IBM System Storage-Kompendium

IBM Systems and Technology Group
IBM System Storage-Kompendium
Die IBM Speichergeschichte von 1952 bis 2010
ibm.com/systems/de/storage

2
Cover Photo: IBM TS3500 Tape Library
David Hobby, USA, a.k.a. Strobist,
www.strobist.com
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Vorwort des Autors Kurt Gerecke
Sehr geehrte Kunden, sehr geehrte Geschäftspartner, liebe Leser,
begeben Sie sich auf eine spannende Zeitreise durch die IBM Speichergeschichte. Vor
bereits 58 Jahren erfand die IBM die erste externe Speichereinheit in Form des Rollenbandes
der IBM 726 mit einer Speicherkapazität von 1,4 MB. Lassen Sie sich faszinieren, was in
diesem halben Jahrhundert an Erfindungen und Produkten von IBM im Speicherumfeld ent­
wickelt und auf den Markt gebracht wurde. Vielleicht möchten Sie sich durch dieses Buch
auch an Ihre Anfangszeiten in der IT zurückerinnern und gedanklich Ihren beruflichen Werde­
gang Revue passieren lassen. Aber auch für alle jungen Menschen, die diese Zeitspanne nicht direkt erlebt haben, ist es ein
faszinierendes Nachschlagewerk.
Die beschriebenen Zeitepochen reflektieren sehr klar die ganzheitliche IBM Entwicklungsstrategie: Rechner und Speichersys­
teme gehören als Einheit zusammen! Speichertechnologien und Speicherlösungen wurden bis heute immer im Einklang mit
den Servertechnologien vorangetrieben, um ausgewogene, performante und aufeinander abgestimmte Gesamtlösungen zur
Verfügung zu stellen. Diese Strategie brachte viele neue Erfindungen hervor und machte IBM zum weltweiten Patentführer –
und das seit 17 Jahren in Folge.
Vor drei Jahren wurde der Nobelpreis für Physik an Peter Grünberg von der KFA in Jülich und Albert Fert von der Universität
in Paris vergeben, die 1988 den GMR­Effekt (Giant Magnetoresistance) bei extrem niederen Temperaturen entdeckt hatten.
Wir alle wissen, dass ohne diese Entdeckung die heutigen Festplattenkapazitäten nie möglich geworden wären. Was viele
nicht wissen, ist, dass es IBM zu verdanken ist, dass aus der Entdeckung ein Produkt wurde. Bereits 1989 begann der IBM
Forscher Stuart Parkin im IBM Labor Almaden in Kalifornien mit der Umsetzung und dem Ziel, den Effekt auch bei normalen
Temperaturen zu realisieren. Er erforschte mehr als 30.000 Materialkombinationen, um 1997 den ersten einsetzbaren GMR­
Lesekopf für Plattenlaufwerke zur Verfügung zu stellen. Alle drei Forscher wurde 1997 gemeinsam für die GMR­Entwicklung
mit dem Euro­Physik­Preis ausgezeichnet.
Vielleicht nicht alles, aber alles fundamental Wichtige wurde von IBM im Storage­Bereich entdeckt und entwickelt. Ich möchte
Ihnen neben GMR ein paar weitere Eckdaten nennen: 1991 führte IBM drei zukunftsweisende Technologien ein, Dünnfilmbe­
schichtungen auf den Platten, die ersten MR­Köpfe (Magnetoresistive Köpfe) und RAID­5­basierende Subsystemarchitekturen.
1999 entdeckte IBM den paramagnetischen Effekt und im selben Jahr brachte IBM den ersten Microdrive auf den Markt, ein
Laufwerk in der Größe einer Zwei­Euro­Münze. Im Jahr 2000 erhielt IBM als erste Firma die „National Medal of Technology for
Innovations in Storage“ von der amerikanischen Regierung, eine der höchsten technologischen Ehrungen, die bis dahin aus­
schließlich an Einzelpersonen vergeben wurde. Alle diese faszinierenden Erfindungen und viele mehr finden Sie im Techno­
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
3

4
Vorwort des Autors
logie­Anhang dieses Storage Kompendiums. Die IBM leistete auf dem Gebiet der Speicherentwicklungen
Einmaliges und ich bin überzeugt, dass dies auch in der Zukunft der Fall sein wird.
Widmen Sie Ihre Aufmerksamkeit besonders auch der jetzigen Zeitepoche, die vor allem durch Virtualisierung in
allen Bereichen der Datenspeicherung geprägt ist. Alle aktuellen IBM Produkte sind dort ausführlich beschrieben.
Das Kompendium ist also nicht nur ein historisches Nachschlagewerk, sondern informiert Sie vor allem über alle
aktuellen IBM Speicherentwicklungen.
Die Überarbeitung des IBM System Storage Kompendiums als Update 2010 erforderte doch wieder viel freie Zeit
und viele Wochenenden. Deshalb möchte ich mich zuallererst wieder bei meiner Ehefrau Gabriele für das auf­
gebrachte Verständnis bedanken. Ihre Geduld war wieder einmal bewundernswert.
Ein großer Dank gilt auch dem IBM Storage Produktexpertenteam für seine wertvollen Informationen. Herrn Dr.
Stefan Radtke möchte ich für seine technischen Ausführungen des XIV Storage Systems danken, Herrn Jens
Gerlach von der Firma LSI für seinen DS5000­Input, Herrn Stefan Neff für seinen TS7700­Beitrag, Herrn Hartmut
Grund für seine Hilfe beim IBM Information Archive, Jürgen Loeb für seinen SOFS­ bzw. SPSC­Input und Axel
Melber für die Fotobearbeitung der Exponaten­Sammlung.
Ganz besonders möchte ich mich bei den Herren Hans W. Spengler und Heinz Graichen vom IBM Museum in
Sindelfingen für ihre tabellarischen Zusammenstellungen, Grafiken und Bilder von der jetzt im Museum fertig­
gestellten Plattenrotunde und dem Interview mit mir bedanken, bei dem beide den RAMAC 350­Zugriff detailliert
darlegen. Ebenso möchte ich mich bei beiden dafür bedanken, dass ich die Plattenprofile, die vor allem Hans
W. Spengler in einer zehnjährigen Arbeit zusammengestellt hat, in dieses neue Kompendium integrieren konnte.
Allen anderen Kollegen, die mir dabei geholfen haben und jetzt nicht namentlich erwähnt sind, gilt ein ebenso
großes Danke.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Mein Dank gilt auch Herrn Ivano Rodella von IBM System Storage Marketing, der die Agenturarbeit ermöglichte,
sowie den Sponsoren, die den Druck dieses Kompendiums finanziell unterstützt haben.
Am meisten freut mich, dass ich die Herren Werner Bauer und Klemens Poschke, alle langjährige Kollegen und
Freunde, dafür gewinnen konnte, an diesem Kompendium mitzuarbeiten. Werner hat das Thema des System­
verwalteten Speichers (System Managed Storage) im Mainframe­Umfeld aufgearbeitet. Klemens hat die
Geschichte des Tivoli Storage Managers (TSM) dokumentiert, der dieses Jahr sein 20­jähriges Bestehen feiert.
Ebenso ganz herzlich bedanken möchte ich mich bei Edelgard Schittko, die sich einfach ganz kurzfristig dazu
bereiterklärte, das Thema BRMS im System i Umfeld aufzuarbeiten. Damit reflektiert das Kompendium jetzt eine
ganzheitliche Dokumentation der wichtigsten Storage­Hardware­ und ­Softwareprodukte.
Ein bisschen Reklame möchte ich auch noch machen! Sollten Sie sich im Raum Stuttgart aufhalten, vergessen
Sie nicht, das IBM Museum, das Haus der Geschichte der IBM Datenverarbeitung, Bahnhofstraße 43 in 71063
Sindelfingen zu besuchen. Dort können Sie „live“ die Geschichte der Informationstechnologie von 1890 bis ins
Jahr 2000 erleben. Auch das erste Plattenprodukt der IBM, die RAMAC 350 als Teil des damaligen Rechnersy­
stems IBM RAMAC 305, können Sie dort in Betrieb sehen. Ein besonderer Höhepunkt ist die neu aufgebaute
Plattenrotunde. Begleitet von einer Diashow können Sie sich auf eine Zeitreise begeben und die faszinierenden
Produkte und Erfindungen im Plattenbereich von 1956 bis ins Jahr 2000 kennenlernen.
Melden Sie sich rechtzeitig wegen einer Terminabsprache über mich, Tel. 0170­2207066, oder Herrn Hans W.
Spengler vom IBM Museum, Tel. 07031­271378 an.
Ich wünsche Ihnen viel Freude und viel Spaß beim Lesen und Studieren des IBM System Storage Kompendiums
und hoffe, dass Sie viele Gelegenheiten haben, diese Informationen für Ihre Zwecke erfolgreich einzusetzen.
Mit den besten Grüßen
Ihr Kurt Gerecke
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
5

6
Vorwort des Co-Autors Klemens Poschke
Ein paar Worte persönlicher Bezug…
Die Idee zu einer historischen Dokumentation der Tivoli Storage Manager Soft­
ware entstand im Gespräch mit meinem Freund und Kollegen Kurt Gerecke auf der
CeBIT 2009, als er eine erweiterte Neuauflage dieses Buches zum 100­jährigen
Bestehen der IBM Deutschland 2010 plante. Ich freue mich, mit einem TSM­
Kapitel zum Erfolg des Buches beitragen zu können, weil die Geschichte von
Tivoli Storage Manager und seinen Namensvorgängen eng mit der Geschichte
der Speichertechnologie der IBM verknüpft ist. Insofern komplettiert dieses Kapitel einerseits den von Kurt
Gerecke und Kollegen verfassten Hardware­Teil, dokumentiert aber auch die Tradition der erfolgreichen gemein­
samen Arbeit zwischen den Menschen aus unterschiedlichen Bereichen der IBM.
Diese Zusammenstellung über die Geschichte des IBM Tivoli Storage Manager ist gleichzeitig auch ein Reflek­
tieren der letzten 20 Jahre meiner eigenen beruflichen Geschichte bei der IBM, da ich mich seit 1990 mit diesem
Thema als Architekturberater beschäftige. Bei der Stoffsammlung und inhaltlichen Aufbereitung habe ich mich
immer wieder gerne an viele sympathische Menschen erinnert, die ich über dieses Thema bei Kunden,
Geschäftspartnern und als Kollegen kennengelernt habe.
Das Kapitel beschränkt sich bewusst auf die Themenbereiche, in denen TSM und seine Namensvorgänger Teil
von IBM Datensicherungs­/Archiv­Lösungen sind. Ich habe dabei absichtlich auch Informationen zu Firmenüber­
nahmen und Begleitprodukten des Backup­Marktes mit aufgenommen, um die historische Entwicklung und
Marktbedeutung ganzheitlich zu beschreiben.
20 Jahre Beschäftigung mit diesem Thema ermöglichen mir, auf eine große Menge an Ressourcen zurückzugreifen,
die bei der Bereitstellung der nachfolgenden Informationen, Dokumente und historischen Bilder geholfen haben.
Ich möchte mich stellvertretend für alle Beiträge bei folgenden Kollegen besonders bedanken für die Übersen­
dung von Hintergrundinformationen, Dokumenten, Geschichten und Bildschirmfotos:
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Jim Smith (San José), Frank Albert Müller (Mainz), Chris Zaremba (Endicott), Edward Gretz (West Chester), Norm
Pass (Almaden), Barry Fruchtman (Tucson), Dr. Hans­Joachim Renger (Böblingen), Claire Rankin (San José),
Mike Welkley (San José), Paul Bradshaw (Almaden).
Besonderer Dank gilt meinen Kollegen Wolfgang Hitzler (Ehningen) und Dr. Hans­Joachim Renger (Böblingen),
die ihre Zeit geopfert haben, um den Text inhaltlich zu validieren, und meiner Frau Doris, die sich des Fach­
chinesisch auf grammatikalisch/stilistischer Ebene angenommen hat.
Ich bedanke mich auch bei den Redaktionen der Zeitschrift „Computerwoche“ (Sandra Holleber) und dem
Online Magazin „Monitor“ (Dipl.­Ing. Rüdiger Maier) für die Genehmigung, Artikelauszüge ihrer Publikationen aus
dem Internet benutzen zu dürfen.
Sollten sich trotz intensiver Recherche inhaltliche Fehler eingeschlichen haben, bitte ich dies zu entschuldigen
und mich darüber zu informieren (Klemens.Poschke@de.ibm.com).
Ich wünsche Ihnen viel Spaß und Freude beim Lesen und Studieren der 20­jährigen TSM­Erfolgsgeschichte und
verbleibe mit den herzlichsten Grüßen
Ihr Klemens Poschke
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
7

8
Speicherentwicklung und Gesamtüberblick von 1952 bis 2010
Allgemeines:
Die Geschichte der IBM Speichertechnologie und der IBM
Speichersysteme ist mit ziemlicher Sicherheit eines der faszinierendsten
Ereignisse unserer Zeitgeschichte der letzten
58 Jahre. Spannend vom Anfang bis in die heutige Zeit soll
diese Broschüre einen Überblick geben und vor allem auch
das Verständnis entwickeln, wie erfinderisch die Menschheit
sein kann, wenn es darum geht, technologische Grenzen zu
überschreiten, um neue Möglichkeiten für die Speicherung
von Daten zu eröffnen. Die Vielzahl von Produkten und Erfindungen
in diesem Bereich macht es notwendig, die Zeitgeschichte
ein bisschen zu ordnen und in zeitgeschichtliche
Epochen zu unterteilen. Da dieses Unterfangen bisher nie
gemacht wurde, erlaubt sich der Autor, das Speicherzeitgeschehen
von 1952 bis in die heutige Zeit in technologische
Epochen zu unterteilen, um dann im Detail die einzelnen
Epochen von der Produkt­ und Produktentwicklungsseite zu
beleuchten. Nach den Produktepochen schließt das Kapitel
„IBM Storage Software“ an, das die wichtigsten SW­Entwicklungen
im Speicherumfeld darstellt. Am Ende dieses
Buches im Kapitel „Technologie­Anhang“ befindet sich ein
Technologie­Teil, der die Entwicklung der Speicherbasistechnologien
und Aufzeichnungsverfahren einschließlich
anstehender Technologien näher beschreibt.
Entwicklung der Speichersysteme von 1952 bis 2010
1952 – 1961 die Anfangsepoche der
elektro magnetischen Speicherung
1962 – 1974 die Epoche der Wechselplatten
und die ‘Winchester’-Zeit
Die einzelnen Epochen beschreiben immer eine Zeitphase,
die durch besondere Produkte geprägt war, die in dieser
Zeitphase auf den Markt kamen. In vielen Fällen wurden die
Produkte über die definierte Epoche hinaus aktiv vertrieben
und wurden meistens erst in der Folgeepoche oder später
vom Marketing zurückgezogen. Die einzelnen Produkte sind
in der Epoche, in der die Markteinführung erfolgte, so beschrieben,
dass sie den gesamten Lebenszyklus darstellen.
Das Storage Kompendium erhebt keinen Anspruch auf Vollständigkeit,
beschreibt aber die wichtigsten Produkte in der
jeweiligen Epoche.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Seite 13
Seite 19
1975 – 1993 die Epoche der fest eingebauten Platten
mit externen Kontrollein heiten
Seite 27
1994 – 1998 die Epoche der RAID-Systeme Seite 37
1999 – 2005 die Epoche der Multiplattform-Systeme
und des FibreChannel SAN/NAS
2006 – 2010 die Epoche der Server-basierenden
Speichersysteme und der Speichervirtualisierung
Seite 51
Seite 87

Preisentwicklung Magnetplattenspeicher
Die Schnelligkeit der technologischen Entwicklung bei
Magnetplattenspeichern von 1956 bis ins Jahr 2010 lässt
sich im besonderen Maße aus dem Preisverfall für ein
gespeichertes Megabyte ablesen. Der Verlauf war in etwa
folgendermaßen:
Jahr 1956 1964 1975 1987 1991
Euro/MB 12 000 8 000 70 12 9
Jahr 1997 2000 2006 2009
Euro/MB 1 0.25 0.015 0.0054 (FC-Disk)
0.0025 (SATA)
Rechnet man den verminderten Platz­ und Energiebedarf so­
wie den geringeren Wartungsaufwand pro Megabyte hinzu, so
ist der Trend bei der Kostenentwicklung eher noch günstiger.
Kapazitätsentwicklung Magnetplattenspeicher
Während der Preisverfall für das gespeicherte Megabyte
kontinuierlich anhielt, war in den letzten 10 Jahren ein überdimensional
hoher Preisverfall zu verzeichnen, der speziell
in den letzten Jahren eine Spanne von 40 bis 70 % pro Jahr
erreichte. Parallel dazu wurde die Aufzeichnungsdichte
durch technologische Innovationen in einem Maße gesteigert,
dass sie dem Preisverfall für das gespeicherte Megabyte
standhalten und Rechnung tragen konnte.
Die Steigerung der Aufzeichnungsdichte war in etwa folgendermaßen:
Jahr Produkt Aufzeichnungsdichte
(Millionen Bits/qcm)
1956 RAMAC 350 0.00031
1961 1311 0.008
1964 2311 0.017
1965 2314 0.034
1970 3330 0.12
1973 3340 0.26
1975 3350 0.48
1979 3370 1.2
1980 3375 1.51
1980 3380 1.9
1985 3380­E 2.99
1987 3380­K 5.47
1991 3390­3 13.95
1994 3390­9 41.6
1996 RAMAC 3 129.2
1999 ESS 427.5
2004 ESS 2.9 Milliarden Bits/qcm
2006 DS8000 5.8 Milliarden Bits/qcm
2009 DS8000­FC­Platten
DS8000­SATA­Platten
8.7 Milliarden Bits/qcm
19.3 Milliarden Bits/qcm
Im Jahr 2003, mit Verfügbarkeit der 146­GB­Laufwerke für
ESS, wurde die magische Grenze von 1 Milliarde Bits auf
dem Qua dratzentimeter überschritten. Mit der heutigen
Verfügbarkeit von 1 TB SATA­Laufwerken erreicht man eine
Aufzeichnungsdichte von über 19 Milliarden Bits/qcm.
Die großen Sprünge ergaben sich speziell in den letzten
10 Jahren (siehe auch Technologie­Anhang).
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
9

10
Produktübersicht der IBM Speichersysteme
Vorwort des Autors Kurt Gerecke ........................ Seite ......3
Vorwort der Co­Autors Klemens Poschke ............ Seite ......6
Speicherentwicklung, Gesamtüberblick .............. Seite ......8
Preis­ und Kapazitätsentwicklung
Plattenspeicher ..................................................... Seite ......9
Produktübersicht .................................................. Seite ....10
Die Anfangsepoche der elektromagnetischen
Speicherung ........................................................Seite ....13
726/727 Magnetbandsystem .............................. Seite ....14
RAMAC 305/350 Plattensystem .......................... Seite ....14
729 Magnetbandsystem ...................................... Seite ....16
1405 Platteneinheit/1414 Steuereinheit ................ Seite ....16
1301 Plattensystem .............................................. Seite ....16
7340 Hyper Tapes ................................................ Seite ....17
2321 Magnetstreifenspeicher............................... Seite ....17
Die Epoche der Wechselplatten und
die ‘Winchester’-Zeit...........................................Seite ....19
1311 Wechselplattensystem ................................ Seite ....20
1302 Plattensystem .............................................. Seite ....21
2401 Magnetbandsystem .................................... Seite ....21
2314 Wechselplattensystem ................................ Seite ....21
2305 Plattenspeicher ‘Zeus’ ................................. Seite ....21
3330 Wechselplattensystem/3830
Steuereinheit ......................................................... Seite ....22
3340 Wechselplattensystem
‘Winchester’­Platte ................................................ Seite ....23
3420 Magnetbandsystem .................................... Seite ....24
3410 Magnetbandsystem .................................... Seite ....24
3850 MSS­Massenspeicher ................................. Seite ....25
Die Epoche der fest eingebauten Platten
mit externen Kontrolleinheiten ..........................Seite ....27
3350 Festplattensystem ....................................... Seite ....28
3310 Magnetbandsystem .................................... Seite ....28
3370/3375 Plattensystem ..................................... Seite ....28
3380 Plattensystem/3880 Steuereinheit ............... Seite ....29
3430 Magnetbandsystem .................................... Seite ....30
3480 Magnetbandkassettensystem ..................... Seite ....30
3390 Plattensystem/3990 Steuereinheit ............... Seite ....31
9340/9345 Plattensystem ..................................... Seite ....32
3490 Magnetbandeinheit ..................................... Seite ....33
3495 Magnetbandarchiv ...................................... Seite ....34
3494 Magnetbandarchiv ...................................... Seite ....35
Die Epoche der RAID-Systeme .........................Seite ....37
RAID­Definitionen ................................................. Seite ....38
RAMAC 1/2/3 RAID­Plattensystem ....................... Seite ....39
RVA RAMAC Virtual Array .................................... Seite ....40
RSA RAMAC Scalable Array ................................ Seite ....40
7133 SSA­Plattensystem ...................................... Seite ....41
3590 Magstar­Magnetbandeinheit ....................... Seite ....42
3570 Magstar­MP­Magnetbandeinheit ................. Seite ....44
3494 B16, B18, B10, B20
Virtual Tape Server ............................................... Seite ....44
LTO Linear­Tape­Open­Bandeinheiten ................. Seite ....46
LTO Libraries ........................................................ Seite ....47
Die Epoche der Multiplattform-Systeme und
des FC SAN und NAS ........................................Seite ....51
SAN Storage Area Network .................................. Seite ....52
NAS Network Attached Storage ........................... Seite ....53
iSCSI ..................................................................... Seite ....54
ESS Enterprise Storage Server (Shark)
Plattensystem ....................................................... Seite ....54
7133 + 7140 Hammer Shark SSA
Plattenlösung für SAN .......................................... Seite ....56
MSS Modular Storage Server Plattensystem ....... Seite ....57
7135 RAIDiant­Array­Plattensystem ..................... Seite ....57
FAStT­Plattensysteme ........................................... Seite ....57
DS4000­Plattensysteme ....................................... Seite ....60
SVC SAN Volume Controller ................................. Seite ....63
LTO2/LTO3 Linear­Tape­Open­
Bandlaufwerke ...................................................... Seite ....63
LTO4 Linear­Tape­Open­Bandlaufwerke .............. Seite ....65
3592/TS1120 Bandlaufwerk (Jaguar) ................... Seite ....66
3584/TS3500 Bandarchiv ..................................... Seite ....69
3581 Band Autoloader ......................................... Seite ....71
3582 Bandarchiv .................................................. Seite ....71
3583 Bandarchiv .................................................. Seite ....71
TS3310 Bandarchiv .............................................. Seite ....71
TS3100 Band Autoloader ..................................... Seite ....72
TS3200 Bandarchiv .............................................. Seite ....72
TS7510 Tape­Virtualisierung für Open Systems .. Seite ....72
3995 Optisches Archivsystem ............................. Seite ....75
DR 450 Data Retention 450 Archivlösung ........... Seite ....76
DR 550 Data Retention 550 Archivlösung ........... Seite ....76
3996 Optisches Archivsystem ............................. Seite ....80
Nseries N3000/N5000/N6000/N7000 ................... Seite ....81
Nseries Funktionen ............................................... Seite ....84
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Die Epoche der Server-basierenden
Speichersysteme und der
Speichervirtualisierung ....................................Seite ....87
DS8000 und DS6000 Plattensysteme .................. Seite ....88
XIV Storage Systeme ............................................ Seite ....97
DS3000 Entry Plattensysteme .............................. Seite ..105
DS5000 Plattensysteme ....................................... Seite ..106
SVC San Volume Controller neue HW und SW .... Seite ..111
Backup­Konzepte ................................................. Seite ..117
TS7700 Tape Virtualisierung für z/OS .................. Seite ..120
TS7520 und TS7530 Tape –
Virtualisierung für Open Systems ......................... Seite ..128
Daten­De­Duplizierung ......................................... Seite ..132
IBM Daten­De­Duplizierung
mit ProtecTIER VTL und Hyperfactor ................... Seite ..134
TS1130 Bandlaufwerk der Enterprise Klasse ...... Seite ..137
TS3500 ALMS Library Virtualisierung .................. Seite ..140
TS3500 Hardware Erweiterungen 2007 – 2010 ... Seite ..142
TS3500 High Density (HD) Frames ...................... Seite ..142
iRMM Library Virtualisierung mit dem integrated
Enterprise Removable Media Manager ............... Seite ..144
TS3400 Mini­Library für TS1120 Laufwerke ......... Seite ..145
TS2900 Autoloader ............................................... Seite ..145
IBM Tape Library Überblick 2010 ........................ Seite ..146
GPFS/SOFS File Virtualisierung ............................ Seite ..147
SPSC Smart Private Storage Cloud ..................... Seite ..147
Tape Encryption mit TS1120/30 und LTO4 .......... Seite ..152
IIA IBM Information Archive ................................. Seite ..156
SAN und IP­Networking Update 2007 – 2010 ..... Seite ..158
Green IT................................................................ Seite ..161
Infini­Band ............................................................ Seite ..162
Neue Basis­Technologien .................................... Seite ..163
Der System-verwaltete Speicher
im Mainframe-Umfeld .........................................Seite ..166
Speicherhierarchie ............................................... Seite ..166
Entstehung ........................................................... Seite ..167
Funktionsweise ..................................................... Seite ..169
SMS für Tape ........................................................ Seite ..172
Komponenten und Funktionen ............................. Seite ..172
Zusammenfassung ............................................... Seite ..176
TSM – Tivoli Storage Manager ..........................Seite ..178
Wie alles begann ... 1983­1993 ........................... Seite ..178
ADSM V1.1 und V1.2 ........................................... Seite ..183
Internet Forum und Benutzergruppen ................. Seite ..187
ADSM Version 2.1 (1995) ..................................... Seite ..188
SAP R/3 Integration .............................................. Seite ..190
ADSM Version 3.1 (1997) ..................................... Seite ..191
Synergien IBM Speicherhardware und ADSM ..... Seite ..192
Tivoli ADSM/Tivoli Storage Manager ................... Seite ..195
TSM Version 3.7 und 4.2 ...................................... Seite ..196
TSM Version 5.X ................................................... Seite ..200
TSM für Data Retention (DR450/DR550) .............. Seite ..202
TSM – kleine Lösungen für den Einstieg ............. Seite ..204
TSM Version 6.1 (2009) ........................................ Seite ..204
Zusammenfassung und Schlusswort ................... Seite ..206
BRMS für System i .............................................Seite ..208
Überblick .............................................................. Seite ..208
Aktuelle Features .................................................. Seite ..208
Geschichte ........................................................... Seite ..215
Zusammenfassung und Ausblick ......................... Seite ..215
Technologie-Anhang ..........................................Seite ..217
Lochkarte und Lochstreifen ................................. Seite ..218
Trommelspeicher .................................................. Seite ..218
Magnetbandentwicklung ...................................... Seite ..219
Magnetplatte ........................................................ Seite ..220
Entwicklung des IBM Systems 305
und des ersten Plattenspeichers IBM 350 ........... Seite ..221
Funktionsweise IBM 350 und IBM 355 ................ Seite ..222
Disketten ............................................................... Seite ..225
Festplattenentwicklung ......................................... Seite ..226
Festplatten für PC’s .............................................. Seite ..229
Induktive Aufzeichnung ........................................ Seite ..230
Magneto Resistive Aufzeichnung (MR) ................ Seite ..230
PRML Encoding ................................................... Seite ..232
GMR Effekt – Giant Magneto­Resistance ............ Seite ..232
Micro­Drives ......................................................... Seite ..233
AFC Aufzeichnung ............................................... Seite ..234
Perpendicular Recording ..................................... Seite ..236
HAMR – Heat Assisted Magnetic Recording ....... Seite ..236
IBM Museum ........................................................ Seite ..238
Magnetplatten Exponatensammlung ................... Seite ..240
IBM Magnetplattenprofile ..................................... Seite ..246
Interview mit den RAMAC 350/355 Experten ...... Seite ..270
Optische Speichertechnologien ........................... Seite ..274
Flashspeicher ....................................................... Seite ..280
RAM – Random Access Memory ......................... Seite ..284
PCM – Phase Change Memory ............................ Seite ..285
Millipede­Nanotechnologie .................................. Seite ..287
Racetrack Memories ............................................ Seite ..290
Nanotechnologien ................................................ Seite ..293
Sponsorenseiten ................................................Seite ..299
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 11

12
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1952 bis 1961
Die Anfangsepoche der elektromagnetischen Speicherung
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
13

14
1952 bis 1961
Die Anfangsepoche der elektromagnetischen Speicherung
Aufnahme des ersten Prototypen des Magnetbandsystems IBM 726 im Jahr
1951 mit zwei Bandlaufwerken pro Einheit
Zum ersten Mal in der Speichergeschichte wurden externe
Speicher mit magnetischer Aufzeichnung von IBM 1952
angeboten: die IBM Magnetbandeinheit IBM 726 mit einer
Speicherkapazität von 1,4 MB auf einem 12­Zoll­Rollenband
(Durchmesser der Bandspule) mit 720 Metern Länge. Die
Einheit hatte zwei integrierte Bandlaufwerke. Dies erwies
sich allerdings als äußerst unpraktisch, weil keines der beiden
Laufwerke im Fehlerfall oder bei Wartungsarbeiten weiterhin
zur Verfügung stand. Bereits ein Jahr später, 1953, folgte
die IBM 727 mit einem Laufwerk pro Einheit, die auf einem
standardisierten Rollenband von ca. 740 Metern Bandlänge
eine Kapazität von 4 MB bot. Bis 1956 war ein Teil der Steuerung
in der damaligen Rechnereinheit IBM 701 untergebracht.
Erste dedizierte Bandsteuereinheiten gab es dann ab 1956.
IBM Magnetbandeinheit Modell 726, Markteinführung 1952
1956 kam das System IBM RAMAC 305 auf den Markt.
Dieses System hatte erstmals eine Plattenspeichereinheit
Type IBM 350. Das IBM 305 System wurde unter dem eingetragenen
Warenzeichen ‘RAMAC’ angekündigt (Random
Access Method of Accounting and Control). Der Rechner
des Gesamtsystems steuerte sowohl das Positionieren des
Schreib­/Lesekopfes auf die gewünschte Plattenoberfläche
und Plattenspur als auch das Übertragen der Daten in beide
Richtungen (Schreiben und Lesen).
Die Aufzeichnungsdichte der RAMAC 350 Platte lag bei 100
Bits pro Inch (40 Bits pro cm) und der Plattenstapel rotierte
mit 1.200 Umdrehungen in der Minute (1200 RPM). Die durchschnittliche
Suchzeit lag bei 600 ms. Der Plattenstapel bestand
aus 51 Platten mit einem Durchmesser von 24 Zoll und bot
eine maximale Kapazität von 5 MB (5 Millionen Characters).
In Betrieb kann die RAMAC 350 im IBM Museum in Sindelfingen
besichtigt werden.
Medium-Rollenband für IBM 726 IBM 350 RAMAC Platte, 51 Platten im Stapel mit 24 Zoll Durchmesser.
1956: Modell mit 5 MB (5 Millionen ‘Characters’), 1958: Modell mit 10 MB
(10 Millionen ‘Characters’), Zurückziehung vom Vertrieb im Jahr 1960
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

IBM RAMAC 350-Plattenstapel
Damals gab es noch keine Zugriffskämme, sondern nur einen
Zugriffsarm, der in die Zwischenräume des Plattenstapels
mit einer Seilzugmechanik hineingesteuert wurde. Die exakte
Positionierung erfolgte mit Zahnstange und Klinke und wurde
per Pressluft elektronisch gesteuert. Die Köpfe schwebten
über der Platte in einem Abstand von 800 Micro­Inches. 1958
wurde mit der Ankündigung des Modells 2 die Möglichkeit
geschaffen, die doppelte Kapazität abzubilden (10 MB). Bei
diesem Modell wurden zwei Zugriffsstationen eingesetzt, sodass
eine Station schreiben oder lesen und die zweite gleichzeitig
suchen konnte, um für die Verarbeitung des nächsten
Satzes die Positionierung des Schreib­/Lesekopfes vorzubereiten.
IBM RAMAC 350 Platte mit zwei Zugriffsstationen IBM RAMAC 350 Einheit
Verkaufstechnisch wurde bereits damals mit der RAMAC
derselbe Marketing­Ansatz gewählt, den man auch heute
noch, nur in anderen Größenordnungen, vorfindet. Wie macht
man dem Käufer und Benutzer klar, was 5 MB sind? 5 MB
lagen damals über jeder normalen Vorstellungskraft. Deshalb
wurden in den meisten Spezifikationsunterlagen 5 MB so definiert,
dass das 60.000 – 80.000 Lochkarten entspreche,
oder 2.000 Feet Bandlänge (die Bänder gab es ja bereits
4 Jahre früher) oder 940 Seiten mit bedrucktem Papier.
Neben dem RAMAC­Plattenstapel und der dazugehörigen
Zugriffsstation enthielt die Einheit 350 eine elektronische
und pneumatische Kontrolle für die Zugriffsstation und einen
Luftkompressor. Die Schmierung der Plattenlager wurde durch
eine Öl­Dunst­Schmierung durchgeführt.
Die Einheit 350 hatte eine Länge von 152,4 cm (60 Inches),
eine Höhe von 172,72 cm (68 Inches) und eine Tiefe von
73,66 cm (29 Inches) und wog etwa eine Tonne.
Das Gesamtsystem, bestehend aus Rechner, Platteneinheit,
Kartenleser, Kartenstanzer, Drucker und Konsoleneinheit,
kostete 185.000 Dollar und wurde auch unter Leasing zu
einer monatlichen Rate von 3.200 Dollar angeboten. In dem
Zeitraum von 1956 bis 1960 wurden weltweit 1.500 Systeme
installiert. 1960 erfolgte dann die Zurückziehung aller Modelle
vom Vertrieb und 1961 die Einstellung der Produktion.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
15

16
1952 bis 1961
Die Anfangsepoche der elektromagnetischen Speicherung
Erstauslieferung IBM RAMAC 305 in Brasilien 1956
1957 wurde der ‘Data Synchronizer’ am IBM System 709
eingeführt, der Vorläufer der heutigen Übertragungskanäle.
1959 führte IBM ein neues Programmpaket, das Eingabe­/
Ausgabesteuerungssystem IOCS für Magnetbänder und
Magnetplatten (Input/Output Control System) ein. Es handelte
sich um Makroinstruktionen zum Erstellen, Wiederauffinden
und Verarbeiten von Dateien sowie zur Fehlerkorrektur.
Außerdem steuerte IOCS die Datenblockbildung und die Entblockung.
IOCS blieb für spätere Systeme von maßgeblicher
Bedeutung.
1958 verwendete IBM erstmals mit den Systemen IBM 7070
und 7090 die Technik der automatischen Programmunterbrechung
(Program Interrupt). Der Prozessor verzweigte bei
bestimmten, von Eingabe­/Ausgabeeinheiten angezeigten
Bedingungen automatisch zu Routinen, die den ‘Interrupt’
behandelten.
1958 wurde die Bandeinheit IBM 729 als Nachfolger des
Vorgängers IBM 727 auf den Markt gebracht. Die IBM
729­Bandfamilie bot neben höheren Datenraten und höherer
Speicherdichte die erste Schreibkontrolle. Mit der Einführung
der IBM 729 wurde beim Schreiben auf Magnetband automatisch
geprüft, ob die eben geschriebene Information gültig
war. Dazu wurde Stelle für Stelle in ein Prüfregister eingelesen
und geprüft.
Im Oktober 1960 wurde der Plattenspeicher IBM 1405 ange­
kündigt, der an den Systemen IBM 1401, 1410 und 1460 (nicht
an System 7000) betrieben wurde. Dieser Plattenspeicher
vervierfachte die Kapazität eines Plattenstapels im Vergleich
zur RAMAC von 1956. Sowohl die Anzahl der Spuren pro
‘Inch’ als auch die Anzahl der Bits in einer Spur wurden verdoppelt,
sodass eine vierfache Kapazität des Plattenstapels
erreicht wurde. Die Plattenstapel waren in zwei Ausführungen
verfügbar, in einer Einheit mit 25 Platten im Stapel und einer
mit 50 Platten. Die kleinere Einheit hatte eine Kapazität von
10 MB und die größere von 20 MB. Die Aufzeichnungsdichte
betrug 220 Bits pro Inch, was 40 Spuren pro Inch entspricht.
Die Schwebehöhe zwischen Kopf und Platte betrug 650 Micro­
Inches und die Platten drehten sich mit 1.800 Umdrehungen
pro Minute. Die Datenrate lag bei 17,5 Kilobytes pro Sekunde.
Der IBM 1405 Plattenspeicher kam vor allem beim IBM
1401­Rechner zum Einsatz.
Ein Jahr später, im Juni 1961, wurde die IBM 1301 Platten-
einheit angekündigt. Sie wurde ein Jahr später, im 3. Quartal
1962, an Kunden ausgeliefert. Die Entwicklung dieser Platteneinheit
trug in größtem Maße zur Weiterentwicklung zukünftiger
Plattensysteme bei und ist als Meilenstein in der gesamten
Plattengeschichte zu betrachten. Das Platten system 1301 war
der Wegbereiter zukünftiger zur Anwendung kommender
Technologien in zwei Bereichen: die ‘Air Bearing Slider’­
Technologie und separate Schreib-/Leseköpfe für jede
Plattenoberfläche mit der Möglichkeit, alle auf einen Datenzylinder
physisch eingestellten Köpfe elektronisch für die
zutreffende Plattenoberfläche zu selektieren und nacheinan­
IBM 1405 Plattenspeicher, Ankündigung am 10. Oktober 1960,
Zurückziehung 30. Juni 1970
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

IBM 1301 Plattenspeichereinheit, Ankündigung im Juni 1961, Zurückziehung
aller Modelle im Oktober 1970
der zu bearbeiten. Damit war der Grundstein des Zylinder­
prinzips bei Plattenspeichern gelegt und der ‘Plattenzylinder’
geboren!
Neben höherer Kapazität und Leistung bot die Maschine eine
wesentlich flexiblere und höhere Übertragungsbandbreite
durch das Prinzip, pro Plattenoberfläche einen Schreib­/Lesekopf
zur Verfügung zu haben, und war auf die neue IBM 7000
Serie von Rechnern abgestimmt (7070, 7094, 7080 und 7090).
Die Kapazitätssteigerung zur ersten RAMAC lag bei Faktor 13.
Die Platten rotierten mit 1.800 Umdrehungen in der Minute.
Durch die Verkleinerung des Flugabstandes zwischen Kopf
und Platte auf 250 Micro­Inches konnten 50 Spuren pro Inch
und bis zu 520 Bits pro Inch aufgezeichnet werden. Das
Modell 1 der IBM 1301 hatte ein Plattenmodul mit einer Kapazität
von 28 MB, das Modell 2 arbeitete mit zwei Modulen und
einer Kapazität von 56 MB. Angeschlossen an die IBM 7631
Steuereinheit konnten bis zu 10 Module (oder bis zu fünf 1301
Einheiten) zum Einsatz kommen, sie boten für die 7000­Serie
eine maximale Kapazität von bis zu 280 MB. Interessant waren
auch die damaligen Preise: Das Modell 1 konnte monatlich
für 2.100 Dollar geleast werden oder für eine Summe von
115.500 Dollar gekauft werden. Das Modell 2 mit zwei
Modulen lag bei 3.500 Dollar monatliche Leasingrate und
einem Kaufpreis von 185.500 Dollar.
IBM 7340 Hyper Tape Drives in der Bildmitte, links die IBM 7640 Kontrolleinheit,
rechts die IBM 729 Bandeinheiten
Die Hyper Tape Drives IBM 7340 reflektierten die neuste
Bandtechnologie, als sie 1961 auf dem Markt eingeführt
wurden. Zusammen mit der Kontrolleinheit IBM 7640 bedienten
sie die IBM Rechner 7074, 7080 und 7090. Die Hyper Tapes
erzielten wesentlich schnellere Lese­ und Schreib­Geschwindigkeiten
im Vergleich zu den bisherigen Bandeinheiten.
Angeschlossen am IBM 7090 Rechner lieferten sie die doppelten
Übertragungsraten im Vergleich zum IBM 729 Bandsystem,
der Weiterentwicklung der IBM 727.
Am 7. April 1964 wurde mit dem System/360 der Magnet-
streifenspeicher IBM 2321 angekündigt. Mit seiner Gesamtspeicherkapazität
von 400 MB auf 1.000 mit magnetisierbarer
Oberfläche versehenen Plastikstreifen galt er zu dieser Zeit
als Massenspeicher. Jeder Streifen enthielt 100 Datenspuren,
hatte eine Kapazität von 0,2 MB und wurde in sogenannten
‘IBM 2321 Data Cell Drives’ aufbewahrt. 200 solcher Streifen
konnten in einer Datenzelle untergebracht werden. Die sich
auf einem drehbaren Karussell befindlichen Datenzellen
wurden durch Rotation so positioniert, dass der gesuchte
Speicherstreifen durch einen Greifer erfasst und um die
Schreib­/Lesetrommel geführt werden konnte. Damit konnte
die adressierte Datenspur gelesen oder beschrieben werden.
Die aufwendige Konstruktion und der damit verbundene hohe
Wartungsaufwand standen einer weiten Verbreitung entgegen.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
17

18
1952 bis 1961
Die Anfangsepoche der elektromagnetischen Speicherung
Prinzip und Arbeitsweise des IBM 2321 Magnetstreifenspeichers
IBM 2321, Gesamtkapazität von 400 MB, Ausbaustufen von 40 bzw. 80 MB,
Zugriffszeiten von 95 bis 600 ms
Kommentar zur Anfangsepoche
der elektromagnetischen Speicherung
Neben der Erfindung der ersten externen Speichereinheiten
mit dem Rollenband IBM 726 und der Platteneinheit IBM
RAMAC 350 war der Topmeilenstein die Einführung der Platteneinheit
IBM 1301.
Die IBM 1301 war das erste Plattensystem, das mit ‘Air Bearing
Slidern’ arbeitete und für den Zugriff einen Zugriffskamm
verwendete, der jede Plattenoberfläche im Plattenstapel mit
dedizierten Schreib­/Leseköpfen ansteuerte. Mit der IBM 1301
wurde die Zylinderarchitektur im Plattenstapel eingeführt, die
bis heute ihren Stellenwert behalten hat.
Bemerkenswert ist auch die Tatsache, dass bereits damals
nach Möglichkeiten gesucht wurde, kleine Files, die nicht so
häufig gebraucht wurden, auf einem billigeren Massenspeicher
abzulegen. Für diesen Zweck wurde der Magnetstreifenspeicher
IBM 2321 eingeführt.
Geprägt wurde die Epoche auch dadurch, dass bei neuen
Systemankündigungen immer die dazugehörigen neuen Platteneinheiten,
die dem neuen System leistungsmäßig angepasst
waren, Teil der Systemankündigung waren.
Die Anfangsepoche legte viele Grundlagen für die Folgeepochen.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1962 bis 1974
Die Epoche der Wechselplatten und die ‘Winchester’-Zeit
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
19

20
1962 bis 1974
Die Epoche der Wechselplatten und die ‘Winchester’-Zeit
IBM 1311: Ankündigung am 11. Oktober 1962, Zurückziehung aller Modelle 1971
Die zwischen 1962 und 1964 eingeführten Magnetplatten-
speicher IBM 1311, IBM 2311 und IBM 2314 zum Anschluss
an die 360er­Systeme arbeiteten mit auswechselbaren
Magnetplattenstapeln. Die neue Plattensteuereinheit IBM
2841 war erstmals Mikroprogramm-gesteuert. Dies war
erforder lich, weil mehrere Speichertypen gesteuert werden
mussten, einschließlich des neu verwendeten CKD­Formats.
IBM entwickelte das Aufzeichnungsformat CKD (Count,
Key, Data, frei übersetzt: Sektorkennzeichnung, Schlüssel,
Daten), das als optimierte Version ECKD über das Jahr 2000
hinaus gültig blieb und bis heute im Mainframe(z/OS)­Umfeld
eingesetzt wird. Das ‘E’ steht für ‘Extended’, also zu deutsch
‘erweitert’. Wie ein Zugriff auf Daten nach dem CKD­Verfahren
abläuft, ist mit dem Produkt der IBM 3330 beschrieben.
Das IBM 1302 Festplattensystem wurde am 23. September 1963 angekündigt
und am 9. Februar 1965 wieder vom Vertrieb zurückgezogen
Das erste Modell des Magnetplattenspeichers IBM 1311 mit
Wechselplatten wurde im Oktober 1962 mit dem System
IBM 1440 angekündigt. Der Wechselplattenstapel war aus
sechs 14­Zoll­Platten aufgebaut, wog 10 Pfund und bildete
eine Speicherkapazität von 2 MB ab. Im Vergleich zur IBM
1301 verdoppelte sich die lineare Speicherdichte auf 1.025
Bits pro Inch. Dies wurde dadurch erreicht, dass der Abstand
zwischen den Köpfen zu den Plattenoberflächen im Vergleich
zur IBM 1301 um Faktor 2 auf 125 Micro­Inches reduziert
wurde. Die Platten drehten mit 1.500 RPMs und boten eine
durchschnittliche Zugriffszeit von 150 ms.
IBM 2401 Magnetbandeinheit
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1963 wurde noch ein Nachfolger der IBM 1301 mit fest ein­
gebauten Platten angekündigt. Die IBM 1302 sah optisch
genauso aus wie die IBM 1301, bot aber auf der Platten ober­
fläche 500 Datenspuren (1301 hatte 250 Spuren pro Plattenoberfläche).
Wie bei der 1301 wurden 20 Platten im Stapel
verwendet und die Kapazität von 28 MB auf 58,5 MB gesteigert.
Damit bot das Modell 1 der 1302 eine Kapazität von
117 MB und das Modell 2 von 234 MB. Die Datentransferrate
wurde von 90 KB/s auf 180 KB/s gesteigert.
1964 kam speziell für die Rechnerfamilie System/360 das
neue Magnetbandsystem IBM 2401 auf den Markt, das mit
9 Spuren gleichzeitig auf dem Rollenband aufzeichnen konnte
und eine wesentlich höhere Zuverlässigkeit im Vergleich zu
den Vorgängern IBM 726, 727 und 729 bot. Dies wurde durch
die Einführung eines sogenannten CRC (Cyclic Redundancy
Check) erreicht, das die erste automatische Fehlerkorrektur
ermöglichte (Automatic Error Capture & Correction) und Basis
für die späteren ECCs (Error Correction Codes) bei Bandsystemen
lieferte.
Im April 1965 – ein Jahr nach der Ankündigung des Prozes­
sors System/360 – wurde das Plattensystem IBM 2314 als
‘IBM Direct Access Storage Facility’ angekündigt. Dies war
das erste Plattensystem, bei dem Controller und der Strang
mit Plattenstapeln in einer Konfiguration bestellt und aufgebaut
werden konnten. Mit der 2314 wurde ein neuer Plattenstapel
mit der doppelten Anzahl an Plattenoberflächen eingeführt,
der eine Speicherkapazität von 29,2 MB abbildete.
Das Gesamtsystem bot eine maximale Kapazität von 233,4
MB. Im Vergleich zur 1311 war die 2314 um den Faktor 4
billiger, was das gespeicherte MB betraf. Die Datenrate lag bei
310 KB pro Sekunde. Im Januar 1969 kamen zwei neue Versionen
der 2314 auf den Markt, die Modelle A1 und A2, die
IBM 2314 Produktionslinie in Mainz 1969
IBM 2305 Fixed Head Storage, bekannt als ‘Zeus-Speicher’, Markteinführung
1971, Zurückziehung vom Vertrieb im Januar 1980
eine um 20 % schnellere Zugriffszeit boten, die im Bereich
von 60 bis 75 ms lag. Die Kapazität blieb dieselbe. Im
Dezember 1970 wurde die Plattenfamilie 2314 noch durch
ein Modell B1 ergänzt, das 50 % höhere Kapazität anbot.
Im Januar 1970 wurde das Plattensystem ‘IBM 2305 Fixed
Head Storage’ angekündigt, das unter dem Entwicklungsnamen
‘Zeus’ entwickelt wurde und als IBM Zeus bekannter
wurde als unter dem offiziellen Typennamen. 1971 erfolgten
die ersten Auslieferungen. Die IBM 2305 war für große Datenbankanwendungen
und für das Batch Processing bestens
geeignet und wurde bei großen System/360 Rechnern der
Modelle 85 und 195 und später dann bei den System/370
Modellen 155 und 165 für diese Applikationsformen eingesetzt.
Mit zwar kleinen Speicherkapazitäten von 5,4 MB und
10,8 MB, jedoch mit einer durchschnittlichen Zugriffszeit von
2,5 ms bzw. 5 ms war das System das schnellste seiner
Zeit. Die Datenrate lag bei 3 MB/s und damit 10­fach höher
als bisherige Plattensysteme.
IBM 2314 Plattensystemfamilie, Ankündigung Modell 1 am 22. April 1965, Modelle A1 und A2 am 10. Januar
1969, Modell B1 am 14. Dezember 1970, Zurückziehung vom Vertrieb im Jahr 1978
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
21

22
1962 bis 1974
Die Epoche der Wechselplatten und die ‘Winchester’-Zeit
1970 bis 1972: Der virtuelle Speicher, der auf Magnetplatten
abgebildet wurde, schaffte eine neue Qualität in der Beziehung
zwischen Prozessoren und Magnetplattenspeichern.
Online­Anwendungen gewannen rasch an Bedeutung. Wie
die neuen Prozessoren IBM/370 trugen Subsysteme aus
den Steuereinheiten IBM 3830 und Magnetplatteneinheiten
IBM 3330 den steigenden Leistungs­ und Zuverlässigkeitsanforderungen
Rechnung. Neue Blockmultiplexkanäle sorgten
für wesentlich höhere Datenübertragungsraten und trugen zu
einer wesentlich höheren Gesamtleistung bei. Dazu einige
Einzelheiten:
Die Plattensteuereinheit IBM 3830 war Mikroprogramm­gesteuert,
jedoch erstmals mit einem ladbaren Mikroprogrammspeicher,
der über eine Diskette geladen wurde. Mit dem
Mikroprogramm war es möglich, mehr Funktionen als in den
Vorgängermodellen zu realisieren. Dazu zählten das Erkennen
und Beseitigen von Bitfehlern, gegebenenfalls mehrfaches
Wiederholen von Kanalbefehlen vor Übergabe einer Fehlerbehandlung
an den Rechner und das Sammeln von Informationen
über aufgetretene Fehler für das Systemprotokoll
(LogRec). Diese Aufzeichnungen lieferten den Bedienern
Informationen über den technischen Zustand von Datenträgern
und boten dem technischen Außendienst Hinweise für
vorbeugende Wartung.
Bei der Empfindlichkeit magnetischer Aufzeichnung gegen
elektrische und mechanische Störungen musste man von
Anfang an mit Bitfehlern rechnen. Über Zusatzbits zur Paritätsprüfung
entwickelte IBM immer ausgefeiltere Methoden, um
Redundanzbits zu generieren, die den gespeicherten Daten
angehängt wurden. Bei den Aufzeichnungsformaten CKD
und ECKD findet diese ‘Redundanz’­Aufzeichnung in den
Zwischenräumen (Gaps) zwischen den Datensätzen statt.
Mit ihrer Hilfe ließen sich durch entsprechende Programme
in Rechnern und Steuereinheiten die meisten Bitfehler beim
Übertragen ohne nennenswerte Zeitverzögerung korrigieren
und durch technische Einflüsse verfälschte Daten praktisch
ausschließen. Die Verfahren setzten für jede Datei die Definition
sogenannter ‘physischer Sätze’, einer einheitlichen Länge
in Bytes, voraus. Solche Sätze wurden als Blöcke bezeichnet.
Bei Eingabe­/Ausgabe­Operationen wurden immer komplette
Blöcke übertragen und geprüft. Meistens war es zweckmäßig,
in einem Block mehrere ‘logische Sätze’ zusammenzufassen.
Sie bestanden aus einem Ordnungsbegriff, dem in ‘Feldern’,
die nach Lage und Länge definiert waren, die zugehörigen
Angaben und Informationen folgten. Bei administrativen
Anwendungen wären z. B. Artikel­, Kunden­ oder Personalnummern
die Ordnungsbegriffe. In den Feldern standen dann
alphabetische und numerische Informationen. Die Anzahl der
logischen Sätze im physischen Satz bezeichnete man als
Blockungsfaktor.
IBM 3330, Kapazität 800 MB, 2-8 Laufwerke, Zugriffszeit 30 ms, Datenrate 806 KB/s, Ankündigung Modell 1 am 30. Juni 1970,
Modell 2 am 4. Oktober 1972, Modell 11 am 17. Juli 1973, Zurückziehung vom Vertrieb am 20. Dezember 1983
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Nach bisherigen hydraulischen Zugriffsmechanismen
benutzten die Magnetplatteneinheiten IBM 3330 erstmals für
das ‘Suchen’, die horizontale Einstellung des Zugriffskammes
mit den Schreib­/Leseköpfen, einen Linearmotor.
Wie bei Lautsprechern wirkt ein durch variablen Stromfluss
in einer Spule erzeugtes Magnetfeld dem statischen Feld
eines Permanentmagneten entgegen. Deshalb die englische
Bezeich nung ‘Voice Coil Motor’ (Lautsprecherspulenmotor).
Die Lage der Schreib­/Leseköpfe zu bestimmten Zeitpunkten
ergab sich aus der Stärke des von der Spule
erzeugten Magnetfelds. Diese Technik setzte voraus, dass
jeweils eine Oberfläche eines Plattenstapels mit vom Benutzer
unveränderbaren Servo spuren versehen war. Der darüber
angeordnete (Nur­)Lesekopf versorgte die elektronische Steu­
erung mit den für gezieltes Positionieren im Rahmen eines
Regelungskreislaufs notwen digen Informationen. Diese
Technik reduzierte damals die durchschnittliche Dauer einer
Suchoperation auf Anhieb um die Hälfte: statt 60 dann nur
noch 30 ms.
Für einen verbesserten Ablauf des direkten Zugriffs auf Daten
war Folgendes von Bedeutung: Die Steuereinheit IBM 3830
konnte mithilfe entsprechender Informationen von der Servoplatte
als erste die Dreh­ oder Winkelposition der an sie
angeschlossenen Magnetplatteneinheiten erkennen (RPS –
Rotational Position Sensing). Mit dem Plattensystem IBM
3830/3330 lief ein Routinezugriff wie folgt ab: Nach Angaben
aus den Datenträgerinhaltsverzeichnissen, den sogenannten
VTOCs (Volume Table Of Contents), und den Indizes zu den
Dateien generierte der Rechner mithilfe der Programme der
Zugriffsmethodensteuerung einen Kanalbefehl. Dieser enthielt
die Plattenadresse, von der zu lesen oder auf die zu schreiben
war, nach Einheit, Zylinder, Spur und Sektor. Die konzentrischen
Spuren auf den Plattenoberflächen waren in Sektoren
eingeteilt. Als Zylinder bezeichnete man die Summe
der übereinanderliegenden Spuren auf einem Plattenstapel,
von denen bei einer gegebenen horizontalen Einstellung
eines Zugriffskammes mit ebenfalls übereinander angeordneten
Schreib­/Leseköpfen gelesen oder auf die geschrieben
werden konnte. Die Steuereinheit wandelte den Kanalbefehl
in spezifische Befehle für die Einheiten um. Den
Suchbefehl zum Einstellen des Zugriffskammes auf den korrekten
Zylinder führten die Einheiten selbstständig aus und
meldeten der Steuereinheit den Abschluss der Suchoperation.
Dann aktivierte die Steuereinheit den richtigen Schreib­/
Lesekopf, analysierte seine Position bezogen auf die Sektoren
und begann mit dem Übertragen der Daten über den
IBM 3340, Maximalkapazität bis 4.800 MB, Winchester-Wechselplatten
Modell 35: 35 MB, Modell 70: 70 MB, bis zu 64 Laufwerke (Modelle 158, 168),
Datenrate 885 KB/Sekunde, Zugriffszeit 25 ms
Kanal des Rechners, sobald der Anfang des im Kanalbefehl
vorgegebenen Sektors erreicht war. Der Kanal war nur während
der Datenübertragung belegt. Mehrere Platteneinheiten
konnten Suchbefehle überlappt ausführen. Auch die Umdrehungswartezeit
(damals bei ca. 17 bis 20 ms) belastete den
Kanal nicht. Diese Methode erlaubte höhere systemeffektive
Daten raten des Magnetplattensystems, die bei günstigen
Konfigurations­ und Anwendungsprofilen nicht sehr weit
unter der Übertragungsleistung der Einheiten lag.
1973: Das an mittlere Rechnersysteme IBM/370, Modelle 115,
125 und 135, direkt anschließbare neue Magnetplattensystem
IBM 3340 benutzte als auswechselbaren Datenträger das
Datenmodul IBM 3348. Die auswechselbaren Datenmodule
3348 boten 35 oder 70 MB Kapazität. Ein Modul enthielt in
einem geschlossenen, staubgeschützten Gehäuse den Plattenstapel
und einen horizontal beweglichen Zugriffskamm mit
zwei Schreib­/Leseköpfen je Datenoberfläche. Das Modul war
auf die Welle des Antriebsmotors im Laufwerk aufgesetzt.
Nach dem automatischen Öffnen einer seitlichen Jalousie
verbanden elektrische Steckverbindungen den Zugriffskamm
mit dem Laufwerk und eine mechanische Verbindung den
Zugriffskamm mit dem Linearmotor. Der Grund für diese Konstruktion:
Wenn auswechselbare Plattenstapel als Datenträger
dienten, bedeu tete das insbesondere für Zugriffskämme
extreme Ansprüche an die Fertigungstoleranzen, weil jeder
Stapel zu jedem beliebigen Laufwerk passen musste und
schon minimale horizontale Abweichungen der Köpfe über
den Spuren zu Lesefehlern führte. Dieser Umstand setzte der
horizontalen Spurdichte Grenzen und minderte die Sicherheit
und Zuverlässigkeit der Systeme. Maximal vier Module mit
einer maximalen Kapazität von 280 MB konnten über einen
Direkt anschluss am IBM/370 Rechner betrieben werden.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
23

24
1962 bis 1974
Die Epoche der Wechselplatten und die ‘Winchester’-Zeit
Aufbau IBM 3340 Winchester-Wechselplattenstapel
Die IBM 3340 mit den Modellen A2, B1, B2 und C2 wurden
am 13. März 1973 angekündigt. Die Modelle B1 und C2
wurden am 20. Dezember 1983 und die Modelle A2 und B2
am 1. Mai 1984 vom Vertrieb zurückgezogen.
Die Tatsache, dass beim Datenmodul der Magnetplattenspeicher
IBM 3340 immer der gleiche Zugriffskamm schrieb
und las, ermöglichte höhere Spurdichten bei gleichzeitig gesteigerter
Zuverlässigkeit. Die Konstruktion insgesamt führte
zu kürzeren Suchzeiten und etwas höherer Übertragungsleistung
gegenüber der IBM 3330.
Mit den neuen Magnetbandeinheiten IBM 3420, Modelle 3,
5 und 7, die in 9­Spur­Technik mit einer Aufzeichnungsdichte
von 1.600 Bytes pro Zoll arbeiteten, konnte eine Datenrate –
je nach Modell – von 120, 200 und 320 Kilobytes pro Sekunde
erzielt werden. Diese Modelle wurden 1970 eingeführt.
Die neuen Magnetbandeinheiten IBM 3420, Modelle 4, 6
und 8, die 1973 auf dem Markt eingeführt wurden, steigerten
mit dem Verfahren der ‘gruppencodierten Aufzeichnung’
(Group Coded Recording) die Aufzeichnungsdichte von
1.600 auf 6.250 Bytes per Zoll und die maximale Übertragungsrate
wurde – je nach Modell – auf 470, 780 und 1.250
Kilobytes pro Sekunde gesteigert. Gleichzeitig erhöhte sich
die Zuverlässigkeit um den Faktor 7 (im Vergleich zu den
Modellen 3, 5, und 7).
Um die Bedienung zu erleichtern, kündigte IBM 1971 parallel
zum 3420 Magnetbandsystem das IBM 3410 Magnetband-
system an, das von der Bauhöhe her Pultform hatte und
erstmals erlaubte, die Rollenbänder horizontal von oben einzulegen.
Die Kapazitäten und die Technologie waren mit der
3420 vergleichbar, allerdings war die Schreib­/Lesegeschwindigkeit
wesentlich niedriger. Die 3410 wurde deshalb – neben
dem 3420 Magnetbandhochleistungssystem – als kostengünstige
Alternative für Benutzer der IBM System/370 und
IBM System/360 angeboten.
1974: Im Zuge des verstärkten Übergangs der mit dem System/370
begonnenen Direktverarbeitung mit preisgünstigen
Terminals zur Programmentwicklung und Problemlösung
(VM/370, APL) wuchs die Zahl der Dateien bei Benutzern
großer Systeme dramatisch. Anders als bei den mit wenigen
großen Dateien und ausgefeilten Sicherungsverfahren arbeitenden
Datenbankanwendungen (IMS, CICS) wurde es
immer schwieriger, speziell die vielen kleinen, unregelmäßig
IBM 3420 Magnetbandeinheit, 1970 Modelle 3, 5 und 7, 1973 Modelle 4, 6 und 8 IBM 3410 Magnetbandsystem mit horizontaler Bandeinlegemöglichkeit
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

enutzten Bestände unter manueller Verwaltung zuverlässig
zu sichern und zu archivieren. Um diese Aufgabe zu lösen
und um kostengünstigeres Speichern von Daten unter Systemkontrolle
zu ermöglichen, führte IBM neue Hardware und
Software ein.
Der Massenspeicher MSS (Mass Storage System) IBM
3850 bildete auf zwei speziellen zylinderförmigen
Magnetband patronen den Inhalt eines Datenträgers des
Magnetplattenspeichers IBM 3330 ab. Man kann ihn als
ersten virtuellen ‘Plattenspeicher’ bezeichnen, der gleichzeitig
ein automa tisches Bandarchiv darstellte. Alle aktiven
Patronen lagerten in einem Schrank mit einander gegenüberliegenden
Regalen in wabenförmigen Zellen. Bei Anforderung
durch die Programme bewegte eine sinnreiche Konstruktion
einen sogenannten Picker automatisch zur richtigen
Patrone. Der Picker hielt den Datenträger im Gegensatz zu
späteren mechanischen Greifern elektromagnetisch fest und
brachte ihn zu einer Schreib­/Lesestation, von der die
gewünschten Daten zum Verarbeiten auf bestimmte
Magnetplattenlaufwerke (Staging Devices) übertragen wurden
oder umgekehrt. Nach Ablauf der Operation brachte
die gleiche Vorrichtung die Patronen an ihren Lagerort
zurück. Der Bediener war nur noch mit den Patronen befasst,
die der Massenspeicher nach Programmvorgaben über
entsprechende Stationen aussteuerte oder die er von außen
anforderte. Der Massenspeicher konnte bis zu 236 GB im
Zugriff der Prozessoren halten. Die technische Entwicklung
der Magnetspeicher – Platte, Band – ließ keinen sinnvollen
Nachfolger zu, während die zugehörige Software bis heute,
im Jahr 2006, hochaktuell blieb.
IBM Mass Storage System 3850 mit ‘Honeycomb Racks’ 1974
IBM MSS 3850 im Rechenzentrum im Hintergrund rechts
ILM, Information Lifecycle Management, das heute in
aller Munde ist, wurde bereits intensiv im Jahr 1974 gelebt!
Der HSM (Hierarchical Storage Manager) als Verwalter der
Speicherhierarchie war damals ein Programm, das zunächst
in Verbindung mit dem Massenspeicher die ihm unterstellten
Dateien gemäß vorgegebener Steuerungskriterien automatisch
sicherte und im Bedarfsfall wiederherstellte. Eine weitere
damals bereits verfügbare Funktion war das Verlagern von
Dateien vom teuren Plattenspeicherplatz auf billigere Speicher
(ursprünglich auf den MSS) während der Zeiten, in denen
sie nicht benötigt wurden. Um den Speicherplatz optimal zu
nutzen, konnte der HSM zu archivierende Dateien komprimieren,
indem er leere Bereiche auf den Datenträgern ausließ,
und er konnte darüber hinaus Daten mithilfe binärarithmetischer
Verfahren verdichten (Compression, Compaction).
Zum Verarbeiten stellte er den ursprünglichen Zustand der
betreffenden Datei wieder her.
An unterschiedlichste Konfigurationen mit unterschiedlichen
externen Speichern angepasst, blieb der HSM fester Bestandteil
späterer Pakete von Dienstleistungsprogrammen für den
Bereich externer Speicher, z. B. der IBM DF­Produkte (Data
Facility), die den systemverwalteten Speicher zum Ziel hatten.
So wurden die DF­Produkte als Programmprodukte im Mainframe­Umfeld,
beginnend mit DFP, 1989 eingeführt. Kurz
darauf folgte der DFDSS und der DFHSM, die dann alle unter
dem Programmpaket DFSMS (Data Facility System Managed
Storage) 1992 zusammengefasst wurden und ein Jahr später
komplett ins MVS­Betriebssystem integriert wurden. HSM
spielt unter unterschiedlichen Bezeichnungen bis heute eine
ganz maßgebliche Rolle.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
25

26
1962 bis 1974
Die Epoche der Wechselplatten und die ‘Winchester’-Zeit
IBM 3850 Roboter mit Doppelgreifer (Standard) in Aktion IBM 3850 Bandpatronen mit 19,5 Metern Bandlänge und einer Kapazität von
jeweils 50 MB im Größenvergleich zum 3330 Plattenstapel mit 100 MB
Kapazität
Das MSS 3850 gab es in acht Modellvarianten. Das kleinste
Modell speicherte bis zu 706 Bandpatronen, bot eine Kapazität
von 35,3 GB und konnte bis zur größten Variante mit
bis zu 4.720 Patronen und einer Kapazität von 236 GB ausgebaut
werden.
Kommentar zur Epoche der Wechselplatten und
der ‘Winchester‘-Zeit
Das starke Ansteigen der Rechnerleistungen durch neue
Systeme machte es notwendig, viele neue Dinge auf der
Speicherseite einzuführen, um den neuen Leistungsanforderungen
dieser Rechner gerecht zu werden.
So wurden mit der IBM 2841 und IBM 3830 die ersten Mikroprogramm­gesteuerten
Steuereinheiten und das bis heute
gültige CKD­Format (heute ECKD bei zSeries) eingeführt. Für
höhere Übertragungsbandbreiten sorgten die neu eingeführten
Blockmultiplexing­Kanäle, die maßgeblich zu einer Verbesserung
der Gesamtleistung von Rechner und Speicherperipherie
beitrugen.
Bei den Platten selbst wurden kleinere Formfaktoren und
kleinere Flughöhen zwischen Kopf und Plattenoberfläche
eingeführt, um die Leistung durch schnellere Drehgeschwindigkeiten
und Datenraten sowie die kapazitiven Möglichkeiten
zu verbessern. Fast parallel dazu wurde die Leistung der
Bandsysteme angepasst und durch neue Möglichkeiten der
Mehrspurtechnik wurden die Datenraten erhöht.
Die Epoche war wie die Anfangsepoche durch neue Systemankündigungen
geprägt, in denen immer das dafür passende
Platten­ und Bandsystem Teil der Ankündigung war. Davon
losgelöste Speicherankündigungen fanden nicht statt.
Der Einsatz der damals verwendeten Wechselplatten war bei
den Endbenutzern sehr beliebt, weil man diese tragbaren
Plattenmodule auch für den Datenträgeraustausch zwischen
unterschiedlichen Lokationen einsetzen konnte. Die 1970 und
1973 neu angekündigten Modelle der 3420 wurden auschließlich
für Backup­Zwecke eingesetzt. Erst in der Folgeepoche,
in der man wieder fest eingebaute Platten einsetzte und
vom Prinzip der Wechselplatten wegging, erlebte die 3420
eine wahre Blütezeit. Das Rollenband war dann das einzige
Medium, das als auswechselbarer Datenträger eingesetzt
werden konnte.
Da die kapazitiven Anforderungen immer größer wurden und
neben Online­Speichern neue Massenspeicher mit höheren
Kapazitäten verlangt wurden, war eines der Meilensteine dieser
Epoche sicherlich das IBM 3850 Mass Storage System,
das erste Nearline­Roboter­System der Welt mit Bandpatronen,
die wie die damaligen Wechselplatten als Online­Speicher
adressiert wurden. Die Tatsache, dass bei dem MSS erstmals
ILM über eine HSM­Funktionalität eingeführt wurde, muss
besonders hervorgehoben werden. Diese HSM­Funktionalität
legte den Grundstein für die späteren DF­Produkte (Data
Facility) im Mainframe­Umfeld.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Die Epoche der fest eingebauten Platten
mit externen Kontrolleinheiten
1975 bis 1993
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
27

28
1975 bis 1993
Die Epoche der fest eingebauten Platten mit externen Kontrolleinheiten
IBM 3350, Kapazität bis 2.536 MB, 317 MB per LW, 8 Laufwerke pro 3350
Strang, Zugriffszeit 25 ms, Datenrate 1.198 KB/s, links hinten: Display-Einheit
für Microfiches, rechts hinten: Steuerkonsole des Systems/370 Modell 168
1975: Mit dem Magnetplattenspeicher IBM 3350 ging die
IBM wieder zu fest eingebauten Platten über. Das bedeutete
einen entscheidenden Schritt zu höherer Zuverlässigkeit
und Verfügbarkeit sowie höherer Aufzeichnungsdichte. Bei
dieser Konstruktion waren gegenüber der mit Datenmodulen
arbeitenden Type IBM 3340 potenzielle Störstellen nicht mehr
vorhanden, auf die 70 % der notwendigen Technikereingriffe
zurückzuführen waren. Tatsächlich registrierte der IBM Technische
Außendienst bei IBM 3350 im Durchschnitt weniger
als einen Eingriff pro Einheit und Jahr. IBM 3350 und die Nachfolgeprodukte
setzten das mit IBM 3330 begonnene Strangkonzept
fort. An eine Kopfeinheit (Master Unit) mit zwei Laufwerken
konnte man bis zu drei Nebeneinheiten anschließen.
Ein Strang bestand also aus acht Laufwerken. Die Kopfeinheit
besaß grundsätzlich zwei Ein­/Ausgänge zur Steuereinheit
IBM 3830. Die beiden Verbindungen konnten zu verschiedenen
Einheiten 3830 führen. Fielen ein Kanal, eine Steuerung
oder Steuerelemente in der Kopfeinheit aus, lief der Betrieb
auf der zweiten Verbindung zu jedem Laufwerk weiter, wenn
auch mit geringerer Leistung. Man kann in diesem neuen
Konzept den ersten Einstieg in Konzepte der Fehlertoleranz
erkennen.
Weil mit dem Magnetplattensystem IBM 3350 mit fest eingebauten
Platten nun die Magnetbandrolle das einzige auswechselbare
Speichermedium für Datensicherung, Offline­
IBM 3310 Direct Access Storage, Plattensystem für IBM 4331 Rechner
Archivierung und Datenträgeraustausch blieb, löste die IBM
3350 einen deutlichen Verkaufsanstieg bei Magnetbandeinheiten
aus, insbesondere bei den schnellen Modellen 6 und 8
des Magnetbandsystems 3420. Fortan waren Magnetbänder
unverzichtbarer Bestandteil größerer und auch mittlerer Datenverarbeitungssysteme.
1979 führte IBM ein weiteres Plattensystem ein, das IBM 3310
Direct Access Storage, das in einer kompakten Bauweise
hohe Leistung bei einem sehr günstigen Preis bot und seinen
Einsatz im Anschluss an IBM 4331, 4341, 4321, 4361 und
kleine 4381 Rechner fand. Jeder Plattenstapel bot eine
Gesamtkapazität von 64,5 MB und der gesamte Plattenstrang
258 MB. Bis zu vier Plattenstränge konnten an obigen Rechnermodellen
betrieben werden und boten eine Gesamtkapazität
von 1.032 MB.
1979 bis 1983: IBM 3370 und 3375 waren neu entwickelte
Magnetplatteneinheiten an der neuen Steuereinheit IBM 3880
für damals mittlere Systeme. Sie arbeiteten aus Gründen der
Vereinfachung und Beschleunigung von Programm abläufen
mit festen Blöcken von 512 Bytes. Der Benutzer definierte
größere Blocklängen mit einem Vielfachen von 512. Damit
war die erste FBA(Fixed Block Architecture)­Platte geboren.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

IBM 3380 Platten und 3880 Steuereinheiten füllten damals ganze Rechenzentrumshallen
Die neue IBM 3880 Steuereinheit leitete ein neues Steue­
rungsprinzip ein, das in der Weiterentwicklung 1985 die erste
Integration von Pufferspeichern, anfangs von 8 bis 16 MB,
zur Folge hatte. Diese kleinen Pufferspeicher waren für das
Ein­ und Auslagern von Seiten (Paging, Swapping) gedacht
und wirkten sich zunächst auf die Leistung älterer Konfigurationen
ohne Erweiterungsspeicher aus. Die Verwendung von
größeren Pufferspeichern führte dann zur Einführung neuer
Caching­Algorithmen. Die zu schreibenden Daten wurden in
der Steuereinheit auf Halbleiterspeicherkarten zwischengespeichert
und auf einem stromunabhängigen Schreibspeicher
dupliziert. Danach meldete die Steuereinheit dem Rechner
den Abschluss der Operation, obwohl die Daten noch nicht
auf die Platten geschrieben waren. Diese Operation wurde
damals als ‘DASD Fast Write’ bezeichnet, weil durch dieses
Prinzip die Antwortzeiten zwischen den Plattensystemen und
dem Rechner um ein Vielfaches verbessert wurde. Dieses
damals eingeführte ‘Caching’­Prinzip für Plattensubsysteme
wurde dann rasch weiterentwickelt und hat bis heute
Gültigkeit.
1981: IBM 3380 waren Magnetplatteneinheiten, die als
Neuentwicklung für die 3880 Steuereinheiten optimiert waren
und das CKD­Format fortsetzten. Die IBM 3380 übertrug mit
3 MB pro Sekunde und nutzte dabei spezielle Fähigkeiten
der Blockmultiplexkanäle (Data Streaming). Die neuen Lauf­
werke kamen gerade rechtzeitig, denn zu diesem Zeitpunkt
war deutlich geworden, wie notwendig es bei der engen
Beziehung zwischen Prozessoren und Plattenspeichern war,
die Leistung beider aufeinander abzustimmen.
1981 wurden die Standardmodelle AA4 und B04 der IBM 3380
angekündigt. 1985 folgten die erweiterten Modelle AD4, BD4,
AE4 und BE4. 1987 wurden die schnellen AJ4 und BJ4 und
die schnellen, großkapazitiven Modelle AK4 und BK4 angekündigt.
Ebenso erfolgte 1987 die Ankündigung der 3380 CJ2,
eines Modells, bei dem die Steuereinheit im Plattengehäuse
integriert war.
IBM 3370, 1 Plattenstapel pro Einheit mit 2 Zugriffsarmen und 2 Adressen,
Modell 1: 571 MB, Modell 2: 730 MB, jeweils per Einheit, bis zu 4 Einheiten
mit 2.285 – 2.920 MB Kapazität, Zugriff 20 ms, Datenrate 1,86 MB/s
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
29

30
1975 bis 1993
Die Epoche der fest eingebauten Platten mit externen Kontrolleinheiten
Die Zeit der 3380­Platte brachte im Antwortzeitverhalten, im
Durchsatz und in den hohen Kapazitäten für die damals betrie­
benen IBM Rechner 3031, 3032, 3033, 3042 und /370 große
Fortschritte. Die durchschnittlichen Suchzeiten bewegten
sich – je nach Modell – zwischen 12 und 16 ms. Immer zwei
Laufwerke waren in einer Gehäuseeinheit untergebracht. Pro
Laufwerk wurden Kapazitäten von 1,26 GB (J­Modelle) und
3,78 GB (K­Modelle) abgebildet. Dies bedeutete für einen
voll ausgebauten 4­pfadigen Strang von J­Modellen eine
Gesamt kapazität von 20,16 GB und bei den K­Modellen
wurden bis zu 60,5 GB Gesamtkapazität erreicht.
Die Platten wurden im 14­Zoll­Format gebaut. Um die gewichtigen
Plattenstapel aus den Gehäuseeinheiten zu heben, wurden
vom technischen Außendienst speziell dafür gebaute
Hubwagen eingesetzt.
Im 3880/3380 Subsystem wurde aus Pfadredundanzgründen
die Funktion ‘Dynamic Path Reconnect’ eingeführt, die im
Falle eines Pfadfehlers dafür sorgte, dass die Datenübertragung
zu jedem HDA des Subsystems auf einem alternativen
Pfad erfolgen konnte. Diese Multipfadarchitektur in Verbindung
mit dem neuen Kanalsubsystem des Mainframes sorgte für
einen um 30 % höheren Durchsatz im Speichersubsystem.
Physikalische Spezifikation der 3380 Plattensubsysteme:
Modelle A/B D E CJ2 J K
Actuators per Unit 4 4 4 2 4 4
Zylinder per Device 885 885 1770 885 885 2655
Tracks per Device 13275 13275 26550 13275 13275 39825
GB per Unit (Box) 2.520 2.520 5.041 1.260 2.520 7.562
Auf der Magnetbandsubsystemseite führte IBM 1983 das
letzte Rollenbandsystem mit der IBM 3430 ein, das vor allem
bei IBM 43xx­ und IBM 303x Series­Prozessoren, aber auch
bei dem damaligen Midrange System/38 seinen Einsatz fand.
Die kompakte Bauweise erlaubte den Benutzern die Aufstellung
auf wesentlich kleinerer Fläche im Vergleich zur IBM 3420.
Die Rollenbänder wurden von oben horizontal eingelegt wie
bei IBM 3410 (1971).
Aufgrund der ein Jahr später angekündigten neuen IBM 3480
Kassettentechnik als Ablösung der Rollenbänder fanden 3430
Einheiten nicht in großen Stückzahlen ihren Absatz, hiel ten sich
aber dennoch ziemlich lange auf dem Markt, um der Datenträgeraustauschanforderung
gerecht zu werden, die in den
Folgejahren immer noch auf Rollenbändern gemacht wurde.
IBM 3430 Magnetbandsubsystem, letztes Rollenband der IBM,
Markteinführung 1983
1984:
Die erreichte Dynamik in der Leistung von 3880/3380 Plattensubsystemen
und /370 Rechnern erforderte auch eine
Leistungsanpassung auf der Backup­Seite, den Magnetbandsystemen.
Mit der IBM 3480 wurde der Wechsel von den bis
dahin verwendeten Rollenbandsystemen auf die Kassettentechnik
eingeleitet. Das neue Magnetbandsystem IBM 3480
übertrug, gleich schnell wie die Plattenspeicher IBM 3380, mit
3 MB pro Sekunde und schloss damit die Lücke im Gesamtsystemverhalten.
Die bis dahin verwendeten 10,5­Zoll­Rollenbänder
der 3420 Technologie wurden durch handtellergroße,
rechteckige Kassetten abgelöst. Bei einer Aufzeichnungsdichte
von 38.000 Bytes pro Zoll nahmen die neuen Kassetten
doppelt so viel Daten auf wie herkömmliche Bandrollen,
also bis zu 200 MB. Mit einem Zusatz, einem Vorratsschacht
(Stacker), konnten mehrere Kassetten hintereinander automatisch
vorgeladen werden. Das erleichterte maßgeblich das
Sichern großer Datenbestände.
IBM 3480 Magnetbandsystem
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1984: Wechsel vom klassischen Rollenband auf die 3480 Kassettentechnologie
1989:
Mit der IBM 3390 Plattentechnologie wurde der bei IBM 3380
verwendete Formfaktor von 14 Zoll auf 10,8 Zoll reduziert.
Anfangs wurde die 3390 Technologie noch mit der herkömmlichen
‘braunen Beschichtung’ produziert, wo Eisenoxyd­
Partikel (Rostpartikel), die möglichst homogen in einer Kunstharzmasse
zur gleichmäßigen Magnetisierung verteilt waren,
als Magnetisierungsträger eingesetzt wurden. Die Einführung
einer neuen Beschichtung, deren Entwicklung 1989 eingeleitet
wurde und die 1991 zur Anwendung kam, ließ den Einsatz
einer neuen Schreib­/Lesetechnik zu. Die neuen Köpfe
schrieben – wie ihre Vorgänger – induktiv, erzeugten also
Magnetfelder in der Beschichtung der Platten mithilfe eines
winzigen Spalts im Metallkern miniaturisierter Elektromagnete.
Bis zu diesem Zeitpunkt dienten die Elektromagnete auch
zum Lesen. Für die Zahl der Spulenwindungen musste man
Größenvergleich Magnetbandsysteme IBM 3420 gegenüber IBM 3480
einen Kompromiss für Lesen und Schreiben finden, um beide
Vorgänge zu ermöglichen. Jetzt konnten sie ausschließlich
für den Schreibvorgang optimiert werden, denn das Lesen
erfolgt bei der 3390 Technologie über eine zweite Komponente,
einen Lesefilm. Der Film war sehr klein und bestand
aus dünnen Schichten verschiedener Metalle wie Eisen, Chrom
und Kobalt. Kurze Zeit später wurde der Film auf Nickel und
Eisen umgestellt. Wenn sich innerhalb der Spur auf der Platte
die Magnetisierungsrichtung umkehrte, änderte sich der
elektrische Widerstand vor allem in der mittleren Schicht des
darüber befindlichen Kopfes sprunghaft. Dies bezeichnet man
als magnetoresistiven Effekt, den man als Signal entsprechend
verstärkt und auswertet. Diese neue Technik gewährleistete
sicheres Lesen bei höchster Aufzeichnungsdichte, weil selbst
kleinste Streufelder von Informationseinheiten differenziert
werden konnten. Man führte – einfach gesagt – zwei Spezialisten
ein, einen für das Schreiben optimierten induktiven Kopf
und einen Spezialisten für den Lesevorgang (ausführliche
Beschreibung im Technologie­Anhang). Beide Spezialisten
zusammen bildeten das Schreib­/Leseelement, das vom
Zugriffsmechanismus positioniert wurde.
Die neue Schreib­/Lesekopf­Technik der IBM 3390 benötigte
eine neue Beschichtung in sogenannter Dünnfilmtechnik.
Dabei beschichtete man die Oberflächen von Glasplatten aus
einem speziell gehärteten Glas mit einer Legierung und unterzog
sie anschließend einem Einbrennprozess. Die magnet o­
resistive Schreib­/Lesetechnik in Verbindung mit Dünnfilmbeschichtungen
auf den Platten kam innerhalb der 3390
Baureihe mit den Modellen 3 und 9 erstmals zum Einsatz. Die
seit der Einführung von Magnetplatten verwendet Aluminiumplatte,
die mit feinst gemahlenem, weichmagnetischem
Material in einem Kunstharz als Bindemittel beschichtet war,
hatte damit ausgedient.
Im Vergleich zur IBM 3380 Baureihe lieferte die 3390 Baureihe
eine Verbesserung in der Zugriffszeit von 28 % und die
Datentransferrate wurde um 40 % gesteigert, weil anstelle von
3 MB/s mit 4,5 MB/s übertragen werden konnte. So konnten
die Kanalgeschwindigkeiten des damals neuen 3090 Rechners
genutzt werden. Ebenso konnte vom Rechner auf die
Subsysteme über vier gleichzeitige Pfade übertragen werden
(Four Path Data Transfer). Die 3390 Platten und auch noch
die 3380 Platten wurden an der neuen IBM 3990 Steuereinheit
angeschlossen, die mit höheren Plattenpuffergrößen
(Cache) von 16 bis 64 MB (3990 Modelle 3) ausgestattet war.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
31

1975 bis 1993
Die Epoche der fest eingebauten Platten mit externen Kontrolleinheiten
1989: IBM 3390-1/2, 1991: IBM 3390-3, 1994: IBM 3390-9, hinten IBM 3380-K Strang mit 60 GB Kapazität, vorne 3390-3 Strang mit 90 GB Kapazität, rechts IBM
3990 Steuereinheiten
Ein voll ausgebauter 3390 Modell 3 Strang mit 1 x A38 und
2 x B3C hatte also eine Gesamtkapazität von 90 GB. Das
Großkapazitätsmodell 9, das 1994 auf den Markt kam, verdreifachte
nochmals die Kapazität. Allerdings kamen die
Modelle 9 nur begrenzt zum Einsatz, weil die Platten aufgrund
ihrer hohen Kapazität langsamer waren, und wurden für
Anwendungen eingesetzt, wo die Zugriffszeiten und Datenraten
ausreichten.
Physikalische Spezifikation der 3390 Plattensubsysteme
Modelle Kapazität/ Kapazität/ Anzahl Kapazität/
Actuator HDA HDAs Unit
A14 0.946 1.89 2 3.78
A18 0.946 1.89 4 7.56
B14 0.946 1.89 2 3.78
B18 0.946 1.89 4 7.56
B1C 0.946 1.89 6 11.35
A24 1.89 3.78 2 7.56
A28 1.89 3.78 4 15.1
B24 1.89 3.78 2 7.56
B28 1.89 3.78 4 15.1
B2C 1.89 3.78 6 22.7
A34 2.838 5.67 2 11.34
A38 2.838 5.67 4 22.68
B34 2.838 5.67 2 11.34
B38 2.838 5.67 4 22.68
B3C 2.838 5.67 6 34.02
1991:
In diesem Jahr wurde von IBM der erste Schritt in Richtung
kleinerer Formfaktoren von Magnetplattenlaufwerken in
Subsystemen eingeleitet. Die angebotenen Plattensysteme
IBM 9340 und IBM 0662, erstmals auf der Basis von Plattendurchmessern
mit 5,25 bzw. 3,5 Zoll, bestanden aus einem
Rahmen, in den die Steuereinheit zusammen mit mehreren
Plattenlaufwerken eingebaut wurden. Ein Standardrahmen
Typ 9309 nahm bis zu acht Platteneinschübe vom Typ IBM
9345 auf. Ein Platteneinschub enthielt zwei Laufwerke mit
jeweils 1 oder 1,5 GB Speicherkapazität. Es waren 5¼­Zoll­
Laufwerke neuster Technologie mit einer Datenrate von
4,4 MB/s, mittlerer Umdrehungswartezeit von nur 5,6 ms
und in bewährter Count­Key­Data(CKD)­Speicherungsform.
Für Anforderungen bis 24 GB gab es den Steuereinschub
IBM 9341, der als 2­Pfad­Subsystem ohne Cache an die
Prozessoren­Reihe 9221 oder 9370 angeschlossen war.
Größerer Speicherbedarf und noch höhere Anforderungen
wurden mit dem Standardrahmen IBM 9343 mit eingebauter
Steuereinheit mit 4­pfadigem Funktionsumfang und mit 9345
Einschüben abgedeckt. Die Kapazität konnte stufenweise auf
48 GB ausgebaut werden. Die IBM 9341/9343 erlaubten das
unterbrechungsfreie Hinzufügen von Platteneinschüben. Hohe
Leistung ohne Cache wurde im Speziellen bei Datenbankanwendungen
mit hohem Randomzugriff erzielt. Erhebliche
Steigerungen bei entsprechenden Anwendungen wurden
später durch einen modellabhängigen 32­MB­ bis 64­MB­
Cache möglich.
32 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang Software Anhang

1989/1991:
Parallel zur 3390 Plattenentwicklungsreihe wurde 1989 auf
der Tape­Seite der Nachfolger des 3480 Bandsystems,
die IBM 3490, verfügbar und 2 Jahre später die erweiterte
Version in Form der IBM 3490E. Bei der 3490 Laufwerktechnologie
wurde mit 18 Spuren, bei der 3490E Technologie mit
36 Spuren gearbeitet.
Die 3490 Technologie verwendete zur Steuerung des Bandsubsystems
erstmals sehr leistungsstarke Kontrolleinheiten
mit einem dynamischen Pufferspeicher von 2 bzw. 8 MB.
Ebenso wurde bei der Aufzeichnung mit einem neuen Kom­
IBM 3490 Magnetbandsystem
primierungsverfahren gearbeitet, dem IDRC (Improved Data
Recording Capability), das Komprimierungsfaktoren von bis
zu 3 :1 zuließ. Die neuen 3490 Systeme konnten mit ESCON­
Kanälen angesteuert werden, wie es bei den 3390 Platten
der Fall war. Damit war der Grundstein für ESCON gelegt,
das im Laufe der nächsten Jahre die bis dahin verwendete
BMPX(Block Multiplex)­Verkabelung ablösen sollte.
Die erreichte Aufzeichnungsdichte lag bei IBM 3490 bei
38.000 BPI mit Kassettenkapazitäten von 600 bzw. 1.200 MB,
bei 3490E wurden durch die doppelte Spurzahl 78.000 BPI
erreicht mit Kassettenkapazitäten von 1.200 und 2.400 MB.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang Software Anhang 33

34
1975 bis 1993
Die Epoche der fest eingebauten Platten mit externen Kontrolleinheiten
IBM 3495 Bandarchiv mit 5.660 bis 18.920 Kassetten (13,5 bis 45,5 TB), Höhe 2,38 Meter, Tiefe 2,46 Meter, Länge modellabhängig 13,4, 18,3, 23,2 oder 28,0
Meter, 4 bis maximal 64 Laufwerke IBM 3490
1992: IBM kündigte nach einigen Jahren der Kooperation im
Bandarchivbereich mit den Firmen Grau und Haushahn ein
eigenes automatisches Magnetbandarchiv IBM 3495 für
große Prozessoren an, die unter dem Betriebssystem MVS
unterstützt waren. Bei einer Kassettenkapazität IBM 3490 von
2,4 GB konnten die Benutzer die Library­Kapazitäten von
13,5 TB auf 45,5 TB ausbauen.
Zum Vergleich: Der Massenspeicher von 1974 erlaubte
maximal etwa 0,24 TB.
Das damals verwendete Robotersystem der 3495 war tonnenschwer
und wurde vom Markt bis auf wenige Kunden
nicht sonderlich akzeptiert. Oft wurde an die IBM die Frage
gerichtet, warum ein tonnenschwerer Roboter notwendig sei,
um eine kleine 3490 Kassette zu transportieren.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1993: Etwa eineinhalb Jahre später kam dann das automatische
Magnetbandarchiv IBM 3494 in wesentlich kompakterer
Bauweise und mit einem adäquaten Robotersystem,
das neben der MVS­Plattform auch AS/400­ und
RISC­6000­Systeme unterstützte.
Das 3494 Librarysystem wurde in den Folgejahren funktional
erweitert und ist bis heute noch ein aktives Librarysystem, das
vor allem im Mainframe­Umfeld eingesetzt wird. Es war auch
die erste IBM Tape­Library, die den Mischbetrieb von 3490
und 3490E Laufwerken und Kassetten ermöglichte und auch
den Nachfolger der 3490, die IBM 3590 Laufwerktechnologie,
unterstützte. Mit 3590 Laufwerken, die als Nachfolger der
3490E im Jahr 1995 verfügbar wurden, konnten mit dem
ersten Modell B Kanaldatenraten von 9 MB/s realisiert werden.
Die 3494 war zudem eine Library, die gleichzeitig den
Mainframe und Open Systems bedienen konnte und kann.
Später wurden die Modelle E und H der 3590 unterstützt.
Der Library Manager der 3494 wurde kontinuierlich weiter­
entwickelt und den Virtual­Tape­Server­Systemen VTS mit
ihren weiterentwickelten Funktionalitäten, die mit der Library
bis heute betrieben werden können, angepasst. Mit der Verfügbarkeit
der ersten Jaguar­3592­Laufwerke im September
2003 (siehe Epoche Multiplattformsysteme und SAN) entwickelte
IBM eine intelligente Integration dieser kleinen Laufwerke
in die 3494 Library. In der exakten Größe eines
Magstar­3590­Laufwerks wurden Gehäuseeinheiten, sogenannte
‘Cradles’ gebaut, wo zwei Jaguar­Laufwerke im vorderen
Teil untergebracht werden können. Nach hinten sind
die Cradles offen. Dort sind zwei Netzteile untergebracht.
Die beiden Jaguar­Laufwerke sind an beide Netzteile angeschlossen,
um die Stromversorgung über zwei unabhängige
Quellen sicher zustellen. Die IBM 3494 wird im Jahr 2010
noch in einigen Rechenzentren aktiv betrieben. IBM publizierte
im Jahr 2005 das ‘SOD’ (Statement of Direction),
zukünftige Jaguar­Laufwerkstechnologien weiterhin zu unterstützen.
So kann auch noch das neue Highend­Laufwerk
TS1130 in die Library eingebaut werden. Im Herbst 2009
erfolgt die Zurückziehung von Marketing. IBM plant, die
Library 3494 bis Ende 2015 in der IBM Wartung zu halten.
1993 IBM 3494 IBM 3494 Gehäuseeinheit D22 mit ‘Cradles’ und TS1120(Jaguar)-Laufwerken
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 35

36
1975 bis 1993
Die Epoche der fest eingebauten Platten mit externen Kontrolleinheiten
Kommentar zur Epoche der fest eingebauten Platten
mit externen Kontrolleinheiten
Die Anforderungen bezüglich Hochverfügbarkeit wurden
immer höher. Deshalb ging man von den Wechselplatten auf
fest eingebaute Platten über. Fest eingebaute Platten waren
um ein Vielfaches zuverlässiger. Neben der Verfügbarkeit
wurden auch die Ansprüche an Investitionsschutz immer
höher. Um dem Rechnung zu tragen, etablierte die IBM über
die gesamte Epoche das Prinzip des Wechsels für Steuereinheiten
und Plattenspeicher. Dies sah so aus, dass neue
Platteneinheiten an die vorhandenen Steuereinheiten angeschlossen
werden konnten, dann kam eine neue, leistungsstärkere
Steuereinheit, an der die alten Platten betrieben
wurden. Dann wurden wieder neue Platten verfügbar, die an
die vorhandene Steuereinheit angeschlossen werden konnten,
danach kam wieder eine neue Steuereinheit. Dieses Wechselprinzip
wurde vom Markt so positiv angenommen, dass es
bis in die Folgeepoche der RAID­Systeme gepflegt wurde.
Auf der Steuereinheiten­Seite wurden mit der IBM 3880 erstmals
Cache und entsprechende Caching­Algorithmen eingeführt,
um mit der Leistungsentwicklung der Rechnersysteme
Schritt zu halten. Die wichtigste Funktion war hier das ‘DASD
Fast Write’. Dies wurde auch mit der neuen 3990 Steuereinheit
weitergepflegt und ausgebaut. Eine Funktion nach der
anderen kam hinzu. Die funktionalen Erweiterungen setzten
sich kontinuierlich bis zum letzten Modell der externen Steuereinheiten,
der 3990 Modell 6, bis Mitte der 90er­Jahre fort.
Anfang der 90er­Jahre wurde die ‘Braune’­Platten­Produktion
umgestellt und Dünnfilm­Beschichtungen wurden eingeführt.
Dies führte zu wesentlich höherer Zuverlässigkeit, weil mit
Grain­Strukturen gearbeitet werden konnte und Eisenoxydpartikel
(Rost) als Datenträger wegfielen. Die neu entwickelte
Magnetoresistive Kopftechnik (MR­Kopftechnik) kam zum
Einsatz (siehe auch Technologie­Anhang).
Im Tape­Bereich kam 1984 der große technologische Wechsel.
Das Rollenband wurde durch eine kleine Kassette mit der
3480 Bandtechnik ersetzt. Dies war vor allem notwendig,
um den Bandbereich in der Leistung den Platten und dem
Gesamtsystem anzugleichen.
Anfang der 90er­Jahre kamen dann die ersten automatisierten
Bandarchive mit den Produkten IBM 3495 und IBM 3494 mit
Roboter und Greifersystemen, die die Bandkassetten transportieren
konnten.
Insgesamt war die sehr lange anhaltende Epoche der fest
eingebauten Platten mit externen Steuereinheiten eine Epoche,
die durch konstante Weiterentwicklungen im Hinblick auf
Datensicherheit und Investitionsschutz geprägt war und sicherstellte,
dass die Speicher mit den neu entwickelten Rechnersystemen
Schritt hielten. Oberstes Gebot war neben Datensicherheit
die Gesamtleistung des Verbundes von Rechnern
und Speichersystemen.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Die Epoche der RAID-Systeme
1994 bis 1998
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
37

38
1994 bis 1998
Die Epoche der RAID-Systeme
Plattensysteme mit RAID-Architekturen
IBM bot 1994 ein völlig neues Konzept externer Magnetplattensysteme
unter dem erstmals seit 1956 wieder benutzten,
eingetragenen Warenzeichen ‘RAMAC’ an. Dieses Mal stand
die Buchstaben­Reihenfolge RAMAC für ‘RAID Architecture
with Multilevel Adaptive Cache’.
Was war der Hintergrund und was bedeutete dies konkret?
1. Die Verarbeitungsgeschwindigkeit vergleichbarer Prozessoren
war zwischen 1964 und 1994 ungefähr 400-mal
schneller gewachsen als die Übertragungsrate der Zugriffsmechanismen
der Plattenspeicher und etwa 30-mal schnel ler
als die Übertragungsgeschwindigkeit der gängigen Kanäle.
Am schnellsten wuchs die Kapazität pro Zugriffsmechanismus
– ungefähr um den Faktor 6.000 – und damit doppelt
so schnell wie die Verarbeitungsgeschwindigkeit der Prozessoren.
Die Ansprüche an die Datenverfügbarkeit in
internationalen und firmeninternen Netzen nahmen ständig
zu und weil technisches Versagen von Komponenten nie
ganz ausgeschlossen werden konnte, wuchs die Forderung
nach fehlertoleranten Systemen.
2. Parallel zur Entwicklung immer leistungsfähigerer Magnetplattenspeicher
für große und mittlere Systeme hatte die
Industrie – IBM eingeschlossen – für den schnell wachsenden
Markt der Einzelplatzrechner (PC, Laptop, Notebook)
in den Abmessungen kleine, aber auf hohem technischem
Niveau stehende, leistungsfähige und zuverlässige
Platten laufwerke auf den Markt gebracht. Damals war
abzusehen, dass die Kapazitäten dieser Laufwerke rasant
steigen würden. Es kam noch hinzu, dass diese kleinen
Plattenlaufwerke aufgrund hoher Maßenproduktion
wesentlich kosten günstiger gefertigt werden konnten als
die großen Plattenfiles, die zu diesem Zeitpunkt bereits als
SLEDs (Single Large Expensive Disks) bezeichnet wurden.
3. Bereits 1987 schilderte die Universität Berkeley in Kalifornien
(die Studie erfolgte im Auftrag der IBM) in einem Dokument
mit dem Titel „Eine Studie über redundante Anforderungen
kostengünstiger Plattenspeicher“ (A Case for Redundant
Arrays of Inexpensive Disks), wie man die betreffenden
Plattenlaufwerke zu einem aus Sicht der Betriebssysteme
einzigen adressierbaren Datenträger zusammenschalten
konnte, um sie für größere Systeme zu nutzen und dabei
entweder höhere Übertragungsraten oder höhere Datenverfügbarkeit
oder beides zu erreichen. In diesem Papier
wurden 5 RAID-Stufen (RAID-Levels) definiert, die sich in
der Abwägung zwischen Übertragungsleistung und dem
Grad der Fehlertoleranz unterschieden.
RAID1 beschreibt die doppelte Speicherung von Daten auf
zwei Platten mit völlig identischem Inhalt (Spiegelung, Mirroring).
Fällt ein Laufwerk aus, greift das System auf das
andere zu.
Bei RAID2 werden die Daten byteweise auf mehrere Platten
kopiert (Mehrfachspiegelung). Auf einer weiteren Platte wird
ein Fehlercode gespeichert, mit dessen Hilfe verlorene Daten
rekonstruiert werden.
Bei RAID3 werden die einzelnen Bytes ebenfalls auf mehre­
ren Platten – allerdings abwechselnd – gespeichert und auf
einer separaten Platte sogenannte Paritätsbits. Fällt eine
Platte aus, lässt sich deren Inhalt über den der intakt gebliebenen
Platten und die Paritätsbits wiederherstellen.
RAID4 unterscheidet sich von RAID3 dadurch, dass die
Daten statt in einzelne Bytes in ganze Blöcke von mehreren
Kilobytes unterteilt werden.
Bei RAID5 erzeugt das System Paritätsbits für Blöcke von
mehreren Kilobytes, die auf alle Platten so verteilt sind, dass
sie immer auf einer anderen Platte stehen als die Daten, aus
denen sie erzeugt wurden. Das Verfahren bietet hohe Sicherheit
bei relativ schnellem Zugriff, weil durch die Verteilung
parallele Schreib­Updates möglich sind. Deswegen erfuhr
dieser RAID­Level die stärkste Verbreitung.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Der Vollständigkeit halber seien noch später hinzugefügte
RAID­Stufen erwähnt:
RAID6 bietet gegenüber RAID5 zusätzliche Paritätsbits
(zwei Parity­Schemen) und damit noch mehr Sicherheit (bis
zu zwei Platten können innerhalb eines Arrays ausfallen),
allerdings auf Kosten der Leistungsfähigkeit eines Arrays.
RAID7 protokolliert dazu noch sämtliche Schreibzugriffe.
RAID0 verteilt die Daten in kleinen Paketen auf mehrere Platten
und ermöglicht schnellen Zugriff, mangels Redundanz
jedoch keine erhöhte Sicherheit. Schließlich gibt es noch
RAID10, auch als Stufe 1 + 0 bezeichnet. Sie arbeitet wie
RAID0, jedoch mit zwei gleich großen Sätzen von Platten,
wobei die zweite Gruppe das exakte Spiegelbild des Inhalts
der ersten Gruppe enthält. Diese Lösung erfordert viele
Laufwerke.
Inzwischen haben sich (bis heute, im Jahr 2010) aus diesen
Basis­RAID­Stufen gänzlich neue RAID­Levels entwickelt, die
jenseits der Standard­Levels liegen, teilweise unsinnig sind,
aber in manchen Fällen auch eine Optimierung der Basis­
Levels darstellen (wie z. B. RAID 1E, 1E0, 1.5, Matrix RAID,
RAID15, 51, 53, 45, RAID5E, 5EE und RAID5DG/RAID ADG).
4. Bereits 1992 konstituierte sich ein RAID-Beratergremium
(RAID Advisory Board) aus 40 Anwender- und Herstellerfirmen,
zu denen auch IBM zählte. Damit wurde RAID in den
90er -Jahren zu einer Art Industriestandard. Die Originalbezeichnung
RAID wurde in der Bedeutung geringfügig
korrigiert: Aus ‘kostengünstigen Einheiten’ (Redundant
Array of Inexpensive Disks) wurden ‘unabhängige Einheiten’
(Redundant Array of Independent Disks).
Bereits seit 1978 besitzt IBM ein Patent über die Wiederherstellung
von Daten, die auf einer ausgefallenen Einheit aus
einer Gruppe von Laufwerken gespeichert wurden. Wie die
gesamte Industrie bemühte sich IBM, den Herausforderungen,
die sich aus den oben dargestellten Punkten ergab, wirksam
zu begegnen. Die zunehmenden Veränderungen im Markt
mit seiner ständig wachsenden Zahl von Anbietern, immer
mehr etablierten Hardware­ und Softwareplattformen, dynamischen
Innovationen und den damit immer kürzer werdenden
Produktzyklen machten es notwendig, die IBM Geschäftspolitik
maßgeblich zu verändern und anzupassen. Bisher hatte
IBM fast ausschließlich für den eigenen Bedarf zum Vertrieb
über die eigene Organisation an Endbenutzer produziert und
war nur vereinzelt als Unterlieferant anderer Hersteller
aufge treten (Branchen­Fachausdruck für solche Geschäfte ist
OEM, Original Equipment Manufacturer). Ein Beispiel waren
in den 80er­ und 90er­Jahren geschlossene Verträge über
Lieferungen von leicht modifizierten IBM Plattenspeichern an
Siemens. IBM ließ immer Fremdprodukte aller Art innerhalb
ihrer Konfigurationen und Softwareplattformen zu, ohne in
den Umgebungen anderer Hersteller als Anbieter aufzutreten.
Auf die bei den DV­Benutzern um sich greifende Vernetzung
von Datenverarbeitungsprodukten und DV­Plattformen verschiedener
Hersteller – heterogene Client­/Serverumgebungen
– reagierte IBM mit Angeboten, bei denen alle für die jeweiligen
Produkte relevanten eigenen und fremden Schnittstellen
unterstützt wurden. Das Storage­Geschäft wurde durch das
Anwerben von entsprechenden Geschäftspartnern neben
dem eigentlich blauen Vertrieb zusätzlich vorangetrieben.
Man arbeitete mit immer mehr Geschäftspartnern, die sich
in ihrer Vertriebsorganisation erfolgreich um den Absatz von
IBM Hardeware­ und Softwareprodukten bemühten. Dieser
Trend hat sich bis heute noch maßgeblich verstärkt.
Wie bereits eingangs dieses Kapitels beschrieben, machte
IBM 1994 als erste Firma das auf RAID5 basierende Magnetplattensystem
verfügbar, der damaligen RAMAC 1 (IBM
9391). RAMAC 1 wurde im Juni 1994 angekündigt und war
ab September 1994 verfügbar. Als Basis für eine RAMAC­
Speichereinheit diente ein Einschub IBM 9392 (Drawer),
der mit mehreren anderen Einschüben in einen Rahmen
integriert wurde. Jeder dieser Einschübe beinhaltete vier
Plattenlaufwerke auf 3,5­Zoll­Basis mit jeweils 2 GB Kapazität
(Allicat­Laufwerke), zwei Netzteile, zwei Kühlgebläse, einen
RISC­Mikroprozessor als Controller, einen batteriegestützten
Pufferspeicher (Non Volatile) und einen Akku. Jeder Einschub
stellte ein für sich geschlossenes RAID5­System dar. Bis zu
16 dieser RAID5­Einschübe konnten in den Rahmen integriert
werden. RAMAC kam in zwei Ausführungen. Das RAMAC
Array beinhaltete nur die RAID5­Einschübe und wurde an
die damalige, leistungsstarke Steuereinheit 3990 angeschlossen.
Das RAMAC Subsystem beinhaltete die übergeordnete
Controllerfunktion in demselben Gehäuse, in dem auch die
Einschübe integriert waren, und war seitlich im Rahmen
eingebaut. In der vollen Ausbaustufe lieferten beide
Systeme eine nutzbare Plattenkapazität, RAID5­gesichert,
von 90 GB aus.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
39

40
1994 bis 1998
Die Epoche der RAID-Systeme
RAMAC 2 und RAMAC 3 folgten wegen der raschen Fort­
schritte in den kapazitiven Möglichkeiten der 3,5­Zoll­Laufwerke
im Abstand von nur einem Jahr. Bei RAMAC 2 kamen
die Ultrastar­XP­Laufwerke und bei RAMAC 3 die Ultrastar­
2XP­Laufwerke zum Einsatz. Die rechnerische Kapazität verdoppelte
sich jeweils per Subsystem.
RAMAC 2 bot mit 16 Einschüben eine nutzbare Kapazität
von 180 GB und RAMAC 3 von 360 GB.
Mit RAMAC 3 in der Version des RAMAC Arrays zum Anschluss
an 3990 Steuereinheiten wurde zeitgleich ein neues
Modell der Steuereinheit eingeführt, der 3990 Modell 6. Diese
Steuereinheit war eine Doppelsteuereinheit, die in ein Gehäuse
integriert war und an der zwei RAMAC 3 Arrays betrieben
werden konnten. Damit lieferten zwei RAMAC 3 Arrays an der
3990­6 als ‘Doppelsubsystem’ eine Gesamtkapazität von bis
zu nutzbaren 720 GB aus.
Die RAID5­RAMAC­Baureihe war auf dem Markt sehr erfolgreich,
konnte aber über die Jahre nicht fortgesetzt werden,
weil der Kostenfaktor in der Produktion dem Preisverfall der
Gigabytes in den angebotenen Subsystemen nicht standhalten
konnte. Jeder Einschub als eigenständiges System und
bis zu 16 Einschübe unter einer eigenen Steuereinheit, dadurch
zwei Cache­Ebenen: das war sehr aufwendig zu produzieren.
links: IBM RAMAC Subsystem mit integrierter Steuereinheit
rechts: IBM RAMAC Array zum Anschluss an 3990 Steuereinheiten
Dies war einer der Hauptgründe, warum 1996 eine Kooperation
mit der Firma StorageTek bezüglich des Vertriebs
und der Weiterentwicklung des verfügbaren ‘Iceberg’­Plattensystems
geschlossen wurde und die IBM zwei Plattensubsysteme
der Firma STK in den Vertrieb nahm. Der ‘Iceberg’
wurde von IBM unter dem Namen IBM RVA (RAMAC
Virtual Array) vermarktet, das Großkapazitätssystem von
STK als IBM RSA (RAMAC Scalable Array). Das RAMAC
Virtual Array wurde im Juli 1996 mit sofortiger Verfügbarkeit
angekündigt. Das leistungsstärkere RVA in der Turboversion
wurde knapp ein Jahr später, im April 1997, verfügbar.
Das RAMAC Virtual Array IBM RVA IBM 9393 erfüllte die Be­
dingungen von RAID6 und bot eine sehr intelligente Lösung
für das Anlegen und das Wachstum von Dateien. Normaler­
weise mussten Benutzer bisher für wachsende Dateien genügend
Platz reservieren. Das bedeutete, einen ständigen
Vorrat von leeren Spuren (Allocated Tracks) bzw. nicht genutzte
Kapazität vorzuhalten. Wenn das System beim Ausführen
eines Programms für eine wachsende Datei keine Kapazität
mehr vorfand, führte das zum anomalen Abbruch der Operation.
Beim RVA suchte das System automatisch freien Platz.
Reservierung (Allocation) war nicht mehr erforderlich und
Abbrüche wegen fehlenden Speicherplatzes ausgeschlossen.
Dieser spezielle Algorithmus wurde als logisch strukturierter
File­Algorithmus (Log Structured File) bezeichnet.
1996 –1998 IBM RAMAC Virtual Array RVA, IBM RAMAC Virtual Array 1996,
IBM RAMAC Virtual Array Turbo 1997, IBM RAMAC Virtual Array Turbo 2 1998,
Kapazitäten von 840 GB bis 1.680 GB Arrays 13+2+1 RAID6 oder 2 x (5+2+1),
Array Kapazität bis 420 GB, Minimalkonfiguration: 2 Arrays, Maximalkonfiguration:
4 Arrays
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Waren Spuren auf den Platten wegzuschreiben, suchte sich
die Kontrolleinheit den Platz auf beliebigen Platten in den
verfügbaren Arrays. Die veralteten Spuren wurden in einem
Space­Reclamation­Prozess wieder einfach zum Überschreiben
freigegeben. Das Ganze wurde über Pointertabellen verwaltet
und die Pointer einer aktuellen geänderten Datei wurden
einfach entsprechend angepasst. Diese neue Log­Structured­
File­Architektur als wirklich erste virtuelle Plattenarchitektur
auf dem Markt erlaubte auch das sekundenschnelle Kopieren
von einzelnen Dateien oder Volumes, ohne dass für die Kopie
zusätzlicher Platz vorgehalten werden musste. Nur die Veränderungen
in Form von neuen Spuren oder Spur­Updates
benötigten wieder neuen Platz. Dabei legte das System entsprechende
Kopier­Pointers an, die auf einzelner Spurbasis
mit den originalen Pointers übereinstimmten. Diese Funktion
wurde als ‘SnapShot’ bezeichnet. Durch dieses Prinzip konnte
die RVA von der Plattenbelegung im Vergleich zu herkömmlichen
Plattensystemen wesentlich höher genutzt werden. Beim
RAMAC Virtual Array wurden im Backend IBM SSA­Platten
eingesetzt und das System konnte mit 4,5­GB­, 9­GB­ und
später mit 18­GB­SSA­Platten konfiguriert werden.
Das zweite Produkt aus der StorageTek­Reihe, die IBM RSA
(RAMAC Skalierbares Array) entsprach den herkömmlichen
Subsystemarchitekturen, konnte aber bereits 1996 in relativ
kleinen skalierbaren Schritten auf 1,4 TB ausgebaut werden.
Das System wurde aber relativ kurzfristig kapazitiv von der
RVA in der Turbo­ und Turbo­2­Version überholt und zeigte
nur eine sehr geringe Marktdurchdringung.
Plattensysteme für Open Systems
Während sich IBM in den 90er­Jahren bei der Magnetplatten­
Subsystementwicklung im Mainframebereich vornehmlich auf
die RAMAC­Reihe konzentrierte, liefen parallel neue Architekturentwicklungen
für Plattensubsysteme im Open­Systems­
Bereich. Bis Ende der 90er­Jahre gab es kein Plattensystem,
das Server aus dem Open­Systems­Bereich (AIX und andere
UNIX­Derivate und die Intel­Plattformen) und den Mainframe
mit seinem MVS­Betriebssystem gleichzeitig bedienen konnte.
Auf der Open­Systems­Seite ging IBM andere Wege. Beginnend
in den 90er­Jahren wurde im IBM Labor in Hursley in
England eine neue, Open­Systems­gerechte Plattenarchitektur
entwickelt, die unter dem Namen SSA für viele Jahre zur
Anwendung kommen sollte. SSA stand für Serial Storage
Architecture, eine Architektur, die die Limitierungen der bisher
an Open­Systems­Server angeschlossene SCSI­Platten­
IBM 7133 Plattensubsystem, SSA-Architektur mit SCSI-Host-Anschlüssen,
Modell T40 ‘Deskside’ Entry, Modell D40 ‘Rackmountable Disk System’
Plattenart Kapazitäten von/bis
18,2 GB 72,8 – 291,2 GB
36,4 GB 145,6 – 582,4 GB
72,8 GB 291,2 GB – 1,16 TB
146,8 GB 587,2 GB – 2,34 TB
systeme (Small Computer Systems Interface) eliminierte. Bei
SSA wurde für die Anbindung von Plattenlaufwerken mit einer
Loop­Technik gearbeitet, die es zuließ, dass man in die Loop
über neu entwickelte Adapter gleichzeitig zwei Schreib­ und
zwei Lese­I/Os absetzen konnte und alle Laufwerke in der
Loop gleichberechtigt bedient wurden. Die bekannte Arbitrierung,
wie es bei SCSI­basierenden Laufwerksträngen der
Fall war, fiel weg. Bei einem SCSI­Laufwerkstrang musste
immer ein I/O fertig abgehandelt werden, bevor der nächste
starten konnte. Zudem wurden Laufwerke, die ganz am Ende
des SCSI­Strangs angeschlossen waren, in der Bedienung
benachteiligt. Ein SCSI­Strang hatte die Limitierung, dass
maximal 15 Laufwerke angeschlossen werden konnten. Diese
Limitierungen überwand die neue SSA­Architektur, die 1992
erstmals in Subsystemen zum Einsatz kam.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
41

42
1994 bis 1998
Die Epoche der RAID-Systeme
Das bekannteste System war das IBM 7133 Serial Storage
Architecture Disk Subsystem, das an RISC Systeme/6000,
Power Servers und Power Stations angeschlossen werden
konnte und immer mit den neusten 3 ½­Zoll­Laufwerken ausgestattet
war. Das IBM 7133 Subsystem wurde im Juli 1995
mit sofortiger Verfügbarkeit angekündigt. Es war eines der
erfolgreichsten Plattensysteme im AIX­Umfeld und wurde
direkt über den AIX­Verkaufskanal vertrieben. Während des
Lebenszyklus der 7133 wurden über 42.000 Plattensysteme
weltweit in Produktion genommen, ein einzigartiger Verkaufserfolg.
Die letzten Systeme in SSA­Architektur (IBM 7133 Modelle T40
und D40) blieben bis 2003 im aktiven IBM Vertrieb und konn­
ten damals über Gateways an bestehende FibreChannel­
Infrastrukturen (SANs, Storage Area Networks) angeschlos sen
werden.
1999 kündigte die IBM für den Mainframe wieder ein eigenes,
selbst entwickeltes Plattensubsystem unter dem Namen IBM
ESS (Enterprise Storage Server) an, das allerdings mehr
unter dem Entwicklungsnamen ‘Shark’ bekannt wurde und
letztendlich die RVA und RSA im IBM Vertrieb ablöste. StorageTek
vertrieb danach wieder selbst die RVA unter dem
Namen STK Shared Virtual Array. Die ESS war nicht nur ein
Plattensystem für den Mainframe, sondern konnte auch an
alle gängigen Open­Systems­Plattformen angeschlossen
werden. Damit war die Voraussetzung geschaffen, mit einem
Plattensubsystem sowohl den Mainframe als auch Open­
Systems­Server zu bedienen, wie es auf der Bandarchivseite
bereits seit Jahren möglich war. Über die Folgejahre löste
die ESS dann auch im Open­Systems­Bereich teilweise
das IBM 7133 Serial Disk System ab. Parallel dazu wurden
FibreChannel­basierende Plattensysteme für die Open­
Systems­Plattformen eingeführt.
Bandsysteme
Neben der Plattensubsystementwicklung in den 90er­Jahren
führte IBM eine neue Bandlaufwerktechnologie als Ablösung
der bis dahin verwendeten 3490 Technologie ein, die
IBM 3590, die unter dem Namen Magstar bekannt wurde.
Das erste Laufwerk der Magstar 3590 war das Modell B, das
auf einer ½­Zoll­Kassette eine native Kapazität von 10 GB
aufzeichnete. Das 3590­B Laufwerk wurde im April 1995 angekündigt
und war im September des gleichen Jahres verfügbar.
Bei dieser neuen Aufzeichnung wurden zum ersten
Blick in die IBM 3590 Magstar Laufwerke
Mal in der Bandtechnologie magnetoresistive Schreib­/Leseköpfe
mit dem ‘Track Following Servo’­Prinzip eingesetzt, wo
die Leseelemente konstant kontrollieren, wie gut die Bits vom
Schreibkopf geschrieben wurden. Die Kassetten wurden mit
128 Spuren vollgeschrieben und die Datenrate des Modells
B der 3590 betrug damals faszinierende 9 MB pro Sekunde
(native).
Die Laufwerke waren als Stand­alone­Version, also fest eingebaut
in einem Gehäuse mit entsprechenden Autoloadern,
zu bekommen, sie wurden aber genauso in der aktuellen Tape
Library IBM 3494 eingesetzt. Voll ausgebaut konnte die IBM
3494 mit 3590­B Laufwerken eine Kapazität von 180 TB
(native) abbilden. Die Laufwerke selbst hatten zwei SCSI­
Schnittstellen und konnten entweder direkt an Open­Systems­
Server angeschlossen werden oder über eine Kontrolleinheit
an ESCON­basierende Mainframe­Server.
Die Magstar­Entwicklungsreihe wurde dann 1999 mit dem
neuen E-Modell erweitert, das mit 256 Spuren die doppelte
Spurzahl aufwies und eine Kapazität von 20 GB auf den Kas­
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

IBM 3590 Magstar Tape Subsystem
1995: IBM 3590-B mit 9 MB/S Datenrate
1999: IBM 3590-E mit 14 MB/S Datenrate
2002: IBM 3590-H mit 14 MB/S Datenrate
Kassettenkapazitäten (native):
Modell normale Kassette lange Kassette
3590-B 10 GB 20 GB
3590-E 20 GB 40 GB
3590-H 30 GB 60 GB
setten speicherte (native ohne Komprimierung). Die Datenrate
wurde von 9 MB/s auf 14 MB/s gesteigert. Parallel dazu
brachte IBM eine neue Kassette, die 3590 ‘Extended Length
Cartridge’, die mit der doppelten Bandlänge (beschrieben
mit 3590E) auch die doppelte Kapazität, nämlich 40 GB,
abbildete. Damit erhöhten sich die 3494 Library­Kapazitäten
auf 374 TB bei Verwendung der normalen Kassette und bis
748 TB bei der langen Kassette. Die Magstar­Entwicklungsreihe
war ab Mai 1999 verfügbar.
Das Modell E der Magstar­Baureihe besaß einen leistungs­
fähigen Controller, der neben der Aufzeichnung von Datenblöcken
auch Parity-Blöcke aufzeichnete, um ein wesentlich
höheres Error Recovery zu ermöglichen. (Bei der Aufzeichnung
von 16 Spuren gleichzeitig wurde nach 7 Datenblöcken
in der achten und nach weiteren 7 Datenblöcken in der
16. Spur ein Parity­Block mitgeschrieben und über das
logische Spurset von acht Spuren ‘gestriped’ – RAID5
auf Band.)
Was Magstar in Sachen Recovery zu leisten vermag, zeigt
ein Versuch mit dem Magstar E­Modell, der im Juni 1999
und im Juli 2000 im IBM Labor in Tucson, Arizona, durchgeführt
wurde. Zu dem Versuch wurden alle maßgeblichen
Consultants wie Gartner Group und IDC eingeladen. Man
hat mit dem E­Modell eine Kassette mit 256 Spuren voll
beschrieben und ein sauberes Read Verify erhalten. Dann
wurde die Kassette aus dem Laufwerk entladen. In die Mitte
des Bandes wurde dann ein 1,25 mm großes Loch gestanzt.
Dieses Loch spiegelte ca.100.000 Bits wieder, die dann fehlten.
Die Kassette mit dem Loch wurde wieder ins Laufwerk
geladen und die Leseoperation wurde erfolgreich ohne Fehler
durchgeführt. Alle fehlenden Datenbits konnten durch den
ECC (Error Correction Code) über die Bitblock­Verteilung
und die Parity­Bit­Blöcke ‘recovered’ werden. Das war zu
dieser Zeit mit Sicherheit mit keiner anderen Bandlaufwerkstechnologie
durchführbar!
Das Laufwerk hatte zwei SCSI­Schnittstellen. Ab Mai 2000
waren die Magstar­Laufwerke auch mit zwei FibreChannel­
Schnittstellen verfügbar. Damit konnten die Laufwerke direkt
an ein FibreChannel­basierendes SAN­Netzwerk angeschlossen
werden. Etwas zeitversetzt kamen auch die entsprechenden
Controller auf den Markt, welche den Anschluss der
Laufwerke auch an FICON­basierende Mainframe­Rechner
ermöglichten.
Lochstanzversuch mit Magstar 3590 Bändern 1999 und 2000 im IBM Labor in
Tucson
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
43

44
1994 bis 1998
Die Epoche der RAID-Systeme
Das letzte Modell der 3590 Magstar­Reihe kam im Jahr 2002
mit dem 3590 Modell H, das auf denselben Kassetten 384
Spuren aufzeichnete und so die Kassettenkapazitäten um
50 % steigerte. Das Modell H wurde am 25. Juni 2002 angekündigt
und war bereits am 28. Juni 2002 verfügbar. Die
Datenrate der 3590­H blieb auf dem Stand des Vorgängers
3590­E, bei 14 MB pro Sekunde. Die 3494 Library­Kassettenkapazitäten
erreichten jetzt 1 Petabyte native Kapazität in
der vollen Ausbaustufe (ohne Kompression).
Im September 1996 wurde von IBM ein neues Kassetten-
bandsystem vorgestellt, das neben hoher Streaminggeschwindigkeit
extrem schnelle Zugriffszeiten realisierte. Die
IBM Magstar MP 3570 bot eine Datentransferrate von 15 MB
pro Sekunde und Zugriffszeiten von nur wenigen Sekunden.
Dies wurde mit einem besonderen Kassettendesign ermöglicht,
wo die Grundstellung des Bandes in einem Zwei­Spulen­
Design in der Mittenstellung lag. So konnte beim Laden des
Bandes sowohl nach links als auch nach rechts gespult werden,
um schnell an eine File zu gelangen. Diese neue Konzeption
allerdings ermöglichte nur kleine Kassettenkapazitäten
von 5 MB und später 10 MB, die vom Markt nicht in der breiten
Akzeptanz angenommen wurde, wie man es ursprünglich gedacht
hatte. Deshalb war der Lebenszyklus der Magstar MP
auch nur von kurzer Dauer und auf etwa 3 Jahre beschränkt.
Mit der Verfügbarkeit der ersten Magstar­Modelle 3590-B 1995
ergab sich im Mainframe­Umfeld eine neue Problemstellung,
denn die jetzt hohen Kassettenkapazitäten von 10 GB native
und die hohen Datenraten von 9 MB/s native wurden nur zu
einem kleinen Teil genutzt. Eine weltweite Studie ergab, dass
der Nutzgrad im Mainframe­Umfeld bei etwa 200­300 MB pro
Kassette lag und die Datenraten bei durchschnittlich 2­3 MB/s
lagen und bei vielen Backup­Jobs sogar unter 1 MB/s. Um
IBM Magstar MP 3570 Bandsubsystem
dieses Problem zu beheben, fing IBM an, Tape-Virtualisierungslösungen
für den Mainframe­Bereich zu entwickeln, um
die dahinter angeschlossene physikalische Ressource sowohl
in der Kapazität der Kassetten als auch in der Datenrate von
Laufwerken maximal nutzen zu können. Aus einer anfänglichen
Software­basierenden Volume­Stacking­Lösung entstand der
3494 Virtual Tape Server VTS, der im Juni 1997 mit dem
ersten Modell B16 auf den Markt kam. Dabei wurden die
Tape Volumes, die es zu sichern galt, auf einem Plattenpuffer
zwischengespeichert und dabei indexiert. Sobald so viele
Volumes in den Plattenpuffer geschrieben waren, dass sie
eine 3590 Kassette füllen konnten, wurde eine Kopie der
gesamten Ansammlung von Platten auf die schnellen Laufwerke
geschrieben (Premigration) und dabei die Kassetten
maximal aufgefüllt (Stacked Volume Prinzip). Das Original
verblieb im Plattenpuffer. Dadurch konnte der Nutzgrad der
Kassettenkapazitäten und der Laufwerkgeschwindigkeiten
maximiert werden. Recalls von Volumes, die noch im Plattenpuffer
standen, wurden in Plattengeschwindigkeit durchgeführt
und beim Backup konnten viele Jobs parallel angestoßen
werden, da viele virtuelle Laufwerke zur Verfügung standen.
IBM implementierte eine sogenannte ‘Outboard’­Lösung, die
völlig transparent zum Host und dem MVS­Betriebssystem
war und dieselbe Transparenz gegenüber dem Bandverwaltungssystem
und dem Katalogeintrag zeigte. Emuliert wurden
3490E Laufwerke mit Kassettenkapazitäten von 400 bzw.
800 MB und der Host registrierte gar nicht, dass er keine
physischen Laufwerke im Zugriff hatte.
Der erste Virtual Tape Server IBM 3494 B16 war damals direkt
als Gehäuseeinheit in das 3494 Bandarchiv integriert. Das
B16­Gehäuse beherbergte den RS/6000 Server, einen RAID­
5­abgesicherten Plattencache mit SSA­Platten, der bis auf
72 GB ausgebaut werden konnte, sowie die für den Host notwendigen
ESCON­Anschlüsse und 400 Kassettenstellplätze.
Später arbeitete man mit externen Einheiten, wie die Weiterentwicklung
dieses Konzepts zeigt. Virtuelle Tape­Lösungen
sind in unserer heutigen Zeit nicht mehr wegzudenken, weil
es die einzige Möglichkeit ist, über diesen Weg Tape­ und
Tape­Library­Ressourcen maximal zu nutzen.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Das Prinzip, den VTS (Virtual Tape Server) direkt in das 3494
Bandarchiv zu integrieren, erwies sich als äußerst ungünstig.
Zudem war die Durchsatzstärke der damaligen B16 sehr
klein und erreichte nur 6­8 MB/s, weil ohne Kompression
gearbeitet wurde. Deshalb kündigte die IBM bereits ein Jahr
später, im Juni 1998, mit einer Verfügbarkeit im August 1998,
ein neues externes Modell B18 an, das als separate Einheit
neben der 3494 Library betrieben werden konnte. Diese neue
Einheit bot Kompression an, die direkt in den Host­Adaptern,
damals auf ESCON­Basis, durchgeführt wurde. Das hatte den
Vorteil, dass alle Daten im Plattenpuffer bereits komprimiert
waren und der Nutzgrad im Plattenpuffer durchschnittlich
um Faktor 3 vergrößert wurde. Durch den Einsatz von SSA­
Laufwerken mit 9 und 18 GB Kapazität wurde die Plattenpuffergröße
auf 288 GB und 576 GB gesteigert. Später wurden
mit 36­GB­SSA­Files Plattenpuffer von bis zu 5,2 TB (nutzbar)
möglich. Dadurch wurde die Verweilzeit der Volumes im
Plattenpuffer um ein Vielfaches vergrößert und Recalls direkt
vom Plattenpuffer als virtuelle Mounts in Plattengeschwindigkeit
durchgeführt. Die damaligen B18­Einheiten erreichten, je
nach Ausbaustufe, Durchsatzmöglichkeiten von 30 bis 40 MB/s.
Viele andere Firmen sprangen sehr schnell auf diesen Geschäftszug
auf und es wurde eine ganze Reihe von Bandvirtualisierungslösungen,
HW­basierend, aber auch reine
SW­Stacking­Lösungen auf dem Markt verfügbar. Viele verschwanden
aber wieder sehr schnell vom Markt.
Das Modell B18 wurde in den Folgejahren funktional erweitert.
Import­/Export­Möglichkeiten von logischen Volumes waren
möglich. Mit der Einführung von Folgemodellen im August
2001, der Modelle B10 und B20, wurden neben den ESCON­
Anschlüssen auch FICON­Anschlüsse verfügbar und eine
große Palette von neuen Funktionen kam zum Einsatz, die
IBM Virtual Tape Server VTS, 1997: Modell B16, 1998: Modell B18,
2001: Modell B10 und B20
auch noch für das alte Modell B18 in eingeschränkter Form
zur Verfügung stand.
Diese neuen Erweiterungen, als ‘Advanced Function’ bezeich­
net, erlaubten über ein APM (Advanced Policy Manage-
ment) neue Funktionalitäten am IBM VTS. Sie sind bis heute
aktiv im Einsatz und bilden die Verzahnung mit SMS
(System Managed Storage) als integralem Bestandteil des
z/OS­Betriebssystems.
Die Funktionalität ‘Logical Volume Pool Assignment’ bietet
die Möglichkeit, logische Volumes einzeln pro Nummernkreis
in unterschiedlichen physischen Kassetten­Pools zu verwalten.
Damit wurde der IBM VTS mandantenfähig. Mit ‘Selective
Dual Copy’ können zwei Kopien eines logischen Volumes in
zwei unterschiedlichen physischen Kassettenpools erzeugt
werden. Die Funktion ‘Peer to Peer Copy Control’ adressiert
einen PtP­VTS­Komplex und erlaubt die Steuerung, welche
logischen Volumes in einem PtP­Komplex im Immediate Copy
Mode und welche logischen Volumes im Deferred Copy Mode
gespiegelt werden.
Mit ‘Tape Volume Cache Management’ (diese Funktion war
bereits vorher verfügbar, allerdings Host­gesteuert) können
logische Volumes einer Cache Management Preference Group
zugeordnet werden. Es stehen zwei Preference Groups zur
Verfügung. Die Preference Group steuert, wie die logischen
Volumes im Plattenpuffer behandelt werden.
Die wohl wichtigste Einführung im August 2000 war aber das
Prinzip der Spiegelung von ganzen VTS-Systemen, die
auch heute noch als Peer to Peer VTS bezeichnet wird und
sich im Markt, vor allem bei Banken und Versicherungskunden,
schnell durchsetzte. Dabei bietet ein Peer­to­Peer­VTS­Komplex
synchrone Spiegelmöglichkeit und eine asynchrone
Spiegelung an. Über eine weitere Funktion, die 2004 eingeführt
wurde (Selective Peer to Peer Copy), können auch
einzelne Volumes oder ganze Storage­Gruppen sowohl
gespiegelt als auch ungespiegelt in einem VTS­Peer­to­
Peer­Spiegelkomplex verwaltet werden.
Die VTS­Geschichte, die 1997 begann, war für die IBM vor
allem im Mainframe­Umfeld eine einzigartige Erfolgsgeschichte
und IBM entschloss sich, diese Erfolgsgeschichte mit neuen
Systemen und neuen Funktionalitäten über die folgenden
Jahre fortzusetzen.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
45

46
1994 bis 1998
Die Epoche der RAID-Systeme
Linear Tape Open LTO Ultrium
In der ersten Hälfte der 90er-Jahre hatte sich im
Open­Systems­Umfeld vor allem im Mittelstandsbereich und
bei kleineren Betrieben eine Tape-Technologie durchgesetzt,
die diesen Markt beherrschte: DLT (Digital Linear Tape), eine
günstige Alternative zur High­End­½­Zoll­Technologie, die für
kleine Unternehmen bezahlbar war und bis Mitte 1995 eine
Marktdurchdringung von 90 % hatte. DLT­Hersteller und ­Anbieter
war Quantum. Der kleinere Teil des Marktes ging an
Helical­Scan­basierende Technologien und die QIC(Quarter
Inch Cartridge)­ und Mini­QIC­Technologien.
Mit dem Zusammenschluss der Firmen IBM, HP und Sea-
gate in einem neuen Tape­Entwicklungsgremium, dem
sogenannten LTO(Linear Tape Open)­Gremium, wurde eine
Initiative gestartet, dem dominierenden umd marktbeherrschenden
DLT von Quantum eine Alternative entgegenzusetzen.
Das LTO­Entwicklungsgremium fing 1996 mit seiner
Arbeit an.
Die Spezifikationen von LTO wurden von 1997 bis 1999 ent­
wickelt, um als erster Bandtechnologie-Standard auf den
Markt zu kommen und den damals herrschenden Wildwuchs
an unterschiedlichen Technologien und Medien zu stoppen.
LTO ist sowohl von der Technologie als auch vom Medium
ein offizieller ISO­Standard, der es erlaubt, LTO­Medien, unabhängig
von welchem Hersteller, auf jedem LTO­Laufwerk,
auch unabhängig von welchem Hersteller, zu verarbeiten.
Heute haben über 30 Firmen die Fertigungslizenzen von LTO
erworben. Hinzu kommen zusätzlich die OEM­Abkommen, die
die Entwicklungsfirmen IBM, HP und Seagate eingegangen
waren. LTO hatte also eine große Chance, sich langfristig
gegenüber DLT auf dem Markt durchzusetzen.
LTO1 Laufwerk mit LTO1 Ultrium Kassette
Wenn man heute, 2010, die Marktanteile betrachtet, ging
diese Rechnung auf. DLT ist heute nahezu vom Markt verschwunden.
Als die LTO Group 1997 anfing, die Spezifikationen für die
Standardisierung zu entwickeln, hatte sie zuerst alle vorhandenen
Bandtechnologien auf ihre Plus­ und Minus­Punkte
bewertet, um das Gute in LTO miteinzuarbeiten und das
Negative auszulassen. Schluss mit dem Wildwuchs, Kompatibilität
war gefragt! Ob Sony AIT oder 4 mm, 8 mm Helical
Scan Technologie von Exabyte, Quantums DLT bis hin zum
Super DLT, Philipps NCTP, Quarter Inch Cartridge oder Mini
Quarter Inch Cartridge: alles Technologien, die keine Kompatibilität
vorwiesen und daher Schwierigkeiten hatten, sich
weiter dauerhaft auf dem Markt zu behaupten!
Bei der Aufzeichnungstechnik entschied man sich aufgrund
der hohen Zuverlässigkeit für die IBM Magstar­Lineare­Serpentinen­Aufzeichnung,
mit der das Band bei einer Datenrate
von 15 MB/s mit 384 Spuren (LTO1) und 35 MB/s mit
512 Spuren (LTO2) beschrieben wird. Dabei wurden immer
acht Spuren gleichzeitig geschrieben. Die Kassetten erreichten
bei diesen Spurdichten native Kapazitäten von 100 GB (LTO1)
und 200 GB (LTO2). Bei dieser hohen Spudichte war es notwendig,
eine möglichst exakte Führung der Schreib­/Lese­
Elemente sicherzustellen.
Zu diesem Zweck wurde ein neues, zeitbasierendes Spur-
nachführungssystem verwendet, das mit fünf vorgeschriebenen
Servobändern mit jeweils acht Servobereichen arbeitete.
Von der AIT(Advanced Intelligent Tape)­Technik von
Sony wurde das in der Kassette integrierte Memory Chip
übernommen, allerdings mit größerer Speicherkapazität (4 KB).
Kassettenladevorgang beim IBM LTO1 Laufwerk
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

IBM Autoloader und Library-Angebot mit LTO-Laufwerken, Ende 2000, links IBM 3584 Library, rechts unten IBM 3583 Library, darüber
der Autolaoder IBM 3581 und das LTO Stand Alone Laufwerk IBM 3580
Dort wird das festgehalten, was z. B. bei Magstar in der Tape­
Volume­Control­Region auf Band gespeichert wird: Hersteller­
angaben als Read­Only­Information, das Inhaltsverzeichnis
des Bandes und Angaben wie viele Schreib­/Lesefehler auf
dem Band vorkommen, um aus Sicherheitsgründen bei einem
bestimmten Schwellwert die Kassette auf ‘Read Only’­Status
zu setzen. Ebenso war Platz für anwenderspezifische Informationen
vorgesehen. Neben der Speicherung auf dem Chip
wurden aus Sicherheitsgründen alle Informationen auch in
der Tape­Volume­Control­Region des Bandes abgespeichert.
Passend zur LTO­Laufwerkentwicklung entwickelte IBM ein
neues Library-Konzept, das mit einem Greifersystem arbeitet
(bis heute), das die Features der standardisierten LTO­
Kassetten optimal handhaben konnte. Das Robotersystem
mit diesem Spezialgreifer wurde Ende 2000 mit der neuen
IBM 3584 Library realisiert. Die IBM 3584, zum damaligen
Zeitpunkt auschließlich an Open Systems betreibbar, stellte
das passende Gegenstück zur IBM 3494 Library dar, allerdings
mit wesentlich moderneren Möglichkeiten und einer
Robotergeschwindigkeit, die bis heute unerreicht ist.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
47

48
1994 bis 1998
Die Epoche der RAID-Systeme
Mit der Einführung der LTO­Bandtechnologie auf dem Markt
änderte die IBM ihr bisher verfolgtes Konzept, alles selbst
herzustellen. In dem damals bereits hart umkämpften Open­
Systems­Markt als Einzelhersteller zu bestehen, der alle Arten
von Lösungsformen abbildet und fertigungstechnisch baut,
war unmöglich. Deshalb schloss IBM bereits 1999 mit der
Firma ADIC ein OEM­Abkommen, das so aussah, dass
ADIC LTO­Laufwerke von IBM bekam und im Gegenzug IBM
die kleinen Libraries von ADIC, die dann unter IBM Logo mit
IBM LTO­Laufwerken vermarktet wurden.
So stellte ADIC die damaligen ‘Midrange Libraries’, die IBM
3583 und später die IBM 3582 (bei ADIC Skalar 100 und
Skalar 24), zur Verfügung. Der einzige Unterschied zu den
ADIC­Produkten war, dass IBM in beide Libraries eine eigene
FibreChannel­basierende Steuereinheit integrierte, um den
Libraries über die dadurch geschaffene Multipfad architektur
die Möglichkeit zu geben, logische Partitionen als Sub­Libraries
anzulegen und um direkt FibreChannel­LTO­Laufwerke
einzubauen. ADIC verwendete SCSI­Laufwerke, die
dann über ein Gateway an SANs anschließbar waren. FC­
Laufwerke wurden bei ADIC erst Anfang 2005 verwendet
und eingebaut.
Die heute aktuellen Autoloader, Midrange Libraries und die
Besonderheiten des 3584 Bandarchivs sind in der Folgeepoche
näher beschrieben.
IBM 3582 Display – Mini-Library mit bis zu 23 LTO-Kassetten
IBM 3583 Ultrium Scalable Tape Library mit geöffneter Tür
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Kommentar zur Epoche der RAID-Systeme
Im Vergleich zur Vorgängerepoche, wo über Jahre dieselben
Steuereinheiten und Platten aktuell blieben, war die Epoche
der RAID­Systeme mit sehr schnellen Entwicklungszyklen
sehr hektisch. RAMAC 1, 2 und 3 kamen hintereinander im
Abstand von nur einem Jahr.
In dieser Epoche herrschte ein enormer Preisdruck, der durch
neue Mitbewerber und Player im Plattenumfeld hervorgerufen
wurde.
RAMAC 3 war der letzte ‘Rolls Royce’, den die IBM baute,
dann liefen die Kosten davon und die Produkte waren viel zu
teuer im Vergleich zum Mitbewerb. Das führte zum Zusammenschluss
von StorageTek und IBM und zum IBM Vertrieb
des RAMAC Virtual Arrays (ehemals STK Iceberg). Plötzlich
musste der IBM Vertrieb ein Produkt verkaufen, von dem man
sich bisher immer distanziert hatte. Ein massives Umdenken
war im Speichervertrieb angesagt. Log Structured File, die
bisher von IBM negativ kommentierte ‘Garbage Collection –
das kann doch nichts sein’ musste nun positiv dargestellt
werden. Die Verbrüderung mit STK im Plattenumfeld musste
erst einmal verdaut werden.
Im Open­Systems­Bereich glichen die erfolgreiche Einführung
der SSA­Architektur und der erfolgreiche Verkauf des Plattensystems
IBM 7133 den Einbruch im Mainframe­Umfeld
entsprechend aus.
Ebenso hektisch waren die Entwicklungsjahre im Tape­
Umfeld geprägt. Neben Magstar 3590, Magstar MP und der
Entwicklung des Virtual Tape Servers (VTS) wurde die
LTO(Linear Tape Open)­Bandtechnologie zusammen mit
Hewlett­Packard und Seagate entwickelt und spezifiziert. Im
Herbst 1999 war der Standard der LTO1­Technologie fertig.
Danach begann ein Prestige­Wettrennen zwischen IBM, HP
und Seagate. Jeder wollte der Erste sein, der mit LTO1­
Laufwerken auf den Markt kommt.
Seagate kündigte als erste Firma, bereits im Frühjahr 2000,
ihre LTO1­Laufwerke an. Die Seagate­Laufwerke wurden aber
dann doch als letzte verfügbar. IBM kündigte im September
2000 mit sofortiger Verfügbarkeit an. HP folgte mit Ankündigung
und Verfügbarkeit einen Monat später.
Die Epoche war geprägt durch Vertriebskämpfe vieler Mitbewerber
im Platten­ und Tape­Umfeld und war deshalb so
hektisch, weil enorme Preis­ und Prestigekämpfe stattfanden.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
49

50
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Die Epoche der Multiplattform-Systeme und
des FibreChannel SAN und NAS
1999 bis 2005
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
51

52
1999 bis 2005
Die Epoche der Multiplattform-Systeme und des FibreChannel SAN und NAS
1999 – 2006: IBM SAN, Switches und Direktoren der Hersteller Brocade, McData (CNT) und Cisco
SAN, NAS, iSCSI
Die Epoche der RAID­Systeme war bis 1999 so gestaltet, dass
Plattensysteme für den Mainframe­Bereich zur Verfügung
standen, während der Open­Systems­Bereich eigene, damals
direkt angeschlossene Plattensysteme verwendete. Nur Tape
Libraries waren in der Lage, beide Welten zu unterstützen.
Das Datenwachstum in dieser Zeit war dramatisch, oft über
60 % pro Jahr für Rechenzentrumsbetriebe. Die IP­Netze und
die damit verbundene Infrastruktur, damals Ethernet auf
10­Mbit­Basis, erlaubten kaum, riesige Datenmengen über
IP­Infrastrukturen hin und her zu bewegen. Der Ruf nach
separaten Speichernetzwerk-Infrastrukturen wurde immer
lauter, um der Datenflut entgegenzuwirken. 1998 kamen
von der Firma Brocade die ersten FibreChannel­Switches
auf 8­Port­Basis mit 1­Gbit­Ports auf den Markt. Eine neue
Infrastruktur, das SAN (Storage Area Network) auf
FibreChannel­Basis, sollte in den kommenden Jahren eine
wahre Blütezeit erleben.
Die Anfänge der ersten SAN-Infrastrukturen fanden allerdings
schon 2 Jahre früher statt. Sie kamen bereits 1996
in Hochleistungsrechenzentren der Universitäten zum Einsatz
und wurden von der Firma Ancor zur Verfügung gestellt.
1998 wurde der erste 8­Port­Switch von der Firma Brocade
im kommerziellen Rechenzentrumsumfeld bei der IT Austria
in Wien eingesetzt und in den Folgejahren gingen viele Firmen
dazu über, in den unterschiedlichsten Unternehmensbereichen
SAN­Infrastrukturen zu implementieren. Nicht nur im Open­
Systems­Bereich erlebte die Glasfaser eine neue Blütezeit,
auch die Mainframe­Umgebungen wechselten, beginnend
mit dem Jahr 2001, von der bisherigen ESCON­Umgebung
(Enterprise Storage CONnection) mit den bis dahin verwendeten
ESCON­Direktoren auf Glasfasernetze, um zusammengefasste
ESCON­Pakete über die Glasfaser zu übertragen.
Das Ganze wird heute als FICON bezeichnet (Fibre CONnection).
Dadurch konnten die hohen Übertragungsraten
der Monomode­Glasfaser mit entsprechenden Multiplexingverfahren
auch im Mainframe­Bereich genutzt werden.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Bereits im Jahr 2003 waren Direktoren auf dem Markt, die
sowohl FibreChannel­ als auch FICON­Ports abbilden konnten.
Leider kann bis heute noch kein FC­Port als FICON­Port
oder umgekehrt genutzt werden und es wird sicherlich noch
einige Zeit dauern, bis SAN­basierende Infrastrukturen
sowohl von der Open­Systems­Umgebung als auch von den
Mainframes gleichzeitig genutzt werden können. Die Fibre­
Channel SANs entwickelten sich rasch weiter. 2002 kamen
die ersten Switches mit 2-Gbit-Ports auf den Markt. Im
Jahr 2006 waren alle Hersteller im Begriff, von 2­Gbit­ auf
4­Gbit­Technologie umzustellen, und bis Ende 2006 war die
Umstellung soweit, dass ‘End to End’­SAN­Implementierungen
auf 4­Gbit­Basis realisiert werden konnten. Sowohl
die Host­Adapter aller Server­Hersteller als auch die Host­
Ports aller Storage­Anbieter waren auf 4­Gbit­Technologie
umgestellt. Heute, im Jahr 2008, wiederholt sich dieses
Spiel nur auf 8­Gbit­Technologie­Basis. Seit Anfang 2008
sind die ersten 8­Gbit­fähigen Direktoren auf den Markt
gekommen.
In der Anfangszeit dieser Epoche waren SAN-Implementie-
rungen sehr kostenintensiv. Nicht jede Firma, vor allem im
Mittelstandsbereich, konnte sich SANs finanziell leisten, um
der neuen Bandbreitenmöglichkeit Rechnung zu tragen. Hinzu
kam die Hochpreispolitik der Glasfaserhersteller, die vor allem
die für das Multiplexing erforderliche Monomode­Faser über
die Anfangsjahre sehr teuer gestaltete. Die Server­Adapter­
Hersteller schlossen sich dieser Hochpreispolitik an. Das
führte dazu, dass die Entwickler von Multiplexing­Verfahren
auf der Glasfaser kein großes Umsatzpotenzial mehr erkennen
konnten und sich deshalb neuen Multiplexing­Verfahren
auf Ethernet­Basis zuwandten. So kommt es, dass heute IP­
Infrastrukturen auf Ethernet­Basis wesentlich größere Übertragungsbandbreiten
bieten (2­Gbit­ und 10­Gbit­Ethernet)
im Vergleich zu FibreChannel­Netzen.
Die Hochpreispolitik führte auch dazu, dass neben dem
SAN eine neue Technologie, das NAS (Networking Attached
Storage), Einzug hielt. NAS­Technologie in Form von File­
Server­Geräten mit eingebauten Platten kam ebenso zum
Einsatz wie Gateways, die prinzipiell nichts anderes als einen
File­Server darstellten, aber die Möglichkeiten hatten, Plattenkapazitäten
innerhalb eines SANs für File­Serving­Zwecke
zu nutzen.
Heute sind SANs selbst für sehr kleine Betriebe bezahlbar.
Der Preisverfall von 2003 bis 2006 liegt in einem Bereich von
nahezu 96 %. Dieser Preisverfall wurde maßgeblich durch die
neuen Bandbreitenmöglichkeiten der IP­Netze auf Ethernet­
Basis erzielt und stellt durchaus, vor allem heute (10­Gbit­
Ethernet), die Notwendigkeit von SANs infrage, wenn es um
Engpässe in der Datenübertragungsmöglichkeit geht. Trotzdem,
vor allem aufgrund der Managementmöglichkeiten, ist
davon auszugehen, dass SAN­Netze von 4 Gbit in Richtung
8 Gbit (oder 12 Gbit) weiterentwickelt werden, die zu den
bestehenden Netzen (Autosensing) kompatibel bleiben.
Neben den Möglichkeiten und Vorteilen von SANs bot IBM
in den Jahren 2000 bis 2004 auch Lösungen und Produkte
auf dem Sektor Networking Attached Storage (NAS) an.
NAS­Systeme sind vorkonfigurierte Fileserver. Sie bestehen
bis heute aus einem oder mehreren internen Servern mit vorkonfigurierter
Plattenkapazität und werden über Ethernet an
das LAN angeschlossen, wo sie ihren Plattenspeicher als
Fileserver oder als HTTP­Server zur Verfügung stellen. NAS­
Server sind speziell für das File Sharing entwickelt. Der Vorteil
von NAS im Vergleich zu klassischen Fileservern bestand
im geringen Installations­ und Wartungsaufwand.
Die IBM NAS­Modelle 200 und 300 waren Lösungen speziell
für Kunden, die in einem Windows­Umfeld Speicher konsolidieren
wollten. Alle IBM NAS Appliances wurden mit einem
vorkonfigurierten Microsoft­Windows­Betriebssystem ausgeliefert.
Dieses Windows wurde speziell für Fileserving angepasst.
Routinen, die überflüssig waren, wurden aus dem
Betriebssystem entfernt, um die Leistung und Zuverlässigkeit
zu erhöhen. Dadurch boten die IBM NAS­Modelle sehr
gute Performance in einer Windows­Umgebung (CIFS). Auch
in einem gemischten Windows­ und UNIX(NFS)­Umfeld zeigten
die IBM NAS­Modelle eine gute Leistung.
Für klassische Block­I/O­Anwendungen wie Datenbanken
waren solche Fileserver nicht vorgesehen, weil diese Anwendungen
direkt auf einen formatierten Plattenplatz ohne ein
darüberliegendes Filesystem zugreifen. Dafür waren Lösungen
wie Direct Attached Storage (DAS), Storage Area Networks
(SAN) und iSCSI­Produkte besser geeignet.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
53

54
1999 bis 2005
Die Epoche der Multiplattform-Systeme und des FibreChannel SAN und NAS
IBM NAS Gateway 500, verfügbar Februar 2004, pSeries-basierend,
bis 224 TB Kapazität im SAN
Um die Speicherressourcen im SAN für Fileserving zu nutzen,
bot die IBM, damals am Anfang als einziger Vendor, die Möglichkeit,
vorhandene IP­Netzwerkstrukturen über ein NAS
Gateway mit dem SAN zu verbinden. Das NAS Gateway war
ein dedizierter Fileserver. Dieser war mit dem SAN über Fibre­
Channel verbunden und so in der Lage, Kapazitäten z. B.
eines Enterprise Storage Servers ESS im SAN optimal für
Fileserving einzusetzen. Durch die Nutzbarmachung eines
SAN­Speicherpools über Gateways konnten Fileserver in ein
SAN konsolidiert werden. Ebenso wurde durch die Nutzung
des Speichers im SAN eine Server­unabhängige Skalierung
bezüglich der Kapazitäten möglich. Das NAS Gateway 300G
wurde später, im Jahr 2004, durch das wesentlich leistungsstärkere
Gateway 500 ersetzt.
iSCSI ist eine gemeinsame Entwicklung der Firmen IBM und
Cisco. Dabei wird das SCSI­Protokoll über TCP/IP übertragen.
iSCSI verfolgt damit einen ähnlichen Ansatz wie SAN, mit
dem Unterschied, dass bei iSCSI eine TCP/IP­Verbindung
das SCSI­Kabel ersetzt, und stellte damals in Bereichen mit
niedrigen oder mittleren Leistungsanforderungen eine kostengünstigere
Alternative zu SANs dar. Der Vorteil bestand darin,
dass bereits vorhandene IP­Netzwerke direkt genutzt werden
konnten und nicht ein separates Glasfasernetz in Form eines
SANs aufgebaut werden musste. Die Implementierung von
iSCSI­Lösungen im Vergleich zu SANs war wesentlich einfacher
und erforderte nicht den hohen IT­Skill, der bei einem
Aufbau eines Storage Area Network (SAN) notwendig war.
Die IBM Modelle IP Storage 200i (Modelle 200 und 225)
verwendeten im Gegensatz zu den NAS und NAS Gateways
Linux als Betriebssystem (Kernel) und boten eine Kapazität
von 108 GB bis 1,74 TB an.
Die iSCSI­Lösungen setzten sich allerdings auf dem Markt
nicht wirklich durch, zumal kurze Zeit später der enorme
Preisverfall der Monomode­Glasfaser einsetzte, der die Implementierung
von SANs auch im Mittelstand und für Kleinbetriebe
bezahlbar machte.
Plattensysteme
Im Juli 1999 wurde das erste IBM multiplattformfähige Plattensystem,
der Enterprise Storage Server ESS, angekündigt.
Unter dessen Entwicklungsname ‘Shark’ fand das System
allerdings weit mehr Verbreitung als unter dem Begriff ESS.
Die Typenbezeichnung war 2105 und die 1999 angekündigten
Modelle waren die E10 und E20 mit einer Kapazität von
420 GB bis 11,2 TB. Dabei wurden Plattenlaufwerke von 9 GB,
18 GB und 36 GB als SSA­Platten verwendet, die über vier
sogenannte Device Adapter Pairs in SSA­Loop­Technik an
den Rechner angebunden waren. Am Anfang konnten die
Plattentypen nicht gemischt werden, später allerdings war es
möglich, unterschiedliche Platten in die Arrays einzubauen.
Cache­Größen von bis zu 6 GB waren konfigurierbar und
ein Strom unabhängiger Schreibspeicher (NVS Non Volatile
Storage) von 384 MB stand zur Verfügung. Die Arrays waren
am Anfang ausschließlich unter RAID5 betreibbar. Für den
Mainframe standen die 3380­ und 3390­Spurformate zur Verfügung,
an Open Systems (UNIX, Windows NT und AS/400)
wurden entsprechende LUNs emuliert (Logical Unit Number).
Vom Vorgänger der ESS, dem Versatile Storage Server, einem
Kurzläufer von wenigen Monaten, wurde der IBM Data Path
Optimizer für AIX und Windows NT als integraler Bestandteil
für die Multipfadfähigkeit der Maschine übernommen.
Funktional war die Maschine am Anfang noch schwach auf
der Brust und es standen nur begrenzt Copy Services als
Funktionen zur Verfügung, was die Markteinführung nicht
gerade vereinfachte. Später kamen dann die Mainframe­Funktionen
‘Concurrent Copy’ und XRC, ‘eXtended Remote Copy’
als asynchrone Spiegelmöglichkeit ganzer Systeme für S/390­
Server (mit konsistentem Datenbestand auf der Sekundärseite)
und wiederum zeitversetzt die Funktion PPRC ‘Peer to
Peer Remote Copy’ als synchrone Spiegelung sowohl für
den Mainframe als auch den Open­Systems­Bereich. Auch
FlashCopy (Instant- oder Point-in-Time-Copy) wurde auf
der Maschine implementiert, um in Sekundenschnelle Kopien
erzeugen zu können, mit denen man sofort arbeiten konnte.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Knapp 2 Jahre nach der Markteinführung bot die Maschine
dann allerdings im Mainframe­Umfeld eine wesentlich höhere
Funktionsvielfalt im Vergleich zu den auf dem Markt befindlichen
Mitbewerbersystemen. Die Funktion PAV (Parallel
Access Volume) erlaubt im Mainframe­Umfeld multiple I/O­
Operationen auf denselben logischen Volume. Multiple
Allegiance lässt den parallelen Schreib­ und Lesezugriff auf
dasselbe logische Volume von verschiedenen S/390­Servern
zu. I/O Priority Queuing verwendet die Priorisierungsinformationen
des OS/390­Workloadmanagers im Goal Mode,
um die Sequenz der einzelnen I/Os optimal zu steuern und
Workloads mit unterschiedlicher Wichtigkeit entsprechend
ihrer Priorisierung optimal zu behandeln.
Das System kam mit neuen Management­Tools, der sogenannten
‘StorWatch’­Familie, auf den Markt, die es erlaubte,
die Maschinen über das Web zu administrieren. Standardmäßig
wurde die Maschine mit dem ESS Specialist ausgeliefert,
der vor allem für das Konfigurieren und für spätere
Modifizierungen notwendig war. Als separates, zusätzlich
käufliches Produkt wurde der ESS Expert zur Verfügung
gestellt, der ausführliche Informationen über genutzte Kapazitäten,
Performance, Antwortzeiten, Cache Hit Ratios und
mehr lieferte, um ein optimales Tuning auf der Maschine für
die unterschiedlichen Workloads durchführen zu können.
Im Mai 2001 kamen die Folgemodelle F10 und F20, die
erstmals native FICON­Anschlüsse boten, um mit FibreChannel
im Mainframe­Umfeld zu arbeiten. Auch die bisher verwendeten
ESCON­ und FC­Adapter waren verbessert worden
und boten 100 MB/s Durchsatz pro Port in FICON und Fibre­
Channel Speed. Sie lieferten Entfernungsmöglichkeiten von
bis zu 10 km (native) und bis zu 100 km über entsprechende
SAN­Fabric­Komponenten aus. Die neuen Modelle konnten
mit bis zu 16 FICON­Anschlüssen und einer zusätzlichen
Cache­Option von 24 GB, also maximal 32 GB, ausgestattet
sein. Damit verbesserte sich die Leistung zu den Vorgängermodellen
um ca. 40 %.
Funktional stellten die neuen Modelle die Funktion PPRC und
FlashCopy auch der Systemplattform AS/400 und iSeries zur
Verfügung. Im März 2002 wurde auch die FICON-Unterstützung
für die bei Airline­Buchungssystemen verwendete
TPF­Anwendung (Transaction Processing Facility) verfügbar.
Enterprise Storage Server ESS (Shark), 1999: Modelle E10/E20 bis 11 TB,
2001: Modelle F10/F20 bis 35 TB, 2002: Modelle 800 und 800 Turbo II bis
56 TB, April 2004: Entry-Modell 750 bis 5 TB (Brutto-Kapazitäten)
Der Wechsel von ESCON­ auf FICON­Infrastrukturen brachte
damals enorme Infrastrukurverbesserungen und Infrastruktureinsparungen
mit sich, weil in der Regel vier ESCON­Kanäle
mit 18 MB/s durch einen FICON­Kanal mit 100 MB/s ersetzt
werden konnten. Allerdings dauert die Penetration noch bis
in die heutige Zeit an.
Im August 2002 kam die letzte Modellreihe der ESS mit den
Modellen 800 und 800 Turbo II auf den Markt, die dann noch
durch ein Einstiegsmodell 750 im Frühjahr 2004 ergänzt
wurde. Die neuen Modelle waren leistungsstärker und
verwen deten zwei 2­, 4­ oder 6­Way­SMP­Rechner mit bis
zu 64 GB Cache.
Dadurch waren ca. 42 % mehr Transaktionen bei Cache
Standard Workloads möglich. Die neuen Modelle konnten im
Mischbetrieb Laufwerke mit 18 GB, 36 GB, 73 GB und 146 GB
ausgestattet werden und boten als Brutto­Kapazität von
582 GB bis 56 TB. Die Laufwerke mit 18 GB, 36 GB und 73
GB gab es mit Umdrehungsgeschwindigkeiten von wahlweise
10.000 Umdrehungen/Minute und 15.000 Umdrehungen/
Minute, während das großkapazitive 146­GB­Laufwerk nur
mit 10.000 Umdrehungen/Minute zur Verfügung stand.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
55

56
1999 bis 2005
Die Epoche der Multiplattform-Systeme und des FibreChannel SAN und NAS
Wahlweise konnten die Arrays mit RAID0, 1, 5 und 10 konfiguriert
werden und alle Platten in einem Array wurden mit
einem Striping­Verfahren (alle Laufwerke arbeiten gleichzeitig,
wenn eine Spur in kleinen Stücken parallel auf alle Laufwerke
des Arrays geschrieben oder gelesen wird) angesteuert, um
eine optimale Schreib­ und Lese­Performance sicherzustellen.
Für die Array­Anbindung wurden SSA­160­Adapter verwendet,
die in einer Doppelloop einen Gesamtdurchsatz von 320 MB/s
bei acht gleichzeitigen I/Os erreichen konnten. Der Gesamtdurchsatz
(interne Bandbreite) lag beim Turbo­II­Modell bei
3,2 GB/s. Die maximale Cache­Größe lag bei bis zu 64 GB.
Das RAID­Management war komplett in die Adapterkarten
verlagert und bei sequenziellen Schreib­Workloads war die
Maschine in der Lage, vom RAID5­ in den RAID3­Modus umzuschalten,
bei der bis zu 64 gleichzeitige physische I/Os
auf die Platten möglich waren.
Alle Maschinen waren von Beginn an auf 2­Gbit­Hostanbindungungstechnologie,
also 2 Gbit FICON und 2 Gbit
Fibre Channel, ausgelegt. Daneben konnte die Maschine
immer auch noch mit ESCON­ und Ultra­SCSI­Adaptern
konfiguriert werden.
Die Modelle 800 und 800 Turbo II waren die Basis, um ein
komplett neues Remote-Copy-Verfahren zu entwickeln, das
in seiner Leistungsfähigkeit bis heute einmalig im Markt ist
und bei den Folgeprodukten der DS6000 und DS8000 maßgeblich
seinen Einsatz findet. Dieses neue Remote­Copy­
Verfahren wurde den neuen ESS­Modellen im April 2004 zur
Verfügung gestellt und ermöglichte durch eine bidirektionale
Implementierung über eine FibreChannel­Verbindung eine
synchrone Spiegellast (PPRC) von bis zu 16.000 I/Os in der
Sekunde (ESS), die sich später bei den neuen DS8000 auf
bis zu 23.000 I/Os pro Sekunde steigerte – und das über
einen einzigen FibreChannel­Link. Bei dieser neuen Implementierung
können extrem kurze Antwortzeiten, auch bei
synchroner Spiegelung über lange Entfernungen, erzielt
wer den. Bei den Modellen 800 der ESS wurden Antwort­
zeiten von 2 ms bei einer synchronen Spiegelung von über
75 km erzielt.
Ebenso wurden für die neuen Modelle die Management­
Möglichkeiten erweitert. So wurden erstmals offene APIs als
Industrie Standard Interface (SNIA­SMI­S) zur Verfügung gestellt.
Die Maschinen konnten mit Scripting Tools über das
CLI (Command Line Interface) automatisiert werden. Ebenso
stand eine Web­basierende grafische Benutzerober fläche
(GUI) für einfache Administration zur Verfügung.
Für alle ESS­Modelle wurden RS/6000 basierende POWER5­
Prozessoren eingesetzt. Die E­Modelle verwendeten eine
H50 als 4­Way­SMP­Version mit einer Taktrate von 340 MHz.
Die F­Modelle benutzten eine H70 als 4­Way­SMP mit
540 MHz. Die letzten Modelle der 800er ­Reihe verwendeten
einen H80­Rechner. Das Einstiegsmodell 750 benutzte eine
H80 als 2x2­Way mit 600 MHz, die Modelle 800 eine H80
als 2x4­Way mit 600 MHz und die leistungsstärkste ESS 800
Turbo 2 eine H80 als 2x6­Way mit 750 MHz. Für die interne
Übertragung in den Maschinen wurde mit PCI­Bussen
gearbeitet.
Im Januar 2006 zog IBM alle ESS­Modelle mit Wirkung vom
April 2006 vom Vertrieb zurück.
Parallel zur ESS wurde bei IBM bereits 1999 der Startschuss
gegeben, an Server­basierenden Speicherarchitekturen zu
arbeiten, die die Basis für die heutige, erste Server­basierende
Speicherarchitektur legten und heute mit dem Produkt
der DS8000 zur Verfügung stehen. Diese neue Architekturentwicklung
fand parallel zur Weiterentwicklung der ESS statt
und wurde unter größter Geheimhaltung vorangetrieben.
Das erfolgreiche, SSA­basierende Plattensystem IBM 7133,
das vor allem in RS/6000­ und pSeries­Umgebungen eingesetzt
wurde, bekam 2002 auch die Möglichkeit, in Fibre­
Channel SANs zum Einsatz zu kommen. Mit dem Adapter
7140 konnte das Plattensystem an SANs angeschlossen
werden und stellte eine neue Funktion über diesen Adapter,
‘InstantCopy’, zur Verfügung. Damit konnte neben einem
RAID1­Spiegel eine weitere Kopie erzeugt werden, die dann
für asynchrone Backup­ oder Testzwecke verwendet werden
konnte. Da die hier eingesetzte SSA­Technologie auch im
Enterprise Storage Server ESS (Shark) eingesetzt wurde, bezeichnete
man die Kombination von 7133 und dem Adapter
7140 auch als ‘Hammershark’. Die Nähe zur ESS (Shark)
wurde auch durch eine Aufrüstoption unterstrichen, bei
der 7133 Kapazität zur Erweiterung einer Shark genutzt
werden konnte.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Nach der Markteinführung der ESS als multiplattformfähiges
Enterprise­Plattensystem erkannte IBM sehr schnell, dass
selbst Einstiegskonfigurationen einer Shark für den Mittelstandsbereich
zu teuer waren. Deshalb wurde bereits im
Jahr 2000 mit der Firma Compaq ein OEM-Vetrtriebsvertrag
unterzeichnet, der IBM erlaubte, das aktuelle Compaq­
Plattensystem mit FibreChannel­Anschlüssen zu vertreiben.
Das Produkt MSS Modular Storage Server unterstützte
heterogene Serverplattformen im Windows­NT­ und UNIX­
Umfeld und wurde über Hubs und/oder Switches an FC­
Server angeschlossen.
Die Zeit des MSS Modular Storage Servers war aber nur von
sehr kurzer Dauer und es wurden nur vereinzelte Systeme
installiert. Mit der Übernahme von Compaq durch Hewlett­
Packard HP war die Allianz mit Compaq beendet.
Daraufhin griff IBM auf eine seit Anfang der 90er­Jahre be­
stehende OEM-Allianz mit der Firma LSI zurück, die es
erlaubte, dass IBM unter IBM Logo Plattenprodukte von LSI
speziell im Intel­Umfeld (NetFinity) über den IBM xSeries­
Kanal vertrieb. Bereits 1993 wurden die LSI­Produkte IBM
7135­110 RAIDiant Array in den Vertrieb aufgenommen, 1995
das IBM 7135­210 RAIDiant Array, 1998 der IBM 3526 FC
RAID Controller, 2000 die IBM 3552 FAStT500 und die IBM
3542 FAStT200 und im Jahr 2001 die IBM 1742 FAStT700.
Im Jahr 2001 wurde diese Allianz zwischen IBM und LSI auf
den gesamten Storage­Vertrieb erweitert, eine Allianz, die sehr
erfolgreich werden sollte und bis in die heutige Zeit hochaktuell
ist. Das erste Produkt, das IBM über diese Allianz vertrieb,
war ein Entry­Plattenprodukt, die FAStT200, damals
auch als IBM 3542 bekannt, das mit bis zu zwei FibreChannel­Ports
mit der Grundeinheit (10 eingebaute Festplatten)
und zwei Erweiterungseinheiten EXP500 (pro EXP500
zusätz liche 15 Platten) eine maximale Kapazität von bis zu
2,1 TB anbot. Das System stellte eine preisgünstige, performante
Plattenlösung für dezentrale Abteilungen und Arbeitsgruppen
mit bis zu vier Servern dar. Das System bot als
Entrysystem damals bereits eine ganze Reihe von Sicherheitsoptionen
wie Dual Active RAID Controller, RAID 0, 1, 10,
3 und 5, redundante Netzteile und Batterie sowie die Möglichkeit,
alle Kom ponenten als ‘Hot Swaps’ zu tauschen. Im
System konnten im Mischbetrieb Platten mit 18 GB, 36 GB
und 73 GB eingesetzt werden.
Die Abkürzung ‘FAStT’ steht für ‘Fibre Array Storage Tech-
nology’. Der ursprüngliche Name sollte FAST – für Fibre Array
Storage Server – lauten, war aber bei der Ankündigung der
LSI­Produkte bereits vergeben und konnte nicht verwendet
werden. Deshalb entschloss man sich für FAStT mit der
Intention, dass das kleine ‘t’ nicht ausgesprochen wird. Trotz
allem setzte sich die Aussprache als ‘fast_T’ in ganzer
Breite durch.
FAStT900 FAStT700 FAStT600 Turbo FAStT600 FAStT200 FAStT200
Host Interface 2 Gbps FC 2 Gbps FC 2 Gbps FC 1 Gbps FC 2 Gbps FC 2 Gbps FC
SAN attachments
(max)
Direct attachments
(max)
Redundant drive
channels
Drive types supported
4 FC-SW 4 FC-SW 4 FC-SW 4 FC-SW 4 FC-SW 4 FC-SW
8 FC-AL 8 FC-AL 4 FC-AL 4 FC-AL 2 FC-AL 4 FC-AL
Four 2 Gb FC Four 2 Gb FC Four 2 Gb FC Four 2 Gb FC Four 1 Gb FC Four 2 Gb FC
FC, SATA FC FC, SATA FC, SATA FC FC, SATA
Max drives 224 224 112 56 66 56
Max physical
capacity with FC
Max physical
capacity with SATA
32 TB 32 TB 16.4 TB 8.2 TB 9.6 TB –
56 TB – 28 TB 28 TB – 14 TB
XOR technology ASIC ASIC Integrated Integrated Integrated Integrated
Subsystem Cache 2 GB 2 GB 2 GB 512 MB 256 MB 512 MB
IBM FAStT-Plattensubsystemfamilie, Spezifikationsübersicht
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
57

58
1999 bis 2005
Die Epoche der Multiplattform-Systeme und des FibreChannel SAN und NAS
Die Reihe der FAStT­Plattensysteme wurde im Oktober 2001
um die leistungsfähigeren Produkte FAStT500 und FAStT700
erweitert, die mit bis zu vier FibreChannel­Anschlüssen höhere
Kapazitäten boten. Im Hochleistungsbereich kam im Februar
2003 die FAStT900 dazu, um die Baureihe auch im oberen
Leistungsbereich abzurunden. Im April 2003 wurde die
FAStT500 duch die FAStT600 und FAStT600 Turbo ersetzt.
Neben den Plattenerweiterungseinheiten EXP500 und EXP700
(EXP steht für Expansion), die mit FibreChannel­Platten
bestückt waren, kündigte IBM im Oktober 2003 die Erweiterungseinheit
EXP100 an, die mit preislich günstigeren SATA­
Platten bestückt war. Der dazu passende Controller wurde
im Mai 2004 mit der FAStT100 angekündigt. SATA-Platten
(Serial Advanced Technology Attached) sind günstige IDE­
Platten mit seriellem Interface, die bisher auschließlich im
Heim­PC­Bereich ihre Anwendung fanden. Mit Ausnahme
der schon länger verfügbaren FAStT200 waren alle Systeme
jetzt mit 2 Gbit FibreChannel ausgestattet, und das sowohl
Host­seitig als auch in der Anbindung der Plattenloops an
den jeweiligen FAStT Controller. Über 90 % des Vertriebs
dieser LSI­Plattensubsystem­Serie lief über IBM oder IBM
Geschäftspartner und war im FibreChannel­Umfeld ein riesiger
Erfolg, der bis heute anhält.
Je nach Controllerstärke wurde bei den FAStT­Plattensystemen
eine Vielzahl von neuen Funktionalitäten eingeführt, die dann
vor allem in den oberen Modellen zum standardmäßigen Einsatz
kamen und bis heute in den Systemen verwendet werden.
Zum besseren Verständnis werden diese Funktionen im
Folgenden beschrieben.
DCE und DVE: Dynamic Capacity Expansion und Dynamic
Volume Expansion ermöglichen, zugewiesene Speicherbereiche
im laufenden Betrieb zu vergrößern. Innerhalb des
FAStT­Systems werden physische Laufwerke zu einzelnen
Array­Groups gebunden. Die Laufwerke können sich dabei
über verschiedene EXP­Erweiterungseinheiten verteilen. Die
Selektion der Laufwerke kann dem System überlassen werden
(dann wird stets die performanteste Konfiguration gewählt)
oder vom Administrator manuell definiert werden. Für die erstellte
Array­Group wird ein RAID­Level definiert, der für die
gesamte Array­Group Gültigkeit hat. Innerhalb dieser Array­
Group können verschiedene Volumes definiert werden. Diese
Volumes werden den einzelnen Servern zugewiesen. Für den
Fall, dass der gewählte Plattenzusammenschluss (Array­Group)
mehr Kapazität benötigt oder eine höhere Performance erforderlich
wird, gibt es die Möglichkeit, dieser Group eine
oder mehrere physische Laufwerke hinzuzufügen (DCE). Die
in dieser Group befindlichen Volumes nutzen diese neue
Kapazität, die Disk wird automatisch in die Volume­Verteilung
aufgenommen.
Sollte innerhalb eines zugewiesenen Volumes mehr Kapazität
benötigt werden, so ist im laufenden Betrieb auch hier eine
Kapazitätserweiterung möglich (DVE). Voraussetzung hierfür
ist, dass entsprechende Kapazitäten innerhalb der Array­
Group zur Verfügung stehen (in diesem Fall kann über DCE
eine beliebige, undefinierte Platte ergänzt werden). Diese
Funktionalitäten ermöglichen es dem Anwender, flexibel auf
Kapazitätsanforderungen einzugehen und diese auf einfachste
Weise umzusetzen. Alle Funktionen arbeiten im laufenden
Betrieb mit Data in Place und werden über den
FAStT Storage Manager initialisiert.
DRM: Dynamic RAID Migration. Genauso wie zugewiesene
Kapazitäten sind ebenfalls zugewiesene RAID­Level nicht
statisch, sondern auch im laufenden Betrieb veränderbar.
Sollten sich durch Änderungen im Lastprofil, der Kapazitätsoder
Sicherheitsanforderung Änderungswünsche am eingesetzten
RAID­Level ergeben, so kann dieser im laufenden
Betrieb je RAID­Array angepasst werden. Es stehen die
RAID­Level 0, 1, 1+0, 3 und 5 zur Verfügung. Es kann von
jedem RAID­Level zu jedem anderen RAID­Level gewechselt
werden. Voraussetzung ist, dass entsprechende Plattenkapazitäten
(z. B. bei einem Wechsel von RAID5 zu RAID1) verfügbar
sind (DCE). Auch dies ist im laufenden Betrieb mit Data
in Place möglich. Die RAID­Berechnung wird im Controller
über HW­Funktionalität durchgeführt.
DAE: Dynamic Array Expansion. Sollte innerhalb einer FAStT
weitere physische Kapazität benötigt werden, so gibt es die
Möglichkeit, im laufenden Betrieb die angeschlossenen Erweiterungseinheiten
mit weiteren FC­Laufwerken in verschiedenen
Kapazitätsgrößen und mit unterschiedlichen RPMs zu
bestücken (bis zu 14 Laufwerke je EXP700). Sollten in den
angeschlossenen EXPs keine freien Slots zur Verfügung stehen,
so besteht die Möglichkeit, im laufenden Betrieb eine
weitere EXP700 an den FAStT­Controller anzuschließen. So
lassen sich einzelne Laufwerke oder ganze Erweiterungseinheiten
im laufenden Betrieb hinzufügen.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Neben diesen Standard­Funktionalitäten sind weitere,
optionale Funktionen verfügbar:
•
FlashCopy: Die Funktion FlashCopy (Point-in-Time-Copy)
ermöglicht bis zu 4 virtuelle Kopien eines bestehenden
Volumes. Diese Funktion kommt vor allem für die Erstellung
von Testumgebungen und die Erhöhung von Onlinezeiten
bei Backups zum Einsatz. Wie funktioniert nun FlashCopy
bei den FAStT-Systemen?
Über dem FAStT Storage Manager (FSM) wird der Flash-
Copy-Befehl über die GUI-Oberfläche abgesetzt. Über das
GUI wird in diesem Schritt ebenfalls ein Repository angelegt,
ein physischer Datenbereich für die Änderungen zwischen
der Kopie und T0, dem Zeitpunkt des Spiegelungsbeginns.
Die Größe des Repositorys ist abhängig von der Anzahl der
Änderungen am Originalvolume. Die Erfahrung zeigt, dass
eine Repositorygröße von 20 % des Originalvolumes sinnvoll
ist. Sollte bei längerer Kopievorhaltung oder überdurchschnittlich
vielen Änderungen der Source mehr Repository-Kapazität
benötigt werden, so kann dieser Bereich
flexibel vergrößert werden (DVE). Die Erstellung einer Flash-
Copy ist innerhalb von wenigen Sekunden abgeschlossen.
Zur weiteren Benutzung einer FlashCopy ist es wichtig, zu
T0 auf einen konsistenten Datenbestand zurückzugreifen,
da ansonsten eine inkonsistente Kopie entsteht. Die erstellte
virtuelle Kopie (nach wenigen Sekunden) kann z. B. dem
Backup-Server zur Datensicherung zugewiesen werden.
Wird während der Nutzung einer FlashCopy (Target) eine
Änderung an der Source (Block A) vorgenommen, so wird
das Original vor der Änderung in das Repository übernommen.
Wird das Target geändert, so wird diese Änderung
ebenfalls im Repository gespeichert. Wurden an der
Source keine Änderungen vorgenommen, so greift man
bei der Nutzung der Copy (Target) automatisch auf die
Source zurück.
FAStT100
FAStT RAID Controller Familie
FAStT200
VolumeCopy: Ergänzend zur Funktion FlashCopy ist für
FAStT-Systeme mit FSM 8.4 auch die Funktion VolumeCopy
verfügbar. VolumeCopy erstellt im Gegensatz zu FlashCopy
eine physische Kopie. Es muss also für die Erstellung einer
VolumeCopy die gleiche physische Kapazität wie die der
Source zur Verfügung stehen. Es besteht die Möglichkeit,
diese Kopie nach Wunsch zu priorisieren. Dies bedeutet,
dass I/O-Tätigkeiten zum Host bevorzugt, die Erstellung
der Kopie nur zweitrangig behandelt wird. VolumeCopy ist
eine Funktion, die besonders für Testumgebungen (z. B. zur
Durchführung von Releasewechseln etc.) oder für Online-
Backups geeignet ist.
Remote Mirroring: Während die Kopierfunktionen FlashCopy
und VolumeCopy Datenkopien innerhalb eines FAStT-
Systems zur Verfügung stellen, erstellt Remote Mirroring
eine Kopie von Daten über eine SAN-Infrastruktur von einer
FAStT auf eine weitere. Diese Funktion ist für die FAStT-
Systeme 700 und 900 verfügbar. Remote Mirroring ist eine
bidirek tionale, synchrone Kopie. Über dedizierte
FibreChannel-Ports können bis zu 32 Volumes auf eine
zweite FAStT gespiegelt werden. Remote Mirroring wird
für Katastrophen vorsorge und High-Performance Copys
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
•
•
•
FAStT600
Single/Dual/Turbo
eingesetzt.
Partitioning: Um unterschiedliche Speicherbereiche auf
der FAStT voneinander abzugrenzen, steht die Funktion
Partitioning zur Verfügung. Die Abgrenzung bewirkt, dass
definierte Server nur auf den ihnen zugewiesenen Speicherbereich
zugreifen können. Auf Speicherbereiche von
‘fremden’ Servern kann somit kein Zugriff erfolgen. Dies
erhöht die Sicherheit der einzelnen Speicherbereiche. Besonders
in Microsoft-Umgebungen ist diese Funktion sehr
wertvoll, da die Betriebssysteme keine derartige
Funktiona lität bieten.
FAStT700
FAStT900
59

60
1999 bis 2005
Die Epoche der Multiplattform-Systeme und des FibreChannel SAN und NAS
Laufwerkerweiterungseinheiten, Management SW und das Einbau-Rack
EXP100
Serial-ATA-Technologie
EXP700
2-Gb-FC-AL-Technologie
Laufwerkeinheiten FAStT Storage
Manager (FSM)
Mit der Ankündigung der ersten Server-basierenden Spei-
cherarchitekturen mit den Plattenprodukten DS6000 und
DS8000 unternahm IBM im September 2004 ein generelles,
einheitliches Re­Branding der Plattenprodukte. DS steht für
Disk System. Die Zahl dahinter soll die Leistungsfähigkeit
des jeweiligen Systems reflektieren: je höher die Zahl, desto
höher die Leistung.
Neben der Vereinheitlichung der Plattenproduktnamen wurden
auch die Namen der jeweiligen Funktionalitäten entsprechend
angepasst. Vergleichbare Funktionen der DS6000 und DS8000
wurden bei den FAStT­Systemen mit denselben Begriffen
bezeichnet. Dies betraf vor allem die Remote­Copy­Spiegelverfahren.
Das synchrone Spiegeln von Plattensystemen wird bei der
DS6000 und DS8000 als Metro Mirroring bezeichnet, das
asynchrone Spiegelverfahren als Global Mirroring. Die neu
eingeführten Begriffe sollen dem neu entwickelten Spiegelverfahren,
das auf der ESS Modell 800 als Plattform entwickelt
wurde und heute das leistungsfähigste Spiegeln im Markt
darstellt, gebührend Rechnung tragen.
Für die FAStT­Plattenfamilien wurden im Einzelnen folgende
Rebrandings durchgeführt:
Naming Prior to Sept 7, 2004 New naming as of Sept 7, 2004
IBM TotalStorage FAStT Storage Server IBM TotalStorage DS4000
FAStT DS4000
FAStT Family DS4000 series
FAStT Storage Manager vX.Y
(example FSM v9.10)
FAStT100 DS4100
FAStT600 DS4300
FAStT600 with Turbo Feature DS4300 Turbo
FAStT700 DS4400
FAStT900 DS4500
DS4000 Storage Manager vX.y
(example 9.10)
EXP700 DS4000EXP700
EXP100 DS4000EXP100
FAStT FlashCopy FlashCopy for DS4000
FAStT VolumeCopy VolumeCopy for DS4000
FAStT Remote Volume Mirror
(RVM)
Enhanced Remote Mirroring for
DS4000
FAStT Synchronous Mirroring Metro Mirroring for DS4000
FAStT Asynchronous Mirroring
(New Feature) w/o Consistency Group
FAStT Asynchronous Mirroring
(New Feature) with Consistency Group
Das Rack
Global Copy for DS4000
Global Mirroring for DS4000
Die jetzt neu bezeichnete DS4000-Plattensubsystemfamilie
wurde im Mai 2005 durch ein neues Hochleistungsmodell
DS4800 ergänzt, das eine doppelt so hohe Leistungsfähigkeit
im Vergleich zur DS4500 auslieferte. Die DS4800 war
vom Aufbau her bereits beim Verfügbarwerden eine 4­Gbit­
Maschine und somit das erste 4­Gbit­Plattensystem auf dem
Markt. Die Cachegrößen am Anfang konnten je nach Modell
mit 4 GB, 8 GB und später 16 GB konfiguriert werden. Die
DS4800 hatte zudem noch eine andere positive Eigenschaft
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

in der Bauweise: Die Maschine war RoHS-konform und ent­
sprach bereits 2005 der neuen EU­Richtlinie, die seit 1. Juli
2006 in Kraft ist.
Im Jahr 2003 bildete sich in den USA ein Gremium, das es
sich zur Aufgabe machte, Plattensubsysteme unterschiedlicher
Hersteller nach realen und produktiven Workloads auszutesten
und diese Ergebnisse zu publizieren. Dieses heute
fest etablierte Gremium nennt sich ‘Storage Performance
Council’ bzw. SPC.
Die neue DS4800 übertraf als Midrange­Plattensystem in der
Leistung alle anderen Hersteller mit großem Abstand und er­
reichte eine Spitzenpunktzahl von 42.254. Damit ist die DS4800
heute das schnellste Plattensystem im Midrange­Markt.
Da die älteren DS4000­Produkte mit Ausnahme der neu verfügbar
gewordenen DS4800 nicht der RoHS­Richtline entsprachen,
wurden im Mai 2006 alle nicht RoHS­konformen
Produkte durch entsprechend neue ersetzt.
RoHS steht für ‘Restriction of Hazardous Substances’
und stellt ab dem 1. Juli 2006 eine gesetzlich kontrollierte
EU­Richtlinie dar, die genau vorschreibt, welche Materialien,
DS4000 Series aktuell im Jahr 2006
DS4200
4 Gbit
2 GB Cache
RoHS compiliant
SATA Controller
DS4700 Modell 70
4 Gbit
2 GB Cache
RoHS compiliant
Aktuelle Modelle der IBM DS4000-Plattenfamilie im Jahr 2006
DS4700 Modell 72
4 Gbit
4 GB Cache
RoHS compiliant
EXP420
4 Gbit
RoHS compiliant
SATA-Platten 500 GB
Legierungen, Barium­Derivate etc. in Neuprodukten eingesetzt
werden dürfen. Diese neue Richtlinie gilt EU­weit und
betrifft alle Neuprodukte in der Elektro­ und IT­Industrie, die
ab dem 1. Juli 2006 vertrieben werden.
Die DS4100 als SATA Controller wurde durch den neuen
DS4200 SATA Controller ersetzt, die EXP100 mit 250­GBund
400­GB­SATA­Platten durch die EXP420 mit 500­GB­
SATA­Platten.
Die DS4300 Dual Controller wurden durch die DS4700 Modell 70
und die DS4300 Turbo durch die DS4700 Modell 72 ersetzt.
Ebenso wurde die EXP710 mit FibreChannel­Platten durch
die EXP810 mit FC­Platten auf 4­Gbit­Basis ersetzt.
Die DS4500, ehemals FAStT900, wurde durch ein neues Einstiegsmodell,
das Modell 80 der leistungsstarken DS4800,
ersetzt. Bei diesem Einstiegsmodell 80 wurde die interne
Übertragungsbandbreite leicht verringert und die Prozessoren
der Controller wurden mit einer 100­MHz­Taktung (im Vergleich
zu einer 133­MHz­Taktung) versehen. Damit schließt
das Modell 80 der DS4800 die Leistungslücke zwischen den
Hochleistungsmodellen der DS4800 und dem Midrange­
Modell 72 der DS4700.
DS4800 Modell 80
4 Gbit
4 GB Cache
RoHS compiliant
EXP810
4 Gbit
RoHS compiliant
DS4800
4 Gbit
4/8/16 GB Cache
RoHS compiliant
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
61

62
1999 bis 2005
Die Epoche der Multiplattform-Systeme und des FibreChannel SAN und NAS
DS4000 Erweiterungen 2007 und 2008
Im Jahr 2007 stellte IBM für die DS4000 Plattenfamilie eine
ganze Reihe von Erweiterungen vor. Im Mai 2007 wurden
für die DS4000 750 GB SATA-Platten und 300 GB Fibre-
Channel-Platten mit 15.000 Umdrehungen in der Minute
eingeführt. Damit skaliert eine DS4800 auf bis zu 68 TB
bzw. 168 TB Speicherkapazität (je nach Verwendung des
Plattentyps). Im Oktober 2007 kamen viele funktionale
Erweiterungen für alle Systeme DS4000 dazu. Für die
Systeme DS4200 und DS4700 steht als neue RAID­Option
RAID6 zur Verfügung. RAID6 sichert den Ausfall von zwei
Platten im RAID­Array ab, da mit zwei Parity­Schemen gearbeitet
wird (siehe auch unter RAID). Die Anzahl der Mirror
Relations wurde verdoppelt, ebenso die Anzahl der Flash
Copies. Mit Verfügbarkeit im Februar 2008 können für alle
Systeme LUNs konfiguriert werden, die größer als 2 TB sind.
Die leistungsstarke DS4800 bekam die Erweiterung, dass
bis zu 512 Server an das Plattensystem angeschlossen
werden können. Es stehen jetzt vier aktuelle Modelle der
DS4800 zur Verfügung, die sich hauptsächlich in der Cache­
Größe unterscheiden. So sind, je nach Modell, die Cache­
Größen 4 GB, 8 GB und 16 GB verfügbar.
Bedient werden die RAID­Level 0, 1, 3, 5 und 10 (der neue
RAID6­Level steht ausschließlich der DS4200 und DS4700
zur Verfügung). Die Berechnung der RAID­Level bzw. die
XOR-Kalkulation in der DS4800 erfolgt in einem eigens
entwickelten ASIC. Dies ist ein spezieller Prozessor, der
speziell für diese Workload konzipiert wurde. Dies macht
die DS4800 frei von Latenzen, weil weder der Cache noch
andere durchsatzrelevanten Teile der Maschine damit belastet
werden.
Ansicht und Aufbau des Hochleistungsmodells DS4800
Die DS4800 hat alle Festplatten in der Expansion Unit
EXP810 konfiguriert. Weitere Expansion Units sowie auch
einzelne Festplatten können im laufenden Betrieb hinzugefügt
und in Betrieb genommen werden.
Alle Komponenten der DS4800 sind redundant ausgelegt,
z. B. Controller, Stromzufuhr und Kühlung. Ebenfalls wird der
Cache gespiegelt und ist über eine Batterie bis zu 72 Stunden
vor Verlust geschützt. Zusätzlich ist bei der DS4800 die
Midplane, die als Interconnect Module bezeichnet wird, im
laufenden Betrieb tauschbar. Dies ist bislang einmalig bei
Plattensystemen im Midrange­Umfeld.
Ebenfalls einmalig ist die Performance der DS4800. Die
Maschine hält bis heute die Führungsposition im Benchmark
des Storage Performance Councils. Dies ist ein Random
I/O­orientierter Benchmark, bei dem reale Workloads hinterlegt
werden. Die genauen Testdaten sowie die Beschreibung
findet man unter www.storageperformance.org.
Der DS4000 Storage Manager wird für alle Systeme kostenfrei
mit jedem System mitgeliefert. Ebenso ist die Multipathing
Software sowie die Call­Home­Funktionalität ohne
zusätzliche Kosten einsetzbar. Als Premium­Features stehen
die Funktionen FlashCopy, VolumeCopy und eRVM zur Verfügung.
Diese sind nicht kostenfrei, jedoch wird immer nur
eine Lizenz pro System und Funktion herangezogen.
Sowohl bei Kapazität und Leistung als auch beim Preis bietet
die aktuelle Modellreihe der DS4000 für jeden Endbenutzer
eine maßgeschneiderte Plattenlösung im FibreChannel­
Umfeld an.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

SAN-Virtualisierung
Die Epoche der Multiplattform-Systeme war stark durch die
Einführung von FibreChannel­Netzen und den Aufbau von
SANs geprägt. Damit wurde das Thema Speichervirtualisierung
im SAN zu einem der aktuellsten Themen im Storage­
Umfeld – wobei das Konzept von Virtualisierung nicht neu
ist. Speichervirtualisierungskonzepte sind im Mainframe (z. B.
DFSMS) oder im UNIX­Bereich in Form von ‘Logischen
Volume­Managern’ schon lange im Einsatz. Der Einsatz von
Storage Area Networks (SAN) hat die Entwicklung hin zur
Speichervirtualisierung beschleunigt. Ebenso die Komplexität
heutiger heterogener Infrastrukturen hinsichtlich der Server,
Speichernetze und Speichersubsysteme.
Der primäre Ansatz von Speichervirtualisierung war die
Entkoppelung der physischen Speicherressourcen von der
direkten Zuordnung zu Serversystemen. Diese SAN­basierte
Lösung legt eine Virtualisierungsebene zwischen Server­ und
Speichersysteme. Vorrangiges Ziel ist die gemeinsame Nutzung
von Speicher quer über die gesamte Speicherhardware
sowie alle Serverplattformen und Betriebssysteme. Virtualisierung
im Speichernetzwerk ermöglicht es, Speicherressourcen
plattformunabhängig zu integrieren, aufzurüsten, zu migrieren,
zu replizieren und zu verteilen.
Um diese enorme Flexibilität innerhalb eines SANs zu
bekommen, entwickelte die IBM in Hursley, UK, das Produkt
SAN Volume Controller, auch SVC genannt, das im
Juni 2003 angekündigt und im September 2003 verfügbar
wurde.
Der IBM SAN Volume Controller wurde für einen Einsatz ent­
wickelt, bei dem Kapazitäten mehrerer heterogener Speichersysteme
zu einem einzigen Speicherreservoir, das von einem
zentralen Punkt aus verwaltet werden kann, zusammengefasst
werden. Er ermöglicht Änderungen an physischen Speichersystemen
mit minimalen oder keinen Beeinträchtigungen für
Anwendungen, die auf den Hosts ausgeführt werden, und
er minimiert Ausfallzeiten durch geplante oder ungeplante
Ereignisse, Wartungsmaßnahmen und Sicherungen. Zudem
erhöht der SVC die Auslastung der Speicherkapazitäten, die
IBM SAN Volume Controller SVC
Onlineverfügbarkeit sowie die Produktivität und Effizienz von
Administratoren. Darüber hinaus bietet er zur weiteren Vereinfachung
des Betriebs die Möglichkeit, erweiterte Kopierservices
systemübergreifend für Speichersysteme vieler verschiedener
Anbieter einzusetzen. In seinem vierten Release
wurde der SAN Volume Controller auf die Verwaltung noch
größerer und verschiedenartiger Speicherumgebungen ausgelegt.
Mit der jetzt erweiterten Unterstützung für zahlreiche
Speichersysteme anderer Anbieter, wie z. B. EMC, HP und
HDS, erlaubt der SAN Volume Controller die Einrichtung
einer mehrstufigen Speicherumgebung, sodass jede Datei
aufgrund ihres Stellenwerts auf dem entsprechenden Subsystem
abgespeichert werden kann. Die neueste Version des
SAN Volume Controller, die im Juli 2006 verfügbar wurde,
beruht auf 4-Gbit-Technologie und ist RoHS-konform.
Bandsysteme
Neben der Plattensubsystem­Weiterentwicklung und den
Fortschritten auf dem Gebiet von SAN­Glasfasernetzen blieb
auch die Weiterentwicklung der Tape­Technologien spannend.
Nach Einführung der LTO-Bandtechnologie 2000 (Ultrium 1)
mit 100 GB nativer Kapazität auf der Kassette wurde bereits
im Februar 2003 die Generation 2 (Ultrium 2) der LTO­Laufwerke
mit einer Kassettenkapazität von 200 GB native eingeführt.
Im Februar 2005 kam die Drittgeneration (Ultrium 3),
wieder mit einer Kapazitätsverdoppelung auf 400 GB native
pro Kassette. Auch die Geschwindigkeit der Laufwerke wurde
massiv verbessert. LTO2­Laufwerke arbeiteten bereits mit
35 MB/s mit 8­Spur­Technik. Bei LTO3 wurde auf 16­Spur­
Technik und eine Datenrate von 80 MB/s umgestellt.
Wie vorgesehen wurde die Schreib­/Lese­Rückwärtskompatibilität
eingehalten. So können LTO3­Laufwerke immer noch
Kassetten der Generation 1 lesemäßig verarbeiten und Kassetten
der Generation 2 sowohl schreiben als auch lesen.
Mit der Einführung der LTO3­Laufwerkgeneration im Februar
2005 wurden neben den bisher verwendeten überschreib­
baren Kassetten auch sogenannte WORM-Kassetten
(Write Once Read Many) eingeführt, die durch eine Mehr­
fachkennzeichnung als Überschreibschutz keine Möglichkeit
mehr bieten, abgespeicherte Daten zu verändern oder zu
löschen. Die WORM­Kennzeichnung ist auf der linken Seite
der Kassette in einem eingebauten Transponder­Chip hinterlegt,
das mit Radiofrequenz ausgelesen wird. Die Kennzeichnung
steht zudem im eingebauten Memory­Chip der
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
63

64
1999 bis 2005
Die Epoche der Multiplattform-Systeme und des FibreChannel SAN und NAS
Ultrium LTO Six-Generation Roadmap
Native Capacity
Native Transfer Rate
Generation 1
100 GB
up to 20 MB/s
Standardisierte LTO-Roadmap bis Generation 6
Kassette und in der Tape Volume Control Region am Bandanfang.
Um absolut manipuliersicher zu sein, wird bei der
Herstellung dieser WORM­Kassetten die Kennzeichnung
noch auf die vorgeschriebenen Servobänder gebracht: eine
Vierfach­Kennzeichnung, die sicherstellt, dass LTO3­WORM­
Kassetten nicht mehr überschrieben werden können. LTO­
WORM­Kassetten sind zweifarbig gekennzeichnet. Die eine
Hälfte ist schwarz und die andere in weißer Farbe.
Mit der Verfügbarkeit von LTO3 wurde die offizielle Roadmap
um zwei weitere Generationen mit LTO5 und LTO6 erweitert.
Es ist davon auszugehen, dass alle 2 bis 2 ½ Jahre eine neue
LTO­Generation gemäß dieser Roadmap auf dem Markt verfügbar
wird.
LTO1-Kassette,
100 GB Kapazität (native)
Generation 2
200 GB
up to 40 MB/s
LTO2-Kassette,
200 GB Kapazität (native)
WORM
Generation 3
400 GB
up to 80 MB/s
WORM WORM WORM
Generation 4
800 GB
up to 120 MB/s
Generation 5
1.6 TB
up to 180 MB/s
Generation 6
3.2 TB
up to 270 MB/s
Die etwas eigenwillige Farbwahl der standardisierten LTO­
Kassetten kommt aufgrund einer wichtigen Anforderung zustande.
Farbenblinde müssen in der Lage sein, die Kassetten
optisch zu unterscheiden.
Lag der Marktanteil 1999 mit 90 % noch DLT­Technologie
von Quantum, hat sich das Bild seither um 180 Grad gedreht
und die LTO­Technologie dominiert heute mit über 80 %.
Der LTO­Massenmarkt mit billigen LTO­Laufwerken in halbhoher
(Half High) Bauweise wurde bisher ausschließlich von
Hewlett­Packard HP abgedeckt. Mit einer Ankündigung im
Oktober 2006 steigt auch IBM in dieses Segment ein und
bietet halbhohe LTO3-Laufwerke im Niedrigpreisbereich
an. Die Laufwerke sind mit einer Ultra 160 SCSI Schnittstelle
ausgestattet und arbeiten mit einer Daten­Transfer­Rate von
60 MB/Sekunde (native).
LTO3-Kassette,
400 GB Kapazität (native)
LTO4-Kassette,
800 GB Kapazität (native)
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Im April 2007 kündigte IBM mit sofortiger Verfügbarkeit als
erster Hersteller LTO4-Laufwerke und -Kassetten an.
Das IBM TS1040 Laufwerk ist ein LTO4­Laufwerk in voller
Bauhöhe (Full High) und für den Einbau in IBM Libraries
vorgesehen. Das Laufwerk arbeitet mit einer Datenrate
von bis zu 120 MB/s (native) und die Kassettenkapazität
der neuen LTO4­Kassetten beträgt 800 GB (native).
Das Laufwerksinterface bietet einen Anschluss über einen
4 Gbit FibreChannel, SCSI oder 3 Gbps Dual Port SAS. Von
der TS1120 (3592) Technologie wurde der Surface Control
Guiding­Mechanismus zur optimierten Bandführung übernommen.
Ebenso bietet das Laufwerk vorausschauende
Fehlerbehandlung SARS (Statistical Analysis and Reporting
System), einen verbesserten ECC (Error Correction Code)
und Digital Speed Matching. Ein interner Pufferspeicher von
256 MB (LTO3 hatte nur 128 MB) sorgt dafür, dass der
Datenstrom nicht abreißt. Insgesamt passt sich das Laufwerk
an 6 Geschwindigkeiten des Servers an (30, 48, 66, 84
103 und 120 MB/s) und reduziert so die Start/Stop­Aktivitäten.
Adaptive Kompression von Daten dient zur optimalen
Nutzung der Bandkapazitäten. WORM­Kassetten sind
neben den Standard­Kassetten verwendbar und die Laufwerke
sind als erste LTO­Generation Encryption­fähig. LTO4
von IBM zeichnet sich durch sehr geringen Energiebedarf
mit Powermanagement­Funktion, u. a. Sleeping­Modus bei
Nichtgebrauch, aus (maximaler Strombedarf 27 Watt). IBM
setzt auf hohe Qualität, z. B. den Einsatz von Metall, und vermeidet
Plastik (weniger Störungen). Diese Merkmale führen
zu einem stabileren Betrieb im Vergleich zu den alten LTO­
Generationen. Es können Laufwerks­/Zugriffsstatistiken
geführt und ggfs. Fehler vorhergesagt werden, um so Laufwerke
präventiv auszutauschen, bevor ein Fehler auftritt.
Viele Innovationen, die im Enterprise­Bandlaufwerk IBM System
Storage TS1120 stecken, wurden in die IBM LTO4­Laufwerke
integriert. Unter Nutzung der Verschlüsselungstechnik
der TS1120 Technologie können die LTO4­Bandlaufwerke
Daten komprimieren und danach verschlüsseln mit fast keiner
Auswirkung auf die Leistung des Laufwerks (ca. 1 %).
IBM TS1040 LTO4-Laufwerk ohne Gehäuse
Die Unterschiede der Verschlüsselungstechnik liegen im
‘Key­Handling’ und sind ausführlich im Kapitel ‘Encryption’
beschrieben.
Die IBM TS1040 Laufwerke sind in den Autoloader TS3100
und in die IBM Libraries TS3200, TS3310 und TS3500 einbaubar.
Neben den TS1040 Laufwerken für die Libraries
kündigte IBM im April 2007 auch Stand Alone LTO4-Laufwerke
an, die auch in ein 19­Zoll­Rack eingebaut werden
können. Die ‘Stand Alone’ Laufwerke werden unter dem
Begriff TS2340 vermarktet und weisen dieselben Spezifikationen
wie TS1040 auf. Auch hier handelt es sich um Laufwerke
mit voller Bauhöhe (Full High). Die TS2340 haben
wahlweise einen Anschluss über 3 Gbps Dual Port SAS
oder SCSI und ein LED­Display zur Administration.
LTO4­Laufwerke können LTO1­Kassetten nicht mehr verar­
beiten. Sie können LTO2­Kassetten auslesen und LTO3­Kassetten
im LTO3­Mode beschreiben und lesen. Mit den LTO4­
Kassetten bietet ein LTO4­Laufwerk das Maximum an
Kapazität (800 GB auf der Kassette) und die hohe Datenrate
von bis zu 120 MB/Sekunde.
Im November 2006 kündigte IBM in der LTO4­Reihe die
IBM TS2240 als externes LTO4­Laufwerk mit halber Bauhöhe
(Half High) als weitere Option zu Full­High­Laufwerken an.
Das halbhohe LTO4­Laufwerk ist als ‘Stand Alone’­Laufwerk
oder ‘Rackmounted’ erhältlich. Im Gegensatz zu LTO3 erzielen
die halbhohen LTO4­Laufwerke dieselben Datenraten
(120 MB/s) wie die Laufwerke mit voller Bauhöhe. Für die
Produktion der halbhohen LTO4­Laufwerke nahm IBM Mitte
2006 ein neues Fertigungswerk in Singapur in Betrieb.
Viele Elemente aus der Produktion der Laufwerke mit voller
Bauhöhe wurden dort übernommen, sodass sicher gestellt
ist, dass die halbhohen Laufwerke in Qualität und Sicherheit
einem extrem hohen Maßstab gerecht werden.
Im Februar 2008 gab IBM bekannt, dass die halbhohen
LTO4-Laufwerke im TS3100 Autoloader und in der TS3200
Library integriert werden können. Anstelle von einem ganz
hohen Laufwerk können zwei halbhohe Laufwerke eingebaut
werden. Damit fasst der Autoloader TS3100 bis zu zwei
halbhohe LTO4­Laufwerke und die Library TS3200 bis zu
vier. In der TS3200 ist auch der Mischbetrieb von ganz
hohen und halbhohen Laufwerken unterstützt (ein ganz
hohes und zwei halbhohe Laufwerke).
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
65

66
1999 bis 2005
Die Epoche der Multiplattform-Systeme und des FibreChannel SAN und NAS
Die Magstar-3590­Bandentwicklung als 1/2­Zoll­Format lief
parallel zur LTO­Entwicklung, allerdings wurde dabei das
ausgereifte Aufzeichnungsverfahren mit Parity­Informationen
beibehalten. Die Magstar­Entwicklungsreihe fand im Juni 2002
mit der Generation 3, den Modellen 3590-H, ihren Abschluss.
Dabei wurde die Lese­Rückwärtskompatibilität der vorangegangenen
Generation, also für Kassetten, die mit dem B­ oder
E­Modell beschrieben wurden, sichergestellt.
Mit dem neuen H­Modell schrieb man 384 Spuren in noch
verdichteterer Form auf die Kassette. Für die Extended Length
Cartridge bedeutete das eine Kapazität von 60 GB unkomprimiert
und 180 GB komprimiert (3 :1). Die Datenrate von
14 MB/s wurde beibehalten. Damit erreichte Magstar im Jahr
2002 dieselbe Spurdichte wie die LTO­Generation 1 im Jahr
2000.
Mit dem von IBM im September 2003 neu angekündigten
Kompaktlaufwerk 3592 wurde ein neues ‘Tape-Zeitalter’
eingeleitet, dessen Dimension nur wenigen bis heute bewusst
ist! Schaut man aber genauer auf die integrierte Technologie
und auf die neue Beschichtungsart der 3592­Kassetten, kann
man diesen Entwicklungsschritt mit 1984 vergleichen. 1984
leitete die IBM den Wechsel vom Rollenband auf die Kassettentechnologie
ein. Mit der 3592­Technologie, die unter dem
Entwicklungsnamen ‘Jaguar’ entwickelt wurde, ergaben sich
technologische Möglichkeiten für Bandkassetten und den
Einsatz von Bandlaufwerken, von denen bis dahin nur geträumt
werden konnte.
Das Laufwerk selbst hat neben der neuen Flat-Lap-Kopf-
Technik, dem neuen, angepassten Guiding System mit Roller
Bearing und dem zeitgesteuerten Spurnachführungssystem
mit Servobändern (alle drei Elemente sind auch im LTO2und
LTO3­Laufwerk integriert) erstmals PRML Encoding
(Partial Response Maximum Likehood – siehe auch Technologie­Anhang)
implementiert, das eine Bit­Abbildung von 1:1
auf Band erlaubt.
Das PRML Encoding hatte auf der Platte bereits 1995 Einzug
gehalten, aber es war bisher nicht möglich, dieses Verfahren
auf Band einzusetzen. Grundvoraussetzung für den Einsatz
von PRML ist die Erzeugung von extrem gut durchmagnetisierten
Bits auf dem Datenträger. Die Beschichtung der
3592­Kassette im Zusammenhang mit den Flat­Lap­Köpfen
mit 10­fach höherer Induktionsstärke macht es möglich, solch
hochqualitative Bits zu erzeugen. Die 3592­Kassette ist auch
das erste Medium, bei dem mit starker Induktion gearbeitet
werden kann, ohne negative Erscheinungen wie z. B. weniger
Kapazität zu bekommen. Damit kann man ca. 50 % mehr in
der Datenspur unterbringen und so 50 % mehr an Kapazität
auf Kassetten mit der gleichen Bandlänge und der gleichen
Spurzahl realisieren.
Die Flat­Lap­Kopf­Technik verbessert das Schreib­/Lesesignal
zwischen Kopf und Band, weil eine wesentlich höhere
Induktion ermöglicht wird. Vor und hinter der Kopfreihe wird
zusätzlich ein Unterdruck erzeugt, der Staubpartikel, die
sich – aus welchen Gründen auch immer – ansammeln, entsprechend
absaugt (‘Self Cleaning Machines’). Diese Kopf ­
Technologie kam erstmals in vollem Umfang bei LTO2 zur
Anwendung und wurde in weitergehender Form im neuen
Laufwerk 3592 implementiert. Dadurch ist die Qualität der
erzeugten Bits wesentlich höher und die Möglichkeit, die Daten
wieder zu lesen, ist ziemlich unübertroffen in der Industrie.
Ebenso wird dadurch sichergestellt, dass selbst bei Langzeitlagerung
von Bändern nahezu kein Impulsverlust auftritt.
Das ‘Surface Control Guiding System’ ermöglicht eine ganz
exakte Führung der Schreib­/Leseelemente über Servobänder.
Die Repositionierung der Elemente auf den Servospuren
erfolgt über eine Zeitsteuerung, die über vorgeschriebene
Analogsignale (Analogspuren) in den Servobändern und eine
Zeitmessung durchgeführt wird. Dadurch wird die Oberfläche
des Bandes für die Feinführung genutzt und nicht der Randbereich
des Bandes, wo bei klassischen Aufzeichnungen
Servospuren aufgebracht waren. Damit lassen sich die Fehlerquellen
vermeiden, die aufgrund der Bandspannung im
Außenbereich auftreten können. Flat­Lap­Technik und das
neue Guiding System wurden erstmals in den Produkten
LTO2 und 3592 implementiert. PRML Encoding ist nur in der
3592 realisiert, weil die neue Beschichtung der 3592­Kassette
Voraussetzung für dieses neue Encoding­Verfahren ist.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Mit 40­MB/s­Datenrate und unglaublich schnellen Spul­ und
Fast­Search­Zeiten entpuppte sich das IBM 3592­Laufwerk
in dieser Zeit als das schnellste und zuverlässigste Laufwerk
auf dem Weltmarkt. Eine weitere Besonderheit der Jaguar­
Technologie sind neue, funktionale Möglichkeiten, die sich
aufgrund der 3592­Beschichtung implementieren ließen, weil
ein 3592­Medium keine Limitierungen in der Benutzerhäufigkeit
hat. Mit der Funktion ‘Virtual Back Hitch’ können viele
Rücksetz­Zeiten beim File Retrieval und alle Start­/Stopp­
Positionierungszeiten bei einzelnen File­Transfers, die nicht
sequenziell verarbeitet werden können, auf breiter Basis eliminiert
werden.
Klassisch arbeitet ein Laufwerk so, dass immer über den Puf­
ferspeicher auf Band geschrieben wird. Das Laufwerk bekommt
also Daten in den Pufferspeicher und über den sogenannten
Flush­Buffer­Befehl die Instruktion, die bisher erhaltenen
Daten auf Band rauszuschreiben. Ist dies geschehen, wird
der Flush­Buffer­Befehl als Tapemark in der Spur hinterlegt.
Sind keine zu schreibenden Daten mehr vorhanden, stoppt
das Laufwerk. Kommt wieder etwas in den Pufferspeicher
mit dem entsprechenden Flush­Buffer­Befehl, kann der Befehl
nicht sofort ausgeführt werden, weil das Laufwerk ja gestoppt
hat. Das Laufwerk muss jetzt zurücksetzen, um an dem Tapemark,
der zuletzt geschrieben wurde, in der Streaminggeschwindigkeit
zu sein, in der der Flush­Buffer­Befehl durchgeführt
werden kann. Dieses Zurücksetzen wird als Backhitch
bezeichnet. Ein Backhitch ist also nichts ‘Gutes’, da er Zeit
benötigt und das Band zusätzlich (vor allem im Außenbereich)
stresst. Mit Virtual Backhitch werden in der 3592 solche Positionierungsvorgänge
auf den minimalsten Level eingegrenzt!
Wie funktioniert nun Virtual Backhitch: Stellt die Control Unit
aufgrund der Pufferspeicherauslastung fest, dass nicht mehr
im Streamingmodus gearbeitet werden kann, schreibt das
Laufwerk in die momentane Spur eine sogenannte RABF­
Marke. RABF steht für Recursive Accumulative Backhitchless
Flush. Die RABF­Marke verweist einfach in ein Spurset, das
vor einem liegt und eigentlich zum Schreiben noch gar nicht
vorgesehen ist. In diesem neuen Spurset streamt das Laufwerk
einfach weiter, d. h., tröpfelt etwas in den Pufferspeicher
rein, wird zeitgleich eine Kopie auf Band in dem Spurset
erzeugt, das noch nicht zum Schreiben vorgesehen ist. Da
einfach weitergestreamt wird, unabhängig davon, ob Daten
kommen oder nicht, können natürlich regelrechte ‘Löcher’
zwischen den tatsächlich weggeschriebenen Daten entstehen.
Den ganzen Vorgang könnte man auch als ‘Nonvolatile
Caching auf Tape’ bezeichnen, da parallel auf Band und in
den Pufferspeicher geschrieben wird. Das Band stellt den
stromunabhängigen NVS­Schreibspeicher dar und der Pufferspeicher
den Cache. Geht der Cache aus irgendwelchen
Gründen kaputt, kann jedes Laufwerk trotzdem die auf Band
geschriebenen Daten verarbeiten, da der Hinweis auf das
Spurset über die RABF­Marke sichergestellt ist.
Ist der Pufferspeicher nun zu 50 % voll oder kommt das
Lauf werk ans Bandende, dreht das Laufwerk um und
schreibt zurück. Ist der Pufferspeicher voll, wird der
gesamte Pufferspeicher nun sequenziell in das richtige
Datenspurset herausgeschrieben. Danach wird der Verweis
der RABF­Marke aufgelöst, so, als ob nichts geschehen
wäre. Virtual Backhitch oder Nonvolatile Caching auf Tape
ist eine geniale Tape­Funktionalität, weil Repositionierungszeiten
eingespart werden und zusätzlicher Bandstress vermieden
wird.
Das 3592-Laufwerk selbst hat noch nie dagewesene
Schock- und Vibrationseigenschaften und kann selbst bei
hohen Erschütterungen noch sauber schreiben und lesen.
Dies wurde durch eine selbstkalibrierende Aufhängung des
Laufwerks im Gehäuse realisiert.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
67

68
1999 bis 2005
Die Epoche der Multiplattform-Systeme und des FibreChannel SAN und NAS
Im November 2005 wurde die zweite Generation der Jaguar­
Laufwerke verfügbar. Die 3592 Generation 2, die Marketing­
seitig als TS1120­Laufwerk (TS steht für Tape System)
bezeichnet wird, war und ist das erste Bandlaufwerk, das
mit zwei 4-Gbit-FibreChannel-Schnittstellen angesteuert
wird und dadurch auf komprimierter Basis eine Datenrate
von 260 MB/s realisiert. Die bisher verwendete 8­Spur­Technik
wurde auf 16­Spur­Technik umgestellt und die Induktion
der Köpfe wurde nochmals verdoppelt, sodass noch ‘bessere’
Bits auf dasselbe Medium geschrieben werden können. Die
mit kurzer Bandlänge gestaltete 60­GB­Kassette wird beim
Beschreiben mit der zweiten Generation zur 100­GB­Kassette
und die 300­GB­Kassette wird zur 500­GB­Kassette. Jaguar 2
schreibt mit einer unglaublichen Datenrate von 100 MB/s
896 Spuren auf die 3592­Kassetten. Aufgrund der extrem
gut erzeugten Streufelder von Bits und Tapemarks konnte
die Streaming­Geschwindigkeit beim High Speed Search auf
10 ms erhöht werden. Das heißt, das Band spult bei einer
File­Anforderung mit 36 km in der Stunde vor. Diese hohe
Geschwindigkeit ist einmalig im Markt und erlaubt trotz hochkapazitiver
Kassetten durchschnittliche Zugriffszeiten von
27 Sekunden (100­GB­Kassette) und 46 Sekunden (500­GB­
Kassette). Auch der Stromverbrauch konnte auf 46 Watt reduziert
werden. Vergleichbare Laufwerke benötigen heute
das Doppelte an Strom.
Auch die einmalige Funktion des Virtual Backhitch wurde
durch die Verwendung eines 512 MB großen Pufferspeichers
(Generation 1 hatte Pufferspeicher) mit 128 MB und durch
zwei eingebaute Control Units weiter optimiert.
Im Vergleich zu LTO bietet die Jaguar­Technologie neben
überschreibbaren Kassetten auch WORM(Write Once Read
Many)­Kassetten an. 3592-WORM-Kassetten sind hochprei­
siger im Vergleich zu LTO3­WORM­Kassetten, bieten aber
neben allen WORM­Sicherheiten den Vorteil, dass das Fortschreiben
immer möglich ist, auch wenn in dem Bereich,
wo fortgeschrieben werden muss, fehlerhafte Spuren oder
Spurbereiche vorkommen sollten. Dies wird dadurch sichergestellt,
dass bei 3592­Kassetten auf den Servobändern
nicht nur die WORM­Kennzeichnung aufgebracht wird, sondern
zusätzlich sogenannte Appendflags, die für die Fehlerkorrektur
herangezogen werden. LTO3­WORM­Kassetten
arbeiten ohne Appendflags, d. h., gibt es beim Fortschreiben
der Kassette fehlerhafte Bereiche, dann lässt sich die
LTO­WORM­Kassette einfach nicht mehr weiterschreiben.
Ende Oktober 2006 kündigte IBM eine neue 700-GB-Kas-
sette für die TS1120­Laufwerke an. Damit stehen jetzt drei
Kassetten (überschreibbar und als WORM) zur Verfügung:
Die 100­GB­Kassette mit 120 Meter Bandlänge, die 500­GB­
Kassette mit 609 Meter Bandlänge und die neue 700­GB­
Kassette mit 825 Meter Bandlänge.
Mit der Markteinführung von LTO im Jahr 2000 kündigte IBM
ein neues Bandarchiv, die IBM 3584, für den unternehmensweiten
Einsatz im Open­Systems­Bereich an. Im Laufe der
Folgejahre wurde die 3584 Library maßgeblich erweitert.
Heute stellt sie die strategische Library-Plattform der IBM
dar. Seit Juni 2005 wird neben den Open­Systems­Plattformen
auch die zSeries (Mainframe) als Serverplattform unterstützt.
Sie machen aus der 3584 ein Bandarchiv, das unternehmensweit
für alle Rechnerplattformen eingesetzt werden kann und
das aufgrund der hohen Leistungsfähigkeit und Flexibilität
alle vergleichbaren Archivprodukte auf dem Markt in den
Schatten stellt.
IBM TS1120(3592 Generation 2)-Bandlaufwerk der Spitzenklasse IBM 3592 WORM-Kassetten in platingrauer Farbe und WORM-Labels
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

IBM 3584 Grundeinheit mit Ein-/Ausgabestation
Auf der CeBIT in Hannover sorgte die 3584 immer wieder
für viele Menschentrauben. Viele können es nicht fassen,
dass es technisch möglich ist, einen Roboter mit dieser
wahnsinnig schnellen Geschwindigkeit zu betreiben. Bei
einer Roboter-Service-Zeit von unter 3 Sekunden in einer
2­Frame­Konfiguration (Kassette holen, in ein Bandlaufwerk
laden, Kassette aus einem anderen Bandlaufwerk entladen
und ins Fach zurückbringen) ist es fast nicht möglich, die bewegten
Kassetten mit dem bloßen Auge zu sichten. Schneller
geht es wirklich nicht mehr!
Diese Geschwindigkeit ist möglich, weil sich ein neu entwi-
ckelter Greifer (IBM Patent) in die LTO­ und 3592­Kassetten
in dort angebrachte Einkerbungen einhakt, die Kassetten in
einen Schacht zieht und der Greifer so lange verhakt bleibt,
bis die Kassetten in ein Laufwerk oder an einen Stellplatz
zurückgebracht werden. Die Kassette kann also auch bei
höchsten Geschwindigkeiten oder schnellsten Drehungen
nicht verloren gehen. Alle Roboterbewegungen sind Servokontrolliert,
um diesen Geschwindigkeiten Rechnung zu tragen.
IBM 3584 Doppelgreifer
In dem 3584 Archiv können sowohl LTO­Laufwerke und
­Kassetten als auch 3592­Laufwerke und ­Kassetten betrieben
werden. Ebenso ist der Mischbetrieb in getrennten Frames
möglich.
Wie schon bei der älteren 3494 Library früher eingeführt,
wurde das System im Frühjahr 2005 so erweitert, dass es mit
zwei Robotersystemen betrieben werden kann, wobei der
zweite Roboter immer im Active Mode betrieben wird. Dabei
werden Zahlen von weit über 1.000 Mounts in der Stunde
erzielt. Des Weiteren kann die 3584 mit zwei Robotersystemen
nahezu unterbrechungsfrei mit Frames erweitert werden (max.
60 Sekunden, wobei kein Roboter Command verloren gehen
kann).
Seit Mai 2005 kann das 3584 Archiv auch an zSeries-Ser-
ver angebunden werden. Dies gilt ausschließlich für den
Betrieb von 3592­Laufwerken und wurde dadurch realisiert,
dass an der 3584 jetzt mehrere Library Manager 3953 L05
und J70 ESCON/FICON Controller betrieben werden können.
Im Gegensatz zur 3494 Library sind die Library Manager
und J70 Controller nicht mehr in die Library Frames integriert,
sondern werden in externen Frames 3953 F05
installiert und an die Library angeschlossen. Dies bietet eine
wesentlich höhere Konfigurationsflexibilität. Die 3584 unterstützt
bis zu vier Library Manager und damit die Anbindung
von bis zu acht Virtual Tape Servern (3494­B10/B20).
Bei VTS­Spiegelungen (Peer to Peer VTS) kann jetzt auf der
primären Seite eine 3494 Library und auf der sekundären
Seite eine 3584 Library oder umgekehrt stehen, d. h., im
VTS­Peer­to­Peer­Spiegel­Betrieb ist der Mischbetrieb beider
Libraries möglich.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
69

70
1999 bis 2005
Die Epoche der Multiplattform-Systeme und des FibreChannel SAN und NAS
Für den Betrieb von Native­Laufwerken an zSeries­Systemen
gibt es fast keine Limitierungen, da in der 3584 bis zu 64 x
J70­Controller mit bis zu 192 Laufwerken konfiguriert werden
können.
Das 3584 Archiv bietet in jeglicher Hinsicht maßgebliche Vorteile
im Vergleich zu herkömmlichen Libraries. Eine Multipfad-Architektur
mit direkter Anbindung von LTO­ und 3592
FibreChannel­Laufwerken ermöglicht das logische Partitionieren
der Library (bis zu 192 Partitionen). Ebenso stehen die
Optionen ‘Control Path Failover’ und ‘Data Path Failover’
zur Verfügung. Mit der Funktion ALMS (Advanced Library
Management System) können die logischen Partitionen
dynamisch vergrößert und verkleinert werden, unabhängig
davon, wo die Laufwerke oder die Kassetten in der Library
untergebracht sind.
Die WWN(World Wide Name)­Adresse ist den Laufwerk­
schlitten zugeordnet und erlaubt einen Laufwerkaustausch,
ohne dass neu ‘gebootet’ werden muss.
Mit der Anbindung der 3584 an zSeries­Server signalisierte
IBM klar, dass die 3584 mit ihrem einzigartigen Robotersystem
die strategische Library­Plattform für zukünftige Weiterentwicklungen
darstellt. Von dieser Weiterentwicklung profitiert
aber auch die 3494 Library, die alle Erweiterungen erhält,
die am Library Manager entwickelt werden. Ebenso wird die
3494 neben der 3584 alle geplanten neuen Laufwerkgenerationen
des 3592­Laufwerks integrieren (SOD vom Mai 2005).
Im Mai 2006 wurde die IBM 3584 im Zuge der Frame­Umstellungen
auf 4-Gbit-FibreChannel-Technologie in TS3500
(TS steht für Tape System) umbenannt und es stehen entsprechende
neue Frames zur Verfügung. Die Library IBM
3584 bzw. TS3500 wird von IBM selbst produziert. Mit der
Umstellung auf 4­Gbit­Technologie wurde auch die RoHS-
Konformität des TS3500 Library­Produktes bekannt gegeben.
Ebenso wurden die bis dahin verwendeten J70-Steuereinheiten,
die für die Anbindung von TS1120­Laufwerken an
den Mainframe benötigt wurden, durch neue RoHS­konforme
leistungsstärkere C06-Steuereinheiten mit 4­Gbit­FICON­
Anschlüssen ersetzt. RoHS steht für ‘Restriction of Hazardous
Substances’ und stellt ab dem 1. Juli 2006 eine gesetzlich
kontrollierte EU­Richtlinie dar, die genau vorschreibt, welche
Materialien, Legierungen, Barium­Derivate etc. in Neuprodukten
eingesetzt werden dürfen. Diese neue Richtlinie gilt
EU­weit und betrifft alle Neuprodukte in der Elektro­ und IT­
Industrie, die ab dem 1. Juli 2006 neu vertrieben werden.
Im mittleren und unteren Systemsegment produzierte IBM
keine eigenen Libraries, sondern kaufte die ‘nackten’ Libraries
über OEM­Verträge ein, um sie dann mit IBM LTO­Laufwerken
auszustatten.
IBM 3583 Modelle L18, L36 und L72, Kapazität mit LTO1-Kassetten bis
7,2 TB (native), ADIC vertrieb unter ADIC Logo das Produkt als Scalar 100
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Mit der Ankündigung der ersten LTO­Laufwerke im Jahr 2000
wurden auch OEM Libraries und Autoloader angekündigt,
die nach dem Umbau/Ausbau als IBM Logo­Produkt weiter­
vertrieben wurden. So wurden 1999 ein Autoloader der Firma
ADIC als IBM 3581­Produkt und ein mittleres Archivsystem
auch von ADIC als IBM 3583 eingeführt. Der Autoloader war
mit einem LTO­SCSI­Laufwerk (LVD oder HVD) ausgestattet
und konnte bis zu acht LTO­Kassetten verwalten. Das Archivsystem
3583 konnte mit sechs LTO­Laufwerken ausgestattet
werden und je nach Modell 18 Kassetten, 36 und 72 Kassetten
verwalten. Am Anfang wurden ausschließlich SCSI­Laufwerke
eingebaut. Um die Library an ein FibreChannel­Netz
anschließen zu können, wurden über ein eingebautes FC­AL
Gateway die bis zu sechs SCSI­Laufwerke ‘daisy chained’
angeschlossen.
Diese FibreChannel­Anschlussweise der IBM 3583 verursachte
bei bestimmten Host­FibreChannel­Adaptern Adressierungsprobleme.
Deshalb wurde im Mai 2003 in der 3583
ein eigener IBM Controller eingebaut, der durch eine Multipfad­Architektur
erlaubte, direkt FC­Laufwerke in der Library
zu betreiben und die Library zu partitionieren. Bis zu drei
logische Partitionen waren in der 3583 möglich.
Im Mai 2004 wurde dieses Midrange­Library­Portfolio ergänzt
durch eine Mini­Library, die IBM 3582. Die Library ist ein
OEM Produkt der Firma ADIC. Sie ist ausgestattet mit dem
IBM Controller für die Anbindung von FC­LTO­Laufwerken
und bietet die Möglichkeit, mit zwei logischen Partitionen
betrieben zu werden.
In die Mini­Library wurden 1 bis 2 LTO­Laufwerke eingebaut
und es konnten bis zu 23 Kassetten verwaltet werden. Neun
Kassetten hatten fest eingebaute Stellplätze, die anderen
14 Stellplätze wurden über zwei herausnehmbare 7er­Kassettenmagazine
abgedeckt.
Im Mai 2006 wurde der OEM­Autoloader von ADIC durch
einen neuen Autoloader der Firma BDT IBM 3581 ersetzt,
der auch bis zu acht Kassetten verwalten konnte, aber in
Flachbauweise konstruiert war und dadurch sehr platzsparend
in ein Standard­19­Zoll­Rack integriert werden konnte.
Auch bei der Midrange­Library­Reihe musste bis 30. Juni
2006 die Umstellung auf die neue, ab 1. Juli 2006 geltende
EU­RoHS­Richtlinie durchgeführt werden.
Die Library 3583 wurde bereits im Oktober 2005 durch eine
neue Library TS3310 ersetzt. Die TS3310 stammt auch aus
dem Haus ADIC, hatte vorbereitete 4­Gbit­Technologie integriert
und war zum Verfügbarkeitszeitraum RoHS-konform.
Am Anfang konnte die Library nur mit der Grundeinheit, einer
Erweiterungseinheit und bis zu sechs LTO3­Laufwerken und
122 Kassettenstellplätzen konfiguriert werden, im Mai 2006
wurden dann die Erweiterungen bis zum Maximalausbau mit
bis zu vier Erweiterungseinheiten und damit bis zu 18 LTO3­
Laufwerken und bis zu 398 Kassettenstellplätzen bekannt
gegeben. IBM verwendet bei dieser neuen Library wiederum
einen eigenen FC­Controller für die Anbindung der Laufwerke.
Damit ist die Library partitionierbar und es können
bis zu 18 logische Partitionen betrieben werden. Die Zuordnung
von Laufwerken und Stellplätzen auf logische Partitionen
ist wesentlich flexibler als beim Vorgänger 3583.
IBM 3581 Modelle L28 und F28, Autoloader der Firma BDT IBM 3582 Mini-Library mit bis zu 23 LTO-Kassetten.
ADIC vertrieb unter ADIC-Logo das Produkt als Scalar 24
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
71

72
1999 bis 2005
Die Epoche der Multiplattform-Systeme und des FibreChannel SAN und NAS
Die neue IBM Midrange Library IBM TS3310 mit bis zu 18 LTO3-Laufwerken
und maximal 398 Kassettenstellplätzen, hier mit einem Erweiterungsframe.
ADIC vertreibt unter ADIC-Logo das Produkt als ADIC 500i
Im Zuge der gesamten RoHS­Umstellung wurde sowohl der
Autoloader von BDT IBM 3581 als auch die Mini­Library von
ADIC IBM 3582 durch neue Produkte der Firma BDT ersetzt.
Die 3581 wurde durch die IBM TS3100 ersetzt, ein neuer
Autoloader mit einem 4­Gbit­Fibre­LTO3­Laufwerk und bis zu
22 Kassettenstellplätzen. Die Mini­Library 3582 wurde durch
die IBM TS3200 ersetzt, die bis zu zwei 4-Gbit-LTO3­Laufwerke
und bis zu 44 Kassetten aufnehmen kann. Die TS3200
besitzt dieselbe Partitioniermöglichkeit wie ihr Vorgänger.
Damit sind alle Library­Produkte und ­Bandlaufwerke, die IBM
vertreibt, durchgängig auf 4-Gbit-Technologie umgestellt
und entsprechen der EU-RoHS­Richtlinie, die am 1. Juli 2006
für Neuprodukte in Kraft getreten ist.
Tape-Virtualisierung im Open-Systems-Umfeld
Tape­Virtualisierung war bisher nur im Mainframe­Umfeld
sinnvoll (siehe VTS Virtual Tape Server). Mit der Zunahme
der Geschwindigkeit und der Datenrate, wurde es immer
schwieriger, die Geschwindigkeit solcher Laufwerke auch
maximal auszunutzen. Ein LTO3­Laufwerk arbeitet heute mit
80 MB/s, ein Jaguar­Laufwerk TS1120 sogar mit 100 MB/s
(native). Um diese hohen Laufwerkgeschwindigkeiten auch
maximal nutzen zu können, werden zunehmend Plattenpuffer
als Zwischenspeicher eingesetzt. Um eine geeignete,
sinnvolle Backup­Konzeption zu etablieren, muss zwischen
dem klassischen Backup über das IP­Netz (LAN-Backup)
und dem LAN-free-Backup, wo die Daten über ein Fibre­
Channel­Netz (SAN) auf die Bandlaufwerke über tragen
werden, unterschieden werden.
Wird der Backup klassisch über das LAN gefahren, ist die
sinnvollste Art einer Virtualisierung, den IBM TSM (Tivoli
Storage Manager) einzusetzen, über den TSM­Server auf
einen Plattenpuffer zu sichern und unter Kontrolle des TSM
vom Plattenpuffer auf Band zu migrieren. Diese Funktionalität
hat der TSM schon seit vielen Jahren. Auf diese Weise
können die hohen Geschwindigkeiten der Laufwerke genutzt
werden. Der Vorteil dieser Lösung liegt in der Automation, weil
man alle Policy­Regeln des TSM entsprechend nutzen kann.
Im LAN­free­Bereich macht eine Virtualisierung dann Sinn,
wenn viele LAN­free­Clients betrieben werden, denn jeder
LAN­free­Client benötigt ein dediziertes Bandlaufwerk. Betreibt
ein Rechenzentrum den Backup mit vielen LAN­free­Clients,
benötigt man dieselbe Anzahl an physikalischen Laufwerken,
und das kann teuer werden. Hier machen virtuelle Bandarchive
Sinn, weil man viele virtuelle Laufwerke zur Verfügung
hat. Um diesem Umstand gerecht zu werden, kündigte IBM
im Oktober 2005 das virtuelle Bandsystem TS7510 für Open­
Systems­Umgebungen an.
IBM TS3200
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Band-Virtualisierung für Open Systems (Virtual Tape Library VTL)
Das virtuelle Bandarchiv TS7510 besteht aus mehreren
wichtigen Komponenten und ist Server­basierend aufgebaut.
Als Server werden xSeries­Rechner mit einem Linux­Kernel
eingesetzt. Die Maschine kann mit einer (Single) oder zwei
xSeries (Dual­Server­Konfiguration) ausgestattet werden. Die
Dual­Server­Konfiguration bietet die Möglichkeit des ‘Active
Failover und Failback’. Die eingesetzten Server stellen die
virtuelle Einheit dar und emulieren virtuelle Bandlaufwerke.
Bis zu 512 virtuelle Laufwerke werden pro Rechnereinheit
emuliert. Bei einer Dual­Server­Konfiguration werden bis zu
1.024 virtuelle Laufwerke emuliert. Abgebildet werden LTO2­,
LTO3­ und 3592(Jaguar 1)­Laufwerke. Es stehen bis zu 128
virtuelle Libraries und bis zu 8.192 virtuelle Volumes zur Verfügung,
also pro Rechnereinheit 64 virtuelle Libraries und
4.096 virtuelle Volumes.
Geschrieben wird in einen Plattenpufferspeicher. Hierzu sind
in dem Gehäuse zwei Platten­Controller und entsprechende
Plattenerweiterungseinschübe auf Basis der DS4000 eingebaut.
Das erste Frame wird mit einem zweiten Frame erweitert,
wenn größere Kapazitäten notwendig werden. Die Minimalkonfiguration
erlaubt 5 TB nutzbaren Plattenplatz und kann
auf die maximale Konfiguration von bis zu 46 TB ausgebaut
werden. Insgesamt stehen acht 2­Gbit­Ports zur Verfügung,
vier für den Plattenzugriff und vier für den Host und die physikalischen
Bandlaufwerke. Spiegelungen der Maschine
können über zwei 1­Gbit­Ethernet­Ports über das IP­Netz
durchgeführt werden (Remote­Replikation). Dabei kann mit
Compression und Encryption als Zusatzoptionen gearbeitet
werden.
Vituelle Tape Library IBM TS7510
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
73

74
1999 bis 2005
Die Epoche der Multiplattform-Systeme und des FibreChannel SAN und NAS
Archivierungslösungen
Archivierung von Informationen ist schon ein sehr altes
Thema, denkt man an die Höhlenmalereien der Grotte Chauvet
im Vallon Pont d’Arc in Südfrankreich, die auf ca. 31.000
Jahre geschätzt werden – die wohl erste Überliefung von
Informationen aus Menschenhand.
Die Techniken, der Nachwelt Informationen zukommen zu
lassen, haben sich seitdem stets verbessert. Zunächst wurden
Information in Stein gemeißelt und in Ton gebrannt, bis die
Ägypter ca. 4.000 Jahre vor unserer Zeit das Papyrus – den
Vorgänger des heutigen Papiers – entdeckten, um in einfacher
Technik, Informationen darauf festzuhalten. Mit fortschreitender
Technik war es nun auch möglich, mehr Informationen
zu speichern und der Nachwelt zu hinterlassen. Denken
wir nur an das Alte Testament, das einen Zeitraum von ca.
2.000 Jahren vor Christi Geburt umfasst und aus insgesamt
zwölf Büchern besteht.
Mit der Erfindung des Buckdrucks durch Johannes Gutenberg
aus Mainz, Mitte des 15. Jahrhunderts, war es dann
auch möglich, Informationen einfach zu vervielfältigen, was
zu vielen interessanten Überlieferungen beigetragen hat und
natürlich auch zum Wachstum an Informationen.
Entwicklung der optischen Technologien in den 90er-Jahren
Bereits 1982 gründeten IBM und Sony eine Entwicklungsallianz
mit dem Ziel, optische Technologien gemeinsam weiter zuentwickeln.
So enstanden im IT­Umfeld Anfang der 90er­
Jahre optische Archivierungsmöglichkeiten, sogenannte ‘Juke’­
Boxen mit optischen Platten und entsprechenden Schreib­/
Lesegeräten, die sich in dieser Zeit auch als Archivierungseinheiten
zur Langzeitarchivierung durchsetzten. Es etablierten
sich drei unterschiedliche optische Medien, die WORM-Platte
(Write Once Read Many), die magneto-optische Platte MO
und die ‘Schein­WORM’­Platte, die sogenannte CCW(Contin
uous Composite WORM)-Platte, eine magneto­optische
Platte, die bei der Herstellung eine Kennzeichnung bekommt,
die sicherstellt, dass das Medium nicht versehentlich überschrieben
wird.
Bereits 1992 begann man, die für die IT­Branche entwickelten
Formate WORM, MO und CCW, basierend auf der Rote­Laser­
Technik, zu standardisieren. Ein ISO­Standardisierungsgremium
bildete sich und selbst der deutsche DIN bildete den
NI23­Arbeitskreis, einen Ausschuss des deutschen DIN zur
Normierung von optischen Datenträgern, der der internationalen
ISO direkt zuarbeitete und seine entsprechende Position
abgab. Die als 1 x Standard verabschiedete ISO­Norm
reflektierte eine 650­GB­Platte in allen drei Formaten, mit dem
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
>
>
>

IBM 3995 optisches Archivierungssystem mit den einzelnen Modellvarianten mit 8 x Standard
2 x Standard kam die 1,3­GB­, mit dem 4 x Standard die
2,6­GB­Platte. 1998 wurde der letzte Standard als 8 x Standard
verabschiedet, der immer noch auf dem roten Laser
basierte. Der 8 x Standard bot auf allen drei Formaten
5,2 GB Kapazität pro Platte.
Um Rückwärtskompatibilität zu gewährleisten, war der Standard
so gestaltet, dass Medien des 1 x Standards sowohl
lese­ als auch schreibmäßig von Schreib­/Lesegeräten des
2 x Standards verarbeitet werden konnten und selbst der
4 x Standard noch in der Lage war, Medien des 1 x Standards
zu lesen. Mit dem 8 x Standard kam der Bruch, da nicht mehr
vorgesehen war, Medien des 1 x Standards auf Schreib­/
Lesegeräten des 8 x Standards verarbeiten zu können.
Mitte der 90er­Jahre wurde die WORM­Platte – vom Gesetz­
geber anerkannt für viele Archivierungsanforderungen – mit
einer Haltbarkeit von 300 Jahren spezifiziert. Viele Unternehmen
gingen dazu über, Langzeitarchivierung auf diesen
optischen Juke­Boxen zu betreiben. IBM bot auf diesem
Gebiet das IBM 3995 optische Archivsystem an.
Nach der Verabschiedung des 8 x Standards passierte viele
Jahre nichts mehr bezüglich einer sinnvollen Standardisierung.
Dies lag darin begründet, dass ein 16 x Standard technisch
nicht realisierbar war, da der rote Laser in diesem Bereich
eine Streuung zeigte, die es nicht zuließ, auf einem nach
8 x Standard erzeugten Pit durch Optimierung der Laserfrequenz
4 Pits unterzubringen. Auch trug der technologische
Wechsel zur Blaue­Laser­Technik (auch ‘Blue Ray’ genannt)
dazu bei, dass ein noch realisierbarer Standard in Rote­
Laser­Technik als 12 x Standard nicht weiterverfolgt wurde.
Hier noch ein wichtiger Hinweis, der zeigt, wie tief IBM in
der Entwicklung von optischen Technologien engagiert war.
Der heutige blaue Laser ist ein IBM Patent, das aus einer
gemeinsamen Entwicklung von IBM und Sony hervorging.
Im Jahr 2000 ergab sich in Deutschland eine massive Ände­
rung für die Langzeitarchivierung. Die GDPdU­Richtlinie
wurde verabschiedet und im Jahr 2001 nochmals genauer
verifiziert. Diese Richtlinie nahm Abschied von der Vorgabe,
bei bestimmten aufzubewahrenden Daten optische WORM­
Medien zu verwenden. Damit war der Weg frei, neue Lösungskonzeptionen
zu entwickeln, die nicht unbedingt auf optischen
Technologien aufgebaut sind.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
75

76
1999 bis 2005
Die Epoche der Multiplattform-Systeme und des FibreChannel SAN und NAS
Wenn die Archivierung gesetzlichen Bestimmungen und
Anforderungen unterliegt, spricht man auch von revisionssicherer
Archivierung. In vielen Bereichen erkennt der Gesetzgeber
die digitale Archivierung als revisionssicher an, stellt
aber gleichzeitig auch Anforderungen an die Art und Weise
der Archivierung. In Deutschland gibt es z. B. die Grundsätze
zum Datenzugriff und zur Prüfbarkeit digitaler
Unterlagen (GDPdU). Viele Gesetze und Bestimmungen
stellen allgemeine Anforderungen an die revisionssichere
Archivierung. Zumeist werden die Aufbewahrungszeiträume
von archivierten Daten vorgeschrieben. Weiterhin muss
sichergestellt sein, dass die Daten im digitalen Archiv nicht
verändert oder gelöscht werden können – in einer Welt mit
zwei bis drei neuen Computerviren pro Tag gar keine so
einfache Sache. Einige Bestimmungen schreiben auch vor,
Kopien der Originaldaten in getrennten Räumen zu erstellen.
Revisionssicherheit bedeutet natürlich auch, dass die Integrität
der Daten zu jeder Zeit nachweislich gewährleistet ist.
Es muss also auch anhand von Protokollen nachgewiesen
werden, dass die Daten dem Original entsprechen. Die eingesetzte
Technologie zur Archivierung wird aber heute von
fast keinem Gesetz oder einer Bestimmung vorgeschrieben.
In einigen Fällen, z. B. im medizinischen und pharmazeu­
tischen Bereich, müssen Daten 30 Jahre und länger archi­
viert werden. Eine Frage, die sich daraus ergibt, ist: Gibt es
ein digitales Archiv, das auch in 30 Jahren noch Bestand
hat? Eine zeitgemäße Antwort darauf ist, dass die Informationen
von Zeit zu Zeit auf neue Systeme und Technologien
überführt werden müssen. Überführung von Informationen
und informationsverarbeitenden Systemen auf neue Systeme
und Technologien – nachfolgend auch Migration genannt –
ist heutzutage der einzige Weg, um die Daten auch in 30
Jahren noch lesen zu können.
Aufgrund der veränderten Bedingungen für die Langzeitarchivierung
kündigte IBM das System DR450 im Oktober 2003
an. Das System wurde mit Standardkomponenten aufgebaut
und als Langzeitarchivierungslösung für den Open­Systems­
Bereich zur Verfügung gestellt. Die Lösung bestand aus
zwei pSeries­p615­Servern, die in einem hochverfügbaren
HACMP­Cluster (AIX­Betriebssystem) zusammengefasst waren.
Auf diesen Servern war der IBM Tivoli Storage Manager für
Data Retention aufgesetzt, der sicherstellte, dass die archivierten
Dateien und Dokumente innerhalb der Aufbewahrungsfrist
nicht gelöscht oder modifiziert werden. Die Daten
wurden auf SATA­Platten (siehe auch Technologie­Anhang)
einer FAStT600 mit EXP100­Erweiterungseinheiten abgespeichert.
Kapazitäten von 3,5 TB bis 56 TB konnten konfiguriert
werden. Das Magnetplattensystem war über ein
redundant ausgelegtes, FibreChannel­basierendes SAN an
die Server angeschlossen. Optional konnten an diesem SAN
auch IBM 3592 Bandlaufwerke mit entsprechenden WORM­
Kassetten und/oder überschreibbaren Kassetten betrieben
werden.
Bereits im Jahr 2005 kam die Weiterentwicklung der
DR450 mit der DR550 auf den Markt, die im Jahr 2006 mit
allen seinen Komponenten auf RoHS­Konformität umgestellt
wurde.
Das IBM DR550­System besteht heute aus den IBM Standard­
Software­ und Hardware­Komponenten AIX, SSAM, pSeries
p52A, den SAN­Komponenten 2005­B16, Disk System DS4700
und Disk­Erweiterungseinheiten EXP810. Optional kann man
ein hochverfügbares DR550­System bestellen. Dabei beinhaltet
das System zusätzlich noch die Cluster­Software HACMP.
Der Vorteil dieses Konzepts liegt auf der Hand: Der Anwender
erhält ein System, dessen Komponenten schon lange im
Markt erprobt sind. Kernkomponente von DR550 ist der
System Storage Archive Manager, ein Derivat vom Tivoli Storage
Manager for Data Retention, der jegliche Veränderung
oder Löschung von Informationen verhindert und somit die
revi sionssichere Speicherung erlaubt.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

In der Produktfamilie IBM System Storage DR550 gibt
es drei Modelle:
•
•
•
Das DR550-Express-System ist eine Einstiegslösung, die
aus einer IBM pSeries Model 52A besteht mit internen
SCSI-Festplatten, die als RAID5 konfiguriert sind. Mit dem
DR550 Express Model wird ein Monitor-Kit mit Keyboard
und Maus geliefert sowie ein SAN Switch 2005-B16, der für
den Anschluss von Tape oder einer Disk-Erwei terungseinheit
vorgesehen ist. Ein DR550-Express-System erhält
man mit einer Einstiegskapazität von 1,1 TB (brutto). Das
System kann um 4 TB oder 8 TB (brutto) erweitert werden,
durch den Anschluss eines DS4700-RAID5-Systems. Ein
entsprechender Einbauschrank kann optional mitbestellt
werden.
Das DR550-Single-Node-System besteht aus einem Einbauschrank,
in dem eine IBM pSeries p52A, ein SAN Switch
2005-B16, ein Disk System DS4700 und optional ein oder
mehrere EXP810 eingebaut und fertig konfiguriert sind. Ein
Single-Node-System kann man mit einer Festplatten-
Kapa zität von 8 TB oder 16 TB bestellen und bis auf
112 TB (brutto) ausbauen.
Das DR550-Dual-Node-System besteht aus den gleichen
Komponenten wie das Single-Node-System, mit dem
Unterschied, dass alle Komponenten redundant (doppelt)
ausgelegt sind. D. h., in den Einbauschrank sind zwei IBM
p52A und zwei SAN Switches 2005-B16 eingebaut und
redundant konfiguriert. Ein Dual-Node-System kann man
mit einer Festplatten-Kapazität von 8 TB oder 16 TB bestellen
und bis auf 112 TB (brutto) ausbauen. Es handelt sich
hierbei um ein hochverfügbares System.
Die Informationen werden innerhalb der DR550 auf Festplatten
gespeichert – optional auch verschlüsselt – und erlauben
schnelle Zugriffzeiten. Die Performance aus Anwendersicht
kann mithilfe der Multiobjekt­Transaktion noch gesteigert
werden, insbesondere, wenn viele Objekte mit einem Male
gelesen oder geschrieben werden. Dabei werden innerhalb
einer Transaktion mehrere Objekte gespeichert oder gelesen.
Mandantenfähigkeit lässt sich mit SSAM auch realisieren. Das
erlaubt die logische Trennung von Speicherbereichen für
verschiedene Klienten und auch das Reporting von benutzter
Speicherkapazität. Dabei ist sichergestellt, dass ein Klient nur
auf die Daten zugreifen kann, die in seiner Partition gespeichert
sind.
IBM DR550 Express
Die Anbindung des Archivsystems IBM DR550 an die Anwendung
erfolgt über das Tivoli Storage Manager for Data Retention
API (Application Programming Interface). Typische Anwendungen,
die Daten auf einem DR550­System zu archivieren,
sind Dokumenten­Management­Systeme, wie z. B. IBM Content
Manager oder Enterprise­Content­Management­Systeme,
wie z. B. Opentext Lifelink Enterprise Archive Server. Das TSM
API steht dem Anwender frei zur Verfügung. Alle Anwendungen,
die das TSM API implementiert haben – gleichgültig
auf welcher Plattform diese Anwendung betrieben wird – können
Datenobjekte auf der DR550 archivieren und lesen.
IBM DR550-Dual-Node-System
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
77

1999 bis 2005
Die Epoche der Multiplattform-Systeme und des FibreChannel SAN und NAS
DR550 File System Gateway
Im Mai 2007 kündigte die IBM für die DR550 ein File Sys-
tem Gateway an. Über das DR550 Gateway kann ein Dateisystem
aufgebaut werden, in dem die Daten vor dem Überschreiben
geschützt sind. Das Gateway wird vorkonfiguriert
ausgeliefert. Nach außen wird ein CIFS­ oder NFS­Dateisystem
ausgegeben. Die Gateways können ‘geclusteret’ werden,
um eine HA­fähige (High Availability) Lösung aufzubauen.
Im August 2007 stellte IBM der DR550 750-GB-SATA-Plat-
ten zur Verfügung. Mit diesen neuen großen Platten kann
eine DR550 auf bis zu 168 TB Kapazität ausgebaut werden.
Seit August 2007 stehen mit der DR550 Komplettlösungs-
pakete für die E-Mail-Archivierung zur Verfügung. Diese
Komplettlösungen für Lotus Domino und Microsoft Exchange
adressieren die Anforderungen kleinerer und mittelständischer
Unternehmen. Das Lösungspaket aus einer Hand enthält
aufeinander abgestimmte, skalierbare Software­ und Hardware­Komponenten
der IBM und kann rasch implementiert
werden. Basierend auf unternehmensspezifischen Aufbewahrungs­
und Zugriffsprofilen, ermöglicht die Lösung eine
sichere Verwaltung und Archivierung von E­Mails einschließlich
Dateianhängen in deren gesamten Lebenszyklus. Dabei
wird sowohl geschäftlichen Anforderungen als auch nationalen
oder internationalen Compliance­Vorschriften Rechnung
getragen und ebenso den Wünschen vieler Unternehmen
nach einer Optimierung des Speicherbedarfs und der
Reduzierung von Administrationskosten. Das Komplettpaket
zur E­Mail­Archivierung für den SMB­Bereich (Small and
Medium Business) ist jederzeit zu einer umfassenden Archivierungslösung
erweiterbar, die sämtliche unstrukturierten
Unternehmensinformationen wie z. B. digitalisierte Korres­
pondenz, Office­Dokumente, Faxe, Präsentationen,
Audio­ und Videodateien etc. verwalten kann. Ebenso ist
eine Anbindung an SAP zur Dokumenten­ und Datenarchivierung
möglich. Auf diese Weise kombiniert das Komplettpaket
modernste Technologie mit einem raschen ROI sowie
höchster Investitions­ und Zukunftssicherheit.
Das Komplettpaket besteht aus der benutzerfreundlichen und
leistungsfähigen E­Mail­Archivierungslösung IBM Common­
Store für Lotus Domino und Microsoft Exchange sowie dem
IBM Content Manager als Basis­Repository. Hinzu kommt ein
IBM System x3650 Server mit Intel Xeon Quadcore­Prozessoren,
der speziell für anspruchsvolle Aufgaben im Unternehmenseinsatz
wie z. B. Enterprise Content Management
(ECM), Virtualisierung, Enterprise Resource Planning (ERP)
oder Datenbankanwendungen entwickelt wurde. Als Speicherkomponente
dient das IBM System Storage DR550, das
eine leistungsfähige Funktionalität zur Ablage relevanter
Dokumente gemäß gesetzlicher Aufbewahrungsfristen und
­vorschriften auf magnetischen Speichermedien bietet. Die
DR550 unterstützt dabei eine nicht löschbare und nicht wieder
beschreibbare Datenspeicherung.
Im Februar 2008 machte IBM die DR550-Lösung als
Maschine mit zwei Modellen DR1 und DR2 in der Version 4.5
verfügbar. Dies zeigt deutlich, dass IBM stark in das Infor­
mation­Retention­Segment investiert. Durch die erweiterte
Nutzung des System Storage Archive Managers (SSAM) für
policy­basierten Information­Retention­Betrieb ermöglicht
die DR550 eine transparente und automatisierte Bewegung
archivierter Daten zwischen verschiedenen Speicherklassen.
Dadurch können Kosten eingespart werden, ohne die
Sicherheit der archivierten Daten zu gefährden. Das inzwischen
preisgekrönte System ist jetzt als Maschine verfügbar.
Es stehen zwei Modelle zur Verfügung: Die DR1 besteht aus
einem 25U­Einheiten großen Rack, ist vorintegriert und eignet
sich besonders für mittelständische Kunden. Die DR2
wurde speziell für Großunternehmen entwickelt und ist in
einem größeren 36U­Einheiten­Rack untergebracht. Die DR2
bietet Single­ oder Dual­Node­Konfigurationsoptionen für
höhere Verfügbarkeit und Skalierbarkeit.
78 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang Software Anhang

Die physikalische Anbindung der DR550 an die Serversysteme
erfolgt über Ethernet­Schnittstellen und basiert auf
dem TCPIP­Protokoll. Standardmäßig wird ein Ethernet Interface
benutzt. Wahlweise können aber auch 2 oder mehr
Ethernet Interfaces angeschlossen werden, was eine Skalierbarkeit
des Datendurchsatzes erlaubt.
Das TSM API im Zusammenwirken mit SSAM bietet der Anwendung
verschiedene Möglichkeiten zur Kontrolle der Aufbewahrungszeit.
So kann eine Anwendung unter Benutzung
der Ereignis­basierenden Aufbewahrungsregel Datenobjekte
mittels Event löschen. Natürlich nur unter der Bedingung,
dass die konfigurierbare Mindestaufbewahrungszeit für das
Datenobjekt bereits abgelaufen ist. Mithilfe der chronologischen
Aufbewahrungsregel sorgt SSAM für die Löschung
der Daten nach Ablauf einer festgelegten Aufbewahrungszeit.
Die Aufbewahrungsregeln werden dabei in sogenannten
Management­Klassen definiert, die Anwendung weist ein
Objekt dann nur noch einer Management­Klasse zu, wodurch
dem Objekt die entsprechende Aufbewahrungszeit zugeordnet
wird. Mit dem zusätzlichen Löschschutz, einer weiteren
Option des TSM API, kann die vordefinierte Aufbewahrungsregel
für Objekte außer Kraft gesetzt werden. Damit kann
verhindert werden, dass ein Objekt nach Ablauf der normalen
Aufbewahrungsfrist gelöscht wird.
Die DR550 bietet auch den Anschluss anderer externer
Speichertechnologien wie z. B. WORM Tape oder optische
Speicher. Generell wird empfohlen, dass ein externes Gerät
eine Native­WORM­Funktionalität besitzt, wenn es an ein
DR550­System angeschlossen wird.
Der Anschluss von Bandlaufwerken an die DR550 erfolgt
über das SAN. Die Anbindung von WORM Tape hat zwei
entscheidende Vorteile für den Anwender:
1. Kopien der Daten können auf WORM Tape geschrieben
werden und in einem anderen Brandabschnitt
katastrophen sicher aufbewahrt werden.
2.
Wenn die Daten auf Festplatte in der DR550 ‘altern’ und
somit die Zugriffe seltener werden, können sie auf WORM
Tape ausgelagert werden. Die Tapes benötigen weniger
Strom, Wartung und Austausch und sind somit viel kostengünstiger
als Festplatten.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang Software Anhang 79

80
1999 bis 2005
Die Epoche der Multiplattform-Systeme und des FibreChannel SAN und NAS
Modell 174
IBM 3996 optische Archive – 960 GB bis 10,4 TB
Im Herbst 2003 wurde endlich ein neuer Standard, basierend
auf dem blauen Laser, auf dem Markt verfügbar. Der neue
1 x Standard reflektierte eine 30­GB­Platte in den bisher
klas sischen Formaten WORM, MO und CCW. Die Firma Plasmon,
die auch sehr aktiv in der Standardisierung der neuen
Blaue­Laser­Technik mitwirkte, bot als erste Firma im Jahr
2004 Juke­Boxen mit den neuen optischen Platten an. Im
Herbst 2005 kam ein OEM-Vertrag zwischen Plasmon und
IBM zustande, der es IBM erlaubt, diese Juke­Boxen unter
IBM Logo zu vermarkten. Am Anfang war der Verkauf zum
Anschluss an iSeries­Server beschränkt, seit Juni 2006 können
die Juke­Boxen auch an pSeries­basierende Server
angeschlossen werden. Mit den Modellen 32, 80 und 174
bietet die IBM 3996 Kapazitäten von 960 GB bis 5,2 TB an.
Im August 2007 kündigte IBM für die 3996 optischen Archivsysteme
die Verwendung der neuen optischen Platten mit
60 GB in den Formaten WORM, MO und CCW an. Die neue
Plattengeneration reflektiert den 2 x Standard, basierend auf
der blauen Laser­Technologie. Damit skaliert die IBM 3996
auf eine Kapazität von bis zu 10,4 TB. Die kapazitiven Möglichkeiten
liegen also deutlich unter den Möglichkeiten einer
DR550.
Modell 80 Modell 32
Es bleibt abzuwarten, ob – basierend auf der Blaue­Laser­
Technik – ein klassischer optischer 4 x Standard verabschiedet
wird, da inzwischen andere Lösungsoptionen für die Langzeitarchivierung
auf dem Markt etabliert sind.
Hinzu kommt noch die Tatsache, dass, ebenfalls auf Blaue­
Laser­Technik basierend, der Standard der ersten holografischen
Platte mit einer Kapazität von 150 GB im XY­Format
im Jahr 2003 verabschiedet wurde, Anfang 2005 bereits
der 2 x Standard mit einer 500­GB­Platte und Ende 2005
ein 2 x Standard als Zusatzstandard für die ‘Consumer’­
Industrie in Form einer 300­GB­Platte. Holografische CDs
und CD­ROMs lassen sich aufgrund der verwendeten Polymerbeschichtung
(Kunststoff) wesentlich kostengünstiger
produzieren als z. B. klassische DVDs oder im IT­Umfeld
verwendete WORM­, MO­ oder CCW­Platten.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Neue NAS-Produkte
Das Jahr 2005 war durch eine weitere Überraschung geprägt.
Am 4. April 2005 wurde eine enge Kooperation und Allianz
zwischen IBM und der Firma Network Appliance bekannt
gegeben. Diese Allianz ermöglicht IBM, alle NetApp­Produkte
als IBM Logo­Produkte zu vertreiben. Da IBM bisher auf dem
Gebiet des NAS (Network Attached Storage) nur begrenzt
aktiv war, ermöglicht diese Partnerschaft IBM, auf dem Gebiet
des ‘File­Servings’ ein breites Storage­Lösungsportfolio anzubieten.
Am Anfang waren nur die kleinen NetApp­Geräte
unter IBM Logo verfügbar, seit Ende 2005 die Geräte mittlerer
Leistungsklasse, seit Juni 2006 entsprechende Gateways und
seit August 2006 die Hochleistungsgeräte und damit nahezu
die gesamte Produktpalette von NetApp.
IBM Nseries N5000 und Nseries N7000
Die IBM Nseries bietet Antworten auf die Fragen der Vereinfachung
der Storage­Infrastrukturen und des zentralen
Datenmanagements, des Backups der Daten und deren einfachster
Wiederherstellung.
IBM läutet mit der Nserie die Konvergenz der Speicherwelten
ein. Stand NAS für ‘Einfachheit’ und Funktionsvielfalt, so
wurden beim Thema SAN Argumente wie High Performance,
Skalierung und Ausfallsicherheit genannt. Mit der Nseries
werden nun diese Unterschiede aufgehoben.
Es stehen dabei generell zwei Modelltypen zur Verfügung.
Systeme mit internen Diskdrives (Filer) und Systeme, die
externe SAN­Disk­Ressourcen verwenden, die sogenannten
NAS­Gateways.
Die Skalierung der beiden Systemreihen reicht von Entryüber
Midrange­ hin zu Enterprise­Storage­Kapazitäten und
Anschlussmöglichkeiten. Als herausragendes Merkmal sei
erwähnt, dass alle Systeme dasselbe Betriebssystem Data
ONTAP nutzen.
Die Nseries­Produkte bieten eine große Möglichkeit, Server
im Netzwerk mit ihren spezifischen Zugriffsprotokollen anzuschließen.
Diese umfassen die NAS­File­I/O­Protokolle (CIFS,
NFS) sowie die Block­I/O­Protokolle iSCSI und FCP.
Die Nseries bietet eine enorme Flexibilität in Bezug auf die
Ausbaustufen und die Möglichkeit, verschiedene Disk­Technologien
für die jeweilige Lösung zusammenzustellen. Fiber­
Channel Diskdrives und SATA Diskdrives können gemischt
werden.
Eine Nseries, bestückt mit FibreChannel Disks, kann so für
ein Mission­Critical­, High­Performance­ und Transaktionsorientiertes
Umfeld eingesetzt werden. Nseries, bestückt mit
SATA Diskdrives, kann die ideale Wahl für Kunden sein, die
eine Disk­to­Disk­Backup­Möglichkeit suchen oder sich für
Archivierung interessieren.
Alle Nseries­Systeme nutzen ein einziges Betriebssystem mit
einer enormen Vielfalt von weiteren, zusätzlichen SW­Optionen,
angefangen vom Storage­ und System­Management,
über Inbound­ und Outbound­Copy­Services bis hin zur
kompletten D/R­Lösung mit integrierten Backup­Funktionen.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
81

82
1999 bis 2005
Die Epoche der Multiplattform-Systeme und des FibreChannel SAN und NAS
IBM N3700
Da das Thema ‘gesetzeskonforme Archivierung’ einen immer
wichtigeren Stellenwert einnimmt, bietet die Nseries WORM­
Funktionen an. Damit können Daten als nicht ‘lösch­/veränder
bar’ abgespeichert werden, um den entsprechenden
Richt linien Rechnung zu tragen. Es können bestimmte
Speicher bereiche im System oder auch die gesamte Nseries
einfach als ‘WORM’­Bereiche definiert werden. Eine breite
Unterstützung der namhaften Application­Management­SW­
Hersteller ist gegeben.
Die Nseries bietet SW­Funktionen an, die dem Systemadministrator
das Management seiner Microsoft­Exchange­, Microsoft­SQL­,
IBM DB2­ und Oracle­Datenbanken erleichtern. Mit
255 SnapShots (Point­in­Time­Kopien) können Applikationen
bei Fehlern leicht wiederhergestellt werden. Ein patentierter
RAID­DP­Algorithmus sorgt für hohe Datenverfügbarkeit und
schützt vor dem Datenverlust bei Ausfall von zwei Platten in
einer RAID­Gruppe. Dies ist vor allem beim Einsatz von SATA­
Platten sinnvoll.
Das Einstiegssystem N3700 bietet eine Kapazität von bis
zu 16 TB, die mittleren Systeme N5200 bis zu 84 TB (bis zu
168 LUNs) und N5500 bis zu 168 TB (bis zu 336 LUNs).
Wahlweise können Platten mit 72 GB, 144 GB und 300 GB
konfiguriert werden. Bei den mittleren Systemen werden zwei
2,8­GHz­Xeon­Prozessoren verwendet. Der sogenannte ‘Kopf’
der Filer (der Begriff hat sich für den Controller der Appliance­
Lösung eingebürgert) ist bei den mittleren Systemen auch
als Gateway verfügbar und bedient sich der verfügbaren
Plattenkapazitäten in einem SAN.
Die Hochleistungssysteme Nseries 7000 bestehen aus der
N7600, die kapazitiv bis 420 TB (bis zu 672 LUNs) skaliert,
und der N7800, die auf bis 504 TB (bis zu 672 LUNs) ausgebaut
werden kann. Bei der N7600 werden vier 2,6­GHz­AMD­
Opteron­Prozessoren, bei der N7800 acht 2,8­GHz­AMD­
Opteron­Prozessoren verwendet. Bei beiden Hochleistungs ­
systemen können neben den anderen Platten auch 500­GB­
SATA­Platten eingebaut werden. Auch die ‘Köpfe’ der Hochleistungssysteme
sind als Gateways verfügbar.
Um das Portfolio der Nseries­Produkte zwischen N5000 und
N7000 in der Skalierbarkeit abzurunden, kündigte IBM im
November 2006 das Modell N5600 als neues leistungsstärkstes
Modell der N5000­Reihe mit einer Verfügbarkeit ab
dem 8. Dezember 2006 an. Die N5600 bietet auf Basis
einer 64­bit­Architektur Kapazitäten von bis zu 252 TB und
eine 30 – 40 % höhere Leistung im Vergleich zur N5500 und
schließt damit die Lücke zwischen N5500 und N7600.
Als Ergänzung der N5600 Appliance kündigte IBM im Mai
2007 das NAS Gateway N5600 an. Zum selben Zeitpunkt, mit
Verfügbarkeit im Juni 2007, wird die Nseries­Reihe durch
die neuen Modelle N5300 und das NAS Gateway N5300
ergänzt. Die N5300 integriert eine 64­Bit­Maschine und skaliert
kapazitiv auf bis zu 126 TB. Das Gateway ist durch die
64­Bit­Maschine bestens für 4­Gbit­SANs geeignet. Im
August 2007 kommen zwei neue Einstiegssysteme hinzu,
das Entrysystem N3300, das bis auf 24 TB Kapazität ausbaubar
ist, und die N3600, die auf bis zu 69 TB Kapazität ausgebaut
werden kann. Die alte N5500 und das N5500 Gateway
wurde im Oktober 2007 vom Vertrieb zurückgezogen.
Im Oktober 2007 wird den Nseries­Produkten eine neue
Management Software, der Virtual File Manager VFM zur
Verfügung gestellt. Dieses Software­Produkt wurde von der
Firma Brocade entwickelt und bietet die Möglichkeit der
File­Virtualisierung.
Im Februar 2008 kündigte IBM eine neue Generation der
Nseries für große Rechenzentrumsbetriebe an.
Die nächste Generation der N7000series ist sowohl als Appliance
als auch als Gateway verfügbar. Die neuen Modelle
N7700 und N7900 ermöglichen eine höhere Skalierbarkeit
für den Rechenzentrumsbetrieb in großem Maßstab. Die
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

neuen Systeme bieten eine Skalierbarkeit mit bis zu 1.176 TB
Kapazitätsunterstützung für speicherintensive Anforderungen
in Rechenzentren. Die N7000series ermöglicht es IT­Betreibern,
SAN­ und NAS­Speicheranforderungen auf einem einzigen
System zu konsolidieren.
Für die Entry­Systeme stehen neue Plattenlaufwerke zur Ver­
fügung. Für die N3300 und N3600 werden nun auch SATA­
oder SAS­Laufwerke im Controller unterstützt. Die N3300
verfügt über eine erweiterte Skalierbarkeit von bis zu 68 TB
und die N3600 von bis zu 104 TB. Zusätzlich wurde bei folgenden
Modellen die Kapazität aufgestockt: N5300 (von
168 auf 336 TB), N5600 (von 252 auf 504 TB), N7600 (von
420 auf 840 TB) und N7800 (von 504 auf 1.008 TB). Der
SnapManager für Office SharePoint­Server von Microsoft ist
jetzt auf allen Systemen der Nseries verfügbar.
Im August 2008 kündigt IBM die neuen Nseries­Systeme
N6040 und N6070 an. Die N6040 bietet Kapazitäten von bis
zu 420 TB und die N6070 von bis zu 840 TB. Die N6000­
Reihe wird im Februar 2009 durch das Modell N6060
ergänzt, das eine Kapazität von bis zu 672 TB bietet. Im
gleichen Zuge werden im Oktober 2008 mit Wirkung vom
Februar 2009 die Systeme N5200, N5300 und N5600 von
Marketing zurückgezogen. Im Vergleich zur N5000­Reihe
bietet die N6000­Reihe 1,4­fach bis 2­fach höhere Leistungsfähigkeit,
weil sie auf moderner Hardware basieren und
mehr Cache besitzen. Auch haben die N6000­Systeme die
Möglichkeit, mit neueren Betriebssystemständen auf Basis
von Data ONTAP zu arbeiten.
Nseries unterstützt eine Vielzahl von Servern und Betriebssystemen
via FCP, CIFS, NFS und iSCSI. Die angeschlossenen
Platten­Arrays können in RAID4 oder RAID­DP (Double Parity),
das dem RAID6­Level entspricht, konfiguriert werden.
Mit der Nseries­Familie stellt die IBM maßgeschneiderte
Plattenspeicherlösungen im Filer­ und NAS­Umfeld zur
Verfügung.
Es stehen für die IBM Nseries zurzeit 40 verschiedene SW­
Funktionen zur Verfügung. Im Anhang sind die wichtigsten
beschrieben.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
83

84
1999 bis 2005
Die Epoche der Multiplattform-Systeme und des FibreChannel SAN und NAS
SnapShot
SnapShots sind lesbare, konsistente Sofort­Kopien (Point­in­
Time Copy) eines Datenbestandes, genauer eines Files oder
einer LUN. Es können bis zu 255 SnapShots pro File/LUN
erzeugt werden. Das Besondere daran ist, dass sie platzsparend
sind, d. h., dass sie beim Erzeugen keinen zusätzlichen
Plattenplatz benötigen. Dies geschieht dadurch, dass
nur der Verweis auf die Daten (Pointer) gespeichert wird.
SnapShots können manuell angestoßen oder auch automatisiert
prozessiert werden – so können z. B. alle 5 Minuten
Point­in­Time­Kopien erzeugt werden. Durch die hohe Anzahl
der SnapShots (255) ist damit ein sehr granulares und zeitnahes
Backup/Recovery möglich. Da SnapShots in einem
speziellen Verzeichnis abgelegt werden, ist es auch für den
User selbst sehr einfach (per Drag&Drop) seine gelöschten
Dateien selbst wiederherzustellen.
SnapRestore
SnapRestore nutzt die zeitnahen SnapShot­Kopien, um eine
File, ein File­System oder eine LUN wiederherzustellen. Sind
SnapShots nur lesbare Kopien und müssen für die Wiederherstellung
der Daten in das aktive Filesystem kopiert werden,
kann mit SnapRestore sehr leicht das aktive Filesystem auf
eine SnapShot­Kopie aufgesetzt werden. Dies bedeutet, dass
für eine Datenwiederherstellung keine Daten umherkopiert
werden. Ein solches Restoring geht mit einem einzelnen Kommando
sehr schnell vonstatten! Eine 300 GB große Datenbank
kann mit dieser Technik in ca. 2 bis 3 Minuten restored werden.
SnapManager
SnapManager wurde speziell für Datenbanken (Oracle und
MS SQL) und Mail­Applikationen (MS Exchange) entwickelt.
Basierend auf SnapRestore bietet der SnapManager ein
hochintegratives SW­Paket für den Systemadministrator.
Statt aufwendiger Scripts kann er hiermit per GUI einfache
Backup­Tasks aufsetzen, Restoring­Prozesse anstoßen oder
per ‘Klick’ Datenbank­Clones für Testzwecke erzeugen. Es
besteht sogar die Möglichkeit, einzelne Mailboxen (mit Kalendereinträgen,
Kontakten, Attachments) für das MS Exchange­
Umfeld nach einem Fehlerfall einfach wiederherzustellen.
SnapMirror
Sind SnapShot und SnapRestore Backup/Recovery­Funktionen,
ist mit SnapMirror eine Funktion entwickelt worden,
die für die Spiegelung der Daten von einer Nseries auf eine
andere Nseries eine D/R Funktion liefert. SnapMirror spiegelt
Daten – vereinfacht gesagt – synchron oder asynchron über
SAN oder LAN auf eine Disaster­Recovery Site. Bei Ausfall
der Produktiv­Seite stehen die Daten trotz Ausfalls zur Verfügung.
Ist die Produktiv­Seite wieder operational, werden die
Daten von der DR­Seite wieder zurückkopiert.
SnapVault und SnapLock
SnapVault und SnapLock sind Lösungen für das Backup und
die Archivierung von Daten. SnapVault ermöglicht ein Backup
einer Nseries auf eine andere (oder von vielen auf eine).
Durch den Einsatz von günstigen SATA Disks kann auf das
Backup system schnell und kostengünstig gesichert werden.
Da ein Restoring von Disk erfolgt, sind die Daten auch schnell
wiederherstellbar. SnapLock bietet die Möglichkeit, die
gesamte Nseries oder einen Teil der Disks als WORM­Bereich
(Write Once Read Many) zu nutzen. Daten, die hier abgelegt
werden, können erst nach dem Ablauf des Aufbewahrungsdatums
gelöscht und/oder verändert werden.
Open System SnapVault (OSSV)
OSSV verhält sich wie SnapVault mit dem Unterschied, dass
die OSSV (Open System SnapVault) Software­Server sichern
und wiederherstellen kann. Hierfür muss die OSSV SW auf
den Server (Open, d. h. Unix und Windows) installiert werden.
Die Server sichern dann auf eine Nseries als Backupsystem.
Cluster Failover
Cluster Failover (CFO) ist eine Standardkomponente bei
jedem Dual­Controller (A20 oder G20) der Nseries. Bei Ausfall
eines Controllers übernimmt automatisch der zweite
Controller die Server­I/Os und der Datenzugriff bleibt erhalten.
MetroCluster
Erweitert man die Cluster­Failover­Funktion (CFO) über
Gebäudegrenzen hinweg, erhält man den MetroCluster.
Der MetroCluster repliziert die Daten vom Controller 1 des
primären RZs zum Controller 2 des sekundären RZs und
garantiert Datenkonsistenz und deren Verfügbarkeit. Fällt die
primäre Site aus, erlaubt MetroCluster einen Failover mit einem
einzigen Befehl des Administrators. MetroCluster ist im Gegensatz
zu SnapMirror keine DR­, sondern eine Business Continuity­Lösung.
Basierend auf dem Design, in dem die Daten
bereits auf beiden Seiten synchron und im sofortigen Zugriff
liegen, ist eine sofortige Weiterführung der Geschäftsprozesse
möglich. Diese Übernahme ist soweit automatisiert, dass der
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Administrator nur noch einen einzigen Befehl absetzen muss.
Stretch MetroCluster bietet einen Schutz von bis zu 300 m
zwischen zwei Nseries­Systemen. Fabric MetroCluster bietet
darüber hinaus einen Schutz von bis zu 100 km mit SAN­
Switchen.
A-SIS (Advanced Single Instance Storage)
Um die gespeicherte Datenmenge auf einem Backup­ oder
Archivsystem zu reduzieren, kann Data­Deduplication eingesetzt
werden. Bei Nseries heißt diese Funktion A­SIS (Advanced
Single Instance Storage Deduplication). Identische Daten
werden nur einmal gespeichert, was bei bestimmten Applikationen
bis zu 70 % Ersparnis in der Speicherkapazität
ausmachen kann. Auf Systemebene analysiert die Nseries
identische Blöcke im Hintergrund (für die Applikation transparent)
und speichert diese nur einmal ab. A­SIS ist ideal
für Archive oder Backup­Systeme.
SMBR (Single Mailbox Recovery für Exchange)
Im Gegensatz zu Lotus Domino, bei dem jede Mailbox separat
als eigene Datenbank gespeichert wird (und damit eine
einfach wiederherstellbare Einheit darstellt), legt Exchange
verschiedene Mailboxen zusammen und in .edb­ und .stm­
Files ab. Diese Files werden im Laufe der Zeit sehr groß.
Das erschwert das Restoring, weil man mit sehr großen .edbund
.stm­Files arbeiten muss, wenn eine einzelne Mailbox
wiederhergestellt werden muss.
Die Lösung hierfür ist SMBR, eine SW, die diese großen Files
durchsucht, um die gewünschte Mailbox (inklusive Anhängen,
Foldern etc.) wiederherzustellen. SMBR setzt auf den
SnapShots auf und muss nicht auf dem Produktionsserver
laufen. Eine ‘Content Analyse’ ist eine Option der SMBR: mit
ihr kann der Inhalt von E­Mails, Anhängen etc. analysiert
und protokolliert werden.
SnapDrive
SnapDrive ist die SW, die es ermöglicht, aus dem Applikationserver
heraus Volumes zu verwalten, zu vergrößern, konsistente
SnapShots auszulösen und LUNs zu clonen (ohne
FlexClone Feature).
Müssen in einem klassischen Storage­Subsystem die Volumes
für eine Datenbank vergrößert werden, muss der Serveradministrator
spätestens dann einen Prozess anstoßen,
um mehr Speicherplatz zu beantragen.
Mit SnapDrive ist das jetzt sehr einfach: Aus dem GUI der
Applicationserver heraus wählt man das entsprechende
Volume an und gibt die neue größere Kapazität ein. Im Hintergrund
(also unterbrechungsfrei) wird das Volume vergrößert.
SnapDrive kommuniziert mit der Nseries, um diese
Aktionen durchzuführen. SnapDrive spart Zeit und Kosten
und hilft Prozesse zu vereinfachen, da diese via GUI erledigt
werden können. Darüber hinaus kann SnapDrive auch
neue Drives anlegen und diese ‘mounten’ (d. h., den Servern
zur Verfügung stellen). SnapDrive unterstützt MSCS (Microsoft
Cluster) und VSS und sollte für iSCSI und FC immer eingesetzt
werden. Mit dieser Funktion werden Microsoft, Windows­
sowie Unix/Linux­Derivate unterstützt.
SyncMirror
SyncMirror ist ein Standardfeature, bei dem jeder I/O faktisch
auf zwei getrennte Diskpools geschrieben wird. Dies
entspricht quasi einem RAID1 innerhalb eines Systems.
SyncMirror lässt sich am besten mit dem LVM (Logical
Volume Manager) unter AIX vergleichen.
RAID-DP
Herkömmliche Single­Parity RAID­Technologien bieten Schutz
beim Ausfall eines Disk­Drives. Es wird erwartet, dass kein
anderer Fehler in der Daten­Rekonstruktionszeit auftritt. Sollte
dennoch ein Fehler in dieser Phase auftreten, kann es zu
Datenverlusten führen. Dies ist besonders im Hinblick auf die
immer größer werdenden SATA Drives der Fall, die inzwischen
1 TB Datenvolumen fassen können. RAID DP (Double Parity)
sichert den Ausfall von zwei Disk­Drives. RAID DP schreibt
16 Stripes, die vorher kalkuliert werden (Data und Parity),
gleichzeitig auf das Disk­Backend.
Spares Drives greifen bei Ausfall einer Disk. RAID­DP entspricht
also RAID6.
FlexVol
FlexVol ist eine Standard­SW, die für das LUN­Management
entwickelt wurde. FlexVol bedient sich dabei aus dem
gesamten Disk­Storage­Pool der Nseries, um daraus die
einzelnen LUNs zu formen. Es werden dabei alle verfügbaren
‘Spindeln’ im Backend ausgenutzt, ohne dass I/O­
Engpässe durch dedizierte Disk­Zuteilungen entstehen.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
85

86
1999 bis 2005
Die Epoche der Multiplattform-Systeme und des FibreChannel SAN und NAS
FlexShare
FlexShare priorisiert den Service für wichtige Workloads
durch Zuordnung von Prioritätsstufen von 1 – 5 für jedes
Volume. So kann z. B. der I/O einer Datenbank gegenüber
Fileservices bevorzugt bedient werden. FlexShare ist ein
Standardfeature der Nseries.
FlexClone
FlexClone ermöglicht, mehrfache Clones von FlexVols zu
erzeugen (z. B. für Testzwecke, QA, DWH etc.). FlexClones
verbrauchen zum Zeitpunkt der Erstellung keinen zusätzlichen
Speicherplatz. Sie setzen auf SnapShots auf und sind
in Sekunden erzeugt und schreibend veränderbar. Sie
haben die gleiche Performance wie FlexVols inklusive aller
Eigenschaften eines FlexVols (dynamisches Vergrößern und
Verkleinern). Eine Einschränkung ist zu berücksichtigen:
‘Parent FlexVol’ und Base SnapShot können nicht gelöscht
werden, solange ein davon abhängiges FlexClone Volume
existiert. Über ‘Split’ kann das FlexClone Volume von seinem
‘Parent Volume’ getrennt werden und unabhängig weiter
existieren. Dafür wird freier Platz im Aggregat benötigt, um
die ‘Shared Blocks’ zu kopieren.
Kommentar zur Epoche Multiplattform-Systeme und FibreChannel
SAN und NAS
Die Schnelligkeit und Hektik nahm in dieser Epoche im Vergleich
zur Vorgänger­Epoche noch weiter zu. Hinzu kamen
neue Komplexitäten durch neue FibreChannel­Netze (SANs)
und die Möglichkeiten im Networking­Attached­Storage­Umfeld.
Storage wurde durch viele neue Produkte im SAN­ und
NAS­Umfeld zwar vielseitiger, aber auch komplexer und
schwieriger.
In dieser Epoche lösten sich die Speichersysteme von ihrer
bisherigen Abhängigkeit von den Servern. Multiplattform­Systeme
wie die ESS konnten jede Server­Plattform bedienen.
Neben diesen Multiplattform­Systemen wurden parallel für die
Open­System­Plattformen FibreChannel­Systeme gebaut, die
sich an den entstehenden und immer weiter verbreiteten SANs
anschließen ließen. SANs und SAN­Strategien beherrschten
immer mehr den Markt. Das gilt auch heute noch! Auch die
zSeries stellte von ESCON auf FICON um, um ESCON­Protokollpakete
über den FibreChannel zu transportieren. SAN­
Virtualisierung war das Fokusthema, dem IBM mit dem SAN
Volume Controller antwortete. SAN­Management, vor allem
zentrales Management, wurde zu einer der Hauptanforderungen
von Rechenzentren, die SANs betrieben. Dazu entwickelte
IBM das Programmpaket IBM TPC (Total Productivity
Center). Nach 1­Gbit­SANs kamen 2­Gbit­ und 4­Gbit­SANs
in Zeitabständen von etwa drei Jahren zum Einsatz. Seit
2006 sind 4­Gbit­FibreChannel­SAN­‘End to End’­Lösungen
möglich.
Im NAS­Umfeld brachte IBM hauptsächlich Lösungen in Form
von Gateways, die sich allerdings während der gesamten
Epoche nicht durchsetzen konnten. IBM hatte zu wenig Fokus
auf die NAS­Möglichkeiten und konzentrierte sich hauptsächlich
auf die SANs. Am Ende der Epoche, im Jahr 2005,
kam es zu einer Allianz der Firmen IBM und Network Appliance,
die auf dem Gebiet NAS sehr erfolgreich waren und
bis heute erfolgreich sind. Diese Allianz ermöglicht IBM, auch
auf dem Gebiet NAS entwickelte Lösungen anzubieten und
das Gesamtspeicher­Portfolio auszubauen.
Auf der Bandentwicklungsseite war neben der Einführung
von LTO2 und LTO3 eines der Meilensteine die Einführung
der sensationellen Jaguar­Bandlaufwerktechnologie mit dem
3592­ und später TS1120­Laufwerk. Jaguar ist das ‘Vehicle’,
um im Tape­Umfeld ganz neue Wege beschreiten zu können.
Jaguar eröffnet technische Möglichkeiten, die wir uns
vielleicht heute noch gar nicht vorstellen können (siehe
Technologie­Anhang, Kapitel Magnetband).
Für die Langzeitarchivierung entstanden neben optischen
Archiven neue und bessere Lösungsansätze, weil der Gesetzgeber
nicht mehr vorschrieb, welches Medium benutzt werden
muss. Dadurch wurden bessere und sinnvollere Lösungen
möglich. IBM entwickelte die Lösung DR450 (Data Retention),
die durch die DR550 ersetzt wurde und heute erfolgreich im
Langzeitarchivierungsbereich eingesetzt wird.
Die verfügbaren Produkte am Ende dieser vielseitigen Epoche
werden mit absoluter Sicherheit die Folgeepoche mit entsprechenden
Weiterentwicklungen begleiten und Lösungen
für die durch SAN und NAS komplex gewordene Speicherwelt
bieten. Insbesondere werden vor allem die Bereiche des
DS4000­Plattensystems, des San Volume Controller, der gesamte
Band­ und Bandarchivbereich, Band­Virtualisierungslösungen
und der Bereich der Langzeitarchivierung mit der
DR550 schnell vorangetrieben werden.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

nchrone Kopie mit Metro Mirror
(bis zu 300 km)
A
B
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme
und der Speichervirtualisierung
Asynchrone
(keine D
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
87

88
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
Was wird uns die neue Epoche der Server­basierenden
Speicherarchitekturen und der Speichervirtualisierung
bringen? Was erwartet uns technologisch in den nächsten
Jahren?
Der Autor erlaubt sich, eine persönliche und durchaus realistische
Abschätzung der nahen Zukunft in dieses Storage­
Kompendium einzuarbeiten.
Server-basierende Plattensysteme
Die Ansätze von Server­basierenden Speicherarchitekturen
sieht man bereits in der Vorgänger­Epoche in den Produkten
DR550 (pSeries­Server) für die Langzeitarchivierung und
TS7500 Familie (xSeries­Server mit Linux Kernel) für die
Bandvirtualisierung im Open­Systems­Bereich. Auch die
SAN­Virtualisierung mit dem SAN Volume Controller muss
dazugezählt werden.
Allerdings bedeuten Server­basierende Speicherarchitek­
turen weit mehr. Systeme auf dieser Basis sind nicht nur
Maschinen, auf denen Daten gespeichert werden, sondern
auch gleichzeitig Server, die Applikationen durchführen kön­
IBM DS8100 2-Wege-System IBM DS8300 4-Wege-System
nen. Konsolidiert man heute Server auf der Serverebene
und Speichereinheiten auf der Speicherebene, lassen Server­basierende
Speicherarchitekturen eine Vertikalkonsolidierung
von Servern und Storage zu. Applikationen können
von der Serverebene auf die Storage­Ebene verlagert werden.
Dies ist vor allem für Applikationen von wesentlichem
Vorteil, die viele I/Os zwischen einer Servereinheit und einer
Storage­Einheit produzieren. Diese I/Os können alle eingespart
werden, wenn die Applikation von einer Speichereinheit
durchgeführt wird (‘No I/O­is the best I/O’).
Das erste Produkt in dieser Server­basierenden Speicherar­
chitektur ist das Plattensystem DS8000, das am 12. Oktober
2004 von IBM angekündigt wurde. Die Ankündigung
erfolgte zweifelsfrei viel zu früh und es dauerte fast noch ein
ganzes Jahr, bis die Maschine den Stabilitätsgrad hatte, um
produktiv eingesetzt zu werden. Heute hat die Maschine
eine noch nie dagewesene Stabilität und eine Leistungsfähigkeit,
die kein anderes vergleichbares System auf dem
Markt ausliefert. Mit der DS8000 wurde am 12. Oktober
auch der kleine Bruder, die DS6000, angekündigt.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Die DS8000 ist das derzeit leistungsfähigste Plattensystem
auf dem Markt. Mit 3,4 Millionen I/Os pro Sekunde ist sie
unschlagbar im Vergleich zu anderen Plattensystemen. IBM
trat mit dem Speichersystem DS8000 aber nicht an, um
irgendwelche Spitzenpositionen auf irgenwelchen Ranglisten
zu erzielen, sondern um mit weniger, leistungsfähiger
Hardware die Datenspeicherung günstiger zu gestalten. Es
geht um die Wirtschaftlichkeit und Spitzentechnologie hilft
dabei, die Total Cost of Ownership (TCO) günstiger zu
gestalten. TCO setzen sich aus Hardware­Anschaffungsko
sten und Betriebskosten zusammen. Mit dem Einsatz von
DS8000 wird beides reduziert. DS8000 führt zu geringeren
Anschaffungskosten und wesentlich günstigeren SAN­Infrastrukturkosten,
weil weniger Komponenten benötigt werden.
Gleichzeitig reduziert sich der Management­ und Tuning­
Aufwand, weil die Hardware leistungsfähiger ist und weniger
überwacht und optimiert werden muss. Durch Architekturprinzipien
wie ein Stripe­all­Design und selbstlernende und
sich an veränderte Workloads automatisch anpassende
Caching­Algorithmen erreicht die DS8000, dass die Hardware
optimal genutzt wird.
Die folgende Tabelle gibt einen Überblick über die Skalierbarkeit
des Speichersystems DS8000. Die Systeme wurden
im Hinblick auf nahezu lineare Skalierbarkeit konzipiert. Dies
geht aus der unten stehenden Tabelle hervor. Den Einstieg
in die DS8000­Welt bietet das 2­Wege­System DS8100, das
bis 116 TB auf Basis von 300­GB­Laufwerken skaliert. Steigen
die Kapazitätsanforderungen, erhöhen sich bei dem
System alle zur Leistungssteigerung erforderlichen Komponenten
wie Anzahl der Prozessoren, Cache, FC/FICON­
Adapter und Disk­Adapter. Dies gilt auch für die zukünftig
geplanten Erweiterungen. Steigen die Kapazitätsanforderungen
über 192 GB hinaus, sind zukünftig 8­Wege­ und
12­Wege­Systeme bis hin zum 32­Wege­System ohne Architekturänderung
machbar. Bei einer nahezu verdreifachten
Kapazität von über 500 TB skaliert das System nahezu
linear mit, da dann auch alle wesentlichen Komponenten zur
Leistungserbringung wie Cache, Prozessoren, FC/FICON­
Adapter und Disk­Adapter beim Upgrade vom 4­Wege­ auf
das 12­Wege­System verdreifacht werden. Die zukünftigen
Systeme sind Bestandteil einer lang angelegten Roadmap.
Die 8­Wege­ und 12­Wege­Systeme werden realisiert werden,
sobald sich der Bedarf nach dieser extrem hohen Leistungsfähigkeit
auf dem Markt abzeichnet.
2-way 4-way 8-way 12-way
Server Processors 2-way POWER5 4-way POWER5 8-way POWER5 12-way POWER5
Cache 16 to 128 GB 32 to 256 GB 64 to 512 GB 96 to 768 GB
FICON (2 Gb/s) (4 ports per adapter) 8 to 64 8 to 128 up to 256 up to 384
FibreChannel (2 Gb/s) (2 ports per adapter) 8 to 64 8 to 128 up to 256 up to 384
ESCON (2 Gb/s) (4 ports per adapter) 4 to 32 8 to 64 up to 128 up to 192
Device Ports 8 to 32 8 to 64 8 to 128 8 to 192
Drives
73 GB (15K RPM), 146 GB, (15K RPM)
146 GB (15K RPM), 300 GB (10K RPM)
16 to 384 16 to 640 up to 1792 up to 1792
Physical Capacity 1.2 to 115 TB 1.2 to 192 TB up to 538 TB up to 538 TB
Number of Frames 1 to 2 1 to 3 2 to 8 2 to 8
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
89

90
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
IBM DS8100 Innenaufbau IBM DS8300 Innenaufbau
Die DS8100 besteht aus einer Basiseinheit und maximal
einer Erweiterungseinheit. An die DS8300 können bis zu
zwei Erweiterungseinheiten angeschlossen werden. Seit
Oktober 2006 können bei den DS8000 Turbo­Modellen bis
zu vier Erweiterungseinheiten angeschlossen werden. Damit
bietet die DS8000 Turbo die Möglichkeit, über 300 TB FC­
Platten und über 500 TB FATA­Platten zu betreiben (maximal
1.024 Plattenlaufwerke).
Die Speichersysteme DS8000 sind die ersten Speichersys­
teme im Markt mit echten Storage­LPARs. Wie bei einem
Server können auf einer physischen Einheit logische LPARs
mit eigenem Prozessor, eigener Bandbreite, eigenen HBAs,
eigenem Disk­Adapter, eigenen Laufwerken und eigenem
Mikrocode gebildet werden. Die LPARs sind robust voneinander
isoliert. Selbst ein Crash in einer LPAR beeinflusst
die zweite LPAR nicht. Das LPAR­Konzept eignet sich daher
besonders gut für die Sicherstellung eines bestimmten Service­Levels
für bestimmte Anwendungsbereiche. Produktion
und Test können auf einer Maschine gefahren werden, ohne
dass die Testaktivitäten die Produktion beeinflussen. zSeries
und Open Systems Workload können ebenfalls ohne Bedenken
auf der gleichen Maschine betrieben werden, da jede
LPAR mit ihren eigenen Ressourcen ausgestattet ist.
Zum heutigen Stand bietet die DS8300 zwei LPARs, die
jeweils 50 % der Ressourcen erhalten. In Kürze wird die Aufteilung
flexibler werden und Sub­Prozessor­Allokationen
werden möglich sein.
In der Zukunft wird es neben den Storage­LPARs auch
Anwendungs-LPARs geben. Da die DS8000 eine pSeries
integriert hat, können alle Möglichkeiten eines Servers für
die Datenspeicherung genutzt werden. Es ist insbesondere
daran gedacht, Anwendungen mit einer hohen Affinität zu
Storage (viele I/Os) direkt auf dem Speichersystem laufen
zu lassen und die internen Bandbreiten der DS8000 für optimale
Performance zu nutzen.
Ein wesentliches Merkmal der DS8000 sind die überle-
genen Copy-Services, die einen unterbrechungsfreien RZ­
Betrieb ermöglichen. Dazu gehören die Funktionen synchrones
und asynchrones Kopieren (Metro Mirror/Copy,
Global Mirror/Copy) sowie Point­in­Time Copy (FlashCopy).
Die Spiegelfunktionen der DS8000 sind heute wegen ihrer
Leistungsfähigkeit (Entfernung, Anzahl I/Os über eine Leitung,
Anzahl gleichzeitiger Spiegel) und ihrer Funktionalität
(Konsistenzgruppen, Suspend­/Resume­Möglichkeit,
Umdrehen der Spiegelungsrichtung, drei Spiegel gleichzeitig
etc.) einzigartig im Markt. Derzeit gibt es keine leistungsfähigere
Remote-Copy-Implementierung auf dem Markt.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Während DS8000 auf Basis der POWER5­Architektur ganz
klar den High­End­Speichermarkt adressiert, gibt es noch
ein riesiges Marktpotenzial mit geringeren Anforderungen an
Leistung und Skalierbarkeit. Dieses Marktpotenzial adressiert
IBM mit einem modularen Speichersystem auf Basis
der PowerPC­Prozessortechnologie. Wichtig für dieses
Marktsegment ist ein kompaktes, modulares Design, das
eine hohe Leistung auf kleinstem Raum ermöglicht, keine
besonderen Anforderungen an die RZ­Infrastruktur stellt und
sich perfekt in die vorhandene IT­Landschaft mit Servern in
19­Zoll­Racks integrieren lässt.
Diesen Designanforderungen entspricht das Speicher -
sy stem DS6000. Das System ist voll und ganz für den Mas­
senmarkt und seine spezifischen Anforderungen konzipiert.
Das System basiert auf modularen Einschüben mit 3U­Bauhöhe,
die sich in vorhandene 19­Zoll­Racks einbauen lassen,
ohne dabei Kompromisse in der Leistungs fähigkeit einzugehen.
Das Speichersystem skaliert von 288 Gigabyte bis
auf 38,4 TB.
DS6000 stellt für IBM bei Plattensystemen einen Durchbruch
im Platzbedarf dar. Während der bisherige Einstieg in die
Enterprise­Welt mit der ESS 750 nicht ohne mindestens
einen Quadratmeter Stellfläche plus zusätzliche Servicefläche
sowie einen stabilen Doppelboden, der eine Tragfähigkeit
von über einer Tonne gestatten musste, zu ermöglichen
war, erreicht die DS6000 völlig neue Dimensionen. Der maßstabsgerechte
Vergleich unten zeigt den großen technologischen
Fortschritt. Der Einstieg in die Enterprise­Welt ist
jetzt mit weniger als 5 % des Volumens bisheriger Speichersysteme
möglich. Damit gehen verringerte Anforderungen
bzgl. der Servicefläche, der RZ­Infrastruktur und des Strombedarfs
einher.
Die DS6000 entspricht im logischen Aufbau der DS8000.
Der Unterschied besteht in der Plattform, auf der das
System betrieben wird. HA­ und DA­Code sind im Wesentlichen
identisch, da es sich um autarke Einheiten handelt.
Die Funktionalität des Speichersystems ist ebenfalls identisch.
Der große Unterschied ist die Prozessor­Plattform. Da
der PowerPC­Prozessor über keine Partitionierungsmöglichkeiten
verfügt, entfällt diese Komponente. Zudem wird der
Prozessor nicht durch AIX, sondern durch Linux gesteuert.
IBM ESS 750 mit 5 TB Kapazität IBM DS6000 mit 4,8 TB Kapazität
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
75,25”
5,25”
19”
91

92
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
Ansicht IBM DS6800 Plattensystem
Wesentliche Änderungen betreffen auch den Abstraction
Layer, der alle HW­Spezifikationen von der Funktionsebene
isoliert. DS6000 ist also ein reines Speichersystem, das
nicht für Applikationszwecke in der Zukunft eingesetzt werden
kann.
Die Maschine besteht im Prinzip aus 5 Komponenten, sogenannten
‘Customer Replaceable Units’ (CRUs). Dies sind
Laufwerke, Stromversorgung, Controller, Batterie und ein
‘Light­Path­Diagnose­Modul’. Wann immer eines dieser Teile
defekt ist, erhält der Kunde ein Ersatzteil zugeschickt, das
er in Minuten mit wenigen Handgriffen selbst einsetzen
kann.
Das Gleiche gilt für den Mikrocode. Wann immer eine neue
Version verfügbar ist, wird der Kunde davon informiert und
kann sich aus dem Internet den neuesten Mikrocode herunterladen
und unterbrechungsfrei einspielen.
Unterstützt wird man bei der Fehleranalyse durch Light Path
Diagnostics, SNMP­Meldungen und ein GUI. Die Fehleranalyse
ist voll vom System gestützt. Interaktive Hilfefunktionen
vereinfachen die Reparatur. Zur einfachen Administration
und schnellen Implementierung verfügt das Speichersystem
über einen Express Configuration Wizzard, der das erstmalige
Konfigurieren oder Umkonfigurieren stark vereinfacht.
Die DS6000 und DS8000 sind die ersten Plattensysteme
von IBM, die mit vier Jahren Gewährleistung angekündigt
wurden. Aufgrund dieser langen Gewährleistung erkennt
man bereits, dass diese neue Architektur sehr lange
Bestand haben wird.
Am 22. August 2006 mit Verfügbarkeit im September 2006
kündigte IBM die neusten Erweiterungen für die DS6000
und DS8000 an. Beide Plattensysteme können jetzt neben
der Auswahl an FibreChannel­Platten auch mit günstigeren
Fibre­ATA(FATA)-Platten bestückt werden. Die Platten
haben eine Kapazität von 500 GB pro Laufwerk. Das bietet
für die Plattensysteme die Möglichkeit, innerhalb des
Systems mit einer Zwei-‘tier’-Storage-Hierarchie zu arbeiten.
So können die FC-Platten für die klassische Transaktionsverarbeitung
und hoch frequentierte Daten eingesetzt werden
und die günstigeren, aber langsameren FATA-Platten
für sequenzielle Datenverarbeitung und nur wenig benutzte
Daten.
Damit bietet eine DS8000 voll ausgebaut mit FATA­Platten
eine Bruttokapazität von 320 TB und eine kleine DS6000 bis
zu 64 TB an Bruttokapazität.
1 st tier-FC Drives
- Transactional IO
- Heavily used data
2 nd tier-FATA Drives
- Streaming data
- Little used data
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Flash

Für die DS8000 wurden neue Modelle angekündigt, die
POWER P5+ Prozessortechnologie integriert haben und
damit 15 % höhere Leistungsfähigkeit ausliefern. Die
I/O­Cages wurden auf 4-Gbit-FibreChannel- und FICON-
Ports umgestellt. Damit ist die DS8000 das erste Plattensystem
auf dem Markt, das mit 4­Gbit­FICON­Ports am zSeries­
Host arbeiten kann. Die DS8000­Systeme mit P5+ Pro zessoren
werden als DS8000-Turbo-Systeme bezeichnet.
Ein neue Einrichtung, die als ‘Synergy Feature’ bezeichnet
und im November 2006 verfügbar wird, verbessert maßgeblich
die Gesamtleistung der Komponenten DS8000 Turbo,
DB 2 und AIX und erzielt eine wesentlich effektivere Kommunikation
zwischen Rechner und Speichersystem für DB2­
Anwendungen. Dies wird durch eine gezielte ‘End to End’­
Prioritätensteuerung ermöglicht.
Teil der Ankündigung vom 22. August 2006 war zudem die
Möglichkeit, bei DS8000­Turbo­Systemen mit einem dritten
Spiegel bei Remote­Copy­Verfahren zu arbeiten. Diese
Lösung wird als ‘3 Site Disaster Recovery Solution’
bezeichnet. Damit wird auch im Disaster­Fall ein konstanter
Zugriff auf die Daten gewährleistet. Diese Möglichkeit war
bisher nur über RPQ (Request for Price Quoting) gegeben.
Das dreifache Remote-Spiegelverfahren setzt sich aus
den Komponenten ‘Metro Mirror’ und ‘Global Mirror’ (ehemals
PPRC XD – Peer to Peer Remote Copy eXtended
Distance – und FlashCopy) zusammen. Von der Lokation A
wird mit der DS8000­Turbo synchron zur Lokation B gespiegelt.
Die Lokation B spiegelt dann asynchron auf die Lokation
C weiter.
Fällt die Lokation A aus, wird die Anwendung auf die Lokation
B umgeleitet und Global Mirror läuft ohne Unterbrechung
zwischen den Lokationen B und C weiter. Kommt
Lokation A wieder online, wird von der Lokation B nach A
auf inkrementeller Basis resynchronisiert. Nach Abschluss
der Resynchronisation kann die Anwendung von B nach A
zurückverlagert werden.
Synchrone Kopie mit Metro Mirror
(bis zu 300 km)
A
Fällt die Lokation B aus, stellen inkrementelle Resynchronisationsverfahren
die Verbindung zwischen A und C her und
gewährleisten damit weiterhin unterbrechungsfreien Spiegelbetrieb.
Steht die Lokation B wieder zur Verfügung, wird
über ein inkrementelles Verfahren von A nach B resynchronisiert.
Nach Abschluss der Resynchronisation werden die
Lokationen B und C wieder über Global Mirror verbunden
und so die Ausgangssituation wieder hergestellt.
Fällt Lokation C aus, ist die Anwendung A nicht betroffen
und die synchrone Spiegelung zwischen A und B bleibt
erhalten. Steht die Lokation C wieder zur Verfügung, wird
Global Mirror inkrementell wieder aufgebaut und die Ausgangssituation
wieder hergestellt.
Parallel Access Volume (PAV): Die Funktion, von mehreren
Rechnern und Anwendungen gleichzeitig auf diesselbe
Platten adresse zu schreiben und von ihr zu lesen, wurde im
z/OS­Umfeld mit dem Enterprise Storage Server (siehe auch
ESS) eingeführt und für die DS8000 weiter optimiert. Der
Work load Manager (WLM) im z/OS steuerte die dynamische
Zuordnung und Umordnung der dafür notwendigen ‘Alias’­
Adressen, was als dynamisches PAV bezeichnet wird. Im
November 2006 kündigte IBM für die DS8000 Hyper PAV
an. Dabei wurde die Funktion so geändert, dass z/OS im
Zusammenspiel mit der DS8000 für jeden einzelnen I/O eine
Alias­Adresse aus einem Pool nehmen kann, ohne dass
eine Koordination zwischen z/OS­Systemen notwendig ist.
Damit kann sofort auf sich ändernde Workloads reagiert
werden. Hyper­PAV benötigt bei derselben Workload nur
etwa die Hälfte an Alias­Adressen und bietet im Vergleich
zum dynamischen PAV bei derselben Anzahl an Alias­
Adressen die Möglichkeit, 50 % mehr I/Os zu prozessieren.
Am 22. August 2006 wurde als neues Software­Produkt IBM
TotalStorage Productivity Center (TPC) für Replikation
angekündigt. TPC für Replikation erlaubt ein zentrales
Management der Copy­Services­Funktionen Metro Mirror,
Global Mirror und FlashCopy für die Produkte DS6000,
DS8000, DS8000 Turbo, SAN Volume Controller SVC und
ESS Modell 800.
Asynchrone Kopie mit Global Mirror
(keine Distanz-Begrenzung)
B C
FlashCopy
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
93

2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
Im Jahr 2007 stellte IBM für die DS8000 Plattensysteme
erhebliche Erweiterungen zur Verfügung.
Im Februar 2007 kündigte IBM mit Verfügbarkeit März für
alle DS8000­Systeme neben den bisherigen Plattentypen
300-GB-FibreChannel-Platten mit 15.000 Umdrehungen
an. Die DS8000 war damit das erste System auf dem Markt,
das mit diesen schnellen großkapazitiven Platten ausgestattet
werden konnte. Im Mai 2008 kamen erhebliche Kapazitätserweiterungen
dazu. Konnte bisher ein 4­Way­System
mit bis zu 640 Platten (bei 2­Way sind es bis zu 384 Platten)
in einer Konfiguration von drei Einheiten ausgestattet sein,
war es seit Juni 2007 möglich, ein 4­Way­System DS8300
mit bis zu 1.024 Platten zu konfigurieren. Dazu werden an
die Basiseinheit vier zusätzliche Erweiterungseinheiten
angeschlossen, insgesamt also eine Konfiguration mit fünf
Gehäuseeinheiten. Bei Verwendung der 500­GB­FATA­Platten
steigerte sich so die maximale Kapazität auf bis zu 512 TB
pro System.
Seit November 2007 stehen der DS8000 weitere leistungs­
optimierende Features zur Verfügung. Die Funktion Storage
Pool Striping mit Rotate Extends reflektiert einen neuen
Default­Algorithmus, der neue logische Platten in 1­GB­
Schritten über das Backend verteilt und so die Leistung
ohne spezielles Tuning optimiert. AMP (Adaptive Multistream
Prefetching) stellt eine neue Caching­Technologie
von IBM Research zur Verfügung, die, auf Workloads bezogen,
ein selbstoptimierendes Prefetching durchführt. AMP
entscheidet dynamisch, was und wann in den Cache vorgeladen
wird. Das kann den Durchsatz von sequentiellen und
Batch­Workloads dramatisch verbessern, d. h., Laufzeiten
können erheblich verkürzt werden. AMP verbessert den Lese­
Durchsatz aus einem RAID5­Array nahezu um Faktor zwei!
AMP kann Hot­Spot­Situationen verhindern, wenn sehr hohe
Anforderungen an sequentielle Workloads gestellt werden.
IBM z/OS Global Mirror Multiple Reader bietet im zSeries­
Umfeld einen deutlich höheren Durchsatz bei Remote­Spiegelungen.
Neben den neuen Performance Features wurden im November
2007 für die Maschinen auch neue funktionale Erweiterungen
verfügbar. Space efficient FlashCopy kann durch
Reduzierung der benötigten Plattenkapazität für Kopien
signifikant die Kosten senken. Dadurch können gleichzeitig
die Strom­ und Klimaanforderungen gesenkt werden. Flash­
Copies benötigen nur Plattenplatz, wenn Veränderungen am
Original durchgeführt werden. Dynamic Volume Expansion
vereinfacht das Management durch ‘Online’­Vergrößerung
von logischen Laufwerken bei Datenwachstum. Neben diesen
Erweiterungen wird das TPC (Total Productivity Center)
bei Auslieferung von neuen DS8000­Systemen standardmäßig
als neu umbenanntes SSPC (System Storage Productivity
Center) mitgeliefert und bietet damit einen einheitlichen
Zugang zum Management von IBM und anderen Speichersystemen.
Damit stehen dem IT­Benutzer eine einheitliche
Management­Oberfläche und eine gemeinsame Konsole für
DS8000­Systeme und die SVCs (San Volume Controller) zur
Verfügung.
Am 26. Februar 2008 wurden zusammen mit der Ankündigung
des neuen Mainframe­Systems z10 neue Erweiterungen für
das DS8000 Plattensystem speziell im z/OS­Umfeld angekündigt.
Mit der Funktion z/OS Metro/Global Mirror Incremental
Resync entfällt bei einer dreifachen Remote Spiegelung
die Notwendigkeit, eine volle Kopie für die Resynchronisation
nach einer Hyper­Swap­Situation zu erzeugen. Die
Erweiterung Extended Distance FICON reduziert den Bedarf
von Kanalerweiterungseinheiten (Channel Extenders) bei
z/OS Global Mirror­ (zweifache Remote­Spiegelung) und z/OS
Metro/Global Mirror­Konfigurationen (dreifache Remote­Spiegelung)
durch eine höhere Parallelität der Leseoperationen.
Die neue Möglichkeit des z/OS Basic Hyper Swap erlaubt
die Konfiguration von Disk Replication Services über das
grafische User Interface (GUI) der DS8000 Plattensysteme.
Diese Möglichkeit kann auch für DS6000­ und ESS­Systeme
genutzt werden, bei denen das GUI auch zur Verfügung steht.
Die Möglichkeit des z/OS Basic Hyper Swap ist auch ohne
GDPS (Geographically Dispersed Parallel Sysplex) benutzbar.
z/OS Basic Hyper Swap ist eine einzigartige Funktion, die
auch ohne GDPS einen automatischen Failover auf das
Remote­Plattensystem vornimmt, wenn die primäre Site nicht
mehr zur Verfügung stehen sollte. Dies ist aber ausschließlich
bei den IBM Systemen DS8000, DS6000 und ESS möglich.
Plattensysteme anderer Hersteller werden nicht unterstützt.
94 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Mit dem Release 4.0 bekommt die DS8300 im August 2008
die Möglichkeit mit variablen LPARs und damit mit mehr
Flexibilität zu arbeiten. Bisher war nur eine Aufteilung von
50 %/50 % möglich, jetzt ist auch eine variable Aufteilung
von 25 %/75 % bzw. 75 %/25 % der System­Ressourcen
unterstützt.
Innerhalb der separaten System­Ressourcen können unter­
schiedliche Versionen des Microcodes betrieben werden,
z. B. separate Produktions­Systeme oder Testsysteme und
das innerhalb eines physischen Storage­Systems. Variable
LPARs werden innerhalb der DS8300 ohne zusätzliche
Kosten ab Microcode R.4.0 zu Verfügung gestellt. Mit R.4
können nun folgende Aufteilungen vorgenommen werden:
50/50 % Split (Factory Default), 75/25 % Split und 25/75 %
Split. Die Aufteilung kann für die System­Ressourcen Prozessoren,
NVS und Cache erfolgen. Host Adapter Slots,
Device Adapter Slots und Storage Enclosure Slots bleiben
nach wie vor im 50/50 % Split.
Mit dem Release 4.1 im September 2008 erhält die
DS8000­Familie folgende Erweiterungen:
Unterstützung von Raid 6 als erweiterter Plattenschutz, ins­
besonders geeignet für große Platten, z. B. bei 1 TB SATA­
Platten. Bei FC­Platten wird aufgrund der geforderten hohen
Plattenperformance und durch die schnelle architekturbedingte
Wiederherstellung des RAID­Verbundes bei einem
Plattenausfall weiterhin RAID5 bevorzugt angewandt. Mit
der Integration von 450 GB FC 15K-Platten erweitert sich
zum einem die mögliche Gesamtkapazität und erhöht so die
Wirtschaftlichkeit des Systems. Ein neuer IBM Service
Plattenlaufwerk oben, Solid State Disk unten
‘Secure Data Overwrite’ garantiert die sichere Löschung
von sensiblen Daten auf Platten. Dieser Service wird durch
einen geschulten IBM Techniker durchgeführt.
Mit dem Release 4.2 im Februar 2009 kommen für die
DS8000­Systeme weitere fundamentale Erweiterungen zum
Tragen. Die DS8000­Systeme können jetzt neben FC­Platten
und SATA­Platten mit SSDs (Solid State Disks) ausgestattet
werden. Dabei sind Solid State Disks in der Größe von 73
GB und 146 GB unterstützt. Standardmäßig ist der Werkseinbau
vorgesehen, für den Feldeinbau muss ein RPQ
gestellt werden. Dieser RPQ dient zur Sicherstellung der
optimalen Performance.
Als erstes IBM Subsystem unterstützt DS8000 in Verbindung
mit speziellen Disk­Drives die Verschlüsselung der Daten
(Encryption) auf den Platten. Dadurch kann sichergestellt
werden, dass selbst bei einem Verlust der Disk­Drives die
Daten nicht ausgelesen werden können. Im Gegensatz zu
anderen Lösungen macht Encryption auf Disk­Drive­Level
Verschlüsselung ohne Leistungsverluste möglich. Es müssen
keine Änderungen in Anwendungen oder der Storage­
Infrastruktur vorgenommen werden. Die Verwaltung der
Schlüssel wird analog zu der Tape­Verschlüsselung mit dem
Softwareprodukt TKLM, früher EKM, vorgenommen (siehe
auch unter Tape Encryption).
Mit der Einführung von hochkapazitiven 1 TB SATA-Platten
eigenet sich das DS8000 Plattensystem auch für den Einsatz
von Data­De­Duplication­Technologien, z. B. in Verbindung
mit den Diligent­Produkten (siehe unter Data­De­Duplication
IBM ProtecTIER).
Mit dem Release 4.3 im Juli 2009 unterstützt die DS8000
‘Thin Provisioning’ ohne Leistungsbeeinträchtigung. Die
Funktion Thin Provisioning ist optional zu bestellen und ist
für die gesamte Kapazität einsetzbar. Thin Provisioning kann
die Nutzung der Storage­Kapzität erhöhen und damit zur
ökonomischen Nutzung des eingesetzten Speichers erheblich
beitragen. Die Storage­Administrationskosten können
durch automatisiertes Storage Provisioning reduziert werden.
Ein neues Feature, das ‘Quick Initialization Feature’
ermöglicht das schnelle Einrichten von Copy Services.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
95

96
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
zHPF Multi-Track Support für DS8000
Diese einzigartige Funktion der DS8000 in Verbindung mit
zSeries führt zu erheblich verbesserten I/O­Leistungen.
Erreicht wird diese Leistungsverbesserung durch ein optimiertes
I/O­Protokoll.
IBM DS8700 Plattensystem
Im Oktober 2009 kündigt IBM die neue Maschine DS8700
als Nachfolger der Plattensysteme DS8100 und DS8300 an.
Die DS8700 basiert auf Power6­Technologie und arbeitet
mit P6-Prozessoren mit 4,7 GHz. Die Leistungsfähigkeit
der Maschine ist ca. 2,5 Mal schneller als die DS8300. Die
Rio­G Loop wird ausschließlich für die P6 ‘Server to Server’­
Kommunikation eingesetzt, während die Platten arrays über
PCI­E (Express)­Karten angesteuert werden. Durch diese
Architekturänderung bekommt die Maschine eine optimale
Backend­Anbindung und höhere Backend­Bandbreite, was
sich vor allem bei Verwendung von schnellen SSDs (Solid
State Disks) auszahlt.
Wie die Vorgängersysteme ist die Maschine mit den neuen
optimierten Cache­Algorithmen ausgestattet: SARC (Simplified
Adaptive Replacement Cache) als Grundalgorithmus
verbunden mit AMP (Adaptive Multistream Prefetching) zur
Optimierung von Leseoperationen von den Platten in den
Cache und IWC (Intelligent Write Caching) zur Optimierung
der Schreib­Workload. Das Antwortzeitverhalten der DS8700
dürfte derzeitig alle verfügbaren Plattensysteme im Markt
weit übertreffen.
Verbunden mit der DS8700­Ankündigung ist ein Ausblick
einer Roadmap bis 2013. Diese Roadmap beinhaltet Funktionen
zur optimalen Nutzung von SSDs durch Analyse des
I/O­Verhaltens und dynamische Verlagerung von Extends,
die sich optimal für die Speicherung auf SSDs eignen. Mit
diesem neuen Algorithmus bekommt die Maschine die
Fähigkeit, Storage Tiers optimal auszunutzen und die Daten
dem I/O­Verhalten entsprechend auf SSDs, FC­Platten und
SATA­Platten abzuspeichern.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

IBM XIV Storage
Nahezu jedes Unternehmen ist heute von der steigenden
Flut digital zu speichernder Daten betroffen. Laut der IDC­
Studie „The Diverse and Exploding Digital Universe“ wird
das installierte Speichervolumen allein innerhalb der kommenden
vier Jahre um 600 % wachsen. Schon heute stellt
die Speichersystemadministration viele Firmen vor erhebliche
Probleme. Das erwartete hohe Wachstum kommt allerdings
nicht aus dem klassischen Rechenzentrumsbereich,
sondern fällt im Bereich der unstrukturierten Daten an. Während
im klassischen RZ­Betrieb sogenannte ‘Scale Up’­Plattensysteme
den Anforderungen an immer schnellere Antwortzeiten
Rechnung tragen (z. B. DS8000 mit schnellen
FibreChannel­Platten und SSDs) fehlen im Bereich des
Datenwachstumsumfelds kostengünstige ‘Scale Out’­
Systeme, die trotz wachsender Kapazität eine gleichbleibende
hohe Leistungsfähigkeit bieten. Eine solche Anforderung
kann nur mit einer Architektur gelöst werden, die es
erlaubt, Standardkomponenten, wie kostengünstige SATA­
Platten und PC­basierende Prozessoren, so zu integrieren,
dass eine hohe Zuverlässigkeit und hohe Leistungsfähigkeit
gewährleistet wird, auch wenn das System kapazitiv wächst.
Diese neue ‘Scale Out’­Anforderung nahm der ehemalige
Chef­Entwickler der EMC­Symmetrix Systeme Moshe Yanai
zum Anlass, die Firma XIV zu gründen, um ein neuartiges
Speichersystem zu entwickeln, das diese neuen Aspekte
von Anfang an berücksichtigt. Die Firma XIV wurde 2002
gegründet, die ersten Systeme waren bereits 2005 in Produktion.
Am 31.12.2007 wurde die Firma XIV von IBM aquiriert.
Bis Ende 2008 sind bereits über 100 Systeme im produktiven
Einsatz und seit Oktober 2008 sind die Systeme in
der zweiten Generation als IBM Produkte verfügbar.
IBM XIV Storage System
Die Entstehung von XIV Storage ist etwas Besonderes! Mit
der neuen XIV­Architektur erblickt der erste Plattensubsystem-Sozialismus
das Licht der Welt! Es ‘menschelt’
nicht, daher funktioniert der Sozialismus perfekt! Wenn
immer die Maschine etwas zu tun hat, sei es etwas auf
Platte wegzuschreiben, von der Platte auszulesen oder sich
intern zu reorganisieren, müssen alle daran arbeiten. Die
integrierten PCs, alle Plattenlaufwerke ohne Ausnahme
arbeiten immer gleichzeitig die anstehende Workload ab.
Dabei hat z. B. jede Platte immmer denselben Füllgrad und
dieselbe Arbeitslast. Wächst das System in der Kapazität,
stehen mehr ‘Arbeiter’, also mehr Plattenlaufwerke, zur Verfügung
und steigern die Leistungsfähigkeit und den Durchsatz
des Gesamtsystems. Das ist der perfekte Sozialismus!
XIV-Architektur
Ein wesentliches Merkmal der IBM XIV­Systeme ist die hohe
Parallelität durch eine modulare GRID­Architektur. Anders
als traditionelle Systeme gibt es nicht nur zwei Controller,
die sämtliche I/Os verarbeiten müssen, sondern mehrere
voneinander unabhängige Module. Diese Module bestehen
aus Standard­Servern mit optimiertem Linux­Betriebssystem.
Die hohe Parallelität wird nun dadurch ermöglicht, dass ein
patentiertes Load­Balancing­Verfahren sämtliche I/Os über
alle Systemkomponenten verteilt: Module, Switche, Caches
und Disks.
XIV-Standard-Hardware
Ein IBM XIV Storage System besteht aus mehreren Modulen,
jedes Modul mit eigenen CPUs, eigenem Cache­Speicher
und eigenen (lokalen) Disks. Einige Module besitzen darüber
hinaus FibreChannel und iSCSI­Interfaces, die zur
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
97

98
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
XIV GRID-Architektur mit verteiltem Speicher, Caches und CPUs
redundanten Anbindung der Hosts dienen. Diese Module
werden auch als Interface­Module bezeichnet. Als Betriebssystem
auf den Modulen (Servern mit Intel CPUs neuester
Generation) dient ein optimiertes Linux, was allerdings für
den Anwender transparent ist. Die Kommunikation der
Module erfolgt über zwei Gigabit­Ethernet­Switche. Die hohe
Performance wird durch die Parallelisierung aller I/Os
erreicht, welche sich stets über alle Module erstreckt.
Ein voll ausgebautes XIV­Rack besteht aus:
•
•
•
•
15 Modulen mit jeweils
-
-
-
Intel Quad-Core CPUs
8 GB RAM (Cache)
4x Gigabit Ethernet für die interne Kommunikation
- 12 Disk-Drives (1 TB SATA II)
6 Interface-Module mit insgesamt
- 24 x 4 GB FC-Adapter
- 6 x 1GB iSCSI-Adapter
2 Gigabit-Ethernet-Switche für die interne Kommunikation
3 unterbrechungsfreie Stromversorgungseinheiten
Beim Einsatz von 1 TB Disks ergibt sich also eine Bruttokapazität
von 15 * 12 * 1 TB = 180 TB. Durch die hohe I/O­
Parallelität können im Vergleich zu FibreChannel­Disks langsamere
Disks mit SATA­II­Technologie verwendet werden,
ohne dass dadurch die Systemperformance langsamer
wäre als bei traditionellen High­End­Speichersystemen mit
FibreChannel­Disks. Der Vorteil bei der Verwendung der
Standard­Komponenten für die Module und den Interconnect
besteht darin, dass neue Technologieentwicklungen
rasch und ohne Neuentwicklungen eingesetzt werden können.
Stehen beispielsweise schnellere Module in Form von
Standard­Servern oder neue Adapter zur Verfügung, können
diese sofort ausgetauscht werden. Gleiches gilt für die Interconnect­Switche.
Derzeit ist jedes Modul über 4­Gigabit­
Ethernet­Verbindungen angeschlossen. Auch der Austausch
durch 10­Gigabit­Ethernet­Switche oder Infiniband ließe sich
kurzfristig realisieren (selbstverständlich verzögern eventuell
notwendige Software­Anpassungen und vor allem Integrationstests
den Einsatz neuer Technologien).
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Datenverteilung und Load Balancing
Um eine möglichst granulare und gleichmäßige Verteilung
der Daten und I/O­Operationen zu ermöglichen, verteilt das
System jedes vom Administrator angelegte Volume immer
auf 16.384 (oder ein Vielfaches davon) primäre und
genauso viele sekundäre Partitionen mit einer Größe von
jeweils 1 MB:
•
•
Die Partitionen werden nach einem ‘pseudo-zufälligen’
Algorithmus auf alle Disks (und damit über alle Module)
verteilt. Dies gilt grundsätzlich für alle Volumes, wodurch
immer eine optimale Performance für alle Volumes erreicht
wird.
Eine Partition enthält dabei entweder eine primäre oder
sekundäre Kopie der Daten. Primäre und sekundäre Daten
werden stets in unterschiedlichen Modulen, also auch auf
unterschiedlichen Disks gespeichert.
Das Verteilungsverfahren arbeitet autonom und dynamisch.
Fällt z. B. eine Disk aus oder wird aus dem System entfernt,
werden sofort alle darauf befindlichen (primären oder
sekundären) 1 MB­Partitionen von allen anderen Disks neu
kopiert bzw. verteilt. Dadurch arbeitet diese Wiederherstellung
extrem schnell. Kopiert werden dabei übrigens nur Partitionen,
die tatsächlich Daten enthalten. In der Praxis sind
die Daten einer 1 TB SATA­II­Disk innerhalb weniger Minuten
wieder redundant. Die maximale Dauer zur Herstellung
einer 1­TB­Disks beträgt 30 Minuten. Die Wiederherstellung
einer ausgefallenen Disk in einem RAID5­ oder RAID6­Array
dauert in der Regel mehrere Stunden, manchmal Tage.
Zusätzlich ist während dieser langen Zeitspanne die Perfor­
mance des Systems herabgesetzt, da beim Zugriff auf
Daten dieses Volumes zusätzliche XOR­Operationen notwendig
sind.
Da ja primäre und sekundäre Partitionen immer über Module
hinweg „gespiegelt“ werden, können sogar mehrere Disks
innerhalb eines Moduls oder gar ein komplettes Modul ausfallen,
da selbst dann immer noch eine intakte Datenkopie
im System vorhanden ist. Auch in diesen Fällen beginnt das
System sofort im Hintergrund die fehlenden Kopien neu zu
erzeugen, immer unter Erhaltung der Gleichverteilung und
damit einer gleichmäßigen Auslastung aller Systemkomponenten.
Das Modul, das für eine IO­Operation eine primäre Partition
beschreibt, sendet parallel zum lokalen IO den gleichen
Datenblock für die sekundäre Kopie an ein anderes Modul.
Erst wenn beide Module die Datenblöcke im Cache haben,
wird dem Host die IO­Operation bestätigt. Das Schreiben
der Datenblöcke auf die jeweils lokalen Caches erfolgt im
Hintergrund.
Vergleich zu bekannten RAID Verfahren
Das dargestellte Verteilungsverfahren der Daten entspricht
keinem der üblichen RAID1­ bis RAID10­Mechanismen. Von
den Eigenschaften ist es einem RAID10­Verfahren am ähnlichsten,
bei dem die Datenblöcke verteilt (engl. striping) und
gespiegelt werden. Würde man 180 Disks in einem RAID10­
Array konfigurieren, wäre die Performance beider Disk­
Anordnungen zu Beginn des Betriebes identisch. In der Praxis
verflüchtigt sich dieser „Gleichstand“ aber recht schnell:
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
99

100
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
•
•
Bei Kapazitätserweiterungen oder Änderung von Volume-
Größen ist die Gleichverteilung bei RAID-Arrays nicht mehr
gewährleistet. Manuelle Nacharbeit am Storage- und Hostsystem
(Rebuild des Stripings etc.) ist arbeitsintensiv und
finden oft nicht statt. Manchmal müssen für solche Operationen
ganze Arrays oder Volumes umgezogen werden.
Eine Gleichverteilung aller I/Os über alle Systemkomponenten
erfordert bei traditionellen Systemen genaue
Kenntnis der Architektur und aller Virtualisierungsschichten.
Diese Arbeiten können häufig nur von Spezialisten
durchgeführt werden. Das Auslagern solcher Tätigkeiten
an die Anwender ist nicht möglich.
Wie bereits erwähnt, sind derlei Maßnahmen bei XIV­Systemen
nicht nötig (und auch nicht möglich), da der Verteilungsalgorithmus
autonom und dynamisch arbeitet. Sobald
das System zusätzliche Module bekommt, beginnt das
System mit der Umverteilung der 1­MB­Partitionen, um wieder
eine Gleichverteilung über alle Systemressourcen zu
erlangen. Auch wenn Module oder Disks entfernt werden,
beginnt eine Neuverteilung, um eine Gleichverteilung und
Verteilung der 1-MB-Partitionen eines Volumes auf alle Disks im System.
Wiederherstellung vollständiger Datenredundanz zu erlangen.
Im Gegensatz zu RAID5­ oder RAID6­Verfahren arbeitet
die Wiederherstellung jedoch sehr viel schneller, weil alle
verbleibenden Disks an den notwendigen IO­Operationen
beteiligt sind und außerdem der Zugriff auf die Daten in dieser
Zeit keine zusätzlichen XOR­Operationen erfordert.
Diese Eigenschaften führen dazu, dass das XIV­System trotz
langsamerer SATA­II­Technologie eine höhere Performance
und eine höhere Verfügbarkeit besitzt als klassische High
End RAID­Systeme mit FibreChannel­Technologie.
Verteilte Caches
Auch hinsichtlich der Caches sorgt die verteilte Architektur
für Vorteile gegenüber Dual­Controller Systemen. Die unabhängigen
Caches sind jeweils nur für die in den Modulen
vorhanden 12 Disks zuständig. Dies gewährleistet eine minimale
Latenzzeit und maximale Bandbreite. Für das Schreiben
der Daten vom Cache auf die Disks steht die volle
Bandbreite von zwei dedizierten PCI­X Bussen zur Verfügung.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Die gesamte CPU­Leistung eines Moduls steht ausschließlich
für diesen lokalen Cache zur Verfügung, was u. a. drei
Dinge ermöglicht:
•
•
•
Aggressives Im-Voraus-Lesen (engl. prefetching) von
Datenblöcken mittels intelligenter Algorithmen.
Sehr kleine Datenblöcke im Cache. Traditionelle Systeme
arbeiten aufgrund eines einfacheren Cache-Managements
meist mit Datenblöcken von 32 oder 64 KB. Das XIV-
System kann aufgrund der hohen lokalen CPU-Leistung
mit 4-KB-Blöcken arbeiten, was eine sehr effiziente Cache-
Nutzung zur Folge hat.
Eine Cache-Synchronisation ist nicht notwendig, weil jeder
Cache nur für seine lokalen Daten bzw. Disks zuständig ist.
Auch hinsichtlich einer für High­End­Systeme notwendigen
Verfügbarkeit hat eine verteilte Cache­Struktur Vorteile:
Selbst beim Ausfall eines gesamten Moduls geht bei einem
Ein­Rack­System nur ein Fünfzehntel der Cache­Kapazität
und Leistung verloren.
Sämtliche Caches sind durch redundante unterbrechungsfreie
Stromversorgungseinheiten (UPS) abgesichert. Das
System besitzt insgesamt drei solcher UPS­Einheiten, die
sich permanent zwischen dem öffentlichen Netz und den
Modulen befinden, sodass diese kurzfristigen Ausfälle oder
Spannungsspitzen verborgen bleiben. Erst bei einem Ausfall
von mehr als 30 Sekunden fängt das System an, geordnet
herunterzufahren. Ein bei anderen Systemen übliches Write­
Through­Verfahren beim Ausfall eines Controllers oder bei
Stromausfällen ist also bei XIV nicht notwendig.
Speicherkapazität
Wie bereits beschrieben, besitzt jedes Modul 12 lokale
Disks. Beim Einsatz von 1 TB SATA­II Disks ergibt sich somit
für ein volles Ein­Rack­System eine Bruttokapazität von:
K (Brutto) = 12 Disks * 15 Module * 1 TB = 180 TB
Wie im Kapitel Datenverteilung und Load Balancing
beschrieben, werden stets alle Daten über alle Disks verteilt
und zwar redundant. Dedizierte Spare­Disks, die im Normalbetrieb
nichts tun, gibt es hier nicht. Dennoch muss natürlich
so viel Kapazität in „Reserve“ gehalten werden, wie Disk
ausfallen können sollen. Für diese Reservezwecke werden
die 12 Disks eines kompletten Moduls plus drei zusätzliche
berücksichtigt. Ferner benötigt das System für interne Zwecke
ca. 3,5 TB. Daraus ergibt sich für die Nettokapazität:
K (Netto) = (15 * 12 – 12 – 3) * 1TB / 2 – 3,5 TB = 79,5 TB
Werden mehr oder weniger als 15 Module verwendet,
vermindert bzw. vergrößert dies die Nettokapazität entsprechend.
XIV-Funktionen
Thin Provisioning
Mit Hilfe des Thin Provisionings lassen sich Speicherkapazitäten
effektiver nutzen. Bei einem traditionellen System wird
der für ein Volume vorgesehene Speicherplatz sofort allokiert
und steht somit anderen Anwendungen nicht mehr zur
Verfügung und zwar auch dann nicht, wenn der Speicherplatz
gar nicht genutzt wird. Das führt in der Praxis zu einer
sehr schlechten Auslastung. Anwender wollen nämlich von
vornherein so viel Speicherplatz reserviert haben, wie auf
absehbare Zeit notwendig ist, weil andernfalls spätere
manuelle Nacharbeit notwendig ist. Beim XIV­System hingegen
kann ein Volume im Prinzip beliebig groß sein. Ist
beispielsweise für eine neue Anwendung bekannt, dass das
Datenvolumen in drei Jahren 10 TB beträgt, kann gleich ein
Volume mit entsprechender Größe angelegt werden. Der tatsächlich
belegte Speicherplatz entspricht lediglich dem der
wirklich gespeicherten Daten. Ist irgendwann der physikalische
Speicherplatz des Systems (oder Pools) erschöpft,
können einfach neue Module hinzugefügt werden. Der Verteilungsalgorithmus
sorgt sofort für eine Neuverteilung der
Daten und die Kapazität ist erweitert. Auch hier ist also keinerlei
Nacharbeit notwendig.
Diese Überprovisionierung ist übrigens nicht systemweit
gültig, sondern jeweils nur innerhalb eines Storage­Pools.
Ein Pool stellt eine administrative Domain dar, innerhalb
derer eine Quota­Verwaltung möglich ist.
Was passiert nun, wenn diese Überprovisionierung für viele
Volumes erfolgt, diese über die Zeit wachsen und die physikalischen
Kapazitätsgrenzen erreicht werden? Wie in jedem
Storage­System wird die Kapazitätsauslastung überwacht.
Bei Überschreiten konfigurierbarer Kapazitätsgrenzen wird
der Administrator benachrichtig (SNMP, SMS oder E­Mail).
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
101

102
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
Reagiert dieser nicht, beginnt das System bei kritischer
Auslastung Snapshots zu löschen. Dabei priorisiert das
System nach Wichtigkeit (beim Anlegen von Snapshots konfigurierbar)
und nach Alter. Reichen auch diese Maßnahmen
nicht mehr, kann das Systemverhalten auf zwei Reaktionen
konfiguriert werden: Entweder werden alle Volumes gelockt
oder auf ‘read­only’ gesetzt. In jedem Fall bleibt aber die
Datenintegrität erhalten.
Durch das Thin Provisioning wird in der Praxis die Speicherauslastung
um 20–30% verbessert.
Snapshots
XIV­Systeme sind mit extrem schnellen und einfach zu
handhabenden Snapsho­Mechanismen ausgestattet. Der
beschriebene Verteilungsalgorithmus der Daten setzt
voraus, dass Verteilungstabellen die Informationen beinhalten,
welche Datenblöcke auf welchen Disks gespeichert
sind. Wird nun für ein Volume oder eine Gruppe von
Volumes ein Snapshot erzeugt, werden lediglich diese Meta­
Informationen gespeichert. Dies ist eine reine Memory Operation,
die immer ca. 150 ms dauert, unabhängig von der
Größe eines Volumes (dies gilt ebenso für das Löschen von
Snapshots). Auch der verwendete Speicherplatz für ein
Snapshot ist zu diesem Zeitpunkt gleich null. Erst wenn
Datenblöcke verändert werden, sorgt ein ‘redirect­on­write’
dafür, dass der modifizierte Datenblock an eine andere
Stelle geschrieben wird. Diese Technik ist schneller als das
übliche ‘copy­on­write’ Verfahren, da eine Schreiboperation
weniger notwendig ist.
XIV­Snapshots führen deshalb in der Praxis zu keiner Perfor­
mance­Einbuße. Pro System können bis zu 16.000
Snapshots erzeugt werden.
Volume-Kopien
Selbstverständlich können auch Volume­Kopien erzeugt
werden. Volume­Kopien können – wie Snapshots – sofort
nach deren Initiierung verwendet werden. Das physikalische
Kopieren läuft im Hintergrund, bis alle Datenblöcke kopiert
sind.
Beschreibbare Snapshots
Ein Snapshot kann jedem beliebigen Host zugewiesen werden.
Dies ist oft hilfreich für eine Weiterverarbeitung der
Daten, z. B. Erzeugen von Backups oder als Datenquelle für
ein Data­Warehouse. Standardmäßig kann auf Snapshots
dabei nur lesend zugegriffen werden. Bei Bedarf können
Snapshots aber auch mit einem Handgriff als beschreibbar
(engl. writeable) markiert werden. Dies ist oft hilfreich für
Tests oder andere Szenarien, bei denen auf die Daten
schreibend zugegriffen werden muss.
Snapshots von Snapshots
Manchmal ist es wünschenswert, von einem Snapshot eine
weitere logische Kopie zu haben. XIV­Systeme können mit
demselben Mechanismus mehrere Kopien eines Snapshots
erzeugen. So könnte ein Snapshot z. B. als beschreibbar
markiert werden, während die zweite Kopie für ein Backup
dient.
Consistency Groups
Für manche Anwendung ist es wichtig, konsistente
Snapshots zu erzeugen, wenn die Anwendung mehrere
Volumes benutzt. Dies trifft z. B. auf Datenbanken zu, wenn
diese ihre Log­Dateien auf separaten Volumes speichert.
Für diese Fälle können mehrere Volumes zu Konsistenzgruppen
(engl. Consistency Groups) zusammengefasst werden.
Beim Erzeugen eines Snapshots ist dann sichergestellt,
dass selbige konsistente Daten enthalten, d. h., dass
der Zeitstempel der verschiedenen Volumes identisch ist.
Volumes einer Konsistenzgruppe müssen alle demselben
Storage­Pool angehören.
Automatischer Snapshot bei entfernter Spiegelung
XIV­Systeme erzeugen vor einem Synchronisationsprozess
entfernter Spiegel automatisch einen sogenannten ‘last­consistency­snapshot’
auf dem Zielsystem. Der Grund hierfür ist
die Sicherstellung eines konsistenten Zustands für den
Fall, dass während des Synchronisationsprozesses das
Quellsystem ausfällt oder die Verbindung unterbrochen wird.
In diesem Fall ist es möglich, dass das Zielsystem einen
inkonsistenten Zustand hat. Der automatische Snapshot
kann dann verwendet werden, um zu einem definierten,
konsistenten Zustand zurückzukehren. Diese automatischen
Snapshots haben eine Deletion­Priority von null, d.h., sie
werden im Falle einer Überprovisionierung eines Pools nicht
automatisch gelöscht.
Remote Mirroring/Disaster Recovery
Für katastrophenresistente Installationen ist es möglich, entfernte
Spiegel (engl. Mirror) auf einem anderen XIV­System
zu erzeugen. Dies kann entweder über dedizierte iSCSI
oder FibreChannel­Ports implementiert werden.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Derzeit werden zwei Möglichkeiten der synchronen Spiegelungen
unterstützt:
Best Effort:
Beim Ausfall des Kommunikationspfades oder des Zielsystems
kann weiter auf dem primären System gearbeitet werden.
Sobald der Link wieder zur Verfügung steht, werden
die in dieser Zeit geänderten Blocks nachträglich resynchronisiert.
Mandatory:
Beim Ausfall des Kommunikationspfades oder des Zielsystems
sind keine Schreibzugriffe mehr auf dem primären
System möglich. Diese Art der Implementierung erfordert
besondere Sorgfalt bei der Planung des gesamten SANs.
Alle Komponenten (Fabrics, Links, Switche etc.) sollten
redundant ausgelegt sein.
Spiegel können pro Volume angelegt werden und es können
mehrere Ziel­Volumes definiert werden.
An einem Zielsystem angeschlossene Hosts können die
Volumes zwar sehen, diese befinden sich aber im ‘read­only’­
Modus. Wird im Falle eines Disasters das sekundäre Zielsystem
zum primären System, können die Volumes beschrieben
werden. Die Volumes des ehemals primären Systems werden
nun zu sekundären Volumes und sind für diesen Zeitraum
nur lesbar (read­only).
Energieverbrauch
Durch die GRID­Architektur und die beschriebenen I/O­
Load­Balancing­Mechanismen können selbst für sehr hohe
Performance­Anforderungen Disks mit hoher Speicherdichte
und SATA­II­Technologie verwendet werden. Um eine entsprechende
Performance zu erreichen, müssen traditionelle
Systeme FC­Disks verwenden, die nicht nur wesentlich
teurer sind, sondern vor allem mehr Energie verbrauchen,
weil sie erstens schneller drehen und zweitens für die gleiche
Kapazität mehr Disks benötigt werden.
Ein vollständig ausgebautes XIV­Rack mit 180 Disks und
einer Bruttokapazität von 180 TB hat einen Energieverbrauch
von 7,7 kW. Dies entspricht einem Verbrauch von 43 W pro
TB Datenvolumen. Traditionelle Storage Systeme mit 146­GB­
FC­Disks haben einen Verbrauch von 180–380 W pro TB.
Energieverbrauch traditioneller Systeme mit FC-Disks vs. XIV
Auch andere Eigenschaften der XIV­Architektur helfen, den
Energieverbrauch zu senken:
Physikalische Kapazität wird nur „verbraucht“, wenn die
Anwendung tatsächlich Daten schreibt, jedoch noch nicht
beim Anlegen eines Volumes. Das Thin Provisioning erlaubt
es somit, eine Überprovisionierung vorzunehmen, was bis
zu 30% weniger nicht genutzte Kapazität bedeutet.
Durch das gleichmäßige Verteilen der Daten eines Volumes
auf alle Disks im System entstehen keine ungenutzten „Reststücke“,
die häufig dann entstehen, wenn verschiedene
RAID­Arrays für verschiedene Zwecke konfiguriert werden
bzw. Volumes auf verschiedene Arrays verteilt werden müssen.
Management
Das einfache Management von XIV­Systemen macht deren
große Stärke aus. Aufgrund des beschriebenen dynamischen
und autonomen Verteilungsverfahrens der Daten
auf alle Volumes entfällt beispielsweise vollständig die
Planung hierfür. Bei traditionellen Systemen ist hier oft eine
aufwendige Planung und Vorarbeit erforderlich, um für die
verschiedenen Anwendungen eine optimale Performance
und Verfügbarkeit zu gewährleisten. Ferner müssten die Einstellungen
bei Systemveränderungen nachgezogen werden,
was wiederum arbeitsintensiv ist. All diese Dinge entfallen
bei XIV­Systemen vollständig. Gleiches gilt auch für die
Platzierung von Snapshots. Auch hier sind keine besonderen
Vorkehrungen zu treffen.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
103

104
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
Benutzerschnittstellen
Das Management von XIV­Systemen ist über drei Wege
möglich:
Eine grafische Benutzeroberfläche (GUI). Diese ist intuitiv
bedienbar, die vollständige Administration eines XIV­
Systems ist in wenigen Stunden erlernbar. Geübte Storage­
Administratoren kommen häufig sofort ohne Vorbereitung
zurecht. Eine Demo für grafische Benutzeroberflächen
befindet sich auf der XIV­Web­Seite:
http://www.xivstorage.com/demo/GUI_Demo.html
Ein Kommandozeileninterface (CLI). Hier können alle administrativen
Aufgaben per Kommandozeile eingegeben oder
durch Skripte automatisiert werden.
SMI­S­konforme­Storage­Management Werkzeuge: Storage­
Tools, wie z.B. das Tivoli Productivity Center, können
verwendet werden, um XIV­Systeme zu administrieren.
Ansicht Statistikdaten über die GUI
Statistikdaten
Neben den regulären Administrationsaufgaben können auch
Statistikdaten über die genannten Benutzerschnittstellen
abgerufen werden. Das System speichert die Performance­
Daten eines Jahres. So können beispielsweise I/Os pro
Sekunde oder Durchsatzzahlen in MB/s aus jedem Zeitfens ter
innerhalb der letzten 12 Monate abgerufen und genauer
untersucht werden. Bei der Ausgabe kann z. B. gefiltert
werden auf:
Interfaces
Hosts
Volumes
Targets
Cache Hit/Miss-Raten
Read, Write oder Read/Write
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
•
•
•
•
•
•
und vieles mehr. Selbstverständlich können diese Daten
über das CLI auch zur Weiterverarbeitung in andere Tools
exportiert werden.

Interoperabilität
XIV­Systeme können an allen gängigen offenen Systemen
betrieben werden, die iSCSI und/oder FibreChannel­Speichersysteme
unterstützen. Dazu gehören z. B. AIX, Solaris,
HP­UX, Linux und die verschiedenen Windows­Varianten.
Auch gängige Cluster­Lösungen unterstützen die XIV­Storage
Systeme.
Release XIV Storage System Software Version 10.2
Im November 2009 kündigt IBM für XIV den Release 10.2
an, der folgende Erweiterungen einführt:
Asynchrones Spiegeln von XIV­Volumes und Consistency
Groups und die Unterstützung des Thin Provisioning Space
Reclamation Features der Veritas Storage Foundation.
DS3000 Platten Entry System
Im Februar 2007 überraschte IBM den Markt mit der Ankündigung
eines Entry­Plattensystems, der DS3000. Das
System wird wie die DS4000­Reihe von der Firma LSI
gebaut und als IBM Logo­Produkt vertrieben. Am Anfang
war das System nur über den Vertriebskanal IBM System x
beziehbar. Als die ersten Performance Benchmarks ergaben,
in welche ansehnliche Leistungsklasse die Maschine
skaliert, wurde das System im April 2007 in den gesamten
Storage­Vertrieb der IBM integriert.
Die DS3000­Familie zeichnet sich im Allgemeinen durch ein
hervorragendes Preis­Leistungs­Verhältnis aus und bietet
einen extrem günstigen Einstiegspreis. Es stehen drei
Modelle zur Verfügung.
Die DS3200 zeichnet sich durch 6 SAS­Hostanschlüsse aus.
Die DS3300 zeichnet sich durch maximal 4 x 1 Gbit Ethernet
iSCSI­Hostanschlüsse aus. Die DS3400 zeichnet sich
durch maximal 4 FibreChannel­Ports aus, die in den
Geschwindigkeiten 4, 2 und 1 Gbps arbeiten können. Die
Platten­ und Backend­Technologie ist in allen drei Modellen
SAS mit der Möglichkeit, auch SATA­Platten anzubinden.
Anfangs standen ausschließlich 300­GB­SAS­Platten (Serial
Attached SCSI) zur Verfügung bei einer maximalen ausbaubaren
Kapazität von bis zu 14,4 TB. Seit Oktober 2007 können
auch 750­GB­SATA­Platten integriert werden. Damit skalieren
die Systeme auf eine maximale Kapazität von 35,2 TB.
Der Mischbetrieb von SAS­Platten und SATA­Platten wurde
sichergestellt.
Allgemein zeichnen sich die Modelle durch eine geringe
Bauhöhe von nur 2U aus sowie eine Skalierbarkeit von bis
zu 48 Festplatten. In der Kopfeinheit können bis zu 12 Festplatten
untergebracht werden. Der Controller und damit das
Gesamtsystem ist über die Erweiterungseinheiten EXP3000
(bis zu 3 weiteren Einheiten) ausbaubar.
Seitens der Betriebssysteme hat die DS3000­Familie eine
geringeres Portfolio an anschließbaren Betriebssystemen.
Hier werden die Systeme Windows, Linux und Novell
standardmäßig angeboten. Zusätzlich bietet die Maschine
je nach Modell die Anschlussmöglichkeit von VMware, SVC
(San Volume Controller) oder AIX.
Rück- und Frontansicht der DS3000
Jedes Modell besitzt einen Ethernet­Zugang für das
Management. Zusätzlich kann die Maschine auch über die
Host Connectivity administriert werden. Mit 512 MB RAM
pro Controller steht ausreichend Speicher für das Caching
zur Verfügung. Dieser Speicher kann mit weiteren 512 MB
pro Controller erweitert werden. Dies ergibt eine maximale
Cache­Größe von 2 GB pro System.
Trotz „Entrysystem“ wird bei der DS3000 auf redundante
Komponenten nicht verzichtet. Die DS3000 hat auch bei
einer Single­Controller­Variante redundant ausgelegte Lüfter
und Netzteile.
Der DS3000 Storage Manager ist analog zum DS4000
Manager ebenfalls intuitiv zu bedienen und leicht zu installieren.
Der initiale Setup der Maschine erfolgt in 6 Dialoggeführten
Schritten und sollte innerhalb von 45 Minuten vollzogen
sein, d. h., nach spätestens 45 Minuten sind die
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
105

106
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
Positionierung der Entry Systeme DS3000 zu den bestehenden DS4000-Systemen (P= Performance, F=Funktionalität)
ersten Volumes den angeschlossenen Servern bekanntgegeben.
Der DS3000 Storage Manager unterstützt die
RAID­Level 0, 1, 3, 5 und 10.
Durch den Recovery Guru und durch automatische Benachrichtigungen
erhält man proaktiv, auch schon vor Crash­
Situationen, Meldungen über eventuelle Fehler oder
Überschreitungen von Schwellwerten. Die Benachrichtigung
erfolgt über SNMP und/oder per E­Mail.
Im Februar 2008 kündigte IBM für alle drei DS3000­Modelle
1.000 GB (1 TB) SATA-Platten an. Damit bekommt das
Entry­System DS3000 als erstes Plattensystem der IBM die
Möglichkeit, Platten mit 1 TB an Kapazität zu verwenden. Mit
diesen Platten kann jede Erweiterungseinheit mit 12 TB
Plattenplatz konfiguriert werden. Das Gesamtsystem,
bestehend aus Kopfeinheit und drei Erweiterungseinheiten,
liefert mit den 1 TB SATA­Platten eine maximale Kapazität
von 48 TB aus.
Für die DS3300 steht ein neues Modell 32T zur Verfügung,
das speziell für Telco­Umgebungen ein 48 V basierendes
doppeltes Netzteil auf Gleichstrombasis in der Controller­
Einheit integriert hat (iSCSI DC­Powered Controller). Damit
kann die DS3300­32T problemlos in Telco­Umgebungen eingesetzt
werden.
DS5000 Plattensysteme
Der August 2008 stand ganz im Zeichen der Ankündigung
des neuen Midrange ‘Flagship’ DS5000, die das Produktportfolio
nach oben abrunden sollte. Das bewährte Hardware­Design
mit der austauschbaren Midplane der DS4800
übernehmend, wurde das System mit einigen weiteren
Funktionen ausgestattet. So lassen sich bei der aus zwei
Produkten bestehenden DS5000­Familie (DS5100 und
DS5300) die Host­Schnittstellen­Karten (kurz HIC, Host
Interface Cards) modular austauschen. Dem Anwender steht
die Anschlussmöglichkeit über 1 GBit iSCSI, wahlweise
auch über 4 Gbit oder 8 Gbit FC zur Verfügung.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Ebenso wurde die kapazitive Skalierbarkeit von bisher 224
Platten bei der DS4800 auf 448 Platten angehoben. Damit
einhergehend wurden die Anzahl der Disk­Backend­Kanäle
auf sechzehn 4­Gbit­FC­Kanäle verdoppelt.
Beim Design der Storage Controller wurde hier wieder
Augenmerk auf die lineare Skalierbarkeit bis zur letzten
Platte gelegt. Die RAID­Berechnung erfolgt über einen eigenen
ASIC. Diese beiden Eigenschaften sorgen für eine hervorragende
Leistung im Bereich von Transaktionen und
Datendurchsatz. Beides wird eindrucksvoll durch die SPC­1und
SPC­2­Tests belegt (www.storageperformance.org).
Eine Neuerung gegenüber allen anderen Midrange­Produkten
im IBM Portfolio stellt eine Veränderung des Cache­
Schutzes dar. Während bei allen Vorgängermodellen im Falle
eines Stromausfalls der Cache über eine Backup­Batterie bis
zu 72 Stunden gestützt wurde, wird der Cache­Inhalt bei der
DS5000 mit Hilfe von Flash­Memory­Bausteinen aufrecht
erhalten. Hierbei wird der Controller selber über eine
Batterie bei einem Stromausfall so lange betrieben, bis der
Cache­Inhalt auf den permanenten Speicher verlagert
wurde. Danach wird die DS5000 ordentlich heruntergefahren.
Für das Cache Mirroring bei der DS5000 stehen jetzt
dedizierte Kanäle zur Verfügung, um die gesamte interne
Bandbreite des Systems ohne Einschränkungen nutzen zu
können.
Funktionell wurde die DS5000 gegenüber dem Vorgänger
DS4800 um RAID6 erweitert. Das verwendete RAID­Verfahren
ist dabei P+Q RAID6, ein Industriestandard, der gemeinsam
mit Intel entwickelt wurde.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
107

108
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
Herkömmliche Platte SSD Drive
Im Jahr 2009 erfolgten dann Schritt für Schritt weitere Funk­
tionserweiterungen der DS5000­Familie:
• Full Disk Encryption Drive (FDE) : Hierbei handelt es sich
um eine FC-Platte, die in der Lage, ist darauf befindliche
Daten über einen auf den Disks befindlichen Key zu verschlüsseln.
Die Freischaltung der Verschlüsselung erfolgt
über einen weiteren, auf dem Speichersystem vorgehaltenen
Key. So ist sichergestellt, dass die Daten bei dem
Entfernen einer FDE-Platte nicht lesbar sind und damit die
darauf befindlichen Daten gegen unberechtigten Zugriff
geschützt sind. Eine Funktion, die gerade bei der Speicherung
von personen- bzw. kundenbezogenen Daten die
Datensicherheit erhöht.
• Anschluss System I:
System I konnte auch zuvor über
einen VIOS angeschlossen werden, mit der Ankündigung
im Herbst 2009 kam dann aber die Möglichkeit, System I
native an eine DS5000 anzuschließen, hinzu. Dies ist eine
Funktion, auf die viele Anwender von System I lange
gewartet haben. Diese Eigenschaft in Kombination mit der
gleichzeitigen Möglichkeit, bis zu 64 GB Cache zu unterstützen,
gewährleistet die für die Anwendungen von
System I so wichtige Response- und Servicezeit.
• Solid State Disk Drives (SSD) : Im Herbst 2009 angekündigt,
wird die Möglichkeit hinzugefügt, bis zu 20 SSD-Laufwerke
in einer DS5000 zu betreiben. Im Gegensatz zu
einer herkömmlichen Platte (Abbildung), verfügt die SSD
über keine rotierenden bzw. sich bewegenden Bauteile.
Hierdurch entfällt die Rotationslatenz, sodass gerade im
Bereich der Transaktionen eine deutliche Verbesserung
erzielt werden kann. Als typischer Anwendungsbereich
können hier die Log-Bereiche einer Datenbank angesehen
werden. Zum Zeitpunkt der Ankündigung stand die SSD in
der Größe von 73 GB zur Verfügung.
• High Density Enclosure EXP5060:
Neben der 16 Platten
fassenden Erweiterungseinheit EXP5000 und EXP810
steht mit der Ankündigung der EXP5060 eine 60 SATA-
Platten fassende 4U Expansion Unit zur Verfügung. Diese
bietet, verteilt über 5 Schubladen, eine hohe Kapazität
(60 1TB-SATA-Platten) und sehr geringen Platzbedarf. Um
die benötigte Performance zu gewährleisten, ist bei der
EXP5060 erstmals möglich, ein Trunking von mehreren FC-
Backend-Kanälen der DS5000 zu nutzen. Mit der EXP5060
soll primär der HPC- (High Performance Computing) und
Archivierungsmarkt adressiert werden.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Ankündigung DS5020 – das Ende der DS4000-Ära
Mitte 2009 galt es, einen Nachfolger für die DS4700 zu
finden. Zum Ankündigungstermin 25.08.2009 wurde dann
schließlich die DS5020 vorgestellt.
Die DS5020 verfügt, ebenso wie ihr Vorgänger DS4700,
über die Ausbaufähigkeit bis zu 112 Disks, die über mehrere
4­Gbit­Kanäle angeschlossen werden. Als Disktypen stehen
Standard FibreChannel, FDE FibreChannel und SATA­Platten
zur Auswahl. Alle Plattentypen können nebeneinander in derselben
Expansionseinheit betrieben werden.
Um den Anforderungen vor allem von virtualisierten Umgebungen
Rechnung zu tragen, wurde bei der Controller­Entwicklung
ein besonderes Augenmerk auf eine ausgewogene
Leistung gelegt. Auf der einen Seite steht eine hervorragende
Performance bei Transaktionen, die einen maximalen
Ausbau sinnvoll erscheinen lässt, und auf der anderen Seite
liefert das System sehr beeindruckende Durchsatzergebnisse.
Beide Werte wurden in entsprechenden SPC­1­ und
SPC­2­Tests dokumentiert. Der mit Flash Memory abgesicherte
Datencache ist bis auf 4 GByte erweiterbar.
Eine weitere Besonderheit ist die Möglichkeit, im FrontEnd,
also im Anschluss der Server verschiedene Protokolle zu
nutzen. Hier stehen 4/8 Gbit FibreChannel und auch 1 Gbit
iSCSI zur Verfügung. Beide Protokolle können parallel auf
einem Controller betrieben werden und ermöglichen ein entsprechendes
‘SAN Tiering’.
Wie alle Mitglieder der DS4000/DS5000­Familie unterstützt
die DS5020 eine Vielzahl von Zusatzfunktionen wie:
Storage-Partitionen
FlashCopy
VolumeCopy
RemoteVolume Mirroring.
Disk Encrypton etc.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
•
•
•
•
•
Daten aus bestehenden DS4000­Systemen können direkt
auf neue DS5000­Systeme, z. B. durch Remote VolumeMirroring
oder in manchen Konstellationen auch durch physische
Migration der Festplattengruppen übernommen werden.
Nach der Ankündigung der DS5020 wird die DS4700 bis
Ende 2009 verfügbar bleiben. Danach wird das Kapitel der
DS4000­Storagesysteme geschlossen.
Um eine für den Betrieb so wichtige Integration der Applikationen
und deren Betriebssystemplattformen zu gewährleis ten,
begleiteten beide Ankündigungen (DS5000 und DS5020)
eine Vielzahl von Lösungsangeboten.
109

110
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
Hier seien exemplarisch genannt:
•
•
•
•
•
•
•
•
Integration in VMware vCenter über ein PlugIn
Unterstützung von VSS/VDS
SMI-S-Integration
Oracle Enterprise Manager PlugIn
Lösungsangebot für DeDuplikation Lösungen (ProtecTier)
TSM FlashCopy Manager
Backup Integration wie z. B. mit FastBack
Integration in das System Storage Productivity Center
(SSPC)
Für die gesamte Systemfamilie steht auch eine vollständige
Integration in die IBM Virtualisierungslösung SVC (SAN
Volume Controller) zur Verfügung.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Virtualisierung
SAN Volume Controller SVC – Virtualisierung von Plattensystemen
im SAN-Umfeld
Die ersten Geräte des SAN Volume Controllers SVC waren
im September 2003 verfügbar und sind in der Epoche der
Multiplattform­Systeme und des FibreChannel SAN und NAS
beschrieben. Die Konzeption des SVC und die dazugehörige
Software wurde über die Jahre kontinuierlich weiterentwickelt
und der heutige Produktplan des SVC sieht für die nächsten
Jahre viele neue Erweiterungen bezüglich der Hardware
und Software vor. Deshalb ist es notwendig, die Konzeption
und den SVC selbst besser zu verstehen.
Die Administration von Speicherkapazitäten stellt nach wie vor
einen hohen Anteil der IT­Kosten dar. Virtualisierte Speicherlandschaften
bieten hier eine mögliche Lösung, indem sie
Speichersysteme sowohl unterschiedlicher Bauarten und
Hersteller gemeinsam verwalten und flexibel den Servern
zuweisen können. Eine Speichervirtualisierung mit dem SAN
Volume Controller begegnet diesen Herausforderungen mit
einer skalierbaren Architektur. Viel Aufwand haben viele Unternehmen
in den letzten Jahren betrieben, um sich von einer
dezentralen Speicherlandschaft mit direkt angeschlossenem
Speicher (Direct Attached Storage, DAS) hin zu einer zentralen
Speicherlösung mit einem Storage Area Network (SAN)
zu entwickeln. Wohl existieren Storage Area Networks nicht
flächendeckend, vielfach bilden sie aber bereits den Standard.
In der jetzigen Phase geht es darum, sowohl Serverumgebungen
als auch Speichersysteme weitgehend zu virtualisieren.
Die derzeit existierenden SAN­Lösungen sind oft
recht starre Umgebungen und bilden meist Einzellösungen
für Plattformen bestimmter Hersteller und Fachbereiche. Folglich
sind Änderungen aufwendig und unterbrechen meist den
Anwendungsbetrieb. Falls ein IT­Betreiber unterschiedliche
Speichersysteme – unter Umständen mehrerer Hersteller –
installiert hat, benötigt er jeweils unterschiedliche Administrations­Tools.
Auch ist die hardwarebasierende Datenspiegelung
zwischen Speichersystemen unterschiedlicher Bauart
nicht möglich, das Gleiche gilt für Speichersysteme unterschiedlicher
Hersteller.
Administrationsarbeiten geraten damit sehr aufwendig, weil
Plattformwissen und die zugehörige Pflege gleich mannigfach
vorzuhalten ist. Weiterhin lasten heutige Speicherlö­
sungen ihre installierten Speicherkapazitäten schlecht aus.
Weltweite Kundenumfragen ergaben, dass die effektive Nutzung
bei etwa 50% liegt. Auch beim Austausch von Speichersystemen
im Rahmen von Business­Continuity­Maßnahmen
war hoher Aufwand notwendig, und zumeist wurde der
Anwendungsbetrieb für die gesamte Migrationsdauer unterbrochen.
Der IBM SAN Volume Controller (SVC) erleichert
dies erheblich, indem er Migrationen bei laufendem
Betrieb ermöglicht.
Eine Speichervirtualisierung mit IBM SVC bietet gegenüber
traditionellen Speicherlösungen den Vorteil, dass Speicherplatz
weitgehend herstellerunabhängig zugeordnet werden
kann. Hieraus folgt eine einfachere Administration, da
sich die virtuelle Oberfläche unabhängig von den jeweils
installierten Speichersystemen konfigurieren lässt. Die Grundidee
besteht darin, schnell und flexibel Plattenspeicher dort
zuordnen zu können, wo gerade Bedarf entsteht. Dem stand
bisher im Wege, dass am SAN angeschlossene Server nur
Zugriff auf die ihnen zugeordneten Speicherbereiche hatten.
Eine virtualisierte Speicherlösung wie der SVC löst dieses
starre Muster auf, da die Server hier nur noch Zugriff auf virtuelle
Speicherbereiche haben. Die SVC­Software entscheidet
nach entsprechenden Vorgaben, wo die Daten physisch
abgelegt werden. Dabei bietet die Lösung Schnittstellen zu
allen marktüblichen Betriebssystemen, Hardwareplattformen
und Speichersystemen und ermöglicht ein Management
über eine zentrale Konsole.
Einige wichtige Hardwarefunktionen verbleiben nach wie vor
im Speichersystem und sind unabhängig vom SVC. So werden
die Systeme vor dem Anschluss an den SVC wie in der
Vergangenheit eingerichtet. Es werden RAID­Arrays und
anschließend die LUNs (Logical Units) gebildet. Dies erfolgt
im Zuge der Installation mittels der vom Hersteller mitgelieferten
Administrierungssoftware. Die so definierten LUNs
werden dann dem SVC zugeteilt, der sie in sogenannte
‘Managed Disks’ (MD) umwandelt. Eine MD hat eine feste
Größe und ist nicht mehr veränderbar. Danach werden eine
oder mehrere MDs in sogenannte ‘Managed Disk Groups’
zusammengefasst. Für die angeschlossenen Server werden
im SVC virtuelle LUNs definiert, worauf der jeweilige Server
zugreift. Die Definition legt auch fest, welcher Managed Disk
Group die virtuelle LUN zugeordnet wird. Dies bestimmt, wo
letztlich die Daten physisch abgelegt werden.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
111

112
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
Einfache Datenmigration
Eine Datenmigration von LUNs zwischen unterschiedlichen
Speichersystemen führt der SVC im laufenden Arbeitsbetrieb
durch. Verliert eine Applikation, deren Daten sich beispielsweise
auf einem High­Performance­Speicher befinden,
für das Unternehmen an Priorität – etwa aufgrund hoher
Betriebskosten für den Fachbereich, lassen sich deren
Daten online auf günstigere Low­Performance­Speicher
migrieren. Dies erfolgt durch eine Änderung der Zuordnung
einer virtuellen LUN zur Managed Disk Group.
Neben der Datenmigration zum Speichersystemaustausch
können nun auch Pflegearbeiten während der Arbeitszeit
stattfinden. Speicherinhalte der Subsysteme lassen sich im
laufenden Betrieb auf andere, freie Bereiche eines anderen
Subsystems verlagern. Alle Datenverlagerungen finden
unter Kontrolle des Speicheradministrators statt und müssen
von diesem eingeleitet werden. Der SVC bietet hierbei keine
regelbasierte Datenverschiebungen aufgrund von Zugriffshäufigkeiten
an. Dies können Analyse­Tools übernehmen, die
etwa im IBM Total Storage Productivity Center eingebettet
sind. Es bietet ein komplettes SAN­Management inklusive
Speicherplatz­ und Zugriffsanalysen und kann regelbasierte
Kopiervorgänge in einem hierarchischen Speichersystem
(HSM) anstoßen. Dabei lassen sich alle IBM Speicherprodukte,
wie auch Tape Libraries, integrieren. Eine Virtualisierung
von Tape Libraries mit dem IBM SVC ist allerdings
nicht möglich.
SVC-Redundanz
Der redundante Aufbau des SVC stellt eine höchstmögliche
Verfügbarkeit der Speicherumgebung sicher. Die Linux­
Cluster­Lösung besteht aus mindestens zwei IBM System x­
Servern. Alle kritischen Elemente sind doppelt ausgelegt,
was das Risiko von Systemausfällen weitgehend minimiert.
In jedem der zum Cluster gehörigen Server läuft ein Linux­
Kernel, das von IBM auf Virtualisierungsbedürfnisse angepasst
wurde und nicht von außen modifizierbar ist. Notwendige
Veränderungen werden wie ein Firmware­Update
behandelt, das der Kunde selbst oder ein Dienstleister
durchführt. Die Virtualisierungssoftware läuft genau wie optionale
Copy­Service­Routinen unter Kontrolle dieses Linux­
Kernels.
Insgesamt stellt der SVC eine vollständige Appliance-Lösung
dar, die Hardware, Software und Managementkonsole beinhaltet.
Jeder der zwei zu einem sogenannten Node­Paar
gehörigen IBM System x­Server ist mit einem 2­Prozessorsystem
mit 2 x 2,4-GHz-Intel-Prozessoren ausgestattet, hat
8 GB Cache und vier 4­Gbit/s­FibreChannel­Ports (2145­
8G4). Diese neuen Prozessoren stehen seit Mai 2007 zur
Verfügung und erhöhen die Leistungsfähigkeit von 160. 000
I/Os auf bis zu 276 .000 I/Os. Über die Managementkonsole
können alle Administrationen ausgeführt und im Fehlerfall
auch notwendige Analysedaten ausgelesen werden. Enthalten
sind auch zwei Komponenten zur unterbrechungsfreien,
batteriegepufferten Stromversorgung (UPS).
Die Implementierung des SVC vollzieht sich wie bei anderen
Geräten, die neu ins SAN eingebunden werden. Anpassungen
im SAN­Zoning und die Zuweisungen der Datenpfade
dürften für einen erfahrenen SAN­Administrator nichts
Neues bedeuten. Zur Datenaufnahme in der virtuellen
Ebene führt der Administrator zunächst einen Imagemode
mit jeder einzelnen LUN durch. Dies bedeutet, dass die bisherigen
LUNs eines Servers dem SVC zugeordnet und von
hier als virtuelle LUN an den jeweiligen Server weitergereicht
werden. Im nächsten Schritt können diese LUNs einer
anderen ‘Managed Disk Group’ zugeordnet werden. Das hat
zur Folge, dass die Daten auf die dieser Gruppe zugeordneten
MDs verlagert werden. Dies erfolgt im laufenden
Betrieb und ist für den jeweiligen Server transparent.
SAN Volume Controller SVC: 3 Knoten im Cluster
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Ein Highlight beim SAN Volume Controller besteht in der
hohen Performance. Der SVC erfüllt alle Skalierungsanforderungen,
indem ein Cluster heute auf bis zu acht Knoten
erweitert werden kann. Falls ein Cluster mit einem Node­
Paar an Performance­ oder Kapazitätsgrenzen stößt, ist im
laufenden Betrieb eine Erweiterung um jeweils ein weiteres
Node­Paar (bis zu einem Maximum von vier Node­Paaren
pro Cluster) möglich. Jeder Knoten des IBM SVC hat einen
8 GB großen Hauptspeicher, der fast vollständig als Cache
genutzt wird. Bei bis zu acht Nodes pro Cluster ergibt sich
somit eine Cache-Größe von bis zu 64 GB. Die Nutzung
des Cache im IBM SVC bringt Performance­Vorteile gegenüber
traditionellen Speicherlösungen, da sämtliche Speicherzugriffe
gegen den Cache des SVC laufen. Damit verliert die
Performance der angeschlossenen Speichersysteme an
Bedeutung, weil ein Großteil der I/Os durch den vorgeschalteten
Cache des SVC bedient wird.
Damit erfüllt der IBM SAN Volume Controller alle Performance­
Anforderungen von marktgängigen Systemen. Unterstrichen
wird dies vom SPC­Benchmark­Test (Storage Performance
Council) der gleichnamigen Herstellervereinigung, den alle
Anbieter von Speichersystemen freiwillig durchführen können.
SVC Standortübergreifende Spiegelungen
Eine hardwarebasierende Datenspiegelung (synchron oder
asynchron) als typische Funktion zur Erfüllung von Business­
Continuity­Vorgaben ist normalerweise herstellerübergreifend
nicht möglich. Der SVC führt eine Datenspiegelung in der
Virtualisierungsschicht durch. In einer virtualisierten Speicherumgebung
ist damit die Datenspiegelung nun auch zwischen
Systemen unterschiedlicher Bauart und Hersteller möglich.
Im Desasterfall lässt sich schnell vom primären auf den
sekundären Speicher umschalten. Dies erfordert in der Regel
einen Eingriff durch den Administrator, was durch vorher
erstellte Skripts unterstützt oder automatisiert werden kann.
SVC Spiegelungsoptionen
Insgesamt laufen beim SVC alle Spiegelungsaktivitäten
zwischen verteilten Standorten zumeist über Glasfaser ab.
Bei großen Entfernungen können SAN­Router zum Einsatz
kommen, die auf der einen Seite das FC­Protokoll in ein IP­
Proto koll und auf der Gegenseite wieder in ein FC­Protokoll
umwan deln. Alternativ bieten einige Hersteller hierfür auch
die DWDM­ (Dense Wave Division Multiplexing) oder
CWDM­Technologie (Coarse Wave Division Multiplexing) an.
Mit diesen Geräten ist eine Bündelung von verschiedenen
Protokollen (etwa IP, FC, FICON, ESCON) auf die Mindestzahl
von physischen Verbindungen (in der Regel Dark Fibre)
möglich.
Diese Grafik beschreibt eindrucksvoll die nahezu lineare Skalierung eines SVC Clusters von 2 Knoten über 4, 6 bis 8 Knoten. Es waren bei diesen
Tests 1536 15K RPM Laufwerke in RAID10 notwendig, um einen 8 Knoten SVC in die Sättigung zu bringen. Damit hält der SVC den Rekord im SPC-1 Benchmark.
Die Benchmark Ergebnisse können unter www.storageperformance.org abgerufen werden.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
113

114
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
SVC Kopierfunktionen (FlashCopies)
FlashCopies eignen sich zur Backup­Unterstützung von
Datenbanken und Filesystemen. Ein FlashCopy wird als
Point­in­Time Copy ausgeführt und erzeugt im Moment seiner
Aktivierung eine Festplatte, die eine exakte Kopie der Quellfestplatte
zum Startzeitpunkt ist.
Mit dem Software Release SVC Version 4.2, das im Mai
2007 zur Verfügung gestellt wurde, kam die neue Funktion
Multi Target FlashCopy hinzu, die es erlaubt, 16 Kopien
einer Festplatte zu erzeugen, d. h., von einer Source 16
Targets abzubilden.
Mit dem Software Release SVC Version 4.2.1 vom Okto-
ber 2007 kündigte IBM die Funktion des Incremental
FlashCopy und des Cascaded FlashCopy an. Incremental
bedeutet, dass eine bestehende FlashCopy auf den aktuellen
Stand gehoben werden kann. Es werden dann nur die bis
dahin angefallenen Änderungen der Ursprungsfestplatte
kopiert. Cascaded bedeutet, dass man auch von der Kopie
weitere Kopien erzeugen kann. Das ist insbesondere dann
wichtig, wenn man eine inkrementelle FlashCopy speichern
möchte, bevor man sie fortführt. In Summe können bis zu 16
Kopien einer Ursprungsfestplatte erzeugt werden. Konsistenzgruppen
werden in allen Modi unterstützt.
Die Version SVC Version 4.2.1 bietet zudem die Möglichkeit,
Copy­Service­Kapazitäten von 256 TB per I/O­Gruppe auf
1.024 TB zu steigern, und eröffnet jetzt die Möglichkeit, eine
maximale Kapazität von 8 PetaByte (vorher war es nur 2 PB)
per SVC­Cluster abzubilden.
Im Mai 2008 kündigt IBM den SVC Release 4.3 mit Verfüg­
barkeit im Juni 2008 an. Der Release 4.3 enthält viele
Erweiterungen und neue Funktionen, die im Folgenden
beschrieben sind.
Space Efficient Virtual Disk (SEV)
Space Efficient Vdisk ist nichts anderes als ”Thin Provisioning”
oder ”Storage Overallocation”.
Anwender können virtuelle Disks erzeugen, die eine unter­
schiedliche reale und virtuelle Kapazität haben. Die reale
Kapazität definiert, wie viel physische Kapazität tatsächlich
durch eine Vdisk verwendet wird. Die virtuelle Kapazität
definiert, wie groß die virtuelle Disk den angeschlossenen
Servern gegenüber erscheint.
Eine SEV unterscheidet sich nur minimal von normalen
Disks und kann wie eine normale Disk vergrößert oder verkleinert
werden. Sie wird wie andere NON SEV Disks aus
jedem beliebigen Pool erzeugt. Die Umwandlung zwischen
SEV und NON SEV wird über Vdisk Mirroring durchgeführt.
SEVs helfen Platz einzusparen von allokierter, aber nicht
genutzter Kapazität. Das Einsparungspotenzial hängt von
der Betriebssystem­Umgebung und der Anwendung ab (in
Windows­Umgebungen oft über 50%). SEVs verbessern
den Ausnutzungsgrad der physischen Disks zusätzlich
(neben dem schon vom Pooling­Konzept der Disk­ und
Spare­Kapazität herrührenden Potenzial). SEV ist die Basis
für Space Efficient FlashCopy.
Space Efficient FlashCopy (auch als SnapShot bekannt)
Space Efficient FlashCopy funktioniert wie Standard Flash­
Copy mit dem Unterschied, dass das FlashCopy Target eine
Space Efficient Vdisk ist. Damit wird für den FlashCopy nur
so viel Platz allokiert, wie aktuell benötigt wird.
Virtual Disk Mirroring
Vdisk Mirroring kann man sich wie einen internen LVM
(Logical Volume Manager) in einer AIX­Umgebung vorstellen.
Vdisk Mirroring stellt eine neue Vdisk­Konfiguration dar, bei
der eine ‘gespiegelte Vdisk’ zeitgleich auf zwei unterschiedliche
Mdisk­Sets geschrieben wird, die normalerweise
auf zwei unterschiedlichen Disk­Systemen liegen. Der SVC
hält beide Kopien synchron. Im Versagensfall eines Spei­
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

chersystems hat das keinen Einfluss auf die Verfügbarkeit
einer gespiegelten Vdisk. Der Spiegel wird nach Wiederverfügbarkeit
automatisch resynchronisiert. Spiegelkopien können
gesplittet werden und die Mdisks können in Disk
Groups mit unterschiedlichen Extent Sizes liegen. Dabei
können eine oder beide Kopien Space Efficient sein. Vdisk
Mirroring kann zusammen mit den SVC Copy Services
genutzt werden.
Normalerweise werden SVC­Cluster in einem Rechenzentrum
aufgebaut. Mit Vdisk Mirroring besteht die Möglichkeit,
einen ‘Stretched SVC Cluster’ aufzubauen (RPQ notwendig),
indem die Knotenpaare auf jeweils zwei Rechenzentren verteilt
werden. Die SVC­Knotenpaare werden dabei über
Longwave FC im Switch verbunden. Distanzen von bis zu
10 km sind möglich.
Erhöhung der FlashCopy Target Volumes auf 256
Für die Kapazität von FlashCopy gibt es nur noch zwei
Begrenzungen: Aus einem Source Volume können bis zu
256 Target Volumes erzeugt werden und die maximale
Kapazität von allen Spiegelaktionen darf 1 PB nicht überschreiten.
Es bestehen nun keine Einschränkungen mehr
bezüglich der Vermischung von Copy­Aktionen.
Höhere Skalierbarkeit von Virtual Disks
Die Skalierbarkeit in der Anzahl an Virtual Disks wurde verdoppelt
und auf 8.192 Virtual Disks erhöht.
SVC Entry Edition
Zeitgleich mit dem Release 4.3 stellt IBM auch eine kostengünstige
Einstiegslösung, die SVC Entry Edition, zur Verfügung.
Diese Geräte basieren auf einem x3250 Server mit
einem Intel Xeon E3110 3,0 GHz 6 MB L2 Cache Dual­Core
Prozessor. Wie das aktuelle Modell 8G4 haben die Entry
Geräte 8 GB Cache und vier 4 Gbps FibreChannel­
Anschlüsse. Die SVC Entry Edition ist preislich um ca. 40%
günstiger positioniert und erreicht ca. 60% des Durchsatzes
und der Leistungsfähigkeit des 8G4­Modells.
Neue leistungsstarke SVCs mit Solid State Disks (SSDs)
mit SVC Release 5.1
Im Oktober 2009 kündigt IBM mit Verfügbarkeit November
2009 den SVC Release 5.1 an, der neben funktionalen
Erweiterungen neue leistungsstärkere Prozessor­Hardware
beinhaltet. Das neue SVC Modell 2145 CF8 basiert auf dem
IBM System x3550 M2­Server mit Intel Core i7 quad­core
2,4 GHz Prozessoren und leistet nahezu das Doppelte wie
der Vorgänger 2145 8G4. Die neuen Maschinen sind mit der
dreifachen Cache­Größe von 24 GB ausgestattet und eine
I/O­Gruppe bietet damit 48 GB als Cache­Speicher an.
Damit ergeben vier Knotenpaaren im Clusterverbund eine
Cache­Größe von 192 GB. Jeder SVC­Knoten bietet zudem
8 x 8 Gbps FC­Ports. Das heißt, im Maximalausbau mit vier
Knotenpaaren im Cluster stehen 32 x 8 Gbps FC­Ports zur
Verfügung. Durch die schnelleren Prozessoren und die
Verdreifachung des Caches gewinnt der SVC eine ungewöhnlich
hohe Leistungsfähigkeit. Per I/O­Gruppe, also per
Knoten, werden 120.000–140.000 IOPS möglich, im Vollausbau
also 480.000–540000 IOPS.
Die neuen SVC Engines können mit eingebauten SSDs
(Solid State Disks) ausgestattet werden. Bis zu vier SSDs
mit einer Kapazität von 146 GB können in eine Engine eingebaut
werden, per I/O­Gruppe also bis zu acht SSDs und
damit einer SSD­Bruttokapazität von 1.168 GB per I/O
Group. Dabei werden nur 600 GB genutzt, weil der Großteil
der SSDs gespiegelt wird. Bei einer maximalen Konfiguration
mit vier Knotenpaaren im Cluster stehen damit bis zu 2,4 TB
an nutzbarer SSD­Kapazität zur Verfügung.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
115

116
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
iSCSI-Unterstützung
Die neuen SVC­Geräte können auch mit eingebauten Ethernet­Ports
ausgestattet werden und so direkt an iSCSI angeschlossen
werden. Es werden dazu die vorhandenen LAN­
Ports des SVC verwendet.
Fällt ein Knoten des SVCs aus, wird die entsprechende IP­
Adresse auf den anderen Knoten übernommen. Somit ist es
nicht nötig, MPIO­Software für iSCSI auf dem Host zu installieren.
Neue Funktionen
Mit Release 5.1 stehen dem SVC neue Funktionen zur Verfügung.
Reverse FlashCopy erlaubt FlashCopy Targets als
‘Restore Point’ für die Source zu werden, ohne dass die
FlashCopy­Beziehung aufgebrochen wird. Dabei werden
multiple Targets und multiple ‘Roll Back Points’ unterstützt.
Multiples Cluster Mirroring erlaubt den Aufbau einer dreifachen
Spiegelung. Vier SVC­Cluster bilden eine Mirror­
Gruppe. Jede Disk kann von jedem Cluster auf einen anderen
Cluster gespiegelt werden.
Installationsbasis Dezember 2009
Weltweit wurden bis zum Dezember 2009 über 17.000 SVC­
Knoten ausgeliefert. Diese Knoten sind in mehr als 5.000
SVC­Systemen im produktiven Einsatz.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Backup-Konzepte
Unabhängig von der jeweiligen Implementierung, ist die
Bedeutung eines Backups von unternehmenskritischen Daten
unbestritten. Zu den klassischen drei Business­Faktoren
Mensch, Boden und Kapital hat sich in den letzten Jahren ein
weiterer Faktor geradezu aufgedrängt. Der Faktor Information.
Informationen sind die Lebensader jedes Unternehmens
und die IT ist dazu da, den Bestand und die Weiterentwicklung
dieser Lebensader zu sichern und zu unterstützen.
Ein Backup ist eine Datenkopie an einem je nach Implementierung
lokalen oder entfernten Ort. Eine solche Datenkopie
schützt vor dem totalen Verlust bei menschlichen Fehlern,
Hardware­Fehlern, Virusinfektionen und totalem Verlust einer
Lokation. Ein gut durchdachtes Backup­Konzept ist eine persönliche
Versicherung für den Fortbestand der Arbeitsfähigkeit
und somit im Extremfall für den Fortbestand eines
gesamten Unternehmens.
Plattentechnologie vs. Bandtechnologie im Backup-Umfeld
Eine Platte bietet direkten Zugriff und Vorteile beim Single File
Restore und Filesystem Restore. Ebenso bietet sich die Möglichkeit
mit „multiple Streams“ auf der Platte zu arbeiten,
umso die Backup­Zeitfenster zu reduzieren. Platten haben
aber genauso Nachteile! Sie bieten keinen Vorteil bei großen
File Backups oder Full Image Backups (hier ist das Tape
meis tens wesentlich schneller). Platten können nicht bewegt,
also nicht als bewegliche Datenträger eingesetzt werden, sie
benötigen Strom und kosten bei entsprechend hohen Kapazitäten
mehr als Tape­Lösungen. Auch stellt sich die fundamentale
Frage, welche Plattentypen setzt man für den
Backup ein? Sollen es ATA­, SATA­, FATA­, SAS­ oder FC­
Platten sein? Was ist das richtige Preis­Leistungs­Verhältnis in
Relation zur Zuverlässigkeit und Sicherheit?
Tapes dagegen sind sequentielle ‘Streaming Devices’ und
heute in der Datenrate meistens schneller als Platten. Deshalb
ist es in der Regel performanter, große Files oder große
Datenbanken direkt auf native Tapes wegzusichern. Tapes
sind ‘On Demand’, skalieren also in Performance und Kapazität,
indem einer Tape Library entweder zusätzliche Laufwerke
oder zusätzliche Kassetten zugeführt werden.
Tapes sind austauschbare Datenträger, das heißt, sie können
in Sicherheitsräume ausgelagert werden oder zwischen
unterschiedlichen Lokationen ausgetauscht werden. Tapes
benötigen keinen Strom, wenn sie einmal beschrieben sind,
und sind wesentlich länger haltbar (LTO als ECMA­Standard
bis zu 30 Jahre). Neben überschreibbaren Kassetten stehen
heute nahezu in allen Tape­Technologien auch WORM­Bänder
(Write Once read Many) zur Verfügung, die sich besonders
im Umfeld der Langzeitarchivierung einsetzen lassen.
Welche Alternativen stehen uns heute für ein sicheres Backup zur
Verfügung?
Das klassische und traditionelle Backup beginnt mit einem
lokal an den Server angeschlossenen Bandlaufwerk. Bei
mehreren Servern wird dies sehr schnell betreuungsintensiv
und skaliert daher nur begrenzt. Der nächste Schritt dazu
wäre eine zentrale, LAN­basierte Datensicherung z. B. über
TSM und einen entsprechenden Backup­Server, bei dem
Disk­ oder Tape­Systeme direkt an die Server angeschlossen
werden. So können mehrere Server eine gemeinsame Bandsicherungs­Infrastruktur
nutzen (z. B. eine Tape Library). Bei
größeren Datenvolumen, z. B. bei DBs, bietet sich ein SANbasiertes
Backup an, das die hohen Daten­Transfermengen
vom lokalen Netzwerk (LAN) fernhält und so insbesondere
Vorteile bei der Geschwindigkeit und Zugriffsmöglichkeit realisiert.
Trotz der immensen Weiterentwicklungen im Tape Bereich,
immer kürzeren Zugriffszeiten mit höheren Schreibdurchsätzen
und Kapazitäten sind die Daten trotzdem nicht im dauerhaften
Zugriff (Online).
Dies kann nur durch eine Diskspeicherinfrastruktur erreicht
werden. Vor dem Hintergrund des Preisverfalls bei Festplattenlaufwerken,
insbesondere bei den günstigen SATA­Platten
(Serial ATA) ergeben sich mannigfaltige Möglichkeiten. Eine
Möglichkeit ist, das Backup­Konzept komplett von Tape auf
Disk umzustellen. Dadurch wird eine hohe Verfügbarkeit und
Geschwindigkeit erreicht, jedoch ist es schwierig bis unmöglich,
die Daten physisch in eine entfernte Lokation zu bringen
(Bergwerk, Bunker, Vault, Bank). Je nach Sensibilität der Daten
wird dies empfohlen bzw. ist z.T. Bestandteil von gesetzlichen
Vorgaben. Zudem entstehen sehr hohe Energiekosten sowie
zusätzliche Migrationsaufwände bei einer reinen Disklösung,
die den Vorteil der vermeintlich günstigen Hardware­
Investition schnell aufheben. Um die Vorteile beider
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
117

118
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
Technologien nutzen zu können, setzt sich zunehmend die
Kombination von Disk und Tape durch für ein schnelles,
hochverfügbares und trotzdem sicheres Backup. Dies ist
industrieweit bekannt als Disk­to­Disk­to­Tape­Backup. In diesem
Konzept werden die Disks als Backup­Puffer (Staging
Area) benutzt, um kürzlich zurückliegende Backups für eine
gewisse Zeit online zu halten und dann nach Ablauf einer
gesetzten Frist auf Tape auszulagern. Dies gilt auch bei Virtualisierungslösungen
von Tape: Hier werden Tape­Laufwerke
auf Disk emuliert, d. h., Disks stellen sich dar wie ein Bandlaufwerk.
Integrierte Tape­Virtualisierungslösungen kombinieren
Hardware und Software zu einer einfach bedienbaren Virtuellen
Tape Library (VTL). Erst die Möglichkeit, auch auf
physische Tapes zu migrieren, bietet eine operative, kostengünstige
und effiziente Umgebung.
Wird mit einer Kombinationslösung aus Platte und Band gear­
beitet, stellt sich die Frage, wie groß muss das vorgeschaltete
Plattensystem von der Kapazität sein, wie muss die Tape
Library dahinter konfiguriert werden und wie implementiert
man die Migration von Platte auf Band sinnvoll! Individuelle
Sizings der vorhandenen Umgebung und der benötigten
Anforderungen sind für eine sinnvolle Lösung notwendig!
Es gibt VTLs auf dem Markt, die keine Tape­Anbindung
haben. Da stellt sich diese Frage natürlich nicht! Allerdings
ist von solchen Konzeptionen dringend abzuraten, da es in
eine technologische Einbahnstraße führt, aus der man nur
wieder mit sehr viel Aufwand und Kosten herauskommt. VTLs
ohne Tape­Anbindung mit sehr günstigen ATA­ oder SATA­
Platten müssen in der Regel komplett nach drei Jahren aus
Sicherheitsgründen ausgetauscht werden, um Plattenausfälle
und Datenverlust zu vermeiden. Sind hier sehr große Kapazitäten
betroffen, kommt es in der Regel zu einer regelrechten
Kostenexplosion!
Beim Einsatz von VTLs und Diskbuffern kann eine effektivere
Nutzung des Plattenpuffers durch De­Duplizierungsverfahren
eine große Menge an sonst benötigten Plattenplatz einsparen,
weil nur noch Datenblöcke einmal abgespeichert werden
und Duplikate vermieden werden. Die Einsparung ist dabei
direkt vom erzielten De­Duplizierungsfaktor abhängig. Es gibt
verschiedene De­Duplizierungsverfahren von unterschiedlichen
Anbietern. Die wichtigste Anforderung an ein De­Duplizierungsverfahren
ist die Sicherstellung einer 100%igen
Datenintegrität neben skalierbarer Leistungsfähigkeit. Nur
Verfahren mit 100%iger Datenintegrität stellen eine sichere
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Restore­Möglichkeit zur Verfügung, denn Backup macht man
wegen des Restores!
Die erzielten De­Duplizierungsfaktoren sind von vielen Gegebenheiten
abhängig: Welche Backup SW ist im Einsatz, wie
wird die Sicherung durchgeführt (z. B. immer inkrementell
oder jede Woche einen Full Backup etc.) und wie lange soll
die Retentionperiode sein, wo die Daten im Plattenpuffer
gespeichert bleiben (siehe auch unter Daten­De­Duplizierung).
Welches Konzept bezüglich der Anforderungen Leistung,
Sicherheit, Kosten, Haltbarkeit und einfache Erweiterbarkeit
die beste Effektivität bietet, ist von der vorhandenen Infrastruktur
abhängig und ob die Daten klassisch über das LAN
oder LAN­free über das SAN oder beides gesichert werden.
In den meisten Fällen bieten sich Kombinationslösungen von
Platte und Band an, um die Stärken beider Technologien entsprechend
für einen effektiven Backup und Restore zu nutzen.
Wichtig ist, dass Daten­Backup sicher und zuverlässig ist und
die Wiederherstellung der Daten in jedem Fall gewährleistet
wird. Das gilt für unvorhergesehene Feher wie z. B. Disaster
(Naturkatastrophen, Hochwasser, technische Fehler, Disk­
Crash), aber auch für menschliche Fehler (versehentliches
Löschen von Daten, falsches Bearbeiten von Dateien) und
Application Errors (Virus, Fehler in der Software). Es ist also
u. a. wichtig, dass Datenkopien an verschiedenen Lokationen,
auf unterschiedlichen Medien und mit unterschiedlichen Tools
bzw. Software und von verschiedenen Verantwortlichen
erzeugt werden. Snaps in derselben Einheit bieten alleine keinen
Schutz, Spiegelung mit derselben Software ebenfalls
nicht!
Der Anspruch an den Sicherheitsgrad sowie die Wiederher­
stellungszeit (Recovery Time Objective) spielen für die Auswahl
der Komponenten respektive der Backup­Strategie
ebenso eine entscheidende Rolle.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
119

120
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
Virtualisierung von Bandsystemen
Neue Server-basierende Tape-Virtualisierung für System z
Am 29. August 2006 kündigte die IBM eine neue Virtualisierungslösung
für die z/OS­Umgebung an. Die TS7700 wird
als Nachfolger der IBM 3494 B10 und B20 Virtual Tape
Server Ende September 2006 verfügbar. Dies war insbesondere
auch deshalb notwendig, weil die alten Einheiten B18,
B10 und B20 nicht der ab 1. Juli gültigen EU­Richtlinie
RoHS entsprachen. Die neue TS7700 Serie für die Bandvirtualisierung
im Mainframe­Umfeld bildet eine neue, langfristige
Basis durch eine modulare und skalierbare Server­
Architektur. Man spricht von einer ‘Distributed Node
Architecture’.
Die TS7700 besteht aus dem 3592 Gehäuse F05, der
TS7740­verteilten Node­Architektur mit unterschiedlichen
Nodes (siehe unten), die entsprechende Funktionen wahrnehmen,
einschließlich zwei aktiv geschalteter ‘I/O­Drawer’,
die entsprechende FICON­Anschlüsse zum Host, Fibre­
Channel­Anschlüsse zu den Platten und Ethernet­Verbindungen
zum Library Manager zur Verfügung stellen, dem
TS7740 Cache Controller als RAID­Steuereinheit und entsprechenden
RAID­basierenden Platteneinschüben, die den
TVC (Tape Volume Cache) als Plattenpuffer reflektieren.
Für die Plattenpufferkapazitäten werden RAID­Arrays mit
146­GB­Platten eingesetzt. Der RAID Controller arbeitet mit
16 integrierten Platten, eine TS7740 Cache­Erweiterung
beinhaltet ebenfalls 16 Platten. In die Gehäuseeinheit sind
neben dem RAID Controller bis zu drei Plattenerweiterungseinheiten
integrierbar. Damit können bis zu 64 Platten in die
Grundeinheit eingebaut werden. Die Gesamtkapazität liegt
bei 6 TB (native) und 18 TB (komprimiert).
Nodes sind funktionale Aufgaben, die als Applikation auf
einem aus zwei Dual­Core 64 bit, 1,9 GHz Prozessoren
bestehenden pSeries­Server laufen. Das vNode (v steht für
Virtual) stellt dem Host virtuelle Laufwerke zur Verfügung
und ist für die Host­Kommunikation verantwortlich. Das
hNode (h steht für Hierarchical Storage Management) ist für
die Verwaltung der logischen Volumes im Plattenpuffer
zuständig. Es managt auch die Migration von Platte auf
Band und ist für die gesamte Verwaltung der physischen
Band­Ressourcen einschließlich des Tape­Reclamation­Prozesses
zuständig. Die Kombination aus vNode und hNode
wird als gNode (g steht für general) bezeichnet und reflek­
tiert die Virtualisierungseinheit des Systems. Dieser Aufbau
erlaubt einfache zukünftige Skalierung bezüglich der Kapazitäten
und der Leistung, indem mehrere gNodes oder auch
nur vNodes im Cluster miteinander gekoppelt werden.
Die Ankündigung enthält ein ‘SOD’ (Statement of Direction),
nachdem ein Cluster mit zwei gNodes verfügbar sein wird.
Das sorgt für erhöhte Verfügbarkeit, erhöhte Performance
sowie mehr virtuelle Devices innerhalb des Clusters und
ermöglicht unterbrechungsfreie Code­Updates. Bei späteren
Erweiterungen können dann vNodes und hNodes auf unterschiedlichen
Systemen laufen und so horizontal innerhalb
des Clusters skalieren. Zukünftig vorstellbar ist, dass die
vNodes dann unterschiedliche Aufgaben wahrnehmen, z. B.
Virtualisierung für Open Systems oder Datenarchivierung.
IBM TS7700 Virtual Tape Server für zSeries
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Zwei Cluster können heute in einem Dual Cluster Grid
(oder auch Multi Cluster Grid) zusammengeschlossen wer­
den und dienen dazu, entsprechende Disaster­Recovery­
Lösungen aufzubauen. Sie sind in der Funktionsweise dem
Peer to Peer VTS mit den Modellen B10 und B20 vergleichbar
(synchrone und asynchrone Spiegelung). Dazu ist das
neu angekündigte TS7700 Grid Communication Feature notwendig.
Seit August 2007 sind Konfigurationen von drei Clustern in
einem Grid möglich. Die Architektur selbst erlaubt langfristig
bis zu acht Cluster in einem Grid und wird in einer späteren
Ankündigung bekanntgegeben.
Der Unterschied der Spiegelung liegt darin, dass bei der
TS7700 dedizierte Ethernet­Verbindungen (IP) eingesetzt
werden. Mit zwei 1­Gbit­Ethernet­Verbindungen wird die
Spiegelung durchgeführt, sie ist wesentlich leistungsfähiger
im Vergleich zu Peer to Peer VTS mit FICON. Das senkt
die Kosten, nutzt offene Standards und vereinfacht die
Infrastruktur.
Die Einheit bietet neben dem 6­TB­Plattenpuffer (18 TB
komprimiert) einen maximalen Durchsatz von 600 MB/s
(Peak) und damit knapp das Doppelte einer 3494­B20. Es
stehen bis zu vier 4­Gbit­FICON­Anschlüsse in dieser Basiseinheit
zur Verfügung. Unterstützt ist die TS3500 Library
(3584 Library) über die Anbindung des IBM 3953 Library
Managers Modell L05. Die Einheit unterstützte im Backend
TS1120 Laufwerke im Emulation­Mode der 3592 J1A. Seit
Februar 2007 ist auch die ‚Native‘­Unterstützung verfügbar.
Bis zu 16 physische Bandlaufwerke TS1120 können an einer
TS7700 betrieben werden.
Zum z/OS­Host werden wie bei den alten VTS­Modellen
3490­E Laufwerke abgebildet. Funktional bietet die neue
Einheit Funktionen, die bei dem Modell 3494­B20 zur Verfügung
standen. Dies sind vor allem die Funktionen des APM
(Advanced Policy Management) wie ‘Volume Pooling’, ‘Dual
Copy’, ‘Logical Volume Sizes’ und ‘Multiple Reclamation
Policies’ (Beschreibung der Funktionen unter 3494­B20), die
bei TS7700 als Outboard Policy Management bezeichnet
werden.
Die TS7740 Node emuliert zum Host viele 3490­E Laufwerke,
die für den Host wie physikalisch vorhandene Laufwerke
sichtbar sind. Die TS7740 ist also völlig transparent
zum Betriebssystem, zum Bandverwaltungssystem und zum
Katalogeintrag. Die emulierten Laufwerke bezeichnet man
als virtuelle Laufwerke. Die TS7700 unterstützt bis zu 256
virtuelle Laufwerke sowie bis zu 100. 000 virtuelle Volumes
und dies erhöht sich später durch die Bildung von Multi
Node Clustern entsprechend. In einem Dual Cluster Grid
(Spiegelung) stehen 512 virtuelle Laufwerke zur Verfügung.
Geschrieben wird in den verfügbaren Plattenpuffer, den
TS7740 Cache (ebenso wird bei Recalls aus dem Plattenpuffer
gelesen). Ist ein Volume im Plattenpuffer gespeichert,
wird dieses als virtuelles Volume bezeichnet. Durch einen
Algorithmus, der als Premigration bezeichnet wird, werden,
etwas zeitversetzt, Kopien der virtuellen Volumes auf die
physischen Bandlaufwerke migriert und auf physische 3592
Kassetten geschrieben. Die Kopie des virtuellen Volumes,
das jetzt auf einer physikalischen Kassette gespeichert ist,
wird als logisches Volume bezeichnet. Viele logische
Volumes auf einer Bandkassette nennt man ‘Stacked
Volumes’. Ein Stacked Volume ist also eine physikalische
Kassette, die viele logische Volumes enthält.
Durch den Premigration­Prozess werden die Laufwerkgeschwindigkeiten
der physischen Laufwerke voll genutzt.
Ebenso werden die Kassetten in ihrer Kapazität maximal
ausgenutzt, weil viele logische Volumes auf einer Kassette
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
121

122
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
gespeichert werden. Kommt ein Recall des Hosts auf ein
logisches Volume, wird der Recall aus dem Plattenpuffer
bedient, solange das Original des virtuellen Volumes dort
noch verfügbar ist. Ist das virtuelle Volume im Plattenpuffer
nicht mehr verfügbar, wird die physische Kassette, welche
die Kopie des logischen Volumes enthält, in ein Bandlaufwerk
geladen.
Das angeforderte logische Volume wird dann in den Plattenpuffer
zurückgeladen und der Recall wird aus dem Plattenpuffer
bedient.
Sollte aufgrund einer großen Schreib­Workload der Plattenpufferplatz
(TS7740 Cache) knapp werden, werden im Plattenpuffer
die virtuellen Volumes, die am wenigsten benutzt
wurden (LRU Least Recently Used Algorithmus), zum Überschreiben
freigegeben, nachdem deren Kopie bereits auf
Band ‘pre­migriert’ wurde.
Der Reclamation­Prozess der physischen Kassetten findet
im Hintergrund von Laufwerk zu Laufwerk statt, ohne dass
der Plattenpuffer belastet wird. Es erfolgt kein Zurückladen
der noch validen logischen Volumes auf der Kassette in den
Plattenpuffer, sondern diese werden direkt von Laufwerk zu
Laufwerk auf eine neue Kassette geschrieben. Die alte Kassette
geht dann automatisch in den vorhandenen Scratch
Pool zurück.
Die TS7700 bildet die neue Basis eines Mainframe­basierenden
Virtual Tape Servers. Es sind viele neue Funktionalitäten,
Verbesserung in Leistung und Kapazität und größere
Konfigurationen in den nächsten Monaten vorgesehen, die
die TS7700 zum absoluten Tape­Virtualisierungsspezialisten
im Mainframe­Umfeld machen, der mit keiner anderen
Lösung vergleichbar ist. Das war bereits mit den Modellen
B10 und B20 der Fall, die als einzige Systeme über die APM­
Funktionalität eine Verbindung ins SMS (System Managed
Storage) als Teil des z/OS­Betriebssystems hatten. Dabei
werden die SMS­Konstruktnamen, wie Data Class, Storage
Class und Management Class, sowie die Storage­Group­
Namen einschließlich der VolSer­Zuordnung automatisch in
die Library Manager Data Base übernommen. Das bietet
kein anderes System auf dem Markt.
Sowohl für die 3494­B10­ und ­B20­Modelle als auch für die
neue TS7700 ist eine noch stärkere Integration in das SMS
des z/OS­Betriebssystems längerfristig vorgesehen.
Grid-Spiegelungen mit TS7700 Systemen
Bei einer Multi­Cluster­Grid­Spiegelung ist es erforderlich zu
definieren, wie jede Storage Group eines jeden Clusters im
Grid zu behandeln ist. Das Setzen einer Policy auf dem LM
definiert den Consistency Point für jede definierte Site im
Subsystem. Aus den Policies wird ein Array aus Consistency­
Point­Werten, wobei jedes Element des Arrays die Policy für
eine bestimmte Site repräsentiert. Wenn z. B. für Site A eine
Kopie zum Zeitpunkt des Unloads und für Site B eine Kopie
zu einem späteren Zeitpunkt gewünscht wird, sieht das Array
so aus: Site A hat RD und Site B hat RD.
Die Replication Policies können auf den LMs verschieden
sein. Die Policy Settings auf jedem LM diktieren, welche
Aktionen ausgeführt werden, wenn ein Volume auf einem
virtuellen Laufwerk, das zu diesem LM gehört, gemountet
wird. Consistency Policies bestimmen die Site, welche die
Daten als erste erhält (TVC Selektion), welche Sites eine
Kopie der Daten erhalten und zu welchem Zeitpunkt.
Consistency Policies werden über die Management Class
konfiguriert. Dabei werden Policies einem Management­
Class­Namen zugeordnet. Policies werden über den ETL
Specialist auf dem Library Manager gesetzt.
Eine neue Definition ist die des ‘Copy Consistency Points’,
der bestimmt, wann ein Target Volume auf einer TS7700 mit
dem Source Volume konsistent ist. Bei den Consistency
Policy Optionen werden für jede Site Consistency Points
gesetzt. Dabei stehen drei Definitionen zur Verfügung:
RUN (R) – diese Site benötigt eine valide Kopie des
logischen Volumes, bevor Device End an den RUN­Befehl
(Rewind Unload) vom Host geliefert wird (entspricht weitgehend
dem Immediate Mode beim PtP VTS).
Deferred (D) – diese Site benötigt eine valide Kopie zu
einem späteren Zeitpunkt, nachdem der Job beendet wurde
(ähnlich wie Deferred Mode beim PtP VTS).
No copy (N) – diese Site soll keine Kopie von Volumes in
dieser Management Class erhalten.
Durch diese neue Möglichkeit können extrem flexible
Spiegel varianten in Multi­Cluster­Grid­Konfigurationen
realisiert werden.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

TS7700 Erweiterungen 2007
Bei der Ankündigung der TS7700 machte IBM die Aussage,
dass mit vier zusätzlichen Releases im Jahr 2007 in die
TS7700 Systeme eine Vielfalt von neuen funktionalen Erweiterungen
integriert werden, die weit über den Rahmen des Vorgängersystems
B20 hinausgehen. So wurde jedes Quartal ein
neuer Release verfügbar, R1.1 im 1., R1.2 im 2., R1.3 im 3.
und R1.4 im 4. Quartal 2007. Die verfügbaren Funk tionen
werden in AF­basierende Funktionen (Advanced Functions)
und Nicht­AF­basierende Funktionen unterschieden.
Advanced Functions (AF)
Die Funktionalität ‘Logical Volume Pooling’ bietet die Möglichkeit,
logische Volumes einzeln pro Nummernkreis in
unterschiedlichen physischen Kassetten­Pools zu verwalten.
Damit ist die TS7700 mandantenfähig.
Mit ‘Tape Volume Cache Management’ können logische
Volumes einer Cache Management Preference Group zugeordnet
werden. Es stehen zwei Preference Groups zur Verfügung.
Die Preference Group steuert, wie die logischen Volumes
im Plattenpuffer behandelt werden, und beeinflusst
die Verweildauer von virtuellen Volumes im Tape Volume
Cache (Plattenpuffer). Mit ‘Dual Selective Copy’ können zwei
Kopien eines logischen Volumes in zwei unterschiedlichen
TS7700
Cluster 0
3-Cluster-Spiegel-Grid
R 0
R 1
D 2
Host
physischen Kassettenpools erzeugt werden. Die TS7700
speichert dann zum Schutz vor einem Mediendefekt ein
Duplikat eines logischen Volumes auf einer zweiten Kassette.
‘Cross-site Replication’ wird in einer Grid­Konfiguration
verwendet, um eine Kopie in einer zweiten Site zu erzeugen.
Je nach Ein stellung erfolgt dies auf synchroner oder asyn­
chroner Basis. Es können aber auch ungespiegelte Volumes
in einer Grid­Konfiguration verwaltet werden. ‘Logical Virtual
Volume Sizes’ dient der Auswahl von Volume größen, die
die Standard­Volumegrößen von 400/800 MB übersteigen.
Zur Wahl stehen 1.000, 2.000 und 4.000 MB.
Secure Data Erasure mit Encryption Shredding reflektiert
die Wiederkehr der bereits aus dem VTS bekannten Funktion
zur vollautomatisierten ‘Zerstörung’ von Datenbeständen auf
Leerkassetten (nach Reklamation). Das ist ein genialer Trick,
wenn TS1120 Tape Encryption im Einsatz ist: ‘nur’ der Schlüssel
wird auf der Kassette gelöscht, nicht die gesamte Band­
Datenstruktur! Bei einem 3-Site-Grid wird ein TS7700 Grid so
erweitert, dass bis zu 3 Cluster für noch besseren Business
Continuity Support zur Verfügung stehen (Dreifach­Remote­
Spiegelung). Jetzt können in einem 3­Site­Grid zwei TS7700
z.B. lokal synchron gespiegelt werden und beide Systeme
dann asynchron in großer Entfernung über WAN in eine
dritte TS7700.
WAN
TS7700
Cluster 1
TS7700
Cluster 2
Dreiseitiger TS7700 Spiegel-Grid, Cluster 0 und 1 sind synchron gespiegelt und Cluster 0 und 1 asynchron über eine WAN-Strecke auf Cluster 2
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
R 0
R 1
D 2
R 0
R 1
D 2
123

124
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
Copy Export (Stand­Alone­Systeme in R1.3, Grid­Systeme
in R1.4) erlaubt es, eine Gesamt­Kopie der Daten einer
TS7700 zu exportieren, z. B. für Disaster Recovery­Zwecke,
während die originalen Daten weiterhin in der TS7700 verbleiben
und für die Produktionssite verfügbar sind.
Copy Export ist eine neue TS7700 Funktion zur Unterstützung
des Transfers von Daten (auf Stacked Tapes) in eine
regionale/überregionale Sicherheitszone für Disaster­Recovery­Zwecke.
Dabei kann mit der Funktion Dual Selektive
Copy eine Kopie von Volumes innerhalb einer TS7700
erzeugt werden, die in einem separaten Storage Pool und
damit separaten Kassetten abgespeichert wird. Copy Export
exportiert dann eine Kopie von ausgewählten Daten (log.
Volumes), die primäre Kopie verbleibt dabei allerdings in
der produktiven TS7700.
Die ‘Copy Exported physical Volumes’ werden weiterhin von
der produktiven TS7700 verwaltet, d. h., die Volumes werden
weiterhin in der TS7700 Datenbank geführt. Die TS7700
managt dabei auch den ‘Offsite’ Volume Reclamation­Prozess
(Recycling der ausgelagerten Kassetten). Informationen
über die exportierten Volumes können über einen Host
Console Request und einen BVIR Request initiiert werden.
Ein ‘Copy Export Recovery’ wird durch das TS7700
Management Interface unter dem Service­ und Troubleshooting­Menü
oder per User­Id und Password mit ‘role­based’­
Zugriff durchgeführt. Die TS7700 ist ‘offline’ zu den Hosts
während der Recovery. Dabei wird die VolSer des Volumes
benötigt, von welchem die Datenbank restored werden soll.
Es besteht auch die Kunden­Option zur Bereinigung bestehender
Datensätze in einer TS7700 für den Copy Export
Recovery­Vorgang (mfg cleanup). Während des Recovery­
Prozesses ist das einzig angezeigte Panel im Management
Interface das Status Panel zum Copy Export Recovery. Wenn
die Recovery abgeschlossen ist, kann die TS7700 wieder
‘online’ zu den angeschlossenen Hosts genommen werden –
sobald dort TCDB und TMS ebenfalls wieder restored sind.
Zusätzliche Funktionen (Nicht-AF)
Autonomic Ownership Takeover
Ownership bedeutet, dass jedes Volume in einer Grid­Konfiguration
einen Owner hat (Cluster). Um ein Volume auf einem
bestimmten Cluster zu ‘mounten’, muss der Cluster Owner
sein. Ist er es nicht, requestiert die TS7740 auf dieser Clustersite
den Ownership­Transfer von der anderen Clustersite.
Im Falle, dass die andere Site nicht reagiert, wird über die
TSSC (Total Storage Service Console) geprüft, was mit der
TS7740 auf der anderen Site los ist. Ist die TS7740 tatsächlich
nicht mehr verfügbar, wird der Autonomic Ownership
Takeover initiiert. Der Ownership­Transfer kann auch immer
manuell angestoßen werden.
Tape TS1120 Encryption Support
Mit der TS7740 wird eine Verschlüsselung auf den angeschlossenen
TS1120 Bandlaufwerken unterstützt (ab Release 1.2).
Die virtuellen Laufwerke haben damit nichts zu tun. Encryption
wird durch die existierenden Storage Pools (bis zu 32
Pools) auf der TS7740 gemanagt. Der Host verwendet die
existierenden Storage­Konstrukte der Storage Groups und
der Management Class, um festzulegen, welche logischen
Volumes auf welchen Pool physischer 3592 Kassetten kommen.
Ist ein Pool definiert, wo mit Encryption gearbeitet werden
muss, wird er entsprechend behandelt. Dabei kann für
jeden Pool definiert werden, welche ‘Public/Private’ Key­
Paare verwendet werden, um verschlüsselte Schlüssel auf
der Kassette abzuspeichern, die mit Verschlüsselung bearbeitet
wurden.
Host Console Request
Diese Option erlaubt einem MVS Console Operator das
Durchführen von Abfragen und eine einfache Problemanalyse
zum TS7700 Zustand, ohne Zugriff auf das Web Interface
(MI) zu haben.
Enhanced Automated Read Only Recovery (im Backend)
Hier handelt es sich um die Wiederkehr der bereits im Vorgänger
VTS bekannten Funktion zur vollautomatisierten
Recovery von fehlerauffälligen 3592 Backend­Kassetten,
auch unter Nutzung der 2. Kopie in einem Grid­System.
Remote Read and Write Pipelining
Diese Funktion bringt erhebliche Performance­Verbesserungen
beim Lesen und Schreiben in den ‘remote’ Cache
einer TS7700 im Grid.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

FICON
Die bisherigen 128 logischen Kanäle per FICON­Kanal, die
in sehr komlexen Konfigurationen mit vielen LPARs auf der
System z Site zum Engpass werden konnten, wurden auf
256 logische Kanäle erweitert. Damit dürften sich keine
Engpässe mehr bezüglich der Konfigurationen ergeben.
Die TS7700 ist ein Tape­Virtualisierungsprodukt für das
Mainframe­Umfeld, für das aufgrund seiner neuen Architektur
in den kommenden Jahren sowohl kontinuierliche Erweiterungen
als auch die Integration von völlig neuen Entwicklungen
vorgesehen sind.
Dynamic Link Load Balancing
Der im Frühjahr 2008 angekündigte Release 1.4a bietet
neben funktionaler Erweiterungen vor allem die Möglichkeit
des Dynamic Link Load Balancing, das in einem Spiegelgrid
dafür sorgt, das die zur Verfügung stehenden Kanalverbindungen
bezüglich der Workload so ausbalanciert,
dass eine ausgewogene Grid­Performance reflektiert wird.
Das betrifft im Wesentlichen die Laufzeitunterschiede im
Netzwerk aufgrund unterschiedlicher Längen der Grid­Verbindungen.
Um diese Unterschiede entsprechend auszugleichen,
wird alle 5 Minuten ein automatischer „Check“
durchgeführt, die aktuelle Auslastung bewertet und neue
Copy­Jobs entsprechend noch verfügbaren Leistungsresourcen
verteilt.
Dynamic Link Load Balancing für TS7700 Spiegel Grid Konfigurationen
TS7700 Library Manager Integration
Im Herbst 2008 kündigt IBM den TS7700 Release 1.5 an.
Einer der wesentlichen Bestandteile dieser R1.5 Erweiterung
besteht darin, dass die Funktionen des externen Library
Managers in die TS7700 selbst mit integriert wurde. Dieser
externe Library Manager war noch ein Überbleibsel der IBM
3494 Tape Libary und hat die Aufgabe, das Logical und
Physical Volume Inventory für den Host zu verwalten sowie
die zugehörige Advanced Functions zu managen. Dies war
notwendig, da die TS3500 Tape Library eine reine SCSI
Medium Changer Tape Library darstellt. Da die Library
Manager Plattform noch auf OS/2 basierte, kam eine Portierung
1:1 in die TS7700 nicht infrage. Die Entwickler konnten
sich allerdings eines anderen bereits existierenden IBM
Produkts bedienen: Für die Verwaltung des Physical Inventory
wurde der IBM eRMM mit in den TS7700 Microcode aufgenommen.
Durch diese Integration kann nun ein ganzes
zusätzliches Frame eingespart werden (3953F05) und eine
TS7740 Lösung besteht im einfachsten Falle aus nur noch 2
Frames (TS7740 und TS3500 L­Frame).
TS7720 – neues Modell
Diese Vereinfachung lässt dann auch erstmals das Erscheinen
eines Mainframe Virtual Tape Systems zu, welches rein
Disk­basierend ist; d. h., es gibt im Backend kein physikalisches
Tape bzw. keine Tape Library mehr. Dieses System
(die TS7720) hat den gleichen Aufbau und dieselben Kom­
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
125

126
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
ponenten wie eine TS7740 (selbst der Ucode ist der Gleiche)
mit Ausnahme des internen Plattenpuffers. Der Fibre­
Channel PlattenCache der TS7740 wird in der TS7720 mit
einem SATA­Plattensystem auf Basis der IBM DS4700 ausgestattet.
Verwendet werden 1­TB­SATA­Laufwerke, die in
der Maschine unter RAID6 betrieben werden. Es stehen
zwei Konfigurationen mit 40 TB oder 70 TB nativer Kapazität
zur Verfügung (nutzbarer Cache von 120 TB bzw. 210 TB
bei 1:3 Compression). Die TS7720 bietet 2/4 FICON­
Anschlüsse, bietet 256 virtuelle Laufwerke ab und verwaltet
bis zu 1 Million logische Volumes. Mit dem neuen Modell
TS7720 können wie mit der TS7740 Gridkonfigurationen aufgebaut
werden. Dabei erhöhen sich die Anzahl der virtuellen
Laufwerke und die Plattenpufferkapazitäten entsprechend.
In einer 3­seitigen Gridkonfiguartion stehen bis zu
630 TB Plattenpuffer und bis zu 768 virtuelle Laufwerke zur
Verfügung.
Weitere Funktionalität des R1.5 Releases waren der Support
von den TS1130 (Jaguar Generation 3) Bandlaufwerken an
der TS7740 sowie größere Ausbaustufen des internen
TS7740 Plattenpuffers auf bis zu 14 TB.
Neue Möglichkeiten mit TS7700 im Mainframe-Umfeld
Im Oktober 2009 kündigt IBM für die TS7700 Familie den
Release 1.6 an. Der neue Release beinhaltet viele Neuerungen,
die Grid­Computing von TS7700 Clustern und damit
verbundene neue Hochverfügbarkeitslösungen ermöglichen.
4 Cluster-Grid- und Hybrid-Grid-Konfigurationen
Durch den ein Jahr zuvor erschienen R1.5 sind entscheidende
Grundlagen gelegt worden, um mit dem Folgerelease
R1.6 die einmaligen Skalierungsmöglichkeiten einer
TS7700 Umgebung entfalten zu lassen. Dazu waren im
Wesentlichen noch zwei wichtige Erweiterungen notwendig:
Erhöhung der maximalen Anzahl von TS7700 Cluster in
einer Grid-Umgebung (von ehemals 3 auf 4)
Hybrider Support von TS7740 und TS7720 innerhalb eines
Grid-Verbundes
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
•
•
Dieser Release ist die Grundlage von Backup­ und Speicherarchitekturen,
die bislang nicht möglich waren. So können
jetzt 4­Standort­Konzepte realisiert werden oder z. B. ein
2­Standort­Konzept, bei dem nun jede Lokation mit 2 Systemen
auch im Fehlerfall hochverfügbar ausgestattet ist. Auch
ist eine sogenannte ‘Hub and Spoke’ Architektur möglich,
bei der 3 Systeme als I/O­Aufnahmesysteme dienen, die
dann ihren Inhalt gemeinsam zu einem TS7740 als Disaster
Recovery System spiegeln.

Very Large Cache
Intermediate Cache
Tape
Noch interessanter werden diese neuen Architekturansätze
durch das Mischen von TS7720 und TS7740 Systemen
(hybride Konfigurationen). Dadurch können z. B. Kosten eingespart
werden, weil ein TS7720 ohne Backend­Tape günstiger
in der Anschaffung ist. Der wichtigere Aspekt ist allerdings
die 2­dimensionale Skalierbarkeit, die es erlaubt, in
Richtung höhere I/O­Performance­Anforderung zu skalieren
oder die Anforderung an größere interne TS7700 Caches –
kostengünstig – zu befriedigen. So kann z. B. ein Kunde, der
bereits eine TS7740 2­Cluster­Grid­Lösung betreibt und
mehr Durchsatz im Front­End benötigt, den Grid einfach
durch das Hinzufügen von 2 x TS7720 erweitern (im Sinne
von intelligeten I/O­vNodes mit eigenem Cache). Die Daten
können dann mit den bekannten Methoden entweder auf die
andere TS7720 repliziert werden oder gleich über Kreuz auf
die entfernte TS7740. Somit lässt sich bei einer 2­Kopien­
Strategie der mögliche Durchsatz um ca. 75% steigern.
Ohne diese neuen Möglichkeiten müsste sonst ein komplett
neues, zweites TS7740­2­Cluster­Grid­System mit Backend
Tape angeschafft und administriert werden.
Die zweite Skalierungsmöglichkeit einer Hybrid­Lösung
besteht darin, dass der größere interne Plattenspeicher der
TS7720 als größerer, aber kostengünstigerer Cache (SATA)
des TS7700 Grid­Systems dienen kann.
Das hat seinen Charme! So können jetzt z. B. drei TS7720
mit einer TS7740 inklusive Tape­Anbindung zusammengeschaltet
werden. Damit hat die TS7740 einen riesengroßen
vorgeschalteten Plattenpuffer. Bei drei TS7720 wären das
bis zu 3 x 70 TB, also bis zu 210 TB native, komprimiert bis
zu 630 TB (3:1) an vorgeschalteter nutzbarer Plattenpufferkapazität.
Zur Optimierung der Verwaltung und Performace in Hybriden
und multiplen Cluster­Umgebungen wurden zwei wichtige
Funktionen in den R1.6 integriert.
Die ‘Cluster-Family-Funktion’ erlaubt es dem Betreiber,
den TS7700 Systemen mitzuteilen, in welchen geografischen
Positionen sie zueinander stehen. Damit können die
Replizierungswege optimiert werden. So wird z. B. in einer
4­Cluster­Grid­Umgebung in 2 Standorten zuerst eine Kopie
zwischen den Standorten gemacht und erst danach innerhalb
der Standorte eine Kopie zu dem jeweiligen System
innerhalb der Familie. Diese Vorgehensweise spart
Leitungskapazitäten der Replikations­Strecke zwischen
den Standorten.
Damit in einer hybriden TS7700 Umgebung die Plattenspeicher
der TS7720 Cluster nicht überlaufen, wurde die neue
Funktion ‘Automatic Volume Removal Policy’ eingeführt.
Sie sorgt automatisch dafür, dass das älteste logische
Volume einer TS7720 aus dem Cache entfernt wird (sofern
eine Kopie auf einem anderweitigen TS7740 System existiert)
und somit neuer Platz bei Bedarf freigegeben wird.
Dieses intelligente Management lässt die Plattenpuffer der
TS7720 in einer hybriden Grid­Umgebung als zusätzlichen
Cache erscheinen und optimal nutzen, um noch größere
Datenmengen in unmittelbarem Zugriff vorzuhalten, und entlastet
das Backend von Recalls vom Band.
Vorhandene 2­ oder 3­way­Grids sind mit Verfügbarkeit im
Dezember 2009 auf einen 4­way­Grid erweiterbar. Die
Zusammenführung von zwei 2­way­Grids zu einem 4­way­
Grid soll ab 2010 unterstützt werden.
TS7700 Logical WORM Support
In Bezug auf funktionale Erweiterungen wird mit Release
R1.6 der logische WORM Support bereitgestellt. Diese
Funktion erlaubt es, an den ensprechenden Anwendungen
auf dem Host die logischen Volumes als WORM Medien zu
verwalten. Dabei sieht der Host die TS7700 als logische
WORM ‘compliant’ Library. Host­Software­Erweiterungen
unterstützen das Management von logischen WORM
Volumes über die Data­Class­Konstrukte. Der Support ist
sowohl für TS7720 und TS7740 verfügbar. Bereits geschriebene
Volumes können allerdings nicht in logische WORM
Volumes umgewandelt werden!
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
127

128
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
Neue Server-basierende Tape-Virtualisierung für Open Systems
Bereits im Oktober 2005 stellte IBM mit der Virtualisierungslösung
TS7510 eine virtuelle Tape Library für den Open­
Systems­Bereich zur Verfügung, die sich allerdings von den
anderen virtuellen Tape Libraries auf dem Markt in der Funktionalität
nur wenig unterschied.
Im April 2007 kündigte die IBM die neue Virtuelle Tape
Library TS7520 (VTL) als Nachfolger der bisherigen
TS7510 an. Die TS7520 bietet neben höherer Kapazität und
Leistung einen ganz neuen Funktionsumfang, der speziell
für die Anforderungen im Open­Systems­Umfeld in die
Maschine integriert wurde. Bevor das neue Produkt TS7520
detailliert beschrieben wird, ist es wichtig, den Trend
bezüglich VTLs im Open-Systems­Umfeld näher zu
beleuchten.
Nachdem Festplatten in den letzten Jahren immer günstiger
wurden, besonders durch die Einführung von neuen Technologien
wie beispielsweise SATA, werden Disk­basierende
Backup­Lösungen immer mehr propagiert. Viele Marktbeobachter
und Kunden vergleichen oft Disk­Lösungen mit alten
Tape­Technologien und finden so Vorteile bei den Disk­
Lösungen wie schnelleres Backup und Restore oder auch
stabilerer und zuverlässigerer Betrieb als bei älteren Bandtechnologien.
Aber die Zuverlässigkeit mit reinen Disk­
Lösungen wollte sich doch nicht so einstellen, wie von
vielen gewünscht! Besonders beim Einsatz der günstigen
SATA­Laufwerke gibt es immer wieder Disk­Drive­Fehler bis
hin zum Datenverlust, auch unter RAID­Schutz.
Tape ist ein eigenständiges Medium und bietet die Vorteile
von sehr schnellem Lesen und Schreiben von großen Datenmengen,
lange Aufbewahrungssicherheit und braucht
außerdem keinen Strom (Tape ist ‘cool’). Daneben kann Tape
auch als auswechselbarer Datenträger eingesetzt werden.
Disk ist ebenso ein eigenständiges Medium und bietet den
Vorteil von schnellem direktem Zugriff mit kurzen Antwortzeiten
und der Möglichkeit der Parallelität. Optimale maßgeschneiderte
Lösungen bieten sich daher in der Kombination
von beiden Technologien.
Heutzutage werden Disk­Backup­Lösungen hauptsächlich
als Plattenpuffer für hochkapazitive und schnelle Tape Drives
eingesetzt. Dabei werden Sicherungsdaten kurzfristig (ein
bis mehrere Tage) auf diesen Disk­Systemen gespeichert
und zeitnah oder später auf Band migriert oder kopiert. Disk­
Backup­Systeme kommen auch zum Einsatz, um den Restore­Vorgang
zu optimieren, sinnvollerweise allerdings nur
dort, wo Platten Vorteile gegenüber Tape besitzen, also bei
kleinen Files und Filesystemen, aber nicht bei Datenbanken
oder Image­Backups.
Aufgrund der Klimaveränderung, der damit verbundenen
Diskussion um die Verringerung von CO2 (Green­IT) und der
steigenden Energiekosten sollten Disk­Backup­Systeme nur
noch mit Bedacht eingesetzt werden und nur dort, wo es
wirklich nötig ist bzw. Disk echte Vorteile gegenüber Tape
bietet. Dies gilt gerade für kleinere und mittelständische
Unternehmen. Disk­Backup­Systeme locken mit vermeintlich
günstigen Kosten, neigen aber dazu, dass die Strom­ und
Klimakosten über einen Zeitraum von sechs Jahren deutlich
höher sind als die Investitionskosten. Dazu kommen Kosten
für Datenmigration, die bedingt durch den kurzen Lebenszyklus
von Disk­Einheiten entstehen.
Neben der schon lang bestehenden Möglichkeit, den TSM
(Tivoli Storage Manager) so einzusetzen, dass ein LAN-
Backup auf einen Plattenpuffer läuft und später die Migration
auf Tape erfolgt, bietet die IBM nun auch eine neue VTL
(Virtual Tape Library) in Form des Produkts TS7520 an. Der
große Vorteil der TS7520 liegt vor allem im LAN­free­Bereich,
weil viele LAN­free­Clients direkt auf die TS7520 sichern
können, ohne dass viele physikalische Bandlaufwerke benötigt
werden (ein LAN­free­Client benötigt immer ein direktes
Bandlaufwerk, sei es nun physikalisch oder virtuell!). Dabei
stellt prinzipiell die TS7520 den Plattenpuffer und eine Emulationssoftware
zur Verfügung, die Bandlaufwerke emuliert.
Geschrieben wird aber direkt in den Plattenpuffer.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Die Migration vom TS7520 Plattenpuffer auf Band kann
durch die Backup­Software (z. B. TSM) erfolgen oder auch
direkt – allerdings mit entsprechenden Performance­Einschränkungen
– durch die TS7520 selbst.
Zunächst sind VTLs nichts anderes als Disk­Backup­
Lösungen. Allerdings stellen sich VTLs als Tape Libraries mit
Bandlaufwerken dar. Somit bieten VTLs Vorteile, wenn die
Backup­Applikation kein natives Disk­Backup unterstützt oder
die Lizenzkosten für ein solches Disk­Backup zu hoch sind.
VTLs können auch dort sinnvoll eingesetzt werden, wo viele
langsame LAN­free­Sicherungen vorhanden sind, denn hier
lassen sich sonst erforderliche Tape Drives einsparen. VTLs
sind aber meist auch integrierte Lösungen, die den Anwender
von jeglichen administrativen Tätigkeiten, die sonst bei
nativen Disk­Systemen notwendig wären, frei hält.
IBM Virtual Tape Library TS7520 für Open System-Umgebungen
Ein großer Vorteil von VTL­Systemen ist die Möglichkeit, die
Daten zu komprimieren und somit die Disk­Kapazität besser
auszunützen. Allerdings sinkt in den meisten Fällen die Performance
der Systeme bei Einsatz von Kompression. Ein
weiterer Vorteil ist, dass die Daten direkt von der VTL auf
Tape migriert oder kopiert werden können und dies transparent
für den Backup­Server passiert.
Die IBM Tape Virtualization Engine TS7520 stellt eine inte-
grierte Lösung aus Hardware und Software dar, die Band­
virtualisierung für Open­Systems­Server über physische
FibreChannel­ (FC) und iSCSI­Verbindungen bereitstellt.
Durch System x-basierende Server (1-4) werden Bandlaufwerke
emuliert. Die Emulation der TS7520 unterstützt die
Laufwerksformate LTO2, LTO3 und LTO4 sowie die ‘High
End’­Technologien 3592 und TS1120. Der Plattenpuffer
wird durch 500­GB­ und/oder 750­GB­SATA­Platten reflektiert.
Dabei sind die Platten in einem Einschub als RAID5-Array
abgebildet. Die 16 Platten im Einschub reflektieren dabei ein
6+P und ein 7+P RAID5­Array (P= Parity Platte) sowie eine
Hot­Spare­Platte, die für beide Arrays im Fehlerfall als
Rebuild­Platte einspringt. Die Kapazitäten können mit
500-GB-Platten auf bis zu 884 TB und mit 750-GB-Platten
auf bis zu 1,3 PB (native Kapazitäten) ausgebaut werden.
Die kleinste kapazitive Einstiegsgröße beginnt bei 6,5 TB.
Erweiterungen können – je nach Plattenart – in 6,5­TB­
Schritten oder 9,75­TB­Schritten erfolgen.
Die TS7520 bietet eine einmalige Leistungsfähigkeit,
indem bis zu 4. 800 MB/s Durchsatzmenge ermöglicht wer­
den (4 .800 MB/s beim Lesen vom Plattenpuffer und bis zu
4 .500 MB/s beim Schreiben in den Plattenpuffer). Sowohl
von der Leistungsfähigkeit als auch von den kapazitiven
Möglichkeiten gibt es derzeit kein anderes VTL­System auf
dem Markt, das diese Möglichkeiten bietet.
Die TS7520 lässt sich so konfigurieren, dass bis zu vier
Server ‘geclustert’ werden können. Dabei werden bis zu 512
virtuelle Libraries, bis zu 4 .096 virtuelle Bandlaufwerke und
bis zu 256 .000 virtuelle Kassetten emuliert. Zu den Hosts
können bis zu 32 FC­Anschlüsse auf Basis von 4­Gbit­Fibre­
Channel konfiguriert werden. Für die Tape­Anbindung stehen
bis zu 16 FC­Anschlüsse, auch auf Basis von 4­Gbit­Fibre,
zur Verfügung.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
129

130
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
Neben der hohen Flexibilität, Leistungsfähigkeit und Kapazität
bietet die TS7520 einen Funktionsumfang, die derzeit
keine andere VTL auf dem Markt übertrifft. Auf diese Funktionalität
wird später noch ausführlich eingegangen.
Bei einer maximalen Konfiguration der TS7520 werden bis
zu 12 Gehäuseeinheiten benötigt. Wichtig dabei ist die Tatsache,
dass selbst bei kleinen Konfigurationen wegen
Sicherheits­ und Leistungsanforderungen immer mit zwei
Platten­Controllern (SV6) gearbeitet wird (Enterprise Edition).
Sowohl die Platten­Controller als auch die Virtualization
Engines (CV6) sind über ein integriertes SAN auf Basis von
4­Gbit­FibreChannel miteinander verbunden. Dieser hochredundante
Aufbau zeigt sich auch in der Stromzufuhr. Jede
Gehäuseeinheit ist mit zwei Stromversorgungen ausgestattet.
Aufbau einer TS7520 in einer Konfiguration mit drei Gehäuseeinheiten
Als Einstiegsversion steht die TS7520 Limited Edition zur
Verfügung. Diese günstige Einstiegsoption steht für Einstiegskonfigurationen
mit einer Virtualization Engine (CV6)
und nur einem Platten­Controller (SV6) zur Verfügung und
unterstützt Plattenkapazitäten bis zu 29,25 TB (maximal).
Die Limited Edition enthält standardmäßig nicht den ganzen
Funktionsumfang. Tape Caching ist z. B. ein kostenpflichtiges
Feature.
Die Enterprise Edition unterstützt jede Art von TS7520
Konfiguration bis zum Maximalausbau und bietet Tape
Caching standardmäßig an.
Die IBM TS7520 wurde als komplette Appliance entwickelt
und alle Einzel­Komponenten aufeinander abgestimmt. Das
komplette System wurde mit allen Funktionen getestet und
ausführlichen Performance­Messungen unterworfen.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Für IT­Betreiber stellt sich die IBM TS7520 als eine oder
mehrere ‘virtuelle’ Tape Libraries dar und man muss sich
nicht um die Anbindung sowie die Konfiguration des Disk­
Storage­Systems kümmern. Die IBM TS7520 VTL ist als eine
Einheit zu betrachten und auch der Support wird dementsprechend
durchgeführt, d. h., es werden keine Einzelkomponenten,
sondern immer die gesamte Appliance betrachtet
und gewartet (z. B. für Firmeware­Updates). Somit kümmert
sich auch nur ein Supportteam um die IBM TS7520. Eine
zentrale Stelle nimmt die Kundenanfragen entgegen. Eine
Voranalyse des Problems durch den Kunden, wie es bei
Implementierungen, die aus Einzelkomponenten zusammengestellt
wurden, der Fall ist, entfällt.
Mit bis zu 48 x 4-Gbit-FC-Anschlüssen bietet die IBM
TS7520 die höchste Anzahl von ‘Connectivity’­Möglichkeiten.
End­to­End­4­Gbit­Support bedeutet, dass die Maschine in
ihrer gesamten Anbindung zu den Hosts wie auch zum Disk
und Tape Backend eine ausbalancierte Leistung für Front End,
Disk Cache und Tape Backend realisiert. Dabei werden bis
zu 256 physische Backend Tape­Laufwerke (IBM TS1120
J1A/E05 Drives und/oder LTO2, LTO3 und LTO4 Drives)
sowie bis zu 32 physische Backend Tape Libraries (IBM
TS3500 Library, IBM TS3310 Library, IBM TS3200 Library,
IBM 3582 Library, IBM 3583 Library und IBM 3494 Library)
unterstützt.
Während manche andere VTL­Anbieter für die Anzahl an
emulierten Libraries, Drives und Volumes extra Lizenzkosten
berechnen, ist bei der TS7520 immer alles inklusive.
Die IBM TS7520 bietet eine selbstständige Call­Home­Funktionalität
zum IBM Service­Team. Vergleichbare VTLs bieten
nur eine ‘E­Mail’­Call­Home­Funktionalität an, sodass nur
intern, ohne Benachrichtigung des Herstellers, über Fehler
informiert wird.
Als großes Alleinstellungsmerkmal bietet die IBM TS7520 als
einziges VTL­System auf dem Markt einen Multipath Device
Driver für FC Failover und Load balancing. Die Maschine
kann problemlos in ein Dual­Fabric integriert werden. Einen
Dual­Fabric­Support bieten alle auf dem Markt verfügbaren
VTLs an, doch nur die IBM TS7520 bietet zusätzlich Failover
und Load balancing. Dies wird durch den Multipfadtreiber
gewährleistet.
Ohne einen Multipath Device Driver können die einzelnen
virtuellen Tape Drives zwar mühsam und manuell über die
Frontend FC­Ports der VTL verteilt werden, doch ein Load
balancing kann dadurch nicht erreicht werden, weil die
Backup­Applikation, wie z. B. TSM, von der Verteilung der
virtuellen Tape Drives über mehrere FC­Ports keine Informationen
bekommt. Alle Backup­Applikationen verteilen die
Workload auf die verfügbaren Tape Drives nach ‘Round­
Robin’­ und/oder ‘last recently used’­Algorithmen. Dadurch
kommt es aber in Verbindung mit VTLs vor, dass einzelne
FC­Links overloaded sind und gleichzeitig manche Links
ohne Last sind.
Besonders das Load balancing ist für eine ausgewogene
und hohe Performance bei VTLs enorm wichtig. Bei Disk­
Systemen ist ein Load balancing schon seit langem eine
Standardfunktion. Bei VTLs, die eigentlich ein Disk­System
sind bzw. Disk­Backup anbieten, ist dies nicht der Fall,
obwohl die meisten VTLs mehrere FC­Ports im Frontend
anbieten. Der IBM Multipath Device Driver für Tapes verteilt
die Workload auf die verfügbaren FC­Links, so dass die
einzelnen Links eine ausgewogene Workload-Verteilung
haben. Zusätzlich ermöglicht der IBM Multipath Device Driver
ein automatisches Failover, falls ein Link oder eine Fabric
ausfällt oder auch nur für Wartungsarbeiten offline ist.
Spezielle Disk Caching Algorithmen beschleunigen den
Recall von Tape, wenn das logische Volume sich nicht mehr
im Plattenpuffer befindet. Werden VTLs eingesetzt, schreibt
die Backup­Software die einzelnen Files in einen Plattenpuffer.
Im Falle einer Migration von Platte auf Band wird
das logische Volume in einer 1:1­Kopie auf eine Kassette
gespeichert. Im Falle eines Restores einer einzelnen File,
die sich nicht mehr im Plattenpuffer befindet, müssen viele
VTLs das komplette logische Volume in den Plattenpuffer
zurückladen, um von dort den Host­Request zu bedienen.
Das kann je nach emulierter Kassette (man bedenke: eine
LTO4­Kassette fasst 800 GB Kapazität) sehr lange dauern,
oft bis zu zwei Stunden und länger! Der Caching-Algorithmus
der TS7520 arbeitet in solchen Fällen wesentlich intelligenter!
Anstatt des Zurückladens des gesamten logischen
Volumes in den Plattenpuffer wird die zu ‘restorende’ File
direkt von Tape ausgelesen (ohne Zurückladen) und dem
Host zur Verfügung gestellt. Das spart wertvolle Zeit bei
Restore­Aktivitäten.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
131

132
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
Es besteht die Möglichkeit, mehrere TS7520 VTLs über IP-
Verbindungen asynchron zu spiegeln. Dabei wird nach dem
‘demount’ einer Kassette, zu einem bestimmten Zeitpunkt
oder intervallmäßig, eine Kopie des logischen Volumes über
IP zu einer anderen TS7520 übertragen. Bevor auf erzeugte
kopierte Volumes zugegriffen werden kann, müssen diese
Volumes durch einen administrativen Eingriff freigegeben
werden, damit aktiv mit ihnen gearbeitet werden kann.
IP Replication kann nicht gleichzeitig mit Tape Caching
durchgeführt werden.
TS7530 – neues Modell
Im Mai 2008 kündigt IBM die leistungsstärkere IBM Tape
Virtualization Engine TS7530 an, die vom Funktionsumfang
der TS7520 entspricht, allerdings neben höherer Leistung
auch die Möglichkeit von RAID6 und den Einsatz von
1­TB­SATA­Platten bietet und eine Ausbaustufe von bis zu
1,7 PB (Petabyte) erlaubt. Die kleinste kapazitive Einstiegsgröße
beginnt bei 6,5 TB. Erweiterungen können – je nach
Plattenart – in 6,5­TB­Schritten, in 9,75­TB­Schritten und in
13­TB­Schritten erfolgen.
Die TS7520 und TS7530 unterstützen die Encryption-Mög-
lichkeiten für Backend Tape Drives (TS1120 oder LTO4).
Bei dieser HW­Encryption, die in diese Laufwerke integriert
ist, sind keine Leistungsbeeinträchtigungen zu erwarten. Für
Tape­Laufwerke, die nicht mit Verschlüsselungstechnik
arbeiten, bietet die TS7520 die Möglichkeit, die Daten auch
über Software­Encryption­Methoden zu verschlüsseln, bevor
sie auf das physikalische Tape geschrieben werden.
Die TS7520 ermöglicht neben FC­Anbindungen auch iSCSI­
Anbindungen, wenn Kunden iSCSI im Einsatz haben oder
haben wollen.
Über die Funktionalität des Hosted Backups besteht die
Möglichkeit, die Backup­Software auch direkt auf der TS7520
zu installieren. Dies ist allerdings nur zu empfehlen, wenn
keine allzu großen Leistungsanforderungen an den Backup­
Server gestellt werden.
Im Juli 2009 zieht IBM alle Modelle der TS7500 Familie von
Marketing zurück. Einer der Hauptgründe dürfte die fehlende
Möglichkeit der Daten­De­Duplizierung sein. Durch die Aquisition
der Firma Diligent im April 2008 und die schnelle
Umsetzung dieser Technologie in der IBM Hardware setzt
IBM auf die ProtecTIER VTL, die ein einzigartiges Daten­De­
Duplizierungsverfahren bietet und dadurch wesentlich weniger
physischen Plattenplatz benötigt, um diesselbe Kapazität
abzubilden (siehe unter IBM ProtecTIER VTL mit Hyperfactor).
Data De-Duplication
Das Thema De­Duplication wurde im Jahr 2007 zu einem oft
diskutierten Thema. De­Duplication ist nichts Neues. Es handelt
sich um einen mathematischen Algorithmus, der Bit­
Block­Vergleiche durchführt. Das einzige Ziel ist die Vermeidung
von Duplikaten. Dabei gibt es die unterschiedlichsten
Ansätze und Verfahrensmöglichkeiten. Man kann solche
Verfahren im Betriebssystem etablieren. Ein Beispiel dafür
ist das z/OS mit der Funktion Hyper PAV. Auch über Software­Tools
sind solche Verfahren möglich, wie z. B. Analyse­
Tools, ILM, TPC oder Common Store oder über Vergleichsalgorithmen
in SW und HW. Heutige De­Duplication­Verfahren
werden vor allem beim Backup auf Virtuelle Tape Libraries
(VTLs) eingesetzt, weil die meisten Duplikate beim Backup
und bei der Archivierung erzeugt werden.
Das erste professionelle De­Duplication­Verfahren führte
IBM bereits im Jahr 2006 für das Produkt IBM Common
Store ein. Common Store führt diese Vergleiche bei der
E­Mail­Archivierung auf Mail­Basis und/oder Attachment­
Basis durch und stellt sicher, dass eine E­Mail und/oder ein
Attachment nur einmal archiviert wird. De­Duplication ist ein
Feature von Common Store und ist nur in Verbindung mit dem
IBM Content Manager als Backend Repository verfügbar.
Der De­Duplication­Ansatz findet vor allem Freunde bei Vir-
tuellen Tape Libraries (VTLs). Der mathematische
Vergleichs algorithmus läuft dabei auf der VTL mit und führt
Bit­Block­Vergleiche durch. Die Einsparungen an Plattenplatz
können dabei durchaus den Faktor 10 – 20 erreichen.
Es sind verschiedene Ansätze verfügbar: über Software,
über Microcode mit Hardware oder eine Kombination von
Software und Hardware. Man unterscheidet grundsätzlich
zwei Verfahren. Beim Inline-Verfahren werden die Vergleiche
durchgeführt, bevor der Bit­Block auf Platte abgespeichert
wird. Hier ergibt sich das Problem der Skalierbarkeit und
Leistung. Werden zu viele TB mit De­Duplication bearbeitet,
gehen die VTLs sehr schnell in der Leistungsfähigkeit
zurück, weil der Rechner nur noch den De­Dup­Algorithmus
durchführt. Die Empfehlung der Anbieter ist allgemein, nicht
mehr als 15 – 20 TB mit De­Dup zu bearbeiten. Das andere
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Um De-Duplication besser zu verstehen, sehen wir uns folgendes einfaches
Beispiel an:
Unsere abzuspeichernde File ist das hier abgebildete Häuschen (1). Es wird
in seine Bauteile zerlegt (2). Es besteht aus roten Würfeln, grünen Zylindern
und blauen Dächlein. De-Duplication speichert jetzt jedes Bauteil nur einmal
ab. Den drei Bausteinen wird noch eine Aufbauanleitung beigefügt, wie das
Haus wieder aufzubauen ist und wie viele Bausteine dafür von jedem Element
benötigt werden (3).
Verfahren ist das Post-Processing-Verfahren, wobei der
Algorithmus nachgelagert stattfindet. Man schreibt die Blöcke
zuerst ohne De­Dup auf Platte und führt die Vergleiche
anschließend durch. Dafür wird dann aber zusätzlicher
Speicherplatz benötigt.
De­Duplication­Verfahren werden heute von den Firmen
IBM (Diligent), EMC 2 (Data Domain), Quantum, FalconStor,
Sepaton und Network Appliance angeboten. Auch für die
IBM Nseries steht De­Duplication in Form der Funktion A­SIS
(Advanced Single Instance Storage) zur Verfügung.
Die IBM beschäftigt sich schon seit einigen Jahren mit dem
Thema Daten­De­Duplizierung. Bereits im Januar 2004
wurde im IBM Labor Almaden in Kalifornien das Projekt ‘Bit
Block Mathematics’ ins Leben gerufen. Die Gruppe bestand
aus Microcode­Spezialisten und Mathematikern. Ziel war es,
Unsere zweite abzuspeichernde File ist in Form einer Lokomotive (1)
dargestellt:
Hier finden wir dieselben Bauteile, die bei der ersten File enthalten waren:
der rote Würfel, der grüne Zylinder und das blaue Dächlein. Ein weiteres
zusätzliches Element kommt hinzu, das gelbe Rad. Allen vier Bauteilen wird
wieder eine Aufbauanleitung beigefügt (2). Da der rote Würfel, der grüne
Zylinder und das blaue Dächlein bereits abgespeichert sind, müssen wir nur
noch das gelbe Rad und die Aufbauanleitung abspeichern (3). Für beide
Files, das ‘Haus’ und die ‘Lokomotive’, wurden nur vier Bauelemente und
zwei Aufbauanleitungen abgespeichert. Das Kritische an diesem Verfahren
ist: Wenn eine Aufbauanleitung verloren geht, gibt es keine Möglichkeit der
Rekonstruktion!
einen leistungsfähigen und hochskalierbaren Algorithmus zu
entwickeln, der sowohl in Hardware­ als auch in Software­
Lösungen integrierbar ist. Im Herbst 2008 wird ein De­Duplication­Verfahren
als Post­Processing­Verfahren in die
Backup­Software TSM (Tivoli Storage Manager) integriert
und steht mit dem TSM Release 6.1 zur Verfügung.
Im April 2008 aquiriert IBM die israelische Firma Diligent,
um mit der DILIGENT­Technologie namens ProtecTIER die
Herausforderungen Datenwachstum und den Wunsch nach
längerer plattenbasierter Datenvorhaltung innerhalb der
Datensicherung zu adressieren. ProtecTIER ist eine für den
Enterprise­Markt prämierte und seit fünf Jahren bewährte
Softwarelösung, die die Technologien Virtuelle Tape Library
(VTL) und Daten­De­Duplizierung (DDD) vereint. Die DDD­
Engine innerhalb der ProtecTIER­VTL­Lösung heißt Hyperfactor.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
133

134
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
IBM Daten-De-Duplizierung mit ProtecTIER und Hyperfactor
Nach der Übernahme von Diligent etabliert IBM einen Produktplan,
um die ProtecTIER­VTL­Lösung mit Hyperfactor in
geeignete IBM Hardware­Produkte umzusetzen. Bereits im
August 2008 erfolgt die erste Ankündigung der Gateway­
Lösungen, also xSeries­basierende Server, die Plattensystemen,
die als Backup­Repository dienen, vorgeschaltet werden
und mit dem ProtecTIER und Hyperfactor­Algorithmus
arbeiten. Im Februar 2009 kündigt IBM die entsprechenden
Lösungen als Appliances an und im Juli 2009 erfogt die
Ankündigung der direkten Replikationsmöglichkeit der Gateways.
HyperFactor als Data De­Duplizierung ist ein mathematischer
Algorithmus, der auf variable Bit­Block­Vergleiche
schon gespeicherte Blöcke herausfiltert, sodass sie nicht
doppelt abgespeichert werden. Hyperfactor vermeidet also
die Abspeicherung von Duplikaten. Die Einsparung ist dabei
direkt vom erzielten De­Duplizierungsfaktor abhängig, der
bis zu Faktor 25 gehen kann. Vor allem bei Backup­Verfahren,
die viele Full Backups beinhalten und eine relativ lange
Retention­Periode haben, werden die höchsten De­Duplizierungsfaktoren
erreicht. Bei TSM sind die Faktoren wesentlich
kleiner, weil TSM schon auf ‘incremental’ Basis arbeitet und
nur die entstandenen Änderungen im Backup wegschreibt.
Speicherung auf dem ProtecTIER Repository
ProtecTIER Gateway TS7650G
Nachdem das ProtecTier Gateway zwischen den Servern
und den Disksystemen, auf die der Backup gemacht werden
soll, installiert ist, werden die Hyperfactor­Algorithmen
dazu verwendet, redundante Daten herauszufiltern. Dazu ist
ein Index notwendig, über den festgestellt werden kann,
welche Datenblöcke bereits im Repository, d.h. auf den
Disksystemen abgespeichert sind. Der Algorithmus analysiert
den ankommenden Datenstrom und stellt über den
Index Ähnlichkeiten fest (agnostisches Verfahren). Werden
keine Ähnlichkeiten gefunden, wird der entsprechende
Block direkt im Repository gespeichert. Bei Ähnlichkeiten
werden die entsprechenden Blöcke vom Repository eingelesen
und mit den neuen Daten verglichen. Dabei werden die
identischen Daten herausgefiltert und nur die verbleibende
Differenz wird im Repository neu abgespeichert. Über diese
Methode ist eine 100%ige Datenintegrität gewährleistet. Der
Index hat eine feste Größe von 4 GB und wird permanent im
Hauptspeicher des Gateways (xSeries) gehalten.
Das Verhältnis der gespeicherten Daten zum Index (Ratio of
Repository to Index) spiegelt die Effizienz des Index wider.
Die Zahl von 250.000:1 beim Hyperfactor­Verfahren sagt
aus, dass ProtecTier mit einem festen Memory Index von 4
GB das 250.000fache, d.h. 1 PetaByte an Daten verwalten
Metadata
Metadata
Metadata
Metadata
Metadata
Metadata
User Data User Data
User Data
User Data User Data
User Data
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

kann. Dabei ist der De­Duplizierungsfaktor noch nicht
berücksichtigt. Wäre der erzielte Faktor bei 25, könnten 25
PetaByte an Daten verwaltet werden. Dies ist der große
Vorteil dieser Lösung, weil die verwalteten Kapazitäten ohne
Leistungsverlust in diese hohe Dimension skaliert werden
können (im Vergleich: Hash­basierende Verfahren erzielen in
der Regel nur ein Ratio von etwa 400:1. Das bedeutet, dass
die Anforderung an die Hauptspeichergröße im Rechner
wesentlich höher ist und ab einer bestimmten Datenmenge
der Index nicht mehr komplett im Hauptspeicher gehalten
werden kann. Dann kommt es sofort zum Performance­Einbruch!
Die ProtecTier­Lösung ist daher deutlich besser für
sehr hohe Kapazitäten bei hoher Leistungsfähigkeit im Vergleich
zu Hash­basierenden Verfahren geeignet und bildet
eine echte ‘Enterprise’­Lösung ab).
Das ProtecTier Repository beinhaltet sowohl die Backup­
Daten als auch die dazugehörigen Meta­Daten. Die Meta­
Daten beinhalten 2 Kopien des Hyperfactor Index, alle virtuellen
Volume Files, die Konfigurationsdaten der virtuellen
Libraries und Storage Management Daten (Pointer­Tabellen,
Referenz Counter etc.).
Dabei werden die Datenblöcke selbst im Repository RAID5
basierend abgespeichert, während die Meta­Daten aus
Sicherheitsgründen RAID10 basierend, also doppelt, abgespeichert
werden.
Das Repository kann auf einem einzigen RAID­Array gehalten
werden oder über viele RAID­Arrays verteilt werden.
LUNs, die für das ProtecTier Repository benutzt werden,
dürfen nicht von einer Array­Gruppe kommen, die von anderen
Applikationen benutzt werden. Es wird empfohlen, dass
für das Repository eine LUN so angelegt wird, dass sie die
gesamte RAID­Gruppe umfasst.
IBM Hyperfactor kann bis zu einer Datenreduzierung 25:1
führen und skaliert bis auf 1 PB native Plattenkapazität. Bei
einem erreichten De­Duplication­Faktor 25:1 können bei
einer nativen 1­PB­Plattenkapazität 25 PB an Daten verwaltet
werden. Das Gateway ist als Single Note Gateway oder in
einer Clusterkonfiguration mit zwei Nodes verfügbar.
Die Leistung liegt bei einer Clusterkonfiguration bei bis zu
1.000 MB/s, ist aber direkt abhängig von der dahinterliegenden
Platteninfrastruktur und Plattenart (FC­Platten
oder SATA­, FATA­Platten).
Die hohe Leistungsfähigkeit von Hyperfactor kommt von der
Tatsache, dass der Algorithmus auf dynamischer Blockbasis
arbeitet und identifizierte kleine Blöcke, die kleiner als 8 KB
sind, nicht betrachtet werden und sofort als ‘neu’ im Repository
gespeichert werden. Würde man diese kleinen Blöcke
wie die großen Blöcke behandeln, wäre eine Skalierbarkeit
in diese hohe Leistungsklasse nicht möglich.
Als Band­Laufwerksemulation verwendet ProtecTier virtuelle
LTO­Laufwerke (LTO­3). Neben LTO ist auch die Emulation
von DLT (DLT7000) möglich. Unterstützt sind bis zu 256 virtuelle
Laufwerke per Node und 512 Laufwerke per Cluster.
In einer Clusterkonfiguration können bis zu 16 virtuelle
Libraries abgebildet und bis zu 500.000 virtuelle Kassetten
emuliert werden.
Das Hyperfactor­De­Duplication­Verfahren stellt derzeit auf
dem Markt als einziges Verfahren eine 100%ige Dateninte-
grität sicher. Im Backend, also hinter dem Gateway, sind alle
aktuellen IBM Plattensysteme unterstützt. Auch IBM Nicht­
Systeme von HDS, EMC und HP können betrieben werden.
ProtecTIER neue Prozessoren für das TS7650G Gateway
Im 1. Quartal 2009 führt IBM neue Prozessoren für die
TS7650G Gateways ein. Zum Einsatz kommt der x3850 M2
MT7233 Prozessor. Hierbei handelt es sich um einen 4 x 6
Core Prozessor mit 2,6 GHz und 32 GB RAM mit zwei integrierten
RAID1­betriebenen 146 GB SAS Disk­Laufwerken, 2
Emulex Dual Port FC Adapter für die Hostanbindung und
zwei Qlogic Dual Port FC HBAs für die Anbindung des
Backend­Platten­Repositories. Für die Replizierung stehen
Dual Port Gigabit Ethernet Adapter zur Verfügung. Der neue
Prozessor steigert die Gateway­Leistungsfähigkeit um ca.
30%. Dies wird durch den 4 x 6 Core Prozessor möglich,
der jetzt gleichzeitig 24 Datenströme mit De­Duplizierung
bearbeiten kann.
TS7650G Disk Backend als Repository
Im Backend des TS7650G Gateways werden die IBM Plattensysteme
DS3400, die DS4000­ und DS5000­Modelle, die
DS8000, XIV Storage, SVC und Nseries unterstützt. Ebenso
können die Nicht­IBM­Plattensysteme HDS AMS1000, EMC
CX und HP EVA betrieben werden.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
135

136
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
ProtecTIER Replikation
Für die Gateway­Lösung besteht seit September 2009 (Verfügbarkeit)
die Möglichkeit der IP­basierten Replikation.
Damit können virtuelle Bänder in eine andere Lokation direkt
kopiert werden, um auf diese Weise die Notwendigkeit von
physikalischen Bandtransporten zu vermeiden. Da bei der
Replikation nur die geänderten Blöcke übertragen werden,
hält sich die benötigte Bandbreite der IP­Verbindungen in
Grenzen. Die Anforderung für eine dritte, ‘sichere’ Kopie
besteht bei vielen IT­Umgebungen schon lange, doch bisher
konnte dies technisch nicht umgesetzt werden, weil entsprechende
Leitungskapazitäten nicht vorhanden oder nicht
bezahlbar waren. Jetzt steht dem nichts mehr im Wege und
solche Konzepte können ohne die Notwendigkeit riesiger
Übertragungsbandbreiten realisiert werden.
Pro Node stehen zwei Ethernet­IP­Ports zur Verfügung.
Ältere Systeme können durch eine zweite Ethernet­Karte
nachgerüstet werden. Das Besondere dieser Replikationsfunktion
ist der automatische Failover und Failback. Fällt die
primäre Seite aus, kann die Disaster/Recovery­Seite per
Knopfdruck zur ‘Primary’ gemacht werden und der Betrieb
läuft weiter. Steht die primäre Seite dann wieder zur Verfügung,
wird ein Failback durchgeführt und die Daten werden
zur primären Seite zurückrepliziert.
Die Replikation kann Policy­basierend betrieben werden.
Dabei kann die Replikation ständig und sofort durchgeführt
werden (Immediate Mode). Man kann die Replikation aber
auch in einem geplanten Zeitfenster durchführen (Replication
Window). Die Policies können sowohl einzelne Kassetten
als auch einen Pool von vielen Kassetten administrieren.
Dabei gibt es zwei Betriebs­Modi: Der Visibility­Control­
Modus importiert bzw. exportiert die Kassetten, die über die
Backup­Applikation gesteuert werden (Check­Out). Kassetten,
die exportiert werden, werden in die Target­VTL repliziert.
Beim Basic­DR­Modus (Disaster Recovery) läuft die
Replikation ständig und transparent zur Backup­Applikation
mit und die Kassetten stehen sowohl auf der primären Seite
als auch auf der Remote­Seite zur Verfügung.
Multipathing und Control Path Failover
Das TS7650G Gateway und die TS7650 Appliances bieten
zusammen mit der TS7500 Familie derzeit als einzige VTL­
Systeme auf dem Markt einen Multipfad­Device­Treiber für
FC Failover und Load Balancing an. Damit lassen sich die
VTL­Lösungen redundant in SAN Fabric­Infrastrukturen
betreiben. Fallen Adapter, Pfade oder ganze SAN­Switche
aus, läuft der Betrieb unterbrechungsfrei weiter, weil die
‘Commands’ für die virtuelle Library und Laufwerke automatisch
über die verbleibenden Adapter, Pfade und SAN­Switche
übertragen werden können (Control Path Failover und
Data Path Failover).
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Zusätzlich bietet der Data Path Failover ein Load Balancing
auf den redundanten Pfaden vom Server zu den virtuellen
Laufwerken an. Dadurch wird eine gleichmäßige Auslastung
der physikalischen FibreChannel­Links und den FC­Ports
ermöglicht.
ProtecTIER TS7650 Appliances
Neben der Gateway­Lösung stehen auch Appliance­
Lösungen im Sinne von ‘all­in­one’ zur Verfügung.
Mit den Appliances adressiert IBM vor allem Mittelstands­
kunden, die jetzt auch die Möglichkeit haben, eine Enter­
prise­Lösung für De­Dup­VTLs kostengünstig zu etablieren.
IBM hat den Hyperfactor­De­Duplizierungsalgorithmus nach
allen Regeln der Kunst darauf überprüft, ob tatsächlich eine
100%ige Datenintegrität gewährleitet ist. Dafür wurden auch
Fremdfirmen und ‘Hacker’ beauftragt. Es konnten keine
Schwachstellen aufgedeckt werden. Es ist deshalb davon
auszugehen, dass IBM Daten­De­Duplizierung über die Zeit
auf das ganze IBM Speicherportfolio und alle Betriebssystemplattformen
adaptieren wird. ProtecTier ist für die Mainframe­Umgebung
(System z) bereits in 2010 vorgesehen.
TS1130 Bandlaufwerk der ‘Enterprise’-Klasse
IBM TS1130 Bandlaufwerk der ‘Enterprise’-Klasse –
der Durchbruch in der Tape-Technologie
Im Juli 2008 kündigt IBM mit Verfügbarkeit September 2008
das neue Bandlaufwerk TS1130 an und leitet damit eine
neue Technologiebasis für die Tape­Weiterentwicklung ein!
Das technologische Highlight des TS1130 Laufwerks spiegelt
sich in den neuen Schreib­/Leseelementen wider. Erstmalig
wird in einer Tape­Laufwerkstechnologie neben den
induktiven Schreibköpfen als Lesekopf ein GMR-Lesekopf
(Giant Magneto Resistance) eingesetzt. GMR war im Jahr
2007 in aller Munde, als für die Entdeckung des GMR­
Effekts Peter Grünberg und Albert Fert mit dem Nobelpreis
für Physik ausgezeichnet wurden. Ohne diese Entdeckung
wären die hohen Kapazitäten bei Festplatten nicht möglich
geworden. Die Umsetzung dieses Effekts in ein Produkt
wurde durch den IBM Forscher Stuart Parkin ermöglicht, der
dazu noch sieben Jahre benötigte und Ende 1997 den
ersten GMR­Lesekopf in ein Plattenlaufwerk integrierte. Nun
hält diese Technologie auch Einzug im Tape­Bereich!
GMR­Leseköpfe sind in der Lage, kleinste Streufelder von
Bits auszulesen und das in einer Geschwindigkeit, wie es
mit keiner anderen Technologie möglich ist. Dem GMR­Kopf
ist es zu verdanken, dass jetzt in der TS1130 die ‘High
Speed Search’-Geschwindigkeit von bisher 10 m/s (bei
TS1120) auf sagenhafte 12,4 m/s gesteigert werden konnte,
also von 36 km/h auf 45 km/h. Beim High Speed Search
werden die Tape Marks auf dem Band beim Vorspulen ausgelesen
und das geht jetzt mit dem GMR­Kopf wesentlich
schneller, sodass damit die Zugriffsgeschwindigkeit auf eine
auszulesende File beträchtlich gesteigert wird.
Neben den Highlights, die schon die Vorgängertechnologie
TS1120 integriert hatte, sind viele zusätzliche Einrichtungen
verbessert worden, um eine noch höhrere Verfügbarkeit und
Zuverlässigkeit zu gewährleisten.
Die Vorgänger­Laufwerke TS1120 sind zudem auf die neuen
TS1130 Laufwerke hochrüstbar, was jeden TS1120 Nutzer
freuen wird. Die Medien, also die Kassetten, bleiben dieselben,
d. h. kein Medienwechsel.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
137

138
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
3592 Kassetten Bandlänge Kassetten-Type Gen. 1 3592 Gen. 2 TS1120 Gen. 3 TS1130
JJ 200 m Read Write 60 GB 100 GB 128 GB
JA 609 m Read Write 300 GB 500 GB 640 GB
JB 825 m Read Write 700 GB 1.000 GB
JR 200 m WORM 60 GB 100 GB 128 GB
JW 609 m WORM 300 GB 500 GB 640 GB
JX 825 m WORM 700 GB 1.000 GB
IBM 3592 Bandkassettenformate
Das TS1130 Laufwerk arbeitet mit der zur Zeit höchsten
Datenrate (160 MB/s native) und benötigt für die Sicherung
von komprimierten Daten (2,3:1) mit bis zu 1.296 GB nur
eine Stunde. Die maximale Kapazität pro Kassette beträgt
1 Terabyte (JB­ und JX­Kassetten). Dabei werden 1.152
Spuren auf der Kassette aufgezeichnet (288 per Datenband
x 4 = 1.152 Spuren).
Bandformate und Kompatibilität
Die 1. Laufwerksgeneration 3592­J1A schrieb im Gen1­Format
300 GB auf die JA­Kassette und 60 GB auf die JJ­Kassette.
Die 2. Laufwerksgeneration TS1120 (3592­E05) schreibt im
Gen2­Format 500 GB auf die JA­Kassette und 100 GB auf
die JJ­Kassette. Das TS1120 Laufwerk kann auch im Gen1­
Format 300 GB auf die JA­ und 60 GB auf die JJ­Kassette
schreiben. Seit Verfügbarkeit der JB­Kassette schreibt das
TS1120 Laufwerk im Gen2­Format 700 GB auf die JB­
Kassette.
Die 3. Laufwerksgeneration TS1130 (3592­E06/EU6) schreibt
im Gen3­Format 1.000 GB und im Gen2­Format 700 GB auf
die JB­Kassette; 640 GB im Gen3­Format und 500 GB im
Gen2­Format auf die JA­Kassette und 128 GB im Gen3­Format
und 100 GB im Gen2­Format auf die JJ­Kassette.
Der Formatfaktor des Laufwerks und der Kassetten ermöglicht
den Einsatz des Laufwerks in den Tape Libraries IBM 3494
und IBM TS3500, TS3400 oder in Stand­alone­Rack­
Lösungen. Unternehmensweite Anschlussmöglichkeiten
sind gegeben: FibreChannel 4 Gb/s über Switched Fabric
mit zwei Ports für Open­Systems­Server und FICON­ oder
ESCON­Unterstützung (2 Gb) über A60 u J70 und (4 Gb)
über C06 für Server mit zOS.
Die Encryption­Möglichkeit, IBM 3592 Kassetten so zu
beschreiben, dass nur die Instanz sie wieder auslesen kann,
die den dazugehörigen Encryption Key kennt und hat, ist
wie beim Vorgänger TS1120 gegeben.
Mit den Durchsatz­/Kapazitätsmerkmalen und den schnellen
Spul­ und Fast­Search­Zeiten, ist das IBM TS1130 Laufwerk
einzigartig im Markt. Ein Backup­Fenster kann mit dem Einsatz
von TS1130 Laufwerken bei gleicher Laufwerksanzahl
auf 80% reduziert werden (z. B. Im Vergleich zu Generation 1).
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Das Laufwerk ist mit zwei Control­Prozessoren ausgestattet.
Das führt zu enormer Performance und Ausfallsicherheit.
Um den enormen Durchsatz von 160 MB/s auch nutzen zu
können, sind die TS1130 Laufwerke mit zwei 4­Gbit­FC­
Schittstellen ausgerüstet. Bereits mit den 3592­Laufwerken
konnte IBM den Weltrekord in Sachen Spulgeschwindigkeit
(‘High Speed Search’ von 8 m/s.) für sich beanspruchen.
Mit den neuen TS1130 Laufwerken übertrifft IBM ihren eigenen
Rekord und spult mit 12,4 m/s. Das entspricht 45 km/Stunde –
atemberaubend für ein Bandlaufwerk! Ohne GMR­Technik
hätte das nie realisiert werden können!
IBM 3592/TS1120/TS1130 Laufwerkspezifikationen im Überblick
Der Pufferspeicher wurde zum Vorgänger (TS1120) auf
1 GB verdoppelt. Dadurch wird eine wesentliche Leistungssteigerung
bezüglich Virtual Backhitch erreicht, da das
Laufwerk noch länger am ‘Streamen’ bleibt. Für die Optimierung
der Verarbeitung von großen Files wurde ein
SkipSync­Feature eingeführt, das eine bis zu 80 %ige
Leistungsverbesserung für diese Worloads bewirkt. Trotz
der höheren kapazitiven Nutzung der Kassetten (bis 1 TB)
ist das TS1130 Laufwerke in allen Bereichen wesentlich
schneller als sein Vorgänger.
Laufwerk Feature IBM 3592 IBM TS1120 IBM TS1130
Max. Kassettenkapazität 300 GB 700 GB 1.000 GB
Datenrate (native) 40 MB/s 104 MB/s 160 MB/s
System z-Anschluss 2 Gb FICON/ESCON 4 Gb FICON/ESCON 4 Gb FICON/ESCON
Open-System-Anschluss 2 Gbps FibreChannel 4 Gbps FibreChannel 4 Gbps FibreChannel
Virtual Backhitch Ja Ja Ja (erweitert)
Pufferspeicher 128 MB 512 MB 1 GB
Speed Matching 6 Geschwindigkeiten 6 Geschwindigkeiten 6 Geschwindigkeiten
Load-Thread-Zeiten 16 Sekunden 13 Sekunden 13 Sekunden
Durchschnittliche Zugriffszeit inkl.
Laden
60 Sekunden 47 Sekunden 38 Sekunden
Verschlüsselung nein Ja (kein Aufpreis) Ja (kein Aufpreis)
Stromverbrauch 42 Watt 42 Watt 46 Watt
Standby 27 Watt 27 Watt 17 Watt
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
139

140
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
Virtualisierung von Tape Libraries
TS3500 (3584) Library-Virtualisierung mit ALMS
(Advanced Library Management System)
Eine einmalige Funktionalität bietet die TS3500 mit ALMS
(Advanced Tape Library Management System). ALMS steht
für die TS3500 schon seit April 2006 zur Verfügung, wurde
aber erst richtig im Jahr 2007 genutzt. Mit ALMS wird die
physische Library virtualisiert, d. h., die HW wird von den Hosts
abgekoppelt. Zu den Hosts werden virtuelle Laufwerke und
virtuelle Kassettenslots dargestellt. Dies ermög licht eine
noch nie dagewesene Flexibilität, weil logische Partitionen
als logische Libraries im laufenden Betrieb dynamisch verändert,
also verkleinert oder vergrößert, werden können.
Storage Slot und Drive-Virtualisierung mit ALMS
Die Hosts, also die Backup­Applikationen, sehen völlig
transparent virtuelle Laufwerke und virtuelle Kassettenslots
so, als ob sie physisch vorhanden wären. ALMS zieht
zwischen der Library­Hardware und den Hosts eine virtuelle
Schicht ein, die es erlaubt, im laufenden Betrieb Hardware­
Erweiterungen vorzunehmen, logische Partitionen umzukonfigurieren,
zu verkleinern und zu vergrößern, ob es nun die
Laufwerke oder die Slots betrifft. ALMS ist eine einmalige
Funktionalität, die es nur mit der TS3500 Library gibt. ALMS
bietet vier wichtige Funktionalitäten für die TS3500 Library.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1.) Dynamisches Partitioning
Mit ALMS können im laufenden Betrieb Partitionen erstellt oder
verändert werden. Die physische Position in der Library ist
dabei nicht mehr relevant. Dies bezieht sich auf Kassettenund
Laufwerksstellplätze.
2.) Laufwerkssharing
Mit ALMS können Laufwerke verschiedenen Backup­Servern
zugeordnet werden und für den Backup­Server online gesetzt
werden, der sie gerade benötigt.
3.) Virtual I/O
ALMS bietet eine größere logische I/O­Station. Die Funktion
‘Virtual I/O’ ermöglicht es, dem Backup­Server eine virtuelle
I/O­Station von bis zu 255 Slots darzustellen. Das vereinfacht
das Kassettenmanagement beim Ein­ und Auschecken.
4.) Overallocation/Underallocation
Mit ALMS ist eine flexible Darstellung der Library­Größe
möglich und somit Over­ und Underallocation. Overallocation
verringert den Administrationsaufwand bei einer Library­
Erweiterung. Underallocation spart Lizenzkosten, z. B. im
Legato­Umfeld.
TS3500 Library Hardware-Erweiterungen 2007
Neben der Virtual I/O­Option des ALMS besteht seit Juni
2006 die Möglichkeit, D­Frames mit zusätzlichen physischen
I/O-Stations zu versehen. Bis zu vier I/O­Stations
mit jeweils bis zu 16 I/O­Slots können in eine D­Frame­Tür
integriert werden.
Die TS3500 unterstützt drei solchermaßen ausgestattete
D­Frames innerhalb der Library. Zusammen mit der I/O Station
im L­Frame mit 32 I/O­Slots, drei D­Frames mit bis zu
64 I/O­Slots bietet die TS3500 die Möglichkeit, 224 physische
Kassetten in die Library als ‘Bulk’ einzulagern oder
als ‘Bulk’ aus der Library zu entnehmen.
Für die TS3500 stehen flexible Modellkonvertierungen zur
Verfügung. So können alte Frames wie z. B. L22 und D22
mit TS1120 Laufwerken in die neuen L23­ und D23­Frames
umgebaut werden. Dasselbe gilt für die alten LTO­Frames
L52 und D52, die in die neuen LTO­Frames L53 und D53
umgebaut werden können.
TS3500 Library 4 I/O Station D-Frame
Bei den neuen Frames können nun TS1120 Frames (L23,
D23) in LTO­Frames (L53, D53) umgebaut werden. Ebenso
können die neuen LTO­Frames (L53, D53) in neue TS1120­
Frames (L23, D23) konvertiert werden. Damit bietet die
TS3500 eine sehr flexible Möglichkeit, bestehende Frames
auf neu gewünschte Ziel­Frames zu konvertieren.
Die TS3500 Library bietet mit der Funktionalität des Data
Gatherings die Möglichkeit, Informationen über die unter­
schiedlichsten Dinge, die in der Library ablaufen, zu erhalten.
Die Laufwerk-Statistik enthält Informationen über die letz­
ten Mounts jedes Laufwerks (nicht mit LTO1 möglich), die
Port Statistic enthält FibreChannel­Port­Informationen der
letzten Mounts (nicht mit LTO1 möglich), die Mount History
zeigt die Mount­Statistik der letzten 100 Kassetten, die ‘demounted’
wurden, und die Library Statistics gibt Aufschluss
über eine effektive Auslastung der logischen Libraries, d. h.,
es wird deutlich, ob manche logischen Libraries überdurchschnittlich
genutzt werden. Dadurch können die Partitionen
geändert werden, um die Library Performance zu verbessern.
Dies ist nur mit den neuen Frames möglich. Zusätzlich kann
eine Vielzahl von Informationen wie Residency Max Time
(maximale Mountzeit einer Kassette), Residency Avg Time
(durchschnittliche Mountzeit einer Kassette), Mounts Total
(Anzahl der gesamten Mounts), Mounts Max Time
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
141

142
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
(Maximalzeiten der Mounts), Mounts Avg Time (Durch­
schnittszeiten der Mounts), Ejects Total (Anzahl der Kasset­
tenausgaben), Ejects Max Time (Maximalzeiten von Kasset­
tenausgaben), Ejects Avg Time (Durchschnittszeiten von
Kassettenausgaben) und Total Inputs (Anzahl der Kasset­
ten­Inserts, die über die I/O­Station der Library zugeführt
werden) jeweils der letzten Stunde abgerufen werden.
IBM TS3500 Library – neue Erweiterungen und HD-Technologie
(High Density)
Im Juli und August 2008 kündigt IBM für die High End
Library TS3500 (3584) massive Erweiterungen an.
Mit dem am 15.07.2008 angekündigten neuen Release 8A
unterstützt die TS3500 Tape Library die neuen TS1130 Laufwerke.
Der Mischbetrieb mit den Vorgängerlaufwerken ist
auch gewährleistet. Voraussetzung für den Einsatz der
neuen TS1130 Laufwerke ist ALMS (Advanced Library
Management System). Neben der Unterstützung der
TS1130 Laufwerke bietet der neue Release 8A die Möglichkeit
der SSL­Funktionalität (Secure Socket Layer). Dieser
stellt sicher, dass, wenn die Library über das Web administiert
wird, kein anderer sich „dazwischenhacken“ kann, und
gewährleistet so absolute Administrationssicherheit. Ebenso
wurde bezüglich der Standardisierung die IPv6­Unterstützung
zur Verfügung gestellt (in USA eine wichtige Anforderung)
und die standardisierte SMI­S­Schnittstelle integriert.
Ein neues Tool ist der TSR, der ‘Tape System Reporter’.
Dieser erlaubt es mit Windows basierenden Systemen (also
z. B. mit dem Laptop), aktuelle Status­Abfragen der Library
zu bekommen und zu sammeln (auch über einen längeren
Zeitraum). Alle Updates und Neuerungen sind über einen
Microcode­Update verfügbar.
Für alle Sx4­Gehäuseeinheiten stehen jetzt auch LEDs als
Beleuchtung zur Verfügung (Bild rechts). So kann ein Beobachter
genauer sehen, was der Roboter und die Kassetten
machen, und kann den Betriebsablauf in der Library sichtbar
verfolgen. Interessant ist, dass diese Anforderung von
vielen TS3500­Nutzern gestellt wurde!
Mit dem am 26.08.08 angekündigten neuen Release 8B
stehen der Library ganz neue, sogenannte High Density
(HD) Frames, zu Verfügung, die es erlauben, über die dreifache
Menge an physischen Kassetten in einem Frame zu
IBM TS3500 – schnellstes Bandarchiv im Markt
lagern. Für die 3592­Kassetten wird das neue S24 Frame
verwendet, für die LTO­Kassetten das neue S54 Frame.
Voraussetzung für den Betrieb der neuen Frames in der
TS3500 Library ist ALMS (Advanced Library Management
System) und ein neuer Gripper. Die Kassetten werden in
mehreren Slot­Reihen hintereinander abgelegt. Greift der
Gripper, der diesem neuen Handling angepasst wurde, eine
Kassette aus der ersten Reihe, rutschen die dahinterliegenden
Kassetten um einen Slot nach vorne und umgekehrt!
Eine geniale und IBM patentierte Konstruktion, um auf allerkleinstem
Raum viele Kassetten unterzubringen und dabei
Vollautomation sicherzustellen.
IBM TS3500 – LED-Beleuchtung
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Im S24 Frame für 3592 Kassetten (1/2 Zoll) , die etwas größer
als LTO­Kassetten sind, sind 5 Tierstufen etabliert, d. h., auf
der Rückseite des Frames sind hinter jeder Slotreihe nochmals
3 zusätzliche Slotreihen untergebracht. Ein S24 Frame
kann damit bis zu 1.000 Kassetten ablegen. Für die
kleineren LTO­Kassetten stehen sogar 6 Tierstufen zur Verfügung,
d. h., hinter jeder Slotreihe auf der Rückseite sind
nochmals 4 zusätzliche Slotreihen untergebracht. Ein S54
Frame kann somit bis zu 1.320 Kassetten ablegen.
IBM TS3500 – HD-Frame S54 für LTO-Kassetten
Die Hardware in Form von HD­Frames ist die eine Sache,
doch jetzt gilt es, diese HD­Frames effektiv zu verwalten.
Dazu stehen neue Funktionen für die TS3500 Library zur
Verfügung.
Hier ist am Beispiel des S54 Frames (siehe Abbildung) mit
bis zu 5 Tierstufen das HD Slot Management beschrieben.
Alle Tiers und damit alle HD­Slots sind völlig transparent zu
den Hosts. Drei Key­Elemente sind für das HD Slot Management
zuständig. Die Funktion Floating Home Cell optimiert
die Kassettenbelegung in den Slots der Tierstufen 0 und 1.
Darüber hinaus werden die Slots der Tierstufe 0 als Cartridge
Cache behandelt, d.h. alle Kassetten, die sich in
Slots der Tierstufe 0 befinden, werden einem LRU­Caching­
Algorithmus (Least Recently Used) unterzogen. Werden die
Kassetten länger nicht gebraucht (im Vergleich zu anderen
Kassetten der Tierstufe 0), werden sie von Tierstufe 0 in
Slots der Tierstufe 1 verlagert. Werden sie dort im Vergleich
zu anderen Kassetten der Tierstufe 1 nicht benutzt, werden
sie in Slots der Tierstufe 2 verlagert. Das geht je nach Füllgrad
der HD­Slots bis in die letzte Tierstufe. Das Cartridge
Caching stellt also sicher, dass Kassetten, die häufig benötigt
werden, immer im direkten Zugriff des Roboters stehen,
also in Tierstufe 0 und 1.
Sind nun mehrere HD­Frames innerhalb einer Library in
Betrieb, sorgt die Funktion Tier Load Balancing dafür, dass
alle HD­Slots vom Kassettenfüllgrad über alle HD­Frames
gleichmäßig benutzt werden (ausbalancierte Slotausnutzung
über alle HD­Frames). So wird sichergestellt, dass sich die
Kassetten möglichst in den Slots der kleineren Tierstufen
befinden und alle HD­Frames bezüglich ihrer Tierbenutzung
gleichmäßig optimiert werden.
Über eine SCSI Command Option kann für bestimmte Kas­
setten der Cartridge Caching Algorithmus umgangen wer­
den. Die Option lässt zu, ausgewählte Kassetten immer im
Cache, also immer in der Tierstufe 0 zu lagern oder auch
nicht. Der Command steuert das gezielte Prestaging und
Destaging von ausgewählten Kassetten in und aus dem
Cache (Tierstufe 0).
Für die neuen HD­Frames steht eine „Capacity on Demand“
Option (CoD) zur Verfügung. Standardmäßig werden die
neuen S24 und S54 Frames so ausgeliefert, dass 3 vertikale
Tierreihen aktiviert sind. Tier 0 auf der Frontseite und die
ersten beiden Tiers 1 und 2 auf der Rückseite des Frames.
Mit dieser Aktivierung kann ein S24 Frames 600 Slots und
ein S54 Frames 660 Slots nutzen.
Über eine ‘On Demand’­Aktivierung können die noch nicht
genutzten Slots freigeschaltet werden, d. h., bei dem S24
Frame werden die Tiers 3 und 4 freigeschaltet und bei dem
S54 Frame die Tiers 3, 4 und 5. Mit dieser Freischaltung
können alle Slots im Frame genutzt werden und damit die
maximale Anzahl an Kassetten und damit die höchste Kapazität
abgebildet werden.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
143

144
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
Modellkonvertierungen der neuen Frames, also der Umbau
von S24 nach S54 oder von S54 nach S24 stehen seit dem
20. Februar 2009 zur Verfügung.
Mount-Zeiten HD-Frames
Die Roboter Mount­Zeiten wurden für die HD­Frames in
einer 6­Frame­Konfiguration der TS3500 unter Produktionsbedingungen
bei einem Kunden ermittelt (siehe Grafik
‘Roboter Mount­Zeiten HD­Frames’).
Roboter Mount-Zeiten HD-Frames
Der Zugriff auf Kassetten in der Tierstufe 0 ist am schnellsten,
da der Greifer des Roboters in seiner Grundstellung in Richtung
Tierstufe 0 ausgerichtet ist. Der Zugriff auf die Tierstufe
1 ist 760 ms langsamer, da jetzt der Greifer sich um 180
Grad drehen muss, um sich in Richtung Tierstufe 1 auszurichten.
Kassetten in der Tierstufe 2 benötigen nochmals zusätzliche
2 Sekunden. Diese kommen zustande, da der Roboter
zuerst die Kassette in der Tierstufe 1 herausnehmen muss.
Dann rutscht die Kassette in der Tierstufe 2 nach vorne in
die Tierstufe 1. Der Roboter greift dann diese Kassette mit
seinem zweiten Greifer (Dual Gripper Standard) ab. Die
große Zeitspanne ergibt sich zwischen Tierstufe 2 und 3.
Die 10,9 Sekunden kommen zustande, weil der Roboter
zuerst die Kassetten der Tierstufe 1 und 2 herausnehmen
und an einen anderen Platz bringen muss. Dies wird aufgrund
der zwei Gripper in einem Vorgang durchgeführt.
Inzwischen sind die Kassetten von Tierstufe 3 und 4 in die
Tierstufen 1 und 2 vorgerutscht. Der Roboter kann sie dann
dort in einer zweiten Aktion abholen.
Tape Library-Virtualisierung mit dem Enterprise Removable
Media Manager (eRMM, iRMM)
Der Enterprise Removable Media Manager bildet einen Virtualisierungslayer
zwischen Datensicherungs­Anwendungen
und der Tape Library­Hardware. Durch die Entkoppelung
von Datensicherungsanwendungen und Tape Library­Hardware
wird größtmögliche Flexibilität und Skalierbarkeit der
Tape Library­Infrastruktur erreicht und der Funktionsumfang
von Libraries mit SCSI Media Changer wie z. B. IBM TS3500,
durch erweitertes Media Management ergänzt. eRMM (seit
August 2007 als Programmpaket iRMM – integrated
Removable Media Manager – verfügbar) bietet die effizientere
Nutzung von Drives und Libraries durch dynamisches
Sharing und Pooling der Bandlaufwerke. Es erlaubt zentrales
Management von Bändern und Bandlaufwerken, die von
verschiedenen Anwendungen genutzt werden, und bietet so
größtmögliche Flexibilität und Skalierbarkeit der Tape Library­
Infrastruktur. Das Ergebnis sind verkürzte Backup­Laufzeiten
durch flexible Tape Device­Zuordnung und eine deutliche
Ressourceneinsparung bei der Tape Library­Infrastruktur.
In modernen Umgebungen mit Speichernetzen sind Server
und Tape Libraries über ein Speichernetz miteinander verbunden.
Damit sind die technischen Voraussetzungen für
das effiziente Sharing von Tape­Ressourcen zwischen verschiedenen
Backup­ und Archivierungsservern nur bedingt
erfüllt. Für Tapes fehlt eine Abstraktionsschicht, die mit
einem Volume Manager (SAN Volume Controller) oder einem
Dateisystem (SAN File System) vergleichbar ist. Das führt
dazu, dass Tape­Ressourcen nur sehr eingeschränkt von
mehreren Anwendungen gemeinsam genutzt werden können.
Die Datensicherungsanwendungen verlangen meist exklusiven
Zugriff auf einen Teil der Ressourcen. Es fehlte bisher
eine zentrale Verwaltung von Tape­Ressourcen, welche die
Voraussetzung für ein anwendungsübergreifendes Sharing
ermöglichen. Mit eRMM (iRMM) macht IBM eine Lösung
ver fügbar, die genau diese Anforderung erfüllt. Dieses
Programm produkt wurde in der IBM Lokation in Mainz ent­
wickelt. iRMM ist jetzt auch in modifizierter Form integraler
Bestandteil der TS7700 Virtual Tape Server Systeme und
ersetzt den bisher benötigten Library Manager in System z­
Umgebungen.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

TS3400 Mini-Library mit TS1120 Laufwerken für Mainframe und Open Systems
TS3400 Mini-Library für High-End-Tape-Technologie
Im Februar 2007 kündigte IBM eine kleine Library TS3400
an, die wie die große TS3500 mit den TS1120 und TS1130
High­End­Laufwerken arbeitet. Die Library wurde speziell für
die High­End­Tape­Laufwerke TS1120 (Jaguar­Technologie)
als Einstiegslösung konzipiert. Diese kleine Library kann
sowohl im Open­Systems­Umfeld als auch im Mainframe­
Umfeld (über den TS1120 FICON Controller seit August 2007)
betrieben werden. Die TS3400 bietet eine native Kapazität
von 12,6 TB (TS1120) und 18 TB (TS1130) an.
In die TS3400 können 1 bis 2 TS1120 und TS1130 FC-
Bandlaufwerke mit 4­GB/s­Dual­Port­Fibre­Channel­
Anschlüssen integriert werden. Man kann alle Kassetten,
die ein TS1120 und TS1130 Laufwerk verarbeitet, verwenden
(100­, 500­ und 700­GB­Kassetten bei TS1120 und 128­,
640­ und 1.000­GB­Kasetten bei TS1130). Die Library unterstützt
sowohl überschreibbare als auch WORM­Kassetten
und bietet direkte Encryption und Encryption Key Management­Unterstützung
an, eine Verschlüsselungstechnik, die
für die TS1120 Laufwerke im Herbst 2006 zur Verfügung
gestellt wurde und ebenso in die TS1130 Laufwerke integriert
ist. Die Library hat 2 herausnehmbare austauschbare
Kassettenmagazine. Jedes Magazin kann bis zu 9 Kassetten
aufnehmen. Das untere Magazin kann so konfiguriert
werden, dass 3 Slots im Magazin als I/O­Station dienen. Das
obere Magazin ist mit zwei Reinigungskassettenslots konfigurierbar.
Die Ausstattung mit Barcode­Leser ist Standard.
Die TS3400 bietet eine Partitionierung von bis zu 2 logischen
Libraries. Jede logische Library enthält ein Laufwerk und ein
Magazin und kann im Sequential­Mode (Autoloader) oder
Random­Mode (Library) arbeiten. Die TS3400 ist über das
lokale Operator Panel oder remote über ein Web GUI admi­
nistrier­ und managebar. Die Library kann ‘Stand Alone’ oder
‘Rack Mounted’ (5U) betrieben werden. Die Speicherkapazität
bei Verwendung der 700­GB­Kassetten geht bis 12,6 TB
(bis 37,8 TB mit 3:1 Kompression) und bei Verwendung
der 1.000­GB­Kassetten bis 18 TB (bis 54 TB mit 3:1 Kompression).
Die TS3400 ist eine hochredundante Library und mit redundanter
Stromversorgung, ‘Hot Swappable’­Laufwerken und
Netzteilen, einem doppelten Stromanschluss sowie Control
Path und Data Path Failover­Möglichkeit ausgestattet. Die
Library kann an IBM Systeme i, p, x und zLinux sowie an z/OS
via TS1120 Controller angeschlossen werden. Außer den
IBM Systemen werden die Betriebssystem­Plattformen von
HP, Sun und Microsoft Windows unterstützt.
Damit stellt IBM die Möglichkeit zur Verfügung, große
TS3500 Libraries mit TS1120 und TS1130 Laufwerken in
einem zentralen Rechenzentrum zu betreiben, während
Außenstellen mit derselben Technologie in Form einer Mini­
Library arbeiten können. Dies ermöglicht den Datenträgeraustausch
in Form von 3592 Kassetten zwischen Rechenzentrum
und Außenstellen. Um hier höchste Sicherheitsaspekte
zu gewährleisten, bieten die TS1120 und TS1130 Laufwerke
die Möglichkeit, die Kassetten in verschlüsselter Form zu
beschreiben (siehe auch unter Tape Encryption).
Mit der Verfügbarkeit der TS3400 erweitert sich das IBM
Library­Portfolio in der Weise, dass kleine bis ganz große
Lösungen sowohl mit TS1120 und TS1130 Technologie als
auch mit LTO­Technologie ermöglicht werden.
TS2900 Autoloader mit HD-Technologie (High Density)
IBM kündigt im August 2008 (zusammen mit der HD­Frame­
Ankündigung der TS3500) eine neue Library­Einstiegslösung
TS2900 an, die Kapazitäten von 3,6 TB bis 7,2 TB (native)
bietet und mit einem halbhohen LTO3­Laufwerk oder einem
halbhohen LTO4­Laufwerk ausgestattet werden kann. Die
älteren LTO­Technologien LTO1 und LTO2 sind in dieser Einstiegslösung
nicht unterstützt.
Der neue Autoloader steht seit September 2008 für den Einstiegsbereich
zur Verfügung. Er hat nur eine Bauhöhe von
1U und sieht damit fast wie eine dünne „Pizzascheibe“ aus.
Wegen dieser geringen Bauhöhe sind nur LTO­Laufwerke in
halber Bauhöhe integrierbar. Die TS2900 lässt sich mit
einem Laufwerk HH LTO 4 SAS oder einem HH LTO 3 SAS
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
145

146
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
konfigurieren und bietet Platz für bis zu neun LTO­Kassetten,
die in einem austauschbaren Magazin dem Autoloader zur
Verfügung gestellt werden. Ein Slot des Magazins dient als
I/O­Station. Trotz der kleinen Baugröße bietet der Autoloader
beträchtliche Kapazitäten. Mit LTO4 erreicht man bis zu
14,4 TB (mit 2:1 Kompression). Diese kleine Mini­Library
bietet direkten Zugriff auf jede Kassette und kann über das
Web administriert werden.
Die TS2900 Mini­Library ist eine geniale Konstruktion auf
kleinstem Raum, weil man in der Konstruktion von 1U Höhe
ein halbhohes LTO3­ oder LTO4­Laufwerk untergebracht
hat, ein Greifersystem, das direkten Zugriff auf alle neun
Kassetten im Magazin hat, Netzteil, die ganze Elektronik
einschließlich des Gebläses sowie ein herausnehmbares
Magazin mit zehn Kassetten­Stellplätzen, von denen nur
neun Stellplätze mit Kassetten belegt werden können.
Auf dieser niedrigen Bauhöhe neun Kassetten unterzubringen
und die im direkten Zugriff des Greifers zu haben, ist nur
durch die neue patentierte HD-Technologie (High Density)
von IBM möglich.
Das Magazin, das herausgenommen werden kann, ist mit
dieser HD­Technik ausgestattet. Es fasst eigentlich zehn
Kassetten, immer zwei in fünf aneinanderliegenden Reihen
von jeweils zwei Kassetten und darf nur mit neun Kassetten
bestückt werden – damit ist ein Stellplatz im Magazin immer
frei und wird als ‘Cartride Caching’­Slot eingesetzt.
Links auf dem Bild ist das Greifersystem abgebildet, das auf
dem rechten Bild vorne hin­ und herfährt. Muss nun ein
Zugriff auf eine Kassette erfolgen, die in einem der fünf
Schächte hinten abgelegt ist, nimmt der Roboter die erste
Kassette heraus und stellt sie in dem Schacht ab, wo nur
eine Kassette liegt! Die dahinterliegende Kassette rutscht
automatisch einen Stellpatz vor und wird dann in einem
zweiten Schritt vom Roboter geholt und dann zum Laufwerk
gebracht, das sich ganz rechts vom Magazin befindet.
Damit ist der Greifer immer in der Lage, jede Kassette auf
Anforderung zum Laufwerk zu bringen. Einfach faszinierend,
wie sich mit Ideen ganz neue Dinge umsetzen lassen!
Unten stehende Grafik zeigt im Überblick das komplette
Library­Angebot der IBM im Jahr 2009/ 2010, von der Mini­
Library TS2900 bis zur High End Library TS3500. TS2900
und TS3400 sind IBM Eigenentwicklungen und werden von
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

der Firma NEC als OEM­Produkt für IBM produziert. Die Einstiegslösungen
TS3100 und TS3200 kommen von der Firma
BDT und werden als IBM Logo­Produkte vertrieben. Als
Midrange Library für LTO­Laufwerke hat die IBM die TS3310
im Portfolio, eine Library, die von Quantum/Adic gebaut wird
und per OEM als IBM Logo­Produkt vetrieben wird. Quantum
selbst vertreibt diese Library als Scalar 500i auch
selbst. Der Produktunterschied liegt darin, dass die IBM
TS3310 ‘End to End’ Path Failover unterstützt. Im High­End­
Bereich verwendet die IBM die TS3500, die IBM selbst produziert
und konstant weiterentwickelt. Die TS3500 ist derzeit
die schnellste Library auf dem Markt und bietet viele Alleinstellungsmerkmale
und Vorteile gegenüber vergleichbaren
Libraries. Das angebotene Library­Portfolio ist für einen Hersteller/Anbieter
einmalig und bietet Tape Automation für alle
Anforderungen.
File Virtualisierung und File Area Networks (FAN)
Global Parallel File System (GPFS) und Scale Out File Services
(SOFS)
Unter Verwendung von erprobten IBM Baugruppen wie GPFS,
BladeCenter und Storage stellte IBM im November 2007 ein
hochskalierbares und hochperformantes Dateisystem mit
integrierten ILM­Funktionalitäten vor. Das System ist in der
Lage, linear mit den Anforderungen an Speicherplatz und
Durchsatz zu wachsen, und bietet neben extremer Hochverfügbarkeit
eine einfache Administrierbarkeit. Im Frühjahr
2010 kommt als Lösungsnachfolger von SOFS die IBM
SPSC­Lösung zur Anwendung. SPSC steht für Smart Private
Storage Cloud.
IBM SPSC – Smart Private Storage Cloud (vormals SOFS Scale
Out File Services)
Lösungsüberblick
Die IBM SPSC­Lösung wurde entwickelt, um einfach und
performant unstrukturierte Daten in Kundenumgebungen zur
Verfügung zu stellen und bekannte Engpässe (Administration,
Wachstum, Durchsatz, z.B bei Web­Anwendungen) in
aktuellen Network Attached Storage­Lösungen – kurz NAS –
zu beseitigen.
Als Basis der IBM SPSC­Lösung dienen erprobte IBM Hardware­Komponenten
– IBM Bladecenter mit IBM Storage­
Produkten – und das IBM General Parallel File System – kurz
GPFS, das seit 1996 in High­Performance­Computing ­
Umgebungen sehr erfolgreich eingesetzt wird. IBM GPFS
stellt eine stabile Grid­Plattform mit erprobten Skalierungsmöglichkeiten
und integrierten Hochverfügbarkeitsfunktionen
zur Verfügung.
Durch Erweiterungen mit bewährten Bausteinen (Redhat
Linux, Samba) verfügt SPSC über eine hochmoderne und
eine offene Systemplattform. Dieses Grid­basierte Lösungskonzept
stellt eine stabile Scale­Out­Plattform für zukünftige
Storage­Anforderungen zur Verfügung. Durch Fokussierung
der SPSC­Entwicklung auf eine optimierte Betriebsführung
und reduzierte Komplexitätsanforderungen integriert IBM
bereits im SPSC­Standard viele Funktionalitäten und unterstützt
diese mit Prozessen. Diese Funktionalitäten beinhalten
Trendanalysen, Datenmigrationsprozesse und Information
Lifecycle Management Prozesse.
Ebenso wie die in der IBM SPSC­Lösung integrierten
Management­Funktionalitäten wie Monitoring, Administration
und Operation erlauben Schnittstellen eine einfache Integration
in die IT­Überwachung und garantieren geringe Administrationsaufwände.
Zur Steigerung der Backup/Restore­
Zeiten erfolgte eine Integration von IBM Tivoli Storage
Manager – kurz TSM – in die Lösung. Unter Verwendung
der SPSC­Mechanismen reduzieren sich die Scan­Zeiten
erheblich, Gleiches gilt für den Restore.
IBM SPSC bietet:
einen globalen Namensbereich für alle Verzeichnisse
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
•
•
•
•
•
•
•
•
(File-Virtualisierung)
einfachste Betriebsführung und Administration
Hochverfügbarkeitsmechanismen eines Clusters mit Grid-
Mechanismen
dynamische Erweiterung/Reduzierung ohne Betriebsunterbrechung
integrierte Information Lifecycle Funktionalitäten mit automatisierten
Regeln auf File-Ebene, in Kombination mit TSM
HSM eine Integration bis auf Band
flexible Kopplung von Anwendungsservern durch CIFS,
NFS, GPFS Cross Cluster Mount
sehr große Speichervolumen in einem System (>10 Peta-
Byte)
integrierte Datenmigrationsmechanismen
147

148
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
Lösungskomponenten
Im Bild ‘SPSC­Lösungskomponenten’ wird der schematische
Aufbau der Lösung im Gesamtüberblick dargestellt. Die
Bausteine HSM, TSM sind hierbei Optionen, die auf Wunsch
in die Lösung integriert werden können. Die SPSC­Lösung
besteht immer aus IBM Komponenten und Erweiterungen
von GNU­Komponenten.
IBM Lösungskomponenten:
•
•
•
•
IBM Hardware (BladeCenter, Storage)
IBM Software (GPFS, TSM, HSM, SPSC Lizenzmaterial)
inklusive Subscribtion
Zusätzliche SW – Redhat Linux, CIFS, Samba ..
inklusive Subscribtion, soweit nötig
IBM Implementierungsservice
IBM Server und Storage-Hardware
Basierend auf IBM HW­Bausteinen wird für jede Anforderungen
ein System zusammengestellt. Die Konfiguration
wird bestimmt aus der benötigten Leistung (Durchsatzanforderungen,
Speicherbedarf, Verfügbarkeits­ und Erweiterungsanforderungen).
Durch Nutzung des IBM SAN Volume
Controllers besteht die Option, vorhandene Plattensysteme
anderer Hersteller zu integrieren (Investitionsschutz) und die
Vorteile einer Blockvirtualisierung zu nutzen.
IBM Software
GPFS bildet und stellt die Laufzeitumgebung der Lösung
bereit. Optional kann die Lösung mit TSM und/oder um effiziente
Backup­ und Recovery­Mechanismen und/oder
hierarchisches Speicher­Management erweitert werden.
IBM Implementation Service
Mit dem IBM Implementation Service wird die SPSC­Lösung
in bestehende IT­Umgebungen integriert:
Konfigurations- und Anbindungsplanung
Installation aller IBM HW -und SW-Komponenten
In Vertretung die Installation der Open-Source-Produkte
Inbetriebnahme der SPSC und Unterstützung bei
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
•
•
•
•
•
•
•
Einbindung in die IT-Infrastruktur
Überführung der SPSC-Lösung an das Operating Team
Dokumentation der Implementierung
Projektleitung
IBM Basis Support Service
Der Service beinhaltet Solution­orientierten Support mit
zentraler Call Entry für alle Fragen und Probleme mit der
SPSC­Lösung. Diese Support­Struktur beinhaltet die Problemlösung
der Open­Source­Komponenten und stellt höchste
Verfügbarkeit der Lösung sicher.
•
•
•
•
Zentrales Customer Care Center für Fehlermeldung
Bereitstellung von Informationen zu Fehlerkorrekturen,
Programmkorrekturen für bekannte Fehler
Updates des SPSC-Codes und der zugehörigen
Dokumentation
Bereitstellung von Unterstützung für das aktuelle und das
vorhergehende Release des SPSC-Codes
IBM Premium Service (beinhaltet Basis Support Service)
Der Premium Service erweitert den Basis­Support mit der
Übernahme von Basis­Betriebsaufgaben wie Füllstandsüberwachung,
Change und aktive Problembeseitigung und
Pflege des Systems mit SW­Updates, Optimierungen und
technischer Administation der Lösung.

Der IBM SPSC Premium Service unterstützt bei den
Betriebsleistungen auf Basis 7 Tage x 24 Stunden und beinhaltet
folgende Tätigkeiten der IBM:
•
•
•
•
•
•
•
•
•
•
Zentrales Customer Care Center für alle Kundenanfragen
Regelmäßige Überwachung der Lösung und aktives Operating
Bereitstellung von Patches/Updates und Einspielen in die
SPSC-Umgebung nach Absprache mit dem Kunden
Lösungsunterstützung bei Problemen (Problem Ownership
inklusive der Einbindung notwendiger Funktionen,
z. B. HW-Maintenance)
Regelmäßige Betreuung zur Betriebsoptimierung und
Nutzung
IBM Projektverantwortliche für alle Betriebsanfragen
Regelmäßiger Statusreport (Nutzungskenngrößen,
Auslastung, Durchsatz)
Optimierung der SPSC-Lösung auf Basis der Betriebserfahrungen
Planung von Änderungen (neue Kundenprojekte einführen,
Leistungsparameter)
Strategische Weiterentwicklung der Lösung für geplante
Projekte
SPSC-Standard-Funktionalitäten
SPSC stellt eine skalierbare Plattform für alle Anforderungen
von Fileservices zur Verfügung. Durch den sehr modularen
Aufbau passt sich die SPSC­Lösung leicht den Bedürfnissen
und Anforderungen an. Veränderungen an der Konfiguration
und Systemkomponenten können in den meisten Fällen im
Online­Betrieb erfolgen.
Globaler Namensbereich für alle Verzeichnisse
Durch Verwendung des GPFS­Filesystems ermöglicht SPSC
die Repräsentation eines transparenten Filesystems innerhalb
der Lösung (Filesystem­Virtualisierung).
Dieser Ansatz erlaubt es, Daten in unterschiedlichen Speicherklassen
zu speichern, ohne ihre Repräsentation zum
Benutzer zu verändern. Hierbei ist es unerheblich, ob dies
ein SPSC­Cluster ist oder mehrere SPSC­Cluster zusammengeschaltet
werden.
Hochverfügbarkeitsmechanismen eines Grids
Ein SPSC­Cluster kann aus bis zu 26 Blades bestehen mit
einem zusätzlichen Quorum Server. Der Quorum Server
erlaubt eine automatisierte Umschaltung bei Ausfall/Nichtverfügbarkeit
eines Clusterteils.
Die Basis hierfür bildet die Aufsplittung eines SPSC­Clusters
in zwei BladeCenter in zwei Rechenzentren (< 20 km Entfernung).
In diesem Clusteraufbau sind alle Knoten aktiv und
bedienen ankommende Anfragen. Bei Ausfall eines Rechenzentrums
übernimmt der verbleibende Clusterteil die
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
149

150
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
Gesamtmenge der Anfragen und erhält den Service für den
Benutzer. Diese Mechanismen finden bei der Spiegelung
der Filesysteme ebenfalls Anwendung.
Spiegelmechanismen auf Filesystemebene
Bei der Spiegelung von Dateien zur Erhöhung der Datensicherheit
können, basierend auf Datei­Shares, Spiegelungen
mittels Policies eingerichtet werden. Der Spiegel kann hierbei
jeweils (und/oder) im gleichen Share, in einem anderen
Share oder einem anderen Cluster definiert werden.
In SPSC erfolgt die Spiegelung der definierten Dateien
durch das parallele Schreiben der Dateien unter Kontrolle
von GPFS. Diese erlaubt eine parallele Verarbeitung der
Schreibvorgänge, speziell bei mehrfachen Spiegeln in mehreren
Clustern. Hierbei ist einen Kopplung der Plattensysteme
nicht notwendig.
Dynamische Erweiterung ohne Betriebsunterbrechung
Die SPSC­Lösung erlaubt die Erweiterung/Verkleinerung der
Lösung unter vollem Online­Betrieb.
Veränderungen an der SPSC­Lösung erfolgen in voneinander
unabhängigen Schritten. Die Verteilung der Daten liegt ausschließlich
in Verantwortung von SPSC.
Erweiterung von Speicherkapazität (Beispiel):
1. Basiskonfiguration der neuen Storage-Komponenten
(LUNs)
2. Anbindung der Storage-Komponenten an das
BladeCenter
3. Übergabe der Resourcen an SPSC in Form zusätzlicher
LUNs
4. Mit dem SPSC-Administrationsinterface werden die LUNs
Shares zugeordnet.
5. SPSC übernimmt automatisch das Striping der Daten über
den erweiterten Share.
SPSC integrierte ILM-Funktionalitäten
Mit den integrierten ILM­Funktionalitäten (Information Lifecycle
Management) bietet IBM SPSC eine Plattform zur effizienten
und automatisierten Handhabung von unstrukturierten
Daten. Durch die Definition­Regeln auf Fileebene können
automatisiert Verlagerungsprozesse auf unterschiedliche
Speicherklassen angestoßen werden und in Kombination mit
IBM TSM (Tivoli Storage Manager) und HSM (Hierarchical
Storage Manager) erfolgt die Auslagerung bis auf Bänder,
wobei die Dateieinträge transparent im Filesystem für den
Benutzer dargestellt werden.
Wie bereits beschrieben, können in SPSC mehrere unter­
schiedliche Speicherklassen definiert werden.
Zur Optimierung der Nutzung der Speicherklassen verfügt
SPSC bereits in Basisfunktionalität über ILM­Erweiterungen
(Information Lifecycle). Hierbei können auf Grundlage von
Policies auf Share­Ebene definiert werden, auf welchem
Type von Plattenspeicher Daten vorgehalten werden sollen.
Optional kann eine Migration bis auf Band erfolgen:
Definition von Policies für Dateien auf Share-Ebene
Automatische Migration der Dateien nach den definierten
Policies
Transparenter Zugriff für den Benutzer (inklusive der Bandnutzung)
Optional: Bei Einsatz von TSM HSM – Tivoli Storage Manager
Hierarchical Storage Manager – kann bei der Migration ein
Bandlaufwerk integriert werden.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
•
•
•
•

Flexible Anbindung von Anwendungssystemen
Zusätzlich zu den Protokollen CIFS/NFS steht eine hochperformante
Anbindung von Linux­Anwendungsservern mittels
GPFS Cross Cluster Mount zur Verfügung. Die Kopplung
erfolgt hierbei mittels des IBM GPFS­Protokolls, das in
HPC­Umgebungen sehr erfolgreich eingesetzt wird. Zur
Optimierung des Datendurchsatzes unterstützt IBM SPSC
die direkte Kopplung von GPFS­basierten Anwendungsservern.
Diese Kopplung erlaubt durch das im GPFS implementierte
Protokoll einen maximalen Datendurchsatz.
Integrierte Datenmigrationsmechanismen
Basierend auf den beschriebenen Verfahren für die Online­
Erweiterung vom Speicher kann sehr einfach und effizient
eine Datemigration erfolgen. Die Datenmigration kann hierbei
ohne zusätzliche Werkzeuge bei minimalen Systembelastungen
durchgeführt werden.
Die hierzu notwendigen Schritte sind:
1. Bereitstellung der LUNs im SPSC
2. Einrichten der Migrationsbeziehung zwischen den
abzulösenden Speicherbereichen
3. Migration der Daten auf die neuen LUNs
4. Auflösen der Migrationsbeziehung im Speicherbereich
5. Herausnahme der alten LUNs aus dem SPSC-Cluster
Erweiterungspotenziale für SPSC
Mit SPSC steht eine skalierbare NAS­Plattform zur Verfügung.
Die Skalierung kann hierbei unter mehreren
Geschichtspunkten erfolgen:
•
•
•
•
Durchsatz bei Zugriff auf die Dateien: zusätzliche Blades
Volumen: zusätzlicher Speicher
Fehlbedienung/Datenintegrität: asynchroner Spiegel
Höhere Verfügbarkeit: SPSC Cross Cluster Mount
Alle diese Erweiterungen stehen innerhalb der Lösung zur
Verfügung, egal mit welcher Variante und in welcher Umgebung
gestartet wird.
ILM-Prozesse mit integrierter Auslagerung auf Bänder
Da Filer meist mit sehr viel Datenvolumen von inaktiven
Dateien gefüllt sind (60–70% der Daten, da nicht mehr
be nötigt), können diese kostengünstig auf Bänder ausgelagert
werden. Auf Basis von Policies erfolgt automatisiert die
Auslagerung über Speicherklassen bis auf Bandkassetten.
Die Verschiebung erfolgt zunächst innerhalb des Filers auf
unterschiedliche Plattentypen
Die Policies wirken auf Fileebene
Nach Regeln werden die Daten automatisiert an TSM-HSM
übergeben und für den Windows-Benutzer als Offline-
Datei markiert.
Bei Öffnen der Datei wird diese automatisiert aus der
TSM-HSM-Umgebung wiederhergestellt.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
•
•
•
•
Optionale Erweiterungen
Asynchroner Spiegel
Mit dem asynchronen Spiegel können zeitversetzt Daten
online kopiert werden, um gegen ungewollte Datenlöschung
oder im Katastrophenfall einen zusätzlichen Datenbestand
zu haben. Hierbei können kurzfristig Daten zurückgeholt
werden (innerhalb des Synchronisationszeitraums oder im
K­Fall als Betrieb des asynchronen Clusters als Notsystem).
Der asynchrone Spiegel ist hierbei ein SPSC­Cluster, der im
Normalbetrieb als Teil des Produktionsclusters läuft. Die
Spiegelungsregeln werden wie durchgängig in SPSC per
Policy definiert.
Weitstreckenkopplung von SPSC-Clustern durch Grid-Prozesse
Mit SPSC stehen mehrere Varianten einer Kopplung von
unternehmensweiten Lösungen zur Verfügung.
•
•
Kopplung von zwei eigenständigen SPSC-Clustern unter
einem Global Namespace. Jeder der Cluster hält einen Teil
der Benutzerdaten.
Alternativ kann ein SPSC-Cluster als asynchrone Spiegellokation
genutzt werden, in der mit Zeitversatz die
Betriebsdaten bereitstehen. Bei Bedarf kann diese Lokation
als Notfalllokation aktiviert werden.
151

152
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
Encryption für Tape
Im August 2006 kündigte IBM die Verschlüsselungstechnik
und ein dazugehöriges Schlüsselmanagement für die
TS1120 Bandlaufwerke (Jaguar 2) an. Damit können 3592
Kassetten so beschrieben werden, dass nur die Instanz sie
wieder auslesen kann, die den dazugehörigen Encryption
Key kennt und hat. Missbrauch von Daten, die sich auf den
Kassetten befinden, kann somit ausgeschlossen werden.
Fallen Kassetten aus irgendwelchen Gründen in falsche
Hände, können sie nicht ausgelesen werden.
Encryption­Möglichkeiten auf Tape gab es bisher in unter­
schiedlichen Ausprägungen. Mit speziell entwickelter
Encryption­Software auf einem Server, mit speziell entwickelten
Encryption­Anwendungen oder externen Verschlüsselungsgeräten
konnte auf Tape verschlüsselt aufgezeichnet
werden. Das Bandlaufwerk selbst hatte mit der eigentlichen
Encryption nichts zu tun. Solche Lösungen konnten bisher
immer nur in Teilbereichen zur Anwendung kommen. Eine
Implementierung auf unternehmensweiter Basis, unabhängig
von den unterschiedlichen Betriebssystem­Plattformen
und auch über Unternehmensgrenzen hinaus, war bisher
nicht sinnvoll gestaltbar. Hinzu kommen noch die vielen Verschlüsselungsarten
wie z.B. Mars, RC5, Serpent, Twofish,
DES oder AES, um nur einige zu nennen, die das Ganze
entsprechend komplex gestalten. Um Verschlüsselungen
vorzunehmen, wird zum einen ein Verschlüsselungsalgorithmus
benötigt und zum anderen ein sogenannter Datenschlüssel
(Data Key), der die verschlüsselten Daten vor
unautorisiertem Zugriff absichert. Nur über den Datenschlüssel
können die verschlüsselten Daten wieder entschlüsselt
werden. Zum besseren Verständnis werden im
Folgenden die verschiedenen Verschlüsselungsmethoden
beschrieben.
Symmetrische Verschlüsselung: Um das Ausspionieren
von versendeten Daten durch eine dritte Partei zu verhindern,
werden im Allgemeinen kryptografische Verfahren
angewendet. Bei der symmetrischen Verschlüsselung werden
die Daten mittels eines geheimen Schlüssels ver­ bzw.
entschlüsselt. Der Schlüssel muss dabei sowohl dem Sender
als auch dem Empfänger bekannt sein und zu diesem
Zweck vorher persönlich ausgetauscht werden.
Beispiele für bekannte symmetrische Verschlüsselungsalgorithmen
sind der Data Encryption Standard (DES), der von IBM
Anfang der 70er­Jahre entwickelt wurde und mit einer
Schlüssellänge von 56 Bit arbeitet, sowie der International
Data Encryption Algorithm (IDEA), der von den Schweizern
Lai und Massey entwickelt und 1990 veröffentlicht wurde
und mit einer Schlüssellänge von 128 Bit deutlich sicherer
ist als der DES. Der generelle Nachteil dieses Algorithmus ist
der direkte Austausch der geheimen Schlüssel, was seine
Anwendung in einer Kunde­Händler­Beziehung erschwert.
Der Vorteil besteht in der relativ geringen benötigten
Rechen leistung.
Asymmetrische Verschlüsselung: Ein weiteres Verschlüsselungsverfahren
ist die sogenannte asymmetrische Verschlüsselung.
Sie basiert auf der Verwendung eines zusammengehörenden
Schlüsselpaares, wobei ein Schlüssel zur
Ver­ und einer zur Entschlüsselung genutzt wird. Beim
Public­Key­Verfahren wird nun einer der Schlüssel veröffentlicht
und kann von jedem Sender dazu genutzt werden, eine
Nachricht an den Empfänger zu verschlüsseln. Nur der
Empfänger, der im Besitz des zweiten, privaten Schlüssels
ist, kann die Nachricht dann entschlüsseln.
Ein Vertreter der asymmetrischen Verschlüsselungs­Algorithmen
ist der RSA­Algorithmus (RSA Data Security Inc.),
benannt nach seinen Entwicklern Ron Rivest, Adi Shamir,
Leonard Adleman, der in den USA 1977 entwickelt und
patentiert wurde und für den Export in jedoch nur begrenzter
Verschlüsselungstiefe (40 Bit) zur Verfügung steht.
Die asymmetrische Verschlüsselung kann auch genutzt wer­
den, um das Problem der Authentifizierung zu lösen. Zu diesem
Zweck werden die öffentlichen Schlüssel von Sender
und Empfänger gegenseitig bekannt gemacht. Der Sender
verschlüsselt die Nachricht zunächst mit seinem eigenen,
privaten und dann mit dem öffentlichen Schlüssel des Empfängers.
Nach Erhalt der Nachricht entschlüsselt der Empfänger
die Nachricht zunächst mit seinem privaten und
dann mit dem öffentlichen Schlüssel des Senders. Dieser
letzte Schritt ist jedoch nur dann erfolgreich, wenn die
Nachricht wirklich von dem bezeichneten Sender kam, da
andernfalls der verwendete öffentliche Schlüssel nicht passend
ist.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Hybride Verfahren: Der Nachteil der asymmetrischen Ver­
schlüsselung ist der hohe Rechenaufwand. Deswegen wird
oftmals eine Kombination aus symmetrischer und asymmetrischer
Verschlüsselung genutzt. Dabei wird eine Nachricht
durch den Sender zunächst mit einem speziellen geheimen
Schlüssel (Session Key) symmetrisch verschlüsselt.
Anschließend wird dieser Schlüssel mit dem öffentlichen
Schlüssel des Empfängers asymmetrisch verschlüsselt und
übertragen. Der Empfänger kann nun asymmetrisch mit seinem
privaten Schlüssel den Session Key und somit die
eigentliche Nachricht symmetrisch entschlüsseln. Da die
asymmetrische Verschlüsselung nur für die Verschlüsselung
des symmetrischen Schlüssels verwendet wird, bleibt der
Rechenaufwand bei der asymmetrischen Verschlüsselung
relativ gering.
IBM ist die erste Firma, die für Bandlaufwerke eine direkte
Verschlüsselungstechnik anbietet. Um mit den TS1120 Laufwerken
mit der Option Encryption arbeiten zu können, muss
auf installierten TS1120 Laufwerken ein Hardware­Upgrade
und ein Mikrocode­Update durchgeführt werden. TS1120
Laufwerke, die seit September 2006 ausgeliefert werden,
sind standardmäßig mit der Encryptionfähigkeit ausgestattet.
IBM entschied sich für die AES­Verschlüsselung (Advanced
Encryption Standard), die mit 128, 192 und 256 Bit
Schlüssellänge zur Verfügung steht und den Rijndael­Algorithmus
als symmetrisches Kryptografieverfahren verwendet.
AES ist der Nachfolger von DES (Data Encryption Standard
mit 56 Bit Schlüssellänge). AES ist anerkannt von der US­
Behörde NIST (National Institute of Standards and Technology)
und vom US­Handelsministerium und soll anerkanntermaßen
nicht ‘knackbar’ für die kommenden Jahre sein. Das
Bandlaufwerk TS1120 arbeitet mit dem sicheren AES­256­
Bit­Verschlüsselungsalgorithmus. Damit ist zum ersten Mal
die Möglichkeit gegeben, dass das Laufwerk selbst die Verschlüsselung
durchführt.
Die Verschlüsselungsmethode ist die eine Seite. Genauso
wichtig sind die Datenschlüssel, die vor unautorisiertem
Zugriff schützen und über die sich die verschlüsselten
Daten wieder entschlüsseln lassen. Im Mainframe­Umfeld,
wo schon seit Jahren Encryption mit entsprechenden
Krypto­Prozessoren eingesetzt wird, bildet das Herzstück für
die Datenschlüsselverwaltung ein EKM Encryption Key
Manager im z/OS­Betriebssystem. Der im z/OS eingesetzte
EKM bietet eine absolut nicht manipulierbare und hundertprozentig
sichere zentrale Datenschlüsselverwaltung. Dieser
EKM wurde nun auf die JAVA­Plattform portiert und steht so
für alle Betriebssystemplattformen zur Verfügung. Der neue
EKM liefert die Keys zum TS1120 Laufwerk, kann auf unterschiedlichsten
Systemplattformen laufen und unterstützt
dabei zentralisiertes Encryption Key Management, das
unternehmensweit einsetzbar ist.
Der EKM steht für die Betriebssysteme z/OS 1.6 oder 1.7,
AIX 5.2 oder später, I5/OS 5.2 oder später, HP­UX 11.0, 11i,
und 11.23Pl, Sun Solaris 8, 9 und 10, Linux – System z,
System p und Intel, Red Hat Enterprise Linux 4 (REHL 4),
SuSE Linux Enterprise Server 9 (SLES 9), Windows 2000
und Windows 2003 zur Verfügung.
Muss nun ein TS1120 Bandlaufwerk mit Encryption aufzeichnen,
fordert das Laufwerk den Datenschlüssel vom
EKM Encryption Key Manager an. Der EKM prüft dann, ob
das Laufwerk zugelassen ist und im ‘Drive Table’ des EKM
bekannt ist. Falls nicht, muss das Laufwerk über die Konfigurationsfile
im Drive Table des EKM aufgenommen werden.
Dann erstellt der EKM den angeforderten Datenschlüssel,
der im Folgenden als ‘Data Key’ bezeichnet wird.
Da die Datenschlüssel aus Sicherheitsgründen nicht unver­
schlüsselt über ein Netzwerk zum Bandlaufwerk übertragen
werden können, arbeitet der EKM intern mit zwei verschiedenen
Verschlüsselungsmethoden für den Datenschlüssel.
Der eine Algorithmus ist der KEK Key Encryption Key, der
ausschließlich im EKM läuft und mit dem nur der EKM etwas
anzufangen weiß. Der andere Algorithmus ist der SK Session
Key, der sowohl im EKM als auch im Bandlaufwerk zur
Anwendung kommt. Ist zwischen EKM und Bandlaufwerk
eine Session aufgebaut und wird der Data Key mit dem
Session Key SK verschlüsselt und zum Bandlaufwerk übertragen,
entschlüsselt das Bandlaufwerk wieder den originalen
Data Key, um dann mit der AES­256­Bit­Verschlüsselung die
Daten aufzuzeichnen. Bei jeder neu aufgebauten Session
zwischen EKM und Bandlaufwerk kommt immer ein neuer
SK Session Key zum Einsatz. Der mit dem SK verschlüsselte
Data Key wird als SEDK (Session Encryption Data Key)
bezeichnet. Neben dem SEDK überträgt der EKM aber auch
den über den KEK (Key Encryption Key) verschlüsselten Data
Key zum Laufwerk, der als EEDK (Externally Encryption
Data Key) bezeichnet wird und mit dem das Laufwerk
absolut nichts anfangen kann, weil ausschließlich der EKM
den KEK kennt und anwenden kann. Das Laufwerk hat
also keine Möglichkeit, den übertragenen EEDK zu
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
153

154
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
entschlüsseln, um an den eigentlichen Data Key zu gelangen.
Das Laufwerk kann den Data Key ausschließlich über
den übertragenen SEDK entschlüsseln. Hat das Laufwerk
nun die verschlüsselte Aufzeichnung abgeschlossen, wird
am Bandende in die Tape Volume Control Region der EEDK
hinterlegt, mit dem das Bandlaufwerk nichts anzufangen
weiß. Zusätzlich wird der EEDK auch im Memory Chip der
Kassette gespeichert. Sollte nun unautorisiert diese Kassette
auf einem Encryption­fähigen TS1120 Laufwerk ausgelesen
werden, ist dies nicht möglich, weil das Laufwerk mit
dem mitaufgezeichneten EEDK nichts anfangen kann. Ein
nicht autorisiertes Auslesen ist nicht möglich.
Zum Auslesen fordert das Laufwerk vom EKM wieder den
Data Key an und überträgt den aufgezeichneten EEDK zum
EKM. Der EKM sucht den zum EEDK zugehörigen KEK Key
Encryption Key und entschlüsselt den EEDK. Der orginale
Data Key steht also wieder zur Verfügung. Der Data Key
wird nun wieder über einen neuen SK Session Key verschlüsselt
und zum Laufwerk übertragen. Das Laufwerk
erhält den neuen SEDK Session Encryption Data Key und
entschlüsselt den SEDK, um den orginalen Data Key zu
erhalten. Danach können die verschlüsselt aufgezeichneten
Daten auf der Kassette entschlüsselt und ausgelesen werden.
Es besteht also keine Möglichkeit, die verschlüsselten Daten
ohne den originalen Data Key auszulesen. Die Raffinesse
dieser Implementierung liegt in der Tatsache, dass das
Laufwerk eine symmetrische Encryption über einen Data
Key durchführt, während die darübergelegte Key­Verwaltung
asynchron implementiert ist. Dabei kann der auf dem
Tape verschlüsselt abgespeicherte Data Key (EEDK) nicht
von TS1120 Laufwerken, sondern ausschließlich vom EKM
(Encryption Key Manager) für die Wiederherstellung des originalen
Data Keys verwendet werden. Das Laufwerk muss
den abgespeicherten verschlüsselten Data Key zum EKM
übertragen. Der EKM stellt den originalen Data Key wieder
her und schickt ihn für das Laufwerk verständlich verschlüsselt
(Session Key) zurück. Das Laufwerk ist nun in der Lage,
den originalen Data Key herzustellen und damit die Daten
entschlüsselt auszulesen. Die Kombination von synchroner
und asynchroner Technik machen diese Verschlüsselung
absolut ‘wasserdicht’.
Werden Kassetten, die mit Verschlüsselung aufgezeichnet
wurden, in eine andere Lokation transportiert, z.B. zu einem
Geschäftspartner, müssen dort TS1120 Laufwerke mit
Encryptionfähigkeit und ein EKM installiert sein. Will die
Lokation nun die Daten auslesen, schickt ein TS1120 Laufwerk
den auf der Kassette gespeicherten EEDK zum örtlichen
EKM, der einen Private Key hat, um den auf der Kassette
abgespeicherten EEDK zu entschlüsseln.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Es können auf der 3592 Kassette bis zu zwei verschlüsselte
EEDKs mit zwei unterschiedlichen Private Keys abgespeichert
werden. Der erste Key gehört zum EKM, der den Schlüssel
erzeugt hat, und der zweite Key kann einem anderen EKM
gehören, der aufgrund des dort verfügbaren Private Keys
den zweiten EEDK in den orginalen Schlüssel umwandeln
kann. Mit zwei Keys auf der Kassette zu arbeiten ist dann
sinnvoll, wenn in verschlüsselter Form Datenträgeraustausch
zwischen zwei unterschiedlichen Lokationen durchgeführt
wird. Das Laufwerk schickt immer den ersten EEDK
zum EKM. Kann der EKM damit nichts anfangen, wird automatisch
der zweite EEDK zu dem vorhandenen EKM übertragen.
Mit der Ankündigung der LTO4­Laufwerke im April 2007
wurde für LTO4 auch Encryption angekündigt. LTO4­Lauf­
werke arbeiten wie TS1120 Laufwerke auch mit der AES
256­Bit­Verschlüsselungstechnik. Der Unterschied zu
TS1120 liegt darin, dass keine verschlüsselten Schlüssel
(EEDK) auf der LTO4­Kassette abgespeichert werden, sondern
nur der Key Identifier, also der Schlüsselanhänger. Die
Key­Verwaltung und Key­Abspeicherung erfolgt über den
EKM. Soll eine verschlüsselte Kassette ausgelesen werden,
überträgt das LTO4­Laufwerk den Identifier zum EKM, der
dann in der Lage ist, den richtigen Originalschlüssel dem
Identifier zuzuordnen.
Der EKM wurde im Mai 2007 mit dem EKM Release 2 so
erweitert, dass er sowohl das Key­Handling für TS1120,
TS1130 als auch für LTO4 durchführen kann. Damit können
beide Technologien mit demselben EKM gemanagt werden.
Das neue TS1130 Bandlaufwerk, das als Nachfolger der
TS1120 im September 2008 verfügbar wird, ist mit derselben
Verschlüsselungstechnik ausgestattet. Die Bandkassetten
bleiben gleich, d. h., das neue TS1130 Laufwerk verwendet
dieselben Kassetten. Das Abspeichern der Keys auf
den Kassetten ist identisch.
TKLM – Tivoli Key Lifecycle Manager
Im Frühjahr 2008 steht als neue Software zur Keyverwaltung
der TKLM (Tivoli Key Lifecycle Manager) zur Verfügung, der
denselben Funktionsumfang wie der EKM hat und darüber
hinaus auch das Key­Handling für Encryption auf Platte
(Disk) zur Verfügung stellt und eine einfach zu bedienende
Oberfläche besitzt. Der TKLM kann als offizielles IBM
Programmpaket bezogen werden.
IBM bietet drei Encryption­Implementierungs­Möglichkeiten
auf Tape an:
Die Anwendung selektiert die Daten, die mit Encryption auf
Band geschrieben werden müssen, und stellt die Keys
dem TSM zur Verfügung. Der TSM Tivoli Storage Manager
verwaltet dann als Backup-Server die Encryption-Key-
Datenbank.
Im Mainframe-Umfeld kann über System Utilities des
DFSMS im z/OS-Betriebssystem über neue Data-Class-
Parameter selektiert werden, was mit Encryption verarbeitet
werden soll. Ähnlich können Policies für Encryption
auch im ‘AIX Tape Device Driver’ eingerichtet werden. In
beiden Fällen verwaltet der neue Enterprise Key Manager
(EKM) die Encryption-Key-Datenbank.
Die dritte Option geht über die Library selbst. Sowohl die
3494 als auch die TS3500 Library etabliert entsprechende
Policy-Regeln, welche ‘VolSers’ oder welche logischen
Libraries mit Encryption verarbeitet werden sollen. Die
Verwaltung der Encryption-Key-Datenbank wird durch
den neuen Enterprise Key Manager (EKM) durchgeführt.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
•
•
•
Alle drei Optionen lassen sehr flexible, unternehmensweite
und über Unternehmensgrenzen hinausgehende Verschlüsselungslösungen
auf Tape mit einem zentralen Key Management
zu und sind einmalig in ihrer Lösungsform.
Encryption auf Tape sichert die auf Bandkassetten
geschriebenen Daten vor Missbrauch und bietet einen
neuen Sicherheitsstandard auf Tape, der die geschriebenen
Daten vor unautorisiertem Zugriff schützt.
155

156
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
Archivierung
Die Anforderungen an Archivierung haben sich in den letzten
Jahren verändert. Neben der klassischen Aufbewahrung
von Daten aufgrund von gesetzlichen oder firmeninternen
Vorschriften kommen weitere Anforderungsprofile wie
erhöhte Zugriffsgeschwindigkeit und eine automatische Auslagerung
von nicht mehr operational genutzten Daten auf
Archivsysteme dazu. Desweiteren sind heute Archivlösungen
gefragt, die ein hierarchisches Speichermanagement
be inhalten und damit die Möglichkeit bieten, archivierte Daten
automatisch nach ILM­Regulatorien (Information Lifecycle
Management) auf unterschiedlichen Speichersystemen zu
verwalten. Aufgrund der immmer größer werdenden Datenmengen
im Archivierungsbereich sind heute sehr leistungsfähige
und skalierbare Archivsysteme gefragt, die zudem
die Anforderungen nach Hochverfügbarkeit und Datensicherheit
gewährleisten müssen. Dies gilt sowohl für die
Archivierung der klassischen Dokumenten­ bzw. Content­
Management­Systeme als auch für Anwendungen auf
Filesystem­Basis. Moderne Archivlösungen müssen zudem
die Migrationsanforderung hinsichtlich der Daten als auch
des Systems selbst erfüllen, wenn neue Technologien zur
Verfügung stehen.
IBM Information Archive (IIA)
IBM kündigt im November 2009 das neue Archivierungssystem
‘IBM Information Archive’, kurz IIA, als Nachfolger
des bisherigen DR550­Systems an.
Mit dem neuen System werden die veränderten bzw. erweiterten
Anforderungen an Archivsysteme adressiert. IIA ist
eine universelle Lösung zur Archivierung von strukturierten
und unstrukturierten Daten, die sowohl die gesetzlichen Aufbewahrungsvorschriften
erfüllt, als auch generell der vorschriftsfreien
Datenhaltung im Langzeitbereich Rechnung
trägt. Das System zeichnet sich dadurch aus, dass es eine
hohe Flexibilität in der Datenspeicherung bietet, weil zu
archivierende Anwendungen durch unterschiedliche standardisierte
Zugriffsmethoden möglich werden. Die hohe
Leistungsfähigkeit und Skalierbarkeit sind besondere
Merkmale des Systems.
Architektur
Das System besteht aus bis zu drei Rechnerknoten (in der
IIA­Terminologie als ‘Collection’ bezeichnet), die intern mit
den Platten­Arrays durch ein FibreChannel­Netz miteinander
verbunden sind und sich gegenseitig durch das integrierte
GPFS (Generell Parallel File System) Backup geben und
damit eine hohe Verfügbarkeit gewährleisten. Per Knoten
können Anwendungen zum einen via NAS­Interface durch
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

die NFS­ oder HTTP­Schnittstellen oder über die klassische
Schnittstelle SSAM System Storage Archive Manager (TSM­
API) angebunden werden. Zu einem späteren Zeitpunkt
werden auch FTP und CIFS unterstützt werden. Die Knoten
hinsichtlich der zu adressierenden Schnittstellen zu den
Anwendungen sind frei wählbar. Dabei bieten beide Schnittstellen
die Möglichkeit, andere Infrastrukturen wie z. B. Tape
anzuschließen.
Die Möglichkeit, mehrere Archivierungsinstanzen gleichzeitig
innerhalb eines Systems zu betreiben, erhöht die Leistungsfähigkeit
des Gesamtsystems beträchtlich. Im Unterschied
zur DR550 ist die Datenbank des SSAM­Servers
DB2­basierend (durch die Integration von TSM 6.1). Damit
wird die Anzahl der zu speichernden Datenobjekte um den
Faktor 3 pro Collection erhöht. Der SSAM­Server sorgt für
die Datenmigration auf angeschlossenen externen Speichern.
Innerhalb einer Collection zur Fileanbindung (Knoten mit
NAS­Interface) werden Daten, die auf externen Storage wie
z. B. auf Tape ausgelagert werden sollen, durch den internen
TSM­Server mittels seiner HSM­Funktionalität migriert.
Das Management und die Administration des Systems wird
über eine einheitliche Bedieneroberfläche durchgeführt.
Technischer Aufbau
Die Rechnerknoten (GPFS­Knoten) bestehen aus einem IBM
System x Server mit zwei quad­core Prozessoren, 24 GB
Memory und einem Linux­Betriebssystem. Bis zu drei Knoten
können innerhalb eines Clusters konfiguriert werden. Für
das Management des Systems wird ein IBM System x mit
einem quad­core Prozessor und 4 GB Memory verwendet.
Die Platten­Arrays bestehen aus 1­TB­SATA­Platten und werden
mit RAID6 an dual­redundanten Active/Active­Plattensteuereinheiten
betrieben. Jede Steuereinheit ist mit 2 GB
Cache ausgestattet und bietet bis zu 2 x 4 Gbit FC­Ports für
die Serveranbindung und bis zu 2 x 4 Gbit FC­Ports für die
Remote­Spiegelung. Rechnerknoten und Plattensteuereinheiten
sind durch ein 8 Gbit FC­SAN auf Basis von 24­Port­
Switchen miteinander verbunden, wobei der Betrieb am
Anfang auf Basis von 4 Gb läuft. Jeder Plattenkontroller hat
Zugriff auf jeden GPFS­Knoten und umgekehrt. Die Maximalkonfiguration
besteht aus zwei Gehäuseeinheiten und
bildet eine Bruttokapazität von 304 TB ab. Davon sind 209 TB
nutzbar. Im ersten Rack beträgt die Plattenkapazität bis zu
112 TB brutto (77 TB nutzbar). Im zweiten Rack können bis
zu 2 x 96 TB brutto (2 x 66 TB nutzbar) dazukonfiguriert
werden. Der Anschluss von Tape­Laufwerken und Tape
Libraries ist voll unterstützt.
Die neue Architektur des IBM Information Archive bietet
zukünftig skalierbare Erweiterungsmöglichkeiten, indem das
System mit zusätzlichen Rechner­Knoten und zusätzlicher
Plattenkapazität erweitert werden kann.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
157

158
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
SAN und IP-Networking
Brocade hatte im Januar 2007 McData übernommen und
eine Roadmap für die nächsten 18 – 24 Monate angekündigt.
Die Architektur der übernommenen McData SAN Direktoren
IBM 2027­140/256 sowie die Architektur des Brocade 2109­
M48 SAN Direktors wird in einer gemeinsamen neuen Architektur
in einem neuen Produkt, dem ‘Converged’ SAN Direktor,
mit 8 Gbps abgebildet. Die Ankündigung des IBM
SAN768B erfolgte im Februar 2008. Dabei können dann die
2027­140/256 native an den neuen 8­Gbps­Direktor angeschlossen
und weiterverwendet werden.
Der IBM Direktor SAN768B wird von Brocade (Brocade DCX)
gebaut und stellt eine Plattform bereit, die sich durch hochleistungsfähige
IT­ und zukünftige FCoE­Technologien
(FibreChannel over Ethernet) kommenden IT­Entwicklungsstufen
anpasst. Es ist das erste ‘Direktor­artige’ Produkt, das
über FibreChannel­Verbindungen Transferraten von 8 Gigabit
pro Sekunde (Gbps) unterstützt, was die Geschwindigkeit
beim Datentransfer in Zukunft nahezu verdoppeln kann.
Der Direktor bietet die Unterstützung von FibreChannel,
Fibre Channel over Ethernet (FCoE), Data Center Ethernet
(DCE), Gigabit Ethernet und das iSCSI­Protokoll.
Der SAN768B ist das erste Produkt der Branche, das wirkliche
Interoperabilität zwischen Direktoren des b­Typs (Brocade)
und solchen des m­Typs (McDATA) in einer 8­ oder
10­Gbps­FC­SAN­Infrastruktur unterstützt. Für Nutzer des
m­Typs und Großkunden, die ihre Mainframes über FICON­
Kanäle betreiben, bietet diese Interoperabilität eine Roadmap
für die Erweiterung der bestehenden FICON­Struktur.
Die neue Plattform reduziert Komplexität, Ausfallrisiko und
Energieverbrauch mit einer speziellen Skalierbarkeit von bis
zu 768 FibreChannel­Ports (externe User Ports) auf Basis
von 8 Gbps über zwei Domänen.
In einer großen Konfiguration mit zwei Domänen (Bild oben,
Abbildung rechts) bietet der Direktor bis zu 896 Ports.
Davon werden 768 Ports als ‘User Ports für externen
Anschluss’ verwendet. Die restlichen 128 Ports werden über
sogenannte ICL Inter Chassis Links an die Backplane der
beiden Direktoren geführt und als ICL­Ports bezeichnet. Die
Übertragungsbandbreite zwischen den beiden Domänen
(SAN868B Chassis) kann auf bis zu 1 Tbit/s gesteigert werden.
IBM Direktor SAN768B (Brocade DCX) mit bis zu 896 Ports
Die adaptiven Networking Services Features im SAN768B
(Brocade DCX) erlauben in der Fabric eine dynamische
Zuweisung verteilter Ressourcen in dem Moment, in dem
die Anforderungen der virtuellen Server oder des vernetzten
Speichers auftreten. Sollten Engpässe auftreten (oder vorhersehbar
sein), können die Bandbreiten in der Fabric automatisch
und entsprechend der vordefinierten Service Levels
angepasst werden. Dies hilft dabei, Operationen mit einer
höheren Priorität automatisch die benötigten Ressourcen zur
Verfügung zu stellen.
Das Jahr 2008 ist das Jahr der Einführung von 8­Gbps­
Technologie in Storage Area Networks, die es erlauben
8-Gbps-End-to-End-Lösungen zu implementieren. Im Jahr
2009 zeigen sich neue Möglichkeiten auf, SAN­Infrastrukturen
über IP­Netze miteinander zu verbinden, und das Zauberwort
heißt FcoE, FibreChannel over Ethernet.
FCoE – FibreChannel over Ethernet
Neben FibreChannel und iSCSI kommt mit FCoE ein neuer
Standard auf den Markt mit dem Ziel, den Datenverkehr im
Unternehmensnetz zu vereinheitlichen und FibreChannel
SAN­Infrastrukturen via Ethernet miteinander zu verbinden.
LAN nutzt Ethernet und das TCP/IP­Protokoll für den Datentransfer.
SANs, kommunizieren über FibreChannel. Dabei
nutzen Server für die verschiedene Netzwerk­Typen
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

getrennte Interface­Module, die Network Interface Cards
(NICs) für Ethernet und FC, ebenso separate Switch­Infrastrukturen.
FCoE überträgt die Daten in einem FC­SAN über
das lokale produktive Netz via Ethernet. Damit können
bestehende SAN­Systeme weiterhin genutzt werden und per
Ethernet in andere Systeme eingebunden werden, was langfristig
die Betriebskosten durch eine konsolidierte Anbindung
senken wird. Statt zwei parallele Netze zu pflegen, soll
der gesamte Datenverkehr über ein Netz abgewickelt und
administriert werden können. Dabei unterstützt FCoE ein
konsistentes Verwaltungsmodell, das in FibreChannel­SANs
gebräuchlich ist. Diese neue konvergierte Technologie
ermöglicht es, sowohl FibreChannel­Daten wie auch IP­
Daten über denselben Transportmechanismus zu übertragen.
Damit man nun FibreChannel­Pakete über ein Ethernet­
Transport­Protokoll verschicken kann, haben sich verschiedene
Hersteller von Speicherlösungen und Netzwerkkomponenten
zusammengesetzt und einen Vorschlag zum
FCoE­Standard entwickelt. FCoE legt fest, wie man FC­
Daten verlustfrei über IP transportieren kann. Dieses ‘verlustfreie
Ethernet’ besteht aus zwei Protokollen: Einmal das
Protokoll zum Transport der Daten, FCoE genannt, und zweitens
das Protokoll zur Kontrolle der FCoE­Verbindungen, FIP
(FCoE Initialisation Protocol) genannt. FIP kümmert sich um
das Login und Logout von Geräten in einem FCoE­Netzwerk.
FCoE verpackt den FC­Frame in einen Ethernet­Header
und versendet diesen über Ethernet, wobei nun aber
kein ‘traditionelles Ethernet’ zum Einsatz kommt, sondern
eine verbesserte Version, die als CEE (Converged Enhanced
Ethernet) bzw. DCE (Date Center Ethernet) bezeichnet wird.
Was wird mit iSCSI? iSCSI verschickt SCSI­Befehle über
Ethernet und TCP/IP und benötigt keine teuren FC­Netze.
Klassisches FibreChannel verliert gegen iSCSI vor allem bei
den Kosten. iSCSI nutzt die bestehende Infrastruktur, während
die IT für ein FC­SAN komplett neue Komponenten
benötigt. Nun kommt FCoE als neue Technologie und verfügt
über alle Eigenschaften, die iSCSI hat, auch bezüglich
der Kosten. Es stellt sich damit die Frage, wie es mit iSCSI
weitergehen wird, wenn sich FCoE als Technologie durchsetzt.
Brocade hat im Juli 2009 Foundry Networks aquiriert und ist
damit eine ziemlich gute Verbindung eingegangen. Brocade
baut Hardware und Software für die Speicherlandschaft,
Foundry ist im klassischen Unternehmensnetz unterwegs.
Brocade kann sich künftig also in der FC­ und in der Ethernet­Welt
ausbreiten und damit die Konvergenz erfüllen, die
mit FCoE angestrebt wird.
Cisco hat im April 2009 Nuova aquiriert, eine Firma, die
sich schon länger mit FCoE beschäftigt.
Hinter FCoE stehen nun die Firmen Brocade, Cisco, Nuova,
EMC, Emulex, IBM, Intel, QLogic und Sun. Die Spezifikation
für ‘FibreChannel over Ethernet’ sind dem T11-Komitee des
US­amerikanischen National Standards Institute (ANSI) vorgelegt,
um einen gemeinsamen Standard zu etablieren. Seit
Juni 2009 ist der FCoE­Standard verabschiedet. Bis FCoE
professionell im IT­Umfeld eingesetzt werden kann, wird es
noch etwas dauern! Bis Mitte bzw. Ende 2010 ist mit der
Fertigstellung aller notwendigen Protokoll­Standards zu
rechnen.
SAN & Converged Networking
Nach der Ankündigung des IBM SAN768B im Feburar 2008
war die Integration der Technologie von McData, die Brocade
im Januar 2007 übernommen hatte, in einem neuen 8 Gbit/s
Direktor­Produkt komplett. Seither ist viel In der Zusammenarbeit
von Brocade und IBM im Bereich Storage Networking
hinzugekommen: Nach der Erweiterung der Lösungspalette
mit 8 Gbit/s HBAs von Brocade steht erstmals eine durchgängige
Server­zu­Storage­Konnektivität von einem Hersteller
zur Verfügung – mit großen Vorteilen beim durchgängigen
Management der Umgebung. Im Bereich der Netzwerk­Konvergenz
bietet IBM nun mit dem IBM ® Converged Switch
B32 eine Top­of­Rack­Lösung für Benutzer, die FibreChannel
over Ethernet (FCoE) einsetzen und Erfahrungen mit der
neuen Technologie sammeln möchten. Schließlich steht mit
dem SAN384B eine weitere Core­ und Edge­Switching­Plattfom
für mittlere bis große SAN­Umgebungen zur Verfügung,
mit der weitere Design­Optionen im Backbone­Bereich möglich
sind.
‘End-to-End’-Unterstützung
Die 8 Gbps FibreChannel Host Bus Adapter ermöglichen
es, ein hohes Maß an Robustheit und Zuverlässigkeit für die
IBM System x Produktfamilie aufzubauen. Auf Basis der
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
159

160
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
hohen Leistungsfähigkeit der Brocade DCX Backbone Produktfamilie
integrieren die 8 Gbit/s HBAs industrieweit erstmals
wichtige Adapterfunktionen wie beispielsweise virtuelle
Kanäle (Virtual Channels).
Mittels der ‘Adaptive Network Services’ bieten die HBAs
einen echten Quality of Service (QoS) im SAN von virtuellen
Servern bis hin zum Storage Array und unterstützen Funktionen
zur Datenautentifizierung, die eine schnellere und
sicherere Kommunikation zwischen virtuellen Servern und
dem Speicher erlaubt.
Die 8 Gbit/s HBAs wurden dafür ausgelegt, die I/O­Leistung
am Server auf 500.000 Input/Output­Operationen pro
Sekunde (IOPS) pro Port zu steigern. Damit leisten die 8 Gbit/s
HBAs den doppelten Durchsatz im Vergleich zu vergleichbaren
Produkten. Durch die enge Integration lassen sich die
HBAs äußerst einfach installieren und in bestehende SAN­
Umgebungen einbinden.
Erweiterte Fabric Backbone-Optionen mit dem SAN384B
(Brocade DCX-4S)
Der IBM SAN384B ist eine Einstiegsversion des bereits verfügbaren
IBM SAN768B Backbone (Brocade DCX). Die
neue Switching­Plattform, die sowohl im Core als auch im
Edge eingesetzt werden kann, ist für die Konsolidierung von
Servern, Storage Area Networks (SAN) und Rechenzentren
ausgelegt. Da die komplette DCX­Funktionalität zur Verfügung
steht, können mit dem SAN384B die Kosten für die
Infrastruktur und die Administration gesenkt werden.
Der IBM SAN384B skaliert in vier Blade­Einschüben auf bis
zu insgesamt 198 Ports mit vollen 8 Gbit/s und ist damit für
Betreiber von mittleren Netzwerken geeignet. Betreiber von
großen Speichernetzwerken können den IBM SAN384B
auch als Netzwerk­Edge einsetzen. Der IBM SAN384B ist
mit der neuesten Brocade Fabric OS (FOS) Version 6.2 ausgestattet,
die eine neue Virtual­Fabric­Möglichkeit bietet, mit
der die logische Partitionierung eines physischen SAN in
logische Fabrics ermöglicht wird.
Der IBM SAN384B unterstützt optional die Verschlüsselung
von Daten auf Festplatten und Bandlaufwerken (Data at
Rest) in Verbindung mit unterschiedlichen Key­Managementsystemen.
Die Konvergenz im Netzwerkbereich
gewährleistet der IBM SAN384B mit seiner Multiprotokoll­
Architektur durch die Unterstützung neu aufkommender
Standards wie Converged Enhanced Ethernet (CEE) und
FibreChannel over Ethernet (FCoE). Diese Protokolle werden
durch einfache Ergänzung mit entsprechenden Blades zu
einem vom Benutzer gewünschten Zeitpunkt ermöglicht.
Die adaptiven Networking Services Features erlauben – wie
auch im im SAN768B – in der Fabric eine dynamische
Zuweisung verteilter Ressourcen in dem Moment, in dem
die Anforderungen der virtuellen Server oder des vernetzten
Speichers auftreten. Sollten Engpässe entstehen (oder
vorhersehbar sein), können die Bandbreiten in der Fabric
automatisch und entsprechend den vordefinierten Service
Levels angepasst werden. Dies hilft dabei, Operationen mit
einer höheren Priorität automatisch die benötigten Ressourcen
zur Verfügung zu stellen.
FibreChannel over Ethernet (FCoE) Produkte
Auch wenn die Entwicklung noch nicht abgeschlossen ist –
die ersten Standards für FibreChannel over Ethernet (FCoE)
sind da. Mit dem IBM Converged Switch B32 sowie den
dazugehörigen 10 Gb Converged Network Adaptern (CNA
für IBM System x) steht eine Lösung zur Verfügung, die den
Einsatz dieser neuen Technologie bereits erlauben. FCoE
müsste eigentlich FCoCEE heißen, da für den verlustfreien
Transport mit Converged Enhanced Ethernet (CEE) ein
neues Ethernet­Protokoll entwickelt wurde.
Der IBM Converged Switch B32 ist ein multiprotokollfähiger,
Layer 2, Top­of­the­Rack FCoE Switch mit 24 mal 10 Gigabit
Ethernet (GbE) CEE Ports sowie acht FC Ports mit 8 Gbit/s.
Er ermöglicht den konsolidierten Input/Output (I/O) von
Speicher­ und Netzwerk­Ports auf der Server­Seite. Die
neuen Converged Netzwerkadapter (CNAs) bieten eine
Leis tung von bis zu 500.000 I/Os pro Sekunde (IOPS) und
stehen in zwei Varianten zur Verfügung: dem Single Port
Brocade CNA 1010 und dem Dual Port Brocade CNA 1020.
Die neuen Brocade­Adapter gehören zu den ersten CNAs
mit Single­ASIC, die klassisches Ethernet auf Basis des TCP/
IP Protokolls, Converged Enhanced Ethernet sowie Speichernetzwerk­Funktionalität
über einen einzigen 10 Gb/s FCoE­
Link von den Servern über das SAN bis hin zum LAN bieten.
In Kombination ermöglichen der IBM Converged Switch B32
und die 1010/1020 CNAs eine durchgängige FCoE­Konnektivität
vom Server bis hin zum Speicher. Die Lösungen können
in existierende FC­Umgebungen integriert werden und
lassen sich mit einer übergreifenden Management­Plattform,
dem Data Center Fabric Manager (DCFM), administrieren.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Green IT
Das Thema Energieeffizienz rückt immer mehr in den Mittelpunkt.
Manche Rechenzentren können schon heute keine
Server oder Speichereinheiten mehr aufnehmen, weil es klimatechnisch
unmöglich ist.
Laut einer IDC­Umfrage von 2007 sind Themen rund um
Energieverbrauch und Energieversorgung von zunehmender
Bedeutung. Steigende Strompreise belasten die verfügbaren
Budgets. In vielen Rechenzentren wird das Thema Energieeffizienz
inzwischen zum Top­Thema. ‘Stromlose’ Datenträger
wie Bandkassetten oder optische Platten werden in den
nächsten Jahren eine Renaissance erleben. Nach einer Gartner­Studie
aus dem Jahr 2006 und 2008 werden mehr als
70 % aller Daten auf Band abgespeichert. Wenn alle Daten,
die heute im produktiven Einsatz auf Bandkassetten abgespeichert
sind, auf Plattensysteme (Disk) verlagert würden,
müssten ca. 40 neue Kernkraftwerke für die Stromversorgung
gebaut werden. Das Internet und die steigende Nutzung
des Internets erhöhen die Energieproblematik zudem
immens: Vier Internet­Suchanfragen benötigen so viel Strom
wie eine 40­Watt­Glühbirne mit einer Stunde Brenndauer.
Im Mai 2007 kündigte IBM das Projekt ‘Big Green’ an. IBM
investiert seit dieser Ankündigung 1 Milliarde Dollar pro
Jahr in das Projekt zur Verbesserung der ‘green’ Technologien
und Services und arbeitet an einer Roadmap, um die
eingetretene IT­Energie­Krise für Rechenzentren zu bewältigen.
Dazu hat IBM ein Team aus mehr als 850 Energie­Spezialisten
aufgebaut. Der Mehrwert für IT­Betriebe ergibt sich
oft aus der Tatsache, dass Energiekosten für ein typisches
Rechenzentrum halbiert werden können. Das entspricht im
Vergleich einer Emmissionsreduzierung, die ca. 1.300 Autos
erzeugen. IBM bietet dazu neben der Hardware und Software
eine Vielzahl entsprechender Services für Rechenzentrumsbetriebe
an. Teil dieser Services beinhalten Energie­
Effizienz­Analysen und/oder ‘Energy­Self­Assessments’.
Die beispielhaften Aktivitäten der IBM im Rahmen des Projekts
‘Big Green’ und die damit verbundenen langfristigen Verpflichtungen
führten dazu, dass IBM im Februar 2008 als
die ‘Top Green IT Company’ des Jahres 2008 sowohl von
der IDG (International Data Group) als auch von der Computerworld
gewählt und ausgezeichnet wurde.
Virtualisierung allgemein
Virtualisierung in jeglicher Form wird für die Epoche der Server­basierenden
Speicherarchitekturen prägend sein. Neben
Tape­Virtualisierungen und Plattenvirtualisierungslösungen
im SAN wird sich die Virtualisierung auf weit mehr Bereiche
ausdehnen. Die IBM vertritt hier weltweit die Strategie ‘Virtualize
Everything’. Nur so wird es möglich werden, heterogene
Server­ und Speichereinheiten und unterschiedlichste
Infrastrukturen optimal zu nutzen und ein flexibles, nach
Regelwerken betriebenes Datenmanagement zu ermöglichen.
Nur durch Virtualisierung in allen Bereichen werden
Automationsprozesse in den heute unterschiedlichen Infrastrukturen
möglich werden. Server­basierende Speicherarchitekturen
erleichtern den Virtualisierungs­Gesamtansatz
erheblich.
Mit effektiven Virtualisierungslösungen erzielt man eine möglichst
maximale Nutzung der vorhandenen physikalischen
Ressource, d. h., vorhandene Speicherkapazitäten werden
wesentlich höher ausgenutzt. Somit liefert die Virtualisierung
einen maßgeblichen positiven Beitrag zur Bewältigung der
Energieproblematik im IT­Umfeld.
Neue Infrastrukturen und Bandbreiten
Die heutigen FibreChannel­Netze und IP­Infrastrukturen werden
in den nächsten Jahren mit Sicherheit weiterentwickelt
werden. Von heutigen 4­Gbit­SANs und 8­Gbit­SANs geht
es in Richtung 12-Gbit-SAN­Technologie weiter. IP­Netze
heute mit bis zu 2­Gbit­ und 10­Gbit­Ethernet könnten in den
nächsten Jahren durch 100-Gbit-Ethernet-Technologie
abgelöst werden. Der IP­Infrastruktur, speziell dem Ethernet,
wird in den nächsten Jahren noch eine besondere Bedeutung
zukommen. Es ist geplant, innerhalb der nächsten
fünf Jahre jedem Privathaushalt in Deutschland einen
100­Mbit­Ethernet­Anschluss zur Verfügung zu stellen.
Damit bekommen die Privathaushalte neue, riesige Übertragungsbandbreiten.
Ethernet­Infrastrukturen werden also zu
einem maßgeblichen Faktor auch im privaten Umfeld.
So wie die ersten SAN­Infrastrukturen zwei Jahre früher in
den Hochleistungsrechenzentren der Universitäten ihre Anwendung
fanden, bevor sie im kommerziellen Rechen zentrums
umfeld zum Einsatz kamen, entwickeln sich heute ähn­
liche Tendenzen für eine neue Übertragungstechnik, die als
InfiniBand bezeichnet wird. InfiniBand steht für ‘Infinite
Bandwidth’. InfiniBand ist ein neues Transport­Protokoll,
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
161

162
2006 bis 2010
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung
das Servereinheiten, Speichereinheiten und ganze Netzwerke
von Rechenzentren verbinden kann. Seit 1999 wird
der Standard von der InfiniBand Trade Association vorangetrieben,
nachdem damals Compaq, Dell, HP, IBM, Intel,
Microsoft und SUN angekündigt hatten, ihre zukünftigen I/O­
Entwicklungen der InfiniBand­Technologie anzupassen. Seit
Herbst 2005 ist der Standard verfügbar.
InfiniBand schafft die Möglichkeit, heutige LAN­, SAN­, NASund
IPC(Interprocessor Communication)­Infrastrukturen in
einem einzigen universellen Netzwerk zu vereinigen.
Ebenso könnten separate InfiniBand­Netze neben vorhandenen
SAN­ und IP­Infrastrukturen über iSCSI betrieben
werden.
Für das Transport­Protokoll können Kupferkabel (Entfer­
nungslimitierung bei 17 m) und Fibre­Optic­Kabel (bis 10 km)
verwendet werden. Die Fibre­Optic­Kabel für InfiniBand
werden im Vergleich zu heutigen FibreChannel­Verbindungen
anders hergestellt und sind lange nicht so empfindlich.
Ein Knick im Kabel verursacht fast keine Dämpfung
und damit keinen Verlust. Würde man das mit dem heutigen
FibreChannel machen, müssten die Kabel komplett ausgetauscht
werden. Durch diese Eigenschaft ist InfiniBand Fibre
Optic ideal geeignet, um für interne Verkabelungen von
Maschinen zur Anwendung zu kommen.
Für den externen Einsatz ist es wichtig, die Fibre­Optic­
Lösungen sowohl in der Unterstützung der seriellen Schnittstellen
als auch in den Entfernungsmöglichkeiten voranzutreiben.
4, 8 oder 12 ‘Physical Lanes’ können auf einen InfiniBand­
‘Physischen Link’ geschaltet werden, die Paketübertragung
ist ‘byte­multiplexed’ über die Physical Lanes.
InfiniBand repräsentiert ein extrem hohes skalierbares Link
Interface SLI. Es ist möglich, die Anzahl der Physical Lanes
dynamisch – abhängig von Durchsatzanforderungen und
Datenverkehr – zu verändern und dynamisch anzupassen.
InfiniBand bietet eine hoch skalierbare Verbindungstechnik
mit ‘nX’ Multiple Lane Pairs mit einer Datenübertragungsrate
von 2,5 Gbit/s (Single Data Rate SDR), 5 Gbit/s (Double
Data Rate DDR) oder 10 Gbit/s (Quad Data Rate QDR) in
jede Richtung. Die unten stehende Tabelle stellt die maximale
Bandbreite für jede der Möglichkeiten dar:
SDR DDR QDR
1X 2,5 Gb/s 5,0 Gb/s 10,0 Gb/s
4X 10,0 Gb/s 20,0 Gb/s 40,0 Gb/s
8X 20,0 Gb/s 40,0 Gb/s 80,0 Gb/s
12X 30,0 Gb/s 60,0 Gb/s 120,0 Gb/s
InfiniBand hat einen weiteren wesentlichen Vorteil. Die Infini­
Band­Upper­Level­Protokolle wie SDP, SRP und iSER benützen
die Methode des Remote Direct Memory Access
RDMA, um direkt Daten in anwendungszugeordnete Pufferbereiche
des Rechners zu schreiben und gleichzeitig auszulesen.
Dies reduziert den Overhead­Datentransfer zu einem Drittel
und setzt CPU­Kapazitäten frei, die anders genutzt werden
können.
Nachdem die ersten InfiniBand­Netze in einigen Hochleistungsrechenzentren
der Universitäten etabliert sind, kann
man – analog zum FibreChannel – davon ausgehen, dass
die ersten InfiniBand­Netze und ­Infrastrukturen innerhalb
der nächsten 2–3 Jahre in ‘kommerziellen’ Rechenzentren
implementiert werden. Beschleunigend kommt noch hinzu,
dass InfiniBand im Vergleich zum FibreChannel kostengünstiger
ist.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Neue Basis-Technologien
Die Fachwelt im Storagebereich ist sich darin einig, dass
Kunststoff das Speichermedium der Zukunft werden kann.
Mit organischen Polymeren und polykristallinem Chalkogenid
wird schon seit einigen Jahren experimentiert. Organische
Polymere sind geeignet, durch optische Technologien
für die Speicherung von Daten genutzt zu werden. Mit der
neuen blauen Laser-Technik lassen sich Interferenz­Felder
auf dem Kunstoff erzeugen, die eine Vielzahl von Bits abbilden.
Diese Technologie wird auch als holografische Speicherung
bezeichnet und erlaubt viel größere Kapazitäten als
mit herkömmlichen optischen Verfahren. Hierzu wird ein
blauer Laser als ‘Daten­Strahl’ eingesetzt. Ein Teil des
Lasers wird über Spiegelverfahren durch einen Lichtmodulator
geschickt, damit er eine andere Lichtbeugung bekommt.
Anschließend kommen beide Strahlen auf der Polymeroberfläche
wieder zusammen. Durch die unterschiedliche Lichtbeugung
wird ein Interferenzfeld im Polymer erzeugt, das
man heute als Hologramm bezeichnet (siehe Technologie­
Anhang unter HVD Holographic Versatile Disk, PCM Phase
Change Memories und Nano­Technologien).
Da heute noch niemand abschätzen kann, wie sich Kunststoffe
und veränderte Kunststoffe im Laufe ihrer Alterung
verhalten, arbeitet IBM an sinnvollen Alterungsverfahren für
Kunststoffe, um genauere Aussagen zu bekommen. Heute
geht man davon aus, dass ein veränderter Kunststoff einen
Lebenszyklus von ca. 100 Jahren haben müsste. Diese Aussage
muss aber noch durch entsprechende Alterungsverfahren
belegt und bestätigt werden.
Kommentar zur Epoche der Server-basierenden Speicherarchitekturen
mit neuen Infrastrukturmöglichkeiten
Server­basierende Speicherarchitekturen wie DS8000, SVC,
neue Archivierungslösungen, die neuen Tape­Virtualisierungseinheiten
ProtecTIER und TS7700, TS3500 Tape
Library Virtualisierung und File Virtualisierung über File Area
Networks bieten eine noch nie dagewesene Flexibilität und
Skalierung in Leistung, Kapazität und Funktionalität. Sie werden
die vor uns liegende Epoche maßgeblich bestimmen,
weil Konsolidierungen auf einer ganz neuen Basis möglich
werden. Diese neuen Architekturen schaffen die Möglichkeit,
viele Server über Cluster zusammenzuschließen. Damit
sind die ersten Anfänge von Grid Computing im kommerziellen
Umfeld gelegt.
Durch neue Bandbreiten der Datenübertragung und neue
Vernetzungstechniken ergeben sich neue Ansätze für eine
optimale Gestaltung der Rechenzentren und deren Infrastruktur.
Virtualisierungslösungen in den unterschiedlichsten RZ­
Bereichen werden zu einer wesentlichen Vereinfachung der
RZ­Abläufe führen und die Administration stark vereinfachen.
Durch Standards werden die IT­Anbieter gezwungen, näher
zusammenzurücken, und der Endbenutzer bekommt endlich
mehr Kompatibilität zwischen den unterschiedlichen Systemen,
wie es bisher nicht der Fall war. Virtualisierung trägt
hier einen ganz entscheidenden Anteil dazu bei.
Neue Speichertechnologien werden rechtzeitig auf den Markt
kommen, um den Anforderungen an ständig wachsende
Kapazitäten Rechnung zu tragen. Kunststoffe als Speichermedium
der Zukunft werden maßgeblich diese Epoche
prägen. Ebenso können stromunabhängige Flashspeicher in
Form von SSDs (Solid State Disks), Phasenwechselspeicher
und Storage Class Memories die heutigen teuren FC­Platten
verdrängen, wenn sie in den nächsten Jahren entsprechend
billiger produziert werden.
Das Tempo in der Entwicklung und in den Produktzyklen
wird sich noch weiter verstärken. Es wird immer schwieriger
werden, einen Gesamtüberblick über alle Möglichkeiten im
Storage­Umfeld zu behalten, die man aktiv nutzen kann, und
Beratung wird eine größere Bedeutung als bisher haben.
Hardware allein spielt dabei nur noch eine geringe Rolle.
Die Epoche wird sicherlich die innovativste werden und vielleicht
Dinge hervorbringen, an die wir heute noch gar nicht
zu denken wagen. Hätte man in den 90er­Jahren jemandem
erzählt, was heute alles verfügbar ist, wäre man sicher zum
Fantasten gestempelt worden.
Was wird in zehn Jahren sein? Es wird eine spannende
Epoche werden und der Autor fragt sich selbst, ob seine
Aussagen zutreffen werden.
Vielleicht liegt unsere Vorstellungskraft noch weit hinter den
Dingen, die vor uns liegen ...
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
163

164
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

IBM Storage Software
IBM Storage Software
Software
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 165

IBM Storage Software
Der System-verwaltete Speicher im Mainframe-Umfeld – Werner Bauer
Der System-verwaltete Speicher im Mainframe-Umfeld
Wie der Name impliziert, wird die externe Speicherumgebung
durch das System, genauer gesagt durch den
angeschlossenen Server und dessen Betriebssystem,
verwaltet. Verwaltet heißt in diesem Zusammenhang, dass
das Betriebssystem automatisch alle Aktivitäten im Zusammenhang
mit externem Speicher nach einem vordefinierten
Regelwerk – Policy­basierend – verwaltet. Andere oder
ähnliche Begriffe für den systemverwalteten Speicher –
System Managed Storage – sind Information Lifecycle
Management (ILM) oder Scale­out File Services (SoFS). Solche
Begriffe finden sich in IT­Landschaften, die vornehmlich
mit Unix­ und/oder Intel­basierenden Servern ausgestattet
sind. System Managed Storage oder kurz SMS wurde durch
die Ansätze im Mainframe­ und Host­Umfeld in den 80er­
Jahren des vergangenen Jahrhunderts massiv geprägt.
Dieser Ansatz wurde in den Anfängen bereits 1974 durch
das Mass Storage System IBM 3850 eingeführt, wo bereits
eine HSM­Funktionalität zur Verfügung gestellt wurde, um
Daten, die nicht oft benötigt wurden, auf einem billigen
Massenspeicher systemgesteuert abzuspeichern (siehe
auch unter IBM 3850).
SMS hatte zum Ziel, das rasante Speicherwachstum der
damaligen Zeit rasch zu adaptieren, ohne die Anzahl der
Speicheradministratoren analog mitwachsen zu lassen. SMS
verhält sich – fast – völlig elastisch zu dem wachsenden
externen Speichervolumen, skaliert ausgezeichnet und
verwaltet ein 400­GB­Disk­basierendes Speicherumfeld
in 1990 genauso gut wie heute eine 4.000.000 GB große
Disk­Konfiguration.
Speicherhierarchie
Neben dem Abgleich der logischen Anforderungen an eine
Datei mit der physisch vorhandenen Konfiguration wird von
einer automatischen Speichermanagement­Lösung erwartet,
dass die Dateien sinnvoll in der vorhandenen Speicherhierarchie
abgelegt und nach Anforderung bewegt werden.
Heutige Plattensysteme können mit SSDs (Solid State
Disks), FibreChannel­Platten und SATA­Platten bestückt werden
und dadurch systemintern eine Speicherhierarchie
abbilden. SSDs sind zwar noch sehr teuer, bieten dafür aber
extrem schnellen Zugriff und extrem schnelle Antwortzeiten.
166 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Die Speicherhierarchie wird bei den Magnetplatten durch
zwei gegenläufige Trends bestimmt: Je schneller der Speicherzugriff
und je besser und kürzer die Servicezeit ist,
desto teurer ist das gespeicherte GB. Anders ausgedrückt:
das gespeicherte GB wird preiswerter, wenn die Anforderungen
an Zugriffszeit und Schnelligkeit geringer werden.
Ein schnelles FibreChannel­Plattenlaufwerk dreht mit
15.000 Umdrehung pro Minute bzw. 250 Umdrehungen pro
Sekunde, d. h., eine Umdrehung dauert 4 ms. Die übliche
Kapazität einer FibreChannel­Disk liegt heute zwischen
300 GB und 650 GB mit einem Formfaktor von 3,5 Zoll
Durchmesser. Die Anzahl der möglichen Zugriffe ist durch
die hohe Umdrehungszahl wesentlich schneller im Vergleich
zu einer preiswerten, hochkapazitiven SATA­Platte mit 7.200
Umdrehungen pro Minute bzw. 120 Umdrehungen pro
Sekunde mit 8,3 ms pro Umdrehung. Das dauert mehr als
doppelt so lange im Vergleich zu einer FibreChannel­Platte.
Die Kapazitäten bei SATA­Platten liegen heute bei 1 TB
und 2 TB.
Eine übliche Größe, um die Leistungsfähigkeit einer Platte
einzuordnen, ist die Anzahl von Ein­/Ausgabe­Zugriffen
pro Sekunde und pro GB. Das macht deutlich, dass SATA
wesentlich schwächer als eine FibreChannel­Platte ist und
daher für hochaktive Dateien ungeeignet ist. Die Technologie
für 15.000 U/M ist auch anspruchsvoller – und damit teurer –
als die notwendige Technologie, um mit nur 7.200 Um ­
drehungen pro Minute zu rotieren.
Eine spezielle Rolle im Mainframe­Umfeld kommt vir tuellen
Tape­Konfigurationen zu. Um den Vorteil des direkten
Zugriffs der Platte für Backup und ausgelagerte Dateien
zugänglich zu machen, aber andererseits ökonomisch mit
dem genutzten Speicherplatz umzugehen, wird eine Technologie
genutzt, die vermeidet, dass gleiche Datenstrukturen
mehrfach gespeichert werden („Deduplication“). Dabei wird
auf reale Tape­Laufwerke gänzlich verzichtet und die
Backup­Dateien und die ausgelagerten Daten („migrated
data sets“) werden auf Disks abgespeichert. Ein solches
System simuliert Tape­Laufwerke gegenüber den angeschlossenen
z/OS­Servern.
Automatische Tape Libraries und Virtuelle Tape Server
nutzen aber – sinnvoll – weiterhin reale Bandlaufwerke und
Kassetten, auf denen letztlich die Dateien abgelegt werden,
nachdem die geschriebenen Tape­Daten durch einen
vorgeschalteten Plattenpuffer gegangen sind. Über einen
solchen Plattenpuffer können wieder virtuelle Tape­Laufwerke
emuliert werden, die viele Tape­Laufwerke pro virtuellem
Tape Server simulieren. Das eigentliche Backend besteht
nur aus wenigen realen Kassetten­Laufwerken, über die
hochkapazitive Kassetten beschrieben werden. Diese realen
Kassetten­Laufwerke sind in einem virtuellen Tape Server für
das z/OS­Betriebssystem nicht sichtbar.
Entstehung
Storage Management Software
DFSMS/MVS setzt heute den Standard der Storage Management
Software, ohne die das Speicherwachstum in den vergangenen
Jahren im Mainframe­Umfeld nicht administrierbar
gewesen wäre.
Die Anfänge von DFSMS/MVS gehen zurück bis in die
frühen 80er­Jahre des vergangenen Jahrhunderts. Damals
haben Kunden und entsprechende Benutzerorganisationen
einschließlich der IBM die Notwendigkeit für ein vollautomatisches
Speichermanagement erkannt:
Rapides Speicherwachstum
Die TCO für Speicher eskalierten bereits in den Jahren ab
Anfang 1980
„Storage keeps getting cheaper, but also harder
to manage“, Datamation, 15.12.1985
GUIDE/SHARE fordert IBM in den Jahren 1983–1985 auf,
ein „policy based storage management“ anzubieten und
definiert „requirements for futures of storage management“,
GUIDE 1983
„Without improvements in methods, or the emergence of
improved automated managers, the storage management
forces will have to grow exponentially as the data grows“,
GUIDE Paper, 15.11.1985
Internet, e-business, b-2-b interactions, life sciences, WEB
2.0, etc. tragen weiterhin zu einer verstärkten Explosion
der Nachfrage nach Speicherkapazität bei, die verwaltet
werden muss.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
•
•
•
•
•
•
167

IBM Storage Software
Der System-verwaltete Speicher im Mainframe-Umfeld – Werner Bauer
Automatisches Storage und Daten­Management wurde mit
DFSMS/MVS realisiert und wird in den folgenden Abschnitten
beschrieben.
Data Facility Storage Management Subsystem, DFSMS/MVS
IBM hat 1989 mit MVS/DPF 3.0 die 2. Stufe einer Strategie
realisiert, die unter dem internen Begriff „Jupiter Strategy“ in
den frühen 80er­Jahren entstanden ist. Diese 2. Stufe ist
das, was wir heute im Host­Umfeld als SMS verstehen.
Die Jupiter­Strategie war damals in drei Stufen geplant:
1. Jupiter Stage I ist das, was im DFSMS/MVS bzw. z/OS als
Interactive Storage Management Facility (ISMF) verstanden
wird. ISMF ist ein Panel-basierendes ”Frontend“ zu dem
externen Speicher und dem dazugehörigen Repository, in
dem der externe Speicher in einer speziellen, sehr effektiven
und effizienten Datenbank verzeichnet ist. ISMF war der
erste Schritt und wurde 1987 angekündigt und im Markt
eingeführt.
2. Jupiter Stage II wurde 1989 als MVS/DFP 3.0 angekündigt
und allgemein verfügbar. Neben dem Data Facility
Product (DFP) waren auch die Komponenten Data Set Services
(DSS), der Hierarchical Storage Manager (HSM) und
der Removable Media Manager (RMM)
integraler Bestandteil dieser Jupiter Stufe II. Das ist der
Stand von SMS, wie er heute im Mainframe-Umfeld
bekannt ist. Er trägt der Realisierung des Gedankens
Rechnung, den Speicher durch das Betriebssystem nach
einem vordefinierten Regelwerk automatisch zu verwalten.
Über die Jahre hinweg wurde diese Stufe verfeinert und
ergänzt und ist heute unter z/OS integraler Bestandteil
der Betriebssystemsoftware.
3. Jupiter Stage III war als letzte Stufe geplant. In dieser Stufe
sollte die völlige Trennung von logischen Daten und physikalischer
Speicherung umgesetzt werden. Dabei sollte der
externe Speicher auf eine Block-Level Architektur standardisiert
und die logischen Daten automatisch so plaziert
werden, wie es über Regeln und Service-Levels vorge geben
ist. Sollte eine Regel – oder der geforderter Service-
Level – nicht mehr eingehalten werden können, sorgt das
System selbst dafür, dass die betroffenen Blöcke automatisch
und für die Anwendung unbemerkt in der Speicher-
Hierachie so umverlagert werden, dass der geforderte
Service-Level wieder eingehalten werden kann.
Anfang der 90er­Jahre entschied IBM, diese 3. Stufe im
Rahmen der Jupiter­Strategie nicht mehr zu verwirklichen.
Man ging davon aus, dass eine entsprechende Investition
eher für Unix­basierende Server gemacht werden sollte.
168 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Funktionsweise
Dateien im z/OS
Bevor wir SMS und seine Komponenten genauer betrachten,
wollen wir das Prinzip der Datei im z/OS beschreiben bzw.
wie eine Datei angelegt und wiedergefunden wird.
Jede Datei – vergleichbar mit einer „File“ in Unix oder
Windows – bekommt im z/OS einen eindeutigen Namen
bzw. genauer einen Dateinamen, ein „Data Set Name“
(DSN) zugeordnet. Ein DSN kann bis zu 44 Character lang
sein und besteht aus einzelnen „Qualifiern“. Diese Qualifier
sind zwischen 1 und 8 Caracter lang und bestehen aus
alpha­numerischen Zeichen. In der Regel gibt es keine
Vorschriften, wie solch ein Name ausgeprägt sein muss.
Ein Beispiel: “SAP.PROD.KDNR1984.INDEX“ hat den 1.
Qualifier mit SAP, der auch als High Level Qualifier (HLQ)
bezeichnet wird, einen 2. Qualifier PROD, den 3. Qualifier
KDNR1984 und den sogenannten Last Level Qualifier (LLQ)
mit INDEX. Die Qualifier sind jeweils durch einen Punkt
getrennt.
Solch ein Name kann vom System genauso zerlegt und
geprüft werden. Beispielsweise kann eine Regel definiert
werden, die lautet . Unter &variable_llq ist bspw. INDEX, VER*,
GRUPPE1 als mögliche LLQ­Liste definiert, wobei dieser
LLQ auch mit den ersten 3 Zeichen VER in die Auswahl
fallen würde. Dabei wäre gleichgültig, wie die anderen
Qualifier ausgeprägt sind. Also eine Datei mit DSN=TEST.
D30M09.VERZ1 würde die Auswahl als gültig akzeptieren,
da in der LLQ­Liste auch VER* steht.
Mit entsprechenden UND­Verknüpfungen von weiteren
Regeln kann die Auswahl selektiver ausfallen wie etwa
mit SAP*,PROD als Liste in der Variablen
&variable_hlq. Dann fallen alle DSN mit SAP in den ersten
3 Stellen des HLQ und mit den LLQ, wie in der Variablen
&variable_llq definiert, in die Auswahl.
Eine Datei muss in einem SMS Environment immer katalogisiert
sein. Ein Katalog ist ein Verzeichnis, in dem jede
einzelne Datei mit Namen verzeichnet ist und wo diese
Datei zu finden ist. Das wird über ein Volume Label oder
die sog. Volume Serial Number, VOLSER, bewerkstelligt.
Die VOLSER ist ebenfalls eindeutig in einem SMS­System.
Mit Hunderttausenden oder Millionen von Dateien in einem
großen System wird man nicht nur einen einzigen Katalog
nutzen, sondern über den HLQ auf bestimmte Kataloge
Request for
existing data set
DSN + Label
Catalog
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
169

IBM Storage Software
Der System-verwaltete Speicher im Mainframe-Umfeld – Werner Bauer
zugehen. In unserem Beispiel sind alle Dateien, die SAP
als HLQ ausweisen, in dem Katalog U.SAP katalogisiert. Da
auch die Kataloge über einen DSN gefunden werden müssen,
gibt es eine übergeordnete Instanz, die ”Master Catalog“
genannt wird. Es gibt nur einen einzigen aktiven Master
Catalog in einem SMS­System. Dessen Inhalt wird Speicherresident
im z/OS vorgehalten, da er für jedes ”Data Set
Locate“ angezogen werden muss, um den zugehörigen
[user] Catalog anzuziehen. Das geschieht über den HLQ
und wird als ALIAS­Beziehung bezeichnet. Im Master Catalog
wird SAP als HLQ eingetragen und der Verweis auf den
user catalog U.SAP. Immer wenn ein DSN auftaucht, der
SAP als HLQ ausweist, wird in dem Katalog U.SAP diese
Datei definiert oder gesucht.
Da der Katalog nur auf ein Volume verweist, auf dem die
Datei abgelegt wird oder abgelegt ist, hat jedes Volume
ebenfalls eine feste Struktur, damit die Datei letztlich auf
dem Volume Level gefunden oder entsprechend eingetragen
werden kann. Das ”Volume Label“ steht immer auf der gleichen
Stelle eines jeden Volumes, Cylinder 1, Spur 1,
Record 1. Das Label hat u. a. auch einen Zeiger zum
Inhaltsverzeichnis des Volumes, die sog. Volume Table Of
Content oder VTOC. Die VTOC ist funktionell grob mit einem
File System in Unix oder Windows vergleichbar. In der
VTOC stehen alle DSNs, die ein Zuhause auf diesem
Volume haben, und die Anfangs­ und Endadresse dieser
Datei auf dem Volume.
Eine Datei oder DSN ist also ein eindeutiger Name innerhalb
einer SMS­Konfiguration und die zugehörige Datei muss
immer katalogisiert sein. Die Anforderung, eine neue Datei
anzulegen, geht durch das SMS – genauer gesagt durch
das DFSMS, Allocation und Catalog Management – und
sucht einen passenden Platz in der Speicherhierarchie,
abhängig von dem geforderten Service­Level, der für diese
neue Datei vorgegeben wird. Eine Anforderung für eine
bereits bestehende Datei geht nur durch die Allocation und
das Catalog Management, um die bestehende Datei zu
lokalisieren und der Anwendung zugänglich zu machen.
Übersicht über Policy-based Storage Management
Policy­basierendes Storage Management übernimmt die
Aufgaben des Speicher­Administrators, die zuvor manuell
ausgeführt wurden. DFSMS erlaubt die Trennung der
logischen Sicht der Daten von der physikalischen Speicherkonfiguration.
Logisch ist hier synonym mit Service Level
Agreements (SLA) gleichzusetzen und physikalisch bedeutet,
wo die Daten tatsächlich abgespeichert werden. Logische
Sicht heißt in der Terminologie von SMS: Data Class,
Storage Class und Management Class. Die Storage Group
spezifiziert letztlich den physikalischen Speicherplatz.
Über die Data Class werden Angaben über den Speicherbedarf
und die Daten-Attribute für eine Datei gemacht.
Die Storage Class enthält Angaben zur geforderten
Leistung und Antwortzeit und der Level der Verfügbarkeit
für die betroffenen Dateien. Das beinhaltet die Platzierung
auf einem physikalisch Volume mit schneller Zugriffszeit
oder dass eine Datei über das Attribute „sequential data
striping“ automatisch auf mehrere Volumes verteilt wird.
Die Management Class enthält Angaben über Anzahl und
Aufbewahrungsdauer der Sicherungen für eine Datei. Hier
wird auch definiert, wie lange die Datei selbst bestehen
bleibt, bevor sie automatisch gelöscht wird.
Die Storage Group definiert den potenziell physikalischen
Speicherplatz für die betroffene Datei. Eine Storage Group
ist eine Gruppe von Volumes in Disk-Storage-Subsystemen
oder eine Gruppe von Tape-Kassetten und Tape-Laufwerken.
Die betroffenen Volumes werden von DFSMS kollektiv
verwaltet.
170 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
•
•
•
•
Entscheidend ist die Zuweisung dieser Attribute, die in
diesen Klassen oder „Constructs“ definiert sind. Diese
Aufgabe übernehmen sogenannte „Automatic Class Selection
Routines“ (ACS Routinen). Basierend auf Kriterien wie DSN,
Jobname, Größe der Datei und ca. weiteren 25 Kriterien,
werden jeder einzelnen neuen Datei entsprechende Klassen
zugewiesen. Für jede Klasse gibt es eine solche ACS Routine.
Die Übersicht ”ACS Routinen und Speicherhierarchie“ zeigt
die Rolle der ACS Routinen. Basierend auf diesen logischen
Klassen sucht das System den optimalen Speicherplatz für
die betroffene Datei in der vorhandenen Speicherhierarchie.

Die Auswahl des Platzes in der Speicherhierarchie wird
”Volume Selection“ genannt. DFSMS geht durch eine Anzahl
von Schritten und erstellt eine Liste von potenziellen
Volumes, eine sogenannte ”candidate disk volumes“­Liste,
die in Frage kommen, um die neue Datei dort abzuspeichern.
Diese Volume­Liste basiert auf der Auswahl der entsprechenden
Storage­Gruppen, wie sie in der Storage Group ACS
Routine zugewiesen wurden.
Die sogenannte ”primary candidate“­Liste enthält Volumes,
die alle Kriterien erfüllen, die in der entsprechenden Storage
Class und Data Class spezifiziert wurden. Es gibt noch eine
”secondary candidate volumes“­Liste, die alle die Volumes
enthält, die nicht alle Kriterien erfüllen, aber ebenfalls in der
Storage Group ACS Routine zugewiesen wurden.
Wenn diese ”primary candidate”­Liste nicht leer ist, wird
sie an die z/OS­Komponente System Resource Manager
(SRM) übergeben. SRM wählt dann eines oder mehrere
Volumes von dieser Liste aus. Kriterien für SRM sind z. B.
die kürzeste Wartezeit für eine I/O auf dem betreffenden
Volume oder das Volume ist noch nicht für den momentanen
Job im Einsatz. Falls die primary Liste leer ist, versucht
DFSMS aus der secondary Liste direkt ein oder mehrere
Volumes auszuwählen, ohne über den SRM zu gehen. Das
wichtigste Kriterium ist dann der verfügbare freie Platz.
Nachdem eines oder mehrere Volumes ausgewählt wurden,
wird die Datei auf dem betreffenden Volume platzmäßig
angelegt (Volume Allocation) und ein entsprechender
Eintrag im Katalog erstellt.
Sollte die Allocation nicht erfolgreich sein, wird die Volume
Selection so oft wiederholt, bis entweder Volumes gefunden
werden, um die Datei dort anzulegen, oder der Prozess
bricht am Ende mit einer entsprechenden Nachricht ab,
wenn kein eligibles Volume gefunden werden konnte.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
171

IBM Storage Software
Der System-verwaltete Speicher im Mainframe-Umfeld – Werner Bauer
SMS für Tape
Policy-basierendes Storage Management für Tape Libraries
DFSMS verwaltet nicht nur die Dateien in einem Disk
Storage Subsystem, sondern auch die Daten und Einheiten
in einer Tape Library. Das gilt für automatische Tape Libraries
mit einem Robotorzugriff zu den Kassetten und Stellplätzen
oder für sogenannte ”Manual Tape Libraries“ mit
manuellem Laden der Kassetten in ein Tape­Laufwerk.
DFSMS gruppiert in diesem Ansatz die Kassetten und die
zugehörigen Kassetten­Laufwerke in einer entsprechenden
Tape Storage Group.
System­managed Tape verwaltet die Tape Libraries, die
Tape­Laufwerke und die Tape­Kassetten selbst, aber nicht
die einzelnen Dateien, die auf diesen Tape­Kassetten stehen.
Diese Funktion gewährleistet DFSMSrmm (Removable
Media Manager), indem er ein Verzeichnis führt, welche
Datei sich auf welcher Kassette befindet. Die Kassetten
haben ebenfalls ein Label, das ähnlich ist wie bei den Disk
Volumes.
Die Abbildung ”System­managed Tape“ zeigt, wie über
die ACS­Routinen für eine bestimmte Datei auf Tape eine
bestimmte Tape Library zugewiesen wird.
Die Policy­basierende Speicherverwaltung für Dateien auf
Tapes kann auch auf die betroffenen Libraries selbst über
eine sogenannte ”outboard“ Verwaltung ausgelagert werden.
DFSMS weist die Konstrukte Data Class, Storage Class
und Management Class von einer Tape­Datei dem Tape­
Subsystem zu und übergibt diese Konstrukt­Namen
(construct names) an die Library. Die Ausprägung der
„Constructs“ wird in der Library selbst definiert und dann
entsprechend ausgeführt – im Gegensatz zu dem zentralen
Ansatz von DFSMS im Host.
DFSMSrmm verwaltet die eigentlichen Dateien auf den Kassetten.
Auch hier werden Attribute aus der Management
Class entsprechend angewandt wie z. B. Lebensdauer und
automatisches Löschen der Dateien, wenn die Dateien über
einen definierten Zeitraum nicht referenziert wurden.
Komponenten und Funktionen
Komponenten
Die Abbildung ”z/OS components for centralized storage
and data management“ zeigt die System­Komponenten
im z/OS, die für die Allocation, also die Platzierung in der
Storage­Hierarchie, verantwortlich sind. Sie zeigt auch die
Komponenten, die für das Space Management und die
Availability angezogen werden.
Neben dem DFSMSdfp kommt auch der SRM von z/OS
für die „data set allocation“ zum Einsatz, wenn eine Datei
neu angelegt wird.
Für das Space Management und das Availability Management
sind alle vier Komponenten miteinander verknüpft.
Jede Komponente hat einen bestimmten Auftrag innerhalb
von SMS zu erfüllen:
1. DFSMSdfp – stellt das Interface zu den Policies her
und instruiert die anderen Komponenten
2. DFSMSdss – ist eine Art Data Mover und bewegt fast
alle Dateien
3. DFSMShsm – ist zuständig für das Space- und Availability
Management. DFSMShsm bestimmt, welche Datei für
Backup-Zwecke kopiert wird bzw. schafft freien Platz,
indem nicht aktive Dateien ausgelagert und migriert werden.
4. DFSMSrmm – ist für die Aufzeichnung der Kassetteninhalte
bzw. für die Dateien auf Tape verantwortlich.
172 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

DFSMS arbeitet mit zwei Repositories, dem Active
Control Data Set (ACDS) und dem Communication Data
Set (COMMDS). DFSMShsm und DFSMSrmm haben jeweils
eigene Repositories, die aber über DFSMSdfp mit den
DFSMS­Dateien ergänzt und abgeglichen werden.
Funktionen
Space Management
Über die SMS­Konstrukte und hier speziell über die
Management Class werden Service Level Objectives bzgl.
dem verfügbaren Platz auf Disk Storage Subsystemen bzw.
den Volumes in einem solchen Subsystem spezifiziert. Das
Ziel ist, dass Anwendungen nicht abbrechen, weil ein
Problem mit nicht genügend freiem Platz aufgetreten ist.
DFSMShsm ist die DFSMS­Komponente, die die Policies
für das Space Management überwacht und notwendige
Aktionen ausführt, wenn die Policies nicht mehr eingehalten
sind. Dabei werden neben der Management Class auch
Angaben der Storage Groups herangezogen, um den Platz
auf allen verwalteten Volumes in den Disk Storage Subsystemen
auf Datei­Level zu verwalten. Das Kriterium sind
sogenannte Thresholds auf Volume Level und auf Storage
Group Level, die eingehalten werden müssen, um immer
genügend freien Platz für neue Dateien bereitzuhalten.
Dieser Migrationsprozess erfolgt periodisch und es werden
nicht aktive Dateien als Kandidaten für eine Verlagerung
auf eine andere Klasse der Speicherhierarchie von
DFSMShsm ausgewiesen.
Auch wenn eine Datei von einem Volume in eine von
DFSMShsm verwaltete Disk/Tape­Speicherhierarchie
ver lagert wurde, bleibt die Datei nach wie vor katalogisiert.
Wenn eine solche Datei von der Anwendung referenziert
wird, führt DFSMShsm automatisch einen ”Recall“ durch
und bringt die Datei zurück auf ein aktives Application
Volume. Dieser Prozess ist für die betroffene Anwendung
oder den Benutzer völlig transparent und unbemerkt.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
173

IBM Storage Software
Der System-verwaltete Speicher im Mainframe-Umfeld – Werner Bauer
DFSMShsm löscht auch automatisch Dateien, deren
Lebensdauer nach ihrer zugewiesenen Management Class
abgelaufen ist (deleting expired data sets). Es werden aber
auch temporäre Dateien gelöscht oder es wird Platz freigegeben,
der innerhalb einer Datei nicht mit Daten genutzt ist,
wenn das durch die zugehörige Management Class als
Attribut verlangt wird.
Availability Management
Availability Management verwaltet die Backup­Kopien von
aktiven Dateien, die auf aktiven Disk Storage Volumes, auch
L0­Volumes genannt, liegen. Das Ziel ist, dass auf eine
Sicherungskopie zurückgegriffen werden kann, wenn die
Original­Datei fehlerhaft oder beschädigt ist – oder gar ein
ganzes Volume nicht mehr lesbar ist. DFSMShsm nutzt die
Policy­Angaben in der Management Class und Informationen
von der Storage Group, um automatisch und periodisch
Sicherungskopien der Original­Dateien zu erstellen. Diese
Sicherungen können auch über entsprechende
Kommandos angestoßen werden.
Konsolidieren von gültigen Dateien auf Tape-Kassetten
Über die Management Class werden Policies festgeschrieben,
wie und wann Sicherungskopien zu erstellen sind oder
wann Original­Dateien ausgelagert werden sollen. In der
Management Class wird auch festgeschrieben, wann eine
Datei gelöscht werden soll oder wie viele Sicherungs­Versionen
einer Original­Datei wie lange aufbewahrt werden
sollen. Auf einer Tape­Kassette sind oft viele Hunderte
Dateien über das Space Management oder das Availability
Management geschrieben worden, die zu unterschiedlichen
Zeiten für eine Löschung eligibel werden.
Die Abbildung ”Konsolidierung von gültigen Dateien auf
Tape­Kassetten“ zeigt, wie über einen ”Reclamation“­ oder
”Recycle“­Prozess nicht mehr valide Sicherungskopien oder
nicht mehr benötigte und ausgelagerte Dateien
entfernt werden.
Dabei werden neue Tape­Kassetten erstellt, die anschließend
wieder mit gültigen Dateien beschrieben sind. Die
dadurch frei gewordenen Tape­Kassetten werden in einen
Scratch Pool zurückgeführt und stehen damit wieder für
neue Tape Requests zur Verfügung.
DFSMShsm Common Recall Queue
Entscheidend für die Leistungsfähigkeit von DFSMShsm ist
die intelligente Nutzung von Funktionen und Services, die
z/OS und Parallel Sysplex zur Verfügung stellen. Die Leistungsfähigkeit
von DFSMShsm ist besonders kritisch, wenn
viele Dateien aus dem DFSMShsm­verwalteten Repository
zurückgerufen werden müssen (über die Recall­Funktion
von DFSMShsm). Wenn eine Anwendung oder ein Benutzer
eine Datei referenziert, die im Rahmen vom Space Management
auf die DFSMShsm­kontrollierte Speicher­Hierarchie
ausgelagert wurde, muss die Anwendung darauf warten,
bis DFSMShsm die Datei auf das Application­Volume (L0)
zurückgerufen hat (Recall). Wird diese Wartezeit minimiert
und damit der Durchsatz im System erhöht, trägt das zu
einer effizienteren Nutzung des gesamten Systems bei.
DFSMShsm optimiert deshalb diese Recall­Herausforderung
und nutzt die Coupling Facility als Repository für eine
gemeinsame Queue von Recall­Anforderungen. Die
Kommunikation von den DFSMShsm­Systemen innerhalb
eines Sysplexes erfolgt über die XCF­Technologie, bei der
die Coupling Facililty (Cross­System Coupling Facility),
praktisch einen schnellen und gemeinsam genutzten
(shared) Halbleiterspeicher darstellt.
174 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Eine typische Parallel Sysplex Konfiguration besteht aus
einer DFSMShsm­Instanz in jedem z/OS Image innerhalb
eines solchen Sysplexes. Die Recall­Anforderungen können
sehr unterschiedlich in den verschiedenen z/OS Images
eintreffen. Beispielsweise hat der HSM1 in der Abbildung
”DFSMShsm – common recall queue“ für diesen Moment
wesentlich mehr Recall­Anforderungen abzuarbeiten als der
HSM2 in dem zweiten System. Jeder DFSMShsm bearbeitet
die Anforderungen in seiner lokalen Queue und weiß nichts
über die Anforderungen in dem jeweils anderen System.
Parallel­Sysplex­weites Load Balancing wurde mit der
Einführung einer Common Recall Queue möglich.
Neben weiteren positiven Nebeneffekten ist offensichtlich,
dass damit der Gesamtdurchsatz verbessert werden kann.
Nebeneffekte betreffen eine optimalere Berücksichtigung
von Prioritäten, effizientere Nutzung von Tape Resourcen,
indem z. B. alle Requests nach Tape­Kassetten sortiert
werden, und eine größere Flexibilität mit einer Sysplex
Konfiguration.
DFSMSdfp und Data Striping
Ein weiteres Beispiel aus einer Vielzahl von Funktionen und
Services durch DFSMS soll das Data Striping sein. Anstatt
eine Datei auf ein einziges Volume zu platzieren, wird eine
Datei auf mehrere Volumes verteilt oder „gestriped“. Die
daraus resultierende Verbesserung der kombinierten Ein­/
Ausgabe trägt dazu bei, dass der „Single File“­Durchsatz
entsprechend erhöht werden kann. Dadurch kann die
Verweildauer von Anwendungen und Jobs mit hohen Anforderungen
an den Durchsatz von sequenziellen I/Os deutlich
verkürzt werden. Das gilt auch in einem gewissen Maße für
wahlfreie I/Os (Random I/Os), wenn die Anwendung I/Os
parallel absetzen und verarbeiten kann. Dies ist die Regel
bei Datenbank­Subsystemen wie DB2 oder IMS­DB.
Die Abbildung ”DFSMSdfp – Data Set Striping“ illustriert
diesen Striping­Effekt für den sequenziellen Durchsatz.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
175

IBM Storage Software
Der System-verwaltete Speicher im Mainframe-Umfeld – Werner Bauer
Die rechte Seite der Abbildung symbolisiert den Effekt
von Data Striping. Im Fall der Datei auf einem Volume ist
der maximale sequenzielle Durchsatz des Zugriffs­Pfades
100 MB/s. Wird für diese Datei über die Storage Class ein
Attribute mitgegeben, das besagt, dass der sequenzielle
Durchsatz 300 MB/s sein muss, dann würde DFSMS bei der
Anlage dieser Datei automatisch dafür sorgen, dass diese
Datei auf drei Volumes verteilt (gestriped) wird, wenn jedes
Volume mit der Geschwindigkeit von 100 MB/s genutzt werden
kann. DFSMS bzw. z/OS kennt genau die Möglichkeiten
jedes einzelnen Volumes und nutzt diese Information bei
der automatischen Auswahl der Volumes, wenn eine entsprechend
neue Datei angelegt werden soll.
Das System z/OS mit seinem integrierten DFSMS reagiert
automatisch auf geforderte Service­Levels und führt entsprechende
Aktionen bezüglich der Datenverteilung und
der Optimierung der vorgefundenen Speicherkonfiguration
durch. Der System­verwaltete Speicher ist heute im z/OS­
Umfeld die höchste Perfektionsstufe in der automatischen
Datenverwaltung und Datenspeicherung.
Zusammenfassung
DFSMS oder der System­verwaltete Speicher ist eine
Software­basierende Lösung für z/OS. Er wurde seit der
Ankündigung in 1989 kontinuierlich verbessert und nutzt
automatisch neue Möglichkeiten der modernen Server­ und
Speichertechnologie aus. Dieses Kapitel nennt nur einige
Beispiele, wie DFSMS dazu beiträgt, die steigenden Anforderung
an Verfügbarkeit und Leistung in modernen Rechenzentren
zu gewährleisten und ständig zu verbessern.
DFSMS dient auch als Vorbild für ähnliche Entwicklungen
in den Open­Systems­Umgebungen mit Unix und Intelbasierenden
Betriebssystemen.
176 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software
Anhang
177

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

In ersten Pilotprojekten erwies sich die DataKeep/VM­
Lösung als stabiler als E­SMS und führte am 1. November
1990 zur Ankündigung des WDSF/VM­Software­Produkts
(Workstation DataSave Facility Release 1). Die Namensänderung
von „DataKeep/VM“ hin zu „WDSF/VM“ war durch
Vorbehalte der IBM Rechtsabteilung kurz vor der Ankündigung
notwendig geworden, obwohl schon die gesamte
Produktdokumentation gedruckt worden war.
WDSF/VM Release 1 war die erste Cliet/Server Anwendung
der IBM für die Sicherung von PC/Workstation­Daten der
Betriebssysteme MS­DOS, OS/2 und AIX. Das Produkt war
konzipiert nach den noch heute gültigen Prinzipien von
transaktionsbasierter Operation, regelgesteuerter Datenspeicherung,
einem rein inkrementellen Datensicherungszyklus
für Filesystemdaten und der Verwendung von
hierarchischen Speicherpools für den kombinierten Einsatz
unterschiedlicher Speichertechnologien (Disk­to­Disk oder
Disk­to­Disk­to­Tape).
Die Entwicklungsmannschaft hat sich auch selbst ein Denkmal
gesetzt in den Tiefen des TSM­Servers. Wenn man den
undokumentierten Befehl „show developers“ in der Admin­
Commandline des TSM­Servers absetzt, bekommt man die
Protagonisten aufgelistet (siehe Screenshot unten).
Die Entwickler setzen sich ein Denkmal – „show developers“-Befehl im TSM-Server
Die Metadaten­Verwaltung wurde in der WDSF/VM­Server­
Komponente in einer Datenbank realisiert, die Grundlagen
aus der ARIES­Architektur verwendete. ARIES = Algorithms
for Recovery and Isolation Exploiting Semantics war u. a.
vom IBM­Fellow Dr. Mohan aus Almaden entwickelt worden.
Die in ARIES definierten Prinzipien der „write­ahead logging
based recovery method“ sind heute noch die Grundlage
von TSM und einer Vielzahl von anderen IBM Anwendungen
(DB2, MQSeries, Domino etc.) und die Basis relationaler
Datenbanksysteme überhaupt.
Die Implementierung basierte auf einer hierarchischen
Datenbank­Architektur (B+ Tree), die den Anspruch erfüllte,
auf allen Betriebssystemen der geplanten Server­Plattformen
lauffähig zu sein, was zu diesem Zeitpunkt DB2 nicht
erfüllte. Erst jetzt – fast 20 Jahre später – hat das verwaltete
Metadaten­Volumen in TSM­Servern unserer Kunden Größenordnungen
erreicht, die mit der bisherigen Datenbank­Architektur
nicht mehr skalierbar verarbeitet werden können.
Deshalb hat man TSM in seiner aktuellen Version 6.1 auf
DB2 als Datenbanktechnologie umgestellt.
Das Konzept sah weitblickend auch vor, die Funktionen
von Datensicherung in allgemeine Systems Management
Lösungen integrieren zu können, z.B. durch die Bereitstellung
einer übergreifenden Management­Konsole und Schnittstellen
zur Erstellung von Berichten, zum Sammeln von Verrechnungsinformationen
und zum Weiterleiten von Fehlerkonditionen.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 179

IBM Storage Software
Tivoli Storage Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke
Die wichtigsten Designprinzipien der neuen Datensicherungs­Software
waren:
•
•
•
•
•
•
•
•
•
•
Platform Independent Code
Enable the server to preserve the physical locality that data
has at its source even when clients deliver this data over long
periods of time.
Estimate the target workload and develop the system to
accommodate them.
Deploy the system in many computing platforms.
Provide lights-out, unattended operation with unattended
recovery from failures.
Provide continuous operation
Accommodate the peculiarities of a wide variety
of storage devices
Manage the storage system through user controlled policies
Minimize the periods of time in which an entity in the system
cannot be retrieved
Use additional temporary storage space to gain
concurrency and to increase the availability of user data
Quelle: „Applying Database Technology in the ADSM Mass
Storage System“ von Luis-Felipe Cabrera, Robert Rees and
Wayne Hineman IBM Almaden Research
Center 1995.
Policy Manager
Transaction
Manager
Logical Volume Manager
Communication
Driver
Session Manager
Administration
Manager
Transaction and Metadata Support
LOG
Index
Manager
Block Disk Driver
ADSM-Server: Principal Software Components
Central Scheduler
Inventory
Manager
Pseudo Kernel
Bitfile Storage
Storage Segments
Export Import
Manager
Storage Subsystem
Development Driver
Physical Volume
Repository
Hier ein weiterer Auszug aus der gleichen Veröffentlichung
mit einer Strukturdarstellung der Anwendungskomponenten
und einer Beschreibung des Zusammenspiels der Module
beim „incremental backup“:
For incremental backup, the session begins by the client requesting
from the server the corresponding policies from the Policy
Manager. Policies are stored in system catalogues administered
by the Index Manager. The client then builds the candidate list
of files for backup and requests the server to send, from the
Inventory Manager, the latest information for each of the
candidate files. The Inventory Manager stores all its information
in catalogues administered by the Index Manager. The client
then sends to the server, optionally compressing them, only those
user files that have changed or have been created since the last
incremental backup. The server constructs appropriate entries
in the Inventory Manager and appropriate bitfile using the
Bitfile Storage component. Bitfiles are stored using the
Storage Segment Manager.
At the end of sending all the user files the client also sends the
server the list of user files that have been deleted since the last
incremental backup allowing the server to mark them and, eventually,
to expire them from the system. The client then commits
the transaction and disconnects from the server […]
[…] Database technology has been applied before to distributed
systems, to file systems, operating systems, to message queuing
systems and to network I/O subsystems.
To our knowledge we are the first ones to apply transactions
to a mass storage system that administers a
storage hierarchy. The fundamental difference with all
other systems is the need to support high degrees of concurrency
for a variety of transactions in the presence of
devices with enormous latency times. A second difference
is that our server can replicate its metadata with up to three
copies. No other backup system or file system we know of has this
function […].
180 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Auszug aus dem WDSF/VM­Ankündigungsschreiben am
1. November 1990:
Workstation Data Save Facility/VM turns VM host into a server
WDSF/VM Release 1 is a client-server licensed program for
backing up, archiving, and restoring disk data files. It enables
a VM system to act as a server for workstations and personal computers,
and moves the responsibilities of back-up archive media
management to VM, while providing client applications to several
workstation-based environments including MS-DOS, OS/2
Extended, AIX/RT and AIX Version 3.
It consists of a server program that runs under VM and one of
the above environments, and while the archive function is userinitiated,
the back-up function may be automated through
scheduling. Backups may be performed from either end-user
workstations or from workstation-based servers. Incremental
backups may be run as background tasks under OS/2 and AIX,
and when files are backed to VM-attached disks, older and larger
files are automatically moved to tape. Archival functions enable
the use of host storage resources as a off-line storage pool and
WDSF/VM uses TCP/IP, NetBIOS or 3270 data stream support
for communications.
There is an optional facility for compressing data in the workstation
client program. It operates on any System 370 or System
390 processor and requires a 1,600bpi or 6,250bpi tape drive,
a 3480 or 3490 magnetic tape subsystem, 10 cylinders of 3380
disk space and 6Mb of virtual storage.
[ … ] WDSF/VM will be available March 29, and AIX 3 Client,
September 27, 1991
Die erste WDSF/VM­Version beinhaltete die Client­Unterstützung
der damals marktüblichen IBM PC/Workstation
Plattformen OS/2, AIX/RT, AIX V3 und MS­DOS mit der
Anbindung über die LAN­Kommunikationsprotokolle TCP/IP,
NetBIOS und 3270 LU2.0. Hinzu kamen im Laufe der Zeit
noch die Protokolle SNA LU 6.2, IPX/SPX, CLIOS und
Named Pipes. Die Unterstützung dieser Protokoll­Vielfalt
hatte Bestand bis zur TSM Version 4.1 in 2001. Heute
unterstützt TSM nur noch TCP/IP, SNMP für verteilte Umgebungen
und Shared Memory und NamedPipe Protokoll für
Client/Server­Lösungen auf dem gleichen physischen System.
Eine erste Erweiterung war im November 1991 die Ankündigung
von WDSF/VM Release 1 Enhanced mit der Verfügbarkeit
von zusätzlichen Clients auf SunOS und Apple MacOS.
Damit begann auch die Ära der weitreichenden Unterstützung
von anderen Open­System­Betriebssystemplattformen.
In der Blütezeit wies die Client­Unterstützungsliste etwa 40
Systemumgebungen auf.
Workstation Data Save Facility/VM Release 1 Enhanced
Workstation Data Save Facility/VM is enhanced to provide support
for Sun Microsystems Inc‘s SunOS Version 4.0.1 and Version
4.1.1, and Apple Computer Inc MacOS Version 6.0.7 and System
7 clients.
AIX Version 3 for RS/6000 client will be available September 27,
while WDSF/VM Programmer‘s Reference, SunOS Client, and
MacOS Client will ship June 26, 1992.
Der allgemeine Trend in Richtung von verteilten Systemen
war der Grund für den nächsten Schritt, den Tivoli Storage
Manager in seiner Produkthistorie nahm. Im Jahr 1992
wurde einmal die Anwendung von Chip Coy und Bill Fischofer
in Endicott auf MVS portiert und für die Plattformen VM und
MVS in DFDSM umbenannt – somit war das neue Datensicherungsmodul
für Workstations ein Mitglied der S/370
DFxxx Speichersoftware­Familie geworden.
Parallel dazu trieben Norm Pass (RINGMASTER Projekt)
und Mike Kaczmarski mit ihren Teams in Kalifornien die
Portierung auf AIX und OS/2 als Server voran. Das neue
DFDSM­Produkt wurde auch gleich 1992 auf der COMDEX
in Las Vegas gezeigt, allerdings unter etwas fragwürdiger
Schwerpunktsetzung, wie der Entwickler Barry Fruchtman
als Messeteilnehmer beschreibt.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 181

IBM Storage Software
Tivoli Storage Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke
Eingangsbildschirm ADSM V1.2 MS-DOS-Client
Barry Fruchtman: „One item that may be interesting is that
IBM Storage made an appearance at COMDEX in 1992 in Las
Vegas with a demonstration of the DFDSM. We demonstrated,
AIX, OS/2, and DOS clients backing up and restoring to VM,
MVS, AIX and OS/2 servers; The OS/2 clients were running
a video at the same time that they were in a loop backing
up and restoring. For the few people which looked at the
DFDSM sign and stopped to watch, it was an amazing demo,
given the capabilities of the time. It was located in the multimedia
area of COMDEX, however, so there was a mismatch with
the intended audience…“.
Die Anekdote dokumentiert augenzwinkernd, dass die IBM
Messeplaner damals die Bedeutung von Workstation Datensicherung
der Tatsache unterordneten, dass zu gleicher Zeit
ein Multimedia­Video auf dem OS/2­PC ablief.
Wie aus dem Augenzeugenbericht ersichtlich, gab es 1992
schon die ersten internen Portierungen der DFDSM­Server­
Komponente auf die Plattformen AIX und OS/2, die aber erst
ein Jahre später als käufliche Produkte unter dem neuen
Namen ADSM V1.2 verfügbar wurden.
In dieser Zeit gab es noch weitere Entwicklungen und Produkte,
die VM und MVS als Serverplattform für Datendienste
der Open System Workstations nutzten:
• WLFS/VM – Workstation LAN File Services (Ankündigung
Dezember 1992 – später wegen Verfügbarkeit auf MVS in
LAN File Services/ESA umbenannt) – eine Anwendung, die
einen OS/2 LAN-Server über eine S/370 BMPX-Bus/Tag
Adapterkarte an den VM-Server verband und transparent
CMS-Minidisks als Laufwerks-Ressourcen für den OS/2
LAN-Server verfügbar machte. Das geschah mit dem Hintergedanken,
die Zuverlässigkeit der Mainframe-Datenhaltung
mit den neuen interaktiven und grafischen Möglichkeiten
der Workstations synergetisch zu verbinden.
• LANRES/VM und LANRES/MVS (LAN Resource Extension
and Services 1992) – die analoge Lösung zu WLFS/VM für
Novell Netware Fileserver mit Anschluss entweder über
eine BMPX-Kanalkarte, TCP/IP oder eine SNA LU6.2 Kommunikationsverbindung.
Hierbei waren nicht nur Fileservices
unterstützt, sondern auch bi-direktionales Drucken.
182 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Alle diese Lösungen wurden damals in der Computer­
Presse als ein Versuch gewertet, den bevorstehenden
Untergang des Mainframe­Rechners als zentralen Anwendungsserver
durch die Verwendung als Open System
Server Ressource zu verhindern.
Dass die Nutzung des Mainframes als Server bis heute
Bestand hat für eine Vielzahl von unternehmenskritischen
und plattformübergreifenden Anwendungen (z. B. SAP,
Domino, ContentManager etc.) und Diensten (wie TSM),
hätte die damaligen „Branchenkenner“ in ihrem Weltbild
wohl nachhaltig erschüttert.
CW-Artikel (Auszug) vom 22.1.1993 zur Ankündigung von LANRES
(Quelle: http://www.computerwoche.de/heftarchiv/1993/4/1125617/)
Aufbruch in die Open-System-Welt
ADSM V1.1 – 29. Juli 1993 und ADSM V1.2 16. November 1993
Der in Mainframe­Kreisen gängige Name DFDSM konnte
nicht für den Zielmarkt der Open Systems benutzt werden,
weil in dieser Zeit die Polarisierung zwischen Befürwortern
von Mainframe­Systemen und Open Distributed Systems
schon klassenkämpferische Dimensionen annahm und man
um den Produkterfolg fürchtete.
IBM­intern hatte man kurz nach der Verfügbarkeit von
DFDSM entschieden, die Server­Komponente auch auf
PC/Workstation­Betriebssysteme zu portieren und den
Namen auf ADSM (ADSTAR Distributed Storage Manager)
zu ändern.
AdStaR-Ankündigung – New York Times 1992
(Quelle: http://www.nytimes.com/1992/03/20/business/company-news-newibm-name-for-storage-unit.html)
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 183

IBM Storage Software
Tivoli Storage Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke
ADSTAR
Wie im Artikel beschrieben, ist AdStaR das Akronym von
„ADvanced STorage And Retrieval“ und wurde als Brandname
eingeführt für die IBM Storage Systems Division
(IBM ADSTAR Storage Systems Division). Grund für diese
Umbenennung waren Gedankenspiele des damaligen IBM
Managements, IBM Divisionen als selbstständige Unternehmensteile
auszugliedern und sie über eigene Warenzeichen
zu individualisieren (siehe auch MagStaR). Diese Pläne
wurden jedoch in der Folge nicht umgesetzt, aber das
Warenzeichen ADSM blieb bis 1999.
Das „Safeman“­Logo hat der ehemalige IBM Grafik­
Designer Mike Welkley entworfen, der die Entstehungsgeschichte
so beschreibt:
Here‘s a little history on how the Safeman came about... I was
working on the ADSM GUI back in 1993. Periodically we would
bring in prospective customers to test the product and the software
team asked if I would create a mouse pad that could be given to
the customers as a complimentary gift. Given a blank canvas to
create whatever I wanted for the design, I decided to create a
cartoon character that represented ADSM Storage.
Brandname und Identifikation –
Das Original des ersten ADSM „Safeman“-Logos
The mouse pad with the ADSM Safeman character on it, for
whatever reason, never got printed. However, the ADSM Marketing
team somehow got hold of the mouse pad design and wanted to
print the character on buttons as a tradeshow giveaway. This was
the first use of the character.
Die ADSM V1.1­Ankündigung bestand aus zwei unabhängigen
Komponenten, einmal den Speichermanagementfunktionen
für Datensicherung/Archivierung und zum anderen
aus dem Datenzugriffsteil DAS (Data Access Services),
das eigentlich mit dem Thema Datensicherung oder Speicher
nichts zu tun hatte. Hier der Auszug aus dem Ankündigungsschreiben:
Announcement Letter Number 293-382 dated July 29, 1993
US – Last Revised on July 29, 1993
Brief Description of Announcement, Charges, and Availability
IBM announces the availability of ADSTAR (TM) Distributed-
Storage Manager Version 1 Release 1*. The ADSTAR Distributed
Storage Manager provides storage management and data access
capabilities. The storage management capabilities provide an
automated, highly-reliable, high-performance, network-based
backup and archive product for workstations and local area
network (LAN) file servers. It consists of an MVS- or VM-based
backup/archive server and backup/archive clients for DOS, OS/2
(R), AIX (R) for RISC System/6000 (R), Microsoft Windows,
Apple Macintosh, SPARC /Solaris, HP-UX, and Novell NetWare
systems. The data access services (DAS) provide Distributed
FileManager for OS/2 Version 2 and the Record Level Input/
Output (RLIO) API. Distributed FileManager provides local or
remote record level access for OS/2 Version 2 applications.
These capabilities are now available as a separately orderable
component…[…]
ADSTAR Distributed Storage Manager Version 1
Release 1 is the successor product of IBM Workstation
Data Save Facility/VM (5684­122)and supports
existing WDSF/VM backup/archive clients.
184 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Die „Data Access Services (DAS)“ waren eine Zusammenstellung
aus dem „Distributed File Manager (DFM)“ für OS/2
V2 und dem Zugriffs­API RLIO (Record Level I/O). Es handelte
sich also um eine Anwendungs­Middleware, die nach
den Vorgaben der „IBM System Anwendungs Architektur
(SAA)“ verschiedene Anwendungsteile auf unterschiedlichen
Betriebssystemen miteinander kommunizieren lassen
konnte, sofern die geforderte Schnittstellen­Kompatibilitäten
vorhanden waren (DDM/LU6.22 ).
In der Version ADSM V1.1 gab es eine Reihe von Anwendungen,
die für die Datensicherung mit ADSM getestet
waren:
•
•
•
DB2/6000 provides an online backup of log and data to
a remote MVS or VM system using ADSTAR Distributed
Storage Manager.
IBM LAN File Services/ESA [vormals WLFS/VM d. A]
Customers using LAN File Services/ESA to distribute data
objects will now be able to protect their data with ADSTAR
Distributed Storage Manager.
IBM DFSMS/VM uses ADSTAR Distributed Storage Manager
to provide migration support for its SMS-managed
storage hierarchy.
Data Access Services CD – Zusatzkomponente zu ADSM V1.1
•
•
The Norton Backup for Windows. Windows V3.1 users will
now be able to backup their data to ADSTAR Distributed
Storage Manager using the popular Norton Backup for
Windows interface.
Additionally, IBM has tested the ADSTAR Distributed
Storage Manager backup/archive clients with the following
database products for support of offline database backup
and archive
- IBM DB2 OS/2 Version 1
- IBM DB2 AIX/6000 Version 1
- SYBASE 4.5 and 4.9 (except for raw partition support)
- INFORMIX-OnLine for AIX/6000
- Borland dBASE IV 1.5 for DOS
- Borland PARADOX 4.0 for DOS
- Borland PARADOX 1.0 for Windows
- Microsoft ACCESS 1.0 for Windows
- Microsoft FOXPRO 2.5 for Windows
- INGRES Intelligent Database for AIX/6000
- ORACLE for IBM
2 IBM Definition DDM:
“Distributed Data Management DDM“ is a function of the operating system that allows an application program or user on one system to use database files stored
on remote systems. The systems must be connected by a communications network, and the remote systems must also be using DDM…. Remote systems
on which data can currently [1993 d.A.] be read or written are: CICS/MVS (TM), CICS/VSE (TM), OS/400 (R) and 4680 Store Systems.”
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 185

IBM Storage Software
Tivoli Storage Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke
Auszug aus der ADSM V1.2-Ankündigung mit OS/2 und AIX als Server-Plattformen
Im November 1993 wurden mit ADSM V1.2 die ADSM­
Server auf OS/2 und AIX angekündigt (ADSM/2 und
ADSM/6000). Damit begann die Ära der Open­System­
Plattformen für ADSM.
Der Backup­Markt war in dieser Zeit gekennzeichnet
durch eine starke Polarisierung zwischen den Desktop/
PC­basierten Backup­Lösungen (DOS, OS/2, Novell Netware,
Apple MacIntosh) und entsprechenden Lösungen
für UNIX­Workstations. Allen diesen Lösungen war zu eigen,
dass sie Magnetband als Sicherungsmedium unterstützen
konnten, wegen der Vorteile als preiswerter Massenspeicher
für die Langzeitspeicherung.
Die folgenden Aufstellungen sind ein Auszug aus einer
Marktübersicht aus dem PC­Magazine vom 29. März, 1994,
pp.227­272 (Quelle: http://stason.org/TULARC/pc/storage2/
index.html). Die Listen beinhalten ausschließlich Lösungen,
bei denen der Sicherungsserver selbst auf Open­System­
Plattformen betrieben wurde, parallel dazu gab es auch
Angebote, die den Mainframe als Server nutzten, wie
„Harbor“ von New Era oder „FDR/Upstream“ von Innovation
Data Processing:
Arcada Software – Storage Exec. (NT)
Avail (NT)
Cheyenne Software – ArcServe (Netware)
Conner Storage Systems – Backup Exec (Netware)
Emerald Systems – Xpress Librarian
Fortunet – NSure NLM/AllNet
Hewlett-Packard – OmniBack II (NT)
Legato – NetWorker (Netware)
Mountain Network Solutions – FileSafe
NovaStor (Netware)
Palindrome – Backup Director und Network Archivist
(Netware, OS/2, Windows)
186 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
•
•
•
•
•
•
•
•
•
•
•
Nachfolgend die Liste der UNIX­Lösungen, wobei hier die
Bedeutung von Magnetband­Unterstützung nicht so gravierend
war wie bei den Desktops/PCs, weil UNIX durch die
Systemfunktionen tar, cpio, dd und dump schon Bandunterstützung
kannte.

•
•
•
•
•
•
•
•
•
•
•
•
APUnix – FarTool
Cheyenne – ArcServe
Dallastone – D-Tools
Delta MicroSystems (PDC) – BudTool
Epoch Systems – Enterprise Backup
Hewlett-Packard – OmniBack II
Legato – Networker
Network Imaging Systems
Open Vision – AXXion Netbackup 2.0 Software
Software Moguls – SM-arch
Spectra Logic – Alexandria
Unitree Software – Unitree
In diese Märkte brach nun ADSM V1.2 ein, eine unternehmensweite
Backup­Lösung auf Open­System­Plattformen für
Desktops und UNIX­Workstations, die sich schon unter den
Mainframe­Betriebssystemen VM und MVS als Serverplattform
bewährt hatte und die ganze Erfahrung der IBM im Verwalten
großer Datenmengen einbrachte. Dies war vor allem für
solche Kunden wichtig, die einerseits die neue „demokratische“
Organisation von PCs und Workstations in verteilter
Verarbeitung nutzten, andererseits auf die hohen Sicherheits­
und Verfügbarkeitsstandards der Mainframe­Technologie
für das zentrale Datenmanagement nicht verzichten
wollten.
ADSM V1.1 – Handbücher aus der „black books collection“
In der Folgezeit bewährte sich für ADSM eines der obersten
Design­Prinzipien von WDSF/VM, ADSM und TSM – die
Nutzung von „common code“. Es musste nicht für jede
Client­/Server­Plattform neu entwickelt werden, sondern die
Wiederverwendung von Code erwies sich als kostensparend.
Das Verfahren reduziert den Aktualisierungs­ und Pflege­
Aufwand der Entwickler und beschleunigt die Entwicklungszyklen
beträchtlich – ein Prinzip, das bis heute Hardwareund
Software­Entwicklungen erst wirtschaftlich macht.
Die Gründung von Internet-Forum und Benutzergruppen
Die Abkürzung ADSM ist heute noch ein weitverbreitetes
Synonym für Tivoli Storage Manager und man entdeckt
immer wieder Bereiche im Umfeld von TSM, in denen diese
alte Produktbezeichnung noch benutzt wird.
So z. B. im bekannten ADSM­L Internet User­Forum
(www.adsm.org), das zu Beginn der 90er­Jahre vor allem
aus der großen Benutzergruppe der Universitäten heraus
gegründet wurde und bis heute als Wissensdatenbank und
Kommunikationsplattform für alle ADSM/TSM­Interessierten
im Internet gepflegt wird. In dieser Zeit (1994) begannen
sich auch in Deutschland Benutzergruppen zu bilden wie
der GSE­Arbeitskreis „Storagemanagement“ (www.gsenet.
de), in den Anfängen geleitet vom Chairman Franz­Xaver
Maier und seit 2003 aktiv gelebt von seinem Nachfolger
Gerd Becker (IBM Geschäftspartner Empalis). Hier treffen
sich in Deutschland zweimal im Jahr an drei aufeinander
folgenden Tagen interessierte Kunden bei Vorträgen und
Erfahrungsaustausch zu den Themen Mainframe Storage,
Open System Storage und TSM.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 187

IBM Storage Software
Tivoli Storage Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke
Der erste ADSM Large European Sites (ALES) Workshop
wurde 1994 in Karlsruhe abgehalten, initiiert durch die
Universitäten Karlsruhe und Heidelberg, namentlich Prof.
Dr. Gerhard Schneider, Klaus Dilper und Rolf Bogus, ein
Erfahrungsaustausch von großen europäischen ADSM­
Benutzern aus dem universitären, wissenschaftlichen und
kommerziellen Kundenkreis. In der Folge entstand daraus
das seither alle zwei Jahre stattfindende TSM Symposium
(Karlsruhe 1994–1998, Oxford 1999–2007 – Initiator
Sheelagh Treweek, Königswinter/Petersberg 2009 – Initiator
Claus Kalle, Uni Köln) mit mehr als 200 internationalen
Teilnehmern und Sprechern aus dem Teilnehmerkreis, von
Geschäftspartnern, Software­Herstellern und aktiver personeller
Unterstützung durch die TSM­Labors (u. a. Paul
Bradshaw, Andy Raibeck und ab 1999 Dave Cannon).
•
•
•
•
•
•
•
•
•
März 1994 – 1. ALES Workshop Karlsruhe
April 1996 – 2. ADSM Workshop Karlsruhe
September 1998 – 3. ADSM Workshop Karlsruhe
September 1999 – ADSM Symposium Oxford:
Meeting the Challenge
September 2001 – TSM Symposium Oxford:
Managing The Impossible
September 2003 – TSM Symposium Oxford:
A New Perspective
September 2005 – TSM Symposium Oxford:
Facing The Future
September 2007 – TSM Symposium Oxford:
Preparing The Path
September 2009 – TSM Symposium Köln/Petersberg:
Experience The Challenge
ADSM-Server auf weiteren Open-System-Plattformen – V2.1 1995
CW-Artikel (Auszug) vom 31.3.1995 zur Ankündigung von ADSM V2.1
(Quelle: http://www.computerwoche.de/heftarchiv/1995/13/1113172/)
Durch die Verwendung von „common code“ wurde
ADSM V2.1 im Laufe eines Jahres bis November 1996 um
die Server­Plattform OS/400, VSE und um eine Reihe von
Client­ und Anwendungsplattformen erweitert.
Hewlett-Packard HP-UX 10.01
SunOS und Sun Solaris
Windows NT and Windows 95
Apple Macintosh Windows 32-bit client
NCR UNIX SVR4 3.0 und NCR EWS-UX/V
Bull DPX/2 und Bull AIX
Digital UNIX
Siemens Nixdorf SINIX 386/486 und SINIX RISC
SCO UNIX386 und SCO Open Desktop
Sequent PTX
Silicon Graphics IRIX
Pyramid Nile (via SINIX RISC)
Open Edition MVS
AS/400 API-Client für BRMS
Lotus Notes 4.1
HSM-Client für AIX und Solaris 2.5
Cray UNICOS und Fujitsu UXP als Service Offering
188 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•

ADSM V2.1 Win 95 Client GUI und Logo
Der „Lotus Notes Backup Agent“ war die erste reguläre
Produkterweiterung (im Gegensatz zu optionalen Service­
Angeboten wie Backint/ADSM) für die Online­Anwendungssicherung
im ADSM. Sie eröffnete die Möglichkeit, konsistente
Online­Backups zu erstellen und zudem das Verfahren von
„incremental forever“ für Notes­Dokumente anzuwenden.
Dieses Verfahren hatte den Vorteil für die Notes­Benutzer,
auch einzelne Mails oder Anhänge sichern und rekonstruieren
zu können, litt allerdings unter dem Nachteil von schlechtem
Durchsatz und starker Belastung für die ADSM­Datenbank,
weil jedes gespeicherte Dokument auch einen Meta­Daten­
Eintrag erzeugte. Die spätere Datenbank­orientierte Architektur
von Lotus Domino ab V5 hatte diese „single object
backup“­Schnittstelle nicht mehr und der ADSM­Agent
wurde entsprechend angepasst.
Weitere funktionale Neuerungen von ADSM V2.1 waren
unter anderem:
•
•
die Bereitstellung des „Disaster Recovery Managers“ für
die Automatisierung von Disaster Recovery Vorsorgemaßnahmen
und einem strukturierten Verfahren für die Statusverfolgung
der Auslagerungs-Bänder (offsite vault
management)
die automatisierte Erzeugung von ADSM-Datenbank-
Backups und Storage-Pool-Backups (Copypool)
•
•
•
•
Erweiterung des Scheduling-Verfahrens mit pre- und
post-processing Optionen und die Unterstützung von
Admin-Befehlen im Scheduler
HSM-Clients für das Kapazitätsmanagement von
UNIX-File-Systemen (HSM-Client für AIX V3.2/V4.1 und
Solaris 2.5)
Erweiterungen des ADSM-API-Clients um die Funktionen
„Partial Object Retrieve“ und die Bereitstellung eines
OS/400 API-Clients
Ankündigung der Verfügbarkeit eines Oracle/EBU-Clients
für Ende 1996
In dieser Zeit erschienen auch die ersten komplementären
Produkte mit ADSM­Anbindungen auf dem Markt, die zum
Teil im Rahmen von Reseller­Verträgen durch die IBM
weiterverkauft wurden oder wo es mit den Herstellern Entwicklungspartnerschaften
gab.
• IBM Personally Safe’n Sound – IBM Datensicherungslösung
für OS/2-Server für den Anschluss lokaler Speicherressourcen
oder der optionalen Anbindung an den
ADSM-Server.
• DataTools „SQL BackTrack“ – November 1994 (Datatools
wurde 1997 von BMC übernommen), eine Sicherungssoftware
für verschiedenste relationale Datenbanken
(DB2, Oracle, Sybase, Informix etc.) mit dem Alleinstellungsmerkmal
der OBSI-Schnittstelle, die es erlaubt, alle
Schnittstellen-kompatiblen Datensicherungsanwendungen
als Backend verwenden zu können, ohne den Backup-
Code in der Anwendung austauschen zu müssen.
• Avail Systems „Netspace for Netware“ (Avail wurde
1995 von Wang Laboratories Inc. übernommen, das
Produkt später von Kodak vertrieben) – eine HSM-Lösung
für Novell Netware Server.
• ETI Backhome! – Backup Integration für Tandem Guardian
Hochverfügbarkeitslösungen
• Core Data Inc. „Remoteworx“ (Core Data wurde 1999
von Sterling übernommen) – eine Datensicherungslösung
für Desktop und Laptop-Benutzer mit Windows95 und
WindowsNT als Betriebssystem
• Storage Solution Spezialist Inc. SSSI –
„ABC OpenVMS Client“ für ADSM
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 189

IBM Storage Software
Tivoli Storage Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke
• Seagate „Backup Exec“ (vormals Conner Storage
Systems – Seagate wurde 2000 von Veritas übernommen) –
Datensicherungssoftware für kleine und mittlere Umgebungen
mit einer ADSM-Schnittstelle für die Nutzung der
hierarchischen ADSM-Speicherpools als Alternative zu
direkt angeschlossenen Bandlaufwerken.
• EMASS/Grau – Anschluss-Schnittstelle für AML/S, AML/E,
AML/2 Tape-Libraries über das ADSM External Library
Management API.
• Sterling SAMS Vantage DP – Reporting-Werkzeug für
ADSM-Umgebungen (Sterling wurde 2000 von CA
übernommen)
Es ist bemerkenswert, dass man bei entsprechender
Recherche im Internet heute noch Anzeigen zu ADSM V2.1
findet, wie die Abbildung „Resultat aus einer Internetsuche
2009 nach dem Stichwort ADSTAR“ zeigt. Es muss allerdings
bezweifelt werden, ob das Produkt unter dieser Quelle
wirklich noch käuflich ist.
Resultat aus einer Internetsuche 2009 nach dem Stichwort „ADSTAR“
SAP R/3 Integration – eine Erfolgsgeschichte aus dem
IBM Labor Böblingen
Einen besonderen Stellenwert beim Erfolg von ADSM
hatte die frühe Anbindung an die von SAP entwickelte
„Backint­Schnittstelle“. Die SAP­Entwickler erachteten diese
Schnittstelle deshalb für notwendig, weil die integrierten
Backup­Funktionen der Oracle­Datenbank zu dieser Zeit
nicht ausreichend waren zum Erstellen von konsistenten
Online­Backups und die Anforderungen eine enge Verknüpfung
von Backup mit den SAP­spezifischen Management­
Werkzeugen vorsah. Das IBM Labor Böblingen hatte durch
die geografische Nähe zur SAP­Entwicklung in Walldorf
einen strategischen Vorteil für diese Implementierung, weil
für die Pflege einer solchen Integration kontinuierliche
Absprachen und Tests mit dem Anwendungshersteller nötig
sind. Neben der „Backint“­Schnittstelle wurden auch weitere
SAP­Schnittstellen wie „Adint“ (ADABAS­D/MaxDB Datenbank)
und die „Archint“­ oder „ArchiveLink“­Schnittstelle
(IBM CommonStore for SAP) im Böblinger Labor aufgegriffen
und in Kombinationsprodukte zu ADSM integriert.
190 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Hier eine kurze tabellarische Backint/ADSM­Produkthistorie
der Anfangszeit:
•
•
•
•
•
•
•
•
•
•
Die Idee für Backint/ADSM entstand im Sommer 1993
aufgrund zahlreicher Kundenanfragen.
September 1993 Meeting mit SAP – Backint-Schnittstelle
Markteinführung als Service Offering 1994 – V1: Aufruf
der ADSM-Funktionen durch commandline – dmsc calls,
AIX, Oracle
Erste Kundeninstallation April 1994 – ca. 10 Kunden
bis Ende 1994
Erweiterungen 1995 und 1996 – parallele Sessions,
Portierung auf andere Betriebssysteme (DEC, HP, SNI,
SUN), erster Kunde in USA auf HP-UX
Backint/ADSM V2 – API-Schnittstelle zu ADSM als Ersatz
der CmdLine-Implementierung 1996 und Windows/NT
Support
Erweiterungen 1997–1999 – Multithreading,
parallel/alternate Paths und Servers
Weltweit ca. 3000 Kunden Ende 1999
Jahr 2000 Transfer zu Tivoli und Ankündigung als Mitglied
der TSM-Produktfamilie als Tivoli Data Protection for
SAP R/3, Administration Tools
V3 – Objektorientierte Implementierung mit modularem
Aufbau, „common code“ für Oracle und DB2, Support
für DB2, Administration Assistant
Medienkollektion (3,5“ Diskette, 8 mm Bandkassette, CD, Handbuch) zu
Backint/ADSM, TDP for SAP R/3 und TDP for Hardware aus verschiedenen
Jahren
Untypisch für die sonstige ADSM­Produktstruktur war
die Tatsache, dass das Backint/ADSM­Angebot für SAP R/3
zwar eine Schlüssellösung war, aber bis 1999 nur als
Service­Offering angeboten wurde. Grund dafür war möglicherweise
die Tatsache, dass SAP R/3 anfangs nur auf
dem europäischen Markt erfolgreich war. Es ist der Kreativität
der Entwickler und dem Marktengagement des Entwicklungsteams
zu danken, dass dieses Modul zu den wichtigsten
und wirtschaftlich erfolgreichsten ADSM/TSM­Komponenten
insgesamt wurde. Im Jahr 2000 wurde das Modul ein formales
IBM Tivoli­Produkt und die Böblinger Abteilung eine offizielle
TSM­Entwicklungslokation.
Oktober 1997 ADSM V3.1 –
Erweiterungen für den unternehmensweiten Einsatz
ADSM V3.1 Startbildschirm
Die Version V3.1 von ADSM brachte die größte Menge
an substanziellen funktionalen Neuerungen in der
TSM­Geschichte:
•
•
•
ADSM-Server auf Windows/NT und HP-UX V3.1
HSM-Client für Solaris V2.5.1 mit Veritas-Filesystem und
SGI IRIX mit XFS-Filesystem (Integration über die 1997
veröffentlichte X/Open DMAPI-Schnittstelle)
Bereitstellung der Backup-GUI auch für UNIX-Plattformen
basierend auf der „Motiv“-Anwendungsarchitektur,
grafischer Editor für die Options-Datei, „estimate“-Funktion,
Fortschritts-Balken für Backup/Restore, Such- und
Filteroptionen
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 191

IBM Storage Software
Tivoli Storage Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
„point-in-time restore“-Option für die Clients
„no-query-restore“-Protokoll, bei dem der ADSM-Server
und nicht der Client die optimierte Zusammenstellung der
zu restaurierenden Daten vornimmt
„small file aggregation“ und „server file aggregation“ – die
Zusammenfassung von kleinen Dateien in Transaktionsgruppen
und das Speichern in logischen Aggregaten
„Restartable Restores“ – Wiederaufsetzen auf der letzten
„uncommitted transaction“
Der Ersatz der generischen Admin-GUIs durch den Web-
Admin-Client, was zur Oberflächenvereinheitlichung führte
Web-Client als Alternative zur generischen Client-GUI –
damit auch die Verfügbarkeit einer GUI für Netware-Clients
und die Unterstützung von zentralen Help-Desks
SQL-SELECT-Abfragen gegen die Datenbank (SQL’95
Befehlssatz) und ODBC-Schnittstelle
Erweiterung des ADSM-Schedulers zur Definition von
einmaligen Aktionsplänen oder dem Ausführen von
Betriebssystem-Befehlen
„migdelay“ und „migcontinue“ für die planbare Migration
von Daten auf verketteten Storagepools
„Space trigger“ für die automatische Erweiterung von
DB- und Log-Volumes der ADSM-Datenbank
Speicherung von Scripts und Macros in der ADSM-
Datenbank und Bereitstellung des „run“-Befehls zur
Ausführung von Makros
„Client Option-Sets“ zur Vereinheitlichung und zentralem
Management von Client-Konfigurationen
Server-to-Server-Kommunikation – Bereitstellung des
„ADSM Configuration Managers“ zur einheitlichen
Script-, Policy-, Schedule-Verwaltung zwischen multiplen
ADSM-Servern und der Möglichkeit, „virtual volumes“ auf
einem entfernten ADSM-Server zu definieren (Peer-to-Peer
Disaster Protection Szenarien)
„Overflow Storagepool“ und „single-drive reclamation“
für Konfigurationen mit nur einem Magnetbandlaufwerk
Event Logging, Reporting und Monitoring mit Schnittstellen
u. a. zu SNMP-Managern, Tivoli NetView und Netview/MVS
ADSMConnect Agents für:
- DB2 für AIX, HP/UX, SINIX, Solaris, OS/2, Windows NT
- Informix for AIX, HP/UX, Solaris
- Lotus Notes für OS/2 und AIX
- OnDemand für AIX
Oracle 7 (EBU) und Oracle 8 (RMAN) für AIX und Solaris
192 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
-
-
-
-
SAP mit Oracle für AIX, Digital UNIX, HP/UX, NCR UNIX,
SINIX, Solaris, Windows NT auf Basis der Backint-
Schnittstelle
SAP mit ADABAS-D für AIX, HP/UX, SINIX, Solaris,
Windows NT auf Basis der Adint-Schnittstelle
(Service-Offering)
MS-Exchange
Die Breite der funktionalen Neuerungen und die Bereitstellung
zukunftsweisender Technologien und Verfahren katapultierte
IBM mit dem ADSM V3.1­Produktportfolio in die
Königsklasse der Datenmanagement­Anwendungen, was
der Markt und die Analysten auch entsprechend honorierten.
Synergie durch neue Kombinationen aus IBM
Speicher-Hardware und ADSM
Auszug aus einer internen Laudatio (1997) für „Outstanding
Acomplishments“ in der IBM Storage Systems Division:
…A major new release of ADSM (Version 3) was made generally
available in October 1997, with Research contributions that
include a Web administrative interface, support for SQL queries
of its internal database, point-in-time restore, and improved
archive file management. In addition to its sales as a separate
product, ADSM is a key building block in SSD‘s Network
Storage Manager and Virtual Tape Server offerings,
which are integrated hardware and software solutions.
Die interessante Nachricht aus dieser Ehrung ist der Hinweis,
dass die kurz zuvor begonnene „Seascape Storage
Building Block“­Initiative der IBM Storage Systems Division
(die Wiederverwendung von bewährten IBM Komponenten
als Entwicklungsbasis für komplexe Subsysteme) auch auf
die Software ADSM ausgedehnt wurde. Aus dieser Initiative
entstanden in der Folge erfolgreiche Kombinationsprodukte
mit ADSM wie der IBM 3494 Virtual Tape Server (VTS), der
IBM 3466 Network Storage Manager (NSM) und der IBM
3466 WebCache Manager (WCM). Parallel dazu gab es
Kooperationen mit der IBM Softwaregroup in Form der
Integration von ADSM mit IBM ContentManager, Content­
Manager OnDemand und IBM CommonStore als komplette
ECM­Lösung auf Open Systems.

• IBM 3494 Virtual Tape Server (die Hardware-Spezifi-
kationen sind im Hardware-Kapitel „Die Epoche der RAID-
Systeme“ beschrieben) – der VTS war die Realisierung
einer großen Menge von virtuellen Bandlaufwerken und
virtuellen Bandkassetten und wurde auf Basis einer
mo difizierten AIX ADSM-Server/HSM-Client-Lösung in der
B16-Kontrolleinheit implementiert. Nach außen repräsentierten
sich 3490 Laufwerke und die 3490 virtuellen
Volumes (typ. 800 MB) und wurden nach Füllung mit Hilfe
der ADSM/HSM-Funktionen auf physische Laufwerke der
IBM Library 3494 heraus migriert. Über das „Open System
Attachment Feature“ konnten auch ADSM-Server auf
Open-System-Plattformen die Funktionen des VTS nutzen.
Diese Lösung wurde jedoch seltener verwendet, weil im
Open-System Umfeld der ADSM-Server seine ganzen
Stärken zur Verwaltung der Speichermedien erst ausspielt,
wenn er der alleinige Verwalter aller Speichereinheiten ist.
Dieser Vorbehalt gilt heute grundsätzlich auch noch für
solche Open System VTLs, die intern transparente
Migration auf physische Laufwerke implementiert haben.
• IBM 3466 Network Storage Manager (April 1998) –
die „ADSM-in-the-box“-Lösung – heute würde man sie als
„Appliance“ bezeichnen – war ein fertig vorkonfigurierter
ADSM-Server auf Basis einer RS6000/H50 mit Diskpool auf
SSA-Platten, die entweder als JBOD (bis zu 814 GB) oder
im RAID5-Modus (bis zu 610 GB) vorkonfiguriert angeliefert
wurde und nach der Hardware-Installation schon in
kurzer Zeit die ersten Datensicherungen prozessieren
VTS mit Open System Attachment Feature und nativen Anschlüssen an die 3494
IBM 3466 Network Storage Manager
konnte. Das erste Modell A00 hatte SCSI-Adapter integriert,
an die man externe Tape-Libraries anschließen
konnte, Modell A01 hatte eine eingebaute Library (entweder
DLT oder Magstar MP 3570) und Modell B01 wurde
mit IBM 3494/3590 geliefert. Nachfolgemodelle mit geänderten
Technologiekomponenten hatten die Bezeichnungen
C00, C10, C20, C30.
• IBM 3466 WebCache Manager (September 1998) – diese
Lösung war eine faszinierende Modifikation des NSM, die
für die Spezialaufgabe als Internet Filetransfer Ressource
konzipiert war. Filetransfer-Dienstleistungen über Webserver
waren in dieser Zeit schon sehr gefragt, oftmals waren
aber die Bandbreiten der öffentlichen Netzwerke zu den
Web-Servern beschränkt (ISDN-Geschwindigkeit) und
Online-Plattenspeicher war teuer.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 193

IBM Storage Software
Tivoli Storage Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke
Der WebCache Manager bestand – wie der NSM – aus
einem RS6000/H50 Rechner mit ADSM-Server auf AIX,
einem internen SSA-Plattenspeicher, dessen Dateisystem
von einem AIX/HSM-Client verwaltet wurde und einer IBM
3494/3590 Bandlibrary.
In der HSM-Implementierung von ADSM werden Stub-Files
verwendet als Stellvertreter für die physisch migrierten
Dateien. Üblicherweise sind die Stub-Files so groß wie ein
Block des Dateisystems (4 k). Beim WCM änderte man
diese Blockgröße auf einen Wert von 256 kB und größer.
Falls nun ein Filetransfer einer sehr großen Datei über das
Internet (ISDN) angefordert wurde, konnte sofort mit der
Übertragung begonnen werden und der HSM-Agent
begann im Hintergrund den Rest der Datei von Band nachzuladen.
Das Nachladen geschah schneller, als die Stub-
Datei zum Nutzer übertragen wurde, was dem Benutzer
die Illusion vermittelte, jede noch so große Datei in unmittelbarem
Zugriff zu haben.
Den wirtschaftlichen Vorteil dieser Lösung beschreibt ein
Auszug aus einem Artikel aus MONITOR Online 2/99 vom
Kunden Deutsche Telekom AG (Quelle: http://www.monitor.
co.at/index.cfm/storyid/101):
… Der neue IBM 3466 Web Cache Manager ist Teil der von IBM
entwickelten Seascape-Speicherarchitektur und stellt eine Kombination
aus führenden Speichertechnologien dar. Zu einer
Gesamtlösung integriert wurden ein leistungsfähiger Speicher-
Server, Platten- und Bandspeichermedien sowie die entsprechende
Speichermanagement-Software. Durch eine einmalige
Kombination aus hierarchisch eingesetzten Band- und Plattenspeichermedien
bietet das Produkt mit bis zu zwei Terabyte ein
Vielfaches der Speicherkapazität herkömmlicher Web-Proxies
und kann auch sehr große Seiten und Dateien mit 10 MB und
mehr zwischenspeichern. Da die Seiten und Dateien lokal vorgehalten
werden, leistet der Web Cache Manager einen wichtigen
Beitrag zur Verbesserung der Antwortzeiten im Internet […].
[…] Unsere aktuellen Tests haben ergeben, dass wir mit dem
Web Cache Manager mehr als die Hälfte des Web-Traffics in
Bytes sparen können. Im Gegensatz zu anderen Web-Proxies
arbeitet der Web Cache Manager mit einer Hierarchie zweier
Speichermedien, die deutliche Kostenreduktionen auf der Hardware-Seite
ermöglicht. Eingesetzt werden SSA-Platten (Serial
Storage Architecture) und Magstar-Bänder. Diese Wahlmöglichkeit
für die Speicherung von Daten bietet ISPs das bestmögliche
Preis-Leistungs-Verhältnis und den größten derzeit erhältlichen
Cache. Bandspeicher sind um das Fünf- bis Zehnfache preiswerter
als Plattenspeicher und damit der kosteneffizienteste Weg,
größere Web-Objekte mit einem Megabyte oder mehr zu speichern
– denn rund 50 Prozent des Web-Verkehrs besteht mittlerweile aus
Inhalten dieser Größenordnung…
IBM ContentManager, ContentManager OnDemand,
Commonstore, Admira – die effizienten Medienverwaltungs-Funktionen
von ADSM wurden ab Mitte der 90er-
Jahre auch als Backend für die IBM Archivanwendungen
auf Open Systems eingesetzt. Dazu wurde der ADSM-API
Client verwendet, der Grundlage für alle Anwendungsintegrationen
ist. In dieser Zeit wurden als Backendspeicher
für ECM-Archivlösungen bevorzugt optische Medien mit
WORM-Funktionen am ADSM-Server verwendet (z. B.
IBM 3995).
194 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
•

1999–2002: Aus ADSM wird Tivoli ADSM und schließlich
Tivoli Storage Manager
Im März 1996 übernahm IBM den Systems­Management­
Entwickler Tivoli Software Inc. Diese Übernahme hatte
Folgen für die weitere Produktheimat von ADSM innerhalb
der IBM. Im Zeitraum Januar bis Oktober 1999 wurde Vertrieb,
Marketing und Entwicklung des Produktes in die Verantwortung
des Unternehmensbereichs IBM Tivoli übertragen und
das Produkt zuerst in IBM Tivoli ADSM umbenannt (Januar
1999). Im September 1999 erschien das Produkt dann als
Tivoli Storage Manager Version 3.7 unter neuem Namen
und das Safeman­Logo veränderte sich.
ADSM Safeman im Tivoli-Look
Auszug aus der Presseankündigung zur Übertragung der
Marketing­ und Vertriebsverantwortung für ADSM von der
IBM Storage Systems Division zu IBM Tivoli Systems:
Tivoli Systems Announces Next-Generation Applications
Management Storage Product Line
Customers Gain ADSM Enhanced Benefits for Storage
Management
SAN JOSE, Calif. – Dec. 2, 1998 – Tivoli Systems Inc. and IBM’s
Storage Systems Division (SSD), both part of the IBM
company, announced today the transfer of ADSTAR Distributed
Storage Manager (ADSM) to Tivoli. Responsibilities for the
industry leading cross-platform application and data storage
management solution will be transferred to Tivoli, effective
January 1, 1999.
With the transfer, customers will gain a broader, more tightly
integrated application and data management solution for their
enterprise storage management needs. The move is also designed
to significantly increase IBM’s share of the growing distributed
storage management market by combining the strength and
technology of two of IBM’s most successful divisions. ADSM will
also provide customers with next-generation application-centric
storage management solutions, supporting more platforms and
operating systems than any other product available on the
market today.
Today’s announcement underscores the importance of this new
Tivoli business segment. The company plans to further enhance
its enterprise solutions with significant investments in integrated
storage solutions spanning mainframes to notebooks. Plans
include additional investment in cross-platform storage area
networks (SANs) and application-centric solutions.
Die Versionen V3.7 (September 1999) und V4.1 (Juli 2000)
folgten schnell aufeinander. Die „krumme“ Versionsnummer
3.7 war vor allem verursacht durch die Namensänderung
von Tivoli ADSM nach Tivoli Storage Manager, zusätzlich
brachten diese Versionen einige wichtige funktionale Erweiterungen
zur Version 3.1. Erwähnenswert ist vor allem der
Einstieg in die Welt der Storage Area Networks durch die
Bereitstellung von Tape Library Sharing, LAN­free­Datentransfer
und die SAN Datasharing­Optionen, die man
durch die Sanergy­Produkt akquisition von der Firma
Mercury Computer Systems erhielt.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 195

IBM Storage Software
Tivoli Storage Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke
Tivoli Storage Manager V3.7 – neuer Name und neues Logo bis V4.2
•
•
•
Verbesserungen im TSM-Server V3.7:
-
-
-
-
-
-
No-Log Database Load & Audit
Snapshot database backup
SAN Tape Library Sharing zwischen TSM-Server Syste-
men AIX, Windows 2000 und Solaris unter Verwendung
von SAN Data Gateways für SCSI Libraries
Secure Web Admin Proxy
Einführung der Backupsets (Instant Archive und Rapid
Restore)
Windows 2000 mit Cluster-Support
Verbesserungen bei den TSM-Clients V3.7:
-
-
-
-
-
-
Subfile Backup für Windows-Clients
Multi-Session Client (multithreaded backup)
Windows 2000-Support mit Unterstützung von
Cluster, System Objects, Active Directory, Journaling,
Encryption, DFS
Linux Clients auf Redhat, Suse, Caldera und TurboLinux
LAN-free Client Transfer für den TSM API-Client
(Application LAN-free)
Client Encryption DES 56-bit
Neue Produkte und Namensänderungen:
-
Umbenennung der ADSMConnect Agents in Tivoli
Data Protection for …
- Umbenennung der TSM/HSM UNIX Clients in Tivoli
Space Manager
- Tivoli Data Protection for IBM ESS und EMC
Symmetrix für Oracle und SAP/Oracle
- Anbindung an Tivoli Decision Support for Storage
Management Analysis (12/99) – Reporting und Analyse
von TSM-Server-Operationen
- Tivoli SANergy Filesharing (04/00) – LAN-free-to-disk
Backup-Technologie als Resultat aus der Übernahme
der „Shared Storage Unit“ von Mercury Computer
Systems
- Tivoli Removable Media Manager (07/00)
- Tivoli Data Protection for Workgroups (TDPfW) –
Bare Machine Recovery für Windows NT, Windows 2000
und Netware durch Entwicklungspartnerschaft (Juni
1999) mit STAC Software über die Verwendung des
STAC/Replica Moduls.
- Tivoli Plus Module für TSM und TDPfW zur Integration
in das Tivoli Framework (Reporting, Monitoring,
Software-Verteilung)
Die Wende vom 20. zum 21. Jahrhundert war in der
Speichertechnologie gekennzeichnet durch die Einführung
der FibreChannel Storage Area Networks für die offenen
Systeme mit großen Konsequenzen hinsichtlich der
„Sozialisierung“ von Ressourcen und der Basis für die
heute gängigen Speichervirtualisierungstechniken. Die
bewusst konservative Herangehensweise der TSM­Entwickler
bei der Integration dieser – für Open Systems – neuen
Technologie wurde entsprechend kritisch von der den Markt
begleitenden Presse kommentiert.
CW-Artikel (Auszüge) vom 17.9.1999 zur TSM V3.7-Ankündigung
(Quelle: http://www.computerwoche.de/heftarchiv/1999/37/1088572/)
196 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Integration von ADSM in das Tivoli TME10 Framework über PLUS-Module
Der Seitenhieb des Artikels über „ADSM als Beigabe zu
Bandlaufwerken“ war bezeichnend für den Zeitgeist, da der
Redakteur komplette Infrastruktur­Lösungen offensichtlich
nicht als erstrebenswertes Ziel für Unternehmen bewertete.
Die IBM gewann allerdings mit diesen Kombinationsangeboten
aus Hardware, Software und Services stetig Marktanteile
hinzu. Diese Lösungen sind abgestimmt und getestet
und bieten den Kunden Unterstützung im Fehlerfall aus
einer Hand.
Die behutsame Herangehensweise bei der Implementierung
von SAN­Techniken im TSM wie Library­Sharing und LANfree
Backup erwies sich als berechtigt, weil der Weg hin zu
zuverlässigen SAN­Umgebungen durch die fehlende Kompatibilität
von Infrastrukturkomponenten und Protokollen holperig
war. Zudem waren die für das Verwalten und Überwachen
von Storage Area Networks erforderlichen
Managementfunktionen nur rudimentär verfügbar. Die
notwendige Standardisierung (Bluefin, SMI­S) wurde durch
konkurrierende Standardisierungs­Konsortien (FibreChannel
Association, SNIA etc.) anfangs eher behindert als
beschleunigt.
Für TSM bedeuteten die neuen Möglichkeiten der Storage
Area Networks einen Quantensprung in der Realisierung
von verteilten Backup­Instanzen und Disaster­Protection­
Lösungen. Allerdings beinhalteten manche Werbeaussagen
zu SAN auch Heilsversprechen, die diese Technologie nicht
einlösen konnte:
„Ihr LAN-Backup dauert heute 8 Stunden, mit LAN-free wird
er 2 Stunden dauern und mit Server-free sind Sie nach 20
Minuten fertig.“ (Originalton aus einer Marketing-Veranstaltung
dieser Zeit).
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 197

IBM Storage Software
Tivoli Storage Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke
Nicht ganz ernst gemeinte Abschlussfolie eines TSM4.1 Vortrags
Die Sicherungsmethoden LAN­free und Server­free waren
die beherrschenden Themen in dieser Zeit. Wie bei Modethemen
üblich, wurde in Veröffentlichungen häufig eher
plakativ als präzise mit den Einsatzmöglichkeiten der neuen
Technologien umgegangen.
Der am häufigsten beworbene Server­free­Ansatz war die
Umsetzung des 1996 entwickelten SCSI3 T10 extended
copy/3rd party copy Standards (auch unter SNIA 143R1
standardisiert).
Hier war definiert, wie man innerhalb von SAN­Infrastruktur­
komponenten (z. B. SAN Data Gateways erweitert um
Microcode­Funktionen) eine „data mover“­Instanz abbilden
konnte, die in der Lage war, Daten im SAN direkt von Disk
nach Tape zu kopieren, ohne den „zeitraubenden“ Umweg
über den Applikations­Server nehmen zu müssen.
Diese Lösung war nur realisierbar durch Einhaltung einer
Reihe von Rahmenbedingungen und setzte eine Kette T10kompatibler
und getesteter Hardware­ und Software­Komponenten
voraus. Die Anzahl der Hersteller für „data mover“
Instanzen (SAN Data Gateways) war begrenzt u. a. mit den
Herstellern Pathlight und Crossroads. Es fehlte zudem
die Möglichkeit, mit diesem Verfahren Einzeldateien zu
sichern oder zu rekonstruieren, weil der Kopiervorgang eine
Volume Block­Level Operation war. Die notwendige Öffnung
der Filesystem­Hersteller blieb aus, die nötig gewesen wäre,
um über standardisierte API­Schnittstellen die logischen
Dateien auf die physischen Blöcke abbilden zu können
(LBM = Logical Block Mapping List). Für Volume­Dumps
brauchte man die LBMs nicht. Legato unternahm mit dem
Produkt Celestra einen Versuch, dies selbst über Re­engineering­Verfahren
umzusetzen, scheiterte dann aber mittelfristig
am notwendigen Pflegeaufwand durch mangelhaft
publizierte Änderungen der Filesystem­Hersteller. Andere
Ansätze wie die Vertex­Initiative von Veritas versuchten
das Problem auf der Basis ihres eigenen proprietären
Volume Managers bzw. Filesystems zu lösen.
Das Thema SCSI3 T10 beschäftigte die IT­Welt einige Jahre
und war offensichtlich für die Marktpräsenz so wichtig, dass
TSM mit der Version V5.1. eine entsprechende Implementierung
für Windows 2000­Client, IBM SAN Data Gateway 2108
(Pathlight) und TSM­Server auf Windows 2000 verfügbar
machte (das TSM Demo­Highlight auf der CeBIT 2002).
Heute definieren sich „Application Server­free“­Lösungen
über andere technische Möglichkeiten, wobei nach wie vor
das Prinzip von „workload offloading“ das Herz des Verfahrens
ist, wie z. B. das „Copy Backup“­Verfahren Disk­to­Disk
über die Snapshot­Funktionen von Betriebssystemen, Filesystemen,
Plattensubsystemen oder Proxy­Lösungen wie
VMware Consolidated Backup.
Kritisch bei allen Online­Backup­Lösungen, die über Ersatzinstanzen
arbeiten (Server­free und Copy Backup), ist die
notwendige Anwendungsintegration zur Sicherstellung von
Datenkonsistenz beim Backup. Dies muss entweder über
Skript­basierte Verfahren geschehen oder über bereitgestellte
Betriebssystem­ oder Applikationsschnittstellen, z. B.
Microsoft Volume Shadowcopy Services oder SAP „Splitint“.
198 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Server-free Prozessfluss mit SCSI 3rd Party Copy (T10-Standard)
TSM V4.2 erschien im Juni 2001 mit den Neuerungen:
•
•
•
•
•
•
•
Die Erweiterung der LAN-free-Unterstützung für weitere
Plattformen und die Palette der TDP-Clients
Journal-based Backup für Windows-Clients
zLinux-Client, USS-Client (zOS Unix System Services)
Tivoli Data Protection for NDMP (filer-to-tape)
Tivoli Data Protection for Websphere Application Server
TSM Management Console als MMC Plugin
Unicode Support für Windows NT und 2000
Die Jahre 2000 bis 2003 waren gekennzeichnet durch eine
wachsende Anzahl von Entwicklungspartnerschaften und
Reseller­Abkommen zwischen IBM Tivoli mit unabhängigen
Softwarehäusern, die Komplementär­Software zu TSM entwickelt
hatten. Hier die wichtigsten Kooperationen und Produkte:
• „The Kernel Group“ (TKG) – Das „Bare Metal Restore“-
Produkt von TKG wurde als „Tivoli Bare Metal Recovery
Manager“ bzw. als „Tivoli Disaster Recovery for Servers“
ab 2000 von IBM weiterverkauft. Es handelte sich dabei
um Software, die die Anforderungen von Betriebssystem-
Rekonstruktion umsetzte und dabei auf den gesicherten
Daten des TSM-Servers aufsetzte. Unterstützt waren die
Betriebssysteme AIX, HP-UX, Solaris, Windows NT und
später Windows 2000 und Novell Netware. Im Januar 2002
wurde TKG von Veritas gekauft, der TSM-Support wurde
von Veritas im Juni 2003 gekündigt.
• Cristie PC-BaX und später Cristie Bare Machine
Re covery (CBMR) Juni 2003 – Die Partnerschaft und das
Produkt, das die Funktionslücke zur Betriebssystemrekonstruktion
im TSM-Portfolio wieder schloss und bis heute als
CBMR und TBMR (Tivoli Bare Machine Recovery – Rekonstruktion
von Betriebssystem allein durch Verwendung der
im TSM gespeicherten Daten) wichtiger Baustein einer
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 199

IBM Storage Software
Tivoli Storage Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke
ganzheitlichen Datensicherungsstrategie in der
TSM-Architektur ist für die Betriebssysteme Windows
2003/2008, Linux, Solaris und HP-UX.
• St. Bernhard Open File Manager (OFM) – Die Zusatzlösung,
die notwendig war, um Filesysteme (Windows, Netware)
oder Anwendungen aus Filesystemsicht (Exchange,
Groupwise etc.) konsistent online sichern zu können.
• Gresham Computing plc. Enterprise DistribuTape
(EDT) – vormals Open Microsystems (Übernahme durch
Gresham 1998) – Die Anbindung von ACSLS-Tape-Libraries
(StorageTek und andere) an das TSM External Library
Management (ELM) Interface. Der Reseller-Vertrag wurde
im Juni 2001 geschlossen.
• Open Technology Group (OTG) – DiskXtender – Die
Windows 2000 HSM-Lösung für TSM. Die Kooperation
zwischen IBM und OTG begann im Jahr 2000 und endete
im Dezember 2004, weil Legato im Juni 2002 OTG übernommen
hatte und zwischenzeitlich von EMC gekauft
worden war.
• Monitoring und Reporting-Lösungen für TSM-Umgebungen
– Servergraph Professional, JamoDat TSMManager,
STORServer Manager
TSM-Client für PalmOS in V4.2
(Prototyp – war nie ein offizielles Produkt)
2002–2008 TSM V5.x – die Ära von Server-Konsolidierung,
Virtualisierung und NAS
Ab der Version V5.1 wurde die Lizenzstruktur des TSM
geändert. Dazu wurden die vorher verwendeten Umgebungslizenzen
(Desktop Environment, Workstation Environment,
Extended Device Support Module) zugunsten eines
Prozessor­basierten Preismodells ersetzt. Dazu definierte
man zwei Basislizenzmodelle für eine TSM­Umgebung:
Tivoli Storage Manager mit Tape-Library bis zu 2 Bandlaufwerken
und 40 Kassetten
TSM Extended Edition für größere Konfigurationen inklusive
TSM Disaster Recovery Manager und NDMP Support als
Ersatz für die kostenpflichtigen Module Extended Device
Support, TDP for NDMP und DRM.
200 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
•
•
Die Versionen V5.1 (April 2002), V5.1.5 (Oktober 2002) und
V5.2 (Oktober 2003) erweiterten den TSM­Funktionsumfang
um folgende Schwerpunkte:
TSM V5.1 – April 2002
•
Server-free Data Movement auf Basis der SCSI3 T10 Proto-
kollimplementierung, Windows 2000-Client full-volume
Backup/Restore
• Simultaneous Writes to Copy Storage Pools – synchrones
Schreiben von Auslagerungskopien direkt beim Backup
• Multithreaded Restore – Restauration über mehrere parallele
Sessions, sofern der Backup auch multithreaded auf
unterschiedliche Backup-Volumes gespeichert war
• Windows 2000 Image Backup und Open File Backup mit
Hilfe des TSM Logical Volume Snapshot Agents (LVSA)
• ”MOVE NODEDATA“
zum selektiven Verschieben von
Sicherungsdaten eines Clients von einem Storagepool
zu einem anderen
• CRC (Cyclic Redundancy Check) – Quersummen-Prüfung
für TSM-Client und TSM-Server zur Sicherstellung von
konsistentem Datentransfer über Netzwerke (LAN, WAN
und SAN)

•
•
Image Backup für Filesystem und Raw-Devices von
AIX, HP-UX und Solaris
Neuorganisation der TSM Application Clients in:
- TSM for Databases (Oracle, MS-SQL, Informix)
- TSM for Mail (Exchange, Domino)
- TSM for ERP (SAP/Oracle und SAP/DB2)
- TSM for Application Servers (Websphere)
- TSM for Hardware (Copy Backup für Oracle, DB2
und SAP/Oracle, SAP/DB2)
TSM V5.1.5 – Oktober 2002
• Volle Linux/x86-Unterstützung inkl. TSM-Server, LAN-free,
NDMP und Domino-Client
• Server-to-Server Import/Export – die gravierende Vereinfachung
von Systemmigration und Teilungsprozessen der
TSM-Datenbank zur verbesserten horizontalen Skalierung
• Exchange Single Mailbox Restore über Skript-Integration
in das Xmerge-Utility von Microsoft
• TSM-Server auf OS/400 PASE
TSM V5.2 – Oktober 2003 und V5.2.2 – Dezember 2003
•
•
•
•
•
•
•
TSM-Server auf zLinux
TSM zOS LAN-free
Flashback-Funktionen für TSM for ERP/DB2 zusammen
mit TSM for Hardware
Verbesserte Firewall-Unterstützung (server initiated
sessions, single port communication)
SAN-Einheiten-Erkennung für Windows 2000 TSM-Server
NAS-Umgebungen: File-Level Restore durch NDMP Table
of Contents (TOC) und EMC Celerra-Support
Mixed-Media Libraries
•
•
•
•
TSM for System Backup and Recovery (Betriebssystemrekonstruktion
für AIX auf Basis der IBM Service-Lösung
Sysback6000)
Erweiterung der Aufbewahrungszeit für archivierte Daten
von 9.999 Tagen (ca. 27 Jahre) auf 30.000 Tage (ca. 83
Jahre) ohne Abhängigkeit zum Jahr-2038 Problem – auch
„The Friday 13th Bug“ genannt – (http://www.2038bug.
com/index.html).
Tivoli Storage Manager for Data Retention – die Software-
WORM-Variante des TSM für den Einsatz bei revisionssicherer
Archivierung
TSM-Unterstützung für EMC Centera und NetApp
Snaplock (TSM for DR)
Das TSM-Logo der Versionen V5.1 bis V5.3
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 201

IBM Storage Software
Tivoli Storage Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke
Tivoli Storage Manager for Data Retention und DR450/550
(Oktober 2003)
Mit TSM for Data Retention wurde eine spezielle Variante
des TSM bereitgestellt für die revisionssichere Archivierung
von Daten. Diese Software hat besondere Bedeutung auch
für die IBM Speicherlandschaft, weil sie Software­Basis ist
für die Archiv­Backend­Lösungen DR450, DR550 und IBM
Integrated Archive (Oktober 2009).
Hardwaredetails zur DR450/DR550 und eine Beschreibung
der rechtlichen Rahmenaspekte sind im HW­Kapitel „Die
Epoche der Multiplattform­Systeme und des FibreChannel
SAN und NAS“ ausführlich beschrieben.
Der Grund für die Entwicklung solcher Archiv­ Backendlösungen
war einerseits die mangelhafte Zukunftsperspektive
der optischen Speichermedien generell, die bis dahin
die maßgebliche Technologie für die gesetzeskonforme
Langzeitarchivierung waren, andererseits die verschärften
gesetzlichen Regularien, die nach einigen Fällen von Bilanzfälschung
vor allem in USA erlassen wurden (u. a. als
Antwort auf die ENRON/Worldcom­Pleite).
Die Faszination von TSM for Data Retention besteht in der
simplen Funktion, dass man unter seiner Kontrolle wieder
beschreibbare Datenträger (Magnetplatte, Magnetband) im
Software­WORM­Modus (write­once­read­many) betreiben
und zusätzlich neue physische WORM­Medien wie WORM­
Tapes (IBM 3592, LTO3 und LTO4) nutzen kann. WORM
bedeutet das Verhindern von Überschreiben und das
Sicherstellen von Löschen erst nach Ablauf vorgegebener
Sperrfristen.
Die Idee dazu entstand aus der Archiv­Funktion, die
TSM schon immer parallel zum Backup angeboten hat. Im
„Archiv“­Modus überschreibt TSM keine Daten, sondern
schreibt jedes Objekt neu, auch wenn das Objekt mit all seinem
Inhalt und Attributen schon einmal gespeichert wurde.
Gleichnamige Objekte unterscheiden sich über eine eindeutige
Objekt­Id und durch Datum/Uhrzeit der Speicherung
und sind darüber auch wieder eindeutig zugreifbar. Die
prinzipielle Arbeitsweise des „Archive­Mode“ entspricht also
der ersten Forderung von revisionssicherer Archivierung,
dem Verhindern von „Überschreiben“. Die zweite Kardinalforderung
ist die Sicherstellung von Löschoperationen nur
unter Kontrolle der steuernden Archivanwendung, die die
Sperrfristen vorgibt und steuert. Dazu wurde im TSM ein
zusätzliches „retention“­Verfahren implementiert, das es
ermöglicht, die traditionelle Verfallssteuerung des TSM
(„chronological retention“) alternativ durch eine von der
Archivanwendung kontrollierte mehrstufige Verfallssteuerung
zu ersetzen („event­based retention“ und „deletion hold/
release“). Der Löschschutz im TSM for Data Retention wird
zusätzlich durch Maßnahmen komplettiert, die es verhindern,
dass der TSM­Administrator Archivdatenträger löschen
oder die Bindung von Aufbewahrungsregeln an Objekte
verändern kann.
Schnittstelle für die Datenübergabe ins TSM for Data Retention
ist entweder der Archive­Client oder die Archivfunktion der
TSM­API­Schnittstelle ab V5.2.2, die im Laufe der folgenden
Jahre in eine Vielzahl von DMS­ und Archivanwendungen
innerhalb der IBM (IBM ContentManager, IBM Commonstore,
IBM Filenet und IBM Optim) und in Lösungen von
unabhängigen Softwarehäusern eingebaut wurde (u.a.
OpenText, SER, Saperion, d.velop, Easy, Ceyoniq, Waters,
PBS und viele andere).
Logo für die Tivoli-Schnittstellen-Zertifizierung von externen Anwendungen
Im Jahr 2005 wurde „Tivoli Storage Manager for Data
Retention“ in „IBM System Storage Archive Manager“
umbenannt, vor allem wegen des geänderten Lizenzierungsverfahrens
(TB­Lizenz auf Basis des verwalteten
Archivdatenbestandes).
202 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

TSM V5.3 wurde im Dezember 2004 verfügbar mit
folgenden wichtigen Neuerungen:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Einführung der Integrated Service Console als Resultat
einer allgemeinen Oberflächenkonsolidierung bei Tivoli-
Produkten für die grafische Administration
Erweiterungen für tagesgenaue Definitionen im TSM-
Scheduler
Multiple Prozesse bei Reclamation und Migration
Durchsatzverbesserungen im TSM File-Pool
Group-Collocation zur verbesserten Nutzung hochkapazitiver
Bandkassetten
Automatische SAN-Device Erkennung und Re-Konfi guration
Generische Unterstützung von ACSLS-Libraries ohne
externe Software
Segmentieren von NDMP-Backups, NDMP-Dumps
von Snapshots oder Quota-Trees bei NetApp NAS
Neue Verschlüsselungsmethode für Clients AES 128-bit
Einführung des Proxy-Node Supports für die Unterstützung
von virtualisierten System-Umgebungen
Windows Open File Support und online Image Support
über den TSM Logical Volume Snapshot Agent (LVSA)
Unterstützung von TSM-Clients in VMware-Gastsystemen
und Unterstützung des Linux B/A-Clients für die Sicherung
von ESX/GSX
Administration Assistant für TSM for mySAP
TSM HSM for Windows – als Resultat eine Firmenkooperation
mit der Intercope GmbH in Hamburg (OpenStore for
File Server OS4FS)
Mit der Version TSM 5.4 (Januar 2006) änderten sich die
zugesagten Wartungsintervalle pro Release von 3 Jahren
auf 5 Jahre, was solchen TSM­Kunden sehr entgegenkommt,
die Aufrüstungen längerfristig planen. Die
wichtigsten funktionalen Neuerungen:
•
•
•
Unterstützung von TS1120 Encryption und die Implementierung
des Encryption Managers im TSM für den Encryption-Modus
„application managed“
Implementierung der NDMP-Copy-Funktion zur Erstellung
von Kopien für NDMP-Dump-Tapes
NDMP „Filer-to-Server“-Modus – NAS Filer schickt seine
Volume Dumps über LAN an den TSM-Server, dort können
die Daten im TSM-Format auf allen Speicherhierarchiestufen
gespeichert werden inklusive der Erstellung von
Copypool-Tapes.
•
•
•
•
„Data Shredding“-Funktion für Diskpools – das mehrfache
Überschreiben von gelöschten Daten mit zufälligen HEX-
Werten
Backupset-Verbesserungen (Point-in-Time, Kombination
mit Image Backup, Einzeldatei-Restauration über TOC,
multiple Backupsets auf gleichem Medium)
„Active Datapool“ – die Möglichkeit, das Abbild der letzten
Full-Backups auf einem separaten Speicherpool zu erstellen
oder zu bevorraten
TSM for Copy Services – Nutzung der Microsoft Volume
Shadowcopy Services für die konsistente Snapshot-Sicherung
von Exchange und MS-SQL inklusive der „Instant
Restore“-Funktion bei der Nutzung von IBM Diskspeicher
(IBM DS6000/DS8000) oder IBM SAN Volume Controller.
TSM V5.5 wurde im November 2007 angekündigt, dies war
das letzte Release mit der Nutzung der proprietären Datenbank.
Die wichtigsten Neuerungen:
• Encryption-Key-Management durch den TSM-Server,
dadurch auch die Möglichkeit, dass Anwendungs-Clients
(TSM for… Clients) ihre Daten verschlüsselt über Netzwerke
schicken können, ohne dass die Verwaltung der
Keys von der Anwendung unterstützt sein muss
• Verbesserungen bei sequenziellen Diskpools (u. a. multithreaded
read im gleichen Volume)
• Import- und Export-Prozesse sind wiederanlauffähig
• Integration des VMware „VCB Integration Moduls“ in
den Windows B/A-Client zur Unterstützung von VMware
Consolidated Backup VCB
• TSM for Advanced Copy Services – Erweiterungen in der
Einheitenunterstützung und Nutzung für DB2 Snapshots
• NetApp „Snapmirror to tape“-Unterstützung als alternatives
Protokoll zu NDMP mit verbesserter Skalierung
TSM B/A Client Logo V5.4 und V5.5
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 203

IBM Storage Software
Tivoli Storage Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke
2005-2008 Lösungen für Endbenutzer, kleine mittelständische
Betriebe und Niederlassungen von Großkunden
Tivoli Continuous Data Protection CDP (2005) war die
Produktumsetzung des intern in der IBM schon seit 2004
verfügbaren Werkzeugs „Vitalfile“ mit der Zielgruppe der
Laptop­Benutzer im Unternehmen. Interessant vor allem für
solche Benutzer, die nur sporadisch Zugang zu Sicherungsdiensten
ihres Unternehmens haben.
CDP führte eine revolutionäre Neuerung in der Datensicherung
ein, die Sicherung von geänderten Dateien direkt beim
Abspeichern (continuous data protection). Zielmedium für
die Datenkopie ist zuerst lokaler Speicher am Laptop wie
z. B. ein anderes logisches Laufwerk der partitionierten Festplatte
oder lokal angeschlossener externer Speicher (USB).
Zusätzlich kann man eine zweite Kopie auf ein entferntes
Netzwerklaufwerk oder ins TSM schreiben, wobei CDP den
Datentransfer so lange versucht, bis eine gültige Netzwerkverbindung
aufgebaut ist.
Ende 2009 wurde CDP umbenannt in TSM Fastback for
Workstations und um zentrale Konfigurationsfunktionen
erweitert.
TSM Express wurde im März 2006 angekündigt als die
Einstiegslösung für TSM bei kleinen Systemumgebungen.
Die Modifikationen zum Standard­TSM waren:
•
•
•
•
•
•
Datensicherung nur auf Disk
Optionaler Anschluss von Magnetband für die Erzeugung
von auslagerungsfähigen Kopien über TSM-Backupsets
für Filedaten und Exchange/SQL
Sehr einfache Installation und Bedienung
Integriertes Reporting
Unterstützung ausschließlich für Windows-Umgebungen
mit zwei spezifischen Anwendungsagenten für Exchange
und MS-SQL
Migrations-Option zum Standard-TSM
TSM Fastback entstammt der Firmenakquisition der
amerikanisch/israelischen Firma FilesX Inc. durch IBM im
April 2008. TSM Fastback löst TSM Express ab und stellt
ganz neue Funktionen für die Sicherung von kleinen
Systemumgebungen bereit – den ausschließlichen Backup
von Fileservern oder Anwendungsservern über Snapshot­
Verfahren. Durch die Implementierung eines Snapshot­
Filter­Treibers auf dem Client ist es möglich, alle Datensicherungen
über Snapshots umzusetzen, die – ganz in der
Tradition des TSM – rein block­inkrementell ablaufen. Die
wichtigsten Eigenschaften:
Disk-only Backup auf dem lokalen Fastback-Sicherungsserver
Online-Snapshots für Fileserver und Anwendungsserver
durch die Verwendung von bereitgestellten Konsistenzfunktionen
Windows und Linux-Clients (ab Anfang 2010)
Die Möglichkeit, jeden gespeicherten Snapshot entweder
als komplettes Volume zu restaurieren oder sich den
Snapshot als Netzwerklaufwerk verfügbar zu machen, um
selektiv Einzeldateien zurückzuschreiben.
Item-Level Recovery/Single Mailbox Recovery von Microsoft
Exchange-Objekten
Wiederherstellung der Betriebssystem-Partition aus den
Snapshots durch Verwendung einer Lade-CD
Replikation von selektiven Snapshots von vielen entfernten
Fastback-Servern auf einen zentralen Fastback-Server
über WAN-Leitungen
Anbindung des zentralen Fastback-Servers an den zentralen
TSM-Server zur Erstellung von Auslagerungsbändern.
204 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
•
•
•
•
•
•
•
•
April 2009 –TSM V6.1 mit neuer Datenbankarchitektur
und Deduplizierung
Fast 20 Jahre hatte die Datenbank­Architektur auf Basis der
B+ Tree Technologie Bestand. Die steigenden Sicherungsvolumina
und vor allem die steigende Anzahl von Sicherungs­Objekten
machten eine Architekturänderung nötig,
um besser zu skalieren und die Online­Verfügbarkeit den
erhöhten Anforderungen anzupassen. Deshalb wurde in
V6.1 DB2 als Datenbanktechnologie für die Verwaltung der
TSM­Metadaten eingeführt.
Die DB2-Technologie erfüllt einerseits die erhöhten Skalier­
barkeitsanforderungen moderner Umgebungen, ermöglicht
andererseits die Nutzung neuer Verfahren wie die online
Konsistenzprüfung, online Reorganisation und umfassende
Index­Generierung und eröffnet der TSM­Architektur zusätzliche
Freiheitsgrade für zukünftige Erweiterungen.

Die Portierung auf die neue Datenbanktechnologie wurde
in enger Zusammenarbeit mit dem DB2­Labor in Toronto
geplant und umgesetzt und den Entwicklern gelang es, alle
spezifischen Funktionen, die technologisch an die ursprüngliche
Datenbank gebunden waren, auch in die neue DB2­
Umgebung zu portieren.
Deduplizierung ist nach Meinung von selbst ernannten
Brachenkennern „…the biggest thing in backup since the
incremental.“ (W. Curtis Preston im Februar 2009 in „TSM
6,1, dedupe & DB2“ auf www.backupcentral.com). Bei der
Deduplizierung handelt es sich im Grunde genommen nur
um ein neues Verfahren von Datenkompression mit der
Eigenschaft, Datenobjekte in Blöcke zu zerlegen und über
diese Blöcke Vergleichsoperationen laufen zu lassen, mit
dem Ziel­Redundanzen zu erkennen. Redundante Blöcke
werden in den Metadaten referenziert und dann gelöscht.
Die Menge der gelöschten redundanten Blöcke ist dann
das Maß für die Speicherersparnis (= Kompressionsfaktor =
Dedup­Ratio).
TSM V6.1 neues Layout des B/A-Clients
TSM V6.1 stellt Deduplizierungsfunktionen optional für
seine Diskpools zu Verfügung und arbeitet asynchron, d. h.,
die Sicherungsdaten werden zuerst unmodifiziert gespeichert,
dann in Folgeprozessen analysiert und dedupliziert. Es ist
geplant, das Verfahren in Folgereleases von TSM V6.1 auch
auf die TSM­Clients zu erweitern, was einmal die Berechnungslast
verteilt und vor allem die Datenmengen reduziert,
die von den Clients z. B. über öffentliche Netze verschickt
werden müssen. Das Verfahren ist höchst effizient, weil die
Vergleichsoperationen auf dem zentralen TSM Sicherungsserver
stattfinden und die Datenmenge aller Clients als
Basis für die Redundanzerkennung verwendet wird.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 205

IBM Storage Software
Tivoli Storage Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke
Zusammenfassung und Schlusswort:
Hier die historische Entwicklung von Tivoli Storage Manager
von 1990 bis 2009 nochmals in Kurzform:
• 1. November 1990 – WDSF/VM R1 mit Clients auf OS/2,
DOS und AIX
• November 1991 – WDSF/VM R1 Enhanced – Sun,
Apple Clients
• Mai 1992 – DFDSM/VM und DFDSM/MVS
• 29. Juli 1993 und 16. November 1993 – IBM ADSTAR
Distributed Storage Manager V1.1 und V1.2 mit OS/2
und AIX als Serverplattformen
• Frühjahr 1995 – ADSM V2.1 – OS/400, VSE, Sun und
HP als Plattformen für ADSM-Server und eine Vielzahl von
unterstützten Client-Plattformen, DRM und Copypool
• Oktober 1997 – ADSM V3.1 – ADSM-Server auf
Windows NT, Server-to-Server Kommunikation, Web
Admin-GUI, Web-GUI für Clients, SQL-Queries und
Integration in Systems Management Anwendungen
• Januar 1999 – IBM ADSM Marketing wechselt zu Tivoli,
neuer Name Tivoli ADSM
• September 1999 – Tivoli Storage Manager (TSM) V3.7
ersetzt Tivoli ADSM, LAN-free, Tape-Library Sharing
• Juli 2000 – TSM V4.1 – subfile backup, Linux Clients
und Windows 2000 Support
• Juni 2001 – TSM V4.2 – Journal-based backup, LAN-free
backup für den Backup-Archive Client, NDMP und
SANergy
• März 2002 – TSM V5.1 – Windows Server-free Backup und
online Image Backup/Open File Backup für Windows 2000
mit LVSA
• Oktober 2002 – TSM V5.1.5 – Linux/x86 und
Windows 2000 als Server, Server-to-Server Import/Export,
TSM auf OS/400 PASE
• Juli 2003 – TSM V5.2 – TSM-Server auf zLinux, TSM/zOS
LAN-free, TSM for Data Retention, NDMP TOC
• Dezember 2004 – TSM V5.3 – Einführung ISC als
Admin-Konsole, AES128-bit, Proxy-Node Support,
Group Collocation
• Januar 2006 – TSM V5.4 – NDMP Filer-to-Server,
Data-Shredding, Active Datapool, TSM for Copy Services
• November 2007 – TSM V5.5 – VMware Consolidated
Backup
• Juli 2008 – TSM Fastback
• April 2009 – TSM V6.1 – DB2 als Datenbank,
Storagepool-Deduplication
Die TSM Versions­ und Funktionsliste der letzten 20 Jahre ist
auch ein Abbild der technologischen Entwicklung in der IT.
Die Datenverarbeitung hat sich in vergleichbaren Phasen
entwickelt, von der Mainframe­zentrischen IT über die Ära,
in der die verteilte Verarbeitung auf möglichst vielen heterogenen
Systemen schon Prinzip schien, wieder hin zu zentralen
konsolidierten Strukturen auf virtualisierter Hardware.
Die Anforderungen, für die TSM ursprünglich einmal konzipiert
wurde, haben sich über diese Zeit nicht geändert:
Datensicherung ist ein notwendiges Übel, das Kosten verursacht
und dauernder Pflege bedarf, zu dem es aber keine
Alternative gibt. Deshalb bin ich sicher, dass Tivoli Storage
Manager auch weiterhin gebraucht wird und erfolgreich sein
wird. Im November 2010 feiert IBM Tivoli Storage Manager
20. Geburtstag, dazu jetzt schon meine besten Wünsche für
ein langes erfolgreiches Produktleben.
206 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software
Anhang 207

IBM Storage Software
BRMS für System i – Edelgard Schittko
1. BRMS – Überblick
Das Lizenzprogramm „Backup, Recovery and Media Services
for IBM i“ (BRMS) ermöglicht die Implementierung
einer Sicherungsstrategie für IBM POWER Systeme mit
Betriebssystem IBM i (ehemals i5/OS).
Dabei können komplexe Szenarien voll automatisiert abgebildet
werden, wie z. B. die Online­Sicherung von Lotus­Servern
(Domino) in einer i­Umgebung. Damit stehen mit BRMS
mehr Möglichkeiten zur Verfügung als bei Verwendung der
Backup­Befehle vom native Betriebssystem IBM i.
Das aktuelle Lizenzprogramm 5761­BR1 „Backup, Recovery
and Media Services for IBM i“ für Version i 6.1 besteht aus
drei kostenpflichtigen Features: *BASE, Network Feature,
Advanced Feature, die in Bild 1 vorgestellt werden und im
Nachfolgenden ausführlich erläutert werden.
Bild 1
Nützliche Links:
IBM i InfoCenter – BRMS
http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/
index.jsp?topic=/rzai8/rzai8overview.htm
BRMS HomePage
http://www­03.ibm.com/systems/i/support/brms
2. BRMS – aktuelle Features
Die meisten IBM i Kunden, die BRMS verwenden, haben
„nur“ das Feature *BASE lizenziert von 5761­BR1. Bereits
mit diesem Feature *BASE sind vier umfangreiche Module
Backup, Recovery, Media Management und Tape Library
Support verfügbar, siehe Bild 2.
208 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Bild 2
Weitere Details zu den im Bild 2 genannten vier Modulen
Backup, Recovery, Media Management und Tape Library
Support vom *BASE Feature siehe:
Bild 3
http://www.redbooks.ibm.com/redbooks/pdfs/sg244840.pdf
http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/
topic/rzai8/sc415345.pdf
Für BRMS stehen mit i 6.1 drei verschiedene Schnittstellen
(Interfaces) für die Implementierung und das Management
zur Verfügung:
• traditionell „green Screen“ (5250-Interface), siehe Bild 3
• BRMS PlugIn im System i Navigator, siehe Bild 4
• BRMS PlugIn im IBM Systems Director Navigator für IBM i
(ehemals i5/OS), siehe Bild 5
Die Verwendung des 5250­Interfaces (Bild 3) hat
zwei Vorteile:
•
•
eine ausgeprägte Menüstruktur, sinnvoll für BRMS-
„Anfänger“
eine Vielzahl von BRMS-Befehlen, die sich leicht in
beim Kunden vorhandene Programme integrieren lassen,
sinnvoll für den BRMS-„Experten“
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 209

IBM Storage Software
BRMS für System i – Edelgard Schittko
Bild 4
Die Verwendung der beiden in Bild 4 und Bild 5 vorge­
stellten GUI­Schnittstellen für BRMS hat den Vorteil, dass
GUI­orientierte und/oder mit dem Betriebssystem IBM i nur
wenig vertraute Anwender auch mit BRMS arbeiten können.
GUI = Graphical User Interface
Im Bild 4 sind ein paar Beispiele für sogenannte „Backup
Control Groups (Sicherungssteuergruppen)“ zu sehen. Sie
sind Definitionen für automatische Sicherungen. Hier nicht
sichtbar, aber im Hintergrund vorhanden, ist das Scheduling
für die Sicherungen.
Bild 4 wurde mit einer System i Navigator Installation auf
einem Laptop mit englischem Windows XP erstellt. System i
Navigator ist auch auf Deutsch verfügbar.
Die Beispiele für die Backup Control Groups sind von einer
relativ kleinen IBM i Partition (Name „DEBER520“) eines
POWER Systems mit ca. 700 GB Plattenkapazität. Selbstverständlich
ist BRMS bei den IBM i Kunden auch in Verwendung
größerer Partitionen mit mehreren TB Platten kapazität
im Einsatz.
210 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Bild 5
Neu mit IBM i 6.1 ist das Web Browser Interface „IBM
Systems Director Navigator for i“ (frühere Bezeichnung
„... for i5/OS“). Mit dem vorherigen Release IBM i 5.4
(ehemals i5/OS V5R4) ist dieses Interface noch nicht verfügbar
ge wesen.
In diesem Web Browser Interface mit i 6.1 gibt
es auch ein BRMS PlugIn, siehe Bild 5. Details zum
BRMS PlugIn im „IBM Systems Director Navigator for i“
siehe Chapter 12.1 im Redbook „IBM Systems Director
Navigator for i (SG24­7789­00)“:
http://www.redbooks.ibm.com/redbooks/pdfs/sg247789.pdf
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 211

IBM Storage Software
BRMS für System i – Edelgard Schittko
Bild 6
Im obigen Bild 6 sieht man einen Vergleich zwischen den
Möglichkeiten (Befehle, Menüs, Backup Control Group
Special Values) zum Sichern (to save) bzw. Zurückspeichern
(to recover) in einer native IBM i Betriebssystemumgebung
und einer BRMS­Umgebung.
Das Bild ist dem Poster „Are you saving the right stuff?“
(IBM Form Number G325­6328­05, http://publibfp.dhe.ibm.
com/epubs/pdf/32563285.pdf) entnommen.
212 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Bild 7
Das lizenzpflichtige BRMS Network Feature ermöglicht es –
siehe Bild 7, über mehrere Partitionen oder POWER Systeme
mit IBM i und BRMS eine gemeinsame Tape Library zu
verwenden, mit einem gemeinsamen Bandpool und einer
bestimmen Anzahl von Bandlaufwerken. Dabei muss jede
Partition/jedes System mit der Tape Library verbunden sein.
Dadurch werden i.a. weniger Kassetten und auch weniger
Bandlaufwerke benötigt als bei dedizierter Zuordnung.
Außerdem können systemübergreifende Restores (Zurückspeicherungen)
oder Duplizierungen durchgeführt werden,
was z. B. bei zwei Systemen üblich ist, wo eines das Produktionssystem
ist und das andere das Backup­System.
Bei partitionierten Systemen kann das BRMS Network auch
zwischen den Partitionen eingerichtet werden. Hier ist die
Verwendung des in allen partitionierten POWER Systemen
vorhandenen virtuellen Ethernets als interne TCP/IP­Schnittstelle
für das BRMS Network sinnvoll.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 213

214
IBM Storage Software
BRMS für System i – Edelgard Schittko
Bild 8
Das lizenzpflichtige BRMS Advanced Feature – siehe Bild 8 –
beinhaltet neben HSM (Hierachical Storage Management)
seit 21.03.2008 in der Version 5761­BR1 mit i 6.1 noch
zwei weitere Möglichkeiten, einerseits einen individuellen
BRMS­System­Namen zu vergeben („BRMS user defined
system name“) und andererseits die Software­basierende
Verschlüsselung („BRMS Software-based encryption“).
Während HSM im BRMS und damit das bisherige BRMS
Advanced Feature kaum verbreitet war, wird mit den beiden
neuen Funktionen im BRMS Advanced Feature mit i 6.1 die
Nutzung sicherlich steigen. So wird z. B. die Möglichkeit,
einen individuellen BRMS­System­Namen zu vergeben, in
Zusammenhang mit Hochverfügbarkeitsszenarien benötigt.
Hinweis: Die sogenannte „Hardware­based encryption“,
auch bezeichnet als „Tape Drive Encryption“, ist schon seit
Oktober 2006 als „Library Managed Encryption“ im BRMS
unterstützt, siehe http://www­03.ibm.com/systems/i/support/
brms/tapeEncrypt.html
Die oben beschriebenen BRMS­Features beinhalten auch
den Support für sogenannte „spezielle Umgebungen“,
nachfolgend aufgezählt mit weiteren Links:
BRMS Application Client zu einem IBM TSM Server,
siehe Chapter 9 in
http://www.redbooks.ibm.com/redbooks/pdfs/sg247031.pdf
BRMS und FlashCopy, siehe Chapter 15 in
http://www.redbooks.ibm.com/redbooks/pdfs/sg247103.pdf
BRMS und WORM tapes, siehe Chapter 6 in
http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/
topic/rzai8/sc415345.pdf
BRMS und SAP, siehe Chapter 23 in
http://www.redbooks.ibm.com/redbooks/pdfs/sg247166.pdf
BRMS und Domino, siehe u. a.
http://www-03.ibm.com/systems/i/support/brms/domino.html
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
•
•
•
•
•
Neu mit IBM i 6.1.1 (verfügbar seit 23.10.2009) auf POWER6
oder POWER6+ Systemen oder entsprechenden POWER
Blades gibt es einen NPIV Support (NPIV = N_Port ID
Vir tualization) für bestimmte Tape Libraries (Bandroboter),
siehe Informational APAR II14526:
http://www­912.ibm.com/n_dir/nas4apar.nsf/c79815e083182f
ec862564c00079d117/02327e067599839e86257659003c6d
66?OpenDocument&Highlight=2,NPIV
Diese Tape Libraries mit ihren LTO4­Laufwerken sind,
obwohl sie „nur“ über eine virtuelle Fibre­Verbindung von
der IBM i 6.1.1 Partition erreichbar sind, im BRMS voll
unterstützt.

3. BRMS – Geschichte
BRMS wurde erstmals am 01.09.1992 angekündigt (EMEA
Announcement Letter ZP92­0587) unter der damaligen
Bezeichnung „Backup, Recovery and Media Services/400“
mit Lizenzprogramm­Nummer 5798­RYT mit genereller
Verfügbarkeit am 15.01.1993. Das „Lizenzprogramm“ BRMS
hatte 1992/1993 die „exotische“ Lizenzprogramm­Nummer
5798­RYT, weil es damals noch als Ergebnis einer Allianz
mit der Firma Mersch­Bacher & Associates, Inc. vermarktet
wurde und kein „vollwertiges“ Lizenzprogramm war, sondern
„nur“ ein LPO (Licensed Program Offering).
Am 03.05.1994 wurde BRMS als „vollwertiges“ Lizenzprogramm
5763­BR1 (Version 3, EMEA Announcement Letter
ZP94­0348) angekündigt mit genereller Verfügbarkeit am
25.11.1994 und damit in das normale Lizenzprogramm­
Prozedere von IBM Rochester für (damals noch) AS/400­
Systeme mit Betriebssystem OS/400 integriert. Ab diesem
Zeitpunkt hat BRMS jeweils die „normale“ Lizenzprogramm­
Bezeichnung 57xx­BR1 bekommen.
Mit JEDER Betriebssystemversion von OS/400 bzw. i5/OS
bzw. IBM i wurde ab 1994 auch eine neue Version von
BRMS mit diversen Verbesserungen und Funktionserweiterungen
herausgebracht. Anbei ein Link zu einer Übersicht
aller Betriebssystemversionen von OS/400 bzw. i5/OS bzw.
IBM i seit 1988. Für BRMS ist der Zeitraum ab 1994 wichtig:
http://www­947.ibm.com/systems/support/i/planning/
upgrade/suptschedule.html
Die genauen Features vom aktuellen BRMS mit IBM i 6.1
(5761­BR1) sind im Handbuch zu finden:
http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/
topic/rzai8/sc415345.pdf
4. BRMS – Zusammenfassung und Ausblick
Mit BRMS steht ein mächtiges Werkzeug für IBM i­Umgebungen
zur Verfügung, um komplexe Sicherungserfordernisse
umzusetzen und um durch die sechs verschiedenen
Module (Backup, Recovery, Media Management,
Tape Library Support, Network Feature, Advanced Feature)
sowohl für diverse Zurückspeicherungen einschließlich der
kompletten Widerherstellung des gesamten Systems aus
einer Sicherung „gewappnet“ zu sein als auch um spezielle
Anforderungen aus kundenindividuellen Implementierungen
(z.B. Domino, SAP, FlashCopy) zu berücksichtigen.
Bei einer kompletten Widerherstellung des gesamten
Systems wird der sogenannte „Recovery Report“ verwendet,
eine nach der letzten Sicherung automatisch erstellte Anleitung
über die durchzuführenden Rückspeicherungs­Schritte.
Die für 2010 geplanten(*) Ankündigungen zu POWER7 und
IBM i 7.1 und die damit geplanten Erweiterungen wie z.B.
den Ausbau des bereits mit IBM i 6.1.1 möglichen „IBM i
Network Upgrade“ auch für eine Scratch­Installation eines
Systems mit IBM i werden auch auf BRMS Auswirkungen
haben.
Man kann für BRMS in 2010 mit erfreulichen Neuerungen
rechnen.
Bereits existierende Links dazu (*):
www.ibm.com/systems/power/hardware/sod.html
www.ibm.com/systems/power/hardware/sod2.html
(*) Disclaimer: All statements regarding IBM‘s future direction and intent are
subject to change or withdrawal without notice, and represent goals and
objectives only. Any reliance on these Statements of Direction is at the relying
party‘s sole risk and will not create liability or obligation for IBM.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
215

216
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Technologie-Anhang
Technologie-Anhang
Anhang
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 217

Technologie-Anhang
Die Vorgänger der heutigen Massenspeicher
Lochkarten
Lochkarten als Massenspeicher existierten lange vor den
Computern. Bereits Holleriths Volkszählungsmaschine setzte
1891 Lochkarten ein. Lochkarten stellen Binärdaten dar,
indem eine bestimmte Stelle auf der Karte gelocht (oder
eben nicht gelocht) war. Beim Aufkommen der Computer in
den 50er­Jahren beherrschte man diese Technik inzwischen
sehr gut: Die Karten konnten sortiert, gezählt und in jeder
erdenk lichen Form ausgewertet werden.
Hergestellt wurden die Karten mit sogenannten Lochkartenstanzern.
Mit den fertig codierten Karten fütterte man über
einen Leser den Computer und führte ihm auf diese Weise
die gewünschten Programm­ und Verarbeitungsdaten zu.
Statt einzelner Karten wurden später auch Lochstreifen
verwendet, die eine höhere mechanische Verarbeitungsgeschwindigkeit
gestatteten.
Lochkarten
Lochstreifen
Trommelspeicher
Die ersten elektrischen Massenspeicher, die im Zusammenhang
mit Computern eingesetzt wurden, waren 1947/48 die
sogenannten Trommelspeicher. Auf einer massiven Trommel
wurde eine Beschichtung aus einem magnetischen Material
aufgebracht. Dieses konnte induktiv durch einen Strom magnetisiert
werden oder erzeugte beim Auslesen einen induzierten
Strom. Durch die kleineren Ausmaße der Trommelspeicher
verringerte sich auch die Größe der damaligen Computer
erheblich. Bereits ab 1950 wurden vereinzelt Trommelspeicher
eingesetzt, um Programme oder Daten zu laden und zu
speichern.
Trommelspeicher 1947
218 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1 st tape
system
1 st read/write
drive
1 st read/back
drive
1 st cartridge
drive
MP
Beschichtung
Magnetband
Ab 1952 verdrängte das Magnetband (IBM 726, IBM 727)
die Lochkarten als Massenspeicher. Dabei handelte es sich
um ein 12,4 mm breites Plastikband, bei dem eine Seite mit
einer magnetisierbaren Beschichtung überzogen war. Die
Datenaufzeichnung bestand darin, dass die auf dem Band
enthaltenen Ferritstreifen magnetisiert oder nicht magnetisiert
waren und so die Informationen in dem für den Computer
benötigten Binärsystem darstellten. Auf einer zusätzlichen
Bandspur konnten später sogenannte Paritätsbits untergebracht
werden, wodurch eine hohe Datensicherheit gewährleistet
wurde. Der Vorteil der Magnetbänder lag neben einer
hohen Verarbeitungsgeschwindigkeit vor allem in der hohen
Speicherkapazität. Allerdings konnten Daten auf einem Band
immer nur sequenziell (also hintereinander) abgelegt und
wieder gelesen werden. Trotzdem findet das Magnetband bei
Großrechner­Systemen mit hohem Archivierungsbedarf und
als billiger Massenspeicher (heute in Form von Bandkassetten)
Zeitgesteuerte
Spurnachführung
Kassetten-Memory-Chips
1 st to deliver
LTO
1 st with FICON
and Fibre
Parity
Aufzeichnung
1 st with LTO
Fibre
1 st tape encryption
Flat Lap Köpfe
PRML Dünnfilm
Virtual
Backhitch
1 st with LTO4
1 st 1TB capacity
bis heute Verwendung. Zukünftig dürfte das Magnetband
aufgrund der Energie­Effizienz­Problematik und der „Green
IT“­Diskussionen eine Renaissance erfahren. Magnetbänder
brauchen keinen Strom. Tape ist „cool“!
Tape hat als Medium im Vergleich zu allen anderen Speichermedien
die längste Geschichte. Heute bietet Tape als
Medium im Vergleich zu allen vorhandenen Technologien
wie Platte, optische Speicher, RAM, Flashspeicher oder
PCMs das höchste Entwicklungspotenzial bezüglich Kapazität
und Leistung in den nächsten Jahren. Dies wurde mit der
konsequenten technischen Weiterentwicklung von Tape
erreicht (siehe Bild „IBM Tape Historie im Überblick“).
Bereits mit der ersten Kassettentechnologie, der IBM 3480,
wurde MP­Beschichtung (Metall Partikel) eingeführt. Mit der
3590 wurde 1999 Parity­Aufzeichnung eingeführt, wo immer
nach sieben Datenblöcken der dazugehörige Parity­Block
mitaufgezeichnet wurde, was eine wesentlich höhere Fehler­
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 219
GMR

Technologie-Anhang
korrektur ermöglicht. Mit der Einführung von LTO im Jahr
2000 kam etwas ganz entscheidend Neues: die zeitgesteuerte
Spurnachführung über Servobänder, die es erlaubt, die
Schreib­/Leseköpfe exakt – selbst bei sehr dünnen Spuren –
über dem Spurset zu führen. Dies führte zu einer Kapazitäts­
und Leistungssteigerung von Faktor 20 in nur 10 Jahren
(von 2000 bis 2010). Mit Einführung der 3592­Technologie
(Jaguar) im Jahr 2003 für den Enterprise­Bereich wurden
Techniken aus der Plattentechnologie in die Bandlaufwerke
übernommen. Eine neue Kopftechnik kommt zur Anwendung,
die es erlaubt, in Verbindung mit der ersten Dünnfilmbeschichtung
auf dem Medium selbst mit wesentlich
höherer Induktion auf den Köpfen aufzuzeichnen und so
wesentlich stabilere Bits auf dem Medium zu reflektieren.
PRML wurde bei den Platten erstmals 1991 eingeführt und
hält mit der 3592 Einzug in die Tape­Technologie (siehe
auch unter PRML im Technologie­Anhang). Neue Funktionen
wie Virtual Backhitch kommen zum Tragen, die das Band im
Laufwerk am „Streamen“ halten, auch wenn nur kleine
Datenmengen zum Laufwerk transferiert werden.
Das Jahr 2008 allerdings schreibt große Geschichte in der
Tape­Historie. Mit dem Jaguar 3­Laufwerk, das sich jetzt
TS1130 nennt, gelingt der erste Einsatz von GMR­Leseköpfen
(Giant­Magneto­Resistance). GMR­Leseköpfe kamen
erstmals bei den Platten 1997 zum Einsatz und ohne diese
Technologie wären unsere heutigen Festplattenkapazitäten
nie möglich geworden. Jetzt ist die Basis von GMR auch bei
Tape eingeführt, eine Basis, die völlig neue kapazitive Möglichkeiten
schafft. Die Einführung von Dünnfilmbeschichtung
und hochinduktiven Schreibköpfen lassen es zu, extrem
dünne Spuren aufzuzeichen. Dies geschieht so, dass eine
relativ dicke Spur hochinduktiv vom Bandanfang bis zum
Bandende erzeugt wird. Beim Zurückschreiben vom Bandende
zum Bandanfang wird ein Teil der geschriebenen Spur
wieder überschrieben. Mit dieser Überschreibtechnik, die
auch als „Shingling“ bezeichnet wird, ist es möglich,
hauchdünne Spuren zu erzeugen. Das Problem ist jetzt das
Auslesen. Wie können die kleinen magnetischen Streufelder
auf einer so dünnen Spur wieder ausgelesen werden? Die
Lösung hierfür sind die jetzt eingeführten GMR­Leseköpfe.
GMR­Leseköpfe können selbst bei extrem hohen
Geschwindigkeiten problemlos kleinste Streufelder
ab greifen und auslesen. Damit ist eine neue Basis für die
Tape­Weiterentwicklung geschaffen.
Bereits im Mai 2006 wurde im IBM Labor in Almaden, Kalifornien,
der Einsatz von GMR­Leseköpfen in einem Prototyp
auf Basis der 3592 Jaguar­Technologie vorgestellt und eine
Aufzeichnungsdichte von 1 Gigabit pro cm2 erreicht. Die
Grafik „GMR­Einsatz bei Tape“ zeigt die auf dem Band
erzeugten Spuren mit GMR mit einer Spurbreite von 1,5 µm
im Vergleich zu einer LTO3­Spur mit 15 µm.
Almaden: 16. Mai 2006, GMR-Einsatz bei Tape
1 Gigabit pro cm 2 , 8 TB pro Kassette
Magnetplatten
Magnetplatten sind die Nachfolger der voluminösen Trommelspeicher
und gelten als die direkten Vorläufer der heutigen
Festplatten. Am 13. September 1956 stellte IBM die erste
Magnetplatte mit der Bezeichnung RAMAC 350 (Random
Access Method of Accounting and Control) als Teil des
RAMAC 305­Systems und mit einer Kapazität von 5 MB der
Öffentlichkeit vor. Diese Kapazität verteilte sich auf 51
Scheiben mit je 24 Zoll (60 cm) Durchmesser. Die Abtastung
der Informationen erfolgte durch einen Schwebe­Schreib­/
Lesekopf (siehe unter RAMAC 305).
220 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Entwicklung des IBM Systems 305 und des ersten Magnetplattenspeichers
IBM 350
Der IBM Mitarbeiter Reynold B. Johnson erhielt Anfang der
50er­Jahre die Aufgabenstellung, ein Rechnersystem zu
konzipieren, das die Möglichkeit hatte, jeden Geschäftsvorfall
dann zu bearbeiten, wenn er anfällt mit einer Leistung
von etwa 10.000 Fällen pro Tag (ohne Stapelverarbeitung,
wie es die bis dahin verwendeten Lochkarten und Lochstreifen
machten). Reynold B. Johnson stellte sich ein einzigartiges
Team aus Entwicklern und Experten zusammen, um
diese schwierige Aufgabe zu starten. Um eine möglichst
angenehme Umgebung für diese Aufgabe zu haben, die
möglichst viele Innovationen hervorbringen sollte, startete er
das Projekt 1952 in San Jose, im sonnigen Kalifornien. Das
Projekt trug damals den Namen „source recording“. Im
Team von Johnson waren A.J. Critchlow, W.A. Goddard,
J.W. Haanstra, H.P. Luhn, J. Ratinow und C.D. Stevens.
Bereits ein Jahr später, 1953, fällte Johnson die Entscheidung,
dass der Datenspeicher eine mit Magnetspeicherplatten
arbeitende Dateianlage sein sollte.
Damals war gerade die Entwicklungsarbeit der IBM Magnetbandeinheit
726 abgeschlossen und das Team von Reynold
B. Johnson erkannte schnell, dass Magnetbandeinheiten
zwar sehr schnell im seqenziellen Bereich arbeiten konnten,
sich allerdings bei direkten Zugriffen bezüglich der Zugriffszeit
langsam verhielten. Die Zugriffszeiten bewegten sich in
den Minutenbereich hinein und daher waren die Bänder für
Sofortzugriffe bei ganz bestimmten Anwendungen nicht
geeignet. Ein neuer Speicher, der diese Anforderungen
erfüllen konnte, musste entwickelt werden. Die Lösung
bestand aus 51 beidseitig beschichteten Aluminiumplatten,
die auf einer vertikalen Welle montiert wurden und mit einer
Geschwindigkeit von 1.200 Umdrehungen pro Minute
rotierten. Man begnügte sich mit einem Paar von Schreib­/
Leseköpfen, die mittels eines Stahlseilantriebs zweidimensional
positioniert wurden gemäß dem Inhalt eines Adressregisters.
Dieser Vorgang dauerte maximal 800 ms. Damit
konnte die Forderung erfüllt werden, etwa 10.000 Transaktionen
pro Tag, jede sofort beim Eintreffen des Falles, zu
bearbeiten. 1956 war es dann soweit, dass das neue Rechnersystem
RAMAC 305 mit dem dazugehörigen Plattenspeicher
RAMAC 350 auf den Markt gebracht werden konnte.
RAMAC 350 als Teil des RAMAC 305-Rechnersystems
Reynold B. Johnson, der kurz „Rey“ genannt wurde, hatte
bis zu seiner Pensionierung 1971 die Zahl von 90
U.S.­Patenten angemeldet, fast ausschließlich Patente, die
die Plattenweiterentwicklung betrafen.
Mit der RAMAC 350 erblickte der erste Magnetplattenspeicher
das Licht der Welt und es folgten ohne Unterbrechung
über Jahrzehnte weitere Entwicklungen des Plattenspeichers
mit dem ständigen Ziel, Kapazitätssteigerungen,
Zugriffszeitverkürzungen, höhere Datenraten und geringere
Kosten pro gespeichertes Megabyte zu erreichen. Dieser
Entwicklungsgang wurde durch die American Society of
Mechanical Engineers in 1984 gewürdigt, indem sie den
RAMAC­Plattenspeicher zur „International Historic Mechanical
Engineering Landmark“ (Landmark steht für Meilenstein)
erklärte, in Anerkennung des andauernden Einflusses
auf die Speichertechnologie.
Reynold B. Johnson
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 221

Technologie-Anhang
Funktionsweise des Magnetplattenspeichers IBM 350 (1956)
und IBM 355 (1957)
Wie arbeitet nun die Magnetplatte RAMAC 350 und wie
erfolgt die Positionierung? Der Prozessor stellt mit dem
Suchkommando die anzusteuernde Adresse zur Verfügung.
Diese Adresse wird in Adressrelais gesetzt, danach sorgt
ein Startsignal für die Zugriffssteuerung. Ausgehend von der
Ist­Position des Vertikalwagens ist die Zielposition durch die
Aktivierung einer der beiden Magnetpulverkupplungen
anzufahren (siehe Bild „RAMAC Zugriffsmechanismus“).
Ganz unten hängt der Antriebsmotor mit V­förmigem
Antriebspulli, einem Stahlkegel, der mit einer Gummiobe r­
fläche versehen ist. Dieser Kegel treibt zwei Magnetpulver­
kupplungen an, d.h., die eine läuft rechts, die andere links
herum. Die beiden Kupplungen laufen auf einer Welle.
Wenn keine der beiden Kupplungen aktiviert ist, steht die
Ausgangs seilantriebsrolle still (rechts unten). Wird eine der
Kupplungen aktiviert, bewegt sich der Vertikalwagen, der
den Zugriffsarm bewegt (Bildmitte), nach oben oder nach
unten, je nachdem, welche Kupplung aktiviert wurde.
Die Adressrelais repräsentieren die Zielposition als Soll­
Position. Der Kontakt vom Vertikalwagen zu einem von 50
Kontakten (Abbildung „RAMAC 350 Vertikalpositionierung“,
kupferfarbige Kontaktleiste) zeigt die Vertikalwagen­Ist­
Position. Eine ohmsche Messbrücke stellt die Größe der
Differenz von Ist­ zu Soll­Position fest und erzeugt ein entsprechendes
Startsignal. Der Vertikalwagen bewegt sich
jetzt entweder nach oben oder unten.
Dadurch ändert sich laufend der Ist­Widerstand in der
Messbrücke, bis er den Wert Null (Brückengleichheit)
erreicht hat. Trifft dies zu, wird die antreibende Kupplung
stromlos (entweder die eine oder die andere) und damit
wird die Bewegung gestoppt. Damit ist die Vertikalbewegung
abgeschlossen. Um diese Position mechanisch präzise
zu halten, wird ein Präzisionskonus druckluftgesteuert
in eines der Konuslöcher zur Verriegelung eingefahren
(Abbildung „RAMAC 350 Vertikalpositionierung“, Lochschiene
rechts neben der kupferfarbigen Kontaktleiste).
222 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Der Vertikalwagen wird dadurch fest an der V­förmigen
Bewegungsschiene arretiert.
Um die auftretenden Kräfte beim Stoppvorgang zu beherr­
schen, läuft ein Tachogenerator mit (Abbildung „RAMAC
350 Zugriffsmechanismus“ unten links), der die Geschwindigkeit
in Form der abgegebenen Spannung anzeigt. Je
näher der Vertikalwagen zu seiner Zielposition kommt, umso
weniger Kupplungsstrom steht zur Verfügung, und damit
verlangsamt sich die Bewegung.
Ist die Suchposition erreicht, d.h., die Vertikalverriegelung
durch den Präzisionskonus in der Lochschiene ist erfolgt,
wird das Steuersignal für die Phase der Horizontalbewegung
des Zugriffsarmes gestartet (Bild „RAMAC 350
Horizontalpositionierung“).
Die Horizontalpositionierung läuft ähnlich ab wie die Vertikalpositionierung.
Der Zugriffsarm wird in seiner Position
begleitet von dem oben rechts sichtbaren Potentiometer
(Zahnradantrieb) und liefert über die Messbrücke die Soll­
Ist­Differenz für die weitere Ablaufsteuerung. Beim Erreichen
der Zielposition (Spuradresse) wird die präzise Spurposition
mittels pneumatisch betätigter Klinke auf die Präzisionszahnstange
verriegelt. Damit ist die mechanische Positionierung
in beiden Zugriffsachsen abgeschlossen. Ein „End of
Access“­Signal steuert das pneumatische Ausfahren des
S/L­Kopfes auf Schwebehöhe. Die Präzisionszahnstange
enthält 100 Einkerbungen, wo sich die Klinke einrasten
kann, weil die Platte insgesamt 100 Spuren reflektiert.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 223

224
Technologie-Anhang
Wie schwebte der S/L­Kopf wirklich?
Der Kopf befindet sich im nicht aktivierten Zustand in eingefahrener
Position durch Federkraft (siehe Abbildung 350/355
S/L­Kopfgehäuse, F links und rechts). In dieser Position hat
der Kopf einen beträchtlichen Abstand zu den Plattenoberflächen.
Wird das Ladeventil aktiviert, strömt Druckluft (siehe
Bild „DL“) in die drei Zylinderräume der Kolben K. Dadurch
wird der Kopf nach unten hin zur Plattenoberfläche (Speicheroberfläche)
bewegt. Die gesteuerte Druckluft tritt
gleichzeitig aus sechs im Sechseck angeordneten (im Bild
nur vier sichtbar), mit nur 0,1 mm Durchmesser großen Bohrungen
aus. Dadurch lässt sich der Kopf nicht tiefer drücken,
weil das Luftpolster unter den sechs Löchern sich nur
auf eine Höhe von 0,02 mm bringen lässt (konstruktionsbedingt).
Dieser Schwebezustand des Kopfes in dieser Höhe
wird kontinuierlich beibehalten, auch wenn geringfügige
Schwankungen der Platten bei einem Durchmesser von 24 Zoll
(ca. 60 cm) im äußeren Bereich stattfinden (Bernoullisches
Gesetz). Damit ist der S/L­Kopf bereit zu lesen oder zu
schreiben.
Die Solenoide (siehe Abbildung „RAMAC 350 Zugriffsmechanismus“
kleines Bild links, 5 Stück) steuern per Pressluft
das Arretieren und Lösen des Wagenverriegelungsbolzens
bei der Vertikalpositionierung und per Pressluft die Armverriegelungsklinke
auf der Präzisionszahnstange bei der Hori­
zontalpositionierung. Sie steuern ebenso die Druckluftzufuhr
zum 350/355 Kopfgehäuse, um das Ausfahren der Köpfe
auf Schwebedistanz zur Platte durchzuführen. Solenoide
sind röhrenförmige zylindrische Metallspulen, die bei Stromdurchfluss
wie ein Stabmagnet wirken. Im Falle der RAMAC
350/355 arbeiten Solenoide als schnelle Nadelventile für
Pressluft, die per Magnetfeld geöffnet werden und per
Federkraft geschlossen werden.
Hinweis: Es gibt oft Irritationen, ob der RAMAC 350 Plattenstapel
50, 51 oder 52 Platten hatte! Bei der RAMAC 350
wurden 50 Platten, also 100 Plattenoberflächen zur Aufzeichnung
verwendet. Der Stapel selbst umfasste 51 Platten.
Dabei wurden die beiden Außenoberflächen der beiden
äußeren Platten (ganz oben und ganz unten) nicht für die
Aufzeichnung verwendet. Bei der RAMAC 355, die ein Jahr
später, 1957, auf den Markt kam, umfasste der Plattenstapel
52 Platten, 50 für die Aufzeichnung. Die Außenplatten
dienten nur zur Stabilisierung und zum Schutz für die innen
liegenden 50 Platten, die zur Aufzeichnung dienten.
Der druckluftgesteuerte Schwebekopf lernte erst 1961 das
Fliegen und wurde mit dem Produkt IBM 1301 eingeführt
(siehe auch unter IBM 1301). Dabei wurden im Außenbereich
der Platten „Landebahnen“ eingeführt und der Kopf
wurde so aerodynamisch gestaltet, dass er bei einer
Umdrehung von knapp 1.800 Umdrehungen pro Minute
seine Flughöhe erreichte, die damals bei 0,0635 mm lag.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Hinweis: Im Anhang des Kapitels Magnetplatten finden Sie
ein Interview, das der Autor mit den IBM RAMAC 350/355
Spezialisten Hans W. Spengler und Heinz Graichen vom
IBM Museum in Sindelfingen geführt hat. Hier wird der IBM
RAMAC 350/355 Zugriff in allen technischen Einzelheiten
erläutert.
Noch immer dominieren Magnetplattenspeicher die Informationstechnologie,
obwohl auch die optischen Speicher in
Form der wiederbeschreibbaren Compact Discs sich einen
gewichtigen Anteil am Massenspeichermarkt erobert haben.
Magnetplattenspeicher funktionieren alle nach dem gleichen
Grundprinzip: Als Speichermedium dient eine runde Scheibe,
auf der sich eine Schicht aus hartmagnetischem Material
(früher verschiedene Ferrite, heute Dünnfilm) befindet. Die
Platte ist in konzentrische Spuren unterteilt. Ein beweglicher
Magnetkopf wird radial über diese Platte bewegt, um die
nadelförmigen Ferrite auf den einzelnen Spuren so zu
magne tisieren, dass Binärdaten abgebildet werden. Er ist
auch in der Lage, durch Verschiebung des Laufwerksarms
schnell von der einen in die andere Spur zu wechseln. Die
Spuren wiederum sind in Sektoren unterteilt. Die Lage und
Ausdehnung der einzelnen Sektoren werden durch die
sogenannte Formatierung festgelegt.
Prinzipiell sind Magnetplattenspeicher auf wahlfreien Zugriff
ausgelegt. Dies bedeutet, dass das Medium nicht – wie z. B.
bei Bandlaufwerken – von Beginn an sequenziell durchsucht
werden muss, um eine bestimmte Stelle (Datei) zu finden.
Die Köpfe der Magnetplatten können – vergleichbar mit
dem Tonarm eines Plattenspielers und dem Anwählen eines
bestimmten Musikstücks – direkt zu der Stelle springen, an
der die gewünschte Datei angelegt ist.
Disketten
Alan Shugart, der in den späten 60er­Jahren für IBM arbeitete,
wird die Erfindung der 8­Zoll­Diskette im Jahr 1971
zugeschrieben. Die Diskette besteht aus einer Kunstofffolie,
die mit einer nichtorientierten Magnetschicht versehen ist.
Die Datenaufzeichnung erfolgt entweder einseitig (SS) oder
doppelseitig (DS). Zum Schutz und zur besseren Handhabung
befindet sich die Scheibe in einer rechteckigen Kunststoffhülle,
die mit einem Gleit­ und Reinigungsvlies ausgekleidet
ist. Die Hülle besitzt Öffnungen für den Arbeitskonus
(über den die Scheibe angetrieben wird), das Indexloch
und den Schreib­/Lesekopf. Zusätzlich besitzt die Hülle
noch eine Aussparung für das Setzen eines Schreibschutzes.
Je nach System wird der Schreibschutz durch
Abdecken oder Freilassen dieser Aussparung gesetzt. Der
Schreib­/Lesekopf berührt beim Schreiben und Lesen die
Diskettenoberfläche, ansonsten ist der Kopf angehoben.
1971 stellte IBM das erste 8­Zoll­Diskettenlaufwerk der
Öffentlichkeit vor. Damit wird zum ersten Mal bei einem
beweglichen Datenträger der wahlfreie Zugriff realisiert,
denn der Schreib­/Lesekopf kann auf jeder Stelle des
Datenträgers positioniert werden.
Disketten
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
225

Technologie-Anhang
Seine eigene Firma, Shugart Associates, gründete Alan
Shugart dann 1973 zur Entwicklung und Herstellung von
Diskettenlaufwerken. Schon lange wollte er Prozessoren und
Diskettenlaufwerke als Teile in komplette Computersysteme
integrieren. 1976 ist es Alan Shugarts Firma, die das erste
5,25­Zoll­Diskettenlaufwerk (Auftraggeber war die Fa. Wang
Laboratories) auf den Markt bringt. 1978 stellten bereits
zehn Firmen 5,25­Zoll­Laufwerke her. 1980 stellt Sony die
3,5­Zoll­Diskette der Öffentlichkeit vor. Dieses Diskettenformat
mit der gesteigerten Kapazität von 1,44 MB ist heute
noch in sehr alten PCs gebräuchlich. Die Miniaturisierung
bei den Diskettenlaufwerken brachte es u. a. mit sich, dass
eine Kombination von 5,25­Zoll­ und 3,5­Zoll­Floppy in einem
halbhohen Gehäuse unter gebracht werden konnte. Verschie­
dene 3­Zoll­(Amdisk) und 2­Zoll­Formate wie auch die LS­120­
Diskette (Panasonic, sogar abwärts kompatibel zur 1,44­ MB­
Diskette) und die Zip­Diskette (Iomega, 1994, 100 MB – 750
MB) konnten sich nicht mehr als Standard durchsetzen.
Festplatten
Die ersten Ansätze für mobile Festplatten sah man 1973.
IBM stellte 1973 die Festplatte „Winchester 3340“ vor. Kapazität:
35 MB. Der Entwicklungsname „Winchester“ verbindet
die damals angestrebte Speicherkapazität von ca. 30 MB pro
Module und einer Zugriffszeit von 30 ms mit dem amerikanischen
Gewehrtyp „Winchester 30­30“. Dieses Plattenmodul
war leicht zu transportieren, da es im Vergleich zum Vorgänger
IBM 3330 kleiner war und nur etwa die Hälfte wog
(siehe auch unter IBM 3340).
Wie funktionieren nun Festplatten? Eigentlich bis heute nach
dem gleichen Prinzip. Im einem luftdicht verschlossenen
Gehäuse (beinahe luftdicht, denn ein gewisser Luftaustausch
findet statt) sind mehrere übereinander rotierende Magnetplatten
montiert. Bei neueren Festplatten sind das – zur
Redu zierung der Bauhöhe – nur noch wenige Magnetplat­
ten. 1977 brachte Shugart das erste preiswerte Laufwerk
auf den Markt (14 Zoll, 30 MB). Die weitere Entwicklung
führte zu kleineren Platten. Seagate baute 1979 die erste
Festplatte im 5,25­Zoll­Format. 1981 kam SCSI und 1982
gab es die ST506­Schnittstelle von Seagate, aus der sich
IDE, E­IDE, ATA und ATAPI entwickelt haben. Das Seagate­
ST506­Laufwerk, nach dem die Schnittstelle benannt wurde,
verfügte (wie das RAMAC­Laufwerk aus dem Jahr 1956)
über eine Kapazität von 5 MB.
1996 hatte Seagate mit der Cheetah­Serie erste Festplatten
mit 10. 000 U/min präsentiert. 1998 bot die Seagate­Barracuda­
Serie eine Maximalkapazität von 50 GB. Nur zwei Jahre später
waren es schon fast 200 GB. Dies übertraf die bis lang
übliche Steigerung von 60% in einem Jahr oder die Verdoppelung
in 18 Monaten bei Weitem. Zwischen 1957 und 1990
lag die Steigerungsrate noch bei etwa 25% im Jahr. Die
Flächendichte auf den Festplattenscheiben stieg von 2.000
Bit/inch2 im Jahr 1957 auf über 1 Gbit/inch2 in den Jahren
1995 bis 1997.
1973: IBM 3340 Winchester-Wechselplatte 1990: IBM 3390 Montage der Zugriffsarme
226 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Im Schnitt: IBM 3390 Laufwerk
Die Datentransferraten der Festplatten waren mindestens um
das Zehnfache höher als bei Disketten, weil sich die Platten
mit bis zu 20facher Geschwindigkeit einer Diskette drehten,
je nach Typ zwischen 3.500 und 15.000 U/min. Jede Platte
besitzt mindestens zwei Lese­ und Schreibköpfe, die die
Platten auf der Ober­ oder Unterseite abtasten. Es gibt allerdings
auch Festplatten, die über mehrere Sets an Schreib­/
Leseköpfen verfügen, z. B. Festplatten in Hochleistungsrechnern
oder SCSI­Festplatten mit vier R/W­Köpfen,
wodurch die Zugriffszeit verringert wird. Durch das Rotieren
der Magnet scheiben entsteht ein Luftpolster, auf dem sich
dann die Schreib­/Leseköpfe bewegen. Diese sind mechanisch
über den Schreib­/Lesearm (Kamm) auch mit den
anderen Köpfen verbunden, sodass ein Spurwechsel für alle
Platten gleichzeitig vollzogen wird. Um die Bewegung von
Kopf zu Kopf zu beschreiben, hat man den Begriff des
1987: IBM 3380 Fertigung im IBM Werk Berlin 1990: IBM 3390 Montage
Zylinders eingeführt. Dieser umfasst alle Spuren, die die
gleiche Spurnummer tragen. Jede Platte ist also in Spuren
aufgeteilt, die in konzentrischen Kreisen um den Mittelpunkt
angeordnet sind (ähnlich einer Schallplatte). Spuren werden
mit den Nummern von 0 bis N bezeichnet, wobei N die
Gesamtzahl der Spuren minus 1 darstellt. Die äußere Spur
trägt die Nummer 0, die darauffolgende die Nummer 1.
Jede Spur nimmt dabei eine konstante Anzahl von Sektoren
auf, die die Spur in einzelne Abschnitte gleicher Größe
unterteilen. Der Aufbau gleicht also dem einer Diskette.
Jeder Sektor beinhaltet 512 Bytes an Daten (Fixed Block
Architecture FBA) und stellt zugleich die kleinste Zugriffseinheit
dar. Jede Festplatte verfügt über wesentlich mehr konzentrische
Spuren als eine Diskette, die Positionierungsgenauigkeit
ist höher und somit wird auch die mögliche
Speicherdichte größer.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 227

Technologie-Anhang
MFM (Modified Frequenz Modulation)
MFM setzte sich als neues Verfahren zur Übertragung von
Daten über den Schreib­/Lesekopf auf die Oberfläche der
Festplatte durch. MFM­Festplatten waren bis Mitte der 80er­
Jahre der Standard bei den PC­Festplatten. Sehr verbreitet
waren zuerst Festplatten mit einer Kapazität von 20, später
von 40 MB. Man bedenke: Zur gleichen Zeit passte ein komplett
lauffähiges MS­Word 2.0 auch noch auf eine 360­K­Diskette.
Aktuelle Motherboards haben keine Anschlüsse mehr
für diese Art von Festplatten, entsprechende 8­ und 16­Bit­
ISA­Controller können aber noch auf Flohmärkten erworben
werden.
Entwicklung Speicherdichte pro Produkt von 1956 bis 2000
RLL (Run Length Limited)
Prinzipiell ist der Aufbau mit dem der MFM­Festplatte identisch,
nur die Speicherkapazitäten waren größer. Das ergab
sich aus der verbesserten Oberfläche der Platten. Auch die
Steuerung der Laufwerke verbesserte sich sehr stark.
Dadurch wurden pro Spur 26 Sektoren möglich, was eine
erhebliche Erhöhung der Speicherdichte bedeutete. Von
RLL­Platten ist allerdings heute nur noch die Art und Weise
des Aufzeichnungsverfahrens übrig geblieben. Ansonsten
sind sie – wie die MFM­Festplatten – veraltet.
Jahr Produkt Bits/Inch (bpi) Tracks/inch (tpi) Areal Density
(MBit/inch2 Areal Density
)
(MBit/cm2 Kopftechnik
)
1956 350 100 20 0,002 0,00031 Schwebekopf
1957 355 100 20 0,002 0,00031
1961 1405 220 40 0,009 0,00140
1962 1301 520 50 0,026 0,00400 Flugkopf
1963 1311 1 025 50 0,051 0,00790
1964 2311 1 100 100 0,110 0,01700
1966 2314 2 200 100 0,220 0,03400
1971 3330 4 400 192 0,780 0,12100
1973 3340 5 636 300 1,690 0,26200
1976 3350 6 425 478 3,070 0,47600
1979 3370 12 134 635 7,800 1,20000 Dünnfilmkopf
1981 3380-D 15 200 840 12,000 1,86000
1985 3380-E 1 400 19,290 2,99000
1987 3380-K 15 240 2 083 36,000 5,47000
1989 3390-1/2 27 483 2 235 60,510 9,38000
1991 3390-3 29 718 90,000 13,50000 DFpl + MR
1991 9340/9345 24 130 4 450 111,000 16,00000
1993 3390-9 2 921 270,000 41,85000
1994 RAMAC 1 260,000 40,30000
1995 RAMAC 2 544,000 84,32000
1996 RAMAC 3 829,000 129,20000
1999 2105 ESS 2 758,000 427,50000 GMR-Lesekopf
2000 2105 ESS 5 516,000 855,00000
DFpl + MR = Dünnfilmplatte und Magnetoresistiver Schreib-/Lesekopf, GMR = Giant Magnetoresistiver Lesekopf
228 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

IBM Travelstar 60-GB-Serial-ATA-Laufwerk mit 7.200 RPM IBM Ultrastar 146-GB-Laufwerk mit 10 .000 RPM
Festplatten in den ersten IBM PCs
Der erste Schnittstellen­Standard für Festplatten wurde 1980
von Seagate entwickelt: ST­506. Dieser wurde in einer 5 MB
großen Festplatte mit eben dieser Modellbezeichnung verwendet.
Bereits ein Jahr später entstand – ebenfalls von
Seagate – der ST­412 Standard. Diese 10 MB große Festplatte
wurde u. a. im populären IBM XT (5160) verbaut. Diese
beiden frühen Standards unterschieden sich in einem
wesent lichen Aspekt von ihren Nachfolgern IDE/ATA und
SCSI: Sie hatten keine eigene Intelligenz. Die komplette
Steuerung wurde von einem komplex aufgebauten Controller
erledigt, an den sie mit zwei Kabeln angeschlossen
waren. Für die Steuerung der Plattenmechanik wurde der
Controller über ein 34­adriges Kabel mit der Platte verbunden,
für den Daten transport mit einem 20­adrigen Kabel. Die
ganze Sache war noch sehr fehlerträchtig und langsam,
denn die von den Schreib­/Leseköpfen verarbeiteten Daten
mussten erst auf den Controller transportiert werden, bevor
ein Fehler festgestellt werden konnte. Zudem waren diese
frühen Festplattenstandards aufwendig in der Installation.
Viele komplizierte Parameter (z. B. der „Interleave­Faktor“)
und die gesamte Geo metrie der Festplatte mussten von
Hand eingestellt werden, denn es gab noch kein BIOS, in
dem diese Werte voreingestellt gewesen wären. Und
Plug&Play (also die automatische Erkennung der Festplattengeometrie),
so wie wir es heute kennen, kam erst Mitte
der 90er­Jahre.
Der Nachfolger der MFM/RLL­Festplatten war die IDE­Festplatte
(Integrated Drive Electronics) von IBM. Aber auch
diese werden heute eigentlich nicht mehr verwendet, denn
die Kapazität war auf netto 504 MB begrenzt. Die heute verwendeten
Festplattenarten sind EIDE (Enhanced Integrated
Drive Electronics), SCSI (Small Computer Systems Interface)
und aktuell SATA (Serial Advanced Technology Attachment),
eine erst im Jahr 2001 definierte Weiterentwicklung von ATA
(Advanced Technology Attachment).
Der Unterschied lag bei diesen neueren Standards hauptsächlich
im Controllerbereich. SCSI­Festplatten waren zu der
Zeit noch etwas schneller, aber auch wesentlich teurer. Der
Vorteil von SCSI lag in seiner Flexibilität, denn so ziemlich
alle Arten von Geräten (Floppy, Streamer, CD­ROM, Festplatte,
Scanner etc.) können an einen SCSI Controller angeschlossen
werden, und zwar bis zu sieben Stück pro Controller
(Weiterentwicklung dann 16 pro Kanal). Ein EIDE Controller
konnte dagegen nur zwei Geräte verwalten, denn diese
Schnittstelle war eigentlich ausschließlich auf den Betrieb
mit Festplatten ausgelegt. Trotzdem gibt es auch für EIDE
mittlerweile CD­Laufwerke oder Streamer. Moderne Motherboards
enthielten oft bereits zwei integrierte EIDE Controller.
Dadurch konnten vier entsprechende Geräte betrieben werden,
was für die meisten Nutzer vollständig ausreichte. SATA
über trägt die Daten im Gegensatz zu allen anderen Systemen
seriell, d. h. Bit für Bit. Trotzdem werden Übertragungsraten
von bis zu 600 MB je Sekunde erreicht. SATA ist kompatibel
zum ATAPI­Standard und den verschiedenen ATA­Vorgängern.
Ein weiterer großer Vorteil: Eine Konfiguration entfällt fast
vollständig und Geräte können bei eingeschaltetem Rechner
ein­ und ausgesteckt werden (Hot­Plugging).
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 229

Technologie-Anhang
In den 80er­Jahren bis 1991 wurden groß dimensionierte
braune Platten gebaut. Die IBM 3380 Technologie mit 14­Zoll­
Platten, die später von 10,5­Zoll­Platten, der 3390 Technologie,
abgelöst wurden, beschäftigte sich konstant mit der Frage,
wie viel Kapazität unter einem Actuator, also unter einem
Schreib­/Lesekopf, verwaltet werden kann, ohne dass es zu
Warteschlangen kommt und die Leistungsfähigkeit des
Lauf werks beeinträchtigt wird. Aufgrund dieser Problematik
wurden auf dem Zugriff in der Regel 2 Schreib­/Leseköpfe aufgebracht.
Dabei war ein Kopf für den Innenbereich und der
andere für den Außenbereich der Platte zuständig.
Die induktive Aufzeichnung wurde bis 1991 verfolgt und
eingesetzt. Stellen wir uns einen solchen Aufzeichnungs­
Schreib­/Lesekopf als aufgeschnittenen Transformator mit
einer entsprechenden Kupferspule vor. Der Schreibvorgang
verlangt nun eigentlich wenige Kupferwindungen bei Verwendung
eines möglichst dicken Drahtes, damit möglichst viel
Strom transportiert werden kann und ein gut durchmagnetisiertes
Bit auf der Magnetschicht erzeugt wird. Das Lesen
eines Bits verlangt aber genau das Gegenteil, nämlich möglichst
viele Kupferwindungen bei einem möglichst dünnen
Kupferdraht, damit das Streufeld einer Informationseinheit
eine möglichst hohe induktive Spannung hervorruft, die dann
als eindeutiges Lesesignal abgegriffen werden kann. Der
Kopf wurde aufgrund der gegensätzlichen Anforderungen
bei der Anzahl der Windungen und der Dicke des Kupferdrahtes
so gestaltet, dass beide Vorgänge möglich waren.
Dieser Kompromiss schaffte aber eine direkte Abhängigkeit
bezüglich der Geschwindigkeit zwischen Kopf und Platte.
Drehte man zu schnell, wurde der Schreibvorgang schwierig,
drehte man zu langsam, reichte die Drehgeschwindigkeit
nicht aus, um eine entsprechend hohe induktive Spannung
zu generieren, die dann als sauberes Lesesignal abgegriffen
werden konnte. Der komplexeste Fertigungsprozess in dieser
Zeit war die Herstellung der Platte selbst.
Als Magnetisierungsträger wurden Eisenoxydpartikel, also
Rostpartikel, verwendet und die Kunst war es, diese Rostpartikel
möglichst homogen in einer Kunstharzmasse zu verteilen,
um dann einigermaßen gleichmäßig magnetisieren zu
können. Der Herstellprozess der Köpfe war im Vergleich dazu
einfacher.
Diese braunen Platten bereiteten Anfang der 90er­Jahre
(1990–1993) enorme Probleme, speziell bei den Modellen 1,
2 und 3 der 3390­Familie, weil sich nach langjähriger Benutzung
die Eisenoxydpartikel durch die andauernden Drehkräfte
aus der Kunstharzmasse herausarbeiteten und sich an
den Köpfen anlagerten. Die Anlagerung dieser Rostpartikel
erzeugte dann den berühmten Flugeffekt, d.h., der Abstand
zwischen den Köpfen und der Plattenoberfläche wurde
immer größer, bis eine Höhe eintrat, die es nicht mehr erlaubte,
dass geschrieben oder gelesen werden konnte. In einer einzigartigen
Aktion, die über zwei Jahre in Anspruch nahm,
tauschte die IBM damals alle weltweit installierten Plattenstapel
aus.
Bei der induktiven Aufzeichnungstechnik wurden lineare
Zugriffsmechanismen eingesetzt, die von der Mechanik
sehr aufwendig gestaltet waren, um den Kopf, der ja sowohl
für das Schreiben als auch das Lesen zuständig war, exakt
über einer Spur zu positionieren.
1991 verabschiedete sich IBM von der damals eingesetzten
induktiven Aufzeichnung und führte als erstes Unternehmen
MR-Technologie für die Kopftechnik (magnetoresistive
Aufzeichnung) bei den Produkten 3390 Modell 3 und 9 sowie
bei dem 9340 System mit seinen 5,25­Zoll­Platten ein. Heute
arbeitet jeder Hersteller mit dieser Technologie, die IBM entwickelt
hat. Die MR­Kopftechnik hatte so viel Potenzial für die
Weiterentwicklung, dass uns diese Technologie bis in die
heutige Zeit begleitet (2008). Der Unterschied zur induktiven
Aufzeichnung liegt darin, dass man nicht mehr mit einem
Prinzip der induktiven Aufzeichnungstechnik Prinzip der magnetor-resistiven Aufzeichnungstechnik
230 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Schreib­/Lesekopf arbeitet, bei dem die Anzahl und die Dicke
der Kupferspulen so ausgelegt sein muss, dass sowohl das
Schreiben als auch das Lesen möglich wird. Der MR­Kopf
verwendet nach wie vor für den Schreibvorgang einen
induk tiven Kopf, bei dem Anzahl und Dicke der Kupferspulen
jetzt aber so ausgelegt sind, dass ein optimaler Schreibvorgang
stattfinden kann. Mit dem Lesen hat dieser Kopf
nichts mehr zu tun. Damit werden wesentlich schnellere
Drehgeschwindigkeiten möglich. Für den Lesevorgang
macht man sich den „magnetoresistiven Effekt aus der Physik“
zunutze, dass Metalle oder Legierungen ihren Widerstand
verändern können, wenn sie in den Einfluss eines Magnetfelds
geraten. Gearbeitet wird in der Regel mit einem Nickel­
Eisen­Film, der an Schwachstrom angeschlossen ist. Gerät
dieser Slider in den Einflussbereich eines Magnetfelds,
ändert sich die Ausrichtung der Elektronen. Wenn man das
entsprechend verstärkt, bekommt man ein klares, eindeutiges
Lesesignal. Mit diesem Verfahren können selbst
kleinste Streufelder einzelner Informationseinheiten abgegriffen
werden. Auf diese Weise schafft man einen Spezialisten
für den Schreibvorgang und einen Spezialisten für den
Lesevorgang.
Parallel dazu, als zweites wichtiges Element, änderte sich die
Plattenherstellung. Die Laminierverfahren und Vakuumprozesse
waren inzwischen so weit, dass auf der Platte mit Dünnfilmbeschichtung
(Legierungen) gearbeitet werden konnte und
anstelle von Eisenoxyd nun ein Metallfilm zum Einsatz kam.
Der Metallfilm wird unter Vakuum auf eine speziell gehärtete
Glasplatte gesprüht (dieser Vorgang wird als Kathodenzerstäubung
bezeichnet). Anschließend läuft die Platte direkt
vom Vakuum in einen Ofen, um „gebacken“ zu werden (dieser
Vorgang wird als Sputtern bezeichnet). Durch den
Erhitzungs prozess (Sputtern) entstehen im Dünnfilm „Grains“,
also Körner strukturen, und die einzelnen Grains stellen die
Magnetisierungsträger der Platte dar. Die Herstellung solcher
Dünnfilm platten ist vom Prinzip bis in die heutige Zeit beibe­
halten worden und wird etwas später im Teil der AFC­Technik
näher beschrieben. Mit der Kombination von MR­Kopftechnologie
und Dünnfilmplatten war es möglich, die Aufzeichnungsdichte
von damals – 1991, bei der Einführung – 16
Millionen Bits auf dem Quadratzentimeter auf über 5 Milliarden
Bits auf dem Quadratzentimeter zu steigern. Das entspricht
einer Steigerung von über Faktor 300 und stellt eine
einmalige technologische Evolution dar, wie sie in
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 231

Technologie-Anhang
keinem anderen tech nologischen Segment vom Steige­
rungsfaktor her jemals erzielt wurde.
Der dritte treibende Faktor 1991 war die Einführung neuer
Subsystemarchitekturen, der RAID­basierenden Systeme.
Die RAID-Architekturen leiteten den Schritt ein, von großen
Plattengrößen in kleinere Formfaktoren zu wechseln. Die
kleinen Platten hatten zwar nicht den vergleichbaren Zuverlässigkeitsfaktor
wie die großen braunen Platten, die sogenannten
SLEDs (Single Large Expensive Disk), wie sie am
Schluss ihrer Lebensperiode bezeichnet wurden, benötigten
diesen aber auch nicht, weil Laufwerkausfälle in einem Array
durch RAID abgesichert waren (siehe auch unter RAID).
Im Jahr 1990 integrierte IBM in die damals gefertigten 5,25­
und 3,5­Zoll­Laufwerke ein neues Encoding­Verfahren, das
als PRML Encoding bezeichnet wird und heute noch im
Einsatz ist. Partial Response/Maximum Likelyhood
(PRML) ist ein Schreibverfahren, um Daten möglichst platzsparend
auf magnetische Datenträger zu schreiben. Dazu
werden diese Daten vorher codiert. Durch diesen Trick
erhält man eine höhere Datendichte auf der Oberfläche
einer Festplatte. Dies geschieht vom Nutzer völlig unbemerkt
durch den Controller der Festplatte. Im Gegensatz zu
älteren Verfahren wie MFM (Modified Frequence Modulation)
werden beim Lesen des Datenträgers keine einzelnen
Magnetfeld­Umkehrungen im analogen Signalstrom identifiziert
und deren Abfolge als Sequenz von Daten­ und Synchronisierungsbits
interpretiert. Stattdessen wird das analoge
Signal in Abschnitte zerlegt, diese aufbereitet („Partial
Response“) und das Ergebnis mit vorgegebenen Mustern
verglichen, um das ähnlichste zu finden („Maximum Likelyhood“).
Jedes der vorgegebenen Muster steht für eine
Einführung von PRML-Kanälen in IBM Platten
Platte Kapazität
Redwing 0681
Feb. 1990
Corsair 0663
Sep. 1991
Allicat 0664
Nov. 1992
Spitfire 0662
März 1993
Starfire-Reihe
0667/0668
Nov. 1993
GB
Durchmesser
Zoll
Datenrate
MB/S
bestimmte Bitfolge. PRML erlaubt eine 30 – 40 % höhere
Datendichte als MFM. PRML wird heute noch bei modernen
Festplatten eingesetzt, aber mehr und mehr von EPRML
(Enhanced) verdrängt, das wegen seiner verbesserten
Algorithmen und Signalverarbeitung 20 bis 70 % höhere
Datendichten ermöglicht.
PRML wurde 1990 erstmals für Platten der Systeme IBM
RS/6000 und AS/400 eingesetzt, weiterentwickelt und
danach auch bei damals vorrangig gefertigten 3,5­Zoll­Laufwerken
aller IBM Produktreihen genutzt, ebenso in vielen
Folgeprodukten. Entwickelt wurde das Verfahren im IBM
Labor in Rüschlikon bei Zürich.
Ein Beispiel: Wurden herkömmlich etwa 800– 900 durchma­
gnetisierte Grains benötigt, um eine stabile Informationseinheit
abzubilden, konnte durch das PRML­Verfahren im Laufe
der Jahre die Anzahl der Grains auf 200– 250 reduziert werden,
d. h. vierfach höhere Kapazitäten.
Die kapazitiven Auswirkungen von PRML sah man vor allem
von 1995 bis 1997, wo sich die Kapazitäten der damals produzierten
3,5­Zoll­Laufwerke innerhalb von 12 bis 15 Monaten
verdreifachten.
1997 wurde als Weiterentwicklung der MR­Köpfe die GMR-
Technologie, die giant­magnetoresistance Lesekopftechnik,
einge führt, die vor allem das Auslesen von kleinsten Streu­
feldern erlaubte. Den GMR-Effekt entdeckten Ende der
1980er­Jahre unabhängig voneinander Peter Grünberg an
der KFA in Jülich und Albert Fert an der Universität Paris­
Süd. Bei beiden Entdeckungen wurden extrem niedrige
Temperaturen und starke magnetische Felder zur Erzeu­
Aufzeichnung
Dichte Mb/sq“
Kopftype
Plattenart
232 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
PRML
0.857 5¼ 3 63 MIG Dünnfilm 1. Gen.
1.0/1.2 3½ 3 132 MR Dünnfilm 1. Gen.
2.0 3½ 5.2 264 MR Dünnfilm 2. Gen
1.0 3½ 5.2 354 MR Dünnfilm 2. Gen
1.0 – 5.2 3½ 12.2 564 MR Dünnfilm 3. Gen

gung des Effekts benötigt. Einige Zeit nach diesen Arbeiten
begannen Stuart Parkin und andere Forscher im Almaden-
Forschungs zentrum von IBM in San Jose, Kalifornien, mit
dem Versuch, den Effekt bei Normaltemperatur und mit
weniger exotischen Materialzusammensetzungen für die
Massenfertigung weiterzuentwickeln. Sie benötigten dazu
viele Jahre und erforschten mehr als 30.000 unterschiedliche
Multilayer­Materialkombinationen. 1997 erhielten die
drei genannten Forscher gemeinsam den Europhysik-Preis
für die GMR­Entwicklung. Peter Grünberg und Albert Fert
wurden zudem 2007 mit dem Nobelpreis für Physik ausgezeichnet.
Der GMR­Effekt (engl. giant Magnetoresistance, dt. Riesenmagnetwiderstand)
wird in Strukturen beobachtet, die aus
sich abwechselnden magnetischen und nichtmagnetischen
dünnen Schichten mit einigen Nanometern Schichtdicke
bestehen. Der Effekt bewirkt, dass der elektrische Widerstand
der Struktur von der gegenseitigen Orientierung der
Magnetisierung der magnetischen Schichten abhängt, und
zwar ist er bei Magnetisierung in entgegengesetzte Richtungen
deutlich höher als bei Magnetisierung in die gleiche
Richtung.
Dabei handelt es sich um einen quantenmechanischen
Effekt, der durch die Spinabhängigkeit der Streuung von
Elektronen an Grenzflächen erklärt werden kann. Elektronen,
die sich in einer der beiden ferromagnetischen Schichten
gut ausbreiten können, weil ihr Spin günstig orientiert ist,
werden in der zweiten ferromagnetischen Schicht stark
gestreut, wenn diese entgegengesetzt magnetisiert ist. Sie
durchlaufen die zweite Schicht aber wesentlich leichter,
wenn die Magnetisierung dieselbe Richtung aufweist wie in
der ersten Schicht.
Werden zwei Schichten eines ferromagnetischen Materials
durch eine dünne nichtmagnetische Schicht getrennt, so
richten sich die Magnetisierungen bei bestimmten Dicken
der Zwischenschicht in entgegengesetzten Richtungen aus.
Schon kleine äußere magnetische Felder reichen aber aus,
um diese antiferromagnetische Ordnung wieder in die ferromagnetische
Ordnung zurückzuführen.
In Verbindung mit dem GMR­Effekt bewirken Variationen des
äußeren Magnetfelds in geeigneten Strukturen daher große
Änderungen des elektrischen Widerstands der Struktur.
Die Möglichkeiten, den Effekt in einem Sensor für ein
magnetisches Feld einzusetzen (und damit als einen neuen
Typ von Lesekopf in einer Festplatte), wurden schnell durch
ein von Stuart Parkin geleitetes IBM Forschungsteam entdeckt,
indem er zeigte, dass der Effekt auch in polykristallinen
Schichten auftritt.
IBM stellte im Dezember 1997 das erste kommerzielle Lauf­
werk her, das diesen Effekt nutzte. GMR ist bis heute im Einsatz.
Neben der Anwendung in Festplatten wird der GMR­
Effekt auch in Magnetfeldsensoren der Automobilindustrie
und Automatisierungsindustrie ausgenutzt.
1999 konnten die ersten Micro-Drives – damals mit einer
Kapazität von 340 MB – auf dem kommerziellen Markt einge­
führt werden. Die Kapazitäten der Micro­Drives entwickelten
sich rasch weiter und heute, im Jahr 2008, werden bereits
Kapazitäten von 6 GB und 8 GB angeboten.
IBM Micro-Drive
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 233

Technologie-Anhang
Durch einen glücklichen Zufall entdeckten die IBM Entwickler
in der 2. Hälfte des Jahres 1999 die Möglichkeit einer neuen
Aufzeichnungstechnik. Man sprach und spricht heute noch
von der Entdeckung des paramagnetischen Effekts. Schon
am 4. Oktober 1999 konnte das IBM Labor in Almaden eine
Hard­Disk­Laborversion in dieser neuen Technik demonstrieren.
In einer Presseveröffentlichung am 4. Oktober 1999
wurde von einer Aufzeichnungsdichte von 35,3 Gbits/inch2 gesprochen – das sind über 5 Milliarden Bits auf den
Quadratzentimeter. Damit war die Sprengung der bis dahin
für MR­Technik gesehenen physikalischen Grenzen eingeleitet.
Mit dieser Technik lassen sich vierfach höhere Kapazitäten
auf demselben Raum realisieren!
Um die magnetische Beschichtung einer Festplatte heute zu
fertigen, wird unter Vakuum eine komplexe Legierung auf
eine Glasscheiben­Oberfläche gesprüht (Kathodenzerstäubung),
die anschließend „gebacken/gebrannt“ wird (Sputtern).
Dabei entstehen ca. 80–100 Nanometer große magnetische
Körner (MR­Technik). Für das Speichern von einem
Bit richtet ein induktiver Schreibkopf die magnetische Orientierung
von einigen Hundert solcher Partikel aus. Um Speicherdichten
zu vergrößern, versuchte man, die Zahl der Körner
zu reduzieren, die ein Bit bilden. Das hatte jedoch den
gravierenden Nachteil, dass sich das Signal­Rausch­Verhältnis
verschlech terte. Deshalb versuchte man, die Körner zu
verkleinern und die Anzahl beizubehalten, die ein Bit bilden.
Kommt allerdings die Korngröße unter ein bestimmtes Limit,
verlieren die Par tikel ihre ferromagnetischen Eigenschaften
(paramagnetisches Limit). Diesen Effekt kann man teilweise
ausgleichen, indem man „härtere“ magnetische Materialien
mit einer höheren Koerzitivfeldstärke verwendet. Problem
hier ist die Tatsache, dass „härtere“ Materialien wiederum
schwieriger zu magnetisieren sind und damit wesentlich
mehr Energie für die Magnetisierung benötigen.
Mit der Entdeckung des paramagnetischen Effekts und der
paramagnetischen Aufzeichnungsmöglichkeit wurde eine
Korngröße von ca. 25–30 Nanometer möglich, ohne dass
auf härtere Materialien ausgewichen werden musste. Das
bedeutete für die Aufzeichnungsdichte eine Vervierfachung
der Kapazitäten, die auf demselben Raum abgebildet werden
konnten.
Dem MR­Kopf wird ein Spezialkopf vorgeschaltet, der ein vertikales
Bit in der Metallkörnerstruktur erzeugt. Gleich danach
wird das horizontale Datenbit geschrieben. Beide Bits
stabi lisieren sich bei bestimmten Legierungen und lassen
es zu, das horizontale Datenbit wesentlich kleiner zu gestalten
und mit wesentlich höheren Drehgeschwindigkeiten und
Datenraten auf der Platte zu arbeiten.
Die Massenproduktion dieser Technik wäre sehr komplex
und kostenintensiv geworden. Deshalb beschritten die Entwickler
andere Wege. Dies führte dazu, dass IBM die
Massenproduk tion der sogenannten Pixie-Dust-Technologie
im Mai 2001 einleitete, was damals die gesamte Fachpresse
aufrüttelte, weil noch wesentlich höhere Kapazitäten bei noch
schnelleren Drehgeschwindigkeiten realisiert werden konnten.
Im Jahr 2000 erhielt die IBM als erste Firma die National
Medal of Technology for Innovations in Storage von der
amerikanischen Regierung, eine Auszeichnung, die bisher
ausschließlich an Einzelpersonen verliehen wurde. Grund für
die Auszeichnung: die Massenproduktion von Micro­Drives
und die Entdeckung des paramagnetischen Effekts. Sie ist
eine der höchsten technologischen Ehrungen.
Die AFC­Aufzeichnungstechnik (Pixie Dust) erlaubt es, bei
mittleren Korngrößen von 4–8 Nanometer im Dünnfilm eine
wesentlich höhere thermische Langzeitstabilisierung zu erzielen,
ohne dafür eine höhere Koerzitivfeldstärke des Materials
in Kauf nehmen zu müssen. Das heißt: Verwendung von
wesentlich kleineren Körnern als Magnetisierungsträger bei
weicheren Materialien. Dazu wird dem bisher verwendeten,
klassischen Metallfilm aus Kobalt, Platin und Chrom noch Bor
zugesetzt.
Prinzip der AFC(AntiFerromagnetically Coupled)-Aufzeichnungstechnik
234 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Diese Technologie nennt sich AFC (AntiFerromagnetically
Coupled) oder, von den IBM Forschern in Almaden geprägt,
„Pixie Dust“. AFC­Medien bestehen aus drei Schichten.
Zwischen zwei magnetischen Lagen, die aus einer komplexen
Kobalt­Platin­Chrom­Bor­Legierung bestehen, befindet
sich eine nur drei Atomlagen (6 Angström) dicke Schicht
aus dem nichtmagnetischen Metall Ruthenium. Bei
genau dieser Dicke sorgt die Ruthenium­Schicht dafür, dass
die Magnetisierungsausrichtungen der beiden anderen
magnetischen Schichten antiparallel gekoppelt sind. Das
heißt, die untere magnetische Schicht ist stets andersherum
magnetisiert als die obere Schicht. Dies führt zu einer
enormen Stabilisierung der beiden Bits und lässt erheblich
höhere Schreibdichten (bis zu 100 Gigabits pro
Quadratzoll und mehr – ca.15–20 Milliarden Bits auf
dem Quadratzentimeter) bei wesentlich höheren
Drehgeschwindig keiten und Datenraten zu. Wegen der
wundersamen Wirkung der Ruthenium­Schicht tauften
die IBM Forscher in Almaden diese neue Technik „Pixie
Dust“, also Feenstaub, angelehnt an Peter Pans Märchen.
Ein weiterer Vorteil liegt in der Tatsache, dass mit der heu­
tigen MR­Schreib­/Lesekopftechnologie weitergearbeitet
werden kann. Die Miniaturisierung dieser Köpfe ist heute
bereits so weit, dass Schreib­/Lesespaltbreiten von
1– 2 Nanometer als Laborversionen ermöglicht werden.
Dies stellt ein weiteres Potenzial dar, die Aufzeichnungsdichte
voranzutreiben.
Die Plattenaufzeichnungstechnologien werden sicherlich mit
der neuen AFC­Technik in kapazitive Bereiche von über 1 TB
in den Jahren 2010–2011 gehen können.
Wegen der Hitzeentwicklung in den Laufwerken muss man
sich immer mehr über das Packaging, im Speziellen die
Kühlung dieser Platten Gedanken machen. Wassergekühlte
Racks könnten eine Alternative darstellen. In der Entwicklung
befinden sich auch Möglichkeiten einer „Alttechnologie“, wie
sie bei den 3380 Platten eingesetzt wurde, allerdings in entsprechend
miniaturisierter Form. Dabei wird mit zwei Köpfen
auf dem Arm gearbeitet, der eine kontrolliert den Innenbereich
der Platte, der andere den Außenbereich. Dies ist eine
Möglichkeit, die Mehrkapazität unter dem Aktuator leistungsmäßig
auszugleichen, ohne die Drehgeschwindigkeit des
Plattenstapels massiv erhöhen zu müssen. Es bestehen also
Möglichkeiten, die Kapazitäten in den nächsten Jahren voranzutreiben.
Im Jahr 2003 gründeten IBM und Hitachi eine gemeinsame
Entwicklungs- und Fertigungs-Allianz für Plattenlaufwerke.
In dieser Allianz ist IBM für die Weiterentwicklung der Plattentechnologie
zuständig und Hitachi für die Massenproduktion.
Diese Allianz hat sich bis heute bewährt und es ist davon
auszugehen, dass sie noch viele Jahre Bestand haben wird
und auf andere technologische Bereiche ausgedehnt wird.
Inzwischen ist Hitachi der drittgrößte Plattenlieferant weltweit.
Das zweitgrößte Produktionsvolumen wird durch Western
Digital abgedeckt. Der größte ist nach wie vor die Firma
Seagate, die etwa 40 % des weltweiten Gesamtvolumens
produziert. Heute, im Jahr 2010, werden zwei Formfaktoren
produziert: 2,5­Zoll­ und 3,5­Zoll­Laufwerke.
Spätestens innerhalb der nächsten zwei Jahre – da sind
sich alle Plattenhersteller einig – wird generell nur noch mit
einem Formfaktor gearbeitet werden, weil sich kein Hersteller
bei Preisverfällen von etwa 40 % pro Jahr die Fertigung
von zwei unterschiedlichen Formfaktoren leisten kann. Die
3,5­Zoll­Laufwerke, die bisher vor allem in Plattensubsystem­
Architekturen eingebaut sind, werden durch 2,5­Zoll­Laufwerke
ersetzt.
Voraussetzung für diese Strategie ist die Produktion von
leis tungsstarken 2,5­Zoll­Laufwerken. Es kristallisiert sich
heraus, dass dann innerhalb der 2,5­Zoll­Bauweise drei
unterschiedliche Techniken eingesetzt werden: die AFC-
Technik, eine neue Technik mit Perpendicular Recording
und IDE­Platten, die als ATA­, SATA­ oder FATA­Platten
bekannt sind. Diese Vorgehensweise macht die Welt einfacher.
Nur noch ein Formfaktor, das bedeutet:
AFC als hochpreisiges Hochleistungslaufwerk mit extremer
Zuverlässigkeit, Laufwerke mit Perpendicular Recording als
mittelpreisiges Laufwerk mit guter Leistung und vergleichbarer
Zuverlässigkeit wie AFC und die billigen SATA­/FATA­Platten,
die vom Aufbau her IDE­Platten entsprechen.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 235

Technologie-Anhang
Perpendicular Recording
Bei Perpendicular Recording stehen die magnetischen
Momente, die zusammen mit den verwendeten logischen
Schreibverfahren wie PRML jeweils ein logisches Bit repräsentieren,
nicht parallel zur Rotationsrichtung des Datenträgers,
sondern senkrecht dazu. Dies führt zu einer potenziell
wesentlich höheren Datendichte, womit auf der gleichen
Ober fläche mehr Daten gespeichert werden können. Fest­
gestellt wurde dies erstmals bereits 1976 von Professor
Shun­ichi Iwasaki am Tohoku Institute of Technology in
Japan.
Nachteilig ist, dass die kleineren Weiß­Bezirke auch einen
kürzeren Abstand zwischen Schreib­/Lesekopf und der
Magnetoberfläche bedingen, um die Daten noch schreiben
und lesen zu können. Daher ist diese Aufzeichnungstechnik
technisch schwieriger zu realisieren. Das Gegenstück zum
Perpendicular Recording ist das bisher eingesetzte Longitudinal
Recording (englisch für Längsaufnahme). Hier tritt
jedoch bei zu enger Aneinanderreihung der Magnetpartikel
(zu hohe Datendichte) der sogenannte superparamagnetische
Effekt auf, d. h., die einzelnen Bits verlieren ihre
magnetische Richtung und beginnen zu „kippen“, was zu
Datenverlust führt. 3,5­Zoll­Festplatten erreichen somit eine
maximale Kapazität von derzeit 1 TB, 2,5­Zoll­Festplatten
kommen auf derzeit 320 GB. Das entspricht einer durchschnittlichen
Datendichte von 132 Gbit pro Quadratzoll
bzw. 20,46 Gbit pro Quadratzentimeter.
Die Festplattenkapazitäten können durch diese neue Aufzeichnungstechnik
um das maximal Zehnfache gesteigert
werden. Zudem wird durch die deutlich höhere Datendichte
ein Zuwachs der Lese­/Schreibgeschwindigkeit erreicht, da
der Lesekopf pro Umdrehung mehr Daten liest und damit
bei gleicher Umdrehungszahl die Datenrate steigt. Seagate
liefert bereits seit 2006 Platten mit Perpendicular Recording
aus.
Aufzeichnungsverfahren im Vergleich
HAMR (Heat Assisted Magnetic Recording)
HAMR (Heat Assisted Magnetic Recording) bezeichnet ein
Verfahren, das noch größere Datendichten bei Festplatten
erlaubt als das neue Verfahren mit Perpendicular Recording,
welches bereits die Marktreife erreicht hat. Somit sollen
künftig Festplatten mit Volumina im mittleren einstelligen
Terabytebereich möglich sein. Mit Hilfe von HAMR gelingt
das Schreiben von Daten auch auf Materialien mit einem
schwach ausgeprägten superparamagnetischen Effekt. Der
sogenannte Effekt tritt bei heutigen Festplatten auf, wenn
man die Datendichte zu sehr vergrößert. Dies bedeutet,
dass die Domänen, in die Daten geschrieben werden, ihre
ferromagnetischen Eigenschaften verlieren und superparamagnetisch
werden, wodurch die Bits zerstört werden.
Mit HAMR wird die Domäne, in welche Daten geschrieben
werden sollen, zunächst lokal durch einen Laser erhitzt, um
das für einen Schreibvorgang nötige Magnetfeld möglichst
klein zu halten und das Schreiben trotz eines schwach ausgeprägten
superparamagnetischen Effekts zu ermöglichen.
Da beim Erhitzen aber das schützende Schmiermittel der
Festplatte verdampft, will der Festplattenhersteller Seagate
Nachschub in nanometerdünnen Kohlenstoffröhrchen speichern,
welchen letztere bei Bedarf auf die betroffenen
Domänen sprühen sollen.
Es wird bereits spekuliert, welche Speicherkapazität mittels
dieser Technologie erreicht werden kann. So berichtet
itwire.com am 4. Januar 2007, dass es vielleicht bereits im
Jahr 2010, also heute, Kapazitäten von 37,5 TB von Seagate
geben könnte. Das wäre 37,5­mal so viel wie die zur Zeit
größte Festplatte von Hitachi mit rund 1 TB. Allerdings wird
auch berichtet, dass sich mittels dieser Technologie die
Anzahl der Head­Crashes erhöhen könnte und somit die
Qualität der Festplatte darunter leiden würde. Diese Spekulation
steht jedoch im Widerspruch zu der auf Techworld
zitierten Aussage von Seagate, wonach heute im Jahr 2010
mit 3­TB­Festplatten zu rechnen sei.
236 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software
Anhang 237

Technologie-Anhang
Plattenrotunde im IBM Museum Sindelfingen
Das Haus zur Geschichte der IBM Datenverarbeitung in
Sindelfingen, Bahnhofstraße 43
Im IBM Museum können heute zwei einzigartige Systeme
besichtigt werden, die Speichereinheit IBM RAMAC 355,
die 1957 auf den Markt kam, und das legendäre EDV­
System IBM 1401 mit Plattenspeicher IBM 1311, das im
Oktober 1959 angekündigt wurde und letztes Jahr 2009
den 50. Jahrestag feierte.
Besonders bemerkenswert ist die jetzt fertiggestellte Plattenrotunde,
die die IBM Geschichte der Magnetplatten von
1956 bis ins Jahr 2000 aufzeigt und viele Exponate der
unterschiedlichsten Technologien in diesem Zeitraum präsentiert.
Man kann sich im IBM Museum auf eine faszinierende
Zeitreise durch die Welt der IBM Magnetplattenspei­
IBM Plattenrotunde im IBM Museum Sindelfingen
cher begeben. Das absolute „Highlight“ der Rotunde sehen
Sie ganz links in der Plattenrotunde unter Plexiglas: Der
Zugriffsmechanismus der RAMAC 355, der funktional vorgeführt
werden kann. Dazu befindet sich direkt hinter der
Rotundenwand der dazu notwendige Kompressor (im Bild
nicht sichtbar).
238 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Die Initiatoren und Erbauer der Plattenrotunde im IBM
Museum waren die Herren Hans W. Spengler und Heinz
Graichen. Es dauerte über zehn Jahre, bis diese Arbeit fertiggestellt
und zur Besichtigung freigegeben werden konnte.
Allein schon die Datensammlung benötigte viele Jahre, die
vor allem von Hans W. Spengler vorangetrieben wurde. Er
hat dazu von jeder IBM Magnetplatte von 1956 bis ins Jahr
2000 ein Plattenprofil mit allen technischen Einzelheiten
erstellt und erfreulicherweise diese Profile für den Update
des IBM System Storage Kompendiums 2010 zur Verfügung
gestellt. Sie finden diese Profile auf den nächsten Seiten.
Der Autor des Kompendiums trug dazu bei, dass die im
IBM Werk Mainz gesammelten Ausstellungsstücke an das
IBM Museum vor ein paar Jahren überführt wurden, damit
mit dem Aufbau der Plattenrotunde begonnen werden
konnte. Ebenso finden Sie im Anschluss ein Interview, bei
dem der Autor die damaligen Fachleute Heinz Graichen und
Hans Spengler über den IBM RAMAC 350/355 Plattenspeicher
befragt, wie die Zugriffseinheit mit dem Schreib­/Lesekopf
nicht prinzipiell, sondern real arbeitete.
Hans W. Spengler
Heinz Graichen
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 239

Technologie-Anhang
Magnetplatten-Exponatesammlung Plattenrotunde IBM Museum in Sindelfingen
Anfangsepoche der elektromagnetischen Speicherung
Teilrotunde RAMAC 350/355 Zugriff und IBM 1301
Darstellung von 1956–1961
IBM RAMAC 350/355 Platte mit 24 Zoll Durchmesser
Jahre 1956–1957
IBM 1311 Zugriff 1962
240 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Epoche der Wechselplatten
Teilrotunde IBM 2314 offen (siehe unten) und IBM 3330
Darstellung 1965–1972
Epoche der Wechselplatten (Winchester-Zeit) und Epoche der fest
eingebauten Platten mit externen Kontrolleinheiten
Teilrotunde IBM 3340, 3350 und 3370
Darstellung 1973–1979
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 241

Technologie-Anhang
IBM 3340 Laufwerksdatenmodule 1973 IBM 3350 Festplatte 1975
IBM 3370 Laufwerk 1979
242 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Epoche der fest eingebauten Platten mit externen Kontrolleinheiten
Teilrotunde IBM 3380 und IBM 3390
Darstellung von 1981–1994
IBM 3380 Laufwerk 1981
IBM 3390 Laufwerk 1989
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 243

Technologie-Anhang
PC XT Festplatte 5 ¼ Zoll 1980
IBM Piccolo Laufwerk Hursley 1978
IBM 0681 – Laufwerk 5 ¼ Zoll mit PRML 1990
IBM RAMAC 9345 Laufwerkseinschub 1991
244 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Epoche der RAID-Systeme und Anfänge der Epoche der
Multiplattform-Systeme
Teilrotunde IBM RAMAC und IBM ESS
Darstellung von 1994–2000
IBM RAMAC 1, 2, 3 Platten 1994–1998
IBM ESS 9 GB SSA Laufwerke 1999–2000
IBM Travelstar 1996–1998 als mobile Platte in Laptops
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 245

IBM Magnetplattenprofile
Technische Spezifikationen
246 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software
Anhang 247

IBM Magnetplattenprofile
Technische Spezifikationen
248 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software
Anhang 249

IBM Magnetplattenprofile
Technische Spezifikationen
250 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software
Anhang 251

IBM Magnetplattenprofile
Technische Spezifikationen
252 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software
Anhang 253

IBM Magnetplattenprofile
Technische Spezifikationen
254 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software
Anhang 255

IBM Magnetplattenprofile
Technische Spezifikationen
256 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software
Anhang 257

IBM Magnetplattenprofile
Technische Spezifikationen
258 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software
Anhang 259

IBM Magnetplattenprofile
Technische Spezifikationen
260 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software
Anhang 261

IBM Magnetplattenprofile
Technische Spezifikationen
262 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software
Anhang 263

IBM Magnetplattenprofile
Technische Spezifikationen
264 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software
Anhang 265

IBM Magnetplattenprofile
Technische Spezifikationen
266 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software
Anhang 267

IBM Magnetplattenprofile
Technische Spezifikationen
268 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software
Anhang 269

Interview des Autors Kurt Gerecke
mit den RAMAC-Experten Heinz Graichen und Hans W. Spengler
Kurt Gerecke:
Warum war die Erfindung des Produktes RAMAC 305/350
so bedeutend?
Hans Spengler:
Dem ersten Produkt RAMAC 305 mit dem Magnetplattenspeicher
RAMAC 350 folgten ohne Unterbrechung über
Jahrzehnte weitere Entwicklungen von Plattenspeichern mit
dem Ziel, Kapazitätssteigerungen, Zugriffszeitverkürzungen,
höhere Datenraten und geringere Kosten pro gespeichertem
Megabyte zu erreichen. Den Startschuss für diese Entwicklung
leitete die RAMAC 350 ein. Diese Entwicklungsgeschichte
würdigte die American Society of Mechanical Engineers
1984 dadurch, dass sie den RAMAC Plattenspeicher
in Anerkennung des andauernden Einflusses auf die Plattenspeichertechnologie
zur „International Historic Mechanical
Engineering Landmark*“ erklärte (*Meilenstein).
Abb. 1
Kurt Gerecke:
Wie arbeitete der Zugriffsmechanismus der RAMAC
Plattenspeicher 350 (1956) und 355 (1957)? Ein einziges
Schreib­/Lesekopfpaar bediente alle 100 Speicherflächen.
Wie muss man sich die Positionierung des Schreib­/
Lesekopfpaares vorstellen?
Heinz Graichen:
Positionieren bedeutet, einen Weg zurückzulegen. Die 100
Speicheroberflächen sind auf 50 Trägerplatten aufgebracht
und deren Stapelhöhe beträgt etwa 53 cm. Auf jeder
Speicheroberfläche sind 100 Speicherspuren definiert. Die
äußerste Spur (00) ist von der innersten (99) etwa 12,7 cm
entfernt (Maximalweg = 78,4 cm). Das „in Position bringen“
des S/L­Kopfpaares lösten die Kontrukteure mittels eines
Wagens, der einen Zugriffsarm zunächst vertikal zur
gewünschten Platte bringt und dort in dieser Position fest
verriegelt. Danach wird in einer weiteren Phase der Zugriffsarm
horizontal bis zur gewünschten Spur bewegt und eben­
270 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

falls fest verriegelt. Die Grafik „Zugriffsstation als Zeichnung“
(Abb.1) lässt jeweils eingefärbt in Rot den Wagen
und in Grün den Zugriffsarm erkennen.
Hans Spengler:
Damit hat Kollege Graichen den Weg beschrieben, doch
dieser muss jetzt noch vollzogen werden. Ein raffiniert ausgedachter
Stahlseilantrieb mit Seilantriebsrolle (siehe Abb. 1
unten), Laufrolle (siehe Abb. 1 ganz oben) und zwei weitere
Rollen am Wagen selbst bewirken sowohl das Auf und Ab
des Wagens als auch das Rein und Raus des Zugriffsarmes.
Dazu muss die Seilantriebsrolle vor­ und rückwärts
laufen können. Dies bewirkt eine Magnetpulver­Doppelkupplung
für die eine oder die entgegengesetzte Drehrichtung.
Beide Hälften laufen auf einer gemeinsamen Welle,
die einen Tacho­Generator (siehe Abb. 1 links) und die Seilantriebsrolle
(siehe Abb. 1 rechts) treibt. Beide Kupplungshälften
sind konusförmig ausgebildet, damit der mit Gummi
belegte Konus des Zugriffsstationantriebsmotors die beiden
Hälften entgegengesetzt antreiben kann. Der Abtrieb zur
Seilantriebsrolle ist abhängig von der elektronischen Aktivie­
Abb. 2
rung einer der beiden Hälften. Der Zugriffsstationantriebsmotor
läuft ständig.
Kurt Gerecke:
Die Mechanik ist damit soweit klar. Doch wie setzt die Rechnerinstruktion
„Suchen“ die Zugriffsstation in die Lage, mittels
der Angaben zu Plattenoberfläche und Spur automatisch
entsprechende Bewegungen durchzuführen und umzusetzen?
Heinz Graichen:
Auf Basis der bisherigen Erklärung betrachten wir die Zeichnung
„Ablaufschema“ (Abb. 2). Ganz unten links finden wir
die Seilantriebsrolle, den Tacho­Generator und als „Black
Box“ die elektronischen Steuerstufen für beide Antriebskupplungshälften.
Die in die Box eingehende Steuerspannung
kann positiv oder negativ sein. Ist sie positiv, wird der
Wagen in die eine Richtung zur gewünschten Platte bewegt.
Ist sie negativ, wird der Wagen in die andere Richtung zur
ge wünschten Platte bewegt („rauf/runter“). Dies gilt sinngemäß
ebenso für die Bewegungsrichtung des Zugriffsarmes
(„rein/raus“).
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 271

Interview des Autors Kurt Gerecke
mit den RAMAC-Experten Heinz Graichen und Hans W. Spengler
Damit kennen wir bereits das Steuerungsprinzip der
Antriebs kupplungen, doch noch nicht die Umsetzung der
adressierten Speicherplatte (eine von 50) und adressierten
Speicherspur (eine von 100) in entsprechende Abläufe
und Bewegungswege.
Hans Spengler:
Für die Umsetzung des Steuerungsprinzips in Bewegungswege
sind weitere Elemente erforderlich, die Heinz Graichen
und ich aus umfänglichen Schaltbildern zu einem vereinfachten
Schema (siehe Abb. 2 „Ablaufschema“)
verdichtet haben. Das Wesentliche daran sind ein Adressrelais­Satz,
zwei Widerstandsketten, jede mit Relaiskontakt­
Kette, ein Nulldetektor und eine Schaltlogik, die die Abläufe
steuert, inklusive der Antriebskupplung­Steuerstufen.
Der Adressrelais­Satz: speichert die Disk­Plattenseite
(00­99), die Relaiskontakt­Ketten stellen Nullpotenzial für die
Zieladresse bereit und steuern die spätere S/L­Kopfauswahl.
Ebenso speichern Relais die Spuradresse (00­99). Die
Adressrelais sind „2 von 5­kodiert“ zwecks Gültigkeitsprüfung.
Widerstandsketten: Jeder Bewegungsschritt wird durch
einen Widerstand dargestellt. Hintereinandergeschaltet wird
damit jeder Bewegungsweg in Widerstandsgrößen repräsentiert.
An jede Widerstandskette ist eine nicht geerdete
Gleichspannung (150 V) angelegt. Jede Kette hat einen
Schleifkontakt, der die Ist­Position in Form einer Spannung
und deren Polarität abnimmt. Eine Kette dient der Disk­ und
eine Kette der Spur­Darstellung. Die Adressrelais­Kontaktkette
legt Nullpotenzial an die Zielposition an.
Nulldetektor: Wenn Ist­Position und Zielposition als Spannungsdifferenz
und Polarität am Nulldetektor anliegen, liefert
dieser das Signal „Nicht Null“, d. h., Bewegung in Richtung
Ziel ist einzuleiten. Wir betrachten das Beispiel Wagenbewegung.
Letzterer darf nur bewegt werden bei „Arm in Grundstellung“,
wenn dieser also „ganz ausgefahren“ ist. Danach
wird der Wagen erst entriegelt und dann solange bewegt,
bis das „Null Signal“ die Bewegung stoppt, den Wagen verriegelt
und dann über leitet zur Spurauswahl. Für letzteres
gilt analog dasselbe. Das „Null Signal“ stoppt die Armbewegung,
der Arm wird verriegelt, das Signal „Position gefunden“
wird generiert und die Schreib­/Leseköpfe werden geladen.
Kurt Gerecke:
Warum hat man die Widerstandskette für Disk und Arm nicht
einheitlich gestaltet?
Heinz Graichen:
Aus konstruktiven Gründen war es damals nicht möglich,
die Widerstandskette für Disk und Arm einheitlich zu gestalten.
Für den Arm kam ein Spezialpotentiometer mit 10 präzisen
Anzapfungen zusammen mit einer Messbrücke zum
Einsatz, um die Spuren 00 bis 99 per Widerstandskette
nachzubilden. Dies änderte jedoch nichts am angewandten
Prinzip. Das Potentiometer ist am Wagen befestigt und wird
durch die Zahnstange am Zugriffsarm und einem ebenfalls
am Wagen befestigten Zahnrad betätigt. Die Zahnstange
des Armes wird für ungeradzahlige Spuren durch einen
„odd detent“ verriegelt. Die geradzahligen Spuren verriegelt
der „even detent“. Dies verdoppelt die Zahngröße, die
Stabilität und damit die Zuverlässigkeit.
Kurt Gerecke:
Jetzt haben wir sowohl die adressierte Speicherfläche als
auch die adressierte Speicherspur erreicht. Der Zugriffsarm
trägt das Schreib­/Lesekopfpaar. Wie ist dieser „Pionier­
Schreib­/Lesekopf“ aufgebaut?
272 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Hans Spengler:
Der Kopfaufbau ist im Bild „350/355 Schreib­Lesekopf“ zu
erkennen: die Schreib­/Lesespule mit Joch (schwarz) sitzt
links und die Löschspule mit Joch liegt rechts. Die Jochflächen
sind gegen die Speicherplatte nach unten projiziert
und zeigen das Luftspaltmaß von 0,0254 mm und das
angewandte Prinzip „erase wide and read narrow“.
Das ganze magnetische Element wird durch eine konische
Bohrung im Zugriffsarm­Rahmen geführt (siehe Abbildung
„350/355 Schwebetechnik“ in Hellblau). Eine Haarnadelfeder
greift in beide Bohrungen der Kopfführungsstifte (F) ein und
drückt den Kopf an die Abdeckplatte, bis seine Führungsstifte
dort anschlagen. Dieser Zustand wird als „Kopf entladen“
bezeichnet. Um Lesen oder Schreiben vorzubereiten,
erzeugt die Steuerelektronik das Signal „Head Load“ (siehe
Abb. 2 „Ablaufschema“ unten rechts). Damit wird der „Head
Load Solenoid“ erregt. Dieser lässt Druckluft (DL) sowohl an
den sechs 0,1 mm großen, in sechskantform angeordneten
Bohrungen in der Gleitfläche des Elementes austreten als
auch gleichzeitig auf drei im 120­Grad­Winkel angeordnete
Zylinder mit Kolben wirken. Dadurch bewegt sich das
magnetische Element nach unten. Die ausströmende Luft
bewirkt an der planen Fläche den „Bernoully­Effekt“, der
die Schwebehöhe konstant auf 1/800 Zoll (0,02 mm) hält.
Zusammenfassung:
CPU (305):
•
•
•
Im Instruktionsstrom der zentralen Recheneinheit wird der
Suchbefehl dekodiert.
Transfer des Suchbefehls (Steuerwort) und der
Adresskomponenten zur Steuereinheit 652 und weiter zur
350/355.
Die zentrale Recheneinheit beendet die Einleitung der
Suchen-Instruktion und fährt im Instruktionsstrom fort.
350/355:
•
•
•
•
•
•
startet mit „Setzen Adressrelais“ die Abfolge der erforderlichen
Sequenzen.
Nullpotenzial aktivieren am Adress-äquivalenten Kontakt
der Widerstandskette „Disk“.
Entsprechend Nulldetektorausgang a) Nicht-Null = Arm
entriegeln und in Grundstellung bewegen. Anschließend
Wagen entriegeln und vertikal bewegen Richtung Zielplatte,
b) wenn „Disk-Null“-Ergebnis erreicht ist, den
Wagen verriegeln und Überleiten zum Start „Spursuche“.
Spursuche, mit dem Zugriffsarm horizontal, solange der
Null-Detektor „Nicht-Null“ abgibt, fahren. Wenn „Disk-Null“
erreicht ist, Arm verriegeln. Das Signal „Position gefunden“
generieren und Köpfe laden.
Damit ist die Zugriffsstation für eine Lese- oder Schreiboperation
vorbereitet. Dann wird durch die gehaltenen
Adressrelais der obere oder untere S/L-Kopf elektronisch
aktiviert.
Die Bewegungswege determinieren die Zugriffszeit. Minimalzeiten
ergeben sich bei Spurwechsel auf gleicher
Speicheroberfäche (11 ms). Mehr Zeit erfordern Vertikalbewegungen
des Wagens. Maximale Zeit wird von „oben
innen nach unten innen“ gebraucht (800 ms). Dabei fallen
zwei Zwischenstopps durch die Übergänge horizontal/
vertikal und folgend vertikal/horizontal an.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 273

Technologie-Anhang
Optische Speichertechnologien
CD-ROM (Compact Disc Read Only Memory)
1983 stellten Philips und Sony die CD­ROM vor, quasi ein
Ableger der Musik­CD. Das Medium ist auch ähnlich aufgebaut
wie die Musik­CD. Die Datenspeicherung erfolgt
während der Herstellung der Platte und die Daten können
nur gelesen werden (Analogie: ROM). Im Gegensatz zu
Magnetplatten erfolgt die Aufzeichnung – wie bei einer
Schall platte – in einer einzigen, spiralförmigen Spur. In
diese vorgeprägte, reflektierende Schicht werden bei der
Herstellung der Masterplatte mit einem Laser Löcher (Pits)
eingebrannt. Von der Masterplatte lassen sich dann
beliebig viele Kopien herstellen.
Die Kopie wird vom Laserstrahl abgetastet, der durch die
unterschiedliche Struktur der Speicherfläche mit einer digitalen
Information moduliert wird. Die Spurdichte beträgt bis
zu 16.000 Spuren/Zoll. Als Aufzeichnungsstandard hat sich
das Format ISO 9660 durchgesetzt (Transferrate: 1,2 MBit/s,
Kapazität: ca. 600 MB). Die CD­ROM dient hauptsächlich
der Verbreitung größerer Datenmengen, als Foto­CD und
jüngst auch als Videoträger. Die erste CD­ROM­Applikation,
die auf CD­ROM ausgeliefert wird, ist 1987 Microsoft Bookshelf.
1990 kommt der Commodore CDTV auf den Markt, ein
auf dem Amiga 500 basierender Computer mit integriertem
CD­ROM­Laufwerk. 1993 und 1994 gibt NEC den Takt mit
Dreifach­ (Triple Speed) bzw. Vierfach­CD­ROM­Laufwerk
(Quad Speed) an.
Bei der beschreibbaren CD­R ist der Aufbau komplexer als
bei der CD­ROM. Unten liegt die Trägerschicht aus Polycarbonat,
darauf folgt eine lichtempfindliche organische Substanz,
die durchscheinend ist. Dann kommt eine reflektierende
Goldschicht und schließlich eine Lack­Schutzschicht.
Mit erhöhter Laserenergie kann das organische Material verfärbt
bzw. verschmolzen werden und es erhält so eine
andere Reflexionseigenschaft. Die Platte kann danach wie
eine CD­ROM gelesen werden.
WORM (Write Once Read Many)
WORM­Platten lassen sich vom Anwender beschreiben,
jedoch nur einmal (Analogie: PROM). Bei 5,25­Zoll­Platten
sind Speicherkapazitäten von weit über 1 GB (Plasmon bietet
heute im IT­Umfeld basierend auf blauer Laser­Technik
60­GB­Platten an) möglich. WORM kann zur Archivierung
von Daten aller Art verwendet werden (Backup­Medium).
Die Platte arbeitet wie ein Magnetplattenlaufwerk und kann
genauso angesprochen werden, die Treibersoftware sorgt
dafür, dass bei mehrfacher Speicherung einer Datei immer
die jüngste Version angesprochen wird (ältere Versionen
lassen sich über spezielle Programme lesen) —> Speicherung
einer Dateichronologie. Beim Schreiben wird durch
hohe Laserenergie die Plattenstruktur dauerhaft verändert.
Beim Lesen wird diese Veränderung mit niedriger Laserenergie
abgetastet und detektiert. Man unterscheidet zwei
Speichertechniken:
Bei der Blasenerzeugung wird durch den Laserstrahl eine
Polymerschicht erhitzt, die unter einem dünnen Metallfilm
liegt. Es kommt zur Bildung einer Blase, die den Metallfilm
dauerhaft verformt. Bei der Abtastung mit geringer Laserenergie
kann die geänderte Streuung ausgewertet werden.
Bei der Pit­Erzeugung durchbrennt der Laserstrahl eine
lichtundurchlässige Schicht, die über einer Reflexionsschicht
liegt (Pit entsteht). Beim Lesen werden die so
entstandenen Hell­Dunkel­Zonen ausgewertet.
Ende der 90er­Jahre wurde die Haltbarkeit von Daten auf
WORM­Platten auf ca. 300 Jahre geschätzt.
274 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

120 mm Optical Disk im IT-Umfeld für Langzeitarchivierung (WORM, MO und
CCW)
MOD (Magneto Optical Disc)
Mit WORM verwandt ist die MOD, ein modernes Speichermedium
für Computer auf magnetisch­optischer Basis. Sie
erlaubt das digitale Aufnehmen und Löschen über Laser.
Die MOD enthält in Aufzeichnungsspuren geordnet bis zu
einer Milliarde Mikromagnete. Diese sind in einer
bestimmten Richtung vormagnetisiert. An den mit einem
Laserstrahl erwärmten Stellen lassen sich diese Mikromagnete
durch ein angelegtes Magnetfeld umpolen. Beim
Abtasten wird der Laserstrahl durch die nun verschieden
gepolten Magnete zirkular entweder rechts­ oder linksdrehend
zurückgeworfen (magneto­optischer Kerr­Effekt). Die
Änderung der Polari sation kann über eine entsprechende
Optik gelesen werden. Die MOD ist weniger lichtempfindlich
als die CD­R, kann schneller beschrieben werden, ist
unempfindlich gegen Nässe, hat eine hohe Lebenserwartung
und bietet hohe Datensicherheit.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 275

Technologie-Anhang
CCW (Continuous Composite WORM) basiert auf der MO­
Technik. Die Platte erhält bei der Produktion eine Kennzeichnung,
damit sie nicht überschrieben werden kann. Zusätzlich
schützt eine Software im Laufwerk die Platte vor dem
Überschreiben. CCW ist also eine „Schein“­WORM­Platte,
die auf der MOD­Technologie basiert.
Im IT­Umfeld wurden Anfang der 90er­Jahre die Technolo­
gien auf 120­mm­Basis (5,25 Zoll) als MO­, CCW­ und
WORM­Platten standardisiert. Die 120­mm­Technologie
findet bis heute ihren Einsatz im IT­Umfeld für Archivierungszwecke.
Optische Platten auf 90­mm­Basis (3,25 Zoll)
werden vorrangig im Consumer­Umfeld eingesetzt.
UDO (Ultra Density Optical Disk)
In den Jahren 2003 und 2004 wurde die 120­mm­Technologie,
die bis dahin mit einem roten Laser arbeitete, durch
einen neuen Standard ersetzt, die UDO­Technologie (Ultra
Density Optical). Die UDO­Technologie ist nicht rückwärtskompatibel
zur alten 120­mm­Technologie und arbeitet mit
einem blau­violetten Laser mit 405­nm­Wellenlänge. Die
Plattenformate WORM, MO und CCW wurden beibehalten.
UDO bietet ein „Phase Change“ WORM und „Phase Change“
Rewritable­Medium zum Einsatz an. Die ersten Platten auf
dieser neuen Laser­Basis als neuer 1­x­Standard boten eine
Kapazität von 30 GB. Die Zweitgeneration als 2­x­Standard,
der 2006 verfügbar wurde, bot das Doppelte an Kapazität,
also 60 GB. Die UDO­Technologie als neuer 120­mm­Standard
wird gemäß einer Roadmap weiterentwickelt, die im
UDO­Standard verankert wurde.
UDO Roadmap
Generation 1 Generation 2 Generation 3
Capacity 30 GB 60 GB 120 GB
Transfer Rate 8 MB/s 12 MB/s 18 MB/s
RPM 2 000 3 000 3 600
Avg Seek Time 25 ms 25 ms 25 ms
Numerical
Aperture
0.7 0.7 0.85
Media Layers 1 2 2
Encoding 1,7 1,7 ML
Sector Size 8 KB 8 KB 8 KB
SCSI Transfer
Rate
80 MB/s 80 MB/s 80 MB/s
Load Time 5 s 5 s 5 s
Unload Time 3 s 3 s 3 s
MSBF 750 000 750 000 750 000
DVD (Digital Versatile Disk)
DVD steht für „Digital Versatile Disk“ (ehemals „Digital Video
Disk“). Das Medium ist so groß wie eine normale CD­ROM,
jedoch wird mit einer wesentlich höheren Speicherdichte
gearbeitet. Dabei unterscheidet man vier verschiedene
Medien. Die einfache einseitige DVD kann 4,7 GB auf einer
Schicht speichern. Es gibt aber auch zweischichtige DVDs.
Dabei wird die Information auf zwei übereinanderliegenden
Schichten gespeichert, eine davon ist durchsichtig.
Durch unterschiedliche Fokussierung des Lasers wird die
richtige Schicht angesteuert. Damit sind 8,5 GB möglich. Und
dann gibt es das Ganze noch zweiseitig. Damit sind 17 GB
Daten auf einer einzigen DVD möglich. Die ersten Laufwerke
kamen in den 90er­Jahren auf den Markt und können einschichtige,
einseitige DVDs lesen. Leider gab es zu diesem
Zeitpunkt noch wenig DVD­Titel mit Videos. Die Videos wurden
in MPEG­2 kodiert, was eine sehr gute Qualität bei der
Wiedergabe ergibt. Auch die ersten Brenngeräte für einseitige,
einschichtige DVDs waren in den 90er­Jahren bereits
vorgestellt worden, der Brenner von Pioneer wurde im
Herbst 1997 für etwas über 10.000 DM angeboten. Aufgenommen
wurde mit ca. 1 – 2 MB/s und speichern konnte er
maximal 3,9 GB.
Die Lesegeräte können auch normale CDs lesen, jedoch
meist keine CD­Rs, also die beschreibbaren CDs. Dies
kommt daher, dass ein Laser mit einer kürzeren Wellenlänge
verwendet wird, der die selbst gebrannten CDs nicht mehr
richtig lesen kann. Sony hatte dazu ein Laufwerk mit zwei
Laser­Dioden entwickelt, mit dem man dann auch die CD­Rs
wieder lesen kann.
HD DVD
Die HD DVD (High Density Digital Versatile Disk, zuvor:
Advanced Optical Disk, kurz: AOD) ist ein Datenträgerformat
und wurde von 2005 bis Februar 2008 neben Blu­ray
Disc und VMD als ein mögliches Nachfolgeformat der DVD
gehandelt.
276 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Die HD DVD wurde durch das Advanced Optical Disc­Konsortium
(AOD) spezifiziert, dem u. a. NEC, Microsoft, Toshiba,
Intel, IBM und Hewlett­Packard angehörten. Danach haben
sich diese Firmen zur HD DVD Promotion Group zusammengeschlossen,
um die HD DVD effizienter bekannt zu machen.
Das DVD­Forum hatte im November 2003 die HD DVD als
HD­Nachfolger der DVD nach den HD­DVD­Spezifikationen
für Read­Only­Discs verabschiedet. Für die HD DVD wurde
der Kopierschutz Advanced Access Content System (AACS)
aus dem Bereich des Digital Rights Management (DRM)
vorgesehen.
Im März 2006 kam mit dem HD­XA1 von Toshiba der erste
HD­DVD­Player in Japan auf den Markt. Im August 2006
erschien mit Elephants Dream die erste HD DVD in deutscher
Sprache.
Im Februar 2008 erklärte Toshiba, dass man die Entwicklung,
Herstellung und Vermarktung der Technologie Ende März
2008 einstellen werde.
Die HD DVD basierte auf einem blau­violetten Laser mit
405 nm Wellenlänge. Die Dicke der Trägerschicht ist mit
0,6 mm identisch mit der der DVD. Die numerische Apertur
(NA) beträgt dagegen 0,65 im Vergleich zu 0,6 bei der DVD
und 0,85 bei der Blu­ray Disc.
Die HD DVD hatte mit einer Schicht ausgestattet eine Speicherkapazität
von:
•
•
•
15 GB (bei HD DVD-ROMs – gepresste Medien) bzw.
15 GB (bei HD DVD-R/RWs – einmal und wiederbeschreibbare
Medien) bzw.
20 GB (bei HD DVD-RAM – wiederbeschreibbare Medien
mit wahlfreiem Sektorzugriff)
und bei zwei Schichten eine Speicherkapazität von
•
30 GB (bei HD DVD-ROMs – gepresste Medien).
Zusätzlich wurde im August 2007 eine dreilagige Variante
durch das DVD­Forum verabschiedet, bei der pro Schicht
17 GB Platz fanden und die somit eine Gesamtkapazität von
51 GB hatte. Der endgültige Standard für Filme auf HD DVD
umfasste zunächst die 15­GB­ und die 30­GB­Variante,
wobei für Filme fast immer die zweischichtige 30­GB­Variante
verwendet wurde.
Im Januar 2008 gab Time Warner bekannt, dass seine
Studios Warner Bros. und New Line Cinema zukünftig keine
weiteren Filme für die HD DVD veröffentlichen werden, sondern
ausschließlich auf die Blu­ray Disc setzen. Dies wurde
von einigen Medien als Entscheidung des Formatkrieges
bezeichnet. In den darauffolgenden nächsten Tagen folgten
weitere Anbieter, so am 10. Januar der große europäische
Filmverleih Constantin Film, am 12. Januar der US­Pornoanbieter
Digital Playground und die deutsche Senator Film.
Die US­Anbieter Universal Studios und Paramount Pictures
dementierten hingegen Gerüchte, ihre Verträge mit HD DVD
aufzugeben, sie gelten als die letzten verbliebenen großen
Anbieter. Nachdem Toshiba, von denen ein Großteil der HD­
DVD­Player stammt, am 15. Januar die Preise der Geräte in
den USA teilweise drastisch reduziert hatte, sprachen einige
Medien von einem „Ausverkauf“. Auf der anderen Seite nahm
der Druck auf die HD DVD weiter zu: Anfang 2008 nahmen
Märkte der Media­Saturn­Holding beim Kauf eines Blu­ray­
Abspielgerätes den HD­DVD­Player in Zahlung. Weitere
Rückschläge musste das Format im Februar 2008 hinnehmen.
Die US­Elektronikkette Best Buy teilte am 12. Februar 2008
mit, sich zukünftig nur noch auf das Blu­ray­Format zu konzentrieren.
Einen Tag zuvor kündigte schon der größte US­
Online­Videoverleih Netflix an, dass er bis zum Jahresende
die HD DVD aus dem Sortiment nehmen wird. Am 15.
Februar 2008 kündigte zudem Wal­Mart, größter Einzelhändler
der USA, an, HD­DVD­Bestände auszuverkaufen und somit
in Zukunft nur noch auf Blu­ray setzen zu wollen. Am 19.
Februar 2008 gab Toshiba eine Pressemitteilung heraus, in
der bekannt gegeben wurde, dass die Entwicklung, Herstellung
und der Vertrieb der HD DVD sowie entsprechender
Geräte nicht weiter vorangetrieben wird und Ende März
2008 endgültig eingestellt wird. Daraufhin gaben die Universal
Studios noch am selben Tag bekannt, von der HD DVD
auf das Blu­ray­Format zu wechseln.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 277

Technologie-Anhang
Blu-ray Disc
Die Blu­ray Disc (abgekürzt BD oder seltener BRD) ist ein digitales
optisches Speichermedium. Sie wurde neben HD DVD
und VMD als ein möglicher Nachfolger der DVD beworben.
Nachdem Toshiba im Februar 2008 die Einstellung von
Produktion und Weiterentwicklung der HD­DVD­Technik –
einschließlich der Geräte – für März 2008 angekündigt hatte,
gilt die Blu­ray Disc als Sieger im Formatkrieg. Der Name
Blu­ray ist englischen Ursprungs. Blue ray bedeutet wörtlich
soviel wie „Blauer Lichtstrahl“, was sich auf den verwendeten
blauen Laser bezieht. Die bewusste Abweichung von
der orthografisch korrekten Schreibweise „blue ray disc“
zielt darauf ab, eine Registrierung des Ausdrucks als Marke
zu begünstigen.
Die Spezifikationen für die Blu­ray Disc wurden am 19.
Februar 2002 durch die neun Unternehmen der Blu­ray
Group, Panasonic, Pioneer, Philips, Sony, Thomson, LG
Electronics, Hitachi, Sharp und Samsung, beschlossen; dieser
Gruppierung schlossen sich Ende Januar 2004 zusätzlich
noch Dell und Hewlett­Packard sowie Mitte März 2005
Apple an. Hewlett­Packard trat allerdings 2005 wieder aus
dem Blu­ray­Konsortium aus, nachdem einige Verbesserungsvorschläge
abge wiesen worden waren, und wechselte
in das HD­DVD­Lager.
Die Blu­ray Disc gibt es in drei Varianten: als nur lesbare
BD­ROM (vergleichbar mit DVD­ROM), als einmal
beschreib bare Variante BD­R (vergleichbar mit DVD±R) und
als wieder beschreibbare BD­RE (vergleichbar mit DVD±RW).
Durch den Einsatz eines blau­violetten Lasers und dessen
kurzer Wellenlänge (405 Nanometer) lassen sich höhere
Datendichten erreichen als bei einer DVD. Pro Datenschicht
lassen sich 25 GB Daten auf einer BD­ROM speichern,
sodass sich bei zweischichtigen Medien eine Kapazität von
bis zu 50 GB ergibt.
Eine vierlagige Version der Blu­ray Disc, die auf einer Seite
um 100 GB fassen soll, wurde von TDK vorgestellt. TDK ist
es gelungen, auf einer sechslagigen Scheibe 200 GB unterzubringen.
Dabei wurde die Kapazität einer Lage auf 33,3 GB
erhöht. Dies sind jedoch in erster Linie Machbarkeitsstudien.
Von vornherein sind auch beschreibbare Medien vorgesehen,
soll die Blu­ray Disc doch vor allem in der Unterhaltungselektronik
ihre Heimat finden und als Speichermedium für
hochauflösende Filme dienen. Die wiederbeschreibbare
Blu­ray Disc arbeitet mit der Phase­Change­Technik.
Die neue Phase­Change­Technik soll eine doppelt so hohe
Übertragungsrate (Datentransferrate) von 9,0 MB/s (72 Mbit/s)
beim Beschreiben anstatt der ursprünglich maximal spezifizierten
einfachen 4,5 MB/s (36 Mbit/s) ermöglichen. Ein
wichtiger Bestandteil der Spezifikation ist auch ein Kopierschutz
in Form einer eindeutigen Identifikationsnummer.
Außerdem eignen sich Blu­ray Discs besonders gut für Full­
HD­Videos, die dank der hohen Auflösung eine bessere
Qualität als die gängigen Systeme wie PAL und NTSC bieten,
aber auch dementsprechend mehr Speicherplatz benötigen.
BD­Spieler unterstützen in der Regel das zuerst von Panasonic
und Sony eingeführte hochauflösende AVCHD­Format.
Eine weitere Neuerung gegenüber der DVD ist der verkleinerte
Abstand des Lasers zum Datenträger sowie die geringere
Wellenlänge (und daher andere Farbe) des Laserstrahls.
Weiterhin ist die Schutzschicht auf der Laser­Seite mit 0,1 mm
im Vergleich zu 0,6 mm der DVD deutlich kleiner. Aufgrund
der daraus resultierenden größeren Anfälligkeit gegen
Kratzer und Staub war zunächst geplant, die Blu­ray Disc
nur in einer Cartridge anzubieten. Stattdessen wurde jedoch
eine Beschichtung namens „Durabis“ entwickelt, die den
Gebrauch einer Cartridge nicht mehr notwendig macht.
Wegen des geringeren Abstands zwischen Medium und
Laseroptik sowie der dünneren Schutzschicht kann ein
Objektiv mit günstigerer numerischer Apertur eingesetzt
werden, das den Strahl effizienter bündeln kann. Somit werden
Schreibfehler und stärkere Streuungen verringert und
es ist möglich, eine Blu­ray Disc zum Beispiel aus Metall oder
anderen stabilen, undurchsichtigen Materialien kombiniert
278 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

mit einer dünnen durchsichtigen Trägerschicht zu bauen,
die mit erheblich höheren Drehzahlen als eine Scheibe aus
Polycarbonat betrieben werden können, woraus dann
höhere Übertragungsraten resultieren. Zudem erlaubt die
gegenüber der DVD kleinere Wellenlänge des Laserstrahls
eine wesentlich höhere Datendichte und damit eine erhöhte
Speicherkapazität.
Die Firma Verbatim stellte auf der IFA 2005 eine „Blu­ray
Disc Rewriteable“ vor. Dieses Medium soll laut Hersteller
eine Speicherkapazität von 25 Gigabyte erlauben (also
ca. 135 Minuten Video in MPEG2 HD­Qualität). Außerdem
soll die BD­RE mit einer besonders stoß­ und kratzfesten
Schutz schicht versehen sein. Neben der unmittelbaren
Verfügbarkeit von 25­GB­Rohlingen hat TDK für Oktober
2006 auch 50­GB­Discs in Aussicht gestellt. TDK ist eines
der Gründungsmitglieder der Blu­ray Disc Association
(BDA) und war maßgeblich an der Entwicklung beteiligt.
Holographic Versatile Disc (HVD)
Die Holographic Versatile Disc, auch HVD genannt, wird
bereits heute in Fachkreisen als Nachfolger der heutigen
HD­DVD­ und Blu­ray­Technologie gehandelt. HVDs haben
eine Kapazität von bis zu 3,9 TB und damit um ein Vielfaches
mehr als die größte heute zur Verfügung stehende
Blu­ray­Platte mit 200 GB. Auch die Transferrate ist um ein
Vielfaches höher und erreicht 1 Gbit/s im Vergleich zu
36 bzw. 72 Mbit/s bei der Blu­ray­Platte. Zudem ist die HVD
dabei noch lange nicht ausgereizt und es sind neue
Laufwerke mit noch höherer Rotationsgeschwindigkeit
denkbar. Die Spezifikation für die HVD wurde im Dezember
2004 durch das TC44 Committee der Ecma International
beschlossen. Bereits im Februar 2005 wurde die „HVD
Alliance“ gegründet, um die Entwicklung der HVD voranzutreiben.
Inzwischen gehören der Alliance 19 Firmen an:
Alps Electric Corporation, CMC Magnetics, Dainippon Ink
and Chemicals, EMTEC International, Fuji Photo Film,
Konica Minolta Holdings, LiteOn Technology, Mitsubishi
Kagaku, Nippon Kayaku, Nippon Paint, Optware Corporation,
Pulstec Industrial, Shibaura Mechatronics, Software Architects,
Suruga Seiki, Targray Technology, Teijin Chemicals,
Toagosei Company und die Tokiwa Optical Corporation.
Zwei überlagerte Laser mit unterschiedlicher Wellenlänge,
ein blau­grüner Schreib­/Leselaser mit 532 nm und ein roter
Positionierungslaser mit 650 nm, werden auf zwei unterschiedlichen
Lagen in der Platte reflektiert und erzeugen in
der photopolymeren Schicht ein Interferenzfeld, ein sogenanntes
Hologramm. In der schematischen Zeichnung sind
die beiden Laser zur Vereinfachung nicht überlagert dargestellt,
um das Prinzip der unterschiedlichen Reflexion besser
darzustellen.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 279

Technologie-Anhang
Beim Auslesen liest der blau­grüne Laser das Hologramm der
als Laser­Interferenz­Muster codierten Daten in der Polymer­
schicht im oberen Bereich des Mediums aus, während der
rote Laser dazu dient, Hilfsinformationen von einer CD­vergleichbaren
Aluminiumschicht im unteren Bereich auszulesen.
Die Hilfsinformationen dienen zur exakten Positionierung, wo
man sich gerade auf der Platte befindet (vergleichbar mit
Sektor­, Kopf­ und Segmentinformationen einer Festplatte).
Eine dichroitische Spiegelschicht (Reflexionsschicht), die sich
zwischen der Polymerschicht und der Aluminiumschicht
(Basisschicht) befindet, lässt den blau­grünen Laser reflektieren,
während der rote Laser hindurchgeht. Durch diesen
Trick wird die Interferenz durch Refraktion des blau­grünen
Lasers von den Hilfsdaten­„Pits“ verhindert und beide Informationen
(Hologramm und Hilfsdaten) können unabhängig
voneinander sauber angesteuert werden.
Polymere, also Kunststoffe, sind lange Kettenmoleküle, die
aus den immer gleichen Bausteinen bestehen. Sie haben
gegenüber Kristallen den Vorteil, nahezu unbegrenzt modifizierbar
zu sein. Polymere sind extrem lichtempfindlich,
hoch transparent und unempfindlich gegen Temperaturschwankungen.
Sie verändern auch nach häufigem Auslesen
ihre Leistungsfähigkeit nicht und sind ideal für die
Laserbearbeitung. Nach der Bestrahlung mit Laserlicht verändern
die lichtempfindlichen Moleküle im Polymer ihre
Ausrichtung. An den belichteten Stellen lenkt das Material
Licht stärker ab als an den unbelichteten Stellen. In dieser
als Interferenzfeld gezielten Veränderung der molekularen
Ordnung steckt die „holografische“ Information. Da die
Daten nicht als einzelne Bits, sondern als ganze Bitmuster
aufgezeichnet und gelesen werden, lassen sich mit einem
einzigen Laser­„Blitz“ extrem viele Bits gleichzeitig abrufen.
Je nach Polymerart und Polymerdicke können das mehrere
hunderttausend Bits sein. Die Übertragungsraten werden
gigantisch. Ein Spielfilm, der heute auf eine DVD passt,
könnte in etwa 30 Sekunden ausgelesen werden. Die große
Speicherkapazität kommt daher, dass die Hologramme nicht
nur auf die Oberfläche eines Speichermaterials geschrieben
werden, sondern in das gesamte Volumen.
Besonders sensible Daten könnten zusätzlich durch eine
spezielle Maske verschlüsselt werden, die zwischen das
Speichermaterial gesetzt wird. Im Gegensatz zu Informationen
(z. B. auf Chips), die über eine Software verschlüsselt
sind, ließe sich die Hardware­Verschlüsselung von Hologrammen
prinzipiell nicht knacken. Aus denselben Gründen
ist ein Hologramm auch schwer zu fälschen. Die Haltbarkeit
von Informationen in holografischen Speichern wird heute
auf etwa 50 Jahre geschätzt.
Flash-Speicher – Kurzgeschichte
Die Entwicklung des heutzutage bekannten Flash­Speichers
hat sich erst relativ spät in den 90er­Jahren zugetragen. Die
treibende Kraft war die digitale Fotografie. Schließlich ist es
praktisch unmöglich, in eine kleine Digitalkamera einen CD,
Brenner einzubauen, der die geschossenen Bilder direkt auf
die CD brennt. Ebenso wenig war die Diskette tauglich, da
sie einfach zu wenig Daten zu langsam speicherte. Die
Ende der 90er­Jahre von IBM entwickelten Microdrives, die
ein paar Jahre zu den Flash­Speicherkarten eine Alternative
bildeten, verbrauchten im Einsatz viel Strom, sodass der
Akku einer Digitalkamera häufig aufgeladen werden musste.
Auf Dauer waren deshalb die Microdrives keine sinnvolle
Alternative in der digitalen Fotografie.
Der erste Flash­Speicher wurde von Sandisk 1994 auf
den Markt gebracht. Er umfasste damals 4­MB­Speicher.
Mittlerweile ist diese Form der Datensicherung viele Technologieschritte
weiter, da man mit 4 MB Speicherkapazität
kaum etwas anfangen konnte. Heutzutage sind USB­
Sticks, die auf dieser Technologie basieren, mit mehreren
Gigabyte erhältlich.
Die Bezeichnung Flash­Speicher kam in den Laboren von
Toshiba zustande, wo der Forscher Shoji Ariizumi diesen
Namen vorschlug, da ihn das Löschen der Datenblöcke an
ein Blitzlicht (in Englisch: „Flash“) erinnerte.
Flash-Speicher einer Compact-Flash-Speicherkarte (Foto: SANDISK)
280 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Beschreibung und Funktionsweise
Flash­Speicher basieren auf Halbleitertechnologie und kommen
in allen heute verbreiteten Speicherkarten vor. Sie werden
in Hybrid­Festplatten oder Flash­Festplatten in Personal
Computern eingesetzt, aber auch in Speicherkarten für
Arbeitsrechner oder in schnellen Zwischenspeichern von
Großrechnern; darüber hinaus aber vor allem in SIMMs, PC­
Cards und PCMCIA­Karten, in Digitalkameras und MP3­Playern,
in USB­Sticks, Camcordern und Druckern, Notebooks
und Handhelds. Es gibt spezielle Flash­Module für Notebooks,
Laptops, PDAs, Drucker und andere Peripheriegeräte
wie Digitalkameras. Die verschiedenen Ausführungen
haben eine geschützte Bezeichnung und Schreibweise: Beispiele
sind die Compact­Flash­Karte (CF), die Smart Media
Card, Memory Sticks, die Multi Media Card (MMC), die SD­
Karte und andere mit Speicherkapazitäten von mehreren
Gigabyte (GB). Das Lesen von Flash Memorys kann in speziellen
Kartenlesegeräten durchgeführt werden, die über ein
Schnittstellenkabel wie USB mit dem Personal Computer
(PC) verbunden sind. Darüber hinaus können die Flash
Memorys auch über PC­Card­Adapter betrieben werden.
Die prinzipiellen Anforderungen an eine Speicherkarte
sind neben einer sehr kompakten Bauweise hohe Speicher­
kapazitäten, die Wiederbeschreibbarkeit, der Einsatz von
Strom unabhängigen Speicherbausteinen sowie eine möglichst
geringe Störanfälligkeit im mobilen Einsatz. Diese
Anforderungen waren und sind vor allem durch die digitale
Fotografie definiert.
Aufbau einer Flash-Speicherzelle mit Floating Gate
Im Gegensatz zu Festplatten haben Flash­Speicher keine
beweglichen Teile mehr integriert, das heißt mechanische
Komponenten einer Festplatte sind ausgeschlossen und
werden durch Halbleiter, also von elektrotechnischen Bauelementen,
bezüglich der Funktionsweise übernommen.
Diese müssen in der Lage sein, Daten dauerhaft und nicht
flüchtig, also Stromunabhängig, zu speichern. Auch wenn
die Stromversorgung abgebrochen wird, dürfen die Informationen
nicht verloren gehen.
Eine Flash­Zelle besteht aus einem modifizierten MOSFET­
Transistor (Metall­Oxid­Feld­Effekt­Transistor), der mit einer
zusätzlichen Elekrode, dem sogenannten „Floating Gate“,
ausgestattet ist. Diese Elektrode wird zwischen der Steuerelektrode
(Control Gate) und dem aktiven Transistorkanal
platziert und mit einer dünnen halbdurchlässigen Trennschicht
umgeben. Werden nun freie Elektronen mithilfe von
höherer Spannung (Schreibspannung) durch die Barriere,
meist eine Oxidschicht, hindurch auf das Floating Gate
„gepresst“, ändert sich das Transistorverhalten.
Jeder Transistor kann eine elektrische Ladung in Form von
Elektronen entweder leiten oder sperren. Dies entspricht
genau den binären Informationszuständen eines Bits, also
„0“ und „1“. Der Transistor gibt die gespeicherte Information
dann preis, wenn eine Spannung angelegt wird und je
nachdem, ob Strom fließt oder nicht, besitzt er die logische
Information „0“ oder „1“.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 281

Technologie-Anhang
Das Floating Gate ist elektronisch vollständig von allen
anderen Komponenten durch eine Oxydschicht isoliert,
damit die gespeicherte Ladung, also die Information auf der
Datenzelle darunter, auch wirklich in ihr gespeichert bleibt
und auch über längere Zeit nicht verloren gehen kann.
Unter normalen Umständen wäre durch diese Isolation eine
Übertragung nicht möglich, da die Isolation sie blockieren
würde. Der Flash­Speicher bedient sich deshalb des sogenannten
Tunneleffekts aus der Quantenmechanik, der es
ermöglicht, Ladungen auch durch ein nicht­leitendes Material
zu übertragen. Das Floating Gate wird je nach Menge
der aufgenommenen Elektronen zu einem elektronischen
Drosselventil für die Transistorfunktion. Beim Auslesen einer
Transistor­Speicherzelle wird der resultierende Strom als
Indikator für logisch „0“ (viele Elektronen im Floating Gate)
und logisch „1“ (wenige oder fast keine Elektronen im Floating
Gate) ausgewertet. Ein geladenes „Floating Gate“
reflektiert also „0“ und ein ungeladenes wird als „1“ gewertet.
Eine andere Zuordnung wäre möglich, wurde aber nie
angewandt. Jedes einzelne Bit wird damit über das „Floating
Gate“ übertragen. Für das erneute Beschreiben einer
bereits mit Information bestückten Datenzelle ist das vorhergehende
Löschen dieser notwendig. Der Grund hierfür ist,
dass man die Bits in einem Flash­Speicher immer nur von 1
nach 0 verändern kann. Nur ein Löschvorgang ermöglicht
es, diesen Zustand in die andere Richtung zu ändern.
Die schematische Abbildung „Aufbau einer Flash­Speicher­
zelle mit Floating Gate“ zeigt, wie das Floating Gate eine
Ladungsfalle bildet, in der die elektrische Ladung gespeichert
wird. Es liegt in einer Oxidschicht unterhalb des Control
Gates und verhindert im Normalfall den Ladungsabfluss
zu den N­ und P­Schichten (N = stark negativ dotierte Elektroden
Drain und Source, P = stark positiv dotiertes Substrat).
Die Ladung auf dem Floating Gate bildet über ihr
elektrisches Feld einen leitenden Kanal zwischen Drain und
Source, über den die Ladung ausgelesen wird. Das
Löschen erfolgt blockweise. Durch Anlegen einer negativen
Löschspannung werden die Ladungsträger aus dem Floating
Gate herausgetrieben.
Weitere Überlegungen
Flash­Speicher sind stromunabhängig und unterscheiden
sich deshalb grundsätzlich von stromabhängigen (volatile)
RAM­Bausteinen (Random Access Memory), denn die im
RAM­Hauptspeicher eines Computers gespeicherte Informationen
bleiben immer nur solange erhalten, wie der
Computer läuft. Ist der Computer ohne Strom, verlieren
RAM­Module die Fähigkeit, Daten zu speichern.
Ein klassich bipolarer Transistor benötigt Strom für mehrere
Funktionen. Zum einen werden Elektronen aus Siliziumflächen
des Transistors herausgelöst, um damit den Schaltzustand
zu verändern. Informationen werden auf diese Weise
gespeichert oder gelöscht. Zum anderen wird der Strom in
Form von „Refresh“­Impulsen benötigt, um den erreichten
Zustand zu stabilisieren.
MOSFETs hingegen sind in der Lage, mittels einer dünnen
Oxidschicht einen kleinen Kondensator aufzubauen, der
über ein einmal aufgebautes elektrisches Feld Ladungsträger
zwischen den Siliziumschichten transportiert. Dadurch
baut sich Spannung auf, bis ein Grenzwert erreicht wird. In
der Folge entsteht ein dünner leitender Kanal, der ohne
„Refresh“­Impulse stabil bleibt. MOSFETs benötigen also nur
Strom, um den Kondensator zu laden oder zu entladen,
während im anderen Fall Strom dauerhaft zugeführt werden
muss, um die Leitfähigkeit in einem stabilen Zustand zu halten
und die gespeicherte Information zu erhalten.
NAND-Architektur
Die Bezeichnung NAND, die den NAND­Flash­Speicher
beschreibt, kommt eigentlich aus der Aussagenlogik. Hier
wird ein Gatter beschrieben, das eine bestimmte UND­Verknüpfung
darstellt (Not AND = NAND). In die Welt der Elektronik
umgewälzt bedeutet es, dass die Speicherzellen auf
einem Flash­Speicher seriell geschaltet sind, also auf verschiedenen
Datenleitungen hintereinander gereiht sind.
Dabei werden die Metall­Oxid­Halbleiter­Feldtransistoren
über ein NAND­Gatter miteinander verbunden. Der große
Vorteil dieser Architektur ist, dass nur eine geringe Anzahl
an Datenspuren benötigt werden, da eine Spur mehrere
Speicherzellen enthält. Im Vergleich zur NOR­Architektur
kann somit eine Platzersparnis der Speicherzellen von weit
über 50 % erzielt werden.
282 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Die Zugriffszeiten der NAND­Architektur sind relativ hoch,
da man nicht auf einzelne Speicherzellen zugreifen, sondern
immer nur die ganze Leitung herauslesen kann. Man muss
die Daten also blockweise lesen. Dabei bedient man sich
der page­ und blockorientierten Arbeitsweise. Eine Page
besteht aus 512 bzw. 2.048 Bytes, die ihrerseits wieder zu
Blöcken zusammengefasst werden, die zwischen 16 und
128 KB liegen.
Wie bereits ausgeführt, kann man ein erneutes Beschreiben
eines Speicherbereichs, also einer Page, nur dann durchführen,
wenn man sie zuvor löscht. Da die Datenzellen seriell
geschaltet sind, muss man gleich den ganzen Block
löschen, in dem sich die jeweilige Page befindet.
Man verwendet NAND­Flashs in jenen Bereichen, wo
relativ viel Speicher gebraucht wird und das Flash­Module
klein und sehr kompakt gebaut sein soll. Etwas nachteilig
sind die langsameren Zugriffszeiten im Vergleich zur
NOR­Architektur.
NAND­Speicher oder auch SLC­Flash genannt (Single Level
Cell) haben sich aufgrund ihrer hohe Speicherdichte und
der kostengünstigen Produktionsweise gegenüber NOR­
Speichern weitgehend durchgesetzt.
NOR-Architektur
Als Gegenstück zum NAND­Speicher existiert der sogenannte
NOR­Speicher. Wie der Name schon vermuten
lässt, besteht dieser Speichertyp anstatt aus NAND aus
NOR­Gattern (Not OR). Dabei ergibt sich auch der Umstand,
dass die Speicherzellen eines NOR­Flashs parallel zueinander
geschaltet sind, wodurch ein paralleler und somit
wahlfreier Zugriff möglich wird. Man muss also beim Lesen
nicht Block für Block vorgehen.
Der parallele NOR­Flash verfügt über geringere Speicher­
dichte und ist vergleichsweise teuer, führt aber Abrufvor­
gänge wesentlich schneller aus. NOR­Speicher werden
auch als MLC­Speicher (Multi Level Cell) bezeichnet und
können aufgrund ihrer „Gitter“­Struktur flexibl angesprochen
werden. Durch ihren Aufbau verfügen sie verglichen mit
NAND­Speichern über relativ wenig Speicherplatz, da durch
die Parallelität einfach mehr Platz beansprucht wird.
Generell
NAND wird in großen Datenspeichern in kommerziellen
Systemen genutzt, weil damit kompaktere, schnellere und
preiswertere Speichersysteme gebaut werden können. Im
NOR­Speicher sind die Speicherzellen parallel auslesbar,
daher sind solche Speicher bei einem überwiegenden Lesebetrieb
besonders schnell und z. B. als Programm­ oder
Codespeicher sehr gut geeignet. NAND­Speicherzellen können
dichter gepackt werden. Dabei sind aber viele Speicherzellen
in Reihe geschaltet. Daher ist der wahlweise
Lesezugriff langsamer. Löschen und Schreiben gehen bei
NAND­Speichern schneller, wenn blockweise gearbeitet
wird. Die Speicherdichten bei NAND­ und NOR­Techniken
für Einbit­Zellen unterscheiden sich. Üblicherweise verwendet
NAND Einbit­Zellen und NOR Mehrbit­Zellen. Allerdings
gibt es beide Techniken inzwischen auch in Mehrbit­Varianten
mit zwei, drei oder vier Bits in einer Zelle. Generell sind
Mehrbit­Zellen langsamer und störanfälliger als Einbit­Zellen.
Mehrbit­Zellen (Multi Level Cell) haben dieselbe Zellgröße
und die Bits in der Zelle werden durch unterscheidbare
Spannungspegel definiert. Das erklärt die Kostenreduktion
von MLC­Speichern gegenüber dem SLC­Speicher (Single
Level Cell). Allerdings gibt es immer wieder Schwierigkeiten,
die geringen Spannungsunterschiede präzise auszulesen.
Deshalb sollte beim heutigen Stand der Technik im professionellen
IT­Betrieb aus Zuverlässigkeits­ und Geschwindigkeitsgründen
SLC­Flash in NAND­Technik eingesetzt werden.
Lebensdauer
Aufgrund ihrer Funktionsweise sind FLASH­Speicher nicht
unbegrenzt haltbar. Jeder Schreib­ und Löschvorgang verursacht
einen gewissen Verschleiß in den Oxidschichten
der Zellen, sodass die Hersteller von Flash­Speicherkarten
eine Art Mindesthaltbarkeit für ihre Produkte angeben, die
auf der Anzahl der durchgeführten Löschzyklen basiert.
Bei NAND (SLC) beträgt dieser Wert 100.000 Zyklen, bei
NOR (MLC) nur 10.000 Zyklen. Dabei wird immer ein
großzügiger Sicherheitspuffer mit einkalkuliert, d. h., NAND­
Speicherkarten können in der Regel auch nach einer Million
und mehr Löschzyklen funktionsfähig sein.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 283

Technologie-Anhang
Eine Art Defektmanagement erhöht zusätzlich die Lebensdauer
von Flash­Speicherkarten. Sobald der Verschleiß
innerhalb eines Blocks die Integrität der Daten beeinträchtigt,
wird dieser Block als defekt gekennzeichnet und die
dort abgelegten Daten auf einen Reserveblock umgelagert.
Diese Blockverwaltung kümmert sich zudem von Anfang an
um eine gleichmässige Verteilung der Schreibzugriffe, damit
die Blöcke möglichst gleichmässig und einheitlich abgenutzt
werden.
Steuerung
Die Steuerung, die das Defektmanagement durchführt, hat
maßgeblichen Einfluss auf die Leistungsfähigkeit einer
Flash­ Speicherkarte. Sie kümmert sich neben der Wartung
der Flash­Zellen vor allem um die Kommunikation der Speicherkarte
mit dem Endgerät und ist damit maßgeblich für
die Datentransferraten verantwortlich, die beim Lesen von
und beim Schreiben auf eine Flash­Zelle erreicht werden.
Die Zugriffszeiten liegen bei etwa 100 µs, die Lesegeschwindigkeit
liegt bei 25 MB/s und geht bis über 50 MB/s.
Neben der Geschwindigkeit ist auch die Zuverlässigkeit
bei der Datenkommunikation sowie das Protokoll, das für
ein reibungsloses An­ und Abmelden der Speicherkarte
beim Betriebssystem sorgt, Sache der Steuerung. Für diese
Steuerung werden Controller eingesetzt.
Bei den meisten heute verfügbaren Speicherkarten ist der
Controller in der Datenträgereinheit integriert, bei einigen
Modellen wird er aber auch extern eingesetzt, um eine noch
kompaktere Bauform zu erreichen. Der Nachteil der externen
Variante liegt darin, dass außen liegende Controller oftmals
mehr als ein Kartenmodell verwalten müssen und nicht
optimal auf die Anforderung jedes einzelnen abgestimmt
sind. Leistungsverlust und Kompatibilitätsprobleme können
dann die Folge sein.
Ausblick
Man geht heute von einer Zeitspanne von vier bis fünf Quartalen
zwischen zwei Flash­Generationen aus, bei der die
Kapazität mindestens um 50 % gesteigert oder in vielen
Fällen verdoppelt werden kann. Dies kann in den nächsten
Generationen ähnlich weitergehen, die Kurve könnte aber
stark abflachen! Deshalb wird bereits heute an neuen und
anderen Flash­Speichertechniken gearbeitet. IDC erwartet,
dass der Einsatz von Flash­Speichern in mobilen PCs von
heute fast 0 auf 20 % im Jahr 2011 steigen wird.
RAM – Random Access Memory
RAM ist die Abkürzung für Random Access Memory. RAM
wird auch als Arbeitsspeicher oder Hauptspeicher bezeichnet
und ist ein Speichertyp, dessen Speicherzellen über ihre
Speicheradressen direkt angesprochen werden können. In
diesem Zusammenhang wird auch von „wahlfrei“ gesprochen,
was sich auf „random“ bezieht und nichts mit „Zufall“
oder „zufälligem Zugriff“ zu tun hat. In diesem Zusammenhang
spricht man von „Speicher mit wahlfreiem Zugriff“ oder
„Direktzugriffsspeicher“.
RAM erlaubt den Zugriff auf jede einzelne Speicherzelle
sowohl lesend, wie auch schreibend. RAM Speicher benötigen
immer Stromzufuhr. Wird die Stromversorgung abgeschaltet,
gehen die Daten im RAM verloren.
RAM wird in Computer­ und Mikrocontroller­Systemen als
Arbeitsspeicher eingesetzt. In diesen Arbeitsspeichern wer­
den Programme und Daten von externen Speicherträgern
und Festplatten geladen. Zur schnellen Verarbeitung kann
der Prozessor darauf zugreifen, verarbeiten und danach
wieder in den Arbeitsspeicher schreiben.
Kurzgeschichte
Die Entstehung des Begriffs geht in die Anfangszeit der
Computer zurück, bei denen alle Daten auf sequenziell zu
lesenden Speicherformen wie Lochkarten, magnetischen
Trommelspeichern und Magnetbändern vorlagen, die zur
Verarbeitung in schnelle Rechenregister geladen wurden.
Um Zwischenergebnisse schneller als diese blockorientierten
Geräte bereitzuhalten, wurden zeitweise Verzögerungsleitungen
(engl. delay line) für Zwischenwerte eingesetzt,
bis dann die Ferritkernspeicher eingeführt wurden.
Diese beschreibbaren Speicher hatten schon die gleiche
Form des Matrixzugriffs wie heutige RAMs. Zu jener Zeit
waren die schnellen Speichertypen alle beschreibbar und
die wesentliche Neuerung bestand im wahlfreien Zugriff der
magnetischen Kernspeicher und der dann auf Halbleiterspeichern
aufsetzenden RAM­Bausteine.
Funktionsweise
RAMs sind Halbleiter­Speicher und es gibt prinzipiell zwei
Arten von RAM: SRAM als statisches RAM und DRAM als
dynamisches RAM. Bei statischen RAMs wird die Information
in rückgekoppelten Schaltkreisen (sogenannten Flipflops)
gespeichert, bei dynamischen RAMs in Kondensatoren,
deren Ladung periodisch aufgefrischt wird. Während
284 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

des Wiederaufladens hat der Prozessor (CPU) keinen Zugriff
auf den DRAM. Deswegen arbeiten Computer mit DRAMs
oft langsamer als solche mit SRAMs. Die Speicherkapazität
der DRAMs liegt jedoch deutlich über den von SRAMs.
SRAM ist statisch. Das bedeutet, dass der Speicherinhalt
mittels Flipflops gespeichert wird und so nach dem Abruf
des Speicherinhalts erhalten bleibt. Dadurch ist der Stromverbrauch
sehr hoch, was aber zu einem schnellen Arbeiten
innerhalb des Speichers führt. Aufgrund seines hohen
Preises und des großen Stromverbrauchs wird SRAM nur
als Cache­ oder Pufferspeicher mit geringen Kapazitäten
verwendet (z. B. L1­, L2­ und L3­Cache von großen Rechner ­
systemen). Sein Inhalt ist flüchtig (volatile), d. h., die
ge speicherte Information geht bei Abschaltung der Betriebsspannung
verloren. In Kombination mit einer Pufferbatterie
kann aus dem statischen RAM eine spezielle Form von
nicht flüchtigen Speicher­NVRAM realisiert werden, da
SRAM­Zellen ohne Zugriffzyklen nur einen sehr geringen
Leistungsbedarf aufweisen und die Pufferbatterie über
mehrere Jahre den Dateninhalt im SRAM halten kann.
DRAM ist im Vergleich einfacher und langsamer. Lange Zeit
war im Computer­Bereich für den Arbeitsspeicher nur dieser
eine Speichertyp mit seinen verschiedenen Varianten bekannt.
Eine DRAM­Speicherzelle besteht aus einem Transistor und
einem Kondensator, der das eigentliche Speicherelement
ist. Die Informationen werden in Form des Ladezustands
eines Kondensators gespeichert. Dieser sehr einfache
Aufbau macht die Speicherzelle zwar sehr klein, allerdings
entlädt sich der Kondensator bei den kleinen möglichen
Kapazitäten durch die auftretenden Leckströme schnell, und
der Informationsinhalt geht verloren. Daher müssen die
Speicherzellen regelmäßig wieder aufgefrischt werden.
Im Vergleich zum SRAM ist DRAM wesentlich preiswerter.
Deshalb verwendet man DRAM vornehmlich für den Arbeitsspeicher
eines PCs.
Phase Change Memories (PCM) – Phasenwechselspeicher
Schon in den 1920er­Jahren wurde beobachtet, dass sich
die elektrische Leitfähigkeit durch eine Strukturänderung
an einem Chalkogenid verändert. In den 1950er­Jahren
erforschte man die Halbleitereigenschaften kristalliner und
amorpher Chalkogenide. In den 1960er­Jahren fing man an,
reversible phasenwechselnde Materialien auf ihre elek­
trischen und dann auch optischen Eigenschaften zu untersuchen.
Chalkogenide sind chemische Verbindungen aus einem
oder mehreren Chalkogen­Elementen wie Sauerstoff,
Schwefel, Selen und Tellur, die mit anderen Bindungspartnern
(wie Arsen, Germanium, Phosphor, Blei, Aluminium und
andere) Feststoffe mit ionischem oder kovalentem Charakter
bilden. Die Feststoffe treten meist kristallin auf.
1968 wurden erstmals Phase Change Memories als mögliches
Speichermedium in Betracht gezogen. Jedoch war zu
diesem Zeitpunkt die Technologie noch nicht so weit, um mit
anderen Speichermedien wie DRAM und SRAM mitzuhalten.
Die Chalkogenide wurden jedoch speziell in der optischen
Speicherung weiter erforscht und fanden mit der CD­/DVD­
RW ihren Markt. Dabei wird mit einem Laser ein Punkt auf
einer CD erhitzt, sodass dieser seinen Zustand ändert
(amorph zu kristallin und wieder zurück).
Erst als im Zuge dieser Entwicklungen Materialien entdeckt
wurden, die bezüglich Schreibzeiten und ­strömen in interessante
Regionen kamen, bekam auch die Phase­Change­
RAM­Entwicklung wieder Fahrt.
Beim Phase Change Memory wird das Chalkogenid im
Gegensatz zur optischen Anwendung mit einem Stromimpuls
zur Phasenänderung angeregt. Durch das Wechseln
des Zustands ändert sich der elektrische Widerstand. Dabei
kann zwischen zwei oder auch mehr Zuständen unterschieden
werden und damit noch mehr in einer Zelle gespeichert
werden.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 285

Technologie-Anhang
PCM – Funktionsweise
Im Inneren eines Phase­Change­Speichers befindet sich
eine winzige Menge einer Halbleiterlegierung, die schnell
zwischen einer geordneten kristallinen Phase mit einem
niedrigeren elektrischen Widerstand und einer ungeordneten
amorphen Phase mit einem viel höheren elektrischen
Widerstand wechseln kann. Da die Aufrechterhaltung beider
Phasenzustände keine Stromzufuhr erfordert, ist der
Phasenwechselspeicher nicht flüchtig.
Der Phasenzustand des Materials wird durch die Amplitude
und Dauer des elektrischen Stromstoßes bestimmt, der für
die Erwärmung des Materials genutzt wird. Wenn die Temperatur
der Legierung bis etwas über den Schmelzpunkt
erhöht wird, verteilen sich die durch Energiezufuhr angeregten
Atome in einer zufälligen Anordnung. Wird die Stromzufuhr
dann abrupt unterbrochen, erstarren die Atome in
dieser willkürlich angeordneten, amorphen Phase. Wird die
Stromzufuhr über einen längeren Zeitraum – ungefähr 10
Nanosekunden – reduziert, bleibt den Atomen genug Zeit,
um in die bevorzugte, gut geordnete Struktur der kristallinen
Phase zurückzukehren.
PCM versus Flash
PCM schließt technologisch dort an, wo NAND­Flash an die
Grenzen der Machbarkeit stößt. Nach Ansicht vieler Experten
stehen der Flash­Technologie wegen ihrer beschränkten
Skalierbarkeit in naher Zukunft bereits große Probleme
bevor.
In den Almaden­Forschungslabors von IBM wurde in
Ko operation mit Macronix und Qimoda an neuen Speichertechniken
gearbeitet, die Flash­Memories ablösen können.
Die „Phase Change Memory“­Technologie (PCM) ermöglicht
bei kleineren Baugrößen deutlich höhere Geschwindigkeiten.
So verbessern sich die Eigenschaften von PCMs mit
kleiner werdender Größe. Es wird weniger Strom benötigt,
da weniger Material erhitzt werden muss, und es erhöht sich
aufgrund der kleinen Wege die Geschwindigkeit. Alles
Vorteile, die mit dem Kleinerwerden von PCM­Zellen erzielt
werden können. Allerdings schrumpft auch der elektrische
Widerstand mit dem Kleinerwerden der Zellen und es
wird dadurch schwieriger, die Zustände voneinander zu
unterscheiden. Deshalb ist es wichtig, hier eine gute
Balance zu finden.
„Gemeinsam ist es uns jetzt gelungen, ein neues Material
für Phase­Change­Speicher zu entwickeln, das auch
bei extremer Miniaturisierung hohe Leistung bietet“, sagt
Rolf Allenspach, Leiter der Gruppe Nanophysik am IBM
Forschungslabor Rüschlikon bei Zürich.
NAND­Flash ist derzeit zwar weiterhin im Kommen, jedoch
ist die Technologie noch teuer, die Kapazitäten für einen
alleinigen Einsatz in Computern zu gering und sie machen
bereits nach 100.000 Lese­ und Schreibzyklen schlapp.
Diese relativ schnelle Materialermüdung ist zwar bei Comsumer­Anwendungen
unproblematisch, sie disqualifiziert die
Module jedoch für den Einsatz als Haupt­ sowie Pufferspeicher
in Network­ oder Storagesystemen. Auf den Markt
drängen auch vermehrt Hybrid­Lösungen, die eine herkömmliche
Harddisk mit Flash­Modulen kombinieren, um
einen schnelleren Datenzugriff zu ermöglichen.
Die Flash­Memory­Technik dürfte ein künftiges Opfer der
Miniaturisierung werden. Neue Produktionsprozesse
machen in Chips zwar immer kleinere Leiterbahnen möglich,
beim Flash­Speicher ist nach aktuellen Forschungen jedoch
bei 45 Nanometer Schluss. Darunter verhindern Streuverluste,
dass sich ohne Stromzufuhr noch Daten speichern
lassen.
Die PCM­Module hingegen soll Produktionsprozesse bis
20 Nanometer und sogar darunter ermöglichen. Die theoretische
Grenze der Skalierbarkeit von PCMs liegt bei unter
5 Nanometer. Dabei verwenden die Entwickler für ihre
Speicher als neues Material eine Germanium­Legierung.
PCM – klein und universell einsetzbar
Zusammen mit hoher Leistung und Zuverlässigkeit könnte
PCM daher zur Basistechnologie für Universalspeicher in
mobilen Applikationen werden, denn Phasenwechelspeicher
sind wie Flash nicht flüchtig. Das bedeutet, sie merken sich
die Informationen auch dann, wenn kein Strom zugeführt
wird. Darüber hinaus weist der PCM­Prototyp von IBM sehr
vorteilhafte technische Werte auf: Er ist 500 Mal schneller
beschreibbar und benötigt dabei nur die Hälfte an Energie.
286 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Zudem seien deutlich mehr Lese­ und Schreibzyklen möglich
und die Bauelemente sind mit einem Querschnitt von
drei mal 20 Nanometer erheblich kleiner als die kleinsten
heute herstellbaren Flash­Speicher. „Sobald die Skalierbarkeit
von Flash endgültig an ihre Grenzen stößt, wird sich
eine neue Technik wie PCM durchsetzen“, ist Allenspach,
vom IBM Labor in Zürich, überzeugt. Dies könnte schon
bald möglich werden.
Heutige PCMs sind etwa 30 Mal schneller im Vergleich zu
Flash und bewegen sich im Bereich von 100 bis 200
Nanometer. Betrachtet man aber die schnelle Entwicklung
bzgl. Schreib­ und Lesegeschwindigkeit, eignet sich PCM
auch als Ersatz für heute übliches RAM. Mit PCM als Ersatz
von RAM würde das bisherige Booten von Computern
entfallen, allerdings könnten sich Sicherheitsprobleme
ergeben, da die PCMs nicht flüchtig sind (man könnte die
vertraulichen Daten im RAM wie z. B. Passwörter etc.
auslesen). Zudem hat PCM viel weniger Abnutzungserscheinungen,
wie sie etwa bei Flash durch den Verschleiß
der Oxidschicht am Floating Gate auftreten. PCM bietet
also eine lange Datenhaltbarkeit sowie einen nicht allzu
hohen Energieverbrauch beim Betrieb.
Millipede-Nano-Technologie
Mitte der 90er­Jahre wurde im IBM Grundlagenforschungslabor
in Rüschlikon das Projekt „Millipede“ gestartet. Das
Projekt hatte zum Ziel, Nano­Technologie und Nanospeicherarchitekturen
für die Datenspeicherung zu nutzen und in
Speichersubsysteme zu integrieren. Projektleiter in Rüschlikon
war der IBM Mitarbeiter Peter Vettinger und die technologisch
treibende Kraft war der IBMer und Nobelpreisträger
Gerd Binnig. Die Entwicklung von Millipede brachte IBM
viele neue Patente im Bereich der Nano­Technologie und
Nano­Mechanik ein und ergab viele neue Erkenntnisse über
Polymerstrukturen und die Möglichkeit, Kunststoffe als
Datenträger einzusetzen. Die Millipede­Entwicklung ist deshalb
für zukünftige Technologien von maßgeblicher Bedeutung.
Deshalb wurde das Projekt Millipede mit großem
finanziellem Aufwand bis ins Jahr 2007 aktiv weitergetrieben.
Grundprinzip
Das Grundprinzip ist simpel und ist mit dem der früheren
Lochkarte vergleichbar, nun aber mit Strukturgrößen im Bereich
von Nanometern. Ein weiterer entscheidender Unter­
schied: mithilfe der eingesetzten Technologie lassen sich Bits
löschen und überschreiben. Winzige Hebelchen mit einer
feinen Spitze aus Silizium schmelzen ebenso winzige Vertiefungen
in ein Polymer­Medium, um Bits zu schreiben.
Diesel ben Spitzen kann man auch verwenden, um diese Vertiefungen
nachzuweisen, also die Bits wieder auszulesen.
Dazu bringt man die Spitze in die Nähe des Polymerfilms
und erwärmt sie. Taucht die Spitze in einen Bit­Krater, erhöht
sich der Wärmeaustausch zwischen ihr und dem Speichermedium,
wodurch der elektrische Widerstand des Hebelchens,
auch Kantilever genannt, abnimmt. Um ein Bit wieder
zu überschreiben, erzeugt man mit der Spitze auf dem
Kraterrand neue Vertiefungen, deren Ränder die alte Vertiefung
überlappen und so das Polymer­Material in Richtung
Krater drängen.
Weil die Löcher so enorm klein sind, kann man sie sehr dicht
nebeneinandersetzen und so fantastische Datendichten erreichen:
Mit revolutionärer Nanotechnologie ist es IBM Wissenschaftlern
im Forschungslabor Rüschlikon gelungen, in
den Bereich der Millionstelmillimeter vorzudringen. So konnte
bei der Speicherung von Daten eine Aufzeichnungsdichte
von 1 Terabit pro Quadratzoll überschritten werden – was
etwa dem Inhalt von 25 DVDs auf der Fläche einer Briefmarke
entspricht. Die Terabit­Dichte wurde mit einer einzelnen Silizium­Spitze
erreicht, die Vertiefungen mit einem Durchmesser
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 287

Technologie-Anhang
von ca. 10 Nanometern erzeugt. Um die Datenrate, also die
Schreib­ und Lesegeschwindigkeit, zu erhöhen, wird nicht
nur eine Spitze verwendet, sondern eine ganze Matrix von
Hebelchen, die parallel arbeiten. Die neue Version verfügt
über mehr als 4.000 solcher Spitzen, die in einem kleinen
Quadrat von 6,4 Millimetern Seitenlänge angeordnet sind.
Diese Dimensionen ermöglichen es, ein komplettes Speichersystem
hoher Kapazität in das kleinste standardisierte Format
für Flash­Speicher zu packen.
Ein Kantilever im Millipede schreibt und liest aus einer ihm
zugeordneten rund 100 mal 100 Mikrometer kleinen Zelle.
Während sich beispielsweise bei Festplatten der Schreib­ und
Lesekopf und auch das Speichermedium bewegen, wird beim
Millipede­Speicher nur das Medium bewegt. Zwei winzige
Spulen, die zwischen Magneten platziert sind, treiben die
Bewegung des Plättchens an: Der Mikroscanner kann mit
einer Genauigkeit von bis zu 2 Nanometern positioniert
werden. Aus der überlappenden Fläche von streifenförmigen
Sensoren kann man die Position jederzeit präzise bestimmen.
Kantilever-Array
Kern der Millipede­Technologie ist eine zweidimensionale
Anordnung von v­förmigen Silizium­Federzungen (Kantilever),
die 70 Mikrometer (Tausendstelmillimeter) lang sind. Am Ende
jeder „Zunge“ befinden sich ein Sensor zum Lesen und ein
Widerstand oberhalb der Spitze zum Schreiben. Die Spitze ist
knapp 1 Mikrometer lang und der Radius beträgt nur wenige
Nanometer. Die Zellen mit den Kantilevern sind auf einem
Kantilever­Array­Chip angeordnet. Der Chip ist 7 x 14 mm
groß. Im Zentrum sitzt das Array, das momentan aus insgesamt
4.096 (64 x 64) Kantilevern besteht, die aus dem Silizium
herausgeätzt sind. Der eigentliche Datenträger besteht
aus einem nur wenige Nanometer dünnen Polymerfilm auf
einem Silizium­Substrat. Über Multiplexer einzeln angesteuert
lesen, schreiben oder löschen die Köpfe das gewünschte
Bit. Bis zu 100.000 Schreib­ und Überschreib­Zyklen sind
bisher erfolgreich getestet worden. Obwohl in der Konstruktion
Mech a nik eingesetzt wird, kann die Übertragungsgeschwindigkeit
von bis zu 20 bis 30 Megabit pro Sekunde erreicht
werden (beim Chip der 2. Generation mit 64 x 64 Tips).
Mikroscanner
Die Bewegung des Speichermediums relativ zu dem
Kantilever­Array wird mithilfe des siliziumbasierten x/y­
Mikro scan ners realisiert. Der Scanner besteht aus ca.
6,8 x 6,8 mm² Scan Table, der das Polymer­Medium und
zwei elektromagnetische Auslöser trägt. Der Scanner­Chip
wird auf der Siliziumplatte montiert, die als mechanischer
Grund des Systems dient. Der Abstand zwischen seiner
288 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Oberfläche und der Oberfläche von beweglichen Teilen des
Scanners beträgt ca. 20 µm. Die Scan Table kann durch
Auslöser in x­und y­Richtungen um 120 µm bewegt werden.
Jeder Auslöser besteht aus zwei Permanentmagneten, die
in die Siliziumplatte eingebaut sind, und einer kleinen Spule,
die sich zwischen den Magneten befindet. Um die Vibrationen
von außen zu löschen, wird ein sogenanntes Pivot verwendet,
das mit den Auslösern gekoppelt ist.
Positionsbestimmung
Die Informationen über die Positionierung werden durch vier
thermische Sensoren zur Verfügung gestellt. Diese Sensoren
befinden sich direkt über der Scan Table, auf dem Kantilever­
Array. Die Sensoren haben thermisch isolierte Erhitzer. Jeder
Sensor wird über einen Rand der Scan­Tabelle in Position
gebracht und wird durch Strom erhitzt. Ein Teil dieser Wärme
wird durch die Luft auf die Scan Table geleitet, die nun
als Kühler dient. Eine Versetzung der Scan Table verursacht
eine Änderung der Effizienz dieses Kühlsystems, was
zur Änderung der Temperatur des elektrischen Widerstands
vom Erhitzer führt.
Ein raffiniertes Design gewährleistet die exakte Nivellierung
der Spitzen über dem Speichermedium und dämpft Vibrationen
und Stöße von außen. Zeitmultiplexing­Elektronik, wie
sie in ähnlicher Art in Speicherchips (DRAM) verwendet wird,
ermöglicht die Adressierung jeder einzelnen Spitze im Parallelbetrieb.
Elektromagnetische Aktuation bewegt das Substrat
mit dem Speichermedium auf dessen Oberfläche sehr präzise
in x­ und y­Richtung, sodass jede Spitze in ihrem Speicherfeld
von 100 Mikrometern Seitenlänge lesen und schreiben
kann. Die kurzen Distanzen tragen wesentlich zu einem
geringen Energieverbrauch bei.
Für die Funktionen des Gerätes, d. h. Lesen, Schreiben,
Löschen und Überschreiben, werden die Spitzen mit dem
Polymerfilm auf dem Siliziumsubstrat in Kontakt gebracht.
Schreibtechnologie
Das Schreiben von Bits erfolgt durch Aufheizen des in den
Kantilever integrierten Widerstands auf typischerweise 400
Grad Celsius. Die dadurch ebenfalls aufgeheizte Spitze weicht
das Polymer auf, sinkt ein und hinterlässt eine Vertiefung
von wenigen Nanometern. Zum Lesen wird der Lese­Sensor
des Kantilevers erhitzt, ohne den Polymerfilm aufzuweichen.
„Fällt“ nun die Spitze in eine Vertiefung, kühlt sich der Lese­
Sensor wegen des geringeren Abstands zum Substrat geringfügig
ab, was aber zu einer messbaren Veränderung
des Widerstands führt. Um Daten zu überschreiben, setzt
die Spitze Vertiefungen in die Oberfläche. Deren äußere
Ränder überlappen die alten Vertiefungen und löschen so
die alten Daten. Mehr als 100.000 Schreib­ und Überschreib­
Zyklen haben den Nachweis erbracht, dass sich das Konzept
für einen wiederbeschreibbaren Speichertyp eignet.
Um die Daten schneller in den Speicher und wieder hinaus
zu bekommen, bearbeitet eine komplette Matrix­Anordnung
an Hebelchen das Medium gleichzeitig. Es stellte sich allerdings
heraus, dass es enorm schwierig ist, Mechanik und
Elektronik in einem Stück auf einem Chip zu fertigen. Die
Wissenschaftler entschlossen sich also, den Aufbau in zwei
Stücken zu realisieren:
1. Die Matrix der Mikrospitzen wird mit winzigen Kontaktstiften
versehen, die unter dem Elektronenmikroskop aussehen
wie die Noppen von Lego-Steinchen.
2. Diese Studs werden dann mit den Gegenstücken auf der
elektronischen Platine kontaktiert.
Mit den gezeigten Prototypen wurde unlängst die technische
Machbarkeit eines Produktes etwa hinsichtlich Speicherdichte,
Leistung und Verlässlichkeit demonstriert. Während
die heute eingesetzten Speichertechnologien allmählich an
fundamentale Grenzen stoßen, hat der nanomechanische
Ansatz ein enormes Entwicklungspotenzial für eine tausendfach
höhere Speicherdichte. Dieser nanomechanische Datenträger
entwickelt nahezu keine Wärme, nimmt nur wenig
Strom auf und ist völlig schockresistent.
Millipede-Projektphasen
Während der gesamte Projektlaufzeit wurden Chips in drei
Generationen entwickelt. Der letzte fertiggestellte Chip
im Jahr 2007 arbeitet mit 128 x 128 Tips, hat eine kapazitive
Speichermöglichkeit von 160 Gbytes und eine Datenrate
von 120 Mbit/s. IBM überlegt derzeit, wie und auf welche
Weise Millipede­Chips sinnvoll zum Einsatz kommen können.
Es bleibt also spannend, auf welche Weise Nano­Technologien
und Nano­Mechanik in die Welt der Datenspeicherung
Einzug halten werden.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 289

Technologie-Anhang
Revolutionäre Speichertechnologie aus der IBM Forschung rückt
näher an die Realisierung
„Racetrack Memory“ eröffnet neue Dimensionen in
Speicherdichte, Geschwindigkeit und Zuverlässigkeit
11. April 2008: IBM Forscher berichten im renommierten
Wissenschaftsjournal Science über einen Durchbruch in der
Erforschung einer neuen Speichertechnologie, die unter
dem Namen „Racetrack“ (deutsch: Rennstrecke) bekannt
geworden ist. Die Technologie könnte eine neue Klasse von
Speichern hervorbringen, die die hohe Leistungsfähigkeit
von Flash­Speichern mit der großen Kapazität und den niedrigen
Kosten von Festplattenspeichern auf sich vereint.
In der aktuellen Ausgabe von Science beschreiben IBM
Fellow Stuart Parkin und seine Kollegen vom IBM Almaden
Research Center, USA, einen bedeutenden Schritt in der
Entwicklung von Speicherbausteinen auf Basis des „Racetrack­Verfahrens“.
Innerhalb der nächsten zehn Jahre
könnte die Technologie zum Einsatz kommen und neue
Größenordnungen von Speicherkapazitäten eröffnen, ein
extrem schnelles Einschalten von elektronischen Geräten
ermöglichen und dabei wesentlich kostengünstiger,
energieeffizienter und robuster als heutige Systeme sein.
Stuart Parkin, IBM Fellow und einer der größten Speicher-Forscher und Entwickler bei IBM
Stuart Parkin war es zu verdanken, dass der GMR­Effekt
(Plattentechnologie, siehe unter GMR) zu einem Produkt in
Form eines GMR­Lesekopfes umgesetzt wurde, und er
benötigte sieben Jahre dazu. Ihm und seinem Team ist es
zu verdanken, dass die hohen Festplattenkapazitäten heute
möglich wurden. Der Autor findet es nicht richtig, dass
Stuart Parkin bei der Vergabe des Nobelpreies für Physik im
Jahr 2007 unberücksichtigt blieb, zumal der Nobelpreis an
drei Personen hätte verliehen werden können. Mit Racetrack
Memories wird er wirkliche Geschichte im Speicher bereich
schreiben! Davon ist der Autor überzeugt!
Universalspeicher der Zukunft
Das revolutionäre Konzept beruht auf der Speicherung von
Informationen in Form von winzigen, gegensätzlich magnetisierten
Regionen (Domänen) in einem Nanodraht. Bei der
herkömmlichen als Speichermedium verwendeten Festplatte
werden das Medium und ein Schreib­/Lesekopf bewegt, um
Daten zu lesen, zu schreiben oder zu löschen. Anders beim
„Racetrack­Verfahren“: Hier werden die magnetischen Domänen
zu den zentralen Lese­ und Schreibeinheiten, die in der
Mitte des Nanodrahtes angebracht sind, hin verschoben –
und dies mit extrem hoher Geschwindigkeit. Die gespeicherten
Datenbits scheinen durch den Datenleiter zu „rasen“, daher
der Name „Racetrack“.
290 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Da ein einzelner ‘Racetrack’ nur wenige Nanometer groß ist
und zwischen 10 und 100 Bits speichern kann, erlaubt die
Technologie extrem hohe Speicherdichten. Im Vergleich zu
Flash­Speichern könnte ein ‘Racetrack­Speicher’ eine 100mal
größere Datenmenge auf derselben Fläche aufzeichnen.
Das entspräche rund 500 000 Musiktiteln oder 3 500 Filmen.
Durch den minimalen Stromverbrauch eines ‘Racetrack­
Speichers’ könnte ein MP3­Gerät zudem wochenlang mit
einer einzigen Batterie betrieben werden.
Darüber hinaus benötigt das Verfahren keine beweglichen
Teile, wodurch nahezu keine Abnutzungs­ oder Verschleißerscheinungen
auftreten. Das macht den ‘Racetrack­Speicher’
widerstandsfähiger als alle existierenden Speichertechnologien
und verleiht ihm eine quasi unbegrenzte Lebensdauer.
„Die Verbindung zwischen der Erforschung von neuen
physi kalischen Phänomenen, die auf der molekularen und atomaren
Ebene auftreten, und dem Nano­Engineering – der
Fähigkeit, gezielt Materialstrukturen aus einzelnen Atomen
Da ein einzelner „Racetrack“ nur wenige Nanometer groß ist
und zwischen 10 und 100 Bits speichern kann, erlaubt die
Technologie extrem hohe Speicherdichten. Im Vergleich zu
Flash­Speichern könnte ein „Racetrack­Speicher“ eine 100mal
größere Datenmenge auf derselben Fläche aufzeichnen.
Das entspräche rund 500.000 Musiktiteln oder 3.500 Filmen.
Durch den minimalen Stromverbrauch eines „Racetrack­
Speichers“ könnte ein MP3­Gerät zudem wochenlang mit
einer einzigen Batterie betrieben werden.
Darüber hinaus benötigt das Verfahren keine beweglichen
Teile, wodurch nahezu keine Abnutzungs­ oder Verschleißerscheinungen
auftreten. Das macht den „Racetrack­Speicher“
widerstandsfähiger als alle existierenden Speichertechnologien
und verleiht ihm eine quasi unbegrenzte Lebensdauer.
„Die Verbindung zwischen der Erforschung von neuen
physi kalischen Phänomenen, die auf der molekularen und
atomaren Ebene auftreten, und dem Nano­Engineering –
der Fähigkeit, gezielt Materialstrukturen aus einzelnen
Atomen und Molekülen zu erschaffen – birgt immer neue,
spannende Herausforderungen“, erklärt Stuart Parkin.
Er führt weiter aus:
„Ein Ausschöpfen des Potenzials, das in unserer
„Racetrack­Technologie“ liegt, könnte zu faszinierenden
neuen Anwendungen führen – Anwendungen, die heute
noch unvorstellbar sind.“
Schematische Darstellung der Racetrack-Memory-Speicherung
Bereits mehrmals in der Geschichte der IBM wurden
durch radikale technische Innovationen, die in der Grundlagenforschung
ihren Anfang nahmen, neue Märkte und
Anwendungs felder erschlossen. Hierzu zählen etwa der
Memory Chip, die relationale Datenbank oder die Festplatte.
Die „Racetrack-Methode“
Seit rund 50 Jahren versuchen Wissenschaftler, digitale
Informationen durch sogenannte magnetische Domänenwände
– die Grenzflächen zwischen zwei gegensätzlich
magnetisierten Regionen in einem magnetischen Material –
zu speichern. Bis jetzt war die Manipulation von Domänenwänden
nur durch kostspielige, komplexe und energieintensive
Verfahren möglich.
In ihrer nun veröffentlichten Arbeit „Current­Controlled
Magnetic Domain­Wall Nanowire Shift Register“ demonstrieren
Parkin und seine Teamkollegen eine neue, sehr effiziente
Methode. Hierbei werden die Domänenwände durch einen
spinpolarisierten Strom bewegt, der die Magnetisierung in
der Wand drehen kann. Ursache hierfür ist der Spintransfer­
Effekt, der die Speichertechnologie erheblich vereinfacht,
weil der Strom direkt durch die Domänenwände fließt und
keine zusätzlichen Magnetfelder generiert werden müssen.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 291

Technologie-Anhang
In der zweiten Arbeit „Magnetic Domain­Wall Racetrack
Memory“ fassen die Forscher die Grundprinzipien der
„Racetrack­Technologie“ zusammen. Diese beruht auf der
Speicherung von Daten in winzigen magnetischen Regionen
innerhalb eines Datenleiters. Als Datenleiter verwenden die
Forscher kleine Nanodrähte, die magnetisch mit Informationen
beschrieben werden. Diese werden der Länge nach
waagerecht oder in Form einer Schlaufe senkrecht auf einer
Siliziumfläche angebracht. Wenn eine Spannung angelegt
wird, bewegen sich dabei weder die Drähte noch das
Silizium, sondern nur die magnetischen Domänenwände,
in denen die Information gespeichert wird.
Jede magnetische Domäne, die ein Bit repräsentiert, verfügt
über einen „Head“, einen magnetischen Nordpol, und einen
„Tail“, einen magnetischen Südpol. Die Domänenwände,
die sich an den Grenzflächen formen, wechseln sich so im
Datenleiter zwischen „Head­to­Head“­ und „Tail­to­Tail“­
Konfigurationen ab. Die Abstände zwischen zwei hintereinander
folgenden Domänenwänden gleichen der Bit­Länge
und werden durch Markierungen entlang des Nanodrahtes,
so genannte Pinningzentren, bestimmt.
In ihrem Experiment verwendeten die Forscher Nanodrähte
aus Permalloy (einer FeNi­Legierung) und zeigten, wie
sie Domänenwände gezielt kreieren, verschieben und auslesen,
indem sie Stromimpulse von präzise kontrollierter
Dauer im Nanosekundenbereich verwenden. Der Schreibund
Verschiebe zyklus benötigt gerade einmal einige
10 Nanosekunden.
Ziel ist es, viele Tausende dieser Nanodraht­Speicher, die
zwischen 10 und 100 Bits speichern können, dicht auf einer
Fläche anzuordnen. Die senkrechte Anordnung von Nanodrähten
eröffnet zudem neuartige dreidimensionale Architekturen
– ein Paradigmenwechsel im Vergleich zu derzeitigen
zweidimensionalen Chip­ und Speichertechnologien.
Die Ausnutzung der dritten Dimension schafft neue Spielräume
für Leistungssteigerungen und Kostenreduktionen,
die nicht mehr nur – wie bis jetzt – durch Miniaturisierung
erzielt werden.
Stuart Parkin darf sich zu Recht freuen, er hat es geschafft und Racetrack
kann die Welt verändern
292 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

IUPAP Magnetism Award und Louis Neel Medaille
Am 27 Juli 2009 erhält IBM Fellow Dr. Stuart Parkin eine der
höchsten Auszeichnungen, die auf dem Gebiet der Erforschung
des Magnetismus vergeben werden. Er wird in
Karlsruhe auf der „International Conference on Magnetism“
mit dem „International Union of Pure and Applied Physics
Magnetism Award (IUPAP) und der Louis Neel Medaille für
seine fundamentalen Erforschungs­ und Entwicklungsergebnisse
im Bereich des Nano­Magnetismus ausgezeichnet.
Diese Auszeichnung wird durch das IUPAP Magnetism
Committee nur alle drei Jahre vergeben. Vor allem wurde
er für seine letzten Forschungsergebnisse bezüglich der
Racetrack Memories geehrt. Die Louis Neel Medaille geht
zurück auf den Wissenschaftler Louis Eugene Felix Neel,
der 1970 den Nobel­Preis für Physik für die Entdeckung des
Antiferromagnetismus erhielt.
Nanotechnologie – Schlüsseltechnologie des 21. Jahrhunderts
Nanotechnologie stellt eine neue Technologie dar, die Funktionen
in einem außerordentlich kleinen Maßstab anwendet.
Sie konzentriert sich auf Strukturen und Prozesse in Dimensionen
unter 100 Nanometer – ungefähr 400­mal dünner als
ein menschliches Haar. Im Größenbereich der Nanometer
spielen sich viele grundlegende Prozesse der Biologie, Chemie
und Physik ab, die in bislang ungekanntem Maß kontrolliert
werden können und neue Perspektiven in vielen
Bereichen eröffnen. Dazu gehören hochentwickelte funktionale
Materialien, Nanoelektronik, Informations­ und Kommunikationstechnologie,
Sensorik, Life Sciences sowie Energietechnologie.
Nanotech­Anwendungen könnten zur
effizienteren Nutzung von Solarenergie beitragen oder zu
neuen Arten der Wasseraufbereitung.
Durch die Forschung an der ETH Zürich (Eidgenössische
Technische Hochschule) und am IBM Forschungslabor in
Rüschlikon ZRL (Zürich Research Laboratory) sind von
Zürich immer wieder entscheidende Impulse in der Quantenmechanik
und Nanoforschung ausgegangen. Dies sind
zum Beispiel die bahnbrechenden Konzepte der Quantenmechanik
durch den ETH­Physiker und Nobelpreisträger
Wolfgang Pauli oder die Entwicklung des Rastertunnelmikroskops
(RTM) durch Gerd Binnig und Heinrich Rohrer am
IBM Forschungslabor in Rüschlikon. Dafür erhielten die
Forscher 1986 den Nobelpreis für Physik. Dieses Gerät
ermöglichte den ersten Blick in die Welt der Atome. Kurz
darauf wurde es möglich, einzelne Atome zu manipulieren,
wodurch die Tür zur Nanotechnologie weit aufgestoßen
wurde. Das RTM wird generell als das Instrument angesehen,
das das Tor zum Nanokosmos öffnete. Das Rasterkraftmikroskop
(RKM), das eng mit dem RTM verwandt ist,
wurde 1986 von Gerd Binnig erfunden.
Das Rastertunnelmikroskop (RTM) wird im Englischen
als STM (Scanning Tunnelling Microscope) bezeichnet,
das Rasterkraftmikroskop (RKM) als AFM (Atomic Force
Microscope).
IBM und ETH Zürich gründen neues gemeinsames
Nanotech-Forschungszentrum
Rund 6.000 Quadratmeter umfasst das neue Nanotech­
Forschungszentrum von IBM und ETH Zürich. Die beiden
Institutionen verbindet eine langjährige Tradition wissenschaftlicher
Zusammenarbeit. An einer gemeinsamen Medienkonferenz
in Zürich kündigten Ralph Eichler, Präsident der
ETH Zürich, und John E. Kelly, Senior Vice­President und
Direktor für Forschung bei IBM, die geplante Zusammenarbeit
an. Zentrales Element dieser Zusammenarbeit ist ein neues
Gebäude, das auf dem Gelände des ZRL in Rüschlikon
gebaut wird. Die Grundsteinlegung erfolgt im Frühjahr 2009.
Nanoforschung auf dem allerhöchsten Niveau wird das
neue Forschungszentrum auf dem Campus der IBM in
Rüschlikon ermöglichen. Das „Nanoscale Exploratory Technology
Laboratory“ ist Teil einer wichtigen strategischen
Partnerschaft in Nanotechnologie mit der Eidgenössischen
Technischen Hochschule Zürich (ETHZ). Die Forschungsaktivitäten
werden 2011 aufgenommen.
IBM Forschungsstandort Rüschlikon: neues Labor für Nano-Technologie
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 293

Technologie-Anhang
Forschungsschwerpunkte der beiden Institutionen reichen
von der Grundlagenforschung bis hin zu angewandter
Forschung. Gemeinsam wird in verschiedenen Bereichen
geforscht, wie zum Beispiel kohlenstoffbasierte Materialien,
Nano­Photonics, Spintronics, Nanodrähte und Tribologie.
Neuer Durchbruch in der Nanotechnologie –
IBM Forscher messen den Ladungszustand von einzelnen
Atomen mit dem Rasterkraftmikroskop
In Zusammenarbeit mit Wissenschaftlern der Universitäten
Regensburg und Utrecht erzielten im Juni 2009 IBM Forscher
einen Durchbruch auf dem Gebiet der Nanotechnologie.
Sie konnten zum ersten Mal den Ladungszustand von
einzelnen Atomen direkt mittels Rasterkraftmikroskopie
(RKM) messen. Die Präzision, mit der sie dabei zwischen
ungeladenen bzw. positiv oder negativ geladenen Atomen
unterscheiden konnten, betrug eine einzelne Elektronenladung
bei einer nanometergenauen räumlichen Auflösung.
Dies eröffnet neue Möglichkeiten für die Erforschung von
Nanostrukturen und Bausteinen auf atomarer und molekularer
Skala in Anwendungsbereichen wie etwa der molekularen
Elektronik, der Katalyse oder der Photovoltaik.
Für ihre Experimente verwendeten die Forscher eine Kombination
aus Rastertunnel­ (RTM) und Rasterkraftmikroskop
(RKM), betrieben im Ultrahochvakuum und bei tiefen Temperaturen
(5 Kelvin), um die für die Messungen notwendige
Stabilität zu erreichen.
Ein RKM misst mittels einer atomar feinen Spitze, die auf
einem schwingenden Federbalken angebracht ist, die
Kräfte, die zwischen dieser Spitze und den Atomen auf dem
Substrat auftreten. In der vorliegenden Arbeit verwendeten
die Forscher einen sogenannten qPlus­Kraftsensor, bei dem
die Spitze auf einem Zinken einer Stimmgabel, wie man sie
in mechanischen Uhrwerken von Armbanduhren findet,
angebracht ist, während der andere Zinken fixiert ist. Die
Stimmgabel wird mechanisch angeregt und schwingt mit
einer Amplitude von 0,02 Nanometer. Dies entspricht nur
etwa einem Zehntel des Durchmessers eines Atoms. Wird
die RKM­Spitze nun sehr nah über der Probe, etwa über
einem einzelnen Atom, platziert, verändert sich die Resonanzfrequenz
der Stimmgabel aufgrund der Kräfte, die zwischen
Probe und Spitze auftreten.
Mit dieser Methode und unter extrem stabilen Bedingungen
konnten die IBM Forscher nun die minimalen Unterschiede
in der Kraft messen, die zwischen Spitze und einzelnen,
unterschiedlich geladenen Atomen herrscht. Die Kraftdifferenz
zwischen einem neutralen Goldatom und einem Goldatom
mit einem zusätzlichen Elektron, beträgt nur etwa
11 Piko­Newton, gemessen bei einer minimalen Distanz
zwischen Spitze und Probe von ungefähr einem halben
Nanometer. Die Messgenauigkeit dieser Experimente liegt
im Bereich von 1 Piko­Newton, was der Gravitationskraft
entspricht, die zwei Menschen in einem Abstand von mehr
als einem halben Kilometer aufeinander ausüben. Die
Forscher bestimmten zudem, wie sich die Kraft mit der
zwischen Spitze und Probe angelegten Spannung veränderte.
Dies erlaubte die Unterscheidung, ob das entsprechende
Atom negativ oder positiv geladen war.
Dieser Durchbruch ist ein weiterer, wichtiger Fortschritt auf
dem Gebiet der Nanoforschung. Im Gegensatz zum RTM,
das auf elektrisch leitfähige Proben angewiesen ist, kann
das RKM auch für nicht leitende Proben verwendet werden.
In der molekularen Elektronik, in der die Verwendung von
Molekülen als funktionale Bausteine in zukünftigen Schaltkreisen
und Prozessoren erforscht wird, werden nicht
leitende Trägersubstanzen (Substrate) benötigt. Deshalb
würde bei solchen Experimenten bevorzugt die Rasterkraftmikroskopie
zum Einsatz kommen.
„Das Rasterkraftmikroskop mit einer Messgenauigkeit von
einer Elektronenladung ist hervorragend dazu geeignet,
den Ladungstransfer in Molekülkomplexen zu untersuchen,
was uns wertvolle, neue Erkenntnisse und physikalische
Grundlagen liefern könnte und zudem eines Tages zu neuen
Bauelementen in der Informationstechnologie führen könnte“,
erklärt Gerhard Meyer, der die Forschung im Bereich Rastertunnel­
und Rasterkraftmikroskopie am IBM Forschungslabor
Zürich leitet. Computerbausteine auf der molekularen Skala
haben das Potenzial, um Größenordnungen kleiner, schneller
und auch energieeffizienter zu sein als heutige Transistoren
und Speicherbausteine.
294 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

Für zukünftige Experimente können sich die Forscher
vorstellen, Verbindungen aus einzelnen metallischen Atomen
und Molekülen herzustellen, diese mit Elektronen zu laden
und deren Verteilung direkt mit dem RKM zu messen.
IBM Forscher Leo Gross weist auch auf die Bedeutung ihrer
Arbeit für andere Bereiche hin: „Ladungszustand und
Ladungsverteilung sind kritische Größen in der Katalyse
und bei der Umwandlung von Licht in elektrische Energie.
Das Abbilden der Ladungsverteilung auf atomarer Skala
könnte zu einem besseren Verständnis der grundlegenden
Abläufe auf diesen Gebieten führen.“
Die jüngsten Ergebnisse schließen sich einer Reihe grundlegender
wissenschaftlicher Durchbrüche an, die IBM
Forschern in den letzten Jahren gelungen sind: 2008 gelang
es Wissenschaftlern am IBM Almaden Research Center in
Kalifornien, mit einem qPlus­RKM erstmals die Kraft zu
messen, die benötigt wird, um ein Atom auf einer Oberfläche
zu verschieben. Dies bahnte den Weg für die aktuellen
Experimente. 2007 demonstrierte das Team um Gerhard
Meyer am IBM Forschungslabor Zürich ein Molekül, das
kontrolliert zwischen zwei Zuständen geschaltet werden
konnte, ohne Veränderung seiner äußeren Form. Schon
2004 war der gleichen Gruppe ein Experiment gelungen,
in dem sie gezielt den Ladungszustand eines einzelnen
Goldatoms mit einem RTM manipulieren konnte. Indem sie
Spannungspulse an die RTM­Spitze anlegten, konnten die
Forscher ein zusätzliches Elektron auf ein einzelnes Atom,
das sich auf einem isolierenden Substrat befand, aufbringen.
Dieses negativ geladene Atom blieb stabil, bis mittels
der RTM­Spitze ein entsprechender Spannungspuls mit
umgekehrtem Vorzeichen erfolgte. Diese Methode verwendeten
die Forscher auch in ihren aktuellen Experimenten,
um die einzelnen Atome zu laden.
IBM Forscher zeigen erstmals die innere Struktur von
Molekülen mit atomarer Auflösung
IBM Forscher im IBM ZRL Rüschlikon gelang es im August
2009, erstmals die vollständige chemische Struktur eines
Moleküls mit einem Rasterkraftmikroskop atomar aufzulösen.
Den Wissenschaftlern gelang damit ein Durchbruch auf dem
Gebiet der Nanowissenschaften, der auch der Erforschung
neuartiger elektronischer Bauelemente auf der atomaren
und molekularen Skala neue Möglichkeiten eröffnen könnte.
In den letzten Jahren wurden in der Charakterisierung von
Nanostrukturen auf der atomaren Skala mittels Rasterkraftmikroskopie
erstaunliche Fortschritte erzielt. Der Blick auf
die innere Struktur eines Moleküls mit atomarer Auflösung
blieb der Wissenschaft jedoch bis jetzt verwehrt.
In der Ausgabe des Wissenschaftsjournals Science vom
28. August 2009 berichten die IBM Forscher Leo Gross,
Fabian Mohn, Nikolaj Moll und Gerhard Meyer sowie Peter
Liljeroth von der Universität in Utrecht, wie sie mithilfe eines
RKMs die vollständige, chemische Struktur von Pentazen­
Molekülen (C22H14) mit atomarer Auflösung abbilden konnten.
Die Experimente wurden im Ultrahochvakuum und bei
sehr tiefen Temperaturen (5 Kelvin oder –268°C) durchgeführt.
Die erzielten Abbildungen haben in gewisser Weise
Ähnlichkeit mit Röntgenaufnahmen, die einen Blick ins
Innere des menschlichen Körpers erlauben. Das „RKM mit
Röntgenblick“ der IBM Forscher kann durch die Elektronenwolke
schauen, die das Molekül umhüllt, und das atomare
Rückgrat eines Pentazens abbilden.
Diese Publikation folgt nur gerade zwei Monate nach einer
weiteren Arbeit der gleichen Gruppe, die am 12. Juni 2009
in Science veröffentlicht wurde. In dieser wurde die
Ladungsmessung einzelner Atome mittels RKM beschrieben.
„Rastersondentechnologien bieten ein unvergleichliches
Potenzial, um auf der atomaren Skala Prototypen
komplexer funktionaler Strukturen zu bauen und damit deren
elektronischen und chemischen Eigenschaften gezielt maßzuschneidern
und zu untersuchen“, erklärt Gerhard Meyer,
der die Forschung im Bereich Rastertunnelmikroskopie und
Rasterkraftmikroskopie bei IBM in Rüschlikon leitet.
Die Ergebnisse der beiden Forschungsarbeiten eröffnen
neue Möglichkeiten, um die Ladungsverteilung in spezifischen
Molekülen oder Molekülnetzwerken zu untersuchen.
Das Wissen um diese Vorgänge ist generell sehr wichtig
für die Entwicklung von elektronischen Bauelementen auf
der atomaren und molekularen Skala. Solche Bauelemente
könnten in der Zukunft schnellere, leistungsfähigere
und energieeffizientere Prozessoren und Speicherchips
ermöglichen, wenn die Grenzen heutiger Chiptechnologien
ausgereizt sind.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 295

Technologie-Anhang
Das RKM verwendet eine winzige, sehr scharfe Metallspitze,
um die minimalen Kräfte zu messen, die auftreten, wenn
diese Spitze sehr nah an eine Probe, wie etwa ein Molekül,
herangeführt wird. Mit einer Punkt­für­Punkt­Messung dieser
Kräfte kann daraus ein Abbild der Oberfläche erstellt
werden. Die Pentazen­Moleküle, die die IBM Forscher in der
vorliegenden Arbeit verwendeten, bestehen aus 22 Kohlenstoffatomen
und 14 Wasserstoffatomen und haben eine
Länge von nur 1,4 Nanometern (Millionstelmillimeter).
Die Abstände der in Sechsecken angeordneten Kohlenstoffatome
sind dabei noch rund zehnmal kleiner. Auf den
RKM­Aufnahmen sind diese hexagonalen Kohlenstoffringe
be stechend klar aufgelöst und selbst die Positionen der
Wasserstoffatome können eindeutig identifiziert werden.
IBM Forscher Leo Gross betont: „Ausschlaggebend für
die Auflösung waren eine atomar scharfe Spitze mit einem
definierten Aufbau sowie eine sehr hohe Stabilität des
Gesamtsystems.“ Damit die chemische Struktur eines
Moleküls sichtbar wird, ist es notwendig, die Spitze äußerst
nah – weniger als einen Nanometer – an das Molekül
heranzuführen. Nur in diesem Bereich treten Kräfte auf, die
maßgeblich durch chemische Wechselwirkung bestimmt
werden. Um dies zu erreichen, mussten die Forscher die
Empfindlichkeit der Spitze verbessern und eine große Hürde
überwinden: Ähnlich wie zwei nebeneinander liegende
Magnete, die sich anziehen oder abstoßen, verschiebt sich
das Molekül oder heftet sich an die Spitze, wenn diese
zu nahe kommt. Geschieht dies, können keine weiteren
Messungen durchgeführt werden.
Beide Probleme konnten durch die Wahl eines geeigneten
Atoms oder Moleküls an der RKM­Spitze gelöst werden.
„Um unsere Spitze zu schärfen, haben wir gezielt Atome
und Moleküle durch Manipulationstechniken an die Spitze
angefügt. Unsere Messungen mit unterschiedlich präparierten
Spitzen zeigen deutlich, dass das vorderste Atom
oder Molekül der Spitze die Auflösung entscheidend beeinflusst“,
konstatiert Leo Gross. Ein Kohlenstoffmonoxid­
Molekül (CO) an der Spitze brachte den Durchbruch und
sorgte, bei einem Abstand von etwa einem halben Nanometer
zum Pentazen, für optimale Auflösung der einzelnen
Atompositionen und deren chemische Verbindungen.
Den Wissenschaftern gelang es außerdem, eine
vollständige dreidimensionale, topografische Abbildung der
Kräfte über dem Molekül zu erstellen. „Die Datenerhebung
beanspruchte mehr als 20 Stunden. Dies stellte höchste
Ansprüche an die thermische und mechanische Stabilität
unseres Systems, um zu gewährleisten, dass die Spitze
und das Molekül während der gesamten Zeit unverändert
blieben“, beschreibt Fabian Mohn, Doktorand bei IBM
Research in Rüschlikon.
Theoretische Rechnungen, durchgeführt von IBM Forscher
Nikolaj Moll, bestätigten die experimentellen Ergebnisse
und gaben Aufschluss über die genaue Natur des Abbildungsmechanismus.
Nikolaj Moll erklärt hierzu: „Die Berechnungen
zeigen, dass die sogenannte Pauli­Abstoßung
zwischen dem CO­Molekül an der Spitze und dem Pentazen
für den atomaren Kontrast verantwortlich ist.“ Diese abstoßende
Kraft geht auf einen quantenmechanischen Effekt
zurück, der verhindert, dass sich zwei identische Elektronen
zu stark aneinander annähern.
Für die Leser, die noch mehr über die beiden Experimente
und Forschungsarbeiten wissen möchten, ist die wissenschaftliche
Arbeit von L. Gross, F. Mohn, N. Moll, P. Liljeroth
und G. Meyer mit dem Titel „The Chemical Structure of a
Molecule Resolved by Atomic Force Microscopy”, erschienen
in Science, Vol. 325, Nr. 5944, S. 1110 – 1114
(28. August 2009) zu empfehlen.
Nanotechnologien werden in großem Maße in den nächsten
Jahren in der Speichertechnologie ihren Einzug halten und
Speicherchips ermöglichen, die die Grenzen heutiger Chiptechnologien
sprengen – davon ist der Autor überzeugt!
296 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software
Anhang 297

298
Ein ganz herzlicher Dank gilt auch den Sponsoren dieses IBM System Storage
Kompendiums, welche die Druckauflage unterstützt haben:
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software
Anhang
299

300
Ein ganz herzlicher Dank gilt auch den Sponsoren dieses IBM System Storage
Kompendiums, welche die Druckauflage unterstützt haben:
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software
Anhang
301

302
Ein ganz herzlicher Dank gilt auch den Sponsoren dieses IBM System Storage
Kompendiums, welche die Druckauflage unterstützt haben:
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software
Anhang
303

304
Ein ganz herzlicher Dank gilt auch den Sponsoren dieses IBM System Storage
Kompendiums, welche die Druckauflage unterstützt haben:
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

INteLLIgeNte uNd INtegRAtIve
LöSuNgeN füR IhR RecheNzeNtRuM
Storage- und Servervirtualisierung
Backup- und Recovery-Lösungen
Information Lifecycle Management
Kontakt:
Bechtle Ag
Bechtle Platz 1, 74172 Neckarsulm
www.bechtle.com
Bechtle – Ihr starker It-Partner. heute und morgen.
Martin Schneider
telefon: +49 7132 981-3676
e-Mail: ibmstorage@bechtle.com
skalierbares Storage Networking
gesetzeskonforme Archivierung
hierarchische Storagekonzepte
die Bechtle Ag ist mit einem umsatz von rund 1,43 Mrd. € und rund 4.400 Mitarbeitern
führendes deutsches Systemhaus. An über 50 Standorten in deutschland, österreich und
der Schweiz bieten wir unseren Kunden herstellerübergreifend ein lückenloses Angebot
rund um It-Infrastruktur und It-Betrieb aus einer hand.
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
305

306
Ein ganz herzlicher Dank gilt auch den Sponsoren dieses IBM System Storage
Kompendiums, welche die Druckauflage unterstützt haben:
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software
Anhang
307

308
Ein ganz herzlicher Dank gilt auch den Sponsoren dieses IBM System Storage
Kompendiums, welche die Druckauflage unterstützt haben:
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software
Anhang
309

310
Ein ganz herzlicher Dank gilt auch den Sponsoren dieses IBM System Storage
Kompendiums, welche die Druckauflage unterstützt haben:
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software
Anhang
311

312
Ein ganz herzlicher Dank gilt auch den Sponsoren dieses IBM System Storage
Kompendiums, welche die Druckauflage unterstützt haben:
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software
Anhang
313

314
Ein ganz herzlicher Dank gilt auch den Sponsoren dieses IBM System Storage
Kompendiums, welche die Druckauflage unterstützt haben:
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software
Anhang
315

316
Ein ganz herzlicher Dank gilt auch den Sponsoren dieses IBM System Storage
Kompendiums, welche die Druckauflage unterstützt haben:
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software
Anhang
317

318
Ein ganz herzlicher Dank gilt auch den Sponsoren dieses IBM System Storage
Kompendiums, welche die Druckauflage unterstützt haben:
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang

1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software
Anhang
319

IBM Deutschland GmbH
IBM-Allee 1
71139 Ehningen
ibm.com/de
IBM Österreich
Obere Donaustraße 95
1020 Wien
ibm.com/at
IBM Schweiz
Vulkanstrasse 106
8010 Zürich
ibm.com/ch
Die IBM Homepage finden Sie unter:
ibm.com
IBM, das IBM Logo und ibm.com sind eingetragene
Marken der IBM Corporation.
Weitere Unternehmens-, Produkt- oder Servicenamen
können Marken anderer Hersteller sein.
Java und alle Java-basierenden Marken und
Logos sind Marken von Sun Microsystems, Inc. in
den USA und/oder anderen Ländern.
Microsoft, Windows, Windows NT und das Windows-Logo
sind Marken der Microsoft Corporation
in den USA und/oder anderen Ländern.
Intel, Intel logo, Intel Inside, Intel Inside logo, Intel
Centrino, Intel Centrino logo, Celeron, Intel Xeon,
Intel SpeedStep, Itanium, and Pentium sind Marken
der Intel Corporation in den USA und/oder
anderen Ländern.
UNIX ist eine eingetragene Marke von The Open
Group in den USA und anderen Ländern.
Linux ist eine Marke von Linus Torvalds in den
USA und/oder anderen Ländern.
Gedruckt in Deutschland.
© Copyright IBM Corporation 2010
Alle Rechte vorbehalten.
€ 49,90 – unverbindliche Preisempfehlung