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 visión realista del rendimiento, asegúrate de hacer pruebas a una frecuencia y duración suficientemente altas. En los recursos compartidos de archivos provisionados, una prueba corta puede medir IOPS en ráfagas basadas en crédito en lugar de IOPS provisionadas. Para más información, véase Bursting.

• 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.

Creación de ráfagas

Los recursos compartidos de archivos que utilizan el modelo de facturación v2 provisionado o v1 provisionado admiten ráfagas de IOPS basadas en créditos. El bursting basado en crédito permite que un recurso compartido de archivos use más IOPS de los que tiene aprovisionados durante un tiempo limitado. El aumento de capacidad basado en créditos es una característica del recurso compartido de archivos. El tráfico irregular es un patrón de carga de trabajo con picos cortos en IOPS o rendimiento. El bursting basado en créditos puede absorber picos cortos de IOPS por tráfico a ráfagas.

La ráfaga basada en créditos está incluida en el coste del recurso compartido de archivos aprovisionado y no añade cargos a tu factura. El bursting basado en créditos solo se aplica a IOPS. No aumenta el rendimiento por encima del rendimiento aprovisionado.

El 'bursting' no se aplica a los recursos compartidos de archivos de pago por uso. Los recursos compartidos de archivos clásicos con capacidad de ráfaga siguen estando sujetos a los límites de IOPS de la cuenta de almacenamiento. Para más información, véase Límites clásicos del plano de datos de compartición de archivos. Para información sobre cómo el bursting afecta al coste, consulta Entender la facturación de Azure Files.

Expansión del modelo aprovisionado v2

La expansión de IOPS basada en créditos agrega flexibilidad al uso de IOPS. Use esta flexibilidad como búfer frente a picos de E/S imprevistos. Para patrones de E/S ya establecidos, aprovisione para los picos de E/S.

Los créditos de IOPS de ráfaga se acumulan cada vez que el tráfico del recurso compartido de archivos es menor que el IOPS aprovisionado (línea base). Cada vez que el uso de IOPS de un recurso compartido de archivos supera las IOPS aprovisionadas y hay créditos de IOPS de expansión disponibles, el recurso compartido de archivos puede expandirse hasta el límite máximo permitido de IOPS de expansión. Los recursos compartidos de archivos pueden continuar expandiéndose siempre que haya créditos restantes, en función del número de créditos de expansión acumulados. Cada operación de entrada/salida más allá de las IOPS aprovisionadas consume un crédito. Una vez consumidos todos los créditos, el recurso compartido vuelve a los IOPS aprovisionados. IOPS en el recurso compartido de archivos no tiene que hacer nada especial para usar la expansión. La expansión funciona según el principio del mejor esfuerzo.

Los créditos de recursos compartidos tienen tres estados:

• Acumulando, cuando el recurso compartido de archivos está usando menos de las IOPS aprovisionadas.
• Rechazando, cuando el recurso compartido de archivos está usando más de las IOPS aprovisionadas y en modo de expansión.
• Constante, cuando el recurso compartido de archivos usa exactamente la IOPS aprovisionada y no hay créditos acumulados o usados.

Un nuevo archivo compartido comienza con el número completo de créditos en su almacén ampliable. Los créditos de expansión no se acumulan si las IOPS del recurso compartido de archivos está por debajo del límite aprovisionado debido a la limitación del servidor. Las siguientes fórmulas se usan para determinar el límite de IOPS de ráfaga y el número de créditos posibles para una compartición de archivos:

En la siguiente tabla se muestran algunos ejemplos de estas fórmulas para varias cantidades de IOPS aprovisionadas:

Expansión del modelo aprovisionado v1

El modelo aprovisionado v1 soporta dos tipos de ráfagas: ráfagas basadas en crédito, que se incluyen sin coste adicional, y ráfagas de pago, que opcionalmente puedes habilitar para permitir IOPS y un rendimiento superiores a la cantidad aprovisionada a cambio de cargos basados en el uso.

Expansión del modelo aprovisionado v1 basada en crédito

La expansión de IOPS basada en créditos agrega flexibilidad al uso de IOPS. Use esta flexibilidad como búfer frente a picos de E/S imprevistos. Para patrones de E/S ya establecidos, aprovisione para los picos de E/S.

Los créditos de IOPS de ráfaga se acumulan siempre que el tráfico del recurso compartido de archivos clásico sea menor que el IOPS aprovisionado (línea base). Cada vez que el uso de IOPS de un recurso compartido de archivos clásico supera las IOPS aprovisionadas y hay créditos de IOPS de ráfaga disponibles, el recurso compartido de archivos clásico puede aumentar hasta el límite máximo permitido de IOPS de ráfaga. Los recursos compartidos de archivos clásicos pueden continuar expandiéndose siempre que haya créditos restantes, en función del número de créditos de expansión acumulados. Cada operación de entrada/salida más allá de las IOPS aprovisionadas consume un crédito. Una vez consumidos todos los créditos, el recurso compartido de archivos clásico vuelve a los IOPS aprovisionados. IOPS en el recurso compartido de archivos no tiene que hacer nada especial para usar la expansión. La expansión funciona según el principio del mejor esfuerzo.

Los créditos de recursos compartidos tienen tres estados:

• Acumulando, cuando el recurso compartido de archivos clásico está usando menos de las IOPS aprovisionadas.
• Disminuyendo, cuando el recurso compartido de archivos clásico está utilizando más IOPS de las aprovisionadas y se encuentra en modo de aumento de capacidad.
• Constante, cuando el recurso compartido de archivos clásico usa exactamente la IOPS aprovisionada y no hay créditos acumulados o usados.

Un nuevo recurso compartido de archivos clásico comienza con el número completo de créditos en su almacén ampliable. Los créditos de expansión no se acumulan si las IOPS del recurso compartido de archivos está por debajo del límite aprovisionado debido a la limitación del servidor. Las fórmulas siguientes se usan para determinar el límite de IOPS de ráfaga y el número de créditos posibles para un recurso compartido de archivos clásico:

En la tabla siguiente se muestran algunos ejemplos de estas fórmulas para los tamaños aprovisionados:

Expansión de pago del modelo aprovisionado v1

La funcionalidad expansión de pago es una característica avanzada del modelo v1 aprovisionado, diseñado para apoyar a los clientes que nunca quieran verse limitados por restricciones. La expansión de pago agrega una facturación adicional basada en el uso para cualquier cantidad de IOPS o rendimiento por encima del almacenamiento aprovisionado. Esta característica es distinta de la expansión basada en crédito, que se incluye sin coste adicional como parte del almacenamiento aprovisionado. Aunque la expansión de pago puede agregar una flexibilidad eficaz a la forma de aprovisionar el recurso compartido de archivos clásico, también puede provocar una facturación inesperada si se usa incorrectamente.

Al igual que la expansión basada en crédito, la expansión de pago no es un reemplazo para aprovisionar la cantidad correcta de IOPS y rendimiento. En su lugar, proporciona más protección contra la limitación si se produce una demanda inesperada. Si tiene un nivel constante de uso de IOPS o de rendimiento, resulta más barato aprovisionar suficientes IOPS y suficiente rendimiento (mediante el aprovisionamiento de almacenamiento) para cubrir la demanda, en lugar de depender de ráfagas de pago.

La expansión de pago está deshabilitada de manera predeterminada, pero se puede habilitar siguiendo las instrucciones para modificar las características de coste y rendimiento de un recurso compartido de archivos clásico v1 aprovisionado (solo PowerShell y CLI). Si habilita la expansión de pago, supervise el uso de IOPS y rendimiento mediante las siguientes métricas disponibles a través de Azure Monitor:

• IOPS aprovisionado del recurso compartido de archivos
• MiB/s de ancho de banda aprovisionado del recurso compartido de archivos (rendimiento)
• Transacciones por número máximo de IOPS
• Ancho de banda por MiB máximo/s (rendimiento)
• Créditos de ráfaga para IOPS (expansión basada en crédito)
• E/S de expansión de pago (E/S)
• Ancho de banda de expansión de pago

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