Planeamiento de una implementación de Azure Files Sync

Azure File Sync es un servicio que permite almacenar en caché varios recursos compartidos de archivos de Azure en una VM en la nube o en una instancia local de Windows Server.

En este artículo se explican los conceptos y características de Azure File Sync. Una vez que esté familiarizado con Azure File Sync, considere la posibilidad de seguir la guía de implementación de Azure File Sync para probar este servicio.

Los archivos se almacenarán en la nube en recursos compartidos de archivos de Azure. Se pueden usar recursos compartidos de archivos de Azure de dos formas: montando directamente los recursos compartidos de archivos de Azure sin servidor (SMB) o almacenando en caché recursos compartidos de archivos de Azure localmente mediante Azure File Sync. La opción de implementación que elija cambiará los aspectos que debe tener en cuenta a la hora de planear la implementación.

• Montaje directo de un recurso compartido de archivos de Azure: dado que Azure Files proporciona acceso SMB, puede montar recursos compartidos de archivos de Azure locales o en la nube mediante el cliente SMB estándar disponible en Windows, macOS y Linux. Dado que los recursos compartidos de archivos de Azure no tienen servidor, la implementación en escenarios de producción no requiere la administración de un servidor de archivos o un dispositivo NAS. lo que significa que no tiene que aplicar revisiones de software ni intercambiar discos físicos.

• Almacenamiento en caché de recursos compartidos de archivos de Azure localmente con Azure File Sync: Azure File Sync le permite centralizar los recursos compartidos de archivos de su organización en Azure Files sin renunciar a la flexibilidad, el rendimiento y la compatibilidad de un servidor de archivos local. Azure File Sync transforma una instancia de Windows Server local (o en la nube) en una caché rápida de su recurso compartido de archivos de Azure.

Conceptos de administración

Las implementaciones de Azure File Sync tiene tres objetos de administración fundamentales:

• Recurso compartido de archivos de Azure: Un recurso compartido de archivos de Azure es un recurso compartido de archivos en la nube sin servidor, que proporciona el punto de conexión en la nube de una relación de sincronización de Azure File Sync. A los archivos de un recurso compartido de archivos de Azure se puede acceder directamente con SMB o el protocolo FileREST, aunque se recomienda acceder a ellos principalmente mediante la memoria caché de Windows Server cuando el recurso compartido de archivos de Azure se vaya a usar con Azure File Sync. Ello se debe a que en la actualidad, Azure Files carece de un mecanismo de detección de cambios eficaz como el de Windows Server, por lo que los cambios directos en el recurso compartido de archivos de Azure tardarán un tiempo en propagarse en los puntos de conexión del servidor.
• Punto de conexión de servidor: la ruta de acceso de Windows Server que se sincroniza con un recurso compartido de archivos de Azure. Puede ser una carpeta concreta de un volumen o la raíz del volumen. Si sus espacios de nombres no se superponen, pueden existir varios puntos de conexión de servidor en el mismo volumen.
• Grupo de sincronización: el objeto que define la relación de sincronización entre un punto de conexión en la nube, o un recurso compartido de archivos de Azure, y un punto de conexión de servidor. Los puntos de conexión dentro de un grupo de sincronización se mantienen sincronizados entre sí. Si, por ejemplo, tiene dos conjuntos distintos de archivos que desea administrar con Azure File Sync, podría crear dos grupos de sincronización y agregar a cada uno puntos de conexión diferentes.

Conceptos de administración de recursos compartidos de archivos de Azure

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, así como otros recursos de almacenamiento, tales como contenedores de blobs, colas o tablas. Todos los recursos de almacenamiento que se implementan en una cuenta de almacenamiento comparten los límites que se aplican a esa cuenta de almacenamiento. Para ver los límites actuales de una cuenta de almacenamiento, consulte Objetivos de escalabilidad y rendimiento de Azure Files.

Hay dos tipos principales de cuentas de almacenamiento que se usarán para las implementaciones de 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.
• 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. Solo las cuentas de FileStorage pueden implementar recursos compartidos de archivos SMB y NFS.

Existen otros tipos de cuenta de almacenamiento que puede encontrar en el Azure Portal, PowerShell o la CLI. Dos tipos de cuentas de almacenamiento, BlockBlobStorage y BlobStorage, no pueden contener recursos compartidos de archivos de Azure. Los otros dos tipos de cuenta de almacenamiento que puede ver son las cuentas de almacenamiento clásico y de uso general de la versión 1 (GPv1), y ambas pueden contener recursos compartidos de archivos de Azure. Aunque las cuentas de almacenamiento clásico y de GPv1 pueden contener recursos compartidos de archivos de Azure, la mayoría de las nuevas características de Azure Files solo están disponibles en las cuentas de almacenamiento de GPv2 y FileStorage. Por lo tanto, se recomienda usar solo las cuentas de almacenamiento de GPv2 y FileStorage para las nuevas implementaciones, así como actualizar las cuentas de almacenamiento de GPv1 y clásico si ya existen en su entorno.

Conceptos de administración de Azure File Sync

Los grupos de sincronización se implementan en los servicios de sincronización del almacenamiento, que son objetos de primer nivel que registran servidores para que se usen con Azure File Sync y contienen las relaciones del grupo de sincronización. El recurso del servicio de sincronización de almacenamiento es un homólogo del recurso de la cuenta de almacenamiento, y se puede implementar igualmente en grupos de recursos de Azure. Los servicios de sincronización del almacenamiento pueden crear grupos de sincronización que contengan recursos compartido de archivos de Azure en varias cuentas de almacenamiento y varios servidores Windows Server registrados.

Para poder crear un grupo de sincronización en un servicio de sincronización de almacenamiento, antes es preciso registrar un servidor Windows Server en el servicio. De esta forma se crea un objeto de servidor registrado, que representa una relación de confianza entre el servidor o clúster y el servicio de sincronización de almacenamiento. Para registrar un servicio de sincronización de almacenamiento, antes hay que instalar el agente de Azure File Sync en el servidor. Un servidor o un clúster individuales no se puede registrar con varios servicios de sincronización de almacenamiento simultáneos.

Un grupo de sincronización contiene un punto de conexión en la nube, o un recurso compartido de archivos de Azure, y al menos un punto de conexión de servidor. El objeto de punto de conexión de servidor contiene los valores que configuran la funcionalidad de nube por niveles, que proporciona la funcionalidad de almacenamiento en caché de Azure File Sync. Para realizar la sincronización con un recurso compartido de archivos de Azure, la cuenta de almacenamiento que contiene el recurso compartido de archivos de Azure debe estar en la misma región de Azure que el servicio de sincronización de almacenamiento.

Importante

Puede realizar cambios en el espacio de nombres de cualquier punto de conexión en la nube o punto de conexión de servidor en el grupo de sincronización y sincronizar los archivos con los demás puntos de conexión del grupo de sincronización. Si realiza algún cambio directamente en el punto de conexión en la nube (recurso compartido de archivos de Azure), tenga en cuenta que un trabajo de detección de cambios de Azure File Sync deberá detectar primero esos cambios. Se inicia un trabajo de detección de cambios para un punto de conexión en la nube solo una vez cada 24 horas. Para obtener más información, consulte Preguntas más frecuentes de Azure Files.

Tener en cuenta el recuento de servicios de sincronización de almacenamiento necesarios

En una sección anterior se describe el recurso principal que se va a configurar para Azure File Sync: un servicio de sincronización de almacenamiento. Windows Server solo se puede registrar en un servicio de sincronización de almacenamiento. Por lo tanto, a menudo es mejor implementar solo un servicio de sincronización de almacenamiento y registrar en este todos los servidores.

Solo debe crear varios servicios de sincronización de almacenamiento si tiene:

• distintos conjuntos de servidores que nunca deben intercambiar datos. En este caso, debe diseñar el sistema para excluir determinados conjuntos de servidores que se van a sincronizar con un recurso compartido de archivos de Azure que ya está en uso como punto de conexión en la nube en un grupo de sincronización de un servicio de sincronización de almacenamiento diferente. Otra forma de ver esto es que los servidores de Windows Server registrados en un servicio de sincronización de almacenamiento distinto no se pueden sincronizar con el mismo recurso compartido de archivos de Azure.
• necesidad de tener más grupos de sincronización o servidores registrados de los que un único servicio de sincronización de almacenamiento puede admitir. Para más información, revise los Objetivos de escalabilidad de Azure File Sync.

Plan para topologías de sincronización equilibrada

Antes de implementar los recursos, es importante planear lo que va a sincronizar en un servidor local, con el recurso compartido de archivos de Azure. La realización de un plan le ayudará a determinar el número de cuentas de almacenamiento, recursos compartidos de archivos de Azure y recursos de sincronización que necesitará. Estas consideraciones siguen siendo pertinentes, incluso si los datos no residen actualmente en Windows Server o en el servidor que quiere usar a largo plazo. La sección de migración puede ayudar a determinar las rutas de migración adecuadas para su situación.

En este paso, establecerá cuántos recursos compartidos de archivos de Azure se necesitan. Una sola instancia de Windows Server (o clúster) puede sincronizar hasta 30 recursos compartidos de archivos de Azure.

Es posible que tenga más carpetas en los volúmenes que actualmente comparte localmente como recursos compartidos de SMB en sus usuarios y aplicaciones. La manera más sencilla de visualizar este escenario es imaginar un recurso compartido local que asigne 1:1 a un recurso compartido de archivos de Azure. Si tiene un número suficientemente pequeño de recursos compartidos, por debajo de 30 para una sola instancia de Windows Server, se recomienda una asignación 1:1.

Si tiene más de 30 recursos compartidos, a menudo no es necesaria la asignación 1:1 de recursos compartidos locales a un recurso compartido de archivos de Azure. Considere las opciones siguientes.

Agrupación de recursos compartidos

Por ejemplo, si el departamento de RR. HH. tiene 15 recursos compartidos, podría considerar la posibilidad de almacenar todos los datos de RR. HH. en un solo recurso compartido de archivos de Azure. El almacenamiento de varios recursos compartidos locales en un recurso compartido de archivos de Azure no evita que tenga que crear los 15 recursos compartidos de SMB habituales en la instancia local de Windows Server. Solo significa que organiza las carpetas raíz de estos 15 recursos compartidos como subcarpetas en una carpeta común. A continuación, sincronizará esta carpeta común con un recurso compartido de archivos de Azure. De este modo, solo se necesita un único recurso compartido de archivos de Azure en la nube para este grupo de recursos compartidos locales.

Sincronización de volúmenes

Azure File Sync admite la sincronización de la raíz de un volumen con un recurso compartido de archivos de Azure. Si sincroniza la raíz del volumen, todas las subcarpetas y los archivos van al mismo recurso compartido de archivos de Azure.

La sincronización de la raíz del volumen no siempre es la mejor opción. La sincronización de varias ubicaciones ofrece varias ventajas. Por ejemplo, ayuda a disminuir el número de elementos por ámbito de sincronización. Probamos los recursos compartidos de archivos de Azure y Azure File Sync con 100 millones de elementos (archivos y carpetas) por recurso compartido. Pero un procedimiento es intentar mantener el número por debajo de 20 o 30 millones en un solo recurso compartido. La configuración de Azure File Sync con un número de elementos menor no solo es beneficiosa para la sincronización de archivos. Un menor número de elementos también beneficia a escenarios como estos:

• El examen inicial del contenido de la nube puede realizarse más rápido, lo que a su vez reduce la espera de que aparezca el espacio de nombres en un servidor habilitado para Azure File Sync.
• La restauración en la nube a partir de una instantánea de recursos compartidos de archivos de Azure se hará con mayor rapidez.
• La recuperación ante desastres de un servidor local puede acelerarse de forma considerable.
• Los cambios hechos directamente en un recurso compartido de archivos de Azure (sin sincronización) se pueden detectar y sincronizar más rápido.

Sugerencia

Si no está seguro de cuántos archivos y carpetas tiene, consulte la herramienta TreeSize de JAM Software GmbH.

Un enfoque estructurado de una asignación de implementación

Antes de implementar el almacenamiento en la nube en un paso posterior, es importante crear una asignación entre carpetas locales y recursos compartidos de archivos de Azure. Esta asignación informará de cuántos recursos del grupo de sincronización de Azure File Sync se van a aprovisionar y de cuáles van a ser. Un grupo de sincronización está relacionado con el recurso compartido de archivos de Azure y la carpeta de su servidor, y establece una conexión de sincronización.

Para decidir cuántos recursos compartidos de archivos de Azure necesita, revise los límites y procedimientos recomendados siguientes. Eso le va a ayudar a optimizar la asignación.

• Un servidor donde está instalado el agente de Azure File Sync puede sincronizarse con hasta 30 recursos compartidos de archivos de Azure.

• Un recurso compartido de archivos de Azure se implementa en una cuenta de almacenamiento. Esta disposición hace que la cuenta de almacenamiento sea un destino de escalado para los números de rendimiento, como IOPS y rendimiento.

  Preste atención a las limitaciones de IOPS de una cuenta de almacenamiento al implementar recursos compartidos de archivos de Azure. Lo ideal sería asignar recursos compartidos de archivos 1:1 con cuentas de almacenamiento. Pero quizás no sea posible debido a diversos límites y restricciones, tanto de su organización como de Azure. Cuando no sea posible tener un solo recurso compartido de archivos implementado en una cuenta de almacenamiento, tenga en cuenta qué recursos compartidos estarán muy activos y cuales estarán menos activos, con el fin de asegurarse de que los recursos compartidos de archivos más activos no se colocan en la misma cuenta de almacenamiento.

  Si tiene previsto mover una aplicación a Azure que usará el recurso compartido de archivos de Azure de forma nativa, es posible que necesite un mayor rendimiento del recurso compartido de archivos de Azure. Si este tipo de uso es una posibilidad, incluso en el futuro, lo mejor es crear un único recurso compartido de archivos de Azure estándar en su propia cuenta de almacenamiento.

• Hay un límite de 250 cuentas de almacenamiento por suscripción por cada región de Azure.

Sugerencia

Teniendo en cuenta esta información, suele ser necesario agrupar varias carpetas de nivel superior de sus volúmenes en un nuevo directorio raíz común. Luego se sincroniza este nuevo directorio raíz y todas las carpetas agrupadas en él, en un solo recurso compartido de archivos de Azure. Esta técnica permite permanecer dentro del límite de 30 sincronizaciones de recursos compartidos de archivos de Azure por servidor.

Esta agrupación bajo una raíz común no afecta al acceso a sus datos. Las ACL se mantienen como están. Solo tiene que ajustar algunas rutas de acceso a los recursos compartidos (como las de los recursos compartidos SMB o NFS) que podría haber en las carpetas de servidor locales que ahora han cambiado a una raíz común. No cambia nada más.

Importante

El vector de escala más importante para Azure File Sync es el número de elementos (archivos y carpetas) que tienen que sincronizarse. Para más información, revise los objetivos de escala de Azure File Sync.

Se recomienda mantener bajo el número de elementos por ámbito de sincronización. Ese es un factor importante que se debe tener en cuenta en la asignación de carpetas a recursos compartidos de archivos de Azure. Azure File Sync se prueba con 100 millones elementos (archivos y carpetas) por recurso compartido. Pero a menudo es mejor mantener el número de elementos por debajo de 20 o 30 millones en un solo recurso compartido. Divida el espacio de nombres en varios recursos compartidos si empieza a superar estos números. Puede seguir agrupando varios recursos compartidos locales en el mismo recurso compartido de archivos de Azure, siempre y cuando se mantenga aproximadamente por debajo de estos números. Esto le proporcionará más espacio para crecer.

En una situación tal, es posible que un conjunto de carpetas pueda sincronizarse de forma lógica con el mismo recurso compartido de archivos de Azure (mediante el nuevo enfoque de carpeta raíz común mencionado anteriormente). Pero puede que siga siendo mejor reagrupar carpetas de modo que se sincronicen con dos recursos compartidos de archivos de Azure en lugar de uno. Puede usar este enfoque para mantener equilibrado el número de archivos y carpetas por recurso compartido de archivos en el servidor. También puede dividir los recursos compartidos locales y sincronizarlos entre más servidores locales, lo que agrega la posibilidad de sincronizar 30 recursos compartidos de archivos de Azure más por cada servidor adicional.

Escenarios y consideraciones comunes de sincronización de archivos

#	Escenario de sincronización	Compatible	Consideraciones (o limitaciones)	Solución (o solución alternativa)
1	Servidor de archivos con varios discos o volúmenes y varios recursos compartidos en el mismo recurso compartido de archivos de Azure de destino (consolidación)	No	Un recurso compartido de archivos de Azure de destino (punto de conexión en la nube) solo admite la sincronización con un grupo de sincronización. Un grupo de sincronización solo admite un punto de conexión de servidor por servidor registrado.	1) Comience con la sincronización de un disco (su volumen raíz) para el recurso compartido de archivos de Azure de destino. Empezar con el disco o volumen más grande, ayudará con los requisitos de almacenamiento locales. Configure la nube por niveles para organizar en capas todos los datos en la nube, lo que libera espacio en el disco del servidor de archivos. Mueva datos de otros volúmenes o recursos compartidos al volumen actual que se está sincronizando. Continúe los pasos uno por uno hasta que todos los datos estén en capas en la nube o migrados. 2) Tenga un solo volumen raíz (disco) como destino a la vez. Use la nube por niveles para organizar en capas todos los datos para tener como destino el recurso compartido de archivos de Azure. Quite el punto de conexión de servidor del grupo de sincronización, vuelva a crear el punto de conexión con el siguiente volumen o disco raíz, sincronice y repita el proceso. Nota: Es posible que sea necesario volver a instalar el agente. 3) Se recomienda usar varios recursos compartidos de archivos de Azure de destino (misma o diferente cuenta de almacenamiento en función de los requisitos de rendimiento)
2	Servidor de archivos con un único volumen y varios recursos compartidos en el mismo recurso compartido de archivos de Azure de destino (consolidación)	Sí	No se pueden tener varios puntos de conexión de servidor por servidor registrado que se sincronicen con el mismo recurso compartido de archivos de Azure de destino (igual que anteriormente)	Sincronice la raíz del volumen que contiene varios recursos compartidos o carpetas de nivel superior. Consulte Concepto de agrupación de recursos compartidos y Sincronización de volúmenes para obtener más información.
3	Servidor de archivos con varios recursos compartidos o volúmenes en varios recursos compartidos de archivos de Azure en una sola cuenta de almacenamiento (asignación de recursos compartidos de 1:1)	Sí	Una sola instancia de Windows Server (o clúster) puede sincronizar hasta 30 recursos compartidos de archivos de Azure. Una cuenta de almacenamiento es un destino de escalado para el rendimiento. IOPS y el rendimiento se comparten entre recursos compartidos de archivos. Mantenga el número de elementos por grupo de sincronización por debajo de 100 millones de elementos (archivos y carpetas) por recurso compartido. Idealmente, es mejor permanecer por debajo de 20 o 30 millones por recurso compartido.	1) Use varios grupos de sincronización (número de grupos de sincronización = número de recursos compartidos de archivos de Azure con los que sincronizar). 2) Solo se pueden sincronizar 30 recursos compartidos en este escenario a la vez. Si tiene más de 30 recursos compartidos en ese servidor de archivos, use el concepto de agrupación de recursos compartidos y la sincronización de volúmenes para reducir el número de carpetas raíz o de nivel superior en el origen. 3) Use servidores File Sync adicionales locales y divida o mueva datos a estos servidores para solucionar las limitaciones del servidor Windows de origen.
4	Servidor de archivos con varios recursos compartidos o volúmenes en varios recursos compartidos de archivos de Azure en una cuenta de almacenamiento diferente (asignación de recursos compartidos de 1:1)	Sí	Una sola instancia de Windows Server (o clúster) puede sincronizar hasta 30 recursos compartidos de archivos de Azure (la misma cuenta de almacenamiento o una diferente). Mantenga el número de elementos por grupo de sincronización por debajo de 100 millones de elementos (archivos y carpetas) por recurso compartido. Idealmente, es mejor permanecer por debajo de 20 o 30 millones por recurso compartido.	El mismo enfoque que más arriba
5	Varios servidores de archivos con un único (volumen raíz o recurso compartido) en el mismo recurso compartido de archivos de Azure de destino (consolidación)	No	Un grupo de sincronización no puede usar el punto de conexión en la nube (recurso compartido de archivos de Azure) ya configurado en otro grupo de sincronización. Aunque un grupo de sincronización puede tener puntos de conexión de servidor en distintos servidores de archivos, los archivos no pueden ser distintos.	Siga las instrucciones del escenario n.º 1 anterior con una consideración adicional sobre tener un único servidor de archivos como destino a la vez.

Creación de una tabla de asignación

Use la información anterior para decidir cuántos recursos compartidos de archivos de Azure necesita, y qué partes de los datos existentes terminarán en cuál recurso compartido de archivos de Azure.

Cree una tabla para registrar sus ideas, de modo que pueda consultarla cuando sea necesario. La organización es importante, ya que puede ser fácil perder detalles del plan de asignación cuando se aprovisionan muchos recursos de Azure a la vez. Descargue el siguiente archivo de Excel para usarlo como plantilla para ayudar a crear la asignación.

Descargue una plantilla de asignación de espacios de nombres.

Consideraciones sobre el servidor de archivos de Windows

Para habilitar la funcionalidad de sincronización en Windows Server, es preciso instalar el agente de Azure File Sync, que se puede descargar. Este agente proporciona dos componentes principales: FileSyncSvc.exe, el servicio de Windows en segundo plano responsable de supervisar los cambios en los puntos de conexión del servidor e iniciar sesiones de sincronización, y StorageSync.sys, un filtro del sistema de archivos que permite la organización de la nube por niveles y una rápida recuperación ante desastres.

Requisitos de sistema operativo

Azure File Sync es compatible con las siguientes versiones de Windows Server:

Versión	SKU compatibles	Opciones de implementación compatibles
Windows Server 2025	Azure, Datacenter, Essentials, Standard e IoT	Full y Core
Windows Server 2022	Azure, Datacenter, Essentials, Standard e IoT	Full y Core
Windows Server 2019	Datacenter, Essentials, Standard e IoT	Full y Core
Windows Server 2016	Datacenter, Essentials, Standard y Storage Server	Full y Core
Windows Server 2012 R2*	Datacenter, Essentials, Standard y Storage Server	Full y Core

*Requiere descargar e instalar Windows Management Framework (WMF) 5.1. El paquete adecuado que hay que descargar e instalar para Windows Server 2012 R2 es Win8.1AndW2K12R2-KB*******-x64.msu.

Las versiones futuras de Windows Server se agregarán tan pronto como se publiquen.

Importante

Se recomienda mantener sincronizadas todas las instancias que use con Azure File Sync con las actualizaciones más recientes de Windows Update.

Recursos mínimos del sistema

Azure File Sync requiere un servidor, físico o virtual, con al menos una CPU, un mínimo de 2 GiB de memoria y un volumen conectado localmente con el sistema de archivos NTFS.

Importante

Si el servidor se ejecuta en una máquina virtual con la memoria dinámica habilitada, la máquina debe configurarse con un mínimo de 2048 MiB de memoria.

En la mayoría de las cargas de trabajo de producción, no se recomienda configurar un servidor de Azure File Sync que tenga los requisitos mínimos. Para más información, consulte el artículo en el que se indican los recursos del sistema recomendados.

Recursos del sistema recomendados

Al igual que cualquier característica del servidor o aplicación, los requisitos de los recursos del sistema para Azure File Sync los determina la escala de la implementación; cuanto mayores sean las implementaciones en un servidor más recursos del sistema requerirán. En el caso de Azure File Sync, la escala la determinada el número de objetos en los puntos de conexión del servidor y en la renovación en el conjunto de datos. Un servidor individual puede tener puntos de conexión de servidor en varios grupos de sincronización y el número de objetos enumerados en la tabla siguiente tiene en cuenta el espacio de nombres completo al que está asociado un servidor.

Por ejemplo, el punto de conexión del servidor A con 10 millones de objetos + el punto de conexión de servidor B con 10 millones de objetos = 20 millones de objetos. Para esa implementación de ejemplo, se recomienda usar 8 CPU y 16 GiB de memoria para el estado estable y, si es posible, 48 GiB de memoria para la migración inicial.

Los datos del espacio de nombres se almacenan en la memoria por motivos de rendimiento. Por eso, los espacios de nombres más grandes requieren más memoria para mantener un buen rendimiento, y una mayor renovación requiere más CPU para procesar.

En la tabla siguiente, se proporcionan tanto el tamaño del espacio de nombres como una conversión a la capacidad para los recursos compartidos de archivos de uso general típicos, donde el tamaño medio de los archivos es de 512 KiB. Si el tamaño de los archivos es menor, considere la posibilidad de agregar memoria adicional para la misma cantidad de capacidad. Base la configuración de memoria en el tamaño del espacio de nombres.

Tamaño del espacio de nombres: archivos y directorios (millones)	Capacidad típica (TiB)	Núcleos de CPU	Memoria recomendada (GiB)
3	1.4	2	8 (sincronización inicial)/2 (renovación típica)
5	2.3	2	16 (sincronización inicial)/4 (renovación típica)
10	4,7	4	32 (sincronización inicial)/8 (renovación típica)
30	14,0	8	48 (sincronización inicial)/16 (renovación típica)
50	23,3	16	64 (sincronización inicial)/32 (renovación típica)
100*	46,6	32	128 (sincronización inicial)/32 (renovación típica)

*No se recomienda sincronizar más de 100 millones de archivos y directorios. Este límite es flexible y se basa en los umbrales que hemos probado. Para más información, consulte Objetivos de escalabilidad de Azure File Sync.

Sugerencia

La sincronización inicial de un espacio de nombres es una operación intensiva y se recomienda asignar más memoria hasta que se complete la sincronización inicial. Esto no es necesario, pero puede acelerar la sincronización inicial.

La renovación típica es el 0,5 % del espacio de nombres que cambia por día. Para mayores niveles de renovación, considere la posibilidad de agregar más CPU.

Cmdlet de evaluación

Antes de implementar Azure File Sync, debe evaluar si es compatible con el sistema mediante el cmdlet de evaluación de Azure File Sync. Este cmdlet busca posibles problemas con el sistema de archivos y el conjunto de datos, tales como caracteres no admitidos o una versión de sistema operativo no compatible. Las comprobaciones incluyen la mayoría de las características que se mencionan a continuación, pero no todas; se recomienda que lea el resto de esta sección detenidamente para asegurarse de que la implementación se realiza sin problemas.

El cmdlet de evaluación se puede instalar mediante el módulo Az de PowerShell, que se puede instalar siguiendo estas instrucciones: Instale y configure Azure PowerShell.

Uso

Puede invocar la herramienta de evaluación de varias maneras diferentes: puede realizar las comprobaciones del sistema, las comprobaciones del conjunto de datos o ambas. Para realizar las comprobaciones del sistema y el conjunto de datos:

Invoke-AzStorageSyncCompatibilityCheck -Path <path>

Para probar solo el conjunto de datos:

Invoke-AzStorageSyncCompatibilityCheck -Path <path> -SkipSystemChecks

Para probar solo los requisitos del sistema:

Invoke-AzStorageSyncCompatibilityCheck -ComputerName <computer name> -SkipNamespaceChecks

Para mostrar los resultados en CSV:

$validation = Invoke-AzStorageSyncCompatibilityCheck C:\DATA
$validation.Results | Select-Object -Property Type, Path, Level, Description, Result | Export-Csv -Path C:\results.csv -Encoding utf8

Compatibilidad del sistema de archivos

Azure File Sync solo se admite en volúmenes NTFS conectados directamente. El almacenamiento conectado directamente, o DAS, en Windows Server significa que el sistema operativo Windows Server es el propietario del sistema de archivos. DAS se puede proporcionar mediante discos conectados físicamente al servidor de archivos, para lo que se conectan discos virtuales a una máquina virtual servidor de archivos (como una máquina virtual hospedada por Hyper-V), o incluso mediante ISCSI.

Solo se admiten volúmenes NTFS; ReFS, FAT, FAT32 y otros sistema de archivos no se admiten.

La siguiente tabla muestra el estado de interoperabilidad de las características del sistema de archivos NTFS:

Característica	Compatibilidad con el estado	Notas
Listas de control de acceso (ACL)	totalmente compatible	Azure File Sync conserva las listas de control de acceso discrecional con estilo Windows y Windows Server las exige en los puntos de conexión de servidor. También se pueden exigir listas de control de acceso cuando el recurso compartido de archivos de se monta directamente; sin embargo, esto requiere configuración adicional. Para más información, consulte la sección acerca de la identidad.
Vínculos físicos	Omitido
Vínculos simbólicos	Omitido
Puntos de montaje	Compatibilidad parcial	Los puntos de montaje podrían ser la raíz de un punto de conexión de servidor, pero se omiten si están incluidos en el espacio de nombres del punto de conexión de servidor.
Uniones	Omitido	Por ejemplo, las carpetas DfrsrPrivate y DFSRoots del Sistema de archivos distribuido.
Puntos de repetición de análisis	Omitido
Compresión NTFS	Parcialmente compatible	Azure File Sync no admite puntos de conexión de servidor ubicados en un volumen que tenga el directorio de información del volumen del sistema (SVI) comprimido.
Archivos dispersos	totalmente compatible	Los archivos dispersos se sincronizan (no se bloquean), pero lo hacen con la nube como un archivo completo. Si se cambia el contenido del archivo en la nube (o en otro servidor), el archivo ya no estará disperso cuando el cambio se haya descargado.
Flujos de datos alternativos (ADS)	Conservados, pero no sincronizados	Por ejemplo, las etiquetas de clasificación creadas por la infraestructura de clasificación de archivos no están sincronizadas. Las etiquetas de clasificación existentes en los archivos en cada uno de los puntos de conexión del servidor se dejan como están.

Azure File Sync también omitirá ciertos archivos temporales y carpetas del sistema:

Archivo/carpeta	Nota:
pagefile.sys	Archivo específico del sistema
Desktop.ini	Archivo específico del sistema
thumbs.db	Archivo temporal para miniaturas
ehthumbs.db	Archivo temporal para miniaturas de elementos multimedia
~$*.*	Archivo temporal de Office
*.tmp	Archivo temporal
*.laccdb	Archivo de bloqueo de base de datos de Access
635D02A9D91C401B97884B82B3BCDAEA.*	archivo de sincronización interno
\System Volume Information	Carpeta específica del volumen
$RECYCLE.BIN	Carpeta
\SyncShareState	carpeta de sincronización
.SystemShareInformation	Carpeta para la sincronización en el recurso compartido de archivos de Azure

Nota:

Aunque Azure File Sync admite la sincronización de archivos de base de datos, las bases de datos no son una buena carga de trabajo para las soluciones de sincronización (incluida Azure File Sync), ya que los archivos de registro y las bases de datos deben sincronizarse juntos y pueden salir de la sincronización por varias razones que podrían provocar daños en la base de datos.

Tenga en cuenta la cantidad de espacio disponible que necesita en el disco local.

Al planear el uso de Azure File Sync, tenga en cuenta la cantidad de espacio disponible que necesita en el disco local en el que piensa tener un punto de conexión de servidor.

Con Azure File Sync, deberá tener en cuenta lo siguiente para tener espacio en el disco local:

• Con la nube por niveles habilitada:

  • Puntos de repetición de análisis para archivos en capas
  • Base de datos de metadatos de Azure File Sync
  • Almacén térmico de Azure File Sync
  • Archivos totalmente descargados en la caché de acceso frecuente (de existir)
  • Requisitos de la directiva de espacio disponible del volumen

• Con la nube por niveles deshabilitada:

  • Archivos totalmente descargados
  • Almacén térmico de Azure File Sync
  • Base de datos de metadatos de Azure File Sync

Usaremos un ejemplo para ilustrar cómo calcular la cantidad de espacio disponible que se necesita en el disco local. Supongamos que ha instalado el agente de Azure File Sync en una VM Windows de Azure y tiene pensado crear un punto de conexión de servidor en el disco F. Tiene 1 millón de archivos y le gustaría crear niveles de todos ellos, 100 000 directorios y un tamaño de clúster de disco de 4 KiB. El tamaño del disco es de 1000 GiB. Quiere habilitar la nube por niveles y establecer la directiva de espacio libre del volumen en el 20 %.

1. NTFS asigna un tamaño de clúster para cada uno de los archivos en capas. 1 millón de archivos * tamaño de clúster de 4 KiB = 4 000 000 KiB (4 GiB)

   Nota:

   Para beneficiarse completamente de la nube por niveles, se recomienda usar tamaños de clúster NTFS más pequeños (menos de 64KiB), ya que cada archivo en capas ocupa un clúster. Además, NTFS asigna el espacio ocupado por los archivos en capas. Por lo tanto, no se mostrará en ninguna interfaz de usuario.

2. Los metadatos de sincronización ocupan un tamaño de clúster por elemento. (1 millón de archivos + 100 000 directorios) * tamaño del clúster de 4 KiB = 4 400 000 KiB (4,4 GiB)
3. El almacén térmico de Azure File Sync ocupa 1,1 KiB por archivo. 1 millón de archivos * 1,1 KiB = 1 100 000 KiB (1,1 GiB)
4. La directiva de espacio disponible del volumen es del 20 %. 1000 GiB * 0,2 = 200 GiB

En este caso, Azure File Sync necesitaría unos 209 500 000 KiB (209,5 GiB) de espacio para este espacio de nombres. Agregue esta cantidad a cualquier espacio disponible adicional que desee para averiguar cuánto espacio libre se necesita para este disco.

Clústeres de conmutación por error

1. La característica de clústeres de conmutación por error de Windows es compatible con Azure File Sync en la opción de implementación "Servidor de archivos para uso general". Para más información sobre cómo configurar el rol "Servidor de archivos para uso general" en un clúster de conmutación por error, consulte Implementación de un servidor de archivos en clúster de dos nodos.
2. El único escenario admitido por Azure File Sync es el clúster de conmutación por error de Windows Server con discos en clúster.
3. La característica de clústeres de conmutación por error no se admite en "Servidor de archivos de escalabilidad horizontal para datos de aplicación" (SOFS) o en volúmenes compartidos de clúster (CSV) o discos locales.

Nota:

El agente de Azure File Sync debe estar instalado en cada nodo de un clúster de conmutación por error para que la sincronización funcione correctamente.

Desduplicación de datos

Windows Server 2025, Windows Server 2022, Windows Server 2019 y Windows Server 2016
Ahora se admite la desduplicación de datos independientemente de si la nube por niveles está habilitada o deshabilitada en uno o varios puntos de conexión de servidor del volumen para Windows Server 2016, Windows Server 2019, Windows Server 2022 y Windows Server 2025. Habilitar la desduplicación de datos en un volumen con la nube por niveles habilitada, le permite almacenar en caché más archivos en el entorno local sin necesidad de aprovisionar más almacenamiento.

Cuando la desduplicación de datos está habilitada en un volumen con la nube por niveles habilitada, los archivos optimizados para desduplicación dentro de la ubicación del punto de conexión del servidor se organizan en niveles de forma similar a un archivo normal en función de la configuración de la directiva de la nube por niveles. Una vez que los archivos optimizados para la desduplicación se han organizado en niveles, el trabajo de recolección de elementos no utilizados de desduplicación de datos se ejecutará automáticamente para recuperar el espacio en disco mediante la eliminación de fragmentos innecesarios a los que ya no hacen referencia otros archivos del volumen.

Tenga en cuenta que el ahorro de volumen solo se aplica al servidor; los datos del recurso compartido de Azure no se desduplicarán.

Nota:

Para admitir la desduplicación de datos en volúmenes con una nube por niveles habilitada en Windows Server 2019, se debe instalar la actualización de Windows KB4520062, de octubre de 2019 o una actualización acumulativa mensual posterior.

Windows Server 2012 R2
Azure File Sync no admite la desduplicación de datos y la nube por niveles en el mismo volumen en Windows Server 2012 R2. Si la desduplicación de datos está habilitada en un volumen, se debe deshabilitar la nube por niveles.

Notas

• Si la desduplicación de datos está instalada antes de instalar el agente de Azure File Sync, es necesario reiniciar para que se admita en el mismo volumen la desduplicación de datos y la nube por niveles.

• Si habilita la desduplicación de datos en un volumen después de haber habilitado la nube por niveles, el trabajo inicial de optimización por desduplicación optimiza los archivos del volumen que no están aún en niveles, y tendrá la siguiente repercusión en la nube por niveles:

  • La directiva de espacio disponible seguirá colocando los archivos en niveles según el espacio libre en el volumen mediante el uso del mapa térmico.
  • La directiva de fecha omitirá la organización en niveles de los archivos, que podrían haber sido en otra situación aptos para niveles, ya que el trabajo de optimización por desduplicación tiene acceso a los archivos.

• Para los trabajos de optimización por desduplicación en curso, el valor de desduplicación de datos MinimumFileAgeDays, retrasará la nube por niveles con directiva de fecha, si el archivo no está colocado ya en un nivel.

  • Ejemplo: Si el valor MinimumFileAgeDays es de siete días y la directiva de fecha de nube por niveles es de 30 días, la directiva de fecha colocará los archivos en niveles pasados 37 días.
  • Nota: Una vez que Azure File Sync haya colocado un archivo en un nivel, el trabajo de optimización por desduplicación omitirá el archivo.

• Si un servidor que ejecuta Windows Server 2012 R2 y que tiene instalado el agente de Azure File Sync se actualiza a Windows Server 2016, Windows Server 2019, Windows Server 2022 o Windows Server 2025, es necesario realizar los pasos siguientes para que se pueda admitir en el mismo volumen la desduplicación de datos y la nube por niveles:

  • Desinstalar al agente de Azure File Sync para Windows Server 2012 R2 y reiniciar el servidor.
  • Descargar al agente de Azure File Sync para la versión de sistema operativo del nuevo servidor (Windows Server 2016, Windows Server 2019, Windows Server 2022 o Windows Server 2025).
  • Instalar el agente de Azure File Sync y reiniciar el servidor.

  Nota: Los valores de configuración de Azure File Sync en el servidor se conservan cuando el agente se desinstala y reinstala.

Sistema de archivos distribuido (DFS)

Azure File Sync admite la interoperabilidad con espacios de nombres DFS (DFS-N) y la replicación DFS (DFS-R).

Espacios de nombres DFS (DFS-N): Azure File Sync es totalmente compatible con una implementación DFS-N. Puede instalar el agente de Azure File Sync en uno o varios servidores de archivos para sincronizar los datos entre los puntos de conexión del servidor y el punto de conexión en la nube y, a continuación, usar DFS-N para proporcionar el servicio de espacio de nombres. Para obtener más información, consulte Introducción a los espacios de nombres DFS y Espacios de nombres DFS con Azure Files.

Replicación DFS (DFS-R) : puesto que DFS-R y Azure File Sync son soluciones de replicación, en la mayoría de los casos, se recomienda reemplazar DFS-R por Azure File Sync. Hay, sin embargo, varios escenarios donde puede que desee usar DFS-R y Azure File Sync conjuntamente:

• Va a migrar desde una implementación de DFS-R a una implementación de Azure File Sync. Para más información, consulte Migrate a DFS Replication (DFS-R) deployment to Azure File Sync (Migración de una implementación de la replicación DFS (DFS-R) a Azure File Sync).
• No todos los servidores locales que necesitan una copia de los datos de archivo pueden estar conectados directamente a Internet.
• Los servidores de sucursales consolidan los datos en un único servidor central, para el que le gustaría utilizar Servidores de sucursales consolidan los datos en un único servidor concentrador, le gustaría utilizar Azure File Sync.

Para que Azure File Sync y DFS-R trabajen en paralelo:

1. Los niveles de nube de Azure File Sync deben deshabilitarse en volúmenes con carpetas replicadas DFS-R.
2. Los puntos de conexión de servidor no se deben configurar en carpetas de replicación de solo lectura DFS-R.
3. Solo un punto de conexión de servidor puede superponerse con una ubicación DFS-R. Varios puntos de conexión de servidor superpuestos con otras ubicaciones DFS-R activas pueden provocar conflictos.

Para más información, consulte Introducción a Espacios de nombres DFS y Replicación DFS.

Sysprep

No se admite la ejecución de sysprep en un servidor que tenga instalado el agente de Azure File Sync y esto puede provocar resultados inesperados. La instalación del agente y el registro del servidor se deben realizar después de implementar la imagen del servidor y completar la instalación mínima de sysprep.

Windows Search

Si en un punto de conexión de un servidor están habilitados los niveles en la nube, Windows Search omite y no indexa los archivos que están en capas. Los archivos que no están en capas se indexan correctamente.

Nota:

Los clientes de Windows provocarán recuperaciones al buscar en el recurso compartido de archivos si la configuración Buscar siempre en los nombres y el contenido de los archivos está habilitada en la máquina cliente. Este valor está deshabilitado de forma predeterminada.

Otras soluciones de administración de almacenamiento jerárquico (HSM)

No deben utilizarse otras soluciones HSM deben utilizarse con Azure File Sync.

Escalabilidad y rendimiento

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 archivos, las características de rendimiento de una solución basada en Azure File Sync se mide mejor en el número de objetos (archivos y directorios) que se procesan por segundo.

Los cambios realizados en el recurso compartido de archivos de Azure mediante Azure Portal o SMB no se detectan y replican de forma inmediata como cambios en el punto de conexión del servidor. Azure Files aún no dispone de registros en diario o notificaciones, por lo que no hay manera de iniciar automáticamente una sesión de sincronización cuando se cambian los archivos. En Windows Server, Azure File Sync usa el registro en diario de USN de Windows para iniciar automáticamente una sesión de sincronización cuando cambian los archivos.

Para detectar cambios en el recurso compartido de archivos de Azure, Azure File Sync tiene un trabajo programado que se denomina trabajo de detección de cambios. Un trabajo de detección de cambios enumera todos los archivos del recurso compartido de archivos y, a continuación, los compara con la versión de sincronización correspondiente. Cuando el trabajo de detección de cambios determina qué archivos han cambiado, Azure File Sync inicia una sesión de sincronización. El trabajo de detección de cambios se inicia cada 24 horas. Dado que el trabajo de detección de cambios enumera todos los archivos del recurso compartido de archivos de Azure, la detección de cambios tarda más en los espacios de nombres más largos que los espacios de nombres más cortos. En el caso de los espacios de nombres largos, es posible que sea necesario determinar más de una vez cada 24 horas qué archivos han cambiado.

Para obtener más información, consulte Métricas de rendimiento de Azure File Sync y Objetivos de escalabilidad de Azure File Sync.

identidad

Azure File Sync funciona con su identidad basada en AD estándar sin ninguna configuración especial más allá de configurar la sincronización. Cuando se usa Azure File Sync, la expectativa general es que la mayor parte de los accesos atraviesen los servidores de almacenamiento en caché de Azure File Sync, en lugar del recurso compartido de archivos de Azure. Dado que los puntos de conexión del servidor se encuentran en Windows Server y que Windows Server ha admitido listas de control de acceso de estilo AD y Windows durante mucho tiempo, lo único que se necesita es asegurarse de que los servidores de archivos de Windows registrados en el servicio de sincronización de almacenamiento están unidos a un dominio. Azure File Sync almacenará las listas de control de acceso en los archivos del recurso compartido de archivos de Azure y los replicará en todos los puntos de conexión del servidor.

Aunque los cambios que se realizan directamente en el recurso compartido de archivos de Azure tardarán más tiempo en sincronizarse con los puntos de conexión del servidor del grupo de sincronización, es posible que también quiera asegurarse de que también puede aplicar sus permisos de AD DS en su recurso compartido de archivos directamente en la nube. Para ello, debe unir a un dominio su cuenta de almacenamiento a su AD local de la misma forma que los servidores de archivos de Windows se unen a un dominio. Para más información acerca de la unión a un dominio de una cuenta de almacenamiento a una instancia de Active Directory propiedad de un cliente, consulte la introducción a Active Directory de Azure Files.

Importante

La unión a un dominio de una cuenta de almacenamiento a Active Directory no es necesaria para implementar Azure File Sync correctamente. Este es un paso estrictamente opcional que permite al recurso compartido de archivos de Azure exigir listas de control de acceso locales cuando los usuarios montan el recurso compartido de archivos de Azure directamente.

Redes

El agente de Azure File Sync se comunica con su servicio de sincronización del almacenamiento y el recurso compartido de archivos de Azure mediante los protocolos REST y FileREST de Azure File Sync, ambos usan siempre HTTPS sobre el puerto 443. SMB nunca se usa para cargar o descargar datos entre Windows Server y el recurso compartido de archivos de Azure. Dado que la mayoría de las organizaciones permiten el tráfico HTTPS sobre el puerto 443, como requisito para visitar la mayor parte de sitios web, normalmente no se requiere ninguna configuración especial de la red para implementar Azure File Sync.

Importante

Azure File Sync no admite el enrutamiento de Internet. La opción de enrutamiento de red predeterminada, el enrutamiento de Microsoft, es compatible con Azure File Sync.

En función de los requisitos normativos únicos y de la directiva de su organización, puede requerir una comunicación más restrictiva con Azure y, por consiguiente, Azure File Sync proporciona varios mecanismos para que configure la red. En función de sus requisitos, puede:

• Tunnel sync and file upload/download traffic sobre ExpressRoute o Azure VPN.
• Usar las características de Azure Files y Redes de Azure como los puntos de conexión de servicio y los puntos de conexión privados.
• Configurar Azure File Sync para que admita su proxy en su entorno.
• Limitar la actividad de la red desde Azure File Sync.

Sugerencia

Si quiere comunicarse con el recurso compartido de archivos de Azure a través de SMB, pero el puerto 445 está bloqueado, considere la posibilidad de usar SMB a través de QUIC, que ofrece "VPN SMB" de configuración cero para el acceso SMB a los recursos compartidos de archivos de Azure mediante el protocolo de transporte QUIC a través del puerto 443. Aunque Azure Files no admite directamente SMB a través de QUIC, puede crear una caché ligera de los recursos compartidos de archivos de Azure en una máquina virtual de Azure Edition de Windows Server 2022 mediante Azure File Sync. Para más información sobre esta opción, consulte SMB a través de QUIC con Azure File Sync.

Para más información sobre Azure File Sync y las redes, vea Consideraciones de redes para Azure File Sync.

Cifrado

Cuando se usa Azure File Sync, hay que tener en cuenta tres capas diferentes de cifrado: cifrado en el almacenamiento en reposo de Windows Server, cifrado en tránsito entre el agente de Azure File Sync y Azure, y cifrado en reposo de los datos del recurso compartido de archivos de Azure.

Cifrado en reposo de Windows Server

Hay dos estrategias para cifrar datos en Windows Server que funcionan habitualmente con Azure File Sync: el cifrado debajo del sistema de archivos, de forma que tanto el sistema de archivos como todos los datos escritos en ella estén cifrados y el cifrado del propio formato de archivo. Estos métodos no son mutuamente excluyentes; se pueden usar conjuntamente si se desea, ya que el fin del cifrado es diferente.

Para proporcionar cifrado debajo del sistema de archivos, Windows Server ofrece la Bandeja de entrada de BitLocker. BitLocker es totalmente transparente para Azure File Sync. La razón principal para usar un mecanismo de cifrado como BitLocker es evitar la filtración física de los datos de un centro de datos local por parte de alguien que robe los discos y evitar la transferencia local de un sistema operativo no autorizado para realizar lecturas y escritura de los datos. Para más información sobre BitLocker, consulte Introducción a BitLocker.

Los productos de terceros que funcionan de forma similar a BitLocker, en que se usan al lado del volumen NTFS, deberían ser completamente transparentes para Azure File Sync.

El otro método principal para cifrar datos es cifrar el flujo de datos del archivo cuando la aplicación lo guarde. Algunas aplicaciones pueden hacerlo de forma nativa, pero esto normalmente no es el caso. Un ejemplo de un método para cifrar el flujo de datos del archivo es Azure Information Protection (AIP)/Azure Rights Management Services (Azure RMS)/Active Directory RMS. La principal razón para usar un mecanismo de cifrado como AIP/RMS es impedir la filtración de datos de un recurso compartido de archivos por parte de personas que los copien a ubicaciones alternativas, como una unidad flash, o que los envíen por correo electrónico a una persona no autorizada. Cuando el flujo de datos de un archivo se cifra como parte del formato de archivo, el archivo seguirá estando cifrado en el recurso compartido de archivos de Azure.

Azure File Sync no interopera con el Sistema de cifrado de archivos NTFS (NTFS EFS) ni con soluciones de cifrado de terceros que se encuentran por encima del sistema de archivos, pero por debajo del flujo de datos del archivo.

Cifrado en tránsito

Nota:

El servicio Azure File Sync quitará la compatibilidad con TLS 1.0 y 1.1 a partir del 1 de agosto de 2020. Todas las versiones compatibles del agente de Azure File Sync ya usan TLS 1.2 de forma predeterminada. El uso de una versión anterior de TLS podría producirse si TLS 1.2 estaba deshabilitado en el servidor o se utiliza un proxy. Si usa un proxy, se recomienda que compruebe la configuración del proxy. Las regiones del servicio Azure File Sync agregadas después del 1/5/2020 solo admiten TLS1.2. Para más información, consulte la guía para la solución de problemas.

El agente de Azure File Sync se comunica con su servicio de sincronización del almacenamiento y el recurso compartido de archivos de Azure mediante los protocolos REST y FileREST de Azure File Sync, ambos usan siempre HTTPS sobre el puerto 443. Azure File Sync no envía solicitudes sin cifrar a través de HTTP.

Las cuentas de Azure Storage contienen un modificador para requerir el cifrado en tránsito, que está habilitado de manera predeterminada. Aunque el modificador del nivel de la cuenta de almacenamiento esté deshabilitado, lo que significa que son posibles las conexiones no cifradas con los recursos compartidos de Azure, Azure File Sync solo usará canales cifrados para acceder al recurso compartido de archivos.

La razón principal para deshabilitar el cifrado en tránsito para la cuenta de almacenamiento es admitir una aplicación heredada que debe ejecutarse en un sistema operativo anterior, como Windows Server 2008 R2 o una distribución de Linux anterior, que se comunique con un recurso compartido de archivos de Azure directamente. Si la aplicación heredada se comunica con la caché de Windows Server del recurso compartido de archivos, el hecho de alternar este valor no tendrá efecto alguno.

Se recomienda encarecidamente asegurarse de que está habilitado el cifrado de los datos en tránsito.

Para obtener más información sobre el cifrado en tránsito, consulte Requerir transferencia segura en Azure Storage.

Cifrado en reposo del recurso compartido de archivos de Azure

Todos los datos almacenados en Azure Files se cifran en reposo mediante el cifrado de servicio de almacenamiento (SSE) de Azure. El cifrado del servicio de almacenamiento funciona de forma similar a BitLocker en Windows: los datos se cifran bajo el nivel del sistema de archivos. Dado que los datos se cifran bajo el sistema de archivos del recurso compartido de archivos de Azure, ya que se codifican en el disco, no es necesario tener acceso a la clave subyacente en el cliente para leer o escribir en dicho recurso compartido. El cifrado en reposo se aplica a los protocolos SMB y NFS.

De manera predeterminada, los datos almacenados en Azure Files se cifran con claves administradas por Microsoft. Con las claves administradas por Microsoft, Microsoft mantiene las claves para cifrar o descifrar los datos y es responsable de rotarlas de forma periódica. También puede elegir administrar sus propias claves, lo que le permitirá controlar el proceso de rotación. Si decide cifrar los recursos compartidos de archivos con claves administradas por el cliente, Azure Files está autorizado para tener acceso a las claves con el fin de satisfacer las solicitudes de lectura y escritura de los clientes. Con las claves administradas por el cliente, puede revocar esta autorización en cualquier momento, pero esto significa que el recurso compartido de archivos de Azure ya no será accesible a través de SMB o la API FileREST.

Azure Files usa el mismo esquema de cifrado que los otros servicios de almacenamiento de Azure, como Azure Blob Storage. Para aprender más sobre el cifrado del servicio de almacenamiento (SSE) de Azure, consulte Cifrado de Azure Storage para datos en reposo.

Niveles de almacenamiento

Azure Files ofrece dos niveles multimedia diferentes de almacenamiento, SSD y HDD, que permiten adaptar los recursos compartidos a los requisitos de rendimiento y precio de su escenario:

• SSD (Premium): recursos compartidos de archivos Premium que usan las unidades de estado sólido (SSD) y proporcionan un alto rendimiento coherente y una baja latencia, en milisegundos de un solo dígito para la mayoría de las operaciones de E/S y para cargas de trabajo intensivas de E/S. Los recursos compartidos de archivos Premium son adecuados para una amplia variedad de cargas de trabajo como bases de datos, hospedaje de sitios web y entornos de desarrollo. Los recursos compartidos de archivos Premium se pueden usar con los protocolos Bloque de mensajes del servidor (SMB) y Network File System (NFS). Los recursos compartidos de archivos Premium se implementan en la cuenta de almacenamiento de FileStorage y solo están disponibles en un modelo de facturación aprovisionado. Para más información sobre el modelo de facturación aprovisionado para recursos compartidos de archivos Premium, consulte Planeamiento de una implementación de Azure Files. Los recursos compartidos de archivos Premium ofrecen una SLA de mayor disponibilidad que los recursos compartidos de archivos estándar (consulte "Nivel Premium de Azure Files").

• HDD (estándar):los recursos compartidos de archivos estándar usan unidades de disco duro (HDD) y proporcionan una opción de almacenamiento rentable para recursos compartidos de archivos de uso general. Los recursos compartidos de archivos estándar se implementan en la cuenta de almacenamiento de tipo de cuenta de almacenamiento de uso general 2 (GPv2). Para obtener información sobre el Acuerdo de Nivel de Servicio, consulte la página de acuerdos de nivel de servicio de Azure (consulte "Cuentas de almacenamiento"). Los recursos compartidos de archivos estándar usan un modelo de pago por uso que proporciona precios basados en el uso. El nivel de acceso de un recurso compartido de archivos le permite ajustar los costos de almacenamiento con respecto al costo de IOPS para optimizar la factura total:

  • Los recursos compartidos de archivos optimizados para transacciones ofrecen los precios de transacción de menor costo para cargas de trabajo pesadas de transacciones que no necesitan la baja latencia que ofrecen los recursos compartidos de archivos premium. Se recomienda al migrar datos a Azure Files.
  • Los recursos compartidos de archivos de nivel de acceso frecuente ofrecen precios equilibrados de almacenamiento y transacciones para cargas de trabajo que realizan estos procesos en gran medida.
  • Los recursos compartidos de archivos de nivel de acceso esporádico ofrecen los precios de almacenamiento más rentable para cargas de trabajo que consumen mucho almacenamiento.

Al seleccionar un nivel multimedia para la carga de trabajo, tenga en cuenta los requisitos de rendimiento y uso. Si la carga de trabajo requiere latencia de un solo dígito o usa medios de almacenamiento SSD en el entorno local, es probable que el nivel Premium sea el mejor ajuste. Si no es muy importante que la latencia sea baja, por ejemplo, en el caso de recursos compartidos de equipo montados localmente desde Azure o almacenados en la caché local mediante Azure File Sync, desde el punto de vista del costo es posible que sea más adecuado usar el almacenamiento estándar.

Una vez que haya creado un recurso compartido de archivos en una cuenta de almacenamiento, no podrá moverlo a niveles exclusivos de diferentes tipos de cuentas de almacenamiento. Por ejemplo, para cambiar un recurso compartido de archivos optimizado para transacciones al nivel Premium, es preciso crear un recurso compartido de archivos en una cuenta de almacenamiento de FileStorage y copiar los datos desde el recurso compartido original a un nuevo recurso compartido de archivos en la cuenta de FileStorage. Se recomienda usar AzCopy para copiar datos entre recursos compartidos de archivos de Azure, pero también se pueden usar herramientas como robocopy en Windows o rsync en macOS y Linux.

Para más información, consulte Facturación de Azure Files.

Disponibilidad en regiones de Azure File Sync

Para la disponibilidad regional, consulte Productos disponibles por región.

Las siguientes regiones requieren que solicite acceso a Azure Storage antes de poder usar Azure File Sync en ellas:

• Sur de Francia
• Oeste de Sudáfrica
• Centro de Emiratos Árabes Unidos

Para solicitar acceso a estas regiones, siga el proceso de este documento.

Redundancia

Para proteger los datos de los recursos compartidos de archivos de Azure contra la pérdida o daños de los datos, Azure Files almacena varias copias de cada archivo a medida que se escriben. En función de sus requisitos, podrá seleccionar diferentes grados de redundancia. Actualmente, Azure Files admite las siguientes opciones de redundancia de datos:

• Almacenamiento con redundancia local (LRS) : con LRS, todos los archivos se almacenan tres veces dentro de un clúster de almacenamiento de Azure. Esto protege contra la pérdida de datos debido a errores de hardware, como una unidad de disco incorrecta. No obstante, si se produjera un desastre, como un incendio o una inundación en el centro de datos, es posible que todas las réplicas de las cuentas de almacenamiento que usen LRS se pierdan o no se puedan recuperar.
• Almacenamiento con redundancia de zona (ZRS): con ZRS, se almacenan tres copias de cada archivo. Sin embargo, estas copias están aisladas físicamente en tres clústeres de almacenamiento distintos en diferentes zonas de disponibilidad de Azure. Las zonas de disponibilidad son ubicaciones físicas exclusivas dentro de una región de Azure. Cada zona consta de uno o varios centros de datos equipados con alimentación, refrigeración y redes independientes. No se acepta la escritura en el almacenamiento hasta que se realice la escritura en los clústeres de almacenamiento en las tres zonas de disponibilidad.
• Almacenamiento con redundancia geográfica (GRS): con GRS, hay dos regiones, una primaria y una secundaria. Los archivos se almacenan tres veces dentro de un clúster de almacenamiento de Azure en la región primaria. Las escrituras se replican de forma asincrónica en una región secundaria definida por Microsoft. GRS proporciona seis copias de los datos distribuidas entre dos regiones de Azure. En caso de un desastre importante, como la pérdida permanente de una región de Azure debido a una catástrofe natural o a otro evento similar, Microsoft realizará una conmutación por error. En este caso, la base de datos secundaria se convertiría en la principal, atendiendo todas las operaciones. Dado que la replicación entre las regiones principal y secundaria es asincrónica, en caso de que se produzca un desastre importante, se perderán los datos que todavía no se hayan replicado en la región secundaria. También puede realizar una conmutación por error manual de una cuenta de almacenamiento con redundancia geográfica.
• Almacenamiento con redundancia de zona geográfica (GZRS): GZRS es como ZRS, pero con redundancia geográfica. Con GZRS, los archivos se almacenan tres veces en tres clústeres de almacenamiento distintos en la región primaria. Todas las escrituras se replican de forma asincrónica en una región secundaria definida por Microsoft. El proceso de conmutación por error de GZRS funciona igual que en GRS.

Los recursos compartidos de archivos estándar de Azure de hasta 5 TiB admiten los cuatro tipos de redundancia. Los recursos compartidos de archivos estándar de más de 5 TiB solo admiten LRS y ZRS. Los recursos compartidos de archivos premium de Azure solo admiten LRS y ZRS.

Las cuentas de almacenamiento de uso general versión 2 (GPv2) proporcionan otras dos opciones de redundancia que Azure Files no admite: almacenamiento con redundancia geográfica con acceso de lectura (RA-GRS) y almacenamiento con redundancia de zona geográfica con acceso de lectura (RA-GZRS). Puede aprovisionar recursos compartidos de archivos de Azure en cuentas de almacenamiento con estas opciones establecidas; sin embargo, Azure Files no admite la lectura desde la región secundaria. Los recursos compartidos de archivos de Azure implementados en cuentas de almacenamiento de RA-GRS o RA-GZRS se facturan como GRS o GZRS, respectivamente.

Importante

Tanto el almacenamiento con redundancia geográfica como el almacenamiento con redundancia de zona geográfica tienen la capacidad de realizar la conmutación por error manual en la región secundaria. Se recomienda no hacerlo si no se produce un desastre al usar Azure File Sync debido a la mayor probabilidad de pérdida de datos. En caso de desastre en el que desee iniciar una conmutación por error manual del almacenamiento, necesitará abrir un caso de soporte técnico con Microsoft para reanudar la sincronización de Azure File Sync con el punto de conexión secundario.

Migración

Si tiene un servidor de archivos de Windows 2012R2 o de una versión posterior, Azure File Sync se puede instalar directamente en su lugar, sin necesidad de trasladar los datos a un nuevo servidor. Si planea migrar a un nuevo servidor de archivos de Windows como parte de la adopción de Azure File Sync, o si los datos se encuentran actualmente en el almacenamiento conectado a la red (NAS), existen varios enfoques posibles de migración para usar Azure File Sync con estos datos. El método de migración que debe elegir depende de dónde residan los datos actualmente.

Consulte el artículo Introducción a la migración de azure File Sync y recursos compartidos de archivos de Azure para obtener instrucciones detalladas.

Antivirus

Dado que lo que hace un antivirus es examinar los archivos en busca de código malintencionado conocido, puede provocar la recuperación de archivos por niveles, lo que da lugar a cargos elevados de salida. Los archivos por niveles tienen establecido el atributo de Windows seguro FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS. Se recomienda consultar con el proveedor de software cómo configurar la solución en particular para omitir la lectura de archivos que tengan establecido este atributo (muchas veces se hace automáticamente).

Las soluciones de antivirus internas de Microsoft, Windows Defender y System Center Endpoint Protection (SCEP), omiten de forma automática la lectura de archivos que tienen establecido dicho atributo. Hemos probado ambas soluciones e identificamos un problema menor: al agregar un servidor a un grupo de sincronización existente, se recuperan (descargan) los archivos de menos de 800 bytes en el nuevo servidor. Estos archivos permanecerán en el nuevo servidor y no se organizarán en niveles ya que no cumplen con el requisito de tamaño de niveles (>64 kb).

Nota:

Los proveedores de software antivirus pueden comprobar la compatibilidad entre sus productos y Azure File Sync con Azure File Sync Antivirus Compatibility Test Suite, que está disponible para su descarga en el Centro de descarga de Microsoft.

Backup

Si está habilitada la nube por niveles, no se deben usar soluciones que realicen copias de seguridad directamente del punto de conexión de servidor o de una máquina virtual en la que se encuentre este. La nube por niveles hace que solo un subconjunto de los datos se almacene en el punto de conexión de servidor, y que el conjunto de datos completo resida en el recurso compartido de archivos de Azure. En función de la solución de copia de seguridad usada, los archivos por niveles se omitirán y no se realizará una copia de seguridad de ellos (porque tienen el conjunto de atributos FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS), o se recuperarán en el disco, lo que provocará cargos elevados de salida. Se recomienda usar una solución de copia de seguridad en la nube para realizar la copia de seguridad del recurso compartido de archivos de Azure directamente. Para más información, consulte Acerca de la copia de seguridad de recursos compartidos de archivos de Azure o póngase en contacto con el proveedor de copias de seguridad para ver si admite la copia de seguridad de recursos compartidos de Azure.

Si prefiere usar una solución de copia de seguridad local, las copias de seguridad deben realizarse en un servidor del grupo de sincronización que tenga deshabilitada la nube por niveles y asegúrese de que no hay archivos en capas. Al realizar una restauración, use las opciones de restauración de nivel de volumen o de archivo. Los archivos restaurados con la opción de restauración a nivel de archivo se sincronizarán con todos los puntos de conexión del grupo de sincronización y los archivos existentes se reemplazarán con la versión restaurada desde la copia de seguridad. Las restauraciones a nivel de volumen no reemplazarán las versiones más recientes de los archivos en el recurso compartido de archivos de Azure ni en otros puntos finales del servidor.

Nota:

La restauración con reconstrucción completa (BMR), la restauración de máquinas virtuales, la restauración del sistema operativo (restauración integrada de Windows) y la restauración a nivel de archivo con su versión en capas (esto sucede cuando el software de copia de seguridad realiza una copia de seguridad de un archivo en capas en lugar de un archivo completo) puede provocar resultados inesperados y no se admiten actualmente cuando está habilitada la nube por niveles. Las instantáneas de VSS (incluida la pestaña Versiones anteriores) se admiten en los volúmenes que tienen habilitada la nube por niveles. Sin embargo, debe habilitar la compatibilidad con la versión anterior a través de PowerShell. Más información.

Clasificación de datos

Si tiene instalado un software de clasificación de datos, la activación de la clasificación por niveles en la nube puede suponer un aumento de los costes por dos razones:

1. Con la nube por niveles habilitada, los archivos de uso más frecuentes se almacenan en la memoria caché local y los archivos de acceso esporádico se organizan por niveles en el recurso compartido de archivos de Azure en la nube. Si la clasificación de datos examina periódicamente todos los archivos del recurso compartido de archivos, los archivos en niveles de la nube deben volver a llamarse cada vez que se examinan.

2. Si el software de clasificación de datos utiliza los metadatos del flujo de datos de un archivo, este debe volver a llamarse por completo para que el software pueda ver la clasificación.

El aumento del número de llamadas y de la cantidad de datos que se llaman puede aumentar los costos.

Directiva de actualización del agente de Azure File Sync

El agente de Azure File Sync se actualiza periódicamente con el fin de agregar nueva funcionalidad y solucionar los problemas. Se recomienda actualizar el agente de Azure File Sync cuando haya nuevas versiones disponibles.

Versiones de agente principales y secundarias

• Con frecuencia, las versiones de agente principales contienen nuevas características y en la primera parte del número de versión tienen un número creciente. Por ejemplo: 17.0.0.0
• Las versiones de agente secundarias se llaman también "revisiones" y se lanzan con más frecuencia que las principales. Suelen contener correcciones de errores y mejoras más pequeñas, pero no características nuevas. Por ejemplo: 17.2.0.0

Rutas de actualización

Existen cinco métodos aprobados y probados para instalar las actualizaciones del agente de Azure File Sync.

1. Usar la característica de actualización automática del agente de Azure File Sync para instalar las actualizaciones del agente. El agente de Azure File Sync se actualizará automáticamente. Puede seleccionar la instalación de la versión más reciente del agente cuando esté disponible o actualizar cuando el agente instalado esté a punto de expirar. Para más información, consulte Administración automática del ciclo de vida del agente.
2. Configurar Microsoft Update para descargar e instalar automáticamente las actualizaciones del agente. Se recomienda instalar todas las actualizaciones de Azure File Sync para asegurarse de que tiene acceso a las correcciones más recientes del agente de servidor. Microsoft Update realiza este proceso íntegramente al descargar e instalar automáticamente estas actualizaciones.
3. Use AfsUpdater.exe para descargar e instalar las actualizaciones del agente. AfsUpdater.exe se encuentra en el directorio de instalación del agente. Haga doble clic en el archivo ejecutable para descargar e instalar las actualizaciones del agente. En función de la versión de lanzamiento, es posible que tenga que reiniciar el servidor.
4. Aplicar revisiones a un agente de Azure File Sync existente mediante un archivo de revisiones de Microsoft Update o un archivo ejecutable .msp. La actualización más reciente de Azure File Sync se puede descargar del Catálogo de Microsoft Update. La ejecución de un ejecutable .msp actualizará su instalación de Azure File Sync con el mismo método que utiliza automáticamente Microsoft Update. Cuando se aplica una revisión de Microsoft Update, se realiza una actualización local de una instalación de Azure File Sync.
5. Descargue el instalador del agente de Azure File Sync más reciente del Centro de descarga de Microsoft. Para actualizar una instalación existente del agente de Azure File Sync, desinstale la versión antigua e instale a continuación la versión más reciente del instalador descargado. El registro del servidor, los grupos de sincronización y cualquier otra configuración se mantienen durante la instalación de Azure File Sync.

Nota:

No se admite la degradación del agente de Azure File Sync. Las nuevas versiones suelen incluir cambios importantes en comparación con las versiones anteriores, lo que hace que el proceso de degradación no sea compatible. En caso de que encuentre algún problema con la versión actual del agente, póngase en contacto con el soporte técnico o actualice a la versión más reciente disponible.

Administración automática del ciclo de vida del agente

El agente de Azure File Sync se actualizará automáticamente. Puede seleccionar cualquiera de los dos modos y especificar una ventana de mantenimiento en la que se debe realizar la actualización en el servidor. Esta característica está diseñada para ayudarle con la administración del ciclo de vida de agente, proporcionando una barrera protectora para evitar que al agente expire o para permitir mantener la configuración actual sin problemas.

1. La configuración predeterminada intentará evitar que el agente expire. Dentro del plazo de 21 días tras publicarse la fecha de expiración de un agente, el agente intentará actualizarse automáticamente. Iniciará un intento de actualización una vez por semana en los 21 días anteriores a la expiración y en la ventana de mantenimiento seleccionada. Esta opción no elimina la necesidad de realizar las revisiones regulares de Microsoft Update.
2. Si lo desea, puede seleccionar que el agente se actualice automáticamente tan pronto como esté disponible una nueva versión del agente (esta opción no se aplica actualmente a los servidores en clúster). Esta actualización se producirá durante la ventana de mantenimiento seleccionada y permite que el servidor pueda beneficiarse de las nuevas características y mejoras en cuanto estén disponibles con carácter general. Esta es la configuración recomendada, sin preocupaciones, que proporcionará versiones principales del agente, así como revisiones de actualización regulares a su servidor. Cada agente publicado tiene una calidad de disponibilidad general. Si selecciona esta opción, Microsoft lanzará como paquete piloto la versión más reciente del agente para usted. Se excluyen los servidores en clúster. Una vez finalizada la distribución del paquete piloto, el agente también estará disponible en Microsoft Update y en el Centro de descarga de Microsoft.

Cambiar la configuración de actualización automática

En las instrucciones siguientes se describe cómo cambiar la configuración después de haber completado el instalador, en caso de que sea necesario realizar cambios.

Abra una consola de PowerShell y navegue hasta el directorio donde instaló el agente de sincronización e importe los cmdlets del servidor. De manera predeterminada, esto tendría un aspecto similar al siguiente:

cd 'C:\Program Files\Azure\StorageSyncAgent'
Import-Module -Name .\StorageSync.Management.ServerCmdlets.dll

Puede ejecutar Get-StorageSyncAgentAutoUpdatePolicy para comprobar la configuración de la directiva actual y determinar si quiere cambiarla.

Para cambiar la configuración de directiva actual a la pista de actualización retrasada, puede usar:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration

Para cambiar la configuración de directiva actual a la pista de actualización inmediata, puede usar:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest -Day <day> -Hour <hour>

Nota:

Si el paquete piloto ya se ha completado para la versión más reciente del agente y la directiva de actualización automática del agente se cambia a InstallLatest, el agente no se actualizará automáticamente hasta que se abra la siguiente versión del agente. Para actualizar a una versión del agente que ha completado la distribución de paquetes piloto, use Microsoft Update o AfsUpdater.exe. Para comprobar si una versión del agente está actualmente en curso, consulte la sección versiones admitidas en las notas de la versión.

Garantías de ciclo de vida y administración de cambios del agente

Azure File Sync es un servicio en la nube que introduce de forma continua nuevas características y funcionalidades. Esto significa que una versión específica del agente de Azure File Sync solo se puede admitir por tiempo limitado. Para facilitar la implementación, las siguientes reglas garantizan que dispone de tiempo suficiente y le notifican que adapte las actualizaciones del agente en el proceso de administración de cambios:

• Las versiones principales del agente se admiten durante seis meses como mínimo desde la fecha de lanzamiento inicial.
• Se garantiza que, al menos durante tres meses, el soporte técnico de las versiones principales del agente se solapa.
• Se emiten advertencias para los servidores registrados mediante un agente "expirará pronto" al menos tres meses antes de la expiración. Puede comprobar si un servidor registrado usa una versión anterior del agente en la sección de servidores registrados de un servicio de sincronización de almacenamiento.
• La duración de una versión secundaria del agente está enlazada a la versión principal asociada. Por ejemplo, cuando la versión 17.0.0.0 del agente se establece en expirar, se establecerá que las versiones de agente 17.*.*.* expiren todas juntas.

Nota:

Al instalarse una versión del agente con un aviso de expiración se mostrará una advertencia, pero la instalación se realizará. Al intentar instalar una versión expirada del agente, o conectarse a ella, no se admite y se bloqueará.

Pasos siguientes

• Tenga en cuenta los valores de proxy y firewall
• Implementación de Azure Files
• Implementación de Azure File Sync
• Supervisión de Azure File Sync