[GTER] Servidor PPPoE - Accel-PPP

Marcelo Gondim gondim at bsdinfo.com.br
Fri Dec 1 17:40:31 -02 2017


Em 28/11/2017 18:20, Rubens Marins Schner escreveu:
> 2017-11-28 14:53 GMT-03:00 André Carlim <andre at stubnet.info>:
>
>> Antes de mais nada, só quero saber se o amigo aqui já teve experiência com
>> linux e pppoe em larga escala?
>>
>>
>> Concordo plenamente, se estiver usando placa de rede "realtreco" ou
>> aquelas intel pro/1000! Com boas placas de rede isso é eliminado.
>
> Claro que já é implicito que para isso você vai usar um placa de rede "boa".
> O problema não é placa de rede, e sim a velocidade de copia do cabeçalho da
> placa de rede para a CPU, e a velocidade que a CPU demora para decidir o
> que fazer com o pacote.
>
> Com placas de rede que usam o driver igb ou tg3 é só NÃO usar o irqbalance
>> e fazer o irq affinity manualmente que vai funcionar perfeitamente!
>>
> Vai funcionar perfeitamente até o limite de processamento de 1 Core, o que
> nesse caso, não é um limite lá muito alto.
Que 1 core? Rapaz você não conhece de cpu affinity e agora tenho certeza 
disso.
Dá uma estudade em MSI-X. Vou te dar um exemplo:

Essa máquina está usando 3 portas de 10GbE. Possui 2 processadores 
físicos (12 cores). O -l é o core que estou setando e o -x é a 
interrupção da interface de rede.
Ou seja estou dizendo que as interrupções 268,269,270 e 271 da interface 
ix0 vão rodar nos cores 11,10,9 e 8. O mesmo com as outras interfaces.

# ix0
/usr/bin/cpuset -l 11 -x 268
/usr/bin/cpuset -l 10 -x 269
/usr/bin/cpuset -l 9 -x 270
/usr/bin/cpuset -l 8 -x 271

# ix2
/usr/bin/cpuset -l 7 -x 280
/usr/bin/cpuset -l 6 -x 281
/usr/bin/cpuset -l 5 -x 282
/usr/bin/cpuset -l 4 -x 283

# ix3
/usr/bin/cpuset -l 3 -x 285
/usr/bin/cpuset -l 2 -x 286
/usr/bin/cpuset -l 1 -x 287
/usr/bin/cpuset -l 0 -x 288

Um vmstat do sistema:

(root at seca)[~]# vmstat -i
interrupt                          total       rate
irq9: acpi0                            4          0
irq22: ehci1                     9321813          2
irq23: ehci0                    19500423          5
cpu0:timer                    4781182208       1127
irq264: bge0                 12235018336       2883
irq268: ix0:q0               30090871472       7091
irq269: ix0:q1               28918911733       6815
irq270: ix0:q2               28731698864       6771
irq271: ix0:q3               28691294877       6762
irq272: ix0:link                       1          0
irq278: mfi0                     5452952          1
irq280: ix2:q0               77479593937      18260
irq281: ix2:q1               73920356915      17421
irq282: ix2:q2               73186702342      17248
irq283: ix2:q3               73337242508      17283
irq284: ix2:link                       1          0
irq285: ix3:q0               79754713516      18796
irq286: ix3:q1               79716548778      18787
irq287: ix3:q2               80650864060      19007
irq288: ix3:q3               78833201010      18579
irq289: ix3:link                   20215          0
cpu10:timer                   4762182284       1122
cpu3:timer                    4776187867       1126
cpu2:timer                    4776017299       1126
cpu8:timer                    4757861309       1121
cpu9:timer                    4757901234       1121
cpu6:timer                    4779647797       1126
cpu11:timer                   4762990535       1122
cpu7:timer                    4779637761       1126
cpu4:timer                    4780154439       1127
cpu1:timer                    4776784905       1126
cpu5:timer                    4780301620       1127
Total                       802852163015     189207



>
> Bom, aqui não pude entender mesmo o objetivo do comentário, com um pouco de
>>> tempo qualquer um faz CGNAT (ou seja lá qual for) usando iptables...
>>>
> O problema não é saber o comando de Iptables, é a caixa que já esta no
> gargalo fazendo controle de banda, agora precisar fazer NAT, que também é
> feito em CPU.
>
> E você não consegue fazer o controle de banda em um core e NAT em outro
> core, depois que setou o CPU affinity já era.
> Até por que o NAT precisa esperar o controle de banda decidir se vai
> transmitir o pacote ou não, antes de operar o mascaramento. Esse baile não
> da para dançar em dois cores separados.
> Não dá para fazer a divisão de pacotes por cores, os pacotes da mesma
> conexão precisam sair mais na mesma ordem que chegaram, pacotes fora de
> ordem vai tornar Voip e Jogos online inviaveis.
>
> O problema é Hardware

Olha você realmente deve ter tido muito problema com isso. Não sei 
porque você teve mas ainda bem que aqui funciona bem. rsrsrsrs
Realmente com hardware errado, tudo dá errado e pelo que to vendo você 
só escolheu hardware errado nessa vida.

Eu já vivi casos que com o hardware errado dava problemas até com 
300Mbps, casos onde dava problemas com 2Gbps e hoje tenho hardware 
suportando quase 6Gbps e com muita folga.
Existem soluções como da Brocade onde você tem servidores Dell usando 
solução Linux + DPDK com tráfego próximo dos 80Gbps. Então não vejo 
desse modo como você vê. Vejo que existem limitações assim como qualquer 
arquitetura, basta usar o equipamento certo. Tudo vai da necessidade e 
do custo x benefício.



>
>
> Rubens Marins
> Administrador de Sistemas
> rubens.marins at gmail dot com
>
>
> 2017-11-27 20:46 GMT-03:00 André Carlim <andre at stubnet.info>:
>
> Pessoal sei que é meio contra producente o que vou fazer aqui, mas eu
>> limitado a recursos para testar o potencial das ultimas mudanças que fiz no
>> meu esquema de PPPoE. Alguns clientes grandes que estava atendendo acabaram
>> migrando para Cisco/Juniper e fiquei na mão! Todavia, queria saber se
>> alguém topa usar e medir o quanto pode ser útil essa estrutura. Eu penso na
>> faixa que fica entre as CCRs e um Juniper, nos provedor que tem algo em
>> torno de 6000 ~ 9000 clientes. Sei que com essa quantidade já da pra pensar
>> nessas caixas, mas acho atrativo o baixo custo que o Debian + Accel-PPP
>> podem trazer para quem quer atender umas 7000 sessões PPPoE em no máximo
>> dois servidores (que nem precisa ser servidor mesmo). Eu já tive por
>> algumas vezes experiência de rodar até 2200 sessões PPPoE sobre um Core i3
>> com uso de processador abaixo de 15% e banda próxima a 1Gbit. Se alguém se
>> interessar estou a disposição!
>>
>> --
>>
>> Atenciosamente,
>> André Carlim
>> StubNetwork
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
>> --




More information about the gter mailing list