View a markdown version of this page

Praktik terbaik - AWS ParallelCluster
Praktik terbaik: pemilihan jenis instance node kepalaPraktik terbaik: kinerja jaringanPraktik terbaik: peringatan anggaranPraktik terbaik: memindahkan cluster ke yang baru AWS ParallelCluster versi minor atau patchPraktik terbaik: Pemeriksaan kesehatan GPU

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

Praktik terbaik

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 solusi yang mungkin.

Praktik terbaik: pemilihan jenis instance node kepala

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

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 di Panduan Pengguna Amazon EC2. Anda dapat menentukan a PlacementGroup di Networking bagian antrian, setiap sumber daya komputasi ditetapkan ke grup penempatan antrian. Saat menentukan a PlacementGroup di 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/Networking/PlacementGroupdan 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 atauId, 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/Networking/PlacementGroup/Nameditambahkan sebagai alternatif pilihan untuk SlurmQueues/Networking/PlacementGroup/Id.

    Untuk informasi selengkapnya, lihat Networking.

  • Jaringan yang ditingkatkan: Pertimbangkan untuk memilih jenis instance yang mendukung jaringan yang ditingkatkan. Rekomendasi ini berlaku untuk semua inst ans generasi saat ini. Untuk informasi selengkapnya, lihat peningkatan jaringan di Linux 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 untuk digunakan Efa. Untuk informasi lebih lanjut tentang menggunakan EFA dengan AWS ParallelCluster, lihatElastic Fabric Adapter.

    ComputeResources:
  - Name: your-compute-resource-name
    Efa:
      Enabled: true

    Untuk informasi selengkapnya tentang EFA, lihat Adaptor Kain Elastis 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 dan jenis volume Amazon EBS di Panduan Pengguna Amazon EC2.

Praktik terbaik: peringatan anggaran

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 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.

Praktik terbaik: memindahkan cluster ke yang baru AWS ParallelCluster versi minor atau patch

Saat ini setiap versi AWS ParallelCluster minor bersifat mandiri bersama dengan CLI-nyapcluster. 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.

    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 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.

    2. Verifikasi pcluster versi dan perbarui jika diperlukan.

    3. 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.

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

Praktik terbaik: Pemeriksaan kesehatan GPU

Pemeriksaan kesehatan GPU bawaan

Pemeriksaan kesehatan GPU bawaan (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.

Selain itu, pada keluarga instance GPU P6 dan P6e (misalnya, p6-b200 danp6-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

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); 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 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 mendalamdcgmi 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 kustom.

  • 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), atau level-1. dcgmi diag Lihat Slurm dan prolog epilog.

  • 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 dalamdcgmi diag. Untuk menghindari pemeriksaan setelah setiap pekerjaan, Anda mungkin ingin menjalankan diagnostik level-2 hanya ketika pekerjaan gagal. Lihat Slurm dan prolog epilog.

catatan

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