Test performance vSphere 4.1 parte 1: vmware driver lsiscsi vs pvscsi in FC, iSCSI ed NFS.

Posted on 13 dicembre 2010 di

0



Con la nuova release, il driver per PVSCSI di vmware per i dischi virtuali è stato ulteriormente migliorato.

Le limitazioni di utilizzo sono sotto riportate nell’appendice A (per noi principalmente cluster Microsoft).

Ho deciso di effettuare dei test comparativi sulla macchina di nome Test_2k3_sp2 che è un server windows 2003 sp2
(32bit) a due vCPU tramite iometer sui due dischi (sistema e dati) ognuno con

un controller dedicato, per capire se nel nostro ambiente varrebbe la pena introdurre queste migliorie come consigliato dall’articolo ufficiale vmware http://www.youtube.com/watch?v=aiSa7THgxrI

Sicuramente per applicazioni (tipo i database) che effettuano alto numero di I/O ed i cui dischi virtuali risiedono su SAN (come indicato dai principali best practice).
Lo scopo? Dimostrare al boss (ed a noi stessi) che vale la pena migrare!
In tutti i casi il Test è stato effettuato con 2 workers (processi di iometer), 1 per ciascun disco, i cui parametri

di accesso in lettura e scrittura sono stati testati in maniera identica per 10 minuti in

durata di tempo sul nuovo ambiente vSphere 4.1.

Il tutto simulando per il test sul server accessi disco di tipo Webserver sul disco di sistema e Database sul disco dati

(seguendo le direttive della S.N.I.A. riportate in appendice B), che poi

è similare alla situazione in cui si trovano molte delle nostre macchine virtuali.

Nei grafici che risporto sotto, configurando tutte le variabili in gioco, è possibile affermare che la situazione ideale di

performance dello storage è quando avvengono 3 condizioni:

1) Minori richieste al disco (azzurro)

2) Minore collo di bottiglia per le CPU (rosso)

3) Minori code per le richieste di I/O (verde)

I test sono di tipo incrementale/esponenziale, quindi i grafici tendono tutti a salire fino al loro termine in base al numero di

“Oustanding I/Os” che vanno da 1 (applicazioni single threaded) a 32 (multi threaded)

in 6 steps diversi a distanza di poco meno 2 minuti. (quindi prima 1 thread, poi 2, poi 4, poi 8, poi 16 ed infine 32).

NEL NOSTRO CASO

FC = Netapp fas3020

iSCSI = Netapp fas2020

NAS = Iomega StoreCenter ix4

CASO #1
1) VMTOOLS aggiornati alla ultima versione
2) Hardware virtuale aggiornato alla ultima versione
3) Disco sistema e Disco dati con controller LSI SCSI

iSCSI CASO #1

FC CASO #1

NFS CASO #1

CASO #2
1) VMTOOLS aggiornati alla ultima versione
2) Hardware virtuale aggiornato alla ultima versione
3) Disco sistema controller LSI SCSI e Disco dati con controller PVSCSI
iSCSI CASO #2

FCCASO#2

NFS CASO #2

CASO #3
1) VMTOOLS aggiornati alla ultima versione
2) Hardware virtuale aggiornato alla ultima versione
3) Disco sistema e Disco dati con controller PVSCSI

iSCSI CASO #3

FC CASO #3

NFS CASO #3

RISULTATI

E’ estremamente complicato giudicare i risultati sopra riportati in assoluto, poiché in gioco vi sono tante variabili (momento in cui il test viene effettuato, scsi reservation in atto sulla lun e shares apllicati da vmware anche a livello di processi e cpu) nonostante ho cercato di lavorare sempre in condizioni simili. La macchina virtuale può “riportare” quei grafici campione sul test effettuato, ma essi non contengono la verità assoluta.

Di certo un ulteriore ausilio a questa analisi è il rapporto tra apporto tra byte trasmessi e tempo cpu (nominato CPU Effectiveness) prelevato dai risultati di Iometer che riporto nella matrice sottostante.

CPU Effectiveness LSI SCSI LSI + PVSCSI PVSCSI
FC CASO1 CASO2 CASO3
Thread =1 756.087.090 329.412.101 765.354.964
Thread =2 910.637.692 715.038.907 1.206.661.412
Thread =4 849.572.221 875.522.066 1.200.765.133
Thread =8 538.287.462 616.413.756 738.232.751
Thread =16 536.776.694 606.956.848 559.633.059
Thread =32 566.003.605 613.649.877 598.400.669
iSCSI CASO1 CASO2 CASO3
Thread =1 397.693.138 407.411.483 407.411.483
Thread =2 549.632.304 487.248.960 487.248.960
Thread =4 717.596.595 643.819.330 643.819.330
Thread =8 829.624.350 704.163.441 704.163.441
Thread =16 840.474.135 789.978.392 789.978.392
Thread =32 878.360.526 861.790.395 861.790.395
NFS CASO1 CASO2 CASO3
Thread =1 330.481.929 552.201.869 414.375.846
Thread =2 401.305.192 710.841.420 492.604.152
Thread =4 438.974.494 802.139.080 538.475.870
Thread =8 343.564.938 575.164.486 497.170.085
Thread =16 132.140.754 305.687.893 287.128.000
Thread =32 148.295.470 289.163.385 348.820.708

PERFORMANCE IN FIBRA (x = threads ; y= CPU Effectiveness) grafico clickabile

PERFORMANCE iSCSI (x = threads ; y= CPU Effectiveness) grafico clickabile

PERFORMANCE NFS (x = threads ; y= CPU Effectiveness) grafico clickabile

CONCLUSIONI

A quanto dicono i risultati dei test questi sono i migliori compromessi da adottare:

FIBRA: molto meglio mettere driver PVSCSI su tutti i dischi.

iSCSI: di gran lunga meglio PVSCSI su tutti i dischi.

NFS: meglio mettere sul disco di sistema LSI e sul disco dati PVSCSI od entrambi PVSCSI per appliacazioni multithread con alto I/O.

Interessante analizzare i dati comprativi tra tutte le situazioni testate: i massimi punti di performance raggiunti in termini di MBps risultano in iSCSI con applicazione a 32 thread.

Y=MBps

APPENDICE A: UTILIZZO DEL DRIVER PVSCI (LIMITAZIONI)

APPENDICE B: L’ente SNIA (Storage Networking Industry Association) ha pubblicato un documento che indica i principali test da eseguire in modo che essi sia ritenuti affidabili.

Io ho utilizzato quelli dedicati a websever e database, per propositi di test.

Annunci
Messo il tag: