elasticsearch集群扩容和容灾

时间 2019-11-14

原文原文链接

elasticsearch专栏：https://www.cnblogs.com/hello-shf/category/1550315.htmlhtml

1、集群健康

Elasticsearch 的集群监控信息中包含了许多的统计数据，其中最为重要的一项就是集群健康，它在 status 字段中展现为 green 、 yellow 或者 red。node

在kibana中执行：GET /_cat/health?vmysql

1 epoch      timestamp cluster        status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
2 1568794410 08:13:30  my-application yellow          1         1     47  47    0    0       40             0                  -                 54.0%

其中咱们能够看到当前我本地的集群健康状态是yellow ，但这里问题来了，集群的健康情况是如何进行判断的呢？sql

green（很健康）
    全部的主分片和副本分片都正常运行。
yellow（亚健康）
    全部的主分片都正常运行，但不是全部的副本分片都正常运行。
red（不健康）
    有主分片没能正常运行。

注意：服务器

我本地只配置了一个单节点的elasticsearch，由于primary shard和replica shard是不能分配到一个节点上的因此，在我本地的elasticsearch中是不存在replica shard的，因此健康情况为yellow。架构

2、shard和replica

为了将数据添加到Elasticsearch，咱们须要索引(index)——一个存储关联数据的地方。实际上，索引只是一个用来指向一个或多个分片(shards)的“逻辑命名空间(logical namespace)”. 一个分片(shard)是一个最小级别“工做单元(worker unit)”,它只是保存了索引中全部数据的一部分。道分片就是一个Lucene实例，而且它自己就是一个完整的搜索引擎。咱们的文档存储在分片中，而且在分片中被索引，可是咱们的应用程序不会直接与它们通讯，取而代之的是，直接与索引通讯。分片是Elasticsearch在集群中分发数据的关键。把分片想象成数据的容器。文档存储在分片中，而后分片分配到你集群中的节点上。当你的集群扩容或缩小，Elasticsearch将会自动在你的节点间迁移分片，以使集群保持平衡。分片能够是主分片(primary shard)或者是复制分片(replica shard)。app

你索引中的每一个文档属于一个单独的主分片，因此主分片的数量决定了索引最多能存储多少数据。理论上主分片能存储的数据大小是没有限制的，限制取决于你实际的使用状况。分片的最大容量彻底取决于你的使用情况：硬件存储的大小、文档的大小和复杂度、如何索引和查询你的文档，以及你指望的响应时间。负载均衡

复制分片只是主分片的一个副本，它能够防止硬件故障致使的数据丢失，同时能够提供读请求，好比搜索或者从别的shard取回文档。当索引建立完成的时候，主分片的数量就固定了，可是复制分片的数量能够随时调整。让咱们在集群中惟一一个空节点上建立一个叫作 blogs 的索引。默认状况下，一个索引被分配5个主分片，一个主分片默认只有一个复制分片。elasticsearch

重点：
shard分为两种：
    1，primary shard --- 主分片 2，replica shard --- 复制分片（或者称为备份分片或者副本分片）

须要注意的是，在业界有一个约定俗称的东西，单说一个单词shard通常指的是primary shard，而单说一个单词replica就是指的replica shard。分布式

另一个须要注意的是replica shard是相对于索引而言的，若是说当前index有一个复制分片，那么相对于主分片来讲就是每个主分片都有一个复制分片，即若是有5个主分片就有5个复制分片，而且主分片和复制分片之间是一一对应的关系。

很重要的一点：primary shard不能和replica shard在同一个节点上。重要的事情说三遍：

primary shard不能和replica shard在同一个节点上

因此es最小的高可用配置为两台服务器。

3、master节点、协调节点和节点对等特性

elasticsearch同大多数的分布式架构，也会进行主节点的选举，elasticsearch选举出来的主节点主要承担一下工做：

1 集群层面的设置
2 集群内的节点维护
3 集群内的索引、映射（mapping）、分词器的维护
4 集群内的分片维护

不一样于hadoop、mysql等的主节点，elasticsearch的master将不会成为整个集群环境的流量入口，即其并不独自承担文档级别的变动和搜索（curd），也就意味着当流量暴增，主节点的性能将不会成为整个集群环境的性能瓶颈。这就是elasticsearch的节点对等特性。

节点对等：

所谓的节点对等就是在集群中每一个节点扮演的角色都是平等的，也就意味着每一个节点都能成为集群的流量入口，当请求进入到某个节点，该节点就会暂时充当协调节点的角色，对请求进行路由和处理。这是一个区别于其余分布式中间件的很重要的特性。节点对等的特性让elasticsearch具有了负载均衡的特性。在后面对document的写入和搜索会详细介绍该牛叉的特性。

协调节点：

经过上面的分析，咱们能够得出一个结论，协调节点其实就是请求命中的那个节点。该节点将承担当前请求的路由工做。

4、扩容

通常的扩容模式分为两种，一种是水平扩容，一种是垂直扩容。

4.一、垂直扩容：

所谓的垂直扩容就是升级服务器，买性能更好的，更贵的而后替换原来的服务器，这种扩容方式不推荐使用。由于单台服务器的性能老是有瓶颈的。

4.二、水平扩容：

水平扩容也称为横向扩展，很简单就是增长服务器的数量，这种扩容方式可持续性强，将众多普通服务器组织到一块儿就能造成强大的计算能力。水平扩容 VS 垂直扩容用一句俗语来讲再合适不过了：三个臭皮匠胜过诸葛亮。

4.三、垂直扩容的过程分析

上面咱们详细介绍了分片，master和协调节点，接下来咱们经过画图的方式一步步带你们看看横向扩容的过程。

首先呢须要铺垫一点关于自定义索引shard数量的操做

1 PUT /student
2 {
3    "settings" : {
4       "number_of_shards" : 3,
5       "number_of_replicas" : 1
6    }
7 }

以上代码意味着咱们建立的索引student将会分配三个primary shard和三个replica shard（至于上面为何是1，那是相对于索引来讲的，前面解释过）。

4.3.一、一台服务器

当咱们只有一台服务器的时候，shard是怎么分布的呢？

注：P表明primary shard， R表明replica shard。明确一点在后面的描述中默认一个es节点在一台服务器上。

分析一下上面的过程，首先须要明确的两点：

1，primary shard和replica shard不能再同一台机器上，由于replica和shard在同一个节点上就起不到副本的做用了。

2，当集群中只有一个节点的时候，node1节点将成为主节点。它将临时管理集群级别的一些变动，例如新建或删除索引、增长或移除节点等。

明确了上面两点也就很简单了，由于集群中只有一个节点，该节点将直接被选举为master节点。其次咱们为student索引分配了三个shard，因为只有一个节点，因此三个primary shard都被分配到该节点，replica shard将不会被分配。此时集群的健康情况为yellow。

4.3.二、增长一台服务器

接着上面继续，咱们增长一台服务器，此时shard是如何分配的呢？

Rebalance（再平衡），当集群中节点数量发生变化时，将会触发es集群的rebalance，即从新分配shard。Rebalance的原则就是尽可能使shard在节点中分布均匀，达到负载均衡的目的。

原先node1节点上有p0、p一、p2三个primary shard，另外三个replica shard还未分配，当集群新增节点node2，触发集群的Rebalance，另外三个replica shard将被分配到node2上，即如上图所示。

此时集群中全部的primary shard和replica shard都是active（可用）状态的因此此时集群的健康情况为yellow。可见es集群的最小高可用配置就是两太服务器。

4.3.三、继续新增服务器

继续新增服务器，集群将再次进行Rebalance，在primary shard和replica shard不能分配到一个节点上的原则，此次rebalance一样本着使shard均匀分布的原则，将会从node1上将P1，P2两个primary shard分配到node1，node2上面，而后将node2在primary shard和replica shard不能分配到一台机器上的原则上将另外两个replica shard分配到node1和node2上面。

注意：具体的分配方式上，多是P0在node2上面也有可能在node3上面，可是只要本着Rebalance的原则将shard均匀分布达到负载均衡便可。

5、集群容灾

分布式的集群是必定要具有容灾能力的，对于es集群一样如此，那es集群是如何进行容灾的呢？接下来听我娓娓道来。

在前文咱们详细讲解了primary shard和replica shard。replica shard做为primary shard的副本当集群中的节点发生故障，replica shard将被提高为primary shard。具体的演示以下

集群中有三台服务器，其中node1节点为master节点，primary shard 和 replica shard的分布如上图所示。此时假设node1发生宕机，也就是master节点发生宕机。此时集群的健康状态为red，为何呢？由于不是全部的primary shard都是active的。

具体的容灾过程以下：

1，从新选举master节点，当es集群中的master节点发生故障，此时es集群将再次进行master的选举，选举出一个新的master节点。假设此时新的主节点为node2。

2，node2被选举为新的master节点，node2将做为master行驶其分片分配的任务。

3，replica shard升级，此时master节点会寻找node1节点上的P0分片的replica shard，发现其副本在node2节点上，而后将R0提高为primary shard。这个升级过程是瞬间完成的，就像按下一个开关同样。由于每个shard其实都是lucene的实例。此时集群以下所示，集群的健康状态为yellow，由于不是每个replica shard都是active的。

容灾的过程如上所示，其实这也是通常分布式中间件容灾备份的通常手段。若是你很了解kafka的话，这个就很容易理解了。

　　参考文献：

　　《elasticsearch-权威指南》

　　若有错误的地方还请留言指正。

　　原创不易，转载请注明原文地址：http://www.javashuo.com/article/p-agwjugrf-cx.html