Erreurs de configuration Ceph : guide pratique pour des modifications sécurisées, la validation et le retour en arrière

Introduction

Ceph est un système de stockage distribué puissant qui offre une flexibilité remarquable, mais cette même flexibilité peut conduire à des erreurs de configuration entraînant une dégradation des performances, l'indisponibilité des données, voire une perte de données. Cet article présente des exemples pratiques d'erreurs courantes et montre comment valider les modifications en toute sécurité, les mettre en œuvre avec un risque minimal et revenir en arrière si nécessaire. En suivant ces directives, vous éviterez des erreurs coûteuses et maintiendrez un cluster Ceph sain.

Inventaire de la version et de l'environnement

Avant d'apporter toute modification de configuration, vous devez comprendre votre environnement. Cela inclut la version de Ceph, la topologie du cluster, les spécifications matérielles et les paramètres de configuration actuels. Un inventaire solide évite les erreurs dues à des comportements spécifiques à une version ou à des paramètres incompatibles.

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)

Ensuite, examinez l'état du cluster et la topologie :

ceph status
ceph osd tree

Ces commandes montrent la santé du cluster, le quorum des moniteurs, la disposition des OSD et les groupes de placement. Documentez cette base de référence.

Inspectez également la configuration actuelle :

ceph config dump

Cela affiche toutes les options de configuration, leurs sources et leurs valeurs. Portez une attention particulière aux surcharges dans la base de données de configuration centrale par rapport aux fichiers ceph.conf locaux.

Enfin, vérifiez les prérequis : assurez-vous que la synchronisation de l'heure (NTP) fonctionne, que la latence réseau entre les nœuds est faible et qu'un espace disque suffisant est disponible pour les OSD et les moniteurs. Ces facteurs influencent le comportement de la configuration.

Chemin de configuration sécurisé

Un chemin de configuration sécurisé implique d'apporter des modifications de manière contrôlée et limitée. Évitez de modifier plusieurs paramètres à la fois. Modifiez plutôt un paramètre, validez son effet, puis poursuivez.

Utilisez la base de données de configuration Ceph pour les modifications centralisées. Par exemple, pour définir la priorité de récupération OSD à une valeur plus basse afin de réduire l'impact pendant la récupération :

ceph config set osd osd_recovery_op_priority 2

Cette commande modifie le paramètre pour tous les OSD. Pour limiter la modification à un OSD spécifique, utilisez un masque :

ceph config set osd.0 osd_recovery_op_priority 2

Testez toujours les modifications sur un sous-ensemble non productif ou moins critique d'abord. Par exemple, si vous avez un OSD de test ou un nœud canari, appliquez-y la modification.

Documentez chaque modification : enregistrez la valeur d'origine, la nouvelle valeur, la raison et la date. Cette documentation est essentielle pour le retour en arrière et le dépannage.

Pour les modifications dans ceph.conf sur des nœuds individuels, modifiez le fichier et redémarrez le démon concerné. Cependant, préférez la base de données de configuration centrale pour éviter les incohérences.

Exemple d'erreur courante : modifier osd_pool_default_size (facteur de réplication) sans tenir compte de l'impact sur la durabilité des données. Une approche sûre consiste à créer d'abord un pool de test, à modifier le paramètre uniquement pour ce pool et à observer le comportement.

ceph osd pool create testpool 128 128
ceph osd pool set testpool size 2

Vérifiez ensuite les paramètres du pool avec ceph osd pool get testpool size.

Vérification et diagnostic

Après avoir apporté une modification de configuration, vérifiez qu'elle a pris effet et que le cluster reste sain. Utilisez les commandes suivantes :

• Vérifiez la configuration effective pour un démon :

ceph config get osd.0 osd_recovery_op_priority

Sortie attendue :

2

• Surveillez la santé du cluster :

ceph -s

Recherchez HEALTH_OK. Si des avertissements apparaissent, enquêtez avant de continuer.

• Vérifiez les métriques de performance. Par exemple, observez la progression de la récupération si vous avez modifié les paramètres de récupération :

ceph pg stat

Ou utilisez ceph osd perf pour voir la latence des OSD.

• Examinez les journaux pour détecter les erreurs. Les journaux Ceph se trouvent dans /var/log/ceph/. Utilisez grep pour filtrer le démon et la plage de temps.

Exemple : si vous avez modifié un paramètre de moniteur, vérifiez le journal du moniteur :

tail -n 50 /var/log/ceph/ceph-mon.$(hostname -s).log

• Pour les modifications sensibles aux performances, exécutez des benchmarks avant et après. Pour RBD, vous pouvez utiliser rbd bench ou fio avec le module noyau RBD.

Exemple de bench RBD :

rbd bench --io-type write --io-size 4096 --io-threads 4 --io-total 1G myimage

Comparez les résultats à la référence. Si les performances se dégradent, envisagez de revenir en arrière.

Modes de défaillance et récupération

Malgré les précautions, les erreurs de configuration peuvent provoquer des défaillances. Les modes de défaillance courants incluent :

• Définir une valeur trop basse ou trop élevée, entraînant l'échec ou l'absence de réponse des OSD.
• Mal configurer les paramètres réseau, entraînant des échecs de communication entre les moniteurs et les OSD.
• Modifier les paramètres de pool qui entraînent l'indisponibilité des données ou une perte de redondance.

Pour récupérer, identifiez d'abord la modification à l'origine du problème. Vérifiez l'historique de configuration si vous utilisez un système de gestion de configuration, ou examinez votre journal des modifications.

Revenez en arrière en utilisant la même méthode que celle utilisée pour appliquer la modification. Pour les modifications de la base de données de configuration centrale :

ceph config rm osd osd_recovery_op_priority

Cela supprime la surcharge et revient à la valeur par défaut. Si vous avez défini une valeur spécifique, remettez-la à la valeur d'origine :

ceph config set osd.0 osd_recovery_op_priority <valeur d'origine>

Si le cluster est dans un mauvais état, vous devrez peut-être redémarrer les démons concernés :

systemctl restart [email protected]

Pour les moniteurs, assurez-vous que le quorum est maintenu. Si un moniteur échoue en raison de la configuration, vous pouvez le retirer de la monmap et le réajouter après avoir corrigé la configuration.

Exemple de scénario de récupération : vous définissez osd_max_backfills à 0 pour arrêter le remplissage, mais les OSD restent bloqués dans un état dégradé. Revenez en arrière en le définissant à une valeur saine comme 1 :

ceph config set osd osd_max_backfills 1

Surveillez ensuite la récupération avec ceph -s.

Ayez toujours une sauvegarde des fichiers de configuration critiques et de la monmap du cluster. Testez les procédures de retour en arrière dans un environnement de préproduction.

Liste de contrôle des opérations

Utilisez cette liste de contrôle avant et après avoir apporté des modifications de configuration pour minimiser les erreurs et garantir une récupération rapide.

Le respect de cette liste de contrôle garantit une approche systématique de la gestion de la configuration et réduit le risque de pannes prolongées.

Pièges courants et comment les éviter

Même les administrateurs expérimentés peuvent commettre des erreurs. Voici quelques pièges courants et des stratégies pour les éviter.

1. Modifier plusieurs paramètres à la fois : il devient difficile d'identifier quelle modification a causé un problème. Modifiez toujours un paramètre à la fois et testez minutieusement avant de passer au suivant.

1. Ignorer le comportement spécifique à la version : certaines options de configuration ont des valeurs par défaut ou une sémantique différentes selon les versions de Ceph. Consultez toujours la documentation de votre version spécifique et testez dans un environnement de préproduction.

1. Ne pas sauvegarder la configuration : sans sauvegarde, le retour en arrière devient un jeu de devinettes. Utilisez ceph config dump pour enregistrer la configuration actuelle avant de faire des modifications.

1. Appliquer des modifications globalement sans test : un paramètre qui fonctionne sur un OSD peut ne pas convenir à tous. Utilisez des masques spécifiques au démon pour tester d'abord sur un sous-ensemble.

1. Négliger les limitations matérielles : les modifications de configuration peuvent avoir des effets différents selon le matériel. Par exemple, augmenter osd_max_backfills sur un cluster avec des disques lents peut les submerger. Tenez toujours compte des capacités matérielles.

1. Oublier de mettre à jour la documentation : ne pas documenter les modifications entraîne de la confusion plus tard. Tenez un journal des modifications avec les valeurs d'origine, les raisons et les dates.

Conclusion

Les erreurs de configuration Ceph sont courantes mais évitables grâce à une planification minutieuse, une validation et des procédures de retour en arrière. En inventoriant votre environnement, en apportant des modifications limitées, en vérifiant les effets et en vous préparant aux défaillances, vous pouvez maintenir un cluster Ceph stable et performant. Utilisez la liste de contrôle des opérations comme pratique standard et documentez toujours les modifications pour référence future. Avec ces habitudes, vous gérerez en toute confiance les configurations Ceph et récupérerez rapidement de toute erreur.