Hoe de Open edX MongoDB-database te implementeren voor hoge beschikbaarheid

Open edX is een platform dat de enorm schaalbare leersoftwaretechnologie achter edX biedt. Het Open edX-project is een webgebaseerd platform voor het maken, leveren en analyseren van online cursussen. Het is de software die edx.org en vele andere online onderwijssites aandrijft.

We hebben eerder geblogd over het implementeren van een High Availability for MySQL-database op het Open edX-platform. Zoals eerder vermeld, is het een complex platform omdat het meerdere componenten omvat, en als onderdeel van dit enorme platform wordt het gedekt door meerdere services:

eCommerce:https://github.com/edx/ecommerce
Catalogus:https://github.com/edx/course-discovery
LMS / Studio:https://github.com/edx/edx-platform
Inloggegevens:https://github.com/edx/credentials
Inzichten:https://github.com/edx/edx-analytics-dashboard
Analytics-API:https://github.com/edx/edx-analytics-data-api

In wezen is de Open Edx perfect voor online cursussen te midden van pandemie en online training, zoals je misschien al hebt geprobeerd en gevolgd, vooral als je een productcertificering behaalt.

Kort architectonisch overzicht

Het middelpunt van de Open edX-architectuur is het edx-platform, dat de toepassingen voor leerbeheer en het schrijven van cursussen bevat (respectievelijk LMS en Studio). Naast het edx-platform omvat de technische dienstverlening die het hele platform omvat, verschillende betrokken technologieën die een heel complex niveau van deze software dekken. Zie het onderstaande diagram uit de presentatie van het edX-team afgelopen december.

Je hebt Snowflake, Amazon RDS, MongoDB, Amazon S3, Elasticsearch, Memcached , en Redis als de technologieën die dit rijke platform belichamen. Toch is het zelfs moeilijk om Open edX te installeren en in te stellen, maar het is me gelukt om een eenvoudige ontwikkelomgeving op te zetten om een beetje van dit platform te begrijpen.

Laten we ons concentreren op MongoDB, dat wordt gebruikt om inhoud op te slaan voor forums, cursusstructuur en cursusmiddelen. Per-leerlinggegevens worden opgeslagen in MySQL, dus als u uw MySQL met Open edX wilt weten en high availability wilt hebben, lees het dan hier.

Inhoud opslaan voor MongoDB

MongoDB is de favoriete database van Open edX voor het opslaan van grote bestanden, zoals tekstbestanden, PDF's, audio-/videoclips, tarballs, enz. Als u bekend bent met Open edX en het vooral hebt gebruikt als een auteur voor de LMS of Studio, worden gegevens opgeslagen als u activa uploadt naar uw Open edX-installatie. Deze uploads zijn de zogenaamde "contentstore" en zijn in feite een door MongoDB ondersteunde GridFS-instantie. Open edX gebruikt MongoDB GridFS om bestandsgegevens op te slaan in chunks binnen een MongoDB-instantie en kan bestanden groter dan 16 MB opslaan. Het kan ook delen van grote bestanden bedienen in plaats van het hele bestand.

Een item kan worden geüpload als "vergrendeld" of "ontgrendeld". Een vergrendeld item is alleen beschikbaar voor studenten die een bepaalde cursus volgen - het edx-platform controleert de rol van de gebruiker voordat het het bestand aanbiedt. Ontgrendelde activa worden op verzoek aan elke gebruiker aangeboden. Wanneer een student in een cursus een asset aanvraagt, wordt de volledige asset geleverd vanuit GridFS.

Een hoge beschikbaarheid instellen voor uw Open edX MongoDB-database

Laten we toegeven dat het installeren of instellen van uw Open edX-platform een grote uitdaging is. Het is moeilijk, vooral als je nieuw bent met dit platform of deze software, maar het heeft een zeer goed architectonisch ontwerp. Het is echter mogelijk dat uw installatie met uw MongoDB een replicaset-standaard met één knooppunt is als primaire. Aan de andere kant is het het beste dat uw replicaset ten minste een secundaire of meerdere secundaire knooppunten moet hebben naast de primaire. Dit dient uw instelling voor hoge Beschik baarheid in het geval dat uw primaire kapot gaat, uw secundaire replicaknooppunt de primaire rol overneemt.

Een replicaset instellen met secundaire replica's

Als je dit doet, hoef je alleen maar ten minste twee secundaire replica's toe te voegen en in te stellen. Het ideaal is dat u in een replicaset tenminste 3 knooppunten hebt waarvan één uw primaire is, en de andere twee knooppunten uw secundaire knooppunten die repliceren naar de primaire. Hierdoor kan de MongoDB Replica-set doorgaan met een verkiezing in het geval dat de primaire verbinding met zijn secundairen wordt verbroken. Dit geeft u betrouwbaarheid, redundantie en natuurlijk een hoge beschikbaarheid. Het is een eenvoudige setup die u kunt hebben om een hoge beschikbare omgeving te bereiken met MongoDB.

Waarom biedt dit een hoge beschikbaarheid? Een replicaset in MongoDB is een groep mongod-processen die dezelfde dataset onderhouden. MongoDB Replica-sets gebruiken verkiezingen om te bepalen welk setlid primair wordt voor het geval dat de primaire uitvalt of abnormaal wordt beëindigd of een aantal configuratiewijzigingen. Replica-sets kunnen een verkiezing activeren als reactie op verschillende gebeurtenissen, zoals:

Een nieuw knooppunt toevoegen aan de replicaset,
het starten van een replicaset,
het uitvoeren van onderhoud aan de replicaset met methoden zoals rs.stepDown() of rs.reconfig(), en
de secundaire leden verliezen de verbinding met de primaire gedurende meer dan de geconfigureerde time-out (standaard 10 seconden).

Neem dit voorbeelddiagram dat visualiseert hoe de verkiezingen werken.

Afbeelding met dank aan MongoDB-documentatie

Bovendien kunt u de andere secundaire replica's gebruiken als uw leesvoorkeur, maar dit hangt af van de instelling op basis van de verbinding van uw klant. U kunt meer leren door de leesvoorkeursopties voor verbinding te lezen of door de Leesvoorkeur hier te bekijken.

Dit ziet er goed uit, maar het omgaan met het eindpunt van uw toepassingsclient, zoals het wijzigen van de hostnaam of het IP-adres, vereist een handmatige wijziging. Het is niet ideaal als je een load balancer bovenop je Replica Set hebt, net als HaProxy, aangezien MongoDB Replica Set de verkiezing intern van MongoDB uitvoert.

Een Sharded Cluster instellen

Sharded cluster is ideaal als je te maken hebt met grote hoeveelheden datasets. Hoewel het niet betekent dat je een sharded cluster moet ontwerpen, moet het te maken hebben met grote datasets. MongoDB biedt mongos, een hulpprogramma dat zal fungeren als een routeringsservice voor MongoDB-shardconfiguraties die query's van de applicatielaag verwerkt en vervolgens de locatie van deze gegevens bepaalt in het shard-cluster dat wordt geïdentificeerd via de shard-sleutel om de transacties of database te voltooien activiteiten. Denk er eigenlijk aan dat mongos-instanties zich identiek gedragen als elke andere MongoDB-instantie.

Dus waarom een mongos voor je sollicitatie? In tijden dat uw Replica set Primary hostname of IP verandert na de verkiezing, betekent dit vanuit applicatieperspectief dat u ook het endpoint moet wijzigen. Bij mongos hoeft u uw applicatieclient gewoon naar een van onze mongos-instanties te verwijzen. Uw toepassingsclient heeft alleen een interface met de mongos-instantie en dat is alles wat er toe doet. De mongo's zullen degene zijn die uw vraagverzoeken of transacties afhandelt met behulp van het doel en de functie voor uw MongoDB Shard-configuratie. Dat betekent dat er in uw Open edx-configuratiebestanden geen wijzigingen hoeven te worden aangebracht. U hoeft uw applicatieservers niet opnieuw op te starten om de wijzigingen van uw MongoDB Replica Sets bij te houden.

Hoge beschikbaarheid instellen

Bijvoorbeeld met ClusterControl. Het gebruik van ClusterControl kan eenvoudig en efficiënt worden gedaan, omdat dit via de gebruikersinterface kan worden gedaan, waardoor handmatige configuraties en installaties voor een zeer complexe installatie worden vermeden.

Laten we aannemen dat u een bestaande MongoDB-instantie met Open edX-database heeft,

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

}

U kunt dit eenvoudig als een bestaande database naar ClusterControl importeren en een back-up maken met de back-upfunctie van ClusterControl. U kunt ook mongodump gebruiken of de Percona Backup voor MongoDB proberen.

Maak nu in ClusterControl een MongoDB Shard als nieuwe implementatie. Dit kan worden gedaan door de volgende stappen:

Implementeer een nieuwe MongoDB Shard in het dialoogvenster van de implementatiewizard.

Stel de SSH-instellingen en de bijbehorende configuratieservers en routers in. Dit is waar uw mongos-instanties zich naast uw configuratieservers bevinden.

Definieer je scherven. Dit zijn je replicaset-scherven. Afhankelijk van uw behoefte. In deze implementatie heb ik bijvoorbeeld twee shards geïmplementeerd, maar je kunt in het begin maar één shard gebruiken, vooral voor kleine implementaties.

Definieer uw database-instellingen

Klik op dit punt druk op de knop Implementeren en wacht tot de taak wordt verwerkt door ClusterControl.

Als je klaar bent, kun je nu de back-up herstellen die je van mongodump hebt gemaakt. Ik heb bijvoorbeeld een back-up gemaakt met ClusterControl en deze vervolgens gebruikt als mijn bronback-up. Wanneer u de mongorestore-opdracht gebruikt, moet u ervoor zorgen dat uw bestemmingshost een van uw mongos-instanties is. Voor deze voorbeeldimplementatie heb ik host 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'

…

……

Nu bent u klaar en brengt u enkele wijzigingen aan in uw Open edX-configuratiebestanden . In mijn installatieconfiguratie kun je de /edx/etc/studio.yml en /edx/etc/lms.yml updaten. Mogelijk moet u ook de bestanden in de bestanden /edx/app/edxapp/lms.auth.json en /edx/app/edxapp/cms.auth.json wijzigen en deze vervangen door de juiste hostnaam van uw mongos-instantie.
Controleer in uw mongo's en controleer of de databases zijn geladen en toegankelijk zijn,

[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

Nu ben je klaar!!!

In de webweergave ook van ClusterControl, zodra de ClusterControl de implementatie voltooit, heeft u een topologie die er als volgt uit zal zien,

Als u klaar bent, kunt u uw Open edX beheren en beheren uw cursussen!