Afetados pela pandemia do COVID-19, muitas PMEs/PMEs estão migrando para plataformas online. As aulas presenciais ou físicas também são afetadas por essa pandemia e muitas escolas e universidades também estão migrando para o online e buscando ferramentas que estejam disponíveis para serem usadas para continuar atendendo os alunos ou alunos, pois a educação tem para não ser prejudicado. Uma das plataformas famosas que estão disponíveis para fins educacionais on-line ou de aprendizado on-line é o Moodle.
O que é o Moodle?
Moodle é um software de código aberto para sistema de gerenciamento de aprendizagem online, ou LMS (também conhecido como Ambiente Virtual de Aprendizagem ou AVA) sob licença GPL. Ele permite que os educadores criem seu próprio site privado repleto de cursos dinâmicos que ampliam o aprendizado, a qualquer hora e em qualquer lugar. O Moodle possui todo suporte com fácil acesso e recursos para professores, alunos ou administradores.
Como é uma plataforma de software livre e de código aberto, você pode usar este software gratuitamente e sem taxas de royalties, assim como outros softwares de código aberto. Os custos incorrem apenas quando este software é hospedado em uma plataforma de hospedagem paga ou se você o hospeda com o Moodle Cloud. O Moodle também está disponível para dispositivos portáteis, como celulares ou tablets.
Por que você precisa de um banco de dados altamente disponível?
Na década de 1990, foi inventada uma solução muito simples para Alta Disponibilidade (HA), chamada Heartbeat. Um cluster Heartbeat basicamente pode fazer duas coisas:ele monitora dois nós (e não mais que dois) e é configurado para iniciar um ou mais serviços nesses dois nós. Se o nó que estava hospedando os recursos no momento ficar inativo, ele reiniciou os recursos de cluster no nó restante. Embora a versão inicial do Heartbeat não tivesse monitoramento dos próprios recursos, isso muda até o lançamento do Heartbeat 2.0 no início dos anos 2000, onde permite gerenciar mais de dois nós para o cluster. Basicamente, isso compreende o estado do cluster HA do Linux, que é baseado em grande parte no Heartbeat 2.0. A partir disso, muitas soluções de HA foram impactadas e foram desenvolvidas e criadas para minimizar o tempo de inatividade especialmente para recursos críticos.
Ser altamente disponível não significa apenas minimizar o tempo de inatividade. Também abrange o grau de responsabilidade de poder operar e manter continuamente os serviços que você está oferecendo e prometido aos seus clientes. Estar disponível para os clientes não significa também que você é capaz de responder a eles caso precisem de ajuda. Ele precisa colocar seu aplicativo e sistema de negócios totalmente funcional, como se fosse sempre o estado normal das operações, mesmo que ocorra um desastre sem precedentes.
Você não pode operar seu aplicativo AVA usando o Moodle enquanto seu banco de dados estiver em manutenção. Se você tiver apenas um único servidor de banco de dados, o que é muito comum para uma configuração de aplicativo simples e leve, quando o servidor cair, seu aplicativo será interrompido. Se você tiver um cluster de banco de dados usando replicação mestre-escravo e encontrar um incidente sem precedentes que, por sua vez, seu aplicativo está gravando em dois mestres após o incidente, isso pode ser uma grande bagunça que, por sua vez, causa corrupção de dados em todo o aplicativo de negócios e camada de dados. Se houvesse pagamentos em andamento naquele momento, isso poderia ser um grande desastre e envolveria uma grande quantidade de trabalho ao realizar a recuperação de dados.
Então, por que seu banco de dados precisa ser altamente disponível? É porque tem que ser,
- Capaz de realizar manutenção ou interrupção planejada de forma viável e na janela de manutenção permitida
- O tempo de atividade é vital e deve evitar o tempo de inatividade quando necessário
- O SLA é importante por seu grau mais alto para alcançar um atendimento ao cliente de alta qualidade
- Fornecer serviço e usabilidade contínuos
- Nenhum ponto único de falha
- Capaz de realizar failover quando o mestre quebra ou trava
- Evite o cenário de cérebro dividido em que vários mestres atuam como escritores ativos ao mesmo tempo
Construindo o cluster de banco de dados
Agora que enfatizamos a importância de ter HA como plano e como solução para seu cluster de banco de dados, especialmente para PostgreSQL, vamos nos concentrar em construir o cluster de cima para baixo para alcançar um configuração disponível pronta para configuração do aplicativo Moodle.
Instalando o PostgreSQL
Em primeiro lugar, por que o PostgreSQL? O PostgreSQL possui grandes vantagens quando comparado a outros bancos de dados suportados pelo Moodle. É uma questão de preferência se eu tiver que resumir, pois todos os bancos de dados suportados pelo Moodle são todos capazes de lidar com os dados e também estão sujeitos a otimização. Depende de quão habilidoso e experiente você está usando o banco de dados. Embora para resumir o porquê de usar o PostgreSQL, é um banco de dados confiável e seu sofisticado software de código aberto, especialmente em bancos de dados que podem ser comparados a outros fornecedores proprietários, como Oracle e MS SQL. Ele suporta paralelismo de consulta, capaz de gerenciar bancos de dados grandes ou enormes, possui amplo suporte para JSON e muito mais. Você pode conferir aqui as razões para escolher o PostgreSQL. Agora vamos prosseguir com a instalação do PostgreSQL
Para este blog, usaremos o PostgreSQL 12 usando o Ubuntu 18.04 (Bionic Beaver). Em seguida, para a configuração de alta disponibilidade, você deve ter um nó primário e pelo menos um nó em espera (réplica) para o qual ele assumirá o controle quando o mestre ficar inativo.
- Configure o repositório e a chave de assinatura
sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/postgresql.list' wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add - - Instale o servidor PG 12
# Update the package lists: sudo apt-get update # Install server and client apt install postgresql-12 postgresql-client-12
Faça isso também na réplica de destino, mas você precisa configurá-la como standby ou réplica. Como alternativa, sugiro que você use o ClusterControl e faça o download, pois é gratuito. Seria mais rápido e rápido instalar e configurar uma configuração primária/em espera. Para minha configuração usando ClusterControl e usando a guia de exibição Topologia, obtive a seguinte topologia:
Tendo uma configuração master/slave ou primária/standby, não significa que você está totalmente coberto para um cluster de banco de dados de alta disponibilidade. Ainda não está altamente disponível. Depois que o primário ou mestre ficar inativo, não haverá failover que possa ocorrer. Outra coisa é que não há balanceamento de conexões de clientes que vão para o master contra o slave. Embora o balanceamento de carga entre o mestre/escravo não implique que ele precise ser configurado ou aplicado para atender a uma configuração altamente disponível. Ter um balanceamento de carga entre o mestre/primário e um escravo/em espera ajuda seu nó mestre a não sobrecarregar o alto desempenho de carga, especialmente em horas de tráfego muito alto.
Configurando o balanceamento de carga
Como mencionado anteriormente, o balanceamento de carga entre o mestre e o escravo ajuda seu mestre a separar a carga. Não é ideal se você deixar seu standby apenas usar apenas para replicação ou assumir o controle caso o mestre fique inativo. Embora isso possa funcionar, no entanto, isso implica tempo de inatividade e trabalho manual se o mestre ficar inativo, pois você precisa alternar a função do nó em espera para um mestre. Isso também é bom, mas, novamente, ter um balanceador de carga pode ajudar a direcionar as gravações para o mestre e, em seguida, direcionar as leituras entre o mestre e o escravo. Isso basicamente fornece divisão de leitura/gravação. Para fazer isso, há muitas opções que você pode escolher com o PostgreSQL. Basicamente, a configuração mais comum, porém simples e leve, é usar o HAProxy.
Embora existam opções como usar PgBouncer ou pgpool-II. Para simplificar este blog, vamos usar o HAProxy. Para instalar o HAProxy, é bastante simples se você usar o ClusterControl. Vamos fazer isso via ClusterControl. Para fazer isso, você pode simplesmente ir para a guia Gerenciar, selecionar Load Balancer como mostrado abaixo,
Como precisamos ter uma configuração altamente disponível para seu cluster de banco de dados PostgreSQL, devemos ter pelo menos dois nós. Portanto, se o nó HAProxy primário ficar inativo, o HAProxy passivo ou de espera poderá assumir o controle. Vamos ver como fica do meu lado,
Embora pareça bom. Esta configuração ainda é insuficiente. Se você acha que somos bons para uma configuração altamente disponível com essa topologia, não há failover caso o HAProxy fique inativo no nó 192.168.30.222 na porta 9600 ou se 192.168.30.223:9600 cair e se seu aplicativo estiver configurado para isso host, ainda haverá tempo de inatividade se nenhuma configuração proativa tiver sido feita. Dessa forma, você tem tempo de inatividade se tiver que ser configurado manualmente. Nesse caso, usaremos e configuraremos Keepalived para que as instâncias do HAProxy sejam monitoradas de perto quanto à integridade e failover caso o outro nó encontre um problema.
Manter os balanceadores de carga altamente disponíveis
Agora que temos balanceadores de carga em cima de nossos bancos de dados, ainda precisamos que nosso HAProxy esteja sempre ativo caso o nó primário do endpoint do aplicativo fique inativo. Basicamente, o que o HAProxy pode fazer com a configuração que temos na seção anterior, os aplicativos podem usar o 192.168.30.223 ou 192.168.30.222 com as portas 5433 (porta leitura-gravação) e 5434 (porta somente leitura), respectivamente. Agora há um aborrecimento caso você precise alternar caso os outros nós fiquem inativos, além disso, o ruim é que você está prejudicando os negócios, pois cobre o tempo de inatividade se não houver failover automático para lidar com isso. Evitar o tempo de inatividade é o melhor caminho aqui, a menos que você tenha um SLA muito baixo e um RTO e RPO altos.
Para aliviar esse desastre ou tempo de inatividade, sugerimos configurar o Keepalived em cima do HAProxy. Basicamente, o HAProxy fará o balanceamento de carga entre leitura e gravação, fornecendo divisão de leitura e gravação, e o Keepalived monitora apenas a integridade dos nós do HAProxy e conseguirá pegar o nó mais saudável de acordo com sua configuração desejada. Keepalived é uma ferramenta que você pode usar para fazer com que os nós HAProxy sejam monitorados, embora não seja tão complexo gerenciar bancos de dados. Keepalived usa VIP (IP virtual) que atribui ao nó HAProxy primário padrão e, em seguida, reatribui esse VIP caso o nó HAProxy primário falhe e o aponta para o nó HAProxy subsequente ou em espera.
Agora vamos configurar isso usando o ClusterControl, pois é mais rápido e fácil de gerenciar com o ClusterControl. Para fazer isso, é basicamente a mesma abordagem de como configuramos o HAProxy, mas, em vez disso, selecione Keepalived como mostrado abaixo,
Basicamente, se você instalar o Keepalived manualmente, estamos selecionando o primário contra o secundário caso o HAProxy primário falhe. Vamos ver como é a nossa visualização de topologia,
Isso pode parecer muito promissor. Basicamente, o cliente do aplicativo Moodle se conectará ao VIP, ou seja, 192.168.30.201 nas portas 5433 (porta de leitura e gravação) e 5434 (porta somente leitura). Por exemplo, verificando em um host externo que tenho,
[[email protected] ~]# psql -h 192.168.30.201 -U dbapgadmin -W postgres -p 5433
Password:
psql (11.2, server 12.4 (Ubuntu 12.4-1.pgdg18.04+1))
WARNING: psql major version 11, server major version 12.
Some psql features might not work.
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
postgres=# select inet_server_addr();
inet_server_addr
------------------
192.168.30.221
(1 row)que revela que apenas o nó de gravação que tenho aponta para meu nó mestre, ou seja, 192.168.30.22. Então, minha porta somente leitura deve ir para os nós mestre e escravo, conforme mostrado abaixo,
[[email protected] ~]# psql -h 192.168.30.201 -U dbapgadmin -W postgres -p 5434
Password:
psql (11.2, server 12.4 (Ubuntu 12.4-1.pgdg18.04+1))
WARNING: psql major version 11, server major version 12.
Some psql features might not work.
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
postgres=# select inet_server_addr();
inet_server_addr
------------------
192.168.30.221
(1 row)
postgres=# \q
[[email protected] ~]# psql -h 192.168.30.201 -U dbapgadmin -W postgres -p 5434
Password:
psql (11.2, server 12.4 (Ubuntu 12.4-1.pgdg18.04+1))
WARNING: psql major version 11, server major version 12.
Some psql features might not work.
Type "help" for help.
postgres=# select inet_server_addr();
inet_server_addr
------------------
192.168.30.222
(1 row)Isso revela que meus nós primários e de espera são identificados como nós de "leitura de banco de dados".
Agora isso parece muito promissor como o que eu disse anteriormente. Ainda assim, há uma parte que falta aqui que é realmente muito importante. Não há mecanismo de failover de banco de dados pronto para esse tipo de configuração. No entanto, temos o Keepalived que monitora o HAProxy e, em seguida, faz um failover alternando o VIP caso o HAProxy principal falhe ou morra. No entanto, o Keepalived não está configurado para lidar com a configuração complexa que o PostgreSQL possui. Há um muito decente que está disponível e gratuito para configurar isso. Você pode usar o Slony-I, um sistema de replicação de terceiros.
Tendo um mecanismo de failover para seu cluster PostgreSQL
Existem maneiras de fornecer um mecanismo de failover para seu PostgreSQL. Slony-I ou comumente chamado apenas de Slony é uma das ferramentas comuns que são usadas. Embora o Slony exija que sua configuração seja uma replicação lógica, pois requer uma configuração de editor/assinante, pode não ser ideal para outra configuração que esteja usando uma replicação de streaming padrão. A desvantagem de usar o Slony é que ele não fornece nenhuma detecção automática para sistemas com falha ou nenhum suporte para delimitação de nós. Portanto, um comumente chamado STONITH (atirar no outro nó na cabeça ou atirar no nó com falha na cabeça) que basicamente elimina a falha para evitar cenários de cérebro dividido em que vários nós mestres (nós de gravação ativos) estão aceitando gravações no mesmo tempo. Embora isso possa ser configurado adequadamente, ainda pode ser demorado e complicado se for criado com menos experiência e insights sobre quais cenários podem acontecer para o PostgreSQL quando ocorrer um desastre. Para Slony, abandonar transações confirmadas é uma decisão de negócios que não pode ser tomada por um sistema de banco de dados. Se alguém quiser colocar os comandos abaixo em um script executado automaticamente a partir do sistema de monitoramento de rede, basta deixar à sua disposição que são seus dados e sua política de failover.
Alternativamente, se você estiver procurando por opções corporativas e ainda assim puder gastar seu dinheiro com uma despesa razoável, o ClusterControl tem recuperação automática para clusters PostgreSQL. Basicamente, a recuperação automática responde aos problemas mencionados acima com o Slony. Embora nossa recuperação automática seja melhor testada com replicação de streaming e seja compatível apenas com o tipo de replicação de streaming da configuração do PostgreSQL. Então, como isso funciona? Basicamente, você só precisa ativar os botões de recuperação automática, como abaixo,
Isto suporta cerca de nó, o que significa que ele derrubará o nó com falha no caso o nó volta vivo por algum motivo não previsto. Além disso, a recuperação automática do ClusterControl suporta a recuperação de nó e cluster que, se um nó mestre ou escravo for desligado ou morto acidentalmente, o ClusterControl tentará reviver isso, especialmente se ocorrer fora de uma interrupção planejada ou janela de manutenção. Esse recurso apenas protege você de ter se desgastado com os medos do banco de dados e, ao mesmo tempo, também fornece monitoramento proativo que o notificará sobre a ocorrência de algum possível desastre antes que seja tarde demais para se recuperar.
Conclusão
As configurações altamente disponíveis para seu cluster de banco de dados, especialmente para o Moodle, podem variar dependendo do tipo de configuração e dos requisitos necessários. Se é puramente dependente de tecnologias gratuitas e de código aberto ou há outras opções que valem a pena investir em seu aplicativo corporativo, desde que o orçamento possa acomodar, pois pode fornecer uma situação vantajosa para todos, especialmente se você quiser mais foco apenas no lado comercial das coisas do que focar em outras ferramentas, como administração e tipo de trabalho devops.
