-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Marcio Merlone <[EMAIL PROTECTED]> writes: > Independente de MTA, a pergunta � simples: qual o melhor dos mundos > (dentro da opini�o pessoal de cada um) em uma solu��o de alta > disponibilidade e desempenho para um �nico (e grande) servidor de email > sem utilizar switches ou solu��es caras de balanceamento de carga? > Digamos uns 5.000 dominios e 100.000 contas pop. Independente do servidor, tenha uma coisa em mente: e-mail � 'I/O bound', ou seja, amarrado � capacidade de I/O de teu sistema. Seja este I/O capacidade de leitura e grava��o em disco ou seja este capacidade de escoamento de tr�fego por teu link. > Um grande servidor que armazena os maildirs (n�o mbox), SCSI > ultra-hiper-super-wide RAID 5 por hardware hot-swap, fontes redundantes, > etc. Outra m�quina destina-se apenas a gerenciar a fila de entrega e > aplicar regras de relay, anti-virus, etc. A estas duas, somam-se > v�rias Regras de relay deveriam ser tratadas na primeira m�quina, logo na entrada. Assim evitarias que mensagens trafegassem desnecessariamente pela rede interna dos servidores. Esse tr�fego desnecess�rio geraria logs desnecess�rios, ocuparia ciclos de CPU desnecessariamente, ocuparia banda desnecessariamente, etc. > outras pequenas, de baixo custo, todas configuradas como MX de mesma > prioridade no DNS e todas respondendo por pop.dominio.com.br e > smtp.dominio.com.br (round-robin DNS para balanceamento (divis�o, vai) > de carga). Cada uma delas tem montado por NFS o diret�rio /var/mail da > m�quina que mant�m os maildirs (HASH 2 - /var/mail/f/u/fulano/) dos > usu�rios virtuais (eles existir�o apenas em uma tabela de MySQL), assim > como o IP de quem fizer pop para controle do relay > (pop-before-smtp). Lembre-se que NFS apresenta diversos probleminhas e que uma queda de tens�o (e falha dos equipamentos de prote��o) pode causar queda do sistema e perda de mensagens. O NFS deve ser usado com pastas do tipo Maildir, n�o podendo ser usado com mailboxes padr�o devido a problemas de locking. > Desta forma, um MUA remoto de algu�m vai acessar aleatoriamente os > pequenos servidores para pop e smtp, aquele em que ele se conectar vai > ler o maildir do usu�rio por NFS. Depois de feito o pop, quando for > enviar uma msg, consulta no mysql se o IP est� liberado. Um pequeno > script limpa os IPs 'vencidos' regularmente. Se uma destas pequenas > m�quinas cair, sobrar�o as outras e n�o far� falta at� ser reposta. N�o sei at� que valor isso � interessante, mas cheque se � realmente necess�rio um banco de dados como o MySQL. Muitas vezes arquivos DBM resolvem muito bem e muito rapidamente este tipo de problema. > Al�m de backup das configura��es e outra m�quina igualzinha ao lado da > que armazena os maildirs, de que forma poderia melhorar a > disponibilidade desta m�quina? Ela me parece o elo fraco da est�ria.... Use um storage e n�o uma m�quina para armazenar esses diret�rios. Use sistemas do tipo LVS (Linux Virtual Server) para balanceamento de carga. Funcionam MUITO melhor que round robin. O problema do round robin � o seguinte: Suponha que tens 10 m�quinas. Uma delas cai. Usando round robin, vais perder 10% de tuas requisi��es. Usando LVS (+ mon + heartbeat + p� de coelho + figa + ferradura na parede) podes manter uma lista de servidores que ser�o acessados sequencialmente e, em caso de falha, os programas encarregar�o-se de remover este servidor da lista. Tentativas de conex�o a intervalos definidos poder�o ser refeitas e caso sejam bem sucedidas, o servidor que caiu pode ser readicionado � lista de servidores dispon�veis, evitando-se assim a perda de requisi��es. > Que outra configura��o atenderia � necessidade de alta disponibilidade > em servidor de email? Que acham disto tudo? A sugerida acima, por exemplo. N�o se esque�a de rodar caches de DNS em todas as m�quinas que t�m um MTA rodando. Isso � imprescind�vel. > Obrigado por qualquer id�ia, desculpem o email longo. Mas estou muito > curioso sobre as solu��es em uso por ai.-- Fiz um projeto parecido, para uma solu��o um pouco maior. Envolvia mais detalhes, mas os requisitos eram diferentes. Infelizmente, n�o posso comentar sobre ele. Mas, um pouco do aprendido est� acima. - -- Godoy. <[EMAIL PROTECTED]> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8wlrpEzC+baSjBiURAhxqAKCTSbFCqKhlW9N87wY5gsaO+QUFrACdEWRf BaiGs+yW/6BA/qOClM9ilTA= =eMw8 -----END PGP SIGNATURE----- Assinantes em 21/04/2002: 2240 Mensagens recebidas desde 07/01/1999: 163467 Historico e [des]cadastramento: http://linux-br.conectiva.com.br Assuntos administrativos e problemas com a lista: mailto:[EMAIL PROTECTED]
