[GTER] Balanceamento round robin LACP em swtichs HP 5500

Wed Feb 4 00:22:21 -02 2015

Concordo. ECMP é L3, é controlado por protocolos em L3, independente de
controladores externos.

Não está claro no caso do Kalil se a aplicação dele é sobre L3 ou L2, mas
acho que é claro que ele não precisa obrigatoriamente de roteamento. O que
também me parece bem claro é que ele não consegue balancear igualmente o
tráfego e por isso queria round robin.
Não temos informação da quantidade de fluxos que ele tem, quanto mais
fluxos, melhor fica o hashing. Mas ao balancear fluxos, o round robin não
vai proporcionar um balanceamento de dados bruto ideal, pois cada fluxo tem
particularidades de tamanhos de pacotes/frame distintos. Acho que o hashing
baseado em um seed com esses dados de tráfego mais eficaz, só que esse
hashing depende de amostragem. Maior a amostragem, melhor o hashing.

Tanto port aggregation (LAG) como Openflow possuem mecanismos que avaliam o
fluxo como um todo, não somente vendo o L2. Como é feito programando o ASIC
do equipamento (ao menos nos equipamentos de ponta) uma vez programado, o
fluxo é diretamente tratado por hardware, só mudando em caso de expiração
do fluxo ou queda de link.

A maioria das implementações de LAG usam 5 tuplas, os ASICS modernos são
altamente programáveis. No caso de um ethernet puro, a única coisa que
sobra mesmo é o src/dst mac, mas se souber o padrão do que vêm após o
header é possível programar alguns ASICs para analisar e fazer engenharia
de tráfego em cima desse padrão.

O IP realmente domina a comunicação de dados, mas existe uma tendência a
fazer overlay em alguns ambientes e aí existe a tendência de tunelamento em
cima da camada IP e o caminho de balancear fica mais em ECMP ou análise de
pacotes de maior nível. Particularmente eu acho que ECMP resolve e é mais
padronizado nesses casos.

Uma das coisas q vejo frequentemente no Openflow é o uso dele para offload,
acho bem prático e flexível... mas isso é outra discussão. ;)

Em 3 de fevereiro de 2015 20:34, Carlos Ribeiro <cribeiro at telbrax.com.br>
escreveu:

> Durval,
>
> De fato ECMP é L3. Mas na prática, os problemas se tornam semelhantes,
> apesar das diferentes possibilidades técnicas.
>
> Eu conferi a documentação da HP e ela tem uma "pegadinha", pois fala em
> ECMP com round robin, mas usa um hash com o endereço IP, ou seja... não é
> round robin puro.
>
> Nesse sentido também é interessante notar que há implementações de port
> aggregation que operam em L2 mas usam o hash de pacotes incluindo até
> partes do header L3 (endereço IP) ou L4 (porta TCP). Não quer dizer que ele
> faça roteamento, apenas que o chipset usa essa informação diretamente dos
> pacotes IP. Não sei como ele faz com o tráfego que não é IP nesses casos...
> (se é que sobra algo hoje em dia!!!).
>
> *Carlos Ribeiro*
> *Sócio*
> Cel: +55 (31) 9303-3366
> Tel: +55 (31) 3305-5620
> Geral: +55 (31) 3305-5600
> cribeiro at telbrax.com.br
> www.telbrax.com.br
>
> Em 3 de fevereiro de 2015 02:39, Durval Menezes <durval at tmp.com.br>
> escreveu:
>
> > Prezados,
> >
> > On Mon, Feb 02, 2015 at 07:19:19PM -0200, Marcus Sandri wrote:
> > [...]
> > >              Por??m reafirmo que os HP 5500 possuem ECMP (utiliza RR) e
> > > tamb??m suportam OpenFlow.
> >
> > Nunca usei o Openflow, mas... o ECMP nao atua somente em L3? Assim sendo,
> > mesmo que se use a facilidade L3 da switch, acho que nao se aplica ao
> caso
> > que o Kalil perguntou, pois me parece claro que ele gostaria de trabalhar
> > em L2.
> >
> > Um Grande Abraco,
> > --
> >   Durval Menezes (durval AT tmp DOT com DOT br, http://www.tmp.com.br/)
> >
> >
> > > No caso de usar o OpenFlow, d?? pra
> > > emular algoritmos bem melhores do que o RR, diminuindo a
> > > probabilidade de colis??o de hash. Creio que a melhor solu????o
> > > seria testar a t??cnica do Rafael e comparar o desempenho
> > > antes/depois. Se come??ar a ter perdas significativas, sugiro
> > > apelar pro OpenFlow.
> > >
> > > > Pessoal,
> > > >
> > > > Em outro grande fabricante (leia Cisco), WRR e WRED s??o mecanismos
> de
> > > > scheduling entre filas e congestion avoidance, respectivamente. Ou
> > seja,
> > > > s??
> > > > e somente QoS. E n??o RR entre canais L2/L3.
> > > > N??o seria o mesmo caso da HP?
> > > >
> > > > J?? sobre o hashing dos etherchannels, os dois lados do channel n??o
> > > > precisam
> > > > ter a mesma estrat??gia de hashing. Uma boa escolha em cada um dos
> > lados
> > > > pode compartilhar a carga da maneira mais equilibrada (mas nunca
> > iguais).
> > > >
> > > >
> > > >
> > > > Em 2 de fevereiro de 2015 18:11, Marcus Sandri <
> > marcus.sandri at ufscar.br>
> > > > escreveu:
> > > >
> > > >> Oi Carlos,
> > > >>
> > > >>      N??o ?? bem assim. Como esse problema ?? antigo, existem novas
> > > >> implementa????es que melhoram o desempenho e est??o habilitadas a
> > operar
> > > >> no switch HP 5500: "weighted round robin (WRR), weighted fair
> queuing
> > > >> (WFQ), weighted random early discard (WRED), weighted deficit round
> > > >> robin (WDRR)". Al??m do mais, balanceamento n??o ir??
> necessariamente
> > > >> impactar na performance da rede. Acontece que isso depende de uma
> > > >> rela????o entre a quantidade de fluxos que o RR ir?? balancear e a
> > > >> qualidade de sua implementa????o.
> > > >>
> > > >>
> > > >> > Pessoal,
> > > >> >
> > > >> > A quest??o do round robin ?? simples. Se for tr??fego TCP/IP, como
> > > >> 99.9999%
> > > >> > do
> > > >> > tr??fego hoje ??, round robin causar?? falhas de ordena????o de
> > pacotes. O
> > > >> > tamanho do problema depende da qualidade das pilhas TCP das duas
> > > >> pontas,
> > > >> > mas haver?? impacto de performance com certeza. ?? quest??o de
> > saber se
> > > >> vai
> > > >> > ficar s?? ruim ou se vai ficar MUITO ruim.
> > > >> >
> > > >> > Quem quiser experimentar em redes reais, n??o deve ser dif??cil,
> > seria
> > > >> legal
> > > >> > postar os resultados aqui depois.
> > > >> >
> > > >> > *Carlos Ribeiro*
> > > >> > *S??cio*
> > > >> > Cel: +55 (31) 9303-3366
> > > >> > Tel: +55 (31) 3305-5620
> > > >> > Geral: +55 (31) 3305-5600
> > > >> > cribeiro at telbrax.com.br
> > > >> > www.telbrax.com.br
> > > >> >
> > > >> > Em 2 de fevereiro de 2015 12:25, Marcus Sandri
> > > >> <marcus.sandri at ufscar.br>
> > > >> > escreveu:
> > > >> >
> > > >> >> Oi Kalil,
> > > >> >>
> > > >> >>           D?? uma olhada nesse documento anexo. Pag. 3.
> > > >> >>
> > > >> >>
> > > >> >> *PS: Acabei de ver tamb??m na pag. 3 que por padr??o o HP 5500
> > suporta
> > > >> >> diversos tipos de round robin:
> > > >> >>
> > > >> >> "weighted round robin (WRR), weighted fair queuing (WFQ),
> weighted
> > > >> >> random
> > > >> >> early discard (WRED), weighted
> > > >> >> deficit round robin (WDRR)"
> > > >> >>
> > > >> >>
> > > >> >> > Bom dia Marcus.
> > > >> >> >
> > > >> >> > Onde encontro documenta????o do HP 5500 mostrando isso?
> > > >> >> >
> > > >> >> > Tentei ver no documento que esta na Internet, oficial e
> refente a
> > > >> este
> > > >> >> > equipamento, e n??o encontrei nada.
> > > >> >> >
> > > >> >> > Atenciosamente,
> > > >> >> >
> > > >> >> >
> > > >> >> > 2015-02-01 21:38 GMT-03:00 Marcus Sandri <
> > marcus.sandri at ufscar.br>:
> > > >> >> >
> > > >> >> >> Pode ser fluxos de protocolos L3, L4, como tamb??m em L2.
> Como o
> > > >> >> >> controlador ?? program??vel, ent??o voc?? consegue balancear
> > > >> modificando
> > > >> >> a
> > > >> >> >> tupla que o round robin ir?? escalonar. Como exemplo, o
> > > >> balanceamento
> > > >> >> por
> > > >> >> >> fluxos L3 & L4 utiliza a tupla-5 (IP_o, IP_d, Porta_o,
> Porta_d,
> > > >> >> >> Tipo_de_proto). Mas veja que se voc?? modificar a tupla para
> > MAC, o
> > > >> >> >> balanceamento ser?? em L2.
> > > >> >> >>
> > > >> >> >>
> > > >> >> >>
> > > >> >> >> > Mas isso ?? balanceamento de fluxos e n??o de frames
> ethernet,
> > > >> >> confere?
> > > >> >> >> >
> > > >> >> >> > Enviada do meu iPhone
> > > >> >> >> >
> > > >> >> >> >> Em 31/01/2015, ??s 21:31, "Marcus Sandri"
> > > >> <marcus.sandri at ufscar.br
> > > >> >
> > > >> >> >> >> escreveu:
> > > >> >> >> >>
> > > >> >> >> >> ?? poss??vel com os HP 5500. N??o sei se no pr??prio
> switch,
> > mas
> > > >> voc??
> > > >> >> >> pode
> > > >> >> >> >> usar o m??dulo OpenFlow dele
> > > >> >> >> >> e rodar um controlador com round-robin (Anexa a
> > especifica????o
> > > >> do
> > > >> >> SW).
> > > >> >> >> >>
> > > >> >> >> >> *Existe um problema j?? comentado que o round-robin possui
> > > >> falhas.
> > > >> >> Na
> > > >> >> >> >> verdade isso acontece pelas colis??es no algoritmo hash.
> > Ent??o,
> > > >> ele
> > > >> >> ??
> > > >> >> >> >> muito
> > > >> >> >> >> dependente da implementa????o. O bom ?? que com o OpenFlow,
> > voc??
> > > >> pode
> > > >> >> >> usar
> > > >> >> >> >> algumas implementa????es mais modernas (ex.: WRR (1)).
> > > >> >> >> >>
> > > >> >> >> >>
> > > >> >> >> >>
> > > >> >> >> >> (1) http://g33kinfo.com/info/archives/2657
> > > >> >> >> >>
> > > >> >> >> >>
> > > >> >> >> >> --
> > > >> >> >> >> Cheers,
> > > >> >> >> >>
> > > >> >> >> >> Marcus Sandri
> > > >> >> >> >> Researcher (Msc.),
> > > >> >> >> >> Department of Computing
> > > >> >> >> >> UFSCar - Federal University of S??o Carlos
> > > >> >> >> >>
> > > >> >> >> >> dcomp.sor.ufscar.br/sandri
> > > >> >> >> >> Skype: marcus.sandri
> > > >> >> >> >>
> > > >> >> >> >> --
> > > >> >> >> >> gter list    https://eng.registro.br/mailman/listinfo/gter
> > > >> >> >> >
> > > >> >> >> >
> > > >> >> >>
> > > >> >> >>
> > > >> >> >> --
> > > >> >> >> Cheers,
> > > >> >> >>
> > > >> >> >> Marcus Sandri
> > > >> >> >> Researcher (Msc.),
> > > >> >> >> Department of Computing
> > > >> >> >> UFSCar - Federal University of S??o Carlos
> > > >> >> >>
> > > >> >> >> dcomp.sor.ufscar.br/sandri
> > > >> >> >> Skype: marcus.sandri
> > > >> >> >>
> > > >> >> >>
> > > >> >> >>
> > > >> >> >> --
> > > >> >> >> gter list    https://eng.registro.br/mailman/listinfo/gter
> > > >> >> >>
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> > --
> > > >> >> > Atenciosamente,
> > > >> >> > Kalil de A. Carvalho
> > > >> >> >
> > > >> >>
> > > >> >>
> > > >> >> --
> > > >> >> Cheers,
> > > >> >>
> > > >> >> Marcus Sandri
> > > >> >> Researcher (Msc.),
> > > >> >> Department of Computing
> > > >> >> UFSCar - Federal University of S??o Carlos
> > > >> >>
> > > >> >> dcomp.sor.ufscar.br/sandri
> > > >> >> Skype: marcus.sandri
> > > >> >>
> > > >> >> --
> > > >> >> gter list    https://eng.registro.br/mailman/listinfo/gter
> > > >> >>
> > > >> >
> > > >>
> > > >>
> > > >> --
> > > >> Cheers,
> > > >>
> > > >> Marcus Sandri
> > > >> Researcher (Msc.),
> > > >> Department of Computing
> > > >> UFSCar - Federal University of S??o Carlos
> > > >>
> > > >> dcomp.sor.ufscar.br/sandri
> > > >> Skype: marcus.sandri
> > > >>
> > > >>
> > > >> --
> > > >> gter list    https://eng.registro.br/mailman/listinfo/gter
> > > >>
> > > >
> > >
> > >
> > > --
> > > Cheers,
> > >
> > > Marcus Sandri
> > > Researcher (Msc.),
> > > Department of Computing
> > > UFSCar - Federal University of S??o Carlos
> > >
> > > dcomp.sor.ufscar.br/sandri
> > > Skype: marcus.sandri
> > >
> > >
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>