Azure 仮想マシンスケールセット正常性監視と自動インスタンス修復

Azure 正常性監視はhttp, http, tcpのいずれかを用いて仮想マシンスケールセット内のアプリケーションが正常かどうかを判定する機能です。この機能は「ローリングアップデート」や「自動修復機能」と組み合わせる事ができます。もし、正常性がNGと判定されれば、その仮想マシンを削除し、新たな仮想マシンを自動的にデプロイします。

ローリングアップデートとの併用方法は「Azure 仮想マシンスケールセットローリングアップデート」を参照ください。

関連記事 : Azure コンピュート : 仮想マシン

関連記事 : Azure コンピュート : 仮想マシンスケールセット

前提
1. 公式ドキュメント
2. 事前設定
正常性拡張機能
自動修復ポリシー
1. 自動修復の設定
2. 自動修復の動作確認
補足
1. 拡張機能

前提

公式ドキュメント

参考になる公式ドキュメントを以下に示します。

事前設定

以下、リソースグループを作成します。

az group create --name MyResourceGroup --location japaneast

仮想マシンスケールセットを作成します。仮想マシンはnginxインストール済の状態とします。

az vmss create \
  --resource-group MyResourceGroup \
  --name MyScaleSet01 \
  --image UbuntuLTS \
  --vm-sku Standard_B1s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/authorized_keys \
  --custom-data /dev/stdin << EOF
#!/bin/bash
apt install -y nginx
echo "this is ${HOSTNAME}" > /var/www/html/index.html
EOF

正常性拡張機能

仮想マシンスケールセットの正常性監視は「仮想マシンの拡張機能」のひとつとして提供されています。拡張機能の説明は公式ドキュメントの「Azure 仮想マシンの拡張機能とその機能」に説明を委ねます。

それでは正常性拡張機能を「仮想マシンスケールセット」に対して設定します。設定例は以下の通りです。引数settingsにはJSON形式で監視方法を指定してください。protocolはhttps, http, tcpの3通りを選ぶ事ができます。https, httpは応答有無ではなく、200番応答を返した場合のみ正常と判定されます。

az vmss extension set \
  --name ApplicationHealthLinux \
  --publisher Microsoft.ManagedServices \
  --version 1.0 \
  --resource-group MyResourceGroup \
  --vmss-name MyScaleSet01 \
  --settings /dev/stdin << EOF
{
  "protocol": "http",
  "port": 80,
  "requestPath": "/index.html"
}
EOF

仮想マシンへの拡張機能インストール

前述の操作は「仮想マシンスケールセットに対する拡張機能の設定」だけで、仮想マシンには拡張機能はインストールされていません。まずは、この状態を確認しましょう。仮想マシンスケールセットの「インスタンス」画面を見ると、「正常性の状態」は空欄で、「最新のモデル」は「いいえ」と表示されています。

デフォルト設定のアップグレードポリシーは「手動」ですので、仮想マシンスケールセットに対する設定変更は仮想マシンに自動的に反映されません。設定を反映させるために、仮想マシン名(MyScaleSet01_0)を押下して、仮想マシンの設定画面へ遷移します。

「アップグレード」を押下すると、仮想マシンが最新化されます。すなわち、拡張機能がインストールされます。

「正常性の状態」が「健全」に変わり、「最新のモデル」が「はい」に変わった事が分かります。

同様の操作を繰り返し、全ての仮想マシンに拡張機能をインストールします。なお、これをCLIで操作する場合は、以下のようになります。

az vmss update-instances \
  --resource-group <リソースグループ名> \
  --name <仮想マシンスケールセット名> \
  --instance-ids <インスタンスID(複数指定可)>

やや乱暴な操作ですが、instance-idsに「*」を指定すると、全ての仮想マシンを同時に最新化する事もできます。

az vmss update-instances \
  --resource-group <リソースグループ名> \
  --name <仮想マシンスケールセット名> \
  --instance-ids '*'

状態確認

以上の操作後、全ての仮想マシンの「正常性の状態」が「健全」になる事を確認します。

自動修復ポリシー

自動修復の設定

正常性拡張機能による監視をする場合は、正常性NGとなる仮想マシンを削除し再デプロイする事もできます。この設定は「自動修復ポリシー」と呼びます。

自動修復ポリシーはenable-automatic-repairsをtrueにする事で有効化できます。automatic-repairs-grace-periodは正常性NGの状態がどの程度継続した場合に仮想マシンを削除するかの設定で、最低値は10分です。あまりに短い値を設定し過ぎると、デプロイ処理が完了する前に削除されてしまったり、フラッピングが発生してしまったりのリスクがあるので、過度に短い値は設定しないようにしましょう。

az vmss update \
  --resource-group MyResourceGroup \
  --name MyScaleSet01 \
  --enable-automatic-repairs true \
  --automatic-repairs-grace-period 10

自動修復の動作確認

現在デプロイされている仮想マシンのインスタンスIDを確認します。

$ az vmss list-instances  \
  --resource-group MyResourceGroup \
  --name MyScaleSet01 \
  --query "[].{instanceId:instanceId, name:name}" \
  --output table
InstanceId    Name
------------  --------------
0             MyScaleSet01_0
3             MyScaleSet01_3

動作確認のために、1台の仮想マシンのnginxを停止させます。

INSTANCE_ID=$(az vmss list-instances  \
  --resource-group MyResourceGroup \
  --name MyScaleSet01 \
  --query "[0].instanceId" \
  --output tsv )

az vmss run-command invoke \
  --resource-group MyResourceGroup \
  --name MyScaleSet01 \
  --command-id RunShellScript \
  --instance-id ${INSTANCE_ID} \
  --scripts 'systemctl stop nginx.service'

1台の仮想マシンが正常性NGとなる事を確認します。

10分後、インスタンスIDを確認します。すると、インスタンスIDが0である仮想マシンが削除され、インスタンスIDが4である仮想マシンが新設されている事が分かります。

$ az vmss list-instances  \
  --resource-group MyResourceGroup \
  --name MyScaleSet01 \
  --query "[].{instanceId:instanceId, name:name}" \
  --output table
InstanceId    Name
------------  --------------
3             MyScaleSet01_3
4             MyScaleSet01_4

「仮想マシンスケールセット」の「アクティビティログ」を確認すると、「Health Event Resolved」と記録されている事も分かります。

補足

拡張機能

正常性監視は、Linux内にインストールされた「Microsoft Azure Linux エージェント (waagent) 」が実行します。そのため、「Azure ネットワークセキュリティグループ」や「OS標準機能のfirewalld」などの影響を受けません。これら「Azure ネットワークセキュリティグループ」や「OS標準機能のfirewalld」がtcpを拒否していたとしても、正常性監視はOKになります。

nginxのアクセスログを確認します。すると、送信元IPアドレスが127.0.0.1(localhost)になっている事が分かります。

azureuser@myscae302000003:~$ sudo tail -n3 -f /var/log/nginx/access.log
127.0.0.1 - - [21/Mar/2022:10:44:54 +0000] "GET /index.html HTTP/1.1" 200 49 "-" "ApplicationHealthExtension/1.0"
127.0.0.1 - - [21/Mar/2022:10:44:59 +0000] "GET /index.html HTTP/1.1" 200 49 "-" "ApplicationHealthExtension/1.0"
127.0.0.1 - - [21/Mar/2022:10:45:04 +0000] "GET /index.html HTTP/1.1" 200 49 "-" "ApplicationHealthExtension/1.0"

psコマンドで確認すると、waagentが常駐プロセスとして動作している事も分かります。

azureuser@myscae302000003:~$ ps aux | grep waagent
root      1010  0.0  2.3  80300 22156 ?        Ss   10:11   0:00 /usr/bin/python3 -u /usr/sbin/waagent -daemon
root      2445  0.0  0.2  21888  2048 ?        S    10:39   0:00 /bin/bash /var/lib/waagent/Microsoft.ManagedServices.ApplicationHealthLinux-1.0.3/bin/applicationhealth-shim enable
root      2462  0.0  1.0 535840 10132 ?        Sl   10:39   0:00 /var/lib/waagent/Microsoft.ManagedServices.ApplicationHealthLinux-1.0.3/bin/applicationhealth-extension enable
azureus+  2848  0.0  0.1  14860  1068 pts/0    S+   10:49   0:00 grep --color=auto waagent