[GTER] balanceamento de sites

[Paulo Henrique]

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 !!!