L’obiettivo 2.1 sembra il più innocuo del blueprint e invece è quello dove si perdono punti stupidamente, perché chiede due cose che si somigliano ma non coincidono: quali problemi risolve la virtualizzazione (i casi d’uso) e perché l’azienda ci mette dei soldi (la value proposition). La documentazione parte da una definizione volutamente banale — una macchina virtuale è «a software computer» che esegue un sistema operativo e applicazioni, con la propria CPU virtuale, memoria, disco e scheda di rete — e da lì costruisce tutto il resto. Conviene tenere il ragionamento su tre assi: consolidamento, continuità, agilità.

Consolidamento: il ferro diventa un pool

ESX gira sul bare metal di server x86 standard e serve, testualmente, «as a platform for running virtual machines and allows for the consolidation of computing resources». Consolidare qui non vuol dire solo «meno server nel rack»: vuol dire che CPU, memoria, storage e rete smettono di essere attributi di una macchina e diventano pool da cui le VM attingono dinamicamente. È l’oggetto cluster dell’inventario a rendere la cosa operativa: una raccolta di host ESX e delle VM associate «intended to work together as a unit», dove vCenter gestisce le risorse dell’insieme come una sola entità.

Il meccanismo che produce davvero il risparmio è il livello di mappatura in più introdotto dalla virtualizzazione: il VMM di ogni VM mantiene la corrispondenza fra le pagine «fisiche» viste dal guest e quelle reali dell’host, e questo permette a ESX di gestire la memoria trasversalmente a tutte le VM. Da lì l’overcommitment: la somma della memoria configurata può eccedere la RAM fisica dell’host, e ha senso perché «some virtual machines are lightly loaded while others are more heavily loaded». Quando la coperta si accorcia intervengono ballooning, page sharing, compressione e swapping. Sopra ci stanno i controlli che l’amministratore tocca davvero — reservation, limit, shares — e i resource pool, che servono a delegare: si dà a un reparto il controllo delle risorse dentro il perimetro del suo pool, isolato dagli altri, senza dargli il cluster.

Continuità: il downtime pianificato è la voce grossa

Qui la documentazione fornisce il dato che l’esame ama: il downtime pianificato — manutenzione hardware, migrazione dei server, aggiornamenti firmware — vale «over 80% of data center downtime». Il valore non sta principalmente nel sopravvivere ai guasti, ma nell’eliminare le finestre di fermo concordate. Lo strumento è vSphere vMotion: si sposta una VM accesa su un altro host «without any interruption in its availability», e da Actions > Migrate si sceglie se muovere solo il compute, solo lo storage (Storage vMotion) o entrambi. La cold migration resta per VM spente o sospese, e permette anche il salto fra data center e fra virtual switch diversi.

Sul non pianificato agiscono due meccanismi che l’esame confronta di continuo. vSphere HA sfrutta più host ESX configurati a cluster «to provide rapid recovery from outages»: rapido, ma è un riavvio, quindi lo stato in memoria si perde. vSphere Fault Tolerance protegge la VM da un guasto host «with no loss of data, transactions, or connections», perché la Secondary VM ne assume il ruolo con l’intero stato preservato. I casi d’uso di FT sono elencati: applicazioni che devono essere sempre disponibili, specie con connessioni client di lunga durata; applicazioni custom prive di clustering nativo; alternativa a soluzioni di clustering troppo onerose da configurare e mantenere; e la protezione on demand, attivata per un periodo critico — la documentazione cita la chiusura trimestrale — e poi disattivata. Sul piano di gestione, vCenter High Availability aggiunge il failover automatico da nodo attivo a passivo.

Agilità: la VM è un insieme di file

Una VM «consists of a set of specification and configuration files and is backed by the physical resources of a host». È da qui che discende tutto il valore di agilità: si sposta, si clona, si versiona. ESX presenta l’hardware dell’host come «a normalized set of resources», e i datastore nascondono le idiosincrasie dello storage fisico presentando un modello uniforme: per questo una VM si sposta da un host a un altro, o i suoi dischi da un tipo di storage a un altro, senza che il funzionamento cambi. In pratica: template e cloni per il provisioning ripetibile, content library per distribuire quei template, OVF per portarli dentro e fuori, storage policy da Policies and Profiles > VM Storage Policies per esprimere il requisito invece del LUN. E DRS, da cluster > Configure > vSphere DRS, che fa posizionamento iniziale e bilanciamento, mentre DPM «allows a DRS cluster to reduce its power consumption by powering hosts on and off».

Il valore di VVF, e dove si ferma

VMware vSphere Foundation è descritta come «an enterprise-grade workload platform for modern infrastructure»: piattaforma unificata per VM e container, operations intelligenti, iperconvergenza, deployment semplificato. In concreto porta vSphere (vCenter Standard, ESX, vSphere Supervisor), vSAN — che aggrega i dispositivi locali o direct-attached di tutti gli host ESX del cluster «and creates a single storage pool», con policy per-VM, RAID 5/6 e scaling indipendente di compute e storage — più VCF Operations e VCF Operations for Logs per monitoraggio, capacità, costi e compliance. E si ferma lì: VVF «does not include the cloud management and integrated automation capabilities» di VCF.

Trappole tipiche d’esame

  • VVF non è VCF. Niente NSX, niente VCF Automation, niente workload domain. Il networking dell’esame è quello di vSphere: standard switch, distributed switch, port group, VMkernel, teaming, VLAN. Una risposta che cita l’overlay o i segmenti logici è sbagliata per costruzione.
  • Container sì, vSphere Pod no. I vSphere Pod «are only supported with Supervisors that are configured with NSX as the networking stack»: su VVF i workload Kubernetes girano nei cluster VKS, non nei Pod. Il blueprint nomina i Pod, la doc ne pone il limite.
  • HA non è «zero downtime». HA riavvia le VM su un altro host: veloce, ma con perdita dello stato in memoria. Solo FT promette nessuna perdita di dati, transazioni o connessioni. Chi confonde i due sbaglia quasi sempre la domanda sul mission-critical.
  • vMotion non è una tecnologia di disaster recovery. Richiede una VM accesa e un host sano: copre il downtime pianificato, non il guasto improvviso. È esattamente l’inverso dell’uso di HA.
  • L’overcommit non è memoria gratis. Funziona perché i carichi non sono tutti al picco insieme, e si governa con reservation, limit e shares; l’overhead di virtualizzazione è riservato e sottrae memoria disponibile.