以前投稿した 複数サブネット構成を使用した SQL Server on Azure VM の可用性構成について に近いものとなりますが、改めて特徴を把握しておきたいと思います。
2023/1 時点で作成可能な可用性グループリスナー
可用性グループリスナーの種類
現在の Azure では複数サブネット (マルチサブネット) の構成をとった仮想マシンを使用することで、Azure ロードバランサーを使用することなく、可用性グループのリスナーを使用したアクセスが可能な環境を構築することができるようになりました。
これにより、現在 Azure では次のパターンで可用性グループを構築することができます。
- 単一サブネット
- 複数サブネット
- ロードバランサーを使用しない構成: マルチサブネットリスナー
この中で、今後使用するケースが多いのは次の 2 種類となるのではないでしょうか。
DNN リスナー については、AG と DNN リスナーとの機能の相互運用性 に記載されているような機能制限があり構成についても少しトリッキーな構成となっていると感じています。
ロードバランサーを使用しない構成をとりたいのであれば、今後は マルチサブネットリスナー になると思いますので、DNN リスナーを Always On 可用性グループの候補に入れることはないと考えています。 (DNN のテクノロジー自体は使用する箇所があるので機能としては覚えておく必要があります)
サポートする OS と SQL Server のバージョン
どのバージョンであれば、どの構成が使用できるかについては、Azure VM 上の SQL Server の Always On 可用性グループ の デプロイ オプション に記載されています。
DNN リスナーについては、前提条件 / 接続性 に記載されているバージョンの SQL Server であり、Windows Server 2016 以降である必要がありましたが、それ以外のリスナーについては制限はないため、柔軟な構成をとることができます。
構成の特徴
VNN リスナーとマルチサブネットリスナーの特徴としては次のようになるのではないでしょうか。メリット / デメリットに記載している内容もありますので本節では簡単に記載しておきます。
詳細についてはメリット / デメリットの内容でまとめています。
VNN リスナー
最大の特徴は「ロードバランサー」を経由して可用性グループのリスナーにアクセスをするという点です。
ロードバランサー経由でアクセスができるので、該当のロードバランサーの IP or ロードバランサーの IP を登録した DNS レコードでアクセスができ、接続に関しての考慮事項はほぼないのではないでしょうか。
ただし、可用性グループ内のどのサーバーに接続をするかに関しては、ロードバランサーの正常性プローブの仕組みを使用して実現をしているため、SQL Server としてフェールオーバーがされた後に、正常性プローブによる死活監視による切り替えが完了して初めて接続が可能となります。
そのため、障害発生時の切り替えについてはマルチサブネットリスナーと比較して、時間がかかることになります。
メリット / デメリットには記載しませんでしたら、ロードバランサーのコストもかかりますので VNN リスナーのほうがロードバランサー分コストが上がるということもあるかもしれませんね。
特徴をまとめると次のようになります。
- ロードバランサーを経由して可用性グループにアクセスする
- ロードバランサーのコストが発生する
- 障害発生時の切り替えには SQL Server のフェールオーバーだけでなく、正常性プローブの動作も影響
- ロードバランサーの IP 経由でアクセスできるため接続方法はシンプル
- OS レイヤーでは可用性グループリスナーの IP アドレスの設定 (ロードバランサーの IP を指定) する必要があるが、Azure のリソースのレイヤーでは明示的に設定する必要はない (これは後述)
マルチサブネットリスナー
最大の特徴は「ロードバランサーを使用せず」可用性グループのリスナーにアクセスをするという点です。
ロードバランサーは使用していないため、フェールオーバーについては、VNN リスナーと異なり正常性プローブについては考慮する必要はなく、SQL Server のフェールオーバーが完了すれば、可用性グループに対してアクセスが可能となり、障害発生時の切り替えの速度はこちらのほうが早いです。
VNN リスナーの場合は、Azure の VM のリソースとしての IP アドレスは 1 つ (OS レイヤーで見た場合は可用性グループの IP が付与されますが、Azure のリソースのレイヤーで見た場合は VM 自身の IP アドレス1つとなります) です。
しかし、マルチサブネットリスナーの場合は、リスナーに使用する IP アドレスは明示的に VM のリソースとして付与する (Azure の VM のリソースの NIC の IP としてポータル or REST 等で明示的に付与) 必要があり、この辺も特徴的なものです。
これについては Azure のリソースの構成の話なので、特に問題になることはないかと。
マルチサブネットリスナーは接続方法としては「DNS による名前解決」を基本としているところがあり、リスナーで必要となる A レコードを DNS で解決できる必要があります。これは DNS レベルとデータアクセスプロバイダーレベルの 2 種類の観点があり、以下がポイントとなります。
- DNS でリスナー名を解決できる必要がある
- リスナー名による名前解決を実施すると、各サブネット用の IP の複数レコードが応答される
- リスナー名で複数レコードの応答があった場合のアクセス方法をデータアクセスプロバイダーが対応できる (MultiSubnetFailover をサポートしている)
IP アドレスベースでも接続はできるのですが、「データベースミラーリング接続文字列」を使用する必要があり、2 ノードの可用性グループでないと対応はできません。 (3 ノードの可用性グループでミラーリング接続文字列による接続を試みるとエラーとなります)
特徴をまとめると次のようになります。
- ロードバランサーを使用せずに可用性グループにアクセスする
- フェイルオーバー時に正常性プローブの考慮が不要となる
- MultiSubnetFailover の仕組みを使用して可用性グループにアクセスする
- OS レイヤー / Azure のリソースのレイヤーともに、リスナーで使用する IP を明示的に指定する
- DNS による リスナー名の名前解決 + MultiSubnetFailover のオプションをサポートするデータアクセスプロバイダーによるアクセス
- IP アドレスによるアクセスを使用する場合は、データベースミラーリングの接続文字列を利用し、2 ノードの可用性グループのみサポート
DNN リスナー
マルチサブネットリスナーの登場により、Always On 可用性グループのリスナーに DNN リスナーを使用することはなくなったと考えていますが、AlwaysOn 可用性グループで DNN リスナーで使用されている DNN (Distributed Network Name) のテクノロジを使用してもよさそうな箇所が 1 箇所あり、それが「クラスター名オブジェクト (CNO)」です。
Windows 版の Always On 可用性グループは、WSFC (Windows Server Failover Clustering) のテクノロジが使用されており、クラスター名のクラスターリソースの作成については考慮しておく必要があります。
Azure 上で WSFC を構成した場合、Windows Server 2016 以降で利用できるようになった DNN の情報について に記載したように、DNN をベースとしてコンピューター名のオブジェクトが作成されます。
DNN コンピューター名のオブジェクトを作成した場合、クラスターの IP アドレスは不要でリソースを作成することができます。
WSFC の CNO はリモートでアクセスする必要がほとんどないものとなりますので、CNO については DNN で作成してもよいのではと思っています。
これについては、フェールオーバー クラスターの IP アドレスを設定する にも記載されている次の記載となります。
注意
Windows Server 2019 では、クラスター ネットワーク名の代わりに分散サーバー名がクラスターによって作成されます。また、クラスターの全ノードの IP アドレスにクラスター名オブジェクト (CNO) が自動的に登録されるので、Windows クラスター専用 IP アドレスは必要ありません。 Windows Server 2019 をご使用の場合は、このセクション、そしてクラスター コア リソースに触れるその他の手順をスキップするか、または PowerShell を使用して仮想ネットワーク名 (VNN) ベースのクラスターを作成してください。 詳細については、「フェールオーバー クラスター: クラスター ネットワーク オブジェクト」のブログを参照してください。
余談ですが、Always On 可用性グループは DNN をサポートしていますが、FCI (Failover Clustering Instance) ではサポートされていません。
マルチサブネットリスナーにすることによるメリット / デメリット
従来から使用できていたロードバランサーを使用した VNN リスナーと比較したマルチサブネットリスナーのメリット / デメリットについても考えてみたいと思います。
メリットデメリットと合わせて HADR 構成のベスト プラクティス (Azure VM 上の SQL Server) も確認しておくとよいかと。
メリット
マルチサブネットリスナーのメリットとしては、
- ロードバランサーが不要
というのが一番のメリットとなるかと思います。
これにより次のようなメリットも現れてきます。
- 障害発生時に切り替え速度の向上
- インターネット接続が必要な場合の構成の簡略化
障害発生時の切り替え速度の向上
使用するリソースが少なければシンプルな構成となり、シンプルな構成であるほど障害ポイントが減ります。
ロードバランサーが不要になったことによるメリットとしては、シンプルな構成となるほかに次のようなものもあるのではないでしょうか。
VNN リスナーはロードバランサーが必要となります。
ロードバランサーから可用性グループ内のプライマリサーバーへのアクセスについては、正常性プローブ により実現されており、サーバーの切り替えが発生した場合には正常性プローブの間隔で切り替えが行われます。
- Always On 可用性グループとしてのフェールオーバー
- Azure ロードバランサーとしての正常性プローブによるフェールオーバー
ロードバランサーを使用した構成では、プライマリとセカンダリのフェールオーバーが発生する場合には、この二つの時間が切り替えにかかる時間となりますが、ロードバランサーを使用しなくなることで、フェールオーバーに必要となる時間が
- Always On 可用性グループとしてのフェールオーバー
のみとなります。
インターネット接続が必要な構成の簡略化
ロードバランサーとして「内部ロードバランサー」を使用した場合は、送信専用のロード バランサーの構成 についても考慮をする必要があります。
これは、Azure ロードバランサー利用時の注意点 / インターネットとの通信 で解説されていますが、内部ロードバランサーを使用した場合、バックエンドプールに設定した VM からインターネットへの通信ができなくなる可能性があります。
Windows Update 等でインターネットに接続する必要がある場合には、
- VM にパブリック IP を付与
- パブリックロードバランサーのバックエンドプールとしても合わせて追加する
- プロキシサーバーを追加する etc
等の対応が必要となりますが、ロードバランサーを使用しない構成であれば、インターネット接続についてはデフォルトの設定で実現することができますので、外部接続についての考慮が不要となります。
デメリット
マルチサブネットリスナーと VNN リスナーを比較した場合、メリットだけでなくデメリットとなる可能性のあるポイントもあります。
- 必要となる IP アドレスが増える
- DNS ベースのリスナー名の解決を前提として考える必要がある
ということが大きな内容となるのではと考えています。
必要となる IP アドレスが増える
VNN リスナーの場合は、IP アドレスとしては、「ロードバランサーに設定する IP アドレス = 可用性グループリスナーで使用する IP アドレス」が追加で必要となります。
マルチサブネットリスナーを使用する場合、
- リスナーごとに各 VM に IP アドレスを追加する
必要があり、「リスナー×可用性グループのサーバー」の IP アドレスが追加で必要となります。
DNS ベースのリスナー名の解決を前提として考える必要がある
VNN リスナーの場合、ロードバランサーの IP アドレスに接続ができればよいため、リスナーを DNS で解決できなくても接続を行うことができます。
しかしマルチサブネットリスナーの場合は、DNS での名前解決を基本に考える必要があります。
VNN リスナーの場合は、どのサーバーがプライマリになっていても接続に使用する IP アドレスは同一です。しかし、マルチサブネットリスナーの場合は、プライマリサーバーによってリスナーの IP アドレスが変わります。
マルチサブネットリスナーは、SQL Server マルチサブネット クラスタリング と似たような考えをする必要があります。
マルチサブネットリスナーのクラスターリソースの CAP (クライアントアクセスポイント) は次のような構成となります。
一つのリスナー名に対して、各サーバーのサブネットの IP アドレスが関連づいた形となります。DNS についても次のように登録されます。
一つのリスナー名に対して複数の IP アドレスが A レコードとして登録されます。
これでオンラインとなっている IP アドレスに接続ができる理由は、クライアントのデータアクセスプロバイダーの実装によります。基本的な考えとしては MultiSubnetFailover を使用した接続 / 接続性 / AlwaysOn に対する MultiSubnetFailover の接続動作の向上 / 高可用性障害復旧のための SqlClient サポート になります。
データアクセスプロバイダーで MultiSubnetFailover の機能が実装されている場合、リスナー名で複数の IP アドレスが DNS に登録されている場合、接続時には次のようなパケットが送信されます。
DNS に登録されている IP アドレスすべてに対してパケットを送信し、応答があったサーバーに対して接続を行うという方式が取られます。
このような接続を行うためには可用性グループのリスナーを DNS で解決できる必要があり、SQL Server に対しての名前解決に任意の A レコードを設定できる DNS が使用できる環境から接続ができるようにする必要があります。
任意の DNS を設定できず、IP アドレスベースで接続ができる場合の回避策としては、データベースミラーリングの接続文字列 (FailoverPartner) を使用するという方法があります。
「Server=<Server #1 のリスナー用 IP>;Failover Partner=<Server #2 のリスナー用 IP>」というような接続文字列を使用することで、マルチサブネットリスナーに対して IP アドレスで接続を行うこともできます。
ただし、可用性グループとしては、接続 に記載されている次の制約があります。
- 1 つのプライマリ レプリカと 1 つのセカンダリ レプリカがある。
- セカンダリ レプリカが読み取り不可として構成されている ( [読み取り可能なセカンダリ] オプションが [いいえ] に設定されている)。
可用性グループが 3 ノードで構成されているグループに対して、ミラーリング用の接続文字列を使用して接続を行うと「Server xxxxxx, database xxxx is not configured for database mirroring.」というようなエラーとなり接続を行うことができません。
IP アドレスでリスナーに接続する必要がある場合は「データベースミラーリング用の接続文字列」を使用する必要がありますが「可用性グループ内のサーバーは 2 台まで」という制約がつくことを意識しておく必要があります。
IP アドレスでリスナーに接続する必要があるのは、
- DNS による名前解決ができない
- MultiSubnetFailover の接続文字列のオプションをサポートしていない
ケースになると思いますが、このような場合は接続方法については注意しておく必要があるのではないでしょうか。
まとめ
マルチサブネットリスナーはロードバランサーが不要となりシンプルな構成で可用性グループを構築することができ、フェールオーバー時の即応性が向上します。
しかし、どのような特徴があるかを把握することは重要であり、DNS によるリスナーの解決 / MultiSubnetFailover 相当の接続ができるかは、使用するかどうかを重要なポイントとなるのではないでしょうか。
これが満たせない場合、ロードバランサーを使用した VNN リスナーを使用する必要があるため、アプリケーションからの接続も考慮し、どのリスナーを使用するかを判断する必要があるのではないでしょうか。