[GTER] Sugestão BRAS/NAS

[Douglas Fischer]

 Agoooooora...

Eu ficaria animado em ver um case assim em x86 virtualizado.
Seja de IPoE ou de PPP.

Pelas mágicas que andei vendo por aí, não seria difícil de imaginar que 3
Servers com 2 pastilhas e 22 cores cada poderiam tocar isso.
Considerando a redundância N+1 e muita folga...

Em ter, 4 de set de 2018 às 10:17, Douglas Fischer <fischerdouglas at gmail.com>
escreveu:

> Teve um amigo que teve a infelicidade de ter que complementar a operação
> de uma operadora média com um paredão de MK...
> Ele ficou de cabelo branco, corcunda, enrugado, ranzinza...
>
> Hoje eu sei que ele tá feliz com 2 RedBack fazendo todo o B-RAS deles.
> Ficou uns 15 anos mais jovem depois da virada.
>
>
>
> Em ter, 4 de set de 2018 às 10:05, Douglas Fischer <
> fischerdouglas at gmail.com> escreveu:
>
>> Brunão...
>> Aprendi a remover minha aversão automática ao MK.
>> Mas vamos combinar que esse não é o cenário para um paredão de CCR.
>>
>> Que dá pra fazer dá! Mas vamos fazer umas contas?
>> Se forem 1036, no perfil de cliente que o Guilherme falou(30Mbps ou mais)
>> pra cada uma segurar 1.000 sessões teria que fazer "o" malabarismo e mesmo
>> assim, acho que não vai dar para ela... Seriam 50(cinquenta) Caixas!
>> Nominal dela é 60W. Considerando 45W cada -> 2,250W.
>>
>> Mais uns 4 Switchs para suportar o número de portas agregadas.
>> (não pense que 1.000 sessões a 30Mbps vão passar em uma porta de 1Gb).
>> Só em energia uns 3Kva.
>>
>> Se falar em trocar tudo isso por 3 x MX204, o que consta no datasheet é
>> nominal de 260W, o que daria +/- 750W.
>>
>> Só considerando a energia de alimentação e energia gasta em
>> climatização...
>> A conta já não fecha.
>>
>> Se adicionar a complexidade de gerenciamento, problema de roteamento
>> interno pulverizado, etc...
>> Acho que nem precisa continuar, né?
>>
>>
>> Canhão para afundar navio!
>> Rifle para matar Cateto!
>> E mata-mosca para matar mosca.
>>
>>
>>
>>
>>
>> Em ter, 4 de set de 2018 às 09:27, Bruno Cabral <bruno at openline.com.br>
>> escreveu:
>>
>>> Nao necessariamente
>>>
>>> Cada porta com seu server, 600 a 2000 usuarios como limite por porta,
>>> dependendo do perfil dos seus planos
>>>
>>> Obviamente vai gastar bastante porta de switch
>>> ________________________________
>>> De: gter <gter-bounces at eng.registro.br> em nome de Guilherme Domingues <
>>> guilherme.domingues.oliveira at gmail.com>
>>> Enviado: segunda-feira, 3 de setembro de 2018 20:31:46
>>> Para: Grupo de Trabalho de Engenharia e Operacao de Redes
>>> Assunto: Re: [GTER] Sugestão BRAS/NAS
>>>
>>> Só se for dois racks inteiros de ccr né ?
>>>
>>> Em seg, 3 de set de 2018 18:51, Lucas Willian Bocchi <
>>> lucas.bocchi at gmail.com>
>>> escreveu:
>>>
>>> > Pilha de CCR não pode?
>>> >
>>> > Em seg, 3 de set de 2018 às 16:14, Guilherme Domingues <
>>> > guilherme.domingues.oliveira at gmail.com> escreveu:
>>> >
>>> > > Pessoal,
>>> > >
>>> > > Muitos colegas e amigos de telecom sugeriram aumentar porte da caixa
>>> e a
>>> > > distribuir a carga do PPPOE.
>>> > >
>>> > > Até ai achamos o plano interessante, mas até quando poderemos
>>> empilhar é
>>> > o
>>> > > que nos tange a nossa dúvida. Sem olhar preço ou marca e modelo,
>>> alguém
>>> > > indicaria algum chassi ou algo mais congruente para o crescimento das
>>> > > sessões pppoe ativas ?
>>> > >
>>> > > Temos em linha Juniper MX-204 (algumas caixas), mas precisamos
>>> demostrar
>>> > o
>>> > > plano B neste projeto.
>>> > >
>>> > > Att.
>>> > > Guilherme Domingues
>>> > > ---
>>> > > "A mente que se abre a uma nova idéia jamais voltará ao seu tamanho
>>> > > original."  Albert Einstein
>>> > > --
>>> > > 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
>>>
>>
>>
>> --
>> Douglas Fernando Fischer
>> Engº de Controle e Automação
>>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação