Ja, die NetWorker Version 8.2 ist jetzt schon seit 31. Januar offiziell nicht mehr unter Support, aber dennoch laufen wohl noch eine ganze Menge NetWorker-Server unter dieser Version!

Gerade große NetWorker Konfigurationen, mit mehr als 1000 Clients, Umgebungen die mit externen Schedulern wie Atomic (UC4) und ähnlichem gekoppelt sind, sowie Sicherungen mit langen Aufbewahrungszeiten, bilden für die Umstellung eine sehr große Hürde. Die Probleme bei der Umstellung sind bekanntlich die nötige Anpassung der Skripte, aber auch die Problematik der automatischen Konvertierung der NetWorker 8 Gruppen in eine einzige Policy namens Backup. Sollte der NetWorker 8 aber mehr als 50 Gruppen gehabt haben, wird die NMC nach einer In-Place Migration nicht mehr bedienbar. Ein weiteres nicht zu unterschätzendes Problem bei der Migration besteht darin, dass die Logik des NetWorker 9 lässt sich nicht mit der Logik des NetWorker 8 gleich setzen. Man benötigt folglich für den Update einer großen NetWorker-Umgebung, nicht nur eine Anpassung der bestehenden Datensicherungs-Skripte sondern auch ein neues Konzept und einen Migrationsplan.

Nachdem ich in den letzten 2 Jahren einige In-Place Updates in kleineren Umgebungen und auch Migrationen von großen NetWorker-Umgebungen in eine neue NetWorker 9 Umgebung begleitet habe, kam ein großer Outsourcer auf mich zu, ob ich mit den in diesen Projekten entstandenen Skripten (siehe Blog) in der Lage sei, eine In-Place Migration von NetWorker-Servern mit mehr als 1700 Clients und hunderten von Gruppen zu automatisieren.

Im letzten Monat habe ich nun dieses Projekt abgeschlossen.

Wie funktioniert der implementierte Ansatz?

Die Migration läuft im wesentlichen in 2 Schritten ab.

1. In-Place Migration der NetWorker 8 Datenbanken.

   • zuvor kopieren der NetWorker Ressource DB (/nsr/res/nsrdb)

   • In-Place Migration der NetWorker Umgebung

   • Löschen aller Policys, Protection-Gruppen und auch Clients aus dem NetWorker 9 Server (mit Hilfe eines nsradmin Skriptes)

2. Migrieren der NetWorker 8 Client-Ressourcen in die neue NetWorker 9 Umgebung.

   • Anhand eines definierten Algorithmus werden die Client-Attribute der NetWorker-8 Clients wie Gruppe, StorageNode usw. herangezogen, um jeden Client in eine neu definierte NetWorker 9 Policy/Workflow/Protection-Group abzubilden.

   • Das Anlegen der neuen Policy/Workflow/Protection-Group Ressourcen wird hierbei mittels REST-API Aufrufen automatisiert erledigt. Die Clients werden wegen fehlender Client-Attribute in der REST-API mit Hilfe von nsradmin-Skripten erzeugt. Das Sammeln der „alten“ Ressource-Attribute, sowie das Anlegen der Clients erfolgt mit Hilfe der Schäfer & Tobies eigenen nsradmin-API.

Worin lag das größte Problem bzw. der größte Aufwand bei diesem Projekt?

Die Problematik bestand in einer möglichst genauen Definition der Abbildung der Alten Client-Gruppen-Strucktur auf eine eindeutige Policy/Workflow Struktur. Diese Logik musste in das Migrations-Skript implementiert werden und der Aufwand hierfür war durch fehlende und missverstandene Kommunikationen leider wesentlich höher als erwartet.

Ergebnis des Projektes:

1. Eine NetWorker-Server Migration lässt sich an einem beliebigen NetWorker-Server leicht in wenigen Stunden testen.

2. Die eigentliche In-Place-Migration ist in wenigen Stunden auch für sehr große Umgebungen durchführbar.

3. Die Migrationsquote der getesteten NetWorker-Server mit ca. 1500 und 1700 Clients lag bei 98% bzw. 99%. Clients die aus verschiedenen Gründen nicht in der neuen Umgebung angelegt werden können werden, mit allen Attributen in einer eigenen Datei abgelegt und können von den NetWorker-Administratoren per Hand leicht korrigiert und nach-migriert werden.

FAZIT:

Auch große NetWorker-Umgebungen können mit einem relativ geringem Zeitaufwand auf NetWorker 9/18 In-Place migriert werden! Der Aufwand der Migration wird von der eigentlichen Migrations-Phase auf eine Planung und Implementationsphase verschoben.

Die Vorteile dieses Verfahrens liegen auf der Hand:

• Durch die In-Place Migration können Langzeitsicherungen ordentlich übernommen werden.

• Die Migration kann vor dem eigentlichen Umstieg ordentlich getestet werden.

• Der eigentliche Update-Vorgang ist zeitlich überschaubar.

Sollte auch Ihr Unternehmen noch vor dem Update ihrer NetWorker Umgebung stehen, haben sie mit unseren Migrations-Skripten vielleicht eine neue bisher nicht bedachte Möglichkeit der sanften Migration der NetWorker Umgebung. Sprechen Sie uns ruhig unverbindlich an.