Предположим сценарий, в котором у вас есть только один экземпляр Redis в вашей рабочей среде, и в какой-то момент он выходит из строя по какой-то причине. Ваше приложение кэширует данные в хранилище данных Redis, и теперь ваш единственный источник данных мертв. Одним из способов управления такого рода сценариями является поддержка архитектуры «главный-подчиненный», в которой подчиненные могут копировать главный узел до тех пор, пока он не вернется. Кластеры Redis в некоторой степени поддерживают высокую доступность с помощью подхода мастер-реплика. Redis Sentinel — это еще один подход, обеспечивающий более надежный способ поддержания высокой доступности экземпляров Redis. Он отслеживает сбои главного узла Redis и немедленно запускает процесс аварийного переключения, который переводит существующий подчиненный узел в новый главный узел.
Кроме того, Redis Sentinel действует как посредник, когда клиенты подключаются и запрашивают последний IP-адрес главного узла. Таким образом, подключенный Sentinel немедленно предоставляет адрес главного узла.
Кроме того, отказ главного узла подтверждается, если несколько дозорных согласились, что данный главный узел недоступен или недоступен. На этом этап обнаружения сбоя завершается, и сразу же начинается процесс аварийного переключения. Следовательно, Redis Sentinel можно рассматривать как распределенную систему с определенными свойствами.
Соглашение дозорных основано на значении кворума, которое будет обсуждаться в следующем разделе.
Чья ценность
Значение кворума — это максимальное количество дозорных, которое необходимо согласовать, когда главный узел не работает. Это значение используется только для определения сбоя в главном узле. Процесс отработки отказа начинается с авторизации нескольких доступных дозорных узлов для продолжения работы с выбранным дозорным в качестве лидера.
Особенности Redis Sentinel
Sentinel известен тем, что обеспечивает механизм высокой доступности для хранилища данных Redis. Помимо этого, можно перечислить еще несколько возможностей.
- Sentinel постоянно отслеживает состояние главных и подчиненных узлов в вашей системе Redis.
- Всякий раз, когда происходит сбой или что-то не так с вашими экземплярами Redis, дозорный может уведомить администратора или подключенные приложения с помощью Sentinel API.
- Этап отработки отказа управляется дозорным, продвигая реплику в качестве нового мастера. Остальные реплики настроены на использование нового мастера. Наконец, соответствующие клиенты получат уведомление о новом адресе главного узла.
- Кроме того, Redis Sentinel является поставщиком конфигурации для подключенных клиентов, где клиенты могут запросить адрес доступного в данный момент главного экземпляра, и если произойдет внезапный сбой, Sentinel немедленно отправит новый адрес главного узла.
В следующем разделе мы будем настраивать дозорные Redis с экземплярами мастер-реплика и использовать Sentinel API для мониторинга узлов.
Конфигурация часового
Сначала мы создаем два экземпляра Redis на портах 7000 и 7001. Порт 7000 будет главным узлом, а другой реплицирует главный узел. Оба экземпляра используют следующие файлы конфигурации соответственно:
Конфигурация главного узла
порт 7000с поддержкой кластера нет
файл конфигурации кластера nodes.conf
время ожидания узла кластера 5000
только аппендикс да
Конфигурация ведомого узла
порт 7001с поддержкой кластера нет
файл конфигурации кластера nodes.conf
время ожидания узла кластера 5000
только аппендикс да
Оба экземпляра начнут работу с предоставления файла конфигурации, связанного с каждым. Мы можем использовать следующую команду для запуска экземпляров Redis по отдельности:
redis-сервер redis.conf
Давайте подключимся к экземпляру Redis, запущенному на порту 7001, следующим образом:
Redis-Cli -п 7001
Теперь мы можем сделать этот экземпляр репликой мастера, работающего на порту 7000. Команду REPLICAOF можно использовать следующим образом:
реплика 127.0.0.1 7000
Как и ожидалось, экземпляр, работающий на порту 7001, стал узлом-репликой мастера, работающего на порту 7000.
Теперь мы готовы настроить три Sentinel Redis для мониторинга вышеуказанного главного экземпляра. Нам нужно иметь три файла конфигурации для создания трех экземпляров Sentinel на портах 5000, 5001 и 5002, как показано ниже.
Каждый sentinel.conf файл выглядит следующим образом, за исключением того, что номер порта будет изменен:
порт 5000Мастернода дозорного монитора 127.0.0.1 7000 два
мастернода Sentinel Down-after-Millseconds 5000
Мастернода Sentinel Failover-Timeout 60000
Теперь пришло время запустить трех стражей. Вы можете использовать исполняемый файл redis-sentinel вместе с путем к sentinel.conf файл конфигурации для создания экземпляра Sentinel. В противном случае мы все еще можем вызвать исполняемый файл redis-server, указав путь к sentinel.conf и флаг – часовой .
Давайте запустим каждого часового, используя следующую команду:
redis-сервер sentinel.conf --сентинел
Первый Sentinel был запущен на порту 5000. Таким же образом вы можете запустить и два других экземпляра.
Теперь наша установка Redis Sentinel настроена и работает, как показано на следующем рисунке:
В следующем разделе мы узнаем больше о Sentinel API и о том, как мы можем использовать его для получения информации, связанной с главным узлом Redis.
Сентинел API
Redis предоставляет отдельный Sentinel API для мониторинга связанных мастеров и реплик, подписки на уведомления и изменения настроек Sentinel. Кроме того, несколько вариантов использования перечислены ниже.
- Проверьте состояние отслеживаемых основных и подчиненных экземпляров Redis.
- Подробности о других стражах
- Получать push-уведомления от дозорных в случае аварийного переключения
Команду SENTINEL можно использовать со связанными с ней подкомандами для запроса, обновления или установки контрольных точек Redis и отслеживаемых узлов.
Проверьте статус мастер-узла
Очень важно время от времени контролировать или проверять работоспособность главного узла. Для получения основных сведений можно использовать следующую команду Sentinel API:
СТРАЖНЫЙ МАСТЕР < имя_отслеживаемого_мастера >
имя_отслеживаемого_мастера: Имя главного узла, указанное в файле конфигурации Sentinel, который мы создали на предыдущем шаге.
Давайте используем эту команду для запроса основного статуса в нашей настройке. В нашем случае имя мастер-узла «мастернода».
Мастернода SENTINEL MASTER
Было получено несколько фрагментов информации, и некоторые из них важны, такие как количество подчиненных, флаги и количество других часовых.
флаги свойство установлено на мастер значит, хозяин здоров. Всякий раз, когда главный узел не работает, s_down или же о_вниз флаг будет отображаться. Недвижимость num-other-sentinels установлено значение 2, что означает, что Redis Sentinel уже распознал два других Sentinel для главного узла. В дополнение число рабов Свойство отображает доступные реплики для главного узла. В данном случае установлено значение 1, так как у нас есть только одна реплика.
Получить информацию о подключенных репликах
Мы можем проверить реплики, подключенные к главному узлу, используя следующую подкоманду SENTINEL:
СТРАЖНЫЕ РЕПЛИКАЦИИ < имя_отслеживаемого_мастера >
В этом примере мастер-имя — «мастернода».
SENTINEL копирует мастерноду
Как и ожидалось, Sentinel обнаружил подчиненный узел, работающий на порту 7001.
Получить информацию о связанных Sentinels
Точно так же мы можем запросить детали, относящиеся к другим часовым, связанным с текущим главным узлом, используя следующую подкоманду SENTINEL:
СТРАЖНЫЕ СТРАЖИ < master_node_name >
В этом случае мы будем получать информацию, относящуюся к главному узлу с именем «masternode».
SENTINEL контролирует мастерноду
Получите адрес главного узла
Как упоминалось в предыдущем разделе, Redis sentinel — это поставщик конфигурации для подключенных клиентов. Таким образом, он может предоставить запрошенным клиентам IP-адрес и порт текущего главного узла. Для получения упомянутой информации можно использовать следующую подкоманду Sentinel API.
SENTINEL GET-MASTER-ADDR-BY-NAME < master_node_name >
Давайте выполним приведенную выше команду для нашего сценария следующим образом:
часовой мастернода get-master-addr-by-name
Мы обсудили только несколько команд Sentinel API. Доступны несколько других подкоманд, таких как Sentinel-Failover, Sentinel Info-Cache, Sentinel Masters и т. д. Кроме того, многие команды также доступны для использования в целях администрирования. В следующем разделе мы сосредоточимся на процессе отработки отказа Redis Sentinel.
Отказоустойчивый процесс Sentinel
Поскольку наш дозорный настроен, мы можем протестировать фазу аварийного переключения. Давайте отправим наш главный узел в спящий режим на 300 секунд, что имитирует сбой в главном узле.
отлаживать спать 300
Главный узел, работающий на порту 7000, теперь должен быть недоступен. Таким образом, связанные часовые заметят, что мастер недоступен с +sdown мероприятие. Затем для этого будет установлено значение +odown где 2 дозорных подтверждают, что главный узел не работает в соответствии со значением кворума. Наконец, начнется фаза отработки отказа, и в идеале реплика должна быть повышена до нового мастера.
Давайте еще раз проверим IP-адрес главного узла и порт.
часовой мастернода get-master-addr-by-name
Как и ожидалось, предыдущая реплика была повышена до нового мастера, что означает, что процесс аварийного переключения дозорного узла прошел успешно. На этом развертывание и тестирование наших трех дозорных установок для одной пары мастер-реплика завершается.
Вывод
Redis Sentinel — это наиболее надежный подход к обеспечению высокой доступности данного экземпляра главной реплики Redis. Sentinel способен отслеживать, уведомлять и инициировать автоматическое отключение при сбое без вмешательства человека. Кроме того, несколько дозорных вместе договариваются о том, что главный узел недоступен, и значение кворума используется как максимальное количество дозорных, которое необходимо согласовать при проверке доступности главного экземпляра. Redis Sentinel предлагает простой в использовании API для получения информации о работоспособности главного узла и связанных реплик, а также для выполнения административных задач.