Stockage entreprise au S2 2026 : arrêtez de payer deux fois le même téraoctet.
Les prix NAND se sont envolés, Ceph Tentacle change le calcul, OpenStack Gazpacho est sorti — mais le réflexe entreprise reste le même : financer un îlot de stockage isolé de plus dès qu'un projet apparaît. Six mois après le premier choc de prix, ce réflexe coûte cher. Voici les questions à poser avant de signer le prochain bon de commande.
Le S2 2026 n'est pas « après la pénurie de stockage » — c'est après le premier choc de prix. Le NAND a grimpé de 70-75 % en QoQ au Q2, et le Q3 ajoute encore 10-15 %. Et l'achat entreprise tourne toujours sur deux réflexes coûteux : chaque nouveau déploiement OpenStack se paie son propre cluster Ceph ou sa baie, et chaque peur de Ceph se répond par un nouveau bon de commande adressé à « quelqu'un qu'on peut poursuivre ». Les deux financent des silos qui prélèvent quatre impôts par an.
En janvier, on a vu MinIO s'auto-détruire pendant que Ceph publiait sa release 20. Six mois plus tard, le drame a migré de GitHub vers le service achats. Nous vendons du conseil Ceph et nous vendons du stockage IBM entreprise — nous sommes payés dans les deux cas, et c'est précisément pour ça que les questions ci-dessous existent. Jugez les questions, pas le fournisseur.
Q2 2026 (QoQ)
16 juin 2026
SLURP · 1er avril
de réplique ×3 sur 1 Po brut
La pénurie n'est pas terminée. La panique a changé de forme.
TrendForce prévoyait les prix contrats NAND Flash en hausse de 55-60 % en QoQ au Q1 2026 et les SSD entreprise en hausse de 53-58 %. Le Q2 a été révisé à 70-75 % en QoQ, et la prévision Q3 ajoute encore 10-15 % — modérer n'est pas inverser (TrendForce Q1, TrendForce Q2). Les délais des HDD nearline n'offrent pas non plus d'échappatoire : basculer un design du flash vers le disque tournant résout moins qu'il ne le promet.
La question utile pour les achats a cessé d'être « quel nouveau système achète-t-on pour la nouvelle cloud OpenStack ? ». Au S2 2026, elle est :
Quelles capacités possédons-nous déjà, lesquelles devraient être mutualisées, et où une véritable frontière technique ou métier justifie-t-elle une autre plateforme de stockage ?
Un nouveau déploiement OpenStack n'est pas un sacrement qui exige un nouveau cluster Ceph. Parfois, un cluster dédié est exactement la bonne réponse. Souvent, non.
Nouveau cloud, nouvel îlot de stockage. Nouveau besoin, une baie de plus du fournisseur habituel.
Chaque déploiement OpenStack débarque avec sa liste de courses : nouveau cluster Ceph (ou nouvelle baie), nouveau réseau, nouvelle supervision, nouveaux disques de secours. Le diagramme est impeccable. Deux ans plus tard, un îlot a de la capacité qu'il ne peut pas partager, un autre étouffe, et déplacer une charge entre les deux est un projet avec sa propre ligne budgétaire.
Chaque îlot accidentel prélève quatre impôts récurrents — chaque année, aux prix des supports de 2026 :
- Impôt de capacité — chaque plateforme finance son propre espace libre, ses réserves de panne et sa marge d'expansion. Quand la demande bouge, un système a de la capacité dont un autre a besoin en urgence et qu'il ne peut consommer.
- Impôt d'opérations — chaque cluster ou baie apporte ses propres monitors, cycle de vie, certificats, alerting, répétitions d'upgrade, runbooks de DR. Les petites plateformes ne sont pas des miniatures gratuites des grandes.
- Impôt de cohérence — systèmes séparés, conventions séparées. C'est comme ça qu'une organisation se retrouve avec cinq tiers appelés « Gold », aucun ne livrant le même service.
- Impôt de migration — les données placées dans un système isolé finissent par devoir en sortir. La seule question est de savoir si le chemin de sortie est conçu avant le premier volume de production ou découvert cinq ans plus tard, pendant le démantèlement (Cinder multi-backend).
OpenStack Gazpacho n'exige pas de « Ceph Gazpacho Edition ». Cinder pilote plusieurs backends — IBM, Dell, NetApp, Pure, Hitachi compris, avec les drivers entreprise qui continuent de s'améliorer dans Gazpacho — à travers des volume types qui devraient décrire le service (block-critical-replicated), pas l'historique d'achats (old-san-fast, un vrai nom qu'on a vu, sur un système qui n'était ni vieux ni rapide).
Le second réflexe : « Ceph va manger nos données » → achetons une baie de plus
Cet acheteur signe une part remarquable des bons de commande en ce moment. Il a entendu les histoires — le cluster qui est passé en read-only pendant un upgrade, la tempête de recovery qui a mis un réseau à plat, le consultant parti avec la seule copie mentale de la CRUSH map. Chaque nouveau besoin déclenche le même rituel : encore une baie d'un logo connu. Sécurité par la carte bancaire.
Ces peurs ne sont pas idiotes. Un Ceph conçu par des optimistes et exploité par personne fait des dégâts — nous tenons une practice de conseil Ceph et support L3 et nous avons vu les scènes de crime. Mais acheter une baie de plus ne neutralise pas le risque, il le transforme : vous échangez un risque opérationnel testable en laboratoire contre quatre impôts de silos facturés chaque année, aux prix de pénurie, sur N+1 plateformes.
Interrogez les peurs au lieu de les nourrir. « Ceph perd des données » : pouvez-vous nommer le scénario exact de panne, et quelqu'un l'a-t-il reproduit contre un cluster bien conçu ? Bloomberg, CERN et DigitalOcean ont documenté publiquement des estates Ceph de plusieurs dizaines à plus de 100 Po (sources dans notre guide de janvier). Si un scénario a un nom, il se teste et se chiffre. « Notre équipe ne sait pas l'opérer » : c'est la peur la plus légitime de la liste — et celle qui a le remède le plus prévisible, formation Ceph structurée avec labs plus un partenaire de support, budgété comme la maintenance des compétences que vous payez déjà pour chaque stack propriétaire.
Ceph face aux baies entreprise : l'hybride qui survit au réel
Ni « on arrache les baies » ni « on garde Ceph au sandbox pour toujours ». Le modèle qui tient est un hybride contrôlé où chaque couche gagne sa place, avec trois règles et une charge de la preuve claire.
Imaginez l'estate 2026 qu'on croise sans arrêt : une douzaine de silos de baies, un cluster VMware dont le devis de renouvellement exige désormais une réunion, et chaque nouveau projet prêt à ajouter les îlots quinze à trente. Ce qui casse le motif, c'est une seule plateforme Ceph + OpenStack indépendante, déployée petite mais conçue comme la destination par défaut — RBD pour les réfugiés VMware (RBD + OpenStack), RGW pour les projets qui allaient s'acheter leur propre S3, CephFS ou RGW derrière le pipeline IA. Le jour un, techniquement, c'est la plateforme quinze. La différence : c'est la seule avec le mandat écrit d'absorber les quatorze autres.
Ceph Tentacle 20.2.2 — ce qui bouge vraiment
Ceph Tentacle 20.2.2 (16 juin 2026) est la baseline de production actuelle. Trois capacités déplacent de l'argent réel.
FastEC change la conversation autour de l'erasure coding Ceph
Traditionnellement, le design Ceph plaçait les charges RBD latence-critiques sur des pools répliqués parce que l'erasure coding portait une pénalité notable en I/O petit et en amplification d'écriture. Tentacle introduit une nouvelle implémentation d'I/O pour l'erasure coding pensée pour améliorer les performances et l'amplification d'espace, en opt-in via le paramètre allow_ec_optimizations du pool. Elle change également le plugin EC par défaut pour les nouveaux clusters, de la bibliothèque Jerasure (non maintenue) vers ISA-L (blog release Tentacle).
La différence théorique de capacité sur 1 Po brut : réplique ×3 donne ~333 To utiles ; un profil EC 6+2 donne ~750 To. Ces chiffres excluent les réserves d'espace libre opérationnelles, l'overhead BlueStore, l'utilisation inégale des devices, les metadata et les contraintes de failure domain — ce ne sont pas des calculs de dimensionnement. Ils s'appliquent aux pools nouveaux ou migrés ; convertir aujourd'hui un pool répliqué en EC reste un projet de migration de données. FastEC réduit l'écart avec la réplication, il ne renverse pas la physique — le tier latence-critique voudra toujours des réplicas. Mais aux prix NAND actuels, les charges que vous aviez écartées d'EC en 2023-2025 méritent d'être re-benchmarkées.
RBD live migration entre clusters
Tentacle étend les capacités RBD live-migration : les images peuvent être importées depuis un autre cluster Ceph au format natif, ou depuis des sources externes via des flux NBD supportés. RBD mirroring gagne le support du remapping de namespace. Pour les organisations avec plusieurs îlots Ceph, c'est sans doute la capacité Tentacle la plus stratégique — un outil pour consolider des clusters sous-taillés, évacuer une infrastructure vieillissante et planifier une migration par étapes au lieu d'une seule coupure terrifiante.
Ceph NVMe-oF, SMB intégré et multi-tenance S3 renforcée — un seul stack opérationnel
Tentacle élargit la surface de service pratique de Ceph : les groupes de gateway NVMe/TCP et namespaces multiples reçoivent une meilleure gestion ; les services SMB intégrés exposent des shares CephFS via Samba et CTDB ; le resharding de bucket RGW réduit l'impact visible côté client des maintenances de gros buckets ; IAM Accounts continue vers une multi-tenance S3 plus solide ; et le management gateway cephadm fournit un point d'entrée avec TLS qui s'intègre à OAuth 2.0 / OpenID Connect. Cela renforce l'argument d'une plateforme Ceph commune servant plus d'un consommateur — block via RBD, object via RGW, fichier via CephFS ou SMB, NVMe/TCP là où les clients le demandent.
Crimson et SeaStore restent en tech preview dans Tentacle — bons pour du temps de laboratoire, pas pour être la base d'un design critique de production en 2026.
OpenStack Gazpacho — baseline de production, pas une raison de remplacer le stockage
OpenStack 2026.1 Gazpacho est sortie le 1er avril 2026 comme release SLURP maintenue, permettant un rolling upgrade depuis Epoxy en sautant Flamingo. Changements pertinents pour le stockage : Nova gagne la live migration parallèle, un IOThread QEMU par instance par défaut et l'attach de volume asynchrone depuis la microversion 2.101 (notes Nova). Cinder ajoute une sélection plus précise de région pour les endpoints de backup Glance et Swift, plus des améliorations continues des drivers entreprise (notes Cinder).
À lire avec un œil d'ingénieur. L'attach asynchrone améliore le comportement du plan de contrôle ; il ne rend pas rapide un backend lent. La live migration parallèle réduit les fenêtres de maintenance ; elle provoque aussi des pics de demande sur le fabric de stockage et de réseau. Gazpacho améliore la mécanique. L'architecture décide toujours du résultat.
Hibiscus arrive vers le 30 septembre avec Nova qui bascule par défaut vers le native threading. Testez cela d'abord en staging sous Gazpacho — l'upstream le recommande (Nova unreleased). Et quoi que vous fassiez, ne mettez pas dans le même week-end un OpenStack majeur, un Ceph majeur, une migration EC, un redesign réseau et un déplacement de charges. Votre plateforme aura peut-être besoin des cinq changements. Elle n'a pas besoin des cinq surprises.
3 questions, une recommandation initiale
Trois questions rapides pour placer votre situation sur la carte. Aucune donnée collectée, pas d'email demandé — tout tourne dans votre navigateur. Pour approfondir, le livre blanc ci-dessous couvre les mêmes décisions en entier, avec l'auto-évaluation de 20 questions et le plan mois par mois jusqu'à la fin d'année.
Quel mouvement de stockage correspond à votre situation ?
Répondez aux trois questions et nous vous montrons la recommandation initiale. C'est un point de départ pour la conversation, pas un bordereau matériel.
Jouez avec vos propres chiffres — erasure coding Ceph face à la réplication, et l'impôt du silo
Deux calculatrices en direct. Tapez vos chiffres, regardez le compromis apparaître. Les deux tournent dans votre navigateur — rien n'est envoyé nulle part. Approximatives à dessein ; la méthodologie complète est dans le livre blanc.
FastEC face à la réplique ×3
Combien de capacité utile tirez-vous vraiment du To brut — avec ISA-L par défaut sous Tentacle et FastEC en opt-in (allow_ec_optimizations) ?
Passer de la réplique ×3 à EC 6+2 vous donne +417 To depuis le même pool brut. Sur block généraliste, images et object — à re-benchmarker. Sur les écritures aléatoires petites synchrones — testez toujours avec votre charge.
Théorique uniquement. Exclut les réserves d'espace libre, l'overhead BlueStore et les contraintes de failure domain. Convertir aujourd'hui un pool répliqué en EC reste un projet de migration de données.
Le compteur des quatre impôts
Estimation grossière de ce que N silos accidentels vous coûtent chaque année — en capacité échouée et en opérations dupliquées. Illustratif, pas un devis.
Une plateforme mutualisée absorbant la moitié de ces silos récupérerait l'essentiel de cet impôt sur 3 ans. Pas la totalité — jamais — mais assez pour financer l'assessment qui vous dit le vrai chiffre.
Modèle règle du pouce : ~15 % de réserve échouée par silo · ~30 k€/an d'ops par silo (supervision, upgrades, astreinte, qualification des spares). Utilisez la méthodologie complète du livre blanc pour ce qui va au CFO.
Cinq questions à agrafer à chaque achat de stockage
Une plateforme dédiée se justifie quand la frontière elle-même apporte de la valeur — régulation, souveraineté, géographie, propriété indépendante, exigence explicite de blast radius, incompatibilité de charges prouvée en test, ou échelle extrême. « L'équipe projet voulait ses propres jouets » n'apparaît nulle part sur cette liste.
Avant de signer le prochain bon de commande, produisez par écrit, avec preuves, les réponses à ces cinq questions :
- Quelle frontière précise créons-nous ?
- Quel risque réduit-elle, et comment mesurera-t-on la réduction ?
- Quel coût dupliqué la frontière introduit-elle ? (capacité, ops, cohérence, migration)
- Pourquoi les pools, identités CephX, quotas, règles CRUSH, device classes ou volume types ne peuvent-ils pas satisfaire le besoin ?
- Quel test de laboratoire a disqualifié l'option mutualisée ?
Sans réponses adossées à des preuves → ce n'est pas un besoin, c'est une préférence. Les préférences sont autorisées. Ce qui ne l'est pas, c'est de les déguiser en architecture.
Que faire du reste du budget 2026
Le pire résultat de fin d'année n'est pas un budget non dépensé. C'est un budget entièrement dépensé qui crée cinq ans de coût d'exploitation évitable. Cinq étapes d'ici décembre — cochez-les au fur et à mesure.
Capacité brute et utile, consommation réelle, exposition au thin provisioning, volumes et images orphelins, percentiles de latence et de débit, dates EOL, compatibilité des drivers Cinder, projection de croissance à 2029. Ne dimensionnez pas uniquement à partir des estimations du propriétaire d'application.
Réutilisation maximale des baies existantes · hybride baies + Ceph mutualisé · Ceph nouveau ou étendu comme principal. Comparez le coût sur cinq ans, la complexité de migration, l'efficacité de capacité, l'effort équipe, le coût de sortie. Lancez la réservation d'approvisionnement en parallèle pour protéger les supports à long lead time.
Performance normale, latence percentile 95 et 99, fonctionnement dégradé, panne de disque et d'hôte, recovery et backfill, snapshot et clone, live migration, backup et restore, étapes d'upgrade. Pas un benchmark synthétique contre un cluster vide.
Vagues de migration, conditions de rollback, runbooks, formation de l'équipe avant la bascule en production. Un runbook écrit pendant un incident s'appelle une transcription.
Si les supports n'arrivent pas avant la fin d'année, engagez le budget sur un fabric réseau validé, des spares qualifiés, un backup indépendant, la supervision, l'automatisation, l'ingénierie et la formation. Un rack de NAND sans recovery testé et sans opérateurs formés n'est pas un service de stockage — c'est de l'inventaire.
Téléchargez le playbook complet — 20 questions, 5 critères de filtre, 4 patrons architecturaux
L'article ci-dessus est le résumé. Le livre blanc est la version complète : l'auto-évaluation en vingt questions, les cinq critères du filtre de décision, les quatre patrons architecturaux avec leur cas d'usage, un modèle illustratif de budget 2026, et comment séquencer assessment / architecture / PoC / achat / migration jusqu'à la fin d'année. Écrit pour le CTO, l'architecte et l'acheteur qui s'apprête à renouveler.
Téléchargez le livre blanc stockage S2 2026
Laissez votre nom et votre email — on vous envoie le livre blanc dans la boîte mail. Pas d'appel commercial, pas de drip campaign. Si le Substack LibrePower sur l'open source pour IBM Power vous intéresse aussi, cochez la case ; vous terminez l'abonnement en un clic depuis le mail de confirmation.
Nous utilisons Google Forms pour collecter vos données. Elles sont traitées selon la politique de confidentialité de SIXE. Vous pouvez vous désabonner à tout moment.
Achetez du stockage quand vous avez besoin de stockage. Construisez une frontière quand vous avez besoin d'une frontière.
Faites de Ceph mutualisé le candidat par défaut pour la nouvelle capacité mutualisée, laissez les baies garder ce qu'elles méritent, et n'approuvez des clusters dédiés que lorsque la frontière apporte une valeur mesurable. Tout le reste est de la préférence déguisée en architecture.
Nous faisons du conseil Ceph et du support L3, de la formation Ceph avec labs et certification Credly, du design et migration cloud privé OpenStack et du stockage IBM entreprise. Quelle que soit votre décision, c'est nous qui l'exécutons.
Les questions qui reviennent le plus
Faut-il un nouveau cluster Ceph pour un nouveau déploiement OpenStack ?
Non. OpenStack Cinder est conçu pour consommer plusieurs backends — y compris vos baies existantes IBM, Dell, NetApp, Pure ou Hitachi — via leurs drivers officiels. Un nouveau plan de contrôle n'exige pas un nouveau plan de données. Il exige un inventaire de ce que vous avez déjà et un catalogue de service par-dessus.
Qu'est-ce qui change vraiment avec Ceph Tentacle 20.2.2 ?
FastEC en opt-in (erasure coding avec un bien meilleur comportement en I/O petit), RBD live migration native entre clusters, gestion des gateways NVMe/TCP, SMB intégré via Samba et CTDB, et multi-tenance S3 renforcée via IAM Accounts. La release 20.2.2 (16 juin 2026) est la baseline de production actuelle.
OpenStack Gazpacho est-elle la bonne release pour le S2 2026 ?
Pour la plupart des déploiements critiques au S2 2026, oui. Gazpacho (2026.1, publiée le 1er avril) est SLURP : rolling upgrade depuis Epoxy en sautant Flamingo. Hibiscus arrive vers le 30 septembre avec Nova basculant par défaut vers le native threading — testez-la tôt en staging, adoptez-la en production en connaissance de cause.
Quand un cluster Ceph dédié a-t-il vraiment du sens ?
Lorsque la frontière apporte elle-même une valeur mesurable : régulation ou souveraineté des données, isolation géographique, propriété indépendante, exigence explicite de blast radius, charges dont l'incompatibilité est prouvée en test, ou échelle très grande. L'existence d'un autre plan de contrôle OpenStack n'est pas, à elle seule, un motif valable.
Ceph est-il assez sûr pour les données de production entreprise ?
Oui, bien conçu et bien opéré. Bloomberg, CERN et DigitalOcean ont documenté publiquement des estates Ceph allant de dizaines de Po à plus de 100 Po. La durabilité dépend de la conception des domaines de panne, du recovery répété et d'opérations tenues par une équipe — tout cela se contracte à votre échelle. Ceph est porté par une fondation multi-vendor sous la Linux Foundation, avec des distributions enterprise proposant du support L3 contractuel.
Puis-je mélanger baies entreprise et Ceph sous le même OpenStack ?
Oui, et pour la plupart des entreprises disposant déjà de baies, c'est le design le plus solide pour le S2 2026. Les baies gardent les charges où elles excellent ; Ceph devient le candidat par défaut pour la nouvelle capacité mutualisée. Cinder expose les deux via des volume types orientés service (block-critical-replicated, block-standard, block-capacity).
Vous voulez les cinq options chiffrées avec vos propres nombres ?
Vous apportez l'inventaire. Nous, le laboratoire. Un rapport court avec le coût sur cinq ans de chaque option appliqué à votre parc réel — réutiliser les baies que vous avez, hybride baies + Ceph mutualisé, Ceph neuf ou étendu, Ceph dédié ou hyperconvergé. La première conversation est gratuite. Si ça ne colle pas, ça ne colle pas. Si ça colle, vous nous le direz.
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.
