TOC

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

Вступление

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

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

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

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

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

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

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

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

Предпосылки

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

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

  • Ubuntu 14.04 LTS

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

  • Доступ к вашим компьютерам через SSH с пользователем не-root sudo, как описано в Initial Настройка сервера с Ubuntu 14.04

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

Начиная с Droplet, в котором будет размещен наш * главный сервер *, наш первый шаг - установить 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

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

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

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

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

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

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

sudo nano /etc/redis/redis.conf

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

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

/etc/redis/redis.conf

tcp-keepalive

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

/etc/redis/redis.conf

bind 127.0.0.1

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

/etc/redis/redis.conf

requirepass

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

/etc/redis/redis.conf

maxmemory-policy

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

/etc/redis/redis.conf

appendonly
appendfilename

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

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

sudo service redis-server restart

Если вы хотите пройти лишнюю милю, вы можете добавить некоторый уникальный контент в базу данных master, следуя разделам * Redis Operations * в https://www.digitalocean.com/community/tutorials/how-to-install-and- use-redis [этот учебник], так что позже мы увидим, как он реплицируется на подчиненный сервер.

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

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

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

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

sudo nano /etc/redis/redis.conf

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

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

/etc/redis/redis.conf

bind 127.0.0.1

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

/etc/redis/redis.conf

requirepass

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

/etc/redis/redis.conf

slaveof

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

/etc/redis/redis.conf

masterauth

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

sudo service redis-server restart

Это повторно инициализирует 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-set-up-an- openvpn-server-on-ubuntu-14-04 [OpenVPN] или https://www.digitalocean.com/community/tutorials/how-to-install-tinc-and-set-up-a-basic-vpn-on -ubuntu-14-04 [Tinc]. Кроме того, процедуры тестирования и сценарии имеют жизненно важное значение для проверки ваших конфигураций.

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

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

Related