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
AWS ParallelCluster versi 2.9.0 memperkenalkan beberapa mode antrian dan arsitektur penskalaan baru untuk (). Slurm Workload Manager Slurm
Bagian berikut memberikan gambaran umum tentang penggunaan Slurm cluster dengan arsitektur penskalaan yang baru diperkenalkan.
## Ikhtisar
Arsitektur penskalaan baru 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 baru, 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 simpul dalam `POWER_SAVING` keadaan muncul dengan `~` akhiran (misalnya`idle~`) di`sinfo`. Dalam keadaan ini, tidak ada instans 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`
+ Ketika Slurm mengalokasikan pekerjaan ke node dalam `POWER_SAVING` keadaan, node secara otomatis mentransfer ke keadaan. `POWER_UP` Jika tidak, node dapat ditempatkan dalam `POWER_UP` keadaan secara manual menggunakan `scontrol update nodename=nodename state=power_up` perintah. Pada tahap ini, instans `ResumeProgram` dipanggil, dan instans EC2 diluncurkan dan dikonfigurasi untuk mendukung node. `POWER_UP`
+ Node yang saat ini tersedia untuk digunakan muncul tanpa akhiran apa pun (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 instance di EC2 sama dengan jumlah node yang tersedia. Dalam kebanyakan kasus, node statis selalu 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[`scaledown_idletime`](scaling-section.md#scaledown-idletime). Sebaliknya, node statis dalam banyak kasus tidak dimatikan. Namun, node dapat ditempatkan dalam `POWER_DOWN` keadaan secara manual menggunakan `scontrol update nodename=nodename state=powering_down` perintah. Dalam keadaan ini, instance yang terkait dengan node dihentikan, dan node diatur ulang kembali ke `POWER_SAVING` status ke future use after[`scaledown_idletime`](scaling-section.md#scaledown-idletime). `scaledown-idletime`Pengaturan disimpan ke Slurm konfigurasi sebagai `SuspendTimeout` pengaturan.
+ 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.
Sekarang perhatikan status node yang ditunjukkan dalam `sinfo` contoh berikut.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
efa up infinite 4 idle~ efa-dy-c5n18xlarge-[1-4]
efa up infinite 1 idle efa-st-c5n18xlarge-1
gpu up infinite 1 idle% gpu-dy-g38xlarge-1
gpu up infinite 9 idle~ gpu-dy-g38xlarge-[2-10]
ondemand up infinite 2 mix# ondemand-dy-c52xlarge-[1-2]
ondemand up infinite 18 idle~ ondemand-dy-c52xlarge-[3-10],ondemand-dy-t2xlarge-[1-10]
spot* up infinite 13 idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3]
spot* up infinite 2 idle spot-st-t2large-[1-2]
```
`efa-st-c5n18xlarge-1`Node `spot-st-t2large-[1-2]` dan sudah memiliki instance pendukung yang disiapkan dan tersedia untuk digunakan. `ondemand-dy-c52xlarge-[1-2]`Node berada dalam `POWER_UP` keadaan, dan mereka akan tersedia dalam beberapa menit. `gpu-dy-g38xlarge-1`Node dalam `POWER_DOWN` keadaan, dan akan bertransisi ke `POWER_SAVING` keadaan setelah [`scaledown_idletime`](scaling-section.md#scaledown-idletime) (default ke 120 detik).
Semua node lain dalam `POWER_SAVING` keadaan tanpa instance EC2 yang mendukungnya.
## Bekerja dengan node yang tersedia
Node yang tersedia didukung oleh instance EC2. Secara default, nama node dapat digunakan untuk langsung SSH ke instance (misalnya`ssh efa-st-c5n18xlarge-1`). Alamat IP pribadi dari instance dapat diambil menggunakan `scontrol show nodes nodename` perintah dan memeriksa `NodeAddr` bidang. Untuk node yang tidak tersedia, `NodeAddr` bidang tidak boleh mengarah ke instance 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 `POWER_UP` status 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 semua fitur yang tersedia untuk node tertentu dengan menggunakan `scontrol show nodes nodename` perintah dan memeriksa `AvailableFeatures` daftar.
Pertimbangan lain adalah pekerjaan. Pertama pertimbangkan keadaan awal cluster, yang dapat Anda lihat dengan menjalankan `sinfo` perintah.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
efa up infinite 4 idle~ efa-dy-c5n18xlarge-[1-4]
efa up infinite 1 idle efa-st-c5n18xlarge-1
gpu up infinite 10 idle~ gpu-dy-g38xlarge-[1-10]
ondemand up infinite 20 idle~ ondemand-dy-c52xlarge-[1-10],ondemand-dy-t2xlarge-[1-10]
spot* up infinite 13 idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3]
spot* up infinite 2 idle spot-st-t2large-[1-2]
```
Perhatikan bahwa `spot` adalah antrian default. Hal ini ditunjukkan oleh `*` sufiks.
Kirim pekerjaan ke satu node statis ke antrian default (`spot`).
```
$ sbatch --wrap "sleep 300" -N 1 -C static
```
Kirim pekerjaan ke satu node dinamis ke `EFA` antrian.
```
$ sbatch --wrap "sleep 300" -p efa -C dynamic
```
Kirim pekerjaan ke delapan (8) `c5.2xlarge` node dan dua (2) `t2.xlarge` node ke `ondemand` antrian.
```
$ sbatch --wrap "sleep 300" -p ondemand -N 10 -C "[c5.2xlarge*8&t2.xlarge*2]"
```
Kirim pekerjaan ke satu node GPU ke `gpu` antrian.
```
$ sbatch --wrap "sleep 300" -p gpu -G 1
```
Sekarang 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-c52xlarge-[1-8],ondemand-dy-t2xlarge-[1-2]
13 gpu wrap ubuntu CF 0:05 1 gpu-dy-g38xlarge-1
7 spot wrap ubuntu R 2:48 1 spot-st-t2large-1
8 efa wrap ubuntu R 0:39 1 efa-dy-c5n18xlarge-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-c5n18xlarge-[2-4]
efa up infinite 1 mix efa-dy-c5n18xlarge-1
efa up infinite 1 idle efa-st-c5n18xlarge-1
gpu up infinite 1 mix~ gpu-dy-g38xlarge-1
gpu up infinite 9 idle~ gpu-dy-g38xlarge-[2-10]
ondemand up infinite 10 mix# ondemand-dy-c52xlarge-[1-8],ondemand-dy-t2xlarge-[1-2]
ondemand up infinite 10 idle~ ondemand-dy-c52xlarge-[9-10],ondemand-dy-t2xlarge-[3-10]
spot* up infinite 13 idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3]
spot* up infinite 1 mix spot-st-t2large-1
spot* up infinite 1 idle spot-st-t2large-2
```
## Status dan fitur simpul
Dalam kebanyakan kasus, status node sepenuhnya dikelola oleh 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.md#clustermgtd).
## 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 mulai dan berhenti
Ketika [`pcluster stop`](pcluster.stop.md) dijalankan, semua partisi ditempatkan di `INACTIVE` negara bagian, dan AWS ParallelCluster proses menjaga partisi dalam keadaan. `INACTIVE`
Ketika [`pcluster start`](pcluster.start.md) dijalankan, semua partisi awalnya ditempatkan di `UP` negara bagian. 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. Jika [`initial_count`](compute-resource-section.md#compute-resource-initial-count) lebih besar dari[`max_count`](compute-resource-section.md#compute-resource-max-count), maka [`initial_count`](compute-resource-section.md#compute-resource-initial-count) mungkin tidak puas ketika status partisi diubah ke `UP` status.
Kapan [`pcluster start`](pcluster.start.md) dan [`pcluster stop`](pcluster.stop.md) sedang berjalan, Anda dapat memeriksa status cluster dengan menjalankan [`pcluster status`](pcluster.status.md) perintah dan memeriksa`ComputeFleetStatus`. Berikut daftar kemungkinan status:
+ `STOP_REQUESTED`: [`pcluster stop`](pcluster.stop.md) Permintaan dikirim ke cluster.
+ `STOPPING`: `pcluster` Proses saat ini menghentikan cluster.
+ `STOPPED`: `pcluster` Proses menyelesaikan proses penghentian, semua partisi dalam `INACTIVE` keadaan, dan semua instance komputasi dihentikan.
+ `START_REQUESTED`: [`pcluster start`](pcluster.start.md) Permintaan dikirim ke cluster.
+ `STARTING`: `pcluster` Proses saat ini memulai cluster
+ `RUNNING`: `pcluster` Proses menyelesaikan proses awal, semua partisi dalam `UP` keadaan, dan node statis akan tersedia setelah beberapa menit.
## Kontrol manual pada antrian
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.
+ Nyalakan node dinamis dalam `POWER_SAVING` status: Jalankan `scontrol update nodename=nodename state=power_up` perintah atau kirimkan `sleep 1` pekerjaan placeholder yang meminta sejumlah node tertentu dan mengandalkan Slurm untuk meningkatkan jumlah node yang diperlukan.
+ Matikan node dinamis sebelumnya[`scaledown_idletime`](scaling-section.md#scaledown-idletime): Atur node dinamis `DOWN` dengan `scontrol update nodename=nodename state=down` perintah. AWS ParallelCluster secara otomatis mengakhiri dan me-reset node dinamis yang jatuh. Secara umum, kami tidak menyarankan pengaturan node untuk `POWER_DOWN` langsung menggunakan `scontrol update nodename=nodename state=power_down` perintah. Ini karena AWS ParallelCluster secara otomatis menangani proses power down. Tidak diperlukan intervensi manual. Oleh karena itu, kami menyarankan Anda mencoba mengatur node `DOWN` kapan pun memungkinkan.
+ Nonaktifkan antrian (partisi) atau hentikan semua node statis di partisi tertentu: Tetapkan antrian tertentu `INACTIVE` dengan perintah. `scontrol update partition=queue name state=inactive` Melakukan hal ini mengakhiri semua instance backing node di partisi.
+ Aktifkan antrian (partisi): Tetapkan antrian tertentu `INACTIVE` dengan perintah. `scontrol update partition=queue name 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-c5xlarge-[1-2]`).
+ `ResumeProgram`meluncurkan dua instans EC2 dan menetapkan alamat IP pribadi dan nama host dari`queue1-dy-c5xlarge-[1-2]`, menunggu `ResumeTimeout` (periode default adalah 60 menit (1 jam)) sebelum mengatur ulang node.
+ Instans dikonfigurasi dan bergabung dengan cluster. Job mulai berjalan pada instance.
+ Job sudah selesai.
+ Setelah konfigurasi `SuspendTime` telah berlalu (yang diatur ke[`scaledown_idletime`](scaling-section.md#scaledown-idletime)), instance dimasukkan ke `POWER_SAVING` status oleh penjadwal. Scheduler menempatkan `queue1-dy-c5xlarge-[1-2]` ke `POWER_DOWN` status dan panggilan `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, mengkonfigurasi `queue1-dy-c5xlarge-[1-2]` ke dalam keadaan idle dan mengatur ulang alamat IP pribadi dan nama host sehingga mereka dapat diaktifkan untuk pekerjaan masa depan lagi.
Sekarang, jika ada yang salah dan instance untuk node tertentu tidak dapat diluncurkan karena alasan tertentu, maka hal berikut terjadi.
+ Scheduler menerima pekerjaan yang membutuhkan dua node.
+ Scheduler menempatkan dua node cloud bursting ke `POWER_UP` status dan memanggil `ResumeProgram` dengan nama node, (misalnya). `queue1-dy-c5xlarge-[1-2]`
+ `ResumeProgram`meluncurkan hanya satu (1) instans EC2 dan mengkonfigurasi`queue1-dy-c5xlarge-1`, tetapi gagal meluncurkan instance untuk. `queue1-dy-c5xlarge-2`
+ `queue1-dy-c5xlarge-1`tidak akan terpengaruh dan akan online setelah mencapai `POWER_UP` negara bagian.
+ `queue1-dy-c5xlarge-2`ditempatkan dalam `POWER_DOWN` keadaan, dan pekerjaan diminta ulang secara otomatis karena Slurm mendeteksi kegagalan node.
+ `queue1-dy-c5xlarge-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 diulang sampai pekerjaan dapat berjalan pada node yang tersedia tanpa terjadi kegagalan.
Ada dua parameter waktu yang dapat disesuaikan jika diperlukan.
+ `ResumeTimeout`(defaultnya adalah 60 menit (1 jam)): `ResumeTimeout` mengontrol waktu Slurm menunggu sebelum meletakkan node status down.
+ Mungkin berguna untuk memperpanjang ini jika proses pre/post instalasi Anda memakan waktu hampir selama itu.
+ Ini juga merupakan waktu maksimum yang AWS ParallelCluster menunggu sebelum mengganti atau mengatur ulang node jika ada masalah. Menghitung node berhenti sendiri jika terjadi kesalahan selama peluncuran atau penyiapan. Selanjutnya, AWS ParallelCluster proses juga menggantikan node ketika melihat bahwa instance 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 bahwa node akan diatur ulang lebih cepat, dan Slurm dapat mencoba meluncurkan instance lebih sering.
+ `SuspendTimeout`Yang lebih lama membuat node yang gagal diatur ulang lebih lambat. Sementara itu, Slurm ban menggunakan node lain. Jika `SuspendTimeout` lebih dari beberapa menit, cobalah Slurm untuk menelusuri semua node dalam sistem. Yang lebih lama `SuspendTimeout` mungkin bermanfaat untuk sistem skala besar (lebih dari 1.000 node) untuk mengurangi stres Slurm dengan 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 beberapa menit. Namun, selama waktu ini, node tetap dalam keadaan mati daya dan tidak tersedia untuk digunakan dalam penjadwal.
## Log untuk arsitektur baru
Lit berikut berisi log kunci untuk arsitektur antrian ganda. Nama aliran log yang digunakan dengan Amazon CloudWatch Logs memiliki format`{hostname}.{instance_id}.{logIdentifier}`, di mana *logIdentifier* mengikuti nama log. Untuk informasi selengkapnya, lihat [Integrasi dengan Amazon CloudWatch Logs](cloudwatch-logs.md).
+ `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` pernah dipanggil dengan node. Jika tidak, periksa `slurmctld` log untuk menentukan apakah Slurm pernah 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 dapat 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 tidak, harus ada kesalahan yang jelas tentang mengapa instance gagal diluncurkan.
+ Jika sebuah instance diluncurkan, ada beberapa masalah selama 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, kegagalan node**
+ Node secara replaced/terminated 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 tersebut. Jika alasannya terkait penjadwal (misalnya, simpulnya`DOWN`), periksa `slurmctld` log untuk lebih jelasnya. Jika alasannya terkait EC2, gunakan alat untuk memeriksa status atau log untuk contoh itu. Misalnya, Anda dapat memeriksa apakah instans memiliki acara terjadwal atau gagal pemeriksaan status kesehatan 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 analisis 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[`scaledown_idletime`](scaling-section.md#scaledown-idletime), lihat di `SuspendProgram` log untuk melihat apakah sebuah program `slurmctld` dengan node tertentu sebagai argumen. Catatan `SuspendProgram` tidak benar-benar melakukan tindakan tertentu. Sebaliknya, itu hanya log ketika dipanggil. Semua penghentian dan `NodeAddr` reset instans diselesaikan oleh`clustermgtd`. Slurmmenempatkan node ke dalam `IDLE` setelah`SuspendTimeout`.
**Masalah lainnya**
+ AWS ParallelCluster tidak membuat alokasi pekerjaan atau keputusan penskalaan. Sederhana mencoba 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.