Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Slurmpanduan untuk beberapa mode antrian
Di sini Anda dapat mempelajari bagaimana AWS ParallelCluster dan Slurm mengelola node antrian (partisi) dan bagaimana Anda dapat memantau status antrian dan node.
## Ikhtisar
Arsitektur penskalaan didasarkan pada Slurm [Panduan Penjadwalan Cloud](https://slurm.schedmd.com/elastic_computing.html) dan plugin hemat daya. Untuk informasi selengkapnya tentang plugin hemat daya, lihat [Panduan Penghematan Slurm Daya](https://slurm.schedmd.com/power_save.html). Dalam arsitektur, sumber daya yang berpotensi tersedia untuk cluster biasanya telah ditentukan sebelumnya dalam Slurm konfigurasi sebagai node cloud.
## Siklus hidup simpul awan
Sepanjang siklus hidupnya, node cloud memasukkan beberapa jika tidak semua status berikut:`POWER_SAVING`, `POWER_UP` (`pow_up`), (), dan `ALLOCATED` `POWER_DOWN` (`alloc``pow_dn`). Dalam beberapa kasus, node cloud mungkin memasuki `OFFLINE` status. Daftar berikut merinci beberapa aspek status ini dalam siklus hidup node cloud.
+ **Sebuah node dalam `POWER_SAVING` keadaan** muncul dengan `~` akhiran (misalnya`idle~`) di`sinfo`. Dalam keadaan ini, tidak ada instance EC2 yang mendukung node. Namun, masih Slurm dapat mengalokasikan pekerjaan ke node.
+ **Sebuah simpul yang beralih ke `POWER_UP` status** muncul dengan `#` akhiran (misalnya`idle#`) di. `sinfo` Sebuah node secara otomatis bertransisi ke `POWER_UP` keadaan, ketika Slurm mengalokasikan pekerjaan ke node dalam keadaan. `POWER_SAVING`
Atau, Anda dapat mentransisikan node ke `POWER_UP` status secara manual sebagai pengguna `su` root dengan perintah:
```
$ scontrol update nodename={{nodename}} state=power_up
```
Pada tahap ini, `ResumeProgram` dipanggil, instans EC2 diluncurkan dan dikonfigurasi, dan transisi node ke status. `POWER_UP`
+ **Node yang saat ini tersedia untuk digunakan** muncul tanpa akhiran (misalnya`idle`) di`sinfo`. Setelah node diatur dan telah bergabung dengan cluster, itu menjadi tersedia untuk menjalankan pekerjaan. Pada tahap ini, node dikonfigurasi dengan benar dan siap digunakan.
Sebagai aturan umum, kami merekomendasikan bahwa jumlah instans Amazon EC2 sama dengan jumlah node yang tersedia. Dalam kebanyakan kasus, node statis tersedia setelah cluster dibuat.
+ **Node yang bertransisi ke `POWER_DOWN` status** muncul dengan `%` akhiran (misalnya`idle%`) di. `sinfo` Node dinamis secara otomatis memasuki `POWER_DOWN` status setelahnya [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime). Sebaliknya, node statis dalam banyak kasus tidak dimatikan. Namun, Anda dapat menempatkan node dalam `POWER_DOWN` keadaan secara manual sebagai pengguna `su` root dengan perintah:
```
$ scontrol update nodename={{nodename}} state=down reason="manual draining"
```
Dalam keadaan ini, instance yang terkait dengan node dihentikan, dan node diatur kembali ke `POWER_SAVING` status dan tersedia untuk digunakan setelahnya. [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)
[`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)Pengaturan disimpan ke `SuspendTimeout` pengaturan Slurm konfigurasi.
+ **Node yang offline** muncul dengan `*` akhiran (misalnya`down*`) di`sinfo`. Sebuah node akan offline jika Slurm controller tidak dapat menghubungi node atau jika node statis dinonaktifkan dan instance backing dihentikan.
Pertimbangkan status simpul yang ditunjukkan pada `sinfo` contoh berikut.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
efa up infinite 4 idle~ efa-dy-efacompute1-[1-4]
efa up infinite 1 idle efa-st-efacompute1-1
gpu up infinite 1 idle% gpu-dy-gpucompute1-1
gpu up infinite 9 idle~ gpu-dy-gpucompute1-[2-10]
ondemand up infinite 2 mix# ondemand-dy-ondemandcompute1-[1-2]
ondemand up infinite 18 idle~ ondemand-dy-ondemandcompute1-[3-10],ondemand-dy-ondemandcompute2-[1-10]
spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3]
spot* up infinite 2 idle spot-st-spotcompute2-[1-2]
```
`efa-st-efacompute1-1`Node `spot-st-spotcompute2-[1-2]` dan sudah memiliki instance pendukung yang disiapkan dan tersedia untuk digunakan. `ondemand-dy-ondemandcompute1-[1-2]`Node berada dalam `POWER_UP` keadaan dan harus tersedia dalam beberapa menit. `gpu-dy-gpucompute1-1`Node dalam `POWER_DOWN` keadaan, dan transisi ke `POWER_SAVING` keadaan setelah [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)(default ke 10 menit).
Semua node lain dalam `POWER_SAVING` keadaan tanpa instance EC2 yang mendukungnya.
## Bekerja dengan node yang tersedia
Node yang tersedia didukung oleh instans Amazon EC2. Secara default, nama node dapat digunakan untuk langsung SSH ke dalam instance (misalnya`ssh efa-st-efacompute1-1`). Alamat IP pribadi dari instance dapat diambil menggunakan perintah:
```
$ scontrol show nodes {{nodename}}
```
Periksa alamat IP di `NodeAddr` bidang yang dikembalikan.
Untuk node yang tidak tersedia, `NodeAddr` bidang tidak boleh mengarah ke instans Amazon EC2 yang sedang berjalan. Sebaliknya, itu harus sama dengan nama node.
## Status pekerjaan dan pengajuan
Pekerjaan yang dikirimkan dalam banyak kasus segera dialokasikan ke node dalam sistem, atau ditempatkan di pending jika semua node dialokasikan.
Jika node yang dialokasikan untuk pekerjaan menyertakan node apa pun dalam suatu `POWER_SAVING` keadaan, pekerjaan dimulai dengan`CF`, atau `CONFIGURING` status. Pada saat ini, pekerjaan menunggu node di `POWER_SAVING` negara bagian untuk beralih ke negara `POWER_UP` bagian dan menjadi tersedia.
Setelah semua node yang dialokasikan untuk pekerjaan tersedia, pekerjaan memasuki status `RUNNING` (`R`).
Secara default, semua pekerjaan dikirimkan ke antrian default (dikenal sebagai partisi diSlurm). Ini ditandai dengan `*` akhiran setelah nama antrian. Anda dapat memilih antrian menggunakan opsi pengiriman `-p` pekerjaan.
Semua node dikonfigurasi dengan fitur berikut, yang dapat digunakan dalam perintah pengiriman pekerjaan:
+ Tipe instance (misalnya`c5.xlarge`)
+ Tipe simpul (Ini adalah salah satu `dynamic` atau`static`.)
Anda dapat melihat fitur untuk node tertentu dengan menggunakan perintah:
```
$ scontrol show nodes {{nodename}}
```
Sebagai gantinya, periksa `AvailableFeatures` daftarnya.
Pertimbangkan status awal cluster, yang dapat Anda lihat dengan menjalankan `sinfo` perintah.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
efa up infinite 4 idle~ efa-dy-efacompute1-[1-4]
efa up infinite 1 idle efa-st-efacompute1-1
gpu up infinite 10 idle~ gpu-dy-gpucompute1-[1-10]
ondemand up infinite 20 idle~ ondemand-dy-ondemandcompute1-[1-10],ondemand-dy-ondemandcompute2-[1-10]
spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3]
spot* up infinite 2 idle spot-st-spotcompute2-[1-2]
```
Perhatikan bahwa `spot` adalah antrian default. Hal ini ditunjukkan oleh `*` sufiks.
Kirim pekerjaan ke satu node statis dalam antrian default (`spot`).
```
$ sbatch --wrap {{"sleep 300"}} -N {{1}} -C {{static}}
```
Kirim pekerjaan ke satu node dinamis dalam `EFA` antrian.
```
$ sbatch --wrap {{"sleep 300"}} -p {{efa}} -C {{dynamic}}
```
Kirim pekerjaan ke delapan (8) `c5.2xlarge` node dan dua (2) `t2.xlarge` node dalam `ondemand` antrian.
```
$ sbatch --wrap {{"sleep 300"}} -p {{ondemand}} -N {{10}} -C "[{{c5.2xlarge*8&t2.xlarge*2}}]"
```
Kirim pekerjaan ke satu node GPU dalam `gpu` antrian.
```
$ sbatch --wrap {{"sleep 300"}} -p {{gpu}} -G {{1}}
```
Pertimbangkan keadaan pekerjaan menggunakan `squeue` perintah.
```
$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
12 ondemand wrap ubuntu CF 0:36 10 ondemand-dy-ondemandcompute1-[1-8],ondemand-dy-ondemandcompute2-[1-2]
13 gpu wrap ubuntu CF 0:05 1 gpu-dy-gpucompute1-1
7 spot wrap ubuntu R 2:48 1 spot-st-spotcompute2-1
8 efa wrap ubuntu R 0:39 1 efa-dy-efacompute1-1
```
Pekerjaan 7 dan 8 (dalam `spot` dan `efa` antrian) sudah berjalan (`R`). Pekerjaan 12 dan 13 masih mengkonfigurasi (`CF`), mungkin menunggu instance tersedia.
```
# Nodes states corresponds to state of running jobs
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
efa up infinite 3 idle~ efa-dy-efacompute1-[2-4]
efa up infinite 1 mix efa-dy-efacompute1-1
efa up infinite 1 idle efa-st-efacompute1-1
gpu up infinite 1 mix~ gpu-dy-gpucompute1-1
gpu up infinite 9 idle~ gpu-dy-gpucompute1-[2-10]
ondemand up infinite 10 mix# ondemand-dy-ondemandcompute1-[1-8],ondemand-dy-ondemandcompute2-[1-2]
ondemand up infinite 10 idle~ ondemand-dy-ondemandcompute1-[9-10],ondemand-dy-ondemandcompute2-[3-10]
spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3]
spot* up infinite 1 mix spot-st-spotcompute2-1
spot* up infinite 1 idle spot-st-spotcompute2-2
```
## Status dan fitur simpul
Dalam kebanyakan kasus, status node dikelola sepenuhnya AWS ParallelCluster sesuai dengan proses spesifik dalam siklus hidup node cloud yang dijelaskan sebelumnya dalam topik ini.
Namun, AWS ParallelCluster juga menggantikan atau mengakhiri node yang tidak sehat di `DOWN` dan `DRAINED` status dan node yang memiliki instance dukungan yang tidak sehat. Untuk informasi selengkapnya, lihat [`clustermgtd`](processes-v3.md#clustermgtd-v3).
## Status partisi
AWS ParallelCluster mendukung status partisi berikut. SlurmPartisi adalah antrian di AWS ParallelCluster.
+ `UP`: Menunjukkan bahwa partisi dalam keadaan aktif. Ini adalah keadaan default partisi. Dalam keadaan ini, semua node di partisi aktif dan tersedia untuk digunakan.
+ `INACTIVE`: Menunjukkan bahwa partisi dalam keadaan tidak aktif. Dalam keadaan ini, semua instance backing node dari partisi tidak aktif dihentikan. Instance baru tidak diluncurkan untuk node di partisi yang tidak aktif.
## pcluster update-compute-fleet
+ **Menghentikan armada komputasi** - Ketika perintah berikut dijalankan, semua partisi beralih ke `INACTIVE` negara bagian, dan AWS ParallelCluster proses menjaga partisi dalam keadaan. `INACTIVE`
```
$ pcluster update-compute-fleet --cluster-name {{testSlurm}} \
--region {{eu-west-1}} --status STOP_REQUESTED
```
+ **Memulai armada komputasi** - Ketika perintah berikut dijalankan, semua partisi awalnya beralih ke negara. `UP` Namun, AWS ParallelCluster proses tidak menjaga partisi dalam `UP` keadaan. Anda perlu mengubah status partisi secara manual. Semua node statis menjadi tersedia setelah beberapa menit. Perhatikan bahwa menyetel partisi ke `UP` tidak menyalakan kapasitas dinamis apa pun.
```
$ pcluster update-compute-fleet --cluster-name {{testSlurm}} \
--region {{eu-west-1}} --status START_REQUESTED
```
Ketika `update-compute-fleet` dijalankan, Anda dapat memeriksa status cluster dengan menjalankan `pcluster describe-compute-fleet` perintah dan memeriksa`Status`. Berikut daftar kemungkinan status:
+ `STOP_REQUESTED`: Permintaan armada stop compute dikirim ke cluster.
+ `STOPPING`: `pcluster` Proses saat ini menghentikan armada komputasi.
+ `STOPPED`: `pcluster` Proses menyelesaikan proses penghentian, semua partisi dalam `INACTIVE` keadaan, dan semua instance komputasi dihentikan.
+ `START_REQUESTED`: Permintaan armada komputasi awal dikirim ke cluster.
+ `STARTING`: `pcluster` Proses saat ini memulai cluster.
+ `RUNNING`: `pcluster` Proses menyelesaikan proses awal, semua partisi dalam `UP` keadaan, dan node statis tersedia setelah beberapa menit.
+ `PROTECTED`: Status ini menunjukkan bahwa beberapa partisi memiliki kegagalan bootstrap yang konsisten. Partisi yang terpengaruh tidak aktif. Silakan selidiki masalah ini dan kemudian jalankan `update-compute-fleet` untuk mengaktifkan kembali armada.
## Kontrol antrian secara manual
Dalam beberapa kasus, Anda mungkin ingin memiliki beberapa kontrol manual atas node atau antrian (dikenal sebagai partisi diSlurm) dalam sebuah cluster. Anda dapat mengelola node dalam cluster melalui prosedur umum berikut menggunakan `scontrol` perintah.
+ **Nyalakan node dinamis dalam `POWER_SAVING` keadaan**
Jalankan perintah sebagai pengguna `su` root:
```
$ scontrol update nodename={{nodename}} state=power_up
```
Anda juga dapat mengirimkan `sleep 1` pekerjaan placeholder yang meminta sejumlah node dan kemudian mengandalkan Slurm untuk meningkatkan jumlah node yang diperlukan.
+ **Matikan node dinamis sebelumnya [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)**
Kami menyarankan Anda mengatur node dinamis `DOWN` sebagai pengguna `su` root dengan perintah:
```
$ scontrol update nodename={{nodename}} state=down reason="manually draining"
```
AWS ParallelCluster secara otomatis mengakhiri dan me-reset node dinamis yang jatuh.
Secara umum, kami tidak menyarankan Anda mengatur node untuk `POWER_DOWN` langsung menggunakan `scontrol update nodename={{nodename}} state=power_down` perintah. Ini karena AWS ParallelCluster secara otomatis menangani proses power down.
+ **Nonaktifkan antrian (partisi) atau hentikan semua node statis di partisi tertentu**
Tetapkan antrian tertentu untuk `INACTIVE` sebagai pengguna `su` root dengan perintah:
```
$ scontrol update partition={{queuename}} state=inactive
```
Melakukan hal ini mengakhiri semua instance backing node di partisi.
+ **Aktifkan antrian (partisi)**
Tetapkan antrian tertentu ke `UP` pengguna `su` root dengan perintah:
```
$ scontrol update partition={{queuename}} state=up
```
## Perilaku dan penyesuaian penskalaan
**Berikut adalah contoh alur kerja penskalaan normal:**
+ Penjadwal menerima pekerjaan yang membutuhkan dua node.
+ Penjadwal mentransisikan dua node ke `POWER_UP` status, dan memanggil `ResumeProgram` dengan nama node (misalnya`queue1-dy-spotcompute1-[1-2]`).
+ `ResumeProgram`meluncurkan dua instans Amazon EC2 dan menetapkan alamat IP pribadi dan nama host `queue1-dy-spotcompute1-[1-2]` dari, `ResumeTimeout` menunggu (periode default adalah 30 menit sebelum mengatur ulang node.
+ Instans dikonfigurasi dan bergabung dengan cluster. Sebuah pekerjaan mulai berjalan pada instance.
+ Pekerjaan selesai dan berhenti berjalan.
+ Setelah konfigurasi `SuspendTime` telah berlalu (yang diatur ke [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)), penjadwal menyetel instance ke status. `POWER_SAVING` Scheduler kemudian menetapkan `queue1-dy-spotcompute1-[1-2]` ke `POWER_DOWN` status dan memanggil `SuspendProgram` dengan nama node.
+ `SuspendProgram`disebut untuk dua node. Node tetap dalam `POWER_DOWN` keadaan, misalnya, dengan tetap `idle%` selama a `SuspendTimeout` (periode default adalah 120 detik (2 menit)). Setelah `clustermgtd` mendeteksi bahwa node dimatikan, itu mengakhiri instance dukungan. Kemudian, transisi `queue1-dy-spotcompute1-[1-2]` ke keadaan idle dan me-reset alamat IP pribadi dan nama host sehingga siap untuk power up untuk pekerjaan masa depan.
**Jika ada yang salah dan instance untuk node tertentu tidak dapat diluncurkan karena alasan tertentu, maka hal berikut terjadi:**
+ Penjadwal menerima pekerjaan yang membutuhkan dua node.
+ Penjadwal mentransisikan dua node cloud bursting ke `POWER_UP` status dan memanggil `ResumeProgram` dengan nama node, (misalnya). `queue1-dy-spotcompute1-[1-2]`
+ `ResumeProgram`meluncurkan hanya satu (1) instans Amazon EC2 dan `queue1-dy-spotcompute1-1` mengonfigurasi, dengan satu (1) instance`queue1-dy-spotcompute1-2`, gagal diluncurkan.
+ `queue1-dy-spotcompute1-1`tidak terpengaruh dan online setelah mencapai `POWER_UP` negara bagian.
+ `queue1-dy-spotcompute1-2`transisi ke `POWER_DOWN` status, dan pekerjaan diminta ulang secara otomatis karena Slurm mendeteksi kegagalan node.
+ `queue1-dy-spotcompute1-2`menjadi tersedia setelah `SuspendTimeout` (defaultnya adalah 120 detik (2 menit)). Sementara itu, pekerjaan tersebut diminta ulang dan dapat mulai berjalan di node lain.
+ Proses di atas berulang sampai pekerjaan dapat berjalan pada node yang tersedia tanpa terjadi kegagalan.
**Ada dua parameter waktu yang dapat disesuaikan jika diperlukan:**
+ **`ResumeTimeout`(defaultnya adalah 30 menit)**: `ResumeTimeout` mengontrol waktu Slurm menunggu sebelum mentransisikan node ke keadaan turun.
+ Mungkin berguna untuk memperpanjang `ResumeTimeout` jika proses pre/post instalasi Anda memakan waktu hampir selama itu.
+ `ResumeTimeout`juga merupakan waktu maksimum yang AWS ParallelCluster menunggu sebelum mengganti atau mengatur ulang node jika ada masalah. Menghitung node berhenti sendiri jika ada kesalahan yang terjadi selama peluncuran atau penyiapan. AWS ParallelCluster proses menggantikan node pada deteksi instance yang dihentikan.
+ **`SuspendTimeout`(defaultnya adalah 120 detik (2 menit))**: `SuspendTimeout` mengontrol seberapa cepat node ditempatkan kembali ke sistem dan siap digunakan lagi.
+ Yang lebih pendek `SuspendTimeout` berarti node diatur ulang lebih cepat, dan Slurm dapat mencoba meluncurkan instance lebih sering.
+ Yang lebih lama `SuspendTimeout` berarti bahwa node yang gagal diatur ulang lebih lambat. Sementara itu, Slurm mencoba menggunakan node lain. Jika `SuspendTimeout` lebih dari beberapa menit, cobalah Slurm untuk menelusuri semua node dalam sistem. Yang lebih lama `SuspendTimeout` mungkin bermanfaat bagi sistem skala besar (lebih dari 1.000 node) untuk mengurangi stres Slurm ketika mencoba untuk sering mengantri ulang pekerjaan yang gagal.
+ Perhatikan bahwa `SuspendTimeout` tidak mengacu pada waktu AWS ParallelCluster menunggu untuk mengakhiri instance dukungan untuk sebuah node. Instance pendukung untuk `POWER_DOWN` node segera dihentikan. Proses penghentian biasanya selesai dalam beberapa menit. Namun, selama waktu ini, node tetap dalam `POWER_DOWN` status dan tidak tersedia untuk penggunaan penjadwal.
## Log untuk arsitektur
Daftar berikut berisi log kunci. Nama aliran log yang digunakan dengan Amazon CloudWatch Logs memiliki format`{{{hostname}}}.{{{instance_id}}}.{{{logIdentifier}}}`, di mana {{logIdentifier}} mengikuti nama log.
+ `ResumeProgram`: `/var/log/parallelcluster/slurm_resume.log` (`slurm_resume`)
+ `SuspendProgram`: `/var/log/parallelcluster/slurm_suspend.log` (`slurm_suspend`)
+ `clustermgtd`: `/var/log/parallelcluster/clustermgtd.log` (`clustermgtd`)
+ `computemgtd`: `/var/log/parallelcluster/computemgtd.log` (`computemgtd`)
+ `slurmctld`: `/var/log/slurmctld.log` (`slurmctld`)
+ `slurmd`: `/var/log/slurmd.log` (`slurmd`)
## Masalah umum dan cara men-debug:
**Node yang gagal diluncurkan, dinyalakan, atau bergabung dengan cluster**
+ Node dinamis:
+ Periksa `ResumeProgram` log untuk melihat apakah `ResumeProgram` dipanggil dengan node. Jika tidak, periksa `slurmctld` log untuk menentukan apakah Slurm mencoba memanggil `ResumeProgram` dengan node. Perhatikan bahwa izin yang salah `ResumeProgram` dapat menyebabkannya gagal secara diam-diam.
+ Jika `ResumeProgram` dipanggil, periksa untuk melihat apakah sebuah instance diluncurkan untuk node. Jika instance tidak diluncurkan, harus ada pesan kesalahan yang jelas mengapa instance gagal diluncurkan.
+ Jika sebuah instance diluncurkan, mungkin ada beberapa masalah selama proses bootstrap. Temukan alamat IP pribadi dan ID instance yang sesuai dari `ResumeProgram` log dan lihat log bootstrap yang sesuai untuk instance tertentu di CloudWatch Log.
+ Node statis:
+ Periksa `clustermgtd` log untuk melihat apakah instance diluncurkan untuk node. Jika instance tidak diluncurkan, harus ada kesalahan yang jelas tentang mengapa instance gagal diluncurkan.
+ Jika sebuah instance diluncurkan, ada beberapa masalah dengan proses bootstrap. Temukan IP pribadi dan ID instance yang sesuai dari `clustermgtd` log dan lihat log bootstrap yang sesuai untuk instance tertentu di CloudWatch Log.
**Node diganti atau dihentikan secara tak terduga, dan kegagalan node**
+ Node replaced/terminated secara tak terduga:
+ Dalam kebanyakan kasus, `clustermgtd` menangani semua tindakan pemeliharaan node. Untuk memeriksa apakah `clustermgtd` diganti atau dihentikan node, periksa `clustermgtd` log.
+ Jika `clustermgtd` diganti atau dihentikan node, harus ada pesan yang menunjukkan alasan tindakan. Jika alasannya terkait penjadwal (misalnya, simpulnya`DOWN`), periksa `slurmctld` log untuk lebih jelasnya. Jika alasannya terkait Amazon EC2, gunakan alat seperti Amazon CloudWatch atau konsol Amazon EC2, CLI, atau SDK, untuk memeriksa status atau log untuk instance itu. Misalnya, Anda dapat memeriksa apakah instans memiliki acara terjadwal atau gagal pemeriksaan status kesehatan Amazon EC2.
+ Jika `clustermgtd` tidak mengakhiri node, periksa apakah node `computemgtd` dihentikan atau apakah EC2 menghentikan instance untuk merebut kembali Instance Spot.
+ Kegagalan simpul:
+ Dalam kebanyakan kasus, pekerjaan secara otomatis diminta ulang jika node gagal. Lihat di `slurmctld` log untuk melihat mengapa pekerjaan atau node gagal dan menilai situasi dari sana.
**Kegagalan saat mengganti atau menghentikan instance, kegagalan saat mematikan node**
+ Secara umum, `clustermgtd` menangani semua tindakan penghentian instance yang diharapkan. Lihat di `clustermgtd` log untuk melihat mengapa gagal mengganti atau mengakhiri node.
+ Untuk node dinamis gagal [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime), lihat di `SuspendProgram` log untuk melihat apakah `slurmctld` proses membuat panggilan dengan node tertentu sebagai argumen. Catatan sebenarnya `SuspendProgram` tidak melakukan tindakan spesifik apa pun. Sebaliknya, itu hanya log ketika dipanggil. Semua penghentian dan `NodeAddr` penyetelan ulang instans diselesaikan oleh`clustermgtd`. Slurmtransisi node ke `IDLE` setelahnya`SuspendTimeout`.
**Masalah lainnya:**
+ AWS ParallelCluster tidak membuat alokasi pekerjaan atau keputusan penskalaan. Itu hanya mencoba untuk meluncurkan, menghentikan, dan memelihara sumber daya sesuai dengan Slurm instruksi.
Untuk masalah terkait alokasi pekerjaan, alokasi node, dan keputusan penskalaan, lihat `slurmctld` log untuk kesalahan.