Upgraden der Clusterruntime über die Azure CLI

Artikel
12/23/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.

Überprüfen der aktuellen Laufzeitversion

Überprüfen Sie die aktuelle Clusterlaufzeitversion vor dem Upgrade: Überprüfen der aktuellen Clusterlaufzeitversion.

Suchen aller verfügbaren Runtimeversionen

Verwenden des Azure-Portals

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>" /
--subscription <subscriptionID>

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 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> /
--subscription <subscriptionID>

Erforderliche Parameter:

strategy-type: Definiert die Updatestrategie. Dies kann "Rack" (ein Rack nach dem anderen) ODER "PauseAfterRack" (Ein Rack nach dem anderen aufrüsten und dann auf die Bestätigung warten, bevor mit dem nächsten Rack fortgefahren wird) sein. Der Standardwert ist Rack. Um ein Cluster-Laufzeitupgrade mit der „PauseRack”-Strategie durchzuführen, führen Sie die unter Upgraden der Clusterruntime mit einer PauseRack-Strategie beschriebenen Schritte aus.
threshold-type: Bestimmt, wie der Schwellenwert ausgewertet werden soll, und wird in den Einheiten angewendet, die durch die Strategie definiert sind. Dies kann "PercentSuccess" ODER "CountSuccess" sein. 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.

Das folgende Beispiel zeigt einen Kunden, der die Rack-zu-Rack-Strategie mit einer prozentualen Erfolgsrate von 60 % und einer Pause von 1 Minute verwendet.

az networkcloud cluster update --name "<clusterName>" /
--resource-group "<resourceGroup>" /
--update-strategy strategy-type="Rack" threshold-type="PercentSuccess" /
threshold-value=60 wait-time-minutes=1 /
--subscription <subscriptionID>

Überprüfen von Updates:

az networkcloud cluster show --resource-group "<resourceGroup>" /
--name "<clusterName>" /
--subscription <subscriptionID>| grep -a5 updateStrategy

      "strategyType": "Rack",
      "thresholdType": "PercentSuccess",
      "thresholdValue": 60,
      "waitTimeMinutes": 1

Wenn in diesem Beispiel weniger als 60 % der in einem Rack bereitgestellten Serverknoten nicht bereitgestellt werden (auf Rack-zu-Rack-Basis), schlägt die Clusterbereitstellung fehl. Wenn mindestens 60 % der Serverknoten erfolgreich bereitgestellt werden, wird die Clusterbereitstellung mit dem nächsten Rack mit Serverknoten fortgesetzt.

Das folgende Beispiel zeigt einen Kunden, der die Rack-zu-Rack-Strategie mit dem Schwellenwerttyp CountSuccess mit 10 Knoten pro Rack und einer Pause von 1 Minute verwendet.

az networkcloud cluster update --name "<clusterName>" /
--resource-group "<resourceGroup>" /
--update-strategy strategy-type="Rack" threshold-type="CountSuccess" /
threshold-value=10 wait-time-minutes=1 /
--subscription <subscriptionID>

Überprüfen von Updates:

az networkcloud cluster show --resource-group "<resourceGroup>" /
--name "<clusterName>" /
--subscription <subscriptionID>| grep -a5 updateStrategy

      "strategyType": "Rack",
      "thresholdType": "CountSuccess",
      "thresholdValue": 10,
      "waitTimeMinutes": 1

Wenn in diesem Beispiel weniger als 10 Serverknoten in einem Rack bereitgestellt werden (auf Rack-zu-Rack-Basis), schlägt die Clusterbereitstellung fehl. Wenn mindestens 10 Serverknoten erfolgreich bereitgestellt werden, wird die Clusterbereitstellung mit dem nächsten Rack mit Serverknoten fortgesetzt.

Hinweis

update-strategy kann nicht geändert werden, nachdem das Clusterlaufzeitupgrade gestartet wurde. Wenn ein Schwellenwert unter 100 % festgelegt wird, ist es möglich, dass fehlerhafte Knoten nicht aktualisiert werden, aber der „Clusterstatus” könnte dennoch angeben, dass das Upgrade erfolgreich war. Informationen zur Problembehandlung bei Bare-Metal-Computern finden Sie unter Problembehandlung von Azure Operator Nexus-Serverproblemen.

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>" /
--subscription <subscriptionID>

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, je nachdem, wie viele Racks für den Cluster vorhanden 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>" /
--subscription <subscriptionID>

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 Knoten in jedem Rack überprüft werden. Ein Beispiel für die Überprüfung des Status wird im Referenzabschnitt unter BareMetal Machine-Rollenbereitgestellt.

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.

Eine indefinitely attempting to upgrade-Situation 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 Laufzeitupgrade fehlschlägt, weil die Schwellenwerte für Rechen- und Steuerungsknoten nicht erreicht wurden, kann eine erneute Ausführung des Laufzeitupgrades erforderlich sein. Je nachdem, wann der Fehler aufgetreten ist und der Zustand der einzelnen Server in einem Rack. 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 Laufzeitversion durchzuführen, übermitteln Sie eine neue Clusterupgradeanforderung. Nur die Knoten mit der vorherigen Laufzeitversion 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 Laufzeitupgrades wechselt der Cluster in den Status 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 Fehler verursachen. In einigen Szenarien kann es erforderlich sein, den Fehler mit dem Microsoft-Support zu diagnostizieren.

Freigeben über