Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# SageMaker HyperPod FAQs
Gunakan pertanyaan umum berikut untuk memecahkan masalah dengan menggunakan. SageMaker HyperPod
**Topics**
+ [Mengapa saya tidak dapat menemukan grup log SageMaker HyperPod cluster saya di Amazon CloudWatch?](#hyperpod-faqs-q1)
+ [Konfigurasi khusus apa yang HyperPod dikelola dalam file konfigurasi Slurm seperti dan? `slurm.conf` `gres.conf`](#hyperpod-faqs-q2)
+ [Bagaimana cara menjalankan Docker pada node slurm? HyperPod](#hyperpod-faqs-q3)
+ [Mengapa pekerjaan pelatihan paralel saya gagal ketika saya menggunakan NVIDIA Collective Communications Library (NCCL) dengan Slurm di platform? SageMaker HyperPod](#hyperpod-faqs-q4)
+ [Bagaimana cara menggunakan NVMe penyimpanan lokal instance P untuk meluncurkan wadah Docker atau Enroot dengan Slurm?](#hyperpod-faqs-q5)
+ [Bagaimana cara mengatur grup keamanan EFA?](#hyperpod-faqs-q6)
+ [Bagaimana cara memonitor node HyperPod cluster saya? Apakah ada CloudWatch metrik yang diekspor dari? HyperPod](#hyperpod-faqs-q7)
+ [Bisakah saya menambahkan penyimpanan tambahan ke node HyperPod cluster? Instance cluster memiliki penyimpanan instance lokal terbatas.](#hyperpod-faqs-q8)
+ [Mengapa node komputasi saya ditampilkan sebagai “DOWN” atau “DRAINED” setelah reboot?](#hyperpod-faqs-q9)
+ [Mengapa node saya terus terkuras karena masalah Out of Memory (OOM)?](#hyperpod-faqs-q10)
+ [Bagaimana saya bisa memastikan sumber daya dibersihkan dengan benar setelah pekerjaan selesai?](#hyperpod-faqs-q11)
## Mengapa saya tidak dapat menemukan grup log SageMaker HyperPod cluster saya di Amazon CloudWatch?
Secara default, log agen dan log start-up instance dikirim ke akun HyperPod platform. CloudWatch Dalam kasus skrip siklus hidup pengguna, log konfigurasi siklus hidup dikirim ke akun Anda. CloudWatch
Jika Anda menggunakan [contoh skrip siklus hidup](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) yang disediakan oleh tim HyperPod layanan, Anda dapat menemukan log konfigurasi siklus hidup yang ditulis`/var/log/provision/provisioning.log`, dan Anda tidak akan mengalami masalah ini.
Namun, jika Anda menggunakan jalur khusus untuk mengumpulkan log dari penyediaan siklus hidup dan tidak dapat menemukan grup log yang muncul di akun Anda CloudWatch, itu mungkin karena ketidakcocokan di jalur file log yang ditentukan dalam skrip siklus hidup Anda dan apa yang dicari CloudWatch agen yang berjalan pada instance cluster. HyperPod Dalam hal ini, itu berarti Anda perlu mengatur skrip siklus hidup Anda dengan benar untuk mengirim log ke CloudWatch agen, dan juga mengatur konfigurasi CloudWatch agen yang sesuai. Untuk mengatasi masalah, pilih salah satu opsi berikut.
+ **Opsi 1:** Perbarui skrip siklus hidup Anda untuk menulis log. `/var/log/provision/provisioning.log`
+ **Opsi 2:** Perbarui CloudWatch agen untuk mencari jalur kustom Anda untuk mencatat penyediaan siklus hidup.
1. Setiap instance HyperPod cluster berisi file konfigurasi CloudWatch agen dalam format JSON di`/opt/aws/amazon-cloudwatch-agent/sagemaker_cwagent_config.json`. Dalam file konfigurasi, cari nama bidang`logs.logs_collected.files.collect_list.file_path`. Dengan pengaturan default oleh HyperPod, pasangan kunci-nilai harus `"file_path": "/var/log/provision/provisioning.log"` seperti yang didokumentasikan di. [Logging SageMaker HyperPod di tingkat instans](sagemaker-hyperpod-cluster-management-slurm.md#sagemaker-hyperpod-cluster-management-slurm-logging-at-instance-level) Cuplikan kode berikut menunjukkan bagaimana file JSON terlihat dengan konfigurasi default. 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. Ganti nilai untuk nama `"file_path"` bidang dengan jalur kustom yang Anda gunakan dalam skrip siklus hidup Anda. Misalnya, jika Anda telah menyiapkan skrip siklus hidup untuk menulis`/var/log/custom-provision/custom-provisioning.log`, perbarui nilainya agar sesuai dengannya sebagai berikut.
```
"file_path": "/var/log/custom-provision/custom-provisioning.log"
```
1. Mulai ulang CloudWatch agen dengan file konfigurasi untuk menyelesaikan penerapan jalur kustom. Misalnya, CloudWatch perintah berikut menunjukkan cara me-restart CloudWatch agen dengan file konfigurasi CloudWatch agen dari langkah 1. Untuk informasi selengkapnya, lihat juga [Memecahkan masalah agen. 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
```
## Konfigurasi khusus apa yang HyperPod dikelola dalam file konfigurasi Slurm seperti dan? `slurm.conf` `gres.conf`
Saat Anda membuat klaster Slurm aktif HyperPod, HyperPod agen akan menyiapkan [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html)file [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html)dan file `/opt/slurm/etc/` untuk mengelola klaster Slurm berdasarkan permintaan pembuatan klaster dan skrip siklus HyperPod hidup Anda. Daftar berikut menunjukkan parameter spesifik apa yang ditangani dan ditimpa HyperPod agen.
**penting**
Kami sangat menyarankan agar Anda TIDAK mengubah parameter ini dikelola oleh HyperPod.
+ Dalam [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html), HyperPod mengatur parameter dasar berikut:`ClusterName`,`SlurmctldHost`,`PartitionName`, dan`NodeName`.
Juga, untuk mengaktifkan [Pemulihan simpul otomatis dan lanjutkan otomatis](sagemaker-hyperpod-resiliency-slurm-auto-resume.md) fungsionalitas, HyperPod membutuhkan `TaskPlugin` dan `SchedulerParameters` parameter yang ditetapkan sebagai berikut. HyperPod Agen mengatur dua parameter ini dengan nilai yang diperlukan secara default.
```
TaskPlugin=task/none
SchedulerParameters=permit_job_expansion
```
+ Di [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html), HyperPod mengelola `NodeName` node GPU.
## Bagaimana cara menjalankan Docker pada node slurm? HyperPod
Untuk membantu Anda menjalankan Docker pada node Slurm yang berjalan HyperPod, tim HyperPod layanan menyediakan skrip penyiapan yang dapat Anda sertakan sebagai bagian dari konfigurasi siklus hidup untuk pembuatan klaster. Untuk mempelajari selengkapnya, lihat [Skrip siklus hidup dasar yang disediakan oleh HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) dan [Menjalankan kontainer Docker pada simpul komputasi Slurm HyperPod](sagemaker-hyperpod-run-jobs-slurm-docker.md).
## Mengapa pekerjaan pelatihan paralel saya gagal ketika saya menggunakan NVIDIA Collective Communications Library (NCCL) dengan Slurm di platform? SageMaker HyperPod
Secara default, OS Linux menetapkan `#RemoveIPC=yes` bendera. Pekerjaan slurm dan mpirun yang menggunakan NCCL menghasilkan sumber daya komunikasi antar-proses (IPC) di bawah sesi pengguna non-root. Sesi pengguna ini mungkin keluar selama proses pekerjaan.
Ketika Anda menjalankan pekerjaan dengan Slurm atau mpirun, jika `systemd` mendeteksi bahwa pengguna tidak masuk, itu membersihkan sumber daya IPC. Pekerjaan slurm dan mpirun dapat berjalan tanpa pengguna masuk, tetapi itu mengharuskan Anda menonaktifkan pembersihan di tingkat systemd dan mengaturnya di tingkat Slurm sebagai gantinya. Untuk informasi selengkapnya, lihat [Systemd dalam dokumentasi NCCL](https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/troubleshooting.html#systemd).
Untuk menonaktifkan pembersihan di tingkat systemd, selesaikan langkah-langkah berikut.
1. Tetapkan bendera `#RemoveIPC=no` dalam file `/etc/systemd/logind.conf` jika Anda menjalankan pekerjaan pelatihan yang menggunakan Slurm dan NCCL.
1. Secara default, Slurm tidak membersihkan sumber daya bersama. Kami menyarankan Anda menyiapkan skrip epilog Slurm untuk membersihkan sumber daya bersama. Pembersihan ini berguna ketika Anda memiliki banyak sumber daya bersama dan ingin membersihkannya setelah pekerjaan pelatihan. Berikut adalah contoh skrip.
```
#!/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
```
Untuk informasi selengkapnya tentang parameter Epilog, lihat dokumentasi [Slurm](https://slurm.schedmd.com/slurm.conf.html#OPT_Epilog).
1. Dalam `slurm.conf` file dari node controller, tambahkan baris untuk menunjuk ke skrip epilog yang Anda buat.
```
Epilog="/path/to/epilog.sh" #For example: /fsx/epilogue/epilog.sh
```
1. Jalankan perintah berikut untuk mengubah izin skrip dan membuatnya dapat dieksekusi.
```
chown slurm:slurm /path/to/epilog.sh
chmod +x /path/to/epilog.sh
```
1. Untuk menerapkan semua perubahan Anda, jalankan`scontrol reconfigure`.
## Bagaimana cara menggunakan NVMe penyimpanan lokal instance P untuk meluncurkan wadah Docker atau Enroot dengan Slurm?
Karena volume root default node head Anda biasanya dibatasi oleh volume EBS 100GB, Anda perlu mengatur Docker dan Enroot untuk menggunakan penyimpanan instance lokal. NVMe Untuk mempelajari cara menyiapkan NVMe toko dan menggunakannya untuk meluncurkan kontainer Docker, lihat[Menjalankan kontainer Docker pada simpul komputasi Slurm HyperPod](sagemaker-hyperpod-run-jobs-slurm-docker.md).
## Bagaimana cara mengatur grup keamanan EFA?
Jika Anda ingin membuat HyperPod klaster dengan instans yang mendukung EFA, pastikan Anda menyiapkan grup keamanan untuk mengizinkan semua lalu lintas masuk dan keluar ke dan dari grup keamanan itu sendiri. Untuk mempelajari selengkapnya, lihat [Langkah 1: Menyiapkan grup keamanan berkemampuan EFA](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-security) di Panduan Pengguna *Amazon EC2*.
## Bagaimana cara memonitor node HyperPod cluster saya? Apakah ada CloudWatch metrik yang diekspor dari? HyperPod
Untuk mendapatkan observabilitas dalam pemanfaatan sumber daya klaster Anda, sebaiknya Anda mengintegrasikan HyperPod klaster dengan Grafana Terkelola Amazon dan Layanan Terkelola Amazon untuk HyperPod Prometheus. Dengan berbagai dasbor Grafana sumber terbuka dan paket eksportir, Anda dapat mengekspor dan memvisualisasikan metrik yang terkait dengan sumber daya cluster. HyperPod Untuk mempelajari lebih lanjut tentang pengaturan SageMaker HyperPod dengan Grafana Terkelola Amazon dan Layanan Terkelola Amazon untuk Prometheus, lihat. [SageMaker HyperPod pemantauan sumber daya cluster](sagemaker-hyperpod-cluster-observability-slurm.md) Perhatikan bahwa SageMaker HyperPod saat ini tidak mendukung ekspor metrik sistem ke Amazon. CloudWatch
## Bisakah saya menambahkan penyimpanan tambahan ke node HyperPod cluster? Instance cluster memiliki penyimpanan instance lokal terbatas.
Jika penyimpanan instans default tidak mencukupi untuk beban kerja Anda, Anda dapat mengonfigurasi penyimpanan tambahan per instans. Mulai dari [rilis pada 20 Juni 2024,](sagemaker-hyperpod-release-notes.md#sagemaker-hyperpod-release-notes-20240620) Anda dapat menambahkan volume Amazon Elastic Block Store (EBS) tambahan ke setiap instans di cluster Anda. SageMaker HyperPod Perhatikan bahwa kemampuan ini tidak dapat diterapkan ke grup instans SageMaker HyperPod cluster yang ada yang dibuat sebelum 20 Juni 2024. Anda dapat memanfaatkan kemampuan ini dengan menambal SageMaker HyperPod cluster yang ada yang dibuat sebelum 20 Juni 2024 dan menambahkan grup instans baru ke dalamnya. Kemampuan ini sepenuhnya efektif untuk setiap SageMaker HyperPod cluster yang dibuat setelah 20 Juni 2024.
## Mengapa node komputasi saya ditampilkan sebagai “DOWN” atau “DRAINED” setelah reboot?
Ini biasanya terjadi ketika node di-boot ulang menggunakan `sudo reboot` alih-alih antarmuka kontrol Slurm. Untuk me-reboot node dengan benar, gunakan perintah Slurm. `scontrol reboot nextstate=resume ` Ini memastikan Slurm mempertahankan kontrol yang tepat dari keadaan node dan melanjutkan operasi normal setelah reboot.
Untuk instance GPU (seperti NVIDIA P5), ini juga dapat terjadi jika node tidak dapat menyelesaikan proses booting dalam batas waktu default Slurm (60 detik). Untuk mengatasi ini, tingkatkan `TimeToResume` parameter `slurm.conf` menjadi 300 detik. Ini memberi instance GPU waktu yang cukup untuk boot dan menginisialisasi driver.
## Mengapa node saya terus terkuras karena masalah Out of Memory (OOM)?
Masalah OOM terjadi ketika pekerjaan melebihi kapasitas memori node. Untuk mencegah hal ini, terapkan `cgroups` untuk menegakkan batas memori per pekerjaan. Ini mencegah satu pekerjaan mempengaruhi seluruh node dan meningkatkan isolasi dan stabilitas.
Contoh pengaturan di`slurm.conf`:
```
TaskPlugin=task/cgroup
```
Contoh pengaturan di`cgroup.conf`:
```
CgroupAutomount=yes
ConstrainCores=yes
CgroupPlugin=autodetect
ConstrainDevices=yes
ConstrainRAMSpace=yes
ConstrainSwapSpace=yes
SignalChildrenProcesses=yes
MaxRAMPercent=99
MaxSwapPercent=80
MinRAMSpace=100
```
[Untuk informasi selengkapnya, lihat [Control Group di Slurm](https://slurm.schedmd.com/cgroups.html), [Cgroup dan kontrol login berbasis PAM untuk node komputasi Slurm, dan Configure Cgroups for Slurm](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).](https://catalog.workshops.aws/sagemaker-hyperpod/en-US/07-tips-and-tricks/16-enable-cgroups)
## Bagaimana saya bisa memastikan sumber daya dibersihkan dengan benar setelah pekerjaan selesai?
Terapkan skrip epilog untuk membersihkan sumber daya secara otomatis setelah pekerjaan selesai. Sumber daya mungkin tidak dihapus dengan benar ketika pekerjaan mogok secara tak terduga, berisi bug yang mencegah pembersihan normal, atau ketika buffer memori bersama (termasuk yang dibagi antara proses dan driver GPU) tetap dialokasikan.
Skrip epilog dapat melakukan tugas-tugas seperti membersihkan memori GPU, menghapus file sementara, dan melepas sistem file. Skrip ini memiliki batasan ketika sumber daya tidak secara eksklusif dialokasikan untuk satu pekerjaan. Untuk instruksi terperinci dan contoh skrip, lihat bullet point kedua dari pertanyaan. [Mengapa pekerjaan pelatihan paralel saya gagal ketika saya menggunakan NVIDIA Collective Communications Library (NCCL) dengan Slurm di platform? SageMaker HyperPod](#hyperpod-faqs-q4) Untuk informasi selengkapnya, lihat [Aktifkan skrip epilog Slurm](https://catalog.workshops.aws/sagemaker-hyperpod/en-US/07-tips-and-tricks/18-slurm-epilogue).