Il cluster è l’oggetto d’inventario in cui un host ESX smette di essere un server a sé e diventa una quota di un pool. Vive sotto un data center, aggrega CPU e memoria degli host che contiene e ospita i due servizi su cui l’esame insiste: vSphere DRS, che decide dove una macchina virtuale gira, e vSphere HA, che decide che cosa succede quando l’host su cui girava sparisce. Su VMware vSphere Foundation tutto questo si configura nel vSphere Client contro vCenter: non c’è un livello di automazione sopra e il networking sotto è quello di vSphere — distributed switch, port group, VMkernel.

Quello che si decide creando il cluster

Alla creazione si sceglie se attivare vSphere DRS, vSphere HA e vSAN, e se gestire tutti gli host del cluster con una singola immagine di vSphere Lifecycle Manager indicando un reference host da cui estrarla. Le prime tre sono spunte che si possono cambiare dopo; la scelta dell’immagine unica orienta invece tutto il lifecycle successivo degli host, quindi va fatta consapevolmente.

Il cluster si configura poi a mano o con il flusso Quickstart, organizzato in tre card: Cluster basics, Add hosts, Configure cluster. Quickstart è comodo perché gli host aggiunti vengono configurati per corrispondere alla configurazione del cluster, impostazioni di rete comprese, ma ha prerequisiti reali: ESX 7.0 o successivo, credenziali root, e host che non arrivino con una configurazione vSAN o di rete già fatta a mano. Fra le opzioni avanzate del flusso compaiono proprio admission control, automation level, migration threshold, lockdown mode e server NTP.

DRS: automazione, soglia e DRS Score

DRS lavora su due momenti distinti: il posizionamento iniziale, quando una VM si accende, e il bilanciamento continuo, che sposta le VM accese con vMotion. Il livello di automazione stabilisce quale dei due sia automatico. Con Manual le raccomandazioni di posizionamento e di migrazione vengono mostrate e si applicano a mano; con Partially Automated il posizionamento iniziale è automatico e le migrazioni restano raccomandazioni; con Fully Automated sono automatici entrambi. Esiste anche lo stato Disabled, in cui vCenter non migra nulla.

Il migration threshold misura quanto DRS è aggressivo nel raccomandare migrazioni e va da Conservative ad Aggressive: in Conservative genera solo raccomandazioni di priorità uno, cioè quelle obbligatorie. Il metro di merito è il DRS Score, la «VM happiness»: lo score del cluster è la media pesata dei DRS Score delle VM accese e si legge nella scheda Monitor del cluster. Perché DRS abbia qualcosa da fare servono i presupposti di vMotion: storage condiviso raggiungibile da tutti gli host, rete vMotion e CPU compatibili. Da qui EVC, che maschera alcune feature dei processori così che tutti gli host presentino alle VM lo stesso set di istruzioni; richiede CPU dello stesso vendor, e in vSphere 9.0 accanto alle baseline predefinite c’è il Custom EVC Mode, che calcola il set più alto di feature comune agli host selezionati. Senza vMotion DRS resta utile per il solo posizionamento iniziale.

Un’avvertenza che smonta una nozione ormai vecchia: vCenter 9.0 deprecates vCLS e raccomanda di portare il servizio in retreat mode per evitare consumo ridondante di risorse, perché «Deactivating vCLS does not impact the operation of vSphere DRS and vSphere HA services».

Le regole che vincolano il posizionamento

Sopra DRS si costruiscono i vincoli: si definiscono VM group e host group, poi si scrivono regole VM-VM (tenere le VM insieme o separarle) e regole VM-Host nelle quattro forme Must run on hosts in group, Should run on hosts in group, Must not run on hosts in group, Should not run on hosts in group. La differenza fra must e should non è stilistica: la prima è un vincolo, la seconda una preferenza sacrificabile. Quando una regola viene violata il cluster continua a operare e cerca di correggere la violazione; in cluster manuali o parzialmente automatici la correzione arriva come raccomandazione. Le violazioni si leggono nella scheda DRS del cluster, sotto Faults.

HA: chi sorveglia chi, e come distingue i guasti

Attivando HA, su ogni host viene caricato un agente e un host viene eletto automaticamente primary; gli altri sono secondary. Il primary parla con vCenter, monitora VM e host e fa network heartbeating sulla rete di management. Il punto decisivo: quando il primary non raggiunge più un secondary via rete, usa il datastore heartbeating per capire se quell’host è davvero fallito oppure soltanto isolato o finito in una partizione di rete — un host fallito smette di scrivere heartbeat sul datastore, un host isolato no. Da questa distinzione dipende la host isolation response, che governa il comportamento quando un host perde la connettività di management.

La configurazione si articola in quattro blocchi: Failures and responses, Admission Control, Heartbeat Datastores e Advanced Options. Dentro il primo vivono VM Component Protection, che rileva i guasti di accessibilità del datastore e automatizza il recupero negli scenari APD e PDL, e VM Monitoring, che riavvia le singole VM se gli heartbeat di VMware Tools non arrivano entro il tempo impostato.

Admission control e risorse condivise

L’admission control di HA è la riserva che rende credibile il failover, e serve almeno tre host. Le policy sono tre più la disattivazione: Cluster resource percentage, che riserva una percentuale di CPU e memoria del cluster; Slot policy, che garantisce risorse sufficienti al failover delle VM di un numero dichiarato di host; Dedicated failover hosts, che designa host di riserva. A parte c’è la soglia di degrado prestazionale tollerato: 100% non avvisa mai, 0% avvisa appena l’utilizzo supera la capacità disponibile.

Dentro il cluster le risorse si suddividono con i resource pool, gerarchici, con shares, reservation e limit e con l’Expandable Reservation che consente al figlio di prendere in prestito risorse dal padre risalendo ricorsivamente la gerarchia. Attenzione alla rimozione di un host: la gerarchia resta al cluster e l’host si tiene solo il root resource pool, quindi lo si mette prima in maintenance mode. Su un cluster DRS si può infine attivare vSphere DPM, che confronta la domanda cumulativa di CPU e memoria con la capacità, mette host in standby mode e li spegne dopo aver migrato le VM, risvegliandoli con IPMI, iLO o WOL in quest’ordine.

Trappole tipiche d’esame

  • VVF non è VCF. Su vSphere Foundation il cluster si configura nel vSphere Client: niente NSX, niente VCF Automation, niente workload domain. Corollario che l’esame sfrutta: i vSphere Pod richiedono NSX come networking stack, quindi su VVF i container girano nei cluster VKS.
  • HA riavvia, DRS bilancia. HA non fa vMotion delle VM di un host morto: le riaccende altrove. DRS non riavvia niente dopo un crash. E l’«admission control» di HA (capacità riservata al failover) non è il controllo che vCenter fa all’accensione di una VM per verificare le risorse disponibili.
  • Isolato non vuol dire fallito. Se una domanda descrive un host che perde solo la rete di management, la risposta passa dal datastore heartbeating e dalla isolation response, non dal riavvio immediato delle VM.
  • vSAN cambia le regole di HA. Con vSAN attivo il traffico fra agenti HA scorre sulla rete vSAN e non su quella di management, e i datastore vSAN non si usano come heartbeat datastore. L’ordine conta: HA va disattivato mentre si abilita vSAN sul cluster, e riattivato dopo.
  • vCLS: la memoria vecchia inganna. In vCenter 9.0 il servizio è deprecato e la retreat mode è raccomandata; disattivarlo non compromette DRS né HA. Chi risponde «senza vCLS DRS si ferma» sta citando una versione precedente.