Ampliar Ceph por un solo nodo no amplía nada

La entrada del blog de Ceph va fechada el 11 de noviembre de 2026 —el blog la fecha mañana; nosotros la leímos hoy— y la firma Anthony D'Atri. Empieza hablando de tarta de Acción de Gracias y termina con un ejemplo que vale una reunión de presupuesto: tres nodos con pesos 100, 100 y 1.138. Hay 1.338 de disco crudo. El pool escribe 95. Y 1.043 —el 78 % de lo que pagaste— no lo puede usar nadie, nunca.

Operamos Proxmox VE con Ceph en producción, repartido en varios centros de datos, y la conversación que más se repite cuando a alguien se le llena el clúster es siempre la misma: «tenemos hueco en el nodo tres, le metemos discos ahí y listo». Es la respuesta natural, es la más barata, y en un clúster de tres nodos con réplica 3 no sirve absolutamente para nada. No es opinión nuestra: es aritmética de CRUSH, y el autor acaba de publicarla con una calculadora al lado para que nadie se la crea de palabra.

La regla que decide tu capacidad cabe en una línea

Cada grupo de colocación (PG) de un pool es una tarta. Un pool replicado la corta en tantas porciones idénticas como diga su size; uno de código de borrado la corta en k porciones de datos y m de paridad. CRUSH reparte esas porciones entre los dominios de fallo que nombre la regla del pool, como mucho una porción a cada uno, de modo que perder un nodo, un rack o una sala le cueste a cada PG como mucho una sola porción. Esa es la parte que protege tus datos. La parte que decide tu factura es el corolario, y el autor lo escribe sin rodeos: «A failure domain can never hold more than 1/n of what the pool stores, however big it is.»

Donde n es el size del pool replicado o el k+m del de código de borrado. El dominio de fallo por defecto es el host: lo usan tanto la regla replicada por defecto como el perfil de código de borrado por defecto. Y el peso CRUSH de un dominio es la suma de los pesos de sus OSD, que por defecto es su capacidad en TiB. El cambio mental, entonces, es este: tu capacidad no es la suma de tus discos. Es el crudo que CRUSH puede repartir sin que ningún dominio pase de 1/n, rebajado por el full_ratio (0,95 por defecto, el punto en el que Ceph corta las escrituras) y dividido entre n —o multiplicado por k/(k+m) si vas con código de borrado—. Y cuando tienes exactamente n dominios, eso es sencillamente lo que quepa en el más pequeño. El relleno, además, se detiene antes, en el backfillfull_ratio (0,90).

1.338 de disco, 95 escribibles

Estos son los tres repartos que publica el autor, puestos uno debajo de otro. Conviene leer la columna «escribe» con cuidado: son unidades de dato, no de crudo. Con réplica 3, escribir 95 ocupa 285 de disco.

Las dos últimas filas son la misma cifra. Un cuarto nodo de 1.701 y un cuarto nodo de 150 escriben exactamente lo mismo: 142,5. De esos 1.701, trabajan 150. Los otros 1.551 están ahí para que alguien los vea en el inventario. Y la comparación que a nosotros nos parece la que de verdad duele es esta otra, que no está en el artículo pero sale de sus mismos números: pasar de tres nodos de 100 a cuatro de 100 sube la capacidad de 95 a 126,7, un 33 % más; meterle 1.038 de disco a uno de los tres la deja en 95, igual que estaba.

La fórmula para llevar a la reunión de compras

El autor la deja escrita de dos maneras equivalentes: ningún dominio de fallo puede aprovechar más de 1/n de la capacidad cruda del pool; o, dicho al revés, el dominio más grande puede ser como mucho la suma de los demás dividida entre n−1. Eso es una fórmula de hoja de cálculo, y aguanta una reunión con el comercial que te quiere vender la caja grande.

Apliquémosla a un caso que no está en el artículo. Tienes cinco nodos de 100 y vas a comprar el sexto. Con réplica 3, n = 3, la suma de los otros es 500, y el nodo nuevo puede llegar a 250 sin desperdiciar nada. Con código de borrado 4+2, n = 6, la misma suma de 500 dividida entre cinco deja el techo en 100: ni un disco más. Es decir, el mismo hierro, el mismo presupuesto y la misma sala dan dos respuestas distintas según una decisión que se tomó al crear el pool, probablemente hace años, probablemente sin apuntarla en ningún sitio.

CRUSH por su cuenta no llega al techo

Todas las cifras de arriba suponen un reparto perfecto, y CRUSH solo no lo consigue. Su algoritmo straw2 sortea cada dominio en proporción a su peso, pero si le sale uno que el PG ya está usando, vuelve a sortear. El efecto es que un dominio pesado se elige menos veces de lo que su peso diría, y los ligeros se llenan antes de tiempo. En el reparto 100·100·100·150, el techo con reparto equilibrado es 142,5 y sin varar nada; CRUSH por su cuenta se queda en unos 132, que es cuando se llena el primer nodo pequeño.

El mismo disco muerto, dos finales distintos

Aquí es donde la cuenta deja de ser contable y se vuelve operativa. Muere un OSD de peso 10 en uno de tres nodos de 100, con réplica 3. Cada PG ya tiene una copia en los otros dos nodos, así que lo que había en ese OSD solo se puede volver a proteger dentro de su propio nodo. Ese nodo pasa a valer 90, y como todos los PG tienen una copia en él, marca el paso: el techo del pool cae de 95 a 85,5. Pierdes 9,5 por el disco muerto y otros 9,5 en cada uno de los dos nodos sanos, que dejan de poder usarse.

Y ahora la frase que debería estar colgada en la pared de cualquiera que opere un Ceph de tres nodos: el relleno se detiene en el backfillfull_ratio, así que si el pool guardaba más de 81 —el 85 % de su techo— cuando murió el disco, la recuperación se para con los PG todavía degradados. No es que vaya lenta: es que no termina. Con un cuarto nodo de 100, el mismo disco muerto baja el techo solo de 126,7 a 123,5, y para reproteger del todo basta con estar por debajo de 117, el 92 % del techo. Si lo que pierdes es un nodo entero de tres, no hay dónde reproteger: los PG se quedan degradados hasta que el nodo vuelva. De cuatro, se reprotegen en los otros tres mientras el pool esté por debajo de 90, el 71 % de su techo.

El mismo disco muerto, en el mismo armario, el mismo martes. Con cuatro nodos es papeleo —se repone solo y lo cuentas el lunes—; con tres, es un clúster degradado esperando a que llegue el recambio. La diferencia no la decide el disco ni la suerte: se decidió meses antes, cuando alguien eligió tres nodos en lugar de cuatro porque tres era lo que hacía falta para el quórum. Ya lo contamos con más detalle en por qué un Ceph de tres nodos no se cura solo, aguanta, y este artículo le pone por fin los números de capacidad al lado.

Código de borrado: la misma cuenta, con k+m

Un pool 4+2 sobre seis nodos de 100 escribe 380. Muere un OSD de peso 10 y el techo cae a 342; para reproteger del todo hace falta estar por debajo de 324. Sobre siete nodos de 100, el mismo pool escribe 443,3, el mismo fallo lo deja en 437 y la reprotección pide estar por debajo de 414. Lo que compra ese séptimo nodo, dicho con los porcentajes que hemos sacado nosotros de sus cifras: un 17 % más de capacidad, convertir una caída de 38 en una de 6, y pasar de tener que ir al 85 % del techo a poder ir al 93 %. Tres cosas distintas, y solo una de ellas aparece en una hoja de cálculo de compras.

Y una advertencia que el autor despacha en una frase y que nosotros repetimos cada vez que alguien propone m = 1 para ahorrar un disco de paridad: «if you choose m=1, expect data unavailability during maintenance and data loss when component failures overlap». No es un «no recomendado» de manual. Es que durante un mantenimiento planificado —el tuyo, el del martes— el pool no está disponible, y si un fallo pilla a otro por medio, los datos se pierden. El PG Calc reescrito marca en ámbar precisamente eso: los pools con menos de tres réplicas y los que llevan m = 1.

Las cinco órdenes que miramos antes de firmar una ampliación

Cuando nos llaman para «ampliar el Ceph», la primera pregunta no es qué discos, es cuántos dominios de fallo hay y cuánto pesa cada uno. Esta es la cuenta de fuera del nodo; la de dentro —los umbrales por OSD y por qué el disco más lleno manda sobre todo el clúster— la contamos en la capacidad la marca el disco más lleno. Esto es lo que ejecutamos antes de mirar un catálogo, y se puede copiar tal cual:

Con esas cinco salidas y la fórmula de arriba, la recomendación sale sola, y bastantes veces es la que peor sienta en una reunión de presupuesto: no compres discos todavía, compra un nodo. Es una factura más incómoda de defender y bastante más trabajo de puesta en marcha, pero es la única respuesta que arregla a la vez la capacidad y la recuperación. Y hay un «cuándo no» igual de honesto: si tu clúster ya tiene cinco o seis dominios bien repartidos y lo que necesitas es volumen, entonces sí, discos; en ese reparto la fórmula te da margen de sobra y no hace falta gastarse un servidor entero.

Un apunte de versiones, porque el artículo lo menciona de pasada y tiene consecuencias: el autoescalador de PG responde bien a la pregunta de cuántos PG debe tener un pool en muchos clústeres con releases recientes —el matiz es suyo, no lo vende como universal— una vez el mon_target_pg_per_osd está al menos en 200, y ese es su valor por defecto a partir de la release Umbrella. Si tu clúster viene de atrás, ese parámetro probablemente siga donde estaba. Sobre quién tiene hoy Umbrella y quién no, ya escribimos lo que trae y lo que no trae el asistente de Proxmox. Y si lo que te preocupa es la otra cara —qué pasa cuando la reposición de copias está apagada a propósito—, está en lo que hace de verdad el flag noout.

Las sobras, que es donde está la comida

El artículo cierra con cinco líneas bajo el título «Leftovers». Las traducimos porque valen más que el resto de este texto:

• Ten al menos un dominio de fallo más que el size del pool o su k+m.
• Mantén los dominios de fallo con pesos parecidos: ninguno puede aprovechar más de 1/n de la capacidad cruda.
• Añade capacidad repartida entre dominios, no a uno solo.
• Deja el balanceador encendido.
• Deja sitio por debajo del backfillfull para que la recuperación quepa.

Nosotros le añadimos una séptima, que no es técnica: mide el peso, no el catálogo. El ceph osd df tree se ejecuta antes de la orden de compra, no después de que el comercial haya puesto la oferta encima de la mesa. Cuesta treinta segundos y es lo único que separa «hemos ampliado el almacenamiento» de «hemos ampliado el inventario».

Fuentes (consultadas el 10-11-2026): todas las cifras de reparto, fallo y reprotección —100·100·1.138 escribiendo 95 con 1.043 varados (78 % del crudo); 100·100·100·1.701 escribiendo 142,5 con el mismo 78 % varado; el tope de 150 para el cuarto nodo; 100·100·100·150 llegando a 142,5 equilibrado y a unos 132 con CRUSH solo; la caída de 95 a 85,5 y el umbral de 81 al morir un OSD de peso 10 en tres nodos de 100; la de 126,7 a 123,5 y el umbral de 117 con cuatro; los 90 (71 % del techo) al perder un nodo entero de cuatro; y el pool 4+2 con 380 → 342 → 324 sobre seis nodos y 443,3 → 437 → 414 sobre siete—, las dos frases citadas («A failure domain can never hold more than 1/n of what the pool stores, however big it is» y «if you choose m=1, expect data unavailability during maintenance and data loss when component failures overlap»), la regla del dominio mayor ≤ suma de los demás ÷ (n−1), el comportamiento de straw2 al volver a sortear, el balanceador activo por defecto en modo upmap, los valores por defecto 0,95 y 0,90 de full_ratio y backfillfull_ratio, el mon_target_pg_per_osd en 200 por defecto desde Umbrella, el ámbar del PG Calc para m=1 y menos de tres réplicas, y la lista de «Leftovers» — «Slicing the Pie: CRUSH Failure Domains and Your Capacity», de Anthony D'Atri, blog oficial de Ceph, fechado el 11-11-2026, que incluye además una calculadora interactiva —la misma que la documentación publica como FD Calc— y el PG Calc reescrito. Son elaboración nuestra, a partir de esas mismas cifras: la comparación entre pasar de tres a cuatro nodos de 100 (95 → 126,7, un 33 % más) frente a engordar uno de los tres (95 → 95); el ejemplo del sexto nodo con cinco de 100, con techo de 250 en réplica 3 y de 100 en 4+2; el cálculo de que los 10,5 que se deja CRUSH sin balanceador son un 7 % de la capacidad usable; los porcentajes de margen del 85 % y el 93 % del techo en el caso 4+2 de seis y siete nodos, y el 17 % de capacidad extra del séptimo nodo; los 1.551 del cuarto nodo de 1.701, que salen de restarle el tope útil de 150 que publica el artículo y no de su convención de capacidad varada (que para ese caso da 78 % del crudo); la formulación de la capacidad como crudo repartible ÷ n tras el full_ratio; las cinco órdenes de comprobación; y el «cuándo no» del final. Fotografía: «20-Bay Hard Drive Case 20251006 – fünf 3,5"-HDDs», de PantheraLeo1359531, CC BY 4.0 vía Wikimedia Commons, original de 9.531 × 6.357, recortada y aclarada por nosotros.