Différences

Ci-dessous, les différences entre deux révisions de la page.

--- wiki:cluster:ceph [2018/06/16 21:28]
insolentbacon
+++ wiki:cluster:ceph [2020/06/27 18:16] (Version actuelle)
@@ Ligne 1: / Ligne 1: @@
 ====== Ceph ======
-À MiNET, depuis 2018, on utilise un cluster [[https://ceph.com|Ceph]] pour le stockage.
+Avant de zoulouter sur ceph merci de consulter la [[http://docs.ceph.com/docs/master/|doc]], sinon vous pourrez avoir des surprises (du genre plus d'accès aux données)
+Il y aussi la [[https://wiki.gentoo.org/wiki/Ceph/Guide#Monitor_server|documentation de Gentoo]] qui explique bien les concepts
+À MiNET, depuis 2018, on utilise un cluster [[https://ceph.com|Ceph]] pour le stockage pour un tas de [[wiki:cluster:ceph:choix|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.
+===== Politique de sauvegarde =====
+Nous n'avons actuellement pas de [[wiki:cluster:ceph:backup_morte|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 [[https://gitlab.minet.net/InsolentBacon/insolentbackuper|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 [[https://gitlab.minet.net/varens/ceph_snapshots_monitoring|quelques scripts]].
+===== Ceph =====
 D'après [[https://fr.wikipedia.org/wiki/Ceph|Wikipédia]]:
@@ Ligne 21: / Ligne 39: @@
 [[http://docs.ceph.com/docs/mimic/rbd/|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.
-![Schéma RADOS](http://docs.ceph.com/docs/giant/_images/stack.png)
+{{ :wiki:cluster:stack.png?600 |}}
 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.
@@ Ligne 29: / Ligne 47: @@
 Au moment où vous voulez accéder au disque de la VM XYZ, vous contactez les //mon//s 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 //pool//s. 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). On peut créer des pools pour différents types d'utilisation.
+Concrètement, vous avez plusieurs //pool//s. 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 [[http://docs.ceph.com/docs/jewel/rados/operations/placement-groups/|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 =====
+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
 ===== Les commandes usuelles =====
-Lancez celle-ci en root sur un noeud de stockage.
+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
@@ Ligne 49: / Ligne 84: @@
 Pour voir tous les OSDs
+> ceph mon stat
+Permet de voir le cluster des mons
 > ceph osd lspools
@@ Ligne 61: / Ligne 99: @@
 Pour voir tous les snapshots d'un block device
-==== Remplacer un disque défaillant ====
-Voir [[wiki:cluster:ceph:remplacement_disque|Remplacer un disque]]
+==== Problèmes de PGs - Remplacer un disque défaillant ====
+Si vous avez des problèmes avec vos Placement Groups c'est peut-être qu'un disque est endommagé, vous pouvez allez voir [[wiki:cluster:ceph:remplacement_disque|ici]], pour s'en assurer et savoir comment on remplace un disque.
+===== À MiNET... =====
+{{ :wiki:cluster:schema_ceph.jpg?400 |}}
+À 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).
+{{ :wiki:cluster:schema_ceph_justification_mon.jpg?600 |}}
+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.

WikiMiNET

Outils pour utilisateurs

Outils du site

Différences

Outils de la page