Dépannage des OSD et des moniteurs Ceph dans des environnements Proxmox

Intro

Cette version française explique Ceph OSD and monitor troubleshooting for Proxmox environments avec le même objectif pratique que l article source : aider le lecteur à comprendre le contexte, les décisions à prendre et les points à vérifier avant de passer à l action.

Ceph sous-tend de nombreux environnements Proxmox, et lorsque des OSD tombent, que des moniteurs perdent le quorum, ou que des placement groups (PG) se dégradent, le rayon d'impact peut croître très vite. Ce guide de Ceph troubleshooting propose une méthode claire et reproductible pour diagnostiquer et corriger les problèmes les plus courants : OSD down/out, difficultés côté moniteurs, Ceph health warning, PG dégradées ou bloquées, ainsi que les soucis disque ou réseau sous-jacents.

Ce que vous obtiendrez :

• Un workflow de dépannage éprouvé sur le terrain
• Des extraits de commandes à exécuter depuis n'importe quel nœud
• Des garde-fous pour éviter la « churn » de données en maintenance
• Un petit pilote local, sûr, à exécuter avant un déploiement plus large

Vue d'ensemble du workflow

Utilisez cette séquence pour limiter l'impact et accélérer le retour au vert :

1. Confirmer l'état et l'impact

• ceph -s et ceph health detail
• Identifiez les pools et clients affectés. Si l'impact est faible et que vous prévoyez une maintenance, envisagez de définir temporairement noout. Sinon, conservez le comportement par défaut pour que Ceph puisse se soigner.

1. Cartographier la portée

• 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 moniteurs

1. Stabiliser avant les changements

• Pour une opération planifiée, ceph osd set noout pour prévenir les rééquilibrages inutiles ; retirez-le rapidement avec ceph osd unset noout
• Évitez de modifier plusieurs variables en même temps

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

• 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 OSD ↔ disques
• smartctl -a /dev/<disk> ou nvme smart-log /dev/<nvme>
• ip link, ip addr, ethtool -S <iface> pour repérer pertes et erreurs

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

• Redémarrez les services défaillants si la cause est transitoire
• Remplacez les disques en panne et réintégrez les OSD
• Réweight ou mark out uniquement quand la direction est claire
• Surveillez la vitesse de recovery et la latence client ; ajustez temporairement la priorité de recovery si nécessaire

1. Post-incident

• Retirez les drapeaux temporaires (noout, nobackfill, norecover)
• Revérifiez ceph health detail et les journaux
• Documentez ce qui a fonctionné et positionnez des alertes pour une détection précoce

Triage santé rapide

Commencez par la santé globale, puis orientez-vous vers le sous-système en alerte.

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 hôte complet, ne rapportent plus. Vérifiez alimentation, services, et disques.
• PG_DEGRADED ou PG_UNDERSIZED : la redondance est inférieure à la cible. Inspectez les OSD down et la paire size/min_size des pools.
• MON_DOWN ou quorum moniteur réduit : les opérations client peuvent continuer mais les changements de cluster et la recovery peuvent stagner. Restaurez rapidement le quorum.
• Avertissements de désynchronisation d'horloge : corrigez NTP/chrony et gardez l'heure cohérente sur tous les nœuds.

Pour une maintenance sur un cluster sain, utilisez ceph osd set noout juste avant et ceph osd unset noout immédiatement après. Laisser noout trop longtemps peut masquer de vrais incidents et accroître le risque.

Diagnostics OSD down/out

1. Vérifier processus et journaux

• systemctl status ceph-osd@<id>
• journalctl -u ceph-osd@<id> --since -2h
• ceph osd tree pour visualiser 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 filesystem et l'état 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 les erreurs I/O noyau

1. Ramener un OSD si le disque est sain

• systemctl restart ceph-osd@<id>
• Surveillez : ceph -s et ceph osd stat

1. Si le disque est défaillant

• Marquez l'OSD out pour déclencher le backfill : ceph osd out <id>
• Remplacez le disque, préparez et créez un nouvel OSD (méthode de provisionnement standard), puis :
• Vérifiez son intégration : ceph osd tree et ceph osd df
• Ajustez le poids si nécessaire : ceph osd reweight <id> <0.0-1.0>

1. Éviter la churn lors d'arrêts courts

• Pour des redémarrages planifiés brefs, utilisez noout pour éviter les mouvements inutiles
• En cas de panne réelle, ne laissez pas l'OSD in ; marquez-le out pour permettre la recovery

Moniteurs et restauration du quorum

Les moniteurs maintiennent la carte du cluster et le quorum. Une perte de quorum bloque de nombreuses opérations.

1. Évaluer la santé des moniteurs

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

1. Corriger l'évidence d'abord

• Assurez une bonne synchronisation du temps (chrony/ntpd)
• Vérifiez la connectivité réseau entre moniteurs
• systemctl status ceph-mon@<host> et journalctl -u ceph-mon@<host>

1. Restaurer le quorum

• Si un processus mon est down mais que l'hôte est sain, redémarrez-le
• Si l'hôte est down, récupérez le nœud ou déplacez le rôle vers un nœud sain selon vos standards opérationnels
• Visez un nombre impair de moniteurs (souvent 3) sur des nœuds fiables

1. Retirer ou remplacer un moniteur mort uniquement en cas de certitude

• Après perte permanente confirmée, retirez-le du monmap en suivant la CLI supportée par votre déploiement
• Ajoutez un moniteur de remplacement et confirmez la stabilisation du quorum

Vérification : ceph -s doit indiquer un monmap sain et un quorum présent.

PG dégradées et récupération

Des PG dégradées ou undersized augmentent le risque. Stabilisez rapidement.

1. Inspecter les PG

• ceph pg stat
• ceph pg ls-by-state degraded, undersized, peering, backfill_wait, backfilling
• Pour une PG précise : ceph pg <pgid> query

1. Trouver les OSD manquantes ou lentes

• Examinez les acting et up sets dans la requête PG
• Recoupez avec ceph osd tree et l'état des services

1. Favoriser la recovery, prudemment

• Assurez suffisamment d'OSD up pour atteindre min_size
• Si besoin, augmentez temporairement l'effort de recovery en période creuse (exemple) :
• ceph tell osd.* injectargs '--osd_max_backfills 2 --osd_recovery_max_active 3 --osd_recovery_op_priority 63'
• Surveillez la latence client ; revenez aux valeurs par défaut après la recovery

1. Réparation de PG (ultime recours pour cas de corruption ciblés)

• ceph pg repair <pgid>
• À utiliser avec parcimonie et seulement après avoir confirmé la santé des OSD sous-jacents

La recovery est complète quand les PG reviennent à active+clean et que ceph health est OK.

Contrôles disque et réseau

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

Vérifs disque

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

Vérifs réseau

• ip link show et ip addr show pour confirmer interfaces et VLANs
• ethtool -S <iface> pour drops, erreurs CRC, overflows fifo
• Assurez une MTU cohérente de bout en bout sur les réseaux public et cluster de Ceph
• Validez la configuration bonding/LACP si utilisée

Spécifiques Proxmox

• Vérifiez que les trafics public et cluster de Ceph empruntent des réseaux fiables
• Assurez la synchro horaire des hôtes Proxmox et une gestion réseau stable ; un réseau bruité peut se traduire par une instabilité Proxmox Ceph

Plan pilote local

Démarrez petit, mesurez, et facilitez l'inspection locale.

Objectif

• Valider le comportement de redémarrage d'OSD et la recovery de PG sans risque pour la production

Étapes du pilote

1. Créer un petit pool de test

• ceph osd pool create pilot-pool 32
• Définissez 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
• Mappez et écrivez quelques centaines de Mo pour générer de l'activité PG

1. Simuler un redémarrage d'OSD unique en période creuse

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

1. Capturer les métriques

• Temps de recovery, latence client maximale, nombre de PG déplacées
• Fixez des seuils acceptables pour la production

1. S'exercer à un remplacement contrôlé de disque sur un spare

• Marquez un OSD out, remplacez un disque de réserve, ré-ajoutez un OSD, et confirmez la vitesse et la propreté de la recovery

Critères de succès

• Retour des PG à active+clean dans votre fenêtre cible
• Pas d'erreurs I/O client inattendues
• Les drapeaux temporaires sont immédiatement nettoyés après usage

Conclusion

Une approche rapide et disciplinée du Ceph troubleshooting maintient la stabilité des environnements Proxmox, même en cas de pannes. Commencez par ceph -s et les détails de santé, cartographiez la portée, stabilisez avec le minimum de drapeaux, corrigez les causes à l'échelle nœud ou disque, puis récupérez et vérifiez. N'utilisez un tuning de recovery ciblé que sous surveillance de l'impact client. Enfin, validez le tout avec un petit pilote local avant une application large.

Vérifications finales

• Confirmer l'absence de drapeaux persistants : ceph osd dump | grep flags
• S'assurer que les moniteurs sont en quorum et que la synchro horaire est saine
• Vérifier que les PG sont active+clean et que le min_size des pools est sûr
• Documenter les étapes et les seuils pour accélérer le prochain incident

Mots-clés à garder en tête : Ceph OSD down, Ceph monitor, Ceph health warning, Proxmox Ceph, et les bases du Ceph storage cluster pour Proxmox VE.