SQL Server 2012 自習書シリーズ （HTML 版）
新機能編 No.2「AlwaysOn による可用性の向上」

2.10　障害のシミュレーション2： 2台のサーバーが障害発生した場合

◆ 障害のシミュレーション2： 2台のサーバーが障害発生した場合

次に、可用性グループを構成する ３台の SQL Server のうち、2台（SERVER1、SERVER2）に障害が発生した場合の動作を確認してみましょう。

◆ Let's Try

それでは、これを試してみましょう。ここでは、まず現在のプライマリ（SERVER2）を停止して、自動フェールオーバーされるのを待ち、その後新しいプライマリとなった SERVER1 を停止してみましょう。

1．まずは、現在のプライマリ（SERVER2）をシャットダウンして、OS を停止します（Hyper-V などの仮想環境で試している場合は、仮想マシンの［停止］（電源オフ）をクリックして、より現実に近い障害をシミュレートしてみてください）。

2．プライマリがシャットダウンされることにより、自動フェールオーバーが発生し（10～20秒でフェールオーバーが完了）、セカンダリ（SERVER1）がプライマリへ切り替わることを確認できます。自動フェールオーバーが発生したことを確認するには、オブジェクト エクスプローラーを最新の情報に更新します。

SERVER1 がプライマリへ変更されて、SERVER2 との［接続状態］が「接続解除」、［同期状態］が「同期されていません」と表示されていることを確認できます。

3．次に、フェールオーバー クラスター マネージャーを起動して、リソースの所有者が SERVER1 へ変更されていることを確認します。

4．次に、［ノード］をクリックすると、SERVER2 が停止状態になっていることを確認できます。

5．次に、Visual Studio 2010 で作成した Windows アプリケーションを実行して、正しく結果が取得できることを確認します。

6．次に、SERVER1 へ接続して、データを 1件追加しておきます。

◆ 2台目のサーバー（SERVER1）の停止

1．次に、SERVER1 をシャットダウンして、OS を停止します（Hyper-V などの仮想環境で試している場合は、仮想マシンの［停止］（電源オフ）をクリックして、より現実に近い障害をシミュレートしてみてください）。

SERVER1 がシャットダウンされることにより、残りは非同期モードへ設定したセカンダリ（SERVER3）のみになります。

2．シャットダウン後、SERVER3 で Management Studio を起動して、［可用性グループ］フォルダーを確認します。

SERVER3 は「解決中」と表示されて、正常に動作していないことを確認できます。

3．次に、フェールオーバー クラスター マネージャーを起動します。

クラスター内のノードが表示されず、クラスター全体が停止していることを確認できます。今回は SERVER1、SERVER2、SERVER3 の 3台でクラスターを構成しているので、クォーラムを既定値の「ノード マジョリティ」へ設定しています。この設定の場合、3台中 2台のノードが停止したときに、クラスターとしての機能を停止する、という動作をとります。したがって、現在 SERVER1 と SERVER2 の 2台が停止しているので、全体として停止された状態になっています。

◆ クラスター サービスの起動（forcequorum オプション）

1．この状態で、クラスターを起動するには、forcequorum または fixquorumオプションを利用してククラスター サービスを起動します。このオプションを利用すると、現在のクォーラムに問題があったとしてもクラスター サービスを起動することができます。

これを行うには、まずコマンド プロンプトを起動します。

2．次に、net start コマンドを利用して、forcequorum オプションを利用してクラスター サービス（clussvc）を起動します。

なお、サービスが開始されずに、「要求したサービスは既に開始されています」というエラーが表示される場合は、いったん net stop コマンドを利用してクラスター サービス（clussvc）を停止してから（net stop clussvc と入力／実行して、サービスを停止してから）、上記のコマンドを再実行してみてください。

◆ 強制フェールオーバーの実行

クラスター サービスが開始されたら、次は強制フェールオーバー（FORCE～ オプション）を実行します。

1．強制フェールオーバーを実行するには、Management Studio で SERVER3 へ接続し、次のように FORCE_FAILOVER_ALLOW_DATA_LOSS を指定して、ALTER AVAILABILITY GROUP ステートメントを実行します。

このステートメントは、約10秒程度で完了します。これが完了すると、クライアント アプリケーションからアクセスできるようになるので、障害発生時のダウンタイム（停止時間）は、障害検知から、クラスター サービスの開始、強制フェールオーバーの実行完了まで、と非常に短い時間で済みます。

ただし、前述したように、非同期モードでは、データを失う可能性がある（同期がとれていない可能性がある）ので、実際の障害発生時には、ネットワーク障害などによるデータ転送遅延なども起こりえるため、最新のデータであるかどうかは、手動でデータを確認していく必要があります。

2．次に、オブジェクト エクスプローラーを最新の情報に更新します。

SERVER3 がプライマリとして正常に動作していることを確認できます。

3．次に、フェールオーバー クラスター マネージャーで、リソースの所有者が SERVER3 へ変更されていることを確認します。

4．次に、Visual Studio 2010 で作成した Windows アプリケーションを実行して、正しく結果が取得できることを確認します。

最後に追加したデータ（7）も正しく取得できていることを確認できます。このように、可用性グループでは、障害が発生しても、アプリケーションを変更することなく、アプリケーションからはどのサーバーが処理しているかを意識することなく、透過的にアクセスすることが可能です。

以上で、2台のサーバーに障害が発生した場合のシミュレーションが完了です。従来のバージョンでは、3台以上で高可用性を実現する場合には、「WSFC と DBM の組み合わせ」や「WSFC とログ配布の組み合わせ」などを利用する必要がありましたが、SQL Server 2012 からは可用性グループのみで 3台以上の高可用性を簡単に実現できます。また、障害時のダウンタイムも大幅に短縮できます。可用性グループではリスナー機能が提供されたことで、アプリケーションを修正する必要がないからです。また、障害検知に WSFC のリソース機能を利用しているので、迅速な障害検知も可能です。

可用性グループは、コスト面でのメリットもあります。従来の WSFC による SQL Server クラスターでは、共有ストレージ（エントリ クラスでも数百万円～）が必須であったり、DBM での自動フェールオーバー構成時には、監視サーバー（ウィットネス）を別途用意する必要があったりしましたが、可用性グループではこれらは不要です。

可用性グループは、性能面では、データ転送のオーバーヘッドがありますが、ローカルのストレージ（筐体内の HDD や SSD）を利用できることで、共有ストレージよりも性能の良いストレージを選択できるメリットがあるので、書き込みよりも読み取り操作の多いシステムの場合には、逆に性能面でのメリットにもなります。

◆ SERVER1 と SERVER2 が復旧した場合

障害発生後に、SERVER1 や SERVER2 が何の問題もなく復旧できる場合は、現在の可用性グループ（SERVER3 がプライマリ）へ簡単に参加させることができます。これは、前の Step で試した RESUME オプションで同期の再開を行うだけで完了します。これも試してみましょう。

1．まずは、SERVER1 を起動します。

2．SERVER1 が起動したら、Management Studio を起動して、［可用性グループ］フォルダーを確認します。

［可用性データベース］フォルダーを展開すると、AGTestDB データベースのアイコンが白くなっていて、同期が行われていないことを確認できます。

3．次に、SERVER1 へ接続して、RESUME を実行します。

4．実行が完了したら、オブジェクト エクスプローラーを最新の情報に更新します。

データベースが「緑」のアイコンに変わって、同期が再開されたことを確認できます。

5．次に、SELECT ステートメントを実行して、t1 テーブルのデータが複製されていることを確認します。

6．次に、フェールオーバー クラスター マネージャーを起動して、ノードの状態を確認します。

SERVER1 が「稼働中」と表示されて、クラスターのノードとしても正常に動作していることを確認できます。

7．次に、SERVER2 を起動します。

8．SERVER2 に対しても、SERVER1 に対して行った RESUME を実行するだけで、SERVER3 をプライマリとした可用性グループのメンバーにすることができます。また、同期モードを変更したり、別のノードを可用性グループへ追加したりすることも簡単に行えるので、SERVER3 をプライマリとした新しい可用性グループを構成していくことも簡単です。

なお、SERVER1 をプライマリとした元の構成（一番最初の構成）へ戻したい場合でも、前の Step の手順（FORCE～ での強制フェールオーバーと RESUME での同期の再開）を全く同じように操作するだけで元に戻すことができます。この場合の手順は、次のとおりです。