NGINX balanceamento de carga usando a diretiva ip_hash

Question

Eu tenho um cluster de servidor de dois nós simples, sendo executado em localhost:8001 e localhost:8002 , com balanceamento de carga usando NGINX. Abaixo está o contexto http do meu nginx.conf .

http {
    include       mime.types;
    default_type  application/octet-stream;

    upstream backend {
        ip_hash;
        server localhost:8001;
        server localhost:8002;
    }

    log_format upstreamlog 'upstream: $upstream_addr: $request upstream-response-status: $upstream_status';

    server {
        listen              80;
        listen              [::]:80;
        server_name         localhost;
        access_log  logs/access.log  upstreamlog;

        location / {
            proxy_pass http://backend/;
        }
    }
}

Inicialmente, todas as solicitações para o link foram redirecionadas para o servidor upstream sendo executado na porta 8001.

- Registros

 upstream: [::1]:8001: GET / HTTP/1.1 upstream-response-status: 200
 upstream: [::1]:8001: GET /favicon.ico HTTP/1.1 upstream-response-status: 200
 upstream: [::1]:8001: GET / HTTP/1.1 upstream-response-status: 200
 upstream: [::1]:8001: GET /favicon.ico HTTP/1.1 upstream-response-status: 200
 upstream: [::1]:8001: GET / HTTP/1.1 upstream-response-status: 200
 upstream: [::1]:8001: GET /favicon.ico HTTP/1.1 upstream-response-status: 200
 upstream: [::1]:8001: GET / HTTP/1.1 upstream-response-status: 200
 upstream: [::1]:8001: GET /favicon.ico HTTP/1.1 upstream-response-status: 200
 ----
 upstream: [::1]:8001: GET / HTTP/1.1 upstream-response-status: 200
 upstream: [::1]:8001: GET /favicon.ico HTTP/1.1 upstream-response-status: 200
 upstream: [::1]:8001: GET / HTTP/1.1 upstream-response-status: 200
 upstream: [::1]:8001: GET /favicon.ico HTTP/1.1 upstream-response-status: 200
 upstream: [::1]:8001: GET / HTTP/1.1 upstream-response-status: 200
 upstream: [::1]:8001: GET /favicon.ico HTTP/1.1 upstream-response-status: 200
 upstream: [::1]:8001: GET / HTTP/1.1 upstream-response-status: 200
 upstream: [::1]:8001: GET /favicon.ico HTTP/1.1 upstream-response-status: 200

Agora, para testar o failover dessa configuração, parei o servidor em execução na porta 8001. Mas o failover não funcionou e todas as solicitações subsequentes também foram encaminhadas para o servidor na porta 8001.

- Registros

 upstream: [::1]:8001: GET / HTTP/1.1 upstream-response-status: -
 upstream: [::1]:8001: GET / HTTP/1.1 upstream-response-status: -
 upstream: [::1]:8001: GET / HTTP/1.1 upstream-response-status: -
 upstream: [::1]:8001: GET / HTTP/1.1 upstream-response-status: -
 upstream: [::1]:8001: GET / HTTP/1.1 upstream-response-status: -
 upstream: [::1]:8001: GET / HTTP/1.1 upstream-response-status: -
 upstream: [::1]:8001: GET / HTTP/1.1 upstream-response-status: -
 ----
 upstream: [::1]:8001: GET / HTTP/1.1 upstream-response-status: -
 upstream: [::1]:8001: GET / HTTP/1.1 upstream-response-status: -
 upstream: [::1]:8001: GET / HTTP/1.1 upstream-response-status: -
 upstream: [::1]:8001: GET / HTTP/1.1 upstream-response-status: -
 ----
 upstream: [::1]:8001: GET / HTTP/1.1 upstream-response-status: -
 upstream: [::1]:8001: GET / HTTP/1.1 upstream-response-status: -
 upstream: [::1]:8001, 127.0.0.1:8001, [::1]:8002: GET / HTTP/1.1 upstream-response-status: 504, 504, 200

O NGINX demorou muito tempo, aproximadamente 3 minutos, para passar para o outro nó na porta 8002. O que eu estou perdendo na configuração? Eu sei que o padrão max_fails é 1 e fail_timeout é 10 seconds . Como fazer o NGINX alternar para outro nó de servidor com tempo de inatividade zero?

(NOTA: ip_hash teve que ser usado para afinidade de sessão e outros propósitos)

    

Answer 1

Acho que você precisa adicionar a diretiva proxy_next_upstream no bloco de localização. Esta função diretiva é especificar em quais casos uma solicitação deve ser passada para o próximo servidor. Em seguida, adicione http_503, porque quando você parar a instância, ele irá lançar 503 ou o serviço estará indisponível. Se o seu problema é porque o tempo limite você pode mudar o proxy_connect_timeout e proxy_read_timeout. Exemplo de configuração

    location / {
        proxy_pass http://backend/;
        proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
        #timeout for 10 second
        proxy_connect_timeout 10;
        proxy_read_timeout 10;
    }

Aqui está a documentação de todas as diretivas de proxy no link