En la documentación de Ceph hay una tabla que no aparece en ninguna nota de prensa y que ordena el trabajo de este otoño mejor que cualquier hoja de ruta: la de ciclo de vida de las versiones. Dice que Squid (19.2) —la rama que hay debajo de casi todos los clusters hiperconvergentes montados en los dos últimos años— tiene el fin de vida estimado el 19 de septiembre de 2026. Cincuenta días desde hoy. Lo que hace daño llega al mirar de cerca: actualizar Ceph casi nunca cabe en una sola ventana.
Operamos Proxmox VE con Ceph en producción repartido en varios datacenters, así que esta cuenta atrás nos toca de lleno y la hemos hecho para nosotros antes de escribirla. Esto es lo que hemos sacado: las fechas reales, la secuencia obligada y el orden en que va, dos cambios de Tentacle que se pasan por alto y el orden concreto de comandos. Nada de esto es dramático. Lo que sale caro es descubrirlo el sábado a las once de la noche.
Las tres fechas que mandan
Todo sale de la tabla oficial de versiones. Las fechas de fin de vida futuras están marcadas como estimadas, y conviene leerlas así: el proyecto publica una intención y ya la ha movido otras veces.
Leído del derecho: Squid recibió una versión de mantenimiento a mediados de julio y le quedan siete semanas. Tentacle lleva ocho meses de rodaje y dos versiones de mantenimiento encima. Reef está entre las archivadas desde marzo del año pasado, es decir, sin mantenimiento; si tu cluster todavía está ahí, la conversación es otra y más urgente.
En Proxmox la cosa fue a su propio ritmo. Cuando Tentacle llegó a sus repositorios, en enero, estaba solo en test y con la etiqueta de vista previa bien puesta. Ya no: Proxmox VE 9.2, del 21 de mayo, cambió el valor por defecto para instalaciones nuevas —pveceph install en un nodo sin Ceph y el asistente de un cluster sin Ceph proponen ya Tentacle 20.2.1—, y un desarrollador de Proxmox lo confirmó por escrito en julio: quedó marcado como estable con la 9.2. Los clusters que ya existen no se mueven solos, porque el asistente sigue fijando los nodos nuevos a la versión que el cluster ya usa. Esa parte sigue siendo trabajo tuyo.
Por qué no es un salto, son tres
Aquí está el nudo. Ceph, en un cluster hiperconvergente, no se actualiza solo: va atado a la versión de Proxmox que tiene debajo. La guía oficial de Squid a Tentacle pide Proxmox VE 9.1 o superior (con pve-manager 9.1.4 o más nuevo y paquetes de Ceph 19.2.3-pve3 en adelante). Y la guía de actualización de Proxmox VE 8 a 9 pide lo contrario en el otro extremo: llevar Ceph a Squid antes de empezar el salto del hipervisor.
Junta las dos reglas y sale una secuencia que no elige nadie: Ceph a Squid → Proxmox VE a 9 → Ceph a Tentacle. Tres trabajos distintos, cada uno con su ventana y su comprobación del día siguiente. Si estás en Reef y en Proxmox VE 8, tienes las tres por delante y, además, la rama 8 del hipervisor caduca este agosto: hablamos de eso hace dos días en el artículo sobre el fin de soporte de Proxmox VE 8. Dos cuentas atrás encadenadas —la de la rama 8, que Proxmox fecha solo por mes (2026-08), y la de Squid, que sí tiene día: el 19 de septiembre— y un orden que no admite atajos.
Upstream, por cierto, es algo más permisivo: las notas de Tentacle dicen que hay que estar en Reef (18.2.z) o en Squid (19.2.z) para saltar. Pero en Proxmox lo que hay documentado son dos guías separadas, Reef a Squid y Squid a Tentacle, y nosotros vamos con las guías. En almacenamiento distribuido, la creatividad se paga con datos.
Quince minutos de comprobaciones antes de decidir nada
Antes de poner fechas en un calendario hay que saber de dónde se sale. Esto se hace hoy, con el cluster tranquilo y a plena luz del día, no la noche de la ventana:
Con esas seis salidas ya sabes en qué escalón estás, cuántas ventanas te separan de Tentacle y —esto se mira poco— si el salto te va a dejar sin visibilidad. Vamos a ello.
El módulo que desaparece (y a quién le va a doler)
Tentacle elimina dos módulos del manager: mgr/restful y mgr/zabbix. Las notas de la versión no se andan con rodeos: estaban obsoletos desde 2020, nadie los mantenía activamente y arrastraban vulnerabilidades en su cadena de dependencias. Como decisión de proyecto nos parece la correcta —código sin dueño dentro del componente que lo ve todo del cluster acaba costando más de lo que da—, pero si tu monitorización de Ceph pasa por ahí, el día que actualices dejas de recibir datos y el aviso te lo va a dar el silencio.
Nosotros monitorizamos con Zabbix, y lo que sacamos de esto es simple: la monitorización va dentro del plan de actualización, no en sus consecuencias. Si ceph mgr module ls te devuelve zabbix entre los activos, la sustitución (el módulo prometheus del propio manager, la vía del agente, o la integración que Proxmox publicó este año y que comentamos en este artículo) se monta y se valida antes del salto, no después. Un cluster sin métricas justo la semana en que acabas de tocarlo es exactamente el momento en el que más las necesitas.
Lo que cambia de verdad en Tentacle
La lista de novedades es larga; lo que de verdad mueve la aguja en un cluster de empresa cabe en cuatro puntos, y tres de ellos tienen letra pequeña:
- ✓Optimizaciones para erasure coding (FastEC): lecturas y escrituras parciales en pools con código de borrado, que es justo donde ese tipo de pool lo pasaba peor. La letra pequeña: no se activan solas. Hay que poner el flag
allow_ec_optimizationsen cada pool, y los pools existentes solo pueden hacerlo una vez actualizados los OSD y los monitores. Si tienes dudas sobre si tu pool debería ser réplica o código de borrado, ese debate lo hicimos con la cuenta hecha en réplica 3 frente a erasure coding. - ✓BlueStore mejora compresión y estrena un WAL más rápido. Es la clase de mejora que no se nota en una demo y sí en la cola de escrituras de un martes por la mañana. Aquí no hay que hacer nada: viene con el salto.
- ✓El plugin por defecto de erasure coding pasa de Jerasure a ISA-L, porque Jerasure ya no se mantiene. Ojo al matiz, que es el que evita sustos: solo afecta a los clusters creados en Tentacle o posterior. Los que actualizan conservan sus valores por defecto y sus pools no se tocan.
- ✓mClock incorpora umbrales mínimos de IOPS al medir la capacidad de cada OSD (50 en disco mecánico, 1.000 en SSD, ambos configurables). Traducido: si una medición sale absurdamente baja, el planificador deja de creérsela. Es una de esas mejoras que solo aprecias si alguna vez has visto un cluster autoestrangularse por una medida mala.
Y sobre ese primer punto, un aviso con historia. En 20.2.0, activar allow_ec_optimizations sobre un pool de código de borrado ya existente tumbó OSD en cadena en un cluster real —hay un análisis público del incidente, de enero, con la traza en ECTransaction::WritePlanObj— y además apareció una tanda de errores de scrub que resultaron ser falsos positivos: al activar las optimizaciones, los objetos escritos antes dejan de ir rellenados hasta el ancho de banda de la franja y el comprobador se confundía. La 20.2.1, de abril, trae correcciones de esa parte (entre ellas, prohibir las optimizaciones cuando el tamaño de trozo no está alineado a 4K) y la rama va ya por la 20.2.2. Nada de esto es motivo para no ir a Tentacle. Es motivo para activar el flag en un pool, mirarlo una semana con calma y seguir después, en vez de encenderlo en todos la misma tarde.
Ninguna de estas cuatro cosas justifica por sí sola una ventana de mantenimiento. La razón para saltar sigue siendo la de siempre y es más aburrida: al otro lado de septiembre, Squid deja de recibir arreglos, y las correcciones de seguridad en la capa donde viven los datos no son opcionales.
El orden del salto, sin misterio
La secuencia de Squid a Tentacle está en el wiki oficial y es corta. Lo que no está en el wiki es el ritmo: entre paso y paso se espera a que el cluster vuelva a HEALTH_OK, y nadie tiene prisa.
Dos avisos que el wiki da y que conviene tener presentes. Si usas CephFS, los demonios MDS tienen su propia coreografía: se desactiva el standby replay, se baja el número de rangos activos a uno, se paran los MDS en espera, se reinicia el que queda, se vuelven a arrancar los demás y al final se restauran max_mds y el standby replay. Y entre el punto 5 y el 6 el cluster te va a decir que todos los OSD corren Tentacle pero que require_osd_release sigue por detrás: ese aviso es normal y desaparece con el comando del punto 6. No hay nada roto: el cluster te está pidiendo que confirmes que ya no piensas volver atrás.
Ese último punto merece una frase más, porque es la parte incómoda: en Ceph, la vuelta atrás real no existe una vez has fijado la versión mínima de OSD. Tu plan B no es «deshacer», es restaurar. Por eso las copias verificadas —y una restauración que alguien haya cronometrado de verdad— forman parte del trabajo de esta ventana.
Cincuenta días, repartidos
Contando desde hoy, 31 de julio, así es como repartiríamos el trabajo para llegar al 19 de septiembre sin épica:
- 1.Esta semana: las seis comprobaciones de arriba. Sabes en qué rama estás, qué versión de hipervisor tienes debajo y si el módulo
zabbixestá en juego. Quince minutos, y ya no decides a ciegas. - 2.Primera quincena de agosto: la monitorización sustituta, montada y dando datos en paralelo. Y una restauración de prueba con cronómetro, que es el plan B de todo lo demás.
- 3.Segunda quincena de agosto: si sigues en Reef, Ceph a Squid. Es la precondición que el wiki de la actualización de Proxmox VE 8 a 9 pone por escrito, no una recomendación amable.
- 4.Finales de agosto: el salto del hipervisor a la 9, solo y con Ceph ya en Squid. Con el matiz que defendíamos hace dos días: si caes en alguno de los seis casos en los que ese salto no toca en agosto, Tentacle tampoco toca en septiembre. Llegar tarde a las dos en orden es mejor que llegar puntual a una y romper la otra.
- 5.Primeras dos semanas de septiembre: Squid a Tentacle, con la secuencia de arriba y el cluster mirado a la mañana siguiente. Deja la última semana libre a propósito; el margen está para eso.
Y si no llegas, tampoco pasa nada catastrófico el día 20: un fin de vida no es una bomba de relojería: marca el punto a partir del cual ya nadie arregla los fallos que aparezcan. Lo que sí pasa es que el riesgo se acumula sin avisar, y en almacenamiento distribuido eso se nota tarde y de golpe.
La parte aburrida es la que salva el cluster
La actualización de Ceph tiene mala fama y en general no se la merece: los pasos son pocos, están documentados y el proyecto lleva años haciéndolos aburridos a propósito. Lo que sí merece respeto es la planificación, porque el salto casi nunca viene solo. Nuestra regla operando estos clusters es corta: una cosa por ventana, el cluster en verde antes de cada paso, la monitorización viva desde el minuto uno y una fecha en el calendario con nombre y apellidos. Nada glamuroso, y funciona: el lunes por la mañana nadie se entera de que el fin de semana hubo trabajo.
Fuentes (verificadas): fechas de las ramas y fin de vida estimado (Squid 19.2 publicada el 26-09-2024, última 19.2.5 el 14-07-2026, fin de vida estimado el 19-09-2026; Tentacle 20.2.0 el 18-11-2025, 20.2.2 el 16-06-2026, fin de vida estimado el 18-11-2027; Reef 18.2 entre las versiones archivadas) — índice de versiones de Ceph. Eliminación de mgr/restful y mgr/zabbix («obsoletos desde 2020», sin mantenimiento y con vulnerabilidades en su cadena de dependencias), cambio del plugin por defecto de erasure coding a ISA-L solo en clusters nuevos, flag allow_ec_optimizations por pool, umbrales de mClock (50 IOPS en disco mecánico, 1.000 en SSD) y requisito de partir de Reef o Squid — notas de la versión Tentacle. FastEC y BlueStore (compresión y WAL) — anuncio de v20.2.0 Tentacle. Requisitos y secuencia del salto en Proxmox (PVE 9.1 o superior, pve-manager 9.1.4, Ceph 19.2.3-pve3, noout, orden monitores → managers → OSD → MDS, require-osd-release) — wiki oficial Ceph Squid to Tentacle. Estado en Proxmox: anuncio del 09-01-2026 con Tentacle solo en el repositorio de pruebas y Squid «soportado hasta septiembre de 2026 por ahora», más la confirmación de un desarrollador de Proxmox el 03-07-2026 de que quedó marcado como estable con Proxmox VE 9.2 — hilo oficial en el foro de Proxmox. Tentacle 20.2.1 como valor por defecto para instalaciones nuevas desde Proxmox VE 9.2 (21-05-2026), con los clusters existentes fijados a la versión que ya usan — hoja de ruta oficial de Proxmox VE. Caídas de OSD al activar allow_ec_optimizations sobre un pool de código de borrado existente en 20.2.0, con la traza en ECTransaction::WritePlanObj, y los errores de scrub por el cambio de relleno de los objetos — análisis público del incidente (13-01-2026). Correcciones de esa área y prohibición de las optimizaciones con tamaños de trozo no alineados a 4K en la 20.2.1 del 06-04-2026 — notas de la versión 20.2.1.
¿Tienes un cluster Ceph con fecha en el calendario?
En everyWAN diseñamos y operamos almacenamiento distribuido con Ceph en producción, junto a infraestructura Proxmox VE repartida en varios datacenters. Miramos tu cluster, te decimos cuántas ventanas te separan de Tentacle y en qué orden van — y si vemos que aguanta perfectamente hasta después de septiembre, también te lo decimos.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN