ES如何实现高可用(生产环境均为一台机器一个节点)
- ES在分配单个索引的分片时会将每个分片尽可能分配到更多的节点上。但是,实际情况取决于集群拥有的分片和索引的数量以及它们的大小,不一定总是能均匀地分布。
- ES不允许Primary和它的Replica放在同一个节点中,并且同一个节点不接受完全相同的两个Replica
- 同一个节点允许多个索引的分片同时存在。
容错机制
- 啥叫容错?
①傻X的代码你能看懂,牛X的代码你也能看懂
②只能看懂自己的代码,容错性低
③PS:各种情况(支持的情况越多,容错性越好)下,都能保证work 正常运行
④换到咱们ES上就是,就是在局部出错异常的情况下,保证服务正常运行并且有自行恢复能力。 - ES-node
- 节点分类:
- 1)Master:主节点,每个集群都有且只有一个
a.尽量避免Master节点 node.data = true - 2)voting:投票节点
a.Node.voting_only = true(仅投票节点,即使配置了data.master = true,也不会参选, 但是仍然可以作为数据节点)。 - 3)coordinating:协调节点
每一个节点都隐式的是一个协调节点,如果同时设置了data.master = false和data.data=false,那么此节点将成为仅协调节点。 - 4)Master-eligible node(候选节点)
- 5)Data node(数据节点)
- 6)Ingest node:(预处理节点)
- 7)Machine learning node(机器学习节点)
- 两个配置:
- 1)node.master = true node.data = true
这是ES节点默认配置,既作为候选节点又作为数据节点,这样的节点一旦被选举为Master,压力是比较大的,通常来说Master节点应该只承担较为轻量级的任务,比如创建删除索引,分片均衡等。 - 2)node.master = true node.data = false
只作为候选节点,不作为数据节点,可参选Master节点,当选后成为真正的Master节点。 - 3)node.master = false node.data = false
既不当候选节点,也不作为数据节点,那就是仅协调节点,负责负载均衡 - 4)node.master=false node.data=true
不作为候选节点,但是作为数据节点,这样的节点主要负责数据存储和查询服务。
- (3)图解容错机制
①第一步:Master选举(假如宕机节点是Master)
1)脑裂:可能会产生多个Master节点
②第二步:Replica容错,新的(或者原有)Master节点会将丢失的Primary对应的某个副本提升为Primary
③第三步:Master节点会尝试重启故障机
④第四步:数据同步,Master会将宕机期间丢失的数据同步到重启机器对应的分片上去 - 选举过程
- 脑裂过程
- 脑裂”问题可能的成因
1.网络问题:集群间的网络延迟导致一些节点访问不到master,认为master挂掉了从而选举出新的master,并对master上的分片和副本标红,分配新的主分片
2.节点负载:主节点的角色既为master又为data,访问量较大时可能会导致ES停止响应造成大面积延迟,此时其他节点得不到主节点的响应认为主节点挂掉了,会重新选取主节点。
3.内存回收:data节点上的ES进程占用的内存较大,引发JVM的大规模内存回收,造成ES进程失去响应。 - 脑裂问题解决方案:
1.减少误判:discovery.zen.ping_timeout节点状态的响应时间,默认为3s,可以适当调大,如果master在该响应时间的范围内没有做出响应应答,判断该节点已经挂掉了。调大参数(如6s,discovery.zen.ping_timeout:6),可适当减少误判。
2.选举触发 discovery.zen.minimum_master_nodes:1
该参数是用于控制选举行为发生的最小集群主节点数量。
当备选主节点的个数大于等于该参数的值,且备选主节点中有该参数个节点认为主节点挂了,进行选举。官方建议为(n/2)+1,n为主节点个数(即有资格成为主节点的节点个数)
增大该参数,当该值为2时,我们可以设置master的数量为3,这样,挂掉一台,其他两台都认为主节点挂掉了,才进行主节点选举。
3.角色分离:即master节点与data节点分离,限制角色
主节点配置为:
node.master: true node.data: false
从节点配置为:
node.master: false node.data: true
如何提高ES分布式系统的可用性以及性能最大化
- (1)每台节点的Shard数量越少,每个shard分配的CPU、内存和IO资源越多,单个Shard的性能越好,当一台机器一个Shard时,单个Shard性能最好。
- (2)稳定的Master节点对于群集健康非常重要!理论上讲,应该尽可能的减轻Master节点的压力,分片数量越多,Master节点维护管理shard的任务越重,并且节点可能就要承担更多的数据转发任务,可增加“仅协调”节点来缓解Master节点和Data节点的压力,但是在集群中添加过多的仅协调节点会增加整个集群的负担,因为选择的主节点必须等待每个节点的集群状态更新确认。
- (3)反过来说,如果相同资源分配相同的前提下,shard数量越少,单个shard的体积越大,查询性能越低,速度越慢,这个取舍应根据实际集群状况和结合应用场景等因素综合考虑。
- (4)数据节点和Master节点一定要分开,集群规模越大,这样做的意义也就越大。
- (5)数据节点处理与数据相关的操作,例如CRUD,搜索和聚合。这些操作是I /
O,内存和CPU密集型的,所以他们需要更高配置的服务器以及更高的带宽,并且集群的性能冗余非常重要。 - (6)由于仅投票节不参与Master竞选,所以和真正的Master节点相比,它需要的内存和CPU较少。但是,所有候选节点以及仅投票节点都可能是数据节点,所以他们都需要快速稳定低延迟的网络。
- (7)高可用性(HA)群集至少需要三个主节点,其中至少两个不是仅投票节点。即使其中一个节点发生故障,这样的群集也将能够选举一个主节点。生产环境最好设置3台仅Master候选节点(node.master
= true node.data = true) - (8)为确保群集仍然可用,集群不能同时停止投票配置中的一半或更多节点。只要有一半以上的投票节点可用,群集仍可以正常工作。这意味着,如果存在三个或四个主节点合格的节点,则群集可以容忍其中一个节点不可用。如果有两个或更少的主机资格节点,则它们必须都保持可用