Upgrade der Clusterlaufzeit von Azure CLI

In diesem Artikel wird erläutert, wie Sie ein Laufzeitupgrade für einen Operator Nexus Cluster durchführen.

Voraussetzungen

1. Installieren Sie die neueste Version der passenden CLI-Erweiterungen.
2. Zugriff auf das Abonnement, um die CLI-Erweiterungsbefehle für Azure Operator Nexus Network Fabric (NF) und -Netzwerkcloud (NC) auszuführen.
3. Sammeln Sie die folgenden Informationen:
   • Abonnement-ID (SUBSCRIPTION)
   • Clustername (CLUSTER)
   • Ressourcengruppe (CLUSTER_RG)
4. Der detaillierte Clusterstatus muss sein Running.
5. Cluster-zu-Cluster-Manager-Konnektivität muss sein Connected.
6. Azure Voraussetzungen (Log Analytics Workspace, Storage Account, Key Vault) müssen überprüft werden. Diese Ressourcen werden überprüft, bevor das Upgrade beginnt. Siehe clusterverwaltete Identität und vom Benutzer bereitgestellte Ressourcen.
7. Unter >Clusterworkload->Computeservern
   • Die Anforderungen an den Zustand der Control-Plane-Knoten vor dem Upgrade sind:
     • Wenn kein Ersatzknoten der Steuerungsebene vorhanden ist, müssen alle Steuerungsebenen-Knoten in einem einwandfreien Zustand sein: Energiezustand On, Cordon-Status Uncordoned, Bereitschaftsstatus Yes und Degraded No.
     • Wenn ein Ersatz-Steuerebenenknoten vorhanden ist, kann sich nur der Ersatzknoten im Energiezustand Off, im Bereitschaftszustand No und im Zustand „Degradiert“ No befinden. Jeder andere Knoten der Steuerungsebene muss funktionsfähig sein: Energiestatus On, Sperrstatus Uncordoned, Bereitschaftsstatus Yes und „Heruntergestuft“ No.

     Hinweis

     Wenn der Ersatzcomputer der Steuerungsebene zuvor einen Bereitstellungsprozess durchlaufen hat, sollte er sich im Sperrstatus Cordoned befinden. Wenn nicht, sollte es im Status „Cordon“ sein Uncordoned.

   • Die Server der Verwaltungsebene sind in zwei Gruppen unterteilt, die sich auf ungerade und gerade nummerierte Racks verteilen. In jeder Gruppe müssen mehr als 50 % der Server funktionsfähig sein: Energiezustand On, Cordon-Status Uncordoned, Bereitschaftsstatus Yes und degradiert No.
     • In beiden Managementebenengruppen müssen mindestens 75% der Verwaltungsmaschinen fehlerfrei sein.
   • Compute-Plane-Servernummern variieren je nach den individuellen Schwellenwerteinstellungen für die Clusterlaufzeit. Kunden müssen ihre Mindestanzahl basierend auf ihren Einstellungen ermitteln, indem sie nach Energiestatus On, Sperrstatus Uncordoned, Bereitschaftsstatus Yes und Herabgestuft No suchen.
8. Wählen Sie unter "Clusterverwaltete > Ressourcengruppe" den Gruppennamen aus, um zur Seite "Ressourcengruppe" zu wechseln.
   • Suchen Sie in der Ressourcengruppe nach Kubernetes - Azure Arc, um die Azure Arc Informationen zu identifizieren und auszuwählen. Der Status sollte sein Connected.
     • Wählen Sie auf der Azure Arc-Seite „Einstellungen > Erweiterungen“ aus.
       • nc-platform-extension sollte sich im Status Succeededbefinden.
       • nc-platform-runtime-extension sollte sich im Status Succeededbefinden.

Überprüfen der aktuellen Laufzeitversion

Überprüfen Sie vor dem Upgrade die aktuelle Cluster-Laufzeitversion: Siehe So überprüfen Sie die aktuelle Cluster-Laufzeitversion.

Suchen aller verfügbaren Runtimeversionen

Über das Azure-Portal

Um verfügbare upgradefähige Laufzeitversionen zu finden, navigieren Sie im Azure portal zum Zielcluster. Navigieren Sie im Übersichtsbereich des Clusters zur Registerkarte "Verfügbare Upgradeversionen ".

Auf der Registerkarte "Verfügbare Upgradeversionen " können Sie die verschiedenen Clusterversionen sehen, die für das Upgrade verfügbar sind. Wählen Sie die Ziellaufzeitversion aus der Liste aus, und fahren Sie dann mit dem Upgrade des Clusters fort.

Mithilfe der Azure-CLI

Verfügbare Upgrades können über die Azure CLI abgerufen werden:

az networkcloud cluster show --name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--subscription "<SUBSCRIPTION>" | grep -A8 availableUpgradeVersions

In der Ausgabe finden Sie die availableUpgradeVersions-Eigenschaft. Sehen Sie sich das Feld targetClusterVersion an:

  "availableUpgradeVersions": [
    {
      "controlImpact": "True",
      "expectedDuration": "Upgrades may take up to 4 hours + 2 hours per rack",
      "impactDescription": "Workloads will be disrupted during rack-by-rack upgrade",
      "supportExpiryDate": "2023-07-31",
      "targetClusterVersion": "3.3.0",
      "workloadImpact": "True"
    }
  ],

Wenn keine Clusterupgrades verfügbar sind, ist die Liste leer.

Konfigurieren Sie Berechnungsschwellenwerte für das Laufzeit-Upgrade mithilfe von Cluster updateStrategy

Der folgende Azure CLI Befehl wird verwendet, um die Berechnungsschwellenwerte für ein Laufzeitupgrade zu konfigurieren:

az networkcloud cluster update \
--name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--subscription "<SUBSCRIPTION>" \
--update-strategy strategy-type="<strategyType>" threshold-type="<thresholdType>" \
threshold-value="<thresholdValue>" max-unavailable="<maxNodesOffline>" \
wait-time-minutes="<waitTimeBetweenRacks>"

Erforderliche Parameter:

• strategy-type: Definiert die Updatestrategie. Die verwendeten Einstellungen sind Rack (Rack-by-Rack) OR PauseAfterRack (Pause für Benutzer, bevor jedes Rack gestartet wird). Der Standardwert ist Rack. Führen Sie ein Cluster-Laufzeitupgrade mithilfe der PauseAfterRack Strategie durch, indem Sie die Schritte ausführen, die im Upgrade der Cluster-Laufzeit mit der PauseAfterRack-Strategie beschrieben sind.
• threshold-type: Bestimmt, wie der Schwellenwert ausgewertet werden soll, und wird in den Einheiten angewendet, die durch die Strategie definiert sind. Verwendete Einstellungen sind PercentSuccess OR CountSuccess. Der Standardwert ist PercentSuccess.
• threshold-value: Der numerische Schwellenwert, der zum Auswerten einer Aktualisierung verwendet wird. Der Standardwert ist 80.

Optionale Parameter:

• max-unavailable: Die maximale Anzahl von Workerknoten, die offline sein können, d. h. jeweils ein Rack wird aktualisiert. Der Standardwert ist 32767.
• wait-time: Verzögerung oder Wartezeit vor dem Aktualisieren eines Racks. Der Standardwert ist 15.

Upgradeverhalten basierend auf dem Schwellenwerttyp "PercentSuccess"

Das folgende Beispiel ist für einen Kunden, der die Rack-by-Rack-Strategie mit einer Erfolgsrate von 60 %% und einer 1-minütigen Pause verwendet.

az networkcloud cluster update --name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--update-strategy strategy-type="Rack" threshold-type="PercentSuccess" \
threshold-value=60 wait-time-minutes=1 \
--subscription "<SUBSCRIPTION>"

Überprüfen von Updates:

az networkcloud cluster show --name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--subscription "<SUBSCRIPTION>" | grep -A5 updateStrategy

  "updateStrategy": {
    "maxUnavailable": 32767,
      "strategyType": "Rack",
      "thresholdType": "PercentSuccess",
      "thresholdValue": 60,
      "waitTimeMinutes": 1

Sobald in diesem Beispiel 60% der Maschinen in einem Rack erfolgreich aktualisiert wurden, berücksichtigt das System den erreichten Schwellenwert und setzt fort, das nächste Rack zu aktualisieren, während alle verbleibenden Maschinen im aktuellen Rack weiterhin bereitgestellt werden. Wenn der Schwellenwert nicht erreicht ist – was bedeutet, dass weniger als 60% der Computer im Rack upgraden konnten und stattdessen fehlgeschlagen sind, wird das Clusterupgrade angehalten. Wenn ein Upgrade angehalten wird, stellt das System eine detaillierte Statusmeldung im Cluster bereit, die den Grund erklärt. Zu diesem Zeitpunkt müssen die problematischen Maschinen im Rack repariert werden, und ein Vorgang zur Fortsetzung der Aktualisierungsversion des Clusters muss ausgelöst werden, um das Upgrade abzuschließen und fortzusetzen.

Um den Upgradestatus über die Azure portal anzuzeigen, navigieren Sie zur zielbezogenen Clusterressource. Auf dem Bildschirm "Clusterübersicht " wird der detaillierte Status zusammen mit einer detaillierten Statusmeldung bereitgestellt.

Die Clusterbereitstellung ist in Bearbeitung, wenn „detailedStatus“ auf Updating festgelegt ist und „detailedStatusMessage“ den Fortschritt der Bereitstellung anzeigt. Einige Beispiele für den Upgradefortschritt in detailedStatusMessage sind Waiting for control plane upgrade to complete..., Waiting for nodepool "<rack-id>" to finish upgrading... usw.

Das Clusterupgrade ist abgeschlossen, wenn „detailedStatus“ auf Running gesetzt ist und „detailedStatusMessage“ die Meldung Cluster is up and running anzeigt.

Wenn das Upgrade in der detaillierten Statusmeldung angehalten wird, sieht die Meldung wie folgt aus: Cluster is deployed but the upgrade has been paused. Machines in rack "<rack-id>" are unhealthy. Fix the machines and perform cluster continue-update-version action to finish the upgrade

Führen Sie zum Fortsetzen des Laufzeitupgrades den folgenden Az networkcloud cli-Befehl aus.

az networkcloud cluster continue-update-version --cluster-name "<CLUSTER>" \
--resource-group="<CLUSTER_RG>" \
--subscription="<SUBSCRIPTION>" \
--safeguard-mode <SAFEGUARD_MODE>

Optionale Parameter:

• --safeguard-mode: Gibt an, wie Sicherheitsmechanismen beim Vorgang „continue-update-version“ angewendet werden. Verwenden Sie All, um alle Validierungsprüfungen vor dem Vorgang auszuführen. Wird None verwendet, um Schutzmaßnahmen zu umgehen, die das Upgrade blockieren, wenn probleme erkannt werden. Der Standardwert ist All.

Upgradeverhalten basierend auf dem Schwellentyp „CountSuccess“

Das folgende Beispiel ist für einen Kunden, der rack-by-Rack-Strategie mit einer Schwellenwertart CountSuccess von 10 Knoten pro Rack und einer Pause von 1 Minuten verwendet.

az networkcloud cluster update --name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--update-strategy strategy-type="Rack" threshold-type="CountSuccess" \
threshold-value=10 wait-time-minutes=1 \
--subscription "<SUBSCRIPTION>"

Überprüfen von Updates:

az networkcloud cluster show --name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--subscription "<SUBSCRIPTION>" | grep -A5 updateStrategy

  "updateStrategy": {
    "maxUnavailable": 32767,
      "strategyType": "Rack",
      "thresholdType": "CountSuccess",
      "thresholdValue": 10,
      "waitTimeMinutes": 1

In diesem Beispiel wechselt das Upgrade zum nächsten Rack, wenn mindestens 10 Knoten erfolgreich aktualisiert werden, während die verbleibenden Maschinen im aktuellen Rack weiterhin bereitgestellt werden. Wenn mindestens 10 Computer im Rack nicht aktualisiert werden können, wird das Clusterupgrade angehalten. In diesem Fall muss die erforderliche Hardware repariert werden, bevor die Aktion zur Weiterführung des Versionsupdates ausgeführt wird, um das Upgrade abzuschließen.

Informationen zur Problembehandlung bei Bare-Metal-Computern finden Sie unter Fehlerbehebung bei Azure Operator Nexus-Serverproblemen

Überprüfungen, die das Clusterlaufzeitupgrade blockieren können

Wenn Sie ein Cluster-Laufzeitupgrade auslösen, führt der Prozess eine Reihe von Vorabupgradeüberprüfungen aus, bevor das Laufzeitupgrade auf den Cluster-Bare-Metal-Computern gestartet wird. Diese Überprüfungen bestätigen, dass das Laufzeitupgrade aufgrund des aktuellen Status des Clusters erfolgreich ausgeführt werden kann. Weitere Informationen finden Sie unter Vorabvalidierungen für das Upgrade der Clusterlaufzeit.

Upgrade der Clusterlaufzeit mit CLI

Um die Clusterlaufzeitversion zu aktualisieren, verwenden Sie den folgenden Azure CLI Befehl:

az networkcloud cluster update-version\
--cluster-name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--subscription "<SUBSCRIPTION>" \
--target-cluster-version "<versionNumber>" \
--safeguard-mode "<SAFEGUARD_MODE>"

Erforderliche Parameter:

• --target-cluster-version: Die Version, die während des Updates auf den Cluster angewendet werden soll.

Optionale Parameter:

• --safeguard-mode: Gibt an, wie Sicherheitsvorkehrungen während des Updateversionsvorgangs angewendet werden. Verwenden Sie All, um alle Validierungsprüfungen vor dem Vorgang auszuführen. Wird None verwendet, um Schutzmaßnahmen zu umgehen, die das Upgrade blockieren, wenn probleme erkannt werden. Der Standardwert ist All.

Dieser Befehl initiiert den Laufzeitupgradeprozess für den angegebenen Cluster. Der Befehl selbst endet in der Regel innerhalb von etwa fünf Minuten, aber er startet nur den Upgradevorgang, nachdem die Überprüfung erfolgreich war. Das eigentliche Laufzeit-Upgrade läuft im Hintergrund weiter und kann mehrere Stunden dauern, da es Knoten Rack für Rack aktualisiert und die neue Betriebssystemversion installiert.

Detaillierte Status- und Diagnoseinformationen für den Initiierungsschritt sind in Azure portal in der ressource JSON View der Ressource Cluster (Operator Nexus) verfügbar. Die folgenden Informationen sind im updateVersion Eintrag des properties.actionStates Felds enthalten, wenn Sie die API-Version 2025-07-01-preview oder höher verwenden.

• Start- und Endzeit der Aktion.
• Aktueller Status (Succeeded, Failedoder InProgress).
• Alle zusätzlichen Kontext- oder Fehlermeldungen, die dem aktuellen Status zugeordnet sind.
• Die Korrelations-ID für den ursprünglichen cluster update-version-Vorgang, wie auch im Azure Aktivitätsprotokoll gezeigt.
• Eine sortierte Liste der einzelnen Schritte und deren Status , z. B Validate Cluster conditions and upgrade versions. und Initiate Platform Runtime Extension update.

JSON View-Beispielausgabe für die Clusterressource (Operator Nexus):

{
  "properties": {
    "actionStates": [
      {
        "correlationId": "aaaa0000-bb11-2222-33cc-444444dddddd",
        "status": "Completed",
        "actionType": "Microsoft.NetworkCloud/clusters/updateVersion",
        "endTime": "2025-08-01T03:46:13Z",
        "message": "Cluster upgrade to 4.6.0 successfully initiated - monitor progress via cluster detailed status",
        "startTime": "2025-08-01T03:42:08Z",
        "stepStates": [
          {
            "status": "Completed",
            "endTime": "2025-08-01T03:42:08Z",
            "message": "Cluster validation and version checks passed",
            "startTime": "2025-08-01T03:42:08Z",
            "stepName": "Validate Cluster conditions and upgrade versions"
          },
          {
            "status": "Completed",
            "endTime": "2025-08-01T03:46:11Z",
            "message": "Platform Runtime Extension deployment initiated",
            "startTime": "2025-08-01T03:42:39Z",
            "stepName": "Initiate Platform Runtime Extension update"
          },
          {
            "status": "Completed",
            "endTime": "2025-08-01T03:46:11Z",
            "message": "Platform Runtime Extension installation completed",
            "startTime": "2025-08-01T03:46:11Z",
            "stepName": "Monitor Platform Runtime Extension readiness"
          },
          {
            "status": "Completed",
            "endTime": "2025-08-01T03:46:13Z",
            "message": "Platform Cluster version updated successfully",
            "startTime": "2025-08-01T03:46:13Z",
            "stepName": "Update Platform Cluster version specification"
          }
        ]
      }
    ]
  }
}

Nach Abschluss dieses Befehls beginnt der vollständige Laufzeitupgradeprozess. Dieser Vorgang kann je nach Anzahl der Racks im Cluster und der Anzahl der Arbeitsknoten in jedem Rack mehrere Stunden dauern.

• Beim Upgrade werden zunächst die Steuerungsebenenknoten, dann die Verwaltungsknoten und anschließend die Workerknoten sequentiell Rack für Rack aktualisiert.
• Die Verwaltungsserver sind in zwei Gruppen unterteilt, die separat aktualisiert werden. Mit diesem Ansatz können Komponenten, die auf den Verwaltungsservern ausgeführt werden, die Resilienz während des Laufzeitupgrades durch Anwenden von Affinitätsregeln sicherstellen.
• Die Clouddienstnetzwerke (CSNs) verwenden diese Funktionalität auch, indem eine Instanz in jeder Verwaltungsgruppe platziert wird.
• Es gibt keine Kundeninteraktion mit dieser Funktionalität. Es können jedoch auf Verwaltungsknoten auch andere Bezeichnungen zur Kennzeichnung der Gruppen verwendet werden.

Das Upgrade gilt als abgeschlossen, wenn die durch das updateStrategy des Clusters für Worker-Node-Racks konfigurierten Schwellenwerte erreicht sind und mindestens 50 % der Verwaltungsknoten in jeder Gruppe erfolgreich aktualisiert wurden. Workloads können betroffen sein, während die Workerknoten in einem Rack aktualisiert werden, Workloads jedoch in allen anderen Racks nicht betroffen sind. Angesichts dieses Implementierungsdesigns sollte über die Platzierung von Workloads nachgedacht werden.

Überwachen Sie den Fortschritt mithilfe des detaillierten Status des Clusters, verfügbar über das Azure Portal oder Azure CLI.

Um den Upgradestatus über die Azure CLI anzuzeigen, verwenden Sie az networkcloud cluster show.

az networkcloud cluster show --cluster-name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--subscription "<SUBSCRIPTION>"

Die Ausgabe enthält die Informationen des Zielclusters zusammen mit dem detaillierten Status und der detaillierten Statusmeldung. Für detailliertere Einblicke in den Upgradefortschritt können die einzelnen Knoten in jedem Rack auf den Status überprüft werden. Ein Beispiel finden Sie im Referenzabschnitt unter BareMetal Machine-Rollen.

Um den Upgradestatus über das Azure-Portal anzuzeigen, wechseln Sie zur Zielclusterressource. Auf dem Bildschirm "Übersicht " des Clusters können Sie den detaillierten Status zusammen mit einer detaillierten Statusmeldung anzeigen.

Das Cluster-Upgrade läuft, wenn detailedStatus auf Updating festgelegt ist und detailedStatusMessage den Fortschritt des Upgrades anzeigt. Einige Beispiele für den Fortschritt des Upgrades detailedStatusMessage sind Waiting for control plane upgrade to complete... und Waiting for nodepool "<rack-id>" to finish upgrading....

Das Cluster-Upgrade ist abgeschlossen, wenn detailedStatus auf Running gesetzt ist und detailedStatusMessageCluster is up and running anzeigt.

Das Cluster-Upgrade wird pausiert, wenn detailedStatus auf Updating festgelegt ist, und detailedStatusMessage zeigt den Grund oder die Komponente an, die zur Pausierung des Upgrades geführt hat.

Pausierte Cluster-Laufzeitaktualisierung

Das Upgrade wird angehalten, wenn eine der folgenden Aktionen auftritt:

1. Alle Maschinen der Control Plane können nicht erfolgreich aktualisiert werden und sind weder bereitgestellt noch einsatzbereit.
2. Mehr als 50 % der Maschinen in einer Gruppe der Verwaltungsebene können weder aktualisiert werden noch sind sie bereitgestellt und einsatzbereit. Die Server der Verwaltungsebene sind in zwei Gruppen unterteilt, die sich auf ungerade und gerade nummerierte Racks verteilen.
3. Compute - oder Workerknotencomputer, die pro Schwellenwert konfiguriert sind, können nicht aktualisiert werden und sind weder bereitgestellt noch bereit.

Überprüfen Sie die detaillierte Statusmeldung des Clusters, um zu ermitteln, welche Komponente dazu führte, dass das Upgrade in einen angehaltenen Zustand versetzt wurde. Die folgenden Beispiele zeigen detaillierte Statusmeldungen für jede Komponente.

Detaillierte Statusmeldung zum Ausfall der Kontrollebene (KCP)

• Cluster ist bereitgestellt, aber das Upgrade wurde pausiert. Upgrade der Steuerungsebene ist fehlgeschlagen, da <clusterName> fehlerhaft ist. MachineHealthCheck tauscht möglicherweise fehlerhafte KCP-Computer mit Verwaltungsebenencomputern aus, um das Quorum wiederherzustellen. Warten Sie, bis die Korrektur abgeschlossen ist, und führen Sie dann die Aktion "Continue-update-version" aus, um das Upgrade abzuschließen."

Detaillierte Statusmeldung zum Gruppenfehler auf Compute- oder Verwaltungsebene

• Cluster wurde bereitgestellt, aber das Upgrade wurde pausiert. Computer im Rack „<Rack-ID>“ sind fehlerhaft. Reparieren Sie die Maschinen und führen Sie die Aktion „cluster continue-update-version“ aus, um das Upgrade abzuschließen.

Führen Sie nach der Identifizierung der betroffenen Komponente (Steuerungsebene, Verwaltung oder Berechnung) die folgenden Schritte aus:

Schritt 1: Überprüfen Sie den Status einzelner Bare-Metal-Maschinen für die betroffene Komponente.

Ein Beispiel findet sich im Referenzabschnitt unter BareMetal Machine roles.

Nachdem Sie die Bare Metal-Maschinen für die betroffene Komponente identifiziert haben, überprüfen Sie den Status jeder Maschine, und führen Sie die folgenden Aktionen basierend auf ihrem Zustand aus.

Schritt 2: Überprüfen sie Aktionsstatusprotokolle für das BMM.

Um Aktionsstatusprotokolle für ein BMM zu überprüfen, navigieren Sie zum> für BMM-Ressourcenvorgänge>.

Sobald das Problem behoben ist und der Baremetal-Computer bereitgestellt und bereit ist, führen Sie die Clusteraktion continue-update-version aus, um das Upgrade fortzusetzen und abzuschließen.

az networkcloud cluster continue-update-version \
-g <CLUSTER_RG> \
-n <CLUSTER_NAME> \
--subscription <CUSTOMER_SUB_ID> \
--safeguard-mode <SAFEGUARD_MODE>

Optionale Parameter:

• --safeguard-mode: Gibt an, wie Sicherheitsmechanismen beim Vorgang „continue-update-version“ angewendet werden. Verwenden Sie All, um alle Validierungsprüfungen vor dem Vorgang auszuführen. Wird None verwendet, um Schutzmaßnahmen zu umgehen, die das Upgrade blockieren, wenn probleme erkannt werden. Der Standardwert ist All.

Häufig gestellte Fragen

Identifizieren, ob das Clusterupgrade angehalten wurde/hängen geblieben ist

Während eines Laufzeitupgrades wechselt der Cluster in einen angehaltenen Zustand, sobald der Upgradevorgang feststellt, dass das Upgrade ohne manuelle Eingriffe nicht fortgesetzt werden kann. Der Upgradeprozess kommt jedoch manchmal nicht weiter, obwohl die detaillierte Statusanzeige das Upgrade weiterhin als laufend anzeigt. Da das Laufzeit-Upgrade sehr lange dauern kann, bis es erfolgreich abgeschlossen ist, ist derzeit keine feste Timeout-Dauer festgelegt. Überprüfen Sie regelmäßig den detaillierten Status und die Protokolle Ihres Clusters, um festzustellen, ob das Upgrade unbegrenzt versucht, ein Upgrade durchzuführen.

Sie können ein auf unbestimmte Zeit hängengebliebenes Upgrade anhand der Protokolle, der Detailmeldung und der detaillierten Statusmeldung des Clusters erkennen. Wenn diese Bedingung auftritt, beobachten Sie, dass der Cluster denselben Zustand kontinuierlich abgleicht, ohne voranzukommen. Überprüfen Sie die Clusterprotokolle oder konfigurierten Log Analytics Workspace (LAW), um festzustellen, ob ein Fehler oder ein bestimmter Schritt zu einem Mangel an Fortschritt führt.

Identifizieren des Bare Metal Machine Upgrades festgefahren/hängen geblieben

Eine Anleitung zum Identifizieren von Problemen mit Bereitstellungs-Workerknoten finden Sie bei der Problembehandlung bei der Bereitstellung von Bare Metal Machine Provisioning.

Hardwarefehler erfordert keine erneute Ausführung des Upgrades

Wenn während eines Upgrades ein Hardwarefehler aufgetreten ist, wird das Laufzeitupgrade fortgesetzt, solange die festgelegten Schwellenwerte für die Compute- und Verwaltungs-/Steuerungsknoten erfüllt sind. Sobald der Computer behoben oder ersetzt wurde, wird er mit dem Betriebssystem der aktuellen Plattform-Runtime bereitgestellt, das die Zielversion der Runtime enthält. Wenn ein Rack vor einem Fehler aktualisiert wurde, wird die aktualisierte Runtimeversion verwendet, wenn die Knoten neu bereitgestellt werden. Wenn die Spezifikation des Racks vor dem Hardwarefehler nicht auf die aktualisierte Laufzeitversion aktualisiert wurde, stellt der Computer die vorherige Laufzeitversion bereit, wenn die Hardware repariert wird. Die Maschine wird zusammen mit dem Rack aktualisiert, wenn das Rack mit dem Upgrade beginnt.

Nach einem Laufzeitupgrade zeigt der Cluster den Bereitstellungsstatus "Fehlgeschlagen" an.

Während eines Laufzeitupgrades wechselt der Cluster in einen Zustand von Upgrading. Wenn das Laufzeitupgrade fehlschlägt, wechselt der Cluster in einen Failed Bereitstellungszustand. Infrastrukturkomponenten (z. B. die Storage Appliance) können während des Upgrades Zu Fehlern führen. In einigen Szenarien kann es erforderlich sein, den Fehler mit Microsoft Unterstützung zu diagnostizieren.

Bare Metal Machine wird nach dem Laufzeitupdate als degradiert angezeigt

Unter bestimmten Umständen kann ein Knoten in den Zustand Degraded zurückkehren. Dieser Zustand tritt auf, wenn eine der in Behandlung von Fehlern aufgrund des Status „Heruntergestuft“ aufgeführten Bedingungen erfüllt ist. Herabgestufter Status bedeutet, dass der Knoten automatisch abgebunden wird, um zu verhindern, dass neue Workloads auf dem Knoten geplant werden, bis das zugrunde liegende Problem behoben ist.