Moodle est le système de gestion de l'apprentissage (LMS) le plus populaire permettant aux enseignants de créer leur propre site Web avec des cours ou du contenu qui prolongent l'apprentissage. Ces types de plateformes deviennent de plus en plus importants pour vous permettre de continuer à apprendre à distance lorsque le système éducatif traditionnel n'est pas disponible ou simplement en complément de celui-ci, de sorte que l'augmentation du trafic ou des utilisateurs nécessite de faire évoluer votre environnement pour assurer une faible réponse. temps.
L'évolutivité est la propriété d'un système/base de données pour gérer une quantité croissante de demandes en ajoutant des ressources. Il existe différentes approches disponibles pour mettre à l'échelle votre base de données en fonction de la manière dont vous devez la mettre à l'échelle et, dans un environnement de production, un long temps d'arrêt n'est probablement pas souhaité, vous devez donc également en tenir compte.
Dans ce blog, nous verrons quelles options de mise à l'échelle sont disponibles et comment mettre à l'échelle votre base de données Moodle PostgreSQL de manière simple sans affecter votre système en cours d'exécution.
Mise à l'échelle horizontale et mise à l'échelle verticale
Il existe deux manières principales de faire évoluer votre base de données :
- Mise à l'échelle horizontale (scale-out) :elle est effectuée en ajoutant plus de nœuds de base de données en créant ou en augmentant un cluster de base de données.
- Vertical Scaling (scale-up) :il est effectué en ajoutant plus de ressources matérielles (CPU, mémoire, disque) à un nœud de base de données existant.
Pour la mise à l'échelle horizontale , vous pouvez ajouter d'autres nœuds de base de données en tant que nœuds de secours. Cela peut vous aider à améliorer les performances de lecture en équilibrant le trafic entre les nœuds. Dans ce cas, vous devrez ajouter un équilibreur de charge pour distribuer le trafic au bon nœud en fonction de la politique et de l'état du nœud. Vous devriez également envisager d'ajouter deux nœuds d'équilibrage de charge ou plus pour éviter un point de défaillance unique, et d'utiliser un outil comme « Keepalived », pour assurer la disponibilité. Keepalived est un service qui vous permet de configurer une adresse IP virtuelle au sein d'un groupe de serveurs actif/passif. Cette adresse IP virtuelle est attribuée à un serveur actif (actif Load Balancer). Si ce serveur échoue, l'adresse IP est automatiquement migrée vers le serveur passif "secondaire", lui permettant de continuer à fonctionner avec la même adresse IP de manière transparente pour les systèmes.
Pour la mise à l'échelle verticale , il peut être nécessaire de modifier certains paramètres de configuration pour permettre à PostgreSQL d'utiliser une ressource matérielle nouvelle ou meilleure. Voyons certains de ces paramètres dans la documentation de PostgreSQL.
- work_mem :spécifie la quantité de mémoire à utiliser par les opérations de tri internes et les tables de hachage avant d'écrire dans les fichiers de disque temporaires. Plusieurs sessions en cours d'exécution peuvent effectuer de telles opérations simultanément, de sorte que la mémoire totale utilisée peut être plusieurs fois supérieure à la valeur de work_mem.
- maintenance_work_mem :spécifie la quantité maximale de mémoire à utiliser par les opérations de maintenance, telles que VACUUM, CREATE INDEX et ALTER TABLE ADD FOREIGN KEY. Des paramètres plus importants peuvent améliorer les performances de nettoyage et de restauration des vidages de base de données.
- autovacuum_work_mem :spécifie la quantité maximale de mémoire à utiliser par chaque processus de travail autovacuum.
- autovacuum_max_workers :spécifie le nombre maximal de processus d'autovacuum pouvant être exécutés à tout moment.
- max_worker_processes :définit le nombre maximal de processus d'arrière-plan que le système peut prendre en charge. Spécifiez la limite du processus, comme l'aspiration, les points de contrôle et d'autres tâches de maintenance.
- max_parallel_workers :définit le nombre maximal de nœuds de calcul que le système peut prendre en charge pour les opérations parallèles. Les travailleurs parallèles sont extraits du pool de processus de travail établi par le paramètre précédent.
- max_parallel_maintenance_workers :définit le nombre maximal de travailleurs parallèles pouvant être démarrés par une seule commande d'utilitaire. Actuellement, la seule commande d'utilitaire parallèle qui prend en charge l'utilisation de travailleurs parallèles est CREATE INDEX, et uniquement lors de la construction d'un index B-tree.
- effective_cache_size :définit l'hypothèse du planificateur concernant la taille effective du cache disque disponible pour une seule requête. Ceci est pris en compte dans les estimations du coût d'utilisation d'un indice; une valeur plus élevée augmente la probabilité d'utiliser des analyses d'index, une valeur inférieure augmente la probabilité d'utiliser des analyses séquentielles.
- shared_buffers :définit la quantité de mémoire utilisée par le serveur de base de données pour les tampons de mémoire partagée. Des paramètres nettement supérieurs au minimum sont généralement nécessaires pour obtenir de bonnes performances.
- temp_buffers :définit le nombre maximal de tampons temporaires utilisés par chaque session de base de données. Ce sont des tampons locaux de session utilisés uniquement pour accéder aux tables temporaires.
- effective_io_concurrency :définit le nombre d'opérations d'E/S de disque simultanées qui, selon PostgreSQL, peuvent être exécutées simultanément. L'augmentation de cette valeur augmentera le nombre d'opérations d'E/S que toute session PostgreSQL individuelle tentera d'initier en parallèle. Actuellement, ce paramètre n'affecte que les analyses de tas bitmap.
- max_connections :détermine le nombre maximal de connexions simultanées au serveur de base de données. L'augmentation de ce paramètre permet à PostgreSQL d'exécuter plus de processus backend simultanément.
Le défi ici peut être de savoir si vous devez faire évoluer votre base de données Moodle et de quelle manière, et la réponse est la surveillance.
Surveillance de PostgreSQL pour Moodle
La mise à l'échelle d'une base de données est un processus complexe, vous devez donc vérifier certaines métriques pour pouvoir déterminer la meilleure stratégie pour la mettre à l'échelle.
Vous pouvez surveiller l'utilisation du processeur, de la mémoire et du disque pour déterminer s'il y a un problème de configuration ou si vous devez réellement mettre à l'échelle votre base de données. Par exemple, si vous constatez une charge de serveur élevée mais que l'activité de la base de données est faible, il n'est probablement pas nécessaire de la mettre à l'échelle, il vous suffit de vérifier les paramètres de configuration pour la faire correspondre à vos ressources matérielles.
Vérifier l'espace disque utilisé par le nœud PostgreSQL par base de données peut vous aider à confirmer si vous avez besoin de plus de disque ou même d'une partition de table. Pour vérifier l'espace disque utilisé par une base de données/table, vous pouvez utiliser une fonction PostgreSQL comme pg_database_size ou pg_table_size.
Du côté de la base de données, vous devez vérifier :
- Nombre de connexions
- Exécuter des requêtes
- Utilisation de l'index
- Bloat
- Délai de réplication
Il peut s'agir de mesures claires pour confirmer si la mise à l'échelle de votre base de données est nécessaire.
ClusterControl en tant que système de mise à l'échelle et de surveillance
ClusterControl peut vous aider à faire face aux deux méthodes de mise à l'échelle que nous avons mentionnées précédemment et à surveiller toutes les métriques nécessaires pour confirmer l'exigence de mise à l'échelle.
Si vous n'utilisez pas encore ClusterControl, vous pouvez l'installer et déployer ou importer votre base de données PostgreSQL actuelle en sélectionnant l'option "Importer" et suivre les étapes, pour profiter de toutes les fonctionnalités de ClusterControl comme les sauvegardes, basculement automatique, alertes, surveillance, etc.
Mise à l'échelle horizontale
Pour la mise à l'échelle horizontale, si vous accédez aux actions de cluster et sélectionnez "Ajouter un esclave de réplication", vous pouvez soit créer un nouveau réplica à partir de zéro, soit ajouter une base de données PostgreSQL existante en tant que réplica.
Voyons comment l'ajout d'un nouvel esclave de réplication peut être une tâche vraiment facile.
Comme vous pouvez le voir sur l'image, il vous suffit de choisir votre Master serveur, entrez l'adresse IP de votre nouveau serveur esclave et le port de la base de données. Ensuite, vous pouvez choisir si vous voulez que ClusterControl installe le logiciel pour vous et si l'esclave de réplication doit être synchrone ou asynchrone.
De cette façon, vous pouvez ajouter autant de répliques que vous le souhaitez et répartir le trafic de lecture entre elles à l'aide d'un équilibreur de charge, que vous pouvez également implémenter avec ClusterControl.
Maintenant, si vous accédez aux actions de cluster et sélectionnez "Ajouter un équilibreur de charge", vous pouvez déployer un nouvel équilibreur de charge HAProxy ou en ajouter un existant.
Et puis, dans la même section load balancer, vous pouvez ajouter un Keepalived service qui s'exécutera sur les nœuds de l'équilibreur de charge pour améliorer votre environnement de haute disponibilité.
Après l'ajout d'un équilibreur de charge ou l'utilisation d'une adresse IP virtuelle ayant le service Keepalived dans place, vous devez mettre à jour votre configuration Moodle pour utiliser le nouveau point de terminaison de la base de données. Pour cela, rendez-vous dans votre répertoire racine Moodle et modifiez le fichier config.php avec la nouvelle adresse IP :
$CFG->dbhost = 'IP_ADDRESS';
$CFG->dbname = 'moodle';
$CFG->dbuser = 'mdluser';
$CFG->dbpass = '********';
$CFG->prefix = 'mdl_';
$CFG->dboptions = array (
'dbpersist' => 0,
'dbport' => PORT,
'dbsocket' => '',
);Assurez-vous que vous pouvez accéder à votre base de données via l'équilibreur de charge ou l'adresse IP virtuelle, ou si vous devez mettre à jour votre fichier PostgreSQL pg_hba.conf pour l'autoriser.
Échelle verticale
Pour la mise à l'échelle verticale, avec ClusterControl, vous pouvez surveiller vos nœuds de base de données à la fois du système d'exploitation et du côté de la base de données. Vous pouvez vérifier certaines mesures telles que l'utilisation du processeur, la mémoire, les connexions, les principales requêtes, les requêtes en cours d'exécution, etc. Vous pouvez également activer la section Tableau de bord, qui vous permet de voir les métriques de manière plus détaillée et plus conviviale.
Depuis ClusterControl, vous pouvez également effectuer différentes tâches de gestion telles que Redémarrer l'hôte, Reconstruire Esclave de réplication ou Promouvoir l'esclave en un seul clic.
Conclusion
La mise à l'échelle de votre base de données Moodle PostgreSQL peut être une tâche difficile car vous devrez savoir comment vous devez évoluer et comment le faire sans affecter les systèmes. Avoir un bon système de surveillance est la première étape pour savoir quand et comment vous devez faire évoluer votre base de données Moodle. L'ajout d'un équilibreur de charge vous aidera à éviter les temps d'arrêt inutiles et améliorera également la haute disponibilité dans votre environnement LMS.
Toutes ces choses que nous avons mentionnées peuvent être faites en utilisant ClusterControl, ce qui facilitera le travail. ClusterControl fournit toute une gamme de fonctionnalités, telles que la surveillance, les alertes, le basculement automatique, la sauvegarde, la récupération ponctuelle, la vérification des sauvegardes, la mise à l'échelle, etc.
