[VMware] Come aggiornare VMware Cloud Foundation dalla 9.0 alla 9.1: guida completa
L’aggiornamento a VMware Cloud Foundation 9.1 non è il classico minor update che si liquida con un paio di bundle e una finestra di manutenzione notturna. Broadcom ha cambiato pezzi importanti dell’architettura di gestione: l’appliance di Fleet Management introdotta con la 9.0 sparisce, arriva un nuovo layer chiamato VCF Management Services, e il licensing passa attraverso un License Server dedicato che diventa componente obbligatorio.
Tradotto: l’ordine dei fattori qui cambia il prodotto. Saltare un passaggio o invertire due componenti significa quasi certamente trovarsi con vCenter che non riesce a licenziarsi o con i binari 9.1 che non compaiono nel depot.
In questa guida vediamo l’intera sequenza di upgrade da VCF 9.0.x a 9.1, i prerequisiti da sistemare prima di partire, le differenze rispetto al percorso vSphere Foundation (VVF) e i problemi noti già catalogati da Broadcom.
Prima di tutto: questa guida copre il percorso 9.0.x → 9.1. Se parti da VCF 5.2.x la sequenza è diversa (più lunga) e se sei sotto la 5.2 devi prima portare management domain e workload domain alla 5.2.x.
In breve
- Verifica prerequisiti: DNS tutto minuscolo (forward e reverse), IP statici pre-allocati, backup validi, HCL e Interop Matrix.
- Aggiorna VCF Operations e il Cloud Proxy alla 9.1 (qui avviene la migrazione del fleet management).
- Aggiorna SDDC Manager alla 9.1.
- Distribuisci VCF Management Services e il License Server, poi trasferisci le licenze.
- Aggiorna VCF Identity Broker, VCF Automation, Operations for Networks, Log Management.
- Aggiorna NSX Manager, poi vCenter, poi ESX.
- Aggiorna l’NSX Edge Cluster e finalizza NSX.
- Attività di chiusura: VMware Tools 13.1, compatibilità VM, vDS, vSAN on-disk format, vSAN File Service.
I workload domain non sono obbligatori in questa finestra: puoi aggiornarli come attività Day-N successiva.
Cosa cambia davvero nella 9.1
Prima di mettere mano al depot vale la pena capire cosa stai per fare all’ambiente, perché tre di questi punti sono trasformazioni architetturali, non semplici bump di versione.
VCF Management Services. È il nuovo runtime comune che ospita in modo nativo i componenti di lifecycle e operations: Fleet Lifecycle e SDDC Lifecycle girano dentro questo layer, che è un componente obbligatorio per VCF (opzionale per vSphere Foundation). In pratica smetti di gestire appliance separate per il lifecycle e ti ritrovi con un cluster di servizi centralizzato.
L’appliance di Fleet Management viene dismessa. La 9.1 sostituisce completamente la Fleet Management Appliance della 9.0: la VM viene spenta e resta pronta per essere decommissionata. La transizione avviene durante l’upgrade di VCF Operations, che valida le credenziali e migra inventory dei componenti, certificati e service account.
Arriva il License Server centralizzato. È una nuova appliance che centralizza la gestione delle licenze ed è richiesta sia per VCF sia per vSphere Foundation.
L’Identity Broker viene consolidato. Il cluster multi-nodo esterno usato per il vIDB in 9.0 viene migrato dentro VCF Management Services e le VM standalone vengono spente.
La UI di SDDC Manager è in deprecazione. Dopo l’upgrade a 9.1 le attività di lifecycle management vanno eseguite da VCF Operations; la UI di SDDC Manager sarà rimossa in una release futura.
Prerequisiti
Questa è la fase che decide se l’upgrade dura una giornata o una settimana. La 9.1 ha alzato parecchio l’asticella sui controlli di validazione.
DNS rigorosamente minuscolo
Tutti i record DNS forward e reverse, esistenti e nuovi, devono usare esclusivamente caratteri minuscoli, altrimenti si incappa in errori di validazione durante lo switchover. È il tipo di dettaglio che in un ambiente cresciuto negli anni ti costa mezza giornata di pulizia: controlla tutta la zona, non solo i nuovi record.
# Verifica rapida forward + reverse di un host
nslookup vcenter01.dominio.local
nslookup 10.0.0.10Indirizzamento IP pre-allocato
Servono IP statici dedicati e record DNS forward/reverse mappati per VCF Management Services (configurati come IP Pool in notazione CIDR nella UI) e per il License Server headless.
Sul dimensionamento, la documentazione Broadcom è esplicita: servono minimo 12 indirizzi IP per il deployment, con la possibilità di aggiungerne altri 18 in seguito per l’aggiunta di nuovi VCF Management Services o per lo scale-out dei nodi nei futuri upgrade.
Se lavori con subnet di management strette, questo è il punto in cui scoprire di non avere spazio. Verificalo prima di scaricare i bundle.
Backup, sempre
Il backup di un ambiente VCF richiede sia i backup file-based nativi per vCenter, sia target SFTP per SDDC Manager e VCF Operations (backup image-based).
Aggiungici, per buon senso operativo:
- snapshot delle appliance di management prima di ogni singola fase (e rimozione immediata a fase conclusa);
- export della configurazione NSX;
- verifica che l’ultimo backup schedulato sia effettivamente riuscito, non solo pianificato.
Compatibilità e prerequisiti software
- Puoi aggiornare l’ambiente VCF solo verso una versione rilasciata dopo la data di rilascio della versione corrente: la Interoperability Matrix è il riferimento.
- Hardware da validare contro la Compatibility Guide aggiornata.
- Va scaricato e revisionato il Planning and Preparation Workbook, che riporta i requisiti di hardware, rete, software e servizi esterni.
- Tra i prerequisiti dei componenti core rientrano la disponibilità di un indirizzo IP temporaneo per ogni vCenter, il download dei bundle, la verifica di validità di certificati e password e l’aggiornamento del database di compatibilità hardware vSAN.
- vSphere Lifecycle Manager: da VCF 9.0 in poi sono supportati solo i cluster gestiti tramite vLCM Images; i baseline non sono più supportati. Se hai ancora cluster a baseline, la conversione a immagini va fatta come parte dell’upgrade.
- Verifica che l’ambiente di backup in uso sia compatibile con la versione 9.1 . Ad esempio Veeam lo sarà dalla 13.1.
Precheck
Esegui il precheck di upgrade prima di iniziare: se emergono errori, l’interfaccia fornisce le istruzioni dettagliate per risolverli prima di avviare l’aggiornamento. Non trattarlo come una formalità — è il punto in cui l’ambiente ti dice cosa non va, gratis.
C’è anche un VCF Upgrade Planning Tool che guida nella scelta del percorso corretto in base alla versione di partenza.
La sequenza ufficiale 9.0.x → 9.1
Questa tabella è la traduzione operativa dell’ordine imposto da Broadcom. L’ordine è vincolante.
| # | Componente 9.0 | Azione |
|---|---|---|
| 0 | VCF Identity Broker (appliance mode su segmento NSX overlay) | Transizione sulla VCF Management Network |
| 1 | VCF Operations + Cloud Proxy | Upgrade a 9.1 |
| 2 | vSphere Replication | Converge/upgrade a Protection and Recovery 9.1 |
| 3-5 | Live Site Recovery, vSAN Data Protection, Avi Load Balancer | Upgrade (non inclusi nella SKU VCF) |
| 6 | SDDC Manager | Upgrade a 9.1 + deploy Management Services e License Server + trasferimento licenze |
| 7 | VCF Identity Broker | Upgrade a 9.1 |
| 8 | VCF Automation | Upgrade a 9.1 |
| 9 | VCF Operations Orchestrator | Upgrade a 9.1 |
| 10 | VCF Operations for Networks | Upgrade a 9.1 |
| 11 | VCF Operations for Logs | Deploy Log Management 9.1 |
| 12 | VCF Operations HCX | Upgrade a 9.1 |
| 13 | NSX Global Manager | Upgrade (solo ambienti federati) |
| 14 | NSX Manager | Upgrade a 9.1 |
| 15 | vCenter | Upgrade a 9.1 |
| 16 | Supervisor | Upgrade a 9.1 |
| 17 | vSAN Witness Host | Upgrade ESX a 9.1 |
| 18 | ESX | Upgrade a 9.1 |
| 19 | NSX Edge + finalize | Upgrade e finalizzazione |
| 20-23 | VMware Tools 13.1, compatibilità VM, vSAN on-disk format, vSAN File Service | Attività di chiusura |
Si parte sempre dal VCF Instance che ospita l’istanza di VCF Operations dedicata alla gestione del fleet. Gli altri instance del fleet si aggiornano dopo.
Fase 1 — VCF Operations e Cloud Proxy
È il primo componente e anche il più delicato, perché è qui che avviene la migrazione del fleet management.
Durante l’upgrade il sistema valida credenziali, migra inventory, certificati e service account, e alla fine spegne l’appliance di Fleet Management. Serve inoltre un Cloud Proxy nel VCF Instance per l’integrazione tra VCF Operations, SDDC Manager e i Management Services: se non è presente nel primo instance del fleet dove è ospitato VCF Operations, va distribuito per completare l’upgrade.
Prima di lanciare: crea gli snapshot dei nodi VCF Operations ed esegui il backup dei contenuti personalizzati.
Effetto collaterale da tenere a mente: dopo l’upgrade di VCF Operations a 9.1 non puoi più gestire certificati e password di VCF Automation, Identity Broker, Operations for Logs e Operations for Networks finché non aggiorni anche quei componenti alla 9.1. Non lasciare la finestra aperta per settimane.
Fase 2 — SDDC Manager
L’upgrade di SDDC Manager non è cambiato in modo significativo rispetto alle versioni precedenti. Si avvia da Lifecycle Management > SDDC Manager, dove vengono presentate le versioni disponibili; si seleziona la 9.1.0.0, si scarica il bundle e si esegue il precheck. Superato il precheck, l’update può partire.
Fase 3 — VCF Management Services e License Server
Questo passaggio non esiste nelle versioni precedenti ed è il cuore della 9.1.
Prima di poter aggiornare gli altri componenti core devi distribuire i VCF Management Services: è il cluster a container che ospita fleet lifecycle, SDDC lifecycle, il software depot e il license server. È un componente obbligatorio con un workflow di installazione dedicato nell’interfaccia.
Il deployment si avvia dalla tab Build > Lifecycle e prosegue con un wizard che completa anche la migrazione del fleet management dentro il nuovo cluster.
Subito dopo va eseguito il trasferimento delle licenze: dalla 9.1 il license server è obbligatorio, e le licenze migrano dall’istanza VCF Operations al nuovo componente.
Il licensing è la principale fonte di grattacapi post-upgrade in questa release. Vedi la sezione sui problemi noti più avanti.
Fase 4 — Identity Broker e componenti di management
L’Identity Broker 9.0.x in appliance mode ha un percorso di upgrade dedicato alla versione 9.1. Se è distribuito su un segmento NSX overlay e non sulla VCF management network, devi distribuire una nuova istanza prima dell’upgrade. In embedded mode viene invece aggiornato automaticamente insieme a vCenter.
Per gli altri componenti:
- VCF Automation: upgrade diretto 9.0.x → 9.1 gestito da VCF Operations. Data la complessità e le integrazioni personalizzate, spesso conviene trattarlo come workstream indipendente rispetto al percorso core.
- Operations for Logs: non esiste upgrade diretto — il log management è diventato parte del cluster Management Services. Si distribuisce il componente Log Management da Build > Lifecycle > VCF Management, e nella 9.1 è possibile trasferire i dati di log alla nuova istanza.
- Operations for Networks: upgrade diretto se già in 9.0.x.
Fase 5 — NSX Manager
In VCF 9.x l’upgrade di NSX è un processo in due tempi, perché i VIB NSX sono inclusi in ESX per impostazione predefinita. Il primo step aggiorna lo stack di management: si va su Build > Lifecycle > [workload domain] > Upgrades, si esegue Run Prechecks e poi Upgrade Now, che lancia un ulteriore precheck prima di avviare l’aggiornamento a NSX 9.1.
Il secondo tempo (Edge + finalize) arriva dopo ESX.
Con NSX Federation configurata, i Global Manager vanno aggiornati prima dei Local Manager e non sono gestiti da SDDC Manager: l’operazione è manuale per ogni instance.
Fase 6 — vCenter
Qui c’è la scelta operativa più interessante della guida.
Per un upgrade da 9.0.x a 9.1 puoi scegliere tra in-place upgrade e Reduced Downtime Upgrade (RDU); la RDU è invece obbligatoria se arrivi da VCF 5.2, trattandosi di un salto tra versioni major di vCenter. Nel workflow si configurano i parametri di update — tra cui la rete temporanea e l’orario di avvio — poi viene eseguito il prerequisite check e l’upgrade può partire.
C’è però un dettaglio che vale la pena conoscere in anticipo, perché determina se ti serve una seconda finestra:
Con il metodo reduced downtime la virtual hardware version della VM vCenter viene aggiornata automaticamente dalla 10 alla 17, perché viene creata una nuova VM. Dopo un in-place update da 9.0.x a 9.1.0, invece, la hardware version della VM vCenter deve essere aggiornata manualmente, e l’operazione richiede lo spegnimento della VM.
Detto in termini pratici: l’in-place sembra più semplice ma ti lascia un’attività di spegnimento in coda. Se hai la possibilità di allocare la rete temporanea, la RDU chiude la partita in un colpo solo.
Nota a margine utile: la 9.1 introduce una API che permette di ridimensionare vCenter con una singola chiamata più un reboot, per scalare CPU e dimensioni disco.
Fase 7 — Host ESX
Il processo è simile alle versioni precedenti, con l’eccezione già citata dei baseline vLCM non più supportati: i cluster devono essere convertiti a vLCM Images come parte dell’upgrade. Una volta create e assegnate le immagini, l’aggiornamento ESX può essere completato.
L’avanzamento si segue dal vSphere Client durante la remediation; nella maggior parte dei casi è previsto il riavvio dell’host.
Nella schermata di upgrade, per default tutti gli host standalone risultano selezionati: con Custom Selection puoi scegliere un sottoinsieme di host. Utile per fare un primo host pilota prima di lanciare l’intero cluster.
Ricordati del vSAN Witness Host: nella sequenza ufficiale viene prima degli host ESX veri e propri.
Fase 8 — NSX Edge e finalizzazione
Ultimo step della parte core: l’upgrade dell’edge cluster alla 9.1 e la finalizzazione dell’aggiornamento del workload domain. Dopo qualche minuto il management domain risulta completamente aggiornato a VCF 9.1 in SDDC Manager.
Fase 9 — Attività di chiusura
Da non rimandare sine die, perché sono ciò che ti permette di sfruttare davvero la nuova baseline:
- Upgrade del vSphere Distributed Switch
- VMware Tools alla 13.1 su tutte le VM
- Virtual hardware / compatibilità VM
- Upgrade della versione del file system vSAN (on-disk format) e vSAN File Service
- Configurazione del licensing
- Workload domain: opzionali, eseguibili in qualsiasi momento dopo l’aggiornamento del management domain del rispettivo instance
Se il tuo ambiente è vSphere Foundation (VVF)
Se non hai lo stack VCF completo ma vSphere Foundation, il percorso è decisamente più corto. L’ordine è: VCF Operations e Cloud Proxy, poi vCenter — insieme al deployment dei VCF Management Services e del License Server e al trasferimento delle licenze — poi Log Management, ESX, Supervisor, VMware Tools 13.1, compatibilità VM, vSAN on-disk format e vSAN File Service.
Differenza sostanziale: in vSphere Foundation il layer VCF Management Services è opzionale, mentre in VCF è obbligatorio. Il License Server invece resta necessario in entrambi gli scenari.
Problemi noti da conoscere prima di iniziare
Broadcom ha raccolto in KB gli errori tipici causati da un percorso di upgrade errato. Vale la pena leggerli prima, non a incidente avvenuto:
| Sintomo | KB |
|---|---|
| I binari 9.1 non compaiono in VCF Operations 9.0 | 440282 |
| vCenter non licenziabile dopo l’upgrade: “not connected to a license server” | 440471 |
| Fallimento nell’assegnazione licenze ai vCenter | 424533 |
| Errore di sync durante l’upgrade degli host ESXi da VCF Operations 9.0.2 | 440407 |
Il riferimento generale sulla sequenza è la KB 440630.
Tre errori su quattro riguardano il licensing. Se dopo la Fase 3 le licenze non risultano correttamente trasferite al License Server, fermati lì invece di proseguire con NSX e vCenter.
Consigli operativi finali
Non fare tutto in una notte. La sequenza è lunga e ogni fase ha il suo precheck. Un’ipotesi ragionevole è spalmare l’upgrade su più finestre: management stack (Fasi 1-4) in una, data plane (Fasi 5-8) in un’altra, chiusura (Fase 9) in modalità Day-N.
Snapshot chirurgici. Prima di ogni fase, snapshot delle appliance coinvolte; a fase validata, rimozione immediata. Snapshot dimenticate su appliance di management sono un classico problema di performance e crescita disco a scoppio ritardato.
Documenta le password. La 9.1 ha standard più stringenti sulle password: verifica in anticipo che le credenziali dei componenti siano conformi e non in scadenza durante la finestra.
Fai un host pilota. Sulla Fase 7, usa Custom Selection per un singolo host prima di lanciare tutto il cluster.
Tieni sotto mano i log. Se qualcosa fallisce, l’upgrade history e i file di log dei task sono il primo posto dove guardare — prima di aprire il ticket.
Conclusioni
La 9.1 non è un upgrade cosmetico: consolida in un unico runtime tutto ciò che nella 9.0 era distribuito su appliance separate, dismette la Fleet Management Appliance e introduce un license server obbligatorio. È un lavoro di pianificazione più che di esecuzione — la parte tecnica, se i prerequisiti sono a posto, è largamente orchestrata dalla piattaforma.
Il tempo speso su DNS minuscoli, IP pre-allocati e backup verificati è il tempo che non spenderai a fare rollback.
