Frame Jumbo vs Frame Ethernet

Un Jumbo frame è un frame Ethernet con un "payload" maggiore di 1500 byte, fino ad un massimo di 9000 byte. Se possiamo imballare in uno stesso pacchetto un payload più grande riusciamo a ridurre l’overhead nella rete e possiamo sperare di ottenere delle prestazioni migliori, poiché il sovraccarico di elaborazione di un host è proporzionale al numero di frame che vengono generati.

ESXi supporta i Jumbo Frames solo per la comunicazione con i dispositivi di storage e per le operazioni di vMotion, per cui ci siamo chiesti se, in quest’ultimo caso, potessimo ottenere qualche vantaggio dal loro utilizzo. Ovviamente lungo il path end-to-end tutti i dispositivi devono essere in grado di riconoscere i jumbo frames. Nel nostro caso dobbiamo abilitare i jumbo frame sul vSwitch 0 e sul vmkernel port che utilizziamo per la

134

vMotion, impostando il valore della MTU a 9000. Poi, ovviamente, configuriamo anche il NetGear in modo tale che non scarti frame più lunghi di 1500 byte (valore di default per la lunghezza massima di un pacchetto).

Figura 4.55

In figura 4.55 vengono proposti i risultati relativi al confronto tra vMotion eseguite utilizzando Frame Jumbo (MTU 9000) o Frame Ethernet.

Per queste misurazioni sono state replicate più migrazioni alternando l’uso di Frame Jumbo ed Ethernet.

Purtroppo, non è stato possibile ripetere l’analisi dettagliata fatta per le prove precedenti (Throughput Graph e Time/Sequence Graph), poiché Wireshark non è in grado di analizzare frame Ethernet con una lunghezza maggiore di 1500 byte.

Il grafico mostra che è possibile avere un guadagno significativo anche di 2 secondi quando si utilizza una MTU di 9000 byte e che, globalmente, l’utilizzo di Frame Jumbo consente di ridurre il tempo di migrazione.

135

CONCLUSIONI

Concludendo, la virtualizzazione consente di consolidare l’utilizzazione di server fisici e di abilitare alcune importanti feature per ottenere grande elasticità e grande affidabilità in ambienti cloud.

Tuttavia alcuni processi legati all’architettura virtuale, come lo spostamento delle VM o lo spostamento di virtual disk da un datastore ad un altro, producono un traffico bursty che sommato al traffico utente, inter e intra datacenter, può provocare, per brevi lassi di tempo, una saturazione del link trasmissivo.

L’utilizzo di interfacce dedicate per la vMotion risolverebbe il problema, ma non sarebbe ottimo, visto che per lunghi periodi di tempo le VM potrebbero non necessitare di spostamenti e i link rimarrebbero scarichi. Lo studio di questi fenomeni suggerisce che la ridistribuzione delle VM, in seguito al failure di un host o a causa di un improvviso aumento delle risorse richieste, deve essere effettuato tenendo conto dell’overhead che la vMotion produce. Tale overhead è proporzionale all’occupazione di RAM della VM sull’host, come sperimentato, per cui le VM dovranno essere classificata anche in base al tipo di lavoro che svolgono.

Ad esempio, VM che eseguono lavori a intenso uso della memoria e che quindi necessitano di un lungo tempo di migrazione, dovranno essere ridirette su host con interfacce di rete scariche, specie se si vuole offrire QoS. In questo modo si sceglie di sacrificare il concetto di consolidamento hardware, in maniera tale da non creare contesa sul trasmissivo, che produrrebbe un abbassamento del throughput (la vMotion opera attraverso

136

connessioni TCP!), che, a sua volta, determinerebbe un aumento della durata della migrazione e un peggioramento delle performance della VM. Il tempo di migrazione, come è stato verificato, può essere ridotto di qualche secondo abilitando l’utilizzo di Frames Jumbo (in particolare con MTU=9000). Questo ovviamente è possibile se lungo tutto il path di spostamento delle VM, è possibile configurare l’uso dei Frames Jumbo. Per quanto riguarda le prestazioni dei dispositivi di storage utilizzati, il confronto restituisce iSCSI come vincitore, ma è bene ricordare che il server NFS gira su una VM e il filesystem utilizzato (UFS) potrebbe influire sulle performance negative.

Al di là di ciò, l’analisi dei dati suggerisce caldamente di riservare una rete dedicata per lo storage dei dati, visto che l’accesso al virtual disk di una macchina può essere continuo e prolungato, come ad esempio durante una sessione di file transfer.

Infine, questo lavoro può dare un contributo qualitativo e quantitativo per la creazione di modelli di generazione del traffico in un datacenter e per poter effettuare traffic engeneering in maniera intelligente (network-aware

migration), tenuto conto che i fenomeni legati alla virtualizzazione possono

essere determinanti nella sagomatura del traffico, in particolare nel livello di accesso dei grossi datacenter.

Conclusioni

138

BIBLIOGRAFIA

 Expert Group Report “The Future of Cloud Computing: Opportunities

for European Cloud Computing Beyond 201”

 Wiley “Cloud Computing: Principles and Paradigms”

 O’ Reley “Cloud Computing”

 Guido Montalbano, Cataldo Tiano, Fabio Valant “Cloud Computing:

Le Soluzioni di Telecom Italia”

 Giovanni Lofrumento “Dalle Centrali Telefoniche alle Centrali

Computazionali: verso il Cloud Computing”

 Scott Love “Mastering VMware vSphere 5”

 VMware Technical Withe Paper “Performance Implication of Storage

I/O Control: Enabled NFS Datastore in VMware vSphere 5.0”

 VMware Technical Withe Paper “Storage I/O control Technical

Overview and Consideration for Deployment”

 VMware Technical Withe Paper “What’s New in VMware vSphere 5.0:

Networking”

 Virtual Geek “A ‘Multivendor Post’ on using iSCSI with VMware

vSphere”

 SysAdmin Talk “Create your own Network Storage Solution using

FreeNAS”

 Carl A. Waldspurger “Memory Resource Management in VMware ESX

Server”

 S. Kandula, S. Sengupta, A. Greenberg, P. Patel, R. Chaiken “The

Bibliografia

139

 M. Hauck, J.Happe, R.H. Reussner “Towards Performance Prediction

for Cloud Computin Environments Based on Goal-Oriented Measurements”

 VMware Technical Withe Paper “vCloud Director 1.5 Evaluation

Guide”

 VMware Technical Withe Paper “vCloud Director 1.5 Administrator

Guide”

 K. Chen, C.Hu, X. Zhang, K. Zheng, Y. Chen, A.V. Vasilakos “Survey

on Routing in Data Centers: Insights and Future Directions”

 M. Al-Fares, A. Loukissas, A. Vahdat “A Scalable, Commodity Data

Center Network Architecture”

 R. N. Mysore, A. Panboris, N. Farrington, N. Huang, P. Miri, S. Radhakrishnan, V. Subramanya, A. Vahdat “PortLand: A Scalable

Fault-Tolerant Layer 2 Data Center Network Fabric”

 A. Stage, T. Setzer “Network-aware migration control and scheduling

of differentiated virtual machine workloads”

 D. Kliazhovich, P. Bouvry, S.U. Khan “GreenCloud: a packet-level

simulator of energy-aware cloud computing data centers”

 D. Kliazhovich, P. Bouvry, S.U. Khan “DENS: data center energy-

efficient network-aware scheduling”

 T. Benson, A. Akella, D.A. Maltz “Networ Traffic Characteristics of

Data Centers in the Wild”

 T. Benson, A. Anand, A. Akella, M. Zhang “ Understanding Data

Center Traffic Characteristics”

 M. Nelson, B. Lim, G. Hutchins “Fast Transparent Migration for

140

 C. Clark, K. Fraser, S. Hand, J. Hansen, E. Jul, C. Limpach, I. Pratt, A. Warfield “Live Migration of Virtual Machines”

 H. Ballani, P. Costa, T. Karagiannis, A. Rowstron “Towards

Predictable Datacenter Networks”

 A. Greenberg “Networking the Cloud”

 M.R Hines, K. Gopalan “Post-Copy Based Live Virtual Machine

141

INDICE