Support Ceph Support et conseil pour clusters Ceph en production. Pour OpenStack, Kubernetes ou Proxmox VE.
On nous appelle normalement pour trois choses : monter le cluster proprement dès le premier coup, récupérer celui qu'un autre a laissé à moitié fait, ou remplacer une baie SAN qui coûte désormais plus cher que le reste de l'infra. On couvre RBD, CephFS et RGW (S3) sur OpenStack, Kubernetes ou Proxmox VE.
Qu'est-ce que Ceph
et quand l'utiliser
Ceph tourne sur Linux et matériel x86 standard, et un même cluster vous donne du bloc (RBD) pour les machines virtuelles, des fichiers POSIX (CephFS) pour ce qu'on monte depuis cent endroits, et des objets S3 (RGW) pour la sauvegarde et l'état applicatif. Les données se répliquent entre serveurs ; un disque mort, un hôte mort, même une salle morte, la production continue.
C'est ce qui tient le cloud privé quand on décide de ne pas dépendre d'un hyperscaler, et ce qui a du sens quand votre baie SAN se remplit et que la suivante coûte plus qu'une voiture. On grandit en ajoutant des serveurs, pas en rachetant chez le même fournisseur.
SAP HANA certifié, non. Bases de données à latence sub-milliseconde stricte, non plus. Là, Ceph n'est pas la réponse et on vous épargne le projet. Pour presque tout le reste du datacenter — virtualisation, cloud privé, sauvegarde, S3 interne, conteneurs — ça colle.
Comment apprendre Ceph depuis zéro →
Projet officiel · ceph.io ↗ · Documentation technique ↗
Ce que nous couvrons dans Ceph
Toute la vie du cluster avec la même équipe : conception, migration depuis d'anciennes baies, tuning quand ça rame, et le tour de garde de 3 h du matin quand quelque chose tombe.
Ceph RBD
Le disque de vos VM, servi par Ceph au lieu d'une baie. Avec snapshots et clones en quelques secondes parce qu'ils sont en copy-on-write, pas des copies complètes. Parle nativement à Cinder, libvirt/KVM et Proxmox VE.
CephFS
Un système de fichiers POSIX qui se monte depuis cent machines à la fois sans qu'un serveur de métadonnées devienne le goulot. Quand quelqu'un demande "du NFS mais pour de vrai", c'est ce qu'on déploie. Comment le monter en haute dispo avec Ganesha →
Ceph RGW · Stockage objet S3
Un endpoint S3 qui pointe sur votre cluster, pas sur AWS. Bucket policies, IAM, versioning, cycle de vie. Veeam et IBM Storage Defender le voient comme un bucket lambda.
S3 · Swift · Veeam · IBM Defender Migration IBM COS vers Ceph object storage →Rook / Ceph CSI
Les pods ont besoin de volumes qui survivent au reschedule. Avec Rook Ceph vit dans le cluster K8s ; avec Ceph CSI il se branche sur un cluster externe. Les deux cas avec snapshots et RWX réel.
RWO · RWX · Snapshots CSICeph sur Proxmox VE
Trois nœuds avec calcul et stockage sur la même machine, sans acheter vSAN et sans licence par CPU. Proxmox intègre Ceph nativement ; on le dimensionne et on le règle pour qu'il tienne la production, pas juste les démos.
Alternative vSANCeph avec NVMe pour IA, HPC et analytique
Une heure de GPU coûte plus qu'un mois d'OSD ; le stockage ne peut pas être le goulot. Pools 100 % NVMe, réseau 100 GbE ou RDMA, et une CRUSH map pensée pour que les répliques ne se battent pas sur le même switch.
Ce que nous faisons exactement
Ingénieurs internes qui s'assoient avec votre équipe et connaissent votre cluster.
On commence par mesurer ce que le cluster fera vraiment, pas ce que dit le cahier des charges. Ça donne le nombre d'OSD, le ratio SSD:HDD, la topologie réseau et les règles de la CRUSH map. Déploiement en cephadm, et on ne valide qu'après que fio et rados aient reproduit les chiffres promis.
La vieille baie ne s'éteint que quand Ceph a servi la même donnée pendant plusieurs semaines. On déplace les charges par vagues — d'abord celles qui redémarrent facilement, puis celles de 3 h du matin — et on compare les checksums avant de débrancher le câble.
Ceph rend ce qu'on le laisse rendre. Quand ça rame, c'est presque toujours le réseau, la taille du PG, ou un pool mal équilibré ; presque jamais "Ceph est lent". On mesure, on change une chose à la fois, et on vous laisse les benchmarks pour que vous puissiez les rejouer.
Prometheus, Grafana et Ceph Dashboard branchés sur ce que vous avez déjà. On ne vous alerte pas à chaque scrub ; on vous alerte quand un OSD est en train de mourir ou quand la capacité va se manger le mur dans trois mois.
C'est celui qui nous appelle à 3 h du matin. PG inconsistants, monitors sans
quorum, OSD qui ne redémarrent pas, un upgrade coincé à moitié. Astreinte 24/7
avec SLA contractuel. Règle d'or : si le cluster est dégradé, ne touchez à rien
avant de nous parler.
L'erreur la plus courante et comment la corriger →
Temps de réponse
Cluster en lecture seule, perte de quorum des monitors, PG inaccessibles.
OSD tombés, dégradation des performances ou récupération en cours.
Revue d'architecture, tuning et recommandations proactives.
SLA et pénalités définis dans le contrat.
Quand Ceph gagne,
quand non
Aucune techno ne convient à tout. Voici les cas où Ceph résout, et ceux qu'on renverrait ailleurs même si le projet nous passait sous le nez.
| Ce qu'il faut résoudre | Ceph | Ce qu'on suggérerait à la place |
|---|---|---|
| Remplacer une baie SAN qui coûte plus qu'un renouvellement complet du matériel | Ça colle | — |
| Stockage persistant pour OpenStack ou Kubernetes | Modèle de référence | — |
| Bucket S3 interne sans passer par AWS | RGW résout | — |
| Cluster hyperconvergé sur Proxmox ou KVM sans licence par CPU | Combo mature | — |
| Sauvegarde et archivage longue durée avec Veeam ou Storage Defender | RGW S3 | — |
| Base de données à latence sub-milliseconde stricte | Ne forçons pas | NVMe local + réplication applicative |
| SAP HANA certifié par SAP | Non certifié | IBM FlashSystem ou autre baie certifiée SAP |
| Répertoires utilisateur d'un bâtiment (3-5 To, un seul site) | Surdimensionné | NFS classique ou petite baie |
Ceph voyage rarement
tout seul
Il arrive avec OpenStack au-dessus, ou avec Kubernetes. Souvent les deux. Ceux qui connaissent la couche du bas sont les mêmes qui supportent les couches du haut.
Stockage distribué : bloc pour VM, POSIX pour fichiers, S3 pour le reste. Ce qui porte tout ce qu'il y a au-dessus.
Vous êtes iciUn vrai cloud privé, hors hyperscaler. Nova, Neutron, Cinder et Glance sur Ceph. Formation dispo en attendant la landing de support.
Formation OpenStack →OpenShift, Rancher (k3s), Canonical, Talos. Les volumes persistants viennent de Ceph via Rook ou Ceph CSI.
Formation Docker & Kubernetes →Questions fréquentes sur Ceph
Ceph est une plateforme de stockage distribué open source qui tourne sur Linux et matériel standard. Un même cluster offre trois interfaces : bloc (RBD) pour VM et bases de données, fichiers POSIX (CephFS) pour charges partagées et objets compatibles S3 (RGW). Les données sont répliquées entre nœuds et le cluster tolère la panne de disques, serveurs ou salles entières si la conception le prévoit.
Quand vous voulez croître sans racheter une baie à chaque saturation, quand le coût de licence par To de votre fournisseur augmente plus vite que le business, ou quand vous avez besoin de S3 et de fichiers partagés en plus du bloc sans acheter trois produits distincts. Si votre charge principale est SAP HANA certifiée ou exige une latence sub-milliseconde stricte, Ceph n'est pas la réponse et nous vous le dirons.
Oui, et c'est une des combinaisons les plus matures. Proxmox VE intègre Ceph nativement, ce qui permet de monter des clusters hyperconvergés à partir de trois nœuds : calcul et stockage sur les mêmes machines, sans licence supplémentaire ni vSAN. Chez SIXE, nous concevons et réglons ce tandem pour la production, pas seulement pour la maquette.
Ceph est le stockage de référence des deux. Dans OpenStack, Cinder (bloc), Glance (images) et Manila (fichiers) le consomment nativement. Dans Kubernetes, il se déploie avec l'opérateur Rook ou avec Ceph CSI, et fournit des volumes persistants ReadWriteOnce et ReadWriteMany, snapshots et clones. Fonctionne avec OpenShift, Rancher (k3s), Canonical Kubernetes et Talos.
Un cluster utile en production commence à trois nœuds, le minimum pour maintenir le quorum des monitors et une règle de réplication x3. En dessous, Ceph fonctionne mais en laboratoire, pas comme système tolérant aux pannes. Six nœuds permettent des domaines de panne par rack, dix et plus relèvent des topologies d'entreprise.
Oui, avec une conception adaptée. Pour l'inférence et l'entraînement distribué, on monte des pools NVMe avec réseau haute vitesse (25/100 GbE ou plus) et on ajuste la configuration pour les IOPS et la bande passante réels. Pour le HPC, le motif est CephFS avec MDS actifs en parallèle. Il faut bien dimensionner la partie physique : on n'achète pas un cluster générique en espérant qu'il tienne des GPU à pleine charge.
Oui, c'est une des raisons pour lesquelles on nous appelle. Diagnostic de PG inconsistants, perte de quorum des monitors, OSD qui ne redémarrent pas, récupération bloquée ou upgrades interrompus. Astreinte 24/7 avec SLA contractuel pour les incidents P1.
Écrivez-nous, on regarde
Racontez-nous ce qui se passe : cluster neuf, un qui ne redémarre pas, ou une baie SAN qui vous file entre les doigts. C'est un ingénieur qui répond, pas un formulaire.
Blog!
Notre mission
SIXE garantit que vos infrastructures basées sur les technologies IBM®, Red Hat®, Canonical® et SUSE® restent stables, sécurisées et optimisées aussi longtemps que vous en avez besoin.
Chez SIXE, nous nous engageons pour la durabilité. C’est pourquoi nous vous aidons à concevoir, mettre en œuvre et maintenir des solutions technologiques durables et efficaces.
