Forneci um servidor com 8 núcleos e planejo implantar um serviço de rede. Para distribuir a carga de solicitações, gostaria de executar 8 instâncias do meu serviço. Nada chocante aqui. Não tenho acesso a um balanceador de carga de hardware. Devo mencionar que atualmente aloquei 5 endereços IP públicos (mas posso conseguir mais).
Assim, gostaria de ouvir suas recomendações para estruturar uma solução de balanceamento de carga de software.
As escolhas óbvias seriam:
- usar HAProxy; ou
- pré-fork meu aplicativo (como o Facebook Tornado e o Unicorn fazem);
- insira sua ideia aqui.
Meus objetivos são:
- distribuir a carga de solicitação entre as instâncias de serviço; e
- permitir reinicializações contínuas do meu serviço (atualizações de código).
Devo mencionar que este não é um serviço baseado em HTTP, então NGiNX e similares estão fora de questão.
Não adoro 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 na minha aplicação. Isso está ficando bobo! Talvez eu esteja faltando alguma coisa a esse respeito?
Obrigado!
Responder1
qualquer que seja a solução, se você instalar um processo para encaminhar dados de fluxo, serão necessários buffers por conexão. Isso ocorre porque nem sempre você pode enviar tudo o que recebeu, então você tem que manter o excesso em um buffer. Dito isto, o uso de memória dependerá do número de conexões simultâneas. Um grande site está executando haproxy com configurações padrão de 150.000 conexões simultâneas (4 GB de RAM). Se 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 do kernel por soquete nunca ficarão abaixo de 4kB por direção e por soquete, portanto, pelo menos 16kB por conexão. Isso significa que não faz sentido fazer o haproxy rodar com menos de 8 kB por buffer, pois ele já consumirá menos que o kernel.
Além disso, se o seu serviço for TCP puro e um proxy não tiver valor agregado, dê uma olhada em 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 podem ser instalados na mesma máquina que o serviço.
Editar: Javier, processos pré-bifurcados que dependem do sistema operacional para fazer o balanceamento de carga não são tão bem dimensionados. O sistema operacional acordatodoprocessa quando consegue uma conexão, apenas um deles consegue e todos os outros vão dormir novamente. O Haproxy no modo multiprocesso mostra seu melhor desempenho em torno de 4 processos. Aos 8 processos, o desempenho já começa a cair. O Apache usa um truque legal contra isso: ele faz um bloqueio em torno do accept() para que apenas um processo esteja aguardando a aceitação. Mas isso elimina o recurso de balanceamento de carga do sistema operacional e interrompe o escalonamento entre 1.000 e 2.000 processos. Ele deveria usar uma matriz de alguns bloqueios para que alguns processos fossem ativados, mas não faz isso.
Responder2
sem quaisquer detalhes sobre o seu serviço é muito difícil dizer; mas, em geral, eu preferiria pré-forcar. É uma estratégia de servidor testada e comprovada (e não um truque moderno como algumas pessoas pensam depois de ler os fansites de tornado/unicórnio).
Além disso, algumas dicas:
cada processo pré-bifurcado pode usar não-
selectestratégias modernas (libevent, principalmente) para lidar com grandes quantidades de clientes.é muito raro que uma relação 1:1 entre núcleos e processos proporcione desempenho ideal; geralmente é muito melhor fazer alguma adaptabilidade dinâmica para carregar.