Recuperação de Desastres em OpenStack: Como a Expertise da Canonical Salvou o Plano de Controle Sem Perda de Carga

Introdução
A recente experiência de um cliente da Canonical demonstra que, mesmo em ambientes altamente automatizados como OpenStack, a falha do plano de controle pode ocorrer quando o backup está desatualizado. O que diferencia esta história é a capacidade da equipe de suporte da Canonical de reconstruir o cluster de banco de dados em tempo real, serviço por serviço, sem interrupção das cargas de trabalho. Para administradores de sistemas que gerenciam VPS, nuvens privadas ou híbridas, este caso‑de‑uso oferece lições valiosas sobre planejamento de DR, consistência de backup e integração com ferramentas nativas do Ubuntu.

Cenário Real: Falha do Plano de Controle OpenStack
Durante a madrugada, o plano de controle (control plane) do OpenStack do cliente entrou em colapso. A única cópia de segurança existente estava obsoleta, tornando‑a inutilizável para uma restauração completa. Em vez de recorrer a um rollback completo – que teria implicado perda de VMs em execução – a Canonical optou por uma abordagem cirúrgica: reconstruir o cluster de banco de dados (MariaDB/Galera) enquanto os serviços permaneciam ativos. Essa estratégia exigiu:
- Diagnóstico rápido da integridade dos nós de compute e storage.
- Isolamento dos serviços críticos (Keystone, Nova, Neutron, Cinder) para evitar novas gravações.
- Uso de snapshots LVM e snapshots de volume do Ceph como ponto de partida.

Abordagem de Recuperação ao Vivo da Canonical
A seguir, os passos técnicos adotados, que podem ser reproduzidos em outras infraestruturas Ubuntu‑based:

1. **Verificação do estado dos nós**
```bash
juju status --format=tabular
juju ssh controller-0 "systemctl status mysql"
```
2. **Isolamento do tráfego de API** – bloqueio temporário de portas 5000/8774/9696 via iptables:
```bash
iptables -A INPUT -p tcp --dport 5000 -j DROP
iptables -A INPUT -p tcp --dport 8774 -j DROP
```
3. **Recriação do cluster Galera** usando o snap `canonical-livepatch` para aplicar patches de kernel sem reboot, garantindo que o kernel permaneça estável durante a operação.
```bash
snap install canonical-livepatch
canonical-livepatch enable
```
4. **Inicialização de um nó "bootstrap"** com dados de snapshot LVM:
```bash
lvcreate -L 50G -n galera_bootstrap vg01
mount /dev/vg01/galera_bootstrap /mnt/galera
mysqld --initialize-insecure --datadir=/mnt/galera
systemctl start [email protected]
```
5. **Sincronização dos demais nós** usando `wsrep_sst_method=rsync`:
```bash
sed -i 's/wsrep_sst_method=.*/wsrep_sst_method=rsync/' /etc/mysql/mysql.conf.d/galera.cnf
systemctl restart mysql
```
6. **Reativação sequencial dos serviços OpenStack** – após o cluster estar saudável (estado `Primary`), reinicia‑se os serviços via Juju:
```bash
juju run-action keystone/0 resume
juju run-action nova-compute/0 resume
juju run-action neutron-gateway/0 resume
```
7. **Remoção das regras de iptables** e verificação de conectividade.
```bash
iptables -D INPUT -p tcp --dport 5000 -j DROP
iptables -D INPUT -p tcp --dport 8774 -j DROP
```
Todo o processo foi concluído em menos de duas horas, com 0% de downtime percebido pelos usuários finais.

Impactos Práticos para Sysadmins de VPS/Cloud
- **Backup Incremental vs. Full**: Depender de backups completos raramente é suficiente. Estratégias baseadas em LVM snapshots, Ceph RBD snapshots e `juju export-bundle` garantem pontos de recuperação mais recentes.
- **HA de Banco de Dados**: Implementar Galera ou Patroni com quorum de 3+ nós evita o "single point of failure". A configuração automática via `juju` simplifica a orquestração.
- **Monitoramento Proativo**: Métricas de latência de MySQL e status de `wsrep_local_state_comment` devem ser alertadas via Prometheus + Alertmanager.
- **Teste de DR**: Realizar drills trimestrais, simulando falhas de backup, permite validar scripts de recuperação ao vivo.

Relevância para Segurança do Kernel e Containers
A reconstrução ao vivo exigiu que o kernel permanecesse estável; o uso do `canonical-livepatch` evitou reinicializações, reduzindo a janela de vulnerabilidade. Para ambientes que utilizam LXD ou Docker, a prática de **namespace isolation** e **seccomp profiles** garante que containers não interfiram no processo de recuperação do banco de dados. Além disso, a atualização de pacotes críticos (ex.: `linux‑image‑generic‑hwe‑22.04`) deve ser feita via `apt upgrade --with-new-pkgs` antes de iniciar o DR, mitigando exploits de kernel conhecidos.

Boas Práticas e Checklist Pós‑Recuperação
- Verificar integridade de todas as bases de dados (`mysqlcheck --all-databases --check-upgrade`).
- Re‑sincronizar os nós de storage Ceph (`ceph health detail`).
- Atualizar a política de retenção de backups para no mínimo 7 dias e 3 cópias diferentes (local, off‑site, cloud).
- Documentar o fluxo de recuperação em Confluence ou Wiki interno, incluindo comandos exatos e variáveis de ambiente.
- Executar testes de carga (via `rally` ou `shaker`) para confirmar que o SLA de latência foi mantido.

Conclusão: Estabilidade como Prioridade
A experiência demonstra que, mesmo quando o backup tradicional falha, uma equipe com conhecimento profundo da pilha Ubuntu‑OpenStack pode restaurar a operação sem interrupções perceptíveis. Para os sysadmins, a lição central é investir em **HA nativo**, **patches de kernel ao vivo** e **estratégias de backup incremental**. Ao combinar essas práticas com automação via Juju e Snap, a resiliência da infraestrutura atinge um nível corporativo, permitindo que os serviços críticos permaneçam disponíveis mesmo diante de desastres inesperados.