Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Memecahkan masalah bootstrap node komputasi dan masalah pendaftaran di PCS AWS
Ketika node komputasi gagal melakukan bootstrap atau mendaftar dengan benar dengan cluster AWS PCS Anda, Anda mungkin mengalami gejala berikut:
+ Pekerjaan tidak dimulai
+ Anda tidak dapat terhubung ke instance di AWS Systems Manager
+ Instans dimatikan secara tak terduga
+ Contoh terus diganti
Kegagalan ini dapat disebabkan oleh masalah selama peluncuran instans EC2 atau selama proses bootstrap node komputasi AWS PCS. Topik ini menjelaskan prosedur untuk membantu Anda memecahkan masalah selama proses bootstrap node AWS PCS. Untuk informasi selengkapnya tentang pemecahan masalah peluncuran instans EC2, lihat [Memecahkan masalah peluncuran instans Amazon EC2 di Panduan Pengguna Amazon Elastic](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html) *Compute* Cloud.
Kegagalan bootstrap terjadi ketika instans EC2 berhasil diluncurkan tetapi gagal selama proses bergabung dengan cluster AWS PCS. Proses bootstrap mencakup dua fase utama:
+ **Registrasi node** - Instans EC2 memanggil tindakan [RegisterComputeNodeGroupInstance](https://docs.aws.amazon.com/pcs/latest/APIReference/API_RegisterComputeNodeGroupInstance.html) AWS PCS API untuk mendaftar dengan layanan AWS PCS. Kegagalan dapat terjadi karena masalah sebagai berikut:
+ Izin
+ [Profil contoh yang salah](#troubleshooting-compute-node-bootstrap-wrong-instance-profile)
+ Jaringan
+ [Tidak dapat terhubung ke titik akhir AWS PCS](#troubleshooting-compute-node-bootstrap-connect-to-endpoints)
+ [Titik akhir AWS PCS yang salah dikonfigurasi](#troubleshooting-compute-node-bootstrap-misconfigured-pcs-endpoint)
+ [Instance dalam subnet publik tanpa IP publik](#troubleshooting-compute-node-bootstrap-public-subnet-no-public-ip)
+ [Instans multi-NIC di subnet publik](#troubleshooting-compute-node-bootstrap-multi-nic-public-subnet)
+ Rahasia cluster
+ [Rahasia cluster telah dihapus atau ditandai untuk dihapus](#troubleshooting-compute-node-bootstrap-cluster-secret-deleted)
+ **Integrasi slurm** — Instance berjalan `slurmd` dan bergabung dengan cluster Slurm. Kegagalan dapat terjadi karena masalah sebagai berikut:
+ Izin
+ [Konfigurasi grup keamanan](#troubleshooting-compute-node-bootstrap-security-groups)
+ [Slurmctld tidak dapat melakukan ping node komputasi](#troubleshooting-compute-node-bootstrap-slurmctld-ping-issue)
+ Pengaturan AMI kustom
+ [Driver NVIDIA hilang](#troubleshooting-compute-node-bootstrap-missing-nvidia-drivers)
+ [ResumeTimeout mencapai](#troubleshooting-compute-node-bootstrap-resume-timeout)
## Bagaimana Slurm bekerja pada PCS AWS
Ini mungkin membantu Anda untuk membandingkan cara standar Slurm bekerja dengan cara Slurm bekerja pada PCS. AWS
**Pemrosesan pekerjaan Slurm standar**
Langkah-langkah berikut terjadi dalam pemrosesan pekerjaan Slurm standar:
1. Saat Anda mengirimkan pekerjaan, `slurmctld` validasi dan antrian pekerjaan.
1. Ketika sumber daya tersedia, `slurmctld` mengalokasikan node yang ada.
1. `slurmd`daemon menjalankan pekerjaan pada node yang dialokasikan.
**Pemrosesan pekerjaan slurm pada PCS AWS**
Langkah-langkah berikut terjadi dalam pemrosesan pekerjaan AWS PCS:
1. Saat Anda mengirimkan pekerjaan, `slurmctld` validasi dan antrian pekerjaan.
1. **Ketika kapasitas tambahan diperlukan, AWS PCS menggunakan template peluncuran untuk grup node komputasi untuk meluncurkan instans EC2 baru.**
1. **Contoh baru bootstrap ke dalam cluster:**
1. **Instans mendaftar dengan AWS PCS.**
1. **Instance bergabung dengan cluster Slurm.**
1. Ketika sumber daya siap, `slurmctld` alokasikan node (termasuk yang baru di-bootstrap).
1. `slurmd`daemon menjalankan pekerjaan pada node yang dialokasikan.
## Ambil log contoh
Langkah pertama dalam memecahkan masalah bootstrap node komputasi adalah mengambil log instance. Gunakan salah satu metode berikut:
------
#### [ AWS CLI ]
Ambil output konsol dari node komputasi menggunakan perintah berikut:
```
aws ec2 get-console-output --region us-east-1 --instance-id i-1234567890abcdef0 --output text
```
Ganti *us-east-1* dengan AWS Region Anda dan *i-1234567890abcdef0* dengan ID instans Anda.
------
#### [ AWS Systems Manager ]
Jika Anda dapat terhubung ke instance menggunakan Systems Manager, Anda dapat melihat file log bootstrap secara langsung:
1. Connect ke instance menggunakan Systems Manager. Untuk informasi selengkapnya, lihat [Memulai sesi](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-sessions-start.html#start-ec2-console) di *Panduan Pengguna Systems Manager*.
1. Lihat file log bootstrap:
```
sudo cat /var/log/amazon/pcs/bootstrap.log
```
**catatan**
Jika ada masalah selama fase inisialisasi, Anda mungkin perlu menunggu sekitar 20 menit sebelum dapat terhubung ke instance. Systems Manager dan layanan SSH dimulai hanya setelah inisialisasi selesai atau ketika eksekusi bootstrap mencapai batas waktu jika terjadi kegagalan.
------
## Mengambil VPC/Subnet/Security Grup dari ID instance
Untuk memecahkan masalah dengan node komputasi, Anda mungkin perlu mengambil informasi tentang VPC, subnet, dan grup keamanan yang terkait dengan instans Anda. Jika Anda tidak tahu contoh Anda IDs, lihat[Menemukan instance grup node komputasi di PCS AWS](working-with_compute-instances.md).
------
#### [ Konsol Manajemen AWS ]
**Untuk mendapatkan VPC, subnet, dan grup keamanan**
1. Buka [konsol Amazon EC2](https://console.aws.amazon.com/ec2).
1. Pilih **Instans**.
1. Dalam tabel **Instances**, pilih ID instance.
1. Temukan ID **VPC dan ID** **Subnet** dalam ringkasan instance yang ditampilkan untuk instance tersebut.
1. Dalam ringkasan instance, pilih tab **Keamanan**.
1. Temukan **Grup keamanan** di tab **Keamanan**.
------
#### [ AWS CLI ]
Gunakan perintah berikut untuk mengambil VPC, subnet, dan informasi grup keamanan untuk instans Anda:
```
aws ec2 describe-instances --instance-ids i-1234567890abcdef0 --query 'Reservations[*].Instances[*].{InstanceId:InstanceId,VpcId:VpcId,SubnetId:SubnetId,SecurityGroups:SecurityGroups[*].GroupId}' --output table
```
------
## Masalah pendaftaran node
Registrasi node adalah tindakan pertama yang dijalankan oleh node komputasi selama bootstrap. Node memanggil titik akhir AWS PCS API untuk mendaftarkan dirinya dengan AWS PCS. Kegagalan pendaftaran biasanya menampilkan pesan kesalahan yang mirip dengan yang berikut ini:
```
<13>Nov 13 16:23:50 user-data: [2025-11-13T16:23:50.510+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Registering node to cluster
<13>Nov 13 16:24:18 user-data: [2025-11-13T16:24:18.192+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Retriable exception detected.
<13>Nov 13 16:24:18 user-data: [2025-11-13T16:24:18.193+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Response is [specific error message]
<13>Nov 13 16:24:18 user-data: [2025-11-13T16:24:18.194+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Retrying in 31 seconds...
<13>Nov 13 16:24:18 user-data: [2025-11-13T16:24:18.192+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Retriable exception detected.
...
<13>Nov 13 16:25:18 user-data: [2025-11-13T16:25:18.195+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Registration timeout (600 seconds) reached. Exiting.
<13>Nov 13 16:25:18 user-data: [2025-11-13T16:25:18.200+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: ERROR: Error: (2) occurred on line 1 when running /opt/aws/pcs/bin/pcs_bootstrap_init.sh. Shutting down instance.
```
### Profil contoh yang salah
Jika node tidak dapat mendaftar karena profil instance yang salah, Anda akan melihat kesalahan berikut:
```
<13>Nov 13 18:43:08 user-data: [2025-11-13T18:43:08.268+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Response is {
<13>Nov 13 18:43:08 user-data: "__type": "com.amazon.coral.service#AccessDeniedException",
<13>Nov 13 18:43:08 user-data: "Message": "User: arn:aws:sts:::assumed-role// is not authorized to perform: pcs:RegisterComputeNodeGroupInstance on resource: arn:aws:pcs:::cluster/ as either the resource does not exist, some policy explicitly denies access, or no policy grants access",
<13>Nov 13 18:43:08 user-data: "nodeID": null
<13>Nov 13 18:43:08 user-data: }
```
Verifikasi bahwa profil instance yang terkait dengan node komputasi memiliki `pcs:RegisterComputeNodeGroupInstance` izin. Untuk informasi selengkapnya tentang cara membuat profil instans yang valid, lihat[Buat profil instance untuk AWS PCS](getting-started_create-cng_instance-profile.md).
### Tidak dapat terhubung ke titik akhir AWS PCS
Jika node komputasi Anda berada dalam subnet pribadi, pastikan Anda telah mengonfigurasi titik akhir VPC untuk AWS PCS atau subnet Anda memiliki rute ke gateway NAT untuk akses internet. Untuk informasi selengkapnya, lihat berikut ini:
+ [Akses AWS layanan menggunakan titik akhir VPC antarmuka](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) di panduan *Amazon Virtual Private Cloud*. AWS PrivateLink
+ [Titik akhir dan kuota layanan untuk PCS AWS](service-endpoints-quotas.md).
+ [Hubungkan VPC Anda ke jaringan lain di Panduan](https://docs.aws.amazon.com/vpc/latest/userguide/extend-intro.html) Pengguna *Amazon Virtual Private Cloud*
+ [AWS Jaringan PCS](working-with_networking.md)
### Titik akhir AWS PCS yang salah dikonfigurasi
Jika Anda melihat pesan galat yang mirip dengan berikut ini, verifikasi kebijakan yang terkait dengan titik akhir AWS VPC PC Anda:
```
com.amazon.coral.security.AccessDeniedException: User: arn:aws:sts::xxx:assumed-role// is not authorized to perform: pcs:RegisterComputeNodeGroupInstance on resource: arn:aws:pcs:::cluster/ as either the resource does not exist, some policy explicitly denies access, or no policy grants access
```
Untuk informasi selengkapnya tentang cara mengonfigurasi titik akhir antarmuka VPC untuk AWS PCS, lihat. [Akses AWS Parallel Computing Service menggunakan endpoint antarmuka ()AWS PrivateLink](vpc-interface-endpoints.md)
### Instance dalam subnet publik tanpa IP publik
Jika subnet Anda tidak mengaktifkan **IP publik penetapan otomatis** dan konfigurasi rute Anda menggunakan gateway internet, instance tidak dapat berkomunikasi dengan PCS API. AWS
Contoh di subnet dengan gateway internet harus memiliki alamat IP publik. Untuk mengatasi masalah ini, pilih salah satu opsi berikut:
+ Tambahkan titik akhir VPC untuk AWS PCS ke VPC cluster Anda. Hal ini memungkinkan instance untuk berkomunikasi dengan AWS PCS tanpa perlu alamat IP publik untuk melewati gateway internet.
+ Gunakan subnet pribadi dengan gateway NAT, sehingga alamat IP publik tidak diperlukan.
+ Aktifkan penetapan alamat IP publik otomatis melalui subnet atau template peluncuran Anda sehingga instance dapat menghubungi API melalui gateway internet. Perhatikan bahwa opsi ini tidak berlaku untuk instance antarmuka multi-jaringan.
### Instans multi-NIC di subnet publik
Anda harus menggunakan subnet pribadi jika Anda menggunakan jenis instance yang memiliki beberapa antarmuka jaringan ()NICs.
AWS Alamat IP publik hanya dapat ditetapkan ke instance yang diluncurkan dengan antarmuka jaringan tunggal. Untuk informasi selengkapnya tentang alamat IP, lihat [Menetapkan IPv4 alamat publik selama peluncuran instans](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#public-ip-addresses) di *Panduan Pengguna Amazon EC2 untuk* Instans Linux.
Jenis instans multi-NIC memerlukan gateway NAT atau proxy internal di subnet untuk mengakses titik akhir PCS. AWS Atau, Anda dapat menambahkan titik akhir VPC untuk AWS PCS ke VPC cluster Anda.
### Rahasia cluster telah dihapus atau ditandai untuk dihapus
Jika rahasia bersama Slurm di AWS Secrets Manager telah dihapus atau ditandai untuk dihapus, node komputasi akan gagal mendaftar dan klaster Anda akan mengalami gangguan.
AWS PCS secara otomatis membuat rahasia bersama Slurm di AWS Secrets Manager (dengan format nama:`pcs!slurm-secret-`) saat Anda membuat cluster. Rahasia ini diperlukan untuk komunikasi yang aman di cluster. Untuk informasi selengkapnya, lihat [Bekerja dengan rahasia cluster di AWS PCS](working-with_clusters_secrets.md).
Jika rahasia ini dihapus atau ditandai untuk dihapus, node baru tidak akan dapat bergabung dengan cluster dan pengontrol atau daemon cluster lainnya (seperti `slurmd` dan`slurmdbd`) mungkin tidak dapat bergabung kembali dengan cluster jika dimulai ulang.
Untuk mengatasi masalah ini, Anda dapat memulihkan rahasia yang dihapus jika masih dalam jendela pemulihan. Untuk petunjuk mendetail, lihat [Mengembalikan AWS rahasia Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_restore-secret.html).
Jika jendela pemulihan kedaluwarsa, rahasia tidak dapat dipulihkan dan cluster AWS PCS yang terpengaruh tidak dapat dipulihkan. Anda perlu membuat cluster baru dengan konfigurasi yang sama. AWS PCS secara otomatis membuat rahasia penjadwal baru.
## Masalah bergabung klaster slurm
Setelah registrasi node berhasil, node komputasi mencoba untuk bergabung dengan cluster Slurm. `slurmd`Daemon pada node menghubungi controller Slurm untuk mendaftar dengan cluster. Kegagalan bergabung slurm biasanya menampilkan pesan kesalahan yang mirip dengan yang berikut ini:
```
<13>Nov 5 17:20:29 user-data: [2024-11-05T17:20:28+00:00] FATAL: Mixlib::ShellOut::ShellCommandFailed: service[slurmd] (aws-pcs-slurm::finalize_slurm line 18) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
<13>Nov 5 17:20:29 user-data: ---- Begin output of ["/usr/bin/systemctl", "--system", "start", "slurmd"] ----
<13>Nov 5 17:20:29 user-data: STDOUT:
<13>Nov 5 17:20:29 user-data: STDERR: Job for slurmd.service failed because the control process exited with error code. See "systemctl status slurmd.service" and "journalctl -xe" for details.
<13>Nov 5 17:20:29 user-data: ---- End output of ["/usr/bin/systemctl", "--system", "start", "slurmd"] ----
```
### Konfigurasi grup keamanan
Verifikasi bahwa grup keamanan Anda dikonfigurasi dengan benar untuk memungkinkan komunikasi antara node komputasi dan pengontrol Slurm. Grup keamanan harus mengizinkan lalu lintas berikut:
+ Port 6817 `slurmd` untuk berkomunikasi `slurmctld`
+ Port 6818 untuk `slurmctld` melakukan ping `slurmd`
Untuk informasi selengkapnya tentang persyaratan grup keamanan, lihat topik berikut:
+ [Buat grup keamanan untuk AWS PCS](getting-started_create-sg.md)
+ [Buat template peluncuran untuk AWS PCS](getting-started_create-cng_launch-templates.md)
+ [Persyaratan dan pertimbangan kelompok keamanan](working-with_networking_sg.md#working-with_networking_sg-requirements)
**penting**
Grup keamanan klaster yang Anda kaitkan dengan klaster selama pembuatan klaster juga harus dikonfigurasi dalam grup keamanan grup node komputasi Anda agar node komputasi dapat berkomunikasi dengan pengontrol.
### Driver NVIDIA hilang
Jika instance bootstraps dengan benar tetapi pekerjaan tidak dimulai, dan Anda melihat pesan kesalahan yang mirip dengan yang berikut di log instans Anda, Anda mungkin kehilangan driver NVIDIA:
```
<13>Dec 2 13:52:00 user-data: [2024-12-02T13:52:00.094+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_config_always.sh: INFO: nvidia-smi not found!
...
<13>Dec 2 13:54:10 user-data: Job for slurmd.service failed because the control process exited with error code. See "systemctl status slurmd.service" and "journalctl -xe" for details.
<13>Dec 2 13:54:12 user-data: [2024-12-02T13:54:12.718+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_finalize.sh: INFO: systemctl could not start slurmd!
```
Jika Anda terhubung ke instance dan memeriksa status `slurmd` daemon, Anda mungkin melihat kesalahan yang mirip dengan berikut ini:
```
$ systemctl status slurmd
...
fatal: can't stat gres.conf file /dev/nvidia0: No such file or directory
```
Untuk mengatasi masalah ini, instal driver NVIDIA pada AMI kustom Anda. Untuk informasi selengkapnya, lihat [Langkah 4 - (Opsional) Instal driver tambahan, perpustakaan, dan perangkat lunak aplikasi](working-with_ami_custom_install-software.md).
### ResumeTimeout mencapai
Jika node komputasi dan instans EC2-nya dihentikan karena node tidak sehat, AWS PCS mungkin tidak mendukung AMI atau mungkin ada masalah jaringan. Instans EC2 berjalan selama sekitar 30 menit sampai Slurm ResumeTimeout tercapai dan menandai node sebagai. `DOWN`
Jika instance tidak bootstrap dengan benar dan tidak terdaftar dengan AWS PCS (tidak ada `RegisterComputeNodeGroupInstance` panggilan untuk instans EC2), periksa log instance Anda untuk pesan kesalahan yang mirip dengan berikut ini:
```
/opt/aws/pcs/bin/pcs_bootstrap_init.sh: No such file or directory
```
Kesalahan ini menunjukkan bahwa perangkat lunak bootstrap AWS PCS bukan bagian dari AMI. Untuk mengatasi masalah ini, pastikan AMI kustom Anda menyertakan perangkat lunak bootstrap AWS PCS. Untuk informasi selengkapnya, lihat [Gambar Mesin Amazon Kustom (AMIs) untuk AWS PCS](working-with_ami_custom.md).
### Slurmctld tidak dapat melakukan ping node komputasi
Jika instance menjalankan prosedur bootstrap dengan benar dan terdaftar dengan AWS PCS, tetapi `slurmctld` tidak dapat melihatnya dan mengirimkan pekerjaan ke sana, instance diatur ke `DOWN` setelah beberapa waktu dan kemudian dihentikan.
Ini mungkin disebabkan oleh grup keamanan yang salah dikonfigurasi. Misalnya, jika port 6817 diaktifkan untuk memungkinkan `slurmd` untuk berkomunikasi`slurmctld`, tetapi port 6818 tidak ada `slurmctld` untuk memungkinkan ping. `slurmd`
Verifikasi bahwa grup keamanan Anda menyertakan semua aturan yang diperlukan sebagaimana didokumentasikan dalam[Persyaratan dan pertimbangan kelompok keamanan](working-with_networking_sg.md#working-with_networking_sg-requirements).