Descripción y optimización del rendimiento del recurso compartido de archivos de Azure

✔️ Se aplica a recursos compartidos de archivos clásicos SMB y NFS creados con el proveedor de recursos Microsoft.Storage

✔️ Se aplica a: recursos compartidos de archivos creados con el proveedor de recursos Microsoft.FileShares

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 afectan al rendimiento del recurso compartido de archivos y cómo optimizar el rendimiento de Azure Files para la carga de trabajo.

Glosario de rendimiento de almacenamiento

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" se usa indistintamente junto a 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. Dependiendo de la aplicación, el tamaño de E/S puede oscilar entre tamaños pequeños, como 4 KiB y tamaños 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 tamaño de E/S de MiB = 10 GiB/s, mientras que 10 000 IOPS × 4 tamaño de E/S de KiB = 38 MiB/s.

• Latencia

  La latencia es un sinónimo de retraso y 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 multimedia basado en patrones de uso

Azure Files proporciona dos niveles de medios de almacenamiento que puede usar para equilibrar el rendimiento y el precio: SSD y HDD. Seleccione el nivel de medios del recurso compartido de archivos en el nivel de cuenta de almacenamiento. Después de crear una cuenta de almacenamiento en un nivel multimedia determinado, no se puede mover al otro nivel multimedia sin migrar manualmente a un nuevo recurso compartido de archivos.

Al elegir entre recursos compartidos de archivos SSD y HDD, tenga en cuenta los requisitos del patrón de uso esperado que planea ejecutar en Azure Files. Si necesita grandes cantidades de IOPS, velocidades de transferencia de datos rápidas o baja latencia, elija Recursos compartidos de archivos SSD.

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

Los recursos compartidos de archivos SSD usan un modelo de aprovisionamiento que garantiza el siguiente perfil de rendimiento en función del tamaño del recurso compartido. Para obtener más información, consulte el modelo v1 aprovisionado.

Mejores prácticas de rendimiento

Tanto si va a evaluar los requisitos de rendimiento para una carga de trabajo nueva como existente, comprender los patrones de uso le ayuda a lograr un rendimiento predecible.

• Sensibilidad de latencia: Las cargas de trabajo que son sensibles a la latencia de lectura y tienen alta visibilidad para los usuarios finales son más adecuadas para los recursos compartidos de archivos SSD, lo que puede proporcionar latencia de un solo milisegundos para las operaciones de lectura y escritura (menos de 2 ms para un tamaño de E/S pequeño).

• Requisitos de IOPS y rendimiento: Los recursos compartidos de archivos SSD admiten mayores límites de IOPS y rendimiento que los recursos compartidos de archivos HDD. Para obtener más información, consulte los objetivos de escalado de recursos compartidos de archivos.

• Duración y frecuencia de la carga de trabajo: Es menos probable que las cargas de trabajo cortas (minutos) y las cargas de trabajo poco frecuentes (por hora) alcancen los límites de rendimiento superior de los recursos compartidos de archivos HDD en comparación con las cargas de trabajo de larga duración que se producen con frecuencia. En los recursos compartidos de archivos SSD, la duración de la carga de trabajo ayuda a determinar el perfil de rendimiento correcto que se usará en función del almacenamiento aprovisionado, las IOPS y el rendimiento. Un error común es ejecutar pruebas de rendimiento durante solo unos minutos, lo que suele ser 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 SSD proporcionan una ventaja clara sobre los recursos compartidos de archivos HDD: SMB multicanal. Para obtener más información, consulte Mejorar el rendimiento del recurso compartido de archivos de Azure SMB.

• Distribución de operaciones de API: las cargas de trabajo pesadas de metadatos, como las cargas de trabajo que realizan operaciones de lectura en un gran número de archivos, son una mejor opción para los recursos compartidos de archivos SSD. Para obtener más información, consulte Carga de trabajo intensa en metadatos o espacios de nombres.

• Ubicación zonal: use la ubicación zonal para seleccionar la zona de disponibilidad específica en la que reside la cuenta de almacenamiento. Esta característica permite colocar las máquinas virtuales en la misma zona de disponibilidad que el almacenamiento, lo que puede reducir la latencia hasta el 30 %. Esta característica solo está disponible actualmente para las cuentas de almacenamiento SSD con almacenamiento con redundancia local (LRS) en regiones admitidas.

Latencia

Cuando piense en la latencia, en primer lugar comprenda cómo Azure Files determina la latencia. 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 transacciones puede ayudarle a identificar problemas de latencia y redes del lado cliente mostrando cuánto tiempo pasa el tráfico de la aplicación en tránsito hacia y desde el cliente.

• 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 de Azure Files. Esta medida no incluye ninguna latencia de cliente o red.

  

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 indica una latencia baja y la latencia de extremo a extremo indica una latencia muy alta en las solicitudes, todo el tiempo se emplea en el tránsito de ida y vuelta entre el cliente y no en el servicio Azure Files.

Además, 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á lograr límites de escalado de rendimiento con cualquier servicio en la nube. Esta condición es especialmente cierta al acceder a Azure Files desde el entorno local. Aunque las opciones como Azure ExpressRoute son ideales para el entorno local, todavía no coinciden con el rendimiento de una aplicación (proceso y almacenamiento) que se ejecuta exclusivamente en la misma región de Azure.

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 utilizados en los sistemas de almacenamiento pasaron de unidades de disco duro (HDD) (IDE, SATA, SAS) a dispositivos de estado sólido (SSD, NVMe), también pasaron a 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 escala, compilar y probar cargas de trabajo con una profundidad de cola elevada.

Puede alcanzar una gran profundidad de cola de varias formas. Para determinar la profundidad de cola de la carga de trabajo, multiplique el número de clientes por el número de archivos por el número de subprocesos (los 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 es posible superar la profundidad de cola óptima de 64, 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.

Aplicaciones de un solo subproceso frente a aplicaciones multiproceso

Azure Files funciona mejor con aplicaciones multiproceso. La forma más fácil de comprender el impacto en el rendimiento que tienen los subprocesos múltiples en una carga de trabajo es recorrer el escenario por E/S. En el ejemplo siguiente, tiene una carga de trabajo que necesita copiar 10 000 archivos pequeños lo antes posible hacia o desde un recurso compartido de archivos de Azure.

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.

En este ejemplo, se tarda aproximadamente 14 ms en crear un único archivo de 16 KiB mediante seis operaciones. Si una aplicación de un solo subproceso quiere mover 10 000 archivos a un recurso compartido de archivos de Azure, esa operación se traduce a 140 000 ms (14 ms × 10 000) o 140 segundos porque cada archivo se mueve secuencialmente de una en una. El tiempo de servicio de cada solicitud se determina principalmente por la proximidad del proceso y el almacenamiento entre sí, como se describe en la sección anterior.

Mediante el uso de ocho subprocesos en lugar de uno, puede reducir la carga de trabajo anterior de 140 000 ms (140 segundos) a 17 500 ms (17,5 segundos). Como se muestra en la tabla siguiente, al mover ocho archivos en paralelo en lugar de un archivo a la vez, puede mover la misma cantidad de datos en 87,5% menos tiempo.

Consulte también

• Solución de problemas de rendimiento de recursos compartidos de archivos de Azure
• Supervisión de Azure Files
• Planeamiento de una implementación de Azure Files
• Descripción de la facturación de Azure Files
• Precios de Azure Files