Pruebas comparativas de rendimiento de volumen normales de Azure NetApp Files para Linux

En este artículo se describen las pruebas comparativas de rendimiento que Azure NetApp Files ofrece para Linux con un volumen normal.

Cargas de trabajo completas de streaming de archivos (pruebas de punto de referencia de escalabilidad horizontal)

La intención de una prueba de escalabilidad horizontal es mostrar el rendimiento de un volumen de Azure NetApp File al escalar horizontalmente (o aumentar) el número de clientes que generan cargas de trabajo simultáneas en el mismo volumen. Estas pruebas suelen ser capaces de insertar un volumen en el perímetro de sus límites de rendimiento y son indicativos de cargas de trabajo como la representación multimedia, la inteligencia artificial y el aprendizaje automático, y otras cargas de trabajo que usan granjas de procesos grandes para realizar el trabajo.

Configuración de puntos de referencia de escalabilidad horizontal de I/OP elevada

Estos puntos de referencia usaron lo siguiente:

• Un único volumen normal de Azure NetApp Files 100 TiB con un conjunto de datos de 1 TiB mediante el nivel de rendimiento Ultra
• FIO (con y sin establecer randrepeat=0)
• Tamaños de bloque de 4 KiB y 8 KiB
• 6 máquinas virtuales D32s_v5 que ejecutan RHEL 9.3
• NFSv3
• QoS manual
• Opciones de montaje: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg

Configuración de puntos de referencia de escalabilidad horizontal de alto rendimiento

Estos puntos de referencia usaron lo siguiente:

• Un único volumen normal de Azure NetApp Files con un conjunto de datos de 1 TiB mediante el FIO del nivel de rendimiento Ultra (con y sin establecer randrepeat=0)
• FIO (con y sin establecer randrepeat=0)
• Tamaño de bloque de 64 KiB y 256 KiB
• 6 máquinas virtuales D32s_v5 que ejecutan RHEL 9.3
• NFSv3
• QoS manual
• Opciones de montaje: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg

Configuración de puntos de referencia de la conexión de red paralela (nconnect)

Estos puntos de referencia usaron lo siguiente:

• Un único volumen normal de Azure NetApp Files con un conjunto de datos de 1 TiB mediante el nivel de rendimiento Ultra
• FIO (con y sin establecer randrepeat=0)
• 4 KiB y 64 KiB wsize/rsize
• Una sola máquina virtual D32s_v4 que ejecuta RHEL 9.3
• NFSv3 con y sin nconnect
• Opciones de montaje: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg

Pruebas de punto de referencia de escalabilidad vertical

La intención de la prueba de escalabilidad vertical es mostrar el rendimiento de un volumen de Azure NetApp File al escalar verticalmente (o aumentar) el número de trabajos que generan cargas de trabajo simultáneas en varias conexiones TCP en un solo cliente al mismo volumen (por ejemplo, con nconnect).

Sin nconnect, estas cargas de trabajo no pueden presionar los límites del rendimiento máximo de un volumen, ya que el cliente no puede generar suficiente E/S o rendimiento de red. Estas pruebas suelen indicar qué experiencia de un solo usuario podría haber en cargas de trabajo, como la representación multimedia, las bases de datos, IA/ML y los recursos compartidos de archivos generales.

Puntos de referencia de escalabilidad horizontal de I/OP elevadas

Los siguientes puntos de referencia muestran el rendimiento obtenido para Azure NetApp Files con una carga de trabajo de I/OP elevada mediante:

• 32 clientes
• Lecturas y escrituras aleatorias de 4 KiB y 8 KiB
• Conjunto de datos de 1 TiB
• Relaciones de lectura y escritura de la siguiente manera: 100 %:0 %, 90 %:10 %, 80 %:20 %, etc.
• Con y sin el almacenamiento en caché del sistema de archivos implicado (mediante randrepeat=0 en FIO)

Para obtener más información, consulte Metodología de pruebas.

Resultados: 4 KiB, aleatorio, almacenamiento en caché de cliente incluido

En este punto de referencia, FIO se ejecutó sin la opción randrepeat de asignar datos aleatorios. Por lo tanto, una cantidad indeterminada de almacenamiento en caché entró en juego. Esta configuración da como resultado un número de rendimiento ligeramente mejor que las pruebas que se ejecutan sin almacenar en caché toda la pila de E/S que se está utilizando.

En el gráfico siguiente, las pruebas muestran que un volumen normal de Azure NetApp Files puede controlar entre aproximadamente 130 000 escrituras aleatorias puras de 4 KiB y aproximadamente 460 000 lecturas aleatorias puras de 4 KiB durante este punto de referencia. Combinación de lectura y escritura para la carga de trabajo ajustada en un 10 % para cada ejecución.

A medida que la combinación de I/OP de lectura y escritura aumenta hacia una gran cantidad de escritura, el total de I/OPS disminuye.

Resultados: 4 KiB, aleatorio, almacenamiento en caché de cliente excluido

En este punto de referencia, FIO se ejecutó con el ajuste randrepeat=0 para asignar datos aleatorios, lo que reduce la influencia del almacenamiento en caché en el rendimiento. Esto dio lugar a una reducción aproximada del 8 % en la I/OPS de escritura y una reducción aproximada del 17 % en I/OPS de lectura, pero muestra números de rendimiento más representativos de lo que realmente puede hacer el almacenamiento.

En el gráfico siguiente, las pruebas muestran que un volumen normal de Azure NetApp Files puede controlar entre aproximadamente 120 000 escrituras aleatorias puras de 4 KiB y aproximadamente 388 000 lecturas aleatorias puras de 4 KiB. Combinación de lectura y escritura para la carga de trabajo ajustada en un 25 % para cada ejecución.

A medida que la combinación de I/OP de lectura y escritura aumenta hacia una gran cantidad de escritura, el total de I/OPS disminuye.

Resultados: 8 KiB, aleatorio, almacenamiento en caché de cliente excluido

Los tamaños de lectura y escritura mayores darán lugar a menos operaciones de I/OPS totales, ya que se pueden enviar más datos con cada operación. Se usó un tamaño de lectura y escritura de 8 KiB para simular con más precisión lo que usan la mayoría de las aplicaciones modernas. Por ejemplo, muchas aplicaciones de EDA usan lecturas y escrituras de 8 KiB.

En este punto de referencia, FIO se ejecutó con randrepeat=0 para aleatorizar los datos, por lo que se redujo el impacto en el almacenamiento en caché del cliente. En el gráfico siguiente, las pruebas muestran que un volumen normal de Azure NetApp Files puede controlar entre aproximadamente 111 000 escrituras aleatorias puras de 8 KiB y aproximadamente 293 000 lecturas aleatorias de 8 KiB puras. Combinación de lectura y escritura para la carga de trabajo ajustada en un 25 % para cada ejecución.

A medida que la combinación de I/OP de lectura y escritura aumenta hacia una gran cantidad de escritura, el total de I/OPS disminuye.

Comparaciones en paralelo

Para ilustrar cómo el almacenamiento en caché puede influir en los puntos de referencia de rendimiento, en el gráfico siguiente se muestra el número total de I/OPS para las pruebas de 4 KiB con y sin mecanismos de almacenamiento en caché. Como se muestra, el almacenamiento en caché proporciona un ligero aumento del rendimiento para las tendencias de I/OPS bastante coherentes.

Desplazamiento específico, cargas de trabajo de lectura y escritura aleatorias de streaming: pruebas de escalabilidad vertical mediante conexiones de red paralelas (nconnect)

Las siguientes pruebas muestran un punto de referencia de I/OP elevado mediante un único cliente con cargas de trabajo aleatorias de 4 KiB y un conjunto de datos de 1 TiB. La combinación de cargas de trabajo generada usa una profundidad de E/S diferente cada vez. Para aumentar el rendimiento de una sola carga de trabajo de cliente, la opción de montaje nconnect se usó para mejorar el paralelismo en comparación con los montajes de cliente sin la opción de montaje nconnect.

Cuando se usa una conexión TCP estándar que proporciona solo una única ruta de acceso al almacenamiento, se envían menos operaciones totales por segundo que cuando un montaje puede aprovechar más conexiones TCP (por ejemplo, con nconnect) por punto de montaje. Cuando se usa nconnect, la latencia total de las operaciones suele ser menor. Estas pruebas también se ejecutan con randrepeat=0 para evitar intencionadamente el almacenamiento en caché. Para obtener más información sobre esta opción, consulte Metodología de pruebas.

Resultados: 4 KiB, aleatorios, con y sin nconnect, se excluye el almacenamiento en caché

Los gráficos siguientes muestran una única comparación en paralelo de lecturas y escrituras de 4 KiB con y sin nconnect para resaltar las mejoras de rendimiento que se ven al usar nconnect: mayor I/OPS, menor latencia.

Puntos de referencia de alto rendimiento

Los puntos de referencia siguientes muestran el rendimiento obtenido para Azure NetApp Files con una carga de trabajo de alto rendimiento.

Las cargas de trabajo de alto rendimiento son más secuenciales por naturaleza y, a menudo, son pesadas en cuanto a lectura y escritura con metadatos bajos. El rendimiento suele ser más importante que I/OPS. Estas cargas de trabajo suelen aprovechar tamaños de lectura y escritura más grandes (de 64 000 a 256 000), lo que genera latencias más altas que los tamaños de lectura y escritura más pequeños, ya que las cargas más grandes tardarán más tiempo en procesarse.

Entre los ejemplos de cargas de trabajo de alto rendimiento se incluyen:

• Repositorios multimedia
• Informática de alto rendimiento
• AI/ML/LLP

Las pruebas siguientes muestran un punto de referencia de alto rendimiento con cargas de trabajo secuenciales de 64 KiB y 256 KiB y un conjunto de datos de 1 TiB. La combinación de cargas de trabajo generada reduce un porcentaje establecido a la vez y muestra lo que se puede esperar al usar distintas relaciones de lectura y escritura (por ejemplo, 100 %:0 %, 90 %:10 %, 80 %:20 %, etc.).

Resultados: E/S secuencial de 64 KiB, almacenamiento en caché incluido

En este punto de referencia, FIO se ejecutó con lógica de bucle que rellenaba la memoria caché de forma más agresiva, por lo que una cantidad indeterminada de almacenamiento en caché influenció los resultados. Esto da como resultado números de rendimiento ligeramente mejores que las pruebas que se ejecutan sin almacenamiento en caché.

En el gráfico siguiente, las pruebas muestran que un volumen normal de Azure NetApp Files puede controlar entre aproximadamente 4500 MiB/s lecturas secuenciales puras de 64 KiB y aproximadamente 1600 MiB/s escrituras secuenciales puras de 64 KiB. La combinación de lectura y escritura para la carga de trabajo se ha ajustado en un 10 % para cada ejecución.

Resultados: E/S secuencial de 64 KiB, lecturas frente a escritura, línea base sin almacenamiento en caché

En esta prueba comparativa de línea de base, las pruebas muestran que un volumen normal de Azure NetApp Files puede controlar entre 3600 MiB/s de lecturas secuenciales puras de 64 KiB y aproximadamente 2400 MiB/s de escrituras secuenciales puras de 64 KiB. Durante las pruebas, una combinación de 50/50 mostró un rendimiento total a la par con una carga de trabajo de lectura secuencial pura.

Con respecto a la lectura pura, la línea de base de 64 KiB ha funcionado ligeramente mejor que la línea de base de 256 KiB. Sin embargo, en lo que respecta a la escritura pura y a todas las cargas de trabajo de lectura y escritura mixtas, la línea de base de 256 KiB superó los 64 KiB, lo que indica que un tamaño de bloque mayor de 256 KiB es más eficaz en general para cargas de trabajo de alto rendimiento.

La combinación de lectura y escritura para la carga de trabajo se ha ajustado en un 25 % para cada ejecución.

Resultados: E/S secuencial de 256 KiB sin almacenamiento en caché

En las dos pruebas comparativas de línea de base siguientes, se usó FIO para medir la cantidad de E/S secuencial (lectura y escritura) que puede proporcionar un único volumen normal en Azure NetApp Files. Para generar una línea de base que reflejara el ancho de banda verdadero que puede lograr una carga de trabajo de lectura totalmente sin almacenar en caché, se configuró FIO para ejecutarse con el parámetro randrepeat=0 para la generación de conjuntos de datos. Cada iteración de la prueba se ajustó con un conjunto de datos grande completamente distinto que no formaba parte de la prueba comparativa, con el fin de eliminar cualquier caché que pudiera haberse generado con el conjunto de datos de esta.

En el grafo siguiente, las pruebas muestran que un volumen normal de Azure NetApp Files puede controlar entre aproximadamente 3500 MiB/s de lecturas secuenciales puras de 256 KiB y aproximadamente 2500 MiB/s de escrituras secuenciales puras de 256 KiB. Durante las pruebas, una combinación de 50/50 mostró un rendimiento total máximo superior a una carga de trabajo de lectura secuencial pura.

Conexiones de red paralelas (nconnect)

Las siguientes pruebas muestran un punto de referencia de I/OP elevada con un solo cliente con cargas de trabajo aleatorias de 64 KiB y un conjunto de datos de 1 TiB. La combinación de cargas de trabajo generada usa una profundidad de E/S diferente cada vez. Para aumentar el rendimiento de una sola carga de trabajo de cliente, la opción de montaje nconnect se ha aprovechado para mejorar el paralelismo en comparación con los montajes de cliente que no usaron la opción de montaje nconnect. Estas pruebas solo se ejecutaron con el almacenamiento en caché excluido.

Resultados: E/S secuencial de 64 KiB, comparación de la caché de rendimiento de lectura

Para demostrar cómo el almacenamiento en caché influye en los resultados del rendimiento, se usó FIO en la siguiente comparación a pequeña escala para medir la cantidad de E/S secuencial (lectura y escritura) que puede proporcionar un único volumen normal en Azure NetApp Files. Esta prueba se contrasta con las ventajas que puede proporcionar una carga de trabajo parcialmente almacenable en caché.

En el resultado sin almacenamiento en caché, las pruebas se diseñaron para mitigar cualquier posible almacenamiento en caché que tuviera lugar, tal como se describe en las pruebas comparativas de línea de base anteriores. En el otro resultado, se usó FIO en volúmenes normales de Azure NetApp Files sin el parámetro randrepeat=0 y con una lógica de iteración de prueba de bucle que rellenaba lentamente la memoria caché a lo largo del tiempo. La combinación de estos factores produjo una cantidad indeterminada de almacenamiento en caché, lo que aumentó el rendimiento general. Esta configuración dio lugar a cifras de rendimiento de lectura ligeramente mejores que las pruebas que se ejecutaron sin almacenamiento en caché.

Los resultados de la prueba que se muestran en el grafo indican la comparación en paralelo del rendimiento de lectura con y sin la influencia del almacenamiento en caché, donde el almacenamiento en caché produjo hasta aproximadamente 4500 MiB/segundo de rendimiento de lectura, mientras que ningún almacenamiento en caché alcanzó en torno a ~3600 MiB/segundo.

Comparación en paralelo (con y sin nconnect)

Los gráficos siguientes muestran una comparación en paralelo de lecturas y escrituras secuenciales de 64 KiB con y sin nconnect para resaltar las mejoras de rendimiento que se ven al usar nconnect: mayor rendimiento general, menor latencia.

Más información

• Metodología de prueba