Настройка кластера KeyDB

Thank you for reading this post, don't forget to subscribe!

Мы рас­смот­рим при­мер настрой­ки отка­зо­устой­чи­во­го кла­стер из сер­ве­ров KeyDB (ана­лог Redis). Все дей­ствия будут выпол­нять­ся в опе­ра­ци­он­ной систе­ме семей­ства Linux. Под­ра­зу­ме­ва­ет­ся, что у нас уже под­го­тов­ле­ны два сер­ве­ра с уста­нов­лен­ны­ми KeyDB.

Настройка системы

Если в нашей систе­ме исполь­зу­ет­ся бранд­мау­эр, необ­хо­ди­мо открыть пор­ты, на кото­рых слу­ша­ют наши сер­ви­сы KeyDB (по умол­ча­нию 6379). Для раз­ных ути­лит управ­ле­ния бранд­мау­э­ром, наши дей­ствия будут отличаться.

firewalld (обычно, на RPM)

Доба­вить порты:

firewall-cmd --permanent --add-port=6379/tcp

Сохра­нить правила:

firewall-cmd --reload

iptables (обычно, на DEB)

Для добав­ле­ния правила:

iptables -I INPUT -p tcp --dport 6379 -j ACCEPT

Для сохра­не­ния пра­ви­ла мож­но исполь­зо­вать ути­ли­ту iptables-persistent:

apt install iptables-persistent

netfilter-persistent save

Настройка KeyDB

Нам нуж­но убе­дить­ся, что наши сер­ве­ры KeyDB слу­ша­ют запро­сы по сети.

Откры­ва­ем кон­фи­гу­ра­ци­он­ные фай­лы на обо­их серверах:

vi /etc/keydb/keydb.conf

Нахо­дим строку:

bind 127.0.0.1 ::1

… и через запя­тую пере­чис­ля­ем IP-адре­са сете­вых интер­фей­сов сер­ве­ра, на кото­ром он дол­жен при­ни­мать запро­сы. При­ве­дем примеры.

а) На сер­ве­ре 1:

bind 127.0.0.1 ::1 192.168.1.5

б) На сер­ве­ре 2:

bind 127.0.0.1 ::1 192.168.1.6

* под­ра­зу­ме­ва­ет­ся, что для сер­ве­ра 1 исполь­зу­ет­ся IP-адрес 192.168.1.5, а для сер­ве­ра 2 — 192.168.1.6.

Пере­за­пус­ка­ем сервис:

systemctl restart keydb

Гото­во, про­ве­рить, что сер­вер слу­ша­ет нуж­ный адрес мож­но командой:

ss -tunlp | grep :6379

Сре­ди спис­ка мы долж­ны уви­деть что-то на подобие:

Про­ве­рить под­клю­че­ние мож­но с помо­щью ути­ли­ты keydb-cli, попро­бо­вав под­клю­чить­ся с сер­ве­ра 1 к сер­ве­ру 2, например:

keydb-cli -h 192.168.1.6

Мы долж­ны уви­деть что-то на подобие:

Message of the day:
KeyDB has now joined Snap! See the announcement at:  https://docs.keydb.dev/news

192.168.1.6:6379>

Мы гото­вы пере­хо­дить к настрой­ке репликации.

Настройка репликации

Настрой­ка неслож­ная — необ­хо­ди­мо в кон­фи­гу­ра­ци­он­ном фай­ле отре­дак­ти­ро­вать дирек­ти­вы active-replica и replicaof. После пере­за­пу­стить сер­ви­сы. Рас­смот­рим про­цесс подробнее.

Откры­ва­ем кон­фи­гу­ра­ци­он­ные фай­лы на обо­их серверах:

vi /etc/keydb/keydb.conf

Нахо­дим опцию active-replica и при­во­дим ее к виду:

active-replica yes

Сле­ду­ю­щие настрой­ки немно­го отли­ча­ют­ся для раз­ных серверов.

а) На сер­ве­ре 1:

replicaof 192.168.1.6 6379

* где пред­по­ла­га­ет­ся, что 192.168.1.6 — адрес сер­ве­ра 2, а 6379 — порт, на кото­ром слу­ша­ет его keydb.

б) На сер­ве­ре 2:

replicaof 192.168.1.5 6379

* где пред­по­ла­га­ет­ся, что 192.168.1.5 — адрес сер­ве­ра 1, а 6379 — порт, на кото­ром слу­ша­ет его keydb.

После пере­за­пус­ка сер­ви­са запу­стит­ся репли­ка­ция и теку­щие дан­ные будут удалены.

Пере­за­пус­ка­ем сервис:

systemctl restart keydb

Гото­во.

Проверка

Убе­дим­ся, что дан­ные, создан­ные на сер­ве­ре 1 доступ­ны на сер­ве­ре 2. На пер­вом сер­ве­ре под­клю­ча­ем­ся к кон­со­ли keydb:

keydb-cli

Созда­ем ключ-значение:

> set test_key_1 "Test value on server 1"

На вто­ром сер­ве­ре так­же под­клю­ча­ем­ся к кон­со­ли и смот­рим все клю­чи и зна­че­ние для создан­но­го ключа:

keydb-cli

> KEYS *

> get test_key_1

Выпол­ним обрат­ное дей­ствие, что­бы убе­дить­ся в дву­на­прав­лен­ной рабо­те кластера.

Настрой­ка закончена.

Много серверов

Если в нашем кла­сте­ре боль­ше двух нод, то настрой­ка будет немно­го другой.

Откры­ва­ем кон­фи­гу­ра­ци­он­ный файл:

vi /etc/keydb/keydb.conf

При­во­дим настрой­ку кла­сте­ра к виду:

* в нашем при­ме­ре мы доба­ви­ли стро­ку multi-master yes и несколь­ко опций replicaof для ука­за­ния, с каки­ми сер­ве­ра­ми будем выпол­нять репликацию.

Пере­за­пус­ка­ем сервис:

systemctl restart keydb

Про­ве­ря­ем.