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

データ保護

共同作成者
PDF

データ保護機能には、リモートレプリケーション、ボリューム Snapshot 、ボリュームクローニング、保護ドメイン、 Double Helix テクノロジによる高可用性などがあります。

Element ストレージデータ保護の概念は次のとおりです。

リモートレプリケーションの種類

データのリモートレプリケーションには、次の形式を使用できます。

詳細については、を参照してください "TR-4741 ：『 NetApp Element Software Remote Replication 』"。

クラスタ間の同期レプリケーションと非同期レプリケーション

NetApp Element ソフトウェアを実行するクラスタでは、リアルタイムレプリケーションを使用してボリュームデータのリモートコピーを迅速に作成できます。

1 つのストレージクラスタを最大 4 つの他のストレージクラスタとペアリングすることができます。フェイルオーバーやフェイルバックの際には、クラスタペアのどちらかのクラスタからボリュームのデータを同期または非同期でレプリケートできます。

同期レプリケーション

同期レプリケーションでは、ソースクラスタからターゲットクラスタにデータが継続的にレプリケートされ、レイテンシ、パケット損失、ジッター、帯域幅に影響します。

同期レプリケーションは、次のような状況に適しています。

  • 複数のシステムを短距離でレプリケート

  • に対して地理的にローカルなディザスタリカバリサイト 出典

  • 時間の影響を受けやすいアプリケーションとデータベースの保護

  • セカンダリサイトを必要とするビジネス継続性アプリケーション プライマリサイトが停止しているときにプライマリサイトとして使用する

非同期レプリケーション

非同期レプリケーションでは、ターゲットクラスタからの確認応答を待たずに、ソースクラスタからターゲットクラスタにデータが継続的にレプリケートされます。非同期レプリケーションでは、書き込みがソースクラスタでコミットされたあとに、クライアント（アプリケーション）に通知されます。

非同期レプリケーションは、次のような状況に適しています。

  • ディザスタリカバリサイトはソースから離れており、アプリケーションはネットワークによるレイテンシを許容しません。

  • ソースクラスタとターゲットクラスタを接続するネットワークには帯域幅の制限があります。

Snapshot のみのレプリケーション

Snapshot のみのデータ保護では、特定の時点における変更済みのデータをリモートクラスタにレプリケートします。ソースクラスタで作成された Snapshot だけがレプリケートされます。ソースボリュームのアクティブな書き込みはレプリケートされません。

Snapshot レプリケーションの頻度を設定できます。

Snapshot レプリケーションは、非同期レプリケーションまたは同期レプリケーションには影響しません。

SnapMirror を使用した Element クラスタと ONTAP クラスタ間のレプリケーション

NetApp SnapMirror テクノロジを使用すると、ディザスタリカバリを目的として、 NetApp Element ソフトウェアを使用して作成された Snapshot を ONTAP にレプリケートできます。SnapMirror 関係では、 Element が一方のエンドポイントで、 ONTAP がもう一方のエンドポイントです。

SnapMirror は、地理的に離れたサイトのプライマリストレージからセカンダリストレージへのフェイルオーバー用に設計されたディザスタリカバリを支える NetApp Snapshot レプリケーションテクノロジです。SnapMirror テクノロジは、セカンダリストレージにある作業データのレプリカまたはミラーを作成します。これにより、プライマリサイトで障害が発生した場合でも、引き続きデータを提供できます。データのミラーリングはボリュームレベルで行われます。

プライマリストレージのソースボリュームとセカンダリストレージのデスティネーションボリュームの関係を、データ保護関係と呼びます。クラスタは、ボリュームが配置されているエンドポイントと呼ばれ、レプリケートされたデータを含むボリュームがピアリングされている必要があります。ピア関係にあることで、クラスタとボリュームの間でデータをセキュアにやり取りできます。

SnapMirror は、 NetApp ONTAP コントローラにあらかじめ搭載されており、 NetApp HCI クラスタと SolidFire クラスタで実行される Element に統合されています。SnapMirror を制御するロジックは ONTAP ソフトウェアにあるため、連携して機能するには、すべての SnapMirror 関係に少なくとも 1 つ ONTAP システムが含まれている必要があります。ユーザは主に Element UI から Element クラスタと ONTAP クラスタの間の関係を管理しますが、一部の管理タスクは NetApp ONTAP System Manager で実行します。また、 ONTAP と Element の両方で使用できる CLI と API を使用して SnapMirror を管理することもできます。

を参照してください "TR-4651 ：『 NetApp SolidFire SnapMirror Architecture and Configuration 』" （ログインが必要）

Element ソフトウェアを使用して、クラスタレベルで SnapMirror 機能を手動で有効にする必要があります。SnapMirror 機能はデフォルトでは無効になっており、新規インストール時やアップグレード時に自動的に有効になることはありません。

SnapMirror を有効にしたあと、 Element ソフトウェアの Data Protection タブで SnapMirror 関係を作成できます。

NetApp Element ソフトウェア 10.1 以降では、 ONTAP システムの SnapMirror 機能による Snapshot のコピーとリストアがサポートされます。

Element 10.1 以降を実行するシステムには、 9.3 以降の ONTAP システム上の SnapMirror と直接通信できるコードが組み込まれています。Element API には、クラスタ、ボリューム、 Snapshot で SnapMirror 機能を有効にするメソッドが用意されています。さらに、 Element UI には、 Element ソフトウェアと ONTAP システムの間の SnapMirror 関係を管理する機能が搭載されています。

Element 10.3 以降および ONTAP 9.4 以降のシステムでは、機能は限定されますが、特定のユースケースで ONTAP ボリュームを Element ボリュームにレプリケートできます。

詳細については、 ONTAP のドキュメントを参照してください。

データ保護用のボリューム Snapshot

ボリューム Snapshot はボリュームのポイントインタイムコピーであり、あとでその時点にボリュームをリストアする際に使用できます。

Snapshot はボリュームクローンに似ていますが、 Snapshot はボリュームメタデータの単なるレプリカであるため、マウントや書き込みはできません。ボリューム Snapshot の作成には少量のシステムリソースとスペースしか使用されないため、クローニングよりも短い時間で完了します。

Snapshot をリモートのクラスタにレプリケートして、ボリュームのバックアップコピーとして使用できます。レプリケートした Snapshot を使用して、ボリュームを特定の時点にロールバックできます。また、レプリケートした Snapshot からボリュームのクローンを作成できます。

Snapshot は、 Element クラスタから外部のオブジェクトストア、または別の Element クラスタにバックアップできます。Snapshot を外部のオブジェクトストアにバックアップする場合は、オブジェクトストアに接続していて、読み取り / 書き込み処理が許可されている必要があります。

データ保護用に、個々のボリュームまたは複数の Snapshot を作成できます。

ボリュームクローン

単一のボリュームまたは複数のボリュームのクローンは、データのポイントインタイムコピーです。ボリュームをクローニングすると、ボリュームの Snapshot が作成され、次にその Snapshot が参照しているデータのコピーが作成されます。

これは非同期のプロセスであり、クローニングするボリュームのサイズおよび現在のクラスタの負荷によって所要時間が異なります。

クラスタでは、ボリュームあたり一度に実行できるクローン要求は最大 2 つ、アクティブなボリュームのクローン処理は最大 8 件までサポートされます。これらの制限を超える要求はキューに登録され、あとで処理されます。

Element ストレージのバックアップとリストアのプロセスの概要

他の SolidFire ストレージ、および Amazon S3 または OpenStack Swift と互換性のあるセカンダリオブジェクトストアに対して、ボリュームのバックアップとリストアを実行できます。

ボリュームは次の場所にバックアップできます。

  • SolidFire ストレージクラスタ

  • Amazon S3 オブジェクトストア

  • OpenStack Swift オブジェクトストア

OpenStack Swift または Amazon S3 からボリュームをリストアするときは、元のバックアッププロセスのマニフェスト情報が必要です。SolidFire ストレージシステムにバックアップされているボリュームをリストアする場合は、マニフェスト情報は不要です。

保護ドメイン

保護ドメインは、データの可用性を維持したまま、任意の部分またはすべてで障害が発生する可能性があるように、グループ化されたノードまたはノードのセットです。保護ドメインを使用すると、ストレージクラスタをシャーシ（シャーシアフィニティ）またはドメイン全体（シャーシのグループ）の損失から自動的に修復できます。

NetApp Element Plug-in for vCenter Server の NetApp Element Configuration 拡張ポイントを使用して、保護ドメインの監視を手動で有効にすることができます。ノードドメインまたはシャーシドメインに基づいて保護ドメインのしきい値を選択できます。Element API または Web UI を使用して、保護ドメインの監視を有効にすることもできます。

Protection Domain レイアウトは、各ノードを特定の保護ドメインに割り当てます。

保護ドメインレベルと呼ばれる 2 つの異なる保護ドメインレイアウトがサポートされます。

  • ノードレベルでは、各ノードが独自の保護ドメインに存在します。

  • シャーシレベルでは、シャーシを共有するノードのみが同じ保護ドメインに存在します。

    • シャーシレベルのレイアウトは、ノードをクラスタに追加するときにハードウェアから自動的に決定されます。

    • 各ノードが別々のシャーシに配置されたクラスタでは、この 2 つのレベルは機能的に同じです。

新しいクラスタの作成時に共有シャーシにあるストレージノードを使用する場合は、保護ドメイン機能を使用してシャーシレベルの障害から保護することを検討してください。

カスタム保護ドメイン

特定のシャーシおよびノードレイアウトに一致するカスタム保護ドメインレイアウトを定義し、各ノードが 1 つだけのカスタム保護ドメインに関連付けられるようにすることができます。デフォルトでは、各ノードは同じデフォルトのカスタム保護ドメインに割り当てられます。

カスタムの保護ドメインが割り当てられていない場合：

  • クラスタ処理には影響はありません。

  • カスタムレベルは、トレラントでも耐障害性でもありません。

クラスタにカスタムの保護ドメインを設定すると、 Element Web UI ダッシュボードに表示される 3 つのレベルで保護が可能です。

  • Not protected ：ストレージクラスタ内のカスタムの保護ドメインのいずれかに障害が発生しても、ストレージクラスタは保護されません。これを修正するには、クラスタにストレージ容量を追加するか、クラスタをデータ損失から保護するようにクラスタのカスタムの保護ドメインを再設定します。

  • フォールトトレランス：カスタムの保護ドメインの 1 つで障害が発生した場合にデータ損失を防ぐために、ストレージクラスタに十分な空き容量が確保されています。

  • 障害への耐障害性：カスタムの保護ドメインの 1 つに障害が発生した場合に自己回復可能な十分な空き容量がストレージクラスタにある。修復プロセスの完了後、他のドメインで障害が発生してもクラスタはデータ損失から保護されます。

複数のカスタム保護ドメインが割り当てられている場合、各サブシステムは重複を個別のカスタム保護ドメインに割り当てます。これができない場合は、重複したデータが別のノードに割り当てられます。各サブシステム（ビン、スライス、プロトコルエンドポイントプロバイダ、アンサンブルなど）は、それぞれ独立して機能します。

Element UI を使用して、を実行できます "カスタムの保護ドメインを設定します"または、次の API メソッドを使用できます。

Double Helix の高可用性

Double Helix データ保護は、システム内のすべてのドライブに、少なくとも 2 つのデータの冗長コピーを分散するレプリケーション方法です。「 RAID レス」アプローチにより、システムは、ストレージシステムのあらゆるレベルで同時に発生する複数の障害を吸収し、迅速に修復することができます。