アーキテクチャ: DDN EXAScaler を使用した Google Cloud 内の Lustre ファイルシステム

Last reviewed 2023-11-15 UTC

このドキュメントでは、ハイパフォーマンスコンピューティング（HPC）ワークロード用に Lustre ファイルシステムの設計とサイズ設定を行う際に活用できるアーキテクチャのガイダンスを提供します。また、DDN EXAScaler を使用して Google Cloud に Lustre ファイルシステムをデプロイするプロセスの概要についても説明します。

Lustre は、密結合な HPC ワークロードに高スループットかつ低レイテンシのストレージを提供するオープンソースの並列ファイルシステムです。Lustre ファイルシステムは、数万もの HPC クライアントとペタバイト規模のストレージに対応するようにスケーリングできます。EXAScaler Cloud は、Lustre のエンタープライズバージョンであり、Google パートナーの DDN が提供しています。EXAScaler Cloud をハイブリッドクラウドアーキテクチャにデプロイして、オンプレミスの HPC 処理能力を増強できます。EXAScaler Cloud は、オンプレミス EXAScaler デプロイから長期的なアセットを保存するためのリポジトリとしても機能します。

このドキュメントのガイダンスは、クラウド内の HPC ワークロードのストレージを設計、プロビジョニング、管理するエンタープライズアーキテクトと技術担当者を対象としています。このドキュメントは、並列ファイルシステムのコンセプトを理解されていることを前提としています。また、Lustre などの並列ファイルシステムが適している HPC ユースケースについて理解されている必要があります。詳細については、HPC ワークロードの並列ファイルシステムをご覧ください。

Lustre ファイルシステムの概要

次の図は、Lustre ファイルシステムのアーキテクチャを示しています。

Lustre ファイルシステムのアーキテクチャ

図に示すように、このアーキテクチャには次のコンポーネントが含まれています。

管理サーバー（MGS）と管理ターゲット（MGT）: MGS は、1 つ以上の Lustre ファイルシステムに関する構成情報を保存し、管理します。この図では、MGS が 1 つの Lustre ファイルシステムを管理しています。 MGS は、管理するすべてのファイルシステムの他の Lustre コンポーネントに構成情報を提供します。MGS は、MGT と呼ばれるストレージデバイスにファイルシステム構成ログを記録します。
メタデータサーバー（MDS）とメタデータターゲット（MDT）: MDS ノードは、Lustre ファイルシステムの名前空間へのクライアントアクセスを管理します。この名前空間には、ディレクトリ階層、ファイル作成時間、アクセス権限など、ファイルシステムのすべてのメタデータが含まれます。メタデータは、MDT と呼ばれるストレージデバイスに保存されます。Lustre ファイルシステムには、少なくとも 1 つの MDS と 1 つの関連する MDT があります。何千ものクライアントが数百万もの小さなファイルを作成してアクセスするなど、メタデータを多用するワークロードのパフォーマンスを向上させるには、さらに MDS ノードをファイルシステムに追加します。
オブジェクトストレージサーバー（OSS）とオブジェクトストレージターゲット（OST）: OSS ノードは、Lustre ファイルシステムに保存されているファイルデータへのクライアントアクセスを管理します。各ファイルは、1 つ以上の Lustre オブジェクトとして保存されます。オブジェクトは単一のストレージデバイス（OST と呼ばれる）に保存されるか、複数の OSS ノードと OST にストライプで保存されます。Lustre ファイルシステムには、少なくとも 1 つの OSS と 1 つの関連する OST があります。OSS ノードと OST を追加することで、ファイルシステムのストレージ容量とパフォーマンスをスケーリングできます。ファイルシステムの合計ストレージ容量は、ファイルシステム内のすべての OSS ノードにアタッチされている OST のストレージ容量の合計です。
クライアント: Lustre クライアントは、マウントポイントを介して Lustre ファイルシステムにアクセスする仮想マシン（VM）などのコンピューティングノードです。マウントポイントは、ファイルシステム全体に統合された名前空間を提供します。Lustre ファイルシステムは、10,000 を超えるクライアントによる同時アクセスに対応するようにスケーリングできます。Lustre クライアントは、Lustre ファイルシステム内のすべての MDS ノードと OSS ノードに同時にアクセスします。この並列アクセスにより、ファイルシステムのパフォーマンスを最大化できます。また、並列アクセスにより、ストレージのホットスポット（他の場所よりも頻繁にアクセスされるストレージ内の場所）を低減することもできます。ホットスポットは、非並列ファイルシステムで一般的であり、クライアント間でパフォーマンスの不均衡を引き起こす可能性があります。

Lustre ファイルシステムにアクセスするために、クライアントは MDS から必要なディレクトリとファイルメタデータを取得し、1 つ以上の OSS ノードと通信してデータの読み取りと書き込みを行います。Lustre は POSIX セマンティクスに厳密に準拠し、すべてのクライアントがファイルシステムへの完全な同時アクセスを可能にします。

Lustre ファイルシステムとその仕組みについて詳しくは、Lustre のドキュメントをご覧ください。

Google Cloud における Lustre のアーキテクチャ

次の図は、Google Cloud に Lustre ファイルシステムをデプロイするためのアーキテクチャを示しています。

Google Cloud の Lustre ファイルシステムのアーキテクチャ

この図に示すアーキテクチャには、次のリソースが含まれています。すべてのリソースは、単一の Google Cloud プロジェクトにデプロイされます。コンピューティングリソースとストレージリソースは、単一のゾーン内でプロビジョニングされます。

Compute Engine VM は、MGS、MDS、OSS のノードと Lustre クライアントをホストします。Google Kubernetes Engine クラスタに Lustre クライアントをデプロイして、Compute Engine VM にファイルシステムをデプロイすることもできます。
このアーキテクチャには、次のネットワーキングリソースが含まれています。
- すべての VM に使用される単一の Virtual Private Cloud（VPC）サブネット。
- プライベート VM からインターネットへのアウトバウンドトラフィック用の Cloud NAT ゲートウェイ（オプション）と Cloud Router（オプション）。
- トポロジ内のすべての VM への SSH 上り（内向き）接続を許可するファイアウォールルール（オプション）。
- インターネットから MGS 上の DDN EXAScaler ウェブコンソールへの HTTP アクセスを許可するファイアウォールルール（オプション）。
- すべての VM 間の TCP 接続を許可するファイアウォール。
Persistent Disk は、MGS ノード、MDS ノード、OSS ノードのストレージ容量を提供します。永続ストレージが不要な場合は、VM にアタッチされるローカルソリッドステートドライブ（SSD）ディスクを使用してスクラッチファイルシステムを構築できます。

Google は、Lustre の永続的なファイルシステムとスクラッチファイルシステムの両方のパフォーマンスを示す IO500 エントリを送信しています。HPC ストレージシステムの IO500 ランキングで 10 Tbps 以上の Lustre ベースのスクラッチファイルシステムについて説明する Google Cloud に送信されたサンプルを確認します。

デザインガイドライン

次のガイドラインを使用して、HPC ワークロードの要件を満たす Lustre ファイルシステムを設計します。このセクションのガイドラインはすべてを網羅したものではありません。これらは、HPC ワークロードのストレージ要件の評価、利用可能なストレージオプションの評価、Lustre ファイルシステムのサイズ設定に役立つフレームワークを提供します。

ワークロードの要件

HPC ワークロードのストレージ要件を特定します。要件を可能な限り詳細に定義し、将来の要件を検討します。ワークロードの要件を特定するには、出発点として次の質問を使用します。

スループットと 1 秒あたりの I/O オペレーション（IOPS）の要件はどのような内容ですか？
必要なストレージ容量はどの程度ですか？
最も重要な設計目標は、スループット、IOPS、ストレージ容量のどれですか？
永続ストレージ、スクラッチストレージ、またはその両方が必要ですか？

ストレージオプション

最も費用対効果の高いストレージオプションとして、次のタイプの永続ディスクから選択できます。

ストレージ容量が主な設計目標である場合は、標準永続ディスク（pd-standard）が最も費用対効果の高いオプションです。ハードディスクドライブ（HDD）を使用して、効率的で信頼性の高いブロックストレージを提供します。
IOPS の最大化が目標の場合は、SSD 永続ディスク（pd-ssd）が最も費用対効果の高いオプションです。SSD を使用して高速で信頼性の高いブロックストレージを提供します。
スループットを最大化する場合は、バランス永続ディスク（pd-balanced）が最も費用対効果の高いオプションです。SSD を使用して費用対効果に優れ、信頼性の高いブロックストレージを提供します。

エクストリーム永続ディスク（pd-extreme）は、他のディスクタイプよりも高いパフォーマンスを実現できるため、必要な IOPS を選択できます。ただし、pd-extreme は他のディスクタイプと比較して費用が増大します。

永続ディスクのパフォーマンス機能の詳細については、ブロックストレージのパフォーマンスをご覧ください。

スクラッチストレージには、エフェメラルローカル SSD を使用できます。ローカル SSD は、VM をホストするサーバーに物理的にアタッチされます。そのため、ローカル SSD は永続ディスクよりもスループットが高く、レイテンシは低くなります。ただし、ローカル SSD に格納されたデータが保持されるのは、VM が停止されるか削除されるまでの間に限られます。

オブジェクトストレージサーバー

OSS ノードのインフラストラクチャを設計する際は、次のことをおすすめします。

ストレージには、ストレージ容量、スループット、IOPS の要件に基づいて適切な永続ディスクタイプを選択します。
- 次の要件があるワークロードには pd-standard を使用します。
  - ワークロードで大容量ストレージ（10 TB 超など）が必要であるか、高い読み取りスループットと大容量ストレージの両方が必要である。
  - I/O レイテンシが重要でない。
  - 低い書き込みスループットを許容できる。
- 次のいずれかの要件があるワークロードには pd-balanced を使用します。
  - 低容量で高スループット。
  - SSD ベースのディスクによる低レイテンシ。
- 高 IOPS が必要なワークロード（小規模な I/O リクエストまたは小さなファイル）には pd-ssd を使用します。
必要な IOPS を達成するのに十分なストレージ容量をプロビジョニングします。各ディスクタイプで実現される読み取りと書き込みの IOPS を考慮してください。
VM には、N2 または N2D マシンファミリーのマシンタイプを使用します。これらのマシンタイプは、予測可能で費用対効果の高いパフォーマンスを実現します。
必要な永続ディスクスループットを達成するのに十分な vCPU を割り当てます。VM あたりの永続ディスクの最大スループットは 1.2 GBps です。このスループットは 16 個の vCPU で実現できます。16 個の vCPU を備えたマシンタイプから始めましょう。パフォーマンスをモニタリングし、IOPS をスケーリングする必要がある場合は、追加の vCPU を割り当てます。

メタデータサーバー

MDS ノードでは、メタデータを処理するために大容量のストレージは必要ありませんが、高 IOPS をサポートするストレージが必要です。MDS ノードのインフラストラクチャを設計する際は、次のことをおすすめします。

ストレージには pd-ssd を使用します。このタイプの永続ディスクでは、低ストレージ容量でも高い IOPS（1 GB あたり 30 IOPS）を実現できます。
必要な IOPS を達成するのに十分なストレージ容量をプロビジョニングします。
VM には、N2 または N2D マシンファミリーのマシンタイプを使用します。これらのマシンタイプは、予測可能で費用対効果の高いパフォーマンスを実現します。
必要な IOP を達成するのに十分な vCPU を割り当てます。
- メタデータ量が少ないワークロードの場合は、16 個の vCPU を使用します。
- メタデータ量が中程度のワークロードの場合は、32 個の vCPU を使用します。
- メタデータ量の多いワークロードの場合は、64 個の vCPU を使用します。パフォーマンスをモニタリングし、必要に応じて追加の vCPU を割り当てます。

管理サーバー

MGS は最小限のコンピューティングリソースを必要としており、ストレージ使用量の多いサービスではありません。VM 用に小さなマシンタイプ（例: n2-standard-2）とストレージ用に 128 GB の pd-ssd ディスクで始めて、パフォーマンスをモニタリングします。レスポンスが遅い場合は、より多くの vCPU を割り当て、ディスクサイズを引き上げます。

可用性と耐久性

永続ストレージが必要な場合、pd-standard 永続ディスクタイプおよび pd-balanced 永続ディスクタイプがゾーン内で可用性と耐久性に優れたストレージを提供します。クロスゾーンまたはクロスリージョンでの永続性を実現するには、Google Cloud CLI または Storage Transfer Service を使用して、データを低コスト Cloud Storage にコピーできます。Cloud Storage にデータを保存する費用を削減するために、アクセス頻度の低いデータは Nearline Storage クラスまたは Coldline Storage クラスのバケットに保存できます。

スクラッチデプロイにエフェメラルストレージのみが必要な場合は、OSS ノードと MDS ノードのデータディスクとしてローカル SSD を使用します。このように設計すると、最小限の OSS VM で高いパフォーマンスを実現できます。また、こうした設計で、他のオプションと比較して最適な費用対パフォーマンス比を実現できます。

OSS VM のサイズ設定例

Lustre ファイルシステムのサイズ設定とプロビジョニングで推奨される戦略は、全体的なスループット要件を満たすのに十分な OSS VM をプロビジョニングすることです。次に、必要なストレージ容量に達するまで OST ディスクのストレージ容量を増やします。このセクションで使用するワークロードの例では、次の手順でこの戦略を実装する方法を示します。

ワークロードの要件を決定します。
永続ディスクタイプを選択します。
OSS VM の数を計算します。
VM あたりのディスクサイズを計算します。
VM あたりの vCPU の数を決定します。

ワークロードの要件を決定する

この例では、ワークロードに 80 TB の永続ストレージ容量、30 GBps の読み取りスループットが必要です。

永続ディスクタイプを選択する

ストレージオプションセクションで説明したように、ストレージ容量が主な設計目標である場合、pd-standard が最も費用対効果の高いオプションです。pd-balanced は、スループットを最大化するための費用対効果が最も高いオプションです。最大スループットはディスクタイプごとに異なり、スループットはディスクサイズでスケーリングされます。

このワークロードに使用できる永続ディスクタイプごとに、読み取りスループットのターゲットである 30 GBps にスケーリングするために必要なストレージ容量を計算します。

ディスクタイプ	読み取りスループット/TB	ターゲットのスループットを達成するために必要なストレージ容量
`pd-standard`	0.12 GBps	30 ÷ 0.12 = 250 TB
`pd-balanced`	0.28 GBps	30 ÷ 0.28 = 107 TB

pd-standard を使用して読み取りスループットのターゲットである 30 Gbps を実現するには、250 TB のストレージ容量をプロビジョニングする必要があります。この量は、必要な容量（80 TB）の 3 倍を超えています。したがって、この例のワークロードの場合、pd-balanced はパフォーマンス要件を満たす費用対効果の高いストレージを提供します。

OSS VM の数を計算する

Compute Engine VM あたりの最大読み取りスループットは 1.2 GBps です。読み取りスループットのターゲットである 30 GBps を達成するには、次のように VM あたりの最大スループットでターゲットの読み取りスループットを除算します。

   30 GBps / 1.2 GBps = 25

ターゲットの読み取りスループットを達成するには、25 台の OSS VM が必要です。

VM あたりのディスクサイズを計算する

VM あたりのディスクサイズを計算するには、次のようにターゲットスループット（30 GBps）を達成するために必要な容量（107 TB）を VM の数で除算します。

   107 TB / 25 VMs = 4.3

VM ごとに 4.3 TB の pd-balanced の容量が必要です。

VM あたりの vCPU の数を決定する

VM の読み取りスループットは、VM に割り当てられた vCPU の数に比例します。読み取りスループットのピークは、16 個（以上）の vCPU で 1.2 Gbps です。16 個以上の vCPU を備えたマシンタイプが必要です。そのため、N2 または N2D のマシンファミリーのマシンタイプ（n2-standard-32 など）を選択してください。

構成の概要

サンプルワークロードには次の要件があります。

80 TB の永続ストレージ容量
30 Gbps の読み取りスループット

このワークロードの要件を満たすには、次のコンピューティングリソースとストレージリソースが必要です。

OSS VM の数: 25
VM マシンファミリー: N2 または N2D
VM あたりの vCPU 数: 16 以上
永続ディスクタイプ: pd-balanced
VM あたりのディスクサイズ: 4.3 TB

スクラッチファイルシステムの構成例

次の構成は、Google Cloud の IO500 への送信に基づいています。これは、Lustre を使用して Google Cloud にデプロイされた、非常に大規模なスクラッチファイルシステムのパフォーマンスを示しています。

構成パラメータ	MDS	OSS	クライアント
VM 数	50	200	1,000
マシンタイプ	`n2-standard-80`	`n2-standard-64`	`c2-standard-16`
VM あたりの vCPU 数	80 vCPU	64 vCPU	16 vCPU
VM あたりの RAM	320 GB	256 GB	64 GB
OS	CentOS 8	CentOS 8	CentOS 8
ネットワーク帯域幅	100 Gbps	75 Gbps	32 Gbps
ローカル SSD ストレージ	9 TB NVMe （ディスク 24 個）	9 TB NVMe （ディスク 24 個）	なし

上記の構成では、次のパフォーマンスが得られました。

パフォーマンス指標	結果
書き込みスループット	700 GBps（5.6 Tbps）
読み取りスループット	1,270 GBps（10.16 Tbps）
ファイルの `stat()` 操作	1 秒あたり 190 万回
小容量ファイルの読み取り（3,901 バイト）	1 秒あたり 150 万回

導入について

このセクションでは、EXAScaler Cloud ファイルシステムを Google Cloud にデプロイするために使用できる方法の概要を説明します。このセクションでは、クライアント VM をデプロイする手順についても概説します。

EXAScaler Cloud ファイルシステムのデプロイ

Google Cloud に EXAScaler Cloud ファイルシステムをデプロイするには、次の方法を選択できます。

DDN 提供の Google Cloud Marketplace ソリューションを使用してデプロイする。
Cloud HPC Toolkit を使用してデプロイする。このツールキットには、DDN 提供の Terraform モジュールを使用して高 I/O ファイルシステムをデプロイするブループリントが含まれています。

いずれの方法でも、デプロイ時にファイルシステムをカスタマイズできます。たとえば、OSS VM の数、VM のマシンタイプ、永続ディスクのタイプ、ストレージ容量を指定できます。

方法を選択する際には、次の相違点を考慮してください。

デプロイ後の変更: Cloud HPC Toolkit を使用すると、デプロイ後にファイルシステムを効率的に変更できます。たとえば、ストレージ容量を追加するには、Cloud HPC Toolkit ブループリントを更新し、生成された Terraform 構成を再度適用することで、OSS ノードの数を増やすことができます。ブループリントで指定できるパラメータのリストについては、Terraform モジュールの README の Inputs セクションをご覧ください。Cloud Marketplace ソリューションを使用してデプロイされたファイルシステムを変更するには、Google Cloud コンソール、gcloud CLI、または API を使用して、各コンピューティングリソースとストレージリソースを個別に変更する必要があります。
サポート: Cloud Marketplace ソリューションでは Deployment Manager を使用しますが、これは VPC Service Controls ではサポートされていません。この制限の詳細については、VPC Service Controls でサポートされているプロダクトと制限事項をご覧ください。

クライアントのデプロイ

EXAScaler Cloud ファイルシステムのデプロイで説明されているいずれかの方法を使用して、クライアント VM をデプロイできます。ただし、クライアント VM はファイルシステムとは別にプロビジョニングして管理することをおすすめします。クライアントをデプロイする方法としては、HPC ワークロード用に最適化された Google 提供の HPC VM イメージを使用することをおすすめします。

HPC VM イメージを使用して Lustre クライアントをデプロイするプロセスの概要は次のとおりです。

HPC VM イメージを使用して VM を作成します。
VM に Lustre クライアントパッケージをインストールします。
必要に応じて VM をカスタマイズします。
VM からカスタムイメージを作成します。
作成したカスタムイメージを使用して、Lustre クライアント VM をプロビジョニングします。クライアント VM のプロビジョニングと管理を自動化するには、Compute Engine マネージドインスタンスグループまたは Slurm ワークロードマネージャーなどのサードパーティツールを使用します。HPC ワークロード用の Compute Engine VM のクラスタのプロビジョニングと管理の詳細については、クラスタを利用して大規模なテクニカルコンピューティングをクラウドで実行するをご覧ください。
クライアント VM に Lustre ファイルシステムをマウントします。

データ転送オプション

Google Cloud に Lustre ファイルシステムをデプロイしたら、データをファイルシステムに移動する必要があります。次の表に、Lustre ファイルシステムにデータを移動する際に使用できる方法を示します。移動する必要があるデータの量とソースデータの場所（オンプレミスまたは Cloud Storage 内）に応じて方法を選択します。

データソース	データサイズ	推奨されるデータ転送方法
オンプレミス	小規模（例: 1 TB 未満）	gsutil ツールを使用して、Cloud Storage 内のデータをステージングします。次に、Storage Transfer Service または gcloud CLI を使用して、データを Lustre ファイルシステムにダウンロードします。
オンプレミス	大	Storage Transfer Service を使用して、データを Lustre ファイルシステムに移動します。POSIX ファイルシステム間でデータを転送するの手順に沿って操作します。この方法では、Cloud Storage の中継バケットを使用します。転送ジョブが完了すると、Storage Transfer Service は中継バケット内のデータを削除します。
Cloud Storage	大規模または小規模	Storage Transfer Service または gcloud CLI を使用して、データを Cloud Storage から Lustre ファイルシステムにダウンロードします。

次のステップ

Lustre の詳細を確認する。
DDN EXAScaler Cloud と DDN と Google のパートナーシップの詳細を確認する。
HPC ストレージシステムの IO500 ランキングで 10 Tbps 以上の Lustre ベースのスクラッチファイルシステムについて説明する Google Cloud に送信されたサンプルを確認する。
このドキュメントの EXAScaler Cloud ファイルシステムのデプロイの説明に従って、DDN EXAScaler を Google Cloud にデプロイする。

協力者

著者: Kumar Dhanagopal | クロスプロダクトソリューションデベロッパー

その他の関係者:

Carlos Boneti | シニアスタッフソフトウェアエンジニア
Dean Hildebrand | テクニカルディレクター
Sean Derrington | グループアウトバウンドプロダクトマネージャー