NetApp Tech OnTap

Quoi de neuf dans la version 4 de NFS ?

Depuis son démarrage en 1984, le système de fichier en réseau (NFS) est devenu un standard du partage de fichiers en réseau, particulièrement dans les communautés UNIX® et Linux®. Au cours des 20 dernières années, le protocole NFS a connu une métamorphose progressive s’adaptant à de nouvelles exigences ainsi qu’à un marché évolutif.

Pendant la majeure partie de cette période, NetApp s’est efforcé d’orienter l’évolution du NFS afin de mieux répondre aux besoins des utilisateurs. Brian Pawlowski, Directeur des technologies NetApp et vice-président du groupe de travail sur la version 4 du NFS (NFSv4), a cosigné la spécification de la troisième version du NFS (version la plus utilisée actuellement). Mike Eisler et Dave Nioveck sont les coauteurs de la spécification de la version 4 du NFS (la version disponible la plus récente du NFS), et sont les éditeurs de la spécification de la version 4.1 actuellement en cours de développement.

 
NFSv3
NFSv4
Personality Stateless Stateful
Semantics UNIX only Suport UNIX and Windows
Authentication Weak (AUTH_SYS) Strong (Kerberos)
Identification 32 bit UID/GID String based (xyz@netapp.com)
Permissions UNIX based Windows like access
Transport UDP & TCP TCP
Caching Ad-hoc Delegations

Figure 1) Comparaison de NFSv3 et NFSv4.

Le NFS est constitué d’un logiciel serveur, par exemple celui du stockage NetApp®, et un logiciel client fonctionnant sur hôte nécessitant un accès au stockage en réseau. Un bon fonctionnement exige une maturité et une implémentation correcte des deux parties de la connexion : client et serveur. Bien que la version 4 du NFS soit intégrée à la livraison de Data ONTAP® 6.4, notre code de base a subi de nombreuses modifications et atteint une telle maturité que NFSv4 nous semble maintenant prêt à être utilisé en production.

Aujourd’hui, les implémentations client se stabilisent. NetApp a également apporté d’éminentes modifications et améliorations à Data ONTAP 7.3 afin de prendre en charge NFSv4. Dans cet article, je vais explorer les trois principales caractéristiques de NFSv4 qui ont suscité un intérêt :

  • Les listes de contrôle d’accès (ACL) pour la sécurité et pour la compatibilité avec Windows®
  • La sécurité obligatoire avec Kerberos
  • Les délégations pour une mise en mémoire cache côté client
Bien que cette discussion concernera en général toutes les mises en application de NFSv4, je décrirai également certains détails propres à NetApp et discuterai des meilleures pratiques le moment venu.

  AIX Client Server BSD/OSX Client Server (not sup. by apple) EMC Server Humingbird Client Linux Client Server
(RHEL5)
NetApp Server Solaris 10 client Server
Delegations Yes   Yes   Yes Yes Yes
Access Control lists Yes   Yes   Yes Yes Yes
Kerberos V5 Yes Yes Yes Yes Yes Yes Yes
File Streams           Yes Yes
I18n Yes Yes   Yes Yes Yes Yes
Global Namespace/Referrals Yes       Yes Future  

Figure 2) Statut de mise en application du NFSv4 pour client et serveur.

Listes de contrôle d’accès

Les ACL représentent les fonctionnalités les plus fréquemment exigées par les utilisateurs de NetApp à la recherche d'une meilleure compatibilité avec les clients Windows. Elles améliorent considérablement la sécurité du NFS et l’interopérabilité avec le protocole réseau CIFS.

Les ACL autorisent ou refusent des droits d'accès par utilisateur pour chaque objet fichier, fournissant un contrôle d'accès plus rigoureux et un degré de sélectivité plus élevé que ne le permettent les bits de permission des systèmes UNIX. Elles sont basées sur le modèle NT mais ne contiennent pas d’informations propriétaire/groupe. Les ACL du NFSv4 se composent de plusieurs Entrées de Contrôle d’Accès (ACE) contenant des informations de type accès autorisé/refusé, bits de permission, nom de l'utilisateur/nom de groupe et indicateurs.

Parce que NetApp offre déjà un support ACL pour les clients CIFS, l’ajout d’ACL dans le NFSv4 suppose certaines considérations. NetApp offre trois types de qtree : UNIX, NTFS et mixte pour une utilisation différente suivant les clients. La façon dont les ACL du NFSv4 sont manipulées dépend du type de qtree :

Qtree UNIX
  • ACL du NFSv4 et bits mode sont effectifs
  • Les clients Windows ne peuvent pas définir d’attributs
  • La sémantique UNIX prédomine

Qtree NTFS

  • Les ACL NT et les bits mode sont effectifs, les clients UNIX ne peuvent pas définir d’attributs
  • Les ACL du NFSv4 sont générés à partir du bits mode pour les clients NFS accédant aux fichiers avec une ACL NT
  • La sémantique NT prédomine

Qtree mixte

  • ACL du NFSv4, ACL NT et bits mode sont effectifs
  • Les clients Windows et UNIX peuvent définir des attributs
  • L’ACL du NFSv4 est générée à partie du bits mode pour les fichiers possédant des ACL NT

Il est évident que vous devez choisir judicieusement le type de Qtree que vous utilisez afin d'obtenir les résultats escomptés :

  • Accès NFS uniquement : Qtree UNIX
  • Accès mixte : Qtree mixte
  • Accès CIFS principalement : Qtree NFTS
  • CIFS uniquement : Qtree NFTS

Une autre bonne pratique relative aux ACL consiste à ne pas utiliser plus de 192 ACE par ACL. Vous pouvez augmenter le nombre d'ACE par ACL à un maximum de 400 mais cela pourrait causer des problèmes au cas où vous voudriez retourner à une version antérieure de Data ONTAP ou si vous utilisez SnapMirror® pour retourner à une version plus ancienne.

Sécurité obligatoire

Outre l'ajout d'ACL, NFSv4 améliore la sécurité des versions plus anciennes du NFS paplusieurs facteurs :

  • L’obligation de disponibilité d'une forte sécurité RPC dépendant de la cryptographie
  • La négociation du type de sécurité utilisé entre serveur et client par un système in-band sécurisé
  • L’utilisation de chaînes de caractères au lieu de nombres entiers pour représenter les identificateurs d'utilisateurs ou de groupes

La sécurité NFS a été rehaussée par l’ajout d’une sécurité basée sur l’API de services de sécurité (GSS-API), appelée RPCSEC_GSS [RFC2203]. Toutes les versions du NFS sont compatibles avec l’utilisation de RPCSEC_GSS. Cependant, une mise en application conforme de la version 4 du NFS nécessite l’implémentation de RPCSEC_GSS. RPCSEC_GSS est alloué de façon similaire à AUTH_SYS généralement utilisé en tant que méthode standard d’authentification dans les versions précédentes.
RPCSEC_GSS diffère de AUTH_SYS et des autres mécanismes de sécurité NFS traditionnels de deux façons :

  • RPCSEC_GSS est plus qu’une simple authentification. Ce mécanisme est capable d'effectuer des sommes de contrôle intégrales et un chiffrement de la totalité du corps de requêtes et de réponses RPC, d’où une sécurité dépassant la simple authentification.
  • Parce que RPCSEC_GSS englobe les jetons de message GSS_API, en opérant simplement en tant qu’agent de transport des jetons à mécanisme spécifique comme pour Kerberos ; l’ajout de nouveaux mécanismes de sécurité (tant qu'ils sont conformes à GSS-API) ne nécessite pas de réécrire d’importantes portions du NFS.

NFS AUTH System















Figure 3) NFS avec AUTH_SYS contre une sécurité RPCSEC-GSS.

NFSv3 et NFSv4 peuvent tous les deux utiliser RPCSEC-GSS. Cependant, AUTH_SYS est la commande par défaut de NFSv3.

Le seul mécanisme de sécurité fourni par NetApp ou la plupart des clients NFSv4 sous RPCSEC_GSS est Kerberos 5. Kerberos est un mécanisme d’authentification utilisant le chiffrement par clé symétrique. Aucun mot de passe n'est envoyé sur le réseau que ce soit en texte clair ou en mode chiffré et des tickets codés ainsi que des clés de session sont utilisés pour authentifier les utilisateurs avant qu’ils puissent accéder aux ressources du réseau. Le système Kerberos utilise des Centres de Distribution de Clés (KDC) qui contiennent une base de données centralisée de noms d'utilisateurs et de mots de passe. NetApp prend en charge deux types de KDC : UNIX et Windows Active Directory.

L’option d’utiliser la méthode de faible authentification des versions NFS précédentes (AUTH_SYS) est toujours disponible si besoin est. Ceci peut être effectué en spécifiant sec=sys sur la ligne de la commande exportfs ou dans le fichier /etc/exports. Data ONTAP ne prend en charge qu’un maximum de 16 ID de groupe supplémentaires dans une authentification plus 1 ID de groupe primaire avec l'utilisation de AUTH_SYS. Un maximum de 32 ID supplémentaires de groupe est pris en charge avec Kerberos.

Délégations pour une mise en mémoire cache côté client

Dans NFSv3, les clients fonctionnent généralement comme s’il existait une contention pour les fichiers qu’ils ont ouverts (même si ce n’est pas souvent le cas). Une faible mémoire cache constante est maintenue par des requêtes fréquentes du client au serveur afin de découvrir si un fichier ouvert a été modifié par quelqu'un d'autre, ce qui peut causer un trafic réseau inutile et des retards dans des environnements à temps d’attente important. Dans les situations pour lesquelles un client détient un verrouillage de fichier, toute E/S d’écriture doit être synchrone, affectant davantage la performance côté client dans de nombreuses situations.

NFSv4 diffère des versions précédentes du NFS en autorisant un serveur à déléguer à un client des actions spécifiques sur un fichier afin de permettre une mise en cache plus agressive des données côté client ainsi que la mise en cache de l'état de verrouillage. Un serveur cède le contrôle des mises à jour de fichiers et de l'état de verrouillage à un client via une délégation. Le temps d’attente est réduit en autorisant le client à effectuer diverses opérations et de mettre des données en cache localement. Deux types de délégations existent actuellement : la lecture et l'écriture. Le serveur a la possibilité de rappeler la délégation d’un client en cas de contention d’un fichier.

Une fois qu’un client détient une délégation, il peut effectuer des opérations sur les fichiers dont les données ont été mises en cache localement afin d’éviter des lenteurs du réseau et d'optimiser les E/S. La mise en cache plus agressive résultant de délégations peut constituer un atout considérable pour les environnements dont les caractéristiques sont les suivantes :

  • Ouvertures et fermetures fréquentes
  • GETATTR fréquentes
  • Verrouillage de fichier
  • Partage en lecture uniquement
  • Temps d’attente important
  • Clients rapides
  • Serveur surchargé par de nombreux clients

Data ONTAP prend en charge les délégations de lecture et d'écriture et vous pouvez ajuster séparément le serveur du NFSv4 pour activer ou désactiver un seul ou les deux types de délégations. Lorsque les délégations sont activées, Data ONTAP attribuera automatiquement une délégation de lecture à un client qui ouvre un fichier pour une lecture, ou une délégation d’écriture en ouvrant un fichier pour l’écriture.

Les options d’activation ou de désactivation des délégations de droits de lecture et d’écriture ont été intégrées en vue d'offrir un certain niveau de contrôle sur l'impact des délégations. Pour une utilisation idéale, c’est le serveur qui détermine s'il fournit une délégation à un client ou non. L’activation de la délégation de lecture dans un environnement de lecture intensif sera bénéfique. Les délégations d’écriture dans des environnements de compilation dans lesquels l’utilisateur écrit afin de séparer des fichiers de compilation et dans lesquels il n’existe aucune contention amélioreront également la performance. Cependant, les délégations d’écriture peuvent ne pas être utiles lorsqu’il existe plusieurs auteurs du même fichier.

Pour en savoir plus

Si vous êtes intéressé par la sécurité des données (et qui ne le serait pas ?), les nouvelles fonctionnalités de NFSv4 telles que l’ACL et la sécurité obligatoire peuvent considérablement réduire le risque d’accès aux données non autorisées. La conception pour NFSv4 avait également pour objectif d’améliorer la performance avec Internet. L’amélioration du comportement de mise en cache client par les délégations nous a permis d’atteindre cet objectif.

Outre les modifications hautement visibles décrites, NFSv4 intègre un certain nombre de modifications notables dont :

  • l’élimination du montage daemon indépendant et d’autres services accessoires nécessitant des l’ouverture de ports supplémentaires
  • la requête composée regroupant plusieurs tâches usuelles en une opération unique afin d’accélérer les réponses et de réduire le trafic du réseau..

Si vous souhaitez en savoir plus sur ces fonctionnalités du NFSv4 ou d’autres fonctionnalités, TR-3085 offre une bonne référence générale.

author

Bikash R. Choudhury
Architecte de solutions informatiques
NetApp

Bikash a débuté chez NetApp il y a huit ans en tant qu'ingénieur support technique avant de devenir conseiller technique mondial (TGA) pour l'un des plus gros clients de NetApp. En tant que conseiller technique mondial, il a orienté ses efforts sur la construction de relations client solides ainsi que sur la conception de solutions techniques. Ses responsabilités actuelles convergent vers des solutions d’applications techniques utilisant NFS mais englobent également les tests, les certifications et le soutien à Global Partner Alliance pour les meilleures pratiques NFS.

Commenter cet article
Explore