Visualisierung und Management von NetWorker Log- und Raw-Dateien sowie Systemparametern

1. Einleitung

Wer für die Sicherung einer größeren Firma verantwortlich ist, möchte frühzeitig mitbekommen, wenn
das Backup-System in eine Schieflage gerät. Um das zu erreichen, reicht es nicht, nur die Meldun-
gen der Sicherungen zu kontrollieren, sondern der Administrator sollte auch die Protokolle der Back-
up-Software und des Betriebssystems betrachten. Zusätzlich sollten die Betriebssystem-Parameter,
wie Hauptspeicherverbrauch, Netzwerkauslastung und Ähnliches im Auge behalten werden.


Ein NetWorker Administrator ist heutzutage aber schon rein zeitlich nicht in der Lage, alle System-
protokolle und die NetWorker-Protokolle täglich durchzuarbeiten. Die Überwachung läuft folglich
auf eine Symptom-Bekämpfung hinaus. Wenn ein akutes Problem auftaucht, z.B. eine Sicherung wird
wiederhollt abgebrochen, dann wird eine Analyse gestartet. Oft wäre das Problem aber bereits im
Vorfeld zu erkennen gewesen. Man hätte die Backup Probleme vermeiden können, wenn die betref-
fenden Meldungen früh genug erkannt worden wären.


Ein Beispiel:
Ein Kunde berichtete mir in einer meiner Workshops, dass die NDMP Sicherungen in seiner Firma seit
längerem ein Zeitfenster-Problem haben. Früher wäre alles ohne Probleme gelaufen, aber seit einiger
Zeit würden die NDMP Sicherungen zu lange brauchen.


An diesem Problem wurde schon seit Wochen herumgedoktert, auch mit externen Support. Aber leider
hatten alle Beteiligten immer nur im Umfeld des Storage-Systems und des NDMP-Workflows nach
Fehlern gesucht. Das eigentliche Problem wurde aber nicht entdeckt. Dabei war das Problem in der
NetWorker Protokoll-Datei (daemon.raw) durchaus ersichtlich, wenn man danach gesucht hätte. Die
Ursache des beschriebenen Problems in diesem Beispiel war nicht der NetWorker-Server oder eine
Konfiguration im NetWorker. Die Ursache des Problems war dem Austausch von Netzwerk-Kompo-
nenten und damit veränderten Netzwerk-Routen geschuldet. Durch diese Änderung in der Peripherie
konnten einige NetWorker-Client Maschinen die DataDomain Systeme nicht mehr direkt erreichen.
Es fand folglich kein Client-Direct-Backup mehr statt, sondern die Maschinen sendeten ihre Daten
zum NetWorker-Server und dieser übergab die Daten dann an die DataDomain. Durch dieses, um
mindestens 90% höhere Datenaufkommen, waren die Netzwerk- und System-Komponenten am Net-
Worker-Server so stark belastet, dass beim Start der NDMP Sicherungen keine Kapazitäten mehr frei
waren. Wie gesagt, die Meldungen, dass die Client-Sicherungen keinen direkten Weg mehr für ihr
Backup hatten, waren in den Logs ersichtlich. Es hat nur keiner bemerkt.


Das Auffinden entprechender Meldungen in der NetWorker daemon.raw wird dadurch erschwert,
dass alle NetWorker Daemonen ihre Standard-Error-Ausgabe in diese Datei schreiben. Wenn es dann
noch ein paar Maschinen gibt deren Client-Zertifikat fehlerhaft im NetWorker eingetragen ist, sieht
man schnell den Wald vor lauter Bäumen nicht mehr. Einige Tausend Meldungen pro Tag sind keine
Seltenheit. Hier die Spreu vom Weizen zu trennen war folglich das Ziel des vorliegenden Tools.

2. Das Ergebnis

   Eine WWW-Oberfläche in der:

   • alle wichtigen NetWorker Umgebungsparameter auf einen Blick ersichtlich sind.
   
   • es möglich ist die daemon.raw Meldungen zu filtern, zu bearbeiten und bei definierten Meldungen
     automatische Aktionen einzuleiten.
   
   • es möglich ist, Meldungen nach dem Status (NEW, ACCEPTED, ...), dem Verursacher (nsrexecd,
     nsrd, ...), nach Meldungs-Texten und ausgewählten Zeiträumen, zu filten und nach allen gezeigten
     Spalten, zu sortieren.
   
   • es möglich ist den zeitlichen Verlauf von System-Ressourcen der NetWorker-Server Maschine graphisch zu betrachten
   • es möglich ist Datensicherungslangläufer (Long Running Jobs  anzeigen zu lassen.
   • es möglich ist den Speicher- und Swap-Verbrauch der NetWorker-Server Maschine des letzten Monats visualisiert zu betrachten

3. Weitere Module

   • Überwachung der RetentionLock Definitionen in den NetWorker Workflow-Actions
   • Visualisierung der NetWorker Rap.log Datei
   • Kontrolle der installierten NetWorker Client- und Modul-Versionen
   • Berechnung der DataDomain DeDup-Werte pro Client und SaveSet. Gruppierung der Clients zu Abrechnungzwecken.

4. Die Zukunft

   Weitere Überwachungsparameter sind in Planung oder bereits in Arbeit.
   zum Beispiel:
   
   • Erkennen von Backup Anomalien
   • Überwachung der Bootstrap Sicherungen
   • Kontrolle der RetentionLock Funktionalität bei Datenbank Sicherungen
   • Visualisierung der NetWorker Client- und Modul-Logdateien
   • ...

Sollten sie weitere Fragen oder Interesse an einer Live-Demo des Tools haben so wenden Sie sich am besten per Mail an den Autor.

Wie im letzten Blog (DataDomain Monitoring) bereits angekündigt, haben wir auf Basis der Docker-Container-Technik nicht nur ein Monitoring der DataDomain Stream-Auslastung implementiert, sondern auch die Backup-Streams der beteiligten NetWorker-Server grafisch aufbereitet.

Genau genommen können die NetWorker-Sessions aus zwei Blickwinkeln analysiert und dargestellt werden:

1.  Wie viele Backup- und Cloning Sessions werden vom NetWorker Server an den angeschlossenen DataDomain Systemen erzeugt.
2. Welche Workflows erzeugen wann wie viele parallele Streams.

Für beide Blickwinkel werden für jeden NetWorker-Server eigene Tabellen in einer Influx-Datenbank gefüllt. Diese können in einer jeweils eigenen Darstellungs-Seite im graphischen Analyse-Tool Grafana betrachtet und analysiert werden.

Die folgenden 3 Grafiken zeigen zunächst die Anzahl Sessions pro DataDomain und pro NetWorker Laufwerk:

In der obigen Grafik wird die Anzahl von parallelen NetWorker-Sessions der letzten 7 Tage dargestellt. In der ersten Zeile erkennt man in der Tachometer Darstellung, die maximale Anzahl Sessions für die beiden DataDomain Systeme in den Kategorien Save, Recover, Clone-Saves und Clone-Recover. In den darunter folgenden Grafiken erkennt man den Verlauf der jeweiligen Session-Anzahl pro Laufwerk. Durch einen Mausklick auf einen der Laufwerksnamen, kann man sich den Verlauf für ein einzelnes Laufwerk anzeigen lassen.

Möchte man die Auslastung des letzen Tages, oder eines beliebigen anderen Zeitraums anzeigen lassen, so kann man dieses leicht über die Grafana WWW-Oberfläche per Menu-Auswahl oder per Maus-Auswahl erreichen.

Die Darstellung der letzten 24 Stunden:

Die Darstellung eines mit der Maus ausgewählten Zeitraum von ca. 2 Stunden:

Wie oben schon erwähnt, möchte man aber nicht nur die Summe der Sessions zum jeweiligen Zeitpunkt betrachten, sondern in bestimmten Fällen ist es auch interessant zu ermitteln, welcher Workflow hat denn die zu hohe Last produziert. Auch zu dieser Darstellung 3 Beispiel-Bilder:

Die Darstellung der Sessions pro Workflow der letzten 7 Tage:

Die Workflow Sessions der letzten 24 Stunden:

Ein mit Hilfe der Maus ausgewählter Zeitraum von ca. 2 Stunden:

Wozu man die Grafiken verwenden kann, sollte jedem NetWorker-Administrator leicht ersichtlich sein. Man erkennt zum Beispiel eventuelle Engpässe, freie Zeiträume und so weiter. Im Falle des Einsatzes von mehreren NetWorker Servern, lassen sich so aber auch die Sicherungszeiten und deren Lastverteilung zwischen den NetWorker-Servern vergleichen, um so eine Basis für bessere Auslastung der DataDomain Systeme zu erhalten, die Datensicherungen zu optimieren und die Probleme zu minimieren.

Technische Implementation:

Noch einige Sätze zur technischen Implementierung und zu den benötigten Ressourcen.

Die gesamte Lösung besteht aus 3 Docker-Images. Ein Image stellt die Datenbank zur Verfügung. Es handelt sich hierbei um die freie NON-SQL Datenbank Influx-DB. Das zweite Image dient der Darstellung der gesammelten Daten. Hier wird wie bereits bei der DataDomain-Monitoring Lösung auf Grafana zurückgegriffen. Das dritte Image ist das Aufzeichnungsimage. Dieses Schäfer & Tobies eigene Image basiert auf einem Ubuntu-Image mit einem integrierten NetWorker-Client und einem Python-Script, das alle ‚n‘ Sekunden die aktuellen Session-Informationen vom NetWorker-Server abfragt. Die Abfragen erfolgen hierbei zum einen mit der NetWorker-REST-API, zum anderen mit dem Command-Line-Tool „nsradmin“. Das dritte Image wird ganz Docker-Like pro NetWorker-Server ausgerollt. Sollten sie z.B. 3 NetWorker Server im Einsatz haben, so benötigen sie für die oben gezeigten Aufzeichnungen folglich 5 Docker-Instanzen. Sollten sie auch die zwei DataDomain Systeme monitoren wollen, so benötigen sie insgesamt 7 Docker-Instanzen auf Basis von 4 verschiedenen Images. Die hier gezeigte Lösung ist somit sehr flexible und sowohl für kleinere NetWorker-Umgebungen als auch für große einsetzbar.

Fazit:

Mit dem Schäfer & Tobies eigenen NetWorker-Monitoring Skripten können Sie Engpässe in Ihren Datensicherungsabläufen erkennen. Ungenutzte Zeiträume, aber auch eventuelle Engpässe und Überlastungen kann man mit den Grafana basierten Grafiken gut analysieren. Beim Einsatz von mehreren NetWorker-Servern können die Zeiten der höchsten Anforderungen der einzelnen Backup-Server leicht gegeneinander verglichen werden.

Sollten Sie Fragen zu der hier dargestellten Analyse-Software haben, so senden sie uns bitte unverbindlich eine E-Mail. Wir werden uns mit Ihnen in Verbindung setzen und wenn gewünscht, auch gerne eine Demo der Möglichkeiten mit Hilfe einer Telefon-Konferenz durchführen.

Weitere Informationen zu unseren Monitoring-Tools erhalten sie auch im BLOG „DataDomain Monitoring“ und in Kürze im Blog „Grafische NetWorker Kapazitätsauswertung“.