Esta é uma idéia de alta disponibilidade sólida (e barata) para o meu site e banco de dados se o ataque do zumbi?

Question

Eu tenho uma idéia de alta disponibilidade para failover do meu site, mas não tenho certeza se isso é bom, ruim ou um desastre em si.

Meu servidor principal hospeda um site ASP.net que usa um banco de dados do servidor SQL em outro servidor.

Ambos os servidores estão executando unidades RAID espelhadas, duas placas de rede, 2 switches etc. O provedor está garantindo 99,999% de tempo de disponibilidade, mas algo deu errado e demorou quase um dia antes de ser resolvido.

Estou mais preocupado com questões como problemas de nome de domínio / DNS que estão fora do nosso controle direto e podem levar de 6 a 24 horas para se propagar.

Ou para o caso de desastres generalizados que possam afetar nosso principal centro de dados, linhas de energia, infra-estrutura de conectividade de rede, sequestro de domínio e aumento de mortos-vivos;) etc.

Então, minha ideia é a seguinte: Hospede um segundo domínio em outro provedor em outro país. Chame o domínio de algo semelhante ao nome do site principal.

Tenha um servidor para o site e um servidor para o banco de dados SQL hospedado nesse provedor secundário. O servidor web é configurado e configurado com o site exatamente como o site principal.

Meus espelhos principais do servidor SQL (usando espelhamento de alto desempenho) para o servidor secundário no provedor secundário a cada 5 minutos.

Suponha que por algum motivo o site principal esteja inacessível devido a algo grande e desagradável acontecendo.

Mude o DNS para apontar para o domínio de backup e divulgue no twitter, facebook etc. que qualquer pessoa que precise do meu site pode usar o www.backupdomain.com até que as atualizações do dns se propaguem pela web.

Isso funcionaria e existe uma opção melhor que lidaria com problemas como esse?

A maioria das pesquisas que fiz apontaram falhas em clusters, balanceamento de carga, duplicar hardware, espelhamento e afins, o que eu sei que tornará a hospedagem local redundante, mas como eu lidei com interrupções mais amplas.

O orçamento também é limitado, então não podemos gastar milhões em um sistema super do Google. Mas algo que pode lidar com uma interrupção muito ruim e levar apenas 30 minutos a 1 hora de inatividade seria perfeito.

Dica, sugestões e links são bem-vindos.

    

Answer 1

As opções que você descreve não são ruins - na verdade, são boas, e o fato de você estar considerando isso fala bem de você.

Você certamente pode implementar o que descreveu acima ou usar um provedor de nuvem como um site de backup (muito menos dispendioso) como o ksm sugere abaixo, mas vou abordar alguns itens mais fundamentais primeiro.

Aqui está a ordem aproximada em que eu trabalharia:

1. Verifique se o seu provedor de hospedagem é decente
   Poder Redundante, Tubulações & Resfriamento no mínimo.

2. Verifique se seu ambiente é bem projetado.

3. Certifique-se de que seu ambiente tenha redundância (espelhos locais de tudo crítico, HA / Failover). Se o seu provedor for bom, seu design é bom e tudo é redundante para lidar com pelo menos uma falha de componente, você cuidou da maior parte de suas interrupções. Provavelmente, você também se deu a capacidade de realizar manutenção simultânea se o design do segundo item fosse bom.

4. Verifique se você tem backups. Certifique-se de que você pode restaurá-los e recuperar um sistema em funcionamento.

5. Teste os números 3 & 4 ( Pense como o Macaco do Caos e simule falhas)

6. Com 1-4 feito e sólido, considere agora como você replicaria isso para um local remoto no caso de um meteoro atingir o prédio do seu provedor.
   Se 2-4 acima foram bem feitos, esta parte deve ter caminhos de implementação óbvios e relativamente fáceis.

7. Teste o problema de falhar / voltar com o que você implementou no # 6.
   Um laboratório VMWare é muito útil aqui.

Note que não entrei em detalhes - Seu ambiente determinará como você procederá com cada uma das etapas acima.

    

Answer 2

Por que você não consegue uma instância na AWS? Obtenha uma instância no E2C , hospede seu aplicativo lá e deixe que ele se preocupe com o tempo de atividade.

Para ser duplamente certo, você poderia ter duas instâncias (a segunda como um hot backup, talvez) em diferentes regiões: uma em seu DC americano e outra em seu CD asiático.