Montei um cluster mas as máquinas não migram: o que falta é o armazenamento

Você montou o cluster, os nós se enxergam, na interface aparecem todos lado a lado. Aí você tenta mover uma máquina para outro nó e não funciona.

O que falta não é o cluster, é o armazenamento.

O que migra não é a máquina, é a memória

Mover uma máquina virtual em funcionamento significa copiar o estado da memória dela para o outro nó. Isso passa pela rede e é rápido.

Mas o disco da máquina também é necessário, e o disco é muitas vezes maior que a memória. Se o disco está só na unidade do primeiro nó, o segundo nó não alcança. A migração ou nunca começa, ou tem que copiar o disco também, e aí já não são segundos, são minutos ou até horas.

Então a resposta cabe numa frase: o disco precisa ser visível a partir dos dois nós.

Dois jeitos de conseguir isso

Armazenamento compartilhado. O disco fica num lugar comum ao qual os dois nós se conectam: um armazenamento de rede, um servidor de armazenamento ou uma camada de armazenamento distribuída. Na hora da migração o disco não é copiado, porque já está lá. É o caminho mais rápido e mais limpo.

Replicação. O disco fica local mas é copiado para o outro nó em intervalos regulares. Na hora da migração só é enviado o que mudou desde a última cópia, por isso é rápido. O preço é este: como a cópia sai em horários, você pode perder os últimos minutos. Numa migração planejada isso não é problema; numa falha repentina pode ser.

A pergunta que decide qual serve para você é esta: se um nó morrer de repente, quantos minutos de perda você aceita? Se a resposta for "zero", você precisa de armazenamento compartilhado. Se for "alguns minutos tudo bem", replicação basta e sai muito mais barato.

Contêineres não migram como máquinas virtuais

É aqui que quem monta o primeiro cluster mais se surpreende. Uma máquina virtual pode ser movida em funcionamento. Um contêiner não: ele é desligado, movido e ligado de novo.

Então não existe migração sem interrupção para os seus contêineres, nem com cluster. Isso não é uma carência, é a natureza do contêiner: uma máquina virtual carrega o próprio núcleo, um contêiner usa o do servidor, e esse núcleo não viaja.

Consequência prática: leve isso em conta ao decidir que trabalho fica em contêiner e qual fica em máquina virtual. Se um trabalho que não tolera interrupção está num contêiner, esse trabalho vai parar nas noites de manutenção.

Defina a ordem antes

Na noite em que você atualizar um nó, as respostas destas perguntas já devem estar prontas: quantas máquinas há neste nó, quantas podem ser movidas, quantas precisam ser desligadas e para qual nó vão as que podem se mover.

Calcular isso na mesma noite é má ideia. Escreva uma vez e deixe de lado.

O que o Atlas faz

Antes de um nó ser atualizado, o Atlas lista as máquinas em funcionamento nele e sugere uma ordem de migração: qual máquina para qual nó. A sugestão distribui as máquinas em rodízio entre os nós disponíveis.

A distinção dos contêineres é feita aqui de forma explícita. Para máquinas virtuais o método sugerido é a migração em funcionamento; para contêineres a corrente desligar, mover, ligar. O produto não oferece isso como opção, ele constata que um contêiner não pode ser movido de outro jeito.

As máquinas deixadas à gestão de alta disponibilidade também são marcadas, porque movê-las na mão e deixá-las à decisão do gestor são coisas diferentes.

E a sugestão continua sendo sugestão: o comando de migração não roda sozinho, o botão você aperta.

Um limite honesto: hoje o Atlas trata toda máquina virtual em funcionamento como migrável e não verifica se o disco dela é realmente visível a partir do outro nó. Ou seja, o produto não responde a pergunta do armazenamento no seu lugar, você tem que respondê-la uma vez. Leia a sugestão sabendo disso.