Aggiornare il runtime del cluster dall'interfaccia della riga di comando di Azure

Questa guida pratica illustra i passaggi per installare l'interfaccia della riga di comando di Azure e le estensioni necessarie per interagire con Operator Nexus.

Prerequisiti

• È necessario installare l'interfaccia della riga di comando di Azure.
• È necessaria l'estensione dell'interfaccia della riga di comando networkcloud. Se l'estensione networkcloud non è installata, è possibile installarla seguendo i passaggi elencati qui.
• Accesso al portale di Azure per l'aggiornamento del cluster di destinazione.
• È necessario accedere alla stessa sottoscrizione del cluster di destinazione tramite az login
• Il cluster di destinazione deve essere in esecuzione, con tutti i nodi del piano di controllo integri e più dell'80% dei nodi di calcolo in stato in corso di esecuzione e integri.

Verifica della versione di runtime corrente

Verificare la versione corrente del runtime del cluster prima dell'aggiornamento: come controllare la versione corrente del runtime del cluster.

Ricerca delle versioni di runtime disponibili

Tramite il portale di Azure

Per trovare le versioni di runtime aggiornabili disponibili, passare al cluster di destinazione nel portale di Azure. Nel riquadro di panoramica del cluster passare alla scheda Versioni di aggiornamento disponibili.

Dalla scheda delle versioni di aggiornamento disponibili è possibile visualizzare le diverse versioni del cluster attualmente disponibili per l'aggiornamento. L'operatore può selezionare tra le versioni di runtime elencate. Dopo averlo selezionato, procedere all'aggiornamento del cluster.

Tramite l'interfaccia della riga di comando di Azure

Gli aggiornamenti disponibili possono essere recuperati tramite l'interfaccia della riga di comando di Azure:

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

Nell'output è possibile trovare la proprietà availableUpgradeVersions ed esaminare il campo targetClusterVersion:

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

Se non sono presenti aggiornamenti del cluster disponibili, l'elenco è vuoto.

Configurare i parametri della soglia di calcolo per l'aggiornamento di runtime tramite cluster updateStrategy

Il comando dell'interfaccia della riga di comando di Azure seguente viene usato per configurare i parametri della soglia di calcolo per un aggiornamento di runtime:

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>

Parametri obbligatori:

• strategy-type: definisce la strategia di aggiornamento. Può essere "Rack" (rack per rack) OR "PauseAfterRack" (aggiornare un rack alla volta e quindi attendere la conferma prima di procedere al rack successivo. Il valore predefinito è Rack. Per eseguire un aggiornamento del runtime del cluster usando la strategia "PauseRack" seguire i passaggi descritti in Aggiornamento di runtime del cluster con la strategia PauseRack
• threshold-type: determina la modalità di valutazione della soglia, applicata nelle unità definite dalla strategia. Può trattarsi di "PercentSuccess" OR "CountSuccess". Il valore predefinito è PercentSuccess.
• threshold-value: valore soglia numerico usato per valutare un aggiornamento. Il valore predefinito è 80.

Parametri facoltativi:

• max-unavailable: numero massimo di nodi di lavoro che possono essere offline, ovvero un rack aggiornato alla volta. Il valore predefinito è 32767.
• wait-time-minutes: il ritardo o il periodo di attesa prima di aggiornare un rack. Il valore predefinito è 15.

L'esempio seguente è destinato a un cliente che usa la strategia Rack by Rack con percentuale di successo del 60% e una pausa di 1 minuto.

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>

Verificare l'aggiornamento:

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

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

In questo esempio, se meno del 60% dei nodi di calcolo di cui viene effettuato il provisioning in un rack non riescono a eseguire il provisioning (su rack), la distribuzione del cluster non riesce. Se viene eseguito correttamente il provisioning del 60% o più nodi di calcolo, la distribuzione del cluster passa al rack successivo dei nodi di calcolo.

L'esempio seguente è destinato a un cliente che usa la strategia Rack per rack con un tipo di soglia CountSuccess di 10 nodi per rack e una pausa di 1 minuto.

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>

Verificare l'aggiornamento:

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

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

In questo esempio, se il provisioning di meno di 10 nodi di calcolo in un rack non riesce a eseguire il provisioning (su rack), la distribuzione del cluster non riesce. Se viene eseguito correttamente il provisioning di 10 o più nodi di calcolo, la distribuzione del cluster passa al rack successivo dei nodi di calcolo.

Nota

update-strategy non può essere modificato dopo l'avvio dell'aggiornamento del runtime del cluster. Quando viene impostato un valore soglia inferiore al 100%, è possibile che tutti i nodi non integri non vengano aggiornati, ma lo stato "Cluster" potrebbe comunque indicare che l'aggiornamento è riuscito. Per la risoluzione dei problemi relativi ai computer bare metal, vedere Risoluzione dei problemi del server Operatore Nexus di Azure

Aggiornare il runtime del cluster tramite l'interfaccia della riga di comando

Per eseguire un aggiornamento di runtime, usare il comando seguente dell'interfaccia della riga di comando di Azure:

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

L'aggiornamento di runtime è un processo lungo. L'aggiornamento aggiorna prima i nodi di gestione e quindi rack in sequenza per rack per i nodi di lavoro. L'aggiornamento viene considerato completato quando l'80% dei nodi di lavoro per rack e il 100% dei nodi di gestione viene aggiornato correttamente. I carichi di lavoro potrebbero essere interessati mentre i nodi di lavoro in un rack sono in fase di aggiornamento, ma i carichi di lavoro in tutti gli altri rack non sono interessati. È consigliabile considerare il posizionamento del carico di lavoro alla luce di questa progettazione di implementazione.

L'aggiornamento di tutti i nodi richiede più ore, a seconda del numero di rack esistenti per il cluster. A causa della lunghezza del processo di aggiornamento, lo stato dei dettagli del cluster deve essere controllato periodicamente per lo stato corrente dell'aggiornamento. Per verificare lo stato dell'aggiornamento, osservare lo stato dettagliato del cluster. Questo controllo può essere eseguito tramite il portale o az CLI.

Per visualizzare lo stato di aggiornamento tramite il portale di Azure, passare alla risorsa cluster di destinazione. Nella schermata Panoramica del cluster viene fornito lo stato dettagliato insieme a un messaggio di stato dettagliato.

L'aggiornamento del cluster è in corso quando detailedStatus è impostato su Updating e detailedStatusMessage mostra lo stato di avanzamento dell'aggiornamento. Alcuni esempi di avanzamento dell'aggiornamento illustrati in detailedStatusMessage sono Waiting for control plane upgrade to complete..., Waiting for nodepool "<rack-id>" to finish upgrading... e così via.

L'aggiornamento del cluster è completo quando detailedStatus è impostato su Running e detailedStatusMessage mostra il messaggio Cluster is up and running

Per visualizzare lo stato di aggiornamento tramite l'interfaccia della riga di comando di Azure, usare az networkcloud cluster show.

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

L'output dovrebbe contenere le informazioni sul cluster di destinazione e dovrebbero essere presenti lo stato dettagliato del cluster e il messaggio di stato dettagliato. Per informazioni più dettagliate sullo stato di avanzamento dell'aggiornamento, è possibile verificare lo stato del singolo nodo in ogni rack. Un esempio di verifica dello stato viene fornito nella sezione di riferimento in Ruoli computer BareMetal.

Domande frequenti

Identificazione dell'aggiornamento del cluster In stallo/bloccato

Durante un aggiornamento di runtime, è possibile che l'aggiornamento non vada avanti e che lo stato dei dettagli indichi che l'aggiornamento è ancora in corso. Poiché l'aggiornamento di runtime può richiedere molto tempo per essere completato correttamente, non è stata specificata alcuna lunghezza di timeout.. È quindi consigliabile controllare periodicamente lo stato dei dettagli e i log del cluster per determinare se l'aggiornamento sta tentando di aggiornarsi a tempo indefinito.

È possibile identificare una indefinitely attempting to upgrade situazione esaminando i log del cluster, il messaggio dettagliato e il messaggio di stato dettagliato. Se si verifica un timeout, si noterà che il cluster si riconcila continuamente nello stesso tempo illimitato e non si sposta in avanti. Da qui è consigliabile controllare i log del cluster o il LAW configurato per verificare la presenza di un errore o un aggiornamento specifico che causa il mancato avanzamento.

L'errore hardware non richiede la riesecuzione dell'aggiornamento

Se si verifica un errore hardware durante un aggiornamento, l'aggiornamento del runtime continua finché vengono soddisfatte le soglie impostate per i nodi di calcolo e gestione/controllo. Una volta corretto o sostituito il computer, viene eseguito il provisioning con il sistema operativo del runtime della piattaforma corrente, che contiene la versione di destinazione del runtime.

Se si verifica un errore hardware e l'aggiornamento del runtime non riesce perché le soglie non sono state soddisfatte per i nodi di calcolo e di controllo, potrebbe essere necessario eseguire di nuovo l'aggiornamento del runtime. A seconda del momento in cui si è verificato l'errore e lo stato dei singoli server in un rack. Se un rack è stato aggiornato prima di un errore, la versione aggiornata del runtime verrà usata quando i nodi verranno sottoposti a provisioning. Se le specifiche del rack non sono state aggiornate alla versione di runtime aggiornata prima dell'errore hardware, verrà eseguito il provisioning del computer con la versione di runtime precedente. Per eseguire l'aggiornamento alla nuova versione di runtime, inviare una nuova richiesta di aggiornamento del cluster. Vengono aggiornati solo i nodi con la versione di runtime precedente. Gli host che hanno avuto esito positivo nell'azione di aggiornamento precedente non lo avranno.

Dopo un aggiornamento di runtime, il cluster mostra lo stato di provisioning "Non riuscito"

Durante un aggiornamento di runtime, il cluster entra in uno stato di Upgrading. Se l'aggiornamento del runtime non riesce, il cluster passa a uno Failed stato di provisioning. I componenti dell'infrastruttura (ad esempio l'appliance di archiviazione) possono causare errori durante l'aggiornamento. In alcuni casi potrebbe essere necessario diagnosticare l'errore con il supporto Tecnico Microsoft.