Redis in ioBroker - Überblick

[apollon77]

Dieser Forum-Thread soll zum Thema ioBroker-Datenbanken und speziell der Option "Redis" als Datenbank zu nutzen informieren und Fragen beantworten. Er soll auch Hintergründe liefern, sodass jeder entscheiden kann ob dies das richtige für sein System ist oder nicht!

ioBroker Datenbank - einige Hintergründe

Ein ioBroker-System lebt von Daten und das diese Daten zwischen den verschiedenen Adaptern ausgetauscht werden. Adapter liefern ständig neue Informationen, in Skripten werden diese verarbeitet und basierend darauf werden neue Aktionen ausgelöst. Die dahinter liegenden Daten und Konfigurationen müssen für alle ioBroker-Komponenten performant und sicher abrufbar sein, damit das System schnell auf Änderungen reagieren kann.

Wenn ioBroker installiert wird, werden in der Standardkonfiguration die Daten in integrierten Datenbanken abgelegt - diese Konfiguration wird "file" genannt.

Diese integrierten Datenbanken sind erprobt, leistungsfähig und benötigen keine zusätzlich zu installierende Software. Das vereinfacht die Einrichtung und Nutzung des Systems.

Konkret bedeutet "file", dass der js-controller die Objects- und States-Daten direkt in seinem RAM-Speicher verwaltet (="In-Memory Data Store"). Der Datenzugriff auf In-Memory-Daten ist extrem schnell. Nachteil ist, dass diese Daten ohne Zwischenspeicherung bei jedem Stopp des js-controllers-Prozesses verloren gehen würden.

Damit die Daten nach einem Neustart des ioBroker-Servers wieder zur Verfügung stehen, werden "file"-Datenbanken bei Änderungen deshalb regelmäßig in das Dateisystem gesichert. Bei der Objects-Datenbank, die sich selten ändert, ist das 5s nach einer Änderung und bei der States-Datenbank sind es 30s nach einer Änderung. Diese Zeiten sind so gewählt, dass Performance, Verschleiß (z.B. SD-Karten) und Datensicherheit ausgewogen sind. Dieser Speichervorgang wird „Persistierung“ genannt.

Die persistierten Datenbanken werden in Form von JSON-Dateien im "iobroker-data"-Ordner gespeichert. Deren Inhalt kann man sich ansehen, aber bitte keinesfalls selbst ändern.

Dieses Setup wird für die meisten Installationen mit State- und Objektanzahlen bis weit in den 5-stelligen Bereich und mehreren 10.000 Ereignissen/15s selbst auf einem aktuellen Raspberrry Pi problemlos funktionieren.

Wenn aber der js-controller-Prozess ständig über 50-70% CPU in Anspruch nimmt oder seine IO-Last im Dateisystem spürbar wird, kann es Zeit werden sich über den Einsatz von Redis Gedanken zu machen

Redis-Datenbank - Was ist das und was bringt es?

Bei Performanceproblemen wegen vieler Datenänderungen bietet ioBroker für große Systeme die Möglichkeit, alternativ zur internen Datenhaltung, die externe Datenbank-Software Redis (https://redis.io/) einzubinden. Diese Konfiguration wird "redis" genannt.

Redis ist genauso wie die im js-controller integrierte "file"-Datenbank ein "In-Memory Data Store". Auch hier werden alle Daten im RAM abgelegt. Im Gegensatz zum js-controller, der in der Programmiersprache JavaScript geschrieben ist, ist Redis zu großen Teilen in C programmiert. Damit kann das für Datenhaltung optimierte Redis z.B. CPU-Ressourcen deutlich besser nutzen.
Der erste Geschwindigkeitsgewinn entsteht üblicherweise, indem man die States-Datenbank auf Redis umstellt, da diese Daten viel öfter geändert werden. Bei einer Umstellung der States-Datenbanken auf Redis bleibt die RAM-Nutzung nahezu gleich. Was der js-controller einspart benötigt jetzt der zusätzliche Redis-Prozess.

ioBroker unterstützte bislang die Möglichkeit, die States-Datenbank alternativ in Redis abzulegen. Neu mit js-controller 2.0 können jetzt neben Objekte auch Dateien im Redis abgelegt werden. Werden Dateien in Redis gespeichert, werden diese dort vollständig im RAM gehalten. Deswegen macht dies nur für Systeme mit mehr als 2GB Speicher Sinn!

Redis muss allerdings als eigener Dienst installiert und konfiguriert werden und auch die Daten wollen beim Backup entsprechend berücksichtigt sein. Das ioBroker System wird also etwas komplexer und jeder Nutzer, der sich für Redis entscheidet, muss sich entsprechend darin einarbeiten.

Redis bietet verglichen mit den internen ioBroker-Datenbanken vor allem Vorteile in den Bereichen Datenzugriffsgeschwindigkeit, IO-Management im Dateisystem und bessere Nutzung von CPU-Ressourcen. Der js-controller wird entlastet. Ein vorher träges System kann wieder schneller werden. Zudem wird damit ioBroker bis hin zu größten professionellen Installationen skalierbar.

Redis einrichten

Diese Anleitung wird vor allem Beispiele für Linux-Systeme wie Ubuntu oder Debian beinhalten. Wer also eine Redis-Datenbank auf einem NAS nutzt, muss bitte schauen was er genau wie anpassen muss. Achtung: Für Windows gibt es keine offiziellen Redis-Builds. Es gibt ältere Versionen die durchaus funktionieren, aber hier sollte man gut überlegen ob das der korrekte Weg ist! (https://github.com/microsoftarchive/redis)

Die Abschnitte weiter unten beschäftigen sich auch damit wo man für welches Szenario den Redis am besten installiert, also bitte vor der Installation weiterlesen

Unter Ubuntu und Debian sind in den Standard-Repositories meist ältere Redis Versionen enthalten. ioBroker benötigt mindestens Version 2.6.0 von Redis, aktuell ist Version 5.x.
Für Ubuntu gibt es ein PPA (https://launchpad.net/~chris-lea/+archive/ubuntu/redis-server), das aktuelle Versionen bereitstellt.

Mit folgenden Kommandos installiert man damit Redis auf einem Ubuntu-System:

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

Danach ist Redis an sich installiert und auch bereits automatisch gestartet.

Ein sudo systemctl status redis-server zeigt den Status an. Falls es bei einem Reboot nicht automatisch wieder startet hilft ein sudo systemctl enable redis-server.

Redis nutzt standardmäßig Port 6379 und bringt auch ein Kommandozeilentool für den Zugriff zur Datenbank mit: redis-cli öffnet eine Shell. Der Befehl info zeigt einige Informationen zum System, Speicherverbrauch und zu den gespeicherten Daten ("Keyspace") an, der natürlich aktuell noch leer ist.

Wenn man ein Single-Host -System betreibt bzw. ioBroker auf dem gleichen Host läuft dann war es das auch schon.

Falls auch andere Hosts auf diesen Redis-Server zugreifen sollen (Slaves oder so), dann muss dies noch erlaubt werden. Dazu muss /etc/redis/redis.conf editiert werden und die Zeile bind 127.0.0.1 zu bind 0.0.0.0 geändert werden und direkt darunter der protected_mode auf no gesetzt werden.

Danach startet sudo systemctl restart redis-server den Server mit der aktualisierten Konfiguration neu.

Redis Backup (Persistenz) und Datensicherheits-Optionen

Normalerweise ist Redis eine "In-Speicher-Datenbank". Die Daten lagern also, wie oben schon erwähnt, im RAM. Wenn Redis beendet wird sind diese also weg. Um aber auch ein Update zu ermöglichen, unterstützt Redis zwei Arten der Datenspeicherung auf Festplatte.

Persistenz: RDB Dateien (Redis-Database-Dump-Datei)

Die erste Option ist das Speichern des gesamten Inhalts in einer Datei (RDB), welches beim Start wieder geladen wird. Diese Speicherung kann durch Kommandos angestoßen werden (BGSAVE) oder es kann konfiguriert werden nach wie vielen Datenänderungen pro Zeit die Datei geschrieben wird. Diese Persistenz ist standardmäßig aktiviert und speichert beispielsweise mindestens alle 15 Minuten wenn es eine Änderung gab oder öfter bei mehr Änderungen.
Dies zu konfigurieren sollte eine Mischung aus Datensicherheit (wie viele Daten kann man verkraften bei einem Crash zu verlieren) und Schreiblast für das Speichermedium, da immer der gesamte Inhalt geschrieben wird. Die ioBroker-eigene Datenbank speichert die Daten aktuell öfter als die Redis-Standard-Konfiguration.

Persistenz: AOF Dateien (Append-Only File)

Die zweite Option generiert mehr Schreiblast im Dateisystem, stellt aber sicher das die Daten ganz aktuell sind. Dazu wird fortlaufend eine sog. AOF Datei geschrieben, wo alle Änderungen immer angehängt werden. In regelmäßigen Abständen wird diese Datei dann konsolidiert und verkleinert sich damit wieder. Man erkauft sich also im Crash-Fall aktuelle Daten mit einer höheren Schreiblast. Für SD-Karten ist dies also eher nicht empfohlen. Für die Konfiguration verweise ich auf das kommentierte Konfig-File von Redis oder den untenstehenden Link.

Persistenz RAM-Bedarf

Wichtig ist zu beachten, dass beide Persistenz-Verfahren zum Zeitpunkt der Speicherung bzw. Konsolidierung der Daten zusätzliches RAM benötigen - teilweise das doppelte! Falls dieser RAM nicht verfügbar ist läuft - je nach Einstellungen - alles problemlos weiter. Ein Backup der Daten wird dann allerdings nicht erzeugt! Entsprechende Meldungen stehen nur im Logfile. Das muss also geprüft werden.

Redis - Persistenz Anwendungsgebiete

Beide Dateien kann man grundsätzlich als Backup sichern und kopieren, das Dump File ist dazu allerdings besser geeignet. Es ist allerdings auch möglich generell nur AOF zu nutzen und direkt vor dem Backup ein RDB-Dump File ganz aktuell mittels redis-cli BGSAVE erstellen lassen und dies nach ein paar Sekunden kopieren.
Beide Optionen helfen allerdings nicht, wenn das Dateisystem des Rechners Fehler hat - dann sind die Daten in jedem Fall weg und man fällt auf das letzte Backup zurück. Eine Option das abzusichern sind Redis-Slaves (siehe nächster Punkt)
Mehr Details zur Persistenz gibt es unter https://redis.io/topics/persistence

Redis Slaves

Eine zweite Möglichkeit immer aktuelle Daten als Sicherung zu haben ist die Einrichtung eines zweiten Redis-Servers, der als Slave mit dem Haupt-Redis verbunden ist. Alle Datenänderungen werden vom Master an diesen Host durchgereicht. Er muss aber auf einem zweiten Rechner (oder mindestens Dateisystem) laufen, weil sonst kein echter Vorteil existiert.

Wenn der Rechner mit dem Master-Redis defekt ist, existieren immer noch die Daten nahezu Echtzeit-aktuell auf dem Slave. Man kann diesen also nutzen um einen Dump zu erstellen um den Master neu aufzusetzen, oder man macht als schnelle Lösung den Slave zum Master und ändert die Datenbank-IPs im ioBroker und ist fast aktuell wieder online.
"Fast aktuell" in den letzten Sätzen bedeutet das Redis keine 100%ige Garantie für die Aktualität der Slaves gibt, da die Synchronisierung erfolgt nachdem eine Änderung schon an das Skript bestätigt wurde. Wenn der Master also abstürzt bevor eine Änderung zum Slave übertragen wurde, so ist diese gegebenenfalls im Slave nicht enthalten. Aber im Normalfall ist dies ein geringes Risiko und betrifft nur sehr wenige Änderungen - wenn überhaupt.

Ein Slave schützt allerdings nicht gegen das versehentliche Löschen von Daten, da diese auf dem Slave auch direkt danach gelöscht sind. Hier helfen nur Backups.

Wer also die Hardware-Möglichkeiten hat sollte, zusätzlich zum Backup einer RDB-Datei in regelmäßigen Abständen, einen Redis-Slave einrichten.

Dazu installiert man Redis auf dem zweiten Host ganz normal, definiert, allerdings im redis.conf mittels replicaof den Redis-Master Host und Port. Details siehe z.B. in der kommentierten Konfig-Datei unter https://raw.githubusercontent.com/antirez/redis/5.0/redis.conf

ioBroker-States-Datenbank auf Redis umstellen

Wie oben bereits geschrieben finden die meisten Änderungen und Datenabfragen mit die States-Datenbank statt. Alle Datenänderungen kommen hier an und werden dann wieder auf Adapter verteilt, wenn diese sich für bestimmte Daten angemeldet haben. Eine Umstellung der States auf Redis hat damit mit Abstand den größten und spürbarsten Performance-Effekt.

Wer nur die States-Datenbank umstellt, sollte den Redis-Server idealerweise auf dem gleichen Host installieren wie den ioBroker-Master. Wenn die States-Datenbank nicht verfügbar ist, beendet sich der Controller nach einer gewissen Wartezeit. Wenn der Redis also auf dem gleichen Host ist wie der Master-Controller, gibt es weniger Szenarien die zu Ausfällen führen.

Die Umstellung der States erfolgt dann über:

iobroker stop
iobroker setup custom

Dann für die "Objects" die aktuellen Einstellungen bestätigen ("file" als Typ, IP, Port 9001) und bei "States" jetzt als Typ "redis", die IP des Redis-Hostservers (bzw. 127.0.01 wenn auf dem gleichen Host) und 6379 als Port einstellen. Damit man nicht alle State-Daten verliert bietet es sich an die Daten zu migrieren, was die nächsten Fragen beid er Konfiguration abfragen.

Nach der Migration kann ioBroker mit iobroker start neu gestartet werden. Falls man auch Slave-Systeme einsetzt, so müssen dort überall die gleichen Einstellungen über iobroker setup custom vorgenommen werden. Allerdings ist die Frage nach der Migration zu verneinen!

Danach sollte das System problemlos wie vorher funktionieren, der js-controller allerdings weniger CPU und RAM benötigen. Der RAM-Verbrauch insgesamt sollte nahezu identisch sein, weil die State-Daten jetzt im Redis liegen und nicht mehr durch den js-controller verwaltet werden.

Das Risiko bei Datenverlusten ist bei den State-Daten meist nicht so groß, da sich diese über die Zeit meist selbst wieder aktualisieren (außer z.B. bei Zählern). Hier kann man also auch beim Redis-Backup gegebenenfalls pragmatisch sein. Eines haben sollte man aber trotzdem, da Skripte gern davon ausgehen das nötigr States auch Werte haben. Nicht vergessen: Auch ioBroker muss immer noch gesichert werden, da dort immer noch die Objektdefinitionen und Dateien liegen (z.B. mit iobroker backup).

ioBroker-States-/Objects-/File-Datenbank auf Redis umstellen

Seit js-controller 2.0 kann auch die Objects- UND File-Datenbank durch Redis verwaltet werden. Der Schritt dies zu nutzen sollte sehr gut überlegt sein! Hier muss einiges beachtet werden, damit es im Fehlerfall nicht zu großen Problemen oder Ausfällen kommt.

Welche Auswirkungen hat das?

Der Haupt-Effekt alle Daten (States, Objekte UND Dateien) im Redis abzulegen ist, dass nichts davon mehr auf einzelnen Rechnern im Dateisystem liegt, sondern alles in Datenbanken im RAM vorgehalten wird. Der Zugriff ist damit, vor allem bei Files, etwas schneller - falls das Speichermedium langsam ist.

Eine ioBroker Installation wird damit also sehr unabhängig. Das frühere "Master/Slave"-Denken ändert sich ebenfalls. Alle js-controller und alle Adapter verbinden sich alle zur zentralen Redis-Datenbank, welche damit zum eigentlichen Koordinator - oder in bisherigem Wortgebrauch "Master" wird. Jeder js-controller kennt nur die Adapterinstanzen die zu seinem Host gehören und kümmert sich darum, dass diese gestartet oder beendet werden. Mehr tut er nicht mehr. Falls ein js-controller Prozess ausfällt, hat das keine Auswirkungen auf die anderen js-controller.

Falls jedoch der Redis-Server ausfällt oder neu gestartet wird, ist das gesamte System betroffen - wie früher beim ioBroker-Master-Controller.

Auch der Fakt das sämtliche Daten im Redis liegen bedeutet, dass man sich ein gutes Backup-Konzept ausdenken muss und auf dem Redis-System auch genügend RAM verfügbar haben muss. Da nun auch alle Dateien im RAM abgelegt sind, kann die Redis-Datenbank schnell auch mal einige hundert MB groß werden!

Warum/Wann sollte man das tun?

Diese komplette Umstellung wird (im Vergleich zu rUmstellung der States-Datenbank) nicht so wirklich große Performance-Gewinne mit sich bringen. Also warum ist das sinnvoll?
Es gibt mehrere valide Anwendungsfälle. Einige davon hier als Beispiel. Ihr habt mehr? Berichtet gern unten im Thread.

Vorweg: Wenn Ihr einen ioBroker-Host nutzt und keine Slaves, dann ist diese Option für Euch in meinen Augen nicht sonderlich sinnvoll. Die eigentlichen Stärken werden erst durch ein verteiltes ioBroker-System wirklich ausgenutzt.

1. Wer eine NAS hat, welche sowieso 24/7 läuft, genug verfügbares RAM und die Option hat dort einen Redis-Server laufen zu lassen kann so eine sichere Datenspeicherung erreichen. Durch ein darunter liegendes RAID ggf. sehr sicher. Die ioBroker Server können damit einfache Raspis mit SD Karten sein. Dort werden die Adapter installiert und ausgeführt. Da aber viel weniger Daten im Dateisystem geschrieben werden halten die SD-Karten ggf. um einiges länger. Auf den Raspis aber Redis-Slaves laufen zu lassen mit allen Daten ist wohl nur bei Raspi 4 mit 4GB RAM sinnvoll. In so einem Szenario, und ausgehend von echten HDDs im NAS, eignet sich die AOF-Persistenz mit regelmäßigem RDB-Backup (auf einen anderen Host als die NAS) recht gut. Die NAS wird allerdings zum "Single-Point-of-Failure" - ist Sie defekt ist ioBroker ebenfalls offline. Dies lässt sich nur mit mindestens einem gesonderten Redis-Slave absichern.

2. Wer mehr Flexibilität möchte wie das ioBroker System aufgestellt werden kann und auch einzelne Hosts mal offline nehmen können will, ohne dass der ganze Rest auch betroffen ist, kann ebenfalls diese Option überlegen. Wichtig ist allerdings das genügend RAM verfügbar ist und auch ein Backup bzw. ein Slave verfügbar ist

3. Geplant wurde das Feature in Vorbereitung für die Möglichkeit ein ioBroker System hochverfügbar zu machen. Dazu ist aber noch einiges mehr nötig. Siehe dazu im nächsten Beitrag "Redis Sentinel“.

Die Umstellung

Die Umstellung ist am Ende so einfach wie bei der States-Umstellung:

iobroker stop
iobroker setup custom

Dort bei beiden Datenbanken den Typ "redis" wählen, IP und Port des Redis-Hosts eingeben und ggf. die Daten migrieren. Das wird eine Weile dauern. Bitte alle Hinweise während der Umstellung beachten.

States und Objekte im gleichen oder getrennten Redis-Prozessen?

Am einfachsten ist es natürlich, States und Objekte zusammen in einem Redis-Prozess speichern zu lassen. Dies bedeutet allerdings auch das nur alle Daten zusammen gesichert werden können. Bei der ioBroker File-DB waren States, Objekte und Files getrennt und konnten so selektiv gesichert werden. Auch die Schreiblast ist, wenn alles in einem Redis gespeichert ist, höher, da die Datenbank größer ist.

Um auch mit einem Redis-Setup die sich oft ändernden States und nicht so oft geänderten Objekte und Dateien zu trennen, kann man einfach zwei Redis-Prozesse je Host nutzen. Anleitungen dazu gibt es zB unter https://gist.github.com/inecmc/f40ca0ee622e86999d9aa016c1b15e8c .

Bei iobroker setup custom werden einfach die jeweiligen unterschiedlichen Ports für States bzw. Objekte/Dateien angegeben.

[apollon77]

In diesem Zusatzbeitrag wird es recht speziell, da es um Vorbereitungen für ein Hochverfügbares iobroker-System geht. Für die meisten Home-Automation-Systeme ist dies ggf gar nicht so relevant. Auch wird die gesamte Installation um einiges komplexer und man muss sich noch tiefer mit den Themen beschäftigen.

Redis-Sentinel - Erste Schritte in Richtung Hochverfügbarkeit

Über die Vorteile eines Systems mit einem Redis-Server und einem oder mehreren Slaves ist weiter oben schon einiges gesagt worden. Dennoch ist ein Master-Slave Setup erst einmal statisch. Falls der Master ausfällt sind keine Änderungen an den Daten mehr möglich. Man kann die Server auch dynamisch umkonfigurieren und so aus einem Slave einen neuen Master machen. Das manuell bei allen Slaves zu machen nachdem es passiert ist und man es mitbekommen hat führt immer noch zu einem längeren Ausfall des Systems.

Was ist Redis Sentinel?

Die Lösung der Redis-Entwickler dies alles zu automatisieren heißt "Redis Sentinel". Der Sentinel ist ein zusätzlicher Prozess, welcher den Redis-Master und die Slaves überwacht und reagiert sobald der Master nicht mehr erreichbar ist. Dann stimmen sich die Sentinel-Prozesse ab und wählen einen neuen Master aus. Hat dies stattgefunden werden die restlichen Redis-Hosts entsprechend automatisch umkonfiguriert.
Über eine Verbindung zu den Sentinel-Prozessen kann abgefragt werden, welcher Host gerade der Master ist.

Die einzige Bedingung dafür ist das mindestens 3 Sentinel-Prozesse auf getrennten Hosts laufen müssen - und idealerweise passend dazu eine entsprechende Anzahl an Redis-Hosts. Mehr Prozesse gehen auch, am besten immer eine ungerade Anzahl. Jeder dieser Hosts muss natürlich genügend RAM verfügbar haben um alle Daten im Speicher zu haben.

Zur Abstimmung über einen neuen Master muss eine Mehrheit vorliegen - bei 3 Hosts müssen also 2 noch erreichbar sein um einen neuen Master zu bestimmen. Bei 5 Hosts werden 3 Stimmen benötigt. Falls keine Mehrheit gefunden werden kann wird kein neuer Master bestimmt und das System bleibt erst einmal offline. Dies passiert um sicherzustellen das es zu keinen sog. "Split-Brain"-Situationen kommt, in denen Untergruppen aktiv sind und sich damit verschiedene Datenstände entwickeln, die am Ende nicht mehr zusammengebracht werden können.

Ein Sentinel Setup benötigt also entsprechende Hardware!

Ausführliche Informationen zu Redis Sentinel (für jeden der es nutzen will fast schon Pflichtlektüre!) gibt es unter https://redis.io/topics/sentinel

Was bringt mir das?

Mit dem notwendigen Hardware-Einsatz kann man ein System aufbauen in dem ioBroker auf mehreren Hosts verteilt laufen kann und auch die Datenbank verteilt läuft. Die Datenbank ist jetzt "Hochverfügbar". SObald ein Host ausfällt übernimmt ein anderer die Rolle des Datenbank-Masters. Alle Adapter erkennen dies und verbinden sich neu. Alles läuft ohne Unterbrechung weiter und Daten gehen nicht verloren.

Um auch die ioBroker js-controller und Adapter hochverfügbar zu machen fehlen noch ein paar Teile, die in der nächsten Zeit geplant sind.

Sentinel einrichten

Der Redis-Sentinel wird mit sudo apt-get install redis-sentinel installiert - auf mindestens 3 Hosts, idealerweise gemeinsam mit den Redis-Prozessen. Die Redis-Prozesse müssen als Master-Slave-System konfiguriert sein und so laufen.
In der Sentinel Konfiguration müssen nun die gleichen Anpassungen bei bind und protected_mode wie beim Redis gemacht werden, damit die ioBroker-Hosts auf den Sentinel zugreifen können.
Standardmässig ist der Name für den Master "mymaster". Um dies zu ändern muss der Name bei allen relevanten Einstellungen in der Konfigurationsdatei angepasst werden.
Darüber hinaus sollte man die Einstellung sentinel failover-timeout mymaster 20000 setzen, da sonst ein Failover (Wahl und Umstellung auf einen neuen Master) bis zu 6 Minuten dauern kann und zu einem kurzen Ausfall führt. Mit der Einstellung sollte eine Wahl in maximal 40s erledigt sein.

Im Falle eines Ausfalls des Masters braucht der Sentinel ca 20-30s um diesen zu erkennen und eine Wahl zu Starten, welche damit nach 40-70s (je nachdem ob eine oder zwei Abstimmungen nötig sind) erledigt sein sollte. js-controller und Adapter-Prozesse beenden sich nach ca. 90s nach Verbindungsverlust.

Ansonsten fehlt nur die Anpassung der IP des Redis-Masters in der Konfiguration sentinel monitor mymaster 127.0.0.1 6379 2. Das Ganze in allen Redis-Sentinel-Konfigurationen. Wer sich wundert: Die Sentinel Prozesse sind untereinander nirgends konfiguriert - diese finden sich über den Redis-Master.

Unter /var/log/redis/redis-sentinel.log sollten nun alle Slaves ebenfalls mit einem +slave aufgelistet sein.

ioBroker für Redis-Sentinel konfigurieren

Die Konfiguration von ioBroker erfolgt wieder über iobroker setup custom. Als Typ muss "redis" gewählt werden. Als "Host" muss nun die Komma-getrennte Liste aller Sentinel-Hosts angegeben werden. Bei Port entweder der Redis-Sentinel-Port (Standard 26739) oder die Komma-getrennte Liste der Ports passend zu den angegebenen Hosts. Die nächste Abfrage gilt dem Sentinel-Master-Namen (Standard: mymaster). Wenn die Daten vorher schon im Redis-System waren, dann ist auch keine Migration nötig.

Danach einfach starten und wenn alles korrekt ist erfragt ioBroker beim Sentinel den aktuellen Master und verbindet sich dort hin. Falls ioBroker die Verbindung zum Master verliert wird der aktuelle Master wieder erneut vom Sentinel abgefragt und die Verbindung erneuert. Daten gehen im Normalfall nicht verloren.

Wenn, wie oben angeregt, getrennte Redis-Prozesse für States und Objects/Dateien eingesetzt werden, muss die Sentinel-Konfiguration ebenso verdoppelt werden und eindeutige Sentinel-Master-Namen gewählt werden (z.B. states-master und objects-master). Es muss aber kein zweiter Sentinel installiert werden! Ein Sentinel-Prozess kann mehrere Redis-Master gleichzeitig überwachen. Es kann dann aber dazu kommen das der States-Master und der Objects-Master auf verschiedenen Hosts liegen.

[apollon77]

Redis FAQ

1. Brauche ich Redis für meinen ioBroker oder nicht?
Für alle üblichen Installationen reichen normalerweise die ioBroker-eigenen Datenbanken vollkommen aus! Erst wenn der js-controller dauerhaft 50-70% oder mehr CPU braucht und sich das System gleichzeitig träge anfühlt kann es Sinn machen sich mit dem Thema Redis zu beschäftigen. Alternativ wird es nötig wenn man ein hochverfügbares ioBroker System anstrebt, aber dazu sich noch einige Dinge mehr nötig.

2. Wie finde ich heraus ob ich Redis nutze oder nicht?
Ein Aufruf von iobroker status zeigt an welcher Datenbanktyp für die States- und Objects-Datenbanken verwendet werden. "file" bedeutet das die ioBroker eigenen Datenbanken genutzt werden. "redis" bedeutet das ein Redis im Einsatz ist.

[sigi234]

@apollon77

Jetzt brauche ich Urlaub.

[Marty56]

Super Artikel.
Ich war wohl etwas voreilig und habe auch die Objekte auf Redis umgestellt, was bei mir nach Lektüre des Artikels gar nicht sinnvoll ist.
Es läuft und ich habe sogar den Eindruck, dass ich mehr RAM habe, als vorher, was eigentlich nicht sein kann.

Kann ich die Speicherung der Objekte unproblematisch wieder auf file umstellen?

Sprich kann ich mit iobroker stepup custom auch wieder zurück auf file bei den Objekten?

Und noch ein zweite Frage. Ist redis mit dem backup Adapter kompatibel?

[Chaot]

@apollon77
Herzlichen Dank für die (endlich) Aufklärung und die umfangreichen Erklärungen dazu.
Mir ist allerdings etwas aufgefallen.
Die Config liegt bei mir woanders.
nicht

/etc/redis/redis-server.conf

sondern

/etc/redis/redis.conf

[darkiop]

@apollon77 Top, Lesestoff fürs Wochenende

Vielleicht noch als Vorschlag für ein weiteres Kapitel: Die Docker-Fraktion wird dafür wohl einen eigenen Container aufsetzen (läuft bei mir seit 3 Wochen sehr stabil)

[apollon77]

@Marty56 ja du kannst jederzeit in alle Richtungen mit dem controller 2.0. Auch die Migration funktioniert dann und macht alles so wie es nötig ist.

Der backitup Adapter kann sogar die Redis-DB sichern ... könnte man noch erweitern oben - Ich habe mich nur damit noch nicht beschäftigt.

[apollon77]

@Chaot Du hast Recht. Aktualisiert!

[apollon77]

@darkiop Auch ich habe mein Sentinel Test-Setup in LXC-Containern auf Proxmox laufen ... fmit Docker hab ich gerade zu wenig Erfahrung. Wenn jemand einen Text schreibt nehme ich es gern oben mit auf oder (vllt sinnvoller) als extra Thread den wir dann verlinken.

[darkiop]

@apollon77 sagte in Redis in ioBroker - Überblick:

Der backitup Adapter kann sogar die Redis-DB sichern ... könnte man noch erweitern oben - Ich habe mich nur damit noch nicht beschäftigt.

Wobei der allerdings von einer lokalen Redis Installation ausgeht, @simatec ggf. kann man hier in Zukunft auch aufh "externe" Redis-DBs schauen?

@apollon77 sagte in Redis in ioBroker - Überblick:

Auch ich habe mein Sentinel Test-Setup in LXC-Containern auf Proxmox laufen ... fmit Docker hab ich gerade zu wenig Erfahrung. Wenn jemand einen Text schreibt nehme ich es gern oben mit auf oder (vllt sinnvoller) als extra Thread den wir dann verlinken.

Das strebe ich für die Zukunft evtl. auch noch an - Ein Nuc i3/i5 auf dem denn alles zusammen läuft und nicht mehr auf der Syno 918+. Wobei ich mich an Docker gewöhnt habe und eigentlich sehr zufrieden bin

Viel gibt es da aber auch nicht zu tun. Container mit

docker run -d \
--name iobroker-redis \
--hostname iobroker-redis \
--user=1026 \
--volume /volume2/docker-ssd/iobroker-redis/data:/data \
--network=mac0 \
--ip=192.168.1.86 \
--dns=192.168.1.43 \
--restart=always \
redis:latest

starten (Netzwerk natürlich zuvor auf eigene Umgebung anpassen).

Verbindung zur Redis-DB testen:

docker run -it --network mac0 --rm redis:latest redis-cli -h iobroker-redis

Die Konfiguration des ioBroker erfolgt ja anlog der "lokalen" Redis Installation.

[apollon77]

@darkiop ich denke das backitup nicht so einfach an das dump file eines externen redis ran kommt oder?!

Bei Docker wäre also der Trick das /var/lib/redis nach außen zu Mappen wie es in deinem Beispiel ist und dann kannst du es so sichern. Und es übersteht auch restarts.

[darkiop]

@apollon77 sagte in Redis in ioBroker - Überblick:

Bei Docker wäre also der Trick das /var/lib/redis nach außen zu Mappen wie es in deinem Beispiel ist und dann kannst du es so sichern. Und es übersteht auch restarts.

Du meinst /data (vom redis Contrainer) nach /var/lib/redis in den ioBroker Container zuhängen? Das kann ich gerne mal probieren. Mit meiner jetztigen Config übersteht /data aber auch restarts.

[apollon77]

@darkiop ich denke das data Volume von deinem Container ist genau das was ich meine. Alles gut. Wenn da eine dump.rdb drin ist passts

[simatec]

@apollon77 sagte in Redis in ioBroker - Überblick:

@darkiop ich denke das backitup nicht so einfach an das dump file eines externen redis ran kommt oder?!

Bei Docker wäre also der Trick das /var/lib/redis nach außen zu Mappen wie es in deinem Beispiel ist und dann kannst du es so sichern. Und es übersteht auch restarts.

Es wäre auf jeden Fall eine Überlegung, das mit in backitup aufzunehmen oder.
Bisher unterstützt backitup die lokale Sicherung der redis db

[apollon77]

@simatec die Frage ist halt wie du an das dump rankommet. Wenn das geht dann ist es nur ein file.

[simatec]

@apollon77
Da gebe ich dir recht ... wie könnten wir Systemübergreifend hier einen Zugriff hinbekommen?

Aktuell fällt mir ohne Freigaben des auf dem externen System nix ein 🧐

[apollon77]

@simatec Ich denke das ich dann sehr schnell sehr vielfältig. Aber ja irgendwie Freigaben

[bauzi]

danke für den Link

[JojoS]

ich habe aus Neugier auch mal Redis installiert. Unter Windows 10 geht das auch mit WSL, ich habe die Ubuntu 18.04 Tools installiert und mit 'sudo apt install redis' bekommt man eine Version 4.0.9. Ist die aktuell genug? Ich hatte zuerst die 5.0.7 von der redis website installiert und kompiliert, damit läuft ioBroker auch komplett lokal unter Win10.
Wenn auf redis umgestellt ist und der server nicht läuft, dann startet der ioBroker Dienst nicht. Bzw. beendet wohl mit Fehler den er nicht anzeigt, nur im EventLog taucht eine Warning auf das der Controller beendet wurde.