Réparer une panne d'OSD Ceph : rééquilibrage des données, problèmes de backfilling et processus de remplacement d'OSD

Réparer une panne d’OSD Ceph est une tâche de routine dans les environnements de stockage d’objets distribués, mais elle comporte des risques : un mauvais réglage peut dégrader les E/S en production, un retrait précipité d’OSD peut entraîner des PGs unsized/lost. Cet article explique étape par étape comment détecter en toute sécurité une panne d’OSD, résoudre les problèmes de backfill/rebalance, ajuster de manière responsable les paramètres de recovery et effectuer un remplacement d’OSD à la fois manuellement avec ceph-volume et de façon orchestrée avec cephadm. Le public visé comprend les administrateurs, system engineers et storage operators.

Pourquoi l’accent sur le rebalance et le backfill est important

OSD signifie Object Storage Daemon ; il représente un disque et le démon associé qui gère les objets dans des Placement Groups (PGs). Lorsqu’un OSD tombe en panne, Ceph tente de restaurer les réplicas manquants via le backfill et le rebalancing. Le backfill (copie des données depuis des réplicas existants) et le rebalance (redistribution des placements d’objets) génèrent beaucoup d’E/S réseau et disque. Sans gestion ciblée, cela peut augmenter les latences ou ralentir nettement la récupération — et donc prolonger la période pendant laquelle le cluster n’est pas dans son état optimal.

Premières actions : évaluation rapide

Commencez par un contrôle « First‑Look » pour déterminer l’étendue et l’urgence. Cela aide à décider si vous devez procéder à un ajustement des paramètres, appliquer des flags temporaires ou effectuer un remplacement d’OSD immédiat.

# Gesamtstatus, betroffene PGs, Recovery-Zeit
ceph -s
# Topologie und welcher Host betroffen ist
ceph osd tree
# Kapazitätsverteilung und freie Kapazität
ceph osd df

Important : notez le nombre de PGs degraded/recovering, le Recover‑Throughput et si les messages des MON marquent des OSD existants comme out/down. Ces valeurs déterminent l’urgence.

Réparer une panne d’OSD Ceph : priorités et arbre de décision

Pour décider de la marche à suivre, distinguez trois priorités : 1) préserver l’accès aux données pour les applications, 2) rétablir la santé du cluster, 3) procéder au nettoyage/remplacement durable de l’OSD défectueux. Un schéma rapide en tête :

• Si des erreurs SMART ou des pannes courtes récurrentes sont présentes → remplacer l’OSD.
• Si l’accessibilité réseau/hôte est la cause → diagnostic de l’hôte, éventuellement noout pour maintenance planifiée.
• Si le backfill est extrêmement lent → analyse des causes (réseau, I/O, paramètres) et ajustement temporaire avec plan de retour en arrière.

Contrôles et métriques essentiels

La supervision est essentielle. Principales métriques :

• Statut des PG : active+clean, recovering, degraded — reflète l’état direct.
• Recover Bytes / Recover Throughput : nombre d’octets/sec transférés.
• Latences OSD (read/write) : une augmentation permanente indique des points chauds ou une saturation.
• Métriques réseau : bande passante, perte de paquets, MTU‑mismatch.
• Niveau hôte : iostat, CPU, mémoire, SMART pour les erreurs de disque.

# Live Überwachung
ceph -w
# PG-Übersicht
ceph pg dump pgs_brief
# Beispiel iostat
iostat -x 1 5

Logs et messages d’erreur typiques

Les logs OSD et MON révèlent les causes. Messages fréquents :

• „heartbeat from osd.X timed out“ → accessibilité réseau/hôte ; vérifiez MTU, les logs du switch, IPMI.
• Erreurs SMART ou I/O → disque physique défectueux.
• „slow request“ → performance OSD/périphérique, souvent cause d’un backfill lent.

# OSD-Logs prüfen
journalctl -u ceph-osd@.service -n 200
# Alternativ Ceph-Logs
grep -i "heartbeat" /var/log/ceph/ceph-osd.*.log

Causes typiques d’un backfill très lent

Un backfill lent n’est généralement pas seulement un problème de paramètres. Causes fréquentes :

• Goulots d’étranglement réseau ou perte de paquets (par ex. MTU‑mismatch, QoS, événements Spanning Tree).
• OSD individuels lents (dégradation matérielle, limite IOPS sur le contrôleur RAID).
• Hotspots dans le cluster : certains OSD reçoivent nettement plus de données que d’autres (déséquilibre CRUSH, CRUSH‑Rules mal configurées).
• Absence d’espace libre sur les OSD cibles : le rééquilibrage nécessite de l’espace libre.

Dépannage progressif en cas de backfills bloqués

1. Vérifier le réseau : tests iperf3 entre les hôtes concernés.

# Auf Host B (Server, Empfänger)
iperf3 -s
# Auf Host A (Client, Sender)
iperf3 -c  -t 30

2. Vérifier la MTU et la comparer sur toutes les interfaces OSD.

ip link show eth0
ethtool -k eth0

3. Vérifier la santé et les performances des périphériques (SMART, iostat).

smartctl -a /dev/sdX
iostat -x 1 10

4. Détecter les hotspots : analyser OSD‑DF et les métriques de latence OSD.

ceph osd df tree
# Falls Prometheus vorhanden, prüfen: ceph_osd_op_latency_seconds

Ajustement temporaire des paramètres : modifier avec responsabilité

Les modifications des paramètres de recovery peuvent accélérer le recovery, mais aussi affecter les I/O en production. Sauvegardez d’abord les valeurs actuelles et augmentez progressivement sous surveillance.

# Werte sichern
ceph config get global osd_max_backfills > /tmp/osd_max_backfills.before || true
ceph config get global osd_recovery_max_active > /tmp/osd_recovery_max_active.before || true
# Beispielhafte, konservative Erhöhung
ceph config set global osd_max_backfills 4
ceph config set global osd_recovery_max_active 8

Pourquoi cela fonctionne : osd_max_backfills contrôle combien de threads de backfill s’exécutent simultanément par OSD ; osd_recovery_max_active limite les opérations de recovery parallèles. Une augmentation permet davantage de mouvements de données parallèles, mais exige nettement plus de réserves réseau et disque. Si un échec se produit parce que certains OSD restent lents ou que la bande passante réseau est limitée, alors un recovery intensifié n’aggravera que les latences.

Utilisation judicieuse des flags : noout, norebalance, nobackfill

Les flags peuvent aider, mais ils sont risqués. noout empêche les MONs de retirer automatiquement les OSDs du CRUSH, par exemple lors d’une maintenance temporaire. Utilisez :

# Vor geplanter Wartung
ceph osd set noout
# Nach Abschluss
ceph osd unset noout

Avertissement : noout peut masquer des pannes réelles. norebalance ou nobackfill sont similaires : utiles pour de courtes fenêtres de maintenance, dangereux si un OSD est réellement perdu.

Remplacement d’OSD : workflow et commandes (manuel avec ceph-volume)

Quand un disque est défectueux ou présente des erreurs SMART, un remplacement propre est généralement la meilleure option. Voici une procédure conservatrice et documentable pour un remplacement manuel avec ceph-volume (OSD basés sur LVM) :

1. Retirer proprement l’OSD du service (out) et attendre que les PGs reviennent en état normal.

# Markieren und prüfen
ceph osd out osd.
ceph -s    # beobachten, bis PGs recovering/clean werden

2. Arrêter le service OSD sur l’hôte.

systemctl stop ceph-osd@.service
# Prüfen, dass der Prozess gestoppt ist
systemctl status ceph-osd@.service

3. Zap/supprimez l’ancien périphérique (en cas de remplacement physique).

# Zap löscht LVM/Partition-Header. ACHTUNG: unwiderruflich für das Device
ceph-volume lvm zap /dev/sdX --destroy

Explication: ceph-volume lvm zap supprime les métadonnées Ceph du périphérique et le prépare pour la réutilisation. L’opération peut échouer si le périphérique est occupé; vérifiez les LV avec lvs.

4. Installez le nouveau disque et créez l’OSD.

# Beispiel: neues OSD auf /dev/sdY anlegen
ceph-volume lvm create --data /dev/sdY

Après create, l’OSD est automatiquement enregistré auprès des MONs et les règles CRUSH sont appliquées. Surveillez la progression du rééquilibrage.

Remplacement d’OSD: avec cephadm (orchestré)

Dans les clusters gérés par cephadm, de nombreux exploitants préfèrent la variante orchestrée, car cephadm prend en charge la gestion du cycle de vie (image de conteneur, déploiement d’unités, journalisation). Étapes typiques :

1. Préparer: rendre le nouveau périphérique disponible sur l’hôte.
2. Avec cephadm, ajouter l’OSD sur l’hôte ou remplacer spécifiquement.

# Alle verfügbaren Devices erkennen (nur lesen)
ceph orch device ls
# Alle verfügbaren Devices als OSDs nutzen (vorsichtig; meist in Staging testen)
ceph orch apply osd --all-available-devices
# Alternativ: gezielt ein Device zu einem Host hinzufügen (prüfen in Ihrer Ceph-Version)
# ceph orch daemon add osd :  <-- je nach Version und Politik

Remarque: ceph orch apply osd --all-available-devices est puissant et ne doit être utilisé en production que si vous comprenez la politique de l’orchestrateur. Testez en environnement de staging.

Validation rigoureuse après remplacement

Après chaque remplacement, validez :

• L’état du cluster est HEALTH_OK ou, à défaut, il n’y a plus de PGs en degraded/recovering.
• ceph osd df tree montre une distribution de données homogène et pas de hotspots extrêmes.
• Accès de contrôle aléatoire en lecture sur les pools/objets critiques et comparaison des sommes de contrôle si disponibles.

# Wichtige Prüfungen
ceph -s
ceph health detail
ceph osd df tree
# Beispiel: stichprobenartiger Objekt-Check
rados -p  ls | head
rados -p  get 

Plan de rollback et documentation

Toute modification des paramètres de récupération ou la suppression d’OSD doit être réversible. Préparez des scripts qui restaurent les valeurs de configuration initiales et conservez des horodatages pour toutes les actions.

# Rücksetzskript-Beispiel
prev1=$(cat /tmp/osd_max_backfills.before || echo "2")
prev2=$(cat /tmp/osd_recovery_max_active.before || echo "2")
ceph config set global osd_max_backfills "$prev1"
ceph config set global osd_recovery_max_active "$prev2"
ceph osd unset noout || true

Pièges typiques et comment les éviter

Erreurs courantes :

• Modification des paramètres de récupération sans observabilité: vérifiez toujours les tableaux de bord et les alertes.
• Supprimer un OSD (ceph osd rm) alors que des PGs sont encore en recovering: provoque des PGs lost/unsized.
• Appliquer aveuglément ceph orch apply osd --all-available-devices sur des hôtes hétérogènes: créations d’OSD non désirées.
• Capacité libre insuffisante avant le remplacement: assurez-vous que les OSDs cibles ont suffisamment d’espace.

Liste de contrôle pragmatique pour le remplacement d’OSD

1. Collecter: ceph -s, ceph osd tree, ceph osd df, logs pertinents.
2. Sauvegarder: exporter les valeurs de configuration actuelles (/tmp) et enregistrer des captures d’écran du monitoring.
3. Décider : remplacement ou réparation (hôte vs. disque). En cas d’incertitude, privilégiez reweight plutôt que rm.
4. Effectuer : définir noout pour une maintenance planifiée ; OSD out ; stop ; zap ; create avec ceph-volume ou cephadm.
5. Observer : débit de récupération, latences et charge réseau ; maintenir des points de restauration prêts.
6. Valider : HEALTH_OK, ceph osd df tree, lectures d’échantillonnage.
7. Documenter : heure, valeurs, décisions, action de rollback.

Conclusion

Réparer une panne d’OSD Ceph signifie : travailler de manière structurée, utiliser le monitoring, modifier les paramètres de façon conservatrice et documentée et tester les workflows de remplacement. Séparez les problèmes d’hôte et de disque, privilégiez le reweighting plutôt qu’une suppression immédiate, et n’utilisez des outils orchestrés comme cephadm qu’après des tests en staging. Avec des vérifications claires, des stratégies de repli et des scripts de rollback automatisés, vous réduisez le risque d’incohérences de données et raccourcissez les temps de recovery.

Remarques complémentaires pour l’exploitation

Assurez-vous que vos Runbooks sont exercés régulièrement. Des simulations en staging augmentent la sécurité lors des interventions en production. Définissez également quelles rôles d’équipe sont informés et interviennent dans quel ordre (Operator, NetAdmin, Storage‑Engineer) – cela accélère les escalades et réduit les erreurs lors d’interventions critiques.

Réparer une panne d’OSD Ceph : aspects d’architecture et d’exploitation

Concernant la réparation d’une panne d’OSD Ceph, la correction immédiate n’est qu’un aspect — les décisions d’architecture et l’exploitation courante déterminent en grande partie la rapidité et la sûreté de la récupération. Sont déterminants la stratégie de placement (CRUSH), le type de pool (réplication vs. Erasure Coding), la topologie réseau et la réserve de capacité.

CRUSH‑map et topologie : assurez-vous que les règles CRUSH reflètent les frontières physiques (serveur, châssis, rack, AZ). Sans placement rack‑aware, la défaillance d’un rack augmente le risque que de nombreux réplicas PG soient affectés simultanément, ce qui concentre les charges de backfill.

Conception des pools : les pools répliqués se comportent différemment lors du backfill par rapport aux pools erasure‑coded. Les pools EC nécessitent souvent temporairement plus d’E/S et de bande passante réseau pour la reconstruction et sont moins tolérants à plusieurs pannes simultanées d’OSD. Prévoyez pour les pools EC des réserves de headroom plus importantes et des temps de recovery plus longs dans vos SLOs.

Headroom de capacité : ne faites jamais tourner Ceph de façon durable avec une très forte occupation. Il est recommandé d’avoir une capacité libre (selon la charge de travail) d’au moins 10–20 % pour permettre le rebalancing et l’espace pour les réplicas temporaires. Si les OSD cibles disposent de peu d’espace libre, le backfill stagne et le temps de panne augmente.

Architecture réseau : séparez physiquement le trafic public et le trafic de cluster ou gérez-les via QoS. La saturation de l’interconnect du cluster est l’une des causes les plus fréquentes de backfills lents. Prévoyez des métriques de monitoring pour la perte de paquets, les erreurs MTU et le débit par OSD, et déclenchez des alertes avant que le rebalancing ne commence.

Remarques d’intégration pour l’exploitation : liez les métadonnées OSD à votre CMDB (hôte, emplacement, numéro de série) et à vos outils d’orchestration. Les workflows automatisés pour le remplacement matériel (BMC‑Reboot, ticketing, mise à jour des assets) réduisent les erreurs lors d’interventions manuelles. Les actions de l’orchestrateur (cephadm) doivent être consignées dans des pipelines de changement et testées en staging.

Surveillance et automatisation : définissez des seuils d’alerte clairs (p. ex. nombre de PGs dégradés, débit de récupération inférieur aux attentes, augmentation de la latence des OSD). Automatisez les vérifications préalables avant un remplacement et un script de rollback qui restaure toutes les valeurs de configuration précédemment sauvegardées. Exercez régulièrement la procédure dans un environnement de réplica — cela réduit les erreurs humaines en production.

Contrôle rapide avant intervention : vérifier la topologie CRUSH, tenir compte du type de pool, vérifier la capacité disponible, contrôler l’état du réseau, confirmer le mapping OSD→matériel dans la CMDB. Ces aspects d’architecture et d’exploitation réduisent sensiblement les temps de récupération et diminuent fortement le risque d’incohérences de données.

Pour ce sujet, le Ceph Backfill et le Ceph Rebalancing sont également importants. L’article situe ces aspects de manière compréhensible et montre ce qui importe au quotidien.