Ceph RBD pour le stockage des VM Proxmox expliqué avec des exemples pratiques

Intro

Cette version française explique Ceph RBD for Proxmox VM storage explained with practical examples avec le même objectif pratique que l article source : aider le lecteur à comprendre le contexte, les décisions à prendre et les points à vérifier avant de passer à l action.

Ceph RADOS Block Device (Ceph RBD) fournit des volumes bloc accessibles sur le réseau. Dans Proxmox, chaque disque de VM stocké sur un backend Ceph RBD correspond à une image RBD dans un pool. Résultat: provisioning fin, snapshots et clones rapides, et stockage partagé pour la migration à chaud. Ce guide explique les composants, montre comment créer et utiliser des pools et des images, et propose des commandes pratiques pour vérifier la santé et dépanner les problèmes (RBD troubleshooting).

Ce que vous allez apprendre:

Comment Proxmox mappe les disques de VM vers des images RBD et des pools
Comment créer un pool, l'ajouter à Proxmox, et provisionner des disques
Comment utiliser snapshots, clones et rollback en sécurité
Les bases de performance à connaître pour éviter les pièges
Les modes de panne à anticiper et comment les détecter tôt

RBD et Proxmox : le modèle mental rapide

Cluster Ceph: les moniteurs (MON) maintiennent les cartes du cluster; les OSD stockent les données. Les clients demandent d'abord les cartes aux MON, puis parlent directement aux OSD pour les E/S.
Pool: un espace logique avec paramètres de réplication et règles de placement. Les images de VM vivent dans un pool.
Image RBD: un périphérique bloc virtuel. Proxmox les nomme vm-<VMID>-disk-<N>.
Snapshots: des points dans le temps au niveau métadonnées. Les clones se créent à partir de snapshots protégées.
Intégration Proxmox: QEMU/KVM accède 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

Isolez le réseau du cluster Ceph du trafic client/public (deux VLANs ou deux NICs). Une latence faible et une MTU cohérente entre les nœuds priment sur la bande passante brute.
Gardez un nombre impair de MON (3 ou 5). Répartissez les OSD entre hôtes et châssis pour éviter les pannes corrélées.

Créer un pool pour les images de VM

Commencez par la réplication (par ex. size=3) pour la simplicité. L'erasure coding pourra venir plus tard.
Démarrez avec un nombre de PG adapté à votre nombre d'OSD. Pour un petit labo, 64 ou 128 conviennent.

Exemples de commandes:

# État du cluster et OSDs
ceph -s
ceph osd tree

# Créer un pool répliqué pour les VMs (ajustez pg_num)
ceph osd pool create vms 64

# Définir la réplication et vérifier
ceph osd pool set vms size 3
ceph osd pool get vms size

Ajouter le stockage Ceph RBD à Proxmox

Si ceph.conf et la keyring sont déployés sur les nœuds, ajoutez le stockage RBD via l'interface Proxmox 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'UI 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 sécurité

Les snapshots sont quasi instantanés. Protégez une snapshot avant de créer des clones.

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

# Revenir en arrière si nécessaire (VM arrêtée)
rbd snap rollback vms/vm-100-disk-0@pre-upgrade

# Cloner depuis une 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

Surveillez la santé, l'espace et les états de récupération.

ceph -s
ceph df
ceph health detail
pvesm status

Pour une maintenance planifiée:

# Éviter le rebalancing si vous arrêtez des OSD volontairement
ceph osd set noout
# ...maintenance...
ceph osd unset noout

Exemples pratiques

Exemple 1: Mettre en service un nouveau pool et l'attacher à Proxmox

Objectif: obtenir un pool vms opérationnel pour des VMs non critiques.

# Créer le pool et définir la taille de réplication
ceph osd pool create vms 64
ceph osd pool set vms size 3

# Vérifier les placement groups
ceph -s

Ajoutez-le à Proxmox via storage.cfg ou l'interface. Confirmez que Proxmox voit le stockage: Datacenter -> Storage -> 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
# Pour rollback (alimentation coupée ou disque non utilisé)
rbd snap rollback vms/vm-101-disk-0@before-change

Exemple 3: Image « golden » et clones vers plusieurs VMs

Transformez un disque de VM préparé en snapshot dorée, puis clonez rapidement:

# Assurez-vous que l'image de base est arrêtée et cohérente
rbd snap create vms/vm-200-disk-0@gold
rbd snap protect vms/vm-200-disk-0@gold
# Créer des clones pour de 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, envisagez de « flatten » les clones lourds pour réduire la dépendance au parent:

rbd flatten vms/vm-201-disk-0

Exemple 4: Vérifications rapides de performance

Établissez une baseline du pool avec rados bench quand les VMs sont calmes:

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

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

rbd status vms/vm-101-disk-0

Contrôlez le réseau et la distribution de charge OSD:

ceph osd df
ceph osd tree

Les bases de performance qui comptent

Le réseau d'abord: gardez la latence basse et cohérente; vérifiez la MTU de bout en bout si vous utilisez des jumbo frames.
Taille de réplication: size=3 est courant. Ne définissez jamais min_size trop bas au risque de servir les données avec une redondance insuffisante.
Évitez la prolifération de pools. Moins de pools avec le bon nombre de PG vaut mieux que trop de petits pools.
Commencez avec librbd (krbd=0). Utilisez krbd seulement pour des cas spéciaux; librbd facilite des fonctionnalités comme la migration à chaud.
Surveillez la plénitude du pool: les flags nearfull et full bloquent les écritures. Gardez de la marge (par ex. évitez de dépasser ~80% sans plan clair).
Mesurez avec des profils réalistes. rados bench teste le cluster; pour des profils type VM, fio dans une VM peut aider, mais évitez en période de pointe.

Modes de panne courants et à quoi faire attention

OSD en panne ou instable
Symptômes: données dégradées, recovery/backfill actifs, IOPS en baisse.
Vérifs: ceph -s, ceph osd tree, journaux ou santé des périphériques.

Perte de quorum des moniteurs
Symptômes: les clients n'obtiennent plus les cartes du cluster; erreurs sévères.
Vérifs: ceph quorum_status, nombre impair de MON et stabilité réseau.

Pool plein ou nearfull
Symptômes: écritures bloquées; VMs figées sur les E/S.
Vérifs: ceph df, ceph health detail pour les flags full/nearfull. Libérez de l'espace ou ajoutez de la capacité.

Partition réseau ou MTU incohérente
Symptômes: timeouts intermittents, requêtes lentes, churn osdmap fréquent.
Vérifs: MTU cohérente, ping/iperf entre nœuds, logs des MON/OSD.

Comptage PG mal dimensionné
Symptômes: hotspots, utilisation OSD déséquilibrée.
Vérifs: ceph pg dump, ceph osd df. Ajustez prudemment et anticipez l'impact du backfill.

Problèmes de mapping côté client
Symptômes: une VM ne démarre pas ou n'attache pas le disque; erreurs d'AUTH.
Vérifs: permissions de la keyring, exactitude de storage.cfg, reachability de monitor_host.

Contrôles opérationnels sûrs avant et après les changements

Exécutez cette checklist compacte avant des opérations risquées (mises à jour, 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  # pas de recovery/backfill massif en cours

Visibilité du stockage Proxmox

pvesm status | grep ceph-vms

Garde-fous optionnels de maintenance

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

Plan pilote local

Démarrez petit, mesurez, puis n'étendez qu'après avoir validé vos critères de sortie.

Portée

3 nœuds Proxmox qui hébergent aussi des MON Ceph et 1-2 OSD chacun
1 pool répliqué vms avec size=3
2 VMs de test: une généraliste, une orientée E/S

Signaux de réussite

Les disques de VM tournent sur Ceph RBD avec une 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

Baseline: rados bench sur un cluster au repos
Charge: fio dans une VM (4k randrw et 1M seq write simples)
Observation: ceph -s pendant les tests; notez les slow requests ou recovery

Critères de sortie

Pas de HEALTH_WARN en charge normale pendant au moins 48 heures
Pool sous 70% d'usage pendant les tests
Migration à chaud réussie pour les deux VMs de test

Étapes suivantes du déploiement

Ajoutez de la capacité ou affinez les réseaux si les objectifs ne sont pas atteints
Documentez les procédures standard pour snapshots et maintenance

Conclusion

Ceph RBD s'intègre proprement à Proxmox Ceph pour fournir des disques de VM partagés, en provisioning fin, avec snapshots et clones rapides. Commencez par un pool répliqué simple, connectez-le à Proxmox VM storage, et validez avec un petit pilote avant de monter en charge. Gardez des réseaux prévisibles, surveillez santé et capacité, et utilisez les snapshots de manière réfléchie.

Actions suivantes

Construisez le pool vms et attachez-le à Proxmox
Créez une VM de test, faites une snapshot avant les changements, et entraînez-vous au rollback
Exécutez les contrôles opérationnels sûrs avant toute maintenance
Augmentez la capacité uniquement après validation des critères de sortie