So konfigurieren Sie Redis Replication unter Ubuntu 16.04

Einführung

Redis ist ein Open-Source-Schlüsselwertdatenspeicher, der ein In-Memory-Speichermodell mit optionalen Festplattenschreibvorgängen für die Persistenz verwendet. Es bietet unter anderem Transaktionen, ein Pub / Sub-Messaging-Muster und automatisches Failover. Redis hat Kunden, die in den meisten Sprachen geschrieben sind, wobei empfohlene auftheir website angegeben sind.

In Produktionsumgebungen wird das Replizieren Ihrer Daten auf mindestens zwei Knoten als bewährte Methode angesehen. Dies ermöglicht eine Wiederherstellung im Falle eines Umgebungsfehlers, was besonders wichtig ist, wenn die Benutzerbasis Ihrer Anwendung wächst. Außerdem können Sie sicher mit Produktionsdaten interagieren, ohne diese zu ändern oder die Leistung zu beeinträchtigen.

In diesem Handbuch konfigurieren wir die Replikation zwischen zwei Servern, auf denen Ubuntu 16.04 ausgeführt wird. Dieser Vorgang kann bei Bedarf einfach für weitere Server angepasst werden.

Voraussetzungen

Um dieses Handbuch zu vervollständigen, benötigen Sie Zugriff auf zwei Ubuntu 16.04-Server. In Übereinstimmung mit der von Redis verwendeten Terminologie beziehen wir uns auf die primären Server, die für das Akzeptieren von Schreibanforderungen verantwortlich sind, alsmaster-Server und den sekundären schreibgeschützten Server alsslave-Server.

Auf jedem dieser Server sollte ein Benutzer ohne Rootberechtigung mitsudo-Berechtigungen konfiguriert sein. In diesem Handbuch wird außerdem davon ausgegangen, dass eine grundlegende Firewall vorhanden ist. Sie können unserenUbuntu 16.04 initial server setup guide folgen, um diese Anforderungen zu erfüllen.

Wenn Sie bereit sind, fahren Sie mit dieser Anleitung fort.

Schritt 1: Installieren Sie Redis

Zunächst installieren wir Redis auf den Servernmaster undslave.

Wir werden ein aktuelles Redis Server-Paket mitChris Lea’s Redis PPA installieren. Seien Sie immer vorsichtig, wenn Sie Repositorys von Drittanbietern aktivieren. In diesem Fall ist Chris Lea ein etablierter Verpacker, der viele hochwertige Verpackungen unterhält.

Fügen Sie zunächst die PPA zu beiden Servern hinzu:

sudo apt-add-repository ppa:chris-lea/redis-server

Drücken SieENTER, um das Repository zu akzeptieren.

Aktualisieren Sie als Nächstes den lokalen Paketindex des Servers und installieren Sie das Redis-Serverpaket, indem Sie Folgendes eingeben:

sudo apt-get update
sudo apt-get install redis-server

Dadurch wird der Redis-Server installiert und der Dienst gestartet.

Überprüfen Sie, ob Redis läuft, indem Sie Folgendes eingeben:

redis-cli ping

Sie sollten die folgende Antwort erhalten:

OutputPONG

Dies zeigt an, dass Redis ausgeführt wird und für den lokalen Client verfügbar ist.

Schritt 2: Sicherer Datenverkehr zwischen den beiden Servern

Bevor Sie die Replikation einrichten, müssen Sie die Auswirkungen des Redis-Sicherheitsmodells kennen. Redis bietet keine nativen Verschlüsselungsoptionen und geht davon aus, dass es in einem privaten Netzwerk vertrauenswürdiger Peers bereitgestellt wurde.

Wenn Redis in einem isolierten Netzwerk bereitgestellt wird…

Wenn Ihre Server in einem isolierten Netzwerk betrieben werden, müssen Sie möglicherweise nur die Konfigurationsdatei von Redis anpassen, um sie an die IP-Adresse Ihres isolierten Netzwerks zu binden.

Öffnen Sie die Redis-Konfigurationsdatei auf jedem Computer:

sudo nano /etc/redis/redis.conf

Suchen Sie die Zeilebindund hängen Sie die IP-Adresse des isolierten Netzwerks des Servers an:

/etc/redis/redis.conf

bind 127.0.0.1 isolated_IP_address

Speichern und schließen Sie die Datei. Starten Sie den Dienst neu, indem Sie Folgendes eingeben:

sudo systemctl restart redis-server.service

Öffnen Sie den Zugang zum Redis-Port:

sudo ufw allow 6379

Sie sollten nun in der Lage sein, von einem Server auf einen Server zuzugreifen, indem Sie die IP-Adresse des alternativen Servers für den Befehlredis-climit dem Flag-hangeben:

redis-cli -h isolated_IP_address ping
OutputPONG

Redis kann jetzt Verbindungen von Ihrem isolierten Netzwerk akzeptieren.

Wenn Redis nicht in einem isolierten Netzwerk bereitgestellt wird…

Für Netzwerke, die nicht isoliert sind oder die Sie nicht steuern, muss der Datenverkehr unbedingt auf andere Weise gesichert werden. Es gibt viele Optionen zum Sichern des Datenverkehrs zwischen Redis-Servern, darunter:

  • Tunneling with stunnel: Sie benötigen für jeden Server einen eingehenden und ausgehenden Tunnel. Ein Beispiel finden Sie unten in der Anleitung.

  • Tunneling with spiped: Sie müssen zwei Systemd-Unit-Dateien pro Server erstellen, eine für die Kommunikation mit dem Remote-Server und eine für die Weiterleitung von Verbindungen an den eigenen Redis-Prozess. Details finden Sie unten in der Anleitung.

  • Setting up a VPN with PeerVPN: Auf beide Server muss über das VPN zugegriffen werden können.

Stellen Sie mit einer der oben genannten Methoden eine sichere Kommunikationsmethode zwischen Ihrem Redis-Master- und -Slave-Server her. Sie sollten die IP-Adresse und den Port kennen, die jeder Computer benötigt, um eine sichere Verbindung zum Redis-Dienst auf seinem Peer herzustellen.

Schritt 3: Konfigurieren Sie Redis Master

Nachdem Redis auf jedem Server ausgeführt wird und ein sicherer Kommunikationskanal eingerichtet wurde, müssen die Konfigurationsdateien bearbeitet werden. Beginnen wir mit dem Server, der alsmaster fungiert.

Öffnen Sie/etc/redis/redis.conf mit Ihrem bevorzugten Texteditor:

sudo nano /etc/redis/redis.conf

Suchen Sie zunächst die Einstellungtcp-keepaliveund setzen Sie sie auf 60 Sekunden, wie in den Kommentaren angegeben. Auf diese Weise erkennt Redis Netzwerk- oder Dienstprobleme:

/etc/redis/redis.conf

. . .
tcp-keepalive 60
. . .

Suchen Sie die Direktiverequirepassund setzen Sie sie auf eine starke Passphrase. Während Ihr Redis-Datenverkehr vor externen Parteien sicher sein sollte, bietet dies eine Authentifizierung für Redis selbst. Da Redis schnell ist und die Anzahl der Kennwortversuche nicht begrenzt, wählen Sie eine starke, komplexe Passphrase, um sich vor Brute-Force-Versuchen zu schützen:

/etc/redis/redis.conf

requirepass your_redis_master_password

Schließlich gibt es einige optionale Einstellungen, die Sie je nach Verwendungsszenario anpassen möchten.

Wenn Sie nicht möchten, dass Redis ältere und weniger verwendete Schlüssel beim Auffüllen automatisch entfernt, können Sie die automatische Schlüsselräumung deaktivieren:

/etc/redis/redis.conf

maxmemory-policy noeviction

Für verbesserte Haltbarkeitsgarantien können Sie die Persistenz von Nur-Anhängen-Dateien aktivieren. Dies trägt dazu bei, den Datenverlust im Falle eines Systemausfalls auf Kosten größerer Dateien und einer etwas langsameren Leistung zu minimieren:

/etc/redis/redis.conf

appendonly yes
appendfilename "redis-staging-ao.aof"

Wenn Sie fertig sind, speichern und schließen Sie die Datei.

Starten Sie den Redis-Dienst neu, um die Konfigurationsänderungen neu zu laden:

sudo systemctl restart redis-server.service

Nehmen Sie sich einen Moment Zeit, um den konfigurierten Master-Server zu testen.

Schritt 4: Testen Sie den Redis Master

Überprüfen Sie, ob Sie sich mit dem Kennwort authentifizieren können, das Sie beim Starten des Redis-Clients festgelegt haben:

redis-cli

Versuchen Sie zunächst einen Befehl ohne Authentifizierung:

info replication

Sie sollten die folgende Antwort erhalten:

Redis master outputNOAUTH Authentication required.

Dies wird erwartet und zeigt an, dass unser Redis-Server nicht authentifizierte Anforderungen korrekt ablehnt.

Verwenden Sie als Nächstes den Befehlauth, um sich zu authentifizieren:

auth your_redis_master_password

Sie sollten eine Bestätigung erhalten, dass Ihre Anmeldeinformationen akzeptiert wurden:

Redis master outputOK

Wenn Sie den Befehl erneut versuchen, sollte diesmal erfolgreich sein:

info replication
Redis master output# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

Legen Sie während der Authentifizierung einen Testschlüssel fest, damit wir die Replikation später überprüfen können:

set test 'this key was defined on the master server'

Kehren Sie zum Betriebssystem zurück, wenn Sie fertig sind:

exit

Nachdem wir den Master-Server bereit haben, fahren wir mit unserer Slave-Maschine fort.

Schritt 5: Konfigurieren Sie den Redis Slave

Als nächstes müssen wir einige Änderungen vornehmen, damit unsereslave server eine Verbindung zu unserer Master-Instanz herstellen können.

Öffnen Sie/etc/redis/redis.conf auf dem Slave-Server:

sudo nano /etc/redis/redis.conf

Suchen und kommentieren Sie zunächst die Zeileslaveof. Diese Direktive verwendet die IP-Adresse und den Port, die Sie verwenden, um eine sichere Verbindung zum Master-Redis-Server herzustellen, getrennt durch ein Leerzeichen. Standardmäßig überwacht der Redis-Server 6379 auf der lokalen Schnittstelle, aber jede der Netzwerksicherheitsmethoden ändert den Standard für externe Parteien in irgendeiner Weise.

Die Werte, die Sie verwenden, hängen von der Methode ab, die Sie zum Sichern Ihres Netzwerkverkehrs verwendet haben:

  • isolated network: Verwenden Sie die isolierte Netzwerk-IP-Adresse und den Redis-Port (6379) des Master-Servers (z. B.slaveof isolated_IP_address 6379).

  • stunnel oderspiped: Verwenden Sie die lokale Schnittstelle (127.0.0.1) und den für den Tunnelverkehr konfigurierten Port (dies wäreslaveof 127.0.0.1 8000, wenn Sie der Anleitung folgen).

  • PeerVPN: Verwenden Sie die VPN-IP-Adresse des Master-Servers und den regulären Redis-Port (dies wäreslaveof 10.8.0.1 6379, wenn Sie der Anleitung folgen).

Die allgemeine Form ist:

/etc/redis/redis.conf

slaveof ip_to_contact_master port_to_contact_master

Kommentieren Sie anschließend die Zeilemasterauthaus und füllen Sie sie mit dem Kennwort aus, das für den Redis-Masterserver festgelegt wurde:

/etc/redis/redis.conf

masterauth your_redis_master_password

Richten Sie ein Kennwort für Ihren Slave-Server ein, um unbefugten Zugriff zu verhindern. Die gleichen Warnungen bezüglich der Komplexität von Passwörtern gelten hier:

/etc/redis/redis.conf

requirepass your_redis_slave_password

Speichern und schließen Sie die Datei, wenn Sie fertig sind.

Schritt 6: Testen Sie den Redis Slave und übernehmen Sie die Änderungen

Bevor wir den Dienst neu starten, um unsere Änderungen zu implementieren, stellen wir eine Verbindung zur lokalen Redis-Instanz auf dem Slave-Computer her und stellen sicher, dass der Schlüssel vontestnicht festgelegt ist:

redis-cli

Fragen Sie nach dem Schlüssel, indem Sie Folgendes eingeben:

get test

Sie sollten die folgende Antwort erhalten:

Redis slave output(nil)

Dies zeigt an, dass die lokale Redis-Instanz keinen Schlüssel mit dem Namentest hat. Kehren Sie zur Shell zurück, indem Sie Folgendes eingeben:

exit

Starten Sie den Redis-Dienst auf dem Slave neu, um diese Änderungen zu implementieren:

sudo systemctl restart redis-server.service

Dadurch werden alle Änderungen übernommen, die wir an der Redis-Slave-Konfigurationsdatei vorgenommen haben.

Stellen Sie erneut eine Verbindung zur lokalen Redis-Instanz her:

redis-cli

Wie beim Redis-Masterserver sollten Vorgänge jetzt fehlschlagen, wenn sie nicht autorisiert sind:

get test
Redis slave output(error) NOAUTH Authentication required.

Authentifizieren Sie sich jetzt mit dem Kennwort des Redis-Slaves, das Sie im letzten Abschnitt festgelegt haben:

auth your_redis_slave_password
Redis slave outputOK

Wenn wir diesmal versuchen, auf den Schlüssel zuzugreifen, stellen wir fest, dass er verfügbar ist:

get test
Redis slave output"this key was defined on the master server"

Sobald wir unseren Redis-Dienst auf dem Slave neu gestartet haben, begann die Replikation sofort.

Sie können dies mit dem Befehlinfovon Redis überprüfen, der Informationen zur Replikation meldet. Der Wert vonmaster_host undmaster_port sollte mit den Argumenten übereinstimmen, die Sie für die Optionslaveof verwendet haben:

info replication
Redis slave output# Replication
role:slave
master_host:10.8.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:5
master_sync_in_progress:0
slave_repl_offset:1387
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

Wenn Sie sich die gleichen Informationen auf dem Redis-Masterserver ansehen, sehen Sie etwa Folgendes:

info replication
Redis master output# Replication
role:master
connected_slaves:1
slave0:ip=10.8.0.2,port=6379,state=online,offset=1737,lag=1
master_repl_offset:1737
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:1736

Wie Sie sehen, identifizieren sich Master- und Slave-Server in ihrer definierten Beziehung korrekt.

Schritt 7: Beförderung eines Redis-Slaves zum Master

Ein Hauptgrund für das Einrichten der Replikation ist die Behebung von Fehlern mit minimalem Datenverlust und minimalen Ausfallzeiten. Redis-Slaves können in den Master-Status befördert werden, um den Schreibverkehr im Falle eines Redis-Master-Fehlers zu verarbeiten.

Manuelles Befördern eines Redis-Slaves

Wir können dies manuell vom Redis-Slave-Server aus tun. Melden Sie sich mit dem Redis-Client an:

redis-cli

Authentifizieren Sie sich mit dem Redis-Slave-Passwort:

auth your_redis_slave_password

Versuchen Sie vor dem Hochstufen des Redis-Slaves, den Testschlüssel zu überschreiben:

set test 'this key was overwritten on the slave server'

Dies sollte fehlschlagen, da Redis-Slaves standardmäßig mit der Optionslave-read-only yeschreibgeschützt konfiguriert sind:

Redis slave output(error) READONLY You can't write against a read only slave.

Verwenden Sie den Befehlslaveof mit dem Wertno one, um die Replikation zu deaktivieren und den aktuellen Server in den Masterstatus zu versetzen:

slaveof no one
Redis slave outputOK

Überprüfen Sie die Replikationsinformationen erneut:

info replication
Redis slave output# Replication
role:master
connected_slaves:0
master_repl_offset:6749
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

Wie Sie sehen, ist der Slave jetzt ein Redis-Master.

Versuchen Sie, den Schlüssel erneut zu überschreiben. Diesmal sollte dies erfolgreich sein:

set test 'this key was overwritten on the slave server'
Redis slave outputOK

Beachten Sie, dass die Replikation fortgesetzt wird, wenn der Dienst ohne Änderung der Konfiguration neu gestartet wird, da die Konfigurationsdatei diesen Knoten weiterhin als Redis-Slave kennzeichnet. Beachten Sie auch, dass alle Einstellungen, die Sie für den Redis-Master verwendet haben, möglicherweise hier erneut angewendet werden müssen (z. B. das Aktivieren von Nur-Anhängen-Dateien oder das Ändern der Räumungsrichtlinie).

Wenn andere Slaves vorhanden sind, weisen Sie sie auf den neu hochgestuften Master, um die Replikation der Änderungen fortzusetzen. Dies kann mit dem Befehlslaveofund den Verbindungsinformationen des neuen Masters erfolgen.

Um die Replikation auf den ursprünglichen Master manuell fortzusetzen, zeigen Sie den Interim-Master und die Slaves mit dem Befehlslaveof mit den in der Konfigurationsdatei verwendeten Werten auf den ursprünglichen Master zurück:

slaveof ip_to_contact_master port_to_contact_master
Redis slave outputOK

Wenn Sie den Schlüssel am Slave erneut überprüfen, sollten Sie feststellen, dass der ursprüngliche Wert vom Redis-Master wiederhergestellt wurde:

get test
Redis slave output"this key was defined on the master server"

Aus Konsistenzgründen werden alle Daten auf dem Slave gelöscht, wenn er mit einem Masterserver neu synchronisiert wird.

Automatisches Hochstufen eines Redis-Slaves

Das automatische Heraufstufen eines Redis-Slaves erfordert eine Abstimmung mit der Anwendungsebene. Dies bedeutet, dass die Implementierung stark von der Anwendungsumgebung abhängt, sodass es schwierig ist, bestimmte Maßnahmen vorzuschlagen.

Wir können jedoch die allgemeinen Schritte durchgehen, die zur Durchführung eines automatischen Failovers erforderlich sind. Bei den folgenden Schritten wird davon ausgegangen, dass alle Redis-Server für den gegenseitigen Zugriff konfiguriert wurden:

  • Stellen Sie in der Anwendung fest, dass der Masterserver nicht mehr verfügbar ist.

  • Führen Sie auf einem Slave den Befehlslaveof no one aus. Dadurch wird die Replikation gestoppt und in den Masterstatus versetzt.

  • Passen Sie alle Einstellungen am neuen Master an die vorherigen Master-Einstellungen an. Dies kann für die meisten Optionen im Voraus in der Konfigurationsdatei erfolgen.

  • Direkter Datenverkehr von Ihrer Anwendung zum neu hochgestuften Redis-Master.

  • Führen Sie auf allen verbleibenden Slavesslaveof new_master_ip new_master_port aus. Dadurch stoppen die Slaves die Replikation vom alten Master, verwerfen ihre (jetzt veralteten) Daten vollständig und beginnen mit der Replikation vom neuen Master.

Nachdem Sie den Dienst auf dem ursprünglichen Master-Server wiederhergestellt haben, können Sie ihm entweder erlauben, sich als Slave wieder anzumelden, der auf den neu hochgestuften Master verweist, oder ihm erlauben, bei Bedarf den Dienst als Master wieder aufzunehmen.

Fazit

Wir haben eine Umgebung eingerichtet, die aus zwei Servern besteht, von denen einer als Redis-Master und der andere als Slave fungiert. Dies bietet Redundanz im Falle eines System- oder Netzwerkausfalls und kann dazu beitragen, Lesevorgänge aus Leistungsgründen auf mehrere Server zu verteilen. Dies ist ein guter Ausgangspunkt für das Entwerfen einer Redis-Konfiguration, die den Anforderungen Ihrer Produktionsanwendung und Infrastruktur entspricht. Weitere Informationen zur Verwendung von Redis für Ihre Anwendungsanforderungen finden Sie in unserenother Redis tutorials.