Plan de implementación de Azure Files

Puede implementar Azure Files de dos maneras principales: mediante el montaje directo de los recursos compartidos de archivos de Azure sin servidor o el almacenamiento en caché de 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 mediante Bloque de mensajes del servidor (SMB) o Network File System (NFS), puede montar recursos compartidos de archivos de Azure en el entorno local o en la nube mediante los clientes SMB o NFS estándar disponibles en el sistema operativo. Dado 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 NAS. lo que significa que no tiene que aplicar revisiones de software ni intercambiar discos físicos. Puede optar por usar recursos compartidos de archivos clásicos de Azure o Microsoft.FileShares (versión preliminar) como modelo de administración.

• Almacenamiento en caché de recursos compartidos de archivos de Azure locales con Azure File Sync: 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 una instancia de Windows Server local (o en la nube) en una caché rápida del recurso compartido de archivos SMB de Azure.

En este artículo se abordan principalmente las consideraciones de implementación de un recurso compartido de archivos de Azure que se va a montar directamente mediante un cliente local o en la nube. Para planear una implementación de Azure File Sync, consulte Planeamiento de una implementación de Azure File Sync.

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. Aunque puede trabajar con muchos recursos para implementar una carga de trabajo en Azure, Azure Files se centra en 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.

• Recursos compartidos de archivos (versión preliminar), 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 se deben implementar en una cuenta de almacenamiento, los recursos compartidos de archivos se implementan 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 compartidos de archivos clásicos (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 admite, incluidos SMB y NFS, los niveles de medios SSD y HDD, todos los tipos de redundancia y 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 clave 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. Esto significa que la colocación de varios recursos compartidos de archivos clásicos en una cuenta de almacenamiento requiere planear la planeación para evitar cuellos de botella de capacidad. Al planear recursos compartidos de archivos clásico, debe tener en cuenta 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 desplazar a otros recursos compartidos de archivos.

• Configuración compartida: muchas configuraciones importantes, como las reglas de seguridad y de red, se aplican en el nivel de cuenta de almacenamiento. Como resultado, la colocación de recursos compartidos de archivo clásicos en la misma cuenta de almacenamiento requiere una consideración cuidadosa. Debe considerar que la cuenta de almacenamiento es un límite de confianza y colocar solo recursos compartidos de archivos clásicos en la misma cuenta de almacenamiento si le parece correcto que ellos compartan 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 de Azure debido a las restricciones de las cuentas de almacenamiento del Microsoft.Storage proveedor de recursos. Consulte Límites de cuentas de almacenamiento para obtener más información.

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.

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

Recurso compartido de archivos (Microsoft.FileShares)

Los recursos compartidos de archivos (versión preliminar) son un nuevo recurso de Azure de nivel superior proporcionado por el proveedor de recursos Microsoft.FileShares. Estos recursos compartidos de archivos ofrecen las siguientes ventajas sobre los recursos compartidos de archivos clásicos:

• Administración simplificada: los recursos compartidos de archivos se crean directamente como recursos de nivel superior en Azure Portal o a través de las API de administración. Esto 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. Esto evita la necesidad de planear la capacidad con respecto a 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: las opciones de red y seguridad se aplican en el nivel de recurso compartido de archivos, lo que proporciona un control preciso de los límites de acceso y el aislamiento. Esto 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 la facturación en Azure se realiza por recurso de Azure de nivel superior, esto le permite 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 más información, consulte Objetivos de escalabilidad y rendimiento de Azure Files.

Disponibilidad regional

Actualmente, la creación de un recurso compartido de archivos con Microsoft.FileShares (versión preliminar) está disponible en las siguientes regiones. La compatibilidad con puntos de conexión privados para el recurso compartido de archivos con Microsoft.FileShares (versión preliminar) está disponible en todas las regiones de nube pública de Azure.

• Australia East
• Centro de Australia
• Australia Southeast
• Este de Asia
• East US
• Norte de Alemania
• Corea del Sur
• Sudeste Asiático
• Norte de Europa
• Oeste de Sudáfrica
• South India
• Centro de Emiratos Árabes Unidos

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

Característica	Recursos compartidos de archivos clásico	Recursos compartidos de archivos (Microsoft.FileShares)
Garantía de soporte técnico	Disponibilidad general	Versión preliminar pública
Recurso de nivel superior para el servicio	Cuenta de almacenamiento	Recursos compartidos de archivos
Protocolo SMB
Protocolo NFS
Compatibilidad con 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

Protocolos disponibles

Azure Files ofrece dos protocolos de sistema de archivos estándar del sector para montar recursos compartidos de archivos de Azure: el protocolo Bloque de mensajes del servidor (SMB) y el protocolo Network File System (NFS), permitiéndole elegir el protocolo que se ajuste más a su 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 de Azure SMB y NFS dentro de 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 se pueden escalar verticalmente para satisfacer sus necesidades de almacenamiento y a los que pueden acceder simultáneamente miles de clientes.

Identidad

Para acceder a un recurso compartido de archivos de Azure, el usuario debe estar autenticado y tener la debida autorización. Esto se hace en función de la identidad del usuario que accede al recurso compartido de archivos. Azure Files admite los siguientes métodos de autenticación:

• Active Directory Domain Services local (AD DS, o AD DS local): las cuentas de almacenamiento de Azure pueden estar unidas a un dominio de Active Directory Domain Services propiedad del cliente, al igual que un servidor de archivos de Windows Server o un dispositivo NAS. Puede implementar un controlador de dominio en el entorno local, en una VM de Azure o, incluso, como VM en otro proveedor de nube. Azure Files es independiente de la ubicación donde se hospeda el controlador de dominio. Una vez que una cuenta de almacenamiento está unida a un dominio, el usuario final puede montar un recurso compartido de archivos con la 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 se 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 Microsoft Entra 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 el identificador de Microsoft Entra para autenticar identidades híbridas o solo en la nube (versión preliminar). 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 a través de SMB para clientes Linux: Azure Files admite la autenticación basada en identidades a través de SMB para clientes Linux mediante el protocolo de autenticación Kerberos mediante AD DS o Microsoft Entra Domain Services.
• Clave de la 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 usar una identidad. Para montar un recurso compartido de archivos mediante la clave de cuenta de almacenamiento, el nombre de la cuenta de almacenamiento se usa como nombre de usuario y la clave de la cuenta de almacenamiento se usa como contraseña. El uso de la clave de cuenta de almacenamiento para montar el recurso compartido de archivos de Azure es eficazmente 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 la cuenta de almacenamiento para el montaje a través de SMB, se usa el protocolo de autenticación NTLMv2. En casi todos los casos, se recomienda usar la autenticación basada en identidades en lugar de la clave de cuenta de almacenamiento para acceder a recursos compartidos de archivos de Azure SMB. Sin embargo, si debe usar la clave de cuenta de almacenamiento, se recomienda usar 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 creando nuevos recursos compartidos de archivos en Azure Files destinados a comportarse como servidores de archivos de Windows o dispositivos NAS, se recomienda unir el dominio de la cuenta de almacenamiento a AD DS propiedad del cliente . Para obtener más información sobre la unión de dominio de su cuenta de almacenamiento a un AD DS propiedad del cliente, consulte Información general: autenticación de Active Directory Domain Services local en SMB para recursos compartidos de archivos de Azure.

Redes

El montaje directo del recurso compartido de archivos de Azure a menudo requiere cierta idea sobre la configuración de red, debido a las siguientes razones:

• El puerto que usan los recursos compartidos de archivos SMB para la comunicación, el puerto 445, se suele bloquear por parte de muchas organizaciones y proveedores de servicios de Internet (ISP) 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 través de Internet e integración con características de red de Azure como puntos de conexión de servicio, que ayudan a restringir el punto de conexión público a redes virtuales específicas y puntos de conexión privados, que proporcionan a la cuenta de almacenamiento una dirección IP privada desde 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.

Esto significa que deberá tener 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 conexión en red especial.
• Si el protocolo requerido es SMB y el acceso es desde clientes locales, entonces se requiere una conexión VPN o ExpressRoute desde los locales a su red Azure, con Azure Files expuestos en su red interna usando 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 zonal, podría provocar que la dirección IP subyacente de la cuenta de almacenamiento cambiase. Aunque los datos seguirán estando disponibles en el recurso compartido de archivos, el cliente requeriría un remontaje del recurso compartido.

Para más información sobre cómo configurar las redes para Azure Files, consulte Consideraciones sobre redes de Azure Files.

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 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 con Azure File Sync.

Cifrado

Azure Files admite dos tipos diferentes de cifrado:

• Cifrado en tránsito, que se relaciona con el cifrado usado 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 Azure Storage tienen habilitado el cifrado en tránsito. Esto 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 de Azure Portal, 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 podrán 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 nuestra documentación para 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. Cuando el cifrado está deshabilitado, 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 debe ejecutarse 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 dentro de la misma región de Azure del recurso compartido de archivos de Azure. Un cliente SMB 2.1 fuera de la región de Azure del recurso compartido de archivos de Azure (por ejemplo, en un entorno local o en una región de Azure diferente) no podrá acceder al recurso compartido de archivos.

Se recomienda encarecidamente asegurarse de que está habilitado el cifrado de los datos en tránsito.

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

Cifrado en reposo

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.

Protección de los datos

Azure Files tiene un enfoque de varias capas para garantizar la copia de seguridad de los datos, su recuperación y su protección contra amenazas de seguridad. Consulte Introducción a la protección de datos de Azure Files.

Eliminación suave

La eliminación suave es una configuración a nivel de cuenta de almacenamiento que permite recuperar la compartición de archivos si se elimina accidentalmente. Cuando se elimina un recurso compartido de archivos, pasa a un estado de eliminación temporal, en lugar de borrarse 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 comparticiones es común y se espera, puede que decida tener un período de retención corto o no tener habilitado el borrado reversible.

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

Copia de seguridad

Puede realizar una copia de seguridad del recurso compartido de archivos de Azure a través de instantáneas de recurso compartido, que son copias de solo lectura de un momento dado del recurso compartido. Las instantáneas son incrementales, lo que significa que solo contienen los datos que han cambiado desde la instantánea anterior. Puede tener hasta 200 instantáneas por recurso compartido de archivos y conservarlas durante un máximo de diez años. Puede realizar instantáneas manualmente en Azure Portal, a través de PowerShell o en la interfaz de la línea de comandos (CLI), o bien puede usar Azure Backup.

Azure Backup para recursos compartidos de archivos de Azure controla la programación y retención de 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 organiza la habilitación de la eliminación temporal y toma un bloqueo de eliminación en una cuenta de almacenamiento en cuanto se configura un recurso compartido de archivos en ella para la copia de seguridad. Por último, Azure Backup proporciona ciertas capacidades clave de supervisión y alertas que permiten a los clientes tener una vista consolidada de su copia de seguridad.

Puede realizar restauraciones de nivel de elemento y de nivel de recurso compartido en Azure Portal mediante Azure Backup. Lo único que debe hacer es elegir el punto de restauración (una instantánea concreta), el archivo o directorio en cuestión si es pertinente y, a continuación, la ubicación (original o alternativa) en la que quiere realizar la restauración. 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 de inteligencia de seguridad nativa de Azure que detecta posibles amenazas a sus 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 capacidades avanzadas de detección de amenazas con tecnología de Inteligencia contra amenazas Microsoft para proporcionar alertas de seguridad contextuales, incluidos los pasos para mitigar las amenazas detectadas y evitar futuros ataques.

Defender para 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 for Cloud 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 un hash de archivo completo (solo se admite para la API de 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 Storage en el nivel de suscripción (recomendado) o de recursos.

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.

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 operaciones de escritura 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.

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

Disponibilidad de archivos compartidos SSD redundantes por zona

Los recursos compartidos de archivos SSD con redundancia de zona están disponibles para un subconjunto de regiones de Azure.

Recuperación ante desastres y conmutación por error

En el caso de una interrupción de 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 procesos relacionados con la recuperación ante desastres y la conmutación por error de la cuenta de almacenamiento, 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 para su organización, sino que migrará uno existente desde un servidor de archivos local o un dispositivo NAS a Azure Files. La elección de la herramienta y estrategia de migración adecuadas para el escenario es importante para el éxito de la migración.

En el artículo de introducción a la migración se describen brevemente los aspectos básicos y se incluye una tabla que le conduce a guías de migración que probablemente cubran su escenario.

Pasos siguientes

• Planeamiento de una implementación de Azure File Sync
• Implementación de Azure Files
• Implementación de Azure File Sync
• Consulte el artículo de introducción a la migración para encontrar la guía de migración para su escenario.