ElasticStack系列之二十 & 数据均衡、迁移、冷热分离以及节点自动发现原理与机制

1. 数据均衡

　　某个shard分配到哪一个节点上，通常来讲，是由 ELasticSearch 自行决定的。如下几种状况会触发分配动做：

• 新索引的创建
• 索引的删除
• 新增副本分片
• 节点增减引起的数据均衡

　　在动态分配的时候有几个默认值须要注意，固然对应的这些默认值都是能够修改的，具体以下：

1. ElasticSearch 默认要求全部分片都正常启动成功之后，才能够进行数据均衡操做，不然的话，在集群重启阶段，会浪费太多的流量
2. ElasticSearch 默承认以有 2 个任务同时运行数据均衡。若是有节点增减且集群压力不高的状况下，能够适当增大(可经过 cluster.routing.alloction.cluster_concurrent_rebalance 参数来控制)
3. ElasticSearch 默承认以有 2 个任务同时运行数据恢复操做，前提是除了主分片重启恢复之外的状况下。因此，节点重启时，能够看到主分片迅速恢复完成，副本分片的恢复却很慢。除了副本分片自己数据要经过网络复制之外，并发线程自己也减小一半（默认同时又4个主分片恢复）。固然这种设置也是有道理的--> 主分片必定是本地恢复，副本分片却须要走网络，带宽是有限的。
4. ElasticSearch 默认当数据磁盘使用量占当前磁盘总空间的 85% 时，新索引分片就不会再分配到这个节点上了。在达到 90% 时，就会触发该节点现存分片的数据均衡，把数据挪到其余节点上去。

2. reroute 接口应用（数据迁移）

　　reroute 接口支持三种指令：allocate、move 和 cancel，咱们最经常使用的就是 allocate 和 move 指令。

　　allocate 指令：

　　　　由于负载太高等缘由，有时候个别分片可能长期处于 unassigned 状态，咱们就能够手动分配到指定节点上。默认状况下不容许手动分配副本分片，因此若是是 主分片 故障，咱们须要单独加一个 allow_primary 选项：

　　curl -XPOST 192.168.1.92:9201/_cluster/reroute -d '{
    　　"commands": [
          　　{
              　　"allocate": {
                  　　"index": "test-index",
                  　　"shard": 3,
                  　　"node": "192.168.1.95",
                  　　"allow_primary": true
              　　}
          　　}
      　　]
　　}'

　　注意：

　　　　若是是历史数据的话，须要提早确认一下哪一个节点上保留有这个分片的实际目录，且目录大小最大，而后手动分配到这个节点上，以此来减小数据的丢失。

　　move 指令：

　　　　由于负载太高，磁盘利用率太高，服务器须要下线，更换磁盘等状况。咱们此时须要从该节点一走部分分片数据到其余节点上，那么 move 指令就颇有用了：

　　curl -XPOST 192.168.1.92:9201/_cluster/reroute -d '{
    　　"move": [
          {
              "allocate": {
                  "index": "test-index",
                  "shard": 0,
                  "from_node": "192.168.1.95",
                  "to_node": "192.168.1.93"
              }
          }
      　]
　　}'

3. 冷热数据读写分离

 　　ElasticSearch集群一个比较突出的问题是：用户作一次大的查询的时候，很是大量的读 I/O 以及 聚合计算致使机器 Load 升高，CPU 使用率上升，会阻塞到新数据的写入，这个过程甚至会持续几分钟。因此，可能须要仿照MySQL集群同样，进行读写分离。具体步骤以下所示：

1. N 台机器作热数据的存储，上面只存放当天的数据。这 N 台热数据节点上的 elasticsearch.yml 中配置： node.tag:hot
2. 除今天以外的以前的数据存放到另外 M 台机器上。这 M 台冷数据节点上的 elasticsearch.yml 中配置：node.tag:code
3. 模板中控制对新建的索引添加 hot 标签

{
    "order": 0,
      "template": "test-index-2018-*",
      "settings": {
            "index.routing.allocation.require.tag": "hot"
      }
}

　　 4. 天天计划任务更新索引的配置，将 tag 更改成 code，ElasticSearch中的索引会自动迁移到 M 台冷数据节点上

curl -XPUT http://192.168.1.92:9201/test-index-2018-12-28/_settings -d '{
    "index": {
         "routing": {
             "allocation": {
                 "require": {
                     "tag": "code"
                }
            }
        }
    }
}'

　　这样，写操做集中在 N 台热数据节点上，大范围的读操做集中在 M 台冷数据节点上。避免了堵塞影响。

4. 节点自动发现原理与机制

前提概要：

　　ElasticSearch 是一个 P2P 类型的分布式系统，使用了 gossip 协议。

　　P2P 含义：即 peer-to-peer , 意为 同等位置 对 同等位置，即常说的点对点类型，各个网络中的节点是互相平等的位置，具体含义能够经过下面介绍的 gossip 协议来进行理解。

　　gossip含义：在一个有界网络中，每一个节点都随机地与其余节点通讯，通过一番杂乱无章的通讯，最终全部节点的状态都会达成一致。每一个节点可能知道全部其余节点，也可能仅知道几个邻居节点，只要这些节点能够经过网络连通，最终他们的状态都是一致的，相似于疫情传播的特色。简单的说，要想传播内容就须要有 “种子节点”。“种子节点” 每秒都会随机向其余节点发送本身所拥有的节点列表，以及须要传播的消息。任何新加入的节点，就在这种传播方式下很快地被全网所知道。这个协议的神奇就在它从设计开始就没想到信息必定要传递给全部的节点，可是随着时间的增加，在最终的某一时刻，全网会获得相同的信息。

自动发现机制：

　　咱们知道，ElasticSearch 除了集群状态管理须要 master 节点来控制外，其余全部的请求均可以发送到集群内任意一节点上，这个节点能够本身找到须要转发给哪些节点，而且直接跟这些节点通讯。因此，从网络架构及服务配置上来讲，构建集群所须要的配置机器简单。在无阻碍的网络下，全部配置了相同 cluster.name 的节点都自动归属到一个集群中。ElasticSearch支持两种自动发现策略，分别以下：

　　multicast(组播) 方式

　　只配置 cluster.name 的集群，实际上是采用了默认的自动发现协议，即 组播(multicast) 方式。节点会在本机全部网卡接口上，使用组播地址 224.2.2.4 以 port=54328 创建组播发送 clustername 信息。

　　可是，并非全部的路由交换设备都支持且开启了组播信息传输！甚至能够说，默认状况下，都是不开启组播信息传输的。

　　因此在没有网络工程师的状况下，ElasticSearch 以默认组播方式，只有在同一个交换机下的节点，才能自动发现，跨交换机的节点是没法收到组播信息的。

　　unicast(单播) 方式

　　ElasticSearch 除了组播方式，还支持 单播(unicast) 方式。配置里需提供几台节点的地址，ElasticSearch 将其视做 gossip router 角色，借以完成集群的发现。因为这只是 ElasticSearch 内一个很小的功能，因此 gossip router 角色并不须要单独配置，每一个 ElasticSearch 节点均可以担任。因此，采用单播方式的集群，各节点都须要配置相同的几个节点列表做为 router 便可。配置以下：

discovery.zen.minimum_master_nodes:3
discovery.zen.ping.unicast.hosts: ["192.168.1.92", "192.168.1.93"]