UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[MartyBr]

Meine Situation:
Ich betreibe eine CCU (RaspberryMatic) auf einem Asus Tinkerboard. Darüber lufen zentrale Steuerungsaufgaben.
Für die Visualisierung und den Komfort betreibe ich ioBroker.
Als Hardware habe ich einen Intel Nuc unter Proxmox mit mehreren VMs am laufen:
iobroker, MySQL, Historian, iobroker-test, pihole
Ein zweiten ioBroker läuft auf einen Rasperry mit zwei USB Leseköpfen für die Stromzähler.
Der Haupt-ioBroker und de Raspi laufen als Multihost, der Test-iobroker läuft separat.

Nun das Problem:
Mir ist letzte Woche der Nuc ausgefallen. Damit stand ioBroker.
Damit funktionierte die von meiner Frau geliebte Sprachsteuerung und die Beregnungssteuerung des Gartens nicht mehr.

Ich habe mir darauf hin einen NUC gekauft und konnte durch Plattenwechsel (SSD) die Server wieder in Betrieb nehemn. Nun funktioniert ja wieder alles.

Der erste NUC ist in Reparatur und kommt in wenigen Tagen zurück.

Meine Frage nun:
Ich werde den ersten NUC wieder mit Proxmox betreben. Für ein echtes ausfallsichers System benötigt man ja mind. 3 Systeme, dass ist mit zuviel Aufwand.
Kann man nun auf einem zweiten NUC einen weiteren ioBroker in Multihost installieren und dort alle Adapter im "Standby" installieren und beim Ausfall des ersten dann händisch starten?
Ich hätte dann nur relativ kurze Ausfallzeiten beim Ausfall der Host-Hardware (== Intel NUC).

[holgerwolf]

@MartyBr
Ich habe auch zwei Nucs. Mein Szenario:

• Mache jede Nacht ein Backup der VMs.
• Falls der Nuc mit den laufenden iobroker und MySql VMs abschmiert, lade ich die letzten Backups in den zweiten Nuc und starte diese. Ich habe auch (fast) immer die VMs im zweiten Nuc vorgeladen. Das könnte man noch scripten...

Hatte aber auch mit den Nucs bis heute noch keine Probs:

[BBTown]

Du kannst auch mit 2 NUCs eine sehr kurze Ausfallsicherheit erreichen, über ein "Cluster" in Verbindung mit der "Replizierung".
Du würdest dann per manuellen Eingriff ioBroker auf dem 2ten NUC starten und bist dann wieder online.

3 NUCs benötigst Du erst dann, wenn Du eine Hochverfügbarkeit aufbauen willst, die automatisch den Ausfall eines Systems abfängt und auf den 2 verbliebenen NUCs den Betrieb weiterlaufen lässt.

Da ich zudem die Daten/Backups/Container auf meinem NAS abgelegt habe und die gemounteten Laufwerke/Shares allen Nodes (NUCs) im Cluster gleichzeitig zur Verfügung stehen, haben alle NUCs immer alle notwendigen Zugriffe.

[MartyBr]

@BBTown Ich würde die 2 NUC Lösung anstreben. Wie hast du die ioBroker dort installiert? In einer Multihost Lösung oder separat?
Frage:
Ich nutze als History Instanz einen SQL-Server und den Adapter.

Wie löst du das?

Vielleicht doch jeden Abend ein Backup der VMs und diese auf dem zweiten NUC vorhalten,

[BBTown]

@MartyBr
Ich habe keine Multihost-Lösung, diese ist separat zu betrachten.
Anstelle von SQL habe ich eine InfluxDB. Diese läuft in einem separaten LXC Container
Dieser Container wird ebenfalls repliziert

Slebstverständlich mache ich auch tägliche Backups auf mein NAS
Aber Backup ist ja unabhängig von Ausfallsicherheit zu betrachten.
Das eine ersetzt das andere ja nicht.

Ähnlich wie ein RAID überhaupt nichts mit einem Backup zu tun hat.

[MartyBr]

@BBTown Ich fasse es mal in meinen Worten zusammen:
Du hast 2 NUCS unter Proxmox
du machst jeden Tag eine Datensicherung der VMs bzw, Lxc Container
diese legst du auf deinen zweiten NUC ab.
Bei Bedarf (erster NUC ist tot) startest du diese Maschinen.
Backup sollte selbstverständlich beachtet werden, in meinem Fall war leider die komplette Hardware defekt, Datensicherung war vorhanden.
Wenn die VMs nicht aktiv sind, dann spielt es keine Rolle ob Multihost oder nichtr.

Habe ich das richtig verstanden?
Wie replizierst du die Conbtainer / VMs?

[BBTown]

@MartyBr
Ich habe 2 NUCs zu einem Cluster verbunden.
Damit ist es unter anderem zunächst einmal völlig egal auf welchem der beiden NUCs ich mich anmelde, ich kann immer beide gleichzeitig verwalten (rebooten, Konsolen aufrufen, VMs oder Container starten oder stoppen, per Konsole bearbeiten, etc.)

Wenn ich im "Rechenzentrum" nun z.B. ein NAS-Laufwerk mounte (im Bereich Storage) oder aber User, Gruppen oder Rollen anlege, dann sind diese immer automatisch bei allen NUCs (Nodes) sofort erreichbar/verfügbar.

Derzeit nutze ich nur einen der beiden NUCs als produktive Umgebung, da ich ausreichend Speicher und Leistung habe. Der zweite NUC ist lediglich für Serviceaufgaben und als Backup da.
Daher replizierer ich auch nur in eine Richtung. Vom produktiven NUC auf das Backup-NUC.
Ob überhaupt repliziert werden soll oder in welchem Intervall, kann für jeden Container und jede VM separat definiert werden.
Durch diese Replizierung könnte ich innerhalb von wenigen Augenblicken (< 1 Minute) eine VM (oder einen Container) von einem NUC auf den andereren "Migrieren" - also dem Produktivbetrieb von einem NUC auf den anderen verlagern.
Hierzu müssen dann allerdings auch beide NUCs noch erreichbar und ansprechbar sein!
Über die Konsole kann auch bei Nicht-Erreichbarkeit des entsprechenden NUCs eine Migration von replizierten VMs und Containern erfolgen.
Replizierung ist eine Proxmox Funktion.

Alternative:
Um den Betrieb nun auch schnellstmöglich wieder herzustellen wenn einer der beiden NUCs nicht mehr erreichbar ist, greifst Du entweder auf ein Backup zu, welches eben nicht auf dem NUC sondern bspw. auf einem NAS liegt und spielst diese auf dem übrig gebliebenen NUC zurück,
oder aber die VM bzw. der Container selber liegen auch schon auf einem NAS und überhaupt nichts mehr lokal auf dem NUC.

[MartyBr]

@BBTown Danke für die Infos. Dann warte ich mal darauf, dass mein NUC aus der Reparatur kommt.
Ich werde die Geräte dann mal zu einem "Rechenzentrum" zusammenfassen. Also erst mal Doku lesen.

[BBTown]

@MartyBr
Du kannst sogar direkt aus der Replizierung das System wieder lauffähig machen selbst wenn der NUC auf dem bisher die VM oder der Container lief nicht mehr erreichbar ist.

Dies erfolgt über die Konsole mittels:

mv /etc/pve/nodes/A/qemu-server/100.conf /etc/pve/nodes/B/qemu-server/100.conf

wobei A der Ursprung und B das Ziel sowie 100.confin diesem Beispiel die VM ist

Hier findest Du (in englisch) die entsprechenden Informationen.

[MartyBr]

@BBTown Super! Herzlichen Dank. Man gewöhnst sich ja schon stark an so ein System und merkt dann beim Ausfall, was so alles fehlt.
Danke für deine Infos.

[MartyBr]

@BBTown Eine Frage noch dazu: In der Anleitung steht, dass der Storage Typ mit dem Dateisystem ZFS unterstützt wird. Ich vermute mal, dass ich ext4 einsetze.
Läuft es auch damit? ext4 unterstützt ja auch Journaling auf dem Dateisystem.

[BBTown]

@MartyBr
das kann ich dir nicht wirklich beantworten. Ich selbst habe meine Systeme auf ZFS aufgesetzt.
Ich glaube aber das es tatsächlich Voraussetzung ist, dass Proxmox bei der Installation mit ZFS Formatierung aufgesetzt wird

[MartyBr]

@BBTown Werde ich mal testen wenn mein NUC wieder greifbar ist,

[Leviathan09]

@MartyBr Was du dir vielleicht auch mal anschauen kannst wäre dieser Post: [Umfrage] Hochverfügbarer ioBroker auf RPIs
Bzw. auch diesen Artikel: Hochverfügbarkeits-Cluster

So etwas möchte ich evtl bei mir realisieren...irgendwann, wenn Zeit und ein weiterer NUC da ist.

[holgerwolf]

Da mein erster Proxmox noch unter 5.x lief und auch noch nicht im Cluster habe ich das Szenario gerade noch mal durchgespielt:

• Beide VMs (SQL und iobroker) gebackupt
• Backup auf anderen NUC hochgeladen.
• VMs auf ersten NUC gestoppt.
• VMs auf zweiten NUC gestartet.
• Läuft :-)

[paul53]

@holgerwolf
Wie wird mit den Modems (Zigbee, Z-Wave, HomeMatic) verfahren ?

[holgerwolf]

@paul53 Zigbee und Z-Wave habe ich nicht. Homematic läuft bei mir auf nem separaten Raspi. Kann deine Frage also nicht beantworten.

[paul53]

@holgerwolf sagte:

Homematic läuft bei mir auf nem separaten Raspi.

Der darf also nicht ausfallen ?

[holgerwolf]

@paul53 Nein ;-)

In Wahrheit, wäre das dann ne größere Aktion. Wegen dem Funk-Board. Das ist eine der nächsten Baustellen.

[MartyBr]

@holgerwolf
Es gibt ja da auch eine neue Entwicklung: Debmatic mit einem neuen USB-Funkmodul (HB-RF-USB ). Aber auch wenn man das Funkmodul redundant auslegt, hat man dann doch wahrscheinlich andere IDs.
Eine Lösung wäre natürlich, das USB-Modul über eine USB-to-Ethernet Adapter ins Netz zu hängen.
Aber ich glaube, hier übersteigt der Aufwand den Nutzen.

Meine Homematic läuft auf einen Tinkerboard mit einem eMMC Speicher, nicht auf einer SD-Karte. Da ist die Zuverlässigkeit im Betrieb wesentlich höher.