ローリング アップグレードのカスタム メトリックを使用すると、アプリケーション正常性拡張機能を利用して、仮想マシン スケール セットにカスタム メトリックを出力できるようになります。 これらのカスタム メトリックを使用して、ローリング アップグレードがトリガーされた際に仮想マシンを更新する順序をスケール セットに指示できます。 カスタム メトリックは、特定のインスタンス上でアップグレードをスキップする必要がある場合に、そのスケール セットに通知することもできます。 これにより、順序付けと更新プロセス自体を、より詳細に制御できます。
カスタム メトリックは、自動 OS アップグレード、自動拡張機能アップグレード、MaxSurge ローリング アップグレードなど、他のローリング アップグレード機能と組み合わせて使用できます。
要件
- Virtual Machine Scale Sets 上でローリング アップグレードのカスタム メトリックを使用する場合、そのスケール セットでは、アプリケーション正常性拡張機能と Rich Health States も使用して、フェーズの順序付けをレポートする、またはアップグレード情報をスキップする必要があります。 カスタム メトリックのアップグレードは、Binary States でアプリケーション正常性拡張機能を使用する場合はサポートされません。
- カスタム メトリック情報を受信するには、HTTP または HTTPS を使用するようにアプリケーション正常性拡張機能を設定する必要があります。 ローリング アップグレードのカスタム メトリックとの統合に対して、TCP はサポートされていません。
概念
フェーズの順序付け
フェーズは、仮想マシンのグループ化構成体です。 各フェーズは プロパティを経由し、customMetrics
から出力されるメタデータを設定することで決定されます。 仮想マシン スケール セットは、カスタム メトリックから取得した情報を受け取り、それを使用して割り当てられたフェーズ内に仮想マシンを配置します。 各フェーズ内で、仮想マシン スケール セットはアップグレード バッチも割り当てます。 各バッチは、各仮想マシンの更新ドメイン (UD)、障害ドメイン (FD)、ゾーン情報を考慮したローリング アップグレード ポリシーを使用して構成されます。
ローリング アップグレードが開始されると、仮想マシンは指定されたフェーズ内に配置されます。 段階的なアップグレードは、数値のシーケンス順序で実行されます。 あるフェーズ内のすべてのバッチ内の Virtual Machines は、次のフェーズに進む前に完了します。 ある仮想マシンに対するフェーズの順序付けが受信されない場合は、スケール セットによって最後のフェーズ内に配置されます
リージョン スケール セット
ゾーン スケール セット
仮想マシンを関連付ける必要があるフェーズ番号を指定するには、phaseOrderingNumber
パラメーターを使用します。
{
“applicationHealthState”: “Healthy”,
“customMetrics”: "{ \"rollingUpgrade\": { \"PhaseOrderingNumber\": 0 } }"
}
アップグレードをスキップする
アップグレードのスキップ機能を使用すると、ローリング アップグレード中に個々のインスタンスをアップグレードから除外できるようになります。 これはインスタンス保護の利用と似ていますが、ローリング アップグレード ワークフローおよびインスタンス レベルのアプリケーションと、よりシームレスに統合できます。 フェーズの順序付けと同様に、アップグレードのスキップ情報は、アプリケーション正常性拡張機能およびカスタム メトリック設定を経由して仮想マシン スケール セットに渡されます。 ローリング アップグレードがトリガーされると、仮想マシン スケール セットはアプリケーション正常性拡張機能のカスタム メトリックの応答をチェックし、アップグレードのスキップが true に設定されている場合、そのインスタンスはローリング アップグレードに含まれません。
仮想マシン上でアップグレードをスキップするには、SkipUpgrade
パラメーターを使用します。 これにより、ローリング アップグレードは、アップグレードの実行時にこの仮想マシンをスキップするように指示されます。
{
“applicationHealthState”: “Healthy”,
“customMetrics”: "{ \"rollingUpgrade\": { \"SkipUpgrade\": true} }"
}
アップグレードのスキップとフェーズの順序を一緒に使用することもできます。
{
“applicationHealthState”: “Healthy”,
“customMetrics”: "{ \"rollingUpgrade\": { \"SkipUpgrade\": false, \"PhaseOrderingNumber\": 0 } }"
}
アプリケーション正常性拡張機能を構成する
アプリケーション正常性拡張機能には、関連付けられたポートまたは要求パスを含む HTTP または HTTPS 要求が必要です。 TCP プローブは、アプリケーション正常性拡張機能を使用する場合にサポートされますが、プローブ応答本文を使用して ApplicationHealthState
を設定できず、カスタム メトリックを使用したローリング アップグレードでは使用できません。
{
"extensionProfile" : {
"extensions" : [
{
"name": "HealthExtension",
"properties": {
"publisher": "Microsoft.ManagedServices",
"type": "<ApplicationHealthLinux or ApplicationHealthWindows>",
"autoUpgradeMinorVersion": true,
"typeHandlerVersion": "1.0",
"settings": {
"protocol": "<protocol>",
"port": <port>,
"requestPath": "</requestPath>",
"intervalInSeconds": 5,
"numberOfProbes": 1
}
}
}
]
}
}
名前 | 値/例 | データ型 |
---|---|---|
プロトコル | http または https |
ひも |
港 | プロトコルが http または https の場合はオプション |
整数 (int) |
requestPath | http または https を使用する場合は必須 |
ひも |
秒単位の間隔 | 省略可能。既定値は 5 秒です。 この設定は、各正常性プローブ間の間隔です。 たとえば、intervalInSeconds == 5 の場合、プローブは 5 秒ごとにローカル アプリケーション エンドポイントに送信されます。 | 整数 (int) |
プローブ数 | 省略可能。既定値は 1 です。 この設定は、正常性状態を変更するために必要な連続プローブの数です。 たとえば、numberOfProbles == 3 の場合、正常性状態を "異常"/"不明" から "正常" 状態に変更するには、3 つの連続した "正常" シグナルが必要です。 正常性状態を "異常" または "不明" 状態に変更する場合も同じ要件が適用されます。 | 整数 (int) |
猶予期間 | 省略可能、既定値 = intervalInSeconds * numberOfProbes 、最大猶予期間は 7200 秒です |
整数 (int) |
アプリケーション正常性拡張機能をインストールする
az vmss extension set を使用して、アプリケーション正常性拡張機能をスケール セット モデルの定義に追加します。
目的の設定を使用して、extensions.json
という json ファイルを作成します。
{
"protocol": "<protocol>",
"port": <port>,
"requestPath": "</requestPath>",
"gracePeriod": <healthExtensionGracePeriod>
}
アプリケーション正常性拡張機能を適用します。
az vmss extension set \
--name ApplicationHealthLinux \
--publisher Microsoft.ManagedServices \
--version 2.0 \
--resource-group myResourceGroup \
--vmss-name myScaleSet \
--settings ./extension.json
スケール セット内の仮想マシンをアップグレードします。 この手順は、そのスケール セットが手動アップグレード ポリシーを使用している場合にのみ必要です。 アップグレード ポリシーの詳細については、「Virtual Machine Scale Sets のアップグレード ポリシー」を参照してください
az vmss update-instances \
--resource-group myResourceGroup \
--name myScaleSet \
--instance-ids "*"
アプリケーション正常性拡張機能の応答を構成する
カスタム メトリックの応答の構成は、さまざまな方法で実現できます。 既存のアプリケーションに統合する、動的に更新する、さまざまな機能と共に使用するなど、特定の状況に基づいて出力を提供できます。
これらのサンプル アプリケーションでは、カスタム メトリックの応答内に、フェーズの順序とアップグレードのスキップ パラメーターを含みます。
#!/bin/bash
# Open firewall port (replace with your firewall rules as needed)
sudo iptables -A INPUT -p tcp --dport 8000 -j ACCEPT
# Create Python HTTP server for responding with JSON
cat <<EOF > server.py
import json
from http.server import BaseHTTPRequestHandler, HTTPServer
# Function to generate the JSON response
def generate_response_json():
return json.dumps({
"ApplicationHealthState": "Healthy",
"CustomMetrics": json.dumps({
"RollingUpgrade": {
"PhaseOrderingNumber": 1,
"SkipUpgrade": "false"
}
})
})
class RequestHandler(BaseHTTPRequestHandler):
def do_GET(self):
# Respond with HTTP 200 and JSON content
self.send_response(200)
self.send_header('Content-type', 'application/json')
self.end_headers()
response = generate_response_json()
self.wfile.write(response.encode('utf-8'))
# Set up the HTTP server
def run(server_class=HTTPServer, handler_class=RequestHandler):
server_address = ('localhost', 8000)
httpd = server_class(server_address, handler_class)
print('Starting server on port 8000...')
httpd.serve_forever()
if __name__ == "__main__":
run()
EOF
# Run the server in the background
python3 server.py &
# Store the process ID of the server
SERVER_PID=$!
# Wait a few seconds to ensure the server starts
sleep 2
# Confirm execution
echo "Server has been started on port 8000 with PID $SERVER_PID"
応答構成の例については、アプリケーション正常性のサンプルを参照してください
次のステップ
Virtual Machine Scale Sets で手動アップグレードを実行する方法について説明します。