Há alguma sugestão sobre quando devo usar roundrobine quando devo usar leastconn?
Estou usando roundrobinatualmente e observei que o carregamento dos meus serviços back-end não é uma distribuição uniforme. Claro que pode haver outro problema, mas queremos leastconntentar, mas como é um servidor de missão crítica, quero consultar outra experiência antes de fazer as alterações.
Alguma idéia para compartilhar?
Eu não experimentei o leastconn, mas meu entendimento é que o caso de uso típico do leastconn é quando você balança a carga com algo que pode ter conexões duradouras. A razão para isso é que o mínimo de conexão se concentra em garantir simultaneidade equilibrada, onde, como o rodízio rodoviário, fornece uma taxa de chegada mais equilibrada . Se essa distinção não estiver clara, veja minha resposta sobre a diferença .
Quando você diz que a carga não é distribuída uniformemente, pode ser útil definir "carga" um pouco melhor. Se você quer dizer recursos do servidor, sugiro identificar o que exatamente está causando o aumento da carga (ou seja, certos tipos de conexões) e trabalhar de trás para frente.
Depende do protocolo e do caso de uso para equilibrar. Para qualquer coisa em que a quantidade de conexões esteja correlacionada com a carga / uso, é melhor usar leastconn. Devido à maneira como as redes e os aplicativos funcionam, é quase sempre verdade e é melhor usar leastconnpor padrão.
Por exemplo, uma empresa possui um pool de áreas de trabalho remotas às quais os funcionários se conectam. Você gostaria que os funcionários fossem distribuídos de maneira uniforme pelos desktops.
O número de conexões ativas nesse caso de uso é aproximadamente "quantos funcionários estão usando essa área de trabalho no momento". O host com menos conexões possui menos funcionários e é provavelmente o menos carregado. Use "leastconn" nessas circunstâncias, ele distribui a carga uniformemente com a quantidade de usuários.
Um balanceador de carga ideal deve estar ciente da carga da área de trabalho remota. Quantos usuários? Quantas aplicações? Quanta memória e CPU consumiram? Existem soluções comerciais dedicadas a desktops remotos (Microsoft / Citrix / etc ...), que geralmente medem essas métricas para espalhar o uso muito bem. O HAProxy é um balanceador de carga de rede simples e não pode fazer melhor do que contar conexões com leastconn.
Com o HTTP, uma conexão ativa significa que o servidor está ocupado processando uma solicitação. As conexões são diretamente proporcionais à carga. Você deseja selecionar o servidor com a menor quantidade de conexões ativas (solicitações em andamento). Use leastconnpara tráfego HTTP (S).
Imagine um cenário com dois servidores HTTP, em que um servidor é mais lento para processar solicitações (talvez esteja sobrecarregado, talvez tenha hardware mais antigo).
roundrobindistribuirá solicitações pela metade entre os dois servidores. É muito ineficiente, o servidor mais rápido deve demorar mais. Pior ainda, o servidor mais lento pode estar sobrecarregado, fica ainda mais lento à medida que mais solicitações chegam e pode começar a descartá-las a qualquer momento. Você não quer isso.
leastconndetectaria que os servidores são desiguais. O servidor mais lento mantém as conexões por mais tempo, possui uma contagem maior de conexões. leastconné responsável por isso e prefere o outro servidor.
Na minha experiência, incluindo funções em que eu estava realizando testes de desempenho exclusivamente para sites moderados a grandes. leastconnpode ser 300% mais eficiente que o roundrobinHTTP (S). roundrobinnão distribui a conexão de maneira justa e causa instabilidade em alta carga.
(Vamos ignorar que o HAProxy não suporta UDP e UDP é menos conexão).
Um último exemplo. DNS é um protocolo simples. Os clientes enviam uma única mensagem UDP para solicitar um domínio e o servidor DNS responde em uma única mensagem.
Nesse caso, não há realmente uma conexão. Mesmo que houvesse, seria instantaneamente fechado (teoricamente).
Não faria sentido contar conexões nessas circunstâncias, não é o ideal leastconn. Um simples roundrobinpode distribuir mensagens.
Às vezes, as pessoas acreditam que não devem usar leastconnpara conexões de vida curta (semelhante ao último exemplo). Até a documentação do HAProxy é enganosa sobre isso.
leastconn
Use of this algorithm is recommended where very long sessions are
expected, such as LDAP, SQL, TSE, etc... but is not very well
suited for protocols using short sessions such as HTTP.
[misleading advice, should ignore it]
No mundo real, short connectionsnão é uma coisa.
Os aplicativos são criados sobre o TCP. As mensagens são entregues e frequentemente processadas em ordem. Quando um servidor está lento ou sobrecarregado, as conexões "curtas" ficam mais longas. Se houver (mais) conexões, provavelmente há algum (mais) trabalho sendo realizado. A contagem e a duração da conexão variam e têm significado.
Pense em um servidor HTTP básico. Alguns ativos demoram alguns milissegundos, algumas chamadas de API demoram alguns segundos, uma página pode demorar a carregar com qualquer quantidade de solicitações, etc. As solicitações não têm vida curta, sua vida útil segue o que está sendo processado em qual servidor. leastconnentende a atividade em andamento e ajusta a distribuição, que é exatamente o que você deseja de um balanceador de carga.