この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
HA/DR 証明テスト計画では、Security Manager アプリケーションが高いアベイラビリティを備え、さまざまなハードウェア障害やソフトウェア障害に対応できることを検証します。テスト計画には、サーバ間でのアプリケーションの手動切り替えなど、メンテナンス作業も含まれます。
(注) Security Manager クライアント セッションでは、アクティブ ユーザがアプリケーションのフェールオーバー後に再度ログインする必要があります。この動作は、サーバで実行されている Security Manager サービスの停止および開始と同じです。
• 「手動切り替え」
• 「サーバの障害」
ここでは、2 種類の手動切り替えについて説明します。2 台のサーバを持つシングル クラスタでは、クラスタ内で 2 台のサーバを切り替えることができます(クラスタ内切り替え)。各クラスタ内に 1 台のサーバが配置されたデュアル クラスタ構成では、クラスタを切り替えることができます(クラスタ間切り替え)。
テスト ケース タイトル:クラスタ内の手動アプリケーション切り替え。
説明:アプリケーションは、VCS を使用して、同じクラスタ内の別のサーバに手動で切り替えられます。
テスト セットアップ:シングル クラスタ構成内のデュアル ノード クラスタ( ローカル冗長性 HA の構成)。
ステップ 1 APP サービス グループがプライマリ サーバで実行されていることを確認します。VCS Cluster Explorer を使用して、[APP] サービス グループを選択します。ショートカット メニューから [Switch To] を選択し、セカンダリ サーバを選択します。または、次のコマンドを発行します。
ステップ 2 APP サービス グループのリソース ビューで、サービス グループのリソースがプライマリ サーバでオフラインになり、その後セカンダリ サーバでオンラインになることを確認します。または、次のコマンドを発行して、APP サービス グループのステータスを確認します。
ステップ 3 クライアント マシンから、ログイン ダイアログボックスで [Server Name] フィールドに仮想ホスト名または IP アドレスを使用して Security Manager クライアントを起動します。アプリケーションに正常にログインできることを確認します。
テスト ケース タイトル:クラスタ間の手動アプリケーション切り替え。
説明:アプリケーションは、VCS を使用して、異なるクラスタ内のサーバに手動で切り替えられます。
テスト セットアップ:各クラスタ内に 1 台のサーバが配置された、 地理的冗長性(DR)の構成 に示すデュアル クラスタ構成。
ステップ 1 VCS Cluster Explorer を使用して、[APP] サービス グループを選択します。ショートカット メニューから、[Switch To]、[Remote Switch(...)] の順に選択して [Switch global] ダイアログボックスを開きます。ダイアログボックスで、リモート クラスタと、必要に応じてリモート クラスタ内の特定のサーバを指定します。または、次のコマンドを発行します。
ステップ 2 APP サービス グループのリソース ビューで、サービス グループのリソースがプライマリ クラスタでオフラインになることを確認します。ツリーでルート クラスタ ノードを選択し、[Remote Cluster Status] ビューを使用して、APP サービス グループがリモート クラスタでオンラインになることを確認します。または、次のコマンドを発行して、APP サービス グループのステータスを確認します。
ステップ 3 クライアント マシンから、ログイン ダイアログボックスで [Server Name] フィールドにセカンダリ クラスタで使用されている適切なホスト名またはアプリケーション IP アドレスを入力して Security Manager クライアントを起動します。アプリケーションに正常にログインできることを確認します。
ステップ 4 Security Manager クライアントからログアウトし、VCS Cluster Explorer または次のコマンドを使用して、APP サービス グループをプライマリ クラスタに切り替えます。
HA/DR 構成には、2 つのタイプのサーバ イーサネット接続があります。1 つ目はネットワーク通信に使用されるイーサネット接続です(パブリック インターフェイス)。2 つ目は、クラスタ内通信専用のイーサネット インターフェイスです(プライベート インターフェイス)。ここでは、イーサネット インターフェイスの各タイプの障害テスト ケースについて説明します。
ここでは、VCS がネットワーク通信に使用されているネットワーク イーサネット ポートの障害を検出できることを確認するために使用するテストを示します。ここでは、次の項目について説明します。
• 「セカンダリ サーバ、シングル クラスタにおけるネットワーク イーサネット障害」
• 「プライマリ サーバ、シングル クラスタにおけるネットワーク イーサネット障害」
テスト ケース タイトル:シングル クラスタ構成内のセカンダリ サーバのネットワーク イーサネット接続で障害が発生しました。
説明:このテスト ケースでは、VCS がセカンダリ サーバのネットワーク イーサネット ポートの障害を検出し、障害の修復後に回復できることを確認します。
テスト セットアップ:サーバごとに 1 本のネットワーク接続を備えたシングル クラスタ構成内のデュアル ノード クラスタ( ローカル冗長性 HA の構成)。
ステップ 1 アプリケーションがプライマリ サーバで実行されていることを確認します。
ステップ 2 クライアント マシンからアプリケーションにログインします。
ステップ 3 セカンダリ サーバのネットワーク ポートからイーサネット ケーブルを取り外して、スイッチ/ルータ ネットワークとの通信からサーバを分離します。VCS がネットワーク ポート障害を検出するまで少なくとも 60 秒間待機します。次のコマンドを実行して、VCS がセカンダリ サーバの NIC リソースの障害を検出することを確認します。
ステップ 4 セカンダリ サーバのネットワーク ポートにイーサネット ケーブルを戻します。次のコマンドを実行して、障害の解消を VCS が検出することを確認します。
テスト ケース タイトル:シングル クラスタ構成内のプライマリ サーバのネットワーク イーサネット接続で障害が発生しました。
説明:このテスト ケースでは、VCS がプライマリ サーバのネットワーク イーサネット ポートの障害を検出し、アプリケーションを自動的にセカンダリ サーバに切り替えることができることを確認します。問題が修正された後、アプリケーションを再びプライマリ サーバに手動で切り替えるできます。
テスト セットアップ:サーバごとに 1 本のネットワーク接続を備えたデュアル ノード クラスタ( デュアル ノード サイトのイーサネット接続とストレージ接続)。
ステップ 1 アプリケーションがプライマリ サーバで実行されていることを確認します。
ステップ 2 プライマリ サーバのネットワーク ポートからイーサネット ケーブルを取り外して、スイッチ/ルータ ネットワークとの通信からサーバを分離します。VCS が NIC リソースの障害を検出し、自動的にセカンダリ サーバに APP サービス グループを切り替えることを確認します。
ステップ 3 セカンダリ サーバで実行中のアプリケーションにログインできることを確認します。
ステップ 4 プライマリ サーバのネットワーク ポートのイーサネット ケーブルを交換し、プライマリ サーバの障害が発生している IP リソースを手動でクリアします。
ステップ 5 APP サービス グループを再びプライマリ サーバに手動で切り替えます。
テスト ケース タイトル:デュアル クラスタ構成内のセカンダリ サーバのネットワーク イーサネット接続で障害が発生しました。
説明:このテスト ケースでは、VCS がネットワーク イーサネット ポートの障害を検出し、障害の修復後に回復できることを確認します。
テスト セットアップ:クラスタごとにシングル ノード、およびサーバごとに 1 本のイーサネット ネットワーク接続を備えたデュアル クラスタ構成( 地理的冗長性(DR)の構成)。
ステップ 1 APP サービス グループがプライマリ クラスタ/サーバで実行されていることを確認します。
ステップ 2 クライアント マシンから Security Manager にログインします。
ステップ 3 セカンダリ クラスタ内のサーバのネットワーク ポートからイーサネット ケーブルを取り外します。これにより、スイッチ/ルータ ネットワークとの通信からサーバが分離され、複製が中断されます。プライマリ サーバで、次のコマンドを実行して、複製が中断(切断)されたことを確認します。
ステップ 4 プライマリ サーバから次のコマンドを実行して、セカンダリ クラスタとの通信が失われたことを確認します。
ステップ 5 ネットワーク イーサネット ケーブルをセカンダリ サーバに再接続し、複製が再開されたことを確認します。
ステップ 6 セカンダリ クラスタへの通信が復元されたことを確認します。
ステップ 7 複製が回復しない場合は、次のように障害が発生した IP リソースを手動でクリアし、次にセカンダリで APPrep サービス グループを開始する必要があります。
テスト ケース タイトル:プライマリ サーバのネットワーク イーサネット接続で障害が発生しました。
説明:このテスト ケースでは、VCS がプライマリ サーバのネットワーク イーサネット ポートの障害を検出し、セカンダリ サーバでアプリケーションを起動して回復できることを確認します。イーサネット接続の復元後、元のプライマリ サーバに手動でフェールオーバーし、セカンダリでの実行中に行われたデータ変更を保持します。
テスト セットアップ:各クラスタ内に 1 台のノードが配置されたデュアル クラスタ構成( 地理的冗長性(DR)の構成)。
ステップ 1 APP サービス グループがプライマリ クラスタで実行されていることを確認します。
ステップ 2 プライマリ クラスタ内のサーバのポートからイーサネット ケーブルを取り外して、スイッチ/ルータ ネットワークとの通信からサーバを分離します。VCS は、IP および NIC リソースの障害としてこれを検出する必要があります。VCS が障害を検出し、APP サービス グループを停止したことを確認します。
ステップ 3 セカンダリ サーバで次のコマンドを使用して、セカンダリ クラスタの APP サービス グループを開始します。
ステップ 4 クライアント マシンから、Security Manager にログインして Security Manager が動作していることを確認します。プライマリ サーバに切り替えたときに変更が維持されることを確認できるように、データを変更します。
ステップ 5 プライマリ クラスタ サーバにネットワーク イーサネット ケーブルを再接続します。
ステップ 6 IP リソースの障害を取り除き、プライマリ サーバから APPrep サービスをオンにします。
ステップ 7 元のプライマリ RVG をセカンダリに変換し、高速フェールバック機能を使用して、元のプライマリ RVG のデータ ボリュームを新しいプライマリ RVG のデータ ボリュームと同期します。セカンダリ クラスタの Cluster Explorer を使用して、RVGPrimary リソース(APP_RVGPrimary)を右クリックし、[actions] を選択して [Actions] ダイアログボックスから [fbsync] を選択し、[OK] をクリックします。または、次のコマンドを発行できます。
ステップ 8 セカンダリ クラスタで VCS Cluster Explorer を使用して、[APP] サービス グループを選択します。ショートカット メニューから、[Switch To]、[Remote Switch(...)] の順に選択して [Switch global] ダイアログボックスを開きます。ダイアログボックスで、プライマリ クラスタとプライマリ サーバを指定します。または、次のコマンドを発行します。
ステップ 9 アプリケーションにログインして、セカンダリ サーバに加えた変更が保持されていることを確認します。
テスト ケース タイトル:クラスタ通信に使用されるイーサネットで障害が発生しました。
説明:クラスタ内通信のためにクラスタ内のサーバ間で使用されている専用のイーサネット接続で障害が発生しました。テストでは、3 本のうち最大 2 本の冗長通信パスが失われた場合でも、クラスタ通信が継続されることを確認します。
テスト セットアップ:2 本の専用クラスタ通信イーサネット接続、およびネットワーク イーサネット接続に設定されたプライオリティの低いクラスタ通信接続を備えた、シングル クラスタ構成のデュアル ノード クラスタ( ローカル冗長性 HA の構成)。
(注) このテスト ケースで指定されたコマンドに加えて、Cluster Explorer からツリーでルート ノードを選択し、[System Connectivity] タブを選択することによってクラスタ通信のステータスをモニタできます。
(注) Group Membership Services/Atomic Broadcast(GAB)は、クラスタ メンバーシップやクラスタ通信を担当する VCS プロトコルです。
ステップ 2 プライマリ サーバでクラスタ通信に使用される最初の専用イーサネット ポートからイーサネット ケーブルを取り外します。
ステップ 3 次のコマンドを発行して、クラスタ通信に使用されるリンクの詳細なステータスを表示し、最初の専用クラスタ通信ポートがダウンしていることを確認します。
(注) 出力のアスタリスク(*)は、コマンドが実行されるサーバを示します。コマンドが実行されるサーバは、これらのポートの 1 つ以上が物理的に切断されている場合でも、常にリンクがアップしていることを示します。
ステップ 4 ネットワーク インターフェイスにプライオリティの低いハートビート リンクを設定した場合は、プライマリ サーバのクラスタ通信に使用される 2 本目の専用イーサネット ポートからイーサネット ケーブルを取り外します。
ステップ 5 次のコマンドを発行して、すべてのシステムが GAB を介して通信していることを確認します。各サーバではハートビートが 1 つだけ動作しているため、クラスタ内の両方のサーバが Jeopardy 状態になったことも確認します。
ステップ 6 次のコマンドを発行して、クラスタ通信に使用されるリンクの詳細なステータスを表示し、プライマリ サーバ上のクラスタ通信に使用される 2 つ目の専用イーサネット ポートがダウンしていることを確認します。
ステップ 7 プライマリ サーバでクラスタ通信に使用される 2 つ目の専用イーサネット ポートのイーサネット ケーブルを交換します。
ステップ 8 次のコマンドを発行して、Jeopardy 状態が解消されたことを確認します。
ステップ 9 プライマリ サーバでクラスタ通信に使用される最初の専用イーサネット ポートのイーサネット ケーブルを交換します。
ここでは、サーバから電源を取り外してサーバ障害を引き起こします。4 つのケースについて説明します。
テスト ケース タイトル:シングル クラスタ構成のスタンバイ サーバで障害が発生しました。
説明:このテスト ケースでは、プライマリ サーバで稼働しているアプリケーションが影響を受けないことと、スタンバイ サーバが修復された後、アプリケーションが正常にクラスタ構成に再度参加できることを確認します。
テスト セットアップ:2 本の専用クラスタ通信イーサネット接続、およびネットワーク イーサネット接続のプライオリティの低いクラスタ通信接続を備えた、デュアル ノード クラスタ( デュアル ノード サイトのイーサネット接続とストレージ接続)。
ステップ 1 アプリケーションがクラスタ内のプライマリ サーバで実行されていることを確認します。
ステップ 2 セカンダリ サーバの電源を取り外し、VCS が障害を検出し、アプリケーションがプライマリ サーバで実行し続けることを確認します。
ステップ 3 電源を再度適用し、セカンダリ サーバをブートします。サーバが回復したら、次のコマンドを実行して、正常な状態でクラスタに再接続されていることを確認します。出力はステップ 1 の出力と同一である必要があります。
テスト ケース タイトル:シングル クラスタ内のプライマリ サーバで障害が発生しました。
説明:このテスト ケースでは、プライマリ サーバで障害が発生するとセカンダリ サーバでアプリケーションが実行を開始することと、プライマリ サーバが修復された後、アプリケーションをプライマリ サーバで再設定できることを確認します。
テスト セットアップ:デュアル ノード クラスタ( ローカル冗長性 HA の構成)。
ステップ 1 次のコマンドの出力を調べて、APP サービス グループがクラスタ内のプライマリ サーバで実行されていることを確認します。
ステップ 2 プライマリ サーバの電源を取り外し、VCS が障害を検出し、APP サービス グループがセカンダリ サーバに正常に移行されることを確認します。
ステップ 3 クライアント マシンから Security Manager に正常にログインできることを確認します。
ステップ 4 電源をプライマリ サーバに復元し、サーバが正常な状態でクラスタに再参加できることを確認します。次のコマンドを実行します。出力はステップ 1 の出力と同一である必要があります。
ステップ 5 APP サービス グループを再びプライマリ サーバに手動で切り替えます。
テスト ケース タイトル:デュアル クラスタ構成のスタンバイ サーバで障害が発生しました。
説明:このテスト ケースでは、プライマリ クラスタで稼働しているアプリケーションがスタンバイ サーバの障害の影響を受けないことと、スタンバイ サーバが修復された後、アプリケーションが正常にデュアル クラスタ構成に再度参加できることを確認します。
テスト セットアップ:各クラスタ内に複製が行われる 1 台のノードが配置されたデュアル クラスタ構成( 地理的冗長性(DR)の構成)。
ステップ 1 プライマリ サーバで次のコマンドを実行して、APP および ClusterService サービス グループがプライマリ クラスタで動作していることを確認します。
ステップ 2 電源をセカンダリ サーバから取り外し、プライマリ クラスタがセカンダリ クラスタとの通信の喪失を検出することを確認します。
ステップ 3 セカンダリ サーバに電源を戻します。サーバの再起動後、プライマリ クラスタで次のコマンドを実行して、セカンダリ クラスタとの通信を再確立したことを確認します。出力はステップ 1 の出力と同一である必要があります。
ステップ 4 次のコマンドを実行して、複製が機能し、矛盾していないことを確認します。
テスト ケース タイトル:デュアル クラスタ構成のプライマリ サーバで障害が発生しました。
説明:このテスト ケースでは、プライマリ サーバで障害が発生するとセカンダリ サーバでアプリケーションが実行を開始することと、プライマリ サーバが修復された後、アプリケーションをプライマリ サーバで再設定できることを確認します。
テスト セットアップ:各クラスタ内に複製が行われる 1 台のノードが配置されたデュアル クラスタ構成( 地理的冗長性(DR)の構成)。
ステップ 1 セカンダリ サーバから次のコマンドを実行して、APP および ClusterService サービス グループがプライマリ クラスタで動作していることを確認します。
ステップ 2 プライマリ サーバから電源を取り外してサーバ障害を引き起こします。セカンダリ クラスタがプライマリ クラスタへの接続の喪失を報告したことを確認します。
ステップ 3 複製の状態が disconnected であることを確認します。次のコマンド出力の flags パラメータからこの状態を確認できます。
ステップ 4 次のコマンドを使用してセカンダリ サーバでアプリケーションを起動します。
ステップ 5 アプリケーションにログインし、プライマリ サーバに戻っても、アプリケーションがセカンダリ サーバ上で稼働している間に行われた変更を保持できることを後で確認できるように、データを変更します。
ステップ 6 電源をプライマリ サーバに戻し、サーバが完全に起動できるようにします。
ステップ 7 複製が connected であることを示す複製のステータスを確認します。ただし、両側が同期していません。
ステップ 8 元のプライマリ RVG をセカンダリに変換し、高速フェールバック機能を使用して、元のプライマリ RVG のデータ ボリュームを新しいプライマリ RVG のデータ ボリュームと同期します。セカンダリ クラスタの Cluster Explorer を使用して、RVGPrimary リソース(APP_RVGPrimary)を右クリックし、[actions] を選択して [Actions] ダイアログボックスから [fbsync] を選択し、[OK] をクリックします。または、次のコマンドを発行できます。
ステップ 9 次のコマンド出力の flags パラメータの consistent キーワードを調べて、現在のセカンダリ(以前のプライマリ)が現在のプライマリ(以前のセカンダリ)と同期していることを確認します。
ステップ 10 セカンダリ クラスタで VCS Cluster Explorer を使用して、[APP] サービス グループを選択します。ショートカット メニューから、[Switch To]、[Remote Switch(...)] の順に選択して [Switch global] ダイアログボックスを開きます。ダイアログボックスで、プライマリ クラスタとプライマリ サーバを指定します。または、次のコマンドを発行します。primarycluster はプライマリ クラスタの名前です。
ステップ 11 アプリケーションにログインして、セカンダリ サーバに加えた変更が保持されていることを確認します。
ここでは、Security Manager アプリケーションで障害が発生した場合のテスト ケースについて説明します。シングル クラスタ構成とデュアル クラスタ構成の 2 つのケースについて説明します。ここでは、次の項目について説明します。
テスト ケース タイトル:シングル クラスタ構成内のプライマリ サーバでアプリケーションの障害が発生しました。
説明:このテスト ケースでは、VCS がアプリケーションの障害を検出し、アプリケーションを自動的にセカンダリ サーバに移行することを確認します。
テスト セットアップ:デフォルトのアプリケーション フェールオーバー動作を使用するデュアル ノード クラスタ( ローカル冗長性 HA の構成)。
ステップ 1 次のコマンドを実行して、APP サービス グループがクラスタ内のプライマリ サーバで実行されていることを確認します。
ステップ 2 Security Manager が実行されているサーバで、次のコマンドを発行してアプリケーションを停止します。
ステップ 3 VCS がプライマリ サーバで Security Manager が失敗したことを検出し、アプリケーションをセカンダリ サーバで開始することを確認します。
ステップ 4 APP サービス グループの障害を手動で解決します。
ステップ 5 APP サービス グループを再びプライマリ サーバに手動で切り替えます。
テスト ケース タイトル:デュアル クラスタ構成内のプライマリ サーバでアプリケーションの障害が発生しました。
説明:このテスト ケースでは、VCS がアプリケーションの障害を検出することを確認します。
テスト セットアップ:各クラスタ内に複製が行われる 1 台のノードが配置されたデュアル クラスタ構成( 地理的冗長性(DR)の構成)。同様に、デフォルトのアプリケーション フェールオーバー動作が変更されていない(つまり、クラスタ間のフェールオーバーに手動による介入が必要である)ことを前提とします。
ステップ 1 プライマリ サーバで次のコマンドを実行して、APP および ClusterService サービス グループがプライマリ クラスタで動作していることを確認します。
ステップ 2 Security Manager が実行されているサーバで、次のコマンドを発行してアプリケーションを停止します。
ステップ 3 VCS がアプリケーションの障害を検出し、APP サービス グループを停止したことを確認します。次のコマンドを発行し、出力を確認します。
ステップ 4 APP サービス グループの障害を手動で解決します。
ステップ 5 APP サービス グループをプライマリ サーバでオンラインにしてアプリケーションを再起動します。