VCF Automation è il piano di consumo di VMware Cloud Foundation 9.0: il pezzo che trasforma un’infrastruttura già costruita — vSphere, vSAN, NSX, sorvegliata da VCF Operations — in un cloud privato self-service e multi-tenant. La documentazione la presenta come la soluzione che permette a team IT e cloud service provider di erogare un private cloud self-service per applicazioni AI, Kubernetes e basate su VM, con offerte IaaS preconfezionate e controllo tramite governance a policy. Chi arriva da vRealize o Aria Automation ritrova concetti familiari, ma nome, collocazione e modo di installarla sono cambiati: è questo il terreno su cui l’esame gioca.

I quattro componenti

La doc scompone il prodotto in quattro parti. Cloud Services espone i servizi cloud attraverso più interfacce: UI, CLI e API. Provider Management è ciò che usano IT o service provider per gestire e scalare i servizi su più istanze vCenter e più istanze VCF, modellando la multi-tenancy con il concetto di Organization. Organization Management è il livello dove l’amministratore dell’organizzazione crea e assegna progetti e vSphere Namespaces ai team applicativi. Infine il vSphere Supervisor, che la doc chiama la fondazione del consumo di VCF perché è ciò che esegue i workload Kubernetes direttamente sugli host ESX. Quest’ultimo punto è il più sottovalutato: senza un Supervisor abilitato non c’è niente da consumare.

Modelli di deploy: la taglia decide i nodi

VCF Automation gira su container dentro un cluster Kubernetes ospitato su appliance virtuali dedicate, che compaiono come singoli nodi nell’inventario vCenter. I modelli sono due. Il Simple VCF Automation Model è a nodo singolo e si applica alla taglia Small: la doc lo indirizza a proof of concept e valutazioni, workload piccoli e non critici, ambienti di sviluppo e test, e avverte che non offre alta disponibilità a livello applicativo. Lo High Availability VCF Automation Model è un cluster a tre nodi nelle taglie Medium o Large, supporta un load balancer esterno ed è il modello per produzione, applicazioni mission-critical e deployment enterprise. Il passaggio fra i due non è una spunta indipendente: ridimensionare il nodo a Medium o Large forza lo scale out a tre nodi.

Installazione come operazione day-N

Se VCF Automation non è stata distribuita durante l’implementazione iniziale, si aggiunge da VCF Operations fleet management: scheda Overview > Fleet Management Lifecycle, riquadro VCF Automation, poi Add. Prima servono i binari, scaricati con Binary Management. Il wizard chiede tipo di installazione (New Install), versione, deployment type Small/Medium/Large — il dimensionamento sta nel Planning and Preparation Workbook — e l’FQDN, con il vincolo che Common Name e Subject Alternative Name del certificato lo includano. Poi il vCenter del management domain con cluster, cartella, resource pool, rete e datastore; domain name e search path, DNS, NTP, gateway e netmask IPv4; e per i componenti FQDN, password di almeno 15 caratteri, un VM node prefix univoco, il primary VIP, un IP pool di almeno quattro indirizzi e l’internal cluster CIDR. Si chiude con Run Precheck e Submit. Dettaglio che l’esame può sfruttare: è supportata una sola istanza di VCF Automation.

Dal Provider Management Portal al namespace

Il giro operativo parte dal VCF Automation Provider Management Portal, sotto Infrastructure > Organizations > Create Organization. I tipi sono tre: Organization for All Apps (VM, Kubernetes, data service), Organization for VM Applications — se ne può creare una sola — e la Provider Consumption Organization, che il provider abilita da Administration > Feature Flags e usa per consumare risorse proprie e pubblicare blueprint e cataloghi verso le altre organizzazioni, pur senza accesso al Provider Management Portal. La creazione chiede nome, region e Supervisor, limiti e reservation di CPU e memoria per zona, VM class e storage class, e un primo utente.

Una region non è un luogo geografico: raggruppa uno o più Supervisor, anche da vCenter diversi, purché configurati con la stessa istanza NSX, e i Supervisor devono essere omogenei (stessi nomi e configurazioni di storage class, versioni Kubernetes corrispondenti, insieme coerente di servizi IaaS). La region quota definisce quanta capacità l’organizzazione ottiene su quella region: compute e vGPU reserved VM class capacity per zona, storage class e VM class a livello di region. Non può essere illimitata, non se ne può dare più di una dalla stessa region alla stessa organizzazione, e non si applica alle organizzazioni VM Apps.

Dentro l’organizzazione i progetti rappresentano i team reali e contengono uno o più namespace, che la doc descrive come buste di risorse dove si distribuiscono le applicazioni; la Namespace Class è il template riutilizzabile che ne fissa limiti di CPU, memoria e storage, VM class e storage class. Si creano da Manage & Govern > Projects > progetto > Namespaces > New Namespace, scegliendo classe, region, VPC e fino a tre zone. La VPC (Manage & Govern > Networking > Virtual Private Clouds) dà l’isolamento di rete: CIDR privati che escono in NAT, blocchi IP del transit gateway raggiungibili dentro l’organizzazione, blocchi esterni assegnati dal provider.

Le superfici di consumo

Il consumo passa dal catalogo self-service, dalla IaaS Services Console e dalla VCF CLI v9.0, oltre che dalle API. Nelle organizzazioni All Apps il catalogo vive nella scheda Build & Deploy, nelle VM Apps nella scheda Consume. I blueprint si disegnano in Build & Deploy > Content Hub > Blueprint Design, con canvas grafico ed editor YAML, si versionano e si pubblicano a catalogo; i workflow di VCF Operations Orchestrator si pubblicano da Content Hub > Workflows. La IaaS Services Console, aperta a Project Administrator e Project Advanced User, provisiona VM, cluster Kubernetes, volumi, load balancer, oggetti di rete e storage, sempre nell’ambito di un namespace. I guardrail sono le policy, da Manage & Govern > Policies > New Policy: IaaS resource policy, lease, approval e day-2 action.

Trappole tipiche d’esame

  • VCF non è VMware vSphere Foundation. La doc dichiara che vSphere Foundation non include le capacità di cloud management e automazione integrata disponibili in VCF: uno scenario che chiede catalogo self-service, blueprint o multi-tenancy non si risolve su VVF.
  • Il modello di deploy segue la taglia, non è una scelta a parte. Small significa nodo singolo e nessuna HA applicativa; Medium o Large impongono il cluster a tre nodi. Chi risponde «tre nodi Small» sbaglia.
  • L’installazione day-N non parte da SDDC Manager. Il percorso è VCF Operations fleet management, riquadro VCF Automation. E l’orchestratore non si chiama più vRealize Orchestrator: è VCF Operations Orchestrator.
  • I tre tipi di organizzazione non sono intercambiabili. Blueprint e IaaS Services Console vivono nelle All Apps; le VM Apps hanno il solo catalogo self-service ed esistono in un unico esemplare; la Provider Consumption Organization serve al provider per consumare e pubblicare, non per amministrare region e ruoli globali.
  • Region, progetto e namespace stanno su tre livelli diversi. La region aggrega Supervisor sotto la stessa istanza NSX, la quota si assegna all’organizzazione sulla region, il progetto raccoglie utenti e namespace, e la capacità si consuma nel namespace. Le domande scambiano volentieri questi livelli fra loro.