Por qué un clúster de dos nodos es la peor elección: la cuestión de la mayoría

Compraste el segundo servidor y montaste un clúster. Te quedas tranquilo: ahora hay dos máquinas, y si una cae la otra sigue.

No sigue. Un clúster de dos nodos es más frágil que un nodo solo, y el día que lo aprendes suele ser un mal día.

Por qué

Las decisiones de un clúster se toman por mayoría. Si dos de tres nodos están en pie hay mayoría y el clúster sigue funcionando. Si cae uno de dos nodos, el único nodo restante no es mayoría, así que el clúster se bloquea a sí mismo: las máquinas siguen corriendo, pero la configuración no se puede cambiar, no se arranca ninguna máquina nueva y casi todo el trabajo de administración se detiene.

No es un defecto, es un diseño deliberado. La alternativa es mucho peor: cuando dos nodos dejan de verse, ambos dicen "yo estoy en pie, el otro cayó" y arrancan la misma máquina virtual en dos sitios. Se escribe en el mismo disco desde los dos lados y los datos se estropean sin vuelta atrás.

Así que el clúster te protege bloqueándote. Pero con dos nodos esa protección salta en la mitad de las averías.

El número correcto es tres

En un clúster de tres nodos, si cae uno quedan dos, la mayoría se mantiene y la vida sigue. Por eso el número tres aparece por todas partes en la documentación de clústeres.

La tercera máquina no tiene que ser potente. Solo emite un voto, no tiene que ejecutar trabajo. Una máquina pequeña, incluso un ordenador viejo, sirve.

Si de verdad no quieres una tercera máquina, se puede montar en su lugar un pequeño nodo testigo que existe solo para votar. No es un nodo completo y no puedes correr máquinas en él, pero completa la cuenta de la mayoría hasta tres. Si vas a quedarte en dos nodos, monta al menos ese.

Si te quedas en dos nodos, ten en cuenta

Cuando un nodo entra en mantenimiento, el nodo restante también queda ingobernable. Así que hasta una actualización planificada te deja bloqueado.

Se puede decir a mano "que un nodo solo también pueda decidir", pero eso reabre exactamente el riesgo de doble arranque descrito arriba. Se hace de forma temporal, consciente y breve; no es una solución permanente.

Montar un clúster no es hacer copias

Son las dos cosas que más se confunden. Un clúster es para la disponibilidad: para que el trabajo siga cuando cae una máquina. Una copia es para la recuperación: para volver atrás cuando los datos se corrompen o se borran por error.

Un clúster no te devuelve una máquina virtual que borraste sin querer. El borrado se propaga a todos los nodos al instante, porque un clúster existe precisamente para que vean lo mismo. Aun con clúster, seguirás necesitando copias.

Qué hace Atlas

Atlas trata el clúster no como un concepto sino como un estado: cuántos nodos hay, cuántos votan, si la mayoría se mantiene ahora mismo.

Donde más ayuda es en la actualización. Antes de actualizar un nodo, Atlas mira cuántas de las máquinas que corren en él pueden pasar a otro nodo y te propone un orden. La propuesta sigue siendo una propuesta: la orden de traslado no se ejecuta sola, el botón lo pulsas tú.

Un detalle importa especialmente aquí, y toca de lleno el tema de este artículo. La orden que pregunta el estado del clúster falla de la misma forma en dos situaciones distintas: ser de verdad una máquina aislada, y ser miembro de un clúster cuya capa de clúster se ha derrumbado. Si no se distinguen, el producto dice "no hay clúster, mayoría correcta" justo en el momento en que el clúster se ha derrumbado. Es decir, construye la frase más tranquilizadora en el instante más peligroso.

Atlas las distingue mirando si existe el archivo de configuración: ese archivo se escribe junto con la pertenencia y permanece en su sitio incluso cuando la capa de clúster se derrumba. La distinción vive en un solo lugar, porque antes estaba escrita por separado en tres sitios distintos y los tres tenían el mismo fallo.