Dépannage Ceph OSD et Monitor pour Proxmox : Guide pratique

Ceph est au cœur de nombreux environnements Proxmox, mais lorsque des OSD tombent, les monitors perdent le quorum ou les groupes de placement (PG) se dégradent, l'impact peut s'étendre rapidement. Ce guide vous donne une méthode claire et reproductible pour trier et corriger les problèmes les plus courants : OSD down/out, soucis de monitor, alertes de santé, PG dégradés ou bloqués, et problèmes de disque ou de réseau sous-jacents.

Ce que vous obtiendrez

• Un workflow de dépannage testé sur le terrain
• Des extraits de commandes exécutables sur n'importe quel nœud
• Des garde-fous pour éviter le brassage de données pendant la maintenance
• Un petit pilote sûr à exécuter localement avant un déploiement large

Vue d'ensemble du workflow

Suivez cette séquence pour limiter l'impact et raccourcir le retour au vert :

1. Confirmer l'état et l'impact

• ceph -s et ceph health detail
• Identifier les pools et clients affectés. Si l'impact est faible et que vous prévoyez de la maintenance, envisagez de définir temporairement noout ; sinon, conservez le comportement par défaut pour laisser Ceph s'auto-guérir.

1. Cartographier l'étendue

• ceph osd tree et ceph osd stat pour lister les OSD down
• ceph pg stat et ceph pg ls-by-state degraded, undersized, peering
• ceph mon stat et ceph quorum_status --format json-pretty pour la santé des monitors

1. Stabiliser avant les changements

• Pour un travail planifié, ceph osd set noout pour empêcher un rééquilibrage inutile ; le retirer avec ceph osd unset noout dès que possible
• Éviter de modifier plusieurs variables à la fois

1. Vérifications nœud et périphérique

• systemctl status ceph-osd@<id>, ceph-mon@<host>
• journalctl -u ceph-osd@<id> et journalctl -u ceph-mon@<host>
• ceph-volume lvm list pour mapper les OSD aux périphériques
• smartctl -a /dev/<disk> ou nvme smart-log /dev/<nvme>
• ip link, ip addr, ethtool -S <iface> pour pertes et erreurs

1. Corriger la cause, puis récupérer

• Redémarrer les services en échec si la cause est transitoire
• Remplacer les disques défaillants et réajouter les OSD
• Rééquilibrer (reweight) ou marquer out seulement quand vous êtes sûr de la direction
• Surveiller la vitesse de récupération et la latence client ; ajuster temporairement le throttling de récupération si nécessaire

1. Post-incident

• Nettoyer les drapeaux temporaires (noout, nobackfill, norecover)
• Revérifier ceph health detail et les logs
• Documenter ce qui a fonctionné et configurer des alertes pour une détection précoce

Triage rapide de la santé

Commencez par la santé globale, puis pivotez vers le sous-système en rouge.

Commandes :

• ceph -s
• ceph health detail
• ceph osd tree
• ceph mon stat

Guide d'interprétation :

• OSD_DOWN ou OSD_HOST_DOWN : Un ou plusieurs démons OSD ou un nœud entier ne rapportent plus. Vérifier l'alimentation, les services et les disques.
• PG_DEGRADED ou PG_UNDERSIZED : La redondance des données est en dessous de la cible. Examiner les OSD down et la taille du pool (size/min_size). Par exemple, si vous voyez PG_DEGRADED sur le pool vmdata, lancez ceph pg ls-by-pool vmdata degraded pour lister les PG affectés.
• MON_DOWN ou quorum monitor bas : Les opérations client peuvent continuer mais les changements de cluster et la récupération peuvent bloquer. Restaurer le quorum rapidement.
• Avertissements de dérive d'horloge (clock skew) : Corriger NTP/chrony et assurer une heure cohérente sur tous les nœuds.

Si vous devez faire de la maintenance sur un cluster sain, utilisez ceph osd set noout juste avant le travail et ceph osd unset noout immédiatement après. Laisser noout activé longtemps peut masquer de vraies pannes et augmenter le risque.

Diagnostic OSD Down/Out

1. Vérifier le processus et les logs

• systemctl status ceph-osd@<id>
• journalctl -u ceph-osd@<id> --since -2h
• ceph osd tree pour voir l'hôte et le placement CRUSH

1. Mapper l'OSD au périphérique

• ceph-volume lvm list | less
• lsblk -f pour confirmer le système de fichiers et la santé du périphérique

1. Santé du disque

• smartctl -a /dev/<disk> ou nvme smart-log /dev/<nvme>
• dmesg | grep -i -E 'blk|i/o|nvme|sata|scsi' pour erreurs I/O noyau

1. Remonter un OSD si le disque est sain

• systemctl restart ceph-osd@<id>
• Surveiller : ceph -s et ceph osd stat
• Vérifier le log OSD pour des messages peer missing indiquant un aléa réseau transitoire.

1. Si le disque est en panne

• Marquer l'OSD out pour déclencher le backfill : ceph osd out <id>
• Remplacer le disque, préparer et créer un nouvel OSD (selon votre méthode de provisionnement standard), puis :
• Vérifier qu'il rejoint : ceph osd tree et ceph osd df
• Rééquilibrer si nécessaire : ceph osd reweight <id> <0.0-1.0>

1. Éviter le brassage pendant les courtes indisponibilités

• Pour des redémarrages brefs planifiés, utiliser noout pour empêcher les mouvements inutiles
• Pour de vraies pannes, ne pas laisser l'OSD in ; le marquer out pour que la récupération progresse

Récupération Monitor et Quorum

Les monitors maintiennent la map du cluster et le quorum. La perte de quorum bloque de nombreuses opérations.

1. Évaluer la santé des monitors

• ceph mon stat
• ceph quorum_status --format json-pretty
• ceph mon dump

1. Corriger l'évident en premier

• S'assurer que la synchronisation d'heure est saine (chrony/ntpd)
• Vérifier la reachabilité réseau entre monitors
• systemctl status ceph-mon@<host> et journalctl -u ceph-mon@<host>

1. Restaurer le quorum

• Si un processus mon est down mais l'hôte va bien, le redémarrer
• Si l'hôte est down, récupérer le nœud ou déplacer le rôle vers un nœud sain selon votre standard opérationnel
• Viser un nombre impair de monitors (souvent 3) sur des nœuds fiables

1. Supprimer ou remplacer un monitor mort seulement quand certain

• Après confirmation de perte permanente, le retirer du monmap via le CLI supporté par votre déploiement
• Ajouter un monitor de remplacement et confirmer que le quorum se stabilise

Revérification : ceph -s doit montrer monmap sain et quorum présent.

PGs dégradés et récupération

Quand les PGs sont dégradés ou undersized, les données sont plus à risque. Stabiliser vite.

1. Inspecter les PGs

• ceph pg stat
• ceph pg ls-by-state degraded, undersized, peering, backfill_wait, backfilling
• Pour un PG spécifique : ceph pg query <pgid>
• Identifier les OSD manquants ou lents
• Examiner les ensembles acting et up dans le query PG
• Croiser ces OSD avec ceph osd tree et le statut des services

1. Encourager la récupération, en sécurité

• S'assurer qu'assez d'OSD sont up pour respecter le min_size du pool
• Si nécessaire, augmenter temporairement l'effort de récupération pendant les fenêtres de faible trafic (exemple) :

     ceph tell osd.* injectargs '--osd_max_backfills 2 --osd_recovery_max_active 3 --osd_recovery_op_priority 63'

Ces valeurs sont des points de départ ; ajuster selon la taille du cluster et la capacité réseau.

• Observer la latence client ; revenir aux défauts après récupération

1. Réparation PG (dernier recours pour corruption spécifique)

• ceph pg repair <pgid>
• Utiliser parcimonieusement et seulement après avoir confirmé que les OSD sous-jacents sont sains

La récupération est complète quand les PGs reviennent à active+clean et ceph health est OK.

Vérifications disque et réseau

Ceph dépend de disques prévisibles et d'un réseau propre, sans pertes.

Vérifications disque

• smartctl -a /dev/<disk> ou nvme smart-log /dev/<nvme>
• Comparer erreurs média, usure et température entre pairs
• dmesg pour resets I/O, timeouts, ou fautes contrôleur

Vérifications réseau

• ip link show et ip addr show pour confirmer interfaces et VLANs
• ethtool -S <iface> pour drops, erreurs CRC, overflows fifo
• Assurer MTU cohérent de bout en bout sur réseaux public et cluster Ceph
• Valider réglages bonding/LACP si utilisés

Spécificités Proxmox

• Vérifier que le trafic Ceph public et cluster passe sur des réseaux fiables
• Assurer synchronisation d'heure hôte Proxmox et réseau de gestion stable ; des réseaux bruyants peuvent cascader en instabilité Ceph

Plan de pilote local

Commencez petit, mesurez, et rendez l'inspection locale facile.

Objectif

• Valider le comportement de redémarrage OSD et la récupération PG sans risquer la production

Étapes du pilote

1. Créer un petit pool de test

• ceph osd pool create pilot-pool 32
• Définir size=3, min_size=2 sur une règle de réplication adaptée à votre matériel

1. Créer un petit RBD et écrire des données

• rbd create pilot-pool/pilot-vol --size 64M
• Mapper et écrire quelques centaines de Mo pour générer de l'activité PG

1. Simuler un redémarrage OSD unique pendant une fenêtre de faible trafic

• ceph osd set noout
• systemctl restart ceph-osd@<id>
• Surveiller ceph -s et ceph pg stat jusqu'à stabilité
• ceph osd unset noout

1. Capturer les métriques

• Temps de récupération, latence client max, nombre de PG déplacés
• Définir seuils acceptables pour la production

1. Pratiquer un remplacement disque contrôlé sur un spare

• Marquer un OSD out, remplacer un disque spare, réajouter un OSD, et confirmer vitesse et propreté de récupération

Critères de succès

• PGs reviennent à active+clean dans votre fenêtre cible
• Aucune erreur I/O client inattendue
• Drapeaux temporaires nettoyés immédiatement après usage

Conclusion

Une approche rapide et disciplinée du dépannage Ceph maintient les environnements Proxmox stables même pendant les pannes. Commencez par ceph -s et les détails de santé, cartographiez l'étendue, stabilisez avec des drapeaux minimaux, corrigez les causes racines au niveau nœud ou disque, puis récupérez et vérifiez. Utilisez le réglage ciblé de récupération seulement en surveillant l'impact client. Enfin, validez tout avec un petit pilote local avant d'appliquer les changements largement.

Prochaines vérifications

• Confirmer aucun drapeau résiduel : ceph osd dump | grep flags
• S'assurer que les monitors sont en quorum et que la sync d'heure est saine
• Vérifier que les PGs sont active+clean et que le min_size du pool est sûr
• Documenter étapes et seuils pour que le prochain incident soit plus rapide