Novedades en Azure Files y Azure File Sync: redundancia, NFS y más

Introducción

Azure Files y Azure File Sync siguen evolucionando como piezas clave para escenarios de almacenamiento de archivos en Azure: recursos compartidos SMB administrados, acceso NFS para determinadas cargas Linux/UNIX, integración híbrida con servidores Windows y opciones de resiliencia adaptadas a distintos niveles de criticidad.

En las novedades recientes conviene separar tres planos que a menudo se mezclan:

Redundancia del almacenamiento, por ejemplo LRS o ZRS, que afecta a la resiliencia dentro de una región.
Protocolos de acceso, principalmente SMB y NFS, con diferencias importantes de compatibilidad, seguridad y operación.
Sincronización híbrida, donde Azure File Sync permite mantener servidores Windows sincronizados con Azure Files.

Este artículo resume los cambios y consideraciones más relevantes desde un punto de vista práctico, evitando una lectura puramente comercial de las novedades.

Resumen rápido de las novedades

Las áreas más relevantes para arquitectos y equipos de plataforma son:

Mayor flexibilidad en redundancia para Azure Files, especialmente en escenarios premium respaldados por SSD donde puede ser necesario pasar de LRS a ZRS, o volver a LRS, si la región y la cuenta lo admiten.
Uso de NFS en Azure Files para cargas Linux/UNIX, con requisitos de red y seguridad distintos a los de SMB.
Azure File Sync como solución híbrida, orientada a servidores Windows y escenarios SMB, no como mecanismo genérico para sincronizar cualquier recurso NFS.
Nuevo modelo de gestión de Azure file shares como recursos independientes, mediante el proveedor Microsoft.FileShares, que reduce la dependencia operativa de las cuentas de almacenamiento en determinados escenarios.
Autenticación basada en Microsoft Entra ID para acceso SMB desde macOS en vista previa pública, según la página oficial de novedades de Azure Files.

Redundancia en Azure Files: LRS, ZRS y decisiones de arquitectura

La redundancia define cómo Azure replica los datos para protegerlos frente a fallos de infraestructura.

LRS

LRS, o Locally Redundant Storage, mantiene varias copias de los datos dentro de una única ubicación física de una región de Azure. Suele ser la opción más sencilla y económica, pero no protege frente a la pérdida completa de una zona de disponibilidad.

Puede ser suficiente para:

Entornos de desarrollo o pruebas.
Cargas no críticas.
Datos que ya están protegidos por otro mecanismo de copia, backup o replicación.
Escenarios donde el coste prima sobre la resiliencia zonal.

ZRS

ZRS, o Zone-Redundant Storage, replica los datos entre zonas de disponibilidad dentro de una misma región, siempre que la región soporte zonas de disponibilidad para el servicio y tipo de cuenta utilizados.

Es más adecuado para:

Aplicaciones críticas dentro de una región.
Cargas que requieren tolerancia a fallo de zona.
Plataformas compartidas donde una interrupción zonal afectaría a muchos consumidores.
Escenarios donde se busca mayor resiliencia regional sin saltar necesariamente a una estrategia geográfica.

Importante: ZRS mejora la resiliencia frente a fallos de zona, pero no sustituye a una estrategia de backup, versionado, protección frente a borrado accidental o recuperación ante desastre geográfico.

Conversión entre LRS y ZRS: qué tener en cuenta

En Azure Storage es posible cambiar la redundancia de algunas cuentas mediante actualización del SKU, siempre que el tipo de cuenta, la región y la combinación de redundancia sean compatibles. En el caso de Azure Files premium, esto se traduce habitualmente en cambios entre SKUs como Premium_LRS y Premium_ZRS.

Antes de plantear una conversión, conviene validar:

Que la región soporta la redundancia objetivo.
Que el tipo de cuenta es compatible.
Que el recurso compartido y sus características no tienen restricciones específicas.
Que las cuotas, límites de rendimiento y requisitos de disponibilidad están alineados.
Que se ha probado el procedimiento en un entorno no productivo.
Que existe una estrategia de rollback o continuidad si la operación no puede completarse.

Para consultar la configuración actual de una cuenta de almacenamiento:

az storage account show \
  --name <nombre-de-la-cuenta> \
  --resource-group <grupo-de-recursos> \
  --query "{sku:sku.name, kind:kind, location:primaryLocation}" \
  --output table

Para solicitar el cambio a ZRS en una cuenta compatible:

az storage account update \
  --name <nombre-de-la-cuenta> \
  --resource-group <grupo-de-recursos> \
  --sku Premium_ZRS

Y para volver a LRS, si la conversión inversa está soportada en ese escenario:

az storage account update \
  --name <nombre-de-la-cuenta> \
  --resource-group <grupo-de-recursos> \
  --sku Premium_LRS

Nota operativa: no debe asumirse que cualquier cuenta puede cambiar de redundancia en cualquier momento. Si la combinación no está soportada, Azure CLI devolverá un error. Para producción, revisa la documentación oficial, valida la región y planifica la operación como un cambio de infraestructura.

NFS en Azure Files: útil, pero no equivalente a SMB

Azure Files no se limita a SMB. También permite crear recursos compartidos NFS para cargas que necesitan semántica de archivos en entornos Linux o UNIX.

Ahora bien, NFS y SMB no son intercambiables sin más. Tienen diferencias en:

Modelo de autenticación.
Semántica de permisos.
Compatibilidad con clientes.
Requisitos de red.
Integración con servicios de identidad.
Herramientas de administración y troubleshooting.

En Azure Files, NFS se utiliza principalmente en cuentas premium FileStorage y requiere una configuración de red más restrictiva que un montaje SMB típico.

Cuándo considerar NFS

NFS puede tener sentido cuando:

La carga se ejecuta principalmente en Linux.
La aplicación ya espera un punto de montaje NFS.
Se quiere evitar desplegar y operar servidores NFS propios.
El patrón de acceso encaja con las capacidades y límites de Azure Files.
El acceso puede realizarse mediante redes privadas, como una VNet, VPN, ExpressRoute o Private Endpoint.

Cuándo no elegir NFS automáticamente

No conviene elegir NFS solo porque la aplicación corre en Linux. Azure Files con SMB también puede ser viable en determinados escenarios Linux, y otros servicios de almacenamiento de Azure pueden encajar mejor según el patrón de acceso.

Antes de decidir, revisa:

Latencia esperada.
Número de operaciones por segundo.
Tamaño medio de archivo.
Patrón de lectura/escritura.
Necesidades de bloqueo de archivos.
Modelo de permisos.
Requisitos de cifrado en tránsito.
Integración con backup, monitorización y cumplimiento.

Ejemplo: crear un recurso compartido NFS con acceso privado

El siguiente ejemplo muestra una aproximación básica usando Azure CLI. Debe adaptarse a las políticas de red, naming, seguridad y gobierno de cada organización.

1. Crear una cuenta `FileStorage` premium

Para NFS en Azure Files se suele usar una cuenta de almacenamiento premium de tipo FileStorage.

az storage account create \
  --name <nombre-de-la-cuenta> \
  --resource-group <grupo-de-recursos> \
  --location <region> \
  --sku Premium_LRS \
  --kind FileStorage \
  --https-only false

Importante: NFS en Azure Files tiene requisitos específicos de red y seguridad. La opción --https-only false deshabilita la exigencia de transferencia segura a nivel de cuenta, algo que puede tener implicaciones si en la misma cuenta se usan otros protocolos. En entornos productivos, es recomendable aislar este tipo de cargas en cuentas dedicadas y restringir el acceso mediante red privada.

2. Crear el recurso compartido NFS

az storage share-rm create \
  --resource-group <grupo-de-recursos> \
  --storage-account <nombre-de-la-cuenta> \
  --name <nombre-del-compartido> \
  --enabled-protocols NFS \
  --quota 100

La cuota se expresa en GiB. En cuentas premium, esta cuota también influye en la capacidad aprovisionada y en el rendimiento disponible.

3. Crear un Private Endpoint para Azure Files

Primero obtenemos el identificador de la cuenta de almacenamiento:

STORAGE_ACCOUNT_ID=$(az storage account show \
  --name <nombre-de-la-cuenta> \
  --resource-group <grupo-de-recursos> \
  --query id \
  --output tsv)

Después se crea el Private Endpoint para el subrecurso file:

az network private-endpoint create \
  --name <nombre-del-private-endpoint> \
  --resource-group <grupo-de-recursos> \
  --vnet-name <nombre-de-la-vnet> \
  --subnet <nombre-de-la-subred> \
  --private-connection-resource-id "$STORAGE_ACCOUNT_ID" \
  --group-id file \
  --connection-name <nombre-de-la-conexion>

También es necesario configurar correctamente la resolución DNS privada para privatelink.file.core.windows.net. Sin DNS privado bien resuelto, los clientes pueden intentar acceder por la ruta pública o no resolver el recurso esperado.

4. Montar desde un cliente Linux

Un ejemplo habitual de montaje NFSv4.1 es:

sudo mount -t nfs \
  -o vers=4,minorversion=1,sec=sys \
  <nombre-de-la-cuenta>.file.core.windows.net:/<nombre-de-la-cuenta>/<nombre-del-compartido> \
  /mnt/azurefiles

Este comando presupone que:

El cliente tiene conectividad privada hacia la cuenta.
El DNS resuelve el endpoint privado.
La subred y las reglas de red permiten el acceso.
El sistema operativo incluye cliente NFS compatible.

Azure File Sync: sincronización híbrida con servidores Windows

Azure File Sync permite centralizar datos en Azure Files y mantener cachés locales en servidores Windows. Es útil cuando se necesita:

Mantener acceso local de baja latencia en oficinas o centros de datos.
Centralizar datos de varios servidores en un recurso compartido de Azure Files.
Reducir almacenamiento local mediante cloud tiering.
Facilitar operaciones de backup y recuperación centralizadas.
Modernizar servidores de archivos sin rediseñar completamente las aplicaciones.

Los componentes principales son:

Storage Sync Service: recurso de Azure que agrupa la configuración de sincronización.
Sync Group: unidad lógica que vincula una nube con uno o más servidores.
Cloud Endpoint: recurso compartido de Azure Files.
Server Endpoint: ruta local de un servidor Windows registrado.
Agente de Azure File Sync: componente instalado en el servidor Windows.

Aclaración importante: Azure File Sync está orientado a escenarios Windows Server y SMB. No debe tratarse como una solución general para sincronizar recursos NFS ni como sustituto directo de herramientas de replicación de aplicaciones Linux.

Buenas prácticas con Azure File Sync

Para producción, es recomendable aplicar al menos estas prácticas:

Diseñar bien la topología

Antes de desplegar, define:

Qué servidores participarán en cada grupo de sincronización.
Qué rutas locales serán server endpoints.
Qué recurso compartido de Azure Files actuará como cloud endpoint.
Si habrá varios sitios sincronizando los mismos datos.
Cómo se resolverán conflictos de escritura concurrente.

Activar cloud tiering solo cuando tenga sentido

Cloud tiering permite mantener localmente los archivos más usados y liberar espacio enviando contenido menos frecuente a Azure. Es útil, pero debe configurarse con cuidado.

Revisa:

Espacio libre objetivo en disco.
Patrones de acceso.
Impacto sobre antivirus, indexadores y procesos batch.
Latencia de recuperación de archivos deshidratados.
Necesidades de backup local frente a backup en Azure.

Monitorizar sincronización y errores

Azure File Sync debe monitorizarse como cualquier otro componente crítico. Conviene revisar:

Estado del agente.
Errores de sincronización.
Backlog de archivos pendientes.
Capacidad del recurso compartido.
Latencia de acceso.
Eventos del servidor Windows.
Versiones del agente instaladas.

Separar backup de sincronización

Sincronizar no es hacer backup. Si un archivo se borra o se corrompe, la sincronización puede propagar ese cambio. Para protección real, considera:

Azure Backup para Azure Files.
Instantáneas de recursos compartidos.
Retención adecuada.
Protección contra borrado accidental.
Procedimientos de recuperación probados.

Recursos compartidos como recursos independientes con `Microsoft.FileShares`

Una de las novedades relevantes en la gestión de Azure Files es la disponibilidad general del modelo en el que los recursos compartidos pueden gestionarse como recursos de primer nivel mediante el proveedor Microsoft.FileShares.

La idea principal es reducir la dependencia operativa de la cuenta de almacenamiento como contenedor único de configuración. En este modelo, cada recurso compartido puede tener una gestión más independiente de aspectos como:

Rendimiento.
Seguridad.
Red.
Facturación.
Aislamiento operativo.

Esto puede simplificar entornos donde un único equipo de plataforma ofrece almacenamiento de archivos a múltiples equipos de aplicación, cada uno con requisitos distintos.

Aun así, no implica que todos los despliegues existentes deban migrar inmediatamente. Antes de adoptar este modelo, conviene revisar:

Compatibilidad con plantillas IaC existentes.
Políticas de Azure Policy.
Modelos de RBAC.
Scripts de automatización.
Monitorización y alertas.
Procesos de tagging y chargeback.
Dependencias de herramientas que esperan una cuenta de almacenamiento tradicional.

Autenticación con Microsoft Entra ID desde macOS

Microsoft también recoge como novedad la autenticación basada en Microsoft Entra ID para Azure Files desde macOS en vista previa pública. El objetivo es acercar la experiencia de acceso SMB desde macOS a la experiencia tradicional de SMB con identidad, evitando depender de claves de cuenta de almacenamiento para el acceso de usuario.

Al estar en vista previa pública, debe tratarse con cautela:

Validar compatibilidad de versiones de macOS.
Revisar requisitos de configuración.
Probar con perfiles reales de usuario.
Verificar comportamiento con herramientas corporativas de gestión de dispositivos.
No asumir automáticamente paridad completa con todos los escenarios Windows.
Revisar las condiciones de soporte de la vista previa antes de usarlo en producción.

Para organizaciones con flotas mixtas Windows/macOS, esta línea de evolución es especialmente interesante porque reduce fricción operativa y mejora el alineamiento con políticas de identidad centralizadas.

Recomendaciones de adopción

Antes de incorporar estas novedades a una arquitectura existente, conviene seguir una secuencia ordenada.

1. Clasificar la carga

Define si la carga necesita:

SMB, NFS o ambos.
Acceso desde Windows, Linux o macOS.
Baja latencia local.
Alta resiliencia zonal.
Integración híbrida.
Identidad centralizada.
Aislamiento por equipo o aplicación.

2. Elegir redundancia según criticidad

No todas las cargas necesitan ZRS. Para algunas, LRS más backup puede ser suficiente. Para otras, ZRS puede ser obligatorio por requisitos de disponibilidad.

La decisión debería basarse en:

RTO y RPO.
Coste aceptable.
Dependencia de zona.
Requisitos regulatorios.
Capacidad de la aplicación para reintentar operaciones.
Estrategia de recuperación ante desastre.

3. Separar protocolos por cuenta cuando sea necesario

Mezclar requisitos SMB y NFS en la misma cuenta puede complicar seguridad, red y operación. Si los requisitos divergen, una cuenta dedicada por protocolo o por aplicación suele facilitar el gobierno.

4. Automatizar con validaciones

Si usas Terraform, Bicep, ARM o pipelines propios, añade validaciones para evitar combinaciones no soportadas:

Tipo de cuenta incorrecto.
SKU no disponible en la región.
Protocolo incompatible.
Private Endpoint ausente.
DNS privado no configurado.
Cuentas NFS expuestas de forma inadecuada.

5. Probar recuperación, no solo despliegue

Una arquitectura de archivos no está lista solo porque el recurso se haya creado correctamente. Hay que probar:

Restauración de archivos.
Recuperación ante borrado accidental.
Conmutación o tolerancia a fallo de zona si aplica.
Rehidratación de archivos con Azure File Sync.
Renovación de credenciales.
Actualización del agente de File Sync.
Montaje desde clientes reales.

Conclusión

Las novedades en Azure Files y Azure File Sync refuerzan la posición del servicio como una plataforma administrada para escenarios de archivos en la nube e híbridos. Las mejoras en redundancia, el soporte NFS, la evolución del modelo de recursos compartidos y la integración con identidad ayudan a cubrir más casos de uso, pero también obligan a tomar decisiones de arquitectura con cuidado.

La recomendación principal es no adoptar estas capacidades de forma aislada. Redundancia, protocolo, red, identidad, backup y sincronización deben diseñarse como un conjunto. En cargas críticas, una configuración funcional no es suficiente: debe ser operable, monitorizable, recuperable y compatible con los límites oficiales del servicio.

Fuente

What’s new in Azure Files and Azure File Sync — Microsoft Learn