FHEM mit Zweitserver?

[Kharim]

Hallo Zusammen,

folgendes ist (noch) mehr ein Gedankenkonstrukt:
Ich habe einen Pi2 mit Fhem und einen über LAN angeschlossenen MaxCube(geflasht mit culfw).

Wenn ich nun einen zweiten Pi2 daneben stelle, ebenfalls mit FHEM, kann ich doch mittels FHEM2FHEM alle Ereignisse des "originalen" Fhems empfangen - richtig?
Nun steht aber im Wiki:
"Einschränkungen: Geräte der entfernten FHEM-Instanz werden über autocreate lokal nicht automatisch angelegt und können weder mit list angezeigt noch lokal angesprochen werden. "

Das heißt, der zweite Pi2 müsste praktisch eine 1zu1 Kopie sein, damit auch das FHEM genau gleich ist?

Im zweiten Fhem müsste man natürlich die Kommunikation mit dem Cube solange unterbinden, wie FHEM2FHEM keine Fehler bringt.....lässt sich das überwachen?

Ziel könnte es am Ende sein, bei Ausfall des ersten Pi/Fhem auf dem zweiten Pi vollautomatisch die IP Adresse zu wechseln und die Kommunikation mit dem Cube zu aktivieren. Damit wäre das System quasi redundant....

Grüße,
Kharim

[CoolTux]

Wenn ich Dich recht verstehe möchtest Du einen Cold Standby System haben. Zu diesem Thema habe ich in der alten Google Usegroup von FHEM mal was gelesen. Eventuell findest Du da was.
Ein Teilnehmer war unter anderem Rudi.


Grüße

[CoolTux]

Habe das mal noch gefunden beim suchen

https://forum.fhem.de/index.php/topic,41813.0.html

[Kharim]

Das klingt schonmal sehr interessant...
Vielen Dank für die schnelle Antwort.

Kannst du mir eventuell noch einen Anstoß zu meinen Frage geben?
Sprich lässt sich der Erfolg einer FHEM2FHEM Synchronisierung überwachen?
(sollte diese ausfallen bedeutet dies ja gleichzeitig FHEM oder Netzwerk am ersten Pi gestorben und könnte damit gleich als Auslöser genutzt werden.)

[[Die 1zu1 Kopie muss ja logischer Weise sein, wenn der Zweit-Pi einspringen soll.]]

Danke,
Kharim

[r_knipp]

Sprich lässt sich der Erfolg einer FHEM2FHEM Synchronisierung überwachen?
(sollte diese ausfallen bedeutet dies ja gleichzeitig FHEM oder Netzwerk am ersten Pi gestorben und könnte damit gleich als Auslöser genutzt werden.)

FHEM2FHEM macht keine Synchronisation. Es zieht sich die Ereignisse von einer entfernten FHEM Instanz.
Das Modul liefert als Status connected oder disconnected. Das könnte man ja nutzen.

[Wernieman]

Überlege Dir mal die Hauptgründe, warum Dein FHEM nicht mehr laufen kann .. und dann erst eine Lösung.

Wenn Du einen "echten" 24/7 Betrieb brauchst und Dir der RasPi dafür zu unstabil, ist eventuell auch die Lösung: eine bessere Platform ..

Bitte berücksichtige auch die "False Positive".. z.B. wenn nur das Netzwerk ausfällt, denkt der 2. RasPi, das der erste weg ist und fängt auch an. Wenn dann (wegen) eines Wacklers das Netzwerk wieder "da ist", versuchen beide Deinen Cube zu steuern .. ob das gut geht ...

[Kharim]

Bitte berücksichtige auch die "False Positive".. z.B. wenn nur das Netzwerk ausfällt, denkt der 2. RasPi, das der erste weg ist und fängt auch an. Wenn dann (wegen) eines Wacklers das Netzwerk wieder "da ist", versuchen beide Deinen Cube zu steuern .. ob das gut geht ...

Guter Einwand....Vorraussetzung dafür wäre aber, dass der 2. Pi auf der IP des 1.Pi läuft, es also auch einen IP-Adressen Konflikt gibt.
Nehmen wir einmal an ich habe 2 bau- und software-gleiche Pi's, beide komplett identisch.
Dazu nehme ich 2 IP Adressen. Eine Ausweich-IP und eine IP auf der der eigentliche Dienst (FHEM) erreichbar sein soll.

Fall a)
zb nach Update und Imageverteilung booten beide PIs auf der selben IP
->es wird ein Adresskonflikt erkannt
->es wird eine Zufallswartezeit ermittelt (1-60s)
->es wird erneut auf Adresskonflikt geprüft
-> existiert dieser noch wird IP verändert und Netzwerk neu gestartet
-> existiert er nicht mehr ist alles gut
=> Einer der beiden Pis sollte durch die Wartezeit schneller sein und somit den Konflikt lösen

Fall b)
Wackelkontakt an Ausweich-IP / Ausfall Ausweich-IP
-> bestimmte Wartezeit und erneuter Test ob Dienst-IP vorhanden
-> IP Änderung
=> Alles gut, oder "irgendwann" Fall a

Fall c)
Wackelkontakt an Dienst-IP / Ausfall Dienst-IP
-> FHEM2FHEM meldet disconnect auf Ausweich-IP
-> Wartezeit und erneuter Test
-> IP Änderung
=>Alles gut, oder "irgendwann" Fall a

Am Besitz der Dienst-IP würde ich die Ausführung von FHEM2FHEM, sowie die Steuerung der Gateway(Cube) fest machen.
Also:
Besitze ich die Dienst-IP darf ich die Gateway ansprechen, aber kein FHEM2FHEM ausführen.
Besitze ich die Ausweich-IP darf ich die Gateway nicht ansprechen, muss aber FHEm2FHEM ausführen.

In jedem Fehlerfall muss logischer Weise eine E-Mail Benachrichtigung erfolgen.
Man könnte auch (um es auf die Spitze zu treiben) beide Pis hinter schaltbare Steckdosen setzen und somit durch den Gegenseitigen IP-Test einen harten Neustart auszuführen bzw nach einem Fehler.
(Zumindest im Falle des Cubes, welcher selbst über das Netzwerk angesprochen wird, entsteht kein sinnloses Dauer-Neustarten bei einem kompletten Netzwerkausfall)


Ist wie gesagt alles noch ein reines Gedankenkonstrukt, aber mich juckt es schon in den Fingern, das mal zu bauen :-D

Grüße,
Kharim

[Wernieman]

War nur ein Beispiel für ein "split Brain" ...

wie Du schreibst ist alles Lösbar, aber dazu holst Du Dir neues Konfliktpotential durch die zunehmende Komplexität ins Haus. Eine 100% Verfügbarkeit ist übrigens Informations-teoretisch nicht erreichbar, man kann sich nur asymptotisch annähern.

[r_knipp]

Ist wie gesagt alles noch ein reines Gedankenkonstrukt, aber mich juckt es schon in den Fingern, das mal zu bauen :-D

Dann würde ich an deiner Stelle auf jeden Fall http://www.linux-ha.org/wiki/Main_Page nutzen.
Das ist genau für dein Szenario gemacht.