Un workload domain è l’unità con cui VCF separa il consumo dalla gestione: ha un proprio vCenter, uno o più cluster vSphere, la propria infrastruttura NSX e il proprio storage. Il management domain nasce dal VCF Installer e contiene i componenti di gestione della VCF Instance — SDDC Manager, l’appliance di fleet management, il vCenter di gestione e, per la prima VCF Instance, VCF Operations e VCF Automation. I workload domain, invece, si creano da VCF Operations, e per il primo di essi VCF Operations depone il vCenter e l’NSX Manager dedicati dentro il management domain. Il vincolo secco da ricordare: un workload domain non può usare il cluster NSX Manager del management domain, mentre due workload domain possono condividere lo stesso NSX Manager.

Prima del wizard: host commissionati e network pool

Il wizard non prepara l’infrastruttura, la consuma. Aggiungere host all’inventario globale si chiama commissioning: dal vSphere Client, Global Inventory Lists → Hosts → Unassigned Hosts → Commission Hosts. Per ogni host si dichiarano FQDN, credenziali root, tipo di storage e network pool, si verificano i fingerprint, si esegue Validate All e si conferma con Commission. Il tipo di storage non è un’etichetta: un host commissionato per NFS non entrerà in un cluster vSAN. Le scelte disponibili sono vSAN (nelle varianti HCI con o senza ESA, Storage, Compute Cluster), NFS, VMFS on FC e vVols con protocollo FC, iSCSI o NFS.

La network pool è «una collezione di sottoreti in un dominio di rete layer-2» che assegna IP statici alle VMkernel degli host per vMotion, vSAN, vSAN Storage Client, NFS e iSCSI. Va creata prima del commissioning, deve contenere le reti richieste dal tipo di storage scelto, e le sue subnet non si cambiano dopo il deploy. Prerequisiti sugli host: certificazione hardware coerente con lo storage, partizioni cancellate, NIC da almeno 10 Gbps con una su vSwitch standard per il management, FQDN risolvibile e certificato rigenerato sull’FQDN. Serve infine un’immagine cluster di vSphere Lifecycle Manager.

Il wizard: dove sta e dove si biforca

VCF Operations → Inventory → Detailed View, si espande VCF Instances, si sceglie l’istanza e si fa Add Workload Domain → Create New. Dopo la checklist si danno nome del dominio (3–20 caratteri), dominio SSO e password, poi FQDN e password root del vCenter, nome cluster ed eventuale nome della vSphere Zone, quindi l’immagine cluster.

Il passo NSX Manager è quello che pesa: si crea un nuovo NSX Manager o si aggancia uno esistente, si sceglie fra deployment Standard (nodo singolo) e High-Availability (cluster a tre nodi), la taglia appliance (Medium, Large, Extra Large) e soprattutto il tipo di connettività, Centralized oppure Distributed. La modalità Distributed chiede VLAN ID, Gateway CIDR, External IP Block e Private Transit Gateway IP Block; il vSphere Supervisor richiede invece Centralized.

Segue la selezione host — solo quelli commissionati con lo storage giusto — e il profilo di distributed switch: Default (un solo VDS), Storage Traffic Separation, NSX Traffic Separation, entrambe le separazioni (tre switch) o Custom Switch Configuration. I tipi di traffico obbligatori sono Management, vMotion, vSAN e NSX, e si configurano una volta sola per cluster. Si chiude con Finish e si segue l’avanzamento in Fleet Management → Tasks.

Storage: principale, supplementare, e vSAN nelle sue forme

Lo storage principale è quello usato alla creazione del dominio o del cluster ed è in grado di eseguire workload; lo storage supplementare si aggiunge dopo e può ospitare workload o dati a riposo. Sono principali vSAN ESA, vSAN OSA, lo storage cluster, il Fibre Channel e NFS v3; sono solo supplementari iSCSI, NVMe/TCP, NVMe/FC e NFS v4.1. Il vVol risulta deprecato a partire da VCF 9.0 e richiede comunque un VASA provider.

Nel wizard vSAN significa spuntare o meno Enable vSAN ESA: ESA è architettura a singolo livello su soli dischi NVMe, OSA è a due livelli e accetta SATA, SAS e NVMe. OSA chiede il valore di Failures to Tolerate — che determina il numero minimo di host — e l’interruttore di space efficiency (deduplica e compressione); ESA chiede il tipo di cluster, vSAN HCI o vSAN Storage, con storage policy in auto-policy management. Un cluster HCI parte da tre host; uno storage cluster disaggregato ne richiede almeno quattro, contribuisce solo capacità e non esegue macchine virtuali, e i compute cluster che lo consumano devono stare nello stesso dominio. NFS chiede nome datastore, path della cartella e IP del server; FC chiede solo il nome del datastore, perché LUN e datastore devono già essere presentati e montati sugli host.

Il Supervisor dentro il workload domain

Nel wizard l’interruttore Enable vSphere Supervisor è attivo per impostazione predefinita e produce un Supervisor con una control plane VM e una zona. I campi sono Supervisor Name, Service CIDR, la casella «Use ESX Management VMK settings» (che eredita la configurazione di gestione degli host, altrimenti si dichiarano VLAN, Control Plane IP Range con almeno cinque indirizzi, subnet mask e gateway), il VDS, l’NSX Project, il VPC Connectivity Profile, i CIDR privati e infine DNS e NTP dei workload. Se il Supervisor è attivo, l’attivazione si completa solo dopo aver messo in campo un NSX Edge cluster con tier-0 gateway in active-standby.

Una vSphere Zone corrisponde a un cluster vSphere: i modelli a tre zone di management proteggono il piano di controllo dal guasto di un singolo cluster, ma richiedono la control plane in alta disponibilità e sono attivabili solo via API. Il modello semplificato (Easy Supervisor) ha una sola control plane VM, una sola rete per management e workload e nessun load balancer: supporta VM Service ma non i vSphere Pod né i Supervisor Services, e si estende in seguito aggiungendo un load balancer, portando le control plane VM a tre e aggiungendo una seconda vNIC. Sui load balancer: NSX è il default e non richiede entitlement aggiuntive ma vale solo per i modelli VPC e Segment; Avi copre tutti i modelli con licenza separata; il Foundation Load Balancer funziona solo con networking VDS ed eroga regole di livello 4. Le storage policy del Supervisor si cambiano in vSphere Client → Supervisor Management → Supervisors → Configure → Storage, su tre voci: Control Plane Node, Pod Ephemeral Disks, Container Image Cache.

Espandere, importare, riallineare

Un dominio si espande aggiungendo host a un cluster esistente o aggiungendo un nuovo cluster, fino ai massimi supportati da vSphere. Con Add Workload Domain → Import a vCenter si porta dentro un vCenter già esistente: richiede vCenter e ESX 8.0 Update 1 o successivi, VDS 8.0 o successivo, NSX Manager 4.2+ se già presente, SSH abilitato sul vCenter, FQDN e non nomi brevi nell’inventario, DRS in automazione completa e VMkernel a IP statico salvo i TEP NSX; importa tutti i cluster, non un sottoinsieme, e attiva il Distributed Firewall su tutti i DVPG. Le configurazioni che la UI non copre — password root diverse fra host, LACP, cluster vSAN HCI layer-3 multi-rack — passano dalla specifica JSON e dall’API di VCF Operations. Quando inventario di SDDC Manager e vCenter divergono per modifiche fuori banda, alcuni workflow si bloccano: si rimedia con Actions → Sync Inventory, un dominio alla volta.

Trappole tipiche d’esame

  • ESA non è il default implicito. Se nel wizard non si spunta Enable vSAN ESA si ottiene vSAN OSA. ESA vuole solo NVMe ed è a singolo livello; OSA è a due livelli e accetta anche SATA e SAS.
  • Principale contro supplementare. NFS è principale solo in versione 3; iSCSI, NVMe/TCP e NVMe/FC non sono mai storage principale, quindi non compaiono come scelta alla creazione del dominio anche se il cluster potrà usarli dopo.
  • Centralized contro Distributed. Il vSphere Supervisor richiede la connettività NSX Centralized: chi sceglie Distributed per eleganza di design si preclude il Supervisor su quel dominio.
  • Il Supervisor del wizard è minimo. Nasce con una control plane VM e una zona; le tre zone di management si attivano solo via API, e senza un Edge cluster con tier-0 active-standby l’attivazione non si chiude.
  • vSAN HCI non è vSAN Storage. Lo storage cluster disaggregato parte da quattro host e non esegue VM; l’HCI parte da tre. E VVF non è VCF: la documentazione dice esplicitamente che vSphere Foundation «non include le capacità di cloud management e di automazione integrata» presenti in VMware Cloud Foundation.