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, almacenamiento en caché excluido

En este punto de referencia, FIO se ejecutó mediante lógica de bucle que rellenaba menos agresivamente la memoria caché. El almacenamiento en caché del cliente no influenció los resultados. Esta configuración da como resultado números de rendimiento de escritura ligeramente mejores, pero números de lectura inferiores a las pruebas sin almacenamiento en caché.

En el gráfico siguiente, las pruebas muestran que un volumen normal de Azure NetApp Files puede controlar entre aproximadamente 3600 MiB/s lecturas secuenciales puras de 64 KiB y aproximadamente 2400 MiB/s 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.

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, almacenamiento en caché excluido

En este punto de referencia, FIO se ejecutó mediante lógica de bucle que rellenaba menos agresivamente la memoria caché, por lo que el almacenamiento en caché no influenció los resultados. Esta configuración da como resultado números de rendimiento de escritura ligeramente menores que pruebas de 64 KiB, pero números de lectura más altos que las mismas pruebas de 64 KiB 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 3500 MiB/s lecturas secuenciales puras de 256 KiB y aproximadamente 2500 MiB/s 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.

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

Comparación en paralelo

Para mostrar mejor cómo el almacenamiento en caché puede influir en las pruebas de punto de referencia de rendimiento, el gráfico siguiente muestra el total de MiB/s para las pruebas de 64 KiB con y sin mecanismos de almacenamiento en caché. El almacenamiento en caché proporciona un ligero aumento inicial del rendimiento para el total de MiB/s, ya que el almacenamiento en caché mejora generalmente las lecturas más que las escrituras. A medida que cambia la combinación de lectura y escritura, el rendimiento total sin almacenamiento en caché supera los resultados que usan el almacenamiento en caché del cliente.

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: 64 KiB, secuencial, almacenamiento en caché excluido, con y sin nconnect

Los resultados siguientes muestran los resultados de una prueba de escalabilidad vertical al leer y escribir en fragmentos de 4 KiB en un montaje NFSv3 en un solo cliente con y sin paralelización de operaciones (nconnect). Los gráficos muestran que a medida que crece la profundidad de E/S, también aumenta la I/OPS. Pero 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 punto de montaje. Además, la latencia total de las operaciones suele ser menor al usar nconnect.

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