SageMaker HyperPod ketahanan klaster - Amazon SageMaker

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.

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-smi terkenal CLI untuk mengelola dan memantau. GPUs Pemeriksa kesehatan bawaan mem-parsing output dari nvidia-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 tingkat 2 GPU DCGMdiagnostik level 2 digunakan untuk melatih sistem GPUs dan menempatkan mereka di bawah tekanan untuk mendapatkan wawasan menyeluruh tentang kesehatan.
Stres CPUstress GPUdan Trainium CPUKesehatan ditentukan menggunakan alat stress Linux, yang menjalankan beberapa utas untuk mencapai CPU pemanfaatan 100% dan melakukan operasi I/O.

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) dilampirkan ke node Slurm, Slurm biasanya tidak mengizinkan perubahan dalam alokasi node, seperti mengganti node, dan dengan demikian tidak memungkinkan untuk melanjutkan pekerjaan yang gagal. Kecuali dilarang secara eksplisit, fungsionalitas HyperPod auto-resume secara otomatis mengantri ulang pekerjaan yang salah yang terkait dengan node yang diaktifkan. GRES Proses ini melibatkan menghentikan pekerjaan, menempatkannya kembali ke antrian pekerjaan, dan kemudian memulai kembali pekerjaan dari awal.

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.

  1. Buat skrip menggunakan contoh kode berikut dan simpan sebagaitrain_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 mendefinisikan NODE_LIST variabel baru untuk menggantikanSLURM_JOB_NODELIST, dan kemudian mengatur MASTER_NODE dan MASTER_ADDR variabel off dari NODE_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_cmd
    Tip

    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.

  2. Luncurkan pekerjaan dengan SageMaker HyperPod resume otomatis diaktifkan dengan menambahkan tanda --auto-resume=1 untuk menunjukkan bahwa srun 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 beberapa srun perintah dalam alokasi. Jika terjadi kegagalan, fungsi SageMaker HyperPod auto-resume hanya beroperasi pada langkah pekerjaan saat ini dari srun perintah dengan bendera--auto-resume=1. Dengan kata lain, mengaktifkan auto-resume dalam perintah tidak berlaku untuk srun srun perintah lain yang diluncurkan dalam sesi alokasi sumber daya.

    Berikut ini adalah contoh srun perintah dengan auto-resume diaktifkan.

    Menggunakan sbatch

    Karena sebagian besar logika untuk mengatur lingkungan sudah adatrain_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 <ip-ipv4> dengan nama simpul Slurm (nama host) dari instance yang salah yang ingin Anda ganti.

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"