Por que o algoritmo de balanceamento não permite a seleção de máquinas de trabalho com base no uso atual da CPU ou da memória

Question

Atualmente estou investigando o balanceamento de carga com o mod_load_balancer e o mod_proxy do Apache. Eu também vou estar olhando para outros balanceadores de carga mais tarde, mas uma coisa ficou clara. Por que dificilmente qualquer um dos balanceadores de carga (se houver algum) toma decisões de distribuição com base na carga real das máquinas de trabalho.

O Apache, por exemplo, distribui solicitações com base no número de solicitações, na quantidade de dados e no tamanho da fila de solicitações. Por que eles não têm algum mecanismo para distribuir pedidos para a máquina com o menor uso de CPU ou de memória.

Estou construindo um sistema onde cada requisição requer muito de CPU a ponto de que 2 ou 3 máquinas trabalhadoras possam atender apenas 10 ou 20 clientes concorrentes antes que eu tenha esgotado todos seus processadores. Alguns pedidos para xml são realmente leves, enquanto outros para 'stuff' são realmente pesados.

Isso realmente faz alguma diferença no esquema das coisas? Será que alguém acha que mesmo um algoritmo de distribuição baseado em CPU se instala em um estilo round robin eventualmente. Adiciona uma sobrecarga extra que não vale a pena.

Existem outros balanceadores de carga que oferecem esse recurso? Eles oferecem isso e ninguém o utiliza por qualquer razão.

Parece algo que seria realmente bom, mas ninguém parece implementá-lo. Estou confuso e preciso de um pouco de conselhos sobre o assunto.

    

Answer 1

Um dos principais problemas com o balanceamento de carga baseado em recursos é que as informações de carga se tornam obsoletas quando você toma a decisão de roteamento. Existe um artigo acadêmico sobre o tópico staleness que você pode querer ler chamado Interpretação da informação de carga do estado . Você pode obter efeitos colaterais desagradáveis, como enviar muita carga para uma caixa que parece subutilizada e sobrecarregá-la. Em suma, o balanceamento baseado em carga parece ser a melhor maneira de fazer isso a princípio para todos, mas acontece que métodos simples tendem a funcionar melhor na prática.

Na maioria dos balanceadores de carga, os algoritmos simples geralmente são bons porque as transações são de curta duração ou causam uma carga tão baixa que uma distribuição aleatória ou round-robin estará perto o suficiente para um bom equilíbrio. Geralmente, há necessidade de sobrecarga para absorver a carga de servidores com falha (se você estiver próximo da utilização máxima em todos os 3, assim que um deles morre, a carga cairá em cascata e você perderá todo o cluster).

Uma solução pode ser criar duas filas, uma para o "material pesado" e outra para o "material leve". Eu chamaria o "material leve" balanceamento de carga e o "material pesado" agendamento de trabalho - em outras palavras, eles parecem ser problemas diferentes. Em seguida, basta limitar o número máximo de sessões para cada cliente e uma fila universal para elas para o planejamento de tarefas. Eu não sei de uma ferramenta ideal para isso fora do topo da minha cabeça embora.

    

Answer 2

Geralmente, descobri que "load" é um termo muito específico derivado de um grande número de métricas que variam de aplicativo para aplicativo. Como nenhum balanceador de carga frontal pode conhecer esse detalhe (fora da caixa) e o fato de que o round robin com alguns limites de conexão cuidadosamente ajustados basicamente funciona, nem sempre vale a pena.

Nos ambientes em que trabalho onde os aplicativos são desenvolvidos internamente, tento fazer com que uma página de "monitor" faça parte do aplicativo que o balanceador de carga usa para monitorar o status do nó (ou seja, para cima / para baixo). Isso pode ser estendido para incluir um fator de carga de número inteiro que um balanceador de carga pode usar para ajustar a carga para esse nó. Tudo o que definimos é a interface consistente e o valor desse inteiro fará com que o balanceador de carga faça isso. Então cabe aos aplicativos e muito teste de carga para garantir que o aplicativo não esteja fazendo nada muito funky para carregar a distribuição.

Seguindo a menção de filas de trabalho de Kyle Brandt, um dos métodos alternativos de balanceamento de carga é que os funcionários recebam solicitações de uma fila em vez de solicitações de balanceamento de carga padrão para um trabalhador (ou preenchidas, conforme o caso) talvez). Um exemplo desta configuração é o servidor web Mongrel2 ( link ) e é usado o 0MQ ( link /) como um mecanismo de distribuição para os trabalhadores da aplicação. Como uma máquina fica mais lenta devido ao processamento pesado, ela não recupera novas solicitações da fila. Você ainda pode se deparar com muitas solicitações "pesadas" sendo recuperadas de uma só vez, mas a questão é mais facilmente interrompida pelos trabalhadores. Seria bastante trivial dividir o trabalho em filas "digitadas", como Kyle sugeriu. Essa é uma grande mudança para um aplicativo de backend suportar a solicitação de pedidos do 0MQ, mas se você começar do zero, pode ser um caminho a seguir.