AWS ParallelCluster pemecahan masalah - AWS ParallelCluster

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

AWS ParallelCluster pemecahan masalah

AWS ParallelCluster Komunitas memelihara halaman Wiki yang menyediakan banyak tips pemecahan masalah di Wiki.AWS ParallelCluster GitHub Untuk daftar masalah yang diketahui, lihat Masalah yang diketahui.

Mengambil dan melestarikan log

Log adalah sumber daya yang berguna untuk memecahkan masalah. Sebelum Anda dapat menggunakan log untuk memecahkan masalah AWS ParallelCluster sumber daya Anda, Anda harus terlebih dahulu membuat arsip log klaster. Ikuti langkah-langkah yang dijelaskan dalam topik Membuat Arsip Log Cluster di AWS ParallelCluster GitHub Wiki untuk memulai proses ini.

Jika salah satu cluster yang sedang berjalan mengalami masalah, Anda harus menempatkan cluster dalam STOPPED status dengan menjalankan pcluster stop <cluster_name> perintah sebelum Anda mulai memecahkan masalah. Ini mencegah timbulnya biaya tak terduga.

Jika pcluster berhenti berfungsi atau jika Anda ingin menghapus cluster sambil tetap mempertahankan lognya, jalankan pcluster delete —keep-logs <cluster_name> perintah. Menjalankan perintah ini menghapus cluster namun mempertahankan grup log yang disimpan di Amazon. CloudWatch Untuk informasi selengkapnya tentang perintah ini, lihat pcluster delete dokumentasi.

Memecahkan masalah penyebaran tumpukan

Jika klaster Anda gagal dibuat dan memutar kembali pembuatan tumpukan, Anda dapat melihat file log berikut untuk mendiagnosis masalah. Anda ingin mencari output dari ROLLBACK_IN_PROGRESS dalam log ini. Pesan kegagalan akan terlihat seperti berikut:

$ pcluster create mycluster Creating stack named: parallelcluster-mycluster Status: parallelcluster-mycluster - ROLLBACK_IN_PROGRESS Cluster creation failed. Failed events: - AWS::EC2::Instance MasterServer Received FAILURE signal with UniqueId i-07af1cb218dd6a081

Untuk mendiagnosis masalah, buat kembali cluster menggunakanpcluster create, termasuk --norollback flag. Kemudian, SSH ke dalam cluster:

$ pcluster create mycluster --norollback ... $ pcluster ssh mycluster

Setelah Anda masuk ke node kepala, Anda harus menemukan tiga file log utama yang dapat Anda gunakan untuk menentukan kesalahan.

  • /var/log/cfn-init.logadalah log untuk cfn-init skrip. Pertama periksa log ini. Anda mungkin melihat kesalahan seperti Command chef failed di log ini. Lihatlah baris segera sebelum baris ini untuk lebih spesifik yang terkait dengan pesan kesalahan. Untuk informasi lebih lanjut, lihat cfn-init.

  • /var/log/cloud-init.logadalah log untuk cloud-init. Jika Anda tidak melihat apa puncfn-init.log, coba periksa log ini selanjutnya.

  • /var/log/cloud-init-output.logadalah output dari perintah yang dijalankan oleh cloud-init. Ini termasuk output daricfn-init. Dalam kebanyakan kasus, Anda tidak perlu melihat log ini untuk memecahkan masalah jenis ini.

Memecahkan masalah di beberapa cluster mode antrian

Bagian ini relevan dengan cluster yang diinstal menggunakan AWS ParallelCluster versi 2.9.0 dan yang lebih baru dengan Slurm penjadwal pekerjaan. Untuk informasi selengkapnya tentang beberapa mode antrian, lihatMode antrian ganda.

Log kunci

Tabel berikut memberikan ikhtisar log kunci untuk node kepala:

/var/log/cfn-init.log

Ini adalah log AWS CloudFormation init. Ini berisi semua perintah yang dijalankan ketika sebuah instance diatur. Ini berguna untuk memecahkan masalah inisialisasi.

/var/log/chef-client.log

Ini adalah log klien Chef. Ini berisi semua perintah yang dijalankan melalui chef/CINC. Ini berguna untuk memecahkan masalah inisialisasi.

/var/log/parallelcluster/slurm_resume.log

Ini adalah ResumeProgram log. Ini meluncurkan instance untuk node dinamis dan berguna untuk memecahkan masalah peluncuran node dinamis.

/var/log/parallelcluster/slurm_suspend.log

Ini SuspendProgram log. Ini disebut ketika instance dihentikan untuk node dinamis, dan berguna untuk memecahkan masalah penghentian node dinamis. Saat Anda memeriksa log ini, Anda juga harus memeriksa clustermgtd log.

/var/log/parallelcluster/clustermgtd

Ini clustermgtd log. Ini berjalan sebagai daemon terpusat yang mengelola sebagian besar tindakan operasi cluster. Ini berguna untuk memecahkan masalah peluncuran, penghentian, atau masalah operasi klaster apa pun.

/var/log/slurmctld.log

Ini adalah Slurm kontrol log daemon. AWS ParallelCluster tidak membuat keputusan penskalaan. Sebaliknya, ia hanya mencoba meluncurkan sumber daya untuk memuaskan Slurm persyaratan. Ini berguna untuk masalah penskalaan dan alokasi, masalah terkait pekerjaan, dan masalah peluncuran dan penghentian terkait penjadwal.

Ini adalah catatan kunci untuk node Compute:

/var/log/cloud-init-output.log

Ini adalah log cloud-init. Ini berisi semua perintah yang dijalankan ketika sebuah instance diatur. Ini berguna untuk memecahkan masalah inisialisasi.

/var/log/parallelcluster/computemgtd

Ini computemgtd log. Ini berjalan pada setiap node komputasi untuk memantau node dalam peristiwa langka bahwa clustermgtd daemon pada node kepala sedang offline. Ini berguna untuk memecahkan masalah penghentian yang tidak terduga.

/var/log/slurmd.log

Ini adalah Slurm menghitung log daemon. Ini berguna untuk memecahkan masalah inisialisasi dan masalah terkait kegagalan komputasi.

Memecahkan masalah inisialisasi node

Bagian ini mencakup bagaimana Anda dapat memecahkan masalah inisialisasi node. Ini termasuk masalah di mana node gagal diluncurkan, dinyalakan, atau bergabung dengan cluster.

Simpul kepala:

Log yang berlaku:

  • /var/log/cfn-init.log

  • /var/log/chef-client.log

  • /var/log/parallelcluster/clustermgtd

  • /var/log/parallelcluster/slurm_resume.log

  • /var/log/slurmctld.log

Periksa /var/log/cfn-init.log dan /var/log/chef-client.log log. Log ini harus berisi semua tindakan yang dijalankan saat node kepala diatur. Sebagian besar kesalahan yang terjadi selama pengaturan harus memiliki pesan kesalahan yang terletak di /var/log/chef-client.log log. Jika skrip pra-instal atau pasca-instal ditentukan dalam konfigurasi cluster, periksa kembali apakah skrip berjalan dengan sukses melalui pesan log.

Ketika sebuah cluster dibuat, node kepala harus menunggu node komputasi untuk bergabung dengan cluster sebelum dapat bergabung dengan cluster. Dengan demikian, jika node komputasi gagal bergabung dengan cluster, maka node kepala juga gagal. Anda dapat mengikuti salah satu dari rangkaian prosedur ini, tergantung pada jenis catatan komputasi yang Anda gunakan, untuk memecahkan masalah jenis ini:

Node komputasi dinamis:

  • Cari ResumeProgram log (/var/log/parallelcluster/slurm_resume.log) untuk nama node komputasi Anda untuk melihat apakah pernah ResumeProgram dipanggil dengan node. (Jika ResumeProgram tidak pernah dipanggil, Anda dapat memeriksa slurmctld log (/var/log/slurmctld.log) untuk menentukan apakah Slurm pernah mencoba menelepon ResumeProgram dengan node.)

  • Perhatikan bahwa izin yang salah untuk ResumeProgram dapat menyebabkan kegagalan ResumeProgram secara diam-diam. Jika Anda menggunakan AMI kustom dengan modifikasi untuk ResumeProgram penyiapan, periksa apakah AMI dimiliki oleh slurm pengguna dan memiliki izin 744 (rwxr--r--). ResumeProgram

  • Jika ResumeProgram dipanggil, periksa untuk melihat apakah sebuah instance diluncurkan untuk node. Jika tidak ada instance yang diluncurkan, Anda seharusnya dapat melihat pesan kesalahan yang menjelaskan kegagalan peluncuran.

  • Jika instance diluncurkan, maka mungkin ada masalah selama proses penyiapan. Anda akan melihat alamat IP pribadi dan ID instance yang sesuai dari ResumeProgram log. Selain itu, Anda dapat melihat log pengaturan yang sesuai untuk contoh tertentu. Untuk informasi selengkapnya tentang pemecahan masalah kesalahan penyiapan dengan node komputasi, lihat bagian selanjutnya.

Node komputasi statis:

  • Periksa log clustermgtd (/var/log/parallelcluster/clustermgtd) untuk melihat apakah instance diluncurkan untuk node. Jika tidak diluncurkan, harus ada pesan kesalahan yang jelas yang merinci kegagalan peluncuran.

  • Jika instance diluncurkan, ada beberapa masalah selama proses penyiapan. Anda akan melihat alamat IP pribadi dan ID instance yang sesuai dari ResumeProgram log. Selain itu, Anda dapat melihat log pengaturan yang sesuai untuk instance tertentu.

  • Hitung node:

    • Log yang berlaku:

      • /var/log/cloud-init-output.log

      • /var/log/slurmd.log

    • Jika node komputasi diluncurkan, periksa terlebih dahulu/var/log/cloud-init-output.log, yang harus berisi log pengaturan yang mirip dengan /var/log/chef-client.log log pada node kepala. Sebagian besar kesalahan yang terjadi selama pengaturan harus memiliki pesan kesalahan yang terletak di /var/log/cloud-init-output.log log. Jika skrip pra-instal atau pasca-instal ditentukan dalam konfigurasi cluster, periksa apakah skrip tersebut berhasil dijalankan.

    • Jika Anda menggunakan AMI kustom dengan modifikasi Slurm konfigurasi, maka mungkin ada Slurm kesalahan terkait yang mencegah node komputasi bergabung dengan cluster. Untuk kesalahan terkait penjadwal, periksa /var/log/slurmd.log log.

Memecahkan masalah penggantian dan penghentian node yang tidak terduga

Bagian ini terus mengeksplorasi bagaimana Anda dapat memecahkan masalah terkait node, khususnya ketika node diganti atau dihentikan secara tidak terduga.

  • Log yang berlaku:

    • /var/log/parallelcluster/clustermgtd(simpul kepala)

    • /var/log/slurmctld.log(simpul kepala)

    • /var/log/parallelcluster/computemgtd(simpul komputasi)

  • Node diganti atau dihentikan secara tak terduga

    • Periksa clustermgtd log (/var/log/parallelcluster/clustermgtd) untuk melihat apakah clustermgtd mengambil tindakan untuk mengganti atau mengakhiri node. Perhatikan bahwa clustermgtd menangani semua tindakan pemeliharaan node normal.

    • Jika clustermgtd diganti atau dihentikan node, harus ada pesan yang merinci mengapa tindakan ini diambil pada node. Jika alasannya terkait penjadwal (misalnya, karena node masukDOWN), periksa slurmctld log untuk informasi lebih lanjut. Jika alasannya EC2 terkait Amazon, harus ada pesan informatif yang merinci masalah EC2 terkait Amazon yang memerlukan penggantian.

    • Jika clustermgtd tidak menghentikan node, periksa terlebih dahulu apakah ini adalah penghentian yang diharapkan oleh Amazon EC2, lebih khusus lagi penghentian spot. computemgtd, berjalan pada node Compute, juga dapat mengambil tindakan untuk mengakhiri node jika clustermgtd ditentukan sebagai tidak sehat. Periksa computemgtd log (/var/log/parallelcluster/computemgtd) untuk melihat apakah node computemgtd dihentikan.

  • Node gagal

    • Periksa slurmctld log (/var/log/slurmctld.log) untuk melihat mengapa pekerjaan atau node gagal. Perhatikan bahwa pekerjaan secara otomatis diantrian ulang jika node gagal.

    • Jika slurm_resume melaporkan bahwa node diluncurkan dan clustermgtd melaporkan setelah beberapa menit bahwa tidak ada instance yang sesuai di Amazon EC2 untuk node itu, node mungkin gagal selama penyiapan. Untuk mengambil log dari compute (/var/log/cloud-init-output.log), lakukan langkah-langkah berikut:

      • Kirim pekerjaan untuk membiarkan Slurm memutar node baru.

      • Setelah node dimulai, aktifkan perlindungan terminasi menggunakan perintah ini.

        aws ec2 modify-instance-attribute --instance-id i-xyz --disable-api-termination
      • Ambil output konsol dari node dengan perintah ini.

        aws ec2 get-console-output --instance-id i-xyz --output text

Mengganti, mengakhiri, atau mematikan instance dan node masalah

  • Log yang berlaku:

    • /var/log/parallelcluster/clustermgtd(simpul kepala)

    • /var/log/parallelcluster/slurm_suspend.log(simpul kepala)

  • Dalam kebanyakan kasus, clustermgtd menangani semua tindakan penghentian instance yang diharapkan. Periksa di clustermgtd log untuk melihat mengapa gagal mengganti atau mengakhiri node.

  • Untuk node dinamis gagalscaledown_idletime, periksa SuspendProgram log untuk melihat apakah SuspendProgram dipanggil slurmctld dengan node tertentu sebagai argumen. Perhatikan bahwa SuspendProgram tidak benar-benar melakukan tindakan apa pun. Sebaliknya, itu hanya log ketika dipanggil. Semua penghentian dan NodeAddr reset instance dilakukan olehclustermgtd. Slurm menempatkan node kembali ke POWER_SAVING keadaan setelah SuspendTimeout secara otomatis.

Memecahkan masalah node dan pekerjaan lain yang diketahui

Jenis lain dari masalah yang diketahui adalah yang AWS ParallelCluster mungkin gagal mengalokasikan pekerjaan atau membuat keputusan penskalaan. Dengan jenis masalah ini, AWS ParallelCluster hanya meluncurkan, mengakhiri, atau memelihara sumber daya menurut Slurm instruksi. Untuk masalah ini, periksa slurmctld log untuk memecahkan masalah ini.

Memecahkan masalah dalam kluster mode antrian tunggal

catatan

Dimulai dengan versi 2.11.5, AWS ParallelCluster tidak mendukung penggunaan SGE atau Torque penjadwal.

Bagian ini berlaku untuk cluster yang tidak memiliki beberapa mode antrian dengan salah satu dari dua konfigurasi berikut:

  • Diluncurkan menggunakan AWS ParallelCluster versi lebih awal dari 2.9.0 dan SGE, Torque, atau Slurm penjadwal pekerjaan.

  • Diluncurkan menggunakan AWS ParallelCluster versi 2.9.0 atau yang lebih baru dan SGE atau Torque penjadwal pekerjaan.

Log kunci

File log berikut adalah log kunci untuk node kepala.

Untuk AWS ParallelCluster versi 2.9.0 atau yang lebih baru:

/var/log/chef-client.log

Ini adalah log klien CINC (koki). Ini berisi semua perintah yang dijalankan melalui CINC. Ini berguna untuk memecahkan masalah inisialisasi.

Untuk semua AWS ParallelCluster versi:

/var/log/cfn-init.log

Ini cfn-init log. Ini berisi semua perintah yang dijalankan ketika sebuah instance disiapkan, dan oleh karena itu berguna untuk memecahkan masalah inisialisasi. Untuk informasi lebih lanjut, lihat cfn-init.

/var/log/clustermgtd.log

Ini adalah clustermgtd log untuk Slurm penjadwal. clustermgtdberjalan sebagai daemon terpusat yang mengelola sebagian besar tindakan operasi cluster. Ini berguna untuk memecahkan masalah peluncuran, penghentian, atau masalah operasi klaster apa pun.

/var/log/jobwatcher

Ini adalah jobwatcher log untuk SGE and Torque penjadwal. jobwatchermemantau antrian penjadwal dan memperbarui Grup Auto Scaling. Ini berguna untuk memecahkan masalah yang terkait dengan penskalaan node.

/var/log/sqswatcher

Ini adalah sqswatcher log untuk SGE and Torque penjadwal. sqswatchermemproses peristiwa siap instance yang dikirim oleh instance komputasi setelah inisialisasi berhasil. Ini juga menambahkan node komputasi ke konfigurasi penjadwal. Log ini berguna untuk memecahkan masalah mengapa node atau node gagal bergabung dengan cluster.

Berikut ini adalah log kunci untuk node komputasi.

AWS ParallelCluster versi 2.9.0 atau yang lebih baru

/var/log/cloud-init-output.log

Ini adalah log init Cloud. Ini berisi semua perintah yang dijalankan ketika sebuah instance diatur. Ini berguna untuk memecahkan masalah inisialisasi.

AWS ParallelCluster versi sebelum 2.9.0

/var/log/cfn-init.log

Ini adalah log CloudFormation init. Ini berisi semua perintah yang dijalankan ketika sebuah instance diatur. Ini berguna untuk memecahkan masalah inisialisasi

Semua versi

/var/log/nodewatcher

Ini nodewatcher log. nodewatcherdaemon yang berjalan di setiap node Compute saat menggunakan SGE and Torque penjadwal. Mereka menurunkan node jika itu menganggur. Log ini berguna untuk masalah apa pun yang terkait dengan mengurangi sumber daya.

Pemecahan masalah gagal meluncurkan dan bergabung dengan operasi

  • Log yang berlaku:

    • /var/log/cfn-init-cmd.log(simpul kepala dan simpul komputasi)

    • /var/log/sqswatcher(simpul kepala)

  • Jika node gagal diluncurkan, periksa /var/log/cfn-init-cmd.log log untuk melihat pesan kesalahan tertentu. Dalam kebanyakan kasus, kegagalan peluncuran node disebabkan oleh kegagalan pengaturan.

  • Jika node komputasi gagal bergabung dengan konfigurasi penjadwal meskipun penyiapan berhasil, periksa /var/log/sqswatcher log untuk melihat apakah peristiwa sqswatcher diproses. Masalah-masalah ini dalam banyak kasus adalah karena sqswatcher tidak memproses acara.

Memecahkan masalah penskalaan

  • Log yang berlaku:

    • /var/log/jobwatcher(simpul kepala)

    • /var/log/nodewatcher(simpul komputasi)

  • Masalah skala: Untuk node kepala, periksa /var/log/jobwatcher log untuk melihat apakah jobwatcher daemon menghitung jumlah node yang diperlukan dan memperbarui Grup Auto Scaling. Perhatikan bahwa jobwatcher memantau antrian penjadwal dan memperbarui Grup Auto Scaling.

  • Perkecil masalah: Untuk node komputasi, periksa /var/log/nodewatcher log pada node masalah untuk melihat mengapa node diperkecil. Perhatikan bahwa nodewatcher daemon menurunkan skala node komputasi jika idle.

Satu masalah yang diketahui adalah catatan komputasi acak gagal pada cluster skala besar, khususnya yang memiliki 500 atau lebih node komputasi. Masalah ini terkait dengan batasan arsitektur penskalaan cluster antrian tunggal. Jika Anda ingin menggunakan cluster skala besar, menggunakan AWS ParallelCluster versi v2.9.0 atau yang lebih baru, sedang menggunakan Slurm, dan ingin menghindari masalah ini, Anda harus memutakhirkan dan beralih ke cluster yang didukung mode antrian ganda. Anda dapat melakukannya dengan berlaripcluster-config convert.

Untuk cluster skala ultra-besar, penyetelan tambahan ke sistem Anda mungkin diperlukan. Untuk informasi lebih lanjut, hubungi Dukungan.

Grup penempatan dan masalah peluncuran instance

Untuk mendapatkan latensi antar simpul terendah, gunakan grup penempatan. Grup penempatan menjamin bahwa instans Anda berada di tulang punggung jaringan yang sama. Jika tidak ada cukup instance yang tersedia saat permintaan dibuat, InsufficientInstanceCapacity kesalahan akan dikembalikan. Untuk mengurangi kemungkinan menerima kesalahan ini saat menggunakan grup penempatan cluster, atur placement_group parameter ke DYNAMIC dan atur placement parameternya kecompute.

Jika Anda memerlukan sistem file bersama berkinerja tinggi, pertimbangkan untuk menggunakan FSx Lustre.

Jika node kepala harus berada dalam grup penempatan, gunakan jenis instance dan subnet yang sama untuk head serta semua node komputasi. Dengan melakukan ini, compute_instance_type parameter memiliki nilai yang sama dengan master_instance_type parameter, placement parameter diatur kecluster, dan compute_subnet_id parameter tidak ditentukan. Dengan konfigurasi ini, nilai master_subnet_id parameter digunakan untuk node komputasi.

Untuk informasi selengkapnya, lihat Memecahkan masalah peluncuran instans serta Peran dan batasan grup penempatan di Panduan Pengguna Amazon EC2

Direktori yang tidak dapat diganti

Direktori berikut dibagi antara node dan tidak dapat diganti.

/home

Ini termasuk folder home pengguna default (/home/ec2_userdi Amazon Linux, /home/centos di CentOS, dan /home/ubuntu pada Ubuntu).

/opt/intel

Ini termasuk Intel MPI, Intel Parallel Studio, dan file terkait.

/opt/sge
catatan

Dimulai dengan versi 2.11.5, AWS ParallelCluster tidak mendukung penggunaan SGE atau Torque penjadwal.

Ini termasuk Son of Grid Engine dan file terkait. (Bersyarat, hanya jika scheduler = sge.)

/opt/slurm

Ini termasuk Slurm Workload Manager dan file terkait. (Bersyarat, hanya jika scheduler = slurm.)

/opt/torque
catatan

Dimulai dengan versi 2.11.5, AWS ParallelCluster tidak mendukung penggunaan SGE atau Torque penjadwal.

Ini termasuk Torque Resource Manager dan file terkait. (Bersyarat, hanya jika scheduler = torque.)

Memecahkan masalah di Amazon DCV

Log untuk Amazon DCV

Log untuk Amazon DCV ditulis ke file di /var/log/dcv/ direktori. Meninjau log ini dapat membantu memecahkan masalah.

Memori jenis instans Amazon DCV

Jenis instans harus memiliki setidaknya 1,7 gibibyte (GiB) RAM untuk menjalankan Amazon DCV. Nano and micro tipe instance tidak memiliki cukup memori untuk menjalankan Amazon DCV.

Masalah Ubuntu Amazon DCV

Saat menjalankan Terminal Gnome melalui sesi DCV di Ubuntu, Anda mungkin tidak secara otomatis memiliki akses ke lingkungan pengguna yang AWS ParallelCluster tersedia melalui shell login. Lingkungan pengguna menyediakan modul lingkungan seperti openmpi atau intelmpi, dan pengaturan pengguna lainnya.

Pengaturan default Terminal Gnome mencegah shell dimulai sebagai shell login. Ini berarti bahwa profil shell tidak bersumber secara otomatis dan lingkungan AWS ParallelCluster pengguna tidak dimuat.

Untuk mendapatkan sumber profil shell dengan benar dan mengakses lingkungan AWS ParallelCluster pengguna, lakukan salah satu hal berikut:

  • Ubah pengaturan terminal default:
    1. Pilih menu Edit di terminal Gnome.

    2. Pilih Preferensi, lalu Profil.

    3. Pilih Command dan pilih Run Command sebagai shell login.

    4. Buka terminal baru.

  • Gunakan baris perintah untuk sumber profil yang tersedia:

    $ source /etc/profile && source $HOME/.bashrc

Memecahkan masalah dalam cluster dengan integrasi AWS Batch

Bagian ini relevan dengan cluster dengan integrasi AWS Batch scheduler.

Masalah simpul kepala

Masalah penyiapan terkait node kepala dapat dipecahkan masalah dengan cara yang sama seperti cluster antrian tunggal. Untuk informasi lebih lanjut tentang masalah ini, lihatMemecahkan masalah dalam kluster mode antrian tunggal.

AWS Batch masalah pengiriman pekerjaan paralel multi-node

Jika Anda memiliki masalah dalam mengirimkan pekerjaan paralel multi-node saat AWS Batch menggunakan sebagai penjadwal pekerjaan, Anda harus meningkatkan AWS ParallelCluster ke versi 2.5.0. Jika itu tidak layak, Anda dapat menggunakan solusi yang dirinci dalam topik: Menambal sendiri cluster yang digunakan untuk mengirimkan pekerjaan paralel multi-node. AWS Batch

Masalah komputasi

AWS Batch mengelola aspek penskalaan dan komputasi layanan Anda. Jika Anda mengalami masalah terkait komputasi, lihat dokumentasi AWS Batch pemecahan masalah untuk mendapatkan bantuan.

Kegagalan Job

Jika pekerjaan gagal, Anda dapat menjalankan awsbout perintah untuk mengambil output pekerjaan. Anda juga dapat menjalankan awsbstat -d perintah untuk mendapatkan tautan ke log pekerjaan yang disimpan oleh Amazon CloudWatch.

Pemecahan masalah saat sumber daya gagal dibuat

Bagian ini relevan dengan sumber daya cluster ketika mereka gagal untuk membuat.

Ketika sumber daya gagal untuk membuat, ParallelCluster mengembalikan pesan kesalahan seperti berikut ini.

pcluster create -c config my-cluster Beginning cluster creation for cluster: my-cluster WARNING: The instance type 'p4d.24xlarge' cannot take public IPs. Please make sure that the subnet with id 'subnet-1234567890abcdef0' has the proper routing configuration to allow private IPs reaching the Internet (e.g. a NAT Gateway and a valid route table). WARNING: The instance type 'p4d.24xlarge' cannot take public IPs. Please make sure that the subnet with id 'subnet-1234567890abcdef0' has the proper routing configuration to allow private IPs reaching the Internet (e.g. a NAT Gateway and a valid route table). Info: There is a newer version 3.0.3 of AWS ParallelCluster available. Creating stack named: parallelcluster-my-cluster Status: parallelcluster-my-cluster - ROLLBACK_IN_PROGRESS Cluster creation failed. Failed events: - AWS::CloudFormation::Stack MasterServerSubstack Embedded stack arn:aws:cloudformation:region-id:123456789012:stack/parallelcluster-my-cluster-MasterServerSubstack-ABCDEFGHIJKL/a1234567-b321-c765-d432-dcba98766789 was not successfully created: The following resource(s) failed to create: [MasterServer]. - AWS::CloudFormation::Stack parallelcluster-my-cluster-MasterServerSubstack-ABCDEFGHIJKL The following resource(s) failed to create: [MasterServer]. - AWS::EC2::Instance MasterServer You have requested more vCPU capacity than your current vCPU limit of 0 allows for the instance bucket that the specified instance type belongs to. Please visit http://aws.amazon.com/contact-us/ec2-request to request an adjustment to this limit. (Service: AmazonEC2; Status Code: 400; Error Code: VcpuLimitExceeded; Request ID: a9876543-b321-c765-d432-dcba98766789; Proxy: null) }

Sebagai contoh, jika Anda melihat pesan status yang ditampilkan dalam respons perintah sebelumnya, Anda harus menggunakan jenis instance yang tidak akan melebihi batas vCPU Anda saat ini atau meminta lebih banyak kapasitas vCPU.

Anda juga dapat menggunakan CloudFormation konsol untuk melihat informasi tentang "Cluster creation failed" status.

Lihat pesan CloudFormation kesalahan dari konsol.

  1. Masuk ke AWS Management Console dan navigasikan ke https://console.aws.amazon.com/cloudformation.

  2. Pilih tumpukan bernama parallelcluster-. cluster_name

  3. Pilih tab Acara.

  4. Periksa Status sumber daya yang gagal dibuat dengan menggulir daftar peristiwa sumber daya berdasarkan ID Logis. Jika subtugas gagal dibuat, kerjakan mundur untuk menemukan peristiwa sumber daya yang gagal.

  5. Contoh pesan AWS CloudFormation kesalahan:

    2022-02-07 11:59:14 UTC-0800 MasterServerSubstack CREATE_FAILED Embedded stack arn:aws:cloudformation:region-id:123456789012:stack/parallelcluster-my-cluster-MasterServerSubstack-ABCDEFGHIJKL/a1234567-b321-c765-d432-dcba98766789 was not successfully created: The following resource(s) failed to create: [MasterServer].

Memecahkan masalah ukuran kebijakan IAM

Lihat IAM dan AWS STS kuota, persyaratan nama, dan batas karakter untuk memverifikasi kuota pada kebijakan terkelola yang dilampirkan pada peran. Jika ukuran kebijakan terkelola melebihi kuota, bagi kebijakan menjadi dua atau lebih kebijakan. Jika Anda melebihi kuota pada jumlah kebijakan yang dilampirkan pada peran IAM, buat peran tambahan dan distribusikan kebijakan di antara mereka untuk memenuhi kuota.

Dukungan tambahan

Untuk daftar masalah yang diketahui, lihat halaman GitHubWiki utama atau halaman masalah. Untuk masalah yang lebih mendesak, hubungi Dukungan atau buka GitHubmasalah baru.