ベストプラクティス

プレイスメントグループ: Slurm を使用している場合には、クラスタープレイスメントグループを使用するように各 Slurm キューを設定することを検討してください。クラスタープレイスメントグループは、単一のアベイラビリティーゾーン内のインスタンスを論理的にグループ化したものです。詳細については、「Amazon EC2 ユーザーガイド」の「プレイスメントグループ」を参照してください。キューの Networking セクションで PlacementGroup を指定できます。各コンピューティングリソースはキューのプレイスメントグループに割り当てられます。コンピュートリソースの Networking セクションで PlacementGroup を指定すると、その特定のコンピューティングリソースがそのプレイスメントグループに割り当てられます。コンピューティングリソースのプレイスメントグループの仕様は、コンピューティングリソースのキュー仕様よりも優先されます。詳細については、「SlurmQueues/Networking/PlacementGroup」および「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/Networking/PlacementGroup/Name が優先的な代替として SlurmQueues/Networking/PlacementGroup/Id に追加されました。

詳細については、「Networking」を参照してください。

拡張ネットワーク: 拡張ネットワークをサポートするインスタンスタイプの選択を検討してください。この推奨事項は、すべての現行世代のインスタンスに適用されます。詳細については、「Amazon EC2 ユーザーガイド」の「Linux での拡張ネットワーキング」を参照してください。

Elastic Fabric Adapter: 高レベルのスケーラブルなインスタンス間通信をサポートするには、ネットワークに EFA ネットワークインターフェイスを選択することを検討してください。EFA のカスタムビルドのオペレーティングシステム (OS) バイパスハードウェアは、 AWS クラウドのオンデマンドの伸縮性と柔軟性により、インスタンス間の通信を強化します。Efa を使用するための Slurm キュー ComputeResource はそれぞれ設定できます。での EFA の使用の詳細については AWS ParallelCluster、「」を参照してくださいElastic Fabric Adapter。

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

EFA の詳細については、「Linux インスタンス用 Amazon EC2 ユーザーガイド」の「Elastic Fabric Adapter」を参照してください。

インスタンス帯域幅: 帯域幅はインスタンスのサイズに合わせて調整されます。さまざまなインスタンスタイプについては、「Amazon EC2 ユーザーガイド」の「Amazon EBS 最適化インスタンス」と「Amazon EBS ボリュームタイプ」を参照してください。

Amazon EFS や FSx for Lustre など、クラスターの外部で作成された外部ボリュームに個人データを保存します。これにより、将来、あるクラスターから別のクラスターにデータを簡単に移動できます。

以下のタイプを使用して共有ストレージシステムを作成します。これらのシステムは、 AWS CLI または を使用して作成できます AWS マネジメントコンソール。

クラスター設定内のファイルシステムまたはボリュームを既存のファイルシステムまたはボリュームとして定義します。これにより、クラスターを削除しても保持され、新しいクラスターにアタッチできます。

Amazon EFS または FSx for Lustre をファイルシステムに使用することをお勧めします。これらのシステムは両方とも、同時に複数のクラスターに接続できます。さらに、既存のクラスターを削除する前に、これらのシステムのいずれかを新しいクラスターに接続できます。

カスタム AMI を使用するのではなく、カスタムブートストラップアクションを使用してインスタンスをカスタマイズします。代わりにカスタム AMI を使用する場合は、新しいバージョンがリリースされるたびにその AMI を削除して再作成する必要があります。

上記の推奨事項を次の順序で適用することをお勧めします。

ノードの起動時に確認します。これを使用して、作業を受け入れる前に、クラスターに参加するときにノードを 1 回検証します。まだ実行中のジョブがないため、ディープ を実行できますdcgmi diag。起動時に存在する障害のみをキャッチし、後で発生する劣化はキャッチしないことに注意してください。OnNodeConfigured カスタムアクションを使用してチェックをインストールして呼び出します。「カスタムブートストラップアクション」を参照してください。

プロログを確認します。これを各ジョブの前に高速準備ゲートに使用します。プロログはすべてのジョブで実行され、ジョブの開始から完了までブロックされるため、チェックは数秒に維持します。例えば、 nvidia-smi (オプションで NVIDIA Xid エラーのカーネルログスキャンを使用) または level-1 ですdcgmi diag。「Slurm および prolog epilog」を参照してください。

エピックログを確認します。これを使用して、ジョブの完了後にノードを検証します。例えば、ジョブが失敗したときにより詳細なチェックを実行したり、次のジョブがスケジュールされる前に実行中にパフォーマンスが低下した GPU をキャッチしたりできます。より深い を実行できますdcgmi diag。ジョブごとにチェックされないようにするには、ジョブが失敗した場合にのみレベル 2 診断を実行することをお勧めします。「Slurm および prolog epilog」を参照してください。