Bom ent�o vamos l�, o que ser� que o pessoal usa uns dois ou tr�s servidores funcionando como MX do dom�nio fazendo antispam e antivirus, e depois? � tudo entregue a uma maquina s�? ou seja 100.000 contas armazenadas numa maquina s�? ser� que n�o tem um cluster ou algo ai que reparta o peso disso?
At� mais Vini
Marcio Merlone escreveu:
Em Tue, 18 Mar 2003 16:48:29 -0300, Alexandre Vasconcelos <[EMAIL PROTECTED]> escreveu:
Vini wrote:
Ser� que algu�m sabe me dizer como os grandes provedores ger�nciam um volume absurdo de contas de email e volume de mensagem? Ser� que usam cluster, replica��o, algo assim? Que plataforma de hardware usam? E o MTA?
<IHMO>
M�quinas RISC, grande quantidade de mem�ria, discos r�pidos (SCSI) funcionando em RAID, fontes redundantes, no-break, gerador de energia,
backup.. clustering � uma boa, mas pede uma avalia��o mais aprofundada.. MTAs como Postfix e Qmail bem configurados e um S.O. bem otimizado para a tarefa devem fazer o trabalho. </IMHO>
� por ai mesmo, sem desconsiderar o cluster. Em se tratando de grandes volumes e o spam que rola por ai hoje em dia, � quase obrigat�rio a exist�ncia de um cluster de m�quinas fazendo anti-spam e anti-virus ANTES do servidor final, onde o cliente faz o pop.
O problema maior nem � o MTA em si, que vai rolar entre Qmail e Postfix (por ignor�ncia de qmail, gosto muito mais de postfix :), mas no sistema de provisionamento de contas, billing, dom�nios, etc. Incluir dom�nios e usu�rios na m�o em um servidor com digamos 100.000 contas n�o tem como ser manual, na linha de comando. Vai ter que ter uma interface para os usu�rios criarem suas pr�prias contas e � isto que vai pegar pois n�o achei nada de t�o boa qualidade quanto os MTAS existentes.
Em rela��o ao que o Vini escreveu, s� questiono o RISC, as Intel d�o conta do recado, m�quinas multiprocessadas, raid por hardware (nem pensar por software), muita mem�ria, muito barramento, muita rede, etc.
Replica��o somente dos dados de contas, etc, n�o das caixas postais, somente no caso em que existir um servidor spare aguardando a falha no prim�rio, ent�o haveria uma sincronia entre os filesystems dos servidores (tipo rsync).
--
Marcio Merlone
_______________________________________________________________ Sair da Lista: http://www2.fugspbr.org/mailman/listinfo/fugspbr Historico: http://www4.fugspbr.org/lista/html/FUG-BR/
_______________________________________________________________ Sair da Lista: http://www2.fugspbr.org/mailman/listinfo/fugspbr Historico: http://www4.fugspbr.org/lista/html/FUG-BR/
