<< Torna agli Approfondimenti Tematici


Rodolfo Trippetti
Le principali novità di VMware vSphere 6.5


Istruttore certificato con una lunga esperienza nella formazione ICT. VMware Certified Instructor (VCI), VMware Certified Professional (VCP), Cisco Certified Systems Instructor (CCSI), Cisco Certified Network Professional R&S (CCNP), Microsoft Certified Trainer (MCT), Microsoft Certified Systems Engineer (MCSE)


1. Introduzione

A metà novembre scorso è uscita la release definitiva della versione 6.5 di VMware vSphere, la piattaforma di virtualizzazione più diffusa al mondo. La pubblicazione delle release notes risale esattamente al 15 novembre 2016. Il periodo che va da metà gennaio agli inizi di febbraio è anche quello di pubblicazione delle versioni finali dei tre corsi principali del curriculum ufficiale VMware rivolti a vSphere 6.5.

Il corso !, della durate di 3 giorni, descrive in dettaglio tutte le novità della nuova versione mettendole in un contesto più ampio di aggiornamento dalla versione 5.5. Il corso !VMware vSphere 6.7: Install, Configure, Manage (VICM), della durata di 5 giorni, è invece la formazione "classica" di carattere generale, che non ha lo scopo di concentrarsi sulle novità bensì quello di passare in rassegna tutti i componenti e le più importanti funzionalità (vecchie e nuove) dell'infrastruttura; è certamente il corso di maggior valore didattico. Infine il corso !VMware vSphere 6.7: Optimize and Scale (VOS), anch'esso della durata di 5 giorni, prosegue il discorso formativo iniziato dal VICM estendendo e approfondendo la descrizione dell'infrastruttura nella direzione degli strumenti che ne permettono l'ottimizzazione e la scalabilità. Questi ultimi due corsi in particolare sono quelli indicati per acquisire le conoscenze necessarie al superamento dei due esami obbligatori con cui si ottiene la certificazione !VCP6-DCV.

In questo articolo presento brevemente quelle che a mio giudizio appaiono come le novità più interessanti del prodotto.


2. Panoramica

Solitamente quando esce una nuova release di un prodotto così complesso e presente ormai da tempo sul mercato, le novità si presentano in genere come una costellazione di modifiche, estensioni e miglioramenti di gran parte delle principali caratteristiche già note a chi segue da tempo le tecnologie di virtualizzazione. Quelle forse più scontate, anche se non certo secondarie, sono quelle che estendono in varia misura le capacità di supporto di ESXi, chiave di volta dell'infrastruttura. Mi riferisco all'aumento del supporto hardware per l'host (ad esempio raddoppia la RAM per host, che passa da 6 TB a 12 TB), all'aumento dei sistemi operativi guest virtualizzabili, all'introduzione di una nuova versione del virtual hardware con la quale è possibile fornire alle macchine virtuali un hardware virtualizzato sempre più potente e performante (ad esempio è possibile fornire alla singola macchina virtuale fino a 6 TB di RAM), all'estensione delle capacità di interfacciamento con lo storage (raddoppiano i paths totali supportati dal singolo host, da 1024 a 2048), e di quelle con la rete (raddoppia il numero di host per distributed switch, da 1000 a 2000).

A parte però tutti questi "numeri" che potenziano ulteriormente le già notevoli capacità della piattaforma, sono interessanti a mio avviso le novità nelle seguenti aree: Clients, vCenter, Security, Availability. Facciamone una breve rassegna.


3. I clients di amministrazione

Fino alla versione 4.x l'unico client grafico disponibile per l'amministrazione era il vSphere Client, un tool sviluppato solo per piattaforma Windows. Questo obbligava ovviamente l'amministratore a lavorare con uno dei sistemi operativi Windows che ne supportavano l'installazione. Dalla versione 5.0 VMware introduce un client web, ovvero la possibilità di utilizzare un browser per amministrare il sistema. Il vSphere Web Client inizialmente giocava un ruolo del tutto secondario in quanto poteva eseguire solo un sottoinsieme di attività amministrative tra tutte quelle possibili; l'uscita della versione 5.1 ha però ribaltato la situazione. Da quel momento in poi infatti VMware ha eletto a client principale il vSphere Web Client e relegato in seconda posizione il vSphere Client tradizionale. Il fatto non era solo formale ma aveva una conseguenza importante: il vSphere Client da quel momento in poi non avrebbe supportato tutte le novità introdotte dalle versioni successive, 5.1 compresa. Quindi all'uscita del vSphere 6.0 il vSphere Client di Windows, sebbene ancora utilizzato da molti amministratori, era rimasto indietro di tre release nella sua capacità di amministrare l'infrastruttura vSphere. La versione 6.5 ha decretato la morte naturale di questo client.

Il vSphere Web Client ha avuto però sempre due punti deboli per chi faceva amministrazione. Il primo è legato alla tecnologia utilizzata (Adobe Flex + Java Server) che rende il tool poco performante e un po' farraginoso da utilizzare (è il motivo per cui tanti amministratori di rete si ostinano ad utilizzare il vSphere Client di Windows, nonostante le sue lacune). Il secondo riguarda l'impossibilità di accedere con il vSphere Web Client all'amministrazione diretta dell'host, una cosa che dovrebbe essere per lo più evitata (e infatti come sappiamo si può inibire attraverso l'impostazione della funzionalità di Lockdown Mode) ma che può in certi casi tornare utile.

Gli sviluppi successivi hanno sopperito ad entrambi i problemi e ad oggi, con la versione 6.5, è finalmente disponibile nativamente sia l'amministrazione web dell'host stand-alone (VMware Host Client), in realtà già introdotta ufficialmente con la 6.0 U1 sia l'amministrazione attraverso un nuovo client web, fornito in parallelo al primo, sviluppato con tecnologia più avanzata (HTML5 + Java Server) e chiamato semplicemente vSphere Client, in sostituzione al client originale per Windows, ormai abbandonato. Nella sua attuale fase di sviluppo questo client non supporta ancora tutte le funzionalità necessarie e il client di riferimento rimane il vSphere Web Client.

I tre clients oggi disponibili in vSphere 6.5 sono raggiungibili ai seguenti indirizzi:
vSphere Web Client - https://<vCenter Server FQDN or IP Address>/vsphere-client
vSphere Client - https://<vCenter Server FQDN or IP Address>/ui
VMware Host Client - https://<ESXi Host FQDN or IP Address>/ui


4. vCenter Server

Anche nel caso del vCenter la versione 5.0 è stata uno spartiacque. Prima di questa versione il vCenter era disponibile solo come componente da installare su un server Windows, con questa versione VMware ha introdotto un vCenter come Virtual Appliance, cioè come macchina virtuale preconfigurata scaricabile dal sito e immediatamente distribuibile e utilizzabile nel datacenter. E' evidente che questa soluzione mostra dei chiari vantaggi, non solo dal punto di vista dell'amministratore del datacenter ma anche dal punto di vista di VMware. L'amministratore ha uno strumento più veloce e facile da gestire (sia in fase di deployment sia in fase di manutenzione), più compatto, senza licenze aggiuntive (quella di Windows) e senza problematiche legate alla gestione di un sistema operativo indipendente che ospita il servizio vCenter. VMware ha un oggetto che può essere meglio controllato in fase di sviluppo, customizzato e ottimizzato in tutti i suoi aspetti, anche quelli di sistema operativo, dunque un modo certamente più efficiente per mettere a disposizione uno strumento così importante per la sua infrastruttura.

Quindi, da quando VMware l'ha rilasciata la prima volta, la VCSA (vCenter Server Appliance) è diventata la soluzione principale e conseguentemente ha subìto lo sviluppo maggiore che, specialmente con la versione 6.5, l'ha portata a superare nettamente l'implementazione sotto Windows, soprattutto come caratteristiche supportate. Ecco le ultime introdotte.


Installer
Prima di tutto nella nuova piattaforma è presente un nuovo installer con una grafica rinnovata che mette a disposizione quattro funzionalità: l'installazione ex-novo del vCenter, il suo aggiornamento da una versione precedente (vCenter 5.5/6.0), la migrazione da un vCenter Windows al vCenter Virtual Appliance 6.5, il restore del vCenter da un set di backup.


Migration
La migrazione era già stata introdotta nell'aggiornamento vSphere 6.0 Update 2m (settembre 2016) ma quella disponibile in 6.5 elimina qualche limitazione ed è integrata con il nuovo tool di installazione. I percorsi di migrazione supportati sono quelli che vanno dalle versioni 5.5 e 6.0 di Windows alla versione 6.5 dell'appliance, non è supportata la migrazione orizzontale da 6.5 Windows a 6.5 Appliance. E' supportata anche la migrazione di un vCenter distribuito, in tal caso è necessario però migrare prima il PSC/SSO e dopo il vCenter. Ovviamente se l'installazione di partenza presenta più PSC/SSO prima vanno migrati questi e solo dopo le istanze del vCenter. I dati vengono migrati da qualunque database supportato nelle versioni 5.5 e 6.0 di Windows (MS-SQL, Oracle, PostgreSQL) verso il database embedded dell'appliance (vPostgres).


Backup/Restore
La procedura di backup nativa introdotta consente di eseguire un backup del vCenter Virtual Appliance in qualsiasi momento utilizzando la VMware vSphere Appliance Management Interface sulla porta 5480. Il backup è file-based, archiviato in uno storage a scelta. Si può scegliere di cosa fare il backup (Core configuration, Inventory, Historical Data) e con quale protocollo (FTP, FTPS, HTTP, HTTPS, SCP). Il restore viene fatto a partire dal nuovo tool di installazione scegliendo la voce Restore che installa una nuova Appliance ripristinando i file di backup quando chiesti.


Management
Al momento della sua prima introduzione (in vSphere 5.0) la VCSA aveva una sua interfaccia Web di gestione, raggiungibile sulla porta 5480. Questo collegamento veniva utilizzato subito dopo il deployment dell'appliance (fatto con il vSphere Client) per la sua prima configurazione, ed eventualmente anche successivamente per modifiche sulla stessa. Il collegamento in console invece offriva solamente una schermata in modalità testo che dava alcune informazioni tra le quali proprio l'indirizzo da contattare in HTTPS per la gestione dell'appliance. Ovviamente c'era anche la possibilità di accedere sia in shell che in SSH.

Gli aggiornamenti successivi hanno modificato questo approccio nel modo seguente: è stata introdotta la possibilità di fare il deployment dell'appliance direttamente da interfaccia Web (estromettendo l'uso del vSphere Client) con un wizard dal quale impostare tutti i settaggi iniziali di funzionamento, senza la necessità di accedere alla prima configurazione successivamente al deployment; è stata introdotta una DCUI (Direct Console User Interface) per l'appliance, organizzata allo stesso modo della tradizionale DCUI dell'host ESXi; alcune funzioni di configurazione dell'appliance sono state esposte sul nuovo vSphere Web Client.

Con quest'ultima versione è ricomparsa una Management Interface raggiungibile sulla porta 5480 che ovviamente rispetto alla precedente risulta essere molto migliorata, sia per l'interfaccia che offre sia per le nuove informazioni e funzionalità esposte. Tra le altre è in grado di mostrare informazioni sullo stato di funzionamento del database vPostgres, in particolare l'andamento nel tempo dell'utilizzo dello spazio su disco.


Integrazione di Update Manager
Il servizio di aggiornamento centralizzato dei componenti di sistema (hosts, vmtools, virtual hardware, appliances) è sempre stato incluso nella licenza di vSphere ma messo a disposizione come servizio separato da installare necessariamente in un server Windows, e collegato ad un database MS-SQL. Ovviamente questo servizio era in grado di dialogare tanto con il vCenter Windows quanto con la VCSA ma nel caso di quest'ultima non poteva essere integrato nella stessa macchina.

Nella nuova versione questo vincolo è stato tolto e il servizio è stato finalmente integrato con il vCenter Virtual Appliance eliminando così l'obbligo di risorse Microsoft, sia il sistema operativo Windows che il database MS-SQL, per farlo funzionare. La nuova versione integrata utilizza il vPostgres messo a disposizione di default dall'appliance. Con questa versione è stata raggiunta anche una completa integrazione degli strumenti amministrativi di aggiornamento con il vSphere Web Client. Tuttavia è ancora disponibile la versione tradizionale dell'Update Manager per quelle realtà che ancora lavorano con vCenter Windows.


vCenter HA
Inizialmente il vCenter poteva essere protetto dal failure dell'host su cui girava (se era una macchina virtuale), o dal failure del sistema operativo o di suoi componenti critici, attraverso una configurazione ridondata a due nodi di tipo Active/Passive garantita da un componente specifico fornito in licenza separata chiamato vCenter Server Heartbeat. Successivamente questo prodotto è stato dismesso da VMware e non sostituito. La best practice ufficiale per proteggere il vCenter era (e rimane tuttora valida) quella di fare il deployment del vCenter come macchina virtuale in un cluster vSphere HA. Questa configurazione garantisce un buon livello di disponibilità (anche se non una completa continuità di servizio, peraltro quasi mai necessaria) proteggendo la VCSA dal failure del nodo del cluster su cui si trova a girare.

Nella nuova versione, e limitatamente alla VCSA, torna la possibilità di proteggere il vCenter con un cluster applicativo dedicato, fornito però questa volta come una funzionalità opzionale ma nativa del prodotto, chiamata vCenter HA. Questo conferisce un livello di resilienza rispetto a failures del vCenter stesso o di suoi importanti componenti e rende il meccanismo indipendente dalla presenza o meno di un cluster di hosts vSphere HA. L'introduzione di questo strumento specifico di resilienza è probabilmente giustificato dal fatto che sempre più componenti del datacenter virtuale hanno una dipendenza più o meno critica dal vCenter Server.

L'architettura generale consiste in tre nodi: Active, Passive e Witness. Solo il primo nodo è operativo, gli altri due nodi vengono costruiti clonando il primo. Questa configurazione può essere fatta in qualunque momento a partire dall'istanza del vCenter operativa ed eventualmente anche cancellata in qualunque momento, ritornando all'istanza originaria non protetta. Il vCenter HA protegge sia la configurazione che il database, non richiede terze parti, non richiede storage condivisi, viene costruito attraverso il Web Client, e i nodi possono essere anche distanti geograficamente (purchè ben collegati). Il failover ha un RTO (Recovery Time Objective) di circa 5 minuti.


5. Security

Le nuove funzioni di sicurezza introdotte riguardano sia gli host ESXi che le macchine virtuali. Per l'host è stato introdotto un processo di boot sicuro mentre per le macchine virtuali è disponibile un meccanismo di cifratura sia per le informazioni in archivio sia per quelle che viaggiano durante una operazione di vMotion.


Secure Boot
La stabilità di un sistema operativo è chiaramente legata alla possibilità di tenere sotto stretto controllo tutti i suoi componenti e poter discriminare tra un componente affidabile e uno non affidabile. Generalmente un metodo può essere quello di sottoporre i vari componenti a opportuni controlli di firma durante la loro installazione e durante il boot del sistema. Questo può essere possibile grazie al firmware UEFI (Unified Extensible Firmware Interface) e al suo store di certificati. VMware ESXi è in grado di utilizzare queste funzionalità evolute di UEFI e assicurare un controllo di firma al boot su tutti i suoi componenti (VIB), consentendo di prevenire qualsiasi modifica non autorizzata del sistema operativo installato e dell'ambiente di boot. Più esattamente UEFI valida il bootloader e il kernel, quest'ultimo valida a sua volta tutti i VIB caricati al boot.


VM Encryption
Fino a quest'ultima versione di vSphere VMware non aveva introdotto funzioni di cifratura per le macchine virtuali, sebbene queste tecnologie già da qualche tempo venissero offerte da soluzioni concorrenti, quali Hyper-V di Microsoft che utilizza la sua tecnologia BitLocker. Con vSphere 6.5 compare un meccanismo di cifratura relativamente semplice da utilizzare che interessa tutto il materiale della macchina virtuale nello storage, dischi e metadati, file di swap compreso. Si tratta di una cifratura gestita dall'hypervisor e quindi totalmente indipendente tanto dal tipo di storage in cui risiede quanto dal tipo di sistema operativo guest installato. Per la gestione delle chiavi di cifratura viene utilizzato lo standard KMIP (Key Management Interoperability Protocol) che consente di separare bene le responsabilità amministrative della gestione delle chiavi (tramite il KMS, Key Management Server) da quelle del loro semplice utilizzo nell'ambiente (tramite il vCenter). Le funzioni di cifratura vengono gestite con le storage policies associate alle singole VM. Per semplificare la distinzione delle responsabilità amministrative in tema di sicurezza il vCenter 6.5 introduce, a fianco all'account Administrator che detiene tutti i privilegi compreso quello delle operazioni crittografiche, un ruolo chiamato No Cryptographic Administrator che ha tutti i privilegi amministrativi tranne quello delle operazioni crittografiche.


vMotion Encryption
In generale sarà necessario non solo proteggere la macchina virtuale quando è archiviata nello storage ma anche nel momento in cui viene spostata a caldo da un host all'altro attraverso la rete di vMotion, altrimenti l'operazione potrebbe rappresentare una vulnerabilità. Dunque è possibile gestire uno specifico settaggio nell'editor della singola macchina virtuale che abilita l'uso della cifratura durante l'operazione di vMotion. In tal caso il traffico verrà cifrato utilizzando una chiave one-time generata dal vCenter e distribuita ai due host attraverso il canale di management già normalmente cifrato con SSL.


6. Availability

Le due tradizionali tecnologie abilitabili in un cluster di host, vSphere HA (High Availability) e vSphere DRS (Distributed Resource Scheduler), hanno raggiunto un certo grado di maturazione e garantiscono un ambiente resiliente e sempre ben bilanciato nelle risorse di calcolo. Tuttavia in questa nuova versione entrambi i servizi trovano un certo margine di migliormento, sia di architettura che di funzionalità.


Proactive HA
E' una funzionalità che si configura sul vSphere HA ma in realtà viene fornita dal DRS. Quest'ultimo può ricevere dall'hardware degli indicatori di possibile malfunzionamento dell'host che alzano il fattore di rischio di failure dell'host nel futuro. Il DRS prepara il cluster a questo evento (che ovviamente verrà gestito dal vSphere HA) tenendo scarico l'host incriminato (al limite svuotandolo).

Questa nuova funzionalità necessita di un software (integrato nella piattaforma hardware e fornito quindi dal produttore) in grado di monitorare le funzionalità dell'host e comunicarle al DRS (attraverso dei specifici plug-in).

vSphere 6.5 dispone di un'interfaccia (new API set) con cui i produttori di terze parti possono fornire al vCenter informazioni sullo stato di salute del server. I dati di host health information vengono utilizzati dal DRS per minimizzare l'impatto di un possibile failure futuro dell'host degradato. I valori dello stato di salute dell'host sono quattro: healthy (green), moderately degraded (yellow), severely degraded (red), unknown (gray). Il DRS può rispondere agli stati di degrado dell'host mettendolo nello stato appropriato: Maintenance Mode, Quarantine Mode.

La funzionalità di Proactive HA deve essere supportata dal produttore dell'hardware (da controllare sulla lista di compatibilità). Inoltre la configurazione comporta non solo il settaggio opportuno sul cluster HA (vSphere Web Client) ma anche sul software di management del produttore.


Orchestrated Restart
La priorità di restart (High, Medium, Low) assegnabile nelle vecchie versioni viene utilizzata dal cluster solo per garantire le risorse alle macchine con priorità più alta senza tener conto della "readiness" della VM. Questo significa che l'assegnazione delle risorse avviene correttamente seguendo le priorità ma lo startup potrebbe seguire un ordine differente in conseguenza delle diverse velocità di boot delle VMs (non c'è una vera dipendenza nello start delle varie VM).

La funzione Orchestraded restart introduce il concetto di dipendenza tra le VMs. L'amministratore può scegliere un metodo (tra quattro disponibili) per stabilire la readiness di una VM (se è "pronta" o meno); il metodo più significativo è quello che controlla se i VMware Tools sono stati avviati. E' possibile agganciare al metodo scelto un delay di tempo personalizzato. Si possono stabilire vari "Tiers" in cui collocare le varie VMs. Solo quando tutte le VMs del primo Tier hanno raggiunto la condizione stabilita di readiness il sistema passa a far partire le VMs del secondo Tier, e così via.


Admission Control Improvements
Nelle versioni precedenti il meccanismo di calcolo di risorse spare utilizzato nell'admission control aveva come unico obiettivo quello di assicurarsi la ripartenza di qualsiasi macchina in un evento di failure. Per questo venivano considerate solo le risorse riservate e sulla base di queste veniva calcolato uno slot size che rappresentava la quantità di risorsa garantita alla singola VM in qualunque situazione. In uno scenario del genere però non viene assicurato nulla di più dello slot size e le VM in un evento di failure potrebbero trovarsi in una situazione di contesa tale da non riuscire più ad avere le risorse sufficienti a garantire delle performance accettabili. In poche parole vengono garantite le risorse riservate e non quelle runtime (le performance possono dipendere in maniera cruciale da queste ultime).

Nel nuovo modo di gestire l'admission control il meccanismo è il seguente: se specifico il failure di un host da tollerare il cluster sceglie l'host con la risorsa maggiore, la esprime in percentuale rispetto alla risorsa totale disponibile sul cluster e questa sarà la "reserved for failover" (ad esempio 40%). La percentuale complementare a questa (nell'esempio il 60%) sarà invece la "available capacity". Se la risorsa runtime utilizzata dalle VMs supera quest'ultimo valore il cluster manda un warning. Eventualmente questa soglia di warning si può personalizzare definendo una "percentuale di degrado della performance tollerabile" (abbassando una percentuale posta di default al 100%) che sposta il warning più in alto.


Predictive DRS
E' una funzionalità che lavora in interazione con il vRealize Operations Manager. Il vROPs fa delle previsioni sull'impiego delle risorse delle VMs nel cluster e manda le metriche al DRS che le usa per "prevenire" gli spike di carico, o quantomeno mitigarli, prima che si verifichino. Questa funzionalità sarà pienamente funzionante solo con la prossima release del vROPs, presumibilmente entro la fine del primo semestre 2017.

Poichè il DRS può sfruttare le metriche predette dal vROPs la sua reazione al momento di carico del sistema è più pronta e questo mitiga (o addirittura annulla) la potenziale fase di contesa delle VM.


vSphere DRS Load Balancing
Il metodo di bilanciamento del vSphere DRS è basato sul calcolo della deviazione standard, una misura dello scarto complessivo del carico del cluster dal suo valor medio. Il servizio DRS monitora il carico corrente nel cluster, valuta la deviazione standard e cerca di minimizzarla tramite opportune migrazioni delle singole VMs da un nodo all’altro. Se il nuovo livello ottenuto della deviazione standard risulta essere al di sotto di un certo valore di soglia il cluster viene considerato bilanciato. Purtroppo se il cluster è molto grande (numero di nodi elevato) è probabile avere un cluster complessivamente bilanciato ma con valori di carico su qualche singolo nodo molto lontani dal valor medio, valori anomali ma che, data la grandezza del cluster, costituiscono fluttuazioni non significative. Ciononstante tali valori anomali possono tradursi in valori di lavoro critici per il nodo interessato. Allo scopo di individuare tali valori anomali e mitigare questo effetto il DRS introduce nell’algoritmo di bilanciamento la differenza tra i due nodi con i valori di carico più lontani dalla media (il nodo più utilizzato e il meno utilizzato) associando a questo calcolo la possibilità di eseguire ulteriori migrazioni. Il risultato è il miglioramento del bilanciamento complessivo.


VM Distribution, Memory Metrics for Load Balancing, CPU Overcommitment
Nel DRS sono state introdotte delle Addictional Options, esposte come checkbox selezionabili nell’interfaccia grafica del vSphere Web Client, che consentono di attivare facilmente tre funzioni avanzate del servizio.

La VM Distribution è una funzionalità che fa in modo che ciascun nodo del cluster abbia sempre un numero di VMs vicino al valor medio. Il DRS cerca di mantere tutti gli host con un numero di VMs al di sotto di un certo valore massimo (maxVMs) calcolato sul valor medio delle VMs. L'obiettivo è quello di evitare che in un qualche momento, per ragioni di puro bilanciamento di carico, ci sia un host con un numero troppo alto di VMs, un aspetto negativo nel caso che quell'host abbia un failure.

La Memory Metric for Load Balancing assicura che il bilanciamento del DRS sulla memoria verrà fatto sulla base della Active Memory anzichè della Consumed Memory.

Il CPU Overcommitment consente di tenere sotto controllo l'overcommitment della CPU impostando un valore di soglia. L'overcommitment viene misurato come rapporto vCPU/pCPU espresso in percentuale e tale valore può andare da 0% a 500%. Si tratta di un valore complessivo per il cluster, non è un valore per il singolo host. Questo significa che l'overcommitment dell'intero cluster può essere sotto il valore impostato ma essere al di sopra di questo valore su uno o più nodi del cluster.


Network-Aware DRS
L’obiettivo principale del DRS rimane quello di bilanciare il cluster nell’uso delle risorse di calcolo, cioè la CPU e la memoria. Nel far questo però è in grado di tenere in conto anche l’utilizzo di altre risorse e, se può, tenta di bilanciare anche quelle. In quest’ultima versione vengono valutate anche le risorse di rete. Monitorando il consumo di banda degli uplink, sia in ricezione che in trasmissione, il DRS cerca di evitare di posizionare le macchine virtuali su degli host che stanno saturando la rete (cioè che superano in utilizzo l’80% della banda disponibile). Ovviamente l’utilizzo delle risorse di rete è solo un input addizionale nel determinare il miglior posizionamento delle VMs, l’input principale rimane sempre quello relativo alle risorse di calcolo.


7. Conclusioni

Le novità introdotte dalla nuova versione di vSphere non si esauriscono qui. In particolare sarebbero da citare cose interessanti sia in area Storage che in area Networking. In area Storage ad esempio l’introduzione di una nuova versione di file system, il VMFS6, con una serie di ottimizzazioni rispetto alla versione precedente. In area Networking l’introduzione della funzionalità detta Gateway per vmknic, che consente di assegnare un gateway separato per ciascuna VMkernel Network Adapter senza duplicare istanze complete Netstack (cioè senza la necessità di creare stack tcp/ip completi) che elimina l’esigenza di aggiungere rotte statiche per i servizi basati sulle VMkernel ottenendo al contempo la minimizzazione delle risorse utilizzate e dell’overhead richiesto all’host.

Con questa nuova versione di vSphere VMware migliora ulteriormente il componente chiave del suo modello SDDC (Software-Defined Data Center) e della sua strategia di Cloud Computing.


Formazione Consigliata

Di seguito i corsi di formazione ufficiali suggeriti per approfondire queste tematiche:

  • !
  • !VMware vSphere 6.7: Install, Configure, Manage (VICM)
  • !VMware vSphere 6.7: Optimize and Scale (VOS)

I corsi sopraelencati sono propedeutici al conseguimento della certificazione:
!vcp6-dcv

Contattaci

Contattaci per qualsiasi ulteriore informazione, saremo lieti di rispondere alle tue domande e di supportarti nella definizione dei tuoi piani formativi! Puoi raggiungerci telefonicamente al numero +39 02 255081 oppure compilando il modulo di contatto.