View a markdown version of this page

Pemecahan Masalah AWS Pembaruan versi cluster PCS - AWS PCS

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

Pemecahan Masalah AWS Pembaruan versi cluster PCS

Topik ini membantu Anda mengidentifikasi dan menyelesaikan masalah umum yang dapat terjadi saat memperbarui versi penjadwal di klaster.

Node komputasi gagal terhubung setelah pembaruan

Penyebab umum

Setelah memperbarui cluster, node komputasi yang baru diluncurkan gagal mendaftar dengan pengontrol. Node mulai tetapi tidak pernah muncul dalam sinfo output, dan grup node komputasi dapat berputar melalui instance berulang kali. Ini terjadi ketika AMI grup node komputasi berisi versi penjadwal yang berada di luar jendela kompatibilitas versi pengontrol baru.

Misalnya, jika Anda memperbarui klaster dari 24.11 ke 25.11 tetapi grup node komputasi masih menggunakan AMI dengan Slurm 23.11, instance baru tidak dapat terhubung karena 23.11 berada di luar jendela kompatibilitas 25.11.

Cara mendiagnosa

Anda dapat mengonfirmasi masalah ini dengan memeriksa log di dua tempat:

Log penjadwal

Jika Anda mengaktifkan pencatatan penjadwal, periksa log penjadwal di CloudWatch Log untuk kesalahan yang mirip dengan berikut ini:

error: unpack_header: protocol_version 10240 not supported error: slurm_unpack_received_msg: [ip-10-0-1-23] Incompatible versions of client and server code

Kesalahan ini menunjukkan bahwa node komputasi dengan versi penjadwal yang tidak kompatibel mencoba terhubung ke pengontrol. Untuk informasi tentang menyiapkan pencatatan penjadwal, lihatLog penjadwal di AWS PCS.

Hitung log instance node

Ambil keluaran konsol instance atau sambungkan melalui Systems Manager dan periksa log bootstrap untuk kesalahan yang mirip dengan berikut ini:

error: _fetch_child: failed to fetch remote configs: Incompatible versions of client and server error: _establish_configuration: failed to load configs error: slurmd initialization failed

Untuk informasi selengkapnya tentang mengambil log instance, lihatAmbil log contoh.

Resolusi

Perbarui grup node komputasi untuk menggunakan AMI yang berisi versi penjadwal dalam jendela kompatibilitas versi cluster baru Anda:

aws pcs update-compute-node-group \ --cluster-identifier my-cluster \ --compute-node-group-identifier my-cng \ --ami-id ami-0123456789abcdef0

Untuk menentukan versi penjadwal mana yang kompatibel dengan cluster Anda, lihatKompatibilitas versi.

Untuk informasi tentang membuat AMI kustom dengan versi penjadwal yang benar, lihatGambar Mesin Amazon (AMI) untuk AWS PCS.

Permintaan pembaruan ditolak dengan ValidationException

Penyebab umum

UpdateClusterPermintaan segera kembali dengan ValidationException kesalahan yang menunjukkan pembaruan tidak didukung. Ini terjadi ketika:

  • Versi target berada di luar jendela kompatibilitas versi saat ini.

  • Versi target ditetapkan sebagai End of Life (EOL) dan tidak lagi menjadi target pembaruan yang valid.

  • Versi target lebih lama dari atau sama dengan versi saat ini (penurunan versi tidak didukung).

Resolusi

Jika versi target berada di luar jendela kompatibilitas, lakukan pembaruan dalam beberapa langkah. Setiap langkah harus menargetkan versi yang didukung dalam jendela kompatibilitas. Misalnya, untuk beralih dari 23.11 ke 25.11, pembaruan pertama ke 25.05, tunggu cluster kembaliACTIVE, lalu perbarui ke 25.11.

Jika versi targetnya adalah EOL, pilih versi yang didukung yang lebih baru. Untuk informasi tentang versi yang didukung, lihatVersi slurm di AWS PCS.

Cluster tetap dalam status UPDATE

Penyebab umum

Cluster tetap dalam UPDATING keadaan lebih lama dari yang diharapkan (lebih dari 20 menit). Ini dapat terjadi karena masalah internal sementara selama proses pembaruan.

Resolusi

AWS PCS secara otomatis memulihkan cluster yang macet dalam UPDATING keadaan. Jika cluster tidak kembali ke ACTIVE atau UPDATE_FAILED dalam waktu 30 menit, hubungi AWS Support untuk bantuan.

Cluster memasuki status UPDATE_FAILED setelah pembaruan

Penyebab umum

Transisi cluster ke UPDATE_FAILED status selama pembaruan. Ini dapat terjadi ketika kesalahan layanan sementara mencegah pembaruan selesai dengan sukses.

Resolusi

Coba lagi pembaruan dengan mengirimkan permintaan yang sama UpdateCluster lagi. Cluster dalam UPDATE_FAILED status menerima permintaan pembaruan baru. Jika pembaruan terus gagal, hubungi AWS Support.

Node komputasi gagal dimulai karena kesalahan penguraian konfigurasi

Penyebab umum

Setelah memperbarui cluster, node komputasi gagal memulai dan tidak pernah muncul di sinfo output. Log instance node komputasi menunjukkan kesalahan yang mirip dengan berikut ini:

error: _parse_next_key: Parsing error at unrecognized key: HashPlugin error: Invalid DebugFlag: AuditRPCs fatal: Unable to process configuration file

Ini terjadi ketika node komputasi yang menjalankan scheduler versi 23.11 menerima konfigurasi dari versi cluster yang lebih baru. Versi penjadwal setelah 23.11 memperkenalkan arahan konfigurasi baru yang tidak dapat diuraikan oleh 23.11. Tidak seperti versi lain dalam jendela kompatibilitas, node komputasi 23.11 tidak dapat terhubung ke cluster yang lebih baru karena kesalahan fatal pada kunci konfigurasi yang tidak dikenal.

Masalah ini juga dapat terjadi jika AMI kustom Anda menggunakan versi agen AWS PCS yang lebih lama dari v1.4.0. Versi agen yang lebih lama tidak mendukung fallback versi otomatis untuk daemon node komputasi.

Resolusi

Bangun kembali AMI kustom Anda dengan persyaratan berikut:

  • Penjadwal versi 24.05 atau yang lebih baru

  • AWS Agen PCS versi 1.4.0 atau yang lebih baru

Kemudian perbarui grup node komputasi untuk menggunakan AMI baru:

aws pcs update-compute-node-group \ --cluster-identifier my-cluster \ --compute-node-group-identifier my-cng \ --ami-id ami-0123456789abcdef0

Untuk informasi tentang membuat AMI kustom, lihatGambar Mesin Amazon (AMI) untuk AWS PCS. Untuk informasi tentang versi agen AWS PCS, lihatAWS Versi agen PCS.

Cluster tidak tersedia setelah pembaruan karena konfigurasi QoS tidak valid

Penyebab umum

Setelah memperbarui ke versi 25.11, cluster memasuki UPDATE_FAILED status atau penjadwal menjadi tidak tersedia. Anda tidak dapat mengirimkan pekerjaan atau menjalankan perintah penjadwal. Log penjadwal menunjukkan kesalahan yang mirip dengan yang berikut ini:

error: Invalid Allow/DenyQOS value: low fatal: Partition my-queue has an invalid DenyQOS (low), please check your configuration

Hal ini terjadi ketika antrian (partisi) referensi nama QoS AllowQOS melaluiDenyQOS,, QOS atau pengaturan yang tidak ada dalam database akuntansi Slurm. Slurm 25.11 memperkenalkan validasi referensi QoS yang lebih ketat pada startup scheduler. Versi sebelumnya mengizinkan referensi ke nama QoS yang tidak ada tanpa kesalahan.

Resolusi

Sebelum memperbarui ke versi 25.11, verifikasi bahwa semua nama QoS yang direferensikan dalam konfigurasi antrian Anda ada di database akuntansi. Connect ke node login dan jalankan perintah berikut untuk memeriksa apakah QoS ada:

sacctmgr show qos where name=low format=name

Jika QoS tidak ada, buat sebelum mencoba pembaruan:

sacctmgr add qos low

Atau, hapus referensi QoS dari konfigurasi antrian Anda dengan memperbarui pengaturan kustom Slurm antrian untuk menghapusAllowQOS,DenyQOS, atau QOS parameter sebelum memperbarui cluster.