RENPAR14 / ASF / SYMPA Hamamet, Tunisie, 10 13 avril 2002

Pierre Lombard, Yves Denneulin Laboratoire Informatique et Distribution - IMAG ENSIMAG - Antenne de Montbonnot - ZIRST 51 avenue Jean Kuntzmann, 38330 MONTBONNOT SAINT MARTIN, FRANCE pierre.lombard,yves.denneulin @imag.fr

R sum e e Les noeuds des grappes disposent souvent de disques qui sont principalement utilis s pour linstallation e du syst` me de base et pour les chiers temporaires. Lid e est dutiliser cet espace inutilis en offrant e e e une abstraction des moyens de stockages a lutilisateur, tout en etant distribu s sur diff rentes machines. ` e e Cet article pr sente limpl mentation dun serveur NFS distribu sappuyant sur une architecture a base e e e ` dun serveur de m tadonn es et de plusieurs serveurs dentr es/sorties (iods ) utilisant du spoong e e e UDP an de servir directement le client. Les premi` res performances du prototype d velopp a partir e e e` du serveur NFS Linux en mode utilisateur montrent des r sultats int ressants. e e Mots-cl s : grappes NFS distribu UDP spoong e e

1. Introduction Le parall lisme connat actuellement un fort d veloppement dans le domaine des clusters de types e e Beowulf (cf. [9]). De nombreux travaux ont et et sont effectu s en ce qui concerne lordonnancement, la e e r partition de charge, les environnements de programmation et d x cution ainsi que lacc` s a distance e e e e ` a ces ressources. ` Le domaine des syst` mes de chiers nest pas non plus en reste comme nous le montrons dans la partie e 2. Cependant, ces solutions ont les d fauts de leur qualit : elles offrent de nombreuses fonctionnalit s, e e e ce qui se traduit par une installation intrusive et une maintenance non triviale. Le syst` me que nous pr sentons dans cet article vise a fournir un serveur NFS purement logiciel qui e e ` r sout les probl` mes suivants : e e possibilit dexploiter lespace disque inutilis de plusieurs machines (nuds), e e offrir une vue unique des diff rents espaces disque, e avoir des performances sufsantes pour saturer les cartes r seau des noeuds, e conserver la m me conguration des clients (ne pas modier le protocole NFS) e Pour cela, nous avons d velopp a partir du serveur NFS Linux en espace utilisateur un serveur NFS e e` distribu compos dun serveur de m tadonn es et de serveurs dentr e/sortie (E/S) assurant le stoe e e e e ckage des donn es. Le code client demeurant du NFS standard, ils voient le serveur de m tadonn es e e e comme un serveur NFS classique et les r ponses aux requ tes dE/S viennent en fait directement des e e serveurs dE/S - gr ce a des techniques de spoong UDP. a ` Apr` s cette introduction, nous pr senterons quelques syst` mes de chiers distribu s au vu des probl` mes e e e e e qui nous int ressent. La section suivante d crira les principes de fonctionnement de notre solution, nfsp e e et sera suivie dune discussion sur les probl` mes techniques li s a notre impl mentation test. Les pree e ` e miers r sultats obtenus seront pr sent s puis nous conclurons et donnerons des extensions possibles a e e e ` ce travail.
Ce travail a et effectu dans le cadre du projet APACHE (CNRS, INPG, INRIA et UJF) et a utilis les ressources de la grappe e e e i-cluster ID/HP (http://icluster.imag.fr)

Serveur NFS distribu pour grappes de PCs e

2. Contexte Les syst` mes de chiers distribu tentent de r pondre a de nombreux probl` mes parmi lesquelles on e e e ` e trouve les performances (utilisation de caches), la scalabilit , la s curit des donn es (condentialit ou e e e e e int grit ). . . e e Larticle [3] recense plusieurs syst` mes de chiers en r seau ainsi que leur fonctionnement. Nous avons e e etudi ces syst` mes du point de vue de la disponibilit sous Linux (clusters de type Beowulf) ainsi que e e e de la simplicit dinstallation et dadministration. e La famille de type AFS (AFS, OpenAFS, CODA) est parmi les plus ancienne et fournit des moyens efcace de partager des donn es au sein dun SAN (cache sur disques locaux, support du mode d connect e e e pour CODA) . En revanche, linstallation et ladministration ne peuvent pas etre quali es de triviales. e Plusieurs autres syst` mes sont int ressants mais malheureusement non disponibles pour Linux ou bien e e les projets se sont termin s. On citera : xFS du projet NoW de Berkeley [10, 11], Swarm [7, 6], . . . e Un autre syst` me, PVFS [4], est developp depuis quelques ann es et vise a ofr un syst` me de e e e ` e chier distribu pour grappe se d composant en serveur de m tadonn es et en serveur de donn es. Ce e e e e e syst` mes a des atouts remarquables mais linstallation dun client n cessite le chargement dun nouveau e e module noyau an dassurer une int gration dans le VFS Linux. e Finalement, le classique serveur NFS est un logiciel simple a installer et bien connu des administra` teurs. La coh rence peut parfois sav rer malheureuse mais cela nemp che pas lindustrie de fournir e e e des serveurs NFS d di s a des prix elev s (solutions NAS). e e ` e Ainsi, aucun des syst` mes pr sent s na pu r pondre aux objectifs pr sent s dans la section 1. Cest e e e e e e ce constat qui a motiv le d veloppement dun serveur NFS avec une architecture inspir e de celle de e e e PVFS. 3. Pr sentation de nfsp e Dans cette section nous pr sentons notre proposition en partant de la description dun serveur NFS e traditionnel et en mettant en evidence les modications que nous avons effectu es pour mettre en uvre e notre proposition. 3.1. Fonctionnement dun serveur NFS Lapproche dun serveur NFS est une approche client-serveur classique : un multiples disques haute-performance qui sert des clients (cf. gure 1). gros serveur avec de

Disque HiPerf Disque HiPerf

serveur de mtadonnes

serveur
Disque HiPerf
1 4 2 5

client

client

iod+client 3 6

client

client

client

client

serveur nfsp

F IG . 1 Serveur NFS traditionnel

F IG . 2 Serveur NFSP

Linconv nient de cette approche est quelle est peu scalable - sauf investissement dans du mat riel e e d di (baies RAID, cartes GB) coutant plusieurs nuds - et est aussi quelque peu en d saccord avec e e e lid e du supercalculateur bon march . e e 2

iod

Cela ne r sout pas le probl` me de lespace disque inutilis (donc perdu) et disponible sur les nuds e e e dune grappe - espace qui peut atteindre plusieurs tera-octets sur des grappes r centes. . . Aussi, au e lieu davoir un serveur central tr` s puissant, avons-nous d compos le serveur NFS en plusieurs souse e e serveurs pouvant etre distribu s sur plusieurs machines. e Nous avons choisi de rester dans le cadre impos par le respect du protocole NFS an de limiter les e probl` mes li s a linstallation, le client etant tr` s souvent d j` utilis et disponible sur les syst` mes Linux e e ` e ea e e install s. Certains probl` mes techniques apparaissent et seront pr sent s dans la section 4. e e e e Le protocole NFS utilise des RPC Sun. Ceux-ci peuvent utiliser de lUDP ou du TCP, mais tr` s souvent e cest lUDP qui est choisi car, NFS a et concu pour etre un protocole sans etat ce qui se transpose e naturellement sur un mode de communication par UDP. Une cons quence de cette conception est que e la gestion des plantages des machines (clients ou serveurs) ne pose pas trop de probl` mes : une e requ te nayant pu etre trait e (parce que perdue par exemple) nit par etre r emise par le client. Une e e e fois le volume NFS mont e par le client, une pseudo connexion UDP est etablie ; le n-uplet (IPclient, Portclient, IPserver, PortServer) d nit le montage NFS. Les diff rentes requ tes sont alors distingu es e e e e par un num ro au niveau des requ tes RPC (xid) choisi par le client. e e 3.2. Architecture de NFSP De la m me mani` re que dans PVFS, nous utilisons un serveur de m tadonn es (nous lappellerons e e e e dor navant nfspd ) ainsi que des d mons dEntr es/Sorties (E/S) appel s iods . e e e e

stockage des metafichiers (IPs,*) to (IPi,PORTi) nfsd IPs:PORTs READ[IOD] /export

stockage des fichiers de donnes

iod IPi:PORTi

READRES [NFS] READ [NFS] (IPc,PORTc) to (IPs,PORTs) (IPs,PORTs) to (ipc,portc)

paquet UDP client IPc:PORTc mount t nfs server:/export /mnt/export IPs:PORTs: IP:port du serveur IPc:PORTc: IP:port du client IPi:PORTi: IP:port du dmon dE/S (iod)

F IG . 3 Fonctionnement dun serveur NFSP

Cette architecture est illustr e sur la gure 3. Les probl` mes pos s par lutilisation de ce serveur de e e e m tadonn es sont multiples. e e Le principal que nous avons eu a r soudre fut celui pos par le chemin de retour des acquittements et ` e e des donn es car a chaque requ te de type NFS doit correspondre une r ponse. Or le client ne connat e ` e e que le nfspd , par cons quent la r ponse doit (sembler) provenir de la machine qui h berge le nfspd . e e e Partant ce de constat, il semble naturellement plus judicieux de faire r pondre les iods en utilisant e des techniques de spoong UDP/IP. Celles-ci sont souvent utilis es dans dans le cas des attaques de e types d ni de service (DoS). De nombreuses r f rences sur cette technique etant disponibles sur les sites e ee de s curit r seau, nous mentionnerons simplement [5] a titre dinformation. Nous traitons les autres e e e ` probl` mes dans la section suivante qui pr sente en d tails limplantation r alis e. e e e e e 4. Notes techniques et impl mentation e Cette partie pr sente les aspects techniques li s a limpl mentation, notamment les fonctionnalit s moe e ` e e di es du d mon NFS. e e 3

4.1. Liens entre chiers, m tachiers, chiers de donn es e e An de stocker les chiers du client, nous utilisons des m tachiers et des chiers de donn es. e e Les m tachiers sont des chiers sur le nfspd , ils stockent les m tadonn es2 du chier du client. Cellese e e ci sont contenues dans le chier (la taille et la version actuelle - cf. 4.2) et dans les m tadonn es du e e m tachier (date de cr ation, permissions, etc. . . ). Evidemment, les op rations concernant les m tadonn es e e e e e (appel stat()) sont g r es directement par par le seul d mon nfspd . ee e Les chiers de donn es sont des chiers sur les iods qui correspondent a des portions (stripes) du e ` chier du client. Leur nom est de la forme i inode s cookie o offset 3 et permet a liod de trouver ` les donn es demand es a partir des informations transmises dans la requ te envoy e par le nfspd . e e ` e e Nous allons maintenant d crire le d roulement des op rations de base sur les chiers (cr ation, effacee e e e ment, lecture, ecriture) dans nfsp . 4.2. Cr ation dun chier e Lorsquun chier normal est cr e par le client, le m taserveur cr e un m tachier de m me nom. Ce e e e e e m tachier (en fait un simple chier sur le m taserveur) contient alors une partie des m tadonn es du e e e e chier de lutilisateur : un cookie qui sert a avoir une version du chier (n cessaire pour eviter que les iods ne servent des ` e donn es non a jour si linode du m tacher a et r allou e apr` s un effacement), e ` e e e e e la taille du chier de lutilisateur Le reste des m tadonn es (droits, dates, etc. . . ) est directement g r par le syst` me de chiers du m taserveur. e e ee e e Un chier est alors caract ris par son num ro dinode et par le cookie qui lui a et attribu . e e e e e 4.3. Effacement dun chier Dans le cas dun serveur NFS classique, le serveur a simplement a appeler lappel syst` me unlink() ` e et a renvoyer lacquittement de leffacement au client. ` Avec nfsp , cette etape est un peu plus d licate car les donn es stock es sur les iods doivent aussi etre e e e effac es sous peine de fuites despace disque. Lorsquun chier doit etre effac , le nombre de liens durs e e sur le m tachier est v ri : sil est sup rieur a 1 alors un simple unlink() du m tachier est effectu e e e e ` e e car il reste des donn es sur les iods qui peuvent etre jointes par un autre chier. Sil vaut 1, alors nous e devons prendre soin denvoyer a tous les iods une demande deffacement des donn es du chier de ` e lutilisateur. 4.4. Lecture Sur un serveur classique, la lecture seffectue en plusieurs phases : retrouver le chier local correspondant au handle NFS, v rier les permissions, e lire les donn es (offset , taille), e renvoyer ces donn es au client. e En utilisant nfsp , la requ te de lecture est envoy e au nfspd qui va effectuer les deux premi` res etapes. e e e Le m tachier va ensuite etre lu an de connatre les discrimants de la requ te (inode , offset , cookie ) puis e e liod destination va etre trouv en calculant un hash sur ces valeurs. e La requ te est transmise a liod concern enrichie des m tainformations (permissions, heures, ...) n cessaires e ` e e e pour g n rer la r ponse depuis liod . Celui-ci lit les donn es correspondantes et g n` re une r ponse e e e e e e e NFS a destination du client en se faisant passer pour le serveur, la r ponse semblant alors appartenir a ` e ` la pseudo-connexion UDP etablie entre le client et le m taserveur. e 4.5. Ecriture L criture utilise les m mes deux premi` res phases que celles de la lecture, la lecture etant ( videmment) e e e e remplac e par une ecriture, et le retour des donn es au client par un acquittement. e e Avec nfsp , la m me phase de recherche de liod devant stocker les donn es se produit. Les m tainformations e e e sont mises a jour et, une fois le destinataire trouv , elles lui sont transmises accompagn es des donn es ` e e e a ecrire. Liod va alors effectuer l criture puis renvoyer lacquittement au client en se faisant passer ` e
litt ralement : les e donn es sur les donn es e e , telles que la taille, la date de dernier acc` s, les permissions, etc. . . e le s vient de seed, qui correspond a un germe al atoire pour choisir un premier hote pour le striping ` e

pour le serveur. 5. Premiers r sultats e 5.1. Mat riel et logiciels utilis s e e Les tests pr sent s ont et effectu s sur des machines de la grappe ID/HP i-cluster 4 . Celles-ci sont e e e e concues autour dun P3-733Mhz et equip es 256MiB de RAM avec 300MiB de swap sur un disque IDE de e 15GB et dune carte ethernet a 100Mb/s. Au moment des tests, elles etaient install es en Mandrake 7.1 ` e ` munie dun noyau 2.4.4. A titre dinformation, le serveur NFS de la grappe est un P3-1Hz avec 512MiB de RAM et 1GiB de swap sur disques SCSI et dispose dun 2.4.5-xfs. 5.2. Etat du prototype Le prototype actuel sappuie en grande partie sur le code du serveur NFS Linux en espace utilisateur 5 qui a et impl ment il y a quelques ann es par Mark Shand, puis am lior par Donald Becker, Rick e e e e e e Sladkey, Orest Zborowski, Fred van Kempen, et Olaf Kirch. Il a peu evolu depuis 1998 (version 2.2) e mais constitue une base tr` s pratique an deffectuer des exp rimentations (par exemple ClusterNFS e e [2]) sur un serveur NFS. Parce quexclusivement en espace utilisateur, il est moins performant que le serveur NFS du noyau plantages durs sur la grappe distante. Une autre cons quence e Linux mais cela evite davoir des appr ciable est linstallation simpli e du serveur qui sinstalle comme une simple application. e e Le prototype a fonctionn pendant un mois sur li-cluster sans probl` me majeur et est disponible a e e ` lURL : http ://www-id.imag.fr/Laboratoire/Membres/Lombard Pierre/nfsp/ 5.3. Lectures concurrentes dun gros chier s quentiel e Le chier fait ici 1 GiB et a et cr e dans le cas de 16 iods en 110s soit 9,3MiB/s, ce qui est inf rieur au e e e maximum th orique (un peu plus de 11MiB/s) mais n anmoins satisfaisant puisque pour ecrire un tel e e chier sur le serveur NFS de la grappe 10 secondes de plus sont n cessaires (soit 8,5MiB/s). e An de lancer les clients rapidement en parall` le nous utilisons ka-run le lanceur parall` le des ka-tools 6 e e Les courbes 4 et 5 illustrent les r sultats obtenus. e

60

120

50

100

40 MiB/s MiB/s 0 2 4 6 8 10 12 14 16

80

30

60

20

40

10

20

0 Nombre de clients concurrents

0 0 5 10 15 20 25 30 35 Nombre de clients concurrents

F IG . 4 Bande passante cumul e (MiB/s) : 16 e iods sur 16 nuds, de 1 a 16 clients sur 16 ` nuds

F IG . 5 Bande passante cumul e (MiB/s) : 8 e iods sur 8 nuds, de 1 a 32 clients sur 16 ` nuds

Sur la courbe 4, nfsp est install sur 16 iods . La courbe croit fortement jusque vers 5-6 clients en pae
Voir http ://icluster.imag.fr ou Universal NFS Daemon - UNFSD http ://ka-tools.sf.net

rall` le puis stagne aux alentours de 50MiB/s - a ce moment le serveur de m tadonn es est satur (CPU). e ` e e e Nous navons pas encore effectu de mesures de proling plus nes an de savoir quelle part du nfspd e consomme le plus de ressources mais nous avons elimin plusieurs causes : gestion des m tachiers e e (moins de 10% de CPU), saturation r seau (moins de 2 MiB/s en entr e - idem en sortie). e e La gure 5 illustre les effets du cache au niveau des clients dans le cas ou plusieurs processus acc` dent ` e au m me chier. Dans ce test, 8 iods sur 8 machines sont utilis s, 16 machines clientes montent la e e partition export e et le nombre total de processus clients varie entre 1 et 32 (donc de 0 a 2 processus e ` clients par nud). Cette courbe pr sente les m mes tendances que la pr cedente (plateau a partir de 5-6 e e e ` clients) mais recommence a crotre une fois pass les 16 clients (i.e. 1 processus client par nud) car le ` e chier est d j` cach et donc accessible imm diatement. ea e e 6. Conclusion et travaux futurs Nous avons pr sent dans cet article une modication dun serveur NFS existant dans le but de le e e r partir sur plusieurs machines an daugmenter sa scalabilit . La proposition que nous avons pr sent e e e e e consiste en la s paration du serveur NFS en serveur de m tadonn es et de serveurs annexes de stockage. e e e Pour ce faire nous utilisons du spoong UDP an d viter aux r ponses de transiter via le serveur de e e m tadonn es. NFSP vise avant tout a etre simple a utiliser et a installer tout en essayant de fournir de e e ` ` ` bonnes performances en distribuant la charge des E/S sur plusieurs noeuds. Une evaluation plus pouss e est n cessaire mais limplantation actuelle gagnerait a mettre en place les e e ` techniques suivantes : utilisations de techniques plus avanc es pour les performances [1] e passage a NFSv3 qui r sout plusieurs limites de NFSv2 [8] : chiers de plus de 2GiB, plus dasyn` e chronisme (bien que cela pose le probl` me de la gestion des COMMIT dans un environnement dise tribu . . . ) e passer certaines parties en espace noyau an de minimiser le nombre de recopies m moire (zero-copy) e Dautres axes de recherches concernent lutilisation de techniques multicast en UDP car ces paquets sont g r es de mani` re hardware par les switchs r cents. Lajout dun support de reconguration a la vol e des ee e e ` e iods an de g rer larriv e ou le d part de nuds (un peu comme dans les syst` mes peer-to-peer) an e e e e daugmenter la capacit de stockage globale serait aussi un axe a etudier. e ` Bibliographie 1. The C10K problem (site web). http ://www.kegel.com/c10k.html. 2. ClusterNFS (site web). http ://clusternfs.sf.net. 3. Peter J. Braam. File systems for clusters from a protocol perspective. In Extreme Linux Workshop #2, USENIX Technical Conference. USENIX, June 1999. 4. Philip H. Carns, Walter B. Ligon III, Robert B. Bross, and Rajeev Thakur. PVFS : A parallel le system for linux clusters. 5. CERT. CA-1996-21 : TCP SYN ooding and IP spoong attacks. http ://www.cert.org/advisories/CA-1996-21.html, september 1996. 6. John H. Hartman, Ian Murdock, and Tammo Spalink. The swarm scalable storage system. In IEEE, editor, Proceedings of the 19th IEEE International Conference on Distributed Computing Systems. IEEE, 1999. 7. Ian Murdock and John H. Hartman. Swarm : A log-structured storage system for linux. In Proceedings of FREENIX Track : 2000 USENIX Annual Technical Conference, June 2000. 8. B. Pawlowski, C. Juszczak, P. Staubach, C. Smith, D. Lebel, and D. Hitz. NFS version 3, design and implementation. In Proceedings of the USENIX Summer 1994 Conference, pages 6579, June 1994. 9. T. Sterling, D. Savarese, D. J. Becker, J. E. Dorband, U. A. Ranawake, and C. V. Packer. BEOWULF : A parallel workstation for scientic computation. In Proceedings of the 24th International Conference on Parallel Processing, pages I :1114, Oconomowoc, WI, 1995. 10. Randolph Y. Wang and Thomas E. Anderson. xFS : A wide area mass storage le system. In Proceedings of the 4th Workshop on Workstation Operating System, 1993. 11. Randolph Y. Wang, Thomas E. Anderson, and Michael D. Dahlin. Experience with a distributed le system implementation. Technical Report CSD-98-986, January 1997. 6