Tornando aplicativos hospedados resilientes a falhas do BGP

Question

Minha empresa cria vários sites para seus clientes com um provedor de hospedagem dedicado.

Este provedor de hospedagem acidentalmente encerra os dispositivos responsáveis pelos anúncios do Border Gateway Protocol (BGP) para uma pequena faixa de IPs. Como tenho sorte assim, um desses IPs era o endereço IP público atribuído ao balanceador de carga para todo o tráfego da Web para nossos clientes. Como resultado, o anúncio de roteamento do BGP para esse intervalo foi retirado e rapidamente se tornou inacessível em todo o mundo.

O provedor de hospedagem corrigiu o problema uma vez alertado, mas isso nos custou mais de 15 minutos de inatividade, o que estamos ansiosos para evitar no futuro.

1. Como poderíamos monitorar isso? É um nível muito inferior ao nosso monitoramento normal, que apenas verifica o status do apache httpd, JVMs, etc. Temos monitoramento interno que usa o Advent AppEngine para verificar processos do servidor, respostas de status do servidor apache, respostas de home page do aplicativo.

2. Somos capazes de tomar medidas para corrigir isso nós mesmos; por exemplo. fazendo nossos próprios anúncios de BGP de alguma forma?

Estou feliz por sugestões / leituras sugeridas, em vez de apenas respostas diretas, já que este nível da pilha é completamente novo para mim e gostaria de preencher as lacunas do meu conhecimento.

    

Answer 1

É improvável que você consiga resolver isso, a menos que seu espaço de endereçamento seja grande o suficiente para que você possa executar seu próprio BGP. Mesmo assim, você está vulnerável a falhas do BGP por seus colegas.

Se você estiver usando vários servidores DNS em AS separados, poderá conseguir algum tipo de trabalho configurando um TTL baixo e failover para um servidor da Web separado em um netblock / data center diferente alterando o DNS uma vez problemas são anotados. Até mesmo isso levará vários minutos, no mínimo.

EDIT: como apontado por Chris, se você está rodando o BGP, você precisa que todos seus colegas falhem antes de você se tornar inacessível.

    

Answer 2

É improvável que você consiga executar o BGP, a menos que tenha pelo menos um / 23 de espaço de endereço Independente do Provedor e tenha um número ASN. Como tal, você precisa confiar em sua empresa de hospedagem. Mudanças de roteador tendem a ser bastante raras, então a probabilidade de esse problema acontecer novamente é pequena. Você pode investigar qualquer SLA que você tenha com eles, mas isso provavelmente envolverá o reembolso das taxas de hospedagem.

No que diz respeito à monitoração, temos um servidor dedicado fora de nossa rede, que usamos como um servidor externo Nagios. Você poderia comprar um servidor VPS barato e usá-lo para monitorar as coisas do PoV de um usuário externo. Por exemplo, verificamos o trabalho de SMTP e HTTP, em vez de verificar se o exim e o apache estão em execução, o que fazemos em nosso monitoramento interno.

    

Answer 3

Para o registro, existem vários sistemas grátis de monitor e alarme BGP. Nenhum fornece uma resolução de 15 min como você deseja. E, como você pode ter muitas outras causas de interrupção, monitorar a conectividade IP de fora é a única solução real.

• Cyclops
• RIPE É
• BGPmon , meu favorito

Um artigo geral sobre o monitoramento do BGP, em francês .

    

Answer 4

Dependendo de como as coisas são configuradas, do tamanho do netblock anunciado e de como as coisas são agregadas no upstream, você pode usar um dos scripts para monitorar os anúncios do BGP para o bloco em que seu servidor está. / p>

Pode ser mais fácil simplesmente executar ping no host e no roteador, a partir do servidor, a partir do exterior. Você pode usar traceroute para determinar qual endereço usar.

Há muito pouco que você pode fazer para evitar que sua empresa de hospedagem faça isso novamente. Para fazer isso, você precisaria ter um roteador ou outro host executando o BGP conectado ao seu provedor, no mínimo. A menos que você também tenha outro provedor, ele não ajudará se eles acidentalmente desligarem o roteador de peering.

Uma solução melhor pode ser ter um site de failover, como mencionado por outra resposta. Dependendo da sua tolerância ao risco, você pode configurar o failover para acontecer em um tempo muito curto, mas envolve o controle completo do seu DNS.

    

Answer 5

Suas opções são bastante limitadas. Você pode gritar com o seu provedor, pode mudar para outro provedor, pode obter dois intervalos de IP diferentes e anunciar serviços em ambos e ter TTLs curtos em suas entradas de DNS.

Mas

Se você realmente quiser resolver isso, mude para uma instalação de "colo" com uma sala de reuniões e compre endereços de largura de banda e IP de alguns provedores. Em seguida, registre um ASN com o arin (ou qualquer que seja o registrador correto para onde quer que você more) e observe com os provedores.

Se você está comprando largura de banda suficiente, não será difícil fazer com que eles ganhem um / 24 ou / 23. O peering também será bem fácil, dependendo do tamanho da instalação do colo e da quantidade de largura de banda que você solicitará.

Se você está escrevendo grandes cheques e age como se soubesse exatamente o que você quer (e o que você quer é razoável), não é difícil fazer essas coisas. Se você cultivar para o seu "provedor", você sempre estará na extremidade do bastão.

    

Answer 6

1. Você pode monitorar os anúncios de seu provedor perguntando aos servidores de rotas públicas ( link ) sobre o prefixo que você está usando . Você pode automatizar esse tipo de monitoramento telnetando esses servidores de rota.
2. Se você usar largura de banda suficiente, tiver o orçamento e as habilidades necessárias para essa implantação, poderá solicitar um número AS e um intervalo de endereços IP. No entanto, isso é caro e, como os RIRs estão saindo dos endereços IPv4, você terá que fornecer uma prova real de suas necessidades.