Arquitetura para MySQL altamente disponível com failover automático em locais fisicamente diversos

Tenho pesquisado soluções de alta disponibilidade (HA) para MySQL entre data centers.

Para servidores localizados no mesmo ambiente físico, eu preferi o mestre duplo com pulsação (VIP flutuante) usando uma abordagem passiva ativa. O batimento cardíaco é realizado tanto por uma conexão serial quanto por uma conexão Ethernet.

Por fim, meu objetivo é manter esse mesmo nível de disponibilidade, mas entre data centers. Desejo realizar failover dinamicamente entre os dois data centers sem intervenção manual e ainda manter a integridade dos dados.

Haveria BGP no topo. Clusters da Web em ambos os locais, com potencial para rotear para os bancos de dados entre os dois lados. Se a conexão com a Internet fosse desativada no site 1, os clientes passariam pelo site 2, para o cluster da Web e depois para o banco de dados no site 1, se o link entre os dois sites ainda estiver ativo.

Nesse cenário, devido à falta de vínculo físico (serial), há uma chance mais provável de dividir o cérebro. Se a WAN diminuísse entre os dois sites, o VIP terminaria nos dois sites, onde uma variedade de cenários desagradáveis ​​poderia introduzir dessincronização.

Outro problema em potencial que vejo é a dificuldade de dimensionar essa infraestrutura para um terceiro data center no futuro.

A camada de rede não é um foco. A arquitetura é flexível nesta fase. Mais uma vez, meu foco é uma solução para manter a integridade dos dados e o failover automático nos bancos de dados MySQL. Eu provavelmente projetaria o resto em torno disso.

Você pode recomendar uma solução comprovada para o MySQL HA entre dois sites fisicamente diversos?

Obrigado por separar um tempo para ler isso. Estou ansioso para ler suas recomendações.

Você enfrentará o problema do teorema "CAP". Você não pode ter consistência, disponibilidade e tolerância à partição ao mesmo tempo.

O DRBD / MySQL HA depende da replicação síncrona no nível do dispositivo de bloco. Isso é bom enquanto os dois nós estão disponíveis ou, se alguém sofre uma falha temporária, é reinicializado etc., e volta. Os problemas começam quando você obtém uma partição de rede.

As partições de rede são extremamente prováveis ​​quando você está executando em dois datacenters. Essencialmente, nenhuma das partes pode distinguir uma partição do outro nó com falha. O nó secundário não sabe se deve assumir (o principal falhou) ou não (o link se foi).

Enquanto suas máquinas estão no mesmo local, você pode adicionar um canal secundário de comunicação (normalmente um cabo serial ou uma Ethernet cruzada) para contornar esse problema - para que o secundário saiba quando o primário está realmente inativo e não é uma partição de rede .

O próximo problema é o desempenho. Embora o DRBD possa ter um desempenho decente ** quando suas máquinas tiverem uma conexão de baixa latência (por exemplo, Ethernet gigabit - mas algumas pessoas usam redes dedicadas de alta velocidade), quanto mais latência a rede tiver, mais tempo será necessário para confirmar uma transação *** . Isso ocorre porque ele precisa aguardar o servidor secundário (quando estiver online) para confirmar todas as gravações antes de dizer "OK" ao aplicativo para garantir a durabilidade das gravações.

Se você fizer isso em diferentes datacenters, normalmente terá mais alguns milissegundos de latência, mesmo que eles estejam por perto.

** Ainda muito mais lento que um controlador de E / S local decente

*** Você não pode usar o MyISAM para um sistema DRBD de alta disponibilidade, porque ele não se recupera corretamente / automaticamente de um desligamento imundo, necessário durante um failover.

Que tal usar uma VLAN para amarrar todos os servidores nos dois (ou mais) data centers juntos. Você poderia usar o CARP para failover automático. Use a replicação de banco de dados para manter tudo sincronizado.

Se você possui os data centers, pode garantir que cada data center tenha vários uplinks de WAN.

Seu primeiro estágio deve ser o upgrade da sua solução atual de HA para uma que use o OpenAIS como a camada de associação do Cluster: isso lhe dará muita flexibilidade e os links de baixa latência entre sites podem ser alcançados. O PaceMaker e o RHEL Clustering suportam isso.

Para failover automático de data center, você realmente precisa de um terceiro site para atuar como desempatador, caso contrário, seus sites não poderão distinguir entre problemas de roteamento entre sites e falha de site remoto. A Microsoft tem alguns web-cast surpreendentemente bons que cobrem a área:

Cluster de vários sites do Windows Server 2008

Obviamente, a tecnologia exata não é mapeada para o domínio Linux, mas os conceitos são os mesmos.

Desculpe, esta é mais uma rede à parte, mas um pensamento para a estrada ...

Para o cenário de cérebro dividido que você mencionou, você pode ter links redundantes entre dois sites, além de diminuir a chance de isso acontecer.

Observe que você provavelmente não pode usar o BGP, pois o menor bloco roteável é 4k, a / 22, boa sorte em obter um. Provavelmente é necessária uma solução baseada em DNS.

Dar uma resposta correta pode ser difícil, dependendo da quantidade de dados que você possui, da quantidade de servidores em que você deseja encaixar isso, etc. Dito isto, minha resposta pode não ser uma, ou pelo menos a que você está procurando.

Não há solução comprovada para vários sites com o MySQL. Mas há uma solução que funciona. Como alguns salientaram, sim, o DRDB funciona bem, mas tem seu limite ou possível problema, dependendo da sua configuração.

Você precisará de um terceiro site (outro datacenter)? Se sim, quanto tempo e dinheiro você terá para fazer isso?

Considerando cada vez que você adiciona um servidor master / slave / dns, backups, ... você adiciona um servidor para gerenciar, qual é a sua capacidade de gerenciamento em termos de número de servidores? Se você pode definir esse número, talvez seja necessário descartar algumas soluções possíveis e trabalhar em direção àquelas que se encaixam nos seus números, para que o gerenciamento não se torne um gargalo.

Considerando que os datacenters não são desativados com frequência, vários sites significam balanceamento de carga e alguns hackers no DNS, isso será no mesmo datacenter? Nesse caso, se um datacenter for desativado por qualquer motivo, você terá problemas porque boa parte do DNS e do balanceamento de carga estará nesse datacenter.

Então você pode ter que planejar a situação do cérebro dividido. Para cada uma das configurações possíveis, a maneira de resolver uma situação no cérebro é diferente. Além disso, cada solução leva X uma quantidade de tempo.
Também pode ser muito mais fácil planejar o uso de três datacenters desde o início. Eu não sou especialista em MySQL, mas ouvi dizer que na produção era mais fácil ter 3 Masters do que 2, se você se deparar com algum problema.

Uma coisa que pode ajudá-lo é o serviço de balanceamento de carga oferecido por algum fornecedor de rede como o Zeus. Dê uma olhada aqui. Provavelmente, há muito mais oferecendo esse tipo de serviço. Tenho certeza de que tem um preço, mas às vezes permite reduzir algumas outras coisas.

Boa sorte!

O DRBD não é uma solução recomendada para data centers remotos, pois requer largura de banda que pode afetar a velocidade do seu banco de dados e replicação. A solução recomendada é Master - Master Replication. O único problema é que os campos de incremento automático precisam ser escalonados.

Se você precisar de uma solução realmente de alta disponibilidade para o MySQL, precisará usar o MySQL Cluster porque o DRBD não pode fornecer integridade aos dados em caso de falhas.

Eu encontrei posts sobre opções disponíveis no MySQL e seus prós e contras. http://mysqlha.blogspot.com/2010/04/consistency-across-wan.html

Superar a falta de um cabo serial é realmente muito fácil, você usa uma coisa da idade das trevas chamada modem - você tem uma em cada extremidade e executa o Heartbeat no link PPP. Você também pode usar o frame relay. Ambos os métodos corrigem qualquer preocupação que você tenha com os caminhos redundantes da camada 1/2.

No entanto, o que foi dito - o DRBD executado em qualquer link com muito mais do que cerca de 300µs (observe que 0,3ms) de latência se torna ridículo muito rapidamente.

Você seria melhor atendido usando a replicação padrão do MySQL e o LinuxHA sobre PPP & eth para realizar o failover.

Pelo menos foi o que fiz para os clientes no passado.