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 ）が所有するボリュームが格納され、データの冗長性が確保されます。データはパートナークラスタのディスクプールにレプリケートされます。ミラーされていないアグリゲートもサポートされます

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

*注1 *：MetroCluster IP構成では、スイッチオーバーの完了後に、ミラーされていないアグリゲートを手動でオンラインにすることができます。

の詳細を確認してください MetroCluster FC 構成と IP 構成のスイッチオーバーの違い。

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

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

MetroCluster 構成に含まれない HA ペアでは、各ストレージコントローラに、不揮発性キャッシュパーティションが 2 つ保持されます。 1 つは不揮発性キャッシュパーティションで、もう 1 つは HA パートナー用です。

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

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

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

MetroCluster FC-to IP の移行では、 MetroCluster IP ノードと IP スイッチを既存の MetroCluster FC 構成に追加し、 MetroCluster FC ノードを撤去します。移行プロセスの各ステージでは、 MetroCluster のスイッチオーバー、修復、スイッチバックの各処理のワークフローが異なります。

を参照してください "移行時のスイッチオーバー、修復、スイッチバックの処理"。

MetroCluster のスイッチオーバー後にサバイバーサイトで問題が発生した場合は、ローカルフェイルオーバーによって中断のないノンストップオペレーションが実現します。ただし、冗長構成ではなくなるため、システムはリスクにさらされます。

スイッチオーバー後にローカルフェイルオーバーが発生すると、 1 台のコントローラが MetroCluster 構成内のすべてのストレージシステムにデータを提供します。そのため、リソースの問題が発生する可能性があり、さらに障害が発生した場合にはシステムが中断します。

次の表に、スイッチオーバー時に使用できるコマンドを示します。

MetroCluster IP 構成では、 iSCSI ターゲットとして機能するリモート DR パートナーノードを介してリモートディスクがアクセスされるため、スイッチオーバー処理でリモートノードが停止している間はリモートディスクにアクセスできません。そのため、 MetroCluster FC 構成とは次の点が異なります。

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

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

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

システムの状態が変わると、各フィールドの値も次のように変わります。

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

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

MetroCluster FC 構成では、サイト全体のコントローラ障害が発生した場合に、特定の状況で自動計画外スイッチオーバー（ AUSO ）がトリガーされ、ノンストップオペレーションが実現します。必要に応じて、 AUSO を無効にすることができます。

MetroCluster FC 構成では、次の理由でサイトのすべてのノードに障害が発生した場合に AUSO がトリガーされます。

2 ノード MetroCluster 構成ではローカル HA フェイルオーバーを使用できないため、システムが AUSO を実行してコントローラ障害発生後も処理が継続されるようにします。この機能は、 HA ペアの HA テイクオーバー機能に相当します。2 ノード MetroCluster 構成では、次のシナリオで AUSO がトリガーされます。

AUSO が実行されると、障害ノードの pool0 と pool1 のディスクの所有権が、 disaster recovery （ DR ；ディザスタリカバリ）パートナーに変更されます。この所有権の変更により、スイッチオーバー後にアグリゲートがデグレード状態に陥ることがなくなります。

自動スイッチオーバーが完了したら、修復処理とスイッチバック処理を手動で実行して、コントローラを通常動作に戻す必要があります。

"MetroCluster IP構成での自動計画外スイッチオーバーのONTAPメディエーターによるサポートの詳細"。

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

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

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

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

"構成の修復"

アグリゲートが同期されたら、 CFO アグリゲートとルートアグリゲートをそれぞれの対応する DR パートナーに戻すことにより、コントローラの修復フェーズを開始します。

"構成の修復"

MetroCluster IP 構成では、修復処理を実行する前に、ディザスタサイトのクラスタ内のノードをブートする必要があります。

アグリゲートを再同期するときにリモートの iSCSI ディスクにアクセスできるように、ディザスタサイトのクラスタ内のノードが実行されている必要があります。

ディザスタサイトのノードが実行されていない場合、ディザスタノードは必要なディスク所有権の変更を実行できないため、修復処理が失敗します。

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

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

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

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

"構成の修復"

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

"構成の修復"

ネゴシエートスイッチオーバー（ -forced-on-disaster true オプションを指定せずにスイッチオーバーコマンドを実行）の実施後、システムを通常動作に戻すために必要な手順が自動修復機能によって実行されます。自動修復に対応したシステムでは、スイッチオーバー後に次の状況が発生します。

この機能は、 ONTAP 9.5 以降を実行する環境 MetroCluster IP 構成に対応しています。MetroCluster FC 構成には適用されません。

ONTAP 9.4 以前を実行する MetroCluster IP 構成では、引き続き手動で修復コマンドを実行する必要があります。

ONTAP 9.6 以降を実行する MetroCluster IP 構成では、計画外スイッチオーバー後の自動修復がサポートされます。計画外のスイッチオーバーでは '-forced-on-disaster true オプションを指定して 'switchover コマンドを問題します

MetroCluster FC 構成では、計画外スイッチオーバー後の自動修復がサポートされません。また、 ONTAP 9.5 以前を実行する MetroCluster IP 構成では、計画外スイッチオーバー後に引き続き手動で修復コマンドを実行する必要があります。

ONTAP 9.6 以降を実行するシステムでは、計画外スイッチオーバー後に次の状況が発生します。

何らかの理由で自動修復操作が失敗した場合は、 ONTAP 9.6 より前の ONTAP バージョンで行われているように、「 MetroCluster heal-」 コマンドを手動で問題する必要があります。修復のステータスを監視し、障害の原因を判別するには、 MetroCluster operation show および MetroCluster operation history show -instance コマンドを使用します。