Sådan implementeres Open edX MongoDB-databasen for høj tilgængelighed

Open edX er en platform, der leverer den massivt skalerbare læringssoftwareteknologi bag edX. Open edX-projektet er en webbaseret platform til at skabe, levere og analysere onlinekurser. Det er softwaren, der driver edx.org og mange andre online undervisningssider.

Vi har tidligere blogget om implementering af en High Availability for MySQL-database på Open edX-platformen. Som tidligere nævnt er det en kompleks platform, da den dækker flere komponenter, og en del af denne enorme platform er dækket af flere tjenester:

eCommerce:https://github.com/edx/ecommerce
Katalog:https://github.com/edx/course-discovery
LMS / Studio:https://github.com/edx/edx-platform
Legitimationsoplysninger:https://github.com/edx/credentials
Indsigt:https://github.com/edx/edx-analytics-dashboard
Analytics API:https://github.com/edx/edx-analytics-data-api

I bund og grund er Open Edx perfekt til onlinekurser midt i pandemi og online træning, som du måske allerede har prøvet og taget, især hvis du er ved at erhverve en produktcertificering.

Kort arkitektonisk oversigt

Det centrale i Open edX-arkitekturen er edx-platformen, som indeholder læringsstyrings- og kursusforfatterapplikationerne (henholdsvis LMS og Studio). Udover sin edx-platform, omfatter de tekniske tjenester, der omfatter hele platformen, forskellige involverede teknologier, som dækker over et helt komplekst niveau af denne software. Se diagrammet nedenfor taget fra edX Team-præsentationen i december sidste år.

Du har Snowflake, Amazon RDS, MongoDB, Amazon S3, Elasticsearch, Memcached , og Redis som de teknologier, der inkorporerer denne rige platform. Alligevel er det endda svært at installere og konfigurere Open edX, men jeg formåede at oprette et simpelt udviklingsmiljø for at forstå lidt af denne platform.

Lad os dog fokusere på MongoDB, som bruges til at gemme indhold til fora, kursusstruktur og kursusaktiver. Per-learner data gemmes i MySQL, så hvis du vil vide og have høj tilgængelighed til din MySQL med Open edX, så læs det her.

Lagring af indhold til MongoDB

MongoDB er Open edX's foretrukne database til lagring af store filer, som er tekstfiler, PDF'er, lyd-/videoklip, tarballs osv. Hvis du er fortrolig med Open edX og har brugt det især som en forfatter til LMS eller Studio, lagres data, hvis du uploader aktiver til din Open edX-opsætning. Disse uploads er såkaldte "contentstore" er dybest set en MongoDB-støttet GridFS-instans. Open edX bruger MongoDB GridFS til at gemme fildata i bidder i en MongoDB-instans og er i stand til at gemme filer større end 16 MB i størrelse. Det kan også tjene dele af store filer i stedet for hele filen.

Et aktiv kan uploades som "låst" eller "ulåst". Et låst aktiv er kun tilgængeligt for studerende, der tager et bestemt kursus - edx-platformen tjekker brugerens rolle, før filen serveres. Ulåste aktiver serveres til enhver bruger efter anmodning. Når en studerende i et kursus anmoder om et aktiv, serveres hele aktivet fra GridFS.

Opsætning af en høj tilgængelighed for din Open edX MongoDB-database

Lad os indrømme, at installation eller opsætning af din Open edX-platform er en stor udfordring. Det er hårdt, især at du er ny på denne platform eller software, men den har et meget flot arkitektonisk design. Det er dog muligt, at din opsætning med din MongoDB er en en-node Replica Set stand som primær. På den anden side er det bedst, at dit replikasæt skal have mindst en sekundær eller flere sekundære noder bortset fra den primære. Dette tjener dit opsætning med høj tilgængelighed, hvis din primære går kaput, vil din sekundære replikaknude overtage den primære rolle.

Opsæt et replikasæt med sekundære replikaer

Hvis du gør dette, skal du blot tilføje og konfigurere mindst to sekundære replikaer. Det ideelle er, at du i det mindste i et replikasæt har 3 noder, hvor den ene er din primære, så er de to andre noder dine sekundære, der replikerer til den primære. Dette gør det muligt for MongoDB Replica-sættet at fortsætte et valg, hvis primære mister forbindelsen til sine sekundære. Dette giver dig pålidelighed, redundans og selvfølgelig høj tilgængelighed. Det er en simpel opsætning, som du kan have for at opnå et højt tilgængeligt miljø med MongoDB.

Hvorfor giver dette høj tilgængelighed? Et replikasæt i MongoDB er en gruppe mongod-processer, der vedligeholder det samme datasæt. MongoDB Replica-sæt bruger valg til at bestemme, hvilket sætmedlem, der bliver primært i tilfælde af, at det primære falder eller afsluttes unormalt eller nogle konfigurationsændringer. Replikasæt kan udløse et valg som svar på en række begivenheder, såsom:

Tilføjelse af en ny node til replikasættet,
initiering af et replikasæt,
udførelse af replikasætvedligeholdelse ved hjælp af metoder såsom rs.stepDown() eller rs.reconfig(), og
de sekundære medlemmer mister forbindelsen til det primære i mere end den konfigurerede timeout (10 sekunder som standard).

Tag dette eksempeldiagram, som visualiserer, hvordan valget fungerer.

Billede med tilladelse fra MongoDB-dokumentation

Desuden kan du bruge de andre sekundære replikaer som din læsepræference, men dette afhænger af opsætningen baseret på din klients forbindelse. Du kan få mere at vide ved at læse indstillingerne for læsepræferencer for tilslutning eller kontrollere læsepræferencen her.

Nu ser det godt ud, men det kræver en manuel ændring at håndtere dit applikationsklientslutpunkt, såsom at ændre værtsnavnet eller IP-adressen. Det er ikke ideelt, hvis du har en load balancer oven på dit Replica Set ligesom HaProxy, da MongoDB Replica Set udfører valget internt i MongoDB.

Opsæt en delt klynge

Sharded cluster er ideel, hvis du har at gøre med en stor størrelse af datasæt. Selvom det ikke betyder, at du skal designe en sharded cluster, skal det handle om store datasæt. MongoDB tilbyder mongos, som er et værktøj, der skal fungere som en routing-tjeneste for MongoDB shard-konfigurationer, der behandler forespørgsler fra applikationslaget og derefter bestemmer placeringen af disse data i den shardede klynge identificeret gennem dens shard-nøgle for at fuldføre dens transaktioner eller database operationer. Tænk i bund og grund bare, at mongo-forekomster opfører sig identisk med enhver anden MongoDB-instans.

Så hvorfor have en mongo foran din ansøgning? På tidspunkter, hvor dit replikasæt Primært værtsnavn eller IP ændres efter valget, betyder det fra applikationsperspektivet, at du også skal ændre slutpunktet. Med mongos skal du blot pege din applikationsklient til en af vores mongo-forekomster. Din applikationsklient har kun grænseflader med mongos-instansen, og det er alt, det betyder noget. Mongoerne vil være den, der håndterer dine forespørgselsanmodninger eller transaktioner ved at bruge dens formål og funktion til din MongoDB Shard-opsætning. Det betyder, at der ikke skal foretages nogen ændringer i dine Open edx-konfigurationsfiler. Du behøver ikke at genstarte dine applikationsservere for at indhente ændringerne fra dine MongoDB Replica Sets.

Sådan konfigurerer du høj tilgængelighed

For eksempel ved at bruge ClusterControl. Brug af ClusterControl kan opnås enkelt og effektivt, da dette kan gøres over brugergrænsefladen og undgå disse manuelle konfigurationer og installationer for en meget kompleks opsætning.

Lad os overveje, at du har en eksisterende MongoDB-instans med Open edX-database,

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

}

Du kan blot importere dette som en eksisterende database til ClusterControl og tage en sikkerhedskopi ved hjælp af ClusterControls sikkerhedskopieringsfunktion. Alternativt kan du bruge mongodump eller prøve at bruge Percona Backup til MongoDB.

Opret nu en MongoDB Shard i ClusterControl som en ny implementering. Dette kan gøres ved følgende trin:

Implementer en ny MongoDB Shard i dialogen med installationsguiden.

Opsæt SSH-indstillingerne og dens konfigurationsservere og routere. Det er her dine mongo-forekomster skal være bortset fra dine konfigurationsservere.

Definer dine Shards. Disse er dine replikasæt-skår. Afhængig af dit behov. For eksempel, i denne udrulning installerede jeg to shards, men du kan bare bruge et shard til at begynde med, især til små implementeringer.

Definer dine databaseindstillinger

På dette tidspunkt skal du trykke på udrul-knappen og bare vent, mens jobbet behandles af ClusterControl.

Når du er færdig, kan du nu gendanne den sikkerhedskopi du har taget fra mongodump. For eksempel tog jeg en sikkerhedskopi ved hjælp af ClusterControl og brugte derefter denne som min kildesikkerhedskopiering. Når du bruger mongorestore-kommandoen, skal du sørge for, at din destinationsvært er en af dine mongo-forekomster. Til dette eksempel har jeg 192.168.40.233 vært.

$ 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 er du klar og foretag nogle ændringer i dine Open edX-konfigurationsfiler . I min installationsopsætning kan du opdatere /edx/etc/studio.yml og /edx/etc/lms.yml. Du skal muligvis også ændre filerne i filerne /edx/app/edxapp/lms.auth.json og /edx/app/edxapp/cms.auth.json og erstatte dem med det korrekte værtsnavn for din mongos-instans.
Bekræft i dine mongoer og kontroller, om databaserne er indlæst og kan være tilgængelige,

[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 er du klar!!!

I webvisningen også af ClusterControl, når ClusterControl afslutter implementeringen, vil du have en topologi, der skal se sådan ud,

Når du er færdig, er du klar til at administrere din Open edX og administrere dine kurser!