L’obiettivo 4.2 chiede una cosa sola, ma chiede quella bene: davanti a uno scenario, saper dire quale capacità di fleet management in VCF Operations lo risolve e da dove si esegue. Non basta ricordare l’elenco: le sette capacità che la documentazione riconosce — gestione licenze, lifecycle, identità e accessi, certificati, password, configurazione, tag — hanno console, prerequisiti e ordini di esecuzione diversi, e l’esame lavora esattamente su quelle differenze.

Flotta, istanza, dominio: chi governa che cosa

Il fleet management non è un prodotto separato: è una sezione della console di VCF Operations, servita dalla VCF Operations fleet management appliance, che la documentazione descrive come parte di VCF Operations e responsabile di deployment, lifecycle e configurazione dei componenti di gestione: VCF Operations, VCF Automation, VCF Identity Broker. Sotto, una VCF fleet raccoglie più VCF instance; dentro ogni istanza SDDC Manager — anch’esso descritto come parte di VCF Operations — resta il motore del lifecycle di ESX, vCenter e NSX e del deploy dei workload domain. Questa doppia titolarità è la chiave di lettura dell’intero obiettivo: le operazioni “di flotta” e quelle “di istanza” non vivono nello stesso posto.

Estendere la flotta a un’istanza già esistente (5.x o successiva) è una sequenza di tre passi in VCF Operations: creare un’integration per la nuova istanza e portarla su un service account gestito dal sistema; aggiungere il vCenter del management domain come deployment target; deployare un VCF Operations collector (cloud proxy) sull’istanza e ripuntare l’integration su quel collector. Il collector non è un dettaglio decorativo: senza registrazione sul cloud proxy diversi oggetti restano fuori dalla raccolta dati, e in più di una schermata compaiono con stato Unavailable.

Lifecycle: due tier, un ordine obbligato

La documentazione separa nettamente VCF management components (VCF Operations, VCF Automation, fleet management, VCF Operations for Logs, VCF Operations for Networks, VCF Identity Broker) dai VCF core components (SDDC Manager, vCenter, NSX Manager, ESX): i primi operano sull’intera flotta e possono coprire più istanze, i secondi vivono dentro la singola istanza. Prima di qualunque cosa servono un download token, un depot online o offline configurato e i binari scaricati.

L’ordine è la parte che l’esame ama: si aggiorna prima la fleet management appliance alla versione target, e solo dopo si possono pianificare upgrade o patch degli altri componenti di gestione. Per i core, la sequenza documentata per le maintenance release è SDDC Manager → NSX → vCenter → host ESX → vSAN, prima nel management domain e poi nei workload domain. Su un dominio, il percorso è Fleet Management → Lifecycle → VCF Instances → dominio → Updates → Plan Upgrade; da lì Customize Upgrade apre il flexible BOM, che consente di scegliere versioni target diverse per singolo core component invece di muovere tutto come un blocco unico, sempre previa precheck e validazione. VCF applica comunque una validazione stretta dei percorsi di aggiornamento.

Certificati, password, licenze, identità

I certificati stanno in Fleet Management → Certificates, con viste distinte per VCF Management, VCF Instances e VCF Domains (queste ultime due con un toggle per mostrare o nascondere gli host ESX) più una scheda di alert dedicata. L’auto-rinnovo si attiva con Activate Auto-renewal sulla vista scelta e, secondo la pagina, scatta 60 giorni prima della scadenza; con Microsoft CA o OpenSSL va prima configurata la Certificate Authority, mentre self-signed e VMCA non lo richiedono.

Le password hanno due indirizzi. Per i componenti core la rotazione si fa da SDDC Manager → Security → Password management: si seleziona l’account, Rotate password, e il sistema genera una password casuale conforme alla policy del componente e ricostruisce le integrazioni; l’interfaccia offre intervalli predefiniti per la rotazione pianificata, mentre intervalli personalizzati passano dall’API e gli account ESX non ammettono rotazione schedulata. Per VCF Operations e il suo cluster, invece, la console espone reset, generazione di passphrase temporanee per l’aggiunta di nodi e operazioni di update/remediate.

Le licenze in 9.0 non sono più chiavi da 25 caratteri ma file di sottoscrizione. VCF Operations si registra alla VCF Business Services console in connected mode (i dati salgono da soli, le licenze si aggiornano con un clic) o disconnected mode (usage file generato e caricato a mano); in entrambi i casi l’uso va riportato almeno ogni 180 giorni. Nella console di Business Services si dividono, uniscono, ridimensionano e assegnano le licenze — e l’assegnazione avviene alle istanze vCenter, da cui gli altri componenti risultano licenziati automaticamente.

Sull’identità, il VCF Identity Broker ha due modelli: embedded nel vCenter del management domain, semplice ma con un singolo punto di rottura, consigliato uno per istanza; oppure appliance, cluster a tre nodi deployato dal fleet management, che regge la perdita di un nodo e serve fino a cinque istanze.

Configurazione e tag: rilevare la deriva, propagare i metadati

Configuration Drifts confronta la configurazione reale di istanze vCenter e cluster vSphere con lo stato desiderato definito in un configuration template, con quattro stati: Not Drifted, Drift Detected, Drift Check Failed, Unavailable (sotto la 9.0 o non registrato sul cloud proxy). Le verifiche si pianificano da Schedule Drift Detection — solo su oggetti di tipo vCenter — e generano un job in automation central. I template si versionano su Git: Administration Control Panel → Source Control, con GitLab o GitHub, code review attiva per default e tre file JSON per template (desiredState, metaData, manifest).

Fleet Management → Tags and Categories centralizza invece categorie e tag: si creano indicando tipi di oggetto e cardinalità, si importano dai vCenter di management o workload domain, si spingono verso vCenter selezionati o gruppi custom. Il nome non è modificabile, solo la descrizione, e la gestione centralizzata serve proprio a non perdere tag e associazioni durante il vMotion.

Trappole tipiche d’esame

  • VCF contro VMware vSphere Foundation. In VVF la console di VCF Operations gestisce i certificati del solo componente VCF Operations, non dell’intero stack: uno scenario VVF che chiede il rinnovo centralizzato dei certificati di vCenter e NSX è una domanda a trabocchetto.
  • Fleet management appliance contro SDDC Manager. Lifecycle di VCF Operations, VCF Automation e Identity Broker: fleet management. Lifecycle di ESX, vCenter, NSX e deploy dei workload domain: SDDC Manager. E la fleet management appliance si aggiorna per prima, altrimenti gli altri componenti di gestione non arrivano alla versione target.
  • vCenter Linking non è Enhanced Linked Mode. Dà una vista unica dal vSphere Client su vCenter 9.0 o successivi (minimo due, massimo quindici, IdP comune, niente vCenter già in ELM) ma non sincronizza ruoli, tag e permessi globali. La propagazione dei tag è compito del tag management, non del linking.
  • Licenze: assegnazione e modalità. Nessuna chiave a 25 caratteri, assegnazione ai vCenter con gli altri componenti licenziati a cascata, e distinzione fra connected e disconnected mode. NSX, HCX e VCF Automation non si licenziano più separatamente.
  • Il drift si rileva, non si rimedia da solo. La pagina della dashboard documenta confronto, dettaglio e download del report, non una remediation automatica; e la schedulazione copre gli oggetti vCenter, non i cluster.