NetApp Tech OnTap
     

Accélérer l'accès aux données partagées
pour les clusters de calcul


L'accès aux données partagées est un facteur essentiel pour les performances des clusters de calcul actuels, lesquels exécutent des applications scientifiques, métier et d'ingénierie. NFS, la norme la plus utilisée pour partager l'accès aux données, peut s'avérer être un goulet d'étranglement dans les clusters de calcul de grande envergure, ces derniers pouvant saturer les serveurs de fichiers, point d'accès unique à tous les fichiers d'un système de fichiers partagé.

Figure 1) Les serveurs de fichiers NFS standard peuvent s'avérer être un goulet d'étranglement avec la croissance de votre cluster de calcul. Le temps de latence (L) augmente et atteint des niveaux inacceptables et quant au serveur, il atteint ses limites en termes de débit (T, throughput).

Malheureusement, la plupart des solutions disponibles aujourd'hui pour un accès aux données partagées plus performant sont toujours plus ou moins propriétaires. De plus, contrairement à des protocoles standard tels que NFS, ces solutions ne sont pas aussi performantes en termes de prise en charge de systèmes hétérogènes et ne sont pas non plus adoptées à une grande échelle.

Parallel NFS (pNFS) est une nouvelle norme, faisant partie des spécifications du protocole NFS version 4.1, répondant aux problématiques de goulets d'étranglement liés à l'utilisation de serveurs uniques. Très prometteuse, cette technologie pourrait bien devenir LA solution en termes d'accès parallèle aux données. Dans cet article, nous vous expliquons le fonctionnement de pNFS et l'état d'avancement du processus de normalisation.


Comprendre pNFS


Le protocole pNFS permet aux clients d'accéder directement aux fichiers répartis sur deux serveurs de données ou plus. En accédant de manière parallèle à plusieurs serveurs de données, les clients peuvent bénéficier d'E/S bien plus rapides. Le protocole pNFS a été conçu pour permettre un accroissement des performances en toute transparence par client et par fichier, sans nuire à la rétro-compatibilité avec le protocole NFS standard ; les clients sans l'extension pNFS pourront toujours accéder aux données.

L'architecture et les protocoles pNFS

L'architecture pNFS s'articule autour de trois composants principaux :
  • Le serveur de métadonnées (MDS), gérant tout le trafic autre que les données. Le serveur de métadonnées assure la maintenance des métadonnées, lesquelles décrivent l'emplacement et le mode de stockage de chaque fichier.
  • Les serveurs de données, stockant les données des fichiers et répondant directement aux demandes de lecture et d'écriture de la part des clients. Les données des fichiers peuvent être réparties sur plusieurs serveurs de données.
  • Un ou plusieurs clients à même d'accéder aux serveurs de données directement sur la base des informations contenues dans les métadonnées reçues du serveur de métadonnées.
Trois types de protocoles sont utilisés entre les clients, le serveur de métadonnées et les serveurs de données :
  • Un protocole de contrôle est utilisé entre le serveur de métadonnées et les serveurs de données pour assurer la synchronisation.
  • Le protocole pNFS est utilisé entre les clients et le serveur de métadonnées. Il s'agit essentiellement du protocole NFS version 4 auquel s'ajoutent des extensions spécifiques à pNFS. Ce protocole sert à récupérer et manipuler les agencements, contenant les métadonnées indiquant l'emplacement et le protocole d'accès au stockage requis pour accéder aux fichiers stockés sur différents serveurs de données.
  • Un ensemble de protocoles d'accès au stockage utilisés par les clients pour accéder directement aux serveurs de données. La spécification pNFS comporte actuellement trois catégories de protocoles de stockage basés sur les fichiers, les blocs ou les objets. Ces protocoles permettent à pNFS de gérer différents types d'agencements pour la prise en charge de différents types d'infrastructures de stockage.

Types d'agencements

Le choix du protocole d'accès au stockage dépend du type de stockage utilisé sur les serveurs de données sous-jacents. L'agencement correspondant à un fichier envoyé par le serveur de métadonnées à un client fournit à ce dernier les informations nécessaires pour déterminer où se trouve chaque "morceau" d'un fichier, comment y accéder et quel protocole utiliser.

  • Si l'agencement par fichiers est utilisé, pNFS fait appel à plusieurs serveurs de fichiers NFS v4.1 comme serveurs de données. Le protocole NFS v4 est utilisé pour accéder aux fichiers.
  • Lorsque l'agencement par blocs est utilisé, les LUN des disques sont hébergés sur un SAN. Le protocole iSCSI ou Fibre Channel est utilisé pour accéder aux équipements SAN utilisant le jeu de commandes par blocs SCSI.
  • L'agencement par objets permet aux données d'être stockées sur des équipements de stockage basés sur les objets (OSD). L'accès s'effectue via le protocole T-10 actuellement en phase de normalisation.
Exemple d'accès aux fichiers

Figure 2) Les différentes composantes de pNFS. Les clients adressent une requête au serveur de métadonnées concernant l'agencement (1, protocole pNFS) puis accèdent directement aux serveurs de données (2, protocole d'accès au stockage).

Quel que soit le type d'agencement des données, pour accéder à un fichier, un client contacte le serveur de métadonnées pour pouvoir ouvrir un fichier et demander l'agencement de ce fichier. Une fois que le client a reçu l'agencement du fichier, il utilise cette information pour procéder directement aux E/S vers et depuis les serveurs de données, de manière parallèle, en utilisant le protocole d'accès au stockage sans devoir recourir à nouveau au serveur de métadonnées. Lorsque le client a terminé ses E/S, il envoie des métadonnées modifiées au serveur de métadonnées et ferme le fichier.

Choisir le type d'agencement

Voici quelques critères à prendre en compte lors du choix de l'agencement à utiliser avec pNFS :

Point de départ

  • Si vous disposez d'une infrastructure NAS, un agencement par fichiers représente l'option la plus judicieuse. Vous pouvez utiliser vos systèmes NAS et vos réseaux existants.
  • Si vous utilisez déjà un SAN Fibre Channel, il est sans doute préférable d'opter pour un agencement par blocs.
  • Si vous commencez à partir de zéro, poursuivez votre lecture.

Infrastructure réseau

  • Avec un agencement par fichiers, il est possible d'utiliser vos systèmes de stockage NAS et votre infrastructure Ethernet existants. L'ajout de bande passante n'est pas absolument nécessaire.
  • Avec un agencement par blocs ou par objets, vous disposerez très certainement d'un réseau SAN (Storage Area Network) Fibre Channel. Tous les clients devront se connecter au SAN FC pour accéder directement aux serveurs de données. La technologie iSCSI peut s'avérer être une alternative moins onéreuse.

Sécurité

  • Sur un système "back end" basé sur les fichiers, la sécurité est assurée par chaque serveur de données, selon les mêmes méthodes qu'un serveur NFS standard, notamment via l'authentification Kerberos, les ACL, etc. La sécurité est bien appréhendée et maîtrisée.
  • L'utilisation de pNFS sur un système "back end" basé sur les blocs ou les objets implique que les clients se chargent de la sécurité. Étant donné que le client fait partie intégrante du système d'exploitation du poste client, il y a peu de contrôle sur la sécurité voire aucun pour ainsi dire. En d'autres termes, vous n'aurez peut-être pas beaucoup de choix pour choisir les mises en œuvre client. Il sera peut-être préférable d'opter pour un agencement dans lequel les serveurs de données sont en charge de la sécurité.

Accès simultané de plusieurs clients et gestion

  • Avec un agencement par fichiers, deux clients pNFS différents peuvent accéder à la même zone logique du même fichier en lecture ou en écriture.
  • Avec un agencement par blocs ou par objets, un seul client pNFS à la fois peut s'approprier un agencement inscriptible correspondant à une zone ou un fichier.

Disponibilité des "briques de base"

  • Les sources disponibles pour les systèmes de stockage "back end" basés sur les objets peuvent être restreintes.

État actuel de pNFS


Le standard pNFS

Les efforts en matière de normalisation de NFSv4.1, dont pNFS fait partie, sont une initiative d'envergure de l'IETF (Internet Engineering Task Force). Les membres du groupe de travail sont représentatifs des fournisseurs leaders dans le domaine du stockage et des systèmes et de laboratoires de recherche, tels que NetApp, EMC, IBM, l'Université du Michigan et Sun Microsystems. Le standard NFSv4.1 et pNFS sont à un stade avancé de normalisation, et il est prévu que l'IETF finalise les spécifications avant fin 2008.

NetApp a été un levier important tant pour NFSv4.1 que pNFS, assurant la co-présidence du groupe de travail. De plus, NetApp a rédigé la spécification NFSv4.1 et a assuré une grande partie des modifications. Cette démarche s'inscrit de manière cohérente avec notre engagement à résoudre les problèmes de stockage via les normes de l'industrie.

Pour plus d'informations sur la spécification IETF pour NFSv4.1 et pNFS, consultez le site Web du groupe de travail NFS v4 de l'IETF.

Tests de NFSV4.1/pNFS

L'interopérabilité est un critère essentiel à l'adoption de pNFS, comme cela a été le cas pour NFS. Une interaction transparente des mises en œuvre client et serveur accélérera l'adoption. Des tests d'interopérabilité de diverses mises en œuvre de pNFS ont lieu depuis mars 2005. NFSv4.1 et pNFS ont été testés lors du forum annuel Connectathon, un forum indépendant consacré aux tests d'interopérabilité du matériel et des logiciels.

Par ailleurs, des événements "Bake-a-thons" ont lieu plusieurs fois par an. Le plus récent s'est tenu en septembre 2008. Six déploiements serveur et deux déploiements client de pNFS ont été testés. Aucun problème n'a été rencontré tant au niveau des spécifications NFSv4.1 que pNFS ; la maturation du protocole se poursuit avec succès. Vous trouverez l'état d'avancement des tests pNFS sur le blog NFS de Mike.

Développement des clients et serveurs pour Linux

En raison de l'hégémonie de Linux® dans les clusters de calcul utilisés par nombre d'applications scientifiques, d'ingénierie et diverses, lesquelles tirent le plus profit de pNFS, il est important de disposer d'un client pNFS pour Linux très bien conçu et ayant fait l'objet de tests exhaustifs, et ce, afin de répondre aux exigences de ces applications en termes de performances. NetApp et d'autres acteurs du marché ont tenu compte de ce besoin et investissent dans la création d'un client pNFS Linux robuste. À mesure que ce client gagne en maturité, la mise en œuvre sera intégrée au noyau Linux généraliste. Cela permettra à pNFS d'être utilisé sur des machines Linux sans devoir installer ni maintenir de logiciels supplémentaires.

NetApp contribue fortement au développement du client pNFS et du pilote d'agencement de fichiers et développe également une version serveur pour Linux. Le fait de disposer d'un serveur pNFS simple parallèlement au client offrira aux utilisateurs optant pour pNFS une plate-forme complète pour les tests, les démonstrations de principe (POC) et la familiarisation avec ces technologies.

Conclusion

Avec une norme reconnue en phase de validation finale, le soutien important de nombreux acteurs du marché, et la capacité à tirer profit de l'infrastructure de stockage existante, pNFS est bien parti pour devenir une norme qui sera largement adoptée, pour qui veut bénéficier d'E/S parallèles hautes performances à même de répondre aux besoins des applications nécessitant davantage de performances d'E/S que ne peut en offrir un serveur de fichiers unique.

Des avis ou des commentaires à propos de pNFS ?

Posez vos questions, échangez des idées et faites part de vos opinions en ligne dans les communautés NetApp.
Mike Eisler

Mike Eisler
Senior Technical Director
NetApp

Mike dirige les travaux de développement de NFS chez NetApp. Il est l'auteur de la spécification NFSv4 et d'autres spécifications en lien avec NFS et la sécurité. C'est chez Lachman Associates, Inc. que Mike a découvert concrètement NFS et NIS. Il était en effet en charge du portage de NFS et de NIS sur les plates-formes System V. Il a intégré NetApp après Sun, où il était responsable de plusieurs projets liés à NFS et à la sécurité.

Joshua Konkle

Joshua Konkle
Technical Evangelist pour les NAS et les applications d'ingénierie
NetApp

Joshua est un fervent militant des technologies et des solutions aidant les clients à être plus productifs. Rompu aux systèmes UNIX® et Windows®, et plus particulièrement au niveau sécurité, il est intervenu à l'occasion de séminaires techniques et spécialisés sur des sujets tels que le stockage et la sécurité informatique.

Explorer