[GTER] Estrutura de redundância

Carlos Roberto Maciel Carneiro carlos.roberto.maciel at gmail.com
Tue Jan 27 10:25:48 -02 2009


Antonio,

Cancela o seu link com a operadora, peça um PtP do DataCenter da operadora até o seu DataCenter principal e compre trânsito dentro do proprio DataCenter da operadora e de lá distribua para os seus servidores no seu DataCenter.

Nesse caso se o seu Datacenter "morrer" você mesmo refaz as rotas "internamente" sem precisar de "favor" da operadora que costuma ser ineficiente e lerda para tratar de urgências de clientes.

Atenciosamente,

CARLOS ROBERTO MACIEL CARNEIRO
carlos.roberto.maciel at gmail.com


----- Original Message ----- 

  From: Antonio Limeira 
  To: gter at eng.registro.br 
  Sent: Tuesday, January 27, 2009 10:11 AM
  Subject: [GTER] Estrutura de redundância


  Bom dia amigos,
  Sou novo na lista e gostaria de tirar umas dúvidas.

  Tenho a seguinte situação:

  - Datacenter principal com diversos servidores servindo SMTP, HTTP e
  HTTPS. Link de 34Mbps.
  - Contratamos uma rack dentro da nossa própria operadora de link e
  vamos colocar alguns servidores lá para redundância em caso de falha
  do Datacenter principal. Serão atribuídos um segmento de IPs para
  esses servidores. A intenção inical seria: em caso de falha
  irrecuperável no Datacenter principal, pediríamos para ela atribuir os
  endereços IP de servidores do datacenter principal nesses servidores
  que estão nesse rack dentro da operadora.

  A operadora falou que é inviável fazer isso (não tem processo, não tem
  gente pra mexer em rotas, etc.) e ela quer configurar algum esquema de
  BGP interno.

  Minhas dúvidas:
  1) Quão difícil é para a operadora mudar os IPs de um router dentro
  dela para encaminhar para outro router, que lançará para os servidores
  mortos no rack? É má vontade e preguiça deles ou é uma coisa chata de
  ser feita?

  2) No caso de falha, para a operadora mexer no BGP pra anunciar os
  novos IPs, não existe um tempo de aprendizagem na Internet? Quanto
  tempo eu ficarei "fora do ar" para que os servidores no rack passem a
  responder pelo tráfego entrante? Não seria mais simples rerotear os
  IPs do site principal para o rack do que fazer anúncio dessas rotas (e
  posteriormente parar o anúncio, uma vez que o site principal voltará
  em determinado momento)?

  3) No caso de termos que ir de BGP interno, os servidores no rack
  dentro da operadora são pra ficar offline, não acessados nesses
  serviços (SMTP, HTTP e HTTPS) pela Internet, a não ser em caso de
  falha grave no site principal. O BGP interno não vai anunciar isso
  para o mundo, certo?

  4) Em caso de ter quebrado o site principal, a operadora irá anunciar
  pro mundo o bloco de IPs do rack a fim de que o tráfego para o site
  principal caia nos servidores lá dentro. É preciso que eu tenha um
  servidor de DNS nesse rack com as mesmas zonas do site principal,
  nomes e endereços dos HTTP e HPTTS servers, SMTP servers, etc., porém
  apontando somente para os IPs desse bloco do rack? Como eu configuro
  esse DNS?

  5) É possível eu cadastrar esse DNS server como um resolver secundário
  do próprio datacenter, mesmo sem anúncio desse prefixo na Internet?
  Posso fazer transfers de zonas para ele e ele pode ser invocado pela
  Internet para resolver nomes localizados no site principal? Posso
  fazer isso ou nem tento misturar?

  6) Tenho um openBSD funcionando como roteador no site principal, porém
  ele já está no limite. Foi orçado para esse ano a compra de um
  roteador CISCO para entrar no lugar desse servidor. Receio que seja
  mais caro colocar um router com IOS atualizado do que, por exemplo,
  colocar um servidor Dell caprichado rodando um openBSD com um software
  para rodar BGP (considerando que existe crescimento estimado para os
  próximos 2 anos para 155Mbps). Portanto, o router cisco que iremos
  comprar tem que suportar, de cara, 155Mbps). O que é mais confiável
  (barato e escalável também): um Cisco ou um Dell caprichado rodando
  openBSD? (não possuo experiência nem com cisco nem com unix pra rodar
  BGP - alguém com bastante experiência no Rio de Janeiro que possa
  entrar em contato PVT para nos ajudar nisso?)

  7) Uma vez restabelecido o site principal (após a falha
  irrecuperável), é só a operadora parar o anúncio dos IPs do rack para
  que o acesso passe a ser pelo site principal? Isso é instantâneo ou
  leva algum tempo para acontecer? (Esse tempo é muito longo?)

  8) Supondo que eu tenha que ter um servidor de DNS nesse rack na
  operadora, ele irá resolver IPs que na verdade estariam "mortos" pro
  mundo (os servidores SMTP, HTTP, HTTPS). Se eu quiser usar esse DNS
  como secundário (mesmo para o site principal), existirá tráfego para
  esses servidores pelo mundo externo, certo?
  exemplo:
  mail     A     200.200.200.1 (site principal)
  mail     A     200.200.180.1 (rack na operadora)
  sitedascouves    A    200.200.200.7 (site principal)
  sitedascouves    A    200.200.180. 7 (rack na operadora)

  Emails entrarão nesse servidor do rack, certo? Se eu colocar um MX com
  preference muito alto não cairá emails nele? No caso de tráfego para
  HTTP e HTTPS entrar nesses servidores, o que faço? Boto uma página
  redirecionando para o site principal? Essa solução é elegante?
  Ou é besteira colocar esse DNS para resolver nomes para o site principal?


  Muitíssimo obrigado pela paciência em ler esse email e pela eventual ajuda!
  Antonio Limeira
  --
  gter list    https://eng.registro.br/mailman/listinfo/gter



More information about the gter mailing list