[GTER] Balanceamento round robin LACP em swtichs HP 5500

[Shine]

Carlos,

Realmente aprecio seu comentário. Estou bem ciente das consequências da
inversão de pacotes e é exatamente por este motivo e das necessidades de
alta performance em ethernet (ainda mais na escala >10G) que os ASICS
atuais já implementam diretamente a agregação de portas em hardware com o
hashing.

Existem aplicações que não se importam com inversões de pacotes, apenas
precisam de dado bruto de forma que a ordem não importa tanto, desde que
exista. E inclusive rodando em cima de ethernet, nem camada IP é
necessário. Ou seja, são fluxos únicos puros.
Essas aplicações não se importam, mas ao mesmo tempo são exceções, então
fazer balanceamento e redundância também se torna complexo. Pode-se criar a
contingência criando redes em loop e fazendo controle de loop (STP), mas
essa alternativa já é conhecida pela relativa baixa eficácia de
convergência se comparado com soluções de link ativo-ativo.
Então eu sugiro que ao invés de seguirmos adaptando a rede, adaptar a
aplicação para o uso eficiente na rede. Embora traga um desenvolvimento
adicional da aplicação, isso acaba beneficiando na padronização da
comunicação da rede, assim o aplicativo não fica refém de uma estrutura de
rede fechada.

Espero ter esclarecido um pouco o que tinha em mente.

Em 29 de janeiro de 2015 14:32, Carlos Ribeiro <cribeiro at telbrax.com.br>
escreveu:

> 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
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>