tencent cloud

随着客户业务的不断发展，ES 集群的数据规模和访问量也越来越大，当集群规模与配置逐渐和业务实际需求不匹配时，客户可选择及时扩容 ES 集群以满足业务的需要。

变配建议综述

当业务遇到瓶颈时，采取何种方式变配是我们需要面对的问题，您可参考下表结合业务情况进行判断（表中提到的滚动模式和蓝绿模式见后文说明）：

说明：

• 上表侧重说明场景和变配方式的对应关系，其中实现原理介绍是针对单独调整当前这一项配置的情况，当同时调整多项配置时（如同时调整节点规格、磁盘容量、磁盘数量），实际的方式会有差异。
• 一次扩容操作只支持对纵向（节点规格、磁盘容量、磁盘数量）或横向（节点个数）的其中一个方向进行调整，不支持纵向横向同时调整。

变配基本概念

当集群变配时，常见的有直接调整、滚动模式、蓝绿模式等，下面将分别介绍这几种变配模式：

直接调整

直接调整不涉及对集群较重的操作（例如重启或拷贝数据），一般来说对线上业务无影响，且变配速度较快。例如，集群横向添加更多节点、或纵向增加磁盘容量等都是直接调整。

滚动模式

对集群中节点逐个滚动重启完成变配，期间系统服务不间断，但可能影响线上访问性能。

• 优点：由于不需要迁移数据，扩容的时间不受集群数据规模影响，变配能够快速完成。适合于集群遇到性能瓶颈，期望快速完成扩容变配的场景。
• 缺点：需要滚动重启集群的每一个数据节点，因此如果集群存在无副本情况下会有丢失数据的风险，且在变配过程中会不停的有节点离开集群和加入集群，会对集群的性能有一定的影响，因此不建议在业务高峰期间选择此种变配方案。
  

蓝绿模式

不重启集群，为原集群添加相同数量的新节点（配置为需要的节点且拷贝原节点数据），完成配置后，无缝切换并剔除掉原节点，变配完成后节点 IP 会发生变化。

• 优点：变配过程中业务不停服，且扩容非常平滑，适合对集群可用性较高的场景。
• 缺点：因涉及数据拷贝，变配耗时和集群数据量成正比，变配时间从数分钟到数天或更长。
  

主要变配场景的原理详述

1. 增加磁盘容量

不改变计算资源配置的情况下提升每个节点的磁盘容量，以提升集群整体的存储量。

原理：扩容单盘容量的流程是对集群中每个数据节点上挂载的磁盘依次进行纵向扩容操作。以达到提升整个集群磁盘存储容量的目的。例如，磁盘原有容量为1000GB，将该磁盘容量提升至5000GB。此种扩容方式无需重启节点和集群，对业务使用集群不造成任何影响。由于集群磁盘容量的扩容是采用数据节点滚动扩容的方式，因此扩容时间与集群节点数量成正相关。预计一个节点扩容需要10秒，以10个数据节点的集群为例，预计扩容磁盘的时间在2分钟左右。流程原理示意图如下图所示：

适用场景：适用于计算资源充足，但是磁盘容量不足的情形。例如，客户集群 CPU 负载和内存使用率都较低，但是磁盘平均利用率较高，且数据都比较重要，不能通过删除数据的方式来释放磁盘空间。此时，客户可选择只扩容磁盘容量的方式来扩容集群。

2. 增加磁盘数量

不改变计算资源配置的情况下提升每个节点的磁盘数量，以提升集群整体的存储量、IOPS 和吞吐量。

原理：将节点上挂载的云盘块数进行提升，例如，原集群中每个数据节点上只挂载了一块盘，通过此流程，能够实现集群中每个数据节点上挂载多块云盘，目前支持蓝绿模式和滚动模式两种变配方式。

• 采用蓝绿模式：
  主要原理是向集群中加入挂载了多块云盘的同等数量的节点，然后将旧节点中的数据迁移至新节点，最后再将旧节点剔除集群。其流程原理示意图如下所示：
  
• 优势：*在整个扩容流程中，集群平滑扩容，适用于对业务稳定性和可用性要求较高的场景。
• 不足：*变配的时间受到集群数据量大小的影响。数据量越大，扩容流程时间越长。
• 采用滚动模式：
  主要原理是直接向原节点中加入更多的盘来达到挂载多盘的目的。由于需要修改节点的集群配置，因此节点需要重启后生效，为了最大程度减少对集群性能的影响，采用滚动重启的方式，即每次只对一个节点进行加盘、重启操作，待节点重新加入集群后再对下一个节点进行操作，以此类推。其流程原理示意图如下所示（灰色表示重启中）。
  
• 优势：*滚动重启扩容的方式由于不需要迁移数据，因此扩容的流程时间不会受到集群数据规模的影响，集群变配能够快速完成。适合于集群遇到性能瓶颈，期望快速完成扩容变配的场景。
• 不足：*此种方案需要滚动重启集群的每一个数据节点，因此，如果集群存在无副本情况下会有丢失数据的风险，且在变配过程中会不停的有节点离开集群和加入集群，会对集群的性能有一定的影响，因此不建议在业务高峰期间选择此种变配方案。

另外，由于 ES 集群不会处理单个节点中的分片再平衡问题，即 ES 不会平衡多数据路径间的分片分配。因此，如果选择了滚动重启的方式向存量节点中直接加盘的方案，ES 会优先将分片分配到最多可用存储空间的磁盘上。这会在短时间内无法发挥多盘的优势，甚至会出现 IO 负载过高的性能问题。直到新磁盘的数据量追上了存量磁盘后，该问题才会得到缓解。另外，当存量集群中单盘的使用率超过了 ES 设置的“水位线”后，意味着整个节点到达了“水位线”，此时即使新盘上还有足够的可用空间，再向节点中加盘也无法解决问题。解决该问题的方法之一是将数据迁移至其他节点或者删除一些数据。

增加磁盘数量方案对比：

3. 添加更多节点

适用于集群的计算资源遇到瓶颈，如 CPU 负载持续较高，内存使用率居高不下，多次触发内存熔断，甚至内存出现 Out Of Memory 现象。此时您可通过对集群节点进行扩容，以提升集群整体性能。

原理：集群添加节点是指在不改变集群节点机型配置的情况下，通过向集群中加入更多节点来完成集群的扩容操作，其流程原理示意图如下所示：

这种扩容流程的优势主要是能够做到平滑扩容，扩容过程中不影响业务使用集群，并且由于在扩容流程中不涉及到新老数据节点间的数据搬迁，因此扩容时间不受节点数量影响，通常在5 - 10分钟完成。

适用场景：节点的配置已经很高，且期望进一步提升集群整体的读写性能，同时对扩容期间集群的稳定性要求较高，这种情况下可选择向集群中添加节点方式进行扩容。

4. 提升节点规格

同样适用于集群的计算资源遇到瓶颈，如 CPU 负载持续较高，内存使用率居高不下，多次触发内存熔断，甚至内存出现 Out Of Memory 现象。可通过对集群节点提升规格，以提升集群整体性能。

原理：节点提升规格是指在不改变集群节点个数的情况下，整体提升集群中数据节点的计算资源配置，目前支持蓝绿模式和滚动模式两种变配方式。例如，将数据节点的配置从4核16G提升到8核16G。

采用蓝绿模式

原理是先将数量大小相等且更高规格的节点加入集群，然后将老节点上的数据全部搬迁到新节点上后，再将老节点剔除集群，以完成集群的扩容操作。其流程原理示意图如下所示：

这种方式的优势主要是能够做到平滑扩容，扩容过程不影响集群的使用和可用性。不足之处在于这种扩容流程需要将老节点中的数据迁移到新节点上，迁移时间受数据量的影响较大，因此如果集群的数据量在 TB 以上，且希望能够尽快完成扩容流程，可选择节点滚动模式，或者通过在 kibana 中设置如下属性，提升数据搬迁的速度：

PUT _cluster/settings  {     "persistent": {      "cluster.routing.allocation.node_concurrent_recoveries":  "8",      "indices.recovery.max_bytes_per_sec": "80mb"   }  } 

其中：

• cluster.routing.allocation.node_concurrent_recoveries 属性表示集群中每个节点上分片并发恢复的个数，默认是2。可根据老数据节点的 CPU 核数 × 4 来确定具体的值，但不要超过50。例如老数据节点为4核16G，则建议该值设置为16，老数据节点为16核64G，则建议该值设置为50，如果发现调大了该值后集群的稳定性受到影响，可适当减小该值。
• indices.recovery.max_bytes_per_sec 属性表示节点之间数据传输的最大带宽限制，默认是40mb。该值不宜设置的过高，否则会破坏集群的稳定性，客户可以5mb为步长，逐步调整该限制值，并持续观察集群的稳定性，最终选择一个相对平衡的值。

适用场景：节点的配置较低，期望提升集群整体的读写性能，但是对集群在扩容期间的稳定性要求较高，且对扩容时间不是很紧急，这种情况下可选择数据搬迁的方式进行扩容。

采用滚动模式

原理是逐个对集群中的节点通过重启的方式完成规格配置的扩容操作。由于该变配方式不涉及到数据迁移，因此变配流程时间不受集群数据规模的影响。变配时间与节点个数成正比，每个节点预计需要3 - 5分钟。其流程原理示意图如下所示（灰色表示重启中）：

适用场景：适合集群节点配置较低，遇到性能瓶颈，对集群稳定性要求不高，期望快速提升集群性能的场景，由于集群在变配过程中节点滚动重启，会有节点不停的离开集群和加入集群，因此建议在业务低峰期操作。

提升节点规格方案对比：