Azure 仮想マシンスケールセットによる自動的な OS イメージのアップグレード

[アーティクル]
10/15/2024

注意

このドキュメントで示されている手順の多くは、均一オーケストレーションモードを使用する Virtual Machine Scale Sets に適用されます。新しいワークロードにはフレキシブルオーケストレーションを使用することをお勧めします。詳細については、「Azure での Virtual Machine Scale Sets のオーケストレーションモード」を参照してください。

スケールセットで OS イメージの自動アップグレードを有効にすると、スケールセット内のすべてのインスタンスの OS ディスクが安全かつ自動的にアップグレードされるようになり、更新プログラムの管理が容易になります。

OS の自動アップグレードには、次の特徴があります。

構成すると、イメージ発行元によって公開された最新の OS イメージが、ユーザーの介入なしでスケールセットに自動的に適用されます。
新しいイメージが発行元によって発行されるたびに、ローリングの方法でバッチごとにインスタンスをアップグレードします。
アプリケーション正常性プローブおよびアプリケーション正常性拡張機能と統合されます。
すべての VM サイズに対して、また、Azure Compute Gallery から入手したカスタムイメージを含む Windows イメージと Linux イメージの両方に対して動作します。
自動アップグレードはいつでも停止できます (OS のアップグレードは、手動でも開始できます)。
VM の OS ディスクが、最新バージョンのイメージで作成された新しい OS ディスクに置き換えられます。永続化されているデータディスクは保持されたまま、構成済みの拡張機能とカスタムデータスクリプトが実行されます。
拡張機能のシーケンス処理がサポートされています。
すべてのサイズのスケールセットで有効にできます。

注意

OS イメージの自動アップグレードを有効にする前に、このドキュメントの要件のセクションを確認してください。

OS イメージの自動アップグレードのしくみ

アップグレードは、VM の OS ディスクを、イメージバージョンを使用して作成された新しいディスクに置き換えることによって実行されます。すべての構成済み拡張機能とカスタムデータスクリプトは OS ディスク上で実行されますが、データディスクは保持されます。アプリケーションのダウンタイムを最小限に抑えるため、アップグレードはバッチで行われ、いつでもスケールセットの 20% を超えてアップグレードされることはありません。

アップグレード後にアプリケーションの正常性を追跡するには、Azure Load Balancer アプリケーション正常性プローブまたはアプリケーションの正常性拡張機能を統合する必要があります。これにより、プラットフォームは VM の正常性を検証して、更新プログラムが安全な方法で適用されることを確認できます。アップグレードの成功を検証するために、アプリケーションハートビートを組み込むことをお勧めします。

可用性優先の更新

以下で説明するプラットフォームの調整された更新の可用性優先モデルにより、Azure の可用性構成が複数の可用性レベルで尊重されます。

複数のリージョン間:

Azure 全体のデプロイが失敗するのを防ぐために、更新は Azure 全体を段階的に移動します。
1 つの "フェーズ" には 1 つ以上のリージョンを含めることができます。前のフェーズで対象の VM が正常に更新された場合にのみ、更新はフェーズ間を移動します。
geo ペアリージョンは同時に更新されず、同じリージョンフェーズに置くことはできません。
更新の成功は、更新後に VM の正常性を追跡することによって測定できます。

リージョン内:

異なる Availability Zones の VM は、同じ更新で同時に更新されることはありません。

"セット" 内:

共通のスケールセット内のすべての VM が同時に更新されることはありません。
共通の仮想マシンスケールセット内の VM は、以下に示すように、バッチにグループ化され、更新ドメインの境界内で更新されます。

プラットフォームの調整された更新プロセスに従って、サポートされている OS プラットフォームイメージのアップグレードが毎月ロールアウトされます。 Azure Compute Gallery から入手したカスタムイメージの場合、イメージのアップグレードは、その新しいイメージが公開され、そのスケールセットのリージョンにレプリケートされた時に、特定の Azure リージョンに対してのみ開始されます。

スケールセット内の VM のアップグレード

スケールセットのリージョンは、プラットフォームイメージ用の可用性優先プロセスまたは Shared Image Gallery の新しいカスタムイメージバージョンのレプリケートによるイメージアップグレードの対象となります。その後、イメージアップグレードは、バッチ処理された方法で次のように個々のスケールセットに適用されます。

アップグレードプロセスを開始する前に、オーケストレーターは異常なインスタンスが全体的なスケールセットの 20% を超えていないことを確認します。
アップグレードオーケストレーターは、どの 1 つのバッチも最大で合計インスタンス数の 20% であり、1 つの仮想マシンの最小バッチサイズを満たしているという条件で、アップグレードする VM インスタンスのバッチを識別します。最小スケールセットサイズの要件はなく、インスタンス数が 5 以下のスケールセットは、アップグレードバッチごとに 1 つの VM を持ちます (最小バッチサイズ)。
選択されたアップグレードバッチの各 VM の OS ディスクは、イメージから作成された新しい OS ディスクに置き換えられます。スケールセットモデルに指定されたすべての拡張機能と構成は、アップグレードされたインスタンスに適用されます。
構成済みのアプリケーション正常性プローブやアプリケーション正常性拡張機能があるスケールセットの場合、アップグレードはインスタンスが正常になるまで 5 分間待機した後、次のバッチのアップグレードに進みます。アップグレードから 5 分以内にインスタンスの正常性が回復しない場合は、既定でそのインスタンスの以前の OS ディスクが復元されます。
また、アップグレードオーケストレーターでは、アップグレード後に異常が発生したインスタンスの割合も追跡されます。アップグレード処理中に異常なアップグレード済みインスタンスの割合が 20% を超えた場合、アップグレードは停止します。
上記のプロセスは、スケールセット内のすべてのインスタンスがアップグレードされるまで続行されます。

スケールセットの OS アップグレードオーケストレーターは、各バッチをアップグレードする前に、スケールセットの全体の正常性を確認します。バッチのアップグレード中に、他の計画メンテナンスまたは計画外メンテナンスのアクティビティが同時に発生することがあり、それによってスケールセットインスタンスの正常性が影響を受ける場合があります。そのような場合、スケールセットのインスタンスの 20% 以上が異常な状態になると、スケールセットのアップグレードは現在のバッチが終了した時点で停止します。

ローリングアップグレードに関連する既定の設定を変更するには、Azure のローリングアップグレードポリシーを確認します。

Note

OS の自動アップグレードでは、スケールセットの参照イメージ SKU はアップグレードされません。 SKU (Ubuntu 18.04-LTS から 20.04-LTS など) を変更するには、目的のイメージ SKU を使用して直接スケールセットモデルを更新する必要があります。既存のスケールセットに対して、イメージ発行者とオファーを変更することはできません。

OS イメージのアップグレードと再イメージ化

スケールセット内の VM の更新に使用される方法には、OS イメージのアップグレード と再イメージ化の両方がありますが、用途も影響もそれぞれ異なります。

OS イメージのアップグレードには、スケールセット内での新しいインスタンスの作成に使用される、基になるオペレーティングシステムイメージの更新が含まれます。 OS イメージのアップグレードを実行するとき、Azure によって、更新された OS イメージを備える新しい VM インスタンスの作成が行われ、スケールセット内の以前の VM インスタンスは、徐々に新しいものと置き換えられます。このプロセスは、通常、段階的に実行され、それにより高可用性が確保されます。 OS イメージのアップグレードは、スケールセット内の VM の基になっている OS への更新や変更の適用のための中断のない方法です。既存の VM インスタンスは、新しいインスタンスと置き換えられるまでは、影響を受けません。

スケールセット内の VM インスタンスの再イメージ化は、より迅速で中断を含むアクションです。 VM インスタンスの再イメージ化を選択すると、選択された VM インスタンスが Azure によって停止され、再イメージ化の操作が行われます。その後、同じ OS イメージを使用して VM が再起動されます。これにより、特定のその VM インスタンスに、OS が効果的に再インストールされます。再イメージ化は、通常、特定の VM インスタンスを、そのインスタンスにかかわる問題が原因でトラブルシューティングまたはリセットする必要がある場合に使用されます。

主な相違点:

OS イメージのアップグレードは、仮想マシンスケールセット全体の OS イメージを、時間の経過とともに更新する、漸進的で中断のないプロセスであり、実行中のワークロードへの影響が最小限であることが保証されます。
再イメージ化は、選択した VM インスタンスにのみ影響する、より迅速で中断を含むアクションであり、その VM インスタンスを一時的に停止し、OS を再インストールします。

どのようなときに各方法を使用するか:

スケールセット全体の OS イメージを更新する必要があり、同時に高可用性を維持したい場合は、OS イメージのアップグレードを使用します。
仮想マシンスケールセット内部の特定の VM インスタンスをトラブルシューティングまたはリセットする必要がある場合は、再イメージ化を使用します。

仮想マシンスケールセット内で実行されているアプリケーションやサービスの中断を最小限に抑えるために、具体的な要件に基づいて、適切な方法を注意深く計画および選択することが重要です。

サポート対象の OS イメージ

現時点では、特定の OS プラットフォームイメージのみがサポートされています。カスタムイメージが Azure Compute Gallery を介してスケールセットで使用されている場合は、そのカスタムイメージはサポートされます。

現時点では、以下のプラットフォーム SKU がサポートされています (定期的に追加されます)。

Publisher	OS 製品	Sku
Canonical	UbuntuServer	18.04-LTS
Canonical	UbuntuServer	18_04-LTS-Gen2
Canonical	0001-com-ubuntu-server-focal	20_04-LTS
正規	0001-com-ubuntu-server-focal	20_04-LTS-Gen2
Canonical	0001-com-ubuntu-server-jammy	22_04-LTS
Canonical	0001-com-ubuntu-server-jammy	22_04-LTS-Gen2
MicrosoftCblMariner	Cbl-Mariner	cbl-mariner-1
MicrosoftCblMariner	Cbl-Mariner	1-Gen2
MicrosoftCblMariner	Cbl-Mariner	cbl-mariner-2
MicrosoftCblMariner	Cbl-Mariner	cbl-mariner-2-Gen2
MicrosoftSqlServer	Sql2017-ws2019	エンタープライズ
MicrosoftWindowsServer	WindowsServer	2012-R2-Datacenter
MicrosoftWindowsServer	WindowsServer	2016-Datacenter
MicrosoftWindowsServer	WindowsServer	2016-Datacenter-gensecond
MicrosoftWindowsServer	WindowsServer	2016-Datacenter-gs
MicrosoftWindowsServer	WindowsServer	2016-Datacenter-smalldisk
MicrosoftWindowsServer	WindowsServer	2016-Datacenter-with-Containers
MicrosoftWindowsServer	WindowsServer	2016-Datacenter-with-containers-gs
MicrosoftWindowsServer	WindowsServer	2019-Datacenter
MicrosoftWindowsServer	WindowsServer	2019-Datacenter-Core
MicrosoftWindowsServer	WindowsServer	2019-Datacenter-Core-with-Containers
MicrosoftWindowsServer	WindowsServer	2019-Datacenter-gensecond
MicrosoftWindowsServer	WindowsServer	2019-Datacenter-gs
MicrosoftWindowsServer	WindowsServer	2019-Datacenter-smalldisk
MicrosoftWindowsServer	WindowsServer	2019-Datacenter-with-Containers
MicrosoftWindowsServer	WindowsServer	2019-Datacenter-with-Containers-gs
MicrosoftWindowsServer	WindowsServer	2022-Datacenter
MicrosoftWindowsServer	WindowsServer	2022-Datacenter-smalldisk
MicrosoftWindowsServer	WindowsServer	2022-Datacenter-smalldisk-g2
MicrosoftWindowsServer	WindowsServer	2022-Datacenter-core
MicrosoftWindowsServer	WindowsServer	2022-Datacenter-core-smalldisk
MicrosoftWindowsServer	WindowsServer	2022-Datacenter-g2
MicrosoftWindowsServer	WindowsServer	Datacenter-core-20h2-with-containers-smalldisk-gs
MicrosoftWindowsServer	WindowsServer	2022-Datacenter-azure-edition
MicrosoftWindowsServer	WindowsServer	2022-Datacenter-azure-edition-smalldisk
Mirantis	Windows_with_Mirantis_Container_Runtime_2019	win_2019_mcr_23_0
Mirantis	Windows_with_Mirantis_Container_Runtime_2019	win_2019_mcr_23_0_gen2

OS イメージの自動アップグレードを構成するための要件

イメージの version プロパティを latest に設定する必要があります。
Service Fabric 以外のスケールセットには、アプリケーション正常性プローブまたはアプリケーション正常性拡張機能を使用する必要があります。 Service Fabric の要件については、「Service Fabric の要件」を参照してください。
コンピューティング API バージョン 2018-10-01 以降を使用します。
スケールセットモデルで指定された外部リソースが利用可能であり、更新可能であることを確認してください。例としては、VM 拡張プロパティ内のブートストラップペイロードの SAS URI、ストレージアカウント内のペイロード、モデル内のシークレットへの参照などが挙げられます。
Windows 仮想マシンを使用するスケールセットの場合、コンピューティング API バージョン 2019-03-01 以降、スケールセットモデル定義で virtualMachineProfile.osProfile.windowsConfiguration.enableAutomaticUpdates プロパティを false に設定する必要があります。 enableAutomaticUpdates プロパティを使用すると、OS ディスクを交換せずにオペレーティングシステムのパッチを "Windows Update" で適用する VM 内パッチが可能になります。スケールセットで OS イメージの自動アップグレードを有効にすると (これを行うには、automaticOSUpgradePolicy.enableAutomaticOSUpgrade を true に設定します)、Windows Update による追加のパッチ適用プロセスは必要ありません。
スケールセットモデルの定義でパッチオーケストレーションモードを AutomaticByPlatform に設定しないようにする必要があります。スケールセットで OS イメージの自動アップグレードが有効になっている場合、プラットフォームのオーケストレーションパッチ適用プロセスは必要ありません。

Note

再イメージ化またはアップグレードによって OS ディスクが置き換えられた後に、アタッチされたデータディスクのドライブ文字が再割り当てされる場合があります。アタッチされたディスクに対して同じドライブ文字を保持するには、カスタムブートスクリプトを使用することをお勧めします。

Service Fabric の要件

Service Fabric を使用している場合は、次の条件が満たされていることを確認します。

Service Fabric の持続性レベルは Silver または Gold です。 Service Fabric の持続性が Bronze の場合、ステートレス専用のノードの型のみが OS イメージの自動アップグレードをサポートします。
スケールセットモデル定義の Service Fabric 拡張機能には、TypeHandlerVersion 1.1 以降が必要です。
持続性レベルは、スケールセットモデル定義の Service Fabric クラスターと Service Fabric 拡張機能で同じである必要があります。
Silver または Gold の持続性については、追加の正常性プローブやアプリケーション正常性拡張機能を使用する必要はありません。ノードの種類がステートレス専用の Bronze の持続性には、追加の正常性プローブが必要です。
プロパティ virtualMachineProfile.osProfile.windowsConfiguration.enableAutomaticUpdates プロパティは、スケールセットモデルの定義で false に設定する必要があります。 enableAutomaticUpdates プロパティを使用すると、"Windows Update" を使用した VM 内パッチが可能になりますが、このプロパティは Service Fabric スケールセットではサポートされていません。代わりに、automaticOSUpgradePolicy.enableAutomaticOSUpgrade プロパティを使う必要があります。

Service Fabric クラスターと Service Fabric 拡張機能で持続性の設定に不一致がないことを確認します。これは、一致しない場合にアップグレードエラーが発生する可能性があるためです。持続性レベルは、このページで説明されているガイドラインに従って変更できます。

カスタムイメージの OS イメージの自動アップグレード

OS イメージの自動アップグレードは、Azure Compute Gallery を介して展開されているカスタムイメージでサポートされています。その他のカスタムイメージは、OS イメージの自動アップグレードではサポートされていません。

カスタムイメージのその他の要件

OS イメージの自動アップグレードのセットアップおよび構成プロセスは、このページの構成に関するセクションで詳しく説明されているように、すべてのスケールセットについて同一です。
OS イメージの自動アップグレード用に構成されたスケールセットインスタンスは、新しいバージョンのイメージが発行され、そのスケールセットのリージョンにレプリケートされたときに、Azure Compute Gallery のイメージのバージョンにアップグレードされます。スケールがデプロイされているリージョンに新しいイメージがレプリケートされていない場合、スケールセットインスタンスはそのバージョンにアップグレードされません。リージョンのイメージレプリケーションによって、スケールセットの新しいイメージのロールアウトを制御することができます。
そのギャラリーイメージのバージョンから、新しいイメージバージョンを除外しないでください。ギャラリーイメージのバージョンから除外されたイメージバージョンは、OS イメージの自動アップグレードによってスケールセットにロールアウトされません。

Note

スケールセットが OS の自動アップグレードに向けて初めて構成された後、スケールセットによって最初のイメージのアップグレードロールアウトがトリガーされるまでには、最大 3 時間かかることがあります。これは、メンテナンス期間やその他の制限などの特定の要因によるものです。最新のイメージを使用しているお客様は、新しいイメージが使用可能になるまでアップグレードが取得されない場合があります。

OS イメージの自動アップグレードの構成

OS イメージの自動アップグレードを構成するには、スケールセットのモデル定義で automaticOSUpgradePolicy.enableAutomaticOSUpgrade プロパティが true に設定されていることを確認します。

Note

アップグレードポリシーモードと OS の自動アップグレードポリシーは別の設定であり、スケールセットの別の側面を制御します。アップグレードポリシーmodeは、スケールセットテンプレートが変更された場合にスケールセット内の既存のインスタンスに対する処理を決定します。一方、OS の自動アップグレードポリシー enableAutomaticOSUpgrade は OS イメージに固有であり、イメージの発行元が行った変更を追跡し、イメージが更新された場合の処理を決定します。

Note

enableAutomaticOSUpgrade が true に設定されている場合、enableAutomaticUpdates は自動的に false に設定され、true に設定することはできません。

REST API

次の例は、スケールセットモデルでの自動 OS アップグレードを設定する方法について説明したものです。

PUT or PATCH on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/myScaleSet?api-version=2021-03-01`

{
  "properties": {
    "upgradePolicy": {
      "automaticOSUpgradePolicy": {
        "enableAutomaticOSUpgrade":  true
      }
    }
  }
}

Azure PowerShell

プロビジョニングの間にスケールセットに対して自動 OS イメージアップグレードを構成するには、New-AzVmss コマンドレットを使います。次の例では、myResourceGroup というリソースグループ内の myScaleSet というスケールセットの自動アップグレードを構成しています。

New-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet" -AutomaticOSUpgrade $true

既存のスケールセットに対して自動 OS イメージアップグレードを構成するには、Update-AzVmss コマンドレットを使います。次の例では、myResourceGroup というリソースグループ内の myScaleSet というスケールセットの自動アップグレードを構成しています。

Update-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet" -AutomaticOSUpgrade $true

Azure CLI 2.0

プロビジョニングの間にスケールセットに対して自動 OS イメージアップグレードを構成するには、az vmss create を使います。 Azure CLI 2.0.47 以上を使用してください。次の例では、myResourceGroup というリソースグループ内の myScaleSet というスケールセットの自動アップグレードを構成しています。

az vmss create --name myScaleSet --resource-group myResourceGroup --enable-auto-os-upgrade true --upgrade-policy-mode Rolling

既存のスケールセットに対して自動 OS イメージアップグレードを構成するには、az vmss update を使います。 Azure CLI 2.0.47 以上を使用してください。次の例では、myResourceGroup というリソースグループ内の myScaleSet というスケールセットの自動アップグレードを構成しています。

az vmss update --name myScaleSet --resource-group myResourceGroup --enable-auto-os-upgrade true --upgrade-policy-mode Rolling

Note

スケールセットで "手動" アップグレードポリシーを使用している場合は、スケールセットに OS イメージの自動アップグレードを構成した後で、スケールセットの VM を最新のスケールセットモデルにする必要もあります。

ARM テンプレート

次の例では、Azure Resource Manager テンプレート (ARM テンプレート) を使用してスケールセットモデルに OS の自動アップグレードを設定する方法について説明します。

"properties": {
   "upgradePolicy": {
     "mode": "Automatic",
     "RollingUpgradePolicy": {
         "BatchInstancePercent": 20,
         "MaxUnhealthyInstancePercent": 25,
         "MaxUnhealthyUpgradedInstancePercent": 25,
         "PauseTimeBetweenBatches": "PT0S"
     },
    "automaticOSUpgradePolicy": {
      "enableAutomaticOSUpgrade": true,
        "useRollingUpgradePolicy": true,
        "disableAutomaticRollback": false
    }
  },
  },
"imagePublisher": {
   "type": "string",
   "defaultValue": "MicrosoftWindowsServer"
 },
 "imageOffer": {
   "type": "string",
   "defaultValue": "WindowsServer"
 },
 "imageSku": {
   "type": "string",
   "defaultValue": "2022-datacenter"
 },
 "imageOSVersion": {
   "type": "string",
   "defaultValue": "latest"
 }

Bicep

次の例は、Bicep を使用してスケールセットモデルで自動 OS アップグレードを設定する方法について説明したものです。

properties: {
    overprovision: overProvision
    upgradePolicy: {
      mode: 'Automatic'
      automaticOSUpgradePolicy: {
        enableAutomaticOSUpgrade: true
      }
    }
}

アプリケーション正常性拡張機能の使用

OS のアップグレード中は、スケールセット内の VM インスタンスが、一度に 1 つのバッチでアップグレードされます。アップグレードは、アップグレード済みの VM インスタンス上でユーザーのアプリケーションが正常である場合のみ続行されます。アプリケーションがスケールセットの OS アップグレードエンジンに正常性通知を提供することをお勧めします。既定では、OS のアップグレード中、プラットフォームは、VM の電源状態と拡張機能のプロビジョニング状態を考慮して、アップグレード後に VM インスタンスが正常であるかどうかを判断します。 VM インスタンスの OS のアップグレード中、VM インスタンス上の OS ディスクは、最新バージョンのイメージに基づく新しいディスクに置き換えられます。 OS のアップグレードが完了した後、構成済みの拡張機能がこれらの VM 上で実行されます。アプリケーションは、インスタンス上のすべての拡張機能が正常にプロビジョニングされた場合にのみ、正常であるとみなされます。

スケールセットにアプリケーション正常性プローブをオプションで構成して、アプリケーションの進行中の状態に関する正確な情報をプラットフォームに提供できます。アプリケーション正常性プローブは、正常性シグナルとして使用されるカスタムロードバランサープローブです。スケールセットの VM インスタンスで実行されているアプリケーションは、外部 HTTP または TCP 要求に応答して、正常かどうかを示すことができます。カスタムロードバランサープローブの動作方法の詳細については、「Load Balancer プローブを理解する」を参照してください。アプリケーション正常性プローブは、Service Fabric スケールセットではサポートされていません。 Service Fabric 以外のスケールセットでは、Load Balancer アプリケーション正常性プローブまたはアプリケーション正常性拡張機能が必須となります。

スケールセットが複数の配置グループを使用するように構成されている場合は、Standard Load Balancer を使用するプローブを使用する必要があります。

Note

仮想マシンスケールセットに使用できる正常性監視のソースは、アプリケーション正常性拡張機能または正常性プローブのいずれかのみです。両方のオプションを有効にしている場合は、インスタンス修復や OS の自動アップグレードなどのオーケストレーションサービスを使用する前に、いずれかのオプションを削除する必要があります。

スケールセットに関するアプリケーション正常性プローブとしてのカスタムロードバランサープローブの構成

ベストプラクティスとして、スケールセットの正常性のためのロードバランサープローブを明示的に作成します。既存の HTTP プローブまたは TCP プローブと同じエンドポイントを使用できますが、この正常性プローブでは、従来のロードバランサープローブとは異なる動作が必要になる可能性があります。たとえば、従来のロードバランサープローブは、インスタンスの負荷が高すぎる場合に異常を返すことがありますが、OS の自動アップグレード中にインスタンスの正常性を決定するには、その動作は適切ではない可能性があります。 2 分未満のプローブ率が高いプローブを構成します。

ロードバランサープローブは、スケールセットの networkProfile 内で参照でき、次のように、内部または公開されているロードバランサーに関連付けることができます。

"networkProfile": {
  "healthProbe" : {
    "id": "[concat(variables('lbId'), '/probes/', variables('sshProbeName'))]"
  },
  "networkInterfaceConfigurations":
  ...
}

Note

Service Fabric と OS 自動アップグレードを使用している場合、Service Fabric で実行されているサービスの高可用性を維持するために、新しい OS イメージは更新ドメインごとにロールアウトされます。 Service Fabric で OS の自動アップグレードを利用するには、クラスターのノードの種類が、シルバー以上の持続性レベルを使用するように構成されている必要があります。ブロンズの持続性レベルの場合、OS イメージの自動アップグレードは、ステートレスのノードの種類でのみサポートされます。 Service Fabric クラスターの持続性の特徴の詳細については、こちらのドキュメントを参照してください。

アプリケーション正常性拡張機能の使用

アプリケーションの正常性拡張機能は、仮想マシンスケールセットのインスタンス内にデプロイされ、スケールセットインスタンス内から VM の正常性について報告します。拡張機能は、アプリケーションエンドポイントでプローブを実行し、そのインスタンスでアプリケーションの状態を更新するように構成することができます。このインスタンスの状態は Azure によってチェックされ、インスタンスがアップグレード操作の対象となるかどうかが判断されます。

拡張機能は VM 内から正常性をレポートするため、(カスタム Azure Load Balancer プローブを使用する) アプリケーションの正常性プローブなどの外部プローブが使用できない状況で使用できます。

こちらの記事の例で詳しく示すように、アプリケーションの正常性拡張機能をお使いのスケールセットにデプロイする方法は複数あります。

Note

OS イメージの自動アップグレードの履歴を取得する

Azure PowerShell、Azure CLI 2.0、または REST API を使用して、スケールセットに対して実行された最新の OS のアップグレードの履歴を確認できます。過去 2 か月間に試行された最後の 5 回の OS アップグレードの履歴を取得できます。

資格情報を最新に保つ

スケールセットが外部のリソースにアクセスするときに資格情報を使用する場合、たとえば、VM 拡張機能がストレージアカウントの SAS トークンを使用するように構成されている場合には、資格情報が最新であることを確認してください。証明書やトークンなどの資格情報の期限が切れている場合は、アップグレードは失敗し、VM の最初のバッチは障害が発生した状態になります。

リソースの認証エラーが発生した場合に、VM を復旧し、OS の自動アップグレードを再度有効にするための推奨手順は次のとおりです。

拡張機能に渡されたトークン (またはその他の資格情報) を再生成します。
外部エンティティと対話する VM 内から使用されるすべての資格情報が最新であることを確認します。
新しいトークンで、スケールセットモデルの拡張機能を更新します。
障害が発生したものを含むすべての VM インスタンスを更新する、更新されたスケールセットをデプロイします。

REST API

次の例では、REST API を使用して、myResourceGroup という名前のリソースグループ内の myScaleSet という名前のスケールセットの状態をチェックします。

GET on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/myScaleSet/osUpgradeHistory?api-version=2021-03-01`

GET 呼び出しは、次の例の出力に似たプロパティを返します。

{
	"value": [
		{
			"properties": {
        "runningStatus": {
          "code": "RollingForward",
          "startTime": "2018-07-24T17:46:06.1248429+00:00",
          "completedTime": "2018-04-21T12:29:25.0511245+00:00"
        },
        "progress": {
          "successfulInstanceCount": 16,
          "failedInstanceCount": 0,
          "inProgressInstanceCount": 4,
          "pendingInstanceCount": 0
        },
        "startedBy": "Platform",
        "targetImageReference": {
          "publisher": "MicrosoftWindowsServer",
          "offer": "WindowsServer",
          "sku": "2016-Datacenter",
          "version": "2016.127.20180613"
        },
        "rollbackInfo": {
          "successfullyRolledbackInstanceCount": 0,
          "failedRolledbackInstanceCount": 0
        }
      },
      "type": "Microsoft.Compute/virtualMachineScaleSets/rollingUpgrades",
      "location": "westeurope"
    }
  ]
}

Azure PowerShell

Get-AzVmss コマンドレットを使用して、スケールセットの OS アップグレード履歴を確認します。次の例は、myResourceGroup というリソースグループ内の myScaleSet というスケールセットの OS アップグレード状態を確認する方法を説明したものです。

Get-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet" -OSUpgradeHistory

Azure CLI 2.0

az vmss get-os-upgrade-history を使用して、スケールセットの OS アップグレード履歴を確認します。 Azure CLI 2.0.47 以上を使用してください。次の例は、myResourceGroup というリソースグループ内の myScaleSet というスケールセットの OS アップグレード状態を確認する方法を説明したものです。

az vmss get-os-upgrade-history --resource-group myResourceGroup --name myScaleSet

プラットフォーム OS イメージの最新バージョンを取得する方法

以下の例を使用して、OS の自動アップグレードがサポートされている SKU の入手できるイメージバージョンを取得できます。

REST API

GET on `/subscriptions/subscription_id/providers/Microsoft.Compute/locations/{location}/publishers/{publisherName}/artifacttypes/vmimage/offers/{offer}/skus/{skus}/versions?api-version=2021-03-01`

Azure PowerShell

Get-AzVmImage -Location "westus" -PublisherName "Canonical" -offer "0001-com-ubuntu-server-jammy" -sku "22_04-lts"

Azure CLI 2.0

az vm image list --location "westus" --publisher "Canonical" --offer "0001-com-ubuntu-server-jammy" --sku "22_04-lts" --all

OS イメージのアップグレードを手動でトリガーする

スケールセットで OS イメージの自動アップグレードが有効な場合、スケールセットでイメージの更新を手動でトリガーする必要はありません。 OS アップグレードオーケストレーターでは、手動による操作なしで、入手できる最新バージョンのイメージを自動的にスケールセットインスタンスに適用されます。

オーケストレーターによる最新イメージの適用を待ちたくない特定のケースでは、次の例を使用して OS イメージのアップグレードを手動でトリガーできます。

Note

OS イメージのアップグレードの手動トリガーでは、自動ロールバック機能を利用できません。アップグレード操作後にインスタンスの正常性が回復しない場合、その以前の OS ディスクは復元できません。

REST API

OS アップグレードの開始 API 呼び出しを使用してローリングアップグレードを開始し、すべての仮想マシンスケールセットインスタンスを、入手できる最新のイメージ OS バージョンに移行します。入手できる最新の OS バージョンを既に実行しているインスタンスは影響を受けません。次の例は、myResourceGroup というリソースグループ内の myScaleSet というスケールセット上でローリング OS アップグレードを開始する方法を説明したものです。

POST on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/myScaleSet/osRollingUpgrade?api-version=2021-03-01`

Azure PowerShell

スケールセットの OS アップグレード履歴を確認するには、Start-AzVmssRollingOSUpgrade コマンドレットを使用します。次の例は、myResourceGroup というリソースグループ内の myScaleSet というスケールセット上でローリング OS アップグレードを開始する方法を説明したものです。

Start-AzVmssRollingOSUpgrade -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet"

Azure CLI 2.0

スケールセットの OS アップグレード履歴を確認するには、az vmss rolling-upgrade start を使用します。 Azure CLI 2.0.47 以上を使用してください。次の例は、myResourceGroup というリソースグループ内の myScaleSet というスケールセット上でローリング OS アップグレードを開始する方法を説明したものです。

az vmss rolling-upgrade start --resource-group "myResourceGroup" --name "myScaleSet" --subscription "subscriptionId"

アップグレード通知と分析情報にアクティビティログを活用する

アクティビティログは、Azure で発生したサブスクリプションレベルのイベントの分析に利用できるサブスクリプションログです。お客様は次のことが可能です。

Azure portal でリソースに対して実行された操作に関連するイベントを表示する
メール、sms、webhook、ITSM などの通知方法を調整するアクショングループを作成する
ポータル、ARM リソーステンプレート、PowerShell、または CLI を使用してさまざまな基準で適切なアラートを設定し、アクショングループに送信する

お客様は、OS の自動アップグレード操作に関連する 3 種類の通知を受け取ります。

特定のリソースに対するアップグレード要求の送信
送信要求の結果とエラーの詳細
アップグレードの完了の結果とエラーの詳細

アクティビティログアラートのアクショングループの設定

アクショングループは、Azure サブスクリプションの "所有者" によって定義された通知設定を集めたものです。 Azure Monitor および Service Health のアラートでは、アクショングループを使用して、アラートがトリガーされたことをユーザーに通知します。

アクショングループは、次を使用して作成および管理できます。

お客様は、アクショングループを使用して以下を設定できます。

SMS またはメール通知
Webhook - お客様は、Webhook を Automation Runbook にアタッチし、Runbook をトリガーするようにアクショングループを構成できます。 Webhookから Runbook を開始できます
ITSM 接続

自動アップグレードエラーを調査して解決する

プラットフォームでは、ローリングアップグレードポリシーを使ったイメージの自動アップグレードの実行中に、VM 上でエラーが返されることがあります。 VM の [インスタンスビュー取得] には、エラーを調査して解決するための詳細なエラーメッセージが含まれています。 [ローリングアップグレード - 最新の取得] では、ローリングアップグレードの構成と状態の詳細を確認できます。 [OS アップグレードの履歴の取得] では、スケールセットでのイメージの最後のアップグレード操作の詳細を確認できます。ローリングアップグレードを引き起こす最もよくあるエラーを次に示します。

RollingUpgradeInProgressWithFailedUpgradedVMs

VM エラーに対してエラーがトリガーされます。
詳細なエラーメッセージには、構成されたしきい値に基づいてロールアウトを続行または一時停止するかどうかが示されます。

MaxUnhealthyUpgradedInstancePercentExceededInRollingUpgrade

アップグレードされた VM の割合が、異常な VM で許可されている最大しきい値を超えると、エラーがトリガーされます。
詳細なエラーメッセージでは、異常な VM の原因となる最も一般的なエラーが集計されます。「MaxUnhealthyUpgradedInstancePercent」を参照してください。

MaxUnhealthyInstancePercentExceededInRollingUpgrade

異常な VM の割合が、アップグレード中に異常な VM で許可されている最大しきい値を超えると、エラーがトリガーされます。
詳細なエラーメッセージには、現在の異常の割合と、許容可能な構成済みの異常な VM の割合が表示されます。「maxUnhealthyInstancePercent」を参照してください。

MaxUnhealthyInstancePercentExceededBeforeRollingUpgrade

異常な VM の割合が、アップグレードの実行前に異常な VM で許可されている最大しきい値を超えると、エラーがトリガーされます。
詳細なエラーメッセージには、現在の異常の割合と、許容可能な構成済みの異常な VM の割合が表示されます。「maxUnhealthyInstancePercent」を参照してください。

InternalExecutionError

実行中に、未処理、書式設定されていない、または予期しない状態が発生すると、エラーがトリガーされます。
詳細のエラーメッセージに、エラーの原因が表示されます。

RollingUpgradeTimeoutError

ローリングアップグレードプロセスがタイムアウトすると、エラーがトリガーされます。
詳細なエラーメッセージには、更新を試みた後でシステムがタイムアウトした時間の長さが表示されます。

次のステップ

アプリケーション正常性拡張機能について確認する

次の方法で共有

Azure 仮想マシンスケールセットによる自動的な OS イメージのアップグレード

OS イメージの自動アップグレードのしくみ

可用性優先の更新

スケールセット内の VM のアップグレード

OS イメージのアップグレードと再イメージ化

サポート対象の OS イメージ

OS イメージの自動アップグレードを構成するための要件

Service Fabric の要件

カスタムイメージの OS イメージの自動アップグレード

カスタムイメージのその他の要件

OS イメージの自動アップグレードの構成

REST API

Azure PowerShell

Azure CLI 2.0

ARM テンプレート

Bicep

アプリケーション正常性拡張機能の使用

スケールセットに関するアプリケーション正常性プローブとしてのカスタムロードバランサープローブの構成

アプリケーション正常性拡張機能の使用

OS イメージの自動アップグレードの履歴を取得する

資格情報を最新に保つ

REST API

Azure PowerShell

Azure CLI 2.0

プラットフォーム OS イメージの最新バージョンを取得する方法

REST API

Azure PowerShell

Azure CLI 2.0

OS イメージのアップグレードを手動でトリガーする

REST API

Azure PowerShell

Azure CLI 2.0

アップグレード通知と分析情報にアクティビティログを活用する

アクティビティログアラートのアクショングループの設定

自動アップグレードエラーを調査して解決する

次のステップ

フィードバック

その他のリソース

次の方法で共有

Azure 仮想マシン スケール セットによる自動的な OS イメージのアップグレード

OS イメージの自動アップグレードのしくみ

可用性優先の更新

スケール セット内の VM のアップグレード

OS イメージのアップグレードと再イメージ化

サポート対象の OS イメージ

OS イメージの自動アップグレードを構成するための要件

Service Fabric の要件

カスタム イメージの OS イメージの自動アップグレード

カスタム イメージのその他の要件

OS イメージの自動アップグレードの構成

REST API

Azure PowerShell

Azure CLI 2.0

ARM テンプレート

Bicep

アプリケーション正常性拡張機能の使用

スケール セットに関するアプリケーション正常性プローブとしてのカスタム ロード バランサー プローブの構成

アプリケーション正常性拡張機能の使用

OS イメージの自動アップグレードの履歴を取得する

資格情報を最新に保つ

REST API

Azure PowerShell

Azure CLI 2.0

プラットフォーム OS イメージの最新バージョンを取得する方法

REST API

Azure PowerShell

Azure CLI 2.0

OS イメージのアップグレードを手動でトリガーする

REST API

Azure PowerShell

Azure CLI 2.0

アップグレード通知と分析情報にアクティビティ ログを活用する

アクティビティ ログ アラートのアクション グループの設定

自動アップグレード エラーを調査して解決する

次のステップ

フィードバック

その他のリソース

Azure 仮想マシンスケールセットによる自動的な OS イメージのアップグレード

スケールセット内の VM のアップグレード

カスタムイメージの OS イメージの自動アップグレード

カスタムイメージのその他の要件

スケールセットに関するアプリケーション正常性プローブとしてのカスタムロードバランサープローブの構成

アップグレード通知と分析情報にアクティビティログを活用する

アクティビティログアラートのアクショングループの設定

自動アップグレードエラーを調査して解決する