Descripción del rendimiento de Azure Files

  • Artículo

Azure Files puede satisfacer los requisitos de rendimiento de la mayoría de las aplicaciones y casos de uso. En este artículo se explican los distintos factores que pueden afectar al rendimiento del recurso compartido de archivos y cómo optimizar el rendimiento de los recursos compartidos de archivos de Azure para la carga de trabajo.

Se aplica a

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

Glosario

Antes de leer este artículo, resulta útil comprender algunos términos clave relacionados con el rendimiento del almacenamiento:

  • Operaciones de E/S por segundo (IOPS)

    IOPS u operaciones de entrada/salida por segundo, mide el número de operaciones del sistema de archivos por segundo. En la documentación de Azure Files, el término "E/S" es un sinónimo de los términos "operación" y "transacción".

  • Tamaño de E/S

    El tamaño de E/S, a veces denominado tamaño de bloque, es el tamaño de la solicitud que una aplicación usa para realizar una única operación de entrada/salida (E/S) en el almacenamiento. En función de la aplicación, el tamaño de E/S puede variar de tamaños muy pequeños, como 4 KiB, a tamaños mucho mayores. El tamaño de E/S desempeña un papel importante en el rendimiento factible.

  • Rendimiento

    El rendimiento mide el número de bits leídos o escritos en el almacenamiento por segundo y se mide en mebibytes por segundo (MiB/s). Para calcular el rendimiento, multiplique las IOPS por el tamaño de E/S. Por ejemplo, 10 000 IOPS * 1 MiB de tamaño de E/S = 10 GiB/s, mientras que 10 000 IOPS * 4 KiB de tamaño de E/S = 38 MiB/s.

  • Latency

    La latencia es un sinónimo de retraso y normalmente se mide en milisegundos (ms). Hay dos tipos de latencia: de un extremo a otro y del servicio. Para obtener más información, vea latencia.

  • Profundidad de la cola

    La profundidad de la cola es el número de solicitudes de E/S pendientes que un recurso de almacenamiento puede controlar en cualquier momento. Para obtener más información, vea Profundidad de la cola.

Elección de un nivel de rendimiento basado en patrones de uso

Azure Files proporciona una variedad de niveles de almacenamiento que ayudan a reducir los costos al permitirle almacenar datos en el nivel adecuado de rendimiento y precio. En el nivel más elevado, Azure Files ofrece dos niveles de rendimiento: Estándar y Premium. Los recursos compartidos de archivos Estándar se hospedan en un sistema de almacenamiento respaldado por unidades de disco duro (HDD), mientras que los recursos compartidos de archivos Premium están respaldados por unidades de estado sólido (SSD) para mejorar el rendimiento. Los recursos compartidos de archivos Estándar tienen varios niveles de almacenamiento (optimizados para transacciones, frecuente y esporádico) entre los que puede moverse sin problemas a fin de maximizar los datos en reposo y los precios de transacción. Pero no puede moverse entre los niveles Estándar y Premium sin migrar físicamente los datos entre diferentes cuentas de almacenamiento.

Al elegir entre recursos compartidos de archivos Estándar y Premium, es importante comprender los requisitos del patrón de uso esperado que tiene previsto ejecutar en Azure Files. Si necesita grandes cantidades de IOPS, velocidades de transferencia de datos extremadamente rápidas o una latencia muy baja, debe elegir recursos compartidos de archivos de Azure Premium.

En la tabla siguiente se resumen los objetivos de rendimiento esperados entre los recursos Estándar y Premium. Para obtener más información, vea Objetivos de escalabilidad y rendimiento de Azure Files.

Requisitos del patrón de uso Estándar Premium
Latencia de escritura (milisegundos de un solo dígito) Sí Sí
Latencia de lectura (milisegundos de un solo dígito) No Sí

Los recursos compartidos de archivos Premium ofrecen un modelo de aprovisionamiento que garantiza el perfil de rendimiento siguiente en función del tamaño del recurso compartido. Para obtener más información, vea Modelo aprovisionado. Cada vez que el tráfico para el recurso compartido de archivos se encuentra por debajo del valor de IOPS de la línea base, se acumulan créditos de ráfaga en un cubo de ráfagas. Los créditos obtenidos se usan más adelante para habilitar la expansión cuando las operaciones superen la IOPS de línea base.

Capacidad (GiB) IOPS base IOPS de ráfaga Créditos de ráfaga Rendimiento (entrada + salida)
100 3100 Hasta 10 000 24 840 000 110 MiB/s
500 3500 Hasta 10 000 23 400 000 150 MiB/s
1024 4 024 Hasta 10 000 21 513 600 203 MiB/s
5120 8120 Hasta 15 360 26 064 000 613 MiB/s
10 240 13 240 Hasta 30 720 62 928 000 1125 MiB/s
33 792 36 792 Hasta 100 000 227 548 800 3480 MiB/s
51 200 54 200 Hasta 100 000 164 880 000 5220 MiB/s
102 400 100 000 Hasta 100 000 0 10 340 MiB/s

Azure Database for PostgreSQL: Lista de comprobación de rendimiento

Si va a evaluar los requisitos de rendimiento de una carga de trabajo nueva o existente, comprender los patrones de uso le permitirá lograr un rendimiento predecible. Consulte con el administrador de almacenamiento o el desarrollador de aplicaciones para determinar los patrones de uso siguientes.

  • Sensibilidad de latencia: ¿los usuarios abren archivos o interactúan con escritorios virtuales que se ejecutan en Azure Files? Estos son ejemplos de cargas de trabajo que son sensibles a la latencia de lectura y que también tienen alta visibilidad para los usuarios finales. Estos tipos de cargas de trabajo son más adecuados para los recursos compartidos de archivos Premium de Azure, que pueden proporcionar una latencia de milisegundos para las operaciones de lectura y escritura (< 2 ms para tamaño de E/S pequeño).

  • Requisitos de IOPS y rendimiento: los recursos compartidos de archivos Premium admiten mayores límites de IOPS y rendimiento que los recursos compartidos de archivos estándar. Consulte Destinos de escalado de recursos compartidos de archivos para obtener más información.

  • Duración y frecuencia de la carga de trabajo: es menos probable que las cargas de trabajo cortas (minutos) y poco frecuentes (por hora) logren los límites de rendimiento superiores de los recursos compartidos de archivos Estándar en comparación con las cargas de trabajo que se producen con frecuencia. En los recursos compartidos de archivos Premium, la duración de la carga de trabajo es útil al determinar el perfil de rendimiento correcto que se va a usar en función del tamaño de aprovisionamiento. En función del tiempo que necesite expandirse la carga de trabajo y el tiempo que tarda por debajo de las IOPS de línea base, puede determinar si va a acumular suficientes créditos de ráfaga para satisfacer constantemente la carga de trabajo en horas punta. La búsqueda del equilibrio correcto reducirá los costos en comparación con el exceso de aprovisionamiento del recurso compartido de archivos. Un error común consiste en ejecutar pruebas de rendimiento solo unos minutos, lo que a menudo es engañoso. Para obtener una vista realista del rendimiento, asegúrese de probar con una frecuencia y una duración suficientemente altas.

  • Paralelización de cargas de trabajo: en el caso de las cargas de trabajo que realizan operaciones en paralelo, como a través de varios subprocesos, procesos o instancias de aplicación en el mismo cliente, los recursos compartidos de archivos premium proporcionan una ventaja clara sobre los recursos compartidos de archivos estándar: SMB multicanal. Para obtener más información, consulte Mejora del rendimiento del recurso compartido de archivos de SMB de Azure.

  • Distribución de operaciones de API: ¿los metadatos de la carga de trabajo son pesados con las operaciones de apertura y cierre de archivos? Esto es habitual para las cargas de trabajo que realizan operaciones de lectura en un número elevado de archivos. Consulte Carga de trabajo pesada del espacio de nombres o los metadatos.

Latencia

Al pensar en la latencia, es importante comprender primero cómo se determina esta con Azure Files. Las medidas más comunes son la latencia asociada a las métricas de latencia de un extremo a otro y latencia del servicio. El uso de estas métricas de transacción puede ayudar a identificar problemas de latencia o de redes del lado cliente al determinar el tiempo que pasa el tráfico de la aplicación en tránsito hacia el cliente y desde este.

  • La latencia de un extremo a otro (SuccessE2ELatency) es el tiempo total que tarda una transacción en realizar un recorrido de ida y vuelta completo desde el cliente, por la red, al servicio Azure Files y de vuelta al cliente.

  • La latencia del servicio (SuccessServerLatency) es el tiempo que tarda una transacción en realizar un recorrido de ida y vuelta solo dentro del servicio Azure Files. Esto no incluye ninguna latencia de red o cliente.

    Diagrama en el que se compara la latencia del cliente y la del servicio para Azure Files.

La diferencia entre los valores de SuccessE2ELatency y SuccessServerLatency es la latencia que probablemente provocan la red y el cliente.

Es habitual confundir la latencia del cliente con la latencia del servicio (en este caso, el rendimiento de Azure Files). Por ejemplo, si la latencia del servicio notifica baja latencia y la de un extremo a otro notifica una latencia muy alta para las solicitudes, eso sugiere que todo el tiempo se invierte en el tránsito hacia el cliente y desde este, y no en el servicio Azure Files.

Además, tal como se muestra en el diagrama, cuanto más lejos esté del servicio, más lenta será la experiencia de latencia y más difícil será alcanzar límites de escalado de rendimiento con cualquier servicio en la nube. Esto sucede especialmente al acceder a Azure Files desde el entorno local. Aunque las opciones como ExpressRoute son ideales para el entorno local, siguen sin coincidir con el rendimiento de una aplicación (proceso y almacenamiento) que se ejecuta exclusivamente en la misma región de Azure.

Sugerencia

El uso de una máquina virtual en Azure para probar el rendimiento entre el entorno local y Azure es una manera eficaz y práctica de establecer como base las capacidades de red de la conexión a Azure. A menudo, un circuito ExpressRoute o una puerta de enlace de VPN con un tamaño insuficiente o incorrectamente enrutado puede ralentizar una carga de trabajo.

Profundidad de la cola

La profundidad de la cola es el número de solicitudes de E/S pendientes que un recurso de almacenamiento puede atender. A medida que los discos que usan los sistemas de almacenamiento han evolucionado de los ejes HDD (IDE, SATA, SAS) a los dispositivos de estado sólido (SSD, NVMe), también han evolucionado para admitir una mayor profundidad de cola. Un ejemplo de profundidad de cola baja consiste en una carga de trabajo que consta de un único cliente que interactúa en serie con un único archivo dentro de un conjunto de datos grande. Por el contrario, una carga de trabajo que admite paralelismo con varios subprocesos y varios archivos puede lograr fácilmente una profundidad de cola alta. Dado que Azure Files es un servicio de archivos distribuido que abarca miles de nodos de clúster de Azure y está diseñado para ejecutar cargas de trabajo a gran escala, se recomienda compilar y probar cargas de trabajo con una profundidad de cola alta.

La profundidad de cola alta se puede alcanzar de varias maneras diferentes en combinación con clientes, archivos y subprocesos. Para determinar la profundidad de cola de la carga de trabajo, multiplique el número de clientes por el número de archivos y por el número de subprocesos (clientes * archivos * subprocesos = profundidad de cola).

En la tabla siguiente se muestran las distintas combinaciones que puede usar para lograr una mayor profundidad de cola. Aunque puede superar la profundidad de cola óptima de 64, esta opción no se recomienda. Si lo hace, no observará más mejoras en el rendimiento y corre el riesgo de aumentar la latencia debido a la saturación de TCP.

Clientes Archivos Subprocesos Profundidad de la cola
1 1 1 1
1 1 2 2
1 2 2 4
2 2 2 8
2 2 4 16
2 4 4 32
1 8 8 64
4 4 2 64

Sugerencia

Para lograr límites de rendimiento superiores, asegúrese de que la carga de trabajo o la prueba de punto de referencia sea de varios subprocesos con varios archivos.

Aplicaciones de un solo subproceso frente a varios subprocesos

Azure Files es más adecuado para aplicaciones de varios subprocesos. La manera más fácil de comprender el impacto en el rendimiento que tiene la opción de varios subprocesos en una carga de trabajo es recorrer el escenario con E/S. En el ejemplo siguiente, tenemos una carga de trabajo que necesita copiar 10 000 archivos pequeños lo antes posible hacia un recurso compartido de archivos de Azure o desde este.

En esta tabla se desglosa el tiempo necesario (en milisegundos) para crear un único archivo de 16 KiB en un recurso compartido de archivos de Azure, basado en una aplicación de un solo subproceso que escribe en tamaños de bloque de 4 KiB.

Operación de E/S Crear Escritura de 4 KiB Escritura de 4 KiB Escritura de 4 KiB Escritura de 4 KiB Close Total
Subproceso 1 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms

En este ejemplo, tardaría aproximadamente 14 ms en crear un único archivo de 16 KiB a partir de las seis operaciones. Si una aplicación de un solo subproceso quiere mover 10 000 archivos a un recurso compartido de archivos de Azure, esto supondría 140 000 ms (14 ms * 10 000) o 140 segundos, porque cada archivo se mueve secuencialmente de uno en uno. Tenga en cuenta que el tiempo de servicio de cada solicitud lo determina principalmente la proximidad entre el proceso y el almacenamiento, tal como se describe en la sección anterior.

Al usar ocho subprocesos en lugar de uno, la carga de trabajo anterior se puede reducir de 140 000 ms (140 segundos) hasta 17 500 ms (17,5 segundos). Tal como se muestra en la tabla siguiente, cuando se mueven ocho archivos en paralelo en lugar de hacerlo de uno en uno, puede mover la misma cantidad de datos empleando un 87,5 % menos de tiempo.

Operación de E/S Crear Escritura de 4 KiB Escritura de 4 KiB Escritura de 4 KiB Escritura de 4 KiB Close Total
Subproceso 1 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Subproceso 2 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Subproceso 3 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Subproceso 4 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Subproceso 5 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Subproceso 6 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Subproceso 7 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Subproceso 8 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms

Vea también