Azure 虛擬機器擴展集的 OS 映像自動升級

發行項
04/29/2024

注意

本文件所列的許多步驟，適用於使用統一協調流程模式的虛擬機器擴展集。我們建議針對新的工作負載使用彈性協調流程。如需詳細資訊，請參閱 Azure 中虛擬機器擴展集的協調流程模式。

在擴展集上啟用 OS 映像自動升級，可藉由為擴展集內的所有執行個體安全且自動地升級 OS 磁碟，來協助您簡化更新的管理。

作業系統自動升級具有下列特性︰

一旦設定之後，映像發行者所發行的最新作業系統映像便會自動套用至擴展集，完全不需要使用者介入。
每次發行者發行新的映像時，都會以循環方式批次升級執行個體。
會與應用程式健康情況探查和應用程式健康情況擴充功能整合。
適用於所有 VM 大小和 Windows 與 Linux 映像，包含透過 Azure Compute Gallery 的自訂映像。
您可以隨時選擇不自動升級 (您也可以手動起始作業系統升級)。
VM 的作業系統磁碟會取代為使用最新映像版本建立的新作業系統磁碟。系統會執行已設定的延伸模組和自訂資料指令碼，同時保留已保存的資料磁碟。
支援擴充功能排序。
可在任何大小的擴展集上啟用。

注意

啟用自動 OS 映像升級之前，請檢查本文件的需求區段。

OS 映像自動升級工作進行的方式為何？

升級的運作方式是將 VM 的 OS 磁碟取代為使用映像版本所建立的新磁碟。任何已設定的擴充功能和自訂資料指令碼都會在 OS 磁碟上執行，同時保留資料磁碟。為了將應用程式停機時間降到最低，升級會分批進行，每次升級不會超過擴展集的 20%。

您可以整合 Azure Load Balancer 應用程式健全狀態探查或應用程式健康延伸模組，以在升級後追蹤應用程式的健全狀況。建議整合應用程式活動訊號以確認升級成功。

可用性優先更新

下述的平台可用性優先模型，確保在多個可用性層級中遵守 Azure 的可用性設定。

跨區域：

升級會以分階段的方式跨 Azure 全域移動，以防止整個 Azure 發生部署失敗。
「階段」可能會有一個或多個區域，而更新僅在前一階段符合資格的 VM 成功更新後，跨階段移動。
異地配對區域不會同時更新，亦不會在同一區域階段。
更新成功會以追蹤 VM 更新後的健全狀況來測量。

區域內：

不同可用性區域的 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 直接升級擴展集模型。映像發行者和供應無法在現有擴展集中變更。

OS 映像升級與重新安裝映像

OS 映像升級和重新安裝映像都是用來更新擴展集內 VM 的方法，但用途不同，且具有不同的影響。

OS 映像升級牽涉到更新在擴展集中用於建立新執行個體的基礎作業系統映像。當您執行 OS 映像升級時，Azure 會使用更新的 OS 映像來建立新的 VM 執行個體，並將擴展集的舊 VM 執行個體逐漸取代為新的執行個體。此流程通常會分階段執行，以確保高可用性。 OS 映像升級是將更新或變更套用至擴展集 VM 基礎 OS 的非干擾性方式。在取代為新的執行個體之前，現有 VM 執行個體都不會受到影響。

重新安裝擴展集 VM 執行個體的映像則是更立即且具干擾性的動作。當您選擇為 VM 執行個體重新安裝映像時，Azure 會停止選取的 VM 執行個體、執行重新安裝映像作業，然後使用相同的 OS 映像重新啟動 VM。此方法可高效地重新安裝該特定 VM 執行個體的 OS。當您因為執行個體發生問題，而需要為特定 VM 執行個體進行疑難排解或重設時，通常會採用重新安裝映像。

主要差異：

OS 映像升級是一個漸進且非干擾性的程式，可逐步更新整個虛擬機器擴展集的 OS 映像，確保讓執行工作負載的影響降到最低。
重新安裝映像是一個更立即且干擾性的動作，只會影響選取的 VM 執行個體、暫時停止並重新安裝 OS。

個別方法的使用時機：

如果要更新整個擴展集的 OS 映像，同時維持高可用性，請使用 OS 映像升級。
若要對虛擬機擴展集內的特定 VM 執行個體進行疑難排解或重設時，請使用重新安裝映像。

請務必根據您的具體需求仔細規劃，並選擇適當的方法，藉此將虛擬機擴展集所執行應用程式和服務的任何中斷降到最低。

支援的作業系統映像

目前僅支援特定的作業系統平台映像。若擴展集透過 Azure Compute Gallery 使用自訂映像，系統支援自訂映像。

目前支援下列平台 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

設定 OS 映像自動升級的需求

映像的版本屬性必須設定為 latest。
非 Service Fabric 的擴展集必須使用應用程式健康情況探查或應用程式健康情況擴充功能。如需了解 Service Fabric 需求，請參閱 Service Fabric 需求。
使用計算 API 2018-10-01 版或更高版本。
請確定擴展集模型中指定的外部資源可供使用且已更新。範例包括在 VM 擴充功能屬性中用於啟動承載的 SAS URI、儲存體帳戶中的承載，以及模型中祕密的參照等等。
在使用 Windows 虛擬機器的擴展集中開始使用計算 API 2019-03-01 版，在擴展集模型定義中 [virtualMachineProfile.osProfile.windowsConfiguration.enableAutomaticUpdates] 應設為 [否]。 [enableAutomaticUpdates] 屬性啟用 VM 內修補，而「Windows 更新」套用至作業系統修補，無須取代 OS 磁碟。透過在擴展集上啟用自動 OS 映像升級 (將 [automaticOSUpgradePolicy.enableAutomaticOSUpgrade] 設定為 true)，您便不需要透過 Windows Update 進行額外的修補程序。

注意

透過重新安裝映像或升級取代 OS 磁碟之後，連結的資料磁碟可能會重新指派其磁碟機代號。若要讓已連結磁碟保留原本的磁碟機代號，建議使用自訂開機指令碼。

Service Fabric 需求

若使用 Service Fabric，請確定符合下列條件：

Service Fabric 耐久性層級為銀級或金級。如果 Service Fabric 耐久性是銅級，則只有僅限無狀態節點類型支援自動 OS 映像升級。
擴展集模型定義的 Service Fabric 擴充功能必須為 TypeHandlerVersion 1.1 或以上。
在擴展集模型定義中，Service Fabric 叢集和 Service Fabric 擴充功能的持久性層級應相同。
銀級或金級持久性無須額外進行健全狀態探查或使用應用程式健康延伸模組。僅限無狀態節點類型的銅級持久性需要額外健全狀態探查。
[virtualMachineProfile.osProfile.windowsConfiguration.enableAutomaticUpdates] 屬性在擴展集模型定義中必須設定為 [否]。 [enableAutomaticUpdates] 屬性會使用「Windows Update」啟用 VM 內修補，且不在 Service Fabric 擴展集不支援。您應該改用 [automaticOSUpgradePolicy.enableAutomaticOSUpgrade] 屬性。

請確保 Service Fabric 叢集和 Service Fabric 擴充功能的持久性設定相符，因為不相符將導致升級發生錯誤。您可根據此頁面所述的指導方針來修改持久性層級。

自訂映像的自動 OS 映像升級

自動 OS 映像升級支援透過 Azure Compute Gallery 部署的自訂映像。自動 OS 映像升級不支援其他自訂映像。

自訂映像的其他需求

自動 OS 映像升級的設定和設定流程，與本頁設定章節中詳述的所有擴展集相同。
當新版本的映像發行並復寫至該擴展集的區域時，針對自動OS映像升級所設定的擴展集實例將會升級至 Azure 計算資源庫映像的版本。如果未將新映射複寫至部署調整的區域，則擴展集實例將不會升級至版本。區域映像複寫允許控制擴展集推出新映像。
不應該從該資源庫映像的版本排除新的映像版本。從資源庫映像版本排除的映像版本不會透過自動OS映射升級向擴展集推出。

注意

由於維護視窗或其他限制，擴展集第一次設定自動 OS 更新後，觸發第一次映像升級推出可能需要 3 個小時。在有新的映像可用之前，最新映像上的客戶可能無法升級。

設定 OS 映像自動升級

若要設定 OS 映像自動升級，請確定擴展集模型定義中的 automaticOSUpgradePolicy.enableAutomaticOSUpgrade 屬性是設為 true。

注意

升級原則模式與自動 OS 升級原則為個別設定，並控制擴展集的不同層面。擴展集範本有所變更時，升級原則mode會決定擴展集內執行個體會發生什麼情況。然而，映像有所更新時，自動 OS 升級原則enableAutomaticOSUpgrade專屬 OS 映像，並追蹤映像發行者所做的變更，再決定會發生什麼情況。

注意

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

使用應用程式健康狀態探查

在作業系統升級期間，擴展集中的 VM 執行個體一次升級一個批次。只有客戶應用程式在已升級的 VM 執行個體上狀況良好時，升級才應該繼續。建議應用程式向擴展集的作業系統升級引擎提供健康情況訊號。根據預設，平台在作業系統升級期間會考慮 VM 電源狀態和延伸模組佈建狀態，以判斷 VM 執行個體在升級之後是否狀況良好。在 VM 執行個體的作業系統升級期間，VM 執行個體上的作業系統磁碟會根據最新的映像版本，取代為新的磁碟。作業系統升級完成後，已設定的延伸模組便會在這些 VM 上執行。只有在執行個體上的所有擴充功能都成功佈建之後，系統才會認為應用程式的狀況良好。

您可以使用應用程式健康情況探查選擇性地設定擴展集，以便為平台提供精確的應用程式持續狀態的相關資訊。應用程式健康情況探查是當作健康情況訊號使用的自訂負載平衡器探查。在擴展集 VM 執行個體上執行的應用程式可以回應外部 HTTP 或 TCP 要求，以指出它是否狀況良好。如需有關自訂負載平衡器探查運作方式的詳細資訊，請參閱了解負載平衡器探查。 Service Fabric 擴展集不支援應用程式健全狀態探查。非 Service Fabric 的擴展集需要使用 Load Balancer 應用程式健康情況探查或應用程式健康情況擴充功能。

如果擴展集設定為使用多個放置群組，則需要用到使用標準負載平衡器的探查。

注意

虛擬機器擴展集只能使用一個狀況監控來源，也就是應用程式健康情況擴充功能或健全狀態探查。如果您已啟用這兩個選項，您必須先移除一個選項，才能使用執行個體修復或自動 OS 升級等協調流程服務。

將自訂負載平衡器探查設定為擴展集上的應用程式健康情況探查

最佳作法是，針對擴展集健康情況明確地建立負載平衡器探查。系統可針對現有的 HTTP 探查或 TCP 探查使用相同的端點，但健康情況探查可能會需要不同於傳統負載平衡器探查的行為。例如，如果執行個體的負載太高，傳統負載平衡器探查可能會傳回狀況不良，但可能不適用於判斷作業系統自動升級期間的執行個體健康情況。將探查設定為具有不到兩分鐘的高探查率。

您可以在擴展集的 networkProfile 中參考負載平衡器探查，而且可以與對內或對外公開的負載平衡器建立關聯，如下所示：

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

注意

搭配 Service Fabric 使用自動 OS 升級時，新的 OS 映像將以更新網域對更新網域的方式推出，以維持在 Service Fabric 中執行之服務的高可用性。若要在 Service Fabric 中利用自動 OS 升級，您的叢集節點類型必須設定為使用銀級耐久性層或更高。針對銅級持久性層，僅限無狀態節點類型才支援自動 OS 映像升級。如需 Service Fabric 叢集持久性特性的詳細資訊，請參閱這份文件。

保持認證為最新狀態

如果您的擴展集使用任一認證來存取外部資源，例如如果已設定的 VM 擴充功能針對儲存體帳戶使用 SAS 權杖，則請確定認證已更新。如果包括憑證和權杖的任何認證已過期，升級將會失敗，第一批的 VM 將會是失敗狀態。

資源驗證失敗時，復原 VM 並重新啟用自動 OS 升級的建議步驟如下：

重新產生傳遞至擴充功能的權杖 (或任何其他認證)。
請確認從 VM 內用來向外部實體通訊的任何認證是最新狀態。
將擴展集模型中的擴充功能更新為任一新權杖。
部署更新的擴展集，這會更新所有 VM 執行個體，包括失敗的 VM 執行個體。

使用應用程式健康情況擴充功能

應用程式健康狀態延伸模組會部署在虛擬機器擴展集執行個體內部，並從擴展集執行個體內部報告 VM 健康狀態。您可以將延伸模組設定為在應用程式端點上探查，並更新該執行個體上的應用程式狀態。 Azure 會檢查此執行個體狀態，以判斷執行個體是否適合進行升級作業。

因為此擴充功能是從 VM 內報告健康情況，所以在無法使用應用程式健康情況探查 (其利用自訂的 Azure Load Balancer 探查) 等外部探查的情況下，可以使用此擴充功能。

有多種方法可以將應用程式健康情況擴充功能部署至您的擴展集，如這篇文章中的範例所詳述。

注意

取得 OS 映像自動升級的記錄

您可以使用 Azure PowerShell、Azure CLI 2.0 或 REST API，檢查您擴展集上最近執行之 OS 升級的記錄。您可以取得過去兩個月內的最近五次 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 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 "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 映像升級。

注意

作業系統映像升級的手動觸發程式不提供自動復原功能。若執行個體在升級作業後未復原其健全狀態，則無法還原其先前的 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"

調查並解決自動升級錯誤

在使用輪流升級原則執行自動映像升級時，平台可能會在 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

調查並解決自動升級錯誤

下一步

其他資源