[Projekt] ioBroker Redundanz/HotStandby
-
@andygr42 Der Teil für JSONL eine migration zu bauen und alles da drum herum fehlt noch ...
-
@apollon77 Die JSONL Datei ist also immer zum Schreiben geöffnet? Damit wäre auch ein Snapshot unsauber. Ich überlege gerade ob es nicht ganz einfach möglich ist, die on-the-fly-backup Dateien zu verwenden. Das erfüllt zwar nicht die Anforderung nach maximal 5 Minuten Datenverlust, wäre aber eine sehr simple Methode ein Standby System zu erstellen. Der Rest des iobroker Verzeichnis sollte sich ja mit rsync spiegeln lassen.
-
@andygr42 sagte in [Projekt] ioBroker Redundanz/HotStandby:
on-the-fly-backup Dateien
Was meinst Du damit?
Also wenn du sowas willst dann ist Redis das einfachste. Auf einem ioBroker host der Redis master und einen Redis slave. Der bekommt vom Master alle änderungen. Das geht auch "Statisch" ohne Sentinel und Auto changeover und so ... aber damit wäre das "Db repliziert" am einfachsten. Brauchstnur etwas mehr RAM weil halt States und Objekte im RAM liegen bei Redis
-
@apollon77 iobroker / JSONL legt automatisch Backup Dateien an, gemäß der Konfiguration im iobroker Host selbst. Das Interval ist mit 2h recht lang, kann aber natürlich verkleinert werden. Der Charme dabei ist halt, dass ich sehr einfach einen manuelle Failback machen kann, indem ich einfach das Verzeichnis im offline Mode wieder zurück kopieren. Ob das mit redis auch so einfach geht, muss ich mir mal anschauen, aber ansonsten ist eine Datenbankreplikation natürlich eleganter. Zumal man den Status der Replikation mit in die Entscheidung für den Failover einfließen lassen könnte.
-
Hallo Zusammen!
Ich habe mir eure Lösungen angesehen, halte sie aber für technisch zu kompliziert. Ausserdem ist ja immer ein "händischer" Eingriff erforderlich.
Eine Art Ausfallsicherheit stelle ich mir anders vor.
Meine Installation: ich betreibe ein ioBroker Multihost-System mit einem "Master" und 6 Slaves (alles Raspis). Master deswegen in Anführungszeichen, weil das bei mir jetzt schon vom Prinzip her kein echter Master mehr ist. Denn ich habe alle Daten (states und objects) in einem Redis Sentinel Cluster bereits ausfallsicher/HA. Man kann ioBroker also von jedem Raspi aus bedienen.
Leider muss man ja die laufenden Adapter-Instanzen jeweils einem ioBroker-Client zuordnen. Damit erreicht man zwar eine Lastverteilung, aber trotzdem wird jeder Raspi für die ihm zugewiesenen Adapater-Instanzen zum single-point-of-failure.
Meine Idee/Vorstellung wäre ein Watchdog (sowas gibt es ja bereits), der die Verfügbarkeit einer ioBroker-Instanz (= 1 Raspi) prüft und bei Ausfall alle auf dieser Node zugewiesenen Adapter-Instanzen auf andere Nodes im Setup verteilt und dort neu startet. Das würde eine relativ einfache und automatische Ausfallsicherheit ermöglichen. Man könnte sogar mit einfachen Quorum-Methoden entscheiden, ob eine Node wirklich ausgefallen ist und wo man die hängenden Adapter-Instanzen neu startet.
Idealerweise werden umverteilte Adapter-Instanzen dann nach Wiederverfügbarkeit der ausgefallenen Node auf den "Notfall-Nodes" gestoppt und laufen dann wieder auf der ursprünglichen Node an.
Gleiches sollte auch für JScripten (und Blocklys) durchgeführt werden, denn auch die können ja beim Ausfall der Node, auf der sie laufen, zu Systemproblemen oder Nicht-Funktionalität führen. Ein einfacher Neustart auf einer Ersatz-Node und Rück-Switch nach Wiederanlauf der ausgefallenen Node ist ja auch kein Hexenwerk.
Was haltet ihr von der Idee? Jetzt muss ich nur noch nach dem grundsätzlichen Ansetzpunkt für eine Umsetzung suchen... wer kann da helfen, Entwicklungs-KnowHow aus 35 Jahren ist vorhanden.
-
@higginsd sagte in [Projekt] ioBroker Redundanz/HotStandby:
Meine Idee/Vorstellung wäre ein Watchdog (sowas gibt es ja bereits), der die Verfügbarkeit einer ioBroker-Instanz (= 1 Raspi) prüft und bei Ausfall alle auf dieser Node zugewiesenen Adapter-Instanzen auf andere Nodes im Setup verteilt und dort neu startet.
Jupp, diese Idee steht unter dem begriff eines "HA Adapters" auf der Ideen/TodoLliste. Das ganze Thema Redis Sentinel war dazu ein wichtiger Schritt und auch das die js-controller Instanzen seit dem js-controller 4 intern einen "Master" auswählen ein Puzzlestück dazu.
Die größere Idee ist das man in dem HA Adapter auswählt welche Instanzen verschoben werden dürfen und welche nicht (weil Sie zb eh an lokalen Seriellen Ports hängen -zigbee, smartmeter ggf - oder lokale Daten haben - history zb) und den Default-Host der Instanz. Dann kommt auf jeden Host der ggf Instanzempfänger sein kann eine HA-Adapter-Instanz.
Im Fall der Fälle bekommt eine dieser Instanzen dann den Auftrag die gerade offline gegangenen Instanzen umzuverteilen.
In der Theorie einfach, in der Praxis komplex weil es wieder eine Millionen Edge-Cases gibt, mal Beispiele:
- Ein einfacher Reboot oder geplante Wartung eines Hosts sollte das nicht direkt auslösen
- Die ganze Monitoring Logik wer so weg ist und wer ggf wieder gekommen ist und was dann zu tun ist ist nicht ohne und will definiert und umgesetzt werden
- Netzwerkprobleme dürfen auch nicht zu einem Chaos führen
- ...
Bisher hat schlicht die Zeit gefehlt das sauber zu bauen. Auch weil die meisten in so einem "großen Umfeld" bei uns am ehestens mit Proxmox unterwegs sind und ehrlich ... dann nimmst Du da ein shared FS und machst proxmox HA cluster draus und schon hast DU das alles weil dir im zweifel Proxmox deine "VM" oder Container beim usfall eines nodes einfach auf nem anderen Node neu startet, damit hast du zwar keine "Instanzumverteilung" aber eine "Host Umverteilung" und am Ende das gleiche erreicht.
Sobald mal wieder Luft neben anderen Themen ist steht das mal mindestens immer noch auf Meiner Liste ...
PS: Und das alles für ein "Zwei Host Setup" zu haben (was wohl 9x% der User abdecken sollte) ist dann nochmal der nächste Schritt - weil das reicht ein Sentinel nicht
-
Ja Ingo, die Edge-Cases sind natürlich nicht ganz so einfach.
Mal eine Frage zu einem Promox HA-Cluster: was wäre denn eine passende Hardware-Basis? Raspi ja sicherlich nicht. Also eher NUC i5 oder i7?
Viele Grüße
Dirk -
@higginsd sagte in [Projekt] ioBroker Redundanz/HotStandby:
Also eher NUC i5 oder i7?
Formal geht alles wo Du Debian installieren kannst (also echtes, keine Flavours), damit ja Raspi eher nicht. Ich denke die meisten sind bei Nucs. Nuc i5 ist ein gutes Mittel. i7 bringt meistens keine echten Vorteile kostet nur mehr und i3 merkt man ggf dann doch bezüglich der Leistung. Und aus meiner Erfahrung uist CPU meistens nicht der Flaschenhals, eher RAM ... also gescheit RAM rein dann geht auch viel
-
Danke!
Bei den aktuellen Wucherpreisen für 8GB PI4 ist ein NUC i5 tatsächlich eine gute Option. Denn zum Pi4 muss ja auch noch eine SSD und ein entsprechendes Gehäuse für Pi und SSD dazu gekauft werden. Auf MicroSD halten die ja nicht lange durch.
Grundsätzlich aber habe ich Pimox gefunden, das ist ein Promox für Raspbian. Zum Testen reicht das erst mal und 3 PIs könnte ich freischaufeln.
https://www.veuhoff.net/proxmox-auf-den-raspberry-pi-4-pimox-7-installation-tutorial/
-
@higginsd sagte in [Projekt] ioBroker Redundanz/HotStandby:
Denn zum Pi4 muss ja auch noch eine SSD
... Bedenke aber das du bei nem Raspi SSD nur per USB anschliessen kannst und der USB baustein (genauso wie Wifi und pot Ethernet) im Notfall bei "Power Engpässen" vpm Raspi auch mal eben schnell abgeschaltet werden ... Also dann wirklich ein "viel überpotentes" Netzteil nutzen
