NFS 4.1 approuvé : tout ce qu'il faut savoir sur pNFS
L'adoption récente du protocole NFS v4.1 par l'IETF signifie aussi les débuts de pNFS, la version parallèle du système de partage de fichiers en réseau, une mouture qui promet de doper de façon significative les performances tout en simplifiant grandement l'administration d'une infrastructure de partage de fichiers NFS.
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».
McClure estime que pNFS va accélérer l'adoption de NFS dans les entreprises. «[NFS] v4.1 devrait certainement accélérer la transition vers NFS en raison des services de fichiers parallèle», explique-t-elle. «C'est assez puissant. Cela permet notamment aux entreprises de surmonter certaines des limitations de bande passante quand ils essaient de servir de gros fichiers». Les organisations qui traitent fréquemment de gros fichiers devraient profiter le plus de pNFS, selon Bunce. Les applications qui effectuent des multitudes de petites transactions, tels que les systèmes de messagerie instantanée, ne verront pas vraiment d’amélioration, car la taille des fichiers est trop petite pour que la parallélisation des livraisons ait un quelconque impact. Reste que les fichiers n'auront pas à être massifs pour bénéficier de pNFS, explique Bunce. Ce dernier estime ainsi que des gains de performances apparaitront dès que la taille des fichiers dépassera 64 Ko.
Où en sont les fournisseurs?
Si le développement de Parallel Network File System (pNFS) ont été long, il va encore falloir patienter un peu pour voir la technologie incorporée dans des systèmes de stockage. Cela n’est pas parce que les fournisseurs ont été pris au dépourvu, mais plutôt parce que l’adoption de pNFS repose sur son support dans les systèmes d'exploitation. Parce que pNFS déporte un grand nombre de traitements sur le client, la plupart des fournisseurs sont contraints d’attendre que les développeurs d’OS incorpore le support de pNFS. Côté Linux, cela avance plutôt vite : tous les fournisseurs qui ont contribué au protocole NFSv4.1 et à la spécification pNFS - notamment EMC, NetApp et Panasas - travaillent avec les développeurs du noyau Linux pour terminer un client qui est stable et répond aux objectifs de performances. Selon Brad Bunce, le Projet Fedora sera le premier système d'exploitation Linux avec un client pNFS, suivie dans l’ordre par Red Hat Enterprise et le projet CentOS. Suse qui est très présent dans le monde du calcul scientifique, devrait suivre rapidement. Sun devrait aussi avoir rapidement une implémentation de pNFS dans OpenSolaris, un support préliminiare du standard étant disponible depuis le printemps 2009. Microsoft collabore quant à lui au développement d'un client NFS v4.1 open source pour Windows avec le centre pour les technologies informatiques de l'université du Michigan depuis 2009, mais n'a pas pour l'instant indiqué si ce pilote serait à terme embarqué dans Windows.
Selon Mike Eisler, il faudra attendre la mi-2011 pour voir les constructeurs adopter le protocole dans leurs serveurs de stockage. «L’explication est qu’il n’y a pas de raison de supporter un protocole côté serveur, si aucun client ne peut en tirer parti» explique Eisler.
Comment évoluera ensuite la technologie?
Pour le CTO et vice-président de NetApp, Brian Pawlowski - qui co-préside le groupe de travail Network File System 4 -, NFS v4.0 et NFS v4.1 pourraient constituer les fondations d’une technologie multi-fournisseurs et hétérogène de global namespace fédéré. Si un client fait une demande sur une certaine portion de l'espace de noms, et que les données que recherche le client ne sont pas dans cet espace, les serveurs NFSv4.0 et NFSv4.1 peuvent rediriger le client vers l'espace de noms optimal pour récupérer les données, même si cet espace de noms fait partie du système d'un autre fournisseur.
Pour Larry Jones, le vice-président du marketing de Panasas, pNFS présente un autre atout, celui de simplifier la gestion des serveurs de fichiers. «[PNFS] fournit une plate-forme idéale pour la consolidation de serveurs», affirme Jones. "Une autre façon de voir pNFS est de le considérer comme un système de ‘Scale-out NAS’. Au lieu d'avoir un unique serveur NAS, ce que permet pNFS est de consolider tout un tas de serveurs NAS. Vous n'avez plus à partir en chasse de vos données. Un point de montage peut vous suffire pour atteindre l’ensemble de ces données». Jones pense également que nombre d’administrateurs s'attendent à une amélioration des performances du fait de l’arrivée de pNFS, mais que les bénéfices en matière de simplicité d’administration «devraient vraiment les surprendre».
Côté NetApp, enfin, Eisler estime que le protocole pNFS sera également une aubaine pour le clustering de serveurs en général. "Vous obtenez tous les avantages en matière d’administration du clustering de stockage sans avoir à payer les habituels inconvénients de performance dont vous pâtiriez en l'absence d'un protocole plus agile comme pNFS».
Adapté d'un article en anglais de Todd Erickson, SearchStorage.com et enrichi par la rédaction du MagIT
A lire aussi sur leMagIT:
En savoir plus :
