[GTER] balanceamento de sites

[Clodonil Trigo]

Olá Geraldo,

Estou dando uma olhada no protocolo VRRP para ver se atende. Estou com a
mesma dúvida sobre o IP virtual. Estou relutante em implementar o DNS com
ttls baixo, mais acho que vai cair nisso. Pense em dns round robin, mais
não rolou.

Vamos pesquisando...

Um grande abraço.

Clodonil

Em 2 de maio de 2012 11:57, Geraldo Magella Junior
<geraldo at webaula.com>escreveu:

> Eu também esto na busca do melhor "desenho" para esta solução.
> Basear a solução em DNS (ttl baixo) não me parece ser uma solução eficiente
> também, mas a solução de usar CDN para realizar a redundância, me parece
> uma boa.
> Eu imaginava que a solução deveria ser um appliance "balanceador de carga"
> Tipo o BigIP ou Cisco ACE, em cada ponta e heartbeat entre eles, etc. Mas
> como fazer o V.IP publico "rotear" para os 2 pontos é o que eu não sei se é
> possível.
>
> *Geraldo Magella Junior**
> *Coordenador de Infraestrutura
>
> Centro de Tecnologia
>
> web*Aula* S/A
>
>
>
>
> 2012/5/1 Paulo Henrique <paulo.rddck at bsd.com.br>
>
> > Em 30 de abril de 2012 21:22, Juliano Primavesi | KingHost <
> > juliano at kinghost.com.br> escreveu:
> >
> > >
> > > O Clodonil mencionou que os servidores estão em 2 datacenters
> diferentes.
> > >
> > > A solução menos complexa é usar DNS round-robin e, quando um IDC cair,
> > > tirar o IP que falhou, do DNS.
> > >
> > > Para isso funcionar, precisará ter um TTL baixo, de até 1 minuto (60)
> > >
> > > Agora, se ele tem um Lan2Lan entre os dois IDCs, aí sim um VRRP poderia
> > > funcionar.
> > >
> > > Juliano
> > >
> > > Em 30/04/2012 14:06, Rodrigo Pedrosa escreveu:
> > >
> > >  Clodonil, não precisa mudar o IP, pode utilizar o conceito de IP
> Virtual
> > >> (VIP), ou seja, o IP virtual ficará ativo no master, o servidor backup
> > >> ativa esse IP apenas quando master ficar indisponível.
> > >> Para isso poderá utilizar os protocolos: VRRP (padrão), HSRP ou GLBP
> > >> (cisco), e até o HeartBeat (aplicação) no caso de serem os servidores
> > >> linux.
> > >> Outra solução seria a utilização de um balanceador de carga, que
> poderia
> > >> ser utilizado o LVS (Linux Virtual Server), que é um framework que
> > permite
> > >> checar a saude da aplicação, balancear ou não o acesso. Desvantágem
> > dessa
> > >> topologia é que necessitaria utilizar mais um host para servir de
> > >> balanceador e outra é que seria um ponto de falha o proprio
> balanceador.
> > >> Vantagem é que possui mais recursos, como várias algoritimos de
> > >> balanceamento e o check da aplicação.
> > >>
> > >> Att., Rodrigo Pedrosa de Aguiar.
> > >>
> > >>
> > >> Em 30 de abril de 2012 09:43, Clodonil Trigo<clodonil at nisled.org>
> > >>  escreveu:
> > >>
> > >>  Olá Amigos,
> > >>>
> > >>> Temos os nossos servidores replicados em 2 datacenter diferente para
> > >>> garantir a segurança e disponibilidade dos dados. Qual é a melhor
> > solução
> > >>> para redundância e alta disponibilidade dos serviços http.  Os
> > servidores
> > >>> http ficam online 100% do tempo. Qual é a melhor forma de fazer o DNS
> > >>> assumir outro IP quando o servidor http master cair? Não quero fazer
> > >>> balanceamento, só redundância.
> > >>>
> > >>>
> > >>> Clodonil Trigo
> > >>>
> > >>
> > Sr. Clodonil,
> > Sugestão, creio não é barato o serviço de hospedagem que paga, por que
> não
> > investe em um serviço efetivamente de melhor qualidade, verifica os
> > serviços da Google, Akamai, Azure, Amazon para hospedar o sistema,
> investir
> > em "adaptação técnica" em algum momento ela será falha, e se a aplicação
> > tem retorno financeiro, investimento em sua operação é como descrito,
> > investimento e não custo.
> >
> > Das soluções acima, o heartbeat é o que melhor irá lhe atender, e solução
> > de TTL de dns baixo não é 100% efetivo.
> > pode tentar usar utilizar a dobratidinha de heratbeat junto com ttl
> baixo,
> > o ttl diminuirá o tempo de indisponibilidade para a propagação em caches
> > dns e o heartbead alterará explicitamente a zona apontando para o segundo
> > servidor, forçando até mesmos os dns caches a atualizarem.
> >
> >
> > Att.
> >
> > --
> > :=)>BattleMaster<(=:
> >
> > Flamers > /dev/null !!!
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>