OK, primeiro uma breve palestra: BGP é um protocolo de roteamento - Ele anuncia caminhos para alcançar o seu servidor (idealmente através de múltiplas conexões através de diferentes provedores e ao longo de diferentes caminhos físicos). O BGP é a mágica que encontra um novo caminho para uma determinada parte da internet quando alguém dirige uma retroescavadeira através de um grande cabo de fibra óptica. Praticamente todas as instalações de colocation que você hospeda rodam o BGP na sua ponta, e 99% delas são "automáticas" - Se não fosse a internet, seria tão estável quanto uma única. cadeira de pernas.
Da mesma forma, a maioria dos provedores de CoLo (pelo menos, qualquer um que você queira lidar) usa uma rede totalmente comutada, geralmente dividida em camadas de acesso e núcleo. Os melhores oferecerão vários caminhos até o núcleo para protegê-lo de uma interrupção no caso de um problema de comutador ou cabo.
Com um pouco de palestra, parece que você está fazendo uma pergunta geral sobre redundância, então darei algumas respostas gerais:
Se você tiver um único datacenter, terá um único ponto de falha (seja a Internet, energia, refrigeração ou erro humano, se o site em que você está desaparece da Internet por qualquer motivo que leve seus servidores com ele ).
A maioria das empresas CoLo tem boa redundância em todas as coisas que acabei de mencionar, mas várias falhas não são inéditas (eu estava envolvido em um pouco tempo atrás que levou uma instalação inteira e todos os seus clientes offline).
Ter dois sites com algum tipo de plano de failover para alternar entre eles não elimina o risco, mas o atenua: seu site principal pode ser ativado on-line (ou se ativar automaticamente) linha) para continuar as operações normais. Com algum trabalho de engenharia, isso pode acontecer com muito pouca interrupção visível para os usuários finais.
O problema é que você precisa projetar seus sistemas para lidar com o failover, e isso pode ser complexo e difícil dependendo exatamente do que você está tentando fazer (tornar um site que ofereça páginas estáticas redundantes é fácil - fazer um E-Commerce transacional site redundante requer substancialmente mais trabalho).
Quanto ao fornecedor único versus o múltiplo, se o Serviço de Colocation da John Smith tiver datacenters em continentes diferentes com provedores de upstream diferentes & (Obviamente) diferentes caminhos de conectividade física, você não terá mais nenhum benefício com a hospedagem de John Smith nos EUA e Jane Jones na Europa (e suas pessoas pagas podem preferir pagar uma grande fatura a um fornecedor aprovado em vez de para aprovar outro fornecedor e pagar duas contas.
Também pode-se argumentar que provedores maiores com uma presença multinacional provavelmente serão mais estáveis financeiramente (não é provável que saiam do negócio e que suas coisas desapareçam da internet), e se eles estiverem operando um ambiente multi-site para Por enquanto, eles terão uma experiência valiosa fazendo isso, algo que pode valer a pena levar em consideração se você achar que precisará de ajuda para configurar seu failover / redundância.
É um axioma de engenharia que o risco não pode ser eliminado: não importa quantas máquinas você tenha e onde você coloca um cenário de pesadelo, sempre pode ser concebido que resultará na explosão do sistema.
As coisas que você precisa considerar são:
- O nível de risco real (o custo do que poderia dar errado e a probabilidade de dar errado)
- O custo de atenuar esse risco
- O custo da recuperação se o risco se materializar em um evento
- Quaisquer obrigações contratuais que você ou sua empresa tenham Re: uptime, etc.
Com base nesses fatores, você pode decidir como deseja projetar seu ambiente e qual nível de redundância faz mais sentido para você.