Ceph ofrece varias formas de proteger los datos dentro de un clúster distribuido, pero dos enfoques concentran la mayor parte de las decisiones prácticas: replicación con tres copias, conocida habitualmente como Replica 3, y Erasure Coding, una técnica que divide los datos en fragmentos y añade paridad para reconstruirlos si se produce un fallo. La elección no es menor. Afecta al coste por terabyte útil, al rendimiento, a la latencia, al consumo de CPU, a la complejidad operativa y al tipo de cargas que conviene alojar.
En un momento en el que el precio de la capacidad, el crecimiento de los datos y la presión por reducir costes pesan cada vez más en las arquitecturas de almacenamiento, Erasure Coding vuelve a estar en muchas conversaciones. Pero no es una sustitución directa de Replica 3. En Ceph, cada método tiene sentido en escenarios distintos, y elegir mal puede convertir un ahorro en disco en un problema de rendimiento o disponibilidad.
Replica 3: simple, rápida y cara en capacidad
Replica 3 es el enfoque más fácil de entender. Cada dato se almacena en tres copias distribuidas en distintos OSD, normalmente repartidos entre nodos o dominios de fallo definidos por CRUSH. Si un disco falla, el clúster conserva otras dos copias. Si se pierde un segundo OSD en condiciones controladas, sigue existiendo una copia disponible. Esta sencillez explica por qué es una opción tan extendida en entornos de virtualización, bases de datos, almacenamiento de máquinas virtuales y cargas sensibles a la latencia.
Su mayor virtud es también su coste: por cada 1 TB útil se consumen 3 TB brutos. Dicho de otra forma, el overhead es del 200 %. Esa inversión en redundancia ofrece una operación más directa, menos cálculo y un comportamiento muy predecible en lecturas y escrituras. Para RBD, máquinas virtuales, discos de contenedores y servicios críticos, Replica 3 sigue siendo una opción muy sólida.
La desventaja es evidente cuando el volumen crece. Almacenar decenas o cientos de terabytes en Replica 3 obliga a comprar mucha capacidad bruta. Para datos fríos, repositorios grandes, archivos de ofimática, imágenes, vídeo, copias secundarias o cargas de lectura intensiva con pocas modificaciones, puede resultar excesivo.
Erasure Coding: más capacidad útil, más cálculo y más planificación
Erasure Coding funciona de otra manera. En lugar de guardar copias completas, Ceph divide cada objeto en fragmentos de datos, definidos por el parámetro k, y añade fragmentos de paridad, definidos por el parámetro m. Con esos fragmentos, el sistema puede reconstruir la información aunque se pierda un número determinado de OSD o dominios de fallo. La documentación de Ceph explica este modelo como una división del objeto en chunks de datos y chunks de codificación almacenados en distintos OSD.
Un perfil 4+2, por ejemplo, divide los datos en cuatro fragmentos y añade dos fragmentos de paridad. Esto permite tolerar la pérdida de dos fragmentos y reduce el consumo bruto frente a Replica 3. En términos prácticos, para almacenar 100 TB útiles se necesitarían alrededor de 150 TB brutos, frente a 300 TB con Replica 3. La eficiencia mejora, pero aparece un coste adicional: cada escritura exige cálculo de paridad, más coordinación entre OSD y más sensibilidad a latencia, CPU, red y tamaño de bloque.
| Perfil | Capacidad bruta aproximada necesaria para 100 TB útiles | Fallos tolerados | Uso típico |
|---|---|---|---|
| Replica 3 | 300 TB | 2 copias pueden perderse antes de quedar sin réplica | Máquinas virtuales, bases de datos, servicios críticos |
| EC 2+1 | 150 TB | 1 fragmento | Pruebas o entornos poco críticos |
| EC 4+2 | 150 TB | 2 fragmentos | Archivos grandes, datos fríos, repositorios, backup secundario |
| EC 6+3 | 150 TB | 3 fragmentos | Almacenamiento de alta capacidad con más resiliencia |
| EC 8+3 | 137,5 TB | 3 fragmentos | Datos fríos a gran escala |
| EC 8+4 | 150 TB | 4 fragmentos | Grandes volúmenes con más tolerancia a fallos |
La tabla muestra una realidad que a veces se pasa por alto: Erasure Coding no siempre reduce más capacidad por añadir más paridad. Lo que cambia es el equilibrio entre eficiencia, resiliencia, número mínimo de OSD o nodos y coste de reconstrucción. Cuanto más ambicioso es el perfil, más importante resulta diseñar bien el clúster.
Ceph recomienda que la mayoría de despliegues con pools Erasure Coded dispongan de al menos k+m dominios de fallo CRUSH, que en muchos casos serán hosts o racks. Esto es importante: no basta con contar discos. Si todos los fragmentos acaban demasiado concentrados, la pérdida de un nodo puede afectar a más piezas de las que el perfil puede tolerar.
Rendimiento: dónde gana cada opción
Replica 3 suele comportarse mejor en escrituras pequeñas, cargas aleatorias y servicios que requieren baja latencia. No hay que calcular paridad ni reconstruir fragmentos para cada operación normal. El sistema escribe copias completas, replica y confirma según la configuración. Esto lo convierte en una opción más natural para RBD, discos de máquinas virtuales, bases de datos, colas, sistemas transaccionales y aplicaciones con muchas escrituras pequeñas.
Erasure Coding brilla cuando la prioridad es la eficiencia de capacidad y los datos son grandes, menos cambiantes o más orientados a lectura. Archivos de gran tamaño, almacenamiento de objetos, repositorios documentales, contenido multimedia, backups secundarios, datasets científicos o datos de archivo pueden beneficiarse de su menor overhead. La propia documentación de Ceph usa como ejemplo de pool Erasure Coded un escenario de almacenamiento frío con objetos grandes y muy pocas escrituras frente a lecturas.
El problema aparece cuando se intenta usar Erasure Coding como si fuera Replica 3. Las escrituras pequeñas pueden penalizarse. La reconstrucción tras fallo consume más CPU y red. La recuperación puede ser más lenta y exigente. Además, en escenarios degradados, el clúster tiene que leer varios fragmentos y recalcular datos, lo que aumenta la presión sobre el sistema.
RBD, CephFS y allow_ec_overwrites
Durante años, una de las limitaciones habituales de los pools Erasure Coded fue que estaban pensados principalmente para operaciones de escritura completa de objetos, como las de RGW. Desde Ceph Luminous se puede habilitar allow_ec_overwrites para permitir escrituras parciales en pools Erasure Coded, lo que abre la puerta a que RBD, CephFS y librados almacenen datos en este tipo de pool.
Esto no significa que Erasure Coding sea automáticamente recomendable para cualquier disco de máquina virtual. En RBD, lo habitual es mantener un pool replicado para metadatos y usar el pool Erasure Coded como data pool. Es una arquitectura válida, pero exige entender sus implicaciones. Para una máquina virtual con carga ligera, ficheros grandes o datos poco cambiantes puede tener sentido. Para bases de datos, sistemas de correo muy activos, ERP, cargas transaccionales o servicios con I/O pequeño e intenso, Replica 3 suele ser más prudente.
En virtualización, la pregunta no debería ser “¿puedo usar Erasure Coding?”, sino “¿qué patrón de I/O tiene esta carga?”. Si la aplicación escribe mucho, en bloques pequeños y con exigencia de baja latencia, el ahorro en disco puede salir caro. Si el dato se escribe poco, se lee ocasionalmente y ocupa mucho espacio, Erasure Coding puede ser una buena herramienta.
La decisión práctica: coste frente a comportamiento
La comparación entre Replica 3 y Erasure Coding suele empezar por la capacidad, pero debería terminar en el tipo de servicio. Replica 3 consume más disco, pero reduce complejidad y ofrece mejor comportamiento para cargas vivas. Erasure Coding ahorra capacidad, pero exige más cálculo, mejor red, más atención al diseño del dominio de fallo y una gestión más cuidadosa de los perfiles.
| Criterio | Replica 3 | Erasure Coding |
|---|---|---|
| Eficiencia de capacidad | Baja: 3 TB brutos por 1 TB útil | Alta: depende de k+m |
| Latencia | Mejor, especialmente en escrituras pequeñas | Mayor por cálculo y distribución |
| Consumo de CPU | Menor | Mayor por codificación y reconstrucción |
| Simplicidad operativa | Alta | Media o baja, según perfil |
| Recuperación tras fallo | Más directa | Más intensiva en cálculo y red |
| Máquinas virtuales críticas | Recomendable | Solo con cautela y casos concretos |
| Bases de datos | Recomendable | No aconsejable en general |
| Archivos grandes y datos fríos | Puede resultar caro | Muy adecuado |
| Backups secundarios | Válido, pero costoso | Adecuado si se acepta el perfil de rendimiento |
La mejor arquitectura suele combinar ambos enfoques. Un clúster Ceph puede usar pools Replica 3 para máquinas virtuales críticas, bases de datos y servicios sensibles a latencia, y pools Erasure Coded para datos fríos, repositorios grandes o almacenamiento de objetos. Esta separación permite optimizar coste sin convertir todo el entorno en una apuesta única.
También conviene recordar que Erasure Coding no sustituye a una estrategia de backup. Protege frente a fallos de discos o nodos dentro del clúster, pero no evita borrados accidentales, corrupción lógica, ransomware, errores humanos o problemas de aplicación. Para eso siguen haciendo falta copias de seguridad, retención, pruebas de restauración y, cuando proceda, réplicas fuera del clúster o en otra ubicación.
Ceph da mucha flexibilidad, pero esa flexibilidad obliga a diseñar. Replica 3 es la respuesta conservadora para cargas críticas y activas. Erasure Coding es una herramienta potente para ganar capacidad útil cuando el patrón de datos lo permite. La decisión correcta no es elegir una tecnología ganadora, sino asignar cada una al lugar donde aporta más valor.
Preguntas frecuentes
¿Qué diferencia hay entre Replica 3 y Erasure Coding en Ceph?
Replica 3 guarda tres copias completas de los datos. Erasure Coding divide los datos en fragmentos y añade fragmentos de paridad para reconstruirlos si se produce un fallo. Replica 3 consume más capacidad, pero suele ofrecer menor latencia y más simplicidad.
¿Qué significa un perfil 4+2 en Erasure Coding?
Significa que cada objeto se divide en cuatro fragmentos de datos y dos fragmentos de paridad. Puede tolerar la pérdida de dos fragmentos y ofrece una eficiencia de capacidad superior a Replica 3.
¿Puedo usar Erasure Coding para máquinas virtuales?
Es posible con configuraciones adecuadas, como allow_ec_overwrites y separación entre pool de metadatos replicado y data pool Erasure Coded. Pero no suele ser la mejor opción para máquinas virtuales críticas, bases de datos o cargas con muchas escrituras pequeñas.
¿Cuándo conviene usar Erasure Coding?
Tiene sentido para archivos grandes, datos fríos, repositorios documentales, almacenamiento de objetos, backups secundarios o contenido que cambia poco y ocupa mucho espacio. Para cargas transaccionales o muy sensibles a latencia, Replica 3 suele ser mejor elección.
