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.

NetApp C-Mode NDMP Backup,

lange viel zu lange gab es keinen Blog mehr zum Thema NetWorker und NetApp.
Aus einem meiner letzten Projekte weiß ich allerdings, dass hier erheblicher Aufklärungsbedarf besteht. NDMP Cluster Aware Backup (CAB) ist eben doch etwas anderes, als NetApp 7-Mode Backup. Aber mal der Reihe nach!

Mit der NetApp C-Mode OS-Version führte NetApp eine neue NDMP-Erweiterung ein. Das sogenannte CAB. Es gibt zur Zeit 2 NDMP-Backup-Methoden zum sichern von NetApp-Volumes mit dem NDMP Protokoll. Den „Node Scoped Mode“ und den „SVM Scoped Mode“.
Der „Node Scope Mode“ entspicht in etwa der alten 7-Mode NDMP-Backup Methode. Dieser Mode funktioniert zwar noch, ist allerdings abgekündigt und birgt insbesondere bei NetApp-Cluster-Umschaltungen oder bei der Migration eines Virtuellen-Storage-Managers zu Index-Problemen. Diesen Modus muss man in den aktuellen NetApp-OS Versionen auch explizit aktivieren. Default ist der neue CAB Mode.

Welche Vorteile bringt der CAB Mode?
In NetApp-C-Mode besteht die größte Neuerung in der unterbrechungsfreien Migration eines virtuellen Storage-Managers mit allen Daten und Netzwerk-Verbindungen von einem physikalischen Knoten auf einen anderen. NetApp bezeichnet dieses Betriebssystem ja auch als „Never Down System“. Denn selbst bei einem Hardware-Tausch soll es dem Anwender ermöglicht werden, seinen kompletten Storage im laufenden Betrieb von einer Hardware auf eine andere umzuziehen. Demzufolge muss auch das Backup die harte Kopplung zwischen den zu sichernden Volumes und den Hardware-Knoten verlieren. CAB ermittelt automatisch welche Tape-Laufwerke im C-Mode-Cluster für die Sicherung eines Volumes zur Verfügung stehen und leitet die zu sichernden Daten automatisch an ein passendes Laufwerk. Kommt bei der Migration eines neuen NetApp Knotens folglich neue Tape-Hardware hinzu, so muss in der Backup Applikation lediglich die neue Tape-Hardware konfiguriert werden. Die Zuordnung der Sicherungen zu diesen Geräten erfolgt bei einer korrekten Konfiguration dann automatisch.

Spätestens seid NetWorker Version 8.2.3 kann man nun beruhigt den CAB-Mode verwenden. Es gibt zwar noch ein kleines Problem, dazu unten mehr, aber keinen Grund mehr den „alten“ Node Scoped Mode zu verwenden. Doch auch hier kann man das Thema von zwei Seiten angehen. Entweder man konfiguriert die Cluster-VSM als NetWorker-Client oder die einzelnen VSMs selbst. Die erstere Variante funktioniert zwar immer, birgt aber wieder Index-Probleme. Denn wenn das NetApp-Storage-System als Metro-Cluster ausgelegt ist, so werden beim Umschaltvorgang zwar die VSMs auf die andere Metro-Cluster-Seite umgezogen und sind somit unter den „alten“ Netzwerk-Adressen bekannt und erreichbar. Die Cluster-VSM ist in diesem Moment aber eine andere Maschine mit anderen Adressen und anderen NDMP-Komponenten. Eine Sicherung und auch eine Wiederherstellung sind in diesem Falle nicht einfach möglich. Eine Sicherung birgt sogar die Gefahr, dass die Index-Informationen in einem anderen NetWorker-Client-Index landen und somit keine konsistente Sicherung mehr gegeben ist. Dies sieht bei der Verwendung der VSMs ganz anders aus. Hier muss bei einem Umschaltvorgang höchstens das Client-Attribut StorageNode in der  NetWorker Konfiguration angepasst werden. Der Client und dessen Volumes behalten aber eine konsistente Sicherungshistorie. Ein weiterer eventueller Vorteil der Verwendung des VSMs als NetWorker Clients besteht darin, dass man bei diesem auch den SaveSet Namen „All“ verwenden kann. NetWorker löst in dieser Konfiguration „All“ in alle zum, VSM gehörige Volumes auf!

Meines Erachtens ist somit die zweite Variante (Konfiguration der VSMs als NetWorker Clients) ganz klar der Cluster-Server Variante vorzuziehen. Leider birgt die Konfiguration dieser Variante noch 2 kleine Stolpersteine, die anscheinend zur irrigen Meinung geführt hat, dass diese Variante nicht zu empfehlen sei.
1. Man muss in diesem Falle das NDMP Protokoll für jede VSM extra aktivieren und für jede VSM einen eigenen NDMP-Benutzer definieren.
2. Die VSM muss ein Netzwerk-LIF in einem Netzwerk besitzen, das sich im selben Subnetz befindet wie ein Management- oder ein Intercluster-LIF des zugehörigen Cluster-Nodes.

Beide Voraussetzungen werden auch benötigt, wenn man das NDMPCOPY Protokoll für eine Datenübertragung zwischen den VSMs verwenden möchte.


Fehlt noch das oben angesprochene Problem bei der Verwendung des CAB-Modes allgemein. Wenn bei der Sicherung mit CAB ein Bandwechsel nötig wird (das erste Medium ist voll) und sich das hierfür ausgewählte Tape-Laufwerk an einem anderen physikalischen Cluster-Node befindet, schafft es der sichernde NetWorker-“nsrmmd“ Prozess nicht, die Kommunikation zu diesem NDMP-Tape-Server aufzubauen. Wird ein anderes Laufwerk auf dem selben physikalischen Node wie zuvor verwendet, funktioniert die Sicherung einwandfrei. Dies ist ganz offensichtlich ein NetWorker Bug, der auch bereits von mindestens einem Kunden gemeldet wurde. Bisher existiert allerdings nur der folgende Workaround:
    „Einschränkung der verwendeten Pools auf die Laufwerke eines physikalischen Nodes“.

Nachtragvom 02.08.2017: Das Problem ist im EMC Knowledge Base Artikel 000484876 beschrieben. Die Lösung ist auch hier der von mir beschriebene Workaround ;-/.

FAZIT:
Man kann sowohl mit NetWorker 8.2 als auch mit NetWorker 9.1 NetApp C-Mode-Cluster mit dem CAB konfigurieren und fehlerfrei sichern. Hierbei ist m.E. die Konfiguration der VSMs als NetWorker Clients zu favorisieren.

Sollten sie mehr zu diesem Thema wissen wollen, so kann ich ihnen zum einen unseren NetWorker Admin III Workshop bei der Firma qSkills in Nürnberg empfehlen, oder sie lassen sich direkt von uns zum Thema beraten.

Die lange ersehnte NetWorker Version 9.1 steht seit dem 23. Dezember 2016 auf der EMC-Support Seite zum Download zur Verfügung.

Update: 10.02.2017

Die Version 9.1 wurde lange von vielen Kunden ersehnt. Ich habe immer wieder gehört, wir warten vor dem Update auf die Version 9 auf die Version 9.1. Auch von Seiten der EMC wurde immer auf diese Version hingewiesen für die best-mögliche Umstiegsversion. Nun ist sie da, und es stellen sich zwei Fragen: was ist neu an dieser Version, warum kann man den Umstieg von der Version 8 auf die Version 9 jetzt leichter bewältigen?

Hier ein paar Antworten zu diesen Fragen:

1. Was ist neu?

   1. VMware Backup die 3'te.

      Mit der NetWorker Version 8.x wurde die VMware Backup Appliance als neues revolutionäres Backup für die VMware basierten virtuellen Maschinen eingeführt. Diese Art der Sicherung über ein Block-orientiertes Verfahren (CBT) mit einer „inkrementell vor Ever“ Technik, war wirklich ein Riesenschritt nach vorne. Hier die wesentlichen Vorteile:

      1. Die Backup-Zeiten wurden auf einen Bruchteil der vorher nötigen VADP-Backup-Zeiten zusammengeschrumpft.

      2. Das zu transferierenden Sicherungsvolumen wurde durch ein auf dem CBT Verfahren aufsetzendes Sichern der veränderten Blöcke marginalisiert. Vor allem wenn man zusätzlich die Verwendung der DataDomain Boost Technik mit einer Deduplizierung innerhalb der VBA mit betrachtet.

      3. Die Zeiten für die Wiederherstellung einer virtuellen Maschine wurde erheblich verringert. Denn auch hier wurde das Datenvolumen, das für die Wiederherstellung einer virtuellen Maschine übertragen werden muss, durch die Verwendung der CBT Technik minimiert

      4. Durch die Einführung des Instant-Recover, einzelner Maschinen auf dem DataDomain-Backup-Storage, ist auch das Testen eines Sicherungsstandes einer virtuellen Maschine in kürzester Zeit realisierbar.

      5. Die Wiederherstellung einzelner Dateien (FLR-Recover) wurde ebenfalls stark verbessert.

      Allerdings gab es in der VBA Technik einen großen Nachteil! Dieser Bestand in der Verwendung der VBA selbst. Innerhalb dieser virtuellen Maschine ist ein Avamar- Server integriert, der auf der einen Seite mit dem VMware-Vsphere Server und auf der anderen Seite mit dem NetWorker-Server kommuniziert. Diese Sicherungsinstanz hatte jetzt außerhalb des NetWorker-Servers Sicherungsinformationen in einer eigenen Datenbank. Die guten alten NetWorker Regeln „Single Point of Administration“ und „Single Point of Information“ war hierdurch verletzt. Die Praxis zeigte in den letzten Jahren, dass genau diese Verletzung immer wieder zu großen Problemen führte. So gingen immer mal wieder in der Dreierbeziehung zwischen NetWorker, Avamar und Vsphere einige Informationen verloren, die dann zwangsläufig zu Fehlern führten.

      Mit der Version 9.1 ist dieser Malus verschwunden!

      NetWorker hält jetzt wieder alle Informationen und Aktionen allein und selbst in der Hand. Die VBA wird nicht mehr benötigt! Stattdessen werden jetzt für die Sicherung der virtuellen Maschinen lediglich sogenannte vProxy Appliances eingeführt. Diese virtuellen Maschinen kann man sich als reine Data-Mover, ähnlich einer NetWorker-StorageNode vorstellen. Sie bewegen die Daten von dem VMware-Storage mit Hilfe des DataDomain-Boost Protokolls auf einen DataDomain Backup-Storage. Alle Informationen über die Sicherungen und die Initiierung der Sicherungen und Wiederherstellungen können vom NetWorker-Server, der NMC oder direkt von der Vsphere WWW-Oberfläche ausgeführt werden.

       

      Fazit zum Thema VMware Backup:

      Mit der Version 9.1 ist die Sicherung der virtuellen VMware-Maschinen auf der Basis der oben beschriebenen Vorteile auf eine solide und wesentlich robustere Technik gehoben worden. Alle bekannten Probleme der NetWorker VBA Backup Lösung sollten somit erledigt sein.

      Alle Kunden, die sich heute noch mit der „alten“ VADP Sicherungstechnik herum schlagen, sollten sich nun ernsthaft überlegen, auf diese Art der Sicherung umzustellen.

   2. Cloud Boost Unterstützung

      Mit der NetWorker Version 9.1 und deren Clients ist jetzt auf aktuellen Linux Betriebssystemen ein direktes Backup in die Cloud möglich.

      Virtuelle Umgebungen die in einer Amazon EC2 Cloud gehostet werden, können jetzt mit NetWorker und einer Cloud-Boost Appliance auf einen Amazon S3 Storage gesichert werden.

   3. DataDomain Cloud-Tier Unterstützung

      • Integration der DataDomain Cloud Tier Unterstützung in die NetWorker Umgebung.

      • Die Version 9.1 unterstützt direktes Recover incl. GLR Recover von einem Cloud-Tier Storage.

   4. NetApp ONTAP 9 Unterstützung

      Mit der NetWorker Version 9.1 ist erstmalig der Support für NDMP mit ONTAP 9 enthalten.

2. Warum kann man jetzt leichter auf die Version 9 umsteigen?

   Um diese Frage beantworten zu können, sollte man vielleicht auf meinen Absatz in der News zum NetWorker 9.0 schauen. Hier hatte ich folgende Probleme für den Umstieg festgestellt:

   Zitat zum NetWorker 9.0

   ---

   Was fehlt an alten Funktionen:

   1. Es gibt kein savegrp Kommando mehr. Aber Backups lassen sich weiterhin mit dem CLI-Kommando nsrpolicy starten.

   2. Das Kommando nsradmin kann für die neuen Policys nicht verwendet werden. Auch hierfür kann stattdessen das neue CLI-Kommando nsrpolicy verwendet werden.

   3. Die Backup-Levels 2-9 sind Geschichte, es gibt nur noch den Level 1, Voll und inkrementelle Sicherungen.

Wie sieht es jetzt mit den obigen Punkten im NetWorker Version 9.1 aus?

Zu 1. Als Ersatz für das Kommando savegrp kann seit der Version 9.0.1.x das Kommando nsrworkflow verwendet werden. Dieses bietet einen fast vollständigen Ersatz.

Zu 2. Zusätzlich zum Kommando nsrpolicy steht seit der Version 9.0.1 ein recht umfängliches REST-API zur Verfügung. Mit dieser Programmierschnittstelle können alle bisher verwendeten nsradmin Skripte umgestellt werden.

Folgende von NetWorker 8 bekannten Features und Funktionen fehlen aber leider weiterhin:

• Die bereits oben in Punkt 3 genannten Level Sicherungen.

• Die fehlende Browse-Policy und damit größer werdende Index-Datenbanken

• Die geänderte Protokollierung und damit fehlende Savegroup-CompletionMessage, sowie die zugehörigen Tools nsrsggrpcomp und nsrscm_filter.

FAZIT:

Alles in allem kann man sagen, die NetWorker Version 9.1 hat nicht alle Features, die sich der ein oder andere zurück gesehnt hat, aber der Umstieg auf die neue Technik mit Policys und Workflows bringt dafür auch einige interessante neue Möglichkeiten. Ob sie auf die NetWorker Version 9.1 umsteigen wollen, oder ob sie auf die nächste Version warten, muss jeder Kunde für sich selbst entscheiden. Ein Zwang zum Update besteht zurzeit nur für Kunden die ihre Daten in die Cloud sichern wollen, oder die einen NDMP Support für NetApp 9 benötigen.

Sollten sie einen tieferen Einblick in die Version bekommen wollen, so kann ich ihnen nur den Besuch eines unserer nächsten NetWorker 9 Workshops im Hause qSkills empfehlen. Selbstverständlich helfen wir ihnen natürlich auch gerne beim Umstieg auf die neue Version. Sei es nun bei der Unterstützung des kompletten Update-Vorganges oder bei der Umstellung diverser Skripte auf das REST-API.