Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Gunakan pertanyaan umum berikut untuk memecahkan masalah dengan menggunakan. SageMaker HyperPod
T. Mengapa saya tidak dapat menemukan grup log SageMaker HyperPod klaster 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 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.
-
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 bidanglogs.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 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 } -
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" -
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
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
-
T. Konfigurasi tertentu 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 gres.confslurm.conf/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
slurm.conf, HyperPod mengatur parameter dasar berikut: ClusterName,SlurmctldHost,PartitionName, danNodeName.Juga, untuk mengaktifkan Lanjutkan otomatis fungsionalitas, HyperPod membutuhkan
TaskPlugindanSchedulerParametersparameter yang ditetapkan sebagai berikut. HyperPod Agen mengatur dua parameter ini dengan nilai yang diperlukan secara default.TaskPlugin=task/none SchedulerParameters=permit_job_expansion -
Di
gres.conf, HyperPod mengelola NodeNamenode GPU.
T. 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 Mulailah dengan skrip siklus hidup dasar yang disediakan oleh HyperPod dan Jalankan kontainer Docker pada node komputasi Slurm HyperPod.
T. Mengapa pekerjaan parallel training saya gagal ketika saya menggunakan NVIDIA Collective Communications Library (NCCL) pada SageMaker HyperPod platform pada framework Slurm?
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
Untuk menonaktifkan pembersihan di tingkat systemd, selesaikan langkah-langkah berikut.
-
Tetapkan bendera
#RemoveIPC=nodalam file/etc/systemd/logind.confjika Anda menjalankan pekerjaan pelatihan yang menggunakan Slurm dan NCCL. -
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="/<PLACEHOLDER>/epilogue" #NOTE: UpdatePLACEHOLDERto 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 0Untuk informasi selengkapnya tentang parameter Epilog, lihat dokumentasi Slurm
. -
Dalam
slurm.conffile dari node controller, tambahkan baris untuk menunjuk ke skrip epilog yang Anda buat.Epilog="/path/to/epilog.sh" #For example: /fsx/epilogue/epilog.sh -
Jalankan perintah berikut untuk mengubah izin skrip dan membuatnya dapat dieksekusi.
chown slurm:slurm /path/to/epilog.sh chmod +x /path/to/epilog.sh -
Untuk menerapkan semua perubahan Anda, jalankan
scontrol reconfigure.
T. Bagaimana cara menggunakan NVMe penyimpanan lokal instans P untuk meluncurkan kontainer 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, lihatJalankan kontainer Docker pada node komputasi Slurm HyperPod.
T. 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: Mempersiapkan grup keamanan berkemampuan EFA di EC2 Panduan Pengguna Amazon.
T. 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 Perhatikan bahwa SageMaker HyperPod saat ini tidak mendukung ekspor metrik sistem ke Amazon. CloudWatch
T. Dapatkah 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, 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.
