UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Homoran]

@tottbeck sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

die Systeminfo muss auf dem Raspi3 laufen

aber über den pi4 dort installiert werden

@tottbeck sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

das Script kann auch auf dem Raspi4 laufen, da der die Systeminfo-Objekte kennt,

solange das script nicht auf die Hardware zugreifen muss, ja!

@tottbeck sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

Sind da Latenzzeiten zu befürchten oder ist das vernachlässigbar ?

ich denke das sollte nicht merklich sein

[Tottbeck]

@homoran
Tja, jetzt habe ich schon wieder etwas komisches hinbekommen.
Ich habe das Raspi3-Backup in den Raspi4 eingespielt. Der Raspi3 war dabei noch eigenständig aktiv, also nicht als Slave verbunden.
Der admin vom Raspi 4 war danach auch nach längere Wartezeit nicht erreichbar. Laut "iobroker list instances" ist auf dem Raspi4 alles wie erwartet vorhanden, aber als host Raspi3 eingetragen, der ja (noch) nicht verbunden ist.
Ich habe alle Instanzen außer den Admin auf dem Raspi4 gestoppt (falls das Probleme machen sollte), das änderte aber nichts.
Dann habe ich noch einen neuen admin hinzugefügt (host Raspi4), der ging auch nicht :confused:
Plötzlich ging der neue admin, aber warum auch immer ist der Raspi3 plötzlich der Master und der Raspi4 der Slave. Ich weiß nicht wie ich das hinbekommen habe. Auf dem Raspi3 habe ich nie ein "iobroker multihost enable" gemacht.
Ich kann jetzt zwar wie gewünscht die Instanzen auf dem Raspi3/Raspi4 verteilen und aktivieren, aber die Datenbank liegt auf dem leistungsschwächeren Raspi3

pi@Raspi4:/opt/iobroker $ iobroker multihost status
No configuration change needed.


Multihost discovery server: disabled
Discovery authentication:   enabled
Persistent activation:      disabled
Objects:                    file on 192.168.178.199
States:                     file on 192.168.178.199

pi@Raspi3:~ $ iobroker multihost status
No configuration change needed.


Multihost discovery server: disabled
Discovery authentication:   enabled
Persistent activation:      disabled
Objects:                    file on 192.168.178.199
States:                     file on 192.168.178.199

[Tottbeck]

Was ich noch nicht erwähnt hatte:
Aufgefallen ist mir das erst, nachdem ich ein "iobroker host this" auf dem Raspi4 versucht habe, welches ich scheinbar direkt nach restore des Raspi3-Backups hätte machen müssen, wie ich danach gelesen habe.
Da kam die Meldung ich müsste den iobroker stoppen auch nachdem ich ein "iobroker stop" gemacht habe, weil der Raspi4 da scheinbar schon als Slave mit dem Raspi3 verbunden war.

Und noch weitere Fragen (sorry)
Ist das ein großes Problem wenn die Datenbank auf dem Raspi3 bleibt bzgl Auslastung, ansonsten wäre ich so schon fast glücklich ;-) Z.B. bei VIS-Diagramme (im Raspi4) müssen dann alle Daten vom Raspi3 gesaugt werden, korrekt ?
Noch eine Frage: Kann ich Blockly-Scripte auch auf Master/Slave aufteilen. Benötige ich dann zwei javascript-Instanzen? Es geht mir da um Ausfallsicherheit. Würde der Slave das Blocky/Instanzen noch weiter abarbeiten, wenn der Master ausfällt oder ist dann Feierabend ?

Danke für Euere Geduld.

[Homoran]

@tottbeck sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

Der Raspi3 war dabei noch eigenständig aktiv, also nicht als Slave verbunden.

nicht gut!
dadurch läuft die gleiche Installation doppelt, und wenn du nicht nach dem restore und vor dem start iobroker host this gemacht hast kann genau das passieren.

@tottbeck sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

Ist das ein großes Problem wenn die Datenbank auf dem Raspi3 bleibt bzgl Auslastung,

leider ja.
1GB RAM und bis zu 100MB je Instanz kommt dann bei etwa 10-15 Instanzen an die Grenzen

Den Rest hast du ja auch schon erkannt.

• erst den Pi4 komplett aufsetzen
• dann erst einen neuen "leeren" pi3 an den Pi4 binden
  • ggf ist es mit iobroker setup custom noch eindeutiger
  • beide Systeme müssen unterschiedliche Hostnamen haben, da darüber die Zuordnungen stattfinden

@tottbeck sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

Kann ich Blockly-Scripte auch auf Master/Slave aufteilen. Benötige ich dann zwei javascript-Instanzen?

Ja und ja

@tottbeck sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

Es geht mir da um Ausfallsicherheit.

das nutzt nichts, da der slave ohne Master nicht funktioniert

[Tottbeck]

@homoran
Danke für Deine Klasse Unterstützung.

Bzgl der Speicherauslastung.
Vom ungewollten Master Raspi3 habe ich fast alle Instanzen auf den Raspi4 geschoben (was super umgesetzt ist), so dass der jetzt mit 3 Prozessen deutlich entspannter läuft.

Datenträger verfügbar: 42.1 %, gesamte RAM-Nutzung: 317 MB / Frei: 66% = 611 MB [Host: Raspi3 - 3 Prozesse]

RAM sollte also reichen. Ich habe mir eher um die CPU-Last Sorgen gemacht, da der Raspi4-Slave, der ja die meisten Aufgaben hat, nun ständig auf die Master-Datenbank im Raspi3 zugreifen muss.
Bisher habe ich aber keine negativen Auswirkungen bemerkt.

Beim Slave Raspi4 scheint es übrigens noch einen Fehler bei der Speicherberechnung zu geben, den 317% frei hätte ich gerne ;-)

Datenträger verfügbar: 83.4 %, gesamte RAM-Nutzung: 1638 MB / Frei: 317% = 2.928 MB [Host: Raspi4 - 20 Prozesse]

Achso noch was: Muss das "backitup" zwingend auf dem Master laufen ? Zumindest schmeisst der mir auf dem Raspi4-Slave als host einen Fehler.

[Homoran]

@tottbeck sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

Muss das "backitup" zwingend auf dem Master laufen ?

Muss nicht unbedingt, aber die zu speichernden Daten sind ja alle auf dem Master (bis auf Daten, die von einer Hardware außerhalb des ioBrokers gespeichert werden)

@tottbeck sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

Zumindest schmeisst der mir auf dem Raspi4-Slave als host einen Fehler.

1.) welchen genau?
2.) dann ist ggf. etwas nicht sauber konfiguriert

[Tottbeck]

@homoran sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

1.) welchen genau?
2.) dann ist ggf. etwas nicht sauber konfiguriert

Gestartet...
[DEBUG] [iobroker] - host.Raspi4 3107 states saved
[DEBUG] [iobroker] - host.Raspi4 3711 objects saved
[ERROR] [iobroker] - host.Raspi4 Cannot pack directory /opt/iobroker/node_modules/iobroker.js-controller/tmp/backup: Error: EACCES: permission denied, open '/opt/iobroker/backups/iobroker_2021_03_17-17_43_29_backupiobroker.tar.gz'
[ERROR] [iobroker] - host.Raspi4 Cannot pack directory /opt/iobroker/node_modules/iobroker.js-controller/tmp/backup: Error [ERR_STREAM_DESTROYED]: Cannot call write after a stream was destroyed
[DEBUG] [iobroker] - done

Lag wohl an den Rechte für den backups-Ordner, ich habe die von 755 auf 775 (+group write) gesetzt.

[Homoran]

chso, ich dachte bei der Installation kam der Fehler

[Tottbeck]

@homoran, @simatec
Ich mache das hier nochmal auf, weil ich jetzt beim Backup-Wiederherstellen ein Problem habe.
Siehe https://forum.iobroker.net/post/776412

Ich habe den BackItUp auf dem Slave (Raspi4) laufen, der Backups auf meinem NAS ablegt (4,1MB, + 150kB Javascript).
Ich bin mir nicht sicher wie ich die Hosttyp-Einstellung gemacht habe, kann ich ja leider nicht mehr nachschauen. Auf dem Master hatte ich (meine ich) keine BackItUp-Instanz, aber die für das BackUp relevanten Sachen sind fast ausschließlich auf dem Slave.

Nach einem Absturz kann ich das BackUp nur noch über die Konsole wiederherstellen.

Auf dem Slave geht es per Konsole überhaupt nicht. Auf dem Master (Raspi3) prinzipiell schon, aber die BackUp sind im Slave-Ordner bzw auf dem NAS. Wenn ich das Backup in den lokalen Master-Ordner einspiele, funktioniert das Restore scheinbar, aber danach sind keine Instanzen zu sehen auf beiden hosts. :confused: iobroker ist aktiv aber admin usw laufen nicht.
Ein Altes Backup (bevor ich BackItUp benutzte habe glaube ich) vom 17.03.2021 (das passt genau zu diesem alten Thread) eingespielt. Das funktioniert, aber dann fehlt mir natürlich ein ganzes Jahr.
Da habe ich dann BackItUp-Adapter im alten Backup aktiviert und versucht das neue Backup darüber einzuspielen. Aber auch ohne Erfolg. Was kann ich noch versuchen ?

[Homoran]

@tottbeck ich lese mir den alten Thread nicht nochmals durch.
Aber der backitup gehört auf den Master. dabei werden alle States und Einstellungen des Slaves mit gesichert.

Lediglich für Instanzen, die weitere Software verwenden benötigt man backitup auf dem Slave

[Tottbeck]

@homoran
Danke, ja da würde er wohl besser hingehören, bringt mir jetzt aktuell allerdings nichts. Hatte die Frage "Muss das "backitup" zwingend auf dem Master laufen ?" damals gestellt, deswegen der alte Thread) aber deine Antwort dazu wohl fehlinterpretiert.
Ich hatte angenommen das BackItUp funktional gleich arbeitet und daher den performanteren Slave gewählt.

Die meisten Instanzen auf dem Slave, aber die Daten dazu sind dann ja trotzdem auf dem Master.
Die BackUps sehen von der Größe her vollständig aus, zumindest so groß wie vorherigen Backups vom Master.
Aber ich müsste doch dann wenigstens das Backup, das der Slave erstellt hat dort auch wiederherstellen können.
Das mache ich aber mit einer neuen unkonfigurierten BackItUp-Instanz. Muss ich da vorher noch etwas einstellen z.B. bzgl. host-typ? (Slave habe ich schon probiert).

[Homoran]

@tottbeck sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

Aber ich müsste doch dann wenigstens das Backup, das der Slave erstellt hat dort auch wiederherstellen können

da kann aber nichts drin sein, wenn der Multihost korrekt aufgesetzt wurde.
Alle Informationen liegen auf dem Master.

lediglich die Instanzen, die vor der Einbindung ins Multihost System auf dem Hosts waren (üblicherweise admin, discovery) könnten gesichert werden.

@tottbeck sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

Muss ich da vorher noch etwas einstellen z.B. bzgl. host-typ? (Slave habe ich schon probiert).

kannte ich gar nicht. Gab es früher wohl nicht.
Hab gerade nachgesehen. Bei mir steht da single, obwohl es der Master ist.
Restore der Slaves hat damit aber trotzdem geklappt.
Muss mich dazu mal schlau machen.

[Tottbeck]

@homoran
Danke: Bei "host-typ" war ich mir jetzt auch nicht sicher, dann gab es damals wohl noch nicht.
Der Multihost hat zumindest 1 Jahr anstandslos funktioniert, trotz der nicht idealen Master/Slave Zuordnung.

Die Größe der Backups hat sich damals nach Umstieg auf BackItUp (17.03.21) quasi nicht verändert. Vorher habe ich das Backup direkt per cronjob ausgeführt. Daher dachte ich das Backup ist komplett.

iobroker_2022_03_13-02_00_10_name__backupiobroker.tar.gz	4.508.030	13.03.22 01:59	-a--
iobroker_2022_03_12-02_00_10_name__backupiobroker.tar.gz	4.506.209	12.03.22 01:59	-a--
..
iobroker_2021_03_19-02_00_10_name__backupiobroker.tar.gz	3.548.369	19.03.21 01:59	-a--
iobroker_2021_03_18-02_00_10_name__backupiobroker.tar.gz	3.525.277	18.03.21 01:59	-a--
iobroker_2021_03_17-17_55_54_name__backupiobroker.tar.gz	3.527.346	17.03.21 17:55	-a--
2021_03_17-01_01_03_backupiobroker.tar.gz	3.514.860	17.03.21 01:00	-a--
2021_03_16-01_01_13_backupiobroker.tar.gz	3.508.618	16.03.21 01:02	-a--
2021_03_15-01_01_04_backupiobroker.tar.gz	3.508.132	15.03.21 01:00	-a--
2021_02_11-01_01_04_backupiobroker.tar.gz	3.631.483	10.02.21 21:42	-a--

Die letzte backup.json ist auch immerhin 27MB groß und enthält soweit ich das sagen kann alle Objekte.
Wenn ich z.B. die Module, wo ich noch viel gemacht habe, daraus extrahieren können, wäre mir auch schon viel geholfen.

[Tottbeck]

Die states.json und objects.json vom Master habe ich noch manuell gesichert.
Damit hätte ich doch alle Objekte wiederhergestellt, oder ?
Die javascripts sind getrennt wiederherstellbar.
Dann müsste ich "nur" noch die Adaptereinstellungen und das vis wiederherstellen.(Ich versuche gerade nachzuvollziehen, was ich in dem Jahr alles verändert habe)

Das wiederherstellen über BackItUp klappt ja leider nicht. Vermutlich weil dabei der iobroker gestoppt wird und die Master/Slave Verbindung fehlt.

[DEBUG] [iobroker] Start ioBroker Restore ...
[ERROR] [iobroker] Stop iobroker first!
[DEBUG] [iobroker] ioBroker Restore completed successfully
[EXIT] 99 **** Restore was canceled!! ****

Gerade nochmal probiert, wenn ich das Backup auf dem Master einspiele (egal ob über Backitup oder Konsole), rödelt er zwar 20 Minuten durch, aber danach ist keine Instanz mehr vorhanden. (logs.txt)

[Homoran]

@tottbeck sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

Das wiederherstellen über BackItUp klappt ja leider nicht. Vermutlich weil dabei der iobroker gestoppt wird und die Master/Slave Verbindung fehlt.

nein!
weil die notwendigen Informationen nicht auf den Slave gehören, sondern auf den Master

[Tottbeck]

@homoran sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

weil die notwendigen Informationen nicht auf den Slave gehören, sondern auf den Master

Jetzt habe ich es doch noch iwie hinbekommen. :flushed:
Ich hatte mich schon dabei gesehen wie ich die ganzen Änderungen wieder einbringe. :man-bowing:

Ich habe nochmal auf dem Master das manuell rüberkopierte Backup per Konsole wiederhergestellt.
Diesmal hatte er komischerweise aber die Instanzen per "iob list instances" angezeigt, allerdings deaktiviert. Den admin per konsole aktiviert, danach durfte ich die Instanzen erst alle vom Master auf den Slave schupsen (der Master hätte die überhaupt nicht gepackt.)
D.h. es läuft wieder. :hugging_face:

BackItUp läuft jetzt auf dem Master. Der gerade angelegte Backup ist (fast) genauso groß wie vorher. D.h. der Inhalt des Backups war vorher schon vollständig aber leider nicht (so einfach) wiederherstellbar.

@Homoran: Danke für Deine Geduld.

[Homoran]

@tottbeck sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

Diesmal hatte er komischerweise aber die Instanzen per "iob list instances" angezeigt, allerdings deaktiviert

das ist normal. Unter Backitup kann man auswählen "Starte alle Instanzen"

@tottbeck sagte in Slave Adapter fehlen beim Multihost System aufsetzen:

BackItUp läuft jetzt auf dem Master.

:clap: