kubernetes部署高可用elasticsearch集群（二）深入理解

1. 部署高可用集群

部署高可用elasticsearch的目的：
       日志收集的重要性，不言而喻。使用elasticsearch收集保存日志，根据项目需求，要保证它的可用性。收集Docker容器日志，保证数据不丢失。部署的项目不可能一直可用（会有各种原因），因此，我们部署的应用，要尽可能的高可用。
       本次部署elasticsearch，集群是master节点三个，data节点根据kubernetes的数据节点定。data节点使用DaemonSet设置。
       根据上一篇文章，重点说一下，master节点配置以及data节点的配置。

2. master节点

参数列表：

属性名称	取值说明
cluster.name	节点加入集群的必要条件，节点还需要单播或组播方式加入集群
node.name	节点名称
node.master	是否设置为候选节点
node.data	是否设置为数据节点
node.ingest	是否设置为预处理节点
gateway.recover_after_nodes	设置最少节点，进行数据恢复
discovery.zen.ping.unicast.hosts	加入单播列表，集群使用单播发现
discovery.zen.minimum_master_nodes	最小主节点数，避免脑裂现象
bootstrap.memory_lock	是否开启内存锁定
ES_JAVA_OPTS	设置堆内存

集群的名称：

所有节点配置相同的集群名称，保证集群可以通过集群名称，形成一个整体。配置示例：

  - name: "cluster.name"
    value: "elasticsearch-cluster"

节点名称：

Elasticsearch节点名称默认是随机生成的，为了方便查找，避免日志混乱。每个节点设置一个有意义的、清楚的、描述性的名字。通过设置node.name，${HOSTNAME}是节点所在主机的名称

  - name: "node.name"
    value: "${HOSTNAME}"

候选节点：

通过node.master可以配置该节点是否有资格成为主节点，如果配置为true，则是候选节点。反之，不是。主节点需要集群经过选举产生。考虑较大的集群搭建，因此分离专用的主节点，数据节点。配置示例：

      - name: "node.master" 
        value: "true" 
      - name: "node.data"
        value: "false"
      - name: "node.ingest"
        value: "false"

集群恢复：

当集群重启时，假设10个节点，每个节点保存一个分片，这个分片可能是主分片也可能时副分片，重启集群时出现了5个节点已经启动，还有5个节点没有及时启动。先启动的5个节点先形成集群，重新分配数据，使其均衡。当另外的5个集群重启成功时，删除过时数据或者多余数据。整个过程消耗磁盘，网络带宽。数据传输同样耗时。
通过gateway.recover_after_nodes配置最少多少节点之前恢复集群。可根据集群大小进行配置，配置示例：

      - name: "gateway.recover_after_nodes"
        value: "4"

集群发现：

elasticsearch默认使用单播发现，以防止节点无意加入集群。只有在同一个机器上运行的节点才会自动组成集群。生产环境时，建议使用单播发现。Elasticsearch提供节点列表，当一个节点联系到单播列表的成员时，就会得到整个集群的所有节点状态，然后联系master节点，加入集群。
节点单播列表，并不需要集群中所有节点，建议使用候选节点作为单播列表。配置示例：

     - name: "discovery.zen.ping.unicast.hosts"
       value: "elasticsearch-discovery"

提示：这里的elasticsearch-discovery映射的是所有节点的端口。

最小主节点数：

minimum_master_nodes 设定集群的稳定极其 重要。 这个配置有助于防止脑裂。
如果集群发生了脑裂，那么集群就会处在丢失数据的危险中，因为主节点被认为是这个集群的最高统治者，它决定了什么时候新的索引可以创建，分片是如何移动的等等。如果有两个master节点， 数据的完整性将得不到保证，因为两个节点认为他们有集群的控制权。
这个配置就是告诉 Elasticsearch 当没有足够 master 候选节点的时候，就不要进行 master 节点选举，等 master 候选节点足够了才进行选举。
通过配置discovery.zen.minimum_master_nodes，确定集群中最小主节点数。此设置应该始终被设置为 ( master 候选节点个数 / 2) + 1 。并且最少个数是3。才能保证高可用。
配置示例：

  - name: "discovery.zen.minimum_master_nodes"
    value: "2"
  - name: "discovery.zen.ping_timeout"
    value: "5s"

通过设置discovery.zen.ping_timeout，节点发现集群ping的超时时间。默认为3s。

内存锁定：

内存交换到磁盘对服务器性能来说是致命的。系统默认会进行内存交换，但是kubernetes环境下，禁止内存交换。
一般部署关闭内存交换的方法是：
操作系统中完全禁用 swap。这样可以暂时禁用：

   swapoff -a

如果需要永久禁用，你可能需要修改 /etc/fstab 文件
如果操作系统内存被禁用。在kubernetes环境下通过配置bootstrap.memory_lock为false即可。配置示例：

  - name: "bootstrap.memory_lock"
    value: "false"

如果使用Elasticsearch，bootstrap.memory_lock进行配置，不更改虚拟机swapoff的条件下：
http://ip:port/_nodes?filter_path=**.mlockall查看内存锁定状态，

{
    "nodes": {
        "P7gsqi6VS4-mqndQImjNBA": {
            "process": {
                "mlockall": false
            }
        },
        "LxRhNzJfS76D4d1josmy4A": {
            "process": {
                "mlockall": false
            }
        },
        "iv3HI6uGSbCzB4FqJPsbkg": {
            "process": {
                "mlockall": false
            }
        },
        "kAcpKCcGR-mjYUMECTeUNg": {
            "process": {
                "mlockall": false
            }
        }
    }
}

修改bootstrap.memory_lock，配置示例：

 - name: "bootstrap.memory_lock"
   value: "true"

同时需要修改宿主机：/etc/security/limits.conf

* soft nofile 65536
* hard nofile 65536
* soft nproc 32000
* hard nproc 32000
* hard memlock unlimited
* soft memlock unlimited

修改宿主机/etc/systemd/system.conf

DefaultLimitNOFILE=65536
DefaultLimitNPROC=32000
DefaultLimitMEMLOCK=infinity

部署Elasticsearch集群后，再访问地址
http://ip:port/_nodes?filter_path=**.mlockall

堆内存：

Elasticsearch 默认安装后设置的堆内存是 1 GB。 对于任何一个业务部署来说，这个设置都太小了。如果生产使用这些默认堆内存配置，集群可能会出现问题。通过设置环境变量配置堆内存。堆内存设置不要32G。原有有两个，一、除了Elasticsearch消耗外， 还有另外一个内存消耗非堆内存 （off-heap）：Lucene。二、 JVM 在内存小于 32 GB 的时候会采用一个内存对象指针压缩技术。超过32 GB，浪费了内存，降低了 CPU 的性能，还要让 GC 应对大内存。配置示例：

- name: "ES_JAVA_OPTS"
  value: "-Xms256m -Xmx256m

3.data数据节点

参数列表：

属性名称	取值说明
cluster.name	节点加入集群的必要条件，节点还需要单播或组播方式加入集群
node.name	节点名称
node.master	是否设置为候选节点
node.data	是否设置为数据节点
node.ingest	是否设置为预处理节点
gateway.recover_after_nodes	设置最少节点，进行数据恢复
discovery.zen.ping.unicast.hosts	加入单播列表，集群使用单播发现
discovery.zen.minimum_master_nodes	最小主节点数，避免脑裂现象
bootstrap.memory_lock	是否开启内存锁定
ES_JAVA_OPTS	设置堆内存

数据节点：

通过node.master可以配置该节点是否有资格成为主节点，如果配置为true，则是候选节点。反之，不是。主节点需要集群经过选举产生。
通过配置node.data可以配置节点为数据节点。数据节点保存包含索引文档的分片。如果配置为true，就是数据节点。配置示例：

         - name: "node.master" 
            value: "false" 
          - name: "node.data"
            value: "true"

data节点配置和master节点配置重复的部分，不在赘述。