Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[hometm]

> 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

[apollon77]

@hometm:

> 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" :-)

@hometm:

` > 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ösung

In 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

[mrmomba]

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....

[Thisoft]

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?

[apollon77]

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

[oFbEQnpoLKKl6mbY5e13]

@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?

[apollon77]

@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 ;-)

[oFbEQnpoLKKl6mbY5e13]

@apollon77

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?

[Thomas Braun]

@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.

[oFbEQnpoLKKl6mbY5e13]

@thomas-braun
Ah, okay. Danke!

[oFbEQnpoLKKl6mbY5e13]

@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...

[apollon77]

@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

[oFbEQnpoLKKl6mbY5e13]

@apollon77
Okay, ich denke, ich habe das soweit verstanden. Danke für die Ausführungen! :+1:

[AndyGR42]

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.

[apollon77]

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.

[AndyGR42]

@apollon77 Danke für die schnelle Antwort. Das klingt etwas zu aufwändig. Ich habe neben dem Odroid M1 des Live System noch einen C4, der zumindest übergangsweise für einen Notbetrieb reichen sollte. Auf einem Pi3 laufen noch ein par Netzwerkdienste, den könnte man als Quorum nehmen.

Sehe ich das aber richtig, mit den JSON Lists kann ich vermutlich keine saubere Synchronisation der Datenbank zu Laufzeit erstellen, oder? Oder einen Snapshot? Der Backup Adapter nutzt dafür vermutlich eine API um iobroker zu sagen, dass es mal die Füße stillhalten soll?

[apollon77]

@andygr42 Der Teil für JSONL eine migration zu bauen und alles da drum herum fehlt noch ...

[AndyGR42]

@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.

[apollon77]

@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

[AndyGR42]

@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.