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).
Чтобы запустить службу Sentinel 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, чтобы избежать ошибки Нет такой мастер с указанным именем.» при перезапуске службы Sentinel.
5. Если на мастере Redis, который нужно отслеживать, установлен пароль (в нашем случае он есть на мастере), укажите пароль, чтобы экземпляр Sentinel мог пройти аутентификацию с помощью защищенного экземпляра.
sentinel auth-pass mymaster
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, а также Redis 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 также переписывается/обновляется каждый раз, когда реплика повышается до статуса master во время отработки отказа и каждый раз, когда в настройке обнаруживается новый Sentinel.
Шаг 3. Проверьте статус установки Redis Sentinel
12. Теперь проверьте статус/информацию Sentinel на мастере, используя команду info sentinel следующим образом.
# redis-cli -p 26379 info sentinel
Из вывода команды, как видно на следующем снимке экрана, у нас есть две реплики/ведомые устройства и три часовых.
13. Чтобы отобразить подробную информацию о мастере (называемом mymaster), используйте команду sentinel master.
# redis-cli -p 26379 sentinel master mymaster
14. Чтобы отобразить подробную информацию о подчиненных устройствах и сторожевых устройствах, используйте команду sentinel slaves и 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
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
Судя по выходным данным запроса, новым мастером теперь является replica/slave2 с IP-адресом 10.42.0.34, как показано на следующем снимке экрана.
Вы можете получить больше информации из документации Redis Sentinel. Но если у вас есть какие-либо мысли или вопросы, которыми вы хотите поделиться, форма обратной связи ниже — ваш путь к нам.
Источник: https://ru.linux-console.net/?p=390