Za prvé, Sentinel není nástroj pro vyrovnávání zatížení ani proxy pro Redis.
Za druhé, ne všechna selhání jsou smrtí hostitele. Někdy se server krátce zasekne, někdy se odpojí síťový kabel atd. Protože v tomto případě není dobré spouštět Sentinel na stejných hostitelích jako vaše instance Redis. Pokud ke správě převzetí služeb při selhání používáte Sentinel, cokoliv méně než tři hlídky běžící na jiných uzlech než na vašem hlavním a podřízeném(i) Redisu si žádají potíže.
Sentinel používá mechanismus kvora k hlasování o převzetí služeb při selhání a slave. S méně než dvěma hlídkami riskujete rozdělení mozku, kde si dva nebo více serverů Redis myslí, že jsou pány.
Představte si scénář, kdy provozujete dva servery a na každém z nich spustíte sentinel. Pokud jeden ztratíte, ztratíte spolehlivou schopnost převzetí služeb při selhání.
Klienti se k Sentinelu připojují pouze za účelem zjištění aktuálních informací o hlavním připojení. Kdykoli klient ztratí připojení, tento proces zopakuje. Sentinel není proxy pro Redis – příkazy pro Redis jdou přímo do Redis.
Jediný spolehlivý důvod, proč spouštět Sentinel s méně než třemi hlídkami, je zjišťování služeb, což znamená, že je nepoužíváte pro správu převzetí služeb při selhání.
Zvažte scénář se dvěma hostiteli:
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis slave + sentinel 2 (Quorum 1)
Pokud v tomto scénáři hostitel B dočasně ztratí síťové připojení k hostiteli A, hostitel B se povýší na master. Nyní máte:
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis master + sentinel 2 (Quorum 1)
Všem klientům, kteří se připojí k Sentinelu 2, bude sděleno, že hostitel B je hlavní, zatímco klientům, kteří se připojí k Sentinelu 1, bude sděleno hostiteli A hlavní (což, pokud máte své Sentinely za vyrovnávačem zátěže, znamená polovinu vašich klientů).
To, co tedy musíte spustit, abyste získali minimální přijatelnou spolehlivou správu převzetí služeb při selhání, je:
Host A: Redis master
Host B: Redis Slave
Host C: Sentinel 1
Host D: Sentinel 2
Host E: Sentinel 2
Vaši klienti se připojí k hlídačům a získají aktuálního mastera pro instanci Redis (podle názvu) a poté se k ní připojí. Pokud master zemře, klient by měl připojení přerušit, načež se klient znovu připojí/měl by se připojit k Sentinelu a získat nové informace.
Jak dobře to každá klientská knihovna zvládne, závisí na knihovně.
V ideálním případě jsou hostitelé C, D a E buď na stejných hostitelích, ze kterých se připojujete k Redis (tj. klientský hostitel). nebo představují dobrý vzorek, dostal jsem je. Hlavním cílem je zajistit, že kontrolujete, odkud se potřebujete připojit k Redis. Pokud se tak nestane, umístí je do stejného DC/Rack/Region jako klienty.
Pokud chcete, aby vaši klienti mluvili s nástrojem pro vyrovnávání zátěže, zkuste mít vaše Sentinely na těchto LB uzlech, pokud je to možné, přidáním dalších non-LB hostitelů podle potřeby, abyste získali lichý počet Sentinelů> 2. Výjimkou je, pokud klientské hostitele jsou dynamické v tom, že jejich počet je nekonzistentní (například se zvětšují kvůli provozu, snižují se například na pomalá období). V tomto scénáři musíte své Sentinely spouštět na hostitelích, kteří nejsou klienty ani na serveru Redis.
Všimněte si, že pokud to uděláte, budete muset napsat démona, který bude monitorovat kanál Sentinel PUBSUB pro událost hlavního přepínače, aby aktualizoval LB - které musíte nakonfigurovat tak, aby mluvilo pouze s aktuálním masterem (nikdy se nepokoušejte mluvit s oběma). Dá to více práce, ale využívá Sentinel transparentně pro klienta – který zná pouze komunikaci s IP/portem LB.