In VCF 9.0 il cluster vSphere non è un oggetto isolato: è l’unità con cui un workload domain cresce, e la documentazione lo chiama SDDC cluster. Il primo riflesso da correggere è quello di chi arriva dalle versioni precedenti. In 9.0 la doc è esplicita: «You can add an ESX host to an SDDC cluster using the vSphere Client» e «you can use the vSphere Client to add an SDDC cluster to a VCF domain». La crescita del dominio si guida quindi dal vSphere Client, mentre la riconciliazione dell’inventario resta in VCF Operations: quando qualcuno tocca vCenter o NSX fuori banda, i workflow possono bloccarsi e si rimedia da Inventory → Detailed View → VCF Instances → <dominio> → Actions → Sync Inventory. Attenzione a una limitazione che l’esame ama: il sync valida e include tutti i cluster vSphere di quel vCenter, non se ne può selezionare un sottoinsieme.

Scegliere il modello di cluster prima di crearlo

La doc di design descrive quattro modelli e la scelta è irreversibile a costo zero. Il Single-Rack Cluster Model ha un solo storage fault domain, rete Layer 2 fra gli host ESX, protezione vSphere HA e nessuna difesa contro il guasto di un rack. Il Layer 2 Multi-Rack introduce più fault domain di storage restando in L2, ed è l’unico modello multi-rack ammesso come cluster di default del management domain. Il Layer 3 Multi-Rack isola i broadcast domain per rack a prezzo di subnet e VLAN aggiuntive, ma non è supportato come cluster di default del management domain e non può essere stretched. Lo Stretched Cluster Model porta due storage fault domain su due availability zone che devono contenere lo stesso numero di host; lo stretch si esegue via API di SDDC Manager con specifica JSON, richiede che il cluster di default del management domain sia già stretched, e non è ammesso se il cluster condivide una vSAN Storage Policy con altri cluster o se gli host sono su subnet diverse.

Creare il cluster e la sua immagine

Nel vSphere Client il nuovo cluster nasce con il wizard New Cluster, dove si attivano vSphere HA, vSphere DRS e vSAN, e dove si può indicare un reference host di cui usare l’immagine per il cluster. Il flusso Quickstart organizza il resto in tre blocchi — Cluster basics, Add hosts, Configure cluster — e ha una trappola operativa: premere Skip Quickstart è definitivo, quel cluster non torna più al workflow guidato. Sul ciclo di vita, VCF usa le vSphere Lifecycle Manager images per portare software e firmware sugli host ESX di un SDDC cluster; l’immagine si costruisce nel vSphere Client e poi si importa nell’istanza VCF da VCF Operations, e un cluster può arrivare a quattro definizioni aggiuntive che compongono una singola immagine composita, utile quando l’hardware nel cluster non è omogeneo.

vSphere HA: quattro leve, non una

Nel pannello del cluster le impostazioni HA sono raggruppate in Failures and responses (risposta al guasto host, isolamento, VM Monitoring, VM Component Protection), Admission Control, Heartbeat Datastores e Advanced Options, con Proactive HA a parte. Sotto il cofano ogni host riceve l’agente FDM e uno viene eletto primary: comunica con vCenter, sorveglia VM protette e host secondari e, quando la rete di gestione cade, usa il datastore heartbeating per distinguere un host davvero guasto da uno partizionato o isolato. L’admission control offre tre policy: Cluster Resources Percentage, Slot Policy e Dedicated Failover Hosts. Il Performance degradation threshold non è una quarta policy: richiede DRS, vale 100% di default (nessun avviso) e produce avvisi, non blocchi.

DRS, vCLS e resource pool

DRS lavora in Fully Automated, Partially Automated o Manual, con un migration threshold su cinque livelli da Conservative ad Aggressive; il DRS Score di ogni VM misura quanto bene sta girando e la media pesata è il Cluster DRS Score, visibile nella scheda Summary e come istogramma in Monitor. Prerequisiti veri: storage condiviso, rete vMotion e compatibilità CPU (EVC o maschere). I vCLS meritano un paragrafo a sé: dalla 8.0 Update 3 sono basati su vSphere Pod ed è l’Embedded vCLS (fino a due VM per cluster) a essere distribuito su host ESX 8.0 U3 o successivi, mentre sugli host precedenti resta l’External vCLS (fino a tre VM). Se un datastore che ospita VM vCLS va in maintenance mode, o si fa storage vMotion manuale o si mette il cluster in retreat mode. E soprattutto: «vCenter 9.0 deprecates vCLS, and the service will be removed in a future vCenter release». I resource pool restano la gerarchia classica: root pool invisibile per host o cluster DRS, Shares su Low/Normal/High/Custom, Reservation con flag Expandable che permette di prendere in prestito dal genitore, Limit come tetto.

Distribuire le macchine virtuali

Il wizard New Virtual Machine parte dal tasto destro su datacenter, cartella, cluster, resource pool o host e attraversa Select a creation type, Select a name and folder, Select a compute resource, Select storage (dove si sceglie anche la VM storage policy), Select compatibility, Select a guest OS, Customize hardware, Ready to complete. Da un template si passa per Deploy from template o per New VM from This Template, con le tre opzioni di clone: personalizzare il sistema operativo guest, personalizzare l’hardware, accendere la VM dopo la creazione. Le content library sono Local (eventualmente pubblicata) o Subscribed — la seconda non accetta upload — e conservano VM template, OVF/OVA e ISO su un datastore. Sull’hardware: le storage policy si compongono con regole per datastore VMFS, Host-Based Data Services, Virtual Volumes e Tag-Based Placement; il thin provisioning alloca i blocchi al primo accesso ed è convertibile in thick; un RDM è un file che punta a una LUN raw; lato CPU si governano vCPU, cores per socket, reservation/limit/shares, l’esposizione della virtualizzazione hardware al guest, CPU/MMU Virtualization e la Scheduling Affinity, con il CPU Hot Add disattivato di default.

Gestire la VM dal vCenter

Gli stati sono Power On, Power Off, Suspend, Reset e l’hard stop da usare solo quando la VM non risponde. Gli snapshot catturano impostazioni, stato di alimentazione, stato dei dischi e — opzionalmente — la memoria, creando delta disk per ogni disco: sono «short-term solutions», non backup. La migrazione può spostare la risorsa di calcolo, i file su un altro datastore con Storage vMotion, o entrambi; lo stato della VM (memoria, registri, connessioni di rete) viene copiato sull’host di destinazione. L’EVC di cluster uniforma le feature CPU, il per-VM EVC è disattivato di default, e in vSphere 9.0 si può creare una custom EVC mode costruita sull’insieme più alto di feature CPU e vSGA comuni agli host selezionati. Infine l’upgrade: prima VMware Tools, poi la compatibilità della VM, che richiede lo spegnimento del guest e può essere schedulata al riavvio successivo.

Trappole tipiche d’esame

  • VCF non è VVF. VCF 9.0 «consists of» vSphere, vSAN, NSX, VCF Operations e VCF Automation; di vSphere Foundation la doc dice che «does not include the cloud management and integrated automation capabilities that are available in VMware Cloud Foundation». Una domanda che chiede quale piattaforma serve per l’automazione self-service si risolve qui.
  • Dove si fa cosa. Aggiungere host o un nuovo SDDC cluster a un dominio si fa dal vSphere Client; risincronizzare l’inventario dopo modifiche out-of-band si fa da VCF Operations con Sync Inventory; lo stretch di un cluster passa dalle API di SDDC Manager. Le risposte che spostano queste operazioni sulla console sbagliata sono i distrattori più frequenti.
  • Witness sì, witness no. In uno stretched cluster il witness serve ai cluster vSAN (sia ESA sia OSA) e ai cluster storage, non allo stretch di un cluster compute. La discriminante è il tipo di cluster, non la scelta fra architettura ESA e OSA: chi legge «ESA» e risponde «niente witness» cade.
  • vCLS: quanti e quali. Due VM con Embedded vCLS su ESX 8.0 U3 o successivo, tre con External vCLS sugli host precedenti — e vCLS è deprecato in vCenter 9.0. Una domanda formulata al presente sul numero di VM vCLS è ambigua per costruzione: guarda sempre la versione degli host nello scenario.
  • Admission control non è il performance threshold. Le policy sono tre e regolano cosa si può accendere; il performance degradation threshold richiede DRS, di default è al 100% e genera avvisi. Confondere i due porta a scegliere la risposta «impedisce l’accensione», che è sbagliata.