Ceph RBD pour le stockage VM Proxmox expliqué avec exemples pratiques : guide d'implémentation pratique

Ceph RADOS Block Device (RBD) vous fournit des volumes bloc en réseau. Dans Proxmox, chaque disque VM sur un stockage Ceph RBD est une image RBD dans un pool. Cela apporte le provisionnement mince (thin provisioning), des snapshots et clones rapides, et un stockage partagé pour la migration à chaud. Ce guide explique les composants, montre comment créer et utiliser pools et images, et donne des commandes pratiques pour vérifier la santé et déboguer les problèmes.

Ce que vous allez apprendre

Comment Proxmox mappe les disques VM aux images et pools RBD
Comment créer un pool, l'ajouter à Proxmox et provisionner des disques VM
Comment utiliser les snapshots, clones et rollback RBD en toute sécurité
Les bases de performance pour éviter les pièges courants
Les modes de panne à prévoir et comment les vérifier avant que les utilisateurs ne les remarquent

RBD et Proxmox : le modèle mental rapide

Cluster Ceph : les moniteurs (MONs) maintiennent les cartes du cluster ; les OSDs stockent les données. Les clients parlent aux MONs pour les cartes, puis aux OSDs pour les données.
Pool : un espace de noms avec réglages de réplication et règles de placement. Les images VM vivent dans un pool.
Image RBD : un périphérique bloc virtuel. Proxmox les nomme comme vm-<VMID>-disk-<N>.
Snapshots : métadonnées point-in-time d'une image RBD. Des clones peuvent être créés à partir de snapshots protégés.
Intégration Proxmox : QEMU/KVM accède aux images via librbd (krbd optionnel). La migration à chaud fonctionne car tous les nœuds voient le même stockage.

Vue d'ensemble du workflow

Planifier le réseau et les domaines de panne

Au minimum, isolez le réseau du cluster Ceph du trafic client/public (deux VLANs ou deux cartes physiques). La faible latence et un MTU constant entre nœuds importent plus que la bande passante brute.
Gardez les MONs en nombre impair (3 ou 5). Placez les OSDs sur plusieurs hôtes et châssis pour éviter les pannes corrélées.

Créer un pool pour les images VM

Choisissez la réplication d'abord (ex: size=3) pour la simplicité. Le codage d'effacement (erasure coding) viendra plus tard.
Commencez avec un nombre de PG modeste adapté à votre nombre d'OSDs. Pour un lab 3 nœuds avec 6 OSDs total (2 par nœud), un pool avec 128 PGs (pg_num=128) donne ~21 PGs par OSD, dans la fourchette recommandée de 100-250 PGs par OSD.

Exemples de commandes :

   # Voir la santé du cluster et les OSDs
   ceph -s
   ceph osd tree

   # Créer un pool répliqué pour les VMs (ajuster pg_num à votre cluster)
   ceph osd pool create vms 128

   # Définir la taille de réplication et confirmer
   ceph osd pool set vms size 3
   ceph osd pool get vms size

Ajouter le stockage Ceph RBD à Proxmox

Si ceph.conf et keyring sont déployés sur les nœuds, ajoutez le stockage RBD via l'interface graphique ou storage.cfg.

Exemple storage.cfg :

   # /etc/pve/storage.cfg
   rbd: ceph-vms
    pool vms
    content images
    krbd 0
    monitor_host 10.0.0.11;10.0.0.12;10.0.0.13
    username admin
    keyring /etc/pve/priv/ceph.client.admin.keyring

Créer une VM et placer son disque sur le stockage RBD

Dans l'interface Proxmox, choisissez le stockage Ceph pour le disque. Proxmox crée des images comme vms/vm-100-disk-0.
Vérifiez depuis un nœud :

     rbd ls -p vms
     rbd info vms/vm-100-disk-0

Utiliser snapshots et clones en toute sécurité

Les snapshots sont quasi-instantanés. Protégez un snapshot avant de le cloner.

   # Créer et lister les snapshots
   rbd snap create vms/vm-100-disk-0@pre-upgrade
   rbd snap ls vms/vm-100-disk-0

   # Rollback si nécessaire (VM doit être éteinte)
   rbd snap rollback vms/vm-100-disk-0@pre-upgrade

   # Cloner depuis un snapshot
   rbd snap protect vms/vm-100-disk-0@gold
   rbd clone vms/vm-100-disk-0@gold vms/vm-101-disk-0

Surveiller, opérer et maintenir

Gardez un œil sur la santé, l'espace et l'état de récupération.

   ceph -s
   ceph df
   ceph health detail
   pvesm status

Pendant la maintenance planifiée, envisagez :

   # Empêcher le rééquilibrage si vous arrêtez des OSDs intentionnellement (utiliser avec parcimonie)
   ceph osd set noout
   # ...maintenance...
   ceph osd unset noout

Exemples pratiques

Exemple 1 : Provisionner un nouveau pool et l'attacher à Proxmox

Objectif : obtenir un pool vms fonctionnel pour des VMs non critiques.

# Créer le pool et définir la taille
ceph osd pool create vms 128
ceph osd pool set vms size 3

# Vérifier les placement groups
ceph -s

Ajoutez à Proxmox via storage.cfg ou l'interface. Confirmez que Proxmox voit le stockage : Datacenter -> Stockage -> ceph-vms.

Créez une petite VM de test avec son disque sur ceph-vms. Confirmez :

rbd ls -p vms
rbd info vms/vm-101-disk-0

Exemple 2 : Snapshot avant un changement risqué

rbd snap create vms/vm-101-disk-0@before-change
# Si rollback nécessaire (éteindre la VM d'abord)
rbd snap rollback vms/vm-101-disk-0@before-change

Exemple 3 : Image de référence vers plusieurs VMs avec clones

Convertissez un disque VM préparé en snapshot de référence, puis clonez rapidement :

# S'assurer que l'image de base est éteinte et consistante
rbd snap create vms/vm-200-disk-0@gold
rbd snap protect vms/vm-200-disk-0@gold
# Créer des clones pour les nouvelles VMs
rbd clone vms/vm-200-disk-0@gold vms/vm-201-disk-0
rbd clone vms/vm-200-disk-0@gold vms/vm-202-disk-0

Après le provisionnement des clones, envisagez d'aplatir (flatten) les gros consommateurs plus tard pour réduire la dépendance à l'image parente :

rbd flatten vms/vm-201-disk-0

Exemple 4 : Vérifications rapides de performance

Établissez une base du pool avec un simple rados bench pendant qu'aucune VM n'est occupée :

rados bench -p vms 60 write --no-cleanup
rados bench -p vms 60 seq
rados bench -p vms 60 rand

Vérifiez l'utilisation du cache côté client pour une image :

rbd status vms/vm-101-disk-0

Vérifiez la distribution de charge réseau et OSD :

ceph osd df
ceph osd tree

Bases de performance qui comptent

Le réseau d'abord : gardez une latence faible et constante ; vérifiez le MTU de bout en bout (ex: 9000) si vous utilisez des trames géantes (jumbo frames).
Taille de réplication : size=3 est courant. Ne définissez jamais min_size si bas que vous risquez de servir des données sans redondance suffisante (ex: gardez min_size=2).
Évitez la prolifération de pools : moins de pools avec des compteurs PG corrects sont généralement meilleurs.
Commencez avec librbd (krbd=0). Envisagez krbd seulement pour des cas spéciaux ; librbd permet des fonctionnalités comme la migration à chaud de façon fluide.
Surveillez le remplissage des pools : les drapeaux nearfull et full bloqueront les écritures. Gardez de la marge (par exemple, évitez de dépasser ~80% sans plan comme ajouter des OSDs, activer le codage d'effacement pour données froides, ou supprimer des images inutilisées).
Benchmark avec des patterns réalistes : rados bench est un test niveau cluster ; pour des patterns VM, fio dans un invité peut aider, mais ne testez pas pendant les pics de production.

Modes de panne courants et quoi surveiller

OSD down ou instable (flapping)

Symptômes : données dégradées, récupération/backfill actif, IOPS plus bas.
Vérifications : ceph -s, ceph osd tree, santé du journal ou du périphérique (SMART).

Perte de quorum des moniteurs

Symptômes : les clients ne peuvent pas obtenir les cartes du cluster ; erreurs sévères.
Vérifications : ceph quorum_status, assurez nombre impair de MONs et stabilité réseau.

Pool plein ou quasi-plein

Symptômes : écritures bloquées ; VMs figées sur I/O.
Vérifications : ceph df, ceph health detail pour full/nearfull. Libérez de l'espace urgemment ou ajoutez de la capacité.

Partitions réseau ou MTU mal assorti

Symptômes : timeouts intermittents, requêtes lentes, beaucoup d'événements de changement osdmap.
Vérifications : MTU constant (ping avec -s 8972 -M do), iperf3 entre nœuds, logs des moniteurs.

Nombre de PG mal dimensionné

Symptômes : points chauds (hotspots), utilisation inégale des OSDs.
Vérifications : ceph pg dump, ceph osd df. Ajustez avec précaution et planifiez l'impact du backfill.

Problèmes de mapping client

Symptômes : VM ne peut pas démarrer ou attacher le disque ; erreurs AUTH.
Vérifications : permissions keyring, exactitude storage.cfg, accessibilité monitor_host.

Vérifications opérationnelles sûres avant et après changements

Exécutez cette liste de contrôle compacte avant les changements risqués (comme mises à niveau ou arrêt de nœuds) :

Santé et capacité

ceph -s
ceph df
ceph health detail

Redondance du pool

ceph osd pool get vms size
ceph osd pool get vms min_size

Arriéré de récupération

ceph -s  # s'assurer qu'aucune grosse récupération/backfill en cours

Visibilité du stockage Proxmox

pvesm status | grep ceph-vms

Garde-fous de maintenance optionnels

# Si vous allez arrêter des OSDs intentionnellement
ceph osd set noout
# ... faire le travail ...
ceph osd unset noout

Plan pilote local

Commencez petit, mesurez, et étendez seulement après avoir validé les critères de sortie.

Périmètre

3 nœuds Proxmox qui hébergent aussi les MONs Ceph et 1-2 OSDs chacun
1 pool répliqué vms avec size=3
2 VMs de test : une usage général, une IO-intensive

Signaux de succès

Les disques VM tournent sur RBD avec latence stable sous charge dev typique
La migration à chaud se termine dans votre fenêtre cible
Snapshots et rollback fonctionnent et sont documentés

Plan de mesure

Base : rados bench sur cluster inactif
Charge : fio dans un invité avec tests simples 4k randrw et 1M seq write
Observer : ceph -s pendant les tests, noter requêtes lentes ou récupération

Critères de sortie

Aucun HEALTH_WARN sous charge normale pendant au moins 48 heures
Pool sous 70% d'utilisation pendant les tests
Migration à chaud réussit pour les deux VMs de test

Prochaines étapes de déploiement

Ajouter capacité ou régler réseaux si vous manquez les cibles
Documenter les procédures opérationnelles standard pour snapshots et maintenance

Conclusion

Ceph RBD s'intègre proprement avec Proxmox pour fournir des disques VM partagés, provisionnés finement, plus snapshots et clones rapides. Commencez avec un pool répliqué simple, câblez-le dans Proxmox, et validez avec un petit pilote avant de passer à l'échelle. Gardez les réseaux prévisibles, surveillez la santé et la capacité, et utilisez les snapshots délibérément.

Prochaines actions

Construire le pool vms et l'attacher à Proxmox
Créer une VM de test, snapshot avant changements, et pratiquer le rollback
Exécuter les vérifications opérationnelles sûres avant toute maintenance
Étendre la capacité seulement après que votre pilote atteigne ses critères de sortie