Die Kontrolle eines NetWorker Workflow-Laufes wird bei den meisten Kunden über das menschliche Auge, sprich den Blick auf die NetWorker-Management-Console (NMC) erfolgen. Leider ist diese Art der Kontrolle fehleranfällig und bei der Analyse von Problemen sehr zeitaufwendig. Außerdem werden nicht unbedingt alle Probleme angezeigt und bleiben damit u.U. unerkannt.

Hier ein paar Beispiele für Probleme bzw. Fehler, die in der NMC mit einem grünen Hacken versehen werden bzw. wurden:

• fehlerhafte Clone-Jobs
• deaktivierte Clients (Client Attribut: scheduled backup)
• Datenbank-Sicherungen im Komprimierungsmodus

NetWorker protokolliert all diese Probleme in den Log-Dateien. Aber eine automatische Kontrolle der Dateien existiert zurzeit leider nicht! Erschwerend kommt hinzu, dass jeder einzelne Workflow-Job, sei es nun die Sicherung eines Filesystems, einer Windows Partition oder eines Datenbank-Logs, in einer eigenen Log-Datei landet. Einige Log-Dateien werden hierbei im Klartext abgelegt, andere sind nur im 'RAW'-Format vorhanden.

Ähnliche Probleme gab es auch schon im NetWorker 8. Hier gab es aber für die automatische Analyse der Sicherungsausgaben ein NetWorker eigenes Programm mit dem Namen scm_filter. Dieses ist mit dem Verschwinden der NetWorker Savegroup-Logik jedoch ebenfalls verschwunden. Kunden, die den SCM-Filter in der Version 8 im Einsatz hatten, beauftragten uns, einen Ersatz für die NetWorker Version 9 zu erstellen.

Das Ergebnis ist ein Programm, das auf Basis der NetWorker 9 REST-API Schnitstelle,  alle zu einem Workflow gehörigen Log-Dateien in einer neuen Log-Datei zusammenfasst und diese Datei anschließend mit Hilfe von definierbaren regulären Ausdrücken analysiert. Die Funktion des ehemaligen SCM-Filters konnte somit vollständig ersetzt werden.

Als weiteres Schmankerl kann  das Programm nun dazu verwendet werden, eine NetWorker 8 Savegroup Ausgabe zu emulieren. Dieses Feature ist für einen weiteren Kunden entstanden, der die NetWorker 8 Savegroup Ausgaben zur Analyse an ein Drittanbieter-Tool sendet und eine schnelle Integration der NetWorker 9 Meldungen benötigte.

Sollten sIe Interesse an diesem Programm haben, so können sie hier das Handbuch unserer REST-API Tools herunterladen. Hier ist der Einsatz des  entstandenen Tools mit dem Namen nsr_workflow_analyse ausführlich beschrieben.

Bei Fragen und ähnlichen Problemen, wenden sie sich bitte per E-Mail an den Autor des Artikels.

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.