Le Blog Utux

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

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 ?

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.

Thx.

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.

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.

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

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.

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

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

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

Salut,

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

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

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