TOC

Как настроить кластер Redis в CentOS 7

Вступление

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

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

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

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

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

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

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

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

Предпосылки

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

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

  • CentOS 7

  • Две капли, любого размера, который вам нужен; один * ведущий * и один или несколько * ведомых (ей) *

  • Доступ к вашим машинам через SSH с пользователем не-root sudo, как описано в Initial Server Setup с CentOS 7

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

Начиная с Droplet, в котором будет размещен наш * главный сервер *, наш первый шаг - установить Redis. Для начала нам нужно включить репозиторий EPEL на нашей машине. Если вы не знакомы с ним, EPEL - это репозиторий Extra Packages for Enterprise Linux, разработанный проектом Fedora с целью предоставления качественных сторонних пакетов для корпоративных пользователей дистрибутивов на основе RHEL.

wget http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm

Если + wget + не распознан, попробуйте запустить + yum install wget + перед вышеуказанной командой.

Теперь запустите:

sudo rpm -ivh epel-release-7-5.noarch.rpm

А теперь введите:

sudo yum -y update

Обратите внимание, что это может занять некоторое время. Теперь вы можете установить Redis на свой компьютер, запустив:

sudo yum install redis -y

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

sudo systemctl start redis.service

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

sudo systemctl status redis.service

Который выводит что-то похожее на:

Output

Наконец, давайте проверим нашу установку Redis, запустив:

redis-cli ping

Это должно вывести + PONG + в качестве ответа. Если это так, то на вашем сервере теперь работает Redis, и мы можем приступить к его настройке. Дополнительный тест для нашей настройки можно выполнить, выполнив:

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

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

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

Output

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

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

Шаг 2 - Настройка Redis Master

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

Давайте начнем с нашего * мастера *.

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

sudo vi /etc/redis.conf

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

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

/etc/redis.conf

tcp-keepalive

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

/etc/redis.conf

bind 127.0.0.1

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

/etc/redis.conf

requirepass

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

/etc/redis.conf

maxmemory-policy

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

/etc/redis.conf

appendonly
appendfilename ""

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

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

sudo systemctl restart redis.service

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

Шаг 3 - Настройте Redis Slave

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

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

sudo vi /etc/redis.conf

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

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

/etc/redis.conf

bind 127.0.0.1

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

/etc/redis.conf

requirepass

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

/etc/redis.conf

slaveof

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

/etc/redis.conf

masterauth

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

sudo systemctl restart redis.service

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

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

redis-cli -h 127.0.0.1 -p

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

AUTH

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

Шаг 4 - Проверьте репликацию «ведущий-ведомый»

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

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

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

redis-cli -h 127.0.0.1 -p

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

AUTH

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

INFO

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

Output. . .

# Replication
role:master
connected_slaves:1
slave0:ip=,port=,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:
master_port:
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

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

AUTH

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

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 +. Начиная с версии 1.0.0 Redis, эта команда сообщает ведомому устройству прекратить репликацию данных и начать действовать как главный сервер

  • На всех остальных ведомых (если они есть) запуск + SLAVEOF + заставит их прекратить репликацию со старого мастера, полностью отбросить устаревшие данные и начать репликацию с нового мастера. Обязательно замените ` и ` на правильные значения от вашего недавно продвинутого мастера

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

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

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

SLAVEOF

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

Заключение

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

Следующие шаги могут включать создание сценариев автоматической процедуры восстановления после отказа или обеспечение безопасной связи между всеми вашими капельками с помощью решений VPN, таких как https://www.digitalocean.com/community/tutorials/how-to-setup-and-configure- ан-OpenVPN-сервера на CentOS-7 [OpenVPN]. Кроме того, процедуры тестирования и сценарии имеют жизненно важное значение для проверки ваших конфигураций.

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

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

Related