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字，但当下我应该先去学习了，我已经充分意识到每个环节所面临的问题，但尽管如此，以我自己的能力目前尚无法改变，我能做的就是再多学点知识，面对问题，可以冷静思考。