De nos jours, l'apprentissage en ligne gagne rapidement du terrain depuis la pandémie de COVID-19. La plupart des établissements d'enseignement doivent mettre en place des plateformes d'apprentissage en ligne, et presque tous les étudiants doivent accéder à la plateforme pour apprendre et interagir avec les enseignants. Moodle est l'un des systèmes de gestion de l'apprentissage open source pour l'apprentissage en ligne,
La haute disponibilité de la plateforme Moodle est un must pour les institutions, sinon cela interrompra et arrêtera le processus d'apprentissage en ligne. Avec de nombreux étudiants accédant à la plateforme en même temps, la disponibilité et l'évolutivité sont importantes. À ce stade, les établissements d'enseignement doivent avoir des connaissances et une architecture de la plate-forme haute disponibilité et évolutivité du Moodle. Si vous souhaitez en savoir plus sur la migration de Moodle autonome vers une base de données évolutive en cluster, vous pouvez suivre cette directive.
Moodle en mode "Point de défaillance unique"
La plate-forme autonome Moodle se compose d'un serveur et de tout ce qui est installé sur le serveur (la base de données et le serveur d'applications en un seul endroit). Ou vous avez 2 serveurs, qui sont pour le serveur d'application et le serveur de base de données comme décrit dans l'image ci-dessous :
Les deux architectures manquent de disponibilité et d'évolutivité du service. Du point de vue de la disponibilité, vous pouvez imaginer que si le serveur tombe en panne, vous n'avez aucun service en cours d'exécution sur le serveur. Si le serveur d'applications tombe en panne ou si la base de données tombe en panne, le service cesse de fonctionner.
D'autre part, l'évolutivité est également importante, plus d'utilisateurs signifie plus de trafic et plus de connexions à la base de données. L'évolutivité peut être obtenue en ajoutant plus de ressources dans les serveurs, ou en ajoutant plus de serveurs afin que le trafic puisse être réparti sur les nœuds, sinon les performances en souffriront.
Conversion d'une base de données autonome à une base de données en cluster
La migration de votre nœud autonome vers une base de données en cluster peut prendre un certain temps, et ce n'est pas une opération sans risque. Voici les étapes que nous devons suivre :
- Vous devez effectuer une sauvegarde (utilisez mysqldump ou xtrabackup).
- Installer la base de données dans tous les nœuds de la base de données dupliquée.
- Restaurer la sauvegarde dans les nœuds de réplique.
- Connectez le nœud dupliqué au maître.
- Configurer ProxySQL et keepalived devant les nœuds de la base de données
- Configurer les équilibreurs de charge ProxySQL (par exemple, créer des groupes d'hôtes, des serveurs, des utilisateurs).
- Pointez la configuration de Moodle vers la nouvelle adresse IP virtuelle.
Comment ClusterControl peut vous aider
ClusterControl est un logiciel de gestion de base de données qui vous aide à déployer, surveiller et gérer votre base de données open source. Nous allons essayer de migrer depuis l'architecture Moodle autonome comme indiqué ci-dessous :
Vers une architecture de base de données en cluster basée sur la réplication :
Vous aurez besoin d'au moins deux serveurs pour la base de données et deux pour la base de données proxy (nous utiliserons ProxySQL comme équilibreur de charge) et le service keepalive pour servir une adresse IP virtuelle.
En supposant que nous ayons une base de données MySQL autonome en cours d'exécution :
Ajouter plus de nœuds de base de données dans ClusterControl est vraiment simple, vous pouvez aller sur le Menu Cluster sur le côté droit de votre cluster et Ajouter un esclave de réplication.
Il affichera un nouveau dialogue pour l'ajout d'un nouvel esclave, il vous suffit de remplir l'adresse IP, puis cliquez simplement sur le bouton Ajouter un nouvel esclave comme indiqué ci-dessous :
Comme vous pouvez le voir sur la capture d'écran, il est possible d'ensemencer l'esclave avec les données d'une sauvegarde existante. Cela permet d'éviter de diffuser en continu toutes les données de la base de données principale en cours d'exécution. Une fois la base de données esclave déployée, elle sera amorcée avec les données maîtres et ClusterControl s'assurera que l'esclave se synchronise avec le maître.
Vous pouvez répéter l'étape pour ajouter un autre nœud de réplique.
La nouvelle architecture sera comme indiqué ci-dessous :
L'étape suivante consiste à ajouter un équilibreur de charge devant la base de données. Un équilibreur de charge comme ProxySQL est utile car il peut rediriger les requêtes d'écriture vers le maître et les requêtes de lecture vers les esclaves. De cette façon, vous répartissez le trafic Moodle. Notez qu'il est également possible de faire une configuration maître-maître basée sur Galera Cluster pour MySQL ou MariaDB.
Nous utiliserons deux équilibreurs de charge pour une haute disponibilité. Vous pouvez accéder à Gérer -> Équilibreurs de charge dans le cluster.
Vous devez remplir certaines informations comme l'adresse du serveur, le mot de passe administratif et moniteur, ajoutez l'utilisateur moodle dans ProxySQL, puis cliquez simplement sur Déployer ProxySQL. Cela déclenchera un nouveau travail. Répétez le déploiement sur l'autre nœud d'équilibreur de charge.
La dernière chose est de configurer keepalived pour les équilibreurs de charge. Allez dans Gérer -> Équilibreurs de charge, il y a un onglet pour Keepalived
Il vous suffit de choisir le type d'équilibreur de charge et de l'ajouter à keepalived . Remplissez l'adresse IP virtuelle et l'interface réseau. Cliquez sur le bouton Déployer Keepalived.
L'architecture finale de notre base de données Moodle hautement disponible en cluster sera comme indiqué ci-dessous :
Il suffit de changer la configuration de la connexion dans config.php en pointant le dbhost à l'adresse IP virtuelle que nous avions configurée.
Après avoir migré vers la base de données en cluster, vous souhaiterez peut-être mettre en place une surveillance dans votre base de données Moodle, que vous pouvez suivre cette directive.
