Especialistas em OpenStack: Recuperação de Desastres com Suporte Canonical – Lições para Sysadmins Ubuntu

Introdução
O incidente descrito no caso "Surviving the uncharted: when dedicated OpenStack expertise is your best ally in disaster recovery" ilustra como a perda de um único ponto de backup pode comprometer toda a infraestrutura de nuvem. Um cliente viu o plano de controle do OpenStack cair durante a madrugada, e o backup disponível estava obsoleto. A Canonical, com sua expertise em OpenStack, conseguiu reconstruir o cluster de bancos de dados em produção, serviço por serviço, sem interrupções nos workloads. Este artigo analisa, passo a passo, os impactos práticos desse cenário para servidores de produção, segurança do kernel, containers LXD/Docker e, principalmente, para o trabalho diário de um Sysadmin Ubuntu.

O que aconteceu?
- O plano de controle (control plane) do OpenStack, composto por services como keystone, nova, neutron, cinder e o banco de dados Galera, ficou indisponível.
- O único backup existente estava desatualizado, impossibilitando uma restauração tradicional.
- A Canonical iniciou uma recuperação "live", reconstruindo o cluster Galera e re‑integrando cada serviço, mantendo as VMs e containers em execução.

Impacto prático para servidores de produção (VPS, Cloud)
1. **Dependência de backups consistentes** – Em ambientes de VPS e nuvem pública/privada, a perda de um backup pode significar downtime total. A prática recomendada passa a ser a implementação de backups incrementais e replicação assíncrona entre zonas de disponibilidade.
2. **Resiliência do banco de dados** – O uso de Galera Cluster oferece quorum e auto‑curing, mas requer monitoramento de SST (State Snapshot Transfer). Um nó desatualizado pode impedir a formação de quorum, como ocorreu no caso.
3. **Orquestração de serviços** – Cada micro‑serviço do OpenStack tem dependências de API e de fila (RabbitMQ). A falha de um componente pode cascatar, portanto, o isolamento de serviços via systemd e a definição de dependências claras são cruciais.

Segurança do Kernel e integridade de dados
- **Kernel Hardening**: A reconstrução ao vivo exige que o kernel esteja configurado com `CONFIG_X86_64` e `CONFIG_KASAN` habilitados para detectar corrupção de memória durante a migração de dados.
- **AppArmor/SELinux**: Garantir perfis atualizados para os processos do OpenStack impede que falhas de recuperação elevem privilégios inesperados.
- **fsync e barrier**: Ao reinicializar o Galera, use `fsync` explícito e `barrier=1` nas opções de montagem do ext4/xfs para assegurar que os writes sejam realmente persistidos antes de assumir o papel de nó primário.

Containers (Docker/LXD) e OpenStack
- OpenStack Compute (Nova) pode provisionar tanto VMs quanto containers LXC/LXD. A interoperabilidade requer que o daemon LXD esteja rodando com `security.nesting=true` e `security.privileged=true` quando usado como backend de compute.
- Em ambientes Docker, o driver `devicemapper` ou `overlay2` deve estar alinhado com o driver de armazenamento do Cinder (por exemplo, LVM) para evitar inconsistências de volume.
- Durante a recuperação, é recomendável pausar temporariamente o scheduler do Nova (`nova-manage service disable --reason "DR" compute`) para evitar novas criações enquanto o banco de dados está em estado de reconciliação.

Passo a passo da recuperação ao vivo
1. **Verificar o estado do cluster Galera**
   ```bash
   sudo galera_check_status --node
   sudo mysql -e "SHOW STATUS LIKE 'wsrep_%';"
   ```
2. **Isolar o nó falho**
   ```bash
   sudo systemctl stop mysql
   sudo pcs cluster node remove
   ```
3. **Reinicializar o nó com SST** (usando rsync ou xtrabackup)
   ```bash
   sudo galera_new_cluster   # no nó que será o primary
   sudo mysql -e "SET GLOBAL wsrep_cluster_address='gcomm://node1,node2,node3';"
   ```
4. **Reintegrar os demais nós**
   ```bash
   for n in node2 node3; do
       ssh $n "sudo systemctl start mysql"
   done
   ```
5. **Validar a consistência dos serviços OpenStack**
   ```bash
   openstack service list
   openstack compute service list
   openstack network agent list
   ```
6. **Reativar o scheduler**
   ```bash
   sudo nova-manage service enable compute
   ```
7. **Monitorar logs** – `journalctl -u mysql`, `journalctl -u nova-api`, `journalctl -u neutron-server`.

Boas práticas e recomendações
- **Backups rotativos**: Use `cinder backup-create` e `swift` com política de retenção mínima de 7 dias.
- **Teste de DR**: Execute drills trimestrais simulando perda total do control plane; automatize com Ansible playbooks que executem os passos acima.
- **Observabilidade**: Integre Prometheus + Grafana com exporters específicos para Galera (`mysqld_exporter`) e OpenStack (`openstack-exporter`).
- **Segurança de rede**: Separe o tráfego de replicação Galera em VLANs dedicadas e habilite IPsec entre nós.
- **Documentação viva**: Mantenha o run‑book no GitLab Wiki, versionado com as mudanças de versão do Ubuntu (ex.: 22.04 LTS → 24.04 LTS).

Conclusão – estabilidade e resiliência
O caso demonstra que, mesmo diante da ausência de um backup válido, a expertise especializada em OpenStack pode transformar uma catástrofe em uma operação controlada de recuperação. Para Sysadmins Ubuntu, a lição principal é reforçar a camada de dados (Galera, Cinder, Swift) com backups incrementais, monitoramento proativo e testes regulares de failover. Ao alinhar práticas de hardening do kernel, políticas de segurança de containers e automação de recuperação, a infraestrutura de nuvem ganha a robustez necessária para garantir disponibilidade contínua, mesmo nos cenários mais imprevisíveis.