AZ-104

Deep Dive

Volver a guías
D1Identidad y Acceso
Microsoft Entra ID (Azure AD)Control de Acceso Basado en RolesAutenticacion Multi-FactorIdentidades AdministradasAcceso CondicionalGestion de ContrasenasAzure Policy y CumplimientoGobernanza y Jerarquia de Recursos
D2Almacenamiento
Cuentas de AlmacenamientoSQL Database y MIAzure Cosmos DBBackup y RecuperacionProteccion de DatosReplicacion de DatosAzure Files y File SyncSeguridad de Almacenamiento
D3Computo
Maquinas VirtualesAzure App ServiceContenedores y AKSAutoscaling y VMSSDisponibilidad y RedundanciaOptimizacion de RendimientoARM Templates y BicepAzure Functions
D4Redes
Redes Virtuales (VNet)Grupos de SeguridadBalanceo de CargaVPN Gateway y ExpressRouteDNS y Resolucion de NombresMonitoreo de Red
D5Monitoreo
Azure MonitorLog AnalyticsAlertas y NotificacionesMetricas y KPIsDiagnosticosApplication Insights
D6Recuperacion
Azure Site RecoveryBackup VaultEstrategia de DRRTO y RPOFailover y FailbackContinuidad del Negocio
Practicar ahora
D2 · Almacenamiento

Azure Files y Azure File Sync

Azure Files ofrece file shares completamente administrados en la nube, accesibles via SMB y NFS. Azure File Sync extiende esto sincronizando con servidores Windows on-premises, un patrón híbrido frecuente en el AZ-104.

Contenido

¿Qué es Azure Files?

Azure Files es un servicio de almacenamiento de archivos compartidos en la nube, completamente administrado. A diferencia de Blob Storage (para objetos sin estructura), Azure Files proporciona file shares con jerarquía de carpetas accesibles mediante protocolos estándar del sector.

Azure Blob

Objetos planos (fotos, backups, logs). Acceso via REST/SDK. Sin jerarquía real de carpetas.

Azure Files

File shares SMB/NFS. Montable como unidad de red. Jerarquía de carpetas real. Ideal para lift-and-shift.

Azure NetApp Files

NFS de alto rendimiento para cargas SAP, HPC. Enterprise, precio premium.

Cuándo usar Azure Files

  • •Migrar aplicaciones on-premises que usan file shares (lift-and-shift)
  • •Reemplazar servidores de archivos NAS o file servers Windows
  • •Compartir archivos de configuración entre múltiples VMs
  • •Acceso concurrente desde múltiples máquinas a los mismos archivos
  • •Diagnósticos y logs que necesiten montarse como unidad de red

Protocolos — SMB vs NFS

CaracterísticaSMB 3.xNFS 4.1
SO soportadoWindows, Linux, macOSLinux únicamente
Tier requeridoStandard y PremiumPremium únicamente
Redundancia soportadaLRS, ZRS, GRS, GZRSLRS, ZRS únicamente
AutenticaciónEntra ID (Kerberos), Storage Key, SASIP-based (sin Kerberos)
Acceso desde internetSí (puerto 445)No — solo dentro de VNet
File Sync compatibleSíNo
Cuota máx. por share100 TiB (Standard: 5 TiB por defecto)100 TiB

Puerto 445 — problema frecuente

SMB usa el puerto 445. Muchos ISP y firewalls corporativos bloquean este puerto por razones de seguridad. Para montar un Azure File Share SMB desde on-premises, el puerto 445 debe estar abierto hacia el endpoint de storage. Alternativa: usar Azure VPN Gateway o ExpressRoute para conectar el tráfico por red privada.

Icon-storage-86

Tiers de Rendimiento

TierStorage Account tipoMediaIOPSUso ideal
Transaction OptimizedStandard (GPv2)HDDBajoFile shares de propósito general con muchas transacciones pequeñas
HotStandard (GPv2)HDDBajoFile shares accedidos frecuentemente
CoolStandard (GPv2)HDDBajoBackups y archivos accedidos raramente. Menor costo almacenamiento
PremiumFileStorage (especializado)SSDAltoLatencia baja. Bases de datos, ERP, aplicaciones críticas
Importante: Las cuentas Standard GPv2 permiten cambiar entre Transaction Optimized, Hot y Cool sin recrear el share. Las cuentas FileStorage (Premium) no se pueden convertir a Standard.

Snapshots de File Share

Los snapshots de Azure Files capturan el estado del file share en un punto del tiempo. Son incrementales (solo almacenan cambios desde el snapshot anterior) y de solo lectura.

Características de snapshots

  • •Máximo 200 snapshots por file share
  • •Se retienen aunque se eliminen los archivos originales
  • •Acceso via "Previous Versions" en Windows Explorer
  • •Pueden restaurarse archivos individuales o el share completo
  • •Se pueden crear manualmente o automáticamente con Azure Backup
  • •La eliminación del share base requiere eliminar todos los snapshots primero

Snapshot vs Soft Delete

Snapshot

Copia point-in-time iniciada por el usuario/proceso. Permite recuperar versiones anteriores de archivos específicos.

Soft Delete

Protege contra eliminación accidental del share completo. El share eliminado se retiene X días (1-365) antes de eliminarse definitivamente.

Azure File Sync

Azure File Sync convierte un Windows Server on-premises (o VM) en una caché rápida de Azure Files. Permite mantener un modelo híbrido: acceso local de baja latencia + almacenamiento en la nube + sincronización multi-sitio.

¿Qué resuelve Azure File Sync?

Problema: File server on-premises lento/caro

Solución: Tier less-used files a Azure, mantener hot files local

Problema: Multi-sitio necesita el mismo share

Solución: Sync Group sincroniza el mismo Azure Files entre 10+ servidores

Problema: Backup de file servers

Solución: Azure Files como backup automático con snapshots

Problema: Migración gradual a cloud

Solución: Migrar mientras usuarios siguen accediendo al server local

Componentes de Azure File Sync

☁️

1. Storage Sync Service

Recurso Azure (como un hub). Gestiona todas las relaciones de sincronización. Un tenant puede tener múltiples Storage Sync Services pero lo normal es 1 por región.

🔄

2. Sync Group

Define la topología de sincronización. Contiene 1 Cloud Endpoint (Azure Files share) y 1 o más Server Endpoints (rutas locales en servidores Windows).

📂

3. Cloud Endpoint

El Azure Files share que actúa como origen de verdad (source of truth). Solo 1 cloud endpoint por Sync Group. El share solo puede ser parte de 1 Sync Group.

🖥️

4. Server Endpoint

Ruta específica en un Windows Server registrado (ej: D:\Data\Shares). Máximo 30 server endpoints por servidor registrado. Un servidor puede estar en múltiples Sync Groups.

⚙️

5. Azure File Sync Agent

Software instalado en el Windows Server (on-premises o VM Azure). Versión actualizable. Registra el servidor en el Storage Sync Service.

// Flujo de configuración de File Sync

1. Crear Storage Account + Azure Files share

2. Crear Storage Sync Service en Azure

3. Instalar Azure File Sync agent en Windows Server

4. Registrar el servidor en el Storage Sync Service

5. Crear Sync Group en el Storage Sync Service

6. Añadir Cloud Endpoint (el Azure Files share)

7. Añadir Server Endpoint (ruta local: D:\Share)

8. Esperar sincronización inicial (puede tomar horas/días)

Cloud Tiering

Cloud tiering mueve automáticamente archivos poco usados del servidor local a Azure Files, dejando un stub (placeholder) que ocupa mínimo espacio pero permite acceder al archivo bajo demanda (se descarga automáticamente al abrirse).

Políticas de tiering

Volume Free Space Policy

Mantiene X% del volumen local libre. Si el disco llega al umbral, mueve archivos fríos a la nube. Configuración: 20% mínimo recomendado.

Date Policy

Mueve archivos no accedidos en los últimos N días (1-2555 días). Complementa la Volume Free Space Policy.

Comportamiento de stubs

  • •El stub tiene el mismo nombre e icono que el archivo original
  • •Al abrir el stub, Windows descarga el archivo automáticamente (recall)
  • •El stub solo ocupa unos KB independientemente del tamaño del archivo
  • •Excluir archivos del tiering: mover a carpeta marcada como "always local"
  • •Se puede forzar recall de todos los archivos: Invoke-StorageSyncFileRecall

Casos de Uso y Comparativa

EscenarioSoluciónPor qué
Compartir archivos entre VMs Windows en AzureAzure Files SMBMontaje nativo como unidad de red desde múltiples VMs
File server Linux que accede a share compartidoAzure Files NFS (Premium)NFS 4.1 solo para Linux, requiere tier Premium
File server on-premises + acceso remoto cloudAzure File Sync + Azure FilesCaché local + nube como fuente de verdad
Backup de file servers Windows on-premisesAzure File Sync (con snapshots Azure)Sincroniza a Azure Files y se hacen snapshots automáticos
Aplicación necesita acceso a archivos por RESTAzure Blob StorageFiles es SMB/NFS. Blob es para REST/SDK
SAP HANA necesita NFS de alta performanceAzure NetApp FilesFiles NFS no cumple los requisitos de latencia SAP

Trampas de Examen

NFS solo funciona en Premium y no soporta File Sync

NFS 4.1 requiere FileStorage account (Premium tier) y solo funciona en redes privadas. NFS NO es compatible con Azure File Sync — solo SMB lo es. Si el escenario pide sincronización híbrida, la respuesta es SMB.

Puerto 445 puede estar bloqueado — usar VPN/ExpressRoute

SMB usa el puerto 445 TCP. Es frecuente que ISP y firewalls corporativos lo bloqueen. La solución oficial es usar Azure VPN Gateway o ExpressRoute para tunnelizar el tráfico, o habilitar el puerto en el firewall corporativo.

Cloud Tiering solo en Server Endpoints, no en Cloud Endpoints

La política de cloud tiering se configura en el Server Endpoint (lado del servidor local), no en el Cloud Endpoint (Azure Files). El Azure Files share siempre tiene todos los archivos; el servidor local puede tener solo los archivos calientes.

Eliminar un file share con snapshots falla

No puedes eliminar un Azure Files share si tiene snapshots. Debes eliminar primero todos los snapshots (o usar az storage share delete --delete-snapshots include). Esto aplica también cuando el share está protegido por Azure Backup.

¿Entendiste este tema?

Pon a prueba lo que acabas de aprender

Una empresa tiene 5 oficinas en Europa con file servers Windows locales que necesitan acceder al mismo conjunto de archivos. Quieren reducir el espacio de almacenamiento local manteniendo acceso rápido a los archivos más usados. Los archivos no accedidos en 30 días pueden moverse a la nube. ¿Cuál es la solución correcta?