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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] ICQ: 78778973 GTalk: [EMAIL PROTECTED] Skype: stockrt http://stockrt.unicruz.edu.br ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd