Asume failure domain = host (la práctica estándar): las réplicas o fragmentos se distribuyen entre nodos distintos, no entre discos del mismo nodo.
Ceph bloquea escrituras en TODO el clúster cuando un solo OSD cruza su full_ratio (95% por defecto) — no cuando el promedio se llena. Operar por debajo de este umbral deja margen para el desbalance normal entre discos y para reconstruir tras perder un nodo.
Con nodos tienes el mínimo estricto para — si un nodo falla, no queda dónde reconstruir la redundancia perdida hasta que regrese. Para producción real, agrega al menos 1 nodo más de margen.
| Esquema | Capacidad útil | Práctica | Tolerancia |
|---|---|---|---|
Estimación de referencia basada en el modelo de capacidad de Ceph (replicación / Erasure Coding con failure domain = host). No sustituye el dimensionamiento con el CRUSH map real, la distribución efectiva de PGs, ni las pruebas de carga sobre el hardware final.
¿Por qué la capacidad "útil" de Ceph no es la capacidad que realmente puedes usar?
Ceph reporta capacidad útil como la matemática pura: capacidad raw dividida entre el factor de redundancia (3 en replicado 3x, o (k+m)/k en Erasure Coding). Pero ese número no es el que deberías planear usar. Ceph bloquea escrituras en todo el clúster cuando un solo OSD —no el promedio, uno solo— cruza su full_ratio (95% por defecto). La distribución de datos entre discos nunca es perfectamente uniforme, así que ese límite se alcanza en algún disco individual antes de que el clúster "en promedio" esté lleno.
Por eso la práctica operativa es mantener el clúster por debajo de 80-85% de su capacidad útil (el nearfull_ratio, que dispara alertas, es 85% por defecto). Ese margen no es desperdicio — es el espacio que necesitas para: (1) el desbalance normal entre OSDs, y (2) reconstruir la redundancia completa después de perder un nodo, sin cruzar el límite de escritura mientras lo haces.
Replicación vs. Erasure Coding: la decisión real
- Replicado 3x — el pool de VMs (RBD): mejor latencia y menor costo de CPU en cada escritura, porque no hay que calcular paridad. Es el esquema recomendado para el almacenamiento de máquinas virtuales en un clúster Proxmox VE, donde el IOPS y la latencia importan más que la eficiencia de espacio.
- Erasure Coding — backup, archivo, datos fríos: mejor eficiencia de espacio (66% en un perfil 4+2, contra 33% de replicado 3x) a cambio de más CPU y más latencia en cada reconstrucción. Tiene sentido para pools que no cargan IOPS de VMs en vivo — repositorios de backup, RGW de objetos, archivo.
- La combinación típica en Proxmox HCI: un pool replicado 3x para las VMs y, si el clúster también sirve como repositorio de backup, un pool EC separado para eso. No es una decisión de "uno u otro" para todo el clúster.
El nodo, no solo el disco, es la unidad de falla que importa
Con failure domain = host, perder un OSD individual es un evento menor — Ceph lo reconstruye automáticamente usando los OSDs restantes del mismo nodo y de otros nodos. El evento que de verdad hay que dimensionar es perder un nodo completo: de golpe salen todos sus OSDs a la vez, y el clúster necesita espacio libre en los nodos restantes para reconstruir esa redundancia perdida. Por eso esta calculadora reporta la tolerancia en nodos, no en discos — es la unidad de riesgo real en un despliegue HCI sobre Proxmox.
El backend de red que carga esa replicación y esa reconstrucción también forma parte del dimensionamiento — una red de 1G se satura con el tráfico de recuperación de un solo nodo caído. 10G dedicado para la red de clúster de Ceph es la práctica estándar, no un lujo.
Preguntas frecuentes
¿Vas a desplegar un clúster Ceph sobre Proxmox VE?
Somos partner oficial de Proxmox. Diseñamos y operamos clústeres HCI Proxmox + Ceph desde nuestro NOC/SOC, incluida la migración desde VMware.
Herramientas relacionadas
Otras herramientas gratuitas de IT Experts