Conceito de balanceamento de carga

O balanceamento de carga é uma técnica fundamental para distribuir requisições de rede entre múltiplos servidores, evitando sobrecarga e garantindo alta disponibilidade. No Nginx, essa funcionalidade é implementada via proxy reverso, onde o servidor atua como intermediário, encaminhando o tráfego para um conjunto de servidores back-end definidos no módulo upstream.

Configuração básica do módulo upstream

Para definir um pool de servidores, utiliza-se a diretiva upstream dentro do bloco http. Cada servidor é listado com seu endereço IP e porta. Exemplo:

# Definição do grupo de servidores back-end
upstream backend_pool {
    server 10.0.0.1:8080;
    server 10.0.0.2:8081;
    server 10.0.0.3:8082;
}

Para redirecionar o tráfego para esse grupo, configura-se o proxy reverso na seção location:

location / {
    proxy_pass http://backend_pool;
}

Estratégias de balanceamento suportadas

O módulo upstream do Nginx suporta diversas estratégias para distribuir as requisições. As principais são:

1. Round-robin (padrão)

Nesta abordagem, as requisições são distribuídas sequencialmente entre os servidores. É a configuração implícita quando nenhuma outra estratégia é especificada. Parâmetros adicionais podem incluir max_fails e fail_timeout para tratar falhas.

upstream backend_pool {
    server 10.0.0.1:8080 max_fails=3 fail_timeout=30s;
    server 10.0.0.2:8081;
    server 10.0.0.3:8082 backup;
}

Neste exemplo, o servidor 10.0.0.3 é designado como backup, sendo utilizado apenas quando os demais estiverem indisponíveis.

2. Peso (weight)

Permite atribuir pesos diferentes aos servidores, direcionando mais tráfego para aqueles com maior capacidade. O valor padrão de peso é 1.

upstream backend_pool {
    server 10.0.0.1:8080 weight=4;
    server 10.0.0.2:8081 weight=2;
    server 10.0.0.3:8082;
}

Aqui, o servidor 10.0.0.1 receberá aproximadamente o dobro de requisições em comparação com 10.0.0.2.

3. ip_hash

As requisições são alocadas com base no hash do endereço IP do cliente. Isso garante que um cliente específico sempre seja direcionado para o mesmo servidor back-end, útil para manter sessões de usuário.

upstream backend_pool {
    ip_hash;
    server 10.0.0.1:8080;
    server 10.0.0.2:8081;
}

4. least_conn

Direciona a requisição para o servidor com o menor número de conexões ativas, otimizando o uso de recursos em cenários com tempos de resposta variáveis.

upstream backend_pool {
    least_conn;
    server 10.0.0.1:8080 weight=3;
    server 10.0.0.2:8081;
    server 10.0.0.3:8082 backup;
}

5. fair (terceiros)

Aloca requisições com base no tempo de resposta dos servidores, priorizando aqueles que respondem mais rapidamente. Requer a instalação de módulos adicionais.

upstream backend_pool {
    server 10.0.0.1:8080;
    server 10.0.0.2:8081;
    fair;
}

6. url_hash (terceiros)

Distribui requisições pelo hash da URL solicitada, garantindo que a mesma URL sempre seja tratada pelo mesmo servidor. Isso pode melhorar a taxa de acerto de cache.

upstream backend_pool {
    hash $request_uri;
    server 10.0.0.1:8080;
    server 10.0.0.2:8081;
}

Parâmetros comuns para servidores no upstream

Cada entrada de servidor pode incluir opções para controle de comportamento:

• down: marca o servidor como permanentemente indisponível.
• weight: define a prioridade de roteamento.
• max_fails: número máximo de falhas permitidas antes de considerar o servidor offline.
• fail_timeout: tempo durante o qual as falhas são contadas.
• backup: reserva o servidor para uso em caso de falha dos principais.

Exemplo de configuração completa

Um cenário prático com ip_hash e parâmetros de tolerância a falhas:

http {
    upstream app_servers {
        ip_hash;
        server 192.168.0.10:8080 max_fails=2 fail_timeout=15s;
        server 192.168.0.11:8081;
        server 192.168.0.12:8082 backup;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://app_servers;
        }
    }
}