Redis Sentinel

Да приемем сценарий, при който имате само един екземпляр на Redis във вашата продукция и той се проваля в даден момент поради някаква причина. Приложението ви кешира данни в хранилището на данни на Redis и сега единственият ви източник на данни е мъртъв. Един от начините за контролиране на тези видове сценарии е поддържането на архитектура главен-подчинен, където подчинените устройства могат да репликират главния възел, докато се върне обратно. Redis клъстерите поддържат висока наличност до известна степен с подхода главна реплика. Redis Sentinel е друг подход, който предоставя по-надежден начин за поддържане на висока наличност на екземплярите на Redis. Той следи главния възел на Redis за повреди и незабавно задейства процеса на прехвърляне при отказ, който ще популяризира съществуващ подчинен възел в чисто нов главен.

Освен това Redis sentinel действа като посредник, където клиентите се свързват и искат най-новия IP адрес на главния възел. Така свързаният страж незабавно предоставя адреса на главния възел.

В допълнение, повреда на главния възел се потвърждава, ако множество сентинели са се съгласили, че даден главен не е достъпен или наличен. Това приключва фазата на откриване на повреда и процесът на преход при повреда започва веднага. Следователно Redis sentinel може да се разглежда като разпределена система със специфични свойства.

Споразумението на стражите се основава на стойност на кворума, която ще бъде обсъдена в следващия раздел.

Чия стойност

Стойността на кворума е максималният брой стражи, които трябва да бъдат договорени, когато главният възел не работи. Тази стойност се използва само за идентифициране на повреда в главния възел. Процесът на преместване при срив започва с упълномощаване на множество налични контролни възли, за да продължи с избран страж като водещ.

Характеристики на Redis Sentinel

Sentinel е известен с осигуряването на механизъм за висока наличност за хранилището на данни Redis. Освен това могат да бъдат изброени няколко други възможности.

• Sentinel непрекъснато следи състоянието на главните и подчинените възли във вашата система Redis.
• Всеки път, когато има повреда или нещо нередно с вашите екземпляри на Redis, sentinel е в състояние да уведоми администратора или свързаните приложения, използвайки sentinel API.
• Фазата на отказ се управлява от стража чрез насърчаване на реплика като нов главен. Останалите реплики са конфигурирани да използват новия главен. Накрая, съответните клиенти ще бъдат уведомени за новия адрес на главния възел.
• Също така, Redis sentinel е доставчик на конфигурация за свързаните клиенти, където клиентите могат да поискат адреса на текущо наличния главен екземпляр и ако настъпи внезапен колапс, sentinel се ангажира незабавно да изпрати новия адрес на главния възел.

В следващия раздел ще конфигурираме стражите на Redis с екземпляри на главни реплики и ще използваме API на стражите за наблюдение на възлите.

Конфигурация на Sentinel

Първо създаваме два Redis екземпляра на портове 7000 и 7001. Порт 7000 ще бъде главният възел, а другият ще репликира главния. И двата екземпляра използват съответно следните конфигурационни файлове:

Конфигурация на главния възел

Конфигурация на подчинен възел

И двата екземпляра ще започнат с предоставяне на конфигурационния файл, свързан с всеки от тях. Можем да използваме следната команда, за да стартираме екземпляри на Redis отделно:

Нека се свържем с екземпляра на Redis, стартиран на порт 7001, както следва:

Сега можем да направим този екземпляр реплика на главния, който работи на порт 7000. Командата REPLICAOF може да се използва, както следва:

Както се очакваше, екземплярът, работещ на порт 7001, стана реплика на възела на главния, работещ на порт 7000.

Сега сме готови да конфигурираме три Redis сентинела за наблюдение на горния главен екземпляр. Трябва да имаме три конфигурационни файла, за да създадем три инстанции на sentinel на портове 5000, 5001 и 5002, както е показано по-долу.

всеки sentinel.conf файлът изглежда по следния начин, с изключение на това, че номерът на порта ще бъде променен:

Сега е време да стартирате трите стражи. Можете да използвате изпълнимия файл redis-sentinel заедно с пътя до sentinel.conf конфигурационен файл за създаване на екземпляр на sentinel. В противен случай все още можем да извикаме изпълнимия файл на redis-сървъра, като посочим пътя до sentinel.conf и знамето – страж .

Нека стартираме всеки страж със следната команда:

Първият страж е стартиран на порт 5000. По същия начин можете да стартирате и другите два екземпляра.

Сега нашата настройка на Redis sentinel е готова и работи, както е показано на следната илюстрация:

В следващия раздел ще проучим повече за Sentinel API и как можем да го използваме за извличане на информация, свързана с главния възел на Redis.

API на Sentinel

Redis предоставя отделен API за наблюдение за наблюдение на свързани главни и реплики, абониране за известия и промяна на настройките за наблюдение. Освен това по-долу са изброени няколко употреби.

• Проверете състоянието на наблюдаваните главни и подчинени екземпляри на Redis
• Подробности за други стражи
• Получавайте известия в стил на натискане от стражи в случай на отказ

Командата SENTINEL може да се използва със свързаните с нея подкоманди за запитване, актуализиране или задаване на Redis сентинели и наблюдавани възли.

Проверете състоянието на главния възел

Много е важно да наблюдавате или проверявате здравето на главния възел от време на време. Следната команда на sentinel API може да се използва за извличане на основни детайли:

наблюдавано_главно_име: Името на главния възел, който е посочен в конфигурационния файл на sentinel, който създадохме в по-ранната стъпка.

Нека използваме тази команда, за да направим заявка за главния статус в нашата настройка. В нашия случай името на главния възел е „главен възел“.

Бяха извлечени няколко части от информацията и някои от тях са важни, като например num-slaves, flags и num-other-sentinels.

The знамена свойството е зададено на майстор което означава, че господарят е в добро здраве. Всеки път, когато главният възел не работи, s_down или o_down ще се покаже флаг. Собствеността брой-други-стражи е настроен на 2, което означава, че Redis sentinel вече е разпознал другите два sentinel за главния възел. В допълнение, на брой-роби показва наличните реплики за главния възел. В този случай е зададено на 1, тъй като имаме само една реплика.

Получете информация за свързани реплики

Можем да проверим репликите, свързани с главния възел, като използваме следната подкоманда SENTINEL:

В този пример главното име е „masternode“.

Както се очакваше, Sentinel откри подчинения възел, работещ на порт 7001.

Получете информация за асоциираните Sentinels

По подобен начин можем да направим заявка за подробностите, свързани с други сентинели, свързани с текущия главен възел, като използваме следната подкоманда SENTINEL:

В този случай ще извличаме информацията, свързана с главния възел, наречен „masternode“.

Получете адреса на главния възел

Както бе споменато в по-ранния раздел, Redis sentinel е доставчик на конфигурация за свързани клиенти. Така че той е в състояние да предостави текущо работещия IP адрес и порт на главния възел на заявените клиенти. Следната подкоманда на Sentinel API може да се използва за извличане на споменатата информация.

Нека изпълним горната команда за нашия сценарий, както следва:

Обсъдихме само няколко команди на Sentinel API. Налични са няколко други подкоманди като преход при срив на стража, инфо-кеш на стража, мастери на стража и т.н. Освен това, много команди са достъпни за използване и за административни цели. В следващия раздел ще се съсредоточим върху процеса на отказ на Redis sentinel.

Sentinel Failover процес

Тъй като нашият страж е конфигуриран, можем да тестваме фазата на отказ. Нека изпратим нашия главен възел да заспи за 300 секунди, което симулира повреда в главния възел.

Главният възел, който работи на порт 7000, сега трябва да е недостъпен. Така че свързаните сентинели ще забележат, че главният е недостъпен с +sdown събитие. След това това ще бъде зададено на +odown където 2 сентинела потвърждават, че главният възел не работи според стойността на кворума. Накрая ще започне фазата на отказ и в идеалния случай репликата трябва да бъде повишена до новия главен.

Нека отново проверим IP адреса на главния възел и порта.

Както се очакваше, предишната реплика беше повишена до новия главен, което означава, че процесът на срив на сентинела е успешен. Това приключва внедряването и тестването на нашите три стражеви настройки за единична двойка главен-реплика.

Заключение

Redis sentinel е най-надеждният подход за осигуряване на висока наличност на даден екземпляр на главна реплика на Redis. Sentinel е в състояние да наблюдава, уведомява и инициира автоматичен отказ без човешка намеса. Също така, множество сентинели заедно се съгласяват относно факта, че главният възел е недостижим и стойността на кворума се използва като максимален брой сентинели, които трябва да бъдат съгласувани при проверка за наличност на главния екземпляр. Redis sentinel предлага лесен за използване API за извличане на информация за изправността на главния възел и свързаните реплики, както и за изпълнение на административни задачи.