Mit »dsmISI MAGS« haben der Bensheimer Systemintegrator Concat und sein Partner General Storage vor wenigen Tagen ein Modul für den TSM (Tivoli Storage Manager) vorgestellt, das die inkrementelle Sicherung großer produktiver File-Services beispielsweise von EMC, HDS, HP, IBM, Netapp oder Windows in endlicher Zeit ermöglicht. TSM-Kunden sollen damit unstrukturierte Daten deutlich schneller identifizieren und sichern können, das Backup beschleunigt sich rasant. speicherguide.de sprach darüber mit Stéphane Criachi von Concat, und Karsten Boll von General Storage.

  Welche Zielgruppe möchten Sie mit »dsmISI MAGS« ansprechen?

Anzeige

Stéphane Criachi, Solution Architect, ConcatCriachi: Mit der Entwicklung von dsmISI MAGS sprechen wir Kunden mit unstrukturierten Daten (Big Data/File Services) an. Wir adressieren hier ein allen bekanntes Problem im Kontext der langen Laufzeiten für Filesystem-Scans vor dem eigentlichen inkrementellen Backup. Das Wachstum unstrukturierter Daten in Unternehmen liegt zwischen 20 und 60 Prozent pro Jahr – Tendenz steigend.

  Gibt es heute schon Standards, wie unstrukturierte Daten gesichert werden?

Criachi: Bei unstrukturierten Daten, wie sie insbesondere auf NAS-Systemen liegen, ist die Situation komplizierter. Eine klare Regelung zur Sicherung von unstrukturierten Daten gibt es noch nicht! Das enorme Wachstum unstrukturierter Daten bzw. Fileobjekte stellt wiederkehrende Herausforderungen an die Backup- und Restore-Konzepte. Dabei beeinflusst die Anzahl der Objekte in einem Filesystem, unabhängig von der Anzahl geänderter Objekte, drastisch die Gesamtlaufzeit für TSM-Backup. Der Mehrwert eines inkrementellen Backups mit TSM rechnet sich dann nicht mehr, wenn aufgrund der Gesamtlaufzeit durch den zuvor notwendigen Filesystem-Scan die Service-Levels nicht mehr eingehalten werden können.

  Was halten sie von NDMP, welches doch seit Jahren genutzt wird?

Criachi: Alternative Konzepte, basierend auf NDMP, machen die Kunden nicht glücklich und erzeugen Abhängigkeiten vom NDMP-Protokoll des jeweiligen Herstellers beim Restore (kein Restore auf eine andere Hardware möglich). Zumal NDMP keine inkrementelle Sicherung unterstützt bzw. wiederkehrende Full-Backups notwendig macht.

  Durch das starke Wachstum bei unstrukturierten Daten empfehlen mittlerweile etliche Experten, dass die Daten bereits an der Quelle klassifiziert werden sollten. Also nicht mehr alle Daten in den Backup-Prozess wandern, sondern vor allem die unstrukturierten gleich in Archivierungs-Architekturen. Was halten Sie davon?

Criachi: Wir unterscheiden bei der Datenklassifizierung, ob es um Archivdaten mit Unveränderbarkeit geht oder um Daten, die ausgelagert werden sollen, um das Backup-Zeitfenster zu reduzieren. Eine Datenklassifizierung durch ein ILM-System (Information Lifecycle Managementsystem), das das Backup-Volumen reduziert bzw. Daten mit weniger Zugriff auslagert, wird dann näher betrachtet, wenn die Backup-Zeitfenster aufgrund wiederkehrender Full-Backups für unstrukturierte Daten aufgrund des Wachstums nicht mehr durchführbar sind. Da die unstrukturierten Daten jedoch oftmals auf NAS-Storage wie zum Beispiel NetApp, Isilon oder HDS liegen, müssen solche Storage-Architekturen in ein ILM integriert werden können, um Daten vom produktiven Speicher in eine günstigere Tier-Klasse verschieben zu können. Die Erfahrung der letzten Jahre hat gezeigt, dass ILM-Projekte beliebig komplex und nicht zwingend günstiger sind.

  Und warum ist das beim TSM anders?

Backup-Konzept im TSM-Umfeld mit »dmsISI MAGS« und EMC-Isilon (Bild: Concat/General Storage)Criachi: Für TSM-Kunden stellt sich diese Frage eher nicht, da mit TSM unstrukturierte Daten ausschließlich inkrementell gesichert werden. Grundsätzlich sehen wir den Trend, nur noch die Änderungsdaten zu sichern und keine Full-Backups mehr durchzuführen. Durch die Sicherung ausschließlich inkrementeller Daten werden Backup-Zeitfenster und Infrastrukturvoraussetzungen drastisch reduziert. Lösungen wie Client-Dedup, SnapDiff, Isi_Change_List, ausschließlich Incremental-Backup, Changed-Block-Tracking sind Methoden, welche die zu sichernden Datenmengen an der Quelle reduzieren, da letztendlich entweder die Change-Rate oder ausschließlich Incremental gesichert wird. Eine Datenklassifizierung durch ein ILM ist dann für die Optimierung der Backup-Zeitfenster kein Mehrwert mehr. Wir schließen bestimmte Anwendungsfälle nicht aus, bei denen sich ILM-Lösungen rechnen, sehen das aber eher als Ausnahme.
Seitens der führenden Storage-Hersteller wird der Preis pro nutzbarem GByte immer günstiger, so dass durch Zusatzfunktionen wie Kompression oder Deduplizierung die Online-Storage-Kosten weiter reduziert werden. Das animiert die Kunden dazu, die Daten online vorzuhalten um die Komplexität von ILM zu vermeiden.
Mit dsmISI MAGS unterstützen wir den traditionellen Ansatz von TSM mit ausschließlich Incremental-Backup und reduzieren drastisch die Zeit, welche für den Filesystem-Scan während des Backups der Änderungsdaten benötigt wird.

  Und was ist mit Methoden für SnapShot?

Criachi: Andere Methoden wie Snapshot und Replikation eignen sich zur schnellen Wiederherstellung im Disaster-Recovery-Fall, ersetzen jedoch kein TSM-Backup mit Medienbruch. Methoden für SnapDiff mit Bereitstellung einer File-Change-List, um den TSM-Filesystem-Scan nicht durchführen zu müssen, stehen aktuell nicht für alle Filesysteme zur Verfügung, obwohl das eine wünschenswerte Funktion wäre.
Auf ein Backup mit Medienbruch zu verzichten und Lösungen basierend auf SnapMirror/SnapVault oder syncIQ/SnapShotIQ zu nutzen, ist oftmals der einzige Weg, um überhaupt noch Data-Protection aufrechterhalten zu können. Da wir jedoch den Medienbruch mit TSM empfehlen, benötigen wir eine praktikable Lösung, welche die eigentlichen Stärken von TSM, verschiedenste Fileservices inkrementell zu sichern, ausnutzt.

  Wie stark ist denn der TSM in der Branche verbreitet, dass sich eine Entwicklung wie »dsmISI MAGS« für die Sicherung unstrukturierter Daten in diesem Umfeld rentiert?

Criachi: TSM ist bei etlichen mittelständischen und großen Kunden weltweit eine zentrale Plattform für Backup-Restore. So sehen wir in dieser Zielgruppe einen sehr großen Anteil von unstrukturierten Daten auf NAS-Storage wie zum Beispiel NetApp, Isilon und Windows. Aus den geschilderten Gründen lassen sich Fileservices mit vielen Millionen Objekten nicht mehr so ohne weiteres mit TSM sichern, da der dafür notwendige Filesystem-Scan zu lange dauert. Für TSM-Kunden ist der Einsatz von dsmISI MAGS eine extreme Optimierung, da wir den TSM-Prozess für ausschließlich incremental drastisch beschleunigen. Für TSM-Kunden, die einen Medienbruch zur Aufrechterhaltung der Service-Levels benötigen und heute nicht mehr in der Lage sind, einen solchen zu erstellen, sehen wir ein sehr großes Potenzial mit dsmISI MAGS. Es wird ab dem 17.06.2015 einen Gratis-Download für Endkunden geben, um dsmISI MAGS zu testen. Diese Testversion wird auf der Concat-Webseite bereitgestellt.

  Welche Vorteile bietet hier »dsmISI MAGS« für die Sicherung unstrukturierter Daten? Was macht denn MAGS anders oder besser als der TSM-Client bei Sicherungen mit vielen Objekten?

Karsten Boll, Mitgründer, General StorageBoll: MAGS ersetzt nicht den TSM-Client, sondern setzt ihn effektiver bzw. massiver ein, wie der Name schon sagt: »Massive Attack General Storage – MAGS«. MAGS parallelisiert also den TSM-Client, ohne die vorhandene Backup-Struktur zu verändern.

  Der TSM-Client kann aber doch bereits jetzt schon über viele parallele Sessions mit dem TSM-Server kommunizieren…

Boll: Ja, für die Datenübertragung selbst, aber der Abgleich der aktuellen Daten mit den bereits gesicherten Daten für die inkrementelle Sicherung skaliert nicht entsprechend. Deswegen benötigen wir viele unabhängige, parallele TSM-Clients. MAGS startet also möglichst viele davon.

  Das klingt nach einem einfachen Ansatz…

Boll: Ja, tatsächlich, die Grundidee ist einfach, viele Kunden haben ja auch bereits begonnen, ihre großen Filesysteme mit mehreren parallelen Clients zu sichern. Dazu muss aber die Filesystem-Struktur manuell zwischen diesen Clients aufgeteilt werden. Das wird mit der Größe immer schwieriger zu organisieren und zu administrieren. Änderungen und ungleichmäßige Verteilung der Objekte im Filesystem führen direkt zu Problemen.
MAGS automatisiert die Analyse, Aufteilung und auch die ständige Optimierung der Sicherung; und das nicht nur in den oberen Directory-Ebenen, sondern in der erforderlichen Tiefe, um die Parallelität massiv zu steigern. Besonders wichtig ist aber, dass am Ende ein Gesamt-Backup-Report zur Verfügung steht und das Filesystem im TSM in der ursprünglichen Struktur verfügbar ist, was gerade den Restore vereinfacht.

  Herr Criachi sprach von Change-Listen, die File-Server liefern könnten, als die vermeintlich optimale Lösung, um den TSM-Scan zu umgehen. Wie passt das zu MAGS?

Boll: Wir sehen das als zukünftige Erweiterung von dsmISI und MAGS. Eine Change-Liste wird aber immer vom Filesystem abhängen, und die Erstellung der Liste muss ja auch verlässlich und performant sein. Mit Isilon arbeiten wir beispielsweise an einer solchen Integration, können aber noch keine Verfügbarkeit nennen. MAGS ist heute für alle Fileserver verfügbar und wird auch mit Change-Listen eine wichtige Rolle bei periodisch notwendigen Full-Scans spielen.

  Auf welcher Plattform läuft MAGS? Es lassen sich ja nicht auf allen File-Servern direkt Clients betreiben…

Boll: MAGS greift mit den TSM-Clients in der Regel über SMB (unter Umständen auch NFS) auf die Daten zu, kann also alle üblichen Fileserver sichern. MAGS wird auf einem separaten Windows-64-Bit-Server eingerichtet.

  Gibt es zusätzliche Hardware-Anforderungen?

Boll: In den meisten Fällen wird keine zusätzliche Hardware für TSM-Clients oder -Server benötigt, um dsmISI MAGS zu nutzen. MAGS setzt für optimale Leistung entsprechend ausgestattete Hardware sowohl auf Seiten des Fileservers, als auch bei den für die Sicherung genutzten TSM-Clients und beim TSM-Server voraus. Letztendlich ist das von der Anzahl der Objekte und der erwarteten Sicherungszeit abhängig. MAGS passt die Ressourcennutzung an die verfügbare Umgebung an, von eingeschränkter Nutzung bis zu Skalierung über weitere Windows-Server. Kunden können sich gerne für Details, weitere Beratung oder eine Testlizenz mit Concat in Verbindung setzen.

  Warum funktioniert diese Kombination aus TSM, Isilon und dsmISI MAGS eigentlich so besonders gut? Könnte es nicht auch andere Kombinationen mit weiteren Backup-/Data-Protection-Paketen oder Backup-Zielsystemen geben?

Boll: dsmISI MAGS unterstützt grundsätzlich alle Fileserver-Varianten, die über SMB angesteuert werden können. Damit wird die Grundlage geschaffen, sowohl SMB- als auch NFS-Daten zu sichern. Da dsmISI MAGS auch Scale-Out-Filesysteme wie Isilon/OneFS unterstützt, können wir mit dsmISI MAGS entsprechend linear mit den Isilon-Knoten skalieren. Wir sehen im »incremental forever«-Prinzip vom TSM die Möglichkeit, überhaupt erfolgreich eine so große Dateianzahl und Datenmenge zu sichern, da keine periodischen Full-Backups mehr erforderlich sind.
Dieses Konzept basiert aber auf dem Abgleich der aktiven Daten und der bereits gesicherten Daten. An diesem Punkt stößt TSM an die bereits beschriebenen Grenzen, die wir mit dsmISI MAGS entscheidend verschieben. dsmISI MAGS nutzt und optimiert also speziell die TSM-Funktionalität.