Open edX er en platform for online undervisningsaktiviteter. I betragtning af den situation, verden er i, støder alle sådanne platforme på højere belastninger, og deres betydning er steget markant. Det er ikke kun "hjælper"-platformene, men de bliver ofte den vigtigste måde, hvorpå uddannelsesaktiviteter udføres. Dette fører til højere krav til den belastning, de kan håndtere eller tilgængeligheden af platformen.
Open edX er et komplekst produkt, der består af flere elementer. En af dem er MySQL-databasen. I denne korte blog vil vi gerne diskutere, hvordan du kan forbedre den høje tilgængelighed af Open edX-platformen.
Det er klart, at den enkelte MySQL-database er et enkelt fejlpunkt, og som sådan er det ikke en fremgangsmåde, der er egnet til produktionsinstallationer. Der er flere måder, hvorpå du kan forbedre tilgængeligheden af MySQL-databasen.
Til at begynde med kan du køre master - slave opsætningen ved at bruge asynkron eller semi-synkron replikering. Fordelen ved det er, at når masteren ikke er tilgængelig, kan du promovere en af slaverne og fortsætte med operationen. Den største ulempe ved sådan en opsætning er, at failover enten skal udføres manuelt, hvilket øger nedetiden, eller du skal bruge noget ekstern software (f.eks. ClusterControl), men det kan stadig tage lidt tid. Endelig er enhver form for asynkron eller semi-synkron replikation underlagt replikationsforsinkelse. Dette kan alvorligt påvirke de læs-efter-skriv-scenarier, hvor applikationen udfører en skrivning på masteren og derefter straks forsøger at læse disse data fra slaven.
En anden fremgangsmåde ville være at bruge en Galera Cluster til at gemme dataene fra Open edX-platformen. Vi kan starte med tre node-klynger – sådanne klynger kan automatisk håndtere svigt af en enkelt node. De resterende to noder vil fortsætte med at arbejde og reagere på forespørgsler, der kommer fra applikationen. En anden fordel ved Galera er, at selvom det er "stort set" synkront (hvilket stort set betyder, at det er næsten synkront), er der en måde at gennemtvinge kausalitetstjek og tvinge klynger ind i den synkrone tilstand (selvom du betaler for det med reduceret ydeevne).
Begge scenarier ville kræve en slags belastningsbalancer foran dem, som ville håndtere trafikken og omdirigere den til en korrekt destination.
Lad os se, hvordan ClusterControl kan hjælpe dig med at implementere en Galera Cluster med et sæt belastningsbalancere, som du kan bruge til din Open edX-platform.
Implementering af MariaDB Cluster
Denne gang vil vi prøve at bruge MariaDB Cluster som vores backend. Igen, det første trin er det samme, vi skal vælge "Deploy" fra guiden:
Når du har gjort det, skal vi definere SSH-forbindelse, uden adgangskode, nøgle -baseret SSH-adgang er et krav for ClusterControl, ellers vil den ikke være i stand til at administrere databaseinfrastruktur.
Så bør vi beslutte os for leverandør, version, adgangskode, værter og nogle yderligere indstillinger:
Med alle disse detaljer udfyldt er vi gode til at fortsætte med implementeringen.
Implementering af ProxySQL
Databasen i sig selv er ikke det eneste element, vi ønsker at implementere. Vi har også brug for en load balancer, som vi vil bruge til at dirigere trafikken til de noder, der er tilgængelige i det givne øjeblik. Vi vil også bruge det til at give læse/skrive-split og dirigere alle skrivningerne til en enkelt MariaDB Galera-node. Dette vil hjælpe os med at undgå konflikter mellem skrivninger udført på forskellige Galera-noder.
For ProxySQL ClusterControl kræver også at udfylde nogle oplysninger - du skal vælge vært for at installere det på, beslut dig for ProxySQL-version, legitimationsoplysninger til de administrative og overvågningsbrugere. Disse brugere vil blive brugt til at administrere ProxySQL og overvåge status for din Galera-klynge. Du bør også importere eksisterende databasebrugere eller oprette en ny til din applikation. Endelig er det op til dig at beslutte, hvilke databasenoder du vil bruge med ProxySQL og beslutte, om du bruger implicitte transaktioner.
Implementering af Keepalived
Som næste trin vil vi implementere Keepalived. Ideen her er at have en virtuel IP, der peger på den fungerende ProxySQL-instans. En sådan VIP kan derefter bruges i applikationen som slutpunktet for MySQL-databaseforbindelsen.
Efter videregivelse af detaljer som ProxySQL-forekomster, der skal overvåges, Virtual IP og interface VIP skal binde til, vi er klar til at implementere. Efter et par minutter skulle alt være klar, og topologien skulle se ud som nedenfor:
Det er stort set det, når det kommer til implementeringen. Du kan pege din Open edX-platform mod VIP og port 6033, dette burde være nok til at få forbindelsen til din backend-database. Den sidste resterende bit, hvis du finder det nødvendigt, ville være at konfigurere kausalitetstjek. Der er en wsrep_sync_wait-variabel, der kan gøre netop det. Det kan aktivere test på flere adgangsmønstre:læser, opdaterer, indsætter, sletter, erstatter og VIS kommandoer. Hvis vi kun er interesseret i SELECT-forespørgslerne, sætter vi denne variabel til '1' ved hjælp af ClusterControl-konfigurationsstyring.
Dette udfører denne ændring på alle MariaDB Cluster-noder.
Det er stort set det. Hvis du gerne vil dele noget af din oplevelse med Open edX, er du velkommen til at efterlade os en kommentar.