Cerca nel blog

domenica 31 luglio 2011

vSphere 5: miglioramenti sullo storage

Supporto di Storage I/O Control per la NFS

vSphere 5 estende il supporto per la funzionalità di Storage I/O Control anche sulle NFS e più in generale sulle Network-Attached Storage (NAS). I benefici più significativi sono:

  • regola dinamicamente l’accesso contemporaneo di più VM allo storage condiviso in base alle share sul disco assegnate a livello di VM;
  • aiuta ad individuare le applicazioni sensibili alla latenza che utilizzano molti I/O di piccole dimensioni (minori di 8KB). Questo consente di aumentare le prestazioni fino al 20%;
  • distribuisce le risorse non utilizzate alle VM che ne hanno bisogno in base alle share del disco delle VM. Questo permette un’allocazione più corretta delle risorse dello storage, senza sprechi;
  • limita le fluttuazioni nelle performance delle VM con workload critici durante i momenti di estremo carico e di congestione sull’ I/O. Il beneficio nelle prestazioni è stato calcolato all’11% rispetto ad uno scenario che non adotta SIOC.

Storage I/O Control fornisce un meccanismo di controllo dinamico per la gestione dell’accesso alle risorse I/O (FC, iSCSI, NFS) da parte delle VM in un cluster. I benefici di SIOC, prima previsti solo per FC e iSCSI sono ora applicati anche a NFS. I test condotti hanno dimostrato che con un adeguato bilanciamento dei carichi SIOC è in grado di migliorare le performance per le applicazioni critiche fino al 10% con un miglioramento sulla latenza delle operazioni di I/O fino al 33%.

Per maggiori informazioni consultare il technical white paper "What’s New in Performance in VMware vSphere™ 5.0"

vSphere 5: miglioramenti lato CPU

32-vCPU: performance e scalabilità

VMware vSphere 5.0 permette la creazione di VM con 32 vCPU. L’utilizzo di un grande numero di vCPU in una VM può potenzialmente aiutare alcune applicazioni Tier 1 e Mission Critical ad avere migliori prestazioni e throughput e/o una migliore risposta durante l’esecuzione. VMware ha condotto, nei suoi laboratori, diversi test includendo applicazioni commerciali T1 e HPC. Le performance osservate erano simili a quelle native (92-97%) man mano che le applicazioni virtualizzate scalavano a 32 vCPU.

Miglioramenti relativi allo schedulatore per l’architettura Intel Simultaneous MultiThreading (SMT)

L’architettura SMT espone 2 HEC (Hardware Execution Contexts) per ogni singolo core. Il beneficio nell’utilizzare 2 HEC comporta un miglioramento di performance dal 10% al 30% in funzione del tipo di workload. In vSphere 5.0, la policy dello schedulatore della CPU è stata ottimizzata per questo tipo di architettura ed è in grado di bilanciare il massimo throughput e “l’imparzialità” (fairness) tra VM. Oltre alle migliorie già presenti in vSphere 4.1, VMware ha ulteriormente potenziato lo schedulatore SMT per assicurare la miglior efficienza e performance per le applicazioni mission critical.

Virtual NUMA (vNUMA)

Virtual NUMA (vNUMA) permette di esporre alla VM la topologia NUMA dell’HOST; i sistemi operativi guest in grado di gestire NUMA e le applicazioni potranno utilizzare nel modo più efficiente l’architettura del server fisico. vNUMA richiede il virtual HW 8, che offre considerevoli benefici in termini di performance per i sistemi operativi e le applicazioni studiate per l’ottimizzazione NUMA

Per maggiori informazioni consultare il technical white paper "What’s New in Performance in VMware vSphere™ 5.0"

vSphere 5: miglioramenti sulla scalabilità di VMware vCenter Server

VMware vSphere 5 migliora ulteriormente le performance e la scalabilità rispetto alla versione precedente.

In merito a vCenter gli sviluppi riguardano:

  • Numero di VM per Cluster
  • HA (High Availability)

Virtual Machines per Cluster

Nonostante le nuove dimensioni delle VM (32 vCPU e 1 TB di VRAM) ed il maggior numero di VM per cluster, vSphere 5 permette di gestire un numero maggiore di operazioni (fino al 120% in più) come: accensioni e spegnimenti di VM, migrazioni, registrazione e de-registrazione di macchine dall’inventario, creazioni di cartelle. Il miglioramento sulla latenza delle operazioni è valutabile in un range dal 25% al 75% in base al tipo di operazione ed al carico di lavoro esistente.

HA (High Availability)

Molte sono le migliorie in vSphere 5.0 per ridurre i tempi di configurazione e incrementare le performance del failover. Il cluster HA supporta fino a 32 host con 3200 VM e la sua configurazione è 9 volte più rapida. Nella stessa quantità di tempo, rispetto alla versione precedente, vSphere 5.0 può gestire il 60% in più di failover di VM. Il tempo minimo per la ripartenza, dal guasto del server alla partenza della prima VM, è stato migliorato del 44,4%. Il tempo medio di failover per la VM è stato migliorato del 14%.

Per quanto riguarda il CPU slot size, ovvero la dimensione della CPU da “risparmiare” per ogni VM protetta da HA, è più piccola rispetto a quella richiesta da vSphere 4.1; questo permette un maggior tasso di consolidamento. Distributed Power Management (DPM), inoltre, potrebbe essere in grado di mettere in standby mode più host nel cluster quando l’utilizzo è basso, aumentando il risparmio energetico.

Per maggiori informazioni consultare il technical white paper "What’s New in Performance in VMware vSphere™ 5.0"

SIOC: Storage I/O Control

Storage I/O Control (SIOC), è una nuova funzionalità disponibile in vSphere4.1 che permette un controllo più granulare dell’accesso delle VM sullo storage.

Spesso i problemi legati alle performance sullo storage dipendono da una eccessiva latenza del device. Quando la latenza misurata sul device supera i 20ms, è possibile che le applicazioni comincino a soffrire ed è necessario risolvere il problema.

Prima di vSphere 4.1 il peso relativo della VM, lato storage, veniva calcolato a livello del singolo host ESX, questo non rappresenta una situazione ottimale in quanto lo storage viene utilizzato da più VM distribuite su più host. Un caso limite è rappresentato da un cluster composto da più host e molte VM nel quale abbiamo un host che ospita una singola VM, questo significa che la VM ottiene l’accesso completo al device, mentre altre VM potrebbero competere a causa delle loro collocazione sui server ESX.

Lo scopo di SIOC è quello di identificare la latenza a livello di volumi VMFS per cercare di evitare che le VM con alta priorità, distribuite su host differenti, vadano in sofferenza durante un picco di lavoro sullo storage.

L’abilitazione della feature avviene chiedendo le proprietà del datastore e premendo l’apposita check box.

Abilitazione SIOC
Abilitazione SIOC

Una volta applicata la funzionalità è possibile osservarne lo stato dal nel riquadro di dettaglio della datastore selezionato.

Dettagli Datastore con SIOC abilitato
Dettagli Datastore con SIOC abilitato

L’immagine sottostante mostra graficamente i vantaggi del SIOC.

Prima e dopo abilitazione SIOC
Prima e dopo abilitazione SIOC

Per comprendere questa funzione è necessario spiegare alcuni termini

  • Disk shares: rappresentano l’importanza relativa della VM rispetto alla distribuzione risorse dello storage. Questo significa che in fase di contesa la VM con più share otterrà un maggiore accesso allo storage e di conseguieunza avrà un throughput più alto e una minore latenza;
    Host aggregate shares: somma delle share sul disco di tutte le VM che condividono il datastore;
    Datastore-wide normalized I/O latency: media ponderata e normalizzata della latenza vista dagli host che raggiungono il datastore. Per fare il calcolo viene usato il numero delle richieste di I/O completate per secondo da ogni host. Dato che la richiesta di I/O può avere diverse dimensioni, deve essere normalizzata, in questo caso una elevata latenza per una grande I/O viene distinta da un’alta latenza causata dalla congestione del device;
    Congestion threshold: rappresenta la soglia normalizzata della latenza per l’intero datastore alla quale SIOC fa riferimento per assegnare la priorità alle richieste di I/O delle VM in base alle share stabilite.

Per maggiori informazioni è possibile consultare le seguenti guide:


martedì 26 luglio 2011

VMware vSphere 5: ma quanto mi costi ????

L'impatto del nuovo listino basato sulla vRAM per i clienti VMware vSphere

VMware ha annunciato il nuovo modello di licenze che sarà essenzialmente in base alla quantità di RAM virtuale assegnata a tutte le macchine virtuali in un cluster vCenter.

Sostanzialemente il modello di vendita delle licenze
si è spostato da un modello basato sul numero di CPU (socket e/o Core) fisica ad un modello basato sulla RAM virtuale.

Con questo cambiamento sul modello di licensing, Vmware andrà ad impattare sui costi che i clienti dovranno sostenere per gestire i loro ambienti virtuali.

Ulteriori informazioni:
Eppure il modello di licensing per-VM non era poi così male ?

Certo, con la diffusione dei sistemi a 64bit, i bassi costi della RAM, il consolidando su poche istanze di OS su cui si può far girare di tutto: forse questo cambio di strategia sui listini era proprio necessaria ?



domenica 17 luglio 2011

Nuovi prodotti e nuove versioni annunciate da VMware

VMware il 12 luglio ha annunciato il rilascio della nuova versione di vSphere e di altri prodotti. I prodotti saranno disponibili nel Q3 del 2011

vSphere 5 dispone di quasi 200 funzioni tra nuove e migliorate; continuando quindi ad essere lo standard ed il punto di riferimento per la virtualizzazione ed il fondamento principale per la costituzione di un ambiente cloud.

vSphere 5 è stato progettato per garantire:

  • migliori prestazioni per le applicazioni

  • incrementare l’alta affidabilità per i servizi business-critical,

  • maggiore automazione


Nella stessa giornata VMware ha inoltre annunciato tre ulteriori aggiornamenti facenti parte della suite per la cloud infrastructure:

  • VMware vShield 5: pensato per indirizzare i problemi relativi alla sicurezza, al controllo ed alla conformità. vShield nasce per proteggere gli ambienti virtuali e cloud ed è quindi in grado di fornire un modello di sicurezza diverso e più “consapevole” rispetto alle soluzioni tradizionali. Per fornire soluzioni ottimizzate ed orientate al cloud VMware collabora con i leader del settore della sicurezza;

  • VMware vCenter Site Manager Recovery 5: evoluzione di SRM che introdurrà nuove funzionalità quali la replica integrata dello storage e nuove features legate al failback ed alla migrazione pianificata. SRM 5 si integra con una vasta gamma di prodotti per la replica dello storage dando agli utenti la massima libertà di scelta nel progettare la propria soluzione di DR;

  • VMware vCloud Director 1.5: aggiornamento della soluzione per il cloud, abilità il modello “self-service” per il provisioning di servizi infrastrutturali interni ed esterni. VMware vCloud Director 1.5 permetterà di ridurre drasticamente il tempo necessario per la messa in produzione di nuovi server/servizi.


Ulteriori risorse:

giovedì 7 luglio 2011

Network Load Balancing: come funziona il criterio IP-Hash

La policy di Load Balancing “Route based on IP-Hash”, selezionabile nella scheda “NIC Teaming” a livello di vSwicth (o Portgroup) permette, di distribuire il traffico di una VM o di una porta VMkernel tra tutte le VMNIC appartenenti allo switch virtuale. Affinché questo metodo possa funzionare è necessario che lo switch fisico sia configurato per aggregare (802.3ad) le porte utilizzate nello switch virtuale.

Network Load Balancing “Route based on IP-Hash”

Il bilanciamento viene eseguito per il traffico in uscita e IP-Hash stabilisce un connessione, impegnando una NIC fisica differente, per ogni sessione “IP-sorgente – IP destinazione”; quindi se una VM con un IP comunica con 2 indirizzi IP differenti (esterni ad ESX) utilizzerebbe 2 NIC fisiche distinte.

Limiti di questo metodo:



  • ogni sessione utilizzarà al massimo alla velocità della NIC fisica su cui si è attesta;


  • il calcolo della scelta della NIC fisica viene fatto per ogni connessione, quindi se una VM comunica sempre o molto spesso solo con un IP, ESX è impegnato per fare un calcolo che darà sempre lo stesso risultato;


  • il sistema non tiene conto del carico di lavoro della NIC quindi in un ambiente ricco di VM è possibile che il calcolo restituisca una NIC fisica già fortemente utilizzata.


Per quanto riguarda il calcolo eseguito per selezionare la NIC fisica è necessario convertire in esadecimale i 2 indirizzi IP della sessione e con una calcolatrice scientifica eseguire lo XOR. Esempio:



  • IP sorgente 192.168.100.134, che in esadecimale diventa C0A86486


  • IP destinazione 192.168.100.70, che in esadecimale diventa C0A86446


  • C0A86486 XOR C0A86446 = C0


Successivamente è necessario calcolare il resto (MOD) dividendo il risultato dell’operazione XOR con il numero di VMNIC associate allo switch virtuale. Quindi se il vSwitch avesse 2 NIC si ottiene:



  • C0 MOD 2 = 0


Per maggiori infoirmazioni è possibile consultare: