SQL Server 2012 ではマルチサブネットフェールオーバークラスターがサポートされます。
実際には、AlwaysOn フェールオーバークラスターインスタンス (FCI) や AlwaysOn 可用性グループ (AG) でマルチサブネット構成を使用することになるかと思います。
マルチサブネットフェールオーバークラスターを使用する場合の注意点について少しまとめてみたいと思います。
Data Case01 緊急時に備えてデータを堅守 のような環境を作成する場合に考慮する必要が出てくるかと。
基本的な情報は
SQL Server マルチサブネット クラスタリング
SQL Server 2012 リリース ノート (ja-JP)
■デフォルトの設定の DNS の登録状況
今回は可用性グループをマルチサブネットの環境で構築しています。
マルチサブネットの環境ではクラスターの IP アドレスが OR で設定され、実行するノードのサブネットに合わせた IP アドレスのみがオンラインの状態となります。
# 実際には両方オンラインにしようとして、対応したものだけがオンラインにできている状態だったはずですが。 
デフォルトの設定では、DNS には両方の IP アドレスが登録されます。 
SQL Server 2012 に対応した SQL Server Native Client 11.0 を使用できる場合は、接続文字列に MultiSubnetFailover を使用することができるようになります。
# 、ADO.NET with .NET Framework 3.5SP1 または SQL Native Client 11.0 OLEDB ではこのオプションが使用できないようなので注意が必要です。
なお、.NET Framewor 4.0 を使用している場合、4.0.2 が AlwaysOn に対応するための更新が入っているものになりますのでこちらを適用しておいたほうがよいかと。
Update 4.0.2 for Microsoft .NET Framework 4 – Runtime Update
高可用性障害復旧のための SqlClient サポート
JDBC を使用する場合は 高可用性、障害回復のための JDBC Driver のサポート ですね。
WSFC ではクライアントアクセスポイントとして仮想コンピューターオブジェクトのコンピューターアカウントが AD 上に作成され、そのコンピューターアカウントに設定されている IP アドレスが DNS に登録されています。
デフォルトの設定ではクラスターリソースのネットワーク名のオブジェクトは RegisterAllProvidersIP が 1 で設定されています。 
この設定はネットワーク名に関連した IP アドレスをすべて登録するという設定になります。
そのため、IP アドレスがオンライン / オフラインの状態にかかわらず DNS に登録されます。
オンラインになっている IP アドレスのみを登録する場合は、 
というようなコマンドを実行して、RegisterAllProvidersIP の設定を 0 に設定します。
この設定をすることで、オンラインの IP アドレスのみが DNS に登録されるようになります。
■RegisterAllProvidersIP の使い分け
RegisterAllProvidersIP は 1 / 0 のどちらを設定すればよいかですが、これは接続元のアプリケーションに依存してくると思います。
私は、接続文字列に MultiSubnetFailover が使用できる場合は 1 を、使用できない場合には 0 を設定するのが良いかと考えています。
SQL Server 2012 のリリースノートに以下の記載があります。
.NET Framework 3.5 および OLEDB で MultiSubnetFailover=True はサポートされない
異なるサブネットからの複数の IP アドレスに応じて可用性グループまたはフェールオーバー クラスター インスタンスにリスナー名 (ネットワーク名または WSFC クラスター マネージャーのクライアント アクセス ポイント) がある場合、ADO.NET with .NET Framework 3.5SP1 または SQL Native Client 11.0 OLEDB を使用している場合は、可用性グループ リスナーに対するクライアント接続要求の 50% が接続タイムアウトに達する可能性があります。
回避策: 次のいずれかのタスクを実行することをお勧めします。
- クラスター リソースを操作する権限がない場合は、接続タイムアウトを 30 秒に設定します (この値は結果として、20 秒の TCP タイムアウトと 10 秒のバッファーになります)。
- 長所: クロスサブネット フェールオーバーが発生した場合、クライアントの復旧時間が短くなります。
- 短所: 半数のクライアント接続に 20 秒以上要します。
- クラスター リソースを操作する権限がある場合は、可用性グループ リスナーのネットワーク名を RegisterAllProvidersIP=0 に設定するアプローチの方をお勧めします。詳細については、後の「RegisterAllProvidersIP を無効にし、TTL を短縮する PowerShell サンプル スクリプト」を参照してください。
- 長所: クライアント接続のタイムアウト値を大きくする必要がありません。
- 短所: クロスサブネット フェールオーバーが発生した場合、クロスサイト DNS/AD レプリケーション スケジュールの HostRecordTTL 設定によっては、クライアントの復旧時間が 15 分以上になる可能性があります。
デフォルトの設定では、RegisterAllProvidersIP は 1 が設定されているため、すべての IP アドレスが登録されます。
DNS に登録されている IP アドレスの中で、オンラインになっているのはネットワーク名の所有者のノードのサブネットと一致するものになりますので、DNS に登録さている IP アドレスの中でアクセスができない IP アドレスが存在することになります。
それでは、MultiSubnetFailover の有効、無効による接続方法の違いを見ていきたいと思います。
SQL Server Narive Client 11.0 がインストールされている環境で、このドライバーを使用して ODBC の設定をする場合、マルチサブネット フェールオーバーを有効にすることができます。 
この設定が有効な場合、SQL Server に接続する際には以下のようなネットワークパケットが流れます。 
設定が有効でない場合はこのようなネットワークパケットとなります。 
この動作について BOL に以下のように記載されています。
複数サブネットの FCI 既定で RegisterAllProvidersIP のクラスター リソースのネットワーク名を有効にします。 マルチサブネット構成では、ネットワーク名のオンラインおよびオフライン両方の IP アドレスが DNS サーバーに登録されます。 クライアント アプリケーションは、すべての登録済み IP アドレスを DNS サーバーから取得し、受信した順序または並列で使用してアドレスへの接続を試みます。 つまり、マルチサブネット フェールオーバーのクライアント回復時間は DNS 更新の待機時間に依存しません。 既定では、クライアントは IP アドレスを順番に試行します。 クライアントが新しいオプションの MultiSubnetFailover=True パラメーターを接続文字列で使用している場合、IP アドレスを同時に試し、最初に応答したサーバーに接続します。 これにより、フェールオーバー発生時のクライアント回復待機時間を最小限に抑えることができます。 この省略可能なパラメーターは、次のデータ プロバイダーによってサポートされています。
MultiSubnetFailover=True の場合には DNS に登録されているすべての IP アドレスに対して同時に接続を試行し、応答があったサーバーに対して接続が行われます。
False (有効でない) 場合には DNS による名前解決に従いますので、DNS で解決された IP アドレスに対して接続を行い、タイムアウトした場合には、次に IP アドレスに対して接続をする形になります。
そのため、タイムアウトの設定によっては次の IP アドレスへの接続を行わずに接続を中止してしまうことがあります。
この動作が
レガシ クライアント ライブラリまたはサードパーティ データ プロバイダーでは、接続文字列に MultiSubnetFailover パラメーターを使用できません。 クライアント アプリケーションが SQL Server 2012 のマルチサブネット FCI と最適な状態で連携して動作するように、クライアント接続文字列の接続タイムアウトを追加の IP アドレスごとに 21 秒で調整を試みてください。 これにより、クライアントの再接続の試みは、マルチサブネット FCI のすべての IP アドレスへの切り替えができるまでタイムアウトしません。
SQL Server Management Studio および sqlcmd の既定のクライアント接続タイムアウト期間は 15 秒です。
として記載されている内容となります。
そのため、MultiSubnetFailover を接続文字として使用できない場合の対応としては、
- 接続時のタイムアウトを伸ばす
- RegisterAllProvidersIP を 0 に設定し、オンラインの IP アドレスのみを登録する
というような対応が必要となってきます。
通常、DNS は冗長化されていると思いますので、RegisterAllProvidersIP を 0 にした場合は最新の情報の使用を適切に行うため、TTL の設定を変更する必要が出てきます。
WSFC のネットワーク名では TTL の値 (HostRecordTTL) の値は1200 秒が設定されています。
この状態ですと一度接続が行われた環境では DNS を更新しても接続先が変わらない可能性がありますので、TTL を短くして、再接続のための更新間隔を調整する必要があります。
# AlwaysOn 可用性グループの前提条件、制限事項、および推奨事項 (SQL Server) によると 60 秒程度が推奨
マルチサブネットフェールオーバークラスターを使用する場合には、接続元のアプリケーションの接続要件を考慮したうえで、設計をしていくことが重要になってきそうですね。
# フェールオーバー後のアプリケーションの接続確認まで確認範囲に入れておけばこの辺はカバーできると思いますが。