Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Penjadwal didukung oleh AWS ParallelCluster AWS ParallelCluster dukungan Slurm dan AWS Batch penjadwal, yang diatur menggunakan pengaturan. [`Scheduler`](Scheduling-v3.md#yaml-Scheduling-Scheduler) Topik berikut akan menjelaskan setiap penjadwal dan cara menggunakannya. **Topics** + [Slurm Workload Manager (`slurm`)](slurm-workload-manager-v3.md) + [Menggunakan AWS Batch (`awsbatch`) scheduler dengan AWS ParallelCluster](awsbatchcli-v3.md) # Slurm Workload Manager (`slurm`) ## Ukuran dan pembaruan kapasitas cluster Kapasitas cluster ditentukan oleh jumlah node komputasi yang dapat diskalakan oleh cluster. Node komputasi didukung oleh instans Amazon EC2 yang ditentukan dalam sumber daya komputasi dalam `(Scheduling/SlurmQueues/`ComputeResources`)` konfigurasi, dan diatur ke dalam AWS ParallelCluster `(Scheduling/SlurmQueues)` antrian yang memetakan 1:1 ke partisi. Slurm [Dalam sumber daya komputasi, dimungkinkan untuk mengonfigurasi jumlah minimum node komputasi (instance) yang harus selalu berjalan di cluster (`MinCount`), dan jumlah maksimum instance yang dapat diskalakan oleh sumber daya komputasi ke (3). `MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount) Pada waktu pembuatan klaster, atau pada pembaruan klaster, AWS ParallelCluster meluncurkan instans Amazon EC2 sebanyak yang dikonfigurasi untuk setiap sumber daya komputasi `Scheduling/SlurmQueues/ ComputeResources` () yang ditentukan `MinCount` dalam klaster. Instance yang diluncurkan untuk mencakup jumlah minimal node untuk sumber daya komputasi di cluster disebut node ***statis***. Setelah dimulai, node statis dimaksudkan untuk persisten di cluster dan mereka tidak dihentikan oleh sistem, kecuali peristiwa atau kondisi tertentu terjadi. Peristiwa tersebut termasuk, misalnya, kegagalan Slurm atau pemeriksaan kesehatan Amazon EC2 dan perubahan status Slurm node menjadi DRAIN atau DOWN. ***Instans Amazon EC2, dalam kisaran `1` hingga `‘MaxCount - MinCount’` (`MaxCount `*minus*` MinCount)`, diluncurkan sesuai permintaan untuk menangani peningkatan beban cluster, disebut sebagai node dinamis.*** Sifat mereka fana, mereka diluncurkan untuk melayani pekerjaan yang tertunda dan dihentikan setelah mereka tetap menganggur untuk jangka waktu yang ditentukan oleh `Scheduling/SlurmSettings/ScaledownIdletime` dalam konfigurasi cluster (default: 10 menit). Node statis dan simpul dinamis mematuhi skema penamaan berikut: + Node statis `-st--` di mana ` = 1..ComputeResource/MinCount` + Node dinamis `-dy--` di mana ` = 1..(ComputeResource/MaxCount - ComputeResource/MinCount)` Misalnya diberikan AWS ParallelCluster konfigurasi berikut: ``` Scheduling: Scheduler: Slurm SlurmQueues: - Name: queue1 ComputeResources: - Name: c5xlarge Instances: - InstanceType: c5.xlarge MinCount: 100 MaxCount: 150 ``` Node berikut akan didefinisikan dalam Slurm ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50] queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100] ``` Ketika sumber daya komputasi memiliki`MinCount == MaxCount`, semua node komputasi yang sesuai akan statis dan semua instance akan diluncurkan pada creation/update waktu cluster dan terus berjalan. Contoh: ``` Scheduling: Scheduler: slurm SlurmQueues: - Name: queue1 ComputeResources: - Name: c5xlarge Instances: - InstanceType: c5.xlarge MinCount: 100 MaxCount: 100 ``` ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100] ``` ## Pembaruan kapasitas cluster Pembaruan kapasitas cluster termasuk menambahkan atau menghapus antrian, menghitung sumber daya atau mengubah sumber daya komputasi. `MinCount/MaxCount` Mulai dari AWS ParallelCluster versi 3.9.0, mengurangi ukuran antrian memerlukan armada komputasi dihentikan atau [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)disetel ke TERMINATE sebelum pembaruan klaster berlangsung. Tidak perlu menghentikan armada komputasi atau menyetel [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)ke TERMINATE saat: + Menambahkan antrian baru ke Penjadwalan/[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) + Menambahkan sumber daya komputasi baru `Scheduling/SlurmQueues/ComputeResources` ke antrian + Meningkatkan `MaxCount` sumber daya komputasi + Peningkatan MinCount sumber daya komputasi dan peningkatan MaxCount sumber daya komputasi yang sama setidaknya dengan jumlah yang sama ## Pertimbangan dan batasan Bagian ini dimaksudkan untuk menguraikan faktor penting, kendala, atau batasan yang harus diperhitungkan saat mengubah ukuran kapasitas cluster. + Saat menghapus antrian dari `Scheduling/SlurmQueues` semua node komputasi dengan nama`-*`, baik statis maupun dinamis, akan dihapus dari Slurm konfigurasi dan instans Amazon EC2 yang sesuai akan dihentikan. + Saat menghapus sumber daya komputasi `Scheduling/SlurmQueues/ComputeResources` dari antrian, semua node komputasi dengan nama`-*--*`, baik statis maupun dinamis, akan dihapus dari Slurm konfigurasi dan instans Amazon EC2 yang sesuai akan dihentikan. Ketika mengubah `MinCount` parameter sumber daya komputasi kita dapat membedakan dua skenario yang berbeda, jika `MaxCount` tetap sama dengan `MinCount` (kapasitas statis saja), dan jika `MaxCount` lebih besar dari `MinCount` (kapasitas statis dan dinamis campuran). ### Perubahan kapasitas hanya dengan node statis + Jika`MinCount == MaxCount`, saat meningkatkan `MinCount` (dan`MaxCount`), cluster akan dikonfigurasi dengan memperluas jumlah node statis ke nilai baru `MinCount` `-st--` dan sistem akan terus mencoba meluncurkan instans Amazon EC2 untuk memenuhi kapasitas statis baru yang diperlukan. + Jika`MinCount == MaxCount`, saat mengurangi `MinCount` (dan`MaxCount`) jumlah N, cluster akan dikonfigurasi dengan menghapus node statis N terakhir `-st--...]` dan sistem akan menghentikan instans Amazon EC2 yang sesuai. + Keadaan awal `MinCount = MaxCount = 100` + ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100] ``` + Update `-30` pada `MinCount` dan `MaxCount: MinCount = MaxCount = 70` + ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70] ``` ### Perubahan kapasitas dengan node campuran Jika`MinCount < MaxCount`, ketika meningkat `MinCount` dengan jumlah N (dengan asumsi `MaxCount` akan tetap tidak berubah), cluster akan dikonfigurasi dengan memperluas jumlah node statis ke nilai baru `MinCount` (`old_MinCount + N`): `-st--` dan sistem akan terus mencoba meluncurkan instans Amazon EC2 untuk memenuhi kapasitas statis baru yang diperlukan. Selain itu, untuk menghormati `MaxCount` kapasitas sumber daya komputasi, konfigurasi cluster diperbarui dengan *menghapus node dinamis N terakhir*: `-dy--[...]` dan sistem akan menghentikan instans Amazon EC2 yang sesuai. + Keadaan awal: `MinCount = 100; MaxCount = 150` + ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50] queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100] ``` + Perbarui \$130 ke `MinCount : MinCount = 130 (MaxCount = 150)` + ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20] queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130] ``` Jika`MinCount < MaxCount`, saat meningkatkan `MinCount` dan `MaxCount` dengan jumlah N yang sama, cluster akan dikonfigurasi dengan memperluas jumlah node statis ke nilai baru `MinCount` (`old_MinCount + N`): `-st--` dan sistem akan terus mencoba meluncurkan instans Amazon EC2 untuk memenuhi kapasitas statis baru yang diperlukan. Selain itu, tidak ada perubahan yang akan dilakukan pada jumlah node dinamis untuk menghormati yang baru `MaxCount`nilai. + Keadaan awal: `MinCount = 100; MaxCount = 150` + ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50] queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100] ``` + Perbarui \$130 ke `MinCount : MinCount = 130 (MaxCount = 180)` + ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-50] queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130] ``` Jika`MinCount < MaxCount`, ketika mengurangi `MinCount` jumlah N (dengan asumsi `MaxCount` akan tetap tidak berubah), cluster akan dikonfigurasi dengan menghapus node statis N terakhir node statis `-st--[...` dan sistem akan menghentikan instance Amazon EC2 yang sesuai. Selain itu, untuk menghormati `MaxCount` kapasitas sumber daya komputasi, konfigurasi cluster diperbarui dengan memperluas jumlah node dinamis untuk mengisi celah`MaxCount - new_MinCount: -dy--[1..]`. Dalam hal ini, karena itu adalah node dinamis, tidak ada instans Amazon EC2 baru yang akan diluncurkan kecuali penjadwal memiliki pekerjaan di pending pada node baru. + Keadaan awal: `MinCount = 100; MaxCount = 150` + ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50] queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100] ``` + Perbarui -30 pada `MinCount : MinCount = 70 (MaxCount = 120)` + ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-80] queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70] ``` Jika`MinCount < MaxCount`, saat mengurangi `MinCount` dan `MaxCount` dengan jumlah N yang sama, cluster akan dikonfigurasi dengan menghapus node statis N terakhir `-st--...]` dan sistem akan menghentikan instans Amazon EC2 yang sesuai. Selain itu, tidak ada perubahan yang akan dilakukan pada jumlah node dinamis untuk menghormati `MaxCount` nilai baru. + Keadaan awal: `MinCount = 100; MaxCount = 150` + ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50] queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100] ``` + Perbarui -30 pada `MinCount : MinCount = 70 (MaxCount = 120)` + ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-50] queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70] ``` Jika`MinCount < MaxCount`, saat mengurangi `MaxCount` jumlah N (dengan asumsi `MinCount` akan tetap tidak berubah), cluster akan dikonfigurasi dengan menghapus node dinamis N terakhir `-dy--]` dan sistem akan menghentikan instance Amazon EC2 yang sesuai jika mereka berjalan. Tidak ada dampak yang diharapkan pada node statis. + Keadaan awal: `MinCount = 100; MaxCount = 150` + ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50] queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100] ``` + Perbarui -30 pada `MaxCount : MinCount = 100 (MaxCount = 120)` + ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20] queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100] ``` ## Dampak pada Pekerjaan Dalam semua kasus di mana node dihapus dan instans Amazon EC2 dihentikan, pekerjaan sbatch yang berjalan pada node yang dihapus akan diantrian ulang, kecuali tidak ada node lain yang memenuhi persyaratan pekerjaan. Dalam kasus terakhir ini, pekerjaan gagal dengan status NODE\$1FAIL dan menghilang dari antrian dan harus dikirim ulang secara manual. Jika Anda berencana untuk melakukan pembaruan pengubahan ukuran cluster, Anda dapat mencegah pekerjaan berjalan di node yang akan dihapus selama pembaruan yang direncanakan. Ini dimungkinkan dengan mengatur node yang akan dihapus dalam pemeliharaan. Perlu diketahui bahwa menyetel node dalam pemeliharaan tidak akan memengaruhi pekerjaan yang pada akhirnya sudah berjalan di node. Misalkan dengan pembaruan pengubahan ukuran cluster yang direncanakan Anda akan menghapus node`qeueu-st-computeresource-[9-10`]. Anda dapat membuat Slurm reservasi dengan perintah berikut ``` sudo -i scontrol create reservation ReservationName=maint_for_update user=root starttime=now duration=infinite flags=maint,ignore_jobs nodes=qeueu-st-computeresource-[9-10] ``` Ini akan membuat Slurm reservasi bernama `maint_for_update` pada node`qeueu-st-computeresource-[9-10]`. Dari saat reservasi dibuat, tidak ada lagi pekerjaan yang bisa berjalan ke node`qeueu-st-computeresource-[9-10]`. Perlu diketahui bahwa reservasi tidak akan mencegah pekerjaan akhirnya dialokasikan pada node`qeueu-st-computeresource-[9-10]`. Setelah pembaruan pengubahan ukuran klaster, jika Slurm reservasi ditetapkan hanya pada node yang telah dihapus selama pembaruan pengubahan ukuran, reservasi pemeliharaan akan dihapus secara otomatis. Jika sebaliknya Anda telah membuat Slurm reservasi pada node yang masih ada setelah pembaruan pengubahan ukuran cluster, kami mungkin ingin menghapus reservasi pemeliharaan pada node setelah pembaruan pengubahan ukuran dilakukan, dengan menggunakan perintah berikut ``` sudo -i scontrol delete ReservationName=maint_for_update ``` Untuk detail tambahan tentang Slurm reservasi, lihat dokumen SchedMD resmi [di sini](https://slurm.schedmd.com/reservations.html). ## Proses pembaruan klaster tentang perubahan kapasitas Setelah perubahan konfigurasi penjadwal, langkah-langkah berikut dijalankan selama proses pembaruan cluster: + Berhenti AWS ParallelCluster `clustermgtd (supervisorctl stop clustermgtd)` + Hasilkan konfigurasi Slurm partisi yang diperbarui dari AWS ParallelCluster konfigurasi + Mulai ulang `slurmctld` (dilakukan melalui resep layanan Chef) + Periksa `slurmctld` status `(systemctl is-active --quiet slurmctld.service)` + Muat ulang konfigurasi Slurm `(scontrol reconfigure)` + Mulai `clustermgtd (supervisorctl start clustermgtd)` Untuk informasi tentang Slurm, lihat [https://slurm.schedmd.com](https://slurm.schedmd.com). Untuk unduhan, lihat [https://github.com/SchedMD/slurm/tag](https://github.com/SchedMD/slurm/tags). Untuk kode sumbernya, lihat [https://github.com/SchedMD/slurm](https://github.com/SchedMD/slurm). ## Versi cluster dan SLURM yang didukung Tabel berikut mencantumkan AWS ParallelCluster dan Slurm versi yang AWS mendukung. | AWS ParallelCluster versi | SlurmVersi yang didukung | | --- | --- | | 3.13.0 | 24.05.07 | | 3.12.0 | 23.11.10 | | 3.11.0 | 23.11.10 | | 3.9.2, 3.9.3, 3.10.0 | 23.11.7 | | 3.9.0, 3.9.1 | 23.11.4 | | 3.8.0 | 23.02.7 | | 3.7.2 | 23.02.6 | | 3.7.1 | 23.02.5 | | 3.7.0 | 23.02.4 | | 3.6.0, 3.6.1 | 23.02.2 | | 3.5.0, 3.5.1 | 22.05.8 | | 3.4.0, 3.4.1 | 22.05.7 | | 3.3.0, 3.3.1 | 22.05.5 | | 3.1.4, 3.1.5, 3.2.0, 3.2.1 | 21.08.8-2 | | 3.1.2, 3.1.3 | 21.08.6 | | 3.1.1 | 21.08.5 | | 3.0.0 | 20.11.8 | **Topics** + [Ukuran dan pembaruan kapasitas cluster](#cluster-capacity-size-and-update) + [Pembaruan kapasitas cluster](#cluster-capacity-update) + [Pertimbangan dan batasan](#considerations-limitations) + [Dampak pada Pekerjaan](#impacts-on-jobs) + [Proses pembaruan klaster tentang perubahan kapasitas](#cluster-update-process) + [Versi cluster dan SLURM yang didukung](#cluster-slurm-version-table) + [Konfigurasi beberapa antrian](configuration-of-multiple-queues-v3.md) + [Slurmpanduan untuk beberapa mode antrian](multiple-queue-mode-slurm-user-guide-v3.md) + [Slurm mode terlindungi cluster](slurm-protected-mode-v3.md) + [Slurmcluster cepat tidak mencukupi kapasitas fail-over](slurm-short-capacity-fail-mode-v3.md) + [Slurm penjadwalan berbasis memori](slurm-mem-based-scheduling-v3.md) + [Beberapa alokasi tipe instans dengan Slurm](slurm-multiple-instance-allocation-v3.md) + [Penskalaan cluster untuk node dinamis](scheduler-node-allocation-v3.md) + [Slurmakuntansi dengan AWS ParallelCluster](slurm-accounting-v3.md) + [Slurm kustomisasi konfigurasi](slurm-configuration-settings-v3.md) + [Slurm dan `prolog` `epilog`](slurm-prolog-epilog-v3.md) + [Ukuran dan pembaruan kapasitas cluster](slurm-cluster-capacity-size-and-update.md) # Konfigurasi beberapa antrian Dengan AWS ParallelCluster versi 3, Anda dapat mengonfigurasi beberapa antrian dengan mengatur [`Scheduler`](Scheduling-v3.md#yaml-Scheduling-Scheduler)ke `slurm` dan menentukan lebih dari satu antrian untuk [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) dalam file konfigurasi. Dalam mode ini, jenis instance yang berbeda hidup berdampingan dalam node komputasi yang ditentukan di [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) bagian file konfigurasi. [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)dengan jenis instance yang berbeda diskalakan ke atas atau ke bawah sesuai kebutuhan untuk. [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) Beberapa *antrian* dalam satu cluster umumnya lebih disukai daripada beberapa cluster ketika beban kerja berbagi infrastruktur dan sumber daya dasar yang sama (seperti penyimpanan bersama, jaringan, atau node login). Jika beban kerja memiliki kebutuhan komputasi, penyimpanan, dan jaringan yang serupa, menggunakan beberapa antrian dalam satu cluster lebih efisien karena memungkinkan untuk berbagi sumber daya dan menghindari duplikasi yang tidak perlu. Pendekatan ini menyederhanakan manajemen dan mengurangi overhead, sambil tetap memungkinkan penjadwalan pekerjaan yang efisien dan alokasi sumber daya. Di sisi lain, beberapa *cluster* harus digunakan ketika ada persyaratan keamanan, data, atau isolasi operasional yang kuat di antara beban kerja. Misalnya, jika Anda perlu mengelola dan mengoperasikan beban kerja secara mandiri, dengan jadwal, siklus pembaruan, atau kebijakan akses yang berbeda, beberapa cluster lebih tepat. **Antrian cluster dan kuota sumber daya komputasi** | Sumber Daya | Kuota | | --- | --- | | [`Slurm queues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) | 50 antrian per cluster | | [`Compute resources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) | 50 sumber daya komputasi per antrian 50 sumber daya komputasi per cluster | **Hitungan Node** Setiap sumber daya komputasi dalam [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)antrian harus memiliki unik [`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Name),, [`InstanceType`[`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-InstanceType), dan. [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount) [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)dan [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)memiliki nilai default yang menentukan rentang instance untuk sumber daya komputasi [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)untuk antrian. Anda juga dapat menentukan nilai Anda sendiri untuk [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)dan [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount). Setiap sumber daya komputasi di [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)terdiri dari node statis bernomor dari 1 ke nilai [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)dan node dinamis diberi nomor dari nilai [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)ke nilai. [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount) **Contoh Konfigurasi** Berikut ini adalah contoh dari bagian [Penjadwalan](Scheduling-v3.md) untuk file konfigurasi cluster. Dalam konfigurasi ini ada dua antrian bernama `queue1` dan `queue2` dan masing-masing antrian memiliki [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)dengan yang ditentukan. [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount) ``` Scheduling: Scheduler: slurm SlurmQueues: - Name: queue1 ComputeResources: - InstanceType: c5.xlarge MaxCount: 5 Name: c5xlarge - InstanceType: c4.xlarge MaxCount: 5 Name: c4xlarge - Name: queue2 ComputeResources: - InstanceType: c5.xlarge MaxCount: 5 Name: c5xlarge ``` **Nama host** Instance yang diluncurkan ke armada komputasi ditetapkan secara dinamis. Nama host dihasilkan untuk setiap node. Secara default AWS ParallelCluster akan menggunakan format nama host berikut: `$HOSTNAME=$QUEUE-$STATDYN-$COMPUTE_RESOURCE-$NODENUM` + `$QUEUE`adalah nama antrian. Misalnya, jika [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)bagian memiliki entri dengan [`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Name)set ke “`queue-name`” maka “`$QUEUE`” adalah “`queue-name`”. + `$STATDYN`adalah `st` untuk node statis atau `dy` untuk node dinamis. + `$COMPUTE_RESOURCE`adalah sumber daya [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)komputasi yang sesuai dengan node ini. [`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Name) + `$NODENUM`adalah jumlah node. `$NODENUM`adalah antara satu (1) dan nilai [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)untuk node statis dan antara satu (1) dan [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)- [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)untuk node dinamis. Dari contoh file konfigurasi di atas, node tertentu dari `queue1` dan sumber daya komputasi `c5xlarge` memiliki nama host:. `queue1-dy-c5xlarge-1` Nama host dan nama domain yang sepenuhnya memenuhi syarat (FQDN) dibuat menggunakan zona yang dihosting Amazon Route 53. FQDN adalah`$HOSTNAME.$CLUSTERNAME.pcluster`, di mana `$CLUSTERNAME` nama cluster. Perhatikan bahwa format yang sama akan digunakan untuk nama Slurm node juga. Pengguna dapat memilih untuk menggunakan EC2 nama host Amazon default dari instance yang memberi daya pada node komputasi alih-alih format nama host default yang digunakan oleh. AWS ParallelCluster Ini dapat dilakukan dengan mengatur [`UseEc2Hostnames`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-UseEc2Hostnames)parameter menjadi benar. Namun, nama Slurm node akan terus menggunakan AWS ParallelCluster format default. # 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. # Slurm mode terlindungi cluster Ketika sebuah cluster berjalan dengan mode dilindungi diaktifkan, AWS ParallelCluster memantau dan melacak kegagalan bootstrap node komputasi saat node komputasi sedang diluncurkan. Hal ini dilakukan untuk mendeteksi apakah kegagalan ini terjadi terus menerus. Jika berikut ini terdeteksi dalam antrian (partisi), cluster memasuki status dilindungi: 1. Kegagalan bootstrap node komputasi berturut-turut terjadi terus menerus tanpa peluncuran node komputasi yang berhasil. 1. Jumlah kegagalan mencapai ambang batas yang telah ditentukan. Setelah cluster memasuki status dilindungi, AWS ParallelCluster menonaktifkan antrian dengan kegagalan pada atau di atas ambang batas yang telah ditentukan. Slurm modus cluster dilindungi ditambahkan dalam AWS ParallelCluster versi 3.0.0. Anda dapat menggunakan mode terlindungi untuk mengurangi waktu dan sumber daya yang dihabiskan untuk siklus kegagalan bootstrap node komputasi. ## Parameter mode terlindungi **`protected_failure_count`** `protected_failure_count`menentukan jumlah kegagalan berturut-turut dalam antrian (partisi) yang mengaktifkan status dilindungi cluster. `protected_failure_count`Defaultnya adalah 10 dan mode terlindungi diaktifkan. Jika `protected_failure_count` lebih besar dari nol, mode terlindungi diaktifkan. Jika `protected_failure_count` kurang dari atau sama dengan nol, mode terlindungi dinonaktifkan. Anda dapat mengubah `protected_failure_count` nilainya dengan menambahkan parameter di file `clustermgtd` konfigurasi yang terletak `/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf` di `HeadNode` file. Anda dapat memperbarui parameter ini kapan saja dan Anda tidak perlu menghentikan armada komputasi untuk melakukannya. Jika peluncuran berhasil dalam antrian sebelum jumlah kegagalan mencapai`protected_failure_count`, hitungan kegagalan diatur ulang ke nol. ## Periksa status klaster dalam status terlindungi Saat klaster berada dalam status terlindungi, Anda dapat memeriksa status armada komputasi dan status node. ### Hitung status armada Status armada komputasi berada `PROTECTED` dalam cluster yang berjalan dalam status dilindungi. ``` $ pcluster describe-compute-fleet --cluster-name --region { "status": "PROTECTED", "lastStatusUpdatedTime": "2022-04-22T00:31:24.000Z" } ``` ### Status simpul Untuk mempelajari antrian (partisi) mana yang memiliki kegagalan bootstrap yang telah mengaktifkan status terlindungi, masuk ke cluster dan jalankan perintah. `sinfo` Partisi dengan kegagalan bootstrap pada atau di atas `protected_failure_count` berada dalam `INACTIVE` keadaan. Partisi tanpa kegagalan bootstrap pada atau di atas `protected_failure_count` berada dalam `UP` keadaan dan berfungsi seperti yang diharapkan. `PROTECTED`status tidak berdampak pada menjalankan pekerjaan. Jika pekerjaan berjalan pada partisi dengan kegagalan bootstrap pada atau di atas`protected_failure_count`, partisi diatur ke `INACTIVE` setelah pekerjaan yang berjalan selesai. Pertimbangkan status simpul yang ditunjukkan pada contoh berikut. ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* inact infinite 10 down% queue1-dy-c5xlarge-[1-10] queue1* inact infinite 3490 idle~ queue1-dy-c5xlarge-[11-3500] queue2 up infinite 10 idle~ queue2-dy-c5xlarge-[1-10] ``` Partisi `queue1` adalah `INACTIVE` karena 10 kegagalan bootstrap node komputasi berturut-turut terdeteksi. Instance di belakang node `queue1-dy-c5xlarge-[1-10]` diluncurkan tetapi gagal bergabung dengan cluster karena status yang tidak sehat. Cluster dalam status dilindungi. Partisi `queue2` tidak terpengaruh oleh kegagalan bootstrap di`queue1`. Itu di `UP` negara bagian dan masih bisa menjalankan pekerjaan. ## Cara menonaktifkan status yang dilindungi Setelah kesalahan bootstrap diselesaikan, Anda dapat menjalankan perintah berikut untuk mengeluarkan cluster dari status yang dilindungi. ``` $ pcluster update-compute-fleet --cluster-name \ --region \ --status START_REQUESTED ``` ## Kegagalan bootstrap yang mengaktifkan status dilindungi Kesalahan bootstrap yang mengaktifkan status dilindungi dibagi lagi menjadi tiga jenis berikut. Untuk mengidentifikasi jenis dan masalah, Anda dapat memeriksa apakah log AWS ParallelCluster yang dihasilkan. Jika log dibuat, Anda dapat memeriksanya untuk detail kesalahan. Untuk informasi selengkapnya, lihat [Mengambil dan melestarikan log](troubleshooting-v3-get-logs.md). 1. **Kesalahan bootstrap yang menyebabkan instance berhenti sendiri**. Sebuah instance gagal di awal proses bootstrap, seperti instance yang berhenti sendiri karena kesalahan dalam skrip [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)\$1 [`CustomActions`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-CustomActions)\$1 [`OnNodeStart`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeStart)\$1 [`OnNodeConfigured`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeConfigured). Untuk node dinamis, cari kesalahan yang mirip dengan berikut ini: ``` Node bootstrap error: Node ... is in power up state without valid backing instance ``` Untuk node statis, lihat di `clustermgtd` log (`/var/log/parallelcluster/clustermgtd`) untuk kesalahan yang mirip dengan berikut ini: ``` Node bootstrap error: Node ... is in power up state without valid backing instance ``` 1. **Node `resume_timeout` atau `node_replacement_timeout` kedaluwarsa.** Sebuah instance tidak dapat bergabung dengan cluster di dalam `resume_timeout` (untuk node dinamis) atau `node_replacement_timeout` (untuk node statis). Itu tidak berakhir sendiri sebelum batas waktu. Misalnya, jaringan tidak diatur dengan benar untuk cluster dan node diatur ke `DOWN` status oleh Slurm setelah batas waktu berakhir. Untuk node dinamis, cari kesalahan yang mirip dengan berikut ini: ``` Node bootstrap error: Resume timeout expires for node ``` Untuk node statis, lihat di `clustermgtd` log (`/var/log/parallelcluster/clustermgtd`) untuk kesalahan yang mirip dengan berikut ini: ``` Node bootstrap error: Replacement timeout expires for node ... in replacement. ``` 1. **Node gagal memeriksa kesehatan**. Instance di belakang node gagal pemeriksaan EC2 kesehatan Amazon atau pemeriksaan kesehatan acara terjadwal, dan node diperlakukan sebagai node kegagalan bootstrap. Dalam hal ini, instance berakhir karena alasan di luar kendali. AWS ParallelCluster Lihat di `clustermgtd` log (`/var/log/parallelcluster/clustermgtd`) untuk kesalahan yang mirip dengan berikut ini: ``` Node bootstrap error: Node %s failed during bootstrap when performing health check. ``` 1. **Node komputasi gagal Slurm pendaftaran**. Pendaftaran `slurmd` daemon dengan Slurm control daemon (`slurmctld`) gagal dan menyebabkan status node komputasi berubah ke status. `INVALID_REG` Salah dikonfigurasi Slurm node komputasi dapat menyebabkan kesalahan ini, seperti node terkomputasi yang dikonfigurasi dengan kesalahan spesifikasi node [`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-CustomSlurmSettings)komputasi. Lihat di file `slurmctld` log (`/var/log/slurmctld.log`) pada node kepala, atau lihat di file `slurmd` log (`/var/log/slurmd.log`) dari node komputasi gagal untuk kesalahan yang mirip dengan berikut ini: ``` Setting node %s to INVAL with reason: ... ``` ## Cara men-debug mode yang dilindungi Jika klaster Anda dalam status terlindungi, dan jika AWS ParallelCluster menghasilkan `clustermgtd` log dari `HeadNode` dan `cloud-init-output` log dari node komputasi yang bermasalah, maka Anda dapat memeriksa log untuk detail kesalahan. Untuk informasi selengkapnya tentang cara mengambil log, lihat[Mengambil dan melestarikan log](troubleshooting-v3-get-logs.md). **`clustermgtd`log (`/var/log/parallelcluster/clustermgtd`) pada simpul kepala** Pesan log menunjukkan partisi mana yang mengalami kegagalan bootstrap dan jumlah kegagalan bootstrap yang sesuai. ``` [slurm_plugin.clustermgtd:_handle_protected_mode_process] - INFO - Partitions bootstrap failure count: {'queue1': 2}, cluster will be set into protected mode if protected failure count reach threshold. ``` Di `clustermgtd` log, cari `Found the following bootstrap failure nodes` untuk menemukan node mana yang gagal di-bootstrap. ``` [slurm_plugin.clustermgtd:_handle_protected_mode_process] - WARNING - Found the following bootstrap failure nodes: (x2) ['queue1-st-c5large-1(192.168.110.155)', 'broken-st-c5large-2(192.168.65.215)'] ``` Di `clustermgtd` log, cari `Node bootstrap error` untuk menemukan alasan kegagalan. ``` [slurm_plugin.clustermgtd:_is_node_bootstrap_failure] - WARNING - Node bootstrap error: Node broken-st-c5large-2(192.168.65.215) is currently in replacement and no backing instance ``` **`cloud-init-output`log (`/var/log/cloud-init-output.log`) pada node komputasi** Setelah mendapatkan alamat IP pribadi node kegagalan bootstrap di `clustermgtd` log, Anda dapat menemukan log node komputasi yang sesuai dengan masuk ke node komputasi atau dengan mengikuti panduan [Mengambil dan melestarikan log](troubleshooting-v3-get-logs.md) untuk mengambil log. Dalam kebanyakan kasus, `/var/log/cloud-init-output` log dari node bermasalah menunjukkan langkah yang menyebabkan kegagalan bootstrap node komputasi. # Slurmcluster cepat tidak mencukupi kapasitas fail-over Dimulai dengan AWS ParallelCluster versi 3.2.0, cluster berjalan dengan mode fail-over kapasitas cepat tidak mencukupi diaktifkan secara default. Ini meminimalkan waktu yang dihabiskan untuk mencoba mengantri pekerjaan ketika kesalahan kapasitas Amazon EC2 tidak mencukupi terdeteksi. Ini sangat efektif ketika Anda mengonfigurasi antrian Anda dengan beberapa sumber daya komputasi yang menggunakan jenis instans yang berbeda. **Amazon EC2 mendeteksi kegagalan kapasitas yang tidak mencukupi:** + `InsufficientInstanceCapacity` + `InsufficientHostCapacity` + `InsufficientReservedInstanceCapacity` + `MaxSpotInstanceCountExceeded` + `SpotMaxPriceTooLow`: Diaktifkan jika harga permintaan Spot lebih rendah dari harga pemenuhan permintaan Spot minimum yang disyaratkan. + `Unsupported`: Diaktifkan dengan penggunaan jenis instance yang tidak didukung secara spesifik Wilayah AWS. Dalam mode kegagalan kapasitas yang cepat tidak mencukupi, jika kesalahan kapasitas yang tidak mencukupi terdeteksi saat pekerjaan ditugaskan ke [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`compute resource`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources), AWS ParallelCluster lakukan hal berikut: 1. Ini menetapkan sumber daya komputasi ke status disabled (`DOWN`) untuk jangka waktu yang telah ditentukan. 1. Ini digunakan `POWER_DOWN_FORCE` untuk membatalkan sumber daya komputasi yang gagal pekerjaan node dan untuk menangguhkan node yang gagal. Ini menetapkan node yang gagal ke `POWER_DOWN (!)` status `IDLE` dan, dan kemudian ke`POWERING_DOWN (%)`. 1. Ini mengembalikan pekerjaan ke sumber daya komputasi lain. Node statis dan dinyalakan dari sumber daya komputasi yang dinonaktifkan tidak terpengaruh. Pekerjaan dapat diselesaikan pada node ini. Siklus ini berulang sampai pekerjaan berhasil ditetapkan ke node sumber daya komputasi atau node. Untuk informasi tentang status node, lihat[Slurmpanduan untuk beberapa mode antrian](multiple-queue-mode-slurm-user-guide-v3.md). Jika tidak ada sumber daya komputasi yang ditemukan untuk menjalankan pekerjaan, pekerjaan disetel ke `PENDING` status hingga periode waktu yang telah ditentukan berlalu. Dalam hal ini, Anda dapat mengubah periode waktu yang telah ditentukan seperti yang dijelaskan di bagian berikut. ## Parameter batas waktu kapasitas tidak mencukupi **`insufficient_capacity_timeout`** `insufficient_capacity_timeout`menentukan periode waktu (dalam detik) bahwa sumber daya komputasi disimpan dalam status disabled (`down`) ketika kesalahan kapasitas tidak mencukupi terdeteksi. Secara default, `insufficient_capacity_timeout` diaktifkan. `insufficient_capacity_timeout`Defaultnya adalah 600 detik (10 menit). Jika `insufficient_capacity_timeout` nilainya kurang dari atau sama dengan nol, mode failure-over kapasitas cepat tidak mencukupi dinonaktifkan. Anda dapat mengubah `insufficient_capacity_timeout` nilai dengan menambahkan parameter dalam file `clustermgtd` konfigurasi yang terletak di `/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf` dalam file. `HeadNode` Parameter dapat diperbarui kapan saja tanpa menghentikan armada komputasi. Contoh: + `insufficient_capacity_timeout=600`: Jika kesalahan kapasitas tidak mencukupi terdeteksi, sumber daya komputasi disetel ke disabled (`DOWN`). Setelah 10 menit, node yang gagal diatur ke status `idle~` (`POWER_SAVING`). + `insufficient_capacity_timeout=60`: Jika kesalahan kapasitas tidak mencukupi terdeteksi, sumber daya komputasi berada di disabled (`DOWN`). Setelah 1 menit, node yang gagal diatur ke `idle~` status. + `insufficient_capacity_timeout=0`: Mode kegagalan kapasitas yang tidak mencukupi dengan cepat dinonaktifkan. Sumber daya komputasi tidak dinonaktifkan. **catatan** Mungkin ada penundaan hingga satu menit antara waktu ketika node gagal dengan kesalahan kapasitas yang tidak mencukupi dan waktu ketika daemon manajemen cluster mendeteksi kegagalan node. Ini karena daemon manajemen cluster memeriksa kegagalan kapasitas node yang tidak mencukupi dan menetapkan sumber daya komputasi ke `down` status pada interval satu menit. ## Status mode fail-over kapasitas cepat tidak mencukupi Ketika sebuah cluster berada dalam mode fail-over kapasitas yang cepat tidak mencukupi, Anda dapat memeriksa status dan status simpulnya. ### Status simpul Ketika pekerjaan dikirimkan ke node dinamis sumber daya komputasi dan kesalahan kapasitas yang tidak mencukupi terdeteksi, node ditempatkan dalam `down#` keadaan dengan alasan. ``` (Code:InsufficientInstanceCapacity)Failure when resuming nodes. ``` Kemudian node yang dimatikan (node dalam `idle~` keadaan) disetel ke `down~` dengan alasan. ``` (Code:InsufficientInstanceCapacity)Temporarily disabling node due to insufficient capacity. ``` Pekerjaan tersebut diminta kembali ke sumber daya komputasi lain dalam antrian. Node statis sumber daya komputasi dan node yang `UP` tidak terpengaruh oleh mode fail-over kapasitas yang cepat tidak mencukupi. Pertimbangkan status simpul yang ditunjukkan pada contoh berikut. ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 30 idle~ queue1-dy-c-1-[1-15],queue1-dy-c-2-[1-15] queue2 up infinite 30 idle~ queue2-dy-c-1-[1-15],queue2-dy-c-2-[1-15] ``` Kami mengirimkan pekerjaan ke antrian1 yang membutuhkan satu node. ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 1 down# queue1-dy-c-1-1 queue1* up infinite 15 idle~ queue1-dy-c-2-[1-15] queue1* up infinite 14 down~ queue1-dy-c-1-[2-15] queue2 up infinite 30 idle~ queue2-dy-c-1-[1-15],queue2-dy-c-2-[1-15] ``` `queue1-dy-c-1-1`Node diluncurkan untuk menjalankan pekerjaan. Namun, instance gagal diluncurkan karena kesalahan kapasitas yang tidak mencukupi. Node `queue1-dy-c-1-1` diatur ke`down`. Node dinamis yang dimatikan dalam sumber daya komputasi (`queue2-dy-c-1`) diatur ke`down`. Anda dapat memeriksa alasan node dengan`scontrol show nodes`. ``` $ scontrol show nodes queue1-dy-c-1-1 NodeName=broken-dy-c-2-1 Arch=x86_64 CoresPerSocket=1 CPUAlloc=0 CPUTot=96 CPULoad=0.00 ... ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s Reason=(Code:InsufficientInstanceCapacity)Failure when resuming nodes [root@2022-03-10T22:17:50] $ scontrol show nodes queue1-dy-c-1-2 NodeName=broken-dy-c-2-1 Arch=x86_64 CoresPerSocket=1 CPUAlloc=0 CPUTot=96 CPULoad=0.00 ... ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s Reason=(Code:InsufficientInstanceCapacity)Temporarily disabling node due to insufficient capacity [root@2022-03-10T22:17:50] ``` Pekerjaan diantrian ke jenis instance lain dalam sumber daya komputasi antrian. Setelah `insufficient_capacity_timeout` berlalu, node dalam sumber daya komputasi diatur ulang ke status. `idle~` ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 30 idle~ queue1-dy-c-1-[1-15],queue1-dy-c-2-[1-15] queue2 up infinite 30 idle~ queue2-dy-c-1-[1-15],queue2-dy-c-2-[1-15] ``` Setelah `insufficient_capacity_timeout` berlalu dan node dalam sumber daya komputasi diatur ulang ke `idle~` status, Slurm penjadwal memberikan node prioritas yang lebih rendah. Penjadwal terus memilih node dari sumber daya komputasi antrian lain dengan bobot yang lebih tinggi kecuali salah satu dari yang berikut terjadi: + Persyaratan pengiriman pekerjaan cocok dengan sumber daya komputasi yang dipulihkan. + Tidak ada sumber daya komputasi lain yang tersedia karena mereka berada pada kapasitas. + `slurmctld`dimulai ulang. + Armada AWS ParallelCluster komputasi dihentikan dan mulai dimatikan dan menyalakan semua node. ### Log terkait Log yang terkait dengan kesalahan kapasitas yang tidak mencukupi dan mode kegagalan kapasitas yang cepat tidak mencukupi dapat ditemukan di Slurm `resume` log dan `clustermgtd` log in node kepala. **Slurm `resume` (`/var/log/parallelcluster/slurm_resume.log`)** Pesan kesalahan ketika node gagal diluncurkan karena kapasitas yang tidak mencukupi. ``` [slurm_plugin.instance_manager:_launch_ec2_instances] - ERROR - Failed RunInstances request: dcd0c252-90d4-44a7-9c79-ef740f7ecd87 [slurm_plugin.instance_manager:add_instances_for_nodes] - ERROR - Encountered exception when launching instances for nodes (x1) ['queue1-dy-c-1-1']: An error occurred (InsufficientInstanceCapacity) when calling the RunInstances operation (reached max retries: 1): We currently do not have sufficient p4d.24xlarge capacity in the Availability Zone you requested (us-west-2b). Our system will be working on provisioning additional capacity. You can currently get p4d.24xlarge capacity by not specifying an Availability Zone in your request or choosing us-west-2a, us-west-2c. ``` **Slurm `clustermgtd` (`/var/log/parallelcluster/clustermgtd`)** Sumber daya komputasi c-1 dalam antrean1 dinonaktifkan karena kapasitas yang tidak mencukupi. ``` [slurm_plugin.clustermgtd:_reset_timeout_expired_compute_resources] - INFO - The following compute resources are in down state due to insufficient capacity: {'queue1': {'c-1': ComputeResourceFailureEvent(timestamp=datetime.datetime(2022, 4, 14, 23, 0, 4, 769380, tzinfo=datetime.timezone.utc), error_code='InsufficientInstanceCapacity')}}, compute resources are reset after insufficient capacity timeout (600 seconds) expired ``` Setelah batas waktu kapasitas yang tidak mencukupi berakhir, sumber daya komputasi diatur ulang, node dalam sumber daya komputasi disetel ke. `idle~` ``` [root:_reset_insufficient_capacity_timeout_expired_nodes] - INFO - Reset the following compute resources because insufficient capacity timeout expired: {'queue1': ['c-1']} ``` # Slurm penjadwalan berbasis memori Dimulai dengan versi 3.2.0, mendukung AWS ParallelCluster Slurm penjadwalan berbasis memori dengan parameter konfigurasi [`SlurmSettings`](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/[`EnableMemoryBasedScheduling`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-EnableMemoryBasedScheduling)cluster. **catatan** [Dimulai dengan AWS ParallelCluster versi 3.7.0, `EnableMemoryBasedScheduling` dapat diaktifkan jika Anda mengonfigurasi beberapa jenis instans di Instans.](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances) Untuk AWS ParallelCluster versi 3.2.0 hingga 3.6. *x*, tidak `EnableMemoryBasedScheduling` dapat diaktifkan jika Anda mengonfigurasi beberapa jenis instans di [Instans.](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances) **Awas** Saat Anda menentukan beberapa jenis instance dalam a Slurm sumber daya komputasi antrian dengan `EnableMemoryBasedScheduling` diaktifkan, `RealMemory` nilainya adalah jumlah minimum memori yang tersedia untuk semua jenis instance. Ini dapat menyebabkan sejumlah besar memori yang tidak digunakan jika Anda menentukan jenis instance dengan kapasitas memori yang sangat berbeda. Dengan`EnableMemoryBasedScheduling: true`, Slurm scheduler melacak jumlah memori yang dibutuhkan setiap pekerjaan pada setiap node. Kemudian, Slurm scheduler menggunakan informasi ini untuk menjadwalkan beberapa pekerjaan pada node komputasi yang sama. Jumlah total memori yang dibutuhkan pekerjaan pada node tidak bisa lebih besar dari memori node yang tersedia. Penjadwal mencegah pekerjaan menggunakan lebih banyak memori daripada yang diminta saat pekerjaan diajukan. Dengan`EnableMemoryBasedScheduling: false`, pekerjaan mungkin bersaing untuk mendapatkan memori pada node bersama dan menyebabkan kegagalan pekerjaan dan `out-of-memory` peristiwa. **Awas** Slurm menggunakan kekuatan 2 notasi untuk labelnya, seperti MB atau GB. Baca label ini sebagai MiB dan GiB, masing-masing. ## Slurm konfigurasi dan penjadwalan berbasis memori Dengan`EnableMemoryBasedScheduling: true`, Slurm menetapkan berikut Slurm parameter konfigurasi: + [https://slurm.schedmd.com/slurm.conf.html#OPT_CR_CPU_Memory](https://slurm.schedmd.com/slurm.conf.html#OPT_CR_CPU_Memory)di`slurm.conf`. Opsi ini mengonfigurasi memori node menjadi sumber daya habis pakai di Slurm. + [https://slurm.schedmd.com/cgroup.conf.html#OPT_ConstrainRAMSpace](https://slurm.schedmd.com/cgroup.conf.html#OPT_ConstrainRAMSpace)di Slurm `cgroup.conf`. Dengan opsi ini, akses pekerjaan ke memori terbatas pada jumlah memori yang diminta pekerjaan saat dikirimkan. **catatan** Beberapa lainnya Slurm parameter konfigurasi dapat memengaruhi perilaku Slurm scheduler dan resource manager ketika dua opsi ini ditetapkan. Untuk informasi lebih lanjut, lihat [Slurm Dokumentasi](https://slurm.schedmd.com/documentation.html). ## Slurm penjadwal dan penjadwalan berbasis memori **`EnableMemoryBasedScheduling: false`(default)** Secara default, `EnableMemoryBasedScheduling` diatur ke false. Ketika salah, Slurm tidak menyertakan memori sebagai sumber daya dalam algoritme penjadwalannya dan tidak melacak memori yang digunakan pekerjaan. Pengguna dapat menentukan `--mem MEM_PER_NODE` opsi untuk mengatur jumlah minimum memori per node yang dibutuhkan pekerjaan. Ini memaksa penjadwal untuk memilih node dengan `RealMemory` nilai setidaknya `MEM_PER_NODE` saat menjadwalkan pekerjaan. Misalnya, anggaplah bahwa pengguna mengirimkan dua pekerjaan dengan`--mem=5GB`. Jika sumber daya yang diminta seperti CPUs atau GPUs tersedia, pekerjaan dapat berjalan pada saat yang sama pada node dengan memori 8 GiB. Kedua pekerjaan tidak dijadwalkan pada node komputasi dengan kurang dari 5 `RealMemory` GiB. **Awas** Saat penjadwalan berbasis memori dinonaktifkan, Slurm tidak melacak jumlah memori yang digunakan pekerjaan. Pekerjaan yang berjalan pada node yang sama mungkin bersaing untuk sumber daya memori dan menyebabkan pekerjaan lain gagal. Ketika penjadwalan berbasis memori dinonaktifkan, kami menyarankan agar pengguna tidak menentukan atau opsi. [https://slurm.schedmd.com/srun.html#OPT_mem-per-cpu](https://slurm.schedmd.com/srun.html#OPT_mem-per-cpu) Opsi ini dapat menyebabkan perilaku yang berbeda dari apa yang dijelaskan dalam [Slurm Dokumentasi](https://slurm.schedmd.com/documentation.html). **`EnableMemoryBasedScheduling: true`** Kapan `EnableMemoryBasedScheduling` diatur ke true, Slurm melacak penggunaan memori setiap pekerjaan dan mencegah pekerjaan menggunakan lebih banyak memori daripada yang diminta dengan opsi `--mem` pengiriman. Menggunakan contoh sebelumnya, pengguna mengirimkan dua pekerjaan dengan`--mem=5GB`. Pekerjaan tidak dapat berjalan pada saat yang sama pada node dengan memori 8 GiB. Ini karena jumlah total memori yang dibutuhkan lebih besar daripada memori yang tersedia di node. Dengan penjadwalan berbasis memori diaktifkan, `--mem-per-cpu` dan `--mem-per-gpu` berperilaku konsisten dengan apa yang dijelaskan dalam Slurm dokumentasi. Misalnya, pekerjaan diserahkan`--ntasks-per-node=2 -c 1 --mem-per-cpu=2GB`. Dalam hal ini, Slurm memberikan pekerjaan total 4 GiB untuk setiap node. **Awas** Ketika penjadwalan berbasis memori diaktifkan, kami menyarankan agar pengguna menyertakan `--mem` spesifikasi saat mengirimkan pekerjaan. Dengan default Slurm konfigurasi yang disertakan dengan AWS ParallelCluster, jika tidak ada opsi memori yang disertakan (`--mem`,`--mem-per-cpu`, atau`--mem-per-gpu`), Slurm menetapkan seluruh memori node yang dialokasikan untuk pekerjaan, bahkan jika itu hanya meminta sebagian dari sumber daya lainnya, seperti CPUs atau. GPUs Ini secara efektif mencegah berbagi node sampai pekerjaan selesai karena tidak ada memori yang tersedia untuk pekerjaan lain. Hal ini terjadi karena Slurm menyetel memori per node untuk pekerjaan [https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerNode](https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerNode)ketika tidak ada spesifikasi memori yang disediakan pada waktu pengiriman pekerjaan. Nilai default untuk parameter ini adalah 0 dan menentukan akses tak terbatas ke memori node. Jika beberapa jenis sumber daya komputasi dengan jumlah memori yang berbeda tersedia dalam antrian yang sama, pekerjaan yang dikirimkan tanpa opsi memori mungkin diberikan jumlah memori yang berbeda pada node yang berbeda. Ini tergantung pada node mana yang disediakan oleh penjadwal untuk pekerjaan itu. Pengguna dapat menentukan nilai kustom untuk opsi, seperti `DefMemPerNode` atau [https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerCPU](https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerCPU), pada tingkat cluster atau partisi di Slurm file konfigurasi untuk mencegah perilaku ini. ## Slurm RealMemory dan AWS ParallelCluster SchedulableMemory Dengan Slurm konfigurasi yang dikirimkan dengan AWS ParallelCluster, Slurm menafsirkan [RealMemory](https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory)sebagai jumlah memori per node yang tersedia untuk pekerjaan. Dimulai dengan versi 3.2.0, secara default, AWS ParallelCluster `RealMemory` disetel ke 95 persen memori yang tercantum dalam [Jenis EC2 Instance Amazon](https://aws.amazon.com/ec2/instance-types) dan dikembalikan oleh Amazon EC2 API [DescribeInstanceTypes](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceTypes.html). Ketika penjadwalan berbasis memori dinonaktifkan, Slurm scheduler menggunakan `RealMemory` untuk memfilter node ketika pengguna mengirimkan pekerjaan dengan `--mem` ditentukan. Saat penjadwalan berbasis memori diaktifkan, Slurm scheduler menafsirkan `RealMemory` sebagai jumlah maksimum memori yang tersedia untuk pekerjaan yang berjalan pada node komputasi. Pengaturan default mungkin tidak optimal untuk semua jenis instance: + Pengaturan ini mungkin lebih tinggi dari jumlah memori yang sebenarnya dapat diakses oleh node. Hal ini dapat terjadi ketika node komputasi adalah tipe instance kecil. + Pengaturan ini mungkin lebih rendah dari jumlah memori yang sebenarnya dapat diakses oleh node. Hal ini dapat terjadi ketika node komputasi adalah tipe instance besar dan dapat menyebabkan sejumlah besar memori yang tidak digunakan. Anda dapat menggunakan [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/[`SchedulableMemory`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-SchedulableMemory)untuk menyempurnakan nilai yang `RealMemory` dikonfigurasi oleh AWS ParallelCluster untuk node komputasi. Untuk mengganti default, tentukan nilai kustom `SchedulableMemory` khusus untuk konfigurasi klaster Anda. Untuk memeriksa memori aktual node komputasi yang tersedia, jalankan `/opt/slurm/sbin/slurmd -C` perintah pada node. Perintah ini mengembalikan konfigurasi perangkat keras node, termasuk [https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory](https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory)nilainya. Untuk informasi selengkapnya, lihat [https://slurm.schedmd.com/slurmd.html#OPT_-C](https://slurm.schedmd.com/slurmd.html#OPT_-C). Pastikan bahwa proses sistem operasi node komputasi memiliki memori yang cukup. Untuk melakukan ini, batasi memori yang tersedia untuk pekerjaan dengan menetapkan `SchedulableMemory` nilai lebih rendah dari `RealMemory` nilai yang dikembalikan `slurmd -C` perintah. # Beberapa alokasi tipe instans dengan Slurm Dimulai dengan AWS ParallelCluster versi 3.3.0, Anda dapat mengonfigurasi klaster untuk mengalokasikan dari kumpulan sumber daya komputasi dari jenis instans yang ditentukan. Alokasi dapat didasarkan pada biaya rendah EC2 armada Amazon atau strategi kapasitas optimal. Kumpulan jenis instance yang ditentukan ini harus memiliki jumlah v yang sama CPUs atau, jika multithreading dinonaktifkan, jumlah inti yang sama. Selain itu, rangkaian jenis instance ini harus memiliki jumlah akselerator yang sama dari produsen yang sama. Jika [`Efa`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Efa)/[`Enabled`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Efa-Enabled)disetel ke`true`, instance harus didukung EFA. Untuk informasi dan persyaratan lebih lanjut, lihat [`Scheduling`](Scheduling-v3.md)/[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`AllocationStrategy`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-AllocationStrategy)dan [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/[`Instances`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances). Anda dapat mengatur [`AllocationStrategy`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-AllocationStrategy)ke `lowest-price` atau `capacity-optimized` tergantung pada [CapacityType](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CapacityType)konfigurasi Anda. Di [`Instances`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances), Anda dapat mengonfigurasi satu set jenis instance. **catatan** [Dimulai dengan AWS ParallelCluster versi 3.7.0, `EnableMemoryBasedScheduling` dapat diaktifkan jika Anda mengonfigurasi beberapa jenis instans di Instans.](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances) Untuk AWS ParallelCluster versi 3.2.0 hingga 3.6. *x*, tidak `EnableMemoryBasedScheduling` dapat diaktifkan jika Anda mengonfigurasi beberapa jenis instans di [Instans.](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances) Contoh berikut menunjukkan bagaimana Anda dapat melakukan kueri jenis instance untuk vCPUs, dukungan EFA, dan arsitektur. Kueri InstanceTypes dengan arsitektur 96 v CPUs dan x86\$164. ``` $ aws ec2 describe-instance-types --region region-id \ --filters "Name=vcpu-info.default-vcpus,Values=96" "Name=processor-info.supported-architecture,Values=x86_64" \ --query "sort_by(InstanceTypes[*].{InstanceType:InstanceType,MemoryMiB:MemoryInfo.SizeInMiB,CurrentGeneration:CurrentGeneration,VCpus:VCpuInfo.DefaultVCpus,Cores:VCpuInfo.DefaultCores,Architecture:ProcessorInfo.SupportedArchitectures[0],MaxNetworkCards:NetworkInfo.MaximumNetworkCards,EfaSupported:NetworkInfo.EfaSupported,GpuCount:GpuInfo.Gpus[0].Count,GpuManufacturer:GpuInfo.Gpus[0].Manufacturer}, &InstanceType)" \ --output table ``` Kueri InstanceTypes dengan 64 core, dukungan EFA, dan arsitektur arm64. ``` $ aws ec2 describe-instance-types --region region-id \ --filters "Name=vcpu-info.default-cores,Values=64" "Name=processor-info.supported-architecture,Values=arm64" "Name=network-info.efa-supported,Values=true" --query "sort_by(InstanceTypes[*].{InstanceType:InstanceType,MemoryMiB:MemoryInfo.SizeInMiB,CurrentGeneration:CurrentGeneration,VCpus:VCpuInfo.DefaultVCpus,Cores:VCpuInfo.DefaultCores,Architecture:ProcessorInfo.SupportedArchitectures[0],MaxNetworkCards:NetworkInfo.MaximumNetworkCards,EfaSupported:NetworkInfo.EfaSupported,GpuCount:GpuInfo.Gpus[0].Count,GpuManufacturer:GpuInfo.Gpus[0].Manufacturer}, &InstanceType)" \ --output table ``` Contoh cuplikan konfigurasi cluster berikutnya menunjukkan bagaimana Anda dapat menggunakan ini InstanceType and AllocationStrategy properti. ``` ... Scheduling: Scheduler: slurm SlurmQueues: - Name: queue-1 CapacityType: ONDEMAND AllocationStrategy: lowest-price ... ComputeResources: - Name: computeresource1 Instances: - InstanceType: r6g.2xlarge - InstanceType: m6g.2xlarge - InstanceType: c6g.2xlarge MinCount: 0 MaxCount: 500 - Name: computeresource2 Instances: - InstanceType: m6g.12xlarge - InstanceType: x2gd.12xlarge MinCount: 0 MaxCount: 500 ... ``` # Penskalaan cluster untuk node dinamis ParallelCluster mendukung Slurm metode untuk menskalakan cluster secara dinamis dengan menggunakan plugin Slurm penghemat daya. Untuk informasi selengkapnya, lihat Panduan [Penjadwalan Cloud dan Panduan](https://slurm.schedmd.com/elastic_computing.html) [Hemat Slurm Daya](https://slurm.schedmd.com/power_save.html) di Slurm dokumentasi. Topik berikut menjelaskan Slurm strategi untuk setiap versi. **Topics** + [Slurmstrategi alokasi node dinamis dalam versi 3.8.0](scheduler-node-allocation-v3-3.8.0.md) + [Slurmstrategi alokasi node dinamis dalam versi 3.7.x](scheduler-dynamic-node-allocation-v3-3.7.x.md) + [Slurmstrategi alokasi node dinamis di versi 3.6.x dan sebelumnya](scheduler-dynamic-node-allocation-v3-3.6.x.md) # Slurmstrategi alokasi node dinamis dalam versi 3.8.0 Dimulai dengan ParallelCluster versi 3.8.0, ParallelCluster menggunakan **resume tingkat Pekerjaan** **atau penskalaan tingkat** pekerjaan sebagai strategi alokasi node dinamis default untuk menskalakan cluster: ParallelCluster meningkatkan skala cluster berdasarkan persyaratan setiap pekerjaan, jumlah node yang dialokasikan untuk pekerjaan, dan node mana yang perlu dilanjutkan. ParallelCluster mendapatkan informasi ini dari variabel lingkungan SLURM\$1RESUME\$1FILE. Penskalaan untuk node dinamis adalah proses dua langkah, yang melibatkan peluncuran instans EC2 dan penetapan instans Amazon EC2 yang diluncurkan ke node. Slurm Masing-masing dari dua langkah ini dapat dilakukan dengan menggunakan logika **upaya terbaik **all-or-nothing**atau terbaik**. Untuk peluncuran instans Amazon EC2: + **all-or-nothing**memanggil peluncuran Amazon EC2 API dengan target minimum sama dengan total kapasitas target + **upaya terbaik** memanggil peluncuran Amazon EC2 API dengan target minimum sama dengan 1 dan total kapasitas target sama dengan kapasitas yang diminta Untuk penetapan instans Slurm Amazon EC2 ke node: + **all-or-nothing**menetapkan instans Amazon EC2 Slurm ke node hanya jika memungkinkan untuk menetapkan instans Amazon EC2 ke setiap node yang diminta + **upaya terbaik** menetapkan instans Amazon EC2 Slurm ke node meskipun semua node yang diminta tidak tercakup oleh kapasitas instans Amazon EC2 Kombinasi yang mungkin dari strategi di atas diterjemahkan ke dalam strategi ParallelCluster peluncuran. **Example** [ ScalingStrategy](Scheduling-v3.md#yaml-Scheduling-ScalingStrategy) **all-or-nothing**penskalaan: Strategi ini melibatkan AWS ParallelCluster memulai panggilan API instans peluncuran Amazon EC2 untuk setiap pekerjaan, yang mengharuskan semua instance yang diperlukan agar node komputasi yang diminta berhasil diluncurkan. Ini memastikan bahwa klaster hanya menskalakan ketika kapasitas yang diperlukan per pekerjaan tersedia, menghindari instance idle yang tersisa di akhir proses penskalaan. Strategi ini menggunakan **all-or-nothing**logika untuk peluncuran instans Amazon EC2 untuk setiap pekerjaan plus dan **all-or-nothing**logika untuk penetapan instans Amazon EC2 ke node. Slurm Grup strategi meluncurkan permintaan ke dalam batch, satu untuk setiap sumber daya komputasi yang diminta dan masing-masing hingga 500 node. Untuk permintaan yang mencakup beberapa sumber daya komputasi atau melebihi 500 node, ParallelCluster secara berurutan memproses beberapa batch. Kegagalan kumpulan sumber daya tunggal mana pun mengakibatkan penghentian semua kapasitas yang tidak digunakan terkait, memastikan bahwa tidak ada instance idle yang tersisa di akhir proses penskalaan. Batasan + Waktu yang dibutuhkan untuk penskalaan berbanding lurus dengan jumlah pekerjaan yang diajukan per pelaksanaan program Slurm resume. + Operasi penskalaan dibatasi oleh batas akun RunInstances sumber daya, ditetapkan pada 1000 instance secara default. Batasan ini sesuai dengan AWS kebijakan pembatasan API EC2, untuk detail selengkapnya lihat dokumentasi pelambatan API [Amazon](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/throttling.html) EC2 + Saat Anda mengirimkan pekerjaan dalam sumber daya komputasi dengan satu jenis instans, dalam antrian yang mencakup beberapa Availability Zone, panggilan API peluncuran **all-or-nothing**EC2 hanya berhasil jika semua kapasitas dapat disediakan dalam satu Availability Zone. + Saat Anda mengirimkan pekerjaan di sumber daya komputasi dengan beberapa jenis instans, dalam antrian dengan satu Availability Zone, panggilan API peluncuran Amazon EC2 hanya berhasil jika semua kapasitas dapat disediakan oleh satu jenis instans. **all-or-nothing** + **Saat Anda mengirimkan pekerjaan di sumber daya komputasi dengan beberapa jenis instans, dalam antrian yang mencakup beberapa Availability Zone, panggilan API peluncuran **all-or-nothing**Amazon EC2 tidak didukung dan ParallelCluster melakukan penskalaan upaya terbaik sebagai gantinya.** **greedy-all-or-nothing**penskalaan: Varian all-or-nothing strategi ini masih memastikan bahwa klaster hanya menskalakan ketika kapasitas yang diperlukan per pekerjaan tersedia, menghindari instans idle di akhir proses penskalaan, tetapi ini melibatkan ParallelCluster memulai panggilan API instans peluncuran Amazon EC2 yang bertujuan untuk kapasitas target minimum 1, mencoba memaksimalkan jumlah node yang diluncurkan hingga kapasitas yang diminta. Strategi ini menggunakan logika upaya terbaik untuk peluncuran instans EC2 untuk semua pekerjaan ditambah **all-or-nothing**logika untuk penetapan instans Amazon EC2 ke node untuk setiap pekerjaan. Slurm Grup strategi meluncurkan permintaan ke dalam batch, satu untuk setiap sumber daya komputasi yang diminta dan masing-masing hingga 500 node. Untuk permintaan yang mencakup beberapa sumber daya komputasi atau melebihi 500 node, ParellelCluster secara berurutan memproses beberapa batch. Ini memastikan bahwa tidak ada instance idle yang tersisa di akhir proses penskalaan, dengan memaksimalkan throughput dengan biaya penskalaan berlebih sementara selama proses penskalaan. Batasan + Penskalaan berlebih sementara dimungkinkan, yang menyebabkan biaya tambahan untuk instance yang beralih ke status berjalan sebelum penyelesaian penskalaan. + Batas instans yang sama seperti dalam all-or-nothing strategi berlaku, tunduk AWS pada batas akun RunInstances sumber daya. penskalaan **upaya terbaik**: Strategi ini memanggil panggilan API instans peluncuran Amazon EC2 dengan menargetkan kapasitas minimum 1 dan bertujuan untuk mencapai total kapasitas yang diminta dengan biaya meninggalkan instans idle setelah eksekusi proses penskalaan jika tidak semua kapasitas yang diminta tersedia. **Strategi ini menggunakan logika upaya terbaik untuk peluncuran instans Amazon EC2 untuk semua pekerjaan ditambah logika upaya terbaik untuk penugasan instans Amazon EC2 ke node Slurm untuk setiap pekerjaan.** Grup strategi meluncurkan permintaan ke dalam batch, satu untuk setiap sumber daya komputasi yang diminta dan masing-masing hingga 500 node. Untuk permintaan yang mencakup beberapa sumber daya komputasi atau melebihi 500 node, ParallelCluster secara berurutan memproses beberapa batch. Strategi ini memungkinkan penskalaan jauh melampaui batas 1000 instans default atas beberapa eksekusi proses penskalaan, dengan biaya memiliki instans idle di seluruh proses penskalaan yang berbeda. Batasan + Kemungkinan instance idle running di akhir proses penskalaan, untuk kasus ketika tidak mungkin mengalokasikan semua node yang diminta oleh pekerjaan. Berikut ini adalah contoh yang menunjukkan bagaimana penskalaan node dinamis berperilaku menggunakan **strategi ParallelCluster peluncuran** yang berbeda. Misalkan Anda telah mengirimkan dua pekerjaan yang meminta masing-masing 20 node, dengan total 40 node dari jenis yang sama, tetapi hanya ada 30 instans Amazon EC2 yang tersedia untuk menutupi kapasitas yang diminta pada EC2. **all-or-nothing**penskalaan: + Untuk pekerjaan pertama, API instans peluncuran ** all-or-nothing**Amazon EC2 dipanggil, meminta 20 instans. Panggilan yang berhasil menghasilkan peluncuran 20 instance + **all-or-nothing **penugasan 20 instance yang diluncurkan ke Slurm node untuk pekerjaan pertama berhasil + API instans peluncuran **all-or-nothing**Amazon EC2 lainnya dipanggil, meminta 20 instans untuk pekerjaan kedua. Panggilan tidak berhasil, karena hanya ada kapasitas untuk 10 contoh lainnya. Tidak ada instance yang diluncurkan saat ini **greedy-all-or-nothing**penskalaan: + API instans peluncuran Amazon EC2 **upaya terbaik** dipanggil, meminta 40 instans, yang merupakan total kapasitas yang diminta oleh semua pekerjaan. Ini menghasilkan peluncuran 30 instance + **all-or-nothing**Penugasan 20 instance yang diluncurkan ke Slurm node untuk pekerjaan pertama berhasil + **all-or-nothing**Penugasan lain dari instance yang diluncurkan yang tersisa ke Slurm node untuk pekerjaan kedua dicoba, tetapi karena hanya ada 10 instance yang tersedia dari total 20 yang diminta oleh pekerjaan, penugasan tidak berhasil + 10 instans yang diluncurkan yang tidak ditetapkan dihentikan penskalaan **upaya terbaik**: + API instans peluncuran Amazon EC2 **upaya terbaik** dipanggil, meminta 40 instans, yang merupakan total kapasitas yang diminta oleh semua pekerjaan. Ini menghasilkan peluncuran 30 instance. + Penugasan **upaya terbaik** dari 20 instance yang diluncurkan ke Slurm node untuk pekerjaan pertama berhasil. + Penugasan **upaya terbaik** lainnya dari 10 instance yang diluncurkan ke Slurm node untuk pekerjaan kedua berhasil, bahkan jika total kapasitas yang diminta adalah 20. Tetapi karena pekerjaan itu meminta 20 node, dan dimungkinkan untuk menetapkan instans Amazon EC2 hanya ke 10 dari mereka, pekerjaan tidak dapat dimulai dan instance dibiarkan berjalan menganggur, hingga kapasitas yang cukup ditemukan untuk memulai 10 instance yang hilang pada panggilan selanjutnya dari proses penskalaan, atau penjadwal menjadwalkan pekerjaan di node komputasi lain yang sudah berjalan. # Slurmstrategi alokasi node dinamis dalam versi 3.7.x ParallelCluster menggunakan 2 jenis strategi alokasi node dinamis untuk menskalakan cluster: + **Alokasi berdasarkan informasi node yang diminta yang tersedia:** + **Semua node melanjutkan** atau penskalaan daftar **simpul**: ParallelCluster meningkatkan skala cluster hanya berdasarkan Slurm nama daftar node yang diminta saat Slurm `ResumeProgram` dijalankan. Ini mengalokasikan sumber daya komputasi ke node hanya dengan nama node. Daftar nama node dapat mencakup beberapa pekerjaan. + **Resume tingkat pekerjaan atau penskalaan** tingkat **pekerjaan**: ParallelCluster skala cluster berdasarkan persyaratan setiap pekerjaan, jumlah node saat ini yang dialokasikan untuk pekerjaan, dan node mana yang perlu dilanjutkan. ParallelCluster mendapatkan informasi ini dari variabel `SLURM_RESUME_FILE` lingkungan. + **Alokasi dengan strategi peluncuran Amazon EC2:** + Penskalaan **upaya terbaik**: ParallelCluster meningkatkan skala cluster dengan menggunakan panggilan API instans peluncuran Amazon EC2 dengan kapasitas target minimum sama dengan 1, untuk meluncurkan beberapa, tetapi tidak harus semua instance diperlukan untuk mendukung node yang diminta. + **ll-or-nothingPenskalaan**: ParallelCluster meningkatkan skala cluster dengan menggunakan panggilan API instans peluncuran Amazon EC2 yang hanya berhasil jika semua instance yang diperlukan untuk mendukung node yang diminta diluncurkan. Dalam hal ini, ia memanggil API instans peluncuran Amazon EC2 dengan kapasitas target minimum sama dengan total kapasitas yang diminta. Secara default, ParallelCluster menggunakan penskalaan **daftar simpul dengan strategi peluncuran **Amazon** EC2 upaya terbaik untuk meluncurkan beberapa, tetapi belum tentu semua instance diperlukan untuk mendukung node** yang diminta. Ia mencoba menyediakan kapasitas sebanyak mungkin untuk melayani beban kerja yang diajukan. **Dimulai dengan ParallelCluster versi 3.7.0, ParallelCluster menggunakan penskalaan **tingkat pekerjaan** dengan strategi peluncuran **all-or-nothing**EC2 untuk pekerjaan yang dikirimkan dalam mode eksklusif.** Saat Anda mengirimkan pekerjaan dalam mode eksklusif, pekerjaan tersebut memiliki akses eksklusif ke node yang dialokasikan. Untuk informasi lebih lanjut, lihat [EKSKLUSIF](https://slurm.schedmd.com/slurm.conf.html#OPT_EXCLUSIVE) dalam Slurm dokumentasi. Untuk mengirimkan pekerjaan dalam mode eksklusif: + Lewati bendera eksklusif saat mengirimkan Slurm pekerjaan ke cluster. Misalnya, `sbatch ... --exclusive`. ATAU + Kirim pekerjaan ke antrian cluster yang telah dikonfigurasi dengan [`JobExclusiveAllocation`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-JobExclusiveAllocation)set ke`true`. Saat mengirimkan pekerjaan dalam mode eksklusif: + ParallelCluster saat ini batch meluncurkan permintaan untuk menyertakan hingga 500 node. Jika pekerjaan meminta lebih dari 500 node, ParallelCluster membuat permintaan **all-or-nothing**peluncuran untuk setiap set 500 node dan permintaan peluncuran tambahan untuk sisa node. + Jika alokasi node dalam sumber daya komputasi tunggal, ParallelCluster buat permintaan **all-or-nothing**peluncuran untuk setiap set 500 node dan permintaan peluncuran tambahan untuk sisa node. Jika permintaan peluncuran gagal, ParallelCluster menghentikan kapasitas yang tidak terpakai yang dibuat oleh semua permintaan peluncuran. + Jika alokasi node mencakup beberapa sumber daya komputasi, ParallelCluster perlu membuat permintaan **all-or-nothing**peluncuran untuk setiap sumber daya komputasi. Permintaan ini juga dikumpulkan. Jika permintaan peluncuran gagal untuk salah satu sumber daya komputasi, ParallelCluster menghentikan kapasitas yang tidak terpakai yang dibuat oleh semua permintaan peluncuran sumber daya komputasi. penskalaan **tingkat pekerjaan** dengan strategi **all-or-nothing**peluncuran batasan yang diketahui: + Saat Anda mengirimkan pekerjaan dalam sumber daya komputasi dengan satu jenis instans, dalam antrian yang mencakup beberapa Availability Zone, panggilan API peluncuran **all-or-nothing**EC2 hanya berhasil jika semua kapasitas dapat disediakan dalam satu Availability Zone. + Saat Anda mengirimkan pekerjaan di sumber daya komputasi dengan beberapa jenis instans, dalam antrian dengan satu Availability Zone, panggilan API peluncuran Amazon EC2 hanya berhasil jika semua kapasitas dapat disediakan oleh satu jenis instans. **all-or-nothing** + **Saat Anda mengirimkan pekerjaan di sumber daya komputasi dengan beberapa jenis instans, dalam antrian yang mencakup beberapa Availability Zone, panggilan API peluncuran **all-or-nothing**Amazon EC2 tidak didukung dan ParallelCluster melakukan penskalaan upaya terbaik sebagai gantinya.** # Slurmstrategi alokasi node dinamis di versi 3.6.x dan sebelumnya AWS ParallelCluster hanya menggunakan satu jenis strategi alokasi node dinamis untuk menskalakan cluster: + Alokasi berdasarkan informasi node yang diminta yang tersedia: + **Semua node melanjutkan** atau penskalaan **daftar** simpul: meningkatkan ParallelCluster skala cluster hanya berdasarkan nama daftar node yang diminta Slurm saat dijalankan. Slurm `ResumeProgram` Ini mengalokasikan sumber daya komputasi ke node hanya dengan nama node. Daftar nama node dapat mencakup beberapa pekerjaan. + Alokasi dengan strategi peluncuran Amazon EC2: + Penskalaan **upaya terbaik**: meningkatkan ParallelCluster skala klaster dengan menggunakan panggilan API instans peluncuran Amazon EC2 dengan kapasitas target minimum sama dengan 1, untuk meluncurkan beberapa, tetapi tidak harus semua instance diperlukan untuk mendukung node yang diminta. ParallelCluster menggunakan penskalaan **daftar simpul dengan strategi peluncuran **Amazon** EC2 upaya terbaik untuk meluncurkan beberapa, tetapi tidak harus semua instance diperlukan untuk mendukung node** yang diminta. Ia mencoba menyediakan kapasitas sebanyak mungkin untuk melayani beban kerja yang diajukan. Batasan + Kemungkinan instance idle running di akhir proses penskalaan, untuk kasus ketika tidak mungkin mengalokasikan semua node yang diminta oleh pekerjaan. # Slurmakuntansi dengan AWS ParallelCluster Dimulai dengan versi 3.3.0, AWS ParallelCluster mendukung Slurm akuntansi dengan parameter konfigurasi klaster [SlurmSettings](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/[Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database). Dimulai dengan versi 3.10.0, AWS ParallelCluster mendukung Slurm akuntansi dengan Slurmdbd eksternal dengan parameter konfigurasi cluster/. [SlurmSettings[ExternalSlurmdbd](Scheduling-v3.md#Scheduling-v3-SlurmSettings-ExternalSlurmdbd)](Scheduling-v3.md#Scheduling-v3-SlurmSettings) Menggunakan Slurmdbd eksternal disarankan jika beberapa cluster berbagi database yang sama. Dengan Slurm akuntansi, Anda dapat mengintegrasikan database akuntansi eksternal untuk melakukan hal berikut: + Mengelola pengguna klaster atau grup pengguna dan entitas lainnya. Dengan kemampuan ini, Anda dapat menggunakan Slurm fitur-fitur yang lebih canggih, seperti penegakan batas sumber daya, pembagian yang adil, dan. QOSs + Kumpulkan dan simpan data pekerjaan, seperti pengguna yang menjalankan pekerjaan, durasi pekerjaan, dan sumber daya yang digunakannya. Anda dapat melihat data yang disimpan dengan `sacct` utilitas. **catatan** AWS ParallelCluster mendukung Slurm akuntansi untuk server [database MySQL yang Slurm didukung](https://slurm.schedmd.com/accounting.html#mysql-configuration). ## Bekerja dengan Slurm akuntansi menggunakan eksternal Slurmdbd di AWS ParallelCluster v3.10.0 dan yang lebih baru Sebelum Anda mengkonfigurasi Slurm akuntansi, Anda harus memiliki server Slurmdbd database eksternal yang ada, yang terhubung ke server database eksternal yang ada. Untuk mengonfigurasi ini, tentukan yang berikut ini: + Alamat Slurmdbd server eksternal [ExternalSlurmdbd](Scheduling-v3.md#Scheduling-v3-SlurmSettings-ExternalSlurmdbd)[di/Host](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ExternalSlurmdbd-Host). Server harus ada dan dapat dijangkau dari node kepala. + Kunci munge untuk berkomunikasi dengan Slurmdbd server eksternal di. [MungeKeySecretArn](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-MungeKeySecretArn) Untuk melangkah melalui tutorial, lihat[Membuat cluster dengan eksternal Slurmdbd akuntansi](external-slurmdb-accounting.md). **catatan** Anda bertanggung jawab untuk mengelola entitas akuntansi Slurm database. Arsitektur fitur SlurmDB dukungan AWS ParallelCluster eksternal memungkinkan beberapa cluster berbagi database yang sama SlurmDB dan sama. ![\[\]](http://docs.aws.amazon.com/id_id/parallelcluster/latest/ug/images/External_Slurmdbd_Architecture_ASG.png) **Awas** Lalu lintas antara AWS ParallelCluster dan eksternal tidak SlurmDB dienkripsi. Disarankan untuk menjalankan cluster dan eksternal SlurmDB di jaringan tepercaya. ## Bekerja dengan Slurm akuntansi menggunakan head node Slurmdbd di AWS ParallelCluster v3.3.0 dan yang lebih baru Sebelum Anda mengkonfigurasi Slurm akuntansi, Anda harus memiliki server database eksternal yang ada dan database yang menggunakan `mysql` protokol. Untuk mengonfigurasi Slurm akuntansi dengan AWS ParallelCluster, Anda harus menentukan yang berikut: + URI untuk server database eksternal di [Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)/[Uri](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-Uri). Server harus ada dan dapat dijangkau dari node kepala. + Kredensyal untuk mengakses database eksternal yang didefinisikan dalam Database/[PasswordSecretArn](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-PasswordSecretArn)dan [[Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)/. [UserName](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-UserName) AWS ParallelCluster menggunakan informasi ini untuk mengkonfigurasi akuntansi di Slurm tingkat dan `slurmdbd` layanan pada node kepala. `slurmdbd`adalah daemon yang mengelola komunikasi antara cluster dan server database. Untuk melangkah melalui tutorial, lihat[Membuat cluster dengan Slurm akuntansi](tutorials_07_slurm-accounting-v3.md). **catatan** AWS ParallelCluster melakukan bootstrap dasar dari database Slurm akuntansi dengan mengatur pengguna cluster default sebagai admin database dalam Slurm database. AWS ParallelCluster tidak menambahkan pengguna lain ke database akuntansi. Pelanggan bertanggung jawab untuk mengelola entitas akuntansi dalam Slurm database. AWS ParallelCluster mengkonfigurasi [https://slurm.schedmd.com/slurmdbd.html](https://slurm.schedmd.com/slurmdbd.html)untuk memastikan bahwa cluster memiliki Slurm database sendiri di server database. Server database yang sama dapat digunakan di beberapa cluster, tetapi setiap cluster memiliki database tersendiri. AWS ParallelCluster menggunakan nama cluster untuk menentukan nama untuk database dalam [https://slurm.schedmd.com/slurmdbd.conf.html#OPT_StorageLoc](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_StorageLoc)parameter file `slurmdbd` konfigurasi. Pertimbangkan situasi berikut. Database yang ada di server database menyertakan nama cluster yang tidak dipetakan ke nama cluster aktif. Dalam hal ini, Anda dapat membuat cluster baru dengan nama cluster tersebut untuk dipetakan ke database tersebut. Slurmmenggunakan kembali database untuk cluster baru. **Awas** Kami tidak menyarankan menyiapkan lebih dari satu cluster untuk menggunakan database yang sama sekaligus. Melakukannya dapat menyebabkan masalah kinerja atau bahkan situasi kebuntuan database. Jika Slurm akuntansi diaktifkan pada node kepala cluster, sebaiknya gunakan tipe instance dengan CPU yang kuat, lebih banyak memori, dan bandwidth jaringan yang lebih tinggi. Slurmakuntansi dapat menambah ketegangan pada simpul kepala cluster. Dalam arsitektur fitur AWS ParallelCluster Slurm akuntansi saat ini, setiap cluster memiliki instance `slurmdbd` daemon sendiri seperti yang ditunjukkan pada konfigurasi contoh diagram berikut. ![\[\]](http://docs.aws.amazon.com/id_id/parallelcluster/latest/ug/images/slurm-acct-arch.png) Jika Anda menambahkan fungsionalitas Slurm multi-cluster atau federasi khusus ke lingkungan cluster Anda, semua cluster harus mereferensikan instance yang sama. `slurmdbd` Untuk alternatif ini, kami menyarankan Anda mengaktifkan AWS ParallelCluster Slurm akuntansi pada satu cluster dan secara manual mengkonfigurasi cluster lain untuk terhubung ke `slurmdbd` yang di-host pada cluster pertama. Jika Anda menggunakan AWS ParallelCluster versi sebelum versi 3.3.0, lihat metode alternatif untuk menerapkan Slurm akuntansi yang dijelaskan dalam Posting [Blog HPC](https://aws.amazon.com/blogs/compute/enabling-job-accounting-for-hpc-with-aws-parallelcluster-and-amazon-rds/) ini. ## Slurmpertimbangan akuntansi ### Database dan cluster berbeda VPCs Untuk mengaktifkan Slurm akuntansi, server database diperlukan untuk berfungsi sebagai backend untuk operasi baca dan tulis yang dilakukan `slurmdbd` daemon. Sebelum cluster dibuat atau diperbarui untuk mengaktifkan Slurm akuntansi, node kepala harus dapat mencapai server database. Jika Anda perlu menyebarkan server database pada VPC selain yang digunakan cluster, pertimbangkan hal berikut: + Untuk mengaktifkan komunikasi antara `slurmdbd` sisi cluster dan server database, Anda harus mengatur konektivitas antara keduanya VPCs. Untuk informasi selengkapnya, lihat [VPC Peering di Panduan](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) Pengguna *Amazon Virtual Private Cloud*. + Anda harus membuat grup keamanan yang ingin Anda lampirkan ke node kepala pada VPC cluster. Setelah keduanya VPCs telah diintip, cross-linking antara sisi database dan kelompok keamanan sisi cluster tersedia. Untuk informasi selengkapnya, lihat [Aturan Grup Keamanan](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SecurityGroupRules) di *Panduan Pengguna Amazon Virtual Private Cloud*. ### Mengkonfigurasi enkripsi TLS antara `slurmdbd` dan server database Dengan konfigurasi Slurm akuntansi default yang AWS ParallelCluster menyediakan, `slurmdbd` menetapkan koneksi terenkripsi TLS ke server database, jika server mendukung enkripsi TLS. AWS layanan database seperti Amazon RDS dan Amazon Aurora mendukung enkripsi TLS secara default. Anda dapat memerlukan koneksi aman di sisi server dengan mengatur `require_secure_transport` parameter pada server database. Ini dikonfigurasi dalam CloudFormation template yang disediakan. Mengikuti praktik keamanan terbaik, kami menyarankan Anda juga mengaktifkan verifikasi identitas server pada `slurmdbd` klien. Untuk melakukan ini, konfigurasikan [StorageParameters](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_StorageParameters)di`slurmdbd.conf`. Unggah sertifikat CA server ke node kepala cluster. Selanjutnya, atur opsi [SSL\$1CA](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_SSL_CA) dari `StorageParameters` in `slurmdbd.conf` ke jalur sertifikat CA server pada node kepala. Melakukan hal ini memungkinkan verifikasi identitas server di `slurmdbd` samping. Setelah Anda membuat perubahan ini, restart `slurmdbd` layanan untuk membangun kembali konektivitas ke server database dengan verifikasi identitas diaktifkan. ### Memperbarui kredensi database Untuk memperbarui nilai untuk [Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)/[UserName](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-UserName)atau [PasswordSecretArn](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-PasswordSecretArn), Anda harus terlebih dahulu menghentikan armada komputasi. Misalkan nilai rahasia yang disimpan dalam AWS Secrets Manager rahasia diubah dan ARN-nya tidak berubah. Dalam situasi ini, cluster tidak secara otomatis memperbarui kata sandi database ke nilai baru. Untuk memperbarui cluster untuk nilai rahasia baru, jalankan perintah berikut dari node kepala. ``` $ sudo /opt/parallelcluster/scripts/slurm/update_slurm_database_password.sh ``` **Awas** Untuk menghindari kehilangan data akuntansi, sebaiknya Anda hanya mengubah kata sandi database saat armada komputasi dihentikan. ### Pemantauan basis data Kami menyarankan Anda mengaktifkan fitur pemantauan layanan AWS database. Untuk informasi selengkapnya, lihat pemantauan [Amazon RDS atau dokumentasi pemantauan](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html) [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/MonitoringAurora.html). # Slurm kustomisasi konfigurasi Dimulai dengan AWS ParallelCluster versi 3.6.0, Anda dapat menyesuaikan `slurm.conf` Slurm konfigurasi dalam konfigurasi AWS ParallelCluster cluster. Dalam konfigurasi cluster, Anda dapat menyesuaikan Slurm parameter konfigurasi dengan menggunakan pengaturan konfigurasi cluster berikut: + Kustomisasi Slurm parameter untuk seluruh cluster dengan menggunakan [`SlurmSettings`](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/[`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-CustomSlurmSettings)atau [`CustomSlurmSettingsIncludeFile`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-CustomSlurmSettingsIncludeFile)parameter. AWS ParallelCluster gagal jika Anda menentukan keduanya. + Kustomisasi Slurm parameter untuk antrian dengan menggunakan [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomSlurmSettings)(dipetakan ke Slurm partisi). + Kustomisasi Slurm parameter untuk sumber daya komputasi dengan menggunakan [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/[`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-CustomSlurmSettings)(dipetakan ke Slurm simpul). ## Slurm batas kustomisasi konfigurasi dan pertimbangan saat menggunakan AWS ParallelCluster + Untuk `CustomSlurmSettings` dan `CustomSlurmSettingsIncludeFile` pengaturan, Anda hanya dapat menentukan dan memperbarui `slurm.conf` parameter yang disertakan dalam [Slurm versi ](slurm-workload-manager-v3.md) yang didukung oleh AWS ParallelCluster versi yang Anda gunakan untuk mengkonfigurasi cluster. + Jika Anda menentukan kustom Slurm konfigurasi di salah satu `CustomSlurmSettings` parameter, AWS ParallelCluster melakukan pemeriksaan validasi dan mencegah pengaturan atau pembaruan Slurm parameter konfigurasi yang bertentangan dengan AWS ParallelCluster logika. Bagian Slurm parameter konfigurasi yang diketahui bertentangan dengan AWS ParallelCluster diidentifikasi dalam daftar penolakan. Daftar penolakan dapat berubah di AWS ParallelCluster versi masa depan jika yang lain Slurm fitur ditambahkan. Untuk informasi selengkapnya, lihat [Terdaftar penolakan Slurm parameter konfigurasi untuk `CustomSlurmSettings`](#slurm-configuration-denylists-v3). + AWS ParallelCluster hanya memeriksa apakah parameter ada dalam daftar penolakan. AWS ParallelCluster tidak memvalidasi kustom Anda Slurm sintaks parameter konfigurasi atau semantik. Anda bertanggung jawab untuk memvalidasi kebiasaan Anda Slurm parameter konfigurasi. Kustom tidak valid Slurm parameter konfigurasi dapat menyebabkan Slurm kegagalan daemon yang dapat menyebabkan kegagalan pembuatan dan pembaruan cluster. + Jika Anda menentukan kustom Slurm konfigurasi di`CustomSlurmSettingsIncludeFile`, AWS ParallelCluster tidak melakukan validasi apa pun. + Anda dapat memperbarui `CustomSlurmSettings` dan `CustomSlurmSettingsIncludeFile` tanpa berhenti dan memulai armada komputasi. Dalam hal ini, AWS ParallelCluster restart `slurmctld` daemon dan menjalankan perintah. `scontrol reconfigure` Beberapa Slurm parameter konfigurasi mungkin memerlukan operasi yang berbeda sebelum perubahan terdaftar di seluruh cluster. Misalnya, mereka mungkin memerlukan restart semua daemon di cluster. Anda bertanggung jawab untuk memverifikasi apakah AWS ParallelCluster operasi cukup untuk menyebarkan kustom Anda Slurm pengaturan parameter konfigurasi selama pembaruan. Jika Anda menemukan bahwa AWS ParallelCluster operasi tidak cukup, Anda bertanggung jawab untuk memberikan tindakan tambahan yang diperlukan untuk menyebarkan pengaturan yang diperbarui seperti yang direkomendasikan dalam [Slurm dokumentasi](https://slurm.schedmd.com/documentation.html). ## Terdaftar penolakan Slurm parameter konfigurasi untuk `CustomSlurmSettings` Tabel berikut mencantumkan parameter dengan AWS ParallelCluster versi yang menolak penggunaannya, dimulai dengan versi 3.6.0. `CustomSlurmSettings`tidak didukung untuk AWS ParallelCluster versi yang lebih awal dari versi 3.6.0. **Parameter yang terdaftar penolakan di tingkat cluster:** | Slurm parameter | Deny-terdaftar dalam versi AWS ParallelCluster | | --- | --- | | CommunicationParameters | 3.6.0 | | Epilog | 3.6.0 | | GresTypes | 3.6.0 | | LaunchParameters | 3.6.0 | | Prolog | 3.6.0 | | ReconfigFlags | 3.6.0 | | ResumeFailProgram | 3.6.0 | | ResumeProgram | 3.6.0 | | ResumeTimeout | 3.6.0 | | SlurmctldHost | 3.6.0 | | SlurmctldLogFile | 3.6.0 | | SlurmctldParameters | 3.6.0 | | SlurmdLogfile | 3.6.0 | | SlurmUser | 3.6.0 | | SuspendExcNodes | 3.6.0 | | SuspendProgram | 3.6.0 | | SuspendTime | 3.6.0 | | TaskPlugin | 3.6.0 | | TreeWidth | 3.6.0 | **Parameter yang terdaftar penolakan pada tingkat klaster saat parameter asli [Slurm integrasi akuntansi](slurm-accounting-v3.md) dikonfigurasi dalam konfigurasi cluster:** | Slurm parameter | Deny-terdaftar dalam versi AWS ParallelCluster | | --- | --- | | AccountingStorageType | 3.6.0 | | AccountingStorageHost | 3.6.0 | | AccountingStoragePort | 3.6.0 | | AccountingStorageUser | 3.6.0 | | JobAcctGatherType | 3.6.0 | **Parameter yang terdaftar penolakan pada tingkat antrian (partisi) untuk antrian yang dikelola oleh: AWS ParallelCluster** | Slurm parameter | Deny-terdaftar dalam versi AWS ParallelCluster | | --- | --- | | Simpul | 3.6.0 | | PartitionName | 3.6.0 | | ResumeTimeout | 3.6.0 | | Status | 3.6.0 | | SuspendTime | 3.6.0 | **Parameter yang terdaftar penolakan pada tingkat sumber daya komputasi (node) untuk sumber daya komputasi yang dikelola oleh: AWS ParallelCluster** | Slurm parameter | Deny-terdaftar dalam AWS ParallelCluster versi dan versi yang lebih baru | | --- | --- | | CPUs | 3.6.0 | | Fitur | 3.6.0 | | Gres | 3.6.0 | | NodeAddr | 3.6.0 | | NodeHostname | 3.6.0 | | NodeName | 3.6.0 | | Berat Badan | 3.7.0 | # Slurm dan `prolog` `epilog` Dimulai dengan AWS ParallelCluster versi 3.6.0, Slurm konfigurasi yang diterapkan dengan AWS ParallelCluster menyertakan parameter `Prolog` dan `Epilog` konfigurasi: ``` # PROLOG AND EPILOG Prolog=/opt/slurm/etc/scripts/prolog.d/* Epilog=/opt/slurm/etc/scripts/epilog.d/* SchedulerParameters=nohold_on_prolog_fail BatchStartTimeout=180 ``` Untuk informasi lebih lanjut, lihat [Panduan Prolog dan Epilog](https://slurm.schedmd.com/prolog_epilog.html) di dokumentasi. Slurm AWS ParallelCluster termasuk skrip prolog dan epilog berikut: + `90_plcuster_health_check_manager`(dalam `Prolog` folder) + `90_pcluster_noop`(dalam `Epilog` folder) **catatan** Kedua folder `Prolog` dan `Epilog` folder harus berisi setidaknya satu file. Anda dapat menggunakan kustom `prolog` atau `epilog` skrip Anda sendiri dengan menambahkannya ke `Epilog` folder `Prolog` dan folder yang sesuai. **Awas** Slurmmenjalankan setiap skrip di folder, dalam urutan abjad terbalik. Durasi waktu berjalan `prolog` dan `epilog` skrip memengaruhi waktu yang dibutuhkan untuk menjalankan pekerjaan. Perbarui pengaturan `BatchStartTimeout` konfigurasi saat menjalankan beberapa atau `prolog` skrip yang berjalan lama. Defaultnya adalah 3 menit. Jika Anda menggunakan kustom `prolog` dan `epilog` skrip, cari skrip di masing-masing `Prolog` dan `Epilog` folder. Kami menyarankan Anda menyimpan `90_plcuster_health_check_manager` skrip yang berjalan sebelum setiap skrip kustom. Lihat informasi yang lebih lengkap di [Slurm kustomisasi konfigurasi](slurm-configuration-settings-v3.md). # Ukuran dan pembaruan kapasitas cluster Kapasitas cluster ditentukan oleh jumlah node komputasi yang dapat diskalakan oleh cluster. Node komputasi didukung oleh EC2 instans Amazon yang ditentukan dalam sumber daya komputasi dalam AWS ParallelCluster konfigurasi`(Scheduling/SlurmQueues/ ComputeResources)`, dan diatur ke dalam antrian yang memetakan 1:1 `(Scheduling/SlurmQueues)` ke Slurm partisi. [Dalam sumber daya komputasi, dimungkinkan untuk mengonfigurasi jumlah minimum node komputasi (instance) yang harus selalu berjalan di cluster (`MinCount`), dan jumlah maksimum instance yang dapat diskalakan oleh sumber daya komputasi ke (3). `MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount) Pada waktu pembuatan klaster, atau pada pembaruan klaster, AWS ParallelCluster meluncurkan sebanyak mungkin EC2 instance Amazon seperti yang dikonfigurasi `MinCount` untuk setiap sumber daya komputasi (`Scheduling/SlurmQueues/ ComputeResources`) yang ditentukan dalam klaster. Instance yang diluncurkan untuk mencakup jumlah minimal node untuk sumber daya komputasi di cluster disebut node ***statis***. Setelah dimulai, node statis dimaksudkan untuk persisten di cluster dan mereka tidak dihentikan oleh sistem, kecuali peristiwa atau kondisi tertentu terjadi. Peristiwa semacam itu termasuk, misalnya, kegagalan Slurm atau pemeriksaan EC2 kesehatan Amazon dan perubahan Slurm status node ke DRAIN atau DOWN. EC2 Instans Amazon, dalam kisaran `1` hingga `‘MaxCount - MinCount’` (`MaxCount `*minus*` MinCount)`, diluncurkan sesuai permintaan untuk menangani peningkatan beban cluster, disebut sebagai node ***dinamis***. Sifat mereka fana, mereka diluncurkan untuk melayani pekerjaan yang tertunda dan dihentikan setelah mereka tetap menganggur untuk jangka waktu yang ditentukan oleh `Scheduling/SlurmSettings/ScaledownIdletime` dalam konfigurasi cluster (default: 10 menit). Node statis dan simpul dinamis mematuhi skema penamaan berikut: + Node statis `-st--` di mana ` = 1..ComputeResource/MinCount` + Node dinamis `-dy--` di mana ` = 1..(ComputeResource/MaxCount - ComputeResource/MinCount)` Misalnya diberikan AWS ParallelCluster konfigurasi berikut: ``` Scheduling: Scheduler: Slurm SlurmQueues: - Name: queue1 ComputeResources: - Name: c5xlarge Instances: - InstanceType: c5.xlarge MinCount: 100 MaxCount: 150 ``` Node berikut akan didefinisikan dalam Slurm ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50] queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100] ``` Ketika sumber daya komputasi memiliki`MinCount == MaxCount`, semua node komputasi yang sesuai akan statis dan semua instance akan diluncurkan pada waktu pembuatan/pembaruan cluster dan terus berjalan. Misalnya: ``` Scheduling: Scheduler: slurm SlurmQueues: - Name: queue1 ComputeResources: - Name: c5xlarge Instances: - InstanceType: c5.xlarge MinCount: 100 MaxCount: 100 ``` ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100] ``` ## Pembaruan kapasitas cluster Pembaruan kapasitas cluster termasuk menambahkan atau menghapus antrian, menghitung sumber daya atau mengubah sumber daya komputasi. `MinCount/MaxCount` Mulai dari AWS ParallelCluster versi 3.9.0, mengurangi ukuran antrian memerlukan armada komputasi dihentikan atau [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)disetel ke TERMINATE sebelum pembaruan klaster berlangsung. Tidak perlu menghentikan armada komputasi atau menyetel [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)ke TERMINATE saat: + Menambahkan antrian baru ke Penjadwalan/[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) + Menambahkan sumber daya komputasi baru `Scheduling/SlurmQueues/ComputeResources` ke antrian + Meningkatkan `MaxCount` sumber daya komputasi + Peningkatan MinCount sumber daya komputasi dan peningkatan MaxCount sumber daya komputasi yang sama setidaknya dengan jumlah yang sama ## Pertimbangan dan batasan Bagian ini dimaksudkan untuk menguraikan faktor penting, kendala, atau batasan yang harus diperhitungkan saat mengubah ukuran kapasitas cluster. + Saat menghapus antrian dari `Scheduling/SlurmQueues` semua node komputasi dengan nama`-*`, baik statis maupun dinamis, akan dihapus dari Slurm konfigurasi dan EC2 instans Amazon yang sesuai akan dihentikan. + Saat menghapus sumber daya komputasi `Scheduling/SlurmQueues/ComputeResources` dari antrian, semua node komputasi dengan nama`-*--*`, baik statis maupun dinamis, akan dihapus dari Slurm konfigurasi dan EC2 instans Amazon yang sesuai akan dihentikan. Ketika mengubah `MinCount` parameter sumber daya komputasi kita dapat membedakan dua skenario yang berbeda, jika `MaxCount` tetap sama dengan `MinCount` (kapasitas statis saja), dan jika `MaxCount` lebih besar dari `MinCount` (kapasitas statis dan dinamis campuran). ### Perubahan kapasitas hanya dengan node statis + Jika`MinCount == MaxCount`, saat meningkatkan `MinCount` (dan`MaxCount`), cluster akan dikonfigurasi dengan memperluas jumlah node statis ke nilai baru `MinCount` `-st--` dan sistem akan terus mencoba meluncurkan EC2 instans Amazon untuk memenuhi kapasitas statis baru yang diperlukan. + Jika`MinCount == MaxCount`, saat mengurangi `MinCount` (dan`MaxCount`) jumlah N, cluster akan dikonfigurasi dengan menghapus node statis N terakhir `-st--...]` dan sistem akan menghentikan instance Amazon yang sesuai. EC2 + Keadaan awal `MinCount = MaxCount = 100` + ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100] ``` + Update `-30` pada `MinCount` dan `MaxCount: MinCount = MaxCount = 70` + ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70] ``` ### Perubahan kapasitas dengan node campuran Jika`MinCount < MaxCount`, ketika meningkat `MinCount` dengan jumlah N (dengan asumsi `MaxCount` akan tetap tidak berubah), cluster akan dikonfigurasi dengan memperluas jumlah node statis ke nilai baru `MinCount` (`old_MinCount + N`): `-st--` dan sistem akan terus mencoba meluncurkan EC2 instans Amazon untuk memenuhi kapasitas statis baru yang diperlukan. Selain itu, untuk menghormati `MaxCount` kapasitas sumber daya komputasi, konfigurasi cluster diperbarui dengan *menghapus N node dinamis terakhir*: `-dy--[...]` dan sistem akan menghentikan instance Amazon EC2 yang sesuai. + Keadaan awal: `MinCount = 100; MaxCount = 150` + ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50] queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100] ``` + Perbarui \$130 ke `MinCount : MinCount = 130 (MaxCount = 150)` + ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20] queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130] ``` Jika`MinCount < MaxCount`, saat meningkatkan `MinCount` dan `MaxCount` dengan jumlah N yang sama, cluster akan dikonfigurasi dengan memperluas jumlah node statis ke nilai baru `MinCount` (`old_MinCount + N`): `-st--` dan sistem akan terus mencoba meluncurkan EC2 instans Amazon untuk memenuhi kapasitas statis baru yang diperlukan. Selain itu, tidak ada perubahan yang akan dilakukan pada jumlah node dinamis untuk menghormati yang baru `MaxCount`nilai. + Keadaan awal: `MinCount = 100; MaxCount = 150` + ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50] queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100] ``` + Perbarui \$130 ke `MinCount : MinCount = 130 (MaxCount = 180)` + ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-50] queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130] ``` Jika`MinCount < MaxCount`, ketika mengurangi `MinCount` jumlah N (dengan asumsi `MaxCount` akan tetap tidak berubah), cluster akan dikonfigurasi dengan menghapus node statis N terakhir node statis `-st--[...` dan sistem akan menghentikan instance Amazon yang sesuai. EC2 Selain itu, untuk menghormati `MaxCount` kapasitas sumber daya komputasi, konfigurasi cluster diperbarui dengan memperluas jumlah node dinamis untuk mengisi celah`MaxCount - new_MinCount: -dy--[1..]`. Dalam hal ini, karena itu adalah node dinamis, tidak ada EC2 instance Amazon baru yang akan diluncurkan kecuali penjadwal memiliki pekerjaan di pending pada node baru. + Keadaan awal: `MinCount = 100; MaxCount = 150` + ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50] queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100] ``` + Perbarui -30 pada `MinCount : MinCount = 70 (MaxCount = 120)` + ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-80] queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70] ``` Jika`MinCount < MaxCount`, saat mengurangi `MinCount` dan `MaxCount` dengan jumlah N yang sama, cluster akan dikonfigurasi dengan menghapus node statis N terakhir `-st--...]` dan sistem akan menghentikan instance Amazon yang sesuai. EC2 Selain itu, tidak ada perubahan yang akan dilakukan pada jumlah node dinamis untuk menghormati `MaxCount` nilai baru. + Keadaan awal: `MinCount = 100; MaxCount = 150` + ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50] queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100] ``` + Perbarui -30 pada `MinCount : MinCount = 70 (MaxCount = 120)` + ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-50] queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70] ``` Jika`MinCount < MaxCount`, ketika mengurangi `MaxCount` jumlah N (dengan asumsi `MinCount` akan tetap tidak berubah), cluster akan dikonfigurasi dengan menghapus N node dinamis terakhir `-dy--]` dan sistem akan menghentikan instance EC2 Amazon yang sesuai jika mereka berjalan. Tidak ada dampak yang diharapkan pada node statis. + Keadaan awal: `MinCount = 100; MaxCount = 150` + ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50] queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100] ``` + Perbarui -30 pada `MaxCount : MinCount = 100 (MaxCount = 120)` + ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20] queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100] ``` ## Dampak pada Pekerjaan Dalam semua kasus di mana node dihapus dan EC2 instance Amazon dihentikan, pekerjaan sbatch yang berjalan pada node yang dihapus akan diantrian ulang, kecuali tidak ada node lain yang memenuhi persyaratan pekerjaan. Dalam kasus terakhir ini pekerjaan gagal dengan status NODE\$1FAIL dan menghilang dari antrian, dan itu harus dikirim ulang secara manual. Jika Anda berencana untuk melakukan pembaruan pengubahan ukuran cluster, Anda dapat mencegah pekerjaan berjalan di node yang akan dihapus selama pembaruan yang direncanakan. Ini dimungkinkan dengan mengatur node yang akan dihapus dalam pemeliharaan. Perlu diketahui bahwa menyetel node dalam pemeliharaan tidak akan memengaruhi pekerjaan yang pada akhirnya sudah berjalan di node. Misalkan dengan pembaruan pengubahan ukuran cluster yang direncanakan Anda akan menghapus node`qeueu-st-computeresource-[9-10`]. Anda dapat membuat Slurm reservasi dengan perintah berikut ``` sudo -i scontrol create reservation ReservationName=maint_for_update user=root starttime=now duration=infinite flags=maint,ignore_jobs nodes=qeueu-st-computeresource-[9-10] ``` Ini akan membuat Slurm reservasi bernama `maint_for_update` pada node`qeueu-st-computeresource-[9-10]`. Dari saat reservasi dibuat, tidak ada lagi pekerjaan yang bisa berjalan ke node`qeueu-st-computeresource-[9-10]`. Perlu diketahui bahwa reservasi tidak akan mencegah pekerjaan akhirnya dialokasikan pada node`qeueu-st-computeresource-[9-10]`. Setelah pembaruan ukuran cluster, jika Slurm reservasi ditetapkan hanya pada node yang telah dihapus selama pembaruan pengubahan ukuran, reservasi pemeliharaan akan dihapus secara otomatis. Jika sebaliknya Anda telah membuat Slurm reservasi pada node yang masih ada setelah pembaruan pengubahan ukuran cluster, kami mungkin ingin menghapus reservasi pemeliharaan pada node setelah pembaruan pengubahan ukuran dilakukan, dengan menggunakan perintah berikut ``` sudo -i scontrol delete ReservationName=maint_for_update ``` Untuk detail tambahan tentang Slurm reservasi, lihat dokumen SchedMD resmi [di sini](https://slurm.schedmd.com/reservations.html). ## Proses pembaruan cluster pada perubahan kapasitas Setelah perubahan konfigurasi penjadwal, langkah-langkah berikut dijalankan selama proses pembaruan cluster: + Berhenti AWS ParallelCluster `clustermgtd (supervisorctl stop clustermgtd)` + Hasilkan diperbarui Slurm konfigurasi partisi dari AWS ParallelCluster konfigurasi + Mulai ulang `slurmctld` (dilakukan melalui resep layanan Chef) + Periksa `slurmctld` status `(systemctl is-active --quiet slurmctld.service)` + Muat ulang Slurm konfigurasi `(scontrol reconfigure)` + Mulai `clustermgtd (supervisorctl start clustermgtd)` # Menggunakan AWS Batch (`awsbatch`) scheduler dengan AWS ParallelCluster **Awas** AWS CodeBuild tidak didukung di wilayah Asia Pasifik (Malaysia) (`ap-southeast-5`) dan Asia Pasifik (Thailand) (`ap-southeast-7`). Oleh karena itu, ParallelCluster AWS Batch integrasi tidak didukung di wilayah tersebut. AWS ParallelCluster juga mendukung AWS Batch penjadwal. Topik berikut menjelaskan cara menggunakan AWS Batch. Untuk informasi tentang AWS Batch, lihat [AWS Batch](https://aws.amazon.com/batch/). Untuk dokumentasi, lihat [Panduan AWS Batch Pengguna](https://docs.aws.amazon.com/batch/latest/userguide/). **AWS ParallelCluster Perintah CLI untuk AWS Batch** Ketika Anda menggunakan `awsbatch` scheduler, perintah AWS ParallelCluster CLI AWS Batch untuk secara otomatis diinstal di node AWS ParallelCluster kepala. CLI menggunakan operasi AWS Batch API dan mengizinkan operasi berikut: + Kirim dan kelola pekerjaan. + Pantau pekerjaan, antrian, dan host. + Cerminkan perintah penjadwal tradisional. **penting** AWS ParallelCluster tidak mendukung pekerjaan GPU untuk AWS Batch. Untuk informasi selengkapnya, lihat [pekerjaan GPU](https://docs.aws.amazon.com/batch/latest/userguide/gpu-jobs.html). CLI ini didistribusikan sebagai paket terpisah. Untuk informasi selengkapnya, lihat [Dukungan penjadwal](moving-from-v2-to-v3.md#scheduler_support). **Topics** + [`awsbsub`](awsbatchcli.awsbsub-v3.md) + [`awsbstat`](awsbatchcli.awsbstat-v3.md) + [`awsbout`](awsbatchcli.awsbout-v3.md) + [`awsbkill`](awsbatchcli.awsbkill-v3.md) + [`awsbqueues`](awsbatchcli.awsbqueues-v3.md) + [`awsbhosts`](awsbatchcli.awsbhosts-v3.md) # `awsbsub` Mengirimkan pekerjaan ke antrian pekerjaan cluster. ``` awsbsub [-h] [-jn JOB_NAME] [-c CLUSTER] [-cf] [-w WORKING_DIR] [-pw PARENT_WORKING_DIR] [-if INPUT_FILE] [-p VCPUS] [-m MEMORY] [-e ENV] [-eb ENV_DENYLIST] [-r RETRY_ATTEMPTS] [-t TIMEOUT] [-n NODES] [-a ARRAY_SIZE] [-d DEPENDS_ON] [command] [arguments [arguments ...]] ``` **penting** AWS ParallelCluster tidak mendukung pekerjaan GPU untuk AWS Batch. Untuk informasi selengkapnya, lihat [pekerjaan GPU](https://docs.aws.amazon.com/batch/latest/userguide/gpu-jobs.html). ## Argumen Posisi ***command*** Mengirimkan pekerjaan (perintah yang ditentukan harus tersedia pada contoh komputasi) atau nama file yang akan ditransfer. Lihat juga `--command-file`. **arguments** (Opsional) Menentukan argumen untuk perintah atau perintah-file. ## Argumen Bernama **-jn *JOB\$1NAME*, --job-name *JOB\$1NAME*** Nama pekerjaan. Karakter pertama harus berupa huruf atau angka. Nama pekerjaan dapat berisi huruf (huruf besar dan kecil), angka, tanda hubung, dan garis bawah, dan panjangnya hingga 128 karakter. **-c *CLUSTER*, --cluster *CLUSTER*** Menentukan cluster untuk digunakan. **-cf, --command-file** Menunjukkan bahwa perintah adalah file yang akan ditransfer ke instance komputasi. Default: Salah **-w *WORKING\$1DIR*, --working-dir *WORKING\$1DIR*** Menentukan folder untuk digunakan sebagai direktori kerja pekerjaan ini. Jika direktori kerja tidak ditentukan, pekerjaan dijalankan di `job-` subfolder direktori home pengguna. Anda dapat menggunakan parameter ini atau `--parent-working-dir` parameter. **-pw *PARENT\$1WORKING\$1DIR*, --parent-working-dir *PARENT\$1WORKING\$1DIR*** Menentukan folder induk dari direktori kerja pekerjaan ini. Jika direktori kerja induk tidak ditentukan, itu default ke direktori home pengguna. Sebuah subfolder bernama `job-` dibuat di direktori kerja induk. Anda dapat menggunakan parameter ini atau `--working-dir` parameter. **-if *INPUT\$1FILE*, --input-file *INPUT\$1FILE*** Menentukan file yang akan ditransfer ke contoh komputasi, di direktori kerja pekerjaan. Anda dapat menentukan beberapa parameter file input. **-p *VCPUS*, --vcpus *VCPUS*** Menentukan jumlah v CPUs untuk cadangan untuk wadah. Ketika digunakan bersama-sama dengan`–nodes`, itu mengidentifikasi jumlah v CPUs untuk setiap node. Default: 1 **-m *MEMORY*, --memory *MEMORY*** Menentukan batas keras memori (dalam MiB) untuk menyediakan pekerjaan. Jika pekerjaan Anda mencoba untuk melebihi batas memori yang ditentukan di sini, pekerjaan berakhir. Default: 128 **-e *ENV*, --env *ENV*** Menentukan daftar dipisahkan koma nama variabel lingkungan untuk mengekspor ke lingkungan kerja. Untuk mengekspor semua variabel lingkungan, tentukan 'semua'. Perhatikan bahwa daftar variabel lingkungan 'semua' tidak termasuk yang tercantum dalam `–env-blacklist` parameter, atau variabel yang dimulai dengan `AWS_*` awalan `PCLUSTER_*` atau. **-eb *ENV\$1DENYLIST*, --env-blacklist *ENV\$1DENYLIST*** Menentukan daftar dipisahkan koma nama variabel lingkungan untuk **tidak** mengekspor ke lingkungan kerja. Secara default,`HOME`,`PWD`,`USER`,`PATH`,`LD_LIBRARY_PATH`,`TERM`, dan tidak `TERMCAP` diekspor. **-r *RETRY\$1ATTEMPTS*, --retry-attempts *RETRY\$1ATTEMPTS*** Menentukan jumlah kali untuk memindahkan pekerjaan ke `RUNNABLE` status. Anda dapat menentukan usaha antara 1 dan 10. Jika nilai percobaan lebih besar dari 1, pekerjaan akan dicoba lagi jika gagal, sampai telah pindah ke `RUNNABLE` status untuk jumlah yang ditentukan kali. Default: 1 **-t *TIMEOUT*, --timeout *TIMEOUT*** Menentukan durasi waktu dalam hitungan detik (diukur dari `startedAt` stempel waktu usaha pekerjaan) setelah itu AWS Batch mengakhiri pekerjaan Anda jika belum selesai. Nilai batas waktu harus minimal 60 detik. **-n *NODES*, --nodes *NODES*** Menentukan jumlah node untuk cadangan untuk pekerjaan itu. Tentukan nilai untuk parameter ini untuk mengaktifkan pengiriman paralel multi-node. Ketika [`CapacityType`](Scheduling-v3.md#yaml-Scheduling-AwsBatchQueues-CapacityType)parameter [`Scheduler`](Scheduling-v3.md#yaml-Scheduling-Scheduler)/[`AwsBatchQueues`](Scheduling-v3.md#Scheduling-v3-AwsBatchQueues)/disetel ke`SPOT`, multi-node parallel jobs *tidak* didukung. Selain itu, harus ada peran `AWSServiceRoleForEC2Spot` terkait layanan di akun Anda. Anda dapat membuat peran ini dengan AWS CLI perintah berikut: ``` $ aws iam create-service-linked-role --aws-service-name spot.amazonaws.com ``` Untuk informasi selengkapnya, lihat [Peran terkait layanan untuk permintaan Instans Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html#service-linked-roles-spot-instance-requests) di *Panduan Pengguna Amazon Elastic Compute Cloud untuk* Instans Linux. **-a *ARRAY\$1SIZE*, --array-size *ARRAY\$1SIZE*** Menunjukkan ukuran array. Anda dapat menentukan nilai antara 2 dan 10.000. Jika Anda menentukan properti array untuk suatu tugas, itu menjadi tugas array. **-d *DEPENDS\$1ON*, --depends-on *DEPENDS\$1ON*** Menentukan daftar dependensi yang dipisahkan titik koma untuk pekerjaan. Sebuah pekerjaan dapat bergantung pada maksimal 20 pekerjaan. Anda dapat menentukan dependensi `SEQUENTIAL` tipe tanpa menentukan ID pekerjaan untuk pekerjaan array. Ketergantungan sekuensial memungkinkan setiap pekerjaan array anak untuk menyelesaikan secara berurutan, dimulai dari indeks 0. Anda juga dapat menentukan dependensi tipe N\$1TO\$1N dengan ID pekerjaan untuk pekerjaan array. Ketergantungan N\$1TO\$1N berarti bahwa setiap turunan indeks dari pekerjaan ini harus menunggu turunan indeks yang sesuai dari setiap dependensi selesai sebelum dapat dimulai. Sintaks untuk parameter ini adalah “joBid=**, type=**;...”. # `awsbstat` Menampilkan pekerjaan yang dikirimkan dalam antrean pekerjaan klaster. ``` awsbstat [-h] [-c CLUSTER] [-s STATUS] [-e] [-d] [job_ids [job_ids ...]] ``` ## Argumen Posisi ***job\$1ids*** Menentukan daftar spasi-dipisahkan dari pekerjaan IDs untuk ditampilkan dalam output. Jika pekerjaan adalah array pekerjaan, semua pekerjaan anak ditampilkan. Jika satu pekerjaan diminta, itu ditampilkan dalam versi terperinci. ## Argumen Bernama **-c *CLUSTER*, --cluster *CLUSTER*** Menunjukkan cluster yang akan digunakan. **-s *STATUS*, --status *STATUS*** Menentukan daftar status pekerjaan yang dipisahkan koma untuk disertakan. Status pekerjaan default adalah “aktif.”. Nilai yang diterima adalah: `SUBMITTED``PENDING`,`RUNNABLE`,`STARTING`,`RUNNING`,`SUCCEEDED`,`FAILED`, dan`ALL`. Default: “`SUBMITTED``PENDING`,`RUNNABLE`,,`STARTING`,`RUNNING`” **-e, --expand-children** Memperluas pekerjaan dengan anak-anak (baik array dan multi-node parallel). Default: Salah **-d, --details** Menampilkan detail pekerjaan. Default: Salah # `awsbout` Menunjukkan output dari pekerjaan yang diberikan. ``` awsbout [-h] [-c CLUSTER] [-hd HEAD] [-t TAIL] [-s] [-sp STREAM_PERIOD] job_id ``` ## Argumen Posisi ***job\$1id*** Menentukan ID pekerjaan. ## Argumen Bernama **-c *CLUSTER*, --cluster *CLUSTER*** Menunjukkan cluster yang akan digunakan. **-hd *HEAD*, --head *HEAD*** Mendapat *HEAD* baris pertama dari output pekerjaan. **-t *TAIL*, --tail *TAIL*** Mendapat baris terakhir dari output pekerjaan. **-s, --stream** Mendapat output pekerjaan, dan kemudian menunggu output tambahan yang akan diproduksi. Argumen ini dapat digunakan bersama dengan —tail untuk memulai dari baris terbaru dari output pekerjaan. Default: Salah **-sp *STREAM\$1PERIOD*, --stream-period *STREAM\$1PERIOD*** Mengatur periode streaming. Default: 5 # `awsbkill` Membatalkan atau menghentikan pekerjaan yang dikirimkan dalam klaster. ``` awsbkill [-h] [-c CLUSTER] [-r REASON] job_ids [job_ids ... ] ``` ## Argumen Posisi ***job\$1ids*** Menentukan daftar spasi-dipisahkan pekerjaan IDs untuk membatalkan atau mengakhiri. ## Argumen Bernama **-c *CLUSTER*, --cluster *CLUSTER*** Menunjukkan nama cluster yang akan digunakan. **-r *REASON*, --reason *REASON*** Menunjukkan pesan untuk dilampirkan ke pekerjaan, menjelaskan alasan untuk membatalkannya. Default:”Terminated by the user” # `awsbqueues` Menampilkan antrian pekerjaan yang terkait dengan cluster. ``` awsbqueues [-h] [-c CLUSTER] [-d] [job_queues [job_queues ... ]] ``` ## Argumen posisi ***job\$1queues*** Menentukan daftar spasi dipisahkan dari nama antrian untuk ditampilkan. Jika satu antrian diminta, itu ditampilkan dalam versi rinci. ## Argumen bernama **-c *CLUSTER*, --cluster *CLUSTER*** Menentukan nama cluster untuk digunakan. **-d, --details** Menunjukkan apakah akan menampilkan detail antrian. Default: Salah # `awsbhosts` Menampilkan host yang termasuk dalam lingkungan komputasi cluster. ``` awsbhosts [-h] [-c CLUSTER] [-d] [instance_ids [instance_ids ... ]] ``` ## Argumen Posisi ***instance\$1ids*** Menentukan daftar spasi-dipisahkan dari contoh. IDs Jika satu contoh diminta, itu ditampilkan dalam versi rinci. ## Argumen Bernama **-c *CLUSTER*, --cluster *CLUSTER*** Menentukan nama cluster yang akan digunakan. **-d, --details** Menunjukkan apakah akan menampilkan detail host. Default: Salah