この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、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 クライアント マシンで、[login] ダイアログボックスの [Server Name] フィールドで、仮想ホスト名または IP アドレスを使用して Security Manager クライアントを起動します。アプリケーションに正常にログインできることを確認します。
事例タイトル:クラスタ間の手動によるアプリケーション切り替え
説明:アプリケーションを、VCS を使用する別のクラスタ内のサーバへ手動で切り替えます。
テスト セットアップ:各クラスタに単一サーバを備えた 地理的冗長性(DR)コンフィギュレーション で示すデュアル クラスタ コンフィギュレーション。
ステップ 1 VCS Cluster Explorer で、[APP] サービス グループを選択します。ショートカット メニューで [Switch To] を選択してから [Remote Switch(...)] を選択し、[Switch global] ダイアログボックスを開きます。このダイアログボックスで、リモート クラスタを指定し、必要に応じてリモート クラスタでの特定のサーバを指定します。あるいは、次のコマンドを実行します。
ステップ 2 APP サービス グループのリソース ビューで、このサービス グループにあるリソースがプライマリ クラスタでオフラインになるのを確認します。ツリー内のクラスタ ノードを選択し、[Remote Cluster Status] ビューを使用して APP サービス グループがリモート クラスタでオンラインになることを確認します。または次のコマンドを実行して、APP サービス グループの状況を観察します。
ステップ 3 クライアント マシンで、[Login] ダイアログボックスの [Server Name] フィールドで、セカンダリ クラスタで使用されている適切なホスト名またはアプリケーションの IP アドレスを入力して Security Manager クライアントを起動します。アプリケーションに正常にログインできることを確認します。
ステップ 4 Security Manager からログアウトし、VCS Cluster Explorer または次のコマンドを使用して、APP サービス グループをプライマリ クラスタに切り替えます。
HA/DR コンフィギュレーションには、2 つのタイプのサーバ イーサネット接続があります。最初のタイプは、ネットワーク通信に使用されるイーサネット接続(パブリック インターフェイス)で、2 番目のタイプは、クラスタ内通信専用として使用されるイーサネット インターフェイス(専用インターフェイス)です。ここでは、イーサネット インターフェイスの個々のタイプに関する障害事例を説明します。
ここでは、VCS がネットワーク通信に使用されるネットワーク イーサネット ポートの障害を検出できるかどうかの検証に使用されるテストについて説明します。ここでは、次の内容について説明します。
• 「セカンダリ サーバ、単一クラスタでのネットワーク イーサネット障害」
• 「プライマリ サーバ、単一クラスタでのネットワーク イーサネット障害」
事例タイトル:単一クラスタ コンフィギュレーションでのセカンダリ サーバ上のネットワーク イーサネット接続で障害が発生します。
説明:この事例は、VCS がセカンダリ サーバ上のネットワーク イーサネット ポートでの障害を検出し、次にこの障害が復旧してから回復できることを検証します。
テスト セットアップ:サーバ単位で単一ネットワーク接続を備えた単一クラスタ コンフィギュレーションでのデュアル ノード クラスタ( ローカル冗長性 HA コンフィギュレーション)。
ステップ 1 アプリケーションがプライマリ サーバで実行されていることを確認します。
ステップ 2 クライアント マシンからアプリケーションにログインします。
ステップ 3 セカンダリ サーバ上のネットワーク ポートからイーサネット ケーブルを取り外し、スイッチ ネットワーク/ルータ ネットワークとの通信からサーバを切断します。VCS がネットワーク ポート障害を検出するまで 60 秒以上待ちます。次のコマンドを実行して、VCS がセカンダリ サーバ上で NIC リソースの障害を検出することを確認します。
ステップ 4 セカンダリ サーバ上のネットワーク ポートでイーサネット ケーブルを元に戻します。次のコマンドを実行して、障害の解消を VCS が検出することを確認します。
事例タイトル:単一クラスタ コンフィギュレーションでのプライマリ サーバ上のネットワーク イーサネット接続で障害が発生します。
説明:この事例は、VCS がプライマリ サーバのネットワーク イーサネット ポートでの障害を検出し、自動的にアプリケーションをセカンダリ サーバへ切り替えることを検証します。問題が修正されると、アプリケーションを手動でプライマリ サーバに戻すことができます。
テスト セットアップ:各サーバに単一ネットワーク接続を備えたデュアル ノード クラスタ( デュアル ノード サイトのイーサネット接続およびストレージ接続)。
ステップ 1 アプリケーションがプライマリ サーバで実行されていることを確認します。
ステップ 2 プライマリ サーバ上のネットワーク ポートからイーサネット ケーブルを取り外し、スイッチ ネットワーク/ルータ ネットワークとの通信からサーバを切断します。VCS が NIC リソースの障害を検出し、APP サービス グループをセカンダリ サーバに自動的に切り替えることを確認します。
ステップ 3 アプリケーションがセカンダリ サーバ上で実行されている間に、このアプリケーションにログインできることを確認します。
ステップ 4 プライマリ サーバのネットワーク ポートにイーサネット ケーブルを取り付け、プライマリ サーバ上の障害が発生している IP リソースを手動で解消します。
ステップ 5 APP サービス グループを手動でプライマリ サーバに戻します。
事例タイトル:デュアル クラスタ コンフィギュレーションでのセカンダリ サーバ上のネットワーク イーサネット接続で障害が発生します。
説明:この事例は、VCS がネットワーク イーサネット ポート上で障害を検出し、次にこの障害が復旧してから回復できることを検証します。
テスト セットアップ:各クラスタ内に単一ノードを備え、各サーバに単一イーサネット ネットワーク接続を備えたデュアル クラスタ コンフィギュレーション( 地理的冗長性(DR)コンフィギュレーション)。
ステップ 1 APP サービス グループがプライマリ クラスタ/プライマリ サーバで実行されているかどうか確認します。
ステップ 2 クライアント マシンから Security Manager にログインします。
ステップ 3 セカンダリ クラスタで、サーバ上のネットワーク ポートからイーサネット ケーブルを取り外します。これにより、スイッチ ネットワーク/ルータ ネットワークとの通信からサーバが切り離され、レプリケーションが中断します。次のコマンドを実行して、プライマリ サーバからレプリケーションが中断(切断)されたことを確認します。
ステップ 4 プライマリ サーバから次のコマンドを実行して、セカンダリ クラスタとの通信が失われたことを確認します。
ステップ 5 ネットワーク イーサネット ケーブルをセカンダリ サーバに取り付け直し、レプリケーションが再開されたことを確認します。
ステップ 6 セカンダリ クラスタへの通信が復元されていることを確認します。
ステップ 7 レプリケーションが回復されていない場合は、IP リソースに障害がある場合はこれを手動で解消し、次のようにセカンダリ側で APPrep サービス グループを開始します。
事例タイトル:プライマリ サーバ上のネットワーク イーサネット接続で障害が発生します。
説明:この事例は、VCS がプライマリ サーバのネットワーク イーサネット ポートでの障害を検出し、セカンダリ サーバでアプリケーションを開始することにより回復できることを検証します。イーサネット接続の復元後、手動で元のプライマリ サーバにフェールオーバーできます。セカンダリ サーバでの実行中に行われたデータの変更はすべて保持されます。
テスト セットアップ:各サーバに単一ノードを備えたデュアル クラスタ コンフィギュレーション( 地理的冗長性(DR)コンフィギュレーション)。
ステップ 1 APP サービス グループがプライマリ クラスタで実行されているかどうか確認します。
ステップ 2 プライマリ クラスタ内のサーバ上のポートからネットワーク イーサネット ケーブルを取り外し、スイッチ ネットワーク/ルータ ネットワークとの通信からサーバを切断します。VCS は、これを IP リソースおよび NIC リソースの障害として検出するはずです。VCS が障害を検出し、APP サービス グループを停止したことを確認します。
ステップ 3 セカンダリ サーバで次のコマンドを使用して、セカンダリ クラスタで APP サービス グループを開始します。
ステップ 4 クライアント マシンから 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 コンフィギュレーション)。
(注) この事例で指定されたコマンドに加えて、ツリーのルート ノードと [System Connectivity] タブを選択することで、Cluster Explorer からクラスタ通信の状況を監視できます。
(注) 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 サービス グループを手動でプライマリ サーバに戻します。
事例タイトル:デュアル クラスタ コンフィギュレーション内のスタンバイ サーバで障害が発生します。
説明:この事例は、プライマリ クラスタで実行されるアプリケーションはスタンバイ サーバの障害による影響を受けず、スタンバイ サーバの復旧後、アプリケーションがデュアル クラスタ コンフィギュレーションに正常に復帰できることを確認します。
テスト セットアップ:各サーバに単一ノードを備えたデュアル クラスタ コンフィギュレーション(レプリケーションあり)( 地理的冗長性(DR)コンフィギュレーション)。
ステップ 1 次のコマンドをプライマリ サーバで実行して、APP サービス グループおよび ClusterService サービス グループがプライマリ サーバで実行されていることを確認します。
ステップ 2 セカンダリ サーバの電源を切り、プライマリ クラスタが、セカンダリ クラスタへの通信が切断されたことを検出します。
ステップ 3 セカンダリ サーバの電源を入れます。サーバの再起動後、次のコマンドを実行して、プライマリ クラスタがセカンダリ クラスタとの通信を再確立したことを確認します。出力は、ステップ 1 の出力と同じになるはずです。
ステップ 4 次のコマンドを実行して、レプリケーションが動作中で一貫していることを確認します。
事例タイトル:デュアル クラスタ コンフィギュレーション内のプライマリ サーバで障害が発生します。
説明:この事例は、プライマリ サーバで障害が発生した場合、アプリケーションはセカンダリ サーバでの実行を開始し、プライマリ サーバの復元後、アプリケーションがプライマリ サーバで再確立できることを検証します。
テスト セットアップ:各サーバに単一ノードを備えたデュアル クラスタ コンフィギュレーション(レプリケーションあり)( 地理的冗長性(DR)コンフィギュレーション)。
ステップ 1 次のコマンドをセカンダリ サーバで実行して、APP サービス グループおよび ClusterService サービス グループがプライマリ サーバで実行されていることを確認します。
ステップ 2 サーバ障害を発生させるためにプライマリ サーバの電源を切ります。セカンダリ クラスタがプライマリ クラスタへの接続の切断を報告したことを確認します。
ステップ 3 レプリケーションが切断状態であることを確認します。次のコマンドの出力に含まれる flags パラメータでこの状態を確認できます。
ステップ 4 次のコマンドを使用して、セカンダリ サーバでアプリケーションを開始します。
ステップ 5 アプリケーションにログインし、一部のデータを変更して、アプリケーションがセカンダリ サーバで動作中に行われた変更が、プライマリ サーバに戻る際に保持されることを後から確認できるようにします。
ステップ 6 プライマリ サーバの電源を入れ、サーバが完全に起動できるようにします。
ステップ 7 レプリケーションは接続しているが、2 つのサイドは同期を維持していないことを示すレプリケーションの状況を確認します。
ステップ 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 がアプリケーション障害を検出し、VCS がアプリケーションをセカンダリ サーバに自動的に移行することを検証します。
テスト セットアップ:デフォルトのアプリケーション フェールオーバーの動作を使用したデュアル ノード クラスタ( ローカル冗長性 HA コンフィギュレーション)。
ステップ 1 次のコマンドを実行することにより、APP サービス グループがクラスタ内のプライマリ サーバで実行中であることを確認します。
ステップ 2 Security Manager が実行されているサーバで次のコマンドを実行して、アプリケーションを停止します。
ステップ 3 VCS が、プライマリ サーバで Security Manager に障害が発生したことを検出し、アプリケーションをセカンダリ サーバで開始することを確認します。
ステップ 4 APP サービス グループの障害を手動で解消します。
ステップ 5 APP サービス グループを手動でプライマリ サーバに戻します。
事例タイトル:デュアル クラスタ コンフィギュレーションでのプライマリ サーバでアプリケーションに障害が発生します。
説明:この事例は、VCS がアプリケーション障害を検出することを検証します。
テスト セットアップ:各サーバに単一ノードを備えたデュアル クラスタ コンフィギュレーション(レプリケーションあり)( 地理的冗長性(DR)コンフィギュレーション)。同様に、デフォルトのアプリケーション フェールオーバー動作は変更されていない(つまり、クラスタ間のフェールオーバーには手動介入が必要である)ことを前提にしています。
ステップ 1 次のコマンドをプライマリ サーバから実行して、APP サービス グループおよび ClusterService サービス グループがプライマリ サーバで実行されていることを確認します。
ステップ 2 Security Manager が実行されているサーバで次のコマンドを実行して、アプリケーションを停止します。
ステップ 3 VCS が、アプリケーションが失敗したことを検出し、APP サービス グループを停止することを確認します。次のコマンドを実行して出力を確認します。
ステップ 4 APP サービス グループの障害を手動で解消します。
ステップ 5 プライマリ サーバで APP サービス グループをオンラインにして、アプリケーションを再起動します。