1 扩容 DataNode
假设一个 ES 集群存储或者计算资源不够了,我们需要进行扩容,这里我们只针对 DataNode,即配置为:
conf/elasticsearch.yml:
node.master: false
node.data: true
然后需要配置集群名、节点名等其他配置,为了让该节点能够加入集群,我们把 discovery.zen.ping.unicast.hosts 配置为集群中的 master-eligible node。
conf/elasticsearch.yml:
cluster.name: es-cluster
node.name: node_Z
discovery.zen.ping.unicast.hosts: ["x.x.x.x", "x.x.x.y", "x.x.x.z"]
然后启动节点,节点会自动加入到集群中,集群会自动进行 rebalance,或者通过 reroute api 进行手动操作。
https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-reroute.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/shards-allocation.html
2 缩容 DataNode
假设一个 ES 集群使用的机器数太多了,需要缩容,我们怎么安全的操作来保证数据安全,并且不影响可用性呢?
首先,我们选择需要缩容的节点,注意本节只针对 DataNode 的缩容,MasterNode 缩容涉及到更复杂的问题,下面再讲。
然后,我们需要把这个 Node 上的 Shards 迁移到其他节点上,方法是先设置 allocation 规则,禁止分配 Shard 到要缩容的机器上,然后让集群进行 rebalance。
PUT _cluster/settings
{
"transient" : {
"cluster.routing.allocation.exclude._ip" : "10.0.0.1"
}
}
等这个节点上的数据全部迁移完成后,节点可以安全下线。
更详细的操作方式可以参考官方文档:
https://www.elastic.co/guide/en/elasticsearch/reference/current/allocation-filtering.html
3 扩容 MasterNode
假如我们想扩容一个 MasterNode(master-eligible node), 那么有个需要考虑的问题是,上面提到为了避免脑裂,ES 是采用多数派的策略,需要配置一个 quorum 数:
conf/elasticsearch.yml:
discovery.zen.minimum_master_nodes: 2
假设之前 3 个 master-eligible node,我们可以配置 quorum 为 2,如果扩容到 4 个 master-eligible node,那么 quorum 就要提高到 3。
所以我们应该先把 discovery.zen.minimum_master_nodes 这个配置改成 3,再扩容 master,更改这个配置可以通过 API 的方式:
curl -XPUT localhost:9200/_cluster/settings -d '{
"persistent" : {
"discovery.zen.minimum_master_nodes" : 3
}
}'
这个 API 发送给当前集群的 master,然后新的值立即生效,然后 master 会把这个配置持久化到 cluster meta 中,之后所有节点都会以这个配置为准。
但是这种方式有个问题在于,配置文件中配置的值和 cluster meta 中的值很可能出现不一致,不一致很容易导致一些奇怪的问题,比如说集群重启后,在恢复 cluster meta 前就需要进行 master 选举,此时只可能拿配置中的值,拿不到 cluster meta 中的值,但是 cluster meta 恢复后,又需要以 cluster meta 中的值为准,这中间肯定存在一些正确性相关的边界 case。
总之,动 master 节点以及相关的配置一定要谨慎,master 配置错误很有可能导致脑裂甚至数据写坏、数据丢失等场景。
4 缩容 MasterNode
缩容 MasterNode 与扩容跟扩容是相反的流程,我们需要先把节点缩下来,再把 quorum 数调下来,不再详细描述。