De nos jours, les réunions en face à face sont limitées au strict minimum, les activités en ligne sont devenues le principal moyen d'interaction enseignant-élève. Cela a accru le stress sur les plateformes de « réunion » en ligne existantes (y a-t-il quelqu'un qui ne sait pas ce qu'est Zoom de nos jours ?) mais aussi sur les plateformes d'apprentissage en ligne. La haute disponibilité des outils en ligne est plus importante que jamais et les équipes opérationnelles se précipitent pour construire des architectures durables et hautement disponibles pour leurs environnements.
Il est fort probable qu'au moins certains d'entre vous aient utilisé Moodle - il s'agit d'une plate-forme d'apprentissage en ligne autonome que vous pouvez déployer sur site et l'utiliser pour dispenser une formation en ligne à votre organisation. Comme nous l'avons mentionné, il est plus important que jamais de le faire fonctionner de manière durable et hautement disponible. Nous aimerions proposer une solution hautement disponible qui implique MariaDB en tant que base de données principale - à la fois la réplication asynchrone et Galera Cluster.
Processus de conception d'environnement
Nous aimerions commencer par un processus où nous expliquerions le processus de réflexion derrière la conception de l'environnement pour Moodle. Nous voulons une haute disponibilité, donc un seul nœud de base de données ne fonctionne pas pour nous. Nous voulons plusieurs nœuds et cela nous amène à la première décision de conception. Doit-on utiliser la réplication asynchrone ou Galera Cluster ? La deuxième question est :comment allons-nous répartir la charge de travail sur les nœuds ? Commençons par le second.
La dernière version de Moodle au moment où ce blog a été écrit (3.9) a introduit une fonctionnalité intéressante appelée lectures sécurisées. Le problème à résoudre ici est la lecture après écriture. Lorsque vous utilisez un nœud, le monde est un endroit simple. Vous écrivez puis vous lisez. Tout ce que vous avez écrit est déjà là. Lorsque vous ajoutez des nœuds, cependant, les choses changent. Dans la réplication asynchrone, les esclaves peuvent être en retard de plusieurs dizaines de secondes ou plus. Tout ce que vous écrivez sur le maître peut prendre même quelques minutes (sinon plus dans les cas les plus extrêmes) pour être appliqué à l'esclave. Si vous exécutez une écriture puis essayez immédiatement de lire les mêmes données à partir de l'un des esclaves, vous risquez d'avoir une mauvaise surprise - les données ne seront pas là. Le cluster Galera utilise une réplication "virtuellement" synchrone et dans ce cas particulier "virtuellement" fait une énorme différence - Galera n'est pas à l'abri des problèmes de lecture après écriture. Il y a toujours un délai entre l'exécution de l'écriture sur le nœud local et l'application de l'ensemble d'écritures aux nœuds restants du cluster. Bien sûr, il est très probablement mesuré en millisecondes plutôt qu'en secondes, mais cela peut toujours briser l'hypothèse selon laquelle vous pouvez lire immédiatement ce que vous avez écrit. Le seul endroit où vous pouvez lire en toute sécurité après avoir écrit est le nœud sur lequel vous avez écrit les données.
Comme Moodle s'appuie beaucoup sur la lecture après écriture, nous ne pouvons pas facilement mettre à l'échelle les lectures uniquement en ajoutant plus de nœuds à partir desquels lire. Pour Galera Cluster, nous pourrions tenter d'atténuer le problème en utilisant le paramètre de configuration wsrep-sync-wait pour forcer Galera à s'assurer que les lectures peuvent être exécutées en toute sécurité. Cela crée un impact sur les performances du système car toutes les lectures doivent attendre que les écritures soient appliquées avant de pouvoir être exécutées. Il s'agit également d'une solution pour MariaDB Cluster (et d'autres solutions basées sur Galera), pas pour la réplication asynchrone. Heureusement, la solution de Moodle résout ce problème. Vous pouvez définir une liste de nœuds qui peuvent éventuellement être en retard et Moodle ne les utilisera que pour les lectures qui ne nécessitent pas d'être à jour avec les écritures. Toutes les lectures restantes qui nécessitent que les données soient toujours à jour seraient dirigées vers le nœud d'écriture. Ainsi, l'évolutivité de Moodle est en quelque sorte limitée car seules les lectures "sûres" peuvent être mises à l'échelle. Nous voudrons certainement utiliser la fonctionnalité 3.9 étant donné que c'est la seule méthode sûre pour déterminer quelle sélection doit aller où. Étant donné que tout est écrit dans un fichier de configuration de Moodle, nous voudrions très probablement utiliser un équilibreur de charge, de préférence ProxySQL, pour créer une logique qui gérerait notre distribution en lecture.
Faut-il utiliser MariaDB Cluster ou la réplication asynchrone ? Nous allons en fait vous montrer comment utiliser les deux. Dans les deux cas, la configuration de Moodle sera à peu près la même. Dans les deux cas, nous utiliserons ProxySQL comme équilibreur de charge. La principale différence entre ces solutions est le basculement. MariaDB Cluster est beaucoup plus facile à gérer - si un nœud est en panne, ProxySQL déplacera simplement le trafic d'écriture vers l'un des nœuds restants. Avec la réplication asynchrone, les choses sont légèrement différentes. Si le maître tombe en panne, le basculement doit se produire. Cela ne se produit pas automatiquement, vous devez soit le faire à la main, soit vous pouvez compter sur un logiciel pour y parvenir. Dans notre cas, nous utiliserons ClusterControl pour gérer l'environnement et effectuer le basculement. Par conséquent, du point de vue de l'utilisateur, il n'y a pas beaucoup de différence entre la réplication asynchrone et le cluster MariaDB - dans les deux cas, l'échec de l'écrivain sera automatiquement géré et le cluster récupérera automatiquement .
Ce que nous avons établi, c'est que nous présenterons à la fois la réplication asynchrone et virtuellement synchrone. Nous utiliserons la fonction d'écriture sécurisée de Moodle 3.9 et nous utiliserons ProxySQL comme équilibreur de charge. Pour assurer une haute disponibilité, nous aurons besoin de plus d'une instance ProxySQL, nous allons donc en utiliser deux et pour créer un point d'entrée unique dans la couche de base de données, nous utiliserons Keepalived pour créer une adresse IP virtuelle et la pointer vers l'un des ProxySQL disponibles. nœuds. Voici à quoi pourrait ressembler notre cluster de bases de données :
Pour la réplication asynchrone, cela pourrait ressembler à ceci :
Déploiement d'un backend de base de données hautement disponible pour Moodle à l'aide de la réplication MariaDB
Commençons par la réplication MariaDB. Nous allons utiliser ClusterControl pour déployer l'ensemble du backend de la base de données, y compris les équilibreurs de charge.
Déploiement du cluster de réplication MariaDB
Dans un premier temps, nous devons sélectionner "Déployer" dans l'assistant :
Ensuite, nous devrions définir la connectivité SSH, l'accès SSH sans mot de passe et basé sur une clé est une exigence pour que ClusterControl gère l'infrastructure de la base de données.
Lorsque vous remplissez ces détails, il est temps de choisir un fournisseur et une version , définissez le mot de passe du superutilisateur et décidez d'autres détails.
Nous allons utiliser MariaDB 10.4 pour le moment. Dans une prochaine étape, nous devons définir la topologie de réplication :
Nous devons transmettre les noms d'hôte des nœuds et comment ils doivent être liés à chacun autre. Une fois que nous sommes satisfaits de la topologie, nous pouvons déployer. Pour les besoins de ce blog, nous utiliserons le maître et deux esclaves comme backend.
Nous avons notre premier cluster opérationnel et prêt. Maintenant, déployons ProxySQL et Keepalived.
Déployer ProxySQL
Pour ProxySQL, il est nécessaire de remplir certains détails - choisissez l'hôte à installer activez-le, décidez de la version de ProxySQL, des informations d'identification pour les utilisateurs administratifs et de surveillance. Vous devez également importer des utilisateurs de base de données existants ou en créer un nouveau pour votre application. Enfin, décidez quels nœuds de base de données vous souhaitez utiliser avec ProxySQL et décidez si vous utilisez des transactions implicites. Dans le cas de Moodle, ce n'est pas vrai.
Déployer Keepalived
Dans la prochaine étape, nous déploierons Keepalived.
Après avoir transmis des détails tels que les instances ProxySQL qui doivent être surveillées, l'adresse IP virtuelle et le l'interface VIP doit être liée à nous sommes prêts à déployer. Après quelques minutes, tout devrait être prêt et la topologie devrait ressembler à celle ci-dessous :
Configurer Moodle et ProxySQL pour l'évolutivité des écritures sécurisées
La dernière étape consistera à configurer Moodle et ProxySQL pour utiliser des écritures sécurisées. Bien qu'il soit possible de coder en dur les nœuds de base de données dans la configuration Moodle, il serait bien préférable de s'appuyer sur ProxySQL pour gérer les changements de topologie. Ce que nous pouvons faire, c'est créer un utilisateur supplémentaire dans la base de données. Cet utilisateur sera configuré dans Moodle pour exécuter des lectures sécurisées. ProxySQL sera configuré pour envoyer tout le trafic exécuté depuis cet utilisateur vers les nœuds esclaves disponibles.
Commençons par créer un utilisateur que nous utiliserons pour un accès en lecture seule.
Nous accordons tous les privilèges ici mais il devrait être possible de limiter cette liste .
L'utilisateur que nous venons de créer doit être ajouté aux deux instances ProxySQL que nous avons dans le cluster afin de permettre à ProxySQL de s'authentifier en tant que cet utilisateur. Dans l'interface utilisateur de ClusterControl, vous pouvez utiliser l'action "Importer un utilisateur".
Nous pouvons rechercher l'utilisateur que nous venons de créer :
ProxySQL utilise un concept de groupes d'hôtes - des groupes d'hôtes qui servent le même objectif . Dans notre configuration par défaut, il y a deux groupes d'hôtes - le groupe d'hôtes 10 qui pointe toujours vers le maître actuel et le groupe d'hôtes 20 qui pointe vers les nœuds esclaves. Nous voulons que cet utilisateur envoie le trafic aux nœuds esclaves, nous allons donc attribuer HG 20 comme nœud par défaut.
Ça y est, l'utilisateur sera affiché sur la liste des utilisateurs :
Nous devons maintenant répéter le même processus sur l'autre nœud ProxySQL ou utiliser le Option "Synchroniser les instances". D'une manière ou d'une autre, l'utilisateur moodle_safereads doit être ajouté aux deux nœuds ProxySQL.
La dernière étape sera de déployer Moodle. Nous n'allons pas parcourir ici tout le processus, mais il y a un problème que nous devons résoudre. ProxySQL se présente comme 5.5.30 et Moodle se plaint qu'il est trop ancien. Nous pouvons le modifier facilement vers la version que nous voulons :
Une fois cela fait, nous devons temporairement envoyer tout le trafic vers le maître. Cela peut être accompli en supprimant toutes les règles de requête dans ProxySQL. L'utilisateur "moodle" a HG10 comme groupe d'hôtes par défaut, ce qui signifie qu'en l'absence de règles de requête, tout le trafic de cet utilisateur sera dirigé vers le maître. Le deuxième utilisateur, en lecture sûre, a le groupe d'hôtes par défaut 20, qui correspond à peu près à toute la configuration que nous souhaitons avoir en place.
Une fois cela fait, nous devrions éditer le fichier de configuration de Moodle et activer le coffre-fort fonction de lecture :
<?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!Ce qui s'est passé ici, c'est que nous avons ajouté la connexion en lecture seule à ProxySQL qui utilisera l'utilisateur moodle_safereads. Cet utilisateur pointera toujours vers les esclaves. Ceci conclut notre configuration de Moodle pour la réplication MariaDB.
Déploiement d'un backend de base de données hautement disponible pour Moodle à l'aide du cluster MariaDB
Cette fois, nous allons essayer d'utiliser MariaDB Cluster comme backend. Encore une fois, la première étape est la même, nous devons sélectionner "Déployer" dans l'assistant :
Une fois que vous avez fait cela, nous devrions définir la connectivité SSH, sans mot de passe, clé- l'accès SSH basé est une exigence pour que ClusterControl gère l'infrastructure de la base de données.
Ensuite, nous devrions décider du fournisseur, de la version, des hôtes de mot de passe et quelques autres paramètres :
Une fois que nous avons rempli tous les détails, nous sommes prêts à déployer.
Nous pourrions continuer ici, mais étant donné que toutes les étapes suivantes sont fondamentalement les mêmes qu'avec la réplication MariaDB, nous vous demandons simplement de faire défiler vers le haut et de vérifier la section "Déploiement de ProxySQL" et tout ce qui la suit. Vous devez déployer ProxySQL, Keepalived, le reconfigurer, modifier le fichier de configuration de Moodle et c'est à peu près tout. Nous espérons que ce blog vous aidera à créer des environnements hautement disponibles pour Moodle soutenus par MariaDB Cluster ou réplication.
