Hur man distribuerar Open edX MongoDB-databasen för hög tillgänglighet

Open edX är en plattform som tillhandahåller den massivt skalbara inlärningstekniken bakom edX. Open edX-projektet är en webbaserad plattform för att skapa, leverera och analysera onlinekurser. Det är programvaran som driver edx.org och många andra webbsajter för utbildning.

Vi har tidigare bloggat om att distribuera en databas med hög tillgänglighet för MySQL på Open edX-plattformen. Som sagt tidigare är det en komplex plattform eftersom den täcker flera komponenter, och en del av denna enorma plattform täcks av flera tjänster:

e-handel:https://github.com/edx/ecommerce
Katalog:https://github.com/edx/course-discovery
LMS / Studio:https://github.com/edx/edx-platform
Inloggningsuppgifter:https://github.com/edx/credentials
Insikter:https://github.com/edx/edx-analytics-dashboard
Analytics API:https://github.com/edx/edx-analytics-data-api

I huvudsak är Open Edx perfekt för onlinekurser mitt i pandemi och onlineutbildning, vilket du kanske redan har provat och tagit, särskilt om du skaffar en produktcertifiering.

Kort arkitektonisk översikt

Hjälpen av Open edX-arkitekturen är edx-plattformen, som innehåller applikationer för lärandehantering och kursförfattande (LMS respektive Studio). Förutom sin edx-plattform, omfattar de tekniska tjänsterna som omfattar hela plattformen olika tekniker som täcker upp en hel komplex nivå av denna programvara. Se diagrammet nedan från edX Team-presentationen i december förra året.

Du har Snowflake, Amazon RDS, MongoDB, Amazon S3, Elasticsearch, Memcached , och Redis som de teknologier som förkroppsligar denna rika plattform. Ändå är det till och med svårt att installera och konfigurera Open edX men jag lyckades skapa en enkel utvecklingsmiljö för att förstå lite av den här plattformen.

Låt oss samtidigt fokusera på MongoDB som används för att lagra innehåll för forum, kursstruktur och kurstillgångar. Per-learnardata lagras i MySQL, så om du vill veta och ha hög tillgänglighet för din MySQL med Open edX, läs det här.

Lagra innehåll för MongoDB

MongoDB är den valda databasen av Open edX för att lagra stora filer som är textfiler, PDF-filer, ljud-/videoklipp, tarballs, etc. Om du är bekant med Open edX och har använt det speciellt som en författare för LMS eller Studio, data lagras om du laddar upp tillgångar till din Open edX-installation. Dessa uppladdningar är så kallade "contentstore" är i grunden en MongoDB-stödd GridFS-instans. Open edX använder MongoDB GridFS för att lagra fildata i bitar inom en MongoDB-instans och kan lagra filer som är större än 16 MB i storlek. Det kan också servera delar av stora filer istället för hela filen.

En tillgång kan laddas upp som "låst" eller "upplåst". En låst tillgång är endast tillgänglig för studenter som går en viss kurs - edx-plattformen kontrollerar användarens roll innan filen serveras. Olåsta tillgångar serveras till alla användare på begäran. När en student i en kurs begär en tillgång serveras hela tillgången från GridFS.

Ställa in en hög tillgänglighet för din Open edX MongoDB-databas

Låt oss erkänna att det är en stor utmaning att installera eller konfigurera din Open edX-plattform. Det är tufft, särskilt att du är ny på den här plattformen eller programvaran, men den har en mycket bra arkitektonisk design. Det är dock möjligt att din installation med din MongoDB är ett replica Set-stativ med en nod som primär. Å andra sidan är det bäst att ditt replikset måste ha minst en sekundär eller flera sekundära noder förutom den primära. Detta tjänar din högtillgänglighetsinställning om din primära går kaput, kommer din sekundära replikanod att ta över den primära rollen.

Konfigurera en replikuppsättning med sekundära repliker

Om du gör detta behöver du bara lägga till och ställa in minst två sekundära repliker. Idealet är att du åtminstone i en replikuppsättning har 3 noder varav en är din primära, sedan är de andra två noderna dina sekundära noder som replikerar till den primära. Detta gör att MongoDB Replica-uppsättningen kan fortsätta ett val i fall primära förlorar anslutningen med sina sekundärer. Detta ger dig tillförlitlighet, redundans och naturligtvis hög tillgänglighet. Det är en enkel installation som du kan behöva för att uppnå en hög tillgänglig miljö med MongoDB.

Varför ger detta hög tillgänglighet? En replikuppsättning i MongoDB är en grupp mongod-processer som upprätthåller samma datamängd. MongoDB Replica-uppsättningar använder val för att avgöra vilken uppsättningsmedlem som kommer att bli primär till händelsen att primära går ner eller avslutas onormalt eller vissa konfigurationsändringar. Replikuppsättningar kan utlösa ett val som svar på en mängd olika händelser, till exempel:

Lägga till en ny nod till replikuppsättningen,
initierar en replikuppsättning,
utför replikuppsättningsunderhåll med metoder som rs.stepDown() eller rs.reconfig() och
de sekundära medlemmarna förlorar anslutningen till den primära under mer än den konfigurerade timeouten (10 sekunder som standard).

Ta detta exempeldiagram som visualiserar hur valet fungerar.

Bild med tillstånd från MongoDB-dokumentation

Dessutom kan du använda de andra sekundära replikerna som dina läspreferenser men detta beror på inställningen baserat på din klients anslutning. Du kan lära dig mer genom att läsa läsinställningarna för anslutning eller kontrollera läsinställningarna här.

Nu ser det här bra ut men att hantera din applikationsklientslutpunkt som att ändra värdnamnet eller IP-adressen kräver en manuell ändring. Det är inte idealiskt om du har en lastbalanserare ovanpå din Replica Set precis som HaProxy eftersom MongoDB Replica Set utför valet internt i MongoDB.

Konfigurera ett delat kluster

Sharded kluster är idealiskt om du har att göra med en stor datamängd. Även om det inte betyder att du måste designa ett fragmenterat kluster, måste det handla om stora datamängder. MongoDB erbjuder mongos, som är ett verktyg som ska fungera som en routingtjänst för MongoDB-shard-konfigurationer som bearbetar frågor från applikationslagret och sedan bestämmer platsen för denna data i det shardade klustret som identifieras genom dess shardnyckel för att slutföra sina transaktioner eller databas operationer. Tänk i princip att mongos-instanser beter sig identiskt med vilken annan MongoDB-instans som helst.

Så varför ha en mongo framför din ansökan? När din replikuppsättning Primärt värdnamn eller IP ändras efter valet, ur applikationsperspektiv, betyder det att du också måste ändra slutpunkten. Med mongos, peka bara din applikationsklient till en av våra mongos-instanser. Din applikationsklient har bara gränssnitt med mongos-instansen och det är allt som spelar roll. Mongos kommer att vara den som hanterar dina frågeförfrågningar eller transaktioner med användning av dess syfte och funktion för din MongoDB Shard-installation. Det betyder att det inte finns några ändringar att göra i dina Open edx-konfigurationsfiler. Du behöver inte starta om dina applikationsservrar för att komma ikapp med ändringarna från dina MongoDB Replica Sets.

Hur man ställer in hög tillgänglighet

Till exempel använda ClusterControl. Att använda ClusterControl kan uppnås enkelt och effektivt eftersom detta kan göras över användargränssnittet och undviker dessa manuella konfigurationer och installationer för en mycket komplex installation.

Låt oss överväga att du har en befintlig MongoDB-instans med Open edX-databas,

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 helt enkelt importera detta som en befintlig databas till ClusterControl och ta en säkerhetskopia med ClusterControls säkerhetskopieringsfunktion. Alternativt kan du använda mongodump eller prova att använda Percona Backup för MongoDB.

Nu, i ClusterControl, skapa en MongoDB Shard som en ny distribution. Detta kan göras genom följande steg:

Distribuera en ny MongoDB Shard i dialogrutan för distributionsguiden.

Ställ in SSH-inställningarna och dess konfigurationsservrar och routrar. Det är här dina mongos-instanser ska finnas förutom dina konfigurationsservrar.

Definiera dina Shards. Dessa är dina replika-uppsättningar. Beroende på ditt behov. Till exempel, i den här implementeringen distribuerade jag två skärvor men du kan bara använda en skärva till att börja med, speciellt för små utplaceringar.

Definiera dina databasinställningar

Vid denna punkt, tryck distribuera-knappen och vänta bara medan jobbet bearbetas av ClusterControl.

När du är klar kan du nu återställa säkerhetskopian du har tagit från mongodump. Till exempel tog jag en säkerhetskopia med ClusterControl och använde sedan denna som min källbackup. När du använder mongorestore-kommandot, se till att din destinationsvärd är en av dina mongos-instanser. För den här exemplet har jag värd 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 är du redo och gör sedan några ändringar i dina Open edX-konfigurationsfiler . I min installationskonfiguration kan du uppdatera /edx/etc/studio.yml och /edx/etc/lms.yml. Du kanske också måste ändra filerna i filerna /edx/app/edxapp/lms.auth.json och /edx/app/edxapp/cms.auth.json och ersätta dem med rätt värdnamn för din mongos-instans.
Verifiera i dina mongos och kontrollera om databaserna är inlästa och kan vara tillgängliga,

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

I webbvyn även för ClusterControl, när ClusterControl har slutfört distributionen, kommer du att ha en topologi som ska se ut så här,

När du är klar är du redo att hantera din Open edX och hantera dina kurser!