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 de un archivo puede verse afectado tanto por el comportamiento del cliente SMB como 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.
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 | 2501 | 2501 |
| Capacidad máxima de la cuenta de almacenamiento | 5 PiB2 | 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 IOPS2 | 102 400 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 Con un aumento de cuota, puede crear hasta 500 cuentas de almacenamiento con puntos de conexión estándar por región. Para más información, consulte Aumento de las cuotas de la cuenta de Azure Storage. 2 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 los objetivos de escala más grandes, 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 para el directorio raíz3 | 10 000 identificadores | 10 000 identificadores |
| Número máximo de identificadores simultáneos por archivo y directorio3 | 2000 identificadores | 2000 identificadores |
1 Se aplica a entradas y salidas de lectura y escritura (normalmente los tamaños de E/S son iguales o menores que 64 KiB). Las operaciones de metadatos, que no sean lecturas y escrituras, pueden ser más lentas. Estos límites son flexibles y la limitación puede producirse más allá de estos límites.
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 10 000 identificadores abiertos en el directorio raíz y 2000 identificadores abiertos por archivo y directorio dentro del recurso compartido. El número de usuarios activos admitidos por recurso compartido depende de las aplicaciones que acceden al recurso compartido. Si las aplicaciones no abren un identificador en el directorio raíz, Azure Files puede admitir más de 10 000 usuarios activos por recurso compartido. Sin embargo, si usa Azure Files para almacenar imágenes de disco para cargas de trabajo de escritorio virtual a gran escala, es posible que se quede sin identificadores para el directorio raíz o por archivo o directorio. En este caso, es posible que tenga que usar varios recursos compartidos de archivos de Azure. Para más información, consulte Guía de ajuste de tamaño de Azure Files para Azure Virtual Desktop.
Guía de ajuste de tamaño de Azure Files para Azure Virtual Desktop
Un caso de uso popular de Azure Files es almacenar contenedores de perfiles de usuario e imágenes de disco para Azure Virtual Desktop, mediante FSLogix o la asociación de aplicaciones. En implementaciones de Azure Virtual Desktop a gran escala, es posible que se quede sin identificadores para el directorio raíz o por archivo o directorio si usa un único recurso compartido de archivos de Azure. En esta sección se describe cómo los diversos tipos de imágenes de disco consumen los identificadores y se proporcionan instrucciones de ajuste de tamaño en función de la tecnología que se use.
FSLogix
Si usa FSLogix con Azure Virtual Desktop, los contenedores de perfiles de usuario son discos duros virtuales (VHD) o discos duros virtuales de Hyper-V (VHDX), y se montan en un contexto de usuario, no en un contexto del sistema. Cada usuario abrirá un único identificador de directorio raíz, que debe ser para el recurso compartido de archivos. Azure Files puede admitir un máximo de 10 000 usuarios suponiendo que tenga el recurso compartido de archivos (\\storageaccount.file.core.windows.net\sharename) + el directorio de perfiles (%sid%_%username%) + el contenedor de perfiles (profile_%username.vhd(x)).
Si alcanza el límite de 10 000 identificadores simultáneos para el directorio raíz o los usuarios experimentan un rendimiento deficiente, pruebe a usar un recurso compartido de archivos de Azure adicional y a distribuir los contenedores entre los recursos compartidos.
Advertencia
Aunque Azure Files puede admitir hasta 10 000 usuarios simultáneos de un único recurso compartido de archivos, es fundamental probar correctamente las cargas de trabajo con respecto al tamaño y el tipo de recurso compartido de archivos que ha creado. Los requisitos pueden variar en función de los usuarios, el tamaño del perfil y la carga de trabajo.
Por ejemplo, si tiene 2400 usuarios simultáneos, necesitará 2400 identificadores en el directorio raíz (uno para cada usuario), que está por debajo del límite de 10 000 identificadores abiertos. En el caso de los usuarios de FSLogix, alcanzar el límite de 2000 identificadores de archivos y directorios abiertos es muy poco probable. Si tiene un único contenedor de perfiles de FSLogix por usuario, solo consumiría dos identificadores de archivo o directorio: uno para el directorio de perfiles y otro para el archivo de contenedor de perfiles. Si los usuarios tienen dos contenedores cada uno (perfil y ODFC), necesitará un identificador adicional para el archivo ODFC.
Asociación de aplicaciones con CimFS
Si usa la asociación de aplicaciones MSIX o la asociación de aplicaciones para asociar aplicaciones dinámicamente, puede utilizar el sistema de archivos de imágenes compuestas (CimFS) o archivos VHD/VHDX para imágenes de disco. En cualquier caso, los límites de escala son por máquina virtual que monta la imagen, no por usuario. El número de usuarios es irrelevante al calcular los límites de escala. Cuando se arranca una máquina virtual, se monta la imagen de disco, incluso si hay cero usuarios.
Si usa la asociación de aplicaciones con CimFS, las imágenes de disco solo consumen identificadores en los archivos de imagen de disco. No consumen identificadores en el directorio raíz ni en el directorio que contiene la imagen de disco. Sin embargo, dado que una imagen CimFS es una combinación del archivo .cim y al menos otros dos archivos, para cada máquina virtual que monta la imagen de disco, necesitará un identificador para cada uno de los tres archivos del directorio. Por lo tanto, si tiene 100 máquinas virtuales, necesitará 300 identificadores de archivo.
Es posible que se queda sin identificadores de archivo si el número de máquinas virtuales por aplicación supera las 2000. En este caso, use un recurso compartido de archivos de Azure adicional.
Asociación de aplicaciones con VHD/VHDX
Si usa la asociación de aplicaciones con archivos VHD/VHDX, los archivos se montan en un contexto del sistema, no en un contexto de usuario, y son compartidos y de solo lectura. Un sistema de conexión puede consumir más de un identificador en el archivo VHDX. Para mantenerse dentro de los límites de escala de Azure Files, el número de máquinas virtuales multiplicado por el número de aplicaciones debe ser inferior a 10 000, y el número de máquinas virtuales por aplicación no puede superar las 2000. Por lo tanto, la restricción es la que se alcance primero.
En este escenario, podría alcanzar el límite por archivo o directorio con 2000 montajes de un único VHD/VHDX. O bien, si el recurso compartido contiene varios archivos VHD/VHDX, podría alcanzar primero el límite del directorio raíz. Por ejemplo, 100 máquinas virtuales que montan 100 archivos VHDX compartidos alcanzarán el límite de 10 000 identificadores de directorio raíz.
En otro ejemplo, 100 máquinas virtuales que acceden a 20 aplicaciones requerirán 2000 identificadores de directorio raíz (100 x 20 = 2000), que está bien dentro del límite de 10 000 identificadores de directorio raíz. También necesitará un identificador de archivo y un identificador de directorio o carpeta para cada máquina virtual que monte la imagen VHD(X), por lo que 200 identificadores en este caso (100 identificadores de archivo + 100 identificadores de directorio), que está cómodamente por debajo del límite de 2000 identificadores por archivo o directorio.
Si alcanza los límites de los identificadores simultáneos máximos para el directorio raíz o por archivo o directorio, use un recurso compartido de archivos de Azure adicional.
Objetivos de escalabilidad de Azure File Sync
En la tabla siguiente, se indica qué destinos son flexibles, que representan el límite probado por Microsoft, y qué destinos son rígidos, 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í |
| Servicios de sincronización de almacenamiento por suscripción | 15 servicios de sincronización de almacenamiento | 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 privados por servicio de sincronización de almacenamiento | 100 puntos de conexión privados | 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 Windows Server que se conecta a los recursos compartidos de archivos de Azure, el rendimiento de sincronización eficaz depende de varios factores en la infraestructura: Windows Server y la configuración del disco subyacente, el ancho de banda de red entre el servidor y el almacenamiento de Azure, el tamaño del archivo, el tamaño total del conjunto de datos y la actividad del 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, se enfrentan a recursos de 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.
Resultados de las pruebas internas
Para ayudarle a planear la implementación para cada una de las fases (aprovisionamiento único inicial y sincronización continua), estos son los resultados observados durante las pruebas internas en un sistema con la siguiente 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
| 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 |
Enumeración inicial de cambios en la 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 ejecuta. 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. No se descargará ningún elemento del punto de conexión en la nube al punto de conexión de servidor y no se cargará ningún elemento desde el punto de conexión de 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. Puede calcular el tiempo que tardará en completar la enumeración inicial de cambios en la nube mediante la determinación del número de elementos del recurso compartido en la nube y el uso de las fórmulas siguientes 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.
Aunque la sincronización carga 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 usado 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 del 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 del archivo desde el punto de conexión de 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
| 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 la nube por niveles está habilitada, es probable que observe un mejor rendimiento, ya que solo se descargan algunos de los datos de archivo. Azure File Sync solo descarga los datos de los archivos almacenados en caché cuando se cambian en cualquiera de los puntos de conexión. En el caso de los archivos en capas o recién creados, el agente no descarga los datos del archivo y, en su lugar, solo sincroniza el espacio de nombres con todos los puntos de conexión del servidor. El agente también admite descargas parciales de archivos en capas a medida que el usuario accede a ellos.
Nota:
Estos números no son una indicación del rendimiento que experimentará. El rendimiento real depende de varios factores como se describe al principio de esta sección.
Como guía general para la implementación, tenga en cuenta algunas cosas:
- 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 el caso de los archivos más pequeños, experimentará un mayor rendimiento en términos del número de objetos procesados por segundo, pero menor rendimiento de MiB por segundo. Por el contrario, para los archivos más grandes, obtendrá menos objetos procesados por segundo, pero un mayor rendimiento de MiB por segundo. El rendimiento en MiB por segundo está limitado por los destinos del escalado de Azure Files.