动态扩展 Amazon EMR 集群上的存储

Original URL:https://aws.amazon.com/cn/blogs/big-data/dynamically-scale-up-storage-on-amazon-emr-clusters/

在托管的 Apache Hadoop 环境（如 Amazon EMR 集群）中，当集群中的存储容量用满时，没有方便的办法处理该问题。出现这种情况的原因是，您设置了 Amazon Elastic Block Store (Amazon EBS) 卷，并在启动集群时配置了挂载点，因此很难在集群运行后修改存储容量。可行的解决方案通常有：向集群添加更多节点，将数据备份到数据湖，然后启动具有更高存储容量的新集群。如果占用存储的数据可舍弃，也可删除多余的数据。下面将演示如何使用 Amazon EBS 的 弹性卷功能的存储动态扩展来处理此问题。利用此功能，您可以增加卷大小、调整性能或在卷使用过程中更改卷类型。在更改生效期间，您可以继续使用 EMR 集群运行大数据应用程序。

HDFS 和 YARN 如何使用 Amazon EMR 集群上的磁盘空间

默认情况下，创建 Amazon EMR 集群时，HDFS（Hadoop 分布式文件系统）和 YARN会配置为使用所有核心/任务节点上的本地磁盘存储。您可以在 yarn-site.xml 和 hdfs-site.xml 配置文件中对此进行配置。

具体而言，对于 HDFS，在dfs.datanode.data.dir 参数中配置使用本地存储。对于 YARN，yarn.nodemanager.local-dirs 参数将配置为存储 NodeManager运行 YARN 容器所需的中间文件。

例如，当集群运行 MapReduce 作业时，映射任务将其输出文件存储在 yarn.nodemanager.local-dirs 定义的目录中。此外，yarn.nodemanager.log-dirs 参数还配置 YARN 应用程序日志的存储位置。

避免存储问题的常用最佳实践

当您规划在 Amazon EMR 集群上运行的作业时，请参见以下这些避免超出集群可用存储的实用技巧。

规划您未来的存储需求

提前规划作业的存储需求。当您使用默认存储配置启动集群时，它可能无法满足您的工作负载要求，并且您可能会在运行作业时遇到问题。最好估计一下作业所需的中间存储空间。在此基础上，您可以在启动新集群时自定义存储配置。

将被动数据存储在数据湖中

尝试将您的工作负载设计为将所有被动数据存储在 Amazon Simple Storage Service (Amazon S3)数据湖中。这样，您可以仅将集群用于数据处理、执行其他计算任务，并将结果重新存储到数据湖以便永久存储。这种方法最大程度地减少了运行集群的存储要求。

规划更多容量

如果您的使用案例要求输入或输出数据存储在集群本地（HDFS 或本地存储），则您应据此规划集群大小。例如，如果使用 HDFS，则可以创建具有更多核心节点的集群，以便为存储数据提供足够空间。或者，可以自定义核心实例组，使其具有比默认配置更多的 EBS 存储容量。

存储达到最大容量时可能出现的问题

随着 EMR 集群用于运行各种不同的数据处理应用程序，在某一刻，集群上的存储容量可能会耗尽。在这种情况下，会出现一些可能会影响集群的问题，如下所示。

YARN 方面的问题

如果 yarn.nodemanager.local-dirs 或 yarn.nodemanager.log-dirs 参数定义的目录占满了卷总存储容量的 90%时，NodeManager 会将该磁盘标记为不正常。然后，此操作会导致 NodeManager 也将拥有这些磁盘的节点标记为不正常。如果节点不正常，ResourceManager 将不会向该节点分配任何容器。

此外，如果在 EMR 集群上关闭了终止保护功能，EMR 服务最终将终止集群中的此节点。

HDFS 方面的问题

如果集群上的 HDFS 使用量增加，相应的 EBS 卷上的本地存储使用量也会增加。在 EMR 中，HDFS 数据目录配置在与 YARN 本地目录和日志目录相同的挂载点下。因此，如果由于 HDFS 而导致挂载点的使用量超出存储阈值 (90%)，则会再次导致 YARN 将该磁盘标记为不正常，而且 ResourceManager 会将该节点列入黑名单。

动态调整核心节点和任务节点上的存储空间

可以使用下面链接里的Bootstrap Actions脚本来实现动态增加集群中核心节点和任务节点的存储：

s3://aws-bigdata-blog/artifacts/resize_storage/resize_storage.sh

(https://aws-bigdata-blog.s3.amazonaws.com/artifacts/resize_storage/resize_storage.sh )

脚本执行的方法请参考下面链接：

https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-bootstrap.html

另外，集群的 EC2 实例配置文件还必须具有 ec2:ModifyVolume 权限才能调整卷的大小。

该脚本在 EMR 集群的所有节点上运行。它会在节点上配置 cron 作业，并每 2 分钟检查一次磁盘利用率。在主节点上，它会对 root 卷和存储各种主守护程序日志的卷进行检查。在核心节点和任务节点上，它会对 YARN 和 HDFS 使用的卷执行检查，并确定是否需要扩展存储。

当它确定卷超出其使用量的 90% 时，该卷将按照“–scaling-factor”参数指定的百分比进行大小扩展。在调整大小过程中，卷的分区将会扩展，并且文件系统也会扩展并反映更新后的容量。所有这些操作在执行时都不会影响集群上运行的应用程序。

在使用此解决方案之前，请考虑以下注意事项：

只有当 EMR 集群使用 EBS 卷作为其存储后端时，才能扩展该集群中节点的存储容量。某些 EC2 实例类型只使用实例存储卷，或者同时使用实例存储卷和 EBS 卷。无法调整使用此类 EC2 实例类型的集群的存储容量。
当您使用脚本的scaling-factor选项时，请提前规划好增加的卷大小。扩展存储后，必须至少等待 6 小时，才能再次对同一卷进行修改。