[GTER] balanceamento de sites
Francisco Neto
fjbvneto at gmail.com
Thu May 3 01:33:40 -03 2012
Concordo também que a melhor solução, se inicia com você ser AS, logo ter e
operar seu próprio bloco de ip´s e no BGP configurar seu anúncio em cada
DC. Não creio que, seja necessário investir em uma solução baseada em
appliance (salvo CAPEX x OPEX for realmente vantajoso, mas não vejo
realmente como, não consigo imaginar operar assim na internet (com uma
certa complexidade, acima o acesso simples e single homed) sem ser sistema
autonomo, mesmo com uma rede pequena /25, /26 até, dependendo do que seja,
dá para o gasto inclusive. E ai sim, é desenhar a rede pegar os recursos de
transito, posicionar e configurar os peers ebgp com tabela completa (full
routing).
SDS,
---
Em 3 de maio de 2012 01:15, <gter-request at eng.registro.br> escreveu:
> Send gter mailing list submissions to
> gter at eng.registro.br
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://eng.registro.br/mailman/listinfo/gter
> or, via email, send a message with subject or body 'help' to
> gter-request at eng.registro.br
>
> You can reach the person managing the list at
> gter-owner at eng.registro.br
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of gter digest..."
>
>
> Today's Topics:
>
> 1. Re: balanceamento de sites (Juliano Primavesi | KingHost)
> 2. Re: PTT-Metro SP - Tr?fego de provedores de conte?do
> (Juliano Primavesi | KingHost)
> 3. Re: PTT-Metro SP - Tr?fego de provedores de conte?do
> (Juliano Primavesi | KingHost)
> 4. Re: balanceamento de sites (Artur Renato Araujo da Silva)
> 5. Re: balanceamento de sites (Juliano Primavesi | KingHost)
> 6. Re: balanceamento de sites (Marcos Pitanga)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 02 May 2012 20:41:14 -0300
> From: Juliano Primavesi | KingHost <juliano at kinghost.com.br>
> To: Grupo de Trabalho de Engenharia e Operacao de Redes
> <gter at eng.registro.br>
> Subject: Re: [GTER] balanceamento de sites
> Message-ID: <4FA1C61A.60506 at kinghost.com.br>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
> 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
> >
> >
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 02 May 2012 20:42:34 -0300
> From: Juliano Primavesi | KingHost <juliano at kinghost.com.br>
> To: Grupo de Trabalho de Engenharia e Operacao de Redes
> <gter at eng.registro.br>
> Subject: Re: [GTER] PTT-Metro SP - Tr?fego de provedores de conte?do
> Message-ID: <4FA1C66A.1080001 at kinghost.com.br>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> 40%
>
> Em 02/05/2012 17:09, Rubens Kuhl escreveu:
> > Pessoal,
> >
> > Algu?m que seja provedor de conte?do com foco no mercado brasileiro e
> > esteja conectado ao PTT-Metro de SP poderia dar uma id?ia de
> > percentagem de tr?fego de redes de acesso que o ATM (n?o peerings
> > bilaterais) absorva ?
> > Se poss?vel com conex?o apenas ao PTT-Metro SP e tr?nsitos, n?o outros
> > pontos de peering em outras cidades (ou outras matrizes em SP).
> >
> >
> >
> > Rubens
> > --
> > gter list https://eng.registro.br/mailman/listinfo/gter
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 02 May 2012 20:44:31 -0300
> From: Juliano Primavesi | KingHost <juliano at kinghost.com.br>
> To: Grupo de Trabalho de Engenharia e Operacao de Redes
> <gter at eng.registro.br>
> Subject: Re: [GTER] PTT-Metro SP - Tr?fego de provedores de conte?do
> Message-ID: <4FA1C6DF.20302 at kinghost.com.br>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
> Corre??o...
>
> ~34% PTT-METRO-SP (priorit?rio)
> ~6% TERREMARK (com segunda prioridade)
>
> Juliano
>
> Em 02/05/2012 17:09, Rubens Kuhl escreveu:
> > Pessoal,
> >
> > Algu?m que seja provedor de conte?do com foco no mercado brasileiro e
> > esteja conectado ao PTT-Metro de SP poderia dar uma id?ia de
> > percentagem de tr?fego de redes de acesso que o ATM (n?o peerings
> > bilaterais) absorva ?
> > Se poss?vel com conex?o apenas ao PTT-Metro SP e tr?nsitos, n?o outros
> > pontos de peering em outras cidades (ou outras matrizes em SP).
> >
> >
> >
> > Rubens
> > --
> > gter list https://eng.registro.br/mailman/listinfo/gter
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 2 May 2012 22:35:43 -0300
> From: Artur Renato Araujo da Silva <artur at css.com.br>
> To: juliano at kinghost.com.br, Grupo de Trabalho de Engenharia e
> Operacao de Redes <gter at eng.registro.br>
> Subject: Re: [GTER] balanceamento de sites
> Message-ID:
> <CABK_+epV7kNe33M=TKMA60FFXJTXhnORrn=vZAvJ5BNCSVcodw at mail.gmail.com
> >
> Content-Type: text/plain; charset=ISO-8859-1
>
> Em 2 de maio de 2012 20:41, Juliano Primavesi | KingHost <
> juliano at kinghost.com.br> escreveu:
>
> >
> > CDN serve apenas para conte?do EST?TICO.
> >
>
> CDN funciona sim para conte?do din?mico. Basta fazer a escolha pelo
> provedor e produto adequado.
>
> Existem produtos que fazem acelera??o para conte?do din?mico (usando
> t?cnicas de cache *e* acelera??o de rede/HTML) e balanceamento com checagem
> de origem.
>
> Artur
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 02 May 2012 23:44:45 -0300
> From: Juliano Primavesi | KingHost <juliano at kinghost.com.br>
> To: Grupo de Trabalho de Engenharia e Operacao de Redes
> <gter at eng.registro.br>
> Subject: Re: [GTER] balanceamento de sites
> Message-ID: <4FA1F11D.4000508 at kinghost.com.br>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
> S?o coisas diferentes.
>
> Se voce n?o tem BGP, depende dos IP dos datacenters. Que v?o apontar
> apenas para os respectivos datacenters.
>
> IDC1 - 189.1.0.10
> IDC2 - 177.200.1.10
>
> O usu?rio final vai receber um IP, que ser? 189.1.0.10 e/ou 177.200.1.10.
>
> O IP 189.1.0.10 vai estar necessariamente no IDC 1
> O IP 177.200.1.10 vai estar necessariamente no IDC 2
>
> Nao existe como acessar o IP 177.200.1.10 e ele levar ao IDC 1
>
> Por isso a solu??o de TTL de DNS ? a que melhor se aplica. A
> persist?ncia do acesso acaba sendo no dominio, que apontar? para quem
> estiver online (que ser? o IDC que responder).
>
> Juliano
>
> Em 02/05/2012 22:43, Marcos Pitanga escreveu:
> > 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 <mailto: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> <mailto: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>
> > <mailto: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>
> > <mailto: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
> >
> >
> > --
> > gter list https://eng.registro.br/mailman/listinfo/gter
> >
> >
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 2 May 2012 22:43:51 -0300
> From: Marcos Pitanga <marcos.pitanga at gmail.com>
> To: juliano at kinghost.com.br, Grupo de Trabalho de Engenharia e
> Operacao de Redes <gter at eng.registro.br>
> Subject: Re: [GTER] balanceamento de sites
> Message-ID:
> <CAOXrEAv2BqGjR3S9jJu=PkPn1x_uH5PGW_Ds2Q9Xnw8xMbU-mA at mail.gmail.com
> >
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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/mailman/listinfo/gter>
> >
>
>
> ------------------------------
>
> --
> gter digest list https://eng.registro.br/mailman/listinfo/gter
>
> End of gter Digest, Vol 110, Issue 9
> ************************************
>
More information about the gter
mailing list