[FUG-BR] Cluster de Firewall com carp + pfsync (tutorial)

[Rogério Schneider]

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 <unixmafia em yahoo.com.br> 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: stockrt em hotmail.com
GTalk: stockrt em gmail.com
Skype: stockrt