はじめに
Azure Load Balancer Admin State とは
2024年11月07日、Azure Load Balancer の Admin State の機能が GA されました。
今回GAした Admin State の機能は、Azure Load Balancer のバックエンドプール内の一部の仮想マシンの正常性プローブの結果をオーバーライドする機能です。バックエンドプール毎に仮想マシン単位で設定でき、以下のように、正常性プローブを常に成功させることや、常に失敗させることで、新規接続の可否を調整することが可能です。
| 管理状態 | 動作 |
|---|---|
| Up | 新規接続させる (正常性プローブ 常に成功でオーバーライド) |
| Down | 新規接続させない（正常性プローブ 常に失敗でオーバーライド） |
| None | 従来通り 正常性プローブの結果に従う |
なお、Admin State は日本語では 管理状態 または 管理者の状態 と表記されています。
何がうれしいのか？
Admin State の機能を使うことで、メンテナンス対象の仮想マシンの正常性プローブを簡単に失敗させることができ、メンテナンス対象の仮想マシンへの新規接続を防ぐことができます。また、メンテナンス後の復旧も簡単に行うことができます。
これまで、バックエンドにある仮想マシンに対して更新プログラム適用などのメンテナンス作業を行いたい場合は、メンテナンス対象の仮想マシンへの新規接続がなされないように、バックエンドプールから一時的に仮想マシンを削除したり、NSG を構成して正常性プローブを失敗させたり、といった面倒な運用が必要でした。
Admin State の機能を使えば、こういった構成変更などが不要になり、制御が可能になります。
さっそく試してみます！
試してみる
Admin State でメンテナンス対象の仮想マシンへの新規接続を防ぐ (Downを設定)
Azure Portal から、Azure Load Balancer のバックエンドプールの設定画面を開きます。
Azure Load Balancer の [設定] - [バックエンドプール] を開くと、右端に [管理者の状態] という項目が追加されているはずです。
キャプチャ画像は、Admin State 機能が一般提供される前に作成しておいた Azure Load Balancer のバックエンドプールの設定画面です。[管理者の状態] は [なし(None)] になっています。
[なし(None)]] は、従来通り正常性プローブの結果に従う状態であり、Admin State の機能が無効になっている状態です。
この Azure Load Balancer の バックエンドプール には、仮想マシンが 2 台登録されており、helloworld + VM名 が表示される Web サイトを構成しています。Azure Load Balancer のフロントエンドにアクセスしてみると、きちんと分散されていることが確認できます。
さて、ここで VM-2 をメンテナンスしたい、という場合を想定して、Admin State の機能を使ってみます。
VM-2 の [管理者の状態] の [なし(None)] の部分をクリックし、開いた画面でプルダウンから [Down] を選択します。
VM-2 の [管理者の状態] が [下へ(Down)] になりました。
さて、VM-2 は [Down] が設定されているため、VM-2 の正常性プローブは常に失敗として扱われます。Azure Load Balancer は、正常性プローブが失敗している VM-2 に対しては新規接続を行わず、VM-1 にのみ新規接続をするようになります。ブラウザを更新してみると、VM-1 にのみ接続されることが確認できます。
正常性プローブの状態を確認してみます。たしかにオーバーライドされています。
これで、VM-2 に対する新規接続が行われないようになりました。メンテナンスが終わったら、[管理者の状態] を [なし(None)] に戻すことで、VM-2 に対する新規接続が再開されます。なお、設定の反映は非常に早く感じました（体感数秒）。
Admin State で正常性プローブの結果を常に成功させる (upを設定)
例えば、次のような port:65535 でのデタラメ正常性プローブを設定してみました。
仮想マシン側で何も待ち受けていないポートですし、NSG も空いていないので、成功しない正常性プローブです。
ですが、Admin State の機能を使って、VM-1 は [up(上へ)] に設定し、結果を常に成功にオーバーライドすることができます。
通常、正常性プローブが失敗しているバックエンドのインスタンスへは通信の振り分けがされませんが、オーバーライドしておいた VM-1 に対しては、新規接続が行われます。
公式ドキュメントでは、使いどころとしては、バックエンドインスタンスの状態が不安定な場合など不定期に正常性プローブが失敗してしまうような場合に、強制的に成功でオーバーライドさせることで安定化させるシナリオが挙げられていました。
ほかには例えば、なんらかのトラブルの際などバックエンドプールに対しての接続や正常性プローブが失敗している場合に、切り分けなどのために一時的に [up(上へ)] として状況を確認してみたり、構築作業時や検証時にカスタムの正常性プローブの用意などが間に合っていない場合などに利用したりなどでしょうか。
負荷分散規則が複数ある場合には？ - 全部に影響
1つのバックエンドプールに複数の負荷分散規則が紐づく場合に、バックエンドプールに Admin State を設定すると、全ての負荷分散規則に影響します。
例えば以下のように、 http の負荷分散規則と RDP の負荷分散規則を構成し、バックエンドプールに VM-1 と VM-2 があるとします。ここで、 VM-2 の Admin State を [down] に設定すると、http でも RDP でも VM-1 のみに接続が行われます。
バックエンドプールが複数ある場合には？ - 個別に設定可能
2つのバックエンドプールがある場合、 Admin State はバックエンドプール毎に独立です。
例えば以下のように、バックエンドプールを2つ用意すると、Admin State が、バックエンドプール毎に設定ができることを見て頂けるかと思います。
２つのバックエンドプールが同じ仮想マシン VM-1 と VM-2 で構成されているような状況であったとしても、Admin State は個別に設定できます。そのため、一方のバックエンドプールでは VM-1 のみを正常とし、もう一方のバックエンドプールでは VM-2 のみ正常、というような設定も可能です。
負荷分散規則それぞれに異なるバックエンドプールを構成できるので、
http の負荷分散規則 - AdminState により VM-1 のみ正常となっているバックエンドプール
RDP の負荷分散規則 - AdminState により VM-2 のみ正常となっているバックエンドプール
といった構成がとれます。
この場合アクセスすると、Web サイトは VM-1 に接続され、RDP での接続は VM-2 に接続されます。
今回例示したように、メンテナンス中でも RDP などのメンテナンス中も必要な接続だけは落とさないといったことや、一つの仮想マシンで複数のサービスが提供されているような場合にサービス毎に制御したりといったことができそうです。
まとめ
これまで NSG で正常性プローブを無効にするなどの手間をかけていたメンテナンス時の接続制御が、Azure Load Balancer の Admin State の機能を使うことで簡単に行えるようになりました！
設定も簡単で、反映も早いので、サクッとご利用ください！
おまけ
おまけ1: 全部 [down] にしたら
バックエンドプールのすべての仮想マシンを [down] にしてしまうと、新規接続が行われなくなります。
おまけ2: 既存接続に影響するか？
既存の TCP 接続には影響がありません。
RDP(TCP:3389) で接続をした状態で up/down/none の設定を変更しても、問題なく接続が維持されました。
ただし、UDP の場合には影響をうけ、正常性プローブが成功扱いとなっているバックエンドへの通信となります。
参考
Discussion