為什麼我在 Amazon CloudWatch 中找不到 SageMaker HyperPod 叢集的日誌群組？HyperPod 在 Slurm 組態檔案中管理哪些特定組態，例如 slurm.conf 和 gres.conf？如何在 HyperPod 上的 Slurm 節點上執行 Docker？為什麼我在 SageMaker HyperPod 平台上使用 NVIDIA Collective Communications Library (NCCL) 搭配 Slurm 時，我的平行訓練任務會失敗？如何使用 P 執行個體的本機 NVMe 存放區，搭配 Slurm 啟動 Docker 或 Enroot 容器？如何設定 EFA 安全群組？如何監控 HyperPod 叢集節點？是否有任何從 HyperPod 匯出的 CloudWatch 指標？我可以將額外的儲存體新增至 HyperPod 叢集節點嗎？叢集執行個體具有受限的本機執行個體儲存體。為什麼我的運算節點在重新啟動之後顯示為 "DOWN" 或 "DRAINED"？為什麼我的節點由於記憶體不足 (OOM) 問題而不斷耗盡？如何確保在任務完成之後正確清除資源？

SageMaker HyperPod 常見問答集

使用下列常見問答集，針對使用 SageMaker HyperPod 的問題進行疑難排解。

Amazon SageMaker HyperPod 常見問答集

為什麼我在 Amazon CloudWatch 中找不到 SageMaker HyperPod 叢集的日誌群組？
HyperPod 在 Slurm 組態檔案中管理哪些特定組態，例如 slurm.conf 和 gres.conf？
如何在 HyperPod 上的 Slurm 節點上執行 Docker？
為什麼我在 SageMaker HyperPod 平台上使用 NVIDIA Collective Communications Library (NCCL) 搭配 Slurm 時，我的平行訓練任務會失敗？
如何使用 P 執行個體的本機 NVMe 存放區，搭配 Slurm 啟動 Docker 或 Enroot 容器？
如何設定 EFA 安全群組？
如何監控 HyperPod 叢集節點？是否有任何從 HyperPod 匯出的 CloudWatch 指標？
我可以將額外的儲存體新增至 HyperPod 叢集節點嗎？叢集執行個體具有受限的本機執行個體儲存體。
為什麼我的運算節點在重新啟動之後顯示為 "DOWN" 或 "DRAINED"？
為什麼我的節點由於記憶體不足 (OOM) 問題而不斷耗盡？
如何確保在任務完成之後正確清除資源？

為什麼我在 Amazon CloudWatch 中找不到 SageMaker HyperPod 叢集的日誌群組？

根據預設，代理程式日誌和執行個體啟動日誌會傳送至 HyperPod 平台帳戶的 CloudWatch。若是使用者生命週期指令碼，生命週期組態日誌會傳送至您帳戶的 CloudWatch。

如果您使用 HyperPod 服務團隊提供的範例生命週期指令碼，您可以預期找到寫入 /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中所述。下列程式碼片段顯示 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
}
```
2. 將 "file_path" 欄位名稱的值取代為您在生命週期指令碼中使用的自訂路徑。例如，如果您已設定生命週期指令碼來寫入 /var/log/custom-provision/custom-provisioning.log，請更新值以與其相符，如下所示。
```
"file_path": "/var/log/custom-provision/custom-provisioning.log"
```
3. 使用組態檔案重新啟動 CloudWatch 代理程式，以完成套用自訂路徑。例如，下列 CloudWatch 命令顯示如何使用步驟 1 中的 CloudWatch 代理程式組態檔案重新啟動 CloudWatch 代理程式。如需詳細資訊，另請參閱針對 CloudWatch 代理程式進行疑難排解。
```
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/ 設定 slurm.conf 和 gres.conf 檔案，以根據您的 HyperPod 叢集建立請求和生命週期指令碼來管理 Slurm 叢集。下列清單顯示 HyperPod 代理程式處理和覆寫哪些特定參數。

重要

強烈建議您不要變更這些由 HyperPod 管理的參數。

在 slurm.conf 中，HyperPod 會設定下列基本參數：ClusterName、SlurmctldHost、PartitionName 和 NodeName。

此外，為了啟用自動節點復原和自動恢復功能，HyperPod 需要 TaskPlugin 和 SchedulerParameters 參數設定如下。HyperPod 代理程式預設會使用必要值來設定這兩個參數。
```
TaskPlugin=task/none
SchedulerParameters=permit_job_expansion
```
在 gres.conf 中，HyperPod 會管理 GPU 節點的 NodeName。

如何在 HyperPod 上的 Slurm 節點上執行 Docker？

為了協助您在 HyperPod 上執行的 Slurm 節點上執行 Docker，HyperPod 服務團隊會提供設定指令碼，您可以包含這些指令碼作為生命週期組態的一部分，以用於建立叢集。如需了解詳細資訊，請參閱 HyperPod 提供的基本生命週期指令碼和在 HyperPod 的 Slurm 運算節點上執行 Docker 容器。

為什麼我在 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。

若要在 systemd 層級停用清除，請完成下列步驟。

如果您正在執行使用 Slurm 和 NCCL 的訓練任務，請在檔案 /etc/systemd/logind.conf 中設定 #RemoveIPC=no 旗標。

根據預設，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="/<PLACEHOLDER>/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 文件。

在來自控制器節點的 slurm.conf 檔案中，新增一行以指向您建立的 epilog 指令碼。
```
Epilog="/path/to/epilog.sh"  #For example: /fsx/epilogue/epilog.sh
```
執行下列命令來變更指令碼的許可，並使其可執行。
```
chown slurm:slurm /path/to/epilog.sh
chmod +x  /path/to/epilog.sh
```
若要套用您的所有變更，請執行 scontrol reconfigure。

如何使用 P 執行個體的本機 NVMe 存放區，搭配 Slurm 啟動 Docker 或 Enroot 容器？

由於主節點的預設根磁碟區通常受到 100GB EBS 磁碟區限制，因此您需要設定 Docker 和 Enroot 以使用本機 NVMe 執行個體儲存體。若要了解如何設定 NVMe 存放區並將其用於啟動 Docker 容器，請參閱在 HyperPod 的 Slurm 運算節點上執行 Docker 容器。

如何設定 EFA 安全群組？

如果您想要使用已啟用 EFA 的執行個體建立 HyperPod 叢集，請確定您設定安全群組，以允許所有進出安全群組本身的傳入和傳出流量。若要進一步了解，請參閱《Amazon EC2 使用者指南》中的步驟 1：準備已啟用 EFA 的安全群組。

如何監控 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 目前不支援將系統指標匯出至 Amazon CloudWatch。

我可以將額外的儲存體新增至 HyperPod 叢集節點嗎？叢集執行個體具有受限的本機執行個體儲存體。

如果預設執行個體儲存體不夠您的工作負載使用，您可以為每個執行個體設定額外的儲存體。從 2024 年 6 月 20 日發行開始，您可以將額外的 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 <list_of_nodes>。這可確保 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 中的控制群組、Slurm 運算節點的 Cgroup 和 PAM 型登入控制，以及設定 Slurm 的 Cgroup。

如何確保在任務完成之後正確清除資源？

實作 epilogue 指令碼，以在任務完成之後自動清除資源。在任務意外毀損、包含防止正常清除的錯誤時，或在共用記憶體緩衝區 (包括程序與 GPU 驅動程式之間共用的緩衝區) 保留配置時，可能無法正確清除資源。

Epilogue 指令碼可以執行任務，例如清除 GPU 記憶體、移除暫存檔案，以及卸載檔案系統。當資源並非專門配置給單一任務時，這些指令碼會有限制。如需詳細指示和範例指令碼，請參閱問題為什麼我在 SageMaker HyperPod 平台上使用 NVIDIA Collective Communications Library (NCCL) 搭配 Slurm 時，我的平行訓練任務會失敗？的第二個項目符號點。如需詳細資訊，請參閱啟用 Slurm epilog 指令碼。

您的瀏覽器已停用或無法使用 Javascript。

您必須啟用 Javascript，才能使用 AWS 文件。請參閱您的瀏覽器說明頁以取得說明。

文件慣用形式

叢集管理

Amazon EKS 協同運作