[GTER] Balanceamento round robin LACP em swtichs HP 5500

Sat Jan 31 14:24:40 -02 2015

Lucas,

Isso só reforça a tese que quem determina se precisa de round robin ou não,
é a aplicação e não a rede.
Não existe verdade absoluta, o que é realidade hoje é que a maioria das
aplicações precisa de hashing por fluxo, que não são round robin, então se
existe uma aplicação onde o round robin faz mais sentido essa aplicação vai
ser penalizada pela arquitetura dos switches modernos que são voltados para
balancear em hashing por fluxo, sem programação para round robin. Assim, é
mais fácil desenvolver uma aplicação que faça uso de hashing por fluxo,
mesmo que seja fake (ou seja a aplicação não precisa) para que se possa
usar switches de mercado, senão fica-se refém de um modelo/marca (vendor
lock).

Em 29 de janeiro de 2015 20:14, Lucas Willian Bocchi <lucas.bocchi at gmail.com
> escreveu:

> Shine
>
> A implentação da pilha TCP/IP varia muito de sistema operacional para
> sistema operacional. OS/2 e minix por exemplo são chatíssimos com essa
> questão de recebimento de pacotes fora de ordem. Simplesmente a pilha
> do sistema descarta e manda retransmitir. Uma vez peguei um problema
> numa rede OS/2 que dei suporte que só pq os pacotes num router linux
> não estavam vindo com o timestamp correto marcado a conexão toda era
> derrubada.
>
> Quanto a questão das routerboards que falaram aqui, é fato que quanto
> maior o processamento maior a reordenação de pacotes. Existem regras
> no mangle que também fazem o negócio se perder, mas isso é bug do
> kernel que foi consertado em versões mais novas no linux. Os kernels
> da versão 6.x tá bem atrás, 3.6.1 se não me engano.
>
> Em 29 de janeiro de 2015 19:06, Shine <eshine at gmail.com> escreveu:
> > 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
> >>
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>