Face-to-face ontmoetingen zijn tegenwoordig beperkt tot het absolute minimum, online activiteiten zijn de belangrijkste manier geworden voor interactie tussen leraar en leerling. Het verhoogde de stress op de bestaande online “vergader” platforms (is er iemand die tegenwoordig niet weet wat Zoom is?) maar ook op online leerplatforms. De hoge beschikbaarheid van de online tools is belangrijker dan ooit en de operationele teams haasten zich om duurzame, zeer beschikbare architecturen voor hun omgevingen te bouwen.
Hoogstwaarschijnlijk hebben sommigen van jullie Moodle gebruikt - het is een op zichzelf staand online leerplatform dat je ter plaatse kunt implementeren en gebruiken om online training voor je organisatie te geven. Zoals we al zeiden, is het net zo belangrijk als altijd om het op een duurzame, zeer beschikbare manier te laten werken. We willen graag een zeer beschikbare oplossing voorstellen waarbij MariaDB als backend-database wordt gebruikt - zowel asynchrone replicatie als Galera Cluster.
Omgevingsontwerpproces
We willen graag beginnen met een proces waarin we het denkproces achter het ontwerpen van de omgeving voor Moodle zouden uitleggen. We willen hoge beschikbaarheid, daarom werkt een enkel databaseknooppunt niet voor ons. We willen meerdere knooppunten en dit leidt ons naar de eerste ontwerpbeslissing. Moeten we asynchrone replicatie of Galera Cluster gebruiken? De tweede vraag is:hoe gaan we de workload verdelen over de nodes? Laten we beginnen met de tweede.
De nieuwste Moodle-versie op het moment dat deze blog werd geschreven (3.9) introduceerde een leuke functie genaamd veilig lezen. Het probleem dat hier moet worden opgelost, is lezen na schrijven. Wanneer u één knooppunt gebruikt, is de wereld een eenvoudige plaats. Je schrijft en dan lees je. Wat je ook schrijft, het is er al. Wanneer u echter knooppunten toevoegt, veranderen de dingen. Bij asynchrone replicatie kunnen slaves zelfs tientallen seconden of meer achterblijven. Wat u ook op de master schrijft, het kan zelfs minuten duren (zo niet meer in de meer extreme gevallen) om op de slave te worden toegepast. Als u een schrijfbewerking uitvoert en vervolgens onmiddellijk dezelfde gegevens van een van de slaven probeert te lezen, kunt u voor een onaangename verrassing komen te staan - de gegevens zullen er niet zijn. Galera-cluster gebruikt een "virtueel" synchrone replicatie en in dit specifieke geval maakt "virtueel" een enorm verschil - Galera is niet immuun voor de lees-na-schrijfproblemen. Er is altijd vertraging tussen de uitvoering van het schrijven op het lokale knooppunt en de schrijfset die wordt toegepast op de resterende knooppunten van het cluster. Natuurlijk wordt het hoogstwaarschijnlijk gemeten in milliseconden in plaats van seconden, maar het kan nog steeds de veronderstelling doorbreken dat je onmiddellijk kunt lezen wat je hebt geschreven. De enige plaats waar u veilig kunt lezen na het schrijven, is het knooppunt waarop u de gegevens hebt geschreven.
Omdat Moodle veel afhankelijk is van lezen-na-schrijven, kunnen we reads niet eenvoudig schalen door meer nodes toe te voegen om van te lezen. Voor Galera Cluster zouden we kunnen proberen het probleem te verhelpen door de configuratie-instelling wsrep-sync-wait te gebruiken om Galera te dwingen ervoor te zorgen dat de reads veilig kunnen worden uitgevoerd. Dit zorgt voor de prestatie-impact op het systeem, omdat alle leesbewerkingen moeten wachten tot schrijfbewerkingen zijn toegepast voordat ze kunnen worden uitgevoerd. Dit is ook een oplossing voor MariaDB Cluster (en andere op Galera gebaseerde oplossingen), niet voor asynchrone replicatie. Gelukkig lost de oplossing van Moodle dit probleem op. U kunt een lijst met knooppunten definiëren die mogelijk achterblijven en Moodle zal ze alleen gebruiken voor leesbewerkingen die niet up-to-date hoeven te zijn met de schrijfbewerkingen. Alle resterende leesbewerkingen waarvoor gegevens altijd up-to-date moeten zijn, worden naar het schrijversknooppunt geleid. De schaalbaarheid van Moodle is dus een beetje beperkt omdat alleen de "veilige" uitlezingen kunnen worden uitgeschaald. We zullen zeker de functie van 3.9 willen gebruiken, aangezien dit de enige veilige methode is om te bepalen welke selectie waar naartoe moet. Aangezien alles is geschreven in het configuratiebestand van Moodle, zouden we hoogstwaarschijnlijk een load balancer willen gebruiken, bij voorkeur ProxySQL, om logica te creëren die onze leesdistributie zou afhandelen.
Moeten we MariaDB Cluster of asynchrone replicatie gebruiken? We zullen u daadwerkelijk laten zien hoe u beide kunt gebruiken. In beide gevallen zal de configuratie voor de Moodle vrijwel hetzelfde zijn. In beide gevallen zullen we ProxySQL gebruiken als loadbalancer. Het belangrijkste verschil tussen deze oplossingen is de failover. MariaDB Cluster is veel gemakkelijker om mee om te gaan - als een knooppunt niet beschikbaar is, verplaatst ProxySQL het schrijfverkeer eenvoudig naar een van de resterende knooppunten. Bij asynchrone replicatie zijn de zaken echter iets anders. Als de master uitvalt, moet er een failover plaatsvinden. Dit gebeurt niet automatisch, u moet het ofwel met de hand uitvoeren of u kunt op software vertrouwen om dat te bereiken. In ons geval zullen we ClusterControl gebruiken om de omgeving te beheren en de failover uit te voeren, daarom is er vanuit het oogpunt van de gebruiker niet veel verschil tussen asynchrone replicatie en de MariaDB-cluster - in beide gevallen wordt schrijffout automatisch afgehandeld en wordt het cluster automatisch hersteld .
Wat we hebben vastgesteld, is dat we zowel asynchrone als vrijwel synchrone replicatie zullen demonstreren. We zullen de veilige schrijffunctie van Moodle 3.9 gebruiken en we zullen ProxySQL gebruiken als de loadbalancer. Om hoge beschikbaarheid te garanderen, hebben we meer dan één ProxySQL-instantie nodig, daarom zullen we er twee gebruiken en om een enkel toegangspunt in de databaselaag te creëren, zullen we Keepalived gebruiken om een virtueel IP-adres te maken en dit naar een van de beschikbare ProxySQL te verwijzen knooppunten. Zo kan ons databasecluster eruitzien:
Voor asynchrone replicatie kan dit er ongeveer zo uitzien:
Een zeer beschikbare database-backend voor Moodle implementeren met MariaDB-replicatie
Laten we beginnen met de MariaDB-replicatie. We gaan ClusterControl gebruiken om de hele database-backend te implementeren, inclusief load balancers.
MariaDB-replicatiecluster implementeren
Eerst moeten we "Deploy" kiezen in de wizard:
Dan moeten we SSH-connectiviteit definiëren, wachtwoordloze, op sleutels gebaseerde SSH-toegang is een vereiste voor ClusterControl om de database-infrastructuur te beheren.
Als je die gegevens hebt ingevuld, is het tijd om een leverancier en een versie te kiezen , definieer het wachtwoord van de superuser en bepaal enkele andere details.
We gaan voorlopig MariaDB 10.4 gebruiken. Als volgende stap moeten we de replicatietopologie definiëren:
We moeten de hostnamen van de knooppunten doorgeven en hoe ze zich tot elkaar moeten verhouden ander. Zodra we tevreden zijn met de topologie, kunnen we implementeren. Voor het doel van deze blog zullen we master en twee slaves gebruiken als onze backend.
We hebben ons eerste cluster in de lucht en klaar. Laten we nu ProxySQL en Keepalive inzetten.
ProxySQL implementeren
Voor ProxySQL is het vereist om enkele details in te vullen - kies de host om te installeren het aan, beslis over de ProxySQL-versie, inloggegevens voor de beheerders en bewakingsgebruikers. U moet ook bestaande databasegebruikers importeren of een nieuwe aanmaken voor uw toepassing. Bepaal ten slotte welke databaseknooppunten u met ProxySQL wilt gebruiken en beslis of u impliciete transacties gebruikt. In het geval van Moodle is dit niet waar.
Keepalived inzetten
Als volgende stap zullen we Keepalive inzetten.
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:
Moodle en ProxySQL configureren voor veilig uitschalen van schrijfbewerkingen
De laatste stap is het configureren van Moodle en ProxySQL om veilig schrijven te gebruiken. Hoewel het mogelijk is om databaseknooppunten in de Moodle-configuratie hard te coderen, zou het veel beter zijn om op ProxySQL te vertrouwen om de topologiewijzigingen af te handelen. Wat we kunnen doen, is een extra gebruiker in de database maken. Die gebruiker wordt in Moodle geconfigureerd om veilige leesbewerkingen uit te voeren. ProxySQL wordt geconfigureerd om al het verkeer dat door die gebruiker wordt uitgevoerd naar de beschikbare slave-knooppunten te sturen.
Laten we eerst een gebruiker maken die we gebruiken voor alleen-lezen toegang.
We verlenen hier alle privileges, maar het zou mogelijk moeten zijn om die lijst te beperken .
De gebruiker die we zojuist hebben gemaakt, moet worden toegevoegd aan beide ProxySQL-instanties die we in het cluster hebben, zodat ProxySQL zich als die gebruiker kan verifiëren. In de gebruikersinterface van ClusterControl kunt u de actie "Gebruiker importeren" gebruiken.
We kunnen zoeken naar de gebruiker die we zojuist hebben gemaakt:
ProxySQL gebruikt een concept van hostgroepen - groepen hosts die hetzelfde doel dienen . In onze standaardconfiguratie zijn er twee hostgroepen - hostgroep 10 die altijd naar de huidige master verwijst en hostgroep 20 die naar slave-knooppunten wijst. We willen dat deze gebruiker het verkeer naar slave-knooppunten stuurt, daarom zullen we HG 20 als standaard toewijzen.
Dat is het, de gebruiker wordt weergegeven in de lijst met gebruikers:
Nu moeten we hetzelfde proces herhalen op het andere ProxySQL-knooppunt of de "Instances synchroniseren" optie. Op de een of andere manier moeten beide ProxySQL-knooppunten de gebruiker moodle_safereads hebben toegevoegd.
De laatste stap is het implementeren van Moodle. We zullen hier niet het hele proces doornemen, maar er is één probleem dat we moeten aanpakken. ProxySQL presenteert zichzelf als 5.5.30 en Moodle klaagt dat het te oud is. We kunnen het gemakkelijk bewerken naar elke gewenste versie:
Zodra dit is gebeurd, moeten we tijdelijk al het verkeer naar de meester. Dit kan worden bereikt door alle queryregels in ProxySQL te verwijderen. De 'moodle'-gebruiker heeft HG10 als de standaard hostgroep, wat betekent dat zonder queryregels al het verkeer van die gebruiker naar de master wordt geleid. De tweede, veilig gelezen, gebruiker heeft de standaard hostgroep 20, wat vrijwel alle configuratie is die we willen hebben.
Zodra dit is gebeurd, moeten we het configuratiebestand van Moodle bewerken en de kluis inschakelen leest functie:
<?php // Moodle configuration file
unset($CFG);
global $CFG;
$CFG = new stdClass();
$CFG->dbtype = 'mysqli';
$CFG->dblibrary = 'native';
$CFG->dbhost = '192.168.1.111';
$CFG->dbname = 'moodle';
$CFG->dbuser = 'moodle';
$CFG->dbpass = 'pass';
$CFG->prefix = 'mdl_';
$CFG->dboptions = array (
'dbpersist' => 0,
'dbport' => 6033,
'dbsocket' => '',
'dbcollation' => 'utf8mb4_general_ci',
'readonly' => [
'instance' => [
'dbhost' => '192.168.1.111',
'dbport' => 6033,
'dbuser' => 'moodle_safereads',
'dbpass' => 'pass'
]
]
);
$CFG->wwwroot = 'http://192.168.1.200/moodle';
$CFG->dataroot = '/var/www/moodledata';
$CFG->admin = 'admin';
$CFG->directorypermissions = 0777;
require_once(__DIR__ . '/lib/setup.php');
// There is no php closing tag in this file,
// it is intentional because it prevents trailing whitespace problems!Wat hier is gebeurd, is dat we de alleen-lezen verbinding hebben toegevoegd aan ProxySQL die gebruikmaakt van moodle_safereads user. Deze gebruiker zal altijd naar slaves wijzen. Hiermee is onze opzet van Moodle voor MariaDB-replicatie afgerond.
Een zeer beschikbare database-backend voor Moodle implementeren met MariaDB-cluster
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 u dat doet, moeten we SSH-connectiviteit, wachtwoordloos, sleutel- gebaseerde SSH-toegang is een vereiste voor ClusterControl om de database-infrastructuur te beheren.
Dan moeten we beslissen over de leverancier, versie, wachtwoordhosts en meer instellingen:
Zodra we alle details hebben ingevuld, zijn we klaar om te implementeren.
We zouden hier verder kunnen gaan, maar aangezien alle verdere stappen in principe hetzelfde zijn als bij MariaDB-replicatie, willen we u vragen naar boven te scrollen en het gedeelte "ProxySQL implementeren" en alles wat erop volgt te controleren. Je moet ProxySQL, Keepalived implementeren, het opnieuw configureren, het configuratiebestand van Moodle wijzigen en dit is het zo'n beetje. We hopen dat deze blog je zal helpen bij het bouwen van omgevingen met hoge beschikbaarheid voor Moodle, ondersteund door MariaDB Cluster of replicatie.