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.

Gambaran Umum

Arsitektur penskalaan didasarkan pada Slurm Panduan Penjadwalan Cloud dan plugin hemat daya. Untuk informasi selengkapnya tentang plugin hemat daya, lihat Panduan Penghematan Slurm Daya. 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 (allocpow_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 (misalnyaidle~) disinfo. 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 (misalnyaidle#) 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 (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 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 (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 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

  ScaledownIdletimePengaturan disimpan ke SuspendTimeout pengaturan Slurm konfigurasi.

• Node yang offline muncul dengan * akhiran (misalnyadown*) disinfo. 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-1Node 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-1Node dalam POWER_DOWN keadaan, dan transisi ke POWER_SAVING keadaan setelah 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 (misalnyassh 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 denganCF, 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 (misalnyac5.xlarge)

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

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.

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 yang 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 status, 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 memeriksaStatus. 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

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

• ResumeProgrammeluncurkan 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), 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.

• SuspendProgramdisebut 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]

• ResumeProgrammeluncurkan hanya satu (1) instans Amazon EC2 dan queue1-dy-spotcompute1-1 mengonfigurasi, dengan satu (1) instancequeue1-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 ulang secara otomatis karena Slurm mendeteksi kegagalan node.

• queue1-dy-spotcompute1-2menjadi 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 instalasi pra/pasca Anda memakan waktu hampir selama itu.

  • ResumeTimeoutjuga 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 diganti/dihentikan 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 tersebut. Jika alasannya terkait penjadwal (misalnya, simpulnyaDOWN), 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 sebuah 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, 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 olehclustermgtd. Slurmtransisi node ke IDLE setelahnyaSuspendTimeout.

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.