Moodle est une plate-forme très populaire pour organiser des cours en ligne. Avec la situation que nous voyons en 2020, Moodle, avec des communicateurs comme Zoom, constitue l'épine dorsale des services qui permettent l'apprentissage en ligne et l'éducation à domicile. La demande sur les plateformes Moodle a considérablement augmenté par rapport aux années précédentes. De nouvelles plates-formes ont été construites, une charge supplémentaire a été imposée aux plates-formes qui, historiquement, n'étaient qu'un outil d'assistance et qui sont désormais destinées à piloter l'ensemble de l'effort éducatif. Comment faire évoluer le Moodle? Nous avons un blog sur ce sujet. Comment faire évoluer le backend de la base de données pour Moodle ? Eh bien, c'est une autre histoire. Jetons-y un coup d'œil, car la mise à l'échelle des bases de données n'est pas la chose la plus simple à faire, surtout si Moodle ajoute sa petite touche personnelle.
Comme point d'entrée, nous utiliserons l'architecture décrite dans l'un de nos articles précédents. Cluster MariaDB avec ProxySQL et Keepalived en plus.
Comme vous pouvez le voir, nous avons un cluster MariaDB à trois nœuds avec ProxySQL qui sépare les lectures sécurisées du reste du trafic en fonction de l'utilisateur.
<?php // Moodle configuration file
unset($CFG);
global $CFG;
$CFG = new stdClass();
$CFG->dbtype = 'mysqli';
$CFG->dblibrary = 'native';
$CFG->dbhost = '192.168.1.222';
$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.222',
'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!L'utilisateur, comme indiqué ci-dessus, est défini dans le fichier de configuration de Moodle. Cela nous permet d'envoyer automatiquement et en toute sécurité des écritures et toutes les instructions SELECT qui nécessitent la cohérence des données au nœud écrivain tout en envoyant certains des SELECT aux nœuds restants du cluster MariaDB.
Supposons que cette configuration particulière ne nous suffit pas. Quelles sont les options que nous avons? Nous avons deux éléments principaux dans la configuration - MariaDB Cluster et ProxySQL. Nous examinerons les problèmes des deux côtés :
- Que peut-on faire si l'instance ProxySQL ne peut pas gérer le trafic ?
- Que peut-on faire si MariaDB Cluster ne peut pas gérer le trafic ?
Commençons par le premier scénario.
L'instance ProxySQL est surchargée
Dans l'environnement actuel, une seule instance ProxySQL peut gérer le trafic - celle vers laquelle pointe l'IP virtuelle. Cela nous laisse avec une instance ProxySQL qui agit comme une instance de secours - opérationnelle mais non utilisée pour quoi que ce soit. Si l'instance ProxySQL active approche de la saturation du processeur, il y a plusieurs choses que vous voudrez peut-être faire. Tout d'abord, évidemment, vous pouvez évoluer verticalement - augmenter la taille d'une instance ProxySQL peut être le moyen le plus simple de lui permettre de gérer un trafic plus élevé. Veuillez garder à l'esprit que ProxySQL, par défaut, est configuré pour utiliser 4 threads.
Si vous souhaitez pouvoir utiliser plus de cœurs de processeur, c'est le paramètre que vous devez également modifier.
Vous pouvez également essayer d'effectuer une mise à l'échelle horizontale. Au lieu d'utiliser deux instances ProxySQL avec VIP, vous pouvez colocaliser ProxySQL avec des hôtes Moodle. Ensuite, vous souhaitez reconfigurer Moodle pour vous connecter à ProxySQL sur l'hôte local, idéalement via le socket Unix - c'est le moyen le plus efficace de se connecter à ProxySQL. Il n'y a pas beaucoup de configuration que nous utilisons avec ProxySQL, donc l'utilisation de plusieurs instances de ProxySQL ne devrait pas ajouter trop de surcharge. Si vous le souhaitez, vous pouvez toujours configurer ProxySQL Cluster pour vous aider à synchroniser les instances ProxySQL concernant la configuration.
Le cluster MariaDB est surchargé
Nous parlons maintenant d'un problème plus sérieux. Bien sûr, augmenter la taille des instances aidera, comme d'habitude. D'autre part, la mise à l'échelle horizontale est quelque peu limitée en raison de la limitation des « lectures sécurisées ». Bien sûr, vous pouvez ajouter plus de nœuds au cluster, mais vous ne pouvez les utiliser que pour les lectures sécurisées. Dans quelle mesure cela vous permet d'évoluer, cela dépend de la charge de travail. Pour une charge de travail en lecture seule (navigation dans le contenu, les forums, etc.), cela semble plutôt agréable :
MySQL [(none)]> SELECT hostgroup, srv_host, srv_port, status, queries FROM stats_mysql_connection_pool WHERE hostgroup IN (20, 10) AND status='ONLINE';
+-----------+---------------+----------+--------+---------+
| hostgroup | srv_host | srv_port | status | Queries |
+-----------+---------------+----------+--------+---------+
| 20 | 192.168.1.204 | 3306 | ONLINE | 5683 |
| 20 | 192.168.1.205 | 3306 | ONLINE | 5543 |
| 10 | 192.168.1.206 | 3306 | ONLINE | 553 |
+-----------+---------------+----------+--------+---------+
3 rows in set (0.002 sec)C'est à peu près un rapport de 1:20 - pour une requête qui touche l'auteur, nous avons 20 "lectures sûres" qui peuvent être réparties sur les nœuds restants. En revanche, lorsque nous commençons à modifier les données, le ratio change rapidement.
MySQL [(none)]> SELECT hostgroup, srv_host, srv_port, status, queries FROM stats_mysql_connection_pool WHERE hostgroup IN (20, 10) AND status='ONLINE';
+-----------+---------------+----------+--------+---------+
| hostgroup | srv_host | srv_port | status | Queries |
+-----------+---------------+----------+--------+---------+
| 20 | 192.168.1.204 | 3306 | ONLINE | 3117 |
| 20 | 192.168.1.205 | 3306 | ONLINE | 3010 |
| 10 | 192.168.1.206 | 3306 | ONLINE | 6807 |
+-----------+---------------+----------+--------+---------+
3 rows in set (0.003 sec)Ceci est une sortie après avoir émis plusieurs notes, créé des sujets de forum et ajouté du contenu de cours. Comme vous pouvez le constater, avec un tel ratio de requêtes sécurisées/non sécurisées, le rédacteur sera saturé plus tôt que les lecteurs. Par conséquent, la mise à l'échelle en ajoutant plus de nœuds n'est pas appropriée.
Que peut-on y faire ? Il existe un paramètre appelé "latence". Selon le fichier de configuration, il détermine quand il est sûr de lire la table après l'écriture. Lorsque l'écriture se produit, la table est marquée comme modifiée et pendant le temps de "latence", tous les SELECT seront envoyés au nœud écrivain. Une fois que le temps supérieur à la "latence" est passé, les SELECT de cette table peuvent à nouveau être envoyés aux nœuds de lecture. Veuillez garder à l'esprit qu'avec MariaDB Cluster, le temps nécessaire pour que le jeu d'écriture soit appliqué sur tous les nœuds est généralement très faible, compté en millisecondes. Cela nous permettrait de définir une latence assez faible dans le fichier de configuration de Moodle, par exemple une valeur comme 0,1 s (100 millisecondes) devrait être tout à fait correcte. Bien sûr, si vous rencontrez des problèmes, vous pouvez toujours augmenter encore cette valeur.
Une autre option à tester serait de s'appuyer uniquement sur MariaDB Cluster pour savoir quand la lecture est sûre et quand elle ne l'est pas. Il existe une variable wsrep_sync_wait qui peut être configurée pour forcer les contrôles de causalité sur plusieurs modèles d'accès (lectures, mises à jour, insertions, suppressions, remplacements et commandes SHOW). Pour notre objectif, il suffirait de s'assurer que les lectures sont exécutées avec la causalité appliquée, nous allons donc définir cette variable sur "1".
Nous allons apporter cette modification à tous les nœuds du cluster MariaDB. Nous devrons également reconfigurer ProxySQL pour le fractionnement lecture/écriture en fonction des règles de requête, et pas seulement des utilisateurs, comme nous l'avions fait précédemment. Nous supprimerons également l'utilisateur "moodle_safereads" car il n'est plus nécessaire dans cette configuration.
Nous avons configuré trois règles de requête qui distribuent le trafic en fonction de la requête. SELECT … FOR UPDATE est envoyé au nœud rédacteur, toutes les requêtes SELECT sont envoyées aux lecteurs et tout le reste (INSERT, DELETE, REPLACE, UPDATE, BEGIN, COMMIT, etc.) est également envoyé au nœud rédacteur.
Cela nous permet de nous assurer que toutes les lectures peuvent être réparties sur les nœuds de lecteur, permettant ainsi une mise à l'échelle horizontale en ajoutant plus de nœuds au cluster MariaDB.
Nous espérons qu'avec ces quelques conseils, vous pourrez faire évoluer votre backend de base de données Moodle beaucoup plus facilement et dans une plus large mesure
