Aggiornamento del software controller su Private Cloud Appliance

Durante le fasi di preparazione dell'ambiente di aggiornamento, il file di metadati con le versioni dei componenti di destinazione viene confrontato con l'installazione corrente e il risultato di questo confronto dei metadati viene registrato in un piano di aggiornamento dettagliato. Per ogni elemento, il piano contiene le versioni e le build correnti e target e se l'aggiornamento è necessario o meno. Se un elemento deve essere aggiornato, il piano indica quali componenti dell'infrastruttura sono interessati, se è necessario un riavvio e quanto tempo richiede l'aggiornamento.

Ogni riavvio può influire sulle prestazioni e sulla disponibilità dell'appliance. Per il rischio minimo e l'uso ottimale del tempo, la logica per popolare il piano di aggiornamento include una valutazione dettagliata dei nuovi pacchetti. Molti pacchetti possono essere aggiornati senza un reboot o richiedono solo un riavvio del servizio. Il flag di reboot nel piano di aggiornamento viene impostato solo se è assolutamente necessario riavviare un componente.

Il piano di aggiornamento funge da lista di controllo che guida tutte le procedure di aggiornamento in un ordine prescritto. Viene avviato un job di upgrade per ogni comando di upgrade, ma se il piano indica che un componente è già nella versione richiesta, non vengono intraprese ulteriori azioni e l'upgrade viene saltato. Tuttavia, se necessario, è possibile forzare un aggiornamento con la stessa versione.

Con l'avanzamento delle operazioni di aggiornamento, il piano viene aggiornato in modo da riflettere lo stato corrente, in modo che un amministratore possa controllare in qualsiasi momento quali componenti sono stati già aggiornati o devono ancora essere aggiornati. Quando le versioni correnti e target sono identiche per ogni elemento del piano di aggiornamento, l'intero sistema è aggiornato.

In qualsiasi momento durante o dopo un aggiornamento, l'amministratore può utilizzare il framework dei job per verificare lo stato delle richieste e dei job. Un comando di aggiornamento corrisponde a una richiesta di aggiornamento, che attiva un workflow che potrebbe contenere diversi job di aggiornamento. I lavori, a loro volta, consistono in una serie di compiti. I dettagli su tutti questi elementi possono essere recuperati utilizzando l'interfaccia utente Web del servizio o l'interfaccia CLI del servizio. Mentre il piano di aggiornamento mostra lo stato in un momento specifico, il framework di job consente a un amministratore di visualizzare lo stato e la cronologia eseguendo il drill-down dei dettagli dell'attività Upgrade, semplificando anche la risoluzione dei problemi.

Ai fini del monitoraggio a lungo termine, i file di metadati e i piani di aggiornamento vengono salvati, mentre le informazioni dettagliate su tutti gli aggiornamenti dei componenti e le patch vengono acquisite nei processi di aggiornamento. La funzione Cronologia aggiornamenti consente a un amministratore di eseguire il drill-down dell'attività di upgrade e applicazione delle patch nell'appliance. La cronologia degli aggiornamenti presenta tutte le informazioni sugli aggiornamenti e sulle patch in modo categorizzato in modo da poter vedere quali aggiornamenti della versione sono stati eseguiti, quali job sono stati eseguiti per ciascuno di tali aggiornamenti e da quale origine (aggiornamento ISO o patch ULN). I dettagli includono le versioni di build, le versioni dei componenti prima e dopo, il completamento del job, l'esito positivo o negativo, gli indicatori orari e la durata.

Tutte le operazioni di aggiornamento sono precedute da un processo di verifica per garantire che i componenti del sistema siano nello stato corretto da aggiornare. Per questi controlli preliminari, il meccanismo di aggiornamento si basa sui controlli dello stato a livello di piattaforma. Anche se i controlli dello stato vengono eseguiti continuamente a scopo di monitoraggio, devono essere eseguiti in modo specifico prima di un'operazione di aggiornamento. L'amministratore non è tenuto a eseguire i controlli preliminari manualmente; vengono eseguiti dal codice di aggiornamento quando viene immesso un comando di aggiornamento. È necessario passare tutti i controlli per consentire l'avvio di un aggiornamento, anche se è selezionato un aggiornamento a componente singolo.

Le versioni software dei prerequisiti vengono applicate nelle release a partire da gennaio 2024. Durante l'upgrade o la preparazione delle patch, il servizio Upgrader convalida la versione del software dell'appliance attualmente installata rispetto alla nuova versione di destinazione. Se l'appliance non esegue almeno la versione minima richiesta, viene eseguito il rollback dell'ambiente allo stato precedente. Prima di procedere con la versione di destinazione desiderata, è necessario installare la versione minima richiesta.

Alcune procedure di aggiornamento richiedono che l'amministratore imposti prima un blocco di provisioning e di manutenzione. Sebbene i lock siano attivi, non possono verificarsi operazioni di provisioning o altre attività in conflitto, il che significa che il processo di upgrade è protetto da potenziali interruzioni. Al termine dell'aggiornamento, è necessario rilasciare i blocchi di manutenzione e provisioning in modo che il sistema torni alla modalità operativa completa.

Nei flussi di lavoro compositi di grandi dimensioni, come l'aggiornamento dell'intero rack e l'aggiornamento di tutti i nodi di calcolo, i blocchi vengono applicati e rilasciati a livello di programmazione. Gli amministratori non devono bloccare e sbloccare i componenti manualmente, ma devono monitorare il flusso di lavoro di upgrade alla ricerca di potenziali interruzioni ed intraprendere azioni correttive in caso di problemi con il blocco dei nodi, le migrazioni delle istanze di computazione e così via.

Il servizio Workflow dell'upgrade (UWS) aggiunge un livello di orchestrazione al processo di upgrade. Riunisce gli aggiornamenti del componente modulare in un flusso di lavoro integrato, consentendo all'amministratore di avviare un aggiornamento dell'intera appliance con un unico comando. La logica di aggiornamento della selezione dei componenti, dell'ordine e della tempistica è determinata dal piano di aggiornamento. Il flusso di lavoro gestisce le operazioni necessarie per completare il piano di aggiornamento generando richieste e monitorando i risultati dei job associati.

L'approccio basato sul flusso di lavoro viene introdotto nella versione software del controller che migra il cluster di gestione completo su Oracle Linux 8. L'upgrade rack completo è il modo preferito per aggiornare Private Cloud Appliance con tutte le release da aprile 2025 in poi. In caso di problemi imprevisti di orchestrazione o requisiti specifici dei componenti, Oracle fornirà indicazioni su come aggiornare i componenti in gruppi o singolarmente.

L'ordine dei componenti è determinato dal piano di aggiornamento per la release specifica. Il flusso di lavoro per l'aggiornamento del rack include i seguenti componenti:

1. Firmware ZFS Storage Appliance (inclusi gli ILOM dei controller di storage)

2. Nodi di calcolo

3. Nodi di gestione

   • Sistema operativo host dei 3 nodi

   • Database cluster MySQL

   • Servizio segreto (inclusi Etcd e Vault)

   • Pacchetti di orchestrazione container Kubernetes (livello piattaforma)

   • Microservizi containerizzati

4. Immagini di Oracle Cloud Infrastructure

5. Firmware ILOM (tutti i nodi)

6. Firmware dello switch (tutti gli switch)

Gli aggiornamenti di Private Cloud Appliance sono progettati per essere modulari, consentendo l'upgrade dei singoli componenti senza interruzioni del servizio nell'ambiente operativo. Oracle consiglia di utilizzare il workflow di aggiornamento rack completo, ma le procedure per i sottoinsiemi e i singoli componenti sono disponibili per scenari specifici.

• Firmware di ZFS Storage Appliance

  Utilizzare questa opzione per aggiornare il software operativo su ZFS Storage Appliance. Entrambi i controller, che operano in una configurazione di cluster attivo-attivo, vengono aggiornati come parte dello stesso processo. Se è disponibile un nuovo firmware dell'ILOM, viene aggiornato anche su entrambi i controller del processo.

• Nodo di calcolo

  Utilizzare questa opzione per installare gli ultimi pacchetti kernel e spazio utente Oracle Linux, nonché strumenti e ottimizzazioni specifici dell'appliance. Puoi eseguire l'upgrade di un singolo nodo fornendo il relativo indirizzo IP host oppure eseguire un workflow che esegue l'upgrade di tutti i nodi di calcolo installati nell'appliance. Non è possibile eseguire upgrade simultanei; i nodi vengono bloccati e aggiornati uno alla volta.

• Cluster di gestione

  Utilizzare questa opzione per eseguire l'upgrade del sistema operativo host e dei servizi in esecuzione su tutti e tre i nodi di gestione, inclusi il database MySQL in cluster e il servizio segreto (etcd/Vault). L'aggiornamento completo del cluster del nodo di gestione integra più aggiornamenti dei componenti in un workflow globale, in modo che tutti i job vengano eseguiti in un ordine predefinito. Con un singolo comando, tutti e tre i nodi di gestione nel cluster vengono aggiornati in sequenza e componenti per componente. Ciò significa che un aggiornamento di un determinato componente viene eseguito su ciascuno dei tre nodi di gestione prima che il workflow globale passi all'aggiornamento successivo del componente.

• Sistema Operativo Host

  Utilizzare questa opzione per aggiornare il sistema operativo Oracle Linux su un nodo di gestione. È possibile aggiornare il sistema operativo host di un singolo nodo fornendo il relativo indirizzo IP host oppure eseguire un workflow che esegue l'aggiornamento sequenziale del sistema operativo host su tutti e tre i nodi di gestione.

• Cluster Kubernetes

  Utilizzare questa opzione per eseguire l'upgrade del cluster Kubernetes, ovvero l'ambiente di orchestrazione dei container in cui vengono distribuiti i servizi. Il cluster Kubernetes viene eseguito su tutti i nodi di gestione e di calcolo; l'upgrade prevede tre operazioni principali:

  • Aggiornamento dei pacchetti Kubernetes e di tutte le dipendenze: kubeadm, kubelet, kubectl e così via.

  • Aggiornamento delle immagini dei container Kubernetes: kube-apiserver, kube-controller-manager, kube-proxy e così via.

  • Aggiornamento di qualsiasi file manifest YAML delle API e dei servizi Kubernetes non più valido.

• Servizi di piattaforma

  Utilizzare questa opzione per eseguire l'upgrade dei servizi containerizzati in esecuzione nel cluster Kubernetes sui nodi di gestione. Il meccanismo di upgrade del servizio si basa su Helm, l'equivalente di Kubernetes di un package manager. Per i servizi che devono essere aggiornati, le nuove immagini dei container e i grafici di distribuzione Helm vengono forniti tramite un'immagine ISO e caricati nel registro interno. Nessuna delle operazioni effettuate fino a questo momento ha effetto sull'ambiente operativo.

  A livello di piattaforma, viene attivato un aggiornamento riavviando i pod che eseguono i servizi. I nuovi grafici di distribuzione vengono rilevati e i pod recuperano la nuova immagine del contenitore al riavvio. Se viene rilevato un problema, è possibile eseguire il rollback di un servizio alla versione di lavoro precedente dell'immagine.

  Nota
  
  

  In circostanze specifiche è possibile eseguire l'upgrade di determinati servizi di piattaforma singolarmente, aggiungendo una stringa JSON facoltativa al comando. Questa opzione non deve essere utilizzata a meno che Oracle non fornisca istruzioni esplicite.

• Firmware dell'ILOM

  Utilizzare questa opzione per aggiornare il firmware Oracle Integrated Lights Out Manager (ILOM) di un componente installato nell'appliance. È possibile aggiornare un singolo ILOM fornendo il relativo indirizzo IP o eseguendo un workflow che aggiorna tutti gli ILOM di tutti i componenti dell'appliance. Una volta eseguito l'aggiornamento del firmware, viene eseguito automaticamente il reboot dell'ILOM. Tuttavia, l'amministratore deve riavviare manualmente il server affinché tutte le modifiche diventino effettive.

• Cambia firmware

  Utilizzare questa opzione per aggiornare il software operativo degli switch. È possibile specificare una categoria di switch da aggiornare: gli switch foglia, gli spine switch o lo switch di gestione. È inoltre possibile eseguire un workflow che aggiorna tutti gli switch installati nell'appliance.

• Immagini offerte da Oracle

  Utilizzare questa opzione per aggiungere le immagini Oracle Cloud Infrastructure disponibili più recenti per Private Cloud Appliance. Le immagini esistenti che non sono più necessarie devono essere rimosse manualmente.