[GTER] balanceamento de sites

Juliano Primavesi | KingHost juliano at kinghost.com.br
Wed May 2 20:41:14 -03 2012


Se voce opera em dois datacenters diferentes, SEM ASN PRÓPRIO, não tem 
appliance no mundo que faça a mágica que voces querem.

SEM ASN PRÓPRIO, só usando TTL menor no DNS, onde cada DNS vai apontar 
para "sua própria rede", assim terá balanceamento de carga por DNS RTT e 
continuidade de negocio por "DNS timeout".

Nao vai ser necessário alterar nada quando um "datacenter cair".

CDN serve apenas para conteúdo ESTÁTICO.

Juliano

Em 02/05/2012 11:57, Geraldo Magella Junior 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 
> <mailto:paulo.rddck at bsd.com.br>>
>
>     Em 30 de abril de 2012 21:22, Juliano Primavesi | KingHost <
>     juliano at kinghost.com.br <mailto: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 <mailto: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
>
>



More information about the gter mailing list