Automatische Betriebssystemimageupgrades mit Azure-VM-Skalierungsgruppen

Artikel
11/15/2023

Hinweis

Viele der in diesem Dokument aufgeführten Schritte gelten für Virtual Machine Scale Sets mit dem Orchestrierungsmodus „Einheitlich“. Für neue Workloads empfehlen wir den Modus „Flexible Orchestrierung“. Weitere Informationen finden Sie unter Orchestrierungsmodi für VM-Skalierungsgruppen in Azure.

Das Aktivieren der automatischen Betriebssystemimage-Upgrades auf Ihrer Skalierungsgruppe vereinfacht die Updateverwaltung durch sicheres und automatisches Aktualisieren des Betriebssystem-Datenträgers für alle Instanzen in der Skalierungsgruppe.

Das automatische Betriebssystemupgrade weist folgende Merkmale auf:

Nach der Konfiguration wird das neueste von den Imageherausgebern veröffentlichte Betriebssystemimage automatisch ohne Benutzereingriff auf die Skalierungsgruppe angewendet.
Aktualisiert Batches von Instanzen immer parallel, wenn ein neues Image vom Herausgeber veröffentlicht wird.
Wird in Anwendungsintegritätstests und Anwendungsintegritätserweiterung integriert.
Funktioniert für alle Formate von virtuellen Computern, sowohl für Windows- als auch für Linux-Images, einschließlich benutzerdefinierter Images über die Azure Compute Gallery.
Sie können automatische Upgrades jederzeit abwählen (Betriebssystemupgrades können auch manuell initiiert werden).
Der Betriebssystemdatenträger eines virtuellen Computers wird durch den neuen, mit der neuesten Imageversion erstellten Betriebssystemdatenträger ersetzt. Konfigurierte Erweiterungen und benutzerdefinierte Datenskripts werden ausgeführt, wobei persistente Datenträger weiterhin aufbewahrt werden.
Erweiterungssequenzierung wird unterstützt.
Kann für Skalierungsgruppen beliebiger Größe aktiviert werden

Hinweis

Bevor Sie automatische Betriebssystemimage-Upgrades aktivieren, überprüfen Sie den Abschnitt „Anforderungen“ in dieser Dokumentation.

Wie funktioniert das automatische Upgrade von Betriebssystemimages?

Bei einem Upgrade wird der Betriebssystemdatenträger eines virtuellen Computers durch einen neuen Datenträger ersetzt, der mit der neuesten Imageversion erstellt wird. Alle konfigurierten Erweiterungen und benutzerdefinierten Datenskripts werden auf dem Betriebssystemdatenträger ausgeführt, wobei die Datenträger weiterhin aufbewahrt werden. Um die Anwendungsausfallzeiten zu minimieren, erfolgen Upgrades in Batches, wobei jeweils nicht mehr als 20% der Skalierungsgruppe aktualisiert werden.

Sie können einen Azure Load Balancer Anwendungszustandstest oder die Anwendungszustandserweiterung integrieren, um die Integrität der Anwendung nach einem Upgrade nachzuverfolgen. Sie sollten einen Anwendungstakt integrieren und den Erfolg des Upgrades überprüfen.

Verfügbarkeitsupdates

Das im Folgenden beschriebene Verfügbarkeitsmodell für plattformorchestrierte Updates stellt sicher, dass die Verfügbarkeitskonfigurationen in Azure für mehrere Verfügbarkeitsstufen berücksichtigt werden.

Über Regionen hinweg:

Ein Update wird in Phasen global in Azure ausgeführt, um Azure-weite Bereitstellungsausfälle zu vermeiden.
Eine „Phase“ kann sich über eine oder mehrere Regionen erstrecken, und ein Update ist nur dann Phasen übergreifend, wenn die in Betracht kommenden VMs in der vorherigen Phase erfolgreich aktualisiert wurden.
Georegionspaare werden nicht gleichzeitig aktualisiert und können sich nicht in der gleichen Regionsphase befinden.
Der Erfolg eines Updates wird durch die Nachverfolgung der Integrität nach dem Update einer VM gemessen.

Innerhalb einer Region:

VMs in verschiedenen Verfügbarkeitszonen werden nicht gleichzeitig mit demselben Update aktualisiert.

Innerhalb einer „Gruppe“:

Alle VMs in einer gemeinsamen Skalierungsgruppe werden nicht gleichzeitig aktualisiert.
VMs in einer gemeinsamen VM-Skalierungsgruppe werden in Batches gruppiert und innerhalb der Grenzen von Upgradedomänen aktualisiert (siehe folgende Beschreibung).

Der Prozess der plattformorchestrierten Updates wird ausgeführt, um jeden Monat unterstützte Upgrades von Betriebssystemplattformimages auszuführen. Bei benutzerdefinierten Images über Azure Compute Gallery wird ein Imageupgrade nur für eine bestimmte Azure-Region gestartet, wenn das neue Image veröffentlicht und in die Region dieser Skalierungsgruppe repliziert wird.

Upgraden von virtuellen Computern in einer Skalierungsgruppe

Die Region einer Skalierungsgruppe ist berechtigt, Imageupgrades entweder über den verfügbarkeitsbasierten Prozess für Plattformimages oder die Replikation neuer benutzerdefinierter Imageversionen für die Shared Image Gallery zu erhalten. Das Imageupgrade wird dann wie folgt in Batches auf eine einzelne Skalierungsgruppen angewendet:

Bevor Sie mit dem Upgradeprozess beginnen, stellt der Orchestrator sicher, dass nicht mehr als 20 % der Instanzen in der gesamten Skalierungsgruppe (aus beliebigem Grund) fehlerhaft sind.
Der Upgradeorchestrator identifiziert den Batch zu aktualisierender VM-Instanzen, wobei ein Batch maximal 20% der gesamten Instanzenzahl aufweist, abhängig von einer minimalen Batchgröße eines virtuellen Computers. Es gibt keine Mindestanforderungen für die Skalierungsgruppengröße, und Skalierungsgruppen mit mindestens 5 Instanzen verfügen über 1 VM pro Upgradebatch (minimale Batchgröße).
Der Betriebssystemdatenträger jeder VM im ausgewählten Upgradebatch wird durch einen neuen Betriebssystemdatenträger ersetzt, der aus dem aktuellen Image erstellt wurde. Alle angegebenen Erweiterungen und Konfigurationen im Skalierungsgruppenmodell werden auf die aktualisierte Instanz angewendet.
Für Skalierungsgruppen mit konfigurierten Anwendungsintegritätstests oder Anwendungsintegritätserweiterung wartet das Upgrade bis zu 5 Minuten darauf, dass die Instanz fehlerfrei wird, bevor mit der Aktualisierung des nächsten Batches fortgefahren wird. Wenn für eine Instanz die Integrität innerhalb von fünf Minuten nach einem Upgrade nicht wiederhergestellt werden kann, wird standardmäßig der vorherige Betriebssystemdatenträger für die Instanz wiederhergestellt.
Der Upgradeorchestrator verfolgt auch den Prozentsatz der Instanzen nach, die nach einem Upgrade fehlerhaft werden. Das Upgrade wird beendet, wenn mehr als 20% der aktualisierten Instanzen während des Upgradeprozesses fehlerhaft werden.
Das oben beschriebene Verfahren wird fortgesetzt, bis alle Instanzen in der Skalierungsgruppe aktualisiert sind.

Der Upgradeorchestrator für das Skalierungsgruppen-Betriebssystem überprüft die allgemeine Skalierungsgruppenintegrität, bevor die einzelnen Batches aktualisiert werden. Beim Upgrade eines Batches finden eventuell andere gleichzeitige geplante oder nicht geplante Wartungsaktivitäten statt, die die Integrität Ihrer Skalierungsgruppeninstanzen beeinträchtigen könnten. Wenn in solchen Fällen mehr als 20% der Instanzen der Skalierungsgruppe fehlerhaft werden, endet das Upgrade der Skalierungsgruppe am Ende des aktuellen Batches.

Informationen zum Ändern der Standardeinstellungen im Zusammenhang mit rollierenden Upgrades finden Sie unter Rolling Upgrade Policy für Azure.

Hinweis

Das automatische Betriebssystemupgrade führt kein Upgrade der Referenzimage-SKU für die Skalierungsgruppe durch. Um die SKU zu ändern (z. B. Ubuntu 18.04-LTS auf 20.04-LTS), müssen Sie das Skalierungsgruppenmodell direkt mit der gewünschten Image-SKU aktualisieren. Imageherausgeber und Angebot können bei einer vorhandenen Skalierungsgruppe nicht geändert werden.

Betriebssystemimage-Upgrade und Reimaging

Sowohl Betriebssystemimage-Upgrade als auch das Durchführen eines Reimagings sind Methoden zum Aktualisieren von VMs innerhalb einer Skalierungsgruppe, dienen jedoch unterschiedlichen Zwecken und haben unterschiedliche Auswirkungen.

Ein Betriebssystemimage-Upgrade umfasst das Aktualisieren des zugrunde liegenden Betriebssystemimages, das zum Erstellen neuer Instanzen in einer Skalierungsgruppe verwendet wird. Wenn Sie ein Betriebssystemimage-Upgrade durchführen, erstellt Azure neue VM-Instanzen mit dem aktualisierten Betriebssystemimage und ersetzt schrittweise die alten VM-Instanzen in der Skalierungsgruppe durch die neuen. Dieser Prozess wird in der Regel in Phasen ausgeführt, um Hochverfügbarkeit sicherzustellen. Mit Betriebssystemimage-Upgrades können Sie Updates oder Änderungen am zugrunde liegenden Betriebssystem der VMs in einer Skalierungsgruppe auf unterbrechungsfreie Weise anwenden. Vorhandene VM-Instanzen sind erst betroffen, wenn sie durch die neuen Instanzen ersetzt werden.

Ein Reimaging für eine VM-Instanz in einer Skalierungsgruppe ist ein unmittelbarerer und nicht unterbrechungsfreier Prozess. Wenn Sie ein Reimaging für eine VM-Instanz durchführen möchten, beendet Azure die ausgewählte VM-Instanz, führt das Reimaging durch und startet die VM dann mit demselben Betriebssystemimage neu. Dadurch wird das Betriebssystem auf dieser bestimmten VM-Instanz im Prinzip neu installiert. Reimaging wird in der Regel verwendet, wenn Sie Probleme mit einer bestimmten VM-Instanz beheben oder die Instanz aufgrund von Problemen zurücksetzen müssen.

Wesentliche Unterschiede:

Das Betriebssystemimage-Upgrade ist ein schrittweiser und unterbrechungsfreier Prozess, der das Betriebssystemimage für die gesamte VM-Skalierungsgruppe im Laufe der Zeit aktualisiert. Dadurch werden minimale Auswirkungen auf ausgeführte Workloads sichergestellt.
Reimaging ist ein unmittelbarerer und nicht unterbrechungsfreier Prozess, der nur die ausgewählte VM-Instanz betrifft und bei dem die Instanz vorübergehend angehalten und das Betriebssystem neu installiert wird.

Einsatz der jeweiligen Methode:

Verwenden Sie das Betriebssystemimage-Upgrade, wenn Sie das Betriebssystemimage für die gesamte Skalierungsgruppe aktualisieren und dabei Hochverfügbarkeit gewährleisten möchten.
Verwenden Sie Reimaging, wenn Sie Probleme mit einer bestimmten VM-Instanz innerhalb der VM-Skalierungsgruppe beheben oder die Instanz zurücksetzen müssen.

Eine sorgfältige Planung und Auswahl der geeigneten Methode auf der Grundlage Ihrer spezifischen Anforderungen ist unerlässlich, um Unterbrechungen Ihrer Anwendungen und Dienste, die in einer VM-Skalierungsgruppe ausgeführt werden, zu minimieren.

Unterstützte Betriebssystemimages

Derzeit werden nur bestimmte Betriebssystemplattform-Images unterstützt. Benutzerdefinierte Images werden unterstützt, wenn die Skalierungsgruppe benutzerdefinierte Images über Azure Compute Gallery nutzt.

Derzeit werden die folgenden Plattform-SKUs unterstützt (weitere werden regelmäßig hinzugefügt):

Herausgeber	Betriebssystemangebot	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	Enterprise
MicrosoftWindowsServer	Windows Server	2012-R2-Datacenter
MicrosoftWindowsServer	Windows Server	2016-Datacenter
MicrosoftWindowsServer	Windows Server	2016-Datacenter-gensecond
MicrosoftWindowsServer	Windows Server	2016-Datacenter-gs
MicrosoftWindowsServer	Windows Server	2016-Datacenter-smalldisk
MicrosoftWindowsServer	Windows Server	2016-Datacenter-with-Containers
MicrosoftWindowsServer	Windows Server	2016-Datacenter-with-containers-gs
MicrosoftWindowsServer	Windows Server	2019-Datacenter
MicrosoftWindowsServer	Windows Server	2019-Datacenter-Core
MicrosoftWindowsServer	Windows Server	2019-Datacenter-Core-with-Containers
MicrosoftWindowsServer	Windows Server	2019-Datacenter-gensecond
MicrosoftWindowsServer	Windows Server	2019-Datacenter-gs
MicrosoftWindowsServer	Windows Server	2019-Datacenter-smalldisk
MicrosoftWindowsServer	Windows Server	2019-Datacenter-with-Containers
MicrosoftWindowsServer	Windows Server	2019-Datacenter-with-Containers-gs
MicrosoftWindowsServer	Windows Server	2022-Datacenter
MicrosoftWindowsServer	Windows Server	2022-Datacenter-smalldisk
MicrosoftWindowsServer	Windows Server	2022-Datacenter-smalldisk-g2
MicrosoftWindowsServer	Windows Server	2022-Datacenter-core
MicrosoftWindowsServer	Windows Server	2022-Datacenter-core-smalldisk
MicrosoftWindowsServer	Windows Server	2022-Datacenter-g2
MicrosoftWindowsServer	Windows Server	Datacenter-core-20h2-with-containers-smalldisk-gs
MicrosoftWindowsServer	Windows Server	2022-Datacenter-azure-edition
MicrosoftWindowsServer	Windows Server	2022-Datacenter-azure-edition-smalldisk

Anforderungen für das Konfigurieren des automatischen Upgrades von Betriebssystemimages

Die version-Eigenschaft des Images muss auf latest festgelegt werden.
Anwendungsintegritätstests oder die Anwendungsintegritätserweiterung für Nicht-Service Fabric-Skalierungsgruppen müssen/muss verwendet werden. Informationen zu den Service Fabric-Anforderungen finden Sie unter Service Fabric-Anforderung.
Verwenden Sie Compute-API-Version 2018-10-01 oder höher.
Stellen Sie sicher, dass im Skalierungsgruppenmodell angegebene externe Ressourcen verfügbar und aktualisiert sind. Zu den Beispielen zählen SAS-URI für die Bootstrap-Nutzlast in VM-Erweiterungseigenschaften, Nutzlast im Speicherkonto, Verweis auf Geheimnisse im Modell und Sonstiges.
Für Skalierungsgruppen mit Verwendung von Windows-VMs ab Compute-API-Version 2019-03-01 muss die virtualMachineProfile.osProfile.windowsConfiguration.enableAutomaticUpdates-Eigenschaft in der Skalierungsgruppen-Modelldefinition auf false festgelegt werden. Die Eigenschaft enableAutomaticUpdates ermöglicht Patching auf einem virtuellen Computer, bei denen „Windows Update“ Betriebssystempatches anwendet, ohne den Betriebssystemdatenträger zu ersetzen. Wenn die automatische Aktualisierung von Betriebssystem-Images in Ihrer Skalierungsgruppe aktiviert ist (indem Sie die Option automaticOSUpgradePolicy.enableAutomaticOSUpgrade auf true setzen), ist ein zusätzlicher Patching-Prozess über Windows Update nicht erforderlich.

Hinweis

Nachdem ein Betriebssystemdatenträger durch Reimaging oder ein Upgrade ersetzt wurde, werden den angefügten Datenträgern ihre Laufwerkbuchstaben möglicherweise neu zugewiesen. Um die gleichen Laufwerkbuchstaben für angefügte Datenträger beizubehalten, wird empfohlen, ein benutzerdefiniertes Startskript zu verwenden.

Service Fabric-Anforderungen

Stellen Sie bei Verwendung von Service Fabric sicher, dass die folgenden Bedingungen erfüllt sind:

Die Dauerhaftigkeitsstufe von Service Fabric lautet „Silber“ oder „Gold“. Wenn die Dauerhaftigkeit von Service Fabric „Bronze“ ist, unterstützen nur zustandslose Knotentypen automatische Betriebssystemimage-Ugrades).
Die Service Fabric-Erweiterung in der Skalierungsgruppenmodell-Definition muss über TypeHandlerVersion 1.1 oder höher verfügen.
Die Dauerhaftigkeitsstufe sollte im Service Fabric-Cluster und für die Service Fabric-Erweiterung in der Skalierungsgruppenmodell-Definition gleich sein.
Ein zusätzlicher Integritätstest oder die Verwendung einer Anwendungsintegritätserweiterung ist für Silber- oder Gold-Dauerhaftigkeit nicht erforderlich. Bronze-Dauerhaftigkeit mit zustandslosen Knotentypen erfordert einen zusätzlichen Integritätstest.
Die Eigenschaft virtualMachineProfile.osProfile.windowsConfiguration.enableAutomaticUpdates muss in der Skalierungsgruppenmodell-Definition auf false festgelegt werden. Die Eigenschaft enableAutomaticUpdates ermöglicht das Patchen in virtuellen VMs mithilfe von „Windows Update“, und wird für Service Fabric-Skalierungsets nicht unterstützt. Sie sollten stattdessen die Eigenschaft automaticOSUpgradePolicy.enableAutomaticOSUpgrade verwenden.

Stellen Sie sicher, dass die Dauerhaftigkeitseinstellungen im Service Fabric-Cluster und für die Service Fabric-Erweiterung nicht in Konflikt stehen, weil dies zu Upgradefehlern führt. Dauerhaftigkeitsstufen können mit den Richtlinien geändert werden, die auf dieser Seite beschrieben sind.

Automatisches Upgrade von Betriebssystemimages für benutzerdefinierte Images

Das automatische Upgrade von Betriebssystemimages wird für benutzerdefinierte Images unterstützt, die über Azure Compute Gallery bereitgestellt wurden. Andere benutzerdefinierte Images werden für automatische Upgrades von Betriebssystemimages nicht unterstützt.

Weitere Anforderungen für benutzerdefinierte Images

Der Einrichtungs- und Konfigurationsprozess für das automatische Upgrade von Betriebssystemimages ist für alle Skalierungsgruppen identisch (siehe Beschreibung im Konfigurationsabschnitt dieser Seite).
Skalierungsgruppeninstanzen, die für automatische Upgrades von Betriebssystemimages konfiguriert sind, werden auf die neueste Version des Azure-Compute-Gallery-Images aktualisiert, wenn eine neue Version des Images veröffentlicht und in die Region der dieser Skalierungsgruppe repliziert wird. Wenn das neue Image nicht in der Region repliziert wird, in der die Skalierung bereitgestellt wird, erfolgt kein Upgrade der Skalierungsgruppeninstanzen auf die neueste Version. Die regionale Imagereplikation ermöglicht es Ihnen, das Rollout des neuen Images für Ihre Skalierungsgruppen zu steuern.
Die neue Imageversion sollte nicht aus der aktuellen Version für das betreffende Katalogimage ausgeschlossen werden. Für Imageversionen, die aus der aktuellen Version des Katalogimages ausgeschlossen werden, erfolgt durch das automatische Upgrade von Betriebssystemimages kein Rollout in der Skalierungsgruppe.

Hinweis

Es kann bis zu drei Stunden dauern, bis eine Skalierungsgruppe den ersten Rollout für das Imageupgrade auslöst, nachdem sie erstmalig für automatische Betriebssystemupgrades konfiguriert wurde. Dies liegt an bestimmten Faktoren wie Wartungsfenstern und anderen Einschränkungen. Kund*innen für das neueste Image erhalten möglicherweise erst ein Upgrade, wenn ein neues Image verfügbar ist.

Konfigurieren des automatischen Upgrades von Betriebssystemimages

Stellen Sie zum Konfigurieren des automatischen Upgrades von Betriebssystemimages sicher, dass die Eigenschaft automaticOSUpgradePolicy.enableAutomaticOSUpgrade in der Definition des Skalierungsgruppenmodells auf true festgelegt ist.

Hinweis

Der Upgraderichtlinienmodus und die Richtlinie für automatische Betriebssystemupgrades sind separate Einstellungen und steuern verschiedene Aspekte der Skalierungsgruppe. Wenn Änderungen an der Skalierungsgruppenvorlage vorgenommen werden, bestimmt die mode-Upgraderichtlinie, was mit vorhandenen Instanzen in der Skalierungsgruppe geschieht. Die Richtlinie für automatische Betriebssystemupgrades enableAutomaticOSUpgrade ist betriebssystemimagespezifisch und verfolgt Änderungen, die der Herausgeber des Images vorgenommen hat, und bestimmt, was geschieht, wenn ein Update des Images erfolgt.

Hinweis

Wenn enableAutomaticOSUpgrade auf truefestgelegt ist, wird enableAutomaticUpdates automatisch auf false festgelegt und kann nicht mehr auf truefestgelegt werden.

REST-API

Im folgenden Beispiel wird beschrieben, wie automatische Betriebssystemupgrades auf einem Skalierungsgruppenmodell festgelegt werden:

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

Verwenden Sie das Cmdlet New-AzVmss, um automatische Betriebssystemimageupgrades für Ihre Skalierungsgruppe während der Bereitstellung zu konfigurieren. Im folgenden Beispiel werden automatische Upgrades für die Skalierungsgruppe myScaleSet in der Ressourcengruppe myResourceGroup konfiguriert:

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

Verwenden Sie das Cmdlet Update-AzVmss, um automatische Betriebssystem-Imageupgrades für Ihre vorhandene Skalierungsgruppe zu konfigurieren. Im folgenden Beispiel werden automatische Upgrades für die Skalierungsgruppe myScaleSet in der Ressourcengruppe myResourceGroup konfiguriert:

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

Azure CLI 2.0

Verwenden Sie az vmss create, um automatische Betriebssystemimageupgrades für Ihre Skalierungsgruppe während der Bereitstellung zu konfigurieren. Verwenden Sie Azure CLI 2.0.47 oder höher. Im folgenden Beispiel werden automatische Upgrades für die Skalierungsgruppe myScaleSet in der Ressourcengruppe myResourceGroup konfiguriert:

az vmss create --name myScaleSet --resource-group myResourceGroup --set UpgradePolicy.AutomaticOSUpgradePolicy.EnableAutomaticOSUpgrade=true

Verwenden Sie az vmss update, um automatische Betriebssystem-Imageupgrades für Ihre vorhandene Skalierungsgruppe zu konfigurieren. Verwenden Sie Azure CLI 2.0.47 oder höher. Im folgenden Beispiel werden automatische Upgrades für die Skalierungsgruppe myScaleSet in der Ressourcengruppe myResourceGroup konfiguriert:

az vmss update --name myScaleSet --resource-group myResourceGroup --set UpgradePolicy.AutomaticOSUpgradePolicy.EnableAutomaticOSUpgrade=true

Hinweis

Nach dem Konfigurieren automatischer Betriebssystem-Imageupgrades für Ihre Skalierungsgruppe müssen Sie die Skalierungsgruppen-VMs auch auf das aktuelle Skalierungsgruppenmodell aktualisieren, wenn Ihre Skalierungsgruppe die Upgraderichtlinie „Manuell“ verwendet.

ARM-Vorlagen

Im folgenden Beispiel wird beschrieben, wie automatische Betriebssystemupgrades für ein Skalierungsgruppenmodell über Azure Resource Manager-Vorlagen (ARM-Vorlagen) festgelegt werden:

"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

Im folgenden Beispiel wird beschrieben, wie automatische Betriebssystemupgrades für ein Skalierungsgruppenmodell über Bicep festgelegt werden:

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

Verwenden von Anwendungsintegritätstests

Während eines Betriebssystemupgrades werden VM-Instanzen in einer Skalierungsgruppe batchweise nacheinander aktualisiert. Das Upgrade sollte nur fortgesetzt werden, wenn die Kundenanwendung auf den aktualisierten VM-Instanzen fehlerfrei ist. Es wird empfohlen, dass die Anwendung der Upgrade-Engine für das Skalierungsgruppen-Betriebssystem Integritätssignale zur Verfügung stellt. Standardmäßig wertet die Plattform während Betriebssystemupgrades den VM-Energiezustand und den Status der Erweiterungsbereitstellung aus, um festzustellen, ob eine VM-Instanz nach einem Upgrade fehlerfrei ist. Während des Betriebssystemupgrades einer VM-Instanz wird ihr Betriebssystemdatenträger durch einen neuen Datenträger ersetzt, der auf der neuesten Imageversion basiert. Nachdem das Betriebssystemupgrade abgeschlossen wurde, werden die konfigurierten Erweiterungen auf diesen VMs ausgeführt. Die Anwendung wird erst dann als fehlerfrei angesehen, wenn alle Erweiterungen erfolgreich auf der Instanz bereitgestellt wurden.

Eine Skalierungsgruppe kann optional mit Anwendungsintegritätstests konfiguriert werden, um der Plattform genaue Informationen zum fortlaufenden Status der Anwendung bereitzustellen. Anwendungsintegritätstests sind benutzerdefinierte Lastenausgleichs-Prüfpunkte, die als Integritätssignal verwendet werden. Die auf einer Skalierungsgruppen-VM-Instanz ausgeführte Anwendung kann auf externe HTTP- oder TCP-Anforderungen reagieren und dadurch anzeigen, dass sie fehlerfrei ist. Weitere Informationen zur Funktionsweise von benutzerdefinierten Lastenausgleichstests finden Sie unter Grundlegendes zu Lastenausgleichstests. Anwendungsintegritätstests werden für Service Fabric-Skalierungsgruppen nicht unterstützt. Nicht-Service Fabric-Skalierungsgruppen erfordern entweder Load Balancer-Anwendungsintegritätstests oder eine Anwendungsintegritätserweiterung.

Wenn die Skalierungsgruppe für die Verwendung mehrerer Platzierungsgruppen konfiguriert ist, müssen Tests mit einem Standardlastenausgleich verwendet werden.

Hinweis

Für eine VM-Skalierungsgruppe kann nur eine Quelle der Integritätsüberwachung verwendet werden, entweder eine Anwendungsintegritätserweiterung oder ein Integritätstest. Wenn Sie beide Optionen aktiviert haben, müssen Sie eine entfernen, bevor Sie Orchestrierungsdienste wie Instanzreparaturen oder automatische Betriebssystemupgrades verwenden.

Konfigurieren eines benutzerdefinierten Lastenausgleichstests als Anwendungsintegritätstest für eine Skalierungsgruppe

Erstellen Sie als bewährte Methode einen Lastenausgleichstest explizit für die Skalierungsgruppenintegrität. Sie können denselben Endpunkt für einen vorhandenen HTTP-Test oder TCP-Test verwenden. Für einen Integritätstest ist jedoch möglicherweise ein anderes Verhalten als bei einem herkömmlichen Lastenausgleichstest erforderlich. Beispielsweise könnte ein herkömmlicher Lastenausgleichstest den Status „Fehlerhaft“ zurückgeben, wenn die Last der Instanz zu hoch ist, aber zum Ermitteln der Instanzintegrität bei einem automatischen Betriebssystemupgrade wäre dies nicht angemessen. Konfigurieren Sie den Test so, dass eine hohe Stichprobenrate von unter zwei Minuten gilt.

Der Lastenausgleichstest kann im networkProfile der Skalierungsgruppe referenziert werden und wie folgt einem internen oder einem öffentlich zugänglichen Lastenausgleich zugeordnet werden:

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

Hinweis

Wenn Sie automatische Betriebssystemupgrades mit Service Fabric verwenden, wird das neue Betriebssystemimage nacheinander in einzelnen Updatedomänen bereitgestellt. So wird gewährleistet, dass die in Service Fabric ausgeführten Dienste hochverfügbar bleiben. Um automatische Betriebssystemupgrades in Service Fabric nutzen zu können, muss Ihr Clusterknotentyp zur Verwendung der Dauerhaftigkeitsstufe „Silber“ oder höher konfiguriert sein. Für die Dauerhaftigkeitsstufe „Bronze“ wird ein automatisches Betriebssystemupgrade nur für zustandslose Knotentypen unterstützt. Weitere Informationen zu den Dauerhaftigkeitsmerkmalen von Service Fabric-Clustern finden Sie in dieser Dokumentation.

Ihre Anmeldeinformationen müssen aktuell sein

Wenn Ihre Skalierungsgruppe Anmeldeinformationen zum Zugreifen auf externe Ressourcen verwendet – z. B. eine VM-Erweiterung, die für die Verwendung eines SAS-Tokens für das Speicherkonto konfiguriert wurde –, sollten Sie sicherstellen, dass die Anmeldeinformationen aktuell sind. Wenn die verwendeten Anmeldeinformationen (Zertifikate und Token eingeschlossen) abgelaufen sind, kommt es beim Upgrade zu einem Fehler, und der erste VM-Batch wechselt in einen Fehlerzustand.

Führen Sie die folgenden Schritte aus, um nach einem Fehler bei der Ressourcenauthentifizierung die VMs wiederherzustellen und automatische Betriebssystemupgrades erneut zu aktivieren:

Generieren Sie das Token (oder andere Anmeldeinformationen) neu, die an Ihre Erweiterungen übergeben werden.
Stellen Sie sicher, dass in der VM verwendete Anmeldeinformationen zur Kommunikation mit externen Entitäten aktuell sind.
Aktualisieren Sie Erweiterungen im Skalierungsgruppenmodell mit den neuen Token.
Stellen Sie die aktualisierte Skalierungsgruppe bereit, um alle VM-Instanzen – einschließlich der fehlerhaften – zu aktualisieren.

Verwenden der Anwendungsintegritätserweiterung

Die Application Health-Erweiterung wird in einer VM-Skalierungsgruppeninstanz bereitgestellt und berichtet von der Skalierungsgruppeninstanz aus über die VM-Integrität. Sie können die Erweiterung konfigurieren, um einen Anwendungsendpunkt zu prüfen und den Status der Anwendung in dieser Instanz zu aktualisieren. Dieser Instanzstatus wird von Azure geprüft, um festzustellen, ob eine Instanz für Upgradevorgänge geeignet ist.

Da die Erweiterung von einem virtuellen Computer aus über die Integrität berichtet, kann die Erweiterung in Situationen verwendet werden, in denen externe Tests wie z.B. Anwendungsintegritätstests (die benutzerdefinierte Azure Load Balancer-Tests verwenden) nicht genutzt werden können.

Es gibt mehrere Möglichkeiten, die Application Health-Erweiterung für Ihre Skalierungsgruppen bereitzustellen, wie in den Beispielen in diesem Artikel beschrieben.

Hinweis

Abrufen des Verlaufs automatischer Betriebssystemimageupgrades

Sie können den Verlauf des letzten für Ihre Skalierungsgruppe durchgeführten Betriebssystemupgrades mit Azure PowerShell, Azure CLI 2.0 oder der REST-API überprüfen. Sie können den Verlauf für die letzten fünf Betriebssystemupgradeversuche innerhalb der vergangenen zwei Monate abrufen.

REST-API

Im folgenden Beispiel wird der Status der Skalierungsgruppe myScaleSet in der Ressourcengruppe myResourceGroup mit der REST-API überprüft:

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

Der GET-Aufruf gibt Eigenschaften ähnlich der folgenden Beispielausgabe zurück:

{
	"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

Überprüfen Sie mit dem Get-AzVmss-Cmdlet den Verlauf des Betriebssystemupgrades für Ihre Skalierungsgruppe. Das folgende Beispiel zeigt, wie der Status des Betriebssystemupgrades für eine Skalierungsgruppe mit dem Namen myScaleSet in der Ressourcengruppe myResourceGroup überprüft wird:

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

Azure CLI 2.0

Überprüfen Sie mit az vmss get-os-upgrade-history den Verlauf des Betriebssystemupgrades für Ihre Skalierungsgruppe. Verwenden Sie Azure CLI 2.0.47 oder höher. Das folgende Beispiel zeigt, wie der Status des Betriebssystemupgrades für eine Skalierungsgruppe mit dem Namen myScaleSet in der Ressourcengruppe myResourceGroup überprüft wird:

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

Wie erhalte ich die neueste Version eines Plattformimages?

Sie können die verfügbaren Imageversionen für automatische Betriebssystemupgrades von unterstützten SKUs mithilfe der folgenden Beispiele erhalten:

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

Manuelles Auslösen von Upgrades des Betriebssystemimages

Wenn automatische Upgrades von Betriebssystemimages für Ihre Skalierungsgruppe aktiviert sind, müssen Sie die Imageupdates in Ihrer Skalierungsgruppe nicht manuell auslösen. Der Orchestrator für Betriebssystemupgrades wendet ohne manuellen Eingriff automatisch die neueste verfügbare Imageversion auf Ihre Skalierungsgruppeninstanzen an.

In bestimmten Fällen, in denen Sie nicht auf das Anwenden des aktuellen Images durch den Orchestrator warten möchten, können Sie manuell ein Upgrade des Betriebssystemimages auslösen, indem Sie die unten angegebenen Beispiele verwenden.

Hinweis

Die manuelle Auslösung von Upgrades des Betriebssystemimages verfügt nicht über Funktionen für den automatischen Rollback. Wenn eine Instanz nach einem Upgradevorgang die Integrität nicht wiedererlangt, kann der vorherige Betriebssystemdatenträger nicht wiederhergestellt werden.

REST-API

Verwenden Sie den API-Aufruf zum Starten eines Betriebssystemupgrades, um ein paralleles Upgrade zu starten, bei dem alle VM-Skalierungsgruppeninstanzen auf die neueste verfügbare Imagebetriebssystemversion aktualisiert werden. Instanzen, auf denen bereits die neueste verfügbare Betriebssystemversion ausgeführt wird, sind nicht betroffen. Das folgende Beispiel zeigt, wie Sie ein paralleles Betriebssystemupgrade für eine Skalierungsgruppe mit dem Namen myScaleSet in der Ressourcengruppe myResourceGroup starten können:

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

Azure PowerShell

Verwenden Sie das Cmdlet Start-AzVmssRollingOSUpgrade, um den Verlauf der Betriebssystemupgrades für Ihre Skalierungsgruppe zu überprüfen. Das folgende Beispiel zeigt, wie Sie ein paralleles Betriebssystemupgrade für eine Skalierungsgruppe mit dem Namen myScaleSet in der Ressourcengruppe myResourceGroup starten können:

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

Azure CLI 2.0

Überprüfen Sie mit az vmss rolling-upgrade start den Verlauf des Betriebssystemupgrades für Ihre Skalierungsgruppe. Verwenden Sie Azure CLI 2.0.47 oder höher. Das folgende Beispiel zeigt, wie Sie ein paralleles Betriebssystemupgrade für eine Skalierungsgruppe mit dem Namen myScaleSet in der Ressourcengruppe myResourceGroup starten können:

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

Untersuchen und Beheben von Fehlern beim automatischen Upgrade

Die Plattform kann Fehler auf virtuellen Computern zurückgeben, während das automatische Imageupgrade mit der Richtlinie zum parallelen Upgrade ausgeführt wird. Mit dem Befehl zum Abrufen der Instanzansicht können Sie für eine VM die detaillierte Fehlermeldung anzeigen, um einen Fehler zu untersuchen und zu beheben. Mit dem Befehl zum Abrufen des neuesten parallelen Ugrades können Sie weitere Details zur Konfiguration und zum Status des parallelen Upgrades abrufen. Mit dem Befehl zum Abrufen des Verlaufs des Betriebssystemupgrades erhalten Sie Details zum letzten Imageupgradevorgang für die Skalierungsgruppe. Nachfolgend sind die häufigsten Fehler aufgeführt, die zu parallelen Upgrades führen können.

RollingUpgradeInProgressWithFailedUpgradedVMs

Der Fehler wird für einen VM-Fehler ausgelöst.
In der detaillierten Fehlermeldung ist angegeben, ob das Rollout basierend auf dem konfigurierten Schwellenwert fortgesetzt/angehalten wird.

MaxUnhealthyUpgradedInstancePercentExceededInRollingUpgrade

Der Fehler wird ausgelöst, wenn der Prozentsatz der aktualisierten VMs den maximal zulässigen Schwellenwert für fehlerhafte VMs überschreitet.
Die detaillierte Fehlermeldung aggregiert die häufigsten Fehler, die zu fehlerhaften VMs beitragen. Siehe MaxUnhealthyUpgradedInstancePercent.

MaxUnhealthyInstancePercentExceededInRollingUpgrade

Der Fehler wird ausgelöst, wenn der Prozentsatz der fehlerhaften VMs den maximal zulässigen Schwellenwert für fehlerhafte VMs während eines Upgrades überschreitet.
Die detaillierte Fehlermeldung zeigt den aktuellen Prozentsatz fehlerhafter VMs und den konfigurierten zulässigen Prozentsatz fehlerhafter VMs an. Siehe maxUnhealthyInstancePercent.

MaxUnhealthyInstancePercentExceededBeforeRollingUpgrade

Der Fehler wird ausgelöst, wenn der Prozentsatz der fehlerhaften VMs den maximal zulässigen Schwellenwert für fehlerhafte VMs vor einem Upgrade überschreitet.
Die detaillierte Fehlermeldung zeigt den aktuellen Prozentsatz fehlerhafter VMs und den konfigurierten zulässigen Prozentsatz fehlerhafter VMs an. Siehe maxUnhealthyInstancePercent.

InternalExecutionError

Der Fehler wird ausgelöst, wenn während der Ausführung ein unbehandelter, nicht formatierter oder unerwarteter Vorgang auftritt.
Die detaillierte Fehlermeldung enthält die Fehlerursache.

RollingUpgradeTimeoutError

Fehler wird ausgelöst, wenn der rollierende Upgradevorgang eine Zeitüberschreitung aufweist.
In der detaillierten Fehlermeldung wird die Zeit angezeigt, nach der das System nach dem Versuch, eine Aktualisierung auszuführen, eine Zeitüberschreitung aufweist.

Nächste Schritte

Weitere Informationen zur Anwendungsintegritätserweiterung

Automatische Betriebssystemimageupgrades mit Azure-VM-Skalierungsgruppen

Wie funktioniert das automatische Upgrade von Betriebssystemimages?

Verfügbarkeitsupdates

Upgraden von virtuellen Computern in einer Skalierungsgruppe

Betriebssystemimage-Upgrade und Reimaging

Unterstützte Betriebssystemimages

Anforderungen für das Konfigurieren des automatischen Upgrades von Betriebssystemimages

Service Fabric-Anforderungen

Automatisches Upgrade von Betriebssystemimages für benutzerdefinierte Images

Weitere Anforderungen für benutzerdefinierte Images

Konfigurieren des automatischen Upgrades von Betriebssystemimages

REST-API

Azure PowerShell

Azure CLI 2.0

ARM-Vorlagen

Bicep

Verwenden von Anwendungsintegritätstests

Konfigurieren eines benutzerdefinierten Lastenausgleichstests als Anwendungsintegritätstest für eine Skalierungsgruppe

Ihre Anmeldeinformationen müssen aktuell sein

Verwenden der Anwendungsintegritätserweiterung

Abrufen des Verlaufs automatischer Betriebssystemimageupgrades

REST-API

Azure PowerShell

Azure CLI 2.0

Wie erhalte ich die neueste Version eines Plattformimages?

REST-API

Azure PowerShell

Azure CLI 2.0

Manuelles Auslösen von Upgrades des Betriebssystemimages

REST-API

Azure PowerShell

Azure CLI 2.0

Untersuchen und Beheben von Fehlern beim automatischen Upgrade

Nächste Schritte

Zusätzliche Ressourcen