[FUG-BR] Failover em placas de rede
Pablo Sánchez
phackwer em gmail.com
Qua Jul 27 16:30:34 BRT 2005
Ok, minha teoria parece ser beeem provável.
Ao colocar o CARP, as duas interfaces respondem pelo IP virtual (elas
são colocadas em modo promíscuo), sendo a resposta enviada pela
interface receptora. Assim, se uma das interfaces é desligada, ou
simplesmente para de receber dados, ela também não enviará dados.
Resultado:
CARP PODE SER UTILIZADO PARA FAILOVER EM UMA MESMA MÁQUINA COM DUAS
INTERFACES DISTINTAS.
Um bj e um abc!
On 7/27/05, Pablo Sánchez <phackwer em gmail.com> wrote:
> Estou vendo o código o CARP que faz a checagem da interface, hehehe. É
> engraçado... olha o comentário (muito provavelmente sobre o que eu
> estou procurando)
>
> * For a bridge, we want to check the address irrespective
> * of the receive interface. (This will change slightly
> * when we have clusters of interfaces).
> + * If the interface does not match, but the recieving interface
> + * is part of carp, we call carp_iamatch to see if this is a
> + * request for the virtual host ip.
> + * XXX: This is really ugly!
>
> Eu estou vendo este código:
> http://people.freebsd.org/~mlaier/CARP/20050110-carp.diff
>
> Deve ter algo mais recente no CVSUP do FreeBSD, mas... Como eu disse,
> só vou poder testar mesmo depois, em casa.
>
> On 7/27/05, Pablo Sánchez <phackwer em gmail.com> wrote:
> > Então lá vai a embromation para explicar porque eu acredito que funcionaria:
> >
> > 1 - O CARP não faz distinção para qual placa de rede ele está sendo
> > aplicado (se fizesse, ia ser mais fácil ainda, mas no "ipconfig capr0
> > create" não tem como)
> >
> > 2 - Assim sendo, se uma máquina tem 2 placas de rede da mesma classe,
> > cada qual com um IP, e cria-se a interface virtual do CARP com o IP
> > virtual, as duas placas deveriam responder indistintamente.
> >
> > 3 - Como não há distinção em qual placa deveria responder, o mais
> > provável é que a resposta escoe pela mesma interface física que
> > recebeu a requisição.
> >
> > Isso tudo é teoria. Realmente precisaria colocar em prática para
> > confirmar. Aqui no trampo não tenho como confirmar, então só vou poder
> > dar a resposta à noite, qdo chegar em casa. Teria que ver como é que o
> > kernel elege a primária, neste caso de uma máquina ter duas placas,
> > com dois ips da mesma classe.
> >
> > On 7/27/05, Douglas Zaghini <XIU> <xiu em irapida.com.br> wrote:
> > > caro confrade
> > >
> > > tudo comecou qdo nossa amigo marcelo disse q era possivel utilizar o
> > > carp para o FAILOVER entre as placas na mesma maquina, e tu defendeu
> > > esta tese com unhas e dentes.
> > >
> > > ai comecamos a discutir sobre sobre ter a mesma classe em 2 interfaces
> > > de rede, e ai foi dispercando o foco inicial do assunto.
> > >
> > > a pergunta eh: como fazer o CARP para o FAILOVER entre placas de rede na
> > > mesma maquina, utilizando a mesma classe com a mesma mascara???
> > >
> > > Pablo Sánchez wrote:
> > >
> > > Pô, quem se confundiu fui eu. Quem é que fez a pergunta original mesmo?
> > >
> > > On 7/26/05, Douglas Zaghini <XIU> <xiu em irapida.com.br> wrote:
> > >
> > >
> > > Ta ok...
> > >
> > > Mas agora vc confundiu minha cabecinha!
> > >
> > > A ideia inicial era em relacao ao FAILOVER.
> > >
> > > Entao , da forma que vc escreveu em relacao ao FAILOVER, a redundancia
> > > de placas teria q ser feitas na mesma mascara e mesmo IP.
> > >
> > > Neste email vc comentou sobre ter mascaras diferentes, o que dai nao se
> > > enchaixa no projeto!
> > >
> > > Sera que o amigo poderia exemplificar a solucao?? Visto que segui suas
> > > recomendacoes e nao encontrei
> > > forma de funcionamento nas mesmas.
> > >
> > > XIU
> > >
> > > Pablo Sánchez wrote:
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Freebsd mailing list
> > > Freebsd em fug.com.br
> > > http://mail.fug.com.br/mailman/listinfo/freebsd_fug.com.br
> > >
> >
>
_______________________________________________
Freebsd mailing list
Freebsd em fug.com.br
http://mail.fug.com.br/mailman/listinfo/freebsd_fug.com.br
Mais detalhes sobre a lista de discussão freebsd