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.
On utilise désormais Proxmox Backup qui exécute la backup sur les limbes
La politique que nous avons choisie est la suivante : une sauvegarde tous les :
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 moniteur Ceph (ceph-mon
) maintient les cartes de l'état du cluster, y compris la carte des moniteurs, la carte des managers, la carte des OSDs, la carte des MDS et la CRUSH map.
Ces cartes constituent l'état critique du cluster nécessaire pour que les démons Ceph puissent se coordonner entre eux. Les moniteurs sont également responsables de la gestion de l'authentification entre les démons et les clients. Au moins trois moniteurs sont normalement nécessaires pour la redondance et la haute disponibilité.
Ce sont les premiers éléments du cluster que l'on contacte pour récupérer la
crush map
et localiser où sont stockées les données (i.e. dans quels OSDs).
Un démon Ceph Manager (ceph-mgr
) est responsable du suivi des mesures d'exécution et de l'état actuel du cluster Ceph, y compris l'utilisation du stockage, les mesures de performance actuelles et la charge du système.
Les manageurs sont contactés après avoir récupéré le
crush map
des MONs, pour directement récupérer les données stockées sur les OSDs du manageur.
Un démon de stockage d'objets (Ceph OSD, ceph-osd) stocke les données, gère la réplication, la récupération et le rééquilibrage des données, et fournit certaines informations de surveillance aux moniteurs et gestionnaires Ceph en vérifiant les autres démons Ceph OSD pour un battement de cœur.
Les OSDs sont lié (à MiNET) à un disque dur directement.
Les bluestore sont toutes les méta data qui permettent de gérer les disques liés aux OSDs (ici on différencie OSD et disque. Ce qui permet de faire le lien et permet de les confondre à MiNET, c'est grâce aux bluestore).
Les bluestore sont stockées dans une base de données sur un disque dédié (une partition par OSD).
La rapidité d'écriture et de lecture de cette base de données détermine la rapidité entière du cluster CEPH.
C'est pour cette raison, que nous avons fait le choix de stocker les bluestore sur des SSDs et non des HDD classiques. Cela ralentit vraiment trop le cluster.
Attention les SSDs sont fragiles et limités en capacité écritures/lectures.
Il faut impérativement monitorer, surveiller et changer en avance les SSDs de CEPH au moindre problème/doute. Une simple mise hors tension peut mener à la perte totale de toutes vos données CEPH, même tous les HDD vont bien.
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) : weil-crush-sc06.pdf
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.
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.
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.
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.