为什么即使我已开启托管式扩缩或满足了调整大小指标，我的 EMR 集群仍无法进行扩缩？

1 分钟阅读

我已开启托管式扩缩或满足了调整大小指标，但我的 EMR 集群无法进行扩缩。

解决方法

未达到 Amazon CloudWatch 指标中设置的扩缩阈值

自动扩缩取决于 Amazon CloudWatch 指标。如果未达到相应的扩展或缩减指标阈值，则不会进行扩缩。

查看 Amazon CloudWatch 中的 Amazon EMR 指标，验证您的扩缩规则中设置的指标（例如 ContainerPendingRatio 和 YARNMemoryAvailablePercentage）是否已填充。

由于以下原因之一，Amazon EMR 指标可能无法按预期在 CloudWatch 中填充：

/etc/hadoop/conf/hadoop-metrics2.properties 文件不存在或已损坏。例如，自定义引导操作可能覆盖了该文件。
Hadoop 或 YARN 等与指标相关的组件可能存在问题。查看相应的应用程序日志以检查是否存在错误。
MetricsCollector 进程守护程序可能未运行。对于托管式扩缩，请在主节点上运行以下命令来检查 MetricsCollector 进程守护程序是否正在运行：
```
sudo systemctl status MetricsCollector
```

使用非基于 YARN 的应用程序

诸如 Presto 等非基于 YARN 的应用程序使用基于 YARN 生成的指标的扩缩方法。因此，即使 Presto 查询利用率很高，集群也不会扩缩。如果您使用的是非基于 YARN 的应用程序，请使用手动扩缩。例如，您可以设置 Amazon EMR 调整大小 API 以使用自定义 Presto 指标。

核心实例组或任务实例组处于暂停或停滞状态

处于暂停或停滞状态的核心实例组或任务实例组在调整大小或扩缩时会陷入停滞。有关更多信息，请参阅暂停状态。

重新配置可能会导致实例组进入停滞状态。有关更多信息，请参阅排查实例组重新配置问题。

Amazon EMR 中的 HDFS 应用程序问题会导致扩缩核心节点时出现问题

如果满足以下两个条件，则最佳做法是保持核心节点不变：

数据存储在 Amazon Simple Storage Service (Amazon S3) 存储桶中。
Hadoop Distributed File System (HDFS) 的利用率处于最低水平。

**注意：**为避免 HDFS 问题，最佳做法是仅扩缩任务节点。

扩缩核心节点比扩缩任务节点耗时更长。这是因为核心节点还有一项用于存储 HDFS 数据的额外服务 (Datanode)。停用 HDFS 数据需要时间。如果您的使用案例需要扩缩核心节点但扩缩处于停滞状态，那么 HDFS 停用可能存在问题。

要排查因 HDFS 停用而导致的扩缩停滞问题，请执行以下操作：

检查 HDFS 服务的运行状况（Namenode 和 Datanode）。
运行 hdfs dfsadmin -report 命令，检查是否存在任何丢失、损坏或复制不足的块。
检查是否有任何核心节点由于磁盘、内存或 CPU 问题而运行状况不佳。
检查您是否将 HDFS 复制因子设置为较高的数值，例如 3 或 2。如果您尝试将核心节点缩减到 1，而复制因子设置为 3 或 2，则扩缩操作会陷入停滞。这是因为 Amazon EMR 必须保持最低副本数量。

请求的容量在 Amazon EMR 中不可用

如果请求的 Amazon Elastic Compute Cloud (Amazon EC2) 容量在 Amazon EMR 中不可用，则扩缩会在超时后失败。如果缩停滞时间超过 2 到 3 小时，并且您在 AWS CloudTrail 事件中收到容量不足错误，则手动调整大小。