Es ist üblich, dass Datenbanken über mehrere geografische Standorte verteilt sind. Ein Szenario für diese Art der Einrichtung ist die Notfallwiederherstellung, bei der sich Ihr Standby-Rechenzentrum an einem anderen Ort als Ihr Hauptrechenzentrum befindet. Es könnte auch erforderlich sein, dass die Datenbanken näher bei den Benutzern liegen.
Die größte Herausforderung beim Erreichen dieses Setups besteht darin, die Datenbank so zu gestalten, dass die Wahrscheinlichkeit von Problemen im Zusammenhang mit der Netzwerkpartitionierung verringert wird.
MariaDB Cluster kann aus mehreren Gründen eine gute Wahl sein, um eine solche Umgebung aufzubauen. Wir möchten sie hier diskutieren und auch ein wenig darüber sprechen, wie eine solche Umgebung aussehen könnte.
Warum MariaDB-Cluster für geografisch verteilte Umgebungen verwenden?
Der erste Grund ist, dass MariaDB Cluster mehrere Autoren unterstützen kann. Dadurch ist das Schreib-Routing viel einfacher zu gestalten – Sie schreiben einfach in die lokalen MariaDB-Knoten. Bei synchroner Replikation wirkt sich die Latenz natürlich auf die Schreibleistung aus, und Sie werden möglicherweise feststellen, dass Ihre Schreibvorgänge langsamer werden, wenn Sie Ihren Cluster geografisch zu weit verteilen. Schließlich kann man die Gesetze der Physik nicht ignorieren und sie sagen zumindest jetzt, dass sogar die Lichtgeschwindigkeit in Glasfaserverbindungen begrenzt ist. Alle darüber hinaus hinzugefügten Router erhöhen die Latenz ebenfalls, wenn auch nur um ein paar Millisekunden.
Zweitens, Verzögerungsbehandlung im MariaDB-Cluster. Die asynchrone Replikation ist ein Thema für Replikationsverzögerungen – Slaves sind möglicherweise nicht auf dem neuesten Stand der Daten, wenn sie Schwierigkeiten haben, alle Änderungen rechtzeitig anzuwenden. In MariaDB Cluster ist dies anders - die Flusskontrolle ist ein Mechanismus, der den Cluster synchron halten soll. Na ja, fast - in einigen Grenzfällen kann man immer noch Verzögerungen beobachten. Wir sprechen hier in der Regel von Millisekunden, höchstens ein paar Sekunden, während im Himmel der asynchronen Replikation die Grenze erreicht ist.
Drittens Segmente. Standardmäßig verwendet MariaDB-Cluster die All-to-All-Kommunikation und jedes Writeset wird vom Knoten an alle anderen Knoten im Cluster gesendet. Dieses Verhalten kann durch Segmente verändert werden. Segmente ermöglichen es Benutzern, MariaDB-Cluster in mehrere Teile aufzuteilen. Jedes Segment kann mehrere Knoten enthalten und wählt einen von ihnen als Relaisknoten aus. Solche Knoten empfangen Writesets von anderen Segmenten und verteilen sie über MariaDB-Knoten, die lokal zum Segment gehören. Wie Sie im obigen Diagramm sehen können, ist es daher möglich, den über das WAN gehenden Replikationsverkehr um das Dreifache zu reduzieren – es werden nur zwei „Repliken“ des Replikationsstroms über das WAN gesendet:eine pro Rechenzentrum im Vergleich zu einer pro Slave bei der asynchronen Replikation.
Wo MariaDB Cluster schließlich wirklich glänzt, ist die Handhabung der Netzwerkpartitionierung. MariaDB Cluster überwacht ständig den Zustand der Knoten im Cluster. Jeder Knoten versucht, sich mit seinen Peers zu verbinden und den Status des Clusters auszutauschen. Wenn eine Teilmenge von Knoten nicht erreichbar ist, versucht MariaDB, die Kommunikation weiterzuleiten, sodass sie erreicht werden, wenn es eine Möglichkeit gibt, diese Knoten zu erreichen.
Ein Beispiel ist im obigen Diagramm zu sehen:DC 1 hat die Konnektivität verloren mit DC2, aber DC2 und DC3 können eine Verbindung herstellen. In diesem Fall wird einer der Knoten in DC3 verwendet, um Daten von DC1 an DC2 weiterzuleiten, um sicherzustellen, dass die Intra-Cluster-Kommunikation aufrechterhalten werden kann.
MariaDB kann Aktionen basierend auf dem Zustand des Clusters durchführen. Es implementiert das Quorum – die Mehrheit der Knoten muss verfügbar sein, damit der Cluster arbeiten kann. Wenn der Knoten vom Cluster getrennt wird und keinen anderen Knoten erreichen kann, wird er seinen Betrieb einstellen.
Wie im obigen Diagramm zu sehen ist, gibt es einen teilweisen Verlust der Netzwerkkommunikation in DC1 und der betroffene Knoten wird aus dem Cluster entfernt, wodurch sichergestellt wird, dass die Anwendung nicht auf veraltete Daten zugreift.
Dies gilt auch im größeren Maßstab. Der DC1 wurde die gesamte Kommunikation abgeschnitten. Infolgedessen wurde das gesamte Rechenzentrum aus dem Cluster entfernt und keiner seiner Knoten wird den Datenverkehr bedienen. Der Rest des Clusters behielt die Mehrheit (6 von 9 Knoten sind verfügbar) und konfigurierte sich selbst neu, um die Verbindung zwischen DC 2 und DC3 aufrechtzuerhalten. Im obigen Diagramm sind wir davon ausgegangen, dass der Writer den Knoten in DC2 trifft, aber denken Sie bitte daran, dass MariaDB mit mehreren Writern ausgeführt werden kann.
Entwurf eines geografisch verteilten MariaDB-Clusters
Wir sind einige der Funktionen durchgegangen, die MariaDB Cluster zu einer guten Lösung für geografisch verteilte Umgebungen machen. Konzentrieren wir uns jetzt ein wenig auf das Design. Lassen Sie uns zu Beginn erklären, in welcher Umgebung wir arbeiten. Wir werden drei entfernte Rechenzentren verwenden, die über Wide Area Network (WAN) verbunden sind. Jedes Rechenzentrum erhält Schreibvorgänge von lokalen Anwendungsservern. Lesevorgänge werden auch nur lokal sein. Dadurch soll unnötiger Datenverkehr über das WAN vermieden werden.
Um diesen Blog weniger kompliziert zu gestalten, gehen wir nicht näher darauf ein, wie die Konnektivität aussehen sollte. Wir gehen von einer Art ordnungsgemäß konfigurierter, sicherer Verbindung über alle Rechenzentren hinweg aus. VPN oder andere Tools können verwendet werden, um dies zu implementieren.
Wir werden MaxScale als Loadbalancer verwenden. MaxScale wird lokal in jedem Rechenzentrum bereitgestellt. Es leitet den Datenverkehr auch nur an die lokalen Knoten weiter. Remote-Knoten können immer manuell hinzugefügt werden und wir werden Fälle erläutern, in denen dies eine gute Lösung sein könnte. Anwendungen können so konfiguriert werden, dass sie sich mit einem Round-Robin-Algorithmus mit einem der lokalen MaxScale-Knoten verbinden. Wir können auch Keepalived und Virtual IP verwenden, um den Datenverkehr an den einzelnen MaxScale-Knoten weiterzuleiten, solange ein einzelner MaxScale-Knoten in der Lage wäre, den gesamten Datenverkehr zu bewältigen.
Eine andere mögliche Lösung besteht darin, MaxScale mit Anwendungsknoten zu verbinden und die Anwendung so zu konfigurieren, dass sie eine Verbindung zum Proxy auf dem lokalen Host herstellt. Dieser Ansatz funktioniert ziemlich gut unter der Annahme, dass es unwahrscheinlich ist, dass MaxScale nicht verfügbar sein wird, die Anwendung jedoch auf demselben Knoten gut funktionieren würde. Typischerweise sehen wir entweder einen Knotenausfall oder einen Netzwerkausfall, der sowohl MaxScale als auch die Anwendung gleichzeitig betreffen würde.
Das obige Diagramm zeigt die Version der Umgebung, in der MaxScale Proxy-Farmen bildet - alle Proxy-Knoten mit der gleichen Konfiguration, Lastenausgleich mit Keepalived oder einfach nur Round-Robin von der Anwendung über alle MaxScale-Knoten. MaxScale ist so konfiguriert, dass die Arbeitslast auf alle MariaDB-Knoten im lokalen Rechenzentrum verteilt wird. Einer dieser Knoten würde als Knoten ausgewählt, an den die Schreibvorgänge gesendet werden, während SELECTs über alle Knoten verteilt würden. Ein dedizierter Writer-Knoten in einem Rechenzentrum trägt dazu bei, die Anzahl möglicher Zertifizierungskonflikte zu reduzieren, was in der Regel zu einer besseren Leistung führt. Um dies noch weiter zu reduzieren, müssten wir den Datenverkehr über die WAN-Verbindung senden, was nicht ideal ist, da die Bandbreitenauslastung erheblich steigen würde. Derzeit werden mit den vorhandenen Segmenten nur zwei Kopien des Writesets über Rechenzentren gesendet – eine pro Domänencontroller.
Fazit
Wie Sie sehen können, kann MariaDB Cluster einfach verwendet werden, um geografisch verteilte Cluster zu erstellen, die sogar auf der ganzen Welt funktionieren können. Der begrenzende Faktor wird die Netzwerklatenz sein. Wenn es zu hoch ist, müssen Sie möglicherweise separate MariaDB-Cluster verwenden, die über asynchrone Replikation verbunden sind.
