Planeamiento de una implementación de Azure Files

Azure Files se puede implementar de dos formas principales: montando directamente los recursos compartidos de archivos de Azure sin servidor o almacenando en caché recursos compartidos de archivos de Azure localmente mediante Azure File Sync. La opción de implementación que elija cambiará todo aquello que debe tener en cuenta a la hora de planear la implementación.

  • 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.

  • Almacenamiento en caché de recursos compartidos de archivos de Azure localmente con Azure File Sync: Azure File Sync le permite centralizar los recursos compartidos de archivos de su organización en Azure Files sin renunciar a 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 de su 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.

Protocolos disponibles

Azure Files ofrece dos protocolos que se pueden usar al montar recursos compartidos de archivos, SMB y Network File System (NFS). Para más información sobre estos protocolos, consulte Protocolos de recurso compartido de archivos de Azure.

Importante

La mayor parte del contenido de este artículo solo se aplica a los recursos compartidos SMB. Cualquier cosa que se aplique a los recursos compartidos NFS indicará que es aplicable.

Conceptos de administración

Los recursos compartidos de archivos de Azure se implementan en cuentas de almacenamiento, que son objetos de nivel superior que representan un grupo compartido de almacenamiento. Este grupo de almacenamiento se puede usar para implementar varios recursos compartidos de archivos, así como otros recursos de almacenamiento, tales como contenedores de blobs, colas o tablas. 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. Para ver los límites actuales de una cuenta de almacenamiento, consulte Objetivos de escalabilidad y rendimiento de Azure Files.

Hay dos tipos principales de cuentas de almacenamiento que se usarán para las implementaciones de Azure Files:

  • Cuentas de almacenamiento de uso general, versión 2 (GPv2) : Las cuentas de almacenamiento de GPv2 permiten implementar recursos compartidos de archivos de Azure en hardware estándar o basado en disco duro (HDD). Además de almacenar recursos compartidos de archivos de Azure, las cuentas de almacenamiento de GPv2 pueden almacenar otros recursos de almacenamiento, como contenedores de blobs, colas o tablas.
  • Cuentas de almacenamiento FileStorage: Las cuentas de almacenamiento FileStorage permiten implementar recursos compartidos de archivos de Azure en hardware prémium o basado en unidades de estado sólido (SSD). Las cuentas FileStorage solo se pueden usar para almacenar recursos compartidos de archivos de Azure. No se puede implementar ningún otro recurso de almacenamiento (contenedores de blobs, colas, tablas, etc.) en una cuenta FileStorage. Solo las cuentas de FileStorage pueden implementar recursos compartidos de archivos SMB y NFS.

Existen otros tipos de cuenta de almacenamiento que puede encontrar en el Azure Portal, PowerShell o la CLI. Dos tipos de cuentas de almacenamiento, BlockBlobStorage y BlobStorage, no pueden contener recursos compartidos de archivos de Azure. Los otros dos tipos de cuenta de almacenamiento que puede ver son las cuentas de almacenamiento clásico y de uso general de la versión 1 (GPv1), y ambas pueden contener recursos compartidos de archivos de Azure. Aunque las cuentas de almacenamiento clásico y de GPv1 pueden contener recursos compartidos de archivos de Azure, la mayoría de las nuevas características de Azure Files solo están disponibles en las cuentas de almacenamiento de GPv2 y FileStorage. Por lo tanto, se recomienda usar solo las cuentas de almacenamiento de GPv2 y FileStorage para las nuevas implementaciones, así como actualizar las cuentas de almacenamiento de GPv1 y clásico si ya existen en su entorno.

Al implementar recursos compartidos de archivos de Azure en cuentas de almacenamiento, se recomienda:

  • Implementar solo recursos compartidos de archivos de Azure en cuentas de almacenamiento con otros recursos compartidos de archivos de Azure. Aunque las cuentas de almacenamiento de GPv2 permiten tener cuentas de almacenamiento de propósito combinado, dado que los recursos de almacenamiento como los recursos compartidos de archivos de Azure y los contenedores de blobs comparten los límites de la cuenta de almacenamiento, la combinación de recursos puede dificultar la solución de problemas de rendimiento más adelante.

  • Prestar atención a las limitaciones de IOPS de la cuenta de almacenamiento al implementar recursos compartidos de archivos de Azure. Lo ideal sería asignar recursos compartidos de archivos 1:1 a cuentas de almacenamiento; sin embargo, quizás no sea posible debido a diversos límites y restricciones, tanto de su organización como de Azure. Cuando no sea posible tener un solo recurso compartido de archivos implementado en una cuenta de almacenamiento, tenga en cuenta qué recursos compartidos estarán muy activos y cuales estarán menos activos, con el fin de asegurarse de que los recursos compartidos de archivos más activos no se colocan en la misma cuenta de almacenamiento.

  • Implementar solamente cuentas de GPv2 y FileStorage, y actualizar las cuentas de almacenamiento clásicas y de GPv1 cuando las encuentre en su entorno.

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 se integra con tres proveedores de identidades principales:

  • Active Directory Domain Services (AD DS) local (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.
  • Azure Active Directory Domain Services (Azure AD DS) : Azure AD DS 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 Azure AD DS proporciona ventajas similares a la unión a un dominio de dicha cuenta a una instancia de Active Directory 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 Azure AD DS proporciona autenticación basada en AD, esta opción también usa el protocolo de autenticación Kerberos.
  • Clave de la cuenta de Azure Storage: los recursos compartidos de archivos de Azure también se pueden montar con una clave de cuenta de almacenamiento de Azure. Para montar un recurso compartido de archivos de esta forma, 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 la cuenta de almacenamiento para montar el recurso compartido de archivos de Azure es realmente una operación de administrador, ya que el recurso compartido de archivos montado tendrá permisos completos para todos los archivos y todas las carpetas del recurso compartido, aunque tengan 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 el caso de los clientes que realizan la migración desde servidores de archivos locales o que crean nuevos recursos compartidos de archivos en Azure Files destinados a comportarse como servidores de archivos de Windows o dispositivos NAS, la unión a un dominio de la cuenta de almacenamiento a Active Directory propiedad del cliente es la opción recomendada. Para más información acerca de la unión a un dominio de la cuenta de almacenamiento a una instancia de Active Directory propiedad del cliente, consulte la introducción a Active Directory de Azure Files.

Si tiene previsto usar la clave de la cuenta de almacenamiento para acceder a los recursos compartidos de archivos de Azure, se recomienda usar puntos de conexión de servicio como se describe en la sección Redes.

Redes

Los recursos compartidos de archivos de Azure son accesibles desde cualquier lugar a través del punto de conexión público de la cuenta de almacenamiento. Esto significa que las solicitudes autenticadas, como las solicitudes autorizadas por la identidad de inicio de sesión de un usuario, pueden originarse de forma segura dentro o fuera de Azure. En muchos entornos de cliente, se producirá un error en el montaje inicial del recurso compartido de archivos de Azure en la estación de trabajo local, aunque los montajes desde las máquinas virtuales de Azure se realicen correctamente. El motivo es que muchas organizaciones y proveedores de servicios de Internet (ISP) bloquean el puerto que usa SMB para comunicarse, el puerto 445. Para ver el resumen de los ISP que permiten o deniegan el acceso desde el puerto 445, visite TechNet.

Para desbloquear el acceso al recurso compartido de archivos de Azure, tiene dos opciones principales:

  • Desbloquear el puerto 445 para la red local de su organización. Solo se puede acceder externamente a recursos compartidos de archivos de Azure a través del punto de conexión público mediante protocolos seguros para Internet, como SMB 3.0 y la API de FileREST. Esta es la manera más fácil de acceder al recurso compartido de archivos de Azure desde el entorno local, ya que no requiere una configuración de red avanzada más allá de cambiar las reglas de puerto de salida de la organización. Sin embargo, se recomienda quitar las versiones heredadas y en desuso del protocolo SMB, concretamente SMB 1.0. Para obtener información sobre cómo hacerlo, consulte Protección de Windows y Windows Server y Protección de Linux.

  • Acceder a recursos compartidos de archivos de Azure a través de una conexión de ExpressRoute o VPN. Al acceder al recurso compartido de archivos de Azure a través de un túnel de red, puede montar el recurso compartido de archivos de Azure como un recurso compartido de archivos local, ya que el tráfico SMB no atraviesa el límite de la organización.

Aunque desde una perspectiva técnica es considerablemente más fácil montar los recursos compartidos de archivos de Azure a través del punto de conexión público, esperamos que la mayoría de los clientes opten por montar sus recursos compartidos de archivos de Azure a través de una conexión de ExpressRoute o VPN. El montaje con estas opciones es posible con ambos recursos compartidos, SMB y NFS. Para ello, deberá configurar las opciones siguientes para su entorno:

  • Tunelización de red mediante ExpressRoute o una VPN de sitio a sitio o de punto a sitio: la tunelización en una red virtual permite acceder a recursos compartidos de archivos de Azure desde el entorno local, aunque el puerto 445 esté bloqueado.
  • Puntos de conexión privados: los puntos de conexión privados proporcionan a su cuenta de almacenamiento una dirección IP dedicada desde el espacio de direcciones de la red virtual. Esto permite la tunelización de red sin necesidad de abrir redes locales en todos los intervalos de direcciones IP que son propiedad de los clústeres de almacenamiento de Azure.
  • Reenvío DNS: configure su DNS local para resolver el nombre de la cuenta de almacenamiento (storageaccount.file.core.windows.net para las regiones de la nube pública) para resolver la dirección IP de sus puntos de conexión privados.

Para planear las redes asociadas a la implementación de un recurso compartido de archivos de Azure, consulte Consideraciones de redes para Azure Files.

Cifrado

Azure Files admite dos tipos de cifrado diferentes: el cifrado en tránsito, que se relaciona con el cifrado que se usa al montar el recurso compartido de archivos de Azure y acceder a este, y el cifrado en reposo, relacionado con la forma en que se cifran los datos cuando se almacenan en el disco.

Cifrado en tránsito

Importante

En esta sección se tratan los detalles del cifrado en tránsito para recursos compartidos SMB. Para más información sobre el cifrado en tránsito con recursos compartidos NFS, consulte Seguridad.

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 de FileREST (por ejemplo, a través de Azure Portal, la CLI o PowerShell, o los SDK de Azure), Azure Files solo permitirá la conexión si se realiza con una versión posterior a SMB 3.0 con cifrado o HTTPS. Los clientes que no admiten SMB 3.0, o los clientes que admiten SMB 3.0, pero no al 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.0 con cifrado, consulte nuestra documentación detallada 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 el uso de SMB 2.1, SMB 3.0 sin cifrado y las llamadas a la API de 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 obtener más información sobre el cifrado en tránsito, consulte Requerir transferencia segura en Azure Storage.

Cifrado en reposo

Todos los datos almacenados en Azure Files se cifran en reposo mediante el cifrado de servicio de almacenamiento (SSE) de Azure. El cifrado del servicio de almacenamiento funciona de forma similar a BitLocker en Windows: los datos se cifran bajo el nivel del sistema de archivos. Dado que los datos se cifran bajo el sistema de archivos del recurso compartido de archivos de Azure, ya que se codifican en el disco, no es necesario tener acceso a la clave subyacente en el cliente para leer o escribir en dicho recurso compartido. 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 mantiene las claves para cifrar o descifrar los datos y es responsable de rotarlas de forma periódica. 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 esto significa que el recurso compartido de archivos de Azure ya no será accesible a través de SMB o la API FileREST.

Azure Files usa el mismo esquema de cifrado que los otros servicios de almacenamiento de Azure, como Azure Blob Storage. Para aprender más sobre el cifrado del servicio de almacenamiento (SSE) de Azure, 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.

Eliminación temporal

La eliminación temporal de recursos compartidos de archivos (versión preliminar) es una configuración de nivel de cuenta de almacenamiento que le permite recuperar el recurso compartido de archivos cuando 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 datos eliminados de forma temporal se pueden recuperar antes de que se eliminen permanentemente y durante este período de retención el recurso compartido se puede recuperar en cualquier momento.

Se recomienda activar la eliminación temporal para la mayoría de los recursos compartidos de archivos. Si tiene un flujo de trabajo en el que la eliminación de recursos compartidos es común y se espera, puede que decida tener un período de retención corto o no tener habilitada la eliminación temporal.

Para obtener más información acerca de la eliminación temporal, 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 estas 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. Las instantáneas se almacenan en el recurso compartido de archivos, lo que significa que si lo elimina, también se eliminarán las instantáneas. Para proteger las copias de seguridad de instantáneas contra eliminaciones accidentales, asegúrese de que la eliminación temporal está habilitada para el recurso compartido.

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.

Para obtener más información sobre Azure Backup, vea Acerca de la copia de seguridad de recursos compartidos de archivos de Azure.

Azure Defender para Azure Files

Azure Defender para Azure Storage (antes Protección contra amenazas avanzada para Azure Storage) ofrece una capa adicional de inteligencia de seguridad que proporciona alertas cuando detecta actividades anómalas en la cuenta de almacenamiento; por ejemplo, intentos no habituales de acceso. También ejecuta análisis de reputación de hash de malware y generará una alerta sobre malware conocido. Puede configurar Azure Defender en un nivel de suscripción o de cuenta de almacenamiento a través de Azure Security Center.

Para más información, consulte Introducción a Azure Defender para Storage.

Niveles de almacenamiento

Azure Files ofrece cuatro niveles diferentes de almacenamiento: Premium, Optimizado para transacciones, Frecuente y Esporádico, con el fin de que pueda adaptar sus recursos compartidos a los requisitos de rendimiento y precio de su escenario:

  • Premium: Los recursos compartidos de archivos Premium tienen el respaldo de discos SSD y proporcionan alto rendimiento y baja latencia de forma consistente en menos de 10 milisegundos en la mayoría de las operaciones de E/S para las cargas de trabajo con mayor uso de E/S. Los recursos compartidos de archivos Premium son adecuados para una amplia variedad de cargas de trabajo como bases de datos, hospedaje de sitios web y entornos de desarrollo. Los recursos compartidos de archivos Premium se pueden usar con los protocolos Bloque de mensajes del servidor (SMB) y Network File System (NFS).
  • Optimizado para transacciones: Los recursos compartidos de archivos con el nivel Optimizado para transacciones permiten cargas de trabajo con muchas transacciones que no necesitan la latencia que ofrecen los recursos compartidos de archivos Premium. Los recursos compartidos de archivos optimizados para transacciones se ofrecen en el hardware de almacenamiento estándar respaldado por unidades de disco duro (HDD). A los optimizados para transacciones se les ha llamado históricamente "estándar"; sin embargo, realmente es el tipo de soporte físico de almacenamiento, en lugar del propio nivel (tanto el acceso frecuente como el esporádico también son niveles "estándar", ya que se encuentran en el hardware de almacenamiento estándar).
  • Acceso frecuente: Los recursos compartidos de nivel de acceso frecuente ofrecen almacenamiento optimizado para escenarios de uso compartido de archivos de uso general, como los recursos compartidos de los equipos. Los recursos compartidos de archivos de nivel de acceso frecuente se ofrecen en el hardware de almacenamiento estándar respaldado por unidades de disco duro.
  • Acceso esporádico: Los recursos compartidos de archivos de acceso esporádico ofrecen un almacenamiento económico optimizado para escenarios de almacenamiento de archivo en línea. Los recursos compartidos de archivos de nivel de acceso esporádico se ofrecen en el hardware de almacenamiento estándar respaldado por unidades de disco duro.

Los recursos compartidos de archivos Premium se implementan en la cuenta de almacenamiento de FileStorage y solo están disponibles en un modelo de facturación aprovisionado. Para más información sobre el modelo de facturación aprovisionado para recursos compartidos de archivos Premium, consulte Planeamiento de una implementación de Azure Files. Los recursos compartidos de archivos estándar, que incluyen los optimizados para las transacciones, los de nivel de acceso frecuente y los de nivel de acceso esporádico, se implementan en la cuenta de almacenamiento de uso general, versión 2 (GPv2) y están disponibles en un modelo de pago por uso.

Al seleccionar una capa de almacenamiento para la carga de trabajo, tenga en cuenta los requisitos de rendimiento y uso. Si la carga de trabajo requiere una latencia de un solo dígito o si usa medios de almacenamiento SSD en un entorno local, es probable que el nivel Premium sea el más adecuado. Si no es muy importante que la latencia sea baja, por ejemplo, en el caso de recursos compartidos de equipo montados localmente desde Azure o almacenados en la caché local mediante Azure File Sync, desde el punto de vista del costo es posible que sea más adecuado usar el almacenamiento estándar.

Una vez que se haya creado un recurso compartido de archivos en una cuenta de almacenamiento, no se podrá mover a niveles exclusivos de diferentes tipos de cuenta de almacenamiento. Por ejemplo, para cambiar un recurso compartido de archivos optimizado para transacciones al nivel Premium, es preciso crear un recurso compartido de archivos en una cuenta de almacenamiento de FileStorage y copiar los datos desde el recurso compartido original a un nuevo recurso compartido de archivos en la cuenta de FileStorage. Se recomienda usar AzCopy para copiar datos entre recursos compartidos de archivos de Azure, pero también se pueden usar herramientas como robocopy en Windows o rsync en macOS y Linux.

Los recursos compartidos de archivos implementados en cuentas de almacenamiento GPv2 se pueden mover entre los niveles estándar (transacción optimizada, de acceso frecuente y de acceso esporádico) sin crear ninguna cuenta de almacenamiento y migrar los datos, pero será preciso abonar los costos de transacción al cambiar el nivel. Si un recurso compartido se pasa de un nivel de acceso frecuente a un nivel esporádico, incurrirá en la carga de transacciones de escritura del nivel más esporádico en cada archivo del recurso compartido. Por contra, si un recurso compartido se pasa de un nivel de acceso esporádico a un nivel frecuente, incurrirá en la carga de transacciones de lectura del nivel más esporádico en cada archivo del recurso compartido.

Para más información, consulte Facturación de Azure Files.

Habilitación de recursos compartidos de archivos para incluir hasta 100 TiB

De forma predeterminada, los recursos compartidos de archivos estándar solo pueden abarcar hasta 5 TiB, pero puede aumentar el límite de recursos compartidos a 100 TiB. Para obtener información sobre cómo aumentar el límite de recursos compartidos, consulte Habilitación y creación de recursos compartidos de archivos grandes.

Limitaciones

Los recursos compartidos de archivos Estándar con 100 TiB de capacidad tienen algunas limitaciones.

  • Actualmente, solo se admiten cuentas de almacenamiento con redundancia local (LRS) y almacenamiento con redundancia de zona (ZRS).
  • Una vez que habilite los recursos compartidos de archivos de gran tamaño, no podrá convertir las cuentas de almacenamiento en cuentas de almacenamiento con redundancia geográfica (GRS) o con redundancia de zona geográfica (GZRS).
  • Una vez que habilite los recursos compartidos de archivos de gran tamaño, no podrá deshabilitarlos.

Redundancia

Para proteger los datos de los recursos compartidos de archivos de Azure contra la pérdida o daños de los datos, todos los recursos compartidos de los archivos de Azure almacenan varias copias de cada archivo a medida que se escriben. En función de los requisitos de la carga de trabajo, puede seleccionar niveles adicionales de redundancia. Actualmente, Azure Files admite las siguientes opciones de redundancia de datos:

  • Redundancia local El almacenamiento con redundancia local, que a menudo se denomina LRS, significa que todos los archivos se almacenan tres veces dentro de un clúster de almacenamiento de Azure. Esto protege contra la pérdida de datos debido a errores de hardware, como una unidad de disco incorrecta.
  • Redundancia de zona El almacenamiento con redundancia de zona, que a menudo se conoce como ZRS, significa que cada archivo se almacena tres veces en tres clústeres de almacenamiento de Azure distintos. Al igual que con el almacenamiento con redundancia local, la redundancia de zona ofrece tres copias de cada archivo, sin embargo, estas copias están aisladas físicamente en tres clústeres de almacenamiento distintos en distintas zonas de disponibilidad de Azure. Las zonas de disponibilidad son ubicaciones físicas exclusivas dentro de 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 la escritura en el almacenamiento hasta que se escribe en los clústeres de almacenamiento en las tres zonas de disponibilidad.
  • Redundancia geográfica El almacenamiento con redundancia geográfica, que a menudo se conoce como GRS, es como el almacenamiento con redundancia local, en el que un archivo se almacena tres veces dentro de un clúster de almacenamiento de Azure en la región primaria. Todas las escrituras se replican de forma asincrónica en una región secundaria definida por Microsoft. El almacenamiento con redundancia geográfica proporciona seis copias de los datos distribuidos entre dos regiones de Azure. En caso de que se produzca un desastre importante, como la pérdida permanente de una región de Azure debido a un desastre natural o a otro evento similar, Microsoft realizará una conmutación por error para que el servidor secundario en vigor se convierta en el servidor principal, atendiendo a todas las operaciones. Dado que la replicación entre las regiones principal y secundaria es asincrónica, en caso de que se produzca un desastre importante, se perderán los datos que todavía no se hayan 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.
  • Redundancia de zona geográfica El almacenamiento con redundancia de zona geográfica, que a menudo se conoce como GZRS, es como el almacenamiento con redundancia de zona, en el que un archivo se almacena tres veces en tres clústeres de almacenamiento distintos en 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 el almacenamiento con redundancia de zona geográfica funciona igual que para el almacenamiento con redundancia geográfica.

Los recursos compartidos de archivos de Azure estándar admiten los cuatro tipos de redundancia, mientras que los recursos compartidos de archivos Premium de Azure solo admiten almacenamiento con redundancia local y redundancia de zona

Las cuentas de almacenamiento de uso general versión 2 (GPv2) proporcionan dos opciones de redundancia adicionales que no son compatibles con Azure Files: almacenamiento con redundancia geográfica con acceso de lectura, que a menudo se conoce como RA-GRS, y almacenamiento con redundancia de zona geográfica accesible. se conoce como RA-GZRS. Puede aprovisionar 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 redundancia geográfica o con redundancia de zona geográfica con acceso de lectura se facturarán como almacenamiento con redundancia geográfica o con redundancia de zona geográfica, respectivamente.

Migración

En muchos casos, no se establecerá un nuevo recurso compartido de archivos para su organización, sino que se migrará uno existente de 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