Ansigt til ansigt-møder er i dag begrænset til det absolutte minimum, onlineaktiviteter har taget over som den vigtigste måde for lærer-elev-interaktion. Det øgede stresset på de eksisterende online "møde" platforme (er der nogen, der ikke ved, hvad Zoom er i dag?), men også på online læringsplatforme. Den høje tilgængelighed af onlineværktøjerne er vigtigere end nogensinde, og driftsteamene skynder sig at bygge holdbare, yderst tilgængelige arkitekturer til deres miljøer.
Sandsynligvis har i det mindste nogle af jer brugt Moodle - det er en selvstændig online læringsplatform, som du kan implementere på stedet og bruge den til at levere online træning til din organisation. Som vi nævnte, er det lige så vigtigt som nogensinde at få det til at fungere på en holdbar, meget tilgængelig måde. Vi vil gerne foreslå en meget tilgængelig løsning, der involverer MariaDB som en backend-database - både asynkron replikering og Galera Cluster.
Miljødesignproces
Vi vil gerne starte med en proces, hvor vi vil forklare tankeprocessen bag design af miljøet til Moodle. Vi ønsker høj tilgængelighed, derfor fungerer en enkelt databaseknude ikke for os. Vi vil have flere noder, og det fører os til den første designbeslutning. Skal vi bruge asynkron replikering eller Galera Cluster? Det andet spørgsmål er:hvordan vil vi fordele arbejdsbyrden på tværs af noderne? Lad os starte med den anden.
Den seneste Moodle-version på det tidspunkt, hvor denne blog er blevet skrevet (3.9), introducerede en fin funktion kaldet sikker læsning. Opgaven, der skal løses her, er læst efter skrivning. Når du bruger én node, er verden et enkelt sted. Du skriver og så læser du. Uanset hvad du skrev er der allerede. Når du tilføjer noder, ændres tingene dog. I asynkron replikering kan slaver halte bagud selv i titusvis af sekunder eller mere. Uanset hvad du skriver på masteren, kan det tage endda minutter (hvis ikke mere i de mere ekstreme tilfælde) at blive anvendt på slaven. Hvis du udfører en skrivning og derefter straks forsøger at læse de samme data fra en af slaverne, kan du komme til en grim overraskelse - data vil ikke være der. Galera-klyngen bruger en "stort set" synkron replikering og i dette særlige tilfælde gør "virtuelt" en kæmpe forskel - Galera er ikke immun over for læs-efter-skriv-problemer. Der er altid forsinkelse mellem skriveudførelse på den lokale node og skrivesæt, der anvendes på de resterende noder i klyngen. Sikker på, det er højst sandsynligt målt i millisekunder snarere end sekunder, men det kan stadig bryde antagelsen om, at du straks kan læse, hvad du skrev. Det eneste sted, hvor du sikkert kan læse efter at have skrevet, er den node, hvor du skrev dataene.
Da Moodle er afhængig af læsning-efter-skriving ret meget, kan vi ikke let skalere læsninger kun ved at tilføje flere noder at læse fra. For Galera Cluster kunne vi forsøge at afhjælpe problemet ved at bruge wsrep-sync-wait-konfigurationsindstillingen for at tvinge Galera til at sikre, at læsningerne er sikre at udføre. Dette skaber ydeevnepåvirkningen på systemet, da alle læsninger skal vente på, at skrivninger bliver anvendt, før de kan udføres. Dette er også en løsning til MariaDB Cluster (og andre Galera-baserede løsninger), ikke til asynkron replikering. Heldigvis løser løsningen fra Moodle dette problem. Du kan definere en liste over noder, der muligvis halter, og Moodle vil kun bruge dem til læsninger, der ikke kræver at være opdateret med skrivningerne. Alle resterende læsninger, der kræver, at data altid er opdateret, vil blive dirigeret til forfatterknudepunktet. Så Moodles skalerbarhed er på en måde begrænset, da kun de "sikre" læsninger kan skaleres ud. Vi vil helt sikkert bruge 3.9's funktion, da dette er den eneste sikre metode til at bestemme, hvilket udvalg der skal gå hvor. Da alt er skrevet i en Moodles konfigurationsfil, ville vi højst sandsynligt ønske at bruge en load balancer, helst ProxySQL, til at skabe logik, der ville håndtere vores læsedistribution.
Skal vi bruge MariaDB Cluster eller asynkron replikering? Vi vil faktisk vise dig, hvordan du bruger begge dele. I begge tilfælde vil konfigurationen for Moodle være stort set den samme. I begge tilfælde vil vi bruge ProxySQL som loadbalancer. Den største forskel mellem disse løsninger er failover. MariaDB Cluster er meget nemmere at håndtere - hvis en node er nede, vil ProxySQL blot flytte skrivetrafikken til en af de resterende noder. Med asynkron replikering er tingene dog lidt anderledes. Hvis masteren går ned, skal failover ske. Dette sker ikke automatisk, du skal enten udføre det i hånden, eller du kan stole på noget software til at opnå det. I vores tilfælde vil vi bruge ClusterControl til at styre miljøet og udføre failover, derfor er der fra brugerens synspunkt ikke meget forskel mellem asynkron replikering og MariaDB Cluster - i begge tilfælde vil skrivefejl blive håndteret automatisk, og klyngen vil automatisk genoprette .
Det, vi har etableret, er, at vi vil fremvise både asynkron og praktisk talt synkron replikering. Vi vil bruge funktionen til sikker skrivning fra Moodle 3.9, og vi vil bruge ProxySQL som loadbalancer. For at sikre høj tilgængelighed har vi brug for mere end én ProxySQL-instans, derfor vil vi gå med to af dem, og for at oprette et enkelt indgangspunkt i databaselaget vil vi bruge Keepalved til at oprette en virtuel IP og pege den til en af de tilgængelige ProxySQL noder. Sådan kan vores databaseklynge se ud:
For asynkron replikering kunne dette se sådan ud:
Implementering af en meget tilgængelig databasebackend til Moodle ved hjælp af MariaDB-replikering
Lad os starte med MariaDB-replikeringen. Vi kommer til at bruge ClusterControl til at implementere hele databasens backend inklusive belastningsbalancere.
Implementering af MariaDB-replikeringsklynge
I første omgang skal vi vælge "Deploy" fra guiden:
Så bør vi definere SSH-forbindelse, adgangskodeløs, nøglebaseret SSH-adgang er et krav til ClusterControl til at administrere databaseinfrastruktur.
Når du udfylder disse oplysninger, er det tid til at vælge en leverandør og en version , definere superbrugerens adgangskode og beslutte nogle andre detaljer.
Vi skal nu bruge MariaDB 10.4. Som et næste trin skal vi definere replikationstopologien:
Vi bør videregive nodernes værtsnavne, og hvordan de skal forholde sig til hver Andet. Når vi er tilfredse med topologien, kan vi implementere. Til formålet med denne blog vil vi bruge master og to slaver som vores backend.
Vi har vores første klynge klar. Lad os nu implementere ProxySQL og Keepalived.
Implementering af ProxySQL
For ProxySQL er det nødvendigt at udfylde nogle detaljer - vælg værten, der skal installeres det på, beslut dig for ProxySQL-version, legitimationsoplysninger til de administrative og overvågningsbrugere. Du bør også importere eksisterende databasebrugere eller oprette en ny til din applikation. Til sidst skal du beslutte, hvilke databasenoder du vil bruge med ProxySQL, og beslutte om du bruger implicitte transaktioner. I tilfældet med Moodle er dette ikke sandt.
Implementering af Keepalived
Som næste trin vil vi implementere Keepalived.
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:
Konfigurer Moodle og ProxySQL til Safe Writes Scale-Out
Det sidste trin vil være at konfigurere Moodle og ProxySQL til at bruge sikker skrivning. Selvom det er muligt at hardkode databasenoder i Moodle-konfigurationen, ville det være meget bedre at stole på ProxySQL til at håndtere topologiændringerne. Det vi kan gøre er at oprette en ekstra bruger i databasen. Denne bruger vil blive konfigureret i Moodle til at udføre sikre læsninger. ProxySQL vil blive konfigureret til at sende al trafik udført fra denne bruger til de tilgængelige slaveknuder.
Lad os først oprette en bruger, som vi vil bruge til skrivebeskyttet adgang.
Vi giver alle privilegier her, men det burde være muligt at begrænse denne liste .
Brugeren, som vi lige har oprettet, skal tilføjes til begge ProxySQL-instanser, som vi har i klyngen, for at tillade ProxySQL at godkende som denne bruger. I ClusterControl UI kan du bruge handlingen "Importér bruger".
Vi kan søge efter den bruger, vi lige har oprettet:
ProxySQL bruger et koncept med værtsgrupper - grupper af værter, der tjener samme formål . I vores standardkonfiguration er der to værtsgrupper - værtsgruppe 10 som altid peger på nuværende master og værtsgruppe 20 som peger mod slaveknudepunkter. Vi ønsker, at denne bruger sender trafikken til slaveknudepunkter, derfor vil vi tildele HG 20 som standard.
Det er det, brugeren vil blive vist på listen over brugere:
Nu bør vi gentage den samme proces på den anden ProxySQL-node eller bruge Muligheden "Synkroniser forekomster". På den ene eller den anden måde bør begge ProxySQL-noder have tilføjet moodle_safereads-brugeren.
Det sidste trin vil være at implementere Moodle. Vi vil ikke gennemgå hele processen her, men der er et problem, vi skal løse. ProxySQL præsenterer sig selv som 5.5.30, og Moodle klager over, at den er for gammel. Vi kan nemt redigere den til den version, vi ønsker:
Når dette er gjort, skal vi midlertidigt sende al trafik til mesteren. Dette kan opnås ved at slette alle forespørgselsreglerne i ProxySQL. 'Moodle'-brugeren har HG10 som standard værtsgruppe, hvilket betyder, at uden forespørgselsregler vil al trafik fra denne bruger blive dirigeret til masteren. Den anden, sikker læsning, bruger har standard værtsgruppe 20, som stort set er al den konfiguration, vi ønsker at have på plads.
Når dette er gjort, bør vi redigere Moodles konfigurationsfil og aktivere pengeskabet læser funktion:
<?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!Det, der skete her, er, at vi tilføjede den skrivebeskyttede forbindelse til ProxySQL, som vil bruge moodle_safereads-brugeren. Denne bruger vil altid pege på slaver. Dette afslutter vores opsætning af Moodle til MariaDB-replikering.
Implementering af en meget tilgængelig databasebackend til Moodle ved hjælp 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, bør vi definere SSH-forbindelse, uden adgangskode, nøgle- baseret SSH-adgang er et krav for ClusterControl til at administrere databaseinfrastruktur.
Så bør vi beslutte os for leverandør, version, adgangskodeværter og et par mere indstillinger:
Når vi har udfyldt alle detaljer, er vi gode til at implementere.
Vi kunne fortsætte her yderligere, men da alle yderligere trin grundlæggende er de samme som med MariaDB-replikering, vil vi bare bede dig om at rulle op og tjekke afsnittet "Deploying ProxySQL" og alt, hvad der følger efter det. Du skal implementere ProxySQL, Keepalived, omkonfigurere den, ændre Moodles konfigurationsfil, og det er stort set det. Vi håber, at denne blog vil hjælpe dig med at bygge meget tilgængelige miljøer til Moodle understøttet af MariaDB Cluster eller replikering.