多くの HPC ワークロードで、アプリケーションまたはワークフローの最高のエンドツーエンドパフォーマンスを達成できるかどうかは、処理中にファイルをホストするためにどのような適切なテクノロジーを使用するか、また MPI または他の通信プロトコルに対して最適に実行するようにネットワークスタックを構成できるかによります。このモジュールでは、AWS がこれらの分野で提供するオプションをカバーし、各ワークロードに適したソリューションを選択するのに役立つ料金/パフォーマンスで考慮すべき事項について説明します。
トピックの内容:
- HPC 用の AWS 上のストレージ
- HPC ワークロードに対するネットワークスケーラビリティ
AWS のストレージオプションの概要: AWS は、高性能なオブジェクトストレージから、EC2 インスタンスにアタッチできるさまざまな種類のファイルシステムまで、さまざまなストレージオプションを提供しています。パフォーマンスのみならず、ストレージタイプは料金やスケーラビリティなど、複数のディメンションで区別されます。次の表は、各 HPC データに適したストレージを見つけるための指針を示しています。
HPC のための共有ファイルシステム: 共有ストレージは、EBS ボリュームの単純な NFS マウント、EBS ボリュームから組み立てられた Intel Lustre、また EFS と呼ばれるマネージド AWS サービスなど、さまざまな方法で実現されます。インスタンスタイプと同様に、ストレージオプションをテストして最もパフォーマンスの高いファイルシステムタイプを見つけるのは簡単です。
インスタンスにアタッチされたストレージ: EBS ボリュームには、高い IOPS ボリューム、汎用、磁気オプションなど、さまざまなオプションがあります。多くの HPC アプリケーションは、より安価で汎用のマグネティックボリューム EBS ストレージタイプで非常にうまく動作します。インスタンスの選択と同様に、EBS ボリュームの選択はテストが簡単で、最適なソリューションを見つけることができます。
Lab Storage の構成: デフォルトの EnginFrame 自動化で使用されるストレージ構成オプションは次のとおりです。
- 統合スクリプトは、マスターとコンピューティングノード上の /efs の下に EFS ボリュームをマウントします。このファイルシステムには、アプリ用のディレクトリと、デフォルトで各ジョブ用の個別の送信ディレクトリをホストするスプーラーディレクトリが含まれます。
- AWS ParallelCluster は、マスターにアタッチされた EBS gp2 ボリュームと、/shared としてコンピューティングノードにマウントされた NFS も提供します。
- マスターインスタンスの /homeディレクトリも、コンピューティングノードに NFS マウントされています。OS の同じファイルシステムにインストールされているため、永続的なストレージとして使用することはお勧めできません。
これらの共有ファイルシステムのパフォーマンスは、作業負荷によって大きく異なります。どちらが最適かを理解するには、/efs (EnginFrame のデフォルトの場所として構成されている) と /shared の両方で同じケースをベンチマークすることが最善の方法です。
現在の AWS ネットワーキング: AWS は現在、SR-IOV (シングルルート I/O 仮想化) を使用した拡張ネットワーキング機能をサポートしています。SR-IOV は、従来の実装と比較し、I/O パフォーマンスが高く、CPU 利用率が低いデバイス仮想化の手法です。サポートされている Amazon EC2 インスタンスでは、より高い毎秒パケット数 (PPS) パフォーマンス、より低いインスタンス間レイテンシー、および非常に低いネットワークジッターを提供し、また High Throughput Computing (HTC)、「驚異的並列」アプリケーションの両方に加えて、「密結合」、MPI および OpenMP ベースの HPC アプリケーションでうまく機能することがテスト済みです。
ネットワーク速度はインスタンスの種類とサイズによって異なります。たとえば、r4.16xlarge は、同じプレイスメントグループ (インスタンスの論理的なグループ化) を使用する場合はインスタンス間に 20 ギガビットの接続性を提供し、拡張ネットワーキングを実現します。
ラボネットワーキング構成: 既定では、ラボは新しいプレイスメントグループを作成し、クラスターのすべてのコンピューティングノードがその中に起動されるように要求します。これにより、ノード間で最小のレイテンシーと最大の帯域幅が得られます。MPI アプリケーションを実行している場合は特に重要です。水平方向に 10 秒間数万コア以上に拡張する HTC 問題がある場合 (これはこのラボの範囲外です)、複数のプレイスメントグループでそれらを実行して、この多数のノードの割り当て場所に関して EC2 に高い柔軟性を与えられるようにすることを検討する必要があります。AWS ParallelCluster 設定で次のパラメータを設定することで、固定プレイスメントグループの使用を無効にできます。
placement_group = NONE
ヒント: クラスタを非常に多数のノードにスケールする必要がある場合や、高性能のストレージ要件がある場合は、テクニカルアカウントマネージャーや HPC Solution Architect に相談して、ターゲットアーキテクチャを確認し、潜在的なボトルネックを特定し、特定の目的に適した正しいテクノロジーを選択するのをサポートしてもらうのがよいでしょう。