El mapa de releases: Tentacle arriba, Reef fuera, Umbrella en camino

Si tu última foto mental del calendario de Ceph es de 2024, está desactualizada. Esto es lo que hay encima de la mesa a fecha de publicación de este post:

La transición más importante aquí es la de Reef. El equipo de release anunció en marzo que v18.2.8 era la última — y previsiblemente la definitiva — backport release de la rama Reef. A partir de ahí, Reef entra en modo "si tienes un problema crítico, toca resolverlo actualizando". Si estás en Reef, ya no estás en una rama mantenida activamente. Hay que mover.

Tentacle, por su parte, es un salto mayor con calado real. Se publicó como versión estable inicial (v20.2.0) en noviembre de 2025, y la v20.2.1 del 6 de abril de 2026 corrige varios bugs significativos detectados en los primeros meses en producción — especialmente uno crítico en Erasure Coding que afectaba al scrub de pools con FastEC activado. Volvemos a ese punto en un momento.

Y luego está Umbrella, la próxima major. No hay fecha firme todavía, pero la presentación en FOSDEM 2026 ha dejado claro el enfoque: recorrer de arriba abajo la experiencia de CephFS, con mejoras en disaster recovery, métricas, tuning de MDS y protección de datos de usuario. Si tu caso de uso principal es fichero (HPC, media, home directories a escala), Umbrella es la versión que vas a querer mirar con calma.

FastEC: la mejora que cambia la ecuación de coste por TB

Si tuviéramos que elegir una sola novedad de Tentacle para explicar por qué esta release importa, sería FastEC. Es un cambio que se describe en una frase y cuya consecuencia tarda un rato en calar: la pipeline de I/O para Erasure Coding ha sido reescrita, con mejoras de rendimiento sustanciales y algunas mejoras de capacidad para pools EC. Se activa por pool mediante el flag allow_ec_optimizations. Los clientes no necesitan actualizarse.

¿Por qué esto importa tanto? Porque hasta ahora, en la mayoría de despliegues serios, la regla de oro era esta: replicado para lo que rinde (virtualización, bases de datos, CephFS con mucho metadata); Erasure Coding solo para lo que puede permitírselo (objeto frío, backups, archivado). La razón era puramente de rendimiento: EC tradicional tenía una penalización de escritura y una latencia que lo hacían poco adecuado para bloque o fichero con cargas mixtas. FastEC cambia esa regla. No del todo, no en todos los casos — pero sí lo suficiente como para que muchas cargas que antes solo tenían sentido en replicado de tres copias puedan moverse a EC con una relación de eficiencia mucho mejor.

Traducido a dinero, esto se parece bastante a esto:

El número exacto depende del perfil EC que uses (4+2, 6+3, 8+3...) y de la distribución física, pero el orden de magnitud es real. En un clúster de medio petabyte, estamos hablando del tipo de ahorro que justifica un proyecto entero.

Dos avisos importantes, porque no queremos que nadie se lleve sorpresas:

El segundo aviso es más general. FastEC no es magia: sigue habiendo cargas para las que EC, incluso optimizado, no es la respuesta correcta — sobre todo IOPS muy altos con bloque pequeño y latencia muy ajustada (piensa en OLTP serio). La decisión de qué pools van en replicado y cuáles en EC sigue siendo una decisión de arquitectura, no de flag. Lo que ha cambiado no es que ahora todo vaya en EC; es que la conversación sobre "replicado vs EC" ya no está tan decantada hacia replicado como lo estaba hace dos años.

Más allá de FastEC: lo que cambia por dentro

FastEC se lleva los titulares, pero no es el único cambio de calado. Estas son las piezas que importan en operación del día a día:

BlueStore: compresión mejorada y un WAL nuevo

El almacén de objetos nativo de Ceph ha recibido dos cambios importantes. La compresión ha mejorado en eficiencia y velocidad, y hay un WAL (write-ahead log) nuevo y más rápido. El efecto práctico es menos latencia en escritura y menos amplificación sobre los dispositivos físicos — especialmente relevante en clusters de NVMe, donde las write amplification heredadas de generaciones anteriores se notaban.

Data Availability Score por pool

Un nuevo indicador por pool que permite ver "cómo de disponibles están de verdad los datos de este pool", teniendo en cuenta réplicas, EC, fallos históricos y recovery. Suena marketing, pero no lo es — para clusters con multi-tenant interno (por ejemplo, un pool para RGW S3 y otro para RBD con SLAs distintos), tener una métrica directa por pool en el dashboard quita trabajo manual de cálculo sobre OSDs y PGs.

Live migration de RBD entre clusters

Este es el cambio que más hemos visto pedir en proyectos de consolidación. Ahora se pueden importar imágenes RBD de otro cluster Ceph, en formato nativo, o desde una gran variedad de fuentes/formatos externos, de forma instantánea. Sin paradas, sin mover bytes antes de empezar a servir. El caso de uso típico: migración de clusters antiguos, consolidación de varios Ceph pequeños en uno grande, o import desde otro SDS o desde imágenes QCOW2. Para quien haya sufrido migraciones de RBD con rbd import en el pasado, esto es un cambio de juego.

CephFS: proxy propio para Samba y mejoras varias

Se despliega automáticamente un nuevo daemon cephfs-proxy que mejora escalabilidad y uso de memoria cuando Samba conecta con CephFS. Además, los directorios se pueden configurar con nombres case-insensitive o normalizados. Si has sufrido alguna vez montando SMB sobre CephFS en entornos mixtos Windows/Linux, esta es la parte que lleva tiempo pidiéndose.

NVMe/TCP para gateway groups y multi-namespace

Ceph lleva tiempo empujando NVMe-oF sobre TCP como puente hacia el almacenamiento de bloque tradicional. En Tentacle, los gateways NVMe/TCP soportan grupos y múltiples namespaces, gestión multi-cluster y OAuth 2.0. El escenario evidente es dar almacenamiento de bloque a hosts VMware o a otros hipervisores sin pasar por iSCSI y sin SAN propietaria. IBM ha sido muy explícito con esta visión y es una de las razones por las que Ceph está entrando en conversaciones donde antes solo se hablaba de vSAN.

SeaStore en tech preview (con Crimson OSD)

SeaStore — el almacén de objetos de próxima generación, diseñado para hardware NVMe moderno y con threading estructurado — es desplegable en preview junto a Crimson-OSD. Esto no es para producción todavía, pero sí es la primera vez que se puede probar end-to-end en un Tentacle estable. Para laboratorios y equipos que quieran familiarizarse con hacia dónde va Ceph en los próximos años, merece el rato.

Lo que se ha ido

Los módulos restful y zabbix, deprecados desde 2020, se han eliminado oficialmente. Si tu monitorización dependía del módulo Zabbix nativo, toca migrar a Prometheus + exporter de Ceph, que es la vía oficial desde hace tiempo.

El factor IBM, watsonx.data y la salida de Broadcom-VMware

La parte técnica de Ceph nunca ha sido el problema. Lo que impedía a muchas empresas españolas mirarlo en serio era el factor "esto es muy open source, no lo veo aprobado por comité". En 2026 ese argumento se ha caído solo, por dos vías independientes que se refuerzan.

IBM watsonx.data incluye 768 TiB de Ceph "de serie"

Desde hace un par de años, IBM ha hecho de Ceph el almacenamiento por defecto del lakehouse on-premise de watsonx.data. IBM Storage Ceph es un producto empresarial con precios publicados desde 0.026 USD/GB/mes, soporte 24/7, integración con Apache Iceberg, Apache Parquet, watsonx.ai, y el ecosistema Red Hat completo (OpenShift, OpenStack). La consecuencia práctica: cuando un CISO o un director de infraestructura pide "una opción soportada por un fabricante gran cuenta", Ceph ya no es "solo comunidad". Es un producto IBM con contrato, SLA y escalado de incidencias.

Broadcom-VMware ha empujado a medio sector a buscar alternativas

No hace falta que nos extendamos en esto. La subida de precios y el cambio de modelo de licenciamiento de VMware desde la compra por Broadcom ha abierto oficialmente la puerta a revisar las pilas de virtualización y almacenamiento. En esa revisión, el combo Proxmox + Ceph, o OpenStack + Ceph, o OpenShift/Kubernetes + Rook-Ceph, está entrando en bastantes shortlists que hace dos años no se planteaban.

Ceph, por diseño, encaja bien en esa conversación porque cubre los tres tipos de almacenamiento en una sola plataforma — bloque para VM y contenedores, fichero para datos compartidos, objeto S3 compatible para backups y datos no estructurados. Eso lo diferencia del resto del catálogo SDS open source: MinIO hace muy bien objeto, pero no bloque ni fichero; Longhorn es bloque para Kubernetes pero no objeto. Ceph hace los tres con el mismo cluster, y eso en proyectos reales ahorra cabinas, ahorra licencias y ahorra pliegos.

Proxmox, Rook y el empuje del ecosistema

Ceph no existe solo. En 2026, tres ecosistemas están tirando del carro y vale la pena mirarlos por separado porque cada uno aporta un ángulo distinto.

Proxmox VE: Ceph integrado y ahora Tentacle en preview

Proxmox lleva años integrando Ceph de forma nativa como almacenamiento del cluster de virtualización. En enero de 2026 Proxmox publicó Ceph 20.2 Tentacle como test preview, con plan de mover a no-subscription una vez estabilice. Para entornos que ya están en Proxmox, esto significa acceso a FastEC, live migration RBD y NVMe/TCP sin cambiar nada más del stack. Proxmox sigue en Squid como default estable y lo mantendrá hasta septiembre de 2026, así que hay margen para planificar.

Rook y el mundo Kubernetes

Rook, el operator oficial de Ceph en Kubernetes, ha recibido actualizaciones importantes. Ceph-CSI v3.16 ya recomienda Ceph-CSI-Operator como mecanismo de despliegue estándar, e introduce driver NVMe-oF CSI para acceder al almacenamiento por NVMe over Fabrics desde Kubernetes. Para equipos que están construyendo plataformas internas tipo IDP sobre Kubernetes, esto abre posibilidades de rendimiento que antes requerían compromisos.

OpenStack y el campo empresarial

En OpenStack, Ceph sigue siendo el almacenamiento de referencia para Cinder (bloque), Glance (imágenes) y Swift-replacement con RGW (objeto). El trabajo de IBM/Red Hat sobre OpenStack y Ceph es continuo, y para organizaciones con necesidades de cloud privado a escala es, probablemente, la combinación más madura del mercado libre.

¿Qué significa todo esto junto? Que Ceph no depende de un único camino de adopción. Hay tres puertas de entrada naturales — virtualización (Proxmox), contenedores (Rook/OpenShift) y nube privada (OpenStack) — y las tres están activamente mantenidas por equipos grandes. Esa diversidad es, probablemente, la razón estructural por la que Ceph es la pieza de SDS open source más difícil de matar.

Cuándo actualizar y cómo hacerlo sin estropear nada

Esta es la parte práctica. Tenemos cuatro escenarios típicos y una respuesta razonable para cada uno:

1. Clúster nuevo desde cero (proyecto greenfield). Directamente Tentacle v20.2.1 o posterior. Con ISA-L como plugin EC por defecto (cambio de Jerasure a ISA-L en pools nuevos), FastEC disponible desde el primer día, y sin deuda técnica heredada. Es el escenario más limpio.
2. Clúster en producción en Squid (v19.x). Sin urgencia. Squid sigue soportada y funcionando bien. La decisión depende de qué features de Tentacle te aportan valor: si necesitas FastEC, live migration RBD, o NVMe/TCP avanzado, planifica el upgrade para Q3 2026 esperando a v20.2.2 o posterior. Si no las necesitas, puedes esperar con tranquilidad a mitad de vida de Tentacle.
3. Clúster en producción en Reef (v18.x). Hay que migrar. Reef está en fin de vida tras v18.2.8. La ruta oficial recomendada es Reef → Squid → Tentacle, no Reef → Tentacle directamente — y especialmente no desde Pacific, porque QA ha detectado problemas con upgrades directos desde Pacific. Haz el salto en dos pasos y con ventanas de mantenimiento bien planificadas.
4. Clúster en Pacific, Quincy o anterior. Esto ya no es "mantenimiento", es deuda técnica activa. Pacific está fuera de soporte, Quincy está en sus últimas backport releases. Si sigues en alguna de esas ramas, es el momento de plantear un proyecto formal de modernización — no solo actualización, porque probablemente haya piezas de arquitectura (cephadm, containerización de daemons, dashboard) que también convenga repensar.

Tres principios de migración que no negociamos

En SIXE, cuando hacemos una migración o una actualización seria de Ceph para un cliente, trabajamos siempre con tres reglas. Las ponemos aquí porque funcionan también si lo gestionas tú mismo:

1. Laboratorio antes que producción. El flag allow_ec_optimizations, la activación de FastEC, el cambio de versión mayor — todo eso se valida primero en un clúster de pruebas con datos no críticos, incluso si es un clúster pequeño. El coste de mantener un laboratorio durante dos semanas es una fracción ínfima del coste de un incidente en producción.
2. Nunca saltar etapas. La escalera oficial Reef → Squid → Tentacle existe por buenas razones. Saltarse pasos ahorra dos semanas de proyecto y cuesta dos meses de depurar cosas raras. Respetamos la escalera y documentamos cada paso.
3. Ventana de rollback viable hasta el último momento. No se borran snapshots del filesystem, no se desactivan backups antiguos, no se retiran nodos viejos hasta que el clúster nuevo lleva funcionando un ciclo de scrub completo con cargas reales encima. Es más tedioso, sí. Y funciona.

Cómo encaja todo esto en un proyecto real

Si has leído hasta aquí, probablemente tu caso se parece a alguno de estos tres:

• Tienes Ceph en producción y necesitas planificar el salto a Tentacle o decidir si FastEC te aplica. Aquí el trabajo es de arquitectura: revisar perfiles EC actuales, dimensionar el cambio, planificar la ventana de upgrade, validar en laboratorio.
• Tienes VMware con vSAN y el coste de renovación te ha hecho mirar alternativas. Aquí la pregunta es de diseño: qué workloads se mueven primero, qué arquitectura Ceph encaja (Proxmox? OpenStack? Rook?), cómo se migran los datos sin parar el servicio.
• Arrancas un proyecto nuevo — lakehouse, plataforma de contenedores, cloud privado — y Ceph es una de las opciones sobre la mesa. Aquí conviene diseñar desde el principio con Tentacle, dimensionar bien la red (spoiler: la red es casi siempre el cuello de botella, no los discos), y elegir la puerta de entrada (k8s vs virtualización vs bare metal).

En los tres casos, el orden sensato es el mismo: conversación técnica corta para entender el caso, propuesta de arquitectura con opciones y trade-offs claros, laboratorio de validación, y proyecto de despliegue con ventanas planificadas. No hay atajos que funcionen bien a medio plazo.

Para seguir leyendo sobre Ceph en SIXE

• Migración a Ceph sin downtime — cómo abordamos migraciones desde cabinas propietarias, vSAN o clústeres Ceph antiguos
• Curso oficial de administración Ceph — formación técnica certificada para equipos que van a operar el día a día del clúster
• Soporte urgente 24/7 — para clusters en producción donde un problema a las 3 de la mañana es un problema de verdad
• Inferencia de IA on-premise sobre Ceph — cuando el almacenamiento distribuido es la base de cargas de IA privadas