BLOG | NGINX

Como evitar os 10 principais erros de configuração do NGINX

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Timo Stark Miniatura
Timo Stark
Publicado em 22 de fevereiro de 2022

Quando ajudamos usuários do NGINX que estão tendo problemas, frequentemente vemos os mesmos erros de configuração que vimos repetidamente nas configurações de outros usuários – às vezes até mesmo em configurações escritas por colegas engenheiros do NGINX! Neste blog, examinamos 10 dos erros mais comuns, explicando o que está errado e como consertar.

  1. Não há descritores de arquivo suficientes por trabalhador
  2. A diretiva error_log off
  3. Não habilitar conexões keepalive para servidores upstream
  4. Esquecendo como funciona a herança diretiva
  5. A diretiva proxy_buffering off
  6. Uso impróprio da diretiva if
  7. Verificações de saúde excessivas
  8. Acesso não seguro às métricas
  9. Usando ip_hash quando todo o tráfego vem do mesmo bloco CIDR /24
  10. Não aproveitar os grupos upstream

Erro 1: Descritores de arquivo insuficientes por trabalhador

A diretiva worker_connections define o número máximo de conexões simultâneas que um processo de trabalho NGINX pode ter abertas (o padrão é 512). Todos os tipos de conexões (por exemplo, conexões com servidores proxy) são contabilizados no máximo, não apenas as conexões de clientes. Mas é importante ter em mente que, em última análise, há outro limite no número de conexões simultâneas por trabalhador: o limite do sistema operacional no número máximo de descritores de arquivo (FDs) alocados para cada processo. Em distribuições UNIX modernas, o limite padrão é 1024.

Para todas as implantações do NGINX, exceto as menores, um limite de 512 conexões por trabalhador provavelmente é muito pequeno. De fato, o arquivo nginx.conf padrão que distribuímos com os binários NGINX Open Source e NGINX Plus o aumenta para 1024.

O erro comum de configuração é não aumentar o limite de FDs para pelo menos o dobro do valor de worker_connections . A solução é definir esse valor com a diretiva worker_rlimit_nofile no contexto de configuração principal.

Eis por que mais FDs são necessários: cada conexão de um processo de trabalho NGINX para um cliente ou servidor upstream consome um FD. Quando o NGINX atua como um servidor web, ele usa um FD para a conexão do cliente e um FD por arquivo servido, para um mínimo de dois FDs por cliente (mas a maioria das páginas web é construída a partir de muitos arquivos). Quando atua como um servidor proxy, o NGINX usa um FD para a conexão com o cliente e o servidor upstream, e potencialmente um terceiro FD para o arquivo usado para armazenar temporariamente a resposta do servidor. Como um servidor de cache, o NGINX se comporta como um servidor web para respostas armazenadas em cache e como um servidor proxy se o cache estiver vazio ou expirado.

O NGINX também usa um FD por arquivo de log e alguns FDs para se comunicar com o processo mestre, mas geralmente esses números são pequenos comparados ao número de FDs usados para conexões e arquivos.

O UNIX oferece várias maneiras de definir o número de FDs por processo:

  • O comando ulimit se você iniciar o NGINX a partir de um shell
  • As variáveis de manifesto do script init ou do serviço systemd se você iniciar o NGINX como um serviço
  • O arquivo /etc/security/limits.conf

No entanto, o método a ser usado depende de como você inicia o NGINX, enquanto worker_rlimit_nofile funciona independentemente de como você inicia o NGINX.

Há também um limite em todo o sistema para o número de FDs, que você pode definir com o comando sysctl fs.file-max do sistema operacional. Geralmente é grande o suficiente, mas vale a pena verificar se o número máximo de descritores de arquivo que todos os processos de trabalho do NGINX podem usar ( worker_rlimit_nofile * worker_processes ) é significativamente menor que fs.file‑max . Se o NGINX de alguma forma usar todos os FDs disponíveis (por exemplo, durante um ataque DoS), será impossível até mesmo efetuar login na máquina para corrigir o problema.

Erro 2: A diretiva error_log off

O erro comum é pensar que a diretiva error_log off desabilita o registro. Na verdade, diferentemente da diretiva access_log , error_log não aceita um parâmetro off . Se você incluir a diretiva error_log off na configuração, o NGINX criará um arquivo de log de erros chamado off no diretório padrão para arquivos de configuração do NGINX (geralmente /etc/nginx ).

Não recomendamos desabilitar o log de erros, porque ele é uma fonte vital de informações ao depurar quaisquer problemas com o NGINX. No entanto, se o armazenamento for tão limitado que seja possível registrar dados suficientes para esgotar o espaço em disco disponível, pode fazer sentido desabilitar o log de erros. Inclua esta diretiva no contexto de configuração principal:

error_log /dev/null emerge;

Observe que esta diretiva não se aplica até que o NGINX leia e valide a configuração. Portanto, cada vez que o NGINX é inicializado ou a configuração é recarregada, ele pode registrar no local de log de erros padrão (geralmente /var/log/nginx/error.log ) até que a configuração seja validada. Para alterar o diretório de log, inclua o parâmetro -e < error_log_location > no comando nginx .

Erro 3: Não habilitar conexões Keepalive para servidores upstream

Por padrão, o NGINX abre uma nova conexão com um servidor upstream (backend) para cada nova solicitação recebida. Isso é seguro, mas ineficiente, porque o NGINX e o servidor precisam trocar três pacotes para estabelecer uma conexão e três ou quatro para encerrá-la.

Em altos volumes de tráfego, abrir uma nova conexão para cada solicitação pode esgotar os recursos do sistema e impossibilitar a abertura de conexões. Eis o porquê: para cada conexão , a tupla quádrupla de endereço de origem, porta de origem, endereço de destino e porta de destino deve ser única. Para conexões do NGINX a um servidor upstream, três dos elementos (o primeiro, o terceiro e o quarto) são fixos, deixando apenas a porta de origem como variável. Quando uma conexão é fechada, o soquete Linux fica no estado TIME-WAIT por dois minutos, o que em altos volumes de tráfego aumenta a possibilidade de esgotar o conjunto de portas de origem disponíveis. Se isso acontecer, o NGINX não poderá abrir novas conexões com servidores upstream.

A correção é habilitar conexões keepalive entre o NGINX e os servidores upstream – em vez de serem fechadas quando uma solicitação é concluída, a conexão permanece aberta para ser usada em solicitações adicionais. Isso reduz a possibilidade de ficar sem portas de origem e melhora o desempenho .

Para habilitar conexões keepalive:

  • Inclua a diretiva keepalive em cada bloco upstream{} para definir o número de conexões keepalive ociosas com servidores upstream preservadas no cache de cada processo de trabalho.

    Observe que a diretiva keepalive não limita o número total de conexões com servidores upstream que um processo de trabalho NGINX pode abrir – esse é um equívoco comum. Portanto, o parâmetro para keepalive não precisa ser tão grande quanto você imagina.

    Recomendamos definir o parâmetro para o dobro do número de servidores listados no bloco upstream{} . Isso é grande o suficiente para que o NGINX mantenha conexões keepalive com todos os servidores, mas pequeno o suficiente para que os servidores upstream também possam processar novas conexões de entrada.

    Observe também que quando você especifica um algoritmo de balanceamento de carga no bloco upstream{} – com a diretiva hash , ip_hash , least_conn , least_time ou random – a diretiva deve aparecer acima da diretiva keepalive . Esta é uma das raras exceções à regra geral de que a ordem das diretivas na configuração do NGINX não importa.

  • No bloco location{} que encaminha solicitações para um grupo upstream, inclua as seguintes diretivas junto com a diretiva proxy_pass :

    proxy_http_version 1.1;
proxy_set_header "Conexão" "";

    Por padrão, o NGINX usa HTTP/1.0 para conexões com servidores upstream e, consequentemente, adiciona o cabeçalho Connection: close às solicitações que ele encaminha aos servidores. O resultado é que cada conexão é fechada quando a solicitação é concluída, apesar da presença da diretiva keepalive no bloco upstream{} .

    A diretiva proxy_http_version informa ao NGINX para usar HTTP/1.1, e a diretiva proxy_set_header remove o valor close do cabeçalho Connection .

Erro 4: Esquecendo como funciona a herança diretiva

As diretivas NGINX são herdadas de baixo para cima, ou “de fora para dentro”: um contexto filho – um aninhado dentro de outro contexto (seu pai ) – herda as configurações das diretivas incluídas no nível pai. Por exemplo, todos os blocos server{} e location{} no contexto http{} herdam o valor das diretivas incluídas no nível http , e uma diretiva em um bloco server{} é herdada por todos os blocos filho location{} nele. Entretanto, quando a mesma diretiva é incluída em um contexto pai e em seu contexto filho, os valores não são somados – em vez disso, o valor no contexto filho substitui o valor pai.

O erro é esquecer esta “regra de substituição” para diretivas de array , que podem ser incluídas não apenas em múltiplos contextos, mas também várias vezes dentro de um determinado contexto. Exemplos incluem proxy_set_header e add_header – ter “add” no nome do segundo torna particularmente fácil esquecer a regra de substituição.

Podemos ilustrar como a herança funciona com este exemplo para add_header :

http { 
add_header X-HTTP-LEVEL-HEADER 1;
add_header X-ANOTHER-HTTP-LEVEL-HEADER 1;

server {
listen 8080;
location / {
return 200 "OK";
} 
}

server {
listen 8081;
add_header X-SERVER-LEVEL-HEADER 1;

location / {
return 200 "OK";
}

location /test {
add_header X-LOCATION-LEVEL-HEADER 1;
return 200 "OK";
}

location /correct {
add_header X-HTTP-LEVEL-HEADER 1;
add_header X-ANOTHER-HTTP-LEVEL-HEADER 1;

add_header X-SERVER-LEVEL-HEADER 1;
add_header X-LOCALIZAÇÃO-NÍVEL-CABEÇALHO 1;
retornar 200 "OK";
} 
}
}

Para o servidor escutando na porta 8080, não há diretivas add_header nos blocos server{} ou location{} . Portanto, a herança é direta e vemos os dois cabeçalhos definidos no contexto http{} :

% curl -i localhost:8080 HTTP/1.1 200 OK Servidor: nginx/1.21.5 Data: Seg, 21 Fev 2022 10:12:15 GMT Tipo de conteúdo: text/plain Comprimento do conteúdo: 2 Conexão: keep-alive X-HTTP-LEVEL-HEADER: 1 X-OUTRO-NÍVEL-HTTP-CABEÇALHO: 1 OK

Para o servidor escutando na porta 8081, há uma diretiva add_header no bloco server{} , mas não em seu local / bloco filho. O cabeçalho definido no bloco server{} substitui os dois cabeçalhos definidos no contexto http{} :

% curl -i localhost:8081 HTTP/1.1 200 OK Servidor: nginx/1.21.5 Data: Seg, 21 Fev 2022 10:12:20 GMT Tipo de conteúdo: text/plain Comprimento do conteúdo: 2 Conexão: keep-alive X-SERVER-LEVEL-HEADER: 1 OK

No bloco /test do local filho, há uma diretiva add_header que substitui o cabeçalho do bloco server{} pai e os dois cabeçalhos do contexto http{} :

% curl -i localhost:8081/test HTTP/1.1 200 OK Servidor: nginx/1.21.5 Data: Seg, 21 Fev 2022 10:12:25 GMT Tipo de conteúdo: text/plain Comprimento do conteúdo: 2 Conexão: keep-alive X-LOCATION-LEVEL-HEADER: 1 OK

Se quisermos que um bloco location{} preserve os cabeçalhos definidos em seus contextos pais, juntamente com quaisquer cabeçalhos definidos localmente, precisamos redefinir os cabeçalhos pais dentro do bloco location{} . Foi o que fizemos no bloco location /correct :

% curl -i localhost:8081/correct HTTP/1.1 200 OK Servidor: nginx/1.21.5 Data: Seg, 21 Fev 2022 10:12:30 GMT Tipo de conteúdo: text/plain Comprimento do conteúdo: 2 Conexão: keep-alive X-HTTP-LEVEL-HEADER: 1 X-OUTRO-CABEÇALHO-DE-NÍVEL-HTTP: 1 CABEÇALHO-DE-NÍVEL-DO-SERVIDOR-X: 1 X-LOCALIZAÇÃO-NÍVEL-CABEÇALHO: 1 OK

Erro 5: A diretiva proxy_buffering off

O buffer de proxy é habilitado por padrão no NGINX (a diretiva proxy_buffering é definida como on ). O buffer de proxy significa que o NGINX armazena a resposta de um servidor em buffers internos conforme ela chega e não começa a enviar dados ao cliente até que toda a resposta seja armazenada em buffer. O buffer ajuda a otimizar o desempenho com clientes lentos – como o NGINX armazena a resposta em buffer pelo tempo que o cliente leva para recuperá-la, o servidor proxy pode retornar sua resposta o mais rápido possível e voltar a ficar disponível para atender outras solicitações.

Quando o buffer de proxy está desabilitado, o NGINX armazena em buffer apenas a primeira parte da resposta de um servidor antes de começar a enviá-la ao cliente, em um buffer que, por padrão, tem o tamanho de uma página de memória (4 KB ou 8 KB, dependendo do sistema operacional). Geralmente, há espaço suficiente apenas para o cabeçalho de resposta. O NGINX então envia a resposta ao cliente de forma síncrona à medida que a recebe, forçando o servidor a ficar ocioso enquanto aguarda até que o NGINX possa aceitar o próximo segmento de resposta.

Então ficamos surpresos com a frequência com que vemos proxy_buffering desativado nas configurações. Talvez a intenção seja reduzir a latência experimentada pelos clientes, mas o efeito é insignificante, enquanto os efeitos colaterais são numerosos: com o buffer de proxy desabilitado, a limitação de taxa e o armazenamento em cache não funcionam, mesmo se configurados, o desempenho é prejudicado e assim por diante.

Há apenas um pequeno número de casos de uso em que desabilitar o buffer de proxy pode fazer sentido (como pesquisas longas), então desencorajamos fortemente a alteração do padrão. Para obter mais informações, consulte o Guia de administração do NGINX Plus .

Erro 6: Uso impróprio da diretiva if

A diretiva if é complicada de usar, especialmente em blocos location{} . Muitas vezes, ele não faz o que você espera e pode até causar falhas de segmentação. Na verdade, é tão complicado que há um artigo intitulado If is Evil no NGINX Wiki, e nós o direcionamos para lá para uma discussão detalhada dos problemas e como evitá-los.

Em geral, as únicas diretivas que você sempre pode usar com segurança dentro de um bloco if{} são return e rewrite . O exemplo a seguir usa if para detectar solicitações que incluem o cabeçalho X‑Test (mas pode ser qualquer condição que você queira testar). NGINX retorna o430 ( Campos de cabeçalho de solicitação muito grandes) , intercepta-o no local nomeado @error_430 e envia a solicitação por proxy para o grupo upstream chamado b .

localização / { 
página_de_erro 430 = @error_430;
if ($http_x_test) {
return 430; 
}

senha_proxy http://a;
}

localização @error_430 {
senha_proxy b;
}

Para este e muitos outros usos de if , muitas vezes é possível evitar a diretiva completamente. No exemplo a seguir, quando a solicitação inclui o cabeçalho X‑Test , o bloco map{} define a variável $upstream_name como b e a solicitação é enviada por proxy para o grupo upstream com esse nome.

mapa $http_x_test $upstream_name { 
padrão "b";
"" "a";
}

# ...

localização / {
proxy_pass http://$upstream_name;
}

Erro 7: Verificações de saúde excessivas

É bastante comum configurar vários servidores virtuais para fazer proxy de solicitações para o mesmo grupo upstream (em outras palavras, incluir a diretiva proxy_pass idêntica em vários blocos server{} ). O erro nessa situação é incluir uma diretiva health_check em cada bloco server{} . Isso apenas cria mais carga nos servidores upstream sem gerar nenhuma informação adicional.

Correndo o risco de ser óbvio, a solução é definir apenas uma verificação de integridade por bloco upstream{} . Aqui definimos a verificação de integridade para o grupo upstream chamado b em um local nomeado especial, completo com tempos limite e configurações de cabeçalho apropriados.

localização / { 
proxy_set_header Host $host;
proxy_set_header "Conexão" "";
proxy_http_version 1.1;
proxy_pass http://b;
}

localização @health_check {
health_check;
proxy_connect_timeout 2s;
proxy_read_timeout 3s;
proxy_set_header Host example.com;
proxy_pass http://b;
}

Em configurações complexas, é possível simplificar ainda mais o gerenciamento ao agrupar todos os locais de verificação de integridade em um único servidor virtual, juntamente com a API e o painel do NGINX Plus , como neste exemplo.

server { 
listen 8080;

location / {
# …
}

location @health_check_b {
health_check;
proxy_connect_timeout 2s;
proxy_read_timeout 3s;
proxy_set_header Host example.com;
proxy_pass http://b;
}

location @health_check_c {
health_check;
proxy_connect_timeout 2s;
proxy_read_timeout 3s;
proxy_set_header Host api.example.com;
proxy_pass http://c;
}

location /api {
api write=on;
# diretivas que limitam o acesso à API (veja 'Erro 8' abaixo)
}

location = /dashboard.html {
root /usr/share/nginx/html;
}
}

Para obter mais informações sobre verificações de integridade para servidores HTTP, TCP, UDP e gRPC, consulte o Guia de administração do NGINX Plus .

Erro 8: Acesso não seguro às métricas

Métricas básicas sobre a operação do NGINX estão disponíveis no módulo Stub Status . Para o NGINX Plus, você também pode reunir um conjunto muito mais extenso de métricas com a API do NGINX Plus . Habilite a coleta de métricas incluindo a diretiva stub_status ou api , respectivamente, em um bloco server{} ou location{} , que se torna a URL que você acessa para visualizar as métricas. (Para a API NGINX Plus , você também precisa configurar zonas de memória compartilhada para as entidades NGINX – servidores virtuais, grupos upstream, caches e assim por diante – para as quais deseja coletar métricas; consulte as instruções no Guia de administração do NGINX Plus .)

Algumas das métricas são informações confidenciais que podem ser usadas para atacar seu site ou os aplicativos proxy do NGINX, e o erro que às vezes vemos nas configurações do usuário é a falha em restringir o acesso à URL correspondente. Aqui veremos algumas maneiras de proteger as métricas. Usaremos stub_status nos primeiros exemplos.

Com a configuração a seguir, qualquer pessoa na Internet pode acessar as métricas em http://example.com/basic_status .

servidor { 
ouvir 80;
nome_do_servidor exemplo.com;

localização = / status_básico {
status_do_stub;
}
}

Proteja métricas com autenticação básica HTTP

Para proteger as métricas com senha com a autenticação básica HTTP , inclua as diretivas auth_basic e auth_basic_user_file . O arquivo (aqui, .htpasswd ) lista os nomes de usuário e senhas dos clientes que podem fazer login para ver as métricas:

servidor { 
listen 80;
server_name example.com;

location = /basic_status {
auth_basic “site fechado”;
auth_basic_user_file conf.d/.htpasswd;
stub_status;
}
}

Proteja as métricas com as diretivas allow e deny

Se você não quiser que usuários autorizados tenham que efetuar login e souber os endereços IP dos quais eles acessarão as métricas, outra opção é a diretiva allow . Você pode especificar endereços IPv4 e IPv6 individuais e intervalos CIDR. A diretiva deny all impede o acesso de qualquer outro endereço.

servidor { 
ouvir 80;
nome_do_servidor exemplo.com;

localização = / status_básico {
permitir 192.168.1.0/24;
permitir 10.1.1.0/16;
permitir 2001:0db8::/32;
permitir 96.1.2.23/32;
negar tudo;
stub_status;
}
}

Combine os dois métodos

E se quisermos combinar os dois métodos? Podemos permitir que clientes acessem as métricas de endereços específicos sem uma senha e ainda exigir login para clientes vindos de endereços diferentes. Para isso usamos a diretiva satisfaz any . Ele informa ao NGINX para permitir acesso a clientes que efetuam login com credenciais de autenticação HTTP Basic ou que estão usando um endereço IP pré-aprovado. Para maior segurança, você pode definir "satisfazer a todos " para exigir que até mesmo pessoas que vêm de endereços específicos façam login.

servidor { 
ouvir 80;
nome_do_servidor monitor.example.com;

localização = / status_básico {
satisfazer qualquer;

auth_basic “site fechado”;
auth_basic_user_file conf.d/.htpasswd;
permitir 192.168.1.0/24;
permitir 10.1.1.0/16;
permitir 2001:0db8::/32;
permitir 96.1.2.23/32;
negar todos;
stub_status;
}
}

Com o NGINX Plus, você usa as mesmas técnicas para limitar o acesso ao ponto de extremidade da API do NGINX Plus ( http://monitor.example.com:8080/api/ no exemplo a seguir), bem como ao painel de monitoramento de atividades ao vivo em http://monitor.example.com/dashboard.html .

Esta configuração permite acesso sem senha somente para clientes vindos da rede 96.1.2.23/32 ou localhost. Como as diretivas são definidas no nível do servidor , as mesmas restrições se aplicam à API e ao painel. Como observação, o parâmetro write=on para api significa que esses clientes também podem usar a API para fazer alterações de configuração.

Para obter mais informações sobre como configurar a API e o painel, consulte o Guia de administração do NGINX Plus .

servidor { 
ouvir 8080;
nome_do_servidor monitor.example.com;

satisfazer qualquer;
auth_basic “site fechado”;
auth_basic_user_file conf.d/.htpasswd;
permitir 127.0.0.1/32;
permitir 96.1.2.23/32;
negar todos;

localização = /api/ { 
api write=on;
}

localização = /dashboard.html {
root /usr/share/nginx/html;
}
}

Erro 9: Usando ip_hash quando todo o tráfego vem do mesmo bloco CIDR /24

O algoritmo ip_hash equilibra a carga do tráfego entre os servidores em um bloco upstream{} , com base em um hash do endereço IP do cliente. A chave de hash são os três primeiros octetos de um endereço IPv4 ou o endereço IPv6 inteiro. O método estabelece persistência de sessão, o que significa que as solicitações de um cliente são sempre passadas para o mesmo servidor, exceto quando o servidor não está disponível.

Suponha que implantamos o NGINX como um proxy reverso em uma rede privada virtual configurada para alta disponibilidade. Colocamos vários firewalls, roteadores, balanceadores de carga de Camada 4 e gateways na frente do NGINX para aceitar tráfego de diferentes fontes (rede interna, redes parceiras, Internet e assim por diante) e passá-lo ao NGINX para proxy reverso para servidores upstream. Aqui está a configuração inicial do NGINX:

http {
upstream {
ip_hash;
servidor 10.10.20.105:8080;
servidor 10.10.20.106:8080;
servidor 10.10.20.108:8080;
}

servidor {# …}
}

Mas acontece que há um problema: todos os dispositivos “interceptadores” estão na mesma rede 10.10.0.0/24, então para o NGINX parece que todo o tráfego vem de endereços nesse intervalo CIDR. Lembre-se de que o algoritmo ip_hash faz o hash dos três primeiros octetos de um endereço IPv4. Em nossa implantação, os três primeiros octetos são os mesmos – 10.10.0 – para cada cliente, então o hash é o mesmo para todos eles e não há base para distribuir tráfego para servidores diferentes.

A solução é usar o algoritmo de hash com a variável $binary_remote_addr como chave de hash. Essa variável captura o endereço completo do cliente, convertendo-o em uma representação binária de 4 bytes para um endereço IPv4 e 16 bytes para um endereço IPv6. Agora o hash é diferente para cada dispositivo de interceptação e o balanceamento de carga funciona conforme o esperado.

Também incluímos o parâmetro consistente para usar o método de hash ketama em vez do padrão. Isso reduz bastante o número de chaves que são remapeadas para um servidor upstream diferente quando o conjunto de servidores muda, o que gera uma maior taxa de acerto de cache para servidores de cache.

http { 
upstream {
hash $binary_remote_addr consistente;
servidor 10.10.20.105:8080;
servidor 10.10.20.106:8080;
servidor 10.10.20.108:8080;
}

servidor {# …}
}

Erro 10: Não aproveitar os grupos upstream

Suponha que você esteja empregando o NGINX para um dos casos de uso mais simples, como um proxy reverso para um único aplicativo de backend baseado em NodeJS escutando na porta 3000. Uma configuração comum pode ser parecida com esta:

http {
servidor {
ouvir 80;
nome_do_servidor exemplo.com;

localização / {
proxy_set_header Host $host;
proxy_pass http://localhost:3000/;
}
}
}

Simples, certo? A diretiva proxy_pass informa ao NGINX para onde enviar solicitações dos clientes. Tudo o que o NGINX precisa fazer é resolver o nome do host para um endereço IPv4 ou IPv6. Depois que a conexão é estabelecida, o NGINX encaminha as solicitações para esse servidor.

O erro aqui é supor que, como há apenas um servidor — e, portanto, não há razão para configurar o balanceamento de carga — não faz sentido criar um bloco upstream{} . Na verdade, um bloco upstream{} desbloqueia vários recursos que melhoram o desempenho, conforme ilustrado por esta configuração:

http {
upstream node_backend {
zona upstreams 64K;
servidor 127.0.0.1:3000 max_fails=1 fail_timeout=2s;
keepalive 2;
}

servidor {
listen 80;
server_name example.com;

localização / {
proxy_set_header Host $host;
proxy_pass http://node_backend/;
proxy_next_upstream erro tempo limite http_500;

}
}
}

A diretiva de zona estabelece uma zona de memória compartilhada onde todos os processos de trabalho do NGINX no host podem acessar informações de configuração e estado sobre os servidores upstream. Vários grupos upstream podem compartilhar a zona. Com o NGINX Plus, a zona também permite que você use a API do NGINX Plus para alterar os servidores em um grupo upstream e as configurações para servidores individuais sem reiniciar o NGINX. Para obter detalhes, consulte o Guia de administração do NGINX Plus .

A diretiva do servidor tem vários parâmetros que você pode usar para ajustar o comportamento do servidor. Neste exemplo, alteramos as condições que o NGINX usa para determinar que um servidor não está íntegro e, portanto, inelegível para aceitar solicitações. Aqui, ele considera um servidor insalubre se uma tentativa de comunicação falhar mesmo uma vez a cada período de 2 segundos (em vez do padrão de uma vez a cada período de 10 segundos ).

Estamos combinando essa configuração com a diretiva proxy_next_upstream para configurar o que o NGINX considera uma tentativa de comunicação com falha, caso em que ele passa as solicitações para o próximo servidor no grupo upstream. Às condições de erro e tempo limite padrão, adicionamos http_500 para que o NGINX considere um HTTP 500(Internal Server Error) código de um servidor upstream para representar uma tentativa com falha.

A diretiva keepalive define o número de conexões keepalive ociosas para servidores upstream preservadas no cache de cada processo de trabalho. Já discutimos os benefícios no Erro 3: Não habilitar conexões Keepalive com servidores upstream .

Com o NGINX Plus, você pode configurar recursos adicionais com grupos upstream:

  • Mencionamos acima que o NGINX Open Source resolve nomes de host de servidor para endereços IP apenas uma vez, durante a inicialização. O parâmetro resolve da diretiva do servidor permite que o NGINX Plus monitore alterações nos endereços IP que correspondem ao nome de domínio de um servidor upstream e modifique automaticamente a configuração upstream sem a necessidade de reiniciar.

    O parâmetro de serviço também permite que o NGINX Plus use registros DNS SRV , que incluem informações sobre números de porta, pesos e prioridades. Isso é essencial em ambientes de microsserviços onde os números de porta dos serviços são frequentemente atribuídos dinamicamente.

    Para obter mais informações sobre como resolver endereços de servidor, consulte Usando DNS para descoberta de serviço com NGINX e NGINX Plus em nosso blog.

  • O parâmetro slow_start da diretiva do servidor permite que o NGINX Plus aumente gradualmente o volume de solicitações enviadas a um servidor que foi considerado íntegro e disponível para aceitar solicitações. Isso evita uma enxurrada repentina de solicitações que podem sobrecarregar o servidor e fazer com que ele falhe novamente.

  • A diretiva queue permite que o NGINX Plus coloque solicitações em uma fila quando não é possível selecionar um servidor upstream para atender à solicitação, em vez de retornar um erro ao cliente imediatamente.

Recursos

Para experimentar o NGINX Plus, comece hoje mesmo seu teste gratuito de 30 dias ou entre em contato conosco para discutir seus casos de uso .

Leia mais postagens de blog sobre F5 NGINX›

"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."