Open edX est une plateforme d'activités éducatives en ligne. Compte tenu de la situation dans laquelle se trouve le monde, toutes ces plates-formes sont confrontées à des charges plus élevées et leur importance a considérablement augmenté. Ce ne sont pas seulement les plateformes "d'aide", mais elles deviennent souvent le principal moyen par lequel les activités éducatives sont réalisées. Cela conduit à des exigences plus élevées concernant la charge qu'ils peuvent gérer ou la disponibilité de la plate-forme.
Open edX est un produit complexe composé de plusieurs éléments. L'un d'eux est la base de données MySQL. Dans ce court blog, nous aimerions discuter de la manière dont vous pouvez améliorer la haute disponibilité de la plate-forme Open edX.
De toute évidence, la base de données MySQL unique est un point de défaillance unique et, en tant que tel, ce n'est pas une approche adaptée aux déploiements de production. Il existe plusieurs façons d'améliorer la disponibilité de la base de données MySQL.
Pour commencer, vous pouvez exécuter la configuration maître - esclave en utilisant une réplication asynchrone ou semi-synchrone. L'avantage est que, lorsque le maître est indisponible, vous pouvez promouvoir l'un des esclaves et poursuivre l'opération. Le principal inconvénient d'une telle configuration est que le basculement doit être effectué soit manuellement, ce qui augmente le temps d'arrêt, soit vous devez utiliser un logiciel externe (par exemple ClusterControl), mais cela peut encore prendre un peu de temps. Enfin, tout type de réplication asynchrone ou semi-synchrone est sujet à un décalage de réplication. Cela peut avoir un impact sérieux sur les scénarios de lecture après écriture dans lesquels l'application exécute une écriture sur le maître, puis tente immédiatement de lire ces données à partir de l'esclave.
Une autre approche consisterait à utiliser un cluster Galera pour stocker les données de la plate-forme Open edX. Nous pouvons commencer avec des clusters à trois nœuds - ces clusters peuvent gérer automatiquement la défaillance d'un seul nœud. Les deux nœuds restants continueront de fonctionner et répondront aux requêtes provenant de l'application. Un autre avantage de Galera est que, même s'il est "virtuellement" synchrone (ce qui signifie à peu près qu'il est presque synchrone), il existe un moyen d'appliquer des contrôles de causalité et de forcer les clusters en mode synchrone (même si vous payez pour cela avec performances réduites).
Les deux scénarios nécessiteraient une sorte d'équilibreur de charge devant eux, qui gérerait le trafic et le redirigerait vers une destination appropriée.
Voyons comment ClusterControl peut vous aider à déployer un cluster Galera avec un ensemble d'équilibreurs de charge que vous pouvez utiliser pour votre plate-forme Open edX.
Déployer le 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 devons définir la connectivité SSH, sans mot de passe, clé L'accès SSH basé sur est une exigence pour ClusterControl, sinon il ne pourra pas gérer l'infrastructure de la base de données.
Ensuite, nous devons décider du fournisseur, de la version, du mot de passe, des hôtes et certains paramètres supplémentaires :
Avec tous ces détails renseignés, nous sommes prêts à procéder au déploiement.
Déployer ProxySQL
La base de données elle-même n'est pas le seul élément que nous souhaitons déployer. Nous avons également besoin d'un équilibreur de charge que nous utiliserons pour diriger le trafic vers les nœuds disponibles à un moment donné. Nous l'utiliserons également pour fournir une division lecture/écriture, en dirigeant toutes les écritures vers un seul nœud MariaDB Galera. Cela nous aidera à éviter les conflits entre les écritures exécutées sur différents nœuds Galera.
Pour ProxySQL ClusterControl nécessite également de remplir certaines informations - vous devez choisir le hôte sur lequel l'installer, décidez de la version de ProxySQL, des informations d'identification pour les utilisateurs administratifs et de surveillance. Ces utilisateurs seront utilisés pour gérer ProxySQL et surveiller l'état de votre cluster Galera. Vous devez également importer des utilisateurs de base de données existants ou en créer un nouveau pour votre application. Enfin, c'est à vous de décider quels nœuds de base de données vous souhaitez utiliser avec ProxySQL et de décider si vous utilisez des transactions implicites.
Déployer Keepalived
Dans la prochaine étape, nous déploierons Keepalived. L'idée ici est d'avoir une adresse IP virtuelle qui pointera vers l'instance ProxySQL de travail. Ce VIP peut ensuite être utilisé dans l'application comme point de terminaison pour la connectivité de la base de données MySQL.
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 :
C'est à peu près tout en ce qui concerne le déploiement. Vous pouvez pointer votre plateforme Open edX vers le VIP et le port 6033, cela devrait suffire pour obtenir la connectivité à votre base de données backend. Le dernier bit restant, si vous le jugez nécessaire, serait de configurer les contrôles de causalité. Il existe une variable wsrep_sync_wait qui peut faire exactement cela. Il peut activer des tests sur plusieurs modèles d'accès :lectures, mises à jour, insertions, suppressions, remplacements et commandes SHOW. Si nous ne sommes intéressés que par les requêtes SELECT, nous mettrons cette variable à '1' en utilisant la gestion de la configuration de ClusterControl.
Cela effectuera cette modification sur tous les nœuds du cluster MariaDB.
C'est à peu près tout. Si vous souhaitez partager une partie de votre expérience avec Open edX, n'hésitez pas à nous laisser un commentaire.
