Risoluzione dei problemi relativi ai picchi di latenza negli archivi dati ESXi NFS

44

Sto riscontrando latenze fsync di circa cinque secondi sui datastore NFS in ESXi, attivate da alcune macchine virtuali. Sospetto che ciò potrebbe essere causato dalle macchine virtuali che utilizzano NCQ / TCQ, poiché ciò non accade con le unità IDE virtuali.

Questo può essere riprodotto usando fsync-tester (di Ted Ts'o) e ioping . Ad esempio utilizzando un sistema live Grml con un disco da 8 GB:

Linux 2.6.33-grml64:
root@dynip211 /mnt/sda # ./fsync-tester
fsync time: 5.0391
fsync time: 5.0438
fsync time: 5.0300
fsync time: 0.0231
fsync time: 0.0243
fsync time: 5.0382
fsync time: 5.0400
[... goes on like this ...]

Sono 5 secondi, non millisecondi. Questo sta persino creando latenze di I / O su una macchina virtuale diversa in esecuzione sullo stesso host e archivio dati :

root@grml /mnt/sda/ioping-0.5 # ./ioping -i 0.3 -p 20 .
4096 bytes from . (reiserfs /dev/sda): request=1 time=7.2 ms
4096 bytes from . (reiserfs /dev/sda): request=2 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=3 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=4 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=5 time=4809.0 ms
4096 bytes from . (reiserfs /dev/sda): request=6 time=1.0 ms
4096 bytes from . (reiserfs /dev/sda): request=7 time=1.2 ms
4096 bytes from . (reiserfs /dev/sda): request=8 time=1.1 ms
4096 bytes from . (reiserfs /dev/sda): request=9 time=1.3 ms
4096 bytes from . (reiserfs /dev/sda): request=10 time=1.2 ms
4096 bytes from . (reiserfs /dev/sda): request=11 time=1.0 ms
4096 bytes from . (reiserfs /dev/sda): request=12 time=4950.0 ms

Quando sposto la prima macchina virtuale nella memoria locale, appare perfettamente normale:

root@dynip211 /mnt/sda # ./fsync-tester
fsync time: 0.0191
fsync time: 0.0201
fsync time: 0.0203
fsync time: 0.0206
fsync time: 0.0192
fsync time: 0.0231
fsync time: 0.0201
[... tried that for one hour: no spike ...]

Le cose che ho provato non hanno fatto differenza:

Testato diverse build ESXi: 381591, 348481, 260247
Testato su hardware diverso, diverse scatole Intel e AMD
Testato con diversi server NFS, mostrano tutti lo stesso comportamento:
- OpenIndiana b147 (sincronizzazione ZFS sempre o disabilitata: nessuna differenza)
- OpenIndiana b148 (sincronizzazione ZFS sempre o disabilitata: nessuna differenza)
- Linux 2.6.32 (sincronizzazione o asincrono: nessuna differenza)
- Non fa differenza se il server NFS si trova sulla stessa macchina (come dispositivo di archiviazione virtuale) o su un host diverso

Sistema operativo guest testato, che mostra problemi:

Windows 7 64 bit (utilizzando CrystalDiskMark, i picchi di latenza si verificano principalmente durante la fase di preparazione)
Linux 2.6.32 (fsync-tester + ioping)
Linux 2.6.38 (fsync-tester + ioping)

Non sono riuscito a riprodurre questo problema su VM Linux 2.6.18.

Un'altra soluzione alternativa consiste nell'utilizzare i dischi IDE virtuali (rispetto a SCSI / SAS), ma ciò sta limitando le prestazioni e il numero di unità per VM.

Aggiornamento 30/06/2011:

I picchi di latenza sembrano verificarsi più spesso se l'applicazione scrive in più piccoli blocchi prima di fsync. Ad esempio fsync-tester fa questo (output di strace):

pwrite(3, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 1048576, 0) = 1048576
fsync(3)                                = 0

ioping fa questo mentre prepara il file:

[lots of pwrites]
pwrite(3, "********************************"..., 4096, 1036288) = 4096
pwrite(3, "********************************"..., 4096, 1040384) = 4096
pwrite(3, "********************************"..., 4096, 1044480) = 4096
fsync(3)                                = 0

La fase di installazione di ioping si blocca quasi sempre, mentre a volte fsync-tester funziona bene. Qualcuno è in grado di aggiornare fsync-tester per scrivere più piccoli blocchi? Le mie abilità in C fanno schifo;)

Aggiornamento 02/07/2011:

Questo problema non si verifica con iSCSI. Ho provato questo con il server iSCSI OpenSTiana COMSTAR. Ma iSCSI non ti dà un facile accesso ai file VMDK, quindi puoi spostarli tra host con snapshot e rsync.

Aggiornamento 06/07/2011:

Questo fa parte di un'acquisizione di WireShark, acquisita da una terza VM sullo stesso vSwitch. Tutto ciò accade sullo stesso host, nessuna rete fisica coinvolta.

Ho iniziato a fare il giro intorno al tempo 20. Non c'erano pacchetti inviati fino al termine del ritardo di cinque secondi:

No.  Time        Source                Destination           Protocol Info
1082 16.164096   192.168.250.10        192.168.250.20        NFS      V3 WRITE Call (Reply In 1085), FH:0x3eb56466 Offset:0 Len:84 FILE_SYNC
1083 16.164112   192.168.250.10        192.168.250.20        NFS      V3 WRITE Call (Reply In 1086), FH:0x3eb56f66 Offset:0 Len:84 FILE_SYNC
1084 16.166060   192.168.250.20        192.168.250.10        TCP      nfs > iclcnet-locate [ACK] Seq=445 Ack=1057 Win=32806 Len=0 TSV=432016 TSER=769110
1085 16.167678   192.168.250.20        192.168.250.10        NFS      V3 WRITE Reply (Call In 1082) Len:84 FILE_SYNC
1086 16.168280   192.168.250.20        192.168.250.10        NFS      V3 WRITE Reply (Call In 1083) Len:84 FILE_SYNC
1087 16.168417   192.168.250.10        192.168.250.20        TCP      iclcnet-locate > nfs [ACK] Seq=1057 Ack=773 Win=4163 Len=0 TSV=769110 TSER=432016
1088 23.163028   192.168.250.10        192.168.250.20        NFS      V3 GETATTR Call (Reply In 1089), FH:0x0bb04963
1089 23.164541   192.168.250.20        192.168.250.10        NFS      V3 GETATTR Reply (Call In 1088)  Directory mode:0777 uid:0 gid:0
1090 23.274252   192.168.250.10        192.168.250.20        TCP      iclcnet-locate > nfs [ACK] Seq=1185 Ack=889 Win=4163 Len=0 TSV=769821 TSER=432716
1091 24.924188   192.168.250.10        192.168.250.20        RPC      Continuation
1092 24.924210   192.168.250.10        192.168.250.20        RPC      Continuation
1093 24.924216   192.168.250.10        192.168.250.20        RPC      Continuation
1094 24.924225   192.168.250.10        192.168.250.20        RPC      Continuation
1095 24.924555   192.168.250.20        192.168.250.10        TCP      nfs > iclcnet_svinfo [ACK] Seq=6893 Ack=1118613 Win=32625 Len=0 TSV=432892 TSER=769986
1096 24.924626   192.168.250.10        192.168.250.20        RPC      Continuation
1097 24.924635   192.168.250.10        192.168.250.20        RPC      Continuation
1098 24.924643   192.168.250.10        192.168.250.20        RPC      Continuation
1099 24.924649   192.168.250.10        192.168.250.20        RPC      Continuation
1100 24.924653   192.168.250.10        192.168.250.20        RPC      Continuation

2 ° aggiornamento 2011-07-06:

Sembra esserci una certa influenza dalle dimensioni della finestra TCP. Non sono riuscito a riprodurre questo problema usando FreeNAS (basato su FreeBSD) come server NFS. Le acquisizioni di WireShark hanno mostrato ad intervalli regolari aggiornamenti della finestra TCP a 29127 byte. Non li ho visti con OpenIndiana, che per impostazione predefinita utilizza finestre di dimensioni maggiori.

Non riesco più a riprodurre questo problema se imposto le seguenti opzioni in OpenIndiana e riavvio il server NFS:

ndd -set /dev/tcp tcp_recv_hiwat 8192 # default is 128000
ndd -set /dev/tcp tcp_max_buf 1048575 # default is 1048576

Ma questo uccide le prestazioni: scrivere da / dev / zero in un file con dd_rescue va da 170 MB / sa 80 MB / s.

Aggiornamento 07/07/2011:

Ho caricato questa acquisizione di tcpdump (può essere analizzata con WireShark). In questo caso 192.168.250.2 è il server NFS (OpenIndiana b148) e 192.168.250.10 è l'host ESXi.

Cose che ho testato durante questa acquisizione:

Iniziato "ioping -w 5 -i 0.2." al momento 30, 5 secondi di blocco nell'installazione, completato al momento 40.

Iniziato "ioping -w 5 -i 0.2." al momento 60, 5 secondi di blocco nell'installazione, completato al momento 70.

Avviato "fsync-tester" al momento 90, con la seguente uscita, arrestato al momento 120:

fsync time: 0.0248
fsync time: 5.0197
fsync time: 5.0287
fsync time: 5.0242
fsync time: 5.0225
fsync time: 0.0209

2 ° aggiornamento 2011-07-07:

Testato un'altra macchina virtuale del server NFS, questa volta edizione della community NexentaStor 3.0.5: mostra gli stessi problemi.

Aggiornamento 2011-07-31:

Posso anche riprodurre questo problema sul nuovo build ESXi 4.1.0.433742.

vmware-esxi nfs latency

— exo_cw
fonte

12

Devo dire che è passato un po 'di tempo da quando un utente nuovo di zecca è arrivato alla lavagna con una domanda così ben documentata e ponderata - sul serio, cappello a te. È anche davvero interessante, non ho mai incontrato fsync-tester prima di allora, quindi grazie. Detto questo, non sono sicuro di avere qualcosa da aggiungere, hai provato così tante cose che avrei già - direi di parlare con VMWare per essere onesti, sono molto bravi a prendere questo tipo di "long-tail" / "non una vera interruzione del servizio" sul serio. Ad ogni modo volevo solo dirti ben fatto per quello che hai fatto finora :)

— Chopper3

Purtroppo il sito Web VMware non mi consente di contattarli: "Al momento non hai diritti di supporto attivi"

— exo_cw,

ah, sì, questo può essere un problema ovviamente ...

— Chopper3

3

Il timeout di 5 secondi con NFS sembrava familiare. In Linux NFS c'è un timeout di .7 secondi per RPC che raddoppia dopo ogni errore e tira un maggiore dopo 3 errori (impostazioni predefinite). .7 + 1,4 + 2,8 = 4,9 secondi. Esistono numerosi problemi di autenticazione RPC che potrebbero causare questo.

— Segna il

2

@Ryan: ho caricato il file di acquisizione. Ho anche caricato l' output di nfsstat .

— exo_cw,

5

Questo problema sembra essere stato risolto in ESXi 5. Ho testato con successo la build 469512.

— exo_cw
fonte

3

Grazie, nfsstat sembra buono. Ho rivisto la cattura. Non ho trovato nulla di conclusivo, ma ho trovato qualcosa di interessante. Ho filtrato su tcp.time_delta> 5. Quello che ho trovato in ogni istanza di ritardo è stato l'inizio esatto di una chiamata RPC. Non tutte le nuove chiamate RPC erano lente, ma tutti i rallentamenti si sono verificati all'inizio esatto di una chiamata RPC. Inoltre, dalla cattura sembra che 192.168.250.10 contenga tutto il ritardo. 192.168.250.2 risponde immediatamente a tutte le richieste.

I risultati:

I ritardi si verificano sempre nel primo pacchetto di una chiamata RPC
I tipi di comando NFS non erano correlati alle istanze di ritardo
Frammentazione = ritarda solo il primo pacchetto

Una chiamata di scrittura di grandi dimensioni può essere suddivisa in 300 singoli pacchetti TCP e solo il primo viene ritardato, ma il resto vola. Il ritardo non si verifica mai nel mezzo. Non sono sicuro di come le dimensioni della finestra possano influenzare così drasticamente l' inizio della connessione.

Passaggi successivi: inizierei a modificare le opzioni NFS come NFSSVC_MAXBLKSIZE verso il basso anziché la finestra TCP. Inoltre, ho notato che 2.6.18 funziona mentre 2.6.38 no. So che durante quel lasso di tempo è stato aggiunto il supporto per il driver VMXnet3. Quali driver NIC stai usando sugli host? Offload TCP sì / no? Intorno al segno di 95 secondi ci sono più di 500 pacchetti TCP per una singola chiamata di scrittura NFS. Qualunque cosa sia responsabile del TCP e della rottura della grande PDU potrebbe essere ciò che blocca.

— Ryan
fonte

Ho provato a impostare nfs: nfs3_max_transfer_size, nfs: nfs3_max_transfer_size_cots e nfs: nfs3_bsize fino a 8192: nessuna differenza, stessi problemi. I guest linux usano semplicemente i loro dischi SCSI / SAS, niente NFS - ESXi è il client NFS, quindi nessun problema con i driver di rete sul guest linux. Sul lato server NFS ho provato sia virtuale e1000 che vmxnet3: non ha fatto differenza. Per quanto ne so ESXi utilizza solo TCP offloading per iSCSI.

— exo_cw,

Il più grande ? Ecco perché la regolazione della finestra TCP farebbe la differenza ... Il mio istinto mi dice che ha a che fare con la frammentazione di quelle grandi PDU su TCP. Qualcosa nello stack di rete che ci sta soffocando. Non riesco proprio a pensare a nulla che si adatti al comportamento che stiamo vedendo. Se la dimensione della finestra era un problema dovremmo vedere la latenza che limita la larghezza di banda nel mezzo di un trasferimento di grandi dimensioni, non all'inizio, ma è sempre il primo pacchetto della chiamata RPC ... difficile.

— Ryan,

2

Ho quello che sembra lo stesso problema usando ESXi4.1U1 e CentOS VM. Gli host sono Dell R610s, l'archiviazione è un cluster Isilon EMC2.

Eri per caso usando VLANS? Ho scoperto che l'utilizzo di una VLAN sulla porta VMkernel per l'archiviazione ha causato "blocchi" di 4000-5000ms per tutto il traffico di archiviazione su VMHost. Tuttavia, se sposto la porta VMkernel dalla VLAN in modo che riceva pacchetti senza tag non vedo il problema.

La semplice configurazione di seguito causerà il problema sulla mia rete:

1) Installa ESXi 4.1U1 su un server o una workstation (entrambi hanno mostrato il problema quando ho provato)

2) Aggiungi una porta VMkernel su una VLAN.

3) Aggiungere un archivio dati NFS (il mio è sulla stessa VLAN, ovvero Isilon riceve i pacchetti con tag)

4) Installa 2 VM CentOS 5.5, una con ioping.

5) Avvia le VM in modalità utente singolo (ovvero nessuna rete, servizi minimi)

6) Esegui ioping su una macchina in modo che scriva sul suo disco virtuale

7) Eseguire dd o somesuch sull'altra macchina per scrivere 100 MB di dati su / tmp o simili

Più spesso vedo il congelamento di entrambe le VM per 4-5 secondi.

Sii davvero interessato a vedere se qualcun altro ha visto simili.

— tacca
fonte

Benvenuti in Server Fault! Questa è una vecchia domanda. Se le risposte non ti aiutano direttamente, dovresti fare una nuova NUOVA domanda facendo clic sul pulsante Poni domanda .

— user9517 supporta GoFundMonica il

Sì, ovviamente sto usando VLAN con tag. Dato che li sto usando ovunque, non li ho nemmeno considerati una potenziale fonte di questo problema. Proverò a riprodurlo su una porta senza tag.

— exo_cw,

Posso riprodurre questo problema anche su una porta senza tag, nessuna VLAN coinvolta su quell'host.

— exo_cw,

Stavo solo riprovando e vedo il problema anche sulla porta senza tag, è un po 'meno frequente, forse è per questo che l'ho perso. Ci scusiamo per il barbone. Non riesco a vedere il problema su Win7 a 64 bit usando iometer, inoltre mi sembra di poter sfogliare l'unità c: mentre sono bloccati gli altri vms di Linux. Proverò con il cristallo di cristalli

— Nick,

In realtà sarei interessato a vedere i tuoi risultati con iometer su win7 x64. Misura la latenza ma la cifra complessiva più alta che ho ottenuto è stata di 300 ms utilizzando il test di lettura 4k, non 4000 + ms

— Nick,

2

Abbiamo avuto esattamente lo stesso problema due settimane fa. Datastore ESX41 U1 e Netapp FAS3170 + NFS. Le macchine virtuali RHEL5 si bloccano per 2 o 4 secondi e abbiamo visto picchi molto elevati dalla console delle prestazioni di Virtual Center.

Chiedo al ragazzo della rete di verificare la configurazione e il problema si è verificato sullo switch Cisco. Abbiamo due collegamenti Ethernet configurati su Etherchannel sul lato Netapp e non sul lato Cisco. Crea un Ethechannel statico sul Cisco e ora funziona benissimo. Per identificare questo tipo di problema, chiudere tutte le porte tranne una tra il filer e lo switch. Lascia in vita solo una porta e guarda come vanno le cose.

La seconda cosa che facciamo è stata quella di rimuovere il controllo di flusso su switcj e sul filer perché sospettiamo che invii frame di pausa.

— Laurent
fonte

1

Come appare il tuo DNS? È /etc/resolv.confcorretto? Il timeout predefinito è 5 secondi.

A partire dal man resolv.conf

timeout:n
                 sets the amount of time the  resolver  will  wait  for  a
                 response  from  a  remote name server before retrying the
                 query via a different name server.  Measured in  seconds,
                 the default is RES_TIMEOUT (currently 5, see <resolv.h>).

Prova ad aggiungere il timeout:3tuo, /etc/resolv.confquindi esegui nuovamente i test fsync.

— Joseph Kern
fonte

Ho provato ad aggiungere questo sul server NFS (OpenIndiana in questo caso) e sull'host ESXi. Purtroppo questo non fa differenza. Posso risolvere bene l'IP del server e dell'ospite.

— exo_cw,

sembra che tu abbia filtrato tutto il traffico non correlato allo stream nfs, potremmo aver bisogno di vedere di più!

— tony roth,

@tony Roth: In realtà questo è l'intero traffico in quel momento. L'ho provato su un vSwitch separato con solo l'host e il server NFS su di esso.

— exo_cw,

Riesci a scaricare DNS con WireShark?

— Joseph Kern,

@Joseph Kern: ho appena analizzato di nuovo i file di acquisizione: durante le mie acquisizioni non c'era alcun traffico DNS. L'archivio dati NFS è mappato dall'IP sull'host ESXi. Il DNS funziona perfettamente su ESXi e sul server NFS, ho testato la ricerca diretta e inversa di tutti gli IP coinvolti. In questo momento non ho motivo di credere che il DNS sia la causa di questo.

— exo_cw,

1

Approfondimento qui, ma quali schede di rete utilizzate in questi server? Gli amministratori di sistema Stack Overflow hanno avuto strani problemi di rete con le schede di rete Broadcom che sono scomparse quando sono passati alle schede di rete Intel: http://blog.serverfault.com/post/broadcom-die-mutha/

— vigoroso
fonte

Gli ultimi test sono stati eseguiti solo su un vSwitch, nessuna rete fisica coinvolta (e1000 e vmxnet3: non ha fatto alcuna differenza). Ma ho anche testato questo su Intel 82574L, Intel 82576 e Intel 82567LF-3, mostrando tutti il problema. Non ho ancora trovato alcun hardware dove non riesco a riprodurlo.

— exo_cw,

1

Ecco un'altra ipotesi ... Il tuo IPv6 è abilitato sull'host EXS? Se sì, prova a spegnerlo? Dalla mia esperienza, se l'intera rete non è configurata correttamente per IPv6 (ovvero RADV, DHCP6, DNS, DNS inverso), potrebbe essere un problema per alcuni servizi. Inoltre, assicurarsi che sia spento sul server NFS.

— dtoubelis
fonte

IPv6 era già disabilitato sull'host ESXi. Ho disabilitato IPv6 sul server NFS (ifconfig -a6 è vuoto ora), ma non fa differenza: mostra gli stessi problemi.

— exo_cw,