Procedimientos recomendados de las opciones de montaje de NFS de Linux para Azure NetApp Files

Este artículo le ayudará a conocer mejor las opciones de montaje y los procedimientos recomendados para usarlas con Azure NetApp Files.

Nconnect

Utiliza la opción de montaje nconnect para especificar el número de conexiones (flujos de red) entre el cliente NFS y el punto final NFS, hasta 16. Tradicionalmente, un cliente NFS usa una única conexión entre él y el punto de conexión. Aumentar el número de flujos de red incrementa significativamente los límites superiores de E/S y de rendimiento. Para encontrar la configuración óptima para tu entorno específico, prueba varios ajustes para nconnect antes de poner tu aplicación en producción, si es posible. En la mayoría de los entornos, el resultado óptimo es nconnect=4.

Al preparar un entorno de SAS GRID de varios nodos para producción, es posible que observe una reducción repetible del 30 % en el tiempo de ejecución que va de 8 a 5,5 horas:

Opción de montaje Tiempos de ejecución del trabajo
No nconnect 8 horas
nconnect=8 5,5 horas

Ambos conjuntos de pruebas usaban la misma máquina virtual E32-8_v4 y RHEL8.3, con la lectura anticipada establecida en 15 MiB.

Cuando use nconnect, tenga en cuenta las siguientes reglas:

  • nconnect es compatible con Azure NetApp Files en todas las distribuciones principales de Linux, pero solo en las versiones más recientes:

    Versión de Linux NFSv3 (versión mínima) NFSv4.1 (versión mínima)
    Red Hat Enterprise Linux RHEL8.3 RHEL8.3
    SUSE SLES12SP4 o SLES15SP1 SLES15SP2
    Ubuntu Ubuntu18.04

    Nota

    SLES15SP2 es la versión mínima de SUSE en la que nconnect es compatible con Azure NetApp Files para NFSv4.1. Las restantes versiones especificadas son las primeras que introdujeron la característica nconnect.

  • Todos los montajes de un único punto de conexión heredarán el valor de nconnect de la primera exportación montada, como se muestra en los siguientes escenarios:

    Escenario 1: nconnect es usado por el primer punto de montaje. Por consiguiente, todos los montajes del mismo punto de conexión usan nconnect=8.

    • mount 10.10.10.10:/volume1 /mnt/volume1 -o nconnect=8
    • mount 10.10.10.10:/volume2 /mnt/volume2
    • mount 10.10.10.10:/volume3 /mnt/volume3

    Escenario 2: el primer montaje no usa nconnect. Por tanto, ninguno de los montajes del mismo punto de conexión usa nconnect, aunque se pueda especificar nconnect en él.

    • mount 10.10.10.10:/volume1 /mnt/volume1
    • mount 10.10.10.10:/volume2 /mnt/volume2 -o nconnect=8
    • mount 10.10.10.10:/volume3 /mnt/volume3 -o nconnect=8

    Escenario 3: la configuración de nconnect no se propaga entre puntos de conexión de almacenamiento independientes. nconnect lo usa el montaje procedente de 10.10.10.10, pero no el montaje procedente de 10.12.12.12.

    • mount 10.10.10.10:/volume1 /mnt/volume1 -o nconnect=8
    • mount 10.12.12.12:/volume2 /mnt/volume2

  • nconnect se puede usar para aumentar la simultaneidad de almacenamiento desde cualquier cliente dado.

Para más información, consulte el artículo sobre los procedimientos recomendados de concurrencia de Linux para Azure NetApp Files.

Nconnect consideraciones

No se recomienda utilizar las opciones de montaje nconnect y sec=krb5* de manera conjunta. El uso conjunto de estas opciones puede provocar una degradación del rendimiento.

La interfaz de programación de aplicaciones del estándar de seguridad genérico (GSS-API) proporciona una manera de que las aplicaciones protejan los datos enviados a aplicaciones del mismo nivel. Estos datos se pueden enviar desde un cliente de una máquina a un servidor en otro equipo. 

Cuando nconnect se usa en Linux, el contexto de seguridad de GSS se comparte entre todas las conexiones nconnect a un servidor determinado. TCP es un transporte confiable que admite la entrega de paquetes desordenados para tratar paquetes desordenados en un flujo GSS, mediante una ventana deslizante de números de secuencia. Cuando se reciben paquetes que no están en la ventana de secuencia, se descarta el contexto de seguridad y se negocia un nuevo contexto de seguridad. Todos los mensajes enviados con en el contexto ahora descartado ya no son válidos, por lo que es necesario volver a enviar los mensajes. Un mayor número de paquetes en una configuración de nconnect provoca frecuentes paquetes fuera de la ventana, desencadenando el comportamiento descrito. No se pueden indicar porcentajes de degradación específicos con este comportamiento.

Rsize y Wsize

En los ejemplos de esta sección, se proporciona información sobre cómo abordar el ajuste del rendimiento. Es posible que tenga que realizar ajustes para adaptarlos a las necesidades específicas de su aplicación.

Los indicadores rsize y wsize establecen el tamaño máximo de transferencia de una operación de NFS. Si rsize o wsize no se especifican al montar, el cliente y el servidor negocian el mayor tamaño que admiten ambos. Actualmente, tanto Azure NetApp Files como las distribuciones modernas de Linux admiten tamaños de lectura y escritura de hasta 1 048 576 bytes (1 MiB). Sin embargo, para obtener el mejor rendimiento general y latencia, Azure NetApp Files recomienda establecer tanto rsize como wsize con un valor no superior a 262 144 bytes (256 K). Si usa unos valores mayores de 256 KiB en rsize y wsize, es posible que observe una mayor latencia y un menor rendimiento.

Por ejemplo, en la implementación de un sistema de escalabilidad horizontal de SAP HANA con nodos en espera en máquinas virtuales de Azure mediante Azure NetApp Files en SUSE Linux Enterprise Server, se muestra el máximo de 256 KiB de rsize y wsize como se indica a continuación:

sudo vi /etc/fstab
# Add the following entries
10.23.1.5:/HN1-data-mnt00001 /hana/data/HN1/mnt00001  nfs rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.6:/HN1-data-mnt00002 /hana/data/HN1/mnt00002  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.4:/HN1-log-mnt00001 /hana/log/HN1/mnt00001  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.6:/HN1-log-mnt00002 /hana/log/HN1/mnt00002  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.4:/HN1-shared/shared /hana/shared  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0

Por ejemplo, SAS Viya recomienda un tamaño de lectura y escritura de 256 KiB, y SAS GRID limita el valor de r/wsize a 64 KiB, a la vez que aumenta el rendimiento de lectura con mayor lectura por adelantado para los montajes de NFS. Consulte más información en Procedimientos recomendados de lectura anticipada de NFS de Linux para Azure NetApp Files.

Las siguientes consideraciones son válidas para el uso de rsize y wsize:

  • Los tamaños de las operaciones de E/S aleatorias suelen ser menores que los valores especificados por las opciones de montaje rsize y wsize. Por lo tanto, no son restricciones.
  • Al usar la caché del sistema de archivos, se producirá una E/S secuencial en el tamaño determinado por las opciones de montaje rsize y wsize, salvo que el tamaño del archivo sea menor que rsize y wsize.
  • Las operaciones que omiten la caché del sistema de archivos, aunque estén restringidas por las opciones de montaje rsize y wsize, no son tan grandes como el máximo especificado por rsize o wsize. Esta consideración es importante cuando se usan generadores de cargas de trabajo que tienen la opción directio.

Como procedimiento recomendado con Azure NetApp Files, para obtener el mejor rendimiento general y latencia, es preciso que el valor de rsize y wsize no sea superior a 262 144 bytes.

Consistencia close-to-open y temporizadores de atributos de caché

NFS usa un modelo de coherencia flexible. La coherencia es flexible porque la aplicación no tiene que acceder al almacenamiento compartido y capturar datos cada vez para usarlos, una situación que tendría un impacto enorme en el rendimiento de la aplicación. Hay dos mecanismos que administran este proceso: los temporizadores de atributos de la caché y la coherencia casi abierta.

Si el cliente tiene la propiedad completa de los datos, es decir, no se comparte entre varios nodos o sistemas, la coherencia está garantizada. En ese caso, puede reducir las operaciones de acceso de getattr para almacenar y agilizar la aplicación mediante la desactivación de la coherencia casi abierta (cto) (nocto como opción de montaje) y la activación de los tiempos de expiración para la administración de la caché de atributos (actimeo=600 como opción de montaje cambia el temporizador a 10 m, frente a los valores predeterminados acregmin=3,acregmax=30,acdirmin=30,acdirmax=60). En algunas pruebas, nocto reduce aproximadamente entre el 65 y el 70 % de las llamadas de acceso de getattr, mientras que el ajuste de actimeo reduce estas llamadas otro 20 a 25 %.

Funcionamiento de los temporizadores de la caché de atributos

Los atributos acregmin, acregmax, acdirmin y acdirmax controlan la coherencia de la caché. Los dos primeros atributos controlan durante cuánto tiempo son de confianza los atributos de los archivos. Los dos últimos atributos controlan durante cuánto tiempo son de confianza los atributos del propio archivo de directorio (tamaño del directorio, propiedad del directorio y permisos de directorio). Los atributos min y max definen la duración mínima y máxima en la que los atributos de un directorio, los atributos de un archivo y el contenido de caché de un archivo se consideran de confianza, respectivamente. Entre min y max, se usa un algoritmo para definir la cantidad de tiempo durante el que se confía en una entrada almacenada en la caché.

Por ejemplo, considere los valores acregmin y acregmaxpredeterminados, 3 y 30 segundos, respectivamente. Por ejemplo, los atributos se evalúan repetidamente para los archivos de un directorio. 3 segundos después, se realiza una consulta del servicio NFS para comprobar su vigencia. Si los atributos se consideran válidos, el cliente duplica el tiempo fiable a 6 segundos, 12 segundos, 24 segundos y, luego, como el máximo está establecido en 30, a 30 segundos. A partir de ese momento, hasta que los atributos almacenados en caché se consideren obsoletos (momento en el que se inicia de nuevo el ciclo), la confiabilidad se define como el valor especificado por acregmax, es decir, 30 segundos.

Hay otros casos que pueden beneficiarse de un conjunto similar de opciones de montaje, incluso cuando no existe una propiedad total por parte de los clientes, por ejemplo, si los clientes usan los datos como de solo lectura y la actualización de datos se administra a través de otra ruta de acceso. En el caso de las aplicaciones que usan mallas de clientes como EDA, el hospedaje web y la representación de películas, y tienen conjuntos de datos relativamente estáticos (herramientas o bibliotecas EDA, contenido web, datos de texturas), el comportamiento típico es que el conjunto de datos se almacene principalmente en la caché de los clientes. Hay pocas lecturas y ninguna escritura. Hay muchas getattr o llamadas de acceso que volverán al almacenamiento. Estos conjuntos de datos normalmente se actualizan a través de otro cliente que monta los sistemas de archivos y envía periódicamente actualizaciones de contenido.

En estos casos, se produce un retraso conocido al detectar contenido nuevo y la aplicación sigue funcionando con datos potencialmente obsoletos. En estos casos, se pueden usar nocto y actimeo para controlar el período en el que se puede administrar la fecha en que empiezan a estar obsoletos. Por ejemplo, en las bibliotecas y herramientas de EDA, actimeo=600 funciona bien porque estos datos normalmente se actualizan con poca frecuencia. En el caso de un hospedaje web pequeño en el que los clientes necesitan ver las actualizaciones de manera puntual mientras editan sus sitios, actimeo=10 puede ser aceptable. En el caso de los sitios web a gran escala, en los que el contenido se inserta en varios sistemas de archivos, actimeo=60 puede ser aceptable.

El uso de estas opciones de montaje reduce significativamente la carga de trabajo del almacenamiento en estos casos (por ejemplo, una experiencia reciente de EDA redujo las E/S por segundo del volumen de las herramientas de >150 000 a aproximadamente 6000). Las aplicaciones se pueden ejecutar considerablemente más rápido porque pueden confiar en los datos que hay en la memoria. (el tiempo de acceso a la memoria se mide en nanosegundos, frente a cientos de microsegundos para getattr/acceso en una red rápida).

Coherencia casi abierta

La consistencia close-to-open (la opción de montaje cto) garantiza que, independientemente del estado de la caché, al abrir, los datos más recientes de un archivo siempre se presentan a la aplicación.

  • Cuando se rastrea un directorio (por ejemplo, ls o ls -l), se emite un número determinado de RPC (llamadas a procedimiento remoto). El servidor NFS comparte su vista del sistema de archivos. Mientras todos los clientes NFS que accedan a una exportación de NFS determinada usen cto, todos los clientes verán la misma lista de archivos y directorios en ella. La vigencia de los atributos de los archivos del directorio se controla mediante los temporizadores de la caché de atributos. En otras palabras, mientras se utilice cto, los archivos aparecen en los clientes remotos en cuanto se crea el archivo y el archivo llega al almacenamiento.
  • Cuando se abre un archivo, se garantiza que el contenido del archivo está actualizado desde la perspectiva del servidor NFS. Si hay una condición de carrera en la que el contenido no ha terminado de volcarse desde la máquina 1 cuando se abre un archivo en la máquina 2, la máquina 2 solo recibirá los datos presentes en el servidor en el momento de la apertura. En este caso, la máquina 2 no recupera más datos del archivo hasta que se alcance el temporizador acreg y la máquina 2 vuelve a comprobar la coherencia de su caché desde el servidor. Para observar este escenario se puede usar tail -f desde la máquina 2 cuando el archivo todavía se escribe desde la máquina 1.

No hay coherencia casi abierta

Cuando no se usa la consistencia close-to-open (nocto), el cliente confiará en la vigencia de su vista actual del archivo y del directorio hasta que hayan expirado los temporizadores de atributos de la caché.

  • Cuando se rastrea un directorio (por ejemplo, ls o ls -l), se emite un número determinado de RPC (llamadas a procedimiento remoto). El cliente solo emite una llamada al servidor para obtener una lista de archivos actual cuando se haya infringido el valor del temporizador de la caché acdir. En este caso, los archivos y directorios creados recientemente no aparecen. Aparecen archivos y directorios eliminados recientemente.

  • Cuando se abre un archivo, si todavía esta en la caché, se devuelve su contenido almacenado en la caché (si existe) sin validar la coherencia con el servidor NFS.

Siguientes pasos

  • Se actualizó por última vez el