訓練
學習路徑
Use advance techniques in canvas apps to perform custom updates and optimization - Training
Use advance techniques in canvas apps to perform custom updates and optimization
注意
本文件所列的許多步驟,適用於使用統一協調流程模式的虛擬機器擴展集。 我們建議針對新的工作負載使用彈性協調流程。 如需詳細資訊,請參閱 Azure 中虛擬機器擴展集的協調流程模式。
在擴展集上啟用 OS 映像自動升級,可藉由為擴展集內的所有執行個體安全且自動地升級 OS 磁碟,來協助您簡化更新的管理。
作業系統自動升級具有下列特性︰
注意
啟用自動 OS 映像升級之前,請檢查本文件的需求區段。
升級的運作方式是將虛擬機的OS磁碟取代為使用映像版本建立的新磁碟。 任何已設定的擴充功能和自訂資料指令碼都會在 OS 磁碟上執行,同時保留資料磁碟。 為了將應用程式停機時間降到最低,升級會分批進行,每次升級不會超過擴展集的 20%。
您必須整合 Azure Load Balancer 應用程式健全狀態探查或應用程式健康延伸模組,以在升級後追蹤應用程式的健全狀況。 這可讓平臺驗證虛擬機健康情況,以確保以安全的方式套用更新。 建議整合應用程式活動訊號以確認升級成功。
下述的平台可用性優先模型,確保在多個可用性層級中遵守 Azure 的可用性設定。
跨區域:
區域內:
「集合」內:
系統會遵循協調更新流程的平台,以每月推出支援作 OS 的平台映像升級。 針對透過 Azure Compute Gallery 的自訂映像,僅在發佈新映像和複寫至擴展集的特定 Azure 區域時,進行該區域的映像升級。
擴展集的區域透過平台映像的可用性優先流程,或者為共用映像資源庫複寫新的自訂映像版本,符合取得映像版本的資格。 映像升級再依批次方式套用至個別擴展集,如下:
擴展集的 OS 升級協調器在升級每個批次之前,都會先檢查整體的擴展集健康情況。 在升級某個批次時,可能會有其他計劃性或非計劃性維護活動也在並行執行,而影響到擴展集執行個體的健康情況。 在此情況下,如果擴展集的執行個體有超過 20% 變得狀況不良,則擴展集升級程序會在當前的批次結束時停止。
若要修改輪流升級相關聯的預設設定,請檢閱 Azure 的輪流升級原則。
注意
自動 OS 升級不會升級擴展集上的參考映像 SKU。 若要變更 SKU (如 Ubuntu 18.04-LTS 至 20.04-LTS),您必須使用所需的映像 SKU 直接升級擴展集模型。 映像發行者和供應無法在現有擴展集中變更。
OS 映射升級和 Reimage 都是用來更新擴展集內虛擬機的方法,但是它們有不同的用途,而且具有不同的影響。
OS 映像升級牽涉到更新在擴展集中用於建立新執行個體的基礎作業系統映像。 當您執行 OS 映射升級時,Azure 會使用更新的 OS 映射來建立新的虛擬機,並逐漸將擴展集中的舊虛擬機取代為新的虛擬機。 此流程通常會分階段執行,以確保高可用性。 OS 映射升級是將更新或變更套用至擴展集中虛擬機基礎OS的非干擾性方式。 現有的虛擬機在以新的實例取代之前不會受到影響。
重新映像擴展集中的虛擬機是更立即且干擾性的動作。 當您選擇重新映像虛擬機時,Azure 會停止選取的虛擬機、執行重新安裝映像作業,然後使用相同的 OS 映像重新啟動虛擬機。 這可有效地在該特定虛擬機上重新安裝 OS。 當您需要針對特定虛擬機進行疑難解答或重設,因為該實例發生問題時,通常會使用重新映像。
主要差異:
個別方法的使用時機:
請務必根據您的具體需求仔細規劃,並選擇適當的方法,藉此將虛擬機擴展集所執行應用程式和服務的任何中斷降到最低。
目前僅支援特定的作業系統平台映像。 若擴展集透過 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 |
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 |
AutomaticByPlatform
。 在擴展集上啟用自動OS映射升級時,不需要平臺協調流程修補程式。注意
透過重新安裝映像或升級取代 OS 磁碟之後,連結的資料磁碟可能會重新指派其磁碟機代號。 若要讓已連結磁碟保留原本的磁碟機代號,建議使用自訂開機指令碼。
若使用 Service Fabric,請確定符合下列條件:
確定 Service Fabric 叢集和 Service Fabric 擴充功能上的持久性設定不相符,因為不相符會導致升級錯誤。 您可根據此頁面所述的指導方針來修改持久性層級。
自動 OS 映像升級支援透過 Azure Compute Gallery 部署的自訂映像。 自動 OS 映像升級不支援其他自訂映像。
注意
由於維護視窗或其他限制,擴展集第一次設定自動 OS 更新後,觸發第一次映像升級推出可能需要 3 個小時。 在有新的映像可用之前,最新映像上的客戶可能無法升級。
若要設定 OS 映像自動升級,請確定擴展集模型定義中的 automaticOSUpgradePolicy.enableAutomaticOSUpgrade 屬性是設為 true。
注意
升級原則模式與自動 OS 升級原則為個別設定,並控制擴展集的不同層面。 當擴展集範本中有變更時,升級原則 mode
會決定擴展集中現有實例會發生什麼情況。 然而,映像有所更新時,自動 OS 升級原則enableAutomaticOSUpgrade
專屬 OS 映像,並追蹤映像發行者所做的變更,再決定會發生什麼情況。
注意
如果 enableAutomaticOSUpgrade
設定為 true,則 enableAutomaticUpdates
會自動設定為 false,且無法設定為 true。
下列範例說明如何設定擴展集模型上的 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
}
}
}
}
使用 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
使用 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映射升級之後,如果您的擴展集使用「手動」 升級原則,您也必須將擴展集虛擬機帶入最新的擴展集模型。
下列範例說明如何透過 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 在擴展集模型上設定 OS 自動升級:
properties: {
overprovision: overProvision
upgradePolicy: {
mode: 'Automatic'
automaticOSUpgradePolicy: {
enableAutomaticOSUpgrade: true
}
}
}
在OS升級期間,擴展集中的虛擬機會一次升級一個批次。 只有在升級的虛擬機上客戶應用程式狀況良好時,才能繼續升級。 建議應用程式向擴展集的作業系統升級引擎提供健康情況訊號。 根據預設,在OS升級期間,平臺會考慮虛擬機電源狀態和擴充功能布建狀態,以判斷虛擬機在升級后是否狀況良好。 在虛擬機的 OS 升級期間,虛擬機上的 OS 磁碟會取代為以最新映射版本為基礎的新磁碟。 操作系統升級完成後,這些虛擬機上會執行設定的擴充功能。 只有在執行個體上的所有擴充功能都成功佈建之後,系統才會認為應用程式的狀況良好。
您可以使用應用程式健康情況探查選擇性地設定擴展集,以便為平台提供精確的應用程式持續狀態的相關資訊。 應用程式健康情況探查是當作健康情況訊號使用的自訂負載平衡器探查。 在擴展集虛擬機上執行的應用程式可以回應外部 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 叢集持久性特性的詳細資訊,請參閱 本檔。
應用程式健康情況擴充功能部署在虛擬機擴展集實例內,並從擴展集實例內報告虛擬機健康情況。 您可以將延伸模組設定為在應用程式端點上探查,並更新該執行個體上的應用程式狀態。 Azure 會檢查此執行個體狀態,以判斷執行個體是否適合進行升級作業。
當擴充功能報告虛擬機內的健康情況時,擴充功能可用於無法使用外部探查,例如應用程式健康情況探查(使用自定義 Azure Load Balancer 探查) 等外部探查。
有多種方法可以將應用程式健康情況擴充功能部署至您的擴展集,如這篇文章中的範例所詳述。
注意
虛擬機器擴展集只能使用一個狀況監控來源,也就是應用程式健康情況擴充功能或健全狀態探查。 如果您已啟用這兩個選項,您必須先移除一個選項,才能使用實例修復或自動OS升級等協調流程服務。
注意
虛擬機器擴展集 上輪流升級的自定義計量目前為預覽狀態。 若您同意補充的使用規定即可取得預覽。 在公開上市 (GA) 之前,這些功能的某些領域可能會變更。
滾動升級的自定義計量可讓您利用 應用程式健康情況擴充功能 ,將自定義計量發出至虛擬機擴展集。 這些自定義計量可用來告訴擴展集在觸發滾動升級時應更新虛擬機的順序。 自定義計量也可以在特定實例上略過升級時通知您的擴展集。 這可讓您更充分掌控排序和更新程式本身。
自定義計量可以與其他滾動升級功能搭配使用,例如 自動OS升級、 自動擴充功能升級 和 MaxSurge滾動升級。
如需詳細資訊,請參閱 虛擬機器擴展集 上滾動升級的自定義計量
您可以使用 Azure PowerShell、Azure CLI 2.0 或 REST API,檢查您擴展集上最近執行之 OS 升級的記錄。 您可以取得過去兩個月內的最近五次 OS 升級嘗試的記錄。
如果您的擴展集使用任何認證來存取外部資源,例如設定為使用記憶體帳戶 SAS 令牌的虛擬機擴充功能,請確定認證已更新。 如果包含憑證和令牌的任何認證已過期,升級會失敗,而第一批虛擬機會處於失敗狀態。
如果資源驗證失敗,請復原虛擬機並重新啟用自動 OS 升級的建議步驟:
下列範例會使用 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"
}
]
}
使用 Get-AzVmss Cmdlet 來檢查擴展集的 OS 升級歷程記錄。 下列範例詳述如何針對 [myResourceGroup] 資源群組中的 [myScaleSet] 擴展集,檢閱其 OS 升級狀態:
Get-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet" -OSUpgradeHistory
使用 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 自動升級之 SKU 的可用映像版本:
GET on `/subscriptions/subscription_id/providers/Microsoft.Compute/locations/{location}/publishers/{publisherName}/artifacttypes/vmimage/offers/{offer}/skus/{skus}/versions?api-version=2021-03-01`
Get-AzVmImage -Location "westus" -PublisherName "Canonical" -offer "0001-com-ubuntu-server-jammy" -sku "22_04-lts"
az vm image list --location "westus" --publisher "Canonical" --offer "0001-com-ubuntu-server-jammy" --sku "22_04-lts" --all
在擴展集上啟用自動OS映射升級時,您不需要在擴展集上手動觸發映像更新。 OS 升級協調器會自動將最新的可用映像版本套用至擴展集實例,而不需要任何手動介入。
針對您不想等候協調器套用最新映像的特定案例,您可以使用下列範例手動觸發OS映射升級。
注意
作業系統映像升級的手動觸發程式不提供自動復原功能。 若執行個體在升級作業後未復原其健全狀態,則無法還原其先前的 OS 磁碟。
使用 [開始 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`
使用 Start-AzVmssRollingOSUpgrade Cmdlet 來檢查擴展集的 OS 升級歷程記錄。 下列範例詳述如何針對 [myResourceGroup] 資源群組中的 [myScaleSet] 擴展集,開始推出 OS 升級:
Start-AzVmssRollingOSUpgrade -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet"
使用 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 中發生的訂用帳戶層級事件。 客戶能夠:
客戶會收到與自動OS升級作業相關的三種通知類型:
動作群組是由 Azure 訂用帳戶的「擁有者」所定義的通知喜好設定集合。 Azure 監視器和服務健康狀態警示使用動作群組來通知使用者警示已被觸發。
動作群組可以使用:
客戶可以使用動作群組來設定下列項目:
平臺可以在使用滾動升級原則執行自動映射升級時,傳回虛擬機上的錯誤。 虛擬機的 [取得實例檢視] 包含詳細的錯誤訊息,可調查並解決錯誤。 輪流升級 - 取得最新可以提供有關輪流升級設定和狀態的詳細資料。 取得 OS 升級歷程記錄會提供擴展集上次映像升級作業的詳細資料。 以下是輪流升級最常遇到的錯誤。
RollingUpgradeInProgressWithFailedUpgradedVMs
MaxUnhealthyUpgradedInstancePercentExceededInRollingUpgrade
MaxUnhealthyInstancePercentExceededInRollingUpgrade
MaxUnhealthyInstancePercentExceededBeforeRollingUpgrade
InternalExecutionError
RollingUpgradeTimeoutError
訓練
學習路徑
Use advance techniques in canvas apps to perform custom updates and optimization - Training
Use advance techniques in canvas apps to perform custom updates and optimization
文件
搭配 Azure 虛擬機器擴展集使用應用程式健康狀態延伸模組 - Azure Virtual Machine Scale Sets
了解如何使用應用程式健康狀態延伸模組監視部署在虛擬機器擴展集上的應用程式健康狀態。
虛擬機器擴展集的升級原則模式 - Azure Virtual Machine Scale Sets
了解虛擬機器擴展集可用的不同升級原則。
修改 Azure 虛擬機器擴展集 - Azure Virtual Machine Scale Sets
了解如何使用 REST API、Azure PowerShell 及 Azure CLI,修改和更新 Azure 虛擬機器擴展集