Het hebben van een installatie met meerdere datacenters is een veelgebruikte topologie voor een Disaster Recovery Plan (DRP), maar er zijn enkele beperkingen bij het implementeren van dit soort omgevingen.
U moet eerst de communicatie tussen de datacenters oplossen door SSH-toegang te gebruiken of een VPN te configureren. Dan hebt u de latentie die (afhankelijk van de configuratie) uw databasecluster kan beïnvloeden. Ten slotte moet u nadenken over het uitvoeren van de failover. Heeft de applicatie toegang tot het externe knooppunt in geval van een masterfout?
In deze blog laten we zien hoe je een multi-datacenter setup voor PostgreSQL kunt implementeren die al deze eerder genoemde punten dekt, waarvan sommige met ClusterControl. Om het niet te saai te maken, splitsen we het op in twee delen. In het eerste deel gaan we in op de connectiviteit tussen de datacenters. De tweede gaat over de implementatie en configuratie zelf, dus laten we beginnen!
Doelstelling
Stel dat je de volgende topologie wilt hebben:
Waar u uw toepassing hebt aangesloten op een load balancer, een primair databaseknooppunt , en één standby-knooppunt in één datacenter en een ander standby-knooppunt in een secundair datacenter voor DR-doeleinden. Dit kan een minimale opzet zijn voor een omgeving met meerdere datacenters. U kunt het gebruik van de load balancer vermijden, maar in geval van failover moet u uw toepassing opnieuw configureren om verbinding te maken met de nieuwe master. punt van mislukking.
Laten we, om het duidelijker te maken, enkele openbare IP-adressen toewijzen aan zowel datacenter 1 als 2 als voorbeeld.
In datacenter 1 is het openbare netwerk 35.166.37.0/24, dus laten we de volgende IP-adressen op deze manier toewijzen:
APP: 35.166.37.10
Load Balancer + ClusterControl: 35.166.37.11
Primary Node: 35.166.37.12
Standby 1 Node: 35.166.37.13In datacenter 2 is het openbare netwerk 18.197.23.0/24, dus:
Standby 2 Node: 18.197.23.14Datacenterconnectiviteit
Het eerste probleem zou dit kunnen zijn. Je kunt er een VPN tussen configureren, en dat moet de veiligste manier zijn, maar aangezien we een VPN-configuratie in een vorige blog hebben besproken, en om het zo kort mogelijk te maken, zullen we ze verbinden via SSH-toegang met behulp van privé/openbare sleutels .
Laten we een gebruiker aanmaken met de naam 'remote' in alle nodes (om het gebruik van root te vermijden):
$ useradd remote
$ passwd remote
Changing password for user remote.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.En je kunt het toevoegen aan het sudoers-bestand om privileges toe te kennen:
$ visudo
remote ALL=(ALL) ALLGenereer nu in de load balancer-server (die ook de ClusterControl-server zal zijn), het sleutelpaar voor de nieuwe gebruiker:
$ 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 homeKopieer de openbare sleutel naar elk knooppunt met behulp van het externe openbare IP-adres:
$ 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.Deze opdracht kopieert uw openbare sleutel naar het externe knooppunt in het bestand Authorized_keys, zodat u er toegang toe krijgt met de privésleutel.
Probeer ze dan te openen:
$ ssh 35.166.37.12Zorg ervoor dat het SSH-verkeer in uw firewall is toegestaan, en om het veiliger te maken, moet u dit alleen toestaan van een bekende bron (bijv. van 35.166.37.0/24).
Als u bijvoorbeeld AWS gebruikt, moet u het verkeer van 35.166.37.0/24 naar de SSH-poort op deze manier toestaan:
Of als u IPTABLES gebruikt, moet u zoiets als dit uitvoeren:
$ iptables -A INPUT -p tcp -s 35.166.37.0/24 --destination-port 22 -j ACCEPTOf een vergelijkbare opdracht als je een andere firewall-oplossing gebruikt.
Om het een beetje veiliger te maken, raden we aan een andere SSH-poort te gebruiken dan de standaardpoort, en het kan ook handig zijn om een tool te gebruiken om meerdere mislukte pogingen om toegang te krijgen, zoals fail2ban.
P>Conclusie
Als alles goed is verlopen, heb je nu SSH-communicatie tussen je datacenters, dus de volgende stap is het implementeren van je PostgreSQL-cluster en het beheren van de failover in geval van storing, zoals we zullen zien in het tweede deel van deze blog.