Marcello, o NFS não é recomendado no uso write one / read all, pq ao modificar o inodes "under the feets" do NFS ele perde a ref, devido ao seu cache. No caso, apenas uma máquina servindo NFS e a outra como mirror daria certo, desde que não se quisesse ler via NFS da máquina mirror.
Att, RS On 11/17/06, Marcello Costa <[EMAIL PROTECTED]> wrote: > 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 > > > -- Rogério Schneider +55 (55) 9985 2127 MSN: [EMAIL PROTECTED] GTalk: [EMAIL PROTECTED] Skype: stockrt ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
