No dia Sun, 21 Apr 2002 03:23:34 -0300
Jorge Godoy <[EMAIL PROTECTED]> exp�s:
JG > Marcio Merlone <[EMAIL PROTECTED]> writes:
E claro, o Godoy seria um dos primeiros a se manifestar... :^)
JG > > Independente de MTA, a pergunta � simples: qual o melhor dos
mundos JG > > (dentro da opini�o pessoal de cada um) em uma solu��o de
alta JG > > disponibilidade e desempenho para um �nico (e grande)
servidor de email JG > > sem utilizar switches ou solu��es caras de
balanceamento de carga? JG > > Digamos uns 5.000 dominios e 100.000
contas pop. JG >
JG > Independente do servidor, tenha uma coisa em mente: e-mail � 'I/O
JG > bound', ou seja, amarrado � capacidade de I/O de teu sistema.
JG > Seja este I/O capacidade de leitura e grava��o em disco ou seja
este JG > capacidade de escoamento de tr�fego por teu link.
hhmm... acho que isto tem, 6 hds scsi3 de 36GB em RAID5 por hardware.
Link em uns 30MB.
JG > > Um grande servidor que armazena os maildirs (n�o mbox), SCSI
JG > > ultra-hiper-super-wide RAID 5 por hardware hot-swap, fontes
redundantes, JG > > etc. Outra m�quina destina-se apenas a gerenciar a
fila de entrega e JG > > aplicar regras de relay, anti-virus, etc. A
estas duas, somam-se JG > > v�rias
JG >
JG > Regras de relay deveriam ser tratadas na primeira m�quina, logo na
JG > entrada. Assim evitarias que mensagens trafegassem
desnecessariamente JG > pela rede interna dos servidores. Esse tr�fego
desnecess�rio geraria JG > logs desnecess�rios, ocuparia ciclos de CPU
desnecessariamente, JG > ocuparia banda desnecessariamente, etc.
Realmente.. muito bem colocado, n�o pensei neste aspecto. Me preocupa um
pouco a administra��o de todas as m�quinas, bloqueio de IPs na hora por
spam, etc. Seria bom uma configura��o centralizada disto. Enfiar uma
m�quina no meio s� pra isto valeria a pena?
JG > > outras pequenas, de baixo custo, todas configuradas como MX de
mesma JG > > prioridade no DNS e todas respondendo por
pop.dominio.com.br e JG > > smtp.dominio.com.br (round-robin DNS para
balanceamento (divis�o, vai) JG > > de carga). Cada uma delas tem
montado por NFS o diret�rio /var/mail da JG > > m�quina que mant�m os
maildirs (HASH 2 - /var/mail/f/u/fulano/) dos JG > > usu�rios virtuais
(eles existir�o apenas em uma tabela de MySQL), assim JG > > como o IP
de quem fizer pop para controle do relay JG > > (pop-before-smtp).
JG >
JG > Lembre-se que NFS apresenta diversos probleminhas e que uma queda
de JG > tens�o (e falha dos equipamentos de prote��o) pode causar queda
do JG > sistema e perda de mensagens. O NFS deve ser usado com pastas do
tipo JG > Maildir, n�o podendo ser usado com mailboxes padr�o devido a
problemas JG > de locking.
Sem d�vida, maildir.
JG > > Desta forma, um MUA remoto de algu�m vai acessar aleatoriamente
os JG > > pequenos servidores para pop e smtp, aquele em que ele se
conectar vai JG > > ler o maildir do usu�rio por NFS. Depois de feito o
pop, quando for JG > > enviar uma msg, consulta no mysql se o IP est�
liberado. Um pequeno JG > > script limpa os IPs 'vencidos' regularmente.
Se uma destas pequenas JG > > m�quinas cair, sobrar�o as outras e n�o
far� falta at� ser reposta. JG >
JG > N�o sei at� que valor isso � interessante, mas cheque se �
realmente JG > necess�rio um banco de dados como o MySQL. Muitas vezes
arquivos DBM JG > resolvem muito bem e muito rapidamente este tipo de
problema.
O MySQL � para poder centralizar as informa��es de pop para liberar
relay, base de usu�rios, virtusertable, aliases, etc. Qualquer outro
mapa fica dif�cil de acesso remoto. Sem contar que tamb�m facilita o
provisionamento e a escrita de aplicativos para manuten��o das infos.
JG > > Al�m de backup das configura��es e outra m�quina igualzinha ao
lado da JG > > que armazena os maildirs, de que forma poderia melhorar a
JG > > disponibilidade desta m�quina? Ela me parece o elo fraco da
est�ria.... JG >
JG > Use um storage e n�o uma m�quina para armazenar esses diret�rios.
hhmmm... � caro. A id�ia foi aproveitar uma grande m�quina que estava
'sobrando' para fazer um 'servidor de arquivos', no caso os maildirs.
Ainda n�o est�, mas retirando o MTA dela e jogando nas maquininhas, ele
vai ficar como um servidor de arquivos somente.
JG > Use sistemas do tipo LVS (Linux Virtual Server) para balanceamento
de JG > carga. Funcionam MUITO melhor que round robin.
JG > O problema do round robin � o seguinte:
JG > Suponha que tens 10 m�quinas. Uma delas cai. Usando round robin,
vais JG > perder 10% de tuas requisi��es.
JG > Usando LVS (+ mon + heartbeat + p� de coelho + figa + ferradura na
JG > parede) podes manter uma lista de servidores que ser�o acessados
JG > sequencialmente e, em caso de falha, os programas encarregar�o-se
de JG > remover este servidor da lista. Tentativas de conex�o a
intervalos JG > definidos poder�o ser refeitas e caso sejam bem
sucedidas, o servidor JG > que caiu pode ser readicionado � lista de
servidores dispon�veis, JG > evitando-se assim a perda de requisi��es.
Onde acho algo sobre LVS? Dif�cil configurar e manter? Sou da filosofia
de que o simples � bom, mesmo que seja complicado chegar l�. :^)
JG > > Que outra configura��o atenderia � necessidade de alta
disponibilidade JG > > em servidor de email? Que acham disto tudo?
JG > A sugerida acima, por exemplo.
JG > N�o se esque�a de rodar caches de DNS em todas as m�quinas que t�m
um JG > MTA rodando. Isso � imprescind�vel.
Hein? Seria um bind como caching-only nameserver? Ou um nscd? Qual o
melhor e mais leve para cache?
JG > > Obrigado por qualquer id�ia, desculpem o email longo. Mas estou
muito JG > > curioso sobre as solu��es em uso por ai.--
JG > Fiz um projeto parecido, para uma solu��o um pouco maior. Envolvia
JG > mais detalhes, mas os requisitos eram diferentes.
JG > Infelizmente, n�o posso comentar sobre ele. Mas, um pouco do
aprendido JG > est� acima.
U�, n�o me interessa quem, mas como.
Valeu, Godoy!
--
Paul's Law:
In America, it's not how much an item costs, it's how much you save.
============================
Marcio Merlone
Linux Registered User 104911
Assinantes em 22/04/2002: 2245
Mensagens recebidas desde 07/01/1999: 163758
Historico e [des]cadastramento: http://linux-br.conectiva.com.br
Assuntos administrativos e problemas com a lista:
mailto:[EMAIL PROTECTED]
