[MASOCH-L] Server para RADIUS e DB

[Claudio Junior]

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
>