Seit einiger Zeit plagten sich einige unserer Kunden und damit auch ich, mit den Problemen, wie kann man bei der Sicherung auf DataDomain Systemen feststellen:

• warum laufen Sicherungen mal schneller oder mal langsamer?

• warum wurden DataDomain-Cloning Aufträge erst nach mehreren „Retrys“ durchgeführt oder gar ganz abgebrochen?

• wie hoch war die Auslastung der DataDomain Streams zum Zeitpunkt ‚X‘?

Eine Antwort auf die letzte Frage war bisher nur sehr schwer möglich. Die DataDomain Systeme haben keine native Möglichkeit, die Anzahl der aktiven Streams nachträglich anzuzeigen. Die einzige Information zu den aktiven Streams, die man meines Wissensstandes nach erhalten kann, ist eine Text-Ausgabe der verwendeten Streams pro Storage-Unit mit Hilfe des Kommandos „ddboost streams show“. Um aus diesen ASCII-Werten jedoch eine brauchbare Ausgabe zu erzeugen, die es ermöglicht am Montag nachzuschauen, wie die Auslastung des Systems am Samstag um 23:15 war und dabei auch noch sagen zu können, welcher Backup-Server war Schuld an der Überlastung des Systems: bedarf es etwas mehr, als die Ist-Werte eines Kommandos in einer ASCII-Datei abzulegen.

Das Ziel war eine Oberfläche zu schaffen, in der man für jeden beliebigen Zeitpunkt in den letzten „n‘ Monaten sagen kann, wie viele Sessions liefen um die Uhrzeit ‚X‘. Welche Storage-Unit und daraus folgernd welche Backup-Applikation hat zu dem Zeitpunkt ‚X‘ wie viele Sessions belegt.

Das Ergebnis:

DataDomain Monitoring über 7 Tage

Auf dieser Grafik können sie die Auslastung eines DataDomain System über die letzten 7 Tage betrachten. Das System hat 6 Storage-Units, also 6 unterschiedliche Systeme die gleichzeitig mit der DataDomain arbeiten. Die 4 Balkendiagramme zeigen die Anzahl der Session für Read, Write und Replikation-In und -Out an. Oberhalb der Balkendiagramme erkennt man in einem Tachometer die maximale Anzahl Sessions in dem gewählten Zeitfenster, sowie die maximal mögliche Anzahl von Sessions auf dem System. Man kann also auf dem obigen Bild leicht erkennen, dass das System noch reichlich Luft nach oben hat. Dennoch ermöglicht die Darstellung das Auslesen einiger interessanter Informationen. Aber schauen wir uns zunächst mal eine andere Zeitscheibe der Aufzeichnung an.

Auf dieser Darstellung lassen sich schon etwas genauere Informationen auslesen. Z.B. welcher Sicherungsserver generiert die meisten Streams. Wann beginnt die Datensicherung auf den Servern. Eventuell hilft diese Darstellung schon den problematischen Zeitpunkt zu erkennen und das Problem durch eine Verlagerung der Sicherungszeiten zu entschärfen.

Um noch genauer hinschauen zu können, können wir uns aber auch einen beliebigen Zeitraum heranzoomen.

Darstellung der DataDomain-Streams von 20:00 – 22:00

Jetzt erkennt man sehr detailliert dass in dem per Maus gewählten Zeitraum (siehe oben in der Menuleiste) 2 Server gleichzeitig mit den Sicherungsarbeiten begonnen haben. Außerdem lässt sich gut erkennen, dass währen des gesamten Zeitraums ein Server einen Wiederherstellungsauftrag mit 12 parallelen Sessions durchgeführt hat. Die parallel laufenden Replikationen waren wohl eher unkritisch.

Implementierung:

Was wird benötigt um diese Grafiken auf Basis eines interaktiven WWW-Fensters zu erhalten? Die ganze Implementierung setzt auf Software-Containern auf. Um genau zu sein, kommen DOCKER-Container auf Basis einer Docker-Maschine oder eines Kubernetis-Clusters zum Einsatz. In dem hier gezeigten Falle wurden 3 Container verwendet. Ein-Container sammelt mit Hilfe von Python-Programmen die Auslastungs-Daten ein und sendet diese an eine Datenbank. Die Datenbank befindet sich im zweiten Container. Der dritte Container beinhaltet das Auswertetool Grafana. Mit Hilfe eines beliebigen WWW-Browsers kann man die Datenbank mit Grafana verknüpfen und erhält die hier gezeigten Grafiken. Sollten mehrere DataDomain Systeme betrachtet werden, so wird pro DataDomain-System ein Aufzeichnungs-Container gestartet. Auch die Sicherheit kommt bei dieser Implementierung nicht zu kurz. Die Werte aus dem DataDomain-System werden mit Hilfe einer SSH-Verbindung von einem Read-Only-Benutzer ermittelt. Die Datenbank ist nur innerhalb der DOCKER-Umgebung bzw. innerhalb des Kubernetis-Clusters sichtbar. Die Grafana WWW-Seite verlangt eine Benutzer-Autorisierung.

Fazit:

Mit Hilfe einer DOCKER-Umgebung, einer freien Datenbank (Influx-DB), dem frei verfügbaren Darstellungsmodul Grafana und unseren Aufzeichnungsskripten, kann man die Auslastung einer DataDomain, aber auch das Lastverhalten der Sicherungs-Server Minutengenau analysieren.

Sollten Sie Interesse an der hier gezeigten Lösung haben, so scheuen Sie sich bitte nicht uns zu kontaktieren. Sollten Sie zusätzlich zur DataDomain auch noch das Backup-Produkt NetWorker im Einsatz haben, dann sollten sie sich auch unseren Blog NetWorker-Session- Monitoring anschauen.