NEWS
[Projekt] ioBroker Redundanz/HotStandby
-
> 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
@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 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 ;-)
-
@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?
-
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. -
@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! -
@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 ;-)
@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
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
-
@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! :+1: -
@apollon77
Okay, ich denke, ich habe das soweit verstanden. Danke für die Ausführungen! :+1: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.
-
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.
@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 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 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 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
-
@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.
-
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
-
@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
-
@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/
662
Online32.6k
Benutzer82.0k
Themen1.3m
Beiträge