Pusiste noout para actualizar Ceph y apagaste la reposición de copias

El procedimiento de actualización de Ceph en Proxmox te recomienda, en su paso cuatro, ejecutar ceph osd set noout: «optional, but recommended», dice el wiki. La documentación de Ceph, en su página de resolución de problemas de OSD, dice que eso es «más un ejercicio mental» que una sugerencia de que alguien «en el mundo post-Luminous» lo ejecute. Las dos frases están publicadas hoy y las dos son defendibles. La que decide si tu cluster repone una copia perdida esta noche es la segunda.

Operamos Proxmox VE con Ceph en producción, repartido en varios datacenters, así que esa bandera la hemos puesto nosotros muchas veces y la vamos a seguir poniendo. Este post no va de que noout esté mal. Va de qué apaga exactamente, de los dos avisos que no vas a leer mientras esté puesta, y de los cuatro comandos que hacen el mismo trabajo sin desactivar el automatismo de todo el cluster.

Octubre es el mes en que mucha gente va a tocar su Ceph

La tabla de versiones activas de la documentación de Ceph, hoy, dice esto: Squid, publicada el 26 de septiembre de 2024, última 19.2.6, fin de vida estimado el 31 de octubre de 2026. Tentacle, publicada el 18 de noviembre de 2025, última 20.2.4, fin de vida estimado el 1 de junio de 2027. Perder el soporte de una rama de Ceph no significa que el cluster se apague: significa que dejan de llegar los backports, incluidos los de seguridad. Así que a quien esté en Squid le quedan semanas de parches, y eso convierte octubre en un mes de ventanas de mantenimiento.

Esa palabra, «estimado», no es decorativa, y ya escribimos sobre ella: la fecha de Squid se movió del 19 de septiembre al 31 de octubre en un commit sin anuncio, y en el mismo movimiento Tentacle perdió 170 días de vida útil estimada. Aquí nos interesa la consecuencia práctica: mucha gente va a ejecutar el guion de actualización de Squid a Tentacle este mes.

Ese guion, en el wiki de Proxmox, tiene una forma muy reconocible: cambiar el repositorio, poner la bandera (y te ofrece hacerlo desde la interfaz, en la pestaña OSD, con un botón que se llama Manage Global Flags), apt update y apt full-upgrade, reiniciar los monitores de uno en uno, los managers, los OSD nodo a nodo, los MDS si hay CephFS, fijar ceph osd require-osd-release tentacle y, al final del todo, quitar la bandera. El último paso de la lista es el que se queda sin hacer. No por dejadez: porque la ventana no termina cuando termina el procedimiento, sino cuando alguien decide que ha terminado, y ese alguien lleva cuatro horas mirando ceph -s a las dos de la mañana.

Lo que noout apaga no es el rebalanceo

La mayoría la pone con una idea en la cabeza: «evito que el cluster se ponga a mover terabytes mientras reinicio un nodo». La documentación es más concreta que esa idea. En la lista de comprobaciones de salud, el aviso OSDMAP_FLAGS describe noout así: los OSD en estado down no pasan automáticamente a out una vez transcurrido el intervalo configurado.

Ese intervalo configurado tiene nombre y valor: mon_osd_down_out_interval, 10 minutos por defecto, descrito como «marca como out cualquier OSD que lleve down este tiempo». Y la diferencia entre los dos estados es toda la conversación: down significa «no contesta»; out significa «sale del reparto». Es el paso a out el que hace que CRUSH recalcule dónde va cada copia y el que pone en marcha la creación de la copia que falta en otro disco. Si nunca llega a out, el cluster no repone nada por su cuenta. Marcarlo out a mano sí funciona, incluso con la bandera puesta; lo que hace falta es que alguien se haya dado cuenta.

Y aquí está el detalle que cambia la conversación: la bandera no distingue. No sabe que el osd.7 está abajo porque lo acabas de reiniciar tú y que el osd.12 está abajo porque se le ha muerto la electrónica. Para ella son el mismo estado y reciben el mismo trato. Con réplica 3, eso significa dos copias donde tu diseño dice tres, y un aviso PG_DEGRADED que define exactamente eso: «la redundancia de datos está reducida para algunos datos». Escribimos hace una semana sobre qué se cura solo y qué no en un Ceph de tres nodos; esto es un escalón por encima, porque aquí la curación la impide una decisión tuya, tomada hace seis horas y escrita en ningún sitio.

El manual de Ceph dice, con esas palabras, que no la uses

En la página de resolución de problemas de OSD, justo después de explicar cómo se pone la bandera global, hay un recuadro de advertencia. Traducido, dice: «esto es más un ejercicio mental ofrecido con el propósito de dar al lector una idea de los dominios de fallo y del comportamiento de CRUSH que una sugerencia de que alguien en el mundo post-Luminous ejecute ceph osd set noout». Y el recuadro sigue, conviene citarlo entero: «cuando los OSD vuelvan al estado up, el rebalanceo se reanudará y el cambio introducido por el comando quedará revertido». Es decir: el proyecto la desaconseja porque la considera poco útil. El motivo por el que la desaconsejamos nosotros es otro y viene a continuación.

Luminous es de 2017. Esa frase no es el comentario de un foro: está en la documentación oficial del proyecto, en la página de resolución de problemas de OSD, y el párrafo siguiente ofrece la alternativa sin rodeos: en Luminous y posteriores, es más seguro marcar únicamente los OSD afectados.

Conviene decir lo otro también, porque si no esto se convierte en un pim-pam fácil: el procedimiento de Proxmox no es imprudente. Pide la bandera global porque es un procedimiento genérico que tiene que funcionar igual en un cluster de tres nodos y en uno de treinta, y porque la alternativa exige saber el nombre del bucket CRUSH de cada host. Para un manual, es una decisión razonable. Lo que no es razonable es que ese manual, escrito para todos, sea lo único que decide la postura de redundancia de tu cluster concreto durante seis horas.

El freno que ya tenías puesto y no sabías

Hay un parámetro que casi nadie mira y que ya hace, por defecto, buena parte de lo que la gente cree estar comprando con noout: mon_osd_down_out_subtree_limit. Su descripción es «la unidad CRUSH más pequeña que Ceph no marcará automáticamente como out», con un ejemplo explícito: si vale host y caen todos los OSD de un host, Ceph no los sacará solo. Su valor por defecto es rack.

Léelo despacio, porque dice dos cosas a la vez. La primera: el escenario que de verdad asusta ya está frenado. Si desaparece un rack entero —o cualquier unidad igual o mayor—, Ceph no se pone a recolocar decenas de terabytes por su cuenta. Con un matiz importante: si tu mapa CRUSH es el plano de serie —raíz y hosts, sin buckets de tipo rack—, el único nivel que llega a ese tamaño es la raíz entera, así que la protección real es bastante menor de lo que suena. La segunda, la que importa para la ventana de esta noche: un host no está frenado. Si reinicias un nodo y tarda más de diez minutos en volver, sus OSD saldrán del reparto. Ese caso, y no otro, es el que justifica tocar una bandera. Y antes de teclear conviene hacerse otra pregunta: ¿qué dominio de fallo voy a tocar? Si la respuesta es un host, la bandera es de ese host.

Y lo que casi nadie cuenta: un PG degradado no se scrubea

Esta parte no sale en ningún procedimiento de actualización y es la que nos hizo escribir el post. La comprobación de salud PG_NOT_SCRUBBED incluye una frase que, leída fuera de contexto, parece un detalle de implementación: «los PG se revisan solo si están marcados como clean… los PG mal colocados o degradados no se marcarán como clean». La de PG_NOT_DEEP_SCRUBBED dice lo mismo en forma más prudente, con un «puede que no».

El deep scrub es el mecanismo que compara los checksums de las copias y encuentra la corrupción silenciosa: el aviso OSD_SCRUB_ERRORS, que levantan las revisiones en general, existe precisamente porque «revisiones recientes han descubierto inconsistencias». Ahora encadena las piezas en el orden en que ocurren:

• Pones noout para la ventana.
• Un disco se muere de verdad (no es el que reiniciaste tú).
• Su OSD se queda en down y nunca llega a out: no se repone la copia.
• Los PG que vivían ahí quedan degraded, luego dejan de estar clean.
• Al no estar clean, dejan de revisarse.

Es decir: el único mecanismo que verifica que las dos copias que te quedan siguen siendo correctas deja de ejecutarse justo sobre los datos a los que les falta una copia. Eso no es la suma de dos problemas. Es un problema que apaga el detector del otro.

Un cluster amarillo permanente es un cluster sin alarma

Alguien dirá, con razón, que Ceph avisa de que no se está revisando. Es verdad, y se puede calcular cuándo. El intervalo máximo de revisión superficial, osd_scrub_max_interval, son 7 días; el aviso salta cuando pasa un porcentaje extra de ese intervalo marcado por mon_warn_pg_not_scrubbed_ratio, que por defecto es 0,5: tres días y medio más, es decir, 10 días y medio. Para el deep scrub, osd_deep_scrub_interval son otros 7 días y el ratio mon_warn_pg_not_deep_scrubbed_ratio es 0,75: 12 días y cuarto.

Esos dos avisos existen y funcionan. Esos avisos llegan. La cuestión es a dónde llegan. Desde el segundo en que ejecutaste ceph osd set noout, el cluster está en HEALTH_WARN por OSDMAP_FLAGS. Si la bandera sigue puesta doce días después, el aviso del deep scrub aterriza en un panel que lleva doce días en amarillo, debajo de una línea que todo el mundo ha aprendido a ignorar porque «es la de la actualización». Un amarillo nuevo dentro de un amarillo viejo no es una alerta: es la misma línea de ayer. La bandera no solo desactiva una función; desactiva el canal por el que Ceph te lo contaría.

La misma entrada OSDMAP_FLAGS describe las demás banderas de la familia, y vale la pena ponerlas una al lado de otra con lo que la gente cree que hacen:

Las tres primeras filas se ponen juntas con una frecuencia que da respeto, normalmente copiando una línea de un hilo de foro. Pero la peor de todas para dejarse puesta es la última. Con nodown, un OSD realmente muerto sigue apareciendo arriba en el mapa, porque los monitores han dejado de hacer caso a quien les informa de lo contrario. Y eso ya no es un amarillo que ignoras: es un verde que no es verdad.

Los cuatro comandos que hacen lo mismo sin apagar el cluster

La alternativa que propone la propia documentación cabe en cuatro líneas. La bandera deja de ser del cluster y pasa a ser del disco o del host que vas a tocar:

# un solo disco que vas a sacar o sustituirceph osd add-noout osd.12
ceph osd rm-noout  osd.12

# el host entero que vas a reiniciar (nombre del bucket CRUSH)ceph osd set-group   noout nodo-03
ceph osd unset-group noout nodo-03

Esto no te deja sin aviso: hay una comprobación de salud propia, OSD_FLAGS, que salta cuando «uno o más OSD, nodos CRUSH o clases de dispositivo tienen una bandera de interés puesta». Sigues teniendo tu amarillo. La diferencia es que ahora es un amarillo que nombra tres OSD concretos en vez de uno que tapa el cluster entero, y que mientras lo tienes puesto, el resto del cluster conserva su automatismo: si durante tu ventana se muere un disco en otro nodo, ese sí sale a los diez minutos y su copia se repone sola, que es exactamente lo que querías que pasara.

La comprobación de treinta segundos, y la que falta en tu monitorización

Antes de seguir leyendo, mira si tienes alguna puesta ahora mismo. Son tres órdenes y ninguna cambia nada:

ceph -s                     # avisa de las banderas puestas, debajo de healthceph osd dump | grep ^flags # las banderas globales, en crudoceph health detail          # OSDMAP_FLAGS y OSD_FLAGS, con el detalle

Si sale noout, nodown, noin o noup —el resto de lo que lista osd dump está ahí de serie—, la pregunta siguiente no es técnica: ¿quién la puso, para qué, y cuándo se iba a quitar? Si nadie sabe contestar a las tres, la bandera lleva puesta más tiempo del que nadie recuerda y tu redundancia real no es la que figura en el diseño.

Y la parte que sí es trabajo nuestro: vigilamos los clusters con Zabbix, y la regla que importa aquí no es «avísame si el cluster no está en HEALTH_OK». Esa alerta se silencia el primer mes, por buenas razones, y a partir de ahí no sirve para nada. La regla útil es otra: avísame si hay una bandera puesta y han pasado más de N horas desde que se puso. Una bandera de mantenimiento es un cambio manual con fecha de caducidad implícita; la alerta tiene que ser sobre la caducidad, no sobre el estado.

Esto no es una manía nuestra. El trabajo clásico de Oppenheimer, Ganapathi y Patterson sobre por qué fallan los servicios de internet (USENIX, 2003) puso el error de operador en cabeza de las causas de caída en dos de los tres servicios que estudió, por delante del hardware, y dentro de él la mala configuración era el subtipo dominante. El paper además precisa cuándo ocurre: mientras los operadores «hacían cambios en el sistema, por ejemplo desplegando o actualizando software». ceph osd set noout es, literalmente, un cambio de configuración manual hecho por un operador. Está en la categoría ganadora.

Lo que no estamos diciendo

No hemos perdido datos por esto, y no vamos a inventarnos un caso de cliente para redondear el post. Lo que hay aquí es la documentación leída entera y la aritmética hecha. La bandera global no es un error en sí misma: es un procedimiento genérico aplicado a un cluster concreto, y todo el riesgo está en cuánto dura, no en el acto de ponerla. Media hora de noout con alguien delante es una cosa; tres semanas porque nadie cerró la ventana es otra muy distinta.

Los valores que hemos citado son los valores por defecto. Si alguien tocó mon_osd_down_out_interval, el subtree_limit o los dos ratios de aviso, tus números no son estos; compruébalos con ceph config get mon mon_osd_down_out_interval y ceph config get mgr mon_warn_pg_not_deep_scrubbed_ratio antes de fiarte de la cuenta. Y las fechas de fin de soporte de la tabla de versiones vienen marcadas como estimadas por el propio proyecto, que ya las ha movido más de una vez.

El conflicto de interés, por delante: no somos revendedores de Proxmox ni vendemos suscripciones de Ceph, no cobramos comisión por ninguna de las dos. Operar clusters ajenos y hacer estas ventanas de madrugada sí lo facturamos.

Fuentes (verificadas el 2 de octubre de 2026): la tabla de versiones activas con Squid 19.2.6 (inicial 26-09-2024, fin de vida estimado 31-10-2026) y Tentacle 20.2.4 (inicial 18-11-2025, fin de vida estimado 01-06-2027) — índice de versiones de Ceph; la descripción literal de noout, nodown, noscrub/nodeep_scrub y nobackfill/norecover/norebalance, la comprobación OSD_FLAGS para OSD y buckets, la definición de PG_DEGRADED, OSD_SCRUB_ERRORS y las frases sobre que los PG degradados no se marcan como clean en PG_NOT_SCRUBBED y PG_NOT_DEEP_SCRUBBED — comprobaciones de salud de Ceph; la advertencia del «ejercicio mental» y los comandos add-noout, rm-noout, set-group y unset-group — resolución de problemas de OSD; mon_osd_down_out_interval (10 minutos) y mon_osd_down_out_subtree_limit (rack) — interacción monitor-OSD; osd_scrub_max_interval y osd_deep_scrub_interval (7 días cada uno) — configuración de OSD; los valores por defecto 0,5 y 0,75 de los dos ratios de aviso — src/common/options/global.yaml.in del código de Ceph; el procedimiento con ceph osd set noout, el botón Manage Global Flags y el unset final — wiki de Proxmox, actualización de Ceph Squid a Tentacle; los cambios de configuración manuales como causa principal de caídas graves — Oppenheimer, Ganapathi y Patterson, «Why Do Internet Services Fail, and What Can Be Done About It?», USENIX 2003. La lectura de que la bandera apaga el detector del otro problema, la aritmética de los 10,5 y 12,25 días y la regla de alerta por antigüedad de la bandera son nuestras, no de esas fuentes.