Eu tenho RAID via hardware...mas a maquina queimou nesse fim de semana..naum perdi dados mas fiquei com o sistema parado. Se eu conseguir replicar as caixas pra outra maquina, com o heartbeat levanto outro server (creio eu) e assim fico pouco tempo sem o server estar desligado. Nem precisa ser algo real-time, mas algo que tenha a menor intervencao humana possivel. Isso jah ajuda
Frederico On Thu, 2003-06-26 at 15:37, Patrick Tracanelli wrote: > 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 ;-) > _______________________________________________________________ Sair da Lista: http://www2.fugspbr.org/mailman/listinfo/fugspbr Historico: http://www4.fugspbr.org/lista/html/FUG-BR/
