☰

Proxy reverso Nginx enviando a mesma solicitação para vários servidores back-end

tag-icon • tag-icon nginx
Proxy reverso Nginx enviando a mesma solicitação para vários servidores back-end

Eu tenho NGINX como proxy reverso e dois Apache como servidores upstream.

Sempre que visito example.com (direcionado para NGINX), ambos os servidores Apache recebem a solicitação GET. Parece estranho, pois o NGINX por padrão funciona com base no método Round Robin

Aqui está minha configuração: -

upstream apache {
         server 172.18.0.164;
         server 172.18.8.18;
        }


location / {
       proxy_pass http://apache;
    }

Registros na máquina Apache 1: -

192.168.10.236 - - [05/out/2015:07:59:21 -0400] "OBTER/HTTP/1.0" 200

Registros na máquina Apache 2: -

172.18.8.97 - - [05/Out/2015:11:59:27 +0000] "OBTER /wordpress/ HTTP/1.0"

Responder1

Direto doGuia de administração Nginx:

Habilitando Persistência de Sessão

NGINX Plus oferece suporte a três métodos de persistência de sessão. Os métodos são definidos com opegajosodiretiva.

Obiscoito pegajosométodo. Com este método, o NGINX Plus adiciona um cookie de sessão à primeira resposta do grupo upstream e identifica o servidor que enviou a resposta. Quando um cliente emitir a próxima solicitação, ele conterá o valor do cookie e o NGINX Plus encaminhará a solicitação para o mesmo servidor upstream:

upstream backend {
    server backend1.example.com;
    server backend2.example.com;

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

No exemplo, o srv_idparâmetro define o nome do cookie que será definido ou inspecionado. O parâmetro opcional expiresdefine o tempo para o navegador manter o cookie. O parâmetro opcional domaindefine um domínio para o qual o cookie está definido. O parâmetro opcional pathdefine o caminho para o qual o cookie está definido. Este é o método de persistência de sessão mais simples.

Orota pegajosamétodo. Com este método, o NGINX Plus atribuirá uma “rota” ao cliente quando receber a primeira solicitação. Todas as solicitações subsequentes serão comparadas com orotaparâmetro doservidordiretiva para identificar o servidor onde as solicitações serão proxy. As informações da rota são obtidas do cookie ou do URI.

upstream backend {
    server backend1.example.com route=a;
    server backend2.example.com route=b;

    sticky route $route_cookie $route_uri;
}

Obiscoito aprendermétodo. Com esse método, o NGINX Plus primeiro encontra identificadores de sessão inspecionando solicitações e respostas. Então o NGINX Plus “aprende” qual servidor upstream corresponde a qual identificador de sessão. Geralmente, esses identificadores são passados ​​em um cookie HTTP. Se uma solicitação contiver um identificador de sessão já “apreendido”, o NGINX Plus encaminhará a solicitação para o servidor correspondente:

upstream backend {
   server backend1.example.com;
   server backend2.example.com;

   sticky learn 
       create=$upstream_cookie_examplecookie
       lookup=$cookie_examplecookie
       zone=client_sessions:1m
       timeout=1h;
}

No exemplo, um dos servidores upstream cria uma sessão definindo o cookie “EXAMPLECOOKIE” na resposta.

O parâmetro obrigatório createespecifica uma variável que indica como uma nova sessão é criada. No nosso exemplo, novas sessões são criadas a partir do cookie “EXAMPLECOOKIE” enviado pelo servidor upstream.

O parâmetro obrigatório lookupespecifica como procurar sessões existentes. No nosso exemplo, as sessões existentes são pesquisadas no cookie “EXAMPLECOOKIE” enviado pelo cliente.

O parâmetro obrigatório zoneespecifica uma zona de memória compartilhada onde todas as informações sobre sessões fixas são mantidas. Em nosso exemplo, a zona é nomeada client_sessionse tem o tamanho de 1 megabyte.

Este é um método de persistência de sessão mais sofisticado, pois não requer a manutenção de cookies no lado do cliente: todas as informações são mantidas no lado do servidor na zona de memória compartilhada.

informação relacionada