fyi: Hochverfügbarkeit für fhem auf Linux

Prof. Dr. Peter Henning · 18 November 2014, 21:45:40

Ach, du entscheidest, was hier etwas zu suchen hat ?

Habe mich immer schon gefragt, wer das ist.

pah

betateilchen · 18 November 2014, 22:37:59

ich geh mal Popcorn holen, das wird hier bestimmt noch lustig

Zephyr · 18 November 2014, 22:56:40

Die Macher des Benzinpreismonitors, des Abfallkalenders und sogar des TV-Programmes in FHEM können ja gerne ihre Themen verfolgen, aber ich zitiere pah mal:

Zitat von: Prof. Dr. Peter Henning am 18 November 2014, 21:38:45
Allerdings ändere ich auch nicht meine Meinung, dass dies unsinnig ist.

Offensichtlich gibt es unterschiedliche Ansichten darüber, was sinnvoll und nicht sinnvoll ist.

Hollo · 18 November 2014, 22:56:48

Zitat von: Zephyr am 18 November 2014, 21:40:59
Weil es in einer Heimautomation nichts zu suchen hat, tonnenweise Websites dazu existieren und die alle möglichen Möglichkeiten der Nutzerinformation bieten.

Das Thema an sich sicher nicht unbedingt, aber die Einbindung in FHEM zur Information (z.B. morgens vor der Fahrt zur Arbeit auf dem RSS-Tablet) finde ich wiederum sehr interessant.
Das ist aber bei vielen Punkten so; ich denke bei den meisten stehen Spieltrieb und Komfortgewinn deutlich vor evtl. Energieeinsparung.

Aber zurück zum eigentlichen Thema:
Wenn es um die reine Systemverfügbarkeit/-stabilität geht, ist natürlich auch generell die Frage der eingesetzten Hardware "in den Raum zu werfen"...
wie wäre es dann mit einer "Industrie-Platform inkl. entsprechender Peripherie" für 24/7-Einsatz anstatt Experimentier-Board mit SD-Card und 4 Euro Billig-Netzteil?

Zephyr · 18 November 2014, 23:05:12

Zitat von: Hollo am 18 November 2014, 22:56:48
Wenn es um die reine Systemverfügbarkeit/-stabilität geht, ist natürlich auch generell die Frage der eingesetzten Hardware "in den Raum zu werfen"...
wie wäre es dann mit einer "Industrie-Platform inkl. entsprechender Peripherie" für 24/7-Einsatz anstatt Experimentier-Board mit SD-Card und 4 Euro Billig-Netzteil?

Man könnte natürlich FHEM auch auf einem 19" Server laufen lassen. Ich schätze aber, dass das ein bisschen viel Strom verbraucht und laut ist. Gebraucht bekommt man die inzwischen auch für ein bisschen mehr als ein Cubietruck kostet.
Wäre interessant zu sehen, ob Pacemaker auf einem ARM-Board tatsächlich läuft. Habe noch nicht geschaut, ob die entsprechenden Pakete zum Beispiel von Debian angeboten werden.
edit: Japp, gibt's: https://packages.debian.org/stable/pacemaker
OpenAIS ist auch verfügbar: https://packages.debian.org/stable/openais

Also vorausgesetzt, man möchte das auf einem der üblichen ARM-Boards aufbauen.

chris1284 · 19 November 2014, 06:54:12

19" Server sagt erstmal 0 über den Stromverbrauch, die Zuverlässigkeit und die Leistung.

19" gibt den Formfaktor des Gehäuses an und sagt erstmal nur dass das Gehäuse in einen dafür vorgeshehenen 19" Schrank passt. Es gibt zb .: 19" Raspberry Pi Gehäuse / Mounting Kits. Und wenn du ihn so verbaust ( in einem 19" Schrank) wird er nicht mehr Strom verbrauchen.

wkarl · 19 November 2014, 07:40:12

Hallo in die Runde,

hier noch meine '2 cents' dazu.

Hochverfügbarkeit eines Systems erstreckt sich nicht nur darauf Services zu überwachen und bei Fehler neu zu starten. Sie adressiert auch Fehler der Hardware und des Betriebssystems und alles was im einzelnen noch zu betrachten ist.
Meine Intention warum ich das Thema näher untersucht habe - auch ich habe die relevanten Service mit Restart-Mechanismen abgesichert. Jetzt bin ich beruflich viel und auch mehrere Tage in Europa unterwegs und da ist mein fhem-System nicht auf Service-Ebene sondern auf Plattform-Ebene (HW, OS) ausgefallen. Keine Chance per remote-Zugriff dies zu korrigieren. Meine drei Mädchen belächeln mein Projekt zwar immer, wenn aber gewohnte Automatismen nicht mehr da sind wird halt auch gemault. Der ein oder andere kann sich vorstellen was ich mir am Telefon anhören musste
Sinnhaftigkeit - bei solchen (privaten) Projekten stelle ich immer die Frage 'wie einfach und schnell ist dies umzusetzen?'. Auf der Suche nach einer Lösung stieß ich dann auf die LCMC Seite. Zumindest das Video verspricht, dass HA einfach und schnell umzusetzen ist. Was in der Praxis noch zu beweisen ist. Dazu komme ich erst über den Weihnachtsurlaub. Ach ja, die Hardware mir doppelt anzulegen ist sowieso mein Plan.
Warum habe ich diese Information hier geteilt? An andere Stelle hier im Forum wurde das Thema HA auch schon andiskutiert, da der ein oder andere fhem höher in die hauseigenen Systeme (Heizung, etc) integriert hat und ein Ausfall gravierendere Auswirkungen hat als das Nichtschalten von Deko-Lichtern.

ciao walter

Hollo · 19 November 2014, 09:45:44

Zitat von: wkarl am 19 November 2014, 07:40:12
...
Meine Intention warum ich das Thema näher untersucht habe - auch ich habe die relevanten Service mit Restart-Mechanismen abgesichert. Jetzt bin ich beruflich viel und auch mehrere Tage in Europa unterwegs und da ist mein fhem-System nicht auf Service-Ebene sondern auf Plattform-Ebene (HW, OS) ausgefallen. Keine Chance per remote-Zugriff dies zu korrigieren. Meine drei Mädchen belächeln mein Projekt zwar immer, wenn aber gewohnte Automatismen nicht mehr da sind wird halt auch gemault. Der ein oder andere kann sich vorstellen was ich mir am Telefon anhören musste
Sinnhaftigkeit - bei solchen (privaten) Projekten stelle ich immer die Frage 'wie einfach und schnell ist dies umzusetzen?'. Auf der Suche nach einer Lösung stieß ich dann auf die LCMC Seite. Zumindest das Video verspricht, dass HA einfach und schnell umzusetzen ist. Was in der Praxis noch zu beweisen ist. Dazu komme ich erst über den Weihnachtsurlaub. Ach ja, die Hardware mir doppelt anzulegen ist sowieso mein Plan.
...

Ich habe auch letztens im Ausland gesessen, während die Thermostaten wilde Temperaturen einstellten und das Bad auf 28,5 heizen wollten.
Wenn man nicht ständig vor Ort ist und das System auch längere Zeit autark funktionieren soll, muss man sich da schon mal Gedanken machen.
Dann ist Hardware, Monitoring etc. ein Thema; deshalb auch der Hinweis zur Auswahl der verwendeten Komponenten.
Hier muss man dann Kosten, Nutzen, Zeitaufwand etc. abwägen.

Beispiel:
Ich habe meinen Heimserver 2x mit relativ identischer Hardware (Linux ist da nicht so pingelig).
Im Normalbetrieb fungiert 1 als Server, 2 als Backupsystem. System- und Mediaplatte sind von der Größe her identisch und wurden zunächst 1:1 geclont.
Das Backupsystem wird vom Server regelmäßig gestartet (WOL) und bootet dann ein Minimal-Linux von CF-Karte; anschliessend werden die beiden Platten mittels rsync auf den "Serverdatenstand" aktualisiert und das Backupsystem wieder runtergefahren.
Geht im Server eine Platte kaputt, nehme ich die aus dem Backupsystem und stecke sie in den Server.
Geht im Server z.B. das Mainboard kaputt, boote ich das Backupsystem von der Systemplatte statt von CF und habe meinen Server wieder 1:1 am Laufen.
Einmaliger Planungs- und Umsetzungsaufwand, seitdem läuft alles automatsich; und der Server ist noch nie ausgefallen.
Verwendete Mainboards sind Industrieware, der Server macht noch diverse andere Dinge und verbrät ca. 20W und hat eine kleine USV.

Ach ja, es ist in einem 19" Schrank untergebracht.

Insofern kann ich sowohl Deinen Thread als auch den Hintergrund verstehen. Probier das einfach mal über Weihnachten aus und berichte hier.

Zephyr · 19 November 2014, 10:19:31

Zitat von: chris1284 am 19 November 2014, 06:54:12
19" Server sagt erstmal 0 über den Stromverbrauch, die Zuverlässigkeit und die Leistung.
19" gibt den Formfaktor des Gehäuses an und sagt erstmal nur dass das Gehäuse in einen dafür vorgeshehenen 19" Schrank passt. Es gibt zb .: 19" Raspberry Pi Gehäuse / Mounting Kits. Und wenn du ihn so verbaust ( in einem 19" Schrank) wird er nicht mehr Strom verbrauchen.

Wenn Hollo von Industrie-Plattform für 24/7-Verfügbarkeit spricht, ich mit einem 19" Server und seinem Stromverbrauch argumentiere, werden wir wohl kaum 19"-Gehäuse für RPis, Mac mini oder sonstigen Bastelkram gemeint haben.

Prof. Dr. Peter Henning · 19 November 2014, 10:47:38

Nun, dann schlage ich doch mal vor: Schreib nächstens das, was Du meinst - und versuch nicht, den Energiebedarf in Zoll auszudrücken.

LG

pah

Doggiebert · 19 November 2014, 11:15:29

eieiei - mit etwas common sense und unter Einbeziehung des Kontexts schaffen es die meisten hier schon, den Passus 19" Server so zu verstehen, wie er gemeint war. Hier ist manchmal schon etwas Kindergarten. Ich glaub' ich nehm auch eine Handvoll Popcorn

---
Disclaimer: dieser Beitrag wurde nicht korrekturgelesen, ich bitte daher, syntaktische und semantische Fehler oder ungenaue Formulierungen zu entschuldigen...

Joachim · 19 November 2014, 13:16:22

Bitteschööön

Deudi · 19 November 2014, 13:50:59

Nichtsdestrotrotz

Zephyr · 19 November 2014, 18:28:31

Zitat von: Prof. Dr. Peter Henning am 19 November 2014, 10:47:38
Nun, dann schlage ich doch mal vor: Schreib nächstens das, was Du meinst - und versuch nicht, den Energiebedarf in Zoll auszudrücken.

Nun, dann schlage ich doch mal vor: Lass beim nächsten Mal einfach etwas Interpretationsspielraum walten. Und versuch nicht, den Kenntnisstand oder die Erfahrungswelt von Dir bei anderen vorauszusetzen.
Ich finde, das kann man schon ganz gut daran sehen, wie viele Postings du oder ich haben.
Und nach wie vor weiß ich nicht wie die Dinger in 19" Gehäusen mit redundanten Lüftern, Festplatten und Netzteilen heißen. Sondern werde lediglich darauf hingewiesen, den falschen Begriff benutzt zu haben.

forum-merlin · 05 April 2015, 10:37:42

Hallo @ All,

Ich habe diesen Thread gelesen, und möchte an dieser Stelle mal NEU starten ohne einen neuen Thread zu eröffnen.
Ich habe nicht vor auf Begrifflichkeiten und einen unschönen Ton einzusteigen. Das nervt nämlich.

Ich suche nach Vorschlägen für folgende Situation:

Ich habe bereits:
- einen HP Microserver mit ESXi für virtuelle Maschinen
- einen RasPi auf dem FHEM derzeit "produktiv" läuft
- einen weiteren RasPi auf dem ich verschiedenste Dinge teste (ich switche die SD Karten und teste FHEM, SDR und Co.)
- und noch einen RasPi, den ich für unten aufgeführtes Szenario verwenden wollte.

Was ist das Ziel?
Mein produktiver RasPi B nicht B+ und nicht RasPi2 ist beim Plotten ziemlich langsam. Auch reagiert manchmal die Weboberfläche nicht mehr so wirklich und braucht ewig bis sie wieder zurück ist.
Zumindest wenn man einen nervösen Mausfinger hat und ungeduldig umherklickt.
Daher würde ich FHEM gerne sozusagen als ACTIVE/ACTIVE Cluster bzw. Loadbalancer bzw. redundates System laufen lassen. (Sucht Euch aus welcher Bergiff Euch am besten passt)

Warum das ganze...
Der ESX läuft zwar immer, aber braucht auch viel Zeit bis alle VMs hochgefahren sind wenn die Kiste mal aus war.
An der Reihenfolge der Startups möchte ich aber nichts ändern. Dependencies!

Wenn jetzt beispielsweise ein Stromausfall war, soll eine FHEM Instanz sofort erreichbar sein um beispielsweise das Licht zu schalten, oder was auch immer.
Ich möchte nicht 20 Minuten warten müssen.

Die Plotts allerdings und die generelle Performance von FHEM sollen eigentlich primär von der als VM gehosteten FHEM instanz kommen.

Idee wäre jetzt ein FHEM auf dem RasPi Nr.1 laufen zu lassen, dazu eine Instanz auf einem VM Image, und ein weiterer RasPi der meine ganzen USB Stick Sender/Empfänger dran hat per FHEM2FHEM

Das Ganze klingt aber auch a bissal strange.

Habt ihr kontruktive Vorschläge?

Neue Hardware wie einen Intel NUC oder was weiss ich was kommt nicht in Frage.

Wie würdet Ihr das machen?
Shared Disk auf einem NAS wo sich beide Instanzen die config ziehen, und die Logs hinschreiben?

Danke Euch!

Gruß

der Merlin