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 <[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 > > > > -- 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/
------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd