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“.

Automatische Generierung von NDMP SaveSet Namen

Ein Kunde hatte das Problem, dass die Sicherungszeit eines NetApp-Volumes mit ca. 40 TB Größe, mehrere Tage betrug. Außerdem waren die Wiederherstellungszeiten für einzelne Dateien aus diesen Sicherungen inakzeptabel.

Eine einfache Parallelisierung der Verzeichnisse von Hand war leider nicht möglich, da sich bereits auf der obersten Verzeichnisebene mehr als 8000 Unterverzeichnisse befanden. Erschwerend kam hinzu, dass jederzeit auch neue Unterverzeichnisse von den Fachabteilungen angelegt werden können. Diese müssen natürlich auch bei der nächsten anstehenden Sicherung mitgesichert werden.

Es stellte sich folglich das Problem: wie kann man die Sicherung des Volumes parallelisieren, ohne Gefahr zu laufen, neu angelegte Verzeichnisse nicht zu sichern.

Die Lösung bestand in der Programmierung eines Python-Skriptes, das mit Hilfe der Schäfer & Tobies eigenen NetApp-Ontapi-Python Schnittstelle und dem NetWorker-REST-API, täglich die NetWorker Client-Ressourcen automatisiert neu generiert.

Das Skript liest hierzu zunächst alle Unterverzeichnisnamen des Volumes per API aus und verteilt die erhaltenen Namen anhand einer Konfigurationstabelle und den Anfangsbuchstaben auf „n“ definierte NetWorker-Client-Ressourcen. Jede dieser NetWorker Client-Ressourcen verwendet einen eigenen Schedule, so dass auch eine Verteilung der Vollsicherungen über die Wochentage erfolgt.

Das Ergebnis konnte sich sehen lassen, die Sicherungszeiten waren wieder im vertretbaren Rahmen (unter 24 Stunden) und auch die Wiederherstellungszeiten sind um ein vielfaches schneller als zuvor.

Sollten Sie ein ähnliches Problem in ihrer Sicherungsumgebung haben, so scheuen Sie sich nicht, den Autor zu kontaktieren. Eine automatisierte und damit sichere Generierung der NetWorker-Ressourcen garantiert auch Ihnen, dass ihre wichtigen Daten immer in der aktuellen Sicherung enthalten sind. Der Aufwand für die Erstellung der benötigten Skripte hält sich in überschaubaren Grenzen und sollte damit auch für ihre Firma erschwinglich sein.

Ja, die NetWorker Version 8.2 ist jetzt schon seit 31. Januar offiziell nicht mehr unter Support, aber dennoch laufen wohl noch eine ganze Menge NetWorker-Server unter dieser Version!

Gerade große NetWorker Konfigurationen, mit mehr als 1000 Clients, Umgebungen die mit externen Schedulern wie Atomic (UC4) und ähnlichem gekoppelt sind, sowie Sicherungen mit langen Aufbewahrungszeiten, bilden für die Umstellung eine sehr große Hürde. Die Probleme bei der Umstellung sind bekanntlich die nötige Anpassung der Skripte, aber auch die Problematik der automatischen Konvertierung der NetWorker 8 Gruppen in eine einzige Policy namens Backup. Sollte der NetWorker 8 aber mehr als 50 Gruppen gehabt haben, wird die NMC nach einer In-Place Migration nicht mehr bedienbar. Ein weiteres nicht zu unterschätzendes Problem bei der Migration besteht darin, dass die Logik des NetWorker 9 lässt sich nicht mit der Logik des NetWorker 8 gleich setzen. Man benötigt folglich für den Update einer großen NetWorker-Umgebung, nicht nur eine Anpassung der bestehenden Datensicherungs-Skripte sondern auch ein neues Konzept und einen Migrationsplan.

Nachdem ich in den letzten 2 Jahren einige In-Place Updates in kleineren Umgebungen und auch Migrationen von großen NetWorker-Umgebungen in eine neue NetWorker 9 Umgebung begleitet habe, kam ein großer Outsourcer auf mich zu, ob ich mit den in diesen Projekten entstandenen Skripten (siehe Blog) in der Lage sei, eine In-Place Migration von NetWorker-Servern mit mehr als 1700 Clients und hunderten von Gruppen zu automatisieren.

Im letzten Monat habe ich nun dieses Projekt abgeschlossen.

Wie funktioniert der implementierte Ansatz?

Die Migration läuft im wesentlichen in 2 Schritten ab.

1. In-Place Migration der NetWorker 8 Datenbanken.

   • zuvor kopieren der NetWorker Ressource DB (/nsr/res/nsrdb)

   • In-Place Migration der NetWorker Umgebung

   • Löschen aller Policys, Protection-Gruppen und auch Clients aus dem NetWorker 9 Server (mit Hilfe eines nsradmin Skriptes)

2. Migrieren der NetWorker 8 Client-Ressourcen in die neue NetWorker 9 Umgebung.

   • Anhand eines definierten Algorithmus werden die Client-Attribute der NetWorker-8 Clients wie Gruppe, StorageNode usw. herangezogen, um jeden Client in eine neu definierte NetWorker 9 Policy/Workflow/Protection-Group abzubilden.

   • Das Anlegen der neuen Policy/Workflow/Protection-Group Ressourcen wird hierbei mittels REST-API Aufrufen automatisiert erledigt. Die Clients werden wegen fehlender Client-Attribute in der REST-API mit Hilfe von nsradmin-Skripten erzeugt. Das Sammeln der „alten“ Ressource-Attribute, sowie das Anlegen der Clients erfolgt mit Hilfe der Schäfer & Tobies eigenen nsradmin-API.

Worin lag das größte Problem bzw. der größte Aufwand bei diesem Projekt?

Die Problematik bestand in einer möglichst genauen Definition der Abbildung der Alten Client-Gruppen-Strucktur auf eine eindeutige Policy/Workflow Struktur. Diese Logik musste in das Migrations-Skript implementiert werden und der Aufwand hierfür war durch fehlende und missverstandene Kommunikationen leider wesentlich höher als erwartet.

Ergebnis des Projektes:

1. Eine NetWorker-Server Migration lässt sich an einem beliebigen NetWorker-Server leicht in wenigen Stunden testen.

2. Die eigentliche In-Place-Migration ist in wenigen Stunden auch für sehr große Umgebungen durchführbar.

3. Die Migrationsquote der getesteten NetWorker-Server mit ca. 1500 und 1700 Clients lag bei 98% bzw. 99%. Clients die aus verschiedenen Gründen nicht in der neuen Umgebung angelegt werden können werden, mit allen Attributen in einer eigenen Datei abgelegt und können von den NetWorker-Administratoren per Hand leicht korrigiert und nach-migriert werden.

FAZIT:

Auch große NetWorker-Umgebungen können mit einem relativ geringem Zeitaufwand auf NetWorker 9/18 In-Place migriert werden! Der Aufwand der Migration wird von der eigentlichen Migrations-Phase auf eine Planung und Implementationsphase verschoben.

Die Vorteile dieses Verfahrens liegen auf der Hand:

• Durch die In-Place Migration können Langzeitsicherungen ordentlich übernommen werden.

• Die Migration kann vor dem eigentlichen Umstieg ordentlich getestet werden.

• Der eigentliche Update-Vorgang ist zeitlich überschaubar.

Sollte auch Ihr Unternehmen noch vor dem Update ihrer NetWorker Umgebung stehen, haben sie mit unseren Migrations-Skripten vielleicht eine neue bisher nicht bedachte Möglichkeit der sanften Migration der NetWorker Umgebung. Sprechen Sie uns ruhig unverbindlich an.

NetWorker erhält immer mehr Funktionen, die den Schutz Ihrer Daten vor dem unbefugten Zugriff schützen sollen. So wurde mit der NetWorker Version 18.1 die DataDomain Retention-Lock Funktionalität vollständig integriert. Aus diesem Anlass möchten wir hier die NetWorker-Sicherheits-Funktionalitäten kurz betrachten.

- Zugriff auf die zu sichernden Maschinen

Für alle bekannt sollte der Schutz vor dem unlauteren Backup / Recover von einem anderen NetWorker_Server sein. Hier steht seit langem die „Servers-Datei“ und das Client-Zertifikat als Sicherheitsschutz zur Verfügung.

- Administrations-Zugriff

Der NetWorker-Administrator darf alle Daten eines Clients sichern, aber auch beliebige Dateien auf die Client-Maschinen pushen. Somit hat der Administrator potentiell alle Maschinen die im NetWorker konfiguriert sind im Zugriff und er kann diese Maschinen auch kompromittieren. Entsprechend wichtig ist der sorgfältige Umgang mit der Administrator-Liste. Hier bietet NetWorker nicht nur den Check auf Benutzer-Name und Maschine, sondern es können weitere Attribute, wie z.B. auch das Client-Zertifikat als Kriterium für den Administrations-Zugriff überprüft werden.

- Verschlüsselung auf dem Transportweg

Wenn die zu sichernden Daten auf dem Sicherungsweg durch ein öffentliches Netz (WAN) gesendet werden, sollten diese natürlich nicht im Klartext vom Client zum Datenmedium gesendet werden. Hierfür bietet NetWorker die Möglichkeit zur Verschlüsselung der Daten auf dem Transportwege an. Diese Verschlüsselung gibt es zum einen bei der Sicherung auf DataDomain (im Boost-Protokoll) aber seid NetWorker 9 auch bei der Sicherung auf andere Medien.

- Verschlüsselung auf dem Datenmedium

Die gesicherten Daten müssen u.U. auch auf dem Backup-Medium vor dem Zugriff von Fremden geschützt werden. Dies kann zum Einen auf dem Backup-Medium DataDomain selbst erfolgen, kann aber auch bei der Erzeugung eines Tape-Mediums bei der Sicherung oder auch bei der Erzeugung eines synthetischen Full Backups.

- Schutz des Backup-Mediums vor Sabotage

Immer wichtiger wird auch der Schutz vor Sabotage. Damit kommt zwangsläufig die Frage auf, wie kann ich meine gesicherten Daten auf einem DataDomain System vor einem Saboteur schützen? Mit NetWorker 18.1 und dem DataDomain RetentionLock Feature können Sie sich jetzt auch von diesem Problem verabschieden. Denn durch die Verwendung der DataDomain Retention-Lock Funktion bei der Sicherung, können die Daten auch gegen unbefugtes Löschen, sowohl von Seiten der Backup-Applikation als auch von Seiten des DataDomain Administrators geschützt werden.

FAZIT:

Wie Sie sehen, ist Ihre Datensicherung mit NetWorker in sicheren Händen. Vorausgesetzt Sie kennen die richtigen Schrauben und Attribute und konfigurieren Ihre Backup-Umgebung danach. Sollten Sie bei einem der obigen Punkte Bedarf für eine Beratung sehen, so können wir Ihnen entweder unseren NetWorker Workshop Admin 3 (Advanced) empfehlen, oder Sie buchen den Autor. dieses Blog-Beitrages für eine vor Ort Beratung.