Systeme aufteilen oder alles auf einer Maschine?

[Timo_FHEM]

Hallo zusammen,

ich habe für Fhem und MySQL + NAS 2 getrennte Systeme (Raspberry 2 und 3). Ich dachte das wäre sinnvoll, falls mal ein Raspberry nicht laufen sollte, ist nicht gleich alles weg.

Letztens hatte ich einen Stromausfall. Der FI ist raus geflogen. Danach lief der Datenbank Raspi nicht mehr an. Wie ich später rausfand, war das Netzteil defekt.
Das blöde aber war, dass auch Fhem nicht lief, denn der konnte die Datenbank nicht mehr erreichen.
Also in Summe hat das Aufteilen der Services auf verschiedene Rechner nicht wirklich was gebracht.

Wie macht ihr das?
Ist es doch sinnvoller die Datenbank auf derselben Maschine wie Fhem zu hosten?

Danke für eure Meinungen und Erfahrungen.

VG Timo

Gesendet von meinem MI 9 mit Tapatalk

[Wuppi68]

Naja,

ein gewisses Rest Risiko ist immer

FHEM als HA aufzubauen ist nicht so trivial.... gerade wegen den IO Devices. Für solche Fälle sollte es eigentlich ausreichen eine USV zu haben.

Und es ist ja nicht nur das NAS und der/Die Raspie's, es kommen auch noch der Switch & Co dazu.
Wenn man dann die Abhängigkeiten visualisiert hat, überlegt man sich am besten ob man es wirklich braucht Das Material und die Energie sind nicht zu unterschätzen

[mähschaf]

Guten Morgen,

Als Passagier ist das Fliegen mit einem zweimotorigen Kleinflugzeug statistisch gefährlicher als das Fliegen mit einer einmotorigen Maschine. Warum? Das Risiko, dass ein Motor ausfällt, ist doppelt so hoch. Und das Landen mit einem Motor ist schwierig und müsste vom Piloten regelmäßig geübt werden....

Aus meiner Sicht ist ein RPI ein toller Rechner, aber keine wirklich gute Plattform für NAS und DB. Die Performance ist im Bezug auf I/O nicht gut (eigentlich schlecht) und die Hardware (insbesondere SD-Karte) neigt bei vielen Schreibzugriffen zum Ausfall. Anders sieht es natürlich mit angeschlossenen Speichermedien und RAID aus, aber dann kann man auch ein QNAP oder Synology NAS mit DB "on board" und weniger Stress, besseren Netzteilen usw. nehmen.

Ist letztlich alles aber Geschmackssache, finde ich...

[Timo_FHEM]

Performance ist für mich eher zweitrangig. An dem NAS raspi hängen 2 Festplatten im RAID. Der NAS dient eher zur Datensicherung. Ich streame keine Filme darüber. Wobei ich das auch schon mal probiert habe. Geht schon.
Die Datenbank ist für das Fhem logging, da ich die sd Karte nicht so belasten will.

Also deine Empfehlung wäre ein System für alles und dann eher kein raspberry.

Gesendet von meinem MI 9 mit Tapatalk

[mähschaf]

Jein, kommt immer drauf an.

In Deinem Fall würde eine Konsolidierung auf einen Raspberry wahrscheinlich schon eine Verbesserung bringen.
Da Du keine Performanceprobleme hast, kannst Du den zweiten Raspberry einfach liegen lassen und den ersten damit ersetzen, wenn er den Geist aufgibt (cold standby).
Regelmäßige Backups durch z. B. mysql-dumps oder ähnliches solltest Du natürlich trotzdem machen (Also für die configDB, logDB natürlich nicht).

Falls Du ein NAS besitzt oder irgendetwas anderes hoch-(höher-)verfügbares, würde ich die DB dorthin auslagern. Falls nicht, reicht normalerweise auch der Raspberry.
FHEM selber kannst Du unabhängig davon in einem Container auf dem NAS laufen lassen, auf einem Raspberry oder sonstwo. Das hängt immer von Deinen Ansprüchen ab. FHEM ist im Vergleich zur config relativ leicht wiederherzustellen.

Wie schnell soll FHEM wieder online sein? Wie verfügbar muss es sein? Kannst Du damit leben, wenn es mal ein paar Tage nicht funktioniert, weil Du z. B. einen kaputten CUL neu bestellen musst oder ähnliches.
Das hängt also auch davon ab, was Du mit FHEM so vor hast...

Verfügbarkeit kostet Geld und Arbeit, das kannst nur Du für Dich und niemals jemand pauschal für andere beantworten, denke ich.

[DS_Starter]

Das blöde aber war, dass auch Fhem nicht lief, denn der konnte die Datenbank nicht mehr erreichen.

Diesen Zustand kann man einfach mit dem Attribut "asyncMode" im DbLog-Device vermeiden. Dann läuft FHEM weiter bzw. startet auch dann wenn die Datenbank nicht erreichbar ist.
Das gilt im Fall dass die DB für das Logging mit DbLog verwendet wird.

[Timo_FHEM]

Hi, ich habe das kurz überflogen. Im async Modus werden die Daten erstmal im Cache gehalten und später in die DB geschrieben. Das würde das Problem wahrscheinlich lösen.

Nachteil ist, dass der Cache vermutlich auf die sdcard geschrieben wird. Genau das will ich ja mit dem DBLogging verhindern.

Auf den ersten Blick ist das nicht das richtige für mich. Oder ich verstehe es falsch.

VG Timo

Gesendet von meinem MI 9 mit Tapatalk

[DS_Starter]

Nachteil ist, dass der Cache vermutlich auf die sdcard geschrieben wird

Wieso vermutest du das ? Nein, die Daten werden im RAM gecacht. Nachteil ist dabei ein zeitlicher Verzug bevor die Daten in der DB landen. Zeit ist einstellbar. Und bei einem Absturz von FHEM sind die gecachten Daten natürlich weg.
Andererseits werden sie automatisch in die DB geschrieben wenn diese wieder verfügbar wird.

Grüße,
Heiko

[Timo_FHEM]

Ok, dann hab ich das falsch interpretiert.
Ich probiere das mal aus. Danke für den Hinweis.

VG Timo

Gesendet von meinem MI 9 mit Tapatalk