Enterprise storage in H2 2026: stop buying the same terabyte twice.
NAND prices exploded, Ceph Tentacle changed the maths, OpenStack Gazpacho shipped — and the enterprise reflex is still to fund another isolated storage island every time a new project appears. Six months into the shortage, that reflex is expensive. Here are the questions to answer before signing another purchase order.
H2 2026 is not "after the storage shortage" — it's after the first price shock. Q2 NAND was up 70–75% QoQ, Q3 still adds another 10–15%. And enterprise buying still runs on two expensive reflexes: every new OpenStack deployment buys itself a fresh Ceph cluster or array, and every fear of Ceph is answered by another purchase order to "someone we can sue". Both fund silos that charge four taxes a year.
Back in January we watched MinIO immolate itself while Ceph shipped its 20th release. Six months later the drama moved from GitHub to the purchasing department. We sell Ceph consulting and we sell IBM enterprise storage — we get paid either way, which is precisely why the questions below exist. Judge the questions, not the vendor.
contract price (QoQ)
June 16, 2026
SLURP · April 1
3× replica on 1 PB raw
The shortage didn't end. The panic changed shape.
TrendForce projected overall NAND Flash contract prices up 55–60% QoQ in Q1 2026 and enterprise SSD prices up 53–58%. Q2 was later revised to 70–75% QoQ, and the Q3 forecast still adds 10–15% on top — moderation is not the same thing as a reversal (TrendForce Q1, TrendForce Q2). Nearline HDD lead times aren't offering an escape route either, so moving a design from flash to spinning disk solves less than it promises.
The useful procurement question stopped being "which new system do we buy for our new OpenStack cloud?". In H2 2026 it is:
Which capabilities do we already own, which capabilities should be shared, and where does a genuine technical or business boundary justify another storage platform?
A new OpenStack deployment is not a sacrament that requires a fresh Ceph cluster. Sometimes a dedicated cluster is exactly the right answer. Quite often, it is not.
New cloud, new storage island. New requirement, another array from a familiar logo.
Every new OpenStack deployment arrives with a shopping list: new Ceph cluster (or new array), new network, new monitoring, new spare drives. The diagram looks immaculate. Two years later one island has capacity it cannot share, another is starving, and moving a workload between them is a project with its own budget code.
Each accidental island charges four recurring taxes — every year, at 2026 media prices:
- Capacity tax — every platform funds its own free space, failure reserves and expansion headroom. When demand shifts, one system has capacity another urgently needs and cannot consume.
- Operations tax — each cluster or array brings its own monitors, lifecycle, certificates, alerting, upgrade rehearsals, DR runbooks. Small platforms are not free miniatures of large ones.
- Consistency tax — separate systems, separate conventions. That is how organisations end up with five tiers called "Gold," none delivering the same service.
- Migration tax — data placed in an isolated system eventually needs to leave. The only question is whether the exit path is designed before the first production volume or discovered five years later during decommissioning (Cinder multi-backend docs).
OpenStack Gazpacho does not require "Ceph Gazpacho Edition". Cinder drives multiple back ends — IBM, Dell, NetApp, Pure, Hitachi included, with enterprise drivers still improving in Gazpacho — through volume types that should describe service (block-critical-replicated), not purchasing history (old-san-fast, a real name we've seen, on a system that was neither).
The second reflex: "Ceph will eat our data" → buy another array
This buyer is signing a remarkable share of the POs right now. They have heard the stories — the cluster that went read-only mid-upgrade, the recovery storm that flattened a network, the consultant who left with the only mental copy of the CRUSH map. Every new capacity requirement triggers the same ritual: another array from a familiar logo. Safety through shopping.
The fears are not stupid. Ceph designed by optimists and operated by nobody will absolutely hurt you — we run a Ceph L3 support practice and we have seen the crime scenes. But buying another array does not neutralise the risk, it converts it: you swap an operational risk you could test in a lab for four silo taxes invoiced annually, at shortage prices, across N+1 platforms.
Interrogate the fears instead of feeding them. "Ceph loses data": can you name the exact failure scenario, and has anyone reproduced it against a correctly designed cluster? Bloomberg, CERN and DigitalOcean have publicly documented Ceph estates from tens of petabytes to 100+ PB (sources in our January guide). If a scenario has a name, it can be tested and priced. "Our team can't operate it": that is the most legitimate fear on the list — and the one with the most predictable fix, structured Ceph training with hands-on labs plus a support partner, budgeted like the skills upkeep you already pay for every proprietary stack.
Ceph vs enterprise arrays: the hybrid that survives contact with reality
Neither "rip out the arrays" nor "keep Ceph in a sandbox forever". The model that survives is a controlled hybrid where each layer earns its place, with three rules and a clear burden of proof.
Picture the 2026 estate we keep meeting: a dozen-plus array silos, a VMware cluster whose renewal quote now requires a sit-down, every new project about to add islands fifteen through thirty. What breaks the pattern is one independent Ceph + OpenStack platform, deployed small but designed as the default destination — RBD for the VMware refugees (RBD + OpenStack), RGW for the projects about to buy their own S3, CephFS or RGW backing the AI pipeline. On day one it's technically platform fifteen. The difference: it's the only one with a written mandate to absorb the other fourteen.
Ceph Tentacle 20.2.2 — what materially moved
Ceph Tentacle 20.2.2 (June 16, 2026) is the current production baseline. Three capabilities move real money.
FastEC changes the Ceph erasure coding conversation
Traditional Ceph design placed latency-sensitive RBD workloads on replicated pools because erasure coding carried a meaningful small-I/O and write-amplification penalty. Tentacle introduces a new erasure-coding I/O implementation intended to improve both performance and space amplification, opt-in via the allow_ec_optimizations pool setting. It also changes the default EC plug-in for new clusters from the unmaintained Jerasure library to ISA-L (Tentacle release blog).
The theoretical capacity difference on 1 PB raw: three-way replication gives ~333 TB usable; a 6+2 EC profile gives ~750 TB. Those figures exclude operational free-space reserves, BlueStore overhead, uneven device utilisation, metadata and failure-domain constraints — they are not sizing results. They apply to new or migrated pools; converting an existing replicated pool to EC today is still a data-migration project. FastEC narrows the gap with replication, it does not repeal physics — latency-critical tiers will still want replicas. But at today's NAND prices, the workloads you rejected for EC in 2023–2025 are worth rebenchmarking.
RBD live migration between clusters
Tentacle expands RBD live-migration capabilities: images can be imported from another Ceph cluster in native format, or from external sources via supported NBD workflows. RBD mirroring gains namespace-remapping support. For organisations with several Ceph islands, this is arguably the most strategically important Tentacle capability — a tool for consolidating undersized clusters, evacuating ageing infrastructure and staging a migration instead of scheduling a single terrifying outage.
Ceph NVMe-oF, integrated SMB and stronger S3 tenancy — one operational stack
Tentacle broadens Ceph's practical service surface: NVMe/TCP gateway groups and multiple namespaces receive improved management; integrated SMB services expose CephFS-backed shares via Samba and CTDB; RGW bucket resharding reduces client-visible impact of large-bucket maintenance; IAM Accounts continue the movement toward stronger S3 tenancy; and the cephadm management gateway provides a TLS-terminated entry point that integrates with OAuth 2.0 / OpenID Connect. This strengthens the case for a common Ceph platform serving more than one consumer — block via RBD, object via RGW, file via CephFS or SMB, NVMe/TCP where clients demand it.
Crimson and SeaStore remain tech preview in Tentacle — worth lab time, not the foundation of a critical 2026 production design.
OpenStack Gazpacho — production baseline, not a reason to replace storage
OpenStack 2026.1 Gazpacho released April 1, 2026 as a maintained SLURP release, allowing a rolling upgrade from Epoxy and skipping Flamingo. Storage-relevant changes: Nova gets parallel live migration, one QEMU IOThread per instance by default, and asynchronous volume attach from microversion 2.101 (Nova notes). Cinder adds more precise region selection for Glance and Swift backup endpoints, plus continuing enterprise-driver enhancements (Cinder notes).
Read those with an engineer's eye. Async attach improves control-plane behaviour; it does not make a slow back end fast. Parallel live migration shortens maintenance windows; it also spikes demand on the storage and network fabric. Gazpacho improves the machinery. Architecture still determines the result.
Hibiscus lands ~September 30 with Nova moving to native threading by default. Test that in staging under Gazpacho first — upstream tells you to (Nova unreleased). And whatever you do, do not put an OpenStack major, a Ceph major, an EC migration, a network redesign and a workload move in the same weekend. Your platform may need all five. It does not need all five surprises.
3 questions, one initial recommendation
Three quick questions to place your situation on the map. No data collected, no email asked — everything runs in your browser. When you want to go deeper, the whitepaper below covers the same decisions in full, with the 20-question self-assessment and the month-by-month year-end plan.
Which storage move fits your situation?
Answer the three questions and we'll show you the initial recommendation. It's a starting point for the conversation, not a bill of materials.
Play with your own numbers — Ceph erasure coding vs replication, and the silo tax
Two live calculators. Type your figures, watch the trade-off appear. Both run in your browser — no data sent anywhere. Rough by design; the whitepaper below has the full methodology.
FastEC vs 3× replication
How much usable capacity do you actually get from raw TB — with Tentacle's ISA-L default and opt-in FastEC (allow_ec_optimizations)?
Moving from 3× replica to 6+2 EC gives you +417 TB from the same raw pool. On general-purpose block, images and object — worth rebenchmarking. On synchronous small random writes — still test with your workload.
Theoretical only. Excludes free-space reserves, BlueStore overhead, failure-domain constraints. Converting existing replicated pools to EC is a data-migration project today.
The four-tax counter
Rough estimate of what N accidental silos cost you every year — in stranded capacity and duplicated operations. Illustrative, not a quote.
A shared platform absorbing half of these silos would recover most of that tax over 3 years. Not the full number — nothing ever is — but enough to fund the assessment that tells you the real one.
Rule-of-thumb model: ~15% stranded reserve per silo · ~€30k/year ops per silo (monitoring, upgrades, on-call, spares qualification). Use the whitepaper's full methodology for anything that goes to a CFO.
Five questions to staple to every new storage purchase
A dedicated platform is justified when the boundary itself has value — regulation, sovereignty, geography, independent ownership, an explicit blast-radius requirement, workload incompatibility proven in testing, or extreme scale. "The project team wanted its own toys" appears nowhere on that list.
Before signing the next PO, produce written, evidence-based answers to these five:
- What precise boundary are we creating?
- Which risk does it reduce, and how will we measure the reduction?
- What duplicated cost does the boundary introduce? (capacity, ops, consistency, migration)
- Why can't pools, CephX identities, quotas, CRUSH rules, device classes or volume types satisfy the requirement?
- Which lab test disqualified the shared option?
No evidence-based answers → it is not a requirement, it is a preference. Preferences are allowed. They should not be disguised as architecture.
What to do with the rest of your 2026 budget
The worst year-end outcome is not an unspent budget. It is a fully spent budget that creates five years of avoidable operating cost. Five checkpoints between now and December — check them off as you complete them.
Raw and usable capacity, real consumption, thin-provisioning exposure, orphaned volumes and images, latency and throughput percentiles, EOL dates, Cinder driver compatibility, growth projection to 2029. Do not size from application-owner estimates alone.
Maximum reuse of existing arrays · hybrid array + shared Ceph · new or expanded Ceph as primary. Compare five-year cost, migration complexity, capacity efficiency, staff effort, exit cost. Run supply reservation in parallel to protect long-lead media.
Normal performance, 95th and 99th percentile latency, degraded operation, drive and host failure, recovery and backfill, snapshot and clone, live migration, backup and restore, upgrade steps. Not a synthetic benchmark against an empty cluster.
Migration waves, rollback conditions, runbooks, team training before production cutover. A runbook written during an incident is called a transcript.
If media cannot land before year-end, commit budget to validated network fabric, qualified spares, independent backup, monitoring, automation, engineering and training. A rack of NAND without tested recovery and trained operators is not a storage service — it is inventory.
Get the full playbook — 20 questions, 5 gate criteria, 4 architectural patterns
The post above is the summary. The whitepaper is the full version: the twenty-question self-assessment, the five decision-gate criteria, the four architectural patterns with when to use each, an illustrative 2026 budget model, and how to sequence assessment / architecture / PoC / procurement / migration through year-end. Written for the CTO, the architect, and the buyer who is about to renew.
Download the H2 2026 storage whitepaper
Enter your name and email — we send the whitepaper straight to your inbox. No sales call, no drip campaign. If you also want the LibrePower Substack on open source for IBM Power, tick the box; you'll finish the subscription in one click on the confirmation email.
We use Google Forms to collect your details. Your data is processed under SIXE's privacy policy. You can unsubscribe at any time.
Buy storage when you need storage. Build a boundary when you need a boundary.
Make shared Ceph the default candidate for new pooled capacity, let arrays keep what they earn, and approve dedicated clusters only when the boundary itself delivers measurable value. Everything else is preference disguised as architecture.
We run Ceph consulting and L3 support, Ceph training with hands-on labs and Credly certification, OpenStack private-cloud design and migration, and IBM enterprise storage. Whatever you decide, we execute.
Questions we get most
Do I need a new Ceph cluster for a new OpenStack deployment?
No. OpenStack Cinder is designed to consume multiple back ends — including your existing IBM, Dell, NetApp, Pure or Hitachi arrays — through supported drivers. A new control plane does not require a new data plane. It requires an inventory of what you already own and a service-intent catalogue on top of it.
What actually changed with Ceph Tentacle 20.2.2?
Opt-in FastEC (erasure coding with substantially better small-I/O behaviour), native RBD live migration between clusters, NVMe/TCP gateway management, integrated SMB via Samba and CTDB, and stronger S3 tenancy through IAM Accounts. Point release 20.2.2 (June 16, 2026) is the current production baseline.
Is OpenStack Gazpacho the right release for H2 2026?
For most critical H2 2026 deployments, yes. Gazpacho (2026.1, released April 1) is a SLURP release, allowing rolling upgrade from Epoxy and skipping Flamingo. Hibiscus lands around September 30 with Nova moving to native threading by default — test it in staging early, adopt in production deliberately.
When does a dedicated Ceph cluster actually make sense?
When the boundary itself has measurable value: regulation or data sovereignty, geographic isolation, independent ownership, explicit blast-radius requirement, workloads whose incompatibility has been proven in testing, or very large scale. The existence of another OpenStack control plane is not, by itself, a valid reason.
Is Ceph safe enough for enterprise production data?
Yes, when designed and operated correctly. Bloomberg, CERN and DigitalOcean have publicly documented Ceph estates from tens of petabytes to 100+ PB. Durability depends on failure-domain design, rehearsed recovery and staffed operations — all of which can be contracted at your scale. Ceph development is backed by a multi-vendor foundation at the Linux Foundation, and enterprise distributions with contractual L3 support exist.
Can I mix enterprise arrays and Ceph under the same OpenStack?
Yes, and for most enterprises with an existing storage estate this is the strongest H2 2026 design. Arrays keep the workloads they are demonstrably best at; Ceph becomes the default candidate for new pooled capacity. Cinder exposes both through service-intent volume types (block-critical-replicated, block-standard, block-capacity).
Want the five options scored with your numbers?
Bring your inventory. We'll bring the lab. A short report with the five-year cost of each option applied to your actual estate — reuse the arrays you own, hybrid array + shared Ceph, new or expanded Ceph, dedicated Ceph, or hyperconverged. First conversation is free. If we don't fit, we don't fit. If we do, you'll tell us.
