Recuperação de Desastres em OpenStack com Expertise Canonical: Lições Cruciais para Sysadmins Ubuntu

Introdução

No universo de infraestrutura como serviço (IaaS), o OpenStack tornou‑se a espinha dorsal de muitas nuvens privadas baseadas em Ubuntu. Recentemente, um caso real de falha total do plano de controle – provocado por um backup obsoleto – mostrou como a intervenção especializada da Canonical pode restaurar um cluster de bancos de dados em produção sem interrupção de workloads. Este artigo analisa detalhadamente o incidente, descreve a metodologia de recuperação ao vivo e extrai lições práticas para administradores de sistemas que gerenciam VPS, clouds públicas/privadas, containers LXD/Docker e precisam garantir a resiliência do kernel e dos serviços críticos.

Cenário do incidente

Um cliente corporativo operava um OpenStack Stein (Ubuntu 22.04 LTS) com um único control plane composto por serviços keystone, nova, neutron, cinder e um cluster Galera de MariaDB. Durante a madrugada, o plano de controle ficou indisponível. A única cópia de segurança existente tinha mais de 30 dias, tornando‑a inútil para uma restauração completa. O risco era a perda total de identidade, catálogos de serviço e, sobretudo, das instâncias em execução, que dependiam de tokens de autenticação ainda válidos.

Abordagem de recuperação ao vivo

A equipe de suporte da Canonical adotou uma estratégia "service‑by‑service", reconstruindo o cluster Galera enquanto os nós de cálculo permaneciam operacionais. Os passos principais foram:

Código Selecionar Expandir

# 1. Isolar o cluster Galera problemático
sudo systemctl stop mariadb

# 2. Criar um novo nó de bootstrap usando o snapshot mais recente do volume lógico
lvcreate -L 200G -n galera_new vg_main
mkfs.ext4 /dev/vg_main/galera_new
mount /dev/vg_main/galera_new /mnt/galera_new

# 3. Inicializar o cluster com wsrep_new_cluster
sudo galera_new_cluster

# 4. Verificar a integridade do esquema com mysqlcheck
mysqlcheck --all-databases --auto-repair --check-upgrade

# 5. Reintegrar os nós restantes ao cluster
for NODE in node02 node03; do
  ssh $NODE "systemctl start mariadb"
done

# 6. Reiniciar os serviços OpenStack sequencialmente
for SERVICE in keystone nova-api neutron-server cinder-api; do
  sudo systemctl restart $SERVICE
  sleep 10
  journalctl -u $SERVICE -n 20 --no-pager
 done
A chave foi manter a camada de cálculo (nova‑compute) ativa, permitindo que as VMs continuassem rodando enquanto o plano de controle era restaurado. O uso do Galera em modo "rolling‑restart" evitou a necessidade de um downtime total.

Impacto prático para servidores de produção

* **VPS e Cloud privada** – A prática demonstra que, mesmo sem backups recentes, é possível recuperar o estado de serviço usando replicação síncrona (Galera) e snapshots de volume. Sysadmins devem configurar snapshots automáticos (LVM, ZFS ou Ceph) e testar a restauração periodicamente.
* **Segurança do Kernel** – A reinstalação do cluster não altera o kernel, mas reforça a necessidade de manter o kernel LTS atualizado (ex.: 5.15.0‑124‑generic) e habilitar o AppArmor para proteger os sockets de comunicação entre os nós Galera.
* **Containers (Docker/LXD)** – Em ambientes híbridos, onde serviços auxiliares (por exemplo, Horizon) rodam em containers, a estratégia de "service‑by‑service" pode ser aplicada com `lxc restart` ou `docker restart` sem impactar o banco de dados. A separação de namespaces garante que a falha do plano de controle não propague para workloads containerizados.

Implicações de segurança do kernel e containers

A reconstrução ao vivo expõe temporariamente portas de rede usadas pelo Galera (TCP 4567/4568). Recomenda‑se restringir o tráfego a IPs internos via firewall `ufw` ou `iptables`:

Código Selecionar Expandir

sudo ufw allow from 10.0.0.0/24 to any port 4567 comment 'Galera sync'
sudo ufw allow from 10.0.0.0/24 to any port 4568 comment 'Galera IST'

Além disso, habilite SELinux em modo "permissive" apenas durante a migração e volte ao "enforcing" logo após a validação. Para LXD, use perfis AppArmor customizados que limitam o acesso a `/var/lib/mysql`.

Boas práticas e comandos úteis

1. **Automatizar snapshots** – Use `cron` + `lvsnapshot` ou o recurso de snapshots do Ceph (`rbd snap create`).
2. **Monitorar a saúde do Galera** – `mysql -e "SHOW STATUS LIKE 'wsrep_%';"` fornece métricas de sincronização.
3. **Teste de failover** – Simule a queda do nó primário com `systemctl stop mariadb` e verifique o quorum.
4. **Documentar runbooks** – Mantenha um runbook em Markdown com passos exatos, incluindo variáveis de ambiente como `MYSQL_ROOT_PASSWORD`.
5. **Auditar logs** – Use `journalctl -u mariadb -f` para acompanhamento em tempo real durante a restauração.

Conclusão – Estabilidade garantida

O caso demonstra que, mesmo diante de backups desatualizados, a expertise dedicada da Canonical e a arquitetura resiliente do OpenStack sobre Ubuntu permitem uma recuperação quase transparente. Para sysadmins, a lição principal é investir em replicação síncrona, snapshots automáticos e runbooks detalhados. Ao combinar essas práticas com políticas rígidas de segurança de kernel e isolamento de containers, a disponibilidade de serviços críticos pode ser mantida em níveis próximos a 99,999 %. Em última análise, a estabilidade de uma nuvem privada depende tanto da tecnologia subjacente quanto da proficiência da equipe – e a Canonical provou ser um aliado indispensável quando o inesperado acontece.