Elasticsearch进阶（三）——生产部署：集群参数配置

在生产环境进行Elasticsearch集群部署时，涉及很多的参数配置，其中又涉及Elasticsearch的底层原理。本章，我们就来聊聊生产环境中这些集群参数的含义和配置。

首先说明一点，Elasticsearch的默认参数已经经过了相当好的优化，适合绝大多数的情况，尤其是一些性能相关的配置。因此，生产环境下的ES集群，几乎所有的配置参数都可以用默认的。也许MySQL或Oracle这种关系型数据库，非常看重调优，但是Elasticsearch真的不需要。如果我们真的面临一些Elasticsearch的性能问题，通常建议的解决方案是更好的进行数学建模，或者增加更多的机器资源。

但是在生产环境中，还是有一些业务相关的配置是需要我们修改的，这些配置往往和具体的业务场景相关联，是没法预先给予最好的默认配置的。

一、名称配置

1.1 集群名称

我们首先来看下集群名称的配置，可以在elasticsearch.yml中配置Elasticsearch集群的名称：

cluster.name: your_es_name

默认情况下，Elasticsearch会启动一个名称为elasticsearch的集群，建议一定要将集群名称重新进行命名，主要是避免公司网络环境中，也许某个开发人员的开发机无意中加入你的集群。

1.2 节点名称

每个node启动的时候，Elasticsearch会分配一个随机的名称，这个不适合在生产环境中使用，因为这会导致我们没法记住每台机器，而且每次重启节点都会随机分配，就导致node名称每次重启都会变化。因此，我们在生产环境中是需要给每个node都分配一个名称的，可以在elasticsearch.yml中配置node节点的名称：

node.name: es_node_name

二、路径配置

2.1 目录

默认情况下，Elasticsearch会将plugin、log、data、config等都放在安装目录中。这有一个问题，就是在进行ES升级的时候，这些目录可能会被覆盖掉，导致我们丢失之前安装好的plugin、log、data、config等。

所以建议在生产环境中，必须将这些重要的文件路径都重新设置一下，放在ES安装目录以外的地方，可以通过配置elasticsearch.yml来改变这些目录位置：

• path.data：用于设置数据文件的目录，可以指定多个目录，用逗号分隔即可，如果多个目录在不同的磁盘上，那么这就是一个最简单的RAID 0方式；
• path.logs：用于设置日志文件的目录；
• path.plugins：用于设置插件存放的目录。

一般建议的目录地址是：

path.logs: /var/log/elasticsearch
path.data: /var/data/elasticsearch
path.plugins: /var/plugin/elasticsearch

2.2 配置文件

我们还可以自定义Elasticsearch的配置文件的目录，可以通过以下命令来重新设置：

./bin/elasticsearch -Epath.conf=/etc/elasticsearch/

三、脑裂配置

所谓脑裂问题，其实就是因为网络问题导致的网络分区，比如集群被划分成了两片，每片都有多个data node以及一个master node，那么整个集群中就出现了两个master node。但是因为master node是集群中非常重要的一个角色，主宰了集群状态的维护、shard分配，所以如果有两个master的话就会造成数据不一致。

3.1 最少master候选节点

Elasticsearch中有一个很重要的参数：discovery.zen.minimum_master_nodes。

这个参数告诉Elasticsearch：只有master候选节点的数量满足这个值时，才可以进行master选举。这个参数的值，必须设置为集群中master候选节点的quorum数量，也就是大多数（master候选节点数量 / 2 + 1）。

所以，一个生产环境的Elasticsearch集群，至少要有3个节点，同时将这个参数设置为master候选节点数的quorum，就可以防止脑裂问题的产生。

但是因为es集群是可以动态增加和下线节点的，所以可能随时会改变quorum。所以这个参数也是可以通过API随时修改的，特别是在节点上线和下线的时候，都需要作出对应的修改。而且一旦修改过后，这个配置就会持久化保存下来：

PUT /_cluster/settings
{
    "persistent" : {
        "discovery.zen.minimum_master_nodes" : 2
    }
}

四、shard recovery配置

在集群启动的时候，有一些配置会影响shard恢复的过程。首先，我们需要理解在默认配置下，shard恢复的过程会发生什么事情：

首先，假设我们有10个node，每个node都有一个shard（总共5个primary shard，5个replica shard）。如果我们将集群关闭后进行一些维护性的操作，当我们重启集群的时候，此时可能会出现5个节点先启动了，然后剩下5个节点还没启动。

接着，这5个启动的节点会通过gossip协议互相通信，选举出一个master，然后组成一个集群。他们会发现数据没有被均匀的分布，因为有5个节点没有启动，那么那5个节点上的shard就是不可用的。此时在线的5个node就会将部分replica shard提升为primary shard，同时为每个primary shard复制足够的replica shard。

最后，剩下的5个节点加入了集群。但是这些节点发现本应该由他们持有的shard已经被复制了，此时他们就会删除自己本地的数据。然后集群又会开始进行shard的rebalance操作，将最早启动的5个node上的shard均匀分布到后来启动的5个node上去。

在这个过程中，shard重新复制、移动、删除、再次移动的过程，会耗费大量的网络和磁盘资源。对于数据量庞大的集群来说，可能导致每次集群重启时都有TB级别的数据移动，导致集群启动会耗费很长时间。

4.1 gateway.expected_nodes

如果可以让整个集群中的所有节点都完全上线之后，再进行复制和移动shard，那情况就会好很多。所以，Elasticsearch提供了一个gateway.recover_after_nodes参数，这个参数可以让ES等待足够的node都上线之后，再开始进行shard recovery的过程。

gateway.recover_after_nodes参数一般和gateway.recover_after_time、gateway.expected_nodes配合使用，比如进行如下设置：

gateway.recover_after_nodes: 8
gateway.recover_after_time: 5m
gateway.expected_nodes: 10

上述配置后，Elasticsearch集群的行为会变成这样：等待至少8个节点在线，然后等待最多5分钟或者10个节点都在线，才开始进行shard recovery的过程。这样就可以避免少数node启动时，就立即开始shard recovery，消耗大量的网络和磁盘资源，甚至可以将shard recovery过程从数小时缩短为数分钟（大数据量场景下）。

五、总结

本章，我主要介绍了Elasticsearch的一些通用参数配置，包括集群的名称配置、node名称配置，以及配置文件的默认路径修改。