Le stockage distribué de niveau Datacenter : Monter un cluster de stockage haute disponibilité avec Ceph et Proxmox VE

Pourquoi Ceph + Proxmox VE est devenu le « standard » du stockage distribué en datacenter

On vit une époque drôle, côté infra. On nous demande du stockage qui ne tombe jamais, qui grossit sans douleur, qui ne coûte pas un rein, et qui continue de servir des IOPS même quand un serveur décide de partir en fumée un mardi à 14h. Et pendant longtemps, la réponse « datacenter » classique, c’était SAN ou NAS. Très bien. Très solide. Jusqu’au moment où... ça ne l’est plus.

Ceph avec Proxmox VE s’est imposé parce que ça répond à la promesse la plus simple et la plus importante en prod : enlever le point de défaillance unique. Et pas juste « mettre deux contrôleurs » dans une baie. Non. Répartir les données, les métadonnées et l’accès réseau sur plusieurs nœuds. Et si un élément sauté, le service continue. Plus lentement parfois, oui. Mais il continue.

Quand ce couple est pertinent ? Dès que vous avez :

• de la virtualisation (VM) sur plusieurs hôtes,
• un cluster HA Proxmox,
• des conteneurs qui doivent redémarrer ailleurs sans vous demander la permission,
• ou juste un besoin de grandir en ajoutant des nœuds et des disques, pas en remplaçant toute la baie.

Dans cet article, on va faire le tour de bout en bout : architecture Ceph sans jargon pénible, design HA, checklist datacenter, formation du cluster Proxmox, déploiement Ceph depuis Proxmox, création des pools RBD, validation de la haute dispo, pièges perf, supervision, maintenance, et enfin sécurité et sauvegardes. Oui, Ceph est résilient. Non, Ceph n’est pas un backup. On y revient.

Le problème avec les stockages « classiques » (et pourquoi ça casse à l’échelle)

Le stockage traditionnel « centralisé » a un défaut structurel : il centralise. Même avec redondance interne, vous avez souvent un endroit où ça se décide, et ça se sature.

Les goulots d’étranglement qu’on croise tout le temps :

• contrôleurs SAN qui plafonnent, ou qui se met à tousser quand on active trop de fonctionnalités,
• liens FC ou iSCSI qui deviennent le plafond de verre, surtout quand on augmente le nombre d’hôtes,
• une baie unique, donc une maintenance qui ressemble à une opération chirurgicale avec un planning à 3 semaines,
• des « features » qui impliquent une fenêtre de maintenance disruptive, parce que « c’est comme ça ».

Et puis il y a les coûts cachés. Ceux qu’on oublie sur le devis initial mais qui arrivent ensuite, tranquillement :

• licences, options, modules, add ons,
• support obligatoire,
• évolutivité par paliers, vous devez racheter un tiroir complet, ou changer de gamme,
• renouvellement matériel imposé par le constructeur, même si vos disques vont bien.

Opérationnellement, ça donne aussi des risques : migrations complexes, dépendances vendor, projets « on va bouger les LUN ce week end » qui finissent à 4h du matin avec des sueurs froides.

Ceph change le modèle : software defined, montée en charge incrémentale, tolérance aux pannes native. Vous ajoutez des OSD, de la capacité, du débit, et vous laissez le cluster rebalancer. Ce n’est pas magique. Mais c’est un autre monde.

Comprendre l’architecture Ceph (sans jargon inutile)

Ceph, en vrai, se comprend assez vite si on le découpe en briques simples.

Les briques principales : MON, OSD, MGR

• MON (monitors) : c’est le « cerveau de cohérence ». Les MON maintiennent la carte du cluster, qui est présent, qui est down, quelles règles s’appliquent. Ils doivent être en quorum. Typiquement 3.
• OSD (object storage daemons) : ce sont les travailleurs. Un OSD correspond en pratique à un disque (ou un device) qui stocke des objets. C’est là que vos données vivent réellement.
• MGR (manager) : c’est la partie pilotage et observabilité. Modules, métriques, dashboard, orchestration de certaines fonctions. On en met au moins 2 pour avoir actif et standby.

Si vous retenez une phrase : MON pour décider, OSD pour stocker, MGR pour gérer et observer.

CRUSH : comment Ceph place les données

CRUSH est l’algorithme qui choisit où placer les données en fonction d’une topologie. Et c’est là que Ceph devient très « datacenter ». Vous pouvez dire : « je veux que mes réplicas soient sur des hôtes différents », ou même « sur des racks différents ». Et Ceph suit cette règle.

Ça sert à quoi ? À éviter la catastrophe classique : vous perdez un serveur, et en fait vous perdez aussi deux copies parce qu’elles étaient sur le même châssis. Avec CRUSH bien pensé, ça n’arrive pas.

Pools et PG : pourquoi c’est important

Un pool est une zone logique de stockage avec des règles : réplication ou erasure coding, règle CRUSH, quotas, etc.

Les PG (placement groups), c’est le mécanisme qui répartit la charge et les objets dans le cluster. Trop peu de PG, vous avez des hotspots. Trop de PG, vous chargez les MON et vous rendez le cluster nerveux. Bonne nouvelle : aujourd’hui, l’autoscaler aide beaucoup. Mais il faut le comprendre au moins un minimum, pour éviter de « tuner » au hasard.

Les interfaces : RBD, CephFS, RGW

• RBD (block) : c’est ce qu’on veut pour Proxmox et les VM. Disques virtuels, snapshots, perf.
• CephFS (file) : intéressant pour du partage de fichiers, certains workloads applicatifs. Moins central pour Proxmox VM pur.
• RGW (object) : compatible S3, utile pour backup objet, archivage, applications.

Dans un cluster Proxmox classique : on commence par RBD. Le reste vient après, si vous avez un cas d’usage clair.

Design du cluster : viser la HA sans se tirer une balle dans le pied

Le design, c’est là que beaucoup gagnent ou perdent leur cluster. Parce que Ceph pardonne certaines erreurs. Mais pas toutes. Et surtout, il peut « marcher » tout en étant une bombe à retardement.

Nombre de nœuds recommandé

Le minimum réaliste, c’est 3 nœuds. Pour le quorum MON, et pour tolérer la perte d’un nœud sans arrêter le service. Deux nœuds, c’est possible avec des bricolages (tie breaker), mais ce n’est plus vraiment la philosophie, et en prod c’est rarement une bonne idée.

À 3 nœuds : vous pouvez perdre 1 nœud, rester en service, puis reconstruire. À condition que vos règles de réplication et vos capacités le permettent.

Règles de placement et anti affinité

Ceph doit placer les réplicas sur des domaines de panne différents :

• au minimum par hôte,
• idéalement par rack si vous avez plusieurs racks,
• et si vous êtes très sérieux, par salle, mais là on parle multi sites et c’est une autre histoire.

Le but : une panne électrique de rack ne doit pas emporter toutes les copies d’un même objet.

Dimensionnement simple

Quelques repères qui évitent des surprises :

• CPU/RAM : un nœud OSD chargé consomme. Compression, scrubs, checksums, chiffrement éventuel, backfill. Si vous êtes trop juste, la latence explose sous incident.
• Disques : HDD pour capacité et stockage froid. SSD ou NVMe pour performance. Et pour des VM « IOPS hungry », le tout HDD est souvent une déception.
• WAL/DB : avec BlueStore, placer DB/WAL sur SSD/NVMe peut transformer le ressenti, surtout si les data sont sur HDD.

Réseau

Le réseau est souvent le vrai facteur limitant.

• 10GbE est un bon minimum en 2026 pour une petite prod.
• 25GbE devient vite logique dès qu’on met de la VM dense.
• Séparer réseau public et cluster est idéal. Sinon, au minimum VLAN dédiés et QoS raisonnable.

Les jumbo frames ? Oui, mais seulement si vous maîtrisez. MTU incohérente, c’est le genre de détail qui vous fait perdre une journée.

RPO/RTO : ce que Ceph garantit, et ce qu’il ne garantit pas

Ceph garantit la disponibilité et la durabilité selon la règle (réplication, EC). Il ne garantit pas que vous êtes protégé contre :

• suppression accidentelle,
• corruption logique,
• ransomware,
• bug applicatif qui écrit n’importe quoi partout.

Donc : backup obligatoire.

Prérequis concrets avant de commencer (checklist datacenter)

Avant même de cliquer sur « Create Ceph Cluster », il faut une base propre. Sinon vous allez déboguer des symptômes, pas des causes.

Matériel

• Serveurs homogènes si possible. Mélanger des générations, ça marche, mais ça complique.
• Contrôleur disque en mode IT/HBA, pas de RAID matériel pour les disques OSD.
• Disques dédiés aux OSD. Pas de partitionnement créatif, pas de RAID5 hardware « pour aider ».

Stockage système vs OSD

Séparez l’OS des disques de données.

• OS sur SSD miroir (ZFS mirror ou RAID1, selon votre standard),
• OSD sur disques dédiés.

Ça simplifie tout : remplacements, réinstallations, et surtout on évite de détruire un OSD en réinstallant l’hyperviseur.

Réseau

• Liens redondants, LACP ou MLAG si dispo.
• Plan IP clair, DNS et NTP obligatoires. Un cluster sans NTP propre, c’est une source de problèmes subtils.
• Switchs capables de tenir la charge. Le « 10G pas cher » avec buffers faibles… ça se voit.

Sécurité et accès

• SSH maîtrisé, comptes admin, gestion des clés.
• Pare feu : ouvrez uniquement ce qui est nécessaire pour Proxmox et Ceph, idéalement par zones réseau.
• Segmentation : trafic de management, trafic VM, trafic Ceph. Même si c’est sur les mêmes liens physiques, séparez logiquement.

Préparation Proxmox

• Version Proxmox VE cohérente sur tous les nœuds.
• Dépôts configurés, mises à jour faites, reboot si nécessaire.
• /etc/hosts

Installer et former le cluster Proxmox VE (base saine avant Ceph)

On pose d’abord la brique compute. Ceph s’intègre à Proxmox, mais si Proxmox cluster est bancal, tout ce qui suit sera… sport.

Créer le cluster Proxmox

Sur le premier nœud : création du cluster. Puis jointure des autres nœuds. Ensuite, vérifiez le quorum côté Proxmox. Pas « ça ping », non. Quorum, état des communications, latence.

Configurer le réseau Proxmox

Créez vos bridges, vos VLAN, et idéalement une interface dédiée au trafic stockage. Même si physiquement c’est la même carte, le fait de séparer le flux aide à diagnostiquer, à prioriser, à comprendre.

Activer la HA côté Proxmox

La HA Proxmox gère le redémarrage des VM sur un autre nœud en cas de panne. Elle s’appuie sur le cluster. Et derrière, il y a une notion importante, même si on reste conceptuel ici : le fencing. En clair : éviter le split brain, s’assurer qu’un nœud supposé mort ne continue pas à écrire.

Bonnes pratiques

• Mises à jour contrôlées, pas « apt full-upgrade en prod à midi ».
• Sauvegarde de la config Proxmox.
• Versions cohérentes entre nœuds.

Déployer Ceph depuis Proxmox : MON, MGR, puis OSD (pas à pas)

Proxmox rend l’installation de Ceph franchement accessible. Mais il faut garder la tête froide et suivre un ordre logique.

Initialiser Ceph via l’interface Proxmox

Dans l’UI Proxmox : installation des paquets Ceph, puis création du cluster Ceph. On vous demande les réseaux : public et éventuellement cluster. Prenez le temps de bien choisir. Une erreur ici, c’est une dette technique immédiate.

Déployer les MON

Déployez 3 MON, sur 3 nœuds distincts. Vérifiez ensuite le quorum. Tant que le quorum n’est pas stable, on ne passe pas à la suite. Ce n’est pas négociable.

Déployer les MGR

Mettez au moins 2 MGR. Actif et standby. Le gain est simple : observabilité, modules, dashboard, et pas de trou noir si le MGR actif tombe.

Créer les OSD

Sélection des disques. BlueStore est le standard aujourd’hui. Si vous avez des SSD ou NVMe pour DB/WAL, c’est le moment de les affecter correctement. Sinon, Ceph fonctionnera, mais vous laissez de la perf sur la table.

Vérifications immédiates

Juste après :

• état du cluster : viser HEALTH_OK,
• latence et charge,
• capacité totale,
• répartition des OSD.

Et surtout, regardez si Ceph commence déjà à se plaindre. Warnings de clock skew, réseau instable, disques lents. Ce sont des signaux précoces.

Créer les pools RBD pour les VM : réglages qui comptent vraiment

On arrive au concret Proxmox : les disques VM.

Créer un pool RBD dédié aux VM

rbd

Réglages importants :

• size
• min_size
• règle CRUSH (par hôte, par rack si possible).

size

size=3

size=2

En performance, plus de réplicas signifie plus d’écritures. Donc plus de coût en write. Mais en lecture, ça peut aider selon le placement et les clients.

PG autoscaler

Activez l’autoscaler, surveillez le comportement. L’idée est d’éviter les réglages extrêmes. Un cluster qui change violemment de PG en pleine charge, ça se ressent.

Options utiles

Selon votre version : compression, quotas, conventions de nommage propres. Ne faites pas un zoo. Un cluster Ceph, ça vit longtemps, et un naming propre vous évite des erreurs humaines bêtes.

Brancher le stockage Ceph à Proxmox

Ajoutez le stockage RBD dans Proxmox, configurez l’authentification CephX, puis testez. Créez un disque VM, lancez une VM, faites un petit test d’I/O. Même basique. L’objectif est de valider l’intégration maintenant, pas le jour où vous migrez 30 VM.

Haute disponibilité : ce que la HA Proxmox + Ceph fait (et comment la valider)

Il faut être clair sur la promesse.

• Ceph assure la disponibilité du stockage.
• Proxmox HA assure la disponibilité du compute (redémarrage des VM ailleurs).

degraded

Tests recommandés

Oui, il faut tester. En conditions contrôlées.

• couper un nœud (proprement, puis brutalement si vous osez),
• simuler la perte d’un OSD,
• degradedbackfill
• vérifier que les VM repartent, et que les services applicatifs reviennent.

Paramètres à connaître

nooutnorebalance

Le point non négociable

Monitoring et alerting. Sans ça, la HA devient un faux sentiment de sécurité. Un cluster peut « tourner » en dégradé pendant des jours. Jusqu’au moment où la deuxième panne arrive. Et là, c’est trop tard.

Performance en production : les pièges les plus fréquents (et comment les éviter)

Ceph peut être très performant. Mais il est impitoyable avec les designs approximatifs.

Réseau sous dimensionné

Symptômes :

• latence RBD qui monte,
• VM qui ont de l’IO wait,
• backfill qui mange tout.

Solutions :

• passer en 10GbE minimum, 25GbE si densité,
• séparer trafic, au moins en VLAN,
• tuning MTU uniquement si vous savez vérifier bout en bout.

Disques mal choisis

Mettre des VM très actives sur HDD, c’est possible. Mais l’expérience utilisateur est souvent mauvaise. Et sans SSD pour DB/WAL, ça empire.

Évitez aussi les mélanges trop exotiques : HDD 7200 anciens avec SSD récents, firmwares disparates, latences différentes. Ceph suit le plus lent.

CPU/RAM OSD

Sous charge et pendant les scrubs ou recovery, ça tape. Si vous dimensionnez au strict minimum, le cluster sera « ok » en normal, puis instable en incident. Or c’est précisément en incident qu’on veut tenir.

Réglages côté VM

Dans Proxmox :

• drivers VirtIO SCSI, queue depth cohérente,
• options de cache réfléchies, pas au hasard,
• discard/TRIM si votre politique l’accepte.

Ce n’est pas glamour, mais ça change la vie.

Backfill et recovery

Planifiez. Limitez si nécessaire. Le rebuild peut tuer la prod si vous laissez Ceph récupérer à fond pendant les heures de pointe. Il vaut mieux récupérer un peu plus lentement et garder les applis vivantes.

Supervision et maintenance : garder un cluster sain sur la durée

Ceph n’est pas « set and forget ». En échange, il vous donne de la résilience. Mais il faut l’exploiter correctement.

Indicateurs à suivre

• HEALTH
• taux d’utilisation, nearfull, full ratios,
• latence côté OSD et côté client,
• scrubs, deep scrubs, et erreurs,
• taux de recovery et durée des backfills,
• SMART des disques, erreurs médias.

Outils

Le dashboard Ceph est utile, les logs aussi. Et dès que c’est sérieux : Prometheus et Grafana. Même à un niveau conceptuel, l’idée est simple : grapher la latence, les IOPS, la bande passante, et déclencher des alertes avant l’incident.

Scrubbing

Le scrub vérifie l’intégrité. Oui, ça consomme. Non, ce n’est pas un truc à désactiver « pour aller plus vite ». Ajustez les plages horaires si besoin, mais gardez la vérification. Ceph est un système distribué, l’intégrité est la base.

Mises à jour

Stratégie rolling upgrade, nœud par nœud, en vérifiant les compatibilités Proxmox et Ceph. Et surtout : ne faites pas l’impasse sur les release notes. Ce conseil a l’air banal. Il ne l’est pas.

Gestion des disques

Procédure typique :

• out
• laisser rebalancer,
• remplacer le disque,
• recréer l’OSD,
• HEALTH_OK

Documentez. Refaites la procédure en exercice. Le jour où ça arrive à 2h du matin, vous voulez suivre une checklist, pas votre mémoire.

Sécurité, sauvegardes et reprise : Ceph n’est pas un backup

C’est le rappel que tout le monde connaît… et que beaucoup oublient quand le cluster est stable depuis 6 mois.

La réplication protège contre une panne matérielle. Elle ne protège pas contre :

• suppression,
• chiffrement ransomware,
• corruption logique,
• erreur humaine.

Approche recommandée

Sauvegardes Proxmox avec Proxmox Backup Server (PBS), et une vraie stratégie 3 2 1.

• 3 copies,
• 2 supports différents,
• 1 copie hors site ou au moins hors domaine de panne.

Si vous pouvez ajouter de l’immutabilité, faites le. Ça change la donne.

Snapshots

Snapshots RBD, snapshots VM. Très utile pour un rollback court, un test, une opération risquée. Mais ça ne remplace pas une politique de sauvegarde. Un snapshot vit dans le même cluster. Donc il vit dans le même risque.

Chiffrement et contrôle d’accès

• En transit : segmentation réseau, et si vous chiffrez, mesurez l’impact.
• Au repos : possible selon options et design, mais attention aux coûts CPU et aux procédures de récupération.
• CephX : utilisez le contrôle d’accès, évitez les clés partagées partout.

Plan de reprise

Le plan, ce n’est pas « on restaurera ». C’est :

• restaurer une VM, chrono en main,
• reconstruire un nœud,
• savoir réinstaller proprement et réintégrer,
• documentation à jour,
• tests réguliers.

Conclusion : le « cheat sheet » pour monter un cluster Ceph + Proxmox fiable

Si vous deviez repartir avec une checklist courte, la voilà.

1. 3 nœuds minimum pour un cluster sérieux, quorum MON et tolérance de panne.
2. Réseau solide : 10GbE minimum, 25GbE si densité. Séparez les flux si possible.
3. Disques dédiés aux OSD, pas de RAID matériel, OS séparé des données.
4. size
5. Testez la panne : nœud down, OSD down, et observez le retour à l’état sain.
6. Monitoring et alerting obligatoires, sinon vous pilotez à l’oreille.
7. Upgrades prudents : rolling, compatibilités vérifiées, pas d’impro.
8. Backups réels : PBS, 3 2 1, et idéalement immutabilité.

degradedbackfillsize

Mais évitez de complexifier trop tôt. Ceph est puissant. Et comme tout ce qui est puissant, ça mérite un design simple, clair, et bien opéré.

Questions fréquemment posées

Pourquoi Ceph associé à Proxmox VE est-il devenu le standard du stockage distribué en datacenter ?

Ceph avec Proxmox VE s'est imposé comme standard car il élimine le point de défaillance unique en répartissant données, métadonnées et accès réseau sur plusieurs nœuds. Ainsi, même en cas de panne d'un serveur, le service continue, garantissant haute disponibilité et scalabilité sans coût exorbitant.

Quels sont les principaux inconvénients des solutions de stockage traditionnelles comme SAN ou NAS ?

Les solutions classiques centralisent le stockage, ce qui crée des goulots d'étranglement au niveau des contrôleurs, liens FC/iSCSI et baies uniques. Elles impliquent aussi des coûts cachés (licences, support), une évolutivité limitée (achat par paliers) et des maintenances souvent longues et disruptives.

Quelles sont les briques essentielles de l'architecture Ceph et leurs rôles ?

Les briques principales sont : MON (moniteurs) qui maintiennent la cohérence et la carte du cluster ; OSD (object storage daemons) qui stockent réellement les données sur les disques ; MGR (managers) qui gèrent l'observabilité, métriques et orchestrations. Ensemble, ils assurent un stockage distribué résilient.

Comment Ceph garantit-il la haute disponibilité dans un environnement virtualisé avec Proxmox ?

Ceph répartit les données sur plusieurs nœuds avec réplicas pour éviter tout point de défaillance unique. En cas de panne d'un nœud, les autres continuent à servir les données. Associé à un cluster HA Proxmox, cela permet aux machines virtuelles et conteneurs de redémarrer automatiquement ailleurs sans interruption majeure.

Qu'est-ce que l'algorithme CRUSH dans Ceph et pourquoi est-il important ?

CRUSH est l'algorithme qui détermine dynamiquement où placer les données dans le cluster selon une topologie définie. Cela évite la centralisation, optimise la distribution des objets sur les OSDs et assure une montée en charge fluide ainsi qu'une tolérance native aux pannes dans un environnement datacenter.

Ceph remplace-t-il les sauvegardes traditionnelles ?

Non, bien que Ceph soit résilient et tolérant aux pannes, il ne remplace pas une stratégie de sauvegarde classique. Il assure la continuité du service en cas de défaillance matérielle mais ne protège pas contre la suppression accidentelle ou la corruption des données. Des sauvegardes régulières restent indispensables.