Im vorherigen Blog der Serie haben wir die Vor- und Nachteile der Verwendung von Galera Cluster zur Erstellung geografisch verteilter Cluster besprochen. In diesem Beitrag werden wir einen Galera-basierten geoverteilten Cluster entwerfen und zeigen, wie Sie alle erforderlichen Teile mit ClusterControl bereitstellen können.
Entwurf eines geografisch verteilten Galera-Clusters
Wir beginnen damit, die Umgebung zu erklären, die wir bauen wollen. 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.
Für dieses Setup ist die Konnektivität vorhanden und gesichert, aber wir werden nicht genau beschreiben, wie dies erreicht werden kann. Es gibt zahlreiche Methoden, um die Konnektivität zu sichern, angefangen bei proprietären Hardware- und Softwarelösungen über OpenVPN bis hin zu SSH-Tunneln.
Wir werden ProxySQL als Loadbalancer verwenden. ProxySQL 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. Die Anwendung kann so konfiguriert werden, dass sie mithilfe des Round-Robin-Algorithmus eine Verbindung zu einem der lokalen ProxySQL-Knoten herstellt. Wir können auch Keepalived und Virtual IP verwenden, um den Datenverkehr an den einzelnen ProxySQL-Knoten weiterzuleiten, solange ein einzelner ProxySQL-Knoten in der Lage wäre, den gesamten Datenverkehr zu verarbeiten.
Eine andere mögliche Lösung besteht darin, ProxySQL 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 ProxySQL nicht verfügbar sein wird, die Anwendung jedoch auf demselben Knoten einwandfrei funktionieren würde. Typischerweise sehen wir entweder einen Knotenausfall oder einen Netzwerkausfall, der sowohl ProxySQL als auch die Anwendung gleichzeitig betreffen würde.
Das obige Diagramm zeigt die Version der Umgebung, in der ProxySQL zusammengestellt ist derselbe Knoten wie die Anwendung. ProxySQL ist so konfiguriert, dass die Arbeitslast auf alle Galera-Knoten im lokalen Rechenzentrum verteilt wird. Einer dieser Knoten würde als Knoten ausgewählt werden, 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.
Das Hauptproblem bei geografisch verteilten Bereitstellungen von Galera Cluster ist die Latenz. Dies müssen Sie immer testen, bevor Sie die Umgebung starten. Bin ich mit der Commit-Zeit einverstanden? Bei jedem Commit muss eine Zertifizierung erfolgen, sodass Writesets an alle Knoten im Cluster gesendet und zertifiziert werden müssen, einschließlich Remote-Knoten. Es kann sein, dass die hohe Latenz das Setup für Ihre Anwendung ungeeignet erscheinen lässt. In diesem Fall finden Sie möglicherweise mehrere Galera-Cluster, die über asynchrone Replikation verbunden sind, besser geeignet. Dies wäre jedoch ein Thema für einen anderen Blogbeitrag.
Bereitstellen eines geografisch verteilten Galera-Clusters mit ClusterControl
Zur Verdeutlichung zeigen wir hier, wie ein Einsatz aussehen kann. Wir werden kein tatsächliches Multi-DC-Setup verwenden, alles wird in einem lokalen Labor bereitgestellt. Wir gehen davon aus, dass die Latenz akzeptabel und das gesamte Setup brauchbar ist. Das Tolle an ClusterControl ist, dass es infrastrukturunabhängig ist. Dabei spielt es keine Rolle, ob die Knoten nah beieinander liegen, sich im selben Rechenzentrum befinden oder ob die Knoten über mehrere Cloud-Anbieter verteilt sind. Solange eine SSH-Verbindung von der ClusterControl-Instanz zu allen Knoten besteht, sieht der Bereitstellungsprozess genau gleich aus. Deshalb können wir es Ihnen Schritt für Schritt zeigen, indem wir nur ein lokales Labor verwenden.
ClusterControl installieren
Zunächst müssen Sie ClusterControl installieren. Sie können es kostenlos herunterladen. Nach der Registrierung sollten Sie auf die Seite mit Anleitung zum Herunterladen und Installieren von ClusterControl zugreifen. Es ist so einfach wie das Ausführen eines Shell-Skripts. Sobald Sie ClusterControl installiert haben, wird Ihnen ein Formular zum Erstellen eines administrativen Benutzers angezeigt:
Sobald Sie es ausgefüllt haben, werden Ihnen ein Willkommensbildschirm und Zugriff angezeigt zu Bereitstellungsassistenten:
Wir entscheiden uns für die Bereitstellung. Dadurch wird ein Bereitstellungsassistent geöffnet:
Wir werden MySQL Galera auswählen. Wir müssen SSH-Konnektivitätsdetails weitergeben - entweder Root-Benutzer oder Sudo-Benutzer werden unterstützt. Im nächsten Schritt definieren wir Server im Cluster.
Wir werden drei Knoten in einem der Rechenzentren bereitstellen. Dann können wir den Cluster erweitern und neue Knoten in verschiedenen Segmenten konfigurieren. Jetzt brauchen wir nur noch auf „Bereitstellen“ zu klicken und ClusterControl beim Bereitstellen des Galera-Clusters zuzusehen.
Unsere ersten drei Knoten sind in Betrieb, wir können jetzt mit dem Hinzufügen fortfahren zusätzliche Knoten in anderen Rechenzentren.
Sie können dies über das Aktionsmenü tun, wie im Screenshot oben gezeigt .
Hier können wir zusätzliche Knoten nacheinander hinzufügen. Was wichtig ist, Sie sollten das Galera-Segment auf einen Wert ungleich Null ändern (0 wird für die ersten drei Knoten verwendet).
Nach einer Weile haben wir alle neun Knoten, verteilt auf drei Segmente.
Jetzt müssen wir die Proxy-Ebene bereitstellen. Wir werden dafür ProxySQL verwenden. Sie können es in ClusterControl über Manage -> Load Balancer:
bereitstellen
Dadurch wird ein Bereitstellungsfeld geöffnet:
Zuerst müssen wir entscheiden, wo ProxySQL bereitgestellt werden soll. Wir werden vorhandene Galera-Knoten verwenden, aber Sie können alles in das Feld eingeben, sodass es durchaus möglich ist, ProxySQL über den Anwendungsknoten bereitzustellen. Außerdem müssen Sie die Zugangsdaten für den administrativen und überwachenden Benutzer übergeben.
Dann müssen wir entweder einen der vorhandenen Benutzer in MySQL auswählen oder einen erstellen im Augenblick. Wir möchten auch sicherstellen, dass ProxySQL so konfiguriert ist, dass es Galera-Knoten verwendet, die sich nur im selben Rechenzentrum befinden.
Wenn Sie ein ProxySQL im Rechenzentrum bereit haben, können Sie es als Quelle für die Konfiguration verwenden:
Dies muss für jeden Anwendungsserver wiederholt werden, den Sie in allen Rechenzentren haben . Dann muss die Anwendung so konfiguriert werden, dass sie sich mit der lokalen ProxySQL-Instanz verbindet, idealerweise über den Unix-Socket. Dies bietet die beste Leistung und die niedrigste Latenz.
Nachdem das letzte ProxySQL bereitgestellt wurde, ist unsere Umgebung bereit. Anwendungsknoten stellen eine Verbindung mit lokalem ProxySQL her. Jedes ProxySQL ist so konfiguriert, dass es mit Galera-Knoten im selben Rechenzentrum funktioniert:
Fazit
Wir hoffen, dass diese zweiteilige Serie Ihnen geholfen hat, die Stärken und Schwächen von geografisch verteilten Galera-Clustern zu verstehen und wie ClusterControl die Bereitstellung und Verwaltung solcher Cluster sehr einfach macht.
