En Ceph la capacidad no la marca el clúster: la marca el disco más lleno

El clúster deja de aceptar escrituras un martes por la tarde. Las máquinas se quedan clavadas, el hipervisor no cuelga y no hay ningún disco roto. Mientras tanto, ceph df sigue enseñando decenas de teras libres. Las dos cosas son ciertas a la vez, y ahí está la lección: en Ceph la capacidad útil no es la suma de los discos. Es lo que quepa en el que se llene primero.

Escribimos esto operando Proxmox VE con almacenamiento Ceph en producción, repartido en varios centros de datos, así que vendemos lo que se cuenta aquí. Conviene decirlo antes de empezar, porque la parte más útil del artículo —la cuenta de la capacidad con un nodo menos— se hace con una hoja de cálculo y dos comandos, y no requiere comprarle nada a nadie.

El umbral no es del clúster: es de cada disco

Ceph tiene tres umbrales de ocupación, y los tres se evalúan por OSD, no sobre el total. Los valores por defecto que trae la documentación son 0,85 para nearfull, 0,90 para backfillfull y 0,95 para full. Nadie los toca casi nunca, y eso está bien: el problema no es el número, es dónde se mide.

La comprobación de salud OSD_FULL lo dice en una frase, y merece la pena leerla despacio porque el sujeto está en singular y el objeto en plural: «One or more OSDs have exceeded the full threshold and are preventing the cluster from servicing writes». Uno o más OSD han superado el umbral y están impidiendo que el clúster sirva escrituras. No que ese disco deje de aceptar datos: que el clúster deje de servir escrituras.

Con precisión: lo que se detiene son las escrituras de los pools que tengan algún grupo de colocación en ese OSD. En un clúster hiperconvergido de manual —una sola regla CRUSH que reparte sobre todos los discos de todos los nodos— eso significa todo lo que tienes. Un disco de veinticuatro detiene las máquinas de doce clientes. Hay un detalle curioso, además, y lo apuntamos porque quien vaya a la documentación se lo va a encontrar: la página de configuración del monitor es más dura que la de las comprobaciones de salud y afirma que Ceph «prevents you from writing to or reading from OSDs», o sea escrituras y lecturas. Las dos páginas son oficiales y no dicen lo mismo; en la práctica, lo que se cae son las escrituras y las lecturas siguen respondiendo. Lo que vas a ver en la consola de Proxmox es un puñado de máquinas congeladas.

Por qué un disco se llena antes que los demás

Porque CRUSH no es un repartidor de huecos. Coloca los grupos de colocación con una función determinista sobre pesos, no buscando el disco que tiene más sitio libre, y ese es su mérito: cualquier cliente calcula dónde vive un objeto sin preguntarle a nadie. El precio es que la distribución es estadística. Con pocos grupos de colocación por disco la varianza se nota, los grupos no pesan lo mismo entre sí, y cada vez que alguien sustituye un disco de 4 TB por uno de 8 TB el reparto se vuelve a torcer.

Para eso está el balanceador, y viene de fábrica: la documentación dice que «the default mode is upmap» y que en ese modo el balanceo automático está activado. Ayuda mucho y no hay que desactivarlo. Pero conviene saber dos cosas. La primera, que upmap optimiza la colocación de grupos, no de bytes, y esto no es una interpretación nuestra: la documentación tiene un apartado dedicado, titulado «Limitation: count-based balancing vs. size-based balancing», que lo dice con todas las letras —«Ceph's built-in balancer optimizes only by PG shard count, not by the actual size of the data stored in each PG»—. Si tus grupos son desiguales, el balanceo se queda a medias. La segunda, que tiene un requisito escrito: «to use upmap, all clients must be Luminous or newer». Basta un cliente antiguo colgando de ese clúster —un servidor de copias que nadie ha tocado, un kernel viejo montando RBD— para que la opción no se pueda activar.

De ahí sale una regla de lectura que ahorra sustos: la media de ocupación de un clúster de Ceph es el número más inútil del panel. El que manda es el máximo. ceph osd df lo enseña disco a disco, con una columna VAR que es la ocupación de cada disco dividida por la media del clúster: 1,00 es estar justo en la media. Si el panel dice 68 % y hay un OSD al 91 %, tu clúster está al 91 %.

El orden de los umbrales es el aviso que nadie lee

Mira otra vez los tres números: 0,85, 0,90 y 0,95. El del medio, backfillfull, no avisa de nada. Apaga algo. La comprobación OSD_BACKFILLFULL dice que uno o más OSD han superado el umbral —o lo superarían si terminasen los backfills ya en marcha—, «which will prevent data from rebalancing to this OSD»: impidiendo que se recoloquen datos hacia ese disco. Fíjate en el inciso, porque decide el resto del artículo: Ceph no espera a que el disco esté al 90 %, hace la proyección y se niega antes.

Es decir: el mecanismo que repara se apaga cinco puntos antes que el que sirve. Cuando el disco más lleno cruza el 90 %, Ceph deja de poder mover datos hacia él, que es justo la herramienta con la que se arregla un desequilibrio. Cuando cruza el 95 %, se para todo. Entre una cosa y la otra, en un disco de 4 TB, hay unos 200 GB. Una máquina virtual mediana. Una noche de crecimiento normal.

Que el orden importa lo demuestra el propio Ceph: tiene una comprobación dedicada, OSD_OUT_OF_ORDER_FULL, cuya única razón de existir es avisarte de que «the utilization thresholds for nearfull, backfillfull, full, and/or failsafe_full are not ascending». Hay un aviso oficial para el caso de que alguien deje los umbrales desordenados. Alguien lo ha hecho antes que tú, y a alguien le ha dolido.

La cuenta que casi nadie hace: la capacidad con un nodo menos

La documentación de Ceph plantea el ejemplo con un clúster de 33 nodos, un OSD de 3 TB en cada uno, 99 TB en total: «with a mon osd full ratio of 0.95, if the Ceph Storage Cluster falls to 5TB of remaining capacity, the cluster will not allow Ceph clients to read and write data». Y añade la parte que casi nunca se traslada al presupuesto: hay que planificar contando con que varios OSD fallen a la vez y el clúster siga pudiendo volver a active+clean.

Traducido a la pyme que tiene cuatro o cinco nodos en vez de treinta y tres, la aritmética es corta y la hacemos nosotros aquí, no la documentación. Si el dominio de fallo es el nodo y pierdes uno, cuando Ceph acaba dándolo por perdido tiene que recrear en los N−1 nodos que quedan todas las réplicas que vivían en el que se fue. El total de datos en bruto no baja: se redistribuye entre menos discos. Para que ninguno cruce el 95 % después de esa reconstrucción, la ocupación antes del fallo no puede pasar de 0,95 × (N−1) / N.

Con cuatro nodos, ese 71 % es el techo para que nadie cruce el 95 % después de reconstruir. Pero reconstruir hay que poder hacerlo, y ahí manda el umbral del medio: si la ocupación proyectada de un OSD pasa de 0,90, Ceph se niega a enviarle datos y los grupos se quedan en backfill_toofull, o sea a medio camino. El número que de verdad te devuelve a active+clean es 0,90 × (N−1) / N: con cuatro nodos, 67 %. Esa es la columna del medio, y es la que hay que mirar, porque el criterio que pide la documentación no es «que no se pare», es que el clúster pueda recuperarse a active+clean. La tercera columna añade el margen de no pasarte siquiera del aviso mientras dura la reconstrucción. Y todo esto suponiendo nodos idénticos y reparto perfecto, que no existe: al máximo real de ceph osd df réstale unos puntos y tendrás el número honesto.

El caso de tres nodos merece párrafo aparte, porque es el más vendido y el que rompe la tabla. Con réplica 3 y dominio de fallo por nodo, si cae un nodo no quedan tres sitios distintos donde poner tres copias: Ceph no puede reconstruir, así que no se llena nada. Se queda degradado y esperando, con min_size 2 dejándote seguir trabajando sobre dos copias. El aviso de Proxmox sobre esto es tajante y va justo en la dirección contraria a la tentación: «do not set a min_size of 1», porque permitir E/S sobre un objeto con una sola réplica lleva a pérdida de datos y a grupos incompletos. En tres nodos, entonces, quien muerde no es el nodo: es el disco suelto. Si muere un OSD y su nodo sigue vivo, sus grupos se recrean en los otros OSD de ese mismo nodo, porque el dominio de fallo no deja sacarlos de ahí. Con cuatro discos por nodo eso multiplica por 4/3 la ocupación de los tres que quedan, peor que perder un nodo entero de seis, y ahí la cuenta se hace con los discos de un nodo y no con los nodos. Lo desarrollamos en la alta disponibilidad de Proxmox no evita la caída, la acorta.

Y hay un tercer factor que mueve la tabla entera: el esquema de protección. Con réplica 3 escribes tres veces lo que ocupas; con codificación de borrado escribes bastante menos, pero necesitas más dominios de fallo y pagas en escrituras pequeñas. Esa cuenta la hicimos entera en réplica 3 frente a erasure coding, y conviene tenerla al lado de esta, porque la ocupación en bruto de la que habla todo este artículo sale de ahí.

Lo que se hace a las tres de la mañana, y lo que cuesta

Con el clúster parado y las máquinas de los clientes congeladas, lo primero que aparece en cualquier búsqueda es subir el umbral:

ceph osd set-full-ratio 0.96

Funciona, y no vamos a fingir que nunca lo hemos escrito. Como maniobra es legítima: devuelve la escritura durante el rato justo para borrar una instantánea vieja, mover un disco de sitio o encender un OSD nuevo. Como estado es una hipoteca, y conviene saber contra qué techo la firmas: por encima del full ratio del monitor hay otro umbral que aplica el propio OSD, osd_failsafe_full_ratio, que vale 0,97 por defecto. Subirlo hasta ahí es pegar el uno al otro y quedarte sin nada entre el umbral que para las escrituras y el frenazo del disco; y por encima de 0,97 el clúster te contesta con un OSD_OUT_OF_ORDER_FULL en rojo, el mismo aviso del párrafo anterior. Por eso la maniobra es 0,96 y el reloj puesto: lo que se sube en una emergencia se baja al día siguiente, y eso es una tarea con fecha en el calendario, no una intención.

La salida ordenada es añadir capacidad, y ahí es donde el problema deja de ser de Ceph. Un OSD más significa un hueco de bahía, o un nodo más significa unidades de rack, potencia contratada y refrigeración para disiparla; eso ya no se resuelve por consola, y lo contamos en el colocation ya no se negocia en U, se negocia en kW. Y aunque el hierro esté, la reconstrucción no es gratis: mover teras entre discos compite con la producción por las mismas colas de entrada y salida, que es lo que gobierna el planificador del OSD y lo que explicamos en Ceph no rinde lo que pone en la ficha del disco. Recuperar espacio con el clúster ya angustiado es la peor hora para pedirle rendimiento.

Cuatro comandos y un número en una hoja

ceph osd df
ceph df
ceph balancer status
ceph osd test-reweight-by-utilization

1. ceph osd df. Ordena por %USE y quédate con el máximo, no con la media. La columna VAR es la ocupación de cada disco dividida por la media, así que 1,00 es la media: si hay OSD por encima de 1,15 tienes un reparto torcido, no un clúster lleno. Para calibrarlo, el propio reweight-by-utilization ataca por defecto a los que superan la media en un 20 %.
2. ceph df. Mira MAX AVAIL por pool, no el AVAIL global, que es el que engaña. La documentación avisa de que ese valor es «a complicated function of the replication or the kind of erasure coding used, the CRUSH rule that maps storage to devices, the utilization of those devices, and the configured mon_osd_full_ratio setting»: la utilización de los dispositivos y el full ratio ya están dentro del número.
3. ceph balancer status. Comprueba que está activo y en modo upmap. Si te dice que no puede usarlo, busca al cliente antiguo que lo impide antes que cualquier otra cosa.
4. ceph osd test-reweight-by-utilization. Es la versión en seco: la documentación la describe como la forma de averiguar a cuántos grupos y OSD afectaría un reweight-by-utilization antes de ejecutarlo. Mírala antes de tocar pesos a mano.

El número de la hoja es uno solo y no cambia casi nunca: el porcentaje de ocupación en bruto a partir del cual dejas de sobrevivir a perder un nodo. Lo sacas de la tabla de arriba, le restas los puntos de desequilibrio que te enseñe ceph osd df, y lo pones como umbral de alerta en la monitorización. El propio manual de Proxmox usa esa misma lógica cuando explica cómo quitar un OSD: «make sure that all OSDs have their Used (%) value well below the nearfull_ratio of default 85%». Cómodamente por debajo. No rozando.

Cuándo esto no te quita el sueño

Si tu clúster está al 40 %, los discos son todos iguales, el balanceador va en upmap y creces 200 GB al mes, tienes años por delante y ninguna decisión que tomar. Haz la cuenta una tarde, pon la alerta y olvídate. Tampoco te afecta si el crecimiento es plano porque lo que guardas son datos operativos con retención cerrada: ahí el problema no es la capacidad, es el tiempo que tardas en recuperarlos.

Sí te afecta, y bastante, en tres situaciones concretas. Cuando el crecimiento lo generan máquinas virtuales que nadie borra nunca —instantáneas de antes de una actualización que salió bien hace dieciocho meses, clones de pruebas, el disco de un servidor que alguien apagó hace un año y nadie borró—. Cuando has ido ampliando el clúster con discos de tamaños distintos, que es lo normal cuando compras cada año. Y cuando el número de nodos es pequeño, porque es donde la fracción (N−1)/N muerde de verdad: la diferencia entre cuatro nodos y diez son catorce puntos porcentuales de disco que creías tener y no tienes.

Nota de fuentes

Umbrales y textos de las comprobaciones de salud (OSD_FULL, OSD_BACKFILLFULL, OSD_NEARFULL, OSD_OUT_OF_ORDER_FULL): documentación oficial de Ceph, «Health checks». Valores por defecto 0,85 / 0,90 / 0,95 de mon_osd_nearfull_ratio, mon_osd_backfillfull_ratio y mon_osd_full_ratio, y el ejemplo del clúster de 33 nodos con 99 TB: «Monitor Config Reference», apartado «Storage Capacity». Definición de MAX AVAIL: «Monitoring a Cluster». Modo por defecto del balanceador, requisito de versión de los clientes y el apartado «Limitation: count-based balancing vs. size-based balancing», de donde sale que el balanceador optimiza por número de fragmentos y no por bytes: «Balancer Module». El valor 0,97 de osd_failsafe_full_ratio es el valor por defecto que trae el fichero de opciones del código de Ceph (src/common/options/global.yaml.in), no una página del manual. Comandos ceph osd df, reweight-by-utilization y su versión en seco: «Control Commands». Valores por defecto de pool en Proxmox (tamaño 3, min_size 2), la advertencia sobre min_size 1 y la de mantener los OSD cómodamente por debajo del 85 % antes de retirar uno: manual de Proxmox VE, capítulo «Deploy Hyper-Converged Ceph Cluster». Las citas se reproducen en su idioma original y se traducen en el texto. La tabla de capacidad con un nodo menos es un cálculo nuestro, no una cifra publicada por Ceph: aplica 0,95 × (N−1) / N a la primera columna, 0,90 × (N−1) / N a la segunda —la que decide si la reconstrucción llega a terminar— y 0,85 × (N−1) / N a la tercera. Supone dominio de fallo por nodo, nodos de igual capacidad, reparto perfecto, que el nodo caído permanece fuera el tiempo suficiente para que Ceph reconstruya sus réplicas y que el esquema de protección cabe en los N−1 dominios que quedan (con codificación de borrado 4+2 sobre seis nodos, por ejemplo, perder uno tampoco reconstruye). Los porcentajes de la tabla están truncados a la baja. Con discos desiguales o reparto torcido, el número real es peor. Las opiniones sobre subir el full ratio en caliente y sobre qué mirar en la monitorización salen de operar Proxmox VE con Ceph en producción, no de las fuentes citadas.