Ausfallssicherheit IoBroker - maximale Verfügbarkeit
-
@jleg bascht schon. Ändert aber nichts daran, wenn kein WLAN, keine WLAN Geräte im ioB.
-
@da_woody sagte in Ausfallssicherheit IoBroker - maximale Verfügbarkeit:
Router tot, kein WLAN
Wie kommst du darauf? Wenn man die richtige Hardware hat, funktioniert das unabhängig vom Router. Mein Router hat keine WLAN-Funktion.
-
@da_woody Jo, klar, der "casus cnaxus" war aber "wenn kein (Internet-)Router, dann kein iobroker"...
-
@dr-bakterius wird langsam korintenkacken.
Würde Mal sagen, 99,8% nutzen " normal" Hardware.
Man kann natürlich alles lösen, ist halt auch eine finanzielle Frage.
Wenn ich da oft lese, "Oi, das Gerät braucht 1W mehr", bekomme ich immer einen Lachkrampf. Wenn's um das geht, biste mit Haus Automatisierung sowieso am falschen Dampfer.
Oder "der Mini PC braucht ja 500W" nur weil's am Netzteil steht.
Im Endeffekt haben wir in Bereichen alle Recht, somit mit erübrigt sich das alles.
WLAN aufziehen, nicht mal Internet notwendig. -
so genug zu WLAN..zurück zum Thema
-
@jleg hab ich so nicht getippt. Irgendeine Kiste muß die Wolke aufmachen. Ist eben im Normalfall der Router.
-
@da_woody sagte in Ausfallssicherheit IoBroker - maximale Verfügbarkeit:
wird langsam korintenkacken.
Wieso? Wer ein Smarthome hat, sollte darauf achten, dass die Geräte auch möglichst ausfallsicher sind. Da ist ein 0-8-15 Router für Dummies die falsche Hardware. Und deine verallgemeinerte Aussage ist einfach falsch - auch wenn es bei einem Großteil der Privatnutzer zutrifft. Und nichts anderes habe ich geschrieben. Zum Beispiel hast du geflissentlich folgendes überlesen:
Mein Router ist kein Konglomerat aus Router, Switch und Accesspoint.
Ein Homerouter ist eben normalerweise nicht nur Router, sondern auch Switch, Accesspoint, DHCP und Nameserver. Also drei bis fünf Geräte in einem. Und wenn der ausfällt, sind praktisch alle für ein Netzwerk wichtige Geräte hinüber. Hat man das getrennt, ist nur ein Gerät weg und daher ist zumindest noch eine Teilfunktion gegeben. Und das ist ganz normale Hardware für Zuhause und kleinere Unternehmen. Kostet zwar mehr und braucht mehr Strom, ist aber zuverlässiger und ausfallsicherer.
-
@dr-bakterius keine angst, hab ich nicht überlesen. trifft aber halt nur auf einen promille anteil zu...
standard, die fritte vom provider. ergo, ist meine "verallgemeinerte Aussage" nicht wirklich falsch, wie du ja selber schreibst.
mein "fallback" ist z.b. die shelly-app. (voraussetzung wlan tut noch) wenn der server abkackt, kann ich die wichtigsten sachen, heizung, licht, steckdosen, ... immer noch von überall steueren. ich will/brauch nicht, daß wenn ich nach hause komme, da und dort licht angeht, mugge irgendwo gespielt wird und vllt noch wetter und nachrichten mich überfluten.
mir langst, wenn ich in einem raum der alexatusse sage "licht ein/licht aus" für mich automatisierung genug. aber jeder, wie er mag...Kostet zwar mehr und braucht mehr Strom
so ähnlich hab ich das weiter oben geschrieben. "boah, das ding braucht um ein W mehr, geht gar nüscht!" "ich will (mit aller gewalt) jedes W einsparen."
IMHO meinen wir beide das selbe, nur halt anders ausgedrückt.
-
@arteck said in Ausfallssicherheit IoBroker - maximale Verfügbarkeit:
@tscheurgen sagte in Ausfallssicherheit IoBroker - maximale Verfügbarkeit:
darf ich fragen wie deine soft- und Hardware Lösung aussieht?
ich nutze proxmox mit ceph.. wo die VM's laufen die bei Ausfall automatisch migriert werden laut regeln.
ich habe Redis mit Sentinel laufen.. wo bei ausfall auf eine andere redis geswechselt wird.backups werden auf PBO nach regeln erstellt.. und zusätzlich auf eine synology.
zigbee ist einfach.. der fällt nie aus.. (rock64 mit armbian und ser2net für zigbee und zwave) sonst läuft da nix drauf.
sonst ein pi liegt daneben.. mit der gleichen IP wir der rock. also anstecken 5 min. warten fertig..das Thema hatten wir schon so oft.. ich bin nicht der einzige der eine iobroker Abhänigkeit hat..
Hallo @arteck
interessant deine Lösung, ich habe in der Zwischenzeit ein bisschen gelesen zu VM, redis usw. und wollte dich noch mal im Detail fragen ob folgender Aufbau deiner Meinung nach machbar bzw sinnvoll ist.Ich würde gerne auf meinem Unraid Server eine Proxmox-VM einrichten und auf dieser Redis und Iobroker laufen lassen, eventuell auch gleich InfluxDB und Grafana gleich mit in die VM, dann ist alles erledigt. Dann auf einem alten Notebook ebenfalls Proxmox aufsetzen und einen Cluster erstellen. Den vorhandenen RasPi4 kann ich ja nicht nehmen, da Proxmox da wahrscheinlich nicht läuft, bzw. der Speicher mit 4GB nicht ausreichen wird. Fürs Quorum könnte ich aber einen der vorhanden RasPi3 Slaves verwenden, die haben aktuell je nur ca 500MB RAM- Auslastung.
Was mir noch ein bisschen unklar ist: Wenn mann schon eine Cluster-HA Lösung mit Proxmox aufsetzt, welch einen Vorteil bringt dann noch Redis-Sentinel? Die DB sollte ja sowieso immer gespiegelt sein, und wenn der Node1 ausfällt, würde der Node2 übernehmen, der ja die gespiegelten Daten hat? Oder geht man den diesen Weg, dass man die Redis DB über Sentinel sehr oft synchronisiert, und deshalb die gesamte VM nicht so of gespiegelt werden muss?
Aber wie ist dass dann mit der InfluxDB? Die müsste ja auch relativ oft synchronisiert werden?Eine Sache fällt mir noch ein: Wie funktioniert so ein System mit Wartungen? Kann ich einfach einen Node updaten, während der andere weiter alle Aufgaben erfüllt, und wenn das Update läuft diese Änderungen auf den 2ten Node überspielen? Natürlich müsste man vorher die "persistenen" Daten von IOB oder Influx auf den "gewarteten" Node kopieren, in Betrieb nehmen und davon ausgehen, dass dieser nun wieder als "Master fungiert und all die "Wartungen" auf den Node 2 migriert?
Ich hoffe, dass ich hier nicht zu blöde Fragen stelle.... aber ich versuche - wenn ich schon den Aufwand treibe - eine für mich schlüssige Lösung zu finden.
Das Thema Netzwerkausfall möchte ich nochmals aufwärmen, da habe ich eine Lösung mit der ich zufrieden bin.
Danke auf jeden Fall an alle die sich hier beteiligen.vG Etze
-
@etzeste13 sagte in Ausfallssicherheit IoBroker - maximale Verfügbarkeit:
Was mir noch ein bisschen unklar ist: Wenn mann schon eine Cluster-HA Lösung mit Proxmox aufsetzt, welch einen Vorteil bringt dann noch Redis-Sentinel?
bei mir sind die Maschienen getrennt.. ALLE.. ich installiere nix zusätzlich in einen Container.. (iobroker mit redis und influx und was weiss ich noch..gibbet nicht)
das hat den veorteil ich die NUR die Daten von jeweiligen system habe. muss ich ein backup einspiellen dann sind die Daten nur von dem System da..
ausserdem ist das system weiter lauffähig wenn eine VM geschoben/mirgriert wird..so sieht es bei mir aus
ich habe 3 iobroker als master/slave laufen und zusätzlich ein Redis/Redis.
die Redis werden nicht migriert.. die synchronisieren sich gegeneinander..
fällt ein iobroker aus.. oder startet neu dann laufen die anderen iobroker prozesse weiter.. ich habe es so aufgetrennt dass die Lichtsteuerung als beispiel nur vom iobrokerslave2 übernommen ist. da läuft auch eigene javascript .. schalte ich den iobrokerMaster ab funktioniert immer noch die Lichsteuerung.die Thematik icht recht komplex. vor allem bedarf es Planung....und es gibt nicht NUR die eine Lösung
@etzeste13 sagte in Ausfallssicherheit IoBroker - maximale Verfügbarkeit:
Wie funktioniert so ein System mit Wartungen?
die einzelnen Nodes können unabhänig voneinander mit updates versehen werden.. das macht Proxmox intern..
p.s: lass die Finger von einem PI fürs Quorum..
-
@arteck
danke für die Erklärung. Ich glaube ich verstehe dein Konzept, und das ist bzgl HA von IOB schon sehr gut ausgefeilt. Schmiert eine IOB VM ab, wird diese auf einen anderen Node vom ProxmoxCluster migriert und wieder gestartet, während die anderen beiden sich an der nach wie vor vorhandenen Redis bedienen und nix mitkriegen.Wäre das theoretisch nicht auch mit der von mir geplanten Hardware so umsetzbar? Am Unraid-Server Proxmox als VM und am alten Notebook diret Proxmox installiert. Am Server eine IOB VM als "Master" aufsetzen und den Cluster auf das Notebook ausweiten. Parallel auf jeder Maschine ein Redis Container und diese als Master-Slave konfigurieren und über Sentinel verbinden.
Für die Mehrheit der Quorums beim Proxmox-Cluster und Redis Sentinel, hätte ich halt doch gerne einen der vorhandenen PIs genommen, weil die da sind und nix wegfressen.
Welche schleche Erfahrung hast du mit dem Quorum und den Pis den gemacht, weil du das nicht befürwortest? Es gibt da einige Videos im Netzt die das explizit als mögl Variante aufzeigen....?Sumasumarum wäre zwar nicht so top wie bei dir, aber wenn ich alles richtig verstanden habe, sollte es doch grundsätzlich funktionieren... und besser sein als wie ich es jetzt habe.
Bliebe dann nur die frage offen, wie man Influx und Grafana handhabt. Ich verwende Influx nur in Verbindung mit dem IOB und habe die Instanz auch nur am Master. D.h. wenn der Master "down" ist, würde die Influx auch keine Daten übernehmen. Sprich für die Zeit wo der Master migriert wird, könnte auch Influx stehen, und beide dann wieder gleichzeitig in Betrieb gehen. Würde das dann nicht auch praktikabel sein Influx und Grafana in die gleiche VM zu geben wie den IOB Master? Dann würde auch das Backup per IOB Adapter für Grafana und InFlux laufen.
Bringt mich zu noch einer Frage? Wie kunktioniert das Redis Backup in den Containern mit dem IOB-Adapter?
Ich hoffe meine Gedanken sind verständlich formuliert, und würde mich freuen wenn du das Konzept kurz bewertest....
Mir ist klar, dass es nicht an deines reicht, aber es ist sicher besser als jetzt....vg E
-
@etzeste13 influx habe ich am meiner Synology laufen.. im RAID
wobei die Daten isnd mir relativ egal .. auch wenn ich keine bekomme .. und ?? passiert ja nix ausser die Diagramme sind dann leer..
eine VM Migration ist mei mir live ..ergo der iob der Migriert wird ist nie offline ausser ich beende den.
Bringt mich zu noch einer Frage? Wie kunktioniert das Redis Backup in den Containern mit dem IOB-Adapter?
keine ahnung.. ich sicher die Redis am PBO..was du machst musst du selber schauen.. wenn du meinst das es mit dem PI ok ist.dann mach es.. du musst damit klar kommen..
mir war die Ausfallsicherheit wichtig..vielleicht findet sich einer der ein QUorum mit einem PI macht.. und kann berichten
-
@arteck
danke mochmals für dein Feedback. Mir war wichtig, dass ich das Konzept mal verstanden habe. Nun kann ich ja mal versuchen ob es auch in der Praxis funktioniert und für micht praktikabel ist. Live muss ich ja erst gehen, wenn das Grundgerüst mal passt.Also nochmals besten Dank für deine Expterise!!
lgEtze -
@arteck
Hallo, ich hätte noch eine Frage? Ich habe jetzt mal eine VM mit IoBroker aufgesetzt und einen LXC Container mit Redis Ich habe nur das Problem, dass ich per iobroker setup custom nicht auf redis umstellen kann. Es scheint als ob die IOB-VM nicht auf den LXC container zugreifen kann, obwohl ich im config-file das bind auf 0.0.0.0 und den protection mode auf no gesetzt habe.generell ist der Redis container aus der IOB-VM per ping erreichbar.
gibt es da noch was auf dass man aufpassen muss?
vG Etze -
@etzeste13 sagte in Ausfallssicherheit IoBroker - maximale Verfügbarkeit:
per iobroker setup custom nicht auf redis umstellen kann
logs ??
-
@arteck ```
set@VM-IOBroker:~$ iobroker setup custom Current configuration: - Objects database: - Type: jsonl - Host/Unix Socket: 127.0.0.1 - Port: 9001 - States database: - Type: jsonl - Host/Unix Socket: 127.0.0.1 - Port: 9000 - Data Directory: ../../iobroker-data/ Type of objects DB [(j)sonl, (f)ile, (r)edis, ...], default [jsonl]: r When Objects and Files are stored in a Redis database please consider the following: 1. All data will be stored in RAM, make sure to have enough free RAM available! 2. Make sure to check Redis persistence options to make sure a Redis problem will not cause data loss! 3. The Redis persistence files can get big, make sure not to use an SD card to store them. Host / Unix Socket of objects DB(redis), default[127.0.0.1]: 192.168.1.62 Port of objects DB(redis), default[6379]: Type of states DB [(j)sonl, (f)file, (r)edis, ...], default [redis]: Host / Unix Socket of states DB (redis), default[192.168.1.62]: Port of states DB (redis), default[6379]: Host name of this machine [VM-IOBroker]: Please choose if this is a Master/single host (enter "m") or a Slave host (enter "S") you are about to edit. For Slave hosts the data migration will be skipped. [S/m]: m Important: Using redis for the Objects database is only supported with js-controller 2.0 or higher! When your system consists of multiple hosts please make sure to have js-controller 2.0 or higher installed on ALL hosts *before* continuing! Important #2: If you already did the migration on an other host please *do not* migrate again! This can destroy your system! Important #3: The process will migrate all files that were officially uploaded into the ioBroker system. If you have manually copied files into iobroker-data/files/... into own directories then these files will NOT be migrated! Make sure all files are in adapter directories inside the files directory! Do you want to migrate objects and states from "jsonl/jsonl" to "redis/redis" [y/N]: y Migrating the objects database will overwrite all objects! Are you sure that this is not a slave host and you want to migrate the data? [y/N]: y Connecting to previous DB "jsonl/jsonl"... Creating backup ... This can take some time ... please be patient! host.VM-IOBroker 77 states saved host.VM-IOBroker 144 objects saved Backup created: /opt/iobroker/backups/2024_01_26-13_27_47_backupiobroker-migration.tar.gz updating conf/iobroker.json Connecting to new DB "redis/redis" (can take up to 20s) ... No connection to objects 192.168.1.62:6379[redis] New Database could not be connected. Please check your settings. No settings have been changed. restoring conf/iobroker.json No connection to states 192.168.1.62:6379[redis] set@VM-IOBroker:~$ set@VM-IOBroker:/$ ping 192.168.1.62 PING 192.168.1.62 (192.168.1.62) 56(84) bytes of data. 64 bytes from 192.168.1.62: icmp_seq=1 ttl=63 time=0.800 ms 64 bytes from 192.168.1.62: icmp_seq=2 ttl=64 time=0.590 ms 64 bytes from 192.168.1.62: icmp_seq=3 ttl=64 time=0.608 ms 64 bytes from 192.168.1.62: icmp_seq=4 ttl=64 time=0.757 ms 64 bytes from 192.168.1.62: icmp_seq=5 ttl=64 time=0.672 ms ^Cund hier der Auszug aus der redis.conf vom LXC Container
# You will also need to set a password unless you explicitly disable protected # mode. # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ bind 0.0.0.0 # By default, outgoing connections (from replica to master, from Sentinel to ## you are sure you want clients from other hosts to connect to Redis # even if no authentication is configured. protected-mode no # Redis uses default hardened security configuration directives to reduce the # attack surface on innocent users. Therefore, several sensitive configuration # directives are immutable, and some potentially-dangerous commands are blocked. # -
@etzeste13 Hast Du den redis-service nach dem Ändern der redis.conf auch einmal neu gestartet, damit das übernommen wird?
Gruss, Jürgen
-
@wildbill
Ja habe ich natürlich gemacht. Lokal über die Container-Console läuft der redis-server auch und ich kann daten eingeben.
Was mir noch aufgefallen ist:
Wenn ich mich über meinen produktiven IOBroker Host (RasPi4 mit lokalem Redis) über folgendem Befehl auf den Redix LXC verbinden will, geht das zwar, aber bei der eingabe des ersten Befehl schmeist es mich wieder raus...pi@RasPi41:~ $ redis-cli -h 192.168.1.62 -p 6379 192.168.1.62:6379> info Error: Connection reset by peer pi@RasPi41:~ $nachtrag: Hier noch der Status vom Redis-Container
root@RedisMaster:~# systemctl status redis-server * redis-server.service - Advanced key-value store Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; preset: enabled) Active: active (running) since Fri 2024-01-26 09:08:19 UTC; 5h 5min ago Docs: http://redis.io/documentation, man:redis-server(1) Main PID: 2676 (redis-server) Status: "Ready to accept connections" Tasks: 5 (limit: 9434) Memory: 3.3M CPU: 43.954s CGroup: /system.slice/redis-server.service `-2676 "/usr/bin/redis-server 0.0.0.0:6379" Jan 26 09:08:18 RedisMaster systemd[1]: Starting redis-server.service - Advanced key-value store... Jan 26 09:08:19 RedisMaster systemd[1]: Started redis-server.service - Advanced key-value store. root@RedisMaster:~# ^C root@RedisMaster:~#vG Etze
-
@etzeste13 sagte in Ausfallssicherheit IoBroker - maximale Verfügbarkeit:
New Database could not be connected. Please check your settings. No settings have been changed.
na steht doch da. firewall regeln ??
port ist anders..zumindest kann keine verbindung zum redis (nicht zu der maschiene) hergestellt werden
-
@arteck
sry für die späte antwort, war ein paar tage nicht da...
also ich habe keine firewall -regeln eingetragen und port ist auch 6379 also standard...
ich glaube ich werden den redis-container nochmals aufsetzen und mein glück versuchen...noch eine frage: ich bin bei der weiteren suche nach wie ich das am besten umsetze über die anleitung von darkiop gestolpert, https://github.com/darkiop/doku-iobroker-ha/blob/main/20211113_ioBroker_auf_Proxmox_HA_v1.40.pdf und das scheint ja deinem Setup sehr ähnlich zu sein. Wenn ja, würdest du sagen mann kann diese Anlietung nach wie vor als Guide nehmen?
Ich frage nur, weil mit das Thema mit GlusterFS nichts sagt... und ich der meinung war Proxmox in den aktuellen Versionen, hat ähnliche Funktionen bereits integriert...
Vlt noch eine Frage: Mein aktuelles Produktivsystem läuft ja auf einem RasPi4 mit Redis direkt am Host. Bei den ersten Versuchen ein Backup auf die Proxmox VM aufzuspielen hat das nie funktioniert, weil beim Einspielen des Backups der Redis-Server ja nicht mehr auf 127.0.0.1 liegt. Muss ich für die Migration auf die Proxmox-Umgebung ein Backup erstellen, das auf Basis File oder json ist?
vG Etze
