発表されてからかなり日が経っているのですが、Azure VM で SQL Server の可用性構成を構築する場合に、複数サブネット (マルチサブネット) 構成を使用することで、従来の構成と比較して構成の簡略化が行うことができるようになっています。
アナウンスとしては次の内容となり、
- SQL Server on Azure Virtual Machines: Multi subnet high availability generally available
- Simplify Azure SQL Virtual Machines HA and DR configuration by adopting multi subnet approach
技術情報としては次の内容となります。
基本構成としては下図のようになり、複数のサブネットに VM を配置し、ロードバランサーは不要で、可用性グループにアクセスを行うことができる構成を Azure 上に展開することができます。
FCI についても、複数サブネットを使用して同様の構成を行うことができ、単体のチュートリアルは提供されていないのですが、https://docs.microsoft.com/en-us/azure/azure-sql/virtual-machines/windows/failover-cluster-instance-prepare-vm?view=azuresql&tabs=multi-subnet#subnets で情報が公開されています。
本投稿ではこの複数サブネット構成について触れたいと思います。
なお、今回の投稿のメインとなる内容は Windows の SQL Server を使用した Always On 可用性グループについてとなります。
Contents
SQL Server on Azure VM のクラスター構成
現在の SQL Server では、可用性環境を構築する際の選択肢は次の 2 種類となります。
- Failover Cluster Instance (FCI)
- Always On 可用性グループ (AG)
これらの可用性環境を構築する際に、基盤となる技術としては Windows Server Failover Cluster (WSFC) が使用されており、Windows クラスターの機能を活用して実装されることになります。(昨今の SQL Server では、クラスターレス可用性グループが組めたりもしますが、それは別の話ということで)
WSFC 上で構築されているリソース (サービス) にアクセスをする際には「クライアントアクセスポイント」(CAP) という
- コンピューター名 (ネットワーク名)
- IP アドレス
を持つ、クラスター内のリソースが必要となり、これがクラスターリソースにアクセスするための仮想 IP アドレス / エンドポイントとなり、クライアントアクセスポイントのリソースが、WSFC を構成するノードの特定のノードでのみオンラインとなることで、フェールオーバー後も単一のアクセスポイントでアクセスを可能としています。
従来までは、Azure 上で、クライアントアクセスポイントを作成する際には次の 2 種類を利用することができました。
- 仮想ネットワーク名 (Virtual Network Name : VNN)
- 分散ネットワーク名 (Distribued Network Name : DNN)
今回、これらの構成に「複数サブネット構成」という選択肢が新たに追加されました。
この構成の特徴としては冒頭で紹介したアナウンスで次のようにまとめられています。
複数サブネット構成 (SQL VMs in separate subnets) は、今後推奨される展開モデルとなり、HADR configuration best practices (SQL Server on Azure VMs) でも推奨構成となってます。
複数サブネット構成は、従来の構成と比較して、次のようなメリットがあります。
- 構成が容易
- 機能制限がない
- フェールオーバー時の即応性
複数サブネット構成に入る前に、VNN / DNN の特徴も改めて確認しておきたいと思います。
仮想ネットワーク名 : VNN
VNN は Azure 上で、Always On 可用性グループがサポートされた当初から使用されていたものとなり、Azure で VNN を利用する際には、次のような構成の特徴がありました。
- Azure ロードバランサーを使用する
- リスナーの IP アドレスをロードバランサーの IP と同一にする
- WSFC のコアクラスターリソースのクラスター名オブジェクト (CNO) IP については、APIPA address (169.254.1.1) を使用するか、IP を設定しない
- プローブポート (一般例としては 59999) を使用して、クラスターリソースをホストしているノードを特定
- WSFC の IP アドレスリソースに、プローブポートの設定を行い、IP アドレスをロードバランサーの IP と同一にする
構成を実施する際には、VM 内の操作と、Azure 上のリソース (ロードバランサー) の操作を行う必要があり、複数のリソースの設定を強調させる必要がありました。
また、VNN 経由で高可用性の SQL Server にアクセスするには、Azure ロードバランサーが必要となり、障害検知後の切り替えについては、ロードバランサーのプローブの設定に依存していました。
WSFC 側でリソースの切り替えが完了していてもロードバランサーのプローブの設定による死活監視によるルーティングの切り替えが完了しないと、フェールオーバー後のノードにトラフィックが流れないため、障害発生時の切り替えに多少の時間を要していました。(これが Failover Latency=Yes となっている理由となるのではないでしょうか)
VNN は、IP アドレスのリソースに対して、プローブポートの設定を行う必要があり、Azure ロードバランサーの利用が必要となりますが、それ以外は特殊な設定は OS 側には必要ないため、昨今使用する SQL Server であれば、バージョンに依存せずに使用することができる、設定には少し手間はかかりますが、汎用的に利用できる仮想 IP の構成方法となっていました。
分散ネットワーク名 : DNN
DNN の Windows Server 2016 で追加された機能となりますが、SQL Server サポートは途中から追加されたものとなっており、特定のバージョン以降 (SQL Server 2016 SP3 / SQL Server 2017 CU25 / SQL Server 2019 CU8) の SQL Server を使用することが前提となります。
DNN は、VNN と異なり、Azure ロードバランサーを使用することなく、SQL Server にアクセスするためのエンドポイントを構成することができました。ロードバランサーが不要になることで、プローブポートによる死活監視が不要となり、WSFC のリソースのフェイルオーバーが完了すれば、切り替えが完了するため、フェールオーバー時の即応性が向上しました。
DNN でロードバランサーが不要となる一因としては、エンドポイントの解決として、DNS に各ノードの IP を登録し、マルチサブネットクラスタリングのような形で、名前解決を行うというような動作が行われています。(エンドポイントとなるコンピューター名の A レコードには、WSFC のノードのプライマリ IP でレコードを作成するため、後述のローカルのポート以外を作成するにつながります)
設定はシンプルで、フェールオーバー時の即応性が向上しますが、DNN にはいくつかの機能制限がありました。
- Configure a DNN listener for an availability group
- Feature interoperability with AG and DNN listener
- Configure a DNN for failover cluster instance
- Feature interoperability with SQL Server FCI & DNN
可用性グループで利用した場合には、次のような機能制限がありました。
- 分散型可用性グループがサポートされていない
- 可用性グループで使用するポートは、ローカルの SQL Server のポート (TCP 1433) は利用できない
- TCP 1433 以外で可用性グループリスナーのポートを指定する必要があり、接続文字列のサーバーの指定にはポート番号が必要
また、DNN を利用した可用性グループリスナーは GUI では実施することができないため、可用性グループリスナーは PowerShell で作成する必要がありました。
DNN はロードバランサーを使用しなくてもエンドポイントが作成できますが、いくつかの制約があり、VNN と同様の利用方法ができないという制約がありました。
複数サブネット構成によるエンドポイントの作成
今回アナウンスされた複数サブネット構成によるエンドポイントの作成は、以下の問題点を改善したものとなります。
- VNN で必要だった Azure ロードバランサーの廃止
- DNN の機能制限と TCP 1433 が使用できない問題の改善
- 使用している SQL Server のバージョンに依存しない (DNN 対応前のバージョンでも使用できる)
DNN と同様に Azure ロードバランサーは不要となり、DNN では制限のあった項目を改善しています。
実際には VNN と DNN が混在しているような構成となっているようなので、構成のポイントをまとめておきたいと思います。
基本的には、次のドキュメントを読んでおけば問題ないはずです。
- Tutorial: Prerequisites for availability groups in multiple subnets (SQL Server on Azure VMs)
- Tutorial: Configure an availability group in multiple subnets (SQL Server on Azure VMs)
クラスター名オブジェクト : CNO の構成
CNO についてですが、DNN を使用して作成が行われます。
DNN の場合は、CNO には IP アドレスリソースは作成されません。
DNN を使用した場合、該当のコンピューター名の A レコードについては、クラスターの各ノードの IP が登録されますので、DNS に登録される内容は次のようになります。
CNO については、フェールオーバークラスターマネージャーでしか接続しないのでこのような登録になっていても問題はないかと思います。
可用性グループリスナー : CAP の構成
複数サブネット構成の可用性グループリスナーはマルチサブネットフェイルオーバークラスターのように、CAP は 複数 IP アドレスを持つ CAP の構成となります。
可用性グループリスナーに指定する IP アドレスは、各ノードのセカンダリ IP アドレスを指定することになり、手順については Add secondary IPs to SQL Server VMs に記載されています。
リスナーの作成は DNN とは異なり、SSMS の可用性グループ作成のウィザードから実行することができます。
リスナーで使用する IP アドレスは、Azure の VM の NIC のリソースに割り当てたセカンダリの IP アドレスを指定します。(NIC のリソースのセカンダリにリスナーで使用する IP を割り当てないと、リスナーを作成できても通信を行うことはできません)
クラスターのリソースとしては、次のように CAP の IP アドレスが OR で設定された状態となります。
DNS には、次のように CAP のコンピューター名 (リスナー名) の A レコードはリスナーに指定したセカンダリの IP アドレスで設定が行われます。
CrossSubnet の設定
本構成は複数サブネットの構成となるため、WSFC のハートビートの設定は「CrossSubnetDelay」「CrossSubnetThreshold」が使用されることになるかと。
ハートビートの設定については、次のドキュメントで触れられています。
- HADR configuration best practices (SQL Server on Azure VMs)
- SQL Server による IaaS – フェールオーバー クラスター ネットワークのしきい値の調整
- クラスターと Always On のタイムアウト値の更新
- Heartbeat and threshold
Market Place の Windows Server 2022 + SQL Server 2019 のイメージで構築をした場合、次のような設定が初期値となっているかと思います。
推奨値は Heartbeat and threshold に記載されている次の設定となります。
初期値は推奨値になっていないので、上記のドキュメントに記載されているコマンドを実行して閾値を変更しておくとよいかと。
(get-cluster).SameSubnetThreshold = 40 (get-cluster).CrossSubnetThreshold = 40
接続時に MultiSubnetFailover を指定
複数サブネット攻勢では、リスナーの A レコードに複数の IP アドレスが登録された状態となります。DNS ラウンドロビンのようなレコード構成になっている場合、正しい IP アドレス (プライマリ) に接続されない可能性があり、このような状態を回避するための方法として MultiSubnetFailover を使用した接続 があります。
接続文字列に「MultiSubnetFailover=True」を指定するものとなり、Test listener connection で触れられています。
.NET ベースの環境であれば、.NET Framework 4.6.1 以降であれば AlwaysOn に対する MultiSubnetFailover の接続動作の向上 が含まれているため、明示的な指定を行わなくてもよいかもしれませんが、.NET 以外を使用する場合には、この接続のオプションを覚えておくとよいかと思います。
「MultiSubnetFailover=True」相当の動作を行う場合、可用性グループのリスナーに複数の IP アドレスが登録されている場合は、次のような動作となります。
リスナー名で名前解決をし、取得された IP アドレスすべてに対して、TCP 1433 での接続を試みます。これで応答のあった IP に対して接続を行うという方式となります。
まとめ
複数サブネット構成を使用した環境では、従来から提供されている VNN と DNN の良いところを組み合わせた構成を使用することができます。
エンドポイントの解決には、DNS が使用されているため、接続するアプリケーションが参照する DNS は、エンドポイントに対して複数の IP アドレスが登録されている状態のものを使用する必要がありますが (このような DNS が実現できない場合は VNN にする必要があるかもしれません)、接続元が使用する DNS の登録内容を制御できる環境なのであれば、複数サブネット構成は、構築作業がシンプルですので、使い勝手が良いのではないでしょうか。