For det første er Sentinel ikke en load balancer eller en proxy for Redis.
For det andet er ikke alle fejl, værtens død. Nogle gange hænger serveren kortvarigt, nogle gange bliver et netværkskabel koblet fra, osv. Fordi det ikke er god praksis at køre Sentinel på de samme værter som din Redis-instans. Hvis du bruger Sentinel til at administrere failover, beder alt mindre end tre vagtposter, der kører på andre noder end din Redis-master og slave(r), om problemer.
Sentinel bruger en quorum-mekanisme til at stemme om en failover og slave. Med mindre end to vagtposter risikerer du at få splittet hjerne, hvor to eller flere Redis-servere tror, de er master.
Forestil dig scenariet, hvor du kører to servere og kører sentinel på hver. Hvis du mister en, mister du pålidelig failover-kapacitet.
Klienter opretter kun forbindelse til Sentinel for at lære de aktuelle masterforbindelsesoplysninger. Hver gang klienten mister forbindelsen, gentager de denne proces. Sentinel er ikke en proxy for Redis - kommandoer for Redis går direkte til Redis.
Den eneste pålidelige grund til at køre Sentinel med mindre end tre vagter er for serviceopdagelse, hvilket betyder, at den ikke bruges til failover-styring.
Overvej de to værtsscenarier:
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis slave + sentinel 2 (Quorum 1)
Hvis vært B midlertidigt mister netværksforbindelsen til vært A i dette scenarie, vil HostB promovere sig selv til at mestre. Nu har du:
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis master + sentinel 2 (Quorum 1)
Alle klienter, der opretter forbindelse til Sentinel 2, får at vide, at Host B er masteren, mens klienter, der opretter forbindelse til Sentinel 1, får at vide, at Host A er masteren (hvilket, hvis du har dine Sentinels bag en load balancer, betyder halvdelen af dine klienter).
Derfor er det, du skal køre for at opnå mindst acceptable pålidelig failover-styring:
Host A: Redis master
Host B: Redis Slave
Host C: Sentinel 1
Host D: Sentinel 2
Host E: Sentinel 2
Dine klienter opretter forbindelse til vagtposterne og får den aktuelle master for Redis-forekomsten (ved navn), og opret derefter forbindelse til den. Hvis masteren dør, skal forbindelsen afbrydes af klienten, hvorefter klienten vil/skal oprette forbindelse til Sentinel igen og få de nye oplysninger.
Hvor godt hvert klientbibliotek håndterer dette afhænger af biblioteket.
Ideelt set er værterne C, D og E enten på de samme værter, som du forbinder til Redis fra (dvs. klientværten). eller repræsentere en god prøveudtagning fik dem. Hovedindsatsen her er at sikre, at du tjekker, hvorfra du skal oprette forbindelse til Redis. I modsat fald placeres dem i samme DC/Rack/Region som klienterne.
Hvis du ønsker at få dine kunder til at tale med en load balancer, så prøv at have dine Sentinels på disse LB-noder, hvis det er muligt, og tilføje yderligere ikke-LB-værter efter behov for at opnå et ulige antal vagtposter> 2. En undtagelse fra dette er, hvis din klientværter er dynamiske ved, at antallet af dem er inkonsekvent (de skalerer op for trafik, ned i langsomme perioder, for eksempel). I dette scenarie skal du stort set køre dine Sentinels på ikke-klient- og ikke-redis-server-værter.
Bemærk, at hvis du gør dette, skal du så skrive en dæmon, som overvåger Sentinel PUBSUB-kanalen for master switch-hændelsen for at opdatere LB'en -som du skal konfigurere til kun at tale med den aktuelle master (forsøg aldrig at tale med begge). Det er mere arbejde at gøre det, men gør brug af Sentinel, der er transparent for klienten - som kun ved at tale med LB IP/Port.