Erreurs courantes de Ceph et solutions : un guide pratique de terrain

Introduction

Ceph est un système de stockage distribué puissant, mais sa complexité peut engendrer des messages d'erreur énigmatiques qui frustrent même les administrateurs expérimentés. Ce guide se concentre sur des corrections pratiques et concrètes des erreurs Ceph les plus courantes : OSD marqués comme hors ligne, moniteurs incapables de former un quorum, problèmes de groupes de placement (PG) et soucis d'authentification. Vous apprendrez à diagnostiquer ces problèmes à l'aide des commandes Ceph standard, à appliquer des changements de configuration en toute sécurité, à vérifier la récupération et à revenir en arrière si nécessaire.

En suivant les exemples et les listes de vérification, vous pourrez réduire les temps d'arrêt et maintenir un cluster en bonne santé. Les conseils s'appuient sur des schémas de dépannage issus du monde réel, en privilégiant des interventions ciblées et mesurables que vous pouvez inspecter localement avant un déploiement plus large.

Un principe clé tout au long de ce guide : vérifiez toujours l'état actuel avant de modifier quoi que ce soit, appliquez les changements de manière limitée et réversible, et confirmez que le cluster revient à un état sain par la suite. Chaque section inclut des commandes concrètes avec des exemples de sortie afin que vous puissiez les comparer à votre propre cluster.

Inventaire de la version et de l'environnement

Avant de dépanner une erreur, rassemblez les informations essentielles sur votre cluster Ceph. Cela garantit que les correctifs sont compatibles et que vous comprenez la topologie. Se précipiter sur une correction sans connaître la base aggrave souvent les problèmes.

Tout d'abord, vérifiez la version de Ceph sur tous les nœuds :

ceph --version

Exemple de sortie attendue :

ceph version 17.2.6 (d7ff0d10654d2280e08f1ab989c7cdf3064446a5) quincy (stable)

Notez les versions des démons MON, OSD et MDS sur chaque hôte. Mélanger des versions majeures peut provoquer un comportement inattendu ; lors d'une mise à niveau, certains démons peuvent exécuter une version différente de manière transitoire, mais un décalage de version à long terme doit être évité. Si vous constatez des différences de version, notez-les et consultez la documentation de mise à niveau de Ceph pour votre version avant d'apporter d'autres modifications.

Ensuite, vérifiez l'état et le statut du cluster :

ceph status

Recherchez la ligne de résumé de l'état, qui peut être HEALTH_OK, HEALTH_WARN ou HEALTH_ERR. La sortie inclut également le nombre de moniteurs, d'OSD et de groupes de placement, ainsi que les avertissements actifs. Voici un exemple de sortie saine :

  cluster:
    id:     a1b2c3d4-5678-90ab-cdef-1234567890ab
    health: HEALTH_OK

  services:
    mon: 3 daemons, quorum ceph-mon-1,ceph-mon-2,ceph-mon-3 (age 2h)
    mgr: ceph-mgr-1(active, since 2h), standbys: ceph-mgr-2
    osd: 12 osds: 12 up (since 2h), 12 in (since 3d)

  data:
    pools:   4 pools, 256 pgs
    objects: 1.23M objects, 4.5 TiB
    usage:   13 TiB used, 40 TiB / 53 TiB avail
    pgs:     256 active+clean

Si l'état n'est pas HEALTH_OK, la sortie de ceph status listera des avertissements ou erreurs spécifiques sous health: tels que OSD_DOWN, PG_DEGRADED ou MON_DOWN. Capturez ces détails avant de continuer.

Documentez la configuration réseau, y compris les réseaux public et de cluster. Assurez-vous que tous les nœuds peuvent résoudre les noms d'hôte et se joindre sur les ports requis : 6789 pour les moniteurs, 6800-7300 pour les OSD (selon la configuration). Utilisez ping et nc -zv <hôte> <port> ou telnet <hôte> <port> pour tester la connectivité.

Enfin, confirmez que l'authentification est correctement configurée et que vous disposez du trousseau de clés d'administration nécessaire. Testez votre accès avec :

ceph -s

Si cela échoue avec un message comme [errno 13] RADOS permission denied ou Error connecting to cluster: PermissionDeniedError, vous avez peut-être un problème de configuration ou de trousseau de clés avant tout souci spécifique au démon. Vérifiez que /etc/ceph/ceph.client.admin.keyring existe et contient une clé valide, et que ceph.conf pointe vers les bons moniteurs.

Chemin de configuration sécurisé

Lors de l'application de modifications de configuration, utilisez toujours la base de données de configuration Ceph (ceph config) et effectuez des changements limités. Évitez de modifier directement ceph.conf sur des nœuds individuels, car cela peut entraîner des incohérences entre les hôtes et rendre le retour en arrière plus difficile. La base de données de configuration stocke les réglages de manière centralisée et les applique automatiquement aux démons.

Un flux de travail sûr pour tout changement de configuration :

1. Identifiez le réglage exact et sa valeur actuelle.
2. Testez le changement sur un ensemble limité de démons (par exemple, un OSD ou un moniteur) à l'aide d'une dérogation spécifique au démon.
3. Observez l'effet pendant un certain temps (minutes à heures) tout en surveillant l'état du cluster.
4. Si le changement est bénéfique, élargissez la portée à tous les démons concernés.
5. Si le changement cause des problèmes, supprimez la dérogation pour revenir à l'état précédent.

Exemple : Ajuster le délai de grâce du battement de cœur des OSD pour tenir compte des retards réseau transitoires.

Le paramètre osd_heartbeat_grace contrôle combien de temps un OSD attend avant de déclarer un OSD pair hors ligne. La valeur par défaut est de 20 secondes. Si vous avez des coupures réseau fréquentes (par exemple, des pertes de paquets sur un commutateur encombré), vous pourriez voir des OSD osciller entre en ligne et hors ligne. Augmenter temporairement cette valeur peut stabiliser le cluster pendant que vous réparez le réseau.

Étape par étape avec les commandes :

# Voir la valeur actuelle de osd_heartbeat_grace pour tous les OSD
ceph config get osd osd_heartbeat_grace

Sortie attendue :

20

# Définir une dérogation temporaire pour un OSD spécifique (osd.3)
ceph config set osd.3 osd_heartbeat_grace 30

# Vérifier le réglage pour cet OSD
ceph config get osd.3 osd_heartbeat_grace

Sortie attendue :

30

Surveillez maintenant l'état du cluster et le comportement de l'OSD pendant quelques minutes. Si l'oscillation cesse et qu'aucun autre problème n'apparaît, vous pouvez décider d'appliquer le réglage à tous les OSD :

ceph config set osd osd_heartbeat_grace 30

Pour supprimer entièrement la dérogation et revenir à la valeur par défaut compilée ou centrale :

ceph config rm osd osd_heartbeat_grace

Pour les dérogations spécifiques au démon, la syntaxe est ceph config set <type_démon>.<id_démon> <clé> <valeur>. Par exemple, ceph config set mds.ceph-mds-1 mds_cache_memory_limit 4294967296 définit la limite de mémoire cache du MDS à 4 Gio pour un seul MDS.

Testez toujours sur un sous-ensemble de démons si possible. Une mauvaise valeur de configuration peut faire planter les démons ou se comporter de manière imprévisible, donc un déploiement limité est essentiel.

Vérification et diagnostics

Un diagnostic efficace repose sur l'observation de l'état du cluster et l'interprétation des journaux. Les commandes suivantes sont vos principaux outils. Exécutez-les lorsque le cluster est sain pour établir une base de référence, puis à nouveau lors du dépannage pour repérer les différences.

1. Vérifier l'état global du cluster

ceph status

Interprétez la sortie comme décrit dans la section d'inventaire. Prêtez attention au bloc health: pour les codes d'erreur spécifiques.

2. Inspecter l'état des OSD

ceph osd tree

Cela affiche une arborescence des hôtes et des OSD avec leur état, leur poids et leur emplacement. Exemple de sortie :

ID  CLASS  WEIGHT   TYPE NAME        STATUS  REWEIGHT  PRI-AFF
-1         0.09799  root default
-3         0.03299      host ceph-osd-1
 0    ssd  0.01100          osd.0        up   1.00000  1.00000
 1    ssd  0.01100          osd.1        up   1.00000  1.00000
 2    ssd  0.01099          osd.2      down   1.00000  1.00000
-5         0.03299      host ceph-osd-2
 3    ssd  0.01100          osd.3        up   1.00000  1.00000
 4    ssd  0.01100          osd.4        up   1.00000  1.00000
 5    ssd  0.01099          osd.5        up   1.00000  1.00000

Recherchez les OSD avec l'état down ou out. Un OSD qui est up mais out a été marqué manuellement hors du cluster et ne recevra pas de données tant qu'il n'est pas marqué in.

3. Examiner les états des groupes de placement

ceph pg dump_stuck

Cela montre les PG bloqués dans des états comme stale, inactive, undersized ou degraded. Par défaut, il liste les PG bloqués depuis 60 secondes ou plus ; vous pouvez ajuster avec --threshold.

Pour obtenir un résumé des états des PG :

ceph pg stat

Exemple de sortie :

256 pgs: 256 active+clean; 12 TiB data, 40 TiB used, 53 TiB / 93 TiB avail

Si vous voyez des PG en inactive, undersized ou degraded, recherchez quels OSD sont manquants ou hors ligne à l'aide de ceph pg <pgid> query.

4. Voir les événements récents du journal du cluster

ceph log last 100

Cela affiche les 100 derniers événements du journal du cluster. Recherchez les messages d'erreur pertinents tels que osd.X failed, mon.X is down ou auth: unable to find a keyring.

5. Localiser un OSD spécifique

ceph osd find <osd-id>

Exemple :

ceph osd find 0

La sortie indique l'hôte, l'emplacement CRUSH et l'adresse IP de l'OSD.

6. Interroger le quorum des moniteurs

ceph quorum_status

Cela renvoie un JSON avec la liste des moniteurs et leur état de quorum. La sortie attendue inclut tous les moniteurs dans le tableau quorum. Exemple :

{
  "election_epoch": 42,
  "quorum": [0, 1, 2],
  "quorum_names": ["ceph-mon-1", "ceph-mon-2", "ceph-mon-3"],
  "quorum_leader_name": "ceph-mon-1",
  "monmap": {
    "epoch": 3,
    "mons": [
      {"name": "ceph-mon-1", "rank": 0, "addr": "10.0.0.11:6789/0"},
      {"name": "ceph-mon-2", "rank": 1, "addr": "10.0.0.12:6789/0"},
      {"name": "ceph-mon-3", "rank": 2, "addr": "10.0.0.13:6789/0"}
    ]
  }
}

Si un moniteur est absent du tableau quorum, examinez la connectivité réseau de ce moniteur et l'état du service.

Pour une analyse plus approfondie, examinez les journaux des démons dans /var/log/ceph/. Chaque démon enregistre dans un fichier nommé ceph-<type_démon>-<id>.log (par exemple, ceph-osd.0.log). Utilisez journalctl -u ceph-osd@0 sur les systèmes avec systemd pour voir les journaux de service récents. Vous pouvez également interroger directement un démon en cours d'exécution avec ceph daemon <nom_démon> status, mais cette interface de socket locale est dépréciée dans les versions plus récentes au profit de la commande ceph tell, par exemple ceph tell osd.0 version.

Modes de défaillance et récupération

Lorsque les choses tournent mal, disposer d'un plan de récupération clair est crucial. Cette section couvre les quatre modes de défaillance les plus courants : OSD hors ligne/sorti, perte de quorum des moniteurs, groupes de placement inactifs et erreurs d'authentification. Pour chacun, vous trouverez des étapes de diagnostic, des commandes de récupération concrètes et des vérifications.

OSD hors ligne ou sorti

Un OSD peut être marqué down si le moniteur ne peut pas l'atteindre pendant la période de grâce du battement de cœur. Cela peut se produire en raison de problèmes réseau, d'un plantage ou d'une latence de disque élevée qui fait manquer les battements de cœur à l'OSD.

Diagnostic :

ceph osd tree

Recherchez l'état down. Vérifiez les journaux de l'OSD pour les raisons du plantage :

journalctl -u ceph-osd@<id> | tail -50

Testez également la connectivité réseau du moniteur vers l'hôte OSD sur les ports 6800-7300.

Récupération :

Tout d'abord, essayez de redémarrer le service OSD :

systemctl restart ceph-osd@<id>

Si l'OSD revient en ligne, le cluster commencera à se rétablir. Surveillez avec ceph -w (mode veille) jusqu'à ce que l'état redevienne OK.

Si le nœud est injoignable et ne peut pas être remis en ligne rapidement, marquez l'OSD out manuellement pour permettre la réplication des données :

ceph osd out <osd-id>

Cela indique à CRUSH de redistribuer les données qui étaient sur cet OSD vers d'autres OSD. Une fois l'OSD de nouveau en ligne et sain, ramenez-le in :

ceph osd in <osd-id>

Après qu'un OSD est marqué out puis in, les données se rééquilibreront. Cela peut prendre beaucoup de temps selon la quantité de données ; suivez la progression avec ceph status et ceph pg stat.

Vérification :

• ceph osd tree montre l'OSD up et in.
• ceph status ne montre aucun avertissement OSD_DOWN.
• ceph pg stat montre les PG revenant à active+clean.

Perte de quorum des moniteurs

Les moniteurs Ceph utilisent l'algorithme Paxos pour maintenir une carte de cluster cohérente. Si moins de la moitié des moniteurs sont joignables, le quorum est perdu et le cluster cesse de répondre aux changements (bien que les E/S existantes puissent continuer si les OSD ont des cartes à jour).

Diagnostic :

ceph quorum_status

Si cette commande se bloque ou renvoie une erreur, les moniteurs ne sont pas en quorum. Vérifiez l'état de chaque moniteur :

systemctl status ceph-mon@<hostname>

Vérifiez la connectivité réseau entre les moniteurs (port 6789) et examinez les journaux des moniteurs :

journalctl -u ceph-mon@<hostname> | tail -100

Causes courantes : partition réseau, mauvaise configuration du pare-feu, décalage d'horloge entre les moniteurs (plus de 0,05 seconde peut causer des problèmes) ou disque plein sur un moniteur.

Récupération :

1. Corrigez la cause sous-jacente : rétablissez le réseau, corrigez la synchronisation de l'heure (utilisez NTP), libérez de l'espace disque.
2. Si un seul moniteur a échoué et ne peut pas être récupéré rapidement, vous pouvez le retirer de la monmap et continuer temporairement avec un nombre pair de moniteurs, mais un nombre impair est requis pour un quorum stable. Il est préférable d'ajouter un nouveau moniteur pour remplacer celui qui a échoué.
3. En dernier recours, si tous les moniteurs ont perdu des données ou si la monmap est corrompue, vous pouvez récupérer le magasin de moniteurs à partir d'une sauvegarde en utilisant ceph-monstore-tool :

ceph-monstore-tool /var/lib/ceph/mon/ceph-<hostname> rebuild

Cela reconstruit le magasin de moniteurs à partir des OSD ; c'est une procédure complexe qui doit être effectuée avec soin et de préférence avec le support du fournisseur ou de la communauté.

Vérification :

• ceph quorum_status montre tous les moniteurs attendus en quorum.
• ceph status montre HEALTH_OK ou seulement des avertissements.

Groupes de placement inactifs

Les groupes de placement (PG) sont les unités internes de distribution des données. Ils résident normalement dans l'état active+clean. Si un PG est inactive, il ne peut pas servir les E/S pour les objets qu'il contient.

Diagnostic :

ceph pg dump_stuck inactive

Puis explorez un PG bloqué spécifique :

ceph pg <pgid> query

Cela renvoie un JSON avec des détails sur l'état de peering du PG, l'ensemble agissant et les erreurs éventuelles. Recherchez "state": "inactive" et les champs "peering_blocked_by" qui indiquent ce qui empêche le peering.

Causes courantes :

• Pas assez d'OSD de l'ensemble agissant du PG sont up et in.
• Le PG manque d'un journal ou d'un objet requis en raison de la perte d'OSD.
• Une erreur de configuration dans les règles CRUSH entraîne trop peu d'OSD.

Récupération :

1. Assurez-vous que les OSD requis sont up et in. Utilisez ceph osd tree et ceph osd in <id> si nécessaire.
2. Si des OSD étaient hors ligne et sont maintenant de retour, les PG peuvent se peer automatiquement. Vérifiez avec ceph pg stat après quelques minutes.
3. Si le PG reste inactif parce qu'il croit que des données sont perdues, vous pouvez le forcer à accepter l'état actuel et tenter de se peer. Cela ne doit être fait qu'après s'être assuré que les données ne sont pas réellement perdues, car cela peut causer une incohérence des données. Utilisez :

ceph pg force_create_pg <pgid>

Cette commande indique au moniteur de créer le PG s'il n'existe pas, ce qui peut relancer le peering. Pour les cas plus graves, vous pouvez avoir besoin d'utiliser ceph osd force-create-pg ou ceph pg mark_unfound_lost revert|delete, mais ces commandes sont avancées et potentiellement destructrices ; consultez la documentation et la communauté avant de les utiliser.

Vérification :

• ceph pg dump_stuck inactive ne renvoie aucun PG.
• ceph pg stat montre tous les PG active+clean finalement.

Erreurs d'authentification

Les clients peuvent ne pas se connecter au cluster avec des erreurs comme error connecting to the cluster ou bad auth. Cela indique généralement des trousseaux de clés manquants ou incorrects, ou des capacités insuffisantes.

Diagnostic :

Testez l'accès client :

ceph -s --id <nom-client>

Si vous voyez [errno 13] RADOS permission denied, le trousseau de clés ou les capacités du client sont erronés. Vérifiez le fichier de trousseau de clés du client (généralement /etc/ceph/ceph.client.<nom>.keyring) et vérifiez que la clé correspond à celle du cluster :

ceph auth get <nom-client>

Comparez la valeur de la clé avec celle du trousseau de clés du client.

Récupération :

1. Assurez-vous que le trousseau de clés du client existe et possède la bonne clé. S'il est manquant, recréez-le à partir du cluster :

ceph auth get-or-create client.<nom> mon 'allow r' osd 'allow rw pool=<nom-pool>' -o /etc/ceph/ceph.client.<nom>.keyring

1. Ajustez les capacités si nécessaire. Par exemple, pour accorder un accès en lecture seule à un pool spécifique :

ceph auth caps client.<nom> mon 'allow r' osd 'allow r pool=<nom-pool>'

1. Régénérez les clés si elles sont compromises :

ceph auth caps client.<nom> mon 'allow r' osd 'allow rw pool=<nom-pool>'
ceph auth get-or-create client.<nom>

Distribuez ensuite la nouvelle clé au client.

Vérification :

• Le client peut exécuter ceph -s --id <nom-client> sans erreur d'authentification.
• ceph auth list montre le client avec les capacités correctes.

Ayez toujours un plan de retour en arrière : documentez toutes les modifications, conservez des sauvegardes de la configuration et des trousseaux de clés, et testez les procédures de récupération dans un environnement non productif d'abord.

Liste de vérification des opérations

Utilisez cette liste de vérification pour les opérations de routine et lors du dépannage. Exécuter ces commandes régulièrement (par exemple, quotidiennement) vous aide à détecter les problèmes avant qu'ils ne s'aggravent.

Pour chaque problème trouvé, documentez le diagnostic et la correction. Testez toujours les changements de manière limitée avant de les appliquer à l'ensemble du cluster. Voici un exemple de vérification de l'utilisation du disque :

ceph df

Exemple de sortie :

--- RAW STORAGE ---
CLASS  SIZE     AVAIL    USED     RAW USED  %RAW USED
ssd    93 TiB   53 TiB   40 TiB    40 TiB      43.01
TOTAL  93 TiB   53 TiB   40 TiB    40 TiB      43.01

--- POOLS ---
POOL        ID  PGS   STORED   OBJECTS  USED     %USED  MAX AVAIL
rbd         1   64    8.5 TiB   2.1M    25 TiB   80.00    6.5 TiB
cephfs_data 2   64    1.2 TiB   300k     3.6 TiB  40.00    8.8 TiB

Si l'utilisation d'un OSD ou d'un pool dépasse 80-85%, prévoyez d'ajouter de la capacité ou de rééquilibrer pour éviter les avertissements OSD_NEARFULL ou OSD_FULL qui peuvent bloquer les écritures.

Conclusion

Vous avez appris des stratégies pratiques pour diagnostiquer et corriger les erreurs Ceph courantes. Commencez par rassembler un inventaire précis de l'environnement, puis appliquez les changements de configuration en toute sécurité à l'aide de la base de données de configuration Ceph avec des dérogations limitées. Vérifiez chaque correction avec des contrôles observables et ayez toujours un plan de retour en arrière. Utilisez la liste de vérification des opérations pour maintenir la santé du cluster et détecter les problèmes tôt.

Points clés à retenir :

• Connaissez votre base : Enregistrez les versions, l'état de santé et la topologie avant que les problèmes ne surviennent.
• Changez progressivement : Utilisez ceph config avec des dérogations spécifiques au démon et testez avant un déploiement large.
• Diagnostiquez systématiquement : Utilisez ceph status, ceph osd tree, ceph pg dump_stuck et ceph quorum_status pour localiser les problèmes.
• Récupérez en toute sécurité : Suivez les étapes de récupération spécifiques pour les défaillances d'OSD, de moniteur, de PG et d'authentification, et vérifiez toujours la récupération.
• Gardez une liste de vérification : Exécutez des contrôles de routine et documentez les changements pour un dépannage plus rapide.

Prochaines étapes : appliquez ce guide à un problème spécifique dans votre propre cluster, en commençant par les commandes de diagnostic. Pour une automatisation plus poussée, envisagez d'intégrer ces contrôles dans votre système de surveillance (par exemple, Prometheus avec l'exportateur Ceph) ou la gestion de configuration (par exemple, Ansible) pour renforcer la cohérence. N'oubliez pas de tester toute procédure de récupération non triviale dans un environnement de test d'abord.

Ceph est robuste mais impitoyable envers les actions précipitées. Avec l'approche disciplinée décrite ici, vous pouvez maintenir votre cluster en bon état de fonctionnement et récupérer rapidement en cas de problème.