本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # SageMaker HyperPod 集群弹性 SageMaker HyperPod 通过 Slurm 编排提供以下集群弹性功能。 **Topics** + [Health 监控代理](sagemaker-hyperpod-resiliency-slurm-cluster-health-check.md) + [自动节点恢复和自动恢复](sagemaker-hyperpod-resiliency-slurm-auto-resume.md) + [使用 Slurm 手动替换或重启节点](sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance.md) # Health 监控代理 本节介绍了一组运行状况检查， SageMaker HyperPod 用于定期监控集群实例的运行状况，以防加速器（GPU 和 Trainium 内核）和网络 (EFA) 等设备出现问题。 SageMaker HyperPod 运行状况监控代理 (HMA) 持续监控每个基于 GPU 或 Trainium 的实例的运行状况。当检测到任何实例或 GPU 故障时，座席会将实例标记为运行状况不佳。 SageMaker HyperPod HMA 对 EKS 和 Slurm 协调器执行相同的运行状况检查。有关 HMA 的更多信息，请参阅[Health 监控系统](sagemaker-hyperpod-eks-resiliency-health-monitoring-agent.md)。 # 自动节点恢复和自动恢复 **注意** 截至2025年9月11日，Slurm编排现在支持健康监测代理。 HyperPod 要使用此功能，请运行[UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html)并更新到最新版本的 AMI。 本节讨论 Amazon SageMaker HyperPod 的两个互补弹性功能：无需人工干预即可替换故障基础设施的自动节点恢复，以及硬件故障后从最后一个检查点重新启动训练作业的自动恢复功能。 ## 自动节点恢复的工作原理 在集群创建或更新期间，集群管理员用户可在集群级别的 `Automatic`（推荐）和 `None` 之间选择节点（实例）恢复选项。如果设置为`Automatic`，则 SageMaker HyperPod 自动重启或更换故障节点。 **重要** 我们建议设置 `Automatic` 选项。默认情况下，群集设置为自动节点恢复。 当从运行状况监控座席、基本运行状况检查和深度运行状况检查中发现问题时，自动运行节点恢复。如果设置为 `None`，运行状况监控座席将在检测到故障时对实例进行标记，但不会在受影响的节点上自动启动任何修复或恢复操作。我们不建议使用此选项。 ## 使用 Amazon SageMaker HyperPod 自动恢复功能运行训练作业 本节介绍如何使用 SageMaker HyperPod 自动恢复功能运行训练作业，该功能提供了零接触弹性基础架构，可在硬件出现故障时自动从上次保存的检查点恢复训练作业。 借助自动恢复功能，如果作业由于硬件故障或训练间隔期间的任何暂时问题而失败，则 SageMaker HyperPod 自动恢复将启动节点替换工作流程，并在更换故障节点后重新启动作业。使用自动恢复时，每当作业失败时，都会运行以下硬件检查： | 类别 | 实用程序名称 | 实例类型兼容性 | 说明 | | --- | --- | --- | --- | | Accelerator | NVIDIA SMI | GPU | [nvidia-smi](https://developer.nvidia.com/nvidia-system-management-interface) 实用程序是一个众所周知的用于管理和监控的 CLI。 GPUs内置运行状况检查程序会解析 nvidia-smi 的输出，以确定实例的运行状况。 | | Accelerator | Neuron sysfs | Trainium | 对于 Trainium-powered 实例，Neuron 设备的运行状况由 Neuron 驱动程序直接从 [Neuron sysfs](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/tools/neuron-sys-tools/neuron-sysfs-user-guide.html) 中读取计数器来确定。 | | Network | EFA | GPU 和 Trainium | 为帮助诊断弹性 Fabric 适配器 (EFA) 设备，EFA 运行状况检查程序会使用实例中所有可用的 EFA 卡运行一系列连接性测试。 | **注意** 当[通用资源（GRES）](https://slurm.schedmd.com/gres.html)连接到 Slurm 节点时，Slurm 通常不允许更改节点分配，如更换节点，因此无法恢复失败的作业。除非明确禁止，否则 HyperPod自动恢复功能会自动将任何与启用 GRES 的节点关联的错误作业重新排队。这个过程包括停止作业，将其放回作业队列，然后从头开始重新启动作业。 **在 Slur SageMaker HyperPod m 中使用自动恢复功能** 当你在 Slurm 中使用 SageMaker HyperPod 自动恢复时，你应该在通过使用或获得的独占分配中运行作业。`salloc` `sbatch`无论如何，您都需要修改入口点脚本，以确保在恢复任务时，所有设置步骤都在一条 `srun` 命令中运行。通过入口点脚本，必须将被替换节点上的环境设置为与作业步骤停止前的运行环境一致。以下过程说明如何准备入口点脚本以保持环境一致并将其作为单个`srun`命令运行。 **提示** 如果您使用 `sbatch`，则可以创建一个单独的脚本来设置环境，并使用单一的 `srun` 命令，从而使批处理脚本保持简洁。 1. 使用以下代码示例创建脚本，并将其保存为 `train_auto_resume.sh`。该脚本会部署训练环境设置，前提是之前没有对被替换节点进行手动配置。这样就能确保环境与节点无关，这样当节点被替换时，就能在节点上配置相同的环境，然后再恢复作业。 **注意** 下面的代码示例显示了如何发现与作业相关的 Slurm 节点列表。请勿使用 Slurm 提供的`$SLURM_JOB_NODELIST`环境变量，因为在 SageMaker HyperPod 自动恢复作业后，其值可能会过时。下面的代码示例展示了如何定义一个新的 `NODE_LIST` 变量来替代 `SLURM_JOB_NODELIST`，然后根据 `MASTER_NODE` 变量设置 `MASTER_ADDR` 和 `NODE_LIST` 变量。 ``` #!/bin/bash # Filename: train_auto_resume.sh # Sample containerized script to launch a training job with a single srun which can be auto-resumed. # Place your training environment setup here. # Example: Install conda, docker, activate virtual env, etc. # Get the list of nodes for a given job NODE_LIST=$(scontrol show jobid=$SLURM_JOBID | \ # Show details of the SLURM job awk -F= '/NodeList=/{print $2}' | \ # Extract NodeList field grep -v Exc) # Exclude nodes marked as excluded # Determine the master node from the node list MASTER_NODE=$(scontrol show hostname $NODE_LIST | \ # Convert node list to hostnames head -n 1) # Select the first hostname as master node # Get the master node address MASTER_ADDR=$(scontrol show node=$MASTER_NODE | \ # Show node information awk -F= '/NodeAddr=/{print $2}' | \ # Extract NodeAddr awk '{print $1}') # Print the first part of NodeAddr # Torchrun command to launch the training job torchrun_cmd="torchrun --nnodes=$SLURM_NNODES \ --nproc_per_node=1 \ --node_rank=$SLURM_NODE \ --master-addr=$MASTER_ADDR \ --master_port=1234 \ " # Execute the torchrun command in the 'pytorch' Conda environment, # streaming output live /opt/conda/bin/conda run --live-stream -n pytorch $torchrun_cmd ``` **提示** 您可以使用前面的脚本添加更多命令，以便为作业安装其他依赖关系。不过，我们建议您将依赖关系安装脚本保留在创建集群时使用的[生命周期脚本集](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md)中。如果您使用托管在共享目录下的虚拟环境，也可以使用此脚本激活虚拟环境。 1. 在启用 SageMaker HyperPod 自动恢复的情况下启动作业，方法是添加标志，`--auto-resume=1`以指示在出现硬件故障时应自动重试该`srun`命令。 **注意** 如果您使用 `sbatch` 或 `salloc` 设置了资源分配，则可以在分配中运行多个 `srun` 命令。如果出现故障， SageMaker HyperPod自动恢复功能仅在带有标志`--auto-resume=1`的`srun`命令的当前[作业步骤](https://slurm.schedmd.com/job_launch.html#step_allocation)中运行。换句话说，在 `srun` 命令中激活自动恢复功能并不适用于在资源分配会话中启动的其他 `srun` 命令。 以下是启用 `auto-resume` 后的 `srun` 命令示例。 **使用 sbatch** 由于设置环境的大部分逻辑已经在 `train_auto_resume.sh` 中，因此批脚本应该很简单，与下面的代码示例类似。假设以下批脚本保存为 `batch.sh`。 ``` #!/bin/bash #SBATCH --nodes 2 #SBATCH --exclusive srun --auto-resume=1 train_auto_resume.sh ``` 使用以下命令运行前面的批脚本。 ``` sbatch batch.sh ``` **使用 salloc** 首先获取独占分配，然后使用 `--auto-resume` 标志和入口点脚本运行 `srun` 命令。 ``` salloc -N 2 --exclusive srun --auto-resume=1 train_auto_resume.sh ``` ## 自动节点恢复和自动恢复是如何协同工作的 当自动节点恢复和自动恢复系统都处于活动状态时，它们会遵循协调的方法来处理故障。如果 HMA 检测到硬件故障，则无论作业级别的状态如何，该节点都会被标记为已耗尽。启用节点自动恢复后，一旦节点中运行的所有作业退出，就会自动替换节点。在这种情况下，对于启用了自动恢复的作业，如果步骤中的退出状态为非零，则自动恢复将启动（替换节点后作业就会恢复）。未启用自动恢复功能的作业将直接退出，需要管理员或用户手动重新提交。 **注意** 如果使用自动恢复，则在检测到硬件故障时将始终替换节点（不重新启动）。 # 使用 Slurm 手动替换或重启节点 本节讨论何时应手动重启或更换节点，并说明如何同时执行这两项操作。 ## 何时手动重启或更换节点 HyperPod 自动恢复功能会监控 Slurm 节点的状态是否变为或。`fail` `down`运行 `sinfo` 可检查 Slurm 节点的状态。 如果节点仍然停滞或无响应，并且自动恢复过程无法将其恢复，则可以手动启动恢复。在重启和更换节点之间做出选择取决于问题的性质。遇到临时问题或与软件相关的问题（例如系统挂起、内存泄漏、GPU 驱动程序问题、内核更新或进程挂起）时，可以考虑重新启动。但是，如果您遇到持续存在的问题或与硬件相关的问题，例如故障 GPUs、内存或网络故障、反复出现的运行状况检查失败，或者节点在多次重启尝试后仍然没有响应，则更换节点是更合适的解决方案。 ## 手动重启或替换节点的方法 SageMaker HyperPod 提供了两种手动恢复节点的方法。首选方法是使用 R SageMaker HyperPod eboot and Replace APIs，它提供了更快、更透明的恢复流程，适用于所有协调器。或者，你可以使用传统的 Slurm 命令`scontrol update`，比如，尽管这种传统方法需要直接访问 Slurm 的控制器节点。这两种方法都激活相同的 SageMaker HyperPod 恢复过程。 ## 使用重启 API 手动重启节点 您可以使用手动重启 SageMaker HyperPod 集群中出现故障的节点。**BatchRebootClusterNodes** 以下是使用以下方法在两个集群实例上运行重启操作的示例 AWS Command Line Interface： ``` aws sagemaker batch-reboot-cluster-nodes \ --cluster-name arn:aws:sagemaker:ap-northeast-1:123456789:cluster/test-cluster \ --node-ids i-0123456789abcdef0 i-0fedcba9876543210 ``` ## 使用替换 API 手动替换节点 您可以使用手动替换 SageMaker HyperPod 集群中出现故障的节点。**BatchReplaceClusterNodes** 以下是使用以下方法对集群的两个实例运行替换操作的示例 AWS Command Line Interface： ``` aws sagemaker batch-replace-cluster-nodes \ --cluster-name arn:aws:sagemaker:ap-northeast-1:123456789:cluster/test-cluster \ --node-ids i-0123456789abcdef0 i-0fedcba9876543210 ``` ## 使用 Slurm 手动重启节点 你也可以使用 scontrol Slurm 命令来触发节点恢复。这些命令直接与 Slurm 控制平面交互并调用相同的底层 SageMaker HyperPod 恢复机制。 在以下命令中，替换为要重启的故障实例的 Slurm 节点名称（主机名）。 ``` scontrol update node= state=fail reason="Action:Reboot" ``` 这会将该节点标记为失败，原因是指定的。 SageMaker HyperPod 检测到这一点并重启实例。避免在操作期间更改节点状态或重新启动 Slurm 控制器。 ## 使用 Slurm 手动替换节点 您可以按如下方式使用 scontrol 更新命令来替换节点。 在以下命令中，``替换为要替换的故障实例的 Slurm 节点名称（主机名）。 ``` scontrol update node= state=fail reason="Action:Replace" ``` 运行此命令后，节点将进入`fail`状态，等待当前正在运行的作业完成，替换为运行正常的实例，然后使用相同的主机名进行恢复。这一过程所需的时间取决于可用性区域中的可用实例以及运行生命周期脚本所需的时间。在更新和替换过程中，避免再次手动更改节点状态或重启 Slurm 控制器；否则会导致替换失败。如果节点长时间无法恢复或转为 `idle` 状态，请联系 [AWS 支持](https://console.aws.amazon.com/support/)。 ## 手动强制更改节点 如果故障节点持续停留在 `fail` 状态，最后的办法就是手动强制将节点状态更改为 `down`。这需要管理员权限（sudo 权限）。 **警告** 在运行以下命令之前请谨慎操作，因为它会强制终止所有作业，您可能会丢失所有未保存的工作。 ``` scontrol update node= state=down reason="Action:Replace" ```