Hallo,
fhem hochverfügbar aufzubauen habe ich mir über das Jahresende vorgenommen. Für die Vorbereitung habe ich heute angefangen zu recherchieren, was sich denn so für Möglichkeiten anbieten. Dabei bin ich auf die Lösung Linux Cluster Management Console (http://lcmc.sourceforge.net/ (http://lcmc.sourceforge.net/)) gestossen.
Diese Information wollte ich Euch nicht vorenthalten, da an andere Stelle dies erst kürzlich andiskutiert wurde.
ciao walter
Zitat von: wkarl am 15 November 2014, 20:51:17
fhem hochverfügbar aufzubauen habe ich mir über das Jahresende vorgenommen
definiere in diesem Zusammenhang bitte "hochverfügbar"
Werde meine HW doppeln und als Hot-Standby aufbauen.
ciao walter
Das hat mit Hochverfügbarkeit nix zu tun.
Und meine Frage ist auch noch nicht beantwortet.
Nun, da haben Wiki und ich ungefähr dasselbe Verständnis:
ZitatHochverfügbarkeit (englisch high availability, HA) bezeichnet die Fähigkeit eines Systems, trotz Ausfalls einer seiner Komponenten mit einer hohen Wahrscheinlichkeit (oft 99,99 % oder besser) den Betrieb zu gewährleisten.
Gut, die 99,99% sehe ich für meine fhem Lösung etwas übertrieben ;-)
Für eine gemeinsame Verständnisbasis - wie ist Deine Definition, bzw kannst Du dem obigen folgen?
Danke und ciao
walter
Naja, die Frage ist eher, was Du in dem Zusammenhang als "System" bezeichnest!?
Die Verdoppelung der Hardware (mit identischer Softwarekonfiguration?) ändert erstmal nichts an der Stabilität/Verfügbarkeit von fhem. Das würde ich eher unter Redundanz sehen.
Wie oft ist denn bisher etwas an Deiner Hardware ausgefallen?
Linux an sich ist ja nun auch nicht als "Absturzkritisch" verschrien. Mein Server läuft so lange durch bis ich ihn mal wegen einem Hardwareumbau neustarten muss. :D
Um die Verfügbarkeit von fhem zu erhöhen, sehe ich eher andere Punkte:
- aktuelles 5.6 stable ordentlich konfigurieren
- saubere config(s)
- Updates nur bei Bedarf (neue Funktionen) machen
- minütlicher watchdog ob fhem prozesse noch korrekt laufen
- ...
Hallo Hollo,
die Intention meines ersten threads war mit Leuten, die ähnliches planen auf LMCM hinzuweisen. Einfach den Inhalt der Web-Seite ansehen, dann macht die Doppelung auch irgendwie Sinn.
Sieh Dir das Video an und Du findest Antworten zu
Zitat- aktuelles 5.6 stable ordentlich konfigurieren
- saubere config(s)
- Updates nur bei Bedarf (neue Funktionen) machen
- minütlicher watchdog ob fhem prozesse noch korrekt laufen
- ...
Wie gesagt ich wollte nur die Information teilen und einigen Leuten die Zeit des Suchens verkürzen.
ciao walter
Halte ich für reichlich überflüssig. Ein ordentlich konfigurierter Watchdog auf dem Raspberry oder einem Cubie ist da viel einfacher.
LG
pah
P.S.: Wikipedia ist keine seriöse Quelle
ich sehe das Problem hier ehr darin 2 Systme zu 24/7 am Laufen zu haben. Das 2. idled noch nicht einmal da es sich ständig mit 1. syncen muss (fhem, ggf db-log, usw).
Dann ist noch der Punkt das ein 2.er Server im Hot-Standby nichts bringt solange du keine Möglichkeit findest deine RFXtrx433 und CUL868 automatisiert an den 2. Server zu binden (evtl. per Software steuerbarer Usb-Switch??). Wenn du das dann noch per Hand machen musst kannste auf den ganzen Einrichtungsaufwand und den höheren Stromverbrauch durch 2 laufende Server eh verzichten und den 2. Server per Hand einschalten und alles umstecken. Die Konfig ändert sich ja nicht so oft die kann man + Logs egal in welcher Form auch regelmäßig per Hand / Job sichern und wieder einspielen.
Des Weiteren bräuchtest du ja 2 Server, 2 CUL, 2 RFXtrx, 2 HMLAN. Rechnest du 99 % auf 365 Tage sind das Ausfallzeiten von 3,65 Tagen.... in der Zeit hat der Shop deines Vertrauens auch die nue Hardware geliefert.
Dann werfe ich noch den Begriff Stromausfall in den Raum. Keine Hocverfügbarkeit 2er Server ohne 2 USV
Man kann die Verfügbarkeit drastisch erhöhen indem man sich ein 2tes System beschafft und auf diesem neue Funktionen und Änderungen erstmal ausgiebig testet und dann erst in den Echtbetrieb übernimmt wenn es sich wirklich bewährt hat.
Ach ?
Ich finde die Idee zumindest bemerkenswert. Ein bisschen mit Computern zu basteln hat noch nie geschadet.
Bemerkenswert finde ich auch, dass dem OP so viel Gegenwind entgegenschlägt.
Beim Benzinpreismonitor und beim TV-Programm in FHEM oder der Einbindung des aktuellen Abfallkalenders passiert das nicht in dem Ausmaß. Vermutlich liegt es einfach daran, dass eben genannte Themen deutlich mehr User direkt anspricht, weil sie einen unmittelbaren Nutzen davon haben.
Aber nur weil die meisten User keinen unmittelbaren Nutzen von einer Sache haben, ist es ja nicht gleich unnötig.
... meint....
Zephyr
Zitat von: magersuppe am 18 November 2014, 09:56:43
Man kann die Verfügbarkeit drastisch erhöhen indem man sich ein 2tes System beschafft und auf diesem neue Funktionen und Änderungen erstmal ausgiebig testet und dann erst in den Echtbetrieb übernimmt wenn es sich wirklich bewährt hat.
...ein 2. System zum Testen, so so
Das ist nicht wirklich ein Ansatz für Hochverfügbarkeit denn wenn ich auf dem System was jede Sekunde zum Einsatz kommen könnte und dann sofort funktionieren muss spiele und teste. Im Ernstfall ist es dann sicher verfriemelt, kaputt oder gerade anderst wie eingesetzt.
zu dem gehts laut Titel nicht stumpf um ein 2 System sonder Hochverfügbarkeit mit angesprochenem Hot-Standby was 1:1 alle Aufgaben wie das Hauptsystem übernehmen kann.
@Zephyr: gegenwind sehe ich keinen, sondern konstruktiuve Kritik die z.B: Wege aufzeigt das System an sich stabil und zuverlässig zu bekommen. es bringt dir kein 2., 3. oder 4. System was wenn die zu 99%NICHT laufen ;)
Der Einsatz des Benzinpreismonitor 's kostet übrigens nichts in der Anschaffung und hilft evtlKosten zu sparen. Warum sollte man das auch kritisieren?
Ich sehe keinen Gegenwind, der Urheber dieses Threads kann gerne ein Hot Swap System aufbauen.
Allerdings ändere ich auch nicht meine Meinung, dass dies unsinnig ist.
Wenn mein FHEM abstürzt, oder der Cubie abstürzt, bin ich innerhalb von wenigen Sekunden dank des Watchdogs wieder da.
Wenn der Netzstrom weg ist, sind die meisten meiner Sensoren ebenfalls weg - und es nutzt mir auch wenig festzustellen, dass die Heizung immer kälter wird. Auch warum ich funkgesteuert das Licht einschalten sollte, wenn kein Strom da ist, ist mir nicht einsichtig. Allenfalls wäre es noch sinnvoll, die Alarmfunktionalität aufrecht zu erhalten. Dann aber wäre eine USV meine Wahl.
Und die Idee, dass man durch Testen auf einer zweiten Instanz (was selbstverständlich ist) die Verfügbarkeit erhöht (was vorsichtig gesprochen Unsinn ist) - nun, mehr als ein "Ach ?" fällt mir dazu nicht ein.
LG
pah
Zitat von: chris1284 am 18 November 2014, 17:46:11
Der Einsatz des Benzinpreismonitor 's kostet übrigens nichts in der Anschaffung und hilft evtlKosten zu sparen. Warum sollte man das auch kritisieren?
Weil es in einer Heimautomation nichts zu suchen hat, tonnenweise Websites dazu existieren und die alle möglichen Möglichkeiten der Nutzerinformation bieten.
Ach, du entscheidest, was hier etwas zu suchen hat ?
Habe mich immer schon gefragt, wer das ist.
pah
ich geh mal Popcorn holen, das wird hier bestimmt noch lustig :)
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.
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? ;)
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 (https://packages.debian.org/stable/pacemaker)
OpenAIS ist auch verfügbar: https://packages.debian.org/stable/openais (https://packages.debian.org/stable/openais)
Also vorausgesetzt, man möchte das auf einem der üblichen ARM-Boards aufbauen.
19" Server sagt erstmal 0 über den Stromverbrauch, die Zuverlässigkeit und die Leistung. :o
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.
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
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. :D
Insofern kann ich sowohl Deinen Thread als auch den Hintergrund verstehen. Probier das einfach mal über Weihnachten aus und berichte hier.
Zitat von: chris1284 am 19 November 2014, 06:54:12
19" Server sagt erstmal 0 über den Stromverbrauch, die Zuverlässigkeit und die Leistung. :o
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.
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
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 8)
---
Disclaimer: dieser Beitrag wurde nicht korrekturgelesen, ich bitte daher, syntaktische und semantische Fehler oder ungenaue Formulierungen zu entschuldigen...
Bitteschööön
Nichtsdestrotrotz ;D ;D ;D
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.
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
Kurze Frage dazu: Was passiert, wenn der raspberry, an dem das usb geraffel hängt abschmiert?
Auch wenn der Ausdruck "Geraffel" nicht gerade zum Fachvokabular gehört: Der Hardware-Watchdog startet einen Raspberry Typ B in ca. 30 Sekunden neu.
LG
pah
Ja schon klar. Ich frage mich nur was es bringt, wenn die frontends redundant laufen und dann doch auf die betriebsfähigkeit einer kommunikationseinheit angewiesen sind.
Nochmal...
Es geht da nicht zwingend um Hochverfügbarkeit.
Mir geht es lediglich darum dass die Performance von FHEM durch eine VM gesteigert wird.
Auch, dass ich sämtliche Vorteile die mir mein ESXi Server bringt nutzen kann.
Ob das Snapshots sind, oder Anbinden von weiteren Netzwerkkarten, VLANs etc...
Der ESXi läuft ja auch im normalfall die ganze Zeit und könnte das alles hosten. Eine Verbindung zum HardwarePi der die Sticks dran hat dann per FHEM2FHEM und gut.
So würde es bereits ohne Probleme laufen.
Aaaaber...
Ich möchte ja, dass ich die komplette Config auch über den HardwarePi ansprechen kann.
Der ESXi braucht nach einem Stromausfall ne Weile bis er wieder komplett alle Images hochgefahren hat und solange könnte ich dann sonst nichts steuern.
Und in dieser Zwischenzeit soll der HardwarePi eben schon ansprechbar sein.
Idee war ungefähr so:
NAS:
- hat ein NFS Share namens "fhemconfig"
- hat ein NFS Share namens "fhemlogs"
- hat ggf alternativ auch eine MySQL DB
- ist als erstes nach einem Stromausfall erreichbar.
ESXi:
- hält das primäre FHEM Image.
HardwarePi:
- hat die USB Sticks
Betrieb:
"ESXi-fhem" und "Pi-fhem" ziehen sich die Config vom NAS Share "fhemconfig" oder eben aus der MySQL DB
Die Logs liegen ja im "fhemlogs" Share.
Daher müsste sich "ESX-fhem" und "Pi-fhem" die Logs vom NAS Share "fhemlogs" ziehen um dann die Plots zu machen.
Jetzt (gerade in dem Augenblick) lese ich gerade dass es auch ein "Dblog" Helpermodul gibt, das die Logs auch in eine DB schreibt.
Würde das das Ganze nicht noch mehr vereinfachen nur aus einer DB zu lesen?
Also korrigierter Betrieb:
>>Beide FHEM instanzen ziehen sich die Config sowie die Logs aus der MySQL DB
Ich habe mir die ConfigDB noch nicht genau angeschaut. Kommt immer wieder was dazwischen ;-)
Aber wenn man jetzt die DB noch mit Usern ansprechen könnte, dann könnte man der Primären Instanz also in meinem Fall ESXi-fhem einen User zuweisen der Alle Rechte hat und dem Pi-fhem dann nur lesend für die Config und schreibend auch fürs Dblog
>> Jenachdem ob das so geht, kann man anhand verschiedener DB User steuern, ob die eine, oder die andere Instanz die lesende, oder die produktive Instanz ist.
Gruß
der Merlin
hmmmmm,
Rahmenbedingnung:
FHEM mit USB ist nicht redundant und noch für die Gerätekommunikation zuständig
FHEM(a) mit ConfigDB und dbLog in eine lokale mySQL DB schreiben lassen; diesen Rechner mit einer USV absichern und per Hardware Watchdog absichern
ESX Server auch per USV absichern
auf dem ESX Server eine "AuswerteDB" mit mySQL aufsetzen
FHEM DB in die "AuswerteDB" mit mySQL spiegeln (Bordmittel mySQL)
ein "ControlFHEM" (b) auf dem ESX Server einrichten
(a) mit FHEM2FHEM mit (b) verbinden und dann nur noch "alles" mit (b) machen
(b) greift dann noch auf die "AuswerteDB" zu
Also ich denke wenn man das ganze in nem Container irgendwo hinpackt mittels Docker oder so sollte es möglich sein die Instanz wenn Zentral auf nem NAS oder so gespeichert auf nem anderen Server einfach hochfahren lässt. Automatisieren würde ich sowas nicht. könntest ja auch zur not per ssh von der Ferne aus machen.
und zur not nimmst nen 2ten raspi und zeigst deinen mädels wie sie die SD Karte und die Kabel umstecken.
Wir betreiben ja auch keine Kernkraftwerke wo jedes System n+mindestens 1 vorhanden sein muss.
Das denke ich ist auch der falsche Einsatzzweck für FHEM.
Aber dann stellt sich hald auch noch die Frage, was wenn das NAS ausfällt, was wenn die Interfaces wie HMLAN ausfallen, was wenn die Datenbank abschmiert von configdb oder wenn CUL's defekt sind, oder was wenn deine Internet Connection den geist aufgibt.
Ich bin ja der Meinung ein System sollte soweit Autark sein das auch wenn Fhem tot ist, man jedes Licht z.B. noch per Hand schalten kann.
Dann müssten hald deine mädels für solange du Weg bist auf den Zentral Aus verzichten.
Und aus der Ferne an Systemen rumkonfigurieren, da sollte man sich immer bewusst sein das man nicht schnell nen Kabel umstecken kann.