[Lösung gefunden] Multihost - Vor- & Nachteile ??
-
@asgothian das ist auch so nicht richtig.... wenn du ein redis/redis system hast dann exisiteren keine master und slave mehr sondern nur hosts
diese laufen gegen die redis unabhänging voneinander.. WEITER..da ist es egal ob der Master (also der eine Host) da ist oder nicht
klar wenn die redis weg ist dann geht nix mehr.. -
Ich habe seit Jahren Multihost im Einsatz.
als master:
nuc mit 16 GB (ordentlich speicher) und proxmox (wg. backup und snapshot).
als slave:
einen Raspi 3 (glaub ich).
und hier angeschlossen 2 x smartmeter (wg. Strom und photovoltaik) und 1 x mbus (Wasserzähler).Läuft seit Jahren einwandfrei.
P.S.
Gibt es einen Link wie dies mit 2 unabhängigen Systemen mittels mqtt funktioniert.
(würde mich interessieren). -
@bahnuhr sagte in Multihost - Vor- & Nachteile ??:
Gibt es einen Link wie dies mit 2 unabhängigen Systemen mittels mqtt funktioniert.
Einen Link hab ich da nicht aber auf dem Hauptsystem hab ich MQTT als Server installiert und auf dem entfernten System MQTT als Client. Hat ganz entspannt funktioniert.
Die Systeme sollten halt im gleichen Netzwerk sein.Server:
User und PW vergeben (identisch im Client eintragen)
Client:
IP die vom Server eintragen
-
@djmarc75
Danke dir, hab ich verstanden.Und wie greifst du dann auf die Daten zu ?
vom broker auf client (oder auch umgedreht).
-
@bahnuhr der client liefert und der server verarbeitet.
DPs und Ordner im Ordner MQTT anlegen (clientseitig)
Sobald die angelegten DPs vom Client beschrieben werden tauchen die auch am Server auf !
-
@djmarc75 sagte in Multihost - Vor- & Nachteile ??:
Sobald die angelegten DPs vom Client beschrieben werden tauchen die auch am Server auf !
Ist ja einfach.
Habe bisher mqtt nur mit tasmota und wemos d1 mini und mähroboter mit roboenect modul benutzt.danke dir für die Info
-
@bahnuhr ich nutze mqtt tatsächlich erst seit ..... vorgestern
-
@djmarc75 sagte in Multihost - Vor- & Nachteile ??:
@bahnuhr ich nutze mqtt tatsächlich erst seit ..... vorgestern
dann biste ja ein blitzmerker
-
@bahnuhr sagte in Multihost - Vor- & Nachteile ??:
dann biste ja ein blitzmerker
Ach weisste, manchmal hab ich auch mal das Hirn frei, dann setz ich sowas schnell um....
und trotzdem weiss ich bis heute noch nicht wie man sich als Root auf einem Linuxsystem anmeldet
Und das soll auch so bleiben
-
@djmarc75 sagte in Multihost - Vor- & Nachteile ??:
Root auf einem Linuxsystem anmeldet
da hätte ich sogar eine Anleitung für dich
-
@bahnuhr sagte in Multihost - Vor- & Nachteile ??:
da hätte ich sogar eine Anleitung für dich
BITTE NICHT !!!!
-
Ich hatte ´mal die Idee (aber noch nicht getestet/umgesetzt), auf einem Master (raspi 4B) / Slave (raspi 3B) System Adapter/Instanzen wie z. B. history oder flot (also welche ohne Gerätezugriff) auf den Slave zu verschieben, um den Master von "Rechenarbeit" zu entlasten (weil meine VIS manchmal etwas "träge" ist, wenn ich flot-Diagramme anzeigen lasse). Haltet Ihr das für eine gute Idee oder sollte man das lieber sein lassen?
-
@andersmacher sagte in [Lösung gefunden] Multihost - Vor- & Nachteile ??:
sollte man das lieber sein lassen?
es wird nichts bringen außer zusätzlichem Netzwerktraffic.
Die Dateien und die Verwaltung wird auf dem Master durchgführt
-
@homoran Danke für Deine Rückmeldung!
Da habe ich dann offenbar das Master-/Slave-Konzept noch nicht verstanden.
Muß ich Deine Antwort so verstehen, daß eine flot-Diagrammanfrage aus VIS heraus tatsächlich bezüglich CPU-Leistung immer den Master und niemals den Slave "belastet".
Was läuft denn dann auf dem Slave überhaupt, wenn man dort einen Adapter bzw. eine Instanz liegen hat oder "hinschiebt"?Ich hatte noch vergessen anzugeben, daß ich die History-Daten derzeit auf einem USB-Stick speichere (also nicht auf der SD-Karte, um diese nicht mit Schreibzugriffen "abzunutzen") und ich diesen Stick dann natürlich auch an den Slave hängen würde (momentan hängt er am Master).
-
@andersmacher sagte in [Lösung gefunden] Multihost - Vor- & Nachteile ??:
daß eine flot-Diagrammanfrage aus VIS heraus tatsächlich bezüglich CPU-Leistung immer den Master und niemals den Slave "belastet".
du benutzst so böse, harte Worte wie immer und niemals
Ich kann dir dazu leider wirklich nichts genaues sagen. Wenn du history auf dem Slave laufen hast und dort auch den Stick mit den Daten dran, wird die Rechenarbeit für das Auslesen der Daten und das Aggregieren auf dem Slave stattfinden.
Die Verwaltung der Objects und States findet trotzdem auf dem Master statt.
Inwieweit das jetzt den Master mehr oder wieviel weniger als den Slave belastet kann ich dir nicht sagen. -
@andersmacher sagte in [Lösung gefunden] Multihost - Vor- & Nachteile ??:
@homoran Danke für Deine Rückmeldung!
Da habe ich dann offenbar das Master-/Slave-Konzept noch nicht verstanden.
Muß ich Deine Antwort so verstehen, daß eine flot-Diagrammanfrage aus VIS heraus tatsächlich bezüglich CPU-Leistung immer den Master und niemals den Slave "belastet".
Was läuft denn dann auf dem Slave überhaupt, wenn man dort einen Adapter bzw. eine Instanz liegen hat oder "hinschiebt"?Jede Instanz die auf dem Slave gestartet wird läuft auf dem Slave. Das heisst alle Berechnungen laufen auf dem Slave. Sofern ich das recht erinnere wird eine Vis sofern auf dem Slave auch ein Web Adapter läuft direkt auf dem Slave erzeugt. Auch Flot Abfragen (die primär auf die Daten eines History Adapters zugreifen) laufen damit auf dem Slave ab.
Soweit also so gut. Allerdings liegen die States und Objekte üblicherweise (Es gibt da eine alternative) auf dem Master. Damit sollte ein auf dem Slave laufender History Adapter die Änderungen der einzubeziehenden States über das Netz vom Master erhalten und dann im Dateisystem des Slave abspeichern. Der FLOT Adapter (auf dem Slave) würde dann auch direkt auf die History Daten vom Slave zugreifen - soweit ok.
Ich hatte noch vergessen anzugeben, daß ich die History-Daten derzeit auf einem USB-Stick speichere (also nicht auf der SD-Karte, um diese nicht mit Schreibzugriffen "abzunutzen") und ich diesen Stick dann natürlich auch an den Slave hängen würde (momentan hängt er am Master).
Vom speichern der History-Daten auf einem USB Stick würde ich generell abraten. Die USB Sticks sind noch weniger als die SD Karten auf ständige Schreibzugriffe ausgelegt - diese sterben noch schneller als die SD Karte. Dazu kommt das der Schreib/Lesezugriff auf den USB Stick auch verhältnismässig langsam ist, so das das Schreiben der Daten und das auslesen der Daten für Graphiken eher langsam erfolgt.
Ich hoffe das bringt etwas dunkel ins Licht. (oder so)
A.
-
@homoran Ja, ja, ich da wohl öfter mal zu "digital" in der Formulierung
Aber so, wie Du es jetzt formulierst ("...Rechenarbeit für das Auslesen der Daten und das Aggregieren auf dem Slave stattfinden.") geht das schon in die Richtung, die ich mir als "Entlastung des Masters" vorgestellt hatte. Ist dann wohl doch mal einen Versuch wert, denn ich würde annehmen, daß sich gerade bei flot und history das mit den Objects und States in Grenzen halten müßte und das ja auch jetzt schon auf dem Master läuft und es daher ja eigentlich nichts verschlimmbessern sollte.
-
Ich würde, bevor ich das Setup unnötigerweise komplexer mache als notwendig, erstmal schauen ob das bisherige System überhaupt in den Grenzbereich reingeht und da per Split überhaupt was gewonnen werden kann.
-
zum Thema USB Stick:
ich habe damals als das Thema sterbende SDSD Karten überhand nahm. und gerade der Pi4-2GB rauskam bewusst eine SD Karte genommen und genauso bewusst history.
Dann auf tTeufel komm raus Daten geloggt, teilweise im 6-Sekundentakt 24 Datenpunkte.
Die Karte lebt heute immer noch! -
@asgothian Auch Dir Danke, für die ausführliche Erklärung, die ja wohl tendenziell in die gleiche Richtung läuft.
USB-Sticks habe ich auch genutzt, weil ich davon noch einige habe, die ich für nichts anderes mehr benutze und ich dann auch im Fall eines Ausfalls eines Sticks (allerdings läuft da seit ca. 3a noch immer die 1. Bestückung) nicht gleich ein Problem mit dem ganzen ioBroker habe.
Wenn das mit den "manchmal trägen Diagrammen" allerdings ein selbstgemachtes Problem durch langsame USB-Sticks ist, muß ich da mal ran.
@thomas-braun Bis jetzt schien es mir jedoch so, daß immer, wenn die Diagramme mal hakten, die CPU-Auslastung auch sehr hoch war. Daher meine oben beschriebene ursprüngliche Idee.
