In unserem vorherigen Blog haben wir ClusterControl CMON HA für Distributed Database High Availability, geschrieben von Krzysztof Ksiazek, in zwei separaten Posts besprochen. In diesem Blog behandeln wir die Verteilung von Knoten über lokale und öffentliche Clouds (unter Verwendung der Google Cloud Platform (GCP)).
Der Grund, warum wir diesen Blog geschrieben haben, ist, dass wir Fragen dazu erhalten haben, wie eine Hochverfügbarkeitsinstanz von ClusterControl mit CMON-Knoten implementiert werden kann, die lokal ausgeführt werden, und einem anderen CMON-Knoten, der auf einem ausgeführt wird anderen Rechenzentrum (z. B. eine Public Cloud). In unserem vorherigen Blog „ClusterControl CMON HA for Distributed Database High Availability“ haben wir Galera-Cluster-Knoten verwendet, aber dieses Mal verwenden wir die MySQL-Replikation mit Percona Server 5.7. Ein ideales Setup dafür besteht darin, die Kommunikation von Knoten von Ihrem On-Premise und Ihren Knoten, die sich in einer öffentlichen Cloud befinden, immer über VPN oder einen sicheren Kanal zu kapseln.
ClusterControl CMON HA befindet sich in einem frühen Stadium, für das es unserer Meinung nach noch nicht ausgereift genug ist. Unser CMON HA ist jedoch in der Lage, Ihnen das Gefühl der Funktionalität für die Bereitstellung eines ClusterControl zu vermitteln, um es hochverfügbar zu machen. Lassen Sie uns damit fortfahren, wie Sie die Verteilung der Knoten lokal über die öffentliche Cloud bereitstellen und einrichten können.
Was ist ein CMON?
Bevor wir zum Hauptthema übergehen, lassen Sie uns Ihnen vorstellen, was CMON ist. CMON steht für ClusterControl Controller, das „primäre Gehirn“ von ClusterControl. Ein Back-End-Dienst, der Automatisierung, Verwaltung, Überwachung von Planungsaufgaben und auch die HA-Verfügbarkeit durchführt. Die gesammelten Daten werden in der CMON-Datenbank gespeichert, für die wir MySQL-kompatible Datenbanken als Datenspeicher verwenden.
Der Architekturaufbau
Einige von Ihnen kennen möglicherweise nicht die Fähigkeiten von ClusterControl, die es ausführen und für Hochverfügbarkeit einrichten kann. Wenn Sie mehrere ClusterControl- (oder CMON-) Knoten ausführen, ist dies kostenlos möglich. Möglicherweise können Sie bei Bedarf unzählige ClusterControl-Knoten ausführen.
Für dieses Setup haben wir ClusterControl-Knoten auf einem ClusterControl, um beispielsweise die Datenbankknoten zu erstellen oder bereitzustellen und ein automatisches Failover zu verwalten, wenn ein Fehler auftritt. Sie können zwar MHA, Orchestrator oder Maxscale verwenden, um das automatische Failover zu verwalten, aber aus Effizienz- und Geschwindigkeitsgründen verwende ich ClusterControl, um die speziellen Dinge zu tun, die andere von mir erwähnte Tools nicht haben.
Sehen wir uns also das Diagramm für dieses Setup an:
Die auf diesem Diagramm basierende Einrichtung zeigt dies zusätzlich zum CMON mit drei Knoten , darüber befindet sich ein laufender CMON (ClusterControl), der das automatische Failover überwacht. Dann kann HAProxy einen Lastenausgleich zwischen den überwachten drei CMON-Knoten durchführen, wobei sich ein Knoten in einer separaten Region befindet, die in GCP für diesen Blog gehostet wird. Sie werden vielleicht bemerken, dass wir Keepalived nicht aufgenommen haben, weil wir einen VIP nicht unter GCP platzieren können, da er sich in einem anderen Netzwerk befindet.
Wie Sie vielleicht bemerkt haben, platzieren wir insgesamt drei Knoten. CMON HA erfordert, dass wir mindestens 3 Knoten benötigen, um einen Abstimmungsprozess oder ein sogenanntes Quorum durchzuführen. Für diese Einrichtung benötigen wir also mindestens 3 Knoten, um eine höhere Verfügbarkeit zu haben.
Bereitstellen eines lokalen ClusterControl-Knotens
In diesem Abschnitt gehen wir davon aus, dass Sie Ihre ClusterControl-Benutzeroberfläche bereits eingerichtet oder installiert haben, die wir verwenden werden, um einen MySQL-Replikationscluster mit drei Knoten unter Verwendung von Percona Server bereitzustellen.
Lassen Sie uns zuerst den Cluster erstellen, indem Sie eine neue MySQL-Replikation bereitstellen, wie unten gezeigt.
Beachten Sie, dass ich hier Percona Server 5.7 verwende, für den die Standardeinstellung ist Einrichtung durch ClusterControl funktioniert effizient.
Definieren Sie dann den Hostnamen oder die IP Ihrer Knoten,
An diesem Punkt gehen wir davon aus, dass Sie bereits einen Knoten mit zwei Knoten eingerichtet haben Master/Slave-Replikation, die gehostet oder lokal ausgeführt wird. Der folgende Screenshot sollte zeigen, wie Ihre Knoten aussehen werden:
ClusterControl einrichten und installieren und CMON HA auf dem ersten Knoten aktivieren
Aus diesem vorherigen Blog ClusterControl CMON HA für Distributed Database High Availability haben wir kurz die Schritte dazu bereitgestellt. Lassen Sie uns wieder nach unten gehen und die Schritte wie angegeben ausführen, aber für dieses spezielle Master/Slave-Replikations-Setup.
Wählen Sie als Erstes einen Knoten aus, auf dem zuerst ClusterControl installiert werden soll (bei diesem Setup installiere ich am Ende zuerst auf dem Knoten 192.168.70.80) und führen Sie die folgenden Schritte aus.
Schritt Eins
ClusterControl installieren
$ wget http://www.severalnines.com/downloads/CMON/install-cc
$ chmod +x install-cc
$ sudo ./install-cc # omit sudo if you run as root
Beachten Sie, dass Sie, sobald Sie dazu aufgefordert werden, dass eine aktuelle mysql-Instanz erkannt wird, ClusterControl die vorhandene mysqld-Instanz verwenden lassen müssen, da dies eines unserer Ziele hier für CMON HA und für dieses Setup ist, um die zu verwenden habe MySQL bereits eingerichtet.
Schritt Zwei
Binde CMON nicht nur, um via localhost zuzulassen, sondern auch an die spezifische IP-Adresse (da wir HA aktivieren werden)
## edit /etc/default/CMON and modify the line just like below or add the line if it doesn't exist
RPC_BIND_ADDRESSES="127.0.0.1,192.168.70.80"
Schritt Drei
Starten Sie dann CMON neu,
service CMON restart
Schritt Vier
S9s-CLI-Tools installieren
$ wget http://repo.severalnines.com/s9s-tools/install-s9s-tools.sh
$ chmod 755 install-s9s-tools.sh
$ ./install-s9s-tools.sh
Während dieser Installation richtet das s9s-Tool einen Admin-Benutzer ein, den Sie verwenden können, wenn Sie mit dem s9s-Befehl umgehen, genau wie beim Aktivieren von CMON HA.
Schritt Fünf
CMON-HA aktivieren
$ s9s controller --enable-CMON-ha
Schritt Sechs
Andern Sie zuletzt die /etc/my.cnf und fügen Sie hinzu,
slave-skip-errors = 1062
im Abschnitt [mysqld]. Vergessen Sie nach dem Hinzufügen nicht, mysql neu zu starten als,
service mysql restart
oder
systemctl restart mysql
Derzeit ist dies die Einschränkung, mit der wir bei CMON HA konfrontiert sind, da es versucht, Protokolleinträge in den Slave einzufügen, aber das kann vorerst in Ordnung sein.
Setup, ClusterControl installieren und CMON HA auf dem zweiten Knoten aktivieren
Einfach so für den ersten Knoten. Jetzt müssen wir auf dem zweiten Knoten (192.168.70.70) die gleichen Schritte ausführen, aber stattdessen müssen wir einige Anpassungen in den Schritten vornehmen, um diese Hochverfügbarkeit zu ermöglichen.
Schritt Eins
Kopieren Sie die Konfiguration vom ersten Knoten (192.168.70.80) auf den zweiten Knoten (192.168.70.70)
$ scp -r /etc/CMON* 192.168.70.70:/etc/
Schritt Zwei
Bearbeiten Sie im zweiten Knoten die /etc/CMON.cnf und stellen Sie sicher, dass der Host richtig konfiguriert ist. z. B.
vi /etc/CMON.cnf
Dann hostname param als zuweisen,
Hostname=192.168.70.70
Schritt Drei
ClusterControl installieren,
$ wget http://www.severalnines.com/downloads/CMON/install-cc
$ chmod +x install-cc
$ sudo ./install-cc # omit sudo if you run as root
Überspringen Sie jedoch die Installation von CMON (oder ClusterControl Controller), sobald Sie auf diese Zeile stoßen,
=> An existing Controller installation detected!
=> A re-installation of the Controller will overwrite the /etc/CMON.cnf file
=> Install the Controller? (y/N):
Der Rest, tun Sie einfach das, was Sie auf dem ersten Knoten getan haben, wie das Einrichten des Hostnamens, verwenden Sie die vorhandene mysqld-laufende Instanz, geben Sie das MySQL-Passwort und das Passwort für Ihren CMON an, das sein muss beide haben das gleiche Passwort mit dem ersten Knoten.
Schritt Vier
S9s-CLI-Tools installieren
$ wget http://repo.severalnines.com/s9s-tools/install-s9s-tools.sh
$ chmod 755 install-s9s-tools.sh
$ ./install-s9s-tools.sh
Schritt Fünf
Kopieren Sie die verbleibende Konfiguration vom 1. Knoten zum 2. Knoten.
$ scp -r ~/.s9s/ 192.168.70.70:/root/
$ scp /etc/s9s.conf 192.168.70.70:/etc/
$ scp /var/www/html/clustercontrol/bootstrap.php 192.168.70.70:/var/www/html/clustercontrol/
Schritt Sechs
Clustercontrol-Controller-Paket installieren,
Für Ubuntu/Debian,
$ apt install -y clustercontrol-controller
Für RHEL/CentOS/Fedora,
$ yum install -y clustercontrol-controller
Schritt sieben
Kopieren Sie die Datei /etc/default/CMON und ändern Sie die IP-Adresse für die RPC-Bindungsadresse
scp /etc/default/CMON 192.168.70.70:/etc/default
RPC_BIND_ADDRESSES="127.0.0.1,10.0.0.103"
Starten Sie dann CMON wie folgt neu,
service CMON restart
Achter Schritt
Ändern Sie /etc/my.cnf und fügen Sie hinzu,
slave-skip-errors = 1062
im Abschnitt [mysqld]. Vergessen Sie nach dem Hinzufügen nicht, mysql neu zu starten als,
service mysql restart
oder
systemctl restart mysql
Derzeit ist dies die Einschränkung, mit der wir bei CMON HA konfrontiert sind, da es versucht, Protokolleinträge in den Slave einzufügen, aber das kann vorerst in Ordnung sein.
Schritt Neun
Überprüfen Sie abschließend, wie die CMON-HA-Knoten aussehen,
[[email protected] ~]# s9s controller --list --long
S VERSION OWNER GROUP NAME IP PORT COMMENT
l 1.7.5.3735 system admins 192.168.70.80 192.168.70.80 9501 Acting as leader.
f 1.7.5.3735 system admins 192.168.70.70 192.168.70.70 9501 Accepting heartbeats.
Total: 2 controller(s)
Bereitstellen Ihres ClusterControl-Knotens in der Cloud
Wie wir bereits erwähnt haben, besteht die ideale Einrichtung für die Kommunikation darin, die Pakete über das VPN oder andere sichere Kanäle zu kapseln. Wenn Sie diesbezüglich Bedenken haben, sehen Sie sich unseren vorherigen Blog Multi-DC PostgreSQL:Einrichten eines Standby-Knotens an einem anderen geografischen Standort über ein VPN an, für den wir uns damit beschäftigt haben, wie Sie mit OpenVPN ein einfaches VPN-Setup erstellen können.
In diesem Abschnitt gehen wir also davon aus, dass Sie die VPN-Verbindung bereits eingerichtet haben. Jetzt werden wir einen Slave hinzufügen, der die Verfügbarkeit von CMON in der Google Cloud Platform verteilen soll. Gehen Sie dazu einfach zu Add Replication Slave, das Sie finden, indem Sie auf das Cluster-Symbol in der Nähe der rechten Ecke klicken. Sehen Sie unten, wie es aussieht:
Nun, so erhalten wir am Ende:
Jetzt, da wir einen neuen Slave hinzugefügt haben, der unter GCP gehostet wird, Möglicherweise müssen Sie erneut dem folgen, was wir zuvor auf dem 2. Knoten getan haben. Ich werde Sie weiterleiten, diesen Schritten zu folgen und den Anweisungen zu folgen, wie wir es auf dem 2. Knoten gemacht haben.
Sobald Sie es richtig gemacht haben, erhalten Sie folgendes Ergebnis:
[[email protected] ~]# s9s controller --list --long
S VERSION OWNER GROUP NAME IP PORT COMMENT
l 1.7.5.3735 system admins 192.168.70.80 192.168.70.80 9501 Acting as leader.
f 1.7.5.3735 system admins 192.168.70.70 192.168.70.70 9501 Accepting heartbeats.
f 1.7.5.3735 system admins 10.142.0.39 10.142.0.39 9501 Accepting heartbeats.
where in nodes
- 192.168.70.80 - (node8) und befindet sich in meinem On-Prem-Bereich
- 192.168.70.70 - (node7) und befindet sich in meinem On-Prem
- 10.142.0.39 – (gnode1) wird auf der GCP und in einer anderen Region gehostet
CMON HA in Aktion
Mein Kollege Krzysztof Ksiazek hat bereits das Setup für HA mit HAProxy hier in diesem Blog bereitgestellt ClusterControl CMON HA für Distributed Database High Availability - Part Two (GUI Access Setup).
Um dem im Blog beschriebenen Verfahren zu folgen, stellen Sie sicher, dass Sie die Pakete xinetd und pathlib haben. Sie können xinetd und pathlib wie folgt installieren,
$ sudo yum install -y xinetd python-pathlib.noarch
Stellen Sie außerdem sicher, dass Sie den CMONhachk in /etc/services genau wie unten definiert haben:
[[email protected] ~]# grep 'CMONhachk' /etc/services
CMONhachk 9201/tcp
und stellen Sie die Änderungen sicher und starten Sie xinetd neu,
service xinetd restart
Ich überspringe die Keepalived- und HAProxy-Prozedur und gehe davon aus, dass Sie entsprechend eingerichtet haben. Eine Erkenntnis, die Sie bei diesem Setup berücksichtigen müssen, ist, dass die Verwendung von Keepalived nicht anwendbar ist, wenn Sie das VIP vom lokalen in das öffentliche Cloud-Netzwerk verteilen, da es sich um ein völlig anderes Netzwerk handelt.
Sehen wir uns nun an, wie CMON HA reagiert, wenn Knoten ausgefallen sind. Wie bereits gezeigt, fungierte der Knoten 192.168.70.80 (Knoten 8) als Leader, genau wie unten gezeigt:
Wobei die Master-Knotendatenbank auch zeigt, dass node8 der Master aus der ClusterControl-Topologieansicht ist . Lassen Sie uns versuchen, node8 zu beenden und sehen, wie CMON HA fortfährt,
Wie Sie sehen, übernimmt gnode1 (GCP-Knoten) die Führung wenn node8 ausfällt. Das Überprüfen der HAProxy-Ergebnisse auf Folgendes:
und unsere ClusterControl-Knoten zeigen, dass node8 ausgefallen ist, während der GCP-Knoten übernimmt als Master vorbei,
Zuletzt Zugriff auf meinen HAProxy-Knoten, der auf Host 192.168.10.100 läuft Port 81 zeigt die folgende Benutzeroberfläche,
Fazit
Unser ClusterControl CMON HA gibt es seit Version 1.7.2, aber es war auch eine Herausforderung für uns, da verschiedene Fragen und Vorlieben, wie man es einsetzt, wie z. B. die Verwendung von MySQL Replication über Galera Cluster, eine Herausforderung darstellten.
Unser CMON HA ist noch nicht ausgereift, aber jetzt bereit, Ihre Hochverfügbarkeitsanforderungen zu erfüllen. Es können verschiedene Ansätze anwendbar sein, solange Ihre Prüfungen den richtigen Knoten ermitteln, der betriebsbereit ist.
Wir empfehlen Ihnen, CMON HA für die Einrichtung und Bereitstellung zu verwenden, und lassen Sie uns wissen, wie gut es Ihren Anforderungen entspricht, oder lassen Sie uns wissen, wie wir Ihnen helfen können, Ihre Hochverfügbarkeitsanforderungen zu erfüllen, wenn das Problem weiterhin besteht.