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.

Die NetWorker Version 9.0.1 hat als wesentliche Änderung ein REST-API erhalten. Diese mittels HTTPS erreichbare Programmschnittstelle wird vom NetWorker eigenen Authorisation-Server über dessen TCP-Port zur Verfügung gestellt. Diese Schnittstelle bietet nun die Möglichkeit, von jedem beliebigen Rechner (auch nicht NetWorker-Instanz) Abfragen zu stellen, Ressourcen zu generieren aber auch Workflows zu starten. Hierzu bedarf es allerdings der Kenntnis einer NetWorker-Administrator Kennung nebst dessen Passwort.

EMC hat für die REST-API Schnittstelle 2 neue Handbücher herausgegeben

• docu71091_NetWorker-9.0.1-REST-API-Getting-Started-Guide.pdf

• docu71092_NetWorker-9.0.1-REST-API-Reference-Guide.pdf

Nur leider sind beide nicht besonders selbst erklärend.

Ich habe nun einige Stunden in das Thema investiert und konnte schon mal die Funktionalität des alten „savegroup -v“ Kommandos nach-implementieren. Auch eine erste Version eines Kommandos zur nachträglichen Erzeugung einer ASCII-Completion-Message ist entstanden (zu den beiden Tools wird es in kürze einen eigenen Blog geben).

Beide Tools können Sie von uns erhalten, schreiben Sie einfach eine Mail an den Autor.
Oder sie besuchen einer der nächsten NSR9-Workshops im Hause qSkills. Hier können sie selbst einen tiefereren Einblick in die API Schnittstelle erhalten und die beiden Tools (nsr_api_start_workflow und nsr_api_get_jobinfo) live ausprobieren.

Fazit:

Die neue NetWorker REST-API Schnitstelle ermöglicht es mit jeder Programmiersprache die Konfiguration von NetWorker Ressourcen in beliebige Abläufe zu integrieren. Wenn auch die Schnittstelle etwas gewöhnungsbedürftig ist, steht einer Automatisierung der Backup Tätigkeiten auch mit NetWorker 9 jetzt nichts mehr im Wege!

Sollten sie einen Bedarf nach einem Automatisierungsskript haben und keinen eigenen Programmierer zur Hand, so scheuen sie sich bitte nicht den Autor, zu kontaktieren.

Oracle-NMDA Backups in großen NetWorker Umgebungen

Die Konfiguration einer NetWorker Oracle-Backup Umgebung hat sich durch die Einführung des NetWorker Moduls für Database Applications (NMDA) und dem zugehörigen NMC-Wizzard, auf den ersten Blick stark vereinfacht. Betrachtet man die Konfiguration aber in Umgebungen mit einer hohen zweistelligen, oder gar dreistelligen Zahl von Datenbanken, so macht sowohl die Migration bestehender Konfigurationen, als auch die Pflege der Oracle-RMAN-Skripte mit dieser Art der Datenbanksicherung-Konfiguration wenig Spass. Der Pflegeaufwand und der potentielle Wildwuchs der verwendeten RMAN-Skripte und NetWorker Konfigurationen wuchert doch sehr schnell aus.

Genau vor diesem Problem Stand ein Kunde bei der anstehenden Umstellung der Oracle-Datenbanksicherungen vom ehemaligen NMO Modul auf das aktuelle NMDA Modul. Die Anzahl der zu sichernden Datenbanken lag im dreistelligen Bereich. Es sollte also eine Möglichkeit gefunden werden,

• die Umstellung des Datenbankmoduls möglichst einfach zu gestalten.
• sowohl den Update-Vorgang des  NetWorker-Clients als auch des Datenbankmoduls zu automatisieren.
• die NetWorker Ressourcen automatisch vom alten Modul auf das neue Modul anzupassen.
• den anschließenden Pflegeaufwand der Datenbanksicherungskonfigurationen und der RMAN-Skripte zu minimieren.

Klingt auf den ersten Blick ziemlich unmöglich. Doch mit der richtigen Systemumgebung und einigen geschickten Randbedingungen war eine Idee ziemlich schnell gefunden und die Implementierung der Lösung war dann sogar relativ einfach.

Hier eine kurze Beschreibung der Randbedingungen und der implementierten Lösung:

Systemumgebung:

1. Alle Datenbanken befinden sich auf LINUX/UNIX Systemen
2. Die zu installierenden Software-Pakete befinden sich auf einem für alle Maschinen zugänglichen NFS-Share.
3. Es existiert eine sichere (gespiegelte) NFS-Umgebung auf der ein Share angelegt wird, der auf allen Datenbankmaschinen gemountet werden kann.

Randbedingungen:

1. Die Oracle RMAN-Skripte lassen sich durch die Verwendung einiger Oracle-Parameter für alle Datenbanken einer Oracle-Version verwenden.
2. Die NetWorker Ressource-Namen der Gruppen-, Schedule und sonstigen Ressourcen müssen standardisiert sein.
3. Der Save-Set des Clients definiert die Sicherungs-Parameter (Oracle-SID, RMAN-Sicherungstyp (Archive, Full, Level, ...))

Implementierte Lösung

Shell und Python-Skripte

Die Lösung des Problems bestand neben dem Aufbau einer geschickten Datenablage, in der Implementierung folgender Skripte:

1. Migrationsskript, das auf einer Oracle-DB-Maschine
   
   • die bestehende NetWorker-Umgebung analysiert
   • die "alten" NetWorker Pakete deinstalliert 
   • die "neuen" definierten NetWorker Pakete installiert
   • die alten NetWorker Ressourcen deaktiviert
   • neue NetWorker Ressourcen erzeugt
   • die Oracle-Backup-Library verlinkt
   • das Backup-Command verlinkt
   • den NFS-Mount des NFS-Ablageverzeichnisses in die /etc/fstab integriert
2. NetWorker Backup Command, das
   • anhand des übergebenen SaveSets, das definierte RMAN-Skript mit den benötigten Parametern aufruft.
   • das Rollieren der "alten" Backup-Protokolle durchführt

NFS-Ablage

Die gemeinsam genutzte NFS-Freigabe enthält folgende Datenstruktur:

1. Ein eigenes Verzeichnis für jede Datenbank mit dem Namen der Oracle-SID,  in dem neben einer Konfigurationsdatei  die Protokolle der Sicherungen und Wiederherstellungen abgelegt werden.
2. Ein Binarie-Verzeichnis, in dem die gemeinsam genutzten RMAN-Skripte und das implementierte NetWorker-Backup-Kommando liegen.

Fazit

Welche Vorteile bringt die implementierte Lösung?

• Leichtere Wartung der RMAN-Skripte. Nur noch wenige zentral abgelegte Skripte werden benötigt.
• Leichtere Fehlersuche, da bei Problemen die Protokolle und Konfigurationen von funktionierenden und fehlerhaften Sicherungen auf jeder Maschine direkt verglichen werden können. Ein mühsames Anmelden des NetWorker Administrators auf der jeweiligen Datenbankmaschine ist nicht mehr notwendig.
• Übersichtlichere NetWorker Konfiguration. In der Client-Ressource definiert alleine der SaveSet die Art der Oracle-Sicherung.
• Einfache und fehlerfreie Migration der alten NetWorker-Client Umgebungen in die neue NMDA-Umgebung.

Sollten sie Fragen zu diesem Blog haben oder vor ähnlichen Herausforderungen stehen, so scheuen sie sich bitte nicht sich per E-Mail an info@schaefer-tobies.de zu wenden.