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
[EMAIL PROTECTED]
"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/

Responder a