0. 概要
HPC/GPUクラスタと共に利用するファイル共有ストレージは、その構築手法を決定する際に以下の評価項目を考慮する必要があります。
- 計算/GPUノードの複数ノード同時アクセス時性能
- ランニングコスト
- ストレージに格納するデータの可用性
- ファイル共有ストレージサービスの可用性
- システム構築・運用のしやすさ
本テクニカルTipsは、HPC/GPUクラスタ向けにNFSでサービスするファイル共有ストレージを構築することを念頭に、いくつかのファイル共有ストレージ構築手法を紹介し、上記評価基準を元にどの手法を採用すればよいか、その考慮点を解説します。
NFSでサービスするファイル共有ストレージを構築する際の最初の考慮点は、マネージドのNFSサービスである ファイル・ストレージ を使用する方法と、 ベア・メタル・インスタンス とストレージサービスで構築する方法（以降”ベア・メタル・インスタンスNFSサーバ”と呼称）の、どちらを採用するかです。
ここで ファイル・ストレージ を採用する場合は、性能要件に合わせて マウント・ターゲット に標準タイプ（以降”標準FSS”と呼称）とHigh Performanceタイプ（以降”高性能FSS”と呼称）（※1）のどちらを使用するかを考慮します。
※1）High Performanceタイプの マウント・ターゲット は、その性能違いで3種類存在しますが、本テクニカルTipsでは読み取りスループット設定が80 Gbpsで性能が最も高い HPMT-80 を前提に解説します。
High Performanceタイプの マウント・ターゲット 詳細は、 ここ を参照して下さい。
またベア・メタル・インスタンスNFSサーバを採用する場合は、以下2種類のどちらにするかを考慮します。
- ストレージに ブロック・ボリューム を使用しこれをベア・メタル・インスタンスにアタッチする方法（以降”ブロック・ボリュームNFSサーバ”と呼称）
- ベア・メタル・インスタンス にNVMe SSDドライブを搭載するDenceIOシェイプを使用する方法（以降”DenceIO NFSサーバ”と呼称）
以上より、本テクニカルTipsで解説するファイル共有ストレージは、以下4種類です。
| 構築手法 | 使用するサービス | NFSサーバ | ストレージ | 保存対象 データ （※2） |
ターゲット スループット レンジ |
|---|---|---|---|---|---|
| 標準FSS | ファイル・ストレージ | 標準 マウント・ターゲット |
ファイル・システム | 長期保存 データ |
120 MiB/s （※3） |
| 高性能FSS | ファイル・ストレージ | High Performance マウント・ターゲット |
ファイル・システム | 長期保存 データ |
10 GiB/s （※3） |
| ブロック・ボリューム NFSサーバ |
ベア・メタル・インスタンス + ブロック・ボリューム |
BM.Optimized3.36 | ブロック・ボリューム | 中期保存 データ |
5 GiB/s （※4） |
| DenceIO NFSサーバ |
DenceIOタイプ ベア・メタル・インスタンス |
BM.DenseIO.E5.128 | NVMe SSD ローカルディスク |
短期保存 データ |
10 GiB/s （※4） |
※2）対象の構築手法が提供するデータ可用性レベルに応じて分類しています。（データ可用性が低いほど短期保存データ用ファイル共有ストレージに分類）
※3）マウント・ターゲット の最大スループット値を元に記載しています。
※4）IOR の測定値を元に記載しています。
以降では、これら4種類のNFSファイル共有ストレージ構築手法について、まず初めに2種類の ベア・メタル・インスタンス NFSサーバ（ブロック・ボリュームNFSサーバとDenceIO NFSサーバ）の構成を解説し、次に前述の評価項目をもとに4種類の構築手法を比較します。
なお各構築手法は、 OCI HPCチュートリアル集 の 1-3. ファイル共有ストレージ カテゴリの以下チュートリアルを参照してください。
| 構築手法 | チュートリアル |
|---|---|
| 標準FSS | ファイル・ストレージでファイル共有ストレージを構築する |
| 高性能FSS | ファイル・ストレージでファイル共有ストレージを構築する |
| ブロック・ボリュームNFSサーバ | ブロック・ボリュームでファイル共有ストレージを構築する |
| DenceIO NFSサーバ | 短期保存データ用高速ファイル共有ストレージを構築する |
1. ベア・メタル・インスタンスNFSサーバ構成
1-0. 概要
本章は、本テクニカルTipsが前提とする2種類のベア・メタル・インスタンスNFSサーバ（ブロック・ボリュームNFSサーバとDenceIO NFSサーバ）の構成を解説します。
1-1. ブロック・ボリュームNFSサーバ構成
NFSサーバのインスタンスは、 BM.Optimized3.36 を使用します。
この理由は、このシェイプが50 GbpsのTCP/IP接続用ポートを2個搭載し、それぞれをiSCSI接続の ブロック・ボリューム アクセス用途とNFSクライアントへのNFSサービス用途に割当ててこれらを同時に使用することで、NFSサービスに50 Gbpsの帯域をフルに使用することが可能となるためです。
またストレージに使用する ブロック・ボリューム は、 パフォーマンス・レベル を バランス で作成します。
パフォーマンス・レベル が バランス の ブロック・ボリューム は、ボリューム・サイズの増加とともにその性能が向上し1 TBで上限に達するため、1 TB以上のボリュームを基本単位として複数ボリュームをLinuxの論理ボリューム機能で各ボリュームにストライピングを掛けつつ1ファイルシステムに構成し、コストパフォーマンスを最大化します。
この際、NFSファイルシステム性能としては15ボリューム程度で性能が頭打ちとなることを考慮し、ボリューム15個をストライプ数15でファイルシステムを作成します。
総容量が15 TBより大きなストレージが必要な場合は、単一 ブロック・ボリューム サイズを1 TBより大きくすることで、性能を維持したままその総容量を増やすことが可能です。
例えば100 TBの総容量が必要な場合は、ボリューム・サイズを7 TBとすることで、7 TB x 15 = 105 TBの総容量を実現することが出来ます。
1-2. DenceIO NFSサーバ構成
NFSサーバのインスタンスは、 BM.DenseIO.E5.128 を使用します。
この理由は、このシェイプが100 GbpsのTCP/IP接続用ポートを1個と12台の6.8 TB NVMe SSDローカルディスクを搭載するため、このローカルディスクをストレージに使用することで、100 Gbpsのネットワーク帯域全てをNFSのサービスに使用することが可能となるためです。
これにより、 1-1. ブロック・ボリュームNFSサーバ構成 で解説するブロック・ボリュームNFSサーバに対して、NFSのサービスに使用できるネットワーク帯域が2倍となり、NVMe SSDローカルディスクの持つ高いI/O性能とあいまって、計算/GPUノードからの多数同時アクセス時に高いスループットとメタデータ性能を提供するファイル共有ストレージを構築することが可能になります。
また、ストレージに使用する12台のNVMe SSDローカルディスクは、データ保全性とパフォーマンスを両立するため、 Linux software RAID によるRAID10構成とします。
2. 各構築手法の比較
2.0 概要
本章は、4種類の構築手法を 0. 概要 に記載の5個の評価項目を以下3グループに分類して比較します。
- コストパフォーマンス
１．計算/GPUノードの複数ノード同時アクセス時性能
２．ランニングコスト - 可用性
３．ストレージに格納するデータの可用性
４．ファイル共有ストレージサービスの可用性 - 運用性
５．システム構築・運用のしやすさ
詳細は以降の章で解説しますが、コストパフォーマンスはベア・メタル・インスタンスNFSサーバを使用する構築手法が有利で、可用性と運用性は ファイル・ストレージ を使用する構築手法が有利となります。
2-1. コストパフォーマンスによる比較
本章は、コストパフォーマンスとして以下2項目の評価指標を採用します。
- 計算/GPUノードの複数ノード同時アクセス時性能
- ランニングコスト
ここで 評価指標 1. は、 IO500 でも採用されているファイルシステムベンチマークツールである IOR と mdtest を、それぞれスループットとメタデータ性能の評価指標として採用します。
以下の表は、4種類の構築手法を価格と性能の観点で比較しています。
| 構築手法 | 構成 | 月額定価 （2024年9月時点） |
IOR | mdtest |
|---|---|---|---|---|
| 標準FSS | マウント・ターゲット (Standard) ファイルシステム (15 TB) Total |
0 円 697,500 円 697,500 円 |
125 MiB/s （※5） |
- （※6） |
| 高性能FSS | マウント・ターゲット (HPMT-80) ファイルシステム (80 TB) Total |
3,360,000 円 0 円 3,360,000 円 |
10 GiB/s （※5） |
- （※6） |
| ブロック・ボリューム NFSサーバ |
ブロック・ボリューム (Balanced 15 TB) BM.Optimized3.36 Total |
98,813 円 302,659 円 401,472 円 |
5,266 MiB/s (Write) 5,707 MiB/s (Read) （※7） |
12,456 (create) 126,916 (stat) 13,231 (delete) （※7） |
| DenceIO NFSサーバ |
BM.DenseIO.E5.128 (6.8 TB NVMe SSD x 12) |
1,328,701 円 | 8,967 MiB/s (Write) 7,526 MiB/s (Read) （※8） |
83,406 (create) 255,682 (stat) 70,499 (delete) （※8） |
※5）IOR 測定値が無いため、 マウント・ターゲット の最大スループット値を記載しています。
※6）mdtest 測定値が無いため、記載していません。
※7）この測定値は、 OCI HPCチュートリアル集 の ブロック・ボリュームでファイル共有ストレージを構築する に従って構築したブロック・ボリュームNFSサーバに於いて、4ノードの VM.Standard2.24 からノード当たりMPIプロセス数8・総MPIプロセス数32の条件で測定し、3回計測した平均値です。
※8）この測定値は、 OCI HPCチュートリアル集 の 短期保存データ用高速ファイル共有ストレージを構築する に従って構築したDenceIO NFSサーバに於いて、8ノードの VM.Standard2.24 からノード当たりMPIプロセス数16・総MPIプロセス数128の条件で測定し、3回計測した平均値です。
この表から、以下のことがわかります。
- IOR スループットレンジが同程度の高性能FSSとDenceIO NFSサーバを比較すると、
- DenceIO NFSサーバのランニングコストは高性能FSSの約3分の1（※9）
- （高性能FSSの測定値が無い状況の中）DenceIO NFSサーバは圧倒的なメタデータ性能を示す
- パフォーマンスがエントリーレベルの標準FSSとブロック・ボリュームNFSサーバを比較すると、
- ブロック・ボリュームNFSサーバのランニングコストは標準FSSの6割程度（※10）（※11）
- ブロック・ボリュームNFSサーバのスループットは標準FSSの40倍以上
※9）この比較は、高性能FSSが80 TBに対してDenceIO NFSサーバが40.8 TBと、異なる総容量で比較しているため条件が異なりますが、高性能FSSの80 TBは使用するにあたっての最低容量で、DenceIO NFSサーバの40.8 TBは当該ベア・メタル・インスタンスに搭載するNVMe SSDドライブの仕様で決定される固定容量です。
※10）総容量15TBのブロック・ボリュームNFSサーバは、その価格の大部分を BM.Optimized3.36 が占めるため、総容量がこれより大きくなると、下表のように標準FSSに対する価格優位性が拡大します。
| 総容量（TB） | 標準FSS 月額定価 （2024年9月時点） |
ブロック・ボリューム NFSサーバ 月額定価 （2024年9月時点） |
|---|---|---|
| 15 | 697,500 円 | 401,472 円 |
| 100 | 4,650,000 円 | 961,409 円 |
| 500 | 23,250,000 円 | 3,596,409 円 |
| 1,000 | 46,500,000 円 | 6,587,500 円 |
※11）標準FSSは、従量制課金のため使用量が15 TBを下回るとそれに応じて金額が安くなりますが、 ブロック・ボリューム NFSサーバはその時点の使用量に関わらず定額課金されます。
以上より、性能レンジが高性能・エントリーレベル何れの場合も、コストパフォーマンスを評価指標に各構築手法を比較すると、ベア・メタル・インスタンスNFSサーバを使用する構築手法がファイル・ストレージを使用する構築手法より圧倒的にコストパフォーマンスが良いことがわかります。
2-2 可用性による比較
本章は、可用性として以下2項目の評価指標を採用します。
- ストレージに格納するデータの可用性
- ファイル共有ストレージサービスの可用性
ここで ファイル・ストレージ を使用する標準FSSと高性能FSSは、可用性を評価指標とした場合同じ評価となるため、これらをまとめて3種類の構築手法を比較します。
以下の表は、これら3種類の構築手法の可用性観点での利点・欠点を比較しています。
| 構築手法 | 利点 | 欠点 |
|---|---|---|
| 標準FSS 高性能FSS |
・HA化された マウント・ターゲット による高い サービス可能性 ・ファイル・システム が 可用性ドメイン 内に複数 レプリカを持つことによる高いデータ可用性 ・ ファイル・ストレージ が用意する豊富なバック アップ機能を使用することによる高いデータ可用性 （※12） |
- |
| ブロック・ボリューム NFSサーバ |
・ブロック・ボリューム が 可用性ドメイン 内に 複数レプリカを持つことによる高いデータ可用性 （※13） |
・NFSサーバがサービス可用性に対する 単一障害点 ・データ可用性を高めるために独自の バックアップ環境構築が必要（※14）（※15） |
| DenceIO NFSサーバ |
・ Linux software RAID のRAID10によるデータ 可用性 |
・NFSサーバがサービス可用性に対する 単一障害点 ・NFSサーバがデータ可用性に対する 単一障害点（※16） ・NVMe SSDドライブのRAID10による脆弱なデータ 可用性 ・データ可用性を高めるために独自の バックアップ環境構築が必要（※14） |
※12）スナップショット、クローン、及びレプリケーションが用意されています。これらサービスの詳細は、OCI公式ドキュメントの ここ を参照ください。
※13）複数の ブロック・ボリューム をNFSサーバにアタッチして使用するため、NFSサーバ障害でインスタンスを入れ替える必要が生じた場合、 ブロック・ボリューム に格納するファイルを復旧するためには特別な手順が必要です。
この詳細は、 OCI HPCテクニカルTips集 の ブロック・ボリュームを使用するNFSサーバのインスタンス障害からの復旧方法 を参照してください。
※14）このバックアップ環境は、 OCI HPCチュートリアル集 の ベア・メタル・インスタンスNFSサーバ向けバックアップサーバを構築する に従って構築することが出来ます。
※15）ブロック・ボリューム に格納するファイルのバックアップは、NFSサーバ上のファイルシステムとしてアクセスしバックアップする必要があり、 ブロック・ボリューム が用意するブロックデバイスレベルのバックアップ機能を利用することが出来ません。
※16）障害等でNFSサーバインスタンスを再構築する必要が発生すると、NVMe SSDローカルディスクに格納するファイルが消失します。
以上より、可用性を評価指標に各構築手法を比較すると、ファイル・ストレージを使用する構築手法がベア・メタル・インスタンスNFSサーバを使用する構築手法より圧倒的にデータ可用性とサービス可用性が高いことがわかります。
2.3 運用性による比較
本章は、運用性としてシステム構築・運用のしやすさを評価指標に採用します。
ここで ファイル・ストレージ を使用する標準FSSと高性能FSSは、運用性を評価指標とした場合同じ評価となるため、これらをまとめて3種類の構築手法を比較します。
以下の表は、これら3種類の構築手法の運用性観点での利点・欠点を比較しています。
| 構築手法 | 利点 | 欠点 |
|---|---|---|
| 標準FSS 高性能FSS |
・サービス開始までの構築手順が簡単 ・ファイルシステムの容量拡張作業が不要 ・メンテナンスフリーのマウント・ターゲット ・マウント・ターゲットのアップグレードによる 動的な性能向上が可能 |
- |
| ブロック・ボリューム NFSサーバ |
・ボリューム・パフォーマンスとシェイプの選択 によるNFSサーバ性能のVertical Scalingが可能 |
・サービス開始までの構築手順が煩雑（※17） ・ファイルシステムの容量拡張作業が煩雑 ・NFSサーバのソフトウェアメンテナンスが必要 |
| DenceIO NFSサーバ |
- | ・サービス開始までの構築手順が煩雑 ・ファイルシステムの容量拡張が不可能 ・NFSサーバのソフトウェアメンテナンスが必要 |
※17）この構築作業を自動化する スタック が GitHub から無料で提供されています。この詳細は、 OCI HPCチュートリアル集 の ブロック・ボリュームでファイル共有ストレージを構築する を参照してください。
以上より、運用性を評価指標に各構築手法を比較すると、ファイル・ストレージを使用する構築手法がベア・メタル・インスタンスNFSサーバを使用する構築手法より圧倒的にシステム構築やシステム運用が容易であることがわかります。