【Elasticsearch-04】集群、节点、分片、副本

背景

分布式系统的可用性与扩展性

• 高可用性
  • 服务可用性 - 允许有节点停止服务
  • 数据可用性 - 部分节点丢失，不会丢失数据
• 可扩展性
  • 请求量 提升 / 数据的不断增长（将数据分布到所有节点上）

分布式特性

• ElasticSearch 的分布式架构的好处
  • 存储的水平扩容
  • 提高系统的可用性，部分节点停止服务，整个集群的服务不受影响
    ElasticSearch的分布式架构
  • 不同的集群通过不同的名字来区分，默认名字 “elasticsearch”
  • 你也可以通过修改配置文件，或者在命令行中 -E cluster.name=wu 进行设定
  • 一个集群可以有一个或者多个节点

节点

• 一个节点就是一个ElasticSeaerch实例
  • 本质上就是一个Java进程
  • 一台机器可以运行多个ElasticSeaerch进程，但是生产环境一般建议一台机器上只运行一个ElasticSeaerch实例
  • 每一个节点都有名字，通过配置文件配置，或者启动时候 -E node.name=node1指定
  • 每一个节点在启动之后，会分配一个UID，保存在data目录下

Master Node

• 每个节点启动后，默认就是一个Master eligible(具备条件的)节点，
  • 可以设置 mode.master:false禁止
    Matser-eligible节点可以参加选主流程，成文Master节点
• 当第一个节点启动的时候，它会将自己选举成Master节点
• 每个节点上都保存了集群的状态，但只有Master节点能够修改集群的状态信息
  • 集群状态(Cluster State)，维护了一个集群中，必要的信息
    • 所有的节点信息
    • 所有的索引和其相关的Mapping与Setting信息
    • 分片的路由信息
  • 任意节点都能修改信息会导致数据的不一致性
• 数据的导入和查询都不会走master节点，所以master节点的压力相对较小，因此master节点的内存分配也可以相对少些；但是master节点是最重要的，如果master节点挂了或者发生脑裂了，你的元数据就会发生混乱，那样你集群里的全部数据可能会发生丢失，所以一定要保证master节点的稳定性。

Data Node

• 专门用于保存和查询数据的节点，负责保存分片数据。在数据扩展上起到了至关重要的作用。它压力会比较大，因此需要多分配点内存，应该选择配置较高的服务器，Data Node要是坏了，可能会丢失一小份数据

Coordinating Node (即Client Node)

• 负责接收Client的请求，将请求分发到合适的节点，最终把结果汇集到一起
• 它也会存元数据，但不会对元数据做任何修改，它的好处在于可以分担下Data Node的一部分压力

Q 为什么Client Node能分担Data Node的一部分压力?

因为ES的查询是两层汇聚的结果，第一层是在Data Node上查询做汇聚，然后把结果转发给Client Node，Client Node接收到Data Node发来的结果后再做第二次的汇聚，然后把最终查询结果返回给用户。so我们看到，Client Node帮忙把第二层的汇聚工作处理了，自然分担了Data Node的压力。

EP：这里，我们可以举个例子，当你有个大数据查询的任务（比如上亿条查询任务量）丢给了es集群，要是没有Client Node，那么压力直接全丢给了Data Node，如果Data Node机器配置不足以接受这么大的查询，那么就很有可能挂掉，一旦挂掉，Data Node就要重新recover，重新reblance，这是一个异常恢复的过程，这个过程的结果就是导致ES集群服务停止… 但是如果你有Client Node，任务会先丢给Client Node，Client Node要是处理不来，顶多就是Client Node停止了，不会影响到Data Node，es集群也不会走异常恢复。

• 每个节点默认都起到了Coordinating Node的职责

其他节点

Hot & Warm Node

• 在做日志case的时候会为节点设置冷热节点，简单来说Hot Node是一些磁盘配置比较高的节点，有着更好的吞吐量和CPU，warm节点存储的都是比较旧的数据，这些节点的配置会比较低，通过冷热节点会帮助集群在硬件开销上减少很多费用
• 不同硬件配置的Data Node，用来实现Hot & Warm架构，降低集群部署的成本

Machine Learning Node

• 负责跑机器学习的Job，用来做异常检测

Tribe Node

• (5.3 开始使用Cross Cluster Search) Tribe Node 连接到不同的ElasticSearch集群，并且支持将这些集群当成一个单独的集群处理

配置节点类型

• 每个节点在启动的时候通过读取elasticsearch.yml来决定自己的角色
• 开发环境中一个节点可以承担多种角色
• 生产环境中，应该设置单一的角色节点（dedicated node）

分片

主分片(Primary Shard & Relica Shard)

• 用以解决数据水平扩展的问题。通过主分片，可以将数据分不到集群内的所有节点之上
  • 一个分片是一个运行的Lucene实例
  • 主分片数在索引创建时指定，后续不允许修改，除非Reindex

副本

• 副本，用以解决数据高可用的问题。
  • 如果出现硬件故障，副本可以保证主分片数据不会丢失，因为副本是主分片的拷贝
  • 副本分片数，可以动态调整
  • 增加副本数，还可以在一定程度上提高服务的可用性
• 一个三节点的集群中，blogs搜索引的分片分布情况
  • number_od_shards设置分片个数，这里有3个分片
  • number_of_replicas设置副本个数，这里设置了一个副本
    
  • 思考：增加一个节点或改大主分片数对系统的影响？
    • 不能起到水平扩展的作用，分片是一开始就提前设置好的，设置好之后不能更改。

分片的设定

• 对生产环境中分片的设定，需要提前做好容量规划
  • 分片数设置过小
    • 导致后续无法增加节点实现水平扩展
    • 单个分片的数据量太大，导致数据重新分配耗时
  • 分片数设置过大，7.0开始，默认主分片设置从5改成1，解决了over-sharding的问题
    • 影响搜索结果的相关性打分，影响统计结果的准确性
    • 单个节点上过多的分片，会导致资源浪费，同时也会影响性能

查看集群的健康状况

• Kibana的Dev Tool 上输入 get _cluster/health
  
  

status	说明
green	主分片与副本都正常分片
yellow	主分片全部正常分片，有副本分片未能正常分配
red	有主分片未能正常分配，例如，当服务器的磁盘容量超过85%时，去创建了一个新的索引