Wie bereits im letzten Blog beschrieben hat die NetWorker Version 9.0.1 ein REST-API erhalten. Dieses ermöglicht es nun NetWorker aus einer beliebigen Umgebung heraus zu Administrieren und zu Verwalten.

NetWorker konnte man bis zur Version 9 über sein Commad-Line-Interface (CLI) automatisieren und ihn so in jeden beliebigen externen Scheduler oder Batch-Job integrieren. Leider sind diese Möglichkeiten durch die im NetWorker 9 eingeführten Policys weitestgehend entfallen. Kunden, die den NetWorker wie bisher über ein externes Programm automatisieren möchten sind somit gezwungen, ihre Routinen auf die neue REST-API-Schnittstelle umzustellen.
NetWorker liefert hierbei aber eben nur die Schnittstelle, die Implementierung der gewünschten Funktionalitäten ist dem Anwender selber überlassen. Da dieses Unterfangen (Implementierung über REST-API) einen normalen Backup-Administrator meist überfordert, haben wir versucht zwei wesentliche Funktionen, Start einer Sicherung und Ermitteln des Sicherungsstatus, als fertige Kommandos zu implementieren. Diese Kommandos sind freilich nur Beispiele und sollen mehr oder weniger nur die Möglichkeiten der REST-API-Schnittstelle beispielhaft aufzeigen.

Die Kommandos:

nsr_api_start_workflow

Start eines NetWorker Workflows.

Usage:

nsr_api_start_workflow -i
nsr_api_start_workflow -a 
nsr_api_start_workflow -s <nsr-srv> [-v]* [-u <user>] [-p <password>] 
      -n <policy-name> -w <workflow> [-c <client>]*
  
  -i   interactive; Ask for all parameters

  -a   active; Parameters are defined in the 'local_defines.py' file

  -n   Policy name

  -w   workflow name

  -c   start only this client from workflow-group

  -v   verbose; Wait till the job finishes!

nsr_api_get_jobinfo

Ermitteln des aktuellen Status eines zuvor gestarteten Workflows.

Usage:

nsr_api_get_jobinfo -i [--wait] <workflow-jobid> 
nsr_api_get_jobinfo [-a] [--wait] <workflow-jobid>
nsr_api_get_jobinfo -s <nsr-srv> [-u <user>] [-p <password>] [--wait] <jobid> 
 
  -i      interactive; Ask for all parameters

  -a      active; Default: Parameters are defined in the 'local_defines.py' file

Common parameters:

  --wait  Job waits until all dependend jobs and the workflow job are finished

~

Da die Ausführung der Kommandos eine relativ aktuelle SSL Umgebung benötigt, die noch nicht mal auf einem SuSE SLES 12.0 standardmäßig gegeben ist, haben wir uns dazu entschlossen, die Kommandos als fertige Pakete mit binär ausführbaren Dateien und nicht als Skripte zur Verfügung zu stellen. Die zurzeit existierenden Pakete sind ausführbar auf einem Windows x64 System (ab Windows7) oder einem Linux System mit einer GLIBC_2.14 oder neuer. Letzteres ist zum Beispiel auf einem SuSE-SLES 12.x oder einem Ubuntu 14.04 gegeben.

Die vollständige Dokumentation mit Installationsanleitung können sie hier herunterladen, die Pakete für Windows und Linux erhalten sie auf Anfrage beim Autor.

Sollten sie ein ähnliches NetWorker Automatisierungsprogramm benötigen, scheuen sie sich bitte nicht den Autor zu kontaktieren. Wir können ihnen bestimmt weiter helfen.

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.

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.

Der Storage-Markt ist in Bewegung. Neben den etablierten Platzhirschen wie EMC, IBM, Hitachi und NetApp gibt es einige neue Markteilnehmer, die versuchen mit neuen Ideen und Produkten im Markt Fuß zu fassen.

Einer dieser neuen Wilden ist Tintri. Tintri hat sein Storage Produkt als VAS "Virtual Aware Storage" implementiert. Soll heißen: Das Storage-System kennt den Virtualisierungs-Service und alle virtuellen Maschinen auf dem Storage und ermöglicht es so, die Storage-Performance und die Latency leicht pro virtueller Maschine zu überwachen und einzustellen.

Tintri bietet 2 Storage Varianten an: Hybrid-Flash und All-Flash. Auf beiden Varianten werden die Daten dedupliziert und komprimiert und dennoch ist das Storage-System im Vergleich zum Mitbewerb um ein mehrfaches schneller.

Genug der Vorrede kommen wir zum Thema: selbstverständlich bietet das Storage-System auch lokale Snapshots. Diese können entweder Crash- oder VM-Konsistent erstellt werden. Das Erzeugen der Snapshots kann entweder per Tintri eigenem Scheduler, per Hand oder über ein API erfolgen. Die Herausforderung bestand nun darin einen Storage-Snapshot eines LINUX-System per Kommando an eben diesem LINUX-System, als eigene(s) Filesystem(e) sichtbar zu machen. Entstanden ist ein "kleines" Python-Skript, dass genau diese Aufgabe erfüllt. Genauerer Informationen und das Tool selbst können sie über GitHub unter folgendem Link herunterladen.

GitHub: Tintri_LINUX_FLR

Sollten sie weitere Informationen zu unserem kleinen Helferlein wünschen, selbst einmal ein Automatisierungstool benötigen, oder Interesse am Tintri Storage bekommen haben, so melden sie sich doch einfach beim Autor per Email, oder rufen sie uns unter der folgenden Telefonnummer an:

Telefon: +49 8250 92903