Como projetar um cluster MariaDB geograficamente distribuído

É muito comum ver bancos de dados distribuídos em várias localizações geográficas. Um cenário para fazer esse tipo de configuração é para recuperação de desastres, em que o datacenter em espera está localizado em um local separado do datacenter principal. Também pode ser necessário para que os bancos de dados estejam localizados mais próximos dos usuários.

O principal desafio para alcançar essa configuração é projetar o banco de dados de uma forma que reduza a chance de problemas relacionados ao particionamento da rede.

O MariaDB Cluster pode ser uma boa opção para construir esse ambiente por vários motivos. Gostaríamos de discuti-los aqui e também falar um pouco sobre como esse ambiente pode ser.

Por que usar o MariaDB Cluster para ambientes distribuídos geograficamente?

A primeira razão é que o MariaDB Cluster pode suportar vários escritores. Isso torna o roteamento de gravação muito mais fácil de projetar - basta gravar nos nós locais do MariaDB. É claro que, dada a replicação síncrona, a latência afeta o desempenho de gravação e você pode ver que suas gravações estão ficando mais lentas se você espalhar seu cluster geograficamente demais. Afinal, você não pode ignorar as leis da física e elas dizem, pelo menos por enquanto, que até a velocidade da luz nas conexões de fibra é limitada. Quaisquer roteadores adicionados a isso também aumentarão a latência, mesmo que apenas por alguns milissegundos.

Segundo, tratamento de lag no MariaDB Cluster. A replicação assíncrona é um assunto para atraso de replicação - os escravos podem não estar atualizados com os dados se tiverem dificuldade em aplicar todas as alterações a tempo. No MariaDB Cluster isso é diferente - o controle de fluxo é um mecanismo que visa manter o cluster em sincronia. Bem, quase - em alguns casos extremos, você ainda pode observar o atraso. Estamos falando aqui, normalmente, de milissegundos, alguns segundos no máximo, enquanto o céu de replicação assíncrona é o limite.

Terceiro, segmentos. Por padrão, o MariaDB CLuster usa a comunicação de todos para todos e cada conjunto de gravação é enviado pelo nó para todos os outros nós do cluster. Esse comportamento pode ser alterado usando segmentos. Os segmentos permitem que os usuários dividam os clusters MariaDB em várias partes. Cada segmento pode conter vários nós e elege um deles como um nó de retransmissão. Esses nós recebem conjuntos de gravação de outros segmentos e os redistribuem entre os nós MariaDB locais para o segmento. Como resultado, como você pode ver no diagrama acima, é possível reduzir três vezes o tráfego de replicação que passa pela WAN - apenas duas “réplicas” do fluxo de replicação estão sendo enviadas pela WAN:uma por datacenter comparada a uma por escravo na replicação assíncrona.

Finalmente, onde o MariaDB Cluster realmente se destaca é o manuseio do particionamento de rede. O MariaDB Cluster monitora constantemente o estado dos nós no cluster. Cada nó tenta se conectar com seus pares e trocar o estado do cluster. Se um subconjunto de nós não for alcançável, o MariaDB tentará retransmitir a comunicação para que, se houver uma maneira de alcançar esses nós, eles sejam alcançados.

Um exemplo pode ser visto no diagrama acima:DC 1 perdeu a conectividade com DC2, mas DC2 e DC3 podem se conectar. Neste caso, um dos nós em DC3 será usado para retransmitir dados de DC1 para DC2 garantindo que a comunicação intra-cluster possa ser mantida.

MariaDB pode realizar ações com base no estado do cluster. Ele implementa o quorum - a maioria dos nós precisa estar disponível para que o cluster possa operar. Se o nó for desconectado do cluster e não puder alcançar nenhum outro nó, ele deixará de operar.

Como pode ser visto no diagrama acima, há uma perda parcial da comunicação da rede no DC1 e o nó afetado é removido do cluster, garantindo que o aplicativo não acesse dados desatualizados.

Isso também é verdade em uma escala maior. O DC1 teve todas as comunicações cortadas. Como resultado, todo o datacenter foi removido do cluster e nenhum de seus nós atenderá ao tráfego. O resto do cluster manteve a maioria (6 de 9 nós estão disponíveis) e se reconfigurou para manter a conexão entre DC 2 e DC3. No diagrama acima, assumimos que o gravador atinge o nó no DC2, mas lembre-se de que o MariaDB é capaz de executar com vários gravadores.

Projetando um cluster MariaDB geograficamente distribuído

Passamos por alguns dos recursos que tornam o MariaDB Cluster uma boa opção para ambientes distribuídos geograficamente, vamos nos concentrar agora um pouco no design. No início, vamos explicar em que ambiente estamos trabalhando. Usaremos três data centers remotos, conectados via Wide Area Network (WAN). Cada datacenter receberá gravações de servidores de aplicativos locais. As leituras também serão apenas locais. Isso se destina a evitar tráfego desnecessário cruzando a WAN.

Para tornar este blog menos complicado, não entraremos em detalhes de como a conectividade deve ser. Assumimos algum tipo de conexão segura e configurada corretamente em todos os datacenters. VPN ou outras ferramentas podem ser usadas para implementar isso.

Usaremos MaxScale como balanceador de carga. O MaxScale será implantado localmente em cada datacenter. Ele também roteará o tráfego apenas para os nós locais. Nós remotos sempre podem ser adicionados manualmente e explicaremos os casos em que isso pode ser uma boa solução. Os aplicativos podem ser configurados para se conectar a um dos nós MaxScale locais usando um algoritmo round-robin. Também podemos usar Keepalived e Virtual IP para rotear o tráfego para o único nó MaxScale, desde que um único nó MaxScale seja capaz de lidar com todo o tráfego.

Outra solução possível é colocar MaxScale com nós do aplicativo e configurar o aplicativo para se conectar ao proxy no host local. Essa abordagem funciona muito bem sob a suposição de que é improvável que MaxScale não esteja disponível, mas o aplicativo funcionaria bem no mesmo nó. Normalmente, o que vemos é falha de nó ou falha de rede, o que afetaria o MaxScale e o aplicativo ao mesmo tempo.

O diagrama acima mostra a versão do ambiente, onde MaxScale forma farms de proxy - todos os nós proxy com a mesma configuração, balanceamento de carga usando Keepalived ou simplesmente round robin do aplicativo em todos os nós MaxScale. O MaxScale está configurado para distribuir a carga de trabalho em todos os nós MariaDB no datacenter local. Um desses nós seria escolhido como um nó para enviar as gravações enquanto os SELECTs seriam distribuídos por todos os nós. Ter um nó de gravador dedicado em um datacenter ajuda a reduzir o número de possíveis conflitos de certificação, levando, normalmente, a um melhor desempenho. Para reduzir ainda mais, teríamos que começar a enviar o tráfego pela conexão WAN, o que não é o ideal, pois a utilização da largura de banda aumentaria significativamente. No momento, com os segmentos implantados, apenas duas cópias do conjunto de gravação estão sendo enviadas pelos datacenters - uma por DC.

Conclusão