

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

# Praktik terbaik
<a name="best-practices-v3"></a>

Bagian berikut memberikan praktik terbaik untuk penggunaan AWS ParallelCluster, yang mencakup kinerja jaringan dan peringatan anggaran. Jika Anda mengalami masalah meskipun Anda mengikuti praktik terbaik ini, lihat [AWS ParallelCluster penyelesaian masalah](troubleshooting-v3.md) solusi yang mungkin.

## Praktik terbaik: pemilihan jenis instance node kepala
<a name="best-practices-head-node-instance-type"></a>

Meskipun node kepala tidak menjalankan pekerjaan, fungsi dan ukurannya sangat penting untuk kinerja keseluruhan cluster. Saat memilih jenis instance yang akan digunakan untuk node kepala Anda, pertimbangkan karakteristik berikut:

**Ukuran cluster: ** Node kepala mengatur logika penskalaan cluster dan bertanggung jawab untuk melampirkan node baru ke penjadwal. Untuk meningkatkan dan menurunkan cluster yang memiliki sejumlah besar node, berikan node kepala beberapa kapasitas komputasi tambahan.

**Sistem file bersama: ** Saat Anda menggunakan sistem file bersama, pilih jenis instance dengan bandwidth jaringan yang cukup, dan bandwidth Amazon EBS yang cukup, untuk menangani alur kerja Anda. Pastikan bahwa node kepala mampu mengekspos direktori server NFS yang cukup untuk cluster dan menangani artefak yang perlu dibagikan antara node komputasi dan node kepala. 

## Praktik terbaik: kinerja jaringan
<a name="best-practices-network-performance-v3"></a>

Kinerja jaringan sangat penting untuk aplikasi komputasi kinerja tinggi (HPC). Tanpa kinerja jaringan yang andal, aplikasi ini tidak dapat bekerja seperti yang diharapkan. Untuk mengoptimalkan kinerja jaringan, pertimbangkan praktik terbaik berikut.
+ **Grup penempatan: ** Jika Anda menggunakanSlurm, pertimbangkan untuk mengonfigurasi setiap Slurm antrian untuk menggunakan grup penempatan cluster. Grup * penempatan cluster * adalah pengelompokan instans logis dalam Zona Ketersediaan tunggal. Untuk informasi selengkapnya, lihat grup [ penempatan ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) di Panduan * Pengguna * Amazon EC2. Anda dapat menentukan a [`PlacementGroup`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-PlacementGroup) di [`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking) bagian antrian, setiap sumber daya komputasi ditetapkan ke grup penempatan antrian. Saat menentukan a [`PlacementGroup`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Networking-PlacementGroup) di [`Networking`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Networking) bagian sumber daya komputasi, sumber daya komputasi tertentu ditetapkan ke grup penempatan itu. Spesifikasi grup penempatan sumber daya komputasi menggantikan spesifikasi antrian untuk sumber daya komputasi. Untuk informasi lebih lanjut, lihat [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking)/[`PlacementGroup`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-PlacementGroup)dan [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/[`Networking`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Networking)/[`PlacementGroup`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Networking-PlacementGroup).

  ```
  Networking:
    PlacementGroup:
      Enabled: true
      Id: {{your-placement-group-name}}
  ```

  Atau, AWS ParallelCluster buat grup penempatan untuk Anda.

  ```
  Networking:
    PlacementGroup:
      Enabled: true
  ```

  Dimulai dengan AWS ParallelCluster versi 3.3.0, pembuatan dan manajemen grup penempatan dimodifikasi. Saat Anda menentukan grup penempatan yang akan diaktifkan, tanpa `name` atau`Id`, dalam antrian, setiap sumber daya komputasi diberi grup penempatan terkelola sendiri, bukan satu grup terkelola untuk seluruh antrian. Ini membantu mengurangi kesalahan kapasitas yang tidak mencukupi. Jika Anda perlu memiliki satu grup penempatan untuk seluruh antrian, Anda dapat menggunakan grup penempatan bernama.

  [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking)/[`PlacementGroup`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-PlacementGroup)/[`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-PlacementGroup-Name)ditambahkan sebagai alternatif pilihan untuk [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking)/[`PlacementGroup`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-PlacementGroup)/[`Id`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-PlacementGroup-Id).

  Untuk informasi selengkapnya, lihat [`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking).
+ **Jaringan yang ditingkatkan: ** Pertimbangkan untuk memilih jenis instance yang mendukung jaringan yang ditingkatkan. Rekomendasi ini berlaku untuk semua inst [ ans generasi saat ini](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#current-gen-instances). Untuk informasi selengkapnya, lihat [ peningkatan jaringan di Linux ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html) di Panduan * * Pengguna Amazon EC2.
+ **Adaptor Fabric Elas ** tic: Untuk mendukung komunikasi instans ke instance tingkat tinggi yang dapat diskalakan, pertimbangkan untuk memilih antarmuka jaringan EFA untuk jaringan Anda. Perangkat keras bypass sistem operasi (OS) yang dibuat khusus EFA meningkatkan komunikasi instans ke instance dengan elastisitas dan fleksibilitas sesuai permintaan. AWS Cloud Anda dapat mengonfigurasi setiap Slurm antrian [`ComputeResource`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) untuk digunakan [`Efa`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Efa). Untuk informasi lebih lanjut tentang menggunakan EFA dengan AWS ParallelCluster, lihat[Elastic Fabric Adapter](efa-v3.md).

  ```
  ComputeResources:
    - Name: {{your-compute-resource-name}}
      Efa:
        Enabled: true
  ```

  Untuk informasi selengkapnya tentang EFA, lihat Adaptor [ Kain Elastis ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html) di Panduan * Pengguna Amazon EC2 untuk Instans Linux. *
+ **Bandwidth instance: ** Bandwidth dinaikkan dengan ukuran instance. Untuk informasi tentang berbagai jenis instans, lihat Instans yang dioptimalkan [ Amazon EBS ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html) dan jenis volume [ Amazon EBS ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html) di Panduan Pengguna * Amazon EC2. *

## Praktik terbaik: peringatan anggaran
<a name="best-practices-budget-alerts-v3"></a>

Untuk mengelola biaya sumber daya di AWS ParallelCluster, sebaiknya gunakan AWS Budgets tindakan untuk membuat anggaran. Anda juga dapat membuat peringatan ambang anggaran yang ditentukan untuk AWS sumber daya yang dipilih. Untuk informasi selengkapnya, lihat Meng [ konfigurasi tindakan anggaran ](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-controls.html) di Panduan *AWS Budgets Pengguna*. Demikian pula, Anda juga dapat menggunakan Amazon CloudWatch untuk membuat alarm penagihan. Untuk informasi selengkapnya, lihat [ Membuat alarm penagihan untuk memantau perkiraan AWS biaya Anda](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/monitor_estimated_charges_with_cloudwatch.html).

## Praktik terbaik: memindahkan cluster ke yang baru AWS ParallelCluster versi minor atau patch
<a name="best-practices-cluster-upgrades-v3"></a>

Saat ini setiap versi AWS ParallelCluster minor bersifat mandiri bersama dengan CLI-nya`pcluster`. Untuk memindahkan cluster ke versi minor atau patch baru, Anda harus membuat ulang cluster menggunakan CLI versi baru.

Untuk mengoptimalkan proses memindahkan cluster ke versi minor atau patch baru, kami sarankan Anda melakukan hal berikut:
+ Simpan data pribadi dalam volume eksternal yang dibuat di luar cluster, seperti Amazon EFS dan FSx for Lustre. Dengan melakukan ini, Anda dapat dengan mudah memindahkan data dari satu cluster ke cluster lain di masa mendatang.
+ Buat sistem penyimpanan bersama menggunakan jenis berikut. Anda dapat membuat sistem ini menggunakan AWS CLI atau Konsol Manajemen AWS.
  + [`SharedStorage`](SharedStorage-v3.md) / [`EbsSettings`](SharedStorage-v3.md#SharedStorage-v3-EbsSettings) / [`VolumeId`](SharedStorage-v3.md#yaml-SharedStorage-EbsSettings-VolumeId)
  + [`SharedStorage`](SharedStorage-v3.md) / [`EfsSettings`](SharedStorage-v3.md#SharedStorage-v3-EfsSettings) / [`FileSystemId`](SharedStorage-v3.md#yaml-SharedStorage-EfsSettings-FileSystemId)
  + [`SharedStorage`](SharedStorage-v3.md) / [`FsxLustreSettings`](SharedStorage-v3.md#SharedStorage-v3-FsxLustreSettings) / [`FileSystemId`](SharedStorage-v3.md#yaml-SharedStorage-FsxLustreSettings-FileSystemId)

  Tentukan sistem file atau volume dalam konfigurasi cluster sebagai sistem file atau volume yang ada. Dengan cara ini, mereka dipertahankan ketika Anda menghapus cluster dan dapat dilampirkan ke cluster baru.

  Kami menyarankan Anda menggunakan Amazon EFS atau FSx untuk sistem file Lustre. Kedua sistem ini dapat dilampirkan ke beberapa cluster secara bersamaan. Selain itu, Anda dapat melampirkan salah satu sistem ini ke cluster baru sebelum Anda menghapus cluster yang ada.
+ Gunakan tindakan bootstrap [ khusus ](custom-bootstrap-actions-v3.md) untuk menyesuaikan instance Anda daripada menggunakan AMI khusus. Jika sebaliknya, Anda menggunakan AMI khusus, maka Anda perlu menghapus dan membuat ulang AMI itu untuk setiap rilis versi baru.
+ Kami menyarankan Anda menerapkan rekomendasi sebelumnya dalam urutan berikut:

  1. Perbarui konfigurasi cluster yang ada untuk menggunakan definisi sistem file yang ada.

  1. Verifikasi `pcluster` versi dan perbarui jika diperlukan.

  1. Buat dan uji cluster baru. Saat Anda menguji cluster baru, periksa hal berikut:
     + Pastikan data Anda tersedia di cluster baru.
     + Pastikan aplikasi Anda berfungsi di cluster baru.

  1. Setelah cluster baru Anda sepenuhnya diuji dan operasional dan Anda tidak lagi memerlukan cluster yang ada, hapus.

## Praktik terbaik: Pemeriksaan kesehatan GPU
<a name="best-practices-gpu-health-checks-v3"></a>

### Pemeriksaan kesehatan GPU bawaan
<a name="best-practices-gpu-health-checks-builtin-v3"></a>

Pemeriksaan kesehatan GPU bawaan ([`HealthChecks/Gpu/Enabled`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-HealthChecks-Gpu-Enabled)) tidak aktif kecuali Anda mengaktifkannya. Saat diaktifkan, ia menjalankan diagnostik NVIDIA DCGM level-2 pada GPU node sebagai bagian dari prolog. Slurm Karena diagnostik berjalan di prolog dan pekerjaan tidak dapat dimulai sampai prolog selesai, desain ini sesuai dengan jenis instance di mana diagnostik selesai dengan cepat.

Pemeriksaan bawaan hanya dapat diandalkan dengan alokasi eksklusif pekerjaan (satu pekerjaan per node). Pada node yang dibagikan oleh lebih dari satu pekerjaan, itu dapat mengganggu pekerjaan yang sedang berjalan dan menguras node yang sehat, jadi aktifkan hanya pada antrian dengan [`JobExclusiveAllocation: true`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-JobExclusiveAllocation).

Selain itu, pada keluarga instance GPU P6 dan P6e (misalnya, `p6-b200` dan`p6-b300`) dan generasi instans P-family GPU yang lebih baru, diagnostik membutuhkan waktu cukup lama sehingga tidak boleh dijalankan di prolog: biasanya melebihi batas waktu Slurm prolog dan menyebabkan node yang sehat terkuras dan pekerjaan diperlukan. Pada jenis instans ini, biarkan pemeriksaan kesehatan GPU dinonaktifkan (`HealthChecks/Gpu/Enabled: false`).

### Opsi untuk menjalankan pemeriksaan kesehatan GPU Anda sendiri
<a name="best-practices-gpu-health-checks-options-v3"></a>

Untuk menjalankan pemeriksaan kesehatan GPU pada instans ini, pilih dari pendekatan berikut, cocokkan setiap pemeriksaan dengan saat dijalankan — saat startup node, sebelum pekerjaan, atau setelah pekerjaan. Ini mengikuti model NVIDIA untuk kesehatan dan diagnostik GPU (lihat kesehatan dan diagnostik [ NVIDIA DCGM](https://docs.nvidia.com/datacenter/dcgm/latest/user-guide/feature-overview.html#health-and-diagnostics)); `dcgmi diag` diagnostik tumbuh secara mendalam dan durasi berdasarkan level (lihat diagnostik [https://docs.nvidia.com/datacenter/dcgm/latest/user-guide/dcgm-diagnostics.html#run-levels-and-tests](https://docs.nvidia.com/datacenter/dcgm/latest/user-guide/dcgm-diagnostics.html#run-levels-and-tests) DCGM).

**penting**  
Pada node yang dibagikan oleh lebih dari satu pekerjaan, jalankan `dcgmi diag` diagnostik apa pun (dari level-1 hingga level-4) hanya jika tidak ada pekerjaan lain yang menggunakan node. Jika tidak, itu bisa gagal dan menguras simpul.
+ **Periksa saat startup simpul. ** Gunakan ini untuk memvalidasi node sekali, ketika bergabung dengan cluster, sebelum menerima pekerjaan. Karena belum ada pekerjaan yang berjalan, itu dapat berjalan secara mendalam`dcgmi diag`; perhatikan bahwa ini hanya menangkap kesalahan yang ada saat startup, bukan degradasi yang muncul nanti. Instal dan panggil cek Anda dengan tindakan `OnNodeConfigured` khusus. Lihat [Tindakan bootstrap khusus](custom-bootstrap-actions-v3.md).
+ **Periksa di prolog. ** Gunakan ini untuk gerbang kesiapan cepat sebelum setiap pekerjaan. Karena prolog berjalan pada setiap pekerjaan dan memblokir pekerjaan dari memulai hingga selesai, pertahankan pemeriksaan selama beberapa detik. Misalnya, `nvidia-smi` (opsional dengan pemindaian log kernel untuk kesalahan [ NVIDIA Xid](https://docs.nvidia.com/deploy/xid-errors/index.html)), atau level-1. `dcgmi diag` Lihat [Slurm dan `prolog` `epilog`](slurm-prolog-epilog-v3.md).
+ **Periksa di epilog. ** Gunakan ini untuk memvalidasi node setelah pekerjaan selesai. Misalnya, untuk menjalankan pemeriksaan lebih dalam ketika pekerjaan gagal, atau untuk menangkap GPU yang terdegradasi selama proses sebelum pekerjaan berikutnya dijadwalkan. Itu bisa berjalan lebih dalam`dcgmi diag`. Untuk menghindari pemeriksaan setelah setiap pekerjaan, Anda mungkin ingin menjalankan diagnostik level-2 hanya ketika pekerjaan gagal. Lihat [Slurm dan `prolog` `epilog`](slurm-prolog-epilog-v3.md).

**catatan**  
AWS ParallelCluster menggantikan node statis yang dikeringkan atau gagal (dan mengakhiri yang dinamis), sehingga menguras node dengan kesalahan yang dikonfirmasi mengakibatkan diganti.