Stockage distribué sous Linux

Transcription

1 Institut Universitaire de Technologie Nancy-Charlemagne Licence Professionnelle Administration de Systèmes, Réseaux et Applications à base de Logiciels Libres Tuteur de projet : Stéphane Casset Stockage distribué sous Linux Félix - Simon Ludovic - Gauthier Nancy, 1 er avril 2009

2 Table des matières Introduction 3 1 État de l art Les plus utilisés Andrew File System Ceph Coda Lustre POHMELFS Le reste Global File System GlusterFS General Parallel File System HAMMER Infinit Parallel Virtual File System OneFS Les plus prometeurs Mise en place Andrew File System Pré-requis et informations Installation Configuration Conclusion sur OpenAFS : Coda Côté serveur Côté client Global File System Prérequis Configuration Création des partitions Utilisation Ceph Ceux que l on garde Évaluation des performances 26 Conclusion 27 Webographie 28 2

3 Introduction Un système de fichier distribué est un système de fichier réparti sur plusieurs ordinateurs de manière à ce que les clients de cet espace de stockage ne le voit que comme un seul et énorme disque dur. Cette technologie étant utilisée pour les problèmes de haute disponibilité des données, quels sont les systèmes de fichier distribués existant sous GNU/Linux et quels sont les plus interessants à mettre en œuvre? Nous allons faire un petit tour de l état de l art pour voir quelques uns de ces systèmes de fichiers, puis nous en retiendrons un échantillon réduit pour un test de mise en application. Enfin nous ferons un test plus approfondi des plus prometteurs. 3

4 Chapitre 1 État de l art 1.1 Les plus utilisés Andrew File System AFS est un système de fichier distribué, il offre une architecture client-serveur pour un partage de fichiers et une réplication de contenu. Il est dimensionable, sécurisé, décentralisé et offre des possibilités de migration. AFS est disponible pour une palette de systèmes hétérogènes : UNIX, Linux, MacOS X et Microsoft Windows. IBM maintient une branche des sources du produit AFS, disponible pour la communauté : OpenAFS Ceph Le principal but de Ceph est d être compatible à POSIX et d être distribué sans aucun bug. Ceph en est encore à sa version alpha est n est pas prêt pour être mis en production. Le serveur tourne comme n importe quel daemon UNIX. Ceph utilise trois types de daemons différents : Cluster monitors, qui gardent une trace des noeuds de cluster actifs ou défaillants. Metadata servers (MDS), qui gèrent la charge de travail en fonction de l accès aux fichiers. Il s adapte en fonction de la taille ou de la popularité des fichiers. Object storage devices (OSDs), qui gèrent le contenu des fichiers. Les OSDs utilisent un format de stockage particulier appelé EBOFS. Ils peuvent tous être exécutés sur le même jeu de serveurs. Les clients interagissent directement avec tous les serveurs. Comme beaucoup de systèmes de fichiers distribués, Ceph utilise le stripping pour gérer les fichiers et assurer de meilleures performances (similaires au RAID 0). Une future extension en projet prévoit un équilibrage de charge, notamment pour les objets les plus souvent sollicités qui pourront être répliqué sur plusieurs noeuds. Ceph est conçu pour supporter clients accédant au même fichier ou écrivant dans le même répertoire Coda Coda est un système de fichier distribué qui puise ses origines dans AFS2. Il permet les opérations déconnectées pour l utilisation itinérante. Il offre une haute performance coté client avec un cache persistant. Les serveurs sont réplicables, leur accès est restreint par authentification Lustre Lustre est un projet libre (GPL) de système de fichier distribué basé sur des objets. Son nom vient du mélange des mots «Linux» et «cluster». Le projet a débuté en 1999 et, depuis 2007, c est 4

5 Sun Microsystems qui le développe et le maintiens. Quinze des trente plus gros super-ordinateurs du monde utilisent Lustre. RedHat et SUSE fournissent des noyaux qui permettent de le faire fonctionner directement. Ce système de fichier à été conçu pour pouvoir accueillir des dizaines de milliers de nœuds et comprendre plusieurs pétaoctets 1 sans perte significative de vitesse. Lustre peut fournir son service à des dizaines de milliers de clients et atteindre des vitesses de l ordre des centaines de gigaoctets par seconde tout en proposant une haute extensibilité, la segmentation des données 2 et une haute disponibilité. Le logiciel comprends un serveur de métadonnées (MDS 3 ), plusieurs serveurs de données (OSS 4 ) et des clients. Le groupe MDS/OSSs peut évidemment être répété plusieurs fois par grappe de nœuds. Lustre se base sur son protocole réseau LNET pour ses échanges et LNET supporte plusieurs protocoles dont TCP/IP 5, InfiniBand, Myrinet, Quadrics et quelques autres. Lustre peut être utilisé en tant que module noyau ou dans l espace utilisateur grâce à la liblustre. Ce système de fichier utilise actuellement ext3 mais Lustre 3 devrait offrir le choix entre ZFS et ldiskfs POHMELFS POHMELFS signifie Parallel Optimized Host Message Exchange Layered File System. POHMELFS est un client noyau développé pour les système de fichiers distribué par internet de manière parallèle. A l heure actuelle c est un système de fichiers réseau à haute performances. Il est dit parallèle car il est capable de lire des informations depuis plusieurs hôtes et d écrire des informations sur différent nœuds réseau. Cette gestion multitâche n est pas assuré par le client POHMELFS mais par l application serveur. Il peut être utilisé comme solution de sauvegarde pour les serveurs réseaux distribués physiquement. Cette capacité à gérer ces sources de données depuis de multiples serveurs le désigne tout particulièrement pour des applications dans le domaine de la haute disponibilité. 1.2 Le reste Global File System GFS est un système de fichier Libre (GPL) dont le développement à débuté en 1997 et à été repris par RedHat en 2003 qui le développe, le maintient et le supporte 6. Global File System est original en le sens où chacun des nœuds est un un pair 7 et est autorisé à un accès concurrent aux ressources. Pour que ce système fonctionne optimalement il nécessite un gestionnaire de verrou tel GULM 8 ou DLM 9 qui est généralement préféré. Il est également possible d utiliser un gestionnaire «nolock» 1 Un pétaoctet contient octets, plus de 200 millions de DVD simples 2 Data stripping 3 MetaData Server 4 Object Storage Servers 5 Transmission Control Protocol/Internet Protocol 6 Le support de GFS par RedHat est payant 7 En opposition au modèle client/serveur 8 Grand Unified Lock Manager 9 Distributed Lock Manager 5

6 dans le cas où l on souhaite l utiliser sur une seule machine. Notons aussi que GFS2 inclut par défaut DLM GlusterFS GlusterFS est un système de fichiers distribué Libre (GPL v.3) ayant une capacité de plusieurs petaoctets. Ce système de fichiers est conçu de manière très modulaire (à la HURD) et la réplication des fichier est automatique. Il est possible de segmenter les données et le logiciel n est pas conçu comme un module du noyau Linux, il utilise FUSE 10. GlusterFS est un des rares logiciels de ce type qui supporte plusieurs protocoles de communication, tels TCP/IP, InfiniBand, SDP 11 ou UDS 12. Le principe de fonctionnement est d établir un serveur (glusterfsd) sur chaque nœud de la grappe, et de s y connecter via un client (FUSE) General Parallel File System Le General Parallel File System est un système de fichier conçu par IBM. Il est disponible sous Linux depuis Il est fait pour adresser de façon unique des volumes de données dépassant le pétaoctet et répartis sur un nombre de supports physiques pouvant dépasser le millier. Ce système de fichier se base sur les techniques du RAID. D une part le stripping pour les performances, et d autre part la tolérance de panne par redondance. La réplication et la technique de journalisation des accès en écriture sont intégrées aux méthodes d accès elles-mêmes. GPFS est le successeur des systèmes de fichiers Tiger Shark File System et Vesta File System. Vesta a été commercialisé en 1994 et GPFS lui a succédé en 1998 en rendant toutes les fonctions de support de hautes performances transparentes. GPFS fournit un système performant en rendant accessible les données par de multiples ordinateurs en même temps. GPFS fournit également de bonnes performances grâce son système de "stripping", similaire au RAID, en prenant des blocs de données d un même fichier sur plusieurs disques. D autres fonctionnalités de GPFS sont la haute disponibilité, le support de clusters hétérogènes, la récupération de données,... Information Lifecycle Management (ILM) Tools : Cet outil permet de gérer la répartition des fichiers sur le cluster, en fonction des pools de stockages. Il y a deux fonctionnalités principales : File placement et File management. File Placement : Cette fonctionnalité dirige les fichiers de données vers certains pools de stockage en fonction d une politique définit. Cette politique peut être définit en fonction du nom du fichier, en fonction de l utilisateur,... File Management : Cette fonctionnalité permet de transférer des données d un pool de stockage à un autre, si des données ont besoin d être transférés sur un pool plus performant par exemple. Cette fonctionnalité est basé sur une politique qui s appuie sur les attributs des données comme la date du dernier accès, la taille du fichier, Filesystem in Userspace 11 Sockets Direct Protocol 12 Unix Domain Socket ou IPC Socket 6

7 1.2.4 HAMMER DragonFlyBSD est un fork d un projet Unix : FreeBSD 4.8. Ce projet est sous la direction de Matt Dillon, qui est également le contributeur principal du systeme de fichier HAMMER. HAMMER est le système de fichiers par défaut sous DragonFlyBSD. Ce projet a vu le jour suite au nouveau système de threading et SMP mis en place dans FreeBSD 5.0. Matt Dillon ne le trouvant pas adapté à commencé a développer DragonFlyBSD afin d apporter une solution qu il jugeait plus adéquate. HAMMER est un système de fichiers de nouvelle génération. Il reprends un grand nombre de spécification de ZFS : partitions de très grandes tailles (jusqu à 1exabit, c est à dire 1024 pétabits en sachant qu un pétabits=1024térabits. Ce qui au vu de la taille des plus gros disque durs actuellement laisse un peu de marge), récupération avancée et rapide des données, création d instantanés facilement accessibles, mirroring, clichés, opération multi-volume, self healing, etc. HAMMER n est pas conçu pour de petite partitions (hormis pour des tests) en effet il a besoin de plusieurs centaine de mégabits (dépends de la taille totale de la partitions) qui sert de buffer pour le reblocker. C est un système de fichiers a 64 bit a Haute Disponibilité à répartition (clustering) basé sur des arbres B. Un arbre B est un arbre équilibré utilisé principalement pour la gestion de base de donnée et de système de fichiers. C est une arborescence qui permet de stocker des index. L arbre est équilibré ce qui signifie qu il comprends le même nombre de niveaux dans chaque branche. L avantage d un arbre équilibré c est qu une recherche sur ce type d arbre à une durée constante. Il n y a pas de portage de HAMMER sous d autre système pour l instant mais son concepteur reste ouvert à toute personne voulant porté ce système de fichiers sous un autre OS Infinit C est un système de fichiers développé par l université de Cambridge. Il a la particularité d être un système de fichier utilisant un modèle peer to peer pour le transfert d informations. Le peer to peer (ou pair à pair en français souvent abrégé p2p) est un modèle de réseau informatique qui s oppose radicalement au modèle client-serveur. En effet a la différence du modèle client serveur (ou un serveur possède les données et les clients demande au serveur les données), dans le modèle p2p tout les pairs sont à la fois clients et serveurs. Ils possèdent et demandent les mêmes ressources. Ce modèle permet d éviter que la panne d un serveur immobilise une architecture réseau. Il y a donc décentralisation des systèmes. Ce modèle a donc des prédisposition évidentes pour la haute disponibilité. C est donc une solution innovante et très intéressante. De plus l agent Infinit fonctionne comme un agent ssh. Les données sont cryptés et l obtention d une clé et nécessaire pour qu un pair puisse fonctionner. Ce qui renforce l aspect sécuritaire de ce type de système.elle avait retenu mon attention (je comptais la mettre en place afin de faire des tests de performance), mais le site internet qui lui est consacré est très peu renseigné. Il s agit plus d un sujet de recherche que d un système de fichiers à proprement parlé Parallel Virtual File System Le Parallel Virtual File System est système de fichier Open Source. Un système de fichier parallèle est un système de fichier qui distribue des données depuis plusieurs serveurs et fournit un accès à une ou plusieurs applications en parallèle. Le développement de PVFS a été lancé (entre autres) par la NASA. PVFS se compose d un processus serveur et d une librairie de clients. Un noyau Linux et un pro- 7

8 cessus client PVFS permettent au système de fichier d être monté avec les utilitaires standards. La librairie de clients fournit de bonnes performances d accès grâce au Message Passing Interface (MPI). MPI est une API qui permet à plusieurs ordinateurs de communiquer ensemble. MPI est spécifiquement utilisé pour les clusters. PVFS a été conçu pour être simple à déployer et à administré. Il s installe sur de nombreuses distributions Linux et n a que quelques dépendances. PVFS n a pas besoin d un noyau spécifique ou de patcher celui-ci pour tourner. PVFS se sert de la cohérence de POSIX pour améliorer sa stabilité et ses performances OneFS OneFS est un système de fichier combinant trois couches : système de fichier, gestionnaire de volume et RAID. OneFS permet un dimensionnement indépendant ou linéaire. Lecture possible : 20GigaB/s Capacité max : 2,3PetaB Accès rapide pour les gros fichiers. Haute disponibilité. 1.3 Les plus prometeurs Nous avons choisi de conserver AFS, Coda, Ceph et Lustre en raison de leur forte utilisation et GFS parce qu il est basé sur une architecture pair à pair. À part Coda les trois autres sont empaquetés sous Debian ce qui réduira sans doute les problèmes de déploiement. 8

9 Chapitre 2 Mise en place 2.1 Andrew File System Pré-requis et informations AFS est une architecture client-serveur qui donne un accès transparent au fichier racine /afs/. AFS utilise Kerberos comme système d authentification. Et sans un ticket Kerberos valide, il est impossible d accéder au système AFS. Même en étant administrateur du système. AFS n exporte pas les partitions de données comme le ferait NFS. AFS nécessite des partitions dédiées à son utilisation. Pour être accessible, les volumes AFS doivent être montés dans la racine du système (/afs/). Les repertoires présents dans /afs/ ne correspondent pas à des mount au sens Unix du terme. Le seul point de montage Unix est le répertoire /afs/. Les permissions d accès sont plus finement gérés par rapport aux droits Unix classiques, grâce à des ACL. Des ACL basés sur les IP sont également paramétrables, pour les cas où il n y aurait pas d autres options. Les ACL sont définies sur les répertoires et s appliquent à la sous-arborescence. AFS est disponible pour les plateformes suivantes : IBM AIX, HP/UX, SGI Irix, MacOS X, Sun Solaris, toutes les plateformes Linux, et Microsoft Windows. Le serveur sera installé sur une machine ayant pour adresse IP : Le client aura pour adresse IP : On ajoutera donc ces lignes au fichier /etc/hosts : eee.ludo.fr eee krb1.ludo.fr krb1 afs1.ludo.fr afs Installation Il faut tout d abord installer module-assistant. Ce programme permet, comme son nom l indique, de compiler des modules pour votre noyau linux en tout simplicité. C est ici le cas pour le module OpenAFS. sudo apt-get install module-assistant sudo m-a prepare openafs sudo m-a a-i openafs On peut maintenant installer l ensemble des paquets pour OpenAFS : sudo apt-get install openafs-{fileserver,dbserver,client,krb5} Pour les questions lors de l installation, on répondra de la manière suivante : AFS cell this workstation belongs to: ludo.fr # (Your domain name in lowercase, matching the Kerberos realm in uppercase) Size of AFS cache in kb? # (Default value is for 50 MB, but you can greatly increase the # size on modern systems to a few gigabytes, with (20 GB) being # the upper reasonable limit) Run Openafs client now and at boot? No # (It is important to say NO at this point, or the client will try to 9

10 # start without the servers in place) Look up AFS cells in DNS? Yes Encrypt authenticated traffic with AFS fileserver? No # (OpenAFS client can encrypt the communication with the fileserver. The # performance hit is not too great to refrain from using encryption, but # generally, disable it on local and trusted-connection clients, and # enable it on clients using insecure channels) Dynamically generate the contents of /afs? No Use fakestat to avoid hangs when listing /afs? Yes Cell this server serves files for: ludo.fr DB server host names for your home cell: afs1 # (Before continuing, make sure you ve edited your DNS configuration or # /etc/hosts file as mentioned above in the section "Conventions", and # that the command ping afs1 really does successfully ping your server) Il est nécessaire de créer un principal Kerberos et d avoir créer au préalable dans Kerberos une politique service. sudo rm -f /tmp/afs.keytab sudo kadmin.local Authenticating as principal root/admin@ludo.fr with password. kadmin.local: addprinc -policy service -randkey -e des-cbc-crc:v4 afs Principal "afs@ludo.fr" created. kadmin.local: ktadd -k /tmp/afs.keytab -e des-cbc-crc:v4 afs Entry for principal afs with kvno 3, encryption type DES cbc mode with \ CRC-32 added to keytab WRFILE:/tmp/afs.keytab. kadmin.local: quit Une fois la clé crée et exporté dans le fichier /tmp/afs.keytab, il faut la charger dans AFS KeyFile. Le nombre 3 correspond à la version de la clé. sudo asetkey add 3 /tmp/afs.keytab afs Il faut vérifier que la clé a bien été chargé et qu il n y en a qu une seule dans AFS KeyFile grâce à la commande bos listkeys : sudo bos listkeys afs1 -localauth key 3 has cksum Keys last changed on Tue Feb 24 23:04: All done Configuration Nous avons vu que AFS utilise ses propres partitions dédiées. Chaque serveur peut avoir jusqu à 256 partitions qui doivent être montées dans des répertoires nommés /vicepxx/, où "XX" est l identifiant de la partition de "a" à "z" et de "aa" à "iv". 10

11 Dans notre cas, on utilisera une partition /vicepa/, formatée en ext3. Il est possible d utiliser ext2 ou ext3. Création d une nouvelle cellule : sudo afs-newcell Prerequisites In order to set up a new AFS cell, you must meet the following: 1)... 2)... 3)... 4)... 5)... Do you meet these requirements? [y/n] y If the fileserver is not running, this may hang for 30 seconds. /etc/init.d/openafs-fileserver stop What administrative principal should be used? root/admin /etc/openafs/server/cellservdb already exists, renaming to.old /etc/init.d/openafs-fileserver start Starting OpenAFS BOS server: bosserver. bos adduser afs.ludo.fr root -localauth Creating initial protection database. This will print some errors about an id already existing and a bad ubik magic. These errors can be safely ignored. pt_util: /var/lib/openafs/db/prdb.db0: Bad UBIK_MAGIC. Is 0 should be Ubik Version is: 2.0 bos create afs1.ludo.fr ptserver simple /usr/lib/openafs/ptserver \ -localauth bos create afs1.ludo.fr vlserver simple /usr/lib/openafs/vlserver \ -localauth bos create afs1.ludo.fr fs fs -cmd /usr/lib/openafs/fileserver -p 23 \ -busyat 600 -rxpck 400 -s l cb b 240 -vc 1200 \ -cmd /usr/lib/openafs/volserver -cmd /usr/lib/openafs/salvager \ -localauth bos setrestart afs1.ludo.fr -time never -general -localauth Waiting for database elections: done. vos create afs1.ludo.fr a root.afs -localauth Volume created on partition /vicepa of afs.ludo.fr /etc/init.d/openafs-client force-start Starting AFS services: afsd. 11

12 afsd: All AFS daemons started. Now, get tokens as root in the ludo.fr cell. Then, run afs-rootvol. La cellule est maintenant crée. Par convention, chaque cellule AFS crée un premier volume appelé root.afs. Comme écrit à la fin de la dernière commande, nous devons obtenir un ticket pour l administrateur AFS puis lancer afs-rootvol : kinit root/admin; aklog Password for root/admin@ludo.fr: PASSWORD afs-rootvol Une fois la commande terminée, nous avons notre cellule OpenAFS! Conclusion sur OpenAFS : OpenAFS est un système de fichiers distribués qui a été beaucoup utilisé et qui a fait ses preuves. Cependant, l architecture logiciel d OpenAFS est complexe. Chaque serveur à un rôle bien précis, et comme OpenAFS offre beaucoup de possibilités, le nombre de serveurs à mettre en place est important : File Server : gestion des entrés/sorties sur les fichiers Basic OverSeer Server (BOS Server) : vérification de la bonne marche des autres serveurs (lancement, terminaison,...) Authentification Server : gestion de l authentification de l utilisateur Protection Server : gestion des ACL Volume Server : gestion des volumes (création, suppression, déplacement,...) Volume Location Server : permet de retrouver sur quel serveur est situé un volume Update server : maintient à jour la version des serveurs Backup server : permet la sauvegarde complète du système de fichier Cache Manager : serveur spécifique au client, il maintient à jour le cache du client en fonction des requêtes de ce dernier Chaque serveur à sa propre configuration, ce qui rend la mise en place d un système avec OpenAFS très complexe. De plus, il est nécessaire d avoir un serveur Kerberos opérationnel pour le fonctionnement d OpenAFS, ce qui rend la mise en place encore plus complexe. 2.2 Coda Côté serveur Prérequis : Création de deux disques virtuels : $ mkdir /coda $ dd if=/dev/zero of=/coda/sdz0 bs=1m count= enregistrements lus enregistrements écrits octets (1,1 GB) copiés, 11,8537 seconde, 90,6 MB/s $ dd if=/dev/zero of=/coda/sdz1 bs=1m count= enregistrements lus enregistrements écrits octets (1,1 GB) copiés, 12,7182 seconde, 84,4 MB/s 12

13 Nous avons donc maintenant deux disques virtuels d une capacité de 1Go : /coda/sdz0 et /coda/sdz1 Informations sur le paquet coda-server : $ apt-cache show coda-server Package: coda-server Priority: optional Section: net Installed-Size: 5052 Maintainer: Jan Harkes <jaharkes@cs.cmu.edu> Architecture: i386 Source: coda Version: Depends: coda-update, rvm-tools, libc6 (>= ), libgcc1 (>= 1: ), liblwp2, libncurses5 (>= 5.4-5), libreadline5 (>= 5.2), librpc2-5, librvm1, libstdc++6 (>= ) Filename: coda/coda-server_6.9.4_i386.deb Size: MD5sum: 8c7751c18105dd008e78f672dd70116e SHA1: 5f51f9e41b815617e6377c6ccb4239f01160ee38 SHA256: 322b5e52e2a91b67169b1e75ca37a18bdf8d5bd7ab1ca38a059931e3c30dd0b2 Description: Server for the Coda distributed file system Coda is an advanced distributed filesystem. It has been developed at CMU by the systems group of M. Satyanarayanan in the SCS department. This package provides the binaries to set up a Coda server. For more information see Installation du paquet : $ apt-get install coda-server Configuration du serveur Coda : $ vice-setup Welcome to the Coda Server Setup script! Setting up config files for a coda server. Do you want the file /etc/coda/server.conf created? [yes] What is the root directory for your coda server(s)? [/vice] Setting up /vice. Directories under /vice are set up. Is this the master server, aka the SCM machine? (y/n) y Setting up tokens for authentication. The following token must be identical on all servers. Enter a random token for update authentication : ptutptut The following token must be identical on all servers. Enter a random token for auth2 authentication : ptutptut The following token must be identical on all servers. Enter a random token for volutil authentication : ptutptut tokens done! Setting up the file list for update client 13

14 Filelist for update ready. Now installing files specific to the SCM... Setting up servers file. Enter an id for the SCM server. (hostname codaserv1) The serverid is a unique number between 0 and 255. You should avoid 0, 127, and 255. serverid: 1 done! Setting up users and groups for Coda You need to give me a uid (not 0 or 1) and username (not root) for a Coda System:Administrator member on this server, (sort of a Coda super user) I will create the initial administrative user with Coda password "changeme". This user/password is only for authenticating with Coda and not for logging into your system (i.e. we don t use /etc/passwd authentication for Coda) Enter the uid of this user: 999 Enter the username of this user: admcoda A server needs a small log file or disk partition, preferrably on a disk by itself. It also needs a metadata file or partition of approx 4% of your filespace. Raw partitions have advantages because we can write to the disk faster, but we have to load a copy of the complete RVM data partition into memory. With files we can use a private mmap, which reduces memory pressure and speeds up server startup by several orders of magnitude. Servers with a smaller dataset but heavy write activity will probably benefit from partitions. Mostly read-only servers with a large dataset will definitely benefit from an RVM data file. Nobody has really measured where the breakeven point is, so I cannot really give any hard numbers WARNING: you are going to play with your partitions now. verify all answers you give WARNING: these choices are not easy to change once you are up and running. Are you ready to set up RVM? [yes/no] yes What will be your log file (or partition)? /coda/sdz0 The log size must be smaller than the available space in the log partition. A smaller log will be quicker to commit, but the log needs to be large enough to handle the largest transaction. A 14

15 larger log also allows for better optimizations. We recommend to keep the log under 30M log size, many people have successfully used as little as 2M, and 20M has worked well with our servers. What is your log size? (enter as e.g. 20M ) 20M Where is your data file (or partition)? /coda/sdz1 The amount of RVM we need to store the metadata for a given amount file space can vary enormously. If your typical data set consists of many small files, you definitely need more RVM, but if you tend to store large files (mp3s, videos or image data) we don t need all that much RVM. Here are some random samples, mp3 files ~0.08MB RVM per GB. jpeg images ~0.50MB RVM per GB. folders ~37.8MB RVM per GB (maildir, 1 file per message) netbsd-pkgsrc ~180MB RVM per GB (large tree but not much data) To get a more precize number for your dataset there is a small tool (rvmsizer) which can reasonably predict the amount of RVM data we need for a file tree. Remember that RVM data will have to be mmapped or loaded into memory, so if anything fails with an error like RVM_EINTERNAL you might have to add more swap space. What is the size of you data file (or partition) [32M, 64M, 128M, 256M, 512M, 768M, 1G]: 128M WARNING: DATA and LOG partitions are about to be wiped log area: /coda/sdz0, size 20M. --- data area: /coda/sdz1, size 128 MB. Proceed, and wipe out old data? [y/n] y LOG file has been initialized! Rdsinit will initialize data and log. This takes a while. rvm_initialize succeeded. Going to initialize data file to zero, could take awhile. done. rds_zap_heap completed successfully. rvm_terminate succeeded. RVM setup is done! Directories on the server will be used to store container files 15

16 that hold the actual data of files stored in Coda. Directory contents as well as metadata will be stored in the RVM segment that we already configured earlier. You should only have one container file hierarchy for each disk partition, otherwise the server will generate incorrect estimates about the actual amount of exportable disk space. Where shall we store your file data [/vicepa]? Shall I set up a vicetab entry for /vicepa (y/n) y Select the maximum number of files for the server. [256K, 1M, 2M, 16M]: 1M Server directory /vicepa is set up! Congratulations: your configuration is ready... Shall I try to get things started? (y/n) y - Coda authentication server (auth2 &) - Coda update server (updatesrv) - Coda update client (updateclnt -h codaserv1) Creating /vice/spool - Coda file server (startserver) Nice, it looks like everything went ok Now I ll try to create an initial root volume - createvol_rep / codaserv1/vicepa Replicated volumeid is 7f creating volume /.0 on codaserv1 (partition /vicepa) V_BindToServer: binding to host codaserv1 V_BindToServer: binding to host codaserv1 Set Log parameters Fetching volume lists from servers: V_BindToServer: binding to host codaserv1 GetVolumeList finished successfully codaserv1 - success V_BindToServer: binding to host codaserv1 VLDB completed. <echo / 7f >> /vice/db/vrlist.new> V_BindToServer: binding to host codaserv1 VRDB completed. Do you wish this volume to be Backed Up (y/n)? [n] That seems to have worked... If you have a working Coda client you should now be able to access the new Coda realm - cfs lv /coda/codaserv1/ enjoy Coda. for more information see 16

17 Réplication du serveur : Deux disques virtuels ont été créés sur le second serveur. Fichier /etc/hosts des deux serveurs : codaserv codaserv2 Configuration du réplicat : $ vice-setup Welcome to the Coda Server Setup script! You already have a file /etc/coda/server.conf! Continueing will remove that file. Do you want to continue? [yes/no] yes Setting up config files for a coda server. Do you want the file /etc/coda/server.conf created? [yes] What is the root directory for your coda server(s)? [/vice] Setting up /vice. Directories under /vice are set up. Is this the master server, aka the SCM machine? (y/n) n Enter the hostname of the SCM machine : codaserv1 Enter the update token that matches SCM codaserv1: ptutptut Fetching needed files from SCM codaserv1. Date: Tue 03/24/ :22:10 Fetch failed with Permission denied Done. Now installing things specific to non-scm machines... A server needs a small log file or disk partition, preferrably on a disk by itself. It also needs a metadata file or partition of approx 4% of your filespace. Raw partitions have advantages because we can write to the disk faster, but we have to load a copy of the complete RVM data partition into memory. With files we can use a private mmap, which reduces memory pressure and speeds up server startup by several orders of magnitude. Servers with a smaller dataset but heavy write activity will probably benefit from partitions. Mostly read-only servers with a large dataset will definitely benefit from an RVM data file. Nobody has really measured where the breakeven point is, so I cannot really give any hard numbers WARNING: you are going to play with your partitions now. verify all answers you give

18 WARNING: these choices are not easy to change once you are up and running. Are you ready to set up RVM? [yes/no] yes What will be your log file (or partition)? /coda/sdz0 The log size must be smaller than the available space in the log partition. A smaller log will be quicker to commit, but the log needs to be large enough to handle the largest transaction. A larger log also allows for better optimizations. We recommend to keep the log under 30M log size, many people have successfully used as little as 2M, and 20M has worked well with our servers. What is your log size? (enter as e.g. 20M ) 20M Where is your data file (or partition)? /coda/sdz1 The amount of RVM we need to store the metadata for a given amount file space can vary enormously. If your typical data set consists of many small files, you definitely need more RVM, but if you tend to store large files (mp3s, videos or image data) we don t need all that much RVM. Here are some random samples, mp3 files ~0.08MB RVM per GB. jpeg images ~0.50MB RVM per GB. folders ~37.8MB RVM per GB (maildir, 1 file per message) netbsd-pkgsrc ~180MB RVM per GB (large tree but not much data) To get a more precize number for your dataset there is a small tool (rvmsizer) which can reasonably predict the amount of RVM data we need for a file tree. Remember that RVM data will have to be mmapped or loaded into memory, so if anything fails with an error like RVM_EINTERNAL you might have to add more swap space. What is the size of you data file (or partition) [32M, 64M, 128M, 256M, 512M, 768M, 1G]: 128M WARNING: DATA and LOG partitions are about to be wiped log area: /coda/sdz0, size 20M. --- data area: /coda/sdz1, size 128 MB Proceed, and wipe out old data? [y/n] y LOG file has been initialized! Rdsinit will initialize data and log. This takes a while. rvm_initialize succeeded. 18

19 Going to initialize data file to zero, could take awhile. done. rds_zap_heap completed successfully. rvm_terminate succeeded. RVM setup is done! Directories on the server will be used to store container files that hold the actual data of files stored in Coda. Directory contents as well as metadata will be stored in the RVM segment that we already configured earlier. You should only have one container file hierarchy for each disk partition, otherwise the server will generate incorrect estimates about the actual amount of exportable disk space. Where shall we store your file data [/vicepa]? Shall I set up a vicetab entry for /vicepa (y/n) y Select the maximum number of files for the server. [256K, 1M, 2M, 16M]: 1M Server directory /vicepa is set up! You have set up linuxlap.arpagus.org Your SCM is codaserv1.arpagus.org Other config files will be fetched from the SCM by updateclnt. To finish your server setup you should start updateclnt as: updateclnt -h codaserv1.arpagus.org start the auth2 server as: auth2 -chk After that, there is still some configuration needed on the SCM before this server can be started. An entry for this host is needed in /vice/db/servers Then all servers need to be shut down and restarted, as they need to know about the new server. After all that it _should_ be ok to start the new server and create your first replicated volume. Fichier /vice/db/servers sur le serveur 1 : codaserv1 1 codaserv2 2 Fichier /vice/db/vsgdb sur les deux serveurs : E codaserv1 codaserv2 E est une adresse de volume. codaserv1:/home/slecaille# createvol_rep replicat codaserv1 linuxlap E Server E not in servers file 19

20 codaserv1:/home/slecaille# createvol_rep replicat codaserv1 linuxlap Replicated volumeid is 7f creating volume replicat.0 on codaserv1 (partition /vicepa) V_BindToServer: binding to host codaserv1 creating volume replicat.1 on linuxlap (partition /vicepa) V_BindToServer: binding to host linuxlap.arpagus.org Fetching volume lists from servers: V_BindToServer: binding to host linuxlap.arpagus.org GetVolumeList finished successfully linuxlap - success V_BindToServer: binding to host codaserv1 GetVolumeList finished successfully codaserv1 - success V_BindToServer: binding to host codaserv1 VLDB completed. <echo replicat 7f >> /vice/db/vrlist.new> V_BindToServer: binding to host codaserv1 VRDB completed. Do you wish this volume to be Backed Up (y/n)? [n] n Sur le serveur 2 : $ updatesrv $ updateclnt Creating /vice/spool $ codasrv Sur le serveur 1 : $ createvol_rep coda.rep foo bar gorp 7F Côté client Information sur le paquet coda-client : $ apt-cache show coda-client Package: coda-client Priority: optional Section: net Installed-Size: 4264 Maintainer: Jan Harkes <jaharkes@cs.cmu.edu> Architecture: i386 Source: coda Version: Depends: libc6 (>= ), libgcc1 (>= 1: ), liblwp2, libncurses5 (>= 5.4-5), libreadline5 (>= 5.2), librpc2-5, librvm1, libstdc++6 (>= ) Pre-Depends: debconf (>= ) Suggests: python-gtk2 Filename: coda/coda-client_6.9.4_i386.deb Size: MD5sum: c1f8be25356a933862fa269ee SHA1: 4e7492f86f28b3caa38987dc3fd9acce285e4663 SHA256: 279dd8775cc0d99e0f7a6b8febc0c87288c304d01096dca4fb7719f Description: Client for the Coda distributed file system 20