Multi-Subnet Clustering
Windows Server 2008でサポートされた複数のサブネットにあるクラスタノードで構成されたWSFCですが、SQL Server 2008 R2まではサポートされていませんでした。そのため災害対策のため異なるサイトに配置したコンピュータでフェールオーバークラスターを構成したい場合、VLANを構成するなどの必要がありました。
SQL Server 2012以降はクラスタノードが複数のサブネットに配置されているクラスターがサポートされます。ただし、SQL Server 2012 Enterprise Edition、Developer Editionまた評価版のエディションのみのサポートとなります。WindowsはWindows Server 2008 R2 Datacenter EditionとEnterprise Editionのみがサポートされ、Windows Server 2008はサポートされませんのでご注意ください。
Multi-subnet Clusteringではサブネットが異なるサイト間でストレージのコピーが必要となります。これは SQL Serverの機能としては提供されません。サードベンダーのSANストレージのリモートレプリケーションをサポートする製品が必要となります。
Multi-subnet Clusteringを構成するとノードが配置されているサブネットごとに1つのIPアドレスをSQL Serverの仮想サーバー名に割り当てます。仮想サーバー名とIPアドレスの依存関係はORに設定され、いずれかのIPアドレスがオンラインであれば仮想サーバーのリソースはオンラインになります。実際にはアクティブなノードが配置されているサブネットのIPアドレスリソースがオンラインになり、全てのIPアドレスが同時にオンラインになることはありません。
Multi-subnet Clusteringではフェールオーバーで異なるサブネットのノードがアクティブとなった場合、仮想サーバー名に対応するIPアドレスもアクティブとなったサブネットのIPアドレスがオンラインとなります。仮想サーバー名がオンラインになるとDNSに登録されている情報は更新され、仮想サーバー名に対応するIPアドレスは新しいサブネットのIPアドレスとなります。しかし、クライアントにはDNSキャッシュがありますので、その後クライアントがSQL Serverへアクセスする場合、キャッシュが無効になるまではフォールオーバー前のIPアドレスへの接続を試み、接続に失敗します。
クライアントがフェールオーバー後のSQL Serverに接続できない期間を短くするためには、仮想サーバー名のリソースプロパティHostRecordTTLを変更します。HostRecordTTLはクライアントでDNSのキャッシュが保持される期間です。デフォルトでは 1200秒（20 分）です。 推奨される値は60秒ですが、短くすることはクライアントからDNSサーバーへの問い合わせを増加させることになります。SQL Serverへアクセスするクライアントが多い場合はネットワークへの負荷を検討してください。
