High Availability/Redundanz

Deutsche Foren Konfiguration
#1

Mal in die Runde gerfragt,

welche Redundanz nutzt ihr bei Euch und wie habt ihr das umgesetzt?

Die Heimautomatisierung nimmt einen immer höheren Stellenwert ein. Wir kontrollieren damit unser Licht, Rolladen, Steckdosen, etc. Wenn es mal hakt, ist der Komfort- und Kontrollverlust immens. Vor allem der viel zitierte “WAF” (Woman Acceptance Factor ) leidet massiv bei Ausfällen.

Ich habe mir mit @pmayer’s CC1101 zwei identische Raspberry Pis aufgebaut. Derzeit ist nur einer davon aktiv, jedoch soll das nicht so bleiben.

Meine erste Überlegung geht in Richtung DRBD in Verbindung mit Heartbeat. Hat sich damit schonmal jemand beschäftigt? Welche Verzeichnisse müssen synchron gehalten werden (ausser /var/lib/homegear)? Speichert Homegear die Zustände und Variablen in einer DB (die dann ggfls. bei einem Sync inkonsistent wäre)?

Gruß
Criena

#2

Hmm,

bei mir läuft homegear auf einem Pi2 mit offiziellem Homegear-Image - also readonly. Dort angebunden sind CC1101, EnOcean USB300 und MAX!-Cube als CUL.
Das System läuft seit 1,5 Jahren stabil, geplant ist noch ein nächtliches Backup der db und config.
Als “Automation” nehme ich aktuell noch node-red was auf einem ESX auf einem Raid 10 läuft, aber nicht im HA-Betrieb. Auf dem ESX läuft auch mein LogitechMediaServer wo die Player auch wiederum Pi’s sind, die auch wieder “abschmieren” könnten.

Ich gebe zu, dass mir das stabil genug ist. Das größte Problem für den WAF habe ich eh, wenn ich wieder mal dran rum bastel und irgend etwas nicht funktioniert.
Die größte Frage ist ja, muss/kann man alle Kommunikationsmodule redundant ausführen?

Es wird aber, soweit ich das weiß, in Zukunft eine Lösung für Homegear diesbezüglich geben.

#3

Eine weitere Idee wäre übrigens homegear auf einem ESX mit HA-Betrieb auszuführen und die Abeckung des Funks mit homegear-gateway zu machen und da dann eben mindestens zwei von jedem Funkmodul zu haben. Nicht pro Gateway aber pro Protokoll - also zwei Gateways…

#4

Oder man beschränkt sich bei wichtigen Funktionen auf Homematic und koppelt diese Geräte direkt.
Damit geht im Fehlerfall ein Licht nicht, oder ein Rollo fährt nicht, oder ein Sensor liefert keine Werte.
Wenn die Zentrale nicht läuft, geht halt die zeitliche Automatisierung nicht, aber wie gesagt, die Grundfunktionen sind verfügbar.

#5

Hi,

das sind alles gute Ideen, aber einen ESX wollte ich nicht noch extra aufsetzen. Und mit direkten Links will ich auch nicht arbeiten, das wären ansonsten wirklich nur noch die Grundfunktionen.

Mit DRBD hat noch keiner was umgesetzt? Ich versuche das hier mal auszuprobieren und dann werde ich ja sehen ob es funktioniert oder nicht. Meine größten Bedenken gelten der internen DB von Homegear. Ich weiß nicht ob das immer alles direkt auf die Platte geschrieben wird (super) oder wie bei einem klassischen RDBMS teilweise im Speicher gehalten wird (schlecht, weil DRBD dann nichts davon mitbekommt).

Ich berichte… falls jemand mal was analog aufsetzen möchte.

Gruß
Criena

#6

Die db wird meines Wissens nach nur beim Anlernen/Konfigurationsänderungen benutzt.
Schau dir mal das offizielle Homegear-Image an. Das ist größtenteils read-only und schreibt erst mal ins tmpfs, bevor es in mit einem Interval auf die SD-Karte geschoben wird.

#7

Ich experimentiere aktuell mit Docker Swarm und Gluster zur Datenreplikation. Ich berichte sobald ich den Homegear Docker Container überhaupt mal zum Laufen bekomme :frowning:

1 Like
#8

Ich habe Homegear via apt auf einem RPi3 installiert, dazu das CC1101 Modul von @pmayer. Zusätzlich läuft auf dem “Rechner” Home-Assistant in einem Docker-Container. Jede Nacht wird ein Backup des Filesystems auf eine externe Ablage gemacht.

  • ein zweites USB-Netzteil liegt bereit
  • ein zweiter RaspberryPi liegt bereit
  • ein neues Boot-Medium (USB-Stick) kann aus einem Rasbian Image, dem Homegear DEB und den Backup-Dateien wieder hergestellt werden

Viel wichtiger aber:

  • alle Aktoren sind zugänglich via Wandtaster oder Hutschiene im Sicherungskasten, so daß eine Bedienung auch gänzlich ohne Automatisierung möglich ist.

Das stellt das für meinen Einsatzzweck sinnvolle Level an Redundanz dar.

1 Like
#9

Danke für die vielen Rückmeldungen! Bisher ist der Glusterfs-Ansatz von @tringler dem was ich erreichen will am nächsten. Ich bin gespannt wie das läuft.

#10

Dazu müsstest du auch noch einen keepalived als Loadbalancer davorhängen, damit du eine VIP ansprechen kannst.

1 Like
#11

Das würde ich über Heartbeat realisieren. Eine virtuelle IP die vom Primary genutzt wird. Wenn der Secondary feststellt, dass der Primary ausgefallen ist, gibt er sich diese virtuelle IP und startet anschließend Homegear.

#12

In meiner Konfiguration würde das das Swarm Cluster übernehmen lassen. Wenn der Healthcheck auf einem System fehlschlägt wird der Container automatisch zum nächsten HomeGear-fähigen Host gemoved. Der keepalived Daemon dient leidlgich dazu, dass überhaupt eine VIP verfügbar ist.

Ich würde die ganze Clustering/Loadbalancing Logik im Docker Swarm halten.

Egal wie man sich die das ganze aufbaut ist nur interessant wie man denn einen Helathcheck für HomeGear gestaltet. Hast du dir da Gedanken gemacht? Oftmals ist das System ja erreichbar und der Daemon läuft, aber er arbeitet einfach nicht richtig.

1 Like
#13

Hi @tringler,

danke für das Feedback.

Homegear läuft bei mir noch nicht so lange, vorher war FHEM im Einsatz. Über die letzten Jahre hatte ich aber weder mit dem einen noch dem anderen System Ausfälle in der Form, dass das OS noch lief, der FHEM/Homegear-Dameon aber abgeraucht war. Insofern wollte ich mich auf den Fall eigentlich nicht vorbereiten. Falls ich mal in solche Situationen laufen sollte, würde ich mich eher fragen ob Homegear wirklich die richtige Wahl oder schlicht zu instabil ist.

Die RPis haben hardwareseitig einen Watchdog-Mechanismus, der sicherstellt, dass im Falle eines OS-Hängers der Rechner neu gestartet wird (bisher auch noch nie eingetreten).
Mein primäres System wird per PoE mit Strom versorgt, sodass die Wahrscheinlichkeit, dass Homegear dort noch aktiv ist obwohl der Secondary ihn nicht mehr erreichen kann, sehr gering ist (wenn das Netz tot ist, bekommt das Primärsystem auch keinen Strom mehr).

Die Redundanz soll in erster Linie Hardwarefehler abfangen. Ich weiß nicht wie zuverlässig die RPis im Dauerbetrieb wirklich laufen bzw. ob die SD-Karte nicht doch (wie früher) nach einigen Monaten den Geist aufgibt.

Und last, but not least, habe ich bisher noch kein Projekt mit DRBD und Heartbeat umgesetzt. Das will ich mal austesten. Es ist nicht so fancy with Docker Swarm und Konsorten, aber im privaten Umfeld ist mir ein simples Setup, das ich von Grund auf verstehe lieber.

Gruß
Criena

#14

Wenn Du nur das adressieren möchtest: Rasperry Pi3 können auch von USB booten, SD Karte braucht man nicht mehr, der RPi3 braucht dafür eine einmalige Vorbereitung, der 3B+ kann’s ab Werk.

1 Like
#15

Gut zu wissen, das war mir neu. Das deckt dann aber noch nicht den letzten Punkt ab. :wink:

Die Heimautomatisierung ist meist ja irgendwie doch noch ein Bastelprojekt, etwas zum Ausprobieren und Lernen.

#16

Ich will Dir den Spass ja auch nicht nehmen, hab selbst schonmal einen Docker-Swarm mit GlusterFS auf 3 RaspberryPi Zero W aufgebaut, weil aktuelles Kubernetes auf 32 Bit Architekturen nicht mehr unterstützt wird.

Die Herausforderung ist die Verhältnismässigkeit. Wenn Du eine HA Lösung aus 2 Raspberries haben möchtest, musst Du noch einen Dritten auf Lager haben, weil ohne Not fällt so ein RPi ja auch nicht aus. Der ist dann in der Regel dauerhaft kaputt.

1 Like
#17

Ein Docker Swarm macht doch eh erst ab 3 Manager Nodes Sinn oder nicht?
Bei mir ist das aktuell:
3x RPi 3 und 1x RPiZ wobei der Zero nur als Manager arbeitet. (4x Worker, 3x Manager)

#18

Wir driften ab …

1 Like
#19

Ja, aber die Datenbank wird bei einem service homegear reload gesichert. Die neueste Sicherung kann dann einfach z. B. per SCP kopiert werden (sie ist ja nicht groß). DRBD ist also gar nicht erforderlich. Bei gleicher Konfiguration, ist die Datenbank auch das einzige, was kopiert werden muss.

Auch Softwarefehler sollten abgefangen werden. Bei guter Hardware würde ich sogar sagen, sind diese häufiger das Problem (z. B. fehlgeschlagene Aktualisierungen).

Viele Grüße

Sathya

1 Like