Slurry panduan untuk beberapa mode antrian

• Sebuah node dalam POWER_SAVING keadaan muncul dengan akh ~ iran (misalnyaidle~) disinfo. Dalam keadaan ini, tidak ada instans 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 Sebuah node secara otomatis bertransisi ke POWER_UP status, ketika Slurm mengalokasikan pekerjaan ke node dalam keadaanPOWER_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, instance EC2 diluncurkan dan dikonfigurasi, dan transisi node ke POWER_UP status.

• Node yang saat ini tersedia untuk digunakan muncul tanpa akhiran (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 instans Amazon EC2 sama dengan jumlah node yang tersedia. Dalam kebanyakan kasus, node statis 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 setelahnya ScaledownIdletime. Sebaliknya, node statis dalam banyak kasus tidak dimatikan. Namun, Anda dapat menempatkan node dalam POWER_DOWN status 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.

  Peng ScaledownIdletime aturan disimpan ke SuspendTimeout pengaturan Slurm konfigurasi.

• Node yang offline muncul dengan akh * iran (misalnyadown*) disinfo. Node menjadi offline jika peng Slurm ontrol tidak dapat menghubungi node atau jika node statis dinonaktifkan dan instance pendukung dihentikan.

• Jenis instance (misalnyac5.xlarge)

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

• 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.

• Menghentikan armada kom putasi - Ketika perintah berikut dijalankan, semua partisi beralih ke INACTIVE status, dan AWS ParallelCluster proses menjaga partisi tetap dalam INACTIVE status.

  $ pcluster update-compute-fleet --cluster-name testSlurm \
     --region eu-west-1 --status STOP_REQUESTED

• Memulai armada komput asi - Ketika perintah berikut dijalankan, semua partisi awalnya beralih ke UP status. 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 mengatur partisi ke UP tidak menyalakan kapasitas dinamis apa pun.

  $ pcluster update-compute-fleet --cluster-name testSlurm \
     --region eu-west-1 --status START_REQUESTED

• STOP_REQUESTED: Permintaan armada penghentian komputasi dikirim ke cluster.

• STOPPING: pcluster Proses saat ini menghentikan armada komputasi.

• STOPPED: Proses pcluster 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 sedang 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 terkena dampak tidak aktif. Silakan selidiki masalah ini dan kemudian jalankan update-compute-fleet untuk mengaktifkan kembali armada.

• Nyalakan node dinamis dalam POWER_SAVING status

  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

  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 mengatur ulang node dinamis yang diturunkan.

  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 INACTIVE sebagai pengguna su root dengan perintah:

  $ scontrol update partition=queuename state=inactive

  Melakukan hal ini mengakhiri semua instance yang mendukung node di partisi.

• Aktifkan antrian (partisi)

  Tetapkan antrian tertentu ke UP pengguna su root dengan perintah:

  $ scontrol update partition=queuename state=up

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-spotcompute1-[1-2]).

• ResumeProgrammeluncurkan dua instans Amazon EC2 dan menetapkan alamat IP pribadi dan nama host dariqueue1-dy-spotcompute1-[1-2], menunggu ResumeTimeout (periode default adalah 30 menit sebelum mengatur ulang node.

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

• Pekerjaan selesai dan berhenti berjalan.

• Setelah konfigurasi SuspendTime telah berlalu (yang disetel ke ScaledownIdletime), penjadwal menetapkan instance ke POWER_SAVING status. Penjadwal kemudian mengatur queue1-dy-spotcompute1-[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 mati, itu mengakhiri instance pendukung. Kemudian, ia beralih queue1-dy-spotcompute1-[1-2] ke status idle dan mengatur ulang alamat IP pribadi dan nama host sehingga siap untuk dinyalakan untuk pekerjaan di masa mendatang.

Jika terjadi kesalahan dan instance untuk node tertentu tidak dapat diluncurkan karena alasan tertentu, maka hal berikut terjadi:

• Penjadwal menerima pekerjaan yang membutuhkan dua node.

• Penjadwal mentransisi dua node cloud bursting ke POWER_UP status dan memanggil ResumeProgram dengan nama simpul, (misalnya). queue1-dy-spotcompute1-[1-2]

• ResumeProgramhanya meluncurkan satu (1) instans Amazon EC2 dan mengonfigurasiqueue1-dy-spotcompute1-1, dengan satu (1) instansqueue1-dy-spotcompute1-2, gagal diluncurkan.

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

• queue1-dy-spotcompute1-2transisi ke POWER_DOWN status, dan pekerjaan diminta secara otomatis karena Slurm mendeteksi kegagalan node.

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

• Proses di atas berulang 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 30 menit): ResumeTimeout mengontrol waktu tunggu sebelum mentransisikan node ke status down.

  • Mungkin berguna untuk memperpanjang ResumeTimeout jika proses pre/post instalasi Anda memakan waktu hampir selama itu.

  • ResumeTimeoutjuga 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. AWS ParallelCluster proses menggantikan node setelah 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.

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

  • Perhatikan bahwa SuspendTimeout itu tidak mengacu pada waktu AWS ParallelCluster menunggu untuk mengakhiri instance pendukung untuk node. Instans 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.

• 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)

• Node dinamis:

  • Periksa ResumeProgram log untuk melihat apakah ResumeProgram dipanggil dengan node. Jika tidak, periksa slurmctld log untuk menentukan apakah Slurm 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 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 replaced/terminated secara 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 Amazon EC2, gunakan alat seperti Amazon CloudWatch atau konsol Amazon EC2, CLI, atau SDK, untuk memeriksa status atau log untuk contoh tersebut. Misalnya, Anda dapat memeriksa apakah instans memiliki kejadian yang dijadwalkan atau gagal dalam pemeriksaan status kesehatan Amazon EC2.

  • 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 menilai situasi dari sana.

• 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 ScaledownIdletime yang gagal, lihat di SuspendProgram log untuk melihat apakah slurmctld proses melakukan panggilan dengan node tertentu sebagai argumen. Catatan sebenarnya SuspendProgram tidak melakukan tindakan tertentu. Sebaliknya, itu hanya mencatat ketika dipanggil. Semua penghentian dan NodeAddr pengaturan ulang instance diselesaikan olehclustermgtd. Slurmtransisi node ke set IDLE elahnyaSuspendTimeout.

• AWS ParallelCluster tidak membuat alokasi pekerjaan atau keputusan penskalaan. Itu hanya mencoba 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.