Article VMware vSphere 7: novità e funzioni
By null / 16 Apr 2020
By null / 16 Apr 2020
Il 10 marzo 2020, Vmware ha annunciato vSphere 7, presentandola come la più importante versione degli ultimi dieci anni ed il 2 aprile 2020 è ufficialmente uscito in due edizioni:
vSphere 7
vSphere 7 with Kubernetes
La prima è la nuova edizione dell’hypervirsor di Vmware, con l’introduzione di interessanti novità e miglioramenti; il secondo, oltre ad avere, ovviamente, le medesime caratteristiche e funzionalità, ha in più incorporato nativamente Kubernetes, risultando a tutti gli effetti una piattaforma comune per l'esecuzione contemporanea di workload / Kubernetes containerizzati e macchine virtuali.
Va precisato che mentre la versione senza Kubernetes è disponibile ed acquistabile nelle medesime modalità delle precedenti versione e di cui, più avanti parlerò del licensing, vSphere with Kubernetes è acquistabile attraverso VMware Cloud Foundation.
vSphere Lifecycle Manager vLCM (precedentemente Update Manager) introduce una suite di funzionalità, ai fini di migliorare e facilitare la gestione del ciclo di vita sw. Con vSphere Lifecycle Manager abbiamo un cambiamento radicale sia nella gestione della configurazione di vCenter Server sia in quella dell'host ESXi. Utilizzando un modello di configurazione che si può definire “dello stato desiderato”, gli amministratori di vSphere possono creare configurazioni una volta sola, applicarle e continuare a monitorarne lo stato desiderato attraverso due nuovi strumenti: vCenter Server Profiles e Image Cluster Management (Next-Gen Infrastructure Image Management)
vCenter Server Profiles consente agli amministratori di standardizzare una configurazione per tutti i loro vCenter Server e monitorarla.
Image Cluster Management è la funzione più interessante, e consente agli amministratori di creare immagini standard a livello di cluster, da applicare agli host al proprio interno, e a quelli che verranno di volta in volta aggiunti. Un'immagine del cluster può, per esempio, comprendere l’ultima release di vSphere (ISO di ESXi), patch, eventuali componenti aggiuntivi del vendor hw (esempio drivers, aggiornamenti di firmware); in questo modo, vSphere Lifecycle Manager può comunicare con strumenti di gestione del firmware come ad esempio OMIVVV di Dell. Va detto che attualmente solo Dell ed HPe integrano i loro strumenti con questa nuova caratteristica di vSphere, ma anche gli altri OEM si stanno adoperando in tal senso.
Infine, all'interno di vSphere Lifecycle Manager troviamo un altro strumento molto utile: vCenter Server Update Planner.
vCenter Server Update Planner fornisce strumenti nativi per aiutare a pianificare, scoprire e aggiornare con successo e facilità gli ambienti Vmware. Quando un aggiornamento è disponibile si riceve una notifica direttamente nel Client vSphere; si può monitorare facilmente la matrice di interoperabilità dei prodotti VMware per garantire che l'aggiornamento disponibile sia compatibile con altri software VMware presenti nell'ambiente. E’ possibile eseguire una serie di pre-controlli di compatibilità prima di iniziare un aggiornamento in modo da essere sicuri che questo andrà a buon fine.
vSphere DRS è stato completamente ripensato e migliorato, oltre che ottimizzato sia per le macchine virtuali sia per i container: se prima c’era una logica di cluster-centric, con il nuovo DRS si è passati alla logica del workload-centric.
Il vecchio algoritmo DRS utilizzava un modello di deviazione standard a livello di cluster, una misura dello scarto complessivo del carico del cluster dal suo valore medio; in pratica, DRS, controllava ogni 5 minuti il cluster, e in caso di sovraccarico (ram/cpu) di un host ESXi, lo segnalava all’amministratore e, in caso di configurazione fully automated, tramite vMotion ne garantiva il bilanciamento con opportune migrazioni di VM su altri nodi ESXi piu scarichi.
Il nuovo algoritmo DRS ha un approccio completamente differente, ossia calcola ed assegna un punteggio alle macchine virtuali (VM DRS score) su ogni host, e sposta la macchina virtuale sull'host che fornisce il punteggio più alto; il nuovo DRS, migliora il bilanciamento concentrandosi sulla metrica a cui si tiene di più: la “felicità” della macchina virtuale. Il VM DRS score viene calcolato sulle prestazioni della macchina virtuale, e sull’efficienza della stessa, attraverso diverse metriche, tra cui il tempo di preparazione della CPU (CPU %RDY), lo swap di memoria, il comportamento della CPU Cache, ecc. Inoltre, per determinare il VM DRS score, viene anche considerata la capacità di riserva di risorse, o headroom, di cui dispone un host ESXi. Infine, a differenza del vecchio DRS, che controllava il cluster ogni 5 minuti, ora, il VM DRS score viene calcolato ogni minuto e questo si traduce in un'ottimizzazione molto più granulare delle risorse.
Nel corso degli anni sono state apportate diverse modifiche a vSphere vMotion e la release di vSphere 7 non fa certo eccezione; in particolar modo, i miglioramenti sono stati fatti concentrandosi sui workload complessi (es. SAP Hana, Oracle) e l’impatto che, finora, la tecnologia vMotion ha avuto sulle loro prestazioni.
Le macchine virtuali con un elevato utilizzo di Ram e CPU, come appunto i backend di database SAP HANA e Oracle, hanno sempre avuto ripercussioni negative durante il processo di migrazione vMotion, e spesso, hanno avuto difficoltà ad essere migrate in tempo reale. L'impatto negativo sulle prestazioni durante il processo di vMotion ha spesso scoraggiato i clienti a utilizzare vMotion per questa tipologia di workload, e di conseguenza la funzionalità DRS fully automated.
Senza scendere troppo nel dettaglio, è importante sapere che l’operazione di migrazione tramite vMotion è composta da diversi processi; per la maggioranza delle macchine virtuali, questi processi vengono eseguiti così velocemente da non essere neanche notati, ma la cosa cambia in modo evidente, quando le macchine virtuali hanno grande allocazione di Ram e Cpu, soprattutto in termine di allungamento delle tempistiche di migrazione. Per ovviare a tutto questo, molti di questi processi sono stati migliorati. Uno di questi processi utilizza i cosiddetti Page-tracers in cui vMotion tiene traccia dell'attività di paging della memoria durante una migrazione. Prima di vSphere 7, durante una migrazione, il processo di tracciamento delle pagine impattava tutte le vCPU all'interno di una macchina virtuale, il che poteva incidere drasticamente sul funzionamento di tutta la VM e delle sue applicazioni. Con vSphere 7, la svolta è stata quella di dedicare una sola vCpu per il Page-tracers, il che significa che la VM e le sue applicazioni possono continuare a funzionare indipendentemente dai processi di vMotion e dalla migrazione stessa che non risulta più vincolarla.
Altro importante cambiamento, riguarda il processo di copia della Ram: prima di vSphere 7, la memoria veniva trasferita tra gli host ESXi in pagine della dimensione di 4k, mentre ora, vSphere 7 utilizza pagine da 1 GB. Per assicurarsi che il tempo in cui avviene il passaggio di una VM tra gli host ESXi, rimanga entro il target di 1 secondo, vengono trasferiti lo stato della VM e solo parte del bitmap della Ram (l’unità in cui è misurata la Ram) ossia vengono trasferite solo le pagine necessarie. Considerato il fatto che poi, sono state fatte altre ottimizzazioni, con il nuovo vMotion è possibile ridurre il tempo di trasferimento da secondi a millisecondi.
Un’altra importante novità introdotta da vSphere 7, è senz’altro quella del nuovo framework Assignable Hardware, sviluppato per dare un miglior supporto e flessibilità alle infrastrutture che presentino accelleratori hardware, questi ultimi sempre più importanti e diffusi per i moderni workload: si pensi per esempio all’utilizzo delle GPU per ambienti VDI, HPC, ma anche per AI/ML.
Nelle versioni precedenti di vSphere, una macchina virtuale identificava uno specifico dispositivo PCIe passthrough utilizzando il suo indirizzo hardware, in una specifica posizione del bus sull’host ESXi in cui era installato fisicamente. Questo vincolava quella VM a quel particolare host, penalizzando di conseguenza, la sua eventuale migrazione a un altro host ESXi con un dispositivo PCIe identico. Ne viene da sé, che questa limitazione, in caso di interruzione dell'host, impattava sulla disponibilità stessa dell'applicazione che utilizzava il dispositivo PCIe associato a quella VM. Caratteristiche come vSphere DRS e HA non erano in grado di spostare automaticamente quella macchina virtuale su un altro host, ed erano necessari un provisioning e una configurazione manuale per poter spostare quella macchina virtuale su un altro host.
Con l’introduzione di Assignable Hardware, ad ogni host viene aggiunto un ulteriore livello di "capacità" che disaccoppia l'indirizzo hardware dalla VM e le consente di migrare ad altri host che hanno lo stesso tipo di hardware PCIe assegnato. vSphere 7 fornisce un meccanismo flessibile per assegnare gli acceleratori hardware ai diversi workload, identificando l'acceleratore hardware in base agli attributi del dispositivo piuttosto che al suo indirizzo hardware: questo consente un livello di astrazione del dispositivo PCIe.
Assignable Hardware, inoltre, implementa una serie di controlli per verificare che gli host ESXi abbiano effettivamente dispositivi assegnabili disponibili e compatibili alle esigenze delle VM; inoltre, è perfettamente integrato con il nuovo DRS e sfrutta vSphere HA.
Dynamic DirectPath I/O
Come elemento del nuovo framework Assignable Hardware, viene introdotto il Dynamic DirectPath I/O, che insieme al DirectPath, e ad Nvidia vGPU rappresentano le tre opzioni tra cui scegliere, in fase di configurazione di una VM a cui associare una accelleratore harwdare.
Il DirectPath I/O è la funzione legacy che associa il dispositivo PCIe nella stessa modalità di prima, senza quindi, alcuna integrazione con vSphere DRS e HA. Dynamic DirectPath I/O è la nuova soluzione che consente di assegnare l’hardware dei dispositivi passthrough in modo intelligente. L'indirizzo hardware del dispositivo PCIe non è più mappato direttamente sul file di configurazione della macchina virtuale (il file .vmx). Al contrario, gli attributi, o capacità, sono esposti alla VM.
Una volta selezionato un dispositivo specifico, l'Assignable Hardware con il nuovo DRS troverà un host adatto a soddisfare la richiesta dell'acceleratore hardware configurato. Altra opzione interessante, è l’utilizzo delle etichette, ad esempio quella indicata in figura (GPUGPU), che permettono al DRS di spostare una VM in un host non necessariamente con lo stesso hardware, ma anche con un'etichetta hardware identica. Ad esempio, si potrebbe spostare una VM associata ad un host in cui è presente una scheda GPU NVIDIA T4, su di un altro host in cui è presente una GPU RTX6000, in quanto, entrambe le schede utilizzano la stessa architettura GPU 'Turing'.
Nvidia vGPU
Si tratta di una soluzione flessibile e sviluppata in collaborazione con NVIDIA, che consente l'allocazione parziale, completa o multipla di GPU ai workload/VM.
A partire da vSphere 6.7 Update 1, la soluzione NVIDIA vGPU consente la portabilità dei workload, anche per le migrazioni live che utilizzano vMotion. Con vSphere 7 la nuova funzionalità Assignable Hardware verifica la disponibilità del profilo vGPU selezionato per la macchina virtuale, ed il posizionamento dei workload per le VM abilitate alla vGPU è stato ulteriormente migliorato.
L’aumento, soprattutto in questo periodo, di utenti che lavorano in smartworking, rende particolarmente importante la gestione IT delle identità e dati sensibili. vSphere 7 ora fornisce opzioni flessibili e a basso rischio per l'MFA (multi-factor autentication), consentendo a vCenter Servers di federarsi con ADFS. Tuttavia, il limite di un sistema di autenticazione MFA è dato dal fatto che ci sono ormai così tanti modi per implementarla, che è quasi impossibile estenderli tutti a vCenter. Per questo motivo, Vsphere 7 tramite Identity Federation utilizza standard di autenticazione e autorizzazione open come OAUTH2 e OIDC, il che apre la porta alla maggior parte di metodi di autenticazione MFA che si collegano ad ADFS.
vSphere Trust Authority (vTA)
vTA è una funzione dedicata a workload e VM che richiedono un maggior grado di sicurezza ed è stato introdotto per rendere più semplice il processo di trust nell'intero stack. vSphere Trust Authority crea una radice hardware di attendibilità utilizzando un piccolo cluster di host ESXi gestito separatamente e che assume il compito di attestazione. L'attestazione dell'host è il punto in cui il processo UEFI Secure Boot, il Trusted Platform Module (TPM) di un server e un servizio esterno lavorano insieme utilizzando la crittografia per verificare che l'host esegua software autentico e in una buona configurazione. vTA tramite l’attestazione, semplifica le connessioni degli host con i sistemi di gestione delle chiavi di crittografia (KMS) oltre che semplificare il controllo dei rischi: un host che fallisce l'attestazione, in pratica non può accedere alle chiavi e di conseguenza, l’host non può eseguire quella VM criptata.
Anche la gestione dei certificati è stata migliorata, riducendo la quantità di certificati da gestire e introducendo una nuova procedura guidata per l'importazione dei certificati. Inoltre, non è più necessario gestire i certificati degli utenti e anche ESXi è stato semplificato in modo che i suoi servizi utilizzino un certificato comune. Infine, esiste un'API REST per operazioni come il rinnovo di un certificato da parte della VMware Certificate Authority (VMCA), rendendo il processo più facile da automatizzare.
La Content Library ha fatto molta strada dalla sua nascita in vSphere 6.0. Avere una tale libreria permette di memorizzare in modo efficiente e centralizzato i template di macchine virtuali, così come gli script, i file di testo e le immagini ISO per la condivisione all'interno del datacenter. La Content Library in vSphere 7 ha funzionalità aggiuntive per supportare la gestione dei template VM (vmtx), semplificando ulteriormente la distribuzione dei contenuti di vSphere.
In vSphere 7, ora è possibile gestire i template VM in modo più efficiente e flessibile; modificarli rapidamente controllandoli, apportando le modifiche necessarie e verificandoli. Inoltre, gli amministratori possono modificare la configurazione delle impostazioni Advanced Content Library attraverso le istanze di vCenter Server direttamente dal vSphere Client.
Che cos'è il Check-In/Check-Out?
Prima di vSphere 7, quando un amministratore doveva eseguire la manutenzione di un Template VM (vmtx), il processo era piuttosto manuale e macchinoso. Un esempio di questi passaggi manuali:
Con l'introduzione delle operazioni di Check-In e Check-Out per l'aggiornamento dei template delle macchine virtuali, quando un template VM è memorizzato nella Content Library, sono disponibili le azioni di Check-In e Check-Out, così come il versioning dei template, per consentire all'amministratore di apportare rapidamente modifiche e tenere traccia delle versioni dei template VM. Non è più necessario eseguire i passi manuali citati per la modifica del template VM, in quanto il processo è stato incluso nei nuovi flussi di lavoro.
Il Checking out di un template VM consente di effettuare modifiche, e il Checking in di template crea una nuova versione del template contenente lo stato aggiornato della macchina virtuale. Qui sotto possiamo vedere un template che viene controllato per salvare le modifiche apportate.
Una volta effettuato il check-in, il template della VM ha ora un versioning (versione) per tenere traccia di eventuali modifiche. Le note, gli orari, ed i nomi degli utenti privilegiati che effettuano le modifiche sono conservati.
In vSphere 7, infine, è possibile accedere direttamente dal client di Vsphere alla modifica delle impostazioni avanzate del servizio di Content Library.
Fra le altre cose, è stata ulteriormente semplificata l'architettura di vCenter Server Appliance ed è stata deprecata la possibilità di installare il Platform Services Controllers (PSC) esterno al vCenter; inoltre non è più disponibile una versione di vCenter per Windows. Se si dispone di uno di questi tipi di distribuzione, il programma di installazione di vCenter Server 7 migrerà automaticamente l'istanza di vCenter Server in un'appliance vCenter Server con un PSC incorporato. È stato inoltre aggiunto il supporto per più NIC per l'appliance vCenter Server, nuovi strumenti CLI e un Developer Center migliorato nel vSphere Client. C'è una nuova versione hardware di VM, 17, che porta più nuove funzionalità, oltre ad un orologio di precisione per il supporto PTP (Precision Time Protocol), e un Watchdog virtuale per aiutare a monitorare le applicazioni in cluster.
Infine, con il rilascio di vSphere 7, è stata annunciata vSAN 7: l'ultima versione viene fornita con diversi miglioramenti, uno dei principali dei quali è incentrato sulla semplificazione della gestione dell'infrastruttura attraverso la riduzione degli strumenti necessari. vSAN 7 unifica block e file storage, riducendo la necessità di soluzioni di terze parti. E ora vSAN supporta i container attraverso VMware Cloud Foundation.
Curiosita? Vpshere 7 è stato provato su Hardware ARM, ed anche se pubblicamente non è disponibile, non è escluso lo sia in futuro.
Ultimo, ma non per questo meno importante, un accenno alla versione di vSphere 7 con supporto Kubernetes, che come argomento merita di essere trattato separatamente ed in modo più dettagliato.
La novità più importante è che Kubernetes ora è a tutti gli effetti integrato in vSphere, il che consente agli sviluppatori di continuare a utilizzare gli stessi strumenti e le stesse interfacce standard che hanno utilizzato per creare app moderne. Gli amministratori di vSphere ne beneficiano anche perché possono aiutare a gestire l'infrastruttura di Kubernetes utilizzando gli stessi strumenti e le stesse competenze che hanno sviluppato intorno a vSphere. Per aiutare a collegare questi due mondi è stato introdotto un nuovo oggetto di vSphere chiamato Namespaces, che permette agli amministratori di vSphere di creare un insieme logico di risorse, permessi e policies che permettono un approccio incentrato sull'applicazione.
Come detto all’inizio del documento, Vsphere7 with Kubernetes è acquistabile tramite Vwmare Cloud Foundation, e questo perché Kubernetes richiede un layer di rete molto flessibile e dinamico per poter collegare sia i container (all'interno dei pod) che le VM tradizionali. Per rispondere al meglio a questa esigenza, Vmware ha deciso di utilizzare NSX; ne viene da se che essendo necessari diversi componenti (ESXi,vCenter, NSX), serva anche un’orchestrazione per coordinarne il ciclo vita e la gestione. Tradotto, vSphere+NSX +SDDC Manager + (opzionale vSAN)= Vmware Cloud Foundation (VCF), che è stato aggiornato, ora alla release 4, per essere integrato alla perfezione con Kubernetes.
A questo link è possibile trovare maggiori e più dettagliate informazioni (in lingua inglese).
Sostanzialmente non è variato molto rispetto al passato; troviamo le versioni di licenza per processore (fino a 32 core per ogni licenza), vSphere Standard e vSphere Entreprise Plus, come i kit vSphere Essentials, ed vSphere Essentials plus che licenziano fino a 6 processori, oltre che un’istanza di vCenter Server Essentials, oltre alle licenze Robo, VMware vSphere Remote Office Branch Office ideali per sedi remote, e fino a 25 VM. Esiste poi la licenza VMware vSphere Scale-Out dedicata ad ambienti HPC e Big Data, oltre che la licenza Vsphere Desktop esclusiva per ambienti VDI, e la nuova VMware vSphere Add-on for Kubernetes che fa parte Vmware Cloud Foundation
A questa pagina potete trovare il nuovo whitepaper ufficiale di Vmware relativo al lincensing.
