Настроить Redis Sentinel

Отказоустойчивость хранилищ Redis, работающих с Creatio, обеспечивается при помощи механизма Redis Sentinel. Он предоставляет следующие возможности:

• Мониторинг. Sentinel следит за тем, чтобы главный (Master) и подчиненные (Slave) экземпляры Redis работали корректно.

• Предупреждение. Sentinel может уведомлять администратора о проблемах с экземплярами Redis.

• Автоматическое восстановление работоспособности (failover). Если Master-экземпляр Redis не работает как ожидается, то Sentinel может назначить один из Slave-экземпляров главным, а другие Slave-экземпляры переконфигурировать на работу с новым Master. При этом приложения Creatio, использующие Redis, оповещаются о новом адресе соединения с Redis.

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

• Факт отказа подтверждается только когда несколько экземпляров Sentinel, составляющих кворум, соглашаются с недоступностью Master-экземпляра Redis. Это уменьшает количество ложных отказов.

• Механизм Sentinel работает, даже если некоторые экземпляры Sentinel неработоспособны. Это повышает отказоустойчивость системы.

Особенности Sentinel 

• Для обеспечения отказоустойчивости необходимо не менее трех экземпляров Sentinel, запущенных на разных физических или виртуальных компьютерах. При этом должна быть четкая уверенность, что их отказы вызваны разными причинами.

• Из-за асинхронной репликации распределенная система Sentinel + Redis не гарантирует, что все данные будут сохранены во время отказа.

• Отказоустойчивость настроенной конфигурации должна регулярно проверяться и подтверждаться тестовыми отказами.

• При использовании Docker невозможны некоторые процессы Sentinel, т. к. Docker может перенаправлять порты (описано в блоке "Sentinel, Docker, NAT, and possible issues" документации Sentinel).

Минимальная отказоустойчивая конфигурация Redis Sentinel 

Условные обозначения:

• М1, M2 — Master-экземпляры Redis.

• R1, R2, R3 — Slave-экземпляры Redis (от Replica).

• S1, S2, S3 — экземпляры Sentinel.

• С1 — клиентское приложение (Creatio).

• [M2] — экземпляр, сменивший свою роль (например из Slave на Master).

Рекомендуется использовать конфигурацию минимум с тремя экземплярами Redis и тремя экземплярами Sentinel (подробнее о конфигурации читайте в блоке "Example 2: basic setup with three boxes" документации Sentinel). Эта конфигурация основана на трех узлах (физических или виртуальных компьютерах), каждый из которых содержит запущенные экземпляры Redis и Sentinel (Рис. 1). Два экземпляра Sentinel (S2 и S3) составляют кворум (quorum) — количество экземпляров, необходимых для определения отказа текущего Master-экземпляра Redis.

Рис. 1 — Конфигурация “трех узлов”: quorum = 2

При нормальной работе конфигурации клиентское приложение (Creatio) записывает свои данные в Master-экземпляр M1. Затем эти данные асинхронно реплицируются в Slave-экземпляры R2 и R3.

Если Master-экземпляр Redis M1 становится недоступным, то экземпляры Sentinel S1 и S2 совместно решают, что произошел отказ и начинают процесс восстановления работоспособности (failover). Они назначают один из Slave-экземпляров Redis (R2 или R3) новым Master-экземпляром, с которым продолжает работать клиентское приложение.

Проблема разделения сети 

При потере сетевого соединения существует риск, что клиентское приложение С1 продолжит работать со старым Master-экземпляром Redis M1, в то время как будет назначен новый Master-экземпляр [M2] (Рис. 2).

Рис. 2 — Разделение сети

Подобной ситуации можно избежать, включив опцию остановки записи данных, если Master-экземпляр обнаруживает уменьшение количества Slave-экземпляров. Для этого можно, например, установить следующие значения в конфигурационном файле redis.conf Master-экземпляра Redis:

min-slaves-to-write 1
min-slaves-max-lag 10

В результате Master-экземпляр Redis M1 перестанет принимать данные через 10 секунд, если не сможет их передать как минимум одному Slave-экземпляру. После восстановления работоспособности системы экземплярами Sentinel, составляющими кворум (S2 и S3), клиентское приложение C1 будет переконфигурировано для работы с новым Master-экземпляром [M2].

Системные требования 

Redis является размещаемой в памяти базой данной (in-memory database). Поэтому основным требованием является скорость работы и объем оперативной памяти. Кроме того, поскольку Redis является однопоточным приложением и нагружает только одно ядро процессора, то для работы одного экземпляра Reids необходим узел (физический или виртуальный компьютер) с двухъядерным процессором, как минимум. Экземпляры Sentinel потребляют относительно немного ресурсов и могут работать на одном узле с Redis.

Redis и Sentinel рекомендуется разворачивать на операционных системах Linux.

В таблице приведены рекомендуемые системные требования для одного узла (физической или виртуальной машины) в зависимости от количества пользователей Creatio.

Установить и настроить Redis Sentinel 

Redis Sentinel поставляется вместе с дистрибутивом Redis. Процесс установки описан в документации Redis. Для установки следует использовать новейшую версию Redis на дату релиза Creatio.

Пример настройки конфигурации Redis Sentinel приведен в разделе "A quick tutorial" документации Sentinel.

Настроить Creatio для работы с Redis Sentinel 

Адаптированные библиотеки и настройка ConnectionStrings.config 

Для получения адаптированных библиотек обратитесь в службу технической поддержки Creatio.

В строке соединения "redis" укажите:

• sentinelHosts — перечисленные через запятую адреса и порты экземпляров Sentinel в формате <адрес>:<порт>. Количество может быть любым.

• masterName — имя Master-экземпляра Redis.

Пример строки соединения:

<add name="redis" connectionString="sentinelHosts=localhost:26380,localhost:26381,localhost:26382;masterName=myMaster;scanForOtherSentinels=false;db=1;maxReadPoolSize=10;maxWritePoolSize=500" />

Web.config 

Убедитесь, что в секции appSettings используются рекомендуемые параметры:

• Feature-UseRetryRedisOperation — включает внутренний механизм Creatio для повтора операций с Redis, которые завершились с ошибкой.

• SessionLockTtlSec — срок действия ключа блокировки сессии.

• SessionLockTtlProlongationIntervalSec — период, на который продлевается срок действия ключа блокировки сессии.

Настройки должны иметь следующие значения:

<add key="Feature-UseRetryRedisOperation" value="true" />
<add key="SessionLockTtlSec" value="60" />
<add key="SessionLockTtlProlongationIntervalSec" value="20" />

Убедитесь, что в секции redis используются рекомендуемые параметры:

• enablePerformanceMonitor — включает мониторинг времени выполнения операций с Redis. Рекомендуется включать для отладки и поиска проблем. Значение по умолчанию: По умолчанию выключен т. к. влияет на производительность приложения.

• executionTimeLoggingThresholdSec — операции с Redis, которые выполнялись дольше указанного времени, будут записаны в лог. По умолчанию 5 секунд.

• featureUseCustomRedisTimeouts — включает использование таймаутов, указанных в конфигурационном файле. Значение по умолчанию: “отключена”.

• clientRetryTimeoutMs — завершенные с ошибкой операции с Redis повторяются с тем же клиентом и соединением до истечения периода, заданного этим параметром. Используется для устранения ошибок, вызванных кратковременными перерывами в работе сети. При этом нет необходимости получать из пула нового клиента. По умолчанию 4000 миллисекунд.

• clientSendTimeoutMs — время, выделяемое на отправку запроса серверу Redis. По умолчанию 3000 миллисекунд.

• clientReceiveTimeoutMs — время, выделяемое на получение ответа от сервера Redis. По умолчанию 3000 миллисекунд.

• clientConnectTimeoutMs — время, выделяемое на установку сетевого соединения с сервером Redis. По умолчанию 100 миллисекунд.

• deactivatedClientsExpirySec — задержка удаления сбойных Redis-клиентов после их удаления из пула. 0 означает немедленное удаление. По умолчанию 0.

• operationRetryIntervalMs — если внутренний цикл повтора сбойных операций не привел к успешному выполнению операции, то такая операция откладывается на указанное время. После этого операция выполняется с новым клиентом, который, уже может иметь установленное соединение с новым Master-экземпляром. По умолчанию 1000 миллисекунд.

• operationRetryCount — количество повторных попыток выполнения операции с новым Redis-клиентом. По умолчанию 10.

Настройки должны иметь следующие значения:

<redis connectionStringName="redis" enablePerformanceMonitor="false" executionTimeLoggingThresholdSec="5" featureUseCustomRedisTimeouts="true" clientRetryTimeoutMs="4000" clientReceiveTimeoutMs="3000" clientSendTimeoutMs="3000" clientConnectTimeoutMs="100" deactivatedClientsExpirySec="0" operationRetryIntervalMs="1000" operationRetryCount="10" />