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

Quinta Novembro 16 14:27:25 BRST 2006

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

On 11/16/06, Marcello Costa <unixmafia em yahoo.com.br> wrote:
> Acho que se para para pensar um pouco vai entender  o que eu disse e nem
> vc ou ninguem nessa lista tem que concordar comigo, para mim ter que
> compartilhar o /tmp em dois servidores é gambiarra e nunca deixarei um
> admin fazer isso sem esgotar todas as possiveis opções
>
> Em Qui, 2006-11-16 às 09:45 -0200, Rogério Schneider escreveu:
> > Exatamente Daniel.
> >
> > Com o CARP é sim possível criar redundância de servers e firewall. No
> > caso de firewall, é simplesmente o exemplo utilizado na doc do PF,
> > tudo bem... Mas existem outras aplicações, é só usar a imaginação.
> >
> > Com servers (www, mail) também fica viável, e muito!
> > Ai alguém diz: "Não quero máquina ociosa, quero divisão de carga!",
> > tudo bem criança!! Cria dois grupos CARP (supondo dois webserers, ok?)
> > e cada um é "backup do outro". Pronto, no momento que um deles cair, o
> > outro assume as duas identidades (ips virtuais).
> > No firewall vc cria um rdr com address pool, utilizando source-hash e
> > pronto, cada source vai sempre cair no mesmo server (sessions?
> > resolvido) e cada novo source cai em round-robin (load balance?
> > resolvido).
> >
> > Feito o esquema, HA com Load Balance no CARP.
> >
> > Que manter os estados entre os servers? pfsync, e ninguém perde as conexões.
> >      - Minha dúvida: É preciso mesmo utilizar pfsync entre os servers
> > internos, www, por exemplo? Ou isso apenas se aplica a redundância de
> > firewall? E ainda, tendo dois www com o esquema de backup mútuo, será
> > que um pfsync entre eles não iria atrapalhar as coisas, já que cada um
> > tem a sua table de estados? A não ser que o pfsync faça um merge dos
> > estados acho que isso iria causar problemas com sobrescrita de
> > estados, perdendo as conexões ativas em um dos pontos, mas ai fica a
> > pergunta, será que é preciso pfsync interno?
> >
> > E fica sempre o problema: sincronia de dados entre os servers,
> > principalmente se for mail, aqui sim é que eu quero ver alguém dar
> > alguma opinião realmente boa, com conhecimento de causa.
> >
> > Utilizar CARP para failover NÃO É GAMBIARRA, ele foi FEITO para isso,
> > é PERFEITO nisso e para load balance usa rdr, e pronto. Não precisa
> > nem verificar quem está ativo ou não (pen) pq se vc tem dois grupos
> > CARP em backup mútuo o rdr nunca irá direcionar para uma máquina
> > inativa. Eu prefiro isso (PF) a DNS balance :)
> >
> > Agora falar mal do PF tem que estar pesado né? Pode parando....
> >
> > Att,
> > RS
> >
> > On 11/14/06, Daniel Bristot de Oliveira <danielbristot em gmail.com> wrote:
> > > Nossa essa thread rendeu hehe.
> > >
> > > Ja usei Pen, Carp, VRRP e rdr com source track no PF
> > >
> > > Porém, isto é para balanceamento de carga entrante, isto é, conexões
> > > entrando na minha rede, para eu servir.
> > >
> > > O artigo, carp e pfsync que o irado se referenciou, é um failover de
> > > um gateway, NAT... de conexões saindo. E fugiu um pouco do escopo da
> > > thread, mas vamos lá....
> > >
> > > O carp, como o nome dis, é um protocolo de redundância de endereço
> > > comum. Ele trabalha em nível de ARP, e não em nivel IP, como o vrrp
> > > faz. Ele foi feito para ser utilizado em qualuer lugar que se possa ou
> > > precize redundância pasiva, isto é, um espera o outro cair e assume.
> > >
> > > Load Balance com o carp, é feito em nivel arp, e por isto ele só
> > > funciona em rede local, por exemplo: duas maquinas estão fazendo um
> > > host virtual, onde as duas possuem um estado mestre e um escravo do
> > > emsmo endereço, desta forma teremos dois mestres, e dois recebendo as
> > > conexõs, porém, a divisão de carga é feita, em round-robin, porém, é
> > > utilizado um hash, para definir quem responde um cliente, então, um
> > > cliente semrpe vai ser respondido pelo mesmo mestre. Porém! isto só
> > > funciona em rede local!
> > >
> > > o Pen é um load balancer, com possibilidade de rastreamento de
> > > clientes. ele recebe uma conexão, redireciona e distribui para outros
> > > servidores, ele utiliza escalonamento em round-robin, (Na veradde
> > > todos estes que falei, utilizam round-robin por se tratar de
> > > escalonamento estático, por que ningeum gerencia estado de carga).
> > > Porém, o pen é o único que é possível utilizar prioridades no
> > > escalonamento. E o Pen verifica se os servidores estão UP ou não.
> > > Porém o Pen executa em nível do usuário, o que adiciona um grande
> > > delay nas trasnsações de rede, por estar sujeito a paginação, swap,
> > > ter que passar do nivel do kernle para usuário, e devolta do usuário
> > > para o kernel, e todas as verificações por trás disto.
> > >
> > > O PF com rdr faz redirecionamento,. e distribuição em round-robin, com
> > > possibilidade de source track, que é o rastreamento de clientes. ele e
> > > o pen são compatíveis, porém, o PF não checa estado de clientes, e não
> > > tem prioridades no escalonamento. Mas executa em nivel do kernel, e
> > > isso da uma direfença grande no desempenho, por que não está em área
> > > paginada, não possui tantas restrições ao acesso aos dados da rede,
> > > mas tem que cuidar para ele não abusar do sistema :) alem de ser mais
> > > facil de aplicar QoS e controle de DoS para o cluster.
> > >
> > > O pfsync serve mais expecificamente para HA de saída!, por que ele
> > > somente sincroniza a tabela state, que é responsável por manter as
> > > conexões "statefull", ela não sincroniza a tabela source, que faz o
> > > source track. Então, ele fica pouco útil para balanceamento de carga
> > > entrante, que é feita com o Pen e o rdr do PF. Mas para saída ele é
> > > perfeito, as conexões não são interrompidas, saiu ate um video que
> > > mostra, se eu não me engano, o Daniel Hartmeyer(grande developer do
> > > PF), mostrando um exemplo, onde uma musica estava passando por um
> > > gateway com failover, e ele quebrava um dos gateways(literalmente a
> > > pauladas), e o carp transferiu estado e o pfsync estava sincronizando,
> > > e a musica não parou :)
> > >
> > > Eu para entrada utilizaria:
> > > Load Balance grande = PF+CARP
> > > Load balance pequeno = CARP+PEN
> > >
> > > Para saída:
> > > carp e PFsync
> > >
> > > porém, eu estou apenas expondo minhas ideias, e não sou dono da
> > > verdade, cada um pensa como quiser, e eu não tenho nada contra!
> > >
> > > Um abraço!
> > > --
> > > Daniel Bristot de Oliveira
> > >
> > > R João Paez 409 Ap 202
> > > Sta Augusta - Criciúma - SC
> > > CEP 88805440 Brazil
> > > +55-48-91032512
> > > -------------------------
> > > 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
>
>
>
>
>
>
> _______________________________________________________
> Voc� quer respostas para suas perguntas? Ou voc� sabe muito e quer compartilhar seu conhecimento? Experimente o Yahoo! Respostas !
> http://br.answers.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
+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