Moodle er en meget populær platform til at afvikle onlinekurser. Med den situation, vi ser i 2020, udgør Moodle sammen med kommunikatører som Zoom rygraden i de tjenester, der tillader online læring og hjemmeundervisning. Efterspørgslen på Moodle-platforme steg markant sammenlignet med tidligere år. Der er bygget nye platforme, lagt ekstra belastning på de platforme, der historisk set kun har fungeret som et hjælpeværktøj og nu skal de drive hele uddannelsesindsatsen. Hvordan skalerer man Moodlen ud? Vi har en blog om dette emne. Hvordan skalerer man databasens backend til Moodle? Nå, det er en anden historie. Lad os tage et kig på det, da udskalering af databaser ikke er den nemmeste ting at gøre, især hvis Moodle tilføjer sit eget lille twist.
Som indgangspunkt vil vi bruge arkitekturen beskrevet i et af vores tidligere indlæg. MariaDB Cluster med ProxySQL og Keepalived oven på tingene.
Som du kan se, har vi en MariaDB-klynge med tre noder med ProxySQL, der opdeler sikker læsning fra resten af trafikken baseret på brugeren.
<?php // Moodle configuration file
unset($CFG);
global $CFG;
$CFG = new stdClass();
$CFG->dbtype = 'mysqli';
$CFG->dblibrary = 'native';
$CFG->dbhost = '192.168.1.222';
$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.222',
'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!Bruger, som vist ovenfor, er defineret i Moodle-konfigurationsfilen. Dette giver os mulighed for automatisk og sikkert at sende skrivninger og alle SELECT-sætninger, der kræver datakonsistens, til writer-noden, mens vi stadig sender nogle af SELECT'erne til de resterende noder i MariaDB-klyngen.
Lad os antage, at denne særlige opsætning ikke er nok for os. Hvilke muligheder har vi? Vi har to hovedelementer i opsætningen - MariaDB Cluster og ProxySQL. Vi vil overveje problemer på begge sider:
- Hvad kan der gøres, hvis ProxySQL-instansen ikke kan klare trafik?
- Hvad kan der gøres, hvis MariaDB Cluster ikke kan klare trafikken?
Lad os starte med det første scenarie.
ProxySQL-instansen er overbelastet
I det nuværende miljø kan kun én ProxySQL-instans håndtere trafikken - den som Virtual IP peger på. Dette efterlader os med en ProxySQL-instans, der fungerer som en standby - oppe og køre, men ikke bruges til noget. Hvis den aktive ProxySQL-instans nærmer sig CPU-mætning, er der et par ting, du måske vil gøre. For det første kan du naturligvis skalere lodret - at øge størrelsen af en ProxySQL-instans kan være den nemmeste måde at lade den håndtere større trafik. Husk at ProxySQL som standard er konfigureret til at bruge 4 tråde.
Hvis du vil være i stand til at bruge flere CPU-kerner, er dette indstilling skal du også ændre.
Alternativt kan du forsøge at skalere ud vandret. I stedet for at bruge to ProxySQL-instanser med VIP kan du samle ProxySQL med Moodle-værter. Så vil du omkonfigurere Moodle til at oprette forbindelse til ProxySQL på den lokale vært, ideelt set gennem Unix-socket - det er den mest effektive måde at oprette forbindelse til ProxySQL. Der er ikke meget af en konfiguration, som vi bruger med ProxySQL, derfor bør brug af flere forekomster af ProxySQL ikke tilføje for meget af overhead. Hvis du vil, kan du altid konfigurere ProxySQL Cluster for at hjælpe dig med at holde ProxySQL-forekomsterne synkroniserede med hensyn til konfigurationen.
MariaDB-klyngen er overbelastet
Nu taler vi om et mere alvorligt problem. Selvfølgelig vil det som sædvanligt hjælpe at øge størrelsen af forekomsterne. På den anden side er horisontal udskalering noget begrænset på grund af begrænsningen for "safe reads". Selvfølgelig kan du tilføje flere noder til klyngen, men du kan kun bruge dem til sikre læsninger. I hvor høj grad dette lader dig skalere ud, afhænger af arbejdsbyrden. For ren skrivebeskyttet arbejdsbyrde (gennemsyn gennem indholdet, fora osv.) ser det ganske pænt ud:
MySQL [(none)]> SELECT hostgroup, srv_host, srv_port, status, queries FROM stats_mysql_connection_pool WHERE hostgroup IN (20, 10) AND status='ONLINE';
+-----------+---------------+----------+--------+---------+
| hostgroup | srv_host | srv_port | status | Queries |
+-----------+---------------+----------+--------+---------+
| 20 | 192.168.1.204 | 3306 | ONLINE | 5683 |
| 20 | 192.168.1.205 | 3306 | ONLINE | 5543 |
| 10 | 192.168.1.206 | 3306 | ONLINE | 553 |
+-----------+---------------+----------+--------+---------+
3 rows in set (0.002 sec)Dette er stort set et forhold på 1:20 - for en forespørgsel, der rammer forfatteren, har vi 20 "sikre læsninger", der kan spredes over de resterende noder. På den anden side, når vi begynder at ændre dataene, ændres forholdet hurtigt.
MySQL [(none)]> SELECT hostgroup, srv_host, srv_port, status, queries FROM stats_mysql_connection_pool WHERE hostgroup IN (20, 10) AND status='ONLINE';
+-----------+---------------+----------+--------+---------+
| hostgroup | srv_host | srv_port | status | Queries |
+-----------+---------------+----------+--------+---------+
| 20 | 192.168.1.204 | 3306 | ONLINE | 3117 |
| 20 | 192.168.1.205 | 3306 | ONLINE | 3010 |
| 10 | 192.168.1.206 | 3306 | ONLINE | 6807 |
+-----------+---------------+----------+--------+---------+
3 rows in set (0.003 sec)Dette er et output efter at have udstedt flere karakterer, oprettet forumemner og tilføjet noget kursusindhold. Som du kan se, vil forfatteren med et sådant sikkert/usikkert forespørgselsforhold blive mættet tidligere end læserne, derfor er det ikke egnet at skalere ud ved at tilføje flere noder.
Hvad kan man gøre ved det? Der er en indstilling kaldet "latency". I henhold til konfigurationsfilen bestemmer den, hvornår det er sikkert at læse tabellen efter skrivningen. Når skrivning sker, markeres tabellen som ændret, og i "latency"-tiden vil alle SELECT'er blive sendt til writer-knuden. Når der er gået længere tid end "latency", kan SELECTs fra den tabel igen sendes til læseknudepunkter. Vær opmærksom på, at med MariaDB Cluster er den tid, der kræves for, at skrivesættet skal anvendes på tværs af alle noderne, typisk meget lav, tællet i millisekunder. Dette ville tillade os at sætte latensen ret lavt i Moodle-konfigurationsfilen, for eksempel burde værdien som 0.1s (100 millisekunder) være helt ok. Skulle du støde på problemer, kan du selvfølgelig altid øge denne værdi yderligere.
En anden mulighed at teste ville være at stole udelukkende på MariaDB Cluster for at fortælle, hvornår læsningen er sikker, og hvornår den ikke er det. Der er en wsrep_sync_wait-variabel, der kan konfigureres til at tvinge kausalitetstjek på flere adgangsmønstre (læser, opdaterer, indsætter, sletter, erstatter og VIS kommandoer). Til vores formål ville det være nok at sikre, at læsninger udføres med kausaliteten påtvunget, så vi sætter denne variabel til '1'.
Vi vil foretage denne ændring på alle MariaDB Cluster-knuderne. Vi bliver også nødt til at omkonfigurere ProxySQL til læse/skriveopdeling baseret på forespørgselsreglerne, ikke kun brugerne, som vi havde tidligere. Vi vil også fjerne 'moodle_safereads'-brugeren, da den ikke længere er nødvendig i denne opsætning.
Vi opsætter tre forespørgselsregler, der fordeler trafikken baseret på forespørgslen. SELECT … FOR UPDATE sendes til writer-noden, alle SELECT-forespørgsler sendes til læsere og alt andet (INSERT, DELETE, REPLACE, UPDATE, BEGIN, COMMIT og så videre) sendes også til writer-noden.
Dette giver os mulighed for at sikre, at alle læsninger kan spredes på tværs af læserknudepunkterne, hvilket giver mulighed for horisontal skalering ved at tilføje flere noder til MariaDB-klyngen.
Vi håber, at du med disse par tips vil være i stand til at udskalere din Moodle-database-backend meget lettere og i højere grad