Lustre と NetApp Eシリーズストレージ - サイジングガイダンス
変更を提案
PDF
容量とメタデータのニーズに基づいて NetApp EシリーズストレージのビルディングブロックでLustreのサイズを決定し、容量を追加するタイミングを判断して、パフォーマンスに影響する要因を確認します。
容量サイジング
2台のEF80アレイで構成される基本ビルディングブロックは、次のLustreターゲットレイアウトを提供します。推奨されるターゲットの配置とNVMe-oFパスについては、"ハードウェア コンポーネント"の"プライマリビルディングブロックのボリューム分散"を参照してください。
| コンポーネント | 数 | 標準的なボリュームサイズ（ターゲットあたり） |
|---|---|---|
MGS |
1 |
5～10 GiB |
MDT |
8 |
サイズはドライブ容量とRAID構成によって異なります |
OST |
32 |
サイズはドライブ容量とRAID構成によって異なります |
各EF80アレイは24台のNVMeドライブを使用します。対応容量は、従来のボリュームグループ（MGS/MDTの場合はRAID 1、OSTの場合はRAID 6）またはDDPを使用した場合、3.84 TB、7.68 TB、15.3 TBです。また、DDPのみを使用した場合、30.7 TBまたは61.4 TBのCapacity Flash（QLC）ドライブが対応します。1.92 TBドライブは、現時点ではこのソリューションには推奨されていません。ドライブスロットのレイアウトとプールの選択については、"ハードウェア コンポーネント"を参照してください。
以下の表は、EF80ビルディングブロック（アレイ2基、ドライブ48台）のおおよその使用可能容量を示しています。アレイの使用可能容量は、最終的なLustreファイルシステムの使用可能容量とは異なります。MDTのinode割り当て、ジャーナル、オーバープロビジョニング、およびインベントリボリュームの割合は、アプリケーションで使用可能な容量を減少させます。
| ドライブ容量 | レイアウト（アレイごと） | おおよそ使用可能な量（構成要素） |
|---|---|---|
3.84 TB |
RAID 1（2+2）+ RAID 6（10）+ RAID 6（10） |
138.08 TB |
3.84 TB |
DDP（24ドライブ、2予約済み） |
133.63 TB |
7.68 TB |
RAID 1（2+2）+ RAID 6（10）+ RAID 6（10） |
276.35 TB |
7.68 TB |
DDP（24） |
267.47 TB |
15.3 TB |
RAID 1（2+2）+ RAID 6（10）+ RAID 6（10） |
552.88 TB |
15.3 TB |
DDP（24） |
535.15 TB |
30.7 TB |
DDPのみ |
1,070.35 TB |
61.4 TB |
DDPのみ |
2,162.70 TB |
メタデータとデータのサイズを個別に設定し、その後、Ansibleインベントリでボリュームサイズを設定します。デプロイメント テンプレートは ldiskfs を使用してターゲットをフォーマットします。MDT は Lustre のデフォルトの inode 比率を使用し、OST テンプレートは `-i 4096`を設定します。
-
メタデータ（MDT）： 予想されるファイル数に基づいてMDTのサイズを決定します。ファイル数の増加を見込んで、予想されるファイル数の約2倍のファイル数を確保してください。MDTのサイズが不足していると、OSTの容量に余裕があっても、新しいファイルの作成ができなくなる場合があります。
-
データ（OST）： 使用可能な容量とスループットのニーズに基づいてOSTのサイズを決定します。
-
MGS: ファイルシステム構成のためだけに、小さな管理ターゲット（5～10 GiB）を使用します。
選択したドライブ容量に合わせて、インベントリ内のMDTおよびOSTボリュームのサイズを調整してください。 `format_options.mkfsoptions`の `eseries_lustre_filesystem_mdt`または `eseries_lustre_filesystem_ost`は、サイトが異なるinode比率を必要とする場合にのみ変更してください。inode比率の背景については、"Lustre Wiki：Lustreチューニング"を参照してください。ビルディングブロックを追加するタイミングについては、[スケーリング]を参照してください。
スケーリング
容量やメタデータの負荷に応じて、構成要素を追加してください。
-
OSTのみ： ファイル数とメタデータの読み込みは既存のMDT容量内に収まっており、より多くのデータ容量または集計スループットが必要です。OSTを32台、OSS/MDSサーバーノードを2台追加します。
-
MDT+OST: ファイル数またはメタデータレートがMDTの容量に近づいているか、メタデータのスループットとデータ容量の両方を増やす必要があります。MDTを8個、OSTを32個追加します。
既存のMDT上でメタデータが飽和状態にあるかどうかを確認するには、 `mdt.*.md_stats`を使用してください。各Pacemaker/Corosyncクラスターは、5つの構成要素（10個のOSS/MDSサーバーノード）に制限してください。大規模な展開の場合は、構成要素を複数のHAクラスターに均等に分割してください。スケーリングルールについては、"ソリューションアーキテクチャ"を参照してください。
以下の例は、1つのHAクラスタ内に、基本構成要素とOST専用の構成要素を備えたファイルシステムを示しています。
| 構成要素 | タイプ | サーバ | 配列 | MGS | MDT | OST |
|---|---|---|---|---|---|---|
BB1を使用したチャンク アップロード署名要求がサポートされるようになりました。 |
基本 |
2 |
2 |
1 |
8 |
32 |
BB2 |
OST のみ |
2 |
2 |
0 |
0 |
32 |
合計 |
4 |
4 |
1 |
8 |
64 |
BB2は、 `mgsnode=`を使用して、BB1のMGSに対してOSTターゲットを登録します。BB2のOSTインデックスはグローバルに割り当てられます（例えば、OST0032からOST0063まで）。これにより、どのインデックスもBB1と競合しません。
パフォーマンス
正式な検証では、LustreクライアントのIOR、mdtest、fioを使用して、相対的なスループット、IOPS、メタデータの動作を特性評価し、HAフェイルオーバーを検証します。これらのテストでは、性能を保証する数値は公表されていません。合成ベンチマークは最良のケースの動作を測定するものであり、実際のアプリケーションのパフォーマンスを反映していない可能性があります。
パフォーマンスは、構成要素の数にほぼ比例します。実際の結果は、ドライブの種類とプールのレイアウト、NVMe-oFパス数、LNetファブリックとクライアント数、およびデータI/OとメタデータI/Oの比率によって異なります。
ワークロード固有のサイジングおよびパフォーマンスに関する推奨事項については、NetApp アカウントチームにお問い合わせください。
ドライブのレイアウトとボリューム数については、"ハードウェア コンポーネント"を参照してください。デプロイ手順については、"解決策をデプロイする"を参照してください。現場レベルの在庫管理に関するガイダンスについては、"Lustre Ansibleインベントリをカスタマイズする"を参照してください。