"Hochverfügbarkeit" mit piVCCU

[Familienvater]

Hi,

ich habe da gerade so eine blöde Idee, so ein "Wunsch" wurde schon öfters im Forum mit einem ähnlichen Ziel diskutiert (rfd auf der CCU gestoppt lassen, etc):
Mal angenommen, man hätte 2 Raspberry Pi, jeder hat sein eigenes Funkmodul, es gibt einen "Live-Raspi" und einen warmen (laufenden) "Hotspare-Standby"-Raspi.
z.B. per rsync wird das User-Filesystem des laufenden Containers auf den Standby-Container gesync (theoretisch wenn man nicht "bastelt" langt alle 12h, dann wird die Regadom geschrieben), der Standby-Container selbst ist aber gestoppt. Wenn jetzt irgendwas mit der Live-Instanz ist, könnte dort einfach der Container gestoppt werden, und direkt die Instanz auf dem Hotspare-Raspi hochgefahren werden? Oder müsste wegen anderer Funk-Modulseriennummern noch irgendwas an den Configdateien gebastelt werden?

Das man sich durch das "permante" rsyncen ggf. auch eine kaputte Installation/Regadom etc. auf die "warme" Reserve holt, ist klar, das ist eher eine Art RAID, was die Verfügbarkeit erhöht, und kein Backup, was für Datensicherheit sorgt.

Guten Rutsch und nicht zu doll,
der Familienvater

[deimos]

Hi,

prinzipiell machbar mit den "normalen" Einschränkungen, das es nach dem Neustart dauern kann, bis der Status aller Geräte wieder korrekt in der CCU vorhanden ist. Zusätzlich kann es bei HmIP beim Wechsel des Funkmoduls dauern kann, bis die Keys im Hintergrund neu ausgehandelt sind.

Es reicht daher nicht einfach nur, piVCCU selber HA zu machen, man muss sich auch bei Skripten Gedanken machen, wie man das dann entsprechend sinnig umsetzt.

Da ich da zu viel Fallstricke für einen normalen Nutzer sehe, werde ich das nicht allgemein umsetzen, aber ich unterstütze gerne, wenn das jemand bei sich umsetzen möchte (und dann vielleicht auch dokumentiert ).

Erste Stichworte wären Heartbeat und ggf. Corosync für den Abgleich der Daten.

Viele Grüße
Alex

[Daimler]

Hi,

ich bin mir auch nicht sicher, wie sich die aktuellen Firmwaren mit der anderen SN des Funkmoduls verhalten.
Zu Anfangszeiten von Yahm musste ich jedenfalls beim Wechsel meiner Produktion auf einen anderen PI mit neuem Funkmodul die Zuordnung aller über das Funkmodul laufenden Geräte auf die neue SN anpassen.

Ansonsten interessante Idee.

Wünsche Euch allen auch einen Tollen und nicht zu dollen Rutsch ins neue Jahr - auf das es die HM-Herzen höher schlagen lässt.

[svenp]

Hallo, mit VmWare gibt es die Möglichkeit eine Schatteninstanz zu starten.
Diese Instanz hat nicht nur die Daten der Festplatte sondern auch Live was im Speicher ist.
Fällt eine Instanz aus, kann die andere innerhalb einer Sekunde übernehmen.

Mir ist klar das VmWare ne nummer zu groß ist. Aber es gibt solche Lösungen auch fast immer im OpenSource Bereich.
Evtl. ist das auch als kleine Linux Lösung machbar.

Dann hättest du eine Optimale Hochverfügbarkeit.
Mit drbd lässt sich wenn ich das richtig sehe nur die Festplatte Blockbasiert syncen. Was nun fehlt ist der Speicher das VM.

[-Markus-]

Ich werde das bei mir mit einem Pacemaker-Cluster lösen, wobei ich mir noch nicht ganz genau sicher bin welche Komponente ich clustere und welche nicht.

Ich sehe das wie Familien-Vater:
Die Config wird ja "bewusst" angefasst und kann daher in einem Arbeitsschritt auch synchronisiert werden. Hier geht es um die Möglichkeit ein Fallback zu haben - oder mal für Wartungsarbeiten manuell umschwenken zu können.

Gruß
Markus

PS: Baubeginn ist Mitte Februar - ich brauche noch ein wenig

[Familienvater]

Hi,

wenn man aktuell eine CCU mit funktionierendem Funkmodul einfach so als virtuelle x86-Maschine laufen lassen könnte, und es mein benötigtes Homeputer-Addon auch als x86-Version dafür gäbe, dann würde das wahrscheinlich schon längst auf dem ESXi bei mir laufen, und dann würde ich mir auch keinen Kopf wegen der Verfügbarkeit machen. So komplizierte Dinge wie Hauptspeicher spiegeln brauch ich gar nicht, meine Homeputer-Lösung sichert selbstständig die wichtigsten Zustände regelmäßig auf einem NFS-Share, und ließt die auch entsprechend beim Starten wieder ein, von daher wäre ein automatischer rsync der Userpartition nur die "faule" Variante, um neu angelernte Geräte etc. auf der warmen Reserve aktuell zu halten.

Der Hintergrund meiner Idee ist einfach, mir fehlt definitiv die Langzeit-Erfahrung, was den Einsatz von SD-Karten bzw. mSATA-SSDs am Raspi angeht, und das ist meine größte Sorge, das der spontane Speicherzellen-Tod gemäß Murphy eintritt, wenn man gerade am Flughafen mit der ganzen Familie geboarded ist, und der Flieger demnächst in den 3 wöchigen Urlaub abhebt (einfachste Lösung, einfach 2 Wochen vor dem Urlaub alles auf eine neue Karte kopieren, falls die Dead-on-Arrival wäre bzw. in den ersten Tagen ausfällt, alles gut, aber das wäre ja viel zu einfach). Da nützt mir theoretisch der beste VPN-Zugang aus der Luft nichts, irgendwie muss eine neue Speicherkarte in den Raspi. Das könnte man sicherlich mit z.B. einer per Ethernet schaltbaren Steckdosenleiste soweit vorbereiten, das man aus der Ferne einfach die kalte Reserve hochfährt, und da hätte man vor dem Urlaub noch dran denken müssen, die "auf Stand" zu bringen, oder man muss aus der Ferne noch das letzte automatisch gezogene Backup wieder einspielen etc. Es verlangt aber in gewisser Weise immer, das man irgendwas aus der Ferne manuell machen muss, und auch einen entsprechenden Zugang nach Hause aufbauen kann, und der nicht von staatlichen Internetfiltern bewusst geblockt wird.
Sicherlich ist die Haussteuerung keine lebenserhaltende Maßnahme, aber wir tun ja alles, damit außenstehenden unsere "Nichtanwesenheit" möglichst nicht auffällt, und wenn die Rolläden für 3 Wochen nicht mehr runterfahren, weil das Ding bei offenen Rollos in die ewigen Jagdgründe eingezogen ist, dann ist das auch ein gewisses Sicherheitsrisiko. Natürlich kann man immer noch die Nachbarn bitten, den Schwager anrufen etc., aber das ist dann nicht mehr "smart", und die will man sich ja für die richtigen GAUs in der Abwesenheit nicht verbrennen.

Und sicherlich gibt es bei sämtlichen Überlegungen zu dem Thema genügend single-Points-of-Failure. Ich fürchte immer, das wahrscheinlich meine gesamte "Rauchmelde"-Geschichte für die Füße ist, weil irgendeine zentrale, nicht-redundante IT-Komponente wie die USV das Feuer auslösen wird, aber wegen dem fehlenden Strom wird es keiner mitbekommen, der nicht im Haus selber vom Rauchmelder geweckt wird.

Der Familienvater

[Dragonfly]

... mit der anderen SN des Funkmoduls verhalten...

Die Frage wäre ja, ob ELV/EQ3 auch ein Funkmodul "clonen" könnte!?

Obwohl alles problemlos schon seit längerer Zeit läuft, wäre dies doch noch eine nette Freizeitbeschäftigung....

[Familienvater]

Hi,

die Funk-Adresse der Zentrale ist ja z.B. in einem Backup enthalten, sonst würden ja das Einspielen/Nutzen von Backups auf anderen Zentralen nicht funktionieren. Nur ob dabei noch irgendwelche Dinge ersetzt werden ist mir nicht bekannt. Die "Seriennummer" des Funkmoduls ist eher ReadOnly im Modul, und nicht einfach änderbar (würde ich mal tippen), wobei es bei YAHM (zumindest früher ohne HmIP-Unterstützung) ja irgendwie die Möglichkeit/Notwendigkeit gab, "irgendeine" Seriennummer der Zentrale vorzugaukeln.

Der Familienvater

[deimos]

Hi,

bei HM classic wird die Seriennummer aus der Config beim Start in das Funkmodul geschrieben, da ist das Klonen also nicht notwendig.
Bei HmIP ist die Seriennummer und der Key fest in der Hardware, aus Sicherheitssicht wäre es aber fatal, wenn eQ-3 die klonen würde, weil dann jeder eine fremde Installation übernehmen könnte, indem er sich ein geklontes Funkmodul liefern lässt. Und bei HmIP ist dieser Key die einzige Sicherheit, einen eigenen Sicherheitsschlüssel kann man ja nicht vergeben.

Aber an sich ist es nicht notwendig einen Klon zu haben, der Wechsel des Funkmoduls klappt problemlos, es dauert im Zweifel nur ein Weilchen.

Viele Grüße
Alex

[Daimler]

Hi,

bei HM classic wird die Seriennummer aus der Config beim Start in das Funkmodul geschriebe

Das kann ich so nicht bestätigen - zum. nicht bei LXCCU und Yahm.
Ich habe hier x Funkmodule im Einsatz und jedes hat eine eindeutige feste SN, welche sich egal auf welchem PI und in welcher Installation niemals ändert.

Und dies hat zur Folge, dass nach einem Restore von einer anderen (Fremd-) Hardware in der Interface Zuordnung halt nicht das gewohnte 'Standard' sondern die SN des Ursprungssystems steht und erst wieder zu 'Standard' wechselt, wenn man über 'Einstellen' das neue bestätigt.

Habe allerdings wimre noch nie versucht, ob die Kommunikation mit der falschen SN funktioniert oder nicht.

P.S.
Ein frohes und gesundes neues Jahr noch allerseits - auf das sich die Wogen im Forum wieder glätten.