Open edX is een platform voor online educatieve activiteiten. Gezien de situatie waarin de wereld zich bevindt, worden al dergelijke platforms zwaarder belast en is hun belang aanzienlijk toegenomen. Dit zijn niet alleen de "helper"-platforms, maar ze worden vaak de belangrijkste manier waarop educatieve activiteiten worden uitgevoerd. Dit leidt tot hogere eisen met betrekking tot de belasting die ze aankunnen of de beschikbaarheid van het platform.
Open edX is een complex product dat uit meerdere elementen bestaat. Een daarvan is de MySQL-database. In deze korte blog willen we bespreken hoe u de hoge beschikbaarheid van het Open edX-platform kunt verbeteren.
Het is duidelijk dat de enkele MySQL-database een single point of failure is en als zodanig niet geschikt is voor productie-implementaties. Er zijn verschillende manieren waarop u de beschikbaarheid van de MySQL-database kunt verbeteren.
Om te beginnen kun je de master - slave setup uitvoeren met asynchrone of semi-synchrone replicatie. Het voordeel hiervan is dat u, wanneer de master niet beschikbaar is, een van de slaven kunt promoveren en doorgaan met de bewerking. Het belangrijkste nadeel van zo'n setup is dat de failover handmatig moet worden uitgevoerd, wat de downtime verhoogt, of dat je externe software moet gebruiken (bijvoorbeeld ClusterControl), maar het kan nog steeds even duren. Ten slotte is elke vorm van asynchrone of semi-synchrone replicatie onderhevig aan replicatievertraging. Dit kan ernstige gevolgen hebben voor de read-after-write-scenario's waarin de toepassing een schrijfactie op de master uitvoert en vervolgens onmiddellijk probeert die gegevens van de slave te lezen.
Een andere benadering zou zijn om een Galera-cluster te gebruiken om de gegevens van het Open edX-platform op te slaan. We kunnen beginnen met drie knooppuntclusters - dergelijke clusters kunnen het falen van een enkel knooppunt automatisch afhandelen. De overige twee knooppunten blijven werken en reageren op vragen van de toepassing. Een ander voordeel van Galera is dat, hoewel het "vrijwel" synchroon is (wat vrijwel betekent dat het bijna synchroon is), er een manier is om causaliteitscontroles af te dwingen en clusters in de synchrone modus te dwingen (zelfs als je ervoor betaalt met verminderde prestaties).
Voor beide scenario's is een soort load balancer nodig, die het verkeer afhandelt en omleidt naar een juiste bestemming.
Laten we eens kijken hoe ClusterControl u kan helpen bij het implementeren van een Galera-cluster met een set load balancers die u kunt gebruiken voor uw Open edX-platform.
MariaDB-cluster implementeren
Deze keer proberen we MariaDB Cluster als onze backend te gebruiken. Nogmaals, de eerste stap is hetzelfde, we moeten "Deploy" kiezen uit de wizard:
Zodra je dat doet, moeten we SSH-connectiviteit, wachtwoordloos, definiëren -gebaseerde SSH-toegang is een vereiste voor ClusterControl, anders kan het de database-infrastructuur niet beheren.
Dan moeten we beslissen over de leverancier, versie, wachtwoord, hosts en wat aanvullende instellingen:
Nu al deze details zijn ingevuld, kunnen we doorgaan met de implementatie.
ProxySQL implementeren
Database zelf is niet het enige element dat we willen implementeren. We hebben ook een load balancer nodig die we zullen gebruiken om het verkeer naar de knooppunten te leiden die op het gegeven moment beschikbaar zijn. We zullen het ook gebruiken om een lees-/schrijfsplitsing te bieden, waarbij alle schrijfbewerkingen naar een enkele MariaDB Galera-node worden geleid. Dit zal ons helpen conflicten te vermijden tussen schrijfacties die op verschillende Galera-knooppunten worden uitgevoerd.
Voor ProxySQL ClusterControl moet ook wat informatie worden ingevuld - u moet de host om het op te installeren, beslis over de ProxySQL-versie, referenties voor de beheerders en bewakingsgebruikers. Die gebruikers zullen worden gebruikt om ProxySQL te beheren en de status van uw Galera-cluster te bewaken. U moet ook bestaande databasegebruikers importeren of een nieuwe aanmaken voor uw toepassing. Ten slotte is het aan jou om te beslissen welke databaseknooppunten je wilt gebruiken met ProxySQL en om te beslissen of je impliciete transacties gebruikt.
Keepalived inzetten
Als volgende stap zullen we Keepalive inzetten. Het idee hier is om een virtueel IP-adres te hebben dat verwijst naar de werkende ProxySQL-instantie. Zo'n VIP kan dan in de applicatie worden gebruikt als het eindpunt voor de MySQL-databaseconnectiviteit.
Na het doorgeven van details zoals ProxySQL-instanties die moeten worden gecontroleerd, Virtual IP en de interface VIP zou moeten binden aan we zijn klaar om te implementeren. Na een paar minuten zou alles klaar moeten zijn en zou de topologie er als volgt uit moeten zien:
Dat is het zowat als het gaat om de implementatie. U kunt uw Open edX-platform naar de VIP en poort 6033 richten, dit zou voldoende moeten zijn om de connectiviteit met uw backend-database te krijgen. Het laatste resterende deel, mocht je het nodig vinden, zou zijn om causaliteitscontroles te configureren. Er is een wsrep_sync_wait variabele die precies dat kan. Het kan tests op verschillende toegangspatronen mogelijk maken:leest, updates, invoegingen, verwijderingen, vervangingen en SHOW-commando's. Als we alleen geïnteresseerd zijn in de SELECT-query's, stellen we deze variabele in op '1' met behulp van ClusterControl-configuratiebeheer.
Hiermee wordt deze wijziging uitgevoerd op alle MariaDB-clusterknooppunten.
Dat is het zo'n beetje. Als je wat van je ervaringen met Open edX wilt delen, kun je een reactie achterlaten.