为什么我的 Amazon Elasticsearch Service 节点会崩溃?

上次更新时间:2020 年 9 月 10 日

我的 Amazon Elasticsearch Service (Amazon ES) 集群中有一个节点出现故障。这个节点为什么会出现故障?如何防止这种情况再次发生?

简短描述

每个 Amazon ES 节点都在一个单独的 Amazon Elastic Compute Cloud (Amazon EC2) 实例上运行。发生故障的节点是未响应来自其他节点的检测信号的实例。检测信号属于周期性信号,用于监控集群中数据节点的可用性。

以下是集群节点出现故障的常见原因:

  • Java 虚拟机 (JVM) 内存压力高
  • 硬件故障

解决方法

检查出现故障的节点

1.    打开 Amazon ECS 控制台

2.    选择您的 Elasticsearch 域的名称。

3.    选择集群运行状况选项卡,然后选择节点指标。如果节点数少于您为集群配置的数量,则表示有节点发生故障。

注意:节点指标可能会因集群配置更改或者对服务的任何例行维护而不准确。这是预期行为。

确定和排查高 JVM 内存压力

JVM 内存压力是指用于 Elasticsearch 集群中所有数据节点的 Java 堆的百分比。高 JVM 内存压力可能导致 CPU 利用率居高不下,还会产生其他集群性能问题。

JVM 内存压力取决于以下因素:

  • 集群上的数据量与资源量之间的比例。
  • 集群上的查询负载。

在 JVM 内存压力增加时,会发生以下情况:

  • 75% 时:Amazon ES 触发并发标记扫描 (CMS) 垃圾收集器。CMS 收集器与其他进程一起运行,将暂停和中断降至最低限度。
    注意:Amazon ES 向 Amazon CloudWatch 发布了几个垃圾收集指标。这些指标可帮助您监控 JVM 内存使用率。有关更多信息,请参阅使用 CloudWatch 指标监控 Amazon Redshift
  • 高于 75%:如果 CMS 收集器无法回收足够的内存且使用率仍高于 75%,则 Amazon ES JVM 会尝试释放内存。Amazon ES JVM 还会尝试通过减慢或停止进程来防范 JVM OutOfMemoryError (OOM) 异常。
  • 如果 JVM 继续增长但空间没有被回收,则 Amazon ES JVM 会终止尝试分配内存的进程。如果某个关键进程被终止,一个或多个集群节点可能会发生故障。最佳实践是保持 CPU 利用率低于 80%。

要防止 JVM 内存压力高的问题,请遵循以下最佳实践:

  • 避免较大范围的查询,例如通配符查询。
  • 避免同时发送大量请求。
  • 确保使用适当数量的分片。有关索引策略的更多信息,请参阅选择分片数量
  • 确保您的分片在节点之间均匀分布。
  • 避免聚合文本字段。这有助于避免增加字段数据。字段数据越多,占用的堆空间越多。使用 GET _cluster/stats API 操作来检查字段数据。有关字段数据的更多信息,请参阅 Elasticsearch 网站
  • 如果您必须聚合文本字段,请将映射类型更改为关键字。如果 JVM 内存压力过高,请使用以下 API 操作清除字段数据缓存:POST /index_name/_cache/clear(索引级缓存)和 POST */_cache/clear(集群级缓存)。
    注意:清除缓存可能会中断正在进行的查询。

确定和排查硬件故障问题

有时,故障可能会影响 Elasticsearch 集群中的节点可用性。要限制潜在硬件故障的影响,请执行以下检查:

  • 确保您的集群拥有不止一个节点。 单节点集群将引发单点故障。由于主分片和副本分片不能分配到同一节点,您将不能使用副本分片来备份数据。如果该节点出现故障,您可以通过快照还原数据。有关快照的更多信息,请参阅使用 Amazon Elasticsearch Service 索引快照。请注意,您无法恢复上次的快照中未捕获的任何数据。有关更多信息,请参阅调整 Amazon ES 域大小创建和管理 Amazon ES 域
  • 确保您至少拥有一个副本。 如果没有任何副本分片,多节点集群仍可能会发生数据丢失的情况。
  • 启用区域感知。 启用区域感知后,Amazon ES 会在多个可用区中启动数据节点。Amazon ES 会尝试将主分片及其对应的副本分片分配到不同的分区。如果一个节点或可用区中出现故障,您的数据仍然可用。有关更多信息,请参阅配置多可用区域