集群升配,集群扩容,集群升级配置,集群变配 - 检索分析服务Elasticsearch版

当Elasticsearch（ES）集群的CPU、内存、磁盘等资源使用率持续处于高位，或查询与写入性能无法满足业务需求时，可通过扩展节点数量、提升节点规格、增加磁盘空间、新增节点类型等方式升级集群配置，恢复服务稳定性。

升配前须知

重要

升配操作可能引发服务延迟、配置冲突及费用变更，请务必提前完整阅读以下须知内容。

服务稳定性

集群变更期间服务稳定性规则：

集群	服务状态	应对措施
正常负载+有副本正常负载：CPU≤60%、堆内存≤50% 、load<核心数	持续服务，性能可能轻微下降	无需额外操作
高负载+无副本高负载：升配时高并发写入或者查询，CPU>60%、堆内存>50%	偶发访问超时	客户端启用重试机制升配前增加索引副本数
高负载+状态异常	偶发访问超时或者抖动	修复集群状态后再变更

操作窗口：业务低峰期进行。

容量规划
合理评估集群所需容量。
配置约束
- 升配不支持版本升级。
- 一次升配操作仅支持变更一种类型的节点。
- V3 架构（云原生新管控）实例不支持关闭智能变更开关：调用更新实例配置的 API 时，即使将 intelligent 参数设置为 false，系统也会将其覆盖为 true；控制台变配页面也不提供智能变更开关，节点规格或磁盘类型升配始终走蓝绿变更路径。
成本影响
提交升配订单后，系统将按照更新后的配置单计费。计费规则请参见按量付费、包年包月。

常见场景推荐规格

根据集群当前的性能瓶颈，参考以下场景选择合适的节点规格族：

场景类型	规格族	示例规格	适用场景
CPU/写入密集型	1:2 计算型（CPU:内存 = 1:2）	8 核 16 GiB	CPU 利用率持续偏高，或写入吞吐量较大的业务。建议在 1:2 规格族内纵向提升核数（如升至 16 核 32 GiB），以直接扩充 CPU 资源。
均衡型	1:4 通用型（CPU:内存 = 1:4）	8 核 32 GiB	CPU 利用率适中、同时需要更大的 JVM 堆内存或堆外内存（page cache）的场景。
内存密集型	1:8 内存型（CPU:内存 = 1:8）	8 核 64 GiB	深度聚合分析、大型索引缓存，或 JVM 堆内存使用率长期偏高的场景。

说明

内存升级对写入速度有一定的间接提升（更大的 JVM 堆内存可减少 GC 停顿，更多的堆外内存可减少磁盘 I/O），但实际效果因业务负载和数据量而异，建议先在测试环境验证后再做决策。如需完整评估集群容量需求，请参见评估集群所需容量。

说明

生产环境不建议使用 ≤2C4G 的小规格节点：在无业务负载的情况下，系统进程和监控索引维护会占用不成比例的基础资源，可能导致 CPU 使用率异常飙升甚至节点失联。建议生产环境最低选用 4C8G 规格的节点。

升配前检查

重要

未完成以下检查直接升配可能导致集群崩溃、数据丢失或服务不可用，请逐项检查验证。

集群健康
执行GET _cluster/health 确保集群为状态为GREEN。如遇集群状态不健康，请参照集群变更报错-集群状态不健康进行解决。
负载安全
执行GET _cat/nodes?v ，建议CPU ≤ 60%，如果超出，客户端启用重试机制，同时增加索引副本数。
索引就绪
- 执行GET /_cat/indices?v检查是否存在状态为CLOSE的索引。如果存在，需执行POST /<index_name>/_open临时打开这些索引，否则配置变更可能失败，原因说明：
  - 存在CLOSE状态的索引时，集群状态无法达到GREEN。ES在执行某些敏感配置变更（如分片分配规则调整）前会强制要求集群状态为GREEN。
  - 变配过程中集群会重新分配分片：
    - 关闭索引的分片无法参与重分配。
    - 导致依赖GREEN状态的操作失败。
    - 导致集群状态无法达到GREEN（最高只能达到YELLOW）。
- 若 CLOSE 索引因业务原因无法打开也无法删除，升配校验仍可能提示“集群状态不健康，不能执行当前操作”。即使执行GET _cluster/health看到集群状态正常，该提示也可能由 CLOSE 索引触发，属于预期的校验行为。此时可在变配页面关闭智能变更，手动将变更方式指定为原地变更后继续升配：原地变更采用滚动更新节点、无需拷贝数据，节点 IP 地址不变，耗时相对较短，适用于存在大量 CLOSE 索引且无法处理的场景。
  说明
  该方案仅适用于可关闭智能变更的 V2 架构实例。V3 架构（云原生新管控）实例不支持关闭智能变更开关，节点规格或磁盘类型升配始终走蓝绿变更路径，架构版本判断方式请参见本文「判断集群架构版本」小节。若当前集群水位较高（如 CPU>60%），选择原地变更时请谨慎评估。
- 执行GET _cat/indices?v检查索引副本数是否至少为1。
  对于多可用区实例，在变更时需确保集群中任意一个索引的副本数小于可用区数，建议副本数设置为1，变更完成后，手动增加副本数。
分片均衡
执行GET _cat/shards?v检查是否存在不均衡的分片。
重要
升配前检查分片分布是否均衡，是预防升配过程中或完成后集群性能恶化甚至崩溃的关键措施。
- prirep：副本分片（r）是否未分配（UNASSIGNED）。
- state：是否存在长期迁移卡住（RELOCATING）。
上述问题会阻止新节点正常接收分片，导致升配后集群状态持续YELLOW/RED，如存在上述问题，请参见集群负载不均解决方案进行解决。

判断集群架构版本

ES 集群存在 v2、v3 两种管控部署架构，架构不同，可选的升配方式与预估耗时也不同（详见本文「方式一：通过控制台升配」中的变更方式耗时说明）。升配前请先确认当前集群的架构版本。

方式一：通过控制台查看

方式二：通过 ES 版本号判断

架构版本	对应 ES 版本号
v2	5.5.3、5.6.16、6.3.2、部分 6.7.0、6.8.6、7.4.0、7.7.1、部分 7.10.0、部分 7.16.2
v3	部分 6.7.0、6.8.23、部分 7.10.0、部分 7.16.2、8.x 及以上

说明

6.7.0、7.10.0、7.16.2 这三个版本号下同时存在 v2 与 v3 架构的实例，无法仅凭版本号唯一判定，请以控制台基本信息页面的管控部署模式字段为准。

方式一：通过控制台升配

在实例列表，单击升配。
更多操作入口：在基本信息页面，单击配置变更 > 集群升配

在变配页面，根据业务需要调整配置项参数。

重要

可调整的配置项参数因集群类型和版本不同而有所出入，以升配页面为准。

可用区数量变配规则如下，如遇可用区规格库存不足时，需迁移可用区下的节点后再升配。
扩增：支持从 1 个可用区扩增至 2 个或 3 个可用区。
缩减：暂不支持将多可用区实例缩减为单可用区。如需此操作，请重新购买满足需求可用区的实例，进行数据迁移，待迁移完成后释放原实例。
支持节点规格（节点存储类型）升级，按性能从低到高排序：
1. 上一代云盘：云盘（普通云盘）-> 高效云盘->SSD云盘。
  说明
  已在部分地域及可用区逐步停止售卖，您在选择云盘时，建议选用ESSD云盘。
2. ESSD云盘：ESSD（Enterprise SSD）云盘结合25 GE网络和RDMA技术，为您提供单盘高达100万的随机读写能力和单路低时延性能。
3. 本地盘。
  说明
  本地盘是ECS实例所在物理机上的本地硬盘设备，为ECS实例提供本地存储访问能力，适用于对存储I/O性能、海量存储性价比有极高要求的业务场景。
SSD 云盘升级为 ESSD 云盘
当集群磁盘 IOUtil 使用率较高且经常打满时，建议将磁盘类型从 SSD 云盘升级为 ESSD 云盘，以提升 I/O 性能。
存储升配约束
- ESSD PL0 限制：已有 SSD 云盘实例升配到 ESSD 云盘时，PL0 不可选，只能选择 PL1 及以上性能级别。新建 ESSD 实例时 PL0 仍可选。
- 强制变更：磁盘已打满导致集群状态异常时，需先删除不必要的索引或降低副本数恢复 GREEN 状态，否则可在升配页面勾选该选项进行强制扩配（会跳过集群健康检查，可能导致服务在重启阶段不稳定）。升配页面同时提供智能变更选项（默认开启），系统会根据变更类型自动选择合适的变更方式。
- 本地盘：本地盘存储空间与实例节点规格物理绑定，无法独立调整；升配本地盘存储空间需依赖整体节点规格的升配。当前新建实例仅支持“新一代云盘型”规格族，本地盘仅适用于存量实例。
- 存储自动扩容：ES 不支持类似云数据库 RDS 的存储自动扩容功能，磁盘空间不足时需手动执行升配操作。
组合变更注意事项：若需同时进行规格升配、磁盘类型变更及扩容，请注意修改磁盘类型不支持原地变更，仅支持蓝绿变更。为避免多次数据迁移，建议分步操作：
1. 先进行实例规格变更和扩容（可使用智能变更或原地变更），待服务恢复后再执行下一步。
2. 单独进行磁盘类型变更（蓝绿变更）。蓝绿变更仅在数据同步完成切换节点时可能有闪断，对业务影响较小。

智能变更（默认开启）：系统根据变配项自动选择最优变更方式。可手动关闭并指定变更方式：

变更方式	原理	耗时	服务影响和使用场景
蓝绿变更	添加新节点→拷贝数据→无缝切换	较长	节点IP会发生变化、集群性能可能出现短暂波动。适用于对变更时长不敏感，对集群可用性要求较高的场景。
原地变更	滚动更新节点（无需数据拷贝）	较短	节点IP无变化、集群性能可能出现短暂波动。适用于集群遇到性能瓶颈，期望快速完成变更的场景。重要如果水位较高（如CPU>60%），谨慎选择原地变更。

V2 架构实例预估耗时（蓝绿变更）

V2 架构集群进行数据节点规格升配或 ES 版本升级时走蓝绿变更，可按以下方式预估耗时：

总耗时 = 管控侧耗时 + 数据迁移耗时

管控侧耗时 = 节点数 × 10 分钟 × 2。蓝绿变更需要先新增一批新节点、再下线一批老节点，因此每个节点按两轮、每轮约 10 分钟计算。
数据迁移耗时（单位：小时）= 单数据节点最大数据量 / indices.recovery.max_bytes_per_sec / 3600。其中 indices.recovery.max_bytes_per_sec 的默认值为 40 MB/s，可通过 GET /_cluster/settings 查看当前值并按需调整。

例如，V2 架构集群有 3 个数据节点做规格升配，管控侧耗时约为 3 × 10 × 2 = 60 分钟（约 1 小时），再加上按上述公式计算出的数据迁移耗时，即为预计总耗时。

V3 架构实例预估耗时（蓝绿变更）

V3 架构集群走蓝绿变更时，可按以下方式预估耗时：

总耗时 = 管控侧耗时 + 数据迁移耗时

管控侧耗时：约 10~20 分钟（涉及新节点启动、下掉老节点）。
数据迁移耗时（单位：小时）= 单数据节点最大数据量 / indices.recovery.max_bytes_per_sec / 3600。

indices.recovery.max_bytes_per_sec 的默认值为 40 MB/s，可通过 GET /_cluster/settings 查看当前值并按需调整。

例如，集群有 3 个数据节点、总数据量 3 TB（单数据节点最大数据量约 1 TB），indices.recovery.max_bytes_per_sec 设置为 100 MB/s 时，数据迁移耗时约为 1 TB / 100 MB/s / 3600 ≈ 2.8 小时。

说明

原地变更并非所有操作都会触发滚动重启：

节点规格变更（如升级 CPU、内存）会逐个重启节点完成变更。
V3 架构集群各升配场景的服务影响如下：
- 存储空间升配：仅执行在线扩容，无需重启节点，不影响变更期间的任务运行。
- 横向扩容（增加数据节点）：老数据节点不重启，变更完成后系统自动进行分片均衡，数据搬迁会占用部分集群资源。
- 节点规格或磁盘类型升配：默认走蓝绿变更，新增节点完成数据迁移后下线老节点，变更结束时业务侧可能出现少量异常，请提前评估影响。

强制变更：跳过健康检查，但会触发集群强制重启，可能导致服务长时间中断（恢复时间取决于数据量），仅用于紧急扩容且集群已不可用场景。

单击查看产品服务协议、服务等级协议，无异议后，单击立即购买，系统按照付费方式收取费用。
变更期间，集群状态变为生效中，集群性能可能出现短暂波动，可能出现请求闪断；变更完成后，集群状态更新为正常。

方式二：调用API升配

集群升配API文档：UpdateInstance

进度监控与升配后验证

升配开始后查看进度：通过控制台->Elasticsearch实例->实例基本信息，单击展开详情：
升配完成后通过集群基本信息页确认配置是否生效：
- 集群状态恢复为正常表示配置已生效。
- 可用区是否与预期一致。
- 节点数和存储规格：确认新节点已加入集群、存储规格是否正确。
- 分片均衡：GET _cat/allocation?v 检查分片分布，如遇分片不均衡，请参考集群负载不均解决方案进行解决。

升配状态长时间处于“生效中”的排查方法

升配开始后，集群状态会变为生效中；如果该状态持续时间超出预期，可按以下方法排查：

正常耗时参考：ESSD 云盘扩容通常需要 30 分钟至 1 小时完成，如果超过 2 小时仍未恢复，需要进一步排查。
V2 架构集群分片分配检查：部分 V2 架构集群在扩容过程中会自动禁用分片分配（cluster.routing.allocation.enable 被设置为 none）以避免扩容期间分片抖动，如果扩容完成后该设置未自动恢复，会导致状态长时间卡在生效中。可在 Kibana Dev Tools 中执行以下命令重新启用分片分配：
```
PUT /_cluster/settings
{
  "transient" : {
    "cluster.routing.allocation.enable" : "all"
  }
}
```
迁移加速：如果数据搬迁速度较慢导致耗时变长，可在控制台将节点数据传输带宽调整至 80 以加速数据迁移。
业务连接超时说明：升级过程中实例重启会导致业务连接短暂超时，这属于正常现象，建议业务端增加重试机制以降低影响。

常见问题

升配与性能指标

Q：升配一定能解决我的ES集群性能问题吗？

A：不一定。升配（增加CPU、内存、磁盘等资源）并非万能解决方案。在决定升配前，请先分析具体瓶颈：

CPU瓶颈：持续长时间超过80%的CPU使用率（非短暂峰值）
内存瓶颈：频繁出现GC时间过长、内存交换（swap）或OOM错误
磁盘瓶颈：关注实际I/O吞吐量而非仅看%util指标（详见下文）
网络瓶颈：网络带宽持续打满，延迟明显增加

升配前请先确认实际瓶颈所在，避免不必要的资源浪费。有时通过索引优化、查询优化或调整配置可能比单纯升配更有效。

Q：为什么我的%util指标经常达到100%，但系统似乎运行正常？

A：iostat中的%util指标表示设备有I/O（即非空闲）的时间比率，不考虑I/O请求量有多少，只考虑有没有I/O活动。由于现代硬盘设备具备并行处理多个I/O请求的能力，即使%util达到100%，也不意味着设备已饱和：

例如：某硬盘处理单个I/O需要0.1秒，有能力同时处理10个I/O请求
- 当10个I/O请求依次提交时，需要1秒完成，此时%util为100%
- 若10个I/O请求一次性提交，0.1秒就完成，此时%util只有10%

重要提示：%util指标在现代存储系统中已基本失去参考意义，不应仅凭此指标判断是否需要升配。

Q：应该关注哪些指标来判断磁盘性能瓶颈？

A：应重点关注以下指标而非仅看%util：

I/O吞吐量：实际读写数据的速率（MB/s），与您的业务需求对比
响应时间：I/O请求的延迟时间，直接影响查询性能
IOPS：每秒I/O操作数量，与业务模式匹配
队列深度：反映I/O请求等待情况

建议：非长时间（持续数小时）达到100%的%util指标无需特别关注。真正的性能瓶颈应通过fio等专业工具进行压测，获取实际的极限带宽和IOPS值来判断。

Q：如何正确评估磁盘是否达到性能瓶颈？

A：请按以下步骤进行评估：

分析业务模式：了解您的读写比例、I/O大小等特征
关注实际吞吐量：与业务需求对比，而非仅看%util
使用专业工具测试：通过fio等工具模拟实际业务负载，测试磁盘在真实场景下的性能
评估查询延迟：ES查询响应时间是否满足业务要求
监控关键指标：如indexing latency、search latency等ES内部指标

如需确认是否需要升配，请提供完整的性能监控数据，包括但不限于：CPU使用率、内存使用情况、I/O吞吐量、查询延迟等，而非仅基于单一指标做决策。

升配操作影响

Q：升配或磁盘扩容是否支持设置执行时间或立即生效？

A：升配和磁盘扩容均不支持定时执行。无论是升配（如提升节点规格、扩节点）还是磁盘扩容，配置提交并支付后，系统会立即生效并触发变更与重启流程，无法指定具体的执行时间或重启时间。如果希望在特定时间点（如业务低峰期凌晨 3 点）执行变更，需在该时间点手动完成支付和提交操作。

Q：增加数据节点后是否需要重建索引？

A：不需要。增加数据节点是在线操作，集群会自动处理数据的重新分布（Rebalance），现有的索引、数据和业务查询都不会中断。

Q：小规格（≤2C4G）ES 节点在无业务负载时 CPU 飙升至 90% 以上并导致节点失联，是什么原因？如何处理？

A：出现该现象通常由以下原因导致：

资源规格不足：≤2C4G 规格下，系统进程本身会占用一部分基础资源，官方不建议在生产环境使用 ≤2C4G 规格的节点。
JVM 堆内存水位过高：堆内存使用率长期处于 85% 以上时，轻微的负载波动即可将堆内存打满，从而频繁触发 Full GC，导致 CPU 出现峰值。
监控开销放大：在低规格节点上，监控索引的维护开销相对于节点总资源占比更高，容易造成资源消耗不成比例地上升。

解决方案：

紧急处理：重启异常节点，释放被占用的资源，此方式仅为临时缓解措施。
根本处理：将节点规格升配至 4C8G 或更高规格，升配操作请参见本文「方式一：通过控制台升配」章节。

Q：升配期间如何保障业务连续性？

A：建议采取以下措施：

确保每个索引至少有 1 个副本，并使集群资源使用率保持在正常水平。
升配期间可能出现请求闪断，需在应用端配置重试机制。
升配期间如发生故障，请及时切流。

检索分析服务Elasticsearch版：升配集群