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.
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
1.2
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.
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
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.
3/11
RADOS,
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
3.2
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.
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
3.4
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
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
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).
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
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.
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
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.
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.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.
8/11
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
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 !
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
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
11/11