Alta disponibilidade com vários VPS e balanceamento de carga

Um único VPS bem configurado atende muito bem a maioria dos projetos. Mas, quando cada minuto fora do ar custa caro — ou o tráfego não cabe mais em um servidor —, é hora de pensar em alta disponibilidade (HA) e escalabilidade horizontal.

O que é alta disponibilidade

É a capacidade do sistema continuar funcionando mesmo quando um componente falha. O princípio básico: eliminar pontos únicos de falha.

Em um único VPS, tudo é ponto único de falha: servidor web, aplicação, banco de dados.

Arquitetura típica

                 ┌──────────────┐
  Visitantes →   │ Balanceador  │
                 └──────┬───────┘
              ┌─────────┴─────────┐
        ┌─────▼─────┐       ┌─────▼─────┐
        │  App 1    │       │  App 2    │
        └─────┬─────┘       └─────┬─────┘
              └─────────┬─────────┘
                ┌───────▼────────┐
                │ Banco primário │ ──replicação──> Banco réplica
                └────────────────┘
        Redis (sessões/cache) · Armazenamento de objetos (uploads)

1. Aplicação sem estado (stateless)

Para ter várias instâncias da aplicação, elas não podem guardar estado local:

• Sessões no Redis ou no banco, não em arquivos locais;
• Uploads em armazenamento de objetos (S3 compatível) ou em armazenamento compartilhado, não no disco de um servidor só;
• Cache centralizado (Redis);
• Deploy idêntico em todos os servidores (CI/CD, Docker).

2. Balanceador de carga

Distribui as requisições entre os servidores da aplicação e remove automaticamente os que falham.

Nginx como balanceador

upstream app {
    least_conn;
    server 10.0.0.11:80 max_fails=3 fail_timeout=10s;
    server 10.0.0.12:80 max_fails=3 fail_timeout=10s;
}

server {
    listen 443 ssl;
    server_name loja.seudominio.com.br;

    location / {
        proxy_pass http://app;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

HAProxy é outra excelente opção, com health checks avançados.

E se o balanceador cair?

O balanceador também é um ponto de falha. Soluções:

• Dois balanceadores com IP flutuante (keepalived/VRRP) — depende de suporte do provedor;
• DNS com health check (failover de DNS);
• Balanceador gerenciado pelo provedor, se disponível.

3. Banco de dados

Normalmente o componente mais difícil de tornar altamente disponível.

• Replicação primário → réplica (MySQL/MariaDB ou PostgreSQL): a réplica pode assumir em caso de falha e servir leituras;
• Failover automático: ferramentas como Patroni (PostgreSQL) ou Galera Cluster/MaxScale/Orchestrator (MySQL/MariaDB);
• Comece com replicação + failover manual documentado — já reduz muito o RTO.

4. Rede privada

A comunicação entre servidores (app ↔ banco, app ↔ Redis) deve passar por rede privada ou VPN (WireGuard), nunca exposta à internet.

5. Monitoramento e testes

• Health checks em todas as camadas;
• Alertas para failover;
• Teste de falha: desligue um servidor de propósito e veja se o sistema continua no ar.

Escalar verticalmente antes?

Antes de partir para vários servidores, considere:

1. Otimizar (cache, consultas, índices);
2. Upgrade vertical (mais vCPU/RAM/NVMe) — é simples e muitas vezes suficiente;
3. Separar o banco em outro VPS;
4. Só então escalar horizontalmente.

HA adiciona complexidade — ela precisa valer o custo.

Conclusão

Com vários VPS, balanceamento e banco replicado, seu sistema resiste a falhas e cresce com o negócio. Monte sua arquitetura com VPS-NVME-BR da VittHost, com NVMe e servidores no Brasil — e consulte nosso suporte sobre rede privada entre servidores.Use o cupom SP-VITT20 e ganhe 20% de desconto na primeira fatura enquanto a promoção estiver ativa.