vlambda博客
学习文章列表

HA架构中keepalived疑似脑裂的排查复盘

    今天遇到了一个问题,现象是HA架构直接宕机,15min不可用,LB、NGINX、API网关这些高可用措施完全失效,第一时间迅速切换了备机,晚上回来默默复盘一下。

    首先出现问题之后怀疑是keepalived用了默认的抢占模式,网络瞬断恢复时,极易产生脑裂,网上有很多案例。

原因可能是:

  • 高可用服务器对之间心跳线链路发生故障,导致无法正常通信。如心跳线坏了(包括断了,老化)。

  • 因网卡及相关驱动坏了,ip配置及冲突问题(网卡直连)。

  • 因心跳线间连接的设备故障(网卡及交换机)。

  • 因仲裁的机器出问题(采用仲裁的方案)。

  • 高可用服务器上开启了 iptables防火墙阻挡了心跳消息传输。

  • Keepalived配置里同一 VRRP实例如果 virtual_router_id两端参数配置不一致也会导致裂脑问题发生。

  • vrrp实例名字不一致、优先级一致


紧接着查询流量监控的同时请求基础架构手动切换备机,查看日志:

    看了一下日志,脑裂是两个节点都认为自己是Master,产生双VIP,这种情况下,我们是没有问题的,两个节点都能同时响应请求。

    从Backup节点的这段日志可以很清楚看到这次故障的原因:Backup节点抢到VIP后,间隔5秒发了两次ARP包,昭告天下,让请求走它这边。16:46:02被Master节点抢走VIP,失去VIP后,Master没有发ARP告诉大家,请求还是走Backup节点这边,Backup节点就不会再响应了。

    网络闪断时,Backup节点接管VIP,这是正常。网络恢复后,Backup拱手让出VIP给Master节点。这也是正常。但问题出在Master节点没有发ARP包广播告诉大家,自己成为VIP了。导致请求还是发给Backup,而Backup不是VIP,所以无响应。

    查看keepalived的conf文件,有好几个配置项设置不合理:用的默认的抢占模式(这很危险,网络恢复,Backup就会拱手让出VIP给Master节点),另外,2秒发一次心跳报文,2次收不到就认为对方故障,也不是很合适。
    总之,当时用keepalived时,其实涉及HA机制,都是很危险的。

临时解决方案之一:由LoadBalancer来负责流量路由,这个方案昨天初步讨论还是有一些问题,目前LB直接对应我们多个应用主机IP,流量是均衡的,存在应用随便挂一个,分流到这个挂的节点的服务都响应不了。

    最后,我自己再次深刻反省和思考一下,这次复盘之前,已经暴露了端倪,在演练不够充分的情况下,某一次确实出现过网络闪断这个问题,我当时觉得是极其偶然的情况,没有在意,更没有上报,这次的问题也和我没有太大的关系,我负责的高可用也做了很充分的演练,但是我为什么要悄悄在这里复盘。因为故障是表象,复盘的背后,是技术管理的问题。我应该思考:

    故障无法快速定位是不是系统可观测性设计问题,故障发现是否及时,容量故障是不是限流、降级、熔断措施缺失?系统监控覆盖率是否充足,我们的故障演练在纸上谈兵吗?以及生产环境的人因故障,是否是一次次的缺失生产敬畏之心?在这里我们需要追寻故障根因是什么,但根因往往不止一个。技术的完善带来的是缺陷的增加,这很正常,但故障缓解措施永远依赖于管理手段而非技术。

    我需要自己有连续问为什么的能力,因为这是一种理性思考的推理能力,要求我有技术知识,也要求我在求知的路上不懈怠。

    关于这些我可以再写8000字,但当下我应该先去学习了,我已经充分意识到每个环节所面临的问题,但尽管如此,以我自己的能力目前尚无法改变,我能做的就是再多学点知识,面对问题,可以冷静思考。