Stockage distribué sous Linux

Transcription

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, 1er avril 2009
Table des matières
Introduction
3
1 État de l’art
1.1 Les plus utilisés . . . . . . . . . . . .
1.1.1 Andrew File System . . . . .
1.1.2 Ceph . . . . . . . . . . . . . .
1.1.3 Coda . . . . . . . . . . . . . .
1.1.4 Lustre . . . . . . . . . . . . .
1.1.5 POHMELFS . . . . . . . . .
1.2 Le reste . . . . . . . . . . . . . . . .
1.2.1 Global File System . . . . . .
1.2.2 GlusterFS . . . . . . . . . . .
1.2.3 General Parallel File System
1.2.4 HAMMER . . . . . . . . . .
1.2.5 Infinit . . . . . . . . . . . . .
1.2.6 Parallel Virtual File System .
1.2.7 OneFS . . . . . . . . . . . . .
1.3 Les plus prometeurs . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
4
4
4
4
5
5
5
6
6
7
7
7
8
8
2 Mise en place
2.1 Andrew File System . . . . . . . .
2.1.1 Pré-requis et informations .
2.1.2 Installation . . . . . . . . .
2.1.3 Configuration . . . . . . . .
2.1.4 Conclusion sur OpenAFS :
2.2 Coda . . . . . . . . . . . . . . . . .
2.2.1 Côté serveur . . . . . . . .
2.2.2 Côté client . . . . . . . . .
2.3 Global File System . . . . . . . . .
2.3.1 Prérequis . . . . . . . . . .
2.3.2 Configuration . . . . . . . .
2.3.3 Création des partitions . . .
2.3.4 Utilisation . . . . . . . . . .
2.4 Ceph . . . . . . . . . . . . . . . . .
2.5 Ceux que l’on garde . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
9
9
10
12
12
12
20
22
22
22
23
23
23
25
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Évaluation des performances
26
Conclusion
27
Webographie
28
2
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
Chapitre
1
1.1
1.1.1
État de l’art
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.
1.1.2
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 10 000 clients accédant au même fichier ou écrivant dans le même
répertoire.
1.1.3
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.
1.1.4
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
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étaoctets1 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ées2 et une haute
disponibilité.
Le logiciel comprends un serveur de métadonnées (MDS3 ), plusieurs serveurs de données (OSS4 ) 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/IP5 , 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.
1.1.5
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
1.2.1
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 supporte6 .
Global File System est original en le sens où chacun des nœuds est un un pair7 et est autorisé à un
accès concurrent aux ressources.
Pour que ce système fonctionne optimalement il nécessite un gestionnaire de verrou tel GULM8
ou DLM9 qui est généralement préféré. Il est également possible d’utiliser un gestionnaire « nolock »
1
Un pétaoctet contient 1015 octets, plus de 200 millions de DVD simples
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
2
5
dans le cas où l’on souhaite l’utiliser sur une seule machine. Notons aussi que GFS2 inclut par défaut
DLM.
1.2.2
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 FUSE10 .
GlusterFS est un des rares logiciels de ce type qui supporte plusieurs protocoles de communication,
tels TCP/IP, InfiniBand, SDP11 ou UDS12 .
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).
1.2.3
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 2001. 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, . . .
10
Filesystem in Userspace
Sockets Direct Protocol
12
Unix Domain Socket ou IPC Socket
11
6
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.
1.2.5
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é.
1.2.6
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 pro7
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.
1.2.7
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
Chapitre
2
2.1
2.1.1
Mise en place
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 : 192.168.10.88. Le client aura
pour adresse IP : 192.168.10.87.
On ajoutera donc ces lignes au fichier /etc/hosts :
192.168.10.87 eee.ludo.fr eee
192.168.10.88 krb1.ludo.fr krb1 afs1.ludo.fr afs1
2.1.2
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? 4000000
# (Default value is 50000 for 50 MB, but you can greatly increase the
# size on modern systems to a few gigabytes, with 20000000 (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
# 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/[email protected] with password.
kadmin.local: addprinc -policy service -randkey -e des-cbc-crc:v4 afs
Principal "[email protected]" 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 2035850286
Keys last changed on Tue Feb 24 23:04:02 2009.
All done.
2.1.3
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
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 354545
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 1200 -l 1200 -cb 65535 -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 536870915 created on partition /vicepa of afs.ludo.fr
/etc/init.d/openafs-client force-start
Starting AFS services: afsd.
11
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/[email protected]: PASSWORD
afs-rootvol
Une fois la commande terminée, nous avons notre cellule OpenAFS !
2.1.4
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
2.2.1
Coda
Côté serveur
Prérequis :
Création de deux disques virtuels :
$ mkdir /coda
$ dd if=/dev/zero of=/coda/sdz0 bs=1M count=1024
1024+0 enregistrements lus
1024+0 enregistrements écrits
1073741824 octets (1,1 GB) copiés, 11,8537 seconde, 90,6 MB/s
$ dd if=/dev/zero of=/coda/sdz1 bs=1M count=1024
1024+0 enregistrements lus
1024+0 enregistrements écrits
1073741824 octets (1,1 GB) copiés, 12,7182 seconde, 84,4 MB/s
12
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 <[email protected]>
Architecture: i386
Source: coda
Version: 6.9.4
Depends: coda-update, rvm-tools, libc6 (>= 2.3.6-6), libgcc1 (>= 1:4.1.1-12),
liblwp2, libncurses5 (>= 5.4-5), libreadline5 (>= 5.2), librpc2-5, librvm1,
libstdc++6 (>= 4.1.1-12)
Filename: coda/coda-server_6.9.4_i386.deb
Size: 1914762
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 http://www.coda.cs.cmu.edu/
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
Enter a random token for auth2 authentication : ptutptut
Enter a random token for volutil authentication : ptutptut
tokens done!
Setting up the file list for update client
13
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
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
jpeg images
~0.50MB RVM per
email folders ~37.8MB RVM per
netbsd-pkgsrc ~180MB RVM per
GB.
GB.
GB (maildir, 1 file per message)
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
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 7f000000
creating volume /.0 on codaserv1 (partition /vicepa)
V_BindToServer: binding to host codaserv1
Set Log parameters
Fetching volume lists from servers:
GetVolumeList finished successfully
codaserv1 - success
VLDB completed.
<echo / 7f000000 1 01000001 0 0 0 0 0 0 0 >> /vice/db/VRList.new>
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 http://www.coda.cs.cmu.edu.
16
Réplication du serveur :
Deux disques virtuels ont été créés sur le second serveur.
Fichier /etc/hosts des deux serveurs :
192.168.1.10 codaserv1
192.168.1.20 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/2009
07: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.
-------------------------------------------------------
17
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
jpeg images
~0.50MB RVM per
email folders ~37.8MB RVM per
netbsd-pkgsrc ~180MB RVM per
GB.
GB.
GB (maildir, 1 file per message)
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
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
codaserv2
1
2
Fichier /vice/db/VSGDB sur les deux serveurs :
E0000104 codaserv1 codaserv2
E0000104 est une adresse de volume.
codaserv1:/home/slecaille# createvol_rep replicat codaserv1 linuxlap E0000104
Server E0000104 not in servers file
19
codaserv1:/home/slecaille# createvol_rep replicat codaserv1 linuxlap
Replicated volumeid is 7f000002
creating volume replicat.0 on codaserv1 (partition /vicepa)
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
linuxlap - success
codaserv1 - success
VLDB completed.
<echo replicat 7f000002 2 01000003 02000001 0 0 0 0 0 0 >> /vice/db/VRList.new>
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 7F000003
2.2.2
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 <[email protected]>
Architecture: i386
Source: coda
Version: 6.9.4
Depends: libc6 (>= 2.3.6-6), libgcc1 (>= 1:4.1.1-12), liblwp2,
libncurses5 (>= 5.4-5), libreadline5 (>= 5.2), librpc2-5, librvm1,
libstdc++6 (>= 4.1.1-12)
Pre-Depends: debconf (>= 0.2.17)
Suggests: python-gtk2
Filename: coda/coda-client_6.9.4_i386.deb
Size: 1722422
MD5sum: 2758454c1f8be25356a933862fa269ee
SHA1: 4e7492f86f28b3caa38987dc3fd9acce285e4663
SHA256: 279dd8775cc0d99e0f7a6b8febc0c87288c304d01096dca4fb7719f696720193
Description: Client for the Coda distributed file system
20
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 userspace binaries to run a Coda client. You might
also need to recompile a linux kernel to include a kernel module for Coda.
.
For more information go to http://www.coda.cs.cmu.edu/
Installation du paquet :
$ apt-get install coda-client
Configuration du client Coda :
$ venus-setup
Starting "dpkg-reconfigure coda-client"
Stopped /usr/sbin/venus (pid 7670).
update-rc.d: warning: /etc/init.d/coda-client missing LSB information
update-rc.d: see <http://wiki.debian.org/LSBInitScripts>
Starting Coda client components: kernel venus
Date: Thu 03/19/2009
18:31:01
18:31:01
18:31:01
18:31:01
18:31:01
18:31:01
18:31:01
18:31:01
18:31:01
18:31:01
18:31:01
18:31:01
18:31:01
18:31:01
18:31:01
18:31:01
18:31:01
18:31:01
18:31:01
18:31:01
18:31:01
18:31:01
Coda Venus, version 6.9.4
/var/lib/coda/LOG size is 2706432 bytes
/var/lib/coda/DATA size is 10821392 bytes
Loading RVM data
Last init was Thu Mar 19 18:27:21 2009
Last shutdown was clean
Starting RealmDB scan
Found 1 realms
starting VDB scan
2 volume replicas
0 replicated volumes
0 CML entries allocated
0 CML entries on free-list
starting FSDB scan (4166, 100000) (25, 75, 4)
1 cache files in table (0 blocks)
4165 cache files on free-list
starting HDB scan
0 hdb entries in table
0 hdb entries on free-list
Mounting root volume...
Venus starting...
/coda now mounted.
Ajout du volume du serveur au client :
$ cfs lv /coda/192.168.1.10/
Status of volume 7f000000 (2130706432) named "/"
Volume type is ReadWrite
Connection State is Reachable
Reintegration age: 0 sec, time 15.000 sec
Minimum quota is 0, maximum quota is unlimited
Current blocks used are 2
The partition has 8014528 blocks available out of 9767184
21
Authentification :
$ clog [email protected]
Password:
2.3
Global File System
Nous testons ce système de fichier dans l’optique d’avoir deux nœuds.
2.3.1
Prérequis
On installe des paquets pour GFS et le cluster (sur tous les nœuds) :
# apt-get install gfs2-tools cman rgmanager
Chargement des modules (sur tous les nœuds) :
# modprobe gfs2
# modprobe lock_dlm
2.3.2
Configuration
Création de la configuration du cluster :
#
#
#
#
ccs_tool
ccs_tool
ccs_tool
ccs_tool
create -2 ClusterAsrall
addfence apc fence_apc ipaddr=192.168.10.48 user=apc password=apc
addnode node1 -n 1 -f apc port=10001
addnode node2 -n 2 -f apc port=10002
La configuration crée est placée dans /etc/cluster/cluster.conf que l’on peut remodifier (et
recopier sur tous les nœuds) :
$ cat /etc/cluster/cluster.conf
<?xml version="1.0"?>
<cluster name="ClusterAsrall" config_version="6">

<cman expected_votes="1" />
<clusternodes>
<clusternode name="node1" votes="1" nodeid="1">
<fence>
<method name="single">
<device name="apc" port="10001"/>
</method>
</fence>
</clusternode>
<clusternode name="node2" votes="1" nodeid="2">
<fence>
<method name="single">
<device name="apc" port="10002"/>
</method>
</fence>
</clusternode>
</clusternodes>
<fencedevices>
<fencedevice name="apc" agent="fence_apc" ipaddr="192.168.10.48" \
user="apc" password="apc"/>
22
</fencedevices>
<rm>
<failoverdomains/>
<resources/>
</rm>
</cluster>
On ajoute les différents nœuds (ici node1 et node2) dans /etc/hosts (sur tous les nœuds) :
# echo ’192.168.10.48
# echo ’192.168.10.224
2.3.3
node1’ >> /etc/hosts
node2’ >> /etc/hosts
Création des partitions
À cette étape il serait interessant de créer un LVM pour une plus grande maniabilité des partitions,
seuleument le LVM ne veut pas se créer en affichant une erreur qui laisse à penser que le disque dur est
trop petit. Néanmoins nous ne nous attardons pas trop sur la question car ce n’est pas indispensable
à l’utilisation de GFS.
Création du GFS, sur le nœud 1 :
# gfs2_mkfs -p lock_dlm -t ClusterAsrall:node1 -j 2 /dev/hda3
Sur le nœud 2 :
# gfs2_mkfs -p lock_dlm -t ClusterAsrall:node2 -j 2 /dev/sda8
2.3.4
Utilisation
On lance les services de gestion du cluster et des verrous :
# /etc/init.d/cman start
# /etc/init.d/rgmanager start
On monte la partition GFS, sur le nœud 1 :
# mount -t gfs2 /dev/hda3 /mnt/gfs/
Sur le nœud 2 :
# mount -t gfs2 /dev/sda8 /mnt/gfs/
Voila, arrivé là on s’attends à avoir un système de stockage distribué opérationnel, on fait donc
un test simple : on met un fichier sur le montage GFS d’un nœud et on regarde si on peut le voir de
l’autre et. . .non.
2.4
Ceph
On ajoute le dépôt de Ceph dans le fichier sources.list :
# echo "deb http://ceph.newdream.net/debian/ unstable main" \
>> /etc/apt/sources.list
Puis on installe :
# apt-get install ceph
On rempli le fichier de configuration comme suit :
23
$ cat /etc/ceph/ceph.conf
; global
[global]
restart on core dump = true
pid file = /var/run/ceph/$name.pid
; monitor
[mon]
mon data = /data/mon$id
[mon0]
host = serv02
mon addr = 192.168.10.48:6789
[mon1]
host = l2c4
mon addr = 192.168.10.224:6789
; mds
[mds]
[mds.serv02]
host = serv02
[mds.l2c4]
host = l2c4
; osd
[osd]
sudo = true
[osd0]
host = serv02
osd data = /dev/hda3
osd journal = /dev/umema
[osd1]
host = l2c4
osd data = /dev/sda8
osd journal = /dev/umema
On crée les systèmes de fichier :
# mkdir -p /usr/var/log/ceph/
# mkcephfs -c /etc/ceph/ceph.conf
/usr/bin/monmaptool --create --clobber --add 192.168.10.48:6789 \
--add 192.168.10.224:6789 --print /tmp/monmap.10982
/usr/bin/monmaptool: monmap file /tmp/monmap.10982
/usr/bin/monmaptool: generated fsid 4962e3e8-844d-3b65-6975-adec6d7b18b4
/usr/bin/monmaptool: monmap: epoch 1
/usr/bin/monmaptool: monmap: fsid 4962e3e8-844d-3b65-6975-adec6d7b18b4
/usr/bin/monmaptool: monmap: mon0 192.168.10.48:6789/0/0
/usr/bin/monmaptool: monmap: mon1 192.168.10.224:6789/0/0
/usr/bin/monmaptool: writing epoch 1 to /tmp/monmap.10982 (2 monitors)
max osd in /etc/ceph/ceph.conf is 1, num osd is 2
/usr/bin/osdmaptool: osdmap file ’/tmp/osdmap.10982’
/usr/bin/osdmaptool: writing epoch 1 to /tmp/osdmap.10982
=== mon1 === 09.03.23 16:23:28.103990 store(/data/mon1) mkfs
09.03.23 16:23:28.119884 store(/data/mon1) test -d /data/mon1 \
&& /bin/rm -r /data/mon1 ; mkdir -p /data/mon1
/usr/bin/mkmonfs: created monfs at /data/mon1 for mon1
24
=== mds.l2c4 ===
=== osd1 === ** WARNING: Ceph is still under heavy development, \
and is only suitable for **
**
testing and review. Do not trust it with important data.
error opening output file /usr/var/log/ceph/l2c4.11090
ceph version 0.7.1 (386814ff1af76f913fc4b7d3e9555fdd68ee91d2)
09.03.23 16:23:28.522898 ebofs(/dev/sda8).mounted /dev/sda8 \
2560351 blocks, 10001.4 MB, no journal
created object store for osd1 fsid 4962e3e8-844d-3b65-6975-adec6d7b18b4 \
on /dev/sda8
**
Et on démarre Ceph :
# /etc/init.d/ceph start
=== mon1 === Starting ceph mon1 on l2c4...
=== mds.l2c4 === Starting ceph mds.l2c4 on l2c4...
** WARNING: Ceph is still under heavy development, and is only suitable for **
**
testing and review. Do not trust it with important data.
**
[...]
09.03.23 16:28:20.762070 3058637712 -- 0.0.0.0:6801/12640/0 >> \
192.168.10.224:6789/0/0 pipe(0xa2ce398 sd=-1 pgs=0 cs=0).fault first fault
2.5
Ceux que l’on garde
Coda et Lustre sont deux systèmes de fichier qui ont bien voulu fonctionner jusqu’au évaluations
de performance. Donc, c’est ceux là que nous avons conservé pour la partie suivante.
25
Chapitre
Évaluation des performances
3
Les tests de performances sont réalisés avec Iozone.
min
moy
max
NFS
9619,83 Ko/s
12063,55 Ko/s
13903,58 Ko/s
Coda
8192,87 Ko/s
11620,17 Ko/s
15057,25 Ko/s
Lustre
12094,05 Ko/s
12247,23 Ko/s
12170,64 Ko/s
16000
15000
14000
13000
12000
11000
10000
9000
8000
7000
6000
5000
4000
3000
2000
1000
0
min
moy
NFS
Coda
max
Lustre
Fig. 3.1 – Comparaison des performances entre NFS, Lustre et Coda.
26
Conclusion
Nous avons vu qu’il existe un nombre conséquent de systèmes de fichier orientés distribution et un
nombre suffisant de ces systèmes sont intéressants et amplement utilisés.
La plupart propose des solutions pour rendre les données hautement disponibles, ainsi que de la
réplication de données.
La difficulté de la mise en place varie selon les systèmes de fichiers. Ainsi, nous avons vu que Coda
été relativement simple à mettre en place, tandis que pour des systèmes comme OpenAFS, cela se
révèle bien plus complexe de par leur dépendances.
De la même manière, tous les systèmes de fichiers distribués ne sont pas documentés de manière
égale. Une bonne partie de la documentation sur OpenAFS date quelque peu mais est assez importante.
En revanche, la documentation sur GFS n’est pas très développé et peu se réveler contradictoire. Pour
ce qui est de Coda, le système est relativement bien documenté et nous avions également l’avantage
d’avoir une personne dans le groupe ayant déjà travaillé sur ce système.
27
Webographie
AFS
http://fr.wikipedia.org/wiki/Andrew_File_System
CephFS
http://kerneltrap.org/Linux/Ceph_Distributed_Network_File_System
CODAFS
http://www.coda.cs.cmu.edu/
http://linuxplanet.com/linuxplanet/tutorials/4481/1/
http://frederic.praca.free.fr/index.php?tag/CodaFS
POHMELFS
http://tservice.net.ru/~s0mbre/old/?section=projects&item=pohmelfs
GPFS
http://fr.wikipedia.org/wiki/General_Parallel_File_System
http://en.wikipedia.org/wiki/IBM_General_Parallel_File_System
Lustre
http://fr.wikipedia.org/wiki/Lustre_(systeme_de_fichier)
http://en.wikipedia.org/wiki/Lustre_(file_system)
Infinit
http://en.wikipedia.org/wiki/Infinit
PVFS
http://en.wikipedia.org/wiki/Parallel_Virtual_File_System
The Circle
http://en.wikipedia.org/wiki/The_Circle
OneFS
http://en.wikipedia.org/wiki/OneFS_distributed_file_system
HAMMER
http://en.wikipedia.org/wiki/HAMMER
GlusterFS
http://en.wikipedia.org/wiki/GlusterFS
28

Stockage distribué sous Linux

Transcription

Documents pareils

palace country Partition:1

origine latine Partition:1

saxo love Partition:1

rendez-vous country Partition:1

la Maison près de la Fontaine - Free

VIVRE D`AMOUR

michel sardou - je viens du sud

Fiche Technique [ pdf

No file - Editions entrefilet

Fiche Technique Cabaret.xlsx