Stockage distribu : retour d'exprience avec

CEPH
Yann Dupont
DSIN / Universit de Nantes
2, rue de la houssinire
44322 Nantes

Rsum
LUniversit de Nantes s'est penche depuis 2005 sur la haute disponibilit des systmes, essentiellement pour des
raisons pratiques : il fallait trouver un moyen d'assurer un service de qualit malgr les incidents rptition dans ses
salles machines.
Au fil des ans, diffrentes plates-formes ont t dployes pour sacquitter de cette mission, assurant la haute
disponibilit des services, mais faisant l'impasse sur la question du stockage. Celui-ci est toujours rest architectur
autour de SAN dont les nombreuses baies de stockage centralises constituent pourtant un point unique de dfaillance.
Nos critres de choix tant fiabilit, simplicit, performance et cot, aucun autre systme de stockage disponibilit
plus leve ne rpondait ce cahier des charges.
CEPH (logiciel open source), faisait partie des candidats surveills depuis quelques annes. Il dispose de nombreux
aspects techniques particulirement originaux et a suffisamment mri en 2012 pour engager une tape de
pr-production, puis passer en production dbut 2013.
Ce retour d'exprience reviendra sur les diffrences fondamentales entre les solutions de stockage traditionnelles
prcdemment dployes et un systme massivement distribu comme CEPH. Il dtaillera galement les gains, limitations
et risques associs. Les quelques msaventures subies en phase de pr-production, maintenant bien comprises, ont t
mises profit pour trouver des solutions. Le syndrome de tous les ufs dans le mme panier est ainsi vaincu en
dployant plusieurs clusters indpendants reposant sur une architecture virtuelle commune.

Mots-clefs
Stockage distribu, SAN, CEPH, open source, clusters, haute disponibilit, LINUX

1 Stratgie de stockage
La DSIN1 de l'Universit de Nantes a choisi en 2003 de grer ses donnes en sparant nettement les aspects stockage (sur
du matriel ddi) et traitement (sur des serveurs). La mise en place de plusieurs rseaux SAN2 fibre channel tendus sur
lagglomration en a t la consquence directe.
Conjointement la virtualisation massive de nos services, qu'elle a contribu rendre aise, cette infrastructure ddie
de stockage, performante, extensible et fiable a t la base technique sous-jacente. Elle s'est aussi avre conomique
grce l'usage de petites baies de stockage (16 24 disques), tolrantes la panne 3, capables d'un taux d'entres/sorties
lev et pourtant peu onreuses car simples et fonctionnellement pauvres, sans redevance logicielle. Nos serveurs
fonctionnant tous sous LINUX, (les serveurs WINDOWS sont virtualiss) ils disposent de toutes les solutions pour grer eux
mme efficacement ces services avancs (snapshot, synchronisation, dplacement chaud). Nous sommes agnostiques
quant aux baies de stockage dployes (quatre constructeurs diffrents au fil du temps et des marchs publics).
La croissance du volume gr a simplement consist multiplier les baies au fur et mesure des besoins, ce qui a
galement augment la capacit totale de traitement de faon linaire : le nombre de canaux et de contrleurs ddis
crot en mme temps que le nombre d'axes. Il est aussi possible de spcialiser des baies ou des parties de baies (type de
disques, de RAID, taille de cache) lorsque des usages spcifiques sont envisags, ou au contraire, agrger virtuellement
1. Direction Des Systmes d'Information et du Numrique.
2. Storage Area Network. Rseau ddi spcialis pour le stockage, utilisant des protocoles spcifiques historiquement incompatibles avec l' Ethernet,
tels que le Fibre Channel, ou compatible tels que l'iSCSI, l'AOE (Ata Over Ethernet), le FcoE (Fibre Channel Over Ethernet)...
3. Contrleurs doubles dots de nombreux canaux fibre channel permettant des chemins indpendants via deux fabriques SAN disjointes.

JRES 2013 Montpellier

1/11

plusieurs baies en un seul ensemble logique. Les donnes sont accessibles au travers d'un priphrique de type bloc
accs exclusif, exactement comme un disque dur local. Pour les besoins d'accs multiples et concurrents, des services de
systme de fichiers en rseau ( NFS, CIFS) coupls aux annuaires LDAP sont dploys et font office d'interfaces NAS
spcialises.
La construction de cette solution hybride multipliant les lments permet d'isoler des flux et garantir une qualit de
service relle, ncessit due la diversit des besoins grs. Ainsi, une charge induite par des TP d'informatique ne
perturbent pas les performances du courrier lectronique du personnel, les dossiers (homedirs) des tudiants et le
courrier lectronique tant stocks sur des baies diffrentes (empruntant des canaux spars).
Il a ainsi t possible d'accompagner toutes les volutions de besoins de stockage de l'universit et de raliser de trs
nombreux projets fdrateurs d'importance (stockage de fichiers pour les tudiants, personnels et quipes de recherche,
messageries, espaces collaboratifs, bases de donnes, bibliothques vidos, support de projets de recherche, etc) tout en
matrisant les investissements.

1.1

Haute disponibilit et stockage centralis

Pour des raisons historiques, la quasi totalit de notre matriel
informatique tait hberge dans deux petites salles machines,
proches gographiquement et la fiabilit relative 4. Au fil des
annes et des volutions politiques, nous avons pu utiliser de
nouvelles petites salles machines5, permettant de minorer le
risque, puis mettre en place une plate-forme de dploiement
redonde, rpartie sur trois plaques gographiques distantes de
plusieurs kilomtres. Prsente lors d'une prcdente session
des JRES [1], celle-ci nous assure une trs haute disponibilit
de nos services6, mais exclut malheureusement le stockage.
Une des dernires phrases de l'article pointait bien cette limite
et prfigurait le prsent article : La dernire solution, la plus
en phase avec la philosophie de nos dploiements, est de
dployer des systmes de fichiers distribus, tels que GLUSTERFS
ou CEPH. Malheureusement, ces technologies trs intressantes
mais complexes sont peine matures et nous ne les avons pas
encore qualifies pour une phase de dploiement

Ceci rsume bien la complexit de la question, laquelle nous

nous heurtions depuis de nombreuses annes. En 2012, les
Figure 1 - Plate-forme haute disponibilit de donnes taient toujours essentiellement concentres en un
l'Universit de Nantes
point gographique unique. Or, celles-ci constituant le
patrimoine de l'tablissement, le risque majeur tait avr ; en cas de sinistre important (incendie, etc.), outre
l'interruption de service, c'tait surtout la survie des donnes qui tait en jeu. La problmatique tait alors partiellement
adresse par des sauvegardes dportes et des synchronisations de volume graduellement mises en place, mais une
solution plus globale devait tre envisage, d'autant que l'aspect sret des donnes n'tait pas le seul point considrer.

1.2

La fin d'une logique

L'augmentation incessante du volume des espaces de stockage (plus de 500 To utiles, rpartis sur une trentaine de baies
de disques, avec une utilisation parfois peu rationnelle) a augment la complexit de manuvre de cette plate-forme
sans que des moyens humains supplmentaires dvolus cette tche ne soient dgags. Les pressions budgtaires
toujours plus fortes invitent aussi une convergence du monde du stockage et celui du rseau traditionnel.
De faon assez claire, le constat est que nous sommes alls au bout de notre logique dcide il y a dj longtemps. Il
tait devenu ncessaire d'voluer progressivement vers une technologie distribue, rsistant mieux au facteur d'chelle,
plus tolrante aux pannes et mieux intgre.

4. Ou non politiquement correct : salles non initialement prvues cet usage, l'instabilit chronique, sources continues de soucis en tout genres .
5. Pas forcment plus fiables. La construction d'un datacenter viendra clore ce chapitre malheureux dbut 2015.
6. De nombreuses pannes, vcues comme autant de tests grandeur nature pour la plateforme, permettent d'assurer que le terme n'est pas galvaud.

JRES 2013 Montpellier

2/11

2 voluer en douceur
Notre recherche s'est oriente vers un remplacement quasi transparent de l'ancienne plate-forme, retenant ses qualits et
gommant ses dfauts ; la nouvelle solution se devant de rester compatible avec les services dploys (compatibilit
POSIX totale requise) et les logiciels de virtualisation 7 existants, tre simple utiliser, sans ncessiter de logiciels ou
pilotes propritaires (voire exotiques) et bnficier d'une intgration directe dans les distributions LINUX8.
Pour s'intgrer notre plan continu d'activit, l'architecture du stockage doit tre structure similairement la
plate-forme dhbergement haute disponibilit et tirer parti de nos trois points de prsence gographique de faon
multi-active et sans point unique de faiblesse. En cas de panne d'une salle machine, les deux salles restantes doivent
assurer le service sans intervention humaine, tout comme le retour l'tat nominal qui doit s'effectuer de faon
automatique. Les donnes doivent donc tre places de faon intelligente.
La solution doit tre capable d'un passage l'chelle important (au del du ptaoctet), tout en simplifiant
l'administration au quotidien (mise disposition de nouveaux volumes), en optimisant le volume de donnes utilis, et
autant que possible, sans dgrader les performances, prserver une qualit de service et tre conomiquement viable.
L'ensemble de ces pr-requis reprsente une belle lettre au pre Nol.

2.1

Recherche de solutions adquates

Eu gard aux contraintes conomiques et de volumtrie, une solution propritaire a rapidement sembl hors de porte ;
toutefois, la recherche d'une rponse au travers des solutions open source a pris des allures de qute du Graal.
Gnralement, l'offre se structure autour de systme de fichiers distribus, de type NAS, permettant un accs concurrent
et multiple, autorisant une bonne souplesse de fonctionnement, mais pas forcment des performances leves
(complexit de gestions des verrous, synchronisation des mta-donnes...). LUSTRE[2], GLUSTERFS[3], HEKAFS[4], MOOSEFS[5],
ROZOFS[6] et CEPHFS font partie de solutions faisant l'objet de veille technologique depuis des annes. Elles ont chacune
leur intrt propre, mais prsentaient aussi des problmes de maturit, de fonctionnalits ou de performances, et aucune
n'avait la dimension globale recherche.
Il s'avre que pour une bonne partie de nos applications hberges, un accs exclusif est suffisant. Il a le mrite de se
calquer sur notre ancien mode de fonctionnement (mise disposition d'un LUN pour chaque nouveau besoin), de rester
simple, d'avoir moins de latences (moins de serveurs traverss) et donc d'tre globalement plus performant.
Mais les solutions orientes bloc ne sont pas lgion. OCFS2[7], GFS2[8] sont des systmes de fichiers en grappe (de
type cluster ). Ils permettent un accs multiple de type actif/actif pour de multiples serveurs partageant une ressource
commune, telle une baie SAN. En soi, cela n'adresse pas la problmatique de la scurisation des donnes, sauf si la baie
sous-jacente est rplique de faon synchrone en deux lieux distants, ou en utilisant un systme de rplication de
priphriques blocs, tel DRBD9[9] pour arriver ses fins.
CEPH[10], quant lui, autorise plusieurs modes de fonctionnement, dont un en mode bloc, constituant en cela une de ses
originalits et ayant de fait, suscit tout notre intrt. Nous l'avons surveill pendant quelques annes et attendu
patiemment sa maturation.

3
Ce logiciel open source (Licence LGPL) fait suite aux travaux de Sage Weil durant sa thse[11]. Il fonctionne
actuellement uniquement sous LINUX10. Il est compos d'une partie client, jouissant d'une intgration native dans le noyau
standard depuis mars 2010, et d'une partie serveur, plus complexe, base sur un ensemble de dmons fonctionnant en
espace utilisateur. Depuis 2011, une socit, (INKTANK), a t cre pour assurer le support et rtribuer les dveloppeurs.
Il est temps plonger dans les entrailles de CEPH, en se limitant au strict ncessaire pour comprendre notre
implmentation.

3.1

Concepts

7. Utilisation de libvirt avec les pilotes KVM et LXC, avec pour chacun un accs direct des volumes et non un fichier image.
8. La compatibilit avec une version de Debian doit tre assure.
9. Mode actif/actif possible partir de la version 8, mais qui n'est pas foncirement conseill sur leur site.
10. Des portages sont envisags sous BSD, pour d'autres OS une utilisation indirecte travers des couches CIFS, NFS voire ISCSI reste possible.

JRES 2013 Montpellier

3/11

 la base de CEPH se trouve

serveurs indpendants.

RADOS,

un systme de stockage d'objets rpartis, l'intgrit auto rgule, gr par des

Une API ainsi qu'une librairie, LIBRADOS, permet une application dinteragir directement avec ce stockage d'objets. CEPH
utilise cette librairie pour fournir de base, trois services principaux l'utilisateur :
Figure 2 - : Architecture de CEPH

Figure 3 - : Architecture de CEPH

une interface directe au stockage objet, RADOSGW,

compatible avec les protocoles de stockage S3 et SWIFT11,
une interface de type block, nomme RBD, directement
utilisable par un client LINUX. Il s'agit d'un vritable SAN
virtuel,
une interface de type systme de fichiers en rseau ,
appele CEPHFS, utilisable par un client LINUX. Il s'agit
d'une interface de type NAS.

Ici rside une des originalit de CEPH. Sa versatilit est forte,

puisqu'il peut tre utilis au sein de projets spcifiquement
dvelopps pour du stockage massif de donnes, mais aussi en
remplacement direct de services de stockage traditionnels,
quelle que soit l'ancienne technologie utilise. C'est cet usage

basique qui nous intresse en premier lieu.

3.2

Stabilit et tat des dveloppements

Le dveloppement du produit, trs actif, jouit d'un rythme de publication bien tabli : une version exprimentale fige
toutes les deux semaines et tous les 3 mois, une version de rfrence, stabilise, faisant l'objet d'un support tendu.
Celle-ci, affuble d'un nom de cphalopode12 dont la premire lettre indique la gnration, est indique pour tout usage
srieux. Emperor , version 0.72, sortie le 9 novembre 2013, constitue donc la 5me itration de la solution.
Le numro de version est infrieur 1.0 car tous les lments ne sont pas au mme stade de maturit : RADOS, RADOSGW et
RBD sont stables depuis la version 0.48 ( Argonaut , sortie en juillet 2012). CEPHFS est moins mature, ses performances
sont considres comme non optimales et le fonctionnement des serveurs de mtadonnes en mode multi-actif est connu
pour tre encore parfois problmatique. CEPHFS est donc actuellement dconseill en support d'applications sensibles.

3.3

Sous le capot...

La partie serveur de cEPH est assure par 3 types de dmons diffrents dployer :

OSD (Object Storage Daemon): son rle est simplement de stocker efficacement des objets. Il utilise le disque
local du serveur, via un systme de fichiers local classique (XFS, BTRFS, EXT4).
MON (MONitor daemon) : son rle est de vrifier le bon tat du cluster, assurer la communication initiale avec les
clients et vrifier les droits d'accs.
MDS (MetaData Server daemon) : son rle est de grer les mta donnes pour CEPHFS.

L'ensemble de ces dmons, dploys en nombre sur des machines, constitue un cluster CEPH. Celui-ci ne comporte
aucun point de faiblesse unique, tous les lments tant redonds volont et fonctionnent en mode multi-actif.
Toutes les volutions de topologie modifient automatiquement des maps stockes dans le cluster et versionnes.
Vritables garanties de la cohrence de celui-ci, elles sont distribues tous ses lments constituants.
Il est souhaitable d'installer un nombre impair 13 de MON et autant d'OSD que ncessaire, puisque la volumtrie totale en est
directement dpendante. L'installation de MDS est optionnelle si l'utilisation de CEPHFS n'est pas envisage. Enfin, des cls
de scurit doivent tre dployes pour scuriser les changes. Un script, ceph-deploy, permet dsormais de simplifier
l'ensemble des tapes d'installation pour l'administrateur. L'ajout de MON et MDS est ralisable a posteriori, tout moment
et de manire dynamique.
11. S3 : Amazon Simple Storage Service, interface trs populaire. SWIFT : stockage simple d'objet dvelopp par Openstack.
12. D'o le nom de CEPH. Le premier logo reprsentait une pieuvre, dsormais remplace par une version stylise.
13. Pour viter le phnomne de split brain , qui, dans le cas d'une panne rseau, divise le cluster en deux parties strictement gales, empchant
ainsi un quorum permettant de dcider de faon sre quelle partie est rellement inaccessible et donc, en panne. Dans les faits, 3 mon suffisent.

JRES 2013 Montpellier

4/11

L'espace disponible s'accrot automatiquement chaque nouvel OSD ajout et intgr activement. Pour ce faire, ce
dernier doit tre dot d'un poids14, et insr dans une arborescence. L'administrateur peut y dfinir finement son
placement grce aux notions de datacenter, salle, etc. En l'absence d'action de l'administrateur, tous les OSD sont placs
dans un rack inconnu , au mme niveau. Plusieurs arborescences peuvent coexister et le critre gographique n'est
pas le seul possible (la capacit d'entres/sorties pouvant en constituer une autre).
L'espace de stockage global gnr par les

OSD

root default
datacenter loi
room loire-presidenc
rack karuizawa
host ceph-osd-loi-A-1-1
osd.12 up
rack hazelburn
host ceph-osd-loi-A-2-1
osd.15 up
datacenter lmb
room lombarderie-ltc
rack kavalan
host ceph-osd-lmb-A-1-1
osd.6 up

Figure 4 - Extrait d'une hirarchie d'OSD

est adressable via des pools , initialement au nombre de trois la

cration d'un nouveau cluster. Chacun associe une des arborescences
d'OSD des rgles de placement et de rplication de donnes au sein de
la CRUSH map stocke au sein du cluster. Celle-ci ressemble ce qui
est illustr Figure 4 -. Elle peut tre extraite et dite la main, ou
manipule directement au travers d'outils en ligne de commande, afin
de modifier le poids ou le placement d'un OSD, par exemple. Elle est
nomme daprs l'algorithme de placement des objets CRUSH[13], au
sein de CEPH. Un systme de permissions bas sur des cls partages
protge les ressources. Seul un client possdant la bonne cl pourra
accder un pool de stockage donn.

3.4

Rplication des donnes

Chaque pool est divis en de nombreux groupes de placement ( PG).

L'algorithme CRUSH permet, en fonction des rgles dfinies dans la
CRUSH map courante, de dterminer automatiquement pour un PG
donn, les OSD de stockage (primaire et secondaires). Chaque client du
pool est capable de raliser ce calcul.

Toute donne stocke dans CEPH est dcoupe en blocs de taille fixe.
Pour un volume RBD, cette taille (4 Mo par dfaut) est dpendante du pool auquel il appartient. Ces fonctions de
dcoupage sont assures par le client. Chacun de ces fragments est ensuite assign un PG. Grce l'algorithme CRUSH,
le client qui veut lire ou crire un morceau de la donne connat les OSD concerns et va contacter directement le
primaire. En cas d'criture, l'OSD primaire stocke les donnes dans son dpt d'objets local, puis s'occupe d'envoyer les
donnes sur les OSD secondaires et attend un acquittement. Une fois celui-ci obtenu, lui mme envoie un acquittement au
client. Le processus est donc synchrone.
Ici se trouve une autre originalit de CEPH. Tous les clients sont intelligents et assurent, en autonomie, une grosse
partie du travail. Ils contactent directement les OSD sans intermdiaire assurant la fois de bonnes performances, une
paralllisation importante et, par voie de consquence, une forte capacit de rsistance au facteur d'chelle.

3.5

Gestion des pannes

En cas de panne ou dysfonctionnement de l'un des OSD, une dtection par les MON ainsi que les autres OSD va exclure
temporairement le fautif du cluster ; certains PG se trouvent alors dgrads, amputs, soit de l'OSD primaire, soit d'un des
secondaires. Dans le cas le moins favorable (rplicat du pool fix 2), ces PG ne disposent plus que d'une seule copie
valide des donnes, considres alors en danger. Si l' OSD fautif n'est pas rapparu au del d'une courte priode (5 minutes
par dfaut), un processus de reconstruction automatique est engag, consistant redupliquer les donnes impactes sur
des OSD de substitution.
Chaque OSD assure galement un auto diagnostic et vrifie l'intgrit des PG qu'il gre une fois par jour de faon lgre et
une fois par semaine de faon complte. Ces vrifications ne s'oprent que lorsque l'OSD est peu sollicit.
Il est maintenant temps de refermer le capot et de se concentrer sur l'utilisation de CEPH en tant que client.

3.6

Interface avec l'utilisateur

CEPH, intgr au noyau LINUX depuis 2010, bnficie d'un support natif au sein des distributions les plus rpandues,
simplifiant en cela son utilisation.
Un client ncessite deux lments : un fichier de configuration, ceph.conf qui doit, au minimum contenir la liste des
serveurs MON, ainsi qu'un trousseau de clefs, contenant le ncessaire pour accder aux pools souhaits.
14. Qui correspond en gnral la quantit de donnes qu'il est capable de grer (taille du volume local).

JRES 2013 Montpellier

5/11

Ici, l'exemple d'un client appel CIE. Le gestionnaire du cluster lui a donn la possibilit d'accder au pool INFO:

[client.CIE]
key:AQCAfXXX6FrhIRAAZgtXXXdbeRmcBmfbSjY0tg==
caps: [mon] allow r
caps: [osd] allow * pool INFO

[global]
auth cluster required = cephx
auth service required = cephx
auth client required = cephx
[mon]
[mon.a]
host = ceph-mon-cha-B-1
mon addr = 172.20.106.84:6789

Ici, pour rfrence, les permissions associes au client, ct cluster.

ceph.conf allg, mais suffisant ct client .
Un client aura seulement besoin des 2 premires lignes (la clef)
Figure 1 - Trousseau de cl et fichier ceph.conf, ct client

## Montage de type CEPHFS

mount -t ceph -o name=CIE,secretfile=/etc/ceph/secret-CIE 172.20.106.84:/prj /mnt/
## Acces a RBD
rbd map INFO/grosvolume --id CIE ## mappe le volume grosvolume du pool INFO
mount /dev/rbd/INFO/grosvolume /mnt2 ## le volume peut tre utilis

L'exemple ci-dessus dtaille les accs une ressource

similaire celle de NFS ( l'identification prs).

CEPHFS,

et un volume

RBD.

La syntaxe d'accs

CEPHFS

est

L'accs une ressource RBD est diffrente mais reste toutefois simple. Puisqu'il s'agit d'un volume de type bloc, celui-ci
aura t pralablement format avant utilisation. Ces volumes sont aussi directement utilisables depuis l'hyperviseur
KVM, constituant en cela un choix intressant ds lors que la migration chaud de machines virtuelles est considre.

3.7

Fonctions avances

La cration instantane de volumes sur un pool donn l'aide d'une technique de sur-rservation (dite de thin
provisionning ) permet une utilisation rationnelle et conomique des ressources : l'espace n'est pas allou
immdiatement mais au fil de l'eau, l'utilisation du volume.
Les snapshots de volumes volont sont grs, avec d'une part, la possibilit de retour arrire mais d'autre part la
possibilit de les utiliser comme image matre de copies indpendantes, utilisables ultrieurement. Une utilit
immdiate apparat dans le cadre de la cration de patrons (masters) pour machines virtuelles. Le processus utilise un
mode copy on write o seules les modifications apportes la copie par rapport l'original consommeront de
l'espace dans le cluster, autorisant un gain de place particulirement important. La nature dlocalise de CEPH fait qu'il
est possible de grer ce processus de faon globale l'ensemble d'un tablissement.

4 Gense de l'implmentation et retour d'exprience

L'adoption de solution logicielle open source encore jeune expose de facto des alas de fonctionnement. Toutefois, au
fur et mesure que l'quipe commence mieux intgrer la solution, et que celle-ci, de son cot, volue et se stabilise,
un design itratif nourri des problmes rencontrs se construit. Il est alors important de ne pas brler les tapes, de bien
valuer les risques et valider la solution sous peine de gros dsagrments. Plusieurs points sont rests communs au fil
des dploiements ; citons le placement des lments (cf Figure 5 -), rest globalement identique celui de notre
plate-forme d'hbergement de services et ncessaire pour atteindre le niveau de tolrance la panne requis : ces trois
points de prsence, symtriques, tant indpendants d'un point de vue lectrique et vis vis du matriel rseau et des
raccordements optiques associs.
Ne faisant pas l'objet d'achats spcifiques, la plate-forme a t monte avec le matriel existant. Pour chaque point

JRES 2013 Montpellier

6/11

gographique, des serveurs connects des baies locales, offrant des disques de 2 To agrgs en RAID5 ont t mis
contribution pour assurer un espace confortable cette plate-forme. Pour ne pas trop restreindre la quantit de donnes
stocker, il a t dcid de se limiter seulement deux copies, divisant tout de mme l'espace utile par deux.

4.1

Premier essai

Un nombre trs limit d'OSD tait dploy par plaque gographique, chacun grant plus de 10 To au moyen de BTRFS, le
systme de fichiers alors prconis. Mais, rapidement des problmes de performance et de stabilit sont apparus. Puis,
une panne (encore !) d'onduleur a priv d'alimentation tous les serveurs d'un mme site. Au redmarrage, 2 des 3 OSD ont
vu leurs donnes irrmdiablement dtruites. Il s'est avr que ces diffrents soucis taient imputables BTRFS, alors trop
jeune. L'erreur principale de ce premier design a t de garder des rglages proches des standards, dont une CRUSH
map ne dfinissant pas l'arborescence des placements. La perte simultane de 2 OSD dans ce contexte a signifi la perte
irrmdiable de donnes, tous les OSD tant alors considrs quivalents, sans critre de localit.

4.2

Second essai

a t abandonn au profit de XFS15, le nombre d'OSD a t augment, pour grer moins de donnes (4 To) et les
rgles de placement de donnes ont t rvises, un PG devant rpliquer ses donnes sur deux plaques gographique
spares.
BTRFS

Aprs un fonctionnement parfait pendant plus de quatre mois et une rsistance avre de nombreuses incidents
(provoqus ou involontaires), un autre crash a toutefois t dplor.
Afin de raliser des tests de charge et de performance, un noyau LINUX rcent (3.6) venait d'tre install sur les serveurs.
Pour ces mmes raisons, notre espace de stockage tait bien rempli. L'algorithme de placement des PG n'a pas rparti les
donnes de faon compltement uniforme16 et deux OSD taient quasiment pleins.
Pendant un week-end, une machine a connu des problmes de stabilit, essentiellement pour des raisons de bugs
d'allocation mmoire, imputables au noyau mentionn. Ceci a dclench la reconstruction des 4 To dgrads. Ce
processus stressant a gnr un plantage identique de deux nuds supplmentaires, et la recopie d'une masse de
donnes encore plus importante, aboutissant in fine, un effet boule de neige dvastateur. la fin du week-end, les OSD
taient soit tous pleins, soit inoprants et donc, inaccessibles.
Contre toute attente, le redmarrage des machines plantes s'est extrmement mal pass. Cette fois, un bug de XFS17 a
dfinitivement corrompu les donnes d'une partie de nos serveurs. Contact suite notre msaventure, Dave Chinner,
dveloppeur XFS, a corrig trs rapidement le bug, mais trop tard pour nos donnes de test.
Bien qu'il s'avre que CEPH ne soit en rien coupable de cet incident, il a mis en lumire que la stratgie utilise tait
revoir. Les risques inhrents de tels dploiements taient nouveaux, complexes apprhender, et avaient
potentiellement un impact dvastateur. Il fallait donc pouvoir les viter au mieux.

4.3

Troisime essai et plate-forme de production

Afin d'viter l'effet domino, la stratgie ne pas mettre tous ses
ufs dans le mme panier a t applique :

il y aura dsormais plusieurs clusters, fonctionnant de

faon parallle sur des machines physiques communes.
Ceci permettra aussi d'avoir des versions de CEPH
diffrentes, une administration spare et une porte des
risques limits. Chaque MON, MDS, OSD aura ses propres
machines virtuelles et volumes de donnes spars,

pour chaque cluster, la multiplication des OSD pour grer

des volumes plus petits (1 2 To maximum) afin de
limiter les dommages collatraux. Faire fonctionner un
systme de fichiers comprenant plusieurs millions
Figure 5 - Une partie de l'infrastructure CEPH
d'entres et occupant plusieurs To restant une opration
risque. En cas de panne ou dysfonctionnement, (qu'elle soit matrielle, logicielle), une tape de vrification du

15. N 'tant pas les seuls avoir subi une telle dconvenue, XFS est maintenant le systme de fichiers local recommand.
16. C'est toujours vrai , mme si les algorithmes ont t amliors depuis.
17. Bug introduit dans la version 3.0 du noyau, li une mauvaise gestion des journaux et capable de dtruire le systme de fichiers.

JRES 2013 Montpellier

7/11

disque doit tre engage. En dpassant la dizaine de millions de fichiers, la structure du systme de fichiers
devient extrmement complexe, et le rsultat de l'tape de vrification devient alatoire par la faute d'un bug
logiciel, d'une saturation mmoire, ou simplement d'un temps d'accomplissement incompatible avec les
contraintes d'exploitation,

toujours veiller garder un espace libre, pour viter les OSD pleins et pour pallier d'ventuelles reconstructions,

considrer les nuds du cluster comme des botes noires et limiter les changements logiciels au strict minimum.

200 To bruts de stockage ont t mis disposition (3 sites de 2x32 To en Raid5), soit 52 To utiles par site (2x26 To).
Sur chaque site gographique, 3 4 machines physiques hbergent les OSD de chaque cluster. N'ayant pas de besoins
spcifiques, les MON et MDS sont eux accueillis sur des serveurs de mutualisation.
Les clusters suivants ont t dmarrs :

A : production. Uniquement des versions 'stables et long terme' de CEPH. Actuellement en version
Dumpling (v0.67.4), constitu de 39 OSD, grant 78 To bruts, pour 39 To utiles (2 rpliquas) ;
B : exprimental. Les versions de dveloppements sont autorises, et permettent de tester les nouvelles
fonctionnalits. Les donnes stockes sur ce cluster ne peuvent tre considres comme vitales l'exploitation. Il
est actuellement en v0.71, constitu de 21 OSD, pour 10,5 To utiles (2 rpliquas).

peine plus de la moiti de l'espace de stockage physique est allou, nous permettant, en cas de besoin, d'augmenter les
espaces accessibles aux OSD de chaque cluster. Avec ces changements, la plate-forme s'est rvle trs stable sur
plusieurs mois, nous conduisant dmarrer la production dbut janvier 2013. Elle fonctionne sans soucis depuis.

5 Bilan de l'utilisation de la plate-forme en production

Eu gard aux problmes rencontrs, la confiance initiale dans la plate-forme tait modre. Le premier usage a t de
stocker des duplications de sauvegarde. Au fil du temps, la confiance est revenue et les sauvegardes sont dsormais
stockes, de manire primaire, sur des volumes RBD. Celles-ci occupent le cluster A , et des dizaines de millions de
fichiers sont sauvegards quotidiennement. Nous avons aussi profit de l'importante capacit disponible pour des
processus de migration (gros volumes de baies de stockage traditionnelles, dplacement de donnes de vieux serveurs
non relis au SAN, cration d'images de disques durs temporaires, etc)
Des services exprimentaux ont aussi t initis, en particulier un service de stockage de fichiers personnels sur le
cluster B. Le systme est actuellement bas sur CEPHFS18, mais une utilisation de RADOSGW (via l'API S3) est envisage. Des
systmes de gestion et d'analyse massif de journaux (logs) ont galement t installs. Ce cluster sert aussi valider
certains paramtres et rglages.

5.1

Bnfices l'utilisation

Si la mise en place de la solution reste une opration relativement complexe, surtout dans un contexte de dploiement
multiples de clusters, son utilisation est en revanche trs simple. Mais plus important encore, l'administration des
espaces est galement nettement plus simple que sur un SAN : plus d'oprations de zoning ou de LUN masking effectuer,
plus de maintenances de commutateurs fibre channel. La scurisation des donnes est intrinsque et offre une haute
tolrance de panne (sinistre majeur), en parfaite adquation avec nos objectifs de PCA.
L'aspect global d'une telle solution permet une utilisation du stockage n'importe quel endroit de l'Universit, et ne
devient presque plus qu'une simple question de dbit d'accs de nos diffrents sites universitaires.
Le gain en terme de souplesse est particulirement important ; la mise disposition de volumes de plusieurs To pour un
projet spcifique demande quelques secondes, de mme que la mise disposition d'images de serveurs prts
l'emploi .

5.2

Performance

La performance des systmes de stockage distribu fait l'objet d'pres comparatifs et de nombreux tests. Nous en
ralisons nous-mme rgulirement pour valider nos choix. Cet article n'en exposera pas, tant par manque de place que
parce que de nombreuses tudes de performances sont publies. Enfin, les chiffres publies serait peu pertinents, notre
plate-forme d'hbergement n'tant pas homogne (plusieurs gnrations de serveurs, les plus lents ralentissant
l'ensemble). Les copies tant synchrones, la rpartition sur trois sites distants de plus jusqu' 13 kilomtres induit
18. Owncloud et Pydio ont t tests, mais aucune solution ne semble encore tout fait mature pour un dploiement large chelle.

JRES 2013 Montpellier

8/11

galement une latence sensible (0,44 ms).

valuer la performance d'un systme ne se limite pas lancer quelques benchmarks surtout s'ils sont mono threads,
alors qu'une des forces du systme est sa monte en charge lors d'oprations parallles. Des tests en situation relle ont
ainsi dmontr l'intrt d'outils multi-threads tels que mcp19[14] pour augmenter trs fortement les dbits.
Disons simplement qu'avec un peu de rglage fin, la partie RBD peut saturer un lien 10 Gb/s et dans la plupart des tests,
les performances obtenues sont proches moins de 30 % de la plupart de nos baies classiques. Pour le dire simplement,
la performance est suffisamment bonne pour nos usages et permet, tant en terme de fonctionnalits qu'en terme de
performances, d'envisager le remplacement des baies de stockage SAN dans la majorit des cas.

5.3

Limitations

Le paragraphe 3.4 a montr que les critures entre OSD sont synchrones, limitant les performances mais dont
l'impact peut tre rduit grce au cache local des serveurs et une gestion optimise du read-ahead . Ainsi, les
performances restent trs correctes sur un plan mtropolitain. Dans un cadre rgional ou national, il est probable
que le problme deviendrait prgnant. Des dveloppements vers la mise disposition d'une rplication
asynchrone sont en cours.
Chaque client communique directement avec les OSD, MON et MDS dploys, impliquant un routage et une gestion
des filtrages rseaux en entre de site appropris. Ceux-ci doivent tre adapts 10 Gb/s et capables d'absorber
le flux induit. Dans le cas de machines faisant fonctionner des applications critiques, des vlans bien identifis
(isols) et restreints l'accs de la plate-forme CEPH doivent tre dfinis.
En terme de scurit et contrle des accs, la granularit se situe au niveau du pool et non pas des volumes, ce
qui aurait t prfrable pour nos besoins.
Il n'est pas possible de dployer de rels mcanismes de QoS. Une gestion fine des pools, conjointement du
shaping au niveau rseau permettrait d'y arriver, mais la situation est loin d'tre quivalente notre existant.
Le thin provisionning des volumes n'est pas dnu de risques. Une ide nave est que l'allocation des PG est
fonction directe de l'usage du systme de fichiers ; pourtant un usage cumulatif se traduisant par le remplissage
progressif des PG du pool est constat. En ralit, lorsque des donnes sont effaces du systme de fichiers, le
priphrique de type bloc n'est pas averti : les PG ne sont alors pas librs. Pour faire le lien et informer la couche
sous-jacente, il faut le support des fonctions TRIM. KVM supporte cette fonctionnalit, mais pas encore le
pilote RBD du noyau ; dans ce cas, il ne faut pas sur-rserver les espaces.

Enfin, le vrai problme est celui de l'appropriation de la technologie par l'quipe, eu gard l'importance stratgique du
projet. Une technologie open source aussi complexe ne peut tre matrise que par une seule personne. Une monte en
comptence de l'quipe et un suivi important sont requis. Le vrai passage l'chelle se situe ce niveau.

5.4

volution de la plate-forme

Les serveurs physiques utiliss (quips de 2 disques internes agrgs en RAID1) ne fournissent pas de performances
optimales pour CEPH. Ils grent de nombreux OSD virtualiss pour diffrents clusters. En phase d'criture, chacun d'eux
gre dans un premier temps le remplissage d'un journal local stock sur l'agrgat RAID1 du serveur physique, puis ensuite
le transfert sur le volume issu d'un agrgat RAID5 unique de la baie associe, qui sert aussi aux lectures.
Pour maximiser le paralllisme de la solution, chaque OSD devrait tre indpendant, mais dans ce schma, il n'en est rien,
tous sont hbergs sur une mme machine physique et partagent les mme priphriques. Ils se gnent mutuellement, en
particulier dans les phases d'criture sollicitant l'agrgat RAID1, aux performances mdiocres. Cela est particulirement
visible lorsqu'une reconstruction est en cours, les performances en tant fortement impactes.
Dbut 2013, trois machines dimensionnes pour CEPH (une par plaque gographique) ont t dployes. Elles sont
quipes de deux disques SSD pour stocker les journaux et disposent de 12 disques locaux SATA de 3 To configurs en 3
agrgats RAID5 ddis un OSD par cluster. Le rsultat est sans appel, avec un facteur 3 4 d'amlioration pour ces
serveurs qui ne reprsentent malheureusement qu'un tiers de notre parc.
5.4.1

Gestion des rplicats

Trois nouvelles machines du mme type vont renforcer notre ensemble en novembre 2013, avec comme objectif de
disposer d'autant OSD indpendants que de disques pour renforcer le paralllisme de la solution. Il sera fait l'impasse sur
l'organisation des donnes en RAID. Il s'agit d'une autre approche de la scurit, une tape psychologique est franchie et
19. Modification de cp pour fonctionner en mode multi-thread. Redoutable en tandem avec ceph !

JRES 2013 Montpellier

9/11

ncessite une confiance absolue dans CEPH : la scurit des donnes repose dsormais intgralement sur celui-ci.
Pour diminuer les risques, ces machines seront intgres dans un pool dont la rplication est place 3. En cas de panne
d'un disque, il n'y a plus de scurit lie au RAID, mais la donne est encore disponible deux endroits dans le cluster, ce
qui assure une bonne scurit. En cas d'une panne ou isolation complte d'une plaque gographique, toutes les donnes
sont encore disponibles en deux endroits, et ne sont donc pas en danger. Il n'y a pas reconstruction dans ce cas, ce qui
vite les pertes de performance et les ventuels effets domino , dplors par le pass. De surcrot, cette stratgie nous
protge mieux en cas de corruption due un systme de fichiers ventuellement dfaillant.
Enfin, un rapide calcul montre qu'en considrant 3 machines quipes de 12 disques de 4 To , soit 144 To bruts, la
solution de 3 copies offre 48 To utiles avec 36 OSD indpendants contre 54 To utiles pour 9 OSD indpendants, ce qui est
acceptable, mme si dans les deux cas, une trs grosse partie de l'espace reste gaspille.
5.4.2

Erasure coding

Le systme de rplication de donnes est donc bien plus onreux qu'un systme RAID traditionnel, mme si la scurit
offerte est incomparable. Dans un systme RAID5, la scurit des donnes est assure par une parit supplmentaire gre
bit bit, et seul l'quivalent d'un disque est consomm par ce processus. Ainsi, la diminution de l'espace global de
stockage est limite. Il est possible d'appliquer ce principe aux systmes de fichiers distribus, en modifiant le codage
de l'information, grce une technique dite d' erasure coding qui apporte une redondance l'information. Celle-ci
est distribue gographiquement par petits blocs. La redondance doit tre suffisante pour permettre le restitution de la
donne d'origine malgr la perte d'un ou plusieurs morceaux. Cette technique peut se rvler trs conome partir du
moment o une forte rpartition est possible. Le systme ROZOFS utilise dj ce principe grce une fonction de
transformation appele mojette[12], issue de travaux de recherches mens l'Universit de Nantes par J.P Guedon.
Dans notre cas prcis, l'exprience et les pannes subies nous ont montr qu'il ne fallait pas raisonner sur le nombre de
serveurs dploys, mais seulement sur nos sites, seuls lments tre compltement indpendants. En utilisant l'erasure
coding, la panne complte d'une plaque gographique doit laisser 100 % des donnes disponibles, signifiant que chaque
point gographique doit dtenir au moins 50 % des donnes. Ce qui donne au mieux un facteur 1.5 (au lieu du facteur 2
actuellement en cours). le gain est limit mais non ngligeable, la disponibilit de points gographiques indpendants
supplmentaires permettrait d'abaisser ce facteur, mais n'est actuellement pas possible.
L'incorporation d'une librairie d'erasure coding est en cours dans CEPH, elle a t initie par Loc Dachary et est
maintenant supporte officiellement par l'quipe de dveloppement et prvue pour la version 'F' : Firefly (Fvrier 2014)
5.4.3

Tiering

Cette mme version devrait aussi intgrer un mcanisme de tiering . Le principe est de dfinir plusieurs types de
pools selon des critres (rapidit, scurit, cot du matriel...). Le mcanisme de tiering permettra de calculer la
frquence d'utilisation des objets et de les dplacer de faon transparente entre pools en fonction de la politique choisie.
Ainsi, les objets auxquels on accde trs frquemment, tels que les index de bases de donnes, seront promus dans les
pools les plus rapides, potentiellement hbergs sur des machines disposant de SSD, alors que ceux moins utiliss
seront relgus dans les pools les moins rapides, y compris ventuellement sur des volumes potentiellement moins
scuriss mais plus conomiques.

5.5

Dveloppements futurs, stratgie

Le systme de clusters multiples fonctionnant bien, le rle actuel des clusters est affin et deux nouveaux clusters vont
tre dmarrs pour 2014.

C : production . Il accueillera les besoins des machines virtuelles et servira pour les interactions avec
openstack, le cluster A tant dsormais exclusivement dvolu aux sauvegardes. Le passage openstack est un
sujet part et fera l'objet d'un travail important dans les annes qui viennent, mais il est clair que CEPH est
complmentaire de cette technologie et est support officiellement.
D : tiers , permettra des stockages volumineux pour des projets spcifiques.

6 Conclusion
Nous pouvons dsormais affirmer que la plate-forme est fonctionnelle, robuste et rpond en trs grande partie nos
besoins. La vitalit du projet, sa communaut importante et dynamique, les fonctionnalits importantes, sont autant de
signes sur la russite de CEPH. En l'tat, ses fonctionnalits et sa performance nous permettent actuellement un
remplacement progressif d'une partie de notre stockage traditionnel sous certaines conditions. Les fonctionnalits en
JRES 2013 Montpellier

10/11

cours de dveloppement, en particulier le tiering, ne font qu'abonder vers cette solution, dont le spectre d'utilisation ne
cesse d'augmenter. Il est toutefois dpendant des investissements en machines ddies que nous serons capables
d'effectuer et surtout des moyens humains mettre en uvre pour prenniser cette solution.

Bibliographie
[1] Yann Dupont, Yoann Juet et Jean-philippe Menil. Plateforme d'hbergement de services tolrante la panne,
redonde gographiquement. Dans Actes du congrs JRES2011, Toulouse, Novembre 2011.
https://2011.jres.org/archives/116/paper116_article.pdf
[2] LUSTRE. http://www.lustre.org
[3] GLUSTERFS. http://www.gluster.org
[4] HEKAFS. http://hekafs.org/
[5] MOOSEFS. http://www.moosefs.org/
[6] ROZOFS. http://www.fizians.com
[7] OCFS2. http://oss.oracle.com/projects/ocfs2/
[8] GFS2. http://www.redhat.com/products/enterprise-linux-add-ons/resilient-storage/
[9] DRBD. http://www.drbd.org/
[10]CEPH. http://www.ceph.com/
[11]Sage Weil : Ceph: reliable, scalable, and high performance distributed storage, University of california, Santa cruz.
Dcembre 2007. http://ceph.com/papers/weil-thesis.pdf
[12]Jean-Pierre Guedon. The Mojette Transform: Theory and Applications. ISTE / WILEY. ISBN : 978-1848210806
[13]Sage A. Weil Scott A. Brandt Ethan L. Miller Carlos Maltzahn. CRUSH: Controlled, Scalable, Decentralized
Placement of Replicated Data. Storage Systems Research Center, University of California, Santa Cruz.
http://ceph.com/papers/weil-crush-sc06.pdf
[14]mcp. http://ti.arc.nasa.gov/opensource/projects/mcp

JRES 2013 Montpellier

11/11