Mejora del rendimiento del recurso compartido de archivos NFS de Azure

En este artículo se explica cómo puede mejorar el rendimiento de los archivos compartidos de NFS de Azure.

Se aplica a

Tipo de recurso compartido de archivos	SMB	NFS
Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS
Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS
Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS

Aumento del tamaño de la lectura anticipada para mejorar el rendimiento de lectura

El parámetro del kernel read_ahead_kb en Linux representa la cantidad de datos que deben "leerse de forma anticipada" o capturarse previamente durante una operación de lectura secuencial. Las versiones del kernel de Linux anteriores a la versión 5.4 establecen el valor de la lectura anticipada en el equivalente de 15 veces el valor de rsize del sistema de archivos montado (la opción de montaje del lado cliente para el tamaño del búfer de lectura). Esto establece el valor de lectura anticipada lo suficientemente alto como para mejorar el rendimiento de lectura secuencial del cliente en la mayoría de los casos.

Sin embargo, a partir de la versión 5.4 del kernel de Linux, el cliente NFS de Linux usa un valor predeterminado de read_ahead_kb de 128 KiB. Este valor pequeño puede reducir la cantidad de rendimiento de lectura para archivos grandes. Los clientes que actualizan desde versiones de Linux con un mayor valor de lectura anticipada en comparación con los que tienen el valor predeterminado de 128 KiB podrían experimentar una disminución en el rendimiento de lectura secuencial.

En el caso de los kernels de Linux 5.4 o posteriores, se recomienda establecer de forma persistente el valor de read_ahead_kb en 15 MiB para mejorar el rendimiento.

Para cambiar este valor, establezca el tamaño de lectura anticipada agregando una regla en udev, un administrador de dispositivos del kernel de Linux. Siga estos pasos:

1. En un editor de texto, cree el archivo /etc/udev/rules.d/99-nfs.rules escribiendo y guardando el texto siguiente:

   SUBSYSTEM=="bdi" \
   , ACTION=="add" \
   , PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi) {ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
   , ATTR{read_ahead_kb}="15360"
   

2. En una consola, aplique la regla udev ejecutando el comando udevadm como superusuario y vuelva a cargar los archivos de reglas y otras bases de datos. Solo tiene que ejecutar este comando una vez para que udev sea consciente del nuevo archivo.

   sudo udevadm control --reload
   

Nconnect

Nconnect es una opción de montaje de Linux del lado cliente que aumenta el rendimiento a escala al permitirle usar más conexiones TCP entre el cliente y el servicio Azure Premium Files para NFSv4.1, a la vez que mantiene la resistencia de la plataforma como servicio (PaaS).

Ventajas de nconnect

Con nconnect, puede aumentar el rendimiento a escala mediante menos máquinas cliente para reducir el costo total de propiedad (TCO). Nconnect aumenta el rendimiento mediante el uso de varios canales TCP en una o varias NIC, mediante uno o varios clientes. Sin nconnect, necesitaría aproximadamente 20 máquinas cliente para lograr los límites de escala de ancho de banda (10 GiB/s) ofrecidos por el mayor tamaño de aprovisionamiento de recursos compartidos de archivos premium de Azure. Con nconnect, puede lograr esos límites usando solo de 6 a 7 clientes. Esa es casi una reducción del 70 % en el costo informático, al tiempo que proporciona mejoras significativas en la IOPS y el rendimiento a escala (consulte la tabla).

Métrica (operación)	Tamaño de E/S	Mejora del rendimiento
IOPS (escritura)	64K, 1024K	3x
IOPS (lectura)	Todos los tamaños de E/S	2-4x
Rendimiento (escritura)	64K, 1024K	3x
Rendimiento (lectura)	Todos los tamaños de E/S	2-4x

Requisitos previos

• Las distribuciones de Linux más recientes son totalmente compatibles con nconnect. En el caso de las distribuciones anteriores de Linux, asegúrese de que la versión del kernel de Linux es 5.3 o posterior.
• La configuración por montaje solo se admite cuando se usa un único recurso compartido de archivos por cuenta de almacenamiento a través de un punto de conexión privado.

Impacto en el rendimiento de nconnect

Hemos logrado los siguientes resultados de rendimiento al usar la nconnect opción de montaje con recursos compartidos de archivos NFS de Azure en clientes Linux a gran escala. Para obtener más información sobre cómo logramos estos resultados, consulte Configuración de pruebas de rendimiento.

Recomendaciones para nconnect

Siga estas recomendaciones para obtener los mejores resultados de nconnect.

Establezcanconnect=4.

Aunque Azure Files admite la configuración nconnect hasta el máximo de 16, se recomienda configurar las opciones de montaje con el valor óptimo de nconnect=4. Actualmente, no hay ganancias más allá de cuatro canales para la implementación de Azure Files de nconnect. De hecho, superar cuatro canales en un único recurso compartido de archivos de Azure de un solo cliente podría afectar negativamente al rendimiento debido a la saturación de la red TCP.

Ajustar el tamaño de las máquinas virtuales cuidadosamente

En función de los requisitos de la carga de trabajo, es importante ajustar correctamente el tamaño de las máquinas cliente para evitar que se vean limitados por el ancho de banda de red esperado. No necesita varias NIC para lograr el rendimiento de red esperado. Aunque es habitual usar máquinas virtuales de uso general con Azure Files, hay varios tipos de máquinas virtuales disponibles en función de las necesidades de la carga de trabajo y la disponibilidad de las regiones. Para más información, consulte Selector de máquinas virtuales de Azure.

Mantener la profundidad de la cola menor o igual que 64

La profundidad de la cola es el número de solicitudes de E/S pendientes que un recurso de almacenamiento puede atender. No se recomienda superar la profundidad óptima de la cola de 64. Si lo hace, no verá más mejoras de rendimiento. Para obtener más información, vea Profundidad de la cola.

Nconnect configuración por montaje

Si una carga de trabajo requiere montar varios recursos compartidos con una o varias cuentas de almacenamiento con una configuración de nconnect diferente de un solo cliente, no podemos garantizar que esa configuración persista al montarse a través del punto de conexión público. La configuración por montaje solo se admite cuando se usa un único recurso compartido de archivos de Azure por cuenta de almacenamiento a través del punto de conexión privado, como se describe en Escenario 1.

Escenario 1: configuración de nconnect por montaje (compatible) a través de un punto de conexión privado con varias cuentas de almacenamiento

• StorageAccount.file.core.windows.net = 10.10.10.10
• StorageAccount2.file.core.windows.net = 10.10.10.11
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

Escenario 2: configuración de nconnect por montaje (no compatible) a través del punto de conexión público

• StorageAccount.file.core.windows.net = 52.239.238.8
• StorageAccount2.file.core.windows.net = 52.239.238.7
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
  • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

Nota:

Incluso si la cuenta de almacenamiento se resuelve en una dirección IP diferente, no podemos garantizar que la dirección persistirá porque los puntos de conexión públicos no son direcciones estáticas.

Escenario 3: configuración de nconnect por montaje (no compatible) a través de un punto de conexión privado con varios recursos compartidos de archivos en una cuenta de almacenamiento

• StorageAccount.file.core.windows.net = 10.10.10.10
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare3

Configuración de prueba de rendimiento

Usamos los siguientes recursos y herramientas de pruebas comparativas para lograr y medir los resultados descritos en este artículo.

• Cliente único: Máquina virtual de Azure (serie DSv4) con una sola NIC
• Sistema operativo: Linux (Ubuntu 20.40)
• Almacenamiento NFS: Recurso compartido de archivos premium de Azure Files (aprovisionado 30 TiB, configurado nconnect=4)

Tamaño	vCPU	Memoria	Almacenamiento temporal (SSD)	Discos de datos máx.	Nº máx. NIC	Ancho de banda de red esperado
Standard_D16_v4	16	64 GiB	Solo almacenamiento remoto	32	8	12 500 Mbps

Pruebas y herramientas de pruebas comparativas

Usamos Flexible I/O Tester (FIO), una herramienta de E/S de disco libre y de código abierto que se usa tanto para pruebas comparativas como para comprobación del esfuerzo y el hardware. Para instalar FIO, siga la sección Paquetes binarios que aparece en el archivo README de FIO para instalar la versión correspondiente a la plataforma que prefiera.

Aunque estas pruebas se centran en patrones de acceso de E/S aleatorios, obtendrá resultados similares al usar E/S secuencial.

IOPS elevadas: lecturas del 100 %

Tamaño de E/S de 4 k - lectura aleatoria - profundidad de 64 colas

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Tamaño de E/S de 8 k - lectura aleatoria - profundidad de 64 colas

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Alto rendimiento: 100 % de lecturas

Tamaño de E/S de 64 k - lectura aleatoria - profundidad de 64 colas

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Tamaño de E/S de 1024 k - 100 % de lectura aleatoria - profundidad de 64 colas

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

IOPS elevadas: 100 % de escrituras

Tamaño de E/S de 4 k - 100 % de escritura aleatoria - profundidad de 64 colas

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Tamaño de E/S de 8 k - 100 % de escritura aleatoria - profundidad de 64 colas

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Alto rendimiento: 100 % de escrituras

Tamaño de E/S de 64 k - 100 % de escritura aleatoria - profundidad de 64 colas

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Tamaño de E/S de 1024 k - 100 % de escritura aleatoria - profundidad de 64 colas

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Consideraciones de rendimiento para nconnect

Al usar la opción de montaje de nconnect, debe evaluar detenidamente las cargas de trabajo que tienen las siguientes características:

• Cargas de trabajo de escritura sensibles a la latencia que son un único subproceso o usan una profundidad de cola baja (menos de 16)
• Cargas de trabajo de lectura confidenciales de latencia que son un único subproceso o usan una profundidad de cola baja en combinación con tamaños de E/S más pequeños

No todas las cargas de trabajo requieren rendimiento de alta escala en todo el sistema o de IOPS. En el caso de cargas de trabajo de escala más pequeñas, es posible que no tenga sentido usar nconnect. Use la tabla siguiente para decidir si nconnect será ventajoso para la carga de trabajo. Se recomiendan escenarios resaltados en verde, mientras que los resaltados en rojo no. Los resaltados en amarillo son neutros.

Consulte también

• Para obtener instrucciones de montaje, consulte Montaje del recurso compartido de archivos NFS en Linux.
• Para obtener una lista completa de las opciones de montaje, consulte página man de NFS de Linux.
• Para obtener información sobre la latencia, las IOPS, el rendimiento y otros conceptos de rendimiento, consulte Descripción del rendimiento de Azure Files.