Ajuste de pila de cliente / servidor NFS

10

Tengo un servidor CentOS 5 VMWare que se conecta a una máquina OpenSolaris 2009.06 a través de NFS que contiene las imágenes de disco. Mis máquinas virtuales parecen estar unidas por un IO lento, por lo que me gustaría hacer todo lo posible para optimizar la conexión.

No estoy seguro de la mejor manera de medir el rendimiento en un sistema de producción, pero algunas pruebas no científicas que usan dd bs=1024k count=400escrituras locales (OpenSolaris) muestran ~ 1.6GB / sy escrituras remotas (CentOS) ~ 50MB / s. Me imagino que estos son más bajos de lo que realmente estoy obteniendo ya que 7 máquinas virtuales se ejecutan actualmente a través de la conexión.

Actualmente, las 2 máquinas son gigE conectadas directamente con marcos jumbo habilitados en ambas NIC (MTU = 9000). Aparte de eso, no se han realizado optimizaciones. NFS mount / export está utilizando los valores predeterminados.

¿Dónde debo comenzar a girar las perillas para mejorar el rendimiento?

Sysadminicus
fuente
El rendimiento no debería importar demasiado. ¿Cuál es la especificación de hardware subyacente en el sistema que ejecuta OpenSolaris? ¿Cuántos discos / husillos tienes? Cuanta RAM
ewwhite
12 discos repartidos en 2 grupos raidz1 en un controlador con 4 GB de RAM. Si el rendimiento no importa, ¿qué métrica debería tener en cuenta?
Sysadminicus
¿Qué hace cat / proc / mounts | grep solaris_server decir en el cliente de Linux? Las diferentes versiones de Linux tienen diferentes opciones de montaje predeterminadas :(
James
10.10.1.1:/tank/vm / vm nfs rw, vers = 3, rsize = 1048576, wsize = 1048576, hard, proto = tcp, timeo = 600, retrans = 2, sec = sys, addr = 10.10.1.1 0 0
Sysadminicus
Con algunas ediciones de Solaris 10, nfs3 era inestable. Si puede pasar a nfs4, puede ver algunas mejoras. Pero, como otros comentaristas han dicho, al ver 50MB / s a través de un enlace de GigE está cerca de la más alta que se puede ver
Warren

Respuestas:

2

Solo para aclarar, ¿está obteniendo 50 MB / seg con NFS a través de una sola conexión de Ethernet Gb?

¿Y el servidor host ejecuta CentOS con VMware Server instalado, que a su vez ejecuta las 7 VM? ¿Hay alguna razón en particular por la que haya optado por CentOS y VMware Server combinados, en lugar de VMware ESXi, que es una solución de mayor rendimiento?

Los 50 MB / seg no son geniales, pero no están muy por debajo de lo que esperarías de un solo cable de red de Gb: una vez que hayas introducido los ajustes de NFS que la gente ha mencionado anteriormente, verás quizás 70- 80MB / seg. Opciones a lo largo de la línea de:

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

son probablemente razonables para usted en ambos extremos del sistema.

Para superar eso, tendrá que considerar agrupar las tarjetas de red en pares, lo que debería aumentar su rendimiento en aproximadamente un 90%. Es posible que necesite un conmutador que admita 802.3ad para obtener el mejor rendimiento con la agregación de enlaces .

Sin embargo, una cosa que sugeriría es que su rendimiento de E / S en el cuadro de OpenSolaris suena sospechosamente alto, es probable que 12 discos no admitan 1,6 GB / seg de rendimiento, y que Solaris + ZFS puede almacenar mucho en caché.

Ewan Leith
fuente
Estamos usando CentOS + VMWare Server porque es gratis. La última vez que verifiqué que ESXi era bastante caro. Según / proc / mounts, el tamaño de rsize / wsize es actualmente 1048576. Solo para confirmar, ¿cree que reducirlos a 32k ayudará a aumentar la velocidad? Comprobaré la agregación de enlaces. ¿Haría esto en ambos extremos de la conexión o solo en uno? Creo que tienes razón acerca del almacenamiento en caché del IO. Subir mis dd's a más de 512 MB disminuye significativamente la velocidad de transferencia (que oscila entre 50-120 MB / s).
Sysadminicus
Ya no tengo la capacidad en la interfaz de usuario para aceptar una respuesta a esta pregunta, pero he votado a favor porque parece que la agregación de enlaces será mi mejor opción.
Sysadminicus
Disculpe la demora en la respuesta, ESXi ahora es gratuito en su forma básica y le dará un aumento de rendimiento, pero tiene una funcionalidad limitada, por lo que puede no ser adecuado para usted. Tendrá que hacer la agregación de enlaces en ambos extremos del enlace de red para ver una gran mejora. Espero que funcione para ti
Ewan Leith
1

Para nuestras máquinas RHEL / CentOS 5 utilizamos las siguientes banderas de montaje

nfsvers = 3, tcp, timeo = 600, retrans = 2, rsize = 32768, wsize = 32768, hard, intr, noatime

La versión más reciente del kernel de Linux admite parámetros rsize / wsize aún más grandes, pero 32k es el máximo para el kernel 2.6.18 en EL5.

En los servidores NFS, al menos para Linux no_wdelay supuestamente ayuda si tiene un controlador de disco con BBWC. Además, si usa el indicador noatime en los clientes, probablemente tenga sentido montar los sistemas de archivos en los servidores también con noatime.

Y, como ya se mencionó, no te molestes con UDP. Con redes de mayor velocidad (1GbE +) existe una pequeña, pero no nula, posibilidad de que un número de secuencia se ajuste y cause corrupción de datos. Además, si existe la posibilidad de pérdida de paquetes, TCP funcionará mejor que UDP.

Si no le preocupa tanto la integridad de los datos, la opción de exportación "asíncrona" puede ser una mejora importante en el rendimiento (el problema con la asíncrona es que podría perder datos si el servidor falla).

Además, al menos para el servidor Linux, debe asegurarse de tener suficientes subprocesos del servidor NFS en ejecución. El valor predeterminado 8 es demasiado bajo.

janneb
fuente
1

Una vez hice una prueba con un dell r710, 1 cpu, 4 GB de RAM, 6 discos SATA con RAID-10. El cliente era un sun x2100, ambos con CentOS 5.3 y los parámetros nfs como se mencionó anteriormente

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

montado en ambos lados con noatime.

También subí a nfsds a 256 y usé el programador noop para el controlador de incursión perc6. Otra cosa que hice fue alinear las particiones con el tamaño de banda de 64K del controlador de banda.

luego medí el rendimiento de nfs con dd: para las lecturas podría llenar el tubo gigE pero para las escrituras solo podría obtener resultados ligeramente mejores que usted. Con async habilitado pude obtener de 70 a 80 MB / s, pero async no era una opción para mi.

¿Tal vez no puedas obtener más con nfs desde un enlace gigE?


fuente
1

Pruebe esto: deshabilite el registro de intención de ZFS (ZIL) temporalmente en el servidor OpenSolaris NFS con los siguientes dos pasos

  1. echo zil_disable/W0t1 | mdb -kw
  2. vuelva a montar la partición de prueba

Luego prueba de nuevo. Puede usar zilstat para asegurarse de que realmente no haya más IO en el ZIL. Si la prueba se ejecuta más rápido, sabrá que el problema de rendimiento tiene algo que ver con el ZIL. Si todavía funciona lento, sabe que el ZIL no es el culpable y que usar un SSD para el ZIL tampoco ayudará. Consulte la Guía de ajuste de ZFS Evil para obtener más información sobre el ZIL.

Otra opción sería capturar el tráfico de red (por ejemplo, con Wireshark) y ver si hay algún problema, por ejemplo, con las tramas Jumbo. Verifique que los paquetes en el cable se vean como espera de su configuración. ¿Hay alguna mala fragmentación? ¿Hay retransmisiones?

Knweiss
fuente
0

Aumentar el tamaño de la carga útil de lectura y escritura puede ayudar. Especialmente en combinación con marcos jumbo.

Tiendo a encontrar 32k para ser óptimo.

rsize=32768,wsize=32768

Cambiar al transporte UDP es, por supuesto, más rápido que TCP, porque ahorra la sobrecarga del control de transmisión. Pero solo es aplicable en redes confiables y donde NFSv4 no está en uso.

Dan Carley
fuente
Parece que CentOS se está conectando usando NFSv3. ¿Hay valor en NFSv4 para nuestro caso de uso? Yo diría que la red es bastante confiable dado que solo hay un cable cruzado entre las dos NIC.
Sysadminicus
2
UDP realmente no vale la pena. Se adhieren a TCP. No recomendaría probar NFSv4 hasta que v3 funcione correctamente.
James
0

El rendimiento de NFS en ZFS mejora enormemente mediante el uso de un SSD para el registro de intenciones de ZFS (ZIL), ya que esto reduce la latencia de las operaciones. Este hilo sobre VMWare NFS en el rendimiento de ZFS en las listas de correo de OpenSolaris NFS y ZFS tiene más información, incluida una herramienta de referencia para ver si el rendimiento de ZIL es el cuello de botella.

TRS-80
fuente
0

FYI, el comando dd escribirá en la memoria caché y no en el disco, esto puede obtener números locos como 1.6G / s porque está escribiendo en RAM y no en disco en Solaris, puede usar "-oflag = sync" para forzar las escrituras en el disco

Kyle Hailey
fuente