Implementace nastavení více datových center pro PostgreSQL – část první

Nastavení více datových center je běžnou topologií plánu obnovy po havárii (DRP), ale implementace tohoto druhu prostředí má určitá omezení.

Nejprve byste měli vyřešit komunikaci mezi datovými centry pomocí přístupu SSH nebo konfigurací VPN. Pak máte latenci, která (v závislosti na konfiguraci) může ovlivnit váš databázový cluster. Nakonec byste se měli zamyslet nad tím, jak provést převzetí služeb při selhání. Může aplikace přistupovat ke vzdálenému uzlu v případě selhání hlavního uzlu?

V tomto blogu si ukážeme, jak implementovat nastavení více datových center pro PostgreSQL pokrývající všechny výše zmíněné body, některé z nich pomocí ClusterControl. Aby to nebylo moc nudné, rozdělíme to na dvě části. V první části se budeme zabývat konektivitou mezi datovými centry. Druhý se bude týkat samotného nasazení a konfigurace, takže začneme!

Cíl

Řekněme, že chcete mít následující topologii:

Pokud máte aplikaci připojenou k vyrovnávání zatížení, primárnímu databázovému uzlu a jeden pohotovostní uzel v jednom datovém centru a další pohotovostní uzel v sekundárním datovém centru pro účely DR. To by mohlo být minimální nastavení pro prostředí s více datovými centry. Můžete se vyhnout použití nástroje pro vyrovnávání zátěže, ale v případě převzetí služeb při selhání byste měli překonfigurovat vaši aplikaci tak, aby se připojovala k novému masteru, takže doporučujeme používat jej, nebo dokonce použít dva z nich (jeden na každém DC), abyste se vyhnuli bod selhání.

Aby to bylo jasnější, přiřaďme jako příklad nějaké veřejné IP adresy jak datovému centru 1, tak 2.

V datacentru 1 je veřejná síť 35.166.37.0/24, takže přiřaďme následující IP adresy tímto způsobem:

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

V datacentru 2 je veřejná síť 18.197.23.0/24, takže:

Standby 2 Node: 18.197.23.14

Připojení datového centra

Prvním problémem by mohl být tento. Můžete mezi nimi nakonfigurovat VPN, a to musí být nejbezpečnější způsob, ale jak jsme se zabývali konfigurací VPN v předchozím blogu, a aby to bylo co nejkratší, propojíme je přes SSH přístup pomocí soukromých/veřejných klíčů .

Pojďme vytvořit uživatele s názvem ‚remote‘ ve všech uzlech (abychom se vyhnuli použití root):

$ useradd remote

$ passwd remote

Changing password for user remote.

New password:

Retype new password:

passwd: all authentication tokens updated successfully.

Můžete jej přidat do souboru sudoers a přidělit mu oprávnění:

$ visudo

remote    ALL=(ALL)       ALL

Nyní na serveru pro vyrovnávání zatížení (který bude také serverem ClusterControl) vygenerujte pár klíčů pro nového uživatele:

$ 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

Zkopírujte veřejný klíč do každého uzlu pomocí vzdálené veřejné IP adresy:

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

Tento příkaz zkopíruje váš veřejný klíč do vzdáleného uzlu v souboru author_keys, takže k němu budete přistupovat pomocí soukromého.

Potom se k nim pokuste dostat:

$ ssh 35.166.37.12

Ujistěte se, že máte ve své bráně firewall povolený provoz SSH, a aby byl bezpečnější, měli byste jej povolit pouze ze známého zdroje (např. z 35.166.37.0/24).

Pokud například používáte AWS, měli byste povolit provoz z 35.166.37.0/24 na port SSH tímto způsobem:

Nebo pokud používáte IPTABLES, měli byste spustit něco takového:

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

Nebo podobný příkaz, pokud používáte jiné řešení brány firewall.

Aby to bylo o něco bezpečnější, doporučujeme použít jiný port SSH, než je výchozí, a také by mohlo být užitečné použít nějaký nástroj, který zakáže více neúspěšných pokusů o přístup, jako je fail2ban.

Závěr

V tuto chvíli, pokud vše proběhlo v pořádku, budete mít SSH komunikaci mezi vašimi datovými centry, takže dalším krokem je nasazení vašeho PostgreSQL clusteru a správa failoveru v případě selhání, jak uvidíme v druhé části tohoto blogu.