Partages de fichiers NFS Azure
Azure Files propose deux protocoles de système de fichiers standard pour le montage de partages de fichiers Azure : SMB (Server Message Block) et NFS (Network File System), ce qui vous permet de choisir le protocole le mieux adapté à votre charge de travail. Les partages de fichiers Azure ne prennent pas en charge l’accès à un partage de fichiers Azure individuel avec à la fois les protocoles SMB et NFS. Cependant, vous pouvez créer des partages de fichiers SMB et NFS au sein du même compte de stockage FileStorage. Azure Files propose des partages de fichiers d’entreprise qui peuvent être mis à l’échelle pour répondre à vos besoins de stockage et accessibles simultanément par des milliers de clients.
Cet article traite des partages de fichiers Azure NFS. Pour plus d’informations sur les partages de fichiers Azure SMB, consultez Partages de fichiers SMB dans Azure Files.
Important
Les partages de fichiers Azure NFS ne sont pas pris en charge pour Windows. Pour obtenir la liste des partages de fichiers NFS Azure en production, consultez Résoudre les problèmes liés aux partages de fichiers Azure NFS. Les listes de contrôle d’accès (ACL) NFS ne sont pas prises en charge.
Scénarios courants
Les partages de fichiers NFS sont souvent utilisés dans les scénarios suivants :
- Stockage d’applications Linux/UNIX, notamment des applications métier écrites à l’aide des API du système de fichiers Linux ou POSIX (même si elles n’ont pas besoin d’être compatibles avec POSIX).
- Des charges de travail qui requièrent des partages de fichiers compatibles POSIX, le respect de la casse ou des autorisations de style UNIX (UID/GID).
- Nouveau développement d’applications et de services, en particulier si cette application ou ce service est obligatoire pour les E/S aléatoires et le stockage hiérarchique.
Fonctionnalités
- Système de fichiers entièrement compatible POSIX.
- Prise en charge des liens physiques.
- Prise en charge des liens symboliques.
- Les partages de fichiers NFS ne prennent actuellement en charge que la plupart des fonctionnalités de la spécification de protocole 4.1. Certaines fonctionnalités telles que les délégations et les rappels de toutes sortes, l’authentification Kerberos, les listes ACL et le chiffrement en transit ne sont pas prises en charge.
Notes
La création d’un lien physique à partir d’un lien symbolique existant n’est actuellement pas prise en charge.
Sécurité et mise en réseau
Toutes les données stockées dans Azure Files sont chiffrées au repos avec Azure Storage Service Encryption (SSE). Cette fonctionnalité fonctionne de la même façon que BitLocker sur Windows : les données sont chiffrées sous le niveau du système de fichiers. Comme les données sont chiffrées sous le système de fichiers du partage de fichiers Azure, car codées sur le disque, il n’est pas nécessaire d’avoir accès à la clé sous-jacente sur le client pour lire ou écrire sur le partage de fichiers Azure. Le chiffrement au repos s’applique aux protocoles SMB et NFS.
Pour un chiffrement en transit, Azure fournit une couche de chiffrement pour toutes les données en transit entre les centres de données Azure en utilisant MACSec. De ce fait, un chiffrement est appliqué lorsque les données sont transférées entre des centres de données Azure.
Contrairement à Azure Files qui utilise le protocole SMB, les partages de fichiers utilisant le protocole NFS n’offrent pas l’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 seules les connexions sécurisées sont établies avec votre partage NFS, vous devez configurer un point de terminaison privé ou 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 dans les réseaux virtuels appairés, y compris ceux situés dans d’autres régions et en local. 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 de 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 dans un autre abonnement, y compris ceux appartenant à un autre tenant (locataire/client) Microsoft Entra. L’utilisation de points de terminaison de service n’engendre pas de frais supplémentaires. Toutefois, sachez qu’un événement rare tel qu’une panne zonale peut entraîner la modification de l’adresse IP sous-jacente du compte de stockage. Bien que les données soient alors toujours disponibles sur le partage de fichiers, le client nécessitera un remontage du partage.
Pour accéder aux partages à partir d’un emplacement local, vous devez configurer un réseau 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 réseau disponibles, consultez Considérations réseau Azure Files.
Prise en charge des fonctionnalités du Stockage Azure
Le tableau suivant indique le niveau actuel de prise en charge des fonctionnalités du Stockage Azure dans les comptes pour lesquels la fonctionnalité NFS 4.1 est activée.
L’état des éléments figurant dans ce tableau peut évoluer au fil du temps, car la prise en charge continue de s’étendre.
Disponibilité régionale
Les partages de fichiers NFS Azure sont pris en charge dans toutes les régions qui prennent en charge le stockage de fichiers Premium. Veuillez consulter la rubrique Disponibilité des produits Azure par région.
Performances
Les partages de fichiers Azure NFS sont uniquement proposés sur des partages de fichiers Premium, qui stockent les données sur des disques SSD. Les IOPS et le débit des partages NFS sont mis à l’échelle avec la capacité provisionnée. Pour comprendre les formules utilisées pour les IOPS, le bursting des E/S et le débit, accédez à l’article Présentation de la facturation et consultez la section relative au Modèle v1 approvisionné. Exprimées en millisecondes, es latences d’E/S moyennes sont à un seul chiffre dans le bas de la fourchette pour une petite taille d’E/S, tandis que les latences de métadonnées moyennes sont à un seul chiffre dans le haut de la fourchette. Les opérations lourdes en métadonnées comme la décompression et les charges de travail telles que WordPress peuvent faire face à des latences supplémentaires en raison du nombre élevé d’opérations d’ouverture et de fermeture.
Remarque
Vous pouvez utiliser l’option de montage Linux nconnect pour améliorer les performances des partages de fichiers Azure NFS à grande échelle. Pour plus d’informations, consultez l’article Améliorer les performances du partage de fichiers Azure NFS.
Charges de travail
Important
Pour obtenir la liste des partages de fichiers NFS Azure en production, consultez Résoudre les problèmes liés aux partages de fichiers Azure NFS.
NFS a été validé pour fonctionner correctement avec les 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 messages, les répertoires de base des serveurs de fichiers à usage général et les référentiels de contenu pour les charges de travail d’application.