Как настроить Redis для обеспечения высокой доступности с помощью Sentinel в CentOS 8 — часть 2

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

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

В этой статье показано, как настроить Redis для обеспечения высокой доступности с помощью Redis Sentinel в CentOS 8, включая настройку датчиков, проверку состояния установки и тестирование Отработка отказа Sentinel.

Предварительное условие:

Как настроить репликацию Redis (с отключенным режимом кластера) в CentOS 8 — часть 1

Настройка тестовой среды

Master Server and Sentinel1: 10.42.0.247
Redis Replica1 and Sentinel2: 10.42.0.21
Redis Replica2 and Sentinel3: 10.42.0.34

Согласно документации Redis Sentinel, для надежного развертывания необходимо как минимум три экземпляра Sentinel. Учитывая нашу настройку выше, в случае сбоя главного Sentinels2 и Sentinel3 согласятся с ошибкой и смогут авторизовать аварийное переключение, что позволит клиентские операции могут продолжаться.

Шаг 1. Запуск и включение службы Redis Sentinel

1. В CentOS 8 служба Redis Sentinel устанавливается вместе с сервером Redis (что мы уже сделали в Настройка репликации Redis).

Чтобы запустить службу дозорного Redis и включить ее автоматический запуск при загрузке системы, используйте следующие команды systemctl. Также убедитесь, что он запущен и работает, проверив его статус (сделайте это на всех узлах):

systemctl start redis-sentinel
systemctl enable redis-sentinel
systemctl status redis-sentinel

Шаг 2. Настройка Redis Sentinel на всех узлах Redis

2. В этом разделе мы объясним, как настроить Sentinel на всех наших узлах. Служба Sentinel имеет тот же формат конфигурации, что и сервер Redis. Для его настройки используйте самодокументированный файл конфигурации /etc/redis-sentinel.conf.

Сначала создайте резервную копию исходного файла и откройте его для редактирования.

cp /etc/redis-sentinel.conf /etc/redis-sentinel.conf.orig
vi /etc/redis-sentinel.conf

3. По умолчанию Sentinel прослушивает порт 26379, проверьте это на всех экземплярах. Обратите внимание, что параметр bind необходимо оставить закомментированным (или установить значение 0.0.0.0).

port 26379

4. Затем сообщите Sentinel следить за нашим главным и рассматривать его в состоянии «Объективно отключен». только в том случае, если хотя бы 2 стража кворума согласны. Вы можете заменить «mymaster» на собственное имя.

#On Master Server and Sentinel1
sentinel monitor mymaster 127.0.0.1 6379 2

#On Replica1 and Sentinel2
sentinel monitor mymaster 10.42.0.247 6379 2

#On Replica1 and Sentinel3
sentinel monitor mymaster 10.42.0.247 6379 2

Важно! Оператор Sentinel Monitor ДОЛЖЕН быть помещен перед оператором Sentinel auth-pass, чтобы избежать ошибки «Нет такого мастера с указанное имя. ” при перезапуске службы дозора.

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

 
sentinel auth-pass mymaster Securep@55Here

6. Затем установите количество миллисекунд, в течение которых мастер (или любая подключенная реплика или дозорный) должен быть недоступен, чтобы считать его в состоянии «Субъективно отключен».

Следующая конфигурация означает, что мастер будет считаться неисправным, как только мы не получим ответа от наших пингов в течение 5 секунд (1 секунда эквивалентна 1000 миллисекундам).

sentinel down-after-milliseconds mymaster 5000

7. Затем установите время ожидания переключения при сбое в миллисекундах, которое определяет многие вещи (читайте документацию по параметру в файле конфигурации).

sentinel failover-timeout mymaster 180000

8. Затем установите количество реплик, которые можно перенастроить для одновременного использования нового мастера после отработки отказа. Поскольку у нас есть две реплики, мы установим одну реплику, а другая будет повышена до нового мастера.

sentinel parallel-syncs mymaster 1

Обратите внимание, что файлы конфигурации в Redis Replica1 и Sentinel2, а также в Reddis Replica1 и Sentinel2 должны быть идентичными.

9. Затем перезапустите службы Sentinel на всех узлах, чтобы применить последние изменения.

systemctl restart redis-sentinel

10. Затем откройте порт 26379 в брандмауэре на всех узлах, чтобы позволить экземплярам Sentinel начать общение и получать соединения от других >Sentinel, используя firewall-cmd.

firewall-cmd --zone=public --permanent --add-port=26379/tcp
firewall-cmd --reload

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

Например, если вы посмотрите в конец файла конфигурации мастера, вы должны увидеть операторы known-sentinels и known-replica, как показано на следующем снимке экрана.

То же самое должно быть и с replica1 и replica2.

Обратите внимание, что конфигурация Sentinel также перезаписывается/обновляется каждый раз, когда реплика повышается до статуса главной во время отработки отказа, и каждый раз, когда в настройке обнаруживается новый Sentinel.

Шаг 3. Проверьте статус установки Redis Sentinel

12. Теперь проверьте статус/информацию Sentinel на ведущем устройстве с помощью команды info Sentinel следующим образом.

redis-cli -p 26379 info sentinel

Судя по выводам команды, как показано на следующем снимке экрана, у нас есть две реплики/ведомые устройства и три стража.

13. Чтобы отобразить подробную информацию о master (называемом mymaster), используйте команду sentinel master.

redis-cli -p 26379 sentinel master mymaster

14. Чтобы отобразить подробную информацию о подчиненных устройствах и дозорных, используйте команду подчиненные устройства Sentinel и команду sentinel. Sentinels соответственно.

redis-cli -p 26379 sentinel slaves mymaster
redis-cli -p 26379 sentinel sentinels mymaster

15. Затем запросите адрес главного устройства по имени у подчиненных экземпляров с помощью команды sentinel get-master-addr-by-name следующим образом.

Выходные данные должны быть IP-адресом и портом текущего главного экземпляра:

redis-cli -p 26379 sentinel get-master-addr-by-name mymaster

Шаг 4. Проверьте аварийное переключение Sentinel

16. Наконец, давайте проверим автоматическое переключение при сбое в нашей настройке Sentinel. На главном сервере Redis/Sentinel переведите главный сервер Redis (работающий на порту 6379) на 60 секунд. . Затем запросите адрес текущего мастера на репликах/подчиненных устройствах следующим образом.

redis-cli -p 6379
127.0.0.1:6379> AUTH Securep@55Here
127.0.0.1:6379>  debug sleep 60
redis-cli -p 26379 sentinel get-master-addr-by-name mymaster
redis-cli -p 26379 sentinel get-master-addr-by-name mymaster

Судя по результатам запроса, новым главным устройством теперь является реплика/ведомое устройство2 с IP-адресом 10.42.0.34, как показано на следующем снимке экрана.

Дополнительную информацию можно получить из документации Redis Sentinel. Но если у вас есть какие-либо мысли или вопросы, форма обратной связи ниже — это ваш путь к нам.

В следующей и последней части этой серии мы рассмотрим, как настроить кластер Redis в CentOS 8. Это будет независимая статья от первых двух.