Ceph a Tentacle: durante la actualización tu clúster corre en dos versiones a la vez

Ceph 19.2 Squid tiene el final de vida estimado el 31 de octubre y Ceph 20.2 Tentacle lleva en el repositorio empresarial de Proxmox desde el 20 de mayo. Con esas dos fechas encima de la mesa, la ventana de mantenimiento de este otoño ya no es una hipótesis: es un punto en el calendario de alguien. Y dentro de esa ventana pasa algo que casi ningún plan contempla, porque suena a detalle y decide el riesgo entero: durante unas horas —a veces días— el clúster no corre Squid ni corre Tentacle. Corre las dos a la vez.

Operamos Proxmox VE con almacenamiento Ceph en producción, repartido en varios centros de datos, así que esto se escribe desde el lado de quien abre la ventana. Empezamos por lo que todavía no hemos hecho: no hemos puesto Tentacle en producción de ningún cliente. El motivo está al final y no tiene que ver con el rendimiento.

El anuncio que sigue circulando ya no describe la realidad

El hilo del anuncio original, del 9 de enero, sigue siendo el primer resultado que encuentra casi todo el mundo al buscar «Proxmox Ceph Tentacle». Dice dos cosas muy citables: que Tentacle está «now available on the Proxmox Ceph test repository for installation or upgrade», en estado de vista previa, y que Ceph 19.2 Squid «will stay supported until September 2026 for the time being». Las dos eran ciertas cuando se escribieron. Ninguna de las dos describe lo que tienes delante en septiembre de 2026.

El 2 de junio, un miembro del equipo de Proxmox lo dejaba escrito en el foro sin ceremonia ninguna: «Ceph Tentacle is in the enterprise repository since May 20th». El 30 de junio, otro confirmaba que la 20.2.2 estaba en el repositorio de pruebas, y el 30 de julio un tercero anunciaba que «Ceph 20.2.2 is now available in the ceph-tentacle enterprise repository». La guía oficial de actualización, la que vas a seguir paso a paso, ya no habla de vista previa en ninguna parte: el ejemplo que te pone es la línea enterprise, con no-subscription y test como alternativas si no tienes suscripción. La puerta se abrió el 20 de mayo, sin anuncio propio, y el hilo que todo el mundo enlaza sigue diciendo que está cerrada.

En Proxmox el estado de un paquete se comprueba en el repositorio, con apt policy ceph-common, no en el hilo del foro donde se anunció. Un anuncio es una foto de un día. El repositorio es el presente.

Las fechas de aguas arriba completan el cuadro. Squid salió el 26 de septiembre de 2024 y el proyecto Ceph le da un final de vida estimado el 31 de octubre de 2026. Tentacle salió el 18 de noviembre de 2025 y llega hasta el 1 de junio de 2027. Entre hoy y la caducidad de Squid quedan menos de dos meses.

apt no actualiza tu clúster

Un apt full-upgrade cambia ficheros en el disco. Los procesos que están sirviendo tu almacenamiento siguen siendo, en memoria, exactamente los de antes. Por eso el procedimiento oficial dedica tres pasos separados a reiniciar tres cosas distintas: systemctl restart ceph-mon.target para los monitores, systemctl restart ceph-mgr.target para los gestores y systemctl restart ceph-osd.target para los OSD. Y ahí nace el estado del que va este artículo, porque esos tres reinicios no ocurren a la vez ni deben ocurrir a la vez. Los monitores, además, también van de un nodo cada vez.

El estado mixto está diseñado, no tolerado

Ceph está pensado para funcionar así. La documentación del orquestador lo dice sin rodeos al describir una actualización: «Each daemon is restarted only after Ceph indicates that the cluster will remain available». Cada demonio se reinicia solo después de que Ceph indique que el clúster va a seguir disponible. Y tienes un comando para mirar por dónde vas, ceph versions, que devuelve el recuento de demonios por versión: cuántos monitores en cada una, cuántos OSD en cada una. Durante buena parte de la ventana ese recuento va a estar repartido, y eso es exactamente lo que se espera.

Conviene apuntar un detalle antes de que te muerda, porque lo vas a encontrar tú solo si lees las dos documentaciones: no coinciden en el orden de los dos primeros pasos. El wiki de Proxmox manda reiniciar primero los monitores y después los gestores. La documentación de Ceph, describiendo la actualización con su propio orquestador, dice lo contrario: «The upgrade order starts with managers, monitors, then other daemons». Son herramientas distintas y procedimientos distintos, así que ninguno está equivocado, pero si te has documentado en las dos vas a parar a mitad de la ventana preguntándote a cuál de los dos hacer caso. Sigue el de Proxmox: es el que corresponde a los paquetes que tienes instalados y el que su equipo prueba.

«Reinicia los OSD de un nodo cada vez»

El wiki pone en negrita el trozo que importa: «Restart all OSDs. Only restart OSDs on one node at a time to avoid loss of data redundancy». Es la instrucción que decide cuánto dura tu ventana, así que merece entenderse en vez de obedecerse a ciegas.

La aritmética es corta. Un pool con los valores por defecto de Proxmox guarda tres copias y exige dos para servir: tamaño 3, min_size 2. Si tu dominio de fallo es el nodo, que es lo habitual en un clúster hiperconvergido, al reiniciar los OSD de un nodo todos los grupos de colocación que tenían una copia allí se quedan momentáneamente con dos. Sigues sirviendo, no se entera nadie, y para eso está pensado. Durante esos minutos, sin embargo, estás a un solo fallo de que un grupo caiga a una copia, quede por debajo de min_size y deje de servir toda la E/S —no solo las escrituras: también las lecturas de ese grupo—. Reiniciar dos nodos a la vez te ahorra una tarde y te cuesta el margen entero que compra esa frase.

Y una precisión que evita una falsa sensación de seguridad: noout no protege de esto. Impide el rebalanceo, no la degradación. Con la marca puesta, los grupos de ese nodo están a dos copias igual que sin ella. Dicho como lo decimos siempre: el fallo es inevitable, la avería es una decisión de diseño. Durante la ventana estás renunciando a propósito a un nivel de redundancia, y eso hay que decidirlo despierto y con alguien mirando, no un viernes a las siete. Conviene además haber hecho antes la cuenta de cuánto aguanta tu clúster con un nodo menos, porque si vas justo de espacio la ventana deja de ser una molestia y pasa a ser un riesgo distinto.

noout: «opcional, pero recomendado»

El procedimiento dice, textualmente: «Set the noout flag for the duration of the upgrade (optional, but recommended)». El comando es ceph osd set noout. Aquí nos vamos a mojar: llamarlo opcional es técnicamente cierto y operativamente engañoso.

Sin esa marca, Ceph hace lo que hace siempre con un OSD que deja de responder: espera y lo saca del clúster. El parámetro que gobierna la espera, mon_osd_down_out_interval, trae por defecto diez minutos. Sacar del clúster un nodo entero de OSD equivale a dar la orden de recrear en el resto de los discos todas las copias que vivían allí. Un apt full-upgrade que se alarga, un nodo que tarda en arrancar, una espera a que un servicio pare bien, y ya has cruzado el umbral. Lo desagradable es que la operación, una vez arrancada, no se cancela sola: vuelves a poner el nodo, Ceph se da cuenta y deshace parte del trabajo, pero mientras tanto tu clúster ha estado moviendo teras que no hacía falta mover, en plena ventana y compitiendo con la producción.

Y luego está el paso que de verdad se olvida: quitarla al terminar. Un clúster que se queda con noout puesto tiene la autorreparación desactivada y nadie se acordará. Funciona perfectamente hasta el día en que un disco muere de verdad y no pasa nada, que es lo peor que puede no pasar.

Hay dos respuestas a «¿qué versión corre mi Ceph?»

La primera es la que da dpkg: los binarios instalados. La segunda es la que el clúster ha declarado, y se cambia con un comando aparte, al final de todo: ceph osd require-osd-release tentacle. El procedimiento lo acompaña de una advertencia que dice más de lo que parece: «Before raising the minimum required OSD version, you should ensure all OSDs got upgraded successfully and report running a Ceph 20.2 version».

Lo que has declarado se lee con ceph osd dump | grep require_osd_release. Y aquí va el aviso que motiva medio artículo: no lo confundas con ceph mon dump | grep min_mon_release. Ese segundo comando está en el wiki, sí, pero en el paso de los monitores y para verificar ese paso; devuelve min_mon_release 20 (tentacle) en cuanto han reiniciado los monitores, y seguirá diciendo 20 aunque no hayas ejecutado require-osd-release en tu vida. Es el comando con el que más gente da la actualización por terminada antes de tiempo, porque enseña el número que uno espera ver.

La consecuencia práctica: un clúster puede pasar meses con todos los binarios en 20.2, el panel en verde y la declaración todavía en 19. No se rompe nada. No aparece ninguna alerta escandalosa. Simplemente sigue funcionando en un modo de compatibilidad que nadie pidió, y todo lo que dependa de que el clúster entero sea nuevo se queda sin encender. Es el mismo patrón que ya contamos con Fast EC, la mejora de rendimiento de Tentacle que llega apagada y hay que activar a mano por cada pool. Si vas a abrir la ventana, ten escrito de antemano qué comandos se ejecutan después de que todo esté verde: es la parte del procedimiento que se pierde cuando el panel se pone verde y todo el mundo se va a dormir.

CephFS es donde se paga en capacidad

Si tienes CephFS, el procedimiento te pide dos cosas antes de tocar los MDS: desactivar standby_replay y reducir el número de rangos a uno. Los comandos son ceph fs set <fs> allow_standby_replay false y ceph fs set <fs> max_mds 1. Es el punto donde renuncias a capacidad de servicio y no solo a redundancia: pasas de repartir el sistema de ficheros entre varios servidores de metadatos a concentrarlo en uno, con lo que eso significa un lunes por la mañana.

Es también el único sitio donde la documentación te pide, entre paréntesis y dos veces, que apuntes algo en un papel: si piensas restaurarlo después, toma nota de si allow_standby_replay estaba activado, y toma nota del número original de demonios MDS. Es una petición muy poco habitual en un manual técnico, y está ahí por una razón evidente para cualquiera que haya hecho esto alguna vez: de madrugada nadie recuerda cuántos rangos había. Sin ese papel, la actualización acaba con un CephFS de un solo rango activo que funciona, rinde peor, y que nadie relaciona con una ventana de mantenimiento de hace seis semanas.

Los requisitos son un orden de trabajo

Son tres y se leen en treinta segundos: Proxmox VE 9.1 o superior, concretamente el paquete pve-manager en versión 9.1.4 o más nueva; Ceph en Squid, concretamente 19.2.3-pve3 o más nuevo; y el clúster sano. Esta última la escriben con signo de exclamación, cosa poco frecuente en documentación técnica: «The cluster must be healthy and working!».

Leídos juntos, esos tres requisitos ordenan el trabajo. Si estás en Proxmox VE 8, tu siguiente paso es Proxmox y Ceph viene detrás —y esa rama ya tiene su propio calendario cerrado, así que probablemente tengas dos ventanas por delante y no una. El tercero es el que se salta la gente con prisa: un clúster que ya arrastra un grupo de colocación degradado, o un OSD que va y viene desde hace semanas, no es candidato. La actualización no arregla nada de eso; lo multiplica, justo en el momento en el que además has bajado la redundancia a propósito.

Por qué nosotros todavía no

La razón ya no es el repositorio, porque esa excusa se acabó el 20 de mayo. Es la cadencia, y el rodaje. Tentacle lleva publicadas cinco versiones: la inicial 20.2.0 en noviembre y cuatro correctivas —20.2.1 el 6 de abril, 20.2.2 el 16 de junio, 20.2.3 el 5 de agosto y 20.2.4 el 19 de agosto—. Dos, el mismo mes, con catorce días de diferencia. Eso habla de una versión que todavía se está moviendo, no de una versión mala.

Hay además una asimetría que conviene mirar antes de discutir versiones: el último anuncio de repositorio empresarial que hemos podido verificar es el del 30 de julio y corresponde a la 20.2.2, mientras aguas arriba ya van por la 20.2.4 del 19 de agosto. Ese desfase es justamente lo que compras con la suscripción: un retraso deliberado mientras alguien mira. Comprueba el tuyo con apt policy ceph-common antes de dar por hecho qué versión te va a instalar la ventana. Montar Tentacle en laboratorio ahora sí tiene todo el sentido, porque un procedimiento se ensaya antes de estrenarlo, y quien tenga CephFS con varios rangos debería ensayarlo dos veces.

Sobre el rendimiento, que es lo que va a circular: en el hilo del anuncio, un usuario publicó que tras actualizar pasaba de 60.207 a 68.516 IOPS aleatorias de 4K (un 13,8 % más) y de 7.488 a 10.120 secuenciales de 64K (un 35,1 %). Hay que reconocerle que publicó más de lo habitual: tres nodos Intel NUC14 con NVMe y el script con rbd bench. Los reparos son otros. Lo midió sobre un pool replicado de tamaño 2 y min_size 2, que no es el valor por defecto de Proxmox ni el de casi ninguna producción seria; lo midió el 17 de enero contra la 20.2.0, cuatro correctivas atrás; y no hay repetición ni segunda fuente. Puede ser perfectamente cierto en su máquina. No es una cifra que nosotros pondríamos en una propuesta, y desde luego no es un motivo para adelantar una ventana.

Cuatro preguntas antes de abrir la ventana

1. ¿Cuánto tiempo va a estar el clúster en dos versiones, y quién lo mira durante ese rato? No hay una respuesta correcta —hay clústeres que tardan una tarde y otros tres días—, pero tiene que haber una respuesta escrita antes de empezar, y un nombre al lado.
2. ¿Qué pasa si un disco muere mientras un nodo de OSD está reiniciando? Si la respuesta es «no lo sé», la ventana todavía no está planificada. Si la respuesta es «ese grupo cae por debajo de min_size y deja de servir E/S hasta que vuelva el nodo», al menos es una respuesta, y decide a qué hora se abre.
3. ¿Quién decide parar a medias, y qué significa parar? Dejar el clúster en dos versiones una semana es una decisión válida y soportada. Dejarlo así sin que nadie lo sepa, no. La diferencia entre las dos cosas es un correo.
4. ¿Está apuntado, en algún sitio que no sea la memoria de alguien, el número de MDS y el estado de standby_replay de antes? Y, ya puestos, ¿quién ejecuta require-osd-release, quién comprueba ceph osd dump y quién quita el noout cuando todo esté verde?

Las cuatro son de gobierno del cambio, que es por donde se caen los sistemas de verdad: el trabajo clásico de Oppenheimer, Ganapathi y Patterson sobre tres grandes servicios de internet ya señalaba en 2003 el error de operación —y dentro de él, la configuración— como la primera causa de caídas visibles para el usuario en dos de los tres servicios, por delante del hardware. Una actualización de Ceph es un cambio de configuración manual sobre el sitio donde viven todos tus datos.

Nota de fuentes

El anuncio original del 9 de enero de 2026 —con las frases sobre el repositorio test, el estado de vista previa y el soporte de Squid «hasta septiembre de 2026»— y el informe de rendimiento del usuario, con su hardware y su script, están en ese hilo del foro de Proxmox; se citan fechados a propósito, porque describen el estado de aquel día y no el de hoy. La entrada de Tentacle en el repositorio empresarial (20 de mayo de 2026) la confirma un miembro del equipo de Proxmox el 2 de junio en este hilo. El paso de Tentacle 20.2.2 al repositorio de pruebas (30 de junio de 2026) y al empresarial (30 de julio de 2026) son mensajes del equipo de Proxmox en este otro hilo. Requisitos (Proxmox VE 9.1 / pve-manager 9.1.4, Ceph 19.2.3-pve3, clúster sano), líneas de los repositorios enterprise, no-subscription y test, orden de reinicio de los demonios, la marca noout descrita como opcional pero recomendada, la instrucción de reiniciar los OSD de un nodo cada vez, los comandos de CephFS y ceph osd require-osd-release tentacle con su advertencia previa: wiki de Proxmox VE, «Ceph Squid to Tentacle». En esa misma guía, ceph mon dump | grep min_mon_release aparece en el paso de los monitores y sirve para verificar ese paso; que no vale como comprobación de require-osd-release, y que para eso se usa ceph osd dump | grep require_osd_release, es una precisión nuestra sobre cómo funcionan el MonMap y el OSDMap. Fechas de publicación y fin de vida estimado de Squid (26-09-2024 y 31-10-2026) y de Tentacle (18-11-2025 y 01-06-2027), y las fechas de las versiones 20.2.1 a 20.2.4: índice oficial de releases de Ceph y notas de Tentacle. La frase sobre que cada demonio se reinicia solo cuando el clúster va a seguir disponible y el orden «gestores, monitores, después el resto» son de la documentación de actualización con cephadm, y se citan como lo que son: el procedimiento de otra herramienta de despliegue. Valor por defecto de mon_osd_down_out_interval (diez minutos): «Monitor/OSD Interaction». Valores por defecto de pool en Proxmox (tamaño 3, min_size 2): manual de Proxmox VE, capítulo «Deploy Hyper-Converged Ceph Cluster». El error de operación como primera causa de caídas visibles para el usuario en dos de los tres servicios estudiados: Oppenheimer, Ganapathi y Patterson, «Why Do Internet Services Fail, and What Can Be Done About It?», USENIX 2003. Las citas se reproducen en su idioma original; el texto explica en cada caso qué dicen. Las opiniones son nuestras: que llamar «opcional» a noout es engañoso, que la cadencia de correcciones dice más que el número de versión, que el desfase del repositorio empresarial es lo que se compra con la suscripción, que la cifra del foro no sirve para una propuesta y que todavía no toca ponerlo en producción de cliente salen de operar Proxmox VE con Ceph, no de las fuentes citadas.