Le operazioni Day 2 sono tutto quello che viene dopo il collaudo: la piattaforma è in piedi, i carichi girano, e il tuo lavoro diventa mantenerla prevedibile. Su VMware vSphere Foundation questo perimetro ha confini precisi che vale la pena fissare subito, perché l’esame ci gioca sopra. Gli strumenti Day 2 di VVF sono il client vSphere su vCenter, VCF Operations per metriche, capacità e compliance, e VCF Operations for Logs per la raccolta centralizzata dei log. Non c’è NSX, non c’è VCF Automation, non ci sono i workload domain: se una domanda ti chiede di creare un dominio di carico o di pubblicare un catalogo self-service per gli sviluppatori, la risposta corretta sta altrove, non in VVF.

Task, eventi e allarmi: il giornale di bordo

Ogni azione in vCenter produce un task. I task si consultano per singolo oggetto o per l’intero inventario, si possono filtrare e si possono annullare mentre sono in corso. Molte operazioni ricorrenti — accensione e spegnimento di una VM, clonazione, migrazione, snapshot, controllo di conformità — si possono schedulare, una volta sola nel futuro oppure a intervallo ricorrente. Attenzione a un dettaglio operativo: annullare un task schedulato ferma quell’esecuzione, non le successive.

Gli eventi sono i record di ciò che utenti e sistema hanno fatto, classificati in Error, Warning, Information e Audit. Gli allarmi si costruiscono sopra agli eventi e agli stati: una definizione d’allarme ha nome e descrizione, i target (il tipo di oggetto monitorato), le Alarm Rules con i trigger e la severità — verde, giallo, rosso — e le azioni. Il trigger può essere basato su condizione o stato (una soglia, per esempio l’utilizzo CPU di un host) oppure basato su evento (l’evento specifico è accaduto). Gli allarmi predefiniti non hanno azioni configurate: l’invio della mail lo aggiungi tu. Le definizioni si toccano sotto Configure > Alarm Definitions; gli allarmi scattati si leggono nella scheda Monitor dell’oggetto. Dare Acknowledge a un allarme interrompe le sue azioni ma non lo riporta in verde; un allarme innescato da evento che non torna da solo in stato normale va resettato manualmente.

Manutenzione degli host e mobilità dei carichi

Prima di riavviare o spegnere un host lo si mette in maintenance mode, avendo spento le VM oppure migrate con vMotion su un altro host. Il menu è Actions > Power > Reboot o Shut Down, e vCenter chiede di motivare l’operazione. In un cluster con DRS l’evacuazione è automatica, ed è qui che si vede se le regole di affinità che hai scritto reggono.

Le migrazioni sono quattro casi distinti: cold migration di una VM spenta o sospesa (può attraversare data center e cambiare switch virtuale), vSphere vMotion di una VM accesa senza interruzione di servizio, Storage vMotion dei soli file su un altro datastore, e la combinazione dei due. Per spostarsi fra istanze vCenter diverse esiste Advanced Cross vCenter vMotion, che non dipende da Enhanced Linked Mode. Quando gli host hanno CPU di generazioni diverse, è EVC a rendere possibile la migrazione allineando il set di funzionalità esposto ai guest.

Snapshot: strumento tattico, non backup

Uno snapshot cattura le impostazioni della VM, lo stato dei dischi e, se lo chiedi, la memoria. Genera un disco delta .vmdk su cui vengono dirottate le scritture, un file .vmsn per la memoria e un .vmsd di metadati. Ogni ramo dell’albero arriva a 32 snapshot. Eliminare uno snapshot consolida il delta nel disco padre; ripristinare riporta la VM allo stato salvato. La documentazione è esplicita: gli snapshot servono per il breve periodo e non sono adatti come backup, e i file non vanno manipolati a mano.

Il backup di vCenter

vCenter è esso stesso un carico Day 2. Il file-based backup si lancia dalla vCenter Management Interface (la VAMI sulla 5480) e trasmette configurazione, inventario e dati storici via FTP, FTPS, HTTP, HTTPS, SFTP, NFS o SMB su un sistema remoto; i backup si possono schedulare. Il ripristino non è un “restore in place”: si distribuisce una nuova appliance con l’installer GUI e ci si copia dentro il backup, in due fasi.

Content library: un catalogo, molti consumatori

Una libreria locale vive in una singola istanza vCenter e può essere pubblicata per essere consumata altrove; una libreria sottoscritta consuma una libreria pubblicata e non accetta upload né import. Gli elementi possono essere template OVF, VM template, ISO, file di testo. Lo storage è un datastore, e la libreria si può migrare fra vSAN, VMFS, vVol e NFS dentro lo stesso vCenter.

La scelta che pesa davvero è il modello di sincronizzazione. Scaricando subito tutti i contenuti si sincronizzano metadati e contenuti; scaricando solo quando servono si sincronizzano i soli metadati, risparmiando spazio, e i contenuti di un elemento si possono cancellare quando non servono più. La sincronizzazione si può forzare a mano su un singolo elemento o su tutta la libreria, e il comportamento automatico si governa nelle impostazioni avanzate (Library Auto Sync Enabled, Library Auto Sync Refresh Interval (minutes), Library Maximum Concurrent Sync Items, Maximum Bandwidth Consumption, e altre; alcune richiedono il riavvio di vCenter). Sui VM template la libreria offre il ciclo check out / check in: mentre il template è in checkout gli altri non possono prenderlo, ma continuano a distribuire VM da esso; ogni check-in crea una nuova versione, e una timeline permette di tornare a versioni precedenti. La OVF security policy impone validazione stretta sugli elementi OVF in deploy, import e sincronizzazione.

Cifratura: prima il key provider, poi le VM

La cifratura vSphere richiede un key provider configurato e impostato come predefinito. Lo Standard Key Provider usa un key server KMIP esterno: solo vCenter ha le credenziali per accedervi, gli host ESX no, e vCenter ottiene le chiavi e le spinge sugli host; quelle chiavi fanno da KEK, mentre le chiavi interne generate dall’host sono le DEK che cifrano i dati. Il vSphere Native Key Provider non richiede alcun key server esterno, si configura rapidamente da vCenter > Configure > Security > Key Providers > Add > Add Native Key Provider, e funziona solo con vSphere. Va sottoposto a backup prima di poter essere usato: finché non lo fai, vCenter alza un allarme che si ripresenta ogni 24 ore. Il backup si protegge con password, e sia la password sia il file vanno custoditi. Opzionalmente puoi vincolare il provider ai soli host con TPM 2.0. La key persistence sull’host serve a far sopravvivere i carichi cifrati a un key server irraggiungibile: non è necessaria con il Native Key Provider.

Con il provider in piedi, una VM si cifra tramite policy di storage: alla creazione si seleziona “Encrypt this virtual machine” e la policy — c’è quella di esempio, VM Encryption Policy. Servono i privilegi Cryptographic operations (per esempio Encrypt new), Profile-driven storage update e le modifiche di configurazione sulla VM; cifrare una VM nuova è più rapido ed economico che cifrarne una esistente, che va spenta. Il vTPM dipende anch’esso da un key provider. Sul movimento: encrypted vSphere vMotion ha tre stati per le VM non cifrate — Disabled, Opportunistic (predefinito) e Required — ma per una VM cifrata la cifratura del vMotion è sempre attiva e non disattivabile; e se poi decifri la VM, l’impostazione resta su Required finché non la cambi esplicitamente.

Trappole tipiche d’esame

  • VVF non è VCF. Day 2 su vSphere Foundation si fa con vCenter, VCF Operations e VCF Operations for Logs. Niente NSX, niente VCF Automation, niente workload domain. Corollario da ricordare: i vSphere Pod richiedono NSX come networking stack, quindi su VVF i container girano nei cluster VKS, non nei Pod, anche se il blueprint nomina entrambi.
  • Acknowledge non è reset. Riconoscere un allarme ne ferma le azioni; non lo riporta in verde. Un allarme da evento che non rientra da solo va resettato a mano.
  • Libreria sottoscritta in modalità on demand. Sincronizza solo i metadati, non i contenuti; e in una libreria sottoscritta non puoi caricare né importare elementi. Cancellare il contenuto di un elemento libera spazio ma non elimina l’elemento dal catalogo.
  • Native Key Provider: il backup è un prerequisito, non un’igiene. Senza backup non lo puoi usare, e l’allarme torna ogni 24 ore. Se la domanda cita l’integrazione con prodotti diversi da vSphere o un KMIP già in casa, la risposta è Standard Key Provider.
  • Limiti della cifratura. L’export OVF non è supportato per una VM cifrata, e registrare una VM cifrata dal VMware Host Client non è supportato. I core dump vanno decifrati prima di spostare una VM su un altro cluster.
  • Snapshot ≠ backup. Eliminare uno snapshot consolida nel disco padre, ripristinare torna indietro: sono due verbi diversi, e nessuno dei due è una strategia di protezione dati.