Работа Creatio с Redis Sentinel

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

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

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

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

Важно

Работа с кластером Redis в Creatio не поддерживается.

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

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

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

Содержание

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

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

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

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

•Установка и настройка Redis Sentinel

•Настройка Creatio для работы с Redis 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-экземпляром, с которым продолжает работать клиентское приложение.

Важно

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

На заметку

Другие возможные отказоустойчивые конфигурации описаны в в документации Sentinel.

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

При потере сетевого соединения существует риск, что клиентское приложение С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].

Важно

После остановки master-экземпляр не сможет автоматически продолжить работу, если сеть будет восстановлена. Если оставшийся slave-экземпляр Reids (R3) также станет недоступным, то система полностью прекратит работу.

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

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

Адаптированные библиотеки

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

Файл ConnectionStrings.config

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

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

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

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

<add name="redisSentinel" 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" />

Смотрите также

•Установка Creatio .NET Framework на IIS

•Часто задаваемые вопросы по установке Creatio