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.

 Halbautomatische Migration der NetWorker V8.2  Client/Gruppen Definition  in eine  NetWorker V9.1 Workflow Umgebung

1.Kurzbeschreibung

Viele NetWorker Kunden haben in der Version 8.x 100 – 1000 oder sogar mehr Gruppen. Der Extremfall sind 1-3 Gruppen pro Client.

Diese Konstellation ist in NetWorker 9 nicht mehr sinnvoll und EMC warnt vor ähnlichen Konfigurationen. Weil diese nicht getestet und damit auch nicht unterstützt wären.

Im Rahmen eines Kundenprojektes kam nun die Idee auf, die Umstellung der alten Client-Gruppen Struktur möglichst weit zu automatisieren. Entstanden ist ein Skript, das mit Hilfe der NetWorker 8 Konfigurationsdatenbank (/nsr/res/nsrdb) und einer Beschreibungsdatei in der Lage ist, Clients die nach definierten Kriterien aufgebaut bzw. anhand definierbarer Ressource-Attribute selektierbar sind, automatisch in einen definierten NSR9-Workflow zu verschieben.

2.Die Definitionsdatei

Mit Hilfe einer der Python Struktur (s.u. „Policy_def“) werden die neuen Ressource-Ziele (Policy-name, Workflow-Name) für die die Client-Ressourcen definiert. Mit Hilfe von Client- und Gruppen-Attributen werden Kriterien für die Aufnahme der Clients in den gegebenen Workflow definiert. Hierbei gibt es nicht nur positive (must criterias), sondern auch ausschließende (false_criterias) Kriterien.

Bei allen Attributen können Listen von gültigen oder ungültigen Werten und auch reguläre Ausdrücke angegeben werden.

Im vorliegenden Fall wurde zusätzlich (in der Definitionsdatei nicht ersichtlich) die „retention policy“ der verwendeten NetWorker Pools in die Migration mit einbezogen und diese wurden den zu migrierenden Clients als „retention policy“ Attribut hinzugefügt. Weitere kundenspezifische Anpassungen sind natürlich denkbar.

Policy_def = {

'Policy-Name' : {

'Workflow-Name' : {

'client_attrs' : {

'must_criterias' : {

'group' : '.*filesystem.*',

'scheduled backup' : 'Enabled',

},

'false_criterias' : {

'backup command' : 'savepnpc',

'group' : ['.*savepnpc.*', ...],

},

},

'group_attrs' : {

'start time' : {

'bigger' : '12:00',

'lower' : '15:00',

},

},

},

'Workflow-Name2' : {

'client_attrs' : {

'must_criterias' : {

'group' : '.*filesystem.*',

'scheduled backup' : 'Enabled',

},

'false_criterias' : {

'backup command' : 'savepnpc',

'group' : ['.*savepnpc.*'],

},

},

'group_attrs' : {

'start time' : {

'bigger' : '18:00',

'lower' : '23:59',

},

},

},

'Policy-Name2' : {
.
.
.
}

3. Der Migrationsablauf

Ein Start des Migrations-Skriptes „move_client.py“ führt dazu, dass bei allen im NetWorker 8 definierten Clients kontrolliert wird, ob sie die definierten Kriterien einer Policy/Workflow Definition entsprechen und wenn ja, werden die Client Attribute „Pool“, „protection group list“ und „retention policy“ für die Client-Ressourcen im bereits laufenden NetWorker 9 verändert.

4.Das Migrations-Skript

USAGE:

move_client.py [-v]* [-n | --TEST] [-s <NSR server>] [-d <nsrdb>] [-p <policy> [-w <workflow>]]

-v verbose

-n TEST

-s <NSR server> NetWorker Server V9 to work on

-d <nsrdb>      NetWorker 8 Resource DB

-p <policy>     only update the Clients for the given Policy

-w <workflow>   only update the Clients for the given Policy and Workflow

Das Skript benötigt eine „alte“ NetWorker 8 Ressource-DB. Diese kann entweder im Aufrufverzeichnis mit dem Namen „nsrdb“ liegen oder der Verzeichnisname der DB kann als Argument übergeben werden.

Achtung: Es sollte eine Kopie der NSR8-Ressource-DB verwendet werden, da auch die DB vom Skript verändert wird.

Wenn das Skript auf dem NetWorker 9 Ziel-Server verwendet wird, wird keine Angabe des Servers benötigt.

Durch die Angaben von Policy und Workflow kann ein erneuter Migrations-Lauf, zum Beispiel nach Änderung der Kriterien für eine spezielle Policy/Workflow Definition, neu durchgeführt werden.

Es empfiehlt sich die Migrations-Definitionen und damit den Test,-des Skriptes auf einem NetWorker 9 Test-Server vor dem eigentlichen Update durch-zuspielen.

Clients, die aus Ausschlussgründen nicht migriert werden konnten, werden in der Standard-Ausgabe des Programms aufgeführt. Zusätzlich wird bei jedem Migrationslauf eine Debug-Datei geschrieben.

5.Fazit

Das hier beschriebene Migrations-Skript kann als Basis für NetWorker 9 Migrationen verwendet werden. Es ist aber keinesfalls sofort einsetzbar, sondern es muss immer eine kundenspezifische Definition der Auswahlattribute stattfinden.

In ungünstigen Fällen kann es auch sein, dass der hier beschriebene Ansatz, zur automatischen Umverteilung der Clients, bei einer Kunden-Umgebung gar nicht funktioniert, z.B. weil es keine brauchbaren Auswahlkriterien gibt.

Sollte auch bei Ihnen die Umstellung von NetWorker 8 auf 9 anstehen und sollten sie in ihrer Umgebung bisher hunderte von Gruppen definiert haben, so scheuen sie sich bitte nicht, uns für die Migrationsunterstützung anzusprechen. Ein unverbindliches Gespräch kostet erst mal nichts, kann ihnen aber sicher weiter helfen.

NetWorker besitzt seit der Version 7.3 einen eigenen Client-Update Mechanismus. Nun ist seit dieser Version doch schon einige Zeit vergangen und es scheint nicht verwunderlich, dass Maschinen die vielleicht in dieser Version inventarisiert wurden, mittlerweile nicht mehr existieren. Doch wie bekommt man diese "alten" Clients jetzt auch aus der NetWorker-Versions-Datenbank (Push-DB) entfernt?

Man kann natürlich erstmal fragen, warum sollte man die denn entfernen wollen? Dazu kurz folgende Zusatzinformation:

Mit Hilfe des nsrpush Kommandos kann man leicht alle NetWorker Clients eines NetWorker Servers auf eine neue Version updaten. Hierzu dient die nsrpush Option 'all'.
Hat man aber seit dem letzten Inventory einen oder mehrere NetWorker-Clients gelöscht, so erhält man vom nsrpush die nette Meldung:
"Skipping client 'old_client' because it is no longer configured with this server"

Wie bekommt man aber jetzt diesen gelöschten Client aus der Push-DB?
Der nsrpush selbst bietet einem hierzu leider keine Option.
Wenn man aber weiß, dass die Push-DB eine NetWorker-RAP Database ist, läßt sich das relativ leicht mit dem 'nsradmin' Kommando bewerkstelligen.
Man benötigt folglich "nur" noch den Ressource-Namen und ein eindeutiges Attribut zum Löschen der zugehörigen Ressource.
Hier der passende Kommando Aufruf:

echo ". type: NSR installed Software; name:  old_client
           delete " | nsradmin -i - -d /nsr/res/cpdb

Wie schon lange von Fujitsu und EMC versprochen hat der neue NetWorker Version 8.0 so ziemlich alle Fujitsu NetWorker Erweiterungen erhalten. Ja - auch das Firewall Modul ist jetzt im NetWorker 8 vorhanden - auch wenn dieses nicht explizit von EMC erwähnt wird.

Damit hat der EMC NetWorker 8 alle nötigen Funktionen, so dass einer Migration der NetWorker Version von FTS zu EMC nichts mehr im Wege stehen sollte.

Hier noch einmal eine Auflistung der wichtigsten nun integrierten FTS Features:

• Firewall Modul
• scm_filter
• "server network interface" Attribute für Devices und Jukeboxen
• compression directive (gzip, bzip2)
• automatisches Rollover der daemon.raw
• Beruhigen eines NetWorker Servers:
  • "accept new session" Attribute

Diese Liste erhebt natürlich keinen Anspruch auf Vollständigkeit, sollte aber die wichtigsten Punkte enthalten.

Sollten SIe Fragen zur Migration von NetWorker-FTS zu NetWorker 8 von EMC haben, so scheuen Sie sich nicht uns per E-Mail zu kontaktieren. Nähere Informationen zur Umstellung, inklusive Aufzeigen eines Migrationsweges, erhalten sie auch in unserem NetWorker 8.0 Update Workshop