Es gibt sie noch die "gute" alte NetWorker Version 7.2 wenn auch offiziel nicht mehr supported laufen einige NetWorker Server wohl immer noch mit dieser sehr stabilen Version, frei nach dem Motto "never change a running system". Aber irgendwann sind auch die Tage eines langlebigen Servers gezählt und man muss den Umstieg auf eine neue Version durchführen.

Der Kunde wollte natürlich nicht mit einer bereits wieder veralteten Version 7.5 anfangen und so wurde entsprechend gleich auf die aktuelle NetWorker Version 7.6 upgedated! Es wurde demzufolgen mein erster produktiver Update auf die NetWorker Version 7.6!

Für den Upate stand eine neue Solaris 10 Umgebung (der alte Server lief auf Solaris 8) für den NetWorker Server und seinen StorageNode zur Verfügung. In der alten Umgebung teilten sich Server, StorageNode und 4 NetApp-Filer  16 Laufwerke,  mit Hilfe der SAN-Sharing Software (SRS) von FTS ehemals FSC. Da die NetWorker Version von FTS aber in absehbarer Zeit auslaufen wird und danach diese Sharing-Lösung nicht mehr unterstützt wird, wollte der Kunde an dieser Stelle gleich den Umstieg auf die Lösung von EMC umschwenken. Dies bedeutete eine Umstellung der Lizenzen und natürlich eine völlige Umkonfiguration der Laufwerke und Library-Konfiguration. Die Lizenzen erhielt der Kunde auf Grund seines Wartungsvertrags von FTS. Die beiden Solaris Maschinen bilden einen halb automatischen NetWorker Cluster. D.h. die Applikation wird zwar nicht automatisch bei einem Ausfall umgeschaltet, aber alle Vorkehrungen dafür sind getroffen. Voraussetzung hierfür sind:

• Die NetWorker Power Edition Lizenz
• eine virtuelle IP für den NetWorker Server
• eine Cluster Software
• die Ablage der NetWorker Datenbanken auf einem von beiden Maschinen zugreifbaren Laufwerk (in unserem Falle NFS)
• einige Konfigurationsdetails in der NetWorker Umgebung (hostids, NetWorkerCluster.srv)

Im Gegensatz zu SRS bei dem die physikalischen Laufwerke dynamisch einem virtuellen NetWorker Laufwerk zugewiesen werden, müssen bei der DDS Lösung alle Laufwerke mit ihren Betriebssystem-Knoten im NetWorker angelegt werden. Hier muss man aber Gott sei Dank nicht die vom OS als Default vorgegebenen Laufwerksknoten verwenden, sondern kann je nach Betriebsystem auch eigene symbolische Links bzw. Aliases für die Laufwerke konfigurieren. Denn die Verwendung des selben Namens auf allen Maschinen für ein physikalische Laufwerk erleichtert die Arbeit mit den Laufwerken ungemein! Hierbei muss bei der Konfiguration der NetWorker-Librarys allerdings auf das automatische Anlegen mittels NMC verzichtet werden. Die Ressource muss unter der Verwendung der Kommandos jbconfig mit einiger Sorgfalt und von Hand erfolgen. Das Ergebnis wird man aber bald zu schätzen wissen.

Natürlich mussten auch noch einige andere Anpassungen an bestehenden Skripten und Überwachungs-mechansimen durchgeführt werden. Seit der Version 7.2 hat sich am NetWorker doch einiges geändert. So wurde z.B. der Savegroup Completion Message Filter eingerichtet und konfiguriert.

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.

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.

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!