MongoDB
 sql >> Base de données >  >> NoSQL >> MongoDB

Comment déployer la base de données Open edX MongoDB pour une haute disponibilité

Open edX est une plate-forme qui fournit la technologie logicielle d'apprentissage massivement évolutive derrière edX. Le projet Open edX est une plate-forme Web pour la création, la diffusion et l'analyse de cours en ligne. C'est le logiciel qui alimente edx.org et de nombreux autres sites d'éducation en ligne.

Nous avons déjà blogué sur le déploiement d'une base de données haute disponibilité pour MySQL sur la plate-forme Open edX. Comme dit précédemment, il s'agit d'une plate-forme complexe car elle couvre plusieurs composants, et une partie de cette énorme plate-forme est couverte par plusieurs services :

  • e-commerce :https://github.com/edx/ecommerce
  • Catalogue :https://github.com/edx/course-discovery
  • LMS/Studio :https://github.com/edx/edx-platform
  • Identifiants :https://github.com/edx/credentials
  • Insights :https://github.com/edx/edx-analytics-dashboard
  • API Analytics :https://github.com/edx/edx-analytics-data-api

Essentiellement, l'Open Edx est parfait pour les cours en ligne en période de pandémie et de formation en ligne comme ce que vous avez peut-être déjà essayé et suivi, surtout si vous obtenez une certification de produit.

Brève présentation de l'architecture

La pièce maîtresse de l'architecture Open edX est la plate-forme edx, qui contient les applications de gestion de l'apprentissage et de création de cours (LMS et Studio, respectivement). Outre sa plate-forme edx, les services techniques comprenant l'ensemble de la plate-forme comprennent diverses technologies impliquées qui couvrent tout un niveau complexe de ce logiciel. Voir le schéma ci-dessous tiré de la présentation de l'équipe edX en décembre dernier.

Vous avez Snowflake, Amazon RDS, MongoDB, Amazon S3, Elasticsearch, Memcached , et Redis en tant que technologies incarnant cette plate-forme riche. Pourtant, il est même difficile d'installer et de configurer Open edX, mais j'ai réussi à mettre en place un environnement de développement simple pour comprendre un peu cette plate-forme.

En attendant, concentrons-nous sur MongoDB qui est utilisé pour stocker le contenu des forums, de la structure du cours et des actifs du cours. Les données par apprenant sont stockées dans MySQL, donc si vous voulez connaître et avoir une haute disponibilité pour votre MySQL avec Open edX, lisez-le ici.

Stocker du contenu pour MongoDB

MongoDB est la base de données de choix d'Open edX pour stocker des fichiers volumineux tels que des fichiers texte, des PDF, des clips audio/vidéo, des archives tar, etc. Si vous connaissez Open edX et que vous l'avez utilisé en particulier comme un auteur pour le LMS ou Studio, les données sont stockées si vous téléchargez des actifs dans votre configuration Open edX. Ces téléchargements sont appelés "contentstore", c'est essentiellement une instance GridFS soutenue par MongoDB. Open edX utilise MongoDB GridFS afin de stocker les données de fichiers en morceaux dans une instance MongoDB et est capable de stocker des fichiers d'une taille supérieure à 16 Mo. Il peut également servir des portions de fichiers volumineux au lieu du fichier entier.

Un élément peut être téléchargé comme "verrouillé" ou "déverrouillé". Un actif verrouillé n'est disponible que pour les étudiants qui suivent un cours particulier - la plate-forme edx vérifie le rôle de l'utilisateur avant de servir le fichier. Les actifs déverrouillés sont servis à tout utilisateur sur demande. Lorsqu'un étudiant d'un cours demande une ressource, la totalité de la ressource est servie à partir de GridFS.

Configurer une haute disponibilité pour votre base de données Open edX MongoDB

Admettons que l'installation ou la mise en place de votre plateforme Open edX est un beau challenge. C'est difficile surtout que vous soyez nouveau sur cette plate-forme ou ce logiciel, mais il a une très bonne conception architecturale. Cependant, il est possible que votre configuration avec votre MongoDB soit un ensemble de répliques à un nœud comme principal. D'autre part, il est préférable que votre jeu de répliques ait au moins un ou plusieurs nœuds secondaires en plus du nœud principal. Cela sert votre configuration de haute disponibilité au cas où votre nœud principal deviendrait kaput, votre nœud de réplica secondaire assumerait le rôle principal.

Configurer un jeu de répliques avec des répliques secondaires

Pour cela, il vous suffit d'ajouter et de configurer au moins deux répliques secondaires. L'idéal est qu'au moins, dans un jeu de répliques, vous ayez 3 nœuds pour lesquels l'un est votre primaire, puis les deux autres nœuds sont vos secondaires se répliquant vers le primaire. Cela permet à l'ensemble MongoDB Replica de procéder à une élection au cas où le primaire perdrait la connectivité avec ses secondaires. Cela vous donne fiabilité, redondance et bien sûr une haute disponibilité. Il s'agit d'une configuration simple que vous pouvez avoir pour obtenir un environnement hautement disponible avec MongoDB.

Pourquoi cela offre-t-il une haute disponibilité ? Un jeu de répliques dans MongoDB est un groupe de processus mongod qui conservent le même jeu de données. Les ensembles de réplicas MongoDB utilisent des élections pour déterminer quel membre de l'ensemble deviendra principal à l'événement que le principal tombe en panne ou s'est terminé anormalement ou à certains changements de configuration. Les ensembles de répliques peuvent déclencher une élection en réponse à divers événements, tels que :

  • Ajout d'un nouveau nœud au jeu de répliques,
  • initier un jeu de répliques,
  • effectuer la maintenance du jeu de répliques à l'aide de méthodes telles que rs.stepDown() ou rs.reconfig(), et
  • les membres secondaires perdent la connectivité avec le principal pendant plus que le délai configuré (10 secondes par défaut).

Prenez cet exemple de diagramme qui visualise le fonctionnement de l'élection.

Image reproduite avec l'aimable autorisation de la documentation MongoDB

De plus, vous pouvez utiliser les autres réplicas secondaires comme votre préférence de lecture, mais cela dépend de la configuration basée sur la connexion de votre client. Vous pouvez en savoir plus en lisant les options de préférence de lecture pour la connexion ou en consultant la préférence de lecture ici.

Maintenant, cela a l'air génial, mais la gestion du point de terminaison de votre client d'application, comme la modification du nom d'hôte ou de l'adresse IP, nécessite une modification manuelle. Ce n'est pas idéal si vous avez un équilibreur de charge au-dessus de votre ensemble de répliques, tout comme HaProxy, car MongoDB Replica Set effectue l'élection en interne de MongoDB.

Configurer un cluster partagé

Le cluster partagé est idéal si vous avez affaire à une grande taille d'ensembles de données. Bien que cela ne signifie pas que vous devez concevoir un cluster fragmenté, il doit traiter de grands ensembles de données. MongoDB propose mongos, qui est un utilitaire qui doit agir comme un service de routage pour les configurations de partition MongoDB qui traite les requêtes de la couche application puis détermine l'emplacement de ces données dans le cluster partitionné identifié par sa clé de partition afin de compléter ses transactions ou sa base de données. opérations. Fondamentalement, pensez simplement que les instances mongos se comportent de la même manière que n'importe quelle autre instance MongoDB.

Alors pourquoi avoir un mongos devant votre application ? Lorsque votre réplique définit le nom d'hôte principal ou l'adresse IP change après l'élection, du point de vue de l'application, cela signifie que vous devez également modifier le point de terminaison. Avec mongos, pointez simplement votre client d'application vers l'une de nos instances mongos. Votre client d'application s'interface uniquement avec l'instance mongos et c'est tout ce qui compte. Les mongos seront ceux qui traiteront vos requêtes ou transactions en utilisant son objectif et sa fonction pour votre configuration MongoDB Shard. Cela signifie que dans vos fichiers de configuration Open edx, il n'y a aucune modification à apporter. Vous n'avez pas besoin de redémarrer vos serveurs d'applications pour rattraper les modifications de vos ensembles de répliques MongoDB.

Comment configurer la haute disponibilité

Par exemple, en utilisant ClusterControl. L'utilisation de ClusterControl peut être réalisée simplement et efficacement car cela peut être fait via l'interface utilisateur en évitant ces configurations et installations manuelles pour une configuration très complexe.

Considérons que vous avez une instance MongoDB existante avec une base de données Open edX existante,

rs0:PRIMARY> show dbs;

admin                0.000GB

cs_comments_service  0.000GB

edxapp               0.087GB

local                0.118GB



rs0:PRIMARY> rs.status()

{

        "set" : "rs0",

        "date" : ISODate("2021-01-22T14:46:51.398Z"),

        "myState" : 1,

        "term" : NumberLong(17),

        "heartbeatIntervalMillis" : NumberLong(2000),

        "members" : [

                {

                        "_id" : 0,

                        "name" : "192.168.40.10:27017",

                        "health" : 1,

                        "state" : 1,

                        "stateStr" : "PRIMARY",

                        "uptime" : 133,

                        "optime" : {

                                "ts" : Timestamp(1611326680, 1),

                                "t" : NumberLong(17)

                        },

                        "optimeDate" : ISODate("2021-01-22T14:44:40Z"),

                        "electionTime" : Timestamp(1611326679, 1),

                        "electionDate" : ISODate("2021-01-22T14:44:39Z"),

                        "configVersion" : 2,

                        "self" : true

                }

        ],

        "ok" : 1

}

Vous pouvez simplement l'importer en tant que base de données existante dans ClusterControl et effectuer une sauvegarde à l'aide de la fonction de sauvegarde de ClusterControl. Vous pouvez également utiliser mongodump ou essayer d'utiliser la sauvegarde Percona pour MongoDB.

Maintenant, dans ClusterControl, créez un fragment MongoDB en tant que nouveau déploiement. Cela peut être fait en suivant les étapes suivantes :

  1. Déployez un nouveau fragment MongoDB dans la boîte de dialogue de l'assistant de déploiement.

  1. Configurez les paramètres SSH et ses serveurs et routeurs de configuration. C'est là que vos instances mongos doivent être en dehors de vos serveurs de configuration.

  1. Définissez vos fragments. Il s'agit de vos fragments d'ensemble de répliques. Selon votre besoin. Par exemple, dans ce déploiement, j'ai déployé deux partitions, mais vous ne pouvez utiliser qu'une seule partition pour commencer, en particulier pour les petits déploiements.

  1. Définir les paramètres de votre base de données

À ce stade, appuyez sur le bouton de déploiement et attendez que le travail soit traité par ClusterControl.

  1. Une fois terminé, vous pouvez maintenant restaurer la sauvegarde que vous avez prise depuis mongodump. Par exemple, j'ai effectué une sauvegarde à l'aide de ClusterControl, puis je l'ai utilisée comme sauvegarde source. Lorsque vous utilisez la commande mongorestore, assurez-vous que votre hôte de destination est l'une de vos instances mongos. Pour cet exemple de déploiement, j'ai l'hôte 192.168.40.233.

$ mongorestore --host 192.168.40.233 --port 27017 --username <username> --password <password> --gzip  --archive=BACKUP-2/rs0.gz --authenticationDatabase=admin

2021-01-22T11:17:06.335+0000    preparing collections to restore from

2021-01-22T11:17:06.336+0000    don't know what to do with subdirectory "cs_comments_service", skipping...

2021-01-22T11:17:06.336+0000    don't know what to do with subdirectory "edxapp", skipping...

2021-01-22T11:17:06.337+0000    don't know what to do with subdirectory "admin", skipping...

2021-01-22T11:17:06.337+0000    don't know what to do with subdirectory "", skipping...

2021-01-22T11:17:06.372+0000    restoring to existing collection edxapp.modulestore.definitions without dropping

2021-01-22T11:17:06.372+0000    reading metadata for edxapp.modulestore.definitions from archive 'BACKUP-2/rs0.gz'

2021-01-22T11:17:06.373+0000    restoring edxapp.modulestore.definitions from archive 'BACKUP-2/rs0.gz'

2021-01-22T11:17:06.387+0000    restoring to existing collection edxapp.fs.chunks without dropping

2021-01-22T11:17:06.387+0000    reading metadata for edxapp.fs.chunks from archive 'BACKUP-2/rs0.gz'

…

……
  1. Maintenant, vous êtes prêt et apportez quelques modifications à vos fichiers de configuration Open edX . Dans ma configuration d'installation, vous pouvez mettre à jour /edx/etc/studio.yml et  /edx/etc/lms.yml. Vous devrez peut-être également modifier les fichiers dans les fichiers /edx/app/edxapp/lms.auth.json et /edx/app/edxapp/cms.auth.json et les remplacer par le nom d'hôte correct de votre instance mongos.

  2. Vérifiez dans vos mongos et vérifiez si les bases de données sont chargées et peuvent être accessibles,

[email protected]:~# mongo --host "mongodb://edxapp:[email protected]:27017/?authSource=admin"

MongoDB shell version v4.2.11

connecting to: mongodb://192.168.40.233:27017/?authSource=admin&compressors=disabled&gssapiServiceName=mongodb

Implicit session: session { "id" : UUID("00a3a395-3531-4381-972e-502478af38d1") }

MongoDB server version: 4.2.11

mongos> show dbs

admin                0.000GB

config               0.002GB

cs_comments_service  0.000GB

edxapp               0.104GB

Maintenant, vous êtes prêt !!!

Dans la vue Web également de ClusterControl, une fois que le ClusterControl a terminé le déploiement, vous aurez une topologie qui ressemblera à ceci,

Une fois cela fait, tout est bon pour gérer votre Open edX et gérer vos cours !