SageMaker HyperPod 常見問答集

使用下列常見問答集來疑難排解使用 SageMaker HyperPod 的問題。

問：為什麼我在 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 代理程式會在設定 slurm.conf和 gres.conf 檔案/opt/slurm/etc/，以根據您的 HyperPod 叢集建立請求和生命週期指令碼來管理 Slurm 叢集。下列清單顯示 HyperPod 代理程式處理和覆寫的特定參數。

重要

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

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

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

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

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

問：當我在 Slurm 架構的 SageMaker HyperPod 平台上使用 NVIDIA Collective Communications Library (NCCL) 時，為什麼我的平行訓練任務會失敗？

根據預設，Linux 作業系統會設定 #RemoveIPC=yes旗標。使用 NCCL 的 Slurm 和 mpirun 任務會在非根使用者工作階段下產生程序間通訊 (IPC) 資源。這些使用者工作階段可能會在任務過程中登出。

當您使用 Slurm 或 mpirun 執行任務時，如果 systemd 偵測到使用者未登入，它會清除 IPC 資源。Slurm 和 mpirun 任務可以在使用者未登入的情況下執行，但這需要您在系統層級停用清除，並改為在 Slurm 層級設定清除。如需詳細資訊，請參閱 NCCL 文件中的系統化。

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

/etc/systemd/logind.conf 如果您正在執行使用 Slurm 和 NCCL 的訓練任務，請在 #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 存放區來啟動 Docker 或 Enroot 容器搭配 Slurm？

由於頭部節點的預設根磁碟區通常受限於 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 叢集完全有效。

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

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

文件慣用形式

叢集管理

使用 Amazon EKS 協調 HyperPod 叢集