Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
SageMaker HyperPod ketahanan klaster
SageMaker HyperPod menyediakan fitur ketahanan cluster berikut.
Topik
Pemeriksaan kesehatan cluster
Bagian ini menjelaskan serangkaian pemeriksaan kesehatan yang SageMaker HyperPod digunakan untuk secara teratur memantau kesehatan instance cluster untuk masalah dengan perangkat seperti akselerator (GPUdan inti Trainium) dan jaringan (EFA).
Kategori | Nama utilitas | Kompatibilitas tipe instans | Deskripsi |
---|---|---|---|
Akselerator | DCGMkebijakan | GPU | Setiap instance di cluster terus memantau semua kebijakan GPU terkait termasuk XID kesalahan dengan NVIDIADCGM |
Akselerator | NVIDIA SMI | GPU | utilitas nvidia-sminvidia-smi untuk menentukan kesehatan instance. |
Akselerator | Sysfs neuron | Trainium | Untuk instance yang didukung Trainium, kesehatan perangkat Neuron ditentukan dengan membaca penghitung dari Sysf Neuron yang disebarkan langsung oleh driver Neuron |
Jaringan | EFA | GPUdan Trainium | Untuk membantu diagnostik perangkat Elastic Fabric Adapter (EFA), pemeriksa EFA kesehatan menjalankan serangkaian tes konektivitas menggunakan semua EFA kartu yang tersedia dalam instance. |
Stres | DCGMdiagnostik |
GPU | DCGMdiagnostik |
Stres | CPUstress | GPUdan Trainium | CPUKesehatan ditentukan menggunakan alat stress Linux |
Lanjutkan otomatis
Bagian ini menjelaskan cara menjalankan pekerjaan pelatihan dengan fungsionalitas SageMaker HyperPod auto-resume, yang menyediakan infrastruktur ketahanan tanpa sentuhan untuk secara otomatis memulihkan pekerjaan pelatihan dari pos pemeriksaan terakhir yang disimpan jika terjadi kegagalan perangkat keras untuk cluster dengan lebih dari 16 node.
Dengan fungsionalitas auto-resume, jika pekerjaan gagal karena kegagalan perangkat keras atau masalah sementara di antara pelatihan, SageMaker HyperPod auto-resume memulai alur kerja penggantian node dan memulai ulang pekerjaan setelah node yang salah diganti.
catatan
Ketika Generic Resources (GRES)
Menggunakan fungsi SageMaker HyperPod auto-resume dengan Slurm
Bila Anda menggunakan SageMaker HyperPod auto-resume dengan Slurm, Anda harus menjalankan pekerjaan di dalam alokasi eksklusif yang diperoleh baik dengan menggunakan atau. salloc
sbatch
Bagaimanapun, Anda perlu memodifikasi skrip entrypoint untuk memastikan bahwa semua langkah penyiapan berjalan dalam satu srun
perintah saat melanjutkan pekerjaan. Melalui skrip entrypoint, penting untuk mengatur lingkungan pada node yang diganti agar konsisten dengan lingkungan tempat langkah pekerjaan dijalankan sebelum dihentikan. Preseden berikut menunjukkan cara menyiapkan skrip entrypoint untuk menjaga lingkungan tetap konsisten dan menjalankannya sebagai satu perintah. srun
Tip
Jika Anda menggunakansbatch
, Anda dapat menjaga skrip batch sederhana dengan membuat skrip terpisah untuk mengatur lingkungan dan menggunakan satu srun
perintah.
-
Buat skrip menggunakan contoh kode berikut dan simpan sebagai
train_auto_resume.sh
. Skrip ini menyebarkan pengaturan lingkungan pelatihan dengan asumsi bahwa tidak ada konfigurasi manual yang sebelumnya dibuat untuk node yang diganti. Ini memastikan bahwa lingkungan adalah node-agnostik, sehingga ketika sebuah node diganti, lingkungan yang sama disediakan pada node sebelum melanjutkan pekerjaan.catatan
Contoh kode berikut menunjukkan bagaimana menemukan daftar simpul Slurm yang terkait dengan pekerjaan. Jangan gunakan variabel
$SLURM_JOB_NODELIST
lingkungan yang disediakan oleh Slurm, karena nilainya mungkin sudah usang setelah melanjutkan pekerjaan SageMaker HyperPod secara otomatis. Contoh kode berikut menunjukkan bagaimana mendefinisikanNODE_LIST
variabel baru untuk menggantikanSLURM_JOB_NODELIST
, dan kemudian mengaturMASTER_NODE
danMASTER_ADDR
variabel off dariNODE_LIST
variabel.#!/bin/bash # Filename: train_auto_resume.sh # Sample containerized script to launch a training job with a single srun which can be auto-resumed. # Place your training environment setup here. # Example: Install conda, docker, activate virtual env, etc. # Get the list of nodes for a given job NODE_LIST=$(scontrol show jobid=$SLURM_JOBID | \ # Show details of the SLURM job awk -F= '/NodeList=/{print $2}' | \ # Extract NodeList field grep -v Exc) # Exclude nodes marked as excluded # Determine the master node from the node list MASTER_NODE=$(scontrol show hostname $NODE_LIST | \ # Convert node list to hostnames head -n 1) # Select the first hostname as master node # Get the master node address MASTER_ADDR=$(scontrol show node=$MASTER_NODE | \ # Show node information awk -F= '/NodeAddr=/{print $2}' | \ # Extract NodeAddr awk '{print $1}') # Print the first part of NodeAddr # Torchrun command to launch the training job torchrun_cmd="torchrun --nnodes=$SLURM_NNODES \ --nproc_per_node=1 \ --node_rank=$SLURM_NODE \ --master-addr=$MASTER_ADDR \ --master_port=
1234
\<your_training_script.py>
" # Execute the torchrun command in the 'pytorch' Conda environment, # streaming output live /opt/conda/bin/conda run --live-stream -n pytorch $torchrun_cmdTip
Anda dapat menggunakan skrip sebelumnya untuk menambahkan lebih banyak perintah untuk menginstal dependensi tambahan apa pun untuk pekerjaan Anda. Namun, kami menyarankan agar Anda menyimpan skrip penginstalan dependensi ke kumpulan skrip siklus hidup yang digunakan selama pembuatan klaster. Jika Anda menggunakan lingkungan virtual yang dihosting di direktori bersama, Anda juga dapat menggunakan skrip ini untuk mengaktifkan lingkungan virtual.
-
Luncurkan pekerjaan dengan SageMaker HyperPod resume otomatis diaktifkan dengan menambahkan tanda
--auto-resume=1
untuk menunjukkan bahwasrun
perintah harus dicoba ulang secara otomatis jika terjadi kegagalan perangkat keras.catatan
Jika Anda telah menyiapkan alokasi sumber daya menggunakan
sbatch
atausalloc
, Anda dapat menjalankan beberapasrun
perintah dalam alokasi. Jika terjadi kegagalan, fungsi SageMaker HyperPod auto-resume hanya beroperasi pada langkah pekerjaansaat ini dari srun
perintah dengan bendera--auto-resume=1
. Dengan kata lain, mengaktifkan auto-resume dalam perintah tidak berlaku untuksrun
srun
perintah lain yang diluncurkan dalam sesi alokasi sumber daya.Berikut ini adalah contoh
srun
perintah denganauto-resume
diaktifkan.Menggunakan sbatch
Karena sebagian besar logika untuk mengatur lingkungan sudah ada
train_auto_resume.sh
, skrip batch harus sederhana dan mirip dengan contoh kode berikut. Asumsikan bahwa skrip batch berikut disimpan sebagaibatch.sh
.#!/bin/bash #SBATCH --nodes 2 #SBATCH --exclusive srun --auto-resume=1
train_auto_resume.sh
Jalankan skrip batch sebelumnya menggunakan perintah berikut.
sbatch
batch.sh
Menggunakan salloc
Mulailah dengan memperoleh alokasi eksklusif, dan jalankan
srun
perintah dengan--auto-resume
flag dan skrip entrypoint.salloc -N 2 --exclusive srun --auto-resume=1
train_auto_resume.sh
Cara mengganti simpul yang salah yang tidak dilanjutkan secara otomatis oleh HyperPod
Fungsionalitas HyperPod auto-resume memonitor jika status node Slurm Anda berubah menjadi atau. fail
down
Anda dapat memeriksa status node Slurm dengan menjalankan. sinfo
Jika Anda memiliki node yang terjebak dengan masalah tetapi tidak diperbaiki oleh fungsionalitas HyperPod auto-resume, kami sarankan Anda untuk menjalankan perintah berikut untuk mengubah status node menjadifail
.
scontrol update node=
<ip-ipv4>
state=fail
reason="Action:Replace"
Pada contoh perintah sebelumnya, ganti
dengan nama simpul Slurm (nama host) dari instance yang salah yang ingin Anda ganti.<ip-ipv4>
Setelah menjalankan perintah ini, node harus masuk ke fail
status, menunggu pekerjaan yang sedang berjalan selesai, diganti dengan instance yang sehat, dan dipulihkan dengan nama host yang sama. Proses ini membutuhkan waktu tergantung pada instance yang tersedia di Availability Zone Anda dan waktu yang diperlukan untuk menjalankan skrip siklus hidup Anda. Selama proses pembaruan dan penggantian, hindari mengubah status node secara manual lagi atau memulai ulang pengontrol Slurm; melakukannya dapat menyebabkan kegagalan penggantian. Jika node tidak pulih atau beralih ke idle
status setelah waktu yang lama, hubungi AWS
Support
Jika node yang salah terus-menerus terjebak dalam fail
status, upaya terakhir yang mungkin Anda coba adalah secara manual mengubah status node menjadidown
. Ini membutuhkan hak administrator (izin sudo).
Awas
Lanjutkan dengan hati-hati sebelum Anda menjalankan perintah berikut karena memaksa membunuh semua pekerjaan, dan Anda mungkin kehilangan semua pekerjaan yang belum disimpan.
scontrol update node=
<ip-ipv4>
state=down
reason="Action:Replace"