Clúster Ceph con 2 OSD: por qué 3 MON no dan HA

Puedes lograr que un clúster de Proxmox con tres MON de Ceph y solo dos OSD funcione, pero seguirá siendo un mal diseño de almacenamiento en alta disponibilidad.

Es fácil entender cómo se llega a esta situación. Tres MON otorgan quorum de monitores a Ceph, por lo que el plano de control parece completamente sano. Dos OSD pueden almacenar dos copias de los datos, así que el pool también parece correcto mientras todo permanezca encendido. Si añades una red separada para Ceph, el esquema técnico empieza a parecer redundante sobre el papel. Sin embargo, en cuanto falla un nodo de almacenamiento, la brecha entre el quorum de los MON y la redundancia real de los datos pasa una factura inmediata.

Proxmox configura por defecto los pools de Ceph con tres réplicas, exigiendo al menos dos disponibles para aceptar operaciones de E/S. Un diseño con dos OSD no puede cumplir esa política habitual 3/2. Rebajar el pool a dos réplicas hace que la configuración encaje en el hardware disponible, pero elimina gran parte del margen de seguridad que justifica usar Ceph. Conseguir que Ceph arranque es sencillo; lo relevante es saber qué te queda en pie cuando algo se rompe.

¿Consiguen tres MON que un clúster Ceph con dos OSD tenga alta disponibilidad?

No, porque el quorum de MON y la redundancia de los OSD resuelven problemas completamente distintos. Un Ceph Monitor (MON) mantiene los mapas del clúster y participa en el consenso sobre el estado global. Conviene tener un número impar de ellos para que la mayoría sobreviva a la caída de un monitor. Un OSD (Object Storage Daemon), en cambio, almacena los datos reales.

Si tres MON siguen vivos pero un pool ha perdido demasiadas réplicas de OSD, el quorum no puede crear por arte de magia otra copia de los datos que faltan. Los monitores simplemente se pondrán de acuerdo en que el almacenamiento está degradado o no disponible.

La mayor parte de la confusión en torno a este clúster pequeño surge de mezclar ambos conceptos. El despliegue propuesto contaba con tres nodos Proxmox y tres MON, pero con OSD solo en dos de ellos. La tercera máquina era deliberadamente más modesta y ejecutaría cargas vinculadas a hardware específico, como Home Assistant con un adaptador Zigbee.

Un nodo cliente de Ceph sin OSD es perfectamente válido. Un nodo de Proxmox no necesita su propio OSD para utilizar un pool RBD; accede al almacenamiento Ceph a través de la red pública como cualquier otro cliente. El punto débil es que la totalidad de los datos reside en solo dos ubicaciones físicas, y el hecho de que el tercer nodo carezca de OSD no cambia esa realidad.

¿Por qué Proxmox configura los pools de Ceph con size 3 y min_size 2 por defecto?

Tres copias ofrecen un margen de tolerancia suficiente y permiten continuar con las operaciones de E/S mientras una réplica queda temporalmente inaccesible.

En la configuración actual de Proxmox Ceph, los valores predeterminados del pool son:

• size = 3
• min_size = 2

size representa el número de réplicas que Ceph intenta mantener para cada objeto. min_size es el número mínimo de réplicas que deben estar disponibles para que el pool acepte operaciones de lectura y escritura.

Un pool 3/2 en buen estado mantiene tres copias. Si un OSD o un host falla y una copia desaparece, quedan dos réplicas disponibles y el pool continúa prestando servicio mientras Ceph trabaja para restaurar la redundancia.

Con solo dos OSD no puedes tener tres réplicas distintas en servidores separados, lo que te deja dos únicas opciones, y ninguna se comporta como el Ceph 3/2 estándar.

La primera es size=2, min_size=2. Ambas copias son obligatorias para cursar E/S, por lo que perder uno de los dos OSD detiene el tráfico del pool al quedar únicamente una réplica en pie.

La segunda es size=2, min_size=1. El pool continúa funcionando apoyado en la única copia superviviente. Esto parece aportar mayor disponibilidad, hasta que adviertes que tu almacenamiento distribuido está sirviendo datos desde su última réplica restante. Un problema adicional de disco, un error de bits, un descuido del operador o cualquier otro incidente menor puede transformar un pool degradado en una pérdida irrecuperable de información.

Los ingenieros de Proxmox han alertado repetidamente contra la idea de normalizar la fórmula 2/1. En debates del foro oficial, el equipo de soporte calificó el esquema 2/1 como arriesgado porque un fallo en la réplica restante te deja sin copia válida, y recomendaron mantener la regla predeterminada 3/2 salvo requisitos muy específicos. Mantener el flujo de E/S y preservar la integridad de los datos son metas distintas, y el ajuste 2/1 sacrifica parte de la segunda en favor de la primera.

¿Es la red realmente el mayor problema?

No en este diseño en concreto. El número de OSD constituye el primer obstáculo arquitectónico, y la red propuesta podría añadir un segundo inconveniente grave.

Proxmox recomienda al menos 10 Gbps dedicados en exclusiva al tráfico de Ceph. Su documentación oficial advierte expresamente de que el tráfico de recuperación de Ceph puede interferir con la red de clúster de Corosync, extremadamente sensible a la latencia, llegando a provocar la pérdida del quorum del clúster. La propuesta inicial incluía ubicar el tráfico público de Ceph en la misma red física que Corosync. Eso puede funcionar en un laboratorio de pruebas, pero no es una opción recomendable si te preocupa el comportamiento ante contingencias.

Corosync apenas requiere ancho de banda, pero es sumamente vulnerable a la latencia y al jitter. Ceph, por su parte, genera ráfagas de tráfico masivas justo en el peor momento: cuando la infraestructura ya sufre por la avería de un OSD, durante la recuperación, el rellenado (backfill) o el rebalanceo de datos. Un clúster inactivo puede parecer impecable en las pruebas. El examen real consiste en desconectar un OSD mientras las máquinas virtuales generan operaciones intensivas de disco. Si la recuperación de Ceph satura el canal del que depende Corosync, el fallo de almacenamiento afectará a la pertenencia al clúster, y dos problemas independientes se transformarán en una caída total del servicio.

Para planificar adecuadamente clústeres pequeños, el hub de Proxmox de Mr.PlanB analiza almacenamiento, agrupación en clúster, migración y tolerancia a fallos de manera conjunta, evitando ajustar cada elemento como si fuera un parámetro aislado.

¿Para qué sirven en realidad las redes pública y de clúster de Ceph?

Llamar a la red pública "la red de los MON" ignora la mayor parte de su función. Los clientes de Ceph se comunican directamente con los OSD a través de la red pública. Los MON también atienden en ese segmento, pero lo decisivo es que el tráfico de almacenamiento de las máquinas virtuales de los nodos Proxmox llega a Ceph por esta interfaz frontal.

La red de clúster opcional tiene otro propósito. Cuando la configuras, Ceph la utiliza para los latidos (heartbeats) entre OSD, la replicación de objetos y el tráfico de recuperación interna entre discos.

Por tanto, un nodo Proxmox sin OSD sigue necesitando una buena conexión a la red pública de Ceph si va a ejecutar VM alojadas en ese almacenamiento. Alojar un servicio MON no obliga a participar en la replicación de OSD. En la conversación técnica original se hizo exactamente esta aclaración: el tercer nodo puede utilizar el pool de Ceph sin albergar OSD, porque el acceso al almacenamiento no se restringe a los equipos que guardan físicamente las réplicas.

Por esta misma razón, el enlace más lento del cliente marca la diferencia. Si un nodo de cómputo dispone únicamente de 1GbE hacia la red pública de Ceph mientras los nodos de almacenamiento cuentan con 2.5GbE o 10GbE, las máquinas virtuales de ese nodo estarán limitadas por el enlace más modesto. Esto no ralentiza cada enlace de Ceph en el clúster a 1Gbps, pero las cargas de trabajo en el nodo lento rendirán mucho peor que en los servidores mejor conectados.

¿Puede funcionar Ceph sobre 1GbE o 2.5GbE?

Sí, aunque lograr que funcione y conseguir que rinda adecuadamente durante una recuperación son metas muy distintas.

Un administrador que mantuvo una configuración similar de dos OSD y tres nodos la describió como operativa pero frustrante. Señaló que la experiencia recordaba a ejecutar máquinas virtuales sobre almacenamiento flash muy lento, con latencias altas y un caudal equivalente al de un enlace 1GbE saturado. Es la vivencia de un usuario y no una comparativa formal de Ceph, pero la limitación técnica que describe es real.

Los clientes de Ceph dialogan directamente con los OSD, estos replican los datos entre sí y las tareas de recuperación y rebalanceo añaden otra carga de tráfico notable encima. La red transporta mucho más tráfico que la simple escritura original iniciada por el sistema invitado. El proyecto Ceph advierte de que la replicación entre OSD impone una carga adicional sobre la red de almacenamiento. Sus recomendaciones indican que una única red pública basta para muchos despliegues si la conectividad es rápida, y que segregar la red de clúster resulta de gran ayuda cuando el tráfico es denso.

Proxmox es más estricto en despliegues hiperconvergentes y recomienda al menos 10 Gbps para Ceph. Con discos NVMe modernos, incluso 10GbE puede convertirse en el cuello de botella del sistema.

Por tanto, 2.5GbE resulta plenamente razonable en un laboratorio para aprender Ceph. Resulta mucho más difícil de defender en un entorno de almacenamiento del que esperas velocidad y predictibilidad ante cualquier avería.

¿Qué ocurre si falla uno de los dos nodos OSD?

Depende de los parámetros de réplicas fijados en el pool, y ninguno de los dos escenarios es satisfactorio. Con dos réplicas y min_size=2, perder una copia bloquea las operaciones de E/S porque el pool cae por debajo del mínimo exigido. Quedas protegido frente a escrituras sobre una réplica solitaria, pero el servicio carece de alta disponibilidad.

Con dos réplicas y min_size=1, el OSD superviviente continúa atendiendo peticiones de disco. El servicio se mantiene arriba, pero los datos afectados quedan a merced de una única réplica, justo el estado vulnerable que el almacenamiento distribuido busca evitar a toda costa.

Disponer de tres MON no altera ninguno de los dos casos. El quorum de monitores puede estar en perfecto estado mientras el pool se encuentra a un solo fallo de hardware de perder datos. La respuesta técnica más respaldada en el debate lo resumió con claridad: puede funcionar, pero no es una buena idea.

¿Cambiaría el diseño al añadir un tercer OSD?

Sí. Incorporar un tercer OSD en un tercer dominio de fallo modifica el modelo de tolerancia a fallos mucho más de lo que aportaría sumar otro MON.

Con tres hosts de almacenamiento, Ceph puede distribuir tres réplicas en tres servidores independientes y aplicar la política habitual 3/2. Si un equipo se apaga, quedan dos copias intactas. Eso se aproxima de verdad a lo que entendemos por alta disponibilidad en Ceph.

La dificultad en este planteamiento radicaba en que la tercera máquina era intencionadamente más modesta, y aquí es donde la simetría del hardware cobra peso. Ceph ofrece su mejor rendimiento cuando la capacidad y la velocidad de los OSD guardan equilibrio entre los hosts. Un nodo de almacenamiento sensiblemente más lento perjudica la recuperación, la colocación de objetos y la agilidad de todo el pool. Es viable construir un Ceph asimétrico, pero forzar a una máquina débil a integrarse en la capa de almacenamiento no siempre es mejor que elegir un modelo de almacenamiento más simple.

¿Es la replicación ZFS mejor opción para un homelab de tres nodos?

A menudo sí, sobre todo cuando solo dos nodos están realmente cualificados para actuar como servidores de almacenamiento.

Varios usuarios experimentados aconsejaron apartarse de Ceph en este caso y recurrir a ZFS local con replicación de almacenamiento en Proxmox. Esta fórmula merece más crédito del que habitualmente recibe, ya que la replicación ZFS encaja perfectamente en una arquitectura de alta disponibilidad de Proxmox. Proxmox puede replicar de forma asíncrona los discos de los invitados desde el almacenamiento ZFS local hacia otro nodo; si el equipo de origen cae, el mecanismo de HA puede reiniciar la máquina virtual a partir de la última copia replicada en el destino.

La contrapartida es el RPO. La replicación funciona por intervalos programados, por lo que una VM recuperada puede perder los cambios producidos tras la última sincronización satisfactoria. La programación por defecto de pvesr es de cada 15 minutos, y puedes ajustarla a intervalos más cortos si el hardware y la red lo toleran.

Ceph persigue mantener el almacenamiento compartido sincronizado en tiempo real. La replicación ZFS asume una pequeña ventana de pérdida potencial a cambio de una infraestructura infinitamente más sencilla. En un clúster doméstico donde ciertas VM están vinculadas a nodos concretos por hardware, esta suele ser la opción más inteligente.

Un participante apuntó que utiliza Ceph en el trabajo pero replicación ZFS en casa, ya que el consumo de recursos y la complejidad de Ceph eran difíciles de justificar en un homelab de tres nodos y seis OSD. Su planteamiento consistía en adecuar la arquitectura a la escala, una conclusión mucho más sensata que debatir en abstracto si ZFS es superior o inferior a Ceph.

¿Qué hay de LINSTOR para solo dos nodos de almacenamiento?

LINSTOR es una alternativa interesante, aunque sustituye una modalidad de complejidad de almacenamiento distribuido por otra diferente.

Algunos participantes sugirieron LINSTOR con DRBD, que permite replicar almacenamiento de bloques de forma síncrona entre un número reducido de nodos. Un usuario describió un entorno Proxmox de tres nodos donde solo dos albergaban almacenamiento replicado y confirmó que funcionaba bien. Esa estructura encaja con un escenario donde dos máquinas ejercen de nodos de almacenamiento potentes y la tercera asume cómputo o actúa como testigo de quorum.

LINSTOR impone su propia operativa técnica: conceptos de DRBD, controladores, satélites y consideraciones de soporte. Si tu meta es familiarizarte con el almacenamiento distribuido, puede resultar muy enriquecedor. Si lo que buscas es simplemente tolerar el reinicio imprevisto de un servidor, la replicación local con ZFS exige un esfuerzo conceptual mucho menor.

¿Qué conviene montar si el objetivo es aprender Ceph?

Despliega Ceph y llámalo por su nombre: un entorno de laboratorio. Montar un clúster de dos OSD deliberadamente para aprender cómo interactúan los MON, MGR, OSD, pools, CRUSH, RBD, los procesos de recuperación y las rutas de red es una gran práctica. Una instalación imperfecta enseña con frecuencia más que una guía impecable de producción. Solo asegúrate de no confundir una instalación que arranca con una arquitectura resistente, y pon a prueba los escenarios más difíciles:

1. Desconecta un OSD.
2. Observa qué ocurre con el tráfico de E/S.
3. Comprueba si el pool queda degradado, inactivo o prosigue con una única copia.
4. Satura deliberadamente la red de Ceph.
5. Vigila la latencia de Corosync al mismo tiempo.
6. Mueve una VM al nodo de cómputo más lento.
7. Mide la latencia de disco en el sistema invitado.
8. Reconecta el OSD averiado y analiza el tráfico de recuperación.
9. Simula la caída completa de un servidor.
10. Restaura una VM desde una copia de seguridad tras destruir deliberadamente los datos del laboratorio.

Una auditoría de salud de Proxmox puede ayudar a descubrir puntos débiles en el host y en el clúster, pero para Ceph la prueba más determinante sigue siendo provocar fallos bajo carga real.

Que un clúster Ceph de dos OSD arranque dice poco sobre el diseño

El atractivo de la propuesta original radica en que casi todos sus componentes tienen sentido por separado. Tres MON son adecuados. Un nodo sin OSD puede utilizar el pool de Ceph. Una red de clúster independiente puede gestionar la replicación de los OSD, dos OSD pueden alojar dos réplicas y Ceph es capaz de funcionar sobre 1GbE o 2.5GbE. Sin embargo, al ensamblar todas esas piezas válidas obtienes un sistema con una tolerancia a fallos extremadamente precaria.

Para un diseño Ceph real de tres nodos, busca contar con tres dominios de fallo de almacenamiento, mantén la política de réplicas habitual 3/2 salvo motivos técnicos justificados y dota a Ceph de ancho de banda suficiente para que las recuperaciones no pongan en peligro a Corosync. Si tu hardware aún no permite esa configuración, la replicación ZFS puede ser la arquitectura que mejor se adapte al clúster que tienes hoy.