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
