Planeamiento de una implementación de Azure File Sync

Azure File Sync es un servicio que se puede usar para almacenar en caché varios recursos compartidos de archivos de Azure en una instancia local de Windows Server o una máquina virtual en la nube (VM).

En este artículo se explican los conceptos y características de Azure File Sync. Después de familiarizarse 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 almacenan en la nube en recursos compartidos de archivos de Azure. Puede usar recursos compartidos de archivos de Azure de las dos maneras siguientes. La opción de implementación que elija cambiará los aspectos que debe tener en cuenta a la hora de planear la implementación.

• Monte directamente un recurso compartido de archivos de Azure mediante el protocolo Bloque de mensajes del servidor (SMB): 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. Puesto 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 de almacenamiento conectado a la red (NAS). Esta opción se traduce en que no tiene que aplicar revisiones de software ni intercambiar discos físicos.

• Almacenamiento en caché de recursos compartidos en el entorno local con Azure File Sync: con Azure File Sync es posible 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

En Azure, un recurso es un elemento administrable que se crea y configura dentro de las suscripciones y grupos de recursos de Azure. Los proveedores de recursos ofrecen recursos. En otras palabras, dichos proveedores son servicios de administración que proporcionan tipos específicos de recursos. Para implementar Azure File Sync, trabajará con dos recursos clave:

• Cuentas de almacenamiento, ofrecidas por el proveedor de recursos Microsoft.Storage. Las cuentas de almacenamiento son recursos de nivel superior que representan un grupo compartido de almacenamiento, IOPS y rendimiento en el que puede implementar recursos compartidos de archivos clásicos u otros recursos de almacenamiento, en función del tipo de cuenta de almacenamiento. 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. Los recursos compartidos de archivos clásicos admiten los protocolos de uso compartido de archivos SMB y NFS, pero solo puede usar Azure File Sync con recursos compartidos de archivos SMB.

  Nota:

  Azure Files también admite la implementación de recursos compartidos de archivos como un recurso de Azure de nivel superior a través del Microsoft.FileShares proveedor de recursos. Sin embargo, dado que actualmente estas comparticiones de archivos solo admiten el protocolo NFS, no son compatibles con Azure File Sync.

• Servicios de sincronización de almacenamiento, ofrecidos por el proveedor de Microsoft.StorageSync recursos. Los servicios de sincronización de almacenamiento actúan como contenedores de administración que permiten registrar servidores de archivos de Windows y definir las relaciones de sincronización para Azure File Sync.

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

Los recursos compartidos de archivos clásicos o los recursos compartidos de archivos implementados en cuentas de almacenamiento son la manera tradicional de implementar recursos compartidos de archivos para Azure Files. Admiten todas las características clave que Azure Files admite, incluidos SMB y NFS, los niveles de medios SSD y HDD, todos los tipos de redundancia y en cada región. Para más información sobre los recursos compartidos de archivos clásicos, consulte Recursos compartidos de archivos clásicos.

Hay dos tipos principales de cuentas de almacenamiento que se usan para las implementaciones clásicas de recursos compartidos de archivos:

• Cuentas de almacenamiento aprovisionadas: las cuentas de almacenamiento aprovisionadas se distinguen mediante el tipo de cuenta de almacenamiento FileStorage. Las cuentas de almacenamiento aprovisionadas permiten implementar recursos compartidos de archivos clásicos aprovisionados en hardware basado en SSD o HDD. Las cuentas de almacenamiento aprovisionadas solo se pueden usar para almacenar recursos compartidos de archivos clásicos y no se pueden usar para almacenar otros recursos de almacenamiento, como contenedores de blobs, colas y tablas. Se recomienda usar cuentas de almacenamiento aprovisionadas para todas las nuevas implementaciones de recursos compartidos de archivos clásicos.
• Cuentas de almacenamiento de pago por uso: las cuentas de almacenamiento de pago por uso se distinguen mediante el tipo de cuenta de almacenamiento StorageV2. Las cuentas de almacenamiento de pago por uso permiten implementar recursos compartidos de archivos de pago por uso en hardware basado en HDD. Las cuentas de almacenamiento de pago por uso se pueden usar para almacenar recursos compartidos de archivos clásicos y otros recursos de almacenamiento, como contenedores de blobs, colas o tablas.

Conceptos de administración de Azure File Sync

Dentro de un servicio de sincronización de almacenamiento, puede implementar:

• Servidores registrados, que representa un servidor de archivos de Windows con una relación de confianza con el servicio de sincronización de almacenamiento. Los servidores registrados pueden ser un servidor o clúster individual, pero un servidor o clúster solo se puede registrar con un servicio de sincronización de almacenamiento a la vez.

• Grupos de sincronización, que definen la relación de sincronización entre un punto de conexión en la nube y uno o varios puntos 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.

  • Puntos de conexión en la nube, que representan recursos compartidos de archivos de Azure.
  • Puntos de conexión de servidor, que representan rutas de acceso en servidores registrados que se sincronizan con Azure Files. Un servidor registrado puede contener varios puntos de conexión de servidor si sus espacios de nombres no se superponen.

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 un cambio en el punto de conexión en la nube (recurso compartido de archivos de Azure) directamente, un trabajo de detección de cambios de Azure File Sync primero debe detectar los cambios. Un trabajo de detección de cambios para un punto de conexión en la nube solo empieza una vez cada 24 horas. Para más información, consulte Preguntas más frecuentes sobre Azure Files y Azure File Sync.

Recuento de los servicios de sincronización de almacenamiento necesarios

Un servicio de sincronización de almacenamiento es el recurso raíz de Azure Resource Manager para Azure File Sync. Administra las relaciones de sincronización entre las instalaciones de Windows Server y los recursos compartidos de archivos de Azure. Cada servicio de sincronización de almacenamiento puede contener varios grupos de sincronización y varios servidores registrados.

Cada instancia de Windows Server solo se puede registrar en un servicio de sincronización de almacenamiento. Después del registro, el servidor puede participar en varios grupos de sincronización dentro de ese servicio de sincronización de almacenamiento mediante una entidad de seguridad de Resource Manager para crear puntos de conexión de servidor en el servidor.

Al diseñar topologías de Azure File Sync, asegúrese de aislar los datos claramente en el nivel del servicio de sincronización de almacenamiento. Por ejemplo, si la empresa requiere entornos independientes de Azure File Sync para dos unidades de negocio distintas y necesita un aislamiento estricto de datos entre estos grupos, debe crear un servicio de sincronización de almacenamiento dedicado para cada grupo. Evite colocar grupos de sincronización para ambos grupos empresariales en el mismo servicio de sincronización de almacenamiento, ya que esa configuración no garantizaría el aislamiento completo.

Para obtener más instrucciones sobre el aislamiento de datos mediante suscripciones independientes o grupos de recursos en Azure, consulte Tipos y proveedores de recursos de Azure.

Planificación de topologías de sincronización equilibrada

Antes de implementar los recursos, es importante planear lo que sincronizará en un servidor local y con qué recurso compartido de archivos de Azure. La realización de un plan le ayuda a determinar el número de cuentas de almacenamiento, recursos compartidos de archivos de Azure y recursos de sincronización que necesita. Estas consideraciones son relevantes incluso si los datos no residen actualmente en una instancia de Windows Server o en el servidor que desea usar a largo plazo. La sección de migración de este artículo puede ayudarle 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 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 en la nube puede finalizar más rápido, lo que a su vez reduce la espera de que el espacio de nombres aparezca en un servidor habilitado para Azure File Sync.
• La restauración en la nube desde una instantánea de recurso compartido de archivos de Azure es más rápida.
• La recuperación ante desastres de un servidor local puede acelerarse de forma considerable.
• Los cambios realizados directamente en un recurso compartido de archivos de Azure (fuera de una 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.

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 informa del número y los recursos del grupo de sincronización de Azure File Sync que va a aprovisionar. 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 optimizar el mapa y decidir cuántos recursos compartidos de archivos de Azure necesita, revise los siguientes límites y procedimientos recomendados:

• 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. Sin embargo, es posible que esta asignación no siempre sea posible debido a varios límites y restricciones, tanto de la organización como de Azure. Si no puede implementar solo un recurso compartido de archivos en una cuenta de almacenamiento, tenga en cuenta qué recursos compartidos estarán muy activos y qué recursos compartidos serán menos activos. No coloque los recursos compartidos de archivos más activos juntos 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

En función de esta información, a menudo es necesario agrupar varias carpetas de nivel superior en los volúmenes en un nuevo directorio raíz común. A continuación, sincronizará este nuevo directorio raíz y todas las carpetas agrupadas en él en un único 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 las rutas de acceso de recurso compartido (como los recursos compartidos SMB o NFS) que pueda tener en las carpetas del servidor local que ahora ha cambiado en 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 escalabilidad de Azure File Sync.

Es posible que, en su situación, un conjunto de carpetas se sincronice lógicamente con el mismo recurso compartido de archivos de Azure (mediante el enfoque de raíz común mencionado anteriormente). Pero podría ser mejor volver a agrupar carpetas para 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 sincronizar entre más servidores locales, para agregar la capacidad de sincronizar con 30 recursos compartidos de archivos de Azure más por servidor adicional.

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 destinos de escalado de Azure File Sync.

Escenarios y consideraciones comunes de sincronización de archivos

Escenario de sincronización	Compatible	Consideraciones (o limitaciones)	Solución (o solución alternativa)
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) admite la sincronización con solo un grupo de sincronización. Un grupo de sincronización solo admite un punto de conexión de servidor por servidor registrado.	1) Empiece por sincronizar un disco (su volumen raíz) con un recurso compartido de archivos de Azure de destino. A partir del disco o volumen más grande, ayudará con los requisitos de almacenamiento locales. Configure la nube por niveles para organizar todos los datos en la nube, de modo que pueda liberar 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 se almacenen en capas hasta la nube o se migren. 2) Tenga un solo volumen raíz (disco) como destino a la vez. Use la nube por niveles para organizar todos los datos en el recurso compartido de archivos de Azure de destino. 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 raíz o disco, sincronizar y, a continuación, repita el proceso. Tenga en cuenta que es posible que tenga que 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).
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 puede 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 el escenario anterior).	Sincronice la raíz del volumen que contiene varios recursos compartidos o carpetas de nivel superior.
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. Las IOPS y el rendimiento se comparten entre recursos compartidos de archivos. Mantenga el número de elementos por grupo de sincronización dentro de 100 millones de elementos (archivos y carpetas) por recurso compartido. Es mejor alojarse por debajo de 20 o 30 millones por acción.	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 a la vez en este escenario. Si tiene más de 30 recursos compartidos en ese servidor de archivos, use la 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 adicionales de Azure File Sync locales y divida o mueva datos a estos servidores para solucionar las limitaciones de la instancia de Windows Server de origen.
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 dentro de 100 millones de elementos (archivos y carpetas) por recurso compartido. Es mejor alojarse por debajo de 20 o 30 millones por acción.	Igual que el enfoque anterior.
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 un punto de conexión en la nube (recurso compartido de archivos de Azure) que ya esté 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 primer escenario, con la consideración adicional de tener como destino un servidor de archivos a la vez.
Topología entre inquilinos (mediante la identidad administrada entre inquilinos)	No	El servicio de sincronización de almacenamiento, el recurso de servidor (servidor habilitado para Azure Arc o máquina virtual de Azure), la identidad administrada y las asignaciones de RBAC en la cuenta de almacenamiento deben estar en el mismo inquilino de Microsoft Entra. No se admiten topologías entre inquilinos.	Las configuraciones entre inquilinos producen un error de autenticación y autorización, y el servidor no se puede conectar. Para continuar, asegúrese de que todos los recursos (servicio de sincronización, servidor, identidad administrada y asignaciones de RBAC) se crean en el mismo inquilino de Microsoft Entra.

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 que registre sus pensamientos para que pueda hacer referencia a ella cuando sea necesario. Mantenerse organizado es importante, ya que la pérdida de detalles del plan de asignación puede ocurrir fácilmente 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 para servidores 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. El agente de Azure File Sync 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 y de iniciar las sesiones de sincronización
• StorageSync.sys, un filtro del sistema de archivos que habilita la nube por niveles y una recuperación ante desastres más rápida

Requisitos de sistema operativo

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

Versión	Versión de RTM	Ediciones compatibles	Opciones de implementación compatibles
Windows Server 2025	26100	Azure, Datacenter, Essentials, Standard e IoT	Full y Core
Windows Server 2022	20348	Azure, Datacenter, Essentials, Standard e IoT	Full y Core
Windows Server 2019	17763	Centro de datos, Essentials, Estándar e IoT	Full y Core
Windows Server 2016	14393	Datacenter, Essentials, Standard y Storage Server	Full y Core

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 todos estos atributos:

• Al menos una CPU.
• Un mínimo de 2 GiB de memoria. Si el servidor se ejecuta en una máquina virtual con la memoria dinámica habilitada, configure la máquina con un mínimo de 2048 MiB de memoria.
• Un volumen asociado localmente con formato del sistema de archivos NTFS.

En la mayoría de las cargas de trabajo de producción, no se recomienda configurar un servidor de sincronización en Azure File Sync solo con los requisitos mínimos.

Recursos del sistema recomendados

Al igual que cualquier característica de servidor o aplicación, la escala de la implementación determina los requisitos de recursos del sistema para Azure File Sync. Las implementaciones más grandes en un servidor requieren mayores recursos del sistema.

Para Azure File Sync, el número de objetos entre los puntos de conexión del servidor y la renovación en el conjunto de datos determinan la escala. Un único servidor puede tener puntos de conexión de servidor en varios grupos de sincronización. 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. Debido a esa configuración, los espacios de nombres más grandes requieren más memoria para mantener un buen rendimiento. Más renovación requiere más CPU para procesar.

La tabla siguiente proporciona el tamaño del espacio de nombres y 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 más memoria 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. Se recomienda asignar más memoria hasta que se complete la sincronización inicial. Este enfoque 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. Estas comprobaciones cubren la mayoría (pero no todas) de las características mencionadas en este artículo. Le recomendamos que lea detenidamente el resto de esta sección para asegurarse de que la implementación va sin problemas.

Puede instalar el cmdlet de evaluación mediante la instalación del módulo Az PowerShell. Para obtener instrucciones, consulte Instalación de Azure PowerShell.

Uso

Puede invocar la herramienta de evaluación realizando comprobaciones del sistema, comprobaciones de conjuntos de datos o ambas. Para realizar 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 un archivo 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 se admite solo en volúmenes NTFS conectados directamente. El almacenamiento conectado directamente (DAS) en Windows Server significa que el sistema operativo Windows Server es el propietario del sistema de archivos. Puede proporcionar DAS mediante la conexión física de discos al servidor de archivos, la conexión de discos virtuales a una máquina virtual de servidor de archivos (como una máquina virtual hospedada por Hyper-V) o incluso mediante iSCSI.

Solo se admiten volúmenes NTFS. No se admiten ReFS, FAT, FAT32 ni otros sistemas de archivos.

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 ACL discrecionales de estilo Windows. Windows Server aplica estas ACL en los puntos de conexión de servidor. También puede aplicar ACL cuando monte directamente el recurso compartido de archivos de Azure, pero este método requiere configuración adicional. Para obtener más información, consulte la sección Identidad más adelante en este artículo.
Vínculos físicos	Omitido
Vínculos simbólicos	Omitido
Puntos de montaje	Compatibilidad parcial	Los puntos de montaje pueden ser la raíz de un punto de conexión de servidor, pero se omiten si el espacio de nombres de un punto de conexión de servidor los contiene.
Uniones	Omitido	Algunos ejemplos son Sistema de archivos distribuidos (DFS) DfrsrPrivate y DFSRoots carpetas.
Puntos de repetición de análisis	Omitido
Compresión NTFS	Compatibilidad parcial	Azure File Sync no admite puntos de conexión de servidor ubicados en un volumen que comprime el directorio de información del volumen del sistema (SVI).
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 que crea la infraestructura de clasificación de archivos no se sincronizan. Las etiquetas de clasificación existentes en los archivos de cada uno de los puntos de conexión de servidor no se modifican.

Nota:

Compresión NTFS con escalonamiento en la nube

El uso de la compresión NTFS en archivos en capas puede provocar un impacto significativo en el rendimiento. Se recomienda no usar la estratificación en la nube con archivos comprimidos.

Si los archivos comprimidos ya se han almacenado en niveles, se deben descomprimir tras recuperar los datos de la nube mediante la ejecución de:

Invoke-StorageSyncFileRecall -FilePath <path>
compact /U /S <filepath>

El uso de la compresión NTFS en archivos en capas puede provocar un impacto significativo en el rendimiento. Se recomienda no usar la estratificación en la nube con archivos comprimidos.

Puede descomprimir archivos mediante el comando compact .

En Windows Server 2019 o posterior, el comando compact omite los archivos en capas, por lo que debe recuperar primero el archivo antes de descomprimirlo.

Import-Module "C:\Program Files\Azure\StorageSyncAgent\StorageSync.Management.ServerCmdlets.dll"
Invoke-StorageSyncFileRecall -FilePath <path>
compact /U /S <filepath>

Si las recuperaciones de archivos provocan problemas de espacio insuficiente en disco, debe esperar a que la migración por niveles en segundo plano se inicie y vuelva a migrar el archivo antes de recuperar más archivos o volver a migrar el archivo después de descomprimirlo mediante la ejecución del cmdlet

Import-Module "C:\Program Files\Azure\StorageSyncAgent\StorageSync.Management.ServerCmdlets.dll"
Invoke-StorageSyncCloudTiering -Path <path>

Azure File Sync también omite determinados archivos temporales y carpetas del sistema:

Archivo/carpeta	Nota:
pagefile.sys	Archivo específico de un sistema
Desktop.ini	Archivo específico de un sistema
thumbs.db	Archivo temporal para miniaturas
ehthumbs.db	Archivo temporal para miniaturas de elementos multimedia
~$*.*	Archivo temporal de Office
*.tmp	Archivo temporal
*.laccdb	Acceso al archivo de bloqueo de base de datos
635D02A9D91C401B97884B82B3BCDAEA.*	Archivo de sincronización interno
\System Volume Information	Carpeta específica de un volumen
$RECYCLE.BIN	Carpeta
\SyncShareState	Carpeta para sincronización
.SystemShareInformation	Carpeta para la sincronización en un 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). 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.

Espacio disponible en el disco local

Cuando planee usar Azure File Sync, tenga en cuenta cuánto espacio libre necesita en el disco local para el punto de conexión del servidor.

Con Azure File Sync, debe tener en cuenta los siguientes elementos que ocupan 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 directiva para el espacio libre de 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

En el ejemplo siguiente se muestra cómo calcular la cantidad de espacio libre que necesita en el disco local. Supongamos que instaló el agente de Azure File Sync en la máquina virtual Windows de Azure y planea crear un punto de conexión de servidor en el disco F. Tiene 1 millón de archivos (y desea organizar 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 %.

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

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

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

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

• 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 libre que piense que podría necesitar para este disco.

Clústeres de conmutación por error

Azure File Sync admite clústeres de conmutación por error de Windows Server para el servidor de archivos para la opción de implementación de uso general. Para obtener más información sobre cómo configurar el servidor de archivos para el rol de 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.

El único escenario que admite Azure File Sync es un clúster de conmutación por error de Windows Server con discos agrupados. No se admite la agrupación en clústeres de conmutación por error en el Servidor de archivos de escalabilidad horizontal, volúmenes compartidos de clúster (CSV) o discos locales.

Para que la sincronización funcione correctamente, el agente de Azure File Sync debe instalarse en cada nodo de un clúster de conmutación por error.

Desduplicación de datos

Windows Server 2025, Windows Server 2022, Windows Server 2019 y Windows Server 2016

La desduplicación de datos se admite si la nube por niveles está habilitada o deshabilitada en uno o varios puntos de conexión de servidor en el volumen de Windows Server 2025, Windows Server 2022, Windows Server 2019 y Windows Server 2016. 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.

Al habilitar Desduplicación de datos 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 almacenan en capas de forma similar a un archivo normal, en función de la configuración de directiva para la nube por niveles. Después de organizar los archivos optimizados para desduplicación, el trabajo de recolección de elementos no utilizados de desduplicación de datos se ejecuta automáticamente. Recupera el espacio en disco quitando fragmentos innecesarios a los que ya no hacen referencia otros archivos del volumen.

En algunos casos en los que se instala Desduplicación de datos, el espacio de volumen disponible puede aumentar más de lo esperado después de que se desencadene la recolección de elementos no utilizados de desduplicación. En el ejemplo siguiente se describe cómo funciona el espacio de volumen:

1. La directiva de espacio libre para la nube por niveles se establece en 20 %.
2. Se notifica a Azure File Sync cuando el espacio disponible es bajo (supongamos que 19 %).
3. La ordenación por niveles determina que 1 % más espacio debe liberarse, pero quiere que 5 % extra, por lo que puede escalar hasta 25 % (por ejemplo, 30 GiB).
4. Los archivos se almacenan en niveles hasta llegar a 30 GiB.
5. Como parte de la interoperabilidad con desduplicación de datos, Azure File Sync inicia la recolección de elementos no utilizados al final de la sesión de niveles.

El ahorro de volumen solo se aplica al servidor. Los datos del recurso compartido de archivos de Azure no se desduplican.

Nota:

Para admitir desduplicación de datos en volúmenes con la nube por niveles habilitada en Windows Server 2019, debe instalar Windows Update KB4520062: octubre de 2019 o una actualización de acumulación 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 habilita Desduplicación de datos en un volumen, debe deshabilitar la nube por niveles.

Notas

• Si instala Desduplicación de datos antes de instalar el agente de Azure File Sync, se requiere un reinicio para admitir la desduplicación de datos y la nube por niveles en el mismo volumen.

• Si habilita Desduplicación de datos en un volumen después de habilitar la nube por niveles, el trabajo de optimización de desduplicación inicial optimiza los archivos en el volumen que aún no están en capas. Este trabajo tiene el siguiente impacto en la nube por niveles:

  • La directiva de espacio libre continúa colocando los archivos en capas según el espacio libre en el volumen mediante el mapa térmico.
  • La directiva de fecha omite la organización por niveles de archivos que podrían ser aptas para la organización por niveles porque el trabajo de optimización de desduplicación tiene acceso a los archivos.

• Para los trabajos de optimización de desduplicación en curso, la configuración MinimumFileAgeDays de desduplicación de datos retrasa la nube por niveles con la directiva de datos, si el archivo aún no está en capas.

  • Por ejemplo, si la MinimumFileAgeDays configuración es de 7 días y la directiva de datos para la nube por niveles es de 30 días, la directiva de fecha tiers archivos después de 37 días.
  • Después de que Azure File Sync tiers un archivo, el trabajo de optimización de desduplicación omite 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 2025, Windows Server 2022, Windows Server 2019 o Windows Server 2016, debe realizar los pasos siguientes para admitir en el mismo volumen la desduplicación de datos y la nube por niveles:

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

  El servidor conserva sus opciones de configuración de Azure File Sync cuando el agente se desinstala y vuelve a instalar.

Sistema de archivos distribuido

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

DFS-N

Azure File Sync es totalmente compatible con la implementación de 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.

DFS-R

Dado que DFS-R y Azure File Sync son soluciones de replicación, se recomienda reemplazar DFS-R por Azure File Sync en la mayoría de los casos. Pero debe usar DFS-R y Azure File Sync juntos en los escenarios siguientes:

• Va a migrar desde una implementación de DFS-R a una implementación de Azure File Sync. Para más información, consulte Migración de una implementación de 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 quiere 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:

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

Para obtener más información, consulte Espacios de nombres DFS e Información general sobre 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 deben producirse después de implementar la imagen del servidor y completar la miniconstalación de Sysprep.

Windows Search

Si la nube por niveles está habilitada en un punto de conexión de servidor, Windows Search omite los archivos en capas y no los indexa. Windows Search indexa los archivos sin niveles correctamente.

Los clientes de Windows provocan 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 HSM

No debe usar ninguna otra solución de administración jerárquica de almacenamiento (HSM) con Azure File Sync.

Rendimiento y escalabilidad

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 estos factores en la infraestructura:

• Windows Server y la configuración del disco subyacente
• Ancho de banda de red entre el servidor y Azure Storage
• Tamaño de archivo
• Tamaño total del conjunto de datos
• Actividad en el conjunto de datos

Azure File Sync funciona en el nivel de archivo. Las características de rendimiento de una solución basada en Azure File Sync se miden mejor en el número de objetos (archivos y directorios) procesados por segundo.

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

Identidad

El administrador que registra el servidor y crea el punto de conexión en la nube debe ser miembro del rol de administración Administrador, propietario o colaborador de Azure File Sync para el servicio de sincronización de almacenamiento. Puede configurar este rol en Control de acceso (IAM) en la página de Azure Portal del servicio de sincronización de almacenamiento.

Al asignar el rol administrador de Azure File Sync, siga estos pasos para garantizar el privilegio mínimo.

1. En la pestaña Condiciones, seleccione Permitir que los usuarios asignen roles seleccionados solo a responsables seleccionados (menos privilegios).

2. Haga clic en Seleccionar roles y principales y, a continuación, seleccione Agregar acción en Condición n.º 1.

3. Seleccione Crear asignación de roles y, a continuación, haga clic en Seleccionar.

4. Seleccione Agregar expresión y, a continuación, seleccione Solicitar.

5. En Origen de atributo, seleccione Id. de definición de rol en Atributo y, a continuación, seleccione ForAnyOfAnyValues:GuidEquals en Operador.

6. Seleccione Agregar roles. Agregue los roles Lector y Acceso a datos, Colaborador con privilegios de datos de archivos de almacenamiento, y Colaborador de la cuenta de almacenamiento, y a continuación, seleccione Guardar.

Azure File Sync funciona con la identidad basada en Active Directory estándar sin ninguna configuración especial más allá de la configuración de la sincronización. Cuando usa Azure File Sync, la expectativa general es que la mayoría de los accesos pasen por los servidores de almacenamiento en caché de Azure File Sync, en lugar de a través del recurso compartido de archivos de Azure. Dado que los puntos de conexión de servidor están en Windows Server y Windows Server admite ACL de Active Directory y estilo de Windows, no necesita nada más allá de asegurarse de que los servidores de archivos de Windows registrados con el servicio de sincronización de almacenamiento están unidos a un dominio. Azure File Sync almacena las ACL en los archivos del recurso compartido de archivos de Azure y replica esas ACL en todos los puntos de conexión de 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 puede aplicar sus permisos de Active Directory en su recurso compartido de archivos directamente en la nube. Para realizar esta configuración, debe unir su cuenta de almacenamiento a la instancia de Active Directory local, al igual que la forma en que los servidores de archivos de Windows están unidos a un dominio. Para más información sobre cómo unir un dominio la cuenta de almacenamiento a una instancia de Active Directory propiedad del cliente, consulte Introducción a la autenticación basada en identidad de Azure Files para el acceso SMB.

Importante

No es necesario unir el dominio de la cuenta de almacenamiento a Active Directory para implementar correctamente Azure File Sync. Es un paso opcional que permite al recurso compartido de archivos de Azure aplicar ACL locales cuando los usuarios montan directamente el recurso compartido de archivos de Azure.

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 protocolos siempre usan HTTPS a través del puerto 443. SMB nunca se usa para cargar o descargar datos entre la instancia de Windows Server y el recurso compartido de archivos de Azure. Dado que la mayoría de las organizaciones permiten el tráfico HTTPS a través del puerto 443 como requisito para visitar la mayoría de los sitios web, normalmente no se requiere una configuración de red especial para implementar Azure File Sync.

Importante

Azure File Sync no admite el enrutamiento de Internet. Azure File Sync admite la opción de enrutamiento de red predeterminada, enrutamiento de Microsoft.

En función de la directiva o de los requisitos normativos únicos de su organización, es posible que necesite una comunicación más restrictiva con Azure. Azure File Sync proporciona varios mecanismos para configurar redes. En función de sus requisitos, puede:

• Tunelizar la sincronización y el tráfico de carga o descarga a través de una red privada virtual (VPN) de Azure o de Azure ExpressRoute.
• Use las características de red de Azure Files y 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.

Si desea 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. Este método ofrece una VPN de configuración cero para el acceso SMB a los recursos compartidos de archivos de Azure a través del 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.

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

Cifrado

Azure File Sync ofrece tres capas 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 para los datos del recurso compartido de archivos de Azure.

Cifrado en reposo de Windows Server

Dos estrategias para cifrar datos en Windows Server funcionan generalmente con Azure File Sync:

• Cifrado debajo del sistema de archivos, de modo que el sistema de archivos y todos los datos escritos en él se cifran
• Cifrado dentro del propio formato de archivo

Estos métodos se excluyen mutuamente. Puede optar por usarlos juntos porque el propósito del cifrado es diferente.

Para proporcionar cifrado debajo del sistema de archivos, Windows Server ofrece una bandeja de entrada de BitLocker. BitLocker es totalmente transparente para Azure File Sync. Las principales razones para usar un mecanismo de cifrado como BitLocker son:

• Impedir la filtración física de datos del centro de datos local por parte de alguien que roba los discos
• Impedir la instalación de prueba de un sistema operativo no autorizado para realizar lecturas y escrituras no autorizadas en los datos

Para obtener más información, consulte Introducción a BitLocker.

Los productos asociados que funcionan de forma similar a BitLocker, en que se encuentran debajo del volumen NTFS, deben funcionar de forma completa y transparente con 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 realizar esta tarea de forma nativa, pero normalmente no lo hacen.

Los métodos de ejemplo para cifrar el flujo de datos del archivo son Azure Information Protection, Azure Rights Management (Azure RMS) y Active Directory Rights Management Services. La razón principal para usar un mecanismo de cifrado como Azure Information Protection o Azure RMS es evitar la filtración de datos del recurso compartido de archivos por parte de personas que lo copien en ubicaciones alternativas (como una unidad flash) o enviarlos 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 sigue estando cifrado en el recurso compartido de archivos de Azure.

Azure File Sync no interopera con NTFS Encrypted File System ni con soluciones de cifrado de asociados que se encuentran encima del sistema de archivos, pero debajo del flujo de datos del archivo.

Cifrado en tránsito

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 protocolos siempre usan HTTPS a través del 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. Este modificador está habilitado de forma predeterminada. Incluso si el modificador en el nivel de cuenta de almacenamiento está deshabilitado y las conexiones sin cifrar a los recursos compartidos de archivos de Azure son posibles, Azure File Sync sigue usando solo 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 se comunica directamente con el recurso compartido de archivos de Azure. Esta aplicación debe ejecutarse en un sistema operativo anterior, como Windows Server 2008 R2 o una distribución de Linux anterior. Si la aplicación heredada se conecta a la memoria caché de Windows Server del recurso compartido de archivos, cambiar esta configuración no tiene ningún efecto.

Se recomienda encarecidamente habilitar el cifrado de datos en tránsito. Para obtener más información sobre el cifrado en tránsito, consulte Requerir transferencia segura para garantizar conexiones seguras.

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. Es posible que esté usando una versión anterior de TLS si ha deshabilitado TLS 1.2 en el servidor o si usa un proxy.

Si usa un proxy, se recomienda comprobar la configuración del proxy. Las regiones del servicio Azure File Sync agregadas después del 1 de mayo de 2020 solo admiten TLS 1.2. Para más información, consulte la guía para la solución de problemas.

Cifrado en reposo del recurso compartido de archivos de Azure

Todos los datos almacenados en Azure Files se cifran en reposo a través del cifrado del lado del servicio (SSE) de Azure Storage. SSE funciona de forma similar a BitLocker en Windows: los datos se cifran debajo del nivel del sistema de archivos.

Dado que los datos se cifran debajo del sistema de archivos del recurso compartido de archivos de Azure, ya que está codificado en el disco, no necesita acceso a la clave subyacente en el cliente para leer o escribir en el recurso compartido de archivos de Azure. 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 contiene las claves para cifrar y descifrar los datos. Microsoft es responsable de rotar estas claves con regularidad.

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 sin esta autorización, el recurso compartido de archivos de Azure ya no es accesible a través de SMB o la API de FileREST.

Azure Files usa el mismo esquema de cifrado que los otros servicios de almacenamiento de Azure, como Azure Blob Storage. Para obtener más información sobre SSE de Azure Storage, consulte Cifrado de Azure Storage para datos en reposo.

Niveles de almacenamiento

Azure Files ofrece dos niveles multimedia de almacenamiento: disco de estado sólido (SSD) y unidad de disco duro (HDD). Estos niveles le permiten adaptar sus recursos compartidos a los requisitos de rendimiento y precio de su escenario:

• SSD (Premium): los recursos compartidos de archivos SSD proporcionan un alto rendimiento coherente y una latencia baja, dentro de milisegundos de un solo dígito para la mayoría de las operaciones de E/S, para cargas de trabajo intensivas de E/S. Los recursos compartidos de archivos SSD son adecuados para una amplia variedad de cargas de trabajo, como bases de datos, hospedaje de sitios web y entornos de desarrollo.

  Puede usar recursos compartidos de archivos SSD con los protocolos SMB y NFS. Los recursos compartidos de archivos SSD están disponibles en los modelos de facturación aprovisionado v2 y aprovisionado v1. Los recursos compartidos de archivos SSD ofrecen un Acuerdo de Nivel de Servicio de mayor disponibilidad que los recursos compartidos de archivos HDD.

• HDD (estándar): los recursos compartidos de archivos HDD proporcionan una opción de almacenamiento rentable para recursos compartidos de archivos de uso general. Los recursos compartidos de archivos HDD están disponibles con los modelos de facturación de pago por uso y aprovisionado v2, aunque se recomienda el modelo aprovisionado v2 para nuevas implementaciones de recursos compartidos de archivos. Para obtener información sobre el Acuerdo de Nivel de Servicio, consulte la página del Acuerdo de Nivel de Servicio de Azure para servicios en línea.

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 los recursos compartidos de archivos SSD sean los más adecuados. Si la latencia baja no es un problema grave, los recursos compartidos de archivos HDD podrían ser una mejor opción desde una perspectiva de costos. Por ejemplo, una latencia baja podría ser menos preocupante con los recursos compartidos de equipo montados en el entorno local desde Azure o almacenados en la caché local a través de Azure File Sync.

Después de crear un recurso compartido de archivos en una cuenta de almacenamiento, no se puede mover directamente a otro nivel multimedia. Por ejemplo, para mover un recurso compartido de archivos HDD al nivel multimedia SSD, debe crear un nuevo recurso compartido de archivos SSD y copiar los datos del recurso compartido original al nuevo recurso compartido de archivos.

Puede encontrar más información sobre los niveles de medios SSD y HDD en Descripción de los modelos de facturación de Azure Files y Descripción y optimización del rendimiento del recurso compartido de archivos de Azure.

Disponibilidad en regiones de Azure File Sync

Para obtener disponibilidad regional, consulte Disponibilidad del producto por región y busque Cuentas de almacenamiento.

Las siguientes regiones requieren que solicite acceso a Azure Storage para poder usar Azure File Sync:

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

Para solicitar acceso a estas regiones, siga el proceso de este artículo.

Redundancia

Para ayudar a proteger los datos de los recursos compartidos de archivos de Azure frente a la pérdida de datos o daños, Azure Files almacena varias copias de cada archivo a medida que se escriben. Según sus requisitos, puede seleccionar grados de redundancia. Azure Files admite actualmente las siguientes opciones para la redundancia de datos:

• Almacenamiento con redundancia local (LRS): con la redundancia local, cada archivo se almacena tres veces en un clúster de almacenamiento de Azure. Este enfoque ayuda a proteger contra la pérdida de datos debido a errores de hardware, como una unidad de disco incorrecta. Sin embargo, si se produce un desastre como un incendio o inundación en el centro de datos, todas las réplicas de una cuenta de almacenamiento que usa LRS podrían perderse o podrían no poder recuperarse.

• Almacenamiento con redundancia de zona (ZRS): con redundancia de zona, se almacenan tres copias de cada archivo. Sin embargo, estas copias están aisladas físicamente en tres clústeres de almacenamiento distintos en zonas de disponibilidad de Azure. Las zonas de disponibilidad son ubicaciones físicas únicas en una región de Azure. Cada zona de disponibilidad consta de uno o varios centros de datos equipados con alimentación, refrigeración y redes independientes. No se acepta una escritura en el almacenamiento hasta que se escribe en los clústeres de almacenamiento en las tres zonas de disponibilidad.

• Almacenamiento con redundancia geográfica (GRS): con la redundancia geográfica, tiene una región primaria y una región secundaria. Los archivos se almacenan tres veces en 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.

  La redundancia geográfica proporciona seis copias de los datos distribuidos entre las dos regiones de Azure. Si se produce un desastre importante, como la pérdida permanente de una región de Azure debido a un desastre natural u otro evento similar, Microsoft realiza una conmutación por error. En este caso, la base de datos secundaria se convierte en la principal y atiende todas las operaciones.

  Dado que la replicación entre las regiones primarias y secundarias es asincrónica, si se produce un desastre importante, se pierden los datos que aún no se han 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): con la redundancia de zona geográfica, los archivos se almacenan tres veces en tres clústeres de almacenamiento distintos de 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 para la redundancia de zona geográfica funciona igual que para la redundancia geográfica.

Los recursos compartidos de archivos HDD admiten los cuatro tipos de redundancia. Los recursos compartidos de archivos SSD solo admiten LRS y ZRS.

Las cuentas de almacenamiento de pago por uso 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 los recursos compartidos de archivos de Azure en cuentas de almacenamiento con estas opciones establecidas, pero Azure Files no admite la lectura desde la región secundaria. Los recursos compartidos de archivos de Azure implementados en cuentas de almacenamiento con RA-GRS o RA-GZRS se facturan como con redundancia geográfica o con redundancia de zona geográfica, respectivamente.

Importante

El almacenamiento con redundancia geográfica y con redundancia de zona geográfica puede conmutar manualmente el almacenamiento a la región secundaria. No se recomienda este enfoque (fuera de un desastre) cuando se usa Azure File Sync debido a la mayor probabilidad de pérdida de datos. Si se produce un desastre y desea iniciar una conmutación por error manual de almacenamiento, debe abrir un caso de soporte técnico con Microsoft para que Azure File Sync reanude la sincronización con el punto de conexión secundario.

Migración

Si tiene un servidor de archivos existente en Windows Server 2012 R2 o posterior, puede instalar directamente Azure File Sync en su lugar. No es necesario mover datos a un nuevo servidor.

Si tiene previsto 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 NAS, hay varios enfoques de migración posibles 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.

Para obtener instrucciones detalladas, consulte Migración a recursos compartidos de archivos de Azure SMB.

Antivirus

Dado que el antivirus funciona mediante el examen de archivos para código malintencionado conocido, un producto antivirus podría provocar la recuperación de archivos en capas y cargos de salida elevados. Los archivos en capas tienen establecido el atributo seguro de FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS Windows. Se recomienda consultar con su proveedor de software para aprender a configurar su solución para omitir la lectura de archivos que tienen este conjunto de atributos. Muchos lo hacen automáticamente.

Durante los exámenes a petición, las soluciones antivirus Microsoft Defender y System Center Endpoint Protection omiten automáticamente la lectura de archivos que tienen este conjunto de atributos. Los probamos y hemos identificado un problema menor: cuando se agrega un servidor a un grupo de sincronización existente, se recuperan los archivos menores de 800 bytes (descargados) en el nuevo servidor. Estos archivos permanecen en el nuevo servidor y no están en capas porque no cumplen el requisito de tamaño de niveles (más de 64 KiB).

Nota:

Microsoft Defender y System Center Endpoint Protection solo omiten la lectura durante los exámenes a petición. Esto no se aplica a la protección en tiempo real (RTP).

Los proveedores de antivirus pueden comprobar la compatibilidad entre sus productos y Azure File Sync mediante el conjunto de pruebas de compatibilidad del antivirus de Azure File Sync en el Centro de descarga de Microsoft.

Copia de seguridad

Si habilita la nube por niveles, no use soluciones que realicen una copia de seguridad directa del punto de conexión del servidor o una máquina virtual que contenga el punto de conexión de servidor.

La nube por niveles hace que solo se almacene un subconjunto de los datos en el punto de conexión del servidor. El conjunto de datos completo reside en el recurso compartido de archivos de Azure. En función de la solución de copia de seguridad que use, los archivos en capas son:

• Se omite y no se realiza una copia de seguridad, ya que tienen el FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS atributo establecido
• Se ha recuperado en el disco, lo que da como resultado cargos de salida elevados

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 Azure Files. O pregunte al proveedor de copia de seguridad si admite la copia de seguridad de recursos compartidos de archivos de Azure.

Si prefiere usar una solución de copia de seguridad local, realice las copias de seguridad en un servidor del grupo de sincronización que tenga deshabilitado la nube por niveles. Asegúrese de que no hay archivos en capas.

Cuando realice una restauración, use la opción de restauración de nivel de volumen o de nivel de archivo. Los archivos restaurados a través de la opción de restauración de nivel de archivo se sincronizan con todos los puntos de conexión del grupo de sincronización. Los archivos existentes se reemplazan por la versión restaurada a partir de la copia de seguridad. Las restauraciones a nivel de volumen no reemplazan 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 sin sistema operativo, 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 niveles puede provocar resultados inesperados. (La restauración en el nivel de archivo se produce cuando el software de copia de seguridad realiza una copia de seguridad de un archivo en capas en lugar de un archivo completo). Actualmente no se admiten cuando está habilitada la nube por niveles.

Las instantáneas del Servicio de instantáneas de volumen (VSS), incluida la pestaña Versiones anteriores, se admiten en 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 software de clasificación de datos, la habilitación de la nube por niveles aumenta los costos por dos motivos:

• Con la nube por niveles habilitada, los archivos más frecuentes se almacenan en caché localmente. Los archivos más esporádicos se almacenan en 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 capas en la nube deben recuperarse siempre que se examinen.
• Si el software de clasificación de datos usa los metadatos del flujo de datos de un archivo, el archivo debe recuperarse completamente para que el software detecte la clasificación.

Estos aumentos, tanto en el número de recuperaciones como en la cantidad de datos que se recuperan, pueden 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 una 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: 18.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: 18.2.0.0.

Actualice las rutas de acceso

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

• Use la característica de actualización automática de Azure File Sync para instalar las actualizaciones del agente: el agente de Azure File Sync se actualiza 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 la sección siguiente Administración automática del ciclo de vida del agente.
• Configure Microsoft Update para descargar e instalar automáticamente las actualizaciones del agente: se recomienda instalar cada actualización de Azure File Sync para asegurarse de que tiene acceso a las correcciones más recientes para el agente de servidor. Microsoft Update realiza este proceso íntegramente al descargar e instalar automáticamente estas actualizaciones.
• Use AfsUpdater.exe para descargar e instalar actualizaciones del agente: el AfsUpdater.exe archivo 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.
• Aplicar revisiones a un agente de Azure File Sync existente mediante un archivo de revisión de Microsoft Update o un archivo ejecutable .msp: puede descargar el paquete de actualización de Azure File Sync más reciente desde el catálogo de Microsoft Update. La ejecución de un archivo ejecutable .msp actualiza la instalación de Azure File Sync con el mismo método que Microsoft Update usa automáticamente. La aplicación de una revisión de Microsoft Update realiza una actualización local de una instalación de Azure File Sync.
• Descargue el instalador del agente de Azure File Sync más reciente: puede obtener el instalador en el 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. La configuración del agente (por ejemplo, el registro del servidor y los puntos de conexión de servidor) se mantiene cuando se desinstala el agente de Azure File Sync.

Nota:

No se admite la degradación del agente de Azure File Sync. Las nuevas versiones suelen incluir cambios importantes cuando se comparan con las versiones anteriores, lo que hace que el proceso de degradación no sea compatible. Si tiene 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 actualiza automáticamente. Puede seleccionar cualquiera de los siguientes modos y especificar una ventana de mantenimiento en la que se intenta realizar la actualización en el servidor. Esta característica está diseñada para ayudarle con la administración del ciclo de vida del agente proporcionando una barrera de protección que impide que el agente expire o permita una configuración sin complicaciones y mantenerse al día.

• La configuración predeterminada intenta impedir que el agente expire. En un plazo de 21 días a partir de la fecha de expiración publicada de un agente, el agente intenta realizar la actualización automática. Inicia un intento de actualización una vez a la semana en un plazo de 21 días antes de la expiración y en la ventana de mantenimiento seleccionada. Tenga en cuenta que esta opción no elimina la necesidad de realizar las revisiones regulares de Microsoft Update.

• Puede seleccionar que el agente se actualiza automáticamente en cuanto esté disponible una nueva versión del agente. Esta capacidad no es aplicable actualmente a los servidores en clúster.

  Esta actualización se produce 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 configuración recomendada y sin preocupaciones proporciona versiones principales del agente y revisiones de actualización periódicas al servidor. Cada agente publicado tiene una calidad de disponibilidad general.

  Si selecciona esta opción, Microsoft le ofrece la versión más reciente del agente. Se excluyen los servidores en clúster. Una vez completado el vuelo, 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 completar el instalador, si necesita realizar cambios.

Abra una consola de PowerShell y vaya al directorio donde instaló el agente de sincronización y, a continuación, importe los cmdlets del servidor. De forma predeterminada, esta acción tiene un aspecto similar al ejemplo 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 vuelo 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 actualiza automáticamente hasta que se envía la siguiente versión del agente. Para actualizar a una versión del agente que finalizó el vuelo, 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 continuamente nuevas características y mejoras. Una versión específica del agente de Azure File Sync solo se puede admitir durante un tiempo limitado. Para facilitar la implementación, las siguientes reglas garantizan que tiene tiempo suficiente y notificación para dar cabida a las actualizaciones del agente en el proceso de administración de cambios:

• Las versiones principales del agente se admiten durante 12 meses como mínimo desde la fecha de lanzamiento inicial.
• Hay una superposición de al menos 3 meses entre la compatibilidad de las versiones principales del agente.
• Las advertencias se emiten para los servidores registrados a través de un agente que expirará pronto al menos 3 meses antes de la expiración. Puede comprobar si un servidor registrado usa una versión anterior del agente en la sección acerca de los servidores registrados en 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 18.0.0.0 del agente se establece en expirar, las versiones del agente 18.*.*.* expiran todas juntas.

Nota:

La instalación de una versión del agente expirada muestra una advertencia, pero se realiza correctamente. Si intenta instalar una versión expirada del agente o conectarse a ella, no se admite y se bloquea.

Contenido relacionado

• Configuración del proxy y el firewall de Azure File Sync
• Cree un recurso compartido de archivos SMB de Azure
• Implementación de Azure File Sync
• Supervisión de Azure File Sync