Différences

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

--- wiki:cluster:ceph [2018/06/16 21:34]
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 33: / Ligne 51: @@
 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 =====
@@ Ligne 41: / Ligne 74: @@
 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 65: / Ligne 100: @@
-==== Remplacer un disque défaillant ====
+==== 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.
-Voir [[wiki:cluster:ceph:remplacement_disque|Remplacer un disque]]

WikiMiNET

Outils pour utilisateurs

Outils du site

Différences

Outils de la page