Objetivos de escalabilidad y rendimiento de Azure Files
Azure Files ofrece recursos compartidos de archivos en la nube totalmente administrados a los que se puede acceder mediante los protocolos SMB y del sistema de archivos NFS. En este artículo se explican los objetivos de escalabilidad y rendimiento de Azure Files y Azure File Sync.
Los objetivos enumerados aquí pueden verse afectados por otras variables de la implementación. Por ejemplo, el rendimiento de E/S para un archivo puede verse afectado por el comportamiento del cliente SMB y por el ancho de banda de red disponible. Debe probar el patrón de uso para determinar si la escalabilidad y el rendimiento de Azure Files cumplen sus requisitos. También debería esperar que estos límites aumenten con el tiempo.
Se aplica a
| Tipo de recurso compartido de archivos | SMB | NFS |
|---|---|---|
| Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS |  |
 |
| Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS | |
|
| Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS | |
|
Objetivos de escalabilidad de Azure Files
Los recursos compartidos de archivos de Azure se implementan en cuentas de almacenamiento, que son objetos de nivel superior que representan un grupo compartido de almacenamiento. Este grupo de almacenamiento se puede usar para implementar varios recursos compartidos de archivos. Por tanto, existen tres categorías que se deben tener en cuenta: cuentas de almacenamiento, recursos compartidos de archivo de Azure y archivos individuales.
Objetivos de escalabilidad de la cuenta de almacenamiento
Los objetivos de escalabilidad de la cuenta de almacenamiento se aplican en el nivel de cuenta de almacenamiento. Hay dos tipos principales de cuentas de almacenamiento para Azure Files:
Cuentas de almacenamiento de uso general, versión 2 (GPv2) : Las cuentas de almacenamiento de GPv2 permiten implementar recursos compartidos de archivos de Azure en hardware estándar o basado en disco duro (HDD). Además de almacenar recursos compartidos de archivos de Azure, las cuentas de almacenamiento de GPv2 pueden almacenar otros recursos de almacenamiento, como contenedores de blobs, colas o tablas. Los recursos compartidos de archivos se pueden implementar en los niveles de transacción optimizada (valor predeterminado), acceso frecuente o acceso esporádico.
Cuentas de almacenamiento FileStorage: Las cuentas de almacenamiento FileStorage permiten implementar recursos compartidos de archivos de Azure en hardware prémium o basado en unidades de estado sólido (SSD). Las cuentas FileStorage solo se pueden usar para almacenar recursos compartidos de archivos de Azure. No se puede implementar ningún otro recurso de almacenamiento (contenedores de blobs, colas, tablas, etc.) en una cuenta FileStorage.
| Atributo | Cuentas de almacenamiento GPv2 (estándar) | Cuentas de almacenamiento FileStorage (prémium) |
|---|---|---|
| Número de cuentas de almacenamiento por suscripción y región | 250 | 250 |
| Capacidad máxima de la cuenta de almacenamiento | 5 PiB1 | 100 TiB (aprovisionados) |
| Número máximo de recursos compartidos de archivos | Sin límite | Sin límite, el tamaño total aprovisionado de todos los recursos compartidos debe ser inferior al máximo que la capacidad máxima de la cuenta de almacenamiento. |
| Velocidad máxima de solicitudes simultáneas | 20 000 IOPS1 | 100 000 IOPS |
Rendimiento (entrada + salida) para LRS/GRS
|
|
10,340 MiB/s |
Rendimiento (entrada + salida) para ZRS
|
|
10,340 MiB/s |
| Rendimiento (entrada + salida) para combinaciones de redundancia y región no enumeradas en la fila anterior |
|
10,340 MiB/s |
| Número máximo de reglas de red virtual | 200 | 200 |
| Número máximo de reglas de dirección IP | 200 | 200 |
| Operaciones de lectura de administración | 800 por cada 5 minutos | 800 por cada 5 minutos |
| Operaciones de escritura de administración | 10 por segundo/1200 por hora | 10 por segundo/1200 por hora |
| Operaciones de lista de administración | 100 por cada 5 minutos | 100 por cada 5 minutos |
1 Las cuentas de almacenamiento de uso general, versión 2, admiten límites más altos de capacidad y límites más altos de entrada por solicitud. Para solicitar un aumento en los límites de cuenta, póngase en contacto con el soporte técnico de Azure.
Objetivos de escala de recursos compartidos de archivos de Azure
Los objetivos de escalabilidad de los recursos compartidos de archivos de Azure se aplican en el nivel de recurso compartido de archivos.
| Atributo | Recursos compartidos de archivos estándar1 | Recursos compartidos de archivos Prémium |
|---|---|---|
| Tamaño máximo de un recurso compartido de archivos | Sin mínimo | 100 GiB (aprovisionados) |
| Unidad de aumento/reducción de tamaño aprovisionada | N/D | 1 GiB |
| Tamaño máximo de un recurso compartido de archivos |
|
100 TiB |
| Número máximo de archivos en un recurso compartido de archivos | Sin límite | Sin límite |
| Velocidad máxima de solicitud (IOPS máx.) |
|
|
| Rendimiento (entrada y salida) de un único recurso compartido de archivos (MiB/seg) |
|
100 + CEILING (0,04 * ProvisionedStorageGiB) + CEILING (0,06 * ProvisionedStorageGiB) |
| Número máximo de instantáneas de recurso compartido | 200 instantáneas | 200 instantáneas |
| La longitud máxima del nombre de objeto3 (nombre de ruta de acceso completo que incluye todos los directorios, los nombres de archivo y caracteres de barra diagonal inversa) | 2048 caracteres | 2048 caracteres |
| La longitud máxima del componente nombre de ruta de acceso individual3 (en la ruta de acceso \A\B\C\D, cada letra representa un directorio o archivo que constituye un componente individual) | 255 caracteres | 255 caracteres |
| Límite de vínculo físico (solo NFS) | N/D | 178 |
| Número máximo de canales de SMB multicanal | N/D | 4 |
| Número máximo de directivas de acceso almacenadas por recurso compartido de archivos | 5 | 5 |
1 Los límites de los recursos compartidos de archivos estándar se aplican a los tres niveles disponibles para dichos recursos: optimizado para transacciones, acceso frecuente y acceso esporádico.
2 El valor predeterminado de los recursos compartidos de archivos estándar es 5 TiB; consulte Creación de un recurso compartido de archivos de Azure para obtener más información sobre cómo crear recursos compartidos de archivos con un tamaño de 100 TiB y aumentar los recursos compartidos de archivos estándar existentes hasta 100 TiB. Para aprovechar las ventajas de los destinos de mayor escala, debe cambiar la cuota para que sea mayor que 5 TiB.
3 Azure Files aplica ciertas reglas de nomenclatura para los nombres de los directorios y archivos.
Objetivos de escalabilidad de archivos
Los objetivos de escalabilidad de los archivos se aplican a los archivos individuales almacenados en los recursos compartidos de archivos de Azure.
| Atributo | Archivos en recursos compartidos de archivos estándar | Archivos en recursos compartidos de archivos prémium |
|---|---|---|
| Tamaño de archivo máximo | 4 TiB | 4 TiB |
| Velocidad máxima de solicitudes simultáneas | 1000 IOPS | Hasta 80001 |
| Entrada máxima de un archivo | 60 MiB/s | 200 MiB/s (hasta 1 GiB/s con SMB multicanal)2 |
| Salida máxima de un archivo | 60 MiB/s | 300 MiB/s (hasta 1 GiB/s con SMB multicanal)2 |
| Número máximo de identificadores simultáneos por archivo, directorio y raíz de recurso compartido3 | 2000 identificadores | 2000 identificadores |
1 Se aplica a entradas y salidas de lectura y escritura (normalmente tamaños de E/S menores o iguales que 64 KiB). Las operaciones de metadatos, que no sean lecturas y escrituras, pueden ser más lentas.
2 En función de los límites de red de la máquina, el ancho de banda disponible, los tamaños de E/S, la profundidad de la cola y otros factores. Para más información, consulte Rendimiento multicanal de SMB.
3 Azure Files admite 2000 identificadores abiertos por recurso compartido y, en la práctica, puede aumentar. Sin embargo, si una aplicación mantiene un identificador abierto en la raíz del recurso compartido, se alcanzará el límite de la raíz del recurso compartido antes de alcanzar el límite por archivo o por directorio.
Objetivos de escalabilidad de Azure File Sync
En la tabla siguiente, se indica qué objetivo es flexible, que representa el límite probado por Microsoft, y rígido, lo que indica un máximo obligatorio:
| Recurso | Destino | Límite máximo |
|---|---|---|
| Servicios de sincronización de almacenamiento por región | 100 servicios de sincronización de Storage | Sí |
| Grupos de sincronización por servicio de sincronización de almacenamiento | 200 grupos de sincronización | Sí |
| Servidores registrados por servicio de sincronización de almacenamiento | 99 servidores | Sí |
| Puntos de conexión en la nube por grupo de sincronización | 1 punto de conexión en la nube | Sí |
| Puntos de conexión del servidor por grupo de sincronización | 100 puntos de conexión de servidor | Sí |
| Puntos de conexión del servidor por servidor | 30 puntos de conexión de servidor | Sí |
| Objetos del sistema de archivos (archivos y directorios) por grupo de sincronización | 100 millones de objetos | No |
| Número máximo de objetos del sistema de archivos (directorios y archivos) en un directorio (no recursivo) | 5 millones de objetos | Sí |
| Tamaño máximo del descriptor de seguridad de (archivos y directorios) del objeto | 64 KiB | Sí |
| Tamaño de archivo | 100 GiB | No |
| Tamaño mínimo de un archivo que se va a organizar en niveles | basado en el tamaño del clúster del sistema de archivos (tamaño del clúster del sistema de archivos doble). Por ejemplo, si el tamaño del clúster del sistema de archivos es 4 KiB, el tamaño mínimo del archivo será de 8 KiB. | Sí |
Nota
Un punto de conexión de Azure File Sync puede escalar verticalmente hasta el tamaño de un recurso compartido de archivos de Azure. Si se alcanza el límite de tamaño de recurso compartido de archivos de Azure, la sincronización no podrá funcionar.
Métricas de rendimiento de Azure File Sync
Dado que el agente de Azure File Sync se ejecuta en una máquina con Windows Server que se conecta a los recursos compartidos de archivos de Azure, el rendimiento de sincronización efectivo depende de una serie de factores de su infraestructura: Windows Server y la configuración del disco subyacente, el ancho de banda de la red entre el servidor y Azure Storage, el tamaño del archivo, el tamaño total del conjunto de datos y la actividad en el conjunto de datos. Dado que Azure File Sync funciona en el nivel de archivo, las características de rendimiento de una solución basada en Azure File Sync se debe medir según el número de objetos (archivos y directorios) que se procesan por segundo.
En el caso de Azure File Sync, el rendimiento es fundamental en dos fases:
- Aprovisionamiento inicial que se realiza una sola vez: para optimizar el rendimiento del aprovisionamiento inicial, consulte Incorporación con Azure File Sync, donde obtendrá los detalles de una implementación óptima.
- Sincronización en curso: después de que los datos se inicializan en los recursos compartidos de archivos de Azure, Azure File Sync mantiene varios puntos de conexión sincronizados.
Nota
Cuando muchos puntos de conexión de servidor del mismo grupo de sincronización se están sincronizando al mismo tiempo, compiten por los recursos del servicio en la nube. Como resultado, el rendimiento de la carga se ve afectado. En casos extremos, algunas sesiones de sincronización no podrán acceder a los recursos y se producirá un error. Sin embargo, esas sesiones de sincronización se reanudarán en breve y finalmente se realizarán correctamente una vez que se reduzca la congestión.
Para ayudarle a planear la implementación de cada una de las fases, a continuación encontrará los resultados observados durante las pruebas internas en un sistema con una configuración
| Configuración del sistema | Detalles |
|---|---|
| CPU | 64 núcleos virtuales con una memoria caché L3 de 64 MiB |
| Memoria | 128 GB |
| Disco | Discos SAS con RAID 10 con caché con respaldo de batería |
| Red | Red de 1 Gbps |
| Carga de trabajo | Servidor de archivos de uso general |
| Aprovisionamiento inicial que se realiza una sola vez | Detalles |
|---|---|
| Número de objetos | 25 millones de objetos |
| Tamaño del conjunto de datos | ~4,7 TiB |
| Tamaño de archivo medio | ~200 KiB (archivo más grande: 100 GiB) |
| Enumeración inicial de cambios de nube | 80 objetos por segundo |
| Rendimiento de carga | 20 objetos por segundo por grupo de sincronización |
| Rendimiento de descarga de espacio de nombres | 400 objetos por segundo |
Aprovisionamiento inicial que se realiza una sola vez
Enumeración inicial de cambios de nube: Cuando se crea un nuevo grupo de sincronización, la enumeración inicial de cambios en la nube es el primer paso que se ejecutará. En este proceso, el sistema enumerará todos los elementos del recurso compartido de archivos de Azure. Durante este proceso, no habrá ninguna actividad de sincronización; es decir, no se descargará ningún elemento del punto de conexión de la nube al punto de conexión del servidor, y no se cargará ningún elemento desde el punto de conexión del servidor al punto de conexión en la nube. La actividad de sincronización se reanudará una vez que se complete la enumeración inicial de cambios en la nube. La tasa de rendimiento es de 80 objetos por segundo. Para calcular el tiempo que se tarda en completar la enumeración inicial de cambios en la nube, los clientes pueden calcular el número de elementos del recurso compartido de nube y usar la siguiente fórmula para obtener el tiempo en días.
Tiempo (en días) para la enumeración inicial en la nube = (número de objetos en el punto de conexión de nube)/(80*60*60*24)
Sincronización inicial de datos de Windows Server con un recurso compartido de archivos de Azure: muchas implementaciones de Azure File Sync comienzan con un recurso compartido de archivos de Azure vacío porque todos los datos están en el servidor de Windows. En estos casos, la enumeración inicial de cambios en la nube es rápida y la mayor parte del tiempo se dedica a sincronizar los cambios de Windows Server con los recursos compartidos de archivos de Azure.
Mientras la sincronización carga los datos en el recurso compartido de archivos de Azure, no hay tiempo de inactividad en el servidor de archivos local y los administradores pueden configurar los límites de red para restringir la cantidad de ancho de banda que se usa para la carga de datos en segundo plano.
La sincronización inicial suele estar limitada por la velocidad de carga inicial de 20 archivos por segundo/por grupo de sincronización. Los clientes pueden calcular el tiempo de carga de todos sus datos en Azure con las siguientes fórmulas para obtener el tiempo en días:
Tiempo (en días) para la carga de archivos en un grupo de sincronización = (número de objetos en el punto de conexión del servidor)/(20*60*60*24)
Dividir los datos en varios puntos de conexión de servidor y grupos de sincronización puede acelerar esta carga de datos inicial, ya que la operación puede realizarse en paralelo con varios grupos de sincronización a una velocidad de 20 elementos por segundo. Por lo tanto, se ejecutarían dos grupos de sincronización con una tasa combinada de 40 elementos por segundo. El tiempo total para terminar la operación sería el tiempo estimado del grupo de sincronización con el mayor número de archivos que se van a sincronizar.
Rendimiento de descarga de espacio de nombres Cuando se agrega un nuevo punto de conexión de servidor a un grupo de sincronización existente, el agente de Azure File Sync no descarga ningún contenido de archivo del punto de conexión en la nube. En primer lugar sincroniza el espacio de nombres completo y, después, desencadena la recuperación en segundo plano para descargar los archivos, ya sea en su totalidad o, si está habilitada la organización en niveles en la nube, la directiva de niveles en la nube establecida en el punto de conexión del servidor.
| Sincronización en curso | Detalles |
|---|---|
| Número de objetos sincronizados | 125 000 objetos (renovación ~ 1 %) |
| Tamaño del conjunto de datos | 50 GiB |
| Tamaño de archivo medio | ~500 KiB |
| Rendimiento de carga | 20 objetos por segundo por grupo de sincronización |
| Rendimiento de descarga completa* | 60 objetos por segundo |
*Si están habilitados los niveles de la nube, es probable que observe un rendimiento mejor, ya que solo se descargan algunos de los datos de los archivos. Azure File Sync solo descarga los datos de los archivos almacenados en la memoria caché cuando cambian en cualquiera de los puntos de conexión. En el caso de los archivos en niveles o recién creados, el agente no descarga los datos de los archivos, solo sincroniza el espacio de nombres en todos los puntos de conexión del servidor. El agente también admite descargas parciales de archivos en capas cuando el usuario accede a ellos.
Nota:
Los números anteriores no indican el rendimiento que experimentará. El rendimiento real dependerá de varios factores, como se ha indicado al principio de esta sección.
Como guía general para la implementación, debería tener varios factores en cuenta:
- El rendimiento de los objetos se escala aproximadamente en proporción al número de grupos de sincronización del servidor. La división de los datos en varios grupos de sincronización en un servidor mejora el rendimiento, que también está limitado por el servidor y la red.
- El rendimiento de los objetos es inversamente proporcional al rendimiento de MiB por segundo. En archivos pequeños, el rendimiento será mayor en cuanto al número de objetos procesados por segundo, pero el rendimiento en MiB por segundo será inferior. Por el contrario, en archivos grandes, se procesarán menos objetos por segundo, pero el rendimiento en MiB por segundo será superior. El rendimiento en MiB por segundo está limitado por los destinos del escalado de Azure Files.