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.

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.