Règles CRUSH : classes de disques, failure domain host / rack¶

Day 1 · DéployerNiveau 3 · MaîtriserProcédureRédigé · à valider en lab

Objectif : placer chaque pool sur la bonne classe de disques (par exemple ceph-vm sur NVMe, un pool d'archives sur HDD) et choisir l'unité de panne que Ceph ne doit jamais charger de deux copies : l'hôte par défaut, le rack si vos nœuds sont répartis dans plusieurs baies ou salles. Modifier la carte ou les règles CRUSH d'un cluster en production déplace des données : c'est une opération à confier au MSP (N2 et N3 ; en N1, sur devis). Cette page vous permet de comprendre et de préparer la demande.

Avant de toucher la prod

ceph -s en HEALTH_OK, 100 % active+clean, aucun OSD au-delà de 70 % (ceph osd df tree).
Sauvegarde de la carte CRUSH actuelle (commande à l'étape 1).
Fenêtre de maintenance prévue : un changement de règle peut déplacer la totalité d'un pool.
Assez d'OSD de la classe cible sur au moins size hôtes (ou racks) différents.
Validation MSP obtenue via ticket iTop.

Étapes¶

1. Observer et sauvegarder¶

ceph osd getcrushmap -o /root/crushmap-$(date +%F).bin   # sauvegarde binaire
ceph osd crush tree --show-shadow      # arbre avec les classes (default~ssd, default~nvme…)
ceph osd crush class ls                # classes présentes
ceph osd crush rule ls                 # règles existantes (replicated_rule par défaut)
ceph osd pool ls detail                # règle utilisée par chaque pool (crush_rule N)

2. Corriger une classe de disque mal détectée¶

GUICLI

Nœud → Ceph → OSD : la colonne Class affiche la classe. La GUI ne permet de la choisir qu'à la création de l'OSD (Device Class).

ceph osd crush rm-device-class osd.7
ceph osd crush set-device-class nvme osd.7

3. Créer une règle par classe¶

La règle se crée en CLI. Syntaxe : ceph osd crush rule create-replicated <nom> <racine> <failure-domain> <classe>.

ceph osd crush rule create-replicated replicated-nvme default host nvme
ceph osd crush rule create-replicated replicated-hdd  default host hdd

4. Affecter la règle aux pools¶

GUICLI

Nœud → Ceph → Pools → sélectionner ceph-vm → Edit → Crush Rule = replicated-nvme → OK.

ceph osd pool set ceph-vm crush_rule replicated-nvme
ceph osd pool set .mgr crush_rule replicated-nvme     # voir encadré ci-dessous
watch ceph -s                                         # suivre le déplacement des PG

Autoscaler et classes

Proxmox l'indique : avec l'autoscaler de PG, tous les pools doivent utiliser des règles du même type, soit toutes avec une classe, soit aucune. Un pool resté sur replicated_rule (souvent .mgr) chevauche les racines par classe et l'autoscaler cesse de calculer (ceph osd pool autoscale-status vide ou en erreur). Basculez donc aussi .mgr et les pools CephFS.

5. Failure domain rack (nœuds répartis dans plusieurs baies)¶

Le rack devient l'unité de panne : il faut au moins autant de racks que de copies (3 racks pour un réplica 3, 4 pour pouvoir reconstruire).

ceph osd crush add-bucket rack1 rack
ceph osd crush add-bucket rack2 rack
ceph osd crush add-bucket rack3 rack
ceph osd crush move rack1 root=default
ceph osd crush move rack2 root=default
ceph osd crush move rack3 root=default
ceph osd crush move pve01 rack=rack1
ceph osd crush move pve02 rack=rack2
ceph osd crush move pve03 rack=rack3
ceph osd crush rule create-replicated replicated-rack-nvme default rack nvme
ceph osd pool set ceph-vm crush_rule replicated-rack-nvme

6. Tester une règle avant de l'appliquer (recommandé)¶

ceph osd crush rule dump replicated-rack-nvme | grep rule_id
ceph osd getcrushmap -o /tmp/crush.bin
crushtool -i /tmp/crush.bin --test --rule <rule_id> --num-rep 3 --show-bad-mappings
# Aucune ligne "bad mapping" attendue

Vérifications

ceph osd pool get ceph-vm crush_rule     # crush_rule: replicated-nvme
ceph osd crush tree                      # hôtes sous les bons racks
ceph osd pool autoscale-status           # tous les pools listés
ceph -s                                  # retour à 100 % active+clean, HEALTH_OK
ceph pg ls-by-pool ceph-vm | head        # colonne UP : OSD de la bonne classe, sur 3 hôtes ou racks distincts

Rollback

Remettre l'ancienne règle sur le pool (ceph osd pool set ceph-vm crush_rule replicated_rule) : les données reviennent à leur placement précédent, avec un nouveau déplacement. En dernier recours, réinjecter la carte sauvegardée : ceph osd setcrushmap -i /root/crushmap-<date>.bin, uniquement avec le MSP.

Pièges vus en support

Règle rack avec seulement 2 racks pour un réplica 3 : la 3e copie ne trouve pas de place, PG undersized en permanence.
Changer la règle d'un pool de 20 To en pleine journée : reconstruction massive, latences des VMs multipliées.
SSD SATA et NVMe dans la même classe ssd : le pool est tiré vers la performance du plus lent.
.mgr oublié sur replicated_rule : l'autoscaler ne fonctionne plus.
Déplacer un hôte dans un rack puis réinstaller le nœud : vérifier après redémarrage des OSD que l'hôte est resté sous son rack (ceph osd crush tree).

Quand ouvrir un ticket iTop

Toute création ou modification de règle CRUSH, ajout de racks, changement de classe en production : demande planifiée P4 avec la sortie de ceph osd crush tree --show-shadow et ceph osd pool ls detail. PG undersized ou remapped qui ne se résorbent pas après un changement : P2.

Ouvrir un ticket iTop