Optimiza el rendimiento de NFS

En mi web personal ya os he hablado del sistema de ficheros en red NFS. En el artículo de hoy veremos cómo optimizar su rendimiento. Es el resultado de mi experiencia de años, más información muy valiosa que he ido encontrando en la red de redes.

Optimiza el rendimiento de NFS

He dividido el artículo en apartados para que se más legible. Son una de serie modificaciones y mejoras que pueden hacer que los recursos NFS funcionen mejor y de manera más eficiente.

Modificar el tamaño de los bloques

Debemos sincronizar la configuración, tanto del servidor NFS como del cliente. Ambos son muy importantes, ya que son los que participan en esta comunicación de sistema de archivos en red. Comencemos con algunas opciones de comandos de montaje. Se pueden utilizar para ajustar el rendimiento de NFS, principalmente desde el lado del cliente.

La cantidad y el tamaño de los datos que utilizan servidor y cliente , para pasar los datos entre ellos, es muy importante. La mayoría de las versiones NFS tienen un valor predeterminado para esta configuración. Sin embargo, siempre se pueden ajustar estos valores para satisfacer nuestras necesidades.

Indiquemos los parámetros por defecto:

rw – Indica que el sistema de archivos está montado en modo de lectura / escritura.

vers = 3 Esto significa que estamos utilizando NFS versión 3 para este montaje.

rsize = 32768 & wsize = 32768 Especifica el tamaño del fragmento de datos que cada paquete RPC toma durante la lectura y escritura. Sintonizarlos aumentará el rendimiento a veces pero, en otras ocasiones, también puede reducirlo.

Dichos parámetros se pueden averiguar escribiendo cat /proc/mounts

Sintonizar rsize & wsize siempre debe hacerse manteniendo la capacidad de nuestra red, así como el poder de procesamiento y rendimiento del cliente y del servidor. Así que, digamos que hemos ha decidido disminuir el tamaño de rsize & wsize en su montaje. Disminuir el tamaño de lectura y escritura en paquetes RPC aumentará el número total de paquetes IP de red que necesitan ser enviados a través de la red.

Lo que significa que, si tenemos 1 MB de datos, dividirlo en trozos iguales de 32KB aumentará el número de trozos y, si lo dividimos en trozos iguales de 64KB, el número de trozos se reducirá. Lo que significa que es necesario enviar un gran número de paquetes IP a través de la red si se disminuyen estos valores y, si se aumentan, tendremos que enviar un número menor de paquetes IP a través de la red.

Así que nuestra decisión sobre la modificación de este parámetro siempre debe depender de la capacidad de la red. Si tenemos 1 puerto Gigabit en nuestro servidor NFS y cliente, y los switches de red que conectan estos servidores también son capaces de manejar puertos 1G, entonces yo sugeriría ajustar estos parámetros a un valor más alto.

Se pueden modificar fácilmente como indico a continuación:

mount 192.168.x.x:/data / mnt -o rsize = 65536, wsize = 65536

Se pueden modificar también en el fichero /etc/fstab.

La mejor manera es modificarlo y realizar pruebas de rendimiento.

Consultar estas URL para saber cómo hacerlo:

(http://www.slashroot.in/how-do-linux-nfs-performance-tuning-and-optimization)

(http://www.tldp.org/HOWTO/NFS-HOWTO/performance.htmll)

Por ejemplo:

time dd if=/dev/zero of=/mnt/home/testfile bs=16K count=16834

Modificar el tamaño de MTU para NFS

MTU nos indica la Unidad de Transmisión Máxima. Se trata de la cantidad de datos más alta que se puede pasar por la trama de Ethernet. Por norma general el valor predeterminado es 1500 bytes.

Para averiguar cuál es esta cantidad podemos ejecutar el siguiente comando:

netstat –i

También se puede obtener utilizando el comando

ifconfig

Si, por ejemplo, tenemos configurados los valores rsize y wsize en 8KB y estamos utilizando el valor MTU por defecto de 1500 bytes, los datos seguirán estando fragmentados mientras se envían a 1500 bytes.

Si modificamos el valor MTU a 9000 bytes, se moverá a 8 KB, por ser lo que hemos establecido en rsize y wsize, y el valor MTU es superior. Para que funcionen correctamente estos valores deben estar indicados en el servidor NFS y en el cliente.

Este valor se puede implementar en la tarjeta de red apropiada añadiendo “MTU = 9000”, por ejemplo, en /etc/sysconfig/network-scripts/ifcfg-eth0, en la mayoría de los casos.

También se puede modificar utilizando ifconfig, como hemos comentado antes.

ifconfig eth0 mtu 9000 up

Modificar MTU es delicado. Cambiar su tamaño es arriesgado en redes de producción, porque puede afectar a las aplicaciones en ejecución. Además, algunos ISP no aceptan marcos más grandes que su tamaño especificado de MTU.

Optimización de «timeo» y «retrans» en NFS

Las dos opciones tratadas hasta ahora afectan al número de intentos realizados por el cliente al servidor en caso de una respuesta retardada del servidor o, incluso, de ninguna respuesta del servidor.

La opción de “timeo” en NFS decide el tiempo que el cliente necesita esperar antes de llegar a la conclusión de que debe retransmitir el paquete. El valor predeterminado es 0.7 (se calcula en la décima parte de un segundo por lo que, si se da un valor de 5, significará que el cliente esperará de 5 a 10 segundos antes de decidir que necesita volver a enviar el paquete).

La segunda opción, “retrans”, decide el número total de intentos realizados por el cliente en caso de que obtenga un tiempo de respuesta indicado con “timeo”.

Esto es, si devuelve el valor de “retrans” como 3, el cliente reenviará el paquete RPC tres veces y esperará los segundos indicados en “timeo”. Si falla las tres veces, devolverá el mensaje “Server not responding”. Después de esto, el contador se restablece y seguirá intentando realizar el envío.

Se pueden modificar ambos valores de la siguiente manera, en el caso de haber hecho el montaje desde la consola:

mount 192.168.x.x:/data /mnt -o timeo=5,retrans=4

Si queremos saber la configuración actual podemos utilizar el comando nfssat para la retransmisión de paquetes.

Un ejemplo, con el resultado:

[root@davidhost~]# nfsstat -r

Client rpc stats:

calls      retrans    authrefrsh

161591940   84        161591986

Número de «Threads»

Un valor importante a tener en cuenta al trabajar con NFS es el número de “hilos” (en inglés “threads”) disponibles. Si tenemos un gran número de clientes lo ideal es aumentar el número.

Podemos saber el número actual escribiendo:

ps aux | grep nfs

Por defecto este valor es 8 en el servidor NFS. Se puede modificar en el servidor, en la ruta /etc/sysconfig/nfs, cambiando el valor “RPCNFSDCOUNT = 16”. Haciéndolo así, cambiamos el valor predeterminado de 8 a 16. Recuerda que, para que el cambio sea efectivo, se tiene que reiniciar el servicio NFS.

Valores «async» y «sync»

Ambos valores son los que determinan cómo se describen los datos en el servidor en una solicitud del cliente. Ambos tienen sus propias ventajas y desventajas.

Cualquier cosa que se haga en un cliente NFS se convierte en una operación RPC equivalente, de modo que se puede enviar al servidor mediante el protocolo RPC. Por lo tanto, si estamos utilizando la opción asíncrona en NFS, cuando el servidor recupera una operación RPC para escribir, primero convierte esa operación en una operación VFS (Virtual File System) para escribir los datos en el sistema de disco subyacente.

Tan pronto como el controlador VFS maneja la operación de escritura en el disco subyacente, incluso antes de obtener el reconocimiento de que se ha completado la operación de escritura, el servidor está listo para aceptar más operaciones de escritura RPC. En este caso, el servidor NFS aumenta el rendimiento de escritura al reducir el tiempo necesario para completar esa misma operación.

Pero este método a veces puede causar pérdida de datos y corrupción. Esto se debe a lo que hemos comentado: el servidor NFS comienza a aceptar más operaciones de escritura antes de que el sistema de disco subyacente haya terminado de hacer su trabajo.

El uso de la opción de sincronización hará lo contrario. En este caso, el servidor responderá sólo después de que una operación de escritura se haya completado satisfactoriamente (lo que significa que solo continuará después de que los datos estén completamente escritos en el disco).

Si estamos tratando con datos críticos nunca deberíamos utilizar la opción asíncrona. Sin embargo, la forma asíncrona es una buena opción si los datos no son críticos.

Desde la consola:

mount 192.168.x.x:/data / mnt -o rw, async

Y en /etc/fstab

192.168.x.x:/data  /mnt  nfs  rw,async   0   0

Valores «input» y «output» en la cola del Socket

La transferencia de archivos grandes a través de la red requiere mucha memoria en el servidor, así como en el cliente. Sin embargo, los sistemas GNU Linux, por defecto, nunca asignan una gran cantidad de memoria para este propósito, ya que requieren memoria para otras aplicaciones.

Se puede ajustar y asignar más memoria si tenemos entradas y salidas muy pesadas.

Para ajustarlo, el primero parámetro es la cola de entrada del socket y la otra es la cola de salida. La cola de entrada es el lugar donde las solicitudes deben ser procesadas.

Ya hemos visto en los puntos anteriores que el aumento del número de subprocesos (hilos) del servidor NFS puede mejorar el rendimiento. Imaginemos que tenemos 16 subprocesos en nuestro servidor y que cada uno procesa solicitudes de clientes independientes. Están utilizando la misma entrada de socket y la misma cola de salida, lo que significa que, si tenemos un tamaño de cola de entrada y de salida más alto, todos los subprocesos pueden enviar y recibir datos de forma más efectiva.

Se pueden modificar estos valores modificando el archivo sysctl.conf.

También se puede modificar la cola de salida modificando los valores de vmem_default y wmem_max.

Un ejemplo:

echo 'net.core.wmem_max=219136' >> /etc/sysctl.conf
echo 'net.core.rmem_max=219136'>> /etc/sysctl.conf

Configuración de disco subyacente en el servidor NFS

La configuración y creación del disco subyacente, que se expone como un recurso compartido NFS en el servidor, desempeña un papel importante en el rendimiento. Si tenemos el recurso compartido NFS en una matriz RAID, entonces podemos mejorar el rendimiento de lectura y escritura dependiendo del nivel de raid configurado.

La mejor opción suele ser RAID 10 pero es bastante costosa, debido al número de discos usados.

Fuentes a consultar:

http://www.slashroot.in/how-do-linux-nfs-performance-tuning-and-optimization
http://docs.oracle.com/cd/E19620-01/805-4448/6j47cnj0i/index.html

Fuente de la imagen:

Autor: airpix, para Flickr  (El autor indica que nos estará agradecido si incluimos un enlace de acreditación de su imagen a aboblist.com, así que lo hacemos. Sin embargo, Colaboratorio no está de acuerdo necesariamente con los contenidos mostrado en ese sitio).