23.08.2013 (eh)
4 von 5, (10 Bewertungen)

Concat verwendet Isilon-Storage für TSM-as-a-Service

  • Inhalt dieses Artikels
TSM-Storage-Pool mit »OneFS« skaliert bis 15 PByte (Bild: Concat)
TSM-Storage-Pool mit »OneFS« skaliert bis 15 PByte (Bild: Concat)

Der »Tivoli Storage Manager« (TSM) von IBM ist bei Großunternehmen weit verbreitet. Doch kaum jemand benutzt EMC-Isilon-Storage-Systeme mit dem »OneFS«-Betriebssystem, die als Produktionssysteme für die Video- und Broadcasting-Industrie konzipiert wurden, als Backup-Target für den TSM. Dabei hätte diese Kombination unschlagbare Vorteile, meint der Bensheimer Systemintegrator Concat. Er hat jetzt nach ersten Tests ein TSM-Konzept entwickelt, das OneFS von Isilon als TSM-Storage-Pool zum Einsatz bringt. Es wird am 18. September 2013 auf dem »TSM Symposium« in Berlin erstmals vorgestellt.

Das Besondere an OneFS ist, dass es ein Single-Distributed-Cluster-Filesystem ist, und damit eine nahezu unlimitierte Zahl an Zugriffen aktiver TSM-Instanzen erlaubt. OneFS bietet überdies eine lineare Skalierbarkeit, beginnend mit wenigen TByte bis zu 15 PByte und einen Durchsatz von 138 TByte/h. Drei Knoten sind in der Isilon-Cluster-Speicherarchitektur das Minimum. Wird mehr Kapazität benötigt, ist ein weiterer Knoten (maximal 144 TByte aus 36 Festplatten á 4 TByte) einfach hinzuzufügen. Das Maximum sind derzeit 144 Knoten. »Einen weiteren Knoten einzubinden, dauert nur ganze 60 Sekunden«, erläutert Stéphane Criachi, Solution Architect bei Concat, im Gespräch mit speicherguide.de. »Es ist nur ein Knopfdruck.«

Concat nennt die Lösung TSM-as-a-Service. Damit können Unternehmen laut Concat in sehr kurzer Zeit neue TSM-Server ausrollen und Storage-Pools einrichten. Dabei würden die Gesamtkosten (OPEX/CAPEX) in TSM-Umgebungen drastisch reduziert.

TSM-as-a-Service macht nach Meinung von Concat Schluss mit RAIDs, LUNs und SANs. Administratoren müssten keine Device-Driver mehr installieren, keine Volume-Groups erweitern, keine Dateisysteme anlegen, keine Klassen erweitern oder Volumes verschieben. Stattdessen könnten IT-Verantwortliche flexibel auf unerwartete Herausforderungen reagieren, ohne das komplette TSM-Design überdenken oder ändern zu müssen. TSM-Speicher-Kapazitäten und -Durchsatz ließen sich sehr einfach und ohne Beschränkung erweitern – möglich werde dies durch die Einfachheit von OneFS.

Darüber hinaus führt Concat aus, dass TSM in Kombination mit dem »General Storage Cluster Controller« (GSCC) hochverfügbar wird, und sich als Service flexibel und transparent über beliebig viele physische Server verteilen lässt. Dazu müsse ein Administrator weder SAN-Storage noch einen komplexen Betriebssystem-Cluster implementieren.

»Da Isilon seine Daten automatisch über alle Cluster-Nodes und Disks verteilt, ist auch kein Performance- und Speicherplatz-Management notwendig«, erklärt Criachi. Der TSM-Service stehe einfach immer zur Verfügung und könne, wie der Isilon-Speicher, in kürzester Zeit an neue Anforderungen angepasst und skaliert werden, ohne die Sicherheit zu gefährden.

»Backup-to-Disk hat eigentlich, historisch betrachtet, noch keiner so richtig ausgeliefert«, meint Criachi. Die Branche behelfe sich mit Backup-Appliances. Diese arbeiteten allerdings mit Target-Deduplizierung, wodurch zunächst das gesamte Backup-Volumen (Full Backup) transferiert wird. Doch dies bringe vor allem Großunternehmen mit PByte-Volumina nun an die zeitliche Machbarkeisgrenze.

Anders dagegen beim TSM. Der hat seit Version 6 Source-Deduplikation eingebaut. Und es wird inkrementelles Backup unterstützt. »Und zusammen mit der Performance und der Scale-out-Architektur der Isilon-Systeme sind damit die Backup-Zeitfenster beim Kunden wieder einhaltbar«, erklärt Criachi. »Dann haben die Kunden wieder Spass, PByte-Storage einzukaufen.«

.

Kommentare (8)
28.08.2013 - SC

Sehr geehrter Herr Pfreundt,

FhGFS und Xtreemstore kenne ich nicht so gut, als dass ich mir ein Urteil erlauben würde.
So wie ich verstanden habe handelt es sich um Graudata.

Das Konzept sieht nicht vor die Komplexität eines HSM mit zu integrieren. Es geht um die Ablage der primären Kopie auf Disk mit einem Backupstoragepool über TSM auf Tape.
Gerade der Restore muss von Disk erfolgen und nicht über ausgelagerte Fragmente welche mit HSM auf Tape ausgelagert sind. Alle bekannten HSM Ansätze wie z. B. Tape VTL Tape Caching scheitern aus bekannten Gründen in großen TSM Umgebungen wo es um Backup- Restore-Performance geht mit multiplen parallen Mounts.

Isilon gehört ganz klar zu den Marktführen und gilt in der Branche als etablierte Lösung. Das Produkt gibt es seit 2001.

Die 138 TB/h sind nicht dass alleinige Argument, wobei 138 TB/h nicht langsam ist.
Vielmehr geht es um die Einfachheit Storage mit Isilon zu verwalten, da es keine Raidgruppen, LUNS, Volumes gibt sondern nur ein Filesystem welches das VolumeManagement insich mit der Parität vereint.
Eweiterungen erfolgen per Knopfdruck in 60 sec. pro Knoten.

Gruß
Stephane Criachi

28.08.2013 - pfreundt

Kennen Sie schon FhGFS und Xtreemstore. 138TB/h sind auch nur 40GB/sec . Das ist jetzt nicht besonders viel das aber zu einem stolzen Preis. Isilon beindruckt mich da nicht. Das FhGFS udn Xtreemstore ist da deutlich leistungsfähiger udn kann außerdem zusammen mit Tapes als HSM betriben werden

27.08.2013 - kfr

Regie-Anweisung:
Systembedingt steht der neueste Kommentar immer zu erst. Das ist normalerweise auch gut so. Zudem ist das Kommentarfeld auf 1.000 Zeichen begrentzt.

Die Beiträge von Concat (SC) sollten daher von unten nach oben gelesen werden.

Beste Grüße
Karl
speicherguide.de

26.08.2013 - SC

Die großen Datencenter werden nicht auf Tape verzichten wollen, so das dieses Konzept darauf basiert immer einen Backup-Storage-Pool von Isilon auf Tape über TSM gesteuert zu ermöglichen.
Bei der Erarbeitung des Konzeptes war es uns daher ein Anliegen den dafür notwendigen single Stream für die Nutzung von TS1140 und LTO6 sicherzustellen.
Ziel ist es nicht alle derzeitigen Konzepte in Frage zu stellen, sondern mit Isilon eine weitere Option zu bieten die Leistungsfähigkeit einer Backup- und Restore-Infrastruktur für TSM Policy Based Dynamic Tiering zu verbessern.
Wir seitens der Concat AG gehören seit Jahren zu den erfolgreichen Integratoren von VTLs mit Inline-Deduplikation und wissen, dass diese Lösungen weiter für gezielte Anforderungen benötigt werden.
OneFS als TSM Storage Pool eignet sich insbesondere zur Sicherung von Daten und Ablage der primären Kopie, welche keinen oder einen schlechten Dedupfaktor ausweisen, über LAN gesichert werden und von Disk wiederhergestellt werden müssen. Für den Medien-Bruch wird eine Kopie auf Tape erstellt.

Offene herstellerunabhängige Lösungen wie z. B. Simpana über CommVault sind aktuell im Engen Kontakt mit der Isilon, da das enorme Potential erkannt worden ist.

Ich stehe Ihnen für Fragen sehr gerne zur Verfügung bzw. würde es mich freuen, wenn wir Ihr Interesse wecken konnten.

Stephane Criachi

Weitere Link zum Thema
Blog: insightsonit.wordpress.com/2013/08/15/isilon-als-effizientes-backup-target-am-beispiel-tsm/

26.08.2013 - SC

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

26.08.2013 - SC

Zurück zum Thema Isilon!!
Es ist nicht das Ziel mit TSM Files in Isilon zu schreiben, welche kleiner oder gleich 128k sind, da dies schizophren wäre.
Ziel muss es sein, eine entsprechen TSM Volumegröße zu definieren, welche den maximalen Nutzungsgrad für Durchsatz (Striping) und Nettokapazität sicherstellt.
Mit TSM können Container-Files, Volumes mit freiwählbarer Größe eingerichtet werden für das Schreiben und lesen der einzelnen Sessions in das Filesystem OneFS.
Die Sicherung der TSM-Client, Session erfolgt mit hoher Parallelität, wobei jede Session Ihr eigenes Volume sequentiell beschreibt und liest.
So wird ein Durchsatz von bis zu 350 MB/s single Stream mit nur 144 SATA und NFS (Linux, Unix) ermöglicht.
Isilon wurde für Scale-Out-Anforderungen entwickelt, welches mit dem TSM Workload vergleichbar einer Streaming Applikation voll ausgenutzt wird.
Bei 144 SATA Disks konnte ein Durchsatz von ca. 1200 MB/s mit 1000 parallelen Sessions schreibend und oder lesend erreicht werden.
OneFS bietet darüber hinaus etliche Eigenschaften den Aufwand für das Ausrollen von TSM Instanzen und Erweiterung des Storagepool drastisch zu reduzieren.
Das wiederum wird ermöglicht, da OneFS ein shared distributed Cluster-Filesystem bereitstellt.
Dieses Filesystem wird als Aktiv-Aktiv für den parallelen Zugriff der TSM Instanzen hochverfügbar genutzt.
Durch die automatischen Verteilungs- Algorithmus werden die NFS/CIFS Verbindung der TSM Instanzen auf die FrontEnd-Ports der Isilon-Knoten symmetrisch verteilt (Scale-Out)

26.08.2013 - SC

gerne möchte ich seitens der Concat AG, Stephane Criachi auf Ihre Ausführungen eingehen.
Vorab sei zu erwähnen, dass TSM bei den führenden DAX Unternehmen in Deutschland im Einsatz ist und das nicht ohne Grund.
Mit der TSM Version 6.x bzw. zukünftig Version 7.x gibt es erweiterte Funktionalitäten welche einen sequentiellen Storage Pool voraussetzen.
Der Trend Richtung source basierender Funktionen für progressive incrementals, Dedup, Kompression und Encryption ist nicht aufzuhalten.
Zur Umsetzung solcher Konzepte bedarf es einer entsprechenden Storageplattform, welches die Eigenschaften von TSM unterstützt.
Mit dem Umstieg auf DB2 als Datenbank für TSM wurden weitere Voraussetzungen geschaffen für Skalierbarkeit, Node Replication und Hochverfügbarkeit basierend auf HADR.
Durch GSCC (General Storage Cluster Controller) 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, so dass auch internen FlashSpeicher zur Ablage der TSM DB genutzt werden kann.
Mit all den grundsätzliche Eigeneschafften einer Backup-Lösung hat sich TSM in den letzten 20 Jahren im Markt bei den großen Kunden etabliert.
Die Eigentliche Stärke von TSM ist, dass all die Eigenschaften, Funktionen nicht in Abhängigkeit zur Storage- und Tape-Infrastruktur stehen.
TSM virtualisiert die angeschlossenen Storapools und stellt damit die Flexibilität bei Ablösung von Storage und gewollter Dual-Vendor-Strategie für den Betreiber sicher.
Damit erfüllt TSM die Attribute für „Software-Defined-Storage“.

26.08.2013 - sethm

Eine Isilon als Speicher hinter TSM? Wie ich verstanden habe speichert Isilon alle Daten unter 128kn doppelt ab und ist für große Medien und Filmdaten gebaut, jedoch kein Backup Speicher.
Ausserdem ist unsere Erfahrung mit der TSM Deduplizierung (v.6.x) eher schlecht als Recht. Man könnte behaupten. Einen Dank an die EMC für die Verknüpfung von Appliance (DataDomain) und DDBoost Software mit dem NetWorker hat bei uns massive Verbesserungen erbracht. Hier hat IBM verschlafen. Daher sehe ich auch in keinster Weise einen Sinn hinter Isilon und TSM.


powered by
Boston Server & Storage Solutions Itiso GmbH
Fujitsu Technology Solutions GmbH Infortrend
N-TEC GmbH FAST LTA AG
Lenovo
Folgen Sie speicherguide.de auch auf unseren Social-Media-Kanälen
Folgen Sie und auf Facebook Folgen Sie und auf YouTube Folgen Sie und auf Twitter