MetroCluster マニュアル

MetroCluster構成でのHAペアの仕組みを理解する必要があります。

ピア ネットワークにある2つのクラスタは、それぞれがもう一方のクラスタのソース クラスタまたはバックアップ クラスタになることで、双方向のディザスタ リカバリーを実現します。各クラスタは、HAペアとして構成された2つのノードで構成されます。1つのノード構成内で障害が発生した場合やメンテナンスが必要な場合、ストレージ フェイルオーバーによって、そのノードの機能をローカルのHAパートナーに転送することができます。

次の図はMetroCluster FC構成を示しています。HA機能は、HAインターコネクトがクラスタ スイッチで確立されている点を除いて、MetroCluster IP構成と同じです。

ハイアベイラビリティ構成

ONTAPのConfiguration Replication Service（CRS;設定レプリケーション サービス）は、DRパートナーに情報を自動的にレプリケートしてMetroCluster構成を保護します。

CRSは、ローカル ノードの設定をパートナー クラスタのDRパートナーに同期的にレプリケートします。このレプリケーションは、クラスタ ピアリング ネットワーク経由で行われます。

レプリケートされる情報には、クラスタの設定とSVMの設定が含まれます。

ONTAPのConfiguration Replication Service（CRS;設定レプリケーション サービス）は、冗長なデータ サーバー構成とSVMに属するデータ ボリュームのミラーリングを提供します。スイッチオーバーでは、ソースSVMが停止し、サバイバー クラスタ上にあるデスティネーションSVMがアクティブになります。

次の例は、MetroCluster構成のSVMを示しています。「SVM_cluster_A」はソース サイトのSVM、「SVM_cluster_A-mc」はディザスタ リカバリー サイトの同期先のアグリゲートです。

スイッチオーバーが行われると、サバイバー クラスタ上のリモート プレックスがオンラインになり、セカンダリーSVMがデータの提供を開始します。

スイッチオーバー後にリモート プレックスを使用できるかどうかは、MetroCluster構成のタイプによって決まります。

システム管理

SyncMirror機能を使用するミラーされたアグリゲートにはソースとデスティネーションのStorage Virtual Machine（SVM）が所有するボリュームが格納され、データの冗長性が確保されます。データはパートナー クラスタのディスク プールにレプリケートされます。ミラーされていないアグリゲートもサポートされます。

次の表に、スイッチオーバー後のミラーされていないアグリゲートの状態（オンラインまたはオフライン）を示します。

次の図は、ディスク プールがパートナー クラスタ間でミラーされる仕組みを示しています。ローカル プレックス（プール0内）のデータは、リモート プレックス（プール1内）にレプリケートされます。

ストレージ コントローラーの不揮発性メモリー（プラットフォーム モデルに応じてNVRAMまたはNVMEM）は、ローカルHAパートナーにローカルでミラーされ、同時にパートナー サイトのリモート ディザスタ リカバリー（DR）パートナーにリモートでミラーされます。この構成により、ローカルでフェイルオーバーまたはスイッチオーバーが発生しても、不揮発性キャッシュ内のデータを保護することができます。

MetroCluster構成に含まれていないHAペアでは、各ストレージ コントローラーが不揮発性キャッシュ パーティションを2つ（当該コントローラーとそのHAパートナー用に1つずつ）使用します。

4ノードMetroCluster構成では、各ストレージ コントローラーの不揮発性キャッシュが4つのパーティションに分かれています。2ノードMetroCluster構成では、ストレージ コントローラーがHAペアとして構成されないため、HAパートナー パーティションとDR補助パーティションが使用されません。

不揮発性キャッシュには次のデータが格納されます。

たとえば、ノード（node_A_1）のローカル キャッシュは、MetroClusterサイトでローカルおよびリモートの両方でミラーされます。次の図では、node_A_1のローカル キャッシュが、HAパートナー（node_A_2）とDRパートナー（node_B_1）にミラーされています。

次の表は、スイッチオーバー中に実行できるコマンドの一覧です。

ハイアベイラビリティ処理およびMetroCluster処理中、ディスク所有権が一時的に変更されます。どのノードがどのディスクを所有するかをシステムが追跡する仕組みを把握しておくと役に立ちます。

ONTAPは、コントローラー モジュールの固有なシステムID（ノードのNVRAMカードまたはNVMEMボードから取得）を使用して、どのノードがどの特定のディスクを所有するかを識別します。システムのHAまたはDRの状態によっては、ディスク所有権が一時的に変わる場合があります。HAテイクオーバーまたはDRスイッチオーバーによって所有権が変わった場合、HAギブバックまたはDRスイッチバックの終了後に所有権を元に戻すことができるよう、どのノードがディスクの元々の（「ホーム」）所有者であるかが記録されます。ディスク所有権の追跡には次のフィールドが使用されます。

MetroCluster構成でスイッチオーバーが実行された場合、ノードは、パートナー クラスタのノードが元々所有していたアグリゲートの所有権を取得できます。このようなアグリゲートは「クラスタ外アグリゲート」と呼ばれます。クラスタ外アグリゲートはその時点でクラスタに認識されていないアグリゲートで、したがって、DRホーム所有者フィールドにはパートナー クラスタのノードが所有者として表示されます。HAペア内の従来の外部アグリゲートは所有者とホーム所有者の値が異なりますが、クラスタ外アグリゲートは所有者とホーム所有者の値が同じであるため、DRホーム所有者の値で識別できます。

システムの状態が変化するにしたがい、これらのフィールドの値も次の表に示すように変わります。

次の図と表は、物理的にはcluster_Bに配置されているnode_A_1のディスク プール1のディスクについて、所有権が変化する例を示しています。

ミラーされていないアグリゲートが構成に含まれている場合、スイッチオーバー処理後にアクセスに関する問題が発生する可能性があります。

MetroCluster IP構成では、ONTAPメディエーターを使用して障害を検出し、Mediator-Assisted Automatic Unplanned Switchover（MAUSO;メディエーター アシスト自動計画外スイッチオーバー）を実行できます。

ONTAP 9.13.1以降では、MetroCluster IP構成のAUSOステータスのデフォルト値は「auso-on-dr-group」に設定されています。ONTAP 9.12.1以前では、デフォルト値は「auso-on-cluster-disaster」に設定されています。8ノードMetroCluster IP構成では、HAペアの両方のノードに障害が発生した場合に、このオプションによってAUSOがトリガーされます。

metrocluster modify -auto-switchover-failure-domain auso-on-cluster-disasterコマンドを使用して、AUSOドメインを「auso-on-cluster-disaster」ドメインに変更できます。

ONTAPメディエーターは、MetroCluster IPノード用のメールボックスLUNを提供します。これらのLUNは、ONTAP Mediatorとともに、MetroClusterサイトとは物理的に分離されたLinuxホストに配置されます。

MetroClusterノードでは、このメールボックスの情報を使用してMAUSOが必要かどうかを判断します。ストレージ コントローラーの不揮発性メモリー（プラットフォーム モデルに応じてNVRAMまたはNVMEM）がパートナー サイトのリモート ディザスタ リカバリー（DR）パートナーにミラーリングされていない場合、MAUSOは開始されません。

ディザスタ サイトでの問題が解決したら、ストレージ修復フェーズを開始します。

このフェーズでは、RAIDサブシステムがミラーされたアグリゲートを再同期し、WAFLサブシステムが、スイッチオーバー時にプール1プレックスで障害が発生したミラーされたアグリゲートのnvsaveファイルを再実行します。

ソースのストレージ コンポーネントの一部で障害が発生した場合は、該当するレベル（Storage、Sanown、またはRAID）でエラーが報告されます。

エラーが何も報告されなければ、アグリゲートの再同期は成功です。このプロセスは、完了までに数時間かかることがあります。

構成の修復

アグリゲートの同期が完了したら、ルート アグリゲートの修復フェーズを実行します。MetroCluster IP構成では、アグリゲートが修復されたことをこのフェーズで確認します。

構成の修復