Le Blog Utux

HTTP 200 GET /

Mauvaise expérience avec Ceph

Rédigé par uTux 14 commentaires

Ceph fait du stockage distribué. Il permet de répartir des données sur plusieurs machines avec réplicas, assurant ainsi une certaine sécurité et résilience.

Ceph logo

Sauf que ça c'est la théorie, en pratique mon expérience a été assez mauvaise et non seulement source d'interruptions de service mais aussi d'un niveau de stress très important (jusqu'à ne plus dormir la nuit). Parce que oui perdre un serveur de prod n'est déjà pas agréable, mais quand il s'agit du stockage c'est encore pire.

Commitstrip
Un admin qui bosse avec Ceph

Problème 1: l'usine à gaz

Ceph est gros, très gros, pour le compiler prévoyez au minimum 8GB de ram (sous peine de faire exploser votre machine) et plusieurs heures.

Ensuite pour être à l'aise prévoyez des machines bien dimensionnées (Xeon), beaucoup de RAM (1GB par TB) et du stockage SSD pour la journalisation. A l'usage ne vous étonnez pas de voir la RAM et la swap proche de la saturation, c'est le rythme de croisière.

Et puis l'architecture n'est pas simple il y a les OSD, les PGs, les différents services, et les logs parfois pas très clairs qui vous disent que la reconstruction est bloquée sans vraiment donner de raison.

Problème 2: les bugs

Sur la version Kraken (11.2) il existe une fuite de mémoire avec le service ceph-mgr. La solution est donc de le couper. Sauf que son rôle est justement de contrôler l'utilisation de la mémoire, donc le serveur va naturellement gonfler au fil des mois jusqu'à finir par exploser en vol. Il faut donc régulièrement lancer ceph-mgr puis le couper.

Le hic, c'est que dans le cas où votre serveur est déjà bien chargé (RAM + swap), le lancement de ceph-mgr ajoute un poids supplémentaire ce qui peut amener des lag sur le cluster le temps que la mémoire baisse... et ça c'est très mauvais. Dans mon cas cela a fait basculer plusieurs machines virtuelles en readonly.

Problème 3: ceph-deploy

Avec la mouvance devops il est de plus en plus courant de vouloir installer les choses sans devoir mettre les mains dans le cambouis, faire du sysadmin sans rien connaître en sysadmin quoi. Et c'est problématique. Certes c'est rapide et facile, mais en cas de panne on ne sait pas quoi faire car on ne sait pas comment marche le système.

Ceph-deploy fait le boulot à votre place, et dans le cas où ce n'est pas vous qui avez monté l'infra, si vous ne disposez pas du répertoire contenant les clés et la configuration, bon courage pour manipuler le cluster (ajout ou retrait de nodes). De plus ceph-deploy réserve des surprises en installant pas forcément la version qu'on lui demande...

Problème 4: les performances

Même avec un setup assez costaud (plein de RAM et de SSD) les I/O des VM qui sont stockées dessus sont décevantes. C'est un ressenti, mais à l'aire du SSD et/ou du stockage en RAID10, une installation d'une VM debian stockée sur cluster Ceph parait interminable.

Problème 5: résilience

Dans un cluster de 3 nodes on se dit qu'on est tranquilles car on peut en perdre 2 et continuer à fonctionner, un peu comme avec un RAID1 de 3 disques. Sauf qu'en pratique, il faut au minimum 2 nodes actives... Et oui, j'ai testé sur un cluster Ceph 0.96 et 11.2, dans les deux cas les données ne sont plus accessibles s'il ne reste qu'une seule node en vie.

Problème 6: targetcli

C'est le daemon iscsi de Ceph. Le problème ? Il perd sa conf partiellement ou totalement à chaque reboot. Prévoyez un targetctl restore systématique et un downtime possible si vous devez effectuer cette opération.

Conclusion: abandon

Alors que Ceph est censé apporter une continuité de service et donc un sérénité pour les admin, j'ai expérimenté le contraire. Les nombreux downtimes et les fois où j'ai été à deux doigts de perdre l'intégralité du stockage (et donc des machines virtuelles) m'ont causé des nuits blanches d'angoisse.

Les VM sont en cours de migration vers un SAN artisanal à base de Debian + iscsitarget. Il n'est peut-être redondé mais il est fiable, il n'y a pas de fuite de RAM, et s'il y a le moindre pépin nous connaissons les couches de A à Z pour pouvoir diagnostiquer.

En ce qui me concerne Ceph est une usine à gaz qui n'est pas production ready et j'espère ne plus avoir à y toucher de ma vie.

14 commentaires

#1  - cozi a dit :

Arfff je comprend ce que tu dis. Sauf que je pense que tu as du loupé des étapes. Dans ma boîte ça fait 3ans qu’on a du ceph block et objet. On a aussi fait des maj successives.
Des choses que je ne comprends pas c’est pourquoi le compiler à la main ?

Voici ce que nous avons fait et pourquoi. Déjà qd on parle de stockage on parle de réseau donc 10G minimum. C’est ultra important. Car lors de certaines maj, perte d’un serveur il y a rebalancement des données. Donc si ton lien de réplication n’est pas assez important ton cluster passe en erreur et tes vm en read only.
Ensuite nous faisons les maj et autre opération via ceph deploy tout est nickel. Bien sûr pour savoir ce qu’il fait il faut regarder la doc c’est important pour debug. Si tu n’as pas les clés tu peux les récupérer facilement. Ensuite oui si tu as que 3 serveurs et que tu en perds 2 le cluster s’arrete car il ne peut pas avoir une autre copie des data. Donc au risque de tout perdre il arrête les lectures écritures. Ensuite très important c’est le calcul des pg. Niveau perf sur les vm nous sommes à 480Mo/s ce qui est pas mal. Ce n’est jamais testé la partie iscsi. Je te conseil d’oublier un peu ce stockage et d’y revenir plus tard. C’est une formidable techno. Si tu as besoin de conseil tu as mon mail :)

Répondre
#2  - uTux a dit :

Merci pour ce retour d'expérience assez complet.
Si on ne peut pas tourner avec un seul serveur, ça veut dire qu'il en faut 4 voire 5 pour être tranquille ?

Répondre
#3  - cozi a dit :

Non tu peux en avoir que 3. Mais je supposes que t’es monitor sont sur les même serveurs que tes osd ? Je ne sais plus si tu peux tourner sur 1 monitor à tester ... mais dans ta conf ceph tu peux lui indiquer une valeur de min size pour les replica. Donc tu peux mettre 1. Après il est conseillé d’avoir l’es serveurs monitor à part. Concernant les osd sur des technos de sds plus tu as de serveurs plus tu as perf.

Répondre
#4  - uTux a dit :

Thx.

Répondre
#5  - cvubrugier a dit :

Je ne connais pas Ceph mais j'ai souvent utilisé targetcli. Il faut effectivement restaurer la configuration iSCSI à chaque reboot mais cette opération est normalement réalisée par un script d'init.
La target iSCSI iscsitarget n'est plus maintenue depuis plusieurs années et je vous suggère d'utiliser LIO / targetcli ou tgt à la place.

Répondre
#6  - uTux a dit :

Ah en effet il semble que ce ne soit plus dispo. Le serveur tourne sous Wheezy, à l'époque ça devait toujours exister :)
Concernant la perte de conf de targetcli je pense avec du recul que cela peut venir d'un problème d'ordre de boot. Par exemple si Ceph n'a pas fini de démarrer, le périphérique block (rbd) n'est pas dispo et donc targetcli ne charge pas complètement sa conf.

Répondre
#7  - DevOoops a dit :

Merci pour ton retour mais sans être un spécialiste de ceph, je pense que tes mésaventures découlent d'un manque de maîtrise de cette techno.

Certes Ceph n'est pas parfait mais il est très largement utilisé dans les infrastructures de type cloud ce qui prouve qu'il est malgré ses défauts "production Ready".

Concernant l'histoire de la résilience. Il me semble tout à fait normal qu'un cluster composé de 3 machines ne fonctionne plus après la perte de 2 machines, cela est lié au fonctionnement des algorithmes gérant l'élection de maître et cela permet d'éviter les phénomènes de type "Split brain".

Quant à la remarque au sujet de la culture devops, j'espère qu'il s'agit que d'un sarcasme.

Merci

Répondre
#8  - uTux a dit :

Ben justement à part le Cern je suis curieux de savoir qui utilise Ceph. Je ne doute pas de son utilité en datacenter mais dans le monde pro on trouve plutôt des baies SAN ou appliances propriétaires similaires. Si j'étais mauvaise langue je dirais que le problème de Ceph est justement "il faut plus". Tu as beau provisionner le truc le plus gros que tu peux, l'explication de l'échec est toujours un manque de bande passante, de ram, de stockage... à un moment j'ai quand même envie de dire qu'on construit une centrale nucléaire dont la complexité dépasse l'usage (si j'installe un Ceph pour une ferme de virtualisation, ça va me prendre plus de temps que de gérer les VMs elle-mêmes).

Pour la remarque sur la débilisation/infantilisation des technos/logiciels ce n'est pas une blague, c'est un troll, je ferai un article là dessus à l'occasion. Je n'ai pas de problème avec le fait de rendre les choses simples ou d'automatiser des déploiements (c'est le cœur de métier du devops) en revanche je ne suis pas d'accord avec cette idée que n'importe qui peut déployer n'importe quoi sans être sysadmin. Déployer Wordpress avec Docker en 2 commandes c'est bien, le problème est qu'on n'a même plus besoin de savoir qu'il y a un apache/php/mysql dessous et qu'en cas de pépin il faut savoir les utiliser.

Répondre
#9  - f4b1 a dit :

Merci pour le retour d'expérience, je suis pas sur d'essayer chez nous du coup, on va rester sur des choses fiables et stables même si c'est parfois galère à gérer ...

Répondre
#10  - cozi a dit :

Pourquoi suivre uniquement un mauvais retour d’expérience alors que d'autres personnes comme moi, l’expérience est plutôt bonne ?
Il faut juste savoir quand l'utiliser, pourquoi et suivre les best practices...

Répondre
#11  - Etienne a dit :

Hello,
Je préviens, je suis un utilisateur ravi de Ceph ;)

1 :
Oui c'est gourmand, mais ce n'est pas une usine à gaz.
Peu de process, chaque rôle est clair.
Savoir pour quelle raison quelque chose est bloqué est au contraire très clair via les pg query/dump des opérations in flight.

On peut avoir cette impression d'usine à gaz quand on découvre la techno.
Mais on retrouve énormément de similitudes à Openstack Swift, une autre techno de stockage objet. Çe ne doit pas être un hasard.

2 :
Je conseille plutôt les versions lts, on utilise que ces versions en prod.
On a rarement eu des bugs, le plus souvent liés à notre utilisation à grande échelle.

3:
Rien n'oblige à l'utiliser.
C'est je pense, surtout pratique à petite échelle.

4:
C'est à mon avis l'un des plus gros défauts actuel, à chaque nouvelle version on a une réelle amélioration des perfs.
C'est donc qu'il y a une grande marge de progression.

5:
On peut autoriser a n'avoir qu'un nœud actif. Mais je déconseille
Sur la pool : min_size 1

6:
Jamais utilisé, pas d'avis ;)

Ceph demande un investissement (matériel/montée en compétences) mais si le besoin colle à la techno, alors je pense que ça vaut réellement le coup ;)

Répondre
#12  - n0n0 a dit :

Salut,

Faut venir aux Ceph Meetups de l'Ouest :
https://fr.groups.yahoo.com/neo/groups/ceph-breizh/info

Répondre
#13  - raspbeguy a dit :

Je partage tes réserves concernant Ceph. Mais j'ai envie de dire : chacun son métier. Pour moi un cluster Ceph doit être géré par une équipe dédiée au stockage... Ça rend le truc a priori très difficile pour des petites boîtes avec uniquement 2 ou 3 sysadmin... Si je devais tout gérer moi même je partirais sur du LVM partagé sur base iSCSI, mais j'ai un collègue qui aime beaucoup Ceph et qui s'occupe de faire en sorte que ça fonctionne. Moi j'arrive très bien à broder dessus avec libvirt par exemple. Mais faut pas me demander de comprendre la grappe de stockage...

Répondre
#14  - Zorgawa a dit :

J'administre un CEPH depuis plusieurs années, et je confirme comme certains l'on écris précédemment dans les commentaires, CEPH c'est pas un truc a mettre en place a la légère et sans moyens financiers...

C'est une solution de stockage robuste et très puissante et pour les gros volumes (moi j'ai plusieurs péta octets dans mon CEPH ça représente des centaines de disques). C'est clairement pas une solution pour une petite entreprise qu'il n'a pas le budget pour cela... Mais bon il est aussi possible de faire du CEPH petit ;)

Ca demande aussi de bien comprendre le fonctionnement de la machinerie et cela avant de le mettre en production, c'est hyper bien documenté sur le site officiel de CEPH, et également il faut noter que la communauté des utilisateurs est relativement dynamique.

Voila ma recette idéale pour un configuration minimum :
3 (5 c'est mieux et plus c'est top) nœuds dédiés aux OSD (disques),
1 nœuds pour le monitor

Il y a aussi trois règles que j'impose dans mon CEPH pour avoir de bonnes performances :

1) RAM
Toujours avoir un ratio de 1GB de RAM pour chaque 1TB de disque !
Donc si vous avez 10 disques de 10To il faudra 100Go de RAM !!!
Dans mon cas mes nœuds ont 24 disques de 14To donc j'ai chargé en RAM mes serveurs a 256Go de RAM, J'ai aussi des nœuds qui ont 45 disques de 10To avec 512Go de RAM

2) CPU
Et aussi l'autre ratio qui tue, CPU vs OSD.
Moi je pèche légèrement la dessus, c’était pas homogène au début (16 a 56coeurs), mais maintenant c'est 48 cœurs par nœuds (ceux qui ont 24 disques de 14To et 256Go de RAM).

3) RESEAU
Moi je distingue plus interfaces a mon CEPH l'interne a CEPH et l'externe.
J'utilise des interfaces 10 Gb/s, mes derniers nœuds ont des interfaces 25Gb/s, mais comme la dorsale du réseau CEPH est encore en 10 Gb/s ça ne sert pas encore.

Pour finir, au niveau des performances moi sur mon gros CEPH j'ai des vitesses de transferts qui dépassent les 250Mo/s et je n'ai pas de SSD dans les OSD ;)

Répondre

Écrire un commentaire

Quelle est le deuxième caractère du mot hz3pw6n ?