本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # SageMaker HyperPod 常見問答集 使用下列常見問答集，針對使用 SageMaker HyperPod 的問題進行疑難排解。 **Topics** + [為什麼我在 Amazon CloudWatch 中找不到 SageMaker HyperPod 叢集的日誌群組？](#hyperpod-faqs-q1) + [HyperPod 在 Slurm 組態檔案中管理哪些特定組態，例如 `slurm.conf` 和 `gres.conf`？](#hyperpod-faqs-q2) + [如何在 HyperPod 上的 Slurm 節點上執行 Docker？](#hyperpod-faqs-q3) + [為什麼我在 SageMaker HyperPod 平台上使用 NVIDIA Collective Communications Library (NCCL) 搭配 Slurm 時，我的平行訓練任務會失敗？](#hyperpod-faqs-q4) + [如何使用 P 執行個體的本機 NVMe 存放區，搭配 Slurm 啟動 Docker 或 Enroot 容器？](#hyperpod-faqs-q5) + [如何設定 EFA 安全群組？](#hyperpod-faqs-q6) + [如何監控 HyperPod 叢集節點？ 是否有任何從 HyperPod 匯出的 CloudWatch 指標？](#hyperpod-faqs-q7) + [我可以將額外的儲存體新增至 HyperPod 叢集節點嗎？ 叢集執行個體具有受限的本機執行個體儲存體。](#hyperpod-faqs-q8) + [為什麼我的運算節點在重新啟動之後顯示為 "DOWN" 或 "DRAINED"？](#hyperpod-faqs-q9) + [為什麼我的節點由於記憶體不足 (OOM) 問題而不斷耗盡？](#hyperpod-faqs-q10) + [如何確保在任務完成之後正確清除資源？](#hyperpod-faqs-q11) ## 為什麼我在 Amazon CloudWatch 中找不到 SageMaker HyperPod 叢集的日誌群組？ 根據預設，代理程式日誌和執行個體啟動日誌會傳送至 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)中所述。下列程式碼片段顯示 JSON 檔案與 HyperPod 預設組態的外觀。 ``` "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 ``` ## HyperPod 在 Slurm 組態檔案中管理哪些特定組態，例如 `slurm.conf` 和 `gres.conf`？ 當您在 HyperPod 上建立 Slurm 叢集時，HyperPod 代理程式會在 `/opt/slurm/etc/` 設定 [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html) 和 [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html) 檔案，以根據您的 HyperPod 叢集建立請求和生命週期指令碼來管理 Slurm 叢集。下列清單顯示 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 會管理 GPU 節點的 `NodeName`。 ## 如何在 HyperPod 上的 Slurm 節點上執行 Docker？ 為了協助您在 HyperPod 上執行的 Slurm 節點上執行 Docker，HyperPod 服務團隊會提供設定指令碼，您可以包含這些指令碼作為生命週期組態的一部分，以用於建立叢集。如需了解詳細資訊，請參閱 [HyperPod 提供的基本生命週期指令碼](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) 和 [在 HyperPod 的 Slurm 運算節點上執行 Docker 容器](sagemaker-hyperpod-run-jobs-slurm-docker.md)。 ## 為什麼我在 SageMaker HyperPod 平台上使用 NVIDIA Collective Communications Library (NCCL) 搭配 Slurm 時，我的平行訓練任務會失敗？ 根據預設，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`。 ## 如何使用 P 執行個體的本機 NVMe 存放區，搭配 Slurm 啟動 Docker 或 Enroot 容器？ 由於主節點的預設根磁碟區通常受到 100GB EBS 磁碟區限制，因此您需要設定 Docker 和 Enroot 以使用本機 NVMe 執行個體儲存體。若要了解如何設定 NVMe 存放區並將其用於啟動 Docker 容器，請參閱[在 HyperPod 的 Slurm 運算節點上執行 Docker 容器](sagemaker-hyperpod-run-jobs-slurm-docker.md)。 ## 如何設定 EFA 安全群組？ 如果您想要使用已啟用 EFA 的執行個體建立 HyperPod 叢集，請確定您設定安全群組，以允許所有進出安全群組本身的傳入和傳出流量。若要進一步了解，請參閱《Amazon EC2 使用者指南》**中的[步驟 1：準備已啟用 EFA 的安全群組](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-security)。 ## 如何監控 HyperPod 叢集節點？ 是否有任何從 HyperPod 匯出的 CloudWatch 指標？ 若要獲得 HyperPod 叢集資源使用率的可觀測性，建議您將 HyperPod 叢集與 Amazon Managed Grafana 和 Amazon Managed Service for Prometheus 整合。透過各種開放原始碼 Grafana 儀表板和匯出工具套件，您可以匯出和視覺化與 HyperPod 叢集資源相關的指標。若要進一步了解如何使用 Amazon Managed Grafana 和 Amazon Managed Service for Prometheus 設定 SageMaker HyperPod，請參閱 [SageMaker HyperPod 叢集資源監控](sagemaker-hyperpod-cluster-observability-slurm.md)。請注意，SageMaker HyperPod 目前不支援將系統指標匯出至 Amazon CloudWatch。 ## 我可以將額外的儲存體新增至 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 記憶體、移除暫存檔案，以及卸載檔案系統。當資源並非專門配置給單一任務時，這些指令碼會有限制。如需詳細指示和範例指令碼，請參閱問題[為什麼我在 SageMaker HyperPod 平台上使用 NVIDIA Collective Communications Library (NCCL) 搭配 Slurm 時，我的平行訓練任務會失敗？](#hyperpod-faqs-q4)的第二個項目符號點。如需詳細資訊，請參閱[啟用 Slurm epilog 指令碼](https://catalog.workshops.aws/sagemaker-hyperpod/en-US/07-tips-and-tricks/18-slurm-epilogue)。