En un cluster Ceph con 384 TB brutos, réplica 3 te deja 128 TB útiles. Erasure coding 4+2 te deja 256 TB, aguantando los mismos dos fallos simultáneos. El doble de espacio con el mismo hardware: la propia documentación de Ceph lo dice así de claro. Y aun así, nosotros —que operamos Ceph en producción, repartido en varios datacenters— seguimos poniendo los discos de las VMs en réplica 3. No es nostalgia. Es que la del espacio es solo una de las cuatro cuentas, y las otras tres casi nunca salen en la presentación.
La cuenta que sale en las presentaciones: el espacio
Primero, qué hace cada uno. Con réplica 3 (el tipo de pool por defecto en Ceph), cada objeto se escribe entero tres veces, en tres OSDs de tres hosts distintos. Sobrevives a la pérdida de dos copias porque siempre queda una tercera. El precio: por cada TB de datos consumes 3 TB de disco. Factor 3,0; un 33% de espacio útil.
Con erasure coding, el objeto se trocea en k fragmentos de datos y se calculan m fragmentos de paridad. Con el perfil 4+2, cada objeto son 6 fragmentos en 6 hosts, y con 4 cualesquiera se reconstruye el dato: aguantas la pérdida de 2. La sobrecarga es (k+m)/k = 1,5; un 67% de espacio útil. Es el RAID 6 elevado a sistema distribuido.
| Con 384 TB brutos (6 nodos × 8 discos de 8 TB) | Réplica 3 | EC 4+2 |
|---|---|---|
| Espacio útil | 128 TB (33%) | 256 TB (67%) |
| Fallos simultáneos que aguanta | 2 | 2 |
| Hosts mínimos (dominio de fallo = host) | 3 (cómodo con 4) | 6 (cómodo con 7) |
| Escrituras pequeñas aleatorias (VMs, BBDD) | Su terreno | Su punto débil |
Hasta aquí la cuenta del espacio, y la gana erasure coding por goleada: mismo hierro, misma tolerancia, 128 TB más. Si el análisis termina en esta tabla, migras todos los pools esta misma tarde. Sigamos con las cuentas que no salen.
La cuenta de las escrituras
Una escritura en réplica 3 es aburrida, y eso es un elogio: el OSD primario recibe el objeto y manda dos copias íntegras a sus compañeros. Tres escrituras, cero matemáticas, latencia predecible.
Una escritura en EC 4+2 trocea el objeto, calcula dos fragmentos de paridad (CPU) y reparte seis escrituras entre seis hosts. Para escrituras grandes y secuenciales, ese coste se amortiza bien. El problema es la escritura pequeña y aleatoria —exactamente lo que generan una VM o una base de datos—: modificar 4 KB dentro de una franja implica leer fragmentos, recalcular la paridad y volver a escribir. Donde réplica hacía tres escrituras y dormía tranquila, EC monta una operación de lectura-modificación-escritura repartida por el cluster.
No lo decimos solo nosotros. La documentación oficial de Ceph lo escribe con estas palabras: «no confundas el erasure coding con un almuerzo gratis: hay un sacrificio de rendimiento significativo, especialmente con discos HDD y durante la recuperación o el backfill del cluster». Cuando la documentación de un producto te avisa así de su propia funcionalidad, conviene escucharla.
¿Se puede poner un disco de VM sobre un pool EC? Poderse, se puede: desde Luminous existe allow_ec_overwrites (solo sobre BlueStore) para permitir escrituras parciales, y RBD funciona. La pregunta nunca fue si se puede. Es si quieres pagar ese peaje en cada escritura pequeña de cada VM, para siempre.
La cuenta de la recuperación
El día que un disco muere es cuando se paga la arquitectura. En réplica, recuperar es copiar: los OSDs que tienen las copias supervivientes las reenvían, y listo. En erasure coding, cada fragmento perdido se reconstruye: hay que leer k fragmentos de otros OSDs, rehacer las matemáticas y escribir el resultado. Más lecturas, más tráfico entre nodos y más CPU, justo en el momento en que el cluster está degradado y tus VMs siguen pidiendo IOPS como si no pasara nada. Es la diferencia entre fotocopiar una página y volver a redactarla a partir de los apuntes de cuatro compañeros.
La cuenta de los nodos (la que decide en una pyme)
Esta es la cuenta que más veces zanja la conversación. Con el dominio de fallo en el host —lo mínimo serio—, un pool EC necesita al menos k+m hosts: 6 nodos para un 4+2. Y la propia documentación recomienda tener k+m+1 para que el cluster pueda auto-repararse con un nodo caído: 7 nodos. Réplica 3 funciona con 3 y está cómoda con 4.
Si tu cluster tiene 3, 4 o 5 nodos —la mayoría de los clusters de virtualización que vemos en pymes—, la decisión está tomada antes de empezar: no hay dominios de fallo suficientes para un EC serio. ¿Perfiles pequeños tipo 2+1? Existen, y es el RAID 5 de los pobres: un solo fallo tolerado y una reconstrucción con el cluster conteniendo la respiración. Nosotros no ponemos m=1 en producción con datos que importen, y la documentación de Ceph tampoco recomienda alegrías: para bloque y fichero sugiere no pasar de m=3, y en general no elegir k>4 o m>2 sin entender muy bien las consecuencias.
Dónde sí brilla erasure coding
Nada de esto convierte el erasure coding en mala tecnología. Es una herramienta excelente para el trabajo correcto: datos que se escriben una vez, en bloques grandes, y sobre todo se leen.
- ✓Backups y archivo: repositorios de copias, datos fríos, retenciones largas. Escritura secuencial grande, lectura ocasional. El caso perfecto.
- ✓Almacenamiento de objetos (S3/RGW): media, documentos, datasets. Aquí un 67% de espacio útil frente a un 33% es dinero de verdad a medida que crecen los TB.
- ✓En Proxmox VE, si el cluster da la talla, la tubería ya viene puesta:
pveceph pool create <nombre> --erasure-coding k=4,m=2crea el pool EC de datos y su pool replicado de metadatos (EC no soporta las operaciones OMAP que RBD necesita, así que los metadatos van aparte). El obstáculo nunca es la herramienta; es la física.
Lo que hacemos nosotros
- ✓Discos de VM y bases de datos: réplica 3. Siempre. La latencia predecible y la recuperación simple valen más que los TB extra.
- ✓Erasure coding para lo frío —copias secundarias, archivo, objetos— y solo cuando el cluster tiene dominios de fallo de sobra para un perfil serio.
- ✗Ni réplica 2 ni m=1 para datos que importan. Ahorrar entre un sexto y un tercio del disco para jugarte el pool a un solo fallo es una mala compra.
- ✗No montamos un cluster de 7 nodos para perseguir el ahorro de EC en discos de VM. Si el presupuesto de discos te empuja a poner las VMs en erasure coding, el problema no es el tipo de pool: es el dimensionamiento.
En corto
Réplica 3 y erasure coding no compiten: hacen trabajos distintos. Réplica compra latencia baja y recuperaciones simples pagando en disco; erasure coding compra espacio pagando en CPU, red, complejidad y nodos. La trampa está en mirar solo la columna del espacio, que es la única que sale en la calculadora del presupuesto. Un pool para las VMs, otro para lo frío, y las cuatro cuentas hechas antes de crear ninguno: eso es diseñar almacenamiento, y no hay atajo.
Llevamos años operando almacenamiento distribuido Ceph bajo clusters Proxmox en producción, y esta decisión —qué pool, qué perfil, cuántos nodos— la hemos tomado muchas veces con datos reales delante. Es de las que salen baratas de pensar y carísimas de deshacer.
Fuentes (verificadas): sobrecarga (k+m)/k, cita del «free lunch», perfil 4+2 con «el doble de espacio útil que réplica size=3», recomendación de m≤3 y de no superar k=4/m=2 sin conocer las implicaciones, allow_ec_overwrites sobre BlueStore y requisito de k+m dominios de fallo (k+m+1 recomendado) — documentación oficial de Ceph; creación de pools EC y pool de metadatos replicado en Proxmox VE (pveceph pool create --erasure-coding, EC sin soporte completo de OMAP para RBD) — documentación de Proxmox VE (pveceph). El ejemplo de 384 TB es aritmética sobre esas fórmulas.
¿Diseñando (o sufriendo) un cluster Ceph?
En everyWAN diseñamos y operamos almacenamiento distribuido Ceph en producción, repartido en varios datacenters —con hardware propio y en infraestructura de nuestros clientes—. Te ayudamos a hacer estas cuentas con tus números —cargas, nodos, crecimiento— antes de que el pool equivocado las haga por ti.
Microsoft 365
ES 
CAT 
EN