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

2.11　複数サブネットの場合の構成例（災害復旧用途）

◆ 複数サブネットの場合の構成例（災害復旧用途）

可用性グループは、サブネットをまたがっても構成することができるので、DR（Disaster Recovery:災害復旧）用途として、遠隔地へセカンダリを配置することもできます。ここでは、次の図ように 192.168.1 のサブネット（東京）と 172.16 のサブネット（大阪）がある場合の構成方法を説明します。

WSFC（Windows Server フェールオーバー クラスター）では、異なるサブネットのノードが存在する場合には、クラスター作成時の「クラスター作成」ウィザードで、次のようにサブネットごとに IP アドレスを設定することができます。

複数サブネットの場合は、クラスター名（画面は CLUSTER001）に対して、2つの IP アドレスが登録されて、どちらか一方がオンラインになるように設定されます。これは、クラスター名のプロパティを開いて、次のように［依存関係］タブから確認することができます。

OR 条件で 2つの IP アドレスが登録されることで、どちらかの IP アドレスに依存するクラスター名が作成されることで、サブネットをまたがってフェールオーバーが発生しても、クライアントからは同じクラスター名でアクセスできるようになります。

このように構成されたクラスターの状態で可用性グループを作成すれば、サブネットをまたがって 可用性グループを構成することができます。作成手順は、前の Step で説明したものとほとんど同じで、違いはリスナー（仮想サーバー名／仮想 IP アドレス）を作成するところだけです。

［新しい可用性グループ］ウィザードの［レプリカの指定］ページの［リスナー］タブで、［リスナー DNS 名］へ任意のリスナー名（AG1_Listener など）を入力、［ポート］へ任意のポート番号（1433 など）、［ネットワーク モード］で「静的 IP」を選択して、［追加］ボタンをクリックし、2つの IP アドレスを追加します（画面は 192.168.1.122 と 172.16.1.122 を追加）。

このようにリスナーには、複数の IP アドレスを登録することができます。

このように作成したリスナーは、フェールオーバー クラスター マネージャーからは、次のように確認できます。

OR 条件で 2つの IP アドレスが登録されることで、どちらかに依存するリスナー名（画面は AG1_Listener）が作成されます。192.168.1 のサブネットに属する SERVER1 または SERVER2 がプライマリの場合には、192.168.1.122 がオンライン、172.16 のサブネットに属する SERVER3 がプライマリになった場合には、172.16.1.122 がオンラインになり、それに依存するリスナー名が利用可能になります。これにより、サブネットをまたがったフェールオーバーが発生した場合でも、クライアントからは同じリスナー名でアクセスすることができます。

以上で、複数サブネットでの可用性グループの構成が完了です。ほかの手順（手動フェールオーバーや強制フェールオーバー、RESUME、障害から復旧手順など）は、これまでの Step で説明したものとまったく同じ手順です。

◆ MultiSubnetFailover=True の追加

複数サブネット構成の場合、.NET Framework で作成するクライアント アプリケーションには、接続文字列へ「MultiSubnetFailover=True」を追加しておく必要があります（追加することで迅速なフェールオーバーが可能になります）。

MultiSubnetFailover=True は、SQL Server Native Client 11.0（SQL Server 2012 で提供される SQL Server Native Client）から利用できるようになったオプションです。

◆ DR 目的のリモート サイトのノードには投票権を与えない（NodeWeight=0）

DR（災害復旧）目的の場合は、リモート サイトの WSFC クラスター ノードには投票権（Vote）を与えない（NodeWeight を 0 へ設定する）ようにします。こうすることで、リモート サイトのノードの障害が、プライマリ サイト（メインのノードを配置している場所）へ影響を与えることを防ぐことができます。

NodeWeight を 0 へ設定するには、Windows の修正プログラム「KB 2494036」を適用しておく必要があります。

現在の NodeWeight 設定を確認するには（既定では全てのノードが 1に設定される）、次のように Cluster コマンドを利用します。

NodeWeight を 0 へ設定するには、次のように Cluster コマンドを利用します。

設定内容を確認するには、前述のコマンドを再度実行します。

なお、Management Studio を利用して、「dm_hadr_cluster_members」ビューを参照しても、NodeWeight の設定を確認することができます。

◆ ローカル ノードが 2台の場合は「ノードおよびファイル共有マジョリティ」

3台のノードで DR を構成する場合（ローカル サイトが 2台、リモート サイトが 1台）の場合には、リモート サイトのノードの NodeWeight を 0 にする（投票権を削除する）ことで、ローカル サイトは 2個の投票権のみとなってしまい、これでは障害対策にならない（1台のノードの障害でクラスターが停止してしまう）ので、クォーラム構成を「ノード マジョリティ」から「ノードおよびファイル共有マジョリティ」へ変更するなどの対処も必要になります。

なお、ファイル共有マジョリティの代わりに、ローカル サイトへノードをもう1台追加して、「ノード マジョリティ」で構成することでも障害対策が可能です。クォーラム構成については、オンライン ブックの以下の場所も参考になります。

WSFC クォーラム モードと投票の構成 (SQL Server)
http://msdn.microsoft.com/ja-jp/library/hh270280.aspx

◆ その他の参考資料

実際に、複数サブネット構成を構築する際には、以下のドキュメントも一読しておくことをお勧めします。

AlwaysOn 可用性グループの前提条件、制限事項、および推奨事項（HostRecordTTL を設定する (60秒を推奨) など）
http://msdn.microsoft.com/ja-jp/library/ff878487

Configure Heartbeat and DNS Settings in a Multi-Site Failover Cluster
http://technet.microsoft.com/en-us/library/dd197562(WS.10).aspx

Requirements and Recommendations for a Multi-Site Failover Cluster
http://technet.microsoft.com/en-us/library/dd197575(WS.10).aspx