Как развернуть полноценный кластер Redis? Часть 1

Linux_Deep_22.3_site-5020-ade2e1.png

Здравствуй, $username! В данной статье мы рассмотрим, как развернуть полноценный кластер Redis с отказоустойчивостью и миграцией мастера между нодами в случае его падения. Всё это мы будем делать в кластере Docker SWARM.

Как мы уже знаем, Redis представляет собой базу данных класса NoSQL с открытым исходным кодом и работает со структурой данных типа ключ:значение. Также данный продукт часто используется для хранения кэшей и в качестве брокера сообщений. Redis sentinel предоставляет мониторинг, оповещение и переключение в автоматическом режиме мастера.

Docker swarm является оркестратором, который позволяет управлять, декларативно описывать и обслуживать сервисы (контейнеры). Также он предоставляет встроенный сервис дискавери, при помощи которого все сервисы могут находить друг друга без проблем.

Немного вводной информации по проекту

К нашему кластеру Redis будет подключаться некое приложение, которое будет писать и читать данные. Также это приложение умеет определять, является ли Redis, к которому оно подключилось, мастером, а в случае, если это slave, оно будет переключаться на другой. Кластер Docker swarm состоит из трёх нод (swarm-1, swarm-2, swarm-3); swarm-1 является лидером кластера и на ней будет запущен redis-мастер.

Чтобы определённый контейнер размещался на конкретной ноде, нам необходимо использовать теги. Сделать это можно следующим образом:

docker node update --label-add redis-master=true swarm-1   

--label-add redis-master=true — добавляем тег к нужной ноде, тег представляет собой ключ-значение.

Теги для всего кластера будут такими:

docker node update --label-add redis-master=true swarm-1   
docker node update --label-add redis-slave-1=true swarm-2
docker node update --label-add redis-slave-2=true swarm-3
docker node update --label-add redis-sentinel-1=true swarm-1
docker node update --label-add redis-sentinel-2=true swarm-2
docker node update --label-add redis-sentinel-3=true swarm-3

Посмотреть какие теги установлены на нодах мы можем следующей командой:

docker node ls -q | xargs docker node inspect  -f '{{ .ID }} [{{ .Description.Hostname }}]: {{ .Spec.Labels }}'

Функционала просмотра тегов из коробки нет, поэтому и придётся прибегнуть к таким ухищрениям.

Таким образом, на схеме размещение контейнеров будет следующим: 1111111-20219-3a86df.png

Собираем контейнеры

Теперь пришло время собирать контейнеры с нашими сервисами. Сначала мы создадим Dockerfile для каждого сервиса. За основу мы возьмем Ubuntu 18.04. Dockerfile для redis-master будет следующим:

FROM ubuntu:18.04
RUN apt update && apt upgrade -y && apt install redis-server -y && apt clean
COPY redis.conf /etc/redis/redis.conf
EXPOSE 6379
CMD ["redis-server", "/etc/redis/redis.conf"]

Файл конфигурации будет redis.conf. Он будет выглядеть следующим образом:

bind 0.0.0.0
port 6379

Стоит обратить внимание, что у нас не настроена авторизация в Redis, поэтому к нашему кластеру может подключиться абсолютно любой. Будьте с этим внимательны!

Dockerfile для redis-slave будет аналогичен redis-master:

FROM ubuntu:18.04
RUN apt update && apt upgrade -y && apt install redis-server -y && apt clean
COPY redis.conf /etc/redis/redis.conf
EXPOSE 6379
CMD ["redis-server", "/etc/redis/redis.conf"]

А конфигурация в файле redis.conf будет отличаться:

bind 0.0.0.0
port 6379
slaveof redis-master 6379

slaveof redis-master 6379 — данной директивой мы указываем, к какому мастеру подключаться.   Dockerfile для redis-sentinel будет отличаться от рассмотренных ранее:

FROM ubuntu:18.04
RUN apt update && apt upgrade -y && apt install redis-server -y && apt clean
COPY sentinel.conf /etc/redis/sentinel.conf
EXPOSE 6379
CMD ["redis-server", "/etc/redis/sentinel.conf", "--sentinel"]

Аналогично и файл конфигурации:

bind 0.0.0.0
port 5000
sentinel monitor mymaster redis-master 6379 2
sentinel down-after-milliseconds mymaster 3000
sentinel failover-timeout mymaster 6000
sentinel parallel-syncs mymaster 1

logfile "/var/log/redis/redis-sentinel.log"

В конфигурационном файле указываем, что мы мониторим redis-master, который слушает порт 6379 и будет называть его mymaster. down-after-milliseconds mymaster указываем, через какое время мы считаем, что наш мастер «умер». failover-timeout указываем, через какое время начнёт работать failover. parallel-syncs указываем, сколько реплик будет переконфигурировано. Более подробно с описанием всех опций вы можете ознакомиться здесь.

Во второй части нашей статьи мы продолжим развёртывание полноценного кластера Redis, поэтому не пропустите! И оставляйте комментарии!

Автор
1 комментарий
0

Redis sentinel уже нет смысла использовать, лучше собирать кластер без него, 3 ноды с 3мя мастерами и слейвами.

Для комментирования необходимо авторизоваться