Face-to-Face-Meetings sind heutzutage auf das Nötigste beschränkt, Online-Aktivitäten haben sich als Hauptweg für die Interaktion zwischen Lehrern und Schülern durchgesetzt. Es erhöhte den Stress auf den bestehenden Online-Meeting-Plattformen (gibt es jemanden, der nicht weiß, was Zoom heutzutage ist?), Aber auch auf Online-Lernplattformen. Die Hochverfügbarkeit der Online-Tools ist wichtiger denn je und die Betriebsteams beeilen sich, dauerhafte, hochverfügbare Architekturen für ihre Umgebungen aufzubauen.
Höchstwahrscheinlich haben zumindest einige von Ihnen Moodle verwendet - es ist eine eigenständige Online-Lernplattform, die Sie vor Ort bereitstellen und verwenden können, um Online-Schulungen für Ihre Organisation bereitzustellen. Wie bereits erwähnt, ist es nach wie vor wichtig, dass es dauerhaft und hochverfügbar funktioniert. Wir möchten eine hochverfügbare Lösung vorschlagen, die MariaDB als Backend-Datenbank einbezieht – sowohl asynchrone Replikation als auch Galera Cluster.
Umgebungsdesignprozess
Wir möchten mit einem Prozess beginnen, in dem wir den Denkprozess hinter der Gestaltung der Umgebung für Moodle erläutern. Wir wollen eine hohe Verfügbarkeit, daher funktioniert ein einzelner Datenbankknoten für uns nicht. Wir wollen mehrere Knoten und dies führt uns zur ersten Entwurfsentscheidung. Sollten wir asynchrone Replikation oder Galera Cluster verwenden? Die zweite Frage lautet:Wie verteilen wir die Arbeitslast auf die Knoten? Beginnen wir mit dem zweiten.
Die neueste Moodle-Version zum Zeitpunkt der Erstellung dieses Blogs (3.9) führte ein nettes Feature namens Safe Reads ein. Das hier zu lösende Problem ist das Lesen nach dem Schreiben. Wenn Sie einen Knoten verwenden, ist die Welt ein einfacher Ort. Du schreibst und dann liest du. Was du geschrieben hast, ist schon da. Wenn Sie jedoch Knoten hinzufügen, ändern sich die Dinge. Bei der asynchronen Replikation können Slaves sogar zehn Sekunden oder mehr hinterherhinken. Was auch immer Sie auf den Master schreiben, es kann sogar Minuten dauern (wenn nicht mehr in den extremeren Fällen), um auf den Slave angewendet zu werden. Wenn Sie einen Schreibvorgang ausführen und dann sofort versuchen, dieselben Daten von einem der Slaves zu lesen, können Sie eine böse Überraschung erleben – die Daten werden nicht da sein. Galera-Cluster verwendet eine „virtuell“ synchrone Replikation und macht in diesem speziellen Fall „virtuell“ einen großen Unterschied – Galera ist nicht immun gegen die Read-after-Write-Probleme. Es gibt immer eine Verzögerung zwischen der Schreibausführung auf dem lokalen Knoten und der Anwendung des Writesets auf die verbleibenden Knoten des Clusters. Sicher, es wird höchstwahrscheinlich eher in Millisekunden als in Sekunden gemessen, aber es kann immer noch die Annahme widerlegen, dass Sie sofort lesen können, was Sie geschrieben haben. Der einzige Ort, an dem Sie nach dem Schreiben sicher lesen können, ist der Knoten, auf dem Sie die Daten geschrieben haben.
Da Moodle sehr stark auf das Lesen nach dem Schreiben angewiesen ist, können wir Lesevorgänge nicht einfach skalieren, indem wir mehr Knoten zum Lesen hinzufügen. Für Galera-Cluster könnten wir versuchen, das Problem zu mindern, indem wir die Konfigurationseinstellung wsrep-sync-wait verwenden, um Galera zu zwingen, sicherzustellen, dass die Lesevorgänge sicher ausgeführt werden können. Dies wirkt sich auf die Leistung des Systems aus, da alle Lesevorgänge warten müssen, bis Schreibvorgänge angewendet werden, bevor sie ausgeführt werden können. Dies ist auch eine Lösung für MariaDB Cluster (und andere Galera-basierte Lösungen), nicht für asynchrone Replikation. Glücklicherweise löst die Lösung von Moodle dieses Problem. Sie können eine Liste von Knoten definieren, die möglicherweise verzögert werden, und Moodle verwendet sie nur für Lesevorgänge, die nicht mit den Schreibvorgängen auf dem neuesten Stand sein müssen. Alle verbleibenden Lesevorgänge, für die Daten immer auf dem neuesten Stand sein müssen, werden an den Writer-Knoten geleitet. Die Skalierbarkeit von Moodle ist also begrenzt, da nur die „sicheren“ Lesevorgänge skaliert werden können. Wir werden auf jeden Fall die Funktion von 3.9 verwenden wollen, da dies die einzige sichere Methode ist, um zu bestimmen, welche Auswahl wohin gehen soll. Da alles in die Konfigurationsdatei von Moodle geschrieben ist, würden wir höchstwahrscheinlich einen Load Balancer, vorzugsweise ProxySQL, verwenden wollen, um eine Logik zu erstellen, die unsere Leseverteilung handhabt.
Sollen wir MariaDB-Cluster oder asynchrone Replikation verwenden? Wir zeigen Ihnen tatsächlich, wie Sie beide verwenden. In beiden Fällen ist die Konfiguration für Moodle ziemlich gleich. In beiden Fällen verwenden wir ProxySQL als Loadbalancer. Der Hauptunterschied zwischen diesen Lösungen ist das Failover. MariaDB Cluster ist viel einfacher zu handhaben – wenn ein Knoten ausfällt, verschiebt ProxySQL den Schreibverkehr einfach auf einen der verbleibenden Knoten. Bei der asynchronen Replikation sind die Dinge jedoch etwas anders. Wenn der Master ausfällt, muss ein Failover stattfinden. Dies geschieht nicht automatisch, Sie müssen es entweder von Hand ausführen oder Sie können sich auf eine Software verlassen, um dies zu erreichen. In unserem Fall verwenden wir ClusterControl, um die Umgebung zu verwalten und das Failover durchzuführen, daher gibt es aus Benutzersicht keinen großen Unterschied zwischen der asynchronen Replikation und dem MariaDB-Cluster – in beiden Fällen wird ein Writer-Fehler automatisch behandelt und der Cluster wird automatisch wiederhergestellt .
Wir haben festgelegt, dass wir sowohl asynchrone als auch praktisch synchrone Replikation präsentieren werden. Wir werden die sichere Schreibfunktion von Moodle 3.9 verwenden und wir werden ProxySQL als Loadbalancer verwenden. Um eine hohe Verfügbarkeit zu gewährleisten, benötigen wir mehr als eine ProxySQL-Instanz. Daher verwenden wir zwei davon, und um einen einzigen Einstiegspunkt in die Datenbankschicht zu erstellen, verwenden wir Keepalived, um eine virtuelle IP zu erstellen und sie auf eine der verfügbaren ProxySQL-Instanzen zu verweisen Knoten. So könnte unser Datenbank-Cluster aussehen:
Für asynchrone Replikation könnte dies etwa so aussehen:
Bereitstellen eines hochverfügbaren Datenbank-Backends für Moodle mit MariaDB-Replikation
Beginnen wir mit der MariaDB-Replikation. Wir werden ClusterControl verwenden, um das gesamte Datenbank-Backend einschließlich der Lastausgleichsfunktionen bereitzustellen.
Bereitstellen des MariaDB-Replikationsclusters
Zunächst müssen wir im Assistenten „Bereitstellen“ auswählen:
Dann sollten wir SSH-Konnektivität, passwortlosen, schlüsselbasierten SSH-Zugriff definieren eine Voraussetzung für ClusterControl zur Verwaltung der Datenbankinfrastruktur.
Wenn Sie diese Details ausgefüllt haben, ist es an der Zeit, einen Anbieter und eine Version auszuwählen , definieren Sie das Passwort des Superusers und entscheiden Sie sich für einige andere Details.
Wir werden vorerst MariaDB 10.4 verwenden. Als nächsten Schritt müssen wir die Replikationstopologie definieren:
Wir sollten die Hostnamen der Knoten und ihre Beziehung zueinander übergeben Sonstiges. Sobald wir mit der Topologie zufrieden sind, können wir bereitstellen. Für die Zwecke dieses Blogs werden wir Master und zwei Slaves als unser Backend verwenden.
Wir haben unseren ersten Cluster eingerichtet und sind bereit. Lassen Sie uns nun ProxySQL und Keepalived bereitstellen.
ProxySQL bereitstellen
Für ProxySQL müssen einige Details ausgefüllt werden – wählen Sie den zu installierenden Host aus Entscheiden Sie sich für die ProxySQL-Version und die Anmeldeinformationen für die Administrator- und Überwachungsbenutzer. Sie sollten auch vorhandene Datenbankbenutzer importieren oder einen neuen für Ihre Anwendung erstellen. Entscheiden Sie schließlich, welche Datenbankknoten Sie mit ProxySQL verwenden möchten, und entscheiden Sie, ob Sie implizite Transaktionen verwenden. Im Fall von Moodle ist dies nicht der Fall.
Bereitstellen von Keepalived
Als nächsten Schritt werden wir Keepalived einsetzen.
Nachdem Sie Details wie zu überwachende ProxySQL-Instanzen, virtuelle IP und die Die Schnittstelle VIP sollte sich an uns binden und ist bereit für die Bereitstellung. Nach ein paar Minuten sollte alles bereit sein und die Topologie sollte wie folgt aussehen:
Konfigurieren Sie Moodle und ProxySQL für Scale-Out für sichere Schreibvorgänge
Der letzte Schritt besteht darin, Moodle und ProxySQL so zu konfigurieren, dass sichere Schreibvorgänge verwendet werden. Während es möglich ist, Datenbankknoten in der Moodle-Konfiguration fest zu codieren, wäre es viel besser, sich auf ProxySQL zu verlassen, um die Topologieänderungen zu handhaben. Was wir tun können, ist, einen zusätzlichen Benutzer in der Datenbank zu erstellen. Dieser Benutzer wird in Moodle so konfiguriert, dass er sichere Lesevorgänge ausführt. ProxySQL wird so konfiguriert, dass der gesamte von diesem Benutzer ausgeführte Datenverkehr an die verfügbaren Slave-Knoten gesendet wird.
Als Erstes erstellen wir einen Benutzer, den wir für den schreibgeschützten Zugriff verwenden.
Wir gewähren hier alle Privilegien, aber es sollte möglich sein, diese Liste einzuschränken .
Der gerade erstellte Benutzer muss zu beiden ProxySQL-Instanzen im Cluster hinzugefügt werden, damit sich ProxySQL als dieser Benutzer authentifizieren kann. In der ClusterControl-Benutzeroberfläche können Sie die Aktion „Benutzer importieren“ verwenden.
Wir können nach dem Benutzer suchen, den wir gerade erstellt haben:
ProxySQL verwendet ein Konzept von Hostgruppen – Gruppen von Hosts, die demselben Zweck dienen . In unserer Standardkonfiguration gibt es zwei Hostgruppen - Hostgruppe 10, die immer auf den aktuellen Master zeigt, und Hostgruppe 20, die auf Slave-Knoten zeigt. Wir möchten, dass dieser Benutzer den Datenverkehr an Slave-Knoten sendet, daher weisen wir HG 20 als Standardknoten zu.
Fertig, der Benutzer wird in der Liste der Benutzer angezeigt:
Jetzt sollten wir denselben Vorgang auf dem anderen ProxySQL-Knoten wiederholen oder verwenden Option „Instanzen synchronisieren“. Auf die eine oder andere Weise sollte beiden ProxySQL-Knoten der Benutzer moodle_safereads hinzugefügt werden.
Der letzte Schritt wird die Bereitstellung von Moodle sein. Wir werden hier nicht den gesamten Prozess durchgehen, aber es gibt ein Problem, das wir ansprechen müssen. ProxySQL präsentiert sich als 5.5.30 und Moodle beschwert sich, dass es zu alt ist. Wir können es einfach in die gewünschte Version bearbeiten:
Sobald dies erledigt ist, müssen wir vorübergehend den gesamten Datenverkehr an senden der Meister. Dies kann erreicht werden, indem alle Abfrageregeln in ProxySQL gelöscht werden. Der „moodle“-Benutzer hat HG10 als Standard-Hostgruppe, was bedeutet, dass ohne Abfrageregeln der gesamte Datenverkehr von diesem Benutzer an den Master geleitet wird. Der zweite, sichere Lesevorgang, Benutzer hat die Standard-Hostgruppe 20, was so ziemlich die gesamte Konfiguration ist, die wir haben möchten.
Sobald dies erledigt ist, sollten wir die Konfigurationsdatei von Moodle bearbeiten und den Safe aktivieren liest 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!Was hier passiert ist, ist, dass wir die Nur-Lese-Verbindung zu ProxySQL hinzugefügt haben, die den Benutzer moodle_safereads verwendet. Dieser Benutzer wird immer auf Sklaven zeigen. Damit ist unsere Einrichtung von Moodle für die MariaDB-Replikation abgeschlossen.
Bereitstellen eines hochverfügbaren Datenbank-Backends für Moodle mit MariaDB-Cluster
Dieses Mal werden wir versuchen, MariaDB Cluster als unser Backend zu verwenden. Auch hier ist der erste Schritt derselbe, wir müssen im Assistenten „Bereitstellen“ auswählen:
Sobald Sie dies getan haben, sollten wir die SSH-Konnektivität definieren, passwortlos, schlüssel- Der basierte SSH-Zugriff ist eine Voraussetzung für ClusterControl, um die Datenbankinfrastruktur zu verwalten.
Dann sollten wir uns für Anbieter, Version, Passwort-Hosts und einige mehr entscheiden Einstellungen:
Sobald wir alle Details ausgefüllt haben, können wir loslegen.
Wir könnten hier weiter fortfahren, aber da alle weiteren Schritte im Grunde dieselben sind wie bei der MariaDB-Replikation, würden wir Sie nur bitten, nach oben zu scrollen und den Abschnitt „Bereitstellen von ProxySQL“ und alles, was darauf folgt, zu überprüfen. Sie müssen ProxySQL, Keepalived bereitstellen, es neu konfigurieren, die Konfigurationsdatei von Moodle ändern und das ist so ziemlich alles. Wir hoffen, dass dieser Blog Ihnen hilft, hochverfügbare Umgebungen für Moodle aufzubauen, die von MariaDB Cluster oder Replikation unterstützt werden.
