Balanceamento de carga com NGINX e NGINX Plus, Parte 1

Owen GarrettDiretor Sênior de Gestão de Produtos

O NGINX é um proxy de aceleração eficiente para uma ampla variedade de aplicações baseadas em HTTP. Seus recursos de cache, processamento de conexões HTTP e descarregamento aumentam significativamente o desempenho das aplicações, especialmente durante períodos de alta carga.

Editor – O NGINX Plus versão 5 e posteriores também podem balancear a carga de aplicações baseadas em TCP. O balanceamento de carga TCP foi significativamente ampliado na versão 6 com a adição de verificações de integridade, reconfiguração dinâmica, terminação SSL e muito mais. No NGINX Plus versão 7<.htmla> e posteriores, o balanceador de carga TCP oferece todos os mesmos recursos do balanceador de carga HTTP. O suporte ao balanceamento de carga UDP foi introduzido na versão 9.

Você configura o balanceamento de carga TCP e UDP no contexto stream em vez do contexto http. As diretivas e os parâmetros disponíveis apresentam algumas diferenças devido às diferenças inerentes entre HTTP e TCP/UDP. Para obter detalhes, consulte a documentação dos módulos Upstream de HTTP e TCP.

NGINX Plus amplia os recursos do NGINX adicionando outras funcionalidades de balanceamento de carga: verificações de integridade, persistência de sessão, monitoramento de atividades em tempo real, e configuração dinâmica de grupos de servidores com balanceamento de carga.

Esta publicação do blog orienta você na configuração do NGINX para balancear o tráfego entre um conjunto de servidores web. Ela destaca alguns dos recursos adicionais do NGINX Plus.

Para saber mais, você também pode consultar o Guia do administrador do NGINX Plus e o artigo que dá continuidade a este, Balanceamento de carga com NGINX e NGINX Plus, Parte 2.

Encaminhando tráfego por proxy com o NGINX

Começaremos encaminhando o tráfego por proxy para dois servidores web upstream. A configuração do NGINX a seguir é suficiente para encerrar todas as solicitações HTTP na porta 80 e encaminhá-las de forma alternada entre os servidores web do grupo upstream:

http {    server {
        listen 80;

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

    upstream backend {
        server web-server1:80;
        server web-server2:80;
    }
}

Com essa configuração simples, o NGINX encaminha cada solicitação recebida na porta 80 alternadamente para web-server1 e web-server2, estabelecendo uma nova conexão HTTP em cada caso.

Definindo o método de balanceamento de carga

Por padrão, o NGINX usa o método Round Robin para distribuir o tráfego uniformemente entre os servidores, levando em conta um “peso” opcional atribuído a cada servidor para indicar sua capacidade relativa.

O método Hash de IP distribui o tráfego com base em um hash do endereço IP de origem. As solicitações provenientes do mesmo endereço IP de cliente são sempre enviadas ao mesmo servidor upstream. Esse é um método rudimentar de persistência de sessão, recalculado sempre que um servidor falha ou se recupera, ou quando o grupo upstream é modificado; o NGINX Plus oferece soluções melhores quando a persistência de sessão é necessária.

O método Menor Número de Conexões encaminha cada solicitação para o servidor upstream com o menor número de conexões ativas. Esse método funciona bem ao processar uma combinação de solicitações rápidas e complexas.

Todos os métodos de balanceamento de carga podem ser ajustados usando um parâmetro opcional weight na diretiva server. Isso é útil quando os servidores têm diferentes capacidades de processamento. No exemplo a seguir, o NGINX direciona quatro vezes mais solicitações ao web-server2 do que ao web-server1:

upstream backend {    zone backend 64k;
    least_conn;

    server web-server1 weight=1;
    server web-server2 weight=4;
}

No NGINX, os pesos são gerenciados de forma independente por cada processo worker. O NGINX Plus usa um segmento de memória compartilhada para os dados do upstream (configurado com a diretiva zone), portanto, os pesos são compartilhados entre os workers e o tráfego é distribuído com mais precisão.

Detecção de falhas

Se ocorrer um erro ou tempo limite quando o NGINX tentar se conectar a um servidor, encaminhar uma solicitação a ele ou ler o cabeçalho da resposta, o NGINX tentará novamente a conexão com outro servidor. (Você pode incluir a diretiva proxy_next_upstream na configuração para definir outras condições para repetir a solicitação.) Além disso, o NGINX pode remover o servidor com falha do conjunto de servidores disponíveis e, ocasionalmente, enviar solicitações a ele para detectar quando se recuperar. Os parâmetros max_fails e fail_timeout da diretiva server controlam esse comportamento.

O NGINX Plus adiciona um conjunto de verificações de integridade fora de banda que realizam testes HTTP sofisticados em cada servidor upstream para determinar se ele está ativo, além de um mecanismo de inicialização lenta para reintroduzir gradualmente os servidores recuperados no grupo com balanceamento de carga:

server web-server1 slow_start=30s;

Uma ‘pegadinha’ comum – corrigindo o cabeçalho Host Header

É bastante comum que um servidor upstream use o cabeçalho Host da solicitação para determinar qual conteúdo deve fornecer. Se você receber erros 404 inesperados do servidor ou qualquer outro indício de que ele está fornecendo o conteúdo errado, essa é a primeira coisa a verificar. Em seguida, inclua a diretiva proxy_set_header na configuração para definir o valor apropriado para o cabeçalho:

location / {
    proxy_pass http://backend;

    # Rewrite the 'Host' header to the value in the client request
    # or primary server name
    proxy_set_header Host $host;

    # Alternatively, put the value in the config:
    #proxy_set_header Host www.example.com;
}

Balanceamento de carga avançado usando o NGINX Plus

Uma série de recursos avançados do NGINX Plus faz dele um balanceador de carga ideal para operar à frente de conjuntos de servidores upstream:

• Balanceamento de carga e persistência de sessão – Melhor balanceamento de carga entre processos de trabalho e métodos de persistência de sessão para identificar e respeitar as sessões da aplicação
• Verificação de integridade HTTP e inicialização lenta do servidor – “Transações sintéticas” assíncronas para verificar o funcionamento correto de cada servidor upstream e reintrodução gradual dos servidores por meio da “inicialização lenta” quando eles se recuperam
• Monitoramento de atividades em tempo real – Relatório imediato de atividades e desempenho
• Grupos de servidores upstream configurados dinamicamente – Ferramenta que facilita algumas tarefas comuns de gerenciamento de upstream, como a remoção segura e temporária de um servidor

Para obter detalhes sobre balanceamento de carga avançado e uso de proxy, consulte a continuação deste artigo, Balanceamento de carga com NGINX e NGINX Plus, Parte 2.

Para experimentar o NGINX Plus, inicie hoje mesmo sua avaliação gratuita de 30 dias ou entre em contato conosco para conversar sobre seus casos de uso de balanceamento de carga.

Sobre o autor

Owen GarrettDiretor Sênior de Gestão de Produtos

Mais publicações de Owen Garrett