[GTER] RES: balanceamento de sites

Sat May 5 08:53:58 -03 2012

Em 3 de maio de 2012 09:50, Cleber @ Inetweb
<cleber-listas at inetweb.com.br> escreveu:
> A solução da Radware você tem que ter um 3 datacenter apontando e
> balanceando para os outros 2, porém, se cair esse 3 datacenter você fica
> fora da mesma forma.
> A melhor solução técnica é ter seu próprio ASN.
Como os datacenters são de empresas diferentes o próprio ASN
resolveria . Sei que existem "Gambiarras" que fariam isto mas não é o
ideal.
No cenário dele ele poderia ter uma solução que funcionasse em nuvem e
hospedar em duas nuvens diferentes Seguindo as boas práticas no uso de
DNS.
Mas para baratear o custo contrar um serviço ja existente  (DynDNS ou
No-IP, ou outro que eu não conheça )é a melhor opção.
Não represento nenhum serviço deste mas segundo o site do DynDNS eles
tem tantos servidores espalhados geograficamente que o serviço fica
virtualmente 100% UP.
Com isto não precisa ficar quebrando a cabeça com muitas soluções.


>
> -----Mensagem original-----
> De: gter-bounces at eng.registro.br [mailto:gter-bounces at eng.registro.br] Em
> nome de Marcos Pitanga
> Enviada em: quarta-feira, 2 de maio de 2012 22:44
> Para: juliano at kinghost.com.br; Grupo de Trabalho de Engenharia e Operacao de
> Redes
> Assunto: Re: [GTER] balanceamento de sites
>
> Será?
>
> Você já leu sobre o Linkproof e o AppDirector da Radware?
>
> []'s
>
>
>
> Em 2 de maio de 2012 20:41, Juliano Primavesi | KingHost <
> juliano at kinghost.com.br> escreveu:
>
>>
>> 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<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<https://eng.registro.
>>> br/mailman/listinfo/gter>
>>>
>>>
>>>  --
>> gter list
> https://eng.registro.br/**mailman/listinfo/gter<https://eng.registro.br/mail
> man/listinfo/gter>
>>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter


-- 
Otavio Augusto
---------------------
Consultor de TI
Citius Tecnologia
31 37761866
31 88651242
http://www.citiustecnologia.com.br