Seite wählen

NETWAYS Blog

Redis Eviction Policies

After install Redis you don’t have any settings configured to control memory consumption. In Production this brings OOM to the arena which leads into a broken applications.

First thingy what users do is to configure MaxMemory config setting (like me of course ;-)). In combination with a noeviction policy (which is also the default) the documentation says:

[…] return errors when the memory limit was reached and the client is trying to execute commands that could result in more memory to be used (most write commands, but DEL and a few more exceptions).

The bad news is, you’ll have a broken application again. Most web apps just use Redis as an uncontrolled cache data sink and left over to you how to handle it. For 99.9% of the use-cases you just need to configure a cache policy, or in Redis-speech, an Eviction Policy, which means:

maxmemory 128mb
maxmemory-policy allkeys-lru
maxmemory-samples 10

1. You allow roughly 128MB of memory for Redis
2. Redis tries to remove the less recently used (LRU) keys first
3. Because LRU is not a exact LRU algo, you use 10 samples to help the algorithm to find the items

Try to explain by counters:

Icinga Redis Plugin Output:

Above is a icinga redis check plugin output. Which shows a roundabout memory use of 108% – which is more than the configured 128M 100% base.

Grafana Graph (Telegraf Redis Input Plugin)

Here is the config change made on the 02/04 down to 128M MaxMemory and the LRU Eviction Policy. The memory footprint stays the same. The change is more granular if you zoom in:

If the allkeys-lru does not work for you, give the documentation a try. There is a lot you can do to keep your applications up and running and make Redis a fluently easy dependency.

Marius Hein
Marius Hein
Head of IT Service Management

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert und viele Jahre in der Softwareentwicklung gearbeitet. Mittlerweile ist er Herr über die interne IT und als Leiter von ITSM zuständig für die technische Schnittmenge der Abteilungen der NETWAYS Gruppe. Wenn er nicht gerade IPv6 IPSec Tunnel bohrt, sitzt er daheim am Schlagzeug und treibt seine Nachbarn in den Wahnsinn.

Aufsetzen eines Redis-clusters

Da mir vor kurzem die Aufgabe zuteil wurde, einen Redis Cluster aufzusetzen, möchte ich diese Erfahrung mit euch teilen.
Die Vorbereitung:
 3 Nodes
– Redis in der aktuellen stabilen Version

Auf allen 3 Nodes die aktuelle (stable) Redis Version herunterladen und das tar.gz file entpacken
wget
tar -xvzf redis-stable-version.tar.gz -C /opt/
cd /opt/redis-stable-version/
make

Da der Cluster aus 6 Nodes bestehen muss (minimal), laufen auf jedem Node ein Master-Prozess und ein Slave-Prozess, deshalb sollte man ein Verzeichnis Cluster anlegen in dem dann eine master.conf und slave.conf liegt, die unterschiedlich konfiguriert sind.
zum Beispiel:
master.conf Node 1:
port 7000
logfile /var/log/redis/redis-master.log
bind 192.168.33.50
cluster-enabled yes
cluster-config-file nodes-master.conf
cluster-node-timeout 5000
appendonly yes
----
slave.conf Node 1:
port 7001
logfile /var/log/redis/redis-slave.log
bind 192.168.33.50
cluster-enabled yes
cluster-config-file nodes-slave.conf
cluster-node-timeout 5000
appendonly yes

Zur Erklärung: Ich habe jetzt den Master-Prozess Ports immer auf eine gerade Zahl gelegt (7000, 7002, 7004)
und die Slaves auf (7001, 7003, 7005). Die bind IP-Adresse ist auch wichtig auf dem jeweiligen Node zu binden.
Die Angabe von der nodes-master.conf / nodes-slave.conf ist dafür, damit hier der Status der Master/Slave Nodes hinein geschrieben werden
und diese Dateien werden beim Start automatisch erstellt.

z.B Node 3:
~# cat /opt/redis-5.0.7/cluster/master.conf
port 7004
logfile /var/log/redis/redis-master.log
bind 192.168.33.52
cluster-enabled yes
cluster-config-file nodes-master.conf
cluster-node-timeout 5000
appendonly yes

Die Nodes werden alle 3 so mit Konfigurationsdateien erstellt damit später der Cluster gebaut werden kann.

Starten der Prozesse auf den drei Nodes:
cd /opt/redis-stable-version/cluster && ../src/redis-server ./master.conf &
../src/redis-server ./slave.conf &
pgrep -a redis-server
# pgrep -fl redis-server
1988 redis-server
1992 redis-server

Bevor wir den Cluster zusammenhängen sollte man auf jedem Node prüfen, ob beide redis-server Prozesse laufen, siehe pgrep Kommando.

Cluster zusammenhängen:
Auf dem ersten Master-Node wird das redis-cli Kommando ausgeführt:
~# redis-cli --cluster create 192.168.33.50:7000 192.168.33.50:7001 192.168.33.51:7002 192.168.33.51:7003 192.168.33.52:7004 192.168.33.52:7005 --cluster-replicas 1
Wie man am Kommando erkennen kann, werden hier alle Master / Slave-Nodes mit ihrem Port zum einem Cluster verbunden –cluster-replicas 1 bedeutet, das zu jedem Master Node ein Slave konfiguriert ist.
Man muss die erstellte Konfiguration noch mit „yes“ bestätigen und anschließend sollte man folgenden Output erhalten:
[OK] All 16384 slots covered
Jetzt kann man per redis-cli mit dem Cluster kommunizieren, Werte setzen, Statis abfragen usw, in der Online-Dokumentation von Redis sind einige Bespiele vermerkt.
So, hat man einen lauffähigen Redis-Cluster am Start, es besteht auch ein fertiges Bash-Skript womit man einen fertigen Redis-Cluster auf einem Node starten kann, dieses ist unter dem Verzeichnis ‚/redis-stable-version/utils/‘ zu finden und als Schnelltest verwendet werden kann.

Das soll es fürs erste mal reichen und ich wünsch euch viel Spaß mit eurem ersten Redis Cluster. Natürlich möchte ich auch hier wieder auf unser Trainingsangebot im OpenSource aufmerksam machen, ihr wisst „Training = „Wissen“, immer fleißig weiterbilden 🙂

Johannes Carraro
Johannes Carraro
Senior Systems Engineer

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Team Operations als Senior Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren.

Einführung in Redis Streams


Redis Streams ist ein neues Feature, das Log-ähnliche Datenstrukturen auf abstrakte Weise modelliert und mit Redis 5.0 eingeführt wurde. Einfach gesagt, ist ein Stream in Redis eine Liste, in der Einträge angehängt werden. Jeder Eintrag hat eine eindeutige ID und besteht aus Schlüssel-Werte-Paaren. So können Nachrichten tatsächlich komplexe Strukturen haben, anstatt stringifizierte Versionen von JSON-Objekten zu sein. Im Gegensatz zu Pub/Sub-Nachrichten, die nach dem fire-and-forget Prinzip funktionieren, bewahren Redis-Streams Nachrichten auf Dauer. Das macht Redis Streams ideal um z.B. Chat-Systeme, message broker oder message queues zu implementieren.

Stream Grundlagen

Die grundlegenden Stream-Operationen sind natürlich Lesen und Schreiben. Um Nachrichten in einen Stream zu schreiben, gibt es den XADD-Befehl:

XADD mystream * key1 value1 key2 value2

Dieser Befehl fügt eine Struktur wie die folgende in einen Stream namens „mystream“ hinzu:

{
"key1": "value1“,
"key2": "value2"
}

Wie eingangs erwähnt, hat jede hinzufügte Nachricht eine eindeutige ID, die das zweite Argument der XADD-Operation ist. In unserem Fall haben wir * übergeben, damit Redis die ID automatisch generiert. In den meisten Anwendungsfällen reicht das völlig aus. Man könnte die ID aber auch selbst angeben.

Daten aus Streams abrufen

Nachdem wir mit XADD einen Stream erstellt und Nachrichten hinzufügt haben, können wir jetzt Daten aus dem Stream abrufen. Dabei gibt es verschiedene Zugriffsmethoden. Im ersten Beispiel abonnieren wir mit dem XREAD-Befehl einen Stream und warten auf neue Nachrichten:

XREAD BLOCK 0 STREAMS mystream $

Auf den ersten Blick mag das wenig einleuchtend sein, also zerlegen wir den Befehl kurz in seine Komponenten:

  • XREAD ist der Befehl zum Abrufen von Einträgen.
  • BLOCK 0 bedeutet, dass der Client endlos blockiert, wenn keine Einträge vorhanden sind. Geben wir hier anstatt 0 beispielsweise 1000 an, tritt nach 1000 Millisekunden ein Timeout auf, wenn nichts eingeht.
  • STREAMS ist eine Direktive, mit der wir eine Liste von Streams gefolgt von einer Liste von IDs angeben, von denen wir lesen wollen. In unserem Beispiel lesen wir von einem Stream mit der Pseudo ID $, die weiter unten erklärt wird.
  • mystream ist der Name des Streams, von dem wir lesen wollen.
  • $ ist eine Pseudo-ID, die jede neue Nachricht liefert, die ankommt nachdem der Befehl abgeschickt wurde. Das bedeutet, wir möchten alle vorherigen Einträge im Stream ignorieren und konzentrieren uns nur auf Nachrichten, die von nun an eintreffen.

Da wir im Moment keine neuen Nachrichten einliefern, blockiert der Befehl endlos, wenn wir ihn jetzt abschicken.

Wir ändern obigen Befehl nun folgendermaßen ab, um alle Nachrichten aus unserem Stream zu lesen:

XREAD STREAMS mystream 0

Wie wir sehen, müssen wir beim XREAD-Befehl nur die STREAMS Direktive angeben, um Ergebnisse zu erhalten. 0 ist wieder eine Pseudo-ID, die sozusagen den Beginn eines Streams angibt.

Wenn wir nur eine bestimmte maximale Anzahl von Nachrichten lesen wollen, erweitern wir obigen Befehl um die COUNT Option:

XREAD COUNT 2 STREAMS mystream 0

Das sind auch schon die Grundlagen um mit XADD Nachrichten in einen Stream zu schreiben und mit XREAD Nachrichten aus Streams zu lesen.

In einem folgenden Blogpost werden wir uns anschauen, wie man Clients schreibt, die alle Nachrichten lesen können. Auch wenn diese nicht verbunden waren, als die Nachrichten im Stream ankamen. Und weitere Features wie den XRANGE-Befehl und Consumer Groups.

Eric Lippmann
Eric Lippmann
CTO

Eric kam während seines ersten Lehrjahres zu NETWAYS und hat seine Ausbildung bereits 2011 sehr erfolgreich abgeschlossen. Seit Beginn arbeitet er in der Softwareentwicklung und dort an den unterschiedlichen NETWAYS Open Source Lösungen, insbesondere inGraph und im Icinga Team an Icinga Web. Darüber hinaus zeichnet er für viele Kundenentwicklungen in der Finanz- und Automobilbranche verantwortlich.

RequestTracker: Optimize Session Handling

To provide features like login or persistence to the user, stateless protocols like HTTP depend heavily on sessions. Almost every web application is using it.

An easy job you would say? Of course! But what about high availability setups with hundreds of concurrent users? And sessions need to be shared between application servers so that that users do not lose their current login session.

RT’s vanilla way is to put this in MySQL which produces queries on every request. Second bad thing is the created GET_LOCK query which slows down the environment after a while.

Better way is to use files because file sessions are extremely fast. No network overhead and not greatly influenced by differential IO. But then you have to share sessions between application servers and you should say good bye to that idea because we do not live in an ideal world and shared file systems are terribly slow.

What Next?

I opt for Redis. Meanwhile available on every system, fast as the LHC in Geneva and rock-solid like carbon. Redis is so adorable simple that you only can fall in love with this single-core-minimal-footprint-key-value-store thingy. But I’ll stop hallowing now.

RequestTracker uses Apache::Session::* default implementation and we choose the NoSQL module from there which provides access to Apache Cassandra and Redis.

Configuration Examples

[perl]# Annouce Redis to RequestTracker
Set($WebSessionClass, "Apache::Session::Redis");

# Single server
Set(%WebSessionProperties,
server => ‚127.0.0.1:6379‘
);

# Sentinel
Set(%WebSessionProperties,
sentinels => [ ‚127.0.0.1:26379‘ ],
service => ‚mymaster‘,
sentinels_cnx_timeout => 0.1,
sentinels_read_timeout => 1,
sentinels_write_timeout => 1
);
[/perl]

You can find more information in the product documentation.

Conclusion

It’s just a glimpse, but there a lot of ways to bring RequestTracker to enterprise level with more than 300 concurrent users and millions of tickets and attachments. Of course, highly available and scaled in every direction. You only need to ask us how to do!

Marius Hein
Marius Hein
Head of IT Service Management

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert und viele Jahre in der Softwareentwicklung gearbeitet. Mittlerweile ist er Herr über die interne IT und als Leiter von ITSM zuständig für die technische Schnittmenge der Abteilungen der NETWAYS Gruppe. Wenn er nicht gerade IPv6 IPSec Tunnel bohrt, sitzt er daheim am Schlagzeug und treibt seine Nachbarn in den Wahnsinn.

Der erste Entwurf für den Webinarkalender 2016 ist online!

NETWAYS Webinare Auch in diesem Jahr wollen wir wieder mit diversen Webinaren durchstarten und neben Icinga 2 natürlich unsere anderen Kernkompetenzen wie unter anderem Puppet, Foreman und unsere Hosting-Angebote nicht außen vor lassen.
Über das Jahr verteilt haben wir bereits diverse Themen fixiert – mehr werden aber natürlich noch folgen! Aktuell geplant sind die Folgenden Themen und Termine:

Titel Zeitraum Registrierung
Icinga Director: Konfiguration leicht gemacht 03. März 2016 – 10:30 Uhr Anmelden
Docker Hosting 10. März 2016 – 10:30 Uhr Anmelden
Foreman: Provisionierungswege 31. März 2016 – 10:30 Uhr Anmelden
ELK: Grundlagen der zentralen Logdatenverwaltung 15. April 2016 – 10:30 Uhr Anmelden
Foreman: Klassen und Parametrisierung in Puppet 20. Mai 2016 – 10:30 Uhr Anmelden
Foreman: Berechtigungen 28. Juli 2016 – 10:30 Uhr Anmelden
Foreman: Docker Integration 05. Oktober 2016 – 10:30 Uhr Anmelden

Wer sich einen Überblick über die bisherigen Webinare verschaffen möchte, kann dies natürlich gerne in unserem Webinar-Archiv tun.

Christian Stein
Christian Stein
Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".