Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Se aplica a: ✔️ recursos compartidos de archivos NFS creados con Microsoft.Storage o Microsoft.FileShares
Azure Files admite dos protocolos estándar del sector para montar recursos compartidos de archivos: 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 el acceso a un recurso compartido de archivos de Azure individual mediante los protocolos SMB y NFS. Para los recursos compartidos de archivos clásicos, puedes crear recursos compartidos de archivos SMB y NFS separados dentro de la misma cuenta de almacenamiento de FileStorage. Microsoft.FileShares actualmente solo soporta recursos compartidos de archivos 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 miles de clientes pueden acceder simultáneamente.
En este artículo se tratan los recursos compartidos de archivos Azure NFS. Para obtener información sobre 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 son compatibles con Windows. Antes de usar los recursos compartidos de archivos NFS de Azure en producción, consulte Solucionar problemas de los recursos compartidos de archivos NFS de Azure para obtener una lista de problemas conocidos. No se admiten las listas de control de acceso (ACL) de NFS.
Casos de uso comunes para recursos compartidos de archivos de Azure NFS
Los recursos compartidos de archivos NFS funcionan bien con cargas de trabajo como la capa de aplicación de SAP, las copias de seguridad de bases de datos, la replicación de bases de datos, las colas de mensajería, los directorios personales para servidores de archivos de uso general y los repositorios de contenido para cargas de trabajo de aplicaciones.
Los recursos compartidos de archivos NFS se suelen usar en los escenarios siguientes:
- Almacenamiento de respaldo para aplicaciones para Linux/UNIX, como aplicaciones de línea de negocio desarrolladas con las API del sistema de archivos de Linux o 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)
- Nuevo desarrollo de aplicaciones y servicios que requiere E/S aleatoria y almacenamiento jerárquico
Características del recurso compartido de archivos Azure NFS
Los recursos compartidos de archivos Azure NFS ofrecen un sistema de archivos totalmente compatible con POSIX. Se admiten vínculos físicos y vínculos simbólicos, pero no se puede crear un vínculo físico a partir de un vínculo simbólico existente.
Los recursos compartidos de archivos Azure NFS admiten actualmente la mayoría de las características de la especificación del protocolo NFSv4.1. Algunas características como delegaciones y devolución de llamada de todo tipo, autenticación Kerberos y ACL no se admiten.
El almacenamiento con redundancia local (LRS) y el almacenamiento con redundancia de zona (ZRS) se admiten para los recursos compartidos de archivos Azure NFS. El almacenamiento con redundancia geográfica (GRS) y el almacenamiento con redundancia de zona geográfica (GZRS) no están disponibles para los recursos compartidos NFS porque NFS requiere almacenamiento SSD, que no admite redundancia geográfica.
Soporte de recursos compartidos de archivos NFS de Azure para las características de Azure Files
En la tabla siguiente se muestra el nivel actual de compatibilidad de características con los recursos compartidos de archivos Azure NFS. Salvo que se indique lo contrario, el soporte se aplica tanto a los recursos compartidos de archivos clásicos (Microsoft.Storage) como a los recursos compartidos de archivos creados con Microsoft.FileShares.
El estado de los elementos que aparecen en esta tabla puede cambiar con el tiempo a medida que se siga ampliando la compatibilidad.
| Característica de Azure Storage | Compatible con recursos compartidos NFS |
|---|---|
| API REST de la capa de gestión de archivos | ✔️ Microsoft.Storage y Microsoft.FileShares |
| API REST del plano de datos de archivos | ✔️ Solo recursos compartidos de archivos clásicos |
| Cifrado en reposo | ✔️ |
| Cifrado en tránsito | ✔️ |
| Tipos de redundancia LRS o ZRS | ✔️ |
| Conversión de LRS a ZRS o viceversa (solo en puntos finales privados) | ✔️ Solo recursos compartidos de archivos clásicos |
| Tipos de redundancia GRS o GZRS | ⛔ |
| Puntos de conexión de la zona de Azure DNS (versión preliminar) | ✔️ Solo recursos compartidos de archivos clásicos |
| Puntos de conexión privados | ✔️ |
| Montajes de subdirectorios | ✔️ |
| Otorgar acceso de red a redes virtuales específicas de Azure | ✔️ |
| Concesión de acceso a determinadas direcciones IP | ⛔ |
| Nivel de medios SSD | ✔️ |
| Nivel multimedia de HDD | ⛔ |
| Permisos POSIX | ✔️ |
| Uso de root_squash | ✔️ |
| Acceso a los mismos datos desde el cliente de Windows y Linux | ⛔ |
| Autenticación basada en identidad | ⛔ |
| Eliminación temporal de recursos compartidos de archivos de Azure | ✔️ Solo recursos compartidos de archivos clásicos |
| Azure File Sync | ⛔ |
| Copias de seguridad de compartición de archivos de Azure | ⛔ |
| Instantáneas de recursos compartidos de archivos de Azure | ✔️ |
| AzCopy | ✔️ Solo recursos compartidos de archivos clásicos |
| Explorador de Azure Storage | ✔️ Solo recursos compartidos de archivos clásicos |
| Azure Storage Browser en Azure portal | ⛔ |
| Compatibilidad con más de 16 grupos | ⛔ |
Nota
El límite de 16 grupos es una restricción del protocolo NFS. Cada usuario está limitado a 16 identificadores de grupo (GID) por conexión.
Modelo de administración
Los recursos compartidos de archivos Azure NFS admiten dos proveedores de recursos de nivel superior:
- Microsoft. FileShares (recomendado para nuevas implementaciones nfS): crea un recurso compartido de archivos independiente sin una cuenta de almacenamiento. Solo admite el modelo de facturación v2 aprovisionado.
- Microsoft. Storage (clásico): crea recursos compartidos de archivos clásicos dentro de una cuenta de almacenamiento. Soporta modelos de facturación provisionados v1 y v2 para comparticiones NFS.
Para obtener una comparación completa de características, consulte Comparación de proveedores de recursos: Microsoft. Almacenamiento frente a Microsoft. FileShares.
Seguridad y redes para recursos compartidos de archivos de Azure NFS
Los recursos compartidos de archivos NFS de Azure protegen los datos mediante cifrado en reposo y en tránsito, y requieren controles de acceso a nivel de red en lugar de la autenticación basada en usuarios.
Encryption
Azure Files cifra todos los datos en reposo mediante el cifrado del servicio de almacenamiento de Azure (SSE). El cifrado del servicio de almacenamiento funciona de forma similar a BitLocker en Windows: cifra los datos debajo del nivel del sistema de archivos. Dado que el cifrado se produce debajo del sistema de archivos del recurso compartido de archivos Azure a medida que los datos se codifican 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 Azure. El cifrado en reposo se aplica a los protocolos SMB y NFS.
Tanto los recursos compartidos de archivos clásicos como los recursos compartidos de archivos de Microsoft.FileShares soportan cifrado TLS en tránsito a través del asistente de montaje AZNFS. Configuras los requisitos de cifrado en diferentes ámbitos:
- Microsoft. FileShares: El cifrado en tránsito es obligatorio por defecto. Este requisito se configura en cada recurso compartido de archivos individual. Consulta Configuración avanzada al crear un recurso compartido de archivos.
- Recursos compartidos de archivos clásicos: Configure Requerir cifrado en tránsito para NFS en la cuenta de almacenamiento. Para las nuevas cuentas de almacenamiento creadas a través del portal de Azure, esta configuración está activada por defecto. Cuando la opción es No seleccionado, Se requiere transferencia segura gobierna el comportamiento del cifrado en NFS. Para conocer los valores predeterminados de creación y los pasos de configuración, consulta Aplicar cifrado en tránsito.
Azure proporciona una capa de cifrado para todos los datos en tránsito entre Azure centros de datos mediante MACSec. A través de esta tecnología, el cifrado existe cuando los datos se transfieren entre Azure centros de datos.
Autenticación y acceso a la red
Como los archivos compartidos de NFS en Azure no soportan autenticación basada en usuarios, dependen de reglas de acceso a la red para autenticar a los clientes. Por tanto, los clientes deben conectarse a través de un punto final privado o un punto de conexión de servicio con restricciones de red virtual.
Tanto los recursos compartidos de archivos clásicos como los recursos compartidos de archivos Microsoft.FileShares admiten estas opciones de conexión. Para los recursos compartidos de archivos clásicos, configuras la red en la cuenta de almacenamiento. Para Microsoft.FileShares, configuras la red en el recurso compartido de archivos individual.
Puntos de conexión privados
Un punto de conexión privado proporciona una dirección IP privada en tu red virtual para acceder al recurso compartido de archivos. Para permitir el acceso solo a través de puntos finales privados, desactiva el acceso a la red pública. Se aplican cargos por Private Link.
Los clientes pueden conectarse desde la red virtual o desde redes virtuales emparejadas. Para acceso en el entorno local, conecta tu red a la red virtual mediante una VPN o ExpressRoute.
Puntos de conexión del servicio
Un punto de conexión de servicio permite a los clientes en una subred acceder al punto de conexión público del recurso compartido de archivos a través de la red troncal de Azure. Activa el endpoint de servicio en la subred del cliente. Configura las reglas de red del recurso compartido de archivos para permitir esa subred. Las subredes permitidas pueden estar en la misma suscripción o en una suscripción diferente, incluyendo un tenant de Microsoft Entra diferente. No hay ningún cargo extra por los endpoints de servicio.
Un punto de conexión de servicio no asigna una dirección IP privada al recurso compartido de archivos. Si un evento raro, como una caída de zona, cambia la dirección IP del endpoint público, los clientes podrían necesitar volver a montar el share.
Filtrado saliente opcional
Las reglas de red del archivo compartido controlan qué clientes pueden acceder a él. No limitan a qué otros recursos de almacenamiento pueden acceder esos clientes. Por ejemplo, un cliente que pueda leer tu recurso compartido de archivos podría copiar datos a otro recurso en el que tenga permiso para escribir.
Para los recursos compartidos de archivos clásicos, opcionalmente puedes usar una política de endpoint de servicio para limitar a qué cuentas de almacenamiento los clientes de una subred pueden acceder a través de endpoints de servicio. El tráfico del punto de conexión de servicio omite Azure Firewall y los dispositivos virtuales de red. Una política filtra los destinos en esta ruta. No restringe otras rutas salientes ni reemplaza las reglas de red y los requisitos de autorización del destino.
Actualmente, las directivas de puntos de conexión de servicio no son compatibles con los recursos compartidos de archivos Microsoft.FileShares. Si la subred del cliente tiene una política, los clientes deben usar un punto de conexión privado para acceder a esos recursos compartidos de archivos. Para más información, consulte Restringir el acceso saliente con políticas de endpoint de servicio.
Para obtener más información sobre las opciones de red, consulte Azure Files consideraciones sobre redes.
Disponibilidad regional de los recursos compartidos de archivos NFS de Azure
La disponibilidad regional depende del proveedor de recursos y de la opción de redundancia:
- Microsoft.FileShares: Consulte las regiones LRS y las regiones ZRS.
- Compartición de archivos clásica: Ver regiones LRS y regiones ZRS.
Rendimiento del recurso compartido de archivos Azure NFS
Los recursos compartidos de archivos Azure NFS solo están disponibles en recursos compartidos de archivos SSD. Ambos proveedores de recursos soportan el modelo de facturación provisionada v2, que permite configurar la capacidad provisionada, IOPS y el rendimiento de forma independiente. Los recursos compartidos de archivos clásicos también soportan el modelo de facturación provisionada v1, en el que IOPS y el rendimiento escalan automáticamente con la capacidad aprovisionada. Para más información sobre ambos modelos, consulte Descripción de la facturación de Azure Files.
Las latencias típicas de E/S de los recursos compartidos de archivos SSD de Azure se sitúan en un intervalo bajo de milisegundos de un solo dígito para operaciones de E/S pequeñas. Las cargas de trabajo intensivas en metadatos, como untar, pueden experimentar latencias más altas debido al gran volumen de operaciones abiertas y cerradas.
Para obtener instrucciones sobre cómo mejorar el rendimiento de NFS a escala, consulte Mejorar el rendimiento del recurso compartido de archivos Azure NFS.