この記事は、2016 年 8 月 31 日 に Data Platform Tech Sales Team Blog にて公開された内容です。
Microsoft Japan Data Platform Tech Sales Team
オンプレ環境において AlwaysOn Availability Group(以後、AGと称す) 構成を幾度となく構築した経験のある人でも、Azure 上で AlwaysOn AG を構築する際についつい躓いてしまうポイントがあります。それはリスナー構成です。今回はそのリスナーを構成する際に Azure ではオンプレ時とは少し違った考え方をしなければならないポイントをお伝えします。
まずは、オンプレ環境にて AlwaysOn AG を構築する際のリスナーについてですが、あまり意識していない方もいらしゃるかと思いますが WSFC(Windows Server Failover Cluster) のクラスターリソースの一つであるクライアントアクセスポイントとして登録されます。具体的にはそのクライアントアクセスポイントの IP が AG ノードの NIC に仮想 IP として割り当てられ、プライマリレプリカとなる AG ノードでその IP が Up されることにより、DB クライアントはリスナーを指定して接続すると常にプライマリレプリカに接続できるようになっています。
[フェールオーバー クラスター マネージャー にて]
[プライマリレプリカノードにて]
この時点ではセカンダリレプリカノードではクライアントアクセスポイントの IP (上記の場合には 10.0.0.20 )は Up していませんが、フェールオーバーするとセカンダリレプリカノードがプライマリに昇格し、クライアントアクセスポイントの IP が Up されます。クラスターリソースであるクライアントアクセスポイントがフェールオーバー先のノード(プライマリに昇格したノード)に移動するためです。
オンプレ環境では上記を理解しておけばよかったのですが、Azure ではさらに理解しておくべきポイントがあります。というのは、この仮想 IP はあくまでもノード側(正確に言うと WSFC )で割り当てた IP となり、Azure ネットワークではその IP を認識していないため、このままではその IP に対してパケットを送信したりはできません。そこで、この仮想 IP を DB クライアントからアクセスできるようにするために登場するのが Azure Load Balancer です。
こちらのドキュメントを参考に設定していただくと Azure 上にて AlwaysOn AG のリスナーを構成することは可能ですが、作業の各ステップの意味をより理解していただくには、先ずは以下のような全体イメージを持っていただくのがよいかと思います。
ここで、重要になるのは以下三点となります。
- WSFC のクラスターリソースであるクライアントアクセスポイント(AlwaysOn AG ではリスナー)の IP は Azure ネットワークでは通信に使用できないため、DB クライアントからアクセス可能にするためにその IP を Load Balancer に持たせる
- Load Balancer が バックエンドの AG ノード内のどのノードでリスナーが起動しているかを確認するためにプローブを使用する
- プローブがどのノードでリスナーが起動しているか確認できるように、クライアントアクセスポイント側にプローブ用のポートを設定する
上記三点を意識しながら設定することにより、Azure 上にて AlwaysOn AG のリスナーを構成することができますが、更にもう一点新しいことを理解しておくことがあります。それは手順内で出てくる Direct Return Server についてです。別の呼び方で Direct Routing などとも呼ばれています。
これまでの Load Balancer は以下のようにクライアントとサーバーの間に配置して送受信のパケットの中継を担っていることが多かったかと思います。ただ、クライアントからサーバーへのパケットに比べると、サーバーからクライアントへのパケットのサイズはかなり大きいという傾向があるために、サーバーからクライアントへのパケットは Load Balancer を介さずに直接返した方が Load Balancer がボトルネックになりにくいというメリットがあります。そこで登場したのが Direct Server Return です。Azure Load Balancer は Direct Server Return に対応しており、AlwaysOn AG のリスナー構成でも使用します。
Direct Server Return 方式での Load Balancer の動きは、クライアントからの 仮想 IP 宛のパケットを受け取った後に、送信元 IP 、宛先 IP は変更しないまま、宛先 MAC だけを変更して実際のサーバーにパケットを送信します。そして、パケットを受け取ったサーバーは送信元 IP に直接応答します。この際、あくまでもクライアントは仮想 IP に対してパケットを送信しているため、サーバーからの応答パケットの送信元 IP も仮想 IP である必要があります。そのため、サーバー側ではループバック用に 仮想 IP を登録しておく必要があります。Azure 上で AlwaysOn AG のリスナーを構成する際に、WSFC 側でクライアントアクセスポイントの IP は直接通信には使用できないとしながらも、IP を設定しているのはループバックとして必要だからです。
上記を意識してこちらの作業を実施しますと Azure 上で AlwaysOn AG のリスナーは構成されますが、もしうまく繋がらないとなった場合には設定を見直す必要があります。例えば WSFC 側のプローブの設定値が正しいかは以下コマンドで確認できます。
また設定値は正しいとして、プローブが正常に動いているかを確認するためには AG のプライマリレプリカとなるノードにて Network Monitor などでパケットをキャプチャーし、Load Balancer のプローブが指定されたポート(ここでは 59999 を指定)に対しポートの確認を実施しているかをチェックします。
(赤枠部分を見ると、プライマリレプリカのノードのポート:59999 に対してSYN,SYN ACK,ACKのスリーウェイハンドシェイクが成功していることが分かります)
逆に AG のセカンダリレプリカとなるノードではクライアントアクセスポイントは起動していないため、プローブが指定されたポート(ここでは 59999 を指定)に対してリッスンしているかの確認パケットを送信してもスリーウェイハンドシェイクは成功しません。
以上により、Azure Load Balancer はクライアントアクセスポイント( AG でいうところのリスナー)が起動しているノード(プライマリレプリカノード)を把握し、クライアントからのパケットをそのノードに転送します。
上記の全体イメージを頭の中に持っていると、なぜ Azure 上ではオンプレ環境と比べると一工夫が必要なのか、そのためにはどういった構成にすべきかがご理解いただけるのではないかと思います。
因みにですが、AlwaysOn AG 構成方法自体は本投稿では触れませんでしたが、手動で構成する際にはこちらをご参考に構成いただくことが可能です。また、構成を理解する上では手動で構築いただくのがよいかと思いますが、自動で構成いただくためのテンプレートもご用意しており、そちらの構築手順はこちらをご参照ください。
以上、今回は Azure 上に AlwaysOn AG 構成を構築する際のリスナーというピンポイントなネタではありますが、皆さまが躓きそうなポイントをご紹介させていただきました。