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

1

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

Sempre que eu visito example.com (direcionado para NGINX), ambos os Apache Servers estão recebendo a solicitação GET. Parece estranho como o NGINX funciona por padrão baseado 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;
    }

Faz o login na máquina do Apache 1: -

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

Faz o login na máquina Apache 2: -

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

    
por zealvora 05.10.2015 / 14:26

1 resposta

1

Diretamente do Guia de administração do Nginx :

Ativando a persistência da sessão

O NGINX Plus suporta três métodos de persistência de sessão. Os métodos são definidos com a diretiva sticky .

O método sticky . Com esse 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 emite a próxima solicitação, ele conterá o valor do cookie e o NGINX Plus roteará 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 parâmetro srv_id define o nome do cookie que será configurado ou inspecionado. O parâmetro opcional expires define o tempo para o navegador manter o cookie. O parâmetro opcional domain define um domínio para o qual o cookie está definido. O parâmetro opcional path define o caminho para o qual o cookie está definido. Este é o método de persistência de sessão mais simples.

O método rota aderente . Com este método, o NGINX Plus atribuirá um “caminho” ao cliente quando receber o primeiro pedido. Todos os pedidos subsequentes serão comparados com o parâmetro rota do Diretiva servidor para identificar o servidor no qual as solicitações serão intermediadas por proxy. As informações da rota são obtidas de cookies ou URI.

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

    sticky route $route_cookie $route_uri;
}

O método cookie learn . Com este método, o NGINX Plus 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á "aprendido", 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 create especifica uma variável que indica como uma nova sessão é criada. Em nosso exemplo, novas sessões são criadas a partir do cookie "EXAMPLECOOKIE" enviado pelo servidor upstream.

O parâmetro obrigatório lookup especifica como procurar sessões existentes. Em nosso exemplo, as sessões existentes são pesquisadas no cookie "EXAMPLECOOKIE" enviado pelo cliente.

O parâmetro obrigatório zone especifica uma zona de memória compartilhada onde todas as informações sobre sessões fixas são mantidas. No nosso exemplo, a zona é denominada client_sessions e tem o tamanho de 1 megabyte.

Este é um método de persistência de sessão mais sofisticado, pois não é necessário manter nenhum cookie no lado do cliente: todas as informações são mantidas no lado do servidor na zona de memória compartilhada.

    
por 05.10.2015 / 15:04

Tags