Site e banco de dados hospedados em vários datacenters

Question

Recentemente, tivemos uma grande interrupção no data center do nosso provedor de hospedagem. Eles perderam uma conexão de fibra, causando uma interrupção de 9 horas, em que a maioria dos nossos clientes não conseguiu se conectar.

Isso nos levou a considerar hospedar nosso site em dois datacenters independentes.

O site é um site asp.net com banco de dados Sql 2008. Eu li alguns artigos sobre IP round-robin, IP anycast, etc.

Este é um novo terror para mim, então estou bastante perdido por onde começar.

Eu tenho algumas perguntas:

1. Como podemos hospedar o banco de dados em dois datacenters e ainda mantê-los em sincronia
2. Um centro de dados teria que agir como o principal?
3. Gostaria que todos os usuários acessassem o datacenter1, mas, no caso de 1 não estar disponível, gostaria que o tráfego fosse movido para o datacenter 2. Como isso pode ser conseguido?

Estas são apenas algumas perguntas para começar. Se alguém puder me dar uma visão geral de como lidar com isso ou me indicar algum recurso que ajude, será muito apreciado.

    

Answer 1

Isso é muito difícil de alcançar. Sério.

O SQL Server não funciona tão bem com links de alta latência (alta latência, neste caso, é > = 1Ms) para espelhamento e armazenamento em cluster, que são os únicos dois métodos disponíveis para garantir dados atualizados. Você precisa alternar para replicação ou envio de logs se tiver alguma latência. Caso contrário, seu banco de dados sofrerá de maneira dramática em termos de velocidade de leitura e gravação.

Em termos de anycasting, isso requer uma rede DNS muito robus. Existem provedores de DNS que podem fazer isso por você.

Para o round robin / failover do DNS, isso geralmente é aceito como um método muito ruim de fazer failover, mas pode ser "bom o suficiente" se o seu SLA com seus clientes puder acomodá-lo. Se você tiver um TTL baixo (digamos, de 5 a 30 minutos), poderá entrar e virar seus registros de DNS para apontar para seu segundo datacenter e, em seguida, a maioria dos seus clientes voltará a ficar on-line em < 30 minutos (embora existam muitos cachers DNS quebrados, por isso a sua quilometragem pode variar).

Outra opção é usar alguma forma de alta disponibilidade incorporada em um SAN e hipervisor. O SRM da VMWare vem à mente. Se a sua SAN puder fazer replicação em nível de bloco de LUNs iSCSI e você tiver um cluster VMWare devidamente licenciado, o VMWare poderá então inicializar o seu site de desastre quando detectar que o site principal ficou offline. Com o vSphere 5 fazendo grandes melhorias no número de vCPUs e alocações de vRAM, isso agora pode ser viável para servidores SQL grandes. No entanto, requer um enorme investimento em termos de $ e infra-estrutura.