Liste de contrôle des opérations de production Ceph avec exemples pratiques

Introduction

Une liste de contrôle des opérations de production Ceph aide les opérateurs à passer d’un problème observé à un résultat vérifié. Ce guide se concentre sur des étapes pratiques et reproductibles pour les développeurs, consultants DevOps et équipes techniques de startups qui gèrent des clusters Ceph. Il relie les opérations, les listes de contrôle, les meilleures pratiques et la maintenance avec des commandes concrètes, des sorties attendues, des signaux d’échec et des décisions de reprise.

L’objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d’impact, utiliser des espaces réservés plutôt que des secrets, vérifier le résultat et documenter comment récupérer si l’état attendu n’est pas atteint. Chaque section ci-dessous suit le même schéma : identifier le composant concerné et la version prise en charge, capturer l’état en lecture seule, définir le plus petit changement justifié et vérifier le résultat. Les commandes utilisent des espaces réservés explicites comme <nom-du-pool> ou <id-osd> ; ne les exécutez jamais avec des valeurs de production réelles sans avoir d’abord compris l’impact.

Inventaire des versions et de l’environnement

Avant tout changement, sachez exactement ce que vous exécutez. Cela évite d’appliquer des conseils destinés à une autre version de Ceph ou à un autre modèle de déploiement. Capturez la version du cluster, l’outil de déploiement et l’état de santé avec des commandes en lecture seule.

Observer d’abord

Exécutez ces commandes depuis un nœud moniteur ou tout client disposant du bon trousseau de clés admin. Elles sont en lecture seule et sûres en production :

ceph --version
ceph -s
ceph versions

Exemple de sortie attendue :

ceph version 17.2.7 (b12291d110049b2f35e32e0de30d70e9a4a3f04c) quincy (stable)
  cluster:
    id:     12345678-1234-1234-1234-123456789abc
    health: HEALTH_OK

  services:
    mon: 3 daemons, quorum a,b,c (age 2h)
    mgr: 2 daemons, active c
    osd: 24 osds: 24 up (since 3d), 24 in (since 10d)

Identifiez également la méthode de déploiement :

ceph orch status   # si vous utilisez cephadm
systemctl status ceph-mon@<nom-d-hôte>   # si vous utilisez des paquets traditionnels

Définir les prérequis et les résultats attendus

Par exemple, si vous prévoyez de modifier la configuration d’un pool, listez le nom du pool, les paramètres actuels et les paramètres souhaités. Avant le changement, enregistrez l’état actuel avec un horodatage :

date -u +%Y-%m-%dT%H:%M:%SZ
ceph osd pool get <nom-du-pool> all

Considération spécifique à la version

Les versions de Ceph diffèrent dans la syntaxe des commandes et les valeurs par défaut. Par exemple, ceph osd pool set <nom-du-pool> pg_autoscale_mode on fonctionne dans Nautilus et les versions ultérieures, mais les versions plus anciennes nécessitent un calcul manuel des PG. Consultez toujours la documentation officielle correspondant à votre version exacte.

Rayon d’impact et récupération

Modifier un paramètre de pool affecte uniquement le placement et les performances de ce pool, mais peut avoir un impact sur tous les clients qui l’utilisent. Pour récupérer, revenez en arrière avec la même commande et la valeur d’origine. Par exemple, si vous avez modifié size de 3 à 4 et constaté une latence inattendue, rétablissez-le :

ceph osd pool set <nom-du-pool> size 3

Chemin de configuration sûr

Les changements de configuration sont une source courante d’incidents. Suivez un chemin contrôlé : observez, enregistrez, modifiez un élément, vérifiez et sachez comment revenir en arrière.

Exemple : ajuster la cible mémoire des OSD

Supposons que vous souhaitiez augmenter osd_memory_target de 4 Go à 8 Go pour réduire les vidages de cache des OSD. Étapes :

1. Vérifiez la valeur actuelle sur tous les OSD :

ceph config get osd osd_memory_target

Sortie attendue : 4294967296 (octets). Si la commande renvoie (unset), la valeur par défaut s’applique. Trouvez la valeur par défaut avec ceph config get osd osd_memory_target --format=json ou consultez la documentation.

1. Modifiez la valeur à l’échelle du cluster en utilisant la base de données de configuration centrale (Nautilus et versions ultérieures) :

ceph config set osd osd_memory_target 8589934592

1. Vérifiez le changement :

ceph config get osd osd_memory_target

Sortie attendue : 8589934592.

1. Surveillez pendant quelques heures ; vérifiez l’utilisation de la mémoire des OSD :

ceph daemon osd.<id-osd> perf dump | jq '.mempool'

Rayon d’impact et retour en arrière

Ce changement affecte tous les OSD et peut augmenter la pression mémoire globale. Si les nœuds ont une RAM limitée, les OSD pourraient être tués par le tueur OOM. Retour en arrière :

ceph config set osd osd_memory_target 4294967296

Pour les versions plus anciennes utilisant ceph.conf, modifiez la section [osd] sur tous les nœuds OSD et redémarrez les OSD un par un, en vérifiant la santé entre les redémarrages.

Utiliser des espaces réservés explicites

Ne mettez jamais de vrais noms d’hôtes, adresses IP ou chemins de trousseaux dans la documentation. Utilisez <hôte-mon>, <trousseau-admin> ou <nom-du-service>.

Vérification et diagnostics

La vérification confirme qu’un changement a produit l’état attendu sans effets secondaires. Les diagnostics aident à localiser la cause lorsque les choses tournent mal.

Vérification de la santé du cluster

Après tout changement, commencez par la santé globale :

ceph -s

Recherchez HEALTH_OK. Sinon, notez l’avertissement ou l’erreur spécifique. Par exemple, si vous voyez HEALTH_WARN: 1 pools have many more objects per pg than average, examinez le nombre de PG du pool.

Diagnostics de performance

Utilisez ceph osd perf pour voir la latence et les temps de commit par OSD :

ceph osd perf

Exemple de sortie :

osd commit_latency(ms) apply_latency(ms)
0   2.5                3.1
1   5.2                4.8
...

Si un OSD présente une latence beaucoup plus élevée, vérifiez la santé de son disque :

smartctl -a /dev/sdX

Diagnostics d’état des PG

Lorsque les clients signalent des E/S lentes, examinez les groupes de placement :

ceph pg stat
ceph pg dump | grep -E 'active\+clean|down|peering|recovering'

Si certains PG restent bloqués en peering, identifiez les OSD actifs :

ceph pg <id-pg> query

Recherchez le "state": "peering" et vérifiez le statut up/out des OSD :

ceph osd tree

Script de vérification

Créez une ligne de commande pour vérifier la santé après la maintenance :

ceph -s | grep -q HEALTH_OK && echo "Cluster sain" || echo "Le cluster nécessite une attention"

Modes de défaillance et récupération

Planifiez les défaillances courantes et connaissez les étapes de récupération à l’avance. Cette section couvre la défaillance d’un disque, un OSD hors service, les problèmes de moniteur et les partitions réseau.

Défaillance d’un OSD ou d’un disque

Si un disque tombe en panne ou qu’un OSD plante :

1. Vérifiez le statut de l’OSD :

ceph osd tree

Un OSD hors service affiche down dans la colonne de statut.

1. Si l’OSD est hors service mais que le disque est sain, essayez de le redémarrer :

systemctl start ceph-osd@<id-osd>

1. Si le disque a définitivement échoué, supprimez l’OSD :

ceph osd out <id-osd>
ceph osd down <id-osd>
ceph osd rm <id-osd>
ceph osd crush remove osd.<id-osd>
ceph auth del osd.<id-osd>

Ensuite, remplacez physiquement le disque et ajoutez un nouvel OSD avec le même ID ou un nouveau.

Perte de quorum des moniteurs

Si vous perdez un moniteur, le cluster fonctionne toujours mais est dégradé. Si vous perdez le quorum (par exemple, 2 des 3 moniteurs hors service), le cluster cesse de servir les écritures. Étapes de récupération :

1. Vérifiez le statut des moniteurs :

ceph mon stat

1. Si un nœud moniteur est joignable, redémarrez le moniteur :

systemctl restart ceph-mon@<nom-d-hôte>

1. Si le démon moniteur ne peut pas démarrer en raison de données corrompues, supprimez-le et ré-ajoutez-le conformément à la documentation officielle, en vous assurant de ne pas casser davantage le quorum.

Partition réseau

Un split-brain peut amener les OSD à échouer les battements de cœur et à se marquer mutuellement hors service. Vérifiez la connectivité réseau entre les nœuds OSD :

ping -c 4 <hôte-osd>

Vérifiez les règles de pare-feu bloquant les ports 6800-7300 (plage OSD Ceph). Après restauration du réseau, les OSD devraient automatiquement rejoindre et commencer la récupération.

Exemple de remplacement avec espaces réservés

Supposons que l’OSD 5 sur l’hôte storage03 ait un disque défaillant. Le chemin de récupération :

• Marquez l’OSD 5 hors service et supprimez-le comme ci-dessus.
• Remplacez le disque /dev/sdb sur storage03.
• Amorcez le nouvel OSD :

ceph-volume lvm create --data /dev/sdb

• Vérifiez que le nouvel OSD démarre et est marqué in :

ceph osd tree | grep osd.5

Attendu : osd.5 up 1.00000 1.00000 sans drapeau down.

Liste de contrôle des opérations

Utilisez cette liste de contrôle avant toute fenêtre de maintenance ou tout changement. Chaque élément inclut la commande pour vérifier l’état actuel, l’action, le résultat attendu et le responsable (pour les équipes). Le responsable est la seule personne imputable qui doit vérifier l’action ; elle doit revoir la liste de contrôle trimestriellement pour s’assurer qu’elle correspond à la version et à la topologie actuelles du cluster.

Pour chaque élément, définissez le signal d’échec et l’étape de récupération. Par exemple, si la capacité libre dépasse 70 % d’utilisation brute, ajoutez des OSD ou supprimez des données inutiles ; si les PG sont bloqués, examinez avec ceph pg <id-pg> query et redémarrez ou rééquilibrez les OSD selon les besoins.

Pièges courants et comment les éviter

Même les opérateurs expérimentés font des erreurs. Voici les plus fréquentes et comment s’en remettre.

Piège 1 : Modifier plusieurs paramètres à la fois

Pourquoi cela arrive : La pression du temps ou la croyance que les changements sont indépendants.

Comment l’éviter : Modifiez un paramètre, vérifiez la santé et les performances, puis continuez. Utilisez une fenêtre de maintenance et enregistrez chaque changement dans un journal.

Récupération : Revenez à la configuration précédente avec ceph config set ou ceph osd pool set en utilisant les valeurs enregistrées.

Piège 2 : Ignorer les avertissements de santé du cluster

Pourquoi cela arrive : Le cluster semble fonctionner malgré les avertissements, donc les équipes reportent leur correction.

Comment l’éviter : Traitez chaque HEALTH_WARN comme actionnable. Planifiez du temps pour résoudre les avertissements ; certains sont des précurseurs de perte de données (par exemple, PG_DEGRADED).

Récupération : Traitez les avertissements un par un. Par exemple, si vous voyez OSD_DOWN, ramenez l’OSD ou supprimez-le s’il est définitivement en panne.

Piège 3 : Ne pas tester les procédures de récupération

Pourquoi cela arrive : La récupération n’est nécessaire qu’en cas d’urgence, donc les équipes sautent les exercices.

Comment l’éviter : Testez le retrait et la ré-ajout d’OSD sur un cluster de préproduction ou un pool non productif. Documentez les étapes exactes.

Récupération : Si une récupération non testée échoue en production, suivez le guide officiel de reprise après sinistre, qui implique souvent des étapes manuelles comme la modification des cartes CRUSH ou l’utilisation de ceph-objectstore-tool.

Piège 4 : Utiliser des nombres de PG incorrects

Pourquoi cela arrive : L’autoscaling est désactivé ou les pools sont définis manuellement sans calcul.

Comment l’éviter : Activez l’autoscaling des PG pour les nouveaux pools (ceph osd pool set <nom-du-pool> pg_autoscale_mode on). Pour les pools existants, surveillez avec ceph osd pool autoscale-status et ajustez manuellement si nécessaire.

Récupération : Si un pool a trop peu de PG, augmentez progressivement pour éviter un impact sur les performances ; s’il en a trop, diminuez après avoir assuré la distribution des données.

Piège 5 : Exécuter des commandes en tant que root sans comprendre

Pourquoi cela arrive : Copier-coller à partir de tutoriels sans vérifier l’effet de la commande.

Comment l’éviter : Lisez toujours la documentation de la commande et vérifiez sa portée. Utilisez les options --dry-run lorsqu’elles sont disponibles. Testez d’abord sur une ressource non critique.

Récupération : Si une commande endommage le cluster, arrêtez tous les changements et consultez immédiatement la communauté Ceph ou le support du fournisseur.

Conclusion

Une liste de contrôle des opérations de production Ceph n’est utile que si chaque recommandation est limitée à la version, observable et réversible lorsque la technologie le permet. Copier une commande sans vérifier les prérequis et la sortie attendue n’est pas une procédure d’exploitation.

Comme prochaine étape, choisissez une vérification à faible risque dans la liste de contrôle, enregistrez l’état actuel, exécutez la vérification documentée, comparez le résultat avec le signal attendu et examinez les dépendances telles que Proxmox, Linux et les clusters de stockage. Par exemple, commencez par ceph -s et assurez-vous que le cluster est sain avant d’approfondir.

Un flux de travail technique fiable rend les défaillances visibles, protège les valeurs sensibles, limite les changements à la ressource prévue et définit la vérification de la récupération avant qu’un incident ne force la décision. Mettez en œuvre ces pratiques progressivement : commencez par l’inventaire des versions et de l’environnement, puis adoptez des chemins de configuration sûrs, et enfin intégrez des exercices de défaillance dans vos opérations régulières.