L’obiettivo 2.1 chiede di «identificare i casi d’uso del private cloud», e la domanda d’esame non è mai filosofica: ti descrive una situazione — un cliente, un vincolo, un requisito operativo — e ti chiede quale forma della piattaforma la soddisfa. La documentazione definisce VMware Cloud Foundation come una private cloud platform che porta scala e agilità del cloud pubblico con sicurezza, resilienza e prestazioni on-premises, cioè una piattaforma IaaS full-stack fatta di compute, storage, networking, sicurezza e management software-defined: vSphere, vSAN, NSX, VCF Operations e VCF Automation. Tutti i casi d’uso che seguono sono modi diversi di consumare lo stesso stack, e riconoscerli significa saper leggere quale pezzo dello stack la domanda sta invocando.

Modernizzare l’esistente invece di ripartire da zero

Il primo caso d’uso reale non è il green field, è la convergenza. Con la VCF Installer appliance si può partire da un’infrastruttura vSphere già in produzione e farla diventare il management domain di una nuova VCF instance: la doc elenca gli scenari supportati (vCenter più host ESX; con VMware Aria Operations; con Aria Suite Lifecycle e Aria Operations; con Aria Lifecycle e Aria Automation; con tutti e tre), e i componenti VCF mancanti vengono deployati durante il processo. È il percorso da citare quando lo scenario dice «abbiamo già vCenter, non vogliamo rifare il data center».

Qui cade anche la scelta fra le due piattaforme. VMware vSphere Foundation (VVF) è definita come piattaforma di workload enterprise e «core foundation for VCF»: unifica VM e container con runtime Kubernetes nativo, aggiunge operations intelligenti e iperconvergenza, ma non include le capacità di cloud management e automazione integrata che stanno in VCF. Il getting started di VVF lo mostra nella pratica: si deploya VCF Operations su un vCenter nuovo o esistente, si aggiungono vCenter instance, si completa la configurazione. Niente workload domain, niente VCF Automation. Se il requisito parla di tenant, cataloghi self-service o rete overlay, la risposta è VCF.

Segmentare la piattaforma: fleet, instance, workload domain

Il management domain è il primo workload domain creato da VCF Installer: contiene vCenter, NSX Manager e SDDC Manager, e sulla prima VCF instance ospita anche VCF Operations e VCF Automation. I workload domain si creano da VCF Operations (o dalla SDDC Manager UI) per far girare i workload dei consumatori: ognuno ha il proprio vCenter e il proprio dominio SSO, può avere identity provider dedicati e ha un lifecycle indipendente. Un dettaglio che l’esame ama: un workload domain può condividere un cluster NSX Manager esistente o riceverne uno nuovo, ma non può usare quello del management domain.

Sopra le instance c’è la VCF fleet: un ambiente gestito da un unico set di componenti fleet-level (VCF Operations e VCF Automation) che contiene una o più VCF instance ed eventualmente vCenter standalone. È il costrutto da invocare quando lo scenario chiede inventario, certificati, password, tag e configurazione governati centralmente su più siti.

Consumo self-service e multi-tenancy

VCF Automation è il pezzo che trasforma l’infrastruttura in servizio. L’organization è l’entità di primo livello che rappresenta una linea di business o un tenant, con il proprio portale; la region aggrega compute, storage, memoria e networking da uno o più Supervisor su uno o più vCenter gestiti dallo stesso NSX Manager; la region quota fissa quanto di quella region spetta all’organizzazione, incluse classi di VM e di storage. Sopra ci stanno progetti, blueprint, catalogo e policy di lease e approvazione.

Sul lato rete lo stesso modello si chiama VPC: subnet logicamente isolate raccordate da un VPC Gateway, definite sotto un NSX Project da un Enterprise Admin o da un Project Admin, con subnet private (scope VPC o scope Transit Gateway) e pubbliche, più NAT, firewall nord-sud stateless e load balancer secondo il connectivity profile. Le VPC si aggiungono anche da vCenter, non solo da NSX. Sul lato applicativo, vSphere Supervisor è il control plane integrato nell’hypervisor che espone un’API dichiarativa e usa i vSphere Namespaces come confine di risorse per cluster Kubernetes, VM dichiarative e vSphere Pod accanto ai workload tradizionali.

Continuità, mobilità e servizi avanzati

Per la resilienza di sito, un cluster vSAN di un workload domain si può stretchare su due availability zone dentro una region, con lo stesso numero di host per zona e — per vSAN HCI e vSAN storage — un witness host in una vSAN witness zone diversa da entrambe (i cluster vSAN compute non lo richiedono). Vincoli da ricordare: il cluster vSphere del management domain va stretchato per primo, e non si stretchano cluster che condividono storage policy vSAN, che hanno host DPU-backed o host su subnet diverse. Il caso d’uso dichiarato è la manutenzione pianificata di una zona senza downtime.

La mobilità è coperta da VCF Operations HCX, per migrazioni intra-VCF e inter-VCF, site-to-site e region-to-region, a ondate o in bulk. E quando il requisito esce dal core, si passa ai VCF Advanced Services: VMware Live Recovery per resilienza cyber e dati, vDefend per microsegmentazione e lateral security, Avi Load Balancer, Data Services Manager, VMware Private AI Foundation with NVIDIA per i microservizi NIM.

Portare la piattaforma all’edge

VCF Edge, che la doc dichiara esplicitamente «earlier called Remote Clusters», è la configurazione ottimizzata di VCF per le sedi dove il dato viene prodotto e consumato: retail, banking, energy, healthcare, utilities. La pagina pubblica criteri di ammissibilità precisi — un minimo di 10 siti, minimo 8 core CPU per host e un massimo di 256 core per sito — e chiarisce due cose spesso confuse: gli host o cluster VCF Edge devono stare in una posizione fisicamente distinta dai workload di data center, e il vCenter dell’edge può risiedere in data center o in colocation, dedicato al workload edge. VCF Operations è requisito di licenza; se si deploya un compute cluster VCF Edge senza stack completo, VCF Operations e vCenter vanno installati manualmente.

Trappole tipiche d’esame

  • VCF contro vSphere Foundation. VVF è la fondazione, non una VCF ridotta a piacere: se lo scenario nomina workload domain, NSX overlay, organizzazioni multi-tenant o cataloghi self-service, VVF è una risposta sbagliata anche quando sembra «più economica».
  • ESA contro OSA. vSAN ESA è single-tier e solo NVMe; vSAN OSA è two-tier e accetta SATA, SAS e NVMe; il vSAN storage cluster (disaggregato) è solo NVMe. Entrambi ESA e OSA supportano lo stretch e i data services: la trappola è la distrattrice che presenta ESA come condizione per stretchare.
  • Edge non è una availability zone. Due availability zone stanno dentro una region e servono la continuità di un cluster; VCF Edge serve molti siti distinti con vincoli di dimensione. Uno scenario con «manutenzione senza downtime» chiede lo stretched cluster, uno con «centinaia di negozi» chiede VCF Edge.
  • I nomi del 9.0. VCF Operations e VCF Automation, non vRealize né Aria; la doc di prodotto scrive VCF Operations for Networks anche dove il blueprint dice «VCF Network Operations»; la doc scrive ESX, non «ESXi». Le risposte con la vecchia nomenclatura sono spesso i distrattori.
  • Le licenze non sono più chiavi. In 9.0 i file di licenza a sottoscrizione sostituiscono le chiavi a 25 caratteri, si gestiscono nella VCF Business Services console e si assegnano solo alle vCenter instance: gli altri componenti sono licenziati automaticamente. Serve una VCF Operations registrata, in connected o disconnected mode.