Nuvem multinó com alta disponibilidade (strongctl)

Com mais de um controller no inventário, o strongctl monta o plano de controle em alta disponibilidade. Não precisa de nenhuma opção a mais: a variável ha (em group_vars/all.yml) fica verdadeira sozinha.

Exemplo: 3 controllers, 2 computes

strongctl init --vip 10.0.0.10 \
  --controller ctl1=10.0.0.11 --controller ctl2=10.0.0.12 --controller ctl3=10.0.0.13 \
  --compute cmp1=10.0.0.21 --network cmp1=10.0.0.21 \
  --compute cmp2=10.0.0.22 --storage cmp2=10.0.0.22
strongctl bootstrap && strongctl deploy && strongctl verify

O strongctl roda num dos controllers e acessa os nós por SSH como root (chave do root do controller em authorized_keys). O --vip é um IP livre na rede de gerenciamento: é o endereço público das APIs (controller_address).

O que roda em cada controller

Componente	Como fica em HA
VIP das APIs	Keepalived (VRRP em unicast). O VIP fica no controller de maior prioridade com HAProxy vivo e muda de nó em poucos segundos se o HAProxy ou o nó cair.
HAProxy	Nos 3 controllers, escutando no VIP (`ip_nonlocal_bind`). Termina o TLS e distribui as APIs entre os 3.
APIs (uWSGI)	Nos 3 controllers, escutando no endereço de gerenciamento de cada um.
MariaDB	Cluster Galera nos 3 controllers. Os serviços usam o VIP:3306, onde o HAProxy manda tudo para um nó só (os outros ficam de reserva), para evitar conflitos de escrita.
RabbitMQ	Cluster nos 3 controllers (cookie comum, `pause_minority`). Os serviços recebem os 3 nós no `transport_url` e usam filas quorum (`rabbit_quorum_queue`).
memcached	Nos 3 controllers. Os serviços recebem a lista dos 3.
OVN NB/SB	Cluster RAFT nos 3 controllers. O `ovn-northd` roda em todos: um ativo, os outros em espera. O Neutron e os chassis recebem a lista dos 3.
Keystone	Nos 3 controllers, com as mesmas chaves fernet e credential (copiadas do primeiro).
Horizon	Nos 3 controllers, com o mesmo `SECRET_KEY` (a sessão vale em qualquer um).
Glance	Nos 3 controllers, mas o HAProxy manda tudo para o primeiro e deixa os outros de reserva, porque o armazenamento `file` é local. Com armazenamento compartilhado (NFS, Ceph), use `glance_shared_store: true` no globals.yml para liberar os três.
Metadata e noVNC	Escutam em todos os controllers e atendem pelo VIP onde ele estiver.

Tarefas que mexem no banco (db sync, células do Nova, metadefs do Glance, bootstrap do Keystone) rodam uma vez só, no primeiro controller.

Conferência

strongctl verify também confere, em cada controller:

o tamanho do Galera e se o nó está Synced;
os nós do RabbitMQ;
os servidores do RAFT NB e SB;
o VIP em exatamente um controller.

Recuperação

Um controller cai e volta: o MariaDB entra de novo no Galera (IST/SST), o RabbitMQ volta ao cluster e o OVN volta ao RAFT sozinhos. Confira com strongctl verify.
Os três controllers caíram: o Galera não sobe sozinho. No nó com safe_to_bootstrap: 1 em /var/lib/mysql/grastate.dat (o último a parar), rode galera_new_cluster; nos outros, systemctl start mariadb.
Mudança de configuração do MariaDB: o deploy reinicia os controllers 2 e 3 um de cada vez. O primeiro precisa de um reinício manual (systemctl restart mariadb), também um de cada vez.

Teste de laboratório

tests/lxd/run-multinode.sh monta a nuvem acima em 5 containers LXD e:

implanta e confere a idempotência;
cria uma VM em cada compute e testa o IP flutuante;
desliga o dono do VIP e confere que a nuvem continua (token, listas, VM nova);
religa o controller e confere a volta ao cluster;
roda o Tempest smoke.

O resultado vai para out/multinode/.