Planificación de una implementación de Azure Files

Planificar un despliegue de Azure Files implica varias decisiones clave. Utiliza este artículo para elegir las opciones adecuadas para tu carga de trabajo.

Debes decidir lo siguiente:

1. ¿Cómo accederán los clientes al recurso compartido? ¿Montar directamente desde clientes en la nube o locales, o mantener una caché en local con Azure File Sync?
2. ¿Qué modelo de gestión? ¿Recursos compartidos de archivos clásicos (cuentas de almacenamiento) o el nuevo proveedor de recursos Microsoft.FileShares?
3. ¿Qué protocolo?¿SMB (Windows/Linux/macOS) o NFS (solo Linux)?
4. ¿Cómo se autenticarán los usuarios?¿Autenticación basada en identidad o clave de cuenta de almacenamiento?
5. ¿Qué configuración de red? ¿Endpoints públicos, endpoints de servicio o endpoints privados?
6. ¿Qué nivel de rendimiento y opción de redundancia?SSD o HDD, ¿y qué opción de redundancia?

Las siguientes secciones cubren cada decisión en detalle.

Conceptos de administración

Azure Files ofrece dos modelos de gestión para desplegar compartidos de archivos:

• Recursos compartidos de archivos clásicos (proveedor de recursos Microsoft.Storage): Implemente recursos compartidos de archivos en una cuenta de almacenamiento. Soporta SMB y NFS, SSD y HDD, todos los tipos de redundancia y todas las regiones.
• Recursos compartidos de archivos (Microsoft.FileShares resource provider): Implemente recursos compartidos de archivos como recursos de nivel superior de Azure sin una cuenta de almacenamiento. Simplifica la gestión con configuración de red, facturación y seguridad por recurso compartido. Actualmente solo está disponible para compartidos de archivos NFS.

Para detalles sobre proveedores de recursos, comparaciones de funcionalidades y disponibilidad regional, consulte Azure Files Management Concepts.

Protocolos disponibles

Azure Files ofrece dos protocolos de sistema de archivos estándar del sector para montar recursos compartidos de archivos Azure: el protocolo Bloque de mensajes del servidor (SMB) y el protocolo Network File System (NFS). Elija el protocolo que mejor se adapte a la carga de trabajo. Los recursos compartidos de archivos de Azure no admiten los protocolos SMB y NFS en el mismo recurso compartido de archivos, aunque puede crear recursos compartidos de archivos SMB y NFS de Azure en la misma cuenta de almacenamiento.

Con los recursos compartidos de archivos SMB y NFS, Azure Files ofrece recursos compartidos de archivos de nivel empresarial que pueden escalar verticalmente para satisfacer sus necesidades de almacenamiento y miles de clientes pueden acceder a ellos simultáneamente.

Identidad

Para acceder a un recurso compartido de archivos de Azure, debe autenticarse y estar autorizado para acceder al recurso compartido. En casi todos los casos, utilice la autenticación basada en identidades en lugar de la clave de la cuenta de almacenamiento para acceder a los recursos compartidos de archivos SMB de Azure Files.

Azure Files admite los siguientes métodos de autenticación para recursos compartidos SMB:

• Servicios de dominio de Active Directory locales (AD DS): Puede unir cuentas de almacenamiento de Azure a un dominio de Servicios de dominio de Active Directory propiedad del cliente, igual que un servidor de archivos de Windows Server o un dispositivo NAS. Puede implementar un controlador de dominio local, en una máquina virtual de Azure o incluso como una máquina virtual en otro proveedor de nube. Azure Files es independiente de dónde se hospeda el controlador de dominio. Después de unirte a una cuenta de almacenamiento, el usuario final puede montar un intercambio de archivos con la cuenta de usuario con la que inició sesión en su PC. La autenticación basada en AD usa el protocolo de autenticación Kerberos.
• Microsoft Entra Domain Services: Microsoft Entra Domain Services proporciona un controlador de dominio administrado por Microsoft que puede usar para los recursos de Azure. La unión a un dominio de la cuenta de almacenamiento a Microsoft Entra Domain Services proporciona ventajas similares a la unión a un dominio de dicha cuenta a una instancia de AD DS propiedad del cliente. Esta opción de implementación es especialmente útil para escenarios de migración mediante lift-and-shift de aplicaciones que requieren permisos basados en AD. Dado que Domain Services proporciona autenticación basada en AD, esta opción también usa el protocolo de autenticación Kerberos.
• Microsoft Entra Kerberos: Microsoft Entra Kerberos permite usar Microsoft Entra ID para autenticar hybrid o identidades solo en la nube. Esta configuración usa Microsoft Entra ID para emitir tickets de Kerberos para acceder al archivo compartido con el protocolo SMB. Esto significa que los usuarios finales pueden acceder a las comparticiones de archivos de Azure a través de Internet desde máquinas virtuales unidas a Microsoft Entra híbrido y a Microsoft Entra.
• Autenticación de Active Directory mediante SMB para clientes de Linux: Azure Files admite la autenticación basada en identidades mediante SMB para clientes de Linux mediante el protocolo de autenticación Kerberos con AD DS o Microsoft Entra Domain Services.
• Clave de cuenta de almacenamiento de Azure: Aunque no se recomienda por motivos de seguridad, también puede montar recursos compartidos de archivos de Azure mediante una clave de cuenta de almacenamiento de Azure en lugar de una identidad. Para montar un recurso compartido de archivos mediante la clave de cuenta de almacenamiento, use el nombre de la cuenta de almacenamiento como nombre de usuario y la clave de la cuenta de almacenamiento como contraseña. El uso de la clave de cuenta de almacenamiento para montar el recurso compartido de archivos Azure es una operación de administrador, ya que el recurso compartido de archivos montado tiene permisos completos para todos los archivos y carpetas del recurso compartido, incluso si tienen ACL. Cuando se usa la clave de cuenta de almacenamiento para montar a través de SMB, se usa el protocolo de autenticación NTLMv2. Si debe usar la clave de la cuenta de almacenamiento, use puntos de conexión privados o puntos de conexión de servicio como se describe en la sección Redes .

Para los clientes que migran desde servidores de archivos locales o crean nuevos recursos compartidos de archivos en Azure Files destinados a comportarse como servidores de archivos de Windows Server o dispositivos NAS, una la cuenta de almacenamiento al AD DS propiedad del cliente. Para más información, consulte Overview: autenticación de AD DS local a través de SMB para recursos compartidos de archivos Azure.

Redes

El montaje directo del recurso compartido de archivos de Azure a menudo requiere cierta consideración sobre la configuración de red porque:

• Muchas organizaciones y proveedores de servicios de Internet (ISP) bloquean el puerto 445, que los recursos compartidos de archivos SMB usan para la comunicación, para el tráfico saliente (Internet).
• Los recursos compartidos de archivos NFS se basan en la autenticación de nivel de red y, por tanto, solo son accesibles mediante redes restringidas. El uso de un recurso compartido de archivos NFS siempre requiere algún nivel de configuración de redes.

Para configurar las redes, Azure Files proporciona un punto de conexión público accesible a Internet e integración con características de red Azure, como puntos de conexión de servicio, que ayudan a restringir el punto de conexión público a redes virtuales especificadas y puntos de conexión privados, que proporcionan a la cuenta de almacenamiento una dirección IP privada desde dentro de un espacio de direcciones IP de red virtual. Aunque no hay ningún cargo adicional por el uso de puntos de conexión públicos o puntos de conexión de servicio, las tasas de procesamiento de datos estándar se aplican a los puntos de conexión privados.

Tenga en cuenta las siguientes configuraciones de red:

• Si el protocolo necesario es SMB y todo el acceso a través de SMB procede de clientes de Azure, no se requiere ninguna configuración de red especial.
• Si el protocolo necesario es SMB y el acceso es desde clientes locales, se requiere una conexión VPN o Azure ExpressRoute desde el entorno local a la red Azure, con Azure Files expuesto en la red interna mediante puntos de conexión privados.
• Si el protocolo necesario es NFS, puede usar puntos de conexión de servicio o puntos de conexión privados para restringir la red a redes virtuales específicas. Si necesita una dirección IP estática o la carga de trabajo requiere alta disponibilidad, use un punto de conexión privado. Con los puntos de conexión de servicio, un evento poco frecuente, como una interrupción de zona, podría provocar que la dirección IP subyacente de la cuenta de almacenamiento cambie. Aunque los datos seguirán estando disponibles en el recurso compartido de archivos, el cliente requeriría un remontaje del recurso compartido.

Para obtener más información, consulte Azure Files consideraciones sobre redes.

Además de conectarse directamente al recurso compartido de archivos mediante el punto de conexión público o mediante una conexión VPN o ExpressRoute con un punto de conexión privado, SMB proporciona una estrategia de acceso de cliente adicional: SMB a través de QUIC. SMB vía QUIC ofrece "VPN SMB" de configuración cero para el acceso SMB a través del protocolo de transporte QUIC. Aunque Azure Files no admite directamente SMB sobre QUIC, puedes crear una caché ligera de tus recursos compartidos de archivos de Azure en una máquina virtual (VM) con Windows Server 2022 Azure Edition mediante Azure File Sync. Para obtener más información sobre esta opción, consulta SMB sobre QUIC con Azure File Sync.

Cifrado para Azure Files

Azure Files admite dos tipos diferentes de cifrado:

• Cifrado en tránsito, que se relaciona con el cifrado utilizado al montar o acceder al recurso compartido de archivos de Azure
• Cifrado en reposo, que se relaciona con la manera en que cifran los datos cuando se almacenan en el disco

Cifrado en tránsito

De forma predeterminada, todas las cuentas de almacenamiento de Azure tienen habilitado el cifrado en tránsito. Esta característica significa que, al montar un recurso compartido de archivos a través de SMB o acceder a él a través del protocolo FileREST (por ejemplo, a través del portal de Azure, PowerShell/CLI o SDK de Azure), Azure Files solo permite la conexión si se realiza con SMB 3.x con cifrado o HTTPS. Los clientes que no admiten SMB 3.x o los clientes que admiten SMB 3.x, pero no el cifrado SMB no pueden montar el recurso compartido de archivos de Azure si está habilitado el cifrado en tránsito. Para obtener más información sobre qué sistemas operativos admiten SMB 3.x con cifrado, consulte la documentación de Windows, macOS y Linux. Todas las versiones actuales de PowerShell, la CLI y los SDK admiten HTTPS.

Puede deshabilitar el cifrado en tránsito para una cuenta de almacenamiento de Azure. Al deshabilitar el cifrado, Azure Files también permite SMB 2.1 y SMB 3.x sin cifrado y llamadas API FileREST sin cifrar a través de HTTP. La razón principal para deshabilitar el cifrado en tránsito es admitir una aplicación heredada que se debe ejecutar en un sistema operativo anterior, como Windows Server 2008 R2 o una distribución de Linux anterior. Azure Files solo permite conexiones SMB 2.1 desde la misma región de Azure que el recurso compartido de archivos de Azure. Un cliente SMB 2.1 situado fuera de la región de Azure en la que se encuentra el recurso compartido de archivos, por ejemplo en el entorno local o en otra región de Azure, no puede acceder al recurso compartido de archivos.

Asegúrese de que el cifrado de datos en tránsito está habilitado.

Para obtener más información sobre el cifrado en tránsito, consulte requirir transferencia segura en almacenamiento Azure y Cifrado en tránsito para recursos compartidos de archivos NFS de Azure.

Cifrado en reposo

Azure Files usa el mismo esquema de cifrado que los demás servicios de almacenamiento de Azure, como Azure Blob Storage. Todos los datos almacenados en Azure Files se cifran en reposo a través de cifrado del lado del servicio (SSE), que funciona de forma similar a BitLocker en Windows.

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 es necesario tener 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 forma predeterminada, los datos almacenados en Azure Files se cifran con claves administradas Microsoft. Con claves administradas Microsoft, Microsoft contiene las claves para cifrar y descifrar los datos. Microsoft es responsable de rotar estas claves con regularidad.

Para recursos compartidos de archivos clásicos de Azure, puede elegir cifrar sus datos con claves administradas por el cliente. Si elige claves administradas por el cliente, Azure Files está autorizado para acceder a las claves para 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. Sin embargo, sin esta autorización, el recurso compartido de archivos de Azure ya no es accesible a través de SMB o la API FileREST.

No se pueden usar claves administradas por el cliente para el cifrado en reposo con recursos compartidos de archivos de Azure creados mediante el proveedor de recursos Microsoft.FileShares. Debe usar claves administradas por Microsoft.

Protección de los datos

Azure Files adopta un enfoque multicapa para garantizar que sus datos estén respaldados, sean recuperables y estén protegidos frente a amenazas de seguridad. Consulte Azure Files información general sobre la protección de datos.

Eliminación suave

La eliminación temporal es una configuración de nivel de cuenta de almacenamiento que puede usar para recuperar su recurso compartido de archivos cuando se elimina accidentalmente. Cuando elimina un recurso compartido de archivos, pasa a un estado de eliminación temporal en lugar de borrarse permanentemente. Se puede configurar el tiempo durante el que los recursos compartidos eliminados de forma no definitiva son recuperables antes de que se eliminen permanentemente, y restaurar el recurso compartido en cualquier momento durante este período de retención.

La eliminación suave está habilitada de manera predeterminada para las nuevas cuentas de almacenamiento. Si tiene un flujo de trabajo en el que la eliminación de recursos compartidos es habitual y previsible, puede decidir establecer un período de retención corto o no habilitar la eliminación lógica.

Para obtener más información sobre la eliminación suave, consulte Evitar la eliminación accidental de datos.

Copia de seguridad

Realice una copia de seguridad de sus recursos compartidos de archivos de Azure mediante instantáneas de recursos compartidos, que son copias de solo lectura de un momento dado de su recurso compartido. Las instantáneas son incrementales, por lo que solo incluyen datos que han cambiado desde la instantánea anterior. Cada recurso compartido de archivos admite hasta 200 instantáneas y puede conservarlas durante un máximo de 10 años. Puede crear manualmente instantáneas en el portal de Azure o usar PowerShell o la interfaz de línea de comandos (CLI). También puede usar Azure Backup.

Azure Backup para almacenamientos de archivos de Azure con SMB se encarga de programar y retener instantáneas. Sus capacidades de abuelo-padre-hijo (GFS) significan que puede tomar instantáneas diarias, semanales, mensuales y anuales, cada una con su propio período de retención distinto. Azure Backup también orquesta la habilitación de la eliminación temporal y aplica un bloqueo de eliminación a una cuenta de almacenamiento tan pronto como se configura una de sus carpetas compartidas para la copia de seguridad. Azure Backup proporciona ciertas funcionalidades clave de supervisión y alertas que permiten a los clientes tener una vista consolidada de su patrimonio de copias de seguridad.

Puede realizar restauraciones de nivel de elemento y de nivel de recurso compartido en el portal de Azure mediante Azure Backup. Elige el punto de restauración (una instantánea concreta), el archivo o directorio en particular si es relevante, y luego la ubicación (original u alternativa) donde quieres restaurar. El servicio de copia de seguridad controla la copia de los datos de instantáneas y muestra el progreso de la restauración en el portal.

Protección de Azure Files con Microsoft Defender para Storage

Microsoft Defender para Storage es una capa nativa Azure de inteligencia de seguridad que detecta posibles amenazas para las cuentas de almacenamiento. Proporciona una seguridad completa mediante el análisis de la telemetría del plano de datos y el plano de control generados por Azure Files. Usa funcionalidades avanzadas de detección de amenazas con tecnología de Microsoft Inteligencia sobre amenazas para proporcionar alertas de seguridad contextuales, incluidos los pasos para mitigar las amenazas detectadas y evitar futuros ataques.

Defender de Storage analiza continuamente el flujo de telemetría generado por Azure Files. Cuando se detectan actividades potencialmente malintencionadas, se generan alertas de seguridad. Estas alertas se muestran en Microsoft Defender para la nube, junto con los detalles de la actividad sospechosa, los pasos de investigación, las acciones de corrección y las recomendaciones de seguridad.

Defender para Storage detecta malware conocido, como ransomware, virus, spyware y otro malware cargado en una cuenta de almacenamiento basada en hash de archivo completo (solo se admite para la API REST). Esto ayuda a evitar que el malware entre en la organización y se propague a más usuarios y recursos. Consulte Descripción de las diferencias entre el examen de malware y el análisis de reputación de hash.

Defender para Storage no tiene acceso a los datos de la cuenta de almacenamiento y no afecta a su rendimiento. Puede habilitar Microsoft Defender para Almacenamiento en el nivel de suscripción (recomendado) o en el nivel de recursos.

Niveles de almacenamiento

Azure Files ofrece dos niveles de almacenamiento multimedia: 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 SLA 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 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 Comprender los modelos de facturación de Azure Files y Comprender y optimizar el rendimiento del recurso compartido de archivos de Azure.

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 actualmente admite las siguientes opciones para la redundancia de datos:

• Almacenamiento con redundancia local (LRS): con 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 Azure availability zones. 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. A continuación, 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 geozonal con acceso de lectura (RA-GZRS). Puede aprovisionar comparticiones 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.

Para obtener más información sobre la redundancia, consulte Azure Files redundancia de datos.

Disponibilidad de archivos compartidos SSD redundantes por zona

Los almacenamientos de archivos SSD con redundancia de zona están disponibles en un subconjunto de regiones de Azure.

Recuperación ante desastres y conmutación por error

En el caso de una interrupción del servicio regional no planeada, debe tener un plan de recuperación ante desastres (DR) para los recursos compartidos de archivos de Azure. Para comprender los conceptos y los procesos implicados en la conmutación por error de la cuenta de almacenamiento y recuperación ante desastres, consulte Recuperación ante desastres y conmutación por error para Azure Files.

Migración

En muchos casos, no establecerá un nuevo recurso compartido de archivos neto para su organización, sino que migrará un recurso compartido de archivos existente desde un servidor de archivos local o un dispositivo NAS a Azure Files. Elegir la estrategia y la herramienta de migración adecuadas es importante para el éxito de la migración.

Para las migraciones de SMB, consulte Información general sobre la migración de SMB que contiene una tabla que le lleva a guías de migración que probablemente cubran su escenario.

Para las migraciones de NFS, consulte Migrate a recursos compartidos de archivos Azure NFS.

Pasos siguientes

• Plan para una implementación de Azure File Sync
• Implementación de Azure Files
• Implementación de Azure File Sync