Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à : ✔️ partages de fichiers NFS
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. Azure partages de fichiers ne prennent pas en charge l'accès à un partage de fichiers Azure individuel avec les protocoles SMB et NFS, même si vous pouvez créer des partages de fichiers SMB et NFS dans le même compte de stockage FileStorage. 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 Azure NFS pour les fonctionnalités de stockage Azure
Le tableau suivant montre le niveau actuel de prise en charge des fonctionnalités pour les partages de fichiers NFS Azure.
L’état des éléments figurant dans ce tableau peut évoluer au fil du temps, car la prise en charge continue de s’étendre.
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 approvisionnés et le jeu de fonctionnalités complet Azure Files.
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.
Pour encryption en transit, Azure Files volumes NFSv4.1 améliorent la sécurité réseau en activant des connexions TLS sécurisées entre le serveur et le client, en protégeant les données en transit contre l’interception. Azure Files fournit un paramètre dédié Require Encryption in Transit for NFS pour contrôler indépendamment si le chiffrement est requis pour l’accès NFS. Pour les nouveaux comptes de stockage créés à l’aide du portail Azure, ce paramètre est activé par défaut. Les comptes de stockage créés à l’aide de Azure PowerShell, de Azure CLI ou de l’API FileREST définissent cette valeur comme Not sélectionné pour garantir la compatibilité descendante. Pour les comptes de stockage existants, le paramètre de transfert sécurisé requis continue de régir le comportement de chiffrement NFS jusqu’à ce que vous configuriez explicitement le paramètre par protocole.
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
Contrairement à Azure Files à l'aide du protocole SMB, les partages de fichiers qui utilisent le protocole NFS n'offrent pas d'authentification basée sur l'utilisateur. L’authentification pour les partages NFS est basée sur les règles de sécurité réseau configurées. Pour cette raison, pour vous assurer que votre partage NFS accepte uniquement les connexions sécurisées, vous devez configurer un point de terminaison privé ou un point de terminaison de service pour votre compte de stockage.
Un point de terminaison privé (également appelé liaison privée) donne à votre compte de stockage une adresse IP privée et statique au sein de votre réseau virtuel, ce qui empêche les interruptions de connectivité dues aux modifications d’adresses IP dynamiques. Le trafic vers votre compte de stockage reste au sein de réseaux virtuels appairés, y compris ceux d’autres régions et ceux sur site. Les tarifs de traitement des données standard s’appliquent.
Si vous n'avez pas besoin d'une adresse IP statique, vous pouvez activer un point de terminaison service pour Azure Files au sein du réseau virtuel. Un point de terminaison de service configure des comptes de stockage pour autoriser l’accès uniquement à partir de sous-réseaux spécifiques. Les sous-réseaux autorisés peuvent appartenir à un réseau virtuel dans le même abonnement ou un autre abonnement, y compris ceux qui appartiennent à un autre locataire Microsoft Entra. L’utilisation de points de terminaison de service n’engendre pas de frais supplémentaires. Toutefois, un événement rare tel qu’une panne de zone peut modifier l’adresse IP sous-jacente du compte de stockage. Bien que les données soient toujours disponibles sur le partage de fichiers, vous devez remonter le partage.
Si vous souhaitez accéder aux partages à partir d’un emplacement local, configurez un VPN ou ExpressRoute en plus d’un point de terminaison privé. Les demandes qui ne proviennent pas des sources suivantes sont rejetées :
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
Les partages de fichiers NFS Azure sont pris en charge dans toutes les régions qui prennent en charge les partages de fichiers SSD. Consultez Azure produits disponibles par région.
Performances du partage de fichiers NFS Azure
Les partages de fichiers Azure NFS ne sont disponibles que sur les partages de fichiers SSD. Sous le modèle de facturation v2 approvisionné, vous pouvez définir la capacité provisionnée, les E/S par seconde et le débit indépendamment, ce qui vous permet de contrôler précisément les coûts des charges de travail NFS avec des modèles d’E/S prévisibles. Dans le modèle de facturation v1 provisionné, les IOPS et le débit évoluent automatiquement en fonction de 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.