Dépannage réseau Ceph : guide pratique avec exemples

La performance et la stabilité de Ceph reposent sur des chemins réseau rapides et fiables entre les moniteurs, gestionnaires, OSD, serveurs de métadonnées et clients. Lorsque le réseau faillit, les symptômes vont des opérations lentes et groupes de placement dégradés à la perte de quorum des moniteurs. Ce guide vous donne une méthode sûre et progressive pour diagnostiquer et corriger les problèmes de DNS, ports, routage, pare-feu et MTU avec des commandes concrètes et des résultats prévisibles.

Note sur la portée : Toutes les adresses IP, noms d'hôtes et sous-réseaux dans cet article sont des exemples construits pour l'illustration. Remplacez-les par les valeurs de votre environnement.

Introduction

Vous allez :

• Établir un inventaire propre des versions et de la topologie réseau.
• Valider le DNS et la résolution de noms sans risquer de mouvement de données.
• Confirmer que les ports requis sont ouverts et en écoute.
• Tester la connectivité et le MTU de bout en bout sur les réseaux public et cluster.
• Identifier les problèmes de routage et de pare-feu et les corriger proprement avec possibilités de retour arrière.
• Vérifier le succès avec des contrôles observables de santé Ceph et réseau.

Public visé : développeurs, consultants DevOps et équipes de startups qui exploitent ou soutiennent des clusters Ceph sur Linux (y compris sur des plateformes comme Proxmox) et qui ont besoin d'un flux de dépannage pratique et à faible risque.

Inventaire des versions et de l'environnement

Avant de modifier quoi que ce soit, capturez l'état actuel. Cela permet de comparer avant/après et de récupérer rapidement si nécessaire.

Prérequis :

• Accès shell à au moins un nœud moniteur et un nœud OSD avec sudo.
• Familiarité de base avec le CLI Ceph et les commandes réseau Linux.
• Une fenêtre de maintenance si vous prévoyez de modifier pare-feu, MTU ou routage.

Enregistrez ces éléments sur chaque nœud :

1. Versions Ceph et santé

   ceph -s
   ceph health detail
   ceph versions
   ceph mon dump -f json-pretty | jq '.mons[] | {name, public_addrs}'

Attendu :

• HEALTH_OK ou des messages WARN clairs que vous pouvez trier.
• Adresses des moniteurs qui correspondent à votre réseau public prévu.

1. Identité d'hôte et DNS

   hostname -f
   hostname -I
   getent hosts $(hostname -f)
   getent ahosts $(hostname -f)

Attendu :

• Le FQDN se résout vers l'IPv4/IPv6 correcte utilisée par Ceph.

1. Interfaces, IPs et MTU

   ip -br a
   ip -br link
   ethtool -k eth0 | grep -E 'tso|gso|gro'

Attendu :

• Adresses correctes sur les réseaux public et (si utilisé) cluster.
• Valeurs MTU cohérentes entre nœuds pairs.

1. Routage

   ip route
   ip rule
   sysctl net.ipv4.conf.all.rp_filter
   sysctl net.ipv4.ip_forward

Attendu :

• Routes déterministes vers les sous-réseaux pairs ; rp_filter=1 peut supprimer les chemins de retour asymétriques.

Utilisez l'outil géré par votre distribution :

1. Pare-feu

   # firewalld
   sudo firewall-cmd --state || true
   sudo firewall-cmd --list-all || true

   # ufw
   sudo ufw status verbose || true

   # nftables
   sudo nft list ruleset || true

Attendu :

• Autorisations explicites pour les ports Ceph entre nœuds du cluster.

1. Synchronisation horaire (affecte les symptômes réseau comme les timeouts)

   timedatectl
   chronyc sources -v || true

Attendu :

• Horloges synchronisées sur tous les nœuds.

Ports des services Ceph (référence)

Utilisez ce tableau pour confirmer les sockets en écoute et les autorisations pare-feu. Ajustez selon vos spécificités de déploiement.

Chemin de configuration sûr

Gardez la première itération étroite, mesurable et facile à inspecter localement avant déploiement. L'objectif est d'isoler les couches réseau sans déclencher de mouvements de données inutiles.

Si vous attendez de brefs flaps d'OSD pendant les tests, posez une garde et rappelez-vous de la retirer :

1. Geler les mouvements de données indésirables (temporaire)

   ceph osd set noout
   # Optionnel si vous attendez de gros changements de lien ; utilisez avec parcimonie
   # ceph osd set norecover
   # ceph osd set nobackfill

Vérification :

   ceph osd dump | grep flags

Retour arrière :

   ceph osd unset noout
   # ceph osd unset norecover
   # ceph osd unset nobackfill

1. Sauvegarder les configs localement

   sudo cp -a /etc/ceph/ceph.conf /etc/ceph/ceph.conf.bak-$(date -Iseconds)
   sudo cp -a /etc/sysctl.conf /etc/sysctl.conf.bak-$(date -Iseconds) || true

1. Limiter les changements

• Testez la reachabilité DNS et ports d'abord. Aucun redémarrage de service requis.
• Changez une variable à la fois (ex. MTU), vérifiez, puis continuez.
• Préférez les autorisations pare-feu additives aux basculements de politique larges.

1. Planifier un retour arrière rapide

• Gardez des notes terminal de chaque commande exécutée.
• Pour les réglages réseau, connaissez le MTU/passerelle précédent et comment revenir.
• Testez sur un seul nœud OSD non critique avant changements cluster-wide.

Vérification et diagnostics

Cette section fournit des contrôles concrets, sorties attendues et interprétation des échecs.

DNS et résolution de noms

Une résolution d'hôtes cohérente évite les mauvaises routes subtiles, surtout sur clusters dual-stack.

1. Résoudre le FQDN vers enregistrements A/AAAA

   dig +short A mon1.ceph.example.com
   dig +short AAAA mon1.ceph.example.com

Attendu :

• IPs correspondant à ce que ceph mon dump montre pour le moniteur.

1. DNS inverse (optionnel mais utile)

   dig +short -x 10.10.10.11

Attendu :

• Retourne le FQDN que vous utilisez de façon cohérente dans les configs.

1. Chemin systemd-resolved ou nswitch

   resolvectl dns
   resolvectl query mon1.ceph.example.com
   getent hosts mon1.ceph.example.com

Attendu :

• Même chemin de réponse sur tous les nœuds. Si les nœuds divergent, alignez résolveurs ou ordre /etc/nsswitch.conf.

Corrections :

• Standardisez /etc/hosts uniquement pour tests d'urgence ; ne laissez pas d'entrées host-only permanentes divergent du DNS.
• Assurez-vous que les domaines de recherche ne causent pas de collisions accidentelles de noms courts.

Écoute des ports et reachabilité

1. Confirmer les listeners sur chaque nœud

   ss -ltnp | grep -E ':(3300|6789|68[0-9]{2,3}|7480)'

Attendu :

• MONs en écoute sur 3300 (et éventuellement 6789).
• OSD/MGR/MDS en écoute dans la plage 6800-7300.

1. Tester depuis les nœuds pairs

   # Depuis mon2 vers mon1
   nc -vz mon1.ceph.example.com 3300
   nc -vz mon1.ceph.example.com 6789 || true

   # Depuis osd3 vers osd5 (port exemple construit)
   nc -vz osd5.ceph.example.com 6802

Attendu :

• Messages "Connection succeeded\). Timeouts ou refus indiquent problèmes pare-feu ou listener.

1. Validation pare-feu

• Exemple firewalld (autoriser sur zone trusted) :

     sudo firewall-cmd --zone=trusted --add-port=3300/tcp --permanent
     sudo firewall-cmd --zone=trusted --add-port=6789/tcp --permanent
     sudo firewall-cmd --zone=trusted --add-port=6800-7300/tcp --permanent
     sudo firewall-cmd --reload

• Exemple ufw :

     sudo ufw allow 3300/tcp comment 'Ceph MON v2'
     sudo ufw allow 6789/tcp comment 'Ceph MON v1'
     sudo ufw allow 6800:7300/tcp comment 'Ceph OSD/MGR/MDS'

Vérification :

   sudo nft list ruleset | grep -E '3300|6789|6800'

Routage et chemins asymétriques

• Tracer le chemin

  # IPv4
  mtr -wrc 10 mon1.ceph.example.com
  # IPv6
  mtr -wrc 10 -6 mon1.ceph.example.com

Attendu :

• Chemin stable avec faible perte. Chemins aller/retour très différents peuvent déclencher des drops rp_filter.

• Vérifier le filtrage de chemin inverse

  sysctl net.ipv4.conf.all.rp_filter
  sysctl net.ipv4.conf.default.rp_filter

Interprétation :

• Valeur 1 (strict) peut supprimer les réponses routées asymétriquement. Si vous routez intentionnellement en asymétrique sur réseaux de stockage, envisagez 2 (lâche) pour l'interface spécifique :

    echo 'net.ipv4.conf.eth1.rp_filter=2' | sudo tee /etc/sysctl.d/60-ceph-rpfilter.conf
    sudo sysctl --system

Retour arrière :

  sudo rm /etc/sysctl.d/60-ceph-rpfilter.conf
  sudo sysctl -w net.ipv4.conf.eth1.rp_filter=1

MTU et fragmentation

Un désaccord MTU peut bloquer les heartbeats OSD et opérations clients.

1. Vérifier le MTU sur les pairs

   ip -br link | awk '{print $1, $3}'

1. Sonner le MTU de chemin (exemple IPv4 pour MTU 9000)

   ping -c 3 -M do -s 8972 osd5.ceph.example.com

Attendu :

Note : 8972 = 9000 MTU moins 28 octets pour en-têtes IP/ICMP.

• Pas de fragmentation requise. Si échec, alignez MTU sur tout le chemin ou utilisez 1500 standard.

Symptômes de santé Ceph indiquant le réseau

Exécutez sur un nœud moniteur :

ceph -s
ceph health detail
ceph osd tree

Messages couramment liés au réseau :

• OSD_DOWN ou OSD_TIMEOUT : souvent lien, MTU, pare-feu ou route.
• MON_DOWN ou tempêtes d'élection : reachabilité port moniteur, sync horaire, DNS.
• SLOW_OPS ou PGs dégradés avec beaucoup de remappés : perte de paquets intermittente.

Inspection au niveau paquet (dernier recours pendant une fenêtre)

Utilisez uniquement quand vous ne pouvez isoler le problème avec les étapes précédentes.

sudo tcpdump -ni eth1 tcp port 3300 or tcp port 6789 or portrange 6800-7300

Attendu :

• SYN/SYN-ACK complet. SYN répétés sans SYN-ACK indiquent filtrage ou pas de listener.

Modes de défaillance et récupération

Utilisez ce mapping pour aller du symptôme à la correction rapidement.

Recettes de récupération

1. Corriger le DNS proprement

• Corrigez enregistrements A/AAAA ou entrées host sur un nœud de test isolé d'abord.
• Vérifiez avec dig et resolvectl sur tous les nœuds.
• Aucun redémarrage daemon n'est nécessaire si le monmap utilise des IPs. Si vous avez changé noms ou adresses moniteurs dans clusters configuration-only, planifiez un redémarrage contrôlé des moniteurs un par un.

1. Rouvrir les ports

• Appliquez règles pare-feu ciblées comme montré plus haut.
• Vérifiez avec nc -vz depuis tous les pairs.
• Persistez règles et documentez.

1. Aligner le MTU

• Si jumbo MTU, assurez-vous que switches et NICs correspondent. Sinon, mettez toutes interfaces stockage à 1500 pour cohérence de base :

     sudo ip link set dev eth1 mtu 1500

• Rendez persistant via votre outil config réseau de distribution.
• Vérifiez avec ping -M do -s 1472.

1. Corriger le routage

• Ajoutez route explicite pour sous-réseau cluster si trafic prenait passerelle par défaut :

     sudo ip route add 10.20.0.0/24 dev eth1 proto static

• Pour routage par politique avec interfaces multiples, assurez chemins retour symétriques avec ip rule et tables par interface.
• Si rp_filter bloquait trafic, mettez mode lâche sur interface stockage seulement et documentez.

1. Plan de retour arrière

• Si un changement dégrade la santé, revenez immédiatement sur la dernière étape : restaurez MTU/passerelle précédent, retirez dernière règle pare-feu, ou supprimez le drop-in sysctl de test et rechargez.
• Confirmez avec ceph -s et tests de reachabilité ciblés.

Liste de contrôle opérations

Utilisez pendant incidents ou validation post-changement.

1. Ligne de base

• [ ] ceph -s accessible et rapporte messages santé.
• [ ] ceph mon dump montre adresses attendues.
• [ ] Temps synchronisé (timedatectl).

1. DNS

• [ ] dig A/AAAA hôte retourne IPs intentionnées.
• [ ] getent hosts cohérent sur tous nœuds.
• [ ] Aucune entrée /etc/hosts obsolète laissée derrière.

1. Ports et listeners

• [ ] ss -ltnp montre MON sur 3300 (et optionnellement 6789).
• [ ] OSD/MGR/MDS écoutent dans 6800-7300.
• [ ] nc -vz réussit entre pairs sur ports requis.

1. Pare-feu

• [ ] Règles autorisent 3300, 6789, 6800-7300 entre nœuds cluster.
• [ ] Règles persistées et documentées.

1. Routage et MTU

• [ ] mtr montre chemins stables, symétriques.
• [ ] rp_filter approprié pour votre routage.
• [ ] MTU aligné bout en bout ; ping -M do passe.

1. Vérification Ceph

• [ ] Aucun nouveau flap OSD pendant et après changements.
• [ ] ceph health detail libre d'avertissements réseau.
• [ ] Si utilisées, retirez garde-fous : ceph osd unset noout (et autres).

Exemples pratiques

Ces exemples bout en bout montrent comment appliquer les étapes. Toutes valeurs sont des exemples construits.

Exemple 1 : Quorum MON perdu après changement DNS

Symptômes : ceph -s depuis nœud survivant montre 1/3 mons dans quorum ; autres oscillent.

Étapes :

1. Vérifier résolution :

   dig +short A mon2.ceph.example.com
   getent hosts mon2.ceph.example.com

Observé : mon2 résout maintenant vers 10.10.20.15, mais monmap montre 10.10.10.15.

1. Corriger enregistrement DNS vers 10.10.10.15. Purger caches (resolvectl flush-caches si applicable).

1. Vérifier reachabilité :

   nc -vz mon2.ceph.example.com 3300

1. Confirmer récupération quorum :

   ceph -s

Attendu : Tous moniteurs rejoignent quorum ; santé s'améliore.

Retour arrière : Si propagation DNS retardée, utilisez entrée /etc/hosts temporaire sur nœuds affectés, puis retirez-la une fois DNS corrigé.

Exemple 2 : Flaps OSD dus à mismatch MTU

Symptômes : Événements répétés OSD_DOWN/UP et ops lentes ; switches ont récemment activé jumbo frames.

Étapes :

1. Vérifier MTU sur pairs :

   ip -br link | grep eth1

Observé : Certains nœuds à 9000, autres à 1500.

1. Choisir base sûre (1500) pour restaurer stabilité :

   sudo ip link set dev eth1 mtu 1500

1. Vérifier bout en bout avec ping -M do -s 1472 osdX.

1. Confirmer stabilité :

   ceph -s
   ceph health detail

Attendu : OSD arrêtent de flapper ; santé se stabilise.

Retour arrière : Si performance régresse plus tard, réintroduisez jumbo MTU seulement après validation que chaque saut le supporte et mise à jour cohérente de tous nœuds.

Exemple 3 : Routage asymétrique casse heartbeats OSD

Symptômes : OSD sur sous-réseau 10.20.0.0/24 timeout intermittent ; trafic retour prend passerelle par défaut sur certains nœuds.

Étapes :

1. Confirmer asymétrie chemin :

   mtr -wrc 10 osd8.ceph.example.com
   mtr -wrc 10 osd3.ceph.example.com

1. Ajouter route explicite sur nœuds affectés :

   sudo ip route add 10.20.0.0/24 dev eth1 proto static

1. Si encore drops, mettre rp_filter lâche interface-spécifique :

   echo 'net.ipv4.conf.eth1.rp_filter=2' | sudo tee /etc/sysctl.d/60-ceph-rpfilter.conf
   sudo sysctl --system

1. Vérifier avec mtr à nouveau et surveiller santé Ceph.

Retour arrière : Retirez la route ou le drop-in sysctl s'il introduit flux inattendus.

Conclusion

Un réseau Ceph fiable vient d'un inventaire discipliné, de tests ciblés et de petits changements réversibles. Commencez par confirmer DNS et ports requis, puis vérifiez symétrie routage et alignement MTU. Utilisez règles pare-feu ciblées et changements sysctl par interface plutôt que basculements de politique larges. Après chaque changement, validez avec nc -vz, mtr, ping -M do et ceph -s. Si une étape dégrade la santé, annulez-la immédiatement et réévaluez la dernière variable changée.

En suivant l'inventaire, diagnostics et étapes de récupération ici, vous pouvez restaurer le quorum moniteur, arrêter le flapping OSD et éliminer les ops lentes causées par le réseau avec confiance. Gardez la liste de contrôle opérations à portée de main, et standardisez ces vérifications dans votre maintenance de routine pour que les futurs incidents se résolvent plus vite et plus sûrement.