ES第二天-ES NODE、高可用，容错机制与Master选举

ES-node

首先，一个Elasticsearch集群(下面简称ES集群)是由许多节点(Node)构成的，Node可以有不同的类型，通过以下配置，可以产生四种不同类型的Node，观察elasticsearch.yml文件：

#是否有竞选master的资格
node.master:true/false
#是否作为存储数据节点
node.data:true/false

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
不作为候选节点，但是作为数据节点，这样的节点主要负责数据存储和查询服务。

角色:

Master: 主节点（主节点，每个集群都有且只有一个）

master节点的主要职责是和集群操作相关的内容，如创建或删除索引，跟踪哪些节点是群集的一部分，并决定哪些分片分配给相关的节点。
稳定的主节点对集群的健康是非常重要的，默认情况下任何一个集群中的节点都有可能被选为主节点，
索引数据和搜索查询等操作会占用大量的cpu，内存，io资源，为了确保一个集群的稳定，分离master和数据节点是一个比较好的选择：
也就是尽量避免Master节点设置 node.data ＝ true

voting: 投票节点（不竞选主节点）

通过设置配置中的node.voting_only=true，（仅投票节点，即使配置了node.master = true，也不会参选, 但是仍然可以作为数据节点）。

Master-eligible node (候选节点)

当node.master为true时，其表示这个node是一个master的候选节点，可以参与选举，在ES的文档中常被称作master-eligible node，类似于MasterCandidate。ES正常运行时只能有一个master(即leader)，多于1个时会发生脑裂。

Data node (数据节点)

当node.data为true时，这个节点作为一个数据节点，数据节点主要是存储索引数据的节点，主要对文档进行增删改查操作，聚合操作等。数据节点对cpu，内存，io要求较高， 在优化的时候需要监控数据节点的状态，当资源不够的时候，需要在集群中添加新的节点。

coordinating: 协调节点

当node.master和node.data配置都设置为false的时候，该节点只能处理路由请求，处理搜索，分发索引操作等，从本质上来说该客户节点表现为智能负载平衡器。
独立的协调节点在一个比较大的集群中是非常有用的，他协调主节点和数据节点，客户端节点加入集群可以得到集群的状态，根据集群的状态可以直接路由请求。
每一个节点都隐式的是一个协调节点，如果同时设置了node.master = false和node.data=false，那么此节点将成为仅协调节点。

不常用：

Ingest node（预处理节点）

Machine learning node (机器学习节点)

建议

在一个生产集群中我们可以对这些节点的职责进行划分，建议集群中设置3台以上的节点作为master节点，这些节点只负责成为主节点，维护整个集群的状态。
再根据数据量设置一批data节点，这些节点只负责存储数据，后期提供建立索引和查询索引的服务，
这样的话如果用户请求比较频繁，这些节点的压力也会比较大，所以在集群中建议再设置一批协调节点(node.master: false node.data: false)，这些节点只负责处理用户请求，实现请求转发，负载均衡等功能。

高可用性（生产环境均为一台机器一个节点）

(1) ES在分配单个索引的分片时会将每个分片尽可能分配到更多的节点上。但是，实际情况取决于集群拥有的分片和索引的数量以及它们的大小，不一定总是能均匀地分布。
(2) ES不允许Primary和它的Replica放在同一个节点中，并且同一个节点不接受完全相同的两个Replica
(3) 同一个节点允许多个索引的分片同时存在。

容错机制

啥叫容错？ 在局部出错异常的情况下，保证服务正常运行并且有自行恢复能力。
ES集群有Master和Slave的角色，一个集群只能有1个Master，假如某一台机器宕机了：
1、此时要看这台机器是否是Master，如果是，会触发Master选举，将会触发其他存活机器中进行选举出一个新的Master节点来，然后另外的节点重新追随新的Master。
2、Replica容错，选举出的新Master（或者非Master节点宕机，原有Master）会检测宕机节点原有的Primary Shared，然后将集群中其对应的副本分片的某一个晋升为Primary Shared。
3、Master尝试重启故障机
4、数据恢复同步，Master会将故障机宕机期间的新增数据以增量的形式同步到重启后的机器对应的分片上去。

Master选举

每个节点会周期性的去探测所有的节点中是否存在Master节点，如果得不到回应，且自身也不是master，该节点会认为master挂了，当达到minimum_master_nodes个节点都认为master挂了，就会触发选举。
然后从候选节点（node.master:true)中去选举master,当某个节点收到票数过半时，此节点将成为master，昭告天下。然后其他节点去追随这个master。

脑裂

假如一个es集群中有2台机器，互相之间网络不能进行通信，那么原来的master还是master，但slave因为感知不到master的存在，且只有自身，便会把自身也升级为master，这样的话，对外就是有2个master了，也就是脑裂。

解决方案

一般来说，需要满足总机器数的过半数，集群才可以正常选举，例如3台机器，需要至少2台可用才可以。
而配置的候选节点数应该是奇数的，而你如果是偶数，es也会给你排掉一个，然后确保台数是奇数的，为什么呢？
试想，如果偶数，有4台机器ABCD,AB可以互相通信，CD可以互相通信，但AB和CD不能通信，此时双方将都会因为无法过半，而选举没有任何进展。
而奇数台的话，如果还是被等分分区，那么一方的2台将可以决定出选举来。

总结（如何提高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）为确保群集仍然可用，集群不能同时停止投票配置中的一半或更多节点。只要有一半以上的投票节点可用，群集仍可以正常工作。这意味着，如果存在三个或四个主节点合格的节点，则群集可以容忍其中一个节点不可用。如果有两个或更少的主机资格节点，则它们必须都保持可用