Ottimizzazione dello stack client / server NFS

Ho un server CentOS 5 VMWare che si collega a una macchina OpenSolaris 2009.06 su NFS che contiene le immagini del disco. Le mie macchine virtuali sembrano essere legate da IO lenti, quindi mi piacerebbe fare tutto il possibile per ottimizzare la connessione.

Non sono sicuro del modo migliore per misurare il throughput su un sistema di produzione, ma alcuni test non scientifici che usano dd bs=1024k count=400scritture show local (OpenSolaris) di ~ 1.6GB / se scritture remote (CentOS) ~ 50MB / s. Immagino che questi siano inferiori a quello che sto effettivamente ottenendo dal momento che 7 VM sono attualmente in esecuzione sulla connessione.

Attualmente, le 2 macchine sono gigE connesse direttamente con frame jumbo abilitati su entrambe le schede NIC (MTU = 9000). A parte questo, non sono state apportate ottimizzazioni. Il mount / export di NFS utilizza i valori predefiniti.

Dove devo iniziare a girare le manopole per migliorare le prestazioni?

Giusto per chiarire, stai ottenendo 50 MB / sec con NFS su una singola connessione Ethernet Gb?

E il server host esegue CentOS con VMware Server installato, che a sua volta esegue le 7 VM? C'è un motivo particolare per cui hai combinato CentOS e VMware Server, anziché VMware ESXi, che è una soluzione dalle prestazioni più elevate?

I 50 MB / sec non sono eccezionali, ma non sono molto al di sotto di quanto ci si aspetterebbe da un singolo cavo di rete Gb: una volta inserite le modifiche NFS che le persone hanno menzionato sopra, vedrai forse 70- 80 MB / sec. Opzioni lungo la linea di:

"ro, hard, intr, Retrans = 2, rsize = 32768, wsize = 32768, nfsvers = 3, tcp"

sono probabilmente ragionevoli per te ad entrambe le estremità del sistema.

Per superare ciò, dovrai cercare di raggruppare le schede di rete in coppie, il che dovrebbe aumentare la velocità effettiva di circa il 90%. Potrebbe essere necessario uno switch che supporti 802.3ad per ottenere le migliori prestazioni con l' aggregazione dei collegamenti .

Una cosa che suggerirei è che il throughput IO sulla confezione di OpenSolaris suona sospettosamente alto, 12 dischi non sono in grado di supportare 1,6 GB / sec di throughput e questo potrebbe essere pesantemente memorizzato nella cache da Solaris + ZFS.

Per le nostre macchine RHEL / CentOS 5 utilizziamo i seguenti flag di montaggio

nfsvers = 3, tcp, timeo = 600, Retrans = 2, rsize = 32768, wsize = 32768, duro, intr, noatime

La versione più recente del kernel Linux supporta parametri rsize / wsize ancora più grandi, ma 32k è il massimo per il kernel 2.6.18 in EL5.

Sui server NFS, almeno per Linux no_wdelay presumibilmente aiuta se si dispone di un controller del disco con BBWC. Inoltre, se si utilizza il flag noatime sui client, probabilmente ha senso montare anche i filesystem sui server con noatime.

E, come già accennato, non preoccuparti di UDP. Con reti a velocità più elevata (1GbE +) esiste una piccola, ma diversa da zero, possibilità che un numero progressivo avvenga causando il danneggiamento dei dati. Inoltre, se esiste la possibilità di perdita di pacchetti, TCP funzionerà meglio di UDP.

Se non ti preoccupi così tanto dell'integrità dei dati, l'opzione di esportazione "asincrona" può rappresentare un notevole miglioramento delle prestazioni (il problema con asincrono è che potresti perdere i dati in caso di arresto anomalo del server).

Inoltre, almeno per il server Linux, devi assicurarti di avere abbastanza thread del server NFS in esecuzione. Il valore predefinito 8 è semplicemente troppo basso.

Una volta ho fatto un test con un Dell R710, 1 CPU, 4 GB RAM, 6 dischi SATA con RAID-10. Il client era un sun x2100, sia con CentOS 5.3 che con i parametri nfs come menzionato sopra

"ro, hard, intr, Retrans = 2, rsize = 32768, wsize = 32768, nfsvers = 3, tcp"

montato su entrambi i lati con noatime.

Ho anche fatto un salto da nfsds a 256 e ho usato lo schedulatore noop per il controller raid perc6. Un'altra cosa che ho fatto è stato allineare le partizioni alla dimensione della striscia 64K del controller raid.

poi ho misurato le prestazioni di nfs con dd - per le letture ho potuto riempire la pipe gigE ma per le scritture ho potuto ottenere solo risultati leggermente migliori come te. Con asincrono abilitato ho potuto ottenere 70 a 80 MB / s ma asincrono non era un'opzione per il mio.

Forse non puoi ottenere di più con nfs da un link gigE?

Prova questo: disabilita temporaneamente il registro degli intenti ZFS (ZIL) sul server OpenSolaris NFS con i seguenti due passaggi

1. echo zil_disable/W0t1 | mdb -kw
2. rimontare la partizione di prova

Quindi riprovare. Puoi usare zilstat per assicurarti che non ci sia più IO in ZIL. Se il test viene eseguito più velocemente, sai che il problema di prestazioni ha a che fare con ZIL. Se funziona ancora lentamente, sai che ZIL non è il colpevole e che l'utilizzo di un SSD per ZIL non è di aiuto. Consulta la Guida alla messa a punto del male di ZFS per ulteriori informazioni su ZIL.

Un'altra opzione sarebbe quella di catturare il traffico di rete (ad esempio con Wireshark) e vedere se ci sono problemi, ad esempio con i frame Jumbo. Verifica che i pacchetti sul filo sembrino come ti aspetti dalla tua configurazione. C'è qualche frammentazione in corso? Ci sono ritrasmissioni?

Aumentare le dimensioni del payload in lettura e scrittura può aiutare. Soprattutto in combinazione con i frame jumbo.

Tendo a trovare 32k per essere ottimale.

rsize=32768,wsize=32768

Il passaggio al trasporto UDP è ovviamente più veloce di TCP, poiché consente di risparmiare il sovraccarico del controllo della trasmissione. Ma è applicabile solo su reti affidabili e dove NFSv4 non è in uso.

Le prestazioni di NFS su ZFS sono notevolmente migliorate utilizzando un SSD per il registro di intenti ZFS (ZIL) in quanto ciò riduce la latenza delle operazioni. Questo thread sulle prestazioni di VMWare NFS su ZFS nelle mailing list di OpenSolaris NFS e ZFS contiene ulteriori informazioni, incluso uno strumento di riferimento per vedere se le prestazioni di ZIL sono il collo di bottiglia.

Cordiali saluti il ​​comando dd scriverà nella cache e nessun disco, questo è possibile ottenere numeri folli come 1.6G / s perché si sta scrivendo su RAM e non su disco su Solaris è possibile utilizzare "-oflag = sync" per forzare le scritture su disco