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 melalui orkestrasi slurm menyediakan fitur ketahanan cluster berikut.
**Topics**
+ [Agen pemantauan kesehatan](sagemaker-hyperpod-resiliency-slurm-cluster-health-check.md)
+ [Pemulihan simpul otomatis dan lanjutkan otomatis](sagemaker-hyperpod-resiliency-slurm-auto-resume.md)
+ [Ganti atau reboot node secara manual menggunakan Slurm](sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance.md)
# Agen pemantauan kesehatan
Bagian ini menjelaskan serangkaian pemeriksaan kesehatan yang SageMaker HyperPod digunakan untuk secara teratur memantau kesehatan instance cluster untuk masalah dengan perangkat seperti akselerator (inti GPU dan Trainium) dan jaringan (EFA). SageMaker HyperPod Health-Monitoring Agent (HMA) terus memantau status kesehatan setiap instans berbasis GPU atau Trainium. Ketika mendeteksi instans atau kegagalan GPU, agen menandai instance sebagai tidak sehat.
SageMaker HyperPod HMA melakukan pemeriksaan kesehatan yang sama untuk orkestra EKS dan Slurm. Untuk informasi lebih lanjut tentang HMA, lihat[Sistem Pemantauan Kesehatan](sagemaker-hyperpod-eks-resiliency-health-monitoring-agent.md).
# Pemulihan simpul otomatis dan lanjutkan otomatis
**catatan**
Per 11 September 2025, HyperPod dengan orkestrasi Slurm sekarang mendukung agen pemantauan kesehatan. Jalankan [UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html)dan perbarui ke versi terbaru AMI untuk menggunakan fungsi ini.
Bagian ini membahas tentang dua fitur ketahanan pelengkap Amazon SageMaker HyperPod: pemulihan simpul otomatis yang menggantikan infrastruktur yang salah tanpa intervensi manual, dan fungsionalitas lanjutkan otomatis yang memulai ulang pekerjaan pelatihan dari pos pemeriksaan terakhir setelah kegagalan perangkat keras.
## Cara kerja pemulihan simpul otomatis
Selama pembuatan atau pembaruan cluster, pengguna admin cluster dapat memilih opsi pemulihan node (instance) antara `Automatic` (Disarankan) dan `None` pada tingkat cluster. Jika disetel ke`Automatic`, SageMaker HyperPod reboot atau ganti node yang salah secara otomatis.
**penting**
Kami merekomendasikan pengaturan `Automatic` opsi. Secara default, cluster diatur dengan Pemulihan node otomatis.
Pemulihan simpul otomatis berjalan ketika masalah ditemukan dari agen pemantauan kesehatan, pemeriksaan kesehatan dasar, dan pemeriksaan kesehatan mendalam. Jika diatur ke`None`, agen pemantauan kesehatan akan memberi label contoh ketika kesalahan terdeteksi, tetapi tidak akan secara otomatis memulai tindakan perbaikan atau pemulihan pada node yang terpengaruh. Kami tidak merekomendasikan opsi ini.
## Menjalankan pekerjaan pelatihan dengan fungsionalitas SageMaker HyperPod resume otomatis Amazon
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.
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. Pemeriksaan perangkat keras berikut dijalankan setiap kali pekerjaan gagal saat menggunakan resume otomatis:
| Kategori | Nama utilitas | Kompatibilitas tipe instans | Deskripsi |
| --- | --- | --- | --- |
| Akselerator | NVIDIA SMI | GPU | utilitas [nvidia-smi](https://developer.nvidia.com/nvidia-system-management-interface) adalah CLI terkenal 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](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/tools/neuron-sys-tools/neuron-sysfs-user-guide.html). |
| Jaringan | EFA | GPU dan Trainium | Untuk membantu diagnostik perangkat Elastic Fabric Adapter (EFA), pemeriksa kesehatan EFA menjalankan serangkaian tes konektivitas menggunakan semua kartu EFA yang tersedia dalam instans. |
**catatan**
Ketika [Generic Resources (GRES)](https://slurm.schedmd.com/gres.html) 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 berkemampuan 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. Prosedur berikut menunjukkan cara menyiapkan skrip entrypoint untuk menjaga lingkungan tetap konsisten dan menjalankannya sebagai satu `srun` perintah.
**Tip**
Jika Anda menggunakan`sbatch`, 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 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 node 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 menggantikan`SLURM_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 \
"
# 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 untuk pekerjaan Anda. Namun, kami menyarankan agar Anda menyimpan skrip penginstalan dependensi ke [kumpulan skrip siklus hidup](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) 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.
1. 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` atau`salloc`, Anda dapat menjalankan beberapa `srun` perintah dalam alokasi. Jika terjadi kegagalan, fungsi SageMaker HyperPod auto-resume hanya beroperasi pada [langkah pekerjaan](https://slurm.schedmd.com/job_launch.html#step_allocation) 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 ada`train_auto_resume.sh`, skrip batch harus sederhana dan mirip dengan contoh kode berikut. Asumsikan bahwa skrip batch berikut disimpan sebagai`batch.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
```
## Bagaimana pemulihan node otomatis dan auto-resume bekerja sama
Ketika pemulihan node otomatis dan sistem auto-resume aktif, mereka mengikuti pendekatan terkoordinasi untuk menangani kegagalan. Jika HMA mendeteksi kesalahan perangkat keras, node ditandai untuk menguras terlepas dari status tingkat pekerjaan. Dengan pemulihan otomatis node diaktifkan, node secara otomatis diganti setelah semua pekerjaan yang berjalan di node keluar. Dalam skenario ini, untuk pekerjaan dengan resume otomatis diaktifkan, jika ada status keluar bukan nol di langkah, resume otomatis dimulai (pekerjaan dilanjutkan setelah node diganti). Pekerjaan tanpa auto-resume diaktifkan hanya akan keluar, membutuhkan pengiriman ulang manual oleh administrator atau pengguna.
**catatan**
Jika Anda menggunakan auto-resume, node selalu diganti (tidak ada reboot) ketika kegagalan perangkat keras terdeteksi.
# Ganti atau reboot node secara manual menggunakan Slurm
Bagian ini berbicara tentang kapan Anda harus me-reboot atau mengganti node secara manual, dengan instruksi tentang cara melakukan keduanya.
## Kapan harus me-reboot atau mengganti node secara manual
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 node tetap macet atau tidak responsif dan proses auto-resume tidak memulihkannya, Anda dapat secara manual memulai pemulihan. Pilihan antara me-reboot dan mengganti node tergantung pada sifat masalahnya. Pertimbangkan untuk me-reboot saat menghadapi masalah sementara atau terkait perangkat lunak, seperti sistem hang, kebocoran memori, masalah driver GPU, pembaruan kernel, atau proses yang macet. Namun, jika Anda mengalami masalah persisten atau terkait perangkat keras seperti kegagalan GPUs, memori atau kesalahan jaringan, kegagalan pemeriksaan kesehatan berulang, atau node yang tetap tidak responsif setelah beberapa upaya reboot, penggantian node adalah solusi yang lebih tepat.
## Cara untuk me-reboot atau mengganti node secara manual
SageMaker HyperPod menawarkan dua metode untuk pemulihan node manual. Pendekatan yang lebih disukai adalah menggunakan SageMaker HyperPod Reboot dan Replace APIs, yang menyediakan proses pemulihan yang lebih cepat dan lebih transparan yang bekerja di semua orkestra. Atau, Anda dapat menggunakan perintah Slurm tradisional seperti`scontrol update`, meskipun metode warisan ini memerlukan akses langsung ke simpul pengontrol Slurm. Kedua metode mengaktifkan proses SageMaker HyperPod pemulihan yang sama.
## Reboot node secara manual menggunakan API reboot
Anda dapat menggunakan **BatchRebootClusterNodes**untuk me-reboot node yang salah secara manual di SageMaker HyperPod cluster Anda.
Berikut adalah contoh menjalankan operasi reboot pada dua Instance cluster menggunakan: AWS Command Line Interface
```
aws sagemaker batch-reboot-cluster-nodes \
--cluster-name arn:aws:sagemaker:ap-northeast-1:123456789:cluster/test-cluster \
--node-ids i-0123456789abcdef0 i-0fedcba9876543210
```
## Ganti node secara manual menggunakan replace API
Anda dapat menggunakan **BatchReplaceClusterNodes**untuk secara manual mengganti node yang salah di SageMaker HyperPod cluster Anda.
Berikut adalah contoh menjalankan operasi replace pada dua Instance cluster menggunakan: AWS Command Line Interface
```
aws sagemaker batch-replace-cluster-nodes \
--cluster-name arn:aws:sagemaker:ap-northeast-1:123456789:cluster/test-cluster \
--node-ids i-0123456789abcdef0 i-0fedcba9876543210
```
## Reboot node secara manual menggunakan Slurm
Anda juga dapat menggunakan perintah scontrol Slurm untuk memicu pemulihan node. Perintah-perintah ini berinteraksi langsung dengan bidang kontrol Slurm dan menggunakan mekanisme pemulihan dasar SageMaker HyperPod yang sama.
Dalam perintah berikut, ganti dengan nama simpul Slurm (nama host) dari instance yang salah yang ingin Anda reboot.
```
scontrol update node= state=fail reason="Action:Reboot"
```
Ini menandai node sebagai GAGAL dengan alasan yang ditentukan. SageMaker HyperPod mendeteksi ini dan me-reboot instance. Hindari mengubah status simpul atau memulai ulang pengontrol Slurm selama operasi.
## Ganti node secara manual menggunakan Slurm
Anda dapat menggunakan perintah scontrol update sebagai berikut untuk mengganti node.
Dalam perintah berikut, ganti `` dengan nama simpul Slurm (nama host) dari instance yang salah yang ingin Anda ganti.
```
scontrol update node= state=fail reason="Action:Replace"
```
Setelah menjalankan perintah ini, node akan 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](https://console.aws.amazon.com/support/).
## Secara manual memaksa mengubah node
Jika node yang salah terus-menerus terjebak dalam `fail` status, upaya terakhir yang mungkin Anda coba adalah secara manual mengubah status node menjadi`down`. 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= state=down reason="Action:Replace"
```