ベストプラクティス - AWS ParallelCluster
ベストプラクティス:マスターインスタンスタイプの選択ベストプラクティス: ネットワークパフォーマンスベストプラクティス: 予算アラートベストプラクティス: AWS ParallelCluster クラスターを新しいマイナーバージョンまたはパッチバージョンに移動する

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

ベストプラクティス

ベストプラクティス:マスターインスタンスタイプの選択

マスターノードはジョブを実行しませんが、その機能とサイジングは、クラスターの全体的なパフォーマンスにとって重要です。

マスターノードに使用するインスタンスタイプを選択するときは、次の項目を評価します。

  • クラスターサイズ: マスターノードはいかなるジョブも実行しませんが、その機能とサイズはクラスターの全体的なパフォーマンスにとって重要です。かなりの数のノードのクラスターをスケールアップまたはスケールダウンする必要がある場合、マスターノードの処理能力を向上させることを検討してください。

  • 共有ファイルシステム: 共有ファイルシステムを使用してコンピューティングノードとマスターノード間でアーティファクトを共有する場合、マスターが NFS サーバーを公開しているノードであることを考慮してください。このため、ワークフローを処理するのに十分なネットワーク帯域幅と Amazon EBS の専用帯域幅を持つインスタンスタイプを選択する必要があります。

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

ネットワーク通信を改善するための可能性を網羅した 3 つのヒントがあります。

  • プレイスメントグループ: クラスタープレイスメントグループは、単一のアベイラビリティーゾーン内のインスタンスを論理的にグループ化したものです。プレイスメントグループの詳細については、「Amazon EC2 ユーザーガイド」の「プレイスメントグループ」を参照してください。placement_group = your-placement-group-name で独自の配置グループを使用するようにクラスターを設定したり、placement_group = DYNAMIC で "compute" 戦略による配置グループを AWS ParallelCluster に作成させることができます。詳細については、「placement_group for multiple queue mode」、「placement_group for single queue mode」を参照してください。

  • 拡張ネットワーキング: 拡張ネットワークをサポートするインスタンスタイプの選択を検討してください。詳細については、「Amazon EC2 ユーザーガイド」の「Linux での拡張ネットワーキング」を参照してください。

  • Elastic Fabric Adapter: スケーラブルで高いレベルのインスタンス間通信をサポートするには、お使いのネットワークに EFA ネットワークインターフェイスを選択することを検討してください。EFA のカスタムビルドオペレーティングシステム (OS) バイパスハードウェアは、 AWS クラウドのオンデマンドの伸縮性と柔軟性により、インスタンス間の通信を強化します。EFA を使用するように単一の Slurm クラスターキューを設定するには、enable_efa = true を設定します。で EFA を使用する方法の詳細については AWS ParallelCluster、Elastic Fabric Adapter「」および「」を参照してくださいenable_efa。EFA の詳細については、「Linux インスタンス用 Amazon EC2 ユーザーガイド」の「Elastic Fabric Adapter」を参照してください。

  • インスタンス帯域幅: 帯域幅はインスタンスサイズに応じてスケールするため、ニーズに合ったインスタンスタイプの選択を検討する必要があります。詳細については、「Amazon EC2 ユーザーガイド」の「Amazon EBS 最適化インスタンス」と「Amazon EBS ボリュームの種類」を参照してください。

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

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

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

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

クラスターを新しいマイナーバージョンに移行するプロセスを最適化するため、またはその他の理由で共有ストレージデータを保存したりするには、次のベストプラクティスを使用することをお勧めします。

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

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

    それらを既存のファイルシステムとして新しいクラスター構成に追加します。こうすることで、クラスターを削除しても保存され、新しいクラスターにアタッチすることができます。共有ストレージシステムは、通常、クラスターに接続されていても、クラスターから切り離されていても料金が発生します。

    Amazon EFS または Amazon FSx for Lustre ファイルシステムを使用することをお勧めします。これは、複数のクラスターに同時にアタッチでき、古いクラスターを削除する前に新しいクラスターにアタッチできるためです。詳細については、「Amazon EFS ユーザーガイド」の「Mounting Amazon EFS file systems」と、「Amazon FSx for Lustre ユーザーガイド」の「FSx for Lustre ファイルシステムへのアクセス」を参照してください。

  • カスタム AMI ではなく、カスタムブートストラップアクションを使用してインスタンスをカスタマイズします。これにより、新しいバージョンごとに新しいカスタム AMI を作成する必要がなくなるため、作成プロセスが最適化されます。

  • 推奨シーケンスです。

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

    2. pcluster バージョンを確認し、必要に応じて更新してください。

    3. 新しいクラスターを作成してテストします。

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

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

    4. 新しいクラスターが完全にテストされ、動作しており、古いクラスターを使用しないことが確実な場合は、そのクラスターを削除します。