Encontros presenciais, hoje em dia, são limitados ao mínimo, as atividades online assumiram como principal meio de interação professor-aluno. Aumentou o stress nas plataformas de “reunião” online existentes (há quem não saiba o que é o Zoom hoje em dia?) mas também nas plataformas de aprendizagem online. A alta disponibilidade das ferramentas online é mais importante do que nunca e as equipes de operação correm para construir arquiteturas duráveis e altamente disponíveis para seus ambientes.
Provavelmente, pelo menos alguns de vocês já usaram o Moodle - é uma plataforma de aprendizado on-line autônoma que você pode implantar no local e usá-la para fornecer treinamento on-line para sua organização. Como mencionamos, é mais importante do que nunca fazê-lo funcionar de maneira durável e altamente disponível. Gostaríamos de propor uma solução altamente disponível que envolve o MariaDB como banco de dados backend - tanto replicação assíncrona quanto Galera Cluster.
Processo de design do ambiente
Gostaríamos de começar com um processo em que explicaríamos o processo de pensamento por trás do design do ambiente para o Moodle. Queremos alta disponibilidade, portanto, um único nó de banco de dados não funciona para nós. Queremos vários nós e isso nos leva à primeira decisão de design. Devemos usar replicação assíncrona ou Galera Cluster? A segunda pergunta é:como vamos distribuir a carga de trabalho entre os nós? Comecemos pelo segundo.
A última versão do Moodle no momento em que este blog foi escrito (3.9) introduziu um bom recurso chamado leituras seguras. O problema a resolver aqui é ler depois de escrever. Quando você usa um nó, o mundo é um lugar simples. Você escreve e depois lê. Tudo o que você escreveu já está lá. Quando você adiciona nós, porém, as coisas mudam. Na replicação assíncrona, os escravos podem estar atrasados até dezenas de segundos ou mais. O que quer que você escreva no mestre pode levar até minutos (se não mais nos casos mais extremos) para ser aplicado ao escravo. Se você executar uma gravação e imediatamente tentar ler os mesmos dados de um dos escravos, poderá ter uma surpresa desagradável - os dados não estarão lá. O cluster Galera usa uma replicação “virtualmente” síncrona e neste caso específico “virtualmente” faz uma enorme diferença - o Galera não está imune aos problemas de leitura após gravação. Sempre há um atraso entre a execução de gravação no nó local e o conjunto de gravação sendo aplicado aos nós restantes do cluster. Claro, é mais provável que seja medido em milissegundos em vez de segundos, mas ainda pode quebrar a suposição de que você pode ler imediatamente o que escreveu. O único lugar onde você pode ler com segurança após a gravação é o nó no qual você gravou os dados.
Como o Moodle depende bastante da leitura após a gravação, não podemos dimensionar facilmente as leituras apenas adicionando mais nós para leitura. Para o Galera Cluster, podemos tentar mitigar o problema usando a configuração wsrep-sync-wait para forçar o Galera a garantir que as leituras sejam seguras para execução. Isso cria o impacto no desempenho do sistema, pois todas as leituras precisam aguardar que as gravações sejam aplicadas antes de poderem ser executadas. Esta também é uma solução para o MariaDB Cluster (e outras soluções baseadas em Galera), não para replicação assíncrona. Felizmente, a solução do Moodle resolve esse problema. Você pode definir uma lista de nós que podem estar atrasados e o Moodle os usará apenas para leituras que não precisam estar atualizadas com as gravações. Todas as leituras restantes que exigem que os dados estejam sempre atualizados seriam direcionadas para o nó do escritor. Portanto, a escalabilidade do Moodle é meio limitada, pois apenas as leituras “seguras” podem ser dimensionadas. Definitivamente, vamos querer usar o recurso do 3.9, já que este é o único método seguro para determinar qual seleção deve ir para onde. Dado que tudo está escrito em um arquivo de configuração do Moodle, provavelmente gostaríamos de usar um balanceador de carga, de preferência ProxySQL, para criar uma lógica que lidaria com nossa distribuição de leitura.
Devemos usar o MariaDB Cluster ou replicação assíncrona? Na verdade, mostraremos como usar os dois. Em ambos os casos, a configuração do Moodle será praticamente a mesma. Em ambos os casos, utilizaremos o ProxySQL como balanceador de carga. A principal diferença entre essas soluções é o failover. O MariaDB Cluster é muito mais fácil de lidar - se um nó estiver inativo, o ProxySQL simplesmente moverá o tráfego de gravação para um dos nós restantes. Com a replicação assíncrona as coisas são um pouco diferentes. Se o mestre ficar inativo, o failover terá que acontecer. Isso não acontece automaticamente, você precisa fazer manualmente ou pode contar com algum software para fazer isso. No nosso caso, usaremos o ClusterControl para gerenciar o ambiente e realizar o failover, portanto, do ponto de vista do usuário, não há muita diferença entre a replicação assíncrona e o MariaDB Cluster - em ambos os casos, a falha do gravador será tratada automaticamente e o cluster será recuperado automaticamente .
O que estabelecemos é que mostraremos a replicação assíncrona e virtualmente síncrona. Usaremos o recurso de escrita segura do Moodle 3.9 e usaremos o ProxySQL como balanceador de carga. Para garantir alta disponibilidade, precisaremos de mais de uma instância ProxySQL, portanto, usaremos duas delas e para criar um único ponto de entrada na camada de banco de dados, usaremos Keepalived para criar um IP virtual e apontá-lo para um dos ProxySQL disponíveis nós. Veja como nosso cluster de banco de dados pode se parecer:
Para replicação assíncrona, isso pode ser algo assim:
Implantando um back-end de banco de dados altamente disponível para Moodle usando a replicação MariaDB
Vamos começar com a Replicação MariaDB. Vamos usar o ClusterControl para implantar todo o back-end do banco de dados, incluindo balanceadores de carga.
Implantando o cluster de replicação MariaDB
Primeiro, precisamos escolher “Implantar” no assistente:
Então devemos definir conectividade SSH, sem senha, acesso SSH baseado em chave é um requisito para o ClusterControl gerenciar a infraestrutura do banco de dados.
Ao preencher esses detalhes, é hora de escolher um fornecedor e uma versão , defina a senha do superusuário e decida sobre alguns outros detalhes.
Vamos usar o MariaDB 10.4 por enquanto. Como próximo passo, temos que definir a topologia de replicação:
Devemos passar os nomes de host dos nós e como eles devem se relacionar com cada um outro. Quando estivermos satisfeitos com a topologia, podemos implantar. Para os propósitos deste blog, usaremos master e dois slaves como nosso backend.
Temos nosso primeiro cluster pronto. Agora, vamos implantar ProxySQL e Keepalived.
Implantando ProxySQL
Para ProxySQL é necessário preencher alguns detalhes - escolha o host para instalar nele, decidir sobre a versão do ProxySQL, credenciais para os usuários administrativos e de monitoramento. Você também deve importar usuários de banco de dados existentes ou criar um novo para seu aplicativo. Finalmente, decida quais nós de banco de dados você deseja usar com o ProxySQL e decida se você usa transações implícitas. No caso do Moodle isso não é verdade.
Implantando Keepalived
Como próximo passo, implantaremos o Keepalived.
Depois de passar detalhes como instâncias ProxySQL que devem ser monitoradas, IP virtual e o A interface VIP deve ser vinculada a estamos prontos para implantar. Após alguns minutos, tudo deve estar pronto e a topologia deve ficar como abaixo:
Configurar o Moodle e o ProxySQL para expansão de gravação segura
A etapa final será configurar o Moodle e o ProxySQL para usar gravações seguras. Embora seja possível codificar os nós do banco de dados na configuração do Moodle, seria muito melhor confiar no ProxySQL para lidar com as alterações de topologia. O que podemos fazer é criar um usuário adicional no banco de dados. Esse usuário será configurado no Moodle para executar leituras seguras. O ProxySQL será configurado para enviar todo o tráfego executado desse usuário para os nós escravos disponíveis.
Primeiro, vamos criar um usuário que usaremos para acesso somente leitura.
Estamos concedendo todos os privilégios aqui, mas deve ser possível limitar essa lista .
O usuário que acabamos de criar deve ser adicionado às duas instâncias do ProxySQL que temos no cluster para permitir que o ProxySQL se autentique como esse usuário. Na interface do usuário do ClusterControl, você pode usar a ação “Importar usuário”.
Podemos procurar o usuário que acabamos de criar:
ProxySQL usa um conceito de hostgroups - grupos de hosts que servem ao mesmo propósito . Em nossa configuração padrão existem dois grupos de host - hostgroup 10 que sempre apontam para o mestre atual e hostgroup 20 que aponta para nós escravos. Queremos que este usuário envie o tráfego para nós escravos, portanto, atribuiremos o HG 20 como o padrão.
É isso, o usuário será mostrado na lista de usuários:
Agora devemos repetir o mesmo processo no outro nó ProxySQL ou usar o Opção “Sincronizar instâncias”. De uma forma ou de outra, ambos os nós ProxySQL devem ter o usuário moodle_safereads adicionado.
O último passo será implantar o Moodle. Não vamos passar aqui por todo o processo, mas há uma questão que temos que resolver. O ProxySQL se apresenta como 5.5.30 e o Moodle reclama que é muito antigo. Podemos editá-lo facilmente para qualquer versão que desejarmos:
Uma vez feito isso, temos que enviar temporariamente todo o tráfego para O mestre. Isso pode ser feito excluindo todas as regras de consulta no ProxySQL. O usuário ‘moodle’ tem o HG10 como hostgroup padrão, o que significa que sem regras de consulta todo o tráfego desse usuário será direcionado para o mestre. O segundo, leituras seguras, o usuário tem o hostgroup padrão 20, que é praticamente toda a configuração que queremos ter.
Uma vez feito isso, devemos editar o arquivo de configuração do Moodle e habilitar o cofre lê o recurso:
<?php // Moodle configuration file
unset($CFG);
global $CFG;
$CFG = new stdClass();
$CFG->dbtype = 'mysqli';
$CFG->dblibrary = 'native';
$CFG->dbhost = '192.168.1.111';
$CFG->dbname = 'moodle';
$CFG->dbuser = 'moodle';
$CFG->dbpass = 'pass';
$CFG->prefix = 'mdl_';
$CFG->dboptions = array (
'dbpersist' => 0,
'dbport' => 6033,
'dbsocket' => '',
'dbcollation' => 'utf8mb4_general_ci',
'readonly' => [
'instance' => [
'dbhost' => '192.168.1.111',
'dbport' => 6033,
'dbuser' => 'moodle_safereads',
'dbpass' => 'pass'
]
]
);
$CFG->wwwroot = 'http://192.168.1.200/moodle';
$CFG->dataroot = '/var/www/moodledata';
$CFG->admin = 'admin';
$CFG->directorypermissions = 0777;
require_once(__DIR__ . '/lib/setup.php');
// There is no php closing tag in this file,
// it is intentional because it prevents trailing whitespace problems!O que aconteceu aqui é que adicionamos a conexão somente leitura ao ProxySQL que usará o usuário moodle_safereads. Este usuário sempre apontará para escravos. Isso conclui nossa configuração do Moodle para replicação do MariaDB.
Implantando um back-end de banco de dados altamente disponível para Moodle usando o MariaDB Cluster
Desta vez, tentaremos usar o MariaDB Cluster como nosso back-end. Novamente, o primeiro passo é o mesmo, precisamos escolher “Deploy” no assistente:
Depois de fazer isso, devemos definir conectividade SSH, sem senha, chave- o acesso SSH baseado é um requisito para o ClusterControl gerenciar a infraestrutura do banco de dados.
Então devemos decidir sobre o fornecedor, versão, hosts de senha e mais alguns definições:
Depois de preencher todos os detalhes, estamos prontos para implantar.
Poderíamos continuar aqui, mas considerando que todas as outras etapas são basicamente as mesmas da replicação do MariaDB, apenas pedimos que você role para cima e verifique a seção “Implantando ProxySQL” e tudo o que a segue. Você tem que implantar ProxySQL, Keepalived, reconfigurá-lo, alterar o arquivo de configuração do Moodle e é basicamente isso. Esperamos que este blog o ajude a construir ambientes altamente disponíveis para Moodle apoiados pelo MariaDB Cluster ou replicação.
