Présentation et installation du système de stockage réparti Ceph

Dans mon laboratoire, les budgets sont en baisse constante depuis plusieurs années, mais les besoins, eux, sont en hausse et notamment en ce qui concerne le stockage. Aujourd'hui, nous avons pratiquement 200 Ti sur 6 serveurs. La facture pour augmenter le stockage se compte en quelques dizaines de milliers d'euros (en une seule dépense). Dans notre contexte, obtenir entre 50 et 100 k euros de budget est très compliqué. Il est relativement plus simple d'obtenir plusieurs fois 5 à 10 k euros et de faire de la consolidation en étalant les dépenses sur plusieurs années. Pour réaliser cela au niveau du stockage, il faut changer de paradigme : il faut trouver un système de stockage souple, robuste, relativement performant et dont la brique de base ne soit pas trop chère. Le stockage objet reparti semble être une solution envisageable.

Dans ce premier article, nous allons voir comment installer un petit cluster Ceph (un système de stockage objet réparti) à l'aide de machines virtuelles.

1. Quelques définitions

Pour faire fonctionner Ceph, il faut 3 ou 4 serveurs qui peuvent éventuellement fonctionner sur une même machine (pour les essais, mais pas dans la vraie vie). Nous pouvons distinguer :

• le serveur d’administration du cluster nommé admin. Il permet d'effectuer les tâches d’administration de l'ensemble du cluster.
• le serveur de métadonnées nommé mds (Meta Data Server) qui gère les données descriptives des objets stockés dans le cluster. Une partie de son travail consiste en la redistribution de la charge. Cela nécessite une grosse capacité de traitement. Il faut donc utiliser une machine qui contiendra un grand nombre de processeurs. La mémoire est également importante pour ce serveur qui aura besoin d'au moins 1 Gi de mémoire par instance. Ce serveur n'est utile que si l'on planifie d'utiliser CephFS.
• le serveur moniteur nommé mon qui permet de suivre l'activité de l'ensemble du cluster.
• les serveurs de données nommés osd qui stockent les objets. Ces machines font tourner un certain nombre de processus et elles ont besoin d'une puissance de calcul correcte. Du côté de la mémoire, 512 Mi par instance sont suffisants sauf lors de la récupération où 1 Gi de mémoire par Ti de données et par instance est conseillé. Il faudra mettre le plus de disques possible dans chacun de ces serveurs en veillant à ne pas utiliser plus d'une instance par disque.

D'une manière générale, il est conseillé de ne pas lésiner sur la mémoire pour les serveurs osd et mds et les recommandations matérielles [1] pour faire fonctionner Ceph sont pleines d'astuces pratiques.

Le site Web de Ceph regorge de documentations détaillées. Elles sont de très bonne qualité et je vous encourage à les utiliser même si elles ne sont qu'exclusivement en anglais.

2. Installation

2.1 Les machines virtuelles créées

Pour se rapprocher d'un système qui pourrait être mis en production je sépare chacun des serveurs Ceph sur une machine virtuelle dédiée : il faut 5 machines virtuelles debian wheezy, car pour avoir un peu de redondance, il y a besoin de deux serveurs OSD. Ces machines virtuelles sont similaires en termes de processeur (un seul par machine) et de mémoire (1 Gi par machine). Un même « utilisateur » dup a été défini sur chacune d'elles (en production on prendra un utilisateur dont le nom sera plus évocateur, par exemple ceph). Il permettra l'installation et l'administration, via le programme ceph-deploy, des différents serveurs de Ceph. On créée une machine d'administration ceph-admin, une machine moniteur ceph-mon, une machine pour les méta-données ceph-mds et deux machines pour stocker les données ceph-osd1 et ceph-osd2. Ces deux machines seront dotées d'un disque virtuel dédié au stockage des données (pour le test, ce disque est d'une capacité de 16 Gi). Dans notre configuration, il s'agit du disque nommé /dev/sdb.

2.2 Les clefs ssh des utilisateurs

Nous créons, pour l'utilisateur root, une paire de clefs sur la machine ceph-admin avec la commande ssh-keygen (pour la démonstration, nous laissons le champ « mot de passe » vide) et copions la clef publique sur chacune des autres machines virtuelles avec la commande ssh-copy-id root@ceph-mds. On recommence de même avec l'utilisateur dup (ssh-copy-id dup@ceph-mon, ...).

2.3 Le sudo total

La documentation sous forme de « check-list » de Ceph [2] indique qu'il convient de donner le sudo sans mot de passe à l'utilisateur dup qui sera utilisé pour installer et maintenir le cluster Ceph. Pour ce faire, il faut créer un fichier nommé dup dans le dossier /etc/sudoers.d. Ce fichier contiendra la ligne suivante : dup ALL = (root) NOPASSWD:ALL qui permet de donner le droit sudo sans mot de passe pour tous les logiciels de la machine pour l'utilisateur dup.

Il faut copier ce fichier dans chacune des machines virtuelles (par exemple : scp /etc/sudoers.d/dup ceph-mds:/etc/sudoers.d/).

2.4 Fichiers hosts

Pour s'assurer que toutes les machines seront bien résolues, nous inscrivons en dur dans le fichier /etc/hosts les adresses de ces machines virtuelles :

En pratique, on utilisera un DNS conjointement à un DHCP. Ce sera plus souple et plus robuste.

2.5 Installation du dépôt logiciel de Ceph

Cette procédure manuelle d'installation du dépôt logiciel de Ceph est maintenant réalisée par ceph-deploy. Elle n'est utile que si vous souhaitez installer une version particulière de Ceph. Dans ce cas, il ne faudra pas utiliser ceph-deploy pour l'installation, mais installer les paquets à la main : aptitude install ceph ceph-common ceph-fs-common ceph-mds ceph-fuse libcephfs1 python-ceph. Il est tout à fait possible d'utiliser ceph-deploy par la suite même si l'installation initiale a été réalisée à la main.

L'Installation de la clef, la création du fichier de source pour apt pour le dépôt principal, et la création du fichier pour le dépôt contenant les extras de Ceph se font par :

Notez que « emperor » était la version stable au moment de l'écriture de ce paragraphe. Il faudra remplacer cette chaîne de caractère par le nom de la version stable au moment où l'on fera la mise en production. Enfin, nous exécutons la commande suivante uniquement sur le nœud d'administration (ceph-admin) :

2.6 Création du cluster Ceph

Nous allons maintenant installer Ceph sur chacune des machines virtuelles pour en faire un cluster puis nous les spécialiserons une à une. Sur la machine d'administration (ceph-admin) et en tant qu'utilisateur dup, il faut créer un dossier nommé demo-ceph dans lequel les commandes ceph-deploy seront utilisées (ceph-deploy crée des fichiers localement là où il est exécuté).

2.6.11 Créer un cluster en spécifiant son moniteur

Un cluster Ceph ne peut fonctionner sans moniteur, aussi nous devons commencer par indiquer quelle machine aura ce rôle futur. Pour ce faire, la commande ceph-deploy new ceph-mon commence le déploiement d'un nouveau cluster en ajoutant une machine moniteur dans ce cluster. Elle crée également trois fichiers : un fichier de clefs, un fichier de log et un fichier de configuration.

2.6.2 Installation de Ceph sur les machines virtuelles

Nous allons installer l'ensemble des programmes et librairies nécessaires à Ceph sur chacune des machines virtuelles. À la fin, ces machines seront toutes identiques et leur rôle leur sera attribué par la suite. Exécutez la commande ceph-deploy install ceph-admin ceph-mon ceph-mds ceph-osd1 ceph-osd2. En fonction de la connexion et de la puissance de la machine hôte, cette opération peut-être assez longue, car le volume des programmes à installer est assez important et les machines virtuelles peuvent être plus ou moins rapides pour les accès disques.

2.6.3 Spécialisation de la machine virtuelle moniteur (ceph-mon)

Maintenant que Ceph est installé sur chacune des machines virtuelles et que l'une d'entre elles est identifiée comme une machine moniteur nous devons la spécialiser. Pour ce faire, nous créons le moniteur à l'aide de la commande ceph-deploy mon create ceph-mon toujours exécutée depuis la machine d'administration.

2.6.4 Ensemble des clefs du cluster

Ceph utilise un système d'authentification basé sur des clefs. Ces clefs sont créées lors de la création du premier moniteur. La commande ceph-deploy les utilise pour la création des autres serveurs. On récupère ces clefs avec la commande ceph-deploy gatherkeys ceph-mon. Une fois les clefs récupérées, le dossier doit contenir les trois fichiers suivants : ceph.bootstrap-mds.keyring, ceph.bootstrap-osd.keyring et ceph.client.admin.keyring.

2.6.5 Les serveurs de données (ceph-osd*)

Nous allons créer les serveurs de données. Dans cet exemple, nous avons choisi d'installer un seul serveur de données par machine, mais il est tout à fait possible d'en installer plus d'un ! Malgré tout, comme on souhaite être assez proche d'une configuration de production, on va utiliser la totalité du deuxième disque des deux machines virtuelles :

• pour lister les disques disponibles de la machine ceph-osd1, on peut utiliser la commande suivante : ceph-deploy disk list ceph-osd1
• notre disque /dev/sdb est totalement disponible et nous allons le formater pour pouvoir l'utiliser : ceph-deploy disk zap ceph-osd1:sdb. Nous rééditons notre commande sur la deuxième machine : ceph-deploy disk zap ceph-osd2:sdb.
• il faut maintenant « préparer » les machines avec la commande ceph-deploy osd prepare ceph-osd1:sdb (on recommence avec la machine osd2).
• enfin, il faut activer les deux serveurs de données : ceph-deploy osd activate ceph-osd1:sdb et ceph-deploy osd activate ceph-osd2:sdb.

Cette suite de commandes crée une partition sur le disque sdb qui est formatée en xfs et montée dans le dossier /var/lib/ceph/osd/ceph-0. C'est elle qui contiendra les morceaux d'objets. Il est possible d'indiquer un dossier pour stocker le journal (ce que nous n'avons pas fait). Il est recommandé de ne pas mettre ce journal sur le même disque que les données. En pratique, on utilisera un autre disque pour cela (un SSD est recommandé pour obtenir de très hautes performances). On aura pris soin de formater et monter ce disque sur le dossier /chemin/vers/le avant de l'utiliser et les commandes pour intégrer le journal sont : ceph-deploy disk prepare ceph-osdn:sdb:/chemin/vers/le/journal et ceph-deploy osd activate ceph-osdn:sdb:/chemin/vers/le/journal).

2.6.6 Ajout du serveur de méta-données (ceph-mds)

Pour utiliser CephFS (le système de fichiers de Ceph), il faut créer un serveur de méta-données. Cette création s'effectue grâce à la commande suivante : ceph-deploy mds create ceph-mds.

2.6.7 Ça y est ? Ça marche ?

Vérifions la santé du cluster Ceph en exécutant la commande ceph health. Nous obtenons un brutal « HEALTH_OK ». La commande ceph status donne plus d'informations, notamment le nombre de serveurs moniteur (ici 1), le nombre de serveurs de méta-données (ici 1), le nombre de serveurs de données (ici 2), s'ils sont actifs ou non, le nombre de « placement groups », le nombre de pools, le nombre d'objets, la taille totale utilisée et la taille totale disponible :

3. Obtenir l'accès à rbd dans l'hôte debian-virt2

L'hôte debian-virt2 est la machine qui accédera en tant que client au cluster Ceph. Pour ce faire, nous allons lui installer Ceph selon la procédure vue précédemment :

• créer l'utilisateur dup et configurer sudo pour qu'il ait les droits root sans mot de passe (cf. paragraphes « Les clefs ssh des utilisateurs » et « Le sudo total »). Suivre ensuite la procédure décrite au chapitre « Installation du dépôt logiciel de Ceph ». Créer le dossier /etc/ceph (mkdir /etc/ceph).
• sur la machine d'administration du cluster Ceph faire :

• installer Ceph à la main sur la machine hôte (debian-virt2) et vérifier que l'on accède bien au cluster :

• créons un pool pour les objets qui seront des périphériques disques. Cela permettra par la suite de lui donner les propriétés que l'on souhaite comme par exemple pour l'authentification ou la répartition des données :

• créons maintenant deux objets qui deviendront des périphériques sur la machine hôte. L'option --size est en Mi par défaut et l'option -p permet d'indiquer le pool dans lequel on souhaite créer nos objets :

• faisons correspondre les objets dd1 et dd2 du cluster ceph à un périphérique dans l'hôte (le module rbd dans le noyau se charge de créer les bons fichiers blocs dans le système de fichier /dev) :

• vérifions que nous avons bien nos périphériques :

Et voilà... nous avons bien deux périphériques accessibles en mode bloc. Pour s'en convaincre, voyons ce que raconte fdisk :

La sortie de la commande fdisk -lu /dev/rbd/periph/dd2 est identique, à l'octet près. Le disque /dev/rbd/periph/dd1 ne contient pas de table de partitions valable. On peut en créer une ou l'utiliser directement dans un RAID logiciel avec mdadm ou avec un système de fichiers... au hasard... ZFS ?!

Juste pour tester et pour le fun, j'ai lancé la suite de commande suivante :

Et ça marche nickel... Pour agrandir un zpool, on pourra soit choisir d'ajouter des disques, soit choisir de les remplacer un à un (mais alors il faudra bien avoir prévu que les disques remplacés soient dans un raidz1 au moins, sinon c'est la perte de données assurée).

J'ai ajouté 3 disques de 1 Gi et une image disque pour debian de 2 Gi (voir le paragraphe « Obtenir l'accès à rbd dans qemu » ci-dessous). Du coup, il doit me rester 25 Gi environ. Voyons ça :

Et non... Par rapport au statut du début, j'ai utilisé environ 100 Mi... Ceph ne stocke que le strict nécessaire. D'où le conseil donné sur le site du projet de choisir le format raw en ce qui concerne les images de machines virtuelles. En effet, la consommation supplémentaire de ressources (par la machine virtuelle) due au format qcow2 (qui permet notamment de n'enregistrer que les blocs non vides et donc de gagner beaucoup de place) est inutile, car, ici, c'est le système de stockage qui le fait !

4. Obtenir l'accès à rbd dans qemu

Dans la machine virtuelle debian-virt2, l'aide de la commande qemu-img indique (sur sa dernière ligne) quels sont les formats de stockage supportés. Pour pouvoir utiliser le cluster Ceph, il faut que le mot clef rbd soit indiqué (ce n'est pas le cas sur mon système).

4.1 Installation de qemu-kvm pour le support de rbd

Nous allons maintenant recompiler qemu-kvm. C'est pour le moment la seule solution, mais il est possible que cela change dans le futur avec une modularisation dans qemu des backends de stockage qui pourraient être chargés à la volée.

On installe d'abord les parties de développement de librados et quelques outils de développement :

4.1.1 Reconstruction manuelle, à partir du code source (obtenu depuis le dépôt git)

On installe tous les paquets nécessaires avant de télécharger les sources via git. À la date de rédaction de cet article, la dernière version est la v2.0.0 (utiliser git tag pour voir les dernières versions). J'ai enlevé les options --enable-spice et --enable-usb-redir qui posent des problèmes pour la compilation. Pour le moment je n'en ai pas besoin.

La commande qemu-img --version indique bien 2.0.0 et dans les formats supportés (en dernière ligne) on trouve bien rbd :

4.1.2 Ne pas faire de mises à jour malheureuses

Pour éviter la mise à jour des paquets fraîchement installés, utiliser les commandes suivantes :

4.2 Utiliser qemu avec des fichiers stockés dans le cluster Ceph

Le format rbd étant maintenant supporté, il est possible d'indiquer le lieu de stockage des fichiers images des machines virtuelles en préfixant ces derniers par la chaîne rbd :. Dans la pratique, on utilisera des pools pour stocker ces fichiers. Créons un pool « images » qui contiendra les fichiers relatifs aux images de machines virtuelles :

Le format rawest également recommandé pour éviter des problèmes liés au cache lors de la migration des machines virtuelles. Attention pour la commande qemu-img la taille est exprimée en octets ! Du coup, l'image debian que nous venons de créer fait seulement 2 Ki ! Augmentons la taille de cette image :

Pour voir les images qui sont disponibles dans le pool on peut soit lister les objets du pool (l'objet se nomme comme le nom de l'image et possède une extension rbd en plus), soit utiliser la commande rbd -p images list qui ne fournira que les objets qui sont effectivement des images.

On peut également importer une image directement dans le pool (ça prend un peu de temps vu qu'il s'agit de machines virtuelles) :

Maintenant, il est possible de commencer l'installation de la machine en utilisant la commande suivante où l'on spécifie que l'objet debian-7.5.0-i386-netinst.iso du pool « image » est un lecteur hdc (index=3) de type cdrom sur lequel on souhaite démarrer le système (-boot order=d) :

Une fois le système installé, on peut démarrer la machine comme suit (par exemple) :

Conclusion

Dans ce premier article, nous avons vu comment installer un cluster Ceph fonctionnel et comment y accéder à travers une interface de périphériques (rbd) ou pour la gestion de machines virtuelles via qemu. Dans le prochain article, nous verrons un aspect de l'architecture de Ceph, son comportement lors d'événements (prévus ou non) et un exemple de mise en œuvre à grande échelle au CERN.

Références et liens intéressants

[1] Recommandations matérielles : http://ceph.com/docs/master/start/hardware-recommendations/

[2] « check-list » de Ceph : http://ceph.com/docs/master/start/quick-start-preflight/

[3] Cephx : http://ceph.com/docs/giant/rados/configuration/auth-config-ref/