Notions de base d’un cluster de stockage Ceph : meilleures pratiques modernes et exemples concrets

Intro

Ceph est un système de stockage distribué et défini par logiciel qui offre des services bloc (RBD), fichier (CephFS) et objet (RGW) avec une forte tolérance aux pannes et une mise à l’échelle horizontale. Ce guide pratique se concentre sur les composants que vous utiliserez réellement : moniteurs, gestionnaires, OSD, pools, groupes de placement et réplication. Vous verrez comment appliquer les meilleures pratiques actuelles, tester de vrais scénarios de panne et intégrer Ceph avec Proxmox VE. Un plan de pilote local est inclus pour prouver la résilience et la performance avant de passer à l’échelle.

À qui cela profite :

Développeurs cherchant un stockage persistant et peu exigeant en maintenance pour CI et services
Ingénieurs DevOps construisant des clusters de petite à moyenne taille
Équipes de startup voulant un stockage résilient sans SAN

Ce que vous allez apprendre :

Les rôles de MON, MGR, OSD, pools, PG et CRUSH
Comment les données sont placées, protégées et rééquilibrées
Les valeurs par défaut modernes : msgr2, BlueStore, autoscaling des PG et classes de périphériques
Un labo pas à pas sur 3 nœuds avec les commandes
Des parcours de panne (OSD, hôte, MON, réseau et conditions de disque plein)
Comment brancher Ceph à Proxmox VE pour le stockage VM

Composants clés (et ce qui compte en pratique)

Moniteurs (MON) : Maintiennent les cartes du cluster et nécessitent un quorum. Exécuter trois MON pour tolérer la perte d’un MON.
Gestionnaires (MGR) : Exposent les métriques, le tableau de bord et les modules de service. Exécuter deux MGR (actif/veille).
OSD : Object Storage Daemons qui stockent les données sur disques, gèrent la réplication ou l’effacement (erasure coding) et récupèrent après panne. Utiliser BlueStore (par défaut) avec optionnellement un SSD/NVMe pour DB/WAL afin d’accélérer les OSD sur HDD.
CRUSH : Algorithme déterministe qui place les données à travers des domaines de défaillance (host, rack, salle). Utiliser des règles qui placent au minimum les réplicas sur des hôtes différents.
Pools : Espaces logiques avec des politiques (facteur de réplication, nombre de PG, autoscaler). Pour les disques de VM, utiliser un pool répliqué avec l’application définie sur rbd.
Groupes de placement (PG) : Fragments d’un pool qui répartissent les données entre OSD. Laisser l’autoscaler de PG gérer les comptes dans la plupart des cas.
Réplication et min_size : Un défaut courant pour les pools VM est size=3, min_size=2 (les écritures continuent avec une réplique manquante).

Notes pratiques :

Préférer les pools répliqués pour les charges VM en raison de la latence ; envisager l’erasure coding seulement pour les données plus froides ou les sauvegardes.
Activer l’autoscaler de PG et le balancer (mode upmap) pour garder un placement efficace sans sur-fragmentation.
Utiliser les classes de périphériques (hdd/ssd/nvme) et des règles CRUSH pour réserver les médias plus rapides aux pools sensibles à la latence.

Planifier le cluster et les réseaux

Charges : Décider des services nécessaires : RBD pour VM, CephFS pour fichiers POSIX partagés, RGW pour objets compatibles S3.
Capacité et performance : Estimer les To utilisables après réplication ; planifier des objectifs d’IOPS/latence.
Réseaux : Utiliser un réseau public pour le trafic client et un réseau de cluster pour la réplication/backfill des OSD. 10 GbE minimum fonctionne ; 25 GbE est recommandé pour des déploiements modernes. Garder une faible latence et une MTU cohérente (jumbo frames seulement si de bout en bout).
Hôtes et disques : Garder NTP synchronisé, les noms d’hôtes cohérents et les micrologiciels à jour. Pour des OSD sur HDD, associer chacun à une petite partition NVMe pour le DB/WAL de BlueStore. Des tailles de disques uniformes simplifient l’équilibrage.
Services : Démarrer avec 3 MON, 2 MGR et au moins 3 hôtes pour que CRUSH puisse répartir les réplicas par hôte.

Déployer avec des valeurs par défaut modernes

Les extraits ci-dessous supposent un shell avec privilèges admin sur le cluster. Adaptez les noms si nécessaire.

Vérifications clés :

ceph -s
ceph health detail
ceph osd tree
ceph osd df

Modules recommandés et autoscaling :

ceph mgr module enable pg_autoscaler
ceph mgr module enable balancer
ceph balancer mode upmap
ceph balancer on

Créer un pool RBD répliqué avec autoscaler :

# Créer un pool et laisser l’autoscaler choisir les PG
ceph osd pool create vms
# Définir la politique de réplication
ceph osd pool set vms size 3
ceph osd pool set vms min_size 2
# Activer l’application RBD pour des fonctionnalités comme layering et deep-flatten
ceph osd pool application enable vms rbd
rbd pool init vms

CRUSH et classes de périphériques :

# Étiqueter les périphériques avec des classes (souvent automatique). Exemple :
ceph osd crush set-device-class ssd osd.1 osd.2
# Créer une règle avec domaine de défaillance host sur SSD (si nécessaire)
ceph osd crush rule create-replicated vms-ssd default host ssd
ceph osd pool set vms crush_rule vms-ssd

Astuce sur la taille des PG : Laisser l’autoscaler gérer les PG. Optionnellement, donner un indice de capacité avec des ratios cibles pour aligner les PG sur le volume de données entre pools :

ceph osd pool set vms target_size_ratio 0.5

Exemple pratique : un labo résilient à 3 nœuds pour VM

Base :

3 nœuds, chacun avec 2 périphériques de données (6 OSD au total)
3 MON (un par nœud), 2 MGR, 6 OSD
Réseaux public et cluster séparés si possible

Créer et vérifier :

# Santé et topologie
ceph -s
ceph osd tree
ceph osd df

# Pool (comme ci-dessus)
ceph osd pool create vms
ceph osd pool set vms size 3
ceph osd pool set vms min_size 2
ceph osd pool application enable vms rbd
rbd pool init vms

# Confirmer que l’autoscaler est actif
ceph osd pool autoscale-status

Règle pratique : pour de petits labos, viser environ 100–200 PG totaux par OSD pour l’ensemble des pools ; l’autoscaler convergera vers des valeurs sûres à mesure que vous ajoutez des données. Éviter de forcer manuellement des comptes de PG très élevés qui augmentent la mémoire et le CPU.

Scénarios de panne à pratiquer

Le moment le plus sûr pour comprendre le comportement de Ceph est en labo. Les commandes ci-dessous créent des fautes contrôlées et les vérifications associées.

Panne d’OSD (disque unique)

Action :

# Identifier un ID d’OSD (p. ex., 2) sur un nœud non critique
systemctl stop ceph-osd@2
# Optionnel : le marquer out si vous voulez évacuer rapidement les données
ceph osd out 2

À prévoir : ceph -s affiche HEALTH_WARN avec des PG dégradés/sous-dimensionnés. Les écritures continuent car size=3, min_size=2.
Récupération : Redémarrer l’OSD et effacer le drapeau out si vous l’avez défini.

systemctl start ceph-osd@2
ceph osd in 2
ceph -s

Réglages pendant la récupération (pour protéger la latence client) :

ceph config set osd osd_max_backfills 2
ceph config set osd osd_recovery_max_active 2

Panne complète d’hôte (nœud hors ligne)

Action : Éteindre ou déconnecter un nœud.
Attendu : Le pool reste inscriptible ; les réplicas demeurent sur les hôtes survivants grâce au domaine de défaillance host. ceph -s montre une disponibilité réduite pour certains PG jusqu’au retour du nœud.
Après rétablissement, observer le backfill et vérifier le retour à HEALTH_OK.

Panne de moniteur et quorum

Action :

systemctl stop ceph-mon@$(hostname -s)

Attendu : Avec trois MON, le quorum tient (2/3). ceph quorum_status indique quels MON sont en quorum. Ne pas exécuter un nombre pair de MON.
Récupération : Redémarrer le MON et confirmer qu’il rejoint le quorum.

Partition réseau

Action : Déconnecter l’interface réseau de cluster d’un nœud tout en gardant le réseau public actif.
Attendu : Les E/S client peuvent continuer, mais la réplication/le backfill de ce nœud seront bloqués ; l’état de santé indique un peering en attente. Cela illustre l’intérêt de réseaux séparés et à faible latence.

Conditions nearfull/full

Seuils : Les valeurs typiques par défaut sont nearfull ~85 % et full ~95 %.
Vérifications et remédiations :

ceph df
ceph health detail
# Ajouter de la capacité ou retirer des données. Ne jamais ignorer un état FULL.

Drapeaux de maintenance sécurisés

Pendant des redémarrages planifiés :

ceph osd set noout
# Redémarrer un nœud à la fois
ceph osd unset noout

N’utiliser norecover/nobackfill que temporairement et les effacer rapidement une fois le travail terminé.

Utiliser Ceph avec Proxmox VE (RBD pour VM)

Proxmox VE s’intègre étroitement avec Ceph, permettant d’exécuter calcul et stockage sur les mêmes nœuds tout en conservant la HA et la migration à chaud.

Approche recommandée :

Installer Ceph sur chaque nœud Proxmox via l’interface de gestion Ceph de Proxmox.
Créer 3 MON répartis sur vos nœuds et 2 MGR.
Préparer les OSD (via l’UI) en utilisant des disques entiers ; pour des OSD sur HDD, choisir un périphérique NVMe pour DB/WAL si disponible.
Créer un pool répliqué nommé vms avec size=3, min_size=2 et activer l’autoscaler de PG.
Dans Proxmox, ajouter un stockage de type RBD (Ceph) pointant vers le pool vms. Activer cephx et msgr2 (par défaut).
Choisir la méthode d’accès : librbd (espace utilisateur) est courant pour les snapshots et la migration à chaud ; RBD noyau (krbd) peut être utilisé si requis par votre environnement.

Étapes de validation :

Créer une petite VM de test sur le stockage adossé à Ceph.
Migrer la VM à chaud entre nœuds.
Arrêter un OSD et vérifier que la VM continue de fonctionner et que les E/S restent disponibles.

Conseils :

Distinguer le réseau de cluster Proxmox et les réseaux public/cluster de Ceph, avec des MTU et un routage prévisibles.
Utiliser une règle CRUSH avec domaine de défaillance host pour survivre à la perte d’un nœud entier.
Surveiller le tableau de bord Ceph de Proxmox pour la latence, l’usage OSD et la progression de la récupération.

Plan de pilote local (sûr et mesurable)

Objectif : Prouver que votre cluster Ceph à 3 nœuds maintient les VM en ligne lors de pannes courantes et atteint une latence de base.

Périmètre :

3 nœuds Proxmox VE exécutant un cluster Ceph pour un unique pool RBD vms
1–2 VM de test pour exercer les chemins lecture/écriture

Étapes :

Construire 3 nœuds avec au moins 2 disques de données chacun. Vérifier NTP, réseaux et noms d’hôtes.
Déployer 3 MON et 2 MGR. Préparer et ajouter tous les disques de données comme OSD.
Créer le pool vms avec autoscaler activé ; définir size=3 et min_size=2 ; activer l’application rbd.
Ajouter un stockage RBD dans Proxmox pointant vers vms et créer une VM de test de 10 Go.
Lancer un court test d’E/S dans la VM :

# Exemple fio dans la VM
fio --name=randrw --filename=/dev/sda \
    --rw=randrw --bs=4k --iodepth=16 --numjobs=1 \
    --time_based --runtime=60 --group_reporting

Arrêter un service OSD et confirmer que la VM reste réactive et que les écritures réussissent :

systemctl stop ceph-osd@<id>
ceph -s

Redémarrer l’OSD et vérifier que la récupération se termine et que HEALTH_OK revient.

Mesures et critères de sortie :

Disponibilité : Les écritures réussissent avec un OSD à l’arrêt.
Santé : Le cluster revient à un état propre après récupération.
Latence : La latence 4k en lecture/écriture aléatoire est acceptable pour votre charge (suivre la moyenne et le 99e percentile dans le tableau de bord).
Équilibre : L’utilisation des OSD est globalement homogène ; activer le balancer et upmap si c’est déséquilibré.

Contrôles de risque :

Utiliser des données jetables et des VM de test.
Pour toute maintenance d’hôte, définir noout avant le reboot et l’annuler après.

Conclusion

Vous avez l’essentiel pour construire, tester et exploiter un petit cluster Ceph résilient :

Les moniteurs et gestionnaires assurent le quorum, la visibilité et l’automatisation.
Les OSD stockent les données, se réparent après panne et s’étendent horizontalement.
Les règles CRUSH, les pools et les PG déterminent le placement et la protection des données.
Les pools répliqués avec size=3 et min_size=2 sont une base robuste pour les charges VM.
L’autoscaler de PG et le balancer réduisent les réglages manuels au fur et à mesure de la croissance.
Proxmox VE s’intègre proprement avec Ceph pour un stockage partagé, la migration à chaud et la HA.

Validez d’abord un petit pilote, capturez des bases de santé et de latence, puis montez en charge méthodiquement. À mesure que vous ajoutez de la capacité, gardez des réseaux à faible latence, appliquez des domaines de défaillance clairs et répétez périodiquement des exercices de panne pour que le comportement de récupération reste conforme à vos attentes.