Redis ist ein Datenbankverwaltungssystem der NoSQL-Klasse (nicht relationale DBMS), das vollständig im RAM abgelegt ist. Für den Zugriff auf die Daten wird das Modell „Schlüssel“ - „Wert“ verwendet. Ein solches DBMS wird häufig zum Speichern von Caches in skalierbaren Diensten, zum Speichern von Bildern und kleinen Daten verwendet.
Redis DBMS ist weit verbreitet aufgrund von:
- hohe Geschwindigkeit, weil Alle Daten werden im RAM gespeichert.
- plattformübergreifend;
- Vertrieb unter der BSD-Lizenz (gilt für Open Source-Software).
Die Verbreitung und Anwendbarkeit von Redis lässt sich anhand der umfangreichen Dokumentation mit allen Arten von Fällen auf der
offiziellen Website des Projekts abschätzen.
Wenn Sie die horizontale Skalierung von DirectumRX-Diensten verwenden, müssen Sie die ausfallsichere Redis-Installation verwenden, um ordnungsgemäß mit dem DirectumRX-Speicherdienst und dem DirectumRX-Webzugriffsdienst zu arbeiten.
Redis speichert Betriebsdaten, Caches und andere Informationen, die für den Betrieb von Diensten im Skalierungsmodus erforderlich sind, damit der Prozess der Benutzerinteraktion mit dem System nicht von der Installation abhängt, mit der er gerade arbeitet.
Redis speichert keine sensiblen Daten und ist nicht stark ausgelastet. Im Falle eines Redis-Fehlers treten beim Wechseln zwischen Installationen jedoch viele Fehler auf.
Auf der offiziellen Redis-Website gibt es zwei Möglichkeiten, um horizontale Skalierung und Fehlertoleranz sicherzustellen:
- Mit Redis Sentiel .
- Redis Cluster verwenden .
Ziehen Sie in Betracht, diese Optionen anzupassen.
Konfigurieren Sie Redis Sentiel
Die Option zur Verwendung des Redis Sentiel (Redis Tracking Node) wurde in Redis 2.4 implementiert und besteht darin, den zusätzlichen Redis Sentiel-Dienst zur Überwachung der Verfügbarkeit des Assistenten zu verwenden. Er führt auch die Konfiguration von Replikatknoten durch, falls der Assistent ausfällt. Legt fest, welcher der SLAVE-Knoten zu MASTER wird, und führt die Neukonfiguration unterwegs durch.
Implementiert das klassische Schema:
Es kann viele SLAVE-Knoten geben (laut offizieller Website bis zu 1000). Für produktive Arbeit wird empfohlen, mindestens zwei SLAVE-Knoten zu verwenden.
In der Regel ist das Schema so konfiguriert, dass der Redis Sentiel-Dienst auf den Knoten MASTER und SLAVE konfiguriert ist. Wenn der Knoten MASTER ausfällt, entscheiden sich die verbleibenden Überwachungsknoten für die Einführung eines neuen MASTER.
Die aktuelle Version von Redis kann von der
offiziellen Website des Produktentwicklers heruntergeladen werden. Die Distributionsseite ist jedoch nur für Linux verfügbar. Zu einer Zeit wurde
das Microsoft-
Projekt für die Portierung von Redis auf Windows entwickelt, aber derzeit hat das Projekt die Entwicklung auf Version 3.2.100 gestoppt. In diesem Artikel werden wir daher die relevanteste Bereitstellungsoption betrachten - unter Linux.
Als Testknoten werden wir zwei virtuelle Hosts redis1 und redis2 mit der installierten Linux-Distribution von Debian 10 verwenden.
Aktualisieren Sie zunächst die Paketlisten aus dem Standard-Repository und installieren Sie Redis:
apt-get update && apt-get upgrade apt install redis-server
Überprüfen Sie die Version:
root@redis1:/home/user
Lassen Sie redis1 als MASTER-Knoten und redis2 als SLAVE-Knoten fungieren.
Zu diesem Zweck schreiben wir in die Redis-Konfigurationsdateien die erforderlichen Parameter, mit denen Sie ein Replikat erstellen können (noch nicht fehlertolerant).
Geben Sie für redis1 in der Konfigurationsdatei /etc/redis/redis.conf Folgendes an:
Geben Sie für redis2 in der Konfigurationsdatei /etc/redis/redis.conf Folgendes an:
Starten Sie die Redis-Server-Dienste auf beiden Knoten neu:
root@redis1:/etc/redis
Wir überprüfen auf der MASTER-Seite, ob die Knoten zu Replikaten wurden und die erforderlichen Rollen erhalten haben:
root@redis1:/etc/redis
Auf der Sklaven-Seite sehen wir die gleiche Situation:
root@redis2:/etc/redis
Jetzt müssen Sie das Replikat so konfigurieren, dass es bei einem Ausfall eines der Knoten automatisch wiederhergestellt wird. Dazu benötigen wir den Redis Sentinel-Tracking-Service.
Basierend auf der
Dokumentation kann der Redis Sentinel-Überwachungsdienst die folgenden Vorgänge ausführen:
- Überprüft die Verfügbarkeit von MASTER- und SLAVE-Knoten und kann Warnungen über die Unzugänglichkeit von Knoten senden.
- Wenn der MASTER-Knoten ausfällt, kann der Zeugenknoten den SLAVE-Knoten in den MASTER-Modus versetzen sowie die verbleibenden SLAVE-Knoten neu konfigurieren, und sie beginnen mit dem neuen MASTER zu arbeiten.
- Nimmt Änderungen an den Konfigurationsdateien der Knoten MASTER und SLAVE vor.
Aus Gründen der Reinheit des Experiments werden wir einen Zeugen-Service auf einer separaten redis3-VM platzieren.
Wir verbinden das Redis-Repository auf die gleiche Weise und installieren das Redis-Sentinel-Paket:
apt install redis-sentinel
Nach der Installation müssen Sie die Einstellungen in der Konfigurationsdatei des Überwachungsknotens /etc/redis/sentinel.conf vornehmen:
Starten Sie den Dienst neu, nachdem Sie die Einstellungen vorgenommen haben:
root@redis3:/etc/redis
Überprüfen Sie, ob der Tracking-Service MASTER und SLAVE gesehen hat:
root@redis3:/etc/redis
Wir beginnen die Experimente.
Wir simulieren einen Fehler, stoppen den Redis-Server-Dienst auf dem Redis1-Knoten und erhalten die aktuellen Informationen des Zeugenknotens:
root@redis3:/etc/redis
Wir sehen, dass sich MASTER verändert hat.
Wir werden den Betrieb des redis1-Knotens wiederherstellen und seinen Status überprüfen:
root@redis3:/var/log/redis
Wir sehen, dass der Knoten die SLAVE-Rolle erhalten hat und der redis2-Knoten ein MASTER-Knoten ist.
Simulieren Sie den Ausfall des redis2-Knotens und überprüfen Sie den Status des Zeugenknotens:
root@redis3:/var/log/redis
Und der Zustand des redis1-Knotens:
root@redis3:/var/log/redis
Großartig, der Mechanismus funktioniert. Jetzt stellt sich jedoch die Frage, wie wir unsere DirectumRX-Dienste verbinden, da sie eine einzelne Knotenadresse benötigen. Wir werden die Situation mit dem HAProxy-Service lösen.
Redis Node Proxying
Jeder Proxy-TCP-Dienst kann als Reverse-Proxy für Redis-Knoten fungieren. In diesem Artikel werden wir die Verwendung von HAProxy betrachten, da es sich um ein spezielles Tool handelt, das für hohe Verfügbarkeit und Lastausgleich ausgelegt ist und von allgemein bekannten Onlinediensten verwendet wird. Weitere Informationen
zu HAProxy finden Sie
auf der Entwicklerseite .
Installieren Sie HAProxy auf dem redis3-Knoten:
root@redis3:/var/log/redis
Fügen Sie in der HAProxy-Konfigurationsdatei /etc/haproxy/haproxy.cfg die Einstellungen für das Proxying von Anforderungen an Redis-Knoten hinzu:
… frontend ft_redis bind *:6379 name redis mode tcp default_backend bk_redis backend bk_redis mode tcp option tcp-check tcp-check connect
In dieser Konfiguration wird angegeben, dass wir alle Anforderungen, die an alle Schnittstellen der aktuellen virtuellen Maschine eingehen, an die Adresse an Port 6379 weiterleiten. Wir übertragen Anforderungen an den Knoten, der antwortet, dass er die MASTER-Rolle hat.
Starten Sie den Haproxy-Dienst neu:
root@redis3:/etc/haproxy
Versuchen wir, eine Verbindung mit dem redis-cli-Client herzustellen und einen Testschlüssel zu erstellen:
root@redis3:/etc/haproxy
Stoppen Sie den Knoten redis1 und fragen Sie die Liste der Schlüssel erneut ab:
127.0.0.1:6379> info keyspace Error: Server closed the connection (3.01s) 127.0.0.1:6379> info keyspace
Wir sehen, dass die Verbindung für einige Zeit getrennt wurde, aber dann die Verbindung wieder hergestellt wurde und alle Daten an Ort und Stelle blieben.
Jetzt reicht es aus, die Reverse-Proxy-Adresse in den Konfigurationsdateien der DirectumRX-Dienste zu registrieren, um eine Verbindung zu Redis herzustellen.
Konfigurieren Sie den Redis-Cluster
Die für Version Redis 3.0 und höher implementierte Redis Cluster-Clustering-Option ist eine Lösung zum Erstellen und Verwalten eines Clusters mit Datensegmentierung und -replikation. Führt Aufgaben der Knotenverwaltung, Replikation, Datensynchronisation auf Knoten aus und stellt den Zugriff der Clientanwendung auf den MASTER-Knoten sicher, falls einer von mehreren MASTER-Knoten ausfällt.
Redis Cluster arbeitet im Multimaster-Modus. Jeder MASTER-Knoten kann einen oder mehrere SLAVE-Knoten (bis zu 1000) haben.
Die Skalierung ist die Hauptfunktion des Clusters. Darüber hinaus kann der Cluster die Fehlertoleranz des Redis-Dienstes garantieren:
- Wenn einige Knoten nicht funktionieren, verteilt der Cluster die Last von ihnen auf andere Knoten.
- Wenn Schlüsselknoten nicht funktionieren, endet der gesamte Cluster.
Eine Situation kann auftreten, wenn Client 2 auf den Knoten M2 schreibt. M2 antwortet mit "OK" und versucht, in S2 zu schreiben. Gleichzeitig wartet M2 nicht auf den korrekten Abschluss des Datenaustauschs mit S2, sondern reagiert sofort auf den Client. In diesem Fall verfügt das S2-Replikat möglicherweise nicht über alle Daten. Daher wird empfohlen, mehrere SLAVE-Replikate zu verwenden.
Eine Situation kann auch auftreten, wenn M1, M3 M2 nicht mehr „sehen“ und der Client weiterhin Daten in M2 schreibt. Wenn die Nichtverfügbarkeit einige Zeit andauert (Cluster-Node-Timeout-Parameter), wird in diesem Fall S2 in den MASTER-Modus versetzt und M2 funktioniert nicht mehr von alleine.
In der offiziellen Dokumentation wird die Verwendung von 6 Knoten empfohlen - eine Redis-Instanz pro Knoten, was eine höhere Zuverlässigkeit ermöglicht. Niemand verbietet jedoch die Verwendung von drei Knoten mit der folgenden Verbindungstopologie:
Wenn einer der physischen Knoten ausfällt, wechseln die entsprechenden SLAVE-Replikate in den MASTER-Modus und der Betrieb wird nicht unterbrochen.
Wir implementieren 3 virtuelle Maschinen (redis1, redis2 und redis3) auf dem Prüfstand, von denen jede 2 Redis-Instanzen ausführen wird.
Die Clientanwendung stellt eine Verbindung zu einem bestimmten Port her, der in der Clientkonfigurationsdatei angegeben ist. Daher sollten MASTER-SLAVE-Paare an denselben Ports funktionieren.
Für das Paar M1 - S1 verwenden wir Port 6381
Für das Paar M2 - S2 verwenden wir Port 6382
Für das Paar M3 - S3 verwenden wir Port 6383
Bereiten Sie die Konfigurationsdateien vor
Auf redis1:
cp /etc/redis/redis.conf /etc/redis/m1_redis.conf cp /etc/redis/redis.conf /etc/redis/s2_redis.conf mv /etc/redis/redis.conf /etc/redis/redis.bak
Auf redis2:
cp /etc/redis/redis.conf /etc/redis/m2_redis.conf cp /etc/redis/redis.conf /etc/redis/s3_redis.conf mv /etc/redis/redis.conf /etc/redis/redis.bak
Auf redis3:
cp /etc/redis/redis.conf /etc/redis/m3_redis.conf cp /etc/redis/redis.conf /etc/redis/s1_redis.conf mv /etc/redis/redis.conf /etc/redis/redis.bak
Füllen Sie die Konfigurationsdateien gemäß der Vorlage aus:
bind <IP- > protected-mode no
Lassen Sie uns die Redis-Knoten starten:
Knoten redis1:
root@redis1:/etc/redis
Redis2-Knoten:
root@redis2:/etc/redis
Redis3-Knoten:
root@redis3:/etc/redis
Um den Cluster zu konfigurieren, müssen Sie das Dienstprogramm redis-cli client verwenden und ihm eine Liste von IP: Port-Serverpaaren übergeben, die die Rollen von MASTER und SLAVE: spielen.
redis-cli --cluster create redis1-ip:6381 redis2-ip:6382 redis3-ip:6383 redis1-ip:6382 redis2-ip:6383 redis3-ip:6381 --cluster-replicas 1
Die Option --cluster-replicas 1 gibt an, wie viele SLAVE jeder Master haben wird, und sie werden automatisch aus der Liste der übertragenen Replikate ausgewählt.
root@redis1:~/redis/src
Der Cluster ist korrekt aufgebaut. Wir werden Informationen zum Cluster anzeigen:
root@redis1:~/redis/src
Um ein bestimmtes Replikat wie bei Redis Sentiel zu testen, können Sie den INFO-Replikationsbefehl verwenden:
root@redis1:~/redis/src
Versuchen wir, mehrere Schlüssel zu erstellen und zu überprüfen, ob diese Schlüssel auf den Replikaten angezeigt wurden:
192.168.9.51:6381> SET key1 test1 -> Redirected to slot [9189] located at 192.168.9.52:6382 OK 192.168.9.52:6382> SET key2 test2 -> Redirected to slot [4998] located at 192.168.9.51:6381 OK 192.168.9.51:6381> SET key3 test3 OK 192.168.9.51:6381>
Überprüfen Sie auf M2:
root@redis2:/home/user
Und auf dem M3:
root@redis3:/home/user
Wir werden den redis1-Knoten deaktivieren und überprüfen, wie S1 funktioniert:
192.168.9.52:6382> CLUSTER NODES <b>182e5cffc9c31c231de69ddbaf507ec1fe17bb09 192.168.9.51:6382@16382 slave,fail d499af3672b3063c7239572ec311ad3160f280ae 1569509904727 1569509900000 4 connected</b> 485ffb786e9763955e6f10ffc59247690ad9bc11 <i>192.168.9.53:6381@16381 master</i> - 0 1569510017272 7 connected 0-5460 44f656062259005adea58bc5ad024071a050e192 192.168.9.52:6383@16383 slave 3a41475e1613519c3ecdec695736a898262a24a5 0 1569510018274 5 connected <b>e92cb96fd6c20db7509662a248902e3751ebe95f 192.168.9.51:6381@16381 master,fail - 1569509906731 1569509901721 1 connected</b> 3a41475e1613519c3ecdec695736a898262a24a5 192.168.9.53:6383@16383 master - 0 1569510019275 3 connected 10923-16383 d499af3672b3063c7239572ec311ad3160f280ae 192.168.9.52:6382@16382 myself,master - 0 1569510017000 2 connected 5461-10922
Wir sehen Informationen über den Ausfall von M1 und S2 und dass S3 in den MASTER-Modus gewechselt ist.
Überprüfen Sie, wo die Schlüssel gespeichert sind:
192.168.9.52:6382> GET key1 "test1" 192.168.9.52:6382> GET key2 -> Redirected to slot [4998] located at 192.168.9.53:6381 "test2" 192.168.9.53:6381> GET key3 "test3" 192.168.9.53:6381>
Schlüssel, die zuvor auf redis1 gespeichert waren, sind jetzt auf redis3 verfügbar.
Stellen Sie den Betrieb des Knotens redis1 wieder her und überprüfen Sie den Status der Knoten M1 und S2:
192.168.9.53:6381> CLUSTER NODES <i>e92cb96fd6c20db7509662a248902e3751ebe95f 192.168.9.51:6381@16381 slave 485ffb786e9763955e6f10ffc59247690ad9bc11 0 1569511658217 7 connected 182e5cffc9c31c231de69ddbaf507ec1fe17bb09 192.168.9.51:6382@16382 slave d499af3672b3063c7239572ec311ad3160f280ae 0 1569511657000 4 connected</i> d499af3672b3063c7239572ec311ad3160f280ae 192.168.9.52:6382@16382 master - 0 1569511656000 2 connected 5461-10922 3a41475e1613519c3ecdec695736a898262a24a5 192.168.9.53:6383@16383 master - 0 1569511656000 3 connected 10923-16383 485ffb786e9763955e6f10ffc59247690ad9bc11 192.168.9.53:6381@16381 myself,master - 0 1569511656000 7 connected 0-5460 44f656062259005adea58bc5ad024071a050e192 192.168.9.52:6383@16383 slave 3a41475e1613519c3ecdec695736a898262a24a5 0 1569511657216 5 connected
Der Zustand von M1 und S2 hat sich erholt, aber jetzt befindet sich M1 im SLAVE-Modus.
Und die Schlüssel befinden sich auch auf dem redis3-Knoten:
192.168.9.53:6383> GET key1 -> Redirected to slot [9189] located at 192.168.9.52:6382 "test1" 192.168.9.52:6382> GET key2 -> Redirected to slot [4998] located at 192.168.9.53:6381 "test2" 192.168.9.53:6383> GET key3 -> Redirected to slot [935] located at 192.168.9.53:6381 "test3"
Der Cluster ist konfiguriert und die Redis-Wiederherstellung wird getestet.
Um auf DirectumRX-Dienste zugreifen zu können, müssen Sie auch Reverse-Proxys konfigurieren, wie im Fall der Einrichtung von Redis Sentiel.
Anstelle einer Schlussfolgerung
In diesem Artikel wurde kein weiterer Weg zur Erhöhung der Redis-Fehlertoleranz in Betracht gezogen - die Verwendung eines Cluster-Ressourcenmanagers eines Drittanbieters, z. B.
Pacemaker . In diesem Fall ist es möglich, mit zwei Knoten auszukommen, es besteht jedoch eine hohe Wahrscheinlichkeit eines Datenverlusts im Notfall.
Für einen Reverse-Proxy (in diesem Fall HAProxy) ist es auch wünschenswert, Fehlertoleranz bereitzustellen, aber dieses Problem ging auch über den Rahmen dieses Artikels hinaus. Wenn Sie sich für das Thema interessieren, können diese Bereitstellungsoptionen auch in separaten Artikeln mit schrittweiser Optimierung und Prüfung der Ergebnisse berücksichtigt werden.
Unter den folgenden Links erfahren Sie mehr über das Thema:
Redis Cluster TutorialRedis Sentinel-DokumentationHAProxy-Konfigurationshandbuch .