Solución de problemas de picos de latencia en almacenes de datos de ESXi NFS

44

Estoy experimentando latencias fsync de alrededor de cinco segundos en almacenes de datos NFS en ESXi, activadas por ciertas máquinas virtuales. Sospecho que esto podría ser causado por máquinas virtuales que usan NCQ / TCQ, ya que esto no sucede con las unidades IDE virtuales.

Esto se puede reproducir usando fsync-tester (por Ted Ts'o) y ioping . Por ejemplo, usando un sistema en vivo Grml con un disco de 8GB:

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 ...]

Eso es 5 segundos, no milisegundos. Esto incluso está creando latencias de E / S en una VM diferente que se ejecuta en el mismo host y almacén de datos :

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

Cuando muevo la primera VM al almacenamiento local, parece perfectamente normal:

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 ...]

Cosas que he probado que no hicieron ninguna diferencia:

  • Probado varias versiones de ESXi: 381591, 348481, 260247
  • Probado en diferentes hardware, diferentes cajas Intel y AMD
  • Probado con diferentes servidores NFS, todos muestran el mismo comportamiento:
    • OpenIndiana b147 (sincronización ZFS siempre o deshabilitada: no hay diferencia)
    • OpenIndiana b148 (sincronización ZFS siempre o deshabilitada: no hay diferencia)
    • Linux 2.6.32 (sincronización o asíncrono: no hay diferencia)
    • No hay diferencia si el servidor NFS está en la misma máquina (como un dispositivo de almacenamiento virtual) o en un host diferente

SO invitado probado, mostrando problemas:

  • Windows 7 64 Bit (usando CrystalDiskMark, los picos de latencia ocurren principalmente durante la fase de preparación)
  • Linux 2.6.32 (fsync-tester + ioping)
  • Linux 2.6.38 (fsync-tester + ioping)

No pude reproducir este problema en máquinas virtuales Linux 2.6.18.

Otra solución es usar discos IDE virtuales (frente a SCSI / SAS), pero eso está limitando el rendimiento y la cantidad de unidades por VM.

Actualización 2011-06-30:

Los picos de latencia parecen ocurrir más a menudo si la aplicación escribe en múltiples bloques pequeños antes de fsync. Por ejemplo, fsync-tester hace esto (salida strace):

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

ioping hace esto mientras prepara el archivo:

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

La fase de configuración de ioping casi siempre se bloquea, mientras que fsync-tester a veces funciona bien. ¿Alguien puede actualizar fsync-tester para escribir varios bloques pequeños? Mis habilidades C apestan;)

Actualización 2011-07-02:

Este problema no ocurre con iSCSI. Intenté esto con el servidor iSCSI de COMSTAR de OpenIndiana. Pero iSCSI no le brinda acceso fácil a los archivos VMDK, por lo que puede moverlos entre hosts con instantáneas y rsync.

Actualización 2011-07-06:

Esto es parte de una captura de Wirehark, capturada por una tercera máquina virtual en el mismo vSwitch. Todo esto sucede en el mismo host, sin ninguna red física involucrada.

Comencé a ioping alrededor del tiempo 20. No se enviaron paquetes hasta que pasaron los cinco segundos de retraso:

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

2da actualización 2011-07-06:

Parece haber cierta influencia de los tamaños de las ventanas TCP. No pude reproducir este problema usando FreeNAS (basado en FreeBSD) como servidor NFS. Las capturas de Wirehark mostraron actualizaciones de la ventana TCP a 29127 bytes a intervalos regulares. No los vi con OpenIndiana, que usa tamaños de ventana más grandes por defecto.

Ya no puedo reproducir este problema si configuro las siguientes opciones en OpenIndiana y reinicio el servidor NFS:

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

Pero esto mata el rendimiento: escribir desde / dev / zero en un archivo con dd_rescue va de 170 MB / sa 80 MB / s.

Actualización 2011-07-07:

He subido esta captura tcpdump (puede analizarse con wireshark). En este caso, 192.168.250.2 es el servidor NFS (OpenIndiana b148) y 192.168.250.10 es el host ESXi.

Cosas que probé durante esta captura:

Comenzó "ioping -w 5 -i 0.2". en el momento 30, 5 segundos de configuración de bloqueo, completado en el tiempo 40.

Comenzó "ioping -w 5 -i 0.2". en el momento 60, 5 segundos de configuración de bloqueo, completado en el tiempo 70.

Comenzó "fsync-tester" en el momento 90, con la siguiente salida, se detuvo en el 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

2da Actualización 2011-07-07:

Probé otra máquina virtual de servidor NFS, esta vez edición comunitaria NexentaStor 3.0.5: muestra los mismos problemas.

Actualización 2011-07-31:

También puedo reproducir este problema en la nueva compilación ESXi 4.1.0.433742.

vmware-esxi nfs latency exo_cw
fuente
12
Tengo que decir que ha pasado un tiempo desde que un nuevo usuario llegó al tablero con una pregunta tan bien documentada y pensada, en serio, felicitaciones para usted. También es realmente interesante, tampoco me he encontrado con fsync-tester antes, así que gracias. Dicho esto, no estoy seguro de que tenga algo que agregar, ya has probado muchas de las cosas que ya hubiera hecho. Diría que hables con VMWare para ser honestos, son muy buenos para tomar este tipo de cosas de 'cola larga' / 'no una interrupción real del servicio' en serio. De todos modos sólo quería decir bien hecho de lo que has hecho hasta ahora :)
Chopper3
Desafortunadamente, el sitio web de VMware no me permite contactarlos: "Actualmente no tiene derechos de soporte activo"
exo_cw
ah, sí, eso puede ser un problema, por supuesto ...
Chopper3
3
5 segundos de tiempo de espera con NFS sonaba familiar. En linux NFS hay un tiempo de espera de .7 segundos para RPC que se duplica después de cada falla y extrae una importante después de 3 fallas (configuración predeterminada). .7 + 1.4 + 2.8 = 4.9 segundos. Hay una gran variedad de problemas de autenticación RPC que podrían causar esto.
Mark
2
@ Ryan: he subido el archivo de captura. También he subido la salida nfsstat .
exo_cw

Respuestas:

5

Este problema parece haberse solucionado en ESXi 5. He probado la compilación 469512 con éxito.

exo_cw
fuente
3

Gracias, nfsstat se ve bien. He revisado la captura. No he encontrado nada concluyente, pero encontré algo interesante. Filtré en tcp.time_delta> 5. Lo que encontré en cada instancia de retraso fue el inicio exacto de una llamada RPC. No todas las nuevas llamadas RPC fueron lentas, pero todas las ralentizaciones ocurrieron al comienzo exacto de una llamada RPC. Además, de la captura parece que 192.168.250.10 contiene todo el retraso. 192.168.250.2 responde de inmediato a todas las solicitudes.

Recomendaciones:

  • Los retrasos siempre ocurren en el primer paquete de una llamada RPC
  • Los tipos de comando NFS no se correlacionaron con las instancias de retraso
  • Fragmentación = retrasa solo el primer paquete

Una gran llamada de escritura se puede dividir en 300 paquetes TCP individuales, y solo el primero se retrasa, pero el resto pasa volando. La demora nunca ocurre en el medio. No estoy seguro de cómo el tamaño de la ventana podría afectar el comienzo de la conexión tan drásticamente.

Próximos pasos: comenzaría a ajustar las opciones de NFS como NFSSVC_MAXBLKSIZE hacia abajo en lugar de la ventana TCP. Además, noté que 2.6.18 funciona mientras que 2.6.38 no. Sé que se agregó soporte para el controlador VMXnet3 durante ese período de tiempo. ¿Qué controladores de NIC está utilizando en los hosts? ¿Descarga de TCP sí / no? Alrededor de la marca de 95 segundos hay más de 500 paquetes TCP para una sola llamada de escritura NFS. Lo que sea que esté a cargo de TCP y romper la gran PDU podría ser lo que está bloqueando.

Ryan
fuente
Intenté configurar nfs: nfs3_max_transfer_size, nfs: nfs3_max_transfer_size_cots y nfs: nfs3_bsize, todo hasta 8192: Sin diferencias, los mismos problemas. Los invitados de Linux solo usan sus discos SCSI / SAS, no NFS: el ESXi es el cliente NFS, por lo tanto, no hay problema de controlador de red en el invitado de Linux. En el lado del servidor NFS, probé tanto virtual e1000 como vmxnet3: no hubo diferencia. Hasta donde sé, ESXi solo usa la descarga TCP para iSCSI.
exo_cw
El mas grande? Lo que tengo es por qué ajustar la ventana TCP haría la diferencia ... Mi instinto me dice que tiene algo que ver con fragmentar esas grandes PDU a través de TCP. Algo en la pila de redes que se está ahogando. Simplemente no puedo pensar en nada que se ajuste al comportamiento que estamos viendo. Si el tamaño de la ventana fuera un problema, deberíamos ver el ancho de banda que limita la latencia en el medio de una transferencia grande, no el comienzo, pero siempre es el primer paquete de la llamada RPC ... difícil.
Ryan
2

Tengo lo que parece ser el mismo problema al usar ESXi4.1U1 y CentOS VM. Los hosts son Dell R610s, el almacenamiento es un clúster EMC2 Isilon.

¿Por casualidad usaste VLAN? Descubrí que el uso de una VLAN en el puerto VMkernel para el almacenamiento causó que los 4000-5000ms se `` bloqueen '' para todo el tráfico de almacenamiento en el VMHost. Sin embargo, si muevo el puerto VMkernel fuera de la VLAN para que reciba paquetes sin etiquetar, no veo el problema.

La configuración simple a continuación causará el problema en mi red:

1) Instale ESXi 4.1U1 en un servidor o estación de trabajo (ambos mostraron el problema cuando lo intenté)

2) Agregue un puerto VMkernel en una VLAN.

3) Agregue un almacén de datos NFS (el mío está en la misma VLAN, es decir, Isilon recibe paquetes etiquetados)

4) Instale 2 máquinas virtuales CentOS 5.5, una con ioping.

5) Arrancar máquinas virtuales en modo de usuario único (es decir, sin red, servicios mínimos)

6) Ejecute ioping en una máquina para que esté escribiendo en su disco virtual

7) Ejecute dd o somesuch en la otra máquina para escribir 100 MB de datos en / tmp o similar

La mayoría de las veces veo que ambas máquinas virtuales se congelan durante 4-5 segundos.

Estar realmente interesado en ver si alguien más ha visto algo similar.

Mella
fuente
¡Bienvenido a Server Fault! Esta es una vieja pregunta. Si sus respuestas no lo ayudan directamente, entonces debe hacer una nueva pregunta NUEVA haciendo clic en el botón Preguntar .
user9517 es compatible con GoFundMonica el
Sí, por supuesto que estoy usando VLAN etiquetadas. Como los estoy usando en todas partes, ni siquiera pensé en ellos como una fuente potencial de este problema. Voy a intentar reproducir esto en un puerto sin etiquetar.
exo_cw
También puedo reproducir este problema en un puerto sin etiquetar, no hay VLAN involucradas en ese host.
exo_cw
Solo estaba intentando de nuevo y también veo el problema en el puerto sin etiquetar, es un poco menos frecuente, tal vez por eso lo perdí. Perdón por el vagabundo. No puedo ver el problema en Win7 de 64 bits con iometer, además parece que puedo navegar por la unidad c: mientras que los otros vms de Linux están bloqueados. Voy a probar con crystalldiskmark
Nick
En realidad, me interesaría ver sus resultados con iometer en win7 x64. Mide la latencia, pero la cifra general más alta que obtuve fue de 300 ms usando la prueba de lectura de 4k, no 4000 + ms
Nick
2

Tuvimos exactamente el mismo problema hace dos semanas. Almacenes de datos ESX41 U1 y Netapp FAS3170 + NFS. Las máquinas virtuales RHEL5 se cuelgan durante 2 o 4 segundos y vimos picos muy altos en la consola de rendimiento de Virtual Center.

Le pido al chico de la red que verifique la configuración y el problema estaba en el conmutador Cisco. Tenemos dos enlaces Ethernet que se configuraron en Etherchannel en el lado de Netapp y no en el lado de Cisco. Él crea un Ethechannel estático en el Cisco y ahora funciona bien. Para identificar este tipo de problema, cierre todos los puertos excepto uno entre el archivador y el conmutador. Deja un solo puerto vivo y mira cómo van las cosas.

Lo segundo que hicimos fue eliminar el control de flujo en el conmutador y el archivador porque sospechamos que envía un marco de pausa.

Laurent
fuente
1

¿Cómo se ve tu DNS? Es tu /etc/resolv.confcorrecto? El tiempo de espera predeterminado es de 5 segundos.

De 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>).

Intente agregar timeout:3a su /etc/resolv.confy luego ejecute sus pruebas fsync nuevamente.

Joseph Kern
fuente
Intenté agregar esto en el servidor NFS (OpenIndiana en este caso) y en el host ESXi. Lamentablemente, esto no hace la diferencia. Puedo resolver el servidor y la IP del invitado bien.
exo_cw
Parece que filtró todo el tráfico no relacionado con la secuencia nfs, ¡es posible que necesitemos ver más!
tony roth
@tony roth: en realidad ese es todo el tráfico en ese momento. Lo probé en un vSwitch separado con solo el host y el servidor NFS.
exo_cw
¿Se puede volcar DNS con wireshark?
Joseph Kern el
@Joseph Kern: acabo de analizar los archivos de captura nuevamente: no hubo tráfico de DNS en absoluto durante mis capturas. El almacén de datos NFS está asignado por IP en el host ESXi. DNS funciona bien en ESXi y el servidor NFS, probé la búsqueda directa e inversa de todas las IP involucradas. En este momento no tengo ninguna razón para creer que el DNS sea la causa de esto.
exo_cw
1

Aferrándose a las pajillas aquí, pero ¿qué NIC está utilizando en estos servidores? Los administradores de sistemas de desbordamiento de pila han tenido problemas de red extraños con las NIC de Broadcom que desaparecieron cuando cambiaron a las NIC de Intel: http://blog.serverfault.com/post/broadcom-die-mutha/

enérgico
fuente
Las últimas pruebas se realizaron solo en un vSwitch, sin redes físicas involucradas (e1000 y vmxnet3: no hubo diferencia). Pero también probé esto en Intel 82574L, Intel 82576 e Intel 82567LF-3, todos mostrando el problema. Todavía no encontré ningún hardware donde no pueda reproducir esto.
exo_cw
1

Aquí hay otra suposición ... ¿Está habilitado su IPv6 en el host EXS? En caso afirmativo, ¿intente apagarlo? Según mi experiencia, si toda su red no está configurada correctamente para IPv6 (es decir, RADV, DHCP6, DNS, DNS inverso), puede ser un problema para algunos servicios. Además, asegúrese de que esté apagado en el servidor NFS.

dtoubelis
fuente
IPv6 ya estaba deshabilitado en el host ESXi. He deshabilitado IPv6 en el servidor NFS (ifconfig -a6 está vacío ahora), pero no hace la diferencia: muestra los mismos problemas.
exo_cw