Avant de zoulouter sur ceph merci de consulter la doc, sinon vous pourrez avoir des surprises (du genre plus d'accès aux données)

Il y aussi la documentation de Gentoo qui explique bien les concepts

À MiNET, depuis 2018, on utilise un cluster Ceph pour le stockage pour un tas de raisons. Ceph est une technologie de stockage développée par Red Hat (et d'autres acteurs comme Cisco & Canonical), qui permet de créer une grappe de serveur se comportant comme un SAN.

Nous n'avons actuellement pas de serveurs de backup morte. Pour l'instant nous réalisons des snapshots des disques des machines via Ceph directement (avec l'outil rbd). Les backups sont lancées depuis Phobos et sa crontab qui lance le script de sauvegarde.

La politique que nous avons choisie est la suivante : une sauvegarde tous les :

• 6 heures, à 5h,11h,17h et 23h, on en conserve 24, on couvre donc 6 jours (ce qui permet de couvrir les WE y compris prolongés)
• jours, à 3h, on en conserve 21, on couvre donc 21 jours (ce qui permet de couvrir les vacances de 2 semaines)
• semaines, à 2h le samedi, on en conserve 13, on couvre donc 3 mois (ce qui permet de couvrir les vacances d'été)
• mois, à 1h le 1er du mois, on en conserve 12, on couvre donc 1 an (ce qui permet d'avoir un historique ou si besoin pour des raisons légales)

Elles sont monitorées via Zabbix et quelques scripts.

D'après Wikipédia:

Ceph est une plateforme libre de stockage distribué. Les objectifs principaux de Ceph sont d'être complètement distribué sans point unique de défaillance, extensible jusqu'à l'exaoctet et librement disponible. Les données sont répliquées, permettant au système d'être tolérant aux pannes.

Ceph fonctionne sur du matériel non spécialisé. Le système est conçu pour s'autoréparer et automatiser au maximum ses tâches administratives afin de réduire les coûts d'exploitation.

Dans cet article, nous résumerons et vulgariserons Ceph, mais gardez à l'esprit que si vous avez une manipulation à faire, allez toujours consulter la documentation Ceph en ligne ou man ceph.

Un OSD (Object Storage Daemon) est un daemon tournant sur les machines de stockage, qui est lié à un disque dur (mais il pourrait être lié à une partition ou même un fichier) et qui stocke à proprement parler les données contenues dans le stockage.

Les mon (Monitors) sont des daemon qui gèrent ensemble l'état et les membres du cluster. Ce sont les premiers éléments que l'on contacte pour avoir les informations nécessaires pour localiser où sont stockées les données sur les OSDs

RADOS (Reliable Autonomic Distributed Object Store) est le moteur de stockage utilisé derrière Ceph.

RBD (RADOS Block Device) est une bibliothèque permettant d'accéder en mode block (donc voir des disques et non pas des fichiers) aux données sur le cluster.

Nous avons donc plein d'OSD (un par disque) qui sont dans un gros cluster Ceph. Nous avons un mon par machine de stockage qui permettent ensemble de gérer le cluster et d'y accéder.

Chaque objet stocké dans ceph (donc nos disques) sont découpés en plein de petits “bouts” qui sont distribués pseudo aléatoirement sur tous les OSD. L'algorithme qui s'occupe de déterminer où mettre (et où accéder) les bouts sur les OSD s'appelle CRUSH (Controlled, Scalable, Decentralized Placement of Replicated Data).

Au moment où vous voulez accéder au disque de la VM XYZ, vous contactez les mons pour qu'ils vous transmettent toutes les informations sur la topologie du cluster. Avec ces information, vous appliquez l'algorithme CRUSH, et vous déterminez la position de chaque “bout” d'objet sur les différents OSD. Une fois que c'est fait, vous contactez les différents OSD pour récupérer votre image.

Concrètement, vous avez plusieurs pools. Une pool est un espace dans lequel vous pouvez mettre des objets (genre des disques) et sur laquelle vous spécifiez différentes propriétés (comme par exemple le nombre de replications, ou qui peut y accéder et faire quoi). On peut créer des pools pour différents types d'utilisation.

En fait, plus précieusement, chaque pool a un nombre de placement groups (souvent appelées pgs). C'est une sorte de conteneur de données. Ainsi CRUSH permet de déterminer dans quels placement group est n'importe quel “bout” des disques. Ensuite, on fait la correspondance OSD ↔ placement group pour récupérer les données.

La réplication des données est vraiment le truc le plus essentiel dans notre infra. On ne veut pas que si un disque meurt, on perde quoique ce soit. Pour ça, on a défini plusieurs replicas par pool. Typiquement, un pool sera répliquée 3 fois, on peut donc se permettre d'avoir deux disques qui lâchent en même temps.

Si un disque lâche, Ceph étant résilient, il va recopier (et répartir équitablement) toutes les placement groups qui étaient sur ce disque, sur tous les autres disques (en se servant des autres replicas).

La replication ne se fait pas totalement n'importe comment. Il y a ce qu'il s'appelle une crush ruleset (ensemble de règle) qui définit comment les placement groups se répartissent sur les OSD. Typiquement, la feature la plus importante est le fait de pouvoir spécifier que, pour une pool répliquée 3 fois, les placement groups répliqués ne doivent pas être placés sur le même serveur (host). Comme ça, si jamais un serveur tombe, on est sûrs que il y a des replicas sur les autres serveurs.

On peut faire des trucs bien plus compliqués avec les ruleset, mais restons simple. Pour voir les ruleset

ceph osd crush rule ls

puis (par exemple pour replicated_rule)

ceph osd crush rule dump replicated_rule

Lancez celles-ci en root sur un noeud de stockage.

ceph status

Permet de voir le status du cluster. (la commande la plus utile de toutes)

ceph health detail

Permet de voir le détail, c'est cette commande qui permet d'orienter vos recherches quand quelquechose ne va pas

ceph -w

Permet de voir le status + les événement arrivant sur le cluster

ceph osd tree

Pour voir tous les OSDs

ceph mon stat

Permet de voir le cluster des mons

ceph osd lspools

Pour voir toutes les pools

rbd ls nom_d'une_pool

Pour voir toutes les block devices d'une pool

rbd snap ls nom_d'une_pool/nom_d'un_block_device

Pour voir tous les snapshots d'un block device

Si vous avez des problèmes avec vos Placement Groups c'est peut-être qu'un disque est endommagé, vous pouvez allez voir ici, pour s'en assurer et savoir comment on remplace un disque.

À MiNET, nous disposons de 3 serveurs qui agissent comme noeud Ceph: Atlas, Callisto et Phobos. Callisto est au U1 alors que Phobos & Atlas sont en salle serveur.

Dans chaque serveur, il y a 10 OSDs (liés à des disques de 2TB), un mon et un mgr.

Attention: Un mon est installé aussi sur discovery et sur houston. La raison est simple: le quorum. Si jamais la salle serveur n'est plus alimentée: Phobos et Atlas s'éteignent, Callisto étant seul, il n'atteint pas le quorum et s'éteint.

Pour qu'il soit encore en majorité il a fallut rajouter des MON sur d'autres noeuds dans d'autres salles (d'où sur Houston et sur Discovery). Ainsi si jamais on éteint la salle serveur, Callisto Ces MONs ne sont pas des dans des VMs/CTs__, c'est normal ! Il faut qu'il puissent avoir une IP dans le 142, or, vu qu'on ne veut pas que les VMs puissent avoir une patte dans le 142, on a pas fait de bridge, et donc on a du mettre directement sur l'host. En plus, ça évite qu'on ait besoin du système d'hypervision pour lancer le stockage (donc on évite qu'il y ait une potentielle double dépendance hyperviseur↔stockage).

On voit bien sur ce schéma très propre, que si vous enlevez une salle (bulle bleue) il vous reste toujours 3 MONs sur 5! Vous avez donc la majorité

Si vous regardez /etc/ceph/ceph.conf, vous vous étonnerez sûrement de ne pas voir Discovery et Houston dans “mon_initial_members = phobos,callisto,atlas”. C'est normal, on ne veut pas dépendre des noeuds de calcul pour lancer le stockage, ne vous inquiétez pas, une fois lancé, leur vote sera quand même pris en compte.