Skip to main content
StorageGRID solutions and resources
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

『Achieving zero RPO with StorageGRID - A Comprehensive Guide to Multi-Site Replication』

共同作成者 netapp-aronk

この技術レポートでは、サイト障害発生時に復旧ポイント目標 (RPO) ゼロを達成するためのStorageGRIDレプリケーション戦略の実装に関する包括的なガイドを提供します。このドキュメントでは、マルチサイト同期レプリケーションやマルチグリッド非同期レプリケーションなど、 StorageGRIDのさまざまな展開オプションについて詳しく説明します。複数の場所にわたってデータの耐久性と可用性を確保するために、 StorageGRID情報ライフサイクル管理 (ILM) ポリシーを構成する方法について説明します。さらに、レポートでは、中断のないクライアント操作を維持するためのパフォーマンスに関する考慮事項、障害シナリオ、および回復プロセスについても説明します。このドキュメントの目的は、同期レプリケーション技術と非同期レプリケーション技術の両方を活用して、サイト全体の障害が発生した場合でも、データがアクセス可能で一貫性が保たれるようにするための情報を提供することです。

StorageGRIDの概要

NetApp StorageGRIDは、業界標準のAmazon Simple Storage Service(Amazon S3)APIをサポートするオブジェクトベースのストレージシステムです。

StorageGRIDは、情報ライフサイクル管理ポリシー(ILM)に基づくさまざまなサービスレベルで、複数の場所にわたって単一のネームスペースを提供します。これらのライフサイクル ポリシーを使用すると、ライフサイクル全体にわたってデータが存在する場所を最適化できます。

StorageGRIDを使用すると、ローカルソリューションや地理的に分散したソリューションで、データの保持方法と可用性を設定できます。データがオンプレミスにあるかパブリッククラウドにあるかに関係なく、統合ハイブリッドクラウドワークフローにより、Amazon Simple Notification Service (Amazon SNS)、Google Cloud、Microsoft Azure Blob、Amazon S3 Glacier、Elasticsearch などのクラウドサービスをビジネスで活用できます。

StorageGRIDスケール

最小限のStorageGRID展開は、単一サイト内の管理ノードと 3 つのストレージ ノードで構成されます。1 つのグリッドは最大 220 ノードまで拡張できます。StorageGRID は、単一のサイトとして展開することも、16 サイトに拡張することもできます。

管理ノードには、メトリックとログの中心点となる管理インターフェイスが含まれており、 StorageGRIDコンポーネントの構成を維持します。管理ノードには、S3 API アクセス用の統合ロードバランサーも含まれています。

StorageGRID は、ソフトウェアのみ、VMware 仮想マシン アプライアンス、または専用アプライアンスとして導入できます。

ストレージ ノードは次のように展開できます。

  • オブジェクト数を最大化するメタデータのみのノード

  • オブジェクトスペースを最大化するオブジェクトストレージ専用ノード

  • オブジェクト数とオブジェクトスペースの両方を追加するメタデータとオブジェクトストレージノードの組み合わせ

各ストレージ ノードは、オブジェクト ストレージ用に数ペタバイトの容量まで拡張でき、数百ペタバイトの単一の名前空間が可能になります。 StorageGRID は、ゲートウェイ ノードと呼ばれる S3 API 操作用の統合ロード バランサーも提供します。

StorageGRIDの導入オプション

StorageGRID は、サイト トポロジに配置されたノードのコレクションで構成されます。 StorageGRID内のサイトは、固有の物理的な場所に配置することも、論理構造としてグリッド内の他のサイトと同じ物理的な場所に配置することもできます。 StorageGRIDサイトは複数の物理的な場所にまたがってはなりません。サイトは、共有ローカル エリア ネットワーク (LAN) インフラストラクチャと障害ドメインを表します。

StorageGRIDおよび障害ドメイン

StorageGRIDには障害ドメインの複数のレイヤが含まれており、ソリューションの設計方法、データの格納方法、障害のリスクを軽減するためのデータの格納場所を決定する際に考慮する必要があります。

  • グリッドレベル-複数のサイトで構成されるグリッドでは、サイト障害や分離が発生しても、アクセス可能なサイトはグリッドとして動作し続けることができます。

  • サイトレベル-サイト内で障害が発生した場合、そのサイトの運用に影響する可能性がありますが、グリッドの残りの部分には影響しません。

  • ノードレベル-ノード障害がサイトの運用に影響することはありません。

  • ディスクレベル-ディスク障害はノードの動作に影響しません。

オブジェクトデータとメタデータ

オブジェクトストレージでは、ストレージの単位がファイルやブロックではなく、オブジェクトになります。ファイルシステムやブロックストレージのツリー階層とは異なり、オブジェクトストレージでは、フラットで非構造化されたレイアウトでデータが編成されます。オブジェクトストレージでは、データの物理的な場所と、データを格納および読み出す方法が切り離されています。

オブジェクトベースのストレージシステムの各オブジェクトには、オブジェクトデータとオブジェクトメタデータという 2 つの要素があります。

  • オブジェクト データは、写真、動画、医療記録など、実際の基礎データを表します。

  • オブジェクトメタデータは、オブジェクトについて記述された任意の情報です。

StorageGRID では、オブジェクトメタデータを使用してグリッド全体のすべてのオブジェクトの場所を追跡し、各オブジェクトのライフサイクルを継続的に管理します。

オブジェクトメタデータには、次のような情報が含まれます。

  • システム メタデータには、各オブジェクトの一意の ID、オブジェクト名、S3 バケットの名前、テナント アカウント名または ID、オブジェクトの論理サイズ、オブジェクトが最初に作成された日時、オブジェクトが最後に変更された日時が含まれます。

  • 各オブジェクトの複製コピーまたは消失訂正符号化フラグメントの現在の保存場所。

  • オブジェクトに関連付けられているカスタムユーザメタデータのキーと値のペア。

  • S3オブジェクトの場合、オブジェクトに関連付けられているオブジェクトタグのキーと値のペア

  • セグメント化されたオブジェクトとマルチパート オブジェクトの場合、セグメント識別子とデータ サイズ。

オブジェクトメタデータはカスタマイズと拡張が可能なため、アプリケーションに合わせて柔軟に設定できます。StorageGRIDがオブジェクトメタデータを格納する方法と場所の詳細については、を参照してください "オブジェクトメタデータストレージを管理する"

StorageGRIDの情報ライフサイクル管理(ILM)システムは、StorageGRIDシステム内のすべてのオブジェクトデータの配置、期間、取り込み動作のオーケストレーションに使用されます。ILMルールは、オブジェクトのレプリカを使用したり、ノードやサイト間でオブジェクトをイレイジャーコーディングしたりして、StorageGRIDが時間の経過に伴ってオブジェクトを格納する方法を決定します。このILMシステムは、グリッド内のオブジェクトデータの整合性を維持します。

イレイジャーコーディング

StorageGRID は、ノード レベルとドライブ レベルでデータを消去コード化する機能を提供します。 StorageGRIDアプライアンスでは、ノード内のすべてのドライブにわたって各ノードに保存されているデータを消去コード化し、データの損失や中断を引き起こす複数のディスク障害に対するローカル保護を提供します。ドライブ障害からの再構築はノードに対してローカルであり、ネットワーク経由でデータを複製する必要はありません。

さらに、 StorageGRIDアプライアンスは、消失訂正符号スキームを使用して、サイト内のノード全体またはStorageGRIDシステム内の 3 つ以上のサイトに分散されたオブジェクト データを保存し、StorageGRID の ILM ルールによってノード障害から保護します。

イレージャー コーディングは、レプリケーションよりも低いオーバーヘッドで、ノードおよびサイトの障害に対して耐性のあるストレージ レイアウトを提供します。データ チャンクを保存するために必要な最小数のノードが満たされていれば、すべてのStorageGRID消去コーディング スキームを単一のサイトに展開できます。つまり、4+2 の EC スキームでは、データを受信するために少なくとも 6 つのノードが必要になります。

オブジェクトで使用可能なStorageGRIDイレイジャーコーディングスキーム

メタデータの整合性

StorageGRIDでは、整合性と可用性を確保するために、メタデータは通常、サイトごとに3つのレプリカとともに格納されます。この冗長性により、障害が発生した場合でも、データの整合性とアクセス性が維持されます。

デフォルトの整合性は、グリッド全体のレベルで定義されます。整合性はバケットレベルでいつでも変更できます。

StorageGRIDで使用できるバケット整合性オプションは次のとおりです。

  • all:最高レベルの一貫性を提供します。グリッド内のすべてのノードがすぐにデータを受信しないと、要求は失敗します。

  • 強力なグローバル:

    • レガシー ストロング グローバル: すべてのサイトにわたるすべてのクライアント要求の書き込み後の読み取り一貫性を保証します。

      • これは、新しい Quorum Strong Global に手動で変更せずに 11.9 以前から 12.0 にアップグレードされたすべてのシステムのデフォルトの動作です。

    • Quorum Strong-global: すべてのサイトにわたるすべてのクライアント要求の書き込み後の読み取り一貫性を保証します。メタデータ レプリカ クォーラムが達成可能な場合は、複数のノードまたはサイト障害に対しても一貫性を提供します。

      • これは、12.0 以降で新しくインストールされたすべてのシステムのデフォルトの動作です。

      • QUORUM の一貫性は、ストレージ ノード メタデータ レプリカのクォーラムとして定義され、各サイトには 3 つのメタデータ レプリカがあります。これは次のように計算できる: 1+((N*3)/2) ここでNはサイトの総数である

      • たとえば、サイト内のレプリカが最大 3 つである 3 つのサイト グリッドからは、最小 5 つのレプリカを作成する必要があります。

  • *strong-site *:サイト内のすべてのクライアント要求に対してリードアフターライト整合性が保証されます。

  • * Read-after-new-write *(デフォルト):新規オブジェクトにはリードアフターライト整合性を提供し、オブジェクトの更新には結果整合性を提供します。高可用性が確保され、データ保護が保証されます。ほとんどの場合に推奨されます。

  • * available *:新しいオブジェクトとオブジェクトの更新の両方について、結果整合性を提供します。S3バケットの場合は、必要な場合にのみ使用します(読み取り頻度の低いログ値を含むバケットや、存在しないキーに対するHEAD処理やGET処理など)。S3 FabricPool バケットではサポートされません。

オブジェクトデータの整合性

メタデータはサイト内およびサイト間で自動的にレプリケートされますが、オブジェクトデータのストレージ配置はユーザが決定します。オブジェクトデータは、サイト内およびサイト間のレプリカ、サイト内またはサイト間のイレイジャーコーディング、またはそれらの組み合わせまたはレプリカとイレイジャーコーディングされたストレージスキームに格納できます。ILMルールは、すべてのオブジェクトに適用することも、特定のオブジェクト、バケット、テナントにのみ適用するようにフィルタリングすることもできます。ILMルールは、オブジェクトの格納方法、レプリカやイレイジャーコーディング、それらの場所にオブジェクトを格納する期間、レプリカの数やイレイジャーコーディングスキームの変更、場所の変更などを定義します。

各ILMルールでは、オブジェクトを保護するための3つの取り込み動作(Dual commit、balanced、またはstrict)のいずれかを設定します。

デュアル コミット オプションは、グリッド内の任意の 2 つの異なるストレージ ノードに 2 つのコピーを直ちに作成し、要求が成功したことをクライアントに返します。ノードの選択はリクエストのサイト内で試行されますが、状況によっては別のサイトのノードが使用される場合があります。オブジェクトは ILM キューに追加され、ILM ルールに従って評価および配置されます。

バランス オプションは、オブジェクトを ILM ポリシーに対して直ちに評価し、要求が成功したことをクライアントに返す前にオブジェクトを同期的に配置します。停止または配置要件を満たすためのストレージ不足のために ILM ルールを直ちに満たすことができない場合、代わりにデュアル コミットが使用されます。問題が解決されると、ILM は定義されたルールに基づいてオブジェクトを自動的に配置します。

厳密なオプションは、オブジェクトを ILM ポリシーに対して直ちに評価し、要求が成功したことをクライアントに返す前にオブジェクトを同期的に配置します。停止または配置要件を満たすためのストレージ不足のために ILM ルールを直ちに満たすことができない場合、要求は失敗し、クライアントは再試行する必要があります。

ロードバランシング

StorageGRIDは、統合ゲートウェイノード、外部の3rdパーティロードバランサ、DNSラウンドロビンを介してクライアントアクセスを使用して導入することも、ストレージノードに直接導入することもできます。1つのサイトに複数のゲートウェイノードを導入し、ハイアベイラビリティグループに構成して、ゲートウェイノードに障害が発生した場合の自動フェイルオーバーとフェイルバックを実現できます。ソリューション内のロードバランシング方式を組み合わせて、ソリューション内のすべてのサイトに単一のアクセスポイントを提供できます。

ゲートウェイ ノードは、デフォルトでゲートウェイ ノードが存在するサイト内のストレージ ノード間で負荷を分散します。StorageGRID は、ゲートウェイ ノードが複数のサイトのノードを使用して負荷を分散できるように構成できます。この構成により、クライアントの要求に対する応答の遅延に、これらのサイト間の遅延が追加されます。これは、合計遅延がクライアントにとって許容できる場合にのみ構成する必要があります。

ローカル負荷分散とグローバル負荷分散を組み合わせることで、RTO ゼロを実現できます。中断のないクライアント アクセスを確保するには、クライアント要求の負荷分散が必要です。StorageGRIDソリューションには、各サイトに多数のゲートウェイ ノードと高可用性グループを含めることができます。サイト障害が発生した場合でも、どのサイトのクライアントにも中断のないアクセスを提供するには、 StorageGRID Gateway ノードと組み合わせて外部の負荷分散ソリューションを構成する必要があります。各サイト内の負荷を管理するゲートウェイ ノードの高可用性グループを構成し、外部ロード バランサを使用して高可用性グループ間で負荷を分散します。リクエストが稼働中のサイトにのみ送信されるように、ヘルス チェックを実行するように外部ロード バランサを構成する必要があります。StorageGRIDによる負荷分散の詳細については、 "StorageGRIDロードバランサのテクニカルレポート"

StorageGRIDによるゼロRPOの要件

オブジェクトストレージシステムで目標復旧時点(RPO)をゼロにするには、障害発生時に次のことを行うことが重要です。

  • メタデータとオブジェクトコンテンツの両方が同期され、整合性があるとみなされる

  • 障害が発生しても、オブジェクトコンテンツには引き続きアクセスできます。

マルチサイト展開の場合、Quorum Strong Global は、すべてのサイト間でメタデータが同期されることを保証するための推奨される一貫性モデルであり、ゼロ RPO 要件を満たすために不可欠です。

ストレージ システム内のオブジェクトは、ライフサイクル全体にわたってデータがどのようにどこに保存されるかを指示する情報ライフサイクル管理 (ILM) ルールに基づいて保存されます。同期レプリケーションの場合、厳密な実行とバランスの取れた実行のどちらかを検討できます。

  • RPOをゼロにするには、これらのILMルールを厳密に実行する必要があります。これは、オブジェクトが定義された場所に配置される際に遅延やフォールバックが発生することなく、データの可用性と整合性が維持されるためです。

  • StorageGRIDのILM Balanceの取り込み動作は、高可用性と耐障害性のバランスを実現し、サイト障害が発生した場合でもデータの取り込みを継続できるようにします。

複数サイト間での同期導入

マルチサイト ソリューション: StorageGRID を使用すると、グリッド内の複数のサイト間でオブジェクトを同期的に複製できます。バランスや厳密な動作を伴う情報ライフサイクル管理 (ILM) ルールを設定すると、オブジェクトは指定された場所にすぐに配置されます。バケットの一貫性レベルを Quorum Strong Global に構成すると、同期メタデータのレプリケーションも保証されます。 StorageGRID は単一のグローバル名前空間を使用し、オブジェクトの配置場所をメタデータとして保存するため、すべてのノードはすべてのコピーまたは消去コード化された部分がどこにあるかを認識します。要求が行われたサイトからオブジェクトを取得できない場合は、フェイルオーバー手順を必要とせずにリモート サイトから自動的に取得されます。

障害が解決されると、手動のフェイルバック作業は必要ありません。レプリケーションパフォーマンスは、ネットワークスループット、レイテンシ、パフォーマンスが最も低いサイトによって異なります。サイトのパフォーマンスは、ノード数、CPUコア数と速度、メモリ、ドライブ数、ドライブタイプに基づいて決まります。

マルチグリッドソリューション: StorageGRIDでは、クロスグリッドレプリケーション(CGR)を使用して、複数のStorageGRIDシステム間でテナント、ユーザ、バケットをレプリケートできます。CGRを使用すると、選択したデータを16以上のサイトに拡張し、オブジェクトストアの使用可能な容量を増やし、ディザスタリカバリを実現できます。CGRを使用したバケットのレプリケーションには、オブジェクト、オブジェクトバージョン、メタデータが含まれ、双方向でも一方向でもかまいません。Recovery Point Objective(RPO;目標復旧時点)は、各StorageGRIDシステムのパフォーマンスと、それらのシステム間のネットワーク接続によって異なります。

概要:

  • グリッド内レプリケーションには同期レプリケーションと非同期レプリケーションの両方が含まれており、ILMの取り込み動作とメタデータの整合性制御を使用して設定できます。

  • グリッド間レプリケーションは非同期のみです。

単一グリッドのマルチサイト環境

次のシナリオでは、 StorageGRIDソリューションは、統合ロード バランサーの高可用性グループへの要求を管理するオプションの外部ロード バランサーを使用して構成されています。これにより、RPO ゼロに加えて RTO ゼロも実現されます。ILM は、同期配置用のバランスの取れた取り込み保護を使用して構成されています。各バケットは、3 つ以上のサイトのグリッドの場合は強力なグローバル整合性モデルのクォーラム バージョンで構成され、2 つのサイトの場合は強力なグローバル整合性のレガシー バージョンで構成されます。

シナリオ1:

2 サイトのStorageGRIDソリューションでは、すべてのオブジェクトのレプリカが少なくとも 2 つあり、すべてのメタデータのレプリカが 6 つあります。障害回復時に、停止からの更新は回復されたサイト/ノードに自動的に同期されます。サイトが 2 つしかない場合、サイト全体の損失を超える障害シナリオでゼロ RPO を達成することはほとんど不可能です。

2サイトのStorageGRIDシステム

シナリオ2:

3 つ以上のサイトのStorageGRIDソリューションでは、すべてのオブジェクトのレプリカまたは EC チャンクが少なくとも 3 つあり、すべてのメタデータのレプリカが 9 つあります。障害回復時に、停止からの更新は回復されたサイト/ノードに自動的に同期されます。3 つ以上のサイトがあれば、RPO ゼロを実現できます。

3サイトのStorageGRIDシステム

複数サイトの障害のシナリオ

障害 2サイトの成果 + レガシーストロンググローバル 3つ以上のサイトの成果 + Quorum Strong Global

単一ノードドライブ障害

各アプライアンスは複数のディスクグループを使用し、中断やデータ損失を発生させることなく、グループごとに少なくとも1本のドライブに障害が発生しても運用を継続できます。

各アプライアンスは複数のディスクグループを使用し、中断やデータ損失を発生させることなく、グループごとに少なくとも1本のドライブに障害が発生しても運用を継続できます。

1つのサイトでの単一ノード障害

運用の中断やデータ損失は発生しません。

運用の中断やデータ損失は発生しません。

1つのサイトでの複数ノードの障害

このサイトに転送されるクライアント処理が中断されますが、データ損失はありません。

もう一方のサイトに転送される処理は中断されず、データ損失も発生しません。

処理は他のすべてのサイトに転送され、中断されず、データ損失も発生しません。

複数サイトでの単一ノード障害

次の場合、システムの停止やデータ損失はゼロ

  • グリッド内に少なくとも 1 つの複製コピーが存在します

  • グリッドに十分な数のECチャンクが存在する

次の場合には、運用が停止し、データ損失のリスクが発生します。

  • 複製コピーは存在しない

  • ECチャックが不十分

次の場合、システムの停止やデータ損失はゼロ

  • グリッド内に少なくとも 1 つの複製コピーが存在する

  • グリッドに十分な数のECチャンクが存在する

次の場合には、運用が停止し、データ損失のリスクが発生します。

  • 複製コピーは存在しない

  • オブジェクトを読み出すための十分なECチャックが存在しません

単一サイト障害

障害が解決されるまで、一部のクライアント操作は中断されます。GET および HEAD 操作は中断されることなく続行されます。この障害状態でも操作を中断せずに継続するには、バケットの一貫性を新規書き込み後の読み取り以下に下げます。

運用の中断やデータ損失は発生しません。

単一サイトと単一ノードの障害

いずれかの障害が解決されるまで、一部のクライアント操作は中断されます。HEAD 操作は中断されることなく継続されます。複製コピーまたは十分な EC チャンクが存在する場合、GET 操作は中断されることなく続行されます。この障害状態でも操作を中断せずに継続するには、バケットの一貫性を新規書き込み後の読み取り以下に下げます。

業務の中断やデータの損失はありません。複製コピーの数に応じてデータが失われる可能性があります。ローカル消去コーディングにより、データの損失を防ぐことができます。

1つのサイトと残りの各サイトの1つのノード

存在するサイトは 2 つだけです。参照: 単一サイトと単一ノード。

メタデータ レプリカ クォーラムを満たすことができない場合、操作は中断されます。この障害状態でも操作を中断せずに継続するには、バケットの一貫性を新規書き込み後の読み取り以下に下げます。複製コピーの数によっては、永続的な障害によりデータが失われる可能性があります。ローカル消去コーディングにより、データの損失を防ぐことができます。

複数サイト障害

稼働中のサイトは残っていません。少なくとも 1 つのサイトを完全に回復できない場合は、データが失われます。

メタデータ レプリカ クォーラムを満たすことができない場合、操作は中断されます。この障害状態でも操作を中断せずに継続するには、バケットの一貫性を新規書き込み後の読み取り以下に下げます。十分な消去コード化されたチャンクが残っていない場合、永続的な障害によりデータが失われる可能性があります。ローカル消去コーディングまたは複製コピーにより、データ損失を防ぐことができます。

サイトのネットワーク分離

いずれかの障害が解決されるまで、クライアント操作は中断されます。この障害状態でも操作を中断せずに継続するには、バケットの一貫性を新規書き込み後の読み取り以下に下げます。データ損失なし

分離されたサイトでは操作が中断されますが、データは失われません。この障害状態でも操作を中断せずに継続するには、バケットの一貫性を新規書き込み後の読み取り以下に下げます。残りのサイトでの業務は中断されず、データも失われません。

マルチサイトマルチグリッド環境

冗長性をさらに高めるために、このシナリオでは 2 つのStorageGRIDクラスターを採用し、クロスグリッド レプリケーションを使用してそれらの同期を維持します。このソリューションでは、各StorageGRIDクラスターに 3 つのサイトが含まれます。 2 つのサイトはオブジェクト ストレージとメタデータに使用され、3 番目のサイトはメタデータ専用に使用されます。両方のシステムは、バランスのとれた ILM ルールを使用して構成され、2 つのデータ サイトのそれぞれで消去コーディングを使用してオブジェクトを同期的に保存します。バケットは、Quorum Strong Global 整合性モデルを使用して構成されます。各グリッドは、すべてのバケットで双方向のクロスグリッド レプリケーションが構成されるように構成されます。これにより、リージョン間の非同期レプリケーションが実現します。オプションで、グローバル ロード バランサを実装して、両方のStorageGRIDシステムの統合ロード バランサ高可用性グループへの要求を管理し、RPO ゼロを実現できます。

このソリューションでは、2つのリージョンに均等に分割された4つのロケーションを使用します。リージョン1には、リージョンのプライマリグリッドであるグリッド1の2つのストレージサイトと、グリッド2のメタデータサイトが含まれます。リージョン2には、リージョンのプライマリグリッドであるグリッド2の2つのストレージサイトと、グリッド1のメタデータサイトが含まれます。各リージョンでは、同じ場所にそのリージョンのプライマリグリッドのストレージサイトと、他のリージョンのメタデータ専用サイトを格納できます。メタデータのみのノードを3番目のサイトとして使用すると、メタデータに必要な整合性が確保され、その場所にあるオブジェクトのストレージが複製されることはありません。

4サイトのマルチグリッドソリューション

このソリューションには4つの場所があり、2つのStorageGRIDシステムの完全な冗長性が確保されます。RPOは0に維持され、マルチサイトの同期レプリケーションとマルチグリッドの非同期レプリケーションの両方が利用されます。いずれかのサイトで障害が発生しても、両方のStorageGRIDシステムでクライアント処理が中断されることはありません。

このソリューションでは、各オブジェクトのイレイジャーコーディングコピーが4つ、すべてのメタデータのレプリカが18個あります。これにより、クライアント処理に影響を与えることなく、複数の障害シナリオに対応できます。障害が発生すると、障害からのリカバリの更新が障害が発生したサイト/ノードに自動的に同期されます。

マルチサイト、マルチグリッドの障害シナリオ

障害 成果

単一ノードドライブ障害

各アプライアンスは複数のディスクグループを使用し、中断やデータ損失を発生させることなく、グループごとに少なくとも1本のドライブに障害が発生しても運用を継続できます。

グリッド内の一方のサイトでの単一ノード障害

運用の中断やデータ損失は発生しません。

各グリッドの1つのサイトでの単一ノード障害

運用の中断やデータ損失は発生しません。

グリッド内の1つのサイトでの複数ノードの障害

運用の中断やデータ損失は発生しません。

各グリッドの1つのサイトでの複数ノードの障害

運用の中断やデータ損失は発生しません。

グリッド内の複数のサイトにおける単一ノード障害

運用の中断やデータ損失は発生しません。

各グリッドの複数サイトでの単一ノード障害

運用の中断やデータ損失は発生しません。

グリッド内の単一サイト障害

運用の中断やデータ損失は発生しません。

各グリッドにおける単一サイト障害

運用の中断やデータ損失は発生しません。

グリッド内の単一サイトと単一ノードの障害

運用の中断やデータ損失は発生しません。

単一のグリッド内の単一のサイトと各サイトのノード

運用の中断やデータ損失は発生しません。

単一ロケーション障害

運用の中断やデータ損失は発生しません。

各グリッドDC1およびDC3での単一ロケーション障害

障害が解決されるかバケットの整合性が低下するまで処理が中断され、各グリッドで2つのサイトが失われる

すべてのデータが2箇所に存在

各グリッドDC1およびDC4またはDC2およびDC3での単一ロケーション障害

運用の中断やデータ損失は発生しません。

各グリッドDC2およびDC4での単一ロケーション障害

運用の中断やデータ損失は発生しません。

サイトのネットワーク分離

分離されたサイトの処理は中断されるが、データは失われない

残りのサイトの処理が中断されたり、データが失われたりすることはありません。

まとめ

StorageGRIDでゼロ目標復旧時点(RPO)を達成することは、サイト障害が発生した場合にデータの保持と可用性を確保するための重要な目標です。マルチサイト同期レプリケーションやマルチグリッド非同期レプリケーションなど、StorageGRIDの堅牢なレプリケーション戦略を活用することで、中断のないクライアント処理を維持し、複数の場所でデータの整合性を確保できます。情報ライフサイクル管理(ILM)ポリシーの実装とメタデータのみのノードの使用により、システムの耐障害性とパフォーマンスがさらに強化されます。StorageGRIDを使用すると、複雑な障害シナリオが発生した場合でも、データへのアクセス性と一貫性を維持しながら、企業は自信を持ってデータを管理できます。データ管理とレプリケーションに対するこの包括的なアプローチは、RPOゼロを達成し、貴重な情報を保護するための綿密な計画と実行の重要性を強調しています。