Delen via

Clusterruntime upgraden vanuit Azure CLI

  • Artikel

In deze handleiding worden de stappen uitgelegd voor het installeren van de vereiste Azure CLI en extensies die nodig zijn om te communiceren met Operator Nexus.

Vereisten

  • De Azure CLI installeren moet zijn geïnstalleerd.
  • De networkcloud CLI-extensie is vereist. Als de extensie niet is geïnstalleerd, kan deze networkcloud worden geïnstalleerd volgens de stappen die hier worden vermeld.
  • Toegang tot Azure Portal om het doelcluster te upgraden.
  • U moet zijn aangemeld bij hetzelfde abonnement als uw doelcluster via az login
  • Het doelcluster moet een actieve status hebben, waarbij alle besturingsvlakknooppunten in orde zijn en 80+% van de rekenknooppunten in een actieve en gezonde status.

Huidige runtimeversie controleren

Controleer de huidige versie van de clusterruntime voordat u een upgrade uitvoert: de huidige versie van de clusterruntime controleren.

Beschikbare runtimeversies zoeken

Via Azure Portal

Als u beschikbare upgradebare runtimeversies wilt vinden, gaat u naar het doelcluster in Azure Portal. Navigeer in het overzichtsvenster van het cluster naar het tabblad Beschikbare upgradeversies.

Schermopname van Azure Portal met het juiste tabblad om beschikbare clusterupgrades te identificeren.

Op het tabblad Beschikbare upgradeversies kunnen we de verschillende clusterversies zien die momenteel beschikbaar zijn om te upgraden. De operator kan kiezen uit de vermelde doelruntimeversies. Zodra dit is geselecteerd, gaat u verder met het upgraden van het cluster.

Schermopname van Azure Portal met beschikbare clusterupgrades.

Via Azure CLI

Beschikbare upgrades kunnen worden opgehaald via de Azure CLI:

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

In de uitvoer vindt u de availableUpgradeVersions eigenschap en kijkt u naar het targetClusterVersion veld:

  "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"
    }
  ],

Als er geen clusterupgrades beschikbaar zijn, is de lijst leeg.

Parameters voor de berekeningsdrempel configureren voor runtime-upgrade met behulp van clusterupdateStrategy

De volgende Azure CLI-opdracht wordt gebruikt voor het configureren van de parameters voor de berekeningsdrempel voor een runtime-upgrade:

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>

Vereiste parameters:

  • strategietype: Definieert de updatestrategie. Dit kan "Rack" (Rack by Rack) OF "PauseAfterRack" (Een rack tegelijk upgraden en vervolgens wachten op bevestiging voordat u verdergaat met het volgende rek. De standaardwaarde is Rack. Als u een clusterruntime-upgrade wilt uitvoeren met behulp van de strategie 'PauseRack', volgt u de stappen die worden beschreven in De upgrade van clusterruntime met een pauzerekstrategie
  • drempeltype: bepaalt hoe de drempelwaarde moet worden geëvalueerd, toegepast in de eenheden die door de strategie zijn gedefinieerd. Dit kan OF "CountSuccess"zijn"PercentSuccess". De standaardwaarde is PercentSuccess.
  • drempelwaarde: de numerieke drempelwaarde die wordt gebruikt om een update te evalueren. De standaardwaarde is 80.

Optionele parameters:

  • maximaal niet beschikbaar: het maximum aantal werkknooppunten dat offline kan zijn, dat wil gezegd, een upgrade van het rek tegelijk. De standaardwaarde is 32767.
  • wachttijd-minuten: de vertraging of wachttijd voordat een rek wordt bijgewerkt. De standaardwaarde is 15.

Het volgende voorbeeld is voor een klant die Rack by Rack-strategie gebruikt met een percentage succes van 60% en een pauze van 1 minuut.

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>

Update controleren:

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

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

In dit voorbeeld mislukt de clusterimplementatie als minder dan 60% van de rekenknooppunten die worden ingericht in een rack, niet kan worden ingericht (op rackbasis). Als 60% of meer van de rekenknooppunten zijn ingericht, wordt de clusterimplementatie verplaatst naar het volgende rek met rekenknooppunten.

Het volgende voorbeeld is voor een klant die Rack by Rack-strategie gebruikt met een drempelwaardetype CountSuccess van 10 knooppunten per rek en een pauze van 1 minuut.

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>

Update controleren:

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

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

In dit voorbeeld mislukt de clusterimplementatie als minder dan 10 rekenknooppunten die in een rack worden ingericht in een rek, mislukt de clusterimplementatie. Als 10 of meer rekenknooppunten zijn ingericht, wordt de clusterimplementatie verplaatst naar het volgende rek met rekenknooppunten.

Notitie

update-strategy kan niet worden gewijzigd nadat de upgrade van de clusterruntime is gestart. Wanneer een drempelwaarde lager dan 100% is ingesteld, is het mogelijk dat beschadigde knooppunten mogelijk niet worden bijgewerkt, maar dat de status Cluster nog steeds kan aangeven dat de upgrade is geslaagd. Voor het oplossen van problemen met bare-metalcomputers raadpleegt u Problemen met de Azure Operator Nexus-server oplossen

Clusterruntime upgraden met CLI

Gebruik de volgende Azure CLI-opdracht om een upgrade van de runtime uit te voeren:

az networkcloud cluster update-version --cluster-name "<clusterName>" /
--target-cluster-version "<versionNumber>" /
--resource-group "<resourceGroupName>" /
--subscription <subscriptionID>

De runtime-upgrade is een lang proces. Met de upgrade worden eerst de beheerknooppunten bijgewerkt en vervolgens sequentieel Rack by Rack voor de werkknooppunten. De upgrade wordt beschouwd als voltooid wanneer 80% van de werkknooppunten per rek en 100% van de beheerknooppunten zijn bijgewerkt. Werkbelastingen kunnen worden beïnvloed terwijl de werkknooppunten in een rek bezig zijn met het upgraden, maar werkbelastingen in alle andere racks worden niet beïnvloed. Overweging van de plaatsing van workloads in het licht van dit implementatieontwerp wordt aangemoedigd.

Het upgraden van alle knooppunten duurt meerdere uren, afhankelijk van het aantal racks voor het cluster. Vanwege de lengte van het upgradeproces moet de detailstatus van het cluster periodiek worden gecontroleerd op de huidige status van de upgrade. Als u de status van de upgrade wilt controleren, bekijkt u de gedetailleerde status van het cluster. Deze controle kan worden uitgevoerd via de portal of az CLI.

Als u de upgradestatus wilt weergeven via Azure Portal, gaat u naar de doelclusterresource. In het scherm Overzicht van het cluster wordt de gedetailleerde status weergegeven, samen met een gedetailleerd statusbericht.

De clusterupgrade wordt uitgevoerd wanneer detailedStatus is ingesteld op Updating en detailedStatusMessage geeft de voortgang van de upgrade weer. Enkele voorbeelden van de voortgang van de upgrade die wordt weergegeven in detailedStatusMessage zijn Waiting for control plane upgrade to complete..., Waiting for nodepool "<rack-id>" to finish upgrading...enzovoort.

De clusterupgrade is voltooid wanneer detailedStatus is ingesteld op Running en detailedStatusMessage bericht weergeeft Cluster is up and running

Schermopname van Azure Portal waarin de upgrade van het cluster wordt uitgevoerd.

Als u de upgradestatus wilt weergeven via de Azure CLI, gebruikt u az networkcloud cluster show.

az networkcloud cluster show --cluster-name "<clusterName>" /
--resource-group "<resourceGroupName>" /
--subscription <subscriptionID>

De uitvoer moet de informatie van het doelcluster zijn en de gedetailleerde status van het cluster en het detailstatusbericht moeten aanwezig zijn. Voor gedetailleerdere inzichten over de voortgang van de upgrade kan het afzonderlijke knooppunt in elk rek worden gecontroleerd op status. Een voorbeeld van het controleren van de status vindt u in de naslagsectie onder BareMetal Machine-rollen.

Veelgestelde vragen

Clusterupgrade is vastgelopen/vastgelopen

Tijdens een runtime-upgrade is het mogelijk dat de upgrade niet verder kan, maar de detailstatus weerspiegelt dat de upgrade nog steeds actief is. Omdat het lang kan duren voordat de runtime-upgrade is voltooid, is er momenteel geen time-outlengte ingesteld. Daarom is het raadzaam om regelmatig te controleren op de detailstatus en logboeken van uw cluster om te bepalen of uw upgrade voor onbepaalde tijd een upgrade probeert uit te voeren.

We kunnen een indefinitely attempting to upgrade situatie identificeren door de logboeken, gedetailleerde berichten en gedetailleerde statusberichten van het cluster te bekijken. Als er een time-out optreedt, zien we dat het cluster continu voor onbepaalde tijd op dezelfde manier wordt afgestemd en niet verder gaat. Vanaf hier raden we u aan clusterlogboeken of geconfigureerde LAW te controleren, om te zien of er een fout is, of een specifieke upgrade die het gebrek aan voortgang veroorzaakt.

Voor hardwarefouten is geen heruitvoering van de upgrade vereist

Als er een hardwarefout optreedt tijdens een upgrade, wordt de runtime-upgrade voortgezet zolang aan de ingestelde drempelwaarden wordt voldaan voor de reken- en beheer-/beheerknooppunten. Zodra de machine is hersteld of vervangen, wordt deze ingericht met het besturingssysteem van de huidige platformruntime, dat de doelversie van de runtime bevat.

Als er een hardwarefout optreedt en de runtime-upgrade mislukt omdat er niet is voldaan aan drempelwaarden voor reken- en beheerknooppunten, is het mogelijk dat de runtime-upgrade opnieuw wordt uitgevoerd. Afhankelijk van wanneer de fout is opgetreden en de status van de afzonderlijke servers in een rek. Als een rek vóór een fout is bijgewerkt, wordt de bijgewerkte runtime-versie gebruikt wanneer de knooppunten opnieuw worden geprovisioneerd. Als de specificatie van het rek vóór de hardwarefout niet is bijgewerkt naar de bijgewerkte runtimeversie, wordt de machine ingericht met de vorige runtimeversie. Als u een upgrade wilt uitvoeren naar de nieuwe runtimeversie, dient u een nieuwe upgradeaanvraag voor het cluster in. Alleen de knooppunten met de vorige runtimeversie worden bijgewerkt. Hosts die in de vorige upgradeactie zijn geslaagd, zullen dit niet doen.

Na een runtime-upgrade toont het cluster de inrichtingsstatus Mislukt

Tijdens een runtime-upgrade voert het cluster de status in.Upgrading Als de runtime-upgrade mislukt, treedt het cluster in een Failed inrichtingsstatus. Infrastructuuronderdelen (bijvoorbeeld het opslagapparaat) kunnen fouten veroorzaken tijdens de upgrade. In sommige scenario's kan het nodig zijn om de fout met Microsoft-ondersteuning vast te stellen.