Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Perbarui versi penjadwal AWS Cluster PCS Gunakan langkah-langkah ini untuk memperbarui versi penjadwal di klaster Anda. Ada dua opsi tergantung pada apakah Anda dapat mentolerir gangguan pekerjaan. Untuk informasi selengkapnya tentang memilih di antara opsi, lihat[Memperbarui versi penjadwal cluster di AWS PCS](working-with_clusters_version_update.md). ## Opsi 1: Pembaruan bergulir Pengontrol diperbarui saat armada terus berjalan. Node yang ada terus menggunakan versi Slurm sebelumnya sampai habis dan diganti. Node baru diluncurkan setelah pembaruan menggunakan versi target. Menjalankan pekerjaan tidak terganggu. **Kapan menggunakan:** + Pengontrol cluster ada di Slurm versi 24.05 atau yang lebih baru. + Anda dapat memberikan AMI yang menyertakan versi Slurm saat ini dan target. ### Langkah 0 - Periksa status awal Cluster Anda menjalankan versi pengontrol “A” (misalnya 24.11) dan Anda ingin bermigrasi ke versi “B” (misalnya 25.11). Konfirmasikan semua node komputasi di armada Anda menjalankan versi mayor yang sama, menggunakan perintah ini dari node cluster: ``` scontrol show nodes | grep "Version=" # Example output: # NodeAddr=compute-1 NodeHostName=compute-1 Version=24.11.7 # NodeAddr=compute-2 NodeHostName=compute-2 Version=24.11.7 ``` Konfirmasikan versi agen AWS PCS pada node komputasi. Connect ke node dengan Systems Manager dan periksa log bootstrap: ``` grep "PCS Agent version" /var/log/amazon/pcs/bootstrap.log | tail -1 # Example output: # /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Bootstrap starting with PCS Agent version: 1.3.2-1 ``` Pembaruan bergulir memerlukan agen AWS PCS versi 1.4.0 atau yang lebih baru pada semua AMI node komputasi. Untuk informasi selengkapnya, lihat [AWS Versi agen PCS](pcs-agent-versions.md). ### Langkah 1 - Siapkan dan luncurkan AMI versi ganda Buat atau identifikasi AMI yang **menyertakan Slurm versi A dan versi B, dan agen AWS PCS terbaru**. + Anda dapat menggunakan **PCS-ready DLAMI** terbaru. AMI semacam itu dikirimkan dengan tiga versi Slurm terbaru yang didukung. Untuk informasi selengkapnya, lihat [Menggunakan PCS-ready DLAMI dengan AWS PCS](working-with_ami_pcs-ready-dlami.md). + Anda dapat membangun **AMI kustom**, mengikuti langkah-langkah instalasi untuk paket Slurm dan agen AWS PCS. Untuk informasi selengkapnya, lihat [Gambar Mesin Amazon Kustom (AMIs) untuk AWS PCS](working-with_ami_custom.md). + Anda **tidak dapat** menggunakan **sampel AWS PCS AMI**. AMI semacam itu tidak dirancang untuk produksi dan saat ini hanya mencakup satu versi Slurm. **catatan** Jika AMI Anda menyertakan lebih dari dua versi Slurm, AWS PCS secara otomatis memilih versi yang cocok dengan pengontrol. Memiliki versi tambahan yang diinstal tidak menyebabkan masalah. Setelah AMI siap: 1. Panggil `UpdateComputeNodeGroup` setiap grup node komputasi untuk mengatur AMI versi ganda yang baru. Node akan diatur ke DRAIN oleh AWS PCS dan akan bermigrasi ke AMI baru. 1. Tunggu node yang terkuras untuk menyelesaikan pekerjaannya, menghentikan, dan digantikan oleh node menggunakan AMI versi ganda yang baru. Periksa semua instans EC2 di cluster menggunakan AMI baru dengan: ``` aws ec2 describe-instances \ --filters "Name=tag:aws:pcs:cluster-id,Values={{cluster-id}}" \ --query "Reservations[].Instances[].[InstanceId,ImageId,State.Name]" \ --output table ``` ### Langkah 2 - Perbarui pengontrol cluster Panggil `UpdateCluster` dengan `scheduler.version` set ke versi B. ------ #### [ Konsol Manajemen AWS ] 1. Buka konsol AWS PCS di [https://console.aws.amazon.com/pcs/](https://console.aws.amazon.com/pcs/). 1. Pada panel navigasi, silakan pilih **Klaster**. 1. Pilih cluster yang akan diperbarui dan pilih **Edit**. 1. Di bawah **Detail cluster**, pilih versi penjadwal target dari dropdown **Scheduler**. 1. Pilih **Perbarui** untuk mengirimkan pembaruan versi. 1. Pantau status cluster. Cluster menunjukkan seperti `UPDATING` selama pembaruan dan kembali ke `ACTIVE` saat selesai. Pembaruan biasanya selesai dalam 5-15 menit. ------ #### [ AWS CLI ] ``` aws pcs update-cluster \ --cluster-identifier {{cluster-id}} \ --scheduler version={{25.11}} ``` Tunggu cluster kembali ke`ACTIVE`. Pembaruan biasanya selesai dalam 5-15 menit. ------ Selama operasi ini, pengontrol tidak tersedia secara singkat: + Menjalankan pekerjaan pada node komputasi **terus dijalankan**. + Pengajuan pekerjaan baru dan perintah penjadwal tidak tersedia sampai pembaruan selesai. + Penskalaan otomatis dijeda hingga cluster kembali ke. `ACTIVE` Setelah pembaruan, armada komputasi berada dalam **status campuran**: node yang berjalan sebelum pembaruan terus menggunakan Slurm versi A`slurmd`; node baru menggunakan Slurm versi B. Ini diharapkan. **catatan** Jangan menambahkan pengaturan Slurm khusus untuk versi B sementara armada masih berisi node pada versi A. Konfigurasi didistribusikan ke semua node; yang lama `slurmd` mungkin tidak mengenali parameter baru. Jika cluster tidak kembali ke `ACTIVE` atau `UPDATE_FAILED` dalam waktu 30 menit, hubungi AWS Support untuk bantuan. ### Langkah 3 - Tiriskan node yang masih menjalankan Slurm versi A Identifikasi dan tiriskan node masih pada versi sebelumnya. Dari node cluster, jalankan: ``` scontrol show nodes | grep "Version=" scontrol update NodeName={{node}} State=DRAIN Reason="Slurm version update" ``` Setelah node yang dikeringkan menyelesaikan pekerjaan mereka saat ini, mereka berhenti dan digantikan oleh node pada Slurm versi B. ### Langkah 4 - Verifikasi armada yang konsisten pada Slurm versi B Konfirmasikan semua node melaporkan versi B. Dari node cluster, jalankan: ``` scontrol show nodes | grep "Version=" ``` Semua node sekarang harus melaporkan versi Slurm B. Pembaruan selesai. ## Opsi 2: daur Full-fleet ulang Seluruh armada dihentikan sebelum pengontrol diperbarui, kemudian ditingkatkan kembali dari AMI baru dengan versi Slurm target. Prosedur ini lebih sederhana, tetapi mengharuskan semua node dan pekerjaan yang sedang berjalan dihentikan. **Kapan menggunakan:** + Anda tidak dapat menyediakan AMI dengan kedua versi Slurm diinstal. + Pengontrol cluster ada di versi 23.11 (Opsi 1 tidak tersedia untuk klaster 23.11). **catatan** Mengakhiri seluruh armada sekaligus meningkatkan kemungkinan kesalahan kapasitas yang tidak mencukupi saat melakukan penskalaan cadangan. Pertimbangkan untuk menggunakan kapasitas cadangan atau penjadwalan selama jam-jam sibuk. ### Langkah 0 - Periksa status awal Cluster Anda menjalankan versi pengontrol “A” (misalnya 24.11) dan Anda ingin bermigrasi ke versi “B” (misalnya 25.11). Konfirmasikan semua node komputasi di armada Anda menjalankan versi mayor yang sama, menggunakan perintah ini dari node cluster: ``` scontrol show nodes | grep "Version=" # Example output: # NodeAddr=compute-1 NodeHostName=compute-1 Version=24.11.7 # NodeAddr=compute-2 NodeHostName=compute-2 Version=24.11.7 ``` Konfirmasikan versi agen AWS PCS pada node komputasi. Connect ke node dengan Systems Manager dan periksa log bootstrap: ``` grep "PCS Agent version" /var/log/amazon/pcs/bootstrap.log | tail -1 # Example output: # /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Bootstrap starting with PCS Agent version: 1.3.2-1 ``` Gunakan agen AWS PCS terbaru pada AMI target Anda. Untuk informasi selengkapnya, lihat [AWS Versi agen PCS](pcs-agent-versions.md). ### Langkah 1 - Siapkan AMI target Buat atau identifikasi AMI yang menyertakan **Slurm versi B dan agen AWS PCS terbaru.** + Anda dapat menggunakan **PCS-ready DLAMI** terbaru. AMI semacam itu dikirimkan dengan tiga versi Slurm terbaru yang didukung. Untuk informasi selengkapnya, lihat [Menggunakan PCS-ready DLAMI dengan AWS PCS](working-with_ami_pcs-ready-dlami.md). + Anda dapat membangun **AMI kustom**, mengikuti langkah-langkah instalasi untuk paket Slurm dan agen AWS PCS. Untuk informasi selengkapnya, lihat [Gambar Mesin Amazon Kustom (AMIs) untuk AWS PCS](working-with_ami_custom.md). + Menggunakan **sampel AWS PCS AMI tidak dianjurkan**. AMI semacam itu tidak dirancang untuk produksi. ### Langkah 2 — Turunkan seluruh armada Rekam saat ini `minNodeCount` dan `maxNodeCount` untuk setiap grup node komputasi - Anda akan mengembalikannya di Langkah 4. ``` for cng in $(aws pcs list-compute-node-groups --cluster-identifier {{cluster-id}} --query "computeNodeGroups[].id" --output text); do aws pcs get-compute-node-group \ --cluster-identifier {{cluster-id}} \ --compute-node-group-identifier "$cng" \ --query "computeNodeGroup.{Id:id,AmiId:amiId,Min:scalingConfiguration.minInstanceCount,Max:scalingConfiguration.maxInstanceCount}" \ --output table done ``` **Awas** Operasi berikut mengakhiri semua node yang berjalan dan pekerjaan pada mereka. Setel `minNodeCount` dan `maxNodeCount` ke `0` pada setiap grup node komputasi: ``` aws pcs update-compute-node-group \ --cluster-identifier {{cluster-id}} \ --compute-node-group-identifier {{cng-id}} \ --scaling-configuration '{"minNodeCount": 0, "maxNodeCount": 0}' ``` Verifikasi tidak ada instance yang ditandai `aws:pcs:cluster-id` yang cocok dengan klaster Anda yang berjalan sebelum melanjutkan: ``` aws ec2 describe-instances \ --filters "Name=tag:aws:pcs:cluster-id,Values={{cluster-id}}" \ --query "Reservations[].Instances[].[InstanceId,ImageId,State.Name]" \ --output table ``` ### Langkah 3 - Perbarui pengontrol cluster ------ #### [ Konsol Manajemen AWS ] 1. Buka konsol AWS PCS di [https://console.aws.amazon.com/pcs/](https://console.aws.amazon.com/pcs/). 1. Pada panel navigasi, silakan pilih **Klaster**. 1. Pilih cluster yang akan diperbarui dan pilih **Edit**. 1. Di bawah **Detail cluster**, pilih versi penjadwal target dari dropdown **Scheduler**. 1. Pilih **Perbarui** untuk mengirimkan pembaruan versi. 1. Pantau status cluster. Cluster menunjukkan seperti `UPDATING` selama pembaruan dan kembali ke `ACTIVE` saat selesai. Pembaruan biasanya selesai dalam 5-15 menit. ------ #### [ AWS CLI ] ``` aws pcs update-cluster \ --cluster-identifier {{cluster-id}} \ --scheduler version={{25.11}} ``` Tunggu cluster kembali ke`ACTIVE`. Pembaruan biasanya selesai dalam 5-15 menit. Jika cluster tidak kembali ke `ACTIVE` atau `UPDATE_FAILED` dalam waktu 30 menit, hubungi AWS Support untuk bantuan. ------ ### Langkah 4 - Perbarui grup node komputasi dan kembalikan kapasitas Untuk setiap grup node komputasi, atur AMI baru dan kembalikan batas kapasitas minimum dan maksimum asli: ``` aws pcs update-compute-node-group \ --cluster-identifier {{cluster-id}} \ --compute-node-group-identifier {{cng-id}} \ --ami-id {{new-ami-id}} \ --scaling-configuration '{"minNodeCount": {{previous-min}}, "maxNodeCount": {{previous-max}}}' ``` Skala cluster kembali. Semua node baru menjalankan Slurm versi B dengan agen AWS PCS terbaru. ## Contoh: Memperbarui di beberapa versi Jika versi target berada di luar jendela kompatibilitas versi Anda saat ini, Anda harus memindahkan pengontrol melalui satu atau lebih versi perantara, memperbaruinya satu hop pada satu waktu. Setiap hop harus menargetkan versi yang didukung dalam jendela kompatibilitas versi pengontrol saat ini. Karena [Opsi 2: daur Full-fleet ulang](#version_update-procedure-option2) skala armada ke nol sebelum memperbarui pengontrol, tidak ada node komputasi yang berjalan saat pengontrol bergerak antar versi. Akibatnya, AMI Anda dapat menggunakan versi target **akhir** secara langsung - hanya pembaruan pengontrol (Langkah 3) yang diulang untuk setiap lompatan. Contoh berikut memperbarui cluster dari **23.11 ke 25.11** menggunakan prosedur Opsi 2. 23.11 berada di luar jendela kompatibilitas 25.11, sehingga pengontrol diperbarui dalam dua hop (23.11 ke 25.05, kemudian 25.05 ke 25.11). Ikuti langkah-langkah Opsi 2, dengan Langkah 3 dibagi menjadi satu pembaruan per hop: 1. **Langkah 1 — Siapkan AMI target.** Buat atau identifikasi AMI dengan versi **final** (25.11) dan agen AWS PCS terbaru. Lihat [Langkah 1 - Siapkan AMI target](#version_update-procedure-option2-step1). 1. **Langkah 2 — Turunkan seluruh armada.** Rekam kapasitas saat ini (lihat[Langkah 2 — Turunkan seluruh armada](#version_update-procedure-option2-step2)), lalu atur setiap grup node komputasi ke nol. ``` aws pcs update-compute-node-group \ --cluster-identifier {{my-cluster}} \ --compute-node-group-identifier {{my-cng}} \ --scaling-configuration '{"minNodeCount": 0, "maxNodeCount": 0}' ``` 1. **Langkah 3a - Perbarui pengontrol dari 23.11 ke 25.05.** Tunggu cluster kembali ke`ACTIVE`. ``` aws pcs update-cluster --cluster-identifier {{my-cluster}} \ --scheduler version=25.05 ``` 1. **Langkah 3b - Perbarui pengontrol dari 25.05 ke 25.11.** Tunggu cluster kembali ke`ACTIVE`. ``` aws pcs update-cluster --cluster-identifier {{my-cluster}} \ --scheduler version=25.11 ``` 1. **Langkah 4 - Perbarui grup node komputasi dan kembalikan kapasitas.** Tetapkan AMI 25.11 pada setiap grup node komputasi dan kembalikan batas kapasitas asli (lihat[Langkah 4 - Perbarui grup node komputasi dan kembalikan kapasitas](#version_update-procedure-option2-step4)). ``` aws pcs update-compute-node-group \ --cluster-identifier {{my-cluster}} \ --compute-node-group-identifier {{my-cng}} \ --ami-id {{ami-0123456789abcdef0}} \ --scaling-configuration '{"minNodeCount": {{previous-min}}, "maxNodeCount": {{previous-max}}}' ``` **catatan** Setiap hop pengontrol harus mendarat pada versi dalam jendela kompatibilitas yang sebelumnya. Untuk menemukan versi perantara yang valid, lihat[Kompatibilitas versi](working-with_clusters_version_update.md#version_update-cluster-compatibility). Armada tetap pada nol melalui Langkah 3a dan 3b, jadi tidak diperlukan pembaruan AMI perantara.