Cisco Security Manager 4.4 ハイ アベイラビリティ インストレーション ガイド
ハイ アベイラビリティおよびディザスタ リカバリ証明テスト計画
ハイ アベイラビリティおよびディザスタ リカバリ証明テスト計画
発行日;2013/05/27 | 英語版ドキュメント(2013/05/06 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 2MB) | フィードバック

目次

ハイ アベイラビリティおよびディザスタ リカバリ証明テスト計画

手動切り替え

クラスタ内切り替え

クラスタ間切り替え

イーサネット/ネットワーク障害

ネットワーク通信障害

セカンダリ サーバ、シングル クラスタにおけるネットワーク イーサネット障害

プライマリ サーバ、シングル クラスタにおけるネットワーク イーサネット障害

セカンダリ サーバ、デュアル クラスタにおけるネットワーク イーサネット障害

プライマリ サーバ、デュアル クラスタにおけるネットワーク イーサネット障害

クラスタ通信障害

サーバの障害

スタンバイ サーバの障害、シングル クラスタ

プライマリ サーバの障害、シングル クラスタ

スタンバイ サーバの障害、デュアル クラスタ

プライマリ サーバの障害、デュアル クラスタ

アプリケーションの障害

アプリケーションの障害、シングル クラスタ

アプリケーションの障害、デュアル クラスタ

ハイ アベイラビリティおよびディザスタ リカバリ証明テスト計画

HA/DR 証明テスト計画では、Security Manager アプリケーションが高いアベイラビリティを備え、さまざまなハードウェア障害やソフトウェア障害に対応できることを検証します。テスト計画には、サーバ間でのアプリケーションの手動切り替えなど、メンテナンス作業も含まれます。


) Security Manager クライアント セッションでは、アクティブ ユーザがアプリケーションのフェールオーバー後に再度ログインする必要があります。この動作は、サーバで実行されている Security Manager サービスの停止および開始と同じです。


この付録には、次のテスト ケース カテゴリがあります。

「手動切り替え」

「イーサネット/ネットワーク障害」

「サーバの障害」

「アプリケーションの障害」

手動切り替え

ここでは、2 種類の手動切り替えについて説明します。2 台のサーバを持つシングル クラスタでは、クラスタ内で 2 台のサーバを切り替えることができます(クラスタ内切り替え)。各クラスタ内に 1 台のサーバが配置されたデュアル クラスタ構成では、クラスタを切り替えることができます(クラスタ間切り替え)。

ここでは、次の項目について説明します。

「クラスタ内切り替え」

「クラスタ間切り替え」

クラスタ内切り替え

テスト ケース タイトル:クラスタ内の手動アプリケーション切り替え。

説明:アプリケーションは、VCS を使用して、同じクラスタ内の別のサーバに手動で切り替えられます。

テスト セットアップ:シングル クラスタ構成内のデュアル ノード クラスタ( ローカル冗長性 HA の構成)。


ステップ 1 APP サービス グループがプライマリ サーバで実行されていることを確認します。VCS Cluster Explorer を使用して、[APP] サービス グループを選択します。ショートカット メニューから [Switch To] を選択し、セカンダリ サーバを選択します。または、次のコマンドを発行します。

C:\> hagrp -switch APP -to secondary_server_name
 

ステップ 2 APP サービス グループのリソース ビューで、サービス グループのリソースがプライマリ サーバでオフラインになり、その後セカンダリ サーバでオンラインになることを確認します。または、次のコマンドを発行して、APP サービス グループのステータスを確認します。

C:\> hagrp -state APP
 

ステップ 3 クライアント マシンから、ログイン ダイアログボックスで [Server Name] フィールドに仮想ホスト名または IP アドレスを使用して Security Manager クライアントを起動します。アプリケーションに正常にログインできることを確認します。


 

クラスタ間切り替え

テスト ケース タイトル:クラスタ間の手動アプリケーション切り替え。

説明:アプリケーションは、VCS を使用して、異なるクラスタ内のサーバに手動で切り替えられます。

テスト セットアップ:各クラスタ内に 1 台のサーバが配置された、 地理的冗長性(DR)の構成 に示すデュアル クラスタ構成。


ステップ 1 VCS Cluster Explorer を使用して、[APP] サービス グループを選択します。ショートカット メニューから、[Switch To]、[Remote Switch(...)] の順に選択して [Switch global] ダイアログボックスを開きます。ダイアログボックスで、リモート クラスタと、必要に応じてリモート クラスタ内の特定のサーバを指定します。または、次のコマンドを発行します。

C:\> hagrp -switch APP -any -clus secondary_cluster_name
 

ステップ 2 APP サービス グループのリソース ビューで、サービス グループのリソースがプライマリ クラスタでオフラインになることを確認します。ツリーでルート クラスタ ノードを選択し、[Remote Cluster Status] ビューを使用して、APP サービス グループがリモート クラスタでオンラインになることを確認します。または、次のコマンドを発行して、APP サービス グループのステータスを確認します。

C:\> hagrp -state APP
#Group Attribute System Value
APP State csm_primary:<Primary Server> |OFFLINE|
APP State localclus:<Secondary Server> |ONLINE|
 

ステップ 3 クライアント マシンから、ログイン ダイアログボックスで [Server Name] フィールドにセカンダリ クラスタで使用されている適切なホスト名またはアプリケーション IP アドレスを入力して Security Manager クライアントを起動します。アプリケーションに正常にログインできることを確認します。

ステップ 4 Security Manager クライアントからログアウトし、VCS Cluster Explorer または次のコマンドを使用して、APP サービス グループをプライマリ クラスタに切り替えます。

C:\> hagrp -switch APP -any -clus primary_cluster_name
 
 


 

イーサネット/ネットワーク障害

HA/DR 構成には、2 つのタイプのサーバ イーサネット接続があります。1 つ目はネットワーク通信に使用されるイーサネット接続です(パブリック インターフェイス)。2 つ目は、クラスタ内通信専用のイーサネット インターフェイスです(プライベート インターフェイス)。ここでは、イーサネット インターフェイスの各タイプの障害テスト ケースについて説明します。

「ネットワーク通信障害」

「クラスタ通信障害」

ネットワーク通信障害

ここでは、VCS がネットワーク通信に使用されているネットワーク イーサネット ポートの障害を検出できることを確認するために使用するテストを示します。ここでは、次の項目について説明します。

「セカンダリ サーバ、シングル クラスタにおけるネットワーク イーサネット障害」

「プライマリ サーバ、シングル クラスタにおけるネットワーク イーサネット障害」

「セカンダリ サーバ、デュアル クラスタにおけるネットワーク イーサネット障害」

「プライマリ サーバ、デュアル クラスタにおけるネットワーク イーサネット障害」

セカンダリ サーバ、シングル クラスタにおけるネットワーク イーサネット障害

テスト ケース タイトル:シングル クラスタ構成内のセカンダリ サーバのネットワーク イーサネット接続で障害が発生しました。

説明:このテスト ケースでは、VCS がセカンダリ サーバのネットワーク イーサネット ポートの障害を検出し、障害の修復後に回復できることを確認します。

テスト セットアップ:サーバごとに 1 本のネットワーク接続を備えたシングル クラスタ構成内のデュアル ノード クラスタ( ローカル冗長性 HA の構成)。


ステップ 1 アプリケーションがプライマリ サーバで実行されていることを確認します。

ステップ 2 クライアント マシンからアプリケーションにログインします。

ステップ 3 セカンダリ サーバのネットワーク ポートからイーサネット ケーブルを取り外して、スイッチ/ルータ ネットワークとの通信からサーバを分離します。VCS がネットワーク ポート障害を検出するまで少なくとも 60 秒間待機します。次のコマンドを実行して、VCS がセカンダリ サーバの NIC リソースの障害を検出することを確認します。

C:\> hastatus -sum
-- SYSTEM STATE
-- System State Frozen
A <PrimaryServer> RUNNING 0
A <SecondaryServer> RUNNING 0
 
-- GROUP STATE
-- Group System Probed AutoDisabled State
B APP <PrimaryServer> Y N ONLINE
B APP <SecondaryServer> Y N OFFLINE|FAULTED
 
-- RESOURCES FAILED
-- Group Type Resource System
C APP NIC NIC <SecondaryServer>
 

ステップ 4 セカンダリ サーバのネットワーク ポートにイーサネット ケーブルを戻します。次のコマンドを実行して、障害の解消を VCS が検出することを確認します。

C:\> hastatus -sum
-- SYSTEM STATE
-- System State Frozen
A <PrimaryServer> RUNNING 0
A <SecondaryServer> RUNNING 0
 
-- GROUP STATE
-- Group System Probed AutoDisabled State
B APP <PrimaryServer> Y N ONLINE
B APP <SecondaryServer> Y N OFFLINE
 


 

プライマリ サーバ、シングル クラスタにおけるネットワーク イーサネット障害

テスト ケース タイトル:シングル クラスタ構成内のプライマリ サーバのネットワーク イーサネット接続で障害が発生しました。

説明:このテスト ケースでは、VCS がプライマリ サーバのネットワーク イーサネット ポートの障害を検出し、アプリケーションを自動的にセカンダリ サーバに切り替えることができることを確認します。問題が修正された後、アプリケーションを再びプライマリ サーバに手動で切り替えるできます。

テスト セットアップ:サーバごとに 1 本のネットワーク接続を備えたデュアル ノード クラスタ( デュアル ノード サイトのイーサネット接続とストレージ接続)。


ステップ 1 アプリケーションがプライマリ サーバで実行されていることを確認します。

ステップ 2 プライマリ サーバのネットワーク ポートからイーサネット ケーブルを取り外して、スイッチ/ルータ ネットワークとの通信からサーバを分離します。VCS が NIC リソースの障害を検出し、自動的にセカンダリ サーバに APP サービス グループを切り替えることを確認します。

C:\> hastatus -sum
-- SYSTEM STATE
-- System State Frozen
A <PrimaryServer> RUNNING 0
A <SecondaryServer> RUNNING 0
 
-- GROUP STATE
-- Group System Probed AutoDisabled State
B APP <PrimaryServer> Y N OFFLINE|FAULTED
B APP <SecondaryServer> Y N ONLINE
 
-- RESOURCES FAILED
-- Group Type Resource System
C APP NIC NIC <PrimaryServer>
C APP IP APP_IP <PrimaryServer>
 

ステップ 3 セカンダリ サーバで実行中のアプリケーションにログインできることを確認します。

ステップ 4 プライマリ サーバのネットワーク ポートのイーサネット ケーブルを交換し、プライマリ サーバの障害が発生している IP リソースを手動でクリアします。

C:\> hares -clear APP_IP -sys primary_server_name
 

ステップ 5 APP サービス グループを再びプライマリ サーバに手動で切り替えます。

C:\> hagrp -switch APP -to primary_server_name
 


 

セカンダリ サーバ、デュアル クラスタにおけるネットワーク イーサネット障害

テスト ケース タイトル:デュアル クラスタ構成内のセカンダリ サーバのネットワーク イーサネット接続で障害が発生しました。

説明:このテスト ケースでは、VCS がネットワーク イーサネット ポートの障害を検出し、障害の修復後に回復できることを確認します。

テスト セットアップ:クラスタごとにシングル ノード、およびサーバごとに 1 本のイーサネット ネットワーク接続を備えたデュアル クラスタ構成( 地理的冗長性(DR)の構成)。


ステップ 1 APP サービス グループがプライマリ クラスタ/サーバで実行されていることを確認します。

ステップ 2 クライアント マシンから Security Manager にログインします。

ステップ 3 セカンダリ クラスタ内のサーバのネットワーク ポートからイーサネット ケーブルを取り外します。これにより、スイッチ/ルータ ネットワークとの通信からサーバが分離され、複製が中断されます。プライマリ サーバで、次のコマンドを実行して、複製が中断(切断)されたことを確認します。

C:\> vxprint -Pl
Diskgroup = datadg
 
Rlink : rlk_172_6037
info : timeout=500 packet_size=1400
latency_high_mark=10000 latency_low_mark=9950
bandwidth_limit=none
state : state=ACTIVE
synchronous=off latencyprot=off srlprot=off
assoc : rvg=CSM_RVG
remote_host=172.25.84.34
remote_dg=datadg
remote_rlink=rlk_172_32481
local_host=172.25.84.33
protocol : UDP/IP
flags : write attached consistent disconnected
 

ステップ 4 プライマリ サーバから次のコマンドを実行して、セカンダリ クラスタとの通信が失われたことを確認します。

 
C:\> hastatus -sum
-- SYSTEM STATE
-- System State Frozen
A <PrimaryServer> RUNNING 0
 
-- GROUP STATE
-- Group System Probed AutoDisabled State
B APP <PrimaryServer> Y N ONLINE
B APPrep <PrimaryServer> Y N ONLINE
B ClusterService <PrimaryServer> Y N ONLINE
 
-- WAN HEARTBEAT STATE
-- Heartbeat To State
L Icmp csm_secondary ALIVE
 
-- REMOTE CLUSTER STATE
-- Cluster State
M csm_secondary LOST_CONN
 
-- REMOTE SYSTEM STATE
-- cluster:system State Frozen
N csm_secondary:<SecondaryServer> RUNNING 0
 
-- REMOTE GROUP STATE
-- Group cluster:system Probed AutoDisabled State
O APP csm_secondary:<SecondaryServer> Y N OFFLINE
 

ステップ 5 ネットワーク イーサネット ケーブルをセカンダリ サーバに再接続し、複製が再開されたことを確認します。

C:\> vxprint -Pl
 
Diskgroup = datadg
 
Rlink : rlk_172_6037
info : timeout=29 packet_size=1400
latency_high_mark=10000 latency_low_mark=9950
bandwidth_limit=none
state : state=ACTIVE
synchronous=off latencyprot=off srlprot=off
assoc : rvg=CSM_RVG
remote_host=172.25.84.34
remote_dg=datadg
remote_rlink=rlk_172_32481
local_host=172.25.84.33
protocol : UDP/IP
flags : write attached consistent connected
 

ステップ 6 セカンダリ クラスタへの通信が復元されたことを確認します。

 
C:\> hastatus -sum
-- SYSTEM STATE
-- System State Frozen
A <PrimaryServer> RUNNING 0
-- GROUP STATE
-- Group System Probed AutoDisabled State
B APP <PrimaryServer> Y N ONLINE
B APPrep <PrimaryServer> Y N ONLINE
B ClusterService <PrimaryServer> Y N ONLINE
 
-- WAN HEARTBEAT STATE
-- Heartbeat To State
L Icmp csm_secondary ALIVE
 
-- REMOTE CLUSTER STATE
-- Cluster State
M csm_secondary RUNNING
 
-- REMOTE SYSTEM STATE
-- cluster:system State Frozen
N csm_secondary:<SecondaryServer> RUNNING 0
 
-- REMOTE GROUP STATE
-- Group cluster:system Probed AutoDisabled State
O APP csm_secondary:<SecondaryServer> Y N OFFLINE
 
 

ステップ 7 複製が回復しない場合は、次のように障害が発生した IP リソースを手動でクリアし、次にセカンダリで APPrep サービス グループを開始する必要があります。

C:\> hares -clear APP_IP
C:\> hagrp -online APPrep -sys secondary_server_name
 
 


 

プライマリ サーバ、デュアル クラスタにおけるネットワーク イーサネット障害

テスト ケース タイトル:プライマリ サーバのネットワーク イーサネット接続で障害が発生しました。

説明:このテスト ケースでは、VCS がプライマリ サーバのネットワーク イーサネット ポートの障害を検出し、セカンダリ サーバでアプリケーションを起動して回復できることを確認します。イーサネット接続の復元後、元のプライマリ サーバに手動でフェールオーバーし、セカンダリでの実行中に行われたデータ変更を保持します。

テスト セットアップ:各クラスタ内に 1 台のノードが配置されたデュアル クラスタ構成( 地理的冗長性(DR)の構成)。


ステップ 1 APP サービス グループがプライマリ クラスタで実行されていることを確認します。

ステップ 2 プライマリ クラスタ内のサーバのポートからイーサネット ケーブルを取り外して、スイッチ/ルータ ネットワークとの通信からサーバを分離します。VCS は、IP および NIC リソースの障害としてこれを検出する必要があります。VCS が障害を検出し、APP サービス グループを停止したことを確認します。

C:\> hastatus -sum
-- SYSTEM STATE
-- System State Frozen
A <PrimaryServer> RUNNING 0
 
-- GROUP STATE
-- Group System Probed AutoDisabled State
B APP <PrimaryServer> Y N OFFLINE
B APPrep <PrimaryServer> Y N OFFLINE|FAULTED
B ClusterService <PrimaryServer> Y N ONLINE
 
-- RESOURCES FAILED
-- Group Type Resource System
C APPrep IP APP_IP <PrimaryServer>
C APPrep NIC NIC <PrimaryServer>
 
-- WAN HEARTBEAT STATE
-- Heartbeat To State
L Icmp csm_secondary DOWN
 
-- REMOTE CLUSTER STATE
-- Cluster State
M csm_secondary FAULTED
 
-- REMOTE SYSTEM STATE
-- cluster:system State Frozen
N csm_secondary:<SecondaryServer> FAULTED 0
 
-- REMOTE GROUP STATE
-- Group cluster:system Probed AutoDisabled State
O APP csm_secondary:<SecondaryServer> Y N OFFLINE
 
 

ステップ 3 セカンダリ サーバで次のコマンドを使用して、セカンダリ クラスタの APP サービス グループを開始します。

C:\> hagrp -online -force APP -sys secondary_server_name
 

ステップ 4 クライアント マシンから、Security Manager にログインして Security Manager が動作していることを確認します。プライマリ サーバに切り替えたときに変更が維持されることを確認できるように、データを変更します。

ステップ 5 プライマリ クラスタ サーバにネットワーク イーサネット ケーブルを再接続します。

ステップ 6 IP リソースの障害を取り除き、プライマリ サーバから APPrep サービスをオンにします。

C:\> hares -clear APP_IP
C:\> hagrp -online APPrep -sys primary_server_name
 

ステップ 7 元のプライマリ RVG をセカンダリに変換し、高速フェールバック機能を使用して、元のプライマリ RVG のデータ ボリュームを新しいプライマリ RVG のデータ ボリュームと同期します。セカンダリ クラスタの Cluster Explorer を使用して、RVGPrimary リソース(APP_RVGPrimary)を右クリックし、[actions] を選択して [Actions] ダイアログボックスから [fbsync] を選択し、[OK] をクリックします。または、次のコマンドを発行できます。

C:\> hares -action APP_RVGPrimary fbsync 0 -sys secondary_server_name

ステップ 8 セカンダリ クラスタで VCS Cluster Explorer を使用して、[APP] サービス グループを選択します。ショートカット メニューから、[Switch To]、[Remote Switch(...)] の順に選択して [Switch global] ダイアログボックスを開きます。ダイアログボックスで、プライマリ クラスタとプライマリ サーバを指定します。または、次のコマンドを発行します。

C:\> hagrp -switch APP -any -clus primarycluster
 

ステップ 9 アプリケーションにログインして、セカンダリ サーバに加えた変更が保持されていることを確認します。


 

クラスタ通信障害

テスト ケース タイトル:クラスタ通信に使用されるイーサネットで障害が発生しました。

説明:クラスタ内通信のためにクラスタ内のサーバ間で使用されている専用のイーサネット接続で障害が発生しました。テストでは、3 本のうち最大 2 本の冗長通信パスが失われた場合でも、クラスタ通信が継続されることを確認します。

テスト セットアップ:2 本の専用クラスタ通信イーサネット接続、およびネットワーク イーサネット接続に設定されたプライオリティの低いクラスタ通信接続を備えた、シングル クラスタ構成のデュアル ノード クラスタ( ローカル冗長性 HA の構成)。


) このテスト ケースで指定されたコマンドに加えて、Cluster Explorer からツリーでルート ノードを選択し、[System Connectivity] タブを選択することによってクラスタ通信のステータスをモニタできます。



ステップ 1 次のコマンドを発行して、すべてのシステムが GAB を介して通信していることを確認します。


) Group Membership Services/Atomic Broadcast(GAB)は、クラスタ メンバーシップやクラスタ通信を担当する VCS プロトコルです。


# gabconfig -a
GAB Port Memberships
===============================================================
Port a gen e8cc02 membership 01
Port h gen e8cc01 membership 01
 
 

ステップ 2 プライマリ サーバでクラスタ通信に使用される最初の専用イーサネット ポートからイーサネット ケーブルを取り外します。

ステップ 3 次のコマンドを発行して、クラスタ通信に使用されるリンクの詳細なステータスを表示し、最初の専用クラスタ通信ポートがダウンしていることを確認します。


) 出力のアスタリスク(*)は、コマンドが実行されるサーバを示します。コマンドが実行されるサーバは、これらのポートの 1 つ以上が物理的に切断されている場合でも、常にリンクがアップしていることを示します。


# lltstat -nvv
LLT node information:
Node State Link Status Address
* 0 <PrimaryServer> OPEN
Adapter0 UP 00:14:5E:28:52:9C
Adapter1 UP 00:14:5E:28:52:9D
Adapter2 UP 00:0E:0C:9C:20:FE
1 <SecondaryServer> OPEN
Adapter0 DOWN
Adapter1 UP 00:14:5E:28:27:17
Adapter2 UP 00:0E:0C:9C:21:C2
...
 

ステップ 4 ネットワーク インターフェイスにプライオリティの低いハートビート リンクを設定した場合は、プライマリ サーバのクラスタ通信に使用される 2 本目の専用イーサネット ポートからイーサネット ケーブルを取り外します。

ステップ 5 次のコマンドを発行して、すべてのシステムが GAB を介して通信していることを確認します。各サーバではハートビートが 1 つだけ動作しているため、クラスタ内の両方のサーバが Jeopardy 状態になったことも確認します。

# gabconfig -a
GAB Port Memberships
===============================================================
Port a gen e8cc02 membership 01
Port a gen e8cc02 jeopardy ;1
Port h gen e8cc01 membership 01
Port h gen e8cc01 jeopardy ;1
 
 

ステップ 6 次のコマンドを発行して、クラスタ通信に使用されるリンクの詳細なステータスを表示し、プライマリ サーバ上のクラスタ通信に使用される 2 つ目の専用イーサネット ポートがダウンしていることを確認します。

# lltstat -nvv
LLT node information:
Node State Link Status Address
* 0 <PrimaryServer> OPEN
Adapter0 UP 00:14:5E:28:52:9C
Adapter1 UP 00:14:5E:28:52:9D
Adapter2 UP 00:0E:0C:9C:20:FE
1 <SecondaryServer> OPEN
Adapter0 DOWN
Adapter1 UP 00:14:5E:28:27:17
Adapter2 DOWN
 
 

ステップ 7 プライマリ サーバでクラスタ通信に使用される 2 つ目の専用イーサネット ポートのイーサネット ケーブルを交換します。

ステップ 8 次のコマンドを発行して、Jeopardy 状態が解消されたことを確認します。

# gabconfig -a
GAB Port Memberships
===============================================================
Port a gen e8cc02 membership 01
Port h gen e8cc01 membership 01
 
 

ステップ 9 プライマリ サーバでクラスタ通信に使用される最初の専用イーサネット ポートのイーサネット ケーブルを交換します。


 

サーバの障害

ここでは、サーバから電源を取り外してサーバ障害を引き起こします。4 つのケースについて説明します。

「スタンバイ サーバの障害、シングル クラスタ」

「プライマリ サーバの障害、シングル クラスタ」

「スタンバイ サーバの障害、デュアル クラスタ」

「プライマリ サーバの障害、デュアル クラスタ」

スタンバイ サーバの障害、シングル クラスタ

テスト ケース タイトル:シングル クラスタ構成のスタンバイ サーバで障害が発生しました。

説明:このテスト ケースでは、プライマリ サーバで稼働しているアプリケーションが影響を受けないことと、スタンバイ サーバが修復された後、アプリケーションが正常にクラスタ構成に再度参加できることを確認します。

テスト セットアップ:2 本の専用クラスタ通信イーサネット接続、およびネットワーク イーサネット接続のプライオリティの低いクラスタ通信接続を備えた、デュアル ノード クラスタ( デュアル ノード サイトのイーサネット接続とストレージ接続)。


ステップ 1 アプリケーションがクラスタ内のプライマリ サーバで実行されていることを確認します。

C:\> hastatus -sum
-- SYSTEM STATE
-- System State Frozen
A <PrimaryServer> RUNNING 0
A <SecondaryServer> RUNNING 0
 
-- GROUP STATE
-- Group System Probed AutoDisabled State
B APP <PrimaryServer> Y N ONLINE
B APP <SecondaryServer> Y N OFFLINE
 

ステップ 2 セカンダリ サーバの電源を取り外し、VCS が障害を検出し、アプリケーションがプライマリ サーバで実行し続けることを確認します。

C:\> hastatus -sum
-- SYSTEM STATE
-- System State Frozen
A <PrimaryServer> RUNNING 0
A <SecondaryServer> FAULTED 0
 
-- GROUP STATE
-- Group System Probed AutoDisabled State
B APP <PrimaryServer> Y N ONLINE
 

ステップ 3 電源を再度適用し、セカンダリ サーバをブートします。サーバが回復したら、次のコマンドを実行して、正常な状態でクラスタに再接続されていることを確認します。出力はステップ 1 の出力と同一である必要があります。

C:\> hastatus -sum
 
 


 

プライマリ サーバの障害、シングル クラスタ

テスト ケース タイトル:シングル クラスタ内のプライマリ サーバで障害が発生しました。

説明:このテスト ケースでは、プライマリ サーバで障害が発生するとセカンダリ サーバでアプリケーションが実行を開始することと、プライマリ サーバが修復された後、アプリケーションをプライマリ サーバで再設定できることを確認します。

テスト セットアップ:デュアル ノード クラスタ( ローカル冗長性 HA の構成)。


ステップ 1 次のコマンドの出力を調べて、APP サービス グループがクラスタ内のプライマリ サーバで実行されていることを確認します。

C:\> hastatus -sum
-- SYSTEM STATE
-- System State Frozen
A <PrimaryServer> RUNNING 0
A <SecondaryServer> RUNNING 0
 
-- GROUP STATE
-- Group System Probed AutoDisabled State
B APP <PrimaryServer> Y N ONLINE
B APP <SecondaryServer> Y N OFFLINE
 

ステップ 2 プライマリ サーバの電源を取り外し、VCS が障害を検出し、APP サービス グループがセカンダリ サーバに正常に移行されることを確認します。

C:\> hastatus -sum
-- SYSTEM STATE
-- System State Frozen
A <PrimaryServer> FAULTED 0
A <SecondaryServer> RUNNING 0
 
-- GROUP STATE
-- Group System Probed AutoDisabled State
B APP <SecondaryServer> Y N ONLINE
 
 

ステップ 3 クライアント マシンから Security Manager に正常にログインできることを確認します。

ステップ 4 電源をプライマリ サーバに復元し、サーバが正常な状態でクラスタに再参加できることを確認します。次のコマンドを実行します。出力はステップ 1 の出力と同一である必要があります。

C:\> hastatus -sum
 

ステップ 5 APP サービス グループを再びプライマリ サーバに手動で切り替えます。

C:\> hagrp -switch APP -to primary_server_name
 
 


 

スタンバイ サーバの障害、デュアル クラスタ

テスト ケース タイトル:デュアル クラスタ構成のスタンバイ サーバで障害が発生しました。

説明:このテスト ケースでは、プライマリ クラスタで稼働しているアプリケーションがスタンバイ サーバの障害の影響を受けないことと、スタンバイ サーバが修復された後、アプリケーションが正常にデュアル クラスタ構成に再度参加できることを確認します。

テスト セットアップ:各クラスタ内に複製が行われる 1 台のノードが配置されたデュアル クラスタ構成( 地理的冗長性(DR)の構成)。


ステップ 1 プライマリ サーバで次のコマンドを実行して、APP および ClusterService サービス グループがプライマリ クラスタで動作していることを確認します。

C:\> hastatus -sum
-- SYSTEM STATE
-- System State Frozen
A <PrimaryServer> RUNNING 0
 
-- GROUP STATE
-- Group System Probed AutoDisabled State
B APP <PrimaryServer> Y N ONLINE
B APPrep <PrimaryServer> Y N ONLINE
B ClusterService <PrimaryServer> Y N ONLINE
 
-- WAN HEARTBEAT STATE
-- Heartbeat To State
L Icmp csm_secondary ALIVE
 
-- REMOTE CLUSTER STATE
-- Cluster State
M csm_secondary RUNNING
 
-- REMOTE SYSTEM STATE
-- cluster:system State Frozen
N csm_secondary:<SecondaryServer> RUNNING 0
 
-- REMOTE GROUP STATE
-- Group cluster:system Probed AutoDisabled State
O APP csm_secondary:<SecondaryServer> Y N OFFLINE
 
 

ステップ 2 電源をセカンダリ サーバから取り外し、プライマリ クラスタがセカンダリ クラスタとの通信の喪失を検出することを確認します。

C:\> hastatus -sum
-- SYSTEM STATE
-- System State Frozen
A <PrimaryServer> RUNNING 0
 
-- GROUP STATE
-- Group System Probed AutoDisabled State
B APP <PrimaryServer> Y N ONLINE
B APPrep <PrimaryServer> Y N ONLINE
B ClusterService <PrimaryServer> Y N ONLINE
 
-- WAN HEARTBEAT STATE
-- Heartbeat To State
L Icmp csm_secondary ALIVE
 
-- REMOTE CLUSTER STATE
-- Cluster State
M csm_secondary LOST_CONN
 
-- REMOTE SYSTEM STATE
-- cluster:system State Frozen
N csm_secondary:<SecondaryServer> RUNNING 0
 
-- REMOTE GROUP STATE
-- Group cluster:system Probed AutoDisabled State
O APP csm_secondary:<SecondaryServer> Y N OFFLINE
 

ステップ 3 セカンダリ サーバに電源を戻します。サーバの再起動後、プライマリ クラスタで次のコマンドを実行して、セカンダリ クラスタとの通信を再確立したことを確認します。出力はステップ 1 の出力と同一である必要があります。

C:\> hastatus -sum
 

ステップ 4 次のコマンドを実行して、複製が機能し、矛盾していないことを確認します。

C:\> vxprint -Pl
Diskgroup = BasicGroup
 
Diskgroup = datadg
 
Rlink : rlk_172_6037
info : timeout=16 packet_size=1400
latency_high_mark=10000 latency_low_mark=9950
bandwidth_limit=none
state : state=ACTIVE
synchronous=off latencyprot=off srlprot=off
assoc : rvg=CSM_RVG
remote_host=172.25.84.34
remote_dg=datadg
remote_rlink=rlk_172_32481
local_host=172.25.84.33
protocol : UDP/IP
flags : write attached consistent connected
 
 


 

プライマリ サーバの障害、デュアル クラスタ

テスト ケース タイトル:デュアル クラスタ構成のプライマリ サーバで障害が発生しました。

説明:このテスト ケースでは、プライマリ サーバで障害が発生するとセカンダリ サーバでアプリケーションが実行を開始することと、プライマリ サーバが修復された後、アプリケーションをプライマリ サーバで再設定できることを確認します。

テスト セットアップ:各クラスタ内に複製が行われる 1 台のノードが配置されたデュアル クラスタ構成( 地理的冗長性(DR)の構成)。


ステップ 1 セカンダリ サーバから次のコマンドを実行して、APP および ClusterService サービス グループがプライマリ クラスタで動作していることを確認します。

C:\> hastatus -sum
-- SYSTEM STATE
-- System State Frozen
A <SecondaryServer> RUNNING 0
 
-- GROUP STATE
-- Group System Probed AutoDisabled State
B APP <SecondaryServer> Y N OFFLINE
B APPrep <SecondaryServer> Y N ONLINE
B ClusterService <SecondaryServer> Y N ONLINE
 
-- WAN HEARTBEAT STATE
-- Heartbeat To State
L Icmp csm_primary ALIVE
 
-- REMOTE CLUSTER STATE
-- Cluster State
M csm_primary RUNNING
 
-- REMOTE SYSTEM STATE
-- cluster:system State Frozen
N csm_primary:<PrimaryServer> RUNNING 0
 
-- REMOTE GROUP STATE
-- Group cluster:system Probed AutoDisabled State
O APP csm_primary:<PrimaryServer> Y N ONLINE
 

ステップ 2 プライマリ サーバから電源を取り外してサーバ障害を引き起こします。セカンダリ クラスタがプライマリ クラスタへの接続の喪失を報告したことを確認します。

C:\> hastatus -sum
-- SYSTEM STATE
-- System State Frozen
A <SecondaryServer> RUNNING 0
 
-- GROUP STATE
-- Group System Probed AutoDisabled State
B APP <SecondaryServer> Y N OFFLINE
B APPrep <SecondaryServer> Y N ONLINE
B ClusterService <SecondaryServer> Y N ONLINE
 
-- WAN HEARTBEAT STATE
-- Heartbeat To State
L Icmp csm_primary ALIVE
 
-- REMOTE CLUSTER STATE
-- Cluster State
M csm_primary LOST_CONN
 
-- REMOTE SYSTEM STATE
-- cluster:system State Frozen
N csm_primary:<PrimaryServer> RUNNING 0
 
-- REMOTE GROUP STATE
-- Group cluster:system Probed AutoDisabled State
O APP csm_primary:<PrimaryServer> Y N ONLINE
 

ステップ 3 複製の状態が disconnected であることを確認します。次のコマンド出力の flags パラメータからこの状態を確認できます。

C:\> vxprint -Pl
Diskgroup = BasicGroup
 
Diskgroup = datadg
 
Rlink : rlk_172_32481
info : timeout=500 packet_size=1400
latency_high_mark=10000 latency_low_mark=9950
bandwidth_limit=none
state : state=ACTIVE
synchronous=off latencyprot=off srlprot=off
assoc : rvg=CSM_RVG
remote_host=172.25.84.33
remote_dg=datadg
remote_rlink=rlk_172_6037
local_host=172.25.84.34
protocol : UDP/IP
flags : write attached consistent disconnected
 

ステップ 4 次のコマンドを使用してセカンダリ サーバでアプリケーションを起動します。

C:\> hagrp -online -force APP -sys secondary_server_name
 

ステップ 5 アプリケーションにログインし、プライマリ サーバに戻っても、アプリケーションがセカンダリ サーバ上で稼働している間に行われた変更を保持できることを後で確認できるように、データを変更します。

ステップ 6 電源をプライマリ サーバに戻し、サーバが完全に起動できるようにします。

ステップ 7 複製が connected であることを示す複製のステータスを確認します。ただし、両側が同期していません。

C:\> vxprint -Pl
Diskgroup = BasicGroup
 
Diskgroup = datadg
 
Rlink : rlk_172_32481
info : timeout=500 packet_size=1400
latency_high_mark=10000 latency_low_mark=9950
bandwidth_limit=none
state : state=ACTIVE
synchronous=off latencyprot=off srlprot=off
assoc : rvg=CSM_RVG
remote_host=172.25.84.33
remote_dg=datadg
remote_rlink=rlk_172_6037
local_host=172.25.84.34
protocol : UDP/IP
flags : write attached consistent connected dcm_logging failback_logging
 

ステップ 8 元のプライマリ RVG をセカンダリに変換し、高速フェールバック機能を使用して、元のプライマリ RVG のデータ ボリュームを新しいプライマリ RVG のデータ ボリュームと同期します。セカンダリ クラスタの Cluster Explorer を使用して、RVGPrimary リソース(APP_RVGPrimary)を右クリックし、[actions] を選択して [Actions] ダイアログボックスから [fbsync] を選択し、[OK] をクリックします。または、次のコマンドを発行できます。

C:\> hares -action APP_RVGPrimary fbsync 0 -sys secondary_server_name
 

ステップ 9 次のコマンド出力の flags パラメータの consistent キーワードを調べて、現在のセカンダリ(以前のプライマリ)が現在のプライマリ(以前のセカンダリ)と同期していることを確認します。

C:\> vxprint -Pl
Diskgroup = BasicGroup
 
Diskgroup = datadg
 
Rlink : rlk_172_32481
info : timeout=29 packet_size=1400
latency_high_mark=10000 latency_low_mark=9950
bandwidth_limit=none
state : state=ACTIVE
synchronous=off latencyprot=off srlprot=off
assoc : rvg=CSM_RVG
remote_host=172.25.84.33
remote_dg=datadg
remote_rlink=rlk_172_6037
local_host=172.25.84.34
protocol : UDP/IP
flags : write attached consistent connected
 

ステップ 10 セカンダリ クラスタで VCS Cluster Explorer を使用して、[APP] サービス グループを選択します。ショートカット メニューから、[Switch To]、[Remote Switch(...)] の順に選択して [Switch global] ダイアログボックスを開きます。ダイアログボックスで、プライマリ クラスタとプライマリ サーバを指定します。または、次のコマンドを発行します。primarycluster はプライマリ クラスタの名前です。

C:\> hagrp -switch APP -any -clus primarycluster
 

ステップ 11 アプリケーションにログインして、セカンダリ サーバに加えた変更が保持されていることを確認します。


 

アプリケーションの障害

ここでは、Security Manager アプリケーションで障害が発生した場合のテスト ケースについて説明します。シングル クラスタ構成とデュアル クラスタ構成の 2 つのケースについて説明します。ここでは、次の項目について説明します。

「アプリケーションの障害、シングル クラスタ」

「アプリケーションの障害、デュアル クラスタ」

アプリケーションの障害、シングル クラスタ

テスト ケース タイトル:シングル クラスタ構成内のプライマリ サーバでアプリケーションの障害が発生しました。

説明:このテスト ケースでは、VCS がアプリケーションの障害を検出し、アプリケーションを自動的にセカンダリ サーバに移行することを確認します。

テスト セットアップ:デフォルトのアプリケーション フェールオーバー動作を使用するデュアル ノード クラスタ( ローカル冗長性 HA の構成)。


ステップ 1 次のコマンドを実行して、APP サービス グループがクラスタ内のプライマリ サーバで実行されていることを確認します。

C:\> hastatus -sum
-- SYSTEM STATE
-- System State Frozen
A <PrimaryServer> RUNNING 0
A <SecondaryServer> RUNNING 0
 
-- GROUP STATE
-- Group System Probed AutoDisabled State
B APP <PrimaryServer> Y N ONLINE
B APP <SecondaryServer> Y N OFFLINE

 

ステップ 2 Security Manager が実行されているサーバで、次のコマンドを発行してアプリケーションを停止します。

C:\> net stop crmdmgtd
 

ステップ 3 VCS がプライマリ サーバで Security Manager が失敗したことを検出し、アプリケーションをセカンダリ サーバで開始することを確認します。

# hastatus -sum
-- SYSTEM STATE
-- System State Frozen
A <PrimaryServer> RUNNING 0
A <SecondaryServer> RUNNING 0
 
-- GROUP STATE
-- Group System Probed AutoDisabled State
B APP <PrimaryServer> Y N OFFLINE|FAULTED
B APP <SecondaryServer> Y N ONLINE
 
-- RESOURCES FAILED
-- Group Type Resource System
C APP CSManager APP_CSManager <PrimaryServer>
 

ステップ 4 APP サービス グループの障害を手動で解決します。

C:\> hagrp -clear APP -sys primary_server_name
 

ステップ 5 APP サービス グループを再びプライマリ サーバに手動で切り替えます。

C:\> hagrp -switch APP -to primary_server_name
 
 


 

アプリケーションの障害、デュアル クラスタ

テスト ケース タイトル:デュアル クラスタ構成内のプライマリ サーバでアプリケーションの障害が発生しました。

説明:このテスト ケースでは、VCS がアプリケーションの障害を検出することを確認します。

テスト セットアップ:各クラスタ内に複製が行われる 1 台のノードが配置されたデュアル クラスタ構成( 地理的冗長性(DR)の構成)。同様に、デフォルトのアプリケーション フェールオーバー動作が変更されていない(つまり、クラスタ間のフェールオーバーに手動による介入が必要である)ことを前提とします。


ステップ 1 プライマリ サーバで次のコマンドを実行して、APP および ClusterService サービス グループがプライマリ クラスタで動作していることを確認します。

C:\> hastatus -sum
-- SYSTEM STATE
-- System State Frozen
A <SecondaryServer> RUNNING 0
 
-- GROUP STATE
-- Group System Probed AutoDisabled State
B APP <SecondaryServer> Y N OFFLINE
B APPrep <SecondaryServer> Y N ONLINE
B ClusterService <SecondaryServer> Y N ONLINE
 
-- WAN HEARTBEAT STATE
-- Heartbeat To State
L Icmp csm_primary ALIVE
 
-- REMOTE CLUSTER STATE
-- Cluster State
M csm_primary RUNNING
 
-- REMOTE SYSTEM STATE
-- cluster:system State Frozen
N csm_primary:<PrimaryServer> RUNNING 0
 
-- REMOTE GROUP STATE
-- Group cluster:system Probed AutoDisabled State
O APP csm_primary:<PrimaryServer> Y N ONLINE

 

ステップ 2 Security Manager が実行されているサーバで、次のコマンドを発行してアプリケーションを停止します。

C:\> net stop crmdmgtd
 

ステップ 3 VCS がアプリケーションの障害を検出し、APP サービス グループを停止したことを確認します。次のコマンドを発行し、出力を確認します。

# hastatus -sum
-- SYSTEM STATE
-- System State Frozen
A <PrimaryServer> RUNNING 0
 
-- GROUP STATE
-- Group System Probed AutoDisabled State
B APP <PrimaryServer> Y N OFFLINE|FAULTED
B APPrep <PrimaryServer> Y N ONLINE
B ClusterService <PrimaryServer> Y N ONLINE
 
-- RESOURCES FAILED
-- Group Type Resource System
C APP CSManager APP_CSManager <PrimaryServer>
 
-- WAN HEARTBEAT STATE
-- Heartbeat To State
L Icmp csm_secondary ALIVE
 
-- REMOTE CLUSTER STATE
-- Cluster State
M csm_secondary RUNNING
 
-- REMOTE SYSTEM STATE
-- cluster:system State Frozen
N csm_secondary:<SecondaryServer> RUNNING 0
 
-- REMOTE GROUP STATE
-- Group cluster:system Probed AutoDisabled State
O APP csm_secondary:<SecondaryServer> Y N OFFLINE
 
 

ステップ 4 APP サービス グループの障害を手動で解決します。

C:\> hagrp -clear APP
 

ステップ 5 APP サービス グループをプライマリ サーバでオンラインにしてアプリケーションを再起動します。

C:\> hagrp -online APP -sys primary_server_name