Betroffen von der COVID-19-Pandemie stellen viele KMUs/KMU auf Online-Plattformen um. Präsenz- oder physischer Unterricht sind ebenfalls von dieser Pandemie betroffen, und viele Schulen und Universitäten stellen ebenfalls auf Online um und suchen nach Tools, die verwendet werden können, um den Studenten oder Schülern weiterhin so zu dienen, wie es die Bildung getan hat nicht behindert werden. Eine der bekanntesten Plattformen, die für Online-Bildungszwecke oder Online-Lernzwecke verfügbar sind, ist Moodle.
Was ist Moodle?
Moodle ist eine Open-Source-Software für ein Online-Lernmanagementsystem oder LMS (auch bekannt als Virtual Learning Environment oder VLE) unter der GPL-Lizenz. Es ermöglicht Pädagogen, ihre eigene private Website mit dynamischen Kursen zu erstellen, die das Lernen jederzeit und überall erweitern. Moodle bietet umfassende Unterstützung mit einfachem Zugriff und Funktionen für Lehrer, Schüler oder Administratoren.
Da es sich um eine Open-Source- und kostenlose Softwareplattform handelt, können Sie diese Software wie andere Open-Source-Software kostenlos und ohne Lizenzgebühren verwenden. Die Kosten entstehen nur, wenn diese Software auf einer kostenpflichtigen Hosting-Plattform gehostet wird oder wenn Sie sie mit ihrer Moodle Cloud hosten. Moodle ist auch für Handheld-Geräte wie Handys oder Tablets verfügbar.
Warum brauchen Sie eine hochverfügbare Datenbank?
In den 1990er Jahren wurde eine sehr einfache Lösung für Hochverfügbarkeit (HA) erfunden, nämlich Heartbeat. Ein Heartbeat-Cluster könnte grundsätzlich zwei Dinge tun:Es überwachte zwei Knoten (und nicht mehr als zwei) und es wurde so konfiguriert, dass es einen oder mehrere Dienste auf diesen beiden Knoten startete. Wenn der Knoten, der derzeit die Ressourcen hostet, ausgefallen ist, hat er die Clusterressourcen auf dem verbleibenden Knoten neu gestartet. Obwohl die ursprüngliche Version von Heartbeat keine Überwachung der Ressourcen selbst hatte, ändert sich dies bis zur Veröffentlichung von Heartbeat 2.0 in den frühen 2000er Jahren, wo es die Verwaltung von mehr als zwei Knoten im Cluster ermöglicht. Im Wesentlichen umfasst dies den Stand des Linux-HA-Clusterings, das zu großen Teilen auf Heartbeat 2.0 basiert. Von diesem Zeitpunkt an waren viele HA-Lösungen betroffen und wurden entwickelt und erstellt, um die Ausfallzeiten insbesondere für kritische Ressourcen zu minimieren.
Hochverfügbarkeit bedeutet nicht nur die Minimierung der Ausfallzeiten. Es deckt auch den Grad der Verantwortung ab, um die Dienstleistungen, die Sie anbieten und Ihren Kunden versprechen, kontinuierlich betreiben und aufrechterhalten zu können. Für die Kunden erreichbar zu sein bedeutet nicht, dass Sie auch in der Lage sind, auf sie zu reagieren, falls sie Hilfe benötigen. Es muss Ihre Geschäftsanwendung und Ihr System voll funktionsfähig machen, als ob es immer der normale Betriebszustand wäre, selbst wenn eine beispiellose Katastrophe eingetreten ist.
Sie können Ihre VLE-Anwendung nicht über Moodle betreiben, während Ihre Datenbank gewartet wird. Wenn Sie nur einen einzigen Datenbankserver haben, was bei einer einfachen und leichtgewichtigen Anwendungseinrichtung sehr häufig vorkommt, wird Ihre Anwendung angehalten, sobald der Server ausfällt. Wenn Sie einen Datenbankcluster mit Master-Slave-Replikation haben und dann auf einen beispiellosen Vorfall stoßen, der wiederum dazu führt, dass Ihre Anwendung nach dem Vorfall auf zwei Master schreibt, kann dies ein riesiges Durcheinander sein, das wiederum zu einer Datenbeschädigung Ihrer gesamten Geschäftsanwendung führt Datenschicht. Wenn zu diesem Zeitpunkt laufende Zahlungen erfolgten, könnte dies eine große Katastrophe bedeuten und einen großen Arbeitsaufwand bei der Datenwiederherstellung bedeuten.
Warum muss Ihre Datenbank also hochverfügbar sein? Weil es sein muss,
- Fähig, Wartungsarbeiten oder geplante Ausfälle machbar und innerhalb des zulässigen Wartungsfensters durchzuführen
- Betriebszeit ist lebenswichtig und muss bei Bedarf Ausfallzeiten vermeiden
- SLA ist in seinem höheren Umfang wichtig, um einen qualitativ hochwertigen Kundenservice zu erreichen
- Kontinuierlichen Service und Benutzerfreundlichkeit bieten
- Kein Single Point of Failure
- Kann ein Failover durchführen, wenn der Master kaputt geht oder abstürzt
- Vermeiden Sie Split-Brain-Szenarien, in denen mehrere Master gleichzeitig als aktive Autoren agieren
Aufbau des Datenbank-Clusters
Da wir nun betont haben, wie wichtig es ist, HA als Plan und als Lösung für Ihren Datenbankcluster zu haben, insbesondere für PostgreSQL, konzentrieren wir uns darauf, den Cluster von oben nach unten aufzubauen, um ein Höchstmaß zu erreichen verfügbares Setup bereit für Moodle-Anwendungs-Setup.
PostgreSQL installieren
Zunächst einmal, warum PostgreSQL? PostgreSQL hat große Vorteile im Vergleich zu anderen von Moodle unterstützten Datenbanken. Es ist eine Frage der Präferenz, wenn ich zusammenfassen muss, da alle von Moodle unterstützten Datenbanken alle in der Lage sind, mit den Daten umzugehen, und auch der Optimierung unterliegen. Es hängt davon ab, wie geschickt und erfahren Sie mit der Datenbank umgehen. Um zusammenzufassen, warum PostgreSQL verwendet wird, ist es eine zuverlässige Datenbank und seine hochentwickelte Open-Source-Software, insbesondere in Datenbanken, die mit anderen proprietären Anbietern wie Oracle und MS SQL verglichen werden können. Es unterstützt Abfrageparallelität, kann große oder riesige Datenbanken verwalten, bietet umfassende Unterstützung für JSON und vieles mehr. Sie können es hier nachlesen, warum Sie sich für PostgreSQL entscheiden sollten. Lassen Sie uns nun mit der Installation von PostgreSQL fortfahren
Für diesen Blog verwenden wir PostgreSQL 12 mit Ubuntu 18.04 (Bionic Beaver). Dann müssen Sie für die Einrichtung der Hochverfügbarkeit einen primären und mindestens einen Standby-Knoten (Replikat) haben, für den er übernimmt, sobald der Master ausfällt.
- Repository und Signaturschlüssel einrichten
sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/postgresql.list' wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add - - Installieren Sie den PG 12-Server
# Update the package lists: sudo apt-get update # Install server and client apt install postgresql-12 postgresql-client-12
Machen Sie dies auch auf dem Zielreplikat, aber Sie müssen es als Standby- oder Replikat konfigurieren. Alternativ schlage ich vor, dass Sie ClusterControl verwenden und es kostenlos herunterladen. Es wäre immer schneller, ein primäres/Standby-Setup zu installieren und einzurichten. Für mein Setup mit ClusterControl und der Registerkarte Topologieansicht habe ich die folgende Topologie erhalten:
Bei einer Master/Slave- oder Primär/Standby-Konfiguration ist dies nicht der Fall bedeutet, dass Sie für ein hochverfügbares Datenbank-Cluster vollständig abgesichert sind. Es ist noch nicht hochverfügbar. Sobald der primäre oder der Master ausfällt, gibt es kein zwangsläufiges Failover. Eine andere Sache ist, dass es keinen Ausgleich von Verbindungen von Clients gibt, die zum Master gegen den Slave gehen. Der Lastausgleich zwischen Master/Slave bedeutet jedoch nicht, dass er eingerichtet oder angewendet werden muss, um ein hochverfügbares Setup zu erfüllen. Ein Lastausgleich zwischen dem Master/Primary und einem Slave/Standby hilft Ihrem Master-Knoten dabei, die hohe Lastleistung nicht zu belasten, insbesondere zu Stunden mit sehr hohem Datenverkehr.
Load-Balancing einrichten
Wie bereits erwähnt, hilft der Lastausgleich zwischen Master und Slave Ihrem Master dabei, die Last herauszugreifen. Es ist nicht ideal, wenn Sie Ihren Standby-Server nur für die Replikation verwenden oder ihn übernehmen, falls der Master ausfällt. Das kann zwar funktionieren, bedeutet aber Ausfallzeiten und manuelle Arbeit, wenn der Master ausfällt, da Sie die Rolle Ihres Standby-Knotens auf einen Master umstellen müssen. Das ist auch in Ordnung, aber auch hier kann ein Load Balancer helfen, die Schreibvorgänge an den Master zu leiten und dann die Lesevorgänge zwischen dem Master und dem Slave zu leiten. Dies bietet Ihnen im Wesentlichen eine Lese-/Schreibaufteilung. Dazu stehen Ihnen bei PostgreSQL viele Optionen zur Auswahl. Grundsätzlich ist die häufigste und dennoch einfachste Einrichtung die Verwendung von HAProxy.
Obwohl es Optionen wie die Verwendung von PgBouncer oder pgpool-II gibt. Zur Vereinfachung dieses Blogs verwenden wir HAProxy. Die Installation von HAProxy ist ziemlich einfach, wenn Sie ClusterControl verwenden. Lassen Sie uns das über ClusterControl tun. Gehen Sie dazu einfach zur Registerkarte „Verwalten“ und wählen Sie „Load Balancer“ aus, wie unten gezeigt,
Da wir ein hochverfügbares Setup für Ihren PostgreSQL-Datenbankcluster benötigen, Wir sollten mindestens zwei Knoten haben. Wenn also Ihr primärer HAProxy-Knoten ausfällt, kann der passive oder Standby-HAProxy übernehmen. Mal sehen, wie es bei mir aussieht,
Obwohl das gut aussieht. Diese Einrichtung ist noch unzureichend. Wenn Sie der Meinung sind, dass wir mit dieser Topologie gut für ein hochverfügbares Setup sind, gibt es kein Failover, falls der HAProxy auf dem Knoten 192.168.30.222 an Port 9600 ausfällt oder wenn 192.168.30.223:9600 ausfällt und Ihre Anwendung so eingerichtet ist host, gibt es immer noch Ausfallzeiten, wenn keine proaktive Einrichtung vorgenommen wurde. Dadurch haben Sie Ausfallzeiten, wenn es manuell eingerichtet werden muss. In diesem Fall verwenden und richten wir Keepalived ein, damit die HAProxy-Instanzen genau auf ihren Zustand und Failover überwacht werden, falls der andere Knoten auf ein Problem stößt.
Halten Sie die Load Balancer hochverfügbar
Nun, da wir Load Balancer auf unseren Datenbanken haben, brauchen wir dennoch, dass unser HAProxy immer am Leben ist, falls der primäre Knoten für den Anwendungsendpunkt ausfällt. Was HAProxy im Wesentlichen mit dem Setup tun kann, das wir im vorherigen Abschnitt haben, können die Anwendungen 192.168.30.223 oder 192.168.30.222 mit den Ports 5433 (Lese-Schreib-Port) bzw. 5434 (Nur-Lese-Port) verwenden. Jetzt gibt es ein Problem, falls Sie wechseln müssen, falls die anderen Knoten ausfallen, und das Schlimme ist, dass Sie dem Geschäft schaden, da es Ausfallzeiten abdeckt, wenn es kein automatisches Failover gibt, um damit umzugehen. Das Vermeiden von Ausfallzeiten ist hier der beste Weg, es sei denn, Sie haben eine sehr niedrige SLA und eine hohe RTO und RPO.
Um solchen Katastrophen oder Ausfallzeiten vorzubeugen, empfehlen wir, Keepalived zusätzlich zu HAProxy einzurichten. Grundsätzlich sorgt HAProxy für einen Lastenausgleich zwischen Lese- und Schreibvorgängen, sofern Sie eine Lese-Schreib-Aufteilung bereitstellen, und Keepalived überwacht nur den Zustand der HAProxy-Knoten und wird es schaffen, den fehlerfreisten Knoten gemäß seiner gewünschten Konfiguration auszuwählen. Keepalived ist ein Tool, mit dem Sie die HAProxy-Knoten überwachen lassen können, obwohl es nicht so komplex ist, Datenbanken zu verwalten. Keepalived verwendet VIP (virtuelle IP), die dem standardmäßigen primären HAProxy-Knoten zuweist und diese VIP dann neu zuweist, falls der primäre HAProxy-Knoten ausfällt, und sie auf den nachfolgenden oder Standby-HAProxy-Knoten verweist.
Lassen Sie uns dies jetzt mit ClusterControl einrichten, da es mit ClusterControl schneller und einfacher zu verwalten ist. Um dies zu tun, ist es im Grunde der gleiche Ansatz wie bei der Einrichtung des HAProxy, aber wählen Sie stattdessen Keepalived aus, wie unten gezeigt,
Wenn Sie Keepalived manuell installieren, wählen wir grundsätzlich das primäre gegen aus die sekundäre, falls der primäre HAProxy ausfällt. Mal sehen, wie unsere Topologieansicht aussieht,
Das könnte sehr vielversprechend aussehen. Grundsätzlich verbindet sich der Moodle-Anwendungsclient mit dem VIP, dh 192.168.30.201 unter den Ports 5433 (Lese-Schreib-Port) und 5434 (Nur-Lese-Port). Zum Beispiel die Überprüfung auf einem externen Host, den ich habe,
[[email protected] ~]# psql -h 192.168.30.201 -U dbapgadmin -W postgres -p 5433
Password:
psql (11.2, server 12.4 (Ubuntu 12.4-1.pgdg18.04+1))
WARNING: psql major version 11, server major version 12.
Some psql features might not work.
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
postgres=# select inet_server_addr();
inet_server_addr
------------------
192.168.30.221
(1 row)was zeigt, dass nur der Writer-Knoten, den ich habe, auf meinen Master-Knoten zeigt, d.h. 192.168.30.22. Dann muss mein Nur-Lese-Port wie unten gezeigt sowohl zum Master- als auch zum Slave-Knoten gehen,
[[email protected] ~]# psql -h 192.168.30.201 -U dbapgadmin -W postgres -p 5434
Password:
psql (11.2, server 12.4 (Ubuntu 12.4-1.pgdg18.04+1))
WARNING: psql major version 11, server major version 12.
Some psql features might not work.
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
postgres=# select inet_server_addr();
inet_server_addr
------------------
192.168.30.221
(1 row)
postgres=# \q
[[email protected] ~]# psql -h 192.168.30.201 -U dbapgadmin -W postgres -p 5434
Password:
psql (11.2, server 12.4 (Ubuntu 12.4-1.pgdg18.04+1))
WARNING: psql major version 11, server major version 12.
Some psql features might not work.
Type "help" for help.
postgres=# select inet_server_addr();
inet_server_addr
------------------
192.168.30.222
(1 row)Dies zeigt, dass sowohl meine primären als auch meine Standby-Knoten als "Datenbank lesen"-Knoten identifiziert werden.
Nun, das sieht sehr vielversprechend aus, genau wie das, was ich zuvor gesagt habe. Trotzdem fehlt hier ein Teil, der eigentlich sehr wichtig ist. Es gibt keinen Datenbank-Failover-Mechanismus, der für diese Art von Setup bereit ist. Wir haben jedoch Keepalived, das HAProxy überwacht und dann ein Failover durch Umschalten des VIP durchführt, falls der primäre HAProxy ausfällt oder stirbt. Keepalived ist jedoch nicht dafür eingerichtet, die komplexe Einrichtung von PostgreSQL zu handhaben. Es gibt eine sehr anständige, die verfügbar und kostenlos ist, um dies einzurichten. Sie können Slony-I, ein Replikationssystem eines Drittanbieters, verwenden.
Failover-Mechanismus für Ihren PostgreSQL-Cluster haben
Es gibt Möglichkeiten, einen Failover-Mechanismus für Ihr PostgreSQL bereitzustellen. Slony-I oder allgemein nur Slony genannt, ist eines der gängigen Tools, die verwendet werden. Obwohl Slony erfordert, dass Ihr Setup eine logische Replikation sein muss, da es ein Publisher/Subscriber-Setup erfordert, ist es möglicherweise nicht ideal für andere Setups, die eine Standard-Streaming-Replikation verwenden. Der Nachteil bei der Verwendung von Slony ist, dass es keine automatische Erkennung für ausgefallene Systeme oder keine Node-Fencing-Unterstützung bietet. Daher ein allgemein als STONITH bezeichnetes Verfahren (dem anderen Knoten in den Kopf schießen oder dem ausgefallenen Knoten in den Kopf schießen), das im Grunde das Scheitern verhindert, um Split-Brain-Szenarien zu vermeiden, bei denen mehrere Masterknoten (aktive Schreibknoten) Schreibvorgänge akzeptieren gleiche Zeit. Obwohl dies angemessen eingerichtet werden kann, kann es dennoch zeitaufwändig und kompliziert sein, wenn es mit weniger Erfahrung und Erkenntnissen darüber erstellt wird, welche Szenarien für PostgreSQL bei einem Notfall eintreten müssen. Für Slony ist das Aufgeben festgeschriebener Transaktionen eine Geschäftsentscheidung, die nicht von einem Datenbanksystem getroffen werden kann. Wenn jemand die folgenden Befehle in ein Skript einfügen möchte, das automatisch vom Netzwerküberwachungssystem ausgeführt wird, dann überlässt es Ihnen einfach, dass es Ihre Daten und Ihre Failover-Richtlinie sind.
Alternativ, wenn Sie nach Enterprise-Optionen suchen, aber Ihr Geld zu einem vernünftigen Preis ausgeben können, dann bietet ClusterControl eine automatische Wiederherstellung für PostgreSQL-Cluster. Grundsätzlich löst die automatische Wiederherstellung die oben genannten Probleme mit Slony. Obwohl unsere automatische Wiederherstellung am besten mit Streaming-Replikation getestet wird und nur für den Streaming-Replikationstyp des PostgreSQL-Setups unterstützt wird. Wie funktioniert es? Im Grunde müssen Sie nur die Schaltflächen für die automatische Wiederherstellung aktivieren, genau wie unten,
Dies unterstützt Node-Fencing, was bedeutet, dass der fehlerhafte Node im Fall des Falles abgeschaltet wird Der Knoten wird aus einem nicht vorhersehbaren Grund wieder aktiv. Abgesehen davon unterstützt die automatische Wiederherstellung durch ClusterControl die Wiederherstellung von Knoten und Clustern. Wenn ein Master- oder Slave-Knoten versehentlich heruntergefahren oder getötet wurde, wird ClusterControl versuchen, dies wiederzubeleben, insbesondere wenn dies außerhalb eines geplanten Ausfalls oder Wartungsfensters auftritt. Diese Funktion schützt Sie nur davor, sich von Datenbankängsten zu erschöpfen, und bietet Ihnen gleichzeitig auch eine proaktive Überwachung, die Sie über mögliche Katastrophen informiert, bevor es für eine Wiederherstellung zu spät ist.
Fazit
Hochverfügbare Setups für Ihren Datenbank-Cluster, insbesondere für Moodle, können variieren, je nachdem, welche Art von Setup und welche Anforderungen Sie benötigen. Unabhängig davon, ob Sie sich ausschließlich auf kostenlose und Open-Source-Technologien verlassen oder ob es andere Optionen gibt, die das Geld wert sind, in Ihre Unternehmensanwendung zu investieren, solange das Budget dies zulässt, da dies eine Win-Win-Situation bieten kann, insbesondere wenn Sie sich nur mehr konzentrieren möchten auf der geschäftlichen Seite der Dinge, anstatt sich auf andere Tools wie Verwaltung und Entwicklungsarbeit zu konzentrieren.
