El salto de Ceph Squid a Tentacle es la ventana que toca abrir a quien no quiera cruzar el 31 de octubre sin parches nuevos. El procedimiento está escrito y es claro. Lo que no está en ninguna nota de versión es la factura: el salto te cobra el clúster que ya tenías. En los OSD creados en 2020 el espacio de metadatos se dispara, y lo que llega al panel de Proxmox es menos capacidad total. Dos módulos del manager llevaban seis años marcados como obsoletos y aún corriendo en tu clúster; ahora desaparecen de verdad. Y el paso del sistema de ficheros te pide, por escrito, que te quedes un rato sin standby. Nada de eso es un fallo: está todo documentado. El problema es que no suele estar apuntado en la ventana de mantenimiento.
La fecha, en dos líneas
El calendario oficial de Ceph marca el 31 de octubre de 2026 como fin de vida estimado de la rama Squid (19). La palabra entre paréntesis es suya: la tabla pone «End of life (estimated)» para Squid y para Tentacle, y «End of life» a secas para Reef, que ya cerró el 20 de marzo. La diferencia no es cosmética y la letra pequeña de esas fechas ya la desgranamos en septiembre. La 19.2.7, del 12 de octubre, es la última Squid publicada; Tentacle (20) está disponible desde el 18 de noviembre de 2025 y su fecha estimada es el 1 de junio de 2027.
Hace dos semanas contábamos que el último parche de Squid tardaba en llegar al repositorio de Proxmox. Hoy, a las 17:05, hemos vuelto a mirar los índices públicos de download.proxmox.com y la foto ha cambiado a medias: ceph-squid para trixie ya sirve 19.2.7-pve1… pero solo en el componente test. En no-subscription lo más alto sigue siendo 19.2.6-pve4. Si tu clúster va con el repositorio gratuito y no piensas saltar, cruzas el 31 con el penúltimo parche de una rama que deja de tenerlos. Es un riesgo pequeño y acotado, pero conviene escribirlo en algún sitio en vez de suponerlo.
La pareja de versiones que nunca existió
Esta es la parte que más nos gusta de la nota de Tentacle, porque cambia cómo hay que leer cualquier matriz de compatibilidad. Dice, literalmente, que actualizar a la última versión menor de la serie de destino es el único camino soportado y probado desde una versión anterior, y da la razón: una versión no se puede probar contra versiones que no existían cuando se publicó.
La dirección del problema sorprende la primera vez: la 19.2.6 es posterior a varias versiones de Tentacle —salió el 19 de agosto de 2026 y la 20.2.3 el 5—, así que esa pareja concreta jamás pudo probarse. El «cambio de tipos de clave» tiene nombre y apellidos en el wiki de Proxmox: Squid 19.2.6 y Tentacle 20.2.4 añadieron comprobaciones de salud para las claves con cifrado aes afectadas por CVE-2025-30156. Si eso te suena, es porque ya hablamos de la migración de claves cephx cuando aparecieron esos avisos.
Aquí es donde conviene mirar el repositorio en vez de suponerlo, así que lo medimos. El de ceph-tentacle de Proxmox sirve hasta 20.2.4-pve5, con lo que quien siga el wiki y deje que apt coja la más alta aterriza bien. Curiosamente, la 20.2.3 del ejemplo upstream nunca llegó a ese repositorio: están la 20.2.0, la 20.2.1, la 20.2.2 y luego directamente la 20.2.4. Y las tres primeras siguen ahí, publicadas al lado de la buena, esperando a quien tenga un pin, un paquete en hold, una réplica interna congelada hace meses o una caché de apt-cacher que recuerde demasiado.
Hay un detalle que une dos párrafos de arriba y que conviene no pasar por alto: el tope del repositorio gratuito para trixie es 19.2.6-pve4, que es exactamente la versión de origen sobre la que avisa la nota de Tentacle. Quien va con no-subscription y no ha tocado nada está, por definición, en el caso del aviso.
Los OSD que creaste en 2020
El wiki de Proxmox tiene una sección de problemas conocidos con una sola entrada, y es la que te va a tocar si tu clúster tiene años: los OSD creados en Ceph Octopus (v15, principios de 2020) y anteriores pueden ver un aumento del uso de META tras la actualización a Tentacle, hasta la versión 20.2.4. El ticket de seguimiento es el 76256 y se titula, sin eufemismos, bluefs: META space usage explodes on osds without sharding after upgrade to tentacle.
Ojo a ese «hasta la versión 20.2.4», porque se lee al revés de lo que dice: la 20.2.4 es, a día de hoy, la última Tentacle publicada, y el repositorio de Proxmox no sirve nada por encima. Traducido: todavía no existe una Tentacle en la que esto esté resuelto. El arreglo está fusionado en la rama de desarrollo (v21) y el backport a Tentacle sigue en cola, que es lo que significa el estado «Backporting» del ticket.
La causa está escrita en la misma página: la RocksDB de esos OSD no usa sharding, que pasó a ser el comportamiento por defecto a partir de Ceph Pacific (v16). Un OSD creado en 2020 ha cruzado Octopus, Pacific, Quincy, Reef y Squid sin que nadie lo rehiciera. Las actualizaciones heredan el formato interno del disco que ya estaba ahí.
Y ahora la parte que acaba en el comité de dirección: el síntoma llega disfrazado de capacidad. Textualmente, «puede presentarse como una disminución del Total Space en la interfaz web de Proxmox, porque Ceph calcula el espacio disponible a partir del OSD más lleno». Ya escribimos sobre ese mecanismo cuando tocaba explicarlo en frío: en Ceph la capacidad la marca el disco más lleno. Aquí lo tienes aplicado. Tu clúster no ha perdido discos, no ha perdido datos y está en verde; simplemente, el OSD más viejo se ha comido unos gigas de metadatos y el cálculo de capacidad lo toma a él como referencia. La verificación es una sola orden, ceph osd df, mirando la columna META.
Lo mejor del ticket es que trae la salida real. Tres OSD idénticos de un clúster desplegado originalmente en 15.2.13, tres hosts, un disco por OSD. La columna META marca 15 GiB en el primero, 14 GiB en el segundo y 346 GiB en el tercero, que se queda al 95,29 % de uso y 33 GiB libres mientras los otros dos andan por el 48 y el 51 %. Y el remate: en ese mismo OSD, la suma de los ficheros que RocksDB tiene realmente en BlueFS son 8 GB. Trescientos y pico gigas ocupados para ocho de contenido.
El apaño temporal está documentado: compactar la RocksDB a mano con ceph daemon osd.# compact, con el aviso de que es intensivo en entrada/salida y que hay que hacerlo de una en una y fuera de hora punta. Pero es un apaño que vuelve: quien abrió el ticket cuenta que estuvo jugando al topo con el compact y que el problema reapareció en todos los OSD de su clúster varias veces. Lo que aguanta son las otras dos salidas, que también están en el wiki y casi nadie lee: aplicar sharding al OSD —solo se puede con el OSD parado— o destruir y recrear los OSD afectados de uno en uno, que ya nacen con la estructura nueva. Ninguna de las dos es «alargar la ventana»: es un proyecto con su propio calendario.
Dos módulos que ya no están
Tentacle retira dos módulos del manager: mgr/restful y mgr/zabbix. La nota de versión es explícita sobre el porqué: estaban obsoletos desde 2020, no se han mantenido de forma activa en los últimos años y empezaron a arrastrar vulnerabilidades en su cadena de dependencias (citan CVE-2023-46136). Como alternativa proponen el módulo dashboard para lo que hacía el restful, y prometheus —«el más adoptado en la comunidad de Ceph»— para lo que hacía el de Zabbix.
Que mgr/zabbix iba a desaparecer ya lo marcamos como punto ciego cuando todavía era un aviso a futuro: lo contamos en julio, cuando esto era un plan a cincuenta días. Lo que ha cambiado desde entonces es el tiempo verbal. Un módulo de monitorización que se va deja la gráfica plana, y una gráfica plana se lee como «no hay novedades», que es justo lo contrario de lo que está pasando. Si tu Zabbix lee el estado de Ceph por ahí, el trabajo de monitorización va antes del salto. Y como Zabbix 8.0 LTS llega en noviembre, cuadrar las dos cosas en la misma planificación sale más barato que hacerlas dos veces.
El paso en el que te piden quitar tu propia redundancia
Si usas CephFS, lee el procedimiento entero antes de abrir la ventana. Para actualizar los MDS te pide desactivar allow_standby_replay, bajar max_mds a 1 —esto último solo hace falta si corres más de un MDS por sistema de ficheros—, parar todos los MDS en standby con systemctl stop ceph-mds.target, confirmar que solo queda uno activo, reiniciarlo y volver a levantar los demás. Durante ese rato tu sistema de ficheros tiene un único MDS y cero suplentes.
Esa es la forma correcta de hacerlo, y aun así significa que durante unos minutos la redundancia que pagas no está. A eso se le suma el noout que el propio procedimiento recomienda poner al principio, y conviene recordar qué hace exactamente: noout apaga la reposición de copias mientras está puesto. Si un disco se muere en mitad del salto, Ceph no va a fabricar la copia que falta hasta que lo quites. Las dos decisiones son correctas y las dos estrechan el margen a la vez. Por eso la hora a la que abres la ventana no es un detalle de agenda.
Si estás en Proxmox VE 8, esto no va contigo
Lo hemos comprobado hoy, porque es el hecho que cambia la conversación con la dirección. El árbol de distribuciones del repositorio ceph-tentacle de Proxmox contiene una sola suite: trixie. Para bookworm —la base de Proxmox VE 8— la URL devuelve 404: no hay ruta que pedir. Y el árbol de ceph-squid para bookworm no se toca desde el 5 de septiembre: sirve 19.2.5 en no-subscription y 19.2.6 en test.
Conclusión incómoda: un clúster en Proxmox VE 8 está a una actualización mayor de Proxmox de distancia de poder volver a tener un Ceph con soporte, no a cuatro días de una decisión. El orden tampoco lo eliges tú, y eso lo contamos en julio, cuando esto era un plan a cincuenta días: la guía oficial del 8 al 9 lo pone en negrita, hay que llevar el clúster a Ceph 19.2 Squid antes de empezar la actualización de Proxmox. La parada obligatoria del camino es, precisamente, la rama que se queda sin soporte el sábado. Lo que no sabíamos en julio es que para bookworm el destino ni siquiera existiría.
Dónde estás y qué te toca
Cuándo NO saltar esta semana
Una fecha de fin de soporte no es una alarma de incendio. El 31 de octubre no se apaga nada: lo que deja de haber es parches nuevos. Eso es un riesgo que crece despacio y que se puede escribir, acotar y revisar en dos semanas. Empezar un salto de rama con el clúster tocado, en viernes y sin haber apuntado la columna META previa es un riesgo que te explota en la misma noche. No son comparables.
Hay un matiz que no está en el wiki de Ceph sino en el de Proxmox, y cambia el criterio de «clúster sano»: las comprobaciones de salud que añadieron 19.2.6 y 20.2.4 para las claves inseguras ponen el clúster en HEALTH_ERR y, sin embargo, todos los servicios siguen operativos. Es decir: puedes estar en rojo por un motivo conocido, documentado y no urgente. El requisito del manual —«el clúster tiene que estar sano»— no significa «en verde pase lo que pase»; significa que sepas exactamente por qué estás en el color que estás. Si no lo sabes, ese es el trabajo de hoy, no el salto.
Las seis comprobaciones antes de tocar el repositorio
Ninguna de estas órdenes modifica nada. Son diez minutos y se pueden hacer ahora mismo, con el salto todavía sin fecha.
pveversion --verboseen cada nodo. El requisito es pve-manager 9.1.4 o posterior y paquetes de Ceph 19.2.3-pve3 o posteriores. El nodo que se quedó atrás en la última ronda de actualizaciones es el que te va a parar el proyecto.ceph -syceph versions. Sin PG en down, incomplete, undersized ni backfilling, y sin ningún demonio rezagado en una versión que no toca.ceph osd dfy guarda la salida. Esa foto de la columna META es la única forma de saber después si creció o si siempre estuvo así. Sin la foto previa, el debate del lunes no tiene datos.ceph mgr module ls. Si zabbix o restful aparecen activos, tienes trabajo de monitorización pendiente y va antes del salto.ceph fs lsy, para cada sistema de ficheros, apuntamax_mdsy si tieneallow_standby_replay. Son los dos valores que tendrás que restaurar al final, y nadie los recuerda a las dos de la mañana.- Después de cambiar el repositorio y antes de instalar nada:
apt update && apt-cache policy ceph. Si el candidato no es 20.2.4 o superior, para. Ahí es donde se cazan los pines, los holds y las réplicas internas con telarañas.
Dónde encaja esto en lo que hacemos
Operamos almacenamiento distribuido con Ceph sobre Proxmox en producción, con el hierro y las ventanas de alguien que tiene que dar la cara al día siguiente. No vendemos licencias de Ceph —no las hay— ni suscripciones de nadie: lo que hacemos es diseñar el clúster, mantenerlo y estar al otro lado del teléfono cuando la ventana se tuerce, que para eso está el soporte 24/7. Si tienes un clúster del que no sabes con qué versión de Ceph se crearon sus OSD más viejos, escríbenos y lo miramos; esa respuesta se da en una tarde y no obliga a nada.
Y si te quedas con una sola frase, que sea la lección del ticket 76256: el formato que llevas dentro de los discos lo decidió la versión con la que los creaste, y lo sigue decidiendo hoy.
Fuentes. Fechas de versión y fin de vida (y la distinción entre «End of life» y «End of life (estimated)») de Tentacle, Squid y Reef, cita sobre la última versión menor del destino y el aviso de la 19.2.6, retirada de mgr/restful y mgr/zabbix con CVE-2023-46136 y procedimiento de actualización: docs.ceph.com/en/latest/releases/ y la nota de versión de Tentacle. Requisitos (PVE 9.1, pve-manager 9.1.4, Ceph 19.2.3-pve3), pasos de MDS y problema conocido de META en OSD de Octopus o anteriores: pve.proxmox.com/wiki/Ceph_Squid_to_Tentacle. Requisito de llegar a Squid antes del salto 8 → 9 y avisos de claves inseguras con HEALTH_ERR: pve.proxmox.com/wiki/Upgrade_from_8_to_9. Título, estado del fallo, la salida de ceph osd df con los 346 GiB de META y el relato del «whack-a-mole» con compact, todo del propio ticket: tracker.ceph.com/issues/76256. Medición propia del 27 de octubre de 2026 a las 17:05 sobre los índices públicos de download.proxmox.com (componentes no-subscription y test de ceph-squid y ceph-tentacle, suites bookworm y trixie): versiones servidas, ausencia de la suite bookworm en ceph-tentacle (404) y fechas de los índices. Foto de portada: «Backblaze 2.0 w/ 45 disks installed», de ChrisDag (Flickr, CC BY 2.0), recortada por nosotros.
Microsoft 365
ES 
CAT 
EN