Partages de fichiers NFS Azure

S’applique à : ✔️ partages de fichiers NFS créés avec Microsoft.Storage ou Microsoft.FileShares

Azure Files prend en charge deux protocoles standard pour le montage de partages de fichiers : le protocole SMB (Server Message Block) et le protocole NFS (Network File System). Choisissez le protocole qui convient le mieux à votre charge de travail. Les partages de fichiers Azure ne prennent pas en charge l'accès à un partage de fichiers Azure individuel à l'aide des protocoles SMB et NFS. Pour les partages de fichiers classiques, vous pouvez créer des partages SMB et NFS séparés au sein du même compte de stockage FileStorage. Microsoft. FileShares ne prend actuellement en charge que les partages de fichiers NFS. Azure Files offre des partages de fichiers de qualité entreprise qui peuvent évoluer pour répondre à vos besoins de stockage et sont accessibles simultanément par des milliers de clients.

Cet article traite des partages de fichiers NFS Azure. Pour plus d’informations sur les partages de fichiers SMB Azure, consultez Partages de fichiers SMB dans Azure Files.

Important

Les partages de fichiers NFS Azure ne sont pas pris en charge pour Windows. Avant d’utiliser des partages de fichiers NFS Azure en production, consultez Troubleshoot NFS Azure partages de fichiers pour obtenir la liste des problèmes connus. Les listes de contrôle d’accès (ACL) NFS ne sont pas prises en charge.

Cas d’usage courants pour les partages de fichiers NFS Azure

Les partages de fichiers NFS fonctionnent bien avec des charges de travail telles que la couche application SAP, les sauvegardes de base de données, la réplication de base de données, les files d’attente de messagerie, les répertoires d’accueil pour les serveurs de fichiers à usage général et les référentiels de contenu pour les charges de travail d’application.

Les partages de fichiers NFS sont souvent utilisés dans les scénarios suivants :

  • Stockage principal pour les applications basées sur Linux/UNIX, telles que les applications métier développées à l’aide des API de système de fichiers Linux ou POSIX
  • Charges de travail nécessitant des partages de fichiers compatibles POSIX, la distinction entre majuscules et minuscules ou des autorisations de type Unix (UID/GID)
  • Nouveau développement d’applications et de services nécessitant des E/S aléatoires et un stockage hiérarchique

Fonctionnalités de partage de fichiers NFS Azure

Les partages de fichiers NFS Azure offrent un système de fichiers entièrement conforme à POSIX. Les liens durs et les liens symboliques sont pris en charge, mais vous ne pouvez pas créer de lien dur à partir d’un lien symbolique existant.

NFS Azure partages de fichiers prennent actuellement en charge la plupart des fonctionnalités de la spécification du protocole NFSv4.1. Certaines fonctionnalités telles que les délégations et les rappels de toutes sortes, l’authentification Kerberos et les listes ACL ne sont pas prises en charge.

Le stockage localement redondant (LRS) et le stockage redondant interzone (ZRS) sont pris en charge pour les partages de fichiers NFS Azure. Le stockage géoredondant (GRS) et le stockage géoredondant interzone (GZRS) ne sont pas disponibles pour les partages NFS, car NFS nécessite un stockage SSD, qui ne prend pas en charge la géoredondance.

Prise en charge du partage de fichiers NFS Azure pour les fonctionnalités d’Azure Files

Le tableau suivant montre le niveau actuel de prise en charge des fonctionnalités pour les partages de fichiers NFS Azure. Sauf indication contraire, le support s’applique à la fois aux partages de fichiers classiques (Microsoft.Storage) et aux partages de fichiers créés avec Microsoft.FileShares.

L’état des éléments figurant dans ce tableau peut évoluer au fil du temps, car la prise en charge continue de s’étendre.

Fonctionnalité Stockage Pris en charge pour les partages NFS
API REST du plan de contrôle de la gestion des fichiers ✔️ Microsoft.Storage et Microsoft.FileShares
API REST du plan de données de fichiers ✔️ Partages de fichiers classiques uniquement
Chiffrement au repos ✔️
Chiffrement en transit ✔️
Types de redondance LRS ou ZRS ✔️
Conversion de LRS vers ZRS ou inversement (points de terminaison privés uniquement) ✔️ Partages de fichiers classiques uniquement
Types de redondance GRS ou GZRS ⛔
extrémités de la zone Azure DNS (aperçu) ✔️ Partages de fichiers classiques uniquement
Points de terminaison privés ✔️
Montages de sous-répertoires ✔️
Accorder l'accès réseau à des réseaux virtuels Azure spécifiques ✔️
Accorder l’accès réseau à des adresses IP spécifiques ⛔
Niveau de stockage SSD ✔️
Niveau de support HDD ⛔
Autorisations POSIX ✔️
Écrasement de la racine ✔️
Accéder aux mêmes données à partir de Windows et du client Linux ⛔
Authentification basée sur l’identité ⛔
Suppression réversible de partage de fichiers Azure ✔️ Partages de fichiers classiques uniquement
Azure File Sync ⛔
sauvegardes de partages de fichiers Azure ⛔
Instantanés de partage de fichiers Azure ✔️
AzCopy ✔️ Partages de fichiers classiques uniquement
Explorateur Stockage Azure ✔️ Partages de fichiers classiques uniquement
navigateur stockage Azure sur Azure portail ⛔
Prise en charge de plus de 16 groupes ⛔

Remarque

La limite de 16 groupes est une contrainte de protocole NFS. Chaque utilisateur est limité à 16 ID de groupe par connexion.

Modèle de gestion

Les partages de fichiers NFS Azure prennent en charge deux fournisseurs de ressources de niveau supérieur :

  • Microsoft.FileShares (recommandé pour les nouveaux déploiements NFS) : crée un partage de fichiers autonome sans compte de stockage. Prend uniquement en charge le modèle de facturation v2 provisionné.
  • Microsoft. Stockage (classique) : crée des partages de fichiers classiques dans un compte de stockage. Prend en charge les modèles de facturation v1 et v2 pour les partages NFS provisionnés.

Pour obtenir une comparaison complète des fonctionnalités, consultez Comparaison des fournisseurs de ressources : Microsoft. Stockage et Microsoft. Partages de fichiers.

Sécurité et mise en réseau pour les partages de fichiers NFS Azure

Les partages de fichiers Azure NFS protègent les données grâce au chiffrement au repos et en transit, et nécessitent des contrôles d’accès au niveau réseau plutôt qu’une authentification basée sur les utilisateurs.

Encryption

Azure Files chiffre toutes les données au repos au moyen du chiffrement du service Stockage Azure (SSE). Le chiffrement du service de stockage fonctionne de la même façon que BitLocker sur Windows : il chiffre les données sous le niveau du système de fichiers. Étant donné que le chiffrement se produit sous le système de fichiers du partage de fichiers Azure car les données sont encodées sur disque, vous n'avez pas besoin d'accéder à la clé sous-jacente sur le client pour lire ou écrire dans le partage de fichiers Azure. Le chiffrement au repos s’applique aux protocoles SMB et NFS.

Les partages de fichiers classiques et les partages de fichiers Microsoft.FileShares prennent en charge le chiffrement TLS en transit via l’utilitaire d’assistance au montage AZNFS. Vous configurez les exigences de chiffrement à différents niveaux :

  • Microsoft.FileShares : Le chiffrement en transit est requis par défaut. Vous configurez ce paramètre sur le partage de fichiers individuel. Voir Paramètres avancés lors de la création d’un partage de fichiers.
  • Partages de fichiers classiques : Vous configurez Exiger le chiffrement en transit pour NFS sur le compte de stockage. Pour les nouveaux comptes de stockage créés via le portail Azure, ce paramètre est activé par défaut. Lorsque le paramètre est défini sur Non sélectionné, Transfert sécurisé requis régit le comportement de chiffrement NFS. Pour les paramètres par défaut de création et les étapes de configuration, voir Imposer le chiffrement en transit.

Azure fournit une couche de chiffrement pour toutes les données en transit entre les centres de données Azure à l’aide de MACSec. Grâce à cette technologie, le chiffrement existe lorsque les données sont transférées entre Azure centres de données.

Authentification et accès réseau

Comme les partages de fichiers Azure NFS ne supportent pas l'authentification basée sur l'utilisateur, ils s'appuient sur des règles d'accès réseau pour authentifier les clients. Les clients doivent donc se connecter via un point de terminaison privé ou un point de terminaison de service avec des restrictions sur le réseau virtuel.

À la fois les partages de fichiers classiques et les partages de fichiers Microsoft.FileShares prennent en charge ces options de connexion. Pour les partages de fichiers classiques, vous configurez le réseau sur le compte de stockage. Pour Microsoft.FileShares, vous configurez la configuration réseau sur chaque partage de fichiers.

Points de terminaison privés

Un point de terminaison privé fournit une adresse IP privée dans votre réseau virtuel pour accéder au partage de fichiers. Pour n’autoriser l’accès que via des points de terminaison privés, désactivez l’accès au réseau public. Les frais Private Link s’appliquent.

Les clients peuvent se connecter depuis le réseau virtuel ou depuis des réseaux virtuels appairés. Pour un accès sur site, connectez votre réseau au réseau virtuel via un VPN ou un ExpressRoute.

Points de terminaison de service

Un point de terminaison de service permet aux clients dans un sous-réseau d'accéder au point de terminaison public du partage de fichiers via le backbone Azure. Activez le point de terminaison du service sur le sous-réseau client. Configurez les règles réseau du partage de fichiers pour autoriser ce sous-réseau. Les sous-réseaux autorisés peuvent être dans le même abonnement ou un autre abonnement, y compris un autre locataire Microsoft Entra. Il n’y a pas de frais supplémentaires pour les points de terminaison de service.

Un point de terminaison de service n’attribue pas d’adresse IP privée au partage de fichiers. Si un événement rare, comme une panne de zone, modifie l’adresse IP du point de terminaison public, les clients pourraient devoir remonter le partage réseau.

Filtrage sortant optionnel

Les règles réseau du partage de fichiers contrôlent quels clients peuvent y accéder. Ils ne limitent pas les ressources de stockage auxquelles ces clients peuvent accéder. Par exemple, un client capable de lire votre partage de fichiers pourrait copier des données vers une autre ressource sur laquelle il a la permission d’écrire.

Pour les partages de fichiers classiques, vous pouvez éventuellement utiliser une stratégie de point de terminaison de service pour limiter les comptes de stockage auxquels les clients d’un sous-réseau peuvent accéder via les points de terminaison de service. Le trafic des points de terminaison de service contourne Pare-feu Azure et les appliances virtuelles réseau. Une stratégie filtre les destinations sur ce trajet. Il ne restreint pas d’autres chemins sortants ni ne remplace les règles réseau et exigences d’autorisation de la destination.

Les stratégies de point de terminaison de service ne sont actuellement pas prises en charge pour les partages de fichiers Microsoft.FileShares. Si le sous-réseau client est associé à une stratégie, les clients doivent utiliser un point de terminaison privé pour accéder à ces partages de fichiers. Pour plus d’informations, voir Restreindre l’accès sortant avec les stratégies de point de terminaison de service.

Pour plus d’informations sur les options de mise en réseau, consultez Azure Files considérations relatives à la mise en réseau.

Disponibilité régionale du partage de fichiers NFS Azure

La disponibilité régionale dépend du fournisseur de ressources et de l’option de redondance :

Performances du partage de fichiers NFS Azure

Les partages de fichiers Azure NFS ne sont disponibles que sur les partages de fichiers SSD. Les deux fournisseurs de ressources supportent le modèle de facturation provisionnée v2, qui vous permet de définir indépendamment la capacité provisionnée, les IOPS et le débit. Les partages de fichiers classiques prennent également en charge le modèle de facturation v1 provisionné, dans lequel les IOPS et le débit évoluent automatiquement avec la capacité provisionnée. Pour plus d’informations sur les deux modèles, consultez Comprendre Azure Files facturation.

Les latences d’E/S standard pour les partages de fichiers SSD Azure se trouvent dans la plage de millisecondes à faible chiffre pour les petites opérations d’E/S. Les charges de travail riches en métadonnées, telles que untar, peuvent connaître une latence plus élevée en raison du volume important d’opérations d’ouverture et de fermeture.

Pour obtenir des conseils sur l’amélioration des performances NFS à grande échelle, consultez Améliorer les performances du partage de fichiers NFS Azure.

Étapes suivantes

  • Last updated on