Opciones de montaje y configuraciones de máquina virtual cliente

Completado

En este módulo, se describirán las opciones de montaje y las configuraciones de máquina virtual cliente que mejoran el rendimiento al ejecutar aplicaciones de HPC o EDA en Azure NetApp Files.

Nota:

Los procedimientos recomendados para clientes NFS dependen de las aplicaciones que se usen. Las sugerencias siguientes no son absolutas y se pueden invalidar mediante recomendaciones de aplicaciones o pruebas de carga de trabajo. Se recomienda encarecidamente probar estos procedimientos antes de implementarlos en producción.

Uso de las opciones de montaje actimeo y nocto para mejorar el rendimiento

Puede usar las opciones de montaje siguientes para mejorar el rendimiento en conjuntos de datos relativamente estáticos y escenarios de lectura masiva:

• actimeo: controla los atributos de caché del cliente NFS de un directorio. Si no lo especifica, el cliente NFS usa un máximo predeterminado de 60 segundos.
• nocto: significa "no cerrar para abrir", lo que implica que un archivo se puede cerrar antes de que haya terminado una operación de escritura para ahorrar tiempo. De manera predeterminada, nocto no se establece en las opciones de montaje de NFS. Esto significa que todos los archivos esperarán a que finalicen las operaciones de escritura antes de permitir un cierre.

La mayoría de las aplicaciones de HPC, entre ellas EDA en nuestro escenario, tienen conjuntos de datos relativamente estáticos (lo que significa que los datos no cambian con frecuencia). En ese caso, se pueden usar nocto y actimeo para reducir las operaciones getattr o de acceso para almacenar, lo que puede ayudar a acelerar la aplicación.

Por ejemplo, se recomienda establecer "nocto,actimeo=600" (600 segundos o 10 minutos) para los volúmenes de biblioteca y herramientas de EDA. Como esos archivos no cambian, no hay ninguna coherencia de caché que mantener. Al establecer esas opciones de montaje, se reducen las llamadas a metadatos, lo que mejora el rendimiento general.

Ajuste de los parámetros del sistema para conseguir un rendimiento óptimo

Tuned es un demonio que se puede usar para supervisar y configurar dispositivos conectados en clientes Linux. En la mayoría de los casos, tuned se instala de manera predeterminada. Si no está instalado, se puede agregar y habilitar para simplificar los parámetros de ajuste del lado cliente con plantillas predeterminadas integradas.

Ejecute los comandos siguientes para aplicar el ajuste básico del servidor y el ajuste de latencia típico para las máquinas virtuales cliente:

sudo systemctl enable --now tuned
sudo tuned-adm profile latency-performance

Es posible que algunos o todos los parámetros del sistema siguientes (/etc/sysctl.conf) sean útiles en las máquinas virtuales cliente Linux para conseguir un rendimiento óptimo. Si tiene máquinas virtuales cliente con grandes cantidades de RAM o un mayor ancho de banda de red, como InfiniBand, es posible que quiera establecer algunos valores incluso más altos que los que se muestran en el ejemplo siguiente.

#
# Recommended client tuning 
#
# For more information, see sysctl.conf(5) and sysctl.d(5)
# Network parameters, in units of bytes
net.core.wmem_max = 16777216
net.core.wmem_default = 1048576
net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.ipv4.tcp_rmem = 1048576 8388608 16777216
net.ipv4.tcp_wmem = 1048576 8388608 16777216
net.core.optmem_max = 2048000
net.core.somaxconn = 65535
#
# These settings are in 4-KiB chunks, in bytes:
# Min=16MiB, Def=350MiB, Max=16GiB
# In units of 4K pages
net.ipv4.tcp_mem = 4096 89600 4194304
#
# Miscellaneous network options and flags
#
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_sack = 1
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.route.flush = 1
net.ipv4.tcp_low_latency = 1
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_slow_start_after_idle = 0
net.core.netdev_max_backlog = 300000
#
# Various file system and page cache options
#
vm.dirty_expire_centisecs = 100
vm.dirty_writeback_centisecs = 100
vm.dirty_ratio = 20
vm.dirty_background_ratio = 5
#
# Recommended by: https://cromwell-intl.com/open-source/performance-tuning/tcp.html
#
net.ipv4.tcp_sack = 0
net.ipv4.tcp_dsack = 0
net.ipv4.tcp_fack = 0

Para que estos ajustes sean persistentes, ejecute lo siguiente:

sudo sysctl -P

Uso de la opción de montaje nconnect para expandir las conexiones de red cuando proceda

La opción de montaje de NFS nconnect ha especificado la disponibilidad general en el kernel 5.3 o posterior de Linux. Para comprobar el kernel de Linux de la máquina virtual cliente, ejecute lo siguiente:

uname -r

El propósito de nconnect es proporcionar varias conexiones de transporte por conexión TCP o puntos de montaje en un cliente. Esto ayuda a aumentar el paralelismo y el rendimiento de los montajes NFS.

A menor número de clientes, más valor proporciona nconnect para ayudar a mejorar el rendimiento, ya que puede utilizar potencialmente todo el ancho de banda de la red disponible. Su valor disminuye gradualmente cuando aumenta el número de clientes; solo hay una cierta cantidad de ancho de banda en total para distribuir, y el número máximo de conexiones TCP puede agotarse más rápidamente, lo que puede dar lugar a una denegación de servicio hasta que se liberen las conexiones TCP.

Dado que Azure NetApp Files permite un máximo de 128 solicitudes simultáneas en curso por conexión TCP antes de que se produzca una limitación (donde se ponen en cola nuevas solicitudes hasta que los recursos estén disponibles), nconnect puede ayudar a ampliar el número de solicitudes en curso permitidas al aumentar las conexiones TCP disponibles por punto de montaje. Por ejemplo, si nconnect se establece para usar ocho conexiones TCP, las solicitudes 1024 (8x128) pueden estar disponibles para el cliente.

Los clientes Linux modernos permiten hasta 65 535 solicitudes por conexión (un valor dinámico). Esto puede sobrecargar potencialmente la cola de solicitudes en curso disponibles de un volumen de Azure NetApp Files y provocar resultados de rendimiento no deseados, en los que los clientes envían más solicitudes de las que se pueden atender en un momento dado. Para reducir el riesgo de impacto en el rendimiento debido a este comportamiento, considere establecer sunrpc.tpc_max_slot_table_entries=256 o 512 si está usando nconnect=8 o 16 a un valor estático inferior. Usa esta tabla como guía.

Nota:

Los distintos tipos de sistema operativo del cliente Linux pueden tener métodos diferentes para establecer este valor. Consulte la documentación del sistema operativo para obtener más información.

Valor de nconnect	Entradas máximas recomendadas de tabla de ranuras TCP
0-1	128
entre 2 y 4	256
Entre 6 y 8	512
>8	No se requieren cambios

Nota:

La opción nconnect solo está disponible para máquinas virtuales del kernel 5.3 o posterior de Linux. Es posible que tenga que reiniciar la máquina virtual al actualizar el kernel. Esto significa que podría no ser aplicable en algunos casos.

Uso de NFSv3 en lugar de NFSv4.1 cuando solo se tiene en cuenta el rendimiento

NFSv3 es un protocolo sin estado, lo que significa que el cliente y el servidor no se comunican entre sí sobre los archivos en uso. Network Lock Manager (NLM) realiza el bloqueo fuera de la pila de protocolos, lo que plantea algunos desafíos cuando los bloqueos se vuelven obsoletos y deben limpiarse manualmente. Los bloqueos solo se establecen a petición de la aplicación, por lo que puede haber escenarios en los que no sea necesario negociar los bloqueos. Dado que no hay id. de cliente, id. de estado, id. de sesión, estados de bloqueo, etc. para realizar un seguimiento, NFSv3 tiende a funcionar un poco mejor que NFSv4.1 en algunas cargas de trabajo, especialmente en cargas de trabajo con un elevado número de archivos o metadatos, como EDA y el desarrollo de software.

NFSv4.1 realiza un seguimiento de los estados de los archivos, incluidos los bloqueos. Cuando se usan muchos archivos a la vez en NFSv4.1, a cada archivo se le asigna un id. de estado y recibe un bloqueo. Al ser con estado añade sobrecarga al rendimiento de la carga de trabajo, ya que el servidor NFS debe procesar cada estado y bloqueo. En algunas cargas de trabajo (como EDA), el rendimiento de NFSv4.1 puede verse afectado entre un 25 % y un 75 %. Otras cargas de trabajo, como archivos grandes, E/S de streaming o bases de datos, no ven la degradación del rendimiento al usar NFSv4.1 e incluso pueden beneficiarse de las operaciones compuestas que usa el protocolo.

Azure NetApp Files admite NFSv3 y NFSv4.1. Debe validar qué versión requiere su aplicación comparando las similitudes y diferencias entre las versiones NFS (así como realizando pruebas) y creando su volumen usando la versión apropiada. Si es necesario, los volúmenes de Azure NetApp Files se pueden configurar en una versión de protocolo diferente después de la creación.

Elija los valores adecuados para las opciones de montaje rsize y wsize

Las opciones de montaje rsize (tamaño de lectura) y wsize (tamaño de escritura) determinan la cantidad de datos que se envían entre el servidor y el cliente NFS para cada paquete enviado. Por ejemplo, establecer rsize o wsize en 65 536 significa que se pueden enviar hasta 64 K de datos por paquete. Si una aplicación envía datos en fragmentos más pequeños (como 8 K), la cantidad de datos enviados depende de las opciones de montaje usadas (como sync).

El procedimiento recomendado para Azure NetApp Files consiste en establecer rsize y wsize en el mismo valor. Por lo general, se recomienda establecer los valores rsize y wsize como 262144 (256 K) en las opciones de montaje.

Comprender las opciones de montaje sincrónico y asíncrono

Si se usa sync, cada llamada WRITE se envía con un comando FILE_SYNC. Esto significa que el servidor debe confirmar cada WRITE y confirmarse en el disco antes de que pueda producirse el siguiente WRITE. Sync se usa cuando una aplicación debe garantizar que todos los datos se confirman en el disco. Las llamadas WRITE envían solo la cantidad de datos especificados por el tamaño de bloque de la aplicación, lo que significa que los tamaños de bloque más pequeños generan más tráfico NFS independientemente de los valores wsize y rsize del montaje, lo que provoca un impacto en el rendimiento.

Si usa la operación de montaje async (predeterminada), un cliente puede enviar varias llamadas WRITE a través de NFS con el comando UNSTABLE. En este escenario, los datos se vacían en el disco después de un período de tiempo de espera. Dado que el cliente NFS no siempre está esperando a que el servidor confirme los datos en el disco antes de iniciar la operación WRITE siguiente, los tiempos de finalización del trabajo para las escrituras en montajes asincrónicos son mucho menores que con sincronización. Cuando se usan tamaños de bloque más pequeños con valores de rsize y wsize mayores, las llamadas WRITE envían tantos datos como se permiten en una sola llamada NFS. Por ejemplo, si se usan tamaños de bloque de 8 K con un wsize/rsize de 64 K, cada llamada NFS WRITE envía ocho bloques por paquete (64 K/8 K). Cuando la escritura se vacía en el disco, el servidor NFS envía una respuesta FILE_SYNC al cliente NFS. Esto reduce el número total de llamadas y respuestas WRITE a través de una red necesaria para completar un trabajo, lo que mejora el rendimiento.

Por ejemplo, en una prueba en la que se creó un archivo de 1 GiB con un tamaño de bloque de 8 K se generaron 262 144 llamadas y respuestas WRITE y finalizó en 70 segundos al usar la opción de montaje sync. La misma creación de archivos con un tamaño de bloque de 8 K y la opción de montaje async envió solo 16 384 llamadas y respuestas WRITE, y se completó en seis segundos.

Azure NetApp Files usa el almacenamiento NVRAM protegido por una batería como caché del búfer para las escrituras NFS entrantes. Los datos de NVRAM se vacían en el disco cada 10 segundos o hasta que se rellena la caché del búfer (lo que ocurra primero). Dado que NVRAM está protegido por una batería, puede sobrevivir a interrupciones inesperadas durante un mínimo de 72 horas conservando los datos, como en el improbable caso de que un centro de datos Azure se quede sin electricidad. La combinación de la resistencia de datos de Azure NetApp Files y el impacto en el rendimiento del uso de la opción de montaje sync hace que la opción asincrónico sea la preferida en casi todos los casos de uso.

Comprender el impacto de los valores de wsize y rsize

Al montar a través de NFS, los valores de wsize y rsize determinan la cantidad de datos que se pueden enviar por llamada NFS a un servidor NFS. Si no se especifican en las opciones de montaje, los valores se establecen según lo que esté configurado en el servidor NFS. Azure NetApp Files usa un tamaño máximo de transferencia para wsize y rsize de 1 MB (1048576). Este valor no se puede cambiar en Azure NetApp Files. Esto significa que si los montajes NFS no especifican los valores wsize y rsize, los montajes tienen como valor predeterminado 1 MB. Los valores recomendados wsize y rsize para los montajes NFS en cargas de trabajo EDA son 256 K.

Si una aplicación necesita crear un archivo de 1 GiB en un montaje NFS de Azure NetApp Files, debe escribir 1 048 576 KiB en el almacenamiento. Un ejercicio matemático puede mostrar por qué el rendimiento puede mejorar con valores wsize o rsize más eficaces.

• Si wsize se establece en 64 K, el número de operaciones y paquetes necesarios para escribir el archivo de 1 GiB es 1 048 576/64=16 384.
• Si wsize se establece en 256 K, el número de operaciones y paquetes necesarios para escribir el archivo de 1 GiB es 1 048 576/256=4096.

Menos paquetes/operaciones significa menos impacto de latencia de red (que afecta al RTT) en las cargas de trabajo, lo que puede ser crítico en las implementaciones en la nube. Sin embargo, si la aplicación escribe archivos que son más pequeños que los valores wsize/rsize, los valores más elevados de wsize/rsize no tienen ningún efecto en el rendimiento.

Los fragmentos más grandes de datos significan más ciclos de procesamiento en el cliente y el servidor, pero la mayoría de las CPU modernas están lo suficientemente equipadas para controlar esas solicitudes de forma eficaz.

El procedimiento recomendado para Azure NetApp Files consiste en establecer rsize y wsize en el mismo valor. Se recomienda establecer los valores rsize y wsize en 262 144 (256 K) en las opciones de montaje. Esta configuración abarca una matriz de valores de tamaño de lectura y escritura de la aplicación.

Elección de la configuración adecuada para las opciones de montaje hard, soft e intr

Las opciones de montaje hard y soft especifican si el programa que usa un archivo en el que se utiliza NFS debe realizar una de las acciones siguientes:

• Detenerse y esperar (hard) a que el servidor vuelva a estar en línea si el servidor NFS no está disponible. Esta opción aparece como un bloqueo de montaje en el cliente, pero garantiza que las operaciones en curso no se pierdan en caso de interrupciones de red. En su lugar, el cliente continúa reintentando la solicitud hasta que el servidor esté disponible o hasta que se agote el tiempo de espera de la aplicación.
• Notificar un error (soft). Los montajes no se bloquean, pero es posible que se pierdan las operaciones en curso.

La opción de montaje intr permite interrumpir los procesos NFS cuando se especifica un montaje como hard (por ejemplo, CTRL+C). Se recomienda usar intr con montajes hard cuando sea aplicable para obtener la mejor combinación de confiabilidad y manejabilidad de los datos.

No tener en cuenta ningún cambio en las MMT

Las unidades de transmisión máximas (MMT) predeterminadas para las máquinas virtuales de Azure son de 1500 bytes. No se recomienda a los clientes aumentar las MTU de máquina virtual para tramas gigantes.

Ejemplo de montaje

El código de ejemplo siguiente montaría un volumen de Azure NetApp Files mediante los procedimientos recomendados anteriores para actimeo, nocto, NFSv3, nconnect, rsize, wsize, hard, intr, tcp y las MMT predeterminadas (1500):

sudo mount -t nfs -o rw,nconnect=16,nocto,actimeo=600,hard,intr,rsize=262144,wsize=262144,vers=3,tcp 10.1.x.x:/ultravol ultravol

Nota:

Async no se especifica, ya que los montajes NFS son async de manera predeterminada.