Viel zu lange her, dass ich hier etwas veröffentlicht habe.
Das hat aber nichts damit zu tun, dass es nichts zu berichten gäbe, sondern dass es einfach zu viel zu tun gibt und ich daher keine Zeit gefunden habe, dies hier zu berichten. Nun sitze ich am Flughafen und warte auf den wegen Nebel verschobenen Flug zur NetApp Insight und habe endlich mal Zeit und Luft diese Zeilen zu schreiben ;-)

Wo fangen wir an?
Unser Snapshot-Backup Entwicklung für Oracle und VMware ist an vielen Ecken vorangetrieben worden.

Folgende Erweiterungen wurden für die Oracle-Sicherung auf NetApp implementiert und sind bereits beim Kunden im Einsatz:

• vollautomatische Recover Funktionalität
  • Recover Until Time
  • Vollständiges Recover (Crash Recover)

Durch diese Erweiterung können NSR-ORA-NDMP Kunden auf unser Produkt wechseln ohne Funktionalität zu verlieren. Im Gegenteil: Sie erhalten zusätzliche Funktionalität (SnapVault Support).

Folgende Erweiterungen wurden für die VMware-Sicherungen auf NetApp implemetiert:

• Parallelisierung einiger Funktionen: Dadurch wurde die Sicherungsdauer zum Teil auf ein Viertel der Zeit reduziert!
• Unterstützung von orignären NetApp Snapshots für das Recovery von Einzeldateien. Hierdurch können mehrere Sicherungsstände pro Tag durch den normale NetApp Snapshot Scheduler generiert werden. Diese Snapshot Sicherungen sind zwar nur Crash-Consistent, können aber für das Recovery einzelner Dateien verwendet werden.

Migrationsunterstützung :

Unterstützung von mehreren gleichzeitigen SnapVault Beziehungen.
Sowohl die Oracle-  als auch die VMware- Lösung erkennen und "updaten" jetzt auch mehrere gleichzeitige SnapVault Beziehungen. Hierdurch kann z.B. der secondary Storage auf einem neuen System angelegt werden und sobald beide Nearstore Systeme den gleichen Snapshot-Stand haben (beide haben Snapshots über "n" Wochen), kann die "alte" Nearstore Verbindung aufgelöst werden.

Volume Backup:

Unterstützung von Volume Sicherungen über unsere Snapshot Integration.
Dieses Feature unsere Snapshot-Backup Integration ermöglicht z.B. die Sicherung eines Multistore-Filers (VFiler) auf eine gemeinsames Nearstore Volume zu sichern und dieses für Langzeitsicherungen anschließend auf Band-Medien zu sichern.

Im letzten Herbst habe ich bereits eine Lösung für das Problem, "werden alle NetApp Volumes auch vom NetWorker gesichert" vorgestellt. Die Überwachung der gesicherten NetApp Volumes wurde anhand von einem Python Script mit unserer eignenen NetApp API durchgeführt und läuft seit dem sehr erfolgreich bei unseren Kunden. Jetzt kam eine neue Herausforderung hinzu!

Ein weiterer Kunde sichert die NetApp Volumes nicht als komplette Volumes, sondern unterteilt diese in mehrere Sicherungen, von NetApp-Qtrees bzw zum Teil auch in Sicherungen von Unterverzeichnissen mehrere Stufen unterhalb des Volume Namens. Natürlich sollte sicher gestellt sein, dass alle Unterverzeichnisse eines Volumes gesichert werden. Es kommt aber leider immer mal wieder vor, dass andere Abteilungen, neue parallele Verzeichnisse zu den bestehenden aufbauen ohne an die Datensicherung zu denken. Dies passiert zum einen, weil mehrere Abteilungen über verschieden Standorte verteilt an der Administration des Storage beteilgt sind. So kann zum Beispiel die Windows-Abteilung in Ihrem Volume selbstverständlich neue Freigaben generieren und hierfür auch neue Verzeichnisse anlegen.

Hier ein kleines Beispiel um das Thema etwas griffiger zu gestalten:

Das Volume /vol/sv_filer3_bauplaene enthält zurzeit 5 TB zu sichernde Daten. Diese Daten verteilen sich in folgende Verzeichisse:
        /vol/sv_filer3_bauplaene/MUC
        /vol/sv_filer3_bauplaene/FRA
        /vol/sv_filer3_bauplaene/HAM
        /vol/sv_filer3_bauplaene/KOB
        /vol/sv_filer3_bauplaene/DUS
        /vol/sv_filer3_bauplaene/KOL
        /vol/sv_filer3_bauplaene/BRE
        /vol/sv_filer3_bauplaene/PDB
        /vol/sv_filer3_bauplaene/KA

Alle Verzeichnisse sind in 3 NetWorker Client Ressourcen eingetragen. Der Vorteil hierbei liegt auf der Hand: Die Vollsicherung des Volumes kann an 3 unterschiedlichen Tagen stattfinden und bei auftretenden Problemen kann gezielt ein SaveSet der Sicherung nachgefahren werden.
       
Die Windows Abteilung generiert das neue Verzeichis "/vol/sv_filer3_bauplaene/STG" vergisst aber leider dies den NetWorker Administratoren mitzuteilen. Nach "n" Wochen möchte ein Entwickler einen 3 Wochen alten Plan aus der Unterverzeichnis "STG" wiederhergestellt haben. Dumm gelaufen.

Um genau dieses Problem nicht entstehen zu lassen, haben wir unser kleines Überwachungstool so erweitert, dass jetzt auch beliebig tiefe Unterverzeichnisstrukturen analysiert werden. Im obigen Fall würde nach dem Generieren des Verzeichnisses am folgenden Morgen eine Mail an den Backup-Administrator gesendet, in der er mitgeteilt bekommt, dass das Verzeichnis "STG" nicht in der Sicherung enthalten ist.

Das Tool ermittelt zunächst für den angegebenen Filer alle im NetWorker enthaltenen SaveSets und generiert daraus eine Liste der Verzeichisse und Volumes, die untersucht werden müssen. Hierauf wird am Filer eine Auflistung der Verzeichnisse und Volumes angefordert. Die gesammelten Daten werden im Anschluß gegen die bereits bekannte "Whitelist" verglichen und alle nicht bekannten Volumes und "parallel Verzeichnisse" werden den NetWorker Administratoren gemailt.

Hier ein Beispiel für den Aufruf eines Überwachungslaufs:

================================================================================
        not saved Volumes und Subdirectorys for NetApp Filer: nafiler3
        check WIKI entry: http://ciwi/s_t_wiki/index.php5/Check_Volume_Backup
================================================================================

db_oaiacc
db_oaidev

/vol/sv_filer3_bauplaene/STG

Die beiden Volumes "db_oaiacc" und "db_oaidev" gehören in die WhiteListe der SaveSets. "/vol/sv_filer3_bauplaene/STG" sollte in die NetWorker Konfiguration aufgenommen werden.

Die Firma Network Appliance (NetApp) hat für die Verwaltung seiner Storage Systeme eine webbasierte API Schnittstelle geschaffen. Leider gibt es für diese Schnittstelle von NetApp keine Pakete für die Programmiersprache Python.

Vor einiger Zeit haben wir daher begonnen, eigens eine Python Bibliothek für unsere Zwecke zu erstellen. Diese war schon nach kurzer Zeit deutlich komfortabler zu benutzen als z.B. die von NetApp bereitgestellte Perl Bibliothek. Ziel war es nun geworden, sämtliche API Kommandos so nachzubilden, dass sie über einen einfachen Funktionsaufruf in Python ausgeführt werden können. Doch durch die Vielzahl an möglichen API Kommandos schien dieses Vorhaben schier unmöglich. Es entwickelte sich die Idee, aus der Dokumentation von NetApp heraus automatisch den Quellcode zu erzeugen...

Zufällig wurde ich dann aber beim Lesen der NetApp Dokumentation auf ein paar API Kommandos aufmerksam, die mir die Arbeit erheblich erleichtern sollten:

Führt man das API Kommando system-api-list aus, gibt es die Namen aller verfügbaren API Kommandos zurück. Verwendet man dazu noch die Kommandos system-api-list-types und system-api-get-elements hat man alle Werkzeuge beisammen, die man für die Generierung benötigt: Welche Argumente hat ein Kommando, wie wird das für die Anfrage wichtige XML Element dafür erstellt und wie kann ich die XML Ausgabe direkt in Python Listen und Dictionaries umbauen.

Nachdem mit jeder neuen ONTAPI Version neue API Kommandos hinzukommen, wird bei unserer Realisierung der Python Code, mit dem man die API Kommandos ausführen kann, automatisch anhand der verwendeten Version generiert. Somit entfällt das händische Updaten für unsere Bibliothek.

Wir haben diese Bibliothek unter der freien Lizenz LGPL zum Download bereitgestellt. Besuchen Sie hierfür die Projektseite.

Wann merkt man, dass ein Datenbereich nicht gesichert wird?
Natürlich erst dann, wenn man Daten aus dem betreffenden Bereich wiederherstellen möchte!

Genau dieses war mal wieder beim Kunden vorgekommen und damit dieses nicht noch mal passiert, sollte eine Lösung entwickelt werden, die einmal täglich überprüft, ob alle zurzeit existierenden Volumes gesichert werden.

Die Umgebung:

Der Kunde sichert mehrere NetApp Filer mit dem Backup Produkte NetWorker und dem NDMP Protokoll auf externe Bandmedien.

Auf den Filern werden sowohl Oracle-Datenbanken, MS-Exchange-Daten, VMware-Datastores als auch Benutzer-Daten gespeichert. Die Oracle-, Exchange,- wie auch die VMware-Daten werden über eigene Module gesichert; so kann folglich nicht einfach der NetWorker-SaveSet "All" verwendt werden, um alle NetApp-Volumes zu sichern.

Die Lösung:

Mit unserer eigenen NetApp-ZAPI-Python-Schnittstelle werden zunächst vom jeweiligen Filer alle Volumes ermittelt.

Dann werden über unsere Python-NetWorker-nsradmin-Schnittstelle alle "Save Sets" für den betreffenden Filer ausgelesen.

Volumes, die nicht im NetWorker definiert sind, werden anschließend noch gegen eine definierbare White-Liste verglichen. Die Oracle- und VMware-Volumes will man ja nicht jeden Morgen vor Augen haben,
da man sonst ja wieder nicht sieht, ob ein neues Volume hinzugekommen ist.

Über die Volumes, die weder in der Sicherung noch in der White-Liste enthalten sind, werden die Administratoren mittels E-Mail informiert.

Durch unsere bestehenden NetApp und NetWorker Frameworks konnte somit eine einfache und praktikable Lösung in kurzer Zeit entwickelt werden, die dem Kunden eine Menge Ärger und Erklärungsnöte ersparen kann.