NEWS
[Projekt] ioBroker Redundanz/HotStandby
-
Hi,
Interessant ist das Thema in jedem Fall und auch Lösungen dazu. ALso immer her damit.
Wie ist das: Läuft das "Standby" System damit die ganze Zeit mit oder fährt es erst hoch wenn es nötig ist? Ich speche vor allem davon ob alle Skripte auch alle dort laufen bzw Gerätedaten ankommen und so?!
Das Problem zum "Switch"-Zeitpunkt in meinen Augen ist genau der Stand der Daten - also Objekte und States. Wenn Du einfach nur switchst hat der Standby im Notfall einen anderen Datenstand, oder wie syncst Du das ?! Damit gehen Skripte kaputt (wäre zumindestens bei mir so).
Meine Idee dazu wäre:
-
Redis
-
Auf dem Standby host ist ein Slave vom Master. Damit sind alle State-Daten aktuell. Das "objects.json" kann man regelmäßig syncen (alle 30 mins sollte locker reichen, so oft ändern sich Objekte nicht wenn das System "nur" läuft)
-
Dann müsste man im Switch fall den Redis stoppen, zum Master machen und wieder hochfahren und dann erst den ioBroker dort hochfahren mit dem "lokalen" Redis.
-
Ein Auto-Switch zurück geht dann aber nicht weil man vorher den Redis wieder in sync bringen muss
Ich hab schon einige Zeit gedanklich in das Thema investiert, aber wenn man es richtig machen will istes zu aufwändig … aber nicht richtig macht wieder mehr Probleme als alles andere.
Richtig wäre eine 3 Server Nummer mit Quorum-Logik und ner Redis Cluster Installation :-))
-
-
Hallo,
das Ganze ist nun unter https://github.com/hometm/ioBroker-Standby zu finden.
> Wie ist das: Läuft das "Standby" System damit die ganze Zeit mit oder fährt es erst hoch wenn es nötig ist? Ich speche vor allem davon ob alle Skripte auch alle dort laufen bzw Gerätedaten ankommen und so?!
Der Standby läuft die ganze Zeit, lediglich die Netzwerkschnittstelle wird aktiviert/deaktiviert.
> Das Problem zum "Switch"-Zeitpunkt in meinen Augen ist genau der Stand der Daten - also Objekte und States. Wenn Du einfach nur switchst hat der Standby im Notfall einen anderen Datenstand, oder wie syncst Du das ?! Damit gehen Skripte kaputt (wäre zumindestens bei mir so).
Mir ging es weniger um lang-laufende Skripte (z.B. Verbrauchsmessung, Datenaufzeichnung, . ..), sondern um die 'lebensnotwendigen' kurz-laufenden Skripte (z.B. Rolladen, Wasser-Magnetventil, Lichter). Wenn meine lang-laufenden Skripte fehlschlagen, ist das für mich verkraftbar. Wenn ich aber nicht zu Hause bin, und das Licht nicht mehr funktioniert, habe ich ein Problem mit meiner Frau
` > Meine Idee dazu wäre:
-
Redis
-
Auf dem Standby host ist ein Slave vom Master. Damit sind alle State-Daten aktuell. Das "objects.json" kann man regelmäßig syncen (alle 30 mins sollte locker reichen, so oft ändern sich Objekte nicht wenn das System "nur" läuft)
-
Dann müsste man im Switch fall den Redis stoppen, zum Master machen und wieder hochfahren und dann erst den ioBroker dort hochfahren mit dem "lokalen" Redis.
-
Ein Auto-Switch zurück geht dann aber nicht weil man vorher den Redis wieder in sync bringen muss `
So etwas war meine erste Idee. Ich hatte ein mal pro Stunde die Engineeringdaten (Skripte, Vis Views, Zustände,…) vom Master kopiert. Und das Standby System nur gestartet, wenn der Master nicht mehr erreicht bar war.
Diese hatte ich aber verworfen, weil:
-
Es ist nicht sicher, dass die übertragenen Daten konsistent sind
-
Was, wenn während dem Kopieren der Daten der Master abstürzt?
-
Man weiß im Vorfeld nicht, ob ioBroker anläuft
-
Der Start dauert auf dem Raspi paar Minuten
=> Für soetwas benötigt man vermutlich zwei Standby Systeme, welche immer abwechselnd Syncen/Starten. Damit immer ein Standby mit Konsistenten Daten bereit steht
Tobias
-
-
Cool … ich würde schon dran scheitern wie ich eine zweite IP auf den Rechnern aufsetze
Muss ich mir mal ansehen.
Wenn der Haupt-master wiederkommt dann lässt du den ioBroker auf dem anderen Host weiterlaufen auch wenn Du ihm das Netzwerk wegziehst?! Macht es nicht Sinn den zu beenden? Oder was ist der Grund?
Wie hältst Du den "Standby aktuell"? Regelmäßig Updates einspielen?
Hier kann ich rsync empfehlen Macht aber nur sinn wenn beide Rechner die gleiche "Systemarchitekur" haben.
-
…. Wenn meine lang-laufenden Skripte fehlschlagen, ist das für mich verkraftbar. Wenn ich aber nicht zu Hause bin, und das Licht nicht mehr funktioniert, habe ich ein Problem mit meiner Frau `
Das heißt,.. Wenn das Netzwerk in Rauch aufgeht kann deine Frau kein Licht mehr anschalten? :shock:…
Mal im Ernst..
Die Idee ist schon gut, keine Frage.. Ich will auch kein "Miesmacher" sein.
Aber ein PING eignet sich für sowas eigentlich "überhaupt nicht"..
Du prüfst ja nur, ob der Rechner läuft bzw. per LAN erreichbar ist - nicht aber ob ioBroker wirklich läuft..
Wenn ioBroker auf dem Master-System (aus welchem Grund auch immer) abstürzt, ist der Rechner ja trotzdem noch per PING erreichbar - obwohl ioBroker nicht mehr läuft.
Du müsstest also eher prüfen ob ioBroker auf dem Master-System noch läuft.
z.B. mit wget das Webinterface von ioBroker aufrufen bzw den Response-Code prüfen..
Aber auch das ist wieder "nicht korrekt", weil wenn nur ein Adapter abstürzt kann die Steuerung ausfallen obwohl ioBroker an sich selbst noch läuft..
Das Thema ist recht komplex..
Ich würde eventuell ein Javascript auf dem Master anlegen, welches alle wichtigen Datenpunkte/Adapter prüft und jede Minute in einen Datenpunkt schreibt
"13:35:25 - Alles ist Okay" ..
Und dann über den simple-api Adapter den Zustand von diesem Datenpunkt auf dem Standby System abfragen..
Wenn Uhrzeit vor "Alles ist Okay" weiter zurück als 2 Minuten ODER Master reagiert überhaupt nicht auf die Anfrage -> Standby System live schalten..
Gruß
-
Ich denke im Normalfall reicht es Port 9001 zu checken (oder vllt sogar nen socket.io client dran zu haben, also so wie ein "adapter" oder so). Port 9001 ist die "Objects Memory DB" die sollte fast immer das sein auch wenn man die States in nem Redis hat. WObei sobald Redis ins spiel kommt geht esbeim Switch wieder kaputt.
Die Idee mit dem State und diesen Abzufragen ist auch gut.
Das was mir (als Perfektionist bei sowas) nicht gefällt ist, wie oben schon beschrieben, das die States/Objects in dem Standby System "out of Sync" sind und ich beim Switch zurück nochmal "State" verliere. Keine AHnung welche Meiner Skripte dann so aus dem Tritt wären.
Bin aber auch ehrlich: So wirkliche Alternativen ausser dem "grossen Hammer" fällt mir nicht ein. Eigentlich bräuchte man mindestens 3 Master-Nodes und auch die Objects und States beides im Redis. Redis in einem 3er Setup mit Sentinel. So könnte man einen Redis pro ioBroker-Master haben und man überlässt dem Redis die Ganze Master-Selection und ioBroker "weiss" damit automatisch wer der Master ist (nämlich der wo der Redis gerade Master ist). Darauf dann reagieren den zum Master machen und Instanzen "umziehen" auf den neuen Host (die die man markiert hat das sie wichtig sind, andere deaktivieren oder so).
Das muss dann aber in ioBroker rein.
-
> Wenn der Haupt-master wiederkommt dann lässt du den ioBroker auf dem anderen Host weiterlaufen auch wenn Du ihm das Netzwerk wegziehst?! Macht es nicht Sinn den zu beenden? Oder was ist der Grund?
Ich ihn laufen, und deaktiviere erneut die Netzwerkverbindung, vielleicht fällt der Master erneut aus.` > Aber ein PING eignet sich für sowas eigentlich "überhaupt nicht"..
Du prüfst ja nur, ob der Rechner läuft bzw. per LAN erreichbar ist - nicht aber ob ioBroker wirklich läuft.. `
Ich verwende den Ping, um zu prüfen, ob der PC auf dem der Master läuft, überhaupt noch erreichbar ist. Genau das war mein Fehlerbild. Wenn ich die Erreichbarkeit von ioBroker testen würde, könnte es vorkommen:-
ioBroker nciht mehr erreichbar
-
PC ist noch erreichbar
=> dann wäre das Konzept mit dem 'Austauschen' der PC auf netzwerkbasis nicht möglich
> Das muss dann aber in ioBroker rein
Wäre sicherlich die Beste Lösung -
-
> Wenn der Haupt-master wiederkommt dann lässt du den ioBroker auf dem anderen Host weiterlaufen auch wenn Du ihm das Netzwerk wegziehst?! Macht es nicht Sinn den zu beenden? Oder was ist der Grund?
Ich ihn laufen, und deaktiviere erneut die Netzwerkverbindung, vielleicht fällt der Master erneut aus. `Naja hast Recht, dann fürht das "iobroker start" am Ende nur zu einem "läuft schon"
` > Aber ein PING eignet sich für sowas eigentlich "überhaupt nicht"..
Du prüfst ja nur, ob der Rechner läuft bzw. per LAN erreichbar ist - nicht aber ob ioBroker wirklich läuft.. `
Ich verwende den Ping, um zu prüfen, ob der PC auf dem der Master läuft, überhaupt noch erreichbar ist. Genau das war mein Fehlerbild. Wenn ich die Erreichbarkeit von ioBroker testen würde, könnte es vorkommen:-
ioBroker nciht mehr erreichbar
-
PC ist noch erreichbar
=> dann wäre das Konzept mit dem 'Austauschen' der PC auf netzwerkbasis nicht möglich `
Ich denke auch hier sind wir mal wieder beim "es gibt keine Wahrheit" Bereich. Ich habe in meiner berufskarriere schon alles gesehn. Applikationen können weg sein. OS kann "stoppen" aber noch pingen (inklusive Applikationsports sind noch erreichbar). Ich denke einen "sauberen" Ausfall "=alles weg wenn weg" gibt es nur selten.
Von daher: Valide in deinem Fall wenn Du ein spezifisches Fehlerbild hast … leider aber halt nicht allgemeingültig.
Das ist alles blöd ... Menno
> Das muss dann aber in ioBroker rein
Wäre sicherlich die Beste LösungIn absehbarer Zeit wird es irgendwas geben was direkt in iobroker drin ist.
Mein Favorit geht in die zuletzt beschriebene "Redis+Sentinel" Richtung. Das einzig wichtige ist man braucht mindestens 3 Sentinels - also 3 Hosts wo Sentinel läuft, mindestens zwei davon mit ioBroker und Redis drauf (besser 3 wegen Ausfallsicherheit). Aber ich denke wer so eine Sicherheit haben will ist bereit das aufzusetzen bzw hat eh schon 2 Hosts da
Mal schauen
-
-
Doofe Frage und mit mehr Aufwand für das Entwicklerteam:
Macht es nicht Sinn den genannten 3."Zeugen" in die IO.Cloud auszulagern?
Quasi lässt man alle 5 Minuten über ein Blockly eine Datei (ich sag mal xml) ablegen (Pro Host).
Ich würde vieles über Javascripte machen, statt über einen eigenes Modul:
<#RunConfig> <iobroker><lasttimestamp>20180329102247</lasttimestamp> <modules><modul1>..........</modul1></modules> <ip>192.168.178.5</ip> <iobroker><objektstats><objekt1>.......... <objektstats></objektstats></objekt1></objektstats></iobroker></iobroker>
Diese Datei soll entweder an die Cloud gepushed, lieber noch gepulled werden.
Sollte jetzt eine der Dateien beim 5min push/pull kann die Datei davor genutzt werden um zumindest die Stats und Configs auszulesen und aktiv zu setzen.
Natürlich wäre sowas auch mit einer Datenbank machbar, aber ich finde eine Datenbank einfach zu Fettleibig für sowas. Zumal es ja dem einfach technisch weniger versierten Nutzer gelingen sollte einzurichten. Immerhin ist Smarthome und ioBroker ja kein Freakzeug mehr - sondern erstürmt ja auch die Hausfrauenrunde ^^
Ok Vielleicht doch ein eigener Adapterset:
Adapter.Instanz.0 Konfiguriert als Zeuge
Adapter.Instanz.1 Konfiguriert als Client
Ähnlich wie beim MQTTAdapter…
MOMENT: Vielleicht streicht man auch XML und löst das über MQTT. Und dann ein Masterless MQTT Cluster? jaja....
-
Könnte man das vielleicht direkt in ioBroker so einbauen dass man einen Slave (oder sogar mehrere…?) als "Standby-Master" definieren kann und auf diesem die Objects-Db automatisch permanent mit dem Master synchron gehalten wird sowie automatisch bei Ausfall des Haupt-Masters auf "Masterbetrieb" umgeschalten wird? Ich kann jetzt nicht so ganz einschätzen was dafür im Hintergrund alles noch erforderlich wäre, aber durch das modulare Konzept dürfte das doch gar nicht mal so sehr aufwendig sein?
-
Die Cloud ist als dritter Zeuge ungeeignet. Du willst an der Stelle so wenig wie möglich Störungen haben (wenn man es richtig machen will) und auf der Weg zum Cloud Server kann zu viel schieff gehen
-
@apollon77 sagte in [Projekt] ioBroker Redundanz/HotStandby:
In absehbarer Zeit wird es irgendwas geben was direkt in iobroker drin ist.
Ziemlich alt der Thread, aber immerhin habe ich die Suche benutzt...
Ich habe mich heute zum ersten Mal mit dem Thema Multihost genauer befasst. Wegen einer ausgefallenen Tischsteckdose ist mein NAS mit iobroker drauf nicht verfügbar gewesen. Da ich nicht zuhause war, konnte ich den Grund nicht schnell ermitteln. Die "Insassen" mussten so einige Zeit auf lieb gewonnene Bequemlichkeiten verzichten...
Jetzt habe ich aber festgestellt, dass Multihost gar keine Redundanz in Form eines Loadbalancers ist.
Was ist hieraus geworden?
-
@ofbeqnpolkkl6mby5e13 load balancer wird nicht wirklich gehen. Am Ende gibt es in meinen Augen drei Optionen:
1.) proxmox ha Cluster (also 2-3 nodes) mit shared filesystem und damit werden Container und vms automatisch migriert. sowas hab ich mir aktuell gebaut. Ist aber bissl Aufwand, aber das was jetzt schon geht. Am besten mit redis sentinel Cluster. Sentinel geht seit controller 3.0
2.) standby system
3.) ha Adapter der im multihost Adapter dann auf andere Hosts verschiebt.
2 und 3 gibt es nicht aber mit den letzten und nächsten js-Controller Versionen werden wir dem Thema immer näher kommen. Ich denke nr3 mit redis wird vor nr2 kommen.
Aber ja alles ein Thema der Zeit und Prios
-
Okay, ich kann dir jetzt zugegebenermaßen nur in Teilen folgen. Aber grundsätzlich habe ich das hoffentlich schon verstanden. Was ist ha Adapter? Und wie verschiebt man von einem Host auf den anderen, wenn der ausgefallen ist?
-
@ofbeqnpolkkl6mby5e13 sagte in [Projekt] ioBroker Redundanz/HotStandby:
Was ist ha Adapter? Und wie verschiebt man von einem Host auf den anderen, wenn der ausgefallen ist?
ha= high availability.
Das verschieben wird dann wohl über die oben genannten drei Systeme laufen müssen. -
@thomas-braun
Ah, okay. Danke! -
@apollon77
Weshalb kann man nicht zwei Hosts aufbauen, die, was die iobroker Installation und Konfiguration betrifft, identisch sind (Hostnamen und IP-Adressen unterscheiden sich natürlich)?
Beim Master sind alle Instanzen aktiv. Beim Slave sind außer Admin alle deaktiviert. Eine neue Funktion in iobroker sorgt jetzt dafür, dass alle Objekte und States zum Slave gesynct werden.
Fällt der Master aus, müssen die Instanzen des Slaves nur aktiviert werden. Läuft der Master wieder, kann man die Änderungen des Slaves zum Master syncen. Danach werden wieder alle Instanzen auf dem Slave deaktiviert. So ungefähr... -
@ofbeqnpolkkl6mby5e13 das was du beschreibst ist ein standby System. Dazu muss man die Datenbank und alle files zwischen den Systeme In Sync halten und einen umschaltmechanismus bauen.
Der „high availability Adapter“ ist eine Idee mehrere aktive Systeme zu haben und ein Adapter stellt dann fest wenn etwas ausgefallen ist und verschiebt die Adapter vom ausgefallenen Host. Auch dazu braucht es voll gesyncter Datenbank und file store. Und alles so das kein „Split Brain“ passiert.
Beide Fälle brauchen noch Logiken die IP der Visualisierungen auf den anderen Host zu schwenken oder die visus müssen im Zweifel mehrere ips kennen Wo sie connecten können.
Also das sind noch einige Bausteine die man idealerweise „User freundlich“ bereitstellen muss. Das sind mehrere „größere“ Themen. Und das braucht Zeit.
Was wie gesagt schon geht ist das oben beschriebene proxmox Cluster Konzept. Das braucht aber sinnvolle Hardware und invests (inkl idealerweise USV(s) und sowas … ist leider nichts für die Raspi Ecke. Aber da wolle. Wir irgendwann mal sein. ;-))
Ingo
-
@apollon77
Okay, ich denke, ich habe das soweit verstanden. Danke für die Ausführungen! -
Moin
Ist aus der Idee irgendwas geworden? Ich überleget auch gerade wie man einen iobroker active/passive Cluster bauen könnte. Ein ESP oder sowas als Quorum sollte ja kein Problem sein. Ich stecke nur nicht tief genug drin, um zu verstehen, wie man die iobroker Datenbank sauber synchronisiert bekommt. Reicht da eine einfache one-way file based Synchronisierung des iobroker Verzeichnis? Mit 5-10 Minuten Datenverlust beim failover könnte ich problemlos leben.
P.S.: auch leben könnte ich mit einem manuellen Failback.
-
Hi, am Ende sind bisher "nur" weitere Überlegungen entstanden aber noch keine echte Lösung oder Adapter (also bei mir zumindestens). Bzw im js-controller gibts Vorbereitungen (seit js-controller 4 hat ein Multihost Verbund intern schon "einen" Master-Host für bestimmte Aufgaben).
Ich nutze aktuell einen proxmox HA cluster und 3 iobroker VMs und Redis als DB mit Sentinel und glusterfs als shared FS. Damit ist die "DB" (was am Ende der neue "Master" ist) hochverfügbar und die 3 VMs verbinden sich dagegen. Mit dem Shared FS und Proxmox würden VPMs oder Redis beim Ausfall eines Proxmox Nodes migriert auf nem anderen host und neu gestartet.
Das ist aktuell das was geht - quasi eher mit "Infrastruktur erschlagen"
Das Thema ist generell noch auf der Liste, aber es gibt momentan höher priorisierte Themen.