Redis Cluster: масштабирование до 1TB

Пошаговый практический гайд по проектированию, развёртыванию и масштабированию Redis Cluster для хранения до 1TB данных с учётом репликации и отказоустойчивости. Примерное время выполнения — 3–8 часов в зависимости от окружения и пропускной способности сети.

В конце вы получите рабочий кластер Redis с распределёнными слотами, мониторингом и планом миграции для увеличения объёма хранимых данных до ~1TB с учётом репликации и overhead. Время выполнения базовой установки на 6 нод — 2–3 часа; полная настройка мониторинга и тестов — 4–8 часов.

Шаг 1: topology и sharding

Цель: спроектировать топологию кластера для 1TB данных. В 2026 году рекомендуется держать masters не менее 3 и оптимально 6 для линейного масштабирования. Учтите replication-factor (обычно 1 реплика на мастер) и резервирование дискового пространства.

# Пример топологии (6 мастеров, 6 реплик) — всего 12 нод
# IP:PORT формат
10.0.0.1:7000  # master A
10.0.0.2:7000  # master B
10.0.0.3:7000  # master C
10.0.0.4:7000  # master D
10.0.0.5:7000  # master E
10.0.0.6:7000  # master F
10.0.0.7:7001  # replica A
10.0.0.8:7001  # replica B
10.0.0.9:7001  # replica C
10.0.0.10:7001 # replica D
10.0.0.11:7001 # replica E
10.0.0.12:7001 # replica F

Пояснение: при replication-factor=1 вы получаете 6 мастеров, 6 реплик. Для 1TB данных с overhead (RDB/AOF, фрагментация) рассчитывайте суммарную доступную память мастеров не менее 1.2TB. Если использовать репликацию 1:1, то суммарная оперативная память кластера будет ~2.4TB.

Ожидаемый вывод команды планирования:
# список нод и ролей (пример)
10.0.0.1:7000 master - 5461 slots
10.0.0.2:7000 master - 5461 slots
10.0.0.3:7000 master - 5462 slots
# replicas привязаны к мастерам
10.0.0.7:7001 replica of 10.0.0.1:7000

Типичная ошибка:
# Ошибка при планировании: недостаточно нод для требуемого количества мастеров
Ошибка: "Not enough nodes to create cluster with X masters"

Как исправить:
- Добавьте больше узлов и пересчитайте слоты.
- Убедитесь, что все ноды доступны по сети и порты не блокируются фаерволом.

Шаг 2: настройка нод

Цель: развернуть redis-server 7.2.3 (релиз 2025) на каждой ноде и подготовить systemd unit. Пример конфигурации для порта 7000 приведён ниже.

# Установка на Ubuntu 22.04 (пример, 2025)
sudo apt-get update && sudo apt-get install -y build-essential tcl
wget http://download.redis.io/releases/redis-7.2.3.tar.gz
tar xzf redis-7.2.3.tar.gz && cd redis-7.2.3
make -j4
sudo make install

Пояснение: сборка из исходников гарантирует контроль версии. В production можно использовать репозитории пакетов, но убедитесь в версии 7.2.3 (релиз 2025).

# Пример /etc/redis/7000.conf
port 7000
cluster-enabled yes
cluster-config-file nodes-7000.conf
cluster-node-timeout 15000
appendonly yes
dir /var/lib/redis/7000
logfile /var/log/redis-7000.log
protected-mode no
bind 0.0.0.0
tcp-backlog 511
# Настройка maxmemory для node
maxmemory 32gb
maxmemory-policy volatile-lru

# systemd unit (пример)
[Unit]
Description=Redis In-Memory Data Store (7000)
After=network.target

[Service]
User=redis
Group=redis
ExecStart=/usr/local/bin/redis-server /etc/redis/7000.conf --supervised systemd
ExecStop=/usr/local/bin/redis-cli -p 7000 shutdown
Restart=always

[Install]
WantedBy=multi-user.target

Ожидаемый вывод при старте:
$ sudo systemctl start redis@7000
$ sudo systemctl status redis@7000
● redis@7000.service - Redis In-Memory Data Store (7000)
   Active: active (running) since Wed 2026-05-12 12:34:56 UTC; 2s ago

Типичная ошибка:
Ошибка: "Address already in use" или "Port 7000 already in use"

Как исправить:
- Проверьте, не запущен ли старый экземпляр: sudo ss -ltnp | grep 7000
- Остановите конфликтующий процесс или измените порт в конфигурации.

Шаг 3: failover

Цель: проверить поведение автоматического failover, протестировать принудительное повышение реплики и восстановление мастера. Redis Cluster реализует автоматический failover через голосование реплик и has quorum. Для корректной работы нужен минимум 3 мастера.

# Создание кластера из 6 мастеров и 6 реплик (пример команды, 2026)
redis-cli --cluster create \
  10.0.0.1:7000 10.0.0.2:7000 10.0.0.3:7000 \
  10.0.0.4:7000 10.0.0.5:7000 10.0.0.6:7000 \
  10.0.0.7:7001 10.0.0.8:7001 10.0.0.9:7001 \
  10.0.0.10:7001 10.0.0.11:7001 10.0.0.12:7001 \
  --cluster-replicas 1 --cluster-yes

Пояснение: флаг --cluster-replicas 1 назначает по одной реплике на каждый мастер. Команда автоматически распределяет 16384 слота по мастерам.

Ожидаемый вывод при успешном создании (сокращённо):
>>> Performing hash slots allocation on 6 nodes...
[OK] All 16384 slots covered.
>>> Adding replica 10.0.0.7:7001 to 10.0.0.1:7000
[OK] All nodes configured correctly.
>>> Cluster created successfully

Тестирование failover (принудительное):
# На реплике выполнить принудительный failover
redis-cli -p 7001 CLUSTER FAILOVER FORCE

Ожидаемый вывод:
OK

Типичная ошибка:
ERR Node is not a replica

Как исправить:
- Убедитесь, что нода действительно является репликой: redis-cli -p 7001 INFO replication
- Если реплика синхронизирована, подождите завершения синхронизации или переключите роли вручную с помощью redis-cli --cluster reshard.

Шаг 4: мониторинг и метрики

Цель: собрать метрики с кластера через redis_exporter и Prometheus. Версия exporter: oliver006/redis_exporter v1.46.0+ (2025). Пример развёртывания с Docker приведён ниже.

# Запуск redis_exporter (Docker)
docker run -d --name redis-exporter -p 9121:9121 \
  -e REDIS_ADDR=redis://10.0.0.1:7000 \
  oliver006/redis_exporter:v1.46.0

# Проверка метрик
curl -s http://localhost:9121/metrics | head -n 20

Ожидаемый вывод (фрагмент):
# HELP redis_up Whether Redis is up (1 = yes, 0 = no)
# TYPE redis_up gauge
redis_up 1
# HELP redis_commands_total Total number of commands processed
redis_commands_total 1234567

Типичная ошибка:
curl: (7) Failed to connect to localhost port 9121: Connection refused

Как исправить:
- Проверьте, что контейнер запущен: docker ps | grep redis-exporter
- Убедитесь, что REDIS_ADDR указывает на доступную ноду кластера и порт открыт.

Интеграция с Prometheus: добавьте в prometheus.yml job с endpoint redis-exporter:9121 и создайте дашборд в Grafana по метрикам redis_up, redis_memory_used_bytes, redis_commands_processed.

Шаг 5: масштабирование до 1TB

Цель: добавить новые мастеры и реплики, перераспределить слоты и довести полезную ёмкость хранилища до ~1TB. Пример расчёта: если целевая полезная память мастеров = 1TB, при replication-factor=1 потребуется суммарно ~2TB оперативной памяти в кластере. Следовательно, при node_size 64GB потребуется минимум 32 мастера (практически 16 мастеров + 16 реплик) — но более оптимально использовать узлы по 128GB.

# Добавление новой ноды в существующий кластер
redis-cli --cluster add-node 10.0.1.1:7000 10.0.0.1:7000

Ожидаемый вывод:
>>> Node 10.0.1.1:7000 added correctly as a new node.

Пояснение: после добавления необходимо пересчитать слоты и выполнить reshard. Процесс reshard перемещает слоты с существующих мастеров на новые. Для большой нагрузки используйте параметр --cluster-use-assignments или выполняйте reshard пакетами по 500–2000 слотов. Планируйте операцию на окно с низкой нагрузкой.

# Онлайн-reshard (пример, перенос 2048 слотов)
redis-cli --cluster reshard 10.0.0.1:7000 --cluster-from \
  --cluster-to --cluster-slots 2048 --cluster-yes

Ожидаемый вывод:
>>> Moving 2048 slots
[OK] Finished resharding

Типичная ошибка:
ERR Slot x is busy or served by another node

Как исправить:
- Проверьте состояние кластера: redis-cli -p 7000 CLUSTER INFO
- Убедитесь, что нет активных операций reshard на тех же слотах.
- Если проблема повторяется, разбейте reshard на меньшие пакеты.

Как избежать split brain?

Split brain возникает, когда кластер теряет сетевую связность между частями узлов и начинается независимая работа фракций. Redis Cluster использует простую модель quorum: при обнаружении мастера offline реплики голосуют за промоушен. Основные меры предосторожности:

• Поддерживайте нечетное количество мастеров (3, 5, 7) для корректного голосования.
• Увеличьте cluster-node-timeout до 15000–30000 мс при нестабильной сети, но не слишком высоко, чтобы не увеличивать время обнаружения сбоя.
• Используйте надежную сеть с минимальной задержкой между нодами и отдельные VLAN для cluster bus.
• Включите мониторинг partition и alerting при «cluster_state:fail».

# Проверка конфигурации, предотвращающей split brain
redis-cli -p 7000 CONFIG GET cluster-node-timeout
# Установить значение
redis-cli -p 7000 CONFIG SET cluster-node-timeout 20000

Ожидаемый вывод:
1) "cluster-node-timeout"
2) "20000"

Типичная ошибка:
ERR Changing 'cluster-node-timeout' requires restart

Как исправить:
- Перезапустите ноду после изменения в конфиге: sudo systemctl restart redis@7000
- Планируйте перезапуск вне пикового времени или последовательно по нодам.

Если требуется дополнительная гарантия согласованности в геораспределённых развертываниях, используйте внешние механизмы координации (например, placement-алгоритмы на уровне приложений) или ограничьте число мастеров в каждой зоне доступности.

Как мигрировать данные?

Задача: безопасно перенести данные между кластерами или внутри кластера при добавлении нод. Для онлайн-миграции используйте redis-cli --cluster reshard или специализированные инструменты: redis-shake (Alibaba, версия 2.0+, 2025) или rdb-tools для оффлайн переноса.

# Пример reshard с интерактивным подтверждением (перенос 4096 слотов)
redis-cli --cluster reshard 10.0.0.1:7000

# В интерактивном режиме укажите:
# How many slots do you want to move (from 0 to 16384)? 4096
# Source node(s) (ip:port, ip:port, ...): 10.0.0.2:7000
# Target node: 10.0.1.1:7000

Ожидаемый вывод:
>>> Moving 4096 slots from 10.0.0.2:7000 to 10.0.1.1:7000
[OK] SLOTS MOVED: 4096

Типичная ошибка:
ERR There are keys in slot which are still being served by other nodes

Как исправить:
- Запустите reshard с опцией --cluster-yes после остановки параллельных операций записи.
- Используйте онлайн-инструменты (redis-shake) для последовательной миграции ключей с конверсией типов и контролем RPS.

Если миграция между кластерами производится для нулевого downtime, настройте репликацию между кластерами через redis-shake: запустите инструмент на стороне источника, укажите целевой кластер и включите --pipe for batch transfer. Тестируйте на 10–20% данных перед полным переносом и отслеживайте задержки.

Частые вопросы

Как правильно выбрать число мастеров для Redis Cluster?

Выбор числа мастеров зависит от объёма данных и скорости доступного network I/O. Для 1TB полезной памяти при replication-factor=1 логика такова: если узлы по 128GB полезной памяти на мастер, потребуется примерно 8 мастеров (8 × 128GB = 1TB). Рекомендуется не менее 3 мастеров для обеспечения quorum и оптимально 5 или 7 для продакшена в распределённой среде. Учтите overhead на фрагментацию и резерв (рекомендуется резерв 15–25%). Всегда тестируйте на реплицированной среде и рассчитывайте сетевые потребности: NVMe SSD и 10Gbps сетевые интерфейсы часто необходимы для крупных кластеров в 2025–2026 годах.

Что делать, если при reshard операции наблюдается сильная нагрузка?

Если reshard вызывает высокую задержку, примените стратегию поэтапного перемещения слотов: уменьшите размер пакетов (например, по 500 слотов), назначьте меньший throttle на операцию и выполняйте пересылку вне пиковых нагрузок. Используйте мониторинг redis_exporter и Prometheus для контроля latency и queue. В случае критической нагрузки стоит переключить часть трафика на дополнительные реплики или временно снизить скорость записей с приложений, чтобы завершить пересылку безопасно.

Почему cluster-require-full-coverage влияет на доступность?

Параметр cluster-require-full-coverage (по умолчанию yes) заставляет кластер отвергать запросы, если есть слоты без владельца. Это предотвращает неконсистентные записи, но может сделать сервис недоступным при частичном отключении мастера. В аварийных сценариях можно временно установить его в no, чтобы обеспечить доступ к части данных, но это увеличивает риск расхождения данных и требует ручной синхронизации после восстановления. Решение зависит от SLA и допустимости частичных ответов.

Чем лучше мигрировать данные: redis-cli или redis-shake?

Для простых операций внутри одного кластера (изменение количества мастеров в рамках одного кластера) достаточно redis-cli --cluster reshard. Для миграции между кластерами или при необходимости минимального downtime и преобразования типов удобнее использовать redis-shake (версия 2.x и выше в 2025) — он поддерживает онлайн-репликацию, контроль RPS и перезапись ключей. redis-shake требует настройки и тестирования, но даёт гибкость при сложных сценариях миграции.

Дополнительные материалы по установке и CI/CD инфраструктуре для баз данных доступны в разделах DevOps и Databases на сайте. Для подробных примеров конфигураций systemd и практик резервного копирования смотрите публикации в разделе DevOps.