Redis обеспечивает высокую доступность через распределенную систему Redis Sentinel. Sentinel помогает отслеживать экземпляры Redis, обнаруживать сбои и автоматически выполнять переключение ролей, обеспечивая тем самым устойчивость развертывания Redis к любым видам сбоев.
Он предоставляет мониторинг экземпляров Redis (мастер и реплики), поддерживает уведомление других служб/процессов или системного администратора с помощью сценария, автоматическое переключение на реплику в мастер, когда мастер выходит из строя, и предоставляет конфигурацию для клиентов, чтобы найти текущего мастера, предлагающего определенную службу.
В этой статье показано, как настроить Redis для обеспечения высокой доступности с помощью Redis Sentinel в CentOS 8, включая настройку сентинелов, проверку статуса настройки и тестирование сбоя Sentinel.
Предварительные требования:
Настройка тестовой среды
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 sentinel и включить ее автоматический запуск при загрузке системы, используйте следующие команды 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 кворумных Sentinel согласны. Вы можете заменить “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 ДОЛЖНО быть размещено перед утверждением auth-pass Sentinel, чтобы избежать ошибки “Нет такого мастера с указанным именем”, при перезапуске службы Sentinel.
5. Если у мастера Redis, который будет отслеживаться, установлен пароль (в нашем случае мастер имеет пароль), укажите пароль, чтобы экземпляр Sentinel мог аутентифицироваться с защищенным экземпляром.
sentinel auth-pass mymaster Securep@55Here
6. Затем установите количество миллисекунд, в течение которых мастер (или любой подключенный репликатор или Sentinel) должен быть недоступен, чтобы считаться в состоянии “Субъективно недоступен”.
Следующая конфигурация означает, что мастер будет считаться недоступным сразу, как только мы не получим ответ на наши пинги в течение 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. Для получения подробной информации о мастере (называемом 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 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. Это будет отдельная статья от первых двух.
Source:
https://www.tecmint.com/setup-redis-high-availability-with-sentinel-in-centos-8/