ストレージ要件

各ホストに適切なタイプと容量のストレージを設定できるよう、StorageGRIDノードのストレージ要件を把握しておく必要があります。

StorageGRIDノードに必要なストレージは、3つの論理カテゴリに分類されます。

コンテナプール – ノードコンテナ用のパフォーマンス階層（10K SASまたはSSD）のストレージ。StorageGRIDノードをサポートするホストにDockerをインストールして設定するときに、Dockerストレージドライバに割り当てられます。
システムメタデータ – システムメタデータとトランザクションログのノード単位の永続的なストレージとして使用されるパフォーマンス階層（10K SASまたはSSD）のストレージ。StorageGRIDホストサービスで個々のノードにマッピングされて使用されます。
オブジェクトデータ – オブジェクトデータとオブジェクトメタデータの永続的なストレージとして使用されるパフォーマンス階層（10K SASまたはSSD）のストレージと大容量階層（NL-SAS / SATA）のストレージ。

カテゴリに関係なく、いずれのストレージにもRAIDベースのブロックデバイスを使用する必要があります。非冗長ディスク、SSD、またはJBODはサポートされていません。いずれのカテゴリのストレージにも、共有またはローカルのどちらかのRAIDストレージを使用できます。ただし、StorageGRIDのノード移行機能を使用する場合は、システムメタデータとオブジェクトデータの両方を共有ストレージに格納する必要があります。

パフォーマンス要件

コンテナプールのボリューム、システムメタデータのボリューム、およびオブジェクトメタデータのボリュームのパフォーマンスは、システム全体のパフォーマンスに大きく影響します。ボリュームのディスクパフォーマンスが、レイテンシ、1秒あたりの入出力操作（IOPS）、スループットの点で適切になるように、それらのボリュームにはパフォーマンス階層（10K SASまたはSSD）のストレージを使用します。オブジェクトデータの永続的なストレージには、大容量階層（NL-SAS / SATA）のストレージを使用できます。

コンテナプール、システムメタデータ、およびオブジェクトデータ用のボリュームでは、ライトバックキャッシュを有効にする必要があります。キャッシュは、保護されたメディアまたは永続的なメディアに配置する必要があります。

NetApp AFFストレージを使用するホストの要件

StorageGRIDノード用のホストでNetApp AFFシステムから割り当てられたストレージを使用する場合は、ボリュームでFabricPool階層化ポリシーが有効になっていないことを確認してください。StorageGRIDノードで使用するボリュームでFabricPoolによる階層化を無効にすることで、トラブルシューティングとストレージの処理がシンプルになります。

注意:FabricPoolを使用してStorageGRIDに関連するデータをStorageGRID自体に階層化することは絶対にしないでください。StorageGRIDにStorageGRIDデータを階層化すると、トラブルシューティングと運用がより複雑になります。

必要なホスト数

各StorageGRIDサイトに、少なくとも3個のストレージノードが必要です。

注意:本番環境では、1台の物理ホストまたは仮想ホスト上で複数のストレージノードを実行しないでください。各ストレージノードに専用のホストを使用すると、分離された障害ドメインが提供されます。

管理ノードやゲートウェイノードなど、他のタイプのノードは、同じホストに導入するか、必要に応じて独自の専用ホストに導入することができます。

各ホストのストレージボリュームの数

次の表に、ホストに導入されるノードの種類別に、各ホストに必要なストレージボリューム（LUN）の数と各LUNに必要な最小サイズを示します。

検証済みの最大LUNサイズは39TBです。

注:これらはホストごとの数値を示したものであり、グリッド全体の数値ではありません。

LUNの用途	ストレージのカテゴリ	LUNの数	LUNあたりの最小サイズ
Dockerストレージプール	コンテナプール	1	ノードの総数 × 100GB
/var/local ボリューム	システムメタデータ	このホストのノードごとに1個	90GB
ストレージノード	オブジェクトデータ	このホストのストレージノードごとに3個注:1個のストレージノードには1～16個のストレージボリュームを設定できます。3個以上のストレージボリュームが推奨されます。	4,000GB 詳細については、以下の「ストレージノードのストレージ要件」を参照してください。
管理ノードの監査ログ	システムメタデータ	このホストの管理ノードごとに1個	200GB
管理ノードのテーブル	システムメタデータ	このホストの管理ノードごとに1個	200GB

注意:設定されている監査レベル、S3オブジェクトキー名などのユーザ入力のサイズ、保持する必要がある監査ログデータの量によっては、各管理ノードの監査ログLUNのサイズを増やす必要があります。概算としては、グリッドはS3処理ごとに約1KBの監査データを生成します。つまり、200GB LUNでは1日あたり7,000万件（1秒あたり800件）の処理を2～3日間サポートします。

ホストの最小ストレージスペース

次の表に、各タイプのノードに必要な最小ストレージスペースを示します。この表を参照して、ホストに導入するノードの種類に応じて、ストレージカテゴリごとにホストで確保しなければならない最小ストレージ容量を決定できます。

ノードのタイプ	コンテナプール	システムメタデータ	オブジェクトデータ
ストレージノード	100GB	90GB	4,000GB
管理ノード	100GB	490GB（3個のLUN）	該当なし
ゲートウェイノード	100GB	90GB	該当なし
アーカイブノード	100GB	90GB	該当なし

例：ホストのストレージ要件の計算

同じホストに3個のノードを導入することを計画しているとします。ストレージノードが1個、管理ノードが1個、ゲートウェイノードが1個です。この場合、少なくとも9個のストレージボリュームをホストに用意する必要があります。ノードコンテナ用にパフォーマンス階層のストレージが300GB以上、システムメタデータとトランザクションログ用にパフォーマンス階層のストレージが670GB以上、オブジェクトデータ用に容量階層のストレージが12TB以上、それぞれ必要になります。

ノードのタイプ	LUNの用途	LUNの数	LUNのサイズ
	Dockerストレージプール	1	300GB（100GB/ノード）
ストレージノード	/var/local ボリューム	1	90GB
ストレージノード	オブジェクトデータ	3	4,000GB
管理ノード	/var/local ボリューム	1	90GB
	管理ノードの監査ログ	1	200GB
	管理ノードのテーブル	1	200GB
ゲートウェイノード	/var/local ボリューム	1	90GB
合計		9	コンテナプール：300GB システムメタデータ：670GB オブジェクトデータ：12,000GB

ストレージノードのストレージ要件

1個のストレージノードには1～16個のストレージボリュームを設定できます。ただし、3個以上のストレージボリュームが推奨されます。各ストレージボリュームのサイズは4TB以上にします。

各ストレージノードのボリューム0に4TB以上を割り当てる必要があります。StorageGRIDは、オブジェクトメタデータ用のスペース（Metadata Reserved Space[CAWM]）、およびコンパクションや修復などの重要なデータベース処理用のスペースをボリューム0に最大4TB確保します。

追加のスペースをボリューム0に割り当てると、そのスペースはオブジェクトストレージに使用されます。ボリューム0に4TB以上を割り当てることが推奨されます。

注:ストレージノードでストレージボリュームを1個しか使用していない場合に、そのボリュームに4TB以下を割り当てると、ストレージノードが起動時にストレージ読み取り専用状態になり、オブジェクトメタデータのみが格納される可能性があります。

注:ボリューム0への割り当てが500GB未満の場合（非本番環境での使用のみ）は、ストレージボリュームの容量の10%がメタデータ用に確保されます。