Настройка кластера 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
Проверяем.
