iobroker hochverfügbar
-
Hi Leute,
Ich habe mir folgendes zusammengestellt:
drei identische Laptop Lenovo G700 mit 8GB RAM und 256 GB SSD auf allen läuft Ubuntu Server 20.04 LTS, Redis Server, Redis Sentinel und iobroker mit bisher nur den Grundadaptern. Einzeln laufen alle drei ohne Probleme mit States und Objects auf Redis. Was mir bisher nicht gelingt ist die Verknüpfung der drei. So dass ich ein hochverfügbarkeits System habe. Das Problem beginnt schon wenn ich versuche zwei als Master/Slave als Multihost konfiguriere. Master läuft ohne Problem weiter und der Slave meldet immer kein Master gefunden. Kann mir jemand nochmal die Konfiguration in Redis zeigen? würde mich sehr freuen.
Grüße Frank -
-
@darkiop ja den super Beitrag hab ich eine Woche studiert ich bekomme es aber nicht hin. ich hänge an der Stelle das der zweite iobroker die redis daten auf dem ersten immer nicht findet,
-
@frankbb27 ok, für mehr bin ich leider raus - hab das ebenfalls für irgendwann auf der todo stehen. Aber vielleicht findet sich ja noch Hilfe.
-
Aaaaaalso
Hochverfügbarkeit ist so ein Thema und wir sind noch nicht ganz angekommen.
Was Du mit Redis als DB und Sentinel hinbekommst, ist dass Du quasi drei ioBroker Hosts hast die alle unabhängig sind. Es gibt dort auch faktisch keinen "Master ioBroker" mehr, weil die DB in dem Fall "der zentrale Faktor" ist.
Daher:- Richte einen iobroker ein (nenne wir Ihn mal kurz Master weil da aktuell dein Admin läuft und die initiale DB Befüllung herkommt) und richte ihn ein das er deinen Redis Sentinel Cluster als DB hat ... Dann teste das da alles geht. Wichtig: Du gibst den Sentinel Port in der Konfig an!! ioBroker fragt dann den Sentinel welcher redis gerade der Master ist
- Dann nimmst Du die zwei anderen und machst dort am besten "iobroker setup custom" und trägst auch deien Redis Sentinel CLuster als DB ein, sagst aber bei den Migrationsfragen das das Slaves sind und du NICHT migrieren willst!!!
- Dann sollten die beiden Hosts im Admin auftauchen wenn Du sie gestartet hast
Ab jetzt ist Master/Slave faktisch egal weil alle drei iobroker Instanzen eigenständig sind. Du kannst natürlich den wo dein Admin läuft immer noch gern Master nennen
Was haben wir damit erreicht:
Egal welcher der Laptops ausfällt Du verlierst "nur" die Instanzen die auf dem Host laufen, das restliche System läuft aber noch weiter - also die Instanzen die auf den anderen Hosts liegen.Das war es aber (leider) auch schon.
Heisst: Im Fehlerfall eines Hosts musst Du immer noch manuell hingehen und die Instanzen auf die anderen Hosts verteilen bis zB die defekte Hardware getauscht ist.Was noch auf meiner Ideenliste steht ist ein "HA-Adapter" der an der Stelle die Konfiguration annimmt welche Adapterinstanz verschoben werden kann und wer nicht (weil zB lokaler Serieller Port genutzt wird oder so). Und dann monitoren Instanzen dieses HA Adapters die Hosts und wenn einer ausfällt schieben die dann Instanzen durch die Gegend um wirklich so viel Funktionalität wie geht zu erhalten.
Ein noch etwas ungelöstes Thema sind Adapter die Netzwerkports anbieten und damit an IPs gebunden sind ...Also ja, Ideen sind da, Zeit nicht
-
@apollon77 sagte in iobroker hochverfügbar:
Also ja, Ideen sind da, Zeit nicht
Eilt ja nicht, alle Achtung was ihr bereits realisiert habt. Macht Spaß ein (kleiner) Teil davon zu sein!
Das Thema schreit eigentlich mal danach mittels 3 lxc's in Proxmox getestet zu werden
Mal Grundsätzlich zu HA: Wäre das ganze nicht auch mittels Proxmox HA + Storage HA gut abgedeckt?
-
@darkiop Natürlich ist ein Proxmox-HA Ansatz mit einem verteilten Filesystem in dem Zuge natürlich auch mit Proxmox jetzt schon "HA". So habe ich es aktuell
Ich habe einen 7 Intel Nuc Proxmox HA Cluster. AUf den Proxmox ist GlusterFS als verteiltes Filesystem drauf wo die Images der Container und VMs liegen.
Pro Host läuft ein Redis LXC, damit eine 7 Node Redis Sentinel Cluster für die ioBroker Redis DB. Mein Prod System sind 3 VMs auf Proxmox.
Das ganze als Proxmox-HA definiert, sodass falls ein proxmox Host ausfällt die VMs und LXC automatisch auf einen anderen Host geschoben werden und wieder hochfahren und über die HA priorisierung wirds wieder zurückgeschoben falls Host wieder hochkommt.Alle USB-Geräte hängen an anderen Mini Hosts und sind in den VMs per USBIP eingebunden - sind also unabhängig von den proxmox hosts. Die 7 Nodes+USB hosts auf 3 Stellen im Haus mit jeweils eigener USV verteilt.
Damit habe ich jetzt schon HA für ioBroker.
Das ganze geht natürlich auch mit 3 proxmox Nodes
-
@apollon77 Klingt spannend, 7 Nodes ...
Ich schieb das ganze aktuell noch vor mir her - wobei ich daran durchaus Interesse habe. Aber aktuell läuft ioBroker noch auf einem Nuc in einer VM und darain ebenfalls die Redis DB.
GlusterFS kenne ich noch nicht - d.h. die Proxmox Nodes stellen zusammen den Storage zur Verfügung und man braucht dafür dann keinen extra Fileserver?
Vielleicht gehe ich das Thema doch mal an, zweiter Nuc + Raspi als quorum für den ersten Schritt Richtung HA.
-
@darkiop Genau, proxmox Root hat bei ir 15 oder 20 GB und der rest der SSD ist dann in einer partition gemacht. Das ganze identisch auf 3 rechnern. Dann glusterfs installieren direkt auf dem proxmox os und dann damit ein zB shared FS machen was dreifach repliziert ist.
glusterfs geht auch nur mit 2 nodes und einem "quorum node", dann ist es aber im Ausfallfall speziell was passiert. Wenn Dir der falsche Node ausfällt ist dann alles weg weil FS dann read only geht. Glusters ginge noch mit 2 replicas plus einem sog. "Arbiter" - der hlt nur meta daten, da könnte man nen raspi oder so als dritten nehmen ... dann gehts auch mit zwei Datennodes.
Aber ja brauchst ein Shared FS. Wenn dein FS auf der NAS liegt ast Du ja sonst wieder einen Single-point-of-Failure (ohh NAS macht ein update ... ohh mist, alles down)Als Setup Link (zur Vorstellung wie es geht) zB https://forum.proxmox.com/threads/create-a-proxmox-6-2-cluster-glusterfs-storage.71971/ ... ich habs aber nicht ganz gelesen ob es wirklich so geht. ich könnte supporten - auch was man danach noch wie machen sollte weil es da bissl spezialiäten gibt die ich lernen musste ... vllt Fällt da ja ne anleitung raus
Und das es bei mir 7 Nodes sind ist Historisch - 7 nodes NUC5PPYH mit max 8 GB waren am Ende billiger als 4 größere ... aber inzwischen haben die 8GB genervt und bin jetzt upgraded auf NUC8i5 mit je 16 GB (und kann noch auf 32GB hoch). Und ja es läuft inzwischen einiges da drauf neben meinem Prod System
-
@apollon77 sagte: Alle USB-Geräte hängen an anderen Mini Hosts und sind in den VMs per USBIP eingebunden
Und diese schränken dann die Hochverfügbarkeit ein (single point of failure)?
-
@paul53 naja aber das tun Sie ja immer auch wenn ich die USB Sticks direkt am Rechner hätte. Irgendwo müssen die drinstecken
Und ja falls der Host wo ein USB stick drin steckt ausfällt dann ist der eine Adapter (oder die wenigen die diese lokalen Geräte brauchen) der den Stick braucht halt tod ... Das lässt sich nicht ändern.man kann keine zwei IR Köpfe an einen Stromzähler klemmen oder zwei Zigbee Master im gleichen Netzwerk haben mit gleicher konfig ...
Lokale Schnittstellen sind hier per definition limitierend ...
Gleiches gilt am Ende für meine CCU2 ... ich hab zwar reserve-HW, aber einen "HA Ansatz" dafür gibt es nicht wirklich
-
@apollon77 sagte:
das tun Sie ja immer auch wenn ich die USB Sticks direkt am Rechner hätte.
Ich meinte mit meiner Aussage, dass die Funk-Modems die Hochverfügbarkeit einschränken, da sie die angelernten Geräte verwalten (außer HomeMatic).
-
@paul53 Ja genau, aber auch bei einem späteren "HA Manager Adapter"-Ansatz sind das dann adapter die man (jetzt mal ohne USBIP gedacht) auf einen spezifischen Host festpinnt weil bringt ja nixx die zu verschieben weil auf keinem anderen Rechner ist der USB Stick
Das sind aber die Limitierungen mit denen man leben muss denke ich
-
@apollon77 sagte: Das sind aber die Limitierungen mit denen man leben muss denke ich
Was nutzt die Hochverfügbarkeit von ioBroker, wenn wichtige Geräte nicht mehr gesteuert werden können?
-
@paul53 Ich denke das kommt immer darauf an und ist dann sehr individuell. Also bei mir ist USB zB zwei smartmeter mit IR und ein mbus und einmal zigbee (nur paar Lampen) und ZWave (ein Lüfte und sowas).
Wenn das wegfällt .. naja ... egal.
Schlimmer wäre bei mir wenn die Homematic CCU ausfällt, die ist per Netzwerk erreichbar. Die ist also quasi mein persönliches "Single Point of Failure".Bei uns ist ioBroker und die ganze Steuerung inzwischen so tief in den Alltag integriert (zB auf der Fingerabdruckscanner und damit Türsteuerung läuft drüber und einige andere Automatisierungen wie Gartenberegner, Rasenmäher, jetzt Poolsteuerung und so. Ich nehme dann lieber 90% als nichts
Wenn der Host mit dem JavaScript Adapter ausfallen würde wäre sehr blöd.Meine Hauptidee für "HA" (neben dem Herausforderungsfaktor) war aber auch: wenn mal was passiert und ich nicht da bin soll sich das System so gut es geht selbst heilen - wenn da unwichtigere Dinge auf der Strecke bleiben ist das akzeptabel ... und am Ende gilt es wie immer: Echtes HA ist unbezahlbar - erst recht im privaten Umfeld, also kann man sich nur nähern und wie "nah" das wird ist auch wieder eine Frage des Geldes und des Aufwands.
Auch für meine CCU könnte ich was bauen das ich die Reserve HW aufbaue und angeschlossen habe, regelmäßig das aktuellste Backup einspiele, sodass Sie falls die erste ausfällt dann von ioBroker erkannt eingeschaltet werden kann und Theoretisch die Arbeit übernehmen könnte. hab ich bisher noch nicht gemacht ... andere Dinge waren spassiger
-
@apollon77 sagte in iobroker hochverfügbar:
@darkiop Genau, proxmox Root hat bei ir 15 oder 20 GB und der rest der SSD ist dann in einer partition gemacht. Das ganze identisch auf 3 rechnern. Dann glusterfs installieren direkt auf dem proxmox os und dann damit ein zB shared FS machen was dreifach repliziert ist.
glusterfs geht auch nur mit 2 nodes und einem "quorum node", dann ist es aber im Ausfallfall speziell was passiert. Wenn Dir der falsche Node ausfällt ist dann alles weg weil FS dann read only geht. Glusters ginge noch mit 2 replicas plus einem sog. "Arbiter" - der hlt nur meta daten, da könnte man nen raspi oder so als dritten nehmen ... dann gehts auch mit zwei Datennodes.
Aber ja brauchst ein Shared FS. Wenn dein FS auf der NAS liegt ast Du ja sonst wieder einen Single-point-of-Failure (ohh NAS macht ein update ... ohh mist, alles down)Als Setup Link (zur Vorstellung wie es geht) zB https://forum.proxmox.com/threads/create-a-proxmox-6-2-cluster-glusterfs-storage.71971/ ... ich habs aber nicht ganz gelesen ob es wirklich so geht. ich könnte supporten - auch was man danach noch wie machen sollte weil es da bissl spezialiäten gibt die ich lernen musste ... vllt Fällt da ja ne anleitung raus
Ich schau mir das bei gelegenheit mal an - hab heut auf meinem Test Rechner Proxmox + 3 Proxmox VMs aufgesetzt - damit sollte sich jetzt etwas spielen lassen. Den Link zu GlusterFS aus dem Proxmox Forum hatte ich sogar schonmal in meiner Dokumentation im Kapitel HA gespeichert. Ich verpasse den 3 VMs mit Proxmox mal jeweils eine HDD und versuch mich mal an GlusterFS. Falls ich Hilfe brauche nehme ich das Support Angebot gerne an. Grundsätzlich dokumentiere ich auch immer schön mit, vielleicht kann das dann zu nem HowTo beitragen. Aber erstmal schauen wie es zeitlich passt.
Und das es bei mir 7 Nodes sind ist Historisch - 7 nodes NUC5PPYH mit max 8 GB waren am Ende billiger als 4 größere ... aber inzwischen haben die 8GB genervt und bin jetzt upgraded auf NUC8i5 mit je 16 GB (und kann noch auf 32GB hoch). Und ja es läuft inzwischen einiges da drauf neben meinem Prod System
Hehe OK
Die ziehen sicher auch einiges an Strom. Glaub ich mache die Tage auch mal einen Thread "Zeigt her eure Virtualisierung" - Ideen geben und bekommen Bei mir läuft da mittlerweile auch einiges, hab nen NUC8i5 mit 32GB und die werden teils auch mal knapp Du hast aber auch das ganze HA Zegs über die eine LAN-Schnittstelle des NUC laufen? Idealerweise sollte man das ja trennen ...
@paul53 sagte in iobroker hochverfügbar:
Ich meinte mit meiner Aussage, dass die Funk-Modems die Hochverfügbarkeit einschränken, da sie die angelernten Geräte verwalten (außer HomeMatic).
Was nutzt die Hochverfügbarkeit von ioBroker, wenn wichtige Geräte nicht mehr gesteuert werden können?
Da hast du absolut Recht - das sind dann Dinge die auch die bessere Hälfte direkt bemerkt - Licht, Bewegungsmelder, Garagentor, Bechattung, etc.
Aber auf dem Proxmox Cluster laufen ja noch mehr Dinge: lokaler DNS, Adblock, VPN, Kameras, Fileserver und eben auch ioBroker und Homematic in einer VM. Somit muss schon das Funkmodul aussteigen damits brenzlich wird. Das Szenario kaputte SD im Raspi und somit keine CCU mehr ist abgefangen.
Könnte man ggf. mit
https://homematic-forum.de/forum/viewtopic.php?t=60150
HomeMatic bzgl. Funk-Modul robuster bekommen?
@apollon77 sagte in iobroker hochverfügbar:
Auch für meine CCU könnte ich was bauen das ich die Reserve HW aufbaue und angeschlossen habe, regelmäßig das aktuellste Backup einspiele, sodass Sie falls die erste ausfällt dann von ioBroker erkannt eingeschaltet werden kann und Theoretisch die Arbeit übernehmen könnte. hab ich bisher noch nicht gemacht ... andere Dinge waren spassiger
Geht das denn so direkt, dachte bisher die HM Komponenten sind an das Funkmodul gebunden.
-
@darkiop sagte: HM Komponenten sind an das Funkmodul gebunden.
Das ist der Vorteil von HomeMatic (zumindest classic), dass sie nicht an das Funkmodul, sondern an die CCU gebunden sind, also nicht wissen, wenn eine andere CCU (mit gleicher ID) übernimmt. Es kann natürlich immer nur eine CCU "funken".
-
Was ist mit der 2. Stromschiene eines 2. Stromanbieters?
-
@darkiop sagte in iobroker hochverfügbar:
Du hast aber auch das ganze HA Zegs über die eine LAN-Schnittstelle des NUC laufen? Idealerweise sollte man das ja trennen ...
Ja habe alles über die eine LAN Schnittstelle, aber alles dann mit der Zeit auf 10G in der Verteilung hochgezogen. Also Faktisch kann damit jetzt wirklich jeder Nuc seine 1G ziehen und weder der Switch noch die Hauptverteilung limitiert das dann. Sonst müsste man ja ganz andere Hardware nutzen, weil auch mit Nuc und dann per USB ne zweite NIC bereitstellen hat wieder andere Probleme.
-
Ich habe mit ewas HM angeht entschieden ncht selbst zu basteln (also Debmatic und wie es alles heisst) sondern echt die CCU Hardware zu nutzen. Updates macht man das wenn nötig über die Firmware und so. Die CCU als "Hardwarekomponente" ist aktuell noch nie ausgefallen und ich kann es nicht kaputtspielen
