Chamilo is, net als Open edX of Moodle, een platform waarmee onderwijsinstellingen hun onderwijsactiviteiten op internet kunnen zetten. Aangezien het grootste deel van de educatieve activiteiten het afgelopen jaar online zijn gegaan, is het niet verwonderlijk dat we steeds meer mensen zien worstelen om hun educatieve platforms uit te breiden en een betere beschikbaarheid te garanderen.
Chamilo is een platform gebouwd op de *AMP-stack, die bestaat uit Apache, MySQL en PHP. Zoals gewoonlijk is de database het moeilijkste element om te migreren naar een omgeving met hoge beschikbaarheid. In deze korte blog willen we het hebben over hoe je de hoge beschikbaarheid van de Chamilo-database kunt verbeteren.
Zoals je je kunt voorstellen, is de enkele MySQL-database een single point of failure en als zodanig moet deze worden vermeden in de productie-implementaties. Gelukkig zijn er een aantal manieren waarop u de beschikbaarheid van de MySQL-database kunt verbeteren.
Een van de manieren waarop u het probleem kunt aanpakken, is door een Galera-cluster te gebruiken. De minimale implementatie moet uit drie knooppunten bestaan - dergelijke clusters kunnen het falen van een enkel knooppunt automatisch afhandelen. De overige twee knooppunten blijven werken en reageren op vragen van de toepassing.
Voor deze opstelling is een soort van load balancer nodig voor het Galera-cluster. Het zou zijn taak zijn om het verkeer af te handelen en het om te leiden naar een goede 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 Chamilo-platform.
MariaDB-cluster implementeren
Deze keer proberen we MariaDB Cluster als onze backend te gebruiken. Chamilo ondersteunt MySQL 5.6 en nieuwer of MariaDB 5.5 en recenter. Als eerste stap moeten we "Deploy" uit de wizard kiezen:
Zodra we dat hebben gedaan, moeten we SSH-connectiviteit, wachtwoordloos, definiëren -gebaseerde SSH-toegang is een vereiste voor ClusterControl, anders kan het de database-infrastructuur niet beheren:het vertrouwt op SSH-connectiviteit om opdrachten uit te voeren om services te starten of te stoppen, software te installeren enzovoort.
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
Zoals we eerder vermeldden, is de database zelf niet het enige element dat we willen implementeren. We zouden een load balancer kunnen gebruiken die we zullen gebruiken om het verkeer te verplaatsen als een van de knooppunten zou falen. We zullen het ook gebruiken om een lees-/schrijfsplitsing te bieden, waarbij alle schrijfbewerkingen naar een enkele MariaDB Galera-node worden geleid en de leesbewerkingen worden gesplitst over de resterende MariaDB Galera-nodes. Dit zal ons helpen conflicten te voorkomen tussen schrijfbewerkingen 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
De ProxySQL zal geweldig werken bij het verdelen van ons verkeer over de clusterknooppunten. Aan de andere kant zal een enkel ProxySQL-knooppunt fungeren als een enkel storingspunt. Daarom willen we er minimaal twee inzetten. Vervolgens is de vraag hoe het falen van ProxySQL-knooppunt kan worden gedetecteerd en hoe het verkeer naar een gezonde ProxySQL kan worden verplaatst. Hier komt Keepalive. 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, zodat de applicatie altijd een gezonde ProxySQL bereikt, wat er op zijn beurt voor zorgt dat het verkeer het gezonde clusterknooppunt bereikt.
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 als het gaat om de omgeving die we aan het bouwen waren. U kunt uw Chamilo naar de VIP en poort 6033 richten, dit zou voldoende moeten zijn om de connectiviteit met uw backend-database te krijgen. Als u problemen tegenkomt met betrekking tot verouderde leesbewerkingen (wanneer schrijven één knooppunt raakt en Chamilo probeert te lezen van een ander knooppunt, kunt u onderzoeken of causaliteitscontroles op het Galera-cluster mogelijk zijn). Er is een wsrep_sync_wait-variabele die tests op verschillende toegangen kan inschakelen patronen:reads, updates, inserts, deletes, Replaces en SHOW-commando's. Als we alleen geïnteresseerd zijn in de SELECT-query's, zullen we deze variabele op '1' zetten 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 Chamilo wilt delen, kun je een reactie achterlaten.