Automatischer Failover bei zwei Fheminstallationen

Begonnen von sweetie-pie, 23 April 2014, 08:57:06

Vorheriges Thema - Nächstes Thema

sweetie-pie

Moin,

ich habe eine sehr umfangreiche FHEM-Installation mit über 450 Geräten. Um so ärgerlicher ist es, wenn der FHEM-Server mal aussteigt.
Für Test und Entwicklung nutze ich eine Zweitinstallation mit extra Interface, die i.d.R. nur passiv lauscht aber nicht sendet (at, notify u.ä. mit attr device disable 1).

Ich stelle mir jetzt so etwas vor, wie einen automatischen Failover: Hängt die erste Installation wir automatisch die Zweitinstallation aktiv.
Denkbar wäre da z.B. eine Heartbeatfunktion zwischen den beiden Installationen. Mit ist klar, dass man das über Umwege schon jetzt realisieren könnte in dem man z.B. über eine Utils-Funktion die disabled-Attribute auf "0" setzt....

Was ich mit aber vorstelle wäre eine 1:1-Kopie der Installation inkl. fhem.cfg und statefile. In der fhem.cgf müsste es dann etwa einen folgende Einträge geben:
master 192.168.178.100
slave 192.168.178.101
failover true
failovertimeout 10
#force slave

Ich denke diese Funktion lässt sich nicht als Modul entwickeln sondern müsste direkt in fhem.pl realisiert werden.
Was haltet Ihr von der Idee? Gibt es bei anderen Usern auch diesen Bedarf?

Gruß
Holger

betateilchen

Nimm für die Konfiguration die configDB, da hast Du sowohl die fhemconfig als auch das statefile drin.

Die Datenbank sollte natürlich an einer Stelle liegen, die von beiden Systemen erreicht werden kann (also am besten NICHT auf einer der beteiligten fhem-Installationen) Wenn die "backup-fhem" Hardware auf Betriebssystem erkennt, dass das "main-fhem" nicht mehr funktioniert, braucht es einfach nur das zweite fhem zu starten, das die gleiche configDB benutzt.

Wichtig ist natürlich, dass Du regelmäßig das statefile schreibst (bei mir passiert das alle 30 Minuten automatisch).

Eine solche Funktion innerhalb von fhem selbst umzusetzen, halte ich nicht für zielführend.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

justme1968

um die ausfallsicherheit zu erhöhen ist es nicht das richtige noch ein zusätzliches system (extra db server) einzuführen. das erhöht die wahrscheinlichkeit statt sie zu verringern.

die db auf beiden fhem systemem zu clustern (simples master/slave reicht und mysql sollte das können. postgres kann es definitiv) wäre hier das richtige wenn man den weg über configdb geht.

wenn das ganze aber sowieso kein active/active system ist sondern nur ein standby/failover dann reicht es auch völlig config- und statefile regelmäßig z.b. per rsync zu synchronisieren und ein paar generationen aufzuheben. die verzögerung und die generationen bilden gleich noch ein schutz gegen 'verkonfigurieren'.

du solltest übrigens beim automatischen starten des backup system sicherstellen das das primär system wirklich nicht mehr funktioniert und das es auch nicht automatisch wieder startet. gerade in verbindung mit der db variante sollte sehr genau darauf geachtet werden nicht versehentlich zwei aktive systeme laufen zu haben.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

sweetie-pie

Zitat von: betateilchen am 23 April 2014, 10:00:06
Nimm für die Konfiguration die configDB, da hast Du sowohl die fhemconfig als auch das statefile drin.
Das ist auch ein Ansatz...
Zitat von: betateilchen am 23 April 2014, 10:00:06
Die Datenbank sollte natürlich an einer Stelle liegen, die von beiden Systemen erreicht werden kann (also am besten NICHT auf einer der beteiligten fhem-Installationen)
Dazu bräuchte ich dann noch eine dritte Installation die wieder ein "Single-Point-of-Failure" darstellen würde. In dem Fall würde ich es dann vorziehen mit MySQL und asynchroner Replikation zu arbeiten, was ich allerdings wiederum für meine CUBIE-Boards als "oversized" betrachte.
Zitat von: betateilchen am 23 April 2014, 10:00:06
Wenn die "backup-fhem" Hardware auf Betriebssystem erkennt, dass das "main-fhem" nicht mehr funktioniert, braucht es einfach nur das zweite fhem zu starten, das die gleiche configDB benutzt.
Mit geht es eher darum, ein echten Hot-Standby auf Applikationseben zu haben. Ich hatte mit gedacht, dass die Backupinstallation durchgängig lauschen soll und nur wenn die andere fhem-Installation nicht mehr aktiv ist bzw. arbeitet, dann soll der Wechsel erfolgen. Mache ich das auf BS-Ebene, muss ich dort auch ein "Hängen" von fhem erkennen. Das kommt bei mir durchaus hin und wieder mal vor... vermutlich wenn irgendwelche TCP-Verbindungen abreißen...
Zitat von: betateilchen am 23 April 2014, 10:00:06
Eine solche Funktion innerhalb von fhem selbst umzusetzen, halte ich nicht für zielführend.
Okay, meinst du dies aus logischen Gründen oder programmiertechnischen Gründen heraus?

Gibt es einen einfachen weg ALLE  at und notify-Funktionen Global zu de-/aktivieren?


betateilchen

Zitat von: sweetie-pie am 23 April 2014, 10:48:09
Okay, meinst du dies aus logischen Gründen oder programmiertechnischen Gründen heraus?

Aus logischen Gründen.

Zitat von: sweetie-pie am 23 April 2014, 10:48:09
Gibt es einen einfachen weg ALLE  at und notify-Funktionen Global zu de-/aktivieren?

Natürlich...


attr TYPE=AT disable 1
attr TYPE=notify disable 1


Das Datenbankproblem könntest Du z.B. dadurch lösen, dass Dein Backup-fhem regelmäßig die configDB des main-fhem in eine lokale sqlite-DB clont. Dann sparst Du Dir die dritte Instanz und das Aufsetzen eines zweiten MySQL Servers auf dem Backup-fhem.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

sweetie-pie

Zitat von: betateilchen am 23 April 2014, 10:54:26
Natürlich...

attr TYPE=AT disable 1
attr TYPE=notify disable 1

Sehr cool... aber das steht nicht in meiner Hilfe !?  :o

betateilchen

Doch, das steht in der commandref, sogar ziemlich weit oben...

(http://up.picr.de/18010939ir.jpg)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

sweetie-pie

Okay, ich habe nochmal ein wenig nachgedacht und gelesen:

Wäre es möglich eine globales Attribut passiv einzuführen?
Ist das Attribut gesetzt, verhält sich die Installation passiv, d.h. es werden alle Kommandos von extern empfangen und intern verarbeitet (logging, notifys, u.a.), aber nach extern wird nichts gesendet.

Ich habe mal (obwohl ich von Perl so gut wie keine Ahnung habe), in fhem.pl rumgeguckt.
Dort gibt es ja folgende Funktion:

sub
IOWrite($@)
{
  my ($hash, @a) = @_;

  my $dev = $hash->{NAME};
  return if(IsDummy($dev) || IsIgnored($dev));
  my $iohash = $hash->{IODev};
  if(!$iohash ||
     !$iohash->{TYPE} ||
     !$modules{$iohash->{TYPE}} ||
     !$modules{$iohash->{TYPE}}{WriteFn}) {
    Log 5, "No IO device or WriteFn found for $dev";
    return;
  }


Wenn ich das richtig verstehe, wird hier abgebrochen, wenn es ein Dummy-Device ist. Kann man nicht hier auch einfach abbrechen, wenn passiv gesetzt wäre?

Ich denke doch mal, ich bin hier nicht der einzige der zwei fhem-Installationen parallel betreibt (Stable und Testing), oder später mal Aktiv und Hot-Standby.

Gruß
   Holger

sweetie-pie

BTW: Die Dummy-Abfrage ist m.E. nicht sauber implementiert:

Auch attr MyIODev dummy 0 bricht dort auch ab, nicht nur 1.

Vielleicht kann man beim Fixen ja gleich das globale Attribut implementieren?

;) ;) ;) ;)

betateilchen

Bevor Rudi ein neues globales Attribut einführt, müssen erstmal Ostern und Weihnachten auf einen Tag fallen oder im Osten ein Stern aufgehen, nachdem eine Jungfrau ein Kind zur Welt gebracht hat...
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

P.A.Trick

Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn

Mathea

#11
Hi Leute,
ich würde dieses Thema gerne noch einmal aufgreifen, da ich gerade dabei bin eine Failover-Lösung mit zwei Raspberries aufzubauen. Es hapert allerdings an dem Punkt, die configDB aus dem /opt/fhem Ordner herauszulösen, um sie für beide Server zugänglich zu machen. Gibt es dazu eine best-practice?
Das Problem: in dem Ordner in dem die configDB liegt, muss auch fhem.pl liegen, usw. Es entstehen also relativ viele Abhängigkeiten und man kann nicht einfach nur die Datenbank verlagern.

Hat jemand einen Tipp für mich?

Edit: Ok, ich habe etwas recherchiert und kam dann auf den Begriff der Hard- / Softlinks, was ich mir so ähnlich vorstelle wie eine Verknüpfung. Könnte ich meine condigDB also zum Beispiel auf meinem glusterfs file System oder NAS ablegen und im /opt/fhem Ordner einen Link dort hin erstellen?

kurzes Update: Softlink war das was ich gesucht habe, das funktioniert. Die FHEM Konfiguration in ein glusterfs system zu übertragen war aus verschiedenen Gründen eine blöde Idee. Ich experimentiere weiterhin mit verschiedenen Failover Lösungen rum.

Gruß,
Mathea