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! 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. > > >>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. > > - 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. > > > > > > >>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/ > _______________________________________________________________ Sair da Lista: http://lists.fugspbr.org/listinfo.cgi Historico: http://www4.fugspbr.org/lista/html/FUG-BR/
