本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # SageMaker HyperPod 叢集彈性 透過 Slurm 協同運作的 SageMaker HyperPod 提供下列叢集彈性功能。 **Topics** + [運作狀態監控代理程式](sagemaker-hyperpod-resiliency-slurm-cluster-health-check.md) + [自動節點復原和自動恢復](sagemaker-hyperpod-resiliency-slurm-auto-resume.md) + [使用 Slurm 手動取代或重新啟動節點](sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance.md) # 運作狀態監控代理程式 本節描述 SageMaker HyperPod 用來定期監控叢集執行個體運作狀態的一組運作狀態檢查，以找出加速器 (GPU 和 Trainium 核心) 和聯網 (EFA) 等裝置的問題。SageMaker HyperPod 運作狀態監控代理程式 (HMA) 會持續監控每個 GPU 型或 Trainium 型執行個體的運作狀態。當它偵測到任何執行個體或 GPU 失敗時，代理程式會將執行個體標示為運作狀態不佳。 SageMaker HyperPod HMA 會對 EKS 和 Slurm 協調器執行相同的運作狀態檢查。如需 HMA 的詳細資訊，請參閱 [運作狀態監控系統](sagemaker-hyperpod-eks-resiliency-health-monitoring-agent.md)。 # 自動節點復原和自動恢復 **注意** 截至 2025 年 9 月 11 日，HyperPod 搭配 Slurm 協同運作現在支援運作狀態監控代理程式。執行 [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 會自動繼續啟動節點取代工作流程，並在取代故障節點之後重新啟動任務。使用自動恢復時，每當任務失敗時，就會執行下列硬體檢查： | Category | 公用程式名稱 | 執行個體類型相容性 | Description | | --- | --- | --- | --- | | 加速器 | NVIDIA SMI | GPU | [nvidia-smi](https://developer.nvidia.com/nvidia-system-management-interface) 公用程式是管理和監控 GPU 的知名 CLI。內建的運作狀態檢查程式會剖析來自 nvidia-smi 的輸出，以判斷執行個體的運作狀態。 | | 加速器 | Neuron sysfs | Trainium | 對於採用 Trainium 技術的執行個體，Neuron 裝置的運作狀態取決於從 [Neuron sysfs](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/tools/neuron-sys-tools/neuron-sysfs-user-guide.html)讀取由 Neuron 驅動程式直接傳播的計數器。 | | 網路 | EFA | GPU 和 Trainium | 為了協助診斷 Elastic Fabric Adaptor (EFA) 裝置，EFA 運作狀態檢查程式會使用執行個體內所有可用的 EFA 卡執行一系列連線測試。 | **注意** 當[一般資源 (GRES)](https://slurm.schedmd.com/gres.html) 連接到 Slurm 節點時，Slurm 通常不允許節點配置的變更，例如取代節點，因此不允許繼續失敗的任務。除非明確禁止，否則 HyperPod 自動繼續功能會自動將與啟用 GRES 的節點相關聯的任何錯誤任務重新排入佇列。此程序涉及停止任務、將其放回任務佇列，然後從頭重新啟動任務。 **搭配 Slurm 使用 SageMaker HyperPod 自動繼續功能** 當您搭配 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`，然後從 `NODE_LIST` 變數設定 `MASTER_NODE` 和 `MASTER_ADDR` 變數。 ``` #!/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. 透過新增旗標 `--auto-resume=1` 啟動已啟用 SageMaker HyperPod 自動繼續的任務，以指示應在硬體故障時自動重試 `srun` 命令。 **注意** 如果您已使用 `sbatch` 或 `salloc` 設定資源配置，則可以在配置內執行多個 `srun` 命令。發生故障時，SageMaker HyperPod 自動繼續功能只會在 `srun` 命令的目前[任務步驟](https://slurm.schedmd.com/job_launch.html#step_allocation)中操作，旗標為 `--auto-resume=1`。換句話說，在 `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 提供兩種手動節點復原的方法。偏好的方法是使用 SageMaker HyperPod 重新啟動和取代 APIs，它提供更快速、更透明的復原程序，適用於所有協調器。或者，您可以使用傳統的 Slurm 命令，例如 `scontrol update`，雖然此舊版方法需要直接存取 Slurm 的控制器節點。這兩種方法都會啟用相同的 SageMaker HyperPod 復原程序。 ## 使用重新啟動 API 手動重新啟動節點 您可以使用 **BatchRebootClusterNodes** 手動重新啟動 SageMaker HyperPod 叢集中的故障節點。 以下是使用 在叢集的兩個執行個體上執行重新啟動操作的範例 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 手動取代節點 您可以使用 **BatchReplaceClusterNodes** 手動取代 SageMaker HyperPod 叢集中的故障節點。 以下是使用 在叢集的兩個執行個體上執行取代操作的範例 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 Support](https://console.aws.amazon.com/support/)。 ## 手動強制變更節點 如果故障節點持續卡在 `fail` 狀態，您可以嘗試的最後手段是手動強制將節點狀態變更為 `down`。這需要管理員權限 (sudo 許可)。 **警告** 在執行下列命令之前，請謹慎進行，因為它會強制刪除所有任務，而且您可能會失去所有未儲存的工作。 ``` scontrol update node= state=down reason="Action:Replace" ```