Внедряване на настройка с множество центрове за данни за PostgreSQL – част първа

Наличието на настройка с множество центрове за данни е често срещана топология за план за възстановяване при бедствия (DRP), но има някои ограничения относно внедряването на този вид среда.

Първо трябва да разрешите комуникацията между центровете за данни, като използвате SSH достъп или конфигурирате VPN. След това имате латентността, която (в зависимост от конфигурацията) може да повлияе на клъстера на вашата база данни. И накрая, трябва да помислите как да извършите отказ. Може ли приложението да получи достъп до отдалечения възел в случай на повреда на главния?

В този блог ще покажем как да внедрите настройка с множество центрове за данни за PostgreSQL, покриваща всички тези точки, споменати по-рано, някои от които с помощта на ClusterControl. За да не стане прекалено скучно, ще го разделим на две части. В първата част ще разгледаме свързаността между центровете за данни. Вторият ще бъде за самото внедряване и конфигуриране, така че нека започнем!

Цел

Да приемем, че искате да имате следната топология:

Когато приложението ви е свързано с балансьор на натоварване, основен възел на базата данни , и един възел в режим на готовност в един център за данни и друг възел в режим на готовност във вторичен център за данни за целите на DR. Това може да е минимална настройка за среда с множество центрове за данни. Можете да избегнете използването на балансира на натоварването, но в случай на отказ, трябва да преконфигурирате приложението си, за да се свържете с новия главен обект, така че за да избегнете това, препоръчваме да го използвате или дори да използвате два от тях (по един на всеки DC), за да избегнете единични точка на провал.

За да стане по-ясно, нека зададем някои публични IP адреси както на център за данни 1, така и на 2 като пример.

В център за данни 1 публичната мрежа е 35.166.37.0/24, така че нека зададем следните IP адреси по този начин:

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

В център за данни 2 публичната мрежа е 18.197.23.0/24, така че:

Standby 2 Node: 18.197.23.14

Свързване на центъра за данни

Първият проблем може да е този. Можете да конфигурирате VPN между тях и това трябва да е най-сигурният начин, но тъй като разгледахме VPN конфигурация в предишен блог и за да бъде възможно най-кратко, ще ги свържем чрез SSH достъп с помощта на частни/публични ключове .

Нека създадем потребител, наречен „remote“ във всички възли (за да избегнем използването на root):

$ useradd remote

$ passwd remote

Changing password for user remote.

New password:

Retype new password:

passwd: all authentication tokens updated successfully.

И можете да го добавите към sudoers файла, за да зададете привилегии:

$ visudo

remote    ALL=(ALL)       ALL

Сега, в сървъра за балансиране на натоварването (който ще бъде и сървърът на ClusterControl), генерирайте двойката ключове за новия потребител:

$ 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

Копирайте публичния ключ към всеки възел, като използвате отдалечения публичен 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.

Тази команда ще копира вашия публичен ключ на отдалечения възел във файла authorized_keys, така че ще имате достъп до него чрез частния.

След това опитайте да получите достъп до тях:

$ ssh 35.166.37.12

Уверете се, че имате разрешен SSH трафик във вашата защитна стена и за да го направите по-сигурен, трябва да го разрешите само от известен източник (напр. от 35.166.37.0/24).

Например, ако използвате AWS, трябва да разрешите трафика от 35.166.37.0/24 към SSH порта по този начин:

Или ако използвате IPTABLES, трябва да изпълните нещо подобно:

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

Или подобна команда, ако използвате различно решение за защитна стена.

За да го направим малко по-сигурен, препоръчваме да използвате различен SSH порт от този по подразбиране, а също така може да бъде полезно да използвате някакъв инструмент за забрана на множество неуспешни опити за достъп до него, като fail2ban.

Заключение

В този момент, ако всичко е минало добре, ще имате SSH комуникация между вашите центрове за данни, така че следващата стъпка е да разположите вашия PostgreSQL клъстер и да управлявате отказоустойчивостта в случай на неуспех, както ще видим във втората част на този блог.