Notions de base d'un cluster de stockage Ceph expliquées avec des exemples pratiques

Introduction

Ceph est un système de stockage distribué et software-defined qui fournit des services bloc, fichier et objet avec tolérance aux pannes et élasticité horizontale. Dans ce guide, nous allons droit à l'essentiel pratique: Ceph monitors (MON), managers (MGR), Ceph OSD, pools, placement groups (PG) et réplication. Nous verrons aussi comment Ceph s'intègre avec Proxmox VE pour le stockage des machines virtuelles, ainsi qu'un plan pilote sûr que vous pouvez exécuter dans un petit labo.

Qui cela aide:

• Développeurs à la recherche d'un stockage fiable pour CI et services
• Consultants DevOps qui construisent des clusters petite à moyenne taille
• Équipes startup visant une couche de stockage résiliente et abordable

Ce que vous apprendrez:

• Les rôles de MON, MGR, OSD, pools, PGs et réplication
• Comment les données sont placées et protégées
• Des commandes simples pour vérifier la santé et créer des pools
• Comment intégrer Ceph avec Proxmox VE
• Un plan pilote local, mesurable et à faible risque

Vue d'ensemble du workflow

Un chemin clair réduit les surprises et améliore la prévisibilité.

1. Définir objectifs et contraintes

• Workloads cibles: VMs via RBD, fichiers via CephFS, objets via RGW
• Attentes de capacité, performance et domaines de défaillance

1. Concevoir les réseaux

• Réseau public pour le trafic client vers OSD
• Réseau cluster pour réplication et backfill des OSD recommandé
• Si possible, viser 10 GbE et une latence faible et stable

1. Préparer noeuds et disques

• Des disques uniformes simplifient l'équilibrage
• Un OSD par périphérique de données dédié
• Assurer NTP, noms d'hôte cohérents et disques propres

1. Déployer monitors (MON) et managers (MGR)

• Typiquement 3 MON pour un quorum robuste dans un petit cluster
• Deux MGR au minimum: un actif et un en veille

1. Créer les OSDs

• Un OSD par disque de données
• Vérifier leur présence dans l'arbre OSD

1. Définir les règles CRUSH

• Choisir un domaine de défaillance host ou chassis
• Empêcher que des répliques atterrissent sur le même hôte

1. Créer des pools et régler les PGs

• Démarrer avec des pools répliqués pour les VMs
• 32 à 128 PGs par pool selon le nombre d'OSD

1. Connecter les clients ou Proxmox VE

• Pour les VMs, utiliser un stockage RBD

1. Tester panne et reprise

• Arrêter un OSD ou éteindre un hôte pour valider la résilience

1. Observer et itérer

• Surveiller ceph -s, l'utilisation OSD, la latence et les durées de recovery

Blocs de base de Ceph

• Monitors (MON): Maintiennent les cartes du cluster et exigent un quorum. Avec trois MON, le cluster peut tolérer la panne d'un MON.
• Managers (MGR): Offrent métriques, tableau de bord et modules de service. Exécuter au moins deux MGR: un actif, un standby.
• OSDs: Ceph OSD stockent les données et métadonnées, répliquent ou encodent, et se réparent lors de défaillances.
• CRUSH: Algorithme de placement déterministe qui mappe les données vers les OSD en respectant les domaines de défaillance comme host, rack, salle.
• Pools: Espaces logiques avec politiques comme le facteur de réplication et le nombre de PG. Séparez par exemple VMs, images et sauvegardes.
• Placement Groups (PGs): Fragments d'un pool répartissant la charge entre OSD. CRUSH mappe chaque PG vers un ensemble d'OSD.
• Réplication et min_size: Les pools répliqués conservent plusieurs copies via size. Un point de départ courant est size=3 avec min_size=2 pour continuer les écritures pendant la perte d'un OSD ou d'un hôte.

Notes pratiques:

• Préférez les pools répliqués pour les workloads VM, pour leur latence plus prévisible.
• L'erasure coding réduit l'overhead de capacité pour les données froides mais augmente le CPU et l'amplification en écriture. À manier avec précaution pour les disques de boot VM.
• Évitez un sur-découpage excessif en PG: chaque PG consomme RAM et CPU.

Exemples pratiques

Exemple 1: Petit labo 3 noeuds pour VMs

• Matériel: 3 noeuds, chacun avec 2 disques de données dédiés aux OSD
• Services: 1 MON par noeud (3 au total), 2 MGR au total, 6 OSD au total
• Réseaux: Séparer public et cluster si possible

Vérifications clés

• ceph status
• ceph osd tree
• ceph osd df

Créer un pool répliqué pour VMs via RBD

• Démarrer avec 6 OSD et size=3
• Un nombre de PG pratique pour le premier pool: 64 ou 128

Commandes utiles

• Vérifier la santé: ceph -s
• Créer un pool avec 64 PGs: ceph osd pool create vms 64
• Définir la réplication: ceph osd pool set vms size 3
• Définir min_size: ceph osd pool set vms min_size 2
• Confirmer le placement: ceph osd pool get vms size et ceph osd pool get vms pg_num

Règle empirique pour les PG

• Pour les petits clusters, commencer entre 32 et 128 PGs par pool
• Réévaluer quand vous ajoutez des OSD ou de nouveaux pools

Test de panne

• Arrêter un service OSD sur un noeud et observer ceph -s
• Le pool doit rester inscriptible avec size=3 et min_size=2
• Après redémarrage de l'OSD, confirmer la fin du recovery et le retour en HEALTH_OK

Exemple 2: Répartir les répliques par hôte

• Utiliser une règle CRUSH avec failure domain host
• Vérifier via ceph osd tree que les répliques d'un même PG ne se trouvent pas sur le même hôte

Utiliser Ceph avec Proxmox VE

Proxmox VE s'intègre bien avec Ceph Proxmox pour fournir un stockage partagé aux VMs sans SAN séparé.

Approche recommandée

• Installer Ceph sur chaque noeud Proxmox
• Créer 3 MON répartis, et au moins 2 MGR
• Préparer les disques en OSD via l'interface Proxmox ou en CLI
• Créer un pool répliqué, par exemple vms, avec size=3 et min_size=2
• Dans Proxmox, ajouter un stockage de type RBD, référencer le pool et vérifier la connectivité

Conseils

• Utiliser une règle CRUSH avec failure domain host pour survivre à la perte d'un noeud complet
• Distinguer le réseau du Proxmox cluster et les réseaux public ou cluster de Ceph, avec MTU et routage maîtrisés
• Pour la live migration et la HA, placer les disques VM sur le stockage RBD Ceph

Étapes de validation dans Proxmox

• Créer une petite VM sur le stockage adossé à Ceph
• Migrer la VM à chaud entre noeuds
• Simuler une panne d'OSD et vérifier que la VM reste en ligne et que le stockage reste disponible

Plan pilote local

Objectif

• Livrer un pilote ciblé, mesurable, inspectable localement avant toute mise en production.

Portée

• 3 noeuds Proxmox VE exécutant un Ceph cluster pour un seul pool RBD nommé vms
• Une ou deux VMs de test pour solliciter lecture et écriture

Étapes

1. Construire 3 noeuds avec 2 disques de données chacun pour les OSD. Assurer NTP et un réseau cohérent.
2. Créer 3 MON et 2 MGR. Préparer et ajouter tous les disques comme OSD.
3. Créer le pool vms avec pg_num=64, size=3, min_size=2.
4. Ajouter le stockage RBD dans Proxmox pointant vers le pool vms.
5. Créer une petite VM, par exemple un disque de 10 Go, sur le stockage Ceph.
6. Lancer un court test FIO dans la VM pour générer des IO lecture et écriture.
7. Arrêter un service OSD. Confirmer que la VM reste réactive et que les écritures réussissent.
8. Redémarrer l'OSD. Vérifier que le recovery se termine et que ceph -s retourne HEALTH_OK.

Mesures et critères de sortie

• Disponibilité: les écritures réussissent avec un OSD à l'arrêt
• Santé: le cluster revient dans un état clean après recovery
• Latence: latences de base lecture et écriture acceptables pour votre workload
• Utilisation: OSD équilibrés, aucun noeud surchargé

Contrôles de risque

• Utiliser des VMs et des données jetables
• Maintenir un rollback clair: retirer le stockage RBD des VMs avant de modifier les politiques du pool

Astuce Ceph troubleshooting

• Surveiller régulièrement ceph -s, ceph osd df et ceph osd tree. En cas d'alerte, examiner les PG inactifs, les OSD down ou les lenteurs réseau.

Conclusion

Vous disposez maintenant des essentiels pour un déploiement Ceph pratique:

• Les monitors et managers apportent contrôle et visibilité
• Les OSD détiennent les données et se réparent après panne
• Les pools et PG définissent le sharding et le placement
• La réplication avec size=3 et min_size=2 est un bon départ pour les VMs
• Proxmox VE se marie bien avec Ceph pour activer live migration et HA

Prochaines étapes

• Valider votre pilote, puis augmenter le nombre d'OSD et rééquilibrer les PG
• Affiner les règles CRUSH et la séparation réseau au fur et à mesure de la croissance
• Envisager l'erasure coding pour les données plus froides où la capacité prime

Un petit pilote vérifié construit la confiance et guide le dimensionnement pour la production. Ensuite, itérez par changements mesurés et surveillez santé, latence et comportement de recovery.