Como os balanceadores de carga se encaixam em um data center com taxa de transferência muito maior do que eles podem suportar?

10

Você tem um data center padronizado em conexões 10GE. Com, digamos, o Nexus 7000s no núcleo, o Nexus 5000s na agregação e alguns extensores de malha para a borda dos servidores (eu uso o Cisco gear como exemplos, porque é isso que está no meu laboratório específico). Existem alguns balanceadores de carga do ACE 4710 pendurados no seu Nexus 5000s, mas eles possuem apenas interfaces 1GE. Todas as suas conexões de switch são 10GE, necessárias para o tráfego maciço leste-oeste (VM para VM) nos modernos datacenters virtualizados.

Os balanceadores de carga não se tornam um gargalo em determinadas condições de tráfego? Eu posso ver como algum tráfego local leste-oeste nem precisa alcançar o balanceador de carga, mas há outras situações em que você precisa atravessar o núcleo e, possivelmente, até uma interconexão de data center.

Basicamente, eu sei que os balanceadores de carga são usados no tráfego cliente-servidor (norte-sul) e coisas como HTTP GET não precisam do 10GE, mas há situações em que o seu balanceador de carga 1GE pode atrapalhar um caminho Caminho de tráfego 10GE e causar problemas para coisas como vMotion (por exemplo)?

load-balancer

— sentinela
fonte

11

O ACE 4710 é EOL / EOS desde 2010. Você está vinculado a esse balanceador de carga ou está aberto a usar um balanceador de carga moderno que pode ser escalado muito mais alto? (Muitos fabricantes as fabricam.) Não há razão para colocar artificialmente limites em sua taxa de transferência da maneira que você descreve. Bem, não há razão fora do custo, mas, na verdade, se você comprou a infraestrutura que descreve, provavelmente terá dinheiro sobrando para uma configuração real do balanceador de carga.

— Brett Lykins

Na verdade, esse não é um ambiente de produção, mas um cenário real de "laboratório" que contém esses dispositivos específicos. Em um sentido mais geral, minha pergunta é, dada a carga de tráfego de um datacenter típico, como garantir que o balanceador de carga não se torne um gargalo no seu design? Isso é importante para o seu design, como, por exemplo, se o seu datacenter é de várias camadas, em que nível você faz o balanceamento de carga, etc. Dispositivos ACE com um único braço dos Nexus 5000, que são muito mais poderosos.

— sentinel

6

Os balanceadores de carga não se tornam um gargalo em determinadas condições de tráfego?

Certamente, mas esse geralmente não é o caso em uma rede bem projetada.

Você deve poder projetar sua rede de uma maneira que permita a maior parte do tráfego interno de servidor para servidor ("leste-oeste", como você diz), mesmo que seja necessário atravessar seu núcleo ou entre os datacenters.

Embora muitas vezes o balanceador de carga seja o gateway padrão para os servidores por trás dele, vi configurações em que um protocolo de roteamento (por exemplo, OSPF ou RIP) é executado para permitir que o tráfego "leste-oeste" contorne o balanceador de carga ou em implantações menores onde rotas estáticas foram usadas.

Se os balanceadores de carga forem um gargalo, mesmo com um bom design (ou seja, o volume de tráfego é tão alto), também existem maneiras de balancear a carga em vários balanceadores de carga.

— YLearn
fonte

4

De fato. Se houver um LB no seu caminho do vMotion, você falhou como engenheiro.

— Ricky feixe

"... existem maneiras de balancear a carga em vários balanceadores de carga também" - como selecionar o balanceador de carga de rede no DNS?

— Andrei Rînea 14/03

2

Este é realmente um gargalo e limitará sua taxa de transferência ao "elo mais fraco da cadeia", que é o seu LBs. No entanto, você pode contornar isso. Se você usar algo conhecido como "retorno" ou "retorno direto do servidor", poderá executar fluxos de tráfego assíncronos. O modo como funciona é o seguinte:

a) o cliente faz uma solicitação http para 2.2.2.2

b) O LB responde no 2.2.2.2 e passa a solicitação de entrada para um servidor - como o LB e o servidor estão na mesma LAN, isso é feito na camada 2.

c) O servidor aceita esta conexão de entrada, pois o IP 2.2.2.2 está em uma interface de loopback com alias (caso contrário, descartaria um pacote que não correspondesse a uma interface).

d) O servidor responde diretamente ao cliente.

A solicitação é de alguns bytes. O conteúdo exibido pode ser de qualquer tamanho. O tráfego de saída não passa pelo LB; portanto, você pode lidar com muito mais tráfego.

Felicidades,

--tc

— Thomas Cannon
fonte

11

Lembre-se de que isso é apropriado apenas para clusters L4. Para clusters L7, isso interrompe a reescrita do cabeçalho, a inserção de cookies (persistência), a terminação SSL, qualquer tipo de correspondência de URL e outros recursos mais avançados de muitos balanços de carga.

— YLearn