För det första är Sentinel inte en lastbalanserare eller proxy för Redis.
För det andra är inte alla misslyckanden värdens död. Ibland hänger sig servern en kort stund, ibland kopplas en nätverkskabel ur, etc. Därför är det inte bra att köra Sentinel på samma värdar som din Redis-instans. Om du använder Sentinel för att hantera failover, frågar allt mindre än tre sentinels som körs på andra noder än din Redis-mästare och slav(ar) om problem.
Sentinel använder en kvorummekanism för att rösta om en failover och slav. Med mindre än två vaktposter riskerar du att få splittrade hjärnor där två eller flera Redis-servrar tror att de är mästare.
Föreställ dig scenariot där du kör två servrar och kör sentinel på var och en. Om du tappar en förlorar du tillförlitlig failover-kapacitet.
Klienter ansluter endast till Sentinel för att lära sig den aktuella huvudanslutningsinformationen. Varje gång klienten förlorar anslutningen upprepar de denna process. Sentinel är inte en proxy för Redis - kommandon för Redis går direkt till Redis.
Det enda tillförlitliga skälet till att köra Sentinel med mindre än tre vaktposter är för tjänsteupptäckt, vilket innebär att man inte använder det för failover-hantering.
Tänk på två värdscenariot:
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis slave + sentinel 2 (Quorum 1)
Om värd B tillfälligt förlorar nätverksanslutningen till värd A i det här scenariot kommer värdB att göra sig behärskad. Nu har du:
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis master + sentinel 2 (Quorum 1)
Alla klienter som ansluter till Sentinel 2 kommer att få veta att Host B är master, medan klienter som ansluter till Sentinel 1 kommer att få veta Host A master (vilket, om du har dina Sentinels bakom en lastbalanserare, betyder hälften av dina klienter).
Så det du behöver köra för att erhålla minsta acceptabla tillförlitliga failover-hantering är:
Host A: Redis master
Host B: Redis Slave
Host C: Sentinel 1
Host D: Sentinel 2
Host E: Sentinel 2
Dina klienter ansluter till vaktposterna och skaffar den nuvarande mastern för Redis-instansen (med namn), anslut sedan till den. Om mastern dör bör anslutningen avbrytas av klienten varpå klienten kommer/ska ansluta till Sentinel igen och få den nya informationen.
Hur väl varje klientbibliotek hanterar detta beror på biblioteket.
Helst är värdarna C, D och E antingen på samma värdar som du ansluter till Redis från (dvs. klientvärden). eller representera ett bra urval fick dem. Huvudsaken här är att se till att du kontrollerar varifrån du behöver ansluta till Redis. Om det misslyckas placera dem i samma DC/Rack/Region som klienterna.
Om du vill att dina kunder ska prata med en lastbalanserare, försök att ha dina Sentinels på dessa LB-noder om möjligt, lägg till ytterligare icke-LB-värdar efter behov för att få ett udda antal sentinels> 2. Ett undantag från detta är om din klientvärdar är dynamiska genom att antalet av dem är inkonsekvent (de skalar upp för trafik, ned för långsamma perioder, till exempel). I det här scenariot måste du i stort sett köra dina Sentinels på icke-klient- och icke-redis-servervärdar.
Observera att om du gör detta kommer du att behöva skriva en demon som övervakar Sentinel PUBSUB-kanalen för huvudväxelhändelsen för att uppdatera LB -som du måste konfigurera för att bara prata med den nuvarande mastern (försök aldrig att prata med båda). Det är mer jobb att göra det men använder Sentinel som är transparent för klienten - som bara vet att prata med LB IP/Port.