Ein Setup mit mehreren Rechenzentren ist eine übliche Topologie für einen Notfallwiederherstellungsplan (DRP), aber es gibt einige Einschränkungen bei der Implementierung dieser Art von Umgebung.
Sie sollten zunächst die Kommunikation zwischen den Rechenzentren lösen, indem Sie einen SSH-Zugang nutzen oder ein VPN konfigurieren. Dann haben Sie die Latenz, die (je nach Konfiguration) Ihren Datenbankcluster beeinträchtigen könnte. Schließlich sollten Sie darüber nachdenken, wie Sie das Failover durchführen. Kann die Anwendung im Falle eines Master-Ausfalls auf den Remote-Knoten zugreifen?
In diesem Blog werden wir zeigen, wie man ein Multi-Datacenter-Setup für PostgreSQL implementiert, das all diese zuvor erwähnten Punkte abdeckt, einige davon mit ClusterControl. Um es nicht zu langweilig zu machen, werden wir es in zwei Teile aufteilen. Im ersten Teil behandeln wir die Konnektivität zwischen den Rechenzentren. Im zweiten geht es um die Bereitstellung und Konfiguration selbst, also fangen wir an!
Ziel
Nehmen wir an, Sie möchten die folgende Topologie haben:
Hier ist Ihre Anwendung mit einem Load Balancer, einem primären Datenbankknoten, verbunden und einen Standby-Knoten in einem Rechenzentrum und einen weiteren Standby-Knoten in einem sekundären Rechenzentrum für DR-Zwecke. Dies könnte eine minimale Einrichtung für eine Umgebung mit mehreren Rechenzentren sein. Sie können die Verwendung des Load Balancers vermeiden, aber im Falle eines Failovers sollten Sie Ihre Anwendung neu konfigurieren, um eine Verbindung zum neuen Master herzustellen. Um dies zu vermeiden, empfehlen wir die Verwendung, oder verwenden Sie sogar zwei davon (eine auf jedem DC), um Single zu vermeiden Punkt des Scheiterns.
Um es klarer zu machen, lassen Sie uns als Beispiel einige öffentliche IP-Adressen sowohl Rechenzentrum 1 als auch 2 zuweisen.
Im Rechenzentrum 1 ist das öffentliche Netzwerk 35.166.37.0/24, also weisen wir die folgenden IP-Adressen auf diese Weise zu:
APP: 35.166.37.10
Load Balancer + ClusterControl: 35.166.37.11
Primary Node: 35.166.37.12
Standby 1 Node: 35.166.37.13Im Rechenzentrum 2 ist das öffentliche Netzwerk 18.197.23.0/24, also:
Standby 2 Node: 18.197.23.14Rechenzentrums-Konnektivität
Das erste Problem könnte dieses sein. Sie können ein VPN zwischen ihnen konfigurieren, und das muss der sicherste Weg sein, aber da wir eine VPN-Konfiguration in einem früheren Blog behandelt haben, und um es so kurz wie möglich zu machen, werden wir sie über SSH-Zugriff mit privaten/öffentlichen Schlüsseln verbinden .
Lassen Sie uns einen Benutzer namens „remote“ in allen Knoten erstellen (um die Verwendung von root zu vermeiden):
$ useradd remote
$ passwd remote
Changing password for user remote.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.Und Sie können es der sudoers-Datei hinzufügen, um Berechtigungen zuzuweisen:
$ visudo
remote ALL=(ALL) ALLGenerieren Sie nun im Load-Balancer-Server (der auch ClusterControl-Server sein wird) das Schlüsselpaar für den neuen Benutzer:
$ su remote
$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/remote/.ssh/id_rsa):
Created directory '/home/remote/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/remote/.ssh/id_rsa.
Your public key has been saved in /home/remote/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:hgVe/unld9+r/Ynk1HM+t089A41bwxFlPYt5/q+ZyL8 [email protected]
The key's randomart image is:
+---[RSA 3072]----+
| . . .=|
| . + oo|
| . o o.o|
| o . . o+o.|
| . S o .oo= |
| . . o =.o|
| . .+.=*|
| [email protected]|
| o=EB/|
+----[SHA256]-----+
Now you will have a new directory in the homeKopieren Sie den öffentlichen Schlüssel auf jeden Knoten unter Verwendung der entfernten öffentlichen IP-Adresse:
$ ssh-copy-id 35.166.37.12
/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/remote/.ssh/id_rsa.pub"
/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
[email protected]'s password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh '35.166.37.12'"
and check to make sure that only the key(s) you wanted were added.Dieser Befehl kopiert Ihren öffentlichen Schlüssel auf den Remote-Knoten in der Datei "authorized_keys", sodass Sie mit dem privaten darauf zugreifen können.
Versuchen Sie dann, darauf zuzugreifen:
$ ssh 35.166.37.12Stellen Sie sicher, dass Sie den SSH-Verkehr in Ihrer Firewall zugelassen haben, und um ihn sicherer zu machen, sollten Sie ihn nur von einer bekannten Quelle zulassen (z. B. von 35.166.37.0/24).
Wenn Sie beispielsweise AWS verwenden, sollten Sie den Datenverkehr von 35.166.37.0/24 zum SSH-Port auf diese Weise zulassen:
Oder wenn Sie IPTABLES verwenden, sollten Sie so etwas ausführen:
$ iptables -A INPUT -p tcp -s 35.166.37.0/24 --destination-port 22 -j ACCEPTOder ein ähnlicher Befehl, wenn Sie eine andere Firewall-Lösung verwenden.
Um es etwas sicherer zu machen, empfehlen wir, einen anderen SSH-Port als den Standardport zu verwenden, und es könnte auch nützlich sein, ein Tool zu verwenden, um mehrere fehlgeschlagene Zugriffsversuche zu sperren, wie fail2ban.
Fazit
Wenn zu diesem Zeitpunkt alles gut gelaufen ist, haben Sie eine SSH-Kommunikation zwischen Ihren Rechenzentren. Der nächste Schritt besteht also darin, Ihren PostgreSQL-Cluster bereitzustellen und das Failover im Falle eines Fehlers zu verwalten, wie wir im zweiten Teil dieses Blogs sehen werden.
