Как настроить кластер Redis в Ubuntu 14.04

Введение

Redis — это хранилище данных типа «ключ-значение» с открытым исходным кодом, в котором используется модель хранения в памяти с дополнительной записью на диск для сохранения. Помимо прочего, он включает транзакции, публикацию/подписку и автоматический переход на другой ресурс. Рекомендуется использовать Redis с Linux для производственных сред, но разработчики также упоминают OS X как платформу, на которой они разрабатывают и тестируют. У Redis есть клиенты, написанные на большинстве языков, рекомендуемые из которых размещены на их веб-сайте.

Для производственных сред репликация данных как минимум на двух узлах считается наилучшей практикой. Избыточность позволяет восстановиться в случае сбоя среды, что особенно важно, когда пользовательская база вашего приложения растет.

К концу этого руководства мы настроим две капли Redis в DigitalOcean следующим образом:

• одна капля для главного сервера Redis
• одна капля для подчиненного сервера Redis

Мы также продемонстрируем, как переключиться на подчиненный сервер и настроить его в качестве временного главного.

Не стесняйтесь настраивать более одного подчиненного сервера.

В этой статье основное внимание уделяется настройке кластера Redis master-slave; Чтобы узнать больше о Redis в целом и его базовом использовании в качестве базы данных, см. этот учебник по использованию.

Предпосылки

Хотя это может работать в более ранних выпусках и других дистрибутивах Linux, мы рекомендуем Ubuntu 14.04.

В целях тестирования мы будем использовать небольшие экземпляры, поскольку реальной рабочей нагрузки не требуется, но для производственных сред могут потребоваться серверы большего размера.

• Убунту 14.04 LTS
• Две капли любого размера, который вам нужен; один ведущий и один или несколько подчиненных
• Доступ к вашим компьютерам через SSH с пользователем без полномочий root, как описано в разделе Начальная настройка сервера с Ubuntu 14.04

Шаг 1 — Установите Redis

Начиная с дроплета, на котором будет размещен наш главный сервер, наш первый шаг — установить Redis. Сначала нам нужно добавить репозиторий Redis Криса Ли (как всегда, будьте предельно осторожны при добавлении сторонних репозиториев; мы используем этот репозиторий, потому что его сопровождающий — авторитетная фигура):

sudo add-apt-repository ppa:chris-lea/redis-server

Нажмите ENTER, чтобы принять репозиторий.

Запустите следующую команду, чтобы обновить наши пакеты:

sudo apt-get update

Установите сервер Redis:

sudo apt-get install redis-server

Убедитесь, что Redis запущен и работает:

redis-benchmark -q -n 1000 -c 10 -P 5

Приведенная выше команда говорит, что мы хотим, чтобы redis-benchmark работал в тихом режиме, с 1000 общими запросами, 10 параллельными подключениями и конвейером 5 запросов. Для получения дополнительной информации о выполнении тестов для Redis введите redis-benchmark --help в своем терминале, чтобы распечатать полезную информацию с примерами.

Пусть тест работает. После завершения вы должны увидеть вывод, подобный следующему:

Output
PING_INLINE: 166666.67 requests per second
PING_BULK: 249999.98 requests per second
SET: 249999.98 requests per second
GET: 499999.97 requests per second
INCR: 333333.34 requests per second
LPUSH: 499999.97 requests per second
LPOP: 499999.97 requests per second
SADD: 499999.97 requests per second
SPOP: 499999.97 requests per second
LPUSH (needed to benchmark LRANGE): 499999.97 requests per second
LRANGE_100 (first 100 elements): 111111.12 requests per second
LRANGE_300 (first 300 elements): 27777.78 requests per second
LRANGE_500 (first 450 elements): 8333.33 requests per second
LRANGE_600 (first 600 elements): 6369.43 requests per second
MSET (10 keys): 142857.14 requests per second

Теперь повторите этот раздел для подчиненного сервера Redis. Если вы настраиваете больше дроплетов, вы можете настроить столько подчиненных серверов, сколько необходимо.

На данный момент Redis установлен и работает на наших двух узлах. Если выходные данные какого-либо узла не похожи на то, что показано выше, внимательно повторите процесс настройки и убедитесь, что все предварительные условия соблюдены.

Шаг 2 — Настройте мастер Redis

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

Начнем с нашего мастера.

Откройте /etc/redis/redis.conf в своем любимом текстовом редакторе:

sudo nano /etc/redis/redis.conf

Отредактируйте следующие строки.

Установите разумное значение для таймера проверки активности для TCP:

tcp-keepalive 60

Сделайте сервер доступным для всех в Интернете, закомментировав эту строку:

#bind 127.0.0.1

Учитывая характер Redis и его очень высокие скорости, злоумышленник может подобрать пароль без особых проблем. Именно поэтому мы рекомендуем раскомментировать строку requirepass и добавить сложный пароль (или, желательно, сложную парольную фразу):

requirepass your_redis_master_password

В зависимости от вашего сценария использования вы можете изменить следующую строку или нет. Для целей этого руководства мы предполагаем, что удаление ключа не должно происходить. Раскомментируйте эту строку и установите ее следующим образом:

maxmemory-policy noeviction

Наконец, мы хотим внести следующие изменения, необходимые для резервного копирования данных. Раскомментируйте и/или установите эти строки, как показано ниже:

appendonly yes
appendfilename redis-staging-ao.aof

Сохраните изменения.

Перезапустите службу Redis, чтобы перезагрузить наши изменения конфигурации:

sudo service redis-server restart

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

Теперь, когда у нас есть готовый главный сервер, давайте перейдем к нашей подчиненной машине.

Шаг 3 — Настройте ведомое устройство Redis

Нам нужно внести некоторые изменения, которые позволят нашему подчиненному серверу подключаться к нашему главному экземпляру:

Откройте /etc/redis/redis.conf в своем любимом текстовом редакторе:

sudo nano /etc/redis/redis.conf

Отредактируйте следующие строки; некоторые настройки будут аналогичны мастеру.

Сделайте сервер доступным для всех в Интернете, закомментировав эту строку:

#bind 127.0.0.1

Подчиненному серверу также нужен пароль, чтобы мы могли давать ему команды (например, INFO). Раскомментируйте эту строку и установите пароль сервера:

requirepass your_redis_slave_password

Раскомментируйте эту строку и укажите IP-адрес, по которому можно получить доступ к главному серверу, а затем порт, установленный на этой машине. По умолчанию порт 6379:

slaveof your_redis_master_ip 6379

Раскомментируйте строку masterauth и укажите пароль/кодовую фразу, которую вы установили ранее на главном сервере:

masterauth your_redis_master_password

Теперь сохраните эти изменения и закройте файл. Затем перезапустите службу, как мы это делали на нашем главном сервере:

sudo service redis-server restart

Это повторно инициализирует Redis и загрузит наши измененные файлы.

Подключиться к Redis:

redis-cli -h 127.0.0.1 -p 6379 

Авторизуйтесь с помощью пароля подчиненного сервера:

AUTH your_redis_slave_password

На данный момент мы запускаем функциональный кластер Redis master-slave с правильно настроенными обеими машинами.

Шаг 4 — Проверка репликации Master-Slave

Тестирование нашей установки позволит нам лучше понять поведение наших дроплетов Redis, как только мы захотим начать сценарий поведения при отказе. Что мы хотим сделать сейчас, так это убедиться, что наша конфигурация работает правильно, и наш главный сервер взаимодействует с подчиненными экземплярами Redis.

Сначала мы подключаемся к Redis через наш терминал на главном сервере:

Сначала подключитесь к локальному экземпляру, работающему по умолчанию на порту 6379. Если вы изменили порт, соответствующим образом измените команду.

redis-cli -h 127.0.0.1 -p 6379

Теперь выполните аутентификацию в Redis с паролем, который вы установили при настройке мастера:

AUTH your_redis_master_password

И вы должны получить в ответ OK. Теперь вам нужно только запустить:

INFO

Вы увидите все, что вам нужно знать о главном сервере Redis. Нас особенно интересует раздел #Replication, который должен выглядеть следующим образом:

Output
. . .

# Replication
role:master
connected_slaves:1
slave0:ip=111.111.111.222,port=6379,state=online,offset=407,lag=1
master_repl_offset:407
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:406

. . .

Обратите внимание на строку connected_slaves:1, которая указывает, что наш другой экземпляр общается с главной каплей. Вы также можете видеть, что мы получаем подчиненный IP-адрес вместе с портом, состоянием и другой информацией.

Теперь давайте посмотрим на раздел #Replication на нашей подчиненной машине. Процесс такой же, как и для нашего главного сервера. Войдите в экземпляр Redis, введите команду INFO и просмотрите вывод:

Output
. . .

# Replication
role:slave
master_host:111.111.111.111
master_port:6379
master_link_status:up
master_last_io_seconds_ago:3
master_sync_in_progress:0
slave_repl_offset:1401
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

. . .

Мы видим, что эта машина играет роль ведомого, взаимодействует с главным сервером Redis и не имеет собственных ведомых.

Шаг 5 — Переключитесь на ведомое устройство

Построение этой архитектуры означает, что мы также хотим, чтобы сбои обрабатывались таким образом, чтобы обеспечить целостность данных и минимальное время простоя для нашего приложения. Любой раб может стать хозяином. Во-первых, давайте проверим переключение вручную.

На подчиненной машине мы должны подключиться к экземпляру Redis:

redis-cli -h 127.0.0.1 -p 6379

Теперь выполните аутентификацию в Redis с паролем, который вы установили при настройке подчиненного устройства.

AUTH your_redis_slave_password

Отключить подчиненное поведение:

SLAVEOF NO ONE

Ответ должен быть OK. Теперь введите:

INFO

Найдите раздел # Replication, чтобы найти следующий вывод:

Output
. . .

# Replication
role:master
connected_slaves:0
master_repl_offset:1737
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

. . .

Как мы и ожидали, ведомое устройство превратилось в ведущее и теперь готово принимать соединения с других машин (если они есть). Мы можем использовать его как временную резервную копию, пока мы отлаживаем наш главный мастер-сервер.

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

Это можно легко написать в сценарии, при этом после обнаружения сбоя необходимо выполнить следующие шаги:

• Отправлять все запросы к Redis из приложения на подчиненный компьютер
• На этом подчиненном устройстве выполните команду SLAVEOF NO ONE. Начиная с Redis версии 1.0.0, эта команда указывает подчиненному устройству прекратить репликацию данных и начать действовать как главный сервер.
• На всех оставшихся ведомых устройствах (если они есть) запуск SLAVEOF hostname port даст им указание прекратить репликацию со старого мастера, отказаться от теперь полностью устарели данные и начните репликацию с нового мастера. Обязательно замените имя хоста и порт правильными значениями из недавно повышенного мастера
• После анализа проблемы вы можете вернуться к исходному серверу в качестве главного, если этого требует ваша конкретная настройка.

Есть много способов выполнить шаги, описанные выше. Тем не менее, вы сами должны внедрить адекватное решение для своей среды и убедиться, что оно тщательно протестировано до того, как произойдут какие-либо реальные сбои.

Шаг 6 — Повторное подключение к мастеру

Давайте снова подключимся к исходному главному серверу. На подчиненном сервере войдите в Redis и выполните следующее:

SLAVEOF your_redis_master_ip 6379

Если вы снова запустите команду INFO, вы увидите, что мы вернулись к исходным настройкам.

Заключение

Мы правильно настроили среду, состоящую из двух серверов, один из которых выступает в качестве главного Redis, а другой реплицирует данные в качестве подчиненного. Таким образом, если главный сервер когда-либо отключится или потеряет наши данные, мы будем знать, как переключиться на один из наших подчиненных для восстановления, пока проблема не будет решена.

Следующие шаги могут включать в себя создание сценария автоматической процедуры аварийного переключения или обеспечение безопасной связи между всеми вашими каплями с помощью решений VPN, таких как Tinc. Кроме того, процедуры тестирования и сценарии жизненно важны для проверки ваших конфигураций.

Кроме того, вы должны принять меры предосторожности при развертывании такой установки в производственных средах. Следует изучить страницу документации Redis и иметь четкое представление о том, какая модель безопасности подходит для вашего приложения. Мы часто используем Redis в качестве хранилища сеансов, и содержащаяся в нем информация может быть ценной для злоумышленника. Обычной практикой является доступ к этим машинам только через частную сеть и размещение их за несколькими уровнями безопасности.

Это простая отправная точка, на которой может быть построено ваше хранилище данных; ни в коем случае не исчерпывающее руководство по настройке Redis для использования архитектуры master-slave. Если есть что-то, что, по вашему мнению, должно охватывать это руководство, оставьте комментарии ниже. Для получения дополнительной информации и помощи по этой теме можно начать с вопросов и ответов DigitalOcean.