MetroCluster マニュアル ( CA08871-401 )
MetroCluster構成の監視
MetroClusterコマンドとActive IQ Unified Managerを使用して、各種ソフトウェア コンポーネントの健全性およびMetroClusterの処理の状態を監視できます。
MetroCluster構成の確認
MetroCluster構成内のコンポーネントおよび関係が正しく機能していることを確認できます。チェックは、初期設定後と、MetroCluster構成に変更を加えたあとに実施する必要があります。また、ネゴシエート(計画的)スイッチオーバーやスイッチバックの処理の前にも実施します。
一方または両方のクラスタに対してmetrocluster check run
コマンドを短時間に2回実行すると、競合が発生してすべてのデータが収集されない場合があります。その結果、metrocluster check show
コマンドで想定した出力が表示されなくなります。
-
構成を確認します。
metrocluster check run
このコマンドはバックグラウンド ジョブとして実行され、すぐに完了しない場合があります。
cluster_A::> metrocluster check run The operation has been started and is running in the background. Wait for it to complete and run "metrocluster check show" to view the results. To check the status of the running metrocluster check operation, use the command, "metrocluster operation history show -job-id 2245"
-
最後に実行した
metrocluster check run
コマンドから、より詳細な結果を表示します。metrocluster check aggregate show
metrocluster check cluster show
metrocluster check config-replication show
metrocluster check lif show
metrocluster check node show
metrocluster check show
コマンドを実行すると、最後に実行したmetrocluster check run
コマンドの結果が表示されます。最新の情報を表示するために、metrocluster check show
コマンドを使用する前に必ずmetrocluster check run
コマンドを実行してください。次の例は、正常な4ノードMetroCluster構成の
metrocluster check aggregate show
コマンドの出力を示しています。cluster_A::> metrocluster check aggregate show Last Checked On: 8/5/2014 00:42:58 Node Aggregate Check Result --------------- -------------------- --------------------- --------- controller_A_1 controller_A_1_aggr0 mirroring-status ok disk-pool-allocation ok ownership-state ok controller_A_1_aggr1 mirroring-status ok disk-pool-allocation ok ownership-state ok controller_A_1_aggr2 mirroring-status ok disk-pool-allocation ok ownership-state ok controller_A_2 controller_A_2_aggr0 mirroring-status ok disk-pool-allocation ok ownership-state ok controller_A_2_aggr1 mirroring-status ok disk-pool-allocation ok ownership-state ok controller_A_2_aggr2 mirroring-status ok disk-pool-allocation ok ownership-state ok 18 entries were displayed.
次の例は、正常な4ノードMetroCluster構成の
metrocluster check cluster show
コマンドの出力を示しています。この出力は、必要に応じてネゴシエート スイッチオーバーを実行できる状態であることを示しています。Last Checked On: 9/13/2017 20:47:04 Cluster Check Result --------------------- ------------------------------- --------- mccint-fas9000-0102 negotiated-switchover-ready not-applicable switchback-ready not-applicable job-schedules ok licenses ok periodic-check-enabled ok mccint-fas9000-0304 negotiated-switchover-ready not-applicable switchback-ready not-applicable job-schedules ok licenses ok periodic-check-enabled ok 10 entries were displayed.
MetroCluster構成の確認および監視用コマンド
ONTAPには、MetroCluster構成を監視し、MetroCluster処理を確認するためのコマンドが用意されています。
MetroCluster処理のチェック用コマンド
実行する処理 |
使用するコマンド |
---|---|
MetroCluster処理のチェックを実行する 注: DR処理実行前のシステムの事前検証に使用できるコマンドは他にもあります。 |
|
MetroCluster処理に対する前回のチェック結果を表示する |
|
サイト間の設定レプリケーションに対するチェック結果を表示する |
|
ノード設定に対するチェック結果を表示する |
|
アグリゲート設定に対するチェック結果を表示する |
|
MetroCluster構成のLIF配置エラーを表示する |
|
MetroClusterインターコネクトの監視用コマンド
実行する処理 |
使用するコマンド |
---|---|
HAおよびDRのミラーリング ステータスと、クラスタ内のMetroClusterノードの情報を表示する |
|
MetroCluster SVMの監視用コマンド
実行する処理 |
使用するコマンド |
---|---|
MetroCluster構成の両方のサイトにあるすべてのSVMを表示する |
|
MetroCluster TiebreakerまたはONTAP Mediatorによる構成の監視
MetroCluster構成を監視して自動スイッチオーバーを開始する2つの方法の違いについては、「ONTAP MediatorとMetroCluster Tiebreakerの違い」を参照してください。
TiebreakerまたはMediatorのインストールと設定については、次のリンクを参照してください。
MetroCluster Tiebreakerソフトウェアで障害を検出する方法
TiebreakerソフトウェアはLinuxホストにインストールされます。Tiebreakerソフトウェアは、2つのクラスタおよびクラスタ間の接続ステータスを第3のサイトから監視する場合にのみ使用します。これにより、クラスタ内の各パートナーでISL障害(サイト間リンクが停止した場合)とサイト障害を区別することができます。
LinuxホストにTiebreakerソフトウェアをインストールしたら、災害状況を監視するMetroCluster構成内のクラスタを設定できます。
Tiebreakerソフトウェアでサイト間接続障害を検出する方法
MetroCluster Tiebreakerソフトウェアは、サイト間のすべての接続が失われると警告を表示します。
ネットワーク パスの種類
構成によっては、MetroCluster構成の2つのクラスタ間のネットワーク パスに次の2種類が存在します。
-
クラスタ間ピアリング ネットワーク
この種類のネットワークは、2つのクラスタ間の冗長IPネットワーク パスで構成されます。クラスタ ピアリング ネットワークは、Storage Virtual Machine(SVM)構成をミラーするために必要な接続を提供します。一方のクラスタのすべてのSVMの設定が、パートナー クラスタにミラーされます。
-
IPネットワーク(MetroCluster IP構成に存在)
この種類のネットワークは、2つの冗長IPスイッチ ネットワークで構成されます。各ネットワークには2つのIPスイッチがあり、各スイッチ ファブリックの1つのスイッチはクラスタと同じ場所に配置されます。各クラスタには、各スイッチ ファブリックから1つずつ、2つのIPスイッチがあります。すべてのノードは、同じ場所に配置されている各FCスイッチに接続されています。データは、クラスタからクラスタへ、ISL経由でレプリケートされます。
サイト間接続の監視
Tiebreakerソフトウェアは、サイト間接続のステータスをノードから定期的に取得します。NVインターコネクト接続が失われて、クラスタ間ピアリングがpingに応答しない場合、クラスタはサイトが分離されたとみなし、Tiebreakerソフトウェアが「AllLinksSevered」としてアラートをトリガーします。クラスタで「AllLinksSevered」ステータスが確認され、もう一方のクラスタにネットワーク経由で到達できない場合は、Tiebreakerソフトウェアが「disaster」としてアラートをトリガーします。
Tiebreakerソフトウェアでサイト障害を検出する方法
MetroCluster Tiebreakerソフトウェアは、MetroCluster構成のノードおよびクラスタに到達できるかをチェックして、サイト障害の有無を判断します。また、Tiebreakerソフトウェアは、特定の状況でアラートをトリガーします。
Tiebreakerソフトウェアで監視されるコンポーネント
Tiebreakerソフトウェアは、IPネットワークでホストされるノード管理LIFとクラスタ管理LIFへの複数のパスを介して冗長接続を確立することで、MetroCluster構成内の各コントローラーを監視します。
Tiebreakerソフトウェアは、MetroCluster構成の次のコンポーネントを監視します。
-
ローカル ノード インターフェイスを介したノード
-
クラスタ指定のインターフェイスを経由するクラスタ
-
サバイバー クラスタとディザスタ サイトとの接続の有無を評価(NVインターコネクト、ストレージ、クラスタ間ピアリング)
Tiebreakerソフトウェアとクラスタ内の全ノードおよびクラスタ自体との接続が失われると、Tiebreakerソフトウェアはそのクラスタを「到達不能
」と宣言します。接続障害を検出するには、約3~5秒かかります。Tiebreakerソフトウェアからクラスタに到達できない場合、障害が発生していないクラスタ(到達可能なクラスタ)は、Tiebreakerソフトウェアがアラートをトリガーする前に、パートナー クラスタへのすべてのリンクが切断されていることを示す必要があります。
サバイバー クラスタがFC(NVインターコネクトとストレージ)とクラスタ間ピアリングを介してディザスタ サイトのクラスタと通信できなくなると、すべてのリンクが切断されたとみなされます。 |
Tiebreakerソフトウェアがアラートをトリガーする障害シナリオ
Tiebreakerソフトウェアは、ディザスタ サイトのクラスタ(すべてのノード)が停止するか到達不能となり、サバイバー サイトのクラスタが「AllLinksSevered」ステータスになるとアラートをトリガーします。
次のシナリオでは、Tiebreakerソフトウェアはアラートをトリガーしません(またはアラートが拒否されます)。
-
8ノードMetroCluster構成で、ディザスタ サイトのHAペアの1つが停止している
-
ディザスタ サイトのすべてのノードを含むクラスタが停止し、サバイバー サイトのHAペアの1つが停止し、サバイバー サイトのクラスタが「AllLinksSevered」ステータスになっている
Tiebreakerソフトウェアはアラートをトリガーしますが、ONTAPはアラートを拒否します。この場合、手動のスイッチオーバーも拒否されます。
-
Tiebreakerソフトウェアがディザスタ サイトの1つ以上のノードまたはクラスタ インターフェイスに到達できる、またはサバイバー サイトがFC(NVインターコネクトとストレージ)またはクラスタ間ピアリングを介してディザスタ サイトのいずれかのノードに到達できる