Aggiornamento del runtime del cluster dall'interfaccia della riga di comando di Azure

Articolo
10/26/2023

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 networkcloud riga di comando. 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 l'80+% dei nodi di calcolo in uno stato in esecuzione e integro.

Ricerca delle versioni di runtime disponibili

Tramite il portale

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 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 aver selezionato, procedere con l'aggiornamento del cluster.

Tramite l'interfaccia della riga di comando di Azure

Gli aggiornamenti disponibili sono recuperabili tramite l'interfaccia della riga di comando di Azure:

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

Nell'output è possibile trovare la availableUpgradeVersions proprietà e osservare il targetClusterVersion campo:

  "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 sarà vuoto.

Aggiornamento del runtime del cluster tramite l'interfaccia della riga di comando

Per eseguire un aggiornamento del 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"

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 è stato 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 saranno 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, ma può richiedere più tempo se altri processi, come gli aggiornamenti del firmware, fanno anche parte dell'aggiornamento. A causa della lunghezza del processo di aggiornamento, è consigliabile controllare periodicamente lo stato dei dettagli del cluster 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 dell'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.

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"

L'output deve essere rappresentato dalle informazioni del cluster di destinazione e deve essere presente lo stato dettagliato del cluster e il messaggio di stato dettagliato del cluster. Per informazioni più dettagliate sullo stato dell'aggiornamento, è possibile verificare lo stato del singolo BMM in ogni rack. Questo esempio viene fornito nella sezione di riferimento in Ruoli computer BareMetal.

Configurare i parametri della soglia di calcolo per l'aggiornamento in fase di esecuzione usando l'aggiornamento del clusterStrategy

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>

Argomenti obbligatori:

strategy-type: definisce la strategia di aggiornamento. In questo caso, "Rack" indica che gli aggiornamenti si verificano rack per rack. Il valore predefinito è "Rack"
threshold-type: determina la modalità di valutazione della soglia, applicata nelle unità definite dalla strategia. Il valore predefinito è "PercentSuccess".
threshold-value: valore soglia numerico usato per valutare un aggiornamento. Il valore predefinito è 80.

Argomenti facoltativi:

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

Di seguito è riportato un esempio di utilizzo del comando:

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

Al termine dell'esecuzione del comando, i valori updateStrategy specificati verranno applicati al cluster:

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

Domande frequenti

Identificazione dell'aggiornamento del cluster bloccato/bloccato

Durante un aggiornamento di runtime, è possibile che l'aggiornamento non venga spostato in avanti, ma lo stato dei dettagli riflette che l'aggiornamento è ancora in corso. Poiché l'aggiornamento del runtime può richiedere molto tempo per completare correttamente, non è attualmente specificata alcuna lunghezza di timeout impostata. È quindi consigliabile controllare periodicamente lo stato dei dettagli e i log del cluster per determinare se l'aggiornamento tenta di eseguire l'aggiornamento a tempo indefinito.

È possibile identificare quando si tratta di questo caso esaminando i log del cluster, il messaggio dettagliato e il messaggio di stato dettagliato. Se si è verificato un timeout, si noterà che il cluster si sta riconciliando continuamente con lo stesso tempo illimitato e non procedendo. Il messaggio di stato dettagliato del cluster riflette "Cluster is in the process of being updated.", . Da qui è consigliabile controllare i log del cluster o la legge configurata per verificare se si è verificato un errore o un aggiornamento specifico che causa la mancanza di avanzamento.

L'errore hardware non richiede la ripetizione dell'aggiornamento

Se si è verificato un errore hardware durante un aggiornamento, l'aggiornamento del runtime continua fino a quando le soglie impostate vengono soddisfatte 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 è riuscito perché le soglie non sono state soddisfatte per i nodi di calcolo e di controllo, potrebbe essere necessario eseguire di nuovo l'aggiornamento di 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 di runtime aggiornata verrà usata quando i nodi vengono riprovisionati. Se la specifica del rack non è stata aggiornata 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 e solo i nodi con la versione di runtime precedente verranno aggiornati. Gli host che hanno avuto esito positivo nell'azione di aggiornamento precedente non verranno visualizzati.

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

Durante un aggiornamento di runtime, il cluster passerà allo stato Upgrading In caso di errore dell'aggiornamento di runtime, per motivi correlati alle risorse, il cluster passerà a uno Failed stato di provisioning. Questo stato può essere collegato al ciclo di vita dei componenti correlati al cluster (ad esempio Archiviazione Appliance) e potrebbe essere necessario per diagnosticare l'errore con il supporto Microsoft.

Share via