Confusão de proxy de balanceamento de carga Nginx

Question

Atualmente, estou tentando configurar um balanceador de carga para vários espelhos de download. Ao ler este assunto, vi que o Nginx se presta perfeitamente como um balanceador de carga, ótimo! Mas ao olhar para as diferentes configurações, fiquei meio confuso.

Pode-se decidir redirecionar ou proxy para os servidores back-end. Redirecionamento é bastante claro, você diz ao cliente para ir em outro lugar e a solicitação é passada e manipulada, o balanceador de carga está fora de cena.

No entanto, se você optar por usar um proxy, isso basicamente não prejudica a ideia de ter vários espelhos de download em execução? Dado que o nginx encaminhará o pedido para o servidor backend, baixe o arquivo e passe para o cliente?

Então, para visualizar como eu acho que funciona (Fluxo de pacotes):

Redirecionar : cliente = > Balanceador de carga = > Backend = > Cliente

Proxy : cliente = > Balanceador de carga = > Backend = > Balanceador de carga = > Cliente

Ou o proxy fará alguma mágica e dirá ao cliente para realmente se conectar ao backend para baixar o arquivo dele?

Caso o proxy realmente derrote o propósito de ter múltiplos espelhos de download para obter mais taxa de transferência, a única alternativa é redirecionar?

EDITAR: Ou estou confundindo o funcionamento de um proxy com o de uma reescrita? Um proxy realmente transmite a solicitação como um redirecionamento usa a mesma URL?

    

Answer 1

Caso você use nginx como balanceador de carga, o fluxo será:

Redirecionar:

Step 1 : Client => LB      (HTTP request) 
Step 2 : LB => Client      (HTTP reply)
Step 3 : Client => Backend (HTTP request)
Step 4 : Backend => Client (HTTP reply)

Proxy:

Step 1 : Client => LB      (HTTP request) 
Step 2 : LB => Backend     (HTTP request) 
Step 3 : Backend => LB     (HTTP reply) 
Step 4 : LB => Client      (HTTP reply) 

Assim, no primeiro caso, o balanceador de carga, da maneira como você pensa, é um servidor HTTP simples e os backends respondem diretamente ao cliente. No segundo caso, vai todo o caminho de volta ao cliente através do nginx. Como o nginx não irá necessariamente esperar que o corpo da resposta completa esteja disponível para iniciar a transferência de dados para o cliente, ele usa buffers ou arquivos temporários para transmitir de volta dependendo da configuração. Mas, você encontrará maiores tempos de ida e volta de pacotes desde que você obtenha mais um salto durante as transferências reais de dados.

Então, essa é a grande figura do balanceamento de carga da camada 7 do OSI, caso o HTTP esteja em uso. Agora, o balanceamento de carga de rede não está limitado à camada 7 e ao HTTP. Existem outras maneiras.

Particularmente, se você está procurando uma maneira de distribuir tráfego para servidores de back-end que hospedam conteúdo essencialmente estático, use keepalived como sua solução de balanceamento de carga no modo Roteamento Direto que fará com que os servidores backend respondam diretamente ao cliente, enquanto as solicitações chegam pelo balanceador de carga (é a camada OSI 4, portanto não sabe o que você está fazendo para cima IP virtual e empurre o fluxo TCP para os servidores reais, onde o mesmo IP virtual é montado na interface de loopback). O Keepalived também manipula o HA usando o VRRP (modelo mestre / backup).

Se você quiser manter o nginx, há algo "semelhante", chamado de stream (apareceu no nginx 1.9.0, não em uma versão "estável"), mas você precisará recompilar você mesmo e isso não impedirá o retorno de volta mesmo trabalhando na camada OSI 4 também.