Monté un clúster pero las máquinas no se mueven: lo que falta es el almacenamiento

Montaste el clúster, los nodos se ven, en la interfaz aparecen todos uno al lado del otro. Luego intentas mover una máquina a otro nodo y no funciona.

Lo que falta no es el clúster, es el almacenamiento.

Lo que se mueve no es la máquina, es la memoria

Mover una máquina virtual en marcha significa copiar el estado de su memoria al otro nodo. Eso pasa por la red y es rápido.

Pero también hace falta el disco de la máquina, y el disco es muchas veces mayor que la memoria. Si el disco está solo en la unidad propia del primer nodo, el segundo no llega a él. La migración o no empieza nunca, o tiene que copiar también el disco, y entonces ya no tarda segundos sino minutos o incluso horas.

Así que la respuesta cabe en una frase: el disco tiene que verse desde ambos nodos.

Dos maneras de conseguirlo

Almacenamiento compartido. El disco está en un sitio común al que se conectan los dos nodos: un almacén de red, un servidor de almacenamiento o una capa de almacenamiento distribuida. Al migrar el disco no se copia en absoluto, porque ya está ahí. Es la vía más rápida y limpia.

Replicación. El disco se queda en local pero se copia al otro nodo a intervalos regulares. Al migrar solo se envía lo que ha cambiado desde la última copia, por eso es rápido. El precio es este: como la copia se toma según un horario, puedes perder los últimos minutos. En una migración planificada eso no es problema; en una avería repentina puede serlo.

La pregunta que decide cuál te conviene es esta: si un nodo muere de golpe, cuántos minutos de pérdida aceptas? Si la respuesta es "cero", necesitas almacenamiento compartido. Si la respuesta es "unos minutos vale", la replicación basta y es mucho más barata.

Los contenedores no se mueven como las máquinas virtuales

Aquí es donde más se sorprende quien monta su primer clúster. Una máquina virtual se puede mover en marcha. Un contenedor no: se apaga, se mueve y se vuelve a arrancar.

Así que para tus contenedores no existe la migración sin interrupción, ni siquiera con clúster. No es una carencia sino la naturaleza del contenedor: una máquina virtual lleva su propio núcleo, un contenedor usa el del servidor, y ese núcleo no puede viajar.

Consecuencia práctica: tenlo en cuenta al decidir qué trabajo va en un contenedor y cuál en una máquina virtual. Si un trabajo que no tolera interrupciones está en un contenedor, ese trabajo se parará las noches de mantenimiento.

Fija el orden de antemano

La noche en que actualices un nodo, las respuestas a estas preguntas ya deben estar listas: cuántas máquinas hay en este nodo, cuántas se pueden mover, cuántas hay que apagar y a qué nodo van las movibles.

Calcularlo esa misma noche es mala idea. Escríbelo una vez y déjalo a mano.

Qué hace Atlas

Antes de actualizar un nodo, Atlas lista las máquinas que corren en él y te propone un orden de traslado: qué máquina a qué nodo. La propuesta las reparte por turnos entre los nodos disponibles.

La distinción de los contenedores se hace aquí de forma explícita. Para las máquinas virtuales el método propuesto es el traslado en marcha; para los contenedores la cadena apagar, mover, arrancar. El producto no lo presenta como una opción, constata que un contenedor no se puede mover de otra manera.

También se marcan las máquinas dejadas a la gestión de alta disponibilidad, porque moverlas a mano y dejarlas a la decisión propia del gestor son cosas distintas.

Y la propuesta sigue siendo una propuesta: la orden de traslado no se ejecuta sola, el botón lo pulsas tú.

Un límite honesto: hoy Atlas da por movible toda máquina virtual en marcha y no comprueba si su disco se ve de verdad desde el otro nodo. Así que el producto no responde por ti a la pregunta del almacenamiento, tienes que responderla tú una vez. Lee la propuesta sabiéndolo.