======= CEPH =======
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 :
{{:wiki:divers:ha:ceph_archi.png?450|}}
===== Les constituants =====
Ceph utilise différents constituants :
- les monitors : **mon**. Leur but est de, à plusieurs, gérer l'ensemble du cluster CEPH. Celà comprends :
- La gestion des opérations effectuées par le client
- La re-répartition des fichiers
- Les checks de santé des autres nœuds
- les "devices" de stockage objet : **osd**. C'est là que sont effectivement stockées les données.
- Les serveurs "Métadata" : **mds**. Contient les Métadatas du système de fichier CEPH.
- 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.
===== Installation =====
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 !!!
==== 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
=== Instalation des moniteurs ===
Nous allons maintenant créer deux moniteurs :
ceph-deploy mon benwa-ceph-mon-1 benwa-ceph-mon-2
=== Instalation des serveurs MétaData ===
Ici aussi, rien de plus simple :
ceph-deploy mds create benwa-ceph-mds-1 benwa-ceph-mds-2
=== Et enfin les osd ===
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 :
- utiliser un (ou plusieurs) disque complets par **osd** et non plus un dossier.
- 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** ^^
=== Vérifier l'état du cluster ===
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 ^^
=== Monter CEPH ===
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.
===== CRUSH Maps =====
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é... )
==== Gestion du fichier de configuration ====
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
==== Édition du fichier de configuration ====
**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 :
- Vous éviter de tout devoir renseigner la jour ou vous voudrez gérer de manière plus fine vos réplications.
- 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 [[http://ceph.com/docs/master/rados/operations/crush-map/|page]].
===== Mes constats =====
Voici le quelques constats que j'ai pu faire :
**Les +**
- Une très très bonne scalabilité
- L'infra est complètement transparente au client
- Une simplicité de mise en place époustouflante ...
- Pouvoir faire de l'object storage ( non mis en place ici )
- Un tel espace de stockage que vous pouvez y mettre à peu près ce que vous voulez ( ça doit même suffire pour youtube... )
- Réorganisation au mieux de l'espace de stockage de manière transparente.
- N'utilise pas FUSE ( donc beaucoup moins consommateur de CPU sur la machine cliente que **GlusterFS** que nous verrons par la suite ).
- Possibilité de customisation de la réplication des fichiers.
- Support des snapshots :-)
**Les -**
- 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 =======
**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 :
{{:wiki:divers:ha:glustefs.png?900|}}
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.
===== Installation =====
==== Serveur ====
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** !!! ).
==== Client ====
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é ;-)
===== Quelques remarques =====
==== Fonctionnalité ====
- L'ajout de nouveau serveurs backend se passe très bien ;-)
- D'après la doc' il existe même des outils pour le faire sans rien couper
- J'ai pu éteindre n'importe lequel des serveurs de n'importe quelle pool de serveur sans éclencher d'indisponibilité. Puissant.
- 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** :
- avec **ALU** vous pouvez établir votre choix en fonction de la charge en IO.
- avec **switch** vous pouvez organiser votre répartition en vous basant sur le nom de fichier. Je trouve la fonctionnalité sympa.
- **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 )
- Vous pouvez faire du Round Robin et du Random, bien que j'en voie pas l'intérêt.
- 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 ;-)
- Et pour finir sur les avantages, **GlusterFS** est d'une simplicité de déploiement effroyable...
==== Performances ====
Je n'ai pu m'empêcher de ressortir **iozone** pour tester tout ceci plus en profondeur. Voici mes conclusions :
- 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.
- En lecture, mes résultats ne me semblent pas exploitables.
- 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.
==== Limites / dangers ====
- 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.
- 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.
- Pour l'utiliser sous OpenVZ, il faut charger tout un tas de modules --> j'ai donc fait que des **KVM**s une fois que je m'en suis rendu compte.
- 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.
- 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**...
==== Conclusions ====
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.
======= Un bricolage basé sur auFS =======
**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.
======= Liens ========
Ceph :
- Une [[http://snia.org/sites/default/files2/SDC2013/presentations/ObjectStorage/SageWeil__Architecting_Block.pdf|présentation]] bien sympa de CEPH.
- Le [[http://ceph.com/docs/master/start/quick-ceph-deploy/| Quick Start ]]
- Les [[http://ceph.com/docs/master/start/intro/|manpages]]
- [[http://ceph.com/docs/master/install/install-ceph-gateway/|installer]] et [[http://ceph.com/docs/master/radosgw/config/| configurer]] CEPH Object Gateway.
- Personalisation de [[http://ceph.com/docs/master/rados/operations/crush-map/|CRUSH]]
GlusterFS :
* La [[http://gluster.org/community/documentation/index.php/GlusterFS_Technical_FAQ|FAQ technique]] de GlusterFS, très instructive...
* Les [[http://gluster.org/community/documentation/index.php/Translators/cluster|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 [[http://ntanyone.tumblr.com/post/1691443277/preparing-openvz-container-for-using-glusterfs|GlusterFS sous OpenVZ]]
* Des recommandations [[http://ceph.com/docs/master/start/hardware-recommendations|hardwares]] et
AuFS :
* Un article approfondissant les usages de [[http://www.thegeekstuff.com/2013/05/linux-aufs/|AuFS]]
** Compléments d'articles : **
* [[http://en.wikipedia.org/wiki/XtreemFS|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 [[http://www.xtreemfs.org/quickstart.php|quick start]]. Je met aussi un pointeur vers la [[http://www.xtreemfs.org/xtfs-guide-1.4/index.html|Doc]].
--- //[[benwa@minet.net|Benoit Tellier]] 2014/01/25 16:06//