Das ist mein erster Beitrag hier, bisher habe ich nur mitgelesen und mir bei Bedarf Hilfe per Suchfunktion geholt. Nun habe ich hier ein Problem, dem ich etwas ratlos gegenüber stehe.
Folgendermaßen sieht mein System aus:
Thin Client HP t630 mit 8GB RAM, kein Proxmox oder so, ein ZBT-2 als Thread Borderrouter, ein weiterer ZBT-2 mit ZigBee (ZigBee2MQTT, kompletter Gerätepfad (/dev/serial/by-id/usb-Nabu_Casa_ZBT-2_xxxxxxxxxxxx-if00) ist eingetragen). Alles ist prima und läuft einwandfrei.
Aber:
Ich bin ein Fan von Redundanz. Somit habe ich einen zweiten t630 identisch mittels einspielen eines Backups konfiguriert und als “kalte Reserve” daneben gestellt. Die Idee dahinter war, sollte es mal Probleme mit dem t630 geben, und ich nicht zu Hause sein, dass meine Frau dann einfach alle Stecker in den anderen t630 umsteckt, den einschaltet, und nach ein paar Minuten alles wieder läuft.
Der zweite t630 hat natürlich eine andere IP-Adresse, nach dem Hochfahren läuft Matter over Thread inkl. aller Geräte einwandfrei, nur alle ZigBee-Geräte sind weg. Der MQTT Broker läuft, ZigBee2MQTT ebenso.
Wäre unfassbar nice, wenn mir jemand bei der Lösung dieses Problems weiterhelfen könnte.
Danke für eure Aufmerksamkeit und Gruß aus Friesland,
Das Problem dabei wird sein, die Z2M Geräte schicken Ihre Daten an den mqtt Broker und der wird vermutlich auf dem ersten T630 sein und daher sendet Z2M an diese IP.
Damit die Daten auf dem anderen T630 ankommen müsste dort der MQTT Broker die gleiche IP Adresse haben (sonst würden die MQTT Nachrichten an den “ausgefallenen” T630 geschickt werden. der “neue” weiß davon nichts)
Alternative wäre den MQTT Broker auf einem anderen Rechner mit eigener IP (virtuell/Hardware) laufen zu lassen und beide T630 greifen auf diesen zu.
Danke dir für die schnelle Antwort. Okay, das mit der IP leuchtet mir ein.
Mal sehen, ich könnte den auf meinem NAS laufen lassen.
Oder ich lasse es, wie es ist, und bringe meiner Frau bei, wie sie im Router die IP-Adressen der beiden t630 ändern kann.
Deine Antwort hilft mir auf jeden Fall schon mal weiter.
Du kannst doch bei beiden Kisten die gleiche IP verwenden. Diese laufen ja nie gleichzeitig.
Einfach nicht den DHCP Server verwenden. Sondern wie es sich gehört, am Server selbst eine statische IP vergeben, außerhalb des Adressennereichs des DHCP Servers.
Ich bin beruflich und privat vorgeschädigt, Hardwareredundanz finde ich prima.
Mir ist tatsächlich schon Hardware ins Nirwana gesegelt, nicht nur Festplatten. Anfangs lief HA auch auf meinem NAS, aber ich wollte dann doch lieber dedizierte Geräte dafür haben. Nenne es persönliche Befindlichkeiten, ich bin eben so.
Auch wenn es sich falsch anfühlt bin ich auch Fan davon beiden Geräten die selbe statische IP-Adresse zu geben. Der Sinn einer Redundanz ist ja eben, dass sie möglichst identisch ist - und da es geht kann man es machen. Man darf sich dann halt nicht wundern, wenn man an Gerät A etwas an der Konfiguration ändertn, Gerät B hochfährt um es nachzuziehen (ohne Gerät A abzuschalten) und dann plötzlich Wurstsalat hat. Oder man dokumentiert es sauber und weiß, dass man A und B nie zeitgleich laufen lassen soll.
Beiden die gleich IP zu geben, wäre natürlich eine Möglichkeit. Du hast Recht, es fühlt sich irgendwie falsch an, aber vielleicht kann ich mich doch dazu überwinden.
Ich werde das noch mal in Ruhe behirnen.
Man könnte auch in der Z2M-Config für den Broker den DNS-Namen des HA eintragen.
Müsste man testen ob der lokale DNS schnell genug arbeitet um auf die jeweilige korrekte IP zu zeigen nachdem geswitcht wurde.
Da ein tägliches Backup erstellt wird, nehme ich dann einfach das aktuellste Backup und spiele das ein. Gegebenenfalls muss ich dann eben mit dem Verlust von ein paar Statistikdaten leben.
Streng genommen benötigst du eine Backup-Appliance und einen Red-Button .
Sobald jemand den Red-Button haut wird der HA runter gefahren, vom Netz getrennt, eine Bare-Metal-Maschine an geschaltet und da per Appliance das letzte Backup aufgespielt. Dann passt das auch mit IPs .
Dann kannst du den alten HA löschen und als bare-metal in Bereitschaft bringen und das nächste Mal geht es dann vice versa.
Eine Alternative wäre evtl. (würde auch das Problem mit der IP lösen wenn die fest konfiguriert ist)
Statt ein tägliches Backup ein 1:1 Image der SSD erstellen auf die “externe SSD” und der Backup-T630 startet einfach mit dieser SSD (wenn beide die gleiche SSD haben und die Laufzeit des Backups egal ist, sowas wie z.B. unter Linux “dd if=/dev/sda of=/dev/sdc”)
Dann sparst du dir das Backup wiederherstellen, musst keine IP ändern nur die SSD vom “alten” T630 an den neuen klemmen.
Nachteil: keine älteren Backups und wenn du deinen Quell-T630 kaputt konfigurierst und das Image rüber spielst wäre auch der Ersatz “kaputt”
Nö, aber das kann ich remote machen. Und wenn kein aktuelles Backup eingespielt wird, ist es auch nicht so schlimm. Hauptsache, die Funktion ist wieder hergestellt.
Keine Ahnung, wie es bei HA ist aber die wenigsten Datenbanken lassen sich gerne per dd im laufenden Betrieb spiegeln (und wenn man den HA dazu außer Betrieb setzt ist die Laufzeit von dd letal).
Daher hatte ich die Appliance angesprochen. Die meisten können ziemlich viele DBs sauber stoppen, sichern und wieder starten. Die Ausfallzeiten sind dann sehr gering.
Man kann sich sowas natürlich auch als Skript zusammenstöpseln. Bootkram-Partitionen per dd, Dateisystem außer DBs per xcopy o.ä. und dann die DBs stoppen, xcopy, starten. Ist halt frickelig.
.