Categories: Шпаргалки

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

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

Наши действия будут пошаговыми:

Подготовка системы
Обработка 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 .

Ну, или можно указать прослушивание на всех сетевых интерфейсах:

bind 0.0.0.0

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

systemctl restart keydb

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

ss -tunlp | grep :6379

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

…
tcp LISTEN 0 128 192.168.1.5: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

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

active-replica yes
multi-master yes
replicaof 192.168.1.6 6379
replicaof 192.168.1.7 6379
replicaof 192.168.1.8 6379

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

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

systemctl restart keydb

Проверяем.

admin