Balanceamento de carga no nginx: upstream, métodos e health checks
Balanceamento de carga no nginx
Load balancer no nginx: upstream, métodos, pesos e saúde | We.Inc
Configure o nginx como load balancer: o bloco upstream, round robin, least_conn, ip_hash e hash, pesos, max_fails e fail_timeout, servidores de backup e um gerador de config.
Para balancear carga com o nginx, liste seus servidores de aplicação em um bloco upstream e aponte o proxy_pass para o nome dele. As requisições se revezam em round robin, a menos que você adicione least_conn, ip_hash, hash ou random. Cada linha server pode ter weight, max_fails e fail_timeout para health checks passivos, além das flags backup ou down.
Métodos de balanceamento de carga do nginx
Diretiva
Como escolhe um servidor
Bom para
(nenhuma)
Round robin com pesos, o padrão
Servidores parecidos e requisições curtas
Menos conexões ativas, considerando os pesos
Requisições de duração muito diferente
Hash do endereço do cliente (três primeiros octetos do IPv4, o IPv6 inteiro)
Manter um visitante no mesmo servidor
hash key
Hash de qualquer valor, como $request_uri
Afinidade de cache; adicione consistent para limitar a redistribuição
Servidor aleatório, ou o melhor de dois com random two
Vários load balancers compartilhando um mesmo pool
Distribuir o tráfego entre várias cópias de uma aplicação é uma das tarefas mais antigas do nginx, e a configuração inteira cabe em uma dúzia de linhas. O gerador abaixo escreve o bloco upstream a partir de uma lista de servidores, avisa sobre combinações que o nginx rejeita e mostra a fatia de requisições de cada servidor quando há pesos. A referência depois dele cobre cada parâmetro de server com o seu padrão.
Adicione o endereço e a porta de cada servidor de aplicação no gerador, com um peso se algumas máquinas forem maiores que outras.
Escolha um método. Deixe em round robin, a menos que as requisições variem muito de duração ou os visitantes precisem ficar em um só servidor.
Copie o resultado para o contexto http, por exemplo um arquivo em conf.d, e rode nginx -t.
Recarregue com nginx -s reload, depois pare um servidor de aplicação e veja as requisições irem para os outros.
Um único servidor em um upstream ignora max_fails e fail_timeout, então os checks passivos só importam com dois ou mais.
Marque um servidor como down em vez de apagar a linha quando usar ip_hash. Assim o hash do endereço de todos os outros clientes continua apontando para onde apontava antes.
Servidores backup só recebem tráfego quando todos os principais estão indisponíveis, e não podem ser combinados com hash, ip_hash ou random.
Quais falhas contam para max_fails é decidido por proxy_next_upstream. Por padrão contam erros e timeouts; um HTTP 500 não conta, a menos que você o liste.
Adicione keepalive com proxy_http_version 1.1 e um header Connection vazio para reutilizar as conexões com os backends em vez de abrir uma por requisição.
Perguntas frequentes
O nginx open source tem health checks ativos?
Não. A diretiva health_check pertence ao NGINX Plus, que é comercial. O nginx open source depende de checks passivos: se uma requisição a um servidor falha max_fails vezes dentro de fail_timeout, o servidor é pulado por fail_timeout e depois testado de novo com tráfego real.
Quais são os padrões de max_fails e fail_timeout?
max_fails tem padrão 1 e fail_timeout, 10 segundos. Portanto, uma única tentativa com falha tira um servidor de circulação por dez segundos. Definir max_fails=0 desliga essa contagem para aquele servidor.
Como deixar sessões fixas (sticky) no nginx?
Use ip_hash para manter cada endereço de cliente em um servidor, ou hash com uma variável de cookie como $cookie_session para um controle mais fino. Diretivas sticky baseadas em cookie só existem na edição comercial.
O que faz o parâmetro weight?
Ele muda quantas requisições um servidor recebe em relação aos outros. Com pesos 3, 1 e 1, o primeiro servidor recebe cerca de três de cada cinco requisições em round robin. O peso padrão é 1.
O nginx consegue balancear conexões WebSocket?
Sim. Aponte o proxy_pass para o upstream e repasse os headers Upgrade e Connection. least_conn combina melhor com sockets de longa duração do que round robin, porque conta quantas conexões cada servidor já mantém.
Onde cada peça fica
O bloco upstream fica no contexto http, ao lado dos seus server blocks. Ele só dá nome a um pool; nada acontece até que um location diga proxy_pass http://name. O mesmo pool pode ser usado por muitos locations e muitos server blocks.
Health checks passivos, passo a passo
Quando uma requisição a um servidor falha de um jeito que o proxy_next_upstream considera, o nginx tenta de novo no próximo servidor e registra a falha. Quando um servidor chega a max_fails falhas dentro da janela de fail_timeout, o nginx para de escolhê-lo. Passado o fail_timeout, ele volta a enviar aos poucos requisições reais de clientes, e um sucesso o coloca de volta no rodízio.
Como os checks usam tráfego real, um visitante pode cair na primeira tentativa com falha. Timeouts curtos em proxy_connect_timeout mantêm esse atraso pequeno.
Parâmetros de server e seus padrões
Parâmetros de uma linha server dentro do upstream
Parâmetro
Padrão
Efeito
weight=n
Fatia relativa de requisições
max_fails=n
Tentativas com falha dentro de fail_timeout antes de o servidor ser pulado; 0 desativa
fail_timeout=time
Janela para contar falhas e por quanto tempo o servidor é pulado
max_conns=n
0 (sem limite)
Limite de conexões ativas simultâneas para este servidor
Usado só quando todos os servidores principais estão indisponíveis
Marca o servidor como permanentemente indisponível
Exemplos completos
Round robin com um reserva
Dois principais dividem a carga; o terceiro só responde se os dois estiverem fora.
least_conn com conexões reutilizadas
keepalive guarda conexões ociosas com os backends; as duas linhas de proxy fazem isso funcionar.
Afinidade de cache por URL
Cada URL continua caindo no mesmo servidor de cache; consistent mantém a maior parte dos mapeamentos quando um servidor é adicionado ou removido.
Nome do upstream
Método
Round robin (padrão)
Chave de hash
Conexões keepalive ociosas (0 para nenhuma)
Servidores
Endereço e porta
Peso
fail_timeout (s)
Fatia
Remover servidor {n}
Adicionar servidor
O nginx rejeita servidores backup com hash, ip_hash e random. Remova a flag backup ou mude o método.
Todos os servidores principais estão marcados como down, então nenhum pode receber tráfego.