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

Daniel Bristot de Oliveira danielbristot em gmail.com
Terça Novembro 14 20:33:03 BRST 2006


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


Mais detalhes sobre a lista de discussão freebsd