NFS não foi seria recomendado http://lists.freebsd.org/pipermail/freebsd-net/2006-August/011331.html
Melhor solução seria sem duvida um raid via rede A latencia pode não ser um grande problema , vc não fica alterando arquivos assim a todo instante , fora o /tmp claro. Tem isso aqui , antigão mas interessante http://blizzard.rwic.und.edu/~nordlie/miniwulf/ http://people.freebsd.org/~brooks/papers/bsdcon2003/ Esse parecem promissores http://www.freebsd.org/cgi/url.cgi?ports/sysutils/sge/pkg-descr http://gridengine.sunsource.net/ Q: What is Grid Engine? A: Grid Engine is a Distributed Resource Management (DRM) software. DRM software aggregates compute power and delivers it as a network service. Grid Engine software is used with a set of computers to create powerful compute farms, which are used in a wide range of technical computing applications such as the development of semiconductors, bioinformatics, mechanical design, software development, oil/gas exploration, and financial analysis; additionally, massively scaling supercomputers use Grid Engine software in a variety of academic and research pursuits. Users enjoy access to large computing capability and organizations enjoy effective utilization of their computing resource investments approaching 100%. Implementrar ai é outra história ... > > Não é besteira não, estou trabalhando para utilizar um sistema baseado > em geom com ggate e gmirror. > Bem, a idéia é replicar um volume de uma máquina para outra, e quando > a slave assumir, checar se ela pode assumir, se estiver com sistema > limpo, consistente. Parece simples, mas na hora de implementar é que > aparecem os problemas reais. > Outra coisa, é que as vezes a sincronização me parece muito lenta, > quando de uma falha, o novo slave recebe, no startup, TODO o volume do > atual master... Isso leva muito tempo. O DRBD diz ser otimizado nisso, > levando de 1 a 3 minutos para sync completa, em volumes de até 4 TB, > isso sim é bom. > Se o gmirror pudesse fazer isso, seria ótimo, trabalhar como o rsync > saca, gerando hashs de blocos contínuos e checando com o destino, > otimizando a transferência, enviando somente aquilo que é realmente > diferente, e não tudo. > > Esbarrei nesse problema agora... E outra coisa é quando um slave > assume master com o FS corrompido. Pode ocorrer, e representa risco > para os dados, imaigna fazer um espelhamento disso sobre o antigo > master, que tem os dados consistentes? Pronto neh... Essa chacagem > deve ser feita antes de o slave assumir master. > > Quanto aos clientes, seriam NFS, ai entra um outro problema. > Como eles se comportariam numa troca onde ninguém asume? Master falha, > slave não assume por inconsistência.. Será que o cliente (server web, > mail) não vai tentar usar arquivos locais nesse caso? Isso seria uma > boa bosta :) > > Att, > RS > > > > > > > > > > Em Qui, 2006-11-16 às 14:27 -0200, Rogério Schneider escreveu: > > > Marcelo, veja: > > > > > > Failover e Load Balance é sim simples de se fazer, o PF resolve tudo > > > isso, com pfsync, CARP e rdr. Ponto. > > > > > > Compartilhar os dados, centralizar, isso sim é uma problema, e seria > > > exatamente sobre isso que eu gostaria que alguém aqui se manifestasse. > > > Existe alguma maneira eficiente de se ter um storage redundante > > > montado sobre FreeBSD (ou mesmo Linux, Open, enfim...) baseado > > > TOTALMENTE em soluções livres? > > > Esse é o ponto. > > > > > > :) > > > > > > Os /tmp poderiam ficar no storage, sem problemas, mesmo. Você vê algum > > > problema? Tudo bem, muda o diretório de sessions nos teus servers www > > > e aponta este novo caminho para dentro do storage, em área > > > compartilhada, assim vc mantém os /tmp isolados. > > > > > > O problema é o storage gente.... alguém? > > > > > > Att, > > > RS > > > > > > > -- > > Marcello Costa > > BSD System Engineer > > unixmafia at yahoo dot com dot br > > FUG-BR #156 > > http://www.fug.com.br > > > > > > > > _______________________________________________________ > > Novidade no Yahoo! Mail: receba alertas de novas mensagens no seu celular. > > Registre seu aparelho agora! > > http://br.mobile.yahoo.com/mailalertas/ > > > > > > ------------------------- > > Histórico: http://www.fug.com.br/historico/html/freebsd/ > > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > > > -- Marcello Costa BSD System Engineer unixmafia at yahoo dot com dot br FUG-BR #156 http://www.fug.com.br _______________________________________________________ O Yahoo! est� de cara nova. Venha conferir! http://br.yahoo.com
------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
