Déployer Ceph avec Proxmox : architecture MON/OSD/MGR, groupes de placement et dépannage des performances

Ceph avec Proxmox est une combinaison répandue dans les infrastructures virtualisées. Dans cet article, je décris de manière pragmatique comment planifier les MON/OSD/MGR, dimensionner correctement les Placement‑Groups (PGs) et diagnostiquer et résoudre systématiquement les problèmes de performance. Le mot‑clé focal Ceph avec Proxmox est intentionnellement placé tôt : l’intégration influe sur l’exploitation, la supervision, la migration et le respect des SLA.

Pourquoi la planification d’architecture est importante pour Ceph

Avant d’intégrer Ceph dans Proxmox, vous devez comprendre les responsabilités des composants. En résumé : les MONs (moniteurs) gèrent le quorum du cluster et la configuration ; les OSDs (Object Storage Daemon) stockent les données et effectuent la réplication et le scrubbing ; les MGRs (manager) fournissent le tableau de bord, l’API et les métriques. Cette séparation des tâches détermine les choix matériels, réseau et d’exploitation — et donc la performance et la tolérance aux pannes.

Règles de base pour l’agencement des MON/OSD/MGR

La répartition des MONs, OSDs et MGRs influence la stabilité et la maintenabilité. Règles de base :

• MONs : Toujours un nombre impair (au moins 3) pour la résilience du quorum ; les MONs sont peu gourmands, mais nécessitent un accès réseau stable.
• OSDs : Répartissez les OSDs sur plusieurs hôtes et domaines de défaillance (hôte, rack) ; les OSDs sont critiques pour l’I/O et constituent le goulot d’étranglement du système.
• MGRs : Au moins deux instances de manager pour la redondance du tableau de bord et des exporteurs ; la perte d’un MGR affecte principalement l’observabilité, pas la cohérence.

Recommandation pour des clusters typiques

Pour des installations Proxmox petites à moyennes (6–20 nœuds), une configuration possible : 3 MONs sur des hôtes séparés, 2 MGRs répartis, et distribuer les OSDs de façon à avoir au moins trois OSDs par domaine de défaillance. Évitez la co‑localisation des MON/MGR avec tous les OSDs d’un même rack afin de réduire le rayon d’impact.

Ceph avec Proxmox : mesures réalistes d’optimisation des performances

L’optimisation des performances commence par la mesure. Les goulets d’étranglement de Ceph ne se comprennent qu’avec des métriques, des profils I/O et des tests contrôlés. Les domaines typiques sont le réseau, les périphériques OSD, le CPU/la mémoire sur les OSDs et la configuration des PG (Placement‑Groups, groupes de distribution logiques).

Configurations Ceph importantes et leur effet

• osd_memory_target (Ceph) : Contrôle de l’empreinte RAM des structures de cache OSD — trop bas → chute de performance, trop élevé → pression mémoire. Valeurs dépendantes de la RAM OSD et du nombre de PG.
• osd_recovery_max_active / osd_recovery_op_priority : Limitent les tâches de récupération parallèles, réduisent temporairement la charge de backfill, mais allongent le temps de récupération.
• osd_max_backfills : Limitation des backfills parallèles par OSD ; utile en cas de saturation réseau.

Recommandations (conservatrices)

Commencez avec des valeurs par défaut conservatrices et ajustez progressivement. Exemples de valeurs à tester :

# Beispiel: vorsichtigere Recovery‑Limits setzen
ceph config set osd osd_recovery_max_active 2
ceph config set osd osd_max_backfills 1
# Memory‑Target nach OSD‑RAM anpassen (Beispiel 8GB RAM)
ceph config set osd osd_memory_target 5368709120 # 5GB

Pourquoi : ces réglages réduisent la pression d’I/O simultanée sur le réseau et le CPU, évitent les pics de latence à court terme et sont réversibles. Testez et documentez chaque modification.

Placement‑Groups (PGs) : concept, calcul et pg_autoscaler

Les Placement‑Groups regroupent des objets et constituent l’unité atomique que CRUSH distribue aux OSD. Le nombre de PG influence la distribution des données, la taille du rebalancing et l’empreinte mémoire des OSD.

Approche de calcul et exemple pratique

Règle empirique : 50–200 PGs par OSD ; une formule simplifiée :

target_pgs = (osd_count * pgs_per_osd) / replication_size

Exemple : 12 OSDs, repl_size=3, pgs_per_osd=100 → target_pgs = (12*100)/3 = 400 → choisissez 256 ou 512 (une puissance de 2 est souvent recommandée). Les versions récentes de Ceph proposent pg_autoscaler, qui ajuste progressivement le nombre de PG — vérifiez la compatibilité avec votre version de Proxmox.

pg_autoscaler : avantages et inconvénients

pg_autoscaler automatise les ajustements et réduit les erreurs humaines. Inconvénients : sur les versions plus anciennes, il peut provoquer des rebalancings indésirables ; activez‑le uniquement après avoir vérifié la version et le comportement.

CRUSH‑Map, Failure Domains et Device Classes

La CRUSH‑Map détermine le placement physique. Définissez clairement les failure‑domains (p. ex. host, rack) et les Device‑Classes (ssd/hdd) afin que les policies (p. ex. placement séparé pour un tier SSD) s’appliquent. Une CRUSH‑Map incorrecte entraîne une distribution inégale et augmente le trafic lors d’une défaillance.

Scrubbing, Backfilling et Recovery : différences et règles d’exploitation

Le scrubbing (vérification des règles d’intégrité des données) est une activité planifiée ; le deep‑scrub examine le contenu de manière plus approfondie. Le backfilling désigne la copie de données après ajout/suppression d’OSD. La recovery est la restauration synchronisée après des pannes. Ces processus sollicitent différemment l’I/O et le réseau — prévoyez des fenêtres de maintenance et imposez des limites sur les tâches parallèles.

Résolution de problèmes de performance : runbook d’incident systématique

En cas d’incident de performance, suivez une procédure structurée : d’abord mesurer, ensuite intervenir, ne jamais modifier globalement la configuration à l’aveugle.

Mesures immédiates (premières 10 minutes)

1. Vérifier l’état du cluster :

ceph -s
ceph osd df tree
ceph pg stat
ceph osd perf

2. Vérifier les données réseau et les statistiques des switches (MTU, erreurs, drops).
3. Contrôler l’I/O des OSD : iostat, iotop, blktrace.
4. Surveiller les clients (I/O des VM Proxmox via iostat dans les VMs).

Interventions courantes et commandes

Si le backfill est la cause, limitez Recovery/Backfill :

# Temporär OSD Noout (Achtung: nur bei geplanter Wartung)
ceph osd set noout
# Drosseln
ceph config set osd osd_recovery_max_active 1
ceph config set osd osd_max_backfills 1
# Überwachen
ceph -w

Si la CPU/la mémoire des OSD est le goulot d’étranglement, vérifiez le nombre de PGs et osd_memory_target. Réduisez les PGs uniquement par étapes et surveillez la stabilité des OSD.

Procédure runbook concrète pour pics de latence critiques

1. Identifier : ceph osd perf, ceph pg dump | grep stuck/degraded.
2. Isoler : réduire temporairement les clients (QoS sur Proxmox), set noout en cas de maintenance.
3. Limiter : appliquer les valeurs recovery/backfill comme ci‑dessus.
4. Rechercher la cause : compteurs des switches, ethtool -S, iostat, dmesg pour erreurs de périphérique.
5. Réinitialisation progressive : lorsque la charge diminue, rétablissez les valeurs et observez le monitoring.

Tests et validation : fio comme outil

Validez les profils de stockage avec fio (simulation de patrons I/O). Exemple pour un mélange random R/W 4k :

fio --name=randrw --ioengine=libaio --direct=1 --rw=randrw --rwmixread=70 
    --bs=4k --numjobs=8 --size=1G --runtime=300 --group_reporting

Exécutez ces tests isolés sur une Test‑VM ou directement sur les OSD‑Devices ; interprétez les IOPS et la latence par rapport aux charges de travail attendues des Proxmox‑VMs.

Remplacement d’OSD : procédure sûre et retour arrière

Lors du remplacement d’un OSD, documentez au préalable l’état, mettez l’OSD out, surveillez la recovery jusqu’à stabilisation et créez des sauvegardes de la CRUSH‑Map et de l’état MON. Commandes d’exemple :

# OSD aus dem Cluster nehmen
ceph osd out 
# Überwachen
ceph -w
# Nach Austausch neu anlegen (Beispiel ceph-volume)
sudo ceph-volume lvm create --data /dev/sdb

Stratégie de repli : si le Replace échoue, vous pouvez remettre temporairement l’ancien Device et ré-attacher l’OSD ou ajuster la Weight‑Scale pour éviter un rebalancing incontrôlé.

Métriques, alertes et observabilité

Les modules MGR fournissent des métriques Prometheus. Les alertes prioritaires devraient être : ceph_health != OK, taux élevés de recovery/backfill, augmentation de la OSD‑latency, de nombreux PGs en STATE ‚active+undersized‘ ou ‚degraded‘. Des dashboards aident à visualiser les tendances et pas seulement les événements isolés.

Règles opérationnelles pratiques et pièges typiques

• Appliquez MTU/Jumbo‑Frames uniquement après un test de bout en bout ; des MTU incohérents provoquent fragmentation et pertes.
• Évitez le mode RAID sur les contrôleurs de stockage pour les OSDs ; HBA/Pass‑through réduit les latences inattendues.
• Modifications du nombre de PGs ou de la CRUSH‑Map toujours graduelles et accompagnées de sprints de monitoring.
• Planifiez les fenêtres de scrub et de deep‑scrub durant les périodes de faible I/O.

Liste de vérification avant mise en production

1. Compatibilité des versions Proxmox et Ceph vérifiée.
2. Réseaux Public/Cluster configurés, MTU vérifié.
3. Nombre et répartition des MON/MGR définis (min. 3 MONs, 2 MGRs).
4. Dimensionnement des OSD : classes de Devices, WAL/DB‑Devices planifiés.
5. Planification des PG : PG cibles calculés et validés en environnement de test.
6. Sauvegardes : workflow de backup MON/MGR/CRUSH‑Map établi.
7. Monitoring : modules MGR, Prometheus Exporter et alerting configurés.
8. Plans de rollback documentés et testés (OSD Replace, MON‑RESTore).

Conclusion : discipline opérationnelle plutôt que réglages magiques

Ceph avec Proxmox offre une grande scalabilité et de bonnes possibilités d’intégration dans des environnements virtualisés — à condition que l’architecture, le réseau et la planification des PG soient alignés. Commencez prudemment, mesurez les effets et optimisez progressivement. En cas de problèmes de performance, un contrôle structuré par couches (Hardware → Kernel → réseau → Ceph → client) et un bridage ciblé de la recovery/backfill aident. La documentation, le monitoring et des stratégies de repli testées réduisent les risques opérationnels et rendent le système prévisible.

Utilisez la checklist comme document opérationnel et complétez‑la par des liens internes vers des how‑tos approfondis (p. ex. Proxmox‑Upgrades, ZFS‑Design) afin de constituer un manuel d’exploitation complet.

Aspects opérationnels et d’intégration souvent négligés

Pour les déploiements Ceph dans Proxmox, le succès ne dépend pas seulement de la configuration pure du cluster, mais aussi de la manière dont vous intégrez le stockage aux processus opérationnels, aux sauvegardes et au change‑management. Ci‑dessous des aspects pragmatiques qui provoquent souvent des surprises en phase projet, ainsi que des recommandations concrètes.

Stratégie de sauvegarde et de snapshot pour les VMs

Les snapshots RBD sont rapides, mais ne remplacent pas une sauvegarde systématique. Utilisez les snapshots pour des points de consistance à court terme (p. ex. avant des patchs), mais exportez régulièrement des sauvegardes hors site (p. ex. export des données de VM ou utilisation d’un backend d’objets comme RGW/S3). Veillez à ce que les snapshots eux-mêmes génèrent de la charge d’E/S et qu’un grand nombre de snapshots puisse entraîner des dégradations de performance. Planifiez donc un intervalle de suppression et l’automatisation du nettoyage des snapshots.

Coordination mit Proxmox‑Funktionen

Assurez‑vous que les Storage Pools Proxmox (RBD) sont correctement taggés et que vous utilisez des contrôles d’admission pour le placement des VM afin d’éviter les hôtes Hot‑OSD. Définissez des règles empêchant la concentration de trop de VM à fort I/O sur des hôtes riches en OSD — cela réduit les risques de points chauds.

Sicherheits‑ und Compliance‑Layer

Activez le chiffrement des transports entre les services Ceph (mTLS) et envisagez le chiffrement des devices (dmcrypt) pour les données sensibles. Portez une attention particulière à la gestion des clés : les clés ne doivent pas être stockées seulement localement, mais référencées dans votre PKI/gestionnaire de secrets externe (p. ex. HashiCorp Vault). Documentez le processus de déchiffrement et de récupération afin que les équipes d’exploitation puissent s’y retrouver en cas d’urgence.

Upgrade‑ und Rollback‑Playbook

Un playbook formel de mise à niveau réduit les risques. Principes de base : mises à niveau par vagues, vérifications de santé (health‑checks) après chaque étape, timeouts conservateurs et une procédure de rollback définie. Testez la mise à niveau sur un environnement de réplication et conservez des sauvegardes des données d’état MON et MGR.

# Beispiel: Health‑Check vor Upgrade (Kurzversion)
ceph status --format=json | jq '.health'
ceph osd tree --format=json | jq '.nodes | length'

Automatisierung und Orchestrierung

Utilisez des outils d’orchestration (cephadm, Ansible) pour des déploiements reproductibles et des configurations documentées. Conservez les modifications de configuration Ceph dans un Git‑Repository et liez‑les à votre système de gestion des changements. Des tests automatisés (smoke‑checks après modifications de configuration) évitent des effets secondaires imprévus dans les pools en production.

Multi‑Site, Replikation und DR‑Szenarien

Si des exigences géoredondantes existent, prévoyez la réplication des buckets RGW ou le mirroring Ceph RADOS. De tels déploiements modifient drastiquement les exigences de latence et de bande passante ; testez la résilience de la réplication en simulant des pannes réseau et quantifiez les SLA de bande passante nécessaires pour les fenêtres de recovery.

Observability: sinnvolle Schwellenwerte und Alerts

Une alerte n’est utile que si elle déclenche une action. Définissez des responsables et des runbooks automatisés pour des alertes telles qu’une latence OSD en hausse, une augmentation du taux de backfill ou une dégradation des PG. Exemples de seuils pragmatiques :

• latency p95 > X ms pendant Y minutes → ouverture d’un ticket + application de paramètres limitant le recovery
• plusieurs OSD hors ligne simultanément → escalade immédiate
• PGs en degraded/stuck > 0 pendant Z minutes → vérifier le mode maintenance

Organisatorische Empfehlung

Élaborez un petit playbook opérationnel (2–3 pages) avec des checklists pour : contrôles de santé quotidiens, procédure de remplacement d’OSD, séquence de mise à niveau et étapes de rollback. Combinez ce playbook avec des automatisations techniques et des tests de chaos réguliers (erreurs contrôlées) — cela permet à vos équipes d’acquérir de la familiarité avec les procédures de recovery et d’intégrer la technologie de manière stable dans le quotidien de production.

Pour ce sujet, Mon Osd Mgr et la performance de Ceph sont également importants. L’article remet ces aspects en contexte de manière compréhensible et montre à quoi il faut prêter attention au quotidien.