Ten eerste is Sentinel geen load balancer of een proxy voor Redis.
Ten tweede zijn niet alle mislukkingen de dood van de host. Soms loopt de server even vast, soms wordt een netwerkkabel losgekoppeld, enz. Daarom is het geen goede gewoonte om Sentinel op dezelfde hosts als uw Redis-instantie te draaien. Als je Sentinel gebruikt om failover te beheren, vragen minder dan drie sentinels die op andere nodes draaien dan je Redis-master en slave(s) om problemen.
Sentinel gebruikt een quorummechanisme om te stemmen over een failover en slave. Met minder dan twee schildwachten loop je het risico op een gespleten brein waarbij twee of meer Redis-servers denken dat ze de baas zijn.
Stel je het scenario voor waarin je twee servers draait en op elke een sentinel draait. Als je er een verliest, verlies je de betrouwbare failover-capaciteit.
Clients maken alleen verbinding met Sentinel om de huidige hoofdverbindingsinformatie te leren. Telkens wanneer de klant de verbinding verliest, herhalen ze dit proces. Sentinel is geen proxy voor Redis - commando's voor Redis gaan rechtstreeks naar Redis.
De enige betrouwbare reden om Sentinel uit te voeren met minder dan drie schildwachten is voor servicedetectie, wat betekent dat het niet wordt gebruikt voor failoverbeheer.
Overweeg de twee hostscenario's:
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis slave + sentinel 2 (Quorum 1)
Als Host B in dit scenario tijdelijk de netwerkverbinding met Host A verliest, zal HostB zichzelf promoveren tot master. Nu heb je:
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis master + sentinel 2 (Quorum 1)
Alle clients die verbinding maken met Sentinel 2 krijgen te horen dat Host B de master is, terwijl clients die verbinding maken met Sentinel 1 aan Host A de master wordt verteld (wat, als u uw Sentinels achter een load balancer hebt, de helft van uw clients betekent).
Dus wat u moet uitvoeren om minimaal acceptabel betrouwbaar failover-beheer te verkrijgen, is:
Host A: Redis master
Host B: Redis Slave
Host C: Sentinel 1
Host D: Sentinel 2
Host E: Sentinel 2
Uw klanten maken verbinding met de schildwachten en verkrijgen de huidige master voor de Redis-instantie (op naam) en maken er vervolgens verbinding mee. Als de master uitvalt, moet de verbinding door de client worden verbroken, waarna de client opnieuw verbinding zal/moet maken met Sentinel en de nieuwe informatie krijgt.
Hoe goed elke clientbibliotheek hiermee omgaat, is afhankelijk van de bibliotheek.
Idealiter bevinden Hosts C, D en E zich op dezelfde hosts waarvandaan u verbinding maakt met Redis (d.w.z. de clienthost). of vertegenwoordigen een goede steekproef kreeg ze. De belangrijkste drijfveer hier is om ervoor te zorgen dat u controleert vanaf waar u verbinding moet maken met Redis. Als dat niet lukt, plaatst u ze in hetzelfde DC/Rack/Regio als de clients.
Als u wilt dat uw klanten met een load balancer praten, probeer dan uw Sentinels indien mogelijk op die LB-knooppunten te hebben, en voeg zo nodig extra niet-LB-hosts toe om een oneven aantal sentinels> 2 te verkrijgen. Een uitzondering hierop is als uw client-hosts zijn dynamisch in die zin dat het aantal ervan inconsistent is (ze schalen bijvoorbeeld op voor verkeer, omlaag voor langzame perioden). In dit scenario moet u uw Sentinels vrijwel uitvoeren op niet-client- en niet-redis-serverhosts.
Merk op dat als je dit doet, je dan een daemon moet schrijven die het Sentinel PUBSUB-kanaal controleert op de masterswitch-gebeurtenis om de LB bij te werken - die je moet configureren om alleen met de huidige master te praten (probeer nooit met beide te praten). Het is meer werk om dat te doen, maar maakt wel gebruik van Sentinel die transparant is voor de klant - die alleen weet te praten met de LB IP/Port.