Отказоустойчивый кластер Redis + Sentinel
Отказоустойчивый кластер Redis с использованием Sentinel состоит из нескольких компонентов, которые обеспечивают высокую доступность, автоматическое переключение на резервный узел при сбоях и мониторинг состояния кластера. Ключевые части кластера Redis на Sentinel включают:
1. Основные компоненты кластера Redis Sentinel
- Master (мастер) — основной узел Redis, который принимает запросы на запись данных. В любой момент времени в кластере может быть только один мастер.
- Slave (реплики) — один или несколько узлов Redis, которые синхронизируют данные с мастером в режиме «только чтение». Реплики позволяют разгрузить мастер, обрабатывая запросы на чтение.
- Sentinel (Наблюдатели) — службы, которые мониторят состояние узлов Redis (мастеров и реплик). Основная роль Sentinel — обнаруживать сбои и автоматически переключать мастер на одну из реплик в случае недоступности текущего мастера.
2. Назначение компонентов кластера
2.1. Master
- Роль: Мастер узел Redis отвечает за обработку всех операций записи и репликацию данных на реплики.
- Назначение: Единственный источник данных для всех записей. При падении мастера узел Sentinel назначит одну из реплик в качестве нового мастера, а данные продолжат быть доступными.
2.2. Slave (Реплики)
- Роль: Реплики Redis поддерживают копию данных из мастер-узла и могут обслуживать запросы на чтение, разгружая мастер.
- Назначение: Обеспечить высокую доступность данных и балансировку нагрузки на чтение. В случае сбоя мастера одна из реплик может стать новым мастером.
2.3. Sentinel
- Роль: Sentinel отслеживает состояние мастера и реплик и автоматически переключает роли в случае сбоя.
- Назначение:
- Мониторинг: Sentinels отслеживают доступность всех узлов (мастера и реплик).
- Выбор нового мастера: Если мастер недоступен, Sentinels выбирают одну из реплик и продвигают её в новый мастер. Это автоматическое переключение называется failover.
- Настройка клиентов: Sentinels обновляют конфигурацию клиентов (например, указывают новый мастер) после переключения.
- Оповещения: Sentinels могут отправлять уведомления об изменениях состояния узлов Redis (например, уведомление о падении мастера).
3. Механизм работы Redis Sentinel
- Мониторинг узлов: Все узлы Sentinel регулярно проверяют статус мастера и его реплик. Если несколько Sentinel обнаруживают, что мастер недоступен, начинается процесс выбора нового мастера.
- Failover (переключение): Когда мастер выходит из строя, Sentinels запускают процедуру выбора нового мастера из реплик. Реплика с самым большим числом синхронизированных данных становится новым мастером, а другие реплики начинают реплицировать данные от него.
- Кворум (Quorum): Чтобы инициировать переключение на нового мастера, должно быть достигнуто согласие среди определённого числа Sentinel узлов (например, большинство узлов должны согласиться, что мастер недоступен).
- Конфигурация клиента: После переключения Sentinels обновляют информацию о новом мастере для всех подключенных клиентов Redis.
4. Архитектура кластера Redis с Sentinel
- Минимальные требования для отказоустойчивого кластера:
- Минимум один мастер и одна реплика.
- Минимум три узла Sentinel для обеспечения кворума при принятии решений о переключении.
- Архитектура взаимодействия:
- Все Sentinels связаны друг с другом для обмена информацией о состоянии узлов.
- Клиенты могут подключаться к узлам Redis через Sentinels, которые предоставляют информацию о текущем мастере.
- При отказе мастера Sentinels автоматически определяют новый мастер и уведомляют клиентов об изменении.
5. Преимущества Redis Sentinel
- Высокая доступность: Автоматическое переключение мастера позволяет избежать длительных простоев.
- Отказоустойчивость: Кластер продолжает работать даже при выходе из строя одного или нескольких узлов, поскольку реплики принимают роль мастера.
- Масштабируемость на чтение: Реплики могут обрабатывать запросы на чтение, что снижает нагрузку на мастер.
- Автоматическое восстановление: Восстановление после сбоя мастера происходит автоматически, без вмешательства администратора.
Пример сценария работы Redis Sentinel:
- Клиент подключается к мастеру для записи данных.
- Sentinel постоянно мониторит мастер и реплики.
- Если мастер выходит из строя, Sentinel обнаруживает это и инициирует процесс failover.
- Одна из реплик продвигается до роли мастера.
- Клиенты перенастраиваются на работу с новым мастером.
Кластер Redis с Sentinel — это надежное решение для обеспечения высокой доступности и отказоустойчивости. Система Sentinel автоматически управляет мастер-репликацией, переключением и обновлением клиентов при сбоях. Такая архитектура позволяет минимизировать простои и гарантирует, что данные всегда будут доступны, даже в случае отказа мастера.
Развертывание кластера с помощью Ansible
Структура директорий:
1 2 3 4 5 6 7 8 9 10 |
redis-cluster-ansible/ ├── group_vars/ │ └── all.yaml ├── inventory/ │ └── hosts └── templates/ └── redis.conf.j2 └── sentinel.conf.j2 ansible.cfg playbook.yaml |
group_vars/all.yaml
Переменные
1 2 |
redis_password: "redispass" redis_dir: "/var/lib/redis" |
inventory/hosts
Группы хостов, к которым будут применены плейбуки
1 2 3 4 5 6 |
[redis_nodes] redis_master ansible_host=31.128.39.18 ansible_user=root ansible_ssh_private_key_file="/home/dmitry/.ssh/id_ed25519" redis_slave1 ansible_host=31.129.98.136 ansible_user=root ansible_ssh_private_key_file="/home/dmitry/.ssh/id_ed25519" redis_slave2 ansible_host=45.147.179.134 ansible_user=root ansible_ssh_private_key_file="/home/dmitry/.ssh/id_ed25519" |
templates/
В этой папке находятся шаблоны конфигурационных файлов
redis.conf.j2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
# Main part bind 0.0.0.0 {% if inventory_hostname == "redis_master" %} port 6379 requirepass {{ redis_password }} masterauth {{ redis_password }} protected-mode yes tcp-keepalive 0 maxmemory 2gb maxmemory-policy volatile-lru dir {{ redis_dir }} {% else %} port 6379 requirepass {{ redis_password }} masterauth {{ redis_password }} protected-mode yes slaveof {{ hostvars['redis_master'].ansible_host }} 6379 tcp-keepalive 0 maxmemory 2gb maxmemory-policy volatile-lru dir {{ redis_dir }} {% endif %} |
Основные параметры конфигурации
1. bind 0.0.0.0
- Описание: Redis будет привязан ко всем сетевым интерфейсам, доступным на машине. Это позволяет принимать запросы от любых клиентов, подключающихся по IP.
- Назначение: Открытие Redis для внешних соединений, а не только для локальных (если вы хотите ограничить доступ, можно заменить на конкретный IP).
2. Условное разделение на мастер и реплику
- С помощью условного оператора Jinja2
if
, шаблон определяет, является ли текущий узел мастером (inventory_hostname == "redis_master"
) или репликой. inventory_hostname
— это переменная Ansible, которая указывает на имя текущего узла, с которым Ansible работает.- В зависимости от того, является ли узел мастером или репликой, настраиваются соответствующие параметры.
Конфигурация для мастер-узла Redis
Recommended Posts
Шаблон jinja2 для конфига redis sentinel
18.02.2024
Шаблон jinja2 для конфига Redis
17.02.2024