Azure 虚拟机规模集自动 OS 映像升级

项目
10/30/2024

注意

本文档中列出的许多步骤都适用于使用统一业务流程模式的虚拟机规模集。建议对新工作负载使用灵活业务流程。有关详细信息，请参阅 Azure 中虚拟机规模集的业务流程模式。

在规模集中启用自动 OS 映像升级有助于简化更新管理，这样可以安全自动升级规模集中所有实例的 OS 磁盘。

自动 OS 升级具有以下特征：

配置后，映像发布者发布的最新 OS 映像将自动应用于规模集，无需用户干预。
每次发布者发布新映像时，以滚动方式分批升级实例。
与应用程序运行状况探测和应用程序运行状况扩展集成。
适用于所有 VM 大小以及 Windows 和 Linux 映像，包括通过 Azure Compute Gallery 获取的自定义映像。
可以随时取消自动升级（也可以手动启动 OS 升级）。
VM 的 OS 磁盘将被替换为使用最新映像版本创建的新 OS 磁盘。运行配置的扩展和自定义数据脚本，同时保留永久性数据磁盘。
支持扩展定序。
可在任意大小的规模集上启用。

注意

在启用自动 OS 映像升级之前，请查看本文档的要求部分。

自动 OS 映像升级的工作原理是什么？

升级的工作原理是将 VM 的 OS 磁盘替换为使用此映像版本创建的新磁盘。所配置的任何扩展和自定义数据脚本将在 OS 磁盘上运行，同时保留数据磁盘。为了尽量减少应用程序停机时间，将分批进行升级，在任一时间，规模集内正在进行升级的计算机不会超过 20%。

必须集成 Azure 负载均衡器应用程序运行状况探测或应用程序运行状况扩展，才能在升级后跟踪应用程序的运行状况。通过此操作，平台可以验证 VM 运行状况，以确保以安全的方式应用更新。我们建议整合应用程序检测信号来验证升级是否成功。

可用性优先更新

下面所述的用于平台协调式更新的可用性优先模型可确保在多个可用性级别遵循 Azure 中的可用性配置。

跨区域：

更新将以分阶段的方式在整个 Azure 中全局推进，以防出现 Azure 范围的部署失败。
一个“阶段”可以涵盖一个或多个区域，仅当前一阶段中符合条件的 VM 成功更新时，更新才会进入下一阶段。
地理配对的区域不会并发更新，因此它们不能处于同一区域阶段。
更新是否成功是通过跟踪 VM 在更新后的运行状况来衡量的。

在区域内部：

位于不同 Azure 可用性区域中的 VM 不会使用同一更新同时进行更新。

在“集”内部：

公用规模集中的所有 VM 不会同时更新。
公用虚拟机规模集中的 VM 将分组成批，并在更新域边界内更新，如下所述。

将会遵循平台协调式更新过程每月推出受支持的 OS 平台映像升级。对于通过 Azure Compute Gallery 获取的自定义映像，仅当已将新映像发布并复制到该规模集的区域时，才为特定的 Azure 区域启动映像升级。

升级规模集中的 VM

规模集的区域可以通过适用于平台映像的可用性优先过程或者通过复制共享映像库的新自定义映像版本来获取映像升级。然后，按如下所述将映像升级分批应用于单个规模集：

在开始升级过程之前，业务流程协调程序将确保整个规模集中（出于任何原因）不正常的实例不会超过 20%。
升级业务流程协调程序会标识要升级的 VM 实例的批，其中任何一个批最多可以包括占实例总数的 20% 的实例，具体取决于一个虚拟机的最小批大小。没有最小规模集大小的要求，包含 5 个或更少实例的规模集的每个升级批包含 1 个 VM（最小批大小）。
所选升级批中每个 VM 的 OS 磁盘将替换为根据此映像创建的新 OS 磁盘。规模集模型中的所有指定扩展和配置都将应用于已升级的实例。
对于配置了应用程序运行状况探测或应用程序运行状况扩展的规模集，升级最多等待 5 分钟来等待实例变得正常，然后继续升级下一批。如果实例在升级后 5 分钟内未恢复其运行状况，则默认情况下将还原该实例先前的 OS 磁盘。
升级业务流程协调程序还会跟踪升级后不正常的实例百分比。如果升级过程中超过 20% 的已升级实例变得不正常，升级将会停止。
上述过程会持续到升级了规模集中的所有实例为止。

规模集 OS 升级业务流程协调程序在升级每个批之前会检查规模集总体运行状况。升级某一批时，可能有其他并发的计划内或计划外维护活动影响规模集实例的运行状况。在这种情况下，如果超过 20% 的规模集实例不正常，则当前批结束时，规模集升级将会停止。

若要修改与滚动升级关联的默认设置，请查看 Azure 的滚动升级策略。

注意

自动 OS 升级不会升级规模集上的引用映像 SKU。要更改 SKU（例如将 Ubuntu 18.04-LTS 更改为 20.04-LTS），必须直接通过所需的映像 SKU 更新规模集模型。无法更改现有规模集的映像发布者和产品/服务。

操作系统映像升级与重置映像

操作系统映像升级和重置映像都是用于更新规模集中虚拟机的方法，但它们具有不同的用途和不同的影响。

操作系统映像升级涉及更新用于在规模集中创建新实例的基础操作系统映像。执行操作系统映像升级时，Azure 将使用更新后的操作系统映像创建新虚拟机实例，并逐步将规模集中的旧虚拟机实例替换为新实例。此过程通常分阶段执行，以确保高可用性。操作系统映像升级是一种无中断的方式，可将更新或更改应用于规模集中虚拟机的基础操作系统。现有虚拟机实例在替换为新实例之前不会受到影响。

重新映像规模集中的虚拟机实例是一种更直接、更具破坏性的操作。选择重置虚拟机实例映像时，Azure 将停止所选虚拟机实例，执行重置映像操作，然后使用同一操作系统映像重启虚拟机。这将有效地在特定虚拟机实例上重新安装操作系统。当由于虚拟机实例出现问题而需要排除故障或重置时，通常会使用重置映像。

主要区别：

操作系统映像升级是一个渐进且无中断的过程，随着时间的推移，会更新整个虚拟机规模集的操作系统映像，确保对正在运行的工作负载的影响降至最低。
重置映像是一种更直接、更具破坏性的操作，它仅影响选定的虚拟机实例，暂时停止它并重新安装操作系统。

每种方法的使用时机：

如果要更新整个规模集的操作系统映像，同时保持高可用性，请使用操作系统映像升级。
如果要对虚拟机规模集内的特定虚拟机实例排除故障或重置，请使用重置映像。

必须根据具体要求仔细计划和选择适当的方法，以尽量减少对虚拟机规模集中运行的应用程序和服务造成的任何中断。

支持的 OS 映像

当前仅支持特定 OS 平台映像。如果规模集使用通过 Azure Compute Gallery 获取的自定义映像，则该映像受支持。

目前支持以下平台 SKU（我们会定期添加更多 SKU）：

发布者	OS 产品/服务	SKU
Canonical	UbuntuServer	18.04-LTS
Canonical	UbuntuServer	18_04-LTS-Gen2
Canonical	0001-com-ubuntu-server-focal	20_04-LTS
Canonical	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 映像升级时的要求

映像的版本属性必须设置为“最新”。
必须对非 Service Fabric 规模集使用应用程序运行状况探测或应用程序运行状况扩展。有关 Service Fabric 要求，请参阅 Service Fabric 要求。
请使用计算 API 版本 2018-10-01 或更高版本。
确保规模集模型中指定的外部资源可用且已更新。示例包括，VM 扩展属性中用于引导有效负载的 SAS URI、存储帐户中的有效负载、对模型中的机密的引用，等等。
对于使用 Windows 虚拟机的规模集，从计算 API 版本 2019-03-01 开始，在规模集模型定义中，必须将“virtualMachineProfile.osProfile.windowsConfiguration.enableAutomaticUpdates”属性设置为“false”。 enableAutomaticUpdates 属性启用 VM 内部修补，其中的“Windows 更新”将应用操作系统补丁但不替换 OS 磁盘。在规模集上启用 OS 映像自动升级（可以通过将 automaticOSUpgradePolicy.enableAutomaticOSUpgrade 设置为 true 来实现）后，不需要通过 Windows 更新执行额外的修补过程。
在规模集模型定义中，“修补程序业务流程模式”不得设置为 AutomaticByPlatform。在规模集上启用自动操作系统映像升级后，不需要平台编排修补流程。

注意

通过重置映像或升级替换 OS 磁盘后，附加的数据磁盘可能会重新分配其驱动器号。要为附加的磁盘保留相同的驱动器号，建议使用自定义启动脚本。

Service Fabric 要求

如果使用的是 Service Fabric，请确保满足以下条件：

Service Fabric 持久性级别为 Silver 或 Gold。如果 Service Fabric 持久性为 Bronze，则只有无状态节点类型支持自动 OS 映像升级。
根据规模集模型定义，Service Fabric 扩展必须具有 TypeHandlerVersion 1.1 或更高版本。
根据规模集模型定义，Service Fabric 群集与 Service Fabric 扩展的持久性级别应相同。
对于银级或金级持久性层，不需要额外的运行状况探测或使用应用程序运行状况扩展。仅限无状态节点类型的铜级持久性层需要额外的运行状况探测。
在规模集模型定义中，virtualMachineProfile.osProfile.windowsConfiguration.enableAutomaticUpdates 属性必须设置为 false 。 enableAutomaticUpdates 属性启用通过“Windows 更新”进行的 VM 内部修补，在 Service Fabric 规模集上不受支持。你应当改用 automaticOSUpgradePolicy.enableAutomaticOSUpgrade 属性。

请确保 Service Fabric 群集与 Service Fabric 扩展上的持久性设置匹配，因为不匹配将导致升级错误。可以通过此页上概述的指导原则来修改持久性级别。

自定义映像的 OS 映像自动升级

通过 Azure Compute Gallery 部署的自定义映像支持 OS 映像自动升级。 OS 映像自动升级不支持其他自定义映像。

自定义映像的其他要求

对于所有规模集，用于 OS 映像自动升级的安装和配置过程均相同，如此页的配置部分中所述。
发布映像的新版本映像，并将其复制到该规模集的区域时，为 OS 映像自动升级配置的规模集实例将升级到 Azure Compute Gallery 映像版本。如果新映像未复制到部署缩放的区域，则规模集实例将不会升级到此版本。区域映像复制使你可控制规模集的新映像的推出。
不应从该库映像的版本中排除新映像版本。从库映像的版本中排除的映像版本不会通过 OS 映像自动升级向规模集推出。

注意

由于维护时段或其他限制等特定因素，首次为 OS 自动升级配置规模集之后，规模集最多可能需要 3 小时才能触发首次映像升级推出。在新映像可用之前，使用最新映像的客户可能无法进行升级。

配置自动 OS 映像升级

若要配置自动 OS 映像升级，请确保在规模集模型定义中将 automaticOSUpgradePolicy.enableAutomaticOSUpgrade 属性设置为 true。

注意

升级策略模式和自动操作系统升级策略是两个单独的设置，可控制规模集的不同方面。当规模集模板发生更改时，升级策略 mode 将确定规模集的现有实例会发生什么情况。但是，自动操作系统升级策略 enableAutomaticOSUpgrade 是特定于操作系统映像的，将跟踪映像发布者所做的更改，并确定更新映像时会发生什么情况。

注意

如果 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

使用 New-AzVmss cmdlet 配置在预配过程中为规模集自动升级 OS 映像。以下示例为 myResourceGroup 资源组中的 myScaleSet 规模集配置自动升级：

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

使用 Update-AzVmss cmdlet 配置为现有规模集自动升级 OS 映像。以下示例为 myResourceGroup 资源组中的 myScaleSet 规模集配置自动升级：

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

Azure CLI 2.0

使用 az vmss create 配置在预配过程中为规模集自动升级 OS 映像。使用 Azure CLI 2.0.47 或更高版本。以下示例为 myResourceGroup 资源组中的 myScaleSet 规模集配置自动升级：

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

使用 az vmss update 配置为现有规模集自动升级 OS 映像。使用 Azure CLI 2.0.47 或更高版本。以下示例为 myResourceGroup 资源组中的 myScaleSet 规模集配置自动升级：

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

注意

为规模集配置 OS 映像自动升级后，如果规模集使用“手动”升级策略，则还必须将规模集 VM 引入最新的规模集模型。

ARM 模板

以下示例介绍如何通过 Azure 资源管理器模板 (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 实例每次只升级一批。只有客户应用程序在升级后的 VM 实例上正常运行时，才会继续升级。建议应用程序向规模集 OS 升级引擎提供运行状况信号。默认情况下，在 OS 升级期间，平台根据 VM 电源状态和扩展预配状态确定升级后 VM 实例是否正常运行。在 VM 实例的 OS 升级期间，VM 实例上的 OS 磁盘被替换为基于最新版本映像的新磁盘。 OS 升级完毕后，配置的扩展在这些 VM 上运行。仅当已成功预配实例上的所有扩展时，才将应用程序视为正常。

可以选择为规模集配置应用程序运行状况探测，用于为平台提供关于应用程序当前状态的准确信息。应用程序运行状况探测是用作运行状况信号的自定义负载均衡器探测。规模集 VM 实例上运行的应用程序可以响应外部的 HTTP 或 TCP 请求，指示其是否正常运行。若要详细了解自定义负载均衡器探测的工作原理，请参阅了解负载均衡器探测。 Service Fabric 规模集不支持应用程序运行状况探测。非 Service Fabric 规模集需要负载均衡器应用程序运行状况探测或应用程序运行状况扩展。

如果规模集配置为使用多个放置组，则探测需使用负载均衡器标准版。

注意

只能将一个运行状况监视源用于虚拟机规模集，即应用程序运行状况扩展或运行状况探测。如果启用这两个选项，则需要在使用实例修复或自动 OS 升级等业务流程服务之前移除一个。

在规模集上将自定义负载均衡器探测配置为应用程序运行状况探测

最佳做法是为规模集运行状况显式创建负载均衡器探测。运行状况探测可使用与现有 HTTP 探测或 TCP 探测相同的终结点，但所需的行为可能与传统负载均衡器探测不同。例如，如果实例的负载过高，传统负载均衡器探测可能返回“不正常”，但是，这不符合自动 OS 升级过程中实际的实例运行状况。请将探测配置为不超过两分钟的高探测速率。

可以在规模集的 networkProfile 中引用负载均衡器探测，并可将探测与内部或公共的负载均衡器相关联，如下所示：

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

注意

使用带 Service Fabric 的自动 OS 升级时，更新域将推出新的 OS 映像，以维持 Service Fabric 中运行的服务的高可用性。若要利用 Service Fabric 中的自动 OS 升级，必须将群集节点类型配置为使用白银持续性层或更高层级。对于青铜持续性层，只有无状态节点类型支持自动 OS 升级。有关 Service Fabric 群集的持续性特征的详细信息，请参阅此文档。

使用应用程序运行状况扩展

应用程序运行状况扩展部署在虚拟机规模集实例中，并从规模集实例中报告 VM 的运行状况。可以配置扩展，以探测应用程序终结点并更新该实例上应用程序的状态。 Azure 会检查此实例状态，以确定实例是否符合升级操作的条件。

因为扩展从 VM 中报告运行状况，所以扩展可在无法利用外部探测（例如使用自定义 Azure 负载均衡器探测的应用程序运行状况探测）的情况下使用。

可以使用多种方法将应用程序运行状况扩展部署到规模集，如此文中的示例所详述。

注意

获取自动 OS 映像升级的历史记录

可以使用 Azure PowerShell、Azure CLI 2.0 或 REST API 检查在规模集上执行的最新 OS 升级的历史记录。可以获取过去两个月内最近五次 OS 升级尝试的历史记录。

请使凭据保持最新

如果规模集使用任何凭据访问外部资源（例如进行配置以使用 SAS 令牌访问存储帐户的 VM 扩展），请确保凭据保持最新。如果任何凭据（包括证书和令牌）过期，则升级将失败，并且第一批 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": "chinanorth2"
    }
  ]
}

Azure PowerShell

使用 Get-AzVmss cmdlet 检查规模集的 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 "chinanorth2" -PublisherName "Canonical" -offer "0001-com-ubuntu-server-jammy" -sku "22_04-lts"

Azure CLI 2.0

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

手动触发 OS 映像升级

在规模集上启用 OS 映像自动升级后，无需在规模集上手动触发映像更新。无需任何手动干预，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

使用 Start-AzVmssRollingOSUpgrade cmdlet 检查规模集的 OS 升级历史记录。以下示例详细说明如何在 myResourceGroup 资源组中的 myScaleSet 规模集上启动 OS 滚动升级：

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

Azure CLI 2.0

使用 az vmss rolling-upgrade start 检查规模集的 OS 升级历史记录。使用 Azure CLI 2.0.47 或更高版本。以下示例详细说明如何在 myResourceGroup 资源组中的 myScaleSet 规模集上启动 OS 滚动升级：

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

利用活动日志获得升级通知和见解

Azure 活动日志是一种方便用户深入了解 Azure 中发生的订阅级别事件的订阅日志。客户能够：

查看 Azure 门户中与对其资源执行的操作相关的事件
创建操作组以优化电子邮件、短信、Webhook 或 ITSM 等通知方法
使用门户、ARM 资源模板、PowerShell 或 CLI 通过不同的条件设置适当的警报，以便将警报发送到操作组

客户将收到与操作系统自动升级操作相关的三种类型的通知：

提交特定资源的升级请求
提交请求的结果以及任何错误详细信息
升级完成的结果以及任何错误详细信息

为活动日志警报设置操作组

操作组是由 Azure 订阅的所有者定义的通知首选项的集合。 Azure Monitor 和服务运行状况警报使用操作组来通知用户某个警报已触发。

可以使用以下方式创建和管理操作组：

客户可以使用操作组设置以下项：

短信和/或电子邮件通知
Webhook - 客户可以将 Webhook 附加到其自动化 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 映像升级时的要求

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

利用活动日志获得升级通知和见解

为活动日志警报设置操作组

调查并解决自动升级错误

后续步骤

其他资源