Je vais commencé par vous présenter celui que je pense être de très loin le roi des file system distribués : CEPH.

Ceph est donc un système de fichier distribué, considéré comme stable depuis peu. La configuration du cluster est inconnue au client. CEPH peut être utilisé pour faire de l'object storage.

Comme d'habitude voici l'archi que nous allons réaliser :

Ceph utilise différents constituants :

1. les monitors : mon. Leur but est de, à plusieurs, gérer l'ensemble du cluster CEPH. Celà comprends :
   1. La gestion des opérations effectuées par le client
   2. La re-répartition des fichiers
   3. Les checks de santé des autres nœuds
2. les “devices” de stockage objet : osd. C'est là que sont effectivement stockées les données.
3. Les serveurs “Métadata” : mds. Contient les Métadatas du système de fichier CEPH.
4. Une ceph object gateway, qui permet via http de gérer les objets stockés ( non utilisée ici ). Elle est basée sur apache et fast-cgi.

L’installation est simpliste : elle repose sur un script, ceph-deploy qui fait tout le boulot à notre place! ( un vrai truc de manager ^^ ).

On commence par installer ceph sur toutes les machines.

• On récupère la clé gpg de ceph et on l'ajoute à apt :

    wget -q -O- 'https://ceph.com/git/?p=ceph.git;a=blob_plain;f=keys/release.asc' | sudo apt-key add -

• On ajoute le dépot ceph :

    echo "deb http://ceph.com/debian/ wheezy main" >> /etc/apt/sources.list

• On update…
• On installe le paquet ceph sur tous les noeuds
• On installe le paquet ceph-deploy sur notre noeud benwa-ceph-master-1

Bon assurez vous que l'utilisateur root peu bien depuis chaque machine du cluster aller en ssh su chaque autre machine du cluster…

Nous pouvons donc commencer à installer ceph via ceph-deploy !!!

Pour utiliser ceph-deploy il vous faut :

• être root, genre vraiment ^^ ( donc pas de sudo su, on se log direct en root )

• Travailler dans un dossier exclusivement dédié à ça ( pour moi /home/benwa/ceph )

Pour créer le cluster :

  ceph-deploy new benwa-ceph-mon-1

Nous allons maintenant créer deux moniteurs :

  ceph-deploy mon benwa-ceph-mon-1 benwa-ceph-mon-2

Ici aussi, rien de plus simple :

  ceph-deploy mds create benwa-ceph-mds-1 benwa-ceph-mds-2

On commence par les préparer :

  ceph-deploy osd prepare benwa-ceph-osd-1 benwa-ceph-osd-2 benwa-ceph-osd-3

Puis on les activent :

  ceph-deploy osd activate benwa-ceph-osd-1 benwa-ceph-osd-2 benwa-ceph-osd-3

Note : D'autres fonctionnalités existent comme :

1. utiliser un (ou plusieurs) disque complets par osd et non plus un dossier.
2. Spécifier un device différent pour la journalisation de l'osd ( → augmentation des perfs… Qui plus est si on utilise pour cette mission un SSD )

Il est de plus possible d'utiliser btrfs ^^

Celà est fait simplement depuis un moniteur par :

  ceph health

On accède notamment à l'ensemble des problèmes des différents noeuds, etc…

Celà donne des possibilité de surveillance via monitoring ^^

L'installation des paquets ceph-common et ceph-fs-common est nécéssaire.

Voici l'entrée dans mon /etc/fstab :

  192.168.103.222:6789,192.168.103.223:6789:/     /mnt/mycephfs    ceph    name=admin,secretfile=/etc/ceph/secret,noatime    0

Les ips corresondent respectivement à benwa-ceph-master-1 et benwa-ceph-master-2.

Ceph utilise l'algorithme CRUSH pour répliquer les données. C'est un algorithme pseudo aléatoire ( rejouable, donc ) qui statistiquement équilibre les écritures.

On peut customiser l'algorithme via un fichier de configuration ( compilé… )

Pour le récupérer :

  ceph osd getcrushmap -o fichier_ou_on_recupere_la_CRUSH_map

Pour le décompiler :

  crushtool -d CRUSH_map_compile -o CRUSH_map_decompile

On fait notre vin puis on recompile :

  crushtool -c CRUSH_map_modif -o CRUSH_map_compile

Et on utilise ce fichier compilé :

  ceph osd setcrushmap -i CRUSH_map_compile

Les buckets : Un bucket est un objet. Il correspond à quelque chose qui vous fait sens ( osd, rack, salle, data-center, région, etc…) Vous pouvez créer vos propres buckets. Vous indiquez ensuite les items enfants, qui constituent le bucket. On indique aussi la capacité de stockage ( 1 ⇔ 1TB ).

Bien renseigner ses buckets permet de :

1. Vous éviter de tout devoir renseigner la jour ou vous voudrez gérer de manière plus fine vos réplications.
2. Des messages d'infos plus pertinents en cas de failure.

Les règles permettent de gérer la position des données pour un pool. On peut s'en servir pour orienter un pool de data vers des serveurs munis de SSDs et un autre pool de data vers un équipé de HDDs. On peut aussi forcer la réplication entre différentes salles, différents data-centers…

Ci joint mon set de règles, pour répliquer “potentiellement” des données avec CEPH entre le U1 et notre salle serveur :

# begin crush map
 
# devices
device 0 device0
device 1 device1
device 2 device2
device 3 osd.3
device 4 osd.4
device 5 osd.5
 
# types
type 0 osd
type 1 host
type 2 rack
type 3 row
type 4 room
type 5 datacenter
type 6 root
 
# buckets
host benwa-ceph-ods-3 {
        id -2           # do not change unnecessarily
        # weight 0.010
        alg straw
        hash 0  # rjenkins1
        item osd.3 weight 0.010
}
host benwa-ceph-osd-2 {
        id -3           # do not change unnecessarily
        # weight 0.010
        alg straw
        hash 0  # rjenkins1
        item osd.4 weight 0.010
}
host benwa-ceph-ods-1 {
        id -4           # do not change unnecessarily
        # weight 0.010
        alg straw
        hash 0  # rjenkins1
        item osd.5 weight 0.010
}
root default {
        id -1           # do not change unnecessarily
        # weight 0.030
        alg straw
        hash 0  # rjenkins1
        item benwa-ceph-ods-3 weight 0.010
        item benwa-ceph-osd-2 weight 0.010
        item benwa-ceph-ods-1 weight 0.010
}
room salle_serveur_principale {
        id -5
        alg straw
        hash 0
        item benwa-ceph-ods-1 weight 0.010
        item benwa-ceph-osd-2 weight 0.010
}
room salle_serveur_U1 {
        id -6
        alg straw
        hash 0
        item benwa-ceph-ods-3 weight 0.020
}
rule metadata {
        ruleset 1
        type replicated
        min_size 1
        max_size 10
        step take default
        step chooseleaf firstn 0 type room
        step emit
}
rule rbd {
        ruleset 2
        type replicated
        min_size 1
        max_size 10
        step take default
        step chooseleaf firstn 0 type room
        step emit
}
 
# end crush map

Je conseille par ailleurs la lecture de cette page.

Voici le quelques constats que j'ai pu faire :

Les +

1. Une très très bonne scalabilité
2. L'infra est complètement transparente au client
3. Une simplicité de mise en place époustouflante …
4. Pouvoir faire de l'object storage ( non mis en place ici )
5. Un tel espace de stockage que vous pouvez y mettre à peu près ce que vous voulez ( ça doit même suffire pour youtube… )
6. Réorganisation au mieux de l'espace de stockage de manière transparente.
7. N'utilise pas FUSE ( donc beaucoup moins consommateur de CPU sur la machine cliente que GlusterFS que nous verrons par la suite ).
8. Possibilité de customisation de la réplication des fichiers.
9. Support des snapshots

Les -

1. Les perfs. Bon certes les tests sont effectués sur des machines virtuelles présentent sur le même NAS, donc du coup le bénéfice d'avoir plusieurs serveurs de Data ( osd ) ne se fait pas sentier mais c'est tout de même bien plus lent que dans le système de fichier de la VM. Celà est je pense plus aussi tranché dès que la barre de la centaine de nœuds est passée. Mais j'hésiterais avant de mettre des Vms dessus. Ce constat est aussi sûrement à nuancer : les osd ne sont pas fait pour tourner au dessus d'un (ou plusieurs dans le cas de l'exemple ) système de fichier …

GlusterFS est un système de fichier distribué en réseau, développé par RedHat.

Il est pensé pour être très largement scalable.

Nous nous baserons dans cet article sur cette installation :

Nous dupliquons les données sur les serveurs (2 à 2).

Cette architecture sera d'abord réalisé avec 4 serveurs GlusterFS, dont on prendra soin de remplir les disques avant d'ajouter deux derniers serveurs.

Commençons par créer le répertoire qui accueillera les données :

  mkdir /data
  mkdir /data/exports

Maintenant installons Glusterfs :

  apt-get install glusterfs-server

Éditions la configuration : ''nano /etc/glusterfs/glusterd.vol

volume posix
        type storage/posix
        option directory /data/exports
end-volume

volume locks
        type features/locks
        subvolumes posix
end-volume

volume brick
        type performance/io-threads
        option thread-count 8
        subvolumes locks
end-volume

volume server
        type protocol/server
        option transport-type tcp
        option auth.addr.brick.allow 192.168.103.211
        subvolumes brick
end-volume

Je ne reviendrais pas sur ce fichier de conf, il est très explicite.

On redémarre glusterfs :

   /etc/init.d/glusterfs-server restart

Et voilà, c'est aussi bête que ça. ( L'instalation de la VM prend beaucoup plus de temps que celle de GlusterFS !!! ).

Ici, on se contente d'installer le client GlusterFS :

  apt-get install glusterfs-client

On cré le point de montage :

  mkdir /mnt/glusterfs

Et un dossier pour abriter notre conf'.

  mkdir /etc/glusterfs

Maintenant on rédige notre fichier de conf :

volume remote1
  type protocol/client
  option transport-type tcp
  option remote-host benwa-glusterfs-1
  option remote-subvolume brick
end-volume

volume remote2
  type protocol/client
  option transport-type tcp
  option remote-host benwa-glusterfs-2
  option remote-subvolume brick
end-volume

volume remote3
  type protocol/client
  option transport-type tcp
  option remote-host benwa-glusterfs-3
  option remote-subvolume brick
end-volume

volume remote4
  type protocol/client
  option transport-type tcp
  option remote-host benwa-glusterfs-4
  option remote-subvolume brick
end-volume

volume replicate1
  type cluster/replicate
  subvolumes remote1 remote2
end-volume

volume replicate2
  type cluster/replicate
  subvolumes remote3 remote4
end-volume

volume replicate3
  type cluster/replicate
  subvolumes remote5 remote6
end-volume

volume distribute
  type cluster/distribute
  subvolumes replicate1 replicate2 replicate3
end-volume

volume writebehind
  type performance/write-behind
  option window-size 1MB
  subvolumes distribute
end-volume

volume cache
  type performance/io-cache
  option cache-size 512MB
  subvolumes writebehind
end-volume

Revenons un peu plus sur ce fichier de conf :

• On définit nos serveurs back-end comme un block de données
• On regroupe ces blocks de données par deux pour la redondance
• On regroupe ensuite ces blocks redondés , dans un autre block.
• Le translator write-behind augmente significativement les performances en écriture. Cette feature permet de regrouper les petites écritures pour en former de plus grosses, afin d'écrire plus vite sur les disques.
• Et enfin on fait du cache en lecture.

Ensuite, il ne reste plus qu'à monter :

  mount -t glusterfs /etc/glusterfs/glusterfs.vol /mnt/glusterfs

Et voilà, vous avez un système de fichier distribué

1. L'ajout de nouveau serveurs backend se passe très bien
2. D'après la doc' il existe même des outils pour le faire sans rien couper
3. J'ai pu éteindre n'importe lequel des serveurs de n'importe quelle pool de serveur sans éclencher d'indisponibilité. Puissant.
4. Par défaut, la répartition des fichiers entre les serveurs est fait en fonction du poids. Vous pouvez modifier ce comportement par défaut en utilisant des Schedulers :
   1. avec ALU vous pouvez établir votre choix en fonction de la charge en IO.
   2. avec switch vous pouvez organiser votre répartition en vous basant sur le nom de fichier. Je trouve la fonctionnalité sympa.
   3. NUFA permet de privilégier un nœud par rapport aux autres (très utile pour privilégier le nœud local, si la machine est à la fois client et un de ses propres serveurs )
   4. Vous pouvez faire du Round Robin et du Random, bien que j'en voie pas l'intérêt.
   5. On peut utiliser dans ses projets la libglusterfs pour court-circuiter FUSE et le système de fichier local dans ses projets de programmation. Une belle attention
5. Et pour finir sur les avantages, GlusterFS est d'une simplicité de déploiement effroyable…

Je n'ai pu m'empêcher de ressortir iozone pour tester tout ceci plus en profondeur. Voici mes conclusions :

1. Globalement, les débits en écriture sont deux fois plus lents pour les petits fichiers, et deux fois plus rapides pour les gros fichiers pour les écritues séquentielles. On est plus rapide pour les écritures aléatoires.
2. En lecture, mes résultats ne me semblent pas exploitables.
3. A priori on perd pas trop en latence…

Ces résultats sont à prendre avec des pincettes. En effet ils sont obtenues en utilisant des KVMs comme client et comme serveur qui sont hébergées sur NAS.

1. L'organisation des écritures est effectué par la machine cliente. On en déduit que si la conf est pas identique sur tous les clients, des blagues peuvent survenir.
2. Quand on fait un ls, on intéroge tous les serveurs, donc on consomme de la ressource, et quand on fait un ls -l, comme en plus on récupère les infos du fichiers bah c'est pire.
3. Pour l'utiliser sous OpenVZ, il faut charger tout un tas de modules –> j'ai donc fait que des KVMs une fois que je m'en suis rendu compte.
4. Comme on ne sais pas sur quel serveur back-end se trouvent les données, qui sont donc décentralisées, des features des systèmes de fichiers NextGen (ZFS, BetterFS) ne sont pas utilisables, nottament le rollback de snapshot pour un dataset, qui perd son sens ( de même pour le clonning de dataset, etc… ) . Par ailleurs, getfaddr sous centOS permet de savoir sur quel back-end est situé le fichier à restaurer. Sinon, il faut chercher et c'est chiant.
5. GlusterFS gère jusqu'à qq péta octets ( ~ 1000 téras ). C'est beaucoup, mais c'est pas forcément si énorme que ça. Tout dépend de vos besoins. Ce que je veux dire par là c'est que la limite est potentiellement atteignable… Bon OK, il faut s'appeler youtube ou la NSA…

Je pense que GlusterFS est un très bon système de fichier dès lors que la scalabilité prime plus que la nécessité des snapshots.

AUFS ( another Union File System ) est un système de fichier permettant de fusionner dans son point de montage plusieurs dossiers de votre Virtual File System. Un des usages possibles est de l'utiliser pour fusionner virtuellement deux points de montage NFS, que nous pourrons utiliser au travers de AuFS comme un seul et unique fileSystem.

Pour installer ce système de fichier sous Debian :

  apt-get install aufs-tools
  modprobe aufs

Ensuite, pour pouvoir l'utiliser :

  mount -t aufs -o br=/mnt/nfs1:/mnt/nfs2 none /mnt/aufs

Attention, il s'agit clairement d'un tric… Je vois pas qui utiliserais ça en prod… Comme pour glusterFS, le client doit avoir conscience de l'architecture de stockage, et en est responsable. Néanmoins cette solution utilise des modules kernels côté clients (nfs et aufs) et est donc beaucoup moins gourmande en ressource. En revanche, je n'ai pas encore trouvé comment apporter de la redondance à cette archi “maison”. De plus, il n'y a clairement pas le même jeu d'options possible comparé à GlusterFS.

Note : AuFS peut être utilisé pour virtuellement écrire sur un filesystem en readOnly (typiquement un live CD. ) On peut en effet écrire sur un file system en read only en gardant un delta des modifications faites aux fichiers de ce filesystem dans les fichiers de l'autre filesystem composant le montage aufs ( en RW, exemple, un truc en RAM ). Ainsi, grâce à ce subterfuge, et à l'aide d'un chroot, on arrive à utiliser virtuellement le filesystem du liveCD en mode RW.

Ceph :

1. Une présentation bien sympa de CEPH.
2. Le Quick Start
3. Les manpages
4. installer et configurer CEPH Object Gateway.
5. Personalisation de CRUSH

GlusterFS :

• La FAQ technique de GlusterFS, très instructive…
• Les schedulers, qui gère la répartition des fichiers…
• Un gars qui combine ZFS on LiNUX et GlusterFS : http://www.gluster.org/community/documentation/index.php/GlusterOnZFS
• Pour faire marcher GlusterFS sous OpenVZ
• Des recommandations hardwares et

AuFS :

• Un article approfondissant les usages de AuFS

Compléments d'articles :

• XtreemFS, un autre système de fichier distribué. C'est pas très en forme, et pas hyper bien documenté, et en plus basé sur FUSE ( Bof pour la prod… ). Qui plus ça supporte pas les dernières versions des distributions sur Debian… Je le met à titre d'indacation. Il laisse cependant à l'utilisateur un choix des fichiers à dupliquer ( peut être pratique ! ). Je laisse un lien vers le quick start. Je met aussi un pointeur vers la Doc.

— Benoit Tellier 2014/01/25 16:06