本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # SageMaker HyperPod FAQs 使用以下常见问题来解决使用问题 SageMaker HyperPod。 **Topics** + [为什么我在 Amazon 中找不到我的 SageMaker HyperPod 集群的日志组 CloudWatch？](#hyperpod-faqs-q1) + [在 Slurm 配置文件（例如`slurm.conf`和）中 HyperPod 管理哪些特定的配置？`gres.conf`](#hyperpod-faqs-q2) + [如何在 Slurm 节点上运行 Docker？ HyperPod](#hyperpod-faqs-q3) + [当我在平台上使用 NVIDIA 集体通信库 (NCCL) 和 Slurm 时，为什么我的并行训练任务会失败？ SageMaker HyperPod](#hyperpod-faqs-q4) + [如何使用本地 NVMe 存储的 P 实例来启动带有 Slurm 的 Docker 或 Enroot 容器？](#hyperpod-faqs-q5) + [如何设置 EFA 安全组？](#hyperpod-faqs-q6) + [如何监控我的 HyperPod 群集节点？ 是否有从中导出的 CloudWatch 指标 HyperPod？](#hyperpod-faqs-q7) + [我能否向 HyperPod 群集节点添加额外的存储空间？ 集群实例的本地实例存储空间有限。](#hyperpod-faqs-q8) + [为什么我的计算节点在重启后显示为“DOWN”或“DRAINED”？](#hyperpod-faqs-q9) + [为什么我的节点总是因内存不足（OOM）问题而被置为不可用状态？](#hyperpod-faqs-q10) + [如何确保在作业完成后正确清理资源？](#hyperpod-faqs-q11) ## 为什么我在 Amazon 中找不到我的 SageMaker HyperPod 集群的日志组 CloudWatch？ 默认情况下，代理日志和实例启动日志会发送到 HyperPod 平台账户的 CloudWatch。如果是用户生命周期脚本，则生命周期配置日志会发送到您的账户 CloudWatch。 如果您使用 HyperPod 服务团队提供的[生命周期脚本示例](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md)，则可以找到写入的生命周期配置日志`/var/log/provision/provisioning.log`，并且不会遇到此问题。 但是，如果您使用自定义路径从生命周期配置中收集日志，但找不到账户中显示的日志组 CloudWatch，则可能是由于生命周期脚本中指定的日志文件路径与在 HyperPod 集群实例上运行的 CloudWatch 代理所查找的内容不匹配。在这种情况下，这意味着您需要正确设置生命周期脚本以向 CloudWatch 代理发送日志，并相应地设置 CloudWatch 代理配置。要解决问题，请选择以下选项之一。 + **选项 1：**更新生命周期脚本，将日志写入 `/var/log/provision/provisioning.log`。 + **选项 2：**更新 CloudWatch 代理以查找用于日志生命周期配置的自定义路径。 1. 每个 HyperPod 集群实例都包含一个 JSON 格式的 CloudWatch 代理配置文件，位于`/opt/aws/amazon-cloudwatch-agent/sagemaker_cwagent_config.json`。在配置文件中找到字段名 `logs.logs_collected.files.collect_list.file_path`。默认设置为 HyperPod，键值对应`"file_path": "/var/log/provision/provisioning.log"`如中所述。[SageMaker HyperPod 在实例级别进行日志记录](sagemaker-hyperpod-cluster-management-slurm.md#sagemaker-hyperpod-cluster-management-slurm-logging-at-instance-level)以下代码片段显示了 HyperPod 默认配置下 JSON 文件的外观。 ``` "logs": { "logs_collected": { "files": { "collect_list": [ { "file_path": "/var/log/provision/provisioning.log", "log_group_name": "/aws/sagemaker/Clusters/[ClusterName]/[ClusterID]", "log_stream_name": "LifecycleConfig/[InstanceGroupName]/{instance_id}", "retention_in_days": -1 } ] } }, "force_flush_interval": 3 } ``` 1. 用生命周期脚本中使用的自定义路径替换 `"file_path"` 字段名的值。例如，如果您已将生命周期脚本设置为写入 `/var/log/custom-provision/custom-provisioning.log`，请按如下方式更新该值以与之匹配。 ``` "file_path": "/var/log/custom-provision/custom-provisioning.log" ``` 1. 使用配置文件重新启动 CloudWatch 代理以完成自定义路径的应用。例如，以下 CloudWatch 命令显示如何使用步骤 1 中的 CloudWatch CloudWatch 代理配置文件重新启动代理。有关更多信息，另请参阅对[ CloudWatch 代理进行故障排除](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/troubleshooting-CloudWatch-Agent.html)。 ``` sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \ -a fetch-config -m ec2 -s -c \ file:/opt/aws/amazon-cloudwatch-agent/sagemaker_cwagent_config.json ``` ## 在 Slurm 配置文件（例如`slurm.conf`和）中 HyperPod 管理哪些特定的配置？`gres.conf` 当您在上创建 Slurm 集群时 HyperPod， HyperPod 代理会根据您的集群创建请求[https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html)和生命周期脚本`/opt/slurm/etc/`将和[https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html)文件设置为管理 Slurm HyperPod 集群。以下列表显示了 HyperPod 代理处理和覆盖的特定参数。 **重要** 我们强烈建议您不要更改由管理的这些参数 HyperPod。 + 在中 [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html)， HyperPod 设置以下基本参数：`ClusterName``SlurmctldHost`、`PartitionName`、和`NodeName`。 此外，要启用该[自动节点恢复和自动恢复](sagemaker-hyperpod-resiliency-slurm-auto-resume.md)功能， HyperPod 需要按以下方式设置`TaskPlugin`和`SchedulerParameters`参数。默认情况下， HyperPod 代理将这两个参数设置为所需的值。 ``` TaskPlugin=task/none SchedulerParameters=permit_job_expansion ``` + 在中 [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html)， HyperPod 管理 G `NodeName` PU 节点。 ## 如何在 Slurm 节点上运行 Docker？ HyperPod 为了帮助您在运行的 Slurm 节点上运行 Docker HyperPod， HyperPod 服务团队提供了安装脚本，您可以将这些脚本包含在集群创建的生命周期配置中。要了解更多信息，请参阅 [提供的基本生命周期脚本 HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) 和 [在 Slurm 计算节点上运行 Docker 容器 HyperPod](sagemaker-hyperpod-run-jobs-slurm-docker.md)。 ## 当我在平台上使用 NVIDIA 集体通信库 (NCCL) 和 Slurm 时，为什么我的并行训练任务会失败？ SageMaker HyperPod 默认情况下，Linux 操作系统会设置 `#RemoveIPC=yes` 标志。使用 NCCL 的 Slurm 和 mpirun 作业在非根用户会话下生成进程间通信（IPC）资源。这些用户会话可能会在作业进程中退出。 当您使用 Slurm 或 mpirun 运行作业时，如果 `systemd` 检测到用户未登录，它将清理 IPC 资源。Slurm 和 mpirun 作业可在用户未登录的情况下运行，但要求您在 systemd 级别禁用清理，转而在 Slurm 级别设置清理。有关更多信息，请参阅 [NCCL 文档中的 Systemd](https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/troubleshooting.html#systemd)。 要在 systemd 级别禁用清理，请完成以下步骤。 1. 如果您正在运行使用 Slurm 和 NCCL 的训练作业，请在文件 `/etc/systemd/logind.conf` 中设置标志 `#RemoveIPC=no`。 1. 默认情况下，Slurm 不会清理共享资源。我们建议您设置 Slurm epilog 脚本来清理共享资源。当您拥有大量共享资源，并且希望在训练作业完成后清理这些资源时，此清理操作很有用。以下为示例脚本。 ``` #!/bin/bash : <<'SUMMARY' Script: epilog.sh Use this script with caution, as it can potentially delete unnecessary resources and cause issues if you don't use it correctly. Note: You must save this script in a shared in a shared location that is accessible to all nodes in the cluster, such as /fsx volume. Workers must be able to access the script to run the script after jobs. SUMMARY # Define the log directory and create it if it doesn't exist LOG_DIR="//epilogue" #NOTE: Update PLACEHOLDER to be a shared value path, such as /fsx/epilogue. mkdir -p "$LOG_DIR" # Name the log file using the Slurm job name and job ID log_file="$LOG_DIR/epilogue-${SLURM_JOB_NAME}_${SLURM_JOB_ID}.log" logging() { echo "[$(date)] $1" | tee -a "$log_file" } # Slurm epilogue script to clean up IPC resources logging "Starting IPC cleanup for Job $SLURM_JOB_ID" # Clean up shared memory segments by username for seg in $(ipcs -m | awk -v owner="$SLURM_JOB_USER" '$3 == owner {print $2}'); do if ipcrm -m "$seg"; then logging "Removed shared memory segment $seg" else logging "Failed to remove shared memory segment $seg" fi done # Clean up semaphores by username for sem in $(ipcs -s | awk -v user="$SLURM_JOB_USER" '$3 == user {print $2}'); do if ipcrm -s "$sem"; then logging "Removed semaphore $sem" else logging "Failed to remove semaphore $sem" fi done # Clean up NCCL IPC NCCL_IPC_PATH="/dev/shm/nccl-*" for file in $NCCL_IPC_PATH; do if [ -e "$file" ]; then if rm "$file"; then logging "Removed NCCL IPC file $file" else logging "Failed to remove NCCL IPC file $file" fi fi done logging "IPC cleanup completed for Job $SLURM_JOB_ID" exit 0 ``` 有关 Epilog 参数的更多信息，请参阅 [Slurm 文档](https://slurm.schedmd.com/slurm.conf.html#OPT_Epilog)。 1. 在控制器节点的 `slurm.conf` 文件中，添加一行以指向所创建的 epilog 脚本。 ``` Epilog="/path/to/epilog.sh" #For example: /fsx/epilogue/epilog.sh ``` 1. 运行以下命令以更改脚本的权限并使其可执行。 ``` chown slurm:slurm /path/to/epilog.sh chmod +x /path/to/epilog.sh ``` 1. 要应用所有更改，请运行 `scontrol reconfigure`。 ## 如何使用本地 NVMe 存储的 P 实例来启动带有 Slurm 的 Docker 或 Enroot 容器？ 由于头节点的默认根卷通常受到 100GB EBS 卷的限制，因此您需要设置 Docker 和 Enroot 才能使用本地实例存储。 NVMe 要了解如何设置 NVMe 存储并使用它来启动 Docker 容器，请参阅[在 Slurm 计算节点上运行 Docker 容器 HyperPod](sagemaker-hyperpod-run-jobs-slurm-docker.md)。 ## 如何设置 EFA 安全组？ 如果要创建具有启用 EFA 的实例的 HyperPod 集群，请确保设置安全组以允许所有进出安全组本身的入站和出站流量。要了解更多信息，请参阅[《Amazon EC2 用户指南》](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-security)中的*步骤 1：准备启用 EFA 的安全组*。 ## 如何监控我的 HyperPod 群集节点？ 是否有从中导出的 CloudWatch 指标 HyperPod？ 为了获得对集群资源利用率的可观察性，我们建议您将 HyperPod 集群与 Amazon Managed Grafana 和适用于 Promethe HyperPod us 的亚马逊托管服务集成。借助各种开源 Grafana 仪表板和导出器包，您可以导出和可视化与集群资源相关的 HyperPod 指标。要详细了解如何 SageMaker HyperPod 使用亚马逊托管 Grafana 和适用于 Prometheus 的亚马逊托管服务进行设置，请参阅。[SageMaker HyperPod 集群资源监控](sagemaker-hyperpod-cluster-observability-slurm.md)请注意， SageMaker HyperPod 目前不支持向 Amaz CloudWatch on 导出系统指标。 ## 我能否向 HyperPod 群集节点添加额外的存储空间？ 集群实例的本地实例存储空间有限。 如果默认实例存储不足以满足工作负载的需要，可以为每个实例配置额外的存储。从 [2024 年 6 月 20 日发布开始，](sagemaker-hyperpod-release-notes.md#sagemaker-hyperpod-release-notes-20240620)您可以向集群中的每个实例再添加一个 Amazon Elastic Block Store (EBS) 卷。 SageMaker HyperPod 请注意，此功能不能应用于 2024 年 6 月 20 日之前创建的现有 SageMaker HyperPod集群实例组。您可以通过修补在 2024 年 6 月 20 日之前创建的现有 SageMaker HyperPod 集群并向其中添加新的实例组来利用此功能。此功能对于 2024 年 6 月 20 日之后创建的任何 SageMaker HyperPod 集群完全有效。 ## 为什么我的计算节点在重启后显示为“DOWN”或“DRAINED”？ 当使用 `sudo reboot` 而不是 Slurm 的控制接口来重启节点时，通常会发生此情况。要正确重启节点，请使用 Slurm 命令 `scontrol reboot nextstate=resume `。这可确保 Slurm 保持对节点状态的适当控制，并在重启后恢复正常运行。 对于 GPU 实例（如 NVIDIA P5），如果节点无法在 Slurm 的默认时间限制（60 秒）内完成启动过程，也会发生这种情况。要解决此问题，请将 `slurm.conf` 中的 `TimeToResume` 参数的值增至 300 秒。这将为 GPU 实例提供足够的时间来启动和初始化驱动程序。 ## 为什么我的节点总是因内存不足（OOM）问题而被置为不可用状态？ 当作业超过节点的内存容量时，就会发生 OOM 问题。为防止此类情况发生，请实施 `cgroups` 以对每个作业强制执行内存限制。这可防止单个作业影响整个节点，并提升隔离性与稳定性。 `slurm.conf` 中的设置示例： ``` TaskPlugin=task/cgroup ``` `cgroup.conf` 中的设置示例： ``` CgroupAutomount=yes ConstrainCores=yes CgroupPlugin=autodetect ConstrainDevices=yes ConstrainRAMSpace=yes ConstrainSwapSpace=yes SignalChildrenProcesses=yes MaxRAMPercent=99 MaxSwapPercent=80 MinRAMSpace=100 ``` 有关更多信息，请参阅 [Slurm 中的控制组](https://slurm.schedmd.com/cgroups.html)、[Slurm 计算节点的基于 Cgroup 和 PAM 的登录控制](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils/pam_adopt_cgroup_wheel.sh#L197)以及[为 Slurm 配置 Cgroup](https://catalog.workshops.aws/sagemaker-hyperpod/en-US/07-tips-and-tricks/16-enable-cgroups)。 ## 如何确保在作业完成后正确清理资源？ 实施 epilogue 脚本，以便在作业完成后自动清理资源。当作业意外崩溃、包含阻碍正常清理的错误或共享内存缓冲区（包括进程和 GPU 驱动程序之间共享的缓冲区）保留已分配状态时，可能无法正常清理资源。 Epilogue 脚本可以执行清除 GPU 内存、删除临时文件和卸载文件系统等任务。当资源未被专门分配给单个作业时，这些脚本会受到一些限制。有关详细说明和示例脚本，请参阅问题[当我在平台上使用 NVIDIA 集体通信库 (NCCL) 和 Slurm 时，为什么我的并行训练任务会失败？ SageMaker HyperPod](#hyperpod-faqs-q4)的第二个要点。有关更多信息，请参阅[启用 Slurm epilog 脚本](https://catalog.workshops.aws/sagemaker-hyperpod/en-US/07-tips-and-tricks/18-slurm-epilogue)。