翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# SageMaker HyperPod のよくある質問
SageMaker HyperPod の使用に関する問題のトラブルシューティングには、次のよくある質問を使用します。
**Topics**
+ [Q. Amazon CloudWatch で SageMaker HyperPod クラスターのロググループが見つからないのはなぜですか。](#hyperpod-faqs-q1)
+ [Q. HyperPod は、`slurm.conf` や `gres.conf` などの Slurm 設定ファイルでどの特定の設定を管理しますか。](#hyperpod-faqs-q2)
+ [Q. HyperPod の Slurm ノードで Docker を実行するにはどうすればよいですか。](#hyperpod-faqs-q3)
+ [SageMaker HyperPod プラットフォームで Slurm で NVIDIA Collective Communications Library (NCCL) を使用すると、並列トレーニングジョブが失敗するのはなぜですか。](#hyperpod-faqs-q4)
+ [Q. P インスタンスのローカル NVMe ストアを使用して、Slurm で Docker または Enroot コンテナを起動するにはどうすればよいですか。](#hyperpod-faqs-q5)
+ [Q. EFA セキュリティグループを設定するにはどうすればよいですか。](#hyperpod-faqs-q6)
+ [Q. HyperPod クラスターノードをモニタリングするにはどうすればよいですか。HyperPod からエクスポートされる CloudWatch メトリクスはありますか。](#hyperpod-faqs-q7)
+ [Q. HyperPod クラスターノードにさらにストレージを追加できますか。クラスターインスタンスのローカルインスタンスストアは限られています。](#hyperpod-faqs-q8)
+ [再起動後にコンピューティングノードが「DOWN」または「DRAINED」と表示されるのはなぜですか。](#hyperpod-faqs-q9)
+ [メモリ不足 (OOM) の問題が原因でノードがドレインし続けるのはなぜですか。](#hyperpod-faqs-q10)
+ [ジョブの完了後にリソースが適切にクリーンアップされるようにするにはどうすればよいですか。](#hyperpod-faqs-q11)
## Q. 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 クラスターインスタンスでは、`/opt/aws/amazon-cloudwatch-agent/sagemaker_cwagent_config.json` に JSON 形式の CloudWatch エージェント設定ファイルが含まれています。設定ファイルで、フィールド名 `logs.logs_collected.files.collect_list.file_path` を見つけます。HyperPod のデフォルト設定では、キーと値のペアは「[インスタンスレベルでの SageMaker HyperPod のログ記録](sagemaker-hyperpod-cluster-management-slurm.md#sagemaker-hyperpod-cluster-management-slurm-logging-at-instance-level)」で説明されている `"file_path": "/var/log/provision/provisioning.log"` でなければなりません。次のコードスニペットは、HyperPod のデフォルト設定で JSON ファイルがどのように表示されるかを示しています。
```
"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
```
## Q. HyperPod は、`slurm.conf` や `gres.conf` などの Slurm 設定ファイルでどの特定の設定を管理しますか。
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 クラスターの作成リクエストとライフサイクルスクリプトに基づいて Slum クラスターを管理します。次のリストは、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) 機能を有効にするには、次のように設定された `TaskPlugin` パラメータと `SchedulerParameters`パラメータが HyperPod に必要です。HyperPod エージェントは、これらの 2 つのパラメータをデフォルトで必要な値を使用して設定します。
```
TaskPlugin=task/none
SchedulerParameters=permit_job_expansion
```
+ [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html) では、HyperPod は `NodeName` GPU ノードを管理します。
## Q. 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 プラットフォームで Slurm で NVIDIA Collective Communications Library (NCCL) を使用すると、並列トレーニングジョブが失敗するのはなぜですか。
デフォルトでは、Linux OS は `#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` を実行します。
## Q. P インスタンスのローカル NVMe ストアを使用して、Slurm で Docker または Enroot コンテナを起動するにはどうすればよいですか。
ヘッドノードのデフォルトのルートボリュームは通常 100GB EBS ボリュームに制限されるため、ローカル NVMe インスタンスストアを使用するよう Docker と Enroot を設定する必要があります。NVMe ストアをセットアップし、Docker コンテナの起動に使用する方法については、「[HyperPod の Slurm コンピューティングノードでの Docker コンテナの実行](sagemaker-hyperpod-run-jobs-slurm-docker.md)」を参照してください。
## Q. EFA セキュリティグループを設定するにはどうすればよいですか。
EFA 対応インスタンスで HyperPod クラスターを作成する場合、セキュリティグループ自体との間で送受信されるすべてのトラフィックを許可するようセキュリティグループを設定してください。詳細については、「*Amazon EC2 ユーザーガイド*」の「[ステップ 1: EFA 対応のセキュリティグループを準備する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-security)」を参照してください。
## Q. 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 へのシステムメトリクスのエクスポートをサポートしていない点に注意してください。
## Q. HyperPod クラスターノードにさらにストレージを追加できますか。クラスターインスタンスのローカルインスタンスストアは限られています。
デフォルトのインスタンスストレージがワークロードに不十分な場合、インスタンスごとに追加のストレージを設定できます。[2024 年 6 月 20 日のリリース](sagemaker-hyperpod-release-notes.md#sagemaker-hyperpod-release-notes-20240620)以降、SageMaker HyperPod クラスターの各インスタンスに Amazon Elastic Block Store (EBS) ボリュームを追加できます。この機能は、2024 年 6 月 20 日より前に作成された SageMaker HyperPod クラスターの既存のインスタンスグループには適用できない点に注意してください。この機能は、2024 年 6 月 20 日より前に作成された既存の SageMaker HyperPod クラスターにパッチを適用し、新しいインスタンスグループを追加することで利用できます。この機能は、2024 年 6 月 20 日以降に作成されたすべての SageMaker HyperPod クラスターに対して完全に有効です。
## 再起動後にコンピューティングノードが「DOWN」または「DRAINED」と表示されるのはなぜですか。
これは通常、Slurm のコントロールインターフェイスの代わりに `sudo reboot` を使用してノードを再起動した場合に発生します。ノードを適切に再起動するには、`scontrol reboot nextstate=resume ` Slurm コマンドを使用します。これにより、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 の Cgroups を設定する](https://catalog.workshops.aws/sagemaker-hyperpod/en-US/07-tips-and-tricks/16-enable-cgroups)」を参照してください。
## ジョブの完了後にリソースが適切にクリーンアップされるようにするにはどうすればよいですか。
ジョブの完了後にリソースを自動的にクリーンアップする epilogue スクリプトを実装します。ジョブが予期せずクラッシュした場合、通常のクリーンアップを妨げるバグが含まれている場合、または共有メモリバッファ (プロセスと GPU ドライバー間で共有されるメモリバッファを含む) が割り当てられたままの場合、リソースが適切に削除されないことがあります。
Epilogue スクリプトは、GPU メモリの消去、一時ファイルの削除、ファイルシステムのアンマウントなどのタスクを実行できます。これらのスクリプトには、リソースが単一のジョブにのみ割り当てられない場合の制限があります。詳細な手順とサンプルスクリプトについては、質問「[SageMaker HyperPod プラットフォームで Slurm で NVIDIA Collective Communications Library (NCCL) を使用すると、並列トレーニングジョブが失敗するのはなぜですか。](#hyperpod-faqs-q4)」の 2 番目の箇条書きを参照してください。詳細については、「[Slurm epilog スクリプトを有効にする](https://catalog.workshops.aws/sagemaker-hyperpod/en-US/07-tips-and-tricks/18-slurm-epilogue)」を参照してください。