[GTER] Balanceamento round robin LACP em swtichs HP 5500

Carlos Ribeiro cribeiro at telbrax.com.br
Thu Jan 29 14:32:28 -02 2015


Shine,

Só para deixar mais claro, o buraco é mais embaixo, pois "round robin" não
é adequado para TCP/IP, pois há sempre o risco de mudar a ordem de chegada
dos pacotes. Mesmo com as melhorias do TCP, incluindo retransmissão
seletiva, há impacto de performance se houver quebra da ordenação.

Há equipamentos (ex: rádios N+1) que fazem o balanceamento com mecanismos
proprietários que preservam o ordenamento. Há também intercalamento a nível
de "bitstream" em tecnologias como 40 Gbps, mas isso está fora do alcance
do que se pode fazer em um switch ou roteador com os pacotes.

*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 27 de janeiro de 2015 22:59, Shine <eshine at gmail.com> escreveu:

> Kalil,
>
> Nos switches atuais é muito difícil ter um balanceamento LACP sem hashing
> baseado em protocolo. Muitos são ajustáveis, mas mesmo assim remover tudo e
> virar round robin é improvável nos chips atuais. Se você achar um que faça,
> possivelmente vai ter problemas quando precisar fazer upgrade para outros
> modelos mais modernos - a não ser que upgrade de rede não seja necessário
> no futuro, mas a maioria descarta essa possibilidade.
>
> Mesmo que não exista um protocolo IP, as switches vão usar mac-src, mac-dst
> e proto para determinar o hashing. O que poderia ser feito é a aplicação
> gerar dois fluxos distintos (por exemplo portas tcp ou udp distintas ou
> mac-src/dst), assim ao chegar no switch ele seria balanceado.
>
>
> Em 26 de janeiro de 2015 18:04, Kalil de A. Carvalho <kalilac at gmail.com>
> escreveu:
>
> > Boa tarde Carlos.
> >
> > Muito obrigado pelo esclarecimento.
> >
> > Gostaria de fazer uma outra pergunta, ainda nesse mérito:
> >
> > E se esta comunicação ocorresse na camada dois, somente com quadros,
> ainda
> > permaneceria esse comportamento?
> >
> > Os pacotes ainda poderão sofrer como descrito?
> >
> > Atenciosamente,
> >
> >
> > 2015-01-26 16:34 GMT-03:00 Carlos Ribeiro <cribeiro at telbrax.com.br>:
> >
> > > Kalil,
> > >
> > > Não se deve nunca, em nenhum hipótese, fazer "round robin" simples de
> > > pacotes. Entendo os seus motivos para querer fazer isso, eu também
> > gostaria
> > > muito de fazer nos meus links, mas é importante que você entenda porque
> > > isso não é possível, e nem mesmo desejável. E isso é geral, não é só
> com
> > > HP, mas com Cisco, Juniper, etc.
> > >
> > > Se você fizer distribuição "round robin", fatalmente terá situações em
> > que
> > > os pacotes chegarão do outro lado fora de ordem. Pacotes fora de ordem
> > > quebram a transmissão em TCP e confundem os controles de comunicação
> que
> > > usam UDP/RDP também, causando descartes de pacotes, retransmissões,
> etc.
> > > Isso acaba com a performance da rede.
> > >
> > > Existem duas situações que causam reordenação:
> > >
> > > 1) A primeira, e mais óbvia, é se os dois links tiverem tamanhos
> > > diferentes. Neste caso o delay de transmissão é diferente e isso pode
> > fazer
> > > com que um pacote que foi transmitido depois chegue antes ao destino.
> > >
> > > 2) A segunda situação, que não é tão óbvia e por isso "passa batido", é
> > > quando você tem dois links idênticos, só que os pacotes variam de
> tamanho
> > > fortemente. Com milhões de pacotes passando, é absolutamente certo que
> de
> > > vez em quando, você vai dar "azar" de colocar pacotes maiores em uma
> > > interface e menores na outra. Resultado: uma fila fica mais curta e
> > começa
> > > a andar mais rápido e os pacotes pequenos "passam na frente" dos
> grandes.
> > > Na hora que isso acontecer (e não se preocupe, vai acontecer
> > > "estatisticamente o tempo todo) dentro de uma conexão TCP ou pior
> ainda,
> > > com um fragmento IP, você terá um problema sério com perda de
> > performance.
> > >
> > > É por isso que os switches e roteadores tem vários algoritmos de
> > > distribuição de tráfego. É comum ter uma diferença variável, no máximo
> da
> > > ordem de 10% a 15% entre os dois links, não mais do que isso. Mas como
> > tudo
> > > é aleatório, você pode estar com uma distribuição pior. Mas não há o
> que
> > > fazer.
> > >
> > > Há soluções mais avançadas para isso, incluindo engenharia de tráfego e
> > > certos tipos de "source routing" (como é o caso do PBR da Cisco). Mas
> são
> > > apenas para contornar situações específicas, e agregam mais
> complexidade
> > ao
> > > cenário.
> > >
> > > Espero ter ajudado...
> > >
> > > *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 26 de janeiro de 2015 11:17, Kalil de A. Carvalho <
> kalilac at gmail.com>
> > > escreveu:
> > >
> > > > Bom dia senhores.
> > > >
> > > > Estou trabalhando com dois swichs HP 5500 e  temos uma agregação
> usando
> > > > LACP entre eles.
> > > >
> > > > Para nossa realidade precisamos que o balanceamento seja round robin.
> > > >
> > > > Foi tentada diversas combinações, como indicado no manual, source
> mac,
> > > > destination mac, ingress port etc mas em nenhuma resultou no que
> > > > esperávamos: distribuição igualitaria entre as portas.
> > > >
> > > > Pelo que pude entender quando se escolhe source  mac, a porta que
> > > aprender
> > > > o caminho com este mac ficara sempre recebendo por ela. Idem
> > destination
> > > > mac.
> > > >
> > > > É isso mesmo ou entendi errado?
> > > >
> > > > É possível fazer isso que queremos, round robin, nestes equipamentos?
> > > >
> > > > Atenciosamente,
> > > >
> > > >
> > > >
> > > > --
> > > > Atenciosamente,
> > > > Kalil de A. Carvalho
> > > > --
> > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> >
> >
> >
> > --
> > Atenciosamente,
> > Kalil de A. Carvalho
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



More information about the gter mailing list