Touchées par la pandémie de COVID-19, de nombreuses PME/PME passent aux plateformes en ligne. Les cours en présentiel ou physiques sont également touchés par cette pandémie et de nombreuses écoles et universités passent également en ligne et recherchent des outils disponibles pour être utilisés afin de continuer à servir les étudiants ou les élèves, car l'éducation a pour ne pas être gêné. L'une des plates-formes célèbres disponibles à des fins éducatives en ligne ou d'apprentissage en ligne est Moodle.
Qu'est-ce que Moodle ?
Moodle est un logiciel open source pour le système de gestion de l'apprentissage en ligne, ou LMS (également connu sous le nom d'environnement d'apprentissage virtuel ou VLE) sous licence GPL. Il permet aux éducateurs de créer leur propre site Web privé rempli de cours dynamiques qui prolongent l'apprentissage, à tout moment, n'importe où. Moodle a un support complet avec un accès facile et des fonctionnalités pour les enseignants, les étudiants ou les administrateurs.
Puisqu'il s'agit d'une plate-forme logicielle open source et gratuite, vous pouvez utiliser ce logiciel gratuitement et sans frais de redevance, tout comme les autres logiciels open source. Les coûts ne sont encourus que lorsque ce logiciel est hébergé sur une plate-forme d'hébergement payante ou si vous l'hébergez avec leur Moodle Cloud. Moodle est également disponible pour les appareils portables tels que les mobiles ou les tablettes.
Pourquoi avez-vous besoin d'une base de données hautement disponible ?
Dans les années 1990, une solution très simple pour la Haute Disponibilité (HA) a été inventée, à savoir Heartbeat. Un cluster Heartbeat pouvait essentiellement faire deux choses :il surveillait deux nœuds (et pas plus de deux) et il était configuré pour démarrer un ou plusieurs services sur ces deux nœuds. Si le nœud qui hébergeait actuellement les ressources tombait en panne, il redémarrait les ressources du cluster sur le nœud restant. Bien que la version initiale de Heartbeat n'ait pas de surveillance des ressources elles-mêmes, cela change jusqu'à la sortie de Heartbeat 2.0 au début des années 2000, où elle permet de gérer plus de deux nœuds sur le cluster. Fondamentalement, cela comprend l'état du clustering Linux HA qui est basé en grande partie sur Heartbeat 2.0. À partir de là, de nombreuses solutions HA ont été impactées et ont été développées et créées pour minimiser les temps d'arrêt, en particulier pour les ressources critiques.
Être hautement disponible ne signifie pas seulement minimiser les temps d'arrêt. Il couvre également le degré de responsabilité d'être en mesure d'exploiter et de maintenir en permanence les services que vous offrez et que vous promettez à vos clients. Être disponible pour les clients ne signifie pas non plus que vous êtes capable de leur répondre s'ils ont besoin d'aide. Il doit rendre votre application et votre système d'entreprise pleinement fonctionnels comme s'il s'agissait toujours de l'état normal des opérations, même si une catastrophe sans précédent s'est produite.
Vous ne pouvez pas utiliser votre application VLE avec Moodle pendant que votre base de données est en maintenance. Si vous n'avez qu'un seul serveur de base de données, ce qui est très courant pour une configuration d'application simple et légère, une fois que le serveur tombe en panne, votre application s'arrête. Si vous avez un cluster de base de données utilisant la réplication maître-esclave, puis rencontrez un incident sans précédent qui à son tour que votre application écrit sur deux maîtres après l'incident, cela pourrait être un énorme gâchis qui à son tour provoque la corruption des données dans l'ensemble de votre application métier et couche de données. S'il y avait des paiements en cours à ce moment-là, cela pourrait être un énorme désastre et impliquerait une grande quantité de travail lors de la récupération des données.
Alors, pourquoi votre base de données doit-elle être hautement disponible ? C'est parce que ça doit être,
- Capable d'effectuer une maintenance ou une interruption planifiée de manière réaliste et dans la fenêtre de maintenance autorisée
- La disponibilité est vitale et doit éviter les temps d'arrêt si nécessaire
- Le SLA est important car il permet d'obtenir un service client de haute qualité
- Fournir un service et une convivialité continus
- Aucun point de défaillance unique
- Capable d'effectuer un basculement lorsque le maître tombe en panne ou tombe en panne
- Évitez le scénario de split-brain où plusieurs maîtres agissent en tant que rédacteurs actifs en même temps
Construire le cluster de bases de données
Maintenant que nous avons souligné l'importance d'avoir HA comme plan et comme solution pour votre cluster de base de données, en particulier pour PostgreSQL, concentrons-nous sur la construction du cluster de haut en bas afin d'obtenir un configuration disponible prête pour la configuration de l'application Moodle.
Installer PostgreSQL
Tout d'abord, pourquoi PostgreSQL ? PostgreSQL présente de grands avantages par rapport aux autres bases de données prises en charge par Moodle. C'est une question de préférence si je dois résumer car toutes les bases de données prises en charge par Moodle sont toutes capables de gérer les données et sont également sujettes à optimisation. Cela dépend de vos compétences et de votre expérience dans l'utilisation de la base de données. Bien que pour résumer pourquoi utiliser PostgreSQL, il s'agit d'une base de données fiable et de son logiciel open source sophistiqué, en particulier dans les bases de données qui peuvent être comparées à d'autres fournisseurs propriétaires, tels qu'Oracle et MS SQL. Il prend en charge le parallélisme des requêtes, capable de gérer des bases de données volumineuses ou énormes, prend largement en charge JSON, et bien plus encore. Vous pouvez le vérifier ici pour les raisons de choisir PostgreSQL. Passons maintenant à l'installation de PostgreSQL
Pour ce blog, nous utiliserons PostgreSQL 12 avec Ubuntu 18.04 (Bionic Beaver). Ensuite, pour la configuration de la haute disponibilité, vous devez disposer d'un nœud principal et au moins d'un nœud de secours (réplique) pour lequel il prendra le relais une fois le maître tombé en panne.
- Configurer le dépôt et la clé de signature
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 - - Installer le serveur PG 12
# Update the package lists: sudo apt-get update # Install server and client apt install postgresql-12 postgresql-client-12
Faites-le également sur le réplica cible, mais vous devez le configurer en tant que serveur de secours ou réplica. Alternativement, je vous suggère d'utiliser ClusterControl et de le télécharger car il est gratuit. Il serait plus rapide et plus rapide d'installer et de configurer une configuration principale/de secours. Pour ma configuration à l'aide de ClusterControl et de l'onglet Topologie, j'ai obtenu la topologie suivante :
Avoir une configuration maître/esclave ou primaire/veille, il ne signifie que vous êtes entièrement couvert pour un cluster de bases de données à haute disponibilité. Il n'est pas encore hautement disponible. Une fois que le primaire ou le maître tombe en panne, aucun basculement n'est lié à se produire. Une autre chose est qu'il n'y a pas d'équilibrage des connexions des clients qui vont au maître contre l'esclave. Bien que l'équilibrage de charge entre le maître/esclave n'implique pas qu'il doive être configuré ou qu'il doive être appliqué pour remplir une configuration hautement disponible. Le fait d'avoir un équilibrage de charge entre le maître/principal et un esclave/de secours aide votre nœud maître à ne pas stresser les performances de charge élevée, en particulier pendant les heures de trafic très élevé.
Configuration de l'équilibrage de charge
Comme mentionné précédemment, l'équilibrage de charge entre le maître et l'esclave aide votre maître à distinguer la charge. Ce n'est pas idéal si vous laissez votre veille uniquement à la réplication ou si vous prenez le relais en cas de panne du maître. Bien que cela puisse fonctionner, cela implique des temps d'arrêt et un travail manuel si le maître tombe en panne, car vous devez basculer le rôle de votre nœud de secours vers un maître. C'est bien aussi, mais encore une fois, avoir un équilibreur de charge peut aider à diriger les écritures vers le maître, puis à diriger les lectures entre le maître et l'esclave. Cela vous fournit essentiellement un fractionnement en lecture/écriture. Pour ce faire, vous pouvez choisir parmi de nombreuses options avec PostgreSQL. Fondamentalement, la configuration la plus courante mais la plus simple et la plus légère consiste à utiliser HAProxy.
Bien qu'il existe des options telles que l'utilisation de PgBouncer ou pgpool-II. Pour simplifier ce blog, utilisons HAProxy. Pour installer HAProxy, c'est assez simple si vous utilisez ClusterControl. Faisons cela via ClusterControl. Pour ce faire, vous pouvez simplement aller dans l'onglet Gérer, sélectionner Équilibreur de charge comme indiqué ci-dessous,
Puisque nous avons besoin d'une configuration hautement disponible pour votre cluster de base de données PostgreSQL, nous devrions avoir au moins deux nœuds. Ainsi, si votre nœud HAProxy principal tombe en panne, le HAProxy passif ou de secours peut prendre le relais. Voyons à quoi ça ressemble de mon côté,
Bien que ça ait l'air bien. Cette configuration est encore insuffisante. Si vous pensez que nous sommes bons pour une configuration hautement disponible avec cette topologie, il n'y a pas de basculement au cas où le HAProxy tombe en panne sur le nœud 192.168.30.222 au port 9600 ou si 192.168.30.223:9600 tombe en panne et si votre application est configurée pour cela hôte, il y a toujours un temps d'arrêt si aucune configuration proactive n'a été effectuée. Cela signifie que vous avez des temps d'arrêt s'il doit être configuré manuellement. Dans ce cas, nous utiliserons et configurerons Keepalived afin que les instances HAProxy soient étroitement surveillées pour leur santé et leur basculement au cas où l'autre nœud rencontrerait un problème.
Maintenir les équilibreurs de charge hautement disponibles
Maintenant que nous avons des équilibreurs de charge au-dessus de nos bases de données, nous avons besoin que notre HAProxy soit toujours actif au cas où le nœud principal du point de terminaison de l'application tomberait en panne. Fondamentalement, ce que HAProxy peut faire avec la configuration que nous avons à la section précédente, les applications peuvent utiliser le 192.168.30.223 ou 192.168.30.222 avec les ports 5433 (port en lecture-écriture) et 5434 (port en lecture seule) respectivement. Maintenant, il y a un problème au cas où vous auriez besoin de basculer au cas où les autres nœuds tomberaient en panne, et le problème est que vous nuisez à l'entreprise car cela couvre les temps d'arrêt s'il n'y a pas de basculement automatique pour y faire face. Éviter les temps d'arrêt est le meilleur moyen ici, sauf si vous avez un SLA très bas et un RTO et un RPO élevés.
Afin de remédier à un tel désastre ou temps d'arrêt, nous vous suggérons de configurer Keepalived au-dessus de HAProxy. Fondamentalement, HAProxy équilibrera la charge entre la lecture et les écritures en vous fournissant un fractionnement en lecture-écriture et Keepalived surveille uniquement la santé des nœuds HAProxy et réussira à sélectionner le nœud le plus sain en fonction de la configuration souhaitée. Keepalived est un outil que vous pouvez utiliser pour faire en sorte que les nœuds HAProxy soient surveillés, bien que la gestion des bases de données ne soit pas aussi complexe. Keepalived utilise VIP (Virtual IP) qui attribue au nœud HAProxy principal par défaut, puis réattribue ce VIP en cas de défaillance du nœud HAProxy principal et le pointe vers le nœud HAProxy suivant ou de secours.
Maintenant, configurons cela à l'aide de ClusterControl car il est plus rapide et plus facile à gérer avec ClusterControl. Pour ce faire, c'est fondamentalement la même approche que la façon dont nous configurons le HAProxy, mais à la place, sélectionnez Keepalived comme indiqué ci-dessous,
Fondamentalement, si vous installez le Keepalived manuellement, nous sélectionnons le primaire contre le secondaire en cas de défaillance du HAProxy principal. Voyons à quoi ressemble notre vue Topologie,
Cela peut sembler très prometteur. Fondamentalement, le client de l'application Moodle se connectera au VIP, c'est-à-dire 192.168.30.201 sous les ports 5433 (port en lecture-écriture) et 5434 (port en lecture seule). Par exemple, en le vérifiant sur un hôte externe que j'ai,
[[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)ce qui révèle que seul le nœud écrivain que j'ai pointe vers mon nœud maître, c'est-à-dire 192.168.30.22. Ensuite, mon port en lecture seule doit aller à la fois aux nœuds maître et esclave, comme indiqué ci-dessous,
[[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)Cela révèle que mes nœuds principal et de secours sont identifiés comme des nœuds de "lecture de la base de données".
Maintenant, cela semble très prometteur comme ce que j'ai dit plus tôt. Pourtant, il manque ici une partie qui est en fait très importante. Aucun mécanisme de basculement de base de données n'est prêt pour ce type de configuration. Pourtant, nous avons Keepalived qui surveille HAProxy, puis effectue un basculement en commutant le VIP en cas de défaillance ou de mort du HAProxy principal. Pourtant, Keepalived n'est pas configuré pour gérer la configuration complexe de PostgreSQL. Il y en a un très décent qui est disponible et gratuit pour le configurer. Vous pouvez utiliser Slony-I, un système de réplication tiers.
Disposer d'un mécanisme de basculement pour votre cluster PostgreSQL
Il existe des moyens de fournir un mécanisme de basculement pour votre PostgreSQL. Slony-I ou communément appelé simplement Slony est l'un des outils couramment utilisés. Bien que Slony exige que votre configuration soit une réplication logique car elle nécessite une configuration éditeur/abonné, elle peut ne pas être idéale pour d'autres configurations qui utilisent une réplication de streaming standard. L'inconvénient de l'utilisation de Slony est qu'il ne fournit aucune détection automatique des systèmes défaillants ou aucun support de clôture de nœud. Par conséquent, un STONITH communément appelé (tirer sur l'autre nœud dans la tête ou tirer sur le nœud défaillant dans la tête) qui élimine essentiellement l'échec pour ne pas éviter les scénarios de cerveau divisé où plusieurs nœuds maîtres (nœuds d'écriture actifs) acceptent les écritures au en même temps. Bien que cela puisse être configuré de manière appropriée, cela peut néanmoins prendre du temps et être compliqué s'il est créé avec moins d'expérience et d'informations sur les scénarios susceptibles de se produire pour PostgreSQL lorsqu'un sinistre se produit. Pour Slony, l'abandon des transactions validées est une décision commerciale qui ne peut pas être prise par un système de base de données. Si quelqu'un souhaite placer les commandes ci-dessous dans un script exécuté automatiquement à partir du système de surveillance du réseau, il vous laisse simplement à votre disposition qu'il s'agit de vos données et de votre politique de basculement.
Alternativement, si vous recherchez des options d'entreprise tout en pouvant prendre votre argent à un coût raisonnable, alors ClusterControl dispose d'une récupération automatique pour les clusters PostgreSQL. Fondamentalement, la récupération automatique répond aux problèmes énoncés ci-dessus avec Slony. Bien que notre récupération automatique soit mieux testée avec la réplication en continu et ne soit prise en charge que pour le type de réplication en continu de la configuration PostgreSQL. Alors, comment ça marche? Fondamentalement, il vous suffit d'activer les boutons de récupération automatique comme ci-dessous,
Cela prend en charge la clôture de nœud, ce qui signifie qu'il supprimera le nœud défaillant au cas où le nœud revient en vie pour une raison qui n'est pas prévue. En dehors de cela, la récupération automatique par ClusterControl prend en charge la récupération des nœuds et des clusters. Si un nœud maître ou esclave a été accidentellement arrêté ou tué, ClusterControl tentera de le réactiver, en particulier s'il se produit en dehors d'une panne planifiée ou d'une fenêtre de maintenance. Cette fonctionnalité vous évite d'avoir épuisé les craintes liées à la base de données et vous fournit en même temps une surveillance proactive qui vous avertira d'un éventuel sinistre avant qu'il ne soit trop tard pour récupérer.
Conclusion
Les configurations hautement disponibles pour votre cluster de base de données, en particulier pour Moodle, peuvent varier en fonction du type de configuration et des exigences dont vous avez besoin. Qu'il s'agisse uniquement de technologies gratuites et open source ou qu'il existe d'autres options qui valent la peine d'investir pour votre application d'entreprise tant que le budget peut s'adapter car il peut vous fournir une situation gagnant-gagnant, surtout si vous voulez plus de concentration uniquement sur le côté commercial des choses plutôt que de se concentrer sur d'autres outils tels que l'administration et le type de travail devops.
