redundanter Pi

Begonnen von Tuppertasse, 14 November 2014, 08:08:36

Vorheriges Thema - Nächstes Thema

Tuppertasse

Hallo liebe Gemeinde,
ich habe eine Frage und vorher auch schon gesucht aber bin nicht fündig geworden; mag auch sein dass ich die falschen Suchbegriffe benutzt habe daher hier nun meine Frage:

Was meint ihr oder gibt es schon User, die mindestens zwei Raspberry Pi's parallel laufen haben und zwar in dem Sinne, daß wenn ein Pi den Geist aufgibt (warum auch immer), dass automatisch der zweite Pi "aktiviert" wird und die Aufgaben übernimmt.
Rudimentär z.B. pingt der zweite Pi den ersten laufenen Pi und wenn der Ping nicht mehr erfolgreich ist, dann übernimmt der zweite Pi die Aufgabe des ersten. Das ist mal die Idee oder habt ihr andere Vorschläge ?

Ich betone nochmal, daß diese nicht gleichzeitig laufen sollen.
Außerdem befinden sich die Logfiles zentral auf einem Nas, sowie jeden Tag wird ein komplettes Backup auf dem Nas hinterlegt.

Abschliessende Frage:
Sollte ich den "neuen" BananaPi als zweiten Pi nehmen oder vertragen sich die nicht ?

Vielen Dank schonmal vorab !

Phill

Hi,

welche Peripheriegeräte hängen denn alle an deinem PI? Ich glaube das Umschalten von diesen evtl. USB-Devices wird das größte Problem geben.

Aber im Grunde habe ich das auch so vor. Allerdings noch keine Grundlagenforschung betrieben.

[klugscheiss]Übrigens... wenn du einen RaspberryPi und einen BananaPi zusammenschaltest nennt man das dann Diversitär-Redundant...  :D

Gruß
Homebrew 1-Wire / HomeMatic Mix - Cubietruck mit FHEM als Server - Raspberry PI 3 als Informationsanzeige im MagicMirror Stil - Raspberry Pi 1 als Klingelanlage - VDR

Mein Modul: Talk2Fhem - Mein Tipp: https://forum.fhem.de/index.php/topic,82442.0.html

Tuppertasse

Harhar

@Phill:
Ich hab gar nix mehr an meinem USB Port hängen, da ich mittlerweile auch von Wlan auf LAN umgestiegen bin.
Aber ich möchte nicht ausschliessen, dass mal ein USB STick dran kommen kann zukünftig (noch wüsste ich nicht warum aber wenn redundant dann sollte das auch mitbeachtet werden).
Bin weiterhin auf Vorschläge gespannt.

hexenmeister

#3
Das kommt sehr darauf an, welchen Grad der Verfügbarkeit du brauchst bzw. haben willst.
Zweiter Rechner und dann noch Hot Standby... das ist schon sehr hoch.
Ich würde folgende Stufen sehen:

1. Absicherung FHEM: ich habe einen Watchdog-Script, der FHEM überwacht und ggf. hängenden Prozesses killt / fehlenden neustartet.
2. Betriebssystem: Da bietet sich interner Hardware-Watchdog an.
3. Rechner-Hardware: Absicherung durch einen zweiten Rechner und externen Hardware-Watchdog. Z.B. auf Arduino-Basis. Prüfung, ob der Hauptrechner noch "lebt" kann per USB-Verbindung erfolgen. Und dann einfach per Relay schalten.
(Mir persönlich reichen Stufen 1 und 2.)

Parallel dazu sollte man dann auch ggf. über eine USV nachdenken.
(Ich habe auch einen Akku, der den Cubietruck, 1wire-Busse und Funk-Empfänger noch ca. 2 Stunden versorgen kann.)

Zusätzlich kann man auch Peripherie-Hardware absichern.
(So habe ich z.B. zwei HomeMatic-Transmitter (parallel / voll automatisch mit VCCU) und einen dritten 1wire-Controller auf der Hutschiene stecken (Cold-Standby).)

Grüße,

Alexander

Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Rince

ZitatParallel dazu sollte man dann auch ggf. über eine USV nachdenken.
(Ich auch einen Akku, der den Cubietruck, 1wire-Busse und Funk-Empfänger noch ca. 2 Stunden versorgen kann.)

Zusätzlich kann man auch Peripherie-Hardware absichern.
(So habe ich z.B. zwei HomeMatic-Transmittern (parallel / voll automatisch mit mit VCCU) und einen dritten 1wire-Controller auf der Hutschiene stecken (Cold-Standby).)

Tuppertasse, wichtig bei der USV Überlegeung:
Hänge nicht deine zwei Rechner an die selbe USV! Single Point of Failure...
Wer zu meinen Posts eine Frage schreibt und auf eine Antwort wartet, ist hiermit herzlich eingeladen mich per PN darauf aufmerksam zu machen. (Bitte mit Link zum betreffenden Thread)

Tuppertasse

Danke hexenmeister, dass hat schon sehr interessante Punkte, die ich gerne aufnehme:

Punkt 1 & 2 ist schon sehr gut! Ist notiert wobei ich sehr verlegen bin um die Watchdogs wie man das aufsetzt!

Ich brauche schon Punkt 3 als Sicherheit da ich über Homematic Komponenten meine teichpumpe / Teichsystem steuere und "überwache".
Also bräuchte ich einen dritten Pi (oder diesen Arduino ? was ist das?) oder kann ich das über meinen NAS laufen lassen?

USV hab ich auch schon drüber nachgedacht!

@Rince:
OK danke notiert !

hexenmeister

Hardware-Watchdog-Anleitung: http://forum.fhem.de/index.php/topic,20553.msg140813.html#msg140813
Wenn man damit FHEM überwacht, dann ersetzt das die Stufe 1 auch mit. Allerdings ist mir so ein Eingrief zu schwerwiegend, da auf der Machine auch andere Dienste laufen und immer gleich einen kompletten Restart...
Meine Lösung für Stufe 1 habe ich hier kurz beschrieben: http://s6z.de/cms/index.php/homeautomation/fhem/23-fhem-watchdog

Vor allem bei Hardware-Watchdog: gut überlegen und alles testen bevor richtig scharf geschaltet wird. Ansonsten erzeugt man sehr schnell eine Reset-Schleife, aus der man nicht mehr rauskommt.


Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

betateilchen

Grundsätzlich sind RaspberryPi, Beaglebone, Cubie und wie sie alle heißen, keine Plattformen, für die ich jemals den Aufwand eines redundaten Betriebes einrichten würden. Diese Einplatinencomputer sind ALLE als Entwicklungsplattformen entstanden und werden auch als solche verkauft. Es sind für mich definitiv keine Plattformen, von denen ich eine Hochverfügbarkeit jemals abverlangen würde. Und eine ungeeignete Plattform wird auch dadurch nicht besser, dass man eine zweite identisch ungeeignete Plattform danebenstellt.

Einen Watchdog einzurichten ist durchaus ok, das ist eine gute Basis für eine möglichst zuverlässige Betriebsbereitschaft. An einem Beispiel verdeutlicht: als ich meine erste unbeaufsichtigt laufende, fhem-basierte Wetterstation in Serbien installiert habe, hatte ich auf dem Raspberry noch keinen Watchdog eingerichtet. Wenn dann irgendwas schieflief, war die Station ausser Betrieb, bis ich das nächste Mal vor Ort bin (nur zweimal pro Jahr). Inzwischen läuft der Watchdog und die Station läuft nun durch, da sie bei einer Störung automatisch neu gestartet wird.  Nachdem diese Station nun über 6 Wochen störungsfrei durchlief, hat der watchdog - aus welchen Gründen auch immer - vor ziemlich genau einer Stunde neu gestartet. Ausser in der Anzeige der uptime im generierten RSS fällt ein solcher Ausfall (der Watchdog reagiert nach 15 Minuten) überhaupt nicht mehr auf.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

hexenmeister

#8
Zitat von: Tuppertasse am 14 November 2014, 09:11:36

Also bräuchte ich einen dritten Pi (oder diesen Arduino ? was ist das?) oder kann ich das über meinen NAS laufen lassen?

Ne, Raspi ist dafür nicht geeignet. Grundsätzlich gebe ich betateilchen recht, wenns dennoch sein muss, dann nimm einen Arduino. Das ist ein kleiner billiger Rechner,  oder eher ein microcontroller. Kein Betriebssystem, dafür sparsam und relativ stabil (so,  wie du ihn eben programmierst). Ein (einfaches) Überwachungsprogramm wirst du jedoch wohl selbst schreiben müssen.

Btw. Arduino hat auch einen Hardware-Watchdog ;D
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Dr. Boris Neubert

Hallo,

ich habe einen Raspberry Pi, Betriebssytem auf Logical Volume. Jede Nacht wird ein Snapshot gesichert. Ein Raspberry im Cold Standby (OVP :-)

Nach dem Überspannungsschaden im Sommer musste ich nur den Rechner austauschen, um FHEM wiederzubeleben, da die SD-Karte noch heil war. Daraufhin ging die SlowRF-Infrastruktur wieder zu bedienen.  Downtime <1 h.

Die kaputte Peripherie ist bis heute nicht vollständig ersetzt.

Fazit: man muss sich alle möglichen Schadenszenarien ansehen und dann überlegen, gegen welche Risiken Hot Standby wirkt und gegen welche nicht.

Viele Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

hexenmeister

Oh, ja, wenn man so ein Grad ver Verfügbarkeit wirklich haben will, dann sind in jedem Fall Maßnahmen gegen die Überspannung zu treffen. Und man muss sich eingestehen, dass gegen einen sehr nahen (oder gar direkten) Blitzschlag kein Kraut gewachsen ist (odes was macht man gegen 50MV bei 20KA?).

Für die Netzspannung habe ich schon Groß und Mittelschutz installieren lassen, auch Feinschutz für die FHEM-Hardware ist vorhanden. Was mir noch fehlt, ist der Schutz für Telefon- und 1wire Leitungen.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Tuppertasse

Guten Morgen liebe Gemeinde :-)

Erst einmal vielen Dank für die zahlreichen Antworten und Gedankenanstoesse. Ich weiss dass es immer wieder ein recht kontrovers geführtes Thema ist, hier ein Hot-Standby System aufzusetzen mitteles zB eines Pi's.
Dass muss letzten EEndes jeder für sich entscheiden und ich habe Verständnis für Meinungen die dafür oder dagegen sind.

Auf jeden Fall habe ich wieder ein paar Anregungen bekommen was man machen kann und was evtl. nicht.....Ich werde mir das System jetzt mal die Tage aufmalen und dann entscheiden, wie es weitergeht :-) Auf jeden Fall schonmal vielen Dank an Alle