Der Kunde musste die Sicherung einer SAP/R3 Datenbank mit 'Dedicated StorageNode' auf NetWorker 7.5 umstellen. Normalerweise kein Problem, denkt man. Aber der Teufel lag mal wieder im Detail.

Zur Umgebung:

• Der Kunde sichert eine MAXDB (früher SAPDB) SAP/R3-Datenbank mit Hilfe des NetWorker Save-Kommandos über eine Pipe. Eine genaue Beschreibung des Verfahrens kann man hier bekommen.
• Bei dieser Sicherungslösung werden die zu sichernden Daten von der MAXDB in eine Pipe geschrieben und auf der anderen Seite vom NetWorker Save-Kommando mit Hilfe des internen rawasm gelesen und weitergereicht.
• Das Save-Kommando wird in diesem Fall vom MAXDB Sicherungsmodul selbst aufgerufen. Der Aufruf erfolgt nicht über den NetWorker Client-Dämonen (nsrexecd). 

Und hier liegt die Ursache des Problems. Seit NetWorker V7.5 wird bei einem vom Benutzer gestarteten Save-Kommando keine Level Angabe mehr akzeptiert! In diesem Fall erhält man folgende Warnung:

# save -l full /etc/host
Client initiated backup.Option '-l' is ignored and backup is performed at level 
adhoc

Diese Meldung veranlasst das MAXDB-Modul die Sicherung als fehlerhaft einzustufen.

Welche Lösungsmöglichkeiten gibt es?

1. Wenn in der Umgebung des Save-Kommandos die Variable NSR_MAST gesetzt ist, akzeptiert das Save-Kommando die Level-Angabe.
2. Aufbau eines "Wrappers" um das eigentliche Save-Kommdando

Da es sich bei der Datenbank um ein 7*24 System handelt, war an einen Restart der Datenbank zum Setzen der Umgebungsvariablen nicht zu denken. Eine Sicherung sollte aber unbedingt täglich erzeugt werden!

Also wurde Variante 2 gewählt: Ein Shellskript ersetzt das Save-Kommando und startet das eigentliche Binary mit der benötigten Umgebung. Wichtig ist hierbei aber auch darauf zu achten, dass die Ausgabe des Save-Kommandos nicht verfälscht wird. Denn auch diese wird von dem MAXDB-Sicherungsmodul ausgewertet. Wurde das Binary auf den Namen "save_bin" umbenannt so wird die Ausgabe des Kommandos in etwa so aussehen:

save_bin: /etc/hosts  8 KB 00:00:00      3 files

Das mag die MAXDB aber auch nicht, das Sicherungsmodul scheint in seiner Auswertung nach dem String "save:" zu suchen und wenn der nicht gefunden wird die Sicherung als fehlerhaft eingestuft.

Der Kunde wollte seine NetApp NDMP Sicherungen von einem "alten" NetWorker Server auf einen neuen bereits aktiven NetWorker Server migrieren. Folglich sollten alle Bänder (600 an der Anzahl) im neuen NetWorker Server bekannt gemacht werden.

Da es ja keine Fleißaufgabe werden sollte und sich kein vernünftiger Mensch freiwillig vor den Bildschirm setzt um 600 Bänder für das Einlesen der Bänder zu wechseln, sollte das ganze per Skript gelöst werden. An sich ja alles nicht so schwierig, aber der Teufel lag mal wieder im Detail!

Hier die Idee:

1. Export der Medien
2. Import der Medien
3. Sortieren der Barcodes nach dem Sicherungsdatum
   • mminfo -av -ot -p <pool> -r barcode
4. Entfernen der recyclebaren Medien
5. Scanner Script dass Band für Band abarbeitet

•  Laden des Mediums
•         disablen des Laufwerks
•         scanner -m <device>
•  Eine Schleife über alle restlichen Bänder
  •      Warten bis der scanner sagt, er will das nächste Band
  •      Enablen des Laufwerks
  •      umount des Bandes
  •      Mount des nächsten Bandes
  •      disabeln des Bandes
  •      Scanner mitteilen, das nächste Band ist bereit

Soweit die Idee, nur leider spielte das Scanner Kommando nicht mit :-(

• Ein "Scanner -z" hat für NDMP leider einen bereits bekannten BUG.

• Die Abfrage nach dem nächsten Band läßt sich  nicht automatisieren.

Nachdem auch kein Googlen und Trussen weiterhilft, konnte eine Anfrage an die FTS-Entwicklung doch noch Abhilfe schaffen! FTS kannte das Problem bereits und hatte für einen ähnlichen Fall einen Scanner entwickelt, der eine Nachfrage nach dem nächsten Band mittels einer Datei ermöglicht. Mit diesem Spezial-Scanner konnte das oben skizierte Skript doch noch zum Einsatz kommen.

Jetzt fehlte nur noch der Aufbau der alten Index-Einträge sowie die Anpassung der Rention-Zeiten und die Migration war geschafft!

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.

Diese Woche war schwitzen angesagt (nicht nur der Temperaturen wegen ;-)), sondern auch das Projekt hatte es mal wieder in sich.

Es sollte ein NetWorker Active-Active Cluster bestehend aus einer NetWorker Storage-Node und einem NetWorker Server aufgebaut werden. Die Basis bilden:

• zwei Solaris-10 Maschinen, auf denen ein Veritas-Cluster zum Einsatz kommt
• ein über NFS angebundener Storage auf einem NetApp Metro-Cluster
• die Networker Version 7.5 von Fujitsu
• SAN Laufwerke aus einem ACSLS Roboter
• die SAN Laufwerkssharing Lösung SRS zum Verwalten der Laufwerksvergabe
• eine VTL-700 für die Sicherung der langsamen und asynchronen Daten

Die Lösung erlaubt eine automatische (von der Cluster-Software überwachte) Übernahme der NetWorker-Server Funktionalität an den StorageNode mit Übernahme aller Laufwerke und umgekehrt. Dies bedingt natürlich gleiche Laufwerksbezeichnungen aller verwendeten Laufwerke auf den beiden Cluster-Maschinen und ein durchdachtes Design des Storage und der Laufwerksaufteilung.

Das Schwitzen hat sich aber gelohnt ;-) das Cluster ist fertig und alle Kundenanforderungen konnten erfüllt werden.