Avant une montée en charge, une mise à niveau ou un achat de stockage, un cluster Ceph se juge sur des mesures, pas sur des impressions. Expert et consultant Ceph indépendant, j’audite et je conçois des plateformes de stockage distribuées : cartes CRUSH et domaines de panne, S3 multi-sites via RGW, RBD pour les PVC Kubernetes, CephFS pour le partage de fichiers, et dimensionnement jusqu’au devis fournisseur. J’interviens aussi en correction, quand un cluster en production ne se comporte plus de façon prévisible.
Point de preuve : performance et observabilité de Ceph et MinIO sur un lac de données multi-pétaoctets en cloud privé ; optimisation des latences de stockage block pour une plateforme d’imagerie satellitaire ; plateforme S3 multi-sites mise à niveau de Ceph Squid vers Tentacle. Références disponibles sous NDA.
Audit de cluster et de stockage Ceph
Revue indépendante d’un cluster existant : carte CRUSH et domaines de panne, layout des pools, erasure coding ou réplication là où le choix compte, classes de matériel et placement des OSD, santé des monitors et managers, politiques RGW, features des images RBD, hygiène des versions et de la sécurité. L’audit se termine par une liste de risques priorisés et des correctifs chiffrés, pas par des généralités.
Stockage block : RBD et PVC Kubernetes
Travail de performance RBD : attribution de la latence entre réseau, WAL des OSD et limites clients, placement du WAL et du DB sur le bon média, jeux de features d’images qui coûtent du débit sans le dire. Pour Kubernetes, le choix et l’exploitation de RBD comme backend PVC, y compris le mirroring RBD pour la continuité multi-sites. Le sujet est détaillé dans un article sur le choix d’un backend PVC.
Stockage objet : RGW et S3 multi-sites
Conception et validation de la réplication multi-sites RGW, tests d’acceptation S3 avant mise en production, politiques de buckets et d’IAM, et chemin de mise à niveau qui tient un SLA de production. La montée de version multi-sites de Squid vers Tentacle et la migration des OSD non gérés vers les OSD gérés documentent les deux en détail.
Performance et dimensionnement
Des mesures avant l’engagement : profilage réseau et NVMe, identification des goulots d’étranglement, arbitrages erasure coding contre réplication face à vos scénarios de panne réels, plans de dimensionnement à 3 et 5 ans, et revue indépendante d’une proposition fournisseur. Chaque recommandation chiffrée est confrontée à votre charge réelle, pas à un benchmark vendeur.
Ce n’est ni de l’infogérance ni du développement : pour une seule décision technique, la revue d’architecture flash suffit.
FAQ
Ceph est-il un bon backend pour la virtualisation et les PVC Kubernetes ?
Oui pour les charges block qui tolèrent une latence shared-nothing : RBD est le backend PVC on-premise le plus répandu, et le mirroring couvre la continuité multi-sites. Il justifie son coût quand le même cluster sert aussi de l’objet ou du fichier ; un besoin purement block est parfois moins cher sur du stockage dédié. L’arbitrage mérite un dimensionnement avant engagement.
Peut-on mettre un cluster Ceph à niveau sans interruption ?
Oui au sein d’une ligne de version : les OSD basculent un domaine de panne à la fois pendant que les clients continuent de servir. Les contraintes apparaissent aux sauts de version majeurs et dans les topologies RGW multi-sites, où l’ordre entre sites fait partie du plan. Une montée de version se répète contre la topologie du cluster lui-même, jamais contre un runbook générique.
Combien de matériel pour un pétaoctet de Ceph ?
Cela dépend du domaine de panne, du profil d’erasure coding et du réseau ; la réponse honnête vient d’un exercice de dimensionnement, pas d’une règle empirique : le même pétaoctet peut varier d’un facteur deux en disques seuls. Je dimensionne sur la charge réelle et je traduis le résultat en configurations serveurs et disques ou en types d’instances cloud.