Balanceamento de carga com NGINX e NGINX Plus, Parte 2

Em Balanceamento de carga com NGINX e NGINX Plus, Parte 1 , configuramos um proxy HTTP simples para balancear a carga do tráfego em vários servidores web. Neste artigo, veremos recursos adicionais, alguns deles disponíveis no NGINX Plus : otimização de desempenho com keepalives , verificações de integridade , persistência de sessão , redirecionamentos e reescrita de conteúdo .

Para obter detalhes sobre os recursos de balanceamento de carga no NGINX e no NGINX Plus, confira o Guia de administração do NGINX Plus .

Editor – O NGINX Plus Release 5 e posteriores também podem balancear a carga de aplicativos baseados em TCP. O balanceamento de carga TCP foi significativamente estendido 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 Release 7 e posteriores, o balanceador de carga TCP tem paridade de recursos completa com o balanceador de carga HTTP. O suporte para balanceamento de carga UDP foi introduzido na versão 9.

Você configura o balanceamento de carga TCP e UDP no contexto de fluxo em vez do contexto http . As diretivas e parâmetros disponíveis diferem um pouco devido a diferenças inerentes entre HTTP e TCP/UDP; para obter detalhes, consulte a documentação dos módulos HTTP e TCP/UDP Upstream.

Uma revisão rápida

Para revisar, esta é a configuração que construímos no artigo anterior:

server { listen 80;

location / {
proxy_pass http://backend;

# Reescreva o cabeçalho 'Host' para o valor na solicitação do cliente,
    # ou nome do servidor primário
    proxy_set_header Host $host;

# Como alternativa, coloque o valor na configuração:
# proxy_set_header Host www.example.com;
} 
}

upstream backend {
zone backend 64k; # Use a memória compartilhada do NGINX Plus
least_conn;

server webserver1 weight=1;
server webserver2 weight=4;
}

Neste artigo, veremos algumas maneiras simples de configurar o NGINX e o NGINX Plus que melhoram a eficácia do balanceamento de carga.

Keepalives HTTP

Habilitar keepalives HTTP entre o NGINX ou NGINX Plus e os servidores upstream melhora o desempenho (reduzindo a latência) e reduz a probabilidade de o NGINX ficar sem portas efêmeras.

O protocolo HTTP usa conexões TCP subjacentes para transmitir solicitações HTTP e receber respostas HTTP. As conexões HTTP keepalive permitem a reutilização dessas conexões TCP, evitando assim a sobrecarga de criar e destruir uma conexão para cada solicitação:

O NGINX é um proxy completo e gerencia conexões de clientes (conexões keepalive de front-end) e conexões com servidores (conexões keepalive de upstream) de forma independente:

O NGINX mantém um “cache” de conexões keepalive – um conjunto de conexões keepalive ociosas para os servidores upstream – e quando precisa encaminhar uma solicitação para um upstream, ele usa uma conexão keepalive já estabelecida do cache em vez de criar uma nova conexão TCP. Isso reduz a latência das transações entre o NGINX e os servidores upstream e reduz a taxa na qual portas efêmeras são usadas, para que o NGINX seja capaz de absorver e balancear a carga de grandes volumes de tráfego. Com um grande pico de tráfego, o cache pode ser esvaziado e, nesse caso, o NGINX estabelece novas conexões HTTP com os servidores upstream.

Com outras ferramentas de balanceamento de carga, essa técnica às vezes é chamada de multiplexação , pool de conexões , reutilização de conexões ou OneConnect .

Você configura o cache de conexão keepalive incluindo as diretivas proxy_http_version , proxy_set_header e keepalive na configuração:

servidor { ouvir 80; localização / { proxy_pass http://backend; proxy_http_version 1.1 ; proxy_set_header Conexão "" ; } } backend upstream { servidor webserver1; servidor webserver2; # manter até 20 conexões ociosas com o grupo de servidores upstream keepalive 20 ; }

Verificações de integridade

Habilitar verificações de integridade aumenta a confiabilidade do seu serviço de balanceamento de carga, reduz a probabilidade de usuários finais verem mensagens de erro e também pode facilitar operações comuns de manutenção.

O recurso de verificação de integridade do NGINX Plus pode ser usado para detectar falhas de servidores upstream. O NGINX Plus sonda cada servidor usando “transações sintéticas” e verifica a resposta em relação aos parâmetros que você configura na diretiva health_check (e, quando você inclui o parâmetro match , o bloco de configuração match associado):

server { listen 80; location / { proxy_pass http://backend; health_check interval=2s failures=1 passes=5 uri=/test.php match=statusok ; # As verificações de integridade herdam outras configurações de proxy proxy_set_header Host www.foo.com; } } match statusok { # Usado para /test.php status de verificação de integridade 200 ; header Content-Type = text/html ; body ~ "Server[0-9]+ is alive" ; }

A verificação de integridade herda alguns parâmetros do seu bloco de localização pai. Isso pode causar problemas se você usar variáveis de tempo de execução na sua configuração. Por exemplo, a configuração a seguir funciona para tráfego HTTP real porque extrai o valor do cabeçalho Host da solicitação do cliente. Provavelmente não funciona para as transações sintéticas que a verificação de integridade usa porque o cabeçalho do Host não está definido para elas, o que significa que nenhum cabeçalho do Host é usado na transação sintética.

location / { proxy_pass http://backend;

# Esta verificação de integridade pode não funcionar...
health_check interval=2s failures=1 passes=5 uri=/test.php match=statusok;

# Extraia o cabeçalho 'Host' da solicitação
proxy_set_header Host $host;
}

Uma boa solução é criar um bloco de localização fictício que defina estaticamente todos os parâmetros usados pela transação de verificação de integridade:

location /internal-health-check1 { internal; # Impedir que solicitações externas correspondam a este bloco de localização

proxy_pass http://backend;

health_check interval=2s fail=1 passes=5 uri=/test.php match=statusok;

# Definir explicitamente os parâmetros da solicitação; não usar variáveis de tempo de execução
proxy_set_header Host www.example.com;
}

Para mais informações, confira o Guia de administração do NGINX Plus .

persistência de sessão

Com a persistência de sessão, os aplicativos que não podem ser implantados em um cluster podem ter a carga balanceada e dimensionada de forma confiável. Os aplicativos que armazenam e replicam o estado da sessão operam com mais eficiência e o desempenho do usuário final melhora.

Certos aplicativos às vezes armazenam informações de estado nos servidores upstream, por exemplo, quando um usuário coloca um item em um carrinho de compras virtual ou edita uma imagem enviada. Nesses casos, talvez você queira direcionar todas as solicitações subsequentes desse usuário para o mesmo servidor.

A persistência de sessão especifica para onde uma solicitação deve ser roteada, enquanto o balanceamento de carga dá ao NGINX a liberdade de selecionar o servidor upstream ideal. Os dois processos podem coexistir usando o recurso de persistência de sessão do NGINX Plus:

   Se a solicitação corresponder a uma regra de persistência de sessão
então use o servidor upstream de destino
caso contrário, aplique o algoritmo de balanceamento de carga para selecionar o servidor upstream

Se a decisão de persistência da sessão falhar porque o servidor de destino não está disponível, o NGINX Plus toma uma decisão de balanceamento de carga.

O método de persistência de sessão mais simples é a abordagem do “ sticky cookie ”, onde o NGINX Plus insere um cookie na primeira resposta que identifica o servidor upstream sticky:

cookie pegajoso srv_id expira=1h domínio=.example.com caminho=/;

No método alternativo “ sticky route ”, o NGINX seleciona o servidor upstream com base em parâmetros de solicitação, como o cookie JSESSIONID:

upstream backend { server backend1.example.com route=a ; server backend2.example.com route=b ; # selecione a primeira variável não vazia; ela deve conter 'a' ou 'b' sticky route $route_cookie $route_uri ; }

Para mais informações, confira o Guia de administração do NGINX Plus .

Reescrevendo redirecionamentos HTTP

Reescreva os redirecionamentos HTTP se alguns redirecionamentos estiverem quebrados e, principalmente, se você for redirecionado do proxy para o servidor upstream real.

Quando você faz proxy para um servidor upstream, o servidor publica o aplicativo em um endereço local, mas você acessa o aplicativo por meio de um endereço diferente – o endereço do proxy. Esses endereços geralmente são resolvidos em nomes de domínio, e podem surgir problemas se o servidor e o proxy tiverem domínios diferentes.

Por exemplo, em um ambiente de teste, você pode endereçar seu proxy diretamente (por endereço IP) ou como localhost . No entanto, o servidor upstream pode escutar em um nome de domínio real (como www.nginx.com ). Quando o servidor upstream emite uma mensagem de redirecionamento (usando um cabeçalho de status e localização 3xx ou usando um cabeçalho de atualização ), a mensagem pode incluir o domínio real do servidor.

O NGINX tenta interceptar e corrigir as instâncias mais comuns desse problema. Se você precisar de controle total para forçar reescritas específicas, use a diretiva proxy_redirect da seguinte maneira:

proxy_redirect http://staging.mysite.com/ http://$host/;

Reescrevendo Respostas HTTP

Às vezes, você precisa reescrever o conteúdo em uma resposta HTTP. Talvez, como no exemplo acima, a resposta contenha links absolutos que se referem a um servidor diferente do proxy.

Você pode usar a diretiva sub_filter para definir a reescrita a ser aplicada:

sub_filter /blog/ /blog-staging/;
sub_filter_once off;

Um problema muito comum é o uso da compactação HTTP. Se o cliente sinalizar que pode aceitar dados compactados e o servidor compactar a resposta, o NGINX não poderá inspecionar e modificar a resposta. A medida mais simples é remover o cabeçalho Accept-Encoding da solicitação do cliente, definindo-o como uma string vazia ( "" ):

proxy_set_header Aceitar-Codificação "";

Um exemplo completo

Aqui está um modelo para uma configuração de balanceamento de carga que emprega todas as técnicas discutidas neste artigo. Os recursos avançados disponíveis no NGINX Plus são destacados em laranja.

[Editor – A configuração a seguir foi atualizada para usar a API NGINX Plus para monitoramento de atividades ao vivo e configuração dinâmica de grupos upstream, substituindo os módulos separados que foram usados originalmente.]

server { listen 80; location / { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Connection ""; proxy_set_header Accept-Encoding ""; proxy_redirect http://staging.example.com/ http://$host/; # Reescreva o cabeçalho do Host para o valor na solicitação do cliente proxy_set_header Host $host; # Substitua quaisquer referências inline para staging.example.com sub_filter http://staging.example.com/ /; sub_filter_once off; } location /internal-health-check1 { internal; # Impedir que solicitações externas correspondam a este bloco de localização proxy_pass http://backend; health_check interval=2s fail=1 passes=5 uri=/test.php match=statusok ; # Defina explicitamente os parâmetros da solicitação; não use variáveis de tempo de execução proxy_set_header Host www.example.com; } upstream backend { zone backend 64k ; # Use a memória compartilhada do NGINX Plus least_conn; keepalive 20; # Aplique persistência de sessão para este cookie fixo do grupo upstream srv_id expires=1h domain=.example.com path=/servlet ; server webserver1 weight=1; server webserver2 weight=4; } match statusok { # Usado para verificação de integridade /test.php status 200 ; header Content-Type = text/html ; body ~ "Server[0-9]+ is alive" ; } server { listen 8080; root /usr/share/nginx/html; location = /api { api write=on ; # Monitoramento de atividade ao vivo e # configuração dinâmica de grupos upstream allow 127.0.0.1; # permit access from localhost deny all; # deny access from everywhere else } }

Experimente você mesmo todos os excelentes recursos de balanceamento de carga do NGINX Plus – comece seu teste gratuito de 30 dias hoje mesmo ou entre em contato conosco para discutir seus casos de uso .