ベストプラクティス - AWS ParallelCluster

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ベストプラクティス

以下のセクションでは、 を使用するためのベストプラクティスを示します。これには AWS ParallelCluster、ネットワークパフォーマンスと予算アラートが含まれます。

ベストプラクティスヘッドノードインスタンスタイプの選択

ヘッドノードはジョブを実行しませんが、その機能とサイジングは、クラスターの全体的なパフォーマンスにとって重要です。ヘッドノードに使用するインスタンスタイプを選択するときは、次の特性を考慮してください。

クラスターサイズ: ヘッドノードは、クラスターのスケーリングロジックをオーケストレーションし、新しいノードをスケジューラに追加する責任を負います。多数のノードを持つクラスターをスケールアップまたはスケールダウンするには、ヘッドノードの処理能力を向上させることを検討してください。

共有ファイルシステム: 共有ファイルシステムを使用する場合は、ワークフローを処理するのに十分なネットワーク帯域幅と十分な Amazon EBS帯域幅を持つインスタンスタイプを選択します。ヘッドノードがクラスターに十分なNFSサーバーディレクトリを公開し、コンピューティングノードとヘッドノード間で共有する必要があるアーティファクトを処理できることを確認します。

ベストプラクティス: ネットワークパフォーマンス

ネットワークパフォーマンスは、高性能コンピューティング (HPC) アプリケーションにとって重要です。信頼できるネットワークパフォーマンスがなければ、これらのアプリケーションは期待どおりに動作しません。ネットワークのパフォーマンスを最適化するには、次のベストプラクティスを検討してください。

  • プレイスメントグループ: を使用している場合 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 クラウド。各 を設定できます。Slurm キューComputeResourceで を使用しますEfa。EFA で を使用する方法の詳細については AWS ParallelCluster、「」を参照してくださいElastic Fabric Adapter

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

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

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

ベストプラクティス: 予算アラート

のリソースコストを管理するには AWS ParallelCluster、 AWS Budgets アクションを使用して予算を作成することをお勧めします。選択した AWS リソースに対して定義済みの予算しきい値アラートを作成することもできます。詳細については、「AWS Budgets ユーザーガイド」の「予算アクションを設定する」を参照してください。同様に、Amazon を使用して請求アラーム CloudWatch を作成することもできます。詳細については、「AWS 予想料金をモニタリングする請求アラームの作成」を参照してください。

ベストプラクティス: クラスターを新しい AWS ParallelCluster マイナーバージョンまたはパッチバージョンに移動する

現在、各 AWS ParallelCluster マイナーバージョンは とともに自己完結型pclusterですCLI。クラスターを新しいマイナーバージョンまたはパッチバージョンに移動するには、新しいバージョンの を使用してクラスターを再作成する必要がありますCLI。

クラスターを新しいマイナーバージョンまたはパッチバージョンに移行するプロセスを最適化するには、次のことをお勧めします。

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

  • 以下のタイプを使用して共有ストレージシステムを作成します。これらのシステムは、 AWS CLI または を使用して作成できます AWS Management Console。

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

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

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

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

    1. 既存のファイルシステム定義を使用するようにクラスター設定を更新します。

    2. pcluster バージョンを確認し、必要に応じて更新します。

    3. 新しいクラスターを作成してテストします。新しいクラスターをテストするときは、以下をチェックしてください。

      • データが新しいクラスターで利用可能であることを確認します。

      • アプリケーションが新しいクラスターで機能することを確認します。

    4. 新しいクラスターが完全にテストされて動作し、既存のクラスターが不要になったら、そのクラスターを削除します。