皇上,还记得我吗?我就是1999年那个Linux伊甸园啊-----24小时滚动更新开源资讯,全年无休!

Zookeeper,你可把我坑惨了!

1 说多了都是泪

前些日子,我们被自己部署的 Zookeeper 集群 DDOS 攻击了,惊不惊喜,意不意外?肯定有很多朋友会问,怎么会呢?

一般来说确实不可能,但在一系列条件的配合下,可以把不可能变为可能(感觉好励志有木有!),下面就让我给大家一一道来。

Zookeeper,你可把我坑惨了!

2 交代下前提

在讲故事前,有几个前提先跟大家说明下:

前提一

我们公司服务治理框架用的是 Dubbo,注册中心使用的是 Zookeeper 集群。但是早期规划的时候,为了运维和开发维护简单,将 Zookeeper 的 IP 放到了 F5 的一个 VS Pool 里,后续增加或修改节点直接修改 VS Pool ,应用中注册中心配置的就是这个 VS 地址。

我们年前已经发现这种连接方式存在弊端(应用通过 F5 与 Zookeeper 之间的心跳检测经常中断),并发布了邮件让大家改为直连 Zookeeper 集群,但没有重视,也没有强制要求。

前提二

我们有两个数据中心,且关键业务应用都实现了双活。但因为一些应用没有部署双活,所以存在跨机房服务调用与治理。因此,早期规划的时候 Zookeeper 也是在一个机房部署了集群,但这种模式在 Zookeeper 进行消息广播时,会占用较多的专线带宽。

经监控系统报警后,我们决定在下周进行 Zookeeper 部署改造,一个机房部署普通 Zookeeper 节点,另一个机房部署 Oberserver 节点,同时修改 DNS,让应用连接本机房的 Zookeeper 节点,这样可以有效降低跨机房带宽占用。

3 吃一堑

那是一个周五的下午,大家本应该轻松下班,然后享受周末。突然监控系统报警 F5 流量过高,导致请求被阻塞。紧急来到案发现场,得到的信息是 Zookeeper 集群是流量大户。按照应急处理原则,我们将所有可能的上线都进行了回滚,但问题没有得到改善。于是,我们怀疑是不是某些应用连接 Zookeeper 做了坏事。

通过网络抓包,看了下基本全是 Dubbo 的注册和订阅事件。当时我也非常奇怪,Dubbo 与 Zookeeper 之间只有在心跳检测失败时才会有大量的广播事件,导致流量上升。但我们的 F5 硬件、网络、 Zookeeper 服务都非常正常,一时之间想不到问题的原因,线索又中断了。

所以当时的第一决定是启动紧急上线,即按照前提 1 中提到的,直接修改公司所有应用的配置文件,让大家直连 Zookeeper 集群,而不通过 F5 做代理。这一过程很坎坷,因为涉及的应用太多,但是完成改造后,F5 的流量终于降下来了。

正当我们以为终于解决问题时,灾难再次发生,跨机房专线流量过高,导致电信机房业务受到影响,还是 Zookeeper 在疯狂的广播。当时的第一想法,是不是同时注册引起的,再加上本身专线带宽就不富裕。我们提议将前提 2 中的方案也实施,看一下效果。

经过一番折腾后,专线流量也下来了,同时看业务也恢复了正常,加上人困马乏,我们决定后续再研究下之前抓取的网络包,先让大家回去休息下,以免明天没人支持。

周六的一天,就这样在偶尔的报警中度过了。至于分析网络包,看了几个内容后,发现都是正常的服务注册和订阅事件,也是一头雾水。

Zookeeper,你可把我坑惨了!

然后从周日 5 点开始,部分业务突然报警,网络 Ping 不通。经排查发现,受影响的业务,都是和 Zookeeper 部署在同一宿主机的应用。Zookeeper 吃掉了宿主机 600M 的带宽。由于还是没查询出“内鬼”是谁,我们只能定下临时方案:迁移 Zookeeper ,部署到与业务系统无关的宿主机上。

正当我们赶赴公司,准备完成迁移 Zookeeper 时,突然某个同事发现一个非常大的网络报文。当他把数据包给我看后,真的是柳暗花明的感觉,“内鬼”终于找到了。原来是一个基础服务,配置了很多路由规则,导致一个包的大小有几百 k ,而我们的机房里有将近两千台机器, Zookeeper 的性能又是变态的强,于是一切的巧合安排在一起,一瞬间,流量打死了物理机,打死了专线,打死了 F5……于是,事情就这样发生了。当我们把一堆无用规则删除后,整个世界安静了,所有报警都消失了。

4 长一智

故事讲到这里似乎就结束了,可是等等,我们在这件事故中到底犯了哪些错误,我们来复盘一下:

在前提 1、2 中,我们发现了异常,却没有刨根问底,只是凭感觉认为做个简单处理方案即可。魔鬼在细节,一切的灾难在发生前都是有征兆的,如果再多一丝细心,多一丝警惕,结果也许会全然不同。

同样在前提 1、2 中,整个事件的追踪与跟进完全没有,问题没有闭环,没有协作推进。

监控不完善,不论是内网的流量监控还是 Zookeeper 方面的监控都缺失,完全是靠运气找到了有问题的数据包。

SOA 技术运营缺失,由于功能权限的随意下放,导致造成了灾难的后果。

技术架构选型与搭建时不够谨慎,不管是 Zookeeper 集群的搭建还是 Dubbo 在服务治理那些坑不能踩等等,都没有去仔细讨论与思考。

技术没有好坏之分,关键是看人如何运用。一定避免人云亦云,适合自己公司技术体系的就是最好的。选好自己公司的技术体系后,最重要的就是做好运维与监控工作。监控的每一次报警,就像先兆一样,万万不可掉以轻心。运维的事情,永远是最辛苦最复杂的,但不能因为这些,就将权限随意下放,一定要确保自己可以掌控全局。

转自 http://blog.jobbole.com/112233/