设计工作室网站首页,太原营销网站建设制作平台,建设银行的网站进不去怎么办,金堂做网站的公司ES节点故障的容错方案 1. es启动加载逻辑1.1 segment和translg组成和分析1.2 es节点启动流程1.3 es集群的初始化和启动过程 2. master高可用2.1 选主逻辑2.1.1 过滤选主的节点列表2.1.2 Bully算法2.1.2 类Raft协议2.1.3 元数据合并 2.2 HA切换 3. 分片高可用3.1 集群分片汇报3.… ES节点故障的容错方案 1. es启动加载逻辑1.1 segment和translg组成和分析1.2 es节点启动流程1.3 es集群的初始化和启动过程 2. master高可用2.1 选主逻辑2.1.1 过滤选主的节点列表2.1.2 Bully算法2.1.2 类Raft协议2.1.3 元数据合并 2.2 HA切换 3. 分片高可用3.1 集群分片汇报3.2 选举主分片3.4 主分片恢复3.4 副分片恢复3.2 分片恢复的一致性3.2 HA切换逻辑3.3 如果写入过程中分片副本节点宕机会如何处理 4. 疑问和思考4.1 如果一个es宕机运行在es上的shard数据丢失是否会自动做均衡 5. 参考文档 本文主要探讨es集群的高可用容错方案和容错能力的探讨。在出现单机故障时相关的容错方案。
更多关于分布式系统的架构思考请参考文档关于常见分布式组件高可用设计原理的理解和思考 1. es启动加载逻辑
1.1 segment和translg组成和分析
可以参考文章ES高可用架构涉及常用功能整理本文不再赘述。
1.2 es节点启动流程 更多细节可以参考玩转Elasticsearch源码-一图看懂ES启动流程
1.3 es集群的初始化和启动过程
es集群的启动大致流程如下 这里的集群启动过程指集群完全重启时的启动过程期间要经历选举主节点、主分片、数据恢复等重要阶段理解其中原理和细节对于解决或避免集群维护过程中可能遇到的脑裂、无主、恢复慢、丢数据等问题有重要作用。
2. master高可用
2.1 选主逻辑
es的master选主逻辑根据版本不同有不同的调整
7.0版本之前使用Bully算法7.0版本以后使用类Raft协议基于Raft协议做了调整
2.1.1 过滤选主的节点列表
选举的第一步就是需要过滤出选参选的活跃master节点列表并判断活跃的master列表是否满足选举条件。
通过参数discovery.zen.ping.unicast.hosts 获取初始的master列表之后需要做2个事情
通过ping机制获取列表中活跃的master列表由于人工静态配置的列表可能不全因此需要跟活跃的初始列表通信获取集群中能够成为master的所有节点
判断过滤出来的活跃master列表数量是否满足discovery.zen.minimum_master_nodes要求如果不满足说明集群中参选的数量不足有可能会有脑裂的风险不能进一步选举。否则无法满足quorum机制 注 在7.0后版本中废除了discovery.zen.minimum_master_nodes参数而是通过类raft算法自行计算 2.1.2 Bully算法
Bully算法的基本原理就是根据节点的ID大小来判定谁是leader
Bully算法在选举的时候会发送三种消息类型
选举消息 Election Message: Sent to announce election.应答消息Answer (Alive) Message: Responds to the Election message.选举成功消息 Coordinator (Victory) Message: Sent by winner of the election to announce victory.
这三种消息类型组成了Bully的基础消息类型这也是Bully算法选举必须要了解的东西。
分步解释
节点1向节点节点3发送选举并且带上自己的序号1节点23接收到消息之后进行序号比较发觉自己的序号更大向节点1返回应答消息Answer (Alive) Message告知节点1被踢出选主序列大概是这个意思节点2向节点3发送选举请求节点3找不到更高序号的节点发送选举请求了节点3向节点2返回应答消息节点3收不到其他节点的应答消息了节点3被认为是leader向其他节点发送Coordinator Message选举成功的请求将自己是master节点广播到节点1节点2
从如上算法的介绍中可以得知
bully算法有点是简单能够选出leader很容易。bully算法有很多缺陷最大的问题还是master假死后不能重新触发选主和难以规避脑裂问题
因此es给bully算增加了限制以规避bully算法的原生问题。
设置最少得节点参选数量discovery.zen.minimum_master_nodes至少满足(n1)/2选票才能成为leader
这也是为什么在7.0版本选举算法切换为raft的重要原因。
2.1.2 类Raft协议
raft协议经常接触可以参考 ETCD高可用架构涉及常用功能整理不在介绍。
相比于Raft算法Es的选主算法有如下不同
初始为 Candidate状态允许多次投票也就是每个有投票资格的节点可以投多票候选人可以有投票的机会可能会产生多个主节点举例来说如果node1node2node3进行选主
如果node1当选leader但是node2发来了投票要求那么node1无条件退出leader状态node2选为主节点但是node3也发来了投票要求那么node2退出leader状态node3当选主节点。
说明白了就是保证最后当选的leader为主leader
2.1.3 元数据合并
无论是bully算法还是类raft协议并不考虑当前节点的数据是否最新而是在完成选举出leader后进行数据合并中完成数据的一致性问题。
原因是客户端在es的副本写入数据过程中并不会通知master节点因此master节点并不知道哪个节点的元数据最新而是通过后续node节点的数据汇报进行完善在这一点上跟hdfs的nn类似。
这跟etcd、zk有本质区别因为etcd、zk的leader节点也是数据节点所有的数据写入是从leader完成follower进行同步因此能够感知谁的数据最新。而es的master节点和node节点是拆分的因此无法实现这一点因此只能是类raft协议。
因此在完成leader选举后需要进行元数据合并
其他的master角色节点没有选举成为master发送自身的元数据给masternode节点上报自身元数据给mastermaster完成元数据合并后广播到其他的节点经合并
2.2 HA切换
当探测到节点离开事件时必须判断当前节点数是否过半。如果达不到半数以上则放弃Master身份重新加入集群。如果不这么做则设想以下情况假设5台机器组成的集群产生网络分区2台一组3台一组产生分区前Master位于2台中的一个此时3台一组的节点会重新并成功选取Master产生双主俗称脑裂。节点失效检测
、
节点失效检测会监控节点是否离线然后处理其中的异常。失效检测是选主流程之后不可或缺的步骤不执行失效检测可能会产生脑裂双主或多主。
3. 分片高可用
3.1 集群分片汇报
完成master选主后需要重建集群的shard路由表该工作全部都是master完成
最开始时Master不知道主分片在哪它向集群的所有其他节点询问让其他节点把[website][0]分片的元信息发过来。Master 收到所有返回后它就有了这个 shard 的信息然后根据某种策略选一个分片作为主分片。
是不是效率有些低这种询问量shard 数×节点数。所以说我们最好控制shard的总规模别太大。
3.2 选举主分片
构建完所有的分片信息现在考虑把哪个分片作为主分片。
ES 5.x以下的版本通过对比shard级元信息的版本号来决定。
但是有问题: 在多副本的情况下考虑到如果只有一个 shard 信息汇报上来则它一定会被选为主分片但也许数据不是最新的版本号比它大的那个shard所在节点还没启动。因此可能会数据丢失。
在解决这个问题的时候ES 5.x开始实施一种新的策略给每个 shard 都设置一个 UUID然后在元信息中记录哪个shard是最新的(ES是先写主分片再由主分片节点转发请求去写副分片所以主分片所在节点肯定是最新的如果它转发失败了则要求Master删除那个节点所以可以识别哪个分片最新
如果集群设置了禁止分配分片集群仍会强制分配主分片。
cluster.routing.allocation.enable: none因此在设置了上述选项的情况下集群重启后的状态为Yellow而非Red。
3.4 主分片恢复
由于每次写操作都会记录事务日志translog事务日志中记录了哪种操作以及相关的数据。因此将最后一次提交一次提交就是一次 fsync 刷盘的过程之后的 translog中进行重放建立索引如此完成主分片的recovery。
3.4 副分片恢复
副分片的恢复是比较复杂的在ES的版本迭代中副分片恢复策略有过不少调整。副分片需要恢复成与主分片一致同时恢复期间允许新的索引操作。在目前的6.0版本中恢复分成两阶段执行
阶段1
在主分片所在节点获取translog保留锁从获取保留锁开始会保留translog不受其刷盘清空的影响调用接口把shard做快照这是已经刷磁盘中的分片数据把这些shard数据复制到副本节点。在阶段1完毕前会向副分片节点发送告知对方启动engine在阶段2开始之前副分片就可以正常处理写请求了。
针对当前的分片数据做checkpoint并送给副分片恢复耗时长但是并不影响新的数据写入写的数据写入到新的translog中并且在快照期间不会translog不会被清理
阶段2
对translog做快照这个快照里包含从阶段1开始到执行translog快照期间的新增索引将这些translog发送到副分片所在节点进行重放。
涉及的数据量少所以耗时短。
由于需要支持恢复期间的新增写操作让ES的可用性更强这两个阶段中需要重点关注以下几个问题
es的分片恢复根据版本不同有不同的调整
6.0版本之前副本分片数据全部来自主分片需要从主分片同步6.0版本以后副本分片数据先从本地的translog加载在从主分片同步环节主分片压力是一个分片恢复的提升。
3.2 分片恢复的一致性
恢复时因为主副分片恢复时间不一致主分片先进行Recovery然后副分片才能基于主分片进行Recovery所以主分片可以工作之后副分片可能还在恢复中此时主分片会向副分片发送写请求因此恢复reply与主分片可能会同时或者不按发生顺序对同一个doc进行操作。ES中通过doc的版本号解决这个问题当收到一个版本号低于doc当前版本号的操作时会放弃本次操作。对于特定的doc只有最新一次操作生效。
3.2 HA切换逻辑
当主分片不可用时es就会重新进行选举把最新的副本分片提高到主分片的地位由master进行检测和分片选主并在分片完成选主后触发分片的数据恢复逻辑。
3.3 如果写入过程中分片副本节点宕机会如何处理
如果正在写入过程时副本分片宕机或者出现异常master会从shard分片中剔除该分片继续执行写入。
如果分片副本标记写入成功的节点数量满足要求具体等待多少副本取决于wait_for_active_shards的配置值本次写入即可标记成功并返回给客户端如果分片副本标记写入成功的节点数量不满足要求具体等待多少副本取决于wait_for_active_shards的配置值本次写入即可标记失败并返回给客户端客户端来决定是否重试。
4. 疑问和思考
4.1 如果一个es宕机运行在es上的shard数据丢失是否会自动做均衡
取决于是否配置自动分配参数cluster.routing.allocation.enable默认是all表示能够自动触发分配。
all:表示能够自动分配分片如果节点宕机节点上的涉及的分片副本会自动迁移到其他的节点上从而满足副本要求配置了节点标签不满足分配条件的除外none: 不触发自动分配通过在节点主动维护时使用。在进行节点维护时如果希望临时关闭自动分配可以使用如下方式
curl -XPUT http://127.0.0.1:9200/_cluster/settings -d {transient : {cluster.routing.allocation.enable : none}
}是否配置主动触发分配有利有弊主要原因是自动分配不能识别难以识别业务高峰期会占用磁盘io和网络带宽。并且如果只是短时间维护节点触发分配后机器维护完成又要重新触发恢复分配恢复时间较长因此根据实际情况调整。
个人建议
如果能够清楚的知道节点维护的时间和周期比如1-2h可以临时关闭自动分配恢复时间快如果不可预估节点维护的时间或者维护周期过长不建议关闭自动分配数据的安全重要度高
5. 参考文档
ElasticSearch——详细看看ES集群的启动流程ElasticSearch-新老选主算法对比
