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.

Bei einem unserer Kunden war der Wartungsvertrag für die NetApp VTL abgelaufen. Eine Verlängerung wäre unverhältnismäßig teuer gewesen. Außerdem war die Kapazität des Systems auch schon an seine Grenzen gestoßen. Da der Großteil der Daten des Kunden auf NetApp Primary Systemen lag oder darauf umgezogen werden sollte, viel die Entscheidung für eine Ablösung auf eine Kombination von 2 NetApp Nearstore Systemen und Advanced File Devices mit einer Bandsicherung für Langzeitsicherungen.

Auf die beiden Nearstore Systeme, die sich an 2 unterschiedlichen Standorten befinden, werden die Sicherungen der Oracle und VMware ESX Backups, sowie die auf den NetApp befindlichen Nutzerdaten mittels des NetApp Produktes SnapVault auf die erste NetApp gesichert. Diese Backup Volumes werden zyklisch mit dem Produkt SnapMirror auf die 2'te Nearstore in einen entfernten Standort gespiegelt. Da der Kunde schon seit einiger Zeit unsere Backup-Lösungen SBint-O und SBint-VM einsetzt, konnte die Sicherung der Oracle Datenbanken und der VMware-ESX-Datastores weiterhin mit NetWorker gestartet und überwacht werden. Die anfallenden Oracle-Archivelog Dateien werden mit SBint-O vom Primary Storage auf die erste Nearstore verdrängt. Jetzt fehlte nur noch eine entsprechende Integration der auf NetApp gehosteten Benutzerdaten. Hierfür gab es jedoch auch bereits eine Lösung unserer SBint-Backup-Tools. Denn auch hierfür kann man mit Hilfe eines NetWorker-Clients und einer zugehörigen NetWorker-Gruppe die Sicherung eines NetApp Volumes von einem Storage-System zum zweiten starten und überwachen. Selbstverständlich werden auch diese Sicherungen in unserer SBint-WWW-Oberfläche visualisiert (siehe auch hier).

Was jetzt noch fehlte, waren eine integrierte Sicherungslösung ganzer virtueller Filer-Umgebungen, sowie eine einfache Möglichkeit die benötigten Volumes und SnapVault- bzw. SnapMirror-Beziehungen automatisiert anzulegen. Jeder virtuelle Filer besitzt mehrere NetApp-Volumes. Diese sollten auf den sekundären Systemen alle die gleiche Aufbewahrungsfristen erhalten. Hierfür wurde unsere SBint-Backup-Lösung kurzerhand um eine entsprechende Funktion erweitert. Ein neuer Parameter in der Konfigurationsdatei definiert welche primären NetApp-Volumes auf einem gemeinsamen sekundären Ziel-Volume gesichert werden sollen. Das Sicherungskommando startet entsprechend bei einer durch NetWorker getriggerten Sicherung den SnapVault-Abgleich aller definierten Volumes auf ein gemeinsames Ziel-Volume. Nach der erfolgreichen Übertragung aller Volumes wird auf dem Nearstore-Volume ein gemeinsamer Snapshot erzeugt, der von unserer Backup-Integration nach der definierten Retentionzeit auch wieder entfernt wird. Jetzt fehlte nur noch ein komfortables Tool, dass die auf den Nearstores benötigten Volumes automatisiert anlegt und die für die Sicherung benötigten Snapshot-Beziehungen konfiguriert. Entstanden ist ein kleines Programm, dass im nächsten Blog beschrieben wird.