Le stockage, épine dorsale de l’infrastructure
Dans une infrastructure d’hébergement moderne, le stockage est souvent le maillon critique. Un hyperviseur peut redémarrer en quelques secondes, mais une perte de données est irréversible. C’est là qu’intervient Ceph : un système de stockage distribué, open source, conçu pour éliminer tout point unique de défaillance.
Chez Datacampus, nous exploitons des clusters Ceph sur NVMe en réplication triple depuis plusieurs années. Cet article vous explique comment ça fonctionne, sans jargon inutile.
L’architecture RADOS : la fondation
Ceph repose sur RADOS (Reliable Autonomic Distributed Object Store), une couche de stockage objet qui gère automatiquement la distribution et la réplication des données. Trois types de démons composent un cluster :
| Composant | Rôle | Nombre minimum |
|---|---|---|
| OSD (Object Storage Daemon) | Stocke les données, gère la réplication, détecte les pannes | 3 (un par disque) |
| MON (Monitor) | Maintient la carte du cluster, consensus entre nœuds | 3 (nombre impair) |
| MDS (Metadata Server) | Gère les métadonnées pour CephFS uniquement | 1 actif + 1 standby |
| MGR (Manager) | Monitoring, dashboard, orchestration | 2 (actif/standby) |
Chaque OSD correspond généralement à un disque physique. Avec 12 disques NVMe répartis sur 3 serveurs, vous avez 12 OSD et une capacité de récupération même en cas de perte d’un serveur complet.
L’algorithme CRUSH : la distribution intelligente
Ce qui rend Ceph unique, c’est CRUSH (Controlled Replication Under Scalable Hashing). Contrairement à un système avec table de correspondance centralisée, CRUSH est un algorithme déterministe : chaque nœud peut calculer l’emplacement d’un objet sans consulter d’annuaire.
- Le client écrit un fichier → celui-ci est découpé en objets
- Chaque objet est assigné à un Placement Group (PG) via un hash
- CRUSH détermine sur quels OSD le PG doit résider, en respectant les règles de topologie
- Les données sont écrites simultanément sur les OSD primaire et secondaires
La CRUSH map définit la topologie : racks, serveurs, disques. On peut imposer que les réplicas ne soient jamais sur le même serveur, ni dans le même rack. Cette granularité est essentielle pour la résilience.
Réplication vs Erasure Coding
Ceph propose deux stratégies de protection des données :
Réplication (replica N)
- Chaque objet est copié N fois
- Replica 3 = 3 copies sur 3 OSD différents
- Coût : capacité utile = capacité brute / 3
- Performances : excellentes en lecture et écriture
- Idéal pour les VM et bases de données
Erasure Coding (k+m)
- Données découpées en k fragments + m fragments de parité
- Exemple EC 4+2 : tolère 2 pannes simultanées
- Coût : capacité utile = k/(k+m) de la capacité brute
- Performances : lectures rapides, écritures plus lentes
- Idéal pour l’archivage et les sauvegardes
Chez Datacampus, nos pools de stockage VM utilisent la réplication triple sur NVMe pour garantir performances et sécurité. Les pools d’archivage utilisent l’erasure coding pour optimiser la capacité.
RBD : le stockage en mode bloc pour les VM
RBD (RADOS Block Device) expose un volume bloc Ceph comme un disque virtuel. C’est le mode de stockage privilégié pour les machines virtuelles :
- Thin provisioning : un disque de 500 Go n’occupe que l’espace réellement écrit
- Snapshots instantanés : sauvegarde cohérente sans interruption de service
- Live migration : déplacement de VM entre hyperviseurs sans coupure, puisque le stockage est partagé
- Clone rapide : création d’une copie en quelques secondes via copy-on-write
CephFS : le système de fichiers distribué
Pour les besoins de stockage fichier partagé, Ceph propose CephFS : un système de fichiers POSIX distribué. Il nécessite le démon MDS pour gérer les métadonnées (arborescence, permissions, verrous).
CephFS est particulièrement adapté pour :
- Les partages réseau hautes performances
- Les environnements de développement avec accès fichier concurrent
- Les pipelines de traitement de données
Intégration avec Proxmox VE
Proxmox VE intègre nativement Ceph, ce qui simplifie considérablement le déploiement. Depuis l’interface web Proxmox, on peut :
- Installer et configurer les MON, OSD et MDS directement
- Créer et gérer les pools de stockage
- Surveiller l’état du cluster en temps réel
- Provisionner des disques RBD pour les VM en un clic
- Lancer des migrations à chaud sans configuration supplémentaire
Cette intégration élimine le besoin d’un SAN externe et de ses coûts de licence. Le stockage distribué fait partie intégrante de la plateforme de virtualisation.
Performances : le rôle du NVMe
Un cluster Ceph sur HDD tourne typiquement autour de 100-200 IOPS par OSD. Avec des NVMe, on atteint facilement 50 000 à 100 000+ IOPS par OSD, soit un facteur 500x.
| Métrique | Ceph HDD | Ceph NVMe |
|---|---|---|
| IOPS (4K random read) | ~150/OSD | ~80 000/OSD |
| Latence | 5-15 ms | 0.2-0.5 ms |
| Débit séquentiel | ~150 Mo/s/OSD | ~2 500 Mo/s/OSD |
| Temps de recovery (1 To) | Plusieurs heures | ~15-30 minutes |
Le temps de recovery est crucial : plus vite un cluster reconstruit ses données après une panne, plus vite il retrouve son niveau de résilience nominal.
Quand utiliser Ceph vs stockage local ?
Ceph n’est pas la réponse à tout. Voici un guide de décision :
- Ceph (distribué) : environnements de production multi-serveurs, haute disponibilité requise, migration à chaud indispensable, clusters de 3 nœuds minimum
- Stockage local : serveur unique, performances extrêmes requises (latence < 0.1 ms), environnements de test, budget limité
La règle est simple : si la perte d’un serveur ne doit pas impacter vos services, Ceph est la réponse.
Chez Datacampus, nos clusters Proxmox s’appuient sur Ceph NVMe en réplication triple. Chaque donnée existe sur trois disques, sur trois serveurs différents. La perte d’un serveur complet n’entraîne aucune interruption de service.
L’équipe Datacampus — hébergeur et infogérant français, entreprise à mission, basé au Futuroscope.