Automatische Betriebssystemimageupgrades mit Azure-VM-Skalierungsgruppen

Artikel
01/21/2025

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 Virtual Machine Scale Sets in Azure.

Das Aktivieren der automatischen Betriebssystemimage-Upgrades für Ihre 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 VM-Größen, sowohl für Windows- als auch für Linux-Images, einschließlich benutzerdefinierter Images über 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 aktuellen 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 Imageversion erstellt wurde. 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 müssen einen Azure Load Balancer Anwendungsintegritätstest oder die Anwendungsintegritätserweiterung integrieren, um die Integrität der Anwendung nach einem Upgrade nachzuverfolgen. Auf diese Weise kann die Plattform die Integrität des virtuellen Computers überprüfen, um zu gewährleisten, dass Updates auf sichere Weise angewendet werden. Es wird empfohlen, einen Anwendungsheartbeat zu integrieren, um den Erfolg des Upgrades zu ü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 phasenweise 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 virtuellen Computer in der vorherigen Phase erfolgreich aktualisiert wurden.
Geografisch gekoppelte Regionen 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 eines virtuellen Computers nach dem Update gemessen.

Innerhalb einer Region:

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

Innerhalb einer „Gruppe“:

Virtuelle Computer in einer gemeinsamen Skalierungsgruppe werden nicht gleichzeitig aktualisiert.
Virtuelle Computer 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.

Aktualisieren 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 höchstens 20 % der Instanzen in der gesamten Skalierungsgruppe (aus irgendeinem Grund) fehlerhaft sind.
Der Upgradeorchestrator identifiziert den Batch zu aktualisierender virtueller Computer, wobei ein Batch maximal 20 % der Gesamtanzahl der Instanzen aufweist, abhängig von der Mindestbatchgröße eines virtuellen Computers. Es gibt keine Mindestanforderungen für die Größe der Skalierungsgruppe, und Skalierungsgruppen mit 5 oder weniger Instanzen verfügen über 1 virtuellen Computer pro Upgradebatch (Mindestbatchgröße).
Der Betriebssystemdatenträger jedes virtuellen Computers im ausgewählten Upgradebatch wird durch einen neuen Betriebssystemdatenträger ersetzt, der auf der Grundlage des Images 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 während des Upgradeprozesses mehr als 20 Prozent der aktualisierten Instanzen 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 Updates von Betriebssystemimages als auch das Durchführen eines Reimaging sind Methoden zum Aktualisieren virtueller Computer in 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 Upgrades von Betriebssystemimages durchführen, erstellt Azure mit dem aktualisierten Betriebssystemimage neue virtuelle Computer und ersetzt schrittweise die alten virtuellen Computer in der Skalierungsgruppe durch die neuen. Dieser Prozess wird in der Regel in Phasen ausgeführt, um Hochverfügbarkeit sicherzustellen. Mit Upgrades von Betriebssystemimages können Sie Updates oder Änderungen am zugrundeliegenden Betriebssystem der virtuellen Computer in einer Skalierungsgruppe unterbrechungsfrei vornehmen. Vorhandene virtuelle Computer sind erst betroffen, wenn sie durch die neuen Instanzen ersetzt werden.

Das Durchführen eines Reimaging von virtuellen Computern in einer Skalierungsgruppe ist ein Prozess, der unmittelbarer ist und zu mehr Störungen führt. Wenn Sie ein Reimaging von virtuellen Computern durchführen möchten, beendet Azure den ausgewählten virtuellen Computer, führt das Reimaging durch und startet den virtuellen Computer dann mit demselben Betriebssystemimage neu. Dadurch wird das Betriebssystem auf dem entsprechenden virtuellen Computer im Prinzip neu installiert. Ein Reimaging wird in der Regel durchgeführt, wenn Sie Probleme mit einem bestimmten virtuellen Computer beheben oder diesen aufgrund von Problemen mit der entsprechenden Instanz 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 Vorgang, der unmittelbarer ist und zu mehr Störungen führt. Es betrifft nur den ausgewählten virtuellen Computer, hält die Instanz vorübergehend an und installiert das Betriebssystem neu.

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.
Führen Sie ein Reimaging durch, wenn Sie Probleme mit einem bestimmten virtuellen Computer innerhalb der VM-Skalierungsgruppe beheben oder den virtuellen Computer 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
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

Anforderungen für das Konfigurieren des automatischen Upgrades von Betriebssystemimages

Die Versionseigenschaft des Bilds muss auf neueste 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 u. a. SAS-URI für die Bootstrap-Nutzdaten in Erweiterungseigenschaften virtueller Computer, Nutzdaten im Speicherkonto und Verweise auf Geheimnisse im Modell.
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.
Der Patchorchestrierungsmodus darf in der Skalierungsgruppen-Modelldefinition nicht auf AutomaticByPlatform festgelegt werden. Wenn für Ihre Skalierungsgruppe automatische Upgrades von Betriebssystemimages aktiviert sind, ist kein Patchingprozess für die Plattformorchestrierung 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.
Weitere Integritätstests oder die Verwendung einer Anwendungsintegritätserweiterung ist für die Dauerhaftigkeitsstufen „Silber“ oder „Gold“ 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.

Die Dauerhaftigkeitseinstellungen im Service Fabric-Cluster und für die Service Fabric-Erweiterung dürfen miteinander 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 Version des Azure Compute Gallery-Images aktualisiert, wenn eine neue Version des Images veröffentlicht und in der Region 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 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 Version für das betreffende Katalogimage ausgeschlossen werden. Für Imageversionen, die aus der 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 Upgraderichtlinie mode, 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 --enable-auto-os-upgrade true --upgrade-policy-mode Rolling

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 --enable-auto-os-upgrade true --upgrade-policy-mode Rolling

Hinweis

Nach dem Konfigurieren automatischer Upgrades von Betriebssystemimages für Ihre Skalierungsgruppe müssen Sie die virtuellen Computer der Skalierungsgruppen 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 der Anwendungsintegritätserweiterung

Während eines Betriebssystemupgrades werden virtuelle Computer in einer Skalierungsgruppe batchweise nacheinander aktualisiert. Das Upgrade sollte nur fortgesetzt werden, wenn die Kundenanwendung auf den aktualisierten virtuellen Computern 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 Energiezustand des virtuellen Computers und den Bereitstellungsstatus der Erweiterung aus, um festzustellen, ob ein virtueller Computer nach einem Upgrade fehlerfrei ist. Während des Betriebssystemupgrades eines virtuellen Computers wird dessen Betriebssystemdatenträger durch einen neuen Datenträger ersetzt, der auf der aktuellen Imageversion basiert. Nachdem das Betriebssystemupgrade abgeschlossen wurde, werden die konfigurierten Erweiterungen auf diesen virtuellen Computern 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 einem virtuellen Computer in einer Skalierungsgruppe 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 davon entfernen, bevor Sie Orchestrierungsdienste wie Instanzreparaturen oder automatische Betriebssystemupgrades nutzen.

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 Dauerhaftigkeitseigenschaften von Service Fabric-Clustern finden Sie in dieser Dokumentation.

Verwenden der Anwendungsintegritätserweiterung

Die Erweiterung für die Anwendungsintegrität wird in einer VM-Skalierungsgruppeninstanz bereitgestellt und meldet von dieser aus die Integrität des virtuellen Computers. 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 die Integrität meldet, 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

Konfigurieren von benutzerdefinierten Metriken für rollierende Upgrades auf Virtual Machine Scale Sets (Vorschau)

Hinweis

Benutzerdefinierte Metriken für rollierende Upgrades auf Virtual Machine Scale Sets befinden sich derzeit in der Vorschau. Vorschauversionen werden Ihnen zur Verfügung gestellt, wenn Sie die zusätzlichen Nutzungsbedingungen akzeptieren. Einige Aspekte dieser Features werden bis zur allgemeinen Verfügbarkeit unter Umständen noch geändert.

Mit benutzerdefinierten Metriken für rollierende Upgrades können Sie die Anwendungsintegritätserweiterung verwenden, um benutzerdefinierte Metriken an Ihre Virtual Machine Scale Sets zu senden. Diese benutzerdefinierten Metriken können verwendet werden, um dem Skalierungssatz mitzuteilen, in welcher Reihenfolge virtuelle Computer aktualisiert werden sollen, wenn ein rollierendes Upgrade ausgelöst wird. Die benutzerdefinierten Metriken können Ihren Skalierungssatz auch informieren, wenn ein Upgrade für eine bestimmte Instanz übersprungen werden soll. Auf diese Weise können Sie mehr Kontrolle über die Reihenfolge und den Aktualisierungsprozess selbst haben.

Benutzerdefinierte Metriken können in Kombination mit anderen rollierenden Upgradefunktionen verwendet werden, z. B. automatische Betriebssystemupgrades, automatische Erweiterungsupgrades und rollierende MaxSurge-Upgrades.

Weitere Informationen finden Sie unter Konfigurieren von benutzerdefinierten Metriken für rollierende Upgrades auf Virtual Machine Scale Sets.

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.

Ihre Anmeldeinformationen müssen aktuell sein

Wenn Ihre Skalierungsgruppe Anmeldeinformationen für den Zugriff auf externe Ressourcen verwendet, z. B. eine Erweiterung eines virtuellen Computers, die für die Verwendung eines SAS-Tokens für das Speicherkonto konfiguriert wurde, überprüfen Sie, ob die Anmeldeinformationen aktuell sind. Wenn Anmeldeinformationen wie Zertifikate und Token abgelaufen sind, kommt es beim Upgrade zu einem Fehler, und der erste Batch virtueller Computer wechselt in den Status „Fehler“.

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

Generieren Sie das Token (oder andere Anmeldeinformationen) neu, die an Ihre Erweiterungen übergeben wurden.
Prüfen Sie, ob die auf dem virtuellen Computer verwendeten Anmeldeinformationen für die Kommunikation mit externen Entitäten aktuell sind.
Aktualisieren Sie Erweiterungen im Skalierungsgruppenmodell mit den neuen Token.
Stellen Sie die aktualisierte Skalierungsgruppe bereit, um alle virtuellen Computer – einschließlich der fehlerhaften – zu aktualisieren.

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

Nutzen von Aktivitätsprotokollen für Upgradebenachrichtigungen und Insights

Das Aktivitätsprotokoll ist ein Abonnementprotokoll, das Einblicke in Ereignisse auf Abonnementebene ermöglicht, die in Azure aufgetreten sind. Kunden können Folgendes tun:

Anzeigen von Ereignissen im Zusammenhang mit Vorgängen, die mit ihren Ressourcen im Azure-Portal ausgeführt werden
Erstellen von Aktionsgruppen zum Optimieren von Benachrichtigungsmethoden wie E-Mail, SMS, Webhooks oder ITSM
Einrichten geeigneter Warnungen, die an Aktionsgruppen gesendet werden sollen, mithilfe von Portal, ARM-Ressourcenvorlage, PowerShell oder CLI

Kunden erhalten drei Arten von Benachrichtigungen im Zusammenhang mit dem Vorgang des automatischen Betriebssystemupgrades:

Senden der Upgradeanforderung für eine bestimmte Ressource
Ergebnis der Übermittlungsanforderung zusammen mit allen Fehlerdetails
Ergebnis des Upgradeabschlusses zusammen mit allen Fehlerdetails

Einrichten von Aktionsgruppen für Aktivitätsprotokollbenachrichtigungen

Eine Aktionsgruppe ist eine Sammlung von Benachrichtigungseinstellungen, die vom Besitzer eines Azure-Abonnements festgelegt werden. Azure Monitor- und Service Health-Warnungen verwenden Aktionsgruppen, um Benutzer zu benachrichtigen, dass eine Warnung ausgelöst wurde.

Aktionsgruppen können erstellt und verwaltet werden mit:

Kunden können die folgenden Aktionen mithilfe von Aktionsgruppen einrichten:

SMS- und/oder E-Mail-Benachrichtigungen
Webhooks: Kunden können Webhooks an ihre Automatisierungsrunbooks anfügen und ihre Aktionsgruppen so konfigurieren, dass die Runbooks ausgelöst werden. Ein Runbook kann über einen Webhook gestartet werden.
ITSM-Verbindungen

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 für parallele Upgrades ausgeführt wird. Mit dem Befehl zum Abrufen der Instanzansicht können Sie für einen virtuellen Computer 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

Ein Fehler des virtuellen Computers wird ausgelöst.
In der detaillierten Fehlermeldung ist angegeben, ob das Rollout basierend auf dem konfigurierten Schwellenwert fortgesetzt oder angehalten wird.

MaxUnhealthyUpgradedInstancePercentExceededInRollingUpgrade

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

MaxUnhealthyInstancePercentExceededInRollingUpgrade

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

MaxUnhealthyInstancePercentExceededBeforeRollingUpgrade

Der Fehler wird ausgelöst, wenn der Prozentsatz der fehlerhaften virtuellen Computer vor einem Upgrade den maximal zulässigen Schwellenwert für fehlerhafte virtuelle Computer überschreitet.
Die detaillierte Fehlermeldung zeigt den aktuellen Prozentsatz und den konfigurierten zulässigen Prozentsatz fehlerhafter virtueller Computer 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

Freigeben über

Automatische Betriebssystemimageupgrades mit Azure-VM-Skalierungsgruppen

Wie funktioniert das automatische Upgrade von Betriebssystemimages?

Verfügbarkeitsupdates

Aktualisieren 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 der Anwendungsintegritätserweiterung

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

Verwenden der Anwendungsintegritätserweiterung

Konfigurieren von benutzerdefinierten Metriken für rollierende Upgrades auf Virtual Machine Scale Sets (Vorschau)

Abrufen des Verlaufs automatischer Betriebssystemimageupgrades

Ihre Anmeldeinformationen müssen aktuell sein

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

Nutzen von Aktivitätsprotokollen für Upgradebenachrichtigungen und Insights

Einrichten von Aktionsgruppen für Aktivitätsprotokollbenachrichtigungen

Untersuchen und Beheben von Fehlern beim automatischen Upgrade

Nächste Schritte

Feedback

Zusätzliche Ressourcen