Open edX ist eine Plattform für Online-Bildungsaktivitäten. Angesichts der weltweiten Situation sind alle diese Plattformen stärker belastet und ihre Bedeutung hat deutlich zugenommen. Dies sind nicht nur die „Helfer“-Plattformen, sondern sie werden oft zur Hauptmethode für die Durchführung von Bildungsaktivitäten. Daraus resultieren höhere Anforderungen an die Belastbarkeit bzw. Verfügbarkeit der Plattform.
Open edX ist ein komplexes Produkt, das aus mehreren Elementen besteht. Eine davon ist die MySQL-Datenbank. In diesem kurzen Blog möchten wir diskutieren, wie Sie die Hochverfügbarkeit der Open edX-Plattform verbessern können.
Offensichtlich ist die einzelne MySQL-Datenbank ein einzelner Fehlerpunkt und daher kein geeigneter Ansatz für Produktionsbereitstellungen. Es gibt mehrere Möglichkeiten, die Verfügbarkeit der MySQL-Datenbank zu verbessern.
Für den Anfang können Sie das Master-Slave-Setup mit asynchroner oder halbsynchroner Replikation ausführen. Der Vorteil besteht darin, dass Sie, wenn der Master nicht verfügbar ist, einen der Slaves heraufstufen und mit der Operation fortfahren können. Der Hauptnachteil eines solchen Setups ist, dass das Failover entweder manuell durchgeführt werden muss, was die Ausfallzeit erhöht, oder dass Sie eine externe Software (z. B. ClusterControl) verwenden müssen, aber es kann trotzdem etwas Zeit dauern. Schließlich unterliegt jede Art von asynchroner oder halbsynchroner Replikation einer Replikationsverzögerung. Dies kann die Read-after-Write-Szenarien ernsthaft beeinträchtigen, in denen die Anwendung einen Schreibvorgang auf dem Master ausführt und dann sofort versucht, diese Daten vom Slave zu lesen.
Ein anderer Ansatz wäre die Verwendung eines Galera-Clusters zum Speichern der Daten von der Open edX-Plattform. Wir können mit Clustern mit drei Knoten beginnen – solche Cluster können den Ausfall eines einzelnen Knotens automatisch handhaben. Die verbleibenden zwei Knoten funktionieren weiterhin und reagieren auf Abfragen, die von der Anwendung kommen. Ein weiterer Vorteil von Galera ist, dass es, obwohl es „virtuell“ synchron ist (was so ziemlich bedeutet, dass es fast synchron ist), eine Möglichkeit gibt, Kausalitätsprüfungen zu erzwingen und Cluster in den synchronen Modus zu zwingen (auch wenn Sie dafür bezahlen). reduzierte Leistung).
Beide Szenarien würden eine Art Load Balancer vor ihnen erfordern, der den Datenverkehr handhaben und an ein geeignetes Ziel umleiten würde.
Sehen wir uns an, wie ClusterControl Ihnen dabei helfen kann, einen Galera-Cluster mit einer Reihe von Load Balancern bereitzustellen, die Sie für Ihre Open edX-Plattform verwenden können.
MariaDB-Cluster bereitstellen
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, müssen wir die passwortlose SSH-Konnektivität und den Schlüssel definieren -basierter SSH-Zugriff ist eine Voraussetzung für ClusterControl, sonst kann es die Datenbankinfrastruktur nicht verwalten.
Dann sollten wir uns für Anbieter, Version, Passwort, Hosts und einiges mehr entscheiden zusätzliche Einstellungen:
Nachdem all diese Details ausgefüllt sind, können wir mit der Bereitstellung fortfahren.
ProxySQL bereitstellen
Die Datenbank selbst ist nicht das einzige Element, das wir bereitstellen möchten. Wir brauchen auch einen Load Balancer, mit dem wir den Datenverkehr zu den Knoten leiten, die im gegebenen Moment verfügbar sind. Wir werden es auch verwenden, um eine Lese-/Schreibaufteilung bereitzustellen, wobei alle Schreibvorgänge an einen einzigen MariaDB Galera-Knoten geleitet werden. Dies hilft uns, Konflikte zwischen Schreibvorgängen zu vermeiden, die auf verschiedenen Galera-Knoten ausgeführt werden.
Für ProxySQL erfordert ClusterControl auch das Ausfüllen einiger Informationen - Sie müssen die auswählen Host, auf dem es installiert werden soll, entscheiden Sie sich für die ProxySQL-Version, die Anmeldeinformationen für die administrativen und überwachenden Benutzer. Diese Benutzer werden verwendet, um ProxySQL zu verwalten und den Status Ihres Galera-Clusters zu überwachen. Sie sollten auch vorhandene Datenbankbenutzer importieren oder einen neuen für Ihre Anwendung erstellen. Schließlich liegt es an Ihnen, zu entscheiden, welche Datenbankknoten Sie mit ProxySQL verwenden möchten, und zu entscheiden, ob Sie implizite Transaktionen verwenden.
Bereitstellen von Keepalived
Als nächsten Schritt werden wir Keepalived einsetzen. Die Idee hier ist, eine virtuelle IP zu haben, die auf die funktionierende ProxySQL-Instanz zeigt. Diese VIP kann dann in der Anwendung als Endpunkt für die MySQL-Datenbankkonnektivität verwendet werden.
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:
Das ist so ziemlich alles, wenn es um die Bereitstellung geht. Sie können Ihre Open edX-Plattform auf den VIP und Port 6033 richten, dies sollte ausreichen, um die Verbindung zu Ihrer Backend-Datenbank herzustellen. Das letzte verbleibende Bit, falls Sie es für notwendig halten, wäre die Konfiguration von Kausalitätsprüfungen. Es gibt eine wsrep_sync_wait-Variable, die genau das tun kann. Es kann Tests für mehrere Zugriffsmuster ermöglichen:Lesen, Aktualisieren, Einfügen, Löschen, Ersetzen und SHOW-Befehle. Wenn wir nur an den SELECT-Abfragen interessiert sind, setzen wir diese Variable mithilfe der ClusterControl-Konfigurationsverwaltung auf „1“.
Dadurch wird diese Änderung auf allen MariaDB-Cluster-Knoten durchgeführt.
Das ist so ziemlich alles. Wenn Sie Ihre Erfahrungen mit Open edX teilen möchten, können Sie uns gerne einen Kommentar hinterlassen.
