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

[Rogério Schneider]

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
>


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