Redis Sentinel: пошаговое руководство по настройке отказоустойчивого кластера | AdminWiki
Logo
Timeweb Cloud — сервера, Kubernetes, S3, Terraform. Лучшие цены IaaS.
Попробовать

Redis Sentinel: пошаговое руководство по настройке отказоустойчивого кластера

06 апреля 2026 13 мин. чтения
Содержание статьи

Redis Sentinel — это стандартная система мониторинга и оркестрации, которая автоматизирует восстановление после сбоя мастер-узла в кластере Redis. В отличие от простой master-slave репликации, где падение мастера требует ручного вмешательства и приводит к простою, Sentinel обеспечивает высокую доступность (High Availability, HA) за счет автоматического обнаружения отказа, выбора новой реплики в качестве мастера и переконфигурации остальных узлов. Это решение устраняет необходимость ручного администрирования при инцидентах, минимизирует время простоя критичных сервисов и является обязательным компонентом для production-сред, где важна отказоустойчивость.

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

Что такое Redis Sentinel и зачем он нужен в production

Базовая master-slave репликация Redis решает задачу резервирования данных, но оставляет уязвимость на уровне управления. Если мастер-узел выходит из строя, администратору необходимо вручную: 1) определить новую реплику-кандидата, 2) перевести её в режим мастера командой SLAVEOF NO ONE, 3) перенастроить все остальные реплики на нового мастера. Этот процесс требует времени, чреват ошибками и приводит к простою приложения.

Redis Sentinel решает эту проблему, выступая в роли распределенной системы мониторинга и управления. Его ключевые функции:

  • Мониторинг: Постоянная проверка работоспособности мастер-узла и его реплик.
  • Оповещение: Уведомление администраторов о событиях в кластере через различные каналы.
  • Автоматический failover: При отказе мастера Sentinel самостоятельно выбирает и продвигает новую реплику, а затем переконфигурирует остальные узлы.
  • Конфигурация клиентов: Предоставление клиентским приложениям актуального адреса текущего мастера.

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

Архитектура Sentinel: как распределенные сторожа следят за кластером

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

Принцип работы:

  1. Каждый экземпляр Sentinel мониторит состояние мастер-узла и всех известных ему реплик, отправляя им команды PING с заданным интервалом.
  2. Сентинели также общаются друг с другом, обмениваясь информацией о состоянии узлов и голосуя при принятии решений (например, о начале failover).
  3. Если мастер не отвечает на PING в течение времени, заданного параметром down-after-milliseconds, Sentinel, обнаруживший проблему, помечает его как субъективно недоступный (SDOWN — Subjectively DOWN).
  4. Чтобы избежать ложного срабатывания из-за сетевых проблем на одном хосте, этот Sentinel запрашивает мнение у других. Если достаточное количество (кворум) Sentinel'ов соглашается, что мастер недоступен, состояние меняется на объективный отказ (ODOWN — Objectively DOWN). Только после этого может быть инициирован процесс failover.

Критически важное правило: Экземпляры Sentinel должны быть развернуты на разных физических серверах или, как минимум, в отдельных контейнерах/виртуальных машинах. Запуск Sentinel на том же хосте, что и мониторируемый им узел Redis, сводит на нет отказоустойчивость — падение сервера убьет и узел данных, и его «сторожа».

Подготовка к развертыванию: требования и планирование

Перед началом настройки необходимо спланировать топологию кластера. Минимальная рекомендуемая и надежная конфигурация для production включает:

  • 3 экземпляра Redis: 1 мастер (master) и 2 реплики (slave).
  • 3 экземпляра Sentinel: Размещенных на отдельных серверах от узлов Redis и друг от друга.

Такая схема гарантирует, что отказ одного сервера не приведет к потере кворума Sentinel'ов и кластер сохранит работоспособность.

Требования к сети:

  • Все узлы (Redis и Sentinel) должны иметь статические IP-адреса или резолвящиеся DNS-имена.
  • Между всеми узлами должна быть стабильная сетевая связь. Необходимо настроить брандмауэры, разрешив трафик на порты Redis (по умолчанию 6379) и Sentinel (по умолчанию 26379).

Подготовка Redis: Убедитесь, что на мастер-узле и репликах в конфигурационном файле redis.conf разрешены подключения из сети (bind 0.0.0.0 или конкретный IP) и, при необходимости, настроена аутентификация (requirepass и masterauth с одинаковым паролем на всех узлах).

Правила формирования кворума: почему нужно минимум три Sentinel

Кворум (quorum) — это фундаментальное понятие распределенных систем. В контексте Redis Sentinel это минимальное количество экземпляров Sentinel, которые должны согласиться с тем, что мастер-узел недоступен, чтобы инициировать процесс автоматического переключения (failover).

Параметр quorum задается в конфигурации Sentinel для каждого мониторируемого мастера. Например, строка sentinel monitor mymaster 192.168.1.10 6379 2 означает, что для мастера с именем mymaster кворум равен 2.

  • При 3 работающих Sentinel'ах и quorum=2 для инициации failover нужно, чтобы как минимум 2 из них детектировали отказ мастера (ODOWN).
  • При 5 Sentinel'ах типичный quorum=3.

Почему два Sentinel'а недостаточно? Рассмотрим сценарий сетевого раздела (network partition), когда сеть делится на две изолированные части. Если в каждой части останется по одному Sentinel'у и мастер-узлу (или реплике), оба Sentinel'а, не имея связи друг с другом, могут принять независимое решение о начале failover. Это приведет к ситуации «раскола мозга» (split-brain), когда в разных сегментах сети появятся два активных мастера, что вызовет потерю согласованности данных. Наличие третьего Sentinel'а, который в случае раздела окажется в одной из частей сети, позволяет сохранить кворум только в одной части и предотвратить двойное переключение.

Слишком высокий кворум (например, quorum=5 при 5 Sentinel'ах) делает систему излишне консервативной — для реакции на отказ мастера потребуется согласие практически всех сторожей, что может замедлить реакцию на реальный инцидент.

Пошаговая настройка Redis Sentinel: от конфигурации до запуска

Предположим, у нас есть три сервера с IP-адресами: 192.168.1.10 (мастер), 192.168.1.11 (реплика-1), 192.168.1.12 (реплика-2). Sentinel'ы будут запущены на этих же серверах, но в отдельных процессах. Это допустимо для демонстрации, но помните о рекомендации по раздельному размещению.

Шаг 1: Настройка мастер-узла Redis (192.168.1.10)
В файле /etc/redis/redis.conf убедитесь в наличии или добавьте следующие строки:

bind 192.168.1.10
port 6379
dir /var/lib/redis
# Опционально, для безопасности:
requirepass YourStrongPassword
masterauth YourStrongPassword

Запустите или перезапустите Redis: sudo systemctl restart redis-server.

Шаг 2: Настройка реплик
На серверах 192.168.1.11 и 192.168.1.12 в файлах redis.conf укажите мастер:

bind 192.168.1.11 # Для второго сервера - 192.168.1.12
port 6379
replicaof 192.168.1.10 6379
masterauth YourStrongPassword
requirepass YourStrongPassword

После перезапуска Redis на репликах проверьте статус репликации на мастере командой redis-cli -h 192.168.1.10 INFO replication. В выводе должны появиться connected slaves.

Шаг 3: Настройка и запуск экземпляров Sentinel
На каждом из трех серверов создайте конфигурационный файл, например, /etc/redis/sentinel.conf.

Конфигурационный файл sentinel.conf: разбор ключевых параметров

Приведем пример файла для сервера 192.168.1.10:

port 26379
daemonize yes
logfile "/var/log/redis/sentinel.log"
sentinel monitor mymaster 192.168.1.10 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
# Если на узлах Redis настроен пароль:
sentinel auth-pass mymaster YourStrongPassword

Разбор параметров:

  • sentinel monitor mymaster 192.168.1.10 6379 2: Объявляет мастер с именем mymaster для мониторинга. Указывает исходный IP и порт мастера, а также кворум (quorum=2). После запуска Sentinel самостоятельно обнаружит реплики.
  • sentinel down-after-milliseconds mymaster 5000: Время в миллисекундах, в течение которого мастер не должен отвечать на PING, чтобы быть помеченным данным Sentinel'ом как субъективно недоступный (SDOWN). Значение 5000 (5 секунд) — хороший старт для большинства сред. Слишком малое значение может вызвать ложные срабатывания при сетевых задержках.
  • sentinel failover-timeout mymaster 60000: Общий таймаут в миллисекундах для операций failover. Определяет, как долго Sentinel будет ждать определенных действий (например, переконфигурации реплик) перед тем, как считать операцию неудачной и, возможно, повторить её.
  • sentinel parallel-syncs mymaster 1: Количество реплик, которые могут одновременно синхронизироваться с новым мастером после failover. Синхронизация — ресурсоемкая операция. Установка значения 1 снижает нагрузку на нового мастера. Если у вас много реплик и они не сильно отстают, можно увеличить.

Создайте аналогичные файлы на других серверах. Единственное отличие — в строке sentinel monitor всегда указывается исходный адрес мастера (192.168.1.10), а не локальный IP сервера.

Шаг 4: Запуск Sentinel
На каждом сервере выполните:
redis-sentinel /etc/redis/sentinel.conf
Или, если используете systemd: sudo systemctl start redis-sentinel (предварительно настроив юнит).

Проверка работоспособности кластера после настройки

Подключитесь к любому экземпляру Sentinel с помощью redis-cli:

redis-cli -h 192.168.1.10 -p 26379

Выполните ключевые диагностические команды:

  1. SENTINEL MASTERS: Покажет список всех мониторируемых мастеров (обычно один) с их статусом, адресом, количеством реплик и Sentinel'ов.
  2. SENTINEL SLAVES mymaster: Выведет детальную информацию обо всех известных репликах для мастера mymaster: IP, порт, состояние репликации (lag), флаги.
  3. SENTINEL SENTINELS mymaster: Покажет список других экземпляров Sentinel, мониторящих тот же мастер. Это критически важно — здесь должны отображаться два других Sentinel'а с их IP-адресами и портами. Если их нет, значит, Sentinel'ы не видят друг друга (проблемы с сетью или конфигурацией).

Проверьте, что все узлы в статусе online, а не s_down или o_down.

Как работает автоматический failover: от сбоя до переключения

Рассмотрим детальный сценарий, что происходит в кластере при отказе мастера (192.168.1.10).

  1. Обнаружение SDOWN: Каждый Sentinel отправляет команду PING мастеру каждую секунду. Если в течение down-after-milliseconds (5 сек) ответа нет, Sentinel, обнаруживший это, помечает мастера как субъективно недоступный.
  2. Переход в ODOWN и голосование: Обнаруживший SDOWN Sentinel запрашивает у других Sentinel'ов их мнение о состоянии мастера. Если количество Sentinel'ов, согласных с недоступностью, достигает заданного кворума (в нашем случае 2 из 3), состояние меняется на ODOWN.
  3. Выбор Лидера (Leader): Среди Sentinel'ов, детектировавших ODOWN, выбирается Лидер, который будет управлять конкретным процессом failover для этого мастера. Выбор происходит по алгоритму Raft.
  4. Выбор кандидата в новый мастер: Лидер анализирует список доступных реплик. Он отфильтровывает те, что помечены как отключенные, и выбирает наилучшего кандидата на основе приоритета (параметр slave-priority в redis.conf реплики, по умолчанию 100, чем меньше — тем выше приоритет) и степени отставания репликации (replication offset).
  5. Продвижение реплики: Лидер отправляет выбранной реплике команду SLAVEOF NO ONE, переводя её в режим мастера.
  6. Переконфигурация остальных реплик: После небольшой паузы, чтобы новый мастер успел начать принимать запросы, Лидер отправляет команду SLAVEOF всем остальным репликам, указывая им подключиться к новому мастеру.
  7. Обновление конфигурации и публикация: После успешной переконфигурации все Sentinel'ы обновляют свою внутреннюю конфигурацию, записывая нового мастера. Клиенты, запрашивающие у Sentinel'ов адрес мастера, начнут получать новый IP.

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

Анализ логов Sentinel во время failover: что искать

Логи Sentinel (файл, указанный в logfile) — основной инструмент для понимания происходящего. Вот типичные записи во время failover:

  • +sdown / -sdown: Узел перешел в состояние SDOWN или вышел из него.
  • +odown: Кворум достигнут, мастер в состоянии ODOWN.
  • +vote-for-leader: Sentinel проголосовал за конкретного лидера для failover.
  • +elected-leader: Данный Sentinel был избран лидером.
  • +failover-state-select-slave: Лидер начал этап выбора реплики-кандидата.
  • +selected-slave: Реплика выбрана.
  • +failover-state-send-slaveof-noone: Отправка команды SLAVEOF NO ONE новой реплике.
  • +switch-master: Ключевое событие. Master <old_ip> <old_port> <new_ip> <new_port>. Конфигурация обновлена.
  • +slave-reconf-done: Реплика успешно переконфигурирована на нового мастера.

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

Интеграция Sentinel с приложением: настройка клиентов

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

Принцип работы клиента:

  1. При инициализации клиенту передается список адресов и портов экземпляров Sentinel (например, все три: 192.168.1.10:26379, 192.168.1.11:26379, 192.168.1.12:26379) и имя мастера (mymaster).
  2. Клиент поочередно опрашивает Sentinel'ы, чтобы найти работоспособный.
  3. У работающего Sentinel'а клиент запрашивает команду SENTINEL get-master-addr-by-name mymaster, чтобы получить IP и порт текущего мастера.
  4. Клиент устанавливает соединение с полученным адресом мастера и работает с ним.
  5. В фоновом режиме клиент периодически перепроверяет адрес мастера у Sentinel'ов. Если произошел failover и адрес изменился, клиент автоматически переподключается к новому мастеру, обрабатывая возможные временные ошибки записи во время переключения.

Примеры настройки популярных клиентов:

Python (redis-py):

from redis.sentinel import Sentinel

sentinel_hosts = [('192.168.1.10', 26379),
                  ('192.168.1.11', 26379),
                  ('192.168.1.12', 26379)]
sentinel = Sentinel(sentinel_hosts, socket_timeout=0.5)

# Получение соединения с мастером
master = sentinel.master_for('mymaster', socket_timeout=0.5, password='YourStrongPassword')
master.set('foo', 'bar')

# Получение соединения с репликой для чтения
slave = sentinel.slave_for('mymaster', socket_timeout=0.5, password='YourStrongPassword')
value = slave.get('foo')

Java (Jedis):

Set<String> sentinels = new HashSet<>();
sentinels.add("192.168.1.10:26379");
sentinels.add("192.168.1.11:26379");
sentinels.add("192.168.1.12:26379");

JedisSentinelPool pool = new JedisSentinelPool("mymaster", sentinels, "YourStrongPassword");
try (Jedis jedis = pool.getResource()) {
    jedis.set("foo", "bar");
}

Важно: Настройте адекватные таймауты подключения и повторные попытки на стороне приложения, так как во время кратковременного failover (10-30 сек) операции могут завершаться ошибками.

Мониторинг и эксплуатация отказоустойчивого кластера

После развертывания кластер требует наблюдения. Ключевые метрики для мониторинга:

  • Состояние узлов Redis: Мастер и реплики в статусе up.
  • Количество подключенных Sentinel'ов: Должно равняться ожидаемому (в нашем случае 3). Команда: SENTINEL SENTINELS mymaster.
  • Количество реплик: Команда: SENTINEL SLAVES mymaster.
  • Lag репликации: В выводе SENTINEL SLAVES смотрите параметр master-link-status (должен быть ok) и master-last-io-seconds-ago (отставание в секундах, должно быть небольшим).
  • События Sentinel: Мониторинг логов на наличие событий +sdown, +odown, +switch-master. Их можно отправлять в системы алертинга (например, Prometheus Alertmanager).

Для интеграции с Prometheus можно использовать экспортеры, такие как redis_exporter, который умеет собирать метрики как с узлов Redis, так и с экземпляров Sentinel.

Типичные проблемы и их решение:

  • «Sentinel не видит других sentinel'ов»: Проверьте сетевую связность между хостами на порту 26379 (команда telnet или nc). Убедитесь, что брандмауэры разрешают трафик. В конфигурации Sentinel убедитесь, что указан правильный bind адрес (или 0.0.0.0).
  • «Реплика не подключается к новому мастеру после failover»: Частая причина — несовпадение пароля masterauth на реплике с паролем requirepass на новом мастере. Убедитесь, что все узлы используют одинаковый пароль. Также проверьте сетевую доступность.
  • «Клиентское приложение не переключается на нового мастера»: Убедитесь, что клиентская библиотека поддерживает Sentinel и настроена с правильным списком адресов. Проверьте логи приложения на наличие ошибок подключения.

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

Добавление новой реплики в работающий кластер

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

  1. Настройте новый сервер с Redis, указав в его redis.conf текущего мастера (используйте команду replicaof <текущий_IP_мастера> 6379) и правильный masterauth.
  2. Запустите Redis на новом сервере.
  3. Sentinel'ы автоматически обнаружат новую реплику в течение нескольких циклов мониторинга (обычно менее минуты). Вы можете убедиться в этом, выполнив SENTINEL SLAVES mymaster — в списке появится новый узел.
  4. Если автоматическое обнаружение не сработало, можно вручную добавить реплику в мониторинг любого Sentinel'а командой: SENTINEL MONITOR mymaster <IP_новой_реплики> 6379 <quorum>. Однако это требуется редко.

Для комплексного мониторинга всей инфраструктуры, включая Redis, ознакомьтесь с руководством по созданию системы мониторинга производительности на основе Prometheus и Grafana.

Резюме: лучшие практики и итоги

Redis Sentinel — это зрелое и надежное решение для обеспечения высокой доступности кластеров Redis в production-средах. Резюмируем ключевые практики для его успешного внедрения:

  1. Минимальная топология: Всегда разворачивайте минимум 3 экземпляра Sentinel на разных физических хостах или в зонах доступности. Используйте минимум 1 мастер и 2 реплики для данных.
  2. Правильные таймауты: Настройте down-after-milliseconds и failover-timeout в соответствии с характеристиками вашей сети (задержки) и инфраструктуры. Тестируйте failover на staging-среде.
  3. Безопасность: Используйте парольную аутентификацию (requirepass/masterauth) и, по возможности, зашифруйте трафик между узлами.
  4. Мониторинг и алертинг: Настройте сбор метрик состояния узлов, количества Sentinel'ов и отставания репликации. Настройте алерты на события +sdown и +switch-master.
  5. Понимание процесса: Изучите логи Sentinel во время тестового failover. Это даст уверенность в работоспособности системы и поможет в будущей диагностике.

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

Поделиться:
Сохранить гайд? В закладки браузера