Entgegen der leider schon des öfteren gehörten Aussagen „das geht nicht“, zunächst mal die gute Nachricht es geht! Es geht zwar nicht mit der NetWorker Management Console, aber mit den NetWorker Kommandos „recover“ und „nsrndmp_recover“ geht es sehr gut. Und das sowohl mit der NetWorker Version 8.2.4.x und natürlich auch mit der aktuellen NetWorker Version 9.2.x.

Es gibt jedoch 2 kleine Stolpersteine, die sich aber leicht aus dem Weg räumen lassen ;-)

1. Beim Aufruf der „recover“-Kommandos benötigt man 2 Optionen

-c <7-Mode Client-Name>

-R <C-Mode-Cluster-Name>

Beispiel:

# recover -c na_82 -R na_93

Die erste Option erklärt sich von selbst, aber die zweite muss entgegen dem vielleicht erwarteten SVM-Namen, den Namen des C-Mode-Clusters enthalten. Oder vielleicht besser gesagt den Namen der StorageNode der zu verwendenden NDMP-Devices.

Nach dem Aufruf des Kommandos können die wiederherzustellenden Dateien wie gewohnt ausgewählt werden.

2. Relocate auf einen virtuellen Storage auf der C-Mode Maschine

Für den Relocate der wiederherzustellenden Daten benötigt man einen Pfad aus Sicht des C-Mode Cluster-Servers. D.h. ein Relocate sieht syntaktisch folgendermaßen aus:

> relocate /<SVM-Name>/<Volume-Name>[/<Pfad auf dem Volume>]

Beispiel:

recover> relocate /na_93_cifs/recover/uws

Hierbei ist der Name „na_93_cifs der Name eines virtuellen Storage-Systemes (SVM)

Berücksichtigt man diese beiden Besonderheiten beim Aufruf, bzw. bei der Verwendung des Kommandos, sollte einem Recover von „alten“ NetApp-7-Mode Daten auf eine neue C-Mode Maschine nichts mehr im Wege stehen.

Wenn sie nähere Informationen zum Thema NetWorker und/oder NDMP Backup mit NetWorker benötigen, so scheuen sie sich nicht eine Mail an den Autor zu senden. Oder besuchen sie unseren NetWorker Advanced Workshop.

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.