Balanceadores de carga de hardware x software: apenas uma questão de custo?


26

Se o custo não fosse um problema, haveria algum benefício em implantar um balanceador de carga de software para tráfego da Web em comparação com um hardware?

Respostas:


33

A distinção entre balanceadores de carga "hardware" e "software" não é mais significativa. O chamado balanceador de carga de "hardware" é uma CPU da classe PC, interfaces de rede com recursos de processamento de pacotes e algum software para unir tudo. Um balanceador de carga de "software" realizado em um bom servidor com NICs modernas é ... o mesmo.

O que você obtém com ofertas comerciais de ponta, como F5 ou Citrix Netscaler, é:

  • Um conjunto de recursos rico e profundo. Sua solução é madura e pode lidar rapidamente com todas as necessidades comuns e algumas incomuns.
  • Excelentes estatísticas. Os tipos de gerenciamento adoram estatísticas e os técnicos de rede percebem que as estatísticas também podem ser úteis na solução de problemas.
  • Um único fornecedor para sufocar quando algo não está funcionando, ou seja, contrato de suporte diretamente com o fornecedor da solução.
  • Custos salariais mais baixos. O appliance funciona basicamente e o gerenciamento de um não leva muitas horas.

Com os balanceadores de carga de software (de código aberto), você não entende o contrário, o que obtém depende do software que você escolher e como o fará. Dito isto, normalmente você verá:

  • Maior tempo para configurar a solução inicial. Especialmente se você precisar de mais do que apenas balanceamento de carga, armazenamento em cache de FX + reescrita de conteúdo + HA, a configuração de software de código aberto leva mais horas.
  • Você constrói, é o dono. Se sua empresa configurar balanceadores de carga de software de código aberto com técnicos internos, você será 100% responsável pela solução. A documentação, o caminho da atualização, a recuperação de desastres, etc, precisarão ser considerados e talvez implementados por você .

A diferenciação não está realmente em "hardware" versus "software". Está em "compre uma pilha de tecnologia comprovada como um appliance" em vez de "construa você mesmo". Obviamente, há muitas variáveis ​​a serem consideradas ao tomar a decisão final (custos, conjuntos de habilidades internas, tolerância a tempo de inatividade, crescimento futuro etc.).


2
Bons pontos, mas certamente existem balanceadores de carga baseados em ASIC (F5 / ACE / ..?) Que lidam com 'muito' nos processadores distribuídos, não na CPU. Eu também contesto a questão das horas de trabalho, especialmente se o custo das horas do especialista para fazer a configuração.
Joris

Você mencionou brevemente isso, mas acho que deve ser enfatizado que, com um balanceador de carga HW, você normalmente obtém um contrato de suporte que pode ser utilizado sempre que algo der errado. Às vezes, isso se torna o fator decisivo para uma empresa em que direção seguir.
vmfarms

@Joris, @vmfarms Bons pontos, eu concordo. Para obter todos os pontos mais precisos, seria necessário digitar um pequeno romance. :-)
Jesper M

Boa resposta, no entanto, a Barracuda Networks, a Loadbalancer.org e a Kemp Technologies estão vendendo milhares de dispositivos de hardware / software / virtuais para sites muito grandes. Você raramente precisa de algo além da pilha de código-fonte aberto Linux / LVS que eles fornecem ... Não me interpretem mal, as pilhas Citrix & F5 são muito melhores, mas para 95% dos aplicativos é irrelevante. Eu escrevi um blog sobre como comparar balanceadores de carga aqui: loadbalancer.org/blog/…
Malcolm turnbull

2

Os balanceadores de carga de hardware geralmente têm um conjunto mais rico de recursos, especialmente quando você chega aos grandes, como o F5. Você também tem o benefício adicional de maior escalabilidade por causa do descarregamento de hardware.

Por outro lado, se você souber que seu tráfego não será muito alto, os balanceadores de carga de software realmente terão um desempenho muito bom. Se você pode se responsabilizar por ter um LB de Camada 4, o Linux LVS + Keepalived é uma opção muito boa. Se você precisar do poder de um Layer 7 LB, poderá experimentar o HAProxy.

Portanto, em resumo, os LBs de HW normalmente são melhores que os LBs de SW.

Espero que isto ajude!


"HW LBs. Escala melhor que SW LBs" não é muito preciso. Os HW LBs oferecem de longe o melhor desempenho de chassi único . Porém, um bom design de LB de software seria dimensionado horizontalmente e, portanto, dimensionado da mesma forma (e provavelmente seria mais barato que um LB de ferro grande).
Jesper M

2

Algumas reflexões:

Pro: a máquina na qual você executa o balanceador de carga pode ter um hardware muito mais poderoso, por isso seria mais rápido e imporia menos latência extra (embora, dependendo da velocidade dos seus links para o mundo externo, isso possa fazer pouca diferença).

Contras: um balanceador de carga de hardware provavelmente não terá mais poder computacional do que o necessário (pode ser executado em um chip baseado em Atom ou ARM, em vez de uma CPU Intel / AMD robusta de última geração, por exemplo), portanto, consumirá menos energia e gerará menos calor.

Pro: a instalação de seu próprio arranjo de balanceador de carga de software pode oferecer mais flexibilidade na configuração e atualizações / alterações posteriores, onde uma solução de hardware pode ser muito mais do que uma solução fechada de "caixa preta". Embora se você estiver comprando um serviço gerenciado para implementar o balanceador de software, isso fará pouca diferença.

Contras: se você não está gerenciando o balanceador de software (ou seja, a tarefa é terceirizada ou está comprando o serviço como parte de um acordo maior de hospedagem gerenciada), as taxas de administração para manter a configuração significam um hardware pronto para uso solução seria mais barata a longo prazo. Além disso, lembre-se de levar em consideração seu tempo em quaisquer custos, se você ou sua empresa gerenciarem o balanceador de carga.


"a máquina na qual você executa o balanceador de carga poderia ter um hardware muito mais poderoso, portanto seria mais rápida e imporia menos latência extra" - sério? Eu já vi isso disse que um ServerIron poderia lidar com conexões simultâneas 15m enquanto haproxy pode lidar com 10s de milhares
Timmy

@ Timmy - Eu li um estudo de caso no site haproxy (o site deles está, infelizmente, offline), onde eles saturavam um link de 10 Gbps para uma caixa HAProxy e eram redimensionados muito bem, e tenho certeza de que seriam mais de 10 mil solicitações simultâneas .
Mark Henderson

1
Encontrei - webcache.googleusercontent.com/… (graças ao Google Cache) - sendo a linha principal 105931 sessions per seconde cerca de 17% de uso da CPU - isso é bastante insano para um único processador Xeon básico
Mark Henderson

@ Farseeker - obrigado, eu não sabia que eles podiam gerenciar tantas sessões.
23410 Timmy

2

Eu levaria em conta esses pontos também:

Se a empresa possui um departamento de TI com um especialista em rede, um LB de hardware pode ajudar a reduzir a carga de manutenção da equipe de desenvolvimento.

Às vezes, especialmente para grandes empresas, adotando um novo hardware que ninguém sabe operar, implica contratar consultores caros ou até mesmo um novo funcionário.

A equipe de desenvolvimento odiará uma solução de hardware se estiver planejando enfatizar os recursos do balanceador de carga, como por exemplo, para adotar a implantação contínua.


0

Aparentemente, os HW LBs podem melhorar o tratamento das conexões SSL e, portanto, reduzir o número geral de servidores de aplicativos necessários:

http://highscalability.com/blog/2010/8/12/strategy-terminate-ssl-connections-in-hardware-and-reduce-se.html


2
O hardware de descarga SSL também está disponível diretamente para servidores da Web e é suportado pela onipresente biblioteca OpenSSL no Linux; essa vantagem não é de forma alguma exclusiva para os balanceadores de carga de hardware.
Charles Duffy
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.