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

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

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

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

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

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

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

可用性優先の更新

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

複数のリージョン間:

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

リージョン内:

• 異なる Availability Zones にある仮想マシンは、同じ更新で同時に更新されることはありません。

"セット" 内:

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

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

スケール セット内の仮想マシンのアップグレード

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

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

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

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

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

スケール セット内の仮想マシンの更新に使用される方法には、 OS イメージのアップグレード と 再イメージ化 の両方がありますが、いずれも異なる目的があり、明確な影響を及ぼします。

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

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

主な相違点:

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

各方法を使用するタイミング:

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

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

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

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

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

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

• イメージの バージョン プロパティを最新に設定する必要があります。
• Service Fabric 以外のスケール セットには、アプリケーション正常性プローブまたはアプリケーション正常性拡張機能を使用する必要があります。 Service Fabric の要件については、「Service Fabric の要件」を参照してください。
• コンピューティング API バージョン 2018-10-01 以降を使用します。
• スケール セット モデルで指定された外部リソースが利用可能であり、更新可能であることを確認してください。 例としては、仮想マシン拡張機能プロパティ内のブートストラップ ペイロードの 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 イメージの自動アップグレードが有効になっている場合、プラットフォームのオーケストレーション パッチ適用プロセスは必要ありません。

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 イメージの自動アップグレードによってスケール セットにロールアウトされません。

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

OS イメージの自動アップグレードを構成するには、スケール セットのモデル定義で automaticOSUpgradePolicy.enableAutomaticOSUpgrade プロパティが 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

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

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

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

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

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

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

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

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

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

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

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

Virtual Machine Scale Sets 上でローリング アップグレードのカスタム メトリックを構成する (プレビュー)

ローリング アップグレードのカスタム メトリックを使用すると、アプリケーション正常性拡張機能を利用して、仮想マシン スケール セットにカスタム メトリックを出力できるようになります。 これらのカスタム メトリックを使用して、ローリング アップグレードがトリガーされた際に仮想マシンを更新する順序をスケール セットに指示できます。 カスタム メトリックは、特定のインスタンス上でアップグレードをスキップする必要がある場合に、そのスケール セットに通知することもできます。 これにより、順序付けと更新プロセス自体を、より詳細に制御できます。

カスタム メトリックは、 OS の自動アップグレード、 自動拡張機能アップグレード 、 MaxSurge ローリング アップグレードなど、他のローリング アップグレード機能と組み合わせて使用できます。

詳細については、 Virtual Machine Scale Sets でのローリング アップグレードのカスタム メトリックを参照してください

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

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

資格情報を最新に保つ

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

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

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

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 イメージのアップグレードを手動でトリガーできます。

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 のアラートでは、アクション グループを使用して、アラートがトリガーされたことをユーザーに通知します。

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

• ARM Resource Manager
• Portal
• PowerShell:
  • New-AzActionGroup
  • Get-AzActionGroup
  • Remove-AzActionGroup
• CLI

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

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

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

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

RollingUpgradeInProgressWithFailedUpgradedVMs

• 仮想マシンで障害が発生すると、エラーがトリガーされます。
• 詳細なエラー メッセージには、構成されたしきい値に基づいて、ロールアウトを続行するか、または一時停止するかが記載されています。

MaxUnhealthyUpgradedInstancePercentExceededInRollingUpgrade

• アップグレード済み仮想マシンの割合が、異常な仮想マシンに対して許容される最大しきい値を超えると、エラーがトリガーされます。
• 詳細なエラー メッセージには、異常な仮想マシンの原因となる最も一般的なエラーがまとめられます。 MaxUnhealthyUpgradedInstancePercentを参照してください。

MaxUnhealthyInstancePercentExceededInRollingUpgrade

• アップグレード中に、異常な仮想マシンの割合が許容される最大しきい値を超えると、エラーがトリガーされます。
• 詳細なエラー メッセージには、現在の異常な仮想マシンの割合と、構成された許容範囲内の異常な仮想マシンの割合が表示されます。 maxUnhealthyInstancePercentを参照してください。

MaxUnhealthyInstancePercentExceededBeforeRollingUpgrade

• アップグレードの開始前に、異常な仮想マシンの割合が許容される最大しきい値を超えると、エラーがトリガーされます。
• 詳細なエラー メッセージには、現在の異常な仮想マシンの割合と、構成された許容範囲内の異常な仮想マシンの割合が表示されます。 maxUnhealthyInstancePercentを参照してください。

InternalExecutionError

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

RollingUpgradeTimeoutError

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

次のステップ