Erstens ist Sentinel kein Load Balancer oder Proxy für Redis.
Zweitens sind nicht alle Fehler der Tod des Hosts. Manchmal hängt sich der Server kurz auf, manchmal wird ein Netzwerkkabel ausgesteckt usw. Aus diesem Grund ist es nicht empfehlenswert, Sentinel auf denselben Hosts wie Ihre Redis-Instanz auszuführen. Wenn Sie Sentinel verwenden, um Failover zu verwalten, gibt es Probleme, wenn weniger als drei Sentinels auf anderen Knoten als Ihrem Redis-Master und Slave(s) ausgeführt werden.
Sentinel verwendet einen Quorum-Mechanismus, um über ein Failover und einen Slave abzustimmen. Bei weniger als zwei Sentinels besteht die Gefahr eines Split Brain, bei dem zwei oder mehr Redis-Server denken, dass sie Master sind.
Stellen Sie sich das Szenario vor, in dem Sie zwei Server betreiben und auf jedem Sentinel ausführen. Wenn Sie eine verlieren, verlieren Sie die zuverlässige Failover-Fähigkeit.
Clients verbinden sich nur mit Sentinel, um die aktuellen Master-Verbindungsinformationen zu erfahren. Jedes Mal, wenn der Client die Verbindung verliert, wiederholen sie diesen Vorgang. Sentinel ist kein Proxy für Redis – Befehle für Redis gehen direkt an Redis.
Der einzige zuverlässige Grund, Sentinel mit weniger als drei Sentinels auszuführen, ist die Diensterkennung, was bedeutet, dass es nicht für die Failover-Verwaltung verwendet wird.
Betrachten Sie das Zwei-Host-Szenario:
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis slave + sentinel 2 (Quorum 1)
Wenn Host B in diesem Szenario vorübergehend die Netzwerkverbindung zu Host A verliert, stuft HostB sich selbst zum Master hoch. Jetzt haben Sie:
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis master + sentinel 2 (Quorum 1)
Allen Clients, die sich mit Sentinel 2 verbinden, wird mitgeteilt, dass Host B der Master ist, während Clients, die sich mit Sentinel 1 verbinden, Host A als Master mitgeteilt wird (was, wenn Sie Ihre Sentinels hinter einem Load Balancer haben, die Hälfte Ihrer Clients bedeutet).
Was Sie also ausführen müssen, um ein akzeptables Minimum an zuverlässiger Failover-Verwaltung zu erhalten, ist:
Host A: Redis master
Host B: Redis Slave
Host C: Sentinel 1
Host D: Sentinel 2
Host E: Sentinel 2
Ihre Clients verbinden sich mit den Sentinels und erhalten den aktuellen Master für die Redis-Instanz (mit Namen) und stellen dann eine Verbindung her. Wenn der Master stirbt, sollte die Verbindung vom Client getrennt werden, woraufhin der Client sich wieder mit Sentinel verbinden wird/sollte und die neuen Informationen erhält.
Wie gut jede Clientbibliothek damit umgeht, hängt von der Bibliothek ab.
Idealerweise befinden sich die Hosts C, D und E entweder auf denselben Hosts, von denen aus Sie eine Verbindung zu Redis herstellen (d. h. dem Client-Host). oder stellen eine gute Probenahme dar, die sie bekommen haben. Der Hauptgrund dafür ist, sicherzustellen, dass Sie überprüfen, von wo aus Sie eine Verbindung zu Redis herstellen müssen. Andernfalls platzieren Sie sie im selben DC/Rack/in derselben Region wie die Clients.
Wenn Sie möchten, dass Ihre Clients mit einem Load Balancer kommunizieren, versuchen Sie, Ihre Sentinels nach Möglichkeit auf diesen LB-Knoten zu haben, und fügen Sie nach Bedarf zusätzliche Nicht-LB-Hosts hinzu, um eine ungerade Anzahl von Sentinels> 2 zu erhalten Client-Hosts sind insofern dynamisch, als ihre Anzahl inkonsistent ist (sie skalieren beispielsweise für Datenverkehr nach oben, für langsame Zeiten nach unten). In diesem Szenario müssen Sie Ihre Sentinels praktisch auf Nicht-Client- und Nicht-Redis-Server-Hosts ausführen.
Beachten Sie, dass Sie in diesem Fall einen Daemon schreiben müssen, der den Sentinel-PUBSUB-Kanal auf das Master-Switch-Ereignis überwacht, um den LB zu aktualisieren – den Sie so konfigurieren müssen, dass er nur mit dem aktuellen Master kommuniziert (versuchen Sie niemals, mit beiden zu sprechen). Es ist mehr Arbeit, dies zu tun, aber macht die Verwendung von Sentinel für den Client transparent – der nur mit der LB-IP/Port kommunizieren kann.
