Open edX é uma plataforma para atividades educacionais online. Dada a situação em que o mundo se encontra, todas essas plataformas estão encontrando cargas mais altas e sua importância aumentou significativamente. Essas não são apenas as plataformas “ajudantes”, mas muitas vezes se tornam a principal forma de realização das atividades educacionais. Isso leva a requisitos mais altos em relação à carga que eles podem manipular ou à disponibilidade da plataforma.
Open edX é um produto complexo que consiste em vários elementos. Um deles é o banco de dados MySQL. Neste breve blog, gostaríamos de discutir como você pode melhorar a alta disponibilidade da plataforma Open edX.
Obviamente, o banco de dados MySQL único é um ponto único de falha e, como tal, não é uma abordagem adequada para as implantações de produção. Existem várias maneiras de melhorar a disponibilidade do banco de dados MySQL.
Para começar, você pode executar a configuração mestre-escravo usando replicação assíncrona ou semi-síncrona. A vantagem disso é que, quando o mestre está indisponível, você pode promover um dos escravos e prosseguir com a operação. A principal desvantagem de tal configuração é que o failover deve ser executado manualmente, o que aumenta o tempo de inatividade ou você precisa usar algum software externo (por exemplo, ClusterControl), mas ainda pode demorar um pouco. Finalmente, qualquer tipo de replicação assíncrona ou semi-síncrona está sujeita ao atraso de replicação. Isso pode afetar seriamente os cenários de leitura após gravação em que o aplicativo executa uma gravação no mestre e tenta imediatamente ler esses dados do escravo.
Outra abordagem seria usar um Galera Cluster para armazenar os dados da plataforma Open edX. Podemos começar com três clusters de nós - esses clusters podem lidar automaticamente com a falha de um único nó. Os dois nós restantes continuarão a funcionar e responderão às consultas provenientes do aplicativo. Outra vantagem do Galera é que, embora seja “virtualmente” síncrono (o que significa praticamente que é quase síncrono), há uma maneira de impor verificações de causalidade e forçar os clusters no modo síncrono (mesmo que você pague por isso com desempenho reduzido).
Ambos os cenários exigiriam algum tipo de balanceador de carga na frente deles, que lidaria com o tráfego e o redirecionaria para um destino adequado.
Vamos ver como o ClusterControl pode ajudá-lo a implantar um Galera Cluster com um conjunto de balanceadores de carga que você pode usar para sua plataforma Open edX.
Implantando o cluster MariaDB
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, temos que definir a conectividade SSH, sem senha, chave o acesso SSH baseado é um requisito para o ClusterControl, caso contrário, ele não poderá gerenciar a infraestrutura do banco de dados.
Depois, devemos decidir sobre o fornecedor, versão, senha, hosts e alguns Configurações adicionais:
Com todos esses detalhes preenchidos, podemos prosseguir com a implantação.
Implantando ProxySQL
O banco de dados em si não é o único elemento que queremos implantar. Também precisamos de um balanceador de carga que usaremos para direcionar o tráfego para os nós disponíveis no momento. Também o usaremos para fornecer divisão de leitura/gravação, direcionando todas as gravações para um único nó MariaDB Galera. Isso nos ajudará a evitar conflitos entre gravações executadas em diferentes nós do Galera.
Para ProxySQL ClusterControl também requer o preenchimento de algumas informações - você deve escolher o host para instalá-lo, decidir sobre a versão do ProxySQL, credenciais para os usuários administrativos e de monitoramento. Esses usuários serão usados para gerenciar o ProxySQL e monitorar o estado do seu cluster Galera. Você também deve importar usuários de banco de dados existentes ou criar um novo para seu aplicativo. Por fim, cabe a você decidir quais nós de banco de dados deseja usar com o ProxySQL e decidir se usa transações implícitas.
Implantando Keepalived
Como próximo passo, implantaremos o Keepalived. A ideia aqui é ter um IP virtual que apontará para a instância ProxySQL em funcionamento. Esse VIP pode ser usado no aplicativo como o ponto de extremidade para a conectividade do banco de dados MySQL.
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:
É basicamente isso quando se trata de implantação. Você pode apontar sua plataforma Open edX para o VIP e a porta 6033, isso deve ser suficiente para obter a conectividade com seu banco de dados de back-end. O último bit restante, caso você ache necessário, seria configurar as verificações de causalidade. Existe uma variável wsrep_sync_wait que pode fazer exatamente isso. Ele pode habilitar testes em diversos padrões de acesso:leituras, atualizações, inserções, exclusões, substituições e comandos SHOW. Se estivermos interessados apenas nas consultas SELECT, definiremos essa variável como '1' usando o gerenciamento de configuração do ClusterControl.
Isso realizará essa alteração em todos os nós do cluster MariaDB.
É mais ou menos isso. Se você gostaria de compartilhar um pouco de sua experiência com o Open edX, fique à vontade para nos deixar um comentário.
