Implementera en Multi-Datacenter Setup för PostgreSQL - Del ett

Att ha en multidatacenterinstallation är en vanlig topologi för en Disaster Recovery Plan (DRP), men det finns vissa begränsningar kring implementering av den här typen av miljö.

Du bör först lösa kommunikationen mellan datacentren genom att använda SSH-åtkomst eller konfigurera ett VPN. Sedan har du latensen som (beroende på konfigurationen) kan påverka ditt databaskluster. Slutligen bör du tänka på hur du ska utföra failover. Kan programmet komma åt fjärrnoden i händelse av masterfel?

I den här bloggen kommer vi att visa hur man implementerar en multidatacenterinstallation för PostgreSQL som täcker alla dessa punkter som nämnts tidigare, några av dem med ClusterControl. För att inte göra det för tråkigt kommer vi att dela upp det i två delar. I den första delen kommer vi att täcka uppkopplingen mellan datacentren. Den andra kommer att handla om själva distributionen och konfigurationen, så låt oss börja!

Mål

Låt oss säga att du vill ha följande topologi:

Där du har din applikation ansluten till en lastbalanserare, en primär databasnod , och en standbynod i ett datacenter och en annan standbynod i ett sekundärt datacenter för DR-ändamål. Detta kan vara en minimal inställning för att ha en multi-datacentermiljö. Du kan undvika att använda lastbalanseraren, men i händelse av failover bör du konfigurera om din applikation för att ansluta till den nya mastern, så för att undvika det rekommenderar vi att du använder den, eller till och med använd två av dem (en på varje DC) för att undvika singel. punkt för misslyckande.

För att göra det mer tydligt, låt oss tilldela några offentliga IP-adresser till både datacenter 1 och 2 som ett exempel.

I datacenter 1 är det offentliga nätverket 35.166.37.0/24, så låt oss tilldela följande IP-adresser på det här sättet:

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 är det offentliga nätverket 18.197.23.0/24, så:

Standby 2 Node: 18.197.23.14

Anslutning till datacenter

Det första problemet kan vara detta. Du kan konfigurera ett VPN mellan dem, och det måste vara det säkraste sättet, men eftersom vi behandlade en VPN-konfiguration i en tidigare blogg, och för att göra den så kort som möjligt, kommer vi att ansluta dem via SSH-åtkomst med privata/offentliga nycklar .

Låt oss skapa en användare som heter 'remote' i alla noder (för att undvika att använda root):

$ useradd remote

$ passwd remote

Changing password for user remote.

New password:

Retype new password:

passwd: all authentication tokens updated successfully.

Och du kan lägga till den i sudoers-filen för att tilldela privilegier:

$ visudo

remote    ALL=(ALL)       ALL

Nu, i belastningsbalansservern (som också kommer att vara ClusterControl-servern), generera nyckelparet för den nya användaren:

$ 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

Kopiera den offentliga nyckeln till varje nod med hjälp av den offentliga fjärranslutna IP-adressen:

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

Detta kommando kommer att kopiera din publika nyckel till fjärrnoden i filen authorized_keys, så du kommer åt den med den privata.

Försök sedan att komma åt dem:

$ ssh 35.166.37.12

Se till att du har tillåten SSH-trafik i din brandvägg, och för att göra den säkrare bör du endast tillåta den från en känd källa (t.ex. från 35.166.37.0/24).

Om du till exempel använder AWS bör du tillåta trafik från 35.166.37.0/24 till SSH-porten på detta sätt:

Eller om du använder IPTABLER bör du köra något så här:

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

Eller ett liknande kommando om du använder en annan brandväggslösning.

För att göra det lite säkrare rekommenderar vi att du använder en annan SSH-port än standardporten, och det kan också vara användbart att använda något verktyg för att förbjuda flera misslyckade försök att komma åt den, som fail2ban.

Slutsats

Vid det här laget, om allt gick bra, kommer du att ha SSH-kommunikation mellan dina datacenter, så nästa steg är att distribuera ditt PostgreSQL-kluster och hantera failover i händelse av fel, som vi kommer att se i den andra delen av denna blogg.