Planeación de la implementación de Azure Files

Puede implementar Azure Files de dos maneras: montando directamente los recursos compartidos de archivos sin servidor Azure o almacenando en caché los recursos compartidos de archivos locales mediante Azure File Sync. Las consideraciones de implementación difieren en función de la opción que elija.

• Montaje directo de un recurso compartido de archivos de Azure: dado que Azure Files proporciona acceso al bloque de mensajes del servidor (SMB) o al sistema de archivos de red (NFS), puede montar Azure recursos compartidos de archivos locales o en la nube mediante el uso de los clientes estándar SMB o NFS disponibles en el sistema operativo. Dado que Azure recursos compartidos de archivos no tienen servidor, la implementación en escenarios de producción no requiere administrar un servidor de archivos ni un dispositivo NAS. Esta arquitectura significa que no tiene que aplicar revisiones de software ni intercambiar discos físicos. Puede elegir ya sea los recursos compartidos de archivos clásicos de Azure (SMB y NFS) o Microsoft.FileShares (solo NFS) como modelo de administración.

• Almacena en caché los recursos compartidos de archivos de Azure en las instalaciones con Azure File Sync (solo SMB): Azure File Sync le permite centralizar los recursos compartidos de archivos de su organización en Azure Files, a la vez que mantiene la flexibilidad, el rendimiento y la compatibilidad de un servidor de archivos local. Azure File Sync transforma un Windows Server local (o en la nube) en una memoria caché rápida del recurso compartido de archivos Azure SMB.

En este artículo se abordan principalmente las consideraciones de implementación para implementar un recurso compartido de archivos de Azure que un cliente local o en la nube monte directamente. Si planea usar Azure File Sync, consulte Planning para una implementación de Azure File Sync.

Conceptos de administración

En Azure, un resource es un elemento administrable que se crea y configura dentro de las suscripciones y grupos de recursos de Azure. Los proveedores de recursos son servicios de administración que proporcionan tipos específicos de recursos. Aunque puede trabajar con muchos recursos para implementar una carga de trabajo en Azure, Azure Files se centra en dos recursos clave:

• Storage accounts, ofrecido 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 implemente 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.

• Recursos compartidos de archivos, ofrecidos por el proveedor de recursos Microsoft.FileShares. Los recursos compartidos de archivos son un nuevo recurso de nivel superior que simplifica la implementación de Azure Files eliminando la necesidad de una cuenta de almacenamiento. A diferencia de los recursos compartidos de archivos clásicos, que debe implementar en una cuenta de almacenamiento, implemente recursos compartidos de archivos directamente en el grupo de recursos, como las cuentas de almacenamiento, u otros recursos de Azure como máquinas virtuales, discos o redes virtuales. Actualmente, Microsoft.FileShares solo admite el protocolo de uso compartido de archivos NFS. Si necesita SMB, elija recursos compartidos de archivos clásicos.

En este vídeo se proporciona información general completa de las diferencias entre la cuenta de almacenamiento y los modelos de administración de recursos compartidos de archivos:

Recursos clásicos de comparticiones de archivos (Microsoft.Storage)

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 admiten, incluidos los niveles de medios SMB y NFS, SSD y HDD, cada tipo de redundancia y disponibilidad en cada región. Aunque los recursos compartidos de archivos clásicos admiten toda la amplitud de las características de Azure Files, tienen limitaciones importantes:

• Planificación de la capacidad: los recursos compartidos de archivo clásicos, así como los objetos secundarios, como los contenedores de blobs que residen dentro de la misma cuenta de almacenamiento, comparten un grupo común de almacenamiento, IOPS y rendimiento. Esta arquitectura significa que debe planificar cuidadosamente para evitar cuellos de botella de capacidad al alojar varios recursos compartidos de archivos clásicos en una cuenta de almacenamiento. Considere las necesidades actuales y futuras de cada recurso compartido de archivos clásico colocado en una cuenta de almacenamiento, ya que el crecimiento de un recurso compartido de archivos clásico puede sacar a otros recursos compartidos de archivos.

• Configuración compartida: se aplican muchas configuraciones importantes, como reglas de red y seguridad, en el nivel de cuenta de almacenamiento. Como resultado, debe considerar cuidadosamente cómo ubicar recursos compartidos de archivos clásicos en la misma cuenta de almacenamiento. Considere la cuenta de almacenamiento un límite de confianza y coloque recursos compartidos de archivos clásicos en la misma cuenta de almacenamiento solo si le parece bien que tengan la misma configuración de seguridad.

• Complejidad del escalado: las implementaciones de Azure Files a gran escala pueden requerir la administración de muchas suscripciones Azure debido a las restricciones en las cuentas de almacenamiento del Microsoft.Storage proveedor de recursos. Consulte Límites de cuentas de almacenamiento para obtener más información.

Las implementaciones clásicas de recursos compartidos de archivos usan dos tipos de cuentas de almacenamiento:

• Cuentas de almacenamiento aprovisionadas: el FileStorage tipo de cuenta de almacenamiento identifica las cuentas de almacenamiento aprovisionadas. Puede implementar recursos compartidos de archivos clásicos aprovisionados en hardware basado en SSD o HDD mediante cuentas de almacenamiento aprovisionadas. Solo se pueden usar cuentas de almacenamiento aprovisionadas para almacenar archivos compartidos clásicos. No se pueden usar para otros recursos de almacenamiento, como contenedores de blobs, colas y tablas. Use cuentas de almacenamiento aprovisionadas para todas las nuevas implementaciones de recursos compartidos de archivos clásicos.

• Cuentas de almacenamiento de pago por uso: el StorageV2 tipo de cuenta de almacenamiento identifica las cuentas de almacenamiento de pago por uso. Puede implementar recursos compartidos de archivos de pago por uso sobre hardware basado en HDD mediante el uso de cuentas de almacenamiento de pago por uso. Puede usar cuentas de almacenamiento de pago por consumo para almacenar archivos compartidos clásicos y otros recursos de almacenamiento, como contenedores de blobs, colas o tablas.

Para obtener más información, consulte Creación de un recurso compartido de archivos clásico.

Recursos compartidos de archivos (Microsoft.FileShares)

El Microsoft.FileShares proveedor de recursos ofrece recursos compartidos de archivos como un nuevo recurso de Azure de nivel superior. Estos recursos compartidos de archivos proporcionan las siguientes ventajas sobre los recursos compartidos de archivos clásicos:

• Administración simplificada: cree recursos compartidos de archivos directamente como recursos de nivel superior en el portal de Azure o a través de las API de administración. Este enfoque elimina el requisito de administrar una cuenta de almacenamiento y simplifica la experiencia de implementación.

• Capacidad y rendimiento independientes: cada recurso compartido de archivos tiene su propio almacenamiento dedicado, IOPS y rendimiento. Este diseño evita la necesidad de planear la capacidad con los recursos limitados de la cuenta de almacenamiento y permite que los recursos compartidos de archivos crezcan libremente a medida que crecen las demandas de carga de trabajo.

• Configuración granular: aplique la configuración de red y seguridad en el nivel de recurso compartido de archivos, por lo que tiene un control preciso de los límites de acceso y el aislamiento. Esta configuración facilita la aplicación de directivas de seguridad para aplicaciones, equipos o entornos específicos.

• Facturación predecible y flexible: los recursos compartidos de archivos usan el modelo de facturación v2 aprovisionado, que permite aprovisionar de forma independiente el almacenamiento, las IOPS y el rendimiento por recurso compartido. Dado que Azure factura por recurso de Azure de nivel superior, puede realizar fácilmente un seguimiento de los costos de cada recurso compartido individual para la atribución de costos al proyecto, equipo o cliente que usa el recurso compartido de archivos.

• Escala y rendimiento mejorados: los recursos compartidos de archivos admiten límites más altos y tiempos de implementación más bajos que los recursos compartidos de archivos clásicos. Para obtener más información, consulte Azure Files objetivos de escalabilidad y rendimiento.

Disponibilidad regional

Actualmente, puede crear un recurso compartido de archivos con Microsoft.FileShares en las siguientes regiones. La compatibilidad con puntos de conexión privados para recursos compartidos de archivos con Microsoft.FileShares está disponible en todas las regiones de la nube pública de Azure.

• Centro de Australia
• Australia East
• Australia Southeast
• Sur de Brasil
• Brazil Southeast
• Centro de Canadá
• Canada East
• Central India
• Este de Asia
• East US
• France Central
• France South
• Norte de Alemania
• Centro-oeste de Alemania
• Israel Central
• Italy North
• Este de Japón
• Japan West
• JIO India Central
• JIO India Occidental
• Korea Central
• Corea del Sur
• Centro-Norte de EE. UU
• Norte de Europa
• Norway East
• Norway West
• Poland Central
• Norte de Sudáfrica
• Oeste de Sudáfrica
• Centro-sur de EE. UU.
• South India
• Sudeste Asiático
• Sweden Central
• Centro de Emiratos Árabes Unidos
• Norte de Emiratos Árabes Unidos
• UK South
• UK West
• Oeste de Europa
• West US

Comparación de proveedores de recursos: Microsoft.Storage frente a Microsoft.FileShares

Le recomendamos que evalúe la nueva experiencia del recurso compartido de archivos con Microsoft. FileShares para todas las nuevas implementaciones de protocolo NFS de Azure Files.

Si un requisito de característica específico aún no está disponible en la nueva experiencia de recurso compartido de archivos o la carga de trabajo requiere compatibilidad con el protocolo SMB, use la experiencia clásica del recurso compartido de archivos. El desuso de la experiencia clásica no comenzará hasta que se cierren las brechas de características restantes. Actualmente, no hay compatibilidad para la migración automatizada de recursos compartidos de archivos clásicos a recursos compartidos de archivos.

Característica	Recursos compartidos de archivos clásico	Recursos compartidos de archivos (Microsoft. FileShares)
Garantía de soporte técnico	Disponible con carácter general	Disponible con carácter general
Recurso de nivel superior para el servicio	Cuenta de almacenamiento	Recursos compartidos de archivos
Protocolo SMB
Protocolo NFS
compatibilidad con Azure File Sync
Requerir cuenta de almacenamiento
Modelo de facturación de pago por uso
Modelo de facturación v1 aprovisionado
Modelo de facturación v2 aprovisionado
Compatibilidad con HDD
Compatibilidad con SSD
LRS
ZRS
GRS
GZRS
Configuraciones de seguridad, redes y facturación de nivel por recurso compartido
Configuraciones de red virtual única para un recurso compartido de archivos
Configuración de red virtual única para varios recursos compartidos de archivos
Controlador CSI de AKS
API de REST de plano de datos
Compatibilidad con la eliminación lógica
Soporte para instantáneas
Cifrado en tránsito
Claves administradas por el cliente
Anclaje zonal

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. Una vez que se une una cuenta de almacenamiento al dominio, el usuario final puede montar un recurso compartido de archivos con la misma cuenta de usuario con la que inició sesión en su equipo. 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 que crean nuevos recursos compartidos de archivos en Azure Files pensados para funcionar como servidores de archivos de Windows Server o dispositivos NAS, una la cuenta de almacenamiento al dominio de 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 a través de QUIC, puede crear una caché ligera de los recursos compartidos de archivos de Azure en una máquina virtual Windows Server 2022 Azure Edition mediante Azure File Sync. Para más información sobre esta opción, consulte 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 a nivel de cuenta de almacenamiento que puede usar para recuperar el recurso compartido de archivos si se elimina accidentalmente. Cuando eliminas un recurso compartido de archivos, pasa a un estado de eliminación temporal en lugar de eliminarse de forma permanente. 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

Haga una copia de seguridad de los 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. Elija el punto de restauración (una instantánea determinada), el archivo o directorio determinado si procede y, a continuación, la ubicación (original o alternativa) a la que desea 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