Recursos compartidos de archivos de Azure mediante NFS
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 el acceso a un recurso compartido de archivos de Azure individual con los protocolos SMB y NFS, aunque se pueden crear recursos compartidos de archivos SMB y NFS dentro de la misma cuenta de almacenamiento de FileStorage. 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.
En este artículo se describen los recursos compartidos de archivos NFS de Azure. Para obtener información acerca de los recursos compartidos de archivos SMB de Azure, consulte Recursos compartidos de archivos SMB en Azure Files.
Importante
Los recursos compartidos de archivos NFS de Azure no se admiten para Windows. Antes de usar recursos compartidos de archivos de NFS de Azure en producción, consulte Solución de problemas de recursos compartidos de archivos de NFS de Azure para ver una lista de problemas conocidos. No se admiten las listas de control de acceso (ACL) de NFS.
Escenarios frecuentes
Los recursos compartidos de archivos NFS se suelen usar en los escenarios siguientes:
- Almacenamiento de respaldo para aplicaciones basadas en Linux o UNIX, como aplicaciones de línea de negocio escritas con API del sistema de archivos Linux o POSIX (incluso aunque no requieran compatibilidad con POSIX).
- Cargas de trabajo que requieren recursos compartidos de archivos compatibles con POSIX, distinción entre mayúsculas y minúsculas o permisos de estilo Unix (UID/GID).
- Desarrollo de aplicaciones y servicios nuevos, sobre todo si esa aplicación o servicio tiene como requisito una E/S aleatoria y almacenamiento jerárquico.
Características
- Sistema de archivos totalmente compatible con POSIX.
- Compatibilidad con vínculos físicos.
- Compatibilidad con vínculos simbólicos.
- Actualmente, los recursos compartidos de archivos NFS solo admiten la mayoría de las características de la especificación del protocolo 4.1. No se admiten algunas características, como delegaciones y devoluciones de llamada de todo tipo, listas de control de acceso, la autenticación Kerberos y el cifrado en tránsito.
Nota
Actualmente no se admite la creación de un vínculo físico a partir de un vínculo simbólico existente.
Seguridad y redes
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.
En el caso del cifrado en tránsito, Azure proporciona una capa de cifrado para todos los datos en tránsito entre los centros de datos de Azure mediante MACSec. Gracias a esto, se produce el cifrado cuando se transfieren datos entre centros de datos de Azure.
A diferencia de Azure Files cuando usa el protocolo SMB, los recursos compartidos de archivos que utilizan el protocolo NFS no ofrecen autenticación basada en usuario. La autenticación de los recursos compartidos NFS se basa en las reglas de seguridad de red configuradas. Debido a esto, para garantizar que solo se establecen conexiones seguras a su recurso compartido NFS, debe configurar un punto de conexión privado o un punto de conexión de servicio para su cuenta de almacenamiento.
Un punto de conexión privado (también denominado vínculo privado) proporciona a la cuenta de almacenamiento una dirección IP privada estática dentro de la red virtual, lo que impide que las interrupciones de conectividad cambien de dirección IP dinámica. El tráfico a la cuenta de almacenamiento se mantiene dentro de las redes virtuales interconectadas, incluidas las de otras regiones y las locales. Se aplican las tarifas de procesamiento de datos estándar.
Si no necesita una dirección IP estática, puede habilitar un punto de conexión de servicio para Azure Files dentro de la red virtual. Un punto de conexión de servicio configura las cuentas de almacenamiento para permitir el acceso solo desde subredes específicas. Las subredes permitidas pueden pertenecer a una red virtual de la misma suscripción o una suscripción diferente, incluidas las que pertenecen a un inquilino de Microsoft Entra diferente. No se realiza ningún cargo adicional por el uso de puntos de conexión de servicio. Sin embargo, tenga en cuenta que 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.
Si desea acceder a recursos compartidos desde un entorno local, debe configurar una VPN o ExpressRoute, además de un punto de conexión privado. Las solicitudes que no tengan los siguientes orígenes se rechazarán:
- Un punto de conexión privado
- Azure VPN Gateway
- ExpressRoute
- Un punto de conexión público restringido
Para más información sobre las opciones de red disponibles, consulte Consideraciones de redes para Azure Files.
Compatibilidad con las características de Azure Storage
En la tabla siguiente, se muestra el nivel actual de compatibilidad con características de Azure Storage en las cuentas que tienen habilitada la característica NFS 4.1.
El estado de los elementos que aparecen en esta tabla puede cambiar con el tiempo a medida que se siga ampliando la compatibilidad.
Disponibilidad regional
Los recursos compartidos de archivos Azure NFS se admiten en las mismas regiones que admiten el almacenamiento de archivos Prémium. Consulte Productos de Azure disponibles por región.
Rendimiento
Los recursos compartidos de archivos de Azure NFS solo se ofrecen en recursos compartidos de archivos premium, que almacenan datos en unidades de estado sólido (SSD). Las IOPS y el rendimiento de los recursos compartidos de NFS se escalan con la capacidad aprovisionada. Consulte la sección modelo v1 aprovisionado del artículo Reconocimiento de la facturación para comprender las fórmulas de IOPS, expansión de E/S y rendimiento. Las latencias de E/S promedio son de un número bajo de milisegundos inferior a 10 para los tamaños de E/S pequeños, mientras que las latencias de metadatos promedio son de un número alto de milisegundos inferior a 10. Las operaciones de metadatos de carga elevada, como la descompresión y las cargas de trabajo como WordPress, pueden tener latencias adicionales debido al gran número de operaciones de apertura y cierre.
Nota:
Puede usar la opción de montaje de Linux nconnect para mejorar el rendimiento de los recursos compartidos de archivos de Azure NFS a escala. Para más información, consulte Mejora del rendimiento del recurso compartido de archivos NFS de Azure.
Cargas de trabajo
Importante
Antes de usar recursos compartidos de archivos de NFS de Azure en producción, consulte Solución de problemas de recursos compartidos de archivos de NFS de Azure para ver una lista de problemas conocidos.
NFS se ha validado para funcionar bien con cargas de trabajo como el nivel de aplicación de SAP, copias de seguridad de bases de datos, replicación de bases de datos, colas de mensajería, directorios particulares para servidores de archivos de uso general y repositorios de contenido para cargas de trabajo de aplicaciones.