[GTER] balanceamento de sites

Wed May 2 14:22:49 -03 2012

Olá Caio, o site do nisled.org é um projeto particular que ministro curso
de OpenLDAP e Samba4 à distância. O projeto de redundância é para uma
empresa que presto consultoria, os servidores estão alocados na alog e na
diveo.

Valeu, um grande abraço.

Em 2 de maio de 2012 13:50, Caio Espíndola <caio.espindola at gmail.com>escreveu:

> *Clodonil,*
> *
> *
> *Me responda duas questões:*
> *
> *
> *1º O site que vai receber tal implementação é o www.nisled.org ?*
> *
> *
> *2º Se for esse site ele esta hospedado na Localweb, você pretende colocar
> o site secundário em outra datacenter concorrente ?*
> *
> *
>
> OBS.: Se a resposta para as duas questões forem "SIM !" esquece VRRP e
> procura um appliance que faça isso.
>
> Qualquer coisa me contata via PVT.
>
> Abraço
>
> --
>
> Cordialmente,
>
> Caio César da S. Espindola
> Administrador de redes
> Analista de suporte Linux/Windows
> Fone:+55 048 8816-9334 / 84655817
>
>
>
> Em 2 de maio de 2012 12:37, Clodonil Trigo <clodonil at nisled.org> escreveu:
>
> > 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
> > >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>