Der Bensheimer Systemintegrator Concat kam auf die ungewöhnliche Idee, EMC-Isilon-Storage-Systeme mit dem OneFS-Betriebssystem, das ursprünglich als Produktionssystem für die Video- und Broadcasting-Industrie konzipiert wurde, als Backup-Target für den TSM (Tivoli Storage Manager) zu verwenden. Über die Hintergründe und die Vorteile einer solchen Lösung sprach speicherguide.de mit Stéphane Criachi, Solution Architect bei Concat, im Umfeld des »TSM Symposium« in Berlin letzte Woche.

Wie kommt man auf die Idee, den TSM (Tivoli Storage Manager) von IBM mit dem Isilon-Storage-System von EMC zu kombinieren?

Criachi: Aus der Historie und einer eigenen Marktanalyse wissen wir, dass sich TSM-Kunden schon immer einen fast unbegrenzt großen Storage-Pool gewünscht haben, der bezahlbar ist. Disk ermöglicht die Abarbeitung von multiplen Mounts, was das Backup- und Restore-Zeitfenster für bestimmte klassifizierte Daten optimiert. Da Disk in der Regel aber sehr teuer war und ist, haben sich solche Konzepte nur bedingt durchgesetzt. Häufig wurde Disk nur für die Sicherung der täglichen Änderungsdaten eingesetzt mit dem Ziel, diese Daten nachgelagert auf günstige Tape-Medien zu kopieren bzw. zu migrieren. Um die Restore-Zeiten zu verbessern, haben sich historisch Lösungen am Markt etabliert, mit denen es gelang, basierend auf NFS/VTL mit Tape-Caching oder Inline-Dedup die Disk-Kosten zu senken. Als mittlere Tier-Stufe zwischen Storage-Pool und Tape haben sich bei etlichen Kunden VTLs durchgesetzt.
Nun stellte sich für uns und viele Kunden die Frage, wie man mit schlecht zu deduplizierenden Daten umgehen soll, die heute auf Tape vorgehalten werden und keine guten Restore-Zeiten bieten. Wir sprechen hier insbesondere von Datenstrukturen, die beim Restore multiple Mounts erzeugen und die Tape-Drives auch nicht streamen können (geringer Nutzungsgrad).
Für solche Daten wäre Disk für die Ablage der primären Kopie von erheblichem Vorteil. Die zweite Herausforderung stellt sich aber dann, wenn der Disk-Pool aufgrund seiner notwendigen Größe zur Ablage der Primärkopie nicht mehr einfach zu verwalten ist und dadurch enorme operative Aufwendungen verursacht.

Sie holen weit aus…

Criachi: Das ist auch nötig. Die gerade erwähnte Herausforderung hat uns motiviert umzudenken und eine Lösung zu entwickeln, die TSM-Service-Funktionen storageseitig unterstützt und eine Antwort für Cloud-Anbieter im Kontext »TSM-as-a-Service« bietet: Ziel war die Bereitstellung eines Storage-Pools, der aufgrund seiner Architektur den Aufwand des Storage-Managements für die Backend-Verwaltung (Raid, LUNs, Volumes, Filesysteme, Filesystem-Migration) eliminiert und gleichzeitig ein distributed-shared-clustered-activ-activ-Filesystem mit linearer Skalierbarkeit zu einem sehr günstigen Preis pro GByte bietet.
Bei der Markterhebung haben wir uns alternative Storage-Konzepte führender Hersteller für Scale-Out angeschaut. Dabei wurde schnell klar, dass traditionelle Scale-Out-Storage-Plattformen einen nicht zu unterschätzenden Aufwand für die Backend-Verwaltung erzeugen. Isilon mit OneFS war somit die beste Storage-Plattform für den Einsatz unter TSM als Storage-Pool.

Was ist das Besondere an EMC/Isilon für diese Lösung?

Criachi: Isilon wurde von Anfang an für Scale-Out-Anforderungen entwickelt. Lineare Skalierbarkeit, eine extrem einfache Administration und ein hoher Automatisierungsgrad für Erweiterungen und Scale-Out waren als Ziele definiert. Wird mehr Kapazität benötigt, ist ein weiterer Knoten (maximal 144 TByte aus 36 Festplatten) einfach hinzuzufügen. Das Maximum sind derzeit 144 Knoten. Einen weiteren Knoten einzubinden dauert nur ganze 60 Sekunden: Gerät ans Stromnetz und ans Speichernetzwerk anschließen, hochfahren, dann wird man gefragt, ob man damit den Isilon-Cluster wirklich erweitern will, bestätigen – das war’s. Es ist nur ein Knopfdruck. Und schon hat man nach dem Autobalancing weitere 144 TByte brutto im Cluster. Storage-Administratoren werden hier massiv entlastet – weil, einmal eingerichtet, reduziert sich der operative Aufwand drastisch.
Die Tests mit TSM und Isilon in unserem Kundenlabor in Bensheim haben unseren Ansatz bestätigt. Die gewonnenen Erkenntnisse waren so vielversprechend, dass wir den Einsatzzweck für TSM und Isilon konzeptionell angingen und die Lösung entwickelten.

Aber es ist ja nicht nur die Isilon-Hardware, auch das Filesystem scheint interessant zu sein…

Criachi: Für TSM präsentiert sich OneFS als ein Distributed-shared-Filesystem, das per NFS/SMB gemounted wird. Die eigentliche Bereitstellung von OneFS für TSM erfordert minimalen Aufwand. Und da es nur ein Filesystem gibt, können sich etliche TSM-Instanzen das gesamte Filesystem teilen, was plötzlich völlig neue Möglichkeiten bietet.

Und Sie vertrauen auch darauf, dass der TSM weiter mitspielt?

Criachi: Dass wir auf dem richtigen Weg sind, zeigt die Roadmap für TSM. Dort ist vorgesehen, sich zukünftig von Konzepten für Random-Storage-Pool zu verabschieden bzw. künftige und heute verfügbare neue Funktionen basierend auf einem sequenziellen Storage-Pool vorauszusetzen.
Beim Ausarbeiten der Lösung haben wir insbesondere Node-Replication, Sicherung von virtuellen Umgebungen und Source-Deduplikation ins Auge gefasst. Unabhängig davon betrachteten wir konzeptionell progressive-incremental und Client-Kompression bzw. die Auswirkungen von Source-Encryption und Oracle-advanced-Kompression.

Welche Rolle spielt Deduplizierung bei diesen Überlegungen?

Criachi: Wir sehen den Trend, dass insbesondere die Deduplikation und Kompression in die Applikation wandert bzw. die Backup-Software solche Funktionen bereitstellt, um die Full-Backups soweit wie möglich zu eliminieren. Die Rechenleistung für Source-Dedup wird auf die CPUs der zu sichernden Clients verteilt, die notwendige Netzwerkbandbreite reduziert.

Das hieße, der aktuell boomende Markt rund um Target-Deduplizierungslösungen könnte hin zu Source-Deduplizierung tendieren?

Criachi: Historische Lösungen, die targetseitig für Backup deduplizieren, lösen das Problem der zyklischen Full-Backups nicht. Ab einer bestimmten Datenmenge können Full-Backups trotz Verteilung auf Wochentage nicht mehr in den geforderten Zeitfenstern durchgeführt werden. Denn die größte Herausforderung beim Backup sind unstrukturierte Daten, die zum Teil nicht mehr gesichert werden, weil die Datenmengen zu groß sind. Zwar werden diese Filesysteme alternativ anstelle eines Backups asynchron repliziert und mit SnapShot-Versionen vorgehalten, jedoch ersetzt Data-Protection kein Backup und ist auch kein Medienbruch. TSM stellt mit seiner Architektur entsprechende Funktionen zur Verfügung, um die zu sichernden Datenmengen an der Quelle zu reduzieren. Für die Sicherung großer Filesysteme werden Funktionen wie Easy-Change-List, Snapdiff und progressiv-incremental verwendet. Die Erkenntnis darüber, wie TSM sich in den kommenden Versionen weiterentwickelt, ermöglichte uns die dafür passende Storage-Plattform mit Isilon OneFS zu identifizieren.

IBM hat auch vor einiger Zeit die unter dem TSM liegende Datenbank ausgetauscht. Was bedeutete dies für Ihre Lösung?

Criachi: Mit dem Umstieg auf DB2 als Datenbank für TSM wurden weitere Voraussetzungen geschaffen für Skalierbarkeit, Node-Replikation und Hochverfügbarkeit basierend auf HADR. Kombiniert man dies mit dem General-Storage-Cluster-Controller (GSCC), werden die Services von TSM auf Ebene der Instanzen und TSM-Services basierend auf HADR hochverfügbar und transparent bereitgestellt. Durch den Einsatz von DB2 HADR und GSCC wird für das Clustering der TSM-Instanzen kein SAN benötigt, sodass man auch internen Flash-Speicher zur Ablage der TSM-Datenbank nutzen kann.

Wie weit ist eigentlich der TSM verbreitet?

Criachi: Mit all den grundsätzlichen Eigenschaften einer Backup-Lösung hat sich TSM in den letzten 20 Jahren im Markt bei den großen Kunden etabliert. Die wesentliche Stärke von TSM ist, dass all die Eigenschaften und Funktionen unabhängig sind von der Storage- und Tape-Infrastruktur. TSM virtualisiert die angeschlossenen Storage-Pools. Das macht Betreiber sehr flexibel bei der Ablösung von Storage und in ihrer Dual-Vendor-Strategie. Damit erfüllt TSM die Attribute für »Software-Defined Storage«.

Was können Anwender denn an Durchsatz erzielen?

Criachi: Durch eine konfigurierbare entsprechende TSM-Volume-Größe wird der Nutzungsgrad von OneFS für Durchsatz (Striping) und Nettokapazität sichergestellt. Die Sicherung der TSM-Client-Session erfolgt mit hoher Parallelität, wobei jede Session ihr eigenes Volume sequenziell beschreibt und liest. Damit erreicht man einen Durchsatz von bis zu ca. 350 MByte/s Single-Stream mit nur 144 SATA-Platten und NFS (Linux, Unix).
Isilon wurde für Scale-Out-Anforderungen entwickelt, wobei sich der TSM-Workload wie eine Streaming-Applikation verhält und die Möglichkeiten von Isilon voll ausschöpft. Bei 144 SATA-Disks haben wir bei unseren Tests einen Durchsatz von ca. 1.200 MByte/s mit 1.000 parallelen Sessions schreibend und/oder lesend erreicht. Durch einen Algorithmus werden die NFS/CIFS-Verbindungen der TSM-Instanzen auf die Frontend-Ports der Isilon-Knoten automatisch symmetrisch verteilt (Scale-Out).

Mit welchen Deduplizierungs-Faktoren kalkulieren Sie eigentlich?

Criachi: Ob nun der Kunde Source-Funktionen für Dedup, Kompression und/oder Encryption nutzen wird, verbleibt eine Anforderung in der Fachabteilung. Das Konzept mit TSM und Isilon ist davon unabhängig, da der Business-Value keinen Dedup-Faktor oder Kompression voraussetzt. Wir betrachten Dedup als »nice to have«, da die Dedup-Faktoren nicht garantiert werden können und ein darauf basierender Business-Case ein Risiko darstellt. Sollte jedoch der Einsatz von Dedup oder Kompression möglich sein, wird der Wert dieser Gesamtlösung drastisch gesteigert.
Das Konzept ermöglicht dann auch bei einem schlechten Dedup- oder Kompressions-Faktor von beispielsweise x3 eine nominale TSM-Kapazität von 45 PByte netto und 138 TByte/h Durchsatz beim Vollausbau von OneFS.

Bei all den Vorteilen dieser Backup-to-Disk-Lösung – kommt bei Ihrem Konzept Tape noch vor?

Criachi: Fakt ist, dass die großen Datacenter nicht auf Tape verzichten werden. Unser Konzept basiert darauf, immer einen Backup-Storage-Pool von Isilon auf Tape über TSM gesteuert zu ermöglichen. Als wir das Konzept erarbeitet haben, war es uns daher wichtig, den dafür notwendigen Single-Stream für die Nutzung von TS1140 und LTO-6 sicherzustellen. OneFS als TSM-Storage-Pool eignet sich ausgezeichnet zur Sicherung von Daten und zur Ablage der primären Kopie, die keinen oder einen schlechten Dedup-Faktor ausweisen, über LAN gesichert werden und von Disk wiederhergestellt werden müssen. Für den Medien-Bruch wird eine Kopie auf Tape erstellt. Natürlich steht es den Kunden frei, Isilon als grundsätzliches Target für alle LAN-basierenden Backups zu nutzen.

Eigentlich müsste Ihr TMS-Isilon-Kombi doch etwas Kopfzerbrechen bei Backup-Appliances-Anbietern verursachen?

Criachi: Das ist gar nicht unser Ansinnen. Wir wollen keinesfalls alle derzeitigen Konzepte infrage stellen, sondern mit Isilon eine weitere Option bieten, um die Leistungsfähigkeit einer Backup- und Restore-Infrastruktur für TSM-Policy-Based-Dynamic-Tiering zu verbessern. Die Concat AG gehört seit Jahren zu den erfolgreichen Integratoren von VTLs mit Inline-Deduplikation. Wir wissen, dass diese Lösungen weiter für gezielte Anforderungen benötigt werden.

Wie sieht Ihre Roadmap für die Lösung aus?

Criachi: Wir stehen erst am Anfang. Aber die Zertifizierungen sind gemacht, und die ersten Testinstallationen laufen. Letzte Woche auf dem »TSM Symposium« in Berlin haben wir die Lösung erstmals der Öffentlichkeit vorgestellt. Ich referierte dort mit Dr. Stefan Radtke, CTO EMEA von EMC/Isilon.

.