Implementacja konfiguracji wielu centrów danych dla PostgreSQL — część pierwsza

Posiadanie konfiguracji z wieloma centrami danych jest powszechną topologią planu odzyskiwania po awarii (DRP), ale istnieją pewne ograniczenia dotyczące wdrażania tego rodzaju środowiska.

Najpierw należy rozwiązać komunikację między centrami danych, korzystając z dostępu SSH lub konfigurując VPN. Następnie masz opóźnienie, które (w zależności od konfiguracji) może wpłynąć na klaster bazy danych. Na koniec powinieneś pomyśleć o tym, jak wykonać przełączanie awaryjne. Czy aplikacja może uzyskać dostęp do węzła zdalnego w przypadku awarii urządzenia głównego?

W tym blogu pokażemy, jak zaimplementować konfigurację wielu centrów danych dla PostgreSQL, obejmującą wszystkie wspomniane wcześniej punkty, niektóre z nich przy użyciu ClusterControl. Aby nie był zbyt nudny, podzielimy go na dwie części. W pierwszej części omówimy łączność między centrami danych. Drugi będzie dotyczył samego wdrożenia i konfiguracji, więc zacznijmy!

Cel

Powiedzmy, że chcesz mieć następującą topologię:

Gdzie aplikacja jest połączona z systemem równoważenia obciążenia, podstawowym węzłem bazy danych oraz jeden węzeł rezerwowy w jednym centrum danych i inny węzeł rezerwowy w pomocniczym centrum danych do celów DR. Może to być minimalna konfiguracja dla środowiska z wieloma centrami danych. Możesz uniknąć używania load balancera, ale w przypadku awarii, powinieneś przekonfigurować swoją aplikację, aby połączyć się z nowym masterem, aby uniknąć korzystania z niego, a nawet użyć dwóch z nich (po jednym na każdym DC), aby uniknąć pojedynczego punkt awarii.

Aby było bardziej jasne, przypiszmy jako przykład kilka publicznych adresów IP do centrum danych 1 i 2.

W centrum danych 1 sieć publiczna to 35.166.37.0/24, więc przypiszmy następujące adresy IP w ten sposób:

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

W centrum danych 2 sieć publiczna to 18.197.23.0/24, więc:

Standby 2 Node: 18.197.23.14

Łączność z centrum danych

Pierwszym problemem może być ten. Możesz skonfigurować VPN między nimi i to musi być najbezpieczniejszy sposób, ale ponieważ omówiliśmy konfigurację VPN w poprzednim blogu i aby była jak najkrótsza, połączymy je przez dostęp SSH za pomocą kluczy prywatnych/publicznych .

Stwórzmy użytkownika o nazwie „zdalny” we wszystkich węzłach (aby uniknąć używania roota):

$ useradd remote

$ passwd remote

Changing password for user remote.

New password:

Retype new password:

passwd: all authentication tokens updated successfully.

I możesz dodać go do pliku sudoers, aby przypisać uprawnienia:

$ visudo

remote    ALL=(ALL)       ALL

Teraz na serwerze równoważenia obciążenia (który będzie jednocześnie serwerem ClusterControl) wygeneruj parę kluczy dla nowego użytkownika:

$ 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

Skopiuj klucz publiczny do każdego węzła przy użyciu zdalnego publicznego adresu IP:

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

To polecenie skopiuje twój klucz publiczny do zdalnego węzła w plikuauthor_keys, więc będziesz mieć do niego dostęp za pomocą prywatnego.

Następnie spróbuj uzyskać do nich dostęp:

$ ssh 35.166.37.12

Upewnij się, że w zaporze zezwala się na ruch SSH i aby był on bezpieczniejszy, należy zezwalać na to tylko ze znanego źródła (np. z 35.166.37.0/24).

Na przykład, jeśli używasz AWS, powinieneś zezwolić na ruch z 35.166.37.0/24 do portu SSH w ten sposób:

Lub jeśli używasz IPTABLES, powinieneś uruchomić coś takiego:

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

Lub podobne polecenie, jeśli używasz innego rozwiązania zapory sieciowej.

Aby uczynić go nieco bezpieczniejszym, zalecamy użycie innego portu SSH niż domyślny, a także może być przydatne użycie jakiegoś narzędzia do zablokowania wielu nieudanych prób uzyskania do niego dostępu, na przykład fail2ban.

Wnioski

W tym momencie, jeśli wszystko poszło dobrze, będziesz mieć komunikację SSH między centrami danych, więc następnym krokiem jest wdrożenie klastra PostgreSQL i zarządzanie przełączaniem awaryjnym w przypadku awarii, jak zobaczymy w drugiej części tego bloga.