男儿欲遂平生志，六经勤向窗前读。这篇文章主要讲述DevOps笔记：脑裂对系统可用性的影响相关的知识，希望能为你提供帮助。
1.
事件时间线
时间 | 问题和动作 |
03:55 | 凌晨三点五十五分IT监控室报了一个预警工单(Mediumpriority) ,提示用户APP平台上的业务渠道的API 网关调用服务时异常返回值占比很高（由于事发后半夜，工单为Medium 非工作时间，这一报警并没有引起IT和业务负责人的广泛关注，也并无激活相关IM等人员）。 |
07:59 | 直到早晨八点钟，业务团队负责人提交了一个IT故障工单，表示用户APP不能正常登陆，并且几分钟之内，陆续有其他业务团队报上来同样问题。 |
08:07 | 随后,IT 的incident事件协调员激活了用户APP团队的资深技术同事介入调查。用户APP 技术团队反馈说有nginx502的报错，提示服务器端问题，所以建议IT 的Linux和网络组深入调查。 |
08:15 | Linux团队很快查出Nginx代理有网络的timeout 提示，并提供具体的源IP地址和目的IP地址，以便网络团队更进一步定位根因。 |
08:30 | 问题自动修复，参考监控图像并且跟业务方负责人确认到，业务已经恢复，用户APP正常登陆。 |
11:33 | 直至此时，网络团队并没有发现什么异常，需要更多的时间进一步调查根因，IT事件协调员开了PR工单以便后续追踪和更新根因细节。 |
2. 根因分析
2.1 5-Why分析
# | Why | Answer |
1 | 为什么用户APP 不能正常登陆 【DevOps笔记（脑裂对系统可用性的影响）】 | 因为用户APP的代理服务器集群出现了问题，提供了错误的VIP。 |
2 | 为什么用户APP代理节点出现错误的VIP. | Nginx代理服务器的主从节点中，由于从节点(slave)不能从主节点(master)获取心跳信息，从服务器(slave)申请自己作为主服务器，产生了脑裂(split brain)。 |
3 | 为什么会出现‘脑裂’现象？ | 代理服务部署的高可用架构是Keepalived+Nginx模式（在每个Nginx节点上部署Keepalived），当日，在夜间服务器例行备份的时候，对Nginx VM进行快照生成/删除动作，由于虚拟机文件系统中的虚机磁盘格式是VMDK 格式，通常VMDK文件都比较大，2TB 起步不足为奇，所以也被定义为‘大的，块级I/O模式’，因此，快照会对虚机的性能造成严重的影响，导致对外响应超慢，此过程会导致服务器临时对请求无响应（假死状态）。从而影响到了一直运行在主/从代理之间的HeartBeat（心跳）健康检查，从节点在一定时间内没能监听到来自主节点的VRRP广播，此刻，从节点的服务器就认为主节点已经死亡失效，随即升级自己为主服务器，对外的VIP也漂到从服务器这边。而主节点很快恢复了heartbeat，此时出现了两个“主节点”，即“脑裂“：两个‘’主节点‘’互相争抢决策权和资源。但很快脑裂结束，原有的主节点最终成为了唯一的主节点。 |
4 | 脑裂结束后为什么VIP仍然出现错误？ | ‘脑裂’期间，代理的VIP也被切到从节点这一方，根据keepalived的配置，从节点服务器被提权升为主节点时，它发送了ARP更新的广播，更新了网络内其他服务，如F5，的ARP表（ARP表是在缓冲区中建立一个映射关系列表，以表示 IP 地址和MAC 地址之间的对应关系）。‘脑裂’结束时，主节点服务恢复正常，主从节点的heartbeart也恢复，原有的主节点因为没有发生身份变化，ARP广播没有发生，也就导致当请求查询ARP 表的时候，流量被导到表中记录的从节点的MAC地址，而不是主节点的MAC地址，从节点收到数据包后在IP层解析时发现IP地址不正确，将丢弃数据包，导致数据请求方得不到正常的响应。直到4小时后ARP刷新了才能正确访问到主节点。 |
5 | 为什么ARP的错误映射持续了4个小时才恢复？ | 在无人干预的情况下，二层网络交换协议会自动对ARP表项进行更新，而网络层默认的设置是14400秒，即4个小时整。 |
2.2 结论
根因总结 |
ARP缓存表在服务器异常期间被更新后，在之后很长一段时间内没有及时刷新到正常状态，保留了老化的映射关系，导致网络引流错误。 |
细节描述 |
在Keepalived+Nginx高可用模式下（在每个Nginx节点上部署Keepalived），遇到夜间Nginx服务器打快照，消耗大量I/O，对服务器性能造成了严重影响，导致服务器处于‘假死’，主备服务器节点开始了‘脑裂’行为。于是更新了ARP 表。但是脑裂期结束后，ARP表并没有根据结束后的状态重新刷新映射关系，而是保留了老化的错误映射关系，导致流量都分配到错误的IP, 最终导致用户APP登录服务中断。 |
3. 解决方案和防范措施
3.1 问题解决方案
具体方案 |
服务自动恢复，经过四个小时的时间，ARP 表自动更新。 |
# | 具体措施 |
1 | 捕获用户APP的http请求状态，监控是不是有大量的502返回值，以便初步定为是否是服务器端的问题 |
2 | 改进keepalived的监控，及时捕捉keepalived的健康状况，对新的可用VIP进行网内广播 1） 当keepalived服务发生改变时，广播推送VRRP包（虚拟路由器冗余协议） 2） 进行时间颗粒度小到分钟级的发包策略,确保主从服务之间沟通顺畅，ARP 能够快速及时更新到最新状态，避免ARP 老化导致的服务异常 |
3 | 从服务器层添加对TCP连接状态的监控。 |
4. 经验教训
总结 |
监控的级别设置不合理，导致事故出现端倪的时候没有引起足够的重视。 架构设计上存在瑕疵，没有考虑到极端情况，例如脑裂和突发灾难。 |
推荐阅读
|
