Partager via


Comprendre les protocoles NAS dans Azure NetApp Files

Les protocoles NAS sont la façon dont les conversations se produisent entre les clients et les serveurs. NFS et S Mo sont les protocoles NAS utilisés dans Azure NetApp Files. Chacun offre ses propres méthodes distinctes pour la communication, mais à leur racine, ils fonctionnent principalement de la même façon.

  • Les deux servent un jeu de données unique à de nombreux clients connectés en réseau disparates.
  • Les deux peuvent utiliser des méthodes d’authentification chiffrées pour partager des données.
  • Les deux peuvent être contrôlées avec des autorisations de partage et de fichier.
  • Les deux peuvent chiffrer les données en cours d’exécution.
  • Les deux peuvent utiliser plusieurs connexions pour faciliter la parallélise des performances.

NFS (Network File System)

NFS est principalement utilisé avec des clients linux/UNIX tels que Red Hat, SUSE, Ubuntu, AIX, Solaris et Apple OS. Azure NetApp Files prend en charge n’importe quel client NFS qui fonctionne dans les normes RFC. Windows peut également utiliser NFS pour l’accès, mais il ne fonctionne pas à l’aide des normes RFC (Request for Comments).

Les normes RFC pour les protocoles NFS sont disponibles ici :

NFSv3

NFSv3 est une offre de base du protocole et possède les attributs clés suivants :

  • NFSv3 est sans état, ce qui signifie que le serveur NFS ne suit pas les états des connexions (y compris les verrous).
  • Le verrouillage est géré en dehors du protocole NFS, à l’aide du Gestionnaire de verrous réseau (NLM). Étant donné que les verrous ne sont pas intégrés au protocole, les verrous obsolètes peuvent parfois se produire.
  • Étant donné que NFSv3 est sans état, les performances avec NFSv3 peuvent être nettement meilleures dans certaines charges de travail, en particulier dans les charges de travail avec des opérations de métadonnées élevées telles que OPEN, CLOSE, SETATTR et GETATTR. C’est le cas, car il y a moins de travail général qui doit être effectué pour traiter les demandes sur le serveur et le client.
  • NFSv3 utilise un modèle d’autorisation de fichier de base où seul le propriétaire du fichier, un groupe et tous les autres peuvent être affectés à une combinaison d’autorisations de lecture/écriture/exécution.
  • NFSv3 peut utiliser des ACL NFSv4.x, mais un client de gestion NFSv4.x doit configurer et gérer les listes de contrôle d’accès. Azure NetApp Files ne prend pas en charge l’utilisation de listes de contrôle d’accès non standard POSIX.
  • NFSv3 nécessite également l’utilisation d’autres protocoles auxiliaires pour les opérations régulières telles que la découverte de ports, le montage, le verrouillage, la surveillance de l’état et les quotas. Chaque protocole auxiliaire utilise un port réseau unique, ce qui signifie que les opérations NFSv3 nécessitent davantage d’exposition par le biais de pare-feu avec des numéros de port connus.
  • Azure NetApp Files utilise les numéros de port suivants pour les opérations NFSv3. Il n’est pas possible de modifier ces numéros de port :
    • Portmapper (111)
    • Montage (635)
    • NFS (2049)
    • NLM (4045)
    • NSM (4046)
    • Rquota (4049)
  • NFSv3 peut utiliser des améliorations de sécurité telles que Kerberos, mais Kerberos affecte uniquement la partie NFS des paquets ; Les protocoles auxiliaires (tels que NLM, portmapper, montage) ne sont pas inclus dans la conversation Kerberos.
    • Azure NetApp Files prend uniquement en charge le chiffrement Kerberos NFSv4.1
  • NFSv3 utilise des ID numériques pour son authentification utilisateur et groupe. Les noms d’utilisateur et de groupe ne sont pas requis pour la communication ou les autorisations, ce qui peut faciliter l’usurpation d’un utilisateur, mais la configuration et la gestion sont plus simples.
  • NFSv3 peut utiliser LDAP pour les recherches d’utilisateurs et de groupes.

Prise en charge de la version du service NFSv3

NFSv3 prend actuellement en charge les versions suivantes de chaque protocole auxiliaire dans Azure NetApp Files :

Service Versions prises en charge
Portmapper 4, 3, 2
NFS 4, 3*
Montage 3, 2, 1
Nlockmgr 4
État 1
Rquotas 1

* Les versions prises en charge par NFS s’affichent en fonction de la version sélectionnée pour le volume Azure NetApp Files.

Ces informations peuvent être collectées à partir de votre volume Azure NetApp Files avec la commande suivante :

# rpcinfo -s <Azure NetApp Files IP address>

NFSv4.x

NFSv4.x fait référence à toutes les versions NFS ou versions mineures qui se trouvent sous NFSv4, notamment NFSv4.0, NFSv4.1 et NFSv4.2. Azure NetApp Files prend actuellement en charge NFSv4.1 uniquement.

NFSv4.x présente les caractéristiques suivantes :

  • NFSv4.x est un protocole avec état, ce qui signifie que le client et le serveur suivent les états des connexions NFS, y compris les états de verrouillage. Le montage NFS utilise un concept appelé « ID d’état » pour suivre les connexions.
  • Le verrouillage est intégré au protocole NFS et ne nécessite pas de protocoles de verrouillage auxiliaires pour assurer le suivi des verrous NFS. Au lieu de cela, les verrous sont accordés sur une base de bail. Ils expirent après une certaine durée si une connexion client ou serveur est perdue, retournant ainsi le verrou au système pour une utilisation avec d’autres clients NFS.
  • L’état de NFSv4.x présente certains inconvénients, tels que les interruptions potentielles pendant les pannes réseau ou les basculements de stockage, et la surcharge des performances dans certains types de charge de travail (tels que des charges de travail de métadonnées élevées).
  • NFSv4.x offre de nombreux avantages significatifs par rapport à NFSv3, notamment :
    • Meilleurs concepts de verrouillage (verrouillage basé sur le bail)
    • Meilleure sécurité (moins de ports de pare-feu nécessaires, intégration standard avec Kerberos, contrôles d’accès granulaires)
    • Autres fonctionnalités
    • Opérations NFS composées (plusieurs commandes dans une requête de paquet unique pour réduire la conversation réseau)
    • TCP uniquement
  • NFSv4.x peut utiliser un modèle d’autorisation de fichier plus robuste similaire aux autorisations NTFS Windows. Ces listes de contrôle d’accès granulaires peuvent être appliquées aux utilisateurs ou aux groupes et autoriser la définition d’autorisations sur un large éventail d’opérations que les opérations de lecture/écriture/exécution de base. NFSv4.x peut également utiliser les bits de mode POSIX standard utilisés par NFSv3.
  • Étant donné que NFSv4.x n’utilise pas de protocoles auxiliaires, Kerberos est appliqué à l’ensemble de la conversation NFS lors de l’utilisation.
  • NFSv4.x utilise une combinaison de noms d’utilisateurs/de groupes et de chaînes de domaine pour vérifier les informations d’utilisateur et de groupe. Le client et le serveur doivent accepter les chaînes de domaine pour que l’authentification d’utilisateur et de groupe appropriée se produise. Si les chaînes de domaine ne correspondent pas, l’utilisateur ou le groupe NFS est squashing ed à l’utilisateur spécifié dans le fichier /etc/idmapd.conf sur le client NFS (par exemple, personne).
  • Bien que NFSv4.x utilise par défaut des chaînes de domaine, il est possible de configurer le client et le serveur pour revenir sur les ID numériques classiques vus dans NFSv3 lorsque AUTH_SYS est en cours d’utilisation.
  • NFSv4.x a une intégration approfondie avec les chaînes de nom d’utilisateur et de groupe, et le serveur et les clients doivent accepter ces utilisateurs et groupes. Par conséquent, envisagez d’utiliser un serveur de service de noms pour l’authentification utilisateur telle que LDAP sur les clients et serveurs NFS.

Pour obtenir des questions fréquemment posées sur NFS dans Azure NetApp Files, consultez la FAQ sur azure NetApp Files NFS.

SMB (Server Message Block)

S Mo est principalement utilisé avec les clients Windows pour les fonctionnalités NAS. Toutefois, il peut également être utilisé sur des systèmes d’exploitation Linux tels qu’AppleOS, RedHat, etc. Ce déploiement s’effectue à l’aide d’une application appelée Samba. Azure NetApp Files prend en charge officiellement S Mo à l’aide de Windows et macOS. S Mo/Samba sur les systèmes d’exploitation Linux peut fonctionner avec Azure NetApp Files, mais il n’existe aucun support officiel.

Azure NetApp Files prend uniquement en charge les versions S Mo 2.1 et S Mo 3.1.

S Mo présente les caractéristiques suivantes :

  • S Mo est un protocole avec état : les clients et le serveur conservent un « état » pour S Mo partager des connexions pour améliorer la sécurité et le verrouillage.
  • Le verrouillage dans S Mo est considéré comme obligatoire. Lorsqu’un fichier est verrouillé, aucun autre client ne peut écrire dans ce fichier jusqu’à ce que le verrou soit libéré.
  • S Mo v2.x et versions ultérieures utilisent des appels composés pour effectuer des opérations.
  • S Mo prend en charge l’intégration Kerberos complète. Avec la façon dont les clients Windows sont configurés, Kerberos est souvent en cours d’utilisation sans que les utilisateurs finaux ne sachent jamais.
  • Lorsque Kerberos ne peut pas être utilisé pour l’authentification, windows NT LAN Manager (NTLM) peut être utilisé comme secours. Si NTLM est désactivé dans l’environnement Active Directory, les demandes d’authentification qui ne peuvent pas utiliser Kerberos échouent.
  • S Mo v3.0 et versions ultérieures prennent en charge le chiffrement de bout en bout pour les partages S Mo.
  • S Mo v3.x prend en charge les gains de performances dans certaines charges de travail.
  • S Mo utilise des noms d’utilisateur et de groupe (via la traduction SID) pour l’authentification. Les informations d’utilisateur et de groupe sont fournies par un contrôleur de domaine Active Directory.
  • S Mo dans Azure NetApp Files utilise des listes de contrôle d’accès NTFS (Windows New Technology File System) standard pour les autorisations de fichier et de dossier.

Pour obtenir des questions fréquemment posées sur S Mo dans Azure NetApp Files, consultez la FAQ sur Azure NetApp Files S Mo.

Protocoles doubles

Certaines organisations ont des environnements Windows purs ou UNIX purs (homogènes) dans lesquels toutes les données sont accessibles à l’aide de l’une des approches suivantes :

Toutefois, de nombreux sites doivent permettre aux jeux de données d’être accessibles à partir de clients Windows et UNIX (hétérogènes). Pour les environnements avec ces exigences, Azure NetApp Files prend en charge le NAS à double protocole natif. Une fois que l’utilisateur est authentifié sur le réseau et dispose à la fois des autorisations de partage ou d’exportation appropriées et des autorisations de niveau fichier nécessaires, l’utilisateur peut accéder aux données des hôtes UNIX à l’aide de NFS ou d’hôtes Windows à l’aide de S Mo.

Raisons d’utiliser des volumes à double protocole

L’utilisation de volumes à double protocole avec Azure NetApp Files offre plusieurs avantages distincts. Lorsque les jeux de données peuvent être accessibles en toute transparence et simultanément par les clients à l’aide de différents protocoles NAS, les avantages suivants peuvent être obtenus :

  • Réduisez les tâches globales de gestion de l’administrateur de stockage.
  • Exiger une seule copie des données à stocker pour l’accès NAS à partir de plusieurs types de clients.
  • Le NAS indépendant du protocole permet aux administrateurs de stockage de contrôler le style d’ACL et le contrôle d’accès présentés aux utilisateurs finaux.
  • Centraliser les opérations de gestion des identités dans un environnement NAS.

Considérations courantes relatives aux environnements à double protocole

L’accès NAS double protocole est souhaitable par de nombreuses organisations pour sa flexibilité. Toutefois, il existe une perception de la difficulté qui crée un ensemble de considérations propres au concept de partage entre les protocoles. Ces considérations incluent, mais ne sont pas limitées aux éléments suivants :

  • Exigence de connaissance entre plusieurs protocoles, systèmes d’exploitation et systèmes de stockage.
  • Connaissance opérationnelle des serveurs de service de noms, tels que DNS, LDAP, etc.

En outre, les facteurs externes peuvent entrer en jeu, tels que :

  • Gestion de plusieurs services et groupes informatiques (tels que les groupes Windows et les groupes UNIX)
  • Acquisitions d’entreprise
  • Consolidations de domaine
  • Réorganisations

Malgré ces considérations, la configuration, la configuration et l’accès NAS à double protocole peuvent être intégrés de manière simple et transparente à n’importe quel environnement.

Comment Azure NetApp Files simplifie l’utilisation du double protocole

Azure NetApp Files consolide l’infrastructure requise pour les environnements NAS à double protocole réussis dans un plan de gestion unique, y compris les services de stockage et de gestion des identités.

La configuration à double protocole est simple et la plupart des tâches sont dotées d’une protection par le framework de gestion des ressources Azure NetApp Files pour simplifier les opérations pour les opérateurs cloud.

Une fois qu’une connexion Active Directory est établie avec Azure NetApp Files, les volumes à double protocole peuvent utiliser la connexion pour gérer à la fois la gestion des identités Windows et UNIX requise pour l’authentification utilisateur et de groupe appropriée avec des volumes Azure NetApp Files sans étapes de configuration supplémentaires en dehors de la gestion normale des utilisateurs et des groupes dans les services Active Directory ou LDAP.

En supprimant les étapes supplémentaires centrées sur le stockage pour les configurations à double protocole, Azure NetApp Files simplifie le déploiement global de double protocole pour les organisations qui cherchent à passer à Azure.

Fonctionnement des volumes double protocole Azure NetApp Files

À un niveau élevé, les volumes double protocole Azure NetApp Files utilisent une combinaison de styles de mappage de noms et d’autorisations pour fournir un accès cohérent aux données, quel que soit le protocole utilisé. Cela signifie que vous accédez à un fichier à partir de NFS ou de S Mo, vous pouvez être assuré que les utilisateurs ayant accès à ces fichiers peuvent y accéder, et les utilisateurs sans accès à ces fichiers ne peuvent pas y accéder.

Lorsqu’un client NAS demande l’accès à un volume à double protocole dans Azure NetApp Files, les opérations suivantes se produisent pour fournir une expérience transparente à l’utilisateur final.

  1. Un client NAS établit une connexion NAS au volume double protocole Azure NetApp Files.
  2. Le client NAS transmet des informations d’identité utilisateur à Azure NetApp Files.
  3. Azure NetApp Files case activée s pour vous assurer que le client/l’utilisateur NAS a accès au partage NAS.
  4. Azure NetApp Files prend cet utilisateur et le mappe à un utilisateur valide trouvé dans les services de noms.
  5. Azure NetApp Files compare cet utilisateur aux autorisations au niveau du fichier dans le système.
  6. Les autorisations de fichier contrôlent le niveau d’accès de l’utilisateur.

Dans l’illustration suivante, user1 s’authentifie auprès d’Azure NetApp Files pour accéder à un volume à double protocole via S Mo ou NFS. Azure NetApp Files recherche les informations Windows et UNIX de l’utilisateur dans Microsoft Entra ID, puis mappe les identités Windows et UNIX de l’utilisateur un à un. L’utilisateur est vérifié comme user1 et obtient user1les informations d’identification d’accès.

Dans cette instance, user1 obtient un contrôle total sur son propre dossier (user1-dir) et aucun accès au HR dossier. Ce paramètre est basé sur les listes de contrôle d’accès de sécurité spécifiées dans le système de fichiers et user1 obtient l’accès attendu, quel que soit le protocole à partir duquel ils accèdent aux volumes.

Diagram of user accessing a dual-protocol volume with Azure NetApp Files.

Considérations relatives aux volumes à double protocole Azure NetApp Files

Lorsque vous utilisez des volumes Azure NetApp Files pour accéder à S Mo et NFS, certaines considérations s’appliquent :

  • Vous avez besoin d’une connexion Active Directory. Par conséquent, vous devez respecter les conditions requises pour les connexions Active Directory.
  • Les volumes à double protocole nécessitent une zone de recherche inverse dans DNS avec un enregistrement de pointeur associé (PTR) de l’ordinateur hôte AD pour empêcher les échecs de création de volumes à double protocole.
  • Votre client NFS et vos packages associés (par exemple nfs-utils) doivent être à jour pour la meilleure sécurité, la fiabilité et la prise en charge des fonctionnalités.
  • Les volumes à double protocole prennent en charge les services de domaine Services de domaine Active Directory (AD DS) et Microsoft Entra Domain Services.
  • Les volumes à double protocole ne prennent pas en charge l’utilisation du protocole LDAP via TLS avec Microsoft Entra Domain Services. Consultez Considérations relatives à LDAP sur TLS.
  • Les versions NFS prises en charge sont les suivantes : NFSv3 et NFSv4.1.
  • Les fonctionnalités NFSv4.1 telles que le système de fichiers réseau parallèle (pNFS), la jonction de session et les références ne sont actuellement pas prises en charge avec les volumes Azure NetApp Files.
  • Les attributs étendus Windows ne sont pas pris en charge dans les set/get volumes à double protocole.
  • Consultez d’autres considérations relatives à la création d’un volume double protocole pour Azure NetApp Files.

Étapes suivantes