Implementering af en multi-datacenter-opsætning til PostgreSQL - del 1

At have en multi-datacenter opsætning er en almindelig topologi for en Disaster Recovery Plan (DRP), men der er nogle begrænsninger omkring implementering af denne form for miljø.

Du bør først løse kommunikationen mellem datacentrene ved at bruge SSH-adgang eller konfigurere en VPN. Så har du den latenstid, der (afhængigt af konfigurationen) kan påvirke din databaseklynge. Til sidst bør du tænke over, hvordan du udfører failover. Kan applikationen få adgang til den eksterne node i tilfælde af masterfejl?

I denne blog vil vi vise, hvordan man implementerer en multi-datacenter opsætning til PostgreSQL, der dækker alle disse punkter nævnt tidligere, nogle af dem ved hjælp af ClusterControl. For ikke at gøre det for kedeligt, deler vi det op i to dele. I den første del vil vi dække forbindelsen mellem datacentrene. Den anden vil handle om selve implementeringen og konfigurationen, så lad os starte!

Mål

Lad os sige, at du vil have følgende topologi:

Hvor du har din applikation forbundet til en load balancer, en primær databasenode , og en standby node i et datacenter og en anden standby node i et sekundært datacenter til DR-formål. Dette kunne være en minimal opsætning for at have et multi-datacentermiljø. Du kan undgå at bruge belastningsbalanceren, men i tilfælde af failover bør du omkonfigurere din applikation til at oprette forbindelse til den nye master, så for at undgå det anbefaler vi at bruge den, eller endda bruge to af dem (en på hver DC) for at undgå enkelt fejlpunkt.

For at gøre det mere klart, lad os tildele nogle offentlige IP-adresser til både datacenter 1 og 2 som et eksempel.

I datacenter 1 er det offentlige netværk 35.166.37.0/24, så lad os tildele følgende IP-adresser på denne måde:

APP: 35.166.37.10

Load Balancer + ClusterControl: 35.166.37.11

Primary Node: 35.166.37.12

Standby 1 Node: 35.166.37.13

I datacenter 2 er det offentlige netværk 18.197.23.0/24, så:

Standby 2 Node: 18.197.23.14

Datacenterforbindelse

Det første problem kunne være dette. Du kan konfigurere en VPN mellem dem, og det skal være den mest sikre måde, men da vi dækkede en VPN-konfiguration i en tidligere blog, og for at gøre den så kort som muligt, vil vi forbinde dem via SSH-adgang ved hjælp af private/offentlige nøgler .

Lad os oprette en bruger kaldet 'remote' i alle noderne (for at undgå at bruge root):

$ useradd remote

$ passwd remote

Changing password for user remote.

New password:

Retype new password:

passwd: all authentication tokens updated successfully.

Og du kan tilføje den til sudoers-filen for at tildele privilegier:

$ visudo

remote    ALL=(ALL)       ALL

Gener nu nøgleparret til den nye bruger i load balancer-serveren (som også vil være ClusterControl-serveren):

$ 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 home

Kopiér den offentlige nøgle til hver node ved hjælp af den offentlige eksterne 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.

Denne kommando vil kopiere din offentlige nøgle til den eksterne node i filen authorized_keys, så du får adgang til den ved hjælp af den private.

Prøv derefter at få adgang til dem:

$ ssh 35.166.37.12

Sørg for, at du har tilladt SSH-trafik i din firewall, og for at gøre den mere sikker, bør du kun tillade den fra en kendt kilde (f.eks. fra 35.166.37.0/24).

For eksempel, hvis du bruger AWS, bør du tillade trafikken fra 35.166.37.0/24 til SSH-porten på denne måde:

Eller hvis du bruger IPTABLER, bør du køre noget som dette:

$ iptables -A INPUT -p tcp -s 35.166.37.0/24 --destination-port 22 -j ACCEPT

Eller en lignende kommando, hvis du bruger en anden firewallløsning.

For at gøre det lidt mere sikkert, anbefaler vi at bruge en anden SSH-port end standardporten, og det kan også være nyttigt at bruge et eller andet værktøj til at forbyde flere mislykkede forsøg på at få adgang til den, såsom fail2ban.

Konklusion

På dette tidspunkt, hvis alt gik fint, vil du have SSH-kommunikation mellem dine datacentre, så næste skridt er at implementere din PostgreSQL-klynge og administrere failover i tilfælde af fejl, som vi vil se i anden del af denne blog.