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:
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.