In VCF 9.0 il deployment non è più una sequenza di installazioni manuali da concatenare: è un flusso guidato che parte da una sola appliance e produce, in un colpo solo, il management domain con tutti i suoi componenti. Capire dove il flusso si interrompe — cioè cosa il wizard non fa e va aggiunto dopo — è esattamente ciò che l’obiettivo 4.1 chiede di saper riconoscere davanti a uno scenario.
Prima del wizard: appliance, binari, host
Il punto di partenza è il VCF Installer, una VM dedicata che si distribuisce dall’OVA VCF-SDDC-Manager-Appliance-9.x.x.<build>.ova — sì, lo stesso file di SDDC Manager. Si può deployare su un host ESX o anche su Workstation/Fusion, purché abbia IP statico, FQDN risolvibile e visibilità sulla VLAN di management, DNS e NTP. Ci si collega a https://<FQDN_installer> come admin@local (l’utente SSH è vcf), con password di almeno 15 caratteri. Dettaglio che vale una domanda: se lo si distribuisce dentro l’infrastruttura di management, cioè su uno degli host che formeranno il management domain, a fine configurazione l’appliance viene spostata in Storage vMotion sullo storage del dominio e commuta in modalità SDDC Manager, perdendo la modalità installer. Per usare la stessa appliance su più piattaforme VCF va tenuta fuori.
Poi servono i binari. In modalità online l’appliance si aggancia a un depot con un download token generato dal Broadcom Support Portal; in ambienti isolati si usa un depot offline oppure il VCF Download Tool su una macchina connessa, caricando poi i pacchetti sull’appliance. Sul fronte host: ESX installato da ISO, rete configurata dal DCUI, port group per le VM di management, NTP configurato e certificato autofirmato rigenerato sull’FQDN. Gli host stateless non sono supportati; il numero di host dipende da storage e deployment model, e la doc rimanda al Planning and Preparation Workbook.
Il Deployment Wizard e le scelte che non si rifanno
Dalla UI si sceglie il VMware Cloud Foundation Deployment Wizard e subito il tipo: New VCF fleet oppure VCF Instance in an existing VCF fleet. Nel primo caso si può far deployare un VCF Operations nuovo o agganciarne uno esistente; nel secondo la connessione a un VCF Operations già presente è obbligatoria, e si configura comunque un nuovo collector locale. Si danno VCF Instance Name e management domain name, si sceglie fra modello Single-node e High Availability a tre nodi (raccomandato in produzione), si decide se generare le password automaticamente e se aderire al CEIP.
Due scelte pesano più delle altre. Lo storage del management domain — vSAN (ESA o OSA), VMFS on FC o NFS v3 — non è modificabile dopo. E il profilo del vSphere Distributed Switch: Default (fabric unico), Storage Traffic Separation, NSX Traffic Separation, Storage and NSX Separation (tre vDS) o Custom Switch Configuration; configurazioni come i Link Aggregation Group richiedono la JSON specification, non la UI. Il wizard valida prima di partire: gli errori bloccano, i warning vanno esplicitamente accettati con Acknowledge. A fine corsa si scarica la JSON spec (senza password) e si consultano le credenziali generate da Review Passwords.
Cosa nasce dal wizard e cosa resta da installare
Per VCF il wizard distribuisce vCenter, VCF Operations (nodo primario, con eventuali replica e data node), l’appliance operations-collector, il fleet management, NSX in tre nodi, VCF Automation in tre nodi e SDDC Manager. Per vSphere Foundation la lista si accorcia: niente replica/data node, niente nodi NSX aggiuntivi, niente VCF Automation, niente SDDC Manager.
Il resto è day-N e si fa da VCF Operations → Fleet Management → Lifecycle, cliccando Add sulla tile del componente, dopo averne scaricato il binario sull’appliance di fleet management: VCF Automation (se non l’hai preso al wizard: New Install, sizing Small/Medium/Large, node prefix, un Node IP Pool di almeno quattro indirizzi, Cluster CIDR e Primary VIP, una sola istanza per deployment), operations-logs cioè VCF Operations for Logs (Standard o Cluster), operations-networks cioè VCF Operations for Networks (una Platform VM più una Collector VM) e VCF Identity Broker per il single sign-on dei componenti della fleet. Ognuno vuole un certificato con l’FQDN in Common Name e SAN, e chiude con un precheck prima del Submit.
Completare la piattaforma: workload domain, host, network pool
Il management domain è uno solo per istanza VCF. I carichi dei consumatori vivono nei VI workload domain, creati da Inventory → Detailed View → VCF Instances → Add Workload Domain → Create New: nome, toggle Enable vSphere Supervisor, SSO domain, FQDN e password root del nuovo vCenter, cluster, NSX (istanza nuova Standard o High-Availability, oppure una condivisa con altri workload domain — mai quella del management domain), connettività Centralized o Distributed, storage fra vSAN, NFS, VMFS on FC e vVol, host e profilo vDS.
Gli host però devono già essere nell’inventario: si commissionano da vSphere Client → Global Inventory Lists → Hosts → Unassigned Hosts → Commission Hosts, indicando FQDN, storage type, network pool e credenziali root. Prerequisiti: hardware certificato, NIC da almeno 10 Gbps, IP di management sul VMkernel, DNS forward e reverse coerenti, certificato rigenerato sull’FQDN e un network pool disponibile. I network pool sono raccolte di subnet in un dominio layer-2 che automatizzano l’assegnazione statica degli IP ai VMkernel per vMotion (sempre), vSAN e vSAN storage client, NFS e iSCSI; uno di default nasce col deployment per il management domain.
Licenze: la registrazione che non si salta
In 9.0 non esistono più chiavi da 25 caratteri: si usano file di licenza a subscription gestiti dalla VCF Business Services console (vcf.broadcom.com), a cui VCF Operations va registrato in modalità connected o disconnected. Le licenze si assegnano solo alle istanze vCenter: gli altri componenti ereditano. Esistono add-on separati, fra cui vSAN (a TiB) e VMware Private AI Foundation, e i report di utilizzo vanno inviati almeno ogni 180 giorni.
Trappole tipiche d’esame
- VCF contro vSphere Foundation. Lo stesso installer e lo stesso wizard producono entrambe, ma VVF non porta SDDC Manager né VCF Automation e non ha la parte di cloud management e automazione integrata. VCF Operations invece c’è in tutti e due: rispondere «VCF Operations» a uno scenario VVF non è automaticamente sbagliato, rispondere «SDDC Manager» sì.
- vSAN ESA contro OSA. È una scelta che si fa alla configurazione del cluster, dentro la selezione dello storage, e lo storage del dominio non si cambia dopo. Uno scenario che chiede di «passare a ESA» dopo il deployment sta chiedendo un ricablaggio, non un’opzione di menu.
- Chi fa cosa fra SDDC Manager e VCF Operations. SDDC Manager copre il lifecycle di ESX, vCenter e NSX; il deployment day-N delle management appliance passa da Fleet Management → Lifecycle in VCF Operations, e il commissioning degli host si fa dal vSphere Client. E l’appliance dell’installer è fisicamente la stessa di SDDC Manager.
- NSX Manager condiviso. Due workload domain possono condividere un NSX Manager; nessun workload domain può usare quello del management domain.
- I quattro «Operations» sono appliance diverse. VCF Operations, VCF Operations fleet management, VCF Operations for Logs e VCF Operations for Networks hanno binari, installazioni e nodi propri (Logs può essere Standard o Cluster, Networks vuole Platform più Collector). Il blueprint scrive «VCF Network Operations», la documentazione di prodotto «VCF Operations for Networks»: stesso prodotto.
- Licenze. Nessuna chiave a 25 caratteri, e l’assegnazione avviene sulle istanze vCenter, non sui singoli componenti.