Ausfallssicherheit IoBroker - maximale Verfügbarkeit

[etzeste13]

@arteck
Hallo, danke für die Anleitung, habe das gerade mal probiert.
Kann es sein, dass der Benutzer auf der VM und am Pi gleich sein müssen?
Ich kann nämlich nachdem ich das iobroker Verzeichnis ( /opt/iobroker) vom Pi in das der VM kopiert habe den iob nicht mehr starten, angeblich augrund fehlender berechtigungen.

Muss aber gleich dazu sagen, dass ich den iob schon einige tage zuvor auf der VM installiert hatte und nur mal in betrieb genommen habe, und nicht wie du beschrieben hast die VM gänzlich jungfräulich aufgesetzt habe. sonst habe ich aber das /opt/iobroker verzeichnis auf der VM komplett gelöscht und mit den Daten vom PI getauscht.

vG Etze

[arteck]

@etzeste13 dann mach noch

iob fix

bevor du startest

[darkiop]

@arteck sagte in Ausfallssicherheit IoBroker - maximale Verfügbarkeit:

vielleicht findet sich einer der ein QUorum mit einem PI macht.. und kann berichten

Link zu meiner Doku wurde ja bereits gepostet - der PI als Quorum Device war eigentlich unauffällig.

@arteck sagte in Ausfallssicherheit IoBroker - maximale Verfügbarkeit:

kannst auch ceph nehmen.. der ist in proxmox direkt intergriert

Ja, Ceph wäre auch eine Option. Meine allerdings gelesen zu haben deutlich Hardware (RAM) hungriger. Wie sind da deine Erfahrungen?

[arteck]

@darkiop sagte in Ausfallssicherheit IoBroker - maximale Verfügbarkeit:

Wie sind da deine Erfahrungen?

meine kisten haben alle 32 GB als Arbeitsspeicher.. ich merk da kein Unterschied. ich hatte früher auch gluster installiert
hab nur gewechselt da ceph mit im proxmox intergriert ist

[amg_666]

@arteck sagte in Ausfallssicherheit IoBroker - maximale Verfügbarkeit:

p.s: lass die Finger von einem PI fürs Quorum..

Hallo
kurze Verständnisfrage dazu: Ich habe iob bislang in einem Container unter proxmox laufen (proxmox auf einem intel nuc) Im "standby" läuft ein 2. nuc auf dem auch proxmox mit iob ist, wenn ein System die Grätsche machen sollte, müsste ich manuell das backup (den container) starten.
Ich will das als nächste Projekt meiner Hausautomatisierung auch auf nodes verteilen mit dem Ziel, dass es stabil auch ohne manuelles Eingreifen im Fehlerfall weiterläuft.
Dazu würde ich iob wohl von Container auf VM umziehen.
Frage: Warum keinen Pi fürs Quorum, bzw was würdest du da mind. empfeheln oder hast du selber im Einsatz. Ich tendiere da bei mir zu einem 3. nuc, spricht da was gegen?
2. Frage: zigbee - Wie machst du das mit dem USB Stick, das wäre doch weiterhin ein single point of failure? Oder kann man auf 2 iob Instanzen jeweils zigbee laufen lassen? Die Devices würden doch nur mit einem Stick/einem Adapter reden?

[arteck]

@amg_666 der pi macht nur das quorum.. mehr nicht.dan bi ich bei dir.. im meisten Fällen installieren sich die Leute noch was da drauf.. und dann fängt der Schlamasel an

ich habe 5 Nuc's... laufen
obs VM oder LXC ist egal.. LXC wird bei migration durchgestartet VM läuft weiter.. also ohne abbruch.

mein Zigbee Stick wie auch der Zwave steckt in einem rock64.. und der gibt die Port per ser2net raus..
das ist der einzie POF bei mir.. wobei ich daneben ein OrnagePi liegen habe mit der gleichen IP und den gleichen Einstellungen..
sollte der Rock abrauchen..warum auch immer...

und wozu soll ich jetzt 2 iob instanzen laufen haben.. ??

[amg_666]

@arteck sagte in Ausfallssicherheit IoBroker - maximale Verfügbarkeit:

und wozu soll ich jetzt 2 iob instanzen laufen haben.. ??

ich meinte 2 Instanzen (oder Slaves ??) um wirklich 2 zigbee sticks aktiv zu haben, aber das scheint ja nicht zu gehen, also muss man da wohl mit single pooint of failure leben

[arteck]

@amg_666 sagte in Ausfallssicherheit IoBroker - maximale Verfügbarkeit:

also muss man da wohl mit single pooint of failure leben

jep leider

[etzeste13]

@arteck Ich habe das Thema mit der Migration mal getestet, so wie du beschrieben hast...
Also Redis dump auf den LXC Container kopiert, und alle dateien von /opt/iobroker vom RasPi in das gleiche Verzeichnis der neu aufgesetzten VM kopiert.
wenn ich dann "iob setup custom" oder jeden anderen iob Befehl starten möchte, funktioniert das nicht und zwar mit folgender Fehlermeldung

hast du eine Ahnung was ich da noch falsch gemacht haben könnte?
Hier noch ein Screenshot des iobroker verzeichnises der VM

was mache ich da falsch?

lg Etze

[arteck]

@etzeste13 sagte in Ausfallssicherheit IoBroker - maximale Verfügbarkeit:

was mache ich da falsch?

aufmerksam lesen... aber nochmal

zuerst da rein ein iob installieren und nicht direkt kopieren..
damit alles so ist wie es soll..

dann den iobroker Verzeichniss löschen und deinen anstatt reinkopieren
dann zuerst

iob host this
iob fix

dann sollte es laufen

[etzeste13]

@arteck said in Ausfallssicherheit IoBroker - maximale Verfügbarkeit:

iob host this

Das ist ja das Problem, das ich zu diesen Befehlen gar nicht komme, weil überhaupt kein iob xxx Befehl funktioniert.
Bevor ich ja

iob host this  
iob fix

ausführen kann müsste ich ja laut deiner Beschreibung

iob setup custom

machen damit ich den neuen LXC-Redis-Server einstellen kann
ich befürchte wenn ich

iob host this  
iob fix

vor

iob setup custom

das es dann nicht funktioniert, weil er ja noch nicht den neuen Redis-Server kennt...., oder verstehe ich da was falsch?

Wäre die Migration vielleicht leichter, wenn ich den aktiven host auf json oder File umstelle und dann ein Backup erstelle, bzw. die Daten aus /opt/iobroker in die VM kopiere?
Müsste ich dann während dieser Zeit auch alle Slaves entsprechend umstellen und den Master-Pi als Datenquelle angeben...?

[arteck]

@etzeste13

lesen BITTE LESEN..sonst bin ich hier raus.. wenn du nur die hälfte machst

zuerst da rein ein iob installieren und nicht direkt kopieren..
damit alles so ist wie es soll..

dann den iobroker Verzeichniss löschen und deinen anstatt reinkopieren

[etzeste13]

@arteck
Hallo Arteck,

sorry ich will wirklich nicht lästig sein. Und ich glaube auch, das ich keinen strukturellen fehler gemacht habe.Ich liste meine Schritte also nochmals auf die zu dem Ergebniss führen, dass iob- Befehle inkl iob-setup custom nicht mehr funktionieren.

1: debian VM aufgesetzt
2: Iobroker auf der nackten VM mit Befehlen

sudo apt-get install curl
curl -sLf https://iobroker.net/install.sh | bash -

installiert.
3:) Auf dieser "nackten IOB-VM" habe ich dann den Inhalt aus dem Orner /opt/iobroker gelöscht und mit den Dateien von meinem PI aus dem Ordner /opt/iobroker ersetzt.

und ab diesem Zeitpunkt, kann ich keinen iob-Befehl auf der IOB-VM mehr absetzen. Ich bin das mehrere Male durchgegangen ist aber immer das gleiche ergebnis

Muss ich vielleicht beim Kopieren der Daten vom PI auf die VM auf was spezielles aufpassen? Ich habe es bisher einfach mit WinSCP vom RasPi auf meinen PC kopiert und von da wieder per WinSCP auf die VM....

Vg Etze

[BananaJoe]

@amg_666 sagte in Ausfallssicherheit IoBroker - maximale Verfügbarkeit:

2. Frage: zigbee - Wie machst du das mit dem USB Stick, das wäre doch weiterhin ein single point of failure? Oder kann man auf 2 iob Instanzen jeweils zigbee laufen lassen? Die Devices würden doch nur mit einem Stick/einem Adapter reden?

Richtig.
Deshalb würde ich ein ZigBee-Gateway nehmen welches über LAN angesprochen wird. Dann kannst du das Backup einfach starten und - Zack - ZigBee ist wieder verbunden.
Ich habe auch eine ioBroker VM auf einem Host und einen 2. als Backuphost auf dem ich die Kopie / den Restore wieder Starten könnte.

[amg_666]

@bananajoe sagte in Ausfallssicherheit IoBroker - maximale Verfügbarkeit:

Deshalb würde ich ein ZigBee-Gateway nehmen welches über LAN angesprochen wird.

Das Thema ist fü mich neu. Hier im Forum wird ja meist über zigbee Sticks diskutiert. Mit Gateway meinst du sowas?
https://www.amazon.de/NOUS-E1-ZigBee-Gateway-Bluetooth-Wei%C3%9F/dp/B0054PSJRC/ref=sr_1_1?keywords=zigbee+gateway&qid=1707434352&sr=8-1-spons&sp_csd=d2lkZ2V0TmFtZT1zcF9hdGY&psc=1

Klingt interessant, was nutzt du und wie sind deine Erfahrungen? Tuya, hue, Tradfri & co, läuft das alles (problemlos)?

[arteck]

@etzeste13 sagte in Ausfallssicherheit IoBroker - maximale Verfügbarkeit:

WinSCP

von winscp war nicht die rede.. ja die rechte passen dann nicht..das geht so nicht
dann musst du es zoppen und das zip file dann nach dem transferieren entpacken

oder du setzt die rechte manuell auf

[etzeste13]

@arteck
OK, an das da die Rechte nicht passen, an das hätte ich nicht gedacht.... danke für den Hinweis!!

[etzeste13]

@arteck
Hallo, nachdem ich alle daten per zippen eingespielt habe hat das system nach dem Tausch der Daten auch funktioniert!! Nochmals Danke für den Hinweis.

Was nun aber abweichend zu deiner Erklärung ist, dass wenn ich

iob host this

ausführe, das folgende Fehlermeldung kommt

[arteck]

@etzeste13 dann mach das wenns das da steht

iob setup first

[etzeste13]

@arteck
Hallo,
hatte ich auch gemacht, bringt folgenden fehler:

Habe mir dann das Redis-Log angesehen und im File des Redis LXC Containers steht unter /var/log/redis/redis-server.log laufend folgender eintrag.

5246:M 09 Feb 2024 15:38:20.138 # Background saving error
5246:M 09 Feb 2024 15:38:26.071 * 1 changes in 3600 seconds. Saving...
5246:M 09 Feb 2024 15:38:26.076 * Background saving started by pid 8301
8301:C 09 Feb 2024 15:38:26.076 # Failed opening the temp RDB file temp-8301.rdb (in server root dir /var/lib/redis) for saving: Permission denied
5246:M 09 Feb 2024 15:38:26.176 # Background saving error
5246:M 09 Feb 2024 15:38:32.009 * 1 changes in 3600 seconds. Saving...
5246:M 09 Feb 2024 15:38:32.014 * Background saving started by pid 8302
8302:C 09 Feb 2024 15:38:32.014 # Failed opening the temp RDB file temp-8302.rdb (in server root dir /var/lib/redis) for saving: Permission denied
5246:M 09 Feb 2024 15:38:32.114 # Background saving error
5246:M 09 Feb 2024 15:38:38.048 * 1 changes in 3600 seconds. Saving...
5246:M 09 Feb 2024 15:38:38.053 * Background saving started by pid 8305
8305:C 09 Feb 2024 15:38:38.053 # Failed opening the temp RDB file temp-8305.rdb (in server root dir /var/lib/redis) for saving: Permission denied
5246:M 09 Feb 2024 15:38:38.153 # Background saving error
5246:M 09 Feb 2024 15:38:44.085 * 1 changes in 3600 seconds. Saving...
5246:M 09 Feb 2024 15:38:44.090 * Background saving started by pid 8311
8311:C 09 Feb 2024 15:38:44.090 # Failed opening the temp RDB file temp-8311.rdb (in server root dir /var/lib/redis) for saving: Permission denied
5246:M 09 Feb 2024 15:38:44.191 # Background saving error
5246:M 09 Feb 2024 15:38:50.023 * 1 changes in 3600 seconds. Saving...
5246:M 09 Feb 2024 15:38:50.027 * Background saving started by pid 8312
8312:C 09 Feb 2024 15:38:50.027 # Failed opening the temp RDB file temp-8312.rdb (in server root dir /var/lib/redis) for saving: Permission denied
5246:M 09 Feb 2024 15:38:50.127 # Background saving error

dann habe ich mir noch die Berechtigungen der dump.rdb angesehen....

root@RedisMaster:/var/lib/redis# ls -la
total 136408
drwxr-xr-x  2 1001 1001      4096 Feb  9 10:15 .
drwxr-xr-x 19 root root      4096 Feb  7 16:38 ..
-rwxr-xr-x  1 1001 1001 139670368 Feb  9 10:15 dump.rdb
root@RedisMaster:/var/lib/redis# 

dabei ist mir aufgefallen, dass die berechtigungen am RasPi hier anders sind... kann das das Problem sein? wenn ja, gibt es eine möglichkeit das richtig zu stellen?

root@RasPi41:/var/lib/redis# ls -la
insgesamt 136404
drwxr-x---  2 redis redis      4096  9. Feb 15:57 .
drwxr-xr-x 45 root  root       4096 10. Aug 2023  ..
-rw-rw----  1 redis redis 139669358  9. Feb 15:57 dump.rdb
root@RasPi41:/var/lib/redis#