[FUGSPBR] FreeBSD, Qmail, e Alta Disponibilidade

[Patrick Tracanelli]

Ricardo Ryoiti S. Junior wrote:

> Timmy!!! wrote:
>
> > O rsync replicando as caixas de email dos usuarios naum causa lentidão
> > não?
> >
> >

Minhas sugestões para *alguma* disponibilidade a mais, são mais 
tradicionais. Pense em um ambiente com as caixas postais e a fila do 
qmail centralizadas, e os recursos de processamento distribuidos. 
Solucoes que eu acho interessante incluem o compartilhamento do FS via 
rede (NFS, tradicionalmente) e algum mirror (mirror+stripping) da(s) 
unidade(s) de armazenamento, podendo estes ser implementados via 
hardware, caso seu equipamento seja capaz, ou uma solucão de RAID via 
software, sendo opcos a se considerar o vinum(8), escrito pelo greg 
lehey (veja man 4 vinum e man 8 vinum), ou RAIDFrame se seu ambiente 
puder ser FreeBSD 5 (RAIDFrame é MFC do NetBSD no FreeBSD 5, veja man 4 
raid e man 8 raidctl em um sistema dessa série).

O proprio vpopamail, se faz parte da sua implementacao atual, oferece 
recursos para replicacao de banco de dados, o que parece interessante 
que seus users não sejam parte nem do sistema nem em arquivos cdb. Se 
bem que todo banco oferece esses recursos, então cabe a você definir o 
que lhe parece mais interessante.

As caixas postais compartilhadas via NFS é trivial, contudo centralizar 
as filas pode não ser tanto. As dicas são QMQP, solucão do DJB prevendo 
uso do QMAil em ambientes mais, digamos, avantajados. O protocolo cuida 
exatamente de centralizar as filas, considerando que você vai ter mirror 
on-the-fly com RAID desse storage compartilhado, me parece redundante o 
bastante para alguma dispon. Pro lado de processamento do Qmail, 
mini-qmail. As paginas http://cr.yp.to/proto/qmqp.html e 
http://cr.yp.to/qmail/mini.html tem ótimas dicas e explicacões mais 
precisas do que as minhas.

A questão das estacões assumindo outras estacões que eventualmente 
falharem, pode ser realizado com alguma das inúmeras solucões já citadas 
nessa lista (da-lhe historico), desde solucoes baseadas em IPTakeover 
até monitoramento via arp, e opcões menos gambiarras como HUT (todos ja 
citados nessa lista).

Mas ainda assim, lembre-se que alta disponibilidade é muito mais do que 
servidores redundantes assumindo-se. Inclui um estudo um pouco mais 
detalhado e o apontamento dos chamados SPOF (Single Point of Failure), 
ou seja, não basta redundancia de servico se voce só tiver 1 link com a 
internet, só tiver 1 roteador servindo seus servidores, etc etc etc.

Boa sorte, paciência, e alguma grana pra redundância.

Acho que isso bastam ;-)


-- 
Atenciosamente,

Patrick Tracanelli

FreeBSD Brasil LTDA.
The FreeBSD pt_BR Documentation Project
http://www.freebsdbrasil.com.br
patrick em freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"

_______________________________________________________________
Sair da Lista: http://www2.fugspbr.org/mailman/listinfo/fugspbr
Historico: http://www4.fugspbr.org/lista/html/FUG-BR/