次の方法で共有

HPC エネルギー環境用ストレージ

  • [アーティクル]

大規模な HPC ワークロードの場合には、従来のクラウド ファイル システムの容量を上回るデータ ストレージが必要になったり、データ アクセスが発生したりします。

使用するストレージ ソリューションを決定するために、アプリケーション要件について考慮して特定する必要がある要素を次に示します

  • 待ち時間、
  • IOPS、
  • スループット、
  • ファイルのサイズと数、
  • ジョブの実行時間
  • 関連するコスト
  • ストレージの場所に対するアフィニティ - オンプレミスと Azure

Azure で選択された HPC ストレージに影響を与える要因の詳細については、「Azure での HPC ストレージの選択に影響を与える要因を理解する」を参照してください。

特定の HPC ストレージ システムの選択に関するデシジョン ツリー。

ストレージ ソリューションを選択するときの考慮事項に関するデシジョン ツリーを示す図。

HPC の設計上の考慮事項

石油およびガス会社は、数エクサバイトの地震データ、井戸データ、地図、リースなどを効果的に管理して保存できる必要があります。 このデータを使用するには、生産の最適化、環境リスクの削減、運用上の安全性の向上に役立つリアルタイム分析を処理して提供できる高性能インフラストラクチャが必要です。

データ ストレージとアクセスのニーズは、ワークロードのスケールによって大きく異なります。 Azure では、HPC アプリケーションの速度と容量を管理するためのいくつかのアプローチがサポートされます。

エネルギー業界の大規模なバッチ ワークロードや HPC ワークロードの場合には、従来のクラウド ファイル システムの容量を上回るデータ ストレージが必要になったり、データ アクセスが発生したりします。 ハイ パフォーマンス コンピューティング (HPC) の高パフォーマンス I/O 要件と大規模なスケーラビリティのニーズにより、データストレージとアクセスに固有の課題が生まれます。

HPC は、地震と貯留層のシミュレーションやモデリングなどの複雑な問題を解決するために使用されます。これらの問題は従来のコンピューティング手法で処理するには実際的ではないかコスト効率が良くありません。 これは、並列処理と大規模なスケーラビリティを組み合わせて行い、大規模で複雑なコンピューティング タスクを迅速で効率的、そして確実に実行します。

さらに、Azure HPC クラスターでは、計算ノードは、必要に応じて起動してクラスターに割り当てられたジョブを実行できる仮想マシンです。 これらのノードは、計算タスクをクラスター全体に分散して、HPC が適用される複雑な問題を解決するために必要な高パフォーマンス並列処理を実現します。 計算ノードでは、ジョブの実行中に共有作業ストレージに対して読み取り/書き込み操作を実行する必要があります。 ノードがこのストレージにアクセスする方法は、次の 2 つのシナリオの間で連続します。

  • 多くの計算ノードに対する 1 つのデータ セット - このシナリオでは、単一のデータ ソースがネットワーク上にあり、すべての計算ノードが作業データにアクセスします。 構造的に単純ですが、I/O 操作はすべて、ストレージの場所の I/O 容量によって制限されます。
  • 多くの計算ノードに対する多数のデータ セット - このシナリオでは、単一のデータ ソースがネットワーク上にあり、すべての計算ノードが作業データにアクセスします。 構造的に単純ですが、I/O 操作はすべて、ストレージの場所の I/O 容量によって制限されます。

HPC の設計上の推奨事項

I/O と容量の独自の要件に最適なソリューションを選択してください。

ネットワーク ファイル システム (NFS)

NFS は、一般的に共有ストレージの場所へのアクセスを提供するために使用されます。 NFS を使用すると、サーバー VM はローカル ファイル システムを共有します。Azure の場合は、Azure Storage でホストされている 1 つ以上の仮想ハード ディスク (VHD) に保存されます。 その後、クライアントはサーバーの共有ファイルをマウントし、共有場所に直接アクセスできます。

ネットワーク ファイル システム (NFS) は、多くの場合、すべてのノードにマウントされたホーム ディレクトリとプロジェクト領域に使用されます。 また、多くの場合、研究グループがデータを共有するためのスペースを提供することもできます。 一般に、スループット ワークロードは水平方向にスケーラブルであり、個々のタスク間の依存関係はほとんどありません。 ジョブ スケジューラは、ノード間で作業を分割し、アクティビティを調整します。 NFS は、TCP/IP ネットワーク経由でアクセスされるノード間の一般的な共有ストレージです。

NFS はセットアップと保守が簡単であるという利点があり、Linux と Windows の両方のオペレーティング システムでサポートされています。 複数の NFS サーバーを使用してストレージをネットワークに分散させることができますが、個々のファイルには 1 つのサーバー経由でのみアクセスできます。

小規模のワークロードの場合は、要件に応じて、大規模なエフェメラル ディスクを搭載したストレージ最適化 VM または Azure Premium Storage を搭載した D シリーズ VM を使用して、ヘッド ノード上で NFS を実行することを検討します。 このソリューションは、500 コア以下のワークロードに適しています。

HPC シナリオでは、多くの場合、ファイル サーバーがボトルネックとして機能し、全体的なパフォーマンスが調整される可能性があります。 記載されている VM ごとの最大 IOPS とスループットよりも高いレートで、1 つの NFS サーバーからキャッシュされていないデータにアクセスしようとすると、調整が発生します。

多数のクライアントが単一の NFS サーバーに格納されているデータに対して作業を試みるシナリオでは、これらの制限に簡単に達してしまい、アプリケーション全体のパフォーマンスが低下する可能性があります。 HPC アプリケーションで使用される純粋な 1 対多のシナリオに近いほど、これらの制限に達するのが早くなります。

Azure 上の並列ファイル システム

並列ファイルシステムは、複数のネットワークのストレージ ノードにブロック レベル ストレージを分散します。 ファイル データは、これらのノード間で分散されます。つまり、ファイル データは複数のストレージ デバイスに分散されます。 これにより、共通の名前空間を介してアクセスできる複数のストレージ ノード間で、個々のストレージ I/O 要求がプールされます。

複数のストレージ デバイスとデータへの複数のパスを使用して高度な並列処理を実現し、一度に 1 つのノードのみにアクセスすることで課されるボトルネックを軽減します。 ただし、API または POSIX I/O インターフェイスのレベルで直接動作する場合、並列 I/O の調整と最適化が困難になる場合があります。 中間データ アクセス層と調整層を導入することで、並列ファイル システムは、アプリケーション開発者にアプリケーション層と I/O 層間の高レベルのインターフェイスを提供します。

Energy MPI ワークロードには、ノード間の待機時間の短い通信が必要な固有の要件があります。 ノードは高速相互接続を介して接続され、他のワークロードとの共有には対応できません。 MPI アプリケーションは、仮想環境でパススルー モードを使用して、ハイ パフォーマンス相互接続全体を活用します。 MPI ノードのストレージは、通常、Lustre のような並列ファイル システムであり、高速相互接続を介してアクセスされます。 Lustre/BeeGFS は、通常、主に地震処理 (ただし、貯留層シミュレーションも含む) の大きなスループット要件を処理するために使用されます。

Lustre などの並列ファイル システムは、大きなファイルへのアクセス、複数の計算ノードからの同時アクセス、大量のデータを必要とする HPC エネルギー ワークロードに使用されます。 並列ファイル システムの実装により、機能とパフォーマンスの観点から簡単にスケールインできます。 このようなファイル システムでは、大きな帯域幅と低い CPU 使用率で RDMA 転送を利用します。 並列ファイル システムは通常、スクラッチ領域として使用され、最適化された I/O を必要とする作業を目的としています。 たとえば、ワークロードのセットアップ、前処理、実行、後処理などがあります。

Azure Managed Lustre などの調整された並列ファイル サービスを使用すると、50,000 以上のコアで動作し、読み取り/書き込み速度は最大 500 GiB/秒、ストレージは 2.5 PB となります。

Azure 上の並列仮想ファイル システムの詳細については、「Microsoft Azure 上の並列仮想ファイル システム - パート 1: 概要 - Microsoft Tech Community」を参照してください。

  • 通常、Azure NetApp Files ディスクとローカル ディスクは、地震の解釈、モデルの準備、視覚化など、待機時間/IOPS の影響を受けやすいワークロードを処理するために使用されます。 最大 4,000 コアのワークロード (最大 6.5 GiB/秒のスループット) と、同じデータ セットへのマルチプロトコル (NFS/SMB) アクセスが必要なワークロードでの使用を検討してください。
  • Azure Managed Lustre は、HPC ワークロードに対してより高速で高容量のストレージを提供します。 このソリューションは、中規模から非常に大規模なワークロードに対して有効で、最大 500 GB/秒のスループットと最大 2.5 PiB のストレージ容量を備えた 50,000 以上のコアをサポートできます。
  • Standard または Premium BLOB は、コスト効率が良く、最も低コストのクラウド オファリングです。 このサービスは、エクサバイト スケール、高処理能力、必要に応じて低遅延アクセス、使い慣れたファイル システム、マルチプロトコル アクセス (REST、HDFS、NFS) を提供します。 高スループットと読み取り負荷の高いワークロードのために、BLOB サービス エンドポイントで NFS v3.0 を使用できます。 最新の更新/最終アクセス時間でライフサイクル管理を実行し、カスタマイズ可能なポリシーを使用したインテリジェントな階層化を実行できる、よりクールな層に移行することで、コストを最適化できます。
  • 石油およびガス エネルギー ワークロードでは大きなデータ サイズと、オンプレミスからクラウドへのボリューム転送メカニズムが必要になる (またはその逆) 場合があり、次の方法で達成できます。
    • オフライン - デバイス ベースの移行 (DataBox)
    • オンライン - ネットワーク経由 (ExpressRoute) ベースの移行。

次のステップ

次の記事の一覧は、エネルギー HPC 環境のクラウド導入のシナリオで成功するために役立つ、クラウド導入の取り組みにおける特定のポイントごとのガイダンスをまとめたものです。