我的 Amazon OpenSearch Service 域为什么卡在“正在处理”状态?

上次更新日期:2021 年 8 月 5 日

我的 Amazon OpenSearch Service(Amazon Elasticsearch Service 的后继者)集群卡在“正在处理”状态。为什么会发生这种情况,我该如何防止此问题?

简短描述

您的 OpenSearch Service 集群在处于配置更改中时会进入“正在处理”状态。如果出现以下任一情况,集群可能会卡在“正在处理”状态:

  • 一组新的数据节点启动失败。
  • 分区迁移到新的数据节点集不成功。

如果您启动配置更改,则域状态将更改为“正在处理”,而 OpenSearch Service 将创建新环境。在新环境中,OpenSearch Service 启动了一组新的适用节点(例如数据、主节点或 UltraWarm)。迁移完成后,旧节点将终止。

解决方法

一组新的数据节点启动失败

当您在第一次更改完成之前同时对集群进行配置更改时,您的集群可能会卡住。请务必检查集群中是否有任何正在进行的蓝/绿部署。要验证是否有任何正在进行的蓝/绿部署,请检查 Amazon CloudWatch 中的节点总数。如果您观察发现节点数高于预期,则可能正在进行蓝/绿部署。

使用以下 API 调用来检索有关其他节点和分区迁移过程的更多信息:

GET /_cluster/health?pretty and GET /_cat/recovery?pretty

如果您使用的是 Amazon Virtual Private Cloud (VPC) 域,请检查以确保您的子网中有足够的空闲 IP 地址。如果您的子网中指定的 IP 地址不足,则启动新节点将失败。因此,您的集群卡在“正在处理”状态。有关更多信息,请参阅在 VPC 子网中保留 IP 地址

如果您有加密的 OpenSearch Service 域,请确保您的 AWS KMS 密钥存在于您的 AWS 账户中,然后再进行配置更改。如果您不小心删除了 AWS KMS 密钥,则集群可能会卡在“正在处理”状态。

您的集群也可能因以下原因而卡住:

  • 主节点过载,其中有太多待处理的任务或较高的 CPU 和 JVM 内存压力水平。使用 cat pending tasks API 检查任何待处理的任务。您还可以在 Amazon CloudWatch 中检查 MasterCPUUtilizationMasterJVMMemoryPressure 指标。
  • 用于 OpenSearch 控制面板的 Amazon Cognito 身份验证先决条件尚未得到满足。如果您已配置 Amazon Cognito 用于 OpenSearch 控制面板身份验证,请确保满足身份验证先决条件。例如,OpenSearch Service 必须为用户池、Amazon Cognito 身份池和 AWS Identity Access Management (IAM) 角色设置正确的权限。此角色的默认名称为 CognitoAccessForAmazonOpenSearch(附加了 AmazonESCognitoAccess 策略)。
    注意:如果您创建了自定义 IAM 角色,请确保您的角色具有与 CognitoAccessForAmazonOpenSearch 相同的权限。

分区迁移到新的数据节点集不成功

分区迁移(从旧的数据节点集到新的数据节点集)可能会失败,原因如下:

  • 您的 OpenSearch Service 集群当前处于红色运行状态。如果您的集群处于红色运行状态,请对红色集群状态进行问题排查,以使您的集群处于运行正常状态。
    注意:最佳做法是在集群处于正常运行状态时配置集群。
  • 由于 JVM 内存压力和 CPU 使用率高导致的高处理负载,节点无法使用。要解决此问题,请减少集群的网络流量或完全停止网络流量,从而使集群恢复正常运行状态。否则,蓝/绿部署过程可能会超时,需要手动干预。
  • 由于内部硬件故障,在迁移过程中,旧数据节点上的分区可能会卡住。( 注意:根据您的硬件问题,您的集群也可能无法自动恢复。) 如果您的集群无法自动恢复,则 OpenSearch Service 将运行自我修复脚本以使节点恢复到正常运行状态。节点的根卷丢失可能会阻止 OpenSearch Service 响应,随后 Auto Scaling 组会自动替换故障节点。如果节点连接的 EBS 卷出现故障,则需要手动干预才能替换 EBS 卷。要帮助确定哪些分区仍在从更早的节点集运行,请使用以下 API 命令:cat allocation APIcat nodes APIcat shards API
  • 由于新节点集中的可用存储空间不足而导致的分区重新定位停滞。当蓝/绿部署过程中有新数据进入集群时,会出现此问题。
    注意:如果 OpenSearch Service 检测到的空间小于成功数据迁移所需的空间,则不会触发蓝/绿部署。
  • 由固定到更早节点集的分区引起的分区重新定位停滞。要确保分区在进行配置更改之前没有固定到任何节点,请检查索引设置。或者,检查您的集群是否有因 JVM 内存压力高或磁盘空间不足而造成的写入数据块。

要确定哪些索引分区被卡住以及相应的索引设置,请使用以下命令:

curl -X GET "ENDPOINT/_cluster/allocation/explain?pretty"
curl -X GET "ENDPOINT/INDEX_NAME/_settings?pretty"

在索引设置中,检查是否出现以下任一设置:

{
    "index.routing.allocation.require._name": "NODE_NAME" (OR)
    "index.blocks.write": true
    }

如果您在索引设置中观察发现 "index.routing.allocation.require._name": "NODE_NAME",请删除类似于以下内容的设置:

curl -X PUT "ENDPOINT/INDEX_NAME/_settings?pretty" H 'Content-Type: application/json' -d '
{
"index.routing.allocation.require._name": null
}'

有关更多信息,请参阅 Elasticsearch 网站上的索引级分区分配筛选

如果您在索引设置中观察发现 "index.blocks.write": true,则您的集群有一个写入数据块。该写入数据块可能因 JVM 内存压力较高或磁盘空间不足造成。在实施任何其他故障排除提示之前,请务必解决这些问题。如需关于排查此异常问题的更多信息,请参阅 ClusterBlockException

注意:如果您的集群卡在“正在处理”状态超过 24 小时,则您的集群需要手动干预。此外,如果您没有进行任何配置更改,但节点数量高于预期,则软件修补可能正在进行中。


这篇文章对您有帮助吗?


您是否需要账单或技术支持?