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

GNU/Linux Magazine n° 179 | février 2015 | Olivier Delhomme
Creative Commons
  • Actuellement 0 sur 5 étoiles
0
Merci d'avoir participé !
Vous avez déjà noté cette page, vous ne pouvez la noter qu'une fois !
Votre note a été changée, merci de votre participation !
Stocker plusieurs milliards d'objets ayant une taille totale supérieure à l'exaoctet de manière totalement distribuée grâce à une myriade de petits serveurs relativement peu onéreux, c'est ce que le logiciel libre Ceph est capable de faire !

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.

Note

Certaines sorties écran ont été légèrement modifiées pour des questions éditoriales (ajout de retours à la ligne par exemple). Le développement étant très actif, certaines commandes de la version « emperor » sont légèrement différentes dans les versions « firefly » et « giant ».

Système de stockage objet réparti

Un système de stockage objet enregistre les données sous forme d'objets. L'organisation des objets n'est pas hiérarchique à l'opposé de ce que l'on rencontre dans un système de fichiers qui enregistre les données dans des fichiers se trouvant dans des dossiers et sous-dossiers.

Un système est réparti dès lors que les données sont distribuées sur plusieurs stockages différents (typiquement plusieurs disques durs contenus dans plusieurs machines).

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 :

192.168.122.206   ceph-admin

192.168.122.100   ceph-mds

192.168.122.77    ceph-mon

192.168.122.189   ceph-osd1

192.168.122.5     ceph-osd2

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 :

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

$ echo deb http://ceph.com/debian-emperor/ $(lsb_release -sc) main | sudo tee /etc/apt/sources.list.d/ceph.list

$ echo deb http://ceph.com/packages/ceph-extras/debian $(lsb_release -sc) main | sudo tee /etc/apt/sources.list.d/ceph-extras.list

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) :

$ sudo apt-get update && sudo apt-get install ceph-deploy

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é).

Note

Cette machine pourra également accueillir les outils de surveillance comme par exemple nagios et munin.

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.

Note

Pour un cluster de production, on commencera directement avec 3 serveurs moniteurs : ceph-deploy new ceph-mon0 ceph-mon1 ceph-mon2.

Depuis la version « firefly » de Ceph, le nombre de réplicats pour les données est de 3 par défaut. Si vous souhaitez obtenir un petit cluster fonctionnel (état « active+clean ») avec seulement deux serveurs de données, il faudra indiquer à Ceph que sa valeur par défaut doit être de 2. Pour ce faire, il convient d'ajouter dans le fichier de configuration de Ceph, sous la section [global], la ligne osd pool default size = 2.

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.

Note

ceph-deploy utilise wget pour rapatrier la clef du dépôt ceph. Si vous êtes derrière un proxy il ne faut pas oublier de renseigner la variable http_proxy dans le fichier /etc/wgetrc de chacune des machines virtuelles.

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 :

$ ceph status

cluster a5bf6b38-02f4-43fb-bffc-9c932e98888e

 health HEALTH_OK

 monmap e1: 1 mons at {ceph-mon=192.168.122.77:6789/0},

           election epoch 1, quorum 0 ceph-mon

 mdsmap e14: 1/1/1 up {0=ceph-mds=up:active}

 osdmap e25: 2 osds: 2 up, 2 in

  pgmap v221: 192 pgs, 3 pools, 9470 bytes data, 21 objects

        73652 kB used, 29858 MB / 29929 MB avail

             192 active+clean

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 :

$ cd /home/dup/demo-ceph

$ ceph-deploy admin debian-virt2

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

$ sudo aptitude install ceph

$ ceph status

cluster a5bf6b38-02f4-43fb-bffc-9c932e98888e

 health HEALTH_OK

 monmap e1: 1 mons at {ceph-mon=192.168.122.77:6789/0}, election epoch 1,

                       quorum 0 ceph-mon

 mdsmap e119: 1/1/1 up {0=ceph-mds=up:active}

 osdmap e82: 2 osds: 2 up, 2 in

  pgmap v21296: 236 pgs, 4 pools, 9470 bytes data, 21 objects

        80764 kB used, 29851 MB / 29929 MB avail

             236 active+clean

Note

Ici, nous nous sommes simplifié la vie à outrance et on a transformé notre nœud client en nœud d'administration du cluster ! Dans la vraie vie, on évitera de procéder ainsi et le commun des administrateurs de Ceph regardera en louchant vers cephx [3] et son système d'authentification.

L'installation « à la main » réalisée ici est équivalente à l'utilisation de la commande ceph-deploy install debian-virt2.

- 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 :

$ rados mkpool periph

successfully created pool periph

- 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 :

$ rbd -p periph --size 1024 create dd1

$ rbd -p periph --size 1024 create dd2

- 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) :

$ rbd map periph/dd1

$ rbd map periph/dd2

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

$ ls -ls /dev/rbd/periph/

total 0

0 lrwxrwxrwx 1 root root 10 juin   7 15:58 dd1 -> ../../rbd0

0 lrwxrwxrwx 1 root root 10 juin   7 15:58 dd2 -> ../../rbd1

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

# fdisk -lu /dev/rbd/periph/dd1

Disque /dev/rbd/periph/dd1 : 1073 Mo, 1073741824 octets

255 têtes, 63 secteurs/piste, 130 cylindres, total 2097152 secteurs

Unités = secteurs de 1 * 512 = 512 octets

Taille de secteur (logique / physique) : 512 octets / 512 octets

taille d'E/S (minimale / optimale) : 4194304 octets / 4194304 octets

Identifiant de disque : 0x00000000

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 ?!

# zpool create testpool /dev/rbd/periph/dd1 /dev/rbd/periph/dd2

# zpool status

 pool: testpool

 state: ONLINE

 scrub: none requested

config:

        NAME              STATE     READ WRITE CKSUM

        testpool          ONLINE       0     0     0

          rbd/periph/dd1  ONLINE       0     0     0

          rbd/periph/dd2  ONLINE       0     0     0

errors: No known data errors

# zfs list

NAME       USED  AVAIL  REFER  MOUNTPOINT

testpool  73,5K  1,95G    21K  /testpool

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

# rbd -p periph --size 1024 create dd3

# rbd map periph/dd3

# zpool add testpool /dev/rbd/periph/dd3

# zpool status testpool

 pool: testpool

state: ONLINE

 scrub: none requested

config:

        NAME              STATE     READ WRITE CKSUM

        testpool          ONLINE       0     0     0

          rbd/periph/dd1  ONLINE       0     0     0

          rbd/periph/dd2  ONLINE       0     0     0

          rbd/periph/dd3  ONLINE       0     0     0

errors: No known data errors

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 :

# ceph status

cluster a5bf6b38-02f4-43fb-bffc-9c932e98888e

 health HEALTH_OK

 monmap e1: 1 mons at {ceph-mon=192.168.122.77:6789/0},

            election epoch 1, quorum 0 ceph-mon

 mdsmap e119: 1/1/1 up {0=ceph-mds=up:active}

 osdmap e86: 2 osds: 2 up, 2 in

  pgmap v21630: 252 pgs, 6 pools, 14071 kB data, 38 objects

        100 MB used, 29829 MB / 29929 MB avail

             252 active+clean

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 :

# aptitude update

# aptitude install librbd-dev librados-dev librados2 librbd1 build-essential

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.

# apt-get build-dep qemu

# aptitude install git

# git clone http://git.qemu.org/git/qemu.git

# cd qemu

# git checkout v2.0.0

# ./configure --enable-attr --enable-bluez --enable-brlapi –enable-curl \

 --enable-curses --enable-libiscsi --enable-linux-aio –enable-rbd \

 --enable-sdl --enable-uuid --enable-vde –enable-vhost-net \

 --enable-virtfs --enable-vnc --enable-vnc-jpeg –enable-vnc-png \

 --enable-vnc-sasl --enable-vnc-tls –enable-xfsctl

# make

# make install

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

$ qemu-img --version

qemu-img version 2.0.0, Copyright (c) 2004-2008 Fabrice Bellard

usage: qemu-img command [command options]

QEMU disk image utility

...

Supported formats: vvfat vpc vmdk vhdx vdi ssh sheepdog sheepdog sheepdog rbd raw host_cdrom host_floppy host_device file qed qcow2 qcow parallels nbd nbd nbd iscsi dmg tftp ftps ftp https http cow cloop bochs blkverify blkdebug

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 :

# echo "kvm hold" | dpkg --set-selections

# echo "qemu-kvm hold" | dpkg --set-selections

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 :

$ rados mkpool images

successfully created pool images

$ qemu-img create -f raw rbd:images/debian 2048

Formatting 'rbd:images/debian', fmt=raw size=2048 cluster_size=0

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 :

$ qemu-img resize rbd:images/debian 2G

Image resized.

$ qemu-img info rbd:images/debian

image: rbd:images/debian

file format: raw

virtual size: 2.0G (2147483648 bytes)

disk size: unavailable

cluster_size: 4194304

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) :

$ rbd import debian-7.5.0-i386-netinst.iso images/debian-7.5.0-i386-netinst.iso

Importing image: 100% complete...done.

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) :

$ qemu -drive file=rbd:images/debian-7.5.0-i386-netinst.iso,index=3,media=cdrom \\

       -drive format=raw,file=rbd:images/debian -boot order=d -m 256

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

$ qemu -drive format=raw,file=rbd:images/debian -m 256

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/

Tags : Ceph, stockage