如何解决 OpenSearch Service 中的 HTTP 503 服务不可用错误？

2 分钟阅读

我想解决在查询我的 Amazon OpenSearch Service 域时，遇到的 HTTP 503 服务不可用错误。

简述

Amazon OpenSearch Service 域使用负载均衡器将传入流量分配到数据节点。资源耗尽可能导致数据节点无响应。示例包括 CPU 使用率高、Java 虚拟机 (JVM) 内存压力大、查询负载过大或索引压力大。当节点无响应时，负载均衡器无法将请求路由到该节点。然后，负载均衡器会返回 HTTP 503 服务不可用状态代码。

注意： 蓝绿部署活动（例如配置更改、软件更新或扩展操作）也可能导致出现 503 状态码。要解决此问题，请等待部署完成以及集群返回到 Active（活动）状态。

解决方法

诊断根本原因

检查集群运行状况

运行以下命令：

GET _cluster/health

如果集群状态为红色，则表示该集群有未分配的主分片，并且数据不可用。如果状态为黄色，则表示该集群有未分配的副本分片。

检查节点级指标

运行以下命令：

GET _cat/nodes?v&h=name,cpu,heap.percent,load_1m,node.role

检查 CPU 使用率大于 80% 或 heap.percent 大于 75% 的节点的输出。

检查 CloudWatch 指标

要确定问题来源，请使用 Amazon CloudWatch 监控以下指标：

5xx： 检查该域返回的 5xx HTTP 状态码的总数。
CPUUtilization： 持续值大于 80% 表示集群处于重负载下。
JVMMemoryPressure： 值大于 75% 时会启动频繁的垃圾回收。值大于 92% 时会启动写入阻塞。
ThreadpoolSearchRejected： 只要增加便表示集群丢弃了搜索请求。
ThreadpoolWriteRejected： 只要增加便表示集群丢弃了写入请求。
IndexingRate： 写入流量的突然激增可能导致 JVM 和 CPU 资源的高度争用。
SearchRate： 搜索流量的突然激增可能导致 JVM 和 CPU 资源的高度争用。

检查域状态

完成以下步骤：

打开 OpenSearch Service 控制台。
在导航窗格中，选择 Domains（域）。
选择您的域。
在 Domain processing status（域处理状态）中，检查域的当前状态。
注意： 如果蓝绿部署处于活动状态，则等待其完成。

检查并发快照操作

OpenSearch 不支持在同一个存储库中执行并发快照操作。一次只能为每个存储库运行一个快照操作，例如创建或删除。如果您尝试运行重叠的快照，则会收到一条带有 503 状态码的“ConcurrentSnapshotExecutionException”错误消息。

错误示例：

{
  "error": {
   "root_cause": [
    {
     "type": "concurrent_snapshot_execution_exception",
     "reason": "[repository-name:xxxxxxxxxx/xxxxxx] cannot restore a snapshot while a snapshot deletion(s) is in-progress [repository-name:xxxxxxxxxx/xxxxxx]"
    }
   ],
   "type": "concurrent_snapshot_execution_exception",
   "status": 503
  }
}

要解决此问题，请等待当前快照完成。如果自动快照长时间卡在 IN_PROGRESS 状态，请联系 AWS Support 手动删除卡住的快照。

预调配更多计算资源

要解决资源耗尽问题，请执行以下操作：

纵向扩展： 切换到更大的实例类型，为您的数据节点提供更多的 CPU、内存和存储空间。有关详细信息，请参阅如何纵向扩展或横向扩展 OpenSearch Service 域？
横向扩展： 向集群添加更多数据节点以分配负载。添加节点时，请添加可用区数量的倍数。例如，如果您使用 3 个可用区，则添加 3 个节点。
使用专用主控节点： 将集群管理任务与数据处理分开，以防止专用主控节点过载。至少使用 3 个专用主控节点。有关详细信息，请参阅 Dedicated master nodes in OpenSearch Service（OpenSearch Service 中的专用主控节点）。
使用正确的实例类型： 为您的工作负载选择具有充足 CPU、内存和存储空间的实例类型。有关详细信息，请参阅 Choosing instance types and testing（选择实例类型和测试）

重要信息： 在集群中至少运行 3 个节点，以便在节点故障期间仍保持可用。单节点或双节点集群没有冗余。如果一个节点出现故障，则其余节点必须处理所有流量，这会导致 503 错误。三个节点可确保集群形成法定人数。这可让集群选择专用的主控节点，而不会出现脑裂的风险。

降低 JVM 内存压力

高于 75% 的 JVM 内存压力会导致垃圾回收长时间暂停，从而消耗 CPU 周期，并可能使节点失去响应。要降低 JVM 内存压力，请执行以下操作：

减少每个节点的分片数量。每个分片都消耗 JVM 堆内存。每个 GiB 的 JVM 堆分片不要超过 25 个。有关详细信息，请参阅 Choosing the number of shards（选择分片数量）。
纵向扩展到更大的实例类型以增加可用的 JVM 堆。OpenSearch 将 50% 的实例 RAM 用于堆，最大容量为 32 GB。
使用关键字字段类型。避免在高基数文本字段上使用字段数据。
如果内存压力非常高，则运行以下命令来清除字段数据缓存：
```
POST /index_name/_cache/clear?fielddata=true
```
注意： 将 index_name 替换为您的索引名称。清除缓存时，可能会中断正在进行的查询。
监控断路器。如果断路器频繁跳闸，则节点有无响应的风险。运行以下命令：
```
GET _nodes/stats/breaker
```

减少查询资源的使用

要减少查询资源的使用，请执行以下操作：

限制查询范围： 缩小搜索时间范围和日期范围。在 OpenSearch 控制面板中使用索引模式来限制全局查询。
避免使用通配符和深度分页搜索： 不要对大型索引使用 select * 或无限制的全量匹配查询。使用 _source 筛选，以便仅返回应用程序需要的字段。
限制客户端流量： 在客户端应用程序上实施退避逻辑、重试策略或排队机制。
缩减旧索引： 使用 _reindex 或 _shrink API 整合过度分片的历史数据，以降低活动分片开销。
实施 ISM（Index State Management，索引状态管理）： 创建 ISM 策略，将较旧、不太活跃的索引从热节点向下迁移到 UltraWarm 或冷存储层。有关详细信息，请参阅 Tutorial: Automating Index State Management processes（教程：自动化索引状态管理流程）。
遵循分片和集群架构的最佳实践。 有关详细信息，请参阅 Amazon OpenSearch Service 101: How many shards do I need?（开始使用 OpenSearch Service：我需要多少分片？）

注意： 数据节点的虚拟 CPU 数量决定 OpenSearch Service 中的线程池容量。您不能直接修改线程池容量。

降低索引压力

如果过度索引导致 503 错误，则执行以下操作：

减少批量索引请求的大小。使用较小的批量，避免节点资源过多。
增加刷新间隔。在大量索引期间将 index.refresh_interval 设置为 60 秒或更长，以减少 I/O 和 CPU 开销。
在批量摄取期间临时将副本设置为零。要降低索引负载，请在批量操作完成后恢复副本。
注意： 如果将副本设置为零，则会降低该时段内的数据耐久性。如果副本设置为零时节点出现故障，则会发生数据丢失。仅对可以从源重新摄取的数据使用此方法。
监控索引背压。查看 ThreadpoolWriteQueue 和 ThreadpoolWriteRejected 指标，以确定集群何时面临索引压力。