Architecture de Ceph expliquée avec des exemples pratiques

Architecture de Ceph expliquée avec des exemples pratiques

Introduction

Ceph est un système de stockage distribué open-source qui fournit un stockage objet, bloc et fichier dans une plateforme unifiée. Son architecture est conçue pour un comportement auto-réparateur et auto-gérant sans point unique de défaillance, ce qui en fait un choix populaire pour l'infrastructure cloud, les clusters Kubernetes et l'analyse de données à grande échelle. Pour les consultants DevOps et les équipes techniques de startups, comprendre les composants de base — moniteurs (MON), gestionnaires (MGR), daemons de stockage objet (OSD), serveurs de métadonnées (MDS) et clients — est essentiel pour un déploiement réussi et une exploitation à long terme. Cet article plonge dans l'architecture de Ceph avec des exemples pratiques, y compris des extraits de configuration, des commandes de vérification et des étapes de reprise après panne que vous pouvez appliquer immédiatement dans votre environnement.

Inventaire des versions et de l'environnement

Avant de commencer, établissez votre version de Ceph et votre environnement. Ceph évolue rapidement ; connaître votre version exacte aide à éviter les surprises et garantit la compatibilité avec les dernières fonctionnalités. Ce guide suppose Ceph Reef (v18.2.0) sur Ubuntu 22.04 LTS, mais les principes s'appliquent à d'autres versions et distributions. Un cluster minimal pour les tests nécessite au moins trois nœuds : un nœud pour MON/MGR et deux nœuds pour les OSD. En production, vous devriez séparer ces rôles et exécuter plusieurs moniteurs et gestionnaires pour la haute disponibilité. Le tableau suivant résume les composants requis et leurs nombres minimaux :

Assurez-vous que votre système d'exploitation, votre noyau et votre réseau répondent aux prérequis. Ceph recommande un réseau 10GbE ou plus rapide pour de bonnes performances. Utilisez ceph --version pour vérifier la version installée. Par exemple :

ceph --version

Sortie attendue :

ceph version 18.2.0 (5dd24139a4e2a36d3b2e1f3f8b3e7b0f2b0e1a9c) reef (stable)

Chemin de configuration sécurisé

La mise en œuvre de Ceph nécessite une configuration minutieuse pour éviter de perturber les charges de travail existantes. Commencez par un projet pilote restreint pour minimiser les risques. Par exemple, si vous prévoyez de migrer depuis une solution de stockage existante, commencez par une seule image RBD sur un pool de test. Cette approche vous permet de valider les performances, les fonctionnalités et les processus de récupération sans affecter les données de production.

Tout d'abord, créez un pool dédié avec un nombre défini de groupes de placement (PG). Utilisez la commande ceph osd pool create. Le nombre de PG dépend du nombre d'OSD et de la distribution souhaitée des données. Une règle courante est d'environ 100 PG par OSD pour les grands clusters, mais pour un petit cluster de test, 32 ou 64 suffisent. Exemple :

ceph osd pool create testpool 32 32   # nom du pool, pg_num, pgp_num

Sortie attendue :

pool 'testpool' created

Ensuite, configurez la taille du pool (facteur de réplication) et l'autoscaling des groupes de placement. Pour un test, définissez la taille à 2 pour économiser de l'espace tout en maintenant la redondance :

ceph osd pool set testpool size 2

Assurez-vous d'avoir au moins deux OSD actifs pour répondre à l'exigence de taille. Vérifiez avec ceph osd tree :

ceph osd tree

Exemple de sortie :

ID  CLASS  WEIGHT   TYPE NAME              STATUS  REWEIGHT  PRI-AFF
-1         0.02939  root default
-3         0.00980      host node1
 0    hdd  0.00980          osd.0              up      1.00000  1.00000
-5         0.00980      host node2
 1    hdd  0.00980          osd.1              up      1.00000  1.00000

Maintenant, créez une image de périphérique bloc et mappez-la sur un nœud client. Sur le client, installez le paquet ceph-common et récupérez le keyring depuis le cluster. Créez l'image :

rbd create testimage --size 1G --pool testpool

Puis mappez-la :

rbd map testpool/testimage

Si cela réussit, le périphérique /dev/rbd/rbd/testpool/testimage (ou /dev/rbd0) apparaîtra. Formatez et montez-le :

mkfs.ext4 /dev/rbd0
mkdir -p /mnt/ceph-test
mount /dev/rbd0 /mnt/ceph-test

Ceci démontre une configuration de base de périphérique bloc Ceph. Pour la production, envisagez d'utiliser les cartes CRUSH pour contrôler le placement des données et les domaines de défaillance, en veillant à ce que les réplicas se trouvent sur des hôtes ou des racks différents.

Vérification et diagnostics

La vérification est essentielle pour garantir la santé de votre cluster Ceph. Utilisez les commandes suivantes pour observer l'état du cluster, les performances et l'intégrité des données.

Tout d'abord, vérifiez la santé globale :

ceph -s

La sortie attendue montre HEALTH_OK ou HEALTH_WARN avec des détails. Par exemple :

  cluster:
    id:     4b5c8ccb-6a5e-4bf0-9e3b-9a2c8b1e5f3a
    health: HEALTH_OK

  services:
    mon: 1 daemons, quorum name (age 5m)
    mgr: 1 daemons active (age 5m)
    osd: 2 osds: 2 up (since 5m), 2 in (since 5m)

  data:
    pools:   1 pools, 32 pgs
    objects: 0 objects, 0 B
    usage:   0 B used, 0 B / 0 B avail
    pgs:     32 active+clean

Inspectez la distribution et l'état des groupes de placement :

ceph pg stat

Devrait afficher des états active+clean. Exemple :

32 pgs: 32 active+clean; 0 B used, 0 B / 0 B avail

Surveillez l'utilisation du disque et les performances :

ceph osd df

Ceci montre l'utilisation par OSD. Exemple :

ID  CLASS  WEIGHT   RAW USED  DATA     OMAP  META     USED%  AVAIL   RAW USE
 0    hdd  0.00980    1.0 GiB  1.0 GiB  0 B  1.0 MiB  10.20%  8.8 GiB  1.0 GiB
 1    hdd  0.00980    1.0 GiB  1.0 GiB  0 B  1.0 MiB  10.20%  8.8 GiB  1.0 GiB
TOTAL          0.0196    2.0 GiB  2.0 GiB  0 B  2.0 MiB  10.20%  17.6 GiB  2.0 GiB

Pour les performances réseau et client, utilisez ceph osd perf :

ceph osd perf

Exemple de sortie :

osd fs_commit_latency_ms fs_apply_latency_ms
 0               0.000000              0.000000
 1               0.000000              0.000000

Vérifiez les opérations sur les images RBD :

rbd info testpool/testimage

Ceci montre la taille de l'image et ses fonctionnalités. Exemple de sortie :

rbd image 'testimage':
	size 1 GiB
	features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
	...

Testez également les E/S de bout en bout avec une simple écriture et lecture :

echo "Hello Ceph" > /mnt/ceph-test/test.txt
cat /mnt/ceph-test/test.txt

Sortie attendue :

Hello Ceph

Modes de défaillance et récupération

Comprendre les modes de défaillance est essentiel pour maintenir un cluster Ceph fiable. Les risques courants incluent la défaillance des OSD, les partitions réseau et les problèmes de moniteur. Explorons chacun et comment récupérer.

Défaillance d'un OSD

Si un OSD plante, Ceph réplique automatiquement les données à partir des copies restantes vers de nouveaux OSD pour maintenir le facteur de réplication. Utilisez ceph osd tree pour voir le statut. Si un OSD est down, redémarrez-le :

systemctl restart ceph-osd@<osd-id>

S'il ne peut pas récupérer, vous devrez peut-être remplacer le disque. Pour tester, simulez une défaillance d'OSD en arrêtant le service systemd. Par exemple, pour arrêter l'OSD 0 :

systemctl stop ceph-osd@0

Vérifiez la santé avec ceph -s ; l'état montrera DEGRADED et des états pg comme degraded ou undersized. Une fois que vous redémarrez l'OSD, le cluster devrait récupérer. Exemple :

systemctl start ceph-osd@0

Vérifiez ensuite avec ceph -s jusqu'à ce que HEALTH_OK soit rétabli.

Défaillance d'un moniteur

Si un moniteur tombe en panne, le cluster peut perdre le quorum, ce qui arrête toutes les E/S. Assurez-vous d'avoir un nombre impair de moniteurs (3 ou plus) en production. Si un moniteur est en panne, vérifiez son statut avec :

ceph mon stat

S'il ne fonctionne pas, redémarrez-le :

systemctl restart ceph-mon@<mon-id>

Si les données du moniteur sont corrompues, vous devrez peut-être le reconstruire à partir d'autres moniteurs en utilisant ceph-mon --cluster ceph --mkfs et le réajouter, mais c'est un scénario de récupération plus avancé.

Partition réseau

Ceph utilise un mécanisme de heartbeat entre les moniteurs et les OSD. S'il y a une déconnexion réseau, les OSD peuvent être marqués down en raison de heartbeats manqués. Assurez-vous que votre réseau est stable et correctement configuré (par exemple, pas de perte de paquets, MTU approprié). Si une partition réseau se produit, Ceph peut marquer les OSD comme down même s'ils sont sains. Une fois le réseau rétabli, Ceph ramènera automatiquement les OSD et rééquilibrera. Vous pouvez vérifier le statut des OSD avec ceph osd tree.

Étapes de récupération

En cas de problème grave, vous pouvez empêcher Ceph de rééquilibrer les OSD mal étiquetés en définissant un indicateur :

ceph osd set noout

Ceci indique à Ceph de ne pas rééquilibrer les données hors des OSD marqués out. Après avoir corrigé le problème sous-jacent, désactivez l'indicateur :

ceph osd unset noout

Pour les défaillances complexes, conservez toujours une sauvegarde de /etc/ceph/ceph.conf et des keyrings. Une surveillance régulière avec ceph health detail aide à détecter les problèmes tôt. Par exemple :

ceph health detail

Ceci fournit des avertissements et des suggestions spécifiques.

Liste de contrôle opérationnelle

Les opérations reproductibles commencent par une liste de contrôle. Utilisez-la pour garantir que votre cluster Ceph reste sain et performant.

Quotidien

• Vérifiez ceph -s pour l'état de santé.
• Examinez les journaux OSD et MON pour les erreurs : journalctl -u ceph-osd@*
• Vérifiez l'espace disque : ceph df

Par exemple, pour vérifier les journaux de l'OSD 0 :

journalctl -u ceph-osd@0 --since "today"

Hebdomadaire

• Exécutez ceph pg repair si des PG sont mal placés ou dégradés.
• Vérifiez les requêtes lentes : ceph daemon osd.<id> ops (par exemple, ceph daemon osd.0 ops)

Exemple de ceph pg repair :

ceph pg repair 1.0

Mensuel

• Mettez à jour les paquets Ceph après avoir testé dans un environnement de staging : sudo apt update && sudo apt upgrade (ou zypper/dnf sur d'autres distributions).
• Examinez la configuration pour les paramètres obsolètes : ceph config dump

Voici un tableau résumant les commandes clés pour chaque tâche :

Documentez toujours les modifications et vérifiez les sauvegardes. Utilisez des fenêtres de maintenance pour les mises à niveau majeures afin de minimiser l'impact.

Conclusion

L'architecture de Ceph fournit une base robuste pour un stockage évolutif, mais elle nécessite une compréhension approfondie et des opérations continues. Nous avons exploré les composants de base, mis en œuvre un périphérique bloc de test, vérifié la santé du cluster et discuté de la reprise après panne. Prochaines étapes : commencez par un projet pilote dans un laboratoire, utilisez la liste de contrôle pour surveiller la santé et développez progressivement vers des charges de travail de production. Continuez à apprendre et restez à jour avec les versions de Ceph pour bénéficier des améliorations et des nouvelles fonctionnalités. Avec la bonne approche, Ceph peut devenir une colonne vertébrale de stockage fiable et efficace pour votre infrastructure.