[GTER] rede 40G para vmware e gbic qsfp+

Mon Oct 3 13:27:49 -03 2016

> On 03/10/2016, at 10:45, Eduardo Schoedler <listas at esds.com.br> wrote:
> 
> Em segunda-feira, 3 de outubro de 2016, Fernando Frediani <
> fhfrediani at gmail.com> escreveu:
> 
>> 
>> Tem um case conhecido na NANOG em que a pessoa descreve o uso de ServerU
>> L-800 com portas de 40G e picos se não me engano de 11Gb. Alguém se lembra
>> qual marca de placa foi utilizada ?
>> 
> 
> Chelsio T580-CR
> https://mailman.nanog.org/pipermail/nanog/2015-May/075351.html
> 
> Forwarding todo em hardware.

Fernando / Eduardo,

Sim, esse cliente especificamente usa a T580-SO-CR no caso. Ambas tem forwarding por hardware, line rate sem encostar na CPU. Pra atividades como roteamento, firewall, as chelsio -SO-CR tem melhor custo beneficio (Stateless Offload), as que tem os offload stateful são importantes pros outros recursos, normalmente associados a virtualizacao, data center, HPC, infiniband etc.

Nós não “anunciamos” a L-800 com portas 40G porque não faz sentido, na prática. A L-800 não tem torque pra empurrar mais do que 5.5G sem netmap e sem DPDK, ou seja 2x10G ou 4x10G é a melhor combinação de densidade de portas e capacidades que faz sentido. Claro que dependendo do cenário tem quem precise de 2x40G mas é bem específico e ai informamos que até pode, mas é uma completa subutilização das portas por “falta de torque” da caixa.

Outro ponto que surge muito interesse, e-mails em particular, é sobre o roteamento direto no ASICS.

Funciona muito bem pra OSPF, rotas estáticas e afins. Esse cliente em específico que é da SU America, é um cliente que usa uma versão de um daemon “experimental” do ProApps. As Chelsio tem um limite de 2000 “regras” que podem ser escritas no firmware nas -SO-CR e “10.000” nas com memória externa. Em ambos os casos, é suficiente pra 90% dos casos de uso, mas pra BGP não. Cada regra de roteamento tem que ter uma rule no firmware. Ou seja, com isso temos limite de 2k ou 10k rotas instaladas direto no ASICS.

O que nós fazemos em alguns casos, incluindo esse cliente, é usar um mecanismo parecido com o que temos no netmap-rt, onde algumas threads do daemon atuam em modo monitor e ficam aguardando o daemon BGP escrever as rotas na FIB, e quando isso acontece nós consultamos a FIB e olhamos o routing counter, que o kernel do FreeBSD tem, indicando quantas vezes cada rota foi usada. Com base nesses eventos, periodicamente o que nós fazemos é elencar as 10k ou 2k rotas mais “populares” que usam portas ou vlans chelsio, e esse daemon escreve essas rotas no ASICS.

Claro que na prática, alivia muito, afinal 2k rotas mais “usadas” representam por baixo 80% do que o roteador faz em frequência / pps, então é essa a taxa de offload que se consegue. Essa thread ao levantar o route count tem que considerar que só pode instalar nas chelsio o que envolve chelsio com chelsio. Ou seja as rotas que envolvam as portas 1G Intel da ServerU tem que continuar em kernel, fora do ASICS, mesmo que sejam populares.

Outro ponto é que a convergência de rotas na Chelsio é bem mais lenta, enquanto a gente coloca 600k rotas na FIB em um tapa, no ASICS levo ate 30 segundos pra 2k rotas. A consequência é que funciona bem em ambientes com BGP mais “calmos” onde existe certa estabilidade e as mensagens de UPDATE ou WITHDRAW não acontecem na pancada (ja que um update ou remoção de rota, se estava na Chelsio, tem que ser feito na hora, não pode esperar). Mas em situações com BGP caindo, subindo, o tempo todo, a potencial demora pra tirar a rota do ASICs pode implicar em problema, mais expressivo do que a demora em rever as novas rotas mais populares.

Portanto, infelizmente, não chegamos em um meio termo pra ter uma solução profissional e ofertar / divulgar o roteamento em ASICS para ambiente BGP, poucos clientes usam, alguns tiveram problemas e preferiram tirar e ficar só em kernel ou netmap. Outros continuam usando e estão felizes da vida roteando 8Mpps, 9Mpps com 2 ou 3 sessões BGP estáveis e fazem até a propaganda boca-a-boca que é esse caso na NANOG. Mas está longe de ser “one size fits all”.

Achei importante esclarecer aqui porque muita gente vem até nós e quer usar isso também que os satisfeitos estão usando. Podem ser que voce goste do resultado, pode ser que não seja viável, cada caso é um caso pra BGP FULL multihomed. Claro que tem aqueles casos que o cidadão tem BGP FULL mas um partial seria suficiente, casos que tem PTT + um FULL com uma operadora só (que portanto deveria ser default route mas é “chique” ter full, nesses casos todos o cenário é altamente viável e o índice de satisfação com o resultado é alto. Mas claro, de novo, não se aplica a todos.

Outra solução porém que tem se tornado muito popular la fora, é o uso do vRouter 5600. Me parte o peito ehhauhauha eu preferiria poder ja estar nesse nível com o netmap-rt mas ainda não estamos, o vRouter porém está muito estável e maduro. Olha os números:

http://www.serveru.us/en/netmapl800 (Performance => Routing performance)

- ProApps, FreeBSD, pfSense	2.89Gbit/s forwarding rate on DUT1; 1.35Mpps/s forwarding rate on DUT1;
- Linux (RHE & Fedora)	2.89Gbit/s forwarding rate on DUT1; 1.35Mpps/s forwarding rate on DUT1;
- Brocade vRouter 5600 (DPDK)	23Gbit/s forwarding rate on DUT1; 6.8Mpps forwarding rate on DUT1;

Não, esses números não são “números mágicos do comercial”, não é propaganda política. São reais, e essa taxa é a real conseguida em vários provedores e empresas nos EUA, Canada, México e Australia. E sim a diferença é gritante, de 1.3Mpps (2.7Mpps com portas 10G) em FreeBSD/Linux pra 6.8Mpps, de 2.9Gbps (5.6Gbps máximo, com expansões 10G) pra 23Gbit/s.

O trabalho que a Brocade fez no Vyatta ao rescrever o dataplane em DPDK é de impressionar, e o vRouter 5600 entrega isso tudo com DPDK. Com netmap-rt eu consigo entregar mais que isso hoje, mas ainda não é um produto pronto/estavel, consideramos ele ainda experimental:

http://support.serveru.us/index.php?/ServerU/Knowledgebase/Article/View/91/20/proapps-routing-in-netmap-mode-with-netmap-rt

Nos EUA a Brocade certificou a L-800 como “bare metal” compatível, e a ServerU suporta o vRouter oficialmente, inclusive com uma imagem propria, os drivers de bypass, LCM ja instalados e o dataplane “unshielded” (que é uma proteção contra sobrecarga e bugs nos Hypervisor pra evitar que todas as vCPU fiquem dedicadas ao dataplane e falte CPU pro control plane e kernel mesmo com affinity). Na L-800 não precisa desse CPU Shield e tem máxima performance quando vem unshielded. o vRouter 5600 pra L-800 ja vem “pronta” bastando a pessoa entrar com a licença trial ou a definitiva se resolver usar.

Ainda não divulgamos pesado no Brasil essa possibilidade, mas fica a consideração. O custo do vRouter 5600 está na casa de 6k dólares. Não é a coisa mais cara do mundo, mas não é uma decisão de olho fechado também. Por outro lado os 30 a 90 dias de trial com o 5600 permitem tomar essa decisão com segurança.

Por motivos exclusivamente comerciais, o vRouter 5600 ainda não funciona em Chelsio, só Intel.

Em 100% dos casos que esses clientes estão usando vRouter 5600 com ServerU, são pessoas que vem de VyOS e ja estavam acostumados, e procuram um roteador “bare metal” certificado pro vRouter. Em diversas revendas nos EUA em especial os distribuidores Brocade da Costa Oeste, eles ja recomendam ServerU. A ServerU em contra-partida não é integradora Brocade então quem decide comprar o vRouter compra com os parceiros Brocade e quem quer metal e não vCPU compra ServerU. Tem funcionado bem.

Então, estou aproveitando esse e-mail (inclusive erroneamente até numa thread inadequada hehe, de tanto que fugiu do assunto) pra tentar elucidar esses “use cases” possíveis, com ServerU + alta performance. Que da pra sumarizar:

1) ServerU + Chelsio + Roteamento no ASICS: limitado a 2k ou 10k rotas no ASICS, até 30s pra convergência total, adequado pra OSPF, estatico e setups BGP mais simples, line rate garantido (ou 13Mpps pra ser honesto, 14.8Mpps na Chelsio só com portas individuais - sem rotear entre si e sem bridge).

2) ServerU + Chelsio/Intel + Roteamento Netmap com netmap-rt: grandes taxas, grandes numeros, ainda prematuro/preliminar. É uma solução em estado -BETA sendo ativamente trabalhada.

3) ServeU + Mellanox: não tem benefício nenhum, prefira Chelsio. Maior compromisso com Netmap, com drivers nos SOs, e offload comprovadamente funcional em Linux/BSD.

4) ServerU + FreeBSD/Linux kernel-path (leia-se Linux/VyOS/BSDRT/FreeBSD/ProApps, etc): estável, bom pra até 5.6Gbit/s e 2.7Mpps (requer expansões de 10 pra conseguir esses numeros, claro)

5) ServerU + Intel DPDK + Brocade vRouter 5600: sonho de consumo (literalmente), espero um dia chegar nesse nível com netmap-rt, taxas até 6.8Mpps/23Gbit/s, estável, poucos bugs (que eu saiba tem umas coisas irritantes no firewall do vRouter, mas pra roteamento sem notícia de problemas), custo de software expressivo (~6k Obamas licença pra 3 dataplanes/vCPUs).

6) ServerU + Chelsio DPDK +  Brocade vRouter 5600: ainda não suportado oficialmente. Se voce instalar na unha o driver de Linux no vRouter, o dataplane reconhece, e usa, a performance chega a 8Mpps, mas não é oficialmente suportado pela Brocade então o risco é seu. Não temos clientes que toparam o risco, nenhum foi pra produção com Chelsio só o que temos são números de laboratório. É promissor, tomara que a Brocade faça isso.

Abraços.

--
Patrick Tracanelli

FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
316601 at sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"