NGINX Open Source com Balanceamento de Carga e Persistência de Sessão

Atualmente, a maioria dos sistemas disponíveis na Internet são críticos e precisam ficar online todo o tempo. O Balanceamento de Carga é uma opção para que os serviços fiquem disponíveis com uma Alta Disponibilidade e o NGINX Open Source se mostra uma excelente escolha para tal cenário.

[ Hits: 13.621 ]

Por: Fabiano Furtado em 29/09/2016


Colocando o servidor backend em manutenção: Minimizando a perda de sessão



Se um servidor precisar de manutenção, podemos utilizar a diretiva down[9]. Como exemplo, para se colocar o primeiro servidor backend (backend1) em manutenção, alteramos a linha 3 conforme abaixo:

3	  server backend1 down;

Neste caso, independentemente do valor cookie presente no navegador, o upstream direcionará o acesso para o próximo servidor válido, no caso, o backend2. Neste cenário, se o cookie possui o valor correspondente ao backend1, não conseguiremos manter a persistência de sessão, mas pelo menos garantimos o HA. Quando o servidor sair da manutenção, o upstream apontará o cliente novamente para o acesso original através do valor especificado no cookie "route".

Existe uma maneira mais trabalhosa de minimizarmos o impacto desta mudança de sessão, alterando a configuração proposta. Para isto, colocarmos o servidor desejado como down (linha 3) e comentamos as linhas do map (linha 12) e split_clients (linha 7) correspondentes ao servidor em manutenção.

Temos também de alterar a proporção de acesso no split_clients (linha 7), uma vez que um dos servidores backend não mais participa da escolha do hash. Esta maneira altera o cookie do cliente, mas minimiza a perda da persistência de sessão, uma vez que todos os clientes serão redirecionados definitivamente para o outro backend.

A vantagem desta configuração é a conservação da sessão mesmo que o servidor original volte a funcionar corretamente. A desvantagem é que o balanceamento de carga poderá ficar comprometido, uma vez que os clientes que migraram para o outro backend, não mais retornarão ao seu backend original.

Se a persistência de sessão não é algo muito crítico, mas desejável, podemos optar por configurar o servidor em manutenção como down ao invés de utilizarmos os comentários nas linhas correspondentes às diretivas map e split_clients.

Módulo sticky Open Source

Há um módulo sticky[10] Open Source que pode desempenhar com louvor o papel desta configuração proposta. Então, por que não utilizar este módulo? Por se tratar de um serviço crítico, desejamos utilizar o NGINX em sua forma nativa, sem módulos de terceiros.

Além disso, este módulo precisa ser compilado no NGINX[1] Open Source, o que representa uma etapa a mais a ser realizada, além de representar um risco em termos de estabilidade e segurança para a aplicação.

Página anterior     Próxima página

Páginas do artigo
   1. Introdução
   2. Primeiro acesso do cliente: recebendo o cookie "route" do servidor
   3. Colocando o servidor backend em manutenção: Minimizando a perda de sessão
   4. Aumentando a segurança
Outros artigos deste autor
Nenhum artigo encontrado.
Leitura recomendada

Trabalhando com RPM

Otimizando o controle e a digitação de comandos no shell

WeeChat - Um (O) cliente IRC CLI

Software livre na educação de crianças

Instalando e configurando o Monesa no Slackware

  
Comentários
[1] Comentário enviado por mpsnet em 30/09/2016 - 10:42h

Parabéns pelo artigo.
Pretendo utilizar seu artigo para aprimorar meu sistema. Mas desculpe minha ignorância;
- como configuro os outros backends (tem que instalar o nginx neles) ?
- como faço para configurar/gerar o hash nos backends ?

Grato

[2] Comentário enviado por fusca em 30/09/2016 - 13:06h

Obrigado mpsnet!

Olha... não existe ignorância. Ninguém nasce sabendo de nada. Basta um pouco de estudo, dedicação e compromisso com aquilo que se deseja alcançar que a sabedoria aparece.

Sobre a primeira pergunta, os backends não precisam do NGINX. Por se tratar de um proxy reverso, somente a borda precisa dele instalado. No NGINX, basta colocar mais backend na conf, exemplo... backend3, backend4, ....

Em relação à outra dúvida, o HASH é utilizado para "esconder" o nome real dos seus backends. Você pode usar qualquer nome (exemplo: b1, b2, b3, ...), mas, por questões de segurança, sugiro você usar um HASH, pois o mesmo aparece no cookie enviado para o cliente. No Linux, vc pode usar o comando "sha1sum" ou "sha224sum" ou "sha256sum" ou "sha384sum" ou "sha512sum" para gerar o HASH.

Espero ter ajudado.


[1] Comentário enviado por mpsnet em 30/09/2016 - 10:42h

Parabéns pelo artigo.
Pretendo utilizar seu artigo para aprimorar meu sistema. Mas desculpe minha ignorância;
- como configuro os outros backends (tem que instalar o nginx neles) ?
- como faço para configurar/gerar o hash nos backends ?

Grato

[3] Comentário enviado por mpsnet em 30/09/2016 - 13:37h

Ajudou sim
Obrigado

[4] Comentário enviado por rdgovieira em 16/06/2018 - 13:24h

Muito bom o artigo, consegui entender e aplicar na minha infraestrutura com sucesso.
Muito obrigado!


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts