Moodle is een erg populair platform om online cursussen te geven. Met de situatie die we in 2020 zien, vormt Moodle, samen met communicatoren zoals Zoom, de ruggengraat van de diensten die online leren en thuisonderwijs mogelijk maken. De vraag naar Moodle-platforms nam aanzienlijk toe in vergelijking met voorgaande jaren. Er zijn nieuwe platforms gebouwd, er is extra belasting op de platforms gelegd die, historisch gezien, alleen als hulpinstrument fungeerden en nu zijn ze bedoeld om de hele educatieve inspanning te stimuleren. Hoe de Moodle uitschalen? We hebben een blog over dit onderwerp. Hoe de database-backend voor Moodle te schalen? Nou, dat is een ander verhaal. Laten we er eens naar kijken, aangezien het uitschalen van databases niet het gemakkelijkste is om te doen, vooral als de Moodle zijn eigen kleine draai geeft.
Als startpunt zullen we de architectuur gebruiken die in een van onze eerdere berichten is beschreven. MariaDB Cluster met ProxySQL en Keepalive er bovenop.
Zoals u kunt zien, hebben we een MariaDB-cluster met drie knooppunten met ProxySQL die splitst veilige leesacties van de rest van het verkeer op basis van de gebruiker.
<?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!Gebruiker, zoals hierboven weergegeven, wordt gedefinieerd in het Moodle-configuratiebestand. Dit stelt ons in staat om automatisch en veilig schrijfbewerkingen en alle SELECT-instructies die gegevensconsistentie vereisen naar het schrijversknooppunt te verzenden, terwijl nog steeds enkele van de SELECT's naar de resterende knooppunten in het MariaDB-cluster worden verzonden.
Laten we aannemen dat deze specifieke opstelling niet genoeg voor ons is. Wat zijn de opties die we hebben? We hebben twee hoofdelementen in de setup:MariaDB Cluster en ProxySQL. We zullen problemen aan beide kanten bekijken:
- Wat kan er worden gedaan als de ProxySQL-instantie het verkeer niet aankan?
- Wat kan er worden gedaan als MariaDB Cluster het verkeer niet aankan?
Laten we beginnen met het eerste scenario.
ProxySQL-instantie is overbelast
In de huidige omgeving kan slechts één ProxySQL-instantie het verkeer afhandelen - degene waar Virtual IP naar verwijst. Dit laat ons achter met een ProxySQL-instantie die fungeert als een stand-by - up and running maar nergens voor gebruikt. Als de actieve ProxySQL-instantie de CPU-verzadiging nadert, zijn er een aantal dingen die u misschien wilt doen. Ten eerste kun je natuurlijk verticaal schalen - het vergroten van de grootte van een ProxySQL-instantie is misschien wel de gemakkelijkste manier om het meer verkeer te laten verwerken. Houd er rekening mee dat ProxySQL standaard is geconfigureerd om 4 threads te gebruiken.
Als u meer CPU-kernen wilt gebruiken, is dit de instelling die u ook moet wijzigen.
Je kunt ook proberen horizontaal uit te schalen. In plaats van twee ProxySQL-instanties met VIP te gebruiken, kunt u ProxySQL samenvoegen met Moodle-hosts. Vervolgens wil je Moodle opnieuw configureren om verbinding te maken met ProxySQL op de lokale host, idealiter via de Unix-socket - dit is de meest efficiënte manier om verbinding te maken met ProxySQL. Er is niet veel van een configuratie die we gebruiken met ProxySQL, daarom zou het gebruik van meerdere instanties van ProxySQL niet te veel overhead moeten toevoegen. Als u wilt, kunt u altijd ProxySQL-cluster instellen om u te helpen de ProxySQL-instanties synchroon te houden met betrekking tot de configuratie.
MariaDB-cluster is overbelast
Nu hebben we het over een serieuzer probleem. Natuurlijk helpt het, zoals gewoonlijk, om de grootte van de instanties te vergroten. Aan de andere kant is horizontale schaalvergroting enigszins beperkt vanwege de "veilige uitlezingen" -beperking. Natuurlijk kunt u meer knooppunten aan het cluster toevoegen, maar u kunt ze alleen gebruiken voor veilige leesbewerkingen. In hoeverre je hiermee kunt uitschalen, hangt af van de workload. Voor pure alleen-lezen werklast (bladeren door de inhoud, forums enz.) ziet het er best aardig uit:
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)Dit is ongeveer een verhouding van 1:20 - voor één zoekopdracht die de schrijver raakt, hebben we 20 "veilige reads" die kunnen worden verspreid over de resterende knooppunten. Aan de andere kant, wanneer we beginnen met het wijzigen van de gegevens, verandert de verhouding snel.
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)Dit is een uitvoer na het geven van verschillende cijfers, het creëren van forumonderwerpen en het toevoegen van cursusinhoud. Zoals je kunt zien, zal met zo'n veilige/onveilige query-verhouding de schrijver eerder verzadigd zijn dan de lezers, daarom is uitschalen door meer knooppunten toe te voegen niet geschikt.
Wat kan eraan gedaan worden? Er is een instelling genaamd "latency". Volgens het configuratiebestand bepaalt het wanneer het veilig is om de tabel na het schrijven te lezen. Wanneer er wordt geschreven, wordt de tabel gemarkeerd als gewijzigd en gedurende de "latentie" -tijd worden alle SELECT's naar het schrijversknooppunt verzonden. Zodra de tijd langer dan "latentie" is verstreken, kunnen SELECT's uit die tabel opnieuw naar leesknooppunten worden verzonden. Houd er rekening mee dat met MariaDB Cluster de tijd die nodig is om de schrijfset op alle knooppunten toe te passen, doorgaans erg laag is, geteld in milliseconden. Dit zou ons in staat stellen om de latentie vrij laag in te stellen in het Moodle-configuratiebestand, bijvoorbeeld de waarde zoals 0,1s (100 milliseconden) zou redelijk goed moeten zijn. Mocht u problemen ondervinden, dan kunt u deze waarde natuurlijk altijd nog verder verhogen.
Een andere optie om te testen is om puur op MariaDB Cluster te vertrouwen om te bepalen wanneer het lezen veilig is en wanneer niet. Er is een wsrep_sync_wait-variabele die kan worden geconfigureerd om causaliteitscontroles af te dwingen op verschillende toegangspatronen (lezen, bijwerken, invoegen, verwijderen, vervangen en SHOW-commando's). Voor ons doel zou het voldoende zijn om ervoor te zorgen dat de uitlezingen worden uitgevoerd met de causaliteit die wordt afgedwongen, dus zullen we deze variabele op '1' zetten.
We gaan deze wijziging doorvoeren op alle MariaDB-clusterknooppunten. We zullen ProxySQL ook opnieuw moeten configureren voor lees-/schrijfsplitsing op basis van de queryregels, niet alleen de gebruikers, zoals we eerder hadden. We zullen ook de 'moodle_safereads'-gebruiker verwijderen omdat deze niet meer nodig is in deze configuratie.
We hebben drie queryregels ingesteld die het verkeer verdelen op basis van de query. SELECT ... FOR UPDATE wordt naar het schrijversknooppunt verzonden, alle SELECT-query's worden naar de lezers verzonden en al het andere (INSERT, DELETE, REPLACE, UPDATE, BEGIN, COMMIT enzovoort) wordt ook naar het schrijversknooppunt verzonden.
Hierdoor kunnen we ervoor zorgen dat alle leesbewerkingen kunnen worden verspreid over de lezerknooppunten, waardoor horizontale schaalvergroting mogelijk wordt door meer knooppunten toe te voegen aan het MariaDB-cluster.
We hopen dat u met deze paar tips uw Moodle-database-backend veel gemakkelijker en in grotere mate kunt uitbreiden