Upgraden der Clusterruntime über die Azure CLI

Artikel
03/06/2024

In dieser Anleitung werden die Schritte zum Installieren der erforderlichen Azure CLI und Erweiterungen erläutert, die für die Interaktion mit Operator Nexus erforderlich sind.

Voraussetzungen

Die Azure CLI muss zuerst installiert werden.
Die networkcloud CLI-Erweiterung ist erforderlich. Wenn die networkcloud-Erweiterung nicht installiert ist, kann sie mithilfe der hier aufgeführten Schritte installiert werden.
Zugriff auf das Azure-Portal für das Upgrade des Zielclusters.
Sie müssen über az login bei demselben Abonnement wie Ihr Zielcluster angemeldet sein.
Der Zielcluster muss sich in einem ausgeführten Zustand befinden, wobei alle Steuerebenenknoten fehlerfrei seien und 80 + % der Computeknoten in einem ausgeführten und fehlerfreien Zustand ausgeführt werden müssen.

Suchen aller verfügbaren Runtimeversionen

Über das Portal

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

Auf der Registerkarte Verfügbare Upgradeversionen sind die verschiedenen Clusterversionen zu sehen, die derzeit für das Upgrade verfügbar sind. Der Operator kann aus den aufgelisteten Ziellaufzeitversionen auswählen. Fahren Sie nach der Auswahl mit dem Upgrade des Clusters fort.

Über Azure-Befehlszeilenschnittstelle

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

az networkcloud cluster show --name "clusterName" --resource-group "resourceGroup"

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.

Upgraden der Clusterruntime über die CLI

Verwenden Sie den folgenden Azure CLI-Befehl, um ein Upgrade der Runtime auszuführen:

az networkcloud cluster update-version --cluster-name "clusterName" --target-cluster-version
  "versionNumber" --resource-group "resourceGroupName"

Das Runtime-Upgrade ist ein langer Prozess. Das Upgrade aktualisiert zuerst die Verwaltungsknoten und dann sequenziell Rack für Rack die Workerknoten. Das Upgrade gilt als abgeschlossen, wenn 80 % der Workerknoten pro Rack und 100 % der Verwaltungsknoten erfolgreich aktualisiert wurden. Workloads können beeinträchtigt sein, während sich die Workerknoten in einem Rack im Upgrade befinden, Workloads in allen anderen Racks sind jedoch nicht betroffen. Angesichts dieses Implementierungsdesigns sollte über die Platzierung von Workloads nachgedacht werden.

Das Upgrade aller Knoten dauert mehrere Stunden, kann aber länger dauern, wenn andere Prozesse, z. B. Firmwareupdates, ebenfalls Teil des Upgrades sind. Aufgrund der Länge des Upgradevorgangs wird empfohlen, den Detailstatus des Clusters regelmäßig auf den aktuellen Status des Upgrades zu überprüfen. Um den Status des Upgrades zu überprüfen, beobachten Sie den detaillierten Status des Clusters. Diese Prüfung kann über das Portal oder die az CLI erfolgen.

Um den Upgradestatus über das Azure-Portal anzuzeigen, navigieren Sie zur Zielclusterressource. Auf dem Bildschirm Übersicht des Clusters 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.

Verwenden Sie az networkcloud cluster show, um den Upgradestatus über die Azure CLI anzuzeigen.

az networkcloud cluster show --cluster-name "clusterName" --resource-group "resourceGroupName"

Die Ausgabe sollte die Informationen des Zielclusters sein, und die detaillierte Status- und Detailstatusmeldung des Clusters sollte vorhanden sein. Für detailliertere Einblicke in den Upgradefortschritt kann der Status der einzelnen BMM in jedem Rack überprüft werden. Dieses Beispiel wird im Referenzabschnitt unter BareMetal-Computer-Rollen bereitgestellt.

Konfigurieren von Computeschwellenwerten für das Runtime-Upgrade mithilfe von updateStrategy für Cluster

Der folgende Azure CLI-Befehl wird verwendet, um die Computeschwellenwerte für ein Runtimeupgrade zu konfigurieren:

az networkcloud cluster update --name "<clusterName>" --resource-group "<resourceGroup>" --update-strategy strategy-type="Rack" threshold-type="PercentSuccess" threshold-value="<thresholdValue>" max-unavailable=<maxNodesOffline> wait-time-minutes=<waitTimeBetweenRacks>

Erforderliche Argumente:

strategy-type: Definiert die Updatestrategie. In diesem Fall bedeutet „Rack“, dass Updates Rack für Rack durchgeführt werden. Der Standardwert ist „Rack“.
threshold-type: Bestimmt, wie der Schwellenwert ausgewertet werden soll, und wird in den Einheiten angewendet, die durch die Strategie definiert sind. Der Standardwert ist „PercentSuccess“.
threshold-value: Der numerische Schwellenwert, der zum Auswerten einer Aktualisierung verwendet wird. Der Standardwert ist 80.

Optionale Argumente:

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 lautet 15.

Eine exemplarische Verwendung für den Befehl:

az networkcloud cluster update --name "cluster01" --resource-group "cluster01-rg" --update-strategy strategy-type="Rack" threshold-type="PercentSuccess" threshold-value=70 max-unavailable=16 wait-time-minutes=15

Nach erfolgreicher Ausführung des Befehls werden die angegebenen updateStrategy-Werte auf den Cluster angewendet:

  "updateStrategy": {
      "maxUnavailable": 16,
      "strategyType": "Rack",
      "thresholdType": "PercentSuccess",
      "thresholdValue": 70,
      "waitTimeMinutes": 15,
    },

Häufig gestellte Fragen

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

Während eines Runtime-Upgrades kann es vorkommen, dass das Upgrade nicht fortgesetzt wird, der Detailstatus aber anzeigt, dass das Upgrade noch läuft. Da das Abschließen des Runtime-Upgrades sehr lange dauern kann, gibt es derzeit keine festgelegte Timeoutdauer. Daher ist es ratsam, auch regelmäßig den Detailstatus und die Protokolle Ihres Clusters zu überprüfen, um zu ermitteln, ob Ihr Upgrade unbegrenzt versucht, ein Upgrade durchzuführen.

Das kann festgestellt werden, indem Sie die Protokolle, die detaillierte Nachricht und die detaillierte Statusmeldung des Clusters betrachten. Wenn ein Timeout aufgetreten ist, würden wir beobachten, dass der Cluster sich ununterbrochen abstimmt und nicht vorwärts kommt. Wir empfehlen, die Clusterprotokolle oder die konfigurierte LAW zu überprüfen, um festzustellen, ob es einen Fehler oder ein bestimmtes Upgrade gibt, das die Ursache für den fehlenden Fortschritt ist.

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 Hardwarefehler auftritt und das Runtime-Upgrade fehlgeschlagen ist, da Schwellenwerte für Compute- und Steuerungsknoten nicht erfüllt wurden, kann die erneute Ausführung des Runtime-Upgrades je nach Auftreten des Fehlers und des Zustands der einzelnen Server in einem Rack erforderlich sein. 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 Runtimeversion aktualisiert wurde, wird der Computer mit der vorherigen Runtimeversion bereitgestellt. Um ein Upgrade auf die neue Runtimeversion durchzuführen, übermitteln Sie eine neue Clusterupgradeanforderung, und nur die Knoten mit der vorherigen Runtimeversion werden aktualisiert. Hosts, die in der vorherigen Upgradeaktion erfolgreich waren, werden nicht ausgeführt.

Nach einem Runtime-Upgrade zeigt der Cluster den Bereitstellungsstatus „Fehlgeschlagen“ an.

Während eines Runtime-Upgrades wechselt der Cluster in den Status Upgrading. Im Falle eines Fehlers des Runtime-Upgrades wechselt der Cluster aus Gründen im Zusammenhang mit den Ressourcen in einen Failed-Bereitstellungsstatus. Dieser Status könnte mit dem Lebenszyklus der mit dem Cluster verbundenen Komponenten (z. B. StorageAppliance) verknüpft sein und die Fehlerdiagnose durch den Microsoft-Support erforderlich machen.

Share via