0
点赞
收藏
分享

微信扫一扫

C#非强签名dll搜索顺序

ETCD跨城容灾与异地多活网络故障的相关表现分析

etcd集群进行分布式设计,并且通过raft协议来进行选leader以及确保数据一致性和高可用能力。本文重点分析在不同网落区之间出现网络中断时,相关的etcd集群的表现,以探究和加强对etcd集群的理解。更多raft协议的理解可以参考 分布式Raft原理详解,从不同角色视角分析相关状态

1. 网络架构

etcd集群一共有7个节点,分别部署在3个IDC,整体架构如下
在这里插入图片描述
在该架构下,理论上能够兼容任意网络区域之间的网络中断,能够重新选举出leader,从而保证etcd整体的可用性。但是当区域的集群表现时,我们通过分析相关日志来验证。

2. 单个网络中断-跟leader区中断

架构如下
在这里插入图片描述

2.1. 网络中断

上图中BC之间的网络出现了中断,leader节点在C区域,集群整体可用

  • 由于leader在C区,并且能够接受来自AC两个区的节点心跳,因此集群leader不会触发选举,整体可用

  • B区由于不能跟C区域通信,跟集群的leader失联,会尝试进行投票选举出新的leade在这里插入图片描述

  • B区的2个节点除了自己投票外,会给A区域的3个节点发送投票申请
    在这里插入图片描述

  • A区的节点由于能够感知到C区的leader心跳,因此会拒绝B区的投票请求
    在这里插入图片描述

  • B区的节点由于无法获取到足够的选票,因此无法选举出leader,并且持续发送投票,因此投票的周期会持续增大
    在这里插入图片描述

2.2. 网络恢复

上图中BC之间的网络恢复后,原leader收到了更高选票周期的B的通信,为了保证数据一致性,会重新出发选

  • B区的节点选票周期虽然更高,但是由于持续没有从原leader同步数据,因此数据索引index小于AC区节点,因此B区不能被选举出leader
    在这里插入图片描述
  • 重新触发选举后,leader会在AC中的节点选举出新leader,从而集群恢复可用
    在这里插入图片描述
  • 新leader选举出来后,会同步相关数据到其他follower节点,保持数据一致

恢复后,重新触发选举leader的原理,在 分布式Raft原理详解,从不同角色视角分析相关状态有说明

3. 单个网络中断-跟非leader区中断

架构如下
在这里插入图片描述

如上图AB区连接中断,由于leader在C区,能够跟A\B正常连接,因此这种情形下,整体集群能够正常提供访问,不会导致leader重新触发选举。

4. 两个网络中断-leader区中断

架构如下
在这里插入图片描述

在这种情况下,由于AC\AB区网络不通,因此会在AB区重新进行选举leader,从而重新提供服务

5. 两个网络中断-非leader区中断

架构如下
在这里插入图片描述
在这里插入图片描述
在这种情况下,leader能够跟其他的区正常连接,因此整体集群能够正常提供服务,也不会重新触发leader选举

6. 两个网络中断-非leader区中断

架构如下

在这里插入图片描述
在这种情况下,由于各个区域网络中断,不能获取超过半数节点选举出leader,因此集群不能对外提供服务。

7. 总结

  • 在3区域环境,按照这样的架构设计,能够兼容非所有区域网络中断的场景,能够兼容2个区网络中断。因此能够提供比较高的高可用服务能力
  • 其他组件在设计多区域高可用时,为了能够保证集群能够兼容多区域之间的网络中断问题,需要确保集群节点数为单数,并且至少3区域,才能在人工不干预的情况下,实现多区域间的网络中断荣灾能力
  • 通常由于在高qps情况下,不通城区之间的网络带宽以及网络时延限制,应当实现多活,并且考虑应用访问 就近原则 以减少网络时延的影响

8. 参考文档

  • 分布式Raft原理详解,从不同角色视角分析相关状态
举报

相关推荐

0 条评论