Concordo e ainda acrescento algumas coisas.
Luiz Gustavo wrote:
"Eumetheus" <[EMAIL PROTECTED]> writes:
No total, teremos perto de 60 usu�rios, acessando o mesmo banco de
dados, pelo menos durante 12 horas por dia. Ainda temos revendedores
no brasil inteiro, que somando d� em torno de 300 usu�rios.
Tenha em mente que vc tb precisa de um sistema de replicacao e failover
robusto.
Talvez seja interessante ter dois servidores no ar, um fazendo replica��o para o outro,
caso o sistema de banco de dados suporte. Isto � mais eficiente que backup, pois pode-se
ter uma frequ�ncia de replica��o alta, o outro servidor poderia ser colocado no ar assim
que o prinmcipal ca�sse.
Nao esqueca da infraestrurura a qual essa maquina sera ligada, se vc se importa com alta disponibilidade.
Leia a man page tuning com afinco, boas dicas por exemplo de quais
parametros eh recomendado a criacao de um filesystem para banco de
dados.
Se o banco de dados suportar, n�p crie file system. D� uma parte do disco inteira para
ele. Isto tira o overhead do file system. Melhor ainda. tenha um disco de sistema e um ou
mais de dados. E d� os discos de dados inteiro para ele, se poss�vel sem fazer particionamento,
se o banco de dados suportar isto.
Haver� updates, selects e mais selects, inserts, deletes o tempo todo.
Nao creio que existam DBAs por aqui com bons conhecimneto sobre MySQL ou Postgres, tenha um a mao(mesmo que seja de Oracle).
Vc precisa de alguem para ficar constantemente fazendo manutencao do banco, criando indices e te passando informacoes.
H� algumas selects que envolvem at� 6 tabelas diferentes.
O total de registos � algo estimado em 300.000.
N�o � um banco de dados grande. Onde eu trabalhei, na Biblioteca Nacional, um
dos bancos tinha carca de 350 mil, e sempre crescendo. O de peri�dicos era grande
tamb�m (na ordem de 300 mil se n�o me engano, com mais de 100 mil obras) e usava
o isis num Xeon dual 550 MHz, sempre sobrando m�quina.
Tenho uma rede de 100 Mbits operante e link dedicado com a Internet de
512Kbps para tal tarefa.
Vai sobrar m�quina.
Eu sugiro uma plica��o https, e n�o permitir que acessem direto ao banco de dados.
� mais seguro, com muitos logs, e impede qualquer transfer�ncia de bando de dados
inteiro, caso encontrem algum problema no banco de dados. Mas os programas tem que
ser bem feitos, para impedir ataques, inclusive o de pedir o banco de dados inteiro.
O Postgres suporta SSL, dependendo da sua aplicacao seria interessante fazer uso dele. Fazendo talvez um polling de conexoes para diminuir o overhead.
Minha pergunta � se a configura��o que coloquei � adequada para um
servidor aguentar uma estrutura deste porte. H� que me sugeriram foi:
Placa M�e Asus SK8N (SATA, Firewire, Som) Athlon XP Processador AMD
Opteron 240 1,4Ghz 2 x Mem�ria 512MB DDR 400MHz Gabinete Solid
Tunning - Preto (ATX) Fonte ATX 400W P4 e XP DRIVE CD ROM 52X -
CRD-8523B Black OEM Floppy Drive de 1.44 Interno - FDD Black Placa
Controladora SCSI Adaptec 29320 HDD SCSI WIDE 36.7GB ST3336607LW
320MB/s 10.000rpm Mouse e Teclado Satellite - Black
Acho muito desktop essa ``configuracao'', eis a minha sugestao:
- Creio que a Tyan tenha placa-mae para Opteron com pedigree de
servidor, asus nao eh exatamente um sinomino de robustez e
desaconselhavel no seu caso.
- Use RAID via hardware usando placas com suporte conhecido
(ICP-Vortex). Pesquise.
N�O use a RAID da Intel. A minha experi�ncia � que � uma M...., um lixo. N�o funciona
direito, parece qeu de vez em quando d� pane no RAID, e tem que reconstruir. Elas parecem
que piufam, ou o driver feito pela Intel, para o FreeBSD, n�o funciona. A minha experi�ncia
com elas foi traum�tica. EU recomendo que n�o use. Fora que � um porre de configurar. Com
o setup dela s� se consegue fazer um RAID. N�o sei se a Intel aprendeu, mas as controladoras
que tinham no meu antigo trabalho foram compradas em 2001, e nunca funcionaram bem.
Por outro lado, eu tive uma experi�ncia sensacional, mas curta em FreeBSD, com as Adaptec
2100S. Claro que sugiro que use um modelo melhor, mas se s�o tranquilas como esta, voc� est�
feito. A controladora listava os HDs que ela reconheceu e tinah um menu para criar RAID. Nele
ela perguntava qual HD deveria participar do RAID. Uma vez escolhidos e terminado o RAID,
voc� podia come�ar outro RAID. Era MUITO f�cil e r�pido.
- Entenda os tipos de RAID diferentes e pesquise qual vai se adequar
melhor ao seu setup.
Resumo r�pido:
RAID 0: entrela�amento de discos. pane em um, perda de tudo. MUITO r�pido, especialmente
para leitura e escrita de blocos grandes. O espa�o de todos os discos � aproveitado.
RAID 1: Espelhamento. R�pido em leitura. Quase t�o r�pido em escrita. Se a controladora fizer
uns golpes meio baixos, pode ser muito r�pido em leitura, especialmente de grande quantidade de
pequenos dados. O golpe baixo seria dividir a carga de leitura entre os discos. Metade dos discos �
usado no espelhamento.
RAID 5: Bom na leitura, possivelmente parecido com o RAID 0. Paridade espalhada. Perde um
disco. Inferno para a escrita de blocos pequenos, pois as leituras implicam em escritas. Desaconselho
para bancos de dados, apesar de ver "profissionais" (eu os classificaria mercen�rios de compet�ncia
duvidosa) usarem para este fim. Nos testes que fizemos no meu antigo trabalho se mostrou ruim em
bancos de dados. Eu aconselho para armazenamento de dados, tipo web server, ftp server.
RAID 10, ou 1+0: Tenta juntas as vantagens do 0 e do 1. S�o dois conjuntos de discos entrela�ados,
sendo que um � o espelho do outro.
- Gabinete rackmountable com fonte de qualidade.
Se poss�vel, redundante, com mais de um cabo de alimenta��o, que podem estar ligados em no-breaks
diferentes, caso queira um n�vel alto de redund�ncia.
- Memoria ECC e de marca confiavel.Podem ser duas m�quinas iguais e mais alguns HDs extras. De vez em quando pode "rotacionar"
- Um sistema de refrigeracao robusto, lembre-se que ar condicionado tb
falha.
- Tenha hardware sobresalente a mao, eh realmente muito chato ficar
esperando fornecedor ou acabar comprando produtos sub-standard.
um HD, especialmente se for hot swap. De noite, quando a m�quina ser� subutilizada, retire um HD,
e coloque um outro. Depois teste o retirado em outro micro, testando a superf�cie. As controladoras da
Adaptec tem este recurso em BIOS. Se for encontrado erro na superf�cie do HD, reformate-o e teste
de novo.
- Nao se esqueca do backup.Um mirror e um backup � melhor ainda. Mas n�o confie muito em fitas. Eu j� cansei de ter problemas
com fitas.
- Monte um ambiente de teste, crie uma base imaginaria com milhares de
registros e de bastante porrada. Tenha em mente que Murphy era um
otimista.
Um antigo amigo meu falava que Murphy n�o era lei. Era uma alma penada que vagava procurando
o que fazer dar errado. E eu digo que � a lei m�xima que rege o universo.
Dependendo dos resultados:
- Tenha um HD somente para os indices.
- Compre o maximo de RAM possivel(cache cache) e configure o BD para
fazer uso dela.
M�ximo de mem�ria, mas evite lotar todos os slots de mem�ria, sen�o pode ter problemas no futuro.
Quero usar o FreeBSD nesta m�quina. Alguma recomenda��es de vcs?
Eh uma escolha interessante, mas eu prefiro o postgres ao mysql.
Acho que vc ja tem algo para comecar pelo menos e repare o qto ainda falta para ser discutido. :)
Jo�o Rocha.
_______________________________________________________________ Sair da Lista: http://lists.fugspbr.org/listinfo.cgi Historico: http://www4.fugspbr.org/lista/html/FUG-BR/
