Tu Ceph de tres nodos no se cura solo: aguanta

Si en un clúster de tres nodos se muere un disco, Ceph lo arregla solo mientras comes. Si se muere el nodo entero, no arregla nada: se queda esperando a que vuelva. Aguantar y curarse son dos cosas distintas con dos facturas distintas, y la diferencia está en cuántos sitios distintos tiene Ceph donde dejar una copia.

Empecemos por lo que viene puesto. El manual de Proxmox VE dice, en su página de Ceph, que al crear un pool «we set a default of 128 PGs, a size of 3 replicas and a min_size of 2 replicas». Tres copias, y el clúster acepta escrituras mientras queden dos. Esas tres copias van a hosts distintos, y eso tampoco es una costumbre: lo decide osd_crush_chooseleaf_type, que vale 1 por defecto. La documentación de Ceph lo deletrea cuando explica cómo montar un clúster de un solo nodo, porque ahí hay que bajarlo «from the default of 1 (meaning host or node) to 0 (meaning osd)». Con tres servidores y tres copias la cuenta sale exacta: cada host guarda una copia de absolutamente todo.

Esa exactitud es el problema. Un diseño donde la cuenta sale exacta se queda sin margen en cuanto falta un sumando.

Un disco muerto sí se arregla solo

Conviene empezar por el caso bueno. Si se muere un disco y el host sigue vivo, la regla de CRUSH elige primero un host y luego baja a un disco dentro de él, así que hay dónde recolocar la copia: otro OSD del mismo servidor. El clúster reconstruye y vuelve a HEALTH_OK sin que nadie toque nada. Y eso no es una configuración rara: el propio manual de Proxmox recomienda «at least three nodes and at least 12 OSDs, evenly distributed among the nodes», o sea cuatro discos por servidor en el mínimo recomendado.

Todo lo que viene a partir de aquí trata del otro caso: el host entero que se va, que es el caso que decide si tu plan de continuidad vale algo.

Los relojes que nadie mira

Pongamos que un nodo pierde la corriente. Lo primero que ocurre es una ausencia de latidos. Los OSD se hacen ping cada seis segundos (osd_heartbeat_interval) y dan por caído al vecino que lleva veinte sin contestar (osd_heartbeat_grace), aunque ese plazo tampoco es rígido: mon_osd_adjust_heartbeat_grace viene activado y Ceph lo estira para los OSD con historial de ir y venir. Los vecinos denuncian al monitor, y hacen falta dos denunciantes (mon_osd_min_down_reporters), contados al nivel de cubo que fija mon_osd_reporter_subtree_level, por defecto host. Con tres hosts y uno caído quedan justo dos cubos desde los que denunciar, que es justo lo que pide el parámetro: la detección funciona, pero deja de funcionar con dos hosts, y ese es el suelo real de este diseño.

Entre «caído» y «fuera» hay un segundo reloj, y es el que importa, porque marcar un OSD como out es lo que dispara el movimiento de datos: mon_osd_down_out_interval, diez minutos por defecto. Diez minutos en los que, a propósito, no se mueve un byte. Está bien pensado: el reinicio de un switch no debería provocar la migración de un clúster entero. Pero es un plazo publicado, así que va dentro de tu RTO en vez de aparecer como sorpresa el día malo. Tampoco es fijo: mon_osd_adjust_down_out_interval viene en true, o sea que Ceph lo escala según su estimación de si ese OSD es de los inestables.

Hay un tercer reloj, más lento, para el nodo que no se muere del todo. Si un OSD deja simplemente de dar parte al monitor, el plazo para declararlo caído es mon_osd_report_timeout, quince minutos. Ese es el camino del servidor que no se apaga pero tampoco contesta, el fallo que de verdad cuesta diagnosticar.

Pasados los diez minutos tampoco pasa nada

El monitor marca los OSD del nodo muerto como out y Ceph intenta colocar la tercera copia en otro sitio. Con el dominio de fallo en host y tres hosts de los que uno está fuera, ese otro sitio no existe: los dos supervivientes ya tienen su copia y la regla prohíbe poner dos copias del mismo dato en el mismo host. Los grupos de colocación se quedan en active+undersized+degraded, que la documentación de Ceph describe con estas palabras: «have the degraded or undersized flag set, which means that there are not enough instances of that PG in the cluster».

Puede que ni siquiera veas todos esos OSD en estado out. Ceph trae un freno, mon_osd_min_in_ratio con valor 0,75, que es «the minimum ratio of in Ceph OSD Daemons before Ceph will mark Ceph OSD Daemons out»: en un clúster con muchos discos por servidor, vaciar un host entero choca con ese límite y parte de sus OSD se quedan en down sin llegar a out. La conclusión no cambia —tampoco hay recuperación— pero explica por qué el ceph osd tree que mires después puede no coincidir con lo que esperabas.

Mientras tanto el clúster sigue sirviendo: quedan dos copias y min_size es dos, así que tus máquinas escriben como si nada. Por eso casi nadie lo mira. Un clúster degradado que funciona genera un aviso amarillo en un panel; un clúster parado genera veinte llamadas. Y la avería que no genera llamadas es la que se queda semanas.

El precio de aguantar está en la misma página del manual

El manual de Proxmox VE tiene una frase que casi todo el mundo lee en otro contexto —está en el apartado de cambiar la red de Ceph— y que es en realidad la regla de operación de un clúster degradado: «Do not restart OSDs on multiple hosts at the same time. Chances are that for some PGs (placement groups), 2 out of the (default) 3 replicas will be down. This will result in I/O being halted until the minimum required number (min_size) of replicas is available again».

Léela otra vez con un nodo ya fuera. Un host caído convierte cualquier operación sobre un segundo host en exactamente el escenario que esa frase prohíbe. Actualizar el kernel del nodo 2 y reiniciarlo, cambiarle un disco, moverle un cable: cualquiera de esas cosas deja algunos grupos de colocación por debajo de min_size y la entrada/salida se para en seco hasta que vuelva el segundo. Mientras un nodo está fuera te quedas sin ventana de mantenimiento en los otros dos. Ese es el precio de aguantar, y no aparece en ninguna factura.

El nodo que vuelve trae el tráfico

El día que devuelves el nodo al clúster empieza lo que no había pasado hasta entonces: reconstruir todo lo que se escribió mientras estuvo fuera. Y ahí hay otra frase del manual de Proxmox que merece leerse dos veces: «The volume of traffic, especially during recovery, will interfere with other services on the same network, especially the latency sensitive Proxmox VE corosync cluster stack can be affected, resulting in possible loss of cluster quorum».

La curación puede costarte el quórum. Si el tráfico de Ceph y el de corosync comparten cable, la recuperación que arregla el almacenamiento es capaz de tumbar el clúster que lo sostiene, y ya hemos contado lo poco que tolera corosync en latencia. De ahí que el manual pida al menos 10 Gbps exclusivos para Ceph y, en instalaciones de alto rendimiento, tres redes físicas separadas. Es la condición para que la recuperación no sea el segundo incidente del día.

Sobre cuánto dura esa reconstrucción el manual es honesto y corto: «Especially with small clusters, recovery might take long», y recomienda SSD en instalaciones pequeñas «to reduce recovery time, minimizing the likelihood of a subsequent failure event during recovery». O sea que el motivo de comprar SSD en un clúster de tres es acortar la ventana en la que un segundo fallo te encuentra sin red, más que el rendimiento diario. Hay otra decisión de compra escondida en la misma página: «a single OSD failure forces Ceph to recover more data at once» cuanto mayor sea el disco. Criterio nuestro, no del manual: ese dato pelea contra el precio por terabyte, que empuja siempre hacia discos más grandes, y conviene decidirlo a sabiendas —igual que la capacidad útil la marca el disco más lleno y no la suma de la hoja de cálculo—.

La memoria que no tienes el día que la necesitas

En un clúster hiperconvergido los dos supervivientes tienen que hacer dos cosas a la vez, y las dos cuestan memoria. Una: arrancar las máquinas del nodo muerto, porque para eso está la alta disponibilidad —que no evita la caída, la acorta—. Dos: pagar el sobrecoste de memoria de Ceph mientras reconstruye. El manual de Proxmox lo dice sin rodeos: los OSD consumen más «during critical operations, such as recovery, rebalancing, or backfilling», recomienda 8 GiB por OSD y advierte de que no se apure la memoria en operación normal, sino «leave some headroom to cope with outages».

Si dimensionaste la RAM para el día bueno, el día malo tienes un problema de memoria encima del problema de almacenamiento. Y llega justo cuando la alta disponibilidad acaba de repartir las máquinas del nodo muerto entre dos supervivientes, que es un cincuenta por ciento más de carga en cada uno. La cabecera de memoria de un clúster de tres no es un lujo de arquitecto: es la mitad de tu plan de recuperación.

Cuenta sitios, no nodos

Lo que separa «aguantar» de «curarse» es un número pequeño: un dominio de fallo más que copias. Con réplica 3 y cuatro hosts, cuando muere uno quedan tres sitios distintos, Ceph tiene dónde dejar la tercera copia, reconstruye, y al terminar vuelves a estar protegido contra el siguiente fallo sin que nadie haya ido al centro de datos. Con tres hosts eso no ocurre nunca cuando lo que se muere es el host, por muchos discos que tengas dentro. El cuarto nodo no compra capacidad: compra el permiso de Ceph para curarse solo. La misma aritmética, con otros números, es la que decide si te compensa réplica 3 o erasure coding.

La pega que más veces hemos visto olvidar merece su propio párrafo: un dominio de fallo es el que cree CRUSH, no el que dice la factura. Si el cuarto servidor cuelga de la misma regleta, del mismo switch y de la misma sala que los otros tres, has comprado un host más y no un sitio más; contra el fallo que de verdad te tumba, el de la sala, sigues teniendo uno solo. Lo que CRUSH sabe de tu instalación es lo que le hayas contado, y por defecto lo único que sabe es cómo se llama cada máquina. Las otras dos pegas son más llevaderas: el cuarto nodo cuesta dinero y añade tráfico y un voto más, y no necesita ser monitor —el manual dice «You won't need more than 3 monitors, as long as your cluster is small to medium-sized»—.

Lo que comprobamos antes de firmar un clúster de tres

• Cuánto tarda este clúster en volver de degradado a HEALTH_OK desde que el nodo regresa, medido una vez con los datos que tiene hoy y no con los que tenía vacío el día de la instalación. Ese número entra en el plan; el de la hoja del fabricante no.
• La ventana de «no se toca», por escrito: mientras un host esté fuera, el segundo no se reinicia, no se le cambia un disco y no se le toca un cable. Y con ella el uso deliberado de ceph osd set noout para el mantenimiento planificado, que es la otra mitad de la conversación. Escrito y firmado, no sabido. Un estudio clásico sobre por qué fallan los grandes servicios de internet (Oppenheimer, Ganapathi y Patterson, USENIX 2003) situó los cambios manuales de configuración por delante del hardware como causa, y la ventana degradada es exactamente el momento en que un cambio razonable sale caro.
• Regleta, switch, sala: los sitios contados uno a uno. Con esa lista delante se decide si el dominio de fallo de la regla CRUSH sigue siendo host o tiene que subir un nivel. Y de paso se mira mon_osd_down_out_subtree_limit, que existe para no vaciar de golpe un subárbol entero y viene puesto en rack: si tu mapa no tiene racks, ese freno nunca llega a entrar.
• Separar de verdad la red de Ceph de la de corosync. No una VLAN distinta sobre el mismo par de cables: separada. Es la diferencia entre una recuperación lenta y una recuperación que se lleva por delante el quórum.
• Y la copia, fuera del clúster. Réplica 3 no es copia de seguridad: un clúster que aguanta un nodo muerto no te devuelve un fichero borrado por error ni sobrevive a un cifrado. Eso es recuperación ante desastres, otro problema y otra factura.

Lo que no estamos diciendo

Todo lo anterior describe la configuración por defecto: tres hosts, réplica 3, dominio de fallo host. Si tu mapa CRUSH tiene otro nivel o si alguien tocó la regla, la conclusión cambia. La comprobación son dos órdenes, ceph osd crush rule dump y ceph osd tree, cuestan diez segundos y valen más que cualquier cosa que digamos nosotros.

Tampoco estamos diciendo que un Ceph de tres nodos esté mal diseñado. Tres es el mínimo documentado —«you must use at least three (preferably) identical servers»— y funciona; nosotros operamos Proxmox VE con almacenamiento Ceph en producción, repartido en varios centros de datos, y llevamos con Proxmox desde las ramas 3.x. Para muchas empresas, tres nodos bien montados protegen más que una cabina cara a la que nunca han hecho una conmutación de verdad.

Y no estamos diciendo «cómprate un cuarto nodo». Si el presupuesto llega a tres, la respuesta no es más hierro: es un procedimiento escrito para la ventana degradada y una copia que viva fuera. Lo único que sostenemos es que «se cura solo» no forma parte de lo que compras con tres cuando lo que se pierde es un servidor entero, y que un plan de continuidad que dé por hecha esa curación está contando con algo que la configuración por defecto no ofrece.

En everyWAN diseñamos y operamos almacenamiento distribuido con Ceph y la infraestructura que lo sostiene, sobre Proxmox VE y en producción. No vendemos licencias de nadie, así que cuando decimos que con tres nodos no hay recuperación automática de un host no nos paga nadie por decirlo, ni por callarlo.

Fuentes (consultadas el 25-sep-2026): los valores por defecto de osd_heartbeat_interval (6 s), osd_heartbeat_grace (20 s), mon_osd_adjust_heartbeat_grace (true), mon_osd_min_down_reporters (2), mon_osd_reporter_subtree_level (host), mon_osd_down_out_interval (10 minutos), mon_osd_report_timeout (15 minutos), mon_osd_adjust_down_out_interval (true), mon_osd_min_in_ratio (0,75) y mon_osd_down_out_subtree_limit (rack) están en Configuring Monitor/OSD Interaction de la documentación de Ceph (rama Tentacle). La descripción de PG_DEGRADED y de las banderas degraded y undersized está en Health checks. Que osd_crush_chooseleaf_type vale 1 por defecto está en Pool, PG and CRUSH config reference, y la frase que traduce ese 1 a «host or node» está en Troubleshooting PGs. En esa misma referencia, osd_pool_default_size vale 3; ojo con osd_pool_default_min_size, cuyo valor por defecto es 0 y significa «no particular minimum», que Ceph evalúa como size − (size/2) y con réplica 3 da 2 —el 2 explícito lo fija Proxmox al crear el pool, según su propio manual—. Las citas de Proxmox (tres servidores como mínimo, el pool por defecto, los 12 OSD repartidos, no reiniciar OSD de varios hosts a la vez, el tráfico de recuperación y el quórum de corosync, 10 Gbps exclusivos, 8 GiB por OSD y la cabecera de memoria, la recomendación de SSD en clústeres pequeños, que un OSD más grande obliga a recuperar más de golpe y el número de monitores) están en el capítulo de Ceph del manual de Proxmox VE. La referencia sobre el peso del error humano frente al hardware en las caídas graves es Oppenheimer, Ganapathi y Patterson, Why Do Internet Services Fail, and What Can Be Done About It?, USENIX 2003. Lo que este post NO afirma: no hemos reproducido la caída de un nodo en laboratorio para este post; el comportamiento descrito se deduce de la documentación citada y de la regla de réplica por defecto, y por eso insistimos en que lo comprobable en tu clúster son ceph osd crush rule dump y ceph osd tree. Los temporizadores son valores por defecto y pueden estar cambiados en tu instalación (ceph config get). No damos ninguna cifra de duración de una recuperación real porque depende del volumen, del disco y de la red, y cualquier número que diéramos sería inventado. Y la regla de contar sitios en vez de nodos, igual que la lectura del precio por terabyte frente al tiempo de reconstrucción, son criterio nuestro y no recomendación de ningún fabricante.