Ceph est un logiciel libre de stockage distribué, comme GlusterFS par exemple. Il permet de créer un espace de stockage unifié entre plusieurs serveurs qui utilisera les ressources de stockage de chacun de ceux‐ci. L’objectif du projet est de rendre l’espace de stockage sans aucun point de défaillance unique. Typiquement, l’espace de stockage doit survivre à la perte d’un serveur. Ceph est distribué sous licence LGPL v2.1.
Cette dépêche est un retour d’expérience sur son installation sous Debian.
Sommaire
- Introduction
- Prérequis
- Installation
- Les moniteurs (monitor)
- Le stockage (OSD)
- Comment utiliser ma grappe de serveurs ?
Introduction
Actuellement, j’utilise GlusterFS et je souhaite évaluer Ceph pour mes prochains déploiements.
J’ai testé l’outil officiel de déploiement automatique de Ceph, nommé ceph-deploy
. L’outil a pour objectif de simplifier au maximum l’installation et la maintenance d’une grappe de serveurs Ceph (cluster), toutefois il n’a pas fonctionné sur mes serveurs alors que j’avais bien suivi tous les prérequis. De mon point de vue, l’utilisation de cet outil ne permet pas de comprendre comment Ceph fonctionne, et laisse donc l’utilisateur bien seul en cas de problème. Des problèmes de sécurité sont aussi à prévoir, car son fonctionnement nécessite un accès SSH vers tous les serveurs de la grappe, avec un compte possédant un droit d’exécution de toutes les commandes avec sudo
sans mot de passe. Bref, vos clefs SSH ont intérêt à être très bien protégées.
La documentation est rédigée avec des notes pour CentOS et RHEL, mais très peu pour Debian. Les différences sont principalement dans la gestion des services par le système d’initialisation (upstart, systemd, SysV…).
Afin de faciliter la découverte de Ceph à d’autres personnes sous Debian, j’ai décidé de partager mes notes techniques en seconde partie. Ces notes permettent de mettre en place RADOS. RADOS est composé de deux parties : les moniteurs (monitor) qui synchronisent les serveurs, et les unités de stockage (OSD). C’est le déploiement minimum pour faire fonctionner Ceph.
Prérequis
- 3 serveurs sous Debian Jessie, avec accès administrateur ;
-
ssh-server
et une authentification par clef publiques pour ne pas perdre son temps ; - NTP, la communication des moniteurs entre eux nécessite une faible dérive du temps entre les serveurs ;
-
hostname et
/etc/hosts
; Ceph utilise les noms d’hôtes courtshostname -s
, il est donc important que ces noms soient résolvables par un serveur DNS et/ou présents dans votre fichier/etc/hosts
.
Installation
La version de Ceph utilisée est Jewel (10.2 LTS). Cette version de Ceph est sortie en avril 2016 et n’est donc pas dans les dépôts de Debian. Toutefois, Ceph propose des dépôts afin de faciliter l’installation.
$ wget -q -O- 'https://download.ceph.com/keys/release.asc' | apt-key add -
$ echo deb http://download.ceph.com/debian-jewel/ $(lsb_release -sc) main > /etc/apt/sources.list.d/ceph.list
$ apt-get update
L’installation du paquet ceph permet de récupérer tous les outils. En revanche, aucune configuration ne sera créée et aucun service ne sera démarré. Sur chaque serveur :
$ apt-get install ceph
Les moniteurs (monitor)
C’est la première étape obligatoire lors du déploiement d’une grappe de serveurs Ceph. Ils permettent de garder les serveurs synchronisés entre eux. Les moniteurs forment un quorum pour être sûr de ne pas être isolés, il est donc obligatoire d’en avoir un nombre impair.
Configuration initiale
Pour initialiser nos serveurs, nous avons besoin de trois fichiers présents sur chacun des serveur :
-
/etc/ceph/ceph.conf
; -
/etc/ceph/ceph.client.admin.keyring
; -
/tmp/ceph.mon.keyring
.
/etc/ceph/ceph.conf
[global]
fsid = 70036746-1cee-11e6-922f-0cc47ab35ede
public network = 10.10.0.0/24
cluster network = 10.10.0.0/24
auth_cluster_required = cephx
auth_service_required = cephx
auth_client_required = cephx
mon_initial_members = srva, srvb, srvc
osd journal size = 1024
filestore xattr use omap = true
osd pool default size = 2
osd pool default min size = 1
osd pool default pg num = 333
osd pool default pgp num = 333
osd crush chooseleaf type = 1
[mon.srva]
host = srva
mon_addr = 10.10.0.1:6789
[mon.srvb]
host = srvb
mon_addr = 10.10.0.2:6789
[mon.srvc]
host = srvc
mon_addr = 10.10.0.3:6789
/etc/ceph/ceph.client.admin.keyring
On va créer une clef administrateur qui permettra de communiquer avec les moniteurs pour exécuter des commandes avec l’outil en ligne de commande ceph
:
$ ceph-authtool --create-keyring /etc/ceph/ceph.client.admin.keyring --gen-key -n client.admin --set-uid=0 --cap mon 'allow *' --cap osd 'allow *' --cap mds 'allow'
$ cat /etc/ceph/ceph.client.admin.keyring
[client.admin]
key = ZWA/D6dqLS0ev2LbhEpQ5MDXih3DiUv0/k5WgQ==
auid = 0
caps mds = "allow"
caps mon = "allow *"
caps osd = "allow *"
/tmp/ceph.mon.keyring
On va créer une clef commune à tous les moniteurs de notre grappe de serveurs pour qu’ils puissent communiquer entre eux. Puis on ajoute notre clef administrateur dans le trousseau de clefs, afin de pouvoir communiquer avec un moniteur.
$ ceph-authtool --create-keyring /tmp/ceph.mon.keyring --gen-key -n mon. --cap mon 'allow *'
$ ceph-authtool /tmp/ceph.mon.keyring --import-keyring /etc/ceph/ceph.client.admin.keyring
$ cat /tmp/ceph.mon.keyring
[mon.]
key = P0qAdtmkdvpCmwONXxRQNmXQrT2+wDymZMh8gQ==
caps mon = "allow *"
[client.admin]
key = ZWA/D6dqLS0ev2LbhEpQ5MDXih3DiUv0/k5WgQ==
auid = 0
caps mds = "allow"
caps mon = "allow *"
caps osd = "allow *"
Préparation des moniteurs
Cette étape consiste à créer un environnement neuf pour les moniteurs de notre grappe de serveurs Ceph. Cette opération doit être faite sur chacun des serveurs.
$ ceph-mon --mkfs -i $(hostname -s) --keyring /tmp/ceph.mon.keyring
$ touch /var/lib/ceph/mon/ceph-$(hostname -s)/done
$ chown -R ceph:ceph /var/lib/ceph
$ rm /tmp/ceph.mon.keyring
Démarrage des moniteurs
Le paquet Ceph fournit une cible systemd (target) qui permet de démarrer tous les services d’un coup. Cela permettra de redémarrer tous les services au prochain démarrage.
$ systemctl enable ceph.target
$ systemctl start ceph.target
On démarre le moniteur, l’opération doit être répétée sur chaque serveur.
$ systemctl enable ceph-mon@$(hostname -s)
$ systemctl start ceph-mon@$(hostname -s)
$ systemctl status ceph-mon@$(hostname -s).service
● ceph-mon@srva.service - Ceph cluster monitor daemon
Loaded: loaded (/lib/systemd/system/ceph-mon@.service; enabled)
Active: active (running) since Fri 2016-05-20 23:08:05 CEST; 7min ago
Main PID: 2836 (ceph-mon)
CGroup: /system.slice/system-ceph\x2dmon.slice/ceph-mon@srva.service
└─2836 /usr/bin/ceph-mon -f --cluster ceph --id srva --setuser ceph --setgroup ceph
Obtenir le statut de la grappe de serveurs Ceph
Il est possible d‘obtenir le statut de la grappe de serveurs Ceph, depuis n’importe quel des trois serveurs, et en tant que simple utilisateur.
$ ceph -s
cluster 70036746-1cee-11e6-922f-0cc47ab35ede
health HEALTH_ERR
no osds
monmap e1: 3 mons at {srva=10.10.0.1:6789/0,srvb=10.10.0.2:6789/0,srvc=10.10.0.3:6789/0}
election epoch 6, quorum 0,1,2 srv03a,srv03b,srv03c
osdmap e1: 0 osds: 0 up, 0 in
flags sortbitwise
pgmap v2: 64 pgs, 1 pools, 0 bytes data, 0 objects
0 kB used, 0 kB / 0 kB avail
64 creating
On peut voir que notre grappe de serveurs est en mode « HEALTH_ERR ». C’est normal, car il ne possède encore aucune unité de stockage (OSD). Les unités de stockage peuvent être rajoutées seulement une fois que les moniteurs fonctionnent correctement.
La commande suivante permet d’obtenir le statut des moniteurs dans un format JSON :
$ ceph mon_status
{
"name": "srvc",
"rank": 2,
"state": "peon",
"election_epoch": 6,
"quorum": [
0,
1,
2
],
"outside_quorum": [],
"extra_probe_peers": [],
"sync_provider": [],
"monmap": {
"epoch": 1,
"fsid": "70036746-1cee-11e6-922f-0cc47ab35ede",
"modified": "2016-05-20 23:08:04.854999",
"created": "2016-05-20 23:08:04.854999",
"mons": [
{
"rank": 0,
"name": "srva",
"addr": "10.10.0.1:6789/0"
},
{
"rank": 1,
"name": "srvb",
"addr": "10.10.0.2:6789/0"
},
{
"rank": 2,
"name": "srvc",
"addr": "10.10.0.3:6789/0"
}
]
}
}
La prochaine étape est de rajouter de l’espace de stockage à notre grappe de serveurs.
Le stockage (OSD)
La partie suivante explique comment ajouter une unité de stockage Ceph (OSD) à la grappe de serveurs. Elle doit donc être répétée autant de fois qu’il y a de serveurs à ajouter. Il est possible de faire fonctionner plusieurs osd
sur le même serveur afin d’ajouter plusieurs disques durs.
Préparation du stockage
On génère un uuid
pour identifier notre nouvelle instance d’un OSD. Puis, on demande à Ceph de nous attribuer un index pour cet OSD. Dans notre cas, l’index est 0
, car c’est le premier OSD que l’on crée.
$ uuid
e367d468-1e80-11e6-9681-0cc47ab35ede
$ ceph osd create e367d468-1e80-11e6-9681-0cc47ab35ede
0
On crée le dossier qui servira de point de montage à notre partition, qui contient le numéro d’index de l’OSD :
$ mkdir /var/lib/ceph/osd/ceph-0
On monte notre partition, pensez à ajouter une ligne dans votre ficher fstab
afin de le remonter automatiquement au prochain démarrage du serveur :
$ mount /dev/sda2 /var/lib/ceph/osd/ceph-0
On génère une clef dédiée à cet OSD.
$ ceph auth add osd.0 osd 'allow *' mon 'allow profile osd' -i /var/lib/ceph/osd/ceph-0/keyring
added key for osd.0
On ajoute notre serveur, puis notre OSD dans la crush map
. Cela permet de décrire l’emplacement des données (datacenter, salle, couloir, baie, serveur), afin d’optimiser la réplication des données :
$ ceph --cluster ceph osd crush add-bucket srva host
added bucket srva type host to crush map
$ ceph osd crush move srva root=default
moved item id -1 name 'srva' to location {root=default} in crush map
$ ceph --cluster ceph osd crush add osd.0 1.0 host=srva
add item id 0 name 'osd.0' weight 1 at location {host=srva} to crush map
On s’assure que tous les fichiers que l’on vient de créer appartiennent bien à Ceph :
$ chown -R ceph:ceph /var/lib/ceph
Démarrage du stockage
$ systemctl enable ceph-osd@0.service
$ systemctl start ceph-osd@0.service
$ systemctl status ceph-osd@0.service
On peut à nouveau utiliser la commande ceph pour nous afficher le statut de notre grappe de serveurs. La ligne contenant osdmap
contient le nombre d’osd
et leur statut :
$ ceph -s
cluster 70036746-1cee-11e6-922f-0cc47ab35ede
health HEALTH_OK
monmap e1: 3 mons at {srv03a=10.10.0.1:6789/0,srv03b=10.10.0.2:6789/0,srv03c=10.10.0.3:6789/0}
election epoch 6, quorum 0,1,2 srva,srvb,srvc
osdmap e22: 3 osds: 3 up, 3 in
flags sortbitwise
pgmap v51: 64 pgs, 1 pools, 0 bytes data, 0 objects
3172 MB used, 568 GB / 571 GB avail
64 active+clean
Comment utiliser ma grappe de serveurs ?
Il y a quatre possibilités et elle sont expliquées dans la documentation d’architecture de Ceph. Le schéma d’introduction en est un extrait. Chaque solution possède des avantages et des inconvénients, le choix dépendra de vos besoins.
Pour ma part, je vais sûrement mettre en place CEPH FS
. Je vous ferai un autre retour d’expérience à cette occasion.
Merci, aux relecteurs.
Aller plus loin
- Site officiel de Ceph (271 clics)
- Liste des versions de Ceph (58 clics)
- Guide de déploiement manuel (92 clics)
- Un glossaire sur Ceph (43 clics)
- Architecture de Ceph (115 clics)
- Code source (65 clics)
# Pertinence de Ceph ou Gluster
Posté par Victor . Évalué à 6.
Dernièrement, j'ai vu plusieurs grosses structures utilisant Ceph ou Gluster décider d'abandonner ces technos.
Je ne suis pas du tout expert, mais je me demande quel est l'avis des experts justement sur cette situation.
Il y a gitlab qui explique ça dans un billet plus général, avec plein de retours de pleins de gens qui alertent sur Ceph: https://about.gitlab.com/2017/03/02/why-we-are-not-leaving-the-cloud/
Puis il y a ma boite qui abandonne Gluster (et qui bouge sur autre chose, je sais pas quoi, peut-être que c'est une techno similaire en fait, pas du Ceph en tout cas :). Ce n'est pas une aussi grosse structure que gitlab je pense.
[^] # Re: Pertinence de Ceph ou Gluster
Posté par haleth . Évalué à 3.
On peut se poser la question de la pertinence d'utiliser cephfs, considérant l'avancé du développement de ce projet
Attention également à ceux qui voit ceph comme un gros raid1 : ce n'est pas du raid, ce n'est pas du NFS, il faut le voir différemment, et le traiter différemment (ne pas comparer orange et bananes). On voit beaucoup de gens faire un cluster avec une poignée de disques de 8TB, puis mettre une bonne couche de VM qui gratte dessus, et ensuite s'étonner que Ceph ne corrige pas miraculeusement les problèmes d'IO (je pense à un certain hébergeur francais par exemple .. :) )
Si tu as les informations sur ce que ta boite va utiliser, partage s'il te plait, ça m'intéresse :)
Je trouve dommage de voir gitlab quitter Ceph pour NFS … NFS quoi ……..
[^] # Re: Pertinence de Ceph ou Gluster
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
Ils auraient au moins pu mettre du CodaFS, histoire de pouvoir répartir un peu la charge.
[^] # Re: Pertinence de Ceph ou Gluster
Posté par el_profesor . Évalué à 4.
Pour répondre à ta question Victor, on n'utilise pas, en général ceph, uniquement pour faire du cephfs. Tout simplement car cette feature est considéré comme stable depuis la version Jewel. De plus pour cephfs il faut un serveur metadata. Si on en installe plusieurs il y en a qu'un seul d'actif. Pour du cephfs il faut obligatoirement des serveurs OSD avec des SSD. Cephfs remplace un serveur NFS. Tu peux créer une arborescence par client si tu le souhaite. (attention à la génération des clés)
J'ai géré un cluster ceph de plus de 100To, et on utilise ceph en mode bloc le plus souvent. C'est à dire en mode "je stocke des VMs" dessus (via librbd). Ca remplace une baie de stockage. Pour faire des serveurs OSD pour du mode bloc il faut :
Pour du bloc tout passe d'abord par le journal. Donc il faut avoir des SSD performant. Et surtout un réseau 10G !
Ensuite après tu peux avoir d'autres serveurs avec que des gros DD pour faire du mode objet.
[^] # Re: Pertinence de Ceph ou Gluster
Posté par michael (mickey) (site web personnel) . Évalué à 4.
Quelque soit la techno faire du stockage c'est un métier. Il faudra mettre en place des procédures d'approvisionnements, de changement de disque, de backup, tester les backup …
Pour Ceph ça commence aussi par choisir le bon matériel avant de se plaindre des mauvaises perfs : SSD de grade entreprise pour les journaux, réseaux 10GB pour l'accès aux data, 10GB pour la réplication entre les OSD, 1 core par OSD …
Utiliser Ceph seulement pour CephFS est à mon avis une erreur. Ceph c'est d'abord un mode bloc et sa passerelle compatible S3 (y'a eu de gros efforts de compatibilité sur la dernière version)
Si les "pleins" de retours sont fait par "pleins" de gens qui se disent qu'il y a qu'à installer les binaires pour faire comme chez Amazon ça doit effectivement donner pleins d'alertes.
[^] # Re: Pertinence de Ceph ou Gluster
Posté par Francois G. . Évalué à 0.
Pour ceux que ça intéresse, un papier est sorti en fin d'année dernière sur OpenStack dans la recherche, il traite aussi de Ceph.
https://www.openstack.org/assets/science/OpenStack-CloudandHPC6x9Booklet-v4-online.pdf
[^] # Re: Pertinence de Ceph ou Gluster
Posté par matli . Évalué à 1.
+10
Je travaille dans une équipe spécialisée en stockage, nous avons monté du Ceph en faisant attention à tous les points que tu mentionnes très justement ici. Et juste ça marche, et bien en plus! Oui, le stockage c'est un métier, et encore plus avec du SDS par rapport à une simple baie milieu de gamme.
Pour le déploiement, on utilise le runbook ansible fournit par Redhat, mais il est dispo sur le github. Ceph-deploy ça marche aussi, mais pas aussi bien.
[^] # Re: Pertinence de Ceph ou Gluster
Posté par Mimosa . Évalué à 2.
Entièrement d'accord.
Le CERN utilise massivement Ceph (RBD + objet). Cluster de prod avec +3Po (pour Openstack) : https://indico.cern.ch/event/542464/contributions/2202295/attachments/1289543/1921810/cephday-dan.pdf
Un test a été effectué avec 30Po pour de la data, toujours au CERN : https://cds.cern.ch/record/2015206/files/CephScaleTestMarch2015.pdf
ça fonctionne. Comme tu le dis, encore faut-il les compétences et le matériel.
[^] # Re: Pertinence de Ceph ou Gluster
Posté par Thomas Mangin (site web personnel) . Évalué à 2.
Proxmox propose un support CEPH en natif - j'en suis très content: deux clusters CEPH en prod depuis quelques années, avec trois machines de 8 OSD chacune - un OSD par disque, et de trois a cinq machines pour faire tourner les VM.
Les IOP ne sont pas encore du niveau d'autres produits, car QEMU ne supporte pas encore très bien le multi-threading pour les operations d'IO. C'est maintenant une thread IO par disque virtuel, ce qui est mieux qu'une par VM, mais pas encore suffisant pour les charges lourdes. Il faut donc pouvoir monter plus d'un disque et repartir la charge - ce qui n'est pas un problème pour nous mais a été une grosse surprise.
J'ai eu le droit a de multiples (5+) coupures de courants dans nos anciens bureaux, et d'autres problèmes avec le switch 10Gb. Avec les bon réglage pour le cache write, et de bons SSD pour le journal, multi-chassis LAG pour avoir 20Gb dédié entres les machines: aucun problèmes. Il faut cependant accepter que les IOP soient bien moins bonne durant la phase de recuperation.
CQFD: C'est très bien pour le stockage a long terme de données et faire tourner des VM pas trop gourmandes. C'est cependant une solution a seulement utiliser une fois que l'on a bien compris ses avantages et inconvénients.
[^] # Re: Pertinence de Ceph ou Gluster
Posté par wysman . Évalué à 1.
Merci de vos retours,
Je vais mettre au propre mes notes pour la partie MDS et montage du FS. Pour écrire la suite !
# la taille compte
Posté par Joris Dedieu (site web personnel) . Évalué à 4.
Je vais rejoindre un peu ce qui s'est dit plus haut et sans doute généraliser de façon excessive, mais il le semble qu'une erreur commune concernant les technologies distribuées telle que ceph est de croire qu'on peut monter de petites infrastructures.
Indépendamment des techno sous jacente, il s'agit ici d'assurer la disponibilité et la permanence d'une ressource au delà des pannes matérielles. Or le premier élément qui va limiter l'impact d'une panne, c'est la possibilité de la noyer au sein de l'infrastructure.
Si tu as 3 serveurs, la panne d'un seul représente un tiers des données. C'est énorme et potentiellement désastreux. Plus le nombre de serveurs va augmenter moins la panne deviendra significative. À un certain niveau, elle sera quasiment dissoute dans la normalité des incidents d'une infra aux dimensions industrielle : un non évènement.
Reste la question de la panne globale. Car finalement, il est pertinent de penser que plus une infra est imposante, plus un désastre majeur devient probable. La encore la réponse est dans une maîtrise de la solution jusqu'au bon niveau. Choix des disques, des composants réseau, maîtrise du soft et de ses mises à jour, procedures d'intervention, qa …
La haute disponibilité au niveau des infrastructures nécessite des moyens importants et une taille critique. Il est rare qu'il n'existe pas un biais pour s'en passer…
# DeepSea
Posté par Anonyme . Évalué à 2.
Voici un outil que j'ai découvert lors d'une présentation au fosdem pour réaliser le déploiement d'un cluster Ceph via Salt.
https://github.com/SUSE/DeepSea
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.