Jo�o...
Muito elucidativo!!!
Bem, de qualquer forma, eu queria implantar esse server no come�o de janeiro... mas j� vi que n�o vai dar, depois dos v�rios e-mails que recebi...
Creio que meu problema � bem mais dif�cil de resolver... e como o investimento � alto, acho melhor analisar, com a ajuda das respostas, o que tenho que fazer exatamente!
Mas mesmo assim, obrigado!
De nada. Pode contar com a lista.
Ia me esquecendo. Duas placas de rede podem ser �teis se for ter 2 servidores.
Use uma para falar com a rede, e a outra entre os servidores. Mas isto n�o � algo
muito importante.
Jo�o Rocha.
Alexandre Cirurgi�o-Dentista
----- Original Message ----- From: "Joao Rocha Braga Filho" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, December 15, 2003 2:00 AM Subject: Re: [FUGSPBR] Opteron + FreeBSD
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.
Vai sobrar m�quina.Tenho uma rede de 100 Mbits operante e link dedicado com a Internet de 512Kbps para tal tarefa.
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:
Acho muito desktop essa ``configuracao'', eis a minha sugestao: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
- 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.
Resumo r�pido:- Entenda os tipos de RAID diferentes e pesquise qual vai se adequar melhor ao seu setup.
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. - 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.
Podem ser duas m�quinas iguais e mais alguns HDs extras. De vez em quando pode "rotacionar" 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.
Jo�o Rocha.
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. :)
_______________________________________________________________ Sair da Lista: http://lists.fugspbr.org/listinfo.cgi Historico: http://www4.fugspbr.org/lista/html/FUG-BR/
_______________________________________________________________ Sair da Lista: http://lists.fugspbr.org/listinfo.cgi Historico: http://www4.fugspbr.org/lista/html/FUG-BR/
_______________________________________________________________ Sair da Lista: http://lists.fugspbr.org/listinfo.cgi Historico: http://www4.fugspbr.org/lista/html/FUG-BR/
