MetroClusterfor clustered Data ONTAP 8.31 NetApp MetroClusterの概要 clustered Data ONTAP 8.3以降、NetApp MetroClusterでは、ミッションクリティカルなアプリケーション向けに、地理的に離れたデータセンターをまたがってデータの可用性を維持できるように

テクニカルレポート

MetroCluster for clustered Data ONTAP 8.3.1 ネットアップ Roy Scaife 2015年 9月 | TR-4375

2 TR-4375 MetroCluster for clustered Data ONTAP 8.3.1 © 2015 NetApp, Inc. All Rights Reserved

バージョン履歴

バージョン日付ドキュメントバージョン履歴

バージョン 1.1 2015年 9月 Roy Scaife：2ノード構成および微修正に関する Clustered Data ONTAP 8.3.1の更新。

バージョン 1.0 2015年 4月 Charlotte Brooks：初版

目次

バージョン履歴 ··········································································································· 2

1 NetApp MetroClusterの概要 ················································································· 4 1.1 機能 ···························································································································· 4 1.2 MetroCluster 8.3.1の新機能 ··························································································· 5 1.3 アーキテクチャおよびサポートされる構成 ··········································································· 5 1.4 MetroClusterレプリケーション ······················································································ 15

2 MetroClusterの初期セットアップ ·········································································· 20 2.1 ハードウェア要件とソフトウェア要件 ·············································································· 20 2.2 インストレーションおよびセットアップ手順の概要 ····························································· 24 2.3 セットアップ後の設定と管理 ·························································································· 26

3 計画的 / 計画外イベントの耐障害性 ········································································· 29 3.1 MetroClusterの計画外処理と計画的処理 ·········································································· 30 3.2 計画的（ネゴシエート）スイッチオーバーの実行 ································································ 33 3.3 スイッチバックの実行··································································································· 38 3.4 強制的スイッチオーバーの実行 ······················································································· 42 3.5 強制的スイッチオーバー後のボリュームの保護 ··································································· 42 3.6 完全なサイト災害を含む強制的スイッチオーバーからのリカバリ ············································ 43

4 相互運用性 ········································································································· 44 4.1 OnCommand System Manager ···················································································· 44 4.2 OnCommand Unified Managerとヘルスモニタ ································································ 45 4.3 AutoSupport ·············································································································· 47 4.4 MetroCluster Tiebreakerソフトウェア ··········································································· 47 4.5 Config Advisor ··········································································································· 48 4.6 Quality of Service (QoS) ····························································································· 49 4.7 SnapMirrorと SnapVault ····························································································· 50 4.8 ボリューム移動 ··········································································································· 50 4.9 Flash Pool ················································································································· 51 4.10 All Flash FAS（AFF） ·································································································· 51


5 MetroClusterへの移行 ························································································ 52 5.1 MetroCluster 8.3.xへのデータのコピー ··········································································· 52 5.2 ハードウェアを再利用する移行シナリオ ··········································································· 54

関連資料 ················································································································· 55

連絡先 ···················································································································· 56

表一覧表 1）必要なハードウェアコンポーネント ···················································································· 11 表 2）推奨されるシェルフ ID ······································································································ 12 表 3）ディスク所有権の変化 ······································································································· 14 表 4）ディスク所有権の変遷例 ···································································································· 14 表 5）計画外処理とMetroClusterの応答およびリカバリ方法 ···························································· 30 表 6）MetroClusterでの計画的処理 ····························································································· 32

図一覧図 1）MetroClusterの基本的な 4ノード構成 ··················································································· 6 図 2）HAパートナーと DRパートナー ··························································································· 7 図 3）MetroCluster 4ノード構成の配線図 ······················································································ 9 図 4）MetroCluster 2ノードファブリック接続構成の配線図 ······························································ 9 図 5）MetroCluster 2ノードブリッジ接続構成 ·············································································· 10 図 6）MetroCluster 2ノード直接接続構成の配線図 ········································································· 10 図 7）MetroCluster 4ノード構成のローカルおよびリモートプールのレイアウト ·································· 12 図 8）スイッチオーバー前後の NVRAMセグメントの割り当て ··························································· 18 図 9）MetroClusterでのプールとシェルフの割り当て ······································································ 23 図 10）クラスタ A：sync_source SVMがロック解除、sync_destination SVMがロック ························ 44 図 11）クラスタ B：sync_source SVMがロック解除、sync_destination SVMがロック ························ 44 図 12）スイッチオーバー後の SVM：すべての SVMがロック解除 ······················································· 45 図 13）OCUMのデバイスおよびリンクの監視 ················································································ 46 図 14）OCUMのレプリケーションの監視 ······················································································ 46 図 15）MetroCluster Tiebreakerソフトウェアの動作 ····································································· 48 図 16）Config Advisorのサンプル出力 ························································································· 49


1 NetApp MetroClusterの概要 clustered Data ONTAP 8.3以降、NetApp MetroClusterでは、ミッションクリティカルなアプリケーション向けに、地理的に離れたデータセンターをまたがってデータの可用性を維持できるようになりました。高可用性機能とディザスタリカバリ（災害復旧）機能を提供する MetroClusterソフトウェアは、clustered Data ONTAPストレージオペレーティングシステム上で動作します。7-Modeバージョン（ファブリック MetroClusterおよびストレッチ MetroCluster）は世界中の数千社もの企業で広く使用されており、データセンターの内外で高可用性、データ損失ゼロ、ノンストップオペレーションを実現しています。本テクニカルレポートでは、clustered Data ONTAP 8.3.xオペレーティングシステム向けのMetroClusterに焦点を当てて説明します。Data ONTAP 7-Modeで動作しているファブリックMetroClusterおよびストレッチMetroClusterは、Data ONTAPバージョン 8.2.xでも引き続きサポートされます。特に明記しないかぎり、本ドキュメントの「MetroCluster」という用語は clustered Data ONTAP 8.3以降のMetroClusterを指します。7-Modeの MetroClusterの詳細については、TR-3548：『MetroCluster Version 8.2.1 Best Practices for Implementation』を参照してください。本ドキュメントは、clustered Data ONTAPのアーキテクチャおよび機能に精通している読者を対象としています。TR-3982：『Clustered Data ONTAP 8.2 概要』で、clustered Data ONTAPの概念の概要が説明されています。

1.1 機能今日のエンタープライズ環境では、IT部門はコスト効率と運用効率を維持しながら、さらに高いサービスレベルを実現することが求められています。データ量が爆発的に増加し、アプリケーションが統合されて共有仮想インフラへと移行される中、ミッションクリティカルなアプリケーションをはじめとする、ビジネスアプリケーションの可用性を継続的に維持することはもはや必要不可欠となっています。データとアプリケーションの統合が進むことは、ストレージインフラ自体が重要な資産となることを意味します。単体でミッションクリティカルと定義できるアプリケーションは 1つも存在しない企業がある一方で、すべての企業にとって、たとえ短時間であってもストレージインフラ全体を失うことは、会社の収益や評判に大きな悪影響を及ぼします。 MetroCluster はストレージインフラの可用性を維持し、次のような重要なメリットをもたらします。 • 障害からの透過的なリカバリ：

− clustered Data ONTAPストレージオペレーティングシステムは、データセンターにおけるノンストップオペレーションを実現します。コンポーネントやノード、ネットワークの障害時にも停止することなく、計画的なハードウェアおよびソフトウェアのアップグレードも可能です。

− MetroClusterを使用すると、ビジネス継続性および継続的可用性が、1つのデータセンター内にとどまらず、第 2のデータセンターまで拡大されます。MetroCluster構成は、自動テイクオーバー（ローカルでの高可用性）と手動スイッチオーバー（データセンターからデータセンター）を実現します。

• アレイベースのクラスタリングと同期ミラーリングを組み合わせて、データ損失ゼロを実現： − データ損失の最大許容量である Recovery Point Objective（RPO;目標復旧時点）ゼロを実

現します。 − 計画的なスイッチオーバーおよびスイッチバックに関して、120秒以下の Recovery Time

Objective（RTO;目標復旧時間）を実現します。RTOは、他のデータセンターへのスイッチオーバー後にストレージおよび関連データを正しい運用状態で使用可能にするまでに必要な最大許容時間です。

http://www.netapp.com/us/media/tr-3548.pdf

http://www.netapp.com/jp/media/tr-3982-ja.pdf


• 管理オーバーヘッドを軽減： − 初期セットアップ後に発生した一方のクラスタでの変更は、2つ目のクラスタに自動的にレ

プリケートされます。 − 管理と運用には NetApp OnCommand® System Manager、OnCommand Unified

Manager、および OnCommand Workflow Automationを使用し、clustered Data ONTAP環境とほぼ同じです。

− アプリケーション、ホスト、およびクライアントに必要な変更はゼロ（または最小限）です。MetroClusterは、あらゆるフロントエンドアプリケーション環境に対して透過的、依存しないように設計されています。スイッチオーバーの前後で接続パスが同じであるため、ほとんどのアプリケーション、ホスト、およびクライアント（NFSおよび SAN）がストレージの再接続や再検出を必要とせずに自動的に再開されます。SMBアプリケーション（共有の継続的可用性を備えた SMB3を含む）は、スイッチオーバーまたはスイッチバック後に再接続する必要があります。これは SMBプロトコルの制限事項です。

• clustered Data ONTAPのフル機能を補完： − MetroClusterは、幅広い SANおよび NASのクライアント / ホストプロトコルに対してマ

ルチプロトコルサポートを提供します。 − テクノロジの更新、容量、およびパフォーマンス管理の処理を無停止で行うことができます。 − Quality of Service（QoS;サービス品質）を実装して重要度の低いワークロードのパフォー

マンスを制限できます。 − データの重複排除および圧縮が、SANと NASの両方の環境で機能します。 − データの管理およびレプリケーションがエンタープライズアプリケーションと統合されます。

• コストの削減： − MetroClusterは、簡単に管理できるアーキテクチャにより、導入コストおよび所有コストを

削減します。MetroClusterの機能は clustered Data ONTAPに直接統合されるため、ライセンスの追加購入やインストールは不要です。

• ディザスタリカバリの簡易化 − サイト全体が失われた場合に、1つのコマンドで数分以内にディザスタリカバリサイトに

サービスを移行できます。複雑なフェイルオーバースクリプトや手順は必要ありません。

1.2 MetroCluster 8.3.1の新機能 MetroCluster 8.3.1では、clustered Data ONTAPの 2ノードアーキテクチャのサポートをはじめとする次の新機能および強化点が追加されています。 • 2ノードのファブリックMetroCluster • 2ノードのストレッチ MetroCluster • PVR承認が不要な All Flash FAS（AFF） • データアグリゲート要件の軽減 • FAS8020プラットフォームの利用率向上

1.3 アーキテクチャおよびサポートされる構成 NetApp MetroClusterは、ストレージインフラおよびミッションクリティカルなビジネスアプリケーションの継続的な保護を必要としている組織向けに設計されています。地理的に離れたクラスタ間でデータを同期的にレプリケートすることにより、管理不要の継続的な可用性を実現し、アレイ内外の障害から保護します。


標準のMetroCluster構成 MetroCluster構成では、最大 200km離れた 2つのクラスタを使用してデータを保護します。それぞれのクラスタが、もう一方のデータおよび構成情報を同期的にミラーします。具体的には、すべての Storage Virtual Machine（SVM）および関連する構成がレプリケートされます。クラスタを独立させることにより、データの分離と論理エラーに対する耐障害性が実現します。一方のサイトで災害が発生した場合、管理者はスイッチオーバーを実行できます。これによってミラーされた SVMがアクティブになり、稼働しているサバイバサイトから、ミラーされたデータの提供が再開されます。clustered Data ONTAP 8.3.xの MetroClusterの 4ノード構成では、2ノードの高可用性（HA）ペアが各サイトに 1つずつ配置されます。その結果、ほとんどの計画的 / 計画外イベントについて、ローカルクラスタ内の単純なフェイルオーバーとギブバックで対応できます。もう一方のサイトへの完全なスイッチオーバーが必要となるのは、災害時またはテスト目的の場合のみです。スイッチオーバーとそれに続くスイッチバック処理では、クラスタワークロード全体がサイト間で転送されます。 MetroClusterの 2ノード構成では、各サイトに 1ノードクラスタがあります。計画的 / 計画外イベントは、スイッチオーバーとスイッチバックを使用して処理されます。スイッチオーバーとそれに続くスイッチバック処理では、クラスタワークロード全体がサイト間で転送されます。図 1は、MetroClusterの基本的な 4ノード構成を示しています。Aと Bの 2つのデータセンターは、最大で 200km離れており、インタースイッチリンク（ISL）が専用のファイバチャネルリンク経由で動作しています。各サイトのクラスタは、HAペアの 2つのノードで構成されています。このレポートでは、次の構成と名称を使用します。 • クラスタ A：ノード A1および A2 • クラスタ B：ノード B1および B2 2つのクラスタおよびサイトは 2つの独立したネットワークによって接続され、レプリケーションが転送されます。クラスタピアリングネットワークは IPネットワークで、サイト間のクラスタ構成情報のレプリケートに使用されます。共有ストレージファブリックは FC接続で、2つのクラスタ間のストレージおよび NVRAMの同期レプリケーションに使用されます。すべてのストレージは、共有ストレージファブリックを介してすべてのコントローラで認識されます。

図 1）MetroClusterの基本的な 4ノード構成

HA関係と DR関係 4ノードのアーキテクチャは、ローカルの HAフェイルオーバーとリモートのディザスタリカバリ（DR）スイッチオーバーの両方を実現します。それぞれのノードには、同じローカルクラスタ内にHAパートナーが存在し、リモートクラスタに DRパートナーが存在します。図 2を参照してください。A1と A2、および B1と B2は、HAパートナーです。A1と B1、および A2と B2は、DRパートナーです。NVRAMは HAと DRの両方のパートナーにレプリケートされます。詳細についてはセクション 1.4を参照してください。ノードの DRパートナーは、MetroClusterの構成時にシステムID（NVRAM ID）に基づいて自動的に選択されます。DRパートナーの選択の詳細については、セクション 2.2を参照してください。


2ノードアーキテクチャのHAフェイルオーバーとリモートDRは、どちらもMetroClusterのスイッチオーバーとスイッチバックの機能を使用して実施されます。それぞれのノードが独立したクラスタであり、HAパートナーとリモートクラスタの DRパートナーの両方の機能を果たします。4ノード構成と同様に、NVRAMはリモートパートナーにレプリケートされます。

図 2）HAパートナーと DRパートナー

HAフェイルオーバーでは、HAペアの一方のノードが HAパートナーのストレージとサービスを一時的にテイクオーバーします。たとえば、ノード A2がノード A1のリソースをテイクオーバーします。テイクオーバーは、ミラーされた NVRAMおよび 2つのノード間のマルチパスストレージによって実現します。フェイルオーバーは、clustered Data ONTAPのアップグレードを無停止で行う場合などに計画的に行う場合と、パニックやハードウェア障害のように計画外で発生する場合があります。ギブバックは逆方向のプロセスです。障害が発生したノードが、テイクオーバーしたノードからリソースを取り戻します。ギブバックは常に計画的に実施されます。フェイルオーバーは常にローカルの HAパートナーに対して行われ、どちらのノードも相互にフェイルオーバーできます。スイッチオーバーでは、一方のクラスタが、自身のワークロードの処理を継続しながら、もう一方のクラスタのストレージとサービスを引き継ぎます。たとえば、サイト Aがサイト Bにスイッチオーバーする場合、クラスタ Aが所有するストレージとサービスをクラスタ Bのノードが一時的に制御します。スイッチオーバー後、クラスタ Aの SVMがオンラインになり、クラスタ B上で動作を継続します。スイッチオーバーは、テストやサイトのメンテナンス目的で事前に決めて実施することも（計画的）、災害によって一方のサイトが使用できなくなった場合に強制的に実行（計画外）することもできます。スイッチバックは、スイッチオーバーされたリソースを稼働しているクラスタから元の場所へ戻し、安定した運用状態をリストアするプロセスです。スイッチバックは 2つのクラスタ間で調整されて実施されるため、常に計画的処理です。どちらのサイトからももう一方のサイトにスイッチオーバーできます。サイトがスイッチオーバー状態のときに障害が続けて発生する可能性もあります。たとえば、クラスタ Bへのスイッチオーバー後に、ノード B1に障害が発生した場合は、B2が自動的にテイクオーバーし、すべてのワークロードに対応します。


アクティブ / アクティブまたはアクティブ / パッシブの構成 MetroClusterは、対称型のスイッチオーバー / スイッチバックに対して自動的に有効になります。つまり、どちらのサイトで災害が発生した場合にも、そのサイトからもう一方のサイトにスイッチオーバーできるということです。したがって、両方のサイトが独立したワークロードをアクティブに処理するアクティブ / アクティブ構成が基本的な構成です。もう 1つの構成であるアクティブ / スタンバイ（アクティブ / パッシブ）構成では、安定した状態では一方のクラスタ（たとえばクラスタA）のみがアプリケーションのワークロードをホストし、サイト Aからサイト Bへの一方向のスイッチオーバーのみが必要となります。クラスタ Bのノードには、独自のミラーされたルートアグリゲートとメタデータボリュームも必要です。これについては「設定レプリケーションサービス」で後述します。あとで要件が変更されてクラスタ Bでワークロードがプロビジョニングされ、その結果アクティブ / パッシブからアクティブ / アクティブに変更されても、MetroCluster構成の変更が必要になることはありません。いずれかのサイトで定義されたワークロード（SVM）はすべて自動的にレプリケートされ、もう一方のサイトで保護されます。サポートされているもう 1つの選択肢は HAペア内のアクティブ / パッシブ構成で、2つのうち 1つのノードだけがワークロードをホストします。これは非常に小規模な構成で、各クラスタに必要なデータアグリゲートは 1つだけです。 MetroClusterでは、スイッチオーバー時にストレージアクセスパスの IDが保持されます。スイッチオーバー後も、論理インターフェイス（LIF）アドレスは維持されます。NFSエクスポートやSMB共有は同じ IPアドレスを使用してアクセスされ、LUNの LUN ID、Worldwide Port Name（WWPN;ワールドワイドポート名）、IPアドレスおよびターゲットポータルグループ（TPG）タグにも変更はありません。このため、フロントエンドのクライアントおよびホストがパスと接続を認識できるよう、フロントエンドネットワークを両方のサイトにまたがって設定する必要があります。レイヤ 2にまたがるイーサネットネットワークと、2つのサイトにまたがる単一の SANファブリックが必要です。

ハードウェア構成 MetroClusterは、各サイトに同一のハードウェアを必要とする、完全冗長構成です。図 3は、4ノード構成の中核となるコンポーネントおよび接続を示しています。現在サポートされているハードウェアコンポーネントの詳細については、Interoperability Matrixを参照してください。 4ノード構成では、クラスタごとに標準的な clustered Data ONTAPクラスタインターコネクトが含まれています。通常これは、2 つのノード間のスイッチを介さない直接接続です。各サイトに 2 つ、計 4つの FCスイッチは、FCイニシエータと FC-VI接続の両方を介してノードに接続し、また、SAS-to-FCブリッジを介してストレージに接続します。これらの接続により、両方のクラスタにあるすべてのノードがすべてのストレージを認識できます。この構成のクラスタからクラスタまでの最大距離は 200kmです。

http://mysupport.netapp.com/matrix


図 3）MetroCluster 4ノード構成の配線図

2ノード構成では、（シングルノード）クラスタごとに、標準のクラスタインターコネクトは必要ありません。2 ノード構成のハードウェア要件は、ストレッチ構成とファブリック構成で異なります。 2ノードのファブリック接続構成では、各サイトに 2つ、計 4つの FCスイッチは、FCイニシエータと FC-VI接続の両方を介してノードに接続し、また、SAS-to-FCブリッジを介してストレージに接続します。これらの接続により、両方のクラスタにあるすべてのノードがすべてのストレージを認識できます。この構成のクラスタからクラスタまでの最大距離は 200kmです。

図 4）MetroCluster 2ノードファブリック接続構成の配線図

2ノードのストレッチブリッジ接続構成の場合は、SAS-to-FCファイバブリッジを使用してノードに接続します。FCスイッチは必要ありません。ストレージへの接続はすべて FCケーブルを使用します。両方のクラスタのすべてのノードがすべてのストレージを認識できます。この構成のクラスタからクラスタまでの距離は最大 500kmです。


図 5）MetroCluster 2ノードブリッジ接続構成

2ノードのストレッチ直接接続構成の場合、FCスイッチや SAS-to-FCブリッジは必要ありません。ストレージへの接続はすべて、光ファイバ SAS延長ケーブルまたは光ファイバパッチパネルケーブルを使用します。両方のクラスタのすべてのノードがすべてのストレージを認識できます。この構成のクラスタからクラスタまでの距離は最大 500kmです。

図 6）MetroCluster 2ノード直接接続構成の配線図


表 1で、個々のコンポーネントの詳細を説明します。

表 1）必要なハードウェアコンポーネント

コンポーネント説明

clustered Data ONTAPクラスタ×2： • 4ノード：コントローラ×4 • 2ノード：コントローラ×2

MetroClusterサイトごとにクラスタが 1つずつ配置されています。両方のクラスタのコントローラは、HAペア（4ノード）内および 2つのサイト間の両方で、すべて同じ FASモデルである必要があります。コントローラごとに、16GBの FC-VIカード（2ポートで、ローカルスイッチごとに 1つずつの接続）1枚、および FCイニシエータが 4つ（8GBまたは16GB：各ローカルスイッチへの接続×2）必要です。 FASコントローラと Vシリーズコントローラがサポートされています。

ファイバチャネルスイッチ（サポートされている BrocadeまたはCiscoモデル）×4： • 2ノードの直接接続またはブ

リッジ接続の構成には不要

4つのスイッチは、2つの独立したファブリックとして構成され、サイト間に専用の ISLを配置することで冗長性が確保されます。ISLはファブリックごとに最低 1つ必要で、ファブリックごとに最大で 4つの ISLを配置してスループットと耐障害性を向上させることができます。複数の ISLファブリックを設定している場合は、トランキングが使用されます。スイッチはすべてネットアップでサポートされているものを使用し、ネットアップから購入する必要があります。

ストレージスタックごとに FC-to-SASブリッジ（ATTO 6500Nファイバブリッジ）×2、ただしストレージアレイ（アレイLUN）が使用されている場合を除く： • 2ノードの直接接続構成には

不要

サポートされているのはSASシェルフのみのため、ブリッジを使用してSASシェルフをローカルのFCスイッチに接続し、SASからFCへプロトコルをブリッジします。ファイバブリッジは、ネットアップのディスクシェルフを接続するためだけに使用され、ストレージアレイはスイッチに直接接続します。

SASディスクシェルフ：サイトごとに最低 4台を推奨。または同等数のストレージアレイディスク（アレイ LUN）

ストレージの構成は、両サイトで同一である必要があります。パフォーマンスと容量を確保し、また、シェルフごとにディスク所有権を割り当てられるように、各サイトに最低でも 4台のシェルフを設置することを強く推奨します。サイトごとにシェルフ 2台という最低条件もサポートされていますが、推奨されません。サポートされているストレージ、サポートされているスタックあたりシェルフ数、およびストレージタイプの混在ルールについては、Interoperability Matrix Tool（IMT）を参照してください。 MetroClusterシステムでは、すべてのノードがすべてのストレージを認識できる必要があります。ルートアグリゲートを含むすべてのアグリゲートは、共有ストレージ上に作成する必要があります。

http://support.netapp.com/matrix/mtx/login.do



ディスク割り当て MetroClusterをインストールする前に、ディスクを適切なプールに割り当てる必要があります。各ノードには、ローカルプール（ノードと同じサイト）とリモートプール（もう一方のサイト）があり、アグリゲートのミラープレックスへのディスク割り当てに使用されます。プールに、またシェルフをまたがってアグリゲートを割り当てる方法については、セクション 2を参照してください。 4ノードMetroCluster構成では、4つのノードそれぞれにローカル（pool0）とリモート（pool1）のプールが 1つずつ、合計 8つのプールがあります（図 7を参照）。クラスタ Aのローカルプールとクラスタ Bのリモートプールはサイト Aにあります。クラスタ Bのローカルプールとクラスタ Aのリモートプールはサイト Bにあります。ディスク所有権は、ノード A1がローカルとリモート両方のプールのすべてのディスクを所有し、他のノードに関しても同様になるように割り当てられます。これを図 7に示します。クラスタ Aが所有するディスクは青で、クラスタ Bが所有するディスクは緑で表示されています。

図 7）MetroCluster 4ノード構成のローカルおよびリモートプールのレイアウト

各サイトにシェルフが 4台ずつという推奨される最小構成では、各シェルフには 1つのプールのディスクだけが搭載されます。これにより、初期セットアップ時にシェルフ単位でディスク所有権を割り当てることができ、障害が発生したディスクの交換時にも所有権が自動で割り当てられます。シェルフが各プール専用でない場合は、初期セットアップ時および障害ディスクの交換時に、手動によるディスク所有権の割り当てが必要です。MetroCluster構成全体（両方のサイト）の各シェルフに一意なシェルフ IDを指定することを推奨します。表 2は、推奨されるシェルフ IDの割り当てを示しています。

表 2）推奨されるシェルフ ID

サイト Aのシェルフ ID 用途サイト Bのシェルフ ID 用途

シェルフ 10～19 A1：Pool0 シェルフ 20～29 A1：Pool1

シェルフ 30～39 A2：Pool0 シェルフ 40～49 A2：Pool1

シェルフ 60～69 B1：Pool1 シェルフ50～59 B1：Pool0

シェルフ 80～89 B2：Pool1 シェルフ70～79 B2：Pool0


ディスクおよびプールの割り当てを表示するには、以下のコマンドを使用します。ストレージスタック 1はサイト Aにあり、ストレージスタック 2はサイト Bにあります。

tme-mcc-A: > disk show -fields home, pool disk home pool ------- ---------- ----- 1.10.0 tme-mcc-A1 Pool0 1.10.1 tme-mcc-A1 Pool0 1.10.2 tme-mcc-A1 Pool0 1.10.3 tme-mcc-A1 Pool0

…. <disks omitted>

1.30.0 tme-mcc-A2 Pool0 1.30.1 tme-mcc-A2 Pool0 1.30.2 tme-mcc-A2 Pool0 1.30.3 tme-mcc-A2 Pool0


1.60.0 tme-mcc-B1 Pool1 1.60.1 tme-mcc-B1 Pool1 1.60.2 tme-mcc-B1 Pool1 1.60.3 tme-mcc-B1 Pool1












ディスク所有権コントローラには、工場出荷時にデフォルトのディスク所有権が割り当てられています。クラスタを作成する前に、この割り当てを確認し、必要なノードとディスクのレイアウトになるよう保守モードで調整し、各ノードに適切な DR パートナーが選択されるようにします。詳細については、セクション 2.2を参照してください。ディスク所有権は、HA フェイルオーバーまたは DR スイッチオーバーの際に一時的に更新されます。clustered Data ONTAPでは、ギブバックまたはスイッチバック後に所有権を正しくリストアできるように、どのコントローラが特定のディスクを所有しているかを追跡し、元の所有情報を保存する必要があります。この追跡を可能にするために、MetroClusterでは、各ディスクの属性として、これまでの ownerフィールドと homeフィールドに加えて新しいフィールド dr-homeが追加されています。dr-homeフィールドはスイッチオーバー後にのみ設定され、パートナークラスタからスイッチオーバーされたアグリゲート内のディスクを識別します。表 3は、さまざまなイベントの際の各フィールドの変化を示しています。


表 3）ディスク所有権の変化

イベントフィールド通常運用（すべ

てのノードが稼働）

ローカル HAフェイルオーバー（4ノード構成）

MetroClusterスイッチオーバー

スイッチオーバー後の HAフェイルオーバー

owner ディスクにアクセスできるノードの名前

ディスクに一時的にアクセスできる HAパートナーの名前

ディスクに一時的にアクセスできるDRパートナーの名前

スイッチオーバー中にディスクに一時的にアクセスできる、DRパートナーの HAパートナーの名前

home クラスタ内の元のディスク所有者の名前

HAペア内の元のディスク所有者の名前

DRパートナーの名前

DRパートナーの名前

dr-home 割り当てなし割り当てなし元の所有ノードの名前

元の所有ノードの名前

表 4は、A1のリモートプール pool1内のあるディスクの所有権の変遷を示しています。このディスクは、物理的にはサイト Bに配置されていますが、通常運用時はノード A1が所有しています。

表 4）ディスク所有権の変遷例

MetroClusterの状態各所有権フィールドの値メモ owner home dr-home

通常運用：すべてのノードが稼働

A1 A1 割り当てなし

ローカル HAフェイルオーバー： A1 A2

A2 A1 注：A2が A1をテイクオーバーし、A1のディスクを一時的に所有します。A1へのギブバック後、ディスク所有権は通常運用時の状態に戻ります。

サイトのスイッチオーバー： A1 / A2 B1 / B2

B1 B1 A1 注：元の所有ノード名が dr-homeに保存されます。この時点で B1が A1のリソースを所有します。サイト Aへのスイッチバック後、ディスク所有権は通常運用時の状態に戻ります。

サイトのスイッチオーバー後に HAテイクオーバー： A1 / A2 B1 / B2 B1 B2

B2 B1 A1 注：唯一稼働しているノードであるため、この時点で B2は A1のリソースを所有します。このシナリオからのリカバリは、2段階のプロセスです。 1. B2が B1にギブバックし、ownerを

B1にリストアします（サイトのスイッチオーバーと同じ状態）。

2. サイト Bがサイト Aにスイッチバックします。所有権が通常運用時の状態に戻り、dr-homeは再び値が割り当てられていない状態になります。


1.4 MetroClusterレプリケーション同期レプリケーションは、2つのサイト間でデータの RPOゼロのソリューションを提供するためのメカニズムです。同期レプリケーションを使用すると、一方のサイトで行われた変更は、もう一方のサイトに自動的に伝播されます。MetroCluster構成では、NetApp SyncMirror®を使用したストレージレプリケーション、NVRAMレプリケーション、クラスタ構成レプリケーションの 3レベルのレプリケーションを提供することにより、同期レプリケーションを実現します。

SyncMirrorのストレージレプリケーション clustered Data ONTAPシステムは、アグリゲートからプロビジョニングされた NetApp FlexVol®ボリュームにデータを格納します。各アグリゲートには、NetApp WAFL®（Write Anywhere File Layout）ファイルシステムが含まれています。MetroClusterを使用しない構成では、各アグリゲートのディスクは単一のグループ、つまりプレックスで構成されます。プレックスは、コントローラに接続されているローカルストレージに存在します。MetroCluster構成では、各アグリゲートは物理的に離れた場所にある 2つのプレックス（ローカルプレックスとリモートプレックス）で構成されます。MetroCluster構成では、すべてのストレージが共有され、すべてのコントローラから認識できます。ローカルプレックスにはローカルプール（pool0）のディスクのみが含まれ、リモートプレックスにはリモートプールのディスクのみが含まれている必要があります。ローカルプレックスは常に plex0です。リモートプレックスには、リモートであることを示すために 0以外の番号が付けられます（plex1、plex2など）。 MetroClusterで作成できるのはミラーされたアグリゲートのみで、ミラーされていないアグリゲートはサポートされていません。そのため、MetroClusterの構成後にアグリゲートを作成する際は、 –mirror trueフラグを指定する必要があります。このフラグを指定しないと作成コマンドは失敗します。-diskcountパラメータで指定したディスク数は、自動的に半分になります。たとえば、使用可能なディスクを 6本含むアグリゲートを作成するには、ディスク数として 12を指定して、ローカルプレックスにローカルプールから 6本のディスクが割り当てられ、リモートプレックスにリモートプールから 6本のディスクが割り当てられるようにする必要があります。アグリゲートにディスクを追加する際も同じです。容量として必要なディスク数の倍の数を指定する必要があります。次の例は、アグリゲートへのディスクの割り当て状況を示しています。各ノードには、ルートアグリゲートとデータアグリゲートが 1つずつあります。ルートアグリゲートにはそれぞれ 8本のドライブが含まれていて、そのうち 4本はローカルプレックスに、4本はリモートプレックスにあります。したがって、アグリゲートの使用可能容量は 4本のドライブです。同様に、データアグリゲートにはそれぞれ 10本のドライブ（ローカル 5本とリモート 5本）が含まれています。

tme-mcc-A::> storage aggr show -fields diskcount, plexes aggregate diskcount plexes --------------------- --------- --------------------------------------------------------- aggr0_tme_A1 8 /aggr0_tme_mcc_A1/plex0,/aggr0_tme_mcc_A1/plex1 aggr0_tme_A2 8 /aggr0_tme_mcc_A2/plex0,/aggr0_tme_mcc_A2/plex1 aggr1_tme_A1 10 /aggr1_tme_mcc_A1/plex0,/aggr1_tme_mcc_A1/plex1 aggr1_tme_A2 10 /aggr1_tme_mcc_A2/plex0,/aggr1_tme_mcc_A2/plex1 tme-mcc-B::> storage aggr show -fields diskcount, plexes aggregate diskcount plexes --------------------- --------- --------------------------------------------------------- aggr0_tme_B1 8 /aggr0_tme_mcc_B1/plex0,/aggr0_tme_mcc_B1/plex1 aggr0_tme_B2 8 /aggr0_tme_mcc_B2/plex0,/aggr0_tme_mcc_B2/plex1 aggr1_tme_B1 10 /aggr1_tme_mcc_B1/plex0,/aggr1_tme_mcc_B1/plex1 aggr1_tme_B2 10 /aggr1_tme_mcc_B2/plex0,/aggr1_tme_mcc_B2/plex1

MetroClusterの通常運用時は、両方のプレックスが RAIDレベルで同時に更新されます。クライアントからかホストからか、I/Oからかクラスタメタデータからかに関係なく、すべての書き込みで物理的書き込み処理が 2つ生成されます。1つはローカルプレックスに対して、もう 1つはリモートプレックスに対してで、書き込みには 2つのクラスタ間の ISL接続が使用されます。読み取りは、デフォルトではローカルプレックスから行われます。


プレックスの読み取り動作デフォルトでは、読み取りはすべてローカルプレックスから行われます。ローカルプレックスとリモートプレックスで交互に読み取り処理を行うように、RAIDオプションを設定できます。特にサイト間の距離が短い場合、一部のワークロードでは両方のプレックスから読み取った方がパフォーマンスが向上する可能性があります。この RAIDオプションは無停止で変更でき、アプリケーションのI/Oには影響しません。2つのプレックスから交互に読み取るようにオプションを設定するには、HAペアのノードごとに次のコマンドを使用します。

storage raid-options modify -node <node-name> -name raid.mirror_read_plex_pref -value alternate

オプションの設定をデフォルト値に戻すには、同じコマンドで–value localを指定します。このオプションは、HAペアの両方のノードで同じ設定にすることを推奨します。ただし、ノードごとに読み取り動作が違う方がパフォーマンスが向上するようなワークロード環境も考えられます。ノード間で設定が違う場合、HAフェイルオーバー時にもう一方のノードに設定は伝播されません。

アグリゲート Snapshotコピー自動のアグリゲート Snapshot®コピーが作成され、デフォルトでは、アグリゲート容量の 5%が、Snapshotコピー用に予約されています。これらの Snapshotコピーは、必要なときにアグリゲートを再同期するためのベースラインとして使用されます。一方のプレックスが使用できなくなった場合（シェルフやストレージアレイの障害などのため）、障害が発生したプレックスがリストアされるまでは、影響を受けていないプレックスがデータの提供を継続します。障害が発生したプレックスが修復されると、プレックスが自動的に再同期され、両方のプレックスの整合性が確保されます。再同期のタイプは自動的に決定され、実行されます。両方のプレックスで同じアグリゲート Snapshotコピーを共有している場合は、この Snapshotコピーをベースとして部分的な再同期が実行されます。プレックス間で Snapshotコピーが共有されていない場合は、完全な再同期が実行されます。

NVRAMキャッシュミラーリング clustered Data ONTAPの HAペアでは、HAインターコネクトを使用して、各ノードの NVRAMがもう一方のノードにミラーされます。NVRAMは、各ノードの NVRAM用に 1つずつ、2つのセグメントに分割されます。加えてMetroClusterでもミラーリングが提供され、各ノードにはもう一方のサイトに DRパートナーノードがあり、NVRAMは ISL接続を介して DRパートナーにミラーされます。つまり、4ノード構成では、各ノードの NVRAMは 2回（HAパートナーと DRパートナーに対して）ミラーされ、各ノードの NVRAMは 4つのセグメントに分割されます。書き込みは、ディスクにコミットされる前に NVRAMに保存されます。すべての NVRAMセグメントが更新された時点で、実行元のホストまたはアプリケーションに書き込み処理の完了が通知されます。4ノード構成では、これにはローカルの NVRAM、HAパートナーの NVRAM、および DRパートナーの NVRAMが含まれます。DRパートナーの NVRAMへの更新は、ISLを介して FC-VI接続経由で送信されます。FC-VIトラフィックは、スイッチ QoSによってストレージレプリケーションよりも優先されます。ISLのレイテンシが増加すると、DRパートナーの NVRAMへの書き込みが確認されるまでの時間が長くなるため、書き込みパフォーマンスに影響が出る可能性があります。ISLがすべて停止した場合や、リモートノードが一定時間反応しない場合、書き込みは完了として通知されるため、一時的にサイトが分離された場合でもローカルの処理を継続できます。少なくとも 1つのISLが使用可能になると、リモートの NVRAMミラーは自動的に再同期されます。すべての ISLで障害が発生した場合の詳細については、セクション 3.1を参照してください。 NVRAMトランザクションは、少なくとも 10秒に 1回、整合ポイントを使用してディスクにコミットされます。コントローラのブート時、WAFLでは常にディスク上の最新の整合ポイントが使用されます。これにより、停電やシステム障害のあとに時間をかけてファイルシステムをチェックする必要がなくなります。最新の整合ポイントのあとに発生したデータ入力 / 出力要求が失われないように、ストレージシステムではバッテリでバックアップされた NVRAMを使用します。テイクオーバーまたはスイッチオーバーが発生すると、コミットされていないトランザクションがミラーNVRAMから再生され、データ損失が回避されます。


metrocluster interconnect showコマンドを実行すると、各ノードの NVRAMミラーリングパートナーが表示されます。次の出力は、4ノード構成のクラスタ Bのものです。 • ノード B1：HAパートナーは B2、DRパートナーは A1。 • ノード B2：HAパートナーは B1、DRパートナーは A2。 tme-mcc-B::> metrocluster interconnect show Mirror Mirror Partner Admin Oper Node Partner Name Type Status Status Adapter Type Status ---- ------------ ------- -------- ------- ----------- ------ ------ tme-mcc-B1 tme-mcc-B2 HA enabled online cxgb3_0 iWARP Up cxgb3_0 iWARP Up tme-mcc-A1 DR enabled online fcvi_device_0 FC-VI Up fcvi_device_1 FC-VI Up tme-mcc-B2 tme-mcc-B1 HA enabled online cxgb3_0 iWARP Up cxgb3_0 iWARP Up tme-mcc-A2 DR enabled online fcvi_device_0 FC-VI Up fcvi_device_1 FC-VI Up

クラスタ Aから実行したコマンドの出力では以下が表示されます。 • ノード A1：HAパートナーは A2、DRパートナーは B1。 • ノード A2：HAパートナーは A1、DRパートナーは B2。 MetroClusterのインストール時に HAの状態をmccに設定すると、NVRAMは必要な 4つのセグメントに分割されます（『インストレーションおよび構成ガイド』の説明に従って ha-config modify controllerコマンドと ha-config modify chassisコマンドを使用）。4ノード構成では、この変数は mccに設定する必要があります。2ノード構成では、この変数は mcc-2nに設定する必要があります。通常運用時は、NVRAMは以下のように割り当てられます。 • セグメント 1：ノード自身の NVRAM • セグメント 2：ノードの HAパートナーの NVRAM • セグメント 3：ノードの DRパートナーの NVRAM • セグメント 4：未使用 4つ目のセグメントは、スイッチオーバー時に使用されます。たとえば、図 8は、4つのノードにおけるスイッチオーバー前後の NVRAMのレイアウトを示しています。スイッチオーバー後、A1および A2の NVRAMのコミットされていないトランザクションはクラスタ Bで再生されます。ローカルの NVRAMセクションが拡張されて再生されたセクションが追加され、その結果、サイト Bの各ノードにすべてのアグリゲートの NVRAMトランザクションログが記録されます。


図 8）スイッチオーバー前後の NVRAMセグメントの割り当て

設定レプリケーションサービス MetroCluster構成は、2つの clustered Data ONTAPクラスタから成ります。各クラスタは、レプリケートされたデータベース（RDB）と呼ばれる内部の耐障害性に優れたデータ構造に、自身のメタデータ（構成情報）を保管します。それぞれのクラスタが専用の RDBを使用するため、エラーが切り分けられ、クラスタからクラスタへ伝播することがありません。スイッチオーバーが発生すると、ストレージサービスが中断しないよう、停止したクラスタのメタデータオブジェクト（SVMおよび関連するプロトコル情報、ボリューム、LUN、エクスポートポリシーなど）が稼働しているクラスタでアクティブになります。つまり、これらのオブジェクトが所有者であるクラスタからもう一方のクラスタに事前に転送済みで、必要に応じていつでもアクティブ化できる状態になっている必要があります。新規および変更された設定オブジェクトを一方のクラスタの RDBからもう一方の RDBへ転送し、この情報を同期するメカニズムが必要です。このメカニズムは次の 3つのコンポーネントで構成されます。 • クラスタピアリング：インタークラスタ LIFを搭載した clustered Data ONTAPnoSnapMirror®

および SnapVault®で使用されているものと同じピアリング方法とインタークラスタ LIFを使用します。2つのクラスタは、設定レプリケーションネットワークと呼ばれるお客様が用意したTCP/IP接続で接続されます。信頼性を確保するために、ノードごとに 2つのインタークラスタLIFを使用して冗長な IP接続を設定することを推奨します。

• 設定レプリケーションサービス（CRS）：このサービスは各クラスタで実行されます。CRS は、必要なメタデータオブジェクトを所有者側のクラスタからレプリケートして、もう一方のクラスタの RDBに格納します。


• メタデータボリューム（MDV）：クラスタメタデータ情報用のステージングボリュームです。MetroClusterの設定時に、10GBのボリュームが 2個、各クラスタ上に作成されます。各ボリュームは、別々のルート以外のアグリゲートに作成する必要があります。したがって、MetroClusterを設定する前に、各クラスタ上に少なくとも 2つのデータアグリゲートが存在する必要があります。耐障害性を確保するために、データアグリゲートはそれぞれ別々のノードに配置することを推奨します。

一方のクラスタの設定に対する変更（新しい SVMや新しい LIFの作成、既存の SVMでのボリュームまたは LUNのプロビジョニングなど）が自動的にもう一方のクラスタに伝播されることは、MetroClusterの中核的な機能です。これにより、データや設定をまったく失わずにスイッチオーバーを実施できます。更新は自動で行われるため、特定のMetroCluster構成を対象とした管理操作はほとんど必要ありません。ワークロードが追加されても自動同期による保護を継続するために管理者による処理は必要なく、新しく追加または変更されたストレージリソースは自動的に保護されます。オブジェクトが作成または更新されると、このトランザクションに関連する情報が、更新を実行しているクラスタ上の MDVにログとして記録されます。変更はロギングが完了した時点でローカルの RDBにコミットされ、設定レプリケーションネットワーク経由でもう一方のクラスタの RDBにほぼ同時に伝播されます。設定レプリケーションネットワークの一時的エラーにより変更が伝播できない場合、接続のリストア後にログに記録されたトランザクションがMDVから再生されて、変更が自動的にもう一方のクラスタに送信されます。このキャッチアップ処理は自動で行われます。ネットワークの停止中に強制スイッチオーバーが必要となり、伝播されていない RDB更新がある場合、サバイバサイトにあるMDVのミラーコピーから更新処理が実行されます。クラスタ設定ネットワークの耐障害性を確保するために、冗長なネットワークを推奨します。 MDVにはシステムによって名前が割り当てられ、以下の例に示すように各クラスタ上で認識されます。コマンドがクラスタ Aから実行されたため、最初の 2つのボリュームがローカルの MDVで、オンラインです。次の 2つの MDVはクラスタ Bに所属し（ホストしているアグリゲートに注目）、スイッチオーバーが実行されないかぎりオフラインです。

tme-mcc-A::> volume show -volume MDV* Vserver Volume Aggregate State Type Size Available Used% --------- ------------ ------------ ---------- ---- ---------- ---------- ----- tme-mcc-A MDV_CRS_cd7628c7f1cc11e3840800a0985522b8_A aggr1_tme_A1 online RW 10GB 9.50GB 5% tme-mcc-A MDV_CRS_cd7628c7f1cc11e3840800a0985522b8_B aggr1_tme_A2 online RW 10GB 9.50GB 5% tme-mcc-A MDV_CRS_e8fef00df27311e387ad00a0985466e6_A aggr1_tme_B1 - RW - - - tme-mcc-A MDV_CRS_e8fef00df27311e387ad00a0985466e6_B aggr1_tme_B2 - RW - - -

作成されたオブジェクトは、CRSを使用してクラスタピアリングネットワーク経由でもう一方のクラスタに自動的に伝播されます。ただし、ジョブスケジュール（たとえば Snapshotポリシーと関連付けるため）は伝播されません。以下の例は、MetroCluster構成でジョブスケジュールを作成または変更したときに表示されるメッセージを示しています。同じジョブスケジュールコマンドを、もう一方のクラスタでも実行する必要があります。どちらかのクラスタに存在しないスケジュールをSnapshotポリシーに関連付け、そのポリシーをボリュームに適用すると、レプリケーションは同期状態でなくなります。

tme-mcc-A::> job schedule cron create -name Monday -hour 8,10 -minute 00 -dayofweek Monday Warning: Because this is a MetroCluster configuration, an additional step is required. To complete applying the changes for schedule "Monday", execute the same command on the remote cluster.


2 MetroClusterの初期セットアップ MetroClusterは、ハードウェアとソフトウェアを組み合わせたソリューションです。共有ストレージファブリックおよびサイト間リンクを作成するために、特定のハードウェアを必要とします。サポートされているハードウェアについては、NetApp Interoperability Matrixを参照してください。ソフトウェアとしての MetroClusterは、clustered Data ONTAPオペレーティングシステムに完全に統合されています。追加のツールやインターフェイスは必要ありません。MetroCluster関係を一度確立すると、データおよび設定はサイト間で自動的かつ継続的にレプリケートされるため、新しくプロビジョニングしたストレージのレプリケーションを手動で設定する必要はありません。この機能により、必要な管理作業が簡素化されるだけでなく、重要なワークロード用のストレージをレプリケートし忘れる可能性もなくなります。 MetroCluster構成のセットアップ手順は、次の 2つの製品ドキュメントに記載されています。 • 『MetroClusterインストレーションおよび構成ガイド』には、MetroClusterのコンポーネン

トを設定するためのワークシートと詳細な手順が記載されています。このガイドの手順に従い、ベストプラクティスとして、ガイドと同じ命名規則およびポート割り当てを使用してください。

• あるいは、Brocade FCスイッチと NetApp FASシェルフのみ（アレイ LUNなし）を搭載し、構成済みの状態でハードウェアが出荷されている場合は、『MetroClusterインストレーションエクスプレスガイド』を使用できます。エクスプレスガイドには、最小限の情報と一部のオプションが記載されています。確信がない場合は、『MetroClusterインストレーションおよび構成ガイド』を使用してください。

2.1 ハードウェア要件とソフトウェア要件

clustered Data ONTAPの要件以下の情報は、4ノード MetroCluster構成に該当します。 • 各サイトに 2つずつ、4つのノードが必要です。4つのノードをまとめて DRグループと呼びま

す。4つのノードはすべて同じ FASモデルまたは Vシリーズモデルである必要があります（FAS8020×4台、FAS8060×4台など）。FASコントローラと Vシリーズコントローラを同じ MetroCluster DRグループ内に共存させることはできません。

• 追加または専用のライセンスは不要です。SyncMirrorを含む MetroCluster機能は、clustered Data ONTAPの基本ライセンスに含まれています。プロトコルおよびその他の機能（SnapMirrorなど）をクラスタで使用する場合はライセンスが必要です。ライセンスは両方のサイトで同じ設定にする必要があります。たとえば、SMBを使用する場合は、両方のクラスタでライセンスを設定する必要があります。両方のサイトで同じライセンスが設定されていないとスイッチオーバーが機能しません。

• すべてのノードに、同じノードロック式ライセンスが設定されている必要があります。 • Infinite Volumeは、MetroCluster構成ではサポートされません。 • アドバンストディスクパーティショニング（ルートアグリゲートまたは Flash Pool™アグリ

ゲート用）はサポートされません。 • NetApp Storage Encryption（NSE）ドライブは、MetroCluster 構成ではサポートされません。

clustered Data ONTAPシステムは、FDEドライブを使用する NetApp Eシリーズのストレージアレイに接続でき、ルートアグリゲートを暗号化ドライブに配置できます。この構成をサポートするシステムのリストは、IMTを参照してください。

以下の情報は、2ノード MetroCluster構成に該当します。 • 各サイトに 1つずつ、2つのノードが必要です。2つのノードをまとめて HAペアまたは DRグ

ループと呼びます。両方のノードが同じ FASモデルまたは Vシリーズモデルである必要があります（FAS8020×2台、FAS8060×4台など）。FASコントローラと Vシリーズコントローラを同じMetroCluster DRグループ内に共存させることはできません。

http://mysupport.netapp.com/matrix/


• 追加または専用のライセンスは不要です。SyncMirrorを含む MetroCluster機能は、clustered Data ONTAPの基本ライセンスに含まれています。プロトコルおよびその他の機能（SnapMirrorなど）をクラスタで使用する場合はライセンスが必要です。ライセンスは両方のサイトで同じ設定にする必要があります。たとえば、SMBを使用する場合は、両方のクラスタでライセンスを設定する必要があります。両方のサイトで同じライセンスが設定されていないとスイッチオーバーが機能しません。

• すべてのノードに、同じノードロック式ライセンスが設定されている必要があります。 • Infinite Volumeは、MetroCluster構成ではサポートされません。 • アドバンストディスクパーティショニング（ルートアグリゲートまたは Flash Poolアグリゲ

ート用）はサポートされません。 • NSEドライブは、MetroCluster構成ではサポートされません。clustered Data ONTAPシステ

ムは、FDEドライブを使用する NetApp Eシリーズのストレージアレイに接続でき、ルートアグリゲートを暗号化ドライブに配置できます。この構成をサポートするシステムのリストは、IMTを参照してください。

アレイ LUNを使用するMetroCluster構成の要件アレイ LUNを使用するMetroCluster構成をセットアップする際の要件は次のとおりです。 • MetroCluster構成用にサポートされていることが Interoperability Matrixに記載されているプ

ラットフォームとストレージを使用する必要があります。注： Interoperability Matrixには、アレイ LUNを使用する MetroCluster構成の詳細が記載され

ています。サポートされているストレージアレイおよびスイッチや、ネットアップコントローラ、アレイ LUNとの連携がサポートされている clustered Data ONTAPのバージョンに関する情報が含まれています。Interoperability Matrixには、アレイ LUNを使用するMetroCluster構成の要件および制限に関して信頼できる情報が掲載されています。「V-Series and FlexArray Virtualization for Fabric MetroCluster」をストレージソリューションとして選択してください。

• 同じMetroCluster構成内の clustered Data ONTAPシステムはすべて同じモデルである必要があります。

• 複数の FCイニシエータポートを同じターゲットポートに接続することは、MetroClusterではサポートされていません。同様に、複数のターゲットポートを同じ FCイニシエータポートに接続することもサポートされていません。

• 『FlexArray仮想化実装ガイド（サードパーティ製ストレージ）』および『FlexArray仮想化実装ガイド（Eシリーズストレージ）』に、サポートされているストレージアレイファミリーに関する詳細が記載されています。MetroCluster構成内のストレージアレイは対称に配置する必要があります。 − つまり、2つのストレージアレイは同じベンダーファミリーに属し、同じバージョンのファー

ムウェアがインストールされている必要があります。 − アレイ LUNは 2セット必要です。1つ目はローカルストレージアレイ上のアグリゲート用、

もう 1つはアグリゲートのミラー用にリモートストレージアレイに配置します。アグリゲートをミラーするには、アレイ LUNが同じサイズである必要があります。

− ミラーされたストレージに使用するディスクタイプ（SATA、SSD、SASなど）は、両方のストレージアレイで同じである必要があります。

− RAIDタイプや階層化など、ストレージアレイを設定するパラメータは、両方のサイトで同じである必要があります。

− 事実上、アレイ LUNを使用するMetroCluster構成は、サイト間で完全に対称である必要があります。


FCスイッチの要件 FCスイッチを使用するMetroCluster構成をセットアップする際の要件は次のとおりです。 • MetroCluster構成用にサポートされていることが Interoperability Matrixで確認されているス

イッチおよびスイッチファームウェアを使用する必要があります。 • 2ノードおよび 4ノードのファブリック構成では、各ファブリックに 2つずつ、合計 4つのスイッ

チが必要です。2ノードのブリッジ接続および直接接続の構成では、FCスイッチは不要です。 • 同じ構成内のスイッチはすべて同じベンダーの同じモデルを使用し、同じポート数でライセンス

が設定されている必要があります。 • スイッチはすべてネットアップから購入し、MetroCluster構成専用にする必要があります。 • ホスト / アプリケーショントラフィックでは、MetroClusterに使用されているスイッチは共有

できません。 • デバイスやパスに障害が発生した場合でも冗長性を確保できるように、各 clustered Data

ONTAPシステムを、冗長コンポーネントを使用してストレージに接続する必要があります。 • clustered Data ONTAPでは、ファブリック 1つにつき 1～4個の ISLをサポートしています。

ファブリック 1つにつき複数の ISLが存在する場合は、トランキングが使用されます。xWDMベンダーが FCスイッチでのトランキングをサポートしていることを確認してください。単一のISL接続の場合は、トランキングは不要です。ISLは 2つ以上使用することを推奨します。

• ファブリック 1つあたりの ISLの数にかかわらず、インオーダー配信がデフォルトであり、推奨される設定です。アウトオブオーダー配信はサポートされていません。注：基本的なスイッチ構成、ISLの設定、および FC-VIの構成の詳細については、『MetroCluster

インストレーションおよび構成ガイド』を参照してください。

ゾーニングの要件 FCスイッチ用にゾーニングを設定する際の要件は次のとおりです。 • MetroCluster構成では、シングルイニシエータからシングルターゲットのゾーニングを使用す

る必要があります。シングルイニシエータからシングルターゲットのゾーニングでは、各ゾーンが単一の FCイニシエータポートに制限されます。

• FC-VIポートは、仮想WWPNを使用してファブリック全体でエンドツーエンドにゾーニングする必要があります。FC-VIカードの Aポートと Bポートは別々のゾーンに配置する必要があります。

• 複数のイニシエータポートを単一のターゲットポートで共有することはサポートされていません。同様に、複数のターゲットポートを単一のイニシエータポートで共有することもサポートされていません。

SyncMirrorおよびストレージの要件 SyncMirrorストレージの要件は次のとおりです。 • 2つのサイト間でディスク構成が同じである必要があります。これには NetApp Flash Poolの

構成も含まれます。あるノードのワークロードに Flash Poolが必要な場合、Flash Poolアグリゲートごとに、ミラープレックスに同じ容量の Flash Poolインテリジェントキャッシングが必要です。

• 4台すべてのコントローラのルートアグリゲートを含めて、MetroCluster構成内のすべてのアグリゲートをミラーする必要があります。

• RAID 4および NetApp RAID DP®テクノロジはいずれもルートアグリゲートおよびデータアグリゲートに対応しています。


1サイトにつき最低 4台のシェルフを配置することを推奨します。1つのサイトに FASシェルフが 4台あると、各プール（各ノードのローカルとリモート）に専用のシェルフを配置できるため、ディスクをシェルフ単位で各ノードに割り当てることができます。将来ディスクを増設する場合は、プールとシェルフの組み合わせが維持されるように計画する必要があります。サイトごとのシェルフ数を4台より少なくする配置もサポートされていますが、その場合はディスクの割り当てが複雑になるだけでなく、使用可能なストレージの容量も大幅に制限されます。

図 9は、プールとシェルフの割り当てのレイアウト例です。シェルフ IDは、表 2）推奨されるシェルフ ID

の推奨に従って割り当てられています。シェルフごとにプールを分けるレイアウトは必須ではありません。ソフトウェアのディスク所有権を使用すれば、任意のシェルフのディスクを任意のノードに割り当てることができます。同じシェルフ上のディスクを複数のノードが所有している場合は、シェルフ単位のディスクの自動割り当ては無効になり、シェルフに障害が発生した場合の影響範囲も拡大します。

図 9）MetroClusterでのプールとシェルフの割り当て

ファイバブリッジ接続されたスタックに SSDが含まれている場合は、Interoperability Matrix Tool（IMT）で、サポートされているスタックの最大シェルフ数を確認してください。単一のディスクスタックには最大で 48本の SSDを搭載でき、SSDはどのシェルフにでも分散させることができます。ただし、同じシェルフ内では SSDと HDDを混在させず、SSDのみのシェルフを構成することを推奨します。さらに、パフォーマンスを最適にするために、SSDシェルフは専用のスタック（HDDシェルフなし）に配置するか、SSDと HDDが混在したスタックの一番上または一番下に配置して、SSDシェルフをファイバブリッジに直接接続することを推奨します。この場合、SSDシェルフには複数のノードのプールが含まれてる可能性が高いため、ディスク所有権は手動で割り当てる必要があります。すべて SSDのアグリゲートの場合、スタックに含まれるのは SSDのみとし、スタック内のSSDシェルフは 2台以下にする必要があります。パフォーマンスが最適化されるのは、スタックにつき SSDシェルフの 1台の構成です。最初の設置後にストレージを追加する場合は、一度に 1シェルフずつ各クラスタに追加できます。複数のシェルフを追加する必要はありません。ただし、ミラーリングの対称状態を保持するために、同じストレージを両方のサイトに追加する必要があります。

ケーブル接続とスイッチ構成のベストプラクティスネットアップサポートサイトで入手できるスイッチ構成ファイルを使用することを強く推奨します。構成ファイルを使用する手順は、MetroClusterのドキュメント、『MetroClusterインストレーションおよび構成ガイド』の「構成ファイルの実行による FCスイッチの設定」を参照してください。構成ファイルを使用すると、『MetroClusterインストレーションおよび構成ガイド』の「FCスイッチのポート割り当ての確認」の表のようにポートが設定されます。推奨される割り当てでは、4つのポートが ISL用に予約されています。Brocade 6505を除くすべてのサポートされているスイッチで、4つのポートがストレージスタック用に割り当てられます。6505では、2つのポートがストレージスタック用に割り当てられます。これは、デフォルトではスイッチ上で有効になっているポートは 12個だけで、そのうち 1つがポートオンデマンド（PoD）に設定されているためです。推奨されるポート割り当てを使用しない場合や、標準構成よりも多くのストレージシェルフを設置する場合は、インストレーションガイドに従ってスイッチを手動で構成する必要があります。



https://library.netapp.com/documentation/docweb/index.html?productID=61999&language=ja


FC-VI-Aポートはすべて一方のファブリックにケーブル接続し、FC-VI-Bポートはすべてもう一方のファブリックにケーブル接続する必要があります。推奨されるポート割り当てを使用していない場合であっても、ケーブル接続は必ずこの方法で行ってください。コントローラ上の各ファブリックへの 2つの接続で別々の ASICが使用されるように、各コントローラの FCイニシエータを接続します。例を以下に示します。 0a/0c：ファブリック1、ポート1およびポート2 0b/0d：ファブリック2、ポート1およびポート2 注： Brocade 6505 スイッチ用に配布されているリファレンス構成ファイルでは、ポート 8、9、10、

11を ISL用に割り当て、2つのポートをストレージスタック用に割り当てます。1つのサイトに 3つ以上のスタックが必要で、ファブリック 1つにつき使用する ISLが 1つまたは 2つだけの場合は、ポート 10と 11を ISL用に使用し、ポート 8と 9を追加の 2つのストレージスタック用に空けておくことができます。最初の 2つのストレージスタックは、すでにポート 6と 7に接続されています。提供されている構成ファイルではポート 8と 11が ISL用に予約されるため、これには手動によるスイッチ構成が必要です。8と 9をストレージスタック用に使用することにより、追加のストレージをサポートするための追加の PoD（12ポート）ライセンスは不要になります。すべての ISLポートと 3つ以上のスタックが必要な場合は、追加の PoDライセンスが必要です。6505のオプションの詳細については、https://kb.netapp.com/support/index?page=content&actp=LIST&id=1015278 を参照してください。

2.2 インストレーションおよびセットアップ手順の概要『MetroClusterインストレーションおよび構成ガイド』では、MetroClusterのコンポーネントを設定するためのワークシートと手順が提供されています。参考のために、MetroCluster 4ノードアーキテクチャのセットアップおよび構成に関する重要な手順の概要を以下に記載します。2ノード構成でも同様のセットアップを使用します。必要な作業は、厳密には、システムが工場出荷時に設定済みかどうかや、既存の機器を再導入するかどうか（移行シナリオの場合など）によって異なります。詳細な手順については、ドキュメントを参照してください。 1. ラックにハードウェアを配置し、デバイス間およびサイト間のケーブルを設置して接続します

（ISLおよびクラスタピアリング接続）。これには、clustered Data ONTAPのノード（FASまたは Vシリーズのコントローラ、クラスタ管理スイッチ、使用している場合はクラスタインターコネクトスイッチ）、SASディスクシェルフ、FCスイッチ、ファイバブリッジが含まれます。ファイバブリッジは、アレイ LUNと一緒には使用しません。

2. FCスイッチを設定します。工場で設定済みの場合もあります。設定済みでない場合は、ネットアップサポートサイトから入手できる構成ファイルを使用することを推奨します。構成ファイルは、MetroClusterでサポートされているスイッチに対応しています。手動による設定が必要な場合は、『MetroClusterインストレーションおよび構成ガイド』の手順に従います。

3. 製品ドキュメントで指示があるまでは、ISLリンクを接続しないでください。リンクがすでに有効な場合、ローカル HAクラスタのセットアップは機能しません。

4. 保守モードで次の手順を実行します。 a. ディスク所有権を確認します。製造元から届いた機器では、通常はディスク所有権がノード

間に均等に割り当てられています。ただし、その割り当てが要件と一致しない場合は、クラスタを作成する前にディスクを手動で再割り当てします。ディスク割り当ての計画ワークシートについては、『MetroCluster インストレーションおよび構成ガイド』を参照してください。ノードごとに、そのノードが所有するディスクで構成されたローカルプール（pool0、ノードと同じサイトに配置）とリモートプール（pool1、もう一方のサイトに配置）が 1つずつ必要です。

https://kb.netapp.com/support/index?page=content&actp=LIST&id=1015278


注：各ノードの DRパートナーは、metrocluster configureコマンドによって、システムID（NVRAM ID）に基づいて自動的に選択されます。一方の HAペアのシステム IDが小さいノードは、もう一方のクラスタのシステム IDが小さい対応するノードと DRパートナーとなり、その他も同様です。DRパートナーの割り当ては、初期設定後は変更できません。特に、1つの HAペア内のノードが別々のストレージで構成されている場合は、各クラスタでシステム IDが小さい対応するノード同士、およびシステム IDが大きい対応するノード同士で、ディスク構成が一致することを確認します。作業を続行する前に必要に応じてディスク所有権を調整し、DRパートナーが正しく割り当てられていることを確認します。DRパートナーの割り当ては、スイッチオーバー時に LIFで使用するポートにも影響します。通常の状況では、LIFは自身の DR パートナーノードにスイッチオーバーします。詳細については、『MetroClusterインストレーションおよび構成ガイド』の「MetroCluster構成用のネットワーク設定および LIF作成ガイドライン」を参照してください。

b. コントローラおよびシャーシのコンポーネントが「mcc-2n」または「mcc」に設定されていることを確認します。これにより、NVRAMをレプリケーション用に正しくパーティショニングできます。

5. 通常モードで次の手順を実行します。 a. システムセットアップウィザードを使用するか、CLIの cluster setupを使用して、各

サイトでクラスタを設定します。 b. インタークラスタ LIFを作成し、2つのクラスタをピアリングします。インタークラスタ

LIFは、専用のポート上でも、共有データポート上でも作成できます。 c. ルートアグリゲートをミラーします。 d. 各ノードでミラーされたデータアグリゲートを作成します。MDVをホストするクラスタご

とに、少なくとも 2つのデータアグリゲートが必要です。初期セットアップの前に作成されるこのアグリゲートは、データ（ボリュームおよび LUN）用に使用できます。MDVには専用のアグリゲートは必要ありません。

e. 必要に応じて追加の clustered Data ONTAP機能ライセンスをインストールします。スイッチオーバー後にクライアントとホストのアクセスが正しく行われるように、ライセンスは両方のクラスタで対称に設定する必要があります。そうでない場合、スイッチオーバーは拒否されます。

f. ISLおよびゾーニングを有効にします。 g. metrocluster configure –node-name <node-initiating-the-command>コマン

ドを使用して、一方のノードからMetroClusterを初期化します。 h. スイッチおよびファイバブリッジを、ヘルスモニタの監視対象のデバイスとして追加します

（storage switch addコマンドおよび storage bridge addコマンド）。ヘルスモニタは、監視およびアラート生成のための情報を OnCommand Unified Managerに提供します（詳細は 4.2を参照）。

i. MetroCluster構成を、metrocluster check runコマンドを使用して確認します。『MetroClusterインストレーションおよび構成ガイド』のその他の検証手順を実行します。

6. OnCommand Unified Manager がない場合はインストールします。MetroCluster クラスタを、管理対象のストレージシステムに追加します。

7. 構成に対して Config Advisorを実行し、エラーが見つかった場合は確認して修正します。Config Advisorはネットアップまたはパートナーの担当者が提供します。

8. MetroClusterのパフォーマンスを監視するために、OnCommand Performance Manager（OPM）をインストールすることを推奨します。

9. これで、構成をテストする準備が整いました。『MetroClusterインストレーションおよび構成ガイド』の手順に従って、HAのテイクオーバー / ギブバックとサイトのスイッチオーバー、修復、ギブバックを確認します。


2.3 セットアップ後の設定と管理 MetroCluster構成完了後の運用管理は、MetroClusterのない clustered Data ONTAP環境とほぼ同じです。必要なプロトコルで SVMを設定し（CLI、System Manager、またはWFAを使用）、必要な LIF、ボリューム、LUNを、通常運用時にこれらのサービスを実行するクラスタ上に作成します。これらのオブジェクトは、クラスタピアリングネットワークを介してもう一方のクラスタに自動的にレプリケートされます。アグリゲート再同期 Snapshotコピー：アグリゲート Snapshotコピーは、SyncMirror処理に対して一定の間隔で作成されます。デフォルトの間隔は 60分です。ネットアップでは、この間隔を 15分に短縮することを推奨します。また、Flash Poolが使用されている場合は、5分に短縮してください。アグリゲート Snapshotの間隔を変更するコマンドについては、セクション 4.9を参照してください。以下の一連のコマンドは、アグリゲートおよび SVMが各クラスタに追加で作成され、プロトコルアクセス用に設定されたあとの、2つのクラスタの状態を表しています。ここでは CLI出力を使用していますが、System Managerを使用して同じ出力を表示することもできます。

アグリゲートの表示通常運用時には、各クラスタからの出力に示されるように、各クラスタに表示されるのは自身のアグリゲートのみです。

tme-mcc-A::> aggr show Aggregate Size Available Used% State #Vols Nodes RAID Status --------- -------- --------- ----- ------- ------ ---------------- ------------ aggr0_tme_A1 1.38TB 741.9GB 48% online 1 tme-mcc-A1 raid_dp, mirrored, normal aggr0_tme_A2 1.38TB 741.9GB 48% online 1 tme-mcc-A2 raid_dp, mirrored, normal aggr1_tme_A1 2.07TB 2.06TB 1% online 4 tme-mcc-A1 raid_dp, mirrored, normal aggr1_tme_A2 2.07TB 2.06TB 0% online 1 tme-mcc-A2 raid_dp, mirrored, normal

tme-mcc-B::> aggr show Aggregate Size Available Used% State #Vols Nodes RAID Status --------- -------- --------- ----- ------- ------ ---------------- ------------ aggr0_tme_B1 1.38TB 741.9GB 48% online 1 tme-mcc-B1 raid_dp, mirrored, normal aggr0_tme_B2 1.38TB 741.9GB 48% online 1 tme-mcc-B2 raid_dp, mirrored, normal aggr1_tme_B1 2.07TB 2.06TB 1% online 2 tme-mcc-B1 raid_dp, mirrored, normal aggr1_tme_B2 2.07TB 2.06TB 1% online 3 tme-mcc-B2 raid_dp, mirrored, normal


SVMの表示 clustered Data ONTAP 8.3.xのデータ SVMは、プロパティのサブタイプによって区別されます。MetroClusterがない場合は、サブタイプはデフォルト値に設定されます。MetroClusterでは、サブタイプは sync-sourceまたは sync-destinationです。データ SVMのタイプは、所属するクラスタ上ではすべて sync-sourceです。もう一方のクラスタにレプリケートされた対の SVMオブジェクトのタイプは sync-destinationで、名前に–mcというサフィックスが追加されます。通常運用時、sync-source SVMの動作状態は「running」、sync-destination SVMの動作状態は「stopped」となっています。それぞれのクラスタで vserver showコマンドを実行した場合の出力について考えてみます。クラスタ Aに svm1_mccAという名前の SVM、クラスタ Bに svm1_mccBという名前の SVMを作成済みであるとします。クラスタ Aの出力には、svm1_mccAが、タイプ sync-sourceで表示されます。出力にあるsvm1_mccB-mcは、クラスタ Bのレプリケートされた SVMです。したがってサブタイプは sync-destinationで、状態は stoppedとなっています。

tme-mcc-A::> vserver show –type data Admin Operational Root Vserver Type Subtype State State Volume Aggregate ----------- ------- ---------- ---------- ----------- ---------- ---------- svm1_mccA data sync-source running svm1_mccA_root aggr1_tme_A1 running svm1_mccB-mc data sync-destination stopped svm1_mccB_root aggr1_tme_B1 running

クラスタ Bの出力はこの逆です。running状態の SVMは svm1_mccB（sync-source）です。クラスタ Aのレプリケートされた SVMは svm1_mccA-mc（sync-destination）で、状態は stoppedとなっています。

tme-mcc-B::> vserver show -type data Admin Operational Root Vserver Type Subtype State State Volume Aggregate ----------- ------- ---------- ---------- ----------- ---------- ---------- svm1_mccA-mc data sync-destination stopped svm1_mccA_root aggr1_tme_A1 running svm1_mccB data sync-source running svm1_mccB_root aggr1_tme_B1 running

スイッチオーバー時には、稼働しているクラスタがすべての sync-destination SVMを起動します。

ボリュームの表示通常運用時は、両方のクラスタのデータ SVMにあるすべてのボリューム、両方のクラスタのすべての MDV、およびローカルクラスタのルートボリュームのみが認識されます。ただし、オンライン状態なのはクラスタ Aの SVM svm1_mccAのボリュームのみです。クラスタ Bの SVMのボリュームは、表示はされますがアクセスはできず、スイッチオーバー後に初めてオンラインになります。わかりやすくするために、この出力ではMDVとルートボリュームは省略しています。

tme-mcc-A::> vol show Vserver Volume Aggregate State Type Size Available Used% --------- ------------ ------------ ---------- ---- ---------- ---------- ----- svm1_mccA svm1_mccA_lun1_vol aggr1_tme_A1 online RW 1.24GB 248.2MB 80% svm1_mccA svm1_mccA_root aggr1_tme_A1 online RW 1GB 972.5MB 5% svm1_mccA vol1 aggr1_tme_A1 online RW 2GB 1.85GB 7% svm1_mccB-mc svm1_mccB_root aggr1_tme_B1 - RW - - - svm1_mccB-mc vol1 aggr1_tme_B2 - RW - - - svm1_mccB-mc vol2 aggr1_tme_B2 - RW - - -


クラスタ Bでは、これが逆になり、クラスタ Bの SVMボリュームはオンラインで、クラスタ AのSVMのボリュームはオフラインです。

tme-mcc-B::> vol show Vserver Volume Aggregate State Type Size Available Used% --------- ------------ ------------ ---------- ---- ---------- ---------- ----- svm1_mccA-mc svm1_mccA_lun1_vol aggr1_tme_A1 - RW - - - svm1_mccA-mc svm1_mccA_root aggr1_tme_A1 - RW - - - svm1_mccA-mc vol1 aggr1_tme_A1 - RW - - - svm1_mccB svm1_mccB_root aggr1_tme_B1 online RW 1GB 972.5MB 5% svm1_mccB vol1 aggr1_tme_B2 online RW 2GB 1.85GB 7% svm1_mccB vol2 aggr1_tme_B2 online RW 1GB 972.5MB 5%

LUNの表示 LUNは、LUNがアクティブになっているクラスタでのみ認識されます。この構成では、LUNが定義された SVMはクラスタ Aにしかありません。

tme-mcc-A::> lun show Vserver Path State Mapped Type Size --------- ------------------------------- ------- -------- -------- -------- svm1_mccA /vol/svm1_mccA_lun1_vol/svm1_mccA_lun1 online mapped windows_2008 1.00GB

したがって、通常運用時は、クラスタ Bには LUNは表示されません。

tme-mcc-B::> lun show This table is currently empty.

LIFの表示クラスタ LIF、クラスタ管理 LIF、インタークラスタ LIFは、ローカルクラスタでのみ認識されます。データ LIFは、SVMの範囲内であれば、両方のクラスタで認識されます。出力は、これらのデータLIFのみを示しています。クラスタ Bの SVM（svm1_mccB_nfs_lif1）のレプリケートされた LIFは、クラスタ Aで現在使用できないため、動作状態が downと示されています。レプリケートされた LIFは、ノードの DRパートナー上にデフォルトで作成されます。各 LIFの IPアドレスとポート割り当てに注目すると、スイッチオーバー後も変更がないことがわかります。詳しくは、セクション 3.2の「LIFの表示」を参照してください。ファイバチャネル SANを使用する構成の場合、各ノードを、フロントエンド SANの正しいファブリックにログインする必要があります。そうしないと、パートナークラスタ上に正しく LIFを作成および割り当てできないため、スイッチオーバーが不可能になります。

tme-mcc-A::> network interface show –vserver svm* Logical Status Network Current Current Is Vserver Interface Admin/Oper Address/Mask Node Port Home ----------- ---------- ---------- ------------------ ------------- ------- ---- svm1_mccA svm1_mccA_iscsi_lifA1_1 up/up 10.228.22.68/24 tme-mcc-A1 e0a true svm1_mccA_iscsi_lifA1_2 up/up 10.228.22.69/24 tme-mcc-A1 e0b true svm1_mccA_iscsi_lifA2_1 up/up 10.228.22.97/24 tme-mcc-A2 e0a true svm1_mccA_iscsi_lifA2_2 up/up 10.228.22.98/24 tme-mcc-A2 e0b true svm1_mccA_nas_A1_1 up/up 10.228.22.62/24 tme-mcc-A1 e0a true svm1_mccB-mc svm1_mccB_nfs_lif1 up/down 10.228.22.74/24 tme-mcc-A1 e0a true


同様に、クラスタ Bではこれが逆になり、クラスタ Aのレプリケートされた LIFの動作状態がdownとなります。

tme-mcc-B::> network interface show –vserver svm* Logical Status Network Current Current Is Vserver Interface Admin/Oper Address/Mask Node Port Home ----------- ---------- ---------- ------------------ ------------- ------- ---- svm1_mccA-mc svm1_mccA_iscsi_lifA1_1 up/down 10.228.22.68/24 tme-mcc-B1 e0a true svm1_mccA_iscsi_lifA1_2 up/down 10.228.22.69/24 tme-mcc-B1 e0b true svm1_mccA_iscsi_lifA2_1 up/down 10.228.22.97/24 tme-mcc-B2 e0a true svm1_mccA_iscsi_lifA2_2 up/down 10.228.22.98/24 tme-mcc-B2 e0b true svm1_mccA_nas_A1_1 up/down 10.228.22.62/24 tme-mcc-B1 e0b true svm1_mccB svm1_mccB_nfs_lif1 up/up 10.228.22.74/24 tme-mcc-B1 e0b true

3 計画的 / 計画外イベントの耐障害性 NetApp MetroClusterは、ネットアップのハードウェアと clustered Data ONTAPに搭載された高可用性機能とノンストップオペレーション機能をさらに拡張することで、サイトにおけるストレージとホスト環境全体の保護を強化します。スタンドアロンサーバ、高可用性サーバクラスタ、仮想サーバなど、アプリケーション環境がどのように構成されているかにかかわらず、停電や冷却装置の不具合、ネットワークの切断、ハードウェアの故障、操作上のエラーなどによって 1つのサイトが障害状態になった場合でも、ストレージの可用性をシームレスに維持できます。 MetroCluster構成では、次の 3つの基本的な手法を使用して、計画的または計画外のイベントに対してデータの継続性を維持します。 • 冗長コンポーネント：1つのコンポーネントで発生した障害から保護 • ローカルでの高可用性テイクオーバー：1台のコントローラに影響するイベントに対応 • 完全なサイトスイッチオーバー：障害が発生したクラスタから稼働しているクラスタへストレー

ジおよびクライアントアクセスを移動して、サービスを迅速に再開前述したように、MetroClusterインフラの主要コンポーネントは冗長構成です。スタックごとに 2つのファイバブリッジ、2つのスイッチファブリック、ノードごとに 2つの FC-VI接続、ファブリックのノードごとに 2つの FCイニシエータ、ファブリックごとに複数の ISLリンクがあります。つまり、1つのコンポーネントで障害が発生しても、動作はシームレスに継続し、障害が発生したコンポーネントが修復または交換された時点で自動的に冗長運用に戻ります。すべての clustered Data ONTAPクラスタには、HAテイクオーバーおよびギブバックの機能がもともと備わっています。ただし、2ノード構成におけるシングルノードクラスタは例外で、スイッチオーバーとスイッチバックを使用して冗長運用を実現します。4ノード構成のコントローラは HAペアになっており、それぞれのペアの 2つのノードはストレージにローカルで接続されています。テイクオーバーは、一方のノードがもう一方のストレージを自動的に継承し、データサービスを継続するプロセスです。ギブバックは、通常運用を再開するための逆のプロセスです。テイクオーバーは、計画的に行う場合（ハードウェアのメンテナンスや、ノードの clustered Data ONTAPをアップグレードする場合など）と、ノードのハードウェアやソフトウェアの障害時に計画外で行う場合があります。テイクオーバー中は、NAS LIFも自動的にフェイルオーバーされます。SAN LIFはフェイルオーバーしません。ホストでは、LUNへの直接パスが自動的に使用されます。HAテイクオーバーおよびギブバックはMetroClusterに固有の機能ではないため、詳細については『Data ONTAP High Availability Guide』を参照してください。サイトスイッチオーバーは、一方のクラスタがオフラインになったときに発生します。サバイバサイトがオフラインクラスタのストレージリソース（ディスクおよびアグリゲート）の所有権を引き継ぎます。サバイバサイトでオフラインクラスタの SVMがオンラインになって再起動され、その際にクライアント / ホストのアクセス用に SVMの IDはそのまま維持されます。


3.1 MetroClusterの計画外処理と計画的処理表 5に、考えられる計画外イベントと、それぞれの場合のMetroCluster構成の動作を示します。

表 5）計画外処理とMetroClusterの応答およびリカバリ方法

計画外処理リカバリ方法

1本または 2本のディスクの障害

自動 RAIDリカバリ。フェイルオーバーやスイッチオーバーはなく、両方のプレックスがすべてのアグリゲートで引き続き使用可能です。スペアからディスクがリビルドされ、アグリゲートに自動的に組み入れられます。 RAID DPアグリゲートは、2本のディスクで障害が発生しても停止することはありません。RAID 4アグリゲートもサポートされていますが、2本のディスクで障害が発生した場合は停止します。RAID DPアグリゲートと RAID 4アグリゲートはいずれも MetroClusterでサポートされています。

シェルフ障害を含めた 3本以上のディスクの障害

稼働しているプレフィックスからデータが提供されます。データサービスの中断はありません。ディスク障害は、ローカルまたはリモートのいずれかのプレックスに影響する可能性があります。アクティブなプレックスが 1つだけなので、アグリゲートはデグレードモードになります。障害の原因がシェルフの電源喪失である場合は、電源が回復したときに、影響を受けたアグリゲートが自動的に再同期して変更内容が反映されます。ディスクの交換が必要な場合は、管理者は障害が発生したプレックスを削除してから（storage aggregate plex delete コマンド）、影響を受けたアグリゲートを再ミラーします（storage aggregate mirror コマンド）。これにより、自動再同期プロセスが開始します。再同期後、アグリゲートは自動的に通常のミラーモードに戻ります。

スイッチの障害データは稼働しているパスで引き続き提供されます。すべてのプレックスが引き続き使用可能です。ファブリックが 2つあるため、一方のファブリックが完全に停止しても処理が中断することはありません。

ファイバブリッジの障害影響を受けるスタックへのすべてのトラフィックが稼働しているブリッジによって継続され、すべてのプレックスが引き続き使用可能です。



単一ノードの障害 4ノード構成：サイトごとに HAペアが 1つずつあるため、一方のノードで障害が発生すると、もう一方のノードへのフェイルオーバーが透過的かつ自動的に実施されます。たとえば、ノード A1で障害が発生した場合、そのストレージおよびワークロードは自動的にノードA2に転送されます。すべてのプレフィックスが引き続き使用可能です。2つ目のサイトのノード（B1および B2）は影響を受けません。フェイルオーバーがローリングディザスタ（連続的に発生するディザスタ）の一部である場合（たとえば、A1が A2にフェイルオーバーし、その後 A2またはサイト A全体で障害が発生した場合など）は、サイト Bへの強制的スイッチオーバーを実行できます。 2ノード構成：2ノード構成には、ローカルのHAペアはありません。そのため、一方のノードで障害が発生した場合は、リモートのMetroClusterパートナーノードにスイッチオーバーする必要があります。メールボックスディスクがアクセス可能な場合は、スイッチオーバーは自動的に実行されます。

サイト間の ISL損失 1つまたは複数のISLで障害が発生した場合、I/Oは残りのリンクを使用して継続します。両方のファブリックのすべてのISLで障害が発生し、サイト間でのストレージとNVRAMのレプリケーション用のリンクがなくなった場合、各コントローラは動作を継続してそれぞれのローカルデータを処理します。2つの独立したファブリック接続が必要（それぞれ独立したネットワークプロバイダを使用可能）で、ファブリックあたり最大4つのISLを設定可能であることを考えると、すべてのISLで障害が発生する可能性は極めて低いと言えます。ISLが1つでもリストアされると、プレックスは自動的に再同期します。すべてのISLが停止しているときに発生した書き込みは、サイト間でミラーされません。この状態で強制的スイッチオーバーを実行すると、サバイバサイトで同期されなかったデータが失われる可能性があります。その場合、スイッチオーバー後にリカバリのための手動操作が必要です。詳細については、セクション3.5を参照してください。すべてのISLが長期間にわたって使用できない可能性がある場合、管理者は、すべてのデータサービスをシャットダウンして、強制的スイッチオーバーが必要になったときのデータ損失リスクを回避することができます。この処理を実行するかどうかは、少なくとも1つのISLが使用可能になる前にスイッチオーバーが必要な災害が発生する可能性を検討して決定する必要があります。また、ISLで連鎖的に障害が発生している場合は、管理者は、すべてのリンクが停止する前に、どちらかのサイトへの計画的スイッチオーバーを実行することもできます。



ピアリングされたクラスタリンク（CRS）の障害

ISLはアクティブなままなので、データサービス（読み取りおよび書き込み）は、両方のサイトで両方のプレックスに対して継続します。クラスタ設定の変更（新しいSVMの追加、既存のSVMでのボリュームまたはLUNのプロビジョニング）は、もう一方のサイトに伝播できません。これらはローカルのCRSメタデータボリュームに保持され、ピアリングされたクラスタリンクのリストア時に、もう一方のクラスタに自動的に伝播されます。ピアリングされたクラスタリンクがリストア可能となる前に強制的スイッチオーバーが必要な場合は、スイッチオーバープロセスの一環として、サバイバサイトにあるメタデータボリュームのリモートレプリケートコピーから、保留になっているクラスタ設定変更が自動的に再生されます。

1つのサイトの全ノードの障害、またはサイトの完全な損壊

管理者は強制的スイッチオーバーを実行して、障害が発生したノードのサービスをサバイバサイトで再開します。強制的スイッチオーバーは手動による処理です。詳細については、セクション4.4を参照してください。障害が発生したノードまたはサイトのリストア後、スイッチバック処理が実行されて安定状態の動作がリストアされます。 4ノード構成で構成がスイッチオーバーされた場合、稼働しているノードのいずれかで続けて障害が発生しても、稼働しているノードにフェイルオーバーすることでシームレスに対応できます。この場合、4つのノードの作業が 1つのノードで実行されることになります。リカバリは、ローカルノードにギブバックしてから、サイトのスイッチバックを実行します。

表 6 に、標準的なメンテナンス（計画的）イベントと、MetroCluster 構成での実行方法を示します。

表 6）MetroClusterでの計画的処理

計画的処理無停止でのプロセス

clustered Data ONTAPのアップグレード

4ノード構成の場合、clustered Data ONTAPの他のアップグレードと同様に、NDU（無停止アップグレード：HAペア内でのフェイルオーバーとギブバック）を使用して実行します。マイナーアップグレード（8.3から 8.3.xなど）の場合は、2つのサイトのクラスタをそれぞれ別にアップグレードできます。これには NDUの自動化を使用できます。各クラスタを同時にアップグレードする必要はなく、clustered Data ONTAPのマイナーバージョンが 2つのクラスタ間で違っても動作と耐障害性は継続します。ただしネットアップでは、安定した動作を確保するために、アップグレードプロセスはできるだけ早く完了させることを推奨します。計画的スイッチオーバーは、すべてのノードが同じバージョンの clustered Data ONTAPにアップグレードされるまで遅らせる必要があります。メジャーアップグレード（8.3から 8.xなど）および 2ノードのアップグレードにはオーケストレーションが必要です。つまり、両方のクラスタを同時にアップグレードする必要があります。各クラスタで実行されている clustered Data ONTAPのバージョンが違う場合、スイッチオーバーおよびスイッチバックの処理は実行できません。


計画的処理無停止でのプロセス

アグリゲートの再配置（ARL）を使用したコントローラハードウェアのアップグレード

アグリゲートの再配置を使用すると、コントローラのモデルを無停止でアップグレードできます。たとえば、FAS8040を FAS8080にアップグレードする場合などです。クラスタ内のすべてのノードを同じコントローラモデルにアップグレードする必要があります。コントローラのアップグレード中、ストレージのレプリケーションには影響はありません。ただし、サイト間の NVRAMレプリケーションは、アップグレードが完了するまで無効にする必要があります。2つのクラスタを次のように順次アップグレードする必要があります。 1. すべてのノードで NVRAMレプリケーションを無効にします。 2. 1つ目のクラスタでノードをアップグレードします。 3. 2つ目のクラスタでノードをアップグレードします。 4. すべてのノードで NVRAMレプリケーションを有効にします。アップグレードによって、コントローラノードのシリアル番号とシステム IDが変わります。MetroClusterは新しいシステム IDを自動的に取得し、新しい HAパートナーと DRパートナーを正しく識別します。ディスクミラーリングは ARLプロセス中も継続しますが、NVRAMは無効にする必要があります。したがって、アグリゲートは同期されたままです。この間に強制的スイッチオーバーが必要になった場合は、最大で過去 10秒間のトランザクションが失われる可能性があります。コントローラのアップグレード中は、計画的スイッチオーバーは実行できません。 NVRAMミラーリングを無効 / 有効にするコマンドは次のとおりです。 metrocluster interconnect modify -node <nodename> -partner-type DR -mirror-status OFFLINE|ONLINE

ARLは、いくつもの手順で構成された時間のかかるプロセスです。詳細な手順については、コントローラのアップグレードガイドを参照してください。

3.2 計画的（ネゴシエート）スイッチオーバーの実行スイッチオーバーには、計画的スイッチオーバーと、災害後の強制的スイッチオーバーの 2種類があります。計画的（ネゴシエート）スイッチオーバーは、スイッチオーバーの必要性が事前にわかっていて、すべてのノードが稼働しているときに実行できます。計画的スイッチオーバーでは、リソースの所有権を通常の操作で転送し、スイッチオーバー元のサイトのすべてのサービスをシャットダウンしてから、稼働しているサイトでサービスを再開します。スイッチオーバー元のノードもクリーンシャットダウンされます。計画的スイッチオーバーの実行前に、MetroCluster構成が安定した状態で動作している必要があります。これには次の項目が含まれます。 • 実行中のフェイルオーバーやギブバックがなく、すべてのノードが稼働している。 • clustered Data ONTAPソフトウェアの更新が実行中ではなく、すべてのノードが同じリリース

で動作している。 • クラスタピアリングネットワークが稼働している。 • 少なくとも 1つの ISLが動作している。 • 再開が必要な、長期にわたって実行するタスクが進行中ではない。 • CPU利用率に余裕があり、適切な時間内にスイッチオーバーを完了できる。


注：このリストはすべての項目をカバーしているわけではありません。計画的スイッチオーバーに必要なその他の条件についても、事前チェックが自動的に実行されます。計画的スイッチオーバーは「クリーンな」処理であり、システムが安定した状態である必要があるため、事前チェックは必ず実行されます。

事前チェックにパスしなかった条件があり、それでもスイッチオーバーを実行する必要がある場合は、強制的スイッチオーバーを実行できます。強制的スイッチオーバーではこれらの要件による制約はありません。ただし、パスしなかった条件がクリアされるまで待って計画的スイッチオーバーを実施することを推奨します。計画的スイッチオーバーは、テスト目的や、たとえばサイトその他の計画的メンテナンスを実行する場合などに便利です。計画的スイッチオーバーを実行するには、リソースを引き継ぐクラスタでmetrocluster switchoverコマンドを実行します。以下にクラスタ Aをクラスタ Bにスイッチオーバーする場合の大まかな手順を記載します。クラスタ Bがサバイバサイトです。 1. セクション 4.3の指示に従って、NetApp AutoSupport™メッセージを送信し、計画的メンテ

ナンスまたはテストを実行することをネットアップサポートに通知します。 2. スイッチオーバーのための環境が整っていることを確認します。計画的スイッチオーバーを実行

するためには、両方のクラスタが安定した状態である必要があります。どちらかのクラスタ設定に変更を行った場合は、変更内容がレプリケートされるまで少なくとも数分待機してから、スイッチオーバーコマンドを実行します。その後、スイッチオーバーが完了するまでは設定への変更は行わないでください。

3. metrocluster check runを実行してすべてのコンポーネントが正常であることを確認します。エラーが報告された場合は、修正してから次に進みます。

4. クラスタ Bのクラスタシェルで、metrocluster switchover –simulateを（アドバンストモードで）実行し、クラスタがスイッチオーバー可能であることを確認します。このコマンドは、計画的スイッチオーバーの妨げとなる条件を対象としたすべての事前チェックを実行しますが、スイッチオーバー自体は実行しません。計画的スイッチオーバーは強制的スイッチオーバーと比較して緊急性が低いため、事前チェックを実行しても問題ありません。次のメッセージが表示されます。

[Job 1234] Job succeeded: Switchover simulation is successful.

上記以外のメッセージが表示される場合は、システムが安定した状態ではなく、計画的スイッチオーバーに適していません。報告された条件を修正して再試行してください。

5. クラスタ Bで metrocluster switchoverを実行し、スイッチオーバーを実施します。プロセス全体が完了するまで数分かかる場合がありますが、クライアントやホストで 2分以上 I/Oが停止することはほとんどありません。進捗状況を監視するには、metrocluster operation showコマンドを使用します。クラスタ Aのコンソールを監視してノードがシャットダウンされたことを確認できます。スイッチオーバーの実行に必要なコマンドは 1つだけです。このコマンドによって以下のタスクが自動的に実行され、管理者によるそれ以上の操作は不要です。 a. metrocluster switchover –simulateコマンドと同じルールを使用して、条件を満た

さない構成がないかチェックします。 b. I/Oの一貫性を保つためにクラスタ Aの NVRAMをディスクにフラッシュします。 c. クラスタ Aのボリュームおよびアグリゲートがすべてオフラインになります。この時点で、

クライアントとホストの I/Oは一時停止します。SVMと LIFはオンのままで、SANホストがパスの問い合わせに応答できるように、クラスタ Aの LUNへのパスは可能なかぎり使用可能な状態に保たれます。

d. クラスタ Bが、クラスタ Aが所有するディスク（両方のプール）の所有権を取得します。ルート以外の（データ）アグリゲートがWAFLに組み込まれ、そのボリュームがオンラインになります。

e. クラスタ Aの SVMと LIFがオフラインになります。 f. クラスタ Aの SVMがクラスタ Bでオンラインになります。LIFがオンラインになり、プロ

トコルサービスが再開されます。クライアント / ホスト / アプリケーションの一時停止していた I/Oが自動的に再開します。


g. クラスタ Aのノードがシャットダウンし、LOADER>プロンプトで待機します。デフォルトではストレージは使用可能なままです。シャットダウンサイトを全体的にフェンシングする必要がある場合は、ストレージ、ブリッジ、スイッチの電源をオフにして、1つのプレックスのみを使用可能な状態で残すことができます。ただし、ストレージをフェンシングするのは、データセンターへの電源が切断された場合や ISLが停止している場合など、必要な場合のみにすることを推奨します。ストレージを稼働させておくと、両方のプレックスが使用可能なままになるため耐障害性が向上し、再同期がほとんどまたはまったく必要ないため、スイッチバックの時間も短縮できます。

コマンド出力は次のようになります。ジョブが完了したら、metrocluster operation showコマンドを使用して、処理が成功したことを確認します。

tme-mcc-B::> metrocluster switchover Warning: negotiated switchover is about to start. It will stop all the data Vservers on cluster "tme-mcc-A" and automatically re-start them on cluster "tme-mcc-B". It will finally gracefully shutdown cluster "tme-mcc-A". Do you want to continue? {y|n}: y [Job 2839] Job succeeded: Switchover is successful.

6. 「Switchover is successful」というメッセージが表示されたら、『MetroCluster管理およびディザスタリカバリガイド』の「DRパートナーのオンライン確認」および「SnapMirrorまたは SnapVaultの SVMピアリング関係の再確立」の説明に従って、サイト Bが安定していることを確認します。セクション 4.7で説明しているように、SnapMirrorまたは SnapVaultとスイッチオーバー元のクラスタ（この例ではクラスタ A）内のデスティネーションボリュームとの関係は、スイッチオーバー / スイッチバック処理の完了後にすべて手動で再作成する必要があります。SnapMirrorおよび SnapVaultとMetroCluster構成上のソースとの関係はそのまま保持されるため、再作成する必要はありません。

tme-mcc-B::> metrocluster node show DR Configuration DR Group Cluster Node State Mirroring Mode ----- ------- ------------------ -------------- --------- -------------------- 1 tme-mcc-B tme-mcc-B1 configured enabled switchover completed tme-mcc-B2 configured enabled switchover completed tme-mcc-A tme-mcc-A1 unreachable - switched over tme-mcc-A2 unreachable - switched over

7. この時点で、計画的スイッチオーバーの目的に応じて、テストおよび検証、またはその他の計画的メンテナンスを実施できます。メンテナンスが完了したら、次のセクションの説明に従ってスイッチバックを開始します。

以下はセクション 2.3と同じコマンドおよびチェックです。スイッチオーバー後に実行して、オブジェクトの表示内容の変化と、すべてのリソースがスイッチオーバーされたことを確認します。クラスタ Aがシャットダウンされているため、コマンドは稼働しているクラスタ Bでのみ実行します。

アグリゲートの表示計画的スイッチオーバー後、すべてのアグリゲートがサイト Bで認識されます。サイト Aのアグリゲートはスイッチオーバーされたアグリゲートとして表示されます。データアグリゲートのみがオンラインです。ルートアグリゲートは、スイッチオーバーはされますが、オンラインにはなりません。すべてのオンラインアグリゲートは、ミラーとして、通常の RAIDステータスで表示されます。この計画的スイッチオーバーではストレージの電源はオフにしておらず、両方のプレックスが使用可能なためです。

tme-mcc-B::> aggr show tme-mcc-A Switched Over Aggregates: Aggregate Size Available Used% State #Vols Nodes RAID Status --------- -------- --------- ----- ------- ------ ---------------- ------------ aggr0_tme_A1 0B 0B 0% offline 0 tme-mcc-B2 raid_dp, mirror degraded aggr0_tme_A2 0B 0B 0% offline 0 tme-mcc-B1 raid_dp, mirror


degraded aggr1_tme_A1 2.07TB 2.06TB 1% online 4 tme-mcc-B2 raid_dp, mirrored, normal aggr1_tme_A2 2.07TB 2.06TB 0% online 1 tme-mcc-B1 raid_dp, mirrored, normal tme-mcc-B Aggregates: Aggregate Size Available Used% State #Vols Nodes RAID Status --------- -------- --------- ----- ------- ------ ---------------- ------------ aggr0_tme_B1 1.38TB 741.9GB 48% online 1 tme-mcc-B1 raid_dp, mirrored, normal aggr0_tme_B2 1.38TB 741.9GB 48% online 1 tme-mcc-B2 raid_dp, mirrored, normal aggr1_tme_B1 2.07TB 2.06TB 1% online 2 tme-mcc-B1 raid_dp, mirrored, normal aggr1_tme_B2 2.07TB 2.06TB 1% online 3 tme-mcc-B2 raid_dp, mirrored, normal

SVMの表示両方の SVMがクラスタ Bで実行されています。クラスタ Aの同期先 SVMである svm1_mccA-mcのステータスが runningに変わっています。

tme-mcc-B::> vserver show -type data Admin Operational Root Vserver Type Subtype State State Volume Aggregate ----------- ------- ---------- ---------- ----------- -------------- ------------- svm1_mccA-mc

data sync-destination running svm1_mccA_root aggr1_tme_A1 running svm1_mccB data sync-source running svm1_mccB_root aggr1_tme_B1 running

ボリュームの表示 4ノード構成をみると、4つすべてのMDVがオンラインであることがわかります（「設定レプリケーションサービス」の出力と比較）。また、クラスタ Aのデータ SVMがオンラインになったため、この SVMのボリュームもクラスタ Bでオンラインになっています。ただし、前掲の出力と同様に、ローカルのルートボリュームは省略されています。スイッチオーバーの状態にかかわらず、各クラスタでは自身のルートボリュームのみが認識されます。

tme-mcc-B::> vol show Vserver Volume Aggregate State Type Size Available Used% --------- ------------ ------------ ---------- ---- ---------- ---------- ----- svm1_mccA-mc svm1_mccA_lun1_vol aggr1_tme_A1 online RW 1.24GB 248.2MB 80% svm1_mccA-mc svm1_mccA_root aggr1_tme_A1 online RW 1GB 972.5MB 5% svm1_mccA-mc vol1 aggr1_tme_A1 online RW 2GB 1.85GB 7% svm1_mccB svm1_mccB_root aggr1_tme_B1 online RW 1GB 972.5MB 5% svm1_mccB vol1 aggr1_tme_B2 online RW 2GB 1.85GB 7% svm1_mccB vol2 aggr1_tme_B2 online RW 1GB 972.5MB 5% tme-mcc-B MDV_CRS_cd7628c7f1cc11e3840800a0985522b8_A aggr1_tme_A1 online RW 10GB 9.50GB 5% tme-mcc-B MDV_CRS_cd7628c7f1cc11e3840800a0985522b8_B


aggr1_tme_A2 online RW 10GB 9.50GB 5% tme-mcc-B MDV_CRS_e8fef00df27311e387ad00a0985466e6_A aggr1_tme_B1 online RW 10GB 9.50GB 5% tme-mcc-B MDV_CRS_e8fef00df27311e387ad00a0985466e6_B aggr1_tme_B2 online RW 10GB 9.50GB 5%

LUNの表示クラスタ Aの SVMには LUNがプロビジョニングされていたため、この LUNをクラスタ Bで認識し、アクセスすることができます。

tme-mcc-B::> lun show Vserver Path State Mapped Type Size --------- ------------------------------- ------- -------- -------- -------- svm1_mccA-mc /vol/svm1_mccA_lun1_vol/svm1_mccA_lun1 online mapped windows_2008 1.00GB

LIFの表示最後に、スイッチオーバーされたクラスタ Aの LIFが、クラスタ Bで動作状態が upとなって使用可能になります。これらの LIFアドレスへのクライアント / ホストアクセスは、すべてクラスタ B経由で行われます。IPアドレスおよびポート割り当てに変更はなく、クラスタ Bでもまったく同じです。MetroClusterシステムでは、スイッチオーバー後もストレージアクセスリソースの ID（LIF IPアドレス、LUNターゲット ID、SCSI予約、WWPN、WWN）が維持されるため、クライアントおよびホストはこれらのアクセス設定を変更する必要がありません。ポート割り当てに関するベストプラクティスは、同等の DRパートナー間で同じネットワークポートを確保しておくことです。そうすることで、スイッチオーバー後にポートも同じ IDでマップされます。

tme-mcc-B::> network interface show -vserver svm* Logical Status Network Current Current Is Vserver Interface Admin/Oper Address/Mask Node Port Home ----------- ---------- ---------- ------------------ ------------- ------- ---- svm1_mccA-mc svm1_mccA_iscsi_lifA1_1 up/up 10.228.22.68/24 tme-mcc-B1 e0a true svm1_mccA_iscsi_lifA1_2 up/up 10.228.22.69/24 tme-mcc-B1 e0b true svm1_mccA_iscsi_lifA2_1 up/up 10.228.22.97/24 tme-mcc-B2 e0a true svm1_mccA_iscsi_lifA2_2 up/up 10.228.22.98/24 tme-mcc-B2 e0b true svm1_mccA_nas_A1_1 up/up 10.228.22.62/24 tme-mcc-B1 e0b true svm1_mccB svm1_mccB_nfs_lif1 up/up 10.228.22.74/24 tme-mcc-B1 e0b true

スイッチオーバーモード中の処理スイッチオーバーモード中も、既存の SVMに変更を行うことができます。たとえば、新しいボリューム、LUN、または LIFを、スイッチオーバー元のクラスタの SVMに作成できます。ただし、スイッチオーバー元のクラスタに新しい SVMを作成することはできません。たとえば、クラスタ Aがクラスタ Bにスイッチオーバーした場合、管理者は、クラスタ Aが所有者となる新しい SVMは作成できませんが、クラスタ Aの SVMにボリュームを追加することはできます。クラスタ Bがもともと所有するリソースの処理に制限はありません。 MetroCluster構成に SnapMirrorまたは SnapVaultの関係が定義されている場合は、セクション 4.7で重要な考慮事項を確認してください。 MetroClusterの処理では、SnapManager®および NetApp SnapProtect®ソフトウェア（V10 SP9リリース）も検証されます。詳細については、それぞれのドキュメントを参照してください。


スイッチオーバー元のクラスタが所有者となる新しいアグリゲートは作成できません。本書の例では、クラスタ Aの新しいアグリゲートは作成できません。稼働しているクラスタには新しいアグリゲートを作成できますが、もう一方のクラスタのリモートストレージが使用できない場合、作成したアグリゲートはミラーされません。これらのアグリゲートは、修復後、スイッチバックを実行する前にミラーする必要があります（storage aggregate mirrorコマンド）。スイッチオーバーモード中、どちらかのクラスタのアグリゲートを拡張することができます。使用可能なプレックスが 1つだけの場合（つまり、スイッチオーバー元のクラスタがフェンシングされている場合）は、アグリゲートのミラーを解除してから（storage aggregate plex delete コマンド）、稼働しているクラスタ上の対応するプレックスからディスクを追加して拡張します。アグリゲートの修復後、スイッチバックの前に、storage aggregate mirrorコマンドを使用して拡張したアグリゲートを再ミラーします。

3.3 スイッチバックの実行スイッチバックは常に計画的に実施されます。つまり、管理者が開始する必要があります。3つのコマンドを順に実行し、シャットダウンサイトを稼働させ、そのリソースを元に戻します。ここでは手順の概要を示します。詳細については、『MetroCluster管理およびディザスタリカバリガイド』の「構成の修復」および「スイッチバックの実行」を参照してください。 1. スイッチオーバーテストでサイト A のストレージの電源をオフにした場合は、ここでシェルフ、

および必要に応じてブリッジやスイッチの電源をオンにします。ノードの電源はオンにしないでください。

2. クラスタは安定した状態である必要があります。稼働しているクラスタは、両方のノードが使用可能で、テイクオーバーモードになっていない必要があります。クラスタピアリングネットワークと、少なくとも 1つの ISLが稼働している必要があります。

3. 次のコマンドを使用してデータアグリゲートを修復します。 tme-mcc-B::> metrocluster heal -phase aggregates [Job 2853] Job succeeded: Heal Aggregates is successful.

4. スイッチオーバー中にシャットダウンサイトのストレージがオフラインになっていた場合は、再同期が自動的に開始され、スイッチオーバー中に発生した I/Oが伝播されます。再同期が完了するまで待ちます。データアグリゲートが再同期されるまでスイッチバックの次のフェーズに進むことはできません。ステータスは次のコマンドで監視します。

tme-mcc-B::> aggr show-resync-status Complete Aggregate Resyncing Plex Percentage --------- ------------------------- ---------- aggr0_tme_A1 plex0 - aggr0_tme_A1 plex2 - aggr0_tme_A2 plex0 - aggr0_tme_A2 plex2 - aggr0_tme_B1 plex0 - aggr0_tme_B1 plex2 - aggr0_tme_B2 plex0 - aggr0_tme_B2 plex2 - aggr1_tme_A1 plex0 70% aggr1_tme_A1 plex1 - aggr1_tme_A2 plex0 - aggr1_tme_A2 plex1 - aggr1_tme_B1 plex0 - aggr1_tme_B1


plex1 - aggr1_tme_B2 plex0 - aggr1_tme_B2 plex1 -

5. 再同期が完了したら、アグリゲートのステータスをもう一度確認します。すべてのアグリゲートの RAIDステータスが、mirrored、normalと表示されているはずです。

tme-mcc-B::> storage aggregate show tme-mcc-A Switched Over Aggregates: Aggregate Size Available Used% State #Vols Nodes RAID Status --------- -------- --------- ----- ------- ------ ---------------- ------------ aggr0_tme_A1 0B 0B 0% offline 0 tme-mcc-B2 raid_dp, mirrored, normal aggr0_tme_A2 0B 0B 0% offline 0 tme-mcc-B1 raid_dp, mirrored, normal aggr1_tme_A1 2.07TB 2.06TB 1% online 4 tme-mcc-B2 raid_dp, mirrored, normal aggr1_tme_A2 2.07TB 2.06TB 0% online 1 tme-mcc-B1 raid_dp, mirrored, normal

tme-mcc-B Aggregates: Aggregate Size Available Used% State #Vols Nodes RAID Status --------- -------- --------- ----- ------- ------ ---------------- ------------ aggr0_tme_B1 1.38TB 741.9GB 48% online 1 tme-mcc-B1 raid_dp, mirrored, normal aggr0_tme_B2 1.38TB 741.9GB 48% online 1 tme-mcc-B2 raid_dp, mirrored, normal aggr1_tme_B1 2.07TB 2.06TB 1% online 2 tme-mcc-B1 raid_dp, mirrored, normal aggr1_tme_B2 2.07TB 2.06TB 1% online 3 tme-mcc-B2 raid_dp, mirrored, normal

6. ルートアグリゲートを修復します。この手順により、ルートアグリゲートは復帰するクラスタにギブバックされます。

tme-mcc-B::> metrocluster heal -phase root-aggregates [Job 2854] Job succeeded: Heal Root Aggregates is successful.

7. クラスタ Aのルートアグリゲートはクラスタ Aに返されたため、スイッチオーバー先のクラスタ Bでは認識されなくなります。ただし、クラスタ Aのデータアグリゲートは引き続きクラスタ Bで認識されます。この時点では、SVMおよびデータサービスはすべてまだクラスタ Bで実行されています。

tme-mcc-B::> aggr show tme-mcc-A Switched Over Aggregates: Aggregate Size Available Used% State #Vols Nodes RAID Status --------- -------- --------- ----- ------- ------ ---------------- ------------ aggr0_tme_A1 - - - unknown - tme-mcc-B2 - aggr0_tme_A2 - - - unknown - tme-mcc-B1 - aggr1_tme_A1 2.07TB 2.06TB 1% online 4 tme-mcc-B2 raid_dp, mirrored, normal aggr1_tme_A2 2.07TB 2.06TB 0% online 1 tme-mcc-B1 raid_dp, mirrored,


normal tme-mcc-B Aggregates: Aggregate Size Available Used% State #Vols Nodes RAID Status --------- -------- --------- ----- ------- ------ ---------------- ------------ aggr0_tme_B1 1.38TB 741.9GB 48% online 1 tme-mcc-B1 raid_dp, mirrored, normal aggr0_tme_B2 1.38TB 741.9GB 48% online 1 tme-mcc-B2 raid_dp, mirrored, normal aggr1_tme_B1 2.07TB 2.06TB 1% online 2 tme-mcc-B1 raid_dp, mirrored, normal aggr1_tme_B2 2.07TB 2.06TB 1% online 3 tme-mcc-B2 raid_dp, mirrored, normal

8. 次の手順に進んでも大丈夫な構成になっていることを確認します。 tme-mcc-B::> metrocluster node show DR Configuration DR Group Cluster Node State Mirroring Mode ----- ------- ------------------ -------------- --------- -------------------- 1 tme-mcc-B tme-mcc-B1 configured enabled heal roots completed tme-mcc-B2 configured enabled heal roots completed tme-mcc-A tme-mcc-A1 unreachable - switched over tme-mcc-A2 unreachable - switched over

9. クラスタ Aのノードに障害が発生しているディスクがないかを、disk show –broken コマンドを使用して確認します。障害が発生しているディスクがある場合は、シェルフから取り外してから作業を続行します。

10. クラスタ Aのノードを電源投入またはブートして、クラスタとMetroCluster構成が安定した状態に戻るのを待ちます。次の出力は、ブート後にクラスタ Aがまだ完全に同期されていないことを示しています。ノード A2はまだ正常な状態ではなく、クラスタ Bへのピアリングは再確立されていません。この時点でスイッチバックを試みても失敗します。

tme-mcc-A::> cluster show Node Health Eligibility --------------------- ------- ------------ tme-mcc-A1 true true tme-mcc-A2 false true 2 entries were displayed. tme-mcc-A::> cluster peer show Peer Cluster Name Cluster Serial Number Availability Authentication ------------------------- --------------------- -------------- -------------- tme-mcc-B 1-80-000011 Unavailable absent

11. 各ノードが正しい状態であることを確認します。 tme-mcc-B::> metrocluster node show DR Configuration DR Group Cluster Node State Mirroring Mode ----- ------- ------------------ -------------- --------- -------------------- 1 tme-mcc-B tme-mcc-B1 configured enabled heal roots completed tme-mcc-B2 configured enabled heal roots completed tme-mcc-A tme-mcc-A1 configured enabled waiting for switchback recovery tme-mcc-A2 configured enabled waiting for switchback recovery


12. クラスタ Aが安定し、クラスタピアリングが完全に稼働するまで待機します。この処理には、数分かかることがあります。クラスタピアリングの Availabilityフィールドが、unavailableから pendingに、その後 availableに変わります。

tme-mcc-A::> cluster show Node Health Eligibility --------------------- ------- ------------ tme-mcc-A1 true true tme-mcc-A2 true true tme-mcc-A::> cluster peer show Peer Cluster Name Cluster Serial Number Availability Authentication ------------------------- --------------------- -------------- -------------- tme-mcc-B 1-80-000011 Pending absent tme-mcc-A::> cluster peer show Peer Cluster Name Cluster Serial Number Availability Authentication ------------------------- --------------------- -------------- -------------- tme-mcc-B 1-80-000011 Available absent

13. クラスタピアリングが正常であることを、クラスタ Bから確認します。 tme-mcc-B::*> cluster peer show Peer Cluster Name Cluster Serial Number Availability Authentication ------------------------- --------------------- -------------- -------------- tme-mcc-A 1-80-000011 Available absent

14. 最終チェックとして、クラスタ Bで switchback –simulateをアドバンストモードで実行します。このコマンドは、スイッチバックの妨げとなる条件を対象としたすべての事前チェックを実行しますが、スイッチバック自体は実行しません。スイッチバックが拒否されたというメッセージが表示された場合は、該当する条件をクリアしてから次の手順に進みます。たとえば、クラスタ Bの 1つのノードがテイクオーバーされている場合は、ギブバックしてから作業を進める必要があります。

tme-mcc-B::*> metrocluster switchback -simulate [Job 2855] Job succeeded: Switchback simulation is successful. tme-mcc-B::*> metrocluster operation show Operation: switchback-simulate State: successful Start Time: 2/27/2015 16:31:51 End Time: 2/27/2015 16:32:20 Errors: -

15. 最後に、スイッチバックを実行します。スイッチバックコマンドによって以下の手順が自動的に実行されるため、それ以上の処理は不要です。 a. metrocluster switchback –simulateコマンドと同じルールを使用して、条件を満た

さない構成がないかチェックします。 b. 必要なすべてのクラスタ設定の完全なコピー（リバースベースライン）を、クラスタピア

リングネットワーク経由で送信します。これにより、スイッチオーバー中に発生した設定変更が、復帰するクラスタにレプリケートされます。

c. I/Oの一貫性を保つために NVRAMをディスクにフラッシュします。 d. クラスタ Bが、クラスタ Aのボリュームおよびアグリゲートをすべてオフラインにします。

この時点で、クライアントとホストの I/O は一時停止します。SVM と LIF はオンのままで、SANホストがパスの問い合わせに応答できるように、クラスタ Aの LUNへのパスは可能なかぎり使用可能な状態に保たれます。

e. データアグリゲートのディスク所有権は、スイッチオーバー前の状態にリストアされます。クラスタ Aが、所有権が戻ったアグリゲートをWAFLに組み入れ、そのボリュームをオンラインにします。

f. クラスタ Bがクラスタ Aの SVMと LIFをオフラインにします。 g. クラスタ Aが、自身の SVM、次に LIFをオンラインにし、プロトコルサービスを再開しま

す。クライアント、ホスト、およびアプリケーションからの一時停止していた I/Oが、クラスタ Aで自動的に再開されます。


tme-mcc-B::> metrocluster switchback [Job 2856] Job succeeded: Switchback is successful. tme-mcc-B::> metrocluster operation show Operation: switchback State: successful Start Time: 2/27/2015 17:21:36 End Time: 2/27/2015 17:22:38 Errors: - tme-mcc-B::> metrocluster node show DR Configuration DR Group Cluster Node State Mirroring Mode ----- ------- ------------------ -------------- --------- -------------------- 1 tme-mcc-B tme-mcc-B1 configured enabled normal tme-mcc-B2 configured enabled normal tme-mcc-A tme-mcc-A1 configured enabled normal tme-mcc-A2 configured enabled normal

16. これでスイッチバックは完了です。『MetroCluster管理およびディザスタリカバリガイド』には、テストまたはメンテナンス目的でスイッチオーバーを実行する場合の詳細な手順が記載されています。

3.4 強制的スイッチオーバーの実行強制的スイッチオーバーがネゴシエートスイッチオーバーと異なる点は、障害が発生したサイトのノードおよびストレージが使用できないか、または最初に完全にフェンシング（分離）する必要がある点です。稼動しているクラスタが、サイト Aのリソースには一切アクセスせずに、すべての手順を実行します。ここでは、計画外（強制的）スイッチオーバーの手順の概要を示します。詳細な手順については、『MetroCluster管理およびディザスタリカバリガイド』を参照してください。 1. 災害の影響を受けたサイトをフェンシングします（『MetroCluster管理およびディザスタリカ

バリガイド』の「ディザスタサイトのフェンシング」を参照）。計画的スイッチオーバーとは異なり、サバイバサイトで強制的スイッチオーバーを実行する必要があります（metrocluster switchover –force-on-disaster true）。以下の手順が自動的に実行され、サバイバサイトでサービスが再開されます。 a. 稼働しているクラスタノードが、障害が発生したサイトの pool1ディスクの所有権を取得し

ます。 b. 稼動しているクラスタが、障害が発生したサイトのアグリゲートを同化し、同サイトのボ

リュームをオンラインにします。 c. コミットされていない I/Oが再生されます。 d. 稼働しているクラスタが、障害が発生したクラスタの SVMと LIFをオンラインにし、プロ

トコルサービスを開始して、ストレージサービスを再開します。障害が発生したサイトからのクライアント、ホスト、アプリケーションの I/Oが再開します。

2. SVMピアリングを手動で再確立します（デスティネーションがMetroCluster構成内にある場合）。

3.5 強制的スイッチオーバー後のボリュームの保護まれに、スイッチオーバー後にボリュームの不整合が発生する場合があります。考えられる原因は、ローリングエラーです。たとえば、まずすべてのサイト間リンクで障害が発生して 2つのサイトが互いに分離され、続けてサイト Aで完全なハードウェア障害が発生したとします。リンクの障害とハードウェアの障害の間にサイト Aで何らかの書き込みが発生した場合、サイト Bに伝播されません。その後サイト Bへのスイッチオーバーが実行されると、サイト Bのデータはサイト Aと不整合になります。


MetroCluster構成は、ノード内で NVRAMの不整合の有無をチェックすることによって、この状況を検出します。影響を受けているボリュームがあった場合、必要に応じてアプリケーションレベルのリカバリを実行できるようにそのボリュームをフェンシングします。NVRAMの不整合が検出されない正常な状況では、ボリュームはフェンシングされず、スイッチオーバー後に自動的に使用可能になります。フェンシングされていないボリュームでは、LUNが自動的にオンラインになり、NFSのファイルシステム ID（FSID）は変更されないため、クライアントのマウントに変更はありません。ボリュームがフェンシングされている場合、LUNはオフラインのままで、FSIDが変わるため、NFSクライアントには古いファイルハンドルが返されます。管理者は、失われたデータに対して適切な処理を行ったあとで、クライアントおよびアプリケーションに対してデータを使用可能にするタイミングを判断できます。SMBクライアントは影響を受けません。スイッチオーバー後にデータの不整合が検出された場合、SVMルートボリュームおよびLUNを含むボリュームには、NVFAILというフラグが自動的に設定されます。必要な場合に新規または既存のボリュームに対してNVFAILを設定できるようにするには、volume createコマンドまたはvolume modifyコマンドで、–nvfailフラグをそれぞれ指定します。スイッチオーバー後にNVFAILフラグが設定されたボリュームはフェンシングされ、手動でフェンシングが解除されるまでクライアントからアクセスすることはできません。ボリュームのフェンシングを解除するには、volume modifyコマンドの-in-nvfailed-stateパラメータをアドバンストモードで使用します。ルートボリュームがNVFAIL状態の場合は、ルートリカバリ手順を使用する必要があります。

データベースアプリケーションで使用するボリュームには、必ずNVFAILを設定することを推奨します。このトピックの詳細については、『MetroCluster管理およびディザスタリカバリガイド』を参照してください。

3.6 完全なサイト災害を含む強制的スイッチオーバーからのリカバリリカバリプロセスは、強制的スイッチオーバーをトリガーしたイベントの性質によって異なります。一方のサイトで突然長時間の停電が発生した場合は、ハードウェアの交換は不要なため、電源が回復したあとでスイッチバックを実行できます。ただし、ハードウェアが破損した場合（データセンター自体の破損までを含む）は、交換後にスイッチバックを実行する必要があります。この場合は、サイトが長時間にわたってスイッチオーバーモードとなる可能性があります。スイッチオーバーモードで動作中に稼働しているクラスタの HAペアでローカルのテイクオーバーイベントが発生すると、稼働ノードが 1つだけになる可能性があります。この時点で残っているノードは、最後の単一点障害となります。そのため、サバイバサイトに影響する災害が続けて発生すると、ストレージの可用性に影響が及びます。元の災害サイトが復旧するまでは、災害に対する保護はありません。スイッチオーバーモードの間は、十分な注意を払って監視し、障害が続けて発生した場合はできるだけ迅速にリカバリしてください。稼働しているクラスタで clustered Data ONTAPのメジャーアップグレードを行うことは、処理が非常に複雑になるため、避けてください。マイナーアップグレードは、スイッチオーバーモードでも実行できます。ただし、事前にサポートの指示を受けて具体的な推奨事項を確認し、最終的なスイッチバックを実行する際に必要な考慮事項をチェックすることを推奨します。たとえば、スイッチバックを実行する前に、災害サイトで停止しているノードを、同じリリースの clustered Data ONTAPにアップグレードする必要があります。強制的スイッチオーバー後のリカバリ手順については、『MetroCluster管理およびディザスタリカバリガイド』を参照してください。ハードウェアの交換が必要な場合は、「両方のコントローラで障害が発生した場合の災害からの復旧」を、ハードウェアの交換が不要な場合は「コントローラの交換を伴わないサイト障害からのリカバリ」を参照します。


4 相互運用性 MetroCluster構成を監視するための管理ツールは、OnCommand System Manager、OnCommand Unified Manager、MetroCluster Tiebreakerソフトウェア、Configuration Advisorなど複数あります。ここでは、これらのツールをMetroClusterで使用する方法について説明します。 SnapMirror、SnapVault、QoS、Flash Poolなどのclustered Data ONTAPの標準ツールについても、MetroCluster構成との互換性や連携について紹介します。一般に、初期セットアップとテストの完了後、MetroCluster構成は 2つの独立したクラスタとして管理されます。System Manager、CLI、Workflow Automation（WFA）、その他の APIベースのツールなど、希望する管理インターフェイスを使用して、必要に応じてどちらかのクラスタで SVM（および関連するボリューム、LIF、LUN、アクセスポリシーなど）を作成して設定します。

4.1 OnCommand System Manager OnCommand System Managerは、clustered Data ONTAP 8.3.xオペレーティングシステムに組み込みのWeb ベースのアプリケーションで、URL にクラスタ管理 LIFを指定してアクセスします。MetroCluster構成のセットアップが完了したら、System Managerを使用して、SVMおよび関連するオブジェクトを作成、設定できます。もちろん、CLI、WFA、その他の APIベースの方法も使用可能で、サポートされています。すべての SVMが両方のクラスタに表示されますが、クラスタが安定した状態のとき、一方のクラスタで管理または更新できるのは、サブタイプの状態が sync_sourceである SVMのみです。図 10では、SVM svm1_mccAはクラスタ Aの sync_source SVMであり、状態は running、設定状態はunlockedとなっています。SVM svm1_mccB-mcは、SVM svm1_mccBの sync_destinationコピーであり、クラスタ Bで状態が stopped、設定状態が lockedと表示されています。

図 10）クラスタ A：sync_source SVMがロック解除、sync_destination SVMがロック

クラスタ Bの System Managerで同じ SVMを表示した場合、SVM svm1_mccA-mcは状態がstoppedで設定状態が locked（サブタイプ sync_destination）、SVM svm1_mccBは状態がrunningで設定状態が unlocked（サブタイプ sync_source）となります。

図 11）クラスタ B：sync_source SVMがロック解除、sync_destination SVMがロック

スイッチオーバーが実行されると、sync_destination SVMはロック解除され、稼働しているクラスタで更新可能となります。たとえば新しいボリュームや LUNをプロビジョニングしたり、エクスポートポリシーを作成または更新したりできます。図 12 は、クラスタ Bをクラスタ Aにスイッチオーバーしたあとのステータスを示しています。SVM svm1_mccB-mcは、クラスタ Aで running、unlockedの状態となっています。


図 12）スイッチオーバー後の SVM：すべての SVMがロック解除

4.2 OnCommand Unified Managerとヘルスモニタ OnCommand Unified Manager（OCUM）6.2は、MetroClusterのトポロジおよび構成（ノード、リンク、ブリッジ、スイッチ、ストレージを含む）の検出、監視、アラートをサポートします。OCUMは、MetroCluster用の組み込みのシステムヘルスモニタが提供する以下の機能を活用します。 • スイッチおよびファイバブリッジの SNMP監視 • MetroClusterおよびクラスタトポロジの詳細。SyncMirrorストレージレプリケーションおよび

NVRAMレプリケーションのステータスを含む • 問題発生時のアラート OCUMを使用してすべての MetroClusterインストレーションを監視することを推奨します。OCUMは、エンタープライズ監視ツールと組み合わせて使用できます。 OCUMは、クラスタのトポロジ情報を使用して、MetroCluster構成全体を図示します。この構成図は、OCUMが MetroClusterシステムを形成しているクラスタを検出すると自動的に作成されます。以降、ヘルスモニタを定期的にポーリングし、検出されたエラーがあれば OCUMアラートに変換します。OCUMが発行するアラートには、考えられる原因および推奨される解決策に関する情報も含まれています。アラートは、適切に処理するためにシステム管理者に割り当てることができます。OCUM 6.2と clustered Data ONTAP 8.3.xを連携させている場合、アラートはポーリングプロセスを使用して検出されます。その結果、タイミングによっては、アラートが表示されるまで数分かかる可能性があります。 OCUMでは、MetroClusterのヘルスモニタによって収集された情報を使用して、構成に関する情報とコンポーネントに関連するイベントを収集します。ヘルスモニタは、SNMPを使用してスイッチおよびブリッジを監視します。OnCommand Unified Managerは、コンポーネントの論理図を作成し、デバイスをエンドツーエンドで監視するとともに、同期ミラーリング（アグリゲートの SyncMirrorおよび NVRAMミラーリング）の状態も監視します。デバイスまたはリンクに問題があるとイベントが生成され、生成されたイベントは OCUM インターフェイスを使用して管理および割り当てできます。接続を監視することにより、OCUMはMetroCluster構成内のハードウェアの健常性を監視および確認し、デバイス間の物理的接続に関連する問題にはアラートを生成します。アラートには、問題の考えられる原因および影響と、推奨される解決方法が提示されます。


図 13）OCUMのデバイスおよびリンクの監視

レプリケーションの監視では、MetroCluster内の同期関係（アグリゲートの SyncMirrorおよびNVRAMレプリケーション）の健常性が表示されます。

図 14）OCUMのレプリケーションの監視


4.3 AutoSupport MetroCluster構成に固有の AutoSupportメッセージも自動的に送信されます。すべてのMetroCluster構成で AutoSupportを使用することを強く推奨します。MetroCluster構成では、SyncMirrorプレックスの障害、スイッチオーバーやスイッチバックの障害を含む一定のイベントに対応して、ケースが自動的に作成されます。これにより、ネットアップサポートが迅速かつプロアクティブに対応できるようになります。テスト目的または計画的処理（スイッチオーバーおよびスイッチバックの機能の確認など）のみを目的としてMetroClusterの処理を実行する場合は、ユーザトリガー型 AutoSupportメッセージを送信して、テストが実行中であることをネットアップサポートに通知する必要があります。これにより自動ケースがエスカレーションされることはなく、実際には災害が発生していないことをネットアップサポートが把握できます。ネットアップの技術情報アーティクル 1015155（ネットアップサポートへのログインが必要）に、この目的での AutoSupportの使用に関する詳細が記載されています。 My AutoSupportには、ダッシュボードに加えて、システムステータス、物理接続、ストレージ使用率、ヘルスサマリ、その他を含むMetroCluster構成が視覚的に表示されます。

4.4 MetroCluster Tiebreakerソフトウェア MetroCluster構成自体には、サイト障害を検出してスイッチオーバーを開始する機能は備わっていません。各サイトが相手サイトの障害を監視することでこれらの機能を実装することはできないからです。つまり、あるクラスタからもう一方のクラスタへの応答がない場合、純粋なサイト障害が原因の場合だけでなく、すべてのサイト間リンクの障害が原因の場合もあるからです。すべてのリンクで障害が発生した場合、MetroCluster構成は引き続き動作し、ローカル I/Oは処理されますが、リモート同期は行われません。少なくとも 1つのサイト間リンクがリストアされると、レプリケーションが自動的に再開し、その間に行われた変更が取り戻されます。このシナリオでは自動スイッチオーバーは望ましくありません。それぞれのクラスタが、もう一方のクラスタで障害が発生したと認識してスイッチオーバーを実行しようとし、その結果「スプリットブレイン」と呼ばれる状況が発生するためです。スイッチオーバーの必要性は、人間、またはアプリケーション主導で判断できます。ネットアップは、MetroCluster Tiebreakerソフトウェアという機能をサポートおよび提供しています。Tiebreakerは第 3のサイトにインストールし、2つのクラスタそれぞれに別々に接続します。Tiebreakerソフトウェアの目的は、個々のサイト障害とサイト間リンクの障害の両方を監視および検出することです。MetroCluster Tiebreakerソフトウェアは、サイト災害時に SNMPアラートを生成できます。オブザーバーモードで動作し、スイッチオーバーが必要な災害を検出してアラートを送信します。その後、管理者がスイッチオーバーを手動で実行できます。または、Program Variation Request（PVR）経由で、災害発生時に自動的にスイッチオーバーを実行するように Tiebreakerソフトウェアを設定することもできます。 Tiebreakerソフトウェアは、ノード、HAペア、クラスタの各レベルで関連するオブジェクトを監視し、サイトの可用性に関する統合的な論理ビューを作成します。クラスタのハードウェアおよびリンクに対してさまざまな直接的、間接的チェックを実行し、検出した障害（HAテイクオーバーイベント、サイト障害、すべてのサイト間リンクの障害）に応じて状態を更新します。直接リンクは、SSHを経由したノードの管理 LIFへのリンクです。クラスタへのすべての直接リンクの障害はサイト障害を示しており、その場合、クラスタがすべてのデータの処理を停止します（すべての SVMが停止）。間接リンクは、いずれかのサイト間（FC-VI）リンクまたはインタークラスタ LIFで、クラスタがピアに到達できるリンクです。クラスタ間の間接リンクが失敗し、ノードへの直接リンクが成功する場合は、サイト間リンクが停止しているためにクラスタが互いに分離されていることを示しています。このシナリオでは、MetroClusterの処理は継続します。詳細については、表 5を参照してください。

https://kb.netapp.com/support/index?page=content&id=1015155


図 15）MetroCluster Tiebreakerソフトウェアの動作

MetroCluster Tiebreakerソフトウェアは、ネットアップサポートサイトで配布されているスタンドアロンアプリケーションです。Linuxホストまたは VM上で動作します。MetroCluster Tiebreakerソフトウェアをダウンロードするには、ネットアップサポートサイト（http://mysupport.netapp.com/NOW/cgi-bin/software/）のソフトウェアダウンロードセクションで、MetroCluster Tiebreakerを選択します。『インストレーションおよび構成ガイド』および『システムの前提条件』も、このリンクから入手できます。Tiebreakerソフトウェアには、clustered Data ONTAPの追加ライセンスは必要ありません。

4.5 Config Advisor Config Advisorは、構成の検証や健常性のチェックに使用できるネットアップシステム向けのツールです。Config Advisor 4.1はMetroCluster構成をサポートし、MetroCluster専用のルールが40以上組み込まれています。Config Advisor、MetroClusterプラグイン、およびドキュメントをダウンロードするには、Config Advisorにアクセスしてください。Config AdvisorをMetroClusterシステムに対して実行したときの出力例を図16に示します。

http://mysupport.netapp.com/NOW/cgi-bin/software/

http://mysupport.netapp.com/NOW/download/tools/config_advisor/


図 16）Config Advisorのサンプル出力

4.6 Quality of Service (QoS) QoSをMetroCluster構成で使用すると、Data ONTAPクラスタでの典型的なユースケースを拡張できます。QoSポリシーは、必要に応じて動的に適用および変更できます。QoSをMetroCluster環境で使用する場合の例をいくつか挙げます。 • 両方のクラスタがアクティブな通常運用時は、ISL経由のトラフィックが増える期間が観察され

た場合に QoSポリシーを適用できます。アプリケーションの I/Oを制限すると、必然的にディスクおよび NVRAMのレプリケーションの ISLトラフィックが減り、ISLの一時的な過負荷を防止できます。

• 構成がスイッチオーバーモードで動作しているときは、半分のノードだけがアクティブなため、使用可能なシステムリソースは少なくなります。システムのサイジングに適用されるヘッドルームによっては、使用可能なリソースが減少すると、クライアントやアプリケーションのワークロードに影響が出る可能性があります。重要でないワークロードに上限（IOPSまたはスループット）を適用する QoSポリシーを設定することで、重要なワークロードで使用可能なリソースを増やすことができます。このポリシーは、スイッチバック後に通常運用が再開された時点で無効にすることができます。

QoSの使用方法については、ホワイトペーパー『Clustered Data ONTAP Quality of Service Performance Isolation for Multi-Tenant Environments』および clustered Data ONTAP製品ドキュメントの『システムアドミニストレーションガイド（クラスタ管理）』の「ストレージQoSを使用したワークロードパフォーマンスの管理」を参照してください。

http://www.netapp.com/jp/system/pdf-reader.aspx?pdfuri=tcm:10-113725-16&m=wp-7191.pdf

http://www.netapp.com/jp/system/pdf-reader.aspx?pdfuri=tcm:10-113725-16&m=wp-7191.pdf

http://mysupport.netapp.com/documentation/productlibrary/index.html?productID=30092


4.7 SnapMirrorと SnapVault SnapMirrorおよび SnapVaultの関係は、MetroClusterで保護されているボリュームをソースまたはデスティネーションとして作成できます。データ保護関係は、MetroCluster環境内（同じクラスタまたはもう一方のクラスタ）で、または MetroClusterを使用しない他の clustered Data ONTAPクラスタとの間で作成できます。MetroClusterで保護されているボリュームを使用してこれらの関係を作成する場合は、次の点を考慮してください。 • MetroCluster構成には含まれないクラスタを関係のソースまたはデスティネーションとして使

用する場合は、そのクラスタにMetroClusterの両方のクラスタをピアリングして、スイッチオーバーまたはスイッチバック後もレプリケーションを継続できるようにする必要があります。たとえば、MetroCluster環境がクラスタ Aと Bで構成されていて、クラスタ A上のボリュームをSnapMirrorを使用してクラスタ Eにミラーする場合は、クラスタ Aと Bの両方をクラスタ Eとピアリングする必要があります。

• SnapMirrorまたは SnapVaultの処理は、該当するボリュームを含む SVMを実行しているクラスタからのみ実行できます。同じボリュームを複数のクラスタで同時にオンラインにすることはできないため、もう一方のサイトで SyncMirrorを使用してミラーされたボリュームのコピーはどのような目的でも使用できません（NetApp FlexClone®、SnapMirror、SnapVault、その他のボリュームをオンラインにする必要のある処理を含む）。もう一方のクラスタがボリュームにアクセスするのは、スイッチオーバーが実行された場合のみです。前述の例では、安定した状態では、SnapMirror関係はクラスタ A内のボリュームからクラスタ E内のボリュームに対して確立されています。クラスタ Bの対応する sync_destination SVMにボリュームがオフラインで存在したとしても、そのボリュームは使用できません。

• MetroClusterボリュームが SnapMirrorまたは SnapVaultソースの場合、スイッチオーバーまたはスイッチバックの際にピアリング関係が自動的に更新され、レプリケーションは次にスケジュールされた時刻に自動的に再開します。手動で開始したレプリケーション処理は、明示的に再開する必要があります。

• MetroClusterボリュームが SnapMirrorまたは SnapVaultデスティネーションの場合、スイッチオーバーおよびスイッチバック後にピアリング関係の確認と再作成が必要です。スイッチオーバーまたはスイッチバックが完了するたびに、snapmirror createを使用して各レプリケーション関係を再作成する必要があります。SnapMirrorまたは SnapVaultのベースラインを再設定する必要はありません。WFAワークフロー「Recreate SnapMirror and SnapVault Protection after MetroCluster Switchover and Switchback」を使用すると、関係の再作成を自動化できます。

4.8 ボリューム移動ボリューム移動（NetApp DataMotion™ for Volumes）を使用したデータ移行は、clustered Data ONTAPの中核となるノンストップオペレーションの 1つです。ボリュームを無停止で移動することで、容量やパフォーマンスの分散や、テクノロジの更新が可能となります。ボリュームは、クラスタ内のアグリゲート間で無停止で移動でき、所属する SVMに変更はありません。ボリューム移動を使用して別の SVMまたは別のクラスタへボリュームを転送することはできません。ボリューム移動は、ボリュームの所有者であるクラスタ上で開始します。MetroCluster環境では、ソースおよびデスティネーションのアグリゲート内のローカルおよびリモートのプレックスは、SyncMirrorを使用して自動的に同期されます。ボリューム移動が完了すると、新しいアグリゲートの場所が、クラスタピアリングネットワークを介してもう一方のクラスタに伝播されます。ボリューム移動ジョブを実行中にスイッチオーバーコマンドが実行され、その時点でジョブの重要なカットオーバーフェーズにまだ達していない場合は、ジョブは自動的に終了されます。この場合、関連する一時（TMP）ボリュームを手動で削除し、その後ボリューム移動ジョブを最初からやり直す必要があります。ただし、コミットフェーズに達している場合は、アグリゲートがスイッチオーバーされたあとに、ジョブコミットフェーズが再開します。この場合は EMSがログに記録され、元のソースボリュームを手動で削除する必要があります。ボリューム移動の実行中は、スイッチバックは実行できません。ボリューム移動ジョブが完了するまで、スイッチバックコマンドは拒否されます。

http://automationstore.netapp.com/pack-list.shtml


MDVはアドバンストモードで移動できますが、この処理はネットアップサポートから指示された場合にのみ実行することを推奨します。以下の警告メッセージが表示されます。処理を確定すると、ボリューム移動が実行されます。

tme-mcc-A::*> vol move start -vserver tme-mcc-A -volume MDV_CRS_e8fef00df27311e387ad00a0985466e6_A -destination-aggregate aggr1_tme_mcc_B1 Warning: You are about to modify the system volume "MDV_CRS_e8fef00df27311e387ad00a0985466e6_A". This may cause severe performance or stability problems. Do not proceed unless directed to do so by support. Do you want to proceed? {y|n}:

MDVのボリューム移動を行う主な理由は、ストレージシェルフの交換などのために、MDVを含むアグリゲートを削除する必要がある場合です。この場合、アグリゲートを完全に退避させる必要があるため、MDVが含まれていない別のアグリゲートに MDVを移動する必要があります。耐障害性を確保するため、各クラスタの 2つの MDVは、別々のアグリゲート、できれば別々のノードに配置する必要があります。

4.9 Flash Pool Flash Poolは MetroCluster構成でサポートされています。Flash Poolアグリゲートには、各サイトに同一のプレックスが 1つ含まれている必要があります。MetroCluster DRグループの Flash Poolで使用可能な最大キャッシュサイズは、同じモデルの HAペアでサポートされているサイズの半分です。たとえば、MetroClusterでない FAS8080の最大キャッシュサイズは 144TiBですが、MetroClusterでは 72TiBとなります。 Flash Poolの動作は MetroClusterに対して透過的です。他のアグリゲートの場合と同様に、2つのプレックス間でキャッシュの同期が保たれます。スイッチオーバーが実行された場合も Flash Poolキャッシュは同期された状態のため、すぐに使用できます。アグリゲート Snapshotコピーの再同期時間（アグリゲート Snapshotの自動コピー間隔）は、SyncMirrorまたはMetroClusterを使用している Flash Poolアグリゲートでは 5分に設定（デフォルトの 60分から変更）する必要があります。5分にすることで、データが必要以上の間フラッシュストレージに保持されることがなくなります。次のコマンドを使用します。 storage aggregate modify -aggregate <aggrname> -resyncsnaptime 5

SSD用のアドバンストディスクパーティショニングは、MetroCluster構成内の Flash Poolではサポートされていません。

4.10 All Flash FAS（AFF） AFFシステムは、8000シリーズコントローラに clustered Data ONTAP 8.3オペレーティングシステムを搭載し、ミリ秒未満のレイテンシと最大 400万 IOPS（1秒あたりの入出力操作）のスループットで、高速なレスポンスが要求されるビジネスアプリケーションに対応します。低いレイテンシで高いアプリケーションデータスループットを実現するだけでなく、最先端のデータ管理機能も提供します。 AFFシステムは、400GB、800GB、800GB NSE、1.6TBのハイパフォーマンス SSDを使用するため、コストや密度に関するさまざまなニーズを満たす柔軟な構成が可能です。 MetroClusterは AFFに完全に対応しており、ハイパフォーマンスと低レイテンシを実現します。AFFは MetroClusterに対して透過的であり、2ノードおよび 4ノードのすべての MetroCluster構成でサポートされています。


5 MetroClusterへの移行このテクニカルレポートでは、移行とは、以下の環境からMetroCluster構成へ移動するプロセスのことを言います。 • MetroClusterを使用しない 7-Mode構成 • MetroCluster 8.2.1以前（7-Mode）、ファブリックまたはストレッチMetroCluster • clustered Data ONTAP このテクニカルレポートは、サードパーティシステムからの移行には対応していません。一般的な手順では、MetroCluster 8.3.x環境をセットアップしてデータおよび設定を移行します。 MetroCluster 8.3.x環境は、クリーンなシステム上でゼロからセットアップする必要があります。ノード上にデータが存在する場合、metrocluster configureコマンドを実行するとエラーが返されます。既存の clustered Data ONTAP環境をそのまま変換して、MetroCluster構成として動作するように設定することはできません。MetroCluster 8.3.xに移行する場合、既存の機器をMetroCluster環境で再利用するかどうかによって、基本的に次の 2つの方法が考えられます。 • 既存のハードウェアが MetroCluster 8.3.xでサポートされていない場合や、ハードウェアの更

新を検討している場合は、新しいMetroCluster構成を購入してデータをコピーします。 • 既存のハードウェアの一部またはすべてが MetroCluster 8.3.xでサポートされている場合は、

4ノードの MetroCluster環境の構築に必要な機器（スイッチ、ブリッジ、コントローラ、ストレージなど）を追加で購入します。IMTを参照して、既存の機器が新しいリリースでサポートされていることを確認してください。次に、以下のいずれかの方法を使用して移行を実施します。 − すべてのデータを既存の環境から一時的な場所にコピーします。既存の機器と新しい機器を

組み合わせて MetroClusterをセットアップして、データをリストアします。 − 一時的に使用できる代替機器がある場合は、その機器を現在の環境にステージングし、機器

の中身を空にして新しいMetroCluster環境を作成するか、新しい機器と組み合わせて新しい MetroCluster環境を作成することができます。これらのシナリオについては、あとで説明します。

− 再利用するコントローラには、必要に応じてMetroClusterをサポートするために正しいカードを追加する必要があります。具体的には、コントローラ 1台あたり 16Gb FC-VIカード 1枚と FCイニシエータポート 4個です。

いずれの場合も、clustered Data ONTAP 8.3.xを実行している新しいMetroCluster環境にデータをコピーする必要があります。

5.1 MetroCluster 8.3.xへのデータのコピーここでは、MetroCluster環境に移行するためのさまざまなシナリオについて説明します。数多くのバリエーションが考えられるため、詳細な計画を立てる際は、プロフェッショナルサービスを利用することを推奨します。データのコピー方法や設定の移行方法は、移行元のシステムによって異なります。

clustered Data ONTAPからの移行ホストまたはアプリケーションベースの方法、または SnapMirrorを使用して、clustered Data ONTAPからMetroCluster構成へデータをコピーできます。SnapMirrorでは、すべての Snapshotコピーデータも含め、64ビットのソースデータのみをコピーできます。詳細については、TR-3978『64-Bit Aggregates Overview and Best Practices』を参照してください。ハードウェア再利用のシナリオハードウェアを退避後に再利用する場合は、まずそのハードウェアが MetroCluster 8.3.xでサポートされていることを確認します。一時的なノードとストレージが必要です。一時的なノードが、クラスタ混在ルールに従って既存のクラスタでサポートされている場合は、以下のプロセスを使用できます。MetroCluster環境ではすべてのノードが同じタイプである必要があるため、この方法は、使用可能な一時ノードのモデルが既存のノードと異なる場合に適しています。




1. 2つの一時ノードと十分なストレージを現在の clustered Data ONTAPクラスタに追加します。 2. vol move と LIF の移行を使用して、元のノードから一時ノードへデータを無停止で退避します。 3. 退避したノードをクラスタから削除します。 4. 退避したノードの内容を完全消去して、新しいMetroCluster環境に再インストールして設定し

ます。ノードおよびストレージを必要に応じて追加して、DRグループおよび FCスイッチとファイバブリッジを構成します。

5. clustered Data ONTAPクラスタの一時ノードから新しいMetroCluster環境へ、データを移行します。

6. カットオーバー後、一時ノードは戻すことができます。以下は、一時的な代替機器を使用する、clustered Data ONTAPから MetroClusterへのもう 1つの移行方法です。 1. 一時ノードを使用するか、一時ノードと購入したノードを組み合わせて使用して、MetroCluster

システムをインストールします。稼働しているMetroCluster構成内のすべてのノードは、同じコントローラモデルである必要があります。たとえば、既存の 4台の FAS8080を、MetroCluster構成の 2つのクラスタとして再導入するとします。この場合、MetroClusterの初期設定には 4台の一時コントローラが必要です。既存のコントローラとタイプ（この場合は FAS8080）が一致する必要はありませんが、4 台すべてが同じモデル（FAS8060×4 など）である必要があります。より一般的なシナリオは、既存の 2ノードの clustered Data ONTAPクラスタを MetroClusterに移行し、2つのノードを新たに購入して 2番目のサイトに設置する方法です。たとえばFAS8080コントローラだと仮定すると、一時的な FAS8080を一方のサイトに、新たに購入した 2台の FAS8080をもう一方のサイトに配置して、MetroCluster構成を導入します。一時的な機器は、既存の機器と同じモデルタイプである必要があります。

2. clustered Data ONTAPから新しい MetroCluster環境へ、データを移行します。 3. MetroCluster環境の一時コントローラを、退避した元の clustered Data ONTAPノードに置き

換えます。既存のノードと一時ノードが同じモデルの場合はテイクオーバー / ギブバックを、別々のモデルの場合はアグリゲートの再配置を実施します。

4. MetroCluster環境で一時ストレージが使用されている場合は、元のストレージをノードに接続し、vol moveと無停止でのシェルフの取り外しを使用して一時ストレージを退避します。

第 3の方法は次のとおりです。 1. アグリゲートの再配置またはテイクオーバー / ギブバックを使用して、既存の clustered Data

ONTAPノードをアップグレードするか、一時ノードに置き換えます。 2. 中身を空にしたノードと新規または一時的なストレージを使用してMetroClusterシステムをイン

ストールします。 3. clustered Data ONTAPから新しい MetroCluster環境へ、データを移行します。 4. MetroCluster環境で一時ストレージが使用されている場合は、元のストレージをノードに接続

し、vol moveと無停止でのシェルフの取り外しを使用して一時ストレージを退避します。

Data ONTAP 7-Modeからの移行 7-Modeシステムで実行されている MetroClusterがファブリックかストレッチかにかかわらず、同じ方法を使用してMetroCluster環境にデータを移行できます。 7-Mode Transition Tool（7MTT）バージョン 2.0以降、7-Mode（ファブリックMetroClusterとストレッチMetroClusterの両方）からMetroCluster 8.3.xへの移行がサポートされています。データは 7-Modeのコントローラから MetroCluster 8.3.xのデスティネーションクラスタへコピーされます。MetroCluster 8.3.xへボリュームをコピーすると、データは自動的にリモートプレックスに同期されます。MetroCluster 8.3.x ではミラーされたアグリゲートのみがサポートされているため、7MTTの事前チェックにより、ミラーされていないアグリゲート内のすべてのボリュームをミラーされたアグリゲートに移行するよう推奨されます。カットオーバー時には、アプリケーションが短時間停止します。


再同期や VMware Storage vMotionなど、アプリケーション / クライアント / ホストレベルの方法も使用できます。詳細については、TR-4052『Successfully Transitioning to Clustered Data ONTAP』および TR-4336『Enterprise Application Transition to Clustered Data ONTAP 8.3』を参照してください。 clustered Data ONTAP 8.3.xでは、64ビットのアグリゲート、ボリューム、Snapshotコピーのみがサポートされています。7MTTまたは SnapMirrorを使用する場合は、すべてのデータを 64ビットに変換してから、MetroCluster環境にコピーする必要があります。SnapMirrorを使用しないその他の方法は、この要件の対象とはなりません。詳細については、TR-3978『64-Bit Aggregates Overview and Best Practices』を参照してください。7MTTを使用する場合は、まず clustered Data ONTAP 8.3.xへの移行をサポートしているリリースに 7-Mode環境をアップグレードする必要があります。詳細については、このセクションで言及している移行関連の資料を参照してください。ファブリックMetroCluster環境で使用しているBrocade 6510スイッチおよび接続しているISLは、移行目的で共有可能です。1つのファブリックMetroCluster（FMC）環境からの移行時に、既存のISLを共有するBrocade 6510スイッチに1つのMetroCluster 8.3.x構成を接続できます。ただし、発生するトラフィックに十分に対応できる帯域幅を用意する必要があり、また、ISLはMetroCluster 8.3.xでサポートされている速度（ISLごとに4G以上）である必要があります。 7-Modeシステム上の既存のアプリケーションのワークロードにデータコピーによる負荷が加わるため、使用される帯域幅に注意を払う必要があります。ISLの限界に達しつつある場合（アプリケーションのスループットが低下している場合やクライアント / ホストのレイテンシが増加している場合など）は、7MTTでスロットルを動的に使用して、レプリケーションのペースを遅くすることができます。最初のベースラインデータ転送を作業量の少ない時間帯に実行して、ISLへの全体的な負荷を軽減することを推奨します。トラフィックを分散させるもう1つの方法は、最初のデータ転送の実行中、ディスクの電源をオフにしてMetroCluster 8.3.x環境内のリモートプレックスを無効にすることです。その後（7-Mode環境からのデータ転送完了後）にディスクの電源をオンにすると、アグリゲートはISL経由で自動的に再同期します。『MetroClusterインストレーションおよび構成ガイド』に、2つの環境間で Brocade 6510スイッチを共有する方法が記載されています。移行が完了すると、ファブリックMetroCluster構成はファブリックから切断されます。MetroCluster 構成は現在のスイッチポートに割り当てられたままです。もともと FMCが使用していたポートに MetroCluster 8.3.x構成を移動する場合は、システムの停止が必要です。移行中のファブリック共有がサポートされているのは Brocade 6510スイッチのみです。FMCでその他のスイッチモデルを使用している場合は、MetroCluster 8.3.x構成用に別のスイッチおよびISLが必要です。1つの MetroCluster 8.3.x構成とスイッチを共有できる FMCは 1つだけです。注： FMCの Brocade 6510スイッチでは 8G SFPを使用しますが、MetroCluster 8.3.xで 6510用

にサポートされるのは 16G SFPのみです。そのため、FCイニシエータ、FC-VIポート、ATTOブリッジを含むすべてのコンポーネントを、16G SFPを使用してスイッチポートに接続する必要があります。ただし ISLに接続するスイッチポートだけは例外で、16Gである必要はありません。したがって、MetroCluster 8.3.xコンポーネントを 6510に接続するためには、必要な数の 16G SFPを購入する必要があります。スイッチで 16Gをサポートするために追加のライセンスは必要ありません。『MetroClusterインストレーションおよび構成ガイド』で説明されているように、MetroCluster 8.3.xのコンポーネントの接続にはポート 23以上を使用します。これらのポートがまだ有効になっていない場合は、PoDライセンスを取得して有効化する必要があります。

5.2 ハードウェアを再利用する移行シナリオ clustered Data ONTAP環境からの移行と同様に、ハードウェアを退避後に再利用する場合もさまざまな移行方法があります。他の場合同様、ハードウェアがMetroCluster 8.3.xでサポートされていることを確認します。一時的なノードとストレージが必要です。以下は、7-Mode MetroCluster構成から移行する 1つ目の方法です。この方法は、一時的に使用する代替機器が元のノードと同じモデルのコントローラではない場合に適しています。







1. 代替機器を使用して 2つ目の 7-Mode MetroCluster環境を作動させます。 2. SnapMirrorまたはその他のユーティリティを使用して、元の 7-Mode MetroCluster構成から新

しいMetroCluster環境へデータをコピーします（7-Modeから 7-Mode）。スイッチによっては、7-Mode環境間で同じスイッチを共有できる場合もあります。

3. 退避したノードの内容を完全消去して、新しいMetroCluster 8.3.x環境で再インストールして設定します。ノードおよびストレージを必要に応じて追加して、DRグループおよび FCスイッチとファイバブリッジを構成します。スイッチとブリッジは、MetroCluster 8.3.xでサポートされていれば再利用できます。Brocade 6510スイッチは、移行中に 7-Modeシステムとclustered Data ONTAP MetroClusterシステム間で共有できます。

4. MetroCluster 8.3.xにデータを移行してカットオーバーします。次の方法は、既存の 7-Mode MetroCluster構成へのアップグレードがすぐに必要でMetroCluster 8.3.xへの移行はあとから行う場合や、既存の FMC / SMCを最近 FAS80x0ノードにアップグレードしていてMetroCluster 8.3.xで再利用できる場合に使用します。 1. FAS80x0を購入し、既存の FMC / SMCコントローラをアップグレードします。MetroCluster

8.3.xへの移行をすぐに実施する必要はありませんが、移行には同一のノードが 4つ必要となるため、同じモデルのコントローラモデルを購入可能である必要があります。

2. MetroCluster 8.3.xへ移行する準備ができたら、各サイト用に FAS80x0とシャーシを 1台ずつ追加で購入します。

3. 一時的な FAS80x0ノード 2つを一方のクラスタに、購入した FAS80x0ノード 2つをもう一方のクラスタに配置して、MetroCluster 8.3.xを設定します。ファイバブリッジ、および FMC環境の Brocade 6510スイッチを共有する場合を除き、追加のスイッチも必要です。

4. データを移行してMetroClusterにカットオーバーし、7-Mode環境の運用を停止します。 5. テイクオーバー / ギブバックを使用して、一時的な FAS80x0コントローラを、7-Mode環境の

データを完全に消去した機器で置き換えます。新規ノードと一時ノードはすべて同じモデルである必要があります。 7-Modeの機器をMetroCluster 8.3.xで再利用する場合は、再利用するハードウェアコンポーネント（コントローラ、カード、ストレージ、スイッチ、ISL速度）がすべてclustered Data ONTAP 8.3.xでサポートされていることを確認します。パーツの追加または交換が必要になる場合もあります。すべてのノードが同じコントローラモデルである必要があります。MetroCluster 8.3.xでは16G FC-VIカード（X1928）のみがサポートされ、8G FC-VIカード（X1927）はサポートされません。Brocade 6510スイッチのすべてのポート（ISLポートを除く）で、16G SFPが必要です。Cisco 9148スイッチは8Gのみなので、SFPを交換する必要はありません。適切なスイッチライセンスも用意する必要があります。他の場合同様に、IMTをチェックしてサポートされている構成（ISL速度を含む）を確認します。

関連資料 • NetApp MetroCluster製品ドキュメント


• TR-3982『NetApp clustered Data ONTAP 8.2概要』 http://www.netapp.com/jp/media/tr-3982-ja.pdf

• TR-3548『MetroCluster Version 8.2.1 Best Practices for Implementation』 http://www.netapp.com/us/media/tr-3548.pdf

• TR-3978『64-Bit Aggregates Overview and Best Practices』 http://www.netapp.com/us/media/tr-3978.pdf

• TR-4052『Successfully Transitioning to Clustered Data ONTAP』 http://www.netapp.com/us/media/tr-4052.pdf

• TR-4336『Enterprise Application Transition to Clustered Data ONTAP 8.3』 http://www.netapp.com/us/media/tr-4336.pdf








• TR-3982『NetApp Clustered Data ONTAP 8.2概要』 http://www.netapp.com/jp/media/tr-3982-ja.pdf

• NetApp Interoperability Matrix http://mysupport.netapp.com/matrix/

連絡先本テクニカルレポートの品質を向上していくため、皆様からのフィードバックをお寄せいただく専用の Eメールアドレスを用意しています。ご意見やご要望は、[email protected]までお寄せください。ご連絡の際は、件名に「TECHNICAL REPORT 4375」と添えてください。


http://mysupport.netapp.com/matrix/

mailto:[email protected]?subject=Technical%20Report%204375

本ドキュメントに記載されている製品や機能のバージョンがお客様の環境でサポートされるかどうかについては、ネットアップサポートサイトで Interoperability Matrix Tool（IMT）を参照してください。NetApp IMTには、ネットアップがサポートする構成を構築するために使用できる製品コンポーネントやバージョンが定義されています。サポートの可否は、お客様の実際のインストール環境が公表されている仕様に従っているかどうかによって異なります。著作権に関する情報 Copyright © 1994–2016 NetApp, Inc. All rights reserved. Printed in the U.S. このドキュメントは著作権によって保護されています。著作権所有者の書面による事前承諾がある場合を除き、画像媒体、電子媒体、および写真複写、記録媒体、テープ媒体、電子検索システムへの組み込みを含む機械媒体など、いかなる形式および方法による複製も禁止します。ネットアップの著作物から派生したソフトウェアは、次に示す使用許諾条項および免責条項の対象となります。このソフトウェアは、ネットアップによって「現状のまま」提供されています。ネットアップは明示的な保証、または商品性および特定目的に対する適合性の暗示的保証を含み、かつこれに限定されないいかなる暗示的な保証も行いません。ネットアップは、代替品または代替サービスの調達、使用不能、データ損失、利益損失、業務中断を含み、かつこれに限定されない、このソフトウェアの使用により生じたすべての直接的損害、間接的損害、偶発的損害、特別損害、懲罰的損害、必然的損害の発生に対して、損失の発生の可能性が通知されていたとしても、その発生理由、根拠とする責任論、契約の有無、厳格責任、不法行為（過失またはそうでない場合を含む）にかかわらず、一切の責任を負いません。ネットアップは、ここに記載されているすべての製品に対する変更を随時、予告なく行う権利を保有します。ネットアップによる明示的な書面による合意がある場合を除き、ここに記載されている製品の使用により生じる責任および義務に対して、ネットアップは責任を負いません。この製品の使用または購入は、ネットアップの特許権、商標権、または他の知的所有権に基づくライセンスの供与とはみなされません。このマニュアルに記載されている製品は、1つ以上の米国特許、その他の国の特許、および出願中の特許によって保護されている場合があります。権利の制限について：政府による使用、複製、開示は、DFARS 252.227-7103（1988年 10月）および FAR 52-227-19（1987年 6月）の Rights in Technical Data and Computer Software（技術データおよびコンピュータソフトウェアに関する諸権利）条項の(c) (1) (ii)項、に規定された制限が適用されます。商標に関する情報 NetApp、NetAppのロゴ、Go Further, Faster、AltaVault、ASUP、AutoSupport、Campaign Express、Cloud ONTAP、clustered Data ONTAP、Customer Fitness、Data ONTAP、DataMotion、Fitness、Flash Accel、Flash Cache、Flash Pool、FlashRay、FlexArray、FlexCache、FlexClone、FlexPod、FlexScale、FlexShare、FlexVol、FPolicy、GetSuccessful、LockVault、Manage ONTAP、Mars、MetroCluster、MultiStore、NetApp Insight、OnCommand、ONTAP、ONTAPI、RAID DP、RAID-TEC、SANtricity、SecureShare、Simplicity、Simulate ONTAP、Snap Creator、SnapCenter、SnapCopy、SnapDrive、SnapIntegrator、SnapLock、SnapManager、SnapMirror、SnapMover、SnapProtect、SnapRestore、Snapshot、SnapValidator、SnapVault、StorageGRID、Tech OnTap、Unbound Cloud、WAFL、その他の名称は、米国およびその他の国における NetApp, Inc.の商標または登録商標です。その他のブランドまたは製品は、それぞれを保有する各社の商標または登録商標であり、相応の取り扱いが必要です。ネットアップの商標の最新のリストは、http://www.netapp.com/jp/legal/netapptmlist.aspx でご覧いただけます。TR-4375-0915-JP


http://www.netapp.com/jp/legal/netapptmlist.aspx

Documents