Ideen zum sh.py Failover / Hot-Standby

[cmalo]

Klasse Feature! Danke dafür. Würde sich das auch machen lassen dass man das Feature zu Laufzeiten via Item/Logik (also ohne Neustart) An/Ausschalten kann? Wäre für ein Hot-Standby-Switching eine Voraussetzung.

Hallo,

dieser Thread soll ausgehend vom Post von Sandman60 eine Ideen Sammlung zum Thema Failover sein.
Da in der Masse komplexe Probleme besser gelöst werden als vom Individuum und das Thema etwas mehr ist als das KNX-Plugin in den Readonly-Modus zu versetzen bin ich mal auf die Ideen, Probleme und Lösungen gespannt.


Happy Brainstorming!

Fragen:
Wie geht man mit Hardware um?

Ideen:

[Sandman60]

Als erstes Mal wie ich es heute mache:
Ich behelfe ich mir dadurch, dass ich ein Senden via Smartvisu zulasse und sämtliche KNX-Sends durch Logiken jage, diese Logiken wiederum laufen nur auf dem Prod-System und werden schon in Zeile 1 der Logik auf den Nicht-Prod-Systemen zum Exit gebracht.

An keinem der SH's ist eine HW wie 1-W oder Enocean angekabelt, daher sind alle reine NW-Devices. Die Anbindung der HW-Komponenten läuft auf einer zusätzlichen Büchse bei mir.

Was mir fehlt im Moment:
- Abschalten der KNX-Send-Funktionalität damit man auch simple Logiken (eval) in Kombi mit knx_send verwenden kann
- Zyklische Batch-Syncronisation von bestimmten Items, bspw. Config-items wie Emailalerts etc. Das geht evtl. simple über ein Aufbohren der CLI oder via REST, aber es steht hinten auf meiner Liste
- Heartbeat für Auto-Failover. Mache ich aktuell über eine virtuelle KNX_GA, ist natürlich nicht so klasse wenn der KNX-Router grad in der Wartung ist.
- Möglichkeit über eine gleichbleibende URL auf die jeweilige SV des produktiven Systems zuzugreifen, aber das ist eher ein NW-Thema, steht auch auf meiner internen Liste weit hinten...

[mumpf]

Hi,

ich habe failover noch nicht realisiert (und es glücklicherweise in den letzten 2 Jahren nicht gebraucht), ein paar Gedanken habe ich mir aber gemacht.

Kommunikation:

• Dass KNX per Item abschaltbar ist (schreibend), ist schon klasse, war für mich der Hauptgrund, warum ich da nicht ran gegangen bin, der Ansatz vom Sandmann60 wäre für mich nicht wartbar
• Das gleiche sollte man für das nw plugin machen, zumindest werden in meinem Haus auch Aktionen über das Netzwerk angetriggert.
• Theoretisch bräuchte man das auch für onewire, da es hier I/O Bausteine gibt und diese auch Zustände verändern (hab ich bei mir nicht)
• Eigentlich für alle plugins, die ein output erlauben (z.B. auch FritzBox)
• Vielleicht wäre "ReanOnly" ja was für den Kern?

Sync:

• Ich mache meine changes an Items und Logiken sowieso offline auf einer VM mache dann einen sync auf den produktiven Raspi. Den sync dann für nen 2. Raspi einzurichten wäre simpel. Restart wäre dann auch so machbar, dass der 1. (Haupt) Raspi den 2. neu startet, sobald er (fehlerfrei) mit dem Restart fertig ist.
• Mein Ziel ist, ein git auf meinem NAS zu haben, in das alle changes reinlaufen, dann können sich die Raspis vor dem Start immer selbst daraus versorgen.
• Ich würde für den Sync nichts in sh.py einbauen, da es definitiv nur schlechter werden kann als die vorhandenen Möglichkeiten unter linux. Da wäre es besser, den Entwicklungsaufwand in andere Bereiche zu stecken.

Hardware:

• Mein Haupt-Raspi kommuniziert über das Wiregate, der neben-Raspi hat einen TUL (soll aber in Zukunft genau anders rum sein). Wenn der KNX-Zugang auch über den Raspi läuft (also Hardware direkt an der Kiste hängt), dann muss man die Hardware auch redundant haben.
• Wenn man nur ein Failover für die Raspis haben will, muss man die Hardware woanders anschließen, hat dann aber dort wieder ein SPOF.

Sonstiges:

• Ich würde gerne die Failover-Funktionalität auch für den Test-/Release-Zyklus (von neuen sh.py-Versionen, neuen Plugin-Versionen oder neuen Konfigs) nutzen
• Idealerweise sind wirklich beide Raspis gleich berechtigt, neue Versionen meiner Config bzw. sh.py würde ich auf dem derzeitigen Standby-Raspi durchführen, der dann sicherlich mehrmals hoch/runtergefahren wird, bis alles läuft.
• Hier wäre es interessant, die ReadOnly-Eigenschaft über die Kommandozeile steuern zu können: Ich würde neue Sachen erstmal mit ReadOnly=true testen, bis es soweit gut läuft, dann mit ReadOnly = false. Wenn dann alles funktioniert, ist der bisherige Master-Raspi automatisch zum Backup-Raspi geworden und man könnte auf dem die nächste Testrunde machen.

Gruß, Waldemar

[Sandman60]

[*]Ich mache meine changes an Items und Logiken sowieso offline auf einer VM mache dann einen sync auf den produktiven Raspi. Den sync dann für nen 2. Raspi einzurichten wäre simpel. Restart wäre dann auch so machbar, dass der 1. (Haupt) Raspi den 2. neu startet, sobald er (fehlerfrei) mit dem Restart fertig ist.

Mache ich auch so mit meinen Transportskripten, aber damit kann ich die Values, also die Einstellungen, der Items nicht transportieren. Hierzu bräuchte ich eine Schnittstelle um die Values bspw. für essentielle Parameter-Items auszutauschen. Oder hast Du einen Weg schon gefunden wie Du die Current Values zwischen 2 SH-Instanzen synchronisierst?