O que é Alta Disponibilidade (HA) em cloud?

Alta Disponibilidade (HA) é a capacidade de um sistema permanecer operacional mesmo quando componentes individuais falham. Em cloud, isso é alcançado eliminando pontos únicos de falha por meio de redundância de hardware, software e rede — sem intervenção manual para recuperação.

Definição e diferença entre HA e Fault Tolerance

Imagine que um dos servidores do seu sistema de ERP trava às 2h da manhã. Com Alta Disponibilidade, em alguns segundos a carga é transferida automaticamente para outro servidor e o serviço volta — talvez o usuário nem perceba. Sem HA, alguém precisa ser acordado para reiniciar o servidor manualmente.

Alta Disponibilidade (HA) visa minimizar o tempo de inatividade não planejado. Quando um componente falha, o sistema detecta a falha e transfere a carga para um componente redundante em segundos a minutos. Há uma breve interrupção perceptível, mas o serviço se recupera automaticamente.

Fault Tolerance (FT) vai além: o sistema continua operando sem nenhuma interrupção mesmo durante falhas. Exige redundância ativa e síncrona em todos os componentes — CPU, memória, storage, rede. O custo é substancialmente maior.

Na prática, a maioria das arquiteturas empresariais implementa HA. Fault Tolerance plena é reservada para sistemas onde qualquer interrupção tem impacto financeiro ou de segurança imediato — pense em sistemas de trading de alta frequência ou controle de UTI hospitalar.

Componentes de HA em cloud

Clustering: Agrupa múltiplos hosts físicos (nós) em um pool lógico. Se um nó falha, as VMs que rodavam nele são reiniciadas automaticamente em outro nó disponível. O Apache CloudStack, base da Cloud Privada Adentro, implementa clustering de hypervisors KVM com detecção de falhas por heartbeat.

Load Balancing: Distribui requisições entre múltiplas instâncias de um serviço. Além de distribuir carga, o load balancer executa health checks contínuos e remove automaticamente instâncias com falha do pool — sem alterar o IP ou DNS exposto ao cliente.

Failover automático: Mecanismo que redireciona tráfego ou reinicia serviços quando uma falha é detectada. Pode operar em nível de VM (host failover), de aplicação (processo reiniciado), ou de rede (roteamento alternativo via BGP).

Health checks: Verificações periódicas de disponibilidade e integridade. Podem ser simples (TCP ping na porta) ou profundas (requisição HTTP com validação de resposta). A frequência e o threshold de falhas determinam a velocidade de detecção.

Replicação de dados: Storage com RAID, replicação entre datastores, ou volumes distribuídos garantem que dados não sejam perdidos quando um disco ou controlador falha.

Métricas de HA

Availability (%): A principal métrica. Calculada como (tempo total - downtime) / tempo total × 100.

MTBF (Mean Time Between Failures): Tempo médio entre falhas. Indica a confiabilidade de um componente ou sistema. Um MTBF alto significa menos falhas.

MTTR (Mean Time To Recovery): Tempo médio para recuperar o serviço após uma falha. HA reduz o MTTR automatizando a recuperação. A disponibilidade efetiva é diretamente proporcional ao MTBF e inversamente proporcional ao MTTR.

HA em cloud privada com CloudStack

No Apache CloudStack com hypervisor KVM, HA é configurado em dois níveis:

HA de host: O CloudStack monitora a saúde dos hosts via heartbeat. Se um host para de responder, o sistema aguarda o timeout configurado e, em seguida, força o desligamento do host via IPMI/ILO (fence) antes de reiniciar as VMs em outros hosts do cluster. O fence evita o cenário “split-brain”, onde uma VM poderia estar rodando em dois hosts simultaneamente.

HA de VM: VMs podem ser marcadas individualmente com a flag HA. Se a VM trava ou o processo da VM é encerrado inesperadamente, o CloudStack a reinicia automaticamente no mesmo host ou em outro do cluster.

Live Migration: Não é recuperação de falha — é movimentação preventiva. Permite mover uma VM em execução entre hosts físicos sem desligar, para manutenção ou balanceamento de carga. Exige storage compartilhado (NFS, Ceph, SAN) acessível por todos os hosts do cluster.

Diagrama: Arquitetura HA em Cloud Privada

┌─────────────────────────────────────────────────────┐
│                    Zona de Cloud                    │
│                                                     │
│  ┌──────────────┐    ┌──────────────┐               │
│  │   Host 01    │    │   Host 02    │               │
│  │  (KVM + CS)  │    │  (KVM + CS)  │               │
│  │  VM-A  VM-B  │    │  VM-C  VM-D  │               │
│  └──────┬───────┘    └───────┬──────┘               │
│         │                   │                       │
│         └────────┬──────────┘                       │
│                  │  Heartbeat / IPMI                 │
│         ┌────────▼──────────┐                       │
│         │  Storage Shared   │ ◄── Ceph / NFS / SAN  │
│         │  (datastores HA)  │                       │
│         └────────┬──────────┘                       │
│                  │                                   │
│  ┌───────────────▼──────────────────┐               │
│  │         Load Balancer            │               │
│  │   Health Check → Remove falhos   │               │
│  └───────────────┬──────────────────┘               │
│                  │                                   │
│           Internet / MPLS                           │
└─────────────────────────────────────────────────────┘

Falha em Host 01:
1. Heartbeat para → CloudStack detecta em N segundos
2. IPMI fence → Host 01 desligado (evita split-brain)
3. VM-A e VM-B reiniciadas no Host 02
4. Load balancer detecta VMs online via health check
5. Tráfego normalizado

Single Points of Failure mais comuns

Mesmo em arquiteturas declaradas como HA, estes componentes frequentemente permanecem como SPOF — e costumam aparecer só quando o problema já aconteceu:

• Switch de rede único entre servidores e storage
• Controladora de storage única em SAN/NAS
• Banco de dados sem replicação (HA da VM não resolve — o dado pode estar corrompido)
• Load balancer sem redundância (o componente que distribui carga também pode falhar)
• DNS mal configurado — TTL alto impede failover de IP
• Certificado TLS expirado — derruba HTTPS antes de qualquer falha de hardware
• Gerenciamento de cloud (CloudStack Management Server) em instância única

Como projetar uma arquitetura HA

1. Mapeie todos os componentes da pilha: rede, compute, storage, banco de dados, aplicação, DNS, certificados.
2. Identifique SPOFs — qualquer componente cuja falha interrompe o serviço.
3. Defina suas metas de SLA (99,9%, 99,99%?) e calcule o downtime tolerável por mês.
4. Elimine SPOFs por ordem de impacto, não de custo. O componente que mais impacta o serviço deve ser redundado primeiro.
5. Implemente health checks em todos os níveis — não assuma que um componente está saudável porque não gerou alerta.
6. Teste o failover regularmente. HA não testado é HA desconhecido. Simule falhas de host, de storage, de rede.
7. Documente o runbook de failover mesmo para processos automáticos — quando a automação falha, alguém precisa executar os passos manualmente.

Para saber como a infraestrutura HA da Adentro é implementada na prática, fale com um arquiteto de soluções.