Weihnachtsangebot 2025! 🎄

[apollon77]

Na klar spricht nichts gegen Storage, wenn er geshared und damit auf allen Nodes identisch ist ... :-)
Mach doch mal so ein Setup und dokumentiere es :-)

[smile]

Sehr interessantes Thema, ähnliches hatte ich ja selber gerade hier angesprochen, wenn auch deutlich simpler.

Wenn iobroker die breite Masse weiter erreichen soll, dann kann ich euch sagen dass es eine simple Lösung sein sollte. Ich bin durchaus Technik und IT - interessiert, aber die Lösungsansätze die hier geschrieben sind halte ich für zu komplex für ein Großteil der Anwender.

Meine simple Lösungslogik ist:
2 Systeme nutzen:

• io.broker auf Raspi oder Mini Windows Server.
• Homematic oder anderes Hardware System welches Aktoren bedient.

Ggenseitige Ausfallüberwachung:
-io.broker prüft die Homematic auf "aktivität" und bei Ausfall wird eine Homematic-unabhängige schaltbare Steckdose vom io.broker angesteuert, die die Homematic per Strom-Reset neustartet

• Die Homematic macht selbiges umgekehrt für io.broker auf dem Raspi / Win Server

Im Schlimmsten Fall habe ich 5 Minuten Ausfallzeit, also die Überprüfungszeit und die Bootzeit der Systeme, aber dann läuft es weiter.
Wenn der ganze Raspi / Win Server / dessen Festplatte schrott ist, dann tauscht man entweder manuell oder hält sich tatsächlich ein komplett 2. System vor, welches dann per selbigen Prinzip gestartet wird.

[MarkusDe]

Naja, iobroker im Docker und dann Docker Swarm.... das dürfte fast jeder, der iobroker installieren kann auch hinbekommen.

Anleitung hier:
https://docs.docker.com/engine/swarm/swarm-tutorial/

und dann als Service den iobroker installieren:

https://hub.docker.com/r/buanet/iobroker/

[AWhiteKnight]

Hallo zusammen,

hier hat sich eine Weile nichts getan. Lebt das Thema noch?
Für mich ist das Thema Ausfallsicherheit/Verfügbarkeit aus leidvoller Erfahrung wichtig geworden.

Ich hatte vor einigen Jahren mal den Ausfall der Zentralheizung, weil der Zündtrafo gesponnen hat.
Es war glücklicherweise nicht so kalt, das die Leitungen eingefroren sind, aber als ich aus dem Urlaub wiederkam, war die Haustemperatur auf 5° C abgesunken und es hat 3 Tage gedauert, bis das Haus wieder angenehm durchgewärmt war.

Das war der Auslöser mir Gedanken über das Thema Ausfallsicherheit im privaten Bereich zu machen.
Alles ausfallsicher zu gestalten ist zu teuer bis unmöglich. Schliesslich gilt dafür immer noch: 2n+1 Instanzen müssen existieren, damit davon n Instanzen ausfallen dürfen.
Also braucht es clevere Ideen, um ein Maximum an Sicherheit zu bekommen. Das Zauberwort heißt dabei Ausfalltoleranz.

Der Beitrag Nr 24 von Karl_999 zeigt die grundsätzliche Konzeption einer solchen Lösung auf:

• Zuverlässige Benachrichtigung, wenn etwas nicht stimmt (oder nicht stimmen könnte)
• Kritische Komponenten ausfallsicher (wenn bezahlbar)
• Wichtige Komponenten standby Ersatz (wenn bezahlbar)
• Jede Komponente muss autark arbeiten wenn die übergeordnete Instanz ausfällt

Beim ersten Punkt kommt bei mir der Bedarf an einem HA-IoBroker-Server auf und einem leistungsfähigen Monitoring innerhalb des IoBroker.
Für letzteres entwickle ich gerade einen Adapter (https://forum.iobroker.net/topic/22026/neuer-adapter-iobroker-moma bzw. https://github.com/AWhiteKnight/ioBroker.moma).

Meine HA-Lösung des Servers plane ich auf Basis von einem Docker-Swarm mit 3 Knoten im Swarm-Mode.
Docker hat laut Doku die Thematik der "Hochverfügbarkeit" bei der Swarm-Implementierung ermöglicht.
Also warum das Rad nochmal erfinden?
Hardwarebasis werden SBC der Raspi-Klasse sein. Ich habe ein paar Odroid C2 in der Bastelkiste, die haben mehr RAM as ein Raspi und arbeiten mit EMMC + SD-Karte.
Docker läuft auch drauf, Anleitung: https://magazine.odroid.com/article/odroid-c2-docker-swarm/.
Als Betriebssystem habe ich Armbian genommen, das ist beim Kernel aktueller als das Ubuntu von Hardkernel.
Ein Docker-Swarm läuft bei mir, aktuell nur mit einem Manager/Master, auf jedem Rechner läuft direkt auf dem Armbian auch schon eine IoBroker Instanz. Portainer läuft auf dem Swarm als grafisches Verwaltungstool, soll aber optional bleiben.

Aktuelle To Dos:

• Verteiltes Dateisystem, damit alle Docker-Instanzen die gleichen Container nutzen können
• Monitoring um Docker erweitern (von aussen und innen)
• Einen IoBroker-Container mit IoBroker als Multihost-Server für arm64 erstellen
• Multi-Manager-Docker-Swarm aus 3 SBC mit Mini-USV zusammenstellen.

Bevor jemand fragt. Ich habe jetzt 3 weitgehend unabhängige Heizsysteme zu Hause:

• die bisherige Zentralheizung
• einen wasserführenden Kachelofen
• Solarthermie auf dem (Garagen)Dach

Die Stromversorgung erfolgt über Photovoltaik und inselfähigem Hauskraftwerk im netzparallelen Betrieb.
Ein paar kleine USV für Steuerungsrechner, NAS etc. gibt es auch schon.

Ausfallstolerante Grüße

[apollon77]

Hi,

interessanter Ansatz generell. Ich bin mir nur nicht sicher ob (vor allem auf Deine Todos blickend) das wirklich auch einfach für viele Leute nutzbar wäre. Vor allem verteilte Dateisystem sind seeehr komplex (wei ssich aus Erfahrung, habe gluster am laufen und drbd kenn ich auch). Und das ist ggf ein Grund "das Rad neu zu erfinden". Wenn man die nötige Ahnung hat ist das alles machbar, aber ohne?

Ich persönlich wäre da generell bei dem folgenden Grundansatz:

• State- und Objects-DBs werden auf alle Nodes repliziert, damit ist überall alles da und man braucht kein verteiltes Dateisystem. DIe InMem-DBs bekommen also Replikations-Support. Alternativ nutzt man Redis. Ab js-controller 2.0 geht das auch mit Objekten.
• Man implementiere einen an Redis-Sentinel angelehnten Quorum Dienst der als Teil des js-controllers läuft und aus mehreren Nodes einen Master bestimmt und auch Neu-Abstimmungen. Alternativ geht ggf auch der echte Redis-Sentinel (geht weil ab js-controller 2.0 das Haupt-InMem-DB Protokoll auch auf Redis basiert auch wenn es kein Redis ist). Vorteil von etwas eigenem: Man kann auch Strategien für "2 Node Szenarien" mit weiteren Quorum-Optionen wir FileShare-Witness oder so einbauen was Redis-Sentinel nicht erlaubt.
• Dazu dann noch ein "HA-Manager" im ioBroker als Adapter oder ioBroker-Core-Teil der nach bestimmten Regeln die Instanzen auf andere Hosts schiebt und neu startet. Die ganze Basis dafür existiert schon inkl. dynamischem npm-install und so. Die Verteilstrategien und so werden interessant.

Was denkst Du zu so einem Ansatz? Die Redis-Protokoll-Implementierung für States und Objekte habe ich in den letzten Wochen gemacht und ist im jsmcontroller 2.0 (GitHub Master) schon fast fertig drin. Wir planen hier gerade Performancetests.
Dann sehen wir weiter

Am Ende kann man die einzelnen Nodes immer noch auf Docker, Raspis, echter HW VMs oder sonst wie laufen lassen, Das geht alles flexibel.

[AWhiteKnight]

Hallo apollon77,

ich bin bisher davon ausgegangen, das ioBroker keine HA-Implementierung hat und macht. Mit den für mich neuen Informationen sieht die Welt anders aus.
Der Ansatz ist natürlich besser und zu bevorzugen.

Dann warte ich mal auf Version 2.0 des js-controller und sehe dann weiter.
Punkt 2 der Liste und von 4 die Mini-USV bleiben zum Werkeln bestehen.
3 Odroid C2 liegen noch in der Bastelkiste.
Der Docker-Swarm kriegt dann andere Aufgaben :-)

[apollon77]

Hi,

naja, das ganze Thema ist eine Größere Nummer und aktuell nur eine Idee in meinem Kopf. Der Plan von Socket.io weg zu gehen zu einem "schlankeren "Protokoll ist auch schon länger da und hat erst einmal nichts direkt mit HA zu tun ... mir ist nur bei der Umsetzung klar geworden das diese neue Basis durchaus Grundlage für weitere Dinge sein könnte.

Beim HM-Usertreffen wo sich auch viele ioBroker-User treffen ist in Gesprächen auch klar geworden das hier verschiedenste Theman existieren die User gern wollen. Angefangen bei fklexibler "Skalierung" der Adapter, über einfache Fallback-Systeme mit zwei Nodes (denke da kommen die meisten User her) bis hinzu "echter selbstheilender" HA wo wieder egal ist wo der Master ist ... und alles einfach verständlich und nicht zu kompliziert :-)

Naja mal schauen ... Und so oder so ist das ganze zu bauen noch ein weiter Weg.

[apollon77]

@AWhiteKnight sagte in [Umfrage] Hochverfügbarer ioBroker auf RPIs:

3 SBC mit Mini-USV

Was nimmst Du denn für Mini-USV? Ich habe Intel Nucs und siche noch nach einer "mini-USV (19V am Ende oder halt 230V) die am Ende nur sicherstellt das der Shutdown sinnvoll verläuft ... Finde nur "Die großen"

[DeepCore]

@AWhiteKnight @apollon77

Das mit den Mini-USV interessiert mich auch brennend, wegen Kabelmodem, Router/Switch und ein paar Raspis! Die Raspis mögen es garnicht wenn denen einfach der Strom abgewürgt wird.

Und für meinen HP Proliant, wo ioBroker drauf ist, suche ich auch noch eine passende USV... ich fahre im Moment auf Risiko :white_frowning_face:

[apollon77]

Also ich bin generell auf APC, hab ich zwei stück von einmal im Arbeitszimmer (Haupt-Router und Homemetaic CCU und 3 Nucs) und eine im Keller (NAS, weitere Nucs, PoE zu CCU Repeater). Einmal ne 550er kleine und ne 700er grosse APC Back UPS.

Die halten auch einiges aus und so gehen 15-60 Minuten problemlos. Kann ich generell empfehlen.

Habe jetzt aber noch einen Nuc woanders stehen und den würde ich gern sicher runterfahren können.

[AWhiteKnight]

Bei mir sind es 3 USV in 2 Räumen:

• Powerwalker VI 650 LCD für NAS (8-Bay vollbestückt) und Raum-Switch (16-Port)
• APC BE 400 (ohne USB-Port) für ioBroker-Master (Odroid HC1 mit SSD) und zeitweilig 7er Odroid C2 Cluster
• König 1000 VA für 3 Fritz-Boxen, Core-Switch (24-Port, PoE), Raum-Switch (8-Port) und DNS-Server (raspi 3 mit PiHole, ioBroker-Slave), Raspimatic, Letrika SolGate

Idee ist, bei der geplanten Hochverfügbarkeitslösung die redundanten ioBroker-Master auf verschiedene USV zu legen

[DeepCore]

@AWhiteKnight sagte in [Umfrage] Hochverfügbarer ioBroker auf RPIs:

... 3 Fritz-Boxen ...

Hast du 3 verschiedene ISPs, oder warum die 3 Boxen ?

[AWhiteKnight]

Nein, ich betreibe aus Sicherheitsgründen 5 Netzwerksegmente geschachtelt in 3 Ebenen. Innerhalb einer Ebene sind die Netze strikt getrennt.
Firewall 1 ( Internetzugang, nur hier gibt es WLAN)

• Gastnetz für Besucher
• IoT-Netz für alles was meint dauernd nach Hause telefonieren zu müssen oder unsicher ist, Drucker etc. und alle WLAN - Geräte wie z.B. Smartphones, Tablets, Laptops ohne Kabel)

Firewall 2 (sitzt hinter Firewall 1, nur Kabelgebunden, WLAN bei Bedarf einschaltbar)

• Office-Netz für den Büro-IT-Kram
• Home-Netz für die privaten IT-Geräte

Firewall 3 (sitzt hinter Firewall 2, definitiv nur kabelgebunden)

• Infrastruktur-Netz für den Zugang zu kritischen Komponenten wie Switche, Heizung, PV-Anlage, ...