Qual é a sua recomendação para um balanceador de carga de software ou compartilhamento de carga para o caso dado?

3

Eu provisionei um servidor com 8 núcleos e planejo a implantação de um serviço de rede. Para distribuir o carregamento da solicitação, gostaria de executar 8 instâncias do meu serviço. Nada chocante aqui. Eu não tenho acesso a um balanceador de carga de hardware. Devo mencionar que atualmente aloquei 5 endereços IP públicos (mas posso obter mais).

Assim, gostaria de ouvir suas recomendações para estruturar uma solução de balanceamento de carga de software.

As escolhas óbvias seriam:

  • use o HAProxy; ou
  • pré-fork meu aplicativo (como Facebook Tornado e Unicorn);
  • insira sua ideia aqui .

Meus objetivos são:

  • carga de solicitação de propagação entre as instâncias de serviço; e
  • permite reinicializar o serviço (upgrades de código).

Devo mencionar que este não é um serviço baseado em HTTP, por isso o NGiNX e similares estão fora.

Eu não amo o HAProxy por causa de seus requisitos de memória; parece exigir um buffer de leitura e gravação por conexão do cliente. Assim, eu teria buffers no nível do kernel, no HAProxy e no meu aplicativo. Isso está ficando bobo! Talvez eu esteja faltando alguma coisa a esse respeito embora?

Obrigado!

    
por z8000 22.01.2010 / 20:22

2 respostas

4

qualquer que seja a solução, se você instalar um processo para encaminhar dados de fluxo, ele exigirá buffers por conexão. Isso é porque você não pode sempre enviar tudo o que você recebeu, então você tem que manter o excesso em um buffer. Dito isso, o uso da memória dependerá do número de conexões simultâneas. Um grande site está executando o haproxy com configurações padrão em 150000 conexões simultâneas (4 GB de RAM). Se você precisar de mais do que isso, a versão 1.4 permite ajustar o tamanho do buffer sem recompilar. No entanto, tenha em mente que os buffers de kernel por soquete nunca ficarão abaixo de 4 kB por direção e por soquete, portanto, pelo menos 16 kb por conexão. Isso significa que é inútil fazer o haproxy rodar com menos de 8 kB por buffer, já que ele consumirá menos que o kernel.

Além disso, se o seu serviço for puro TCP e um proxy não tiver valor agregado, dê uma olhada nas soluções baseadas em rede, como o LVS. É muito mais barato porque processa pacotes e não precisa manter buffers, portanto, os buffers de soquete descartarão pacotes quando estiverem cheios e poderão ser instalados na mesma máquina que o serviço.

Editar : Javier, processos pré-construídos contando com o sistema operacional para fazer o balanceamento de carga não sc Ale que bem em tudo. O sistema operacional ativa todos os processos quando recebe uma conexão,  apenas um deles consegue e todos os outros dormem novamente. Haproxy em multi-pro O modo cess mostra seu melhor desempenho em torno de 4 processos. Em 8 processos, execute a força já começa a cair. O Apache usa um truque legal contra isso, faz um ck em torno do accept () para que apenas um processo esteja aguardando a aceitação. Mas t chapéu mata o recurso de balanceamento de carga do sistema operacional e pára de escala entre 1000 um d 2000 processos. Ele deve usar uma matriz de alguns bloqueios para que alguns processos acorde, mas isso não acontece.

    
por 22.01.2010 / 21:46
1

sem detalhes sobre o seu serviço, é muito difícil dizer; mas, em geral, eu me inclinava para o pré-acabamento. É uma estratégia de servidor testada e verdadeira (e não um truque novo como algumas pessoas pensam depois de ler os fansites de tornado / unicórnio).

Além disso, algumas dicas:

  • cada processo pré-fabricado pode usar estratégias modernas que não são select (libevent, principalmente) para lidar com grandes quantidades de clientes.

  • é muito raro que uma relação de 1: 1 entre núcleos e processos forneça um desempenho ideal; normalmente é muito melhor fazer alguma adaptabilidade dinâmica para carregar.

por 22.01.2010 / 22:08