Opções de failover de cluster de banco de dados completo multinuvem para cluster MariaDB

Com a alta disponibilidade sendo primordial na realidade empresarial atual, um dos cenários mais comuns para os usuários lidarem é como garantir que o banco de dados esteja sempre disponível para o aplicativo.

Todo provedor de serviço vem com um risco herdado de interrupção do serviço, portanto, uma das etapas que podem ser tomadas é contar com vários provedores para aliviar o risco e redundância adicional.

Os provedores de serviços em nuvem não são diferentes - eles podem falhar e você deve planejar isso com antecedência. Quais opções estão disponíveis para o MariaDB Cluster? Vamos dar uma olhada nisso neste post do blog.

Agrupamento de banco de dados MariaDB em ambientes multinuvem

Se o SLA proposto por um provedor de serviços de nuvem não for suficiente, sempre há a opção de criar um site de recuperação de desastres fora desse provedor. Graças a isso, sempre que um dos provedores de nuvem sofrer alguma degradação do serviço, você sempre poderá mudar para outro provedor e manter seu banco de dados ativo e disponível.

Um dos problemas típicos das configurações de várias nuvens é a latência da rede, inevitável se estivermos falando de distâncias maiores ou, em geral, de vários locais separados geograficamente. A velocidade da luz é bastante alta, mas é finita, cada salto, cada roteador também adiciona alguma latência à infraestrutura de rede.

O MariaDB Cluster funciona muito bem em redes de baixa latência. É um cluster baseado em quórum em que a comunicação imediata entre todos os nós é necessária para manter as operações tranquilas. O aumento na latência da rede afetará as operações do cluster, especialmente o desempenho das gravações. Existem várias maneiras de resolver esse problema.

Primeiro temos a opção de usar clusters separados conectados usando links de replicação assíncrona. Isso nos permite quase esquecer a latência porque a replicação assíncrona é significativamente mais adequada para trabalhar em ambientes de alta latência.

Outra opção é que, dadas as redes de baixa latência entre datacenters, você ainda pode executar um cluster MariaDB em vários datacenters. Afinal, vários datacenters nem sempre significam grandes distâncias geograficamente - você também pode usar vários provedores localizados na mesma área metropolitana, conectados com redes rápidas e de baixa latência. Então falaremos sobre o aumento da latência para dezenas de milissegundos no máximo, definitivamente não centenas. Tudo depende da aplicação, mas tal aumento pode ser aceitável.

Replicação assíncrona entre clusters MariaDB

Vamos dar uma olhada rápida na abordagem assíncrona. A ideia é simples - dois clusters conectados entre si usando replicação assíncrona.

Isso vem com várias limitações. Para começar, você precisa decidir se deseja usar vários mestres ou enviar todo o tráfego para apenas um datacenter. Recomendamos evitar gravar em ambos os datacenters e usar a replicação mestre-mestre. Isso pode levar a problemas sérios se você não tomar cuidado.

Se você decidir usar a configuração ativa - passiva, provavelmente desejará implementar algum tipo de roteamento baseado em DNS para gravações, para garantir que seus servidores de aplicativos sempre se conectem a um conjunto de proxies localizados no datacenter ativo. Isso pode ser obtido por literalmente uma entrada DNS que seria alterada quando o failover é necessário ou pode ser feito por meio de algum tipo de solução de descoberta de serviço, como Consul ou etcd.

A principal desvantagem do ambiente construído usando a replicação assíncrona é a falta de capacidade de lidar com divisões de rede entre datacenters. Isso é herdado da replicação - não importa o que você deseja vincular à replicação (nós únicos, clusters MariaDB), não há como contornar o fato de que a replicação não reconhece o quorum. Não há mecanismo para rastrear o estado dos nós e entender a imagem de alto nível de toda a topologia. Como resultado, sempre que o link entre dois datacenters cair, você terá dois clusters MariaDB separados que não estão conectados e ambos estão prontos para aceitar tráfego. Caberá ao usuário definir o que fazer nesse caso. É possível implementar ferramentas adicionais que monitorem o estado dos bancos de dados de fora (ou seja, do terceiro datacenter) e, em seguida, tomem ações (ou não tomem ações) com base nessas informações. Também é possível colocar ferramentas que compartilhariam a infraestrutura com bancos de dados, mas seriam cientes de cluster e poderiam rastrear o estado da conectividade do datacenter e serem usadas como fonte de verdade para os scripts que gerenciariam o ambiente. Por exemplo, o ClusterControl pode ser implantado em um cluster de três nós, nó por datacenter, que usa o protocolo RAFT para garantir o quorum. Se um nó perder a conectividade com o restante do cluster, pode-se supor que o datacenter sofreu particionamento de rede.

Clusters MariaDB multi-DC

Uma alternativa à replicação assíncrona pode ser uma solução de cluster totalmente MariaDB que se estende por vários datacenters.

Como dito no início deste blog, o MariaDB Cluster, assim como todo Cluster baseado em Galera, será impactado pela alta latência. Dito isso, é perfeitamente aceitável executá-lo em ambientes de latência “não tão alta” e esperar que ele se comporte adequadamente, oferecendo desempenho aceitável. Tudo depende da taxa de transferência e design da rede, da distância entre os datacenters e dos requisitos do aplicativo. Essa abordagem funcionará muito bem, especialmente se usarmos segmentos para diferenciar data centers separados. Ele permite que o MariaDB Cluster otimize sua conectividade intracluster e reduza o tráfego entre DCs ao mínimo.

A principal vantagem dessa configuração é que ela depende do MariaDB Cluster para lidar com falhas. Se você usar três data centers, estará praticamente protegido contra a situação de cérebro dividido - enquanto houver uma maioria, ele continuará operando. Não é necessário ter um nó completo no terceiro datacenter - você também pode usar o Galera Arbitrator, um daemon que atua como parte do cluster, mas não precisa lidar com nenhuma operação de banco de dados. Ele se conecta aos nós, participa do cálculo de quorum e pode ser usado para retransmitir o tráfego caso a conexão direta entre os dois data centers não funcione.

Nesse caso, todo o processo de failover pode ser descrito como:definir todos os nós nos balanceadores de carga (todos se os data centers estiverem próximos uns dos outros; em outro caso, você pode querer adicionar alguma prioridade para o nós localizados mais próximos do balanceador de carga) e é basicamente isso. Os nós do cluster MariaDB que formam a maioria serão acessíveis por meio de qualquer proxy.

Implantando um cluster MariaDB multinuvem usando o ClusterControl

Vamos dar uma olhada em duas opções que você pode usar para implantar clusters MariaDB multinuvem usando o ClusterControl. Lembre-se de que o ClusterControl requer conectividade SSH para todos os nós que ele gerenciará, portanto, cabe a você garantir a conectividade de rede em vários datacenters ou provedores de nuvem. Enquanto houver conectividade, podemos prosseguir com dois métodos.

Implantando clusters MariaDB usando replicação assíncrona

ClusterControl pode ajudá-lo a implantar dois clusters conectados usando replicação assíncrona. Quando você tem um único cluster MariaDB implantado, você deseja garantir que um dos nós tenha logs binários habilitados. Isso permitirá que você use esse nó como mestre para o segundo cluster que criaremos em breve.

Depois que o log binário estiver habilitado, podemos usar o trabalho Create Slave Cluster para iniciar o assistente de implantação.

Podemos transmitir os dados diretamente do mestre ou você pode usar um dos backups para provisionar os dados.

Então você é apresentado a um assistente de implantação de cluster padrão onde você deve passar Detalhes de conectividade SSH.

Você também será solicitado a escolher o fornecedor e a versão dos bancos de dados conforme solicitado a senha para o usuário root.

Finalmente, você deve definir os nós que gostaria de adicionar ao cluster e está tudo pronto.

Quando implantado, você o verá na lista de clusters no Interface do usuário do ClusterControl.

Implantando o cluster MariaDB multinuvem

Como mencionamos anteriormente, outra opção para implantar o MariaDB Cluster seria usar segmentos separados ao adicionar nós ao cluster. Na interface do usuário do ClusterControl, você encontrará uma opção para “Adicionar nó”:

Ao usá-lo, você verá a seguinte tela:

O segmento padrão é 0, então você deseja alterá-lo para um valor diferente .

Depois que os nós forem adicionados, você pode verificar em qual segmento eles estão localizados na guia Visão geral:

Conclusão