IBM System Storage-Kompendium

IBM Storage Software
Tivoli Storage Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke
Wie alles begann … 1983–1993
Wenn man bedenkt, dass große Teile der heute verwendeten
Architektur im Tivoli Storage Manager vor 20 Jahren
konzipiert wurden, kann man die Leistung der damaligen
Entwickler nicht hoch genug einschätzen. Besonders nachhaltig
prägen dabei die Architektur­Elemente „forever incremental“,
die Nutzung einer transaktional arbeitenden
Meta­Datenbank und die „tiered storage“­Konzeption den
Gesamt erfolg der TSM­Lösung. Gerade diese Komponenten
sind heute noch wirkungsvolle Differenzierungskriterien zu
anderen Angeboten auf dem Markt.
Die ursprünglichen Ideen für eine Datensicherungslösung
stammen ab Anfang der 1980er­Jahre aus Entwicklungen in
Almaden von Mark Brown, Robert M. Rees und Michael D.
Penner auf der Plattform VM/370. Sie entwickelten eine
Anwendung für den internen Gebrauch mit dem Namen
CMSback, die es erlaubte, Einzeldateien von CMS­Minidisks1 im VM inkrementell zu sichern und zu restaurieren. Zu dieser
Zeit konnte man mit Betriebssystemmitteln CMS­Minidisks
nur als Dump­Volume über DDR (Data Dump Restore)
sichern und rekonstruieren.
Ankündigungsbroschüren DataKeep/VM (Name verworfen) und WDSF/VM
Bob Rees beschreibt die Anwendungskomponenten von
CMSback so:
“In CMSback we explored a crawling model where:
• a central process crawled user ’file systems‘ (VM minidisks)
looking for files that have been changed or deleted
• a framework for supporting tape drives together with disk
• a restore GUI that could communicate with a central server to
allow users to restore their own files.”
In der Folge enstand ein internes Projekt mit Namen
AMORE (Almaden Multi­Operating system backup and
REstore), das eine Reihe von Ideen aus CMSback, RDBMS
Research­Projekten und anderen internen Tools aufgriff.
Diese Initiativen mündeten schließlich Ende der 80er­Jahre
im formalen Projekt Datakeep/VM – einer gemeinsamen
Entwicklung zwischen den Labors in Almaden und Endicott.
Parallel dazu gab es eine weitere Entwicklung zu diesem
Thema in Tucson/Boulder mit Namen E­SMS.
1 CMS = Cambridge Monitoring System – die Realisierung eines virtualisierten
Single-User Systems im Mainframe-Betriebssystem VM, in dem ein
Benutzer in einer eigenständigen System-Umgebung interaktiv arbeiten kann
und als Speicherressourcen „Minidisks“ bereitstehen, die er beliebig mit
Daten oder Programmen verwenden oder mit anderen teilen kann – analog
zu den Möglichkeiten, die heute ein PC/Laptop-Benutzer oder ein VMware-
Benutzer auch hat.
178 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang