Agora vamos subir o nível.

No primeiro post, falamos sobre a base: físico vs virtual

Post 1 — Alta Disponibilidade começa aqui: físico vs virtual

No segundo post, falamos HA (Alta disponibilidade) em ambiente virtualizados

Post 2 — HA na prática: cluster, failover e live migration

Agora vamos trazer isso para o mundo real…

Como as aplicações se comportam nesses dois cenários?

Cenário 1 — Ambiente físico

Aqui temos um modelo bastante comum:

• 2 servidores físicos
• Ambos com: HAProxy Keepalived Aplicação web instalada localmente

Se você não conhece esses componentes, tranquilo — vamos aprofundar isso em outro post ok.

Funcionamento

• Balanceamento de carga entre os dois nós
• Em caso de falha, um servidor assume toda a operação

Até aqui, parece ideal.

Mas é justamente aqui que começam os desafios.

Pontos críticos

• Necessidade de rede preparada (ex: suporte a spoofing de MAC)
• Dependência forte de hardware

E quando ocorre uma falha real?

Você entra em um cenário como:

• Substituição de hardware
• Reinstalação do sistema operacional
• Reconfiguração completa
• Reimplantação da aplicação

Resultado

• Alto tempo de recuperação (RTO elevado)
• Dependência de documentação atualizada
• Dependência de mão de obra especializada
• Risco de inconsistência entre servidores

Aqui, alta disponibilidade existe… Mas com um custo operacional alto.

Cenário 2 — Ambiente virtualizado

Agora mudamos o jogo.

Arquitetura típica:

Em cada host físico:

• 1 VM com: HAProxy + Keepalived
• 1 VM com: Aplicação Web

O que isso muda na prática?

Manutenção sem parada

• Reinício de hosts físicos sem indisponibilidade
• Uso de live migration

Elasticidade

• Criação de clones temporários
• Escala sob demanda

Escalabilidade real

• Inclusão de novos hosts no cluster
• Sem impacto nas aplicações

Centralização com NFS (ganho operacional)

Uma melhoria simples, mas extremamente eficiente:

Centralizar o código das aplicações em um servidor NFS.

Resultado

• Atualização em um único ponto
• Padronização do ambiente
• Redução de erro humano

E a alta disponibilidade do NFS?

Aqui entram dois caminhos:

Opção 1 — Replicação

• NFS replicado entre servidores
• Failover em caso de falha

Opção 2 — Storage distribuído (ex: Ceph)

• Elimina ponto único de falha
• Alta disponibilidade nativa
• Escalabilidade horizontal

Backup e recuperação no virtual

Aqui está um dos maiores diferenciais:

• Backup completo de VMs

Se algo falhar:

• Restore da VM inteira
• Sem reinstalação
• Sem retrabalho

O tempo de recuperação cai drasticamente.

Comparação direta

Físico

• Simples de entender
• Menor dependência de camada virtual
• ❌ Alto tempo de recuperação
• ❌ Difícil escalar
• ❌ Custo de escalabilidade alta
• ❌ Manutenção impacta operação

Virtualizado

• Alta flexibilidade
• Escalabilidade real
• Manutenção sem downtime
• Recuperação rápida (backup/replicação)
• ❌ Exige mais planejamento inicial
• ❌ Dependência da camada de virtualização

Conclusão

• Os dois modelos funcionam.
• Mas entregam níveis completamente diferentes de maturidade operacional.

No físico:

• Você mantém o ambiente funcionando

No virtual:

• Você controla como o ambiente reage.

E o seu ambiente hoje…

• Aguenta crescer sem parar?
• Aguenta manutenção sem impacto?
• Aguenta falha sem reconstrução?

Ou ainda está preso ao modelo tradicional?