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.

Die Kontrolle eines NetWorker Workflow-Laufes wird bei den meisten Kunden über das menschliche Auge, sprich den Blick auf die NetWorker-Management-Console (NMC) erfolgen. Leider ist diese Art der Kontrolle fehleranfällig und bei der Analyse von Problemen sehr zeitaufwendig. Außerdem werden nicht unbedingt alle Probleme angezeigt und bleiben damit u.U. unerkannt.

Hier ein paar Beispiele für Probleme bzw. Fehler, die in der NMC mit einem grünen Hacken versehen werden bzw. wurden:

• fehlerhafte Clone-Jobs
• deaktivierte Clients (Client Attribut: scheduled backup)
• Datenbank-Sicherungen im Komprimierungsmodus

NetWorker protokolliert all diese Probleme in den Log-Dateien. Aber eine automatische Kontrolle der Dateien existiert zurzeit leider nicht! Erschwerend kommt hinzu, dass jeder einzelne Workflow-Job, sei es nun die Sicherung eines Filesystems, einer Windows Partition oder eines Datenbank-Logs, in einer eigenen Log-Datei landet. Einige Log-Dateien werden hierbei im Klartext abgelegt, andere sind nur im 'RAW'-Format vorhanden.

Ähnliche Probleme gab es auch schon im NetWorker 8. Hier gab es aber für die automatische Analyse der Sicherungsausgaben ein NetWorker eigenes Programm mit dem Namen scm_filter. Dieses ist mit dem Verschwinden der NetWorker Savegroup-Logik jedoch ebenfalls verschwunden. Kunden, die den SCM-Filter in der Version 8 im Einsatz hatten, beauftragten uns, einen Ersatz für die NetWorker Version 9 zu erstellen.

Das Ergebnis ist ein Programm, das auf Basis der NetWorker 9 REST-API Schnitstelle,  alle zu einem Workflow gehörigen Log-Dateien in einer neuen Log-Datei zusammenfasst und diese Datei anschließend mit Hilfe von definierbaren regulären Ausdrücken analysiert. Die Funktion des ehemaligen SCM-Filters konnte somit vollständig ersetzt werden.

Als weiteres Schmankerl kann  das Programm nun dazu verwendet werden, eine NetWorker 8 Savegroup Ausgabe zu emulieren. Dieses Feature ist für einen weiteren Kunden entstanden, der die NetWorker 8 Savegroup Ausgaben zur Analyse an ein Drittanbieter-Tool sendet und eine schnelle Integration der NetWorker 9 Meldungen benötigte.

Sollten sIe Interesse an diesem Programm haben, so können sie hier das Handbuch unserer REST-API Tools herunterladen. Hier ist der Einsatz des  entstandenen Tools mit dem Namen nsr_workflow_analyse ausführlich beschrieben.

Bei Fragen und ähnlichen Problemen, wenden sie sich bitte per E-Mail an den Autor des Artikels.

 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.

Wie bereits im letzten Blog beschrieben hat die NetWorker Version 9.0.1 ein REST-API erhalten. Dieses ermöglicht es nun NetWorker aus einer beliebigen Umgebung heraus zu Administrieren und zu Verwalten.

NetWorker konnte man bis zur Version 9 über sein Commad-Line-Interface (CLI) automatisieren und ihn so in jeden beliebigen externen Scheduler oder Batch-Job integrieren. Leider sind diese Möglichkeiten durch die im NetWorker 9 eingeführten Policys weitestgehend entfallen. Kunden, die den NetWorker wie bisher über ein externes Programm automatisieren möchten sind somit gezwungen, ihre Routinen auf die neue REST-API-Schnittstelle umzustellen.
NetWorker liefert hierbei aber eben nur die Schnittstelle, die Implementierung der gewünschten Funktionalitäten ist dem Anwender selber überlassen. Da dieses Unterfangen (Implementierung über REST-API) einen normalen Backup-Administrator meist überfordert, haben wir versucht zwei wesentliche Funktionen, Start einer Sicherung und Ermitteln des Sicherungsstatus, als fertige Kommandos zu implementieren. Diese Kommandos sind freilich nur Beispiele und sollen mehr oder weniger nur die Möglichkeiten der REST-API-Schnittstelle beispielhaft aufzeigen.

Die Kommandos:

nsr_api_start_workflow

Start eines NetWorker Workflows.

Usage:

nsr_api_start_workflow -i
nsr_api_start_workflow -a 
nsr_api_start_workflow -s <nsr-srv> [-v]* [-u <user>] [-p <password>] 
      -n <policy-name> -w <workflow> [-c <client>]*
  
  -i   interactive; Ask for all parameters

  -a   active; Parameters are defined in the 'local_defines.py' file

  -n   Policy name

  -w   workflow name

  -c   start only this client from workflow-group

  -v   verbose; Wait till the job finishes!

nsr_api_get_jobinfo

Ermitteln des aktuellen Status eines zuvor gestarteten Workflows.

Usage:

nsr_api_get_jobinfo -i [--wait] <workflow-jobid> 
nsr_api_get_jobinfo [-a] [--wait] <workflow-jobid>
nsr_api_get_jobinfo -s <nsr-srv> [-u <user>] [-p <password>] [--wait] <jobid> 
 
  -i      interactive; Ask for all parameters

  -a      active; Default: Parameters are defined in the 'local_defines.py' file

Common parameters:

  --wait  Job waits until all dependend jobs and the workflow job are finished

~

Da die Ausführung der Kommandos eine relativ aktuelle SSL Umgebung benötigt, die noch nicht mal auf einem SuSE SLES 12.0 standardmäßig gegeben ist, haben wir uns dazu entschlossen, die Kommandos als fertige Pakete mit binär ausführbaren Dateien und nicht als Skripte zur Verfügung zu stellen. Die zurzeit existierenden Pakete sind ausführbar auf einem Windows x64 System (ab Windows7) oder einem Linux System mit einer GLIBC_2.14 oder neuer. Letzteres ist zum Beispiel auf einem SuSE-SLES 12.x oder einem Ubuntu 14.04 gegeben.

Die vollständige Dokumentation mit Installationsanleitung können sie hier herunterladen, die Pakete für Windows und Linux erhalten sie auf Anfrage beim Autor.

Sollten sie ein ähnliches NetWorker Automatisierungsprogramm benötigen, scheuen sie sich bitte nicht den Autor zu kontaktieren. Wir können ihnen bestimmt weiter helfen.