Skip to main content
本製品の最新リリースがご利用いただけます。
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

StorageGRIDのストレージとパフォーマンスの要件

StorageGRIDノードのストレージ要件を理解し、初期構成と将来のストレージ拡張をサポートするのに十分なスペースを確保する必要があります。

ストレージ容量とパフォーマンスに関する要件は、ソフトウェアベースのノード実装によって異なります。

メモ 「Linux」とは、RHEL、Ubuntu、またはDebianのいずれかの環境を指します。サポートされているバージョンの一覧については、 "NetApp Interoperability Matrix Tool(IMT)"を参照してください。

ストレージカテゴリ

StorageGRIDノードには、3つの論理カテゴリのストレージが必要です。

  • コンテナプール — ノードコンテナ用のパフォーマンス層(10K SAS または SSD)ストレージ。StorageGRID ノードをサポートするホストにコンテナエンジンをインストールして構成すると、コンテナエンジンのストレージドライバに割り当てられます。

  • システムデータ — パフォーマンス層(10K SAS または SSD)ストレージは、システムデータとトランザクションログをノードごとに永続的に保存するためのもので、StorageGRID ホストサービスによって消費され、個々のノードにマッピングされます。

  • オブジェクトデータ — オブジェクトデータとオブジェクトメタデータを永続的に保存するための、パフォーマンス層(10K SASまたはSSD)ストレージと容量層(NL-SAS/SATA)バルクストレージ。

すべてのストレージカテゴリにおいて、RAIDでバックアップされたブロックデバイスを使用する必要があります。冗長構成ではないディスク、SSD、またはJBODはサポートされていません。ストレージカテゴリのいずれにも共有またはローカルのRAIDストレージを使用できますが、ノード移行機能を使用する場合は、StorageGRIDシステムデータとオブジェクトデータの両方を共有ストレージに保存する必要があります。詳細については、"ノードコンテナ移行の要件"を参照してください。

性能要件

コンテナプール、システムデータ、およびオブジェクトメタデータに使用されるボリュームのパフォーマンスは、システム全体のパフォーマンスに大きな影響を与えます。これらのボリュームには、レイテンシ、1秒あたりの入出力操作数(IOPS)、スループットの点で十分なディスクパフォーマンスを確保するために、パフォーマンス階層(10K SASまたはSSD)のストレージを使用する必要があります。オブジェクトデータの永続的な保存には、容量階層型(NL-SAS/SATA)ストレージを使用できます。

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

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

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

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

必要なホスト数

各StorageGRIDサイトには、最低3つのストレージノードが必要です。

メモ 本番環境への展開においては、単一の物理ホストまたは仮想ホスト上で複数のストレージノードを実行しないでください。各ストレージノードに専用ホストを使用することで、障害発生時のドメインを分離できます。

管理ノードやゲートウェイノードなどの他の種類のノードは、同じホスト上にデプロイすることも、必要に応じて専用のホスト上にデプロイすることもできます。

メモ ディスクスナップショットは、グリッドノードの復元には使用できません。代わりに、各ノードタイプの"グリッドノードの復旧"手順を参照してください。

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

以下の表は、各ホストに必要なストレージボリューム(LUN)の数と、各LUNに必要な最小サイズを、そのホストにデプロイされるノードに基づいて示しています。

テスト済みの最大LUNサイズは39 TBです。

メモ これらの数値は、グリッド全体ではなく、各ホストごとの数値です。
LUNの用途 ストレージカテゴリ LUNの数 最小サイズ/LUN

コンテナエンジンストレージプール

コンテナプール

1

ノード総数 × 100 GB

/var/local ボリューム

システムデータ

このホスト上のノードごとに 1

100 GB

ストレージ ノード

オブジェクトデータ

このホスト上のストレージノードごとに3つ

注: Linuxソフトウェアベースのストレージノードは、1~48個のストレージボリュームを持つことができます。VMwareソフトウェアベースのストレージノードは、1~16個のストレージボリュームを持つことができます。少なくとも3つのストレージボリュームを推奨します。

12 TB (4 TB/LUN、最小)

テスト済みの最大LUNサイズ:39 TB。

詳細については、ストレージノードのストレージ要件を参照してください。

ストレージノード(メタデータのみ)

オブジェクトメタデータ

1

4 TB/LUN、最小

テスト済みの最大LUNサイズ:39 TB。

詳細については、ストレージノードのストレージ要件を参照してください。

:メタデータ専用のストレージノードには、rangedb が 1 つだけ必要です。

管理者ノードの監査ログ

システムデータ

このホスト上の各管理ノードにつき1つ

200 GB

管理ノードテーブル

システムデータ

このホスト上の各管理ノードにつき1つ

200 GB

メモ 設定されている監査レベル、S3オブジェクトキー名などのユーザー入力のサイズ、および保持する必要のある監査ログデータの量によっては、各管理ノードの監査ログLUNのサイズを増やす必要がある場合があります。一般的に、グリッドはS3操作1回あたり約1 KBの監査データを生成するため、200 GB のLUNは2~3日間、1日あたり7,000万回の操作、または1秒あたり800回の操作をサポートできることになります。

ホストに必要な最小ストレージ容量

以下の表は、ノードの種類ごとに必要な最小ストレージ容量を示しています。この表を使用すると、ホストにデプロイされるノードに基づいて、各ストレージカテゴリでホストに提供する必要のある最小ストレージ容量を判断できます。

メモ ディスクスナップショットは、グリッドノードの復元には使用できません。代わりに、各ノードタイプの"グリッドノードの復旧"手順を参照してください。

各ノードホストには、OS用に100GBのLUNが必要です。

ノードの種類 コンテナプール システムデータ オブジェクトデータ

ストレージ ノード

100 GB

100 GB

4,000 GB

管理ノード

100 GB

500 GB(3 LUNs)

適用できない

ゲートウェイ ノード

100 GB

100 GB

適用できない

例:ホストまたは仮想マシンのストレージ要件の計算

同じホストまたは仮想マシン上に、ストレージノード、管理ノード、ゲートウェイノードの3つのノードをデプロイする計画を立てているとします。ホストには最低9つのストレージボリュームを提供する必要があります。ノードコンテナには最低 300 GB のパフォーマンス層ストレージ、システムデータとトランザクションログには 700 GB のパフォーマンス層ストレージ、オブジェクトデータには 12 TB の容量層ストレージが必要です。

Linuxホストの例
ノードの種類 LUNの用途 LUNの数 LUN size

ストレージ ノード

コンテナエンジンストレージプール

1

300 GB (100 GB/ノード)

ストレージ ノード

/var/local ボリューム

1

100 GB

ストレージ ノード

オブジェクトデータ

3

12 TB(4 TB/LUN)

管理ノード

/var/local ボリューム

1

100 GB

管理ノード

管理者ノードの監査ログ

1

200 GB

管理ノード

管理ノードテーブル

1

200 GB

ゲートウェイ ノード

/var/local ボリューム

1

100 GB

合計

9

コンテナプール:300 GB

システムデータ: 700 GB

オブジェクトデータ:12,000 GB

VMware仮想マシンの例
ノードの種類 LUNの用途 LUNの数 LUN size

ストレージ ノード

OSボリューム

1

100 GB

ストレージ ノード

オブジェクトデータ

3

12 TB(4 TB/LUN)

管理ノード

OSボリューム

1

100 GB

管理ノード

管理者ノードの監査ログ

1

200 GB

管理ノード

管理ノードテーブル

1

200 GB

ゲートウェイ ノード

OSボリューム

1

100 GB

合計

8

システムデータ: 700 GB

オブジェクトデータ:12,000 GB

ストレージノードの具体的なストレージ要件

LinuxとVMwareでは、ストレージノードのストレージ要件が異なります。

  • Linuxソフトウェアベースのストレージノードは、1~48個のストレージボリュームを持つことができます。

  • VMwareソフトウェアベースのストレージノードは、1~16個のストレージボリュームを持つことができます。

  • 3つ以上のストレージボリュームを使用することをお勧めします。

  • 各ストレージボリュームは4TB以上である必要があります。

メモ アプライアンスのストレージノードは、最大48個のストレージボリュームを持つことができます。

図に示すように、StorageGRID は各ストレージノードのストレージボリューム 0 に、オブジェクトメタデータ用の領域を確保します。ストレージボリューム 0 およびストレージノード内のその他のストレージボリュームに残っている空き容量は、オブジェクトデータ専用に使用されます。

メタデータスペースストレージノード

冗長性を提供し、オブジェクトのメタデータを損失から保護するために、StorageGRID はシステム内のすべてのオブジェクトのメタデータのコピーを、各サイトに3つ保存します。オブジェクトメタデータの3つのコピーは、各サイトのすべてのストレージノードに均等に分散されます。

メタデータ専用のストレージノードでグリッドをインストールする場合、グリッドにはオブジェクトストレージ用のノードも最低限含まれている必要があります。メタデータ専用ストレージノードの詳細については、"ストレージノードの種類"を参照してください。

  • 単一サイトのグリッドの場合、オブジェクトとメタデータ用に少なくとも2つのストレージノードが構成されます。

  • 複数サイト構成のグリッドの場合、オブジェクトとメタデータ用に、サイトごとに少なくとも1つのストレージノードが構成されます。

新しいストレージノードのボリューム0に領域を割り当てる場合、そのノードが保持するすべてのオブジェクトメタデータのための十分な領域が確保されていることを確認する必要があります。

  • 最低でも、ボリューム0には4TB以上の容量を割り当てる必要があります。

    メモ ストレージノードにストレージボリュームを1つだけ使用し、そのボリュームに4TB以下の容量を割り当てると、ストレージノードは起動時にストレージ読み取り専用状態になり、オブジェクトのメタデータのみを保存する可能性があります。
    メモ ボリューム0(非本番環境専用)に500 GB未満の容量を割り当てた場合、ストレージボリューム容量の10%がメタデータ用に予約されます。
  • ソフトウェアベースのメタデータ専用ノードリソースは、既存のストレージノードリソースと一致している必要があります。例:

    • 既存の StorageGRID サイトで SG6000 または SG6100 アプライアンスを使用している場合、ソフトウェアベースのメタデータ専用ノードは以下の最小要件を満たす必要があります:

      • 128GBのRAM

      • 8コアCPU

      • Cassandraデータベース用に8 TB SSDまたは同等のストレージ(rangedb/0)

    • 既存の StorageGRID サイトで 24 GB RAM、8 コア CPU、3 TB または 4 TB のメタデータストレージを備えた仮想ストレージノードを使用している場合、ソフトウェアベースのメタデータ専用ノードも同様のリソース(24 GB RAM、8 コア CPU、4 TB のメタデータストレージ(rangedb/0))を使用する必要があります。

      新しい StorageGRID サイトを追加する場合、新しいサイトの合計メタデータ容量は、少なくとも既存の StorageGRID サイトと同等である必要があり、新しいサイトのリソースは既存の StorageGRID サイトのストレージノードと一致する必要があります。

  • 新しいシステムをインストールする場合(StorageGRID 11.6 以降)で、各ストレージノードに 128 GB 以上の RAM が搭載されている場合は、ボリューム 0 に 8 TB 以上を割り当ててください。ボリューム 0 に大きな値を指定すると、各ストレージノード上のメタデータに割り当てられる容量を増やすことができます。

  • 同一サイト向けに複数のストレージノードを設定する場合は、可能であればボリューム0にも同じ設定を使用してください。サイトに異なるサイズのストレージノードが含まれている場合、ボリューム0が最小のストレージノードがそのサイトのメタデータ容量を決定します。

詳細については、"オブジェクトメタデータストレージの管理"を参照してください。