NFS 4.1 approuvé : tout ce qu'il faut savoir sur pNFS 

Plus de deux ans après la publication par l'Internet Engineering Task Force (IETF) - via son groupe IESG (Internet Engineering Steering Group) - du dernier brouillon de la version 4.1 du protocole de partage de fichiers Network File System, l’IETF a publié dans le courant du mois de janvier 2010 la RFC5661 qui élève NFS 4.1 au range de standard. L’une des grandes nouveautés de cette mouture est le support de pNFS, la version parallèle du protocole. Faute de clients capables de supporter les spécifications pNFS, cette technologie est encore largement dans les starting blocks. Mais les premières implémentations commerciales devraient sans doute apparaitre en 2011 chez certains constructeurs et une adoption plus large est attendue en 2012.

Interrogé sur pNFS, Larry Jones, le vice-président du marketing de Panasas, l’un des constructeurs les plus en pointe lors du développement du protocole, explique que pNFS «va clairement doper considérablement les performances». En fait pour Jones, pNFS devrait profondément changer la façon d’accéder aux fichiers en laissant le client décider de la meilleure méthode à utiliser pour accéder aux serveurs de stockage.

pNFS fournira en effet trois modes différents d’accès au données (même si tous ne seront pas forcément supportés par l’ensemble des constructeurs). La RFC 5661 définit ainsi les accès en mode fichiers, tandis que la RFC 5663 définit les accès en mode bloc. Une troisième RFC, la 5664 spécifie enfin un mode d’accès en mode objet. Selon Jones, NetApp a été le principal contributeur de la technologie en mode fichier, tandis qu’ EMC a mené les développement de la version en mode blocs (pour Fibre Channel, iSCSI et Fibre Channel over Ethernet). Il est à noter qu’EMC s’est pour cela largement inspiré des développement d’HighRoad son système de fichier distribué rebaptisé MPFS. Enfin Panasas a largement développé la technologie d’accès en mode objet.

Quelles différences entre NFSv4 et NFSv4.1?

Pour l'un des directeurs techniques de NetApp, Mike Eisler, qui est aussi l’un des rédacteurs de la RFC 5661, la spécification NFS v4.1 est la plus volumineuse jamais publiée par l'IETF. Et l’une de ses grandes nouveautés est l’arrivée de pNFS, la version parallèle de NFS (qui sépare chemin de données et chemin pour les métadonnées).

Actuellement, les requêtes de fichiers via NFS - que ce soit avec NFSv3 ou NFSv4 - débutent par une requête d’un client logiciel vers un noeud NFS «arbitre». Ce noeud NFS détermine alors les nœuds de stockage qui contiennent les données demandées et assemble séquentiellement les données avant de les présenter au client. Le fait de ne s’appuyer que sur un seul nœud pour recueillir les données provenant de sources multiples pose toutefois plusieurs problèmes dont celui d’introduire de la latence et de nuire aux débits de transfert.

Avec NFSv4.1, c’est le client qui contrôle les requêtes de fichiers. Selon Jones Panasas, lorsque le client effectue une demande de données, il communique d'abord avec un serveur de métadonnées sur IP. Une fois que ce serveur de métadonnées a authentifié le client il lui présente une cartographie  des emplacements où se situent les données requises. Le client se charge alors de communiquer directement avec les nœuds appropriés sur le protocole de transport le plus adapté. et il peut ainsi collecter les données en parallèle depuis plusieurs noeud. Dans la pratique, une partie du travail qui incombé au serveur NFS incombe désormais au client. Vu de l’utilisateur, toutefois rien ne change vraiment, sinon les performances.

Les services de fichiers parallèles pourraient accroitre l'adoption de NFS

Terri McClure, une analyste senior chez Enterprise Strategy Group, explique de son côté que NFS v4.1 peut être considéré comme une architecture multichemins où les métadonnées liées au fichiers et les commandes sont transmises via un lien IP, tandis que les données elles-mêmes sont voyages au travers de l’infrastructure de stockage sous forme de fichiers, de blocs ou d’objets. Bred Bunce, le directeur du stockage unifié che EMC, indique que cette architecture à chemins séparés (split-paths) permet de doper les performances des services de fichiers tout en permettant une plus grande évolutivité et en repoussant les limites en matière de montée en charge. «[PNFS] sépare les requêtes de métadonnées et celles portant sur les données elles-mêmes pour permettre le parallélisme, ce qui vous donne plus de performances et d'évolutivité par rapport à la version 4.0 de la norme ou aux versions précédentes».