Chi arriva a VCF 9.0 dopo anni di vSphere tende a leggere «private cloud» come un sinonimo elegante di «datacenter virtualizzato». La documentazione Broadcom è più precisa: VCF è «a private cloud platform that delivers public cloud scale and agility with on-premises security, resilience and performance, while lowering total cost of ownership». Le tre parti contano tutte, e all’esame contano separatamente: il modello di consumo è quello del cloud pubblico, il perimetro di controllo resta tuo, il costo diventa una voce che si governa invece di subire.

I principi: consumo self-service su infrastruttura che resta tua

Un private cloud non è definito dall’hardware ma da come lo si consuma. In VCF il consumo passa da VCF Automation, che «enables IT teams and cloud service providers (CSPs) to deliver a self-service private cloud for AI, Kubernetes, and VM-based applications»: l’amministratore non consegna macchine virtuali, consegna un catalogo. La gerarchia è multi-tenant per costruzione — Organizations create dal provider, Projects che raggruppano utenti e risorse, vSphere Namespaces assegnati ai team applicativi — e le schede del portale (Home, Consume, Design, Infrastructure, Content and Policies, Extensibility) separano chi progetta i template da chi li richiede.

Lo stesso principio vale in rete. In NSX un VPC è «a logically isolated networking subnet routed together by a VPC Gateway», definito sotto un NSX Project da un Enterprise Admin o da un Project Admin. Il consumatore sceglie fra subnet Private - VPC, Private - Transit Gateway e Public, e ottiene raggiungibilità dall’esterno tramite External IP con traduzione 1:1, senza mai toccare i Tier-0 dell’infrastruttura. È esattamente l’astrazione che rende «cloud» un cloud privato: confini, autonomia e responsabilità delimitate, senza aprire il piano fisico a chi consuma.

Che cosa mette insieme VCF

La pagina di overview elenca cinque componenti: vSphere per virtualizzare il calcolo, vSAN che «aggregates local or direct-attached capacity devices of all ESX hosts in a cluster» in un unico pool condiviso, NSX per la rete software-defined, VCF Operations per gestire e osservare la flotta, VCF Automation per il consumo self-service. Attorno si dispone una serie di appliance i cui nomi vanno conosciuti alla lettera: SDDC Manager (lifecycle di ESX, vCenter e NSX), VCF Operations fleet management, VCF Operations collector, VCF Operations for Logs, VCF Operations for Networks con il proprio collector, VCF Operations HCX per la mobilità dei workload, VCF Identity Broker per collegare l’identity provider alla flotta, e il VCF Installer, che in 9.0 prende il posto del Cloud Builder delle 5.x.

L’unità di aggregazione è il workload domain: «a logical unit of application-ready infrastructure that groups ESX hosts managed by a vCenter instance». Il management domain è il primo e lo crea il VCF Installer durante il deployment o la convergenza; ospita SDDC Manager e l’appliance di fleet management, e nella prima VCF Instance anche VCF Operations e VCF Automation. I workload domain successivi si creano invece da VCF Operations, ciascuno con la propria istanza vCenter distribuita nel management domain; possono condividere un cluster NSX Manager esistente, ma «workload domains cannot use the NSX Manager cluster for the management domain». Sopra i domini stanno la VCF Instance e, al livello superiore, la VCF fleet.

La proposta di valore, dove si tocca davvero

Il valore non sta nel bundle ma nel fatto che le operazioni diventano una sola. Il fleet management centralizza licenze, lifecycle, identità e SSO, certificati TLS, password e tag, e aggiunge la configuration management con drift detection schedulata su vCenter e oggetti cluster: la deriva di configurazione non la scopri più a incidente avvenuto. Su capacità e costo, VCF Operations mette a disposizione la Capacity page e la Capacity tab dentro Inventory, con reclaim delle risorse inutilizzate, rightsizing delle VM e what-if analysis per simulare l’aggiunta di host o macchine, più showback, chargeback e budgeting. Sulla sicurezza, Security Operations dà «a consolidated, high-level, strategic view of the VCF fleet’s security posture» divisa in user security e infrastructure security, mentre la compliance si misura sugli oggetti (Host System, Virtual Machine, vSAN, SDDC Manager, cluster) con benchmark come VCF Security Baseline e CIS Compliance Pack for VCF.

Anche l’ingresso è argomento di valore: la convergenza. Con il VCF Installer si dichiara l’infrastruttura vSphere esistente, ciò che manca «is automatically deployed and configured», e «existing vSphere infrastructure is used to create the management domain of the VCF Instance». Gli scenari supportati vanno dal solo vCenter con host ESX fino allo stack completo con VMware Aria Suite Lifecycle, Aria Operations e Aria Automation preesistenti. Per le sedi periferiche c’è VCF Edge, «earlier called Remote Clusters», dove VCF Operations è requisito obbligatorio ai fini del licensing.

E le licenze sono cambiate davvero: «subscription-based license files replace the use of the 25-character license keys». Si gestiscono nella VCF Business Services console (vcf.broadcom.com), in modalità connected o disconnected; le licenze primarie sono VMware Cloud Foundation e vSphere Foundation, gli add-on sono vSAN (a TiB) e VMware Private AI Foundation with NVIDIA (a core); e «you assign licenses only to the vCenter instances», con gli altri componenti licenziati di conseguenza.

Trappole tipiche d’esame

  • VCF non è vSphere Foundation. VVF è «the core foundation for VCF» e il suo percorso parte dal deploy di VCF Operations con un vCenter nuovo o esistente, poi aggiunta delle istanze vCenter e configurazione di vSphere Supervisor. Ma la doc è esplicita: «vSphere Foundation does not include the cloud management and integrated automation capabilities that are available in VMware Cloud Foundation». Avere VCF Operations non significa avere VCF Automation.
  • ESA non è OSA ribattezzata. La doc 9.0 descrive vSAN ESA come architettura a tier singolo su dispositivi NVMe TLC che «eliminates the need for a cache tier». Ogni opzione che parla di cache tier, disk group o rapporti cache/capacità sta descrivendo l’altra architettura, non ESA.
  • I nomi del 9.0 sono la domanda. VCF Operations (non vRealize/Aria Operations), VCF Operations for Logs e for Networks, VCF Edge (non Remote Clusters), VCF Installer (non Cloud Builder), e la doc scrive ESX, non «ESXi». I nomi Aria compaiono legittimamente solo dove si descrive l’ambiente di partenza da convergere.
  • Chi crea che cosa. Il management domain lo crea il VCF Installer in fase di deployment o convergenza; i workload domain si creano in VCF Operations. E un workload domain può riusare un cluster NSX Manager esistente, mai quello del management domain.
  • Le licenze non si assegnano dove ci si aspetta. Niente chiavi a 25 caratteri: file di subscription gestiti nella VCF Business Services console e assegnati alle istanze vCenter, non ai singoli host o alle singole appliance, con vSAN come add-on misurato a TiB.