Първо, Sentinel не е балансьор на натоварване или прокси за Redis.
Второ, не всички неуспехи са смърт на домакина. Понякога сървърът виси за кратко, понякога мрежовият кабел се изключва и т.н. Поради това, не е добра практика да стартирате Sentinel на същите хостове като вашия Redis екземпляр. Ако използвате Sentinel за управление на отказ, всичко по-малко от три сентинела, работещи на възли, различни от вашия главен и подчинен(и) Redis, иска проблеми.
Sentinel използва механизъм за кворум, за да гласува за отказ и подчинен. С по-малко от двама стражи рискувате да се разделите на мозъка, където два или повече сървъра на Redis смятат, че са господари.
Представете си сценария, при който стартирате два сървъра и пускате сентинел на всеки. Ако загубите такъв, губите надеждна способност за превключване при отказ.
Клиентите се свързват само със Sentinel, за да научат текущата информация за основна връзка. Всеки път, когато клиентът загуби връзка, той повтаря този процес. Sentinel не е прокси за Redis - командите за Redis отиват директно към Redis.
Единствената надеждна причина да стартирате Sentinel с по-малко от три сентинела е откриването на услуга, което означава да не го използвате за управление на отказ.
Помислете за сценария с два хоста:
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis slave + sentinel 2 (Quorum 1)
Ако Host B временно загуби мрежова свързаност към Host A в този сценарий HostB ще се повиши като хозяин. Сега имате:
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis master + sentinel 2 (Quorum 1)
На всички клиенти, които се свързват към Sentinel 2, ще бъде казано, че Host B е главен, докато на клиентите, които се свързват към Sentinel 1, ще бъде казано, че Host A е главен (което, ако имате Sentinels зад балансьор на натоварване, означава половината от вашите клиенти).
По този начин това, което трябва да изпълните, за да получите минимално приемливо надеждно управление на отказ е:
Host A: Redis master
Host B: Redis Slave
Host C: Sentinel 1
Host D: Sentinel 2
Host E: Sentinel 2
Вашите клиенти се свързват със сигналите и получават текущия главен код за екземпляра на Redis (по име), след което се свързват с него. Ако главният умре, връзката трябва да бъде прекъсната от клиента, след което клиентът ще/трябва да се свърже отново със Sentinel и да получи новата информация.
Колко добре всяка клиентска библиотека се справя с това зависи от библиотеката.
В идеалния случай хостовете C,D и E са или на същите хостове, от които се свързвате с Redis (т.е. клиентския хост). или представляват добра извадка ги получих. Основната цел тук е да се уверите, че проверявате откъде трябва да се свържете с Redis. Ако не успеете, ги поставете в същия DC/Rack/Region като клиентите.
Ако искате вашите клиенти да говорят с балансьор на натоварване, опитайте се да поставите Sentinels на тези LB възли, ако е възможно, като добавите допълнителни хостове, които не са LB, ако е необходимо, за да получите нечетен брой сигнали> 2. Изключение от това е, ако вашият клиентските хостове са динамични, тъй като броят им е непостоянен (увеличават се за трафик, намаляват за бавни периоди, например). В този сценарий вие в голяма степен трябва да стартирате вашите Sentinels на хостове, които не са клиентски и не-redis-сървъри.
Имайте предвид, че ако направите това, тогава ще трябва да напишете демон, който следи канала Sentinel PUBSUB за събитието за главен превключвател, за да актуализирате LB - което трябва да конфигурирате да разговаряте само с текущия главен (никога не се опитвайте да говорите и с двамата). Това е повече работа, но използва Sentinel, прозрачен за клиента - който знае само да говори с LB IP/порта.
