Questão #

Um usuário relata que está usando o Relianoid para balanceamento de carga com persistência de sessão baseada em inserção de cookie. Inicialmente, a configuração estava perfeitamente balanceada com cinco servidores. No entanto, após adicionar um novo servidor ao pool, as sessões não estão sendo distribuídas conforme o esperado. O novo servidor tem apenas algumas sessões, enquanto os servidores existentes continuam a lidar com a maior parte do tráfego.

Explicação #

Esse problema surge devido ao mecanismo de persistência de sessão atual e ao algoritmo de balanceamento de carga em uso.

Compreendendo o problema #

1. Persistência de sessão baseada em inserção de cookies : Ao usar a inserção de cookies para persistência de sessão, o balanceador de carga atribui um cookie exclusivo a cada cliente. Esse cookie direciona as solicitações subsequentes do mesmo cliente para o mesmo servidor de backend, garantindo a persistência da sessão. Isso funciona bem em um ambiente estável, mas cria desafios quando um novo servidor é adicionado ao pool.

2. Sessões existentes são “persistentes” : Como as sessões já estão estabelecidas com o conjunto inicial de servidores, essas sessões existentes permanecem “persistentes” aos seus backends originais devido ao cookie de persistência. Consequentemente, o servidor recém-adicionado recebe apenas novas sessões ou tráfego de novos clientes que ainda não receberam um cookie de persistência.

3. Limitações dos Algoritmos de Agendamento Atuais : Muitos balanceadores de carga utilizam algoritmos de agendamento padrão, como Round Robin ou Menor Tempo de Resposta. Esses algoritmos nem sempre reequilibram a carga quando novos servidores são adicionados, especialmente quando há persistência de sessão envolvida. Isso ocorre porque os algoritmos tendem a manter conexões com os servidores de backend existentes para sessões ativas.

Por que as sessões não estão sendo rebalanceadas #

Quando um novo servidor é adicionado, ele não começa imediatamente a compartilhar a carga igualmente porque:

• As sessões existentes são vinculadas aos seus backends originais.
• O algoritmo de agendamento padrão não prioriza backends com menos sessões ou conexões.

Para conseguir uma distribuição justa de sessões, é necessário um algoritmo de balanceamento de carga diferente.

Solução #

Use o algoritmo de agendamento “Least Connections” #

O algoritmo Least Connections é um método de agendamento em que o balanceador de carga seleciona o servidor backend com o menor número de conexões ativas. Essa abordagem ajuda a distribuir sessões de forma mais uniforme, especialmente quando um novo servidor é adicionado ao pool.

Veja por que “Menos Conexões” funciona efetivamente neste cenário:

• Rebalanceamento dinâmico: diferente de algoritmos como Round Robin, Least Connections avalia constantemente qual servidor tem menos sessões ativas. Isso permite que o novo servidor, que tem menos sessões inicialmente, receba mais conexões novas até que a carga se equilibre.
• Melhor utilização de recursos: à medida que novas sessões são criadas, elas serão direcionadas para o servidor com menor carga, melhorando a utilização geral dos recursos.

Etapas para implementar o algoritmo “Least Connections” no Relianoid #

1. Acesse a configuração do balanceador de carga Relianoid: Efetue login no console de administração do Relianoid ou use as ferramentas CLI, se aplicável.
2. Navegue até as configurações do balanceador de carga: Localize as configurações da instância do balanceador de carga que está gerenciando o pool de servidores com persistência de sessão.
3. Modificar o Algoritmo de Agendamento:

• Encontre a configuração para o algoritmo de balanceamento de carga ou método de agendamento.
• Altere o algoritmo da configuração atual (por exemplo, Round Robin) para Menos conexões.

4. Salvar e aplicar alterações: Certifique-se de salvar suas alterações e aplicá-las à configuração do balanceador de carga. Dependendo do seu ambiente, isso pode exigir a reinicialização do balanceador de carga ou a execução de um soft reload.
5. Monitore e verifique: Após aplicar as alterações, monitore a distribuição de sessões em todos os servidores. Com o tempo, o novo servidor deve começar a receber mais sessões, levando a uma carga mais equilibrada.

Conclusão #

Ao alterar o algoritmo de balanceamento de carga para “Least Connections”, você garante que o servidor recém-adicionado possa recuperar o atraso e começar a manipular mais sessões. Este método de agendamento dinâmico considera o número de conexões ativas e distribui a carga de forma eficiente, resolvendo o problema de desequilíbrio causado pela persistência da sessão com inserção de cookie.

Se você continuar enfrentando problemas após implementar essa alteração, considere verificar:

• A integridade e o desempenho do servidor recém-adicionado.
• A configuração de outros parâmetros que podem afetar o balanceamento de carga (por exemplo, configurações de tempo limite de sessão, duração da aderência, etc.).
• Registros em nível de rede ou aplicativo para possíveis erros ou gargalos.

Seguindo essas etapas, você pode otimizar a configuração do balanceador de carga para garantir uma distribuição de sessão justa e equilibrada entre todos os servidores do seu pool.