View a markdown version of this page

Slurry panduan untuk beberapa mode antrian - AWS ParallelCluster
Gambaran umumSiklus hidup simpul cloudBekerja dengan node yang tersediaStatus pekerjaan dan pengajuanStatus simpul dan fiturStatus partisipcluster mulai dan berhentiKontrol manual pada antrianPerilaku dan penyesuaian penskalaanLog untuk arsitektur baruMasalah umum dan cara men-debug:

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Slurry panduan 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.

Gambaran umum

Arsitektur penskalaan baru didasarkan pada Slurm Panduan Penjadwalan Cloud dan plugin hemat daya. Untuk informasi selengkapnya tentang plugin hemat daya, lihat Panduan Slurm Penghematan Daya. Dalam arsitektur baru, sumber daya yang berpotensi tersedia untuk cluster biasanya ditentukan sebelumnya dalam Slurm konfigurasi sebagai node cloud.

Siklus hidup simpul cloud

Sepanjang siklus hidupnya, node cloud memasukkan beberapa jika tidak semua status berikut:POWER_SAVING, POWER_UP (pow_up), ALLOCATED (alloc), dan POWER_DOWN (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 akh ~ iran (misalnyaidle~) disinfo. Dalam keadaan ini, tidak ada instance EC2 yang mendukung node. Namun, masih Slurm dapat mengalokasikan pekerjaan ke node.

  • Sebuah node yang bertransisi ke POWER_UP status muncul dengan akh # iran (misalnyaidle#) di. sinfo

  • Ketika Slurm mengalokasikan pekerjaan ke node dalam POWER_SAVING keadaan, node secara otomatis mentransfer ke status. POWER_UP Jika tidak, node dapat ditempatkan dalam POWER_UP status 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 (misalnyaidle) disinfo. 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 menyarankan agar jumlah instance di EC2 sama dengan jumlah node yang tersedia. Dalam kebanyakan kasus, node statis selalu tersedia setelah cluster dibuat.

  • Sebuah node yang sedang bertransisi ke POWER_DOWN status muncul dengan akh % iran (misalnyaidle%) di. sinfo Node dinamis secara otomatis memasuki POWER_DOWN status setelahnyascaledown_idletime. Sebaliknya, node statis dalam banyak kasus tidak dimatikan. Namun, node dapat ditempatkan dalam POWER_DOWN status 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 status untuk digunakan di POWER_SAVING masa mendatang setelahnyascaledown_idletime. Peng scaledown-idletime aturan disimpan ke Slurm konfigurasi sebagai SuspendTimeout pengaturan.

  • Node yang offline muncul dengan akh * iran (misalnyadown*) disinfo. Node menjadi offline jika Slurm pengontrol tidak dapat menghubungi node atau jika node statis dinonaktifkan dan instance pendukung 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-1N spot-st-t2large-[1-2] ode dan sudah memiliki instans cadangan yang disiapkan dan tersedia untuk digunakan. N ondemand-dy-c52xlarge-[1-2] ode berada di POWER_UP negara bagian, dan mereka harus tersedia dalam beberapa menit. N gpu-dy-g38xlarge-1 ode berada dalam POWER_DOWN keadaan, dan akan beralih ke POWER_SAVING status setelahnya scaledown_idletime (default ke 120 detik).

Semua node lain dalam POWER_SAVING keadaan tanpa instans 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 (misalnyassh 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 menunjuk ke instans 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 dalam penundaan jika semua node dialokasikan.

Jika node yang dialokasikan untuk pekerjaan menyertakan node apa pun dalam POWER_SAVING status, pekerjaan dimulai denganCF, atau CONFIGURING state. Pada saat ini, pekerjaan menunggu node dalam status untuk POWER_SAVING beralih ke POWER_UP status dan menjadi tersedia.

Setelah semua node yang dialokasikan untuk pekerjaan tersedia, pekerjaan memasuki RUNNING status (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:

  • Jenis instance (misalnyac5.xlarge)

  • Jenis simpul (Ini adalah salah satu dynamic ataustatic.)

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 itu spot adalah antrian default. Hal ini ditunjukkan oleh akh * iran.

Mengirimkan pekerjaan ke satu node statis ke antrean default (spot).

$ sbatch --wrap "sleep 300" -N 1 -C static

Kirim pekerjaan ke satu node dinamis ke an EFA trian.

$ 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 an efa trian spot dan) sudah berjalan (R). Jobs 12 dan 13 masih mengkonfigurasi (CF), mungkin menunggu instans 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 simpul dan fitur

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 mengganti atau menghentikan node yang tidak sehat di DOWN dan status dan DRAINED node yang memiliki instance pendukung yang tidak sehat. Untuk informasi selengkapnya, lihat clustermgtd.

Status partisi

AWS ParallelCluster mendukung status partisi berikut. SlurmPartisi adalah antrian dalam AWS ParallelCluster.

  • UP: Menunjukkan bahwa partisi dalam keadaan aktif. Ini adalah status default dari sebuah 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 yang mendukung node dari partisi tidak aktif dihentikan. Instans baru tidak diluncurkan untuk node dalam partisi tidak aktif.

pcluster mulai dan berhenti

Ketika pcluster stop dijalankan, semua partisi ditempatkan dalam INACTIVE status, dan AWS ParallelCluster proses menjaga partisi dalam INACTIVE status.

Ketika pcluster start 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 tersedia setelah beberapa menit. Perhatikan bahwa menyetel partisi ke UP tidak menyalakan kapasitas dinamis apa pun. Jika initial_count lebih besar darimax_count, maka initial_count mungkin tidak terpenuhi ketika status partisi diubah menjadi UP status.

Saat pcluster start dan pcluster stop sedang berjalan, Anda dapat memeriksa keadaan cluster dengan menjalankan pcluster status perintah dan memeriksaComputeFleetStatus. Berikut daftar kemungkinan status:

  • STOP_REQUESTED: pcluster stop Permintaan dikirim ke cluster.

  • STOPPING: pcluster Proses saat ini menghentikan cluster.

  • STOPPED: Proses pcluster menyelesaikan proses penghentian, semua partisi dalam INACTIVE keadaan, dan semua instance komputasi dihentikan.

  • START_REQUESTED: pcluster start Permintaan dikirim ke cluster.

  • STARTING: pcluster Proses saat ini sedang 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 cluster. Anda dapat mengelola node dalam cluster melalui prosedur umum berikut.

  • Nyalakan node dinamis dalam POWER_SAVING status: J scontrol update nodename=nodename state=power_up alankan perintah atau kirimkan sleep 1 pekerjaan placeholder yang meminta sejumlah node tertentu dan andalkan Slurm untuk menyalakan jumlah node yang diperlukan.

  • Matikan node dinamis sebelumnyascaledown_idletime: Atur node dinamis ke DOWN dengan scontrol update nodename=nodename state=down perintah. AWS ParallelCluster secara otomatis mengakhiri dan mengatur ulang node dinamis yang diturunkan. Secara umum, kami tidak merekomendasikan pengaturan node untuk POWER_DOWN langsung menggunakan scontrol update nodename=nodename state=power_down perintah. Ini karena AWS ParallelCluster secara otomatis menangani proses pemadaman daya. Tidak diperlukan intervensi manual. Oleh karena itu, kami sarankan Anda mencoba mengatur node ke DOWN bila memungkinkan.

  • Nonaktifkan antrian (partisi) atau hentikan semua node statis di partisi tertentu: Atur antrian spesifik INACTIVE dengan scontrol update partition=queue name state=inactive perintah. Melakukan hal ini mengakhiri semua instance yang mendukung node di partisi.

  • Aktifkan antrian (partisi): Atur antrian spesifik INACTIVE dengan scontrol update partition=queue name state=up perintah.

Perilaku dan penyesuaian penskalaan

Berikut adalah contoh alur kerja penskalaan normal:

  • Penjadwal menerima pekerjaan yang membutuhkan dua node.

  • Penjadwal mentransisi dua node ke POWER_UP status, dan memang ResumeProgram gil dengan nama node (misalnyaqueue1-dy-c5xlarge-[1-2]).

  • ResumeProgrammeluncurkan dua instance EC2 dan menetapkan alamat IP pribadi dan nama hostqueue1-dy-c5xlarge-[1-2], menunggu ResumeTimeout (periode default adalah 60 menit (1 jam)) sebelum mengatur ulang node.

  • Instans dikonfigurasi dan bergabung dengan cluster. Pekerjaan mulai berjalan pada instance.

  • Pekerjaan sudah selesai.

  • Setelah konfigurasi SuspendTime telah berlalu (yang disetel kescaledown_idletime), instance dimasukkan ke dalam POWER_SAVING status oleh penjadwal. Penjadwal menempatkan queue1-dy-c5xlarge-[1-2] ke POWER_DOWN status dan memanggil SuspendProgram dengan nama node.

  • SuspendProgramdisebut untuk dua node. Node tetap dalam POWER_DOWN keadaan, misalnya, dengan tetap idle% selama SuspendTimeout (periode default adalah 120 detik (2 menit)). Setelah clustermgtd mendeteksi bahwa node dimatikan, itu mengakhiri instance pendukung. Kemudian, ia mengonfigurasi queue1-dy-c5xlarge-[1-2] ke keadaan idle dan mengatur ulang alamat IP pribadi dan nama host sehingga mereka dapat dinyalakan untuk pekerjaan di masa mendatang lagi.

Sekarang, jika terjadi kesalahan 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 cloud bursting node ke POWER_UP status dan memanggil ResumeProgram dengan nama node, (misalnya). queue1-dy-c5xlarge-[1-2]

  • ResumeProgramhanya meluncurkan satu (1) instans EC2 dan mengonfigur queue1-dy-c5xlarge-1 asi, tetapi gagal meluncurkan instance untuk. queue1-dy-c5xlarge-2

  • queue1-dy-c5xlarge-1tidak akan terpengaruh dan akan online setelah mencapai POWER_UP negara bagian.

  • queue1-dy-c5xlarge-2ditempatkan dalam POWER_DOWN status, dan pekerjaan diminta secara otomatis karena Slurm mendeteksi kegagalan node.

  • queue1-dy-c5xlarge-2menjadi tersedia setelah SuspendTimeout (defaultnya adalah 120 detik (2 menit)). Sementara itu, pekerjaan diperlukan dan dapat mulai berjalan di node lain.

  • Proses di atas diulang sampai pekerjaan dapat berjalan pada node yang tersedia tanpa kegagalan terjadi.

Ada dua parameter waktu yang dapat disesuaikan jika diperlukan.

  • ResumeTimeout(default Slurm nya adalah 60 menit (1 jam)): ResumeTimeout mengontrol waktu menunggu sebelum menempatkan node ke 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. Node komputasi dihentikan 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.

    • Yang lebih lama SuspendTimeout membuat node yang gagal diatur ulang lebih lambat. Sementara itu, Slurm ban menggunakan node lain. Jika SuspendTimeout lebih dari beberapa menit, Slurm coba putar melalui semua node dalam sistem. Lebih lama SuspendTimeout mungkin bermanfaat bagi sistem skala besar (lebih dari 1.000 node) untuk mengurangi stres Slurm dengan sering mengantri ulang pekerjaan yang gagal.

    • Perhatikan bahwa itu SuspendTimeout tidak mengacu pada waktu AWS ParallelCluster menunggu untuk menghentikan instance pendukung untuk node. Instans pendukung untuk power down node segera dihentikan. Proses penghentian biasanya selesai beberapa menit. Namun, selama waktu ini, node tetap dalam keadaan mati dan tidak tersedia untuk digunakan di 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.

  • 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 meluncurkan, menghidupkan, atau bergabung dengan cluster:

  • Node dinamis:

    • Periksa ResumeProgram log untuk melihat apakah pernah ResumeProgram dipanggil dengan node. Jika tidak, periksa slurmctld log untuk menentukan apakah Slurm pernah mencoba menelep ResumeProgram on dengan node. Perhatikan bahwa izin yang salah dapat ResumeProgram 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 tidak terduga, kegagalan node

  • Node secara replaced/terminated tak terduga

    • Dalam kebanyakan kasus, clustermgtd menangani semua tindakan pemeliharaan node. Untuk memeriksa apakah node clustermgtd diganti atau dihentikan, periksa clustermgtd log.

    • Jika clustermgtd diganti atau dihentikan node, harus ada pesan yang menunjukkan alasan tindakan. Jika alasannya terkait penjadwal (misalnya, simpul ituDOWN), periksa slurmctld log untuk detail lebih lanjut. Jika alasannya terkait EC2, gunakan alat untuk memeriksa status atau log untuk contoh itu. Misalnya, Anda dapat memeriksa apakah instans memiliki kejadian terjadwal atau pemeriksaan status kesehatan EC2 yang gagal.

    • Jika clustermgtd tidak menghentikan node, periksa apakah node computemgtd dihentikan atau apakah EC2 menghentikan instance untuk merebut kembali Instans Spot.

  • Kegagalan simpul

    • Dalam kebanyakan kasus, pekerjaan secara otomatis diminta jika node gagal. Lihat di slurmctld log untuk melihat mengapa pekerjaan atau node gagal dan analisis situasi dari sana.

Kegagalan saat mengganti atau mengakhiri instance, kegagalan saat mematikan node

  • Secara umum, clustermgtd menangani semua tindakan penghentian instans yang diharapkan. Lihat di clustermgtd log untuk melihat mengapa gagal mengganti atau menghentikan node.

  • Untuk node dinamis gagalscaledown_idletime, lihat di SuspendProgram log untuk melihat apakah sebuah program slurmctld menggunakan node tertentu sebagai argumen. Catatan sebenarnya SuspendProgram tidak melakukan tindakan spesifik apa pun. Sebaliknya, itu hanya mencatat ketika dipanggil. Semua penghentian dan NodeAddr pengaturan ulang instance diselesaikan olehclustermgtd. Slurmmenempatkan node ke set IDLE elahnyaSuspendTimeout.

Masalah lainnya

  • AWS ParallelCluster tidak membuat alokasi pekerjaan atau keputusan penskalaan. Ini sederhana mencoba untuk meluncurkan, menghentikan, dan memelihara sumber daya sesuai Slurm dengan instruksi.

    Untuk masalah mengenai alokasi pekerjaan, alokasi node, dan keputusan penskalaan, lihat slurmctld log untuk kesalahan.