ベストプラクティス - 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 クラウドのオンデマンドの伸縮性と柔軟性により、インスタンス間の通信を強化します。単一の を設定するには Slurm を使用するクラスターキューEFA、 を設定しますenable_efa = true。EFA で を使用する方法の詳細については AWS ParallelCluster、Elastic Fabric Adapter「」および「」を参照してくださいenable_efa。の詳細については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 マイナーバージョンは とともに自己完結型ですpclusterCLI。クラスターを新しいマイナーバージョンまたはパッチバージョンに移動するには、新しいバージョンの を使用してクラスターを再作成する必要がありますCLI。

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

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

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

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

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

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

  • 推奨シーケンスです。

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

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

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

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

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

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