翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ベストプラクティス
以下のセクションでは、 を使用するためのベストプラクティスについて説明します。これには AWS ParallelCluster、ネットワークパフォーマンスと予算アラートが含まれます。これらのベストプラクティスに従っていても問題が発生した場合は、考えられる解決策[AWS ParallelCluster トラブルシューティング](troubleshooting-v3.md)について「」を参照してください。
## ベストプラクティスヘッドノードインスタンスタイプの選択
ヘッドノードはジョブを実行しませんが、その機能とサイジングは、クラスターの全体的なパフォーマンスにとって重要です。ヘッドノードに使用するインスタンスタイプを選択するときは、次の特性を考慮してください。
**クラスターサイズ:** ヘッドノードはクラスターのスケーリングロジックを調整し、スケジューラに新しいノードをアタッチします。多数のノードを持つクラスターをスケールアップおよびスケールダウンするには、ヘッドノードに追加のコンピューティング容量を提供します。
**共有ファイルシステム:** 共有ファイルシステムを使用する場合は、ワークフローを処理するのに十分なネットワーク帯域幅と Amazon EBS の帯域幅を持つインスタンスタイプを選択してください。ヘッドノードがクラスターに十分な NFS サーバーディレクトリを公開できることと、コンピューティングノードとヘッドノード間で共有する必要のあるアーティファクトを処理できることをそれぞれ確認してください。
## ベストプラクティス: ネットワークパフォーマンス
ハイパフォーマンスコンピューティング (HPC) アプリケーションには、ネットワークのパフォーマンスが重要です。信頼できるネットワークパフォーマンスがなければ、これらのアプリケーションは期待どおりに動作しません。ネットワークのパフォーマンスを最適化するには、次のベストプラクティスを検討してください。
+ **プレイスメントグループ:** Slurm を使用している場合には、クラスタープレイスメントグループを使用するように各 Slurm キューを設定することを検討してください。クラスタープレイスメントグループは、単一のアベイラビリティーゾーン内のインスタンスを論理的にグループ化したものです。詳細については、「*Amazon EC2 ユーザーガイド*」の「[プレイスメントグループ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html)」を参照してください。キューの [`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking) セクションで [`PlacementGroup`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-PlacementGroup) を指定できます。各コンピューティングリソースはキューのプレイスメントグループに割り当てられます。コンピュートリソースの [`Networking`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Networking) セクションで [`PlacementGroup`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Networking-PlacementGroup) を指定すると、その特定のコンピューティングリソースがそのプレイスメントグループに割り当てられます。コンピューティングリソースのプレイスメントグループの仕様は、コンピューティングリソースのキュー仕様よりも優先されます。詳細については、「[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking)/[`PlacementGroup`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-PlacementGroup)」および「[`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}}
```
または、 でプレイスメントグループ AWS ParallelCluster を作成することもできます。
```
Networking:
PlacementGroup:
Enabled: true
```
AWS ParallelCluster バージョン 3.3.0 以降、プレイスメントグループの作成と管理が変更されました。キューに `name` または `Id` を付けずに有効にするプレイスメントグループを指定すると、キュー全体に 1 つの管理グループを割り当てるのではなく、各コンピューティングリソースに独自のマネージドプレイスメントグループが割り当てられます。これにより、容量不足によるエラーを減らすことができます。キュー全体に 1 つのプレイスメントグループが必要な場合は、名前付きのプレイスメントグループを使用できます。
[`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) が優先的な代替として [`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) に追加されました。
詳細については、「[`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking)」を参照してください。
+ **拡張ネットワーク:** 拡張ネットワークをサポートするインスタンスタイプの選択を検討してください。この推奨事項は、すべての[現行世代のインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#current-gen-instances)に適用されます。詳細については、「*Amazon EC2 ユーザーガイド*」の「[Linux での拡張ネットワーキング](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html)」を参照してください。
+ **Elastic Fabric Adapter:** 高レベルのスケーラブルなインスタンス間通信をサポートするには、ネットワークに EFA ネットワークインターフェイスを選択することを検討してください。EFA のカスタムビルドのオペレーティングシステム (OS) バイパスハードウェアは、 AWS クラウドのオンデマンドの伸縮性と柔軟性により、インスタンス間の通信を強化します。[`Efa`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Efa) を使用するための Slurm キュー [`ComputeResource`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) はそれぞれ設定できます。での EFA の使用の詳細については AWS ParallelCluster、「」を参照してください[Elastic Fabric Adapter](efa-v3.md)。
```
ComputeResources:
- Name: {{your-compute-resource-name}}
Efa:
Enabled: true
```
EFA の詳細については、「Linux インスタンス用 Amazon EC2 ユーザーガイド**」の「[Elastic Fabric Adapter](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html)」を参照してください。
+ **インスタンス帯域幅:** 帯域幅はインスタンスのサイズに合わせて調整されます。さまざまなインスタンスタイプについては、「*Amazon EC2 ユーザーガイド*」の「[Amazon EBS 最適化インスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html)」と「[Amazon EBS ボリュームタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html)」を参照してください。
## ベストプラクティス: 予算アラート
でリソースコストを管理するには AWS ParallelCluster、 AWS Budgets アクションを使用して予算を作成することをお勧めします。選択した AWS リソースに対して定義された予算しきい値アラートを作成することもできます。詳細については、「AWS Budgets ユーザーガイド**」の「[予算アクションの設定](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-controls.html)」を参照してください。同様に、Amazon CloudWatch を使用して請求アラームを作成することもできます。詳細については、「[AWS 予想料金をモニタリングする請求アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/monitor_estimated_charges_with_cloudwatch.html)」を参照してください。
## ベストプラクティス: AWS ParallelCluster クラスターを新しいマイナーバージョンまたはパッチバージョンに移動する
現在、各 AWS ParallelCluster マイナーバージョンは CLI `pcluster` とともに自己完結型です。クラスタを新しいマイナーバージョンまたはパッチバージョンに移行するには、新しいバージョンの CLI を使用してクラスターを再作成する必要があります。
クラスターを新しいマイナーバージョンまたはパッチバージョンに移行するプロセスを最適化するには、次のことをお勧めします。
+ Amazon EFS や FSx for Lustre など、クラスターの外部で作成された外部ボリュームに個人データを保存します。これにより、将来、あるクラスターから別のクラスターにデータを簡単に移動できます。
+ 以下のタイプを使用して共有ストレージシステムを作成します。これらのシステムは、 AWS CLI または を使用して作成できます 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)
クラスター設定内のファイルシステムまたはボリュームを既存のファイルシステムまたはボリュームとして定義します。これにより、クラスターを削除しても保持され、新しいクラスターにアタッチできます。
Amazon EFS または FSx for Lustre をファイルシステムに使用することをお勧めします。これらのシステムは両方とも、同時に複数のクラスターに接続できます。さらに、既存のクラスターを削除する前に、これらのシステムのいずれかを新しいクラスターに接続できます。
+ カスタム AMI を使用するのではなく、[カスタムブートストラップアクション](custom-bootstrap-actions-v3.md)を使用してインスタンスをカスタマイズします。代わりにカスタム AMI を使用する場合は、新しいバージョンがリリースされるたびにその AMI を削除して再作成する必要があります。
+ 上記の推奨事項を次の順序で適用することをお勧めします。
1. 既存のファイルシステム定義を使用するようにクラスター設定を更新します。
1. `pcluster` バージョンを確認し、必要に応じて更新します。
1. 新しいクラスターを作成してテストします。新しいクラスターをテストするときは、以下をチェックしてください。
+ データが新しいクラスターで利用可能であることを確認します。
+ アプリケーションが新しいクラスターで機能することを確認します。
1. 新しいクラスターが完全にテストされて動作し、既存のクラスターが不要になったら、そのクラスターを削除します。
## ベストプラクティス: GPU ヘルスチェック
### 組み込み GPU ヘルスチェック
組み込み GPU ヘルスチェック ([`HealthChecks/Gpu/Enabled`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-HealthChecks-Gpu-Enabled)) は、有効にしない限りオフになります。有効にすると、Slurmプロログの一部としてノードの GPUs で NVIDIA DCGM レベル 2 診断を実行します。診断は prolog で実行され、prolog が完了するまでジョブを開始できないため、この設計は診断がすぐに終了するインスタンスタイプに適しています。
組み込みチェックは、ジョブ排他的な割り当て (ノードごとに 1 つのジョブ) でのみ信頼性があります。複数のジョブによって共有されるノードでは、ジョブの実行が妨げられ、正常なノードがドレインされる可能性があるため、 を持つキューでのみ有効にします[`JobExclusiveAllocation: true`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-JobExclusiveAllocation)。
さらに、P6 および P6e GPU インスタンスファミリー ( `p6-b200`や など`p6-b300`) 以降の P ファミリー GPU インスタンス世代では、診断には prolog で実行しないように十分な時間がかかります。通常、Slurmprolog の時間制限を超え、正常なノードがドレインされ、ジョブが再キューに入れられます。これらのインスタンスタイプでは、GPU ヘルスチェックを無効にします (`HealthChecks/Gpu/Enabled: false`)。
### 独自の GPU ヘルスチェックを実行するためのオプション
これらのインスタンスで GPU ヘルスチェックを実行するには、ノードの起動時、ジョブ前、ジョブ後など、実行時に各チェックを照合して、次のアプローチから選択します。これは GPU のヘルスと診断に関する NVIDIA のモデルに従っており ([「NVIDIA DCGM のヘルスと診断](https://docs.nvidia.com/datacenter/dcgm/latest/user-guide/feature-overview.html#health-and-diagnostics)」を参照）、`dcgmi diag`診断はレベルごとに深さと期間が増加します ([「DCGM 診断](https://docs.nvidia.com/datacenter/dcgm/latest/user-guide/dcgm-diagnostics.html#run-levels-and-tests)」を参照）。
**重要**
複数のジョブで共有されているノードで、他のジョブがノードを使用していない場合にのみ`dcgmi diag`、診断 (レベル 1 からレベル 4) を実行します。そうしないと、ノードが失敗してドレインする可能性があります。
+ **ノードの起動時に確認します。**これを使用して、作業を受け入れる前に、クラスターに参加するときにノードを 1 回検証します。まだ実行中のジョブがないため、ディープ を実行できます`dcgmi diag`。起動時に存在する障害のみをキャッチし、後で発生する劣化はキャッチしないことに注意してください。`OnNodeConfigured` カスタムアクションを使用してチェックをインストールして呼び出します。「[カスタムブートストラップアクション](custom-bootstrap-actions-v3.md)」を参照してください。
+ **プロログを確認します。**これを各ジョブの前に高速準備ゲートに使用します。プロログはすべてのジョブで実行され、ジョブの開始から完了までブロックされるため、チェックは数秒に維持します。例えば、 `nvidia-smi` (オプションで [NVIDIA Xid エラー](https://docs.nvidia.com/deploy/xid-errors/index.html)のカーネルログスキャンを使用) または level-1 です`dcgmi diag`。「[Slurm および `prolog` `epilog`](slurm-prolog-epilog-v3.md)」を参照してください。
+ **エピックログを確認します。**これを使用して、ジョブの完了後にノードを検証します。例えば、ジョブが失敗したときにより詳細なチェックを実行したり、次のジョブがスケジュールされる前に実行中にパフォーマンスが低下した GPU をキャッチしたりできます。より深い を実行できます`dcgmi diag`。ジョブごとにチェックされないようにするには、ジョブが失敗した場合にのみレベル 2 診断を実行することをお勧めします。「[Slurm および `prolog` `epilog`](slurm-prolog-epilog-v3.md)」を参照してください。
**注記**
AWS ParallelCluster は、ドレインされた静的ノードまたは失敗した静的ノードを置き換え (動的ノードを終了) するため、障害が確認されたノードをドレインすると置き換えられます。