vMotion durante file transfer

Consideriamo adesso una macchina virtuale che esegue una sessione di file transfer, e vediamo come effettuare una vMotion possa incidere sul throughput.

La VM che utilizziamo è, al solito, quella con sistema operativo Ubuntu11.10 impegnata a scaricare un file di 695 MByte, ovvero l’immagine ISO di Ubunut11.10 dai server di Ubuntu.

Pochi secondi dopo che viene avviato il download viene effettuata la migrazione della VM.

Durante la misurazione è stato sniffato il traffico dalle porte g1, g3, g4 per l’host .150, g5 per l’NFS, g7 e g8 per l’host .104. Siccome vengono riportati tutti i pacchetti che attraversano ciascuna porta, in una trasmissione bidirezionale tra due host connessi a due qualunque delle suddette porte, ciascun pacchetto viene riportato due volte. Per poter effettuare correttamente l’analisi del traffico scambiato è stato necessario rimuovere tutti i pacchetti duplicati e per farlo è stato lanciato il seguente comando dal prompt di windows:

Misurazioni Sperimentali

101 editcap -d <infile> <outfile>

Analizziamo innanzi tutto le statistiche sommarie raccolte da Wireshark e proposte in tabella 4.7:

Tabella 4.7

Vediamo adesso, come è distribuito lungo i 150 secondi della misurazione, l’arrivo dei pacchetti.

In particolare, la figura 4.15, presenta 5 grafici sovrapposti con la distribuzione temporale dei bytes scambiati:

- sul segmento LAN osservato (in nero)

- tra il server di ubuntu e la nostra VM, rispettivamente con gli indirizzi 93.63.209.92 e 131.114.53.108 (in rosso)

- tra gli host .104 e .105 (in verde) - tra l’host .104 e il server NFS (in blu) - tra l’host .150 e il server NFS (in viola)

102

Figura 4.15

Come si nota, le 4 distribuzioni, compongono, grossomodo, tutto il traffico scambiato.

La connessione per il download del file dura tutti i 150 secondi, e anche oltre, ma per esigenze di calcolo l’acquisizione di pacchetti è stata bloccata in anticipo, quando erano stati trasferiti circa 350 MByte dei 695Mbyte totali.

Come nel caso precedente la migrazione della VM, con il trasferimento delle pagine di memoria che comporta, occupa un piccolo lasso di tempo in cui si registra il throughput più elevato, con un picco di circa 25 MByte/s, ovvero circa 200 Mbit/s.

In figura 4.16, viene proposto il grafico Time/Sequence Number di una delle due sessioni TCP che determina la vMotion.

Misurazioni Sperimentali

103

Figura 4.16

In figura 4.16 si notano dei buchi, alcuni dei quali dovuti alla perdita di pacchetti, come documentato dall’estratto del capture file di figura 4.17.

Figura 4.17

La migrazione dura poco più di 9 secondi, con un rate medio aggregato di 129,6 Mbit/s, come documentato dalla tabella 4.8.

104

Concentriamoci ora sui grafici che descrivono lo scambio di informazioni tra il server NFS e gli host ESXi. Come è lecito aspettarsi inizialmente, i dati fluiscono tra l’host .104 su cui gira la VM e il server NFS. Tali pacchetti contengono presumibilmente i dati scambiati tra la macchina virtuale ed il server di Ubuntu, e servono a “riempire” il virtual disk della VM.

Nel momento in cui la VM migra sull’host .150 il flusso di dati verso il server NFS non s’interrompe, ma cambia l’host sorgente. E così mentre il throughput della comunicazione tra l’host .104 e il server NFS si spegne (scompare il grafico in blu), aumenta quello tra l’host .150 e l’NFS (grafico in viola).

Tabella 4.9

È difficile stimare, in questo caso, il throughput medio tra gli host ESXi ed il server NFS. Guardando la tabella 4.9 appare chiaro che essa non spiega adeguatamente la situazione: la sessione TCP tra l’host ESXi .104 ed il server NFS rimane aperta per tutta la durata della misurazione (come testimoniano i messaggi di keep alive di figura 4.20), per cui il throughput medio tiene conto anche del periodo successivo alla migrazione quando, apparentemente, non viene trasmesso niente.

Misurazioni Sperimentali

105 I grafici in figura 4.18 e 4.19 mostrano in maniere più fedele l’andamento visto precedentemente, in particolare in figura 4.18, si possono notare tante rampe quanti sono i picchi del grafico in blu.

A questo punto ci aspettiamo un grafico simile per la trasmissione dati tra l’host .150 e l’NFS, in cui le rampe compaiono dopo che è avvenuta la migrazione, e quindi dopo i 90 secondi (figure 4.21 e 4.22).

Figura 4.18 Figura 4.19

106

Figura 4.21 Figura 4.22

In ultimo, vediamo cosa succede al traffico legato al file transfer e vediamo se, in qualche modo, viene influenzato dalla migrazione della VM, per cui guardiamo con interesse a cosa accade tra gli 85 e i 95 secondi della misurazione.

Figura 4.23

Apparentemente guardando la figura 4.23, non sembra che la trasmissione dati abbia risentito particolarmente dello spostamento della VM, ma un’ispezione approfondita mostra una diminuzione del throughput (figura

Misurazioni Sperimentali

107 4.24) e la perdita di alcuni pacchetti causata dal downtime della VM stimabile di circa 1 secondo.

Figura 4.24

Da questo estratto del capture file possiamo ricostruire cosa succede tra gli end host.

L’ultimo pacchetto ack-appato, ma non l’ultimo ricevuto, da parte dell’host .108 è quello con numero di sequenza 226956625. I pacchetti successivi

108

vengono ricevuti, ma non ack-appati, fino a quello che annuncia un next sequence number pari a 227018889, per cui è presumibile che fino all’istante 93.03333 la VM è attiva e capace di prelevare pacchetti. Dopo di che, la VM entra in downtime e i pacchetti on-fly vengono persi (nel nostro caso uno solo).

Durante questo intervallo, però, al server di ubuntu non arrivano ACK, per cui scadono i timeout relativi ai pacchetti non riscontrati, che vengono assunti persi e quindi inviati un’altra volta.

La VM torna attiva all’istante 94.1 e riprende la trasmissione degli ACK dei pacchetti che, intanto, l’altro host gli sta rinviando. Per ogni nuovo pacchetto che arriva, la VM risponde con degli ACK duplicati in cui specifica che attende il pacchetto con sequence number 227018889.

All’arrivo del suddetto pacchetto, la trasmissione riprende normalmente.

Figura 4.25

Il throughput per il download del file diminuisce sensibilmente durante la

Misurazioni Sperimentali

109

Figura 4.26