ip_hash: o servidor ao qual é enviado um pedido é determinado a partir do endereço IP do cliente. Neste caso, os três primeiros octetos do endereço IPv4 ou todo o endereço IPv6 são utilizados para calcular o valor do hash.
Se um dos servidores tem de ser temporariamente removido, pode ser marcado com o parâmetro down afim de preservar a corrente de hashing de endereços IP do cliente. Os pedidos que estavam a ser processados ​​por este servidor são enviados automaticamente para o próximo servidor no grupo:
generic hash: o servidor ao qual é enviado um pedido é determinado a partir de uma chave definida pelo utilizador que pode ser um texto, variável, ou a sua combinação. Por exemplo, a chave pode ser um IP de origem e a porta, ou URI:
O parâmetro consistent é opcional e permite o balanceamento de carga consistente. As solicitações serão distribuídas uniformemente em todos os servidores upstream baseados no valor da chave hashed definido pelo usuário. Se um servidor upstream é adicionado ou removido de um grupo upstream, apenas poucas chaves vão ser remapeadas o que minimiza erros de cache em caso de balanceamento de servidores de cache e outras aplicações.
least_time (método Extra): para cada solicitação, o Nginx seleciona o servidor com a menor latência média e o menor número de conexões ativas, onde a menor latência média é calculada com base em qual dos seguintes parâmetros:
Nota: Ao configurar qualquer método diferente do round-robin, é importante declarar a diretiva correspondente (least_conn, ip_hash, hash, least_time) acima da lista de diretivas de servidor no bloco upstream.
O Ngnix Plus inclui recursos adicionais, como balanceamento de carga avançado e acesso a um amplo conjunto de métricas para monitoramento de desempenho com o nginx plus (pago). No entanto, as configurações abaixo são possíveis na versão free e open-source.
Por padrão, o Nginx distribui as solicitações entre os servidores do grupo de acordo com os seus pesos, utilizando o método round-robin. O parâmetro weight da diretiva server define o peso de um servidor que, por padrão, é 1:
No exemplo, backend1.exemplo.com tem peso 5; os outros dois servidores têm o peso padrão (1), mas o único com endereço IP 192.0.0.1 que está marcado como um servidor de backup, não recebe solicitações a menos que ambos os outros servidores estejam indisponíveis. Com esta configuração de pesos, em cada seis pedidos, cinco são enviados backend1.exemplo.com e um para backend2.exemplo.com.
Existe também uma função de start lento que impede que um servidor inicie sem levar em consideração o tráfego pesado da rede. Desta maneira, evitamos falhas relacionadas ao tráfego intenso da rede. Para tal, basta usar a diretiva slow_start:
Nota: se houver apenas um único grupo de servidores com os parâmetros max_fails, e fail_timeout, o parâmetro slow_start será ignorado pois, estes parâmetros.
O Nginx também suporta métodos de persistência. Os métodos são definidos com a diretiva sticky ou melhor, o método sticky cookie. Com este método, o Nginx adiciona um cookie de sessão para a primeira resposta do grupo upstream e identifica o servidor que enviou a mensagem de resposta:
No exemplo acima, o parâmetro srv_id define o nome do cookie que será definido ou inspecionado. O parâmetro expires limita o tempo em que o parâmetro irá manter o cookie. O parâmetro domain é opcional e define um domínio para o qual o cookie será definido. O parâmetro path define o caminho do cookie. Este é o método mais simples de persistência.
O método sticky route irá atribuir uma rota para o cliente quando ele receber o primeiro pedido. Todos os pedidos subsequentes serão comparados com o parâmetro route da diretiva server e identificar o servidor onde os pedidos serão filtrados. As informações rota são feitas a partir de qualquer cookie ou URI: