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

[Marcello Costa]

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 at 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/