Almacenamiento empresarial en H2 2026: deja de pagar dos veces por el mismo terabyte.
Los precios de NAND se han disparado, Ceph Tentacle cambia el cálculo y OpenStack Gazpacho ya está en producción — pero el reflejo empresarial sigue siendo pagar otra isla de almacenamiento aislada cada vez que aparece un proyecto nuevo. Seis meses después del primer subidón, ese reflejo sale caro. Estas son las preguntas que hay que responder antes de firmar la próxima compra.
H2 2026 no es «después de la escasez de almacenamiento» — es después del primer subidón de precios. La NAND subió un 70-75% intertrimestral en Q2 y Q3 suma otro 10-15% encima. Y la compra empresarial sigue funcionando con dos reflejos caros: cada despliegue OpenStack nuevo se compra su Ceph o cabina propia, y cada miedo a Ceph se contesta con otra orden de compra a «alguien a quien denunciar». Los dos financian silos que cobran cuatro impuestos anuales.
En enero vimos a MinIO auto-inmolarse mientras Ceph publicaba su release 20. Seis meses después el drama se ha mudado de GitHub al departamento de compras. Vendemos consultoría Ceph y también vendemos y soportamos almacenamiento IBM — cobramos en cualquiera de las dos direcciones, y por eso las preguntas de abajo existen. Juzga las preguntas, no al proveedor.
NAND · Q2 2026 (QoQ)
16 junio 2026
SLURP · 1 abril
de 3× replica sobre 1 PB bruto
La escasez no ha acabado. El pánico ha cambiado de forma.
TrendForce proyectó los precios contrato NAND Flash subiendo un 55-60% QoQ en Q1 2026, y los SSD empresariales un 53-58%. Q2 se revisó al alza a 70-75% QoQ, y la previsión de Q3 aún suma otro 10-15% encima — moderar no es lo mismo que dar la vuelta (TrendForce Q1, TrendForce Q2). Los plazos del HDD nearline tampoco están dando escape, así que cambiar un diseño de flash a disco giratorio resuelve menos de lo que promete.
La pregunta útil de compras ha dejado de ser «¿qué sistema nuevo compramos para la nube OpenStack nueva?». En H2 2026 es:
¿Qué capacidades ya tenemos, cuáles deberían compartirse, y dónde justifica una frontera técnica o de negocio real otra plataforma de almacenamiento?
Un despliegue OpenStack nuevo no es un sacramento que exija un clúster Ceph nuevo. A veces un clúster dedicado es exactamente la respuesta. A menudo, no.
Nube nueva, silo de almacenamiento nuevo. Requisito nuevo, otra cabina del proveedor de siempre.
Cada despliegue OpenStack llega con lista de la compra: clúster Ceph nuevo (o cabina nueva), red nueva, monitorización nueva, spare drives nuevos. El diagrama queda impecable. Dos años después, una isla tiene capacidad que no puede compartir, otra se ahoga, y mover una carga entre ellas es un proyecto con su propio código de presupuesto.
Cada isla accidental cobra cuatro impuestos recurrentes — cada año, a precios de medios de 2026:
- Impuesto de capacidad — cada plataforma financia su propio espacio libre, sus reservas de fallo y su margen de expansión. Cuando la demanda se mueve, un sistema tiene capacidad que otro necesita urgente y no puede consumir.
- Impuesto de operaciones — cada clúster o cabina trae sus propios monitores, ciclo de vida, certificados, alertas, ensayos de upgrade y runbooks de DR. Las plataformas pequeñas no son miniaturas gratis de las grandes.
- Impuesto de consistencia — sistemas separados, convenciones separadas. Así acaban las organizaciones con cinco tiers llamados «Gold», ninguno dando el mismo servicio.
- Impuesto de migración — los datos que van a un sistema aislado tarde o temprano tienen que salir. La única pregunta es si el camino de salida se diseña antes del primer volumen productivo o se descubre cinco años después durante el desmantelamiento (Cinder multi-backend).
OpenStack Gazpacho no requiere «Ceph Gazpacho Edition». Cinder maneja múltiples backends — IBM, Dell, NetApp, Pure, Hitachi incluidos, con los drivers empresariales mejorando aún en Gazpacho — a través de volume types que deberían describir servicio (block-critical-replicated), no historial de compra (old-san-fast, un nombre real que hemos visto, en un sistema que ni era viejo ni era rápido).
El segundo reflejo: «Ceph nos va a comer los datos» → compra otra cabina
Este comprador está firmando una parte notable de las órdenes de compra ahora mismo. Ha oído las historias — el clúster que se quedó en read-only durante un upgrade, la tormenta de recovery que tumbó una red, el consultor que se fue con la única copia mental del CRUSH map. Cada nueva necesidad de capacidad dispara el mismo ritual: otra cabina de un logo conocido. Seguridad a base de compras.
Los miedos no son estúpidos. Ceph diseñado por optimistas y operado por nadie te hace daño garantizado — mantenemos una práctica de consultoría Ceph y soporte L3 y hemos visto las escenas del crimen. Pero comprar otra cabina no neutraliza el riesgo, lo transforma: cambias un riesgo operativo que podrías probar en laboratorio por cuatro impuestos de silo facturados cada año, a precios de escasez, en N+1 plataformas.
Interroga los miedos en vez de alimentarlos. «Ceph pierde datos»: ¿puedes nombrar el escenario exacto de fallo, y alguien lo ha reproducido contra un clúster bien diseñado? Bloomberg, CERN y DigitalOcean tienen documentados estados Ceph de decenas de PB a más de 100 PB (fuentes en nuestra guía de enero). Si un escenario tiene nombre, se puede probar y presupuestar. «Nuestro equipo no lo sabe operar»: ese es el miedo más legítimo de la lista — y el que tiene el arreglo más predecible, formación Ceph estructurada con laboratorios más un partner de soporte, presupuestado como el mantenimiento de skills que ya pagas para cada stack propietario.
Ceph frente a cabinas empresariales: el híbrido que sobrevive al mundo real
Ni «fuera las cabinas» ni «Ceph encerrado en un sandbox para siempre». El modelo que aguanta es un híbrido controlado donde cada capa se gana su sitio, con tres reglas y una carga de la prueba clara.
Imagina el escenario de 2026 con el que nos seguimos encontrando: una docena larga de silos de cabinas, un clúster VMware cuya cotización de renovación ya requiere una reunión formal, y cada proyecto nuevo a punto de sumar las islas quince a treinta. Lo que rompe el patrón es una única plataforma Ceph + OpenStack independiente, desplegada pequeña pero diseñada como destino por defecto — RBD para los refugiados de VMware (RBD + OpenStack), RGW para los proyectos que iban a comprar su propio S3, CephFS o RGW debajo del pipeline de IA. El día uno técnicamente es la plataforma quince. La diferencia: es la única con mandato escrito para absorber a las otras catorce.
Ceph Tentacle 20.2.2 — lo que mueve dinero de verdad
Ceph Tentacle 20.2.2 (16 de junio de 2026) es la baseline de producción actual. Tres capacidades mueven dinero de verdad.
FastEC cambia la conversación de Ceph erasure coding
Tradicionalmente el diseño Ceph colocaba las cargas RBD latencia-críticas en pools con réplica porque el erasure coding tenía una penalización notable en I/O pequeño y write amplification. Tentacle introduce una nueva implementación de I/O para erasure coding pensada para mejorar rendimiento y amplificación de espacio, opt-in vía el parámetro allow_ec_optimizations del pool. Además cambia el plugin EC por defecto para clústeres nuevos, de la librería Jerasure (sin mantenimiento) a ISA-L (blog release Tentacle).
La diferencia teórica de capacidad sobre 1 PB bruto: réplica ×3 da ~333 TB útiles; un perfil EC 6+2 da ~750 TB. Esas cifras excluyen reservas operativas de espacio libre, overhead de BlueStore, uso desigual de dispositivos, metadatos y restricciones de failure domain — no son cálculos de dimensionamiento. Aplican a pools nuevos o migrados; convertir hoy un pool replicado a EC sigue siendo un proyecto de migración de datos. FastEC estrecha el hueco con réplica, no deroga la física — el tier latencia-crítico va a seguir queriendo réplicas. Pero a los precios NAND de hoy, las cargas que descartaste para EC en 2023-2025 merecen re-benchmark.
RBD live migration entre clústeres
Tentacle amplía las capacidades de RBD live-migration: se pueden importar imágenes desde otro clúster Ceph en formato nativo, o desde fuentes externas vía flujos NBD soportados. RBD mirroring gana soporte de remapping de namespace. Para organizaciones con varias islas Ceph, ésta es probablemente la capacidad más estratégica de Tentacle — una herramienta para consolidar clústeres pequeños, vaciar infraestructura vieja y planificar una migración en fases en vez de agendar un corte único aterrador.
Ceph NVMe-oF, SMB integrado y multitenencia S3 más sólida — un solo stack operativo
Tentacle amplía la superficie de servicio práctica de Ceph: los grupos de gateway NVMe/TCP y namespaces múltiples reciben mejor gestión; los servicios SMB integrados exponen shares respaldados por CephFS vía Samba y CTDB; el resharding de bucket RGW reduce el impacto visible al cliente durante mantenimientos de buckets grandes; IAM Accounts sigue avanzando hacia una multitenencia S3 más sólida; y el management gateway cephadm proporciona un punto de entrada con TLS que se integra con OAuth 2.0 / OpenID Connect. Esto refuerza el caso de una plataforma Ceph común sirviendo a más de un consumidor — block vía RBD, objeto vía RGW, ficheros vía CephFS o SMB, NVMe/TCP donde los clientes lo pidan.
Crimson y SeaStore siguen siendo tech preview en Tentacle — merece tiempo de laboratorio, no puede ser la base de un diseño crítico de producción en 2026.
OpenStack Gazpacho — baseline de producción, no razón para cambiar el almacenamiento
OpenStack 2026.1 Gazpacho se publicó el 1 de abril de 2026 como release SLURP mantenida, permitiendo rolling upgrade desde Epoxy y saltándose Flamingo. Cambios relevantes para almacenamiento: Nova gana live migration paralela, un QEMU IOThread por instancia por defecto y attach de volumen asíncrono desde microversion 2.101 (notas Nova). Cinder añade selección más precisa de región para endpoints de backup de Glance y Swift, más mejoras continuas de drivers empresariales (notas Cinder).
Léelo con ojo de ingeniera. El async attach mejora el comportamiento del plano de control; no hace rápido a un backend lento. La live migration paralela acorta ventanas de mantenimiento; también genera picos de demanda sobre el fabric de almacenamiento y red. Gazpacho mejora la maquinaria. La arquitectura sigue decidiendo el resultado.
Hibiscus llega hacia el 30 de septiembre con Nova moviéndose a native threading por defecto. Prueba eso en staging bajo Gazpacho primero — upstream lo recomienda así (Nova unreleased). Y hagas lo que hagas, no pongas en el mismo fin de semana un OpenStack major, un Ceph major, una migración a EC, un rediseño de red y un movimiento de cargas. Tu plataforma puede necesitar los cinco cambios. No necesita las cinco sorpresas.
3 preguntas, una recomendación inicial
Tres preguntas rápidas para ubicar tu situación en el mapa. Sin datos, sin correo — todo corre en tu navegador. Si quieres profundizar, el whitepaper de abajo cubre las mismas decisiones al completo, con la autoevaluación de 20 preguntas y el plan mes a mes hasta fin de año.
¿Qué movimiento de almacenamiento encaja en tu situación?
Responde las tres preguntas y te enseñamos la recomendación inicial. Es un punto de partida para la conversación, no una lista de materiales.
Juega con tus propios números — Ceph erasure coding frente a réplica, y el impuesto del silo
Dos calculadoras en vivo. Escribe tus cifras y verás el trade-off aparecer. Ambas corren en tu navegador — no se envía nada a ningún sitio. Aproximadas a propósito; la metodología completa está en el whitepaper.
FastEC frente a réplica ×3
Cuánta capacidad útil sacas de verdad del TB bruto — con el ISA-L por defecto de Tentacle y FastEC opt-in (allow_ec_optimizations).
Pasar de réplica ×3 a EC 6+2 te da +417 TB del mismo pool bruto. En block de propósito general, imágenes y objeto — merece re-benchmark. En escrituras aleatorias pequeñas síncronas — sigue probándolo con tu carga.
Solo teórico. Excluye reservas de espacio libre, overhead BlueStore, restricciones de failure domain. Convertir hoy un pool replicado a EC es un proyecto de migración de datos.
El contador de los cuatro impuestos
Estimación gruesa de lo que N silos accidentales te cuestan cada año — en capacidad varada y operaciones duplicadas. Ilustrativo, no una cotización.
Una plataforma compartida absorbiendo la mitad de esos silos recuperaría la mayor parte de ese impuesto en 3 años. No el número completo — ninguno lo es nunca — pero suficiente para financiar el assessment que te dice el número real.
Modelo por regla de tres: ~15% de reserva varada por silo · ~30 k€/año de ops por silo (monitorización, upgrades, guardia, cualificación de spares). Usa la metodología completa del whitepaper para lo que vaya al CFO.
Cinco preguntas que grapar a cada compra de almacenamiento
Una plataforma dedicada se justifica cuando la propia frontera aporta valor — regulación, soberanía, geografía, propiedad independiente, requisito explícito de blast radius, incompatibilidad de cargas probada en test, o escala extrema. «El equipo del proyecto quería sus propios juguetes» no aparece en ningún sitio de esa lista.
Antes de firmar la próxima orden, produce respuestas escritas y con evidencia a estas cinco:
- ¿Qué frontera exacta estamos creando?
- ¿Qué riesgo reduce, y cómo mediremos esa reducción?
- ¿Qué coste duplicado introduce la frontera? (capacidad, ops, consistencia, migración)
- ¿Por qué no pueden satisfacer el requisito los pools, identidades CephX, cuotas, reglas CRUSH, device classes o volume types?
- ¿Qué prueba de laboratorio ha descartado la opción compartida?
Sin respuestas basadas en evidencia → no es un requisito, es una preferencia. Las preferencias están permitidas. Lo que no está permitido es disfrazarlas de arquitectura.
Qué hacer con el resto del presupuesto de 2026
El peor resultado de fin de año no es un presupuesto sin gastar. Es un presupuesto totalmente gastado que crea cinco años de coste operativo evitable. Cinco hitos de aquí a diciembre — márcalos según los vayas completando.
Capacidad bruta y útil, consumo real, exposición al thin provisioning, volúmenes e imágenes huérfanos, percentiles de latencia y throughput, fechas EOL, compatibilidad de drivers Cinder, proyección de crecimiento a 2029. No dimensiones solo con las estimaciones del dueño de la aplicación.
Máxima reutilización de cabinas actuales · híbrido cabinas + Ceph compartido · Ceph nuevo o ampliado como principal. Compara coste a cinco años, complejidad de migración, eficiencia de capacidad, esfuerzo del equipo, coste de salida. Corre la reserva de suministro en paralelo para proteger los medios con lead time largo.
Rendimiento normal, latencia percentil 95 y 99, operación degradada, fallo de disco y host, recovery y backfill, snapshot y clone, live migration, backup y restore, pasos de upgrade. Nada de benchmark sintético contra un clúster vacío.
Olas de migración, condiciones de rollback, runbooks, formación del equipo antes del cutover a producción. Un runbook escrito durante un incidente se llama transcripción.
Si los medios no llegan antes de fin de año, dedica el presupuesto a fabric de red validado, spares cualificados, backup independiente, monitorización, automatización, ingeniería y formación. Un rack de NAND sin recovery probado y operadores formados no es un servicio de almacenamiento — es inventario.
Descarga el playbook completo — 20 preguntas, 5 criterios de filtro, 4 patrones arquitectónicos
El post de arriba es el resumen. El whitepaper es la versión completa: la autoevaluación de veinte preguntas, los cinco criterios del filtro de decisión, los cuatro patrones arquitectónicos con cuándo usar cada uno, un modelo ilustrativo de presupuesto 2026, y cómo secuenciar assessment / arquitectura / PoC / compra / migración de aquí a fin de año. Escrito para el CTO, el arquitecto y quien está a punto de renovar.
Descarga el whitepaper de almacenamiento H2 2026
Deja tu nombre y correo — te enviamos el whitepaper al inbox. Sin llamada comercial ni drip campaign. Si además te interesa el Substack de LibrePower sobre open source en IBM Power, marca la casilla; terminas la suscripción con un clic desde el correo de confirmación.
Usamos Google Forms para recoger tus datos. Se tratan bajo la política de privacidad de SIXE. Puedes darte de baja cuando quieras.
Compra almacenamiento cuando necesites almacenamiento. Levanta una frontera cuando necesites una frontera.
Haz que Ceph compartido sea el candidato por defecto para capacidad compartida nueva, deja que las cabinas se queden con lo que se ganan, y aprueba clústeres dedicados solo cuando la frontera aporte valor medible. Todo lo demás es preferencia disfrazada de arquitectura.
Hacemos consultoría Ceph y soporte L3, formación Ceph con laboratorios y certificación Credly, diseño y migración de nube privada OpenStack y almacenamiento IBM empresarial. Sea cual sea tu decisión, la ejecutamos nosotros.
Las preguntas que más nos llegan
¿Necesito un clúster Ceph nuevo para un despliegue nuevo de OpenStack?
No. OpenStack Cinder está diseñado para consumir múltiples backends — incluidas tus cabinas actuales de IBM, Dell, NetApp, Pure o Hitachi — a través de sus drivers oficiales. Un plano de control nuevo no exige un plano de datos nuevo. Exige inventario de lo que ya tienes y un catálogo de servicio por encima.
¿Qué cambia de verdad con Ceph Tentacle 20.2.2?
FastEC opt-in (erasure coding con mucho mejor comportamiento en I/O pequeño), RBD live migration nativo entre clústeres, gestión de gateways NVMe/TCP, SMB integrado vía Samba y CTDB, y multitenencia S3 más sólida con IAM Accounts. La release 20.2.2 (16 de junio de 2026) es la baseline de producción actual.
¿Es OpenStack Gazpacho la release correcta para H2 2026?
Para la mayoría de despliegues críticos en H2 2026, sí. Gazpacho (2026.1, publicada el 1 de abril) es SLURP: permite rolling upgrade desde Epoxy saltándose Flamingo. Hibiscus llega hacia el 30 de septiembre con Nova moviéndose a native threading por defecto — pruébalo pronto en staging y llévalo a producción con conocimiento.
¿Cuándo tiene sentido de verdad un clúster Ceph dedicado?
Cuando la propia frontera aporta valor medible: regulación o soberanía del dato, separación geográfica, propiedad independiente, requisito explícito de blast radius, cargas cuya incompatibilidad se ha probado en test, o escala muy grande. Que exista otro plano de control OpenStack no es, por sí mismo, motivo válido.
¿Es Ceph lo bastante seguro para datos de producción empresarial?
Sí, bien diseñado y bien operado. Bloomberg, CERN y DigitalOcean tienen documentados estados Ceph de decenas de PB a más de 100 PB. La durabilidad depende del diseño de dominios de fallo, del recovery probado y de operar con equipo — todo eso se contrata a tu escala. Ceph lo sostiene una fundación multi-vendor bajo la Linux Foundation y hay distribuciones enterprise con soporte L3 contractual.
¿Puedo mezclar cabinas empresariales y Ceph bajo el mismo OpenStack?
Sí, y para la mayoría de empresas con inversión previa en cabinas es el diseño más sólido para H2 2026. Las cabinas se quedan con las cargas donde son mejores; Ceph pasa a ser el candidato por defecto para capacidad compartida nueva. Cinder expone ambas con volume types por servicio (block-critical-replicated, block-standard, block-capacity).
¿Quieres las cinco opciones puntuadas con tus números?
Tú traes el inventario. Nosotros el laboratorio. Un informe corto con el coste a cinco años de cada opción aplicada a tu parque real — reutilizar las cabinas que tienes, híbrido cabinas + Ceph compartido, Ceph nuevo o ampliado, Ceph dedicado o hiperconvergente. La primera conversación es gratis. Si no encajamos, no encajamos. Si sí, ya nos lo dirás.
Blog!
Nuestra mision
SIXE garantiza que tus infraestructuras basadas en tecnologías IBM®, Red Hat®, Canonical® y SUSE® permanezcan estables, seguras y optimizadas durante todo el tiempo que las necesites.
En SIXE, nos comprometemos con la sostenibilidad. Por eso te ayudamos a diseñar, implementar y mantener soluciones tecnológicas duraderas y eficientes.
