Automatische Generierung von NDMP SaveSet Namen

Ein Kunde hatte das Problem, dass die Sicherungszeit eines NetApp-Volumes mit ca. 40 TB Größe, mehrere Tage betrug. Außerdem waren die Wiederherstellungszeiten für einzelne Dateien aus diesen Sicherungen inakzeptabel.

Eine einfache Parallelisierung der Verzeichnisse von Hand war leider nicht möglich, da sich bereits auf der obersten Verzeichnisebene mehr als 8000 Unterverzeichnisse befanden. Erschwerend kam hinzu, dass jederzeit auch neue Unterverzeichnisse von den Fachabteilungen angelegt werden können. Diese müssen natürlich auch bei der nächsten anstehenden Sicherung mitgesichert werden.

Es stellte sich folglich das Problem: wie kann man die Sicherung des Volumes parallelisieren, ohne Gefahr zu laufen, neu angelegte Verzeichnisse nicht zu sichern.

Die Lösung bestand in der Programmierung eines Python-Skriptes, das mit Hilfe der Schäfer & Tobies eigenen NetApp-Ontapi-Python Schnittstelle und dem NetWorker-REST-API, täglich die NetWorker Client-Ressourcen automatisiert neu generiert.

Das Skript liest hierzu zunächst alle Unterverzeichnisnamen des Volumes per API aus und verteilt die erhaltenen Namen anhand einer Konfigurationstabelle und den Anfangsbuchstaben auf „n“ definierte NetWorker-Client-Ressourcen. Jede dieser NetWorker Client-Ressourcen verwendet einen eigenen Schedule, so dass auch eine Verteilung der Vollsicherungen über die Wochentage erfolgt.

Das Ergebnis konnte sich sehen lassen, die Sicherungszeiten waren wieder im vertretbaren Rahmen (unter 24 Stunden) und auch die Wiederherstellungszeiten sind um ein vielfaches schneller als zuvor.

Sollten Sie ein ähnliches Problem in ihrer Sicherungsumgebung haben, so scheuen Sie sich nicht, den Autor zu kontaktieren. Eine automatisierte und damit sichere Generierung der NetWorker-Ressourcen garantiert auch Ihnen, dass ihre wichtigen Daten immer in der aktuellen Sicherung enthalten sind. Der Aufwand für die Erstellung der benötigten Skripte hält sich in überschaubaren Grenzen und sollte damit auch für ihre Firma erschwinglich sein.

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.

Ein Kunde hatte vor einigen Jahren Sicherungen bzw. Archivierungen mit NetWorker auf damals aktuelle Tandberg 9840B und T10000 Medien gespeichert. Die Sicherungen haben zum Teil Sperrfristen von bis zu 30 Jahren. Im Rahmen des endgültigen Abbaus der „veralteten“ Laufwerke sollten diese Sicherungen auf neue aktuelle Medien migriert werden.

Klingt erst mal ganz einfach. NetWorker kann ja seine Sicherungen ohne Probleme von einem Medium auf ein anderes Clonen. Eigentlich sollte ich nur für eine möglichst weitgehende Automatisierung der Migration sorgen. Aber wie so oft lag auch hier mal wieder die Tücke im Detail. Daher möchte ich hier kurz die aufgetretenen Probleme beschreiben.

Folgende unerwartete Probleme kamen zu Tage:

• Die Tandberg 9840B Laufwerke ließen sich weder an einem aktuellen Linux noch an einem NetApp C-Mode Storage-System verwenden. Die aktuellen Treiber konnten mit den alten Laufwerken nicht mehr arbeiten. Kaum zu glauben aber wahr.

• NetApp NDMP Band-Sicherungen lassen sich nur über ein NetApp System auf neue Hardware clonen. An den aktuellen Storage-Systemen waren aber gar keine Bandlaufwerke mehr vorgesehen. Hier musste folglich ein „altes“ NetApp 7-mode System wieder aktiviert werden, um die Daten von den alten Medien lesen zu können.

• Zwei der für das Wiederherstellen benötigten Solaris-Systeme brachen während der Cloning Aktivitäten, wegen Hardwareproblemen zusammen. Bis zu diesem Einsatz liefen sie ja nur noch im Standby-Modus. Jetzt wo die Hauptspeicher und lokalen Platten mal wieder aktiv benötigt wurden, kamen die schwelenden Hardware-Fehler zum Vorschein!

Fazit:

Lassen sie es erst gar nicht so weit kommen. Sollten auch bei ihren Sicherungen lange Aufbewahrungszeiten verwendet worden sein, so überprüfen sie rechtzeitig und regelmäßig, ob die damals verwendeten Medien in der aktuellen Umgebung noch lesbar sind.

Der Hersteller hat die Lesbarkeit der Medien auf „n“ Jahre garantiert, sie haben die Sicherungen auch in doppelter Ausführung vorhanden, aber haben sie auch eine lauffähige Maschine mit der sie die Daten lesen können?

Wollen sie mehr über dieses Projekt erfahren, oder haben sie ähnliche Aufgaben und möchten diese weitgehend automatisiert haben, so wenden sie sich bitte an den  Autor, oder rufen sie uns unter der

+49 8250 92903

an.