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
<a name="working-with_clusters_version_update_troubleshooting"></a>

Topik ini membantu Anda mengidentifikasi dan menyelesaikan masalah umum yang dapat terjadi saat memperbarui versi penjadwal di klaster.
+ [Node komputasi gagal terhubung setelah pembaruan](#update-troubleshooting-nodes-fail)
+ [Permintaan pembaruan ditolak dengan ValidationException](#update-troubleshooting-validation-error)
+ [Cluster tetap dalam status UPDATE](#update-troubleshooting-stuck-updating)
+ [Cluster memasuki status UPDATE\_FAILED setelah pembaruan](#update-troubleshooting-update-failed)
+ [Node komputasi gagal dimulai karena kesalahan penguraian konfigurasi](#update-troubleshooting-config-parse)
+ [Cluster tidak tersedia setelah pembaruan karena konfigurasi QoS tidak valid](#update-troubleshooting-qos-bootloop)

## Node komputasi gagal terhubung setelah pembaruan
<a name="update-troubleshooting-nodes-fail"></a>

### Penyebab umum
<a name="update-troubleshooting-nodes-fail-cause"></a>

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
<a name="update-troubleshooting-nodes-fail-diagnosis"></a>

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, lihat[Log penjadwal di AWS PCS](monitoring_scheduler-logs.md).

**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, lihat[Mengambil log instance](troubleshooting-compute-node-bootstrap.md#troubleshooting-compute-node-bootstrap-retrieve-logs).

### Resolusi
<a name="update-troubleshooting-nodes-fail-resolution"></a>

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, lihat[Kompatibilitas versi](working-with_clusters_version_update.md#version_update-cluster-compatibility).

Untuk informasi tentang membuat AMI kustom dengan versi penjadwal yang benar, lihat[Gambar Mesin Amazon (AMI) untuk AWS PCS](working-with_ami.md).

## Permintaan pembaruan ditolak dengan ValidationException
<a name="update-troubleshooting-validation-error"></a>

### Penyebab umum
<a name="update-troubleshooting-validation-error-cause"></a>

`UpdateCluster`Permintaan segera kembali dengan `ValidationException` kesalahan yang menunjukkan pembaruan tidak didukung. Ini terjadi ketika:
+ Versi target berada di luar [jendela kompatibilitas](https://slurm.schedmd.com/upgrades.html#compatibility_window) 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
<a name="update-troubleshooting-validation-error-resolution"></a>

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 kembali`ACTIVE`, lalu perbarui ke 25.11.

Jika versi targetnya adalah EOL, pilih versi yang didukung yang lebih baru. Untuk informasi tentang versi yang didukung, lihat[Versi slurm di AWS PCS](slurm-versions.md).

## Cluster tetap dalam status UPDATE
<a name="update-troubleshooting-stuck-updating"></a>

### Penyebab umum
<a name="update-troubleshooting-stuck-updating-cause"></a>

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
<a name="update-troubleshooting-stuck-updating-resolution"></a>

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
<a name="update-troubleshooting-update-failed"></a>

### Penyebab umum
<a name="update-troubleshooting-update-failed-cause"></a>

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

### Resolusi
<a name="update-troubleshooting-update-failed-resolution"></a>

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
<a name="update-troubleshooting-config-parse"></a>

### Penyebab umum
<a name="update-troubleshooting-config-parse-cause"></a>

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](https://slurm.schedmd.com/upgrades.html#compatibility_window), 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
<a name="update-troubleshooting-config-parse-resolution"></a>

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, lihat[Gambar Mesin Amazon (AMI) untuk AWS PCS](working-with_ami.md). Untuk informasi tentang versi agen AWS PCS, lihat[AWS Versi agen PCS](pcs-agent-versions.md).

## Cluster tidak tersedia setelah pembaruan karena konfigurasi QoS tidak valid
<a name="update-troubleshooting-qos-bootloop"></a>

### Penyebab umum
<a name="update-troubleshooting-qos-bootloop-cause"></a>

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` melalui`DenyQOS`,, `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
<a name="update-troubleshooting-qos-bootloop-resolution"></a>

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 menghapus`AllowQOS`,`DenyQOS`, atau `QOS` parameter sebelum memperbarui cluster.