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

Question

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

Para servidores localizados no mesmo ambiente físico, eu preferi o dual master com heartbeat (VIP flutuante) usando uma abordagem passiva ativa. A pulsação é sobre uma conexão serial e uma conexão ethernet.

Por fim, meu objetivo é manter esse mesmo nível de disponibilidade, mas entre os data centers. Eu quero dinamicamente o failover 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, que teriam o potencial de direcionar para os bancos de dados entre os dois lados. Se a conexão com a Internet fosse interrompida no site 1, os clientes roteariam pelo site 2, pelo cluster da Web e pelo banco de dados no site 1, se o link entre os dois sites ainda estivesse ativo.

Com este cenário, devido à falta de ligação física (serial), há uma chance mais provável de dividir o cérebro. Se a WAN baixasse entre os dois sites, o VIP acabaria em ambos os sites, onde uma variedade de cenários desagradáveis poderia introduzir a 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 neste estágio. Mais uma vez, meu foco é uma solução para manter a integridade dos dados, bem como o failover automático com os 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 ler isto. Estou ansioso para ler suas recomendações.

    

Answer 1

Você enfrentará o problema do teorema "CAP". Você não pode ter consistência, disponibilidade e tolerância a 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 ambos os nós estão disponíveis, ou se alguém sofre uma falha temporária, é reinicializado etc, então volta. Os problemas começam quando você começa 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 da falha do outro nó. O nó secundário não sabe se deve assumir (o primário falhou) ou não (o link sumiu).

Enquanto suas máquinas estão no mesmo local, você pode adicionar um canal secundário de comunicação (normalmente um cabo serial ou crossover ethernet) para contornar este problema - assim o secundário sabe quando o primário é GENUÍVEL para baixo, e não é uma partição de rede.

O próximo problema é o desempenho. Embora o DRBD possa dar um desempenho decente quando suas máquinas têm uma conexão de baixa latência (por exemplo, gigabit ethernet - mas algumas pessoas usam redes dedicadas de alta velocidade), quanto mais latência a rede tiver, mais tempo levará para cometer uma transação *** . Isso porque ele precisa esperar que o servidor secundário (quando estiver on-line) reconheça todas as gravações antes de dizer "OK" ao aplicativo para garantir a durabilidade das gravações.

Se você fizer isso em datacenters diferentes, normalmente terá vários latência de milissegundos, mesmo que estejam próximos.

** Ainda muito mais lento que um controlador IO local decente

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

    

Answer 2

Que tal usar uma VLAN para unir todos os servidores nos dois (ou mais) centros de dados. Você poderia então usar o CARP para o 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.

    

Answer 3

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

Para o failover automático de data center, você realmente precisa de um terceiro site para atuar como um desempatador; caso contrário, seus sites não conseguirão distinguir entre problemas de roteamento entre sites e falhas no site remoto. A Microsoft tem alguns webcasts surpreendentemente bons cobrindo a área:

Clustering de vários sites do Windows Server 2008

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

    

Answer 4

Desculpe, esta é mais uma rede à parte, mas um pensamento para o futuro ...

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

    

Answer 5

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

    

Answer 6

Dar uma resposta correta pode ser difícil, dependendo da quantidade de dados que você tem, da quantidade de servidores que você quer encaixar, etc. Dito isso, minha resposta pode não ser uma, ou pelo menos aquela que você é procurando por.

Não há solução comprovada para vários sites com o MySQL. Mas há solução que funciona. Como alguns salientaram, sim, o DRDB funciona bem, mas tem seu limite ou possível problema dependendo de 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ê puder definir esse número, talvez seja necessário descartar algumas soluções possíveis e trabalhar em direção àquelas que se encaixam em seus números, para que o gerenciamento não se torne um gargalo.

Considerando que os datacenters não diminuem com frequência, vários sites significam balanceamento de carga e alguns hacks de DNS, isso está no mesmo datacenter? Em caso afirmativo, se um datacenter ficar inativo por qualquer motivo, você terá problemas porque uma boa parte de seu DNS e seu balanceamento de carga será nesse datacenter.

Então você pode ter que planejar a situação do cérebro dividido. Para almsot cada configuração possível, a maneira de resolver uma situação do cérebro é diferente. Além disso, cada solução leva X quantidade de tempo.
Também pode ser muito mais fácil planejar o uso de 3 datacenter desde o início. Não sou especialista em MySQL, mas ouvi dizer que na produção era mais fácil ter 3 mestres do que 2 se você se deparasse com problemas.

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 aqui Provavelmente há muitos mais oferecendo esse tipo de serviço. Tenho certeza que isso tem um preço, mas às vezes permite que você reduza algumas outras coisas.

Boa sorte!

    

Answer 7

O DRBD não é uma solução recomendada para data centers remotos, pois exige 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 com isso é que os campos de incremento automático precisam ser escalonados.

Se você precisar de uma verdadeira solução de HA para o MySQL, você teria que usar o MySQL Cluster, porque o DRBD não pode fornecer integridade de dados em caso de falhas.

    

Answer 8

Eu encontrei posts sobre as opções disponíveis no MySQL e seus prós e contras. link

    

Answer 9

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 ponta e então roda o Heartbeat pelo link PPP. Você também pode usar o frame relay. Os dois métodos consertarão todas as preocupações que você tiver com os caminhos redundantes da camada 1/2.

No entanto, dito isto - o DRBD rodando sobre qualquer link com muito mais do que 300µs (note que 0.3ms) a latência se torna ridícula muito rapidamente.

Você seria melhor servido usando a replicação padrão do MySQL e o LinuxHA sobre PPP & eth para fazer o fail overs.

Pelo menos é o que fiz para clientes no passado.