NGINX Plus da F5: balanceamento de carga

Balanceamento de carga HTTP

Ao balancear a carga do tráfego HTTP, o NGINX Plus encerra cada conexão HTTP e processa cada solicitação individualmente. É possível remover a criptografia SSL/TLS, inspecionar e manipular a solicitação, enfileirar a solicitação usando limites de taxa e, em seguida, selecionar a política de balanceamento de carga.

Para melhorar o desempenho, o NGINX Plus pode aplicar automaticamente uma ampla gama de otimizações a uma transação HTTP, incluindo upgrades de protocolo HTTP, otimização de keepalive e transformações como compactação de conteúdo e cache de resposta.

O balanceamento de carga do tráfego HTTP é fácil com o NGINX Plus:

http {
    upstream my_upstream {
        server server1.example.com;
        server server2.example.com;
    }

    server {
        listen 80;
        location / {
            proxy_set_header Host $host;
            proxy_pass http://my_upstream;
        }
    }
}

Primeiro, especifique um servidor virtual usando a diretiva server e, em seguida, especifique a porta para listen para o tráfego ativo. Combine as URLs das solicitações do cliente usando um bloco de location, defina o cabeçalho Host com a diretiva proxy_set_header e inclua a diretiva proxy_pass para encaminhar a solicitação para um grupo upstream. (O bloco upstream define os servidores nos quais a carga do NGINX Plus equilibra o tráfego.)

Para mais informações, confira esta introdução ao balanceamento de carga com NGINX e NGINX Plus.

Balanceamento de carga TCP e UDP

O NGINX Plus também pode balancear a carga de aplicações TCP, como MySQL, e aplicações UDP, como DNS e RADIUS. Para aplicações TCP, o NGINX Plus encerra as conexões TCP e cria novas conexões com o back-end.

stream {
    upstream my_upstream {
        server server1.example.com:1234;
        server server2.example.com:2345;
    }

    server {
        listen 1123 [udp];
        proxy_pass my_upstream;
    }
}

A configuração é semelhante ao HTTP: especifique um servidor virtual com a diretiva server, listen para o tráfego em uma porta e proxy_pass para encaminhar a solicitação para um grupo upstream.

Para obter mais informações sobre balanceamento de carga TCP e UDP, consulte o Guia de administrador do NGINX Plus.

Métodos de balanceamento de carga

O NGINX Plus oferece suporte a vários métodos de balanceamento de carga de aplicações para balanceamento de carga HTTP, TCP e UDP. Todos os métodos levam em consideração o weight que pode ser atribuído opcionalmente a cada servidor upstream.

• Round Robin (padrão) — Distribui solicitações pelos servidores upstream em ordem.
• Least Connections — Encaminha solicitações para o servidor com o menor número de conexões ativas.
• Least Time — Encaminha solicitações para o servidor menos carregado, com base em um cálculo que combina tempo de resposta e número de conexões ativas. Exclusivo do NGINX Plus.
• Hash — Distribui solicitações com base em uma chave especificada, por exemplo, endereço IP do cliente ou URL de solicitação. O NGINX Plus pode, opcionalmente, aplicar um hash consistente para minimizar a redistribuição de cargas se o conjunto de servidores upstream for alterado.
• IP Hash (Somente HTTP) — Distribui solicitações com base nos três primeiros octetos do endereço IP do cliente.
• Random with Two Choices — Escolhe dois servidores aleatoriamente e encaminha a solicitação para aquele com o menor número de conexões ativas (método Least Connections). Com o NGINX Plus, o método Least Time também pode ser usado.

Limitação de conexão com o NGINX Plus

É possível limitar o número de conexões que o NGINX Plus estabelece com servidores HTTP ou TCP upstream ou o número de sessões com servidores UDP. Quando o número de conexões ou sessões com um servidor excede um limite definido, o NGINX Plus para de estabelecer novas conexões.

No trecho de configuração abaixo, o limite de conexão para o webserver1 é 250 e para o webserver2 é 150. A diretiva de queue especifica o número máximo de conexões em excesso que o NGINX Plus coloca na fila de escuta do sistema operacional, por até 30 segundos cada uma; solicitações adicionais em excesso são descartadas.

upstream backend {
    zone backends 64k;
    queue 750 timeout=30s;

    server webserver1 max_conns=250;
    server webserver2 max_conns=150;
}

Quando o número de conexões ativas em um servidor fica abaixo do limite, o NGINX Plus envia conexões da fila. Limitar as conexões ajuda a garantir um atendimento consistente e previsível às solicitações dos clientes, mesmo durante picos de tráfego.

Persistência de sessão

É possível configurar o NGINX Plus para identificar sessões de usuários e enviar todas as solicitações de uma sessão para o mesmo servidor upstream. Isso é vital quando os servidores de aplicações armazenam o estado localmente, pois ocorrem erros fatais quando uma solicitação de uma sessão de usuário em andamento é enviada para um servidor diferente. A persistência de sessão também pode melhorar o desempenho quando as aplicações compartilham informações em um cluster.

Além da persistência de sessão baseada em hash com suporte do NGINX Open Source (os métodos de balanceamento de carga Hash e IP Hash), o NGINX Plus oferece suporte à persistência de sessão baseada em cookies, incluindo cookie persistente. O NGINX Plus adiciona um cookie de sessão à primeira resposta do grupo upstream para um determinado cliente, identificando com segurança qual servidor gerou a resposta. As solicitações subsequentes do cliente incluem o cookie, que o NGINX Plus usa para encaminhar a solicitação para o mesmo servidor upstream:

upstream backend {
    server webserver1;
    server webserver2;

    sticky cookie srv_id expires=1h domain=.example.com path=/;
}

No exemplo acima, o NGINX Plus insere um cookie chamado srv_id na resposta inicial do cliente para identificar o servidor que processou a solicitação. Quando uma solicitação subsequente contém o cookie, o NGINX Plus o encaminha para o mesmo servidor.

O NGINX Plus também oferece suporte a métodos de aprendizagem fixa e persistência de rota fixa.

Nota: a persistência de sessão baseada em cookies é exclusiva do NGINX Plus.

Verificações de integridade ativas

Por padrão, o NGINX realiza verificações básicas nas respostas dos servidores upstream, repetindo solicitações com falha sempre que possível. O NGINX Plus adiciona verificações de integridade de aplicações fora da banda (também conhecidas como transações sintéticas) e um recurso de inicialização lenta para adicionar servidores novos e recuperados ao grupo com balanceamento de carga.

Esses recursos permitem que o NGINX Plus detecte e resolva uma variedade muito maior de problemas, melhorando significativamente a confiabilidade das aplicações HTTP e TCP/UDP.

upstream my_upstream {
	zone my_upstream 64k;
	server server1.example.com slow_start=30s;
}

server {
    # ...
    location /health {
        internal;
        health_check interval=5s uri=/test.php match=statusok;
        proxy_set_header Host www.example.com;
        proxy_pass http://my_upstream
    }
}

match statusok {
    # Used for /test.php health check
    status 200;
    header Content-Type = text/html;
    body ~ "Server[0-9]+ is alive";
}

No exemplo acima, o NGINX Plus envia uma solicitação para /test.php a cada cinco segundos. O bloco de match define as condições que a resposta deve atender para que o servidor upstream seja considerado íntegro: um código de status 200 OK e um corpo de resposta contendo o texto ServerN is alive.

Nota: as verificações de integridade ativas são exclusivas do NGINX Plus.

Descoberta de serviços usando DNS

Por padrão, os servidores NGINX Plus resolvem nomes DNS na inicialização, armazenando em cache os valores resolvidos de forma persistente. Ao utilizar um nome de domínio como example.com para identificar um grupo de servidores upstream com a diretiva server e o parâmetro resolve, o NGINX Plus resolve o nome de domínio de novo periodicamente. Se a lista associada de endereços IP for alterada, o NGINX Plus iniciará imediatamente o balanceamento de carga no grupo atualizado de servidores.

Para configurar o NGINX Plus para usar registros SRV de DNS, inclua a diretiva resolver junto com o parâmetro service=http na diretiva server, conforme mostrado:

resolver 127.0.0.11 valid=10s;

upstream service1 {
    zone service1 64k;
    server service1 service=http resolve;
}

No exemplo acima, o NGINX Plus consulta 127.0.0.11 (o servidor DNS do Docker integrado) a cada 10 segundos para resolver novamente o service1 de nome de domínio.

Nota: a descoberta de serviços usando DNS é exclusiva do NGINX Plus.

API do NGINX Plus

O NGINX Plus inclui uma API RESTful com um único endpoint de API. Use a API do NGINX Plus para atualizar configurações upstream e armazenamentos de valores-chave em tempo real, sem tempo de inatividade.

O trecho de configuração a seguir inclui a diretiva api para permitir o acesso de leitura e gravação ao endpoint /api.

upstream backend {
    zone backends 64k;
    server 10.10.10.2:220 max_conns=250;
    server 10.10.10.4:220 max_conns=150;
}

server {
    listen 80;
    server_name www.example.org;

    location /api {
        api write=on;
    }
}

Com a API habilitada como no exemplo acima, é possível adicionar um novo servidor a um grupo upstream existente com o seguinte comando curl. Ele usa o método POST e a codificação JSON para definir o endereço IP do servidor como 192.168.78.66, seu peso como 200 e o número máximo de conexões simultâneas como 150. (Para version, substitua o número da versão atual da API conforme especificado na documentação de referência.)

$ curl -iX POST -d '{"server":"192.168.78.66:80","weight":"200","max_conns":"150"}' http://localhost:80/api/version/http/upstreams/backend/servers/

Para exibir a configuração completa de todos os servidores de backend upstream no formato JSON, execute:

$ curl -s http://localhost:80/api/version/http/upstreams/backend/servers/ | python -m json.tool
	{
      "backup": false,
      "down": false,
      "fail_timeout": "10s",
      "id": 0,
      "max_conns": 250,
      "max_fails": 1,
      "route": "",
      "server": "10.10.10.2:220",
      "slow_start": "0s",
      "weight": 1
      },
      {
      "backup": false,
      "down": false,
      "fail_timeout": "10s",
      "id": 1,
      "max_conns": 150,
      "max_fails": 1,
      "route": "",
      "server": "10.10.10.4:220",
      "slow_start": "0s",
      "weight": 1
      },
      {
      "backup": false,
      "down": false,
      "fail_timeout": "10s",
      "id": 2,
      "max_conns": 200,
      "max_fails": 1,
      "route": "",
      "server": "192.168.78.66:80",
      "slow_start": "0s",
      "weight": 200
      }

Para modificar a configuração de um servidor upstream existente, identifique-o pelo respectivo ID interno, que aparece no campo id na saída acima. O comando a seguir usa o método PATCH para reconfigurar o servidor com ID 2, definindo o endereço IP e a porta de escuta como 192.168.78.55:80, o peso como 500 e o limite de conexão como 350.

$ curl -iX PATCH -d '{"server":"192.168.78.55:80","weight":"500","max_conns":"350"}' http://localhost:80/api/version/http/upstreams/backend/servers/2

Acesse a documentação completa do Swagger (especificação OpenAPI) da API do NGINX Plus em https://demo.nginx.com/swagger-ui/.

Nota: a API do NGINX Plus é exclusiva do NGINX Plus.