Umzug von einem Wolf auf einen anderen

[StefanW]

Hallo Tobi,

ich schreibe noch an dem Wiki, arbeite aber gerade an einem Video, das auch fertig werden muss.

1. Docker Images und Docker Container und Docker Volumes sind nicht von Backup / Restore umfasst. D.h. da wird NIX gesichert und auch nichts restored. Muss man selbst machen.

2. Wir arbeiten noch an der Implementierung des Umzugs zwischen den verschiedenen Servermodellen. Wir haben sechs Grundmodelle aus drei Prozessorarchitekturen mit verschiedenen Interfaces. Das ist eine größere Herausforderung als es klingt. Wir implementieren das in drei Stufen.

- Erste Stufe wurde bereits in der Vergangenheit ausgerollt und sorgt dafür, dass die Datenstrukturen kompatibel sind (ARM zu AMD, 32 vs 64 Bit, Little- vs. Big-Endian) und grundsätzlich ein Restore von einem anderen Server möglich ist.

- Zweite Stufe kommt mit IP5 (voraussichtlich nächste Woche), damit wird der Restore von Portainer (nicht der Container) und der LAN-Anschlüsse anders gehandelt (und ein paar weiterer Kleinigkeiten).

- Dritte Stufe kommt dann voraussichtlich mit IP6 und übernimmt dann das Klein-Klein der Umschreibung der Konfig zwischen den Interfaces, das betrifft insbesondere KNX und der seriellen Schnittstellen. Was leider auch nicht so trivial ist, wie es klingt, weil es sind um die 6 Varianten (2100, 2400, 2500, 2600, 3xx, 9xx auf 3500) die hierfür berücksichtigt werden müssen. In der Vergangenheit wurde bei einem derartigen Serverumzug das immer von Hand gemacht, was einen Entwickler aber mehrere Stunden gekostet hat, das geht bei der Menge an Migrationsserver nicht mehr.

Leider werden wir diese dritte Stufe erst im Januar schaffen. War natürlich anders geplant und ja, ich verstehe dass man den neuen Server gleich umbauen möchte, ist ja auch Weihnachtsferien und wir verstehen, dass man uns jetzt die Haut in Streifen schneidet, aber schneller bekommen wir das neue Restore 4.0 leider nicht umgesetzt.

War echt anders geplant, Sorry

Stefan

[gbglace]

Die Daten Volumes der Container sollten ja separat sein und dann packt man sich noch einen SSH Container dazu maounted sich da auch alle Datenvolume dazu und dann kopiert man sich die Inhalte auf seinen PC. Auf dem neuen Wolf auch alle Volumes anlegen SSH Container drauf und dann wieder die Daten vom PC reinkopieren.

Die eigentlichen Container dabei natürlich pausieren.

[tobi42]

Hallo Stefan, vielen Dank für die Antwort. Den aktuellen Stand kann ich gut nachvollziehen und möchte die Migration dann natürlich gerne auch korrekt und vollständig durchführen. Mir ist eine stabile Migration wichtiger und lieber als ggf. mehrere unvollständige. Naheliegend ist natürlich, dass die Migration gut in die Weihnachtsferien passt - ich nutze sie diesmal wirklich im Sinne von Ferien um Uraub mit er Familie zu machen.

Der Hintergrund / der Wunsch den neuen Server einzustzen lieget in der 64bit CPU: Manche Dockerimages stehen nur als 64bit Version zur Verfügung. Aber vielleicht ist folgendes eine Lösung: Was wird beim einem Restore bzgl. der Container denn ersetzt? Wenn in dem Bereich bereits vorhanden Container nicht gelöscht werden (im Rahmen des Restores), dann kann ich den neuen Timberwolf schon für neue Container einsetzen. Wird das so funktionieren?

@gbglace: Vielen Dank für den Hinweis. Das Vorgehen habe ich im Wiki?/Forum? so auch schon gefunden. Ich muss es "nur noch" mal eben umsetzen...

Schön wäre es aus Anwendersicht, wenn die persistenten Volumes optional in das Backup integriert werden können - klar, dass dazu der Container gestoppt werden muss um ein konsistentes Backup zu erstellen. Eine Sicherung der Images ist meiner Meinung nach nicht erforderlich.

[gbglace]

Die persistenten Volumes kennt das TWS OS so nicht da die ja auch ein wenig flexibel gespeichert werden können und dann müssen die auch beim Restore wieder ins Portainer integriert werden.

Auch wenn ich da wahrlich kein Linux-Spezialist bin aber ich kann da Stefan aus Sicht Elabnet sehr gut verstehen.
Die Nutzung der Containeranwendungen durch den Enduser, abseits der geführten App-Container ist Profi-User Zeug.
Da darf man sich gern selbst um eine Sicherung kümmern >> SSH Container und eine externe Backup-Lösung.
Da mir der externe Server fehlt habe ich das noch nicht ausgetestet, aber ich denke das dürfte nicht komplizierter werden wie die Einrichtung eines Containers selbst für NR und Co.

Und wenn man das hat ist man da derzeit noch nen Schritt weiter als die manuelle Backupstrategie des TWS-Backups auf die SSD und/oder Elabnet-Stick.

Insofern aktuell ein Grund mehr sich da eine eigene Lösung für diese Volumes zu bauen.

[Robosoc]

Ich habe diese Woche die Info bekommen, dass meine beiden neuen Server nun versendet wurden. In einer ankündigenden Mail wurde ich auch darauf hingewiesen, dass ein Umzug von einem Servermodell (in meinem Fall 950) auf ein anderes (in meinem Fall 3500) noch nicht möglich ist. In dieser Diskussion hier geht es ja ab Beitrag #56 exakt um das Thema.

Nun bin ich aber etwas verunsichert, insbesondere nachdem nahezu alle Punkte in Beitrag #61 bereits abgeschlossen sind (wir sind aktuell bei IP7 der V4.0 - also ist eventuell einiges schon möglich?).


Konkret gefragt: Was ist aktuell in der IP7 in Bezug auf den Wechsel von Modell 950 auf 3500 möglich (wenn nicht möglich, ab wann wird es möglich)? Ein original USB Stick von Elabnet zum Zwecke der Timberwolf-Datensicherung ist vorhanden.

1. Übernahme vorhandener Logiken (aktuell 182 Stück)
2. Übernahme der vollständigen 1-wire Konfiguration (ich nutze aktuell den integrierten Busmaster und einen externen PBM und erhalte in der Tauschaktion einen weiteren (zweiten) externen betreiben würde). (76 Geräte, 146 Transaktionen, an 6 Kanälen)
3. Übernahme der Zeitserien (aktuell 192 Stück)
4. Apps (Wiregate & Visu) - Sehe ich weniger als Problem, könnte ich selber sichern und wieder herstellen
5. Verknüpfungen im Objektmanager (dafür müssen dann ja zwangsweise auch alle Objekte bekannt sein, also quasi die KNX-HTTP-MQTT-1Wire Konfiguration
6. integriertes Grafana (inkl. aller von mir dort erstellten Dashboards)
7. Netzwerk und KNX-Schnittstelleninformationen - (Muss ich in der ETS eine Programmieränderung vornehmen)



Modbus, Ekey, IFTTT nutze ich nicht, ist daher für mich nicht relevant

[StefanW]

Hi Sven,

wir arbeiten daran, es ist nicht so einfach.

Konkret haben wir mit mehreren Kunden gerade Tests der Migration am Laufen und es wird dann auch eine Software geben und einen Wiki-Eintrag.

Das Problem sind die unterschiedlichen Schnittstellenadressierungen zwischen den verschiedenen Produkten. Bei dem jetzt verfügbaren Restore, wird das nicht passend auf die Ziel-Architektur umgeschrieben und das führt dazu, dass dann ganze Subsysteme mit Ihren Objekten nicht mehr zur Verfügung stehen.

Damit stehen und fallen alle entsprechenden Verknüpfungen und das wirkt sich dann eben systemweit aus. Wenn jemand z.B. 1000 KNX Objekte in zweitausend Verknüpfungen quer über alle Subsysteme hat und nach dem Restore dieses KNX-System nicht mehr mit dem Busankoppler spricht, dann sind diese zweitausend Verknüpfungen unbrauchbar.

Wir werden informieren, wie hier die Fortschritte sind.

Stefan

[StefanW]

Hallo,

ich habe meine Antwort am Freitag geschrieben, nachdem ich erfahren hatte, dass ein enges Mitglied aus der Familie meiner Frau noch jung aus dem Leben gerissen wurde und habe das evt. etwas pessimistisch verfasst, so dass Kunden nun panisch mit "der neue Server ist dann unbrauchbar reagieren". Das ist selbstverständlich nicht so und war es auch nie.

Ich möchte das klarstellen:

1. Solche Migrationen zwischen verschiedenen Servermodellen gibt es schon seit Jahren und wurden von unsere Support-Team bislang per Hand vorgenommen.

2. Da nun sehr viele Migrationen anstehen, wollen wir diese manuellen Anpassungen automatisieren und in den Restore integrieren.

3. Dazu haben wir in der Vergangenheit schon zwei Umstellungen von Backup / Restore implementiert auf dem nun die dritte Stufe der Interface-Umschreibungen basieren soll.

4. Dieses Projekt gehört in den nächsten beiden Wochen zu den Top-3 Aufgaben an denen wir arbeiten werden (die anderen sind Umstellungen im Lizenzshop und eine Reihe von Fehlerverbesserungen in mehreren Subsystemen, wir arbeiten also nicht vorrangig an der VISU, ich erwähne das, weil manche behaupten, "dass nix anderes passieren würde").

5. Die Arbeiten an der Umstellung von 3xx / 9xx auf 3500 laufen jetzt die kommende Woche. Womöglich bekommen wir dann das auch noch in die IP8, oder eben die nachfolgende Version, ich will es aber nicht fest versprechen.

Ja, es ist nicht so einfach für uns, aber unsere Vorstellung ist, dass die Kunden davon nichts merken. Stick in den einen Server und Backup, dann Stick in den anderen Server und "Restore" und ggfls. ein oder zwei Punkte laut Anleitung beachten. Es wird damit auch einfacher werden, als das bisheige Anleitungen angeben, weil wir mit IP5 schon etliches vereinfacht haben.

Kurz: Wir sorgen dafür, dass die Migrationn von alten auf neuen Server so problemlos ausgeführt werden kann wie möglich. Falls es mit einem automatischen Weg zu aufwändig wird, dann machen wir das eben von Hand, wie bisher auch. Also bitte keine Sorge, dass es keine Übernahme von Daten oder Konfiguration gibt. Wir wollen nur die Chance wahrnehnen, das zu automatisieren, weil dann künftig der manuelle "Kelch an uns vorrübergeht".

Wir werden informieren

lg

Stefan

[StefanW]

Hallo Foristen,

Überarbeitung von Backup & Restore V4:

Wir arbeiten noch daran, aber wir wollten Euch einen Überblick über den Zwischenstand geben und haben auch eine kleine Überraschung für Euch





1) NEUHEIT! Erweiterte Anzeige um darauf hinzuweisen, falls eine Restore (hier Migration da von anderem Server) mit der aktuellen Firmware nicht möglich ist mit Link auf das Wiki (dieser Eintrag ist derzeit noch in Bearbeitung), weil die Fähigkeiten mit den nächsten IPs erweitert werden

2) NEUHEIT! Docker Volumes sichern: Wir haben eine kleine Überraschung für Euch, mit dem neuen Backup kann man nun auch näher bestimmen, was ins Backup aufgenommen werden soll und NEU ist nun, dass man Docker Volumes sicher kann.

3) Schnellauswahl: Mit der Schnellauswahl kann man durch ein paar Klicks bestimmen, was gesichert werden soll

4) Detailauswahl: Mit der Detailauswahl kann man die Docker-Volumes mit Namen, Typ und Größe auswählen

5) Volume Dateiübersicht: Wer möchte, kann über die Schnellansicht den Volume Inhalt genauer ansehen




Diese erweitert die Datensicherung um Docker Volumes und eine detaillierte Auswahl, damit man nicht immer alles sichern muss (das ist interessant für Tester, damit das Backup vor und nach dem Upgrade nicht soviel Zeit beansprucht). Dies verbessert auch die Migration erheblich bei den Nutzern, die Docker Container mit Volumes nutzen, weil dies jetzt einfach per Klick in der Sicherung mitkommt und wieder Restauriert wird. Das spart eine Menge Handarbeit.

Das Design ist noch nicht final. Wir wollten Euch aber zeigen, was wir in dieser Woche geschafft haben und dass wir die neue Lösung erweitert und für Euch verbessert haben.


lg

Stefan

[KFloo]

Cool! Das mit der Docker-Volumesicherung ist toll - freut mich richtig!

[blaubaerli]

Hallo Stefan,

das ist im Notfall dann wirklich „Gold wert“.

Danke.
Beste Grüße
Jens