[MASOCH-L] Server para RADIUS e DB

[Herlon Matos]

Replicação e Recovery são essencial.


Em 30/08/2017 09:49, Claudio Junior escreveu:
> Hoje temos que levar em consideração que desempenho de servidor é fácil de
> atender. O custo da memoria e cpu não são mais tão grandes.
> O grande problema ao meu ponto de vista é o armazenamento físico.
> independente da solução, o ideal é vc ter contingencia que é um bom backup
> (e toda a politica de fazer o backup e processo de restore) e também os
> discos terem contingencia interna que conseguimos com esquemas de raid 1 -
> mirror que é muito arriscado, raid 10 (mirror + stripping) ou até mesmo os
> um pouco mais lentos mas bem mais seguros que são o raid 5 ou 6.
> Para armazenar informações recomendo algum storage que alem de ter o raid
> que vc configurar (mas que envolva mirror) tenha discos reservas no qual a
> plataforma suba automaticamente inserindo no raid em caso de necessidade e
> desative o disco problemático permitindo substituição online e com isto
> evitando o máximo possível indisponibilidade. Lembre-se que restaurar um
> backup é demorado e em alguns casos isto deve ser evitado.Isto tudo deve
> ser analisado, levando em conta, a quantidade de informação, tempo de
> acesso. Estou falando em teras de informação e não gigas que podem ser
> restaurados através de um HD externo via USB.
>
> Boa sorte pessoal
>
>
>
>
> --
> Claudio da Silva Junior
> csjunior at gmail.com
>
> Em 29 de agosto de 2017 18:41, Paulo Henrique <paulohenriquef at gmail.com>
> escreveu:
>
>> Concordo com os colegas e ainda acrescento mais uma dica quanto ao
>> "tunning" do banco, este é específico para o radius (freeradius na
>> verdade).
>> Se puder, separe a tabela radacct em duas.
>> Vou explicar: O freeradius já vem com a configuração mastigada para usar
>> duas tabelas para o acct, basta você alterar uma linha se não me engano na
>> configuração do sql.conf e criar as duas tabelas no seu banco, eu costumo
>> chamar de radacct_open e radacct_closed.
>> Como os nomes sugerem, a tabela radacct_open guarda as informações das
>> conexões ativas e a radacct_closed guarda as informações das conexões
>> encerradas. Com isso, a tabela radacct_closed pode crescer volumosamente
>> que não vai impactar tanto no desempenho total da solução. Certamente
>> haverão poucos inserts e algumas operações de leitura e isso "não deve" ser
>> com muita frequência.
>> Já a tabela radacct_open, dependendo do cenário, pode sofrer inserts e
>> updates com bastante frequência, mas isso não vai impactar de forma
>> significativa porque haverão apenas apenas alguns registros nesta tabela
>> (talvez algo com 4 ou 5 dígitos no máximo).
>>
>> Sugiro que dê uma olhada nisso também.
>>
>> Em 29 de agosto de 2017 18:22, Eduardo Rigler <erigler at gmail.com>
>> escreveu:
>>
>>> Em 29 de agosto de 2017 18:04, Andre Almeida <andre at bnet.com.br>
>> escreveu:
>>>> Beleza..... então ok, deixamos o SSD de lado.
>>>>
>>>> Pensando em custo X beneficio:
>>>> Qual hardware?
>>>>
>>> Como diria meu antigo chefe: "Seu dinheiro é o meu guia" :-)  Quanto tem
>>> pra gastar?
>>>
>>> Hoje acho que uma boa referência é o R630 + controladora Perc H730/P, mas
>>> dependendo do restante do hardware a brincadeira já começa nos 15~20k....
>>> pra rodar só 2 VMs é muito dinheiro.
>>>
>>> []´s
>>>
>>>
>>>
>>>
>>>
>>>> Att,
>>>> Andre Almeida
>>>> Em 29 de agosto de 2017 17:52, Herlon Matos <herlon at lcimt.com.br>
>>>> escreveu:
>>>>
>>>>> Penso como o Leonardo, analisar o banco de dados e efetuar os ajustes
>>> de
>>>>> performance rotineiramente é o que vale no processo.
>>>>> Utilizaria como ele disse discos SAS.
>>>>>
>>>>> Herlon Alcantara Matos
>>>>> LCI Telecom
>>>>>
>>>>>
>>>>> Em 29/08/2017 16:38, Leonardo Rodrigues escreveu:
>>>>>
>>>>>> Em 29/08/17 16:14, Andre Almeida escreveu:
>>>>>>
>>>>>>> A principio preciso de algo que seja rápido para processar esse BD
>> e
>>>> esse
>>>>>>> radius, pensei em algo com SSD, mas, não tenho ideia do que ir
>> atrás.
>>>>>>>
>>>>>>      Não tem SSD que conserta a performance ruim de uma base de dados
>>> mal
>>>>>> feita. O que eu já peguei de banco de dados 'morrendo' porque as
>>> tabelas
>>>>>> não tinham índices nos campos consultados, você não faz idéia. Já
>>> ganhei
>>>>>> muito dinheiro, sem nenhuma vergonha de dizer isso, criando índice
>> em
>>>> MySQL
>>>>>> porque o pessoal simplesmente esquece de criar índice em tabela com
>>>> 10-20
>>>>>> milhões de registros. E aí, vou te contar, não tem SSD nem outro
>>>> hardware
>>>>>> que faça isso ter performance !!!
>>>>>>
>>>>>>      Deixa SSD pra um segundo momento, um bom disco SAS tem ótima
>>>>>> performance e bem mais espaço.
>>>>>>
>>>>>>
>>>>>>
>>>>> __
>>>>> masoch-l list
>>>>> https://eng.registro.br/mailman/listinfo/masoch-l
>>>>>
>>>> __
>>>> masoch-l list
>>>> https://eng.registro.br/mailman/listinfo/masoch-l
>>>>
>>> __
>>> masoch-l list
>>> https://eng.registro.br/mailman/listinfo/masoch-l
>>>
>>
>>
>> --
>> Paulo Henrique Fonseca
>> paulohenriquef at gmail.com
>> __
>> masoch-l list
>> https://eng.registro.br/mailman/listinfo/masoch-l
>>
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l

-- 
*Herlon Alcantara Matos*
Gerente de TI
Avenida Ademar Raiter nº 320 - Centro
Fone: (66) 3545-4613 / (66) 99672-9428 / INOC-DBA 28213*100
Sorriso-MT