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

[Rogério Schneider]

Marcelo, você tem boas referências para postar, obrigado, vou ter um
dia cheio de leituras :)


On 11/16/06, Marcello Costa <unixmafia em yahoo.com.br> wrote:
> Bem porque querer compartilhar o /tmp se é possivel manter a sessão http
> do requisitante ? simplesmente não é preciso.
> Log ? o syslog resolve isso , pode ter um servidor que sera o master dos
> logs.
>
> Bem me lembro que tem um exemplo com freebie sendo usado pra cluster via
> nfs , funciona claro , mas não é o caso.
>
> http://www.onlamp.com/pub/a/bsd/2004/07/01/freesbie.html
>
> Apache tem a sua solução :
>
> http://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html
>
> http://www.backhand.org/mod_backhand/
>
>
> Achei outros com java , vadi retro , amenos que vc use tomcat
>
> http://www.samag.com/documents/s=1155/sam0101a/0101a.htm
>
>
> Material muito bom esse aqui :
>
> http://www.enterux.com/en/solutions/load-balancing-high-volume-solutions
>
>
> Citado varias vezes
>
> http://www.tummy.com/journals/entries/scott_20050324_171814
>
> http://www.linux-ha.org/Heartbeat
>
>
> Balance já foi colocado na lista
>
> Tem varias formas de fazer , apenas acho que o problema não precisa
> passar a ser storage.
>
> Storage  , o geom pode ajudar virtualizando ou to falando tremenda
> besteira ?

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
>


-- 
Rogério Schneider

+55 (55) 9985 2127
+55 (55) 3332 5923
+55 (55) 3321 1535

MSN: stockrt em hotmail.com
ICQ: 78778973
GTalk: stockrt em gmail.com
Skype: stockrt

http://stockrt.unicruz.edu.br