Azure HPC ワークロード用のストレージ
ストレージ アクセスは、ハイ パフォーマンス コンピューティング (HPC) ワークロード パフォーマンスを計画する際に考慮すべき重要な要素です。 特定の環境で大規模な HPC ワークロードを使用すると、従来のクラウド ファイル システムの機能を超えるデータ ストレージとアクセスに対する需要を生み出すことができます。 この記事では、Azure HPC ワークロードに適したストレージを選択するのに役立つ推奨事項について説明します。 また、エネルギー、財務、製造業界における HPC ワークロードのストレージに関する推奨事項も提供します。
使用するストレージ ソリューションを決定するのに役立つ、アプリケーションの要件に関連する次の要因を考慮してください。
- レイテンシ
- 1 秒あたりの入出力操作 (IOPS)
- スループット
- ファイルのサイズと数
- ジョブのランタイム
- 費用
- ストレージの場所 - オンプレミスと Azure
詳細については、「Azureでの HPC ストレージの選択に影響を与える要因を理解する」を参照してください。
次の図は、特定の HPC ストレージ システムの選択に適したデシジョン ツリーを示しています。
HPC に関する考慮事項
石油およびガス会社は、数エクサバイトの地震データ、ウェル データ、マップ、リースを効果的に管理および格納できる必要があります。 このデータを使用するには、生産の最適化、環境リスクの軽減、運用上の安全性の向上に役立つリアルタイム分析を処理して提供できる高性能インフラストラクチャが必要です。
データ ストレージの とアクセスのニーズは、ワークロードのスケールによって大きく異なります。 Azure では、HPC アプリケーションの速度と容量を管理するためのいくつかの方法がサポートされています。
エネルギー業界の大規模なバッチワークロードと HPC ワークロードには、従来のクラウド ファイル システムの機能を超えるデータ ストレージとアクセスが必要です。 高パフォーマンスの入出力 (I/O) 要件と、HPC の大規模なスケーラビリティ ニーズにより、データ ストレージとアクセスに固有の課題が生じます。
HPC は、地震と貯水池のシミュレーションやモデリングなどの複雑な問題を解決します。これは、従来のコンピューティング手法では実用的でもコスト効率も高くありません。 HPC は、並列処理と大規模で複雑なコンピューティング タスクを迅速、効率的、確実に実行するための大規模なスケーラビリティを組み合わせることで、これらの問題を解決します。
Azure HPC クラスターでは、コンピューティング ノードは仮想マシン (VM) であり、クラスターに割り当てられているジョブをすばやく作成して実行できます。 これらのノードは、計算タスクをクラスター全体に分散します。 この分散は、複雑な HPC の問題を解決するために必要な高パフォーマンスの並列処理を実現するのに役立ちます。 コンピューティング ノードは、ジョブの実行時に共有作業ストレージに対して読み取りと書き込みの操作を実行する必要があります。 ノードは、次の 2 つの極端なシナリオの範囲でこのストレージにアクセスします。
多くのコンピューティング ノードに対する 1 つのデータ セット。 このシナリオでは、すべてのコンピューティング ノードが作業データにアクセスする単一のデータ ソースがネットワーク上にあります。 構造はシンプルですが、ストレージの場所の I/O 容量によって I/O 操作が制限されます。
多数のコンピューティング ノードに対する多数のデータ セット。 このシナリオでは、すべてのコンピューティング ノードが作業データにアクセスする多数のデータ ソースがネットワーク上にあります。 構造はシンプルですが、ストレージの場所の I/O 容量によって I/O 操作が制限されます。
HPC 設計に関する推奨事項
独自の I/O と容量の要件に最適なソリューションを選択します。
ネットワーク ファイル システム
ネットワーク ファイル システム (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 シナリオでは、ファイル サーバーが全体的なパフォーマンスを調整するボトルネックとして機能することがよくあります。 1 台の NFS サーバーからキャッシュされていないデータに、記載されている VM ごとの最大 IOPS とスループットよりも高いレートでアクセスしようとすると、調整が行われます。
1 つの NFS サーバーに格納されているデータに対して多数のクライアントが作業を試みるシナリオでは、これらの制限に簡単に達できます。 これらの制限により、アプリケーション全体のパフォーマンスが低下する可能性があります。 HPC アプリケーションで使用される純粋な 1 対多シナリオに近いほど、これらの制限が早く発生します。
Azure 上の並列ファイル システム
並列ファイル システムは、複数のネットワークストレージノードにブロックレベルのストレージを分散します。 これらのノード間でファイル データが分散されるため、ファイル データは複数のストレージ デバイスに分散されます。 この配布では、共通の名前空間を介してアクセスできる複数のストレージ ノード間で、個々のストレージ I/O 要求をプールします。
複数のストレージ デバイスとデータへの複数のパスを使用して、高度な並列処理を実現します。 この方法では、一度に 1 つのノードにのみアクセスすることによって課されるボトルネックの数を減らします。 ただし、API または POSIX I/O インターフェイスのレベルで直接動作する場合、並列 I/O の調整と最適化が困難な場合があります。 中間データ アクセス層と調整層を導入することで、並列ファイル システムはアプリケーション開発者にアプリケーション層と I/O 層の間の高度なインターフェイスを提供します。
エネルギー メッセージング パッシング インターフェイス (MPI) ワークロードには、ノード間の待機時間の短い通信を必要とする固有の要件があります。 ノードは高速相互接続を介して接続され、他のワークロードとの共有に簡単に適応できません。 MPI アプリケーションは、仮想化環境で Pass-Through モードを介して、高パフォーマンスの相互接続全体を使用します。 MPI ノードのストレージは、通常、高速相互接続を介してアクセスされる Lustre のような並列ファイル システムです。 Lustre と BeeGFS は、通常、地震処理の大きなスループット要件を処理するために使用されます。 より少ない範囲では、それらは貯水池シミュレーションにも使用されます。
Lustre などの並列ファイル システムは、大規模なファイルへのアクセス、複数のコンピューティング ノードからの同時アクセス、大量のデータを必要とする HPC エネルギー ワークロードに使用されます。 並列ファイル システムの実装により、機能とパフォーマンスの観点から簡単にスケーリングできます。 これらのファイル システムは、大きな帯域幅と CPU 使用率の低下を伴うリモートダイレクト メモリ アクセス転送を利用します。 並列ファイル システムは、多くの場合、スクラッチ領域として使用され、最適化された I/O を必要とする作業を目的としています。 たとえば、ワークロードのセットアップ、前処理、実行、後処理などがあります。
Azure Managed Lustre などの調整された並列ファイル サービスは、最大 500 GBps および 2.5 PB ストレージの読み取り/書き込みレートで、50,000 以上のコアで動作します。 詳細については、Microsoft Azureでの並列仮想ファイル システムの
HPC コンポーネント
通常、Azure NetApp Files とローカル ディスクは、地震の解釈、モデルの準備、視覚化など、待機時間と IOPS に依存するワークロードを処理するために使用されます。 最大 4,000 コアのワークロード (最大 6.5 GiBps) のワークロード、および同じデータ セットへのマルチプロトコル NFS およびサーバー メッセージ ブロック (SMB) アクセスの恩恵を受ける、または必要とするワークロードには、Azure NetApp Files を使用することを検討してください。
Managed Lustre は、HPC ワークロードに対してより高速で高い容量のストレージを提供します。 このソリューションは、中規模から大規模のワークロードに対して機能し、最大 500 GBps のスループットと最大 2.5 PiB のストレージ容量を備えた 50,000 以上のコアをサポートできます。
Standard または Premium Azure Blob Storage は、低コストのクラウド オファリングであるため、コスト効率が高くなります。 このサービスは、必要に応じてエクサバイト規模の高スループットで低待機時間のアクセス、使い慣れたファイル システム インターフェイス、マルチプロトコル アクセス (REST、HDFS、NFS) を提供します。 高スループットで読み取り負荷の高いワークロードには、BLOB サービス エンドポイントで NFS v3.0 を使用できます。 よりクールなストレージ層に移行することで、コストを最適化できます。 このアプローチにより、最後の更新またはアクセス時間に基づくライフサイクル管理と、カスタマイズ可能なポリシーを使用したインテリジェントな階層化が可能になります。
石油およびガスのエネルギー ワークロードでは、オンプレミス システムとクラウドの間で大きなデータ サイズとボリュームを転送することが必要になる場合があります。 オフライン移行では、Azure Data Box などのデバイス ベースのサービスが使用されます。 オンライン移行では、Azure ExpressRoute などのネットワーク ベースのサービスが使用されます。
次の表に、Blob Storage、Azure Files、Managed Lustre、Azure NetApp Files の比較を示します。
| カテゴリ | Blob Storage（ブロブ ストレージ） | Azure Files | Managed Lustre | Azure NetApp Files |
|---|---|---|---|---|
| 使用事例 | データが 1 回取り込まれたり、最小限に変更されたりする大規模な読み取り負荷の高いシーケンシャル アクセス ワークロードに最適です。 メンテナンスが軽い場合は、総保有コストが低くなります。 シナリオの例としては、大規模な分析データ、スループットの機密性の高いハイ パフォーマンス コンピューティング、バックアップとアーカイブ、自動運転、メディア レンダリング、ゲノム シーケンスなどがあります。 |
ランダム アクセス ワークロードに最適な高可用性サービス。 NFS 共有の場合、Azure Files は POSIX ファイル システムの完全なサポートを提供します。 組み込みの CSI ドライバーを使用すると、AZURE Container Instances や Azure Kubernetes Service (AKS) などの VM ベースのプラットフォームやコンテナー プラットフォームから簡単に使用できます。 シナリオの例としては、共有ファイル、データベース、ホーム ディレクトリ、従来のアプリケーション、ERP、CMS、高度な管理を必要としない NAS 移行、スケールアウト ファイル ストレージを必要とするカスタム アプリケーションなどがあります。 |
Managed Lustre は、中から大規模の HPC ワークロードに最適なフル マネージドの並列ファイル システムです。 使い慣れた Lustre 並列ファイル システム機能、動作、パフォーマンスを提供することで、アプリケーションの互換性を損なうことなく、クラウド内の HPC アプリケーションを有効にします。 このサービスは、長期的なアプリケーション投資をセキュリティで保護するのに役立ちます。 |
高度な管理機能を備え、NetApp を利用したクラウド内のフル マネージド ファイル サービス。 Azure NetApp Files は、ランダム アクセスを必要とするワークロードに適しています。 広範なプロトコルサポートと改善されたデータ保護を提供します。 シナリオの例としては、豊富な管理機能を必要とするオンプレミスのエンタープライズ NAS 移行、SAP HANA などの待機時間の影響を受けやすいワークロード、待機時間の影響を受けやすい、IOPS を集中的に使用する高パフォーマンス コンピューティング、同時マルチプロトコル アクセスを必要とするワークロードなどがあります。 |
| 使用可能なプロトコル | NFS 3.0 REST Azure Data Lake Storage |
SMB NFS 4.1 (どちらのプロトコル間の相互運用性もありません) |
Lustre | NFS 3.0 および 4.1 SMB |
| 主な機能 | Azure HPC Cache と統合され、待ち時間の短いワークロードを実現します。 ライフサイクル管理、不変 BLOB、データ フェールオーバー、メタデータ インデックスなどの統合管理。 |
高可用性を確保するためのゾーン冗長性。 一貫した 1 桁ミリ秒の待機時間。 容量に応じてスケーリングできる予測可能なパフォーマンスとコスト。 |
最大 2.5 PB の高いストレージ容量。 待機時間が短く、約 2 ミリ秒。 新しいクラスターを数分で作成します。 AKS でコンテナー化されたワークロードをサポートします。 |
待機時間が非常に短く、ミリ秒未満です。 SnapMirror Cloud などの豊富な NetApp ONTAP 管理機能。 一貫したハイブリッド クラウド エクスペリエンス。 |
| パフォーマンス (ボリュームごと) | 20,000 IOPS まで。 最大で 100 GiBps のスループット。 | 100,000 IOPS まで。 最大 80 GiBps のスループット。 | 100,000 IOPS まで。 スループットが最大で500 GiBpsになります。 | 460,000 IOPS まで。 36 GiBps までのトランスファーレート。 |
| 規模 | 1 つのボリュームに対して最大 2 PiB。 1 つのファイルに対して約 4.75 TiB。 最小容量要件はありません。 |
1 つのボリュームに対して最大 100 TiB。 1 つのファイルに対して 4 TiB まで。 最小容量は 100 GiB です。 |
1 つのボリュームに対して最大 2.5 PiB。 1 つのファイルに対して 32 PB まで。 4 TiB の最小容量。 |
1 つのボリュームに対して最大 100 TiB。 1 つのファイルに対して 16 TiB まで。 一貫したハイブリッド クラウド エクスペリエンス。 |
| 価格設定 | Blob Storage の価格 | Azure Files の価格 | Managed Lustre の価格 | Azure NetApp Files の価格 |
財務設計に関する推奨事項
Standard または Premium Blob Storage を使用して、高スループットで待機時間の短いストレージを実現します。 次の利点があります。
これは、エクサバイト規模、高スループット、低待機時間のアクセス、使い慣れたファイル システム、および REST、HDFS、NFS などのマルチプロトコル アクセスを提供します。
コスト効率が高くなります。
Blob Storage をファイルシステムとして使用するために、BlobFuseを使用してマウントできます。 これにより、複数のノードが読み取り専用のシナリオで同じコンテナーを簡単にマウントできるようになります。
BLOB サービス エンドポイントで NFS 3.0 をサポートし、高スループットで読み取り負荷の高いワークロードを実現します。
データをよりクールなストレージ層に移動することで、コストを最適化できます。 この最適化は、最終更新またはアクセス時間に基づくライフサイクル管理と、カスタマイズ可能なポリシーを使用したインテリジェントな階層化によって可能になります。
ReadWriteMany (一意) または書き込み 1 回/読み取り 1 回のアプリケーションには、Azure NetApp Files を使用します。 次の利点があります。
NFSv3、NFSv4.1、SMB3 などの幅広いファイル プロトコル
複数のレベル (Ultra、Premium、Standard) を使用するオンプレミスのパフォーマンスと同等のパフォーマンス
数分でデプロイでき、さまざまなレベルと柔軟性が提供されます
柔軟な容量プールの種類とパフォーマンス。ボリュームあたりの QoS は、プールの層とボリューム クォータに基づいて自動的に割り当てられます
製造に関する考慮事項
必要なデータが適切なタイミングで HPC クラスター マシンに到達するようにすることが重要です。 また、これらの個々のマシンからの結果が迅速に保存され、詳細な分析に使用できることを確認する必要があります。
ワークロード トラフィックの分散
HPC 環境で生成および処理されるトラフィックの種類を検討します。 この手順は、複数の種類のワークロードを実行し、他の目的でストレージを使用することを計画している場合に特に重要です。 次の種類のトラフィックを考慮して記録します。
- 単一ストリームと複数のストリーム
- 書き込みトラフィックに対する読み取りトラフィックの比率
- ファイルの平均サイズと数
- ランダムアクセスパターンとシーケンシャルアクセスパターン
データのローカリティ
このカテゴリは、データの場所を考慮します。 ローカリティ認識は、データ移動戦略としてコピー、キャッシュ、または同期を使用できるかどうかを判断するのに役立ちます。 事前に次のロケール項目を確認してください。
- ソース データがオンプレミス、Azure、またはその両方にある場合
- 結果データがオンプレミス、Azure、またはその両方の場合
- Azure の HPC ワークロードをソース データ変更タイムラインと調整する必要がある場合
- 機密または医療保険の移植性と説明責任に関する法律のデータが含まれている場合
パフォーマンス要件
ストレージ ソリューションのパフォーマンス要件は、通常、次のようにまとめられています。
- 単一ストリームのスループット
- マルチストリーム スループット
- 予想される最大 IOPS
- 平均待機時間
すべての要素がパフォーマンスに影響するため、これらの数値は、特定のソリューションの予想される結果のガイドとして機能します。 たとえば、HPC ワークロードには、ワークフローの一部として広範なファイルの作成と削除が含まれる場合があります。 これらの操作は、全体的なスループットに影響する可能性があります。
アクセス方法
必要なクライアント アクセス プロトコルを考慮し、必要なプロトコルの機能を明確にします。 NFS と SMB にはさまざまなバージョンがあります。
次の要件を考慮してください。
- NFS/SMB バージョンが必要かどうか
- アクセス制御リストや暗号化など、予想されるプロトコル機能
- 並列ファイル システム ソリューション
合計容量要件
次に、Azure のストレージ容量について検討します。 ソリューションの全体的なコストを通知するのに役立ちます。 大量のデータを長期間保存する予定の場合は、ストレージ ソリューションの一部として階層化を検討することをお考えになる場合があります。 階層化では、低コストのストレージ オプションと、ホット 層のコストが高く、パフォーマンスが高いストレージが組み合わせられます。 次の容量要件を検討してください。
- 必要な合計容量
- 必要なホット層の合計容量
- 必要なウォーム層の合計容量
- 必要なコールド 層の合計容量
認証と承認の方法
LDAP サーバーや Windows Server Active Directory の使用など、認証と承認の要件については、アーキテクチャに必要なサポート システムを必ず含めるようにしてください。 Windows Server Active Directory ユーザーへの UID や GID マッピングなどの機能をサポートする必要がある場合は、ストレージ ソリューションでその機能がサポートされていることを確認します。
次のネットワーク要件を考慮してください。
- ローカル (ファイル サーバー上の UID または GID のみ)
- ディレクトリ (LDAP または Windows Server Active Directory)
- UID または GID が Windows Server Active Directory ユーザーにマッピングされているかどうか
独自ロールの並列ファイル システム
NFS と同様に、マルチノード BeeGFS または Lustre ファイル システムを作成できます。 これらのシステムのパフォーマンスは、主に選択した VM の種類によって異なります。 Azure Marketplaceで見つかるイメージを使用して、BeeGFSやDDNのLustre実装であるWhamcloud を利用できます。 BeeGFS や DDN などのベンダーの Microsoft 以外のイメージを使用する場合は、サポート サービスを購入できます。 マシンとディスクのコストを除き、追加料金なしで、GPL ライセンスで BeeGFS と Lustre を使用できます。 これらのツールは、スクラッチ用のエフェメラル ローカル ディスクまたは永続的ストレージ用の Azure Premium SSD または Azure Ultra Disk Storage
Cray ClusterStor
大規模な Lustre 環境を持つ大規模なコンピューティング クラスターの ベアメタル パフォーマンスをレプリケートすることは、大規模なワークロードにとって課題です。 その他の課題としては、テラバイト毎秒(TBps)の観点から高いスループットを実現し、ペタバイト単位のストレージを処理する可能性があります。 Azure ソリューションで Cray ClusterStor を使用して、これらのワークロードを実行できるようになりました。 このアプローチは、関連する Azure データセンターに配置された純粋なベアメタル Lustre デプロイです。 BeeGFS や Lustre などの並列ファイル システムは、アーキテクチャにより最高のパフォーマンスを提供します。 しかし、そのアーキテクチャとこれらのテクノロジの使用は、高い管理価格を持っています。
次の手順
次の記事では、クラウド導入の過程のさまざまなポイントで役立つガイダンスを提供します。
- Azure ハイ パフォーマンス コンピューティング (HPC) シナリオの概要
- Azure HPC の
ID とアクセス管理 - エネルギー における Azure HPC のネットワーク トポロジと接続性
- エネルギー産業における HPC のリソース組織
- Azure VM での大規模 HPC アプリケーション ワークロードのコンピューティング
- Azure ハイ パフォーマンス コンピューティング (HPC) ランディング ゾーン アクセラレータ