Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
<strong>IBM</strong> <strong>System</strong>s and Technology Group<br />
<strong>IBM</strong> <strong>System</strong> <strong>Storage</strong>-<strong>Kompendium</strong><br />
Die <strong>IBM</strong> Speichergeschichte von 1952 bis 2010<br />
ibm.com/systems/de/storage
2<br />
Cover Photo: <strong>IBM</strong> TS3500 Tape Library<br />
David Hobby, USA, a.k.a. Strobist,<br />
www.strobist.com<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Vorwort des Autors Kurt Gerecke<br />
Sehr geehrte Kunden, sehr geehrte Geschäftspartner, liebe Leser,<br />
begeben Sie sich auf eine spannende Zeitreise durch die <strong>IBM</strong> Speichergeschichte. Vor<br />
bereits 58 Jahren erfand die <strong>IBM</strong> die erste externe Speichereinheit in Form des Rollenbandes<br />
der <strong>IBM</strong> 726 mit einer Speicherkapazität von 1,4 MB. Lassen Sie sich faszinieren, was in<br />
diesem halben Jahrhundert an Erfindungen und Produkten von <strong>IBM</strong> im Speicherumfeld ent<br />
wickelt und auf den Markt gebracht wurde. Vielleicht möchten Sie sich durch dieses Buch<br />
auch an Ihre Anfangszeiten in der IT zurückerinnern und gedanklich Ihren beruflichen Werde<br />
gang Revue passieren lassen. Aber auch für alle jungen Menschen, die diese Zeitspanne nicht direkt erlebt haben, ist es ein<br />
faszinierendes Nachschlagewerk.<br />
Die beschriebenen Zeitepochen reflektieren sehr klar die ganzheitliche <strong>IBM</strong> Entwicklungsstrategie: Rechner und Speichersys<br />
teme gehören als Einheit zusammen! Speichertechnologien und Speicherlösungen wurden bis heute immer im Einklang mit<br />
den Servertechnologien vorangetrieben, um ausgewogene, performante und aufeinander abgestimmte Gesamtlösungen zur<br />
Verfügung zu stellen. Diese Strategie brachte viele neue Erfindungen hervor und machte <strong>IBM</strong> zum weltweiten Patentführer –<br />
und das seit 17 Jahren in Folge.<br />
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<br />
in Paris vergeben, die 1988 den GMREffekt (Giant Magnetoresistance) bei extrem niederen Temperaturen entdeckt hatten.<br />
Wir alle wissen, dass ohne diese Entdeckung die heutigen Festplattenkapazitäten nie möglich geworden wären. Was viele<br />
nicht wissen, ist, dass es <strong>IBM</strong> zu verdanken ist, dass aus der Entdeckung ein Produkt wurde. Bereits 1989 begann der <strong>IBM</strong><br />
Forscher Stuart Parkin im <strong>IBM</strong> Labor Almaden in Kalifornien mit der Umsetzung und dem Ziel, den Effekt auch bei normalen<br />
Temperaturen zu realisieren. Er erforschte mehr als 30.000 Materialkombinationen, um 1997 den ersten einsetzbaren GMR<br />
Lesekopf für Plattenlaufwerke zur Verfügung zu stellen. Alle drei Forscher wurde 1997 gemeinsam für die GMREntwicklung<br />
mit dem EuroPhysikPreis ausgezeichnet.<br />
Vielleicht nicht alles, aber alles fundamental Wichtige wurde von <strong>IBM</strong> im <strong>Storage</strong>Bereich entdeckt und entwickelt. Ich möchte<br />
Ihnen neben GMR ein paar weitere Eckdaten nennen: 1991 führte <strong>IBM</strong> drei zukunftsweisende Technologien ein, Dünnfilmbe<br />
schichtungen auf den Platten, die ersten MRKöpfe (Magnetoresistive Köpfe) und RAID5basierende Subsystemarchitekturen.<br />
1999 entdeckte <strong>IBM</strong> den paramagnetischen Effekt und im selben Jahr brachte <strong>IBM</strong> den ersten Microdrive auf den Markt, ein<br />
Laufwerk in der Größe einer ZweiEuroMünze. Im Jahr 2000 erhielt <strong>IBM</strong> als erste Firma die „National Medal of Technology for<br />
Innovations in <strong>Storage</strong>“ von der amerikanischen Regierung, eine der höchsten technologischen Ehrungen, die bis dahin aus<br />
schließlich an Einzelpersonen vergeben wurde. Alle diese faszinierenden Erfindungen und viele mehr finden Sie im Techno<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
3
4<br />
Vorwort des Autors<br />
logieAnhang dieses <strong>Storage</strong> <strong>Kompendium</strong>s. Die <strong>IBM</strong> leistete auf dem Gebiet der Speicherentwicklungen<br />
Einmaliges und ich bin überzeugt, dass dies auch in der Zukunft der Fall sein wird.<br />
Widmen Sie Ihre Aufmerksamkeit besonders auch der jetzigen Zeitepoche, die vor allem durch Virtualisierung in<br />
allen Bereichen der Datenspeicherung geprägt ist. Alle aktuellen <strong>IBM</strong> Produkte sind dort ausführlich beschrieben.<br />
Das <strong>Kompendium</strong> ist also nicht nur ein historisches Nachschlagewerk, sondern informiert Sie vor allem über alle<br />
aktuellen <strong>IBM</strong> Speicherentwicklungen.<br />
Die Überarbeitung des <strong>IBM</strong> <strong>System</strong> <strong>Storage</strong> <strong>Kompendium</strong>s als Update 2010 erforderte doch wieder viel freie Zeit<br />
und viele Wochenenden. Deshalb möchte ich mich zuallererst wieder bei meiner Ehefrau Gabriele für das auf<br />
gebrachte Verständnis bedanken. Ihre Geduld war wieder einmal bewundernswert.<br />
Ein großer Dank gilt auch dem <strong>IBM</strong> <strong>Storage</strong> Produktexpertenteam für seine wertvollen Informationen. Herrn Dr.<br />
Stefan Radtke möchte ich für seine technischen Ausführungen des XIV <strong>Storage</strong> <strong>System</strong>s danken, Herrn Jens<br />
Gerlach von der Firma LSI für seinen DS5000Input, Herrn Stefan Neff für seinen TS7700Beitrag, Herrn Hartmut<br />
Grund für seine Hilfe beim <strong>IBM</strong> Information Archive, Jürgen Loeb für seinen SOFS bzw. SPSCInput und Axel<br />
Melber für die Fotobearbeitung der ExponatenSammlung.<br />
Ganz besonders möchte ich mich bei den Herren Hans W. Spengler und Heinz Graichen vom <strong>IBM</strong> Museum in<br />
Sindelfingen für ihre tabellarischen Zusammenstellungen, Grafiken und Bilder von der jetzt im Museum fertig<br />
gestellten Plattenrotunde und dem Interview mit mir bedanken, bei dem beide den RAMAC 350Zugriff detailliert<br />
darlegen. Ebenso möchte ich mich bei beiden dafür bedanken, dass ich die Plattenprofile, die vor allem Hans<br />
W. Spengler in einer zehnjährigen Arbeit zusammengestellt hat, in dieses neue <strong>Kompendium</strong> integrieren konnte.<br />
Allen anderen Kollegen, die mir dabei geholfen haben und jetzt nicht namentlich erwähnt sind, gilt ein ebenso<br />
großes Danke.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Mein Dank gilt auch Herrn Ivano Rodella von <strong>IBM</strong> <strong>System</strong> <strong>Storage</strong> Marketing, der die Agenturarbeit ermöglichte,<br />
sowie den Sponsoren, die den Druck dieses <strong>Kompendium</strong>s finanziell unterstützt haben.<br />
Am meisten freut mich, dass ich die Herren Werner Bauer und Klemens Poschke, alle langjährige Kollegen und<br />
Freunde, dafür gewinnen konnte, an diesem <strong>Kompendium</strong> mitzuarbeiten. Werner hat das Thema des <strong>System</strong><br />
verwalteten Speichers (<strong>System</strong> Managed <strong>Storage</strong>) im MainframeUmfeld aufgearbeitet. Klemens hat die<br />
Geschichte des Tivoli <strong>Storage</strong> Managers (TSM) dokumentiert, der dieses Jahr sein 20jähriges Bestehen feiert.<br />
Ebenso ganz herzlich bedanken möchte ich mich bei Edelgard Schittko, die sich einfach ganz kurzfristig dazu<br />
bereiterklärte, das Thema BRMS im <strong>System</strong> i Umfeld aufzuarbeiten. Damit reflektiert das <strong>Kompendium</strong> jetzt eine<br />
ganzheitliche Dokumentation der wichtigsten <strong>Storage</strong>Hardware und Softwareprodukte.<br />
Ein bisschen Reklame möchte ich auch noch machen! Sollten Sie sich im Raum Stuttgart aufhalten, vergessen<br />
Sie nicht, das <strong>IBM</strong> Museum, das Haus der Geschichte der <strong>IBM</strong> Datenverarbeitung, Bahnhofstraße 43 in 71063<br />
Sindelfingen zu besuchen. Dort können Sie „live“ die Geschichte der Informationstechnologie von 1890 bis ins<br />
Jahr 2000 erleben. Auch das erste Plattenprodukt der <strong>IBM</strong>, die RAMAC 350 als Teil des damaligen Rechnersy<br />
stems <strong>IBM</strong> RAMAC 305, können Sie dort in Betrieb sehen. Ein besonderer Höhepunkt ist die neu aufgebaute<br />
Plattenrotunde. Begleitet von einer Diashow können Sie sich auf eine Zeitreise begeben und die faszinierenden<br />
Produkte und Erfindungen im Plattenbereich von 1956 bis ins Jahr 2000 kennenlernen.<br />
Melden Sie sich rechtzeitig wegen einer Terminabsprache über mich, Tel. 01702207066, oder Herrn Hans W.<br />
Spengler vom <strong>IBM</strong> Museum, Tel. 07031271378 an.<br />
Ich wünsche Ihnen viel Freude und viel Spaß beim Lesen und Studieren des <strong>IBM</strong> <strong>System</strong> <strong>Storage</strong> <strong>Kompendium</strong>s<br />
und hoffe, dass Sie viele Gelegenheiten haben, diese Informationen für Ihre Zwecke erfolgreich einzusetzen.<br />
Mit den besten Grüßen<br />
Ihr Kurt Gerecke<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
5
6<br />
Vorwort des Co-Autors Klemens Poschke<br />
Ein paar Worte persönlicher Bezug…<br />
Die Idee zu einer historischen Dokumentation der Tivoli <strong>Storage</strong> Manager Soft<br />
ware entstand im Gespräch mit meinem Freund und Kollegen Kurt Gerecke auf der<br />
CeBIT 2009, als er eine erweiterte Neuauflage dieses Buches zum 100jährigen<br />
Bestehen der <strong>IBM</strong> Deutschland 2010 plante. Ich freue mich, mit einem TSM<br />
Kapitel zum Erfolg des Buches beitragen zu können, weil die Geschichte von<br />
Tivoli <strong>Storage</strong> Manager und seinen Namensvorgängen eng mit der Geschichte<br />
der Speichertechnologie der <strong>IBM</strong> verknüpft ist. Insofern komplettiert dieses Kapitel einerseits den von Kurt<br />
Gerecke und Kollegen verfassten HardwareTeil, dokumentiert aber auch die Tradition der erfolgreichen gemein<br />
samen Arbeit zwischen den Menschen aus unterschiedlichen Bereichen der <strong>IBM</strong>.<br />
Diese Zusammenstellung über die Geschichte des <strong>IBM</strong> Tivoli <strong>Storage</strong> Manager ist gleichzeitig auch ein Reflek<br />
tieren der letzten 20 Jahre meiner eigenen beruflichen Geschichte bei der <strong>IBM</strong>, da ich mich seit 1990 mit diesem<br />
Thema als Architekturberater beschäftige. Bei der Stoffsammlung und inhaltlichen Aufbereitung habe ich mich<br />
immer wieder gerne an viele sympathische Menschen erinnert, die ich über dieses Thema bei Kunden,<br />
Geschäftspartnern und als Kollegen kennengelernt habe.<br />
Das Kapitel beschränkt sich bewusst auf die Themenbereiche, in denen TSM und seine Namensvorgänger Teil<br />
von <strong>IBM</strong> Datensicherungs/ArchivLösungen sind. Ich habe dabei absichtlich auch Informationen zu Firmenüber<br />
nahmen und Begleitprodukten des BackupMarktes mit aufgenommen, um die historische Entwicklung und<br />
Marktbedeutung ganzheitlich zu beschreiben.<br />
20 Jahre Beschäftigung mit diesem Thema ermöglichen mir, auf eine große Menge an Ressourcen zurückzugreifen,<br />
die bei der Bereitstellung der nachfolgenden Informationen, Dokumente und historischen Bilder geholfen haben.<br />
Ich möchte mich stellvertretend für alle Beiträge bei folgenden Kollegen besonders bedanken für die Übersen<br />
dung von Hintergrundinformationen, Dokumenten, Geschichten und Bildschirmfotos:<br />
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<br />
Pass (Almaden), Barry Fruchtman (Tucson), Dr. HansJoachim Renger (Böblingen), Claire Rankin (San José),<br />
Mike Welkley (San José), Paul Bradshaw (Almaden).<br />
Besonderer Dank gilt meinen Kollegen Wolfgang Hitzler (Ehningen) und Dr. HansJoachim Renger (Böblingen),<br />
die ihre Zeit geopfert haben, um den Text inhaltlich zu validieren, und meiner Frau Doris, die sich des Fach<br />
chinesisch auf grammatikalisch/stilistischer Ebene angenommen hat.<br />
Ich bedanke mich auch bei den Redaktionen der Zeitschrift „Computerwoche“ (Sandra Holleber) und dem<br />
Online Magazin „Monitor“ (Dipl.Ing. Rüdiger Maier) für die Genehmigung, Artikelauszüge ihrer Publikationen aus<br />
dem Internet benutzen zu dürfen.<br />
Sollten sich trotz intensiver Recherche inhaltliche Fehler eingeschlichen haben, bitte ich dies zu entschuldigen<br />
und mich darüber zu informieren (Klemens.Poschke@de.ibm.com).<br />
Ich wünsche Ihnen viel Spaß und Freude beim Lesen und Studieren der 20jährigen TSMErfolgsgeschichte und<br />
verbleibe mit den herzlichsten Grüßen<br />
Ihr Klemens Poschke<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
7
8<br />
Speicherentwicklung und Gesamtüberblick von 1952 bis 2010<br />
Allgemeines:<br />
Die Geschichte der <strong>IBM</strong> Speichertechnologie und der <strong>IBM</strong><br />
Speichersysteme ist mit ziemlicher Sicherheit eines der faszinierendsten<br />
Ereignisse unserer Zeitgeschichte der letzten<br />
58 Jahre. Spannend vom Anfang bis in die heutige Zeit soll<br />
diese Broschüre einen Überblick geben und vor allem auch<br />
das Verständnis entwickeln, wie erfinderisch die Menschheit<br />
sein kann, wenn es darum geht, technologische Grenzen zu<br />
überschreiten, um neue Möglichkeiten für die Speicherung<br />
von Daten zu eröffnen. Die Vielzahl von Produkten und Erfindungen<br />
in diesem Bereich macht es notwendig, die Zeitgeschichte<br />
ein bisschen zu ordnen und in zeitgeschichtliche<br />
Epochen zu unterteilen. Da dieses Unterfangen bisher nie<br />
gemacht wurde, erlaubt sich der Autor, das Speicherzeitgeschehen<br />
von 1952 bis in die heutige Zeit in technologische<br />
Epochen zu unterteilen, um dann im Detail die einzelnen<br />
Epochen von der Produkt und Produktentwicklungsseite zu<br />
beleuchten. Nach den Produktepochen schließt das Kapitel<br />
„<strong>IBM</strong> <strong>Storage</strong> Software“ an, das die wichtigsten SWEntwicklungen<br />
im Speicherumfeld darstellt. Am Ende dieses<br />
Buches im Kapitel „TechnologieAnhang“ befindet sich ein<br />
TechnologieTeil, der die Entwicklung der Speicherbasistechnologien<br />
und Aufzeichnungsverfahren einschließlich<br />
anstehender Technologien näher beschreibt.<br />
Entwicklung der Speichersysteme von 1952 bis 2010<br />
1952 – 1961 die Anfangsepoche der<br />
elektro magnetischen Speicherung<br />
1962 – 1974 die Epoche der Wechselplatten<br />
und die ‘Winchester’-Zeit<br />
Die einzelnen Epochen beschreiben immer eine Zeitphase,<br />
die durch besondere Produkte geprägt war, die in dieser<br />
Zeitphase auf den Markt kamen. In vielen Fällen wurden die<br />
Produkte über die definierte Epoche hinaus aktiv vertrieben<br />
und wurden meistens erst in der Folgeepoche oder später<br />
vom Marketing zurückgezogen. Die einzelnen Produkte sind<br />
in der Epoche, in der die Markteinführung erfolgte, so beschrieben,<br />
dass sie den gesamten Lebenszyklus darstellen.<br />
Das <strong>Storage</strong> <strong>Kompendium</strong> erhebt keinen Anspruch auf Vollständigkeit,<br />
beschreibt aber die wichtigsten Produkte in der<br />
jeweiligen Epoche.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
Seite 13<br />
Seite 19<br />
1975 – 1993 die Epoche der fest eingebauten Platten<br />
mit externen Kontrollein heiten<br />
Seite 27<br />
1994 – 1998 die Epoche der RAID-<strong>System</strong>e Seite 37<br />
1999 – 2005 die Epoche der Multiplattform-<strong>System</strong>e<br />
und des FibreChannel SAN/NAS<br />
2006 – 2010 die Epoche der Server-basierenden<br />
Speichersysteme und der Speichervirtualisierung<br />
Seite 51<br />
Seite 87
Preisentwicklung Magnetplattenspeicher<br />
Die Schnelligkeit der technologischen Entwicklung bei<br />
Magnetplattenspeichern von 1956 bis ins Jahr 2010 lässt<br />
sich im besonderen Maße aus dem Preisverfall für ein<br />
gespeichertes Megabyte ablesen. Der Verlauf war in etwa<br />
folgendermaßen:<br />
Jahr 1956 1964 1975 1987 1991<br />
Euro/MB 12 000 8 000 70 12 9<br />
Jahr 1997 2000 2006 2009<br />
Euro/MB 1 0.25 0.015 0.0054 (FC-Disk)<br />
0.0025 (SATA)<br />
Rechnet man den verminderten Platz und Energiebedarf so<br />
wie den geringeren Wartungsaufwand pro Megabyte hinzu, so<br />
ist der Trend bei der Kostenentwicklung eher noch günstiger.<br />
Kapazitätsentwicklung Magnetplattenspeicher<br />
Während der Preisverfall für das gespeicherte Megabyte<br />
kontinuierlich anhielt, war in den letzten 10 Jahren ein überdimensional<br />
hoher Preisverfall zu verzeichnen, der speziell<br />
in den letzten Jahren eine Spanne von 40 bis 70 % pro Jahr<br />
erreichte. Parallel dazu wurde die Aufzeichnungsdichte<br />
durch technologische Innovationen in einem Maße gesteigert,<br />
dass sie dem Preisverfall für das gespeicherte Megabyte<br />
standhalten und Rechnung tragen konnte.<br />
Die Steigerung der Aufzeichnungsdichte war in etwa folgendermaßen:<br />
Jahr Produkt Aufzeichnungsdichte<br />
(Millionen Bits/qcm)<br />
1956 RAMAC 350 0.00031<br />
1961 1311 0.008<br />
1964 2311 0.017<br />
1965 2314 0.034<br />
1970 3330 0.12<br />
1973 3340 0.26<br />
1975 3350 0.48<br />
1979 3370 1.2<br />
1980 3375 1.51<br />
1980 3380 1.9<br />
1985 3380E 2.99<br />
1987 3380K 5.47<br />
1991 33903 13.95<br />
1994 33909 41.6<br />
1996 RAMAC 3 129.2<br />
1999 ESS 427.5<br />
2004 ESS 2.9 Milliarden Bits/qcm<br />
2006 DS8000 5.8 Milliarden Bits/qcm<br />
2009 DS8000FCPlatten<br />
DS8000SATAPlatten<br />
8.7 Milliarden Bits/qcm<br />
19.3 Milliarden Bits/qcm<br />
Im Jahr 2003, mit Verfügbarkeit der 146GBLaufwerke für<br />
ESS, wurde die magische Grenze von 1 Milliarde Bits auf<br />
dem Qua dratzentimeter überschritten. Mit der heutigen<br />
Verfügbarkeit von 1 TB SATALaufwerken erreicht man eine<br />
Aufzeichnungsdichte von über 19 Milliarden Bits/qcm.<br />
Die großen Sprünge ergaben sich speziell in den letzten<br />
10 Jahren (siehe auch TechnologieAnhang).<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
9
10<br />
Produktübersicht der <strong>IBM</strong> Speichersysteme<br />
Vorwort des Autors Kurt Gerecke ........................ Seite ......3<br />
Vorwort der CoAutors Klemens Poschke ............ Seite ......6<br />
Speicherentwicklung, Gesamtüberblick .............. Seite ......8<br />
Preis und Kapazitätsentwicklung<br />
Plattenspeicher ..................................................... Seite ......9<br />
Produktübersicht .................................................. Seite ....10<br />
Die Anfangsepoche der elektromagnetischen<br />
Speicherung ........................................................Seite ....13<br />
726/727 Magnetbandsystem .............................. Seite ....14<br />
RAMAC 305/350 Plattensystem .......................... Seite ....14<br />
729 Magnetbandsystem ...................................... Seite ....16<br />
1405 Platteneinheit/1414 Steuereinheit ................ Seite ....16<br />
1301 Plattensystem .............................................. Seite ....16<br />
7340 Hyper Tapes ................................................ Seite ....17<br />
2321 Magnetstreifenspeicher............................... Seite ....17<br />
Die Epoche der Wechselplatten und<br />
die ‘Winchester’-Zeit...........................................Seite ....19<br />
1311 Wechselplattensystem ................................ Seite ....20<br />
1302 Plattensystem .............................................. Seite ....21<br />
2401 Magnetbandsystem .................................... Seite ....21<br />
2314 Wechselplattensystem ................................ Seite ....21<br />
2305 Plattenspeicher ‘Zeus’ ................................. Seite ....21<br />
3330 Wechselplattensystem/3830<br />
Steuereinheit ......................................................... Seite ....22<br />
3340 Wechselplattensystem<br />
‘Winchester’Platte ................................................ Seite ....23<br />
3420 Magnetbandsystem .................................... Seite ....24<br />
3410 Magnetbandsystem .................................... Seite ....24<br />
3850 MSSMassenspeicher ................................. Seite ....25<br />
Die Epoche der fest eingebauten Platten<br />
mit externen Kontrolleinheiten ..........................Seite ....27<br />
3350 Festplattensystem ....................................... Seite ....28<br />
3310 Magnetbandsystem .................................... Seite ....28<br />
3370/3375 Plattensystem ..................................... Seite ....28<br />
3380 Plattensystem/3880 Steuereinheit ............... Seite ....29<br />
3430 Magnetbandsystem .................................... Seite ....30<br />
3480 Magnetbandkassettensystem ..................... Seite ....30<br />
3390 Plattensystem/3990 Steuereinheit ............... Seite ....31<br />
9340/9345 Plattensystem ..................................... Seite ....32<br />
3490 Magnetbandeinheit ..................................... Seite ....33<br />
3495 Magnetbandarchiv ...................................... Seite ....34<br />
3494 Magnetbandarchiv ...................................... Seite ....35<br />
Die Epoche der RAID-<strong>System</strong>e .........................Seite ....37<br />
RAIDDefinitionen ................................................. Seite ....38<br />
RAMAC 1/2/3 RAIDPlattensystem ....................... Seite ....39<br />
RVA RAMAC Virtual Array .................................... Seite ....40<br />
RSA RAMAC Scalable Array ................................ Seite ....40<br />
7133 SSAPlattensystem ...................................... Seite ....41<br />
3590 MagstarMagnetbandeinheit ....................... Seite ....42<br />
3570 MagstarMPMagnetbandeinheit ................. Seite ....44<br />
3494 B16, B18, B10, B20<br />
Virtual Tape Server ............................................... Seite ....44<br />
LTO LinearTapeOpenBandeinheiten ................. Seite ....46<br />
LTO Libraries ........................................................ Seite ....47<br />
Die Epoche der Multiplattform-<strong>System</strong>e und<br />
des FC SAN und NAS ........................................Seite ....51<br />
SAN <strong>Storage</strong> Area Network .................................. Seite ....52<br />
NAS Network Attached <strong>Storage</strong> ........................... Seite ....53<br />
iSCSI ..................................................................... Seite ....54<br />
ESS Enterprise <strong>Storage</strong> Server (Shark)<br />
Plattensystem ....................................................... Seite ....54<br />
7133 + 7140 Hammer Shark SSA<br />
Plattenlösung für SAN .......................................... Seite ....56<br />
MSS Modular <strong>Storage</strong> Server Plattensystem ....... Seite ....57<br />
7135 RAIDiantArrayPlattensystem ..................... Seite ....57<br />
FAStTPlattensysteme ........................................... Seite ....57<br />
DS4000Plattensysteme ....................................... Seite ....60<br />
SVC SAN Volume Controller ................................. Seite ....63<br />
LTO2/LTO3 LinearTapeOpen<br />
Bandlaufwerke ...................................................... Seite ....63<br />
LTO4 LinearTapeOpenBandlaufwerke .............. Seite ....65<br />
3592/TS1120 Bandlaufwerk (Jaguar) ................... Seite ....66<br />
3584/TS3500 Bandarchiv ..................................... Seite ....69<br />
3581 Band Autoloader ......................................... Seite ....71<br />
3582 Bandarchiv .................................................. Seite ....71<br />
3583 Bandarchiv .................................................. Seite ....71<br />
TS3310 Bandarchiv .............................................. Seite ....71<br />
TS3100 Band Autoloader ..................................... Seite ....72<br />
TS3200 Bandarchiv .............................................. Seite ....72<br />
TS7510 TapeVirtualisierung für Open <strong>System</strong>s .. Seite ....72<br />
3995 Optisches Archivsystem ............................. Seite ....75<br />
DR 450 Data Retention 450 Archivlösung ........... Seite ....76<br />
DR 550 Data Retention 550 Archivlösung ........... Seite ....76<br />
3996 Optisches Archivsystem ............................. Seite ....80<br />
Nseries N3000/N5000/N6000/N7000 ................... Seite ....81<br />
Nseries Funktionen ............................................... Seite ....84<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Die Epoche der Server-basierenden<br />
Speichersysteme und der<br />
Speichervirtualisierung ....................................Seite ....87<br />
DS8000 und DS6000 Plattensysteme .................. Seite ....88<br />
XIV <strong>Storage</strong> <strong>System</strong>e ............................................ Seite ....97<br />
DS3000 Entry Plattensysteme .............................. Seite ..105<br />
DS5000 Plattensysteme ....................................... Seite ..106<br />
SVC San Volume Controller neue HW und SW .... Seite ..111<br />
BackupKonzepte ................................................. Seite ..117<br />
TS7700 Tape Virtualisierung für z/OS .................. Seite ..120<br />
TS7520 und TS7530 Tape –<br />
Virtualisierung für Open <strong>System</strong>s ......................... Seite ..128<br />
DatenDeDuplizierung ......................................... Seite ..132<br />
<strong>IBM</strong> DatenDeDuplizierung<br />
mit ProtecTIER VTL und Hyperfactor ................... Seite ..134<br />
TS1130 Bandlaufwerk der Enterprise Klasse ...... Seite ..137<br />
TS3500 ALMS Library Virtualisierung .................. Seite ..140<br />
TS3500 Hardware Erweiterungen 2007 – 2010 ... Seite ..142<br />
TS3500 High Density (HD) Frames ...................... Seite ..142<br />
iRMM Library Virtualisierung mit dem integrated<br />
Enterprise Removable Media Manager ............... Seite ..144<br />
TS3400 MiniLibrary für TS1120 Laufwerke ......... Seite ..145<br />
TS2900 Autoloader ............................................... Seite ..145<br />
<strong>IBM</strong> Tape Library Überblick 2010 ........................ Seite ..146<br />
GPFS/SOFS File Virtualisierung ............................ Seite ..147<br />
SPSC Smart Private <strong>Storage</strong> Cloud ..................... Seite ..147<br />
Tape Encryption mit TS1120/30 und LTO4 .......... Seite ..152<br />
IIA <strong>IBM</strong> Information Archive ................................. Seite ..156<br />
SAN und IPNetworking Update 2007 – 2010 ..... Seite ..158<br />
Green IT................................................................ Seite ..161<br />
InfiniBand ............................................................ Seite ..162<br />
Neue BasisTechnologien .................................... Seite ..163<br />
Der <strong>System</strong>-verwaltete Speicher<br />
im Mainframe-Umfeld .........................................Seite ..166<br />
Speicherhierarchie ............................................... Seite ..166<br />
Entstehung ........................................................... Seite ..167<br />
Funktionsweise ..................................................... Seite ..169<br />
SMS für Tape ........................................................ Seite ..172<br />
Komponenten und Funktionen ............................. Seite ..172<br />
Zusammenfassung ............................................... Seite ..176<br />
TSM – Tivoli <strong>Storage</strong> Manager ..........................Seite ..178<br />
Wie alles begann ... 19831993 ........................... Seite ..178<br />
ADSM V1.1 und V1.2 ........................................... Seite ..183<br />
Internet Forum und Benutzergruppen ................. Seite ..187<br />
ADSM Version 2.1 (1995) ..................................... Seite ..188<br />
SAP R/3 Integration .............................................. Seite ..190<br />
ADSM Version 3.1 (1997) ..................................... Seite ..191<br />
Synergien <strong>IBM</strong> Speicherhardware und ADSM ..... Seite ..192<br />
Tivoli ADSM/Tivoli <strong>Storage</strong> Manager ................... Seite ..195<br />
TSM Version 3.7 und 4.2 ...................................... Seite ..196<br />
TSM Version 5.X ................................................... Seite ..200<br />
TSM für Data Retention (DR450/DR550) .............. Seite ..202<br />
TSM – kleine Lösungen für den Einstieg ............. Seite ..204<br />
TSM Version 6.1 (2009) ........................................ Seite ..204<br />
Zusammenfassung und Schlusswort ................... Seite ..206<br />
BRMS für <strong>System</strong> i .............................................Seite ..208<br />
Überblick .............................................................. Seite ..208<br />
Aktuelle Features .................................................. Seite ..208<br />
Geschichte ........................................................... Seite ..215<br />
Zusammenfassung und Ausblick ......................... Seite ..215<br />
Technologie-Anhang ..........................................Seite ..217<br />
Lochkarte und Lochstreifen ................................. Seite ..218<br />
Trommelspeicher .................................................. Seite ..218<br />
Magnetbandentwicklung ...................................... Seite ..219<br />
Magnetplatte ........................................................ Seite ..220<br />
Entwicklung des <strong>IBM</strong> <strong>System</strong>s 305<br />
und des ersten Plattenspeichers <strong>IBM</strong> 350 ........... Seite ..221<br />
Funktionsweise <strong>IBM</strong> 350 und <strong>IBM</strong> 355 ................ Seite ..222<br />
Disketten ............................................................... Seite ..225<br />
Festplattenentwicklung ......................................... Seite ..226<br />
Festplatten für PC’s .............................................. Seite ..229<br />
Induktive Aufzeichnung ........................................ Seite ..230<br />
Magneto Resistive Aufzeichnung (MR) ................ Seite ..230<br />
PRML Encoding ................................................... Seite ..232<br />
GMR Effekt – Giant MagnetoResistance ............ Seite ..232<br />
MicroDrives ......................................................... Seite ..233<br />
AFC Aufzeichnung ............................................... Seite ..234<br />
Perpendicular Recording ..................................... Seite ..236<br />
HAMR – Heat Assisted Magnetic Recording ....... Seite ..236<br />
<strong>IBM</strong> Museum ........................................................ Seite ..238<br />
Magnetplatten Exponatensammlung ................... Seite ..240<br />
<strong>IBM</strong> Magnetplattenprofile ..................................... Seite ..246<br />
Interview mit den RAMAC 350/355 Experten ...... Seite ..270<br />
Optische Speichertechnologien ........................... Seite ..274<br />
Flashspeicher ....................................................... Seite ..280<br />
RAM – Random Access Memory ......................... Seite ..284<br />
PCM – Phase Change Memory ............................ Seite ..285<br />
MillipedeNanotechnologie .................................. Seite ..287<br />
Racetrack Memories ............................................ Seite ..290<br />
Nanotechnologien ................................................ Seite ..293<br />
Sponsorenseiten ................................................Seite ..299<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 11
12<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
1952 bis 1961<br />
Die Anfangsepoche der elektromagnetischen Speicherung<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
13
14<br />
1952 bis 1961<br />
Die Anfangsepoche der elektromagnetischen Speicherung<br />
Aufnahme des ersten Prototypen des Magnetbandsystems <strong>IBM</strong> 726 im Jahr<br />
1951 mit zwei Bandlaufwerken pro Einheit<br />
Zum ersten Mal in der Speichergeschichte wurden externe<br />
Speicher mit magnetischer Aufzeichnung von <strong>IBM</strong> 1952<br />
angeboten: die <strong>IBM</strong> Magnetbandeinheit <strong>IBM</strong> 726 mit einer<br />
Speicherkapazität von 1,4 MB auf einem 12ZollRollenband<br />
(Durchmesser der Bandspule) mit 720 Metern Länge. Die<br />
Einheit hatte zwei integrierte Bandlaufwerke. Dies erwies<br />
sich allerdings als äußerst unpraktisch, weil keines der beiden<br />
Laufwerke im Fehlerfall oder bei Wartungsarbeiten weiterhin<br />
zur Verfügung stand. Bereits ein Jahr später, 1953, folgte<br />
die <strong>IBM</strong> 727 mit einem Laufwerk pro Einheit, die auf einem<br />
standardisierten Rollenband von ca. 740 Metern Bandlänge<br />
eine Kapazität von 4 MB bot. Bis 1956 war ein Teil der Steuerung<br />
in der damaligen Rechnereinheit <strong>IBM</strong> 701 untergebracht.<br />
Erste dedizierte Bandsteuereinheiten gab es dann ab 1956.<br />
<strong>IBM</strong> Magnetbandeinheit Modell 726, Markteinführung 1952<br />
1956 kam das <strong>System</strong> <strong>IBM</strong> RAMAC 305 auf den Markt.<br />
Dieses <strong>System</strong> hatte erstmals eine Plattenspeichereinheit<br />
Type <strong>IBM</strong> 350. Das <strong>IBM</strong> 305 <strong>System</strong> wurde unter dem eingetragenen<br />
Warenzeichen ‘RAMAC’ angekündigt (Random<br />
Access Method of Accounting and Control). Der Rechner<br />
des Gesamtsystems steuerte sowohl das Positionieren des<br />
Schreib/Lesekopfes auf die gewünschte Plattenoberfläche<br />
und Plattenspur als auch das Übertragen der Daten in beide<br />
Richtungen (Schreiben und Lesen).<br />
Die Aufzeichnungsdichte der RAMAC 350 Platte lag bei 100<br />
Bits pro Inch (40 Bits pro cm) und der Plattenstapel rotierte<br />
mit 1.200 Umdrehungen in der Minute (1200 RPM). Die durchschnittliche<br />
Suchzeit lag bei 600 ms. Der Plattenstapel bestand<br />
aus 51 Platten mit einem Durchmesser von 24 Zoll und bot<br />
eine maximale Kapazität von 5 MB (5 Millionen Characters).<br />
In Betrieb kann die RAMAC 350 im <strong>IBM</strong> Museum in Sindelfingen<br />
besichtigt werden.<br />
Medium-Rollenband für <strong>IBM</strong> 726 <strong>IBM</strong> 350 RAMAC Platte, 51 Platten im Stapel mit 24 Zoll Durchmesser.<br />
1956: Modell mit 5 MB (5 Millionen ‘Characters’), 1958: Modell mit 10 MB<br />
(10 Millionen ‘Characters’), Zurückziehung vom Vertrieb im Jahr 1960<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
<strong>IBM</strong> RAMAC 350-Plattenstapel<br />
Damals gab es noch keine Zugriffskämme, sondern nur einen<br />
Zugriffsarm, der in die Zwischenräume des Plattenstapels<br />
mit einer Seilzugmechanik hineingesteuert wurde. Die exakte<br />
Positionierung erfolgte mit Zahnstange und Klinke und wurde<br />
per Pressluft elektronisch gesteuert. Die Köpfe schwebten<br />
über der Platte in einem Abstand von 800 MicroInches. 1958<br />
wurde mit der Ankündigung des Modells 2 die Möglichkeit<br />
geschaffen, die doppelte Kapazität abzubilden (10 MB). Bei<br />
diesem Modell wurden zwei Zugriffsstationen eingesetzt, sodass<br />
eine Station schreiben oder lesen und die zweite gleichzeitig<br />
suchen konnte, um für die Verarbeitung des nächsten<br />
Satzes die Positionierung des Schreib/Lesekopfes vorzubereiten.<br />
<strong>IBM</strong> RAMAC 350 Platte mit zwei Zugriffsstationen <strong>IBM</strong> RAMAC 350 Einheit<br />
Verkaufstechnisch wurde bereits damals mit der RAMAC<br />
derselbe MarketingAnsatz gewählt, den man auch heute<br />
noch, nur in anderen Größenordnungen, vorfindet. Wie macht<br />
man dem Käufer und Benutzer klar, was 5 MB sind? 5 MB<br />
lagen damals über jeder normalen Vorstellungskraft. Deshalb<br />
wurden in den meisten Spezifikationsunterlagen 5 MB so definiert,<br />
dass das 60.000 – 80.000 Lochkarten entspreche,<br />
oder 2.000 Feet Bandlänge (die Bänder gab es ja bereits<br />
4 Jahre früher) oder 940 Seiten mit bedrucktem Papier.<br />
Neben dem RAMACPlattenstapel und der dazugehörigen<br />
Zugriffsstation enthielt die Einheit 350 eine elektronische<br />
und pneumatische Kontrolle für die Zugriffsstation und einen<br />
Luftkompressor. Die Schmierung der Plattenlager wurde durch<br />
eine ÖlDunstSchmierung durchgeführt.<br />
Die Einheit 350 hatte eine Länge von 152,4 cm (60 Inches),<br />
eine Höhe von 172,72 cm (68 Inches) und eine Tiefe von<br />
73,66 cm (29 Inches) und wog etwa eine Tonne.<br />
Das Gesamtsystem, bestehend aus Rechner, Platteneinheit,<br />
Kartenleser, Kartenstanzer, Drucker und Konsoleneinheit,<br />
kostete 185.000 Dollar und wurde auch unter Leasing zu<br />
einer monatlichen Rate von 3.200 Dollar angeboten. In dem<br />
Zeitraum von 1956 bis 1960 wurden weltweit 1.500 <strong>System</strong>e<br />
installiert. 1960 erfolgte dann die Zurückziehung aller Modelle<br />
vom Vertrieb und 1961 die Einstellung der Produktion.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
15
16<br />
1952 bis 1961<br />
Die Anfangsepoche der elektromagnetischen Speicherung<br />
Erstauslieferung <strong>IBM</strong> RAMAC 305 in Brasilien 1956<br />
1957 wurde der ‘Data Synchronizer’ am <strong>IBM</strong> <strong>System</strong> 709<br />
eingeführt, der Vorläufer der heutigen Übertragungskanäle.<br />
1959 führte <strong>IBM</strong> ein neues Programmpaket, das Eingabe/<br />
Ausgabesteuerungssystem IOCS für Magnetbänder und<br />
Magnetplatten (Input/Output Control <strong>System</strong>) ein. Es handelte<br />
sich um Makroinstruktionen zum Erstellen, Wiederauffinden<br />
und Verarbeiten von Dateien sowie zur Fehlerkorrektur.<br />
Außerdem steuerte IOCS die Datenblockbildung und die Entblockung.<br />
IOCS blieb für spätere <strong>System</strong>e von maßgeblicher<br />
Bedeutung.<br />
1958 verwendete <strong>IBM</strong> erstmals mit den <strong>System</strong>en <strong>IBM</strong> 7070<br />
und 7090 die Technik der automatischen Programmunterbrechung<br />
(Program Interrupt). Der Prozessor verzweigte bei<br />
bestimmten, von Eingabe/Ausgabeeinheiten angezeigten<br />
Bedingungen automatisch zu Routinen, die den ‘Interrupt’<br />
behandelten.<br />
1958 wurde die Bandeinheit <strong>IBM</strong> 729 als Nachfolger des<br />
Vorgängers <strong>IBM</strong> 727 auf den Markt gebracht. Die <strong>IBM</strong><br />
729Bandfamilie bot neben höheren Datenraten und höherer<br />
Speicherdichte die erste Schreibkontrolle. Mit der Einführung<br />
der <strong>IBM</strong> 729 wurde beim Schreiben auf Magnetband automatisch<br />
geprüft, ob die eben geschriebene Information gültig<br />
war. Dazu wurde Stelle für Stelle in ein Prüfregister eingelesen<br />
und geprüft.<br />
Im Oktober 1960 wurde der Plattenspeicher <strong>IBM</strong> 1405 ange<br />
kündigt, der an den <strong>System</strong>en <strong>IBM</strong> 1401, 1410 und 1460 (nicht<br />
an <strong>System</strong> 7000) betrieben wurde. Dieser Plattenspeicher<br />
vervierfachte die Kapazität eines Plattenstapels im Vergleich<br />
zur RAMAC von 1956. Sowohl die Anzahl der Spuren pro<br />
‘Inch’ als auch die Anzahl der Bits in einer Spur wurden verdoppelt,<br />
sodass eine vierfache Kapazität des Plattenstapels<br />
erreicht wurde. Die Plattenstapel waren in zwei Ausführungen<br />
verfügbar, in einer Einheit mit 25 Platten im Stapel und einer<br />
mit 50 Platten. Die kleinere Einheit hatte eine Kapazität von<br />
10 MB und die größere von 20 MB. Die Aufzeichnungsdichte<br />
betrug 220 Bits pro Inch, was 40 Spuren pro Inch entspricht.<br />
Die Schwebehöhe zwischen Kopf und Platte betrug 650 Micro<br />
Inches und die Platten drehten sich mit 1.800 Umdrehungen<br />
pro Minute. Die Datenrate lag bei 17,5 Kilobytes pro Sekunde.<br />
Der <strong>IBM</strong> 1405 Plattenspeicher kam vor allem beim <strong>IBM</strong><br />
1401Rechner zum Einsatz.<br />
Ein Jahr später, im Juni 1961, wurde die <strong>IBM</strong> 1301 Platten-<br />
einheit angekündigt. Sie wurde ein Jahr später, im 3. Quartal<br />
1962, an Kunden ausgeliefert. Die Entwicklung dieser Platteneinheit<br />
trug in größtem Maße zur Weiterentwicklung zukünftiger<br />
Plattensysteme bei und ist als Meilenstein in der gesamten<br />
Plattengeschichte zu betrachten. Das Platten system 1301 war<br />
der Wegbereiter zukünftiger zur Anwendung kommender<br />
Technologien in zwei Bereichen: die ‘Air Bearing Slider’<br />
Technologie und separate Schreib-/Leseköpfe für jede<br />
Plattenoberfläche mit der Möglichkeit, alle auf einen Datenzylinder<br />
physisch eingestellten Köpfe elektronisch für die<br />
zutreffende Plattenoberfläche zu selektieren und nacheinan<br />
<strong>IBM</strong> 1405 Plattenspeicher, Ankündigung am 10. Oktober 1960,<br />
Zurückziehung 30. Juni 1970<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
<strong>IBM</strong> 1301 Plattenspeichereinheit, Ankündigung im Juni 1961, Zurückziehung<br />
aller Modelle im Oktober 1970<br />
der zu bearbeiten. Damit war der Grundstein des Zylinder<br />
prinzips bei Plattenspeichern gelegt und der ‘Plattenzylinder’<br />
geboren!<br />
Neben höherer Kapazität und Leistung bot die Maschine eine<br />
wesentlich flexiblere und höhere Übertragungsbandbreite<br />
durch das Prinzip, pro Plattenoberfläche einen Schreib/Lesekopf<br />
zur Verfügung zu haben, und war auf die neue <strong>IBM</strong> 7000<br />
Serie von Rechnern abgestimmt (7070, 7094, 7080 und 7090).<br />
Die Kapazitätssteigerung zur ersten RAMAC lag bei Faktor 13.<br />
Die Platten rotierten mit 1.800 Umdrehungen in der Minute.<br />
Durch die Verkleinerung des Flugabstandes zwischen Kopf<br />
und Platte auf 250 MicroInches konnten 50 Spuren pro Inch<br />
und bis zu 520 Bits pro Inch aufgezeichnet werden. Das<br />
Modell 1 der <strong>IBM</strong> 1301 hatte ein Plattenmodul mit einer Kapazität<br />
von 28 MB, das Modell 2 arbeitete mit zwei Modulen und<br />
einer Kapazität von 56 MB. Angeschlossen an die <strong>IBM</strong> 7631<br />
Steuereinheit konnten bis zu 10 Module (oder bis zu fünf 1301<br />
Einheiten) zum Einsatz kommen, sie boten für die 7000Serie<br />
eine maximale Kapazität von bis zu 280 MB. Interessant waren<br />
auch die damaligen Preise: Das Modell 1 konnte monatlich<br />
für 2.100 Dollar geleast werden oder für eine Summe von<br />
115.500 Dollar gekauft werden. Das Modell 2 mit zwei<br />
Modulen lag bei 3.500 Dollar monatliche Leasingrate und<br />
einem Kaufpreis von 185.500 Dollar.<br />
<strong>IBM</strong> 7340 Hyper Tape Drives in der Bildmitte, links die <strong>IBM</strong> 7640 Kontrolleinheit,<br />
rechts die <strong>IBM</strong> 729 Bandeinheiten<br />
Die Hyper Tape Drives <strong>IBM</strong> 7340 reflektierten die neuste<br />
Bandtechnologie, als sie 1961 auf dem Markt eingeführt<br />
wurden. Zusammen mit der Kontrolleinheit <strong>IBM</strong> 7640 bedienten<br />
sie die <strong>IBM</strong> Rechner 7074, 7080 und 7090. Die Hyper Tapes<br />
erzielten wesentlich schnellere Lese und SchreibGeschwindigkeiten<br />
im Vergleich zu den bisherigen Bandeinheiten.<br />
Angeschlossen am <strong>IBM</strong> 7090 Rechner lieferten sie die doppelten<br />
Übertragungsraten im Vergleich zum <strong>IBM</strong> 729 Bandsystem,<br />
der Weiterentwicklung der <strong>IBM</strong> 727.<br />
Am 7. April 1964 wurde mit dem <strong>System</strong>/360 der Magnet-<br />
streifenspeicher <strong>IBM</strong> 2321 angekündigt. Mit seiner Gesamtspeicherkapazität<br />
von 400 MB auf 1.000 mit magnetisierbarer<br />
Oberfläche versehenen Plastikstreifen galt er zu dieser Zeit<br />
als Massenspeicher. Jeder Streifen enthielt 100 Datenspuren,<br />
hatte eine Kapazität von 0,2 MB und wurde in sogenannten<br />
‘<strong>IBM</strong> 2321 Data Cell Drives’ aufbewahrt. 200 solcher Streifen<br />
konnten in einer Datenzelle untergebracht werden. Die sich<br />
auf einem drehbaren Karussell befindlichen Datenzellen<br />
wurden durch Rotation so positioniert, dass der gesuchte<br />
Speicherstreifen durch einen Greifer erfasst und um die<br />
Schreib/Lesetrommel geführt werden konnte. Damit konnte<br />
die adressierte Datenspur gelesen oder beschrieben werden.<br />
Die aufwendige Konstruktion und der damit verbundene hohe<br />
Wartungsaufwand standen einer weiten Verbreitung entgegen.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
17
18<br />
1952 bis 1961<br />
Die Anfangsepoche der elektromagnetischen Speicherung<br />
Prinzip und Arbeitsweise des <strong>IBM</strong> 2321 Magnetstreifenspeichers<br />
<strong>IBM</strong> 2321, Gesamtkapazität von 400 MB, Ausbaustufen von 40 bzw. 80 MB,<br />
Zugriffszeiten von 95 bis 600 ms<br />
Kommentar zur Anfangsepoche<br />
der elektromagnetischen Speicherung<br />
Neben der Erfindung der ersten externen Speichereinheiten<br />
mit dem Rollenband <strong>IBM</strong> 726 und der Platteneinheit <strong>IBM</strong><br />
RAMAC 350 war der Topmeilenstein die Einführung der Platteneinheit<br />
<strong>IBM</strong> 1301.<br />
Die <strong>IBM</strong> 1301 war das erste Plattensystem, das mit ‘Air Bearing<br />
Slidern’ arbeitete und für den Zugriff einen Zugriffskamm<br />
verwendete, der jede Plattenoberfläche im Plattenstapel mit<br />
dedizierten Schreib/Leseköpfen ansteuerte. Mit der <strong>IBM</strong> 1301<br />
wurde die Zylinderarchitektur im Plattenstapel eingeführt, die<br />
bis heute ihren Stellenwert behalten hat.<br />
Bemerkenswert ist auch die Tatsache, dass bereits damals<br />
nach Möglichkeiten gesucht wurde, kleine Files, die nicht so<br />
häufig gebraucht wurden, auf einem billigeren Massenspeicher<br />
abzulegen. Für diesen Zweck wurde der Magnetstreifenspeicher<br />
<strong>IBM</strong> 2321 eingeführt.<br />
Geprägt wurde die Epoche auch dadurch, dass bei neuen<br />
<strong>System</strong>ankündigungen immer die dazugehörigen neuen Platteneinheiten,<br />
die dem neuen <strong>System</strong> leistungsmäßig angepasst<br />
waren, Teil der <strong>System</strong>ankündigung waren.<br />
Die Anfangsepoche legte viele Grundlagen für die Folgeepochen.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
1962 bis 1974<br />
Die Epoche der Wechselplatten und die ‘Winchester’-Zeit<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
19
20<br />
1962 bis 1974<br />
Die Epoche der Wechselplatten und die ‘Winchester’-Zeit<br />
<strong>IBM</strong> 1311: Ankündigung am 11. Oktober 1962, Zurückziehung aller Modelle 1971<br />
Die zwischen 1962 und 1964 eingeführten Magnetplatten-<br />
speicher <strong>IBM</strong> 1311, <strong>IBM</strong> 2311 und <strong>IBM</strong> 2314 zum Anschluss<br />
an die 360er<strong>System</strong>e arbeiteten mit auswechselbaren<br />
Magnetplattenstapeln. Die neue Plattensteuereinheit <strong>IBM</strong><br />
2841 war erstmals Mikroprogramm-gesteuert. Dies war<br />
erforder lich, weil mehrere Speichertypen gesteuert werden<br />
mussten, einschließlich des neu verwendeten CKDFormats.<br />
<strong>IBM</strong> entwickelte das Aufzeichnungsformat CKD (Count,<br />
Key, Data, frei übersetzt: Sektorkennzeichnung, Schlüssel,<br />
Daten), das als optimierte Version ECKD über das Jahr 2000<br />
hinaus gültig blieb und bis heute im Mainframe(z/OS)Umfeld<br />
eingesetzt wird. Das ‘E’ steht für ‘Extended’, also zu deutsch<br />
‘erweitert’. Wie ein Zugriff auf Daten nach dem CKDVerfahren<br />
abläuft, ist mit dem Produkt der <strong>IBM</strong> 3330 beschrieben.<br />
Das <strong>IBM</strong> 1302 Festplattensystem wurde am 23. September 1963 angekündigt<br />
und am 9. Februar 1965 wieder vom Vertrieb zurückgezogen<br />
Das erste Modell des Magnetplattenspeichers <strong>IBM</strong> 1311 mit<br />
Wechselplatten wurde im Oktober 1962 mit dem <strong>System</strong><br />
<strong>IBM</strong> 1440 angekündigt. Der Wechselplattenstapel war aus<br />
sechs 14ZollPlatten aufgebaut, wog 10 Pfund und bildete<br />
eine Speicherkapazität von 2 MB ab. Im Vergleich zur <strong>IBM</strong><br />
1301 verdoppelte sich die lineare Speicherdichte auf 1.025<br />
Bits pro Inch. Dies wurde dadurch erreicht, dass der Abstand<br />
zwischen den Köpfen zu den Plattenoberflächen im Vergleich<br />
zur <strong>IBM</strong> 1301 um Faktor 2 auf 125 MicroInches reduziert<br />
wurde. Die Platten drehten mit 1.500 RPMs und boten eine<br />
durchschnittliche Zugriffszeit von 150 ms.<br />
<strong>IBM</strong> 2401 Magnetbandeinheit<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
1963 wurde noch ein Nachfolger der <strong>IBM</strong> 1301 mit fest ein<br />
gebauten Platten angekündigt. Die <strong>IBM</strong> 1302 sah optisch<br />
genauso aus wie die <strong>IBM</strong> 1301, bot aber auf der Platten ober<br />
fläche 500 Datenspuren (1301 hatte 250 Spuren pro Plattenoberfläche).<br />
Wie bei der 1301 wurden 20 Platten im Stapel<br />
verwendet und die Kapazität von 28 MB auf 58,5 MB gesteigert.<br />
Damit bot das Modell 1 der 1302 eine Kapazität von<br />
117 MB und das Modell 2 von 234 MB. Die Datentransferrate<br />
wurde von 90 KB/s auf 180 KB/s gesteigert.<br />
1964 kam speziell für die Rechnerfamilie <strong>System</strong>/360 das<br />
neue Magnetbandsystem <strong>IBM</strong> 2401 auf den Markt, das mit<br />
9 Spuren gleichzeitig auf dem Rollenband aufzeichnen konnte<br />
und eine wesentlich höhere Zuverlässigkeit im Vergleich zu<br />
den Vorgängern <strong>IBM</strong> 726, 727 und 729 bot. Dies wurde durch<br />
die Einführung eines sogenannten CRC (Cyclic Redundancy<br />
Check) erreicht, das die erste automatische Fehlerkorrektur<br />
ermöglichte (Automatic Error Capture & Correction) und Basis<br />
für die späteren ECCs (Error Correction Codes) bei Bandsystemen<br />
lieferte.<br />
Im April 1965 – ein Jahr nach der Ankündigung des Prozes<br />
sors <strong>System</strong>/360 – wurde das Plattensystem <strong>IBM</strong> 2314 als<br />
‘<strong>IBM</strong> Direct Access <strong>Storage</strong> Facility’ angekündigt. Dies war<br />
das erste Plattensystem, bei dem Controller und der Strang<br />
mit Plattenstapeln in einer Konfiguration bestellt und aufgebaut<br />
werden konnten. Mit der 2314 wurde ein neuer Plattenstapel<br />
mit der doppelten Anzahl an Plattenoberflächen eingeführt,<br />
der eine Speicherkapazität von 29,2 MB abbildete.<br />
Das Gesamtsystem bot eine maximale Kapazität von 233,4<br />
MB. Im Vergleich zur 1311 war die 2314 um den Faktor 4<br />
billiger, was das gespeicherte MB betraf. Die Datenrate lag bei<br />
310 KB pro Sekunde. Im Januar 1969 kamen zwei neue Versionen<br />
der 2314 auf den Markt, die Modelle A1 und A2, die<br />
<strong>IBM</strong> 2314 Produktionslinie in Mainz 1969<br />
<strong>IBM</strong> 2305 Fixed Head <strong>Storage</strong>, bekannt als ‘Zeus-Speicher’, Markteinführung<br />
1971, Zurückziehung vom Vertrieb im Januar 1980<br />
eine um 20 % schnellere Zugriffszeit boten, die im Bereich<br />
von 60 bis 75 ms lag. Die Kapazität blieb dieselbe. Im<br />
Dezember 1970 wurde die Plattenfamilie 2314 noch durch<br />
ein Modell B1 ergänzt, das 50 % höhere Kapazität anbot.<br />
Im Januar 1970 wurde das Plattensystem ‘<strong>IBM</strong> 2305 Fixed<br />
Head <strong>Storage</strong>’ angekündigt, das unter dem Entwicklungsnamen<br />
‘Zeus’ entwickelt wurde und als <strong>IBM</strong> Zeus bekannter<br />
wurde als unter dem offiziellen Typennamen. 1971 erfolgten<br />
die ersten Auslieferungen. Die <strong>IBM</strong> 2305 war für große Datenbankanwendungen<br />
und für das Batch Processing bestens<br />
geeignet und wurde bei großen <strong>System</strong>/360 Rechnern der<br />
Modelle 85 und 195 und später dann bei den <strong>System</strong>/370<br />
Modellen 155 und 165 für diese Applikationsformen eingesetzt.<br />
Mit zwar kleinen Speicherkapazitäten von 5,4 MB und<br />
10,8 MB, jedoch mit einer durchschnittlichen Zugriffszeit von<br />
2,5 ms bzw. 5 ms war das <strong>System</strong> das schnellste seiner<br />
Zeit. Die Datenrate lag bei 3 MB/s und damit 10fach höher<br />
als bisherige Plattensysteme.<br />
<strong>IBM</strong> 2314 Plattensystemfamilie, Ankündigung Modell 1 am 22. April 1965, Modelle A1 und A2 am 10. Januar<br />
1969, Modell B1 am 14. Dezember 1970, Zurückziehung vom Vertrieb im Jahr 1978<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
21
22<br />
1962 bis 1974<br />
Die Epoche der Wechselplatten und die ‘Winchester’-Zeit<br />
1970 bis 1972: Der virtuelle Speicher, der auf Magnetplatten<br />
abgebildet wurde, schaffte eine neue Qualität in der Beziehung<br />
zwischen Prozessoren und Magnetplattenspeichern.<br />
OnlineAnwendungen gewannen rasch an Bedeutung. Wie<br />
die neuen Prozessoren <strong>IBM</strong>/370 trugen Subsysteme aus<br />
den Steuereinheiten <strong>IBM</strong> 3830 und Magnetplatteneinheiten<br />
<strong>IBM</strong> 3330 den steigenden Leistungs und Zuverlässigkeitsanforderungen<br />
Rechnung. Neue Blockmultiplexkanäle sorgten<br />
für wesentlich höhere Datenübertragungsraten und trugen zu<br />
einer wesentlich höheren Gesamtleistung bei. Dazu einige<br />
Einzelheiten:<br />
Die Plattensteuereinheit <strong>IBM</strong> 3830 war Mikroprogrammgesteuert,<br />
jedoch erstmals mit einem ladbaren Mikroprogrammspeicher,<br />
der über eine Diskette geladen wurde. Mit dem<br />
Mikroprogramm war es möglich, mehr Funktionen als in den<br />
Vorgängermodellen zu realisieren. Dazu zählten das Erkennen<br />
und Beseitigen von Bitfehlern, gegebenenfalls mehrfaches<br />
Wiederholen von Kanalbefehlen vor Übergabe einer Fehlerbehandlung<br />
an den Rechner und das Sammeln von Informationen<br />
über aufgetretene Fehler für das <strong>System</strong>protokoll<br />
(LogRec). Diese Aufzeichnungen lieferten den Bedienern<br />
Informationen über den technischen Zustand von Datenträgern<br />
und boten dem technischen Außendienst Hinweise für<br />
vorbeugende Wartung.<br />
Bei der Empfindlichkeit magnetischer Aufzeichnung gegen<br />
elektrische und mechanische Störungen musste man von<br />
Anfang an mit Bitfehlern rechnen. Über Zusatzbits zur Paritätsprüfung<br />
entwickelte <strong>IBM</strong> immer ausgefeiltere Methoden, um<br />
Redundanzbits zu generieren, die den gespeicherten Daten<br />
angehängt wurden. Bei den Aufzeichnungsformaten CKD<br />
und ECKD findet diese ‘Redundanz’Aufzeichnung in den<br />
Zwischenräumen (Gaps) zwischen den Datensätzen statt.<br />
Mit ihrer Hilfe ließen sich durch entsprechende Programme<br />
in Rechnern und Steuereinheiten die meisten Bitfehler beim<br />
Übertragen ohne nennenswerte Zeitverzögerung korrigieren<br />
und durch technische Einflüsse verfälschte Daten praktisch<br />
ausschließen. Die Verfahren setzten für jede Datei die Definition<br />
sogenannter ‘physischer Sätze’, einer einheitlichen Länge<br />
in Bytes, voraus. Solche Sätze wurden als Blöcke bezeichnet.<br />
Bei Eingabe/AusgabeOperationen wurden immer komplette<br />
Blöcke übertragen und geprüft. Meistens war es zweckmäßig,<br />
in einem Block mehrere ‘logische Sätze’ zusammenzufassen.<br />
Sie bestanden aus einem Ordnungsbegriff, dem in ‘Feldern’,<br />
die nach Lage und Länge definiert waren, die zugehörigen<br />
Angaben und Informationen folgten. Bei administrativen<br />
Anwendungen wären z. B. Artikel, Kunden oder Personalnummern<br />
die Ordnungsbegriffe. In den Feldern standen dann<br />
alphabetische und numerische Informationen. Die Anzahl der<br />
logischen Sätze im physischen Satz bezeichnete man als<br />
Blockungsfaktor.<br />
<strong>IBM</strong> 3330, Kapazität 800 MB, 2-8 Laufwerke, Zugriffszeit 30 ms, Datenrate 806 KB/s, Ankündigung Modell 1 am 30. Juni 1970,<br />
Modell 2 am 4. Oktober 1972, Modell 11 am 17. Juli 1973, Zurückziehung vom Vertrieb am 20. Dezember 1983<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Nach bisherigen hydraulischen Zugriffsmechanismen<br />
benutzten die Magnetplatteneinheiten <strong>IBM</strong> 3330 erstmals für<br />
das ‘Suchen’, die horizontale Einstellung des Zugriffskammes<br />
mit den Schreib/Leseköpfen, einen Linearmotor.<br />
Wie bei Lautsprechern wirkt ein durch variablen Stromfluss<br />
in einer Spule erzeugtes Magnetfeld dem statischen Feld<br />
eines Permanentmagneten entgegen. Deshalb die englische<br />
Bezeich nung ‘Voice Coil Motor’ (Lautsprecherspulenmotor).<br />
Die Lage der Schreib/Leseköpfe zu bestimmten Zeitpunkten<br />
ergab sich aus der Stärke des von der Spule<br />
erzeugten Magnetfelds. Diese Technik setzte voraus, dass<br />
jeweils eine Oberfläche eines Plattenstapels mit vom Benutzer<br />
unveränderbaren Servo spuren versehen war. Der darüber<br />
angeordnete (Nur)Lesekopf versorgte die elektronische Steu<br />
erung mit den für gezieltes Positionieren im Rahmen eines<br />
Regelungskreislaufs notwen digen Informationen. Diese<br />
Technik reduzierte damals die durchschnittliche Dauer einer<br />
Suchoperation auf Anhieb um die Hälfte: statt 60 dann nur<br />
noch 30 ms.<br />
Für einen verbesserten Ablauf des direkten Zugriffs auf Daten<br />
war Folgendes von Bedeutung: Die Steuereinheit <strong>IBM</strong> 3830<br />
konnte mithilfe entsprechender Informationen von der Servoplatte<br />
als erste die Dreh oder Winkelposition der an sie<br />
angeschlossenen Magnetplatteneinheiten erkennen (RPS –<br />
Rotational Position Sensing). Mit dem Plattensystem <strong>IBM</strong><br />
3830/3330 lief ein Routinezugriff wie folgt ab: Nach Angaben<br />
aus den Datenträgerinhaltsverzeichnissen, den sogenannten<br />
VTOCs (Volume Table Of Contents), und den Indizes zu den<br />
Dateien generierte der Rechner mithilfe der Programme der<br />
Zugriffsmethodensteuerung einen Kanalbefehl. Dieser enthielt<br />
die Plattenadresse, von der zu lesen oder auf die zu schreiben<br />
war, nach Einheit, Zylinder, Spur und Sektor. Die konzentrischen<br />
Spuren auf den Plattenoberflächen waren in Sektoren<br />
eingeteilt. Als Zylinder bezeichnete man die Summe<br />
der übereinanderliegenden Spuren auf einem Plattenstapel,<br />
von denen bei einer gegebenen horizontalen Einstellung<br />
eines Zugriffskammes mit ebenfalls übereinander angeordneten<br />
Schreib/Leseköpfen gelesen oder auf die geschrieben<br />
werden konnte. Die Steuereinheit wandelte den Kanalbefehl<br />
in spezifische Befehle für die Einheiten um. Den<br />
Suchbefehl zum Einstellen des Zugriffskammes auf den korrekten<br />
Zylinder führten die Einheiten selbstständig aus und<br />
meldeten der Steuereinheit den Abschluss der Suchoperation.<br />
Dann aktivierte die Steuereinheit den richtigen Schreib/<br />
Lesekopf, analysierte seine Position bezogen auf die Sektoren<br />
und begann mit dem Übertragen der Daten über den<br />
<strong>IBM</strong> 3340, Maximalkapazität bis 4.800 MB, Winchester-Wechselplatten<br />
Modell 35: 35 MB, Modell 70: 70 MB, bis zu 64 Laufwerke (Modelle 158, 168),<br />
Datenrate 885 KB/Sekunde, Zugriffszeit 25 ms<br />
Kanal des Rechners, sobald der Anfang des im Kanalbefehl<br />
vorgegebenen Sektors erreicht war. Der Kanal war nur während<br />
der Datenübertragung belegt. Mehrere Platteneinheiten<br />
konnten Suchbefehle überlappt ausführen. Auch die Umdrehungswartezeit<br />
(damals bei ca. 17 bis 20 ms) belastete den<br />
Kanal nicht. Diese Methode erlaubte höhere systemeffektive<br />
Daten raten des Magnetplattensystems, die bei günstigen<br />
Konfigurations und Anwendungsprofilen nicht sehr weit<br />
unter der Übertragungsleistung der Einheiten lag.<br />
1973: Das an mittlere Rechnersysteme <strong>IBM</strong>/370, Modelle 115,<br />
125 und 135, direkt anschließbare neue Magnetplattensystem<br />
<strong>IBM</strong> 3340 benutzte als auswechselbaren Datenträger das<br />
Datenmodul <strong>IBM</strong> 3348. Die auswechselbaren Datenmodule<br />
3348 boten 35 oder 70 MB Kapazität. Ein Modul enthielt in<br />
einem geschlossenen, staubgeschützten Gehäuse den Plattenstapel<br />
und einen horizontal beweglichen Zugriffskamm mit<br />
zwei Schreib/Leseköpfen je Datenoberfläche. Das Modul war<br />
auf die Welle des Antriebsmotors im Laufwerk aufgesetzt.<br />
Nach dem automatischen Öffnen einer seitlichen Jalousie<br />
verbanden elektrische Steckverbindungen den Zugriffskamm<br />
mit dem Laufwerk und eine mechanische Verbindung den<br />
Zugriffskamm mit dem Linearmotor. Der Grund für diese Konstruktion:<br />
Wenn auswechselbare Plattenstapel als Datenträger<br />
dienten, bedeu tete das insbesondere für Zugriffskämme<br />
extreme Ansprüche an die Fertigungstoleranzen, weil jeder<br />
Stapel zu jedem beliebigen Laufwerk passen musste und<br />
schon minimale horizontale Abweichungen der Köpfe über<br />
den Spuren zu Lesefehlern führte. Dieser Umstand setzte der<br />
horizontalen Spurdichte Grenzen und minderte die Sicherheit<br />
und Zuverlässigkeit der <strong>System</strong>e. Maximal vier Module mit<br />
einer maximalen Kapazität von 280 MB konnten über einen<br />
Direkt anschluss am <strong>IBM</strong>/370 Rechner betrieben werden.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
23
24<br />
1962 bis 1974<br />
Die Epoche der Wechselplatten und die ‘Winchester’-Zeit<br />
Aufbau <strong>IBM</strong> 3340 Winchester-Wechselplattenstapel<br />
Die <strong>IBM</strong> 3340 mit den Modellen A2, B1, B2 und C2 wurden<br />
am 13. März 1973 angekündigt. Die Modelle B1 und C2<br />
wurden am 20. Dezember 1983 und die Modelle A2 und B2<br />
am 1. Mai 1984 vom Vertrieb zurückgezogen.<br />
Die Tatsache, dass beim Datenmodul der Magnetplattenspeicher<br />
<strong>IBM</strong> 3340 immer der gleiche Zugriffskamm schrieb<br />
und las, ermöglichte höhere Spurdichten bei gleichzeitig gesteigerter<br />
Zuverlässigkeit. Die Konstruktion insgesamt führte<br />
zu kürzeren Suchzeiten und etwas höherer Übertragungsleistung<br />
gegenüber der <strong>IBM</strong> 3330.<br />
Mit den neuen Magnetbandeinheiten <strong>IBM</strong> 3420, Modelle 3,<br />
5 und 7, die in 9SpurTechnik mit einer Aufzeichnungsdichte<br />
von 1.600 Bytes pro Zoll arbeiteten, konnte eine Datenrate –<br />
je nach Modell – von 120, 200 und 320 Kilobytes pro Sekunde<br />
erzielt werden. Diese Modelle wurden 1970 eingeführt.<br />
Die neuen Magnetbandeinheiten <strong>IBM</strong> 3420, Modelle 4, 6<br />
und 8, die 1973 auf dem Markt eingeführt wurden, steigerten<br />
mit dem Verfahren der ‘gruppencodierten Aufzeichnung’<br />
(Group Coded Recording) die Aufzeichnungsdichte von<br />
1.600 auf 6.250 Bytes per Zoll und die maximale Übertragungsrate<br />
wurde – je nach Modell – auf 470, 780 und 1.250<br />
Kilobytes pro Sekunde gesteigert. Gleichzeitig erhöhte sich<br />
die Zuverlässigkeit um den Faktor 7 (im Vergleich zu den<br />
Modellen 3, 5, und 7).<br />
Um die Bedienung zu erleichtern, kündigte <strong>IBM</strong> 1971 parallel<br />
zum 3420 Magnetbandsystem das <strong>IBM</strong> 3410 Magnetband-<br />
system an, das von der Bauhöhe her Pultform hatte und<br />
erstmals erlaubte, die Rollenbänder horizontal von oben einzulegen.<br />
Die Kapazitäten und die Technologie waren mit der<br />
3420 vergleichbar, allerdings war die Schreib/Lesegeschwindigkeit<br />
wesentlich niedriger. Die 3410 wurde deshalb – neben<br />
dem 3420 Magnetbandhochleistungssystem – als kostengünstige<br />
Alternative für Benutzer der <strong>IBM</strong> <strong>System</strong>/370 und<br />
<strong>IBM</strong> <strong>System</strong>/360 angeboten.<br />
1974: Im Zuge des verstärkten Übergangs der mit dem <strong>System</strong>/370<br />
begonnenen Direktverarbeitung mit preisgünstigen<br />
Terminals zur Programmentwicklung und Problemlösung<br />
(VM/370, APL) wuchs die Zahl der Dateien bei Benutzern<br />
großer <strong>System</strong>e dramatisch. Anders als bei den mit wenigen<br />
großen Dateien und ausgefeilten Sicherungsverfahren arbeitenden<br />
Datenbankanwendungen (IMS, CICS) wurde es<br />
immer schwieriger, speziell die vielen kleinen, unregelmäßig<br />
<strong>IBM</strong> 3420 Magnetbandeinheit, 1970 Modelle 3, 5 und 7, 1973 Modelle 4, 6 und 8 <strong>IBM</strong> 3410 Magnetbandsystem mit horizontaler Bandeinlegemöglichkeit<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
enutzten Bestände unter manueller Verwaltung zuverlässig<br />
zu sichern und zu archivieren. Um diese Aufgabe zu lösen<br />
und um kostengünstigeres Speichern von Daten unter <strong>System</strong>kontrolle<br />
zu ermöglichen, führte <strong>IBM</strong> neue Hardware und<br />
Software ein.<br />
Der Massenspeicher MSS (Mass <strong>Storage</strong> <strong>System</strong>) <strong>IBM</strong><br />
3850 bildete auf zwei speziellen zylinderförmigen<br />
Magnetband patronen den Inhalt eines Datenträgers des<br />
Magnetplattenspeichers <strong>IBM</strong> 3330 ab. Man kann ihn als<br />
ersten virtuellen ‘Plattenspeicher’ bezeichnen, der gleichzeitig<br />
ein automa tisches Bandarchiv darstellte. Alle aktiven<br />
Patronen lagerten in einem Schrank mit einander gegenüberliegenden<br />
Regalen in wabenförmigen Zellen. Bei Anforderung<br />
durch die Programme bewegte eine sinnreiche Konstruktion<br />
einen sogenannten Picker automatisch zur richtigen<br />
Patrone. Der Picker hielt den Datenträger im Gegensatz zu<br />
späteren mechanischen Greifern elektromagnetisch fest und<br />
brachte ihn zu einer Schreib/Lesestation, von der die<br />
gewünschten Daten zum Verarbeiten auf bestimmte<br />
Magnetplattenlaufwerke (Staging Devices) übertragen wurden<br />
oder umgekehrt. Nach Ablauf der Operation brachte<br />
die gleiche Vorrichtung die Patronen an ihren Lagerort<br />
zurück. Der Bediener war nur noch mit den Patronen befasst,<br />
die der Massenspeicher nach Programmvorgaben über<br />
entsprechende Stationen aussteuerte oder die er von außen<br />
anforderte. Der Massenspeicher konnte bis zu 236 GB im<br />
Zugriff der Prozessoren halten. Die technische Entwicklung<br />
der Magnetspeicher – Platte, Band – ließ keinen sinnvollen<br />
Nachfolger zu, während die zugehörige Software bis heute,<br />
im Jahr 2006, hochaktuell blieb.<br />
<strong>IBM</strong> Mass <strong>Storage</strong> <strong>System</strong> 3850 mit ‘Honeycomb Racks’ 1974<br />
<strong>IBM</strong> MSS 3850 im Rechenzentrum im Hintergrund rechts<br />
ILM, Information Lifecycle Management, das heute in<br />
aller Munde ist, wurde bereits intensiv im Jahr 1974 gelebt!<br />
Der HSM (Hierarchical <strong>Storage</strong> Manager) als Verwalter der<br />
Speicherhierarchie war damals ein Programm, das zunächst<br />
in Verbindung mit dem Massenspeicher die ihm unterstellten<br />
Dateien gemäß vorgegebener Steuerungskriterien automatisch<br />
sicherte und im Bedarfsfall wiederherstellte. Eine weitere<br />
damals bereits verfügbare Funktion war das Verlagern von<br />
Dateien vom teuren Plattenspeicherplatz auf billigere Speicher<br />
(ursprünglich auf den MSS) während der Zeiten, in denen<br />
sie nicht benötigt wurden. Um den Speicherplatz optimal zu<br />
nutzen, konnte der HSM zu archivierende Dateien komprimieren,<br />
indem er leere Bereiche auf den Datenträgern ausließ,<br />
und er konnte darüber hinaus Daten mithilfe binärarithmetischer<br />
Verfahren verdichten (Compression, Compaction).<br />
Zum Verarbeiten stellte er den ursprünglichen Zustand der<br />
betreffenden Datei wieder her.<br />
An unterschiedlichste Konfigurationen mit unterschiedlichen<br />
externen Speichern angepasst, blieb der HSM fester Bestandteil<br />
späterer Pakete von Dienstleistungsprogrammen für den<br />
Bereich externer Speicher, z. B. der <strong>IBM</strong> DFProdukte (Data<br />
Facility), die den systemverwalteten Speicher zum Ziel hatten.<br />
So wurden die DFProdukte als Programmprodukte im MainframeUmfeld,<br />
beginnend mit DFP, 1989 eingeführt. Kurz<br />
darauf folgte der DFDSS und der DFHSM, die dann alle unter<br />
dem Programmpaket DFSMS (Data Facility <strong>System</strong> Managed<br />
<strong>Storage</strong>) 1992 zusammengefasst wurden und ein Jahr später<br />
komplett ins MVSBetriebssystem integriert wurden. HSM<br />
spielt unter unterschiedlichen Bezeichnungen bis heute eine<br />
ganz maßgebliche Rolle.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
25
26<br />
1962 bis 1974<br />
Die Epoche der Wechselplatten und die ‘Winchester’-Zeit<br />
<strong>IBM</strong> 3850 Roboter mit Doppelgreifer (Standard) in Aktion <strong>IBM</strong> 3850 Bandpatronen mit 19,5 Metern Bandlänge und einer Kapazität von<br />
jeweils 50 MB im Größenvergleich zum 3330 Plattenstapel mit 100 MB<br />
Kapazität<br />
Das MSS 3850 gab es in acht Modellvarianten. Das kleinste<br />
Modell speicherte bis zu 706 Bandpatronen, bot eine Kapazität<br />
von 35,3 GB und konnte bis zur größten Variante mit<br />
bis zu 4.720 Patronen und einer Kapazität von 236 GB ausgebaut<br />
werden.<br />
Kommentar zur Epoche der Wechselplatten und<br />
der ‘Winchester‘-Zeit<br />
Das starke Ansteigen der Rechnerleistungen durch neue<br />
<strong>System</strong>e machte es notwendig, viele neue Dinge auf der<br />
Speicherseite einzuführen, um den neuen Leistungsanforderungen<br />
dieser Rechner gerecht zu werden.<br />
So wurden mit der <strong>IBM</strong> 2841 und <strong>IBM</strong> 3830 die ersten Mikroprogrammgesteuerten<br />
Steuereinheiten und das bis heute<br />
gültige CKDFormat (heute ECKD bei zSeries) eingeführt. Für<br />
höhere Übertragungsbandbreiten sorgten die neu eingeführten<br />
BlockmultiplexingKanäle, die maßgeblich zu einer Verbesserung<br />
der Gesamtleistung von Rechner und Speicherperipherie<br />
beitrugen.<br />
Bei den Platten selbst wurden kleinere Formfaktoren und<br />
kleinere Flughöhen zwischen Kopf und Plattenoberfläche<br />
eingeführt, um die Leistung durch schnellere Drehgeschwindigkeiten<br />
und Datenraten sowie die kapazitiven Möglichkeiten<br />
zu verbessern. Fast parallel dazu wurde die Leistung der<br />
Bandsysteme angepasst und durch neue Möglichkeiten der<br />
Mehrspurtechnik wurden die Datenraten erhöht.<br />
Die Epoche war wie die Anfangsepoche durch neue <strong>System</strong>ankündigungen<br />
geprägt, in denen immer das dafür passende<br />
Platten und Bandsystem Teil der Ankündigung war. Davon<br />
losgelöste Speicherankündigungen fanden nicht statt.<br />
Der Einsatz der damals verwendeten Wechselplatten war bei<br />
den Endbenutzern sehr beliebt, weil man diese tragbaren<br />
Plattenmodule auch für den Datenträgeraustausch zwischen<br />
unterschiedlichen Lokationen einsetzen konnte. Die 1970 und<br />
1973 neu angekündigten Modelle der 3420 wurden auschließlich<br />
für BackupZwecke eingesetzt. Erst in der Folgeepoche,<br />
in der man wieder fest eingebaute Platten einsetzte und<br />
vom Prinzip der Wechselplatten wegging, erlebte die 3420<br />
eine wahre Blütezeit. Das Rollenband war dann das einzige<br />
Medium, das als auswechselbarer Datenträger eingesetzt<br />
werden konnte.<br />
Da die kapazitiven Anforderungen immer größer wurden und<br />
neben OnlineSpeichern neue Massenspeicher mit höheren<br />
Kapazitäten verlangt wurden, war eines der Meilensteine dieser<br />
Epoche sicherlich das <strong>IBM</strong> 3850 Mass <strong>Storage</strong> <strong>System</strong>,<br />
das erste NearlineRoboter<strong>System</strong> der Welt mit Bandpatronen,<br />
die wie die damaligen Wechselplatten als OnlineSpeicher<br />
adressiert wurden. Die Tatsache, dass bei dem MSS erstmals<br />
ILM über eine HSMFunktionalität eingeführt wurde, muss<br />
besonders hervorgehoben werden. Diese HSMFunktionalität<br />
legte den Grundstein für die späteren DFProdukte (Data<br />
Facility) im MainframeUmfeld.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Die Epoche der fest eingebauten Platten<br />
mit externen Kontrolleinheiten<br />
1975 bis 1993<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
27
28<br />
1975 bis 1993<br />
Die Epoche der fest eingebauten Platten mit externen Kontrolleinheiten<br />
<strong>IBM</strong> 3350, Kapazität bis 2.536 MB, 317 MB per LW, 8 Laufwerke pro 3350<br />
Strang, Zugriffszeit 25 ms, Datenrate 1.198 KB/s, links hinten: Display-Einheit<br />
für Microfiches, rechts hinten: Steuerkonsole des <strong>System</strong>s/370 Modell 168<br />
1975: Mit dem Magnetplattenspeicher <strong>IBM</strong> 3350 ging die<br />
<strong>IBM</strong> wieder zu fest eingebauten Platten über. Das bedeutete<br />
einen entscheidenden Schritt zu höherer Zuverlässigkeit<br />
und Verfügbarkeit sowie höherer Aufzeichnungsdichte. Bei<br />
dieser Konstruktion waren gegenüber der mit Datenmodulen<br />
arbeitenden Type <strong>IBM</strong> 3340 potenzielle Störstellen nicht mehr<br />
vorhanden, auf die 70 % der notwendigen Technikereingriffe<br />
zurückzuführen waren. Tatsächlich registrierte der <strong>IBM</strong> Technische<br />
Außendienst bei <strong>IBM</strong> 3350 im Durchschnitt weniger<br />
als einen Eingriff pro Einheit und Jahr. <strong>IBM</strong> 3350 und die Nachfolgeprodukte<br />
setzten das mit <strong>IBM</strong> 3330 begonnene Strangkonzept<br />
fort. An eine Kopfeinheit (Master Unit) mit zwei Laufwerken<br />
konnte man bis zu drei Nebeneinheiten anschließen.<br />
Ein Strang bestand also aus acht Laufwerken. Die Kopfeinheit<br />
besaß grundsätzlich zwei Ein/Ausgänge zur Steuereinheit<br />
<strong>IBM</strong> 3830. Die beiden Verbindungen konnten zu verschiedenen<br />
Einheiten 3830 führen. Fielen ein Kanal, eine Steuerung<br />
oder Steuerelemente in der Kopfeinheit aus, lief der Betrieb<br />
auf der zweiten Verbindung zu jedem Laufwerk weiter, wenn<br />
auch mit geringerer Leistung. Man kann in diesem neuen<br />
Konzept den ersten Einstieg in Konzepte der Fehlertoleranz<br />
erkennen.<br />
Weil mit dem Magnetplattensystem <strong>IBM</strong> 3350 mit fest eingebauten<br />
Platten nun die Magnetbandrolle das einzige auswechselbare<br />
Speichermedium für Datensicherung, Offline<br />
<strong>IBM</strong> 3310 Direct Access <strong>Storage</strong>, Plattensystem für <strong>IBM</strong> 4331 Rechner<br />
Archivierung und Datenträgeraustausch blieb, löste die <strong>IBM</strong><br />
3350 einen deutlichen Verkaufsanstieg bei Magnetbandeinheiten<br />
aus, insbesondere bei den schnellen Modellen 6 und 8<br />
des Magnetbandsystems 3420. Fortan waren Magnetbänder<br />
unverzichtbarer Bestandteil größerer und auch mittlerer Datenverarbeitungssysteme.<br />
1979 führte <strong>IBM</strong> ein weiteres Plattensystem ein, das <strong>IBM</strong> 3310<br />
Direct Access <strong>Storage</strong>, das in einer kompakten Bauweise<br />
hohe Leistung bei einem sehr günstigen Preis bot und seinen<br />
Einsatz im Anschluss an <strong>IBM</strong> 4331, 4341, 4321, 4361 und<br />
kleine 4381 Rechner fand. Jeder Plattenstapel bot eine<br />
Gesamtkapazität von 64,5 MB und der gesamte Plattenstrang<br />
258 MB. Bis zu vier Plattenstränge konnten an obigen Rechnermodellen<br />
betrieben werden und boten eine Gesamtkapazität<br />
von 1.032 MB.<br />
1979 bis 1983: <strong>IBM</strong> 3370 und 3375 waren neu entwickelte<br />
Magnetplatteneinheiten an der neuen Steuereinheit <strong>IBM</strong> 3880<br />
für damals mittlere <strong>System</strong>e. Sie arbeiteten aus Gründen der<br />
Vereinfachung und Beschleunigung von Programm abläufen<br />
mit festen Blöcken von 512 Bytes. Der Benutzer definierte<br />
größere Blocklängen mit einem Vielfachen von 512. Damit<br />
war die erste FBA(Fixed Block Architecture)Platte geboren.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
<strong>IBM</strong> 3380 Platten und 3880 Steuereinheiten füllten damals ganze Rechenzentrumshallen<br />
Die neue <strong>IBM</strong> 3880 Steuereinheit leitete ein neues Steue<br />
rungsprinzip ein, das in der Weiterentwicklung 1985 die erste<br />
Integration von Pufferspeichern, anfangs von 8 bis 16 MB,<br />
zur Folge hatte. Diese kleinen Pufferspeicher waren für das<br />
Ein und Auslagern von Seiten (Paging, Swapping) gedacht<br />
und wirkten sich zunächst auf die Leistung älterer Konfigurationen<br />
ohne Erweiterungsspeicher aus. Die Verwendung von<br />
größeren Pufferspeichern führte dann zur Einführung neuer<br />
CachingAlgorithmen. Die zu schreibenden Daten wurden in<br />
der Steuereinheit auf Halbleiterspeicherkarten zwischengespeichert<br />
und auf einem stromunabhängigen Schreibspeicher<br />
dupliziert. Danach meldete die Steuereinheit dem Rechner<br />
den Abschluss der Operation, obwohl die Daten noch nicht<br />
auf die Platten geschrieben waren. Diese Operation wurde<br />
damals als ‘DASD Fast Write’ bezeichnet, weil durch dieses<br />
Prinzip die Antwortzeiten zwischen den Plattensystemen und<br />
dem Rechner um ein Vielfaches verbessert wurde. Dieses<br />
damals eingeführte ‘Caching’Prinzip für Plattensubsysteme<br />
wurde dann rasch weiterentwickelt und hat bis heute<br />
Gültigkeit.<br />
1981: <strong>IBM</strong> 3380 waren Magnetplatteneinheiten, die als<br />
Neuentwicklung für die 3880 Steuereinheiten optimiert waren<br />
und das CKDFormat fortsetzten. Die <strong>IBM</strong> 3380 übertrug mit<br />
3 MB pro Sekunde und nutzte dabei spezielle Fähigkeiten<br />
der Blockmultiplexkanäle (Data Streaming). Die neuen Lauf<br />
werke kamen gerade rechtzeitig, denn zu diesem Zeitpunkt<br />
war deutlich geworden, wie notwendig es bei der engen<br />
Beziehung zwischen Prozessoren und Plattenspeichern war,<br />
die Leistung beider aufeinander abzustimmen.<br />
1981 wurden die Standardmodelle AA4 und B04 der <strong>IBM</strong> 3380<br />
angekündigt. 1985 folgten die erweiterten Modelle AD4, BD4,<br />
AE4 und BE4. 1987 wurden die schnellen AJ4 und BJ4 und<br />
die schnellen, großkapazitiven Modelle AK4 und BK4 angekündigt.<br />
Ebenso erfolgte 1987 die Ankündigung der 3380 CJ2,<br />
eines Modells, bei dem die Steuereinheit im Plattengehäuse<br />
integriert war.<br />
<strong>IBM</strong> 3370, 1 Plattenstapel pro Einheit mit 2 Zugriffsarmen und 2 Adressen,<br />
Modell 1: 571 MB, Modell 2: 730 MB, jeweils per Einheit, bis zu 4 Einheiten<br />
mit 2.285 – 2.920 MB Kapazität, Zugriff 20 ms, Datenrate 1,86 MB/s<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
29
30<br />
1975 bis 1993<br />
Die Epoche der fest eingebauten Platten mit externen Kontrolleinheiten<br />
Die Zeit der 3380Platte brachte im Antwortzeitverhalten, im<br />
Durchsatz und in den hohen Kapazitäten für die damals betrie<br />
benen <strong>IBM</strong> Rechner 3031, 3032, 3033, 3042 und /370 große<br />
Fortschritte. Die durchschnittlichen Suchzeiten bewegten<br />
sich – je nach Modell – zwischen 12 und 16 ms. Immer zwei<br />
Laufwerke waren in einer Gehäuseeinheit untergebracht. Pro<br />
Laufwerk wurden Kapazitäten von 1,26 GB (JModelle) und<br />
3,78 GB (KModelle) abgebildet. Dies bedeutete für einen<br />
voll ausgebauten 4pfadigen Strang von JModellen eine<br />
Gesamt kapazität von 20,16 GB und bei den KModellen<br />
wurden bis zu 60,5 GB Gesamtkapazität erreicht.<br />
Die Platten wurden im 14ZollFormat gebaut. Um die gewichtigen<br />
Plattenstapel aus den Gehäuseeinheiten zu heben, wurden<br />
vom technischen Außendienst speziell dafür gebaute<br />
Hubwagen eingesetzt.<br />
Im 3880/3380 Subsystem wurde aus Pfadredundanzgründen<br />
die Funktion ‘Dynamic Path Reconnect’ eingeführt, die im<br />
Falle eines Pfadfehlers dafür sorgte, dass die Datenübertragung<br />
zu jedem HDA des Subsystems auf einem alternativen<br />
Pfad erfolgen konnte. Diese Multipfadarchitektur in Verbindung<br />
mit dem neuen Kanalsubsystem des Mainframes sorgte für<br />
einen um 30 % höheren Durchsatz im Speichersubsystem.<br />
Physikalische Spezifikation der 3380 Plattensubsysteme:<br />
Modelle A/B D E CJ2 J K<br />
Actuators per Unit 4 4 4 2 4 4<br />
Zylinder per Device 885 885 1770 885 885 2655<br />
Tracks per Device 13275 13275 26550 13275 13275 39825<br />
GB per Unit (Box) 2.520 2.520 5.041 1.260 2.520 7.562<br />
Auf der Magnetbandsubsystemseite führte <strong>IBM</strong> 1983 das<br />
letzte Rollenbandsystem mit der <strong>IBM</strong> 3430 ein, das vor allem<br />
bei <strong>IBM</strong> 43xx und <strong>IBM</strong> 303x SeriesProzessoren, aber auch<br />
bei dem damaligen Midrange <strong>System</strong>/38 seinen Einsatz fand.<br />
Die kompakte Bauweise erlaubte den Benutzern die Aufstellung<br />
auf wesentlich kleinerer Fläche im Vergleich zur <strong>IBM</strong> 3420.<br />
Die Rollenbänder wurden von oben horizontal eingelegt wie<br />
bei <strong>IBM</strong> 3410 (1971).<br />
Aufgrund der ein Jahr später angekündigten neuen <strong>IBM</strong> 3480<br />
Kassettentechnik als Ablösung der Rollenbänder fanden 3430<br />
Einheiten nicht in großen Stückzahlen ihren Absatz, hiel ten sich<br />
aber dennoch ziemlich lange auf dem Markt, um der Datenträgeraustauschanforderung<br />
gerecht zu werden, die in den<br />
Folgejahren immer noch auf Rollenbändern gemacht wurde.<br />
<strong>IBM</strong> 3430 Magnetbandsubsystem, letztes Rollenband der <strong>IBM</strong>,<br />
Markteinführung 1983<br />
1984:<br />
Die erreichte Dynamik in der Leistung von 3880/3380 Plattensubsystemen<br />
und /370 Rechnern erforderte auch eine<br />
Leistungsanpassung auf der BackupSeite, den Magnetbandsystemen.<br />
Mit der <strong>IBM</strong> 3480 wurde der Wechsel von den bis<br />
dahin verwendeten Rollenbandsystemen auf die Kassettentechnik<br />
eingeleitet. Das neue Magnetbandsystem <strong>IBM</strong> 3480<br />
übertrug, gleich schnell wie die Plattenspeicher <strong>IBM</strong> 3380, mit<br />
3 MB pro Sekunde und schloss damit die Lücke im Gesamtsystemverhalten.<br />
Die bis dahin verwendeten 10,5ZollRollenbänder<br />
der 3420 Technologie wurden durch handtellergroße,<br />
rechteckige Kassetten abgelöst. Bei einer Aufzeichnungsdichte<br />
von 38.000 Bytes pro Zoll nahmen die neuen Kassetten<br />
doppelt so viel Daten auf wie herkömmliche Bandrollen,<br />
also bis zu 200 MB. Mit einem Zusatz, einem Vorratsschacht<br />
(Stacker), konnten mehrere Kassetten hintereinander automatisch<br />
vorgeladen werden. Das erleichterte maßgeblich das<br />
Sichern großer Datenbestände.<br />
<strong>IBM</strong> 3480 Magnetbandsystem<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
1984: Wechsel vom klassischen Rollenband auf die 3480 Kassettentechnologie<br />
1989:<br />
Mit der <strong>IBM</strong> 3390 Plattentechnologie wurde der bei <strong>IBM</strong> 3380<br />
verwendete Formfaktor von 14 Zoll auf 10,8 Zoll reduziert.<br />
Anfangs wurde die 3390 Technologie noch mit der herkömmlichen<br />
‘braunen Beschichtung’ produziert, wo Eisenoxyd<br />
Partikel (Rostpartikel), die möglichst homogen in einer Kunstharzmasse<br />
zur gleichmäßigen Magnetisierung verteilt waren,<br />
als Magnetisierungsträger eingesetzt wurden. Die Einführung<br />
einer neuen Beschichtung, deren Entwicklung 1989 eingeleitet<br />
wurde und die 1991 zur Anwendung kam, ließ den Einsatz<br />
einer neuen Schreib/Lesetechnik zu. Die neuen Köpfe<br />
schrieben – wie ihre Vorgänger – induktiv, erzeugten also<br />
Magnetfelder in der Beschichtung der Platten mithilfe eines<br />
winzigen Spalts im Metallkern miniaturisierter Elektromagnete.<br />
Bis zu diesem Zeitpunkt dienten die Elektromagnete auch<br />
zum Lesen. Für die Zahl der Spulenwindungen musste man<br />
Größenvergleich Magnetbandsysteme <strong>IBM</strong> 3420 gegenüber <strong>IBM</strong> 3480<br />
einen Kompromiss für Lesen und Schreiben finden, um beide<br />
Vorgänge zu ermöglichen. Jetzt konnten sie ausschließlich<br />
für den Schreibvorgang optimiert werden, denn das Lesen<br />
erfolgt bei der 3390 Technologie über eine zweite Komponente,<br />
einen Lesefilm. Der Film war sehr klein und bestand<br />
aus dünnen Schichten verschiedener Metalle wie Eisen, Chrom<br />
und Kobalt. Kurze Zeit später wurde der Film auf Nickel und<br />
Eisen umgestellt. Wenn sich innerhalb der Spur auf der Platte<br />
die Magnetisierungsrichtung umkehrte, änderte sich der<br />
elektrische Widerstand vor allem in der mittleren Schicht des<br />
darüber befindlichen Kopfes sprunghaft. Dies bezeichnet man<br />
als magnetoresistiven Effekt, den man als Signal entsprechend<br />
verstärkt und auswertet. Diese neue Technik gewährleistete<br />
sicheres Lesen bei höchster Aufzeichnungsdichte, weil selbst<br />
kleinste Streufelder von Informationseinheiten differenziert<br />
werden konnten. Man führte – einfach gesagt – zwei Spezialisten<br />
ein, einen für das Schreiben optimierten induktiven Kopf<br />
und einen Spezialisten für den Lesevorgang (ausführliche<br />
Beschreibung im TechnologieAnhang). Beide Spezialisten<br />
zusammen bildeten das Schreib/Leseelement, das vom<br />
Zugriffsmechanismus positioniert wurde.<br />
Die neue Schreib/LesekopfTechnik der <strong>IBM</strong> 3390 benötigte<br />
eine neue Beschichtung in sogenannter Dünnfilmtechnik.<br />
Dabei beschichtete man die Oberflächen von Glasplatten aus<br />
einem speziell gehärteten Glas mit einer Legierung und unterzog<br />
sie anschließend einem Einbrennprozess. Die magnet o<br />
resistive Schreib/Lesetechnik in Verbindung mit Dünnfilmbeschichtungen<br />
auf den Platten kam innerhalb der 3390<br />
Baureihe mit den Modellen 3 und 9 erstmals zum Einsatz. Die<br />
seit der Einführung von Magnetplatten verwendet Aluminiumplatte,<br />
die mit feinst gemahlenem, weichmagnetischem<br />
Material in einem Kunstharz als Bindemittel beschichtet war,<br />
hatte damit ausgedient.<br />
Im Vergleich zur <strong>IBM</strong> 3380 Baureihe lieferte die 3390 Baureihe<br />
eine Verbesserung in der Zugriffszeit von 28 % und die<br />
Datentransferrate wurde um 40 % gesteigert, weil anstelle von<br />
3 MB/s mit 4,5 MB/s übertragen werden konnte. So konnten<br />
die Kanalgeschwindigkeiten des damals neuen 3090 Rechners<br />
genutzt werden. Ebenso konnte vom Rechner auf die<br />
Subsysteme über vier gleichzeitige Pfade übertragen werden<br />
(Four Path Data Transfer). Die 3390 Platten und auch noch<br />
die 3380 Platten wurden an der neuen <strong>IBM</strong> 3990 Steuereinheit<br />
angeschlossen, die mit höheren Plattenpuffergrößen<br />
(Cache) von 16 bis 64 MB (3990 Modelle 3) ausgestattet war.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
31
1975 bis 1993<br />
Die Epoche der fest eingebauten Platten mit externen Kontrolleinheiten<br />
1989: <strong>IBM</strong> 3390-1/2, 1991: <strong>IBM</strong> 3390-3, 1994: <strong>IBM</strong> 3390-9, hinten <strong>IBM</strong> 3380-K Strang mit 60 GB Kapazität, vorne 3390-3 Strang mit 90 GB Kapazität, rechts <strong>IBM</strong><br />
3990 Steuereinheiten<br />
Ein voll ausgebauter 3390 Modell 3 Strang mit 1 x A38 und<br />
2 x B3C hatte also eine Gesamtkapazität von 90 GB. Das<br />
Großkapazitätsmodell 9, das 1994 auf den Markt kam, verdreifachte<br />
nochmals die Kapazität. Allerdings kamen die<br />
Modelle 9 nur begrenzt zum Einsatz, weil die Platten aufgrund<br />
ihrer hohen Kapazität langsamer waren, und wurden für<br />
Anwendungen eingesetzt, wo die Zugriffszeiten und Datenraten<br />
ausreichten.<br />
Physikalische Spezifikation der 3390 Plattensubsysteme<br />
Modelle Kapazität/ Kapazität/ Anzahl Kapazität/<br />
Actuator HDA HDAs Unit<br />
A14 0.946 1.89 2 3.78<br />
A18 0.946 1.89 4 7.56<br />
B14 0.946 1.89 2 3.78<br />
B18 0.946 1.89 4 7.56<br />
B1C 0.946 1.89 6 11.35<br />
A24 1.89 3.78 2 7.56<br />
A28 1.89 3.78 4 15.1<br />
B24 1.89 3.78 2 7.56<br />
B28 1.89 3.78 4 15.1<br />
B2C 1.89 3.78 6 22.7<br />
A34 2.838 5.67 2 11.34<br />
A38 2.838 5.67 4 22.68<br />
B34 2.838 5.67 2 11.34<br />
B38 2.838 5.67 4 22.68<br />
B3C 2.838 5.67 6 34.02<br />
1991:<br />
In diesem Jahr wurde von <strong>IBM</strong> der erste Schritt in Richtung<br />
kleinerer Formfaktoren von Magnetplattenlaufwerken in<br />
Subsystemen eingeleitet. Die angebotenen Plattensysteme<br />
<strong>IBM</strong> 9340 und <strong>IBM</strong> 0662, erstmals auf der Basis von Plattendurchmessern<br />
mit 5,25 bzw. 3,5 Zoll, bestanden aus einem<br />
Rahmen, in den die Steuereinheit zusammen mit mehreren<br />
Plattenlaufwerken eingebaut wurden. Ein Standardrahmen<br />
Typ 9309 nahm bis zu acht Platteneinschübe vom Typ <strong>IBM</strong><br />
9345 auf. Ein Platteneinschub enthielt zwei Laufwerke mit<br />
jeweils 1 oder 1,5 GB Speicherkapazität. Es waren 5¼Zoll<br />
Laufwerke neuster Technologie mit einer Datenrate von<br />
4,4 MB/s, mittlerer Umdrehungswartezeit von nur 5,6 ms<br />
und in bewährter CountKeyData(CKD)Speicherungsform.<br />
Für Anforderungen bis 24 GB gab es den Steuereinschub<br />
<strong>IBM</strong> 9341, der als 2PfadSubsystem ohne Cache an die<br />
ProzessorenReihe 9221 oder 9370 angeschlossen war.<br />
Größerer Speicherbedarf und noch höhere Anforderungen<br />
wurden mit dem Standardrahmen <strong>IBM</strong> 9343 mit eingebauter<br />
Steuereinheit mit 4pfadigem Funktionsumfang und mit 9345<br />
Einschüben abgedeckt. Die Kapazität konnte stufenweise auf<br />
48 GB ausgebaut werden. Die <strong>IBM</strong> 9341/9343 erlaubten das<br />
unterbrechungsfreie Hinzufügen von Platteneinschüben. Hohe<br />
Leistung ohne Cache wurde im Speziellen bei Datenbankanwendungen<br />
mit hohem Randomzugriff erzielt. Erhebliche<br />
Steigerungen bei entsprechenden Anwendungen wurden<br />
später durch einen modellabhängigen 32MB bis 64MB<br />
Cache möglich.<br />
32 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang Software Anhang
1989/1991:<br />
Parallel zur 3390 Plattenentwicklungsreihe wurde 1989 auf<br />
der TapeSeite der Nachfolger des 3480 Bandsystems,<br />
die <strong>IBM</strong> 3490, verfügbar und 2 Jahre später die erweiterte<br />
Version in Form der <strong>IBM</strong> 3490E. Bei der 3490 Laufwerktechnologie<br />
wurde mit 18 Spuren, bei der 3490E Technologie mit<br />
36 Spuren gearbeitet.<br />
Die 3490 Technologie verwendete zur Steuerung des Bandsubsystems<br />
erstmals sehr leistungsstarke Kontrolleinheiten<br />
mit einem dynamischen Pufferspeicher von 2 bzw. 8 MB.<br />
Ebenso wurde bei der Aufzeichnung mit einem neuen Kom<br />
<strong>IBM</strong> 3490 Magnetbandsystem<br />
primierungsverfahren gearbeitet, dem IDRC (Improved Data<br />
Recording Capability), das Komprimierungsfaktoren von bis<br />
zu 3 :1 zuließ. Die neuen 3490 <strong>System</strong>e konnten mit ESCON<br />
Kanälen angesteuert werden, wie es bei den 3390 Platten<br />
der Fall war. Damit war der Grundstein für ESCON gelegt,<br />
das im Laufe der nächsten Jahre die bis dahin verwendete<br />
BMPX(Block Multiplex)Verkabelung ablösen sollte.<br />
Die erreichte Aufzeichnungsdichte lag bei <strong>IBM</strong> 3490 bei<br />
38.000 BPI mit Kassettenkapazitäten von 600 bzw. 1.200 MB,<br />
bei 3490E wurden durch die doppelte Spurzahl 78.000 BPI<br />
erreicht mit Kassettenkapazitäten von 1.200 und 2.400 MB.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang Software Anhang 33
34<br />
1975 bis 1993<br />
Die Epoche der fest eingebauten Platten mit externen Kontrolleinheiten<br />
<strong>IBM</strong> 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<br />
Meter, 4 bis maximal 64 Laufwerke <strong>IBM</strong> 3490<br />
1992: <strong>IBM</strong> kündigte nach einigen Jahren der Kooperation im<br />
Bandarchivbereich mit den Firmen Grau und Haushahn ein<br />
eigenes automatisches Magnetbandarchiv <strong>IBM</strong> 3495 für<br />
große Prozessoren an, die unter dem Betriebssystem MVS<br />
unterstützt waren. Bei einer Kassettenkapazität <strong>IBM</strong> 3490 von<br />
2,4 GB konnten die Benutzer die LibraryKapazitäten von<br />
13,5 TB auf 45,5 TB ausbauen.<br />
Zum Vergleich: Der Massenspeicher von 1974 erlaubte<br />
maximal etwa 0,24 TB.<br />
Das damals verwendete Robotersystem der 3495 war tonnenschwer<br />
und wurde vom Markt bis auf wenige Kunden<br />
nicht sonderlich akzeptiert. Oft wurde an die <strong>IBM</strong> die Frage<br />
gerichtet, warum ein tonnenschwerer Roboter notwendig sei,<br />
um eine kleine 3490 Kassette zu transportieren.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
1993: Etwa eineinhalb Jahre später kam dann das automatische<br />
Magnetbandarchiv <strong>IBM</strong> 3494 in wesentlich kompakterer<br />
Bauweise und mit einem adäquaten Robotersystem,<br />
das neben der MVSPlattform auch AS/400 und<br />
RISC6000<strong>System</strong>e unterstützte.<br />
Das 3494 Librarysystem wurde in den Folgejahren funktional<br />
erweitert und ist bis heute noch ein aktives Librarysystem, das<br />
vor allem im MainframeUmfeld eingesetzt wird. Es war auch<br />
die erste <strong>IBM</strong> TapeLibrary, die den Mischbetrieb von 3490<br />
und 3490E Laufwerken und Kassetten ermöglichte und auch<br />
den Nachfolger der 3490, die <strong>IBM</strong> 3590 Laufwerktechnologie,<br />
unterstützte. Mit 3590 Laufwerken, die als Nachfolger der<br />
3490E im Jahr 1995 verfügbar wurden, konnten mit dem<br />
ersten Modell B Kanaldatenraten von 9 MB/s realisiert werden.<br />
Die 3494 war zudem eine Library, die gleichzeitig den<br />
Mainframe und Open <strong>System</strong>s bedienen konnte und kann.<br />
Später wurden die Modelle E und H der 3590 unterstützt.<br />
Der Library Manager der 3494 wurde kontinuierlich weiter<br />
entwickelt und den VirtualTapeServer<strong>System</strong>en VTS mit<br />
ihren weiterentwickelten Funktionalitäten, die mit der Library<br />
bis heute betrieben werden können, angepasst. Mit der Verfügbarkeit<br />
der ersten Jaguar3592Laufwerke im September<br />
2003 (siehe Epoche Multiplattformsysteme und SAN) entwickelte<br />
<strong>IBM</strong> eine intelligente Integration dieser kleinen Laufwerke<br />
in die 3494 Library. In der exakten Größe eines<br />
Magstar3590Laufwerks wurden Gehäuseeinheiten, sogenannte<br />
‘Cradles’ gebaut, wo zwei JaguarLaufwerke im vorderen<br />
Teil untergebracht werden können. Nach hinten sind<br />
die Cradles offen. Dort sind zwei Netzteile untergebracht.<br />
Die beiden JaguarLaufwerke sind an beide Netzteile angeschlossen,<br />
um die Stromversorgung über zwei unabhängige<br />
Quellen sicher zustellen. Die <strong>IBM</strong> 3494 wird im Jahr 2010<br />
noch in einigen Rechenzentren aktiv betrieben. <strong>IBM</strong> publizierte<br />
im Jahr 2005 das ‘SOD’ (Statement of Direction),<br />
zukünftige JaguarLaufwerkstechnologien weiterhin zu unterstützen.<br />
So kann auch noch das neue HighendLaufwerk<br />
TS1130 in die Library eingebaut werden. Im Herbst 2009<br />
erfolgt die Zurückziehung von Marketing. <strong>IBM</strong> plant, die<br />
Library 3494 bis Ende 2015 in der <strong>IBM</strong> Wartung zu halten.<br />
1993 <strong>IBM</strong> 3494 <strong>IBM</strong> 3494 Gehäuseeinheit D22 mit ‘Cradles’ und TS1120(Jaguar)-Laufwerken<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 35
36<br />
1975 bis 1993<br />
Die Epoche der fest eingebauten Platten mit externen Kontrolleinheiten<br />
Kommentar zur Epoche der fest eingebauten Platten<br />
mit externen Kontrolleinheiten<br />
Die Anforderungen bezüglich Hochverfügbarkeit wurden<br />
immer höher. Deshalb ging man von den Wechselplatten auf<br />
fest eingebaute Platten über. Fest eingebaute Platten waren<br />
um ein Vielfaches zuverlässiger. Neben der Verfügbarkeit<br />
wurden auch die Ansprüche an Investitionsschutz immer<br />
höher. Um dem Rechnung zu tragen, etablierte die <strong>IBM</strong> über<br />
die gesamte Epoche das Prinzip des Wechsels für Steuereinheiten<br />
und Plattenspeicher. Dies sah so aus, dass neue<br />
Platteneinheiten an die vorhandenen Steuereinheiten angeschlossen<br />
werden konnten, dann kam eine neue, leistungsstärkere<br />
Steuereinheit, an der die alten Platten betrieben<br />
wurden. Dann wurden wieder neue Platten verfügbar, die an<br />
die vorhandene Steuereinheit angeschlossen werden konnten,<br />
danach kam wieder eine neue Steuereinheit. Dieses Wechselprinzip<br />
wurde vom Markt so positiv angenommen, dass es<br />
bis in die Folgeepoche der RAID<strong>System</strong>e gepflegt wurde.<br />
Auf der SteuereinheitenSeite wurden mit der <strong>IBM</strong> 3880 erstmals<br />
Cache und entsprechende CachingAlgorithmen eingeführt,<br />
um mit der Leistungsentwicklung der Rechnersysteme<br />
Schritt zu halten. Die wichtigste Funktion war hier das ‘DASD<br />
Fast Write’. Dies wurde auch mit der neuen 3990 Steuereinheit<br />
weitergepflegt und ausgebaut. Eine Funktion nach der<br />
anderen kam hinzu. Die funktionalen Erweiterungen setzten<br />
sich kontinuierlich bis zum letzten Modell der externen Steuereinheiten,<br />
der 3990 Modell 6, bis Mitte der 90erJahre fort.<br />
Anfang der 90erJahre wurde die ‘Braune’PlattenProduktion<br />
umgestellt und DünnfilmBeschichtungen wurden eingeführt.<br />
Dies führte zu wesentlich höherer Zuverlässigkeit, weil mit<br />
GrainStrukturen gearbeitet werden konnte und Eisenoxydpartikel<br />
(Rost) als Datenträger wegfielen. Die neu entwickelte<br />
Magnetoresistive Kopftechnik (MRKopftechnik) kam zum<br />
Einsatz (siehe auch TechnologieAnhang).<br />
Im TapeBereich kam 1984 der große technologische Wechsel.<br />
Das Rollenband wurde durch eine kleine Kassette mit der<br />
3480 Bandtechnik ersetzt. Dies war vor allem notwendig,<br />
um den Bandbereich in der Leistung den Platten und dem<br />
Gesamtsystem anzugleichen.<br />
Anfang der 90erJahre kamen dann die ersten automatisierten<br />
Bandarchive mit den Produkten <strong>IBM</strong> 3495 und <strong>IBM</strong> 3494 mit<br />
Roboter und Greifersystemen, die die Bandkassetten transportieren<br />
konnten.<br />
Insgesamt war die sehr lange anhaltende Epoche der fest<br />
eingebauten Platten mit externen Steuereinheiten eine Epoche,<br />
die durch konstante Weiterentwicklungen im Hinblick auf<br />
Datensicherheit und Investitionsschutz geprägt war und sicherstellte,<br />
dass die Speicher mit den neu entwickelten Rechnersystemen<br />
Schritt hielten. Oberstes Gebot war neben Datensicherheit<br />
die Gesamtleistung des Verbundes von Rechnern<br />
und Speichersystemen.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Die Epoche der RAID-<strong>System</strong>e<br />
1994 bis 1998<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
37
38<br />
1994 bis 1998<br />
Die Epoche der RAID-<strong>System</strong>e<br />
Plattensysteme mit RAID-Architekturen<br />
<strong>IBM</strong> bot 1994 ein völlig neues Konzept externer Magnetplattensysteme<br />
unter dem erstmals seit 1956 wieder benutzten,<br />
eingetragenen Warenzeichen ‘RAMAC’ an. Dieses Mal stand<br />
die BuchstabenReihenfolge RAMAC für ‘RAID Architecture<br />
with Multilevel Adaptive Cache’.<br />
Was war der Hintergrund und was bedeutete dies konkret?<br />
1. Die Verarbeitungsgeschwindigkeit vergleichbarer Prozessoren<br />
war zwischen 1964 und 1994 ungefähr 400-mal<br />
schneller gewachsen als die Übertragungsrate der Zugriffsmechanismen<br />
der Plattenspeicher und etwa 30-mal schnel ler<br />
als die Übertragungsgeschwindigkeit der gängigen Kanäle.<br />
Am schnellsten wuchs die Kapazität pro Zugriffsmechanismus<br />
– ungefähr um den Faktor 6.000 – und damit doppelt<br />
so schnell wie die Verarbeitungsgeschwindigkeit der Prozessoren.<br />
Die Ansprüche an die Datenverfügbarkeit in<br />
internationalen und firmeninternen Netzen nahmen ständig<br />
zu und weil technisches Versagen von Komponenten nie<br />
ganz ausgeschlossen werden konnte, wuchs die Forderung<br />
nach fehlertoleranten <strong>System</strong>en.<br />
2. Parallel zur Entwicklung immer leistungsfähigerer Magnetplattenspeicher<br />
für große und mittlere <strong>System</strong>e hatte die<br />
Industrie – <strong>IBM</strong> eingeschlossen – für den schnell wachsenden<br />
Markt der Einzelplatzrechner (PC, Laptop, Notebook)<br />
in den Abmessungen kleine, aber auf hohem technischem<br />
Niveau stehende, leistungsfähige und zuverlässige<br />
Platten laufwerke auf den Markt gebracht. Damals war<br />
abzusehen, dass die Kapazitäten dieser Laufwerke rasant<br />
steigen würden. Es kam noch hinzu, dass diese kleinen<br />
Plattenlaufwerke aufgrund hoher Maßenproduktion<br />
wesentlich kosten günstiger gefertigt werden konnten als<br />
die großen Plattenfiles, die zu diesem Zeitpunkt bereits als<br />
SLEDs (Single Large Expensive Disks) bezeichnet wurden.<br />
3. Bereits 1987 schilderte die Universität Berkeley in Kalifornien<br />
(die Studie erfolgte im Auftrag der <strong>IBM</strong>) in einem Dokument<br />
mit dem Titel „Eine Studie über redundante Anforderungen<br />
kostengünstiger Plattenspeicher“ (A Case for Redundant<br />
Arrays of Inexpensive Disks), wie man die betreffenden<br />
Plattenlaufwerke zu einem aus Sicht der Betriebssysteme<br />
einzigen adressierbaren Datenträger zusammenschalten<br />
konnte, um sie für größere <strong>System</strong>e zu nutzen und dabei<br />
entweder höhere Übertragungsraten oder höhere Datenverfügbarkeit<br />
oder beides zu erreichen. In diesem Papier<br />
wurden 5 RAID-Stufen (RAID-Levels) definiert, die sich in<br />
der Abwägung zwischen Übertragungsleistung und dem<br />
Grad der Fehlertoleranz unterschieden.<br />
RAID1 beschreibt die doppelte Speicherung von Daten auf<br />
zwei Platten mit völlig identischem Inhalt (Spiegelung, Mirroring).<br />
Fällt ein Laufwerk aus, greift das <strong>System</strong> auf das<br />
andere zu.<br />
Bei RAID2 werden die Daten byteweise auf mehrere Platten<br />
kopiert (Mehrfachspiegelung). Auf einer weiteren Platte wird<br />
ein Fehlercode gespeichert, mit dessen Hilfe verlorene Daten<br />
rekonstruiert werden.<br />
Bei RAID3 werden die einzelnen Bytes ebenfalls auf mehre<br />
ren Platten – allerdings abwechselnd – gespeichert und auf<br />
einer separaten Platte sogenannte Paritätsbits. Fällt eine<br />
Platte aus, lässt sich deren Inhalt über den der intakt gebliebenen<br />
Platten und die Paritätsbits wiederherstellen.<br />
RAID4 unterscheidet sich von RAID3 dadurch, dass die<br />
Daten statt in einzelne Bytes in ganze Blöcke von mehreren<br />
Kilobytes unterteilt werden.<br />
Bei RAID5 erzeugt das <strong>System</strong> Paritätsbits für Blöcke von<br />
mehreren Kilobytes, die auf alle Platten so verteilt sind, dass<br />
sie immer auf einer anderen Platte stehen als die Daten, aus<br />
denen sie erzeugt wurden. Das Verfahren bietet hohe Sicherheit<br />
bei relativ schnellem Zugriff, weil durch die Verteilung<br />
parallele SchreibUpdates möglich sind. Deswegen erfuhr<br />
dieser RAIDLevel die stärkste Verbreitung.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Der Vollständigkeit halber seien noch später hinzugefügte<br />
RAIDStufen erwähnt:<br />
RAID6 bietet gegenüber RAID5 zusätzliche Paritätsbits<br />
(zwei ParitySchemen) und damit noch mehr Sicherheit (bis<br />
zu zwei Platten können innerhalb eines Arrays ausfallen),<br />
allerdings auf Kosten der Leistungsfähigkeit eines Arrays.<br />
RAID7 protokolliert dazu noch sämtliche Schreibzugriffe.<br />
RAID0 verteilt die Daten in kleinen Paketen auf mehrere Platten<br />
und ermöglicht schnellen Zugriff, mangels Redundanz<br />
jedoch keine erhöhte Sicherheit. Schließlich gibt es noch<br />
RAID10, auch als Stufe 1 + 0 bezeichnet. Sie arbeitet wie<br />
RAID0, jedoch mit zwei gleich großen Sätzen von Platten,<br />
wobei die zweite Gruppe das exakte Spiegelbild des Inhalts<br />
der ersten Gruppe enthält. Diese Lösung erfordert viele<br />
Laufwerke.<br />
Inzwischen haben sich (bis heute, im Jahr 2010) aus diesen<br />
BasisRAIDStufen gänzlich neue RAIDLevels entwickelt, die<br />
jenseits der StandardLevels liegen, teilweise unsinnig sind,<br />
aber in manchen Fällen auch eine Optimierung der Basis<br />
Levels darstellen (wie z. B. RAID 1E, 1E0, 1.5, Matrix RAID,<br />
RAID15, 51, 53, 45, RAID5E, 5EE und RAID5DG/RAID ADG).<br />
4. Bereits 1992 konstituierte sich ein RAID-Beratergremium<br />
(RAID Advisory Board) aus 40 Anwender- und Herstellerfirmen,<br />
zu denen auch <strong>IBM</strong> zählte. Damit wurde RAID in den<br />
90er -Jahren zu einer Art Industriestandard. Die Originalbezeichnung<br />
RAID wurde in der Bedeutung geringfügig<br />
korrigiert: Aus ‘kostengünstigen Einheiten’ (Redundant<br />
Array of Inexpensive Disks) wurden ‘unabhängige Einheiten’<br />
(Redundant Array of Independent Disks).<br />
Bereits seit 1978 besitzt <strong>IBM</strong> ein Patent über die Wiederherstellung<br />
von Daten, die auf einer ausgefallenen Einheit aus<br />
einer Gruppe von Laufwerken gespeichert wurden. Wie die<br />
gesamte Industrie bemühte sich <strong>IBM</strong>, den Herausforderungen,<br />
die sich aus den oben dargestellten Punkten ergab, wirksam<br />
zu begegnen. Die zunehmenden Veränderungen im Markt<br />
mit seiner ständig wachsenden Zahl von Anbietern, immer<br />
mehr etablierten Hardware und Softwareplattformen, dynamischen<br />
Innovationen und den damit immer kürzer werdenden<br />
Produktzyklen machten es notwendig, die <strong>IBM</strong> Geschäftspolitik<br />
maßgeblich zu verändern und anzupassen. Bisher hatte<br />
<strong>IBM</strong> fast ausschließlich für den eigenen Bedarf zum Vertrieb<br />
über die eigene Organisation an Endbenutzer produziert und<br />
war nur vereinzelt als Unterlieferant anderer Hersteller<br />
aufge treten (BranchenFachausdruck für solche Geschäfte ist<br />
OEM, Original Equipment Manufacturer). Ein Beispiel waren<br />
in den 80er und 90erJahren geschlossene Verträge über<br />
Lieferungen von leicht modifizierten <strong>IBM</strong> Plattenspeichern an<br />
Siemens. <strong>IBM</strong> ließ immer Fremdprodukte aller Art innerhalb<br />
ihrer Konfigurationen und Softwareplattformen zu, ohne in<br />
den Umgebungen anderer Hersteller als Anbieter aufzutreten.<br />
Auf die bei den DVBenutzern um sich greifende Vernetzung<br />
von Datenverarbeitungsprodukten und DVPlattformen verschiedener<br />
Hersteller – heterogene Client/Serverumgebungen<br />
– reagierte <strong>IBM</strong> mit Angeboten, bei denen alle für die jeweiligen<br />
Produkte relevanten eigenen und fremden Schnittstellen<br />
unterstützt wurden. Das <strong>Storage</strong>Geschäft wurde durch das<br />
Anwerben von entsprechenden Geschäftspartnern neben<br />
dem eigentlich blauen Vertrieb zusätzlich vorangetrieben.<br />
Man arbeitete mit immer mehr Geschäftspartnern, die sich<br />
in ihrer Vertriebsorganisation erfolgreich um den Absatz von<br />
<strong>IBM</strong> Hardeware und Softwareprodukten bemühten. Dieser<br />
Trend hat sich bis heute noch maßgeblich verstärkt.<br />
Wie bereits eingangs dieses Kapitels beschrieben, machte<br />
<strong>IBM</strong> 1994 als erste Firma das auf RAID5 basierende Magnetplattensystem<br />
verfügbar, der damaligen RAMAC 1 (<strong>IBM</strong><br />
9391). RAMAC 1 wurde im Juni 1994 angekündigt und war<br />
ab September 1994 verfügbar. Als Basis für eine RAMAC<br />
Speichereinheit diente ein Einschub <strong>IBM</strong> 9392 (Drawer),<br />
der mit mehreren anderen Einschüben in einen Rahmen<br />
integriert wurde. Jeder dieser Einschübe beinhaltete vier<br />
Plattenlaufwerke auf 3,5ZollBasis mit jeweils 2 GB Kapazität<br />
(AllicatLaufwerke), zwei Netzteile, zwei Kühlgebläse, einen<br />
RISCMikroprozessor als Controller, einen batteriegestützten<br />
Pufferspeicher (Non Volatile) und einen Akku. Jeder Einschub<br />
stellte ein für sich geschlossenes RAID5<strong>System</strong> dar. Bis zu<br />
16 dieser RAID5Einschübe konnten in den Rahmen integriert<br />
werden. RAMAC kam in zwei Ausführungen. Das RAMAC<br />
Array beinhaltete nur die RAID5Einschübe und wurde an<br />
die damalige, leistungsstarke Steuereinheit 3990 angeschlossen.<br />
Das RAMAC Subsystem beinhaltete die übergeordnete<br />
Controllerfunktion in demselben Gehäuse, in dem auch die<br />
Einschübe integriert waren, und war seitlich im Rahmen<br />
eingebaut. In der vollen Ausbaustufe lieferten beide<br />
<strong>System</strong>e eine nutzbare Plattenkapazität, RAID5gesichert,<br />
von 90 GB aus.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
39
40<br />
1994 bis 1998<br />
Die Epoche der RAID-<strong>System</strong>e<br />
RAMAC 2 und RAMAC 3 folgten wegen der raschen Fort<br />
schritte in den kapazitiven Möglichkeiten der 3,5ZollLaufwerke<br />
im Abstand von nur einem Jahr. Bei RAMAC 2 kamen<br />
die UltrastarXPLaufwerke und bei RAMAC 3 die Ultrastar<br />
2XPLaufwerke zum Einsatz. Die rechnerische Kapazität verdoppelte<br />
sich jeweils per Subsystem.<br />
RAMAC 2 bot mit 16 Einschüben eine nutzbare Kapazität<br />
von 180 GB und RAMAC 3 von 360 GB.<br />
Mit RAMAC 3 in der Version des RAMAC Arrays zum Anschluss<br />
an 3990 Steuereinheiten wurde zeitgleich ein neues<br />
Modell der Steuereinheit eingeführt, der 3990 Modell 6. Diese<br />
Steuereinheit war eine Doppelsteuereinheit, die in ein Gehäuse<br />
integriert war und an der zwei RAMAC 3 Arrays betrieben<br />
werden konnten. Damit lieferten zwei RAMAC 3 Arrays an der<br />
39906 als ‘Doppelsubsystem’ eine Gesamtkapazität von bis<br />
zu nutzbaren 720 GB aus.<br />
Die RAID5RAMACBaureihe war auf dem Markt sehr erfolgreich,<br />
konnte aber über die Jahre nicht fortgesetzt werden,<br />
weil der Kostenfaktor in der Produktion dem Preisverfall der<br />
Gigabytes in den angebotenen Subsystemen nicht standhalten<br />
konnte. Jeder Einschub als eigenständiges <strong>System</strong> und<br />
bis zu 16 Einschübe unter einer eigenen Steuereinheit, dadurch<br />
zwei CacheEbenen: das war sehr aufwendig zu produzieren.<br />
links: <strong>IBM</strong> RAMAC Subsystem mit integrierter Steuereinheit<br />
rechts: <strong>IBM</strong> RAMAC Array zum Anschluss an 3990 Steuereinheiten<br />
Dies war einer der Hauptgründe, warum 1996 eine Kooperation<br />
mit der Firma <strong>Storage</strong>Tek bezüglich des Vertriebs<br />
und der Weiterentwicklung des verfügbaren ‘Iceberg’Plattensystems<br />
geschlossen wurde und die <strong>IBM</strong> zwei Plattensubsysteme<br />
der Firma STK in den Vertrieb nahm. Der ‘Iceberg’<br />
wurde von <strong>IBM</strong> unter dem Namen <strong>IBM</strong> RVA (RAMAC<br />
Virtual Array) vermarktet, das Großkapazitätssystem von<br />
STK als <strong>IBM</strong> RSA (RAMAC Scalable Array). Das RAMAC<br />
Virtual Array wurde im Juli 1996 mit sofortiger Verfügbarkeit<br />
angekündigt. Das leistungsstärkere RVA in der Turboversion<br />
wurde knapp ein Jahr später, im April 1997, verfügbar.<br />
Das RAMAC Virtual Array <strong>IBM</strong> RVA <strong>IBM</strong> 9393 erfüllte die Be<br />
dingungen von RAID6 und bot eine sehr intelligente Lösung<br />
für das Anlegen und das Wachstum von Dateien. Normaler<br />
weise mussten Benutzer bisher für wachsende Dateien genügend<br />
Platz reservieren. Das bedeutete, einen ständigen<br />
Vorrat von leeren Spuren (Allocated Tracks) bzw. nicht genutzte<br />
Kapazität vorzuhalten. Wenn das <strong>System</strong> beim Ausführen<br />
eines Programms für eine wachsende Datei keine Kapazität<br />
mehr vorfand, führte das zum anomalen Abbruch der Operation.<br />
Beim RVA suchte das <strong>System</strong> automatisch freien Platz.<br />
Reservierung (Allocation) war nicht mehr erforderlich und<br />
Abbrüche wegen fehlenden Speicherplatzes ausgeschlossen.<br />
Dieser spezielle Algorithmus wurde als logisch strukturierter<br />
FileAlgorithmus (Log Structured File) bezeichnet.<br />
1996 –1998 <strong>IBM</strong> RAMAC Virtual Array RVA, <strong>IBM</strong> RAMAC Virtual Array 1996,<br />
<strong>IBM</strong> RAMAC Virtual Array Turbo 1997, <strong>IBM</strong> RAMAC Virtual Array Turbo 2 1998,<br />
Kapazitäten von 840 GB bis 1.680 GB Arrays 13+2+1 RAID6 oder 2 x (5+2+1),<br />
Array Kapazität bis 420 GB, Minimalkonfiguration: 2 Arrays, Maximalkonfiguration:<br />
4 Arrays<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Waren Spuren auf den Platten wegzuschreiben, suchte sich<br />
die Kontrolleinheit den Platz auf beliebigen Platten in den<br />
verfügbaren Arrays. Die veralteten Spuren wurden in einem<br />
SpaceReclamationProzess wieder einfach zum Überschreiben<br />
freigegeben. Das Ganze wurde über Pointertabellen verwaltet<br />
und die Pointer einer aktuellen geänderten Datei wurden<br />
einfach entsprechend angepasst. Diese neue LogStructured<br />
FileArchitektur als wirklich erste virtuelle Plattenarchitektur<br />
auf dem Markt erlaubte auch das sekundenschnelle Kopieren<br />
von einzelnen Dateien oder Volumes, ohne dass für die Kopie<br />
zusätzlicher Platz vorgehalten werden musste. Nur die Veränderungen<br />
in Form von neuen Spuren oder SpurUpdates<br />
benötigten wieder neuen Platz. Dabei legte das <strong>System</strong> entsprechende<br />
KopierPointers an, die auf einzelner Spurbasis<br />
mit den originalen Pointers übereinstimmten. Diese Funktion<br />
wurde als ‘SnapShot’ bezeichnet. Durch dieses Prinzip konnte<br />
die RVA von der Plattenbelegung im Vergleich zu herkömmlichen<br />
Plattensystemen wesentlich höher genutzt werden. Beim<br />
RAMAC Virtual Array wurden im Backend <strong>IBM</strong> SSAPlatten<br />
eingesetzt und das <strong>System</strong> konnte mit 4,5GB, 9GB und<br />
später mit 18GBSSAPlatten konfiguriert werden.<br />
Das zweite Produkt aus der <strong>Storage</strong>TekReihe, die <strong>IBM</strong> RSA<br />
(RAMAC Skalierbares Array) entsprach den herkömmlichen<br />
Subsystemarchitekturen, konnte aber bereits 1996 in relativ<br />
kleinen skalierbaren Schritten auf 1,4 TB ausgebaut werden.<br />
Das <strong>System</strong> wurde aber relativ kurzfristig kapazitiv von der<br />
RVA in der Turbo und Turbo2Version überholt und zeigte<br />
nur eine sehr geringe Marktdurchdringung.<br />
Plattensysteme für Open <strong>System</strong>s<br />
Während sich <strong>IBM</strong> in den 90erJahren bei der Magnetplatten<br />
Subsystementwicklung im Mainframebereich vornehmlich auf<br />
die RAMACReihe konzentrierte, liefen parallel neue Architekturentwicklungen<br />
für Plattensubsysteme im Open<strong>System</strong>s<br />
Bereich. Bis Ende der 90erJahre gab es kein Plattensystem,<br />
das Server aus dem Open<strong>System</strong>sBereich (AIX und andere<br />
UNIXDerivate und die IntelPlattformen) und den Mainframe<br />
mit seinem MVSBetriebssystem gleichzeitig bedienen konnte.<br />
Auf der Open<strong>System</strong>sSeite ging <strong>IBM</strong> andere Wege. Beginnend<br />
in den 90erJahren wurde im <strong>IBM</strong> Labor in Hursley in<br />
England eine neue, Open<strong>System</strong>sgerechte Plattenarchitektur<br />
entwickelt, die unter dem Namen SSA für viele Jahre zur<br />
Anwendung kommen sollte. SSA stand für Serial <strong>Storage</strong><br />
Architecture, eine Architektur, die die Limitierungen der bisher<br />
an Open<strong>System</strong>sServer angeschlossene SCSIPlatten<br />
<strong>IBM</strong> 7133 Plattensubsystem, SSA-Architektur mit SCSI-Host-Anschlüssen,<br />
Modell T40 ‘Deskside’ Entry, Modell D40 ‘Rackmountable Disk <strong>System</strong>’<br />
Plattenart Kapazitäten von/bis<br />
18,2 GB 72,8 – 291,2 GB<br />
36,4 GB 145,6 – 582,4 GB<br />
72,8 GB 291,2 GB – 1,16 TB<br />
146,8 GB 587,2 GB – 2,34 TB<br />
systeme (Small Computer <strong>System</strong>s Interface) eliminierte. Bei<br />
SSA wurde für die Anbindung von Plattenlaufwerken mit einer<br />
LoopTechnik gearbeitet, die es zuließ, dass man in die Loop<br />
über neu entwickelte Adapter gleichzeitig zwei Schreib und<br />
zwei LeseI/Os absetzen konnte und alle Laufwerke in der<br />
Loop gleichberechtigt bedient wurden. Die bekannte Arbitrierung,<br />
wie es bei SCSIbasierenden Laufwerksträngen der<br />
Fall war, fiel weg. Bei einem SCSILaufwerkstrang musste<br />
immer ein I/O fertig abgehandelt werden, bevor der nächste<br />
starten konnte. Zudem wurden Laufwerke, die ganz am Ende<br />
des SCSIStrangs angeschlossen waren, in der Bedienung<br />
benachteiligt. Ein SCSIStrang hatte die Limitierung, dass<br />
maximal 15 Laufwerke angeschlossen werden konnten. Diese<br />
Limitierungen überwand die neue SSAArchitektur, die 1992<br />
erstmals in Subsystemen zum Einsatz kam.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
41
42<br />
1994 bis 1998<br />
Die Epoche der RAID-<strong>System</strong>e<br />
Das bekannteste <strong>System</strong> war das <strong>IBM</strong> 7133 Serial <strong>Storage</strong><br />
Architecture Disk Subsystem, das an RISC <strong>System</strong>e/6000,<br />
Power Servers und Power Stations angeschlossen werden<br />
konnte und immer mit den neusten 3 ½ZollLaufwerken ausgestattet<br />
war. Das <strong>IBM</strong> 7133 Subsystem wurde im Juli 1995<br />
mit sofortiger Verfügbarkeit angekündigt. Es war eines der<br />
erfolgreichsten Plattensysteme im AIXUmfeld und wurde<br />
direkt über den AIXVerkaufskanal vertrieben. Während des<br />
Lebenszyklus der 7133 wurden über 42.000 Plattensysteme<br />
weltweit in Produktion genommen, ein einzigartiger Verkaufserfolg.<br />
Die letzten <strong>System</strong>e in SSAArchitektur (<strong>IBM</strong> 7133 Modelle T40<br />
und D40) blieben bis 2003 im aktiven <strong>IBM</strong> Vertrieb und konn<br />
ten damals über Gateways an bestehende FibreChannel<br />
Infrastrukturen (SANs, <strong>Storage</strong> Area Networks) angeschlos sen<br />
werden.<br />
1999 kündigte die <strong>IBM</strong> für den Mainframe wieder ein eigenes,<br />
selbst entwickeltes Plattensubsystem unter dem Namen <strong>IBM</strong><br />
ESS (Enterprise <strong>Storage</strong> Server) an, das allerdings mehr<br />
unter dem Entwicklungsnamen ‘Shark’ bekannt wurde und<br />
letztendlich die RVA und RSA im <strong>IBM</strong> Vertrieb ablöste. <strong>Storage</strong>Tek<br />
vertrieb danach wieder selbst die RVA unter dem<br />
Namen STK Shared Virtual Array. Die ESS war nicht nur ein<br />
Plattensystem für den Mainframe, sondern konnte auch an<br />
alle gängigen Open<strong>System</strong>sPlattformen angeschlossen<br />
werden. Damit war die Voraussetzung geschaffen, mit einem<br />
Plattensubsystem sowohl den Mainframe als auch Open<br />
<strong>System</strong>sServer zu bedienen, wie es auf der Bandarchivseite<br />
bereits seit Jahren möglich war. Über die Folgejahre löste<br />
die ESS dann auch im Open<strong>System</strong>sBereich teilweise<br />
das <strong>IBM</strong> 7133 Serial Disk <strong>System</strong> ab. Parallel dazu wurden<br />
FibreChannelbasierende Plattensysteme für die Open<br />
<strong>System</strong>sPlattformen eingeführt.<br />
Bandsysteme<br />
Neben der Plattensubsystementwicklung in den 90erJahren<br />
führte <strong>IBM</strong> eine neue Bandlaufwerktechnologie als Ablösung<br />
der bis dahin verwendeten 3490 Technologie ein, die<br />
<strong>IBM</strong> 3590, die unter dem Namen Magstar bekannt wurde.<br />
Das erste Laufwerk der Magstar 3590 war das Modell B, das<br />
auf einer ½ZollKassette eine native Kapazität von 10 GB<br />
aufzeichnete. Das 3590B Laufwerk wurde im April 1995 angekündigt<br />
und war im September des gleichen Jahres verfügbar.<br />
Bei dieser neuen Aufzeichnung wurden zum ersten<br />
Blick in die <strong>IBM</strong> 3590 Magstar Laufwerke<br />
Mal in der Bandtechnologie magnetoresistive Schreib/Leseköpfe<br />
mit dem ‘Track Following Servo’Prinzip eingesetzt, wo<br />
die Leseelemente konstant kontrollieren, wie gut die Bits vom<br />
Schreibkopf geschrieben wurden. Die Kassetten wurden mit<br />
128 Spuren vollgeschrieben und die Datenrate des Modells<br />
B der 3590 betrug damals faszinierende 9 MB pro Sekunde<br />
(native).<br />
Die Laufwerke waren als StandaloneVersion, also fest eingebaut<br />
in einem Gehäuse mit entsprechenden Autoloadern,<br />
zu bekommen, sie wurden aber genauso in der aktuellen Tape<br />
Library <strong>IBM</strong> 3494 eingesetzt. Voll ausgebaut konnte die <strong>IBM</strong><br />
3494 mit 3590B Laufwerken eine Kapazität von 180 TB<br />
(native) abbilden. Die Laufwerke selbst hatten zwei SCSI<br />
Schnittstellen und konnten entweder direkt an Open<strong>System</strong>s<br />
Server angeschlossen werden oder über eine Kontrolleinheit<br />
an ESCONbasierende MainframeServer.<br />
Die MagstarEntwicklungsreihe wurde dann 1999 mit dem<br />
neuen E-Modell erweitert, das mit 256 Spuren die doppelte<br />
Spurzahl aufwies und eine Kapazität von 20 GB auf den Kas<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
<strong>IBM</strong> 3590 Magstar Tape Subsystem<br />
1995: <strong>IBM</strong> 3590-B mit 9 MB/S Datenrate<br />
1999: <strong>IBM</strong> 3590-E mit 14 MB/S Datenrate<br />
2002: <strong>IBM</strong> 3590-H mit 14 MB/S Datenrate<br />
Kassettenkapazitäten (native):<br />
Modell normale Kassette lange Kassette<br />
3590-B 10 GB 20 GB<br />
3590-E 20 GB 40 GB<br />
3590-H 30 GB 60 GB<br />
setten speicherte (native ohne Komprimierung). Die Datenrate<br />
wurde von 9 MB/s auf 14 MB/s gesteigert. Parallel dazu<br />
brachte <strong>IBM</strong> eine neue Kassette, die 3590 ‘Extended Length<br />
Cartridge’, die mit der doppelten Bandlänge (beschrieben<br />
mit 3590E) auch die doppelte Kapazität, nämlich 40 GB,<br />
abbildete. Damit erhöhten sich die 3494 LibraryKapazitäten<br />
auf 374 TB bei Verwendung der normalen Kassette und bis<br />
748 TB bei der langen Kassette. Die MagstarEntwicklungsreihe<br />
war ab Mai 1999 verfügbar.<br />
Das Modell E der MagstarBaureihe besaß einen leistungs<br />
fähigen Controller, der neben der Aufzeichnung von Datenblöcken<br />
auch Parity-Blöcke aufzeichnete, um ein wesentlich<br />
höheres Error Recovery zu ermöglichen. (Bei der Aufzeichnung<br />
von 16 Spuren gleichzeitig wurde nach 7 Datenblöcken<br />
in der achten und nach weiteren 7 Datenblöcken in der<br />
16. Spur ein ParityBlock mitgeschrieben und über das<br />
logische Spurset von acht Spuren ‘gestriped’ – RAID5<br />
auf Band.)<br />
Was Magstar in Sachen Recovery zu leisten vermag, zeigt<br />
ein Versuch mit dem Magstar EModell, der im Juni 1999<br />
und im Juli 2000 im <strong>IBM</strong> Labor in Tucson, Arizona, durchgeführt<br />
wurde. Zu dem Versuch wurden alle maßgeblichen<br />
Consultants wie Gartner Group und IDC eingeladen. Man<br />
hat mit dem EModell eine Kassette mit 256 Spuren voll<br />
beschrieben und ein sauberes Read Verify erhalten. Dann<br />
wurde die Kassette aus dem Laufwerk entladen. In die Mitte<br />
des Bandes wurde dann ein 1,25 mm großes Loch gestanzt.<br />
Dieses Loch spiegelte ca.100.000 Bits wieder, die dann fehlten.<br />
Die Kassette mit dem Loch wurde wieder ins Laufwerk<br />
geladen und die Leseoperation wurde erfolgreich ohne Fehler<br />
durchgeführt. Alle fehlenden Datenbits konnten durch den<br />
ECC (Error Correction Code) über die BitblockVerteilung<br />
und die ParityBitBlöcke ‘recovered’ werden. Das war zu<br />
dieser Zeit mit Sicherheit mit keiner anderen Bandlaufwerkstechnologie<br />
durchführbar!<br />
Das Laufwerk hatte zwei SCSISchnittstellen. Ab Mai 2000<br />
waren die MagstarLaufwerke auch mit zwei FibreChannel<br />
Schnittstellen verfügbar. Damit konnten die Laufwerke direkt<br />
an ein FibreChannelbasierendes SANNetzwerk angeschlossen<br />
werden. Etwas zeitversetzt kamen auch die entsprechenden<br />
Controller auf den Markt, welche den Anschluss der<br />
Laufwerke auch an FICONbasierende MainframeRechner<br />
ermöglichten.<br />
Lochstanzversuch mit Magstar 3590 Bändern 1999 und 2000 im <strong>IBM</strong> Labor in<br />
Tucson<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
43
44<br />
1994 bis 1998<br />
Die Epoche der RAID-<strong>System</strong>e<br />
Das letzte Modell der 3590 MagstarReihe kam im Jahr 2002<br />
mit dem 3590 Modell H, das auf denselben Kassetten 384<br />
Spuren aufzeichnete und so die Kassettenkapazitäten um<br />
50 % steigerte. Das Modell H wurde am 25. Juni 2002 angekündigt<br />
und war bereits am 28. Juni 2002 verfügbar. Die<br />
Datenrate der 3590H blieb auf dem Stand des Vorgängers<br />
3590E, bei 14 MB pro Sekunde. Die 3494 LibraryKassettenkapazitäten<br />
erreichten jetzt 1 Petabyte native Kapazität in<br />
der vollen Ausbaustufe (ohne Kompression).<br />
Im September 1996 wurde von <strong>IBM</strong> ein neues Kassetten-<br />
bandsystem vorgestellt, das neben hoher Streaminggeschwindigkeit<br />
extrem schnelle Zugriffszeiten realisierte. Die<br />
<strong>IBM</strong> Magstar MP 3570 bot eine Datentransferrate von 15 MB<br />
pro Sekunde und Zugriffszeiten von nur wenigen Sekunden.<br />
Dies wurde mit einem besonderen Kassettendesign ermöglicht,<br />
wo die Grundstellung des Bandes in einem ZweiSpulen<br />
Design in der Mittenstellung lag. So konnte beim Laden des<br />
Bandes sowohl nach links als auch nach rechts gespult werden,<br />
um schnell an eine File zu gelangen. Diese neue Konzeption<br />
allerdings ermöglichte nur kleine Kassettenkapazitäten<br />
von 5 MB und später 10 MB, die vom Markt nicht in der breiten<br />
Akzeptanz angenommen wurde, wie man es ursprünglich gedacht<br />
hatte. Deshalb war der Lebenszyklus der Magstar MP<br />
auch nur von kurzer Dauer und auf etwa 3 Jahre beschränkt.<br />
Mit der Verfügbarkeit der ersten MagstarModelle 3590-B 1995<br />
ergab sich im MainframeUmfeld eine neue Problemstellung,<br />
denn die jetzt hohen Kassettenkapazitäten von 10 GB native<br />
und die hohen Datenraten von 9 MB/s native wurden nur zu<br />
einem kleinen Teil genutzt. Eine weltweite Studie ergab, dass<br />
der Nutzgrad im MainframeUmfeld bei etwa 200300 MB pro<br />
Kassette lag und die Datenraten bei durchschnittlich 23 MB/s<br />
lagen und bei vielen BackupJobs sogar unter 1 MB/s. Um<br />
<strong>IBM</strong> Magstar MP 3570 Bandsubsystem<br />
dieses Problem zu beheben, fing <strong>IBM</strong> an, Tape-Virtualisierungslösungen<br />
für den MainframeBereich zu entwickeln, um<br />
die dahinter angeschlossene physikalische Ressource sowohl<br />
in der Kapazität der Kassetten als auch in der Datenrate von<br />
Laufwerken maximal nutzen zu können. Aus einer anfänglichen<br />
Softwarebasierenden VolumeStackingLösung entstand der<br />
3494 Virtual Tape Server VTS, der im Juni 1997 mit dem<br />
ersten Modell B16 auf den Markt kam. Dabei wurden die<br />
Tape Volumes, die es zu sichern galt, auf einem Plattenpuffer<br />
zwischengespeichert und dabei indexiert. Sobald so viele<br />
Volumes in den Plattenpuffer geschrieben waren, dass sie<br />
eine 3590 Kassette füllen konnten, wurde eine Kopie der<br />
gesamten Ansammlung von Platten auf die schnellen Laufwerke<br />
geschrieben (Premigration) und dabei die Kassetten<br />
maximal aufgefüllt (Stacked Volume Prinzip). Das Original<br />
verblieb im Plattenpuffer. Dadurch konnte der Nutzgrad der<br />
Kassettenkapazitäten und der Laufwerkgeschwindigkeiten<br />
maximiert werden. Recalls von Volumes, die noch im Plattenpuffer<br />
standen, wurden in Plattengeschwindigkeit durchgeführt<br />
und beim Backup konnten viele Jobs parallel angestoßen<br />
werden, da viele virtuelle Laufwerke zur Verfügung standen.<br />
<strong>IBM</strong> implementierte eine sogenannte ‘Outboard’Lösung, die<br />
völlig transparent zum Host und dem MVSBetriebssystem<br />
war und dieselbe Transparenz gegenüber dem Bandverwaltungssystem<br />
und dem Katalogeintrag zeigte. Emuliert wurden<br />
3490E Laufwerke mit Kassettenkapazitäten von 400 bzw.<br />
800 MB und der Host registrierte gar nicht, dass er keine<br />
physischen Laufwerke im Zugriff hatte.<br />
Der erste Virtual Tape Server <strong>IBM</strong> 3494 B16 war damals direkt<br />
als Gehäuseeinheit in das 3494 Bandarchiv integriert. Das<br />
B16Gehäuse beherbergte den RS/6000 Server, einen RAID<br />
5abgesicherten Plattencache mit SSAPlatten, der bis auf<br />
72 GB ausgebaut werden konnte, sowie die für den Host notwendigen<br />
ESCONAnschlüsse und 400 Kassettenstellplätze.<br />
Später arbeitete man mit externen Einheiten, wie die Weiterentwicklung<br />
dieses Konzepts zeigt. Virtuelle TapeLösungen<br />
sind in unserer heutigen Zeit nicht mehr wegzudenken, weil<br />
es die einzige Möglichkeit ist, über diesen Weg Tape und<br />
TapeLibraryRessourcen maximal zu nutzen.<br />
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<br />
Bandarchiv zu integrieren, erwies sich als äußerst ungünstig.<br />
Zudem war die Durchsatzstärke der damaligen B16 sehr<br />
klein und erreichte nur 68 MB/s, weil ohne Kompression<br />
gearbeitet wurde. Deshalb kündigte die <strong>IBM</strong> bereits ein Jahr<br />
später, im Juni 1998, mit einer Verfügbarkeit im August 1998,<br />
ein neues externes Modell B18 an, das als separate Einheit<br />
neben der 3494 Library betrieben werden konnte. Diese neue<br />
Einheit bot Kompression an, die direkt in den HostAdaptern,<br />
damals auf ESCONBasis, durchgeführt wurde. Das hatte den<br />
Vorteil, dass alle Daten im Plattenpuffer bereits komprimiert<br />
waren und der Nutzgrad im Plattenpuffer durchschnittlich<br />
um Faktor 3 vergrößert wurde. Durch den Einsatz von SSA<br />
Laufwerken mit 9 und 18 GB Kapazität wurde die Plattenpuffergröße<br />
auf 288 GB und 576 GB gesteigert. Später wurden<br />
mit 36GBSSAFiles Plattenpuffer von bis zu 5,2 TB (nutzbar)<br />
möglich. Dadurch wurde die Verweilzeit der Volumes im<br />
Plattenpuffer um ein Vielfaches vergrößert und Recalls direkt<br />
vom Plattenpuffer als virtuelle Mounts in Plattengeschwindigkeit<br />
durchgeführt. Die damaligen B18Einheiten erreichten, je<br />
nach Ausbaustufe, Durchsatzmöglichkeiten von 30 bis 40 MB/s.<br />
Viele andere Firmen sprangen sehr schnell auf diesen Geschäftszug<br />
auf und es wurde eine ganze Reihe von Bandvirtualisierungslösungen,<br />
HWbasierend, aber auch reine<br />
SWStackingLösungen auf dem Markt verfügbar. Viele verschwanden<br />
aber wieder sehr schnell vom Markt.<br />
Das Modell B18 wurde in den Folgejahren funktional erweitert.<br />
Import/ExportMöglichkeiten von logischen Volumes waren<br />
möglich. Mit der Einführung von Folgemodellen im August<br />
2001, der Modelle B10 und B20, wurden neben den ESCON<br />
Anschlüssen auch FICONAnschlüsse verfügbar und eine<br />
große Palette von neuen Funktionen kam zum Einsatz, die<br />
<strong>IBM</strong> Virtual Tape Server VTS, 1997: Modell B16, 1998: Modell B18,<br />
2001: Modell B10 und B20<br />
auch noch für das alte Modell B18 in eingeschränkter Form<br />
zur Verfügung stand.<br />
Diese neuen Erweiterungen, als ‘Advanced Function’ bezeich<br />
net, erlaubten über ein APM (Advanced Policy Manage-<br />
ment) neue Funktionalitäten am <strong>IBM</strong> VTS. Sie sind bis heute<br />
aktiv im Einsatz und bilden die Verzahnung mit SMS<br />
(<strong>System</strong> Managed <strong>Storage</strong>) als integralem Bestandteil des<br />
z/OSBetriebssystems.<br />
Die Funktionalität ‘Logical Volume Pool Assignment’ bietet<br />
die Möglichkeit, logische Volumes einzeln pro Nummernkreis<br />
in unterschiedlichen physischen KassettenPools zu verwalten.<br />
Damit wurde der <strong>IBM</strong> VTS mandantenfähig. Mit ‘Selective<br />
Dual Copy’ können zwei Kopien eines logischen Volumes in<br />
zwei unterschiedlichen physischen Kassettenpools erzeugt<br />
werden. Die Funktion ‘Peer to Peer Copy Control’ adressiert<br />
einen PtPVTSKomplex und erlaubt die Steuerung, welche<br />
logischen Volumes in einem PtPKomplex im Immediate Copy<br />
Mode und welche logischen Volumes im Deferred Copy Mode<br />
gespiegelt werden.<br />
Mit ‘Tape Volume Cache Management’ (diese Funktion war<br />
bereits vorher verfügbar, allerdings Hostgesteuert) können<br />
logische Volumes einer Cache Management Preference Group<br />
zugeordnet werden. Es stehen zwei Preference Groups zur<br />
Verfügung. Die Preference Group steuert, wie die logischen<br />
Volumes im Plattenpuffer behandelt werden.<br />
Die wohl wichtigste Einführung im August 2000 war aber das<br />
Prinzip der Spiegelung von ganzen VTS-<strong>System</strong>en, die<br />
auch heute noch als Peer to Peer VTS bezeichnet wird und<br />
sich im Markt, vor allem bei Banken und Versicherungskunden,<br />
schnell durchsetzte. Dabei bietet ein PeertoPeerVTSKomplex<br />
synchrone Spiegelmöglichkeit und eine asynchrone<br />
Spiegelung an. Über eine weitere Funktion, die 2004 eingeführt<br />
wurde (Selective Peer to Peer Copy), können auch<br />
einzelne Volumes oder ganze <strong>Storage</strong>Gruppen sowohl<br />
gespiegelt als auch ungespiegelt in einem VTSPeerto<br />
PeerSpiegelkomplex verwaltet werden.<br />
Die VTSGeschichte, die 1997 begann, war für die <strong>IBM</strong> vor<br />
allem im MainframeUmfeld eine einzigartige Erfolgsgeschichte<br />
und <strong>IBM</strong> entschloss sich, diese Erfolgsgeschichte mit neuen<br />
<strong>System</strong>en und neuen Funktionalitäten über die folgenden<br />
Jahre fortzusetzen.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
45
46<br />
1994 bis 1998<br />
Die Epoche der RAID-<strong>System</strong>e<br />
Linear Tape Open LTO Ultrium<br />
In der ersten Hälfte der 90er-Jahre hatte sich im<br />
Open<strong>System</strong>sUmfeld vor allem im Mittelstandsbereich und<br />
bei kleineren Betrieben eine Tape-Technologie durchgesetzt,<br />
die diesen Markt beherrschte: DLT (Digital Linear Tape), eine<br />
günstige Alternative zur HighEnd½ZollTechnologie, die für<br />
kleine Unternehmen bezahlbar war und bis Mitte 1995 eine<br />
Marktdurchdringung von 90 % hatte. DLTHersteller und Anbieter<br />
war Quantum. Der kleinere Teil des Marktes ging an<br />
HelicalScanbasierende Technologien und die QIC(Quarter<br />
Inch Cartridge) und MiniQICTechnologien.<br />
Mit dem Zusammenschluss der Firmen <strong>IBM</strong>, HP und Sea-<br />
gate in einem neuen TapeEntwicklungsgremium, dem<br />
sogenannten LTO(Linear Tape Open)Gremium, wurde eine<br />
Initiative gestartet, dem dominierenden umd marktbeherrschenden<br />
DLT von Quantum eine Alternative entgegenzusetzen.<br />
Das LTOEntwicklungsgremium fing 1996 mit seiner<br />
Arbeit an.<br />
Die Spezifikationen von LTO wurden von 1997 bis 1999 ent<br />
wickelt, um als erster Bandtechnologie-Standard auf den<br />
Markt zu kommen und den damals herrschenden Wildwuchs<br />
an unterschiedlichen Technologien und Medien zu stoppen.<br />
LTO ist sowohl von der Technologie als auch vom Medium<br />
ein offizieller ISOStandard, der es erlaubt, LTOMedien, unabhängig<br />
von welchem Hersteller, auf jedem LTOLaufwerk,<br />
auch unabhängig von welchem Hersteller, zu verarbeiten.<br />
Heute haben über 30 Firmen die Fertigungslizenzen von LTO<br />
erworben. Hinzu kommen zusätzlich die OEMAbkommen, die<br />
die Entwicklungsfirmen <strong>IBM</strong>, HP und Seagate eingegangen<br />
waren. LTO hatte also eine große Chance, sich langfristig<br />
gegenüber DLT auf dem Markt durchzusetzen.<br />
LTO1 Laufwerk mit LTO1 Ultrium Kassette<br />
Wenn man heute, 2010, die Marktanteile betrachtet, ging<br />
diese Rechnung auf. DLT ist heute nahezu vom Markt verschwunden.<br />
Als die LTO Group 1997 anfing, die Spezifikationen für die<br />
Standardisierung zu entwickeln, hatte sie zuerst alle vorhandenen<br />
Bandtechnologien auf ihre Plus und MinusPunkte<br />
bewertet, um das Gute in LTO miteinzuarbeiten und das<br />
Negative auszulassen. Schluss mit dem Wildwuchs, Kompatibilität<br />
war gefragt! Ob Sony AIT oder 4 mm, 8 mm Helical<br />
Scan Technologie von Exabyte, Quantums DLT bis hin zum<br />
Super DLT, Philipps NCTP, Quarter Inch Cartridge oder Mini<br />
Quarter Inch Cartridge: alles Technologien, die keine Kompatibilität<br />
vorwiesen und daher Schwierigkeiten hatten, sich<br />
weiter dauerhaft auf dem Markt zu behaupten!<br />
Bei der Aufzeichnungstechnik entschied man sich aufgrund<br />
der hohen Zuverlässigkeit für die <strong>IBM</strong> MagstarLineareSerpentinenAufzeichnung,<br />
mit der das Band bei einer Datenrate<br />
von 15 MB/s mit 384 Spuren (LTO1) und 35 MB/s mit<br />
512 Spuren (LTO2) beschrieben wird. Dabei wurden immer<br />
acht Spuren gleichzeitig geschrieben. Die Kassetten erreichten<br />
bei diesen Spurdichten native Kapazitäten von 100 GB (LTO1)<br />
und 200 GB (LTO2). Bei dieser hohen Spudichte war es notwendig,<br />
eine möglichst exakte Führung der Schreib/Lese<br />
Elemente sicherzustellen.<br />
Zu diesem Zweck wurde ein neues, zeitbasierendes Spur-<br />
nachführungssystem verwendet, das mit fünf vorgeschriebenen<br />
Servobändern mit jeweils acht Servobereichen arbeitete.<br />
Von der AIT(Advanced Intelligent Tape)Technik von<br />
Sony wurde das in der Kassette integrierte Memory Chip<br />
übernommen, allerdings mit größerer Speicherkapazität (4 KB).<br />
Kassettenladevorgang beim <strong>IBM</strong> LTO1 Laufwerk<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
<strong>IBM</strong> Autoloader und Library-Angebot mit LTO-Laufwerken, Ende 2000, links <strong>IBM</strong> 3584 Library, rechts unten <strong>IBM</strong> 3583 Library, darüber<br />
der Autolaoder <strong>IBM</strong> 3581 und das LTO Stand Alone Laufwerk <strong>IBM</strong> 3580<br />
Dort wird das festgehalten, was z. B. bei Magstar in der Tape<br />
VolumeControlRegion auf Band gespeichert wird: Hersteller<br />
angaben als ReadOnlyInformation, das Inhaltsverzeichnis<br />
des Bandes und Angaben wie viele Schreib/Lesefehler auf<br />
dem Band vorkommen, um aus Sicherheitsgründen bei einem<br />
bestimmten Schwellwert die Kassette auf ‘Read Only’Status<br />
zu setzen. Ebenso war Platz für anwenderspezifische Informationen<br />
vorgesehen. Neben der Speicherung auf dem Chip<br />
wurden aus Sicherheitsgründen alle Informationen auch in<br />
der TapeVolumeControlRegion des Bandes abgespeichert.<br />
Passend zur LTOLaufwerkentwicklung entwickelte <strong>IBM</strong> ein<br />
neues Library-Konzept, das mit einem Greifersystem arbeitet<br />
(bis heute), das die Features der standardisierten LTO<br />
Kassetten optimal handhaben konnte. Das Robotersystem<br />
mit diesem Spezialgreifer wurde Ende 2000 mit der neuen<br />
<strong>IBM</strong> 3584 Library realisiert. Die <strong>IBM</strong> 3584, zum damaligen<br />
Zeitpunkt auschließlich an Open <strong>System</strong>s betreibbar, stellte<br />
das passende Gegenstück zur <strong>IBM</strong> 3494 Library dar, allerdings<br />
mit wesentlich moderneren Möglichkeiten und einer<br />
Robotergeschwindigkeit, die bis heute unerreicht ist.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
47
48<br />
1994 bis 1998<br />
Die Epoche der RAID-<strong>System</strong>e<br />
Mit der Einführung der LTOBandtechnologie auf dem Markt<br />
änderte die <strong>IBM</strong> ihr bisher verfolgtes Konzept, alles selbst<br />
herzustellen. In dem damals bereits hart umkämpften Open<br />
<strong>System</strong>sMarkt als Einzelhersteller zu bestehen, der alle Arten<br />
von Lösungsformen abbildet und fertigungstechnisch baut,<br />
war unmöglich. Deshalb schloss <strong>IBM</strong> bereits 1999 mit der<br />
Firma ADIC ein OEMAbkommen, das so aussah, dass<br />
ADIC LTOLaufwerke von <strong>IBM</strong> bekam und im Gegenzug <strong>IBM</strong><br />
die kleinen Libraries von ADIC, die dann unter <strong>IBM</strong> Logo mit<br />
<strong>IBM</strong> LTOLaufwerken vermarktet wurden.<br />
So stellte ADIC die damaligen ‘Midrange Libraries’, die <strong>IBM</strong><br />
3583 und später die <strong>IBM</strong> 3582 (bei ADIC Skalar 100 und<br />
Skalar 24), zur Verfügung. Der einzige Unterschied zu den<br />
ADICProdukten war, dass <strong>IBM</strong> in beide Libraries eine eigene<br />
FibreChannelbasierende Steuereinheit integrierte, um den<br />
Libraries über die dadurch geschaffene Multipfad architektur<br />
die Möglichkeit zu geben, logische Partitionen als SubLibraries<br />
anzulegen und um direkt FibreChannelLTOLaufwerke<br />
einzubauen. ADIC verwendete SCSILaufwerke, die<br />
dann über ein Gateway an SANs anschließbar waren. FC<br />
Laufwerke wurden bei ADIC erst Anfang 2005 verwendet<br />
und eingebaut.<br />
Die heute aktuellen Autoloader, Midrange Libraries und die<br />
Besonderheiten des 3584 Bandarchivs sind in der Folgeepoche<br />
näher beschrieben.<br />
<strong>IBM</strong> 3582 Display – Mini-Library mit bis zu 23 LTO-Kassetten<br />
<strong>IBM</strong> 3583 Ultrium Scalable Tape Library mit geöffneter Tür<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Kommentar zur Epoche der RAID-<strong>System</strong>e<br />
Im Vergleich zur Vorgängerepoche, wo über Jahre dieselben<br />
Steuereinheiten und Platten aktuell blieben, war die Epoche<br />
der RAID<strong>System</strong>e mit sehr schnellen Entwicklungszyklen<br />
sehr hektisch. RAMAC 1, 2 und 3 kamen hintereinander im<br />
Abstand von nur einem Jahr.<br />
In dieser Epoche herrschte ein enormer Preisdruck, der durch<br />
neue Mitbewerber und Player im Plattenumfeld hervorgerufen<br />
wurde.<br />
RAMAC 3 war der letzte ‘Rolls Royce’, den die <strong>IBM</strong> baute,<br />
dann liefen die Kosten davon und die Produkte waren viel zu<br />
teuer im Vergleich zum Mitbewerb. Das führte zum Zusammenschluss<br />
von <strong>Storage</strong>Tek und <strong>IBM</strong> und zum <strong>IBM</strong> Vertrieb<br />
des RAMAC Virtual Arrays (ehemals STK Iceberg). Plötzlich<br />
musste der <strong>IBM</strong> Vertrieb ein Produkt verkaufen, von dem man<br />
sich bisher immer distanziert hatte. Ein massives Umdenken<br />
war im Speichervertrieb angesagt. Log Structured File, die<br />
bisher von <strong>IBM</strong> negativ kommentierte ‘Garbage Collection –<br />
das kann doch nichts sein’ musste nun positiv dargestellt<br />
werden. Die Verbrüderung mit STK im Plattenumfeld musste<br />
erst einmal verdaut werden.<br />
Im Open<strong>System</strong>sBereich glichen die erfolgreiche Einführung<br />
der SSAArchitektur und der erfolgreiche Verkauf des Plattensystems<br />
<strong>IBM</strong> 7133 den Einbruch im MainframeUmfeld<br />
entsprechend aus.<br />
Ebenso hektisch waren die Entwicklungsjahre im Tape<br />
Umfeld geprägt. Neben Magstar 3590, Magstar MP und der<br />
Entwicklung des Virtual Tape Servers (VTS) wurde die<br />
LTO(Linear Tape Open)Bandtechnologie zusammen mit<br />
HewlettPackard und Seagate entwickelt und spezifiziert. Im<br />
Herbst 1999 war der Standard der LTO1Technologie fertig.<br />
Danach begann ein PrestigeWettrennen zwischen <strong>IBM</strong>, HP<br />
und Seagate. Jeder wollte der Erste sein, der mit LTO1<br />
Laufwerken auf den Markt kommt.<br />
Seagate kündigte als erste Firma, bereits im Frühjahr 2000,<br />
ihre LTO1Laufwerke an. Die SeagateLaufwerke wurden aber<br />
dann doch als letzte verfügbar. <strong>IBM</strong> kündigte im September<br />
2000 mit sofortiger Verfügbarkeit an. HP folgte mit Ankündigung<br />
und Verfügbarkeit einen Monat später.<br />
Die Epoche war geprägt durch Vertriebskämpfe vieler Mitbewerber<br />
im Platten und TapeUmfeld und war deshalb so<br />
hektisch, weil enorme Preis und Prestigekämpfe stattfanden.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
49
50<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Die Epoche der Multiplattform-<strong>System</strong>e und<br />
des FibreChannel SAN und NAS<br />
1999 bis 2005<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
51
52<br />
1999 bis 2005<br />
Die Epoche der Multiplattform-<strong>System</strong>e und des FibreChannel SAN und NAS<br />
1999 – 2006: <strong>IBM</strong> SAN, Switches und Direktoren der Hersteller Brocade, McData (CNT) und Cisco<br />
SAN, NAS, iSCSI<br />
Die Epoche der RAID<strong>System</strong>e war bis 1999 so gestaltet, dass<br />
Plattensysteme für den MainframeBereich zur Verfügung<br />
standen, während der Open<strong>System</strong>sBereich eigene, damals<br />
direkt angeschlossene Plattensysteme verwendete. Nur Tape<br />
Libraries waren in der Lage, beide Welten zu unterstützen.<br />
Das Datenwachstum in dieser Zeit war dramatisch, oft über<br />
60 % pro Jahr für Rechenzentrumsbetriebe. Die IPNetze und<br />
die damit verbundene Infrastruktur, damals Ethernet auf<br />
10MbitBasis, erlaubten kaum, riesige Datenmengen über<br />
IPInfrastrukturen hin und her zu bewegen. Der Ruf nach<br />
separaten Speichernetzwerk-Infrastrukturen wurde immer<br />
lauter, um der Datenflut entgegenzuwirken. 1998 kamen<br />
von der Firma Brocade die ersten FibreChannelSwitches<br />
auf 8PortBasis mit 1GbitPorts auf den Markt. Eine neue<br />
Infrastruktur, das SAN (<strong>Storage</strong> Area Network) auf<br />
FibreChannelBasis, sollte in den kommenden Jahren eine<br />
wahre Blütezeit erleben.<br />
Die Anfänge der ersten SAN-Infrastrukturen fanden allerdings<br />
schon 2 Jahre früher statt. Sie kamen bereits 1996<br />
in Hochleistungsrechenzentren der Universitäten zum Einsatz<br />
und wurden von der Firma Ancor zur Verfügung gestellt.<br />
1998 wurde der erste 8PortSwitch von der Firma Brocade<br />
im kommerziellen Rechenzentrumsumfeld bei der IT Austria<br />
in Wien eingesetzt und in den Folgejahren gingen viele Firmen<br />
dazu über, in den unterschiedlichsten Unternehmensbereichen<br />
SANInfrastrukturen zu implementieren. Nicht nur im Open<br />
<strong>System</strong>sBereich erlebte die Glasfaser eine neue Blütezeit,<br />
auch die MainframeUmgebungen wechselten, beginnend<br />
mit dem Jahr 2001, von der bisherigen ESCONUmgebung<br />
(Enterprise <strong>Storage</strong> CONnection) mit den bis dahin verwendeten<br />
ESCONDirektoren auf Glasfasernetze, um zusammengefasste<br />
ESCONPakete über die Glasfaser zu übertragen.<br />
Das Ganze wird heute als FICON bezeichnet (Fibre CONnection).<br />
Dadurch konnten die hohen Übertragungsraten<br />
der MonomodeGlasfaser mit entsprechenden Multiplexingverfahren<br />
auch im MainframeBereich genutzt werden.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Bereits im Jahr 2003 waren Direktoren auf dem Markt, die<br />
sowohl FibreChannel als auch FICONPorts abbilden konnten.<br />
Leider kann bis heute noch kein FCPort als FICONPort<br />
oder umgekehrt genutzt werden und es wird sicherlich noch<br />
einige Zeit dauern, bis SANbasierende Infrastrukturen<br />
sowohl von der Open<strong>System</strong>sUmgebung als auch von den<br />
Mainframes gleichzeitig genutzt werden können. Die Fibre<br />
Channel SANs entwickelten sich rasch weiter. 2002 kamen<br />
die ersten Switches mit 2-Gbit-Ports auf den Markt. Im<br />
Jahr 2006 waren alle Hersteller im Begriff, von 2Gbit auf<br />
4GbitTechnologie umzustellen, und bis Ende 2006 war die<br />
Umstellung soweit, dass ‘End to End’SANImplementierungen<br />
auf 4GbitBasis realisiert werden konnten. Sowohl<br />
die HostAdapter aller ServerHersteller als auch die Host<br />
Ports aller <strong>Storage</strong>Anbieter waren auf 4GbitTechnologie<br />
umgestellt. Heute, im Jahr 2008, wiederholt sich dieses<br />
Spiel nur auf 8GbitTechnologieBasis. Seit Anfang 2008<br />
sind die ersten 8Gbitfähigen Direktoren auf den Markt<br />
gekommen.<br />
In der Anfangszeit dieser Epoche waren SAN-Implementie-<br />
rungen sehr kostenintensiv. Nicht jede Firma, vor allem im<br />
Mittelstandsbereich, konnte sich SANs finanziell leisten, um<br />
der neuen Bandbreitenmöglichkeit Rechnung zu tragen. Hinzu<br />
kam die Hochpreispolitik der Glasfaserhersteller, die vor allem<br />
die für das Multiplexing erforderliche MonomodeFaser über<br />
die Anfangsjahre sehr teuer gestaltete. Die ServerAdapter<br />
Hersteller schlossen sich dieser Hochpreispolitik an. Das<br />
führte dazu, dass die Entwickler von MultiplexingVerfahren<br />
auf der Glasfaser kein großes Umsatzpotenzial mehr erkennen<br />
konnten und sich deshalb neuen MultiplexingVerfahren<br />
auf EthernetBasis zuwandten. So kommt es, dass heute IP<br />
Infrastrukturen auf EthernetBasis wesentlich größere Übertragungsbandbreiten<br />
bieten (2Gbit und 10GbitEthernet)<br />
im Vergleich zu FibreChannelNetzen.<br />
Die Hochpreispolitik führte auch dazu, dass neben dem<br />
SAN eine neue Technologie, das NAS (Networking Attached<br />
<strong>Storage</strong>), Einzug hielt. NASTechnologie in Form von File<br />
ServerGeräten mit eingebauten Platten kam ebenso zum<br />
Einsatz wie Gateways, die prinzipiell nichts anderes als einen<br />
FileServer darstellten, aber die Möglichkeiten hatten, Plattenkapazitäten<br />
innerhalb eines SANs für FileServingZwecke<br />
zu nutzen.<br />
Heute sind SANs selbst für sehr kleine Betriebe bezahlbar.<br />
Der Preisverfall von 2003 bis 2006 liegt in einem Bereich von<br />
nahezu 96 %. Dieser Preisverfall wurde maßgeblich durch die<br />
neuen Bandbreitenmöglichkeiten der IPNetze auf Ethernet<br />
Basis erzielt und stellt durchaus, vor allem heute (10Gbit<br />
Ethernet), die Notwendigkeit von SANs infrage, wenn es um<br />
Engpässe in der Datenübertragungsmöglichkeit geht. Trotzdem,<br />
vor allem aufgrund der Managementmöglichkeiten, ist<br />
davon auszugehen, dass SANNetze von 4 Gbit in Richtung<br />
8 Gbit (oder 12 Gbit) weiterentwickelt werden, die zu den<br />
bestehenden Netzen (Autosensing) kompatibel bleiben.<br />
Neben den Möglichkeiten und Vorteilen von SANs bot <strong>IBM</strong><br />
in den Jahren 2000 bis 2004 auch Lösungen und Produkte<br />
auf dem Sektor Networking Attached <strong>Storage</strong> (NAS) an.<br />
NAS<strong>System</strong>e sind vorkonfigurierte Fileserver. Sie bestehen<br />
bis heute aus einem oder mehreren internen Servern mit vorkonfigurierter<br />
Plattenkapazität und werden über Ethernet an<br />
das LAN angeschlossen, wo sie ihren Plattenspeicher als<br />
Fileserver oder als HTTPServer zur Verfügung stellen. NAS<br />
Server sind speziell für das File Sharing entwickelt. Der Vorteil<br />
von NAS im Vergleich zu klassischen Fileservern bestand<br />
im geringen Installations und Wartungsaufwand.<br />
Die <strong>IBM</strong> NASModelle 200 und 300 waren Lösungen speziell<br />
für Kunden, die in einem WindowsUmfeld Speicher konsolidieren<br />
wollten. Alle <strong>IBM</strong> NAS Appliances wurden mit einem<br />
vorkonfigurierten MicrosoftWindowsBetriebssystem ausgeliefert.<br />
Dieses Windows wurde speziell für Fileserving angepasst.<br />
Routinen, die überflüssig waren, wurden aus dem<br />
Betriebssystem entfernt, um die Leistung und Zuverlässigkeit<br />
zu erhöhen. Dadurch boten die <strong>IBM</strong> NASModelle sehr<br />
gute Performance in einer WindowsUmgebung (CIFS). Auch<br />
in einem gemischten Windows und UNIX(NFS)Umfeld zeigten<br />
die <strong>IBM</strong> NASModelle eine gute Leistung.<br />
Für klassische BlockI/OAnwendungen wie Datenbanken<br />
waren solche Fileserver nicht vorgesehen, weil diese Anwendungen<br />
direkt auf einen formatierten Plattenplatz ohne ein<br />
darüberliegendes Filesystem zugreifen. Dafür waren Lösungen<br />
wie Direct Attached <strong>Storage</strong> (DAS), <strong>Storage</strong> Area Networks<br />
(SAN) und iSCSIProdukte besser geeignet.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
53
54<br />
1999 bis 2005<br />
Die Epoche der Multiplattform-<strong>System</strong>e und des FibreChannel SAN und NAS<br />
<strong>IBM</strong> NAS Gateway 500, verfügbar Februar 2004, pSeries-basierend,<br />
bis 224 TB Kapazität im SAN<br />
Um die Speicherressourcen im SAN für Fileserving zu nutzen,<br />
bot die <strong>IBM</strong>, damals am Anfang als einziger Vendor, die Möglichkeit,<br />
vorhandene IPNetzwerkstrukturen über ein NAS<br />
Gateway mit dem SAN zu verbinden. Das NAS Gateway war<br />
ein dedizierter Fileserver. Dieser war mit dem SAN über Fibre<br />
Channel verbunden und so in der Lage, Kapazitäten z. B.<br />
eines Enterprise <strong>Storage</strong> Servers ESS im SAN optimal für<br />
Fileserving einzusetzen. Durch die Nutzbarmachung eines<br />
SANSpeicherpools über Gateways konnten Fileserver in ein<br />
SAN konsolidiert werden. Ebenso wurde durch die Nutzung<br />
des Speichers im SAN eine Serverunabhängige Skalierung<br />
bezüglich der Kapazitäten möglich. Das NAS Gateway 300G<br />
wurde später, im Jahr 2004, durch das wesentlich leistungsstärkere<br />
Gateway 500 ersetzt.<br />
iSCSI ist eine gemeinsame Entwicklung der Firmen <strong>IBM</strong> und<br />
Cisco. Dabei wird das SCSIProtokoll über TCP/IP übertragen.<br />
iSCSI verfolgt damit einen ähnlichen Ansatz wie SAN, mit<br />
dem Unterschied, dass bei iSCSI eine TCP/IPVerbindung<br />
das SCSIKabel ersetzt, und stellte damals in Bereichen mit<br />
niedrigen oder mittleren Leistungsanforderungen eine kostengünstigere<br />
Alternative zu SANs dar. Der Vorteil bestand darin,<br />
dass bereits vorhandene IPNetzwerke direkt genutzt werden<br />
konnten und nicht ein separates Glasfasernetz in Form eines<br />
SANs aufgebaut werden musste. Die Implementierung von<br />
iSCSILösungen im Vergleich zu SANs war wesentlich einfacher<br />
und erforderte nicht den hohen ITSkill, der bei einem<br />
Aufbau eines <strong>Storage</strong> Area Network (SAN) notwendig war.<br />
Die <strong>IBM</strong> Modelle IP <strong>Storage</strong> 200i (Modelle 200 und 225)<br />
verwendeten im Gegensatz zu den NAS und NAS Gateways<br />
Linux als Betriebssystem (Kernel) und boten eine Kapazität<br />
von 108 GB bis 1,74 TB an.<br />
Die iSCSILösungen setzten sich allerdings auf dem Markt<br />
nicht wirklich durch, zumal kurze Zeit später der enorme<br />
Preisverfall der MonomodeGlasfaser einsetzte, der die Implementierung<br />
von SANs auch im Mittelstand und für Kleinbetriebe<br />
bezahlbar machte.<br />
Plattensysteme<br />
Im Juli 1999 wurde das erste <strong>IBM</strong> multiplattformfähige Plattensystem,<br />
der Enterprise <strong>Storage</strong> Server ESS, angekündigt.<br />
Unter dessen Entwicklungsname ‘Shark’ fand das <strong>System</strong><br />
allerdings weit mehr Verbreitung als unter dem Begriff ESS.<br />
Die Typenbezeichnung war 2105 und die 1999 angekündigten<br />
Modelle waren die E10 und E20 mit einer Kapazität von<br />
420 GB bis 11,2 TB. Dabei wurden Plattenlaufwerke von 9 GB,<br />
18 GB und 36 GB als SSAPlatten verwendet, die über vier<br />
sogenannte Device Adapter Pairs in SSALoopTechnik an<br />
den Rechner angebunden waren. Am Anfang konnten die<br />
Plattentypen nicht gemischt werden, später allerdings war es<br />
möglich, unterschiedliche Platten in die Arrays einzubauen.<br />
CacheGrößen von bis zu 6 GB waren konfigurierbar und<br />
ein Strom unabhängiger Schreibspeicher (NVS Non Volatile<br />
<strong>Storage</strong>) von 384 MB stand zur Verfügung. Die Arrays waren<br />
am Anfang ausschließlich unter RAID5 betreibbar. Für den<br />
Mainframe standen die 3380 und 3390Spurformate zur Verfügung,<br />
an Open <strong>System</strong>s (UNIX, Windows NT und AS/400)<br />
wurden entsprechende LUNs emuliert (Logical Unit Number).<br />
Vom Vorgänger der ESS, dem Versatile <strong>Storage</strong> Server, einem<br />
Kurzläufer von wenigen Monaten, wurde der <strong>IBM</strong> Data Path<br />
Optimizer für AIX und Windows NT als integraler Bestandteil<br />
für die Multipfadfähigkeit der Maschine übernommen.<br />
Funktional war die Maschine am Anfang noch schwach auf<br />
der Brust und es standen nur begrenzt Copy Services als<br />
Funktionen zur Verfügung, was die Markteinführung nicht<br />
gerade vereinfachte. Später kamen dann die MainframeFunktionen<br />
‘Concurrent Copy’ und XRC, ‘eXtended Remote Copy’<br />
als asynchrone Spiegelmöglichkeit ganzer <strong>System</strong>e für S/390<br />
Server (mit konsistentem Datenbestand auf der Sekundärseite)<br />
und wiederum zeitversetzt die Funktion PPRC ‘Peer to<br />
Peer Remote Copy’ als synchrone Spiegelung sowohl für<br />
den Mainframe als auch den Open<strong>System</strong>sBereich. Auch<br />
FlashCopy (Instant- oder Point-in-Time-Copy) wurde auf<br />
der Maschine implementiert, um in Sekundenschnelle Kopien<br />
erzeugen zu können, mit denen man sofort arbeiten konnte.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Knapp 2 Jahre nach der Markteinführung bot die Maschine<br />
dann allerdings im MainframeUmfeld eine wesentlich höhere<br />
Funktionsvielfalt im Vergleich zu den auf dem Markt befindlichen<br />
Mitbewerbersystemen. Die Funktion PAV (Parallel<br />
Access Volume) erlaubt im MainframeUmfeld multiple I/O<br />
Operationen auf denselben logischen Volume. Multiple<br />
Allegiance lässt den parallelen Schreib und Lesezugriff auf<br />
dasselbe logische Volume von verschiedenen S/390Servern<br />
zu. I/O Priority Queuing verwendet die Priorisierungsinformationen<br />
des OS/390Workloadmanagers im Goal Mode,<br />
um die Sequenz der einzelnen I/Os optimal zu steuern und<br />
Workloads mit unterschiedlicher Wichtigkeit entsprechend<br />
ihrer Priorisierung optimal zu behandeln.<br />
Das <strong>System</strong> kam mit neuen ManagementTools, der sogenannten<br />
‘StorWatch’Familie, auf den Markt, die es erlaubte,<br />
die Maschinen über das Web zu administrieren. Standardmäßig<br />
wurde die Maschine mit dem ESS Specialist ausgeliefert,<br />
der vor allem für das Konfigurieren und für spätere<br />
Modifizierungen notwendig war. Als separates, zusätzlich<br />
käufliches Produkt wurde der ESS Expert zur Verfügung<br />
gestellt, der ausführliche Informationen über genutzte Kapazitäten,<br />
Performance, Antwortzeiten, Cache Hit Ratios und<br />
mehr lieferte, um ein optimales Tuning auf der Maschine für<br />
die unterschiedlichen Workloads durchführen zu können.<br />
Im Mai 2001 kamen die Folgemodelle F10 und F20, die<br />
erstmals native FICONAnschlüsse boten, um mit FibreChannel<br />
im MainframeUmfeld zu arbeiten. Auch die bisher verwendeten<br />
ESCON und FCAdapter waren verbessert worden<br />
und boten 100 MB/s Durchsatz pro Port in FICON und Fibre<br />
Channel Speed. Sie lieferten Entfernungsmöglichkeiten von<br />
bis zu 10 km (native) und bis zu 100 km über entsprechende<br />
SANFabricKomponenten aus. Die neuen Modelle konnten<br />
mit bis zu 16 FICONAnschlüssen und einer zusätzlichen<br />
CacheOption von 24 GB, also maximal 32 GB, ausgestattet<br />
sein. Damit verbesserte sich die Leistung zu den Vorgängermodellen<br />
um ca. 40 %.<br />
Funktional stellten die neuen Modelle die Funktion PPRC und<br />
FlashCopy auch der <strong>System</strong>plattform AS/400 und iSeries zur<br />
Verfügung. Im März 2002 wurde auch die FICON-Unterstützung<br />
für die bei AirlineBuchungssystemen verwendete<br />
TPFAnwendung (Transaction Processing Facility) verfügbar.<br />
Enterprise <strong>Storage</strong> Server ESS (Shark), 1999: Modelle E10/E20 bis 11 TB,<br />
2001: Modelle F10/F20 bis 35 TB, 2002: Modelle 800 und 800 Turbo II bis<br />
56 TB, April 2004: Entry-Modell 750 bis 5 TB (Brutto-Kapazitäten)<br />
Der Wechsel von ESCON auf FICONInfrastrukturen brachte<br />
damals enorme Infrastrukurverbesserungen und Infrastruktureinsparungen<br />
mit sich, weil in der Regel vier ESCONKanäle<br />
mit 18 MB/s durch einen FICONKanal mit 100 MB/s ersetzt<br />
werden konnten. Allerdings dauert die Penetration noch bis<br />
in die heutige Zeit an.<br />
Im August 2002 kam die letzte Modellreihe der ESS mit den<br />
Modellen 800 und 800 Turbo II auf den Markt, die dann noch<br />
durch ein Einstiegsmodell 750 im Frühjahr 2004 ergänzt<br />
wurde. Die neuen Modelle waren leistungsstärker und<br />
verwen deten zwei 2, 4 oder 6WaySMPRechner mit bis<br />
zu 64 GB Cache.<br />
Dadurch waren ca. 42 % mehr Transaktionen bei Cache<br />
Standard Workloads möglich. Die neuen Modelle konnten im<br />
Mischbetrieb Laufwerke mit 18 GB, 36 GB, 73 GB und 146 GB<br />
ausgestattet werden und boten als BruttoKapazität von<br />
582 GB bis 56 TB. Die Laufwerke mit 18 GB, 36 GB und 73<br />
GB gab es mit Umdrehungsgeschwindigkeiten von wahlweise<br />
10.000 Umdrehungen/Minute und 15.000 Umdrehungen/<br />
Minute, während das großkapazitive 146GBLaufwerk nur<br />
mit 10.000 Umdrehungen/Minute zur Verfügung stand.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
55
56<br />
1999 bis 2005<br />
Die Epoche der Multiplattform-<strong>System</strong>e und des FibreChannel SAN und NAS<br />
Wahlweise konnten die Arrays mit RAID0, 1, 5 und 10 konfiguriert<br />
werden und alle Platten in einem Array wurden mit<br />
einem StripingVerfahren (alle Laufwerke arbeiten gleichzeitig,<br />
wenn eine Spur in kleinen Stücken parallel auf alle Laufwerke<br />
des Arrays geschrieben oder gelesen wird) angesteuert, um<br />
eine optimale Schreib und LesePerformance sicherzustellen.<br />
Für die ArrayAnbindung wurden SSA160Adapter verwendet,<br />
die in einer Doppelloop einen Gesamtdurchsatz von 320 MB/s<br />
bei acht gleichzeitigen I/Os erreichen konnten. Der Gesamtdurchsatz<br />
(interne Bandbreite) lag beim TurboIIModell bei<br />
3,2 GB/s. Die maximale CacheGröße lag bei bis zu 64 GB.<br />
Das RAIDManagement war komplett in die Adapterkarten<br />
verlagert und bei sequenziellen SchreibWorkloads war die<br />
Maschine in der Lage, vom RAID5 in den RAID3Modus umzuschalten,<br />
bei der bis zu 64 gleichzeitige physische I/Os<br />
auf die Platten möglich waren.<br />
Alle Maschinen waren von Beginn an auf 2GbitHostanbindungungstechnologie,<br />
also 2 Gbit FICON und 2 Gbit<br />
Fibre Channel, ausgelegt. Daneben konnte die Maschine<br />
immer auch noch mit ESCON und UltraSCSIAdaptern<br />
konfiguriert werden.<br />
Die Modelle 800 und 800 Turbo II waren die Basis, um ein<br />
komplett neues Remote-Copy-Verfahren zu entwickeln, das<br />
in seiner Leistungsfähigkeit bis heute einmalig im Markt ist<br />
und bei den Folgeprodukten der DS6000 und DS8000 maßgeblich<br />
seinen Einsatz findet. Dieses neue RemoteCopy<br />
Verfahren wurde den neuen ESSModellen im April 2004 zur<br />
Verfügung gestellt und ermöglichte durch eine bidirektionale<br />
Implementierung über eine FibreChannelVerbindung eine<br />
synchrone Spiegellast (PPRC) von bis zu 16.000 I/Os in der<br />
Sekunde (ESS), die sich später bei den neuen DS8000 auf<br />
bis zu 23.000 I/Os pro Sekunde steigerte – und das über<br />
einen einzigen FibreChannelLink. Bei dieser neuen Implementierung<br />
können extrem kurze Antwortzeiten, auch bei<br />
synchroner Spiegelung über lange Entfernungen, erzielt<br />
wer den. Bei den Modellen 800 der ESS wurden Antwort<br />
zeiten von 2 ms bei einer synchronen Spiegelung von über<br />
75 km erzielt.<br />
Ebenso wurden für die neuen Modelle die Management<br />
Möglichkeiten erweitert. So wurden erstmals offene APIs als<br />
Industrie Standard Interface (SNIASMIS) zur Verfügung gestellt.<br />
Die Maschinen konnten mit Scripting Tools über das<br />
CLI (Command Line Interface) automatisiert werden. Ebenso<br />
stand eine Webbasierende grafische Benutzerober fläche<br />
(GUI) für einfache Administration zur Verfügung.<br />
Für alle ESSModelle wurden RS/6000 basierende POWER5<br />
Prozessoren eingesetzt. Die EModelle verwendeten eine<br />
H50 als 4WaySMPVersion mit einer Taktrate von 340 MHz.<br />
Die FModelle benutzten eine H70 als 4WaySMP mit<br />
540 MHz. Die letzten Modelle der 800er Reihe verwendeten<br />
einen H80Rechner. Das Einstiegsmodell 750 benutzte eine<br />
H80 als 2x2Way mit 600 MHz, die Modelle 800 eine H80<br />
als 2x4Way mit 600 MHz und die leistungsstärkste ESS 800<br />
Turbo 2 eine H80 als 2x6Way mit 750 MHz. Für die interne<br />
Übertragung in den Maschinen wurde mit PCIBussen<br />
gearbeitet.<br />
Im Januar 2006 zog <strong>IBM</strong> alle ESSModelle mit Wirkung vom<br />
April 2006 vom Vertrieb zurück.<br />
Parallel zur ESS wurde bei <strong>IBM</strong> bereits 1999 der Startschuss<br />
gegeben, an Serverbasierenden Speicherarchitekturen zu<br />
arbeiten, die die Basis für die heutige, erste Serverbasierende<br />
Speicherarchitektur legten und heute mit dem Produkt<br />
der DS8000 zur Verfügung stehen. Diese neue Architekturentwicklung<br />
fand parallel zur Weiterentwicklung der ESS statt<br />
und wurde unter größter Geheimhaltung vorangetrieben.<br />
Das erfolgreiche, SSAbasierende Plattensystem <strong>IBM</strong> 7133,<br />
das vor allem in RS/6000 und pSeriesUmgebungen eingesetzt<br />
wurde, bekam 2002 auch die Möglichkeit, in Fibre<br />
Channel SANs zum Einsatz zu kommen. Mit dem Adapter<br />
7140 konnte das Plattensystem an SANs angeschlossen<br />
werden und stellte eine neue Funktion über diesen Adapter,<br />
‘InstantCopy’, zur Verfügung. Damit konnte neben einem<br />
RAID1Spiegel eine weitere Kopie erzeugt werden, die dann<br />
für asynchrone Backup oder Testzwecke verwendet werden<br />
konnte. Da die hier eingesetzte SSATechnologie auch im<br />
Enterprise <strong>Storage</strong> Server ESS (Shark) eingesetzt wurde, bezeichnete<br />
man die Kombination von 7133 und dem Adapter<br />
7140 auch als ‘Hammershark’. Die Nähe zur ESS (Shark)<br />
wurde auch durch eine Aufrüstoption unterstrichen, bei<br />
der 7133 Kapazität zur Erweiterung einer Shark genutzt<br />
werden konnte.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Nach der Markteinführung der ESS als multiplattformfähiges<br />
EnterprisePlattensystem erkannte <strong>IBM</strong> sehr schnell, dass<br />
selbst Einstiegskonfigurationen einer Shark für den Mittelstandsbereich<br />
zu teuer waren. Deshalb wurde bereits im<br />
Jahr 2000 mit der Firma Compaq ein OEM-Vetrtriebsvertrag<br />
unterzeichnet, der <strong>IBM</strong> erlaubte, das aktuelle Compaq<br />
Plattensystem mit FibreChannelAnschlüssen zu vertreiben.<br />
Das Produkt MSS Modular <strong>Storage</strong> Server unterstützte<br />
heterogene Serverplattformen im WindowsNT und UNIX<br />
Umfeld und wurde über Hubs und/oder Switches an FC<br />
Server angeschlossen.<br />
Die Zeit des MSS Modular <strong>Storage</strong> Servers war aber nur von<br />
sehr kurzer Dauer und es wurden nur vereinzelte <strong>System</strong>e<br />
installiert. Mit der Übernahme von Compaq durch Hewlett<br />
Packard HP war die Allianz mit Compaq beendet.<br />
Daraufhin griff <strong>IBM</strong> auf eine seit Anfang der 90erJahre be<br />
stehende OEM-Allianz mit der Firma LSI zurück, die es<br />
erlaubte, dass <strong>IBM</strong> unter <strong>IBM</strong> Logo Plattenprodukte von LSI<br />
speziell im IntelUmfeld (NetFinity) über den <strong>IBM</strong> xSeries<br />
Kanal vertrieb. Bereits 1993 wurden die LSIProdukte <strong>IBM</strong><br />
7135110 RAIDiant Array in den Vertrieb aufgenommen, 1995<br />
das <strong>IBM</strong> 7135210 RAIDiant Array, 1998 der <strong>IBM</strong> 3526 FC<br />
RAID Controller, 2000 die <strong>IBM</strong> 3552 FAStT500 und die <strong>IBM</strong><br />
3542 FAStT200 und im Jahr 2001 die <strong>IBM</strong> 1742 FAStT700.<br />
Im Jahr 2001 wurde diese Allianz zwischen <strong>IBM</strong> und LSI auf<br />
den gesamten <strong>Storage</strong>Vertrieb erweitert, eine Allianz, die sehr<br />
erfolgreich werden sollte und bis in die heutige Zeit hochaktuell<br />
ist. Das erste Produkt, das <strong>IBM</strong> über diese Allianz vertrieb,<br />
war ein EntryPlattenprodukt, die FAStT200, damals<br />
auch als <strong>IBM</strong> 3542 bekannt, das mit bis zu zwei FibreChannelPorts<br />
mit der Grundeinheit (10 eingebaute Festplatten)<br />
und zwei Erweiterungseinheiten EXP500 (pro EXP500<br />
zusätz liche 15 Platten) eine maximale Kapazität von bis zu<br />
2,1 TB anbot. Das <strong>System</strong> stellte eine preisgünstige, performante<br />
Plattenlösung für dezentrale Abteilungen und Arbeitsgruppen<br />
mit bis zu vier Servern dar. Das <strong>System</strong> bot als<br />
Entrysystem damals bereits eine ganze Reihe von Sicherheitsoptionen<br />
wie Dual Active RAID Controller, RAID 0, 1, 10,<br />
3 und 5, redundante Netzteile und Batterie sowie die Möglichkeit,<br />
alle Kom ponenten als ‘Hot Swaps’ zu tauschen. Im<br />
<strong>System</strong> konnten im Mischbetrieb Platten mit 18 GB, 36 GB<br />
und 73 GB eingesetzt werden.<br />
Die Abkürzung ‘FAStT’ steht für ‘Fibre Array <strong>Storage</strong> Tech-<br />
nology’. Der ursprüngliche Name sollte FAST – für Fibre Array<br />
<strong>Storage</strong> Server – lauten, war aber bei der Ankündigung der<br />
LSIProdukte bereits vergeben und konnte nicht verwendet<br />
werden. Deshalb entschloss man sich für FAStT mit der<br />
Intention, dass das kleine ‘t’ nicht ausgesprochen wird. Trotz<br />
allem setzte sich die Aussprache als ‘fast_T’ in ganzer<br />
Breite durch.<br />
FAStT900 FAStT700 FAStT600 Turbo FAStT600 FAStT200 FAStT200<br />
Host Interface 2 Gbps FC 2 Gbps FC 2 Gbps FC 1 Gbps FC 2 Gbps FC 2 Gbps FC<br />
SAN attachments<br />
(max)<br />
Direct attachments<br />
(max)<br />
Redundant drive<br />
channels<br />
Drive types supported<br />
4 FC-SW 4 FC-SW 4 FC-SW 4 FC-SW 4 FC-SW 4 FC-SW<br />
8 FC-AL 8 FC-AL 4 FC-AL 4 FC-AL 2 FC-AL 4 FC-AL<br />
Four 2 Gb FC Four 2 Gb FC Four 2 Gb FC Four 2 Gb FC Four 1 Gb FC Four 2 Gb FC<br />
FC, SATA FC FC, SATA FC, SATA FC FC, SATA<br />
Max drives 224 224 112 56 66 56<br />
Max physical<br />
capacity with FC<br />
Max physical<br />
capacity with SATA<br />
32 TB 32 TB 16.4 TB 8.2 TB 9.6 TB –<br />
56 TB – 28 TB 28 TB – 14 TB<br />
XOR technology ASIC ASIC Integrated Integrated Integrated Integrated<br />
Subsystem Cache 2 GB 2 GB 2 GB 512 MB 256 MB 512 MB<br />
<strong>IBM</strong> FAStT-Plattensubsystemfamilie, Spezifikationsübersicht<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
57
58<br />
1999 bis 2005<br />
Die Epoche der Multiplattform-<strong>System</strong>e und des FibreChannel SAN und NAS<br />
Die Reihe der FAStTPlattensysteme wurde im Oktober 2001<br />
um die leistungsfähigeren Produkte FAStT500 und FAStT700<br />
erweitert, die mit bis zu vier FibreChannelAnschlüssen höhere<br />
Kapazitäten boten. Im Hochleistungsbereich kam im Februar<br />
2003 die FAStT900 dazu, um die Baureihe auch im oberen<br />
Leistungsbereich abzurunden. Im April 2003 wurde die<br />
FAStT500 duch die FAStT600 und FAStT600 Turbo ersetzt.<br />
Neben den Plattenerweiterungseinheiten EXP500 und EXP700<br />
(EXP steht für Expansion), die mit FibreChannelPlatten<br />
bestückt waren, kündigte <strong>IBM</strong> im Oktober 2003 die Erweiterungseinheit<br />
EXP100 an, die mit preislich günstigeren SATA<br />
Platten bestückt war. Der dazu passende Controller wurde<br />
im Mai 2004 mit der FAStT100 angekündigt. SATA-Platten<br />
(Serial Advanced Technology Attached) sind günstige IDE<br />
Platten mit seriellem Interface, die bisher auschließlich im<br />
HeimPCBereich ihre Anwendung fanden. Mit Ausnahme<br />
der schon länger verfügbaren FAStT200 waren alle <strong>System</strong>e<br />
jetzt mit 2 Gbit FibreChannel ausgestattet, und das sowohl<br />
Hostseitig als auch in der Anbindung der Plattenloops an<br />
den jeweiligen FAStT Controller. Über 90 % des Vertriebs<br />
dieser LSIPlattensubsystemSerie lief über <strong>IBM</strong> oder <strong>IBM</strong><br />
Geschäftspartner und war im FibreChannelUmfeld ein riesiger<br />
Erfolg, der bis heute anhält.<br />
Je nach Controllerstärke wurde bei den FAStTPlattensystemen<br />
eine Vielzahl von neuen Funktionalitäten eingeführt, die dann<br />
vor allem in den oberen Modellen zum standardmäßigen Einsatz<br />
kamen und bis heute in den <strong>System</strong>en verwendet werden.<br />
Zum besseren Verständnis werden diese Funktionen im<br />
Folgenden beschrieben.<br />
DCE und DVE: Dynamic Capacity Expansion und Dynamic<br />
Volume Expansion ermöglichen, zugewiesene Speicherbereiche<br />
im laufenden Betrieb zu vergrößern. Innerhalb des<br />
FAStT<strong>System</strong>s werden physische Laufwerke zu einzelnen<br />
ArrayGroups gebunden. Die Laufwerke können sich dabei<br />
über verschiedene EXPErweiterungseinheiten verteilen. Die<br />
Selektion der Laufwerke kann dem <strong>System</strong> überlassen werden<br />
(dann wird stets die performanteste Konfiguration gewählt)<br />
oder vom Administrator manuell definiert werden. Für die erstellte<br />
ArrayGroup wird ein RAIDLevel definiert, der für die<br />
gesamte ArrayGroup Gültigkeit hat. Innerhalb dieser Array<br />
Group können verschiedene Volumes definiert werden. Diese<br />
Volumes werden den einzelnen Servern zugewiesen. Für den<br />
Fall, dass der gewählte Plattenzusammenschluss (ArrayGroup)<br />
mehr Kapazität benötigt oder eine höhere Performance erforderlich<br />
wird, gibt es die Möglichkeit, dieser Group eine<br />
oder mehrere physische Laufwerke hinzuzufügen (DCE). Die<br />
in dieser Group befindlichen Volumes nutzen diese neue<br />
Kapazität, die Disk wird automatisch in die VolumeVerteilung<br />
aufgenommen.<br />
Sollte innerhalb eines zugewiesenen Volumes mehr Kapazität<br />
benötigt werden, so ist im laufenden Betrieb auch hier eine<br />
Kapazitätserweiterung möglich (DVE). Voraussetzung hierfür<br />
ist, dass entsprechende Kapazitäten innerhalb der Array<br />
Group zur Verfügung stehen (in diesem Fall kann über DCE<br />
eine beliebige, undefinierte Platte ergänzt werden). Diese<br />
Funktionalitäten ermöglichen es dem Anwender, flexibel auf<br />
Kapazitätsanforderungen einzugehen und diese auf einfachste<br />
Weise umzusetzen. Alle Funktionen arbeiten im laufenden<br />
Betrieb mit Data in Place und werden über den<br />
FAStT <strong>Storage</strong> Manager initialisiert.<br />
DRM: Dynamic RAID Migration. Genauso wie zugewiesene<br />
Kapazitäten sind ebenfalls zugewiesene RAIDLevel nicht<br />
statisch, sondern auch im laufenden Betrieb veränderbar.<br />
Sollten sich durch Änderungen im Lastprofil, der Kapazitätsoder<br />
Sicherheitsanforderung Änderungswünsche am eingesetzten<br />
RAIDLevel ergeben, so kann dieser im laufenden<br />
Betrieb je RAIDArray angepasst werden. Es stehen die<br />
RAIDLevel 0, 1, 1+0, 3 und 5 zur Verfügung. Es kann von<br />
jedem RAIDLevel zu jedem anderen RAIDLevel gewechselt<br />
werden. Voraussetzung ist, dass entsprechende Plattenkapazitäten<br />
(z. B. bei einem Wechsel von RAID5 zu RAID1) verfügbar<br />
sind (DCE). Auch dies ist im laufenden Betrieb mit Data<br />
in Place möglich. Die RAIDBerechnung wird im Controller<br />
über HWFunktionalität durchgeführt.<br />
DAE: Dynamic Array Expansion. Sollte innerhalb einer FAStT<br />
weitere physische Kapazität benötigt werden, so gibt es die<br />
Möglichkeit, im laufenden Betrieb die angeschlossenen Erweiterungseinheiten<br />
mit weiteren FCLaufwerken in verschiedenen<br />
Kapazitätsgrößen und mit unterschiedlichen RPMs zu<br />
bestücken (bis zu 14 Laufwerke je EXP700). Sollten in den<br />
angeschlossenen EXPs keine freien Slots zur Verfügung stehen,<br />
so besteht die Möglichkeit, im laufenden Betrieb eine<br />
weitere EXP700 an den FAStTController anzuschließen. So<br />
lassen sich einzelne Laufwerke oder ganze Erweiterungseinheiten<br />
im laufenden Betrieb hinzufügen.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Neben diesen StandardFunktionalitäten sind weitere,<br />
optionale Funktionen verfügbar:<br />
•<br />
FlashCopy: Die Funktion FlashCopy (Point-in-Time-Copy)<br />
ermöglicht bis zu 4 virtuelle Kopien eines bestehenden<br />
Volumes. Diese Funktion kommt vor allem für die Erstellung<br />
von Testumgebungen und die Erhöhung von Onlinezeiten<br />
bei Backups zum Einsatz. Wie funktioniert nun FlashCopy<br />
bei den FAStT-<strong>System</strong>en?<br />
Über dem FAStT <strong>Storage</strong> Manager (FSM) wird der Flash-<br />
Copy-Befehl über die GUI-Oberfläche abgesetzt. Über das<br />
GUI wird in diesem Schritt ebenfalls ein Repository angelegt,<br />
ein physischer Datenbereich für die Änderungen zwischen<br />
der Kopie und T0, dem Zeitpunkt des Spiegelungsbeginns.<br />
Die Größe des Repositorys ist abhängig von der Anzahl der<br />
Änderungen am Originalvolume. Die Erfahrung zeigt, dass<br />
eine Repositorygröße von 20 % des Originalvolumes sinnvoll<br />
ist. Sollte bei längerer Kopievorhaltung oder überdurchschnittlich<br />
vielen Änderungen der Source mehr Repository-Kapazität<br />
benötigt werden, so kann dieser Bereich<br />
flexibel vergrößert werden (DVE). Die Erstellung einer Flash-<br />
Copy ist innerhalb von wenigen Sekunden abgeschlossen.<br />
Zur weiteren Benutzung einer FlashCopy ist es wichtig, zu<br />
T0 auf einen konsistenten Datenbestand zurückzugreifen,<br />
da ansonsten eine inkonsistente Kopie entsteht. Die erstellte<br />
virtuelle Kopie (nach wenigen Sekunden) kann z. B. dem<br />
Backup-Server zur Datensicherung zugewiesen werden.<br />
Wird während der Nutzung einer FlashCopy (Target) eine<br />
Änderung an der Source (Block A) vorgenommen, so wird<br />
das Original vor der Änderung in das Repository übernommen.<br />
Wird das Target geändert, so wird diese Änderung<br />
ebenfalls im Repository gespeichert. Wurden an der<br />
Source keine Änderungen vorgenommen, so greift man<br />
bei der Nutzung der Copy (Target) automatisch auf die<br />
Source zurück.<br />
FAStT100<br />
FAStT RAID Controller Familie<br />
FAStT200<br />
VolumeCopy: Ergänzend zur Funktion FlashCopy ist für<br />
FAStT-<strong>System</strong>e mit FSM 8.4 auch die Funktion VolumeCopy<br />
verfügbar. VolumeCopy erstellt im Gegensatz zu FlashCopy<br />
eine physische Kopie. Es muss also für die Erstellung einer<br />
VolumeCopy die gleiche physische Kapazität wie die der<br />
Source zur Verfügung stehen. Es besteht die Möglichkeit,<br />
diese Kopie nach Wunsch zu priorisieren. Dies bedeutet,<br />
dass I/O-Tätigkeiten zum Host bevorzugt, die Erstellung<br />
der Kopie nur zweitrangig behandelt wird. VolumeCopy ist<br />
eine Funktion, die besonders für Testumgebungen (z. B. zur<br />
Durchführung von Releasewechseln etc.) oder für Online-<br />
Backups geeignet ist.<br />
Remote Mirroring: Während die Kopierfunktionen FlashCopy<br />
und VolumeCopy Datenkopien innerhalb eines FAStT-<br />
<strong>System</strong>s zur Verfügung stellen, erstellt Remote Mirroring<br />
eine Kopie von Daten über eine SAN-Infrastruktur von einer<br />
FAStT auf eine weitere. Diese Funktion ist für die FAStT-<br />
<strong>System</strong>e 700 und 900 verfügbar. Remote Mirroring ist eine<br />
bidirek tionale, synchrone Kopie. Über dedizierte<br />
FibreChannel-Ports können bis zu 32 Volumes auf eine<br />
zweite FAStT gespiegelt werden. Remote Mirroring wird<br />
für Katastrophen vorsorge und High-Performance Copys<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
•<br />
•<br />
•<br />
FAStT600<br />
Single/Dual/Turbo<br />
eingesetzt.<br />
Partitioning: Um unterschiedliche Speicherbereiche auf<br />
der FAStT voneinander abzugrenzen, steht die Funktion<br />
Partitioning zur Verfügung. Die Abgrenzung bewirkt, dass<br />
definierte Server nur auf den ihnen zugewiesenen Speicherbereich<br />
zugreifen können. Auf Speicherbereiche von<br />
‘fremden’ Servern kann somit kein Zugriff erfolgen. Dies<br />
erhöht die Sicherheit der einzelnen Speicherbereiche. Besonders<br />
in Microsoft-Umgebungen ist diese Funktion sehr<br />
wertvoll, da die Betriebssysteme keine derartige<br />
Funktiona lität bieten.<br />
FAStT700<br />
FAStT900<br />
59
60<br />
1999 bis 2005<br />
Die Epoche der Multiplattform-<strong>System</strong>e und des FibreChannel SAN und NAS<br />
Laufwerkerweiterungseinheiten, Management SW und das Einbau-Rack<br />
EXP100<br />
Serial-ATA-Technologie<br />
EXP700<br />
2-Gb-FC-AL-Technologie<br />
Laufwerkeinheiten FAStT <strong>Storage</strong><br />
Manager (FSM)<br />
Mit der Ankündigung der ersten Server-basierenden Spei-<br />
cherarchitekturen mit den Plattenprodukten DS6000 und<br />
DS8000 unternahm <strong>IBM</strong> im September 2004 ein generelles,<br />
einheitliches ReBranding der Plattenprodukte. DS steht für<br />
Disk <strong>System</strong>. Die Zahl dahinter soll die Leistungsfähigkeit<br />
des jeweiligen <strong>System</strong>s reflektieren: je höher die Zahl, desto<br />
höher die Leistung.<br />
Neben der Vereinheitlichung der Plattenproduktnamen wurden<br />
auch die Namen der jeweiligen Funktionalitäten entsprechend<br />
angepasst. Vergleichbare Funktionen der DS6000 und DS8000<br />
wurden bei den FAStT<strong>System</strong>en mit denselben Begriffen<br />
bezeichnet. Dies betraf vor allem die RemoteCopySpiegelverfahren.<br />
Das synchrone Spiegeln von Plattensystemen wird bei der<br />
DS6000 und DS8000 als Metro Mirroring bezeichnet, das<br />
asynchrone Spiegelverfahren als Global Mirroring. Die neu<br />
eingeführten Begriffe sollen dem neu entwickelten Spiegelverfahren,<br />
das auf der ESS Modell 800 als Plattform entwickelt<br />
wurde und heute das leistungsfähigste Spiegeln im Markt<br />
darstellt, gebührend Rechnung tragen.<br />
Für die FAStTPlattenfamilien wurden im Einzelnen folgende<br />
Rebrandings durchgeführt:<br />
Naming Prior to Sept 7, 2004 New naming as of Sept 7, 2004<br />
<strong>IBM</strong> Total<strong>Storage</strong> FAStT <strong>Storage</strong> Server <strong>IBM</strong> Total<strong>Storage</strong> DS4000<br />
FAStT DS4000<br />
FAStT Family DS4000 series<br />
FAStT <strong>Storage</strong> Manager vX.Y<br />
(example FSM v9.10)<br />
FAStT100 DS4100<br />
FAStT600 DS4300<br />
FAStT600 with Turbo Feature DS4300 Turbo<br />
FAStT700 DS4400<br />
FAStT900 DS4500<br />
DS4000 <strong>Storage</strong> Manager vX.y<br />
(example 9.10)<br />
EXP700 DS4000EXP700<br />
EXP100 DS4000EXP100<br />
FAStT FlashCopy FlashCopy for DS4000<br />
FAStT VolumeCopy VolumeCopy for DS4000<br />
FAStT Remote Volume Mirror<br />
(RVM)<br />
Enhanced Remote Mirroring for<br />
DS4000<br />
FAStT Synchronous Mirroring Metro Mirroring for DS4000<br />
FAStT Asynchronous Mirroring<br />
(New Feature) w/o Consistency Group<br />
FAStT Asynchronous Mirroring<br />
(New Feature) with Consistency Group<br />
Das Rack<br />
Global Copy for DS4000<br />
Global Mirroring for DS4000<br />
Die jetzt neu bezeichnete DS4000-Plattensubsystemfamilie<br />
wurde im Mai 2005 durch ein neues Hochleistungsmodell<br />
DS4800 ergänzt, das eine doppelt so hohe Leistungsfähigkeit<br />
im Vergleich zur DS4500 auslieferte. Die DS4800 war<br />
vom Aufbau her bereits beim Verfügbarwerden eine 4Gbit<br />
Maschine und somit das erste 4GbitPlattensystem auf dem<br />
Markt. Die Cachegrößen am Anfang konnten je nach Modell<br />
mit 4 GB, 8 GB und später 16 GB konfiguriert werden. Die<br />
DS4800 hatte zudem noch eine andere positive Eigenschaft<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
in der Bauweise: Die Maschine war RoHS-konform und ent<br />
sprach bereits 2005 der neuen EURichtlinie, die seit 1. Juli<br />
2006 in Kraft ist.<br />
Im Jahr 2003 bildete sich in den USA ein Gremium, das es<br />
sich zur Aufgabe machte, Plattensubsysteme unterschiedlicher<br />
Hersteller nach realen und produktiven Workloads auszutesten<br />
und diese Ergebnisse zu publizieren. Dieses heute<br />
fest etablierte Gremium nennt sich ‘<strong>Storage</strong> Performance<br />
Council’ bzw. SPC.<br />
Die neue DS4800 übertraf als MidrangePlattensystem in der<br />
Leistung alle anderen Hersteller mit großem Abstand und er<br />
reichte eine Spitzenpunktzahl von 42.254. Damit ist die DS4800<br />
heute das schnellste Plattensystem im MidrangeMarkt.<br />
Da die älteren DS4000Produkte mit Ausnahme der neu verfügbar<br />
gewordenen DS4800 nicht der RoHSRichtline entsprachen,<br />
wurden im Mai 2006 alle nicht RoHSkonformen<br />
Produkte durch entsprechend neue ersetzt.<br />
RoHS steht für ‘Restriction of Hazardous Substances’<br />
und stellt ab dem 1. Juli 2006 eine gesetzlich kontrollierte<br />
EURichtlinie dar, die genau vorschreibt, welche Materialien,<br />
DS4000 Series aktuell im Jahr 2006<br />
DS4200<br />
4 Gbit<br />
2 GB Cache<br />
RoHS compiliant<br />
SATA Controller<br />
DS4700 Modell 70<br />
4 Gbit<br />
2 GB Cache<br />
RoHS compiliant<br />
Aktuelle Modelle der <strong>IBM</strong> DS4000-Plattenfamilie im Jahr 2006<br />
DS4700 Modell 72<br />
4 Gbit<br />
4 GB Cache<br />
RoHS compiliant<br />
EXP420<br />
4 Gbit<br />
RoHS compiliant<br />
SATA-Platten 500 GB<br />
Legierungen, BariumDerivate etc. in Neuprodukten eingesetzt<br />
werden dürfen. Diese neue Richtlinie gilt EUweit und<br />
betrifft alle Neuprodukte in der Elektro und ITIndustrie, die<br />
ab dem 1. Juli 2006 vertrieben werden.<br />
Die DS4100 als SATA Controller wurde durch den neuen<br />
DS4200 SATA Controller ersetzt, die EXP100 mit 250GBund<br />
400GBSATAPlatten durch die EXP420 mit 500GB<br />
SATAPlatten.<br />
Die DS4300 Dual Controller wurden durch die DS4700 Modell 70<br />
und die DS4300 Turbo durch die DS4700 Modell 72 ersetzt.<br />
Ebenso wurde die EXP710 mit FibreChannelPlatten durch<br />
die EXP810 mit FCPlatten auf 4GbitBasis ersetzt.<br />
Die DS4500, ehemals FAStT900, wurde durch ein neues Einstiegsmodell,<br />
das Modell 80 der leistungsstarken DS4800,<br />
ersetzt. Bei diesem Einstiegsmodell 80 wurde die interne<br />
Übertragungsbandbreite leicht verringert und die Prozessoren<br />
der Controller wurden mit einer 100MHzTaktung (im Vergleich<br />
zu einer 133MHzTaktung) versehen. Damit schließt<br />
das Modell 80 der DS4800 die Leistungslücke zwischen den<br />
Hochleistungsmodellen der DS4800 und dem Midrange<br />
Modell 72 der DS4700.<br />
DS4800 Modell 80<br />
4 Gbit<br />
4 GB Cache<br />
RoHS compiliant<br />
EXP810<br />
4 Gbit<br />
RoHS compiliant<br />
DS4800<br />
4 Gbit<br />
4/8/16 GB Cache<br />
RoHS compiliant<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
61
62<br />
1999 bis 2005<br />
Die Epoche der Multiplattform-<strong>System</strong>e und des FibreChannel SAN und NAS<br />
DS4000 Erweiterungen 2007 und 2008<br />
Im Jahr 2007 stellte <strong>IBM</strong> für die DS4000 Plattenfamilie eine<br />
ganze Reihe von Erweiterungen vor. Im Mai 2007 wurden<br />
für die DS4000 750 GB SATA-Platten und 300 GB Fibre-<br />
Channel-Platten mit 15.000 Umdrehungen in der Minute<br />
eingeführt. Damit skaliert eine DS4800 auf bis zu 68 TB<br />
bzw. 168 TB Speicherkapazität (je nach Verwendung des<br />
Plattentyps). Im Oktober 2007 kamen viele funktionale<br />
Erweiterungen für alle <strong>System</strong>e DS4000 dazu. Für die<br />
<strong>System</strong>e DS4200 und DS4700 steht als neue RAIDOption<br />
RAID6 zur Verfügung. RAID6 sichert den Ausfall von zwei<br />
Platten im RAIDArray ab, da mit zwei ParitySchemen gearbeitet<br />
wird (siehe auch unter RAID). Die Anzahl der Mirror<br />
Relations wurde verdoppelt, ebenso die Anzahl der Flash<br />
Copies. Mit Verfügbarkeit im Februar 2008 können für alle<br />
<strong>System</strong>e LUNs konfiguriert werden, die größer als 2 TB sind.<br />
Die leistungsstarke DS4800 bekam die Erweiterung, dass<br />
bis zu 512 Server an das Plattensystem angeschlossen<br />
werden können. Es stehen jetzt vier aktuelle Modelle der<br />
DS4800 zur Verfügung, die sich hauptsächlich in der Cache<br />
Größe unterscheiden. So sind, je nach Modell, die Cache<br />
Größen 4 GB, 8 GB und 16 GB verfügbar.<br />
Bedient werden die RAIDLevel 0, 1, 3, 5 und 10 (der neue<br />
RAID6Level steht ausschließlich der DS4200 und DS4700<br />
zur Verfügung). Die Berechnung der RAIDLevel bzw. die<br />
XOR-Kalkulation in der DS4800 erfolgt in einem eigens<br />
entwickelten ASIC. Dies ist ein spezieller Prozessor, der<br />
speziell für diese Workload konzipiert wurde. Dies macht<br />
die DS4800 frei von Latenzen, weil weder der Cache noch<br />
andere durchsatzrelevanten Teile der Maschine damit belastet<br />
werden.<br />
Ansicht und Aufbau des Hochleistungsmodells DS4800<br />
Die DS4800 hat alle Festplatten in der Expansion Unit<br />
EXP810 konfiguriert. Weitere Expansion Units sowie auch<br />
einzelne Festplatten können im laufenden Betrieb hinzugefügt<br />
und in Betrieb genommen werden.<br />
Alle Komponenten der DS4800 sind redundant ausgelegt,<br />
z. B. Controller, Stromzufuhr und Kühlung. Ebenfalls wird der<br />
Cache gespiegelt und ist über eine Batterie bis zu 72 Stunden<br />
vor Verlust geschützt. Zusätzlich ist bei der DS4800 die<br />
Midplane, die als Interconnect Module bezeichnet wird, im<br />
laufenden Betrieb tauschbar. Dies ist bislang einmalig bei<br />
Plattensystemen im MidrangeUmfeld.<br />
Ebenfalls einmalig ist die Performance der DS4800. Die<br />
Maschine hält bis heute die Führungsposition im Benchmark<br />
des <strong>Storage</strong> Performance Councils. Dies ist ein Random<br />
I/Oorientierter Benchmark, bei dem reale Workloads hinterlegt<br />
werden. Die genauen Testdaten sowie die Beschreibung<br />
findet man unter www.storageperformance.org.<br />
Der DS4000 <strong>Storage</strong> Manager wird für alle <strong>System</strong>e kostenfrei<br />
mit jedem <strong>System</strong> mitgeliefert. Ebenso ist die Multipathing<br />
Software sowie die CallHomeFunktionalität ohne<br />
zusätzliche Kosten einsetzbar. Als PremiumFeatures stehen<br />
die Funktionen FlashCopy, VolumeCopy und eRVM zur Verfügung.<br />
Diese sind nicht kostenfrei, jedoch wird immer nur<br />
eine Lizenz pro <strong>System</strong> und Funktion herangezogen.<br />
Sowohl bei Kapazität und Leistung als auch beim Preis bietet<br />
die aktuelle Modellreihe der DS4000 für jeden Endbenutzer<br />
eine maßgeschneiderte Plattenlösung im FibreChannel<br />
Umfeld an.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
SAN-Virtualisierung<br />
Die Epoche der Multiplattform-<strong>System</strong>e war stark durch die<br />
Einführung von FibreChannelNetzen und den Aufbau von<br />
SANs geprägt. Damit wurde das Thema Speichervirtualisierung<br />
im SAN zu einem der aktuellsten Themen im <strong>Storage</strong><br />
Umfeld – wobei das Konzept von Virtualisierung nicht neu<br />
ist. Speichervirtualisierungskonzepte sind im Mainframe (z. B.<br />
DFSMS) oder im UNIXBereich in Form von ‘Logischen<br />
VolumeManagern’ schon lange im Einsatz. Der Einsatz von<br />
<strong>Storage</strong> Area Networks (SAN) hat die Entwicklung hin zur<br />
Speichervirtualisierung beschleunigt. Ebenso die Komplexität<br />
heutiger heterogener Infrastrukturen hinsichtlich der Server,<br />
Speichernetze und Speichersubsysteme.<br />
Der primäre Ansatz von Speichervirtualisierung war die<br />
Entkoppelung der physischen Speicherressourcen von der<br />
direkten Zuordnung zu Serversystemen. Diese SANbasierte<br />
Lösung legt eine Virtualisierungsebene zwischen Server und<br />
Speichersysteme. Vorrangiges Ziel ist die gemeinsame Nutzung<br />
von Speicher quer über die gesamte Speicherhardware<br />
sowie alle Serverplattformen und Betriebssysteme. Virtualisierung<br />
im Speichernetzwerk ermöglicht es, Speicherressourcen<br />
plattformunabhängig zu integrieren, aufzurüsten, zu migrieren,<br />
zu replizieren und zu verteilen.<br />
Um diese enorme Flexibilität innerhalb eines SANs zu<br />
bekommen, entwickelte die <strong>IBM</strong> in Hursley, UK, das Produkt<br />
SAN Volume Controller, auch SVC genannt, das im<br />
Juni 2003 angekündigt und im September 2003 verfügbar<br />
wurde.<br />
Der <strong>IBM</strong> SAN Volume Controller wurde für einen Einsatz ent<br />
wickelt, bei dem Kapazitäten mehrerer heterogener Speichersysteme<br />
zu einem einzigen Speicherreservoir, das von einem<br />
zentralen Punkt aus verwaltet werden kann, zusammengefasst<br />
werden. Er ermöglicht Änderungen an physischen Speichersystemen<br />
mit minimalen oder keinen Beeinträchtigungen für<br />
Anwendungen, die auf den Hosts ausgeführt werden, und<br />
er minimiert Ausfallzeiten durch geplante oder ungeplante<br />
Ereignisse, Wartungsmaßnahmen und Sicherungen. Zudem<br />
erhöht der SVC die Auslastung der Speicherkapazitäten, die<br />
<strong>IBM</strong> SAN Volume Controller SVC<br />
Onlineverfügbarkeit sowie die Produktivität und Effizienz von<br />
Administratoren. Darüber hinaus bietet er zur weiteren Vereinfachung<br />
des Betriebs die Möglichkeit, erweiterte Kopierservices<br />
systemübergreifend für Speichersysteme vieler verschiedener<br />
Anbieter einzusetzen. In seinem vierten Release<br />
wurde der SAN Volume Controller auf die Verwaltung noch<br />
größerer und verschiedenartiger Speicherumgebungen ausgelegt.<br />
Mit der jetzt erweiterten Unterstützung für zahlreiche<br />
Speichersysteme anderer Anbieter, wie z. B. EMC, HP und<br />
HDS, erlaubt der SAN Volume Controller die Einrichtung<br />
einer mehrstufigen Speicherumgebung, sodass jede Datei<br />
aufgrund ihres Stellenwerts auf dem entsprechenden Subsystem<br />
abgespeichert werden kann. Die neueste Version des<br />
SAN Volume Controller, die im Juli 2006 verfügbar wurde,<br />
beruht auf 4-Gbit-Technologie und ist RoHS-konform.<br />
Bandsysteme<br />
Neben der PlattensubsystemWeiterentwicklung und den<br />
Fortschritten auf dem Gebiet von SANGlasfasernetzen blieb<br />
auch die Weiterentwicklung der TapeTechnologien spannend.<br />
Nach Einführung der LTO-Bandtechnologie 2000 (Ultrium 1)<br />
mit 100 GB nativer Kapazität auf der Kassette wurde bereits<br />
im Februar 2003 die Generation 2 (Ultrium 2) der LTOLaufwerke<br />
mit einer Kassettenkapazität von 200 GB native eingeführt.<br />
Im Februar 2005 kam die Drittgeneration (Ultrium 3),<br />
wieder mit einer Kapazitätsverdoppelung auf 400 GB native<br />
pro Kassette. Auch die Geschwindigkeit der Laufwerke wurde<br />
massiv verbessert. LTO2Laufwerke arbeiteten bereits mit<br />
35 MB/s mit 8SpurTechnik. Bei LTO3 wurde auf 16Spur<br />
Technik und eine Datenrate von 80 MB/s umgestellt.<br />
Wie vorgesehen wurde die Schreib/LeseRückwärtskompatibilität<br />
eingehalten. So können LTO3Laufwerke immer noch<br />
Kassetten der Generation 1 lesemäßig verarbeiten und Kassetten<br />
der Generation 2 sowohl schreiben als auch lesen.<br />
Mit der Einführung der LTO3Laufwerkgeneration im Februar<br />
2005 wurden neben den bisher verwendeten überschreib<br />
baren Kassetten auch sogenannte WORM-Kassetten<br />
(Write Once Read Many) eingeführt, die durch eine Mehr<br />
fachkennzeichnung als Überschreibschutz keine Möglichkeit<br />
mehr bieten, abgespeicherte Daten zu verändern oder zu<br />
löschen. Die WORMKennzeichnung ist auf der linken Seite<br />
der Kassette in einem eingebauten TransponderChip hinterlegt,<br />
das mit Radiofrequenz ausgelesen wird. Die Kennzeichnung<br />
steht zudem im eingebauten MemoryChip der<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
63
64<br />
1999 bis 2005<br />
Die Epoche der Multiplattform-<strong>System</strong>e und des FibreChannel SAN und NAS<br />
Ultrium LTO Six-Generation Roadmap<br />
Native Capacity<br />
Native Transfer Rate<br />
Generation 1<br />
100 GB<br />
up to 20 MB/s<br />
Standardisierte LTO-Roadmap bis Generation 6<br />
Kassette und in der Tape Volume Control Region am Bandanfang.<br />
Um absolut manipuliersicher zu sein, wird bei der<br />
Herstellung dieser WORMKassetten die Kennzeichnung<br />
noch auf die vorgeschriebenen Servobänder gebracht: eine<br />
VierfachKennzeichnung, die sicherstellt, dass LTO3WORM<br />
Kassetten nicht mehr überschrieben werden können. LTO<br />
WORMKassetten sind zweifarbig gekennzeichnet. Die eine<br />
Hälfte ist schwarz und die andere in weißer Farbe.<br />
Mit der Verfügbarkeit von LTO3 wurde die offizielle Roadmap<br />
um zwei weitere Generationen mit LTO5 und LTO6 erweitert.<br />
Es ist davon auszugehen, dass alle 2 bis 2 ½ Jahre eine neue<br />
LTOGeneration gemäß dieser Roadmap auf dem Markt verfügbar<br />
wird.<br />
LTO1-Kassette,<br />
100 GB Kapazität (native)<br />
Generation 2<br />
200 GB<br />
up to 40 MB/s<br />
LTO2-Kassette,<br />
200 GB Kapazität (native)<br />
WORM<br />
Generation 3<br />
400 GB<br />
up to 80 MB/s<br />
WORM WORM WORM<br />
Generation 4<br />
800 GB<br />
up to 120 MB/s<br />
Generation 5<br />
1.6 TB<br />
up to 180 MB/s<br />
Generation 6<br />
3.2 TB<br />
up to 270 MB/s<br />
Die etwas eigenwillige Farbwahl der standardisierten LTO<br />
Kassetten kommt aufgrund einer wichtigen Anforderung zustande.<br />
Farbenblinde müssen in der Lage sein, die Kassetten<br />
optisch zu unterscheiden.<br />
Lag der Marktanteil 1999 mit 90 % noch DLTTechnologie<br />
von Quantum, hat sich das Bild seither um 180 Grad gedreht<br />
und die LTOTechnologie dominiert heute mit über 80 %.<br />
Der LTOMassenmarkt mit billigen LTOLaufwerken in halbhoher<br />
(Half High) Bauweise wurde bisher ausschließlich von<br />
HewlettPackard HP abgedeckt. Mit einer Ankündigung im<br />
Oktober 2006 steigt auch <strong>IBM</strong> in dieses Segment ein und<br />
bietet halbhohe LTO3-Laufwerke im Niedrigpreisbereich<br />
an. Die Laufwerke sind mit einer Ultra 160 SCSI Schnittstelle<br />
ausgestattet und arbeiten mit einer DatenTransferRate von<br />
60 MB/Sekunde (native).<br />
LTO3-Kassette,<br />
400 GB Kapazität (native)<br />
LTO4-Kassette,<br />
800 GB Kapazität (native)<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Im April 2007 kündigte <strong>IBM</strong> mit sofortiger Verfügbarkeit als<br />
erster Hersteller LTO4-Laufwerke und -Kassetten an.<br />
Das <strong>IBM</strong> TS1040 Laufwerk ist ein LTO4Laufwerk in voller<br />
Bauhöhe (Full High) und für den Einbau in <strong>IBM</strong> Libraries<br />
vorgesehen. Das Laufwerk arbeitet mit einer Datenrate<br />
von bis zu 120 MB/s (native) und die Kassettenkapazität<br />
der neuen LTO4Kassetten beträgt 800 GB (native).<br />
Das Laufwerksinterface bietet einen Anschluss über einen<br />
4 Gbit FibreChannel, SCSI oder 3 Gbps Dual Port SAS. Von<br />
der TS1120 (3592) Technologie wurde der Surface Control<br />
GuidingMechanismus zur optimierten Bandführung übernommen.<br />
Ebenso bietet das Laufwerk vorausschauende<br />
Fehlerbehandlung SARS (Statistical Analysis and Reporting<br />
<strong>System</strong>), einen verbesserten ECC (Error Correction Code)<br />
und Digital Speed Matching. Ein interner Pufferspeicher von<br />
256 MB (LTO3 hatte nur 128 MB) sorgt dafür, dass der<br />
Datenstrom nicht abreißt. Insgesamt passt sich das Laufwerk<br />
an 6 Geschwindigkeiten des Servers an (30, 48, 66, 84<br />
103 und 120 MB/s) und reduziert so die Start/StopAktivitäten.<br />
Adaptive Kompression von Daten dient zur optimalen<br />
Nutzung der Bandkapazitäten. WORMKassetten sind<br />
neben den StandardKassetten verwendbar und die Laufwerke<br />
sind als erste LTOGeneration Encryptionfähig. LTO4<br />
von <strong>IBM</strong> zeichnet sich durch sehr geringen Energiebedarf<br />
mit PowermanagementFunktion, u. a. SleepingModus bei<br />
Nichtgebrauch, aus (maximaler Strombedarf 27 Watt). <strong>IBM</strong><br />
setzt auf hohe Qualität, z. B. den Einsatz von Metall, und vermeidet<br />
Plastik (weniger Störungen). Diese Merkmale führen<br />
zu einem stabileren Betrieb im Vergleich zu den alten LTO<br />
Generationen. Es können Laufwerks/Zugriffsstatistiken<br />
geführt und ggfs. Fehler vorhergesagt werden, um so Laufwerke<br />
präventiv auszutauschen, bevor ein Fehler auftritt.<br />
Viele Innovationen, die im EnterpriseBandlaufwerk <strong>IBM</strong> <strong>System</strong><br />
<strong>Storage</strong> TS1120 stecken, wurden in die <strong>IBM</strong> LTO4Laufwerke<br />
integriert. Unter Nutzung der Verschlüsselungstechnik<br />
der TS1120 Technologie können die LTO4Bandlaufwerke<br />
Daten komprimieren und danach verschlüsseln mit fast keiner<br />
Auswirkung auf die Leistung des Laufwerks (ca. 1 %).<br />
<strong>IBM</strong> TS1040 LTO4-Laufwerk ohne Gehäuse<br />
Die Unterschiede der Verschlüsselungstechnik liegen im<br />
‘KeyHandling’ und sind ausführlich im Kapitel ‘Encryption’<br />
beschrieben.<br />
Die <strong>IBM</strong> TS1040 Laufwerke sind in den Autoloader TS3100<br />
und in die <strong>IBM</strong> Libraries TS3200, TS3310 und TS3500 einbaubar.<br />
Neben den TS1040 Laufwerken für die Libraries<br />
kündigte <strong>IBM</strong> im April 2007 auch Stand Alone LTO4-Laufwerke<br />
an, die auch in ein 19ZollRack eingebaut werden<br />
können. Die ‘Stand Alone’ Laufwerke werden unter dem<br />
Begriff TS2340 vermarktet und weisen dieselben Spezifikationen<br />
wie TS1040 auf. Auch hier handelt es sich um Laufwerke<br />
mit voller Bauhöhe (Full High). Die TS2340 haben<br />
wahlweise einen Anschluss über 3 Gbps Dual Port SAS<br />
oder SCSI und ein LEDDisplay zur Administration.<br />
LTO4Laufwerke können LTO1Kassetten nicht mehr verar<br />
beiten. Sie können LTO2Kassetten auslesen und LTO3Kassetten<br />
im LTO3Mode beschreiben und lesen. Mit den LTO4<br />
Kassetten bietet ein LTO4Laufwerk das Maximum an<br />
Kapazität (800 GB auf der Kassette) und die hohe Datenrate<br />
von bis zu 120 MB/Sekunde.<br />
Im November 2006 kündigte <strong>IBM</strong> in der LTO4Reihe die<br />
<strong>IBM</strong> TS2240 als externes LTO4Laufwerk mit halber Bauhöhe<br />
(Half High) als weitere Option zu FullHighLaufwerken an.<br />
Das halbhohe LTO4Laufwerk ist als ‘Stand Alone’Laufwerk<br />
oder ‘Rackmounted’ erhältlich. Im Gegensatz zu LTO3 erzielen<br />
die halbhohen LTO4Laufwerke dieselben Datenraten<br />
(120 MB/s) wie die Laufwerke mit voller Bauhöhe. Für die<br />
Produktion der halbhohen LTO4Laufwerke nahm <strong>IBM</strong> Mitte<br />
2006 ein neues Fertigungswerk in Singapur in Betrieb.<br />
Viele Elemente aus der Produktion der Laufwerke mit voller<br />
Bauhöhe wurden dort übernommen, sodass sicher gestellt<br />
ist, dass die halbhohen Laufwerke in Qualität und Sicherheit<br />
einem extrem hohen Maßstab gerecht werden.<br />
Im Februar 2008 gab <strong>IBM</strong> bekannt, dass die halbhohen<br />
LTO4-Laufwerke im TS3100 Autoloader und in der TS3200<br />
Library integriert werden können. Anstelle von einem ganz<br />
hohen Laufwerk können zwei halbhohe Laufwerke eingebaut<br />
werden. Damit fasst der Autoloader TS3100 bis zu zwei<br />
halbhohe LTO4Laufwerke und die Library TS3200 bis zu<br />
vier. In der TS3200 ist auch der Mischbetrieb von ganz<br />
hohen und halbhohen Laufwerken unterstützt (ein ganz<br />
hohes und zwei halbhohe Laufwerke).<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
65
66<br />
1999 bis 2005<br />
Die Epoche der Multiplattform-<strong>System</strong>e und des FibreChannel SAN und NAS<br />
Die Magstar-3590Bandentwicklung als 1/2ZollFormat lief<br />
parallel zur LTOEntwicklung, allerdings wurde dabei das<br />
ausgereifte Aufzeichnungsverfahren mit ParityInformationen<br />
beibehalten. Die MagstarEntwicklungsreihe fand im Juni 2002<br />
mit der Generation 3, den Modellen 3590-H, ihren Abschluss.<br />
Dabei wurde die LeseRückwärtskompatibilität der vorangegangenen<br />
Generation, also für Kassetten, die mit dem B oder<br />
EModell beschrieben wurden, sichergestellt.<br />
Mit dem neuen HModell schrieb man 384 Spuren in noch<br />
verdichteterer Form auf die Kassette. Für die Extended Length<br />
Cartridge bedeutete das eine Kapazität von 60 GB unkomprimiert<br />
und 180 GB komprimiert (3 :1). Die Datenrate von<br />
14 MB/s wurde beibehalten. Damit erreichte Magstar im Jahr<br />
2002 dieselbe Spurdichte wie die LTOGeneration 1 im Jahr<br />
2000.<br />
Mit dem von <strong>IBM</strong> im September 2003 neu angekündigten<br />
Kompaktlaufwerk 3592 wurde ein neues ‘Tape-Zeitalter’<br />
eingeleitet, dessen Dimension nur wenigen bis heute bewusst<br />
ist! Schaut man aber genauer auf die integrierte Technologie<br />
und auf die neue Beschichtungsart der 3592Kassetten, kann<br />
man diesen Entwicklungsschritt mit 1984 vergleichen. 1984<br />
leitete die <strong>IBM</strong> den Wechsel vom Rollenband auf die Kassettentechnologie<br />
ein. Mit der 3592Technologie, die unter dem<br />
Entwicklungsnamen ‘Jaguar’ entwickelt wurde, ergaben sich<br />
technologische Möglichkeiten für Bandkassetten und den<br />
Einsatz von Bandlaufwerken, von denen bis dahin nur geträumt<br />
werden konnte.<br />
Das Laufwerk selbst hat neben der neuen Flat-Lap-Kopf-<br />
Technik, dem neuen, angepassten Guiding <strong>System</strong> mit Roller<br />
Bearing und dem zeitgesteuerten Spurnachführungssystem<br />
mit Servobändern (alle drei Elemente sind auch im LTO2und<br />
LTO3Laufwerk integriert) erstmals PRML Encoding<br />
(Partial Response Maximum Likehood – siehe auch TechnologieAnhang)<br />
implementiert, das eine BitAbbildung von 1:1<br />
auf Band erlaubt.<br />
Das PRML Encoding hatte auf der Platte bereits 1995 Einzug<br />
gehalten, aber es war bisher nicht möglich, dieses Verfahren<br />
auf Band einzusetzen. Grundvoraussetzung für den Einsatz<br />
von PRML ist die Erzeugung von extrem gut durchmagnetisierten<br />
Bits auf dem Datenträger. Die Beschichtung der<br />
3592Kassette im Zusammenhang mit den FlatLapKöpfen<br />
mit 10fach höherer Induktionsstärke macht es möglich, solch<br />
hochqualitative Bits zu erzeugen. Die 3592Kassette ist auch<br />
das erste Medium, bei dem mit starker Induktion gearbeitet<br />
werden kann, ohne negative Erscheinungen wie z. B. weniger<br />
Kapazität zu bekommen. Damit kann man ca. 50 % mehr in<br />
der Datenspur unterbringen und so 50 % mehr an Kapazität<br />
auf Kassetten mit der gleichen Bandlänge und der gleichen<br />
Spurzahl realisieren.<br />
Die FlatLapKopfTechnik verbessert das Schreib/Lesesignal<br />
zwischen Kopf und Band, weil eine wesentlich höhere<br />
Induktion ermöglicht wird. Vor und hinter der Kopfreihe wird<br />
zusätzlich ein Unterdruck erzeugt, der Staubpartikel, die<br />
sich – aus welchen Gründen auch immer – ansammeln, entsprechend<br />
absaugt (‘Self Cleaning Machines’). Diese Kopf <br />
Technologie kam erstmals in vollem Umfang bei LTO2 zur<br />
Anwendung und wurde in weitergehender Form im neuen<br />
Laufwerk 3592 implementiert. Dadurch ist die Qualität der<br />
erzeugten Bits wesentlich höher und die Möglichkeit, die Daten<br />
wieder zu lesen, ist ziemlich unübertroffen in der Industrie.<br />
Ebenso wird dadurch sichergestellt, dass selbst bei Langzeitlagerung<br />
von Bändern nahezu kein Impulsverlust auftritt.<br />
Das ‘Surface Control Guiding <strong>System</strong>’ ermöglicht eine ganz<br />
exakte Führung der Schreib/Leseelemente über Servobänder.<br />
Die Repositionierung der Elemente auf den Servospuren<br />
erfolgt über eine Zeitsteuerung, die über vorgeschriebene<br />
Analogsignale (Analogspuren) in den Servobändern und eine<br />
Zeitmessung durchgeführt wird. Dadurch wird die Oberfläche<br />
des Bandes für die Feinführung genutzt und nicht der Randbereich<br />
des Bandes, wo bei klassischen Aufzeichnungen<br />
Servospuren aufgebracht waren. Damit lassen sich die Fehlerquellen<br />
vermeiden, die aufgrund der Bandspannung im<br />
Außenbereich auftreten können. FlatLapTechnik und das<br />
neue Guiding <strong>System</strong> wurden erstmals in den Produkten<br />
LTO2 und 3592 implementiert. PRML Encoding ist nur in der<br />
3592 realisiert, weil die neue Beschichtung der 3592Kassette<br />
Voraussetzung für dieses neue EncodingVerfahren ist.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Mit 40MB/sDatenrate und unglaublich schnellen Spul und<br />
FastSearchZeiten entpuppte sich das <strong>IBM</strong> 3592Laufwerk<br />
in dieser Zeit als das schnellste und zuverlässigste Laufwerk<br />
auf dem Weltmarkt. Eine weitere Besonderheit der Jaguar<br />
Technologie sind neue, funktionale Möglichkeiten, die sich<br />
aufgrund der 3592Beschichtung implementieren ließen, weil<br />
ein 3592Medium keine Limitierungen in der Benutzerhäufigkeit<br />
hat. Mit der Funktion ‘Virtual Back Hitch’ können viele<br />
RücksetzZeiten beim File Retrieval und alle Start/Stopp<br />
Positionierungszeiten bei einzelnen FileTransfers, die nicht<br />
sequenziell verarbeitet werden können, auf breiter Basis eliminiert<br />
werden.<br />
Klassisch arbeitet ein Laufwerk so, dass immer über den Puf<br />
ferspeicher auf Band geschrieben wird. Das Laufwerk bekommt<br />
also Daten in den Pufferspeicher und über den sogenannten<br />
FlushBufferBefehl die Instruktion, die bisher erhaltenen<br />
Daten auf Band rauszuschreiben. Ist dies geschehen, wird<br />
der FlushBufferBefehl als Tapemark in der Spur hinterlegt.<br />
Sind keine zu schreibenden Daten mehr vorhanden, stoppt<br />
das Laufwerk. Kommt wieder etwas in den Pufferspeicher<br />
mit dem entsprechenden FlushBufferBefehl, kann der Befehl<br />
nicht sofort ausgeführt werden, weil das Laufwerk ja gestoppt<br />
hat. Das Laufwerk muss jetzt zurücksetzen, um an dem Tapemark,<br />
der zuletzt geschrieben wurde, in der Streaminggeschwindigkeit<br />
zu sein, in der der FlushBufferBefehl durchgeführt<br />
werden kann. Dieses Zurücksetzen wird als Backhitch<br />
bezeichnet. Ein Backhitch ist also nichts ‘Gutes’, da er Zeit<br />
benötigt und das Band zusätzlich (vor allem im Außenbereich)<br />
stresst. Mit Virtual Backhitch werden in der 3592 solche Positionierungsvorgänge<br />
auf den minimalsten Level eingegrenzt!<br />
Wie funktioniert nun Virtual Backhitch: Stellt die Control Unit<br />
aufgrund der Pufferspeicherauslastung fest, dass nicht mehr<br />
im Streamingmodus gearbeitet werden kann, schreibt das<br />
Laufwerk in die momentane Spur eine sogenannte RABF<br />
Marke. RABF steht für Recursive Accumulative Backhitchless<br />
Flush. Die RABFMarke verweist einfach in ein Spurset, das<br />
vor einem liegt und eigentlich zum Schreiben noch gar nicht<br />
vorgesehen ist. In diesem neuen Spurset streamt das Laufwerk<br />
einfach weiter, d. h., tröpfelt etwas in den Pufferspeicher<br />
rein, wird zeitgleich eine Kopie auf Band in dem Spurset<br />
erzeugt, das noch nicht zum Schreiben vorgesehen ist. Da<br />
einfach weitergestreamt wird, unabhängig davon, ob Daten<br />
kommen oder nicht, können natürlich regelrechte ‘Löcher’<br />
zwischen den tatsächlich weggeschriebenen Daten entstehen.<br />
Den ganzen Vorgang könnte man auch als ‘Nonvolatile<br />
Caching auf Tape’ bezeichnen, da parallel auf Band und in<br />
den Pufferspeicher geschrieben wird. Das Band stellt den<br />
stromunabhängigen NVSSchreibspeicher dar und der Pufferspeicher<br />
den Cache. Geht der Cache aus irgendwelchen<br />
Gründen kaputt, kann jedes Laufwerk trotzdem die auf Band<br />
geschriebenen Daten verarbeiten, da der Hinweis auf das<br />
Spurset über die RABFMarke sichergestellt ist.<br />
Ist der Pufferspeicher nun zu 50 % voll oder kommt das<br />
Lauf werk ans Bandende, dreht das Laufwerk um und<br />
schreibt zurück. Ist der Pufferspeicher voll, wird der<br />
gesamte Pufferspeicher nun sequenziell in das richtige<br />
Datenspurset herausgeschrieben. Danach wird der Verweis<br />
der RABFMarke aufgelöst, so, als ob nichts geschehen<br />
wäre. Virtual Backhitch oder Nonvolatile Caching auf Tape<br />
ist eine geniale TapeFunktionalität, weil Repositionierungszeiten<br />
eingespart werden und zusätzlicher Bandstress vermieden<br />
wird.<br />
Das 3592-Laufwerk selbst hat noch nie dagewesene<br />
Schock- und Vibrationseigenschaften und kann selbst bei<br />
hohen Erschütterungen noch sauber schreiben und lesen.<br />
Dies wurde durch eine selbstkalibrierende Aufhängung des<br />
Laufwerks im Gehäuse realisiert.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
67
68<br />
1999 bis 2005<br />
Die Epoche der Multiplattform-<strong>System</strong>e und des FibreChannel SAN und NAS<br />
Im November 2005 wurde die zweite Generation der Jaguar<br />
Laufwerke verfügbar. Die 3592 Generation 2, die Marketing<br />
seitig als TS1120Laufwerk (TS steht für Tape <strong>System</strong>)<br />
bezeichnet wird, war und ist das erste Bandlaufwerk, das<br />
mit zwei 4-Gbit-FibreChannel-Schnittstellen angesteuert<br />
wird und dadurch auf komprimierter Basis eine Datenrate<br />
von 260 MB/s realisiert. Die bisher verwendete 8SpurTechnik<br />
wurde auf 16SpurTechnik umgestellt und die Induktion<br />
der Köpfe wurde nochmals verdoppelt, sodass noch ‘bessere’<br />
Bits auf dasselbe Medium geschrieben werden können. Die<br />
mit kurzer Bandlänge gestaltete 60GBKassette wird beim<br />
Beschreiben mit der zweiten Generation zur 100GBKassette<br />
und die 300GBKassette wird zur 500GBKassette. Jaguar 2<br />
schreibt mit einer unglaublichen Datenrate von 100 MB/s<br />
896 Spuren auf die 3592Kassetten. Aufgrund der extrem<br />
gut erzeugten Streufelder von Bits und Tapemarks konnte<br />
die StreamingGeschwindigkeit beim High Speed Search auf<br />
10 ms erhöht werden. Das heißt, das Band spult bei einer<br />
FileAnforderung mit 36 km in der Stunde vor. Diese hohe<br />
Geschwindigkeit ist einmalig im Markt und erlaubt trotz hochkapazitiver<br />
Kassetten durchschnittliche Zugriffszeiten von<br />
27 Sekunden (100GBKassette) und 46 Sekunden (500GB<br />
Kassette). Auch der Stromverbrauch konnte auf 46 Watt reduziert<br />
werden. Vergleichbare Laufwerke benötigen heute<br />
das Doppelte an Strom.<br />
Auch die einmalige Funktion des Virtual Backhitch wurde<br />
durch die Verwendung eines 512 MB großen Pufferspeichers<br />
(Generation 1 hatte Pufferspeicher) mit 128 MB und durch<br />
zwei eingebaute Control Units weiter optimiert.<br />
Im Vergleich zu LTO bietet die JaguarTechnologie neben<br />
überschreibbaren Kassetten auch WORM(Write Once Read<br />
Many)Kassetten an. 3592-WORM-Kassetten sind hochprei<br />
siger im Vergleich zu LTO3WORMKassetten, bieten aber<br />
neben allen WORMSicherheiten den Vorteil, dass das Fortschreiben<br />
immer möglich ist, auch wenn in dem Bereich,<br />
wo fortgeschrieben werden muss, fehlerhafte Spuren oder<br />
Spurbereiche vorkommen sollten. Dies wird dadurch sichergestellt,<br />
dass bei 3592Kassetten auf den Servobändern<br />
nicht nur die WORMKennzeichnung aufgebracht wird, sondern<br />
zusätzlich sogenannte Appendflags, die für die Fehlerkorrektur<br />
herangezogen werden. LTO3WORMKassetten<br />
arbeiten ohne Appendflags, d. h., gibt es beim Fortschreiben<br />
der Kassette fehlerhafte Bereiche, dann lässt sich die<br />
LTOWORMKassette einfach nicht mehr weiterschreiben.<br />
Ende Oktober 2006 kündigte <strong>IBM</strong> eine neue 700-GB-Kas-<br />
sette für die TS1120Laufwerke an. Damit stehen jetzt drei<br />
Kassetten (überschreibbar und als WORM) zur Verfügung:<br />
Die 100GBKassette mit 120 Meter Bandlänge, die 500GB<br />
Kassette mit 609 Meter Bandlänge und die neue 700GB<br />
Kassette mit 825 Meter Bandlänge.<br />
Mit der Markteinführung von LTO im Jahr 2000 kündigte <strong>IBM</strong><br />
ein neues Bandarchiv, die <strong>IBM</strong> 3584, für den unternehmensweiten<br />
Einsatz im Open<strong>System</strong>sBereich an. Im Laufe der<br />
Folgejahre wurde die 3584 Library maßgeblich erweitert.<br />
Heute stellt sie die strategische Library-Plattform der <strong>IBM</strong><br />
dar. Seit Juni 2005 wird neben den Open<strong>System</strong>sPlattformen<br />
auch die zSeries (Mainframe) als Serverplattform unterstützt.<br />
Sie machen aus der 3584 ein Bandarchiv, das unternehmensweit<br />
für alle Rechnerplattformen eingesetzt werden kann und<br />
das aufgrund der hohen Leistungsfähigkeit und Flexibilität<br />
alle vergleichbaren Archivprodukte auf dem Markt in den<br />
Schatten stellt.<br />
<strong>IBM</strong> TS1120(3592 Generation 2)-Bandlaufwerk der Spitzenklasse <strong>IBM</strong> 3592 WORM-Kassetten in platingrauer Farbe und WORM-Labels<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
<strong>IBM</strong> 3584 Grundeinheit mit Ein-/Ausgabestation<br />
Auf der CeBIT in Hannover sorgte die 3584 immer wieder<br />
für viele Menschentrauben. Viele können es nicht fassen,<br />
dass es technisch möglich ist, einen Roboter mit dieser<br />
wahnsinnig schnellen Geschwindigkeit zu betreiben. Bei<br />
einer Roboter-Service-Zeit von unter 3 Sekunden in einer<br />
2FrameKonfiguration (Kassette holen, in ein Bandlaufwerk<br />
laden, Kassette aus einem anderen Bandlaufwerk entladen<br />
und ins Fach zurückbringen) ist es fast nicht möglich, die bewegten<br />
Kassetten mit dem bloßen Auge zu sichten. Schneller<br />
geht es wirklich nicht mehr!<br />
Diese Geschwindigkeit ist möglich, weil sich ein neu entwi-<br />
ckelter Greifer (<strong>IBM</strong> Patent) in die LTO und 3592Kassetten<br />
in dort angebrachte Einkerbungen einhakt, die Kassetten in<br />
einen Schacht zieht und der Greifer so lange verhakt bleibt,<br />
bis die Kassetten in ein Laufwerk oder an einen Stellplatz<br />
zurückgebracht werden. Die Kassette kann also auch bei<br />
höchsten Geschwindigkeiten oder schnellsten Drehungen<br />
nicht verloren gehen. Alle Roboterbewegungen sind Servokontrolliert,<br />
um diesen Geschwindigkeiten Rechnung zu tragen.<br />
<strong>IBM</strong> 3584 Doppelgreifer<br />
In dem 3584 Archiv können sowohl LTOLaufwerke und<br />
Kassetten als auch 3592Laufwerke und Kassetten betrieben<br />
werden. Ebenso ist der Mischbetrieb in getrennten Frames<br />
möglich.<br />
Wie schon bei der älteren 3494 Library früher eingeführt,<br />
wurde das <strong>System</strong> im Frühjahr 2005 so erweitert, dass es mit<br />
zwei Robotersystemen betrieben werden kann, wobei der<br />
zweite Roboter immer im Active Mode betrieben wird. Dabei<br />
werden Zahlen von weit über 1.000 Mounts in der Stunde<br />
erzielt. Des Weiteren kann die 3584 mit zwei Robotersystemen<br />
nahezu unterbrechungsfrei mit Frames erweitert werden (max.<br />
60 Sekunden, wobei kein Roboter Command verloren gehen<br />
kann).<br />
Seit Mai 2005 kann das 3584 Archiv auch an zSeries-Ser-<br />
ver angebunden werden. Dies gilt ausschließlich für den<br />
Betrieb von 3592Laufwerken und wurde dadurch realisiert,<br />
dass an der 3584 jetzt mehrere Library Manager 3953 L05<br />
und J70 ESCON/FICON Controller betrieben werden können.<br />
Im Gegensatz zur 3494 Library sind die Library Manager<br />
und J70 Controller nicht mehr in die Library Frames integriert,<br />
sondern werden in externen Frames 3953 F05<br />
installiert und an die Library angeschlossen. Dies bietet eine<br />
wesentlich höhere Konfigurationsflexibilität. Die 3584 unterstützt<br />
bis zu vier Library Manager und damit die Anbindung<br />
von bis zu acht Virtual Tape Servern (3494B10/B20).<br />
Bei VTSSpiegelungen (Peer to Peer VTS) kann jetzt auf der<br />
primären Seite eine 3494 Library und auf der sekundären<br />
Seite eine 3584 Library oder umgekehrt stehen, d. h., im<br />
VTSPeertoPeerSpiegelBetrieb ist der Mischbetrieb beider<br />
Libraries möglich.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
69
70<br />
1999 bis 2005<br />
Die Epoche der Multiplattform-<strong>System</strong>e und des FibreChannel SAN und NAS<br />
Für den Betrieb von NativeLaufwerken an zSeries<strong>System</strong>en<br />
gibt es fast keine Limitierungen, da in der 3584 bis zu 64 x<br />
J70Controller mit bis zu 192 Laufwerken konfiguriert werden<br />
können.<br />
Das 3584 Archiv bietet in jeglicher Hinsicht maßgebliche Vorteile<br />
im Vergleich zu herkömmlichen Libraries. Eine Multipfad-Architektur<br />
mit direkter Anbindung von LTO und 3592<br />
FibreChannelLaufwerken ermöglicht das logische Partitionieren<br />
der Library (bis zu 192 Partitionen). Ebenso stehen die<br />
Optionen ‘Control Path Failover’ und ‘Data Path Failover’<br />
zur Verfügung. Mit der Funktion ALMS (Advanced Library<br />
Management <strong>System</strong>) können die logischen Partitionen<br />
dynamisch vergrößert und verkleinert werden, unabhängig<br />
davon, wo die Laufwerke oder die Kassetten in der Library<br />
untergebracht sind.<br />
Die WWN(World Wide Name)Adresse ist den Laufwerk<br />
schlitten zugeordnet und erlaubt einen Laufwerkaustausch,<br />
ohne dass neu ‘gebootet’ werden muss.<br />
Mit der Anbindung der 3584 an zSeriesServer signalisierte<br />
<strong>IBM</strong> klar, dass die 3584 mit ihrem einzigartigen Robotersystem<br />
die strategische LibraryPlattform für zukünftige Weiterentwicklungen<br />
darstellt. Von dieser Weiterentwicklung profitiert<br />
aber auch die 3494 Library, die alle Erweiterungen erhält,<br />
die am Library Manager entwickelt werden. Ebenso wird die<br />
3494 neben der 3584 alle geplanten neuen Laufwerkgenerationen<br />
des 3592Laufwerks integrieren (SOD vom Mai 2005).<br />
Im Mai 2006 wurde die <strong>IBM</strong> 3584 im Zuge der FrameUmstellungen<br />
auf 4-Gbit-FibreChannel-Technologie in TS3500<br />
(TS steht für Tape <strong>System</strong>) umbenannt und es stehen entsprechende<br />
neue Frames zur Verfügung. Die Library <strong>IBM</strong><br />
3584 bzw. TS3500 wird von <strong>IBM</strong> selbst produziert. Mit der<br />
Umstellung auf 4GbitTechnologie wurde auch die RoHS-<br />
Konformität des TS3500 LibraryProduktes bekannt gegeben.<br />
Ebenso wurden die bis dahin verwendeten J70-Steuereinheiten,<br />
die für die Anbindung von TS1120Laufwerken an<br />
den Mainframe benötigt wurden, durch neue RoHSkonforme<br />
leistungsstärkere C06-Steuereinheiten mit 4GbitFICON<br />
Anschlüssen ersetzt. RoHS steht für ‘Restriction of Hazardous<br />
Substances’ und stellt ab dem 1. Juli 2006 eine gesetzlich<br />
kontrollierte EURichtlinie dar, die genau vorschreibt, welche<br />
Materialien, Legierungen, BariumDerivate etc. in Neuprodukten<br />
eingesetzt werden dürfen. Diese neue Richtlinie gilt<br />
EUweit und betrifft alle Neuprodukte in der Elektro und IT<br />
Industrie, die ab dem 1. Juli 2006 neu vertrieben werden.<br />
Im mittleren und unteren <strong>System</strong>segment produzierte <strong>IBM</strong><br />
keine eigenen Libraries, sondern kaufte die ‘nackten’ Libraries<br />
über OEMVerträge ein, um sie dann mit <strong>IBM</strong> LTOLaufwerken<br />
auszustatten.<br />
<strong>IBM</strong> 3583 Modelle L18, L36 und L72, Kapazität mit LTO1-Kassetten bis<br />
7,2 TB (native), ADIC vertrieb unter ADIC Logo das Produkt als Scalar 100<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Mit der Ankündigung der ersten LTOLaufwerke im Jahr 2000<br />
wurden auch OEM Libraries und Autoloader angekündigt,<br />
die nach dem Umbau/Ausbau als <strong>IBM</strong> LogoProdukt weiter<br />
vertrieben wurden. So wurden 1999 ein Autoloader der Firma<br />
ADIC als <strong>IBM</strong> 3581Produkt und ein mittleres Archivsystem<br />
auch von ADIC als <strong>IBM</strong> 3583 eingeführt. Der Autoloader war<br />
mit einem LTOSCSILaufwerk (LVD oder HVD) ausgestattet<br />
und konnte bis zu acht LTOKassetten verwalten. Das Archivsystem<br />
3583 konnte mit sechs LTOLaufwerken ausgestattet<br />
werden und je nach Modell 18 Kassetten, 36 und 72 Kassetten<br />
verwalten. Am Anfang wurden ausschließlich SCSILaufwerke<br />
eingebaut. Um die Library an ein FibreChannelNetz<br />
anschließen zu können, wurden über ein eingebautes FCAL<br />
Gateway die bis zu sechs SCSILaufwerke ‘daisy chained’<br />
angeschlossen.<br />
Diese FibreChannelAnschlussweise der <strong>IBM</strong> 3583 verursachte<br />
bei bestimmten HostFibreChannelAdaptern Adressierungsprobleme.<br />
Deshalb wurde im Mai 2003 in der 3583<br />
ein eigener <strong>IBM</strong> Controller eingebaut, der durch eine MultipfadArchitektur<br />
erlaubte, direkt FCLaufwerke in der Library<br />
zu betreiben und die Library zu partitionieren. Bis zu drei<br />
logische Partitionen waren in der 3583 möglich.<br />
Im Mai 2004 wurde dieses MidrangeLibraryPortfolio ergänzt<br />
durch eine MiniLibrary, die <strong>IBM</strong> 3582. Die Library ist ein<br />
OEM Produkt der Firma ADIC. Sie ist ausgestattet mit dem<br />
<strong>IBM</strong> Controller für die Anbindung von FCLTOLaufwerken<br />
und bietet die Möglichkeit, mit zwei logischen Partitionen<br />
betrieben zu werden.<br />
In die MiniLibrary wurden 1 bis 2 LTOLaufwerke eingebaut<br />
und es konnten bis zu 23 Kassetten verwaltet werden. Neun<br />
Kassetten hatten fest eingebaute Stellplätze, die anderen<br />
14 Stellplätze wurden über zwei herausnehmbare 7erKassettenmagazine<br />
abgedeckt.<br />
Im Mai 2006 wurde der OEMAutoloader von ADIC durch<br />
einen neuen Autoloader der Firma BDT <strong>IBM</strong> 3581 ersetzt,<br />
der auch bis zu acht Kassetten verwalten konnte, aber in<br />
Flachbauweise konstruiert war und dadurch sehr platzsparend<br />
in ein Standard19ZollRack integriert werden konnte.<br />
Auch bei der MidrangeLibraryReihe musste bis 30. Juni<br />
2006 die Umstellung auf die neue, ab 1. Juli 2006 geltende<br />
EURoHSRichtlinie durchgeführt werden.<br />
Die Library 3583 wurde bereits im Oktober 2005 durch eine<br />
neue Library TS3310 ersetzt. Die TS3310 stammt auch aus<br />
dem Haus ADIC, hatte vorbereitete 4GbitTechnologie integriert<br />
und war zum Verfügbarkeitszeitraum RoHS-konform.<br />
Am Anfang konnte die Library nur mit der Grundeinheit, einer<br />
Erweiterungseinheit und bis zu sechs LTO3Laufwerken und<br />
122 Kassettenstellplätzen konfiguriert werden, im Mai 2006<br />
wurden dann die Erweiterungen bis zum Maximalausbau mit<br />
bis zu vier Erweiterungseinheiten und damit bis zu 18 LTO3<br />
Laufwerken und bis zu 398 Kassettenstellplätzen bekannt<br />
gegeben. <strong>IBM</strong> verwendet bei dieser neuen Library wiederum<br />
einen eigenen FCController für die Anbindung der Laufwerke.<br />
Damit ist die Library partitionierbar und es können<br />
bis zu 18 logische Partitionen betrieben werden. Die Zuordnung<br />
von Laufwerken und Stellplätzen auf logische Partitionen<br />
ist wesentlich flexibler als beim Vorgänger 3583.<br />
<strong>IBM</strong> 3581 Modelle L28 und F28, Autoloader der Firma BDT <strong>IBM</strong> 3582 Mini-Library mit bis zu 23 LTO-Kassetten.<br />
ADIC vertrieb unter ADIC-Logo das Produkt als Scalar 24<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
71
72<br />
1999 bis 2005<br />
Die Epoche der Multiplattform-<strong>System</strong>e und des FibreChannel SAN und NAS<br />
Die neue <strong>IBM</strong> Midrange Library <strong>IBM</strong> TS3310 mit bis zu 18 LTO3-Laufwerken<br />
und maximal 398 Kassettenstellplätzen, hier mit einem Erweiterungsframe.<br />
ADIC vertreibt unter ADIC-Logo das Produkt als ADIC 500i<br />
Im Zuge der gesamten RoHSUmstellung wurde sowohl der<br />
Autoloader von BDT <strong>IBM</strong> 3581 als auch die MiniLibrary von<br />
ADIC <strong>IBM</strong> 3582 durch neue Produkte der Firma BDT ersetzt.<br />
Die 3581 wurde durch die <strong>IBM</strong> TS3100 ersetzt, ein neuer<br />
Autoloader mit einem 4GbitFibreLTO3Laufwerk und bis zu<br />
22 Kassettenstellplätzen. Die MiniLibrary 3582 wurde durch<br />
die <strong>IBM</strong> TS3200 ersetzt, die bis zu zwei 4-Gbit-LTO3Laufwerke<br />
und bis zu 44 Kassetten aufnehmen kann. Die TS3200<br />
besitzt dieselbe Partitioniermöglichkeit wie ihr Vorgänger.<br />
Damit sind alle LibraryProdukte und Bandlaufwerke, die <strong>IBM</strong><br />
vertreibt, durchgängig auf 4-Gbit-Technologie umgestellt<br />
und entsprechen der EU-RoHSRichtlinie, die am 1. Juli 2006<br />
für Neuprodukte in Kraft getreten ist.<br />
Tape-Virtualisierung im Open-<strong>System</strong>s-Umfeld<br />
TapeVirtualisierung war bisher nur im MainframeUmfeld<br />
sinnvoll (siehe VTS Virtual Tape Server). Mit der Zunahme<br />
der Geschwindigkeit und der Datenrate, wurde es immer<br />
schwieriger, die Geschwindigkeit solcher Laufwerke auch<br />
maximal auszunutzen. Ein LTO3Laufwerk arbeitet heute mit<br />
80 MB/s, ein JaguarLaufwerk TS1120 sogar mit 100 MB/s<br />
(native). Um diese hohen Laufwerkgeschwindigkeiten auch<br />
maximal nutzen zu können, werden zunehmend Plattenpuffer<br />
als Zwischenspeicher eingesetzt. Um eine geeignete,<br />
sinnvolle BackupKonzeption zu etablieren, muss zwischen<br />
dem klassischen Backup über das IPNetz (LAN-Backup)<br />
und dem LAN-free-Backup, wo die Daten über ein Fibre<br />
ChannelNetz (SAN) auf die Bandlaufwerke über tragen<br />
werden, unterschieden werden.<br />
Wird der Backup klassisch über das LAN gefahren, ist die<br />
sinnvollste Art einer Virtualisierung, den <strong>IBM</strong> TSM (Tivoli<br />
<strong>Storage</strong> Manager) einzusetzen, über den TSMServer auf<br />
einen Plattenpuffer zu sichern und unter Kontrolle des TSM<br />
vom Plattenpuffer auf Band zu migrieren. Diese Funktionalität<br />
hat der TSM schon seit vielen Jahren. Auf diese Weise<br />
können die hohen Geschwindigkeiten der Laufwerke genutzt<br />
werden. Der Vorteil dieser Lösung liegt in der Automation, weil<br />
man alle PolicyRegeln des TSM entsprechend nutzen kann.<br />
Im LANfreeBereich macht eine Virtualisierung dann Sinn,<br />
wenn viele LANfreeClients betrieben werden, denn jeder<br />
LANfreeClient benötigt ein dediziertes Bandlaufwerk. Betreibt<br />
ein Rechenzentrum den Backup mit vielen LANfreeClients,<br />
benötigt man dieselbe Anzahl an physikalischen Laufwerken,<br />
und das kann teuer werden. Hier machen virtuelle Bandarchive<br />
Sinn, weil man viele virtuelle Laufwerke zur Verfügung<br />
hat. Um diesem Umstand gerecht zu werden, kündigte <strong>IBM</strong><br />
im Oktober 2005 das virtuelle Bandsystem TS7510 für Open<br />
<strong>System</strong>sUmgebungen an.<br />
<strong>IBM</strong> TS3200<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Band-Virtualisierung für Open <strong>System</strong>s (Virtual Tape Library VTL)<br />
Das virtuelle Bandarchiv TS7510 besteht aus mehreren<br />
wichtigen Komponenten und ist Serverbasierend aufgebaut.<br />
Als Server werden xSeriesRechner mit einem LinuxKernel<br />
eingesetzt. Die Maschine kann mit einer (Single) oder zwei<br />
xSeries (DualServerKonfiguration) ausgestattet werden. Die<br />
DualServerKonfiguration bietet die Möglichkeit des ‘Active<br />
Failover und Failback’. Die eingesetzten Server stellen die<br />
virtuelle Einheit dar und emulieren virtuelle Bandlaufwerke.<br />
Bis zu 512 virtuelle Laufwerke werden pro Rechnereinheit<br />
emuliert. Bei einer DualServerKonfiguration werden bis zu<br />
1.024 virtuelle Laufwerke emuliert. Abgebildet werden LTO2,<br />
LTO3 und 3592(Jaguar 1)Laufwerke. Es stehen bis zu 128<br />
virtuelle Libraries und bis zu 8.192 virtuelle Volumes zur Verfügung,<br />
also pro Rechnereinheit 64 virtuelle Libraries und<br />
4.096 virtuelle Volumes.<br />
Geschrieben wird in einen Plattenpufferspeicher. Hierzu sind<br />
in dem Gehäuse zwei PlattenController und entsprechende<br />
Plattenerweiterungseinschübe auf Basis der DS4000 eingebaut.<br />
Das erste Frame wird mit einem zweiten Frame erweitert,<br />
wenn größere Kapazitäten notwendig werden. Die Minimalkonfiguration<br />
erlaubt 5 TB nutzbaren Plattenplatz und kann<br />
auf die maximale Konfiguration von bis zu 46 TB ausgebaut<br />
werden. Insgesamt stehen acht 2GbitPorts zur Verfügung,<br />
vier für den Plattenzugriff und vier für den Host und die physikalischen<br />
Bandlaufwerke. Spiegelungen der Maschine<br />
können über zwei 1GbitEthernetPorts über das IPNetz<br />
durchgeführt werden (RemoteReplikation). Dabei kann mit<br />
Compression und Encryption als Zusatzoptionen gearbeitet<br />
werden.<br />
Vituelle Tape Library <strong>IBM</strong> TS7510<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
73
74<br />
1999 bis 2005<br />
Die Epoche der Multiplattform-<strong>System</strong>e und des FibreChannel SAN und NAS<br />
Archivierungslösungen<br />
Archivierung von Informationen ist schon ein sehr altes<br />
Thema, denkt man an die Höhlenmalereien der Grotte Chauvet<br />
im Vallon Pont d’Arc in Südfrankreich, die auf ca. 31.000<br />
Jahre geschätzt werden – die wohl erste Überliefung von<br />
Informationen aus Menschenhand.<br />
Die Techniken, der Nachwelt Informationen zukommen zu<br />
lassen, haben sich seitdem stets verbessert. Zunächst wurden<br />
Information in Stein gemeißelt und in Ton gebrannt, bis die<br />
Ägypter ca. 4.000 Jahre vor unserer Zeit das Papyrus – den<br />
Vorgänger des heutigen Papiers – entdeckten, um in einfacher<br />
Technik, Informationen darauf festzuhalten. Mit fortschreitender<br />
Technik war es nun auch möglich, mehr Informationen<br />
zu speichern und der Nachwelt zu hinterlassen. Denken<br />
wir nur an das Alte Testament, das einen Zeitraum von ca.<br />
2.000 Jahren vor Christi Geburt umfasst und aus insgesamt<br />
zwölf Büchern besteht.<br />
Mit der Erfindung des Buckdrucks durch Johannes Gutenberg<br />
aus Mainz, Mitte des 15. Jahrhunderts, war es dann<br />
auch möglich, Informationen einfach zu vervielfältigen, was<br />
zu vielen interessanten Überlieferungen beigetragen hat und<br />
natürlich auch zum Wachstum an Informationen.<br />
Entwicklung der optischen Technologien in den 90er-Jahren<br />
Bereits 1982 gründeten <strong>IBM</strong> und Sony eine Entwicklungsallianz<br />
mit dem Ziel, optische Technologien gemeinsam weiter zuentwickeln.<br />
So enstanden im ITUmfeld Anfang der 90er<br />
Jahre optische Archivierungsmöglichkeiten, sogenannte ‘Juke’<br />
Boxen mit optischen Platten und entsprechenden Schreib/<br />
Lesegeräten, die sich in dieser Zeit auch als Archivierungseinheiten<br />
zur Langzeitarchivierung durchsetzten. Es etablierten<br />
sich drei unterschiedliche optische Medien, die WORM-Platte<br />
(Write Once Read Many), die magneto-optische Platte MO<br />
und die ‘ScheinWORM’Platte, die sogenannte CCW(Contin<br />
uous Composite WORM)-Platte, eine magnetooptische<br />
Platte, die bei der Herstellung eine Kennzeichnung bekommt,<br />
die sicherstellt, dass das Medium nicht versehentlich überschrieben<br />
wird.<br />
Bereits 1992 begann man, die für die ITBranche entwickelten<br />
Formate WORM, MO und CCW, basierend auf der RoteLaser<br />
Technik, zu standardisieren. Ein ISOStandardisierungsgremium<br />
bildete sich und selbst der deutsche DIN bildete den<br />
NI23Arbeitskreis, einen Ausschuss des deutschen DIN zur<br />
Normierung von optischen Datenträgern, der der internationalen<br />
ISO direkt zuarbeitete und seine entsprechende Position<br />
abgab. Die als 1 x Standard verabschiedete ISONorm<br />
reflektierte eine 650GBPlatte in allen drei Formaten, mit dem<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
><br />
><br />
>
<strong>IBM</strong> 3995 optisches Archivierungssystem mit den einzelnen Modellvarianten mit 8 x Standard<br />
2 x Standard kam die 1,3GB, mit dem 4 x Standard die<br />
2,6GBPlatte. 1998 wurde der letzte Standard als 8 x Standard<br />
verabschiedet, der immer noch auf dem roten Laser<br />
basierte. Der 8 x Standard bot auf allen drei Formaten<br />
5,2 GB Kapazität pro Platte.<br />
Um Rückwärtskompatibilität zu gewährleisten, war der Standard<br />
so gestaltet, dass Medien des 1 x Standards sowohl<br />
lese als auch schreibmäßig von Schreib/Lesegeräten des<br />
2 x Standards verarbeitet werden konnten und selbst der<br />
4 x Standard noch in der Lage war, Medien des 1 x Standards<br />
zu lesen. Mit dem 8 x Standard kam der Bruch, da nicht mehr<br />
vorgesehen war, Medien des 1 x Standards auf Schreib/<br />
Lesegeräten des 8 x Standards verarbeiten zu können.<br />
Mitte der 90erJahre wurde die WORMPlatte – vom Gesetz<br />
geber anerkannt für viele Archivierungsanforderungen – mit<br />
einer Haltbarkeit von 300 Jahren spezifiziert. Viele Unternehmen<br />
gingen dazu über, Langzeitarchivierung auf diesen<br />
optischen JukeBoxen zu betreiben. <strong>IBM</strong> bot auf diesem<br />
Gebiet das <strong>IBM</strong> 3995 optische Archivsystem an.<br />
Nach der Verabschiedung des 8 x Standards passierte viele<br />
Jahre nichts mehr bezüglich einer sinnvollen Standardisierung.<br />
Dies lag darin begründet, dass ein 16 x Standard technisch<br />
nicht realisierbar war, da der rote Laser in diesem Bereich<br />
eine Streuung zeigte, die es nicht zuließ, auf einem nach<br />
8 x Standard erzeugten Pit durch Optimierung der Laserfrequenz<br />
4 Pits unterzubringen. Auch trug der technologische<br />
Wechsel zur BlaueLaserTechnik (auch ‘Blue Ray’ genannt)<br />
dazu bei, dass ein noch realisierbarer Standard in Rote<br />
LaserTechnik als 12 x Standard nicht weiterverfolgt wurde.<br />
Hier noch ein wichtiger Hinweis, der zeigt, wie tief <strong>IBM</strong> in<br />
der Entwicklung von optischen Technologien engagiert war.<br />
Der heutige blaue Laser ist ein <strong>IBM</strong> Patent, das aus einer<br />
gemeinsamen Entwicklung von <strong>IBM</strong> und Sony hervorging.<br />
Im Jahr 2000 ergab sich in Deutschland eine massive Ände<br />
rung für die Langzeitarchivierung. Die GDPdURichtlinie<br />
wurde verabschiedet und im Jahr 2001 nochmals genauer<br />
verifiziert. Diese Richtlinie nahm Abschied von der Vorgabe,<br />
bei bestimmten aufzubewahrenden Daten optische WORM<br />
Medien zu verwenden. Damit war der Weg frei, neue Lösungskonzeptionen<br />
zu entwickeln, die nicht unbedingt auf optischen<br />
Technologien aufgebaut sind.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
75
76<br />
1999 bis 2005<br />
Die Epoche der Multiplattform-<strong>System</strong>e und des FibreChannel SAN und NAS<br />
Wenn die Archivierung gesetzlichen Bestimmungen und<br />
Anforderungen unterliegt, spricht man auch von revisionssicherer<br />
Archivierung. In vielen Bereichen erkennt der Gesetzgeber<br />
die digitale Archivierung als revisionssicher an, stellt<br />
aber gleichzeitig auch Anforderungen an die Art und Weise<br />
der Archivierung. In Deutschland gibt es z. B. die Grundsätze<br />
zum Datenzugriff und zur Prüfbarkeit digitaler<br />
Unterlagen (GDPdU). Viele Gesetze und Bestimmungen<br />
stellen allgemeine Anforderungen an die revisionssichere<br />
Archivierung. Zumeist werden die Aufbewahrungszeiträume<br />
von archivierten Daten vorgeschrieben. Weiterhin muss<br />
sichergestellt sein, dass die Daten im digitalen Archiv nicht<br />
verändert oder gelöscht werden können – in einer Welt mit<br />
zwei bis drei neuen Computerviren pro Tag gar keine so<br />
einfache Sache. Einige Bestimmungen schreiben auch vor,<br />
Kopien der Originaldaten in getrennten Räumen zu erstellen.<br />
Revisionssicherheit bedeutet natürlich auch, dass die Integrität<br />
der Daten zu jeder Zeit nachweislich gewährleistet ist.<br />
Es muss also auch anhand von Protokollen nachgewiesen<br />
werden, dass die Daten dem Original entsprechen. Die eingesetzte<br />
Technologie zur Archivierung wird aber heute von<br />
fast keinem Gesetz oder einer Bestimmung vorgeschrieben.<br />
In einigen Fällen, z. B. im medizinischen und pharmazeu<br />
tischen Bereich, müssen Daten 30 Jahre und länger archi<br />
viert werden. Eine Frage, die sich daraus ergibt, ist: Gibt es<br />
ein digitales Archiv, das auch in 30 Jahren noch Bestand<br />
hat? Eine zeitgemäße Antwort darauf ist, dass die Informationen<br />
von Zeit zu Zeit auf neue <strong>System</strong>e und Technologien<br />
überführt werden müssen. Überführung von Informationen<br />
und informationsverarbeitenden <strong>System</strong>en auf neue <strong>System</strong>e<br />
und Technologien – nachfolgend auch Migration genannt –<br />
ist heutzutage der einzige Weg, um die Daten auch in 30<br />
Jahren noch lesen zu können.<br />
Aufgrund der veränderten Bedingungen für die Langzeitarchivierung<br />
kündigte <strong>IBM</strong> das <strong>System</strong> DR450 im Oktober 2003<br />
an. Das <strong>System</strong> wurde mit Standardkomponenten aufgebaut<br />
und als Langzeitarchivierungslösung für den Open<strong>System</strong>s<br />
Bereich zur Verfügung gestellt. Die Lösung bestand aus<br />
zwei pSeriesp615Servern, die in einem hochverfügbaren<br />
HACMPCluster (AIXBetriebssystem) zusammengefasst waren.<br />
Auf diesen Servern war der <strong>IBM</strong> Tivoli <strong>Storage</strong> Manager für<br />
Data Retention aufgesetzt, der sicherstellte, dass die archivierten<br />
Dateien und Dokumente innerhalb der Aufbewahrungsfrist<br />
nicht gelöscht oder modifiziert werden. Die Daten<br />
wurden auf SATAPlatten (siehe auch TechnologieAnhang)<br />
einer FAStT600 mit EXP100Erweiterungseinheiten abgespeichert.<br />
Kapazitäten von 3,5 TB bis 56 TB konnten konfiguriert<br />
werden. Das Magnetplattensystem war über ein<br />
redundant ausgelegtes, FibreChannelbasierendes SAN an<br />
die Server angeschlossen. Optional konnten an diesem SAN<br />
auch <strong>IBM</strong> 3592 Bandlaufwerke mit entsprechenden WORM<br />
Kassetten und/oder überschreibbaren Kassetten betrieben<br />
werden.<br />
Bereits im Jahr 2005 kam die Weiterentwicklung der<br />
DR450 mit der DR550 auf den Markt, die im Jahr 2006 mit<br />
allen seinen Komponenten auf RoHSKonformität umgestellt<br />
wurde.<br />
Das <strong>IBM</strong> DR550<strong>System</strong> besteht heute aus den <strong>IBM</strong> Standard<br />
Software und HardwareKomponenten AIX, SSAM, pSeries<br />
p52A, den SANKomponenten 2005B16, Disk <strong>System</strong> DS4700<br />
und DiskErweiterungseinheiten EXP810. Optional kann man<br />
ein hochverfügbares DR550<strong>System</strong> bestellen. Dabei beinhaltet<br />
das <strong>System</strong> zusätzlich noch die ClusterSoftware HACMP.<br />
Der Vorteil dieses Konzepts liegt auf der Hand: Der Anwender<br />
erhält ein <strong>System</strong>, dessen Komponenten schon lange im<br />
Markt erprobt sind. Kernkomponente von DR550 ist der<br />
<strong>System</strong> <strong>Storage</strong> Archive Manager, ein Derivat vom Tivoli <strong>Storage</strong><br />
Manager for Data Retention, der jegliche Veränderung<br />
oder Löschung von Informationen verhindert und somit die<br />
revi sionssichere Speicherung erlaubt.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
In der Produktfamilie <strong>IBM</strong> <strong>System</strong> <strong>Storage</strong> DR550 gibt<br />
es drei Modelle:<br />
•<br />
•<br />
•<br />
Das DR550-Express-<strong>System</strong> ist eine Einstiegslösung, die<br />
aus einer <strong>IBM</strong> pSeries Model 52A besteht mit internen<br />
SCSI-Festplatten, die als RAID5 konfiguriert sind. Mit dem<br />
DR550 Express Model wird ein Monitor-Kit mit Keyboard<br />
und Maus geliefert sowie ein SAN Switch 2005-B16, der für<br />
den Anschluss von Tape oder einer Disk-Erwei terungseinheit<br />
vorgesehen ist. Ein DR550-Express-<strong>System</strong> erhält<br />
man mit einer Einstiegskapazität von 1,1 TB (brutto). Das<br />
<strong>System</strong> kann um 4 TB oder 8 TB (brutto) erweitert werden,<br />
durch den Anschluss eines DS4700-RAID5-<strong>System</strong>s. Ein<br />
entsprechender Einbauschrank kann optional mitbestellt<br />
werden.<br />
Das DR550-Single-Node-<strong>System</strong> besteht aus einem Einbauschrank,<br />
in dem eine <strong>IBM</strong> pSeries p52A, ein SAN Switch<br />
2005-B16, ein Disk <strong>System</strong> DS4700 und optional ein oder<br />
mehrere EXP810 eingebaut und fertig konfiguriert sind. Ein<br />
Single-Node-<strong>System</strong> kann man mit einer Festplatten-<br />
Kapa zität von 8 TB oder 16 TB bestellen und bis auf<br />
112 TB (brutto) ausbauen.<br />
Das DR550-Dual-Node-<strong>System</strong> besteht aus den gleichen<br />
Komponenten wie das Single-Node-<strong>System</strong>, mit dem<br />
Unterschied, dass alle Komponenten redundant (doppelt)<br />
ausgelegt sind. D. h., in den Einbauschrank sind zwei <strong>IBM</strong><br />
p52A und zwei SAN Switches 2005-B16 eingebaut und<br />
redundant konfiguriert. Ein Dual-Node-<strong>System</strong> kann man<br />
mit einer Festplatten-Kapazität von 8 TB oder 16 TB bestellen<br />
und bis auf 112 TB (brutto) ausbauen. Es handelt sich<br />
hierbei um ein hochverfügbares <strong>System</strong>.<br />
Die Informationen werden innerhalb der DR550 auf Festplatten<br />
gespeichert – optional auch verschlüsselt – und erlauben<br />
schnelle Zugriffzeiten. Die Performance aus Anwendersicht<br />
kann mithilfe der MultiobjektTransaktion noch gesteigert<br />
werden, insbesondere, wenn viele Objekte mit einem Male<br />
gelesen oder geschrieben werden. Dabei werden innerhalb<br />
einer Transaktion mehrere Objekte gespeichert oder gelesen.<br />
Mandantenfähigkeit lässt sich mit SSAM auch realisieren. Das<br />
erlaubt die logische Trennung von Speicherbereichen für<br />
verschiedene Klienten und auch das Reporting von benutzter<br />
Speicherkapazität. Dabei ist sichergestellt, dass ein Klient nur<br />
auf die Daten zugreifen kann, die in seiner Partition gespeichert<br />
sind.<br />
<strong>IBM</strong> DR550 Express<br />
Die Anbindung des Archivsystems <strong>IBM</strong> DR550 an die Anwendung<br />
erfolgt über das Tivoli <strong>Storage</strong> Manager for Data Retention<br />
API (Application Programming Interface). Typische Anwendungen,<br />
die Daten auf einem DR550<strong>System</strong> zu archivieren,<br />
sind DokumentenManagement<strong>System</strong>e, wie z. B. <strong>IBM</strong> Content<br />
Manager oder EnterpriseContentManagement<strong>System</strong>e,<br />
wie z. B. Opentext Lifelink Enterprise Archive Server. Das TSM<br />
API steht dem Anwender frei zur Verfügung. Alle Anwendungen,<br />
die das TSM API implementiert haben – gleichgültig<br />
auf welcher Plattform diese Anwendung betrieben wird – können<br />
Datenobjekte auf der DR550 archivieren und lesen.<br />
<strong>IBM</strong> DR550-Dual-Node-<strong>System</strong><br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
77
1999 bis 2005<br />
Die Epoche der Multiplattform-<strong>System</strong>e und des FibreChannel SAN und NAS<br />
DR550 File <strong>System</strong> Gateway<br />
Im Mai 2007 kündigte die <strong>IBM</strong> für die DR550 ein File Sys-<br />
tem Gateway an. Über das DR550 Gateway kann ein Dateisystem<br />
aufgebaut werden, in dem die Daten vor dem Überschreiben<br />
geschützt sind. Das Gateway wird vorkonfiguriert<br />
ausgeliefert. Nach außen wird ein CIFS oder NFSDateisystem<br />
ausgegeben. Die Gateways können ‘geclusteret’ werden,<br />
um eine HAfähige (High Availability) Lösung aufzubauen.<br />
Im August 2007 stellte <strong>IBM</strong> der DR550 750-GB-SATA-Plat-<br />
ten zur Verfügung. Mit diesen neuen großen Platten kann<br />
eine DR550 auf bis zu 168 TB Kapazität ausgebaut werden.<br />
Seit August 2007 stehen mit der DR550 Komplettlösungs-<br />
pakete für die E-Mail-Archivierung zur Verfügung. Diese<br />
Komplettlösungen für Lotus Domino und Microsoft Exchange<br />
adressieren die Anforderungen kleinerer und mittelständischer<br />
Unternehmen. Das Lösungspaket aus einer Hand enthält<br />
aufeinander abgestimmte, skalierbare Software und HardwareKomponenten<br />
der <strong>IBM</strong> und kann rasch implementiert<br />
werden. Basierend auf unternehmensspezifischen Aufbewahrungs<br />
und Zugriffsprofilen, ermöglicht die Lösung eine<br />
sichere Verwaltung und Archivierung von EMails einschließlich<br />
Dateianhängen in deren gesamten Lebenszyklus. Dabei<br />
wird sowohl geschäftlichen Anforderungen als auch nationalen<br />
oder internationalen ComplianceVorschriften Rechnung<br />
getragen und ebenso den Wünschen vieler Unternehmen<br />
nach einer Optimierung des Speicherbedarfs und der<br />
Reduzierung von Administrationskosten. Das Komplettpaket<br />
zur EMailArchivierung für den SMBBereich (Small and<br />
Medium Business) ist jederzeit zu einer umfassenden Archivierungslösung<br />
erweiterbar, die sämtliche unstrukturierten<br />
Unternehmensinformationen wie z. B. digitalisierte Korres<br />
pondenz, OfficeDokumente, Faxe, Präsentationen,<br />
Audio und Videodateien etc. verwalten kann. Ebenso ist<br />
eine Anbindung an SAP zur Dokumenten und Datenarchivierung<br />
möglich. Auf diese Weise kombiniert das Komplettpaket<br />
modernste Technologie mit einem raschen ROI sowie<br />
höchster Investitions und Zukunftssicherheit.<br />
Das Komplettpaket besteht aus der benutzerfreundlichen und<br />
leistungsfähigen EMailArchivierungslösung <strong>IBM</strong> Common<br />
Store für Lotus Domino und Microsoft Exchange sowie dem<br />
<strong>IBM</strong> Content Manager als BasisRepository. Hinzu kommt ein<br />
<strong>IBM</strong> <strong>System</strong> x3650 Server mit Intel Xeon QuadcoreProzessoren,<br />
der speziell für anspruchsvolle Aufgaben im Unternehmenseinsatz<br />
wie z. B. Enterprise Content Management<br />
(ECM), Virtualisierung, Enterprise Resource Planning (ERP)<br />
oder Datenbankanwendungen entwickelt wurde. Als Speicherkomponente<br />
dient das <strong>IBM</strong> <strong>System</strong> <strong>Storage</strong> DR550, das<br />
eine leistungsfähige Funktionalität zur Ablage relevanter<br />
Dokumente gemäß gesetzlicher Aufbewahrungsfristen und<br />
vorschriften auf magnetischen Speichermedien bietet. Die<br />
DR550 unterstützt dabei eine nicht löschbare und nicht wieder<br />
beschreibbare Datenspeicherung.<br />
Im Februar 2008 machte <strong>IBM</strong> die DR550-Lösung als<br />
Maschine mit zwei Modellen DR1 und DR2 in der Version 4.5<br />
verfügbar. Dies zeigt deutlich, dass <strong>IBM</strong> stark in das Infor<br />
mationRetentionSegment investiert. Durch die erweiterte<br />
Nutzung des <strong>System</strong> <strong>Storage</strong> Archive Managers (SSAM) für<br />
policybasierten InformationRetentionBetrieb ermöglicht<br />
die DR550 eine transparente und automatisierte Bewegung<br />
archivierter Daten zwischen verschiedenen Speicherklassen.<br />
Dadurch können Kosten eingespart werden, ohne die<br />
Sicherheit der archivierten Daten zu gefährden. Das inzwischen<br />
preisgekrönte <strong>System</strong> ist jetzt als Maschine verfügbar.<br />
Es stehen zwei Modelle zur Verfügung: Die DR1 besteht aus<br />
einem 25UEinheiten großen Rack, ist vorintegriert und eignet<br />
sich besonders für mittelständische Kunden. Die DR2<br />
wurde speziell für Großunternehmen entwickelt und ist in<br />
einem größeren 36UEinheitenRack untergebracht. Die DR2<br />
bietet Single oder DualNodeKonfigurationsoptionen für<br />
höhere Verfügbarkeit und Skalierbarkeit.<br />
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<br />
erfolgt über EthernetSchnittstellen und basiert auf<br />
dem TCPIPProtokoll. Standardmäßig wird ein Ethernet Interface<br />
benutzt. Wahlweise können aber auch 2 oder mehr<br />
Ethernet Interfaces angeschlossen werden, was eine Skalierbarkeit<br />
des Datendurchsatzes erlaubt.<br />
Das TSM API im Zusammenwirken mit SSAM bietet der Anwendung<br />
verschiedene Möglichkeiten zur Kontrolle der Aufbewahrungszeit.<br />
So kann eine Anwendung unter Benutzung<br />
der Ereignisbasierenden Aufbewahrungsregel Datenobjekte<br />
mittels Event löschen. Natürlich nur unter der Bedingung,<br />
dass die konfigurierbare Mindestaufbewahrungszeit für das<br />
Datenobjekt bereits abgelaufen ist. Mithilfe der chronologischen<br />
Aufbewahrungsregel sorgt SSAM für die Löschung<br />
der Daten nach Ablauf einer festgelegten Aufbewahrungszeit.<br />
Die Aufbewahrungsregeln werden dabei in sogenannten<br />
ManagementKlassen definiert, die Anwendung weist ein<br />
Objekt dann nur noch einer ManagementKlasse zu, wodurch<br />
dem Objekt die entsprechende Aufbewahrungszeit zugeordnet<br />
wird. Mit dem zusätzlichen Löschschutz, einer weiteren<br />
Option des TSM API, kann die vordefinierte Aufbewahrungsregel<br />
für Objekte außer Kraft gesetzt werden. Damit kann<br />
verhindert werden, dass ein Objekt nach Ablauf der normalen<br />
Aufbewahrungsfrist gelöscht wird.<br />
Die DR550 bietet auch den Anschluss anderer externer<br />
Speichertechnologien wie z. B. WORM Tape oder optische<br />
Speicher. Generell wird empfohlen, dass ein externes Gerät<br />
eine NativeWORMFunktionalität besitzt, wenn es an ein<br />
DR550<strong>System</strong> angeschlossen wird.<br />
Der Anschluss von Bandlaufwerken an die DR550 erfolgt<br />
über das SAN. Die Anbindung von WORM Tape hat zwei<br />
entscheidende Vorteile für den Anwender:<br />
1. Kopien der Daten können auf WORM Tape geschrieben<br />
werden und in einem anderen Brandabschnitt<br />
katastrophen sicher aufbewahrt werden.<br />
2.<br />
Wenn die Daten auf Festplatte in der DR550 ‘altern’ und<br />
somit die Zugriffe seltener werden, können sie auf WORM<br />
Tape ausgelagert werden. Die Tapes benötigen weniger<br />
Strom, Wartung und Austausch und sind somit viel kostengünstiger<br />
als Festplatten.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang Software Anhang 79
80<br />
1999 bis 2005<br />
Die Epoche der Multiplattform-<strong>System</strong>e und des FibreChannel SAN und NAS<br />
Modell 174<br />
<strong>IBM</strong> 3996 optische Archive – 960 GB bis 10,4 TB<br />
Im Herbst 2003 wurde endlich ein neuer Standard, basierend<br />
auf dem blauen Laser, auf dem Markt verfügbar. Der neue<br />
1 x Standard reflektierte eine 30GBPlatte in den bisher<br />
klas sischen Formaten WORM, MO und CCW. Die Firma Plasmon,<br />
die auch sehr aktiv in der Standardisierung der neuen<br />
BlaueLaserTechnik mitwirkte, bot als erste Firma im Jahr<br />
2004 JukeBoxen mit den neuen optischen Platten an. Im<br />
Herbst 2005 kam ein OEM-Vertrag zwischen Plasmon und<br />
<strong>IBM</strong> zustande, der es <strong>IBM</strong> erlaubt, diese JukeBoxen unter<br />
<strong>IBM</strong> Logo zu vermarkten. Am Anfang war der Verkauf zum<br />
Anschluss an iSeriesServer beschränkt, seit Juni 2006 können<br />
die JukeBoxen auch an pSeriesbasierende Server<br />
angeschlossen werden. Mit den Modellen 32, 80 und 174<br />
bietet die <strong>IBM</strong> 3996 Kapazitäten von 960 GB bis 5,2 TB an.<br />
Im August 2007 kündigte <strong>IBM</strong> für die 3996 optischen Archivsysteme<br />
die Verwendung der neuen optischen Platten mit<br />
60 GB in den Formaten WORM, MO und CCW an. Die neue<br />
Plattengeneration reflektiert den 2 x Standard, basierend auf<br />
der blauen LaserTechnologie. Damit skaliert die <strong>IBM</strong> 3996<br />
auf eine Kapazität von bis zu 10,4 TB. Die kapazitiven Möglichkeiten<br />
liegen also deutlich unter den Möglichkeiten einer<br />
DR550.<br />
Modell 80 Modell 32<br />
Es bleibt abzuwarten, ob – basierend auf der BlaueLaser<br />
Technik – ein klassischer optischer 4 x Standard verabschiedet<br />
wird, da inzwischen andere Lösungsoptionen für die Langzeitarchivierung<br />
auf dem Markt etabliert sind.<br />
Hinzu kommt noch die Tatsache, dass, ebenfalls auf Blaue<br />
LaserTechnik basierend, der Standard der ersten holografischen<br />
Platte mit einer Kapazität von 150 GB im XYFormat<br />
im Jahr 2003 verabschiedet wurde, Anfang 2005 bereits<br />
der 2 x Standard mit einer 500GBPlatte und Ende 2005<br />
ein 2 x Standard als Zusatzstandard für die ‘Consumer’<br />
Industrie in Form einer 300GBPlatte. Holografische CDs<br />
und CDROMs lassen sich aufgrund der verwendeten Polymerbeschichtung<br />
(Kunststoff) wesentlich kostengünstiger<br />
produzieren als z. B. klassische DVDs oder im ITUmfeld<br />
verwendete WORM, MO oder CCWPlatten.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Neue NAS-Produkte<br />
Das Jahr 2005 war durch eine weitere Überraschung geprägt.<br />
Am 4. April 2005 wurde eine enge Kooperation und Allianz<br />
zwischen <strong>IBM</strong> und der Firma Network Appliance bekannt<br />
gegeben. Diese Allianz ermöglicht <strong>IBM</strong>, alle NetAppProdukte<br />
als <strong>IBM</strong> LogoProdukte zu vertreiben. Da <strong>IBM</strong> bisher auf dem<br />
Gebiet des NAS (Network Attached <strong>Storage</strong>) nur begrenzt<br />
aktiv war, ermöglicht diese Partnerschaft <strong>IBM</strong>, auf dem Gebiet<br />
des ‘FileServings’ ein breites <strong>Storage</strong>Lösungsportfolio anzubieten.<br />
Am Anfang waren nur die kleinen NetAppGeräte<br />
unter <strong>IBM</strong> Logo verfügbar, seit Ende 2005 die Geräte mittlerer<br />
Leistungsklasse, seit Juni 2006 entsprechende Gateways und<br />
seit August 2006 die Hochleistungsgeräte und damit nahezu<br />
die gesamte Produktpalette von NetApp.<br />
<strong>IBM</strong> Nseries N5000 und Nseries N7000<br />
Die <strong>IBM</strong> Nseries bietet Antworten auf die Fragen der Vereinfachung<br />
der <strong>Storage</strong>Infrastrukturen und des zentralen<br />
Datenmanagements, des Backups der Daten und deren einfachster<br />
Wiederherstellung.<br />
<strong>IBM</strong> läutet mit der Nserie die Konvergenz der Speicherwelten<br />
ein. Stand NAS für ‘Einfachheit’ und Funktionsvielfalt, so<br />
wurden beim Thema SAN Argumente wie High Performance,<br />
Skalierung und Ausfallsicherheit genannt. Mit der Nseries<br />
werden nun diese Unterschiede aufgehoben.<br />
Es stehen dabei generell zwei Modelltypen zur Verfügung.<br />
<strong>System</strong>e mit internen Diskdrives (Filer) und <strong>System</strong>e, die<br />
externe SANDiskRessourcen verwenden, die sogenannten<br />
NASGateways.<br />
Die Skalierung der beiden <strong>System</strong>reihen reicht von Entryüber<br />
Midrange hin zu Enterprise<strong>Storage</strong>Kapazitäten und<br />
Anschlussmöglichkeiten. Als herausragendes Merkmal sei<br />
erwähnt, dass alle <strong>System</strong>e dasselbe Betriebssystem Data<br />
ONTAP nutzen.<br />
Die NseriesProdukte bieten eine große Möglichkeit, Server<br />
im Netzwerk mit ihren spezifischen Zugriffsprotokollen anzuschließen.<br />
Diese umfassen die NASFileI/OProtokolle (CIFS,<br />
NFS) sowie die BlockI/OProtokolle iSCSI und FCP.<br />
Die Nseries bietet eine enorme Flexibilität in Bezug auf die<br />
Ausbaustufen und die Möglichkeit, verschiedene DiskTechnologien<br />
für die jeweilige Lösung zusammenzustellen. Fiber<br />
Channel Diskdrives und SATA Diskdrives können gemischt<br />
werden.<br />
Eine Nseries, bestückt mit FibreChannel Disks, kann so für<br />
ein MissionCritical, HighPerformance und Transaktionsorientiertes<br />
Umfeld eingesetzt werden. Nseries, bestückt mit<br />
SATA Diskdrives, kann die ideale Wahl für Kunden sein, die<br />
eine DisktoDiskBackupMöglichkeit suchen oder sich für<br />
Archivierung interessieren.<br />
Alle Nseries<strong>System</strong>e nutzen ein einziges Betriebssystem mit<br />
einer enormen Vielfalt von weiteren, zusätzlichen SWOptionen,<br />
angefangen vom <strong>Storage</strong> und <strong>System</strong>Management,<br />
über Inbound und OutboundCopyServices bis hin zur<br />
kompletten D/RLösung mit integrierten BackupFunktionen.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
81
82<br />
1999 bis 2005<br />
Die Epoche der Multiplattform-<strong>System</strong>e und des FibreChannel SAN und NAS<br />
<strong>IBM</strong> N3700<br />
Da das Thema ‘gesetzeskonforme Archivierung’ einen immer<br />
wichtigeren Stellenwert einnimmt, bietet die Nseries WORM<br />
Funktionen an. Damit können Daten als nicht ‘lösch/veränder<br />
bar’ abgespeichert werden, um den entsprechenden<br />
Richt linien Rechnung zu tragen. Es können bestimmte<br />
Speicher bereiche im <strong>System</strong> oder auch die gesamte Nseries<br />
einfach als ‘WORM’Bereiche definiert werden. Eine breite<br />
Unterstützung der namhaften ApplicationManagementSW<br />
Hersteller ist gegeben.<br />
Die Nseries bietet SWFunktionen an, die dem <strong>System</strong>administrator<br />
das Management seiner MicrosoftExchange, MicrosoftSQL,<br />
<strong>IBM</strong> DB2 und OracleDatenbanken erleichtern. Mit<br />
255 SnapShots (PointinTimeKopien) können Applikationen<br />
bei Fehlern leicht wiederhergestellt werden. Ein patentierter<br />
RAIDDPAlgorithmus sorgt für hohe Datenverfügbarkeit und<br />
schützt vor dem Datenverlust bei Ausfall von zwei Platten in<br />
einer RAIDGruppe. Dies ist vor allem beim Einsatz von SATA<br />
Platten sinnvoll.<br />
Das Einstiegssystem N3700 bietet eine Kapazität von bis<br />
zu 16 TB, die mittleren <strong>System</strong>e N5200 bis zu 84 TB (bis zu<br />
168 LUNs) und N5500 bis zu 168 TB (bis zu 336 LUNs).<br />
Wahlweise können Platten mit 72 GB, 144 GB und 300 GB<br />
konfiguriert werden. Bei den mittleren <strong>System</strong>en werden zwei<br />
2,8GHzXeonProzessoren verwendet. Der sogenannte ‘Kopf’<br />
der Filer (der Begriff hat sich für den Controller der Appliance<br />
Lösung eingebürgert) ist bei den mittleren <strong>System</strong>en auch<br />
als Gateway verfügbar und bedient sich der verfügbaren<br />
Plattenkapazitäten in einem SAN.<br />
Die Hochleistungssysteme Nseries 7000 bestehen aus der<br />
N7600, die kapazitiv bis 420 TB (bis zu 672 LUNs) skaliert,<br />
und der N7800, die auf bis 504 TB (bis zu 672 LUNs) ausgebaut<br />
werden kann. Bei der N7600 werden vier 2,6GHzAMD<br />
OpteronProzessoren, bei der N7800 acht 2,8GHzAMD<br />
OpteronProzessoren verwendet. Bei beiden Hochleistungs <br />
systemen können neben den anderen Platten auch 500GB<br />
SATAPlatten eingebaut werden. Auch die ‘Köpfe’ der Hochleistungssysteme<br />
sind als Gateways verfügbar.<br />
Um das Portfolio der NseriesProdukte zwischen N5000 und<br />
N7000 in der Skalierbarkeit abzurunden, kündigte <strong>IBM</strong> im<br />
November 2006 das Modell N5600 als neues leistungsstärkstes<br />
Modell der N5000Reihe mit einer Verfügbarkeit ab<br />
dem 8. Dezember 2006 an. Die N5600 bietet auf Basis<br />
einer 64bitArchitektur Kapazitäten von bis zu 252 TB und<br />
eine 30 – 40 % höhere Leistung im Vergleich zur N5500 und<br />
schließt damit die Lücke zwischen N5500 und N7600.<br />
Als Ergänzung der N5600 Appliance kündigte <strong>IBM</strong> im Mai<br />
2007 das NAS Gateway N5600 an. Zum selben Zeitpunkt, mit<br />
Verfügbarkeit im Juni 2007, wird die NseriesReihe durch<br />
die neuen Modelle N5300 und das NAS Gateway N5300<br />
ergänzt. Die N5300 integriert eine 64BitMaschine und skaliert<br />
kapazitiv auf bis zu 126 TB. Das Gateway ist durch die<br />
64BitMaschine bestens für 4GbitSANs geeignet. Im<br />
August 2007 kommen zwei neue Einstiegssysteme hinzu,<br />
das Entrysystem N3300, das bis auf 24 TB Kapazität ausbaubar<br />
ist, und die N3600, die auf bis zu 69 TB Kapazität ausgebaut<br />
werden kann. Die alte N5500 und das N5500 Gateway<br />
wurde im Oktober 2007 vom Vertrieb zurückgezogen.<br />
Im Oktober 2007 wird den NseriesProdukten eine neue<br />
Management Software, der Virtual File Manager VFM zur<br />
Verfügung gestellt. Dieses SoftwareProdukt wurde von der<br />
Firma Brocade entwickelt und bietet die Möglichkeit der<br />
FileVirtualisierung.<br />
Im Februar 2008 kündigte <strong>IBM</strong> eine neue Generation der<br />
Nseries für große Rechenzentrumsbetriebe an.<br />
Die nächste Generation der N7000series ist sowohl als Appliance<br />
als auch als Gateway verfügbar. Die neuen Modelle<br />
N7700 und N7900 ermöglichen eine höhere Skalierbarkeit<br />
für den Rechenzentrumsbetrieb in großem Maßstab. Die<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
neuen <strong>System</strong>e bieten eine Skalierbarkeit mit bis zu 1.176 TB<br />
Kapazitätsunterstützung für speicherintensive Anforderungen<br />
in Rechenzentren. Die N7000series ermöglicht es ITBetreibern,<br />
SAN und NASSpeicheranforderungen auf einem einzigen<br />
<strong>System</strong> zu konsolidieren.<br />
Für die Entry<strong>System</strong>e stehen neue Plattenlaufwerke zur Ver<br />
fügung. Für die N3300 und N3600 werden nun auch SATA<br />
oder SASLaufwerke im Controller unterstützt. Die N3300<br />
verfügt über eine erweiterte Skalierbarkeit von bis zu 68 TB<br />
und die N3600 von bis zu 104 TB. Zusätzlich wurde bei folgenden<br />
Modellen die Kapazität aufgestockt: N5300 (von<br />
168 auf 336 TB), N5600 (von 252 auf 504 TB), N7600 (von<br />
420 auf 840 TB) und N7800 (von 504 auf 1.008 TB). Der<br />
SnapManager für Office SharePointServer von Microsoft ist<br />
jetzt auf allen <strong>System</strong>en der Nseries verfügbar.<br />
Im August 2008 kündigt <strong>IBM</strong> die neuen Nseries<strong>System</strong>e<br />
N6040 und N6070 an. Die N6040 bietet Kapazitäten von bis<br />
zu 420 TB und die N6070 von bis zu 840 TB. Die N6000<br />
Reihe wird im Februar 2009 durch das Modell N6060<br />
ergänzt, das eine Kapazität von bis zu 672 TB bietet. Im<br />
gleichen Zuge werden im Oktober 2008 mit Wirkung vom<br />
Februar 2009 die <strong>System</strong>e N5200, N5300 und N5600 von<br />
Marketing zurückgezogen. Im Vergleich zur N5000Reihe<br />
bietet die N6000Reihe 1,4fach bis 2fach höhere Leistungsfähigkeit,<br />
weil sie auf moderner Hardware basieren und<br />
mehr Cache besitzen. Auch haben die N6000<strong>System</strong>e die<br />
Möglichkeit, mit neueren Betriebssystemständen auf Basis<br />
von Data ONTAP zu arbeiten.<br />
Nseries unterstützt eine Vielzahl von Servern und Betriebssystemen<br />
via FCP, CIFS, NFS und iSCSI. Die angeschlossenen<br />
PlattenArrays können in RAID4 oder RAIDDP (Double Parity),<br />
das dem RAID6Level entspricht, konfiguriert werden.<br />
Mit der NseriesFamilie stellt die <strong>IBM</strong> maßgeschneiderte<br />
Plattenspeicherlösungen im Filer und NASUmfeld zur<br />
Verfügung.<br />
Es stehen für die <strong>IBM</strong> Nseries zurzeit 40 verschiedene SW<br />
Funktionen zur Verfügung. Im Anhang sind die wichtigsten<br />
beschrieben.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
83
84<br />
1999 bis 2005<br />
Die Epoche der Multiplattform-<strong>System</strong>e und des FibreChannel SAN und NAS<br />
SnapShot<br />
SnapShots sind lesbare, konsistente SofortKopien (Pointin<br />
Time Copy) eines Datenbestandes, genauer eines Files oder<br />
einer LUN. Es können bis zu 255 SnapShots pro File/LUN<br />
erzeugt werden. Das Besondere daran ist, dass sie platzsparend<br />
sind, d. h., dass sie beim Erzeugen keinen zusätzlichen<br />
Plattenplatz benötigen. Dies geschieht dadurch, dass<br />
nur der Verweis auf die Daten (Pointer) gespeichert wird.<br />
SnapShots können manuell angestoßen oder auch automatisiert<br />
prozessiert werden – so können z. B. alle 5 Minuten<br />
PointinTimeKopien erzeugt werden. Durch die hohe Anzahl<br />
der SnapShots (255) ist damit ein sehr granulares und zeitnahes<br />
Backup/Recovery möglich. Da SnapShots in einem<br />
speziellen Verzeichnis abgelegt werden, ist es auch für den<br />
User selbst sehr einfach (per Drag&Drop) seine gelöschten<br />
Dateien selbst wiederherzustellen.<br />
SnapRestore<br />
SnapRestore nutzt die zeitnahen SnapShotKopien, um eine<br />
File, ein File<strong>System</strong> oder eine LUN wiederherzustellen. Sind<br />
SnapShots nur lesbare Kopien und müssen für die Wiederherstellung<br />
der Daten in das aktive Filesystem kopiert werden,<br />
kann mit SnapRestore sehr leicht das aktive Filesystem auf<br />
eine SnapShotKopie aufgesetzt werden. Dies bedeutet, dass<br />
für eine Datenwiederherstellung keine Daten umherkopiert<br />
werden. Ein solches Restoring geht mit einem einzelnen Kommando<br />
sehr schnell vonstatten! Eine 300 GB große Datenbank<br />
kann mit dieser Technik in ca. 2 bis 3 Minuten restored werden.<br />
SnapManager<br />
SnapManager wurde speziell für Datenbanken (Oracle und<br />
MS SQL) und MailApplikationen (MS Exchange) entwickelt.<br />
Basierend auf SnapRestore bietet der SnapManager ein<br />
hochintegratives SWPaket für den <strong>System</strong>administrator.<br />
Statt aufwendiger Scripts kann er hiermit per GUI einfache<br />
BackupTasks aufsetzen, RestoringProzesse anstoßen oder<br />
per ‘Klick’ DatenbankClones für Testzwecke erzeugen. Es<br />
besteht sogar die Möglichkeit, einzelne Mailboxen (mit Kalendereinträgen,<br />
Kontakten, Attachments) für das MS Exchange<br />
Umfeld nach einem Fehlerfall einfach wiederherzustellen.<br />
SnapMirror<br />
Sind SnapShot und SnapRestore Backup/RecoveryFunktionen,<br />
ist mit SnapMirror eine Funktion entwickelt worden,<br />
die für die Spiegelung der Daten von einer Nseries auf eine<br />
andere Nseries eine D/R Funktion liefert. SnapMirror spiegelt<br />
Daten – vereinfacht gesagt – synchron oder asynchron über<br />
SAN oder LAN auf eine DisasterRecovery Site. Bei Ausfall<br />
der ProduktivSeite stehen die Daten trotz Ausfalls zur Verfügung.<br />
Ist die ProduktivSeite wieder operational, werden die<br />
Daten von der DRSeite wieder zurückkopiert.<br />
SnapVault und SnapLock<br />
SnapVault und SnapLock sind Lösungen für das Backup und<br />
die Archivierung von Daten. SnapVault ermöglicht ein Backup<br />
einer Nseries auf eine andere (oder von vielen auf eine).<br />
Durch den Einsatz von günstigen SATA Disks kann auf das<br />
Backup system schnell und kostengünstig gesichert werden.<br />
Da ein Restoring von Disk erfolgt, sind die Daten auch schnell<br />
wiederherstellbar. SnapLock bietet die Möglichkeit, die<br />
gesamte Nseries oder einen Teil der Disks als WORMBereich<br />
(Write Once Read Many) zu nutzen. Daten, die hier abgelegt<br />
werden, können erst nach dem Ablauf des Aufbewahrungsdatums<br />
gelöscht und/oder verändert werden.<br />
Open <strong>System</strong> SnapVault (OSSV)<br />
OSSV verhält sich wie SnapVault mit dem Unterschied, dass<br />
die OSSV (Open <strong>System</strong> SnapVault) SoftwareServer sichern<br />
und wiederherstellen kann. Hierfür muss die OSSV SW auf<br />
den Server (Open, d. h. Unix und Windows) installiert werden.<br />
Die Server sichern dann auf eine Nseries als Backupsystem.<br />
Cluster Failover<br />
Cluster Failover (CFO) ist eine Standardkomponente bei<br />
jedem DualController (A20 oder G20) der Nseries. Bei Ausfall<br />
eines Controllers übernimmt automatisch der zweite<br />
Controller die ServerI/Os und der Datenzugriff bleibt erhalten.<br />
MetroCluster<br />
Erweitert man die ClusterFailoverFunktion (CFO) über<br />
Gebäudegrenzen hinweg, erhält man den MetroCluster.<br />
Der MetroCluster repliziert die Daten vom Controller 1 des<br />
primären RZs zum Controller 2 des sekundären RZs und<br />
garantiert Datenkonsistenz und deren Verfügbarkeit. Fällt die<br />
primäre Site aus, erlaubt MetroCluster einen Failover mit einem<br />
einzigen Befehl des Administrators. MetroCluster ist im Gegensatz<br />
zu SnapMirror keine DR, sondern eine Business ContinuityLösung.<br />
Basierend auf dem Design, in dem die Daten<br />
bereits auf beiden Seiten synchron und im sofortigen Zugriff<br />
liegen, ist eine sofortige Weiterführung der Geschäftsprozesse<br />
möglich. Diese Übernahme ist soweit automatisiert, dass der<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Administrator nur noch einen einzigen Befehl absetzen muss.<br />
Stretch MetroCluster bietet einen Schutz von bis zu 300 m<br />
zwischen zwei Nseries<strong>System</strong>en. Fabric MetroCluster bietet<br />
darüber hinaus einen Schutz von bis zu 100 km mit SAN<br />
Switchen.<br />
A-SIS (Advanced Single Instance <strong>Storage</strong>)<br />
Um die gespeicherte Datenmenge auf einem Backup oder<br />
Archivsystem zu reduzieren, kann DataDeduplication eingesetzt<br />
werden. Bei Nseries heißt diese Funktion ASIS (Advanced<br />
Single Instance <strong>Storage</strong> Deduplication). Identische Daten<br />
werden nur einmal gespeichert, was bei bestimmten Applikationen<br />
bis zu 70 % Ersparnis in der Speicherkapazität<br />
ausmachen kann. Auf <strong>System</strong>ebene analysiert die Nseries<br />
identische Blöcke im Hintergrund (für die Applikation transparent)<br />
und speichert diese nur einmal ab. ASIS ist ideal<br />
für Archive oder Backup<strong>System</strong>e.<br />
SMBR (Single Mailbox Recovery für Exchange)<br />
Im Gegensatz zu Lotus Domino, bei dem jede Mailbox separat<br />
als eigene Datenbank gespeichert wird (und damit eine<br />
einfach wiederherstellbare Einheit darstellt), legt Exchange<br />
verschiedene Mailboxen zusammen und in .edb und .stm<br />
Files ab. Diese Files werden im Laufe der Zeit sehr groß.<br />
Das erschwert das Restoring, weil man mit sehr großen .edbund<br />
.stmFiles arbeiten muss, wenn eine einzelne Mailbox<br />
wiederhergestellt werden muss.<br />
Die Lösung hierfür ist SMBR, eine SW, die diese großen Files<br />
durchsucht, um die gewünschte Mailbox (inklusive Anhängen,<br />
Foldern etc.) wiederherzustellen. SMBR setzt auf den<br />
SnapShots auf und muss nicht auf dem Produktionsserver<br />
laufen. Eine ‘Content Analyse’ ist eine Option der SMBR: mit<br />
ihr kann der Inhalt von EMails, Anhängen etc. analysiert<br />
und protokolliert werden.<br />
SnapDrive<br />
SnapDrive ist die SW, die es ermöglicht, aus dem Applikationserver<br />
heraus Volumes zu verwalten, zu vergrößern, konsistente<br />
SnapShots auszulösen und LUNs zu clonen (ohne<br />
FlexClone Feature).<br />
Müssen in einem klassischen <strong>Storage</strong>Subsystem die Volumes<br />
für eine Datenbank vergrößert werden, muss der Serveradministrator<br />
spätestens dann einen Prozess anstoßen,<br />
um mehr Speicherplatz zu beantragen.<br />
Mit SnapDrive ist das jetzt sehr einfach: Aus dem GUI der<br />
Applicationserver heraus wählt man das entsprechende<br />
Volume an und gibt die neue größere Kapazität ein. Im Hintergrund<br />
(also unterbrechungsfrei) wird das Volume vergrößert.<br />
SnapDrive kommuniziert mit der Nseries, um diese<br />
Aktionen durchzuführen. SnapDrive spart Zeit und Kosten<br />
und hilft Prozesse zu vereinfachen, da diese via GUI erledigt<br />
werden können. Darüber hinaus kann SnapDrive auch<br />
neue Drives anlegen und diese ‘mounten’ (d. h., den Servern<br />
zur Verfügung stellen). SnapDrive unterstützt MSCS (Microsoft<br />
Cluster) und VSS und sollte für iSCSI und FC immer eingesetzt<br />
werden. Mit dieser Funktion werden Microsoft, Windows<br />
sowie Unix/LinuxDerivate unterstützt.<br />
SyncMirror<br />
SyncMirror ist ein Standardfeature, bei dem jeder I/O faktisch<br />
auf zwei getrennte Diskpools geschrieben wird. Dies<br />
entspricht quasi einem RAID1 innerhalb eines <strong>System</strong>s.<br />
SyncMirror lässt sich am besten mit dem LVM (Logical<br />
Volume Manager) unter AIX vergleichen.<br />
RAID-DP<br />
Herkömmliche SingleParity RAIDTechnologien bieten Schutz<br />
beim Ausfall eines DiskDrives. Es wird erwartet, dass kein<br />
anderer Fehler in der DatenRekonstruktionszeit auftritt. Sollte<br />
dennoch ein Fehler in dieser Phase auftreten, kann es zu<br />
Datenverlusten führen. Dies ist besonders im Hinblick auf die<br />
immer größer werdenden SATA Drives der Fall, die inzwischen<br />
1 TB Datenvolumen fassen können. RAID DP (Double Parity)<br />
sichert den Ausfall von zwei DiskDrives. RAID DP schreibt<br />
16 Stripes, die vorher kalkuliert werden (Data und Parity),<br />
gleichzeitig auf das DiskBackend.<br />
Spares Drives greifen bei Ausfall einer Disk. RAIDDP entspricht<br />
also RAID6.<br />
FlexVol<br />
FlexVol ist eine StandardSW, die für das LUNManagement<br />
entwickelt wurde. FlexVol bedient sich dabei aus dem<br />
gesamten Disk<strong>Storage</strong>Pool der Nseries, um daraus die<br />
einzelnen LUNs zu formen. Es werden dabei alle verfügbaren<br />
‘Spindeln’ im Backend ausgenutzt, ohne dass I/O<br />
Engpässe durch dedizierte DiskZuteilungen entstehen.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
85
86<br />
1999 bis 2005<br />
Die Epoche der Multiplattform-<strong>System</strong>e und des FibreChannel SAN und NAS<br />
FlexShare<br />
FlexShare priorisiert den Service für wichtige Workloads<br />
durch Zuordnung von Prioritätsstufen von 1 – 5 für jedes<br />
Volume. So kann z. B. der I/O einer Datenbank gegenüber<br />
Fileservices bevorzugt bedient werden. FlexShare ist ein<br />
Standardfeature der Nseries.<br />
FlexClone<br />
FlexClone ermöglicht, mehrfache Clones von FlexVols zu<br />
erzeugen (z. B. für Testzwecke, QA, DWH etc.). FlexClones<br />
verbrauchen zum Zeitpunkt der Erstellung keinen zusätzlichen<br />
Speicherplatz. Sie setzen auf SnapShots auf und sind<br />
in Sekunden erzeugt und schreibend veränderbar. Sie<br />
haben die gleiche Performance wie FlexVols inklusive aller<br />
Eigenschaften eines FlexVols (dynamisches Vergrößern und<br />
Verkleinern). Eine Einschränkung ist zu berücksichtigen:<br />
‘Parent FlexVol’ und Base SnapShot können nicht gelöscht<br />
werden, solange ein davon abhängiges FlexClone Volume<br />
existiert. Über ‘Split’ kann das FlexClone Volume von seinem<br />
‘Parent Volume’ getrennt werden und unabhängig weiter<br />
existieren. Dafür wird freier Platz im Aggregat benötigt, um<br />
die ‘Shared Blocks’ zu kopieren.<br />
Kommentar zur Epoche Multiplattform-<strong>System</strong>e und FibreChannel<br />
SAN und NAS<br />
Die Schnelligkeit und Hektik nahm in dieser Epoche im Vergleich<br />
zur VorgängerEpoche noch weiter zu. Hinzu kamen<br />
neue Komplexitäten durch neue FibreChannelNetze (SANs)<br />
und die Möglichkeiten im NetworkingAttached<strong>Storage</strong>Umfeld.<br />
<strong>Storage</strong> wurde durch viele neue Produkte im SAN und<br />
NASUmfeld zwar vielseitiger, aber auch komplexer und<br />
schwieriger.<br />
In dieser Epoche lösten sich die Speichersysteme von ihrer<br />
bisherigen Abhängigkeit von den Servern. Multiplattform<strong>System</strong>e<br />
wie die ESS konnten jede ServerPlattform bedienen.<br />
Neben diesen Multiplattform<strong>System</strong>en wurden parallel für die<br />
Open<strong>System</strong>Plattformen FibreChannel<strong>System</strong>e gebaut, die<br />
sich an den entstehenden und immer weiter verbreiteten SANs<br />
anschließen ließen. SANs und SANStrategien beherrschten<br />
immer mehr den Markt. Das gilt auch heute noch! Auch die<br />
zSeries stellte von ESCON auf FICON um, um ESCONProtokollpakete<br />
über den FibreChannel zu transportieren. SAN<br />
Virtualisierung war das Fokusthema, dem <strong>IBM</strong> mit dem SAN<br />
Volume Controller antwortete. SANManagement, vor allem<br />
zentrales Management, wurde zu einer der Hauptanforderungen<br />
von Rechenzentren, die SANs betrieben. Dazu entwickelte<br />
<strong>IBM</strong> das Programmpaket <strong>IBM</strong> TPC (Total Productivity<br />
Center). Nach 1GbitSANs kamen 2Gbit und 4GbitSANs<br />
in Zeitabständen von etwa drei Jahren zum Einsatz. Seit<br />
2006 sind 4GbitFibreChannelSAN‘End to End’Lösungen<br />
möglich.<br />
Im NASUmfeld brachte <strong>IBM</strong> hauptsächlich Lösungen in Form<br />
von Gateways, die sich allerdings während der gesamten<br />
Epoche nicht durchsetzen konnten. <strong>IBM</strong> hatte zu wenig Fokus<br />
auf die NASMöglichkeiten und konzentrierte sich hauptsächlich<br />
auf die SANs. Am Ende der Epoche, im Jahr 2005,<br />
kam es zu einer Allianz der Firmen <strong>IBM</strong> und Network Appliance,<br />
die auf dem Gebiet NAS sehr erfolgreich waren und<br />
bis heute erfolgreich sind. Diese Allianz ermöglicht <strong>IBM</strong>, auch<br />
auf dem Gebiet NAS entwickelte Lösungen anzubieten und<br />
das GesamtspeicherPortfolio auszubauen.<br />
Auf der Bandentwicklungsseite war neben der Einführung<br />
von LTO2 und LTO3 eines der Meilensteine die Einführung<br />
der sensationellen JaguarBandlaufwerktechnologie mit dem<br />
3592 und später TS1120Laufwerk. Jaguar ist das ‘Vehicle’,<br />
um im TapeUmfeld ganz neue Wege beschreiten zu können.<br />
Jaguar eröffnet technische Möglichkeiten, die wir uns<br />
vielleicht heute noch gar nicht vorstellen können (siehe<br />
TechnologieAnhang, Kapitel Magnetband).<br />
Für die Langzeitarchivierung entstanden neben optischen<br />
Archiven neue und bessere Lösungsansätze, weil der Gesetzgeber<br />
nicht mehr vorschrieb, welches Medium benutzt werden<br />
muss. Dadurch wurden bessere und sinnvollere Lösungen<br />
möglich. <strong>IBM</strong> entwickelte die Lösung DR450 (Data Retention),<br />
die durch die DR550 ersetzt wurde und heute erfolgreich im<br />
Langzeitarchivierungsbereich eingesetzt wird.<br />
Die verfügbaren Produkte am Ende dieser vielseitigen Epoche<br />
werden mit absoluter Sicherheit die Folgeepoche mit entsprechenden<br />
Weiterentwicklungen begleiten und Lösungen<br />
für die durch SAN und NAS komplex gewordene Speicherwelt<br />
bieten. Insbesondere werden vor allem die Bereiche des<br />
DS4000Plattensystems, des San Volume Controller, der gesamte<br />
Band und Bandarchivbereich, BandVirtualisierungslösungen<br />
und der Bereich der Langzeitarchivierung mit der<br />
DR550 schnell vorangetrieben werden.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
nchrone Kopie mit Metro Mirror<br />
(bis zu 300 km)<br />
A<br />
B<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme<br />
und der Speichervirtualisierung<br />
Asynchrone<br />
(keine D<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
87
88<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
Was wird uns die neue Epoche der Serverbasierenden<br />
Speicherarchitekturen und der Speichervirtualisierung<br />
bringen? Was erwartet uns technologisch in den nächsten<br />
Jahren?<br />
Der Autor erlaubt sich, eine persönliche und durchaus realistische<br />
Abschätzung der nahen Zukunft in dieses <strong>Storage</strong><br />
<strong>Kompendium</strong> einzuarbeiten.<br />
Server-basierende Plattensysteme<br />
Die Ansätze von Serverbasierenden Speicherarchitekturen<br />
sieht man bereits in der VorgängerEpoche in den Produkten<br />
DR550 (pSeriesServer) für die Langzeitarchivierung und<br />
TS7500 Familie (xSeriesServer mit Linux Kernel) für die<br />
Bandvirtualisierung im Open<strong>System</strong>sBereich. Auch die<br />
SANVirtualisierung mit dem SAN Volume Controller muss<br />
dazugezählt werden.<br />
Allerdings bedeuten Serverbasierende Speicherarchitek<br />
turen weit mehr. <strong>System</strong>e auf dieser Basis sind nicht nur<br />
Maschinen, auf denen Daten gespeichert werden, sondern<br />
auch gleichzeitig Server, die Applikationen durchführen kön<br />
<strong>IBM</strong> DS8100 2-Wege-<strong>System</strong> <strong>IBM</strong> DS8300 4-Wege-<strong>System</strong><br />
nen. Konsolidiert man heute Server auf der Serverebene<br />
und Speichereinheiten auf der Speicherebene, lassen Serverbasierende<br />
Speicherarchitekturen eine Vertikalkonsolidierung<br />
von Servern und <strong>Storage</strong> zu. Applikationen können<br />
von der Serverebene auf die <strong>Storage</strong>Ebene verlagert werden.<br />
Dies ist vor allem für Applikationen von wesentlichem<br />
Vorteil, die viele I/Os zwischen einer Servereinheit und einer<br />
<strong>Storage</strong>Einheit produzieren. Diese I/Os können alle eingespart<br />
werden, wenn die Applikation von einer Speichereinheit<br />
durchgeführt wird (‘No I/Ois the best I/O’).<br />
Das erste Produkt in dieser Serverbasierenden Speicherar<br />
chitektur ist das Plattensystem DS8000, das am 12. Oktober<br />
2004 von <strong>IBM</strong> angekündigt wurde. Die Ankündigung<br />
erfolgte zweifelsfrei viel zu früh und es dauerte fast noch ein<br />
ganzes Jahr, bis die Maschine den Stabilitätsgrad hatte, um<br />
produktiv eingesetzt zu werden. Heute hat die Maschine<br />
eine noch nie dagewesene Stabilität und eine Leistungsfähigkeit,<br />
die kein anderes vergleichbares <strong>System</strong> auf dem<br />
Markt ausliefert. Mit der DS8000 wurde am 12. Oktober<br />
auch der kleine Bruder, die DS6000, angekündigt.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Die DS8000 ist das derzeit leistungsfähigste Plattensystem<br />
auf dem Markt. Mit 3,4 Millionen I/Os pro Sekunde ist sie<br />
unschlagbar im Vergleich zu anderen Plattensystemen. <strong>IBM</strong><br />
trat mit dem Speichersystem DS8000 aber nicht an, um<br />
irgendwelche Spitzenpositionen auf irgenwelchen Ranglisten<br />
zu erzielen, sondern um mit weniger, leistungsfähiger<br />
Hardware die Datenspeicherung günstiger zu gestalten. Es<br />
geht um die Wirtschaftlichkeit und Spitzentechnologie hilft<br />
dabei, die Total Cost of Ownership (TCO) günstiger zu<br />
gestalten. TCO setzen sich aus HardwareAnschaffungsko<br />
sten und Betriebskosten zusammen. Mit dem Einsatz von<br />
DS8000 wird beides reduziert. DS8000 führt zu geringeren<br />
Anschaffungskosten und wesentlich günstigeren SANInfrastrukturkosten,<br />
weil weniger Komponenten benötigt werden.<br />
Gleichzeitig reduziert sich der Management und Tuning<br />
Aufwand, weil die Hardware leistungsfähiger ist und weniger<br />
überwacht und optimiert werden muss. Durch Architekturprinzipien<br />
wie ein StripeallDesign und selbstlernende und<br />
sich an veränderte Workloads automatisch anpassende<br />
CachingAlgorithmen erreicht die DS8000, dass die Hardware<br />
optimal genutzt wird.<br />
Die folgende Tabelle gibt einen Überblick über die Skalierbarkeit<br />
des Speichersystems DS8000. Die <strong>System</strong>e wurden<br />
im Hinblick auf nahezu lineare Skalierbarkeit konzipiert. Dies<br />
geht aus der unten stehenden Tabelle hervor. Den Einstieg<br />
in die DS8000Welt bietet das 2Wege<strong>System</strong> DS8100, das<br />
bis 116 TB auf Basis von 300GBLaufwerken skaliert. Steigen<br />
die Kapazitätsanforderungen, erhöhen sich bei dem<br />
<strong>System</strong> alle zur Leistungssteigerung erforderlichen Komponenten<br />
wie Anzahl der Prozessoren, Cache, FC/FICON<br />
Adapter und DiskAdapter. Dies gilt auch für die zukünftig<br />
geplanten Erweiterungen. Steigen die Kapazitätsanforderungen<br />
über 192 GB hinaus, sind zukünftig 8Wege und<br />
12Wege<strong>System</strong>e bis hin zum 32Wege<strong>System</strong> ohne Architekturänderung<br />
machbar. Bei einer nahezu verdreifachten<br />
Kapazität von über 500 TB skaliert das <strong>System</strong> nahezu<br />
linear mit, da dann auch alle wesentlichen Komponenten zur<br />
Leistungserbringung wie Cache, Prozessoren, FC/FICON<br />
Adapter und DiskAdapter beim Upgrade vom 4Wege auf<br />
das 12Wege<strong>System</strong> verdreifacht werden. Die zukünftigen<br />
<strong>System</strong>e sind Bestandteil einer lang angelegten Roadmap.<br />
Die 8Wege und 12Wege<strong>System</strong>e werden realisiert werden,<br />
sobald sich der Bedarf nach dieser extrem hohen Leistungsfähigkeit<br />
auf dem Markt abzeichnet.<br />
2-way 4-way 8-way 12-way<br />
Server Processors 2-way POWER5 4-way POWER5 8-way POWER5 12-way POWER5<br />
Cache 16 to 128 GB 32 to 256 GB 64 to 512 GB 96 to 768 GB<br />
FICON (2 Gb/s) (4 ports per adapter) 8 to 64 8 to 128 up to 256 up to 384<br />
FibreChannel (2 Gb/s) (2 ports per adapter) 8 to 64 8 to 128 up to 256 up to 384<br />
ESCON (2 Gb/s) (4 ports per adapter) 4 to 32 8 to 64 up to 128 up to 192<br />
Device Ports 8 to 32 8 to 64 8 to 128 8 to 192<br />
Drives<br />
73 GB (15K RPM), 146 GB, (15K RPM)<br />
146 GB (15K RPM), 300 GB (10K RPM)<br />
16 to 384 16 to 640 up to 1792 up to 1792<br />
Physical Capacity 1.2 to 115 TB 1.2 to 192 TB up to 538 TB up to 538 TB<br />
Number of Frames 1 to 2 1 to 3 2 to 8 2 to 8<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
89
90<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
<strong>IBM</strong> DS8100 Innenaufbau <strong>IBM</strong> DS8300 Innenaufbau<br />
Die DS8100 besteht aus einer Basiseinheit und maximal<br />
einer Erweiterungseinheit. An die DS8300 können bis zu<br />
zwei Erweiterungseinheiten angeschlossen werden. Seit<br />
Oktober 2006 können bei den DS8000 TurboModellen bis<br />
zu vier Erweiterungseinheiten angeschlossen werden. Damit<br />
bietet die DS8000 Turbo die Möglichkeit, über 300 TB FC<br />
Platten und über 500 TB FATAPlatten zu betreiben (maximal<br />
1.024 Plattenlaufwerke).<br />
Die Speichersysteme DS8000 sind die ersten Speichersys<br />
teme im Markt mit echten <strong>Storage</strong>LPARs. Wie bei einem<br />
Server können auf einer physischen Einheit logische LPARs<br />
mit eigenem Prozessor, eigener Bandbreite, eigenen HBAs,<br />
eigenem DiskAdapter, eigenen Laufwerken und eigenem<br />
Mikrocode gebildet werden. Die LPARs sind robust voneinander<br />
isoliert. Selbst ein Crash in einer LPAR beeinflusst<br />
die zweite LPAR nicht. Das LPARKonzept eignet sich daher<br />
besonders gut für die Sicherstellung eines bestimmten ServiceLevels<br />
für bestimmte Anwendungsbereiche. Produktion<br />
und Test können auf einer Maschine gefahren werden, ohne<br />
dass die Testaktivitäten die Produktion beeinflussen. zSeries<br />
und Open <strong>System</strong>s Workload können ebenfalls ohne Bedenken<br />
auf der gleichen Maschine betrieben werden, da jede<br />
LPAR mit ihren eigenen Ressourcen ausgestattet ist.<br />
Zum heutigen Stand bietet die DS8300 zwei LPARs, die<br />
jeweils 50 % der Ressourcen erhalten. In Kürze wird die Aufteilung<br />
flexibler werden und SubProzessorAllokationen<br />
werden möglich sein.<br />
In der Zukunft wird es neben den <strong>Storage</strong>LPARs auch<br />
Anwendungs-LPARs geben. Da die DS8000 eine pSeries<br />
integriert hat, können alle Möglichkeiten eines Servers für<br />
die Datenspeicherung genutzt werden. Es ist insbesondere<br />
daran gedacht, Anwendungen mit einer hohen Affinität zu<br />
<strong>Storage</strong> (viele I/Os) direkt auf dem Speichersystem laufen<br />
zu lassen und die internen Bandbreiten der DS8000 für optimale<br />
Performance zu nutzen.<br />
Ein wesentliches Merkmal der DS8000 sind die überle-<br />
genen Copy-Services, die einen unterbrechungsfreien RZ<br />
Betrieb ermöglichen. Dazu gehören die Funktionen synchrones<br />
und asynchrones Kopieren (Metro Mirror/Copy,<br />
Global Mirror/Copy) sowie PointinTime Copy (FlashCopy).<br />
Die Spiegelfunktionen der DS8000 sind heute wegen ihrer<br />
Leistungsfähigkeit (Entfernung, Anzahl I/Os über eine Leitung,<br />
Anzahl gleichzeitiger Spiegel) und ihrer Funktionalität<br />
(Konsistenzgruppen, Suspend/ResumeMöglichkeit,<br />
Umdrehen der Spiegelungsrichtung, drei Spiegel gleichzeitig<br />
etc.) einzigartig im Markt. Derzeit gibt es keine leistungsfähigere<br />
Remote-Copy-Implementierung auf dem Markt.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Während DS8000 auf Basis der POWER5Architektur ganz<br />
klar den HighEndSpeichermarkt adressiert, gibt es noch<br />
ein riesiges Marktpotenzial mit geringeren Anforderungen an<br />
Leistung und Skalierbarkeit. Dieses Marktpotenzial adressiert<br />
<strong>IBM</strong> mit einem modularen Speichersystem auf Basis<br />
der PowerPCProzessortechnologie. Wichtig für dieses<br />
Marktsegment ist ein kompaktes, modulares Design, das<br />
eine hohe Leistung auf kleinstem Raum ermöglicht, keine<br />
besonderen Anforderungen an die RZInfrastruktur stellt und<br />
sich perfekt in die vorhandene ITLandschaft mit Servern in<br />
19ZollRacks integrieren lässt.<br />
Diesen Designanforderungen entspricht das Speicher -<br />
sy stem DS6000. Das <strong>System</strong> ist voll und ganz für den Mas<br />
senmarkt und seine spezifischen Anforderungen konzipiert.<br />
Das <strong>System</strong> basiert auf modularen Einschüben mit 3UBauhöhe,<br />
die sich in vorhandene 19ZollRacks einbauen lassen,<br />
ohne dabei Kompromisse in der Leistungs fähigkeit einzugehen.<br />
Das Speichersystem skaliert von 288 Gigabyte bis<br />
auf 38,4 TB.<br />
DS6000 stellt für <strong>IBM</strong> bei Plattensystemen einen Durchbruch<br />
im Platzbedarf dar. Während der bisherige Einstieg in die<br />
EnterpriseWelt mit der ESS 750 nicht ohne mindestens<br />
einen Quadratmeter Stellfläche plus zusätzliche Servicefläche<br />
sowie einen stabilen Doppelboden, der eine Tragfähigkeit<br />
von über einer Tonne gestatten musste, zu ermöglichen<br />
war, erreicht die DS6000 völlig neue Dimensionen. Der maßstabsgerechte<br />
Vergleich unten zeigt den großen technologischen<br />
Fortschritt. Der Einstieg in die EnterpriseWelt ist<br />
jetzt mit weniger als 5 % des Volumens bisheriger Speichersysteme<br />
möglich. Damit gehen verringerte Anforderungen<br />
bzgl. der Servicefläche, der RZInfrastruktur und des Strombedarfs<br />
einher.<br />
Die DS6000 entspricht im logischen Aufbau der DS8000.<br />
Der Unterschied besteht in der Plattform, auf der das<br />
<strong>System</strong> betrieben wird. HA und DACode sind im Wesentlichen<br />
identisch, da es sich um autarke Einheiten handelt.<br />
Die Funktionalität des Speichersystems ist ebenfalls identisch.<br />
Der große Unterschied ist die ProzessorPlattform. Da<br />
der PowerPCProzessor über keine Partitionierungsmöglichkeiten<br />
verfügt, entfällt diese Komponente. Zudem wird der<br />
Prozessor nicht durch AIX, sondern durch Linux gesteuert.<br />
<strong>IBM</strong> ESS 750 mit 5 TB Kapazität <strong>IBM</strong> DS6000 mit 4,8 TB Kapazität<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
75,25”<br />
5,25”<br />
19”<br />
91
92<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
Ansicht <strong>IBM</strong> DS6800 Plattensystem<br />
Wesentliche Änderungen betreffen auch den Abstraction<br />
Layer, der alle HWSpezifikationen von der Funktionsebene<br />
isoliert. DS6000 ist also ein reines Speichersystem, das<br />
nicht für Applikationszwecke in der Zukunft eingesetzt werden<br />
kann.<br />
Die Maschine besteht im Prinzip aus 5 Komponenten, sogenannten<br />
‘Customer Replaceable Units’ (CRUs). Dies sind<br />
Laufwerke, Stromversorgung, Controller, Batterie und ein<br />
‘LightPathDiagnoseModul’. Wann immer eines dieser Teile<br />
defekt ist, erhält der Kunde ein Ersatzteil zugeschickt, das<br />
er in Minuten mit wenigen Handgriffen selbst einsetzen<br />
kann.<br />
Das Gleiche gilt für den Mikrocode. Wann immer eine neue<br />
Version verfügbar ist, wird der Kunde davon informiert und<br />
kann sich aus dem Internet den neuesten Mikrocode herunterladen<br />
und unterbrechungsfrei einspielen.<br />
Unterstützt wird man bei der Fehleranalyse durch Light Path<br />
Diagnostics, SNMPMeldungen und ein GUI. Die Fehleranalyse<br />
ist voll vom <strong>System</strong> gestützt. Interaktive Hilfefunktionen<br />
vereinfachen die Reparatur. Zur einfachen Administration<br />
und schnellen Implementierung verfügt das Speichersystem<br />
über einen Express Configuration Wizzard, der das erstmalige<br />
Konfigurieren oder Umkonfigurieren stark vereinfacht.<br />
Die DS6000 und DS8000 sind die ersten Plattensysteme<br />
von <strong>IBM</strong>, die mit vier Jahren Gewährleistung angekündigt<br />
wurden. Aufgrund dieser langen Gewährleistung erkennt<br />
man bereits, dass diese neue Architektur sehr lange<br />
Bestand haben wird.<br />
Am 22. August 2006 mit Verfügbarkeit im September 2006<br />
kündigte <strong>IBM</strong> die neusten Erweiterungen für die DS6000<br />
und DS8000 an. Beide Plattensysteme können jetzt neben<br />
der Auswahl an FibreChannelPlatten auch mit günstigeren<br />
FibreATA(FATA)-Platten bestückt werden. Die Platten<br />
haben eine Kapazität von 500 GB pro Laufwerk. Das bietet<br />
für die Plattensysteme die Möglichkeit, innerhalb des<br />
<strong>System</strong>s mit einer Zwei-‘tier’-<strong>Storage</strong>-Hierarchie zu arbeiten.<br />
So können die FC-Platten für die klassische Transaktionsverarbeitung<br />
und hoch frequentierte Daten eingesetzt werden<br />
und die günstigeren, aber langsameren FATA-Platten<br />
für sequenzielle Datenverarbeitung und nur wenig benutzte<br />
Daten.<br />
Damit bietet eine DS8000 voll ausgebaut mit FATAPlatten<br />
eine Bruttokapazität von 320 TB und eine kleine DS6000 bis<br />
zu 64 TB an Bruttokapazität.<br />
1 st tier-FC Drives<br />
- Transactional IO<br />
- Heavily used data<br />
2 nd tier-FATA Drives<br />
- Streaming data<br />
- Little used data<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
Flash
Für die DS8000 wurden neue Modelle angekündigt, die<br />
POWER P5+ Prozessortechnologie integriert haben und<br />
damit 15 % höhere Leistungsfähigkeit ausliefern. Die<br />
I/OCages wurden auf 4-Gbit-FibreChannel- und FICON-<br />
Ports umgestellt. Damit ist die DS8000 das erste Plattensystem<br />
auf dem Markt, das mit 4GbitFICONPorts am zSeries<br />
Host arbeiten kann. Die DS8000<strong>System</strong>e mit P5+ Pro zessoren<br />
werden als DS8000-Turbo-<strong>System</strong>e bezeichnet.<br />
Ein neue Einrichtung, die als ‘Synergy Feature’ bezeichnet<br />
und im November 2006 verfügbar wird, verbessert maßgeblich<br />
die Gesamtleistung der Komponenten DS8000 Turbo,<br />
DB 2 und AIX und erzielt eine wesentlich effektivere Kommunikation<br />
zwischen Rechner und Speichersystem für DB2<br />
Anwendungen. Dies wird durch eine gezielte ‘End to End’<br />
Prioritätensteuerung ermöglicht.<br />
Teil der Ankündigung vom 22. August 2006 war zudem die<br />
Möglichkeit, bei DS8000Turbo<strong>System</strong>en mit einem dritten<br />
Spiegel bei RemoteCopyVerfahren zu arbeiten. Diese<br />
Lösung wird als ‘3 Site Disaster Recovery Solution’<br />
bezeichnet. Damit wird auch im DisasterFall ein konstanter<br />
Zugriff auf die Daten gewährleistet. Diese Möglichkeit war<br />
bisher nur über RPQ (Request for Price Quoting) gegeben.<br />
Das dreifache Remote-Spiegelverfahren setzt sich aus<br />
den Komponenten ‘Metro Mirror’ und ‘Global Mirror’ (ehemals<br />
PPRC XD – Peer to Peer Remote Copy eXtended<br />
Distance – und FlashCopy) zusammen. Von der Lokation A<br />
wird mit der DS8000Turbo synchron zur Lokation B gespiegelt.<br />
Die Lokation B spiegelt dann asynchron auf die Lokation<br />
C weiter.<br />
Fällt die Lokation A aus, wird die Anwendung auf die Lokation<br />
B umgeleitet und Global Mirror läuft ohne Unterbrechung<br />
zwischen den Lokationen B und C weiter. Kommt<br />
Lokation A wieder online, wird von der Lokation B nach A<br />
auf inkrementeller Basis resynchronisiert. Nach Abschluss<br />
der Resynchronisation kann die Anwendung von B nach A<br />
zurückverlagert werden.<br />
Synchrone Kopie mit Metro Mirror<br />
(bis zu 300 km)<br />
A<br />
Fällt die Lokation B aus, stellen inkrementelle Resynchronisationsverfahren<br />
die Verbindung zwischen A und C her und<br />
gewährleisten damit weiterhin unterbrechungsfreien Spiegelbetrieb.<br />
Steht die Lokation B wieder zur Verfügung, wird<br />
über ein inkrementelles Verfahren von A nach B resynchronisiert.<br />
Nach Abschluss der Resynchronisation werden die<br />
Lokationen B und C wieder über Global Mirror verbunden<br />
und so die Ausgangssituation wieder hergestellt.<br />
Fällt Lokation C aus, ist die Anwendung A nicht betroffen<br />
und die synchrone Spiegelung zwischen A und B bleibt<br />
erhalten. Steht die Lokation C wieder zur Verfügung, wird<br />
Global Mirror inkrementell wieder aufgebaut und die Ausgangssituation<br />
wieder hergestellt.<br />
Parallel Access Volume (PAV): Die Funktion, von mehreren<br />
Rechnern und Anwendungen gleichzeitig auf diesselbe<br />
Platten adresse zu schreiben und von ihr zu lesen, wurde im<br />
z/OSUmfeld mit dem Enterprise <strong>Storage</strong> Server (siehe auch<br />
ESS) eingeführt und für die DS8000 weiter optimiert. Der<br />
Work load Manager (WLM) im z/OS steuerte die dynamische<br />
Zuordnung und Umordnung der dafür notwendigen ‘Alias’<br />
Adressen, was als dynamisches PAV bezeichnet wird. Im<br />
November 2006 kündigte <strong>IBM</strong> für die DS8000 Hyper PAV<br />
an. Dabei wurde die Funktion so geändert, dass z/OS im<br />
Zusammenspiel mit der DS8000 für jeden einzelnen I/O eine<br />
AliasAdresse aus einem Pool nehmen kann, ohne dass<br />
eine Koordination zwischen z/OS<strong>System</strong>en notwendig ist.<br />
Damit kann sofort auf sich ändernde Workloads reagiert<br />
werden. HyperPAV benötigt bei derselben Workload nur<br />
etwa die Hälfte an AliasAdressen und bietet im Vergleich<br />
zum dynamischen PAV bei derselben Anzahl an Alias<br />
Adressen die Möglichkeit, 50 % mehr I/Os zu prozessieren.<br />
Am 22. August 2006 wurde als neues SoftwareProdukt <strong>IBM</strong><br />
Total<strong>Storage</strong> Productivity Center (TPC) für Replikation<br />
angekündigt. TPC für Replikation erlaubt ein zentrales<br />
Management der CopyServicesFunktionen Metro Mirror,<br />
Global Mirror und FlashCopy für die Produkte DS6000,<br />
DS8000, DS8000 Turbo, SAN Volume Controller SVC und<br />
ESS Modell 800.<br />
Asynchrone Kopie mit Global Mirror<br />
(keine Distanz-Begrenzung)<br />
B C<br />
FlashCopy<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
93
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
Im Jahr 2007 stellte <strong>IBM</strong> für die DS8000 Plattensysteme<br />
erhebliche Erweiterungen zur Verfügung.<br />
Im Februar 2007 kündigte <strong>IBM</strong> mit Verfügbarkeit März für<br />
alle DS8000<strong>System</strong>e neben den bisherigen Plattentypen<br />
300-GB-FibreChannel-Platten mit 15.000 Umdrehungen<br />
an. Die DS8000 war damit das erste <strong>System</strong> auf dem Markt,<br />
das mit diesen schnellen großkapazitiven Platten ausgestattet<br />
werden konnte. Im Mai 2008 kamen erhebliche Kapazitätserweiterungen<br />
dazu. Konnte bisher ein 4Way<strong>System</strong><br />
mit bis zu 640 Platten (bei 2Way sind es bis zu 384 Platten)<br />
in einer Konfiguration von drei Einheiten ausgestattet sein,<br />
war es seit Juni 2007 möglich, ein 4Way<strong>System</strong> DS8300<br />
mit bis zu 1.024 Platten zu konfigurieren. Dazu werden an<br />
die Basiseinheit vier zusätzliche Erweiterungseinheiten<br />
angeschlossen, insgesamt also eine Konfiguration mit fünf<br />
Gehäuseeinheiten. Bei Verwendung der 500GBFATAPlatten<br />
steigerte sich so die maximale Kapazität auf bis zu 512 TB<br />
pro <strong>System</strong>.<br />
Seit November 2007 stehen der DS8000 weitere leistungs<br />
optimierende Features zur Verfügung. Die Funktion <strong>Storage</strong><br />
Pool Striping mit Rotate Extends reflektiert einen neuen<br />
DefaultAlgorithmus, der neue logische Platten in 1GB<br />
Schritten über das Backend verteilt und so die Leistung<br />
ohne spezielles Tuning optimiert. AMP (Adaptive Multistream<br />
Prefetching) stellt eine neue CachingTechnologie<br />
von <strong>IBM</strong> Research zur Verfügung, die, auf Workloads bezogen,<br />
ein selbstoptimierendes Prefetching durchführt. AMP<br />
entscheidet dynamisch, was und wann in den Cache vorgeladen<br />
wird. Das kann den Durchsatz von sequentiellen und<br />
BatchWorkloads dramatisch verbessern, d. h., Laufzeiten<br />
können erheblich verkürzt werden. AMP verbessert den Lese<br />
Durchsatz aus einem RAID5Array nahezu um Faktor zwei!<br />
AMP kann HotSpotSituationen verhindern, wenn sehr hohe<br />
Anforderungen an sequentielle Workloads gestellt werden.<br />
<strong>IBM</strong> z/OS Global Mirror Multiple Reader bietet im zSeries<br />
Umfeld einen deutlich höheren Durchsatz bei RemoteSpiegelungen.<br />
Neben den neuen Performance Features wurden im November<br />
2007 für die Maschinen auch neue funktionale Erweiterungen<br />
verfügbar. Space efficient FlashCopy kann durch<br />
Reduzierung der benötigten Plattenkapazität für Kopien<br />
signifikant die Kosten senken. Dadurch können gleichzeitig<br />
die Strom und Klimaanforderungen gesenkt werden. Flash<br />
Copies benötigen nur Plattenplatz, wenn Veränderungen am<br />
Original durchgeführt werden. Dynamic Volume Expansion<br />
vereinfacht das Management durch ‘Online’Vergrößerung<br />
von logischen Laufwerken bei Datenwachstum. Neben diesen<br />
Erweiterungen wird das TPC (Total Productivity Center)<br />
bei Auslieferung von neuen DS8000<strong>System</strong>en standardmäßig<br />
als neu umbenanntes SSPC (<strong>System</strong> <strong>Storage</strong> Productivity<br />
Center) mitgeliefert und bietet damit einen einheitlichen<br />
Zugang zum Management von <strong>IBM</strong> und anderen Speichersystemen.<br />
Damit stehen dem ITBenutzer eine einheitliche<br />
ManagementOberfläche und eine gemeinsame Konsole für<br />
DS8000<strong>System</strong>e und die SVCs (San Volume Controller) zur<br />
Verfügung.<br />
Am 26. Februar 2008 wurden zusammen mit der Ankündigung<br />
des neuen Mainframe<strong>System</strong>s z10 neue Erweiterungen für<br />
das DS8000 Plattensystem speziell im z/OSUmfeld angekündigt.<br />
Mit der Funktion z/OS Metro/Global Mirror Incremental<br />
Resync entfällt bei einer dreifachen Remote Spiegelung<br />
die Notwendigkeit, eine volle Kopie für die Resynchronisation<br />
nach einer HyperSwapSituation zu erzeugen. Die<br />
Erweiterung Extended Distance FICON reduziert den Bedarf<br />
von Kanalerweiterungseinheiten (Channel Extenders) bei<br />
z/OS Global Mirror (zweifache RemoteSpiegelung) und z/OS<br />
Metro/Global MirrorKonfigurationen (dreifache RemoteSpiegelung)<br />
durch eine höhere Parallelität der Leseoperationen.<br />
Die neue Möglichkeit des z/OS Basic Hyper Swap erlaubt<br />
die Konfiguration von Disk Replication Services über das<br />
grafische User Interface (GUI) der DS8000 Plattensysteme.<br />
Diese Möglichkeit kann auch für DS6000 und ESS<strong>System</strong>e<br />
genutzt werden, bei denen das GUI auch zur Verfügung steht.<br />
Die Möglichkeit des z/OS Basic Hyper Swap ist auch ohne<br />
GDPS (Geographically Dispersed Parallel Sysplex) benutzbar.<br />
z/OS Basic Hyper Swap ist eine einzigartige Funktion, die<br />
auch ohne GDPS einen automatischen Failover auf das<br />
RemotePlattensystem vornimmt, wenn die primäre Site nicht<br />
mehr zur Verfügung stehen sollte. Dies ist aber ausschließlich<br />
bei den <strong>IBM</strong> <strong>System</strong>en DS8000, DS6000 und ESS möglich.<br />
Plattensysteme anderer Hersteller werden nicht unterstützt.<br />
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<br />
die Möglichkeit mit variablen LPARs und damit mit mehr<br />
Flexibilität zu arbeiten. Bisher war nur eine Aufteilung von<br />
50 %/50 % möglich, jetzt ist auch eine variable Aufteilung<br />
von 25 %/75 % bzw. 75 %/25 % der <strong>System</strong>Ressourcen<br />
unterstützt.<br />
Innerhalb der separaten <strong>System</strong>Ressourcen können unter<br />
schiedliche Versionen des Microcodes betrieben werden,<br />
z. B. separate Produktions<strong>System</strong>e oder Testsysteme und<br />
das innerhalb eines physischen <strong>Storage</strong><strong>System</strong>s. Variable<br />
LPARs werden innerhalb der DS8300 ohne zusätzliche<br />
Kosten ab Microcode R.4.0 zu Verfügung gestellt. Mit R.4<br />
können nun folgende Aufteilungen vorgenommen werden:<br />
50/50 % Split (Factory Default), 75/25 % Split und 25/75 %<br />
Split. Die Aufteilung kann für die <strong>System</strong>Ressourcen Prozessoren,<br />
NVS und Cache erfolgen. Host Adapter Slots,<br />
Device Adapter Slots und <strong>Storage</strong> Enclosure Slots bleiben<br />
nach wie vor im 50/50 % Split.<br />
Mit dem Release 4.1 im September 2008 erhält die<br />
DS8000Familie folgende Erweiterungen:<br />
Unterstützung von Raid 6 als erweiterter Plattenschutz, ins<br />
besonders geeignet für große Platten, z. B. bei 1 TB SATA<br />
Platten. Bei FCPlatten wird aufgrund der geforderten hohen<br />
Plattenperformance und durch die schnelle architekturbedingte<br />
Wiederherstellung des RAIDVerbundes bei einem<br />
Plattenausfall weiterhin RAID5 bevorzugt angewandt. Mit<br />
der Integration von 450 GB FC 15K-Platten erweitert sich<br />
zum einem die mögliche Gesamtkapazität und erhöht so die<br />
Wirtschaftlichkeit des <strong>System</strong>s. Ein neuer <strong>IBM</strong> Service<br />
Plattenlaufwerk oben, Solid State Disk unten<br />
‘Secure Data Overwrite’ garantiert die sichere Löschung<br />
von sensiblen Daten auf Platten. Dieser Service wird durch<br />
einen geschulten <strong>IBM</strong> Techniker durchgeführt.<br />
Mit dem Release 4.2 im Februar 2009 kommen für die<br />
DS8000<strong>System</strong>e weitere fundamentale Erweiterungen zum<br />
Tragen. Die DS8000<strong>System</strong>e können jetzt neben FCPlatten<br />
und SATAPlatten mit SSDs (Solid State Disks) ausgestattet<br />
werden. Dabei sind Solid State Disks in der Größe von 73<br />
GB und 146 GB unterstützt. Standardmäßig ist der Werkseinbau<br />
vorgesehen, für den Feldeinbau muss ein RPQ<br />
gestellt werden. Dieser RPQ dient zur Sicherstellung der<br />
optimalen Performance.<br />
Als erstes <strong>IBM</strong> Subsystem unterstützt DS8000 in Verbindung<br />
mit speziellen DiskDrives die Verschlüsselung der Daten<br />
(Encryption) auf den Platten. Dadurch kann sichergestellt<br />
werden, dass selbst bei einem Verlust der DiskDrives die<br />
Daten nicht ausgelesen werden können. Im Gegensatz zu<br />
anderen Lösungen macht Encryption auf DiskDriveLevel<br />
Verschlüsselung ohne Leistungsverluste möglich. Es müssen<br />
keine Änderungen in Anwendungen oder der <strong>Storage</strong><br />
Infrastruktur vorgenommen werden. Die Verwaltung der<br />
Schlüssel wird analog zu der TapeVerschlüsselung mit dem<br />
Softwareprodukt TKLM, früher EKM, vorgenommen (siehe<br />
auch unter Tape Encryption).<br />
Mit der Einführung von hochkapazitiven 1 TB SATA-Platten<br />
eigenet sich das DS8000 Plattensystem auch für den Einsatz<br />
von DataDeDuplicationTechnologien, z. B. in Verbindung<br />
mit den DiligentProdukten (siehe unter DataDeDuplication<br />
<strong>IBM</strong> ProtecTIER).<br />
Mit dem Release 4.3 im Juli 2009 unterstützt die DS8000<br />
‘Thin Provisioning’ ohne Leistungsbeeinträchtigung. Die<br />
Funktion Thin Provisioning ist optional zu bestellen und ist<br />
für die gesamte Kapazität einsetzbar. Thin Provisioning kann<br />
die Nutzung der <strong>Storage</strong>Kapzität erhöhen und damit zur<br />
ökonomischen Nutzung des eingesetzten Speichers erheblich<br />
beitragen. Die <strong>Storage</strong>Administrationskosten können<br />
durch automatisiertes <strong>Storage</strong> Provisioning reduziert werden.<br />
Ein neues Feature, das ‘Quick Initialization Feature’<br />
ermöglicht das schnelle Einrichten von Copy Services.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
95
96<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
zHPF Multi-Track Support für DS8000<br />
Diese einzigartige Funktion der DS8000 in Verbindung mit<br />
zSeries führt zu erheblich verbesserten I/OLeistungen.<br />
Erreicht wird diese Leistungsverbesserung durch ein optimiertes<br />
I/OProtokoll.<br />
<strong>IBM</strong> DS8700 Plattensystem<br />
Im Oktober 2009 kündigt <strong>IBM</strong> die neue Maschine DS8700<br />
als Nachfolger der Plattensysteme DS8100 und DS8300 an.<br />
Die DS8700 basiert auf Power6Technologie und arbeitet<br />
mit P6-Prozessoren mit 4,7 GHz. Die Leistungsfähigkeit<br />
der Maschine ist ca. 2,5 Mal schneller als die DS8300. Die<br />
RioG Loop wird ausschließlich für die P6 ‘Server to Server’<br />
Kommunikation eingesetzt, während die Platten arrays über<br />
PCIE (Express)Karten angesteuert werden. Durch diese<br />
Architekturänderung bekommt die Maschine eine optimale<br />
BackendAnbindung und höhere BackendBandbreite, was<br />
sich vor allem bei Verwendung von schnellen SSDs (Solid<br />
State Disks) auszahlt.<br />
Wie die Vorgängersysteme ist die Maschine mit den neuen<br />
optimierten CacheAlgorithmen ausgestattet: SARC (Simplified<br />
Adaptive Replacement Cache) als Grundalgorithmus<br />
verbunden mit AMP (Adaptive Multistream Prefetching) zur<br />
Optimierung von Leseoperationen von den Platten in den<br />
Cache und IWC (Intelligent Write Caching) zur Optimierung<br />
der SchreibWorkload. Das Antwortzeitverhalten der DS8700<br />
dürfte derzeitig alle verfügbaren Plattensysteme im Markt<br />
weit übertreffen.<br />
Verbunden mit der DS8700Ankündigung ist ein Ausblick<br />
einer Roadmap bis 2013. Diese Roadmap beinhaltet Funktionen<br />
zur optimalen Nutzung von SSDs durch Analyse des<br />
I/OVerhaltens und dynamische Verlagerung von Extends,<br />
die sich optimal für die Speicherung auf SSDs eignen. Mit<br />
diesem neuen Algorithmus bekommt die Maschine die<br />
Fähigkeit, <strong>Storage</strong> Tiers optimal auszunutzen und die Daten<br />
dem I/OVerhalten entsprechend auf SSDs, FCPlatten und<br />
SATAPlatten abzuspeichern.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
<strong>IBM</strong> XIV <strong>Storage</strong><br />
Nahezu jedes Unternehmen ist heute von der steigenden<br />
Flut digital zu speichernder Daten betroffen. Laut der IDC<br />
Studie „The Diverse and Exploding Digital Universe“ wird<br />
das installierte Speichervolumen allein innerhalb der kommenden<br />
vier Jahre um 600 % wachsen. Schon heute stellt<br />
die Speichersystemadministration viele Firmen vor erhebliche<br />
Probleme. Das erwartete hohe Wachstum kommt allerdings<br />
nicht aus dem klassischen Rechenzentrumsbereich,<br />
sondern fällt im Bereich der unstrukturierten Daten an. Während<br />
im klassischen RZBetrieb sogenannte ‘Scale Up’Plattensysteme<br />
den Anforderungen an immer schnellere Antwortzeiten<br />
Rechnung tragen (z. B. DS8000 mit schnellen<br />
FibreChannelPlatten und SSDs) fehlen im Bereich des<br />
Datenwachstumsumfelds kostengünstige ‘Scale Out’<br />
<strong>System</strong>e, die trotz wachsender Kapazität eine gleichbleibende<br />
hohe Leistungsfähigkeit bieten. Eine solche Anforderung<br />
kann nur mit einer Architektur gelöst werden, die es<br />
erlaubt, Standardkomponenten, wie kostengünstige SATA<br />
Platten und PCbasierende Prozessoren, so zu integrieren,<br />
dass eine hohe Zuverlässigkeit und hohe Leistungsfähigkeit<br />
gewährleistet wird, auch wenn das <strong>System</strong> kapazitiv wächst.<br />
Diese neue ‘Scale Out’Anforderung nahm der ehemalige<br />
ChefEntwickler der EMCSymmetrix <strong>System</strong>e Moshe Yanai<br />
zum Anlass, die Firma XIV zu gründen, um ein neuartiges<br />
Speichersystem zu entwickeln, das diese neuen Aspekte<br />
von Anfang an berücksichtigt. Die Firma XIV wurde 2002<br />
gegründet, die ersten <strong>System</strong>e waren bereits 2005 in Produktion.<br />
Am 31.12.2007 wurde die Firma XIV von <strong>IBM</strong> aquiriert.<br />
Bis Ende 2008 sind bereits über 100 <strong>System</strong>e im produktiven<br />
Einsatz und seit Oktober 2008 sind die <strong>System</strong>e in<br />
der zweiten Generation als <strong>IBM</strong> Produkte verfügbar.<br />
<strong>IBM</strong> XIV <strong>Storage</strong> <strong>System</strong><br />
Die Entstehung von XIV <strong>Storage</strong> ist etwas Besonderes! Mit<br />
der neuen XIVArchitektur erblickt der erste Plattensubsystem-Sozialismus<br />
das Licht der Welt! Es ‘menschelt’<br />
nicht, daher funktioniert der Sozialismus perfekt! Wenn<br />
immer die Maschine etwas zu tun hat, sei es etwas auf<br />
Platte wegzuschreiben, von der Platte auszulesen oder sich<br />
intern zu reorganisieren, müssen alle daran arbeiten. Die<br />
integrierten PCs, alle Plattenlaufwerke ohne Ausnahme<br />
arbeiten immer gleichzeitig die anstehende Workload ab.<br />
Dabei hat z. B. jede Platte immmer denselben Füllgrad und<br />
dieselbe Arbeitslast. Wächst das <strong>System</strong> in der Kapazität,<br />
stehen mehr ‘Arbeiter’, also mehr Plattenlaufwerke, zur Verfügung<br />
und steigern die Leistungsfähigkeit und den Durchsatz<br />
des Gesamtsystems. Das ist der perfekte Sozialismus!<br />
XIV-Architektur<br />
Ein wesentliches Merkmal der <strong>IBM</strong> XIV<strong>System</strong>e ist die hohe<br />
Parallelität durch eine modulare GRIDArchitektur. Anders<br />
als traditionelle <strong>System</strong>e gibt es nicht nur zwei Controller,<br />
die sämtliche I/Os verarbeiten müssen, sondern mehrere<br />
voneinander unabhängige Module. Diese Module bestehen<br />
aus StandardServern mit optimiertem LinuxBetriebssystem.<br />
Die hohe Parallelität wird nun dadurch ermöglicht, dass ein<br />
patentiertes LoadBalancingVerfahren sämtliche I/Os über<br />
alle <strong>System</strong>komponenten verteilt: Module, Switche, Caches<br />
und Disks.<br />
XIV-Standard-Hardware<br />
Ein <strong>IBM</strong> XIV <strong>Storage</strong> <strong>System</strong> besteht aus mehreren Modulen,<br />
jedes Modul mit eigenen CPUs, eigenem CacheSpeicher<br />
und eigenen (lokalen) Disks. Einige Module besitzen darüber<br />
hinaus FibreChannel und iSCSIInterfaces, die zur<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
97
98<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
XIV GRID-Architektur mit verteiltem Speicher, Caches und CPUs<br />
redundanten Anbindung der Hosts dienen. Diese Module<br />
werden auch als InterfaceModule bezeichnet. Als Betriebssystem<br />
auf den Modulen (Servern mit Intel CPUs neuester<br />
Generation) dient ein optimiertes Linux, was allerdings für<br />
den Anwender transparent ist. Die Kommunikation der<br />
Module erfolgt über zwei GigabitEthernetSwitche. Die hohe<br />
Performance wird durch die Parallelisierung aller I/Os<br />
erreicht, welche sich stets über alle Module erstreckt.<br />
Ein voll ausgebautes XIVRack besteht aus:<br />
•<br />
•<br />
•<br />
•<br />
15 Modulen mit jeweils<br />
-<br />
-<br />
-<br />
Intel Quad-Core CPUs<br />
8 GB RAM (Cache)<br />
4x Gigabit Ethernet für die interne Kommunikation<br />
- 12 Disk-Drives (1 TB SATA II)<br />
6 Interface-Module mit insgesamt<br />
- 24 x 4 GB FC-Adapter<br />
- 6 x 1GB iSCSI-Adapter<br />
2 Gigabit-Ethernet-Switche für die interne Kommunikation<br />
3 unterbrechungsfreie Stromversorgungseinheiten<br />
Beim Einsatz von 1 TB Disks ergibt sich also eine Bruttokapazität<br />
von 15 * 12 * 1 TB = 180 TB. Durch die hohe I/O<br />
Parallelität können im Vergleich zu FibreChannelDisks langsamere<br />
Disks mit SATAIITechnologie verwendet werden,<br />
ohne dass dadurch die <strong>System</strong>performance langsamer<br />
wäre als bei traditionellen HighEndSpeichersystemen mit<br />
FibreChannelDisks. Der Vorteil bei der Verwendung der<br />
StandardKomponenten für die Module und den Interconnect<br />
besteht darin, dass neue Technologieentwicklungen<br />
rasch und ohne Neuentwicklungen eingesetzt werden können.<br />
Stehen beispielsweise schnellere Module in Form von<br />
StandardServern oder neue Adapter zur Verfügung, können<br />
diese sofort ausgetauscht werden. Gleiches gilt für die InterconnectSwitche.<br />
Derzeit ist jedes Modul über 4Gigabit<br />
EthernetVerbindungen angeschlossen. Auch der Austausch<br />
durch 10GigabitEthernetSwitche oder Infiniband ließe sich<br />
kurzfristig realisieren (selbstverständlich verzögern eventuell<br />
notwendige SoftwareAnpassungen und vor allem Integrationstests<br />
den Einsatz neuer Technologien).<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Datenverteilung und Load Balancing<br />
Um eine möglichst granulare und gleichmäßige Verteilung<br />
der Daten und I/OOperationen zu ermöglichen, verteilt das<br />
<strong>System</strong> jedes vom Administrator angelegte Volume immer<br />
auf 16.384 (oder ein Vielfaches davon) primäre und<br />
genauso viele sekundäre Partitionen mit einer Größe von<br />
jeweils 1 MB:<br />
•<br />
•<br />
Die Partitionen werden nach einem ‘pseudo-zufälligen’<br />
Algorithmus auf alle Disks (und damit über alle Module)<br />
verteilt. Dies gilt grundsätzlich für alle Volumes, wodurch<br />
immer eine optimale Performance für alle Volumes erreicht<br />
wird.<br />
Eine Partition enthält dabei entweder eine primäre oder<br />
sekundäre Kopie der Daten. Primäre und sekundäre Daten<br />
werden stets in unterschiedlichen Modulen, also auch auf<br />
unterschiedlichen Disks gespeichert.<br />
Das Verteilungsverfahren arbeitet autonom und dynamisch.<br />
Fällt z. B. eine Disk aus oder wird aus dem <strong>System</strong> entfernt,<br />
werden sofort alle darauf befindlichen (primären oder<br />
sekundären) 1 MBPartitionen von allen anderen Disks neu<br />
kopiert bzw. verteilt. Dadurch arbeitet diese Wiederherstellung<br />
extrem schnell. Kopiert werden dabei übrigens nur Partitionen,<br />
die tatsächlich Daten enthalten. In der Praxis sind<br />
die Daten einer 1 TB SATAIIDisk innerhalb weniger Minuten<br />
wieder redundant. Die maximale Dauer zur Herstellung<br />
einer 1TBDisks beträgt 30 Minuten. Die Wiederherstellung<br />
einer ausgefallenen Disk in einem RAID5 oder RAID6Array<br />
dauert in der Regel mehrere Stunden, manchmal Tage.<br />
Zusätzlich ist während dieser langen Zeitspanne die Perfor<br />
mance des <strong>System</strong>s herabgesetzt, da beim Zugriff auf<br />
Daten dieses Volumes zusätzliche XOROperationen notwendig<br />
sind.<br />
Da ja primäre und sekundäre Partitionen immer über Module<br />
hinweg „gespiegelt“ werden, können sogar mehrere Disks<br />
innerhalb eines Moduls oder gar ein komplettes Modul ausfallen,<br />
da selbst dann immer noch eine intakte Datenkopie<br />
im <strong>System</strong> vorhanden ist. Auch in diesen Fällen beginnt das<br />
<strong>System</strong> sofort im Hintergrund die fehlenden Kopien neu zu<br />
erzeugen, immer unter Erhaltung der Gleichverteilung und<br />
damit einer gleichmäßigen Auslastung aller <strong>System</strong>komponenten.<br />
Das Modul, das für eine IOOperation eine primäre Partition<br />
beschreibt, sendet parallel zum lokalen IO den gleichen<br />
Datenblock für die sekundäre Kopie an ein anderes Modul.<br />
Erst wenn beide Module die Datenblöcke im Cache haben,<br />
wird dem Host die IOOperation bestätigt. Das Schreiben<br />
der Datenblöcke auf die jeweils lokalen Caches erfolgt im<br />
Hintergrund.<br />
Vergleich zu bekannten RAID Verfahren<br />
Das dargestellte Verteilungsverfahren der Daten entspricht<br />
keinem der üblichen RAID1 bis RAID10Mechanismen. Von<br />
den Eigenschaften ist es einem RAID10Verfahren am ähnlichsten,<br />
bei dem die Datenblöcke verteilt (engl. striping) und<br />
gespiegelt werden. Würde man 180 Disks in einem RAID10<br />
Array konfigurieren, wäre die Performance beider Disk<br />
Anordnungen zu Beginn des Betriebes identisch. In der Praxis<br />
verflüchtigt sich dieser „Gleichstand“ aber recht schnell:<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
99
100<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
•<br />
•<br />
Bei Kapazitätserweiterungen oder Änderung von Volume-<br />
Größen ist die Gleichverteilung bei RAID-Arrays nicht mehr<br />
gewährleistet. Manuelle Nacharbeit am <strong>Storage</strong>- und Hostsystem<br />
(Rebuild des Stripings etc.) ist arbeitsintensiv und<br />
finden oft nicht statt. Manchmal müssen für solche Operationen<br />
ganze Arrays oder Volumes umgezogen werden.<br />
Eine Gleichverteilung aller I/Os über alle <strong>System</strong>komponenten<br />
erfordert bei traditionellen <strong>System</strong>en genaue<br />
Kenntnis der Architektur und aller Virtualisierungsschichten.<br />
Diese Arbeiten können häufig nur von Spezialisten<br />
durchgeführt werden. Das Auslagern solcher Tätigkeiten<br />
an die Anwender ist nicht möglich.<br />
Wie bereits erwähnt, sind derlei Maßnahmen bei XIV<strong>System</strong>en<br />
nicht nötig (und auch nicht möglich), da der Verteilungsalgorithmus<br />
autonom und dynamisch arbeitet. Sobald<br />
das <strong>System</strong> zusätzliche Module bekommt, beginnt das<br />
<strong>System</strong> mit der Umverteilung der 1MBPartitionen, um wieder<br />
eine Gleichverteilung über alle <strong>System</strong>ressourcen zu<br />
erlangen. Auch wenn Module oder Disks entfernt werden,<br />
beginnt eine Neuverteilung, um eine Gleichverteilung und<br />
Verteilung der 1-MB-Partitionen eines Volumes auf alle Disks im <strong>System</strong>.<br />
Wiederherstellung vollständiger Datenredundanz zu erlangen.<br />
Im Gegensatz zu RAID5 oder RAID6Verfahren arbeitet<br />
die Wiederherstellung jedoch sehr viel schneller, weil alle<br />
verbleibenden Disks an den notwendigen IOOperationen<br />
beteiligt sind und außerdem der Zugriff auf die Daten in dieser<br />
Zeit keine zusätzlichen XOROperationen erfordert.<br />
Diese Eigenschaften führen dazu, dass das XIV<strong>System</strong> trotz<br />
langsamerer SATAIITechnologie eine höhere Performance<br />
und eine höhere Verfügbarkeit besitzt als klassische High<br />
End RAID<strong>System</strong>e mit FibreChannelTechnologie.<br />
Verteilte Caches<br />
Auch hinsichtlich der Caches sorgt die verteilte Architektur<br />
für Vorteile gegenüber DualController <strong>System</strong>en. Die unabhängigen<br />
Caches sind jeweils nur für die in den Modulen<br />
vorhanden 12 Disks zuständig. Dies gewährleistet eine minimale<br />
Latenzzeit und maximale Bandbreite. Für das Schreiben<br />
der Daten vom Cache auf die Disks steht die volle<br />
Bandbreite von zwei dedizierten PCIX Bussen zur Verfügung.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Die gesamte CPULeistung eines Moduls steht ausschließlich<br />
für diesen lokalen Cache zur Verfügung, was u. a. drei<br />
Dinge ermöglicht:<br />
•<br />
•<br />
•<br />
Aggressives Im-Voraus-Lesen (engl. prefetching) von<br />
Datenblöcken mittels intelligenter Algorithmen.<br />
Sehr kleine Datenblöcke im Cache. Traditionelle <strong>System</strong>e<br />
arbeiten aufgrund eines einfacheren Cache-Managements<br />
meist mit Datenblöcken von 32 oder 64 KB. Das XIV-<br />
<strong>System</strong> kann aufgrund der hohen lokalen CPU-Leistung<br />
mit 4-KB-Blöcken arbeiten, was eine sehr effiziente Cache-<br />
Nutzung zur Folge hat.<br />
Eine Cache-Synchronisation ist nicht notwendig, weil jeder<br />
Cache nur für seine lokalen Daten bzw. Disks zuständig ist.<br />
Auch hinsichtlich einer für HighEnd<strong>System</strong>e notwendigen<br />
Verfügbarkeit hat eine verteilte CacheStruktur Vorteile:<br />
Selbst beim Ausfall eines gesamten Moduls geht bei einem<br />
EinRack<strong>System</strong> nur ein Fünfzehntel der CacheKapazität<br />
und Leistung verloren.<br />
Sämtliche Caches sind durch redundante unterbrechungsfreie<br />
Stromversorgungseinheiten (UPS) abgesichert. Das<br />
<strong>System</strong> besitzt insgesamt drei solcher UPSEinheiten, die<br />
sich permanent zwischen dem öffentlichen Netz und den<br />
Modulen befinden, sodass diese kurzfristigen Ausfälle oder<br />
Spannungsspitzen verborgen bleiben. Erst bei einem Ausfall<br />
von mehr als 30 Sekunden fängt das <strong>System</strong> an, geordnet<br />
herunterzufahren. Ein bei anderen <strong>System</strong>en übliches Write<br />
ThroughVerfahren beim Ausfall eines Controllers oder bei<br />
Stromausfällen ist also bei XIV nicht notwendig.<br />
Speicherkapazität<br />
Wie bereits beschrieben, besitzt jedes Modul 12 lokale<br />
Disks. Beim Einsatz von 1 TB SATAII Disks ergibt sich somit<br />
für ein volles EinRack<strong>System</strong> eine Bruttokapazität von:<br />
K (Brutto) = 12 Disks * 15 Module * 1 TB = 180 TB<br />
Wie im Kapitel Datenverteilung und Load Balancing<br />
beschrieben, werden stets alle Daten über alle Disks verteilt<br />
und zwar redundant. Dedizierte SpareDisks, die im Normalbetrieb<br />
nichts tun, gibt es hier nicht. Dennoch muss natürlich<br />
so viel Kapazität in „Reserve“ gehalten werden, wie Disk<br />
ausfallen können sollen. Für diese Reservezwecke werden<br />
die 12 Disks eines kompletten Moduls plus drei zusätzliche<br />
berücksichtigt. Ferner benötigt das <strong>System</strong> für interne Zwecke<br />
ca. 3,5 TB. Daraus ergibt sich für die Nettokapazität:<br />
K (Netto) = (15 * 12 – 12 – 3) * 1TB / 2 – 3,5 TB = 79,5 TB<br />
Werden mehr oder weniger als 15 Module verwendet,<br />
vermindert bzw. vergrößert dies die Nettokapazität entsprechend.<br />
XIV-Funktionen<br />
Thin Provisioning<br />
Mit Hilfe des Thin Provisionings lassen sich Speicherkapazitäten<br />
effektiver nutzen. Bei einem traditionellen <strong>System</strong> wird<br />
der für ein Volume vorgesehene Speicherplatz sofort allokiert<br />
und steht somit anderen Anwendungen nicht mehr zur<br />
Verfügung und zwar auch dann nicht, wenn der Speicherplatz<br />
gar nicht genutzt wird. Das führt in der Praxis zu einer<br />
sehr schlechten Auslastung. Anwender wollen nämlich von<br />
vornherein so viel Speicherplatz reserviert haben, wie auf<br />
absehbare Zeit notwendig ist, weil andernfalls spätere<br />
manuelle Nacharbeit notwendig ist. Beim XIV<strong>System</strong> hingegen<br />
kann ein Volume im Prinzip beliebig groß sein. Ist<br />
beispielsweise für eine neue Anwendung bekannt, dass das<br />
Datenvolumen in drei Jahren 10 TB beträgt, kann gleich ein<br />
Volume mit entsprechender Größe angelegt werden. Der tatsächlich<br />
belegte Speicherplatz entspricht lediglich dem der<br />
wirklich gespeicherten Daten. Ist irgendwann der physikalische<br />
Speicherplatz des <strong>System</strong>s (oder Pools) erschöpft,<br />
können einfach neue Module hinzugefügt werden. Der Verteilungsalgorithmus<br />
sorgt sofort für eine Neuverteilung der<br />
Daten und die Kapazität ist erweitert. Auch hier ist also keinerlei<br />
Nacharbeit notwendig.<br />
Diese Überprovisionierung ist übrigens nicht systemweit<br />
gültig, sondern jeweils nur innerhalb eines <strong>Storage</strong>Pools.<br />
Ein Pool stellt eine administrative Domain dar, innerhalb<br />
derer eine QuotaVerwaltung möglich ist.<br />
Was passiert nun, wenn diese Überprovisionierung für viele<br />
Volumes erfolgt, diese über die Zeit wachsen und die physikalischen<br />
Kapazitätsgrenzen erreicht werden? Wie in jedem<br />
<strong>Storage</strong><strong>System</strong> wird die Kapazitätsauslastung überwacht.<br />
Bei Überschreiten konfigurierbarer Kapazitätsgrenzen wird<br />
der Administrator benachrichtig (SNMP, SMS oder EMail).<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
101
102<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
Reagiert dieser nicht, beginnt das <strong>System</strong> bei kritischer<br />
Auslastung Snapshots zu löschen. Dabei priorisiert das<br />
<strong>System</strong> nach Wichtigkeit (beim Anlegen von Snapshots konfigurierbar)<br />
und nach Alter. Reichen auch diese Maßnahmen<br />
nicht mehr, kann das <strong>System</strong>verhalten auf zwei Reaktionen<br />
konfiguriert werden: Entweder werden alle Volumes gelockt<br />
oder auf ‘readonly’ gesetzt. In jedem Fall bleibt aber die<br />
Datenintegrität erhalten.<br />
Durch das Thin Provisioning wird in der Praxis die Speicherauslastung<br />
um 20–30% verbessert.<br />
Snapshots<br />
XIV<strong>System</strong>e sind mit extrem schnellen und einfach zu<br />
handhabenden SnapshoMechanismen ausgestattet. Der<br />
beschriebene Verteilungsalgorithmus der Daten setzt<br />
voraus, dass Verteilungstabellen die Informationen beinhalten,<br />
welche Datenblöcke auf welchen Disks gespeichert<br />
sind. Wird nun für ein Volume oder eine Gruppe von<br />
Volumes ein Snapshot erzeugt, werden lediglich diese Meta<br />
Informationen gespeichert. Dies ist eine reine Memory Operation,<br />
die immer ca. 150 ms dauert, unabhängig von der<br />
Größe eines Volumes (dies gilt ebenso für das Löschen von<br />
Snapshots). Auch der verwendete Speicherplatz für ein<br />
Snapshot ist zu diesem Zeitpunkt gleich null. Erst wenn<br />
Datenblöcke verändert werden, sorgt ein ‘redirectonwrite’<br />
dafür, dass der modifizierte Datenblock an eine andere<br />
Stelle geschrieben wird. Diese Technik ist schneller als das<br />
übliche ‘copyonwrite’ Verfahren, da eine Schreiboperation<br />
weniger notwendig ist.<br />
XIVSnapshots führen deshalb in der Praxis zu keiner Perfor<br />
manceEinbuße. Pro <strong>System</strong> können bis zu 16.000<br />
Snapshots erzeugt werden.<br />
Volume-Kopien<br />
Selbstverständlich können auch VolumeKopien erzeugt<br />
werden. VolumeKopien können – wie Snapshots – sofort<br />
nach deren Initiierung verwendet werden. Das physikalische<br />
Kopieren läuft im Hintergrund, bis alle Datenblöcke kopiert<br />
sind.<br />
Beschreibbare Snapshots<br />
Ein Snapshot kann jedem beliebigen Host zugewiesen werden.<br />
Dies ist oft hilfreich für eine Weiterverarbeitung der<br />
Daten, z. B. Erzeugen von Backups oder als Datenquelle für<br />
ein DataWarehouse. Standardmäßig kann auf Snapshots<br />
dabei nur lesend zugegriffen werden. Bei Bedarf können<br />
Snapshots aber auch mit einem Handgriff als beschreibbar<br />
(engl. writeable) markiert werden. Dies ist oft hilfreich für<br />
Tests oder andere Szenarien, bei denen auf die Daten<br />
schreibend zugegriffen werden muss.<br />
Snapshots von Snapshots<br />
Manchmal ist es wünschenswert, von einem Snapshot eine<br />
weitere logische Kopie zu haben. XIV<strong>System</strong>e können mit<br />
demselben Mechanismus mehrere Kopien eines Snapshots<br />
erzeugen. So könnte ein Snapshot z. B. als beschreibbar<br />
markiert werden, während die zweite Kopie für ein Backup<br />
dient.<br />
Consistency Groups<br />
Für manche Anwendung ist es wichtig, konsistente<br />
Snapshots zu erzeugen, wenn die Anwendung mehrere<br />
Volumes benutzt. Dies trifft z. B. auf Datenbanken zu, wenn<br />
diese ihre LogDateien auf separaten Volumes speichert.<br />
Für diese Fälle können mehrere Volumes zu Konsistenzgruppen<br />
(engl. Consistency Groups) zusammengefasst werden.<br />
Beim Erzeugen eines Snapshots ist dann sichergestellt,<br />
dass selbige konsistente Daten enthalten, d. h., dass<br />
der Zeitstempel der verschiedenen Volumes identisch ist.<br />
Volumes einer Konsistenzgruppe müssen alle demselben<br />
<strong>Storage</strong>Pool angehören.<br />
Automatischer Snapshot bei entfernter Spiegelung<br />
XIV<strong>System</strong>e erzeugen vor einem Synchronisationsprozess<br />
entfernter Spiegel automatisch einen sogenannten ‘lastconsistencysnapshot’<br />
auf dem Zielsystem. Der Grund hierfür ist<br />
die Sicherstellung eines konsistenten Zustands für den<br />
Fall, dass während des Synchronisationsprozesses das<br />
Quellsystem ausfällt oder die Verbindung unterbrochen wird.<br />
In diesem Fall ist es möglich, dass das Zielsystem einen<br />
inkonsistenten Zustand hat. Der automatische Snapshot<br />
kann dann verwendet werden, um zu einem definierten,<br />
konsistenten Zustand zurückzukehren. Diese automatischen<br />
Snapshots haben eine DeletionPriority von null, d.h., sie<br />
werden im Falle einer Überprovisionierung eines Pools nicht<br />
automatisch gelöscht.<br />
Remote Mirroring/Disaster Recovery<br />
Für katastrophenresistente Installationen ist es möglich, entfernte<br />
Spiegel (engl. Mirror) auf einem anderen XIV<strong>System</strong><br />
zu erzeugen. Dies kann entweder über dedizierte iSCSI<br />
oder FibreChannelPorts implementiert werden.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Derzeit werden zwei Möglichkeiten der synchronen Spiegelungen<br />
unterstützt:<br />
Best Effort:<br />
Beim Ausfall des Kommunikationspfades oder des Zielsystems<br />
kann weiter auf dem primären <strong>System</strong> gearbeitet werden.<br />
Sobald der Link wieder zur Verfügung steht, werden<br />
die in dieser Zeit geänderten Blocks nachträglich resynchronisiert.<br />
Mandatory:<br />
Beim Ausfall des Kommunikationspfades oder des Zielsystems<br />
sind keine Schreibzugriffe mehr auf dem primären<br />
<strong>System</strong> möglich. Diese Art der Implementierung erfordert<br />
besondere Sorgfalt bei der Planung des gesamten SANs.<br />
Alle Komponenten (Fabrics, Links, Switche etc.) sollten<br />
redundant ausgelegt sein.<br />
Spiegel können pro Volume angelegt werden und es können<br />
mehrere ZielVolumes definiert werden.<br />
An einem Zielsystem angeschlossene Hosts können die<br />
Volumes zwar sehen, diese befinden sich aber im ‘readonly’<br />
Modus. Wird im Falle eines Disasters das sekundäre Zielsystem<br />
zum primären <strong>System</strong>, können die Volumes beschrieben<br />
werden. Die Volumes des ehemals primären <strong>System</strong>s werden<br />
nun zu sekundären Volumes und sind für diesen Zeitraum<br />
nur lesbar (readonly).<br />
Energieverbrauch<br />
Durch die GRIDArchitektur und die beschriebenen I/O<br />
LoadBalancingMechanismen können selbst für sehr hohe<br />
PerformanceAnforderungen Disks mit hoher Speicherdichte<br />
und SATAIITechnologie verwendet werden. Um eine entsprechende<br />
Performance zu erreichen, müssen traditionelle<br />
<strong>System</strong>e FCDisks verwenden, die nicht nur wesentlich<br />
teurer sind, sondern vor allem mehr Energie verbrauchen,<br />
weil sie erstens schneller drehen und zweitens für die gleiche<br />
Kapazität mehr Disks benötigt werden.<br />
Ein vollständig ausgebautes XIVRack mit 180 Disks und<br />
einer Bruttokapazität von 180 TB hat einen Energieverbrauch<br />
von 7,7 kW. Dies entspricht einem Verbrauch von 43 W pro<br />
TB Datenvolumen. Traditionelle <strong>Storage</strong> <strong>System</strong>e mit 146GB<br />
FCDisks haben einen Verbrauch von 180–380 W pro TB.<br />
Energieverbrauch traditioneller <strong>System</strong>e mit FC-Disks vs. XIV<br />
Auch andere Eigenschaften der XIVArchitektur helfen, den<br />
Energieverbrauch zu senken:<br />
Physikalische Kapazität wird nur „verbraucht“, wenn die<br />
Anwendung tatsächlich Daten schreibt, jedoch noch nicht<br />
beim Anlegen eines Volumes. Das Thin Provisioning erlaubt<br />
es somit, eine Überprovisionierung vorzunehmen, was bis<br />
zu 30% weniger nicht genutzte Kapazität bedeutet.<br />
Durch das gleichmäßige Verteilen der Daten eines Volumes<br />
auf alle Disks im <strong>System</strong> entstehen keine ungenutzten „Reststücke“,<br />
die häufig dann entstehen, wenn verschiedene<br />
RAIDArrays für verschiedene Zwecke konfiguriert werden<br />
bzw. Volumes auf verschiedene Arrays verteilt werden müssen.<br />
Management<br />
Das einfache Management von XIV<strong>System</strong>en macht deren<br />
große Stärke aus. Aufgrund des beschriebenen dynamischen<br />
und autonomen Verteilungsverfahrens der Daten<br />
auf alle Volumes entfällt beispielsweise vollständig die<br />
Planung hierfür. Bei traditionellen <strong>System</strong>en ist hier oft eine<br />
aufwendige Planung und Vorarbeit erforderlich, um für die<br />
verschiedenen Anwendungen eine optimale Performance<br />
und Verfügbarkeit zu gewährleisten. Ferner müssten die Einstellungen<br />
bei <strong>System</strong>veränderungen nachgezogen werden,<br />
was wiederum arbeitsintensiv ist. All diese Dinge entfallen<br />
bei XIV<strong>System</strong>en vollständig. Gleiches gilt auch für die<br />
Platzierung von Snapshots. Auch hier sind keine besonderen<br />
Vorkehrungen zu treffen.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
103
104<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
Benutzerschnittstellen<br />
Das Management von XIV<strong>System</strong>en ist über drei Wege<br />
möglich:<br />
Eine grafische Benutzeroberfläche (GUI). Diese ist intuitiv<br />
bedienbar, die vollständige Administration eines XIV<br />
<strong>System</strong>s ist in wenigen Stunden erlernbar. Geübte <strong>Storage</strong><br />
Administratoren kommen häufig sofort ohne Vorbereitung<br />
zurecht. Eine Demo für grafische Benutzeroberflächen<br />
befindet sich auf der XIVWebSeite:<br />
http://www.xivstorage.com/demo/GUI_Demo.html<br />
Ein Kommandozeileninterface (CLI). Hier können alle administrativen<br />
Aufgaben per Kommandozeile eingegeben oder<br />
durch Skripte automatisiert werden.<br />
SMISkonforme<strong>Storage</strong>Management Werkzeuge: <strong>Storage</strong><br />
Tools, wie z.B. das Tivoli Productivity Center, können<br />
verwendet werden, um XIV<strong>System</strong>e zu administrieren.<br />
Ansicht Statistikdaten über die GUI<br />
Statistikdaten<br />
Neben den regulären Administrationsaufgaben können auch<br />
Statistikdaten über die genannten Benutzerschnittstellen<br />
abgerufen werden. Das <strong>System</strong> speichert die Performance<br />
Daten eines Jahres. So können beispielsweise I/Os pro<br />
Sekunde oder Durchsatzzahlen in MB/s aus jedem Zeitfens ter<br />
innerhalb der letzten 12 Monate abgerufen und genauer<br />
untersucht werden. Bei der Ausgabe kann z. B. gefiltert<br />
werden auf:<br />
Interfaces<br />
Hosts<br />
Volumes<br />
Targets<br />
Cache Hit/Miss-Raten<br />
Read, Write oder Read/Write<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
und vieles mehr. Selbstverständlich können diese Daten<br />
über das CLI auch zur Weiterverarbeitung in andere Tools<br />
exportiert werden.
Interoperabilität<br />
XIV<strong>System</strong>e können an allen gängigen offenen <strong>System</strong>en<br />
betrieben werden, die iSCSI und/oder FibreChannelSpeichersysteme<br />
unterstützen. Dazu gehören z. B. AIX, Solaris,<br />
HPUX, Linux und die verschiedenen WindowsVarianten.<br />
Auch gängige ClusterLösungen unterstützen die XIV<strong>Storage</strong><br />
<strong>System</strong>e.<br />
Release XIV <strong>Storage</strong> <strong>System</strong> Software Version 10.2<br />
Im November 2009 kündigt <strong>IBM</strong> für XIV den Release 10.2<br />
an, der folgende Erweiterungen einführt:<br />
Asynchrones Spiegeln von XIVVolumes und Consistency<br />
Groups und die Unterstützung des Thin Provisioning Space<br />
Reclamation Features der Veritas <strong>Storage</strong> Foundation.<br />
DS3000 Platten Entry <strong>System</strong><br />
Im Februar 2007 überraschte <strong>IBM</strong> den Markt mit der Ankündigung<br />
eines EntryPlattensystems, der DS3000. Das<br />
<strong>System</strong> wird wie die DS4000Reihe von der Firma LSI<br />
gebaut und als <strong>IBM</strong> LogoProdukt vertrieben. Am Anfang<br />
war das <strong>System</strong> nur über den Vertriebskanal <strong>IBM</strong> <strong>System</strong> x<br />
beziehbar. Als die ersten Performance Benchmarks ergaben,<br />
in welche ansehnliche Leistungsklasse die Maschine<br />
skaliert, wurde das <strong>System</strong> im April 2007 in den gesamten<br />
<strong>Storage</strong>Vertrieb der <strong>IBM</strong> integriert.<br />
Die DS3000Familie zeichnet sich im Allgemeinen durch ein<br />
hervorragendes PreisLeistungsVerhältnis aus und bietet<br />
einen extrem günstigen Einstiegspreis. Es stehen drei<br />
Modelle zur Verfügung.<br />
Die DS3200 zeichnet sich durch 6 SASHostanschlüsse aus.<br />
Die DS3300 zeichnet sich durch maximal 4 x 1 Gbit Ethernet<br />
iSCSIHostanschlüsse aus. Die DS3400 zeichnet sich<br />
durch maximal 4 FibreChannelPorts aus, die in den<br />
Geschwindigkeiten 4, 2 und 1 Gbps arbeiten können. Die<br />
Platten und BackendTechnologie ist in allen drei Modellen<br />
SAS mit der Möglichkeit, auch SATAPlatten anzubinden.<br />
Anfangs standen ausschließlich 300GBSASPlatten (Serial<br />
Attached SCSI) zur Verfügung bei einer maximalen ausbaubaren<br />
Kapazität von bis zu 14,4 TB. Seit Oktober 2007 können<br />
auch 750GBSATAPlatten integriert werden. Damit skalieren<br />
die <strong>System</strong>e auf eine maximale Kapazität von 35,2 TB.<br />
Der Mischbetrieb von SASPlatten und SATAPlatten wurde<br />
sichergestellt.<br />
Allgemein zeichnen sich die Modelle durch eine geringe<br />
Bauhöhe von nur 2U aus sowie eine Skalierbarkeit von bis<br />
zu 48 Festplatten. In der Kopfeinheit können bis zu 12 Festplatten<br />
untergebracht werden. Der Controller und damit das<br />
Gesamtsystem ist über die Erweiterungseinheiten EXP3000<br />
(bis zu 3 weiteren Einheiten) ausbaubar.<br />
Seitens der Betriebssysteme hat die DS3000Familie eine<br />
geringeres Portfolio an anschließbaren Betriebssystemen.<br />
Hier werden die <strong>System</strong>e Windows, Linux und Novell<br />
standardmäßig angeboten. Zusätzlich bietet die Maschine<br />
je nach Modell die Anschlussmöglichkeit von VMware, SVC<br />
(San Volume Controller) oder AIX.<br />
Rück- und Frontansicht der DS3000<br />
Jedes Modell besitzt einen EthernetZugang für das<br />
Management. Zusätzlich kann die Maschine auch über die<br />
Host Connectivity administriert werden. Mit 512 MB RAM<br />
pro Controller steht ausreichend Speicher für das Caching<br />
zur Verfügung. Dieser Speicher kann mit weiteren 512 MB<br />
pro Controller erweitert werden. Dies ergibt eine maximale<br />
CacheGröße von 2 GB pro <strong>System</strong>.<br />
Trotz „Entrysystem“ wird bei der DS3000 auf redundante<br />
Komponenten nicht verzichtet. Die DS3000 hat auch bei<br />
einer SingleControllerVariante redundant ausgelegte Lüfter<br />
und Netzteile.<br />
Der DS3000 <strong>Storage</strong> Manager ist analog zum DS4000<br />
Manager ebenfalls intuitiv zu bedienen und leicht zu installieren.<br />
Der initiale Setup der Maschine erfolgt in 6 Dialoggeführten<br />
Schritten und sollte innerhalb von 45 Minuten vollzogen<br />
sein, d. h., nach spätestens 45 Minuten sind die<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
105
106<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
Positionierung der Entry <strong>System</strong>e DS3000 zu den bestehenden DS4000-<strong>System</strong>en (P= Performance, F=Funktionalität)<br />
ersten Volumes den angeschlossenen Servern bekanntgegeben.<br />
Der DS3000 <strong>Storage</strong> Manager unterstützt die<br />
RAIDLevel 0, 1, 3, 5 und 10.<br />
Durch den Recovery Guru und durch automatische Benachrichtigungen<br />
erhält man proaktiv, auch schon vor Crash<br />
Situationen, Meldungen über eventuelle Fehler oder<br />
Überschreitungen von Schwellwerten. Die Benachrichtigung<br />
erfolgt über SNMP und/oder per EMail.<br />
Im Februar 2008 kündigte <strong>IBM</strong> für alle drei DS3000Modelle<br />
1.000 GB (1 TB) SATA-Platten an. Damit bekommt das<br />
Entry<strong>System</strong> DS3000 als erstes Plattensystem der <strong>IBM</strong> die<br />
Möglichkeit, Platten mit 1 TB an Kapazität zu verwenden. Mit<br />
diesen Platten kann jede Erweiterungseinheit mit 12 TB<br />
Plattenplatz konfiguriert werden. Das Gesamtsystem,<br />
bestehend aus Kopfeinheit und drei Erweiterungseinheiten,<br />
liefert mit den 1 TB SATAPlatten eine maximale Kapazität<br />
von 48 TB aus.<br />
Für die DS3300 steht ein neues Modell 32T zur Verfügung,<br />
das speziell für TelcoUmgebungen ein 48 V basierendes<br />
doppeltes Netzteil auf Gleichstrombasis in der Controller<br />
Einheit integriert hat (iSCSI DCPowered Controller). Damit<br />
kann die DS330032T problemlos in TelcoUmgebungen eingesetzt<br />
werden.<br />
DS5000 Plattensysteme<br />
Der August 2008 stand ganz im Zeichen der Ankündigung<br />
des neuen Midrange ‘Flagship’ DS5000, die das Produktportfolio<br />
nach oben abrunden sollte. Das bewährte HardwareDesign<br />
mit der austauschbaren Midplane der DS4800<br />
übernehmend, wurde das <strong>System</strong> mit einigen weiteren<br />
Funktionen ausgestattet. So lassen sich bei der aus zwei<br />
Produkten bestehenden DS5000Familie (DS5100 und<br />
DS5300) die HostSchnittstellenKarten (kurz HIC, Host<br />
Interface Cards) modular austauschen. Dem Anwender steht<br />
die Anschlussmöglichkeit über 1 GBit iSCSI, wahlweise<br />
auch über 4 Gbit oder 8 Gbit FC zur Verfügung.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Ebenso wurde die kapazitive Skalierbarkeit von bisher 224<br />
Platten bei der DS4800 auf 448 Platten angehoben. Damit<br />
einhergehend wurden die Anzahl der DiskBackendKanäle<br />
auf sechzehn 4GbitFCKanäle verdoppelt.<br />
Beim Design der <strong>Storage</strong> Controller wurde hier wieder<br />
Augenmerk auf die lineare Skalierbarkeit bis zur letzten<br />
Platte gelegt. Die RAIDBerechnung erfolgt über einen eigenen<br />
ASIC. Diese beiden Eigenschaften sorgen für eine hervorragende<br />
Leistung im Bereich von Transaktionen und<br />
Datendurchsatz. Beides wird eindrucksvoll durch die SPC1und<br />
SPC2Tests belegt (www.storageperformance.org).<br />
Eine Neuerung gegenüber allen anderen MidrangeProdukten<br />
im <strong>IBM</strong> Portfolio stellt eine Veränderung des Cache<br />
Schutzes dar. Während bei allen Vorgängermodellen im Falle<br />
eines Stromausfalls der Cache über eine BackupBatterie bis<br />
zu 72 Stunden gestützt wurde, wird der CacheInhalt bei der<br />
DS5000 mit Hilfe von FlashMemoryBausteinen aufrecht<br />
erhalten. Hierbei wird der Controller selber über eine<br />
Batterie bei einem Stromausfall so lange betrieben, bis der<br />
CacheInhalt auf den permanenten Speicher verlagert<br />
wurde. Danach wird die DS5000 ordentlich heruntergefahren.<br />
Für das Cache Mirroring bei der DS5000 stehen jetzt<br />
dedizierte Kanäle zur Verfügung, um die gesamte interne<br />
Bandbreite des <strong>System</strong>s ohne Einschränkungen nutzen zu<br />
können.<br />
Funktionell wurde die DS5000 gegenüber dem Vorgänger<br />
DS4800 um RAID6 erweitert. Das verwendete RAIDVerfahren<br />
ist dabei P+Q RAID6, ein Industriestandard, der gemeinsam<br />
mit Intel entwickelt wurde.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
107
108<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
Herkömmliche Platte SSD Drive<br />
Im Jahr 2009 erfolgten dann Schritt für Schritt weitere Funk<br />
tionserweiterungen der DS5000Familie:<br />
• Full Disk Encryption Drive (FDE) : Hierbei handelt es sich<br />
um eine FC-Platte, die in der Lage, ist darauf befindliche<br />
Daten über einen auf den Disks befindlichen Key zu verschlüsseln.<br />
Die Freischaltung der Verschlüsselung erfolgt<br />
über einen weiteren, auf dem Speichersystem vorgehaltenen<br />
Key. So ist sichergestellt, dass die Daten bei dem<br />
Entfernen einer FDE-Platte nicht lesbar sind und damit die<br />
darauf befindlichen Daten gegen unberechtigten Zugriff<br />
geschützt sind. Eine Funktion, die gerade bei der Speicherung<br />
von personen- bzw. kundenbezogenen Daten die<br />
Datensicherheit erhöht.<br />
• Anschluss <strong>System</strong> I:<br />
<strong>System</strong> I konnte auch zuvor über<br />
einen VIOS angeschlossen werden, mit der Ankündigung<br />
im Herbst 2009 kam dann aber die Möglichkeit, <strong>System</strong> I<br />
native an eine DS5000 anzuschließen, hinzu. Dies ist eine<br />
Funktion, auf die viele Anwender von <strong>System</strong> I lange<br />
gewartet haben. Diese Eigenschaft in Kombination mit der<br />
gleichzeitigen Möglichkeit, bis zu 64 GB Cache zu unterstützen,<br />
gewährleistet die für die Anwendungen von<br />
<strong>System</strong> I so wichtige Response- und Servicezeit.<br />
• Solid State Disk Drives (SSD) : Im Herbst 2009 angekündigt,<br />
wird die Möglichkeit hinzugefügt, bis zu 20 SSD-Laufwerke<br />
in einer DS5000 zu betreiben. Im Gegensatz zu<br />
einer herkömmlichen Platte (Abbildung), verfügt die SSD<br />
über keine rotierenden bzw. sich bewegenden Bauteile.<br />
Hierdurch entfällt die Rotationslatenz, sodass gerade im<br />
Bereich der Transaktionen eine deutliche Verbesserung<br />
erzielt werden kann. Als typischer Anwendungsbereich<br />
können hier die Log-Bereiche einer Datenbank angesehen<br />
werden. Zum Zeitpunkt der Ankündigung stand die SSD in<br />
der Größe von 73 GB zur Verfügung.<br />
• High Density Enclosure EXP5060:<br />
Neben der 16 Platten<br />
fassenden Erweiterungseinheit EXP5000 und EXP810<br />
steht mit der Ankündigung der EXP5060 eine 60 SATA-<br />
Platten fassende 4U Expansion Unit zur Verfügung. Diese<br />
bietet, verteilt über 5 Schubladen, eine hohe Kapazität<br />
(60 1TB-SATA-Platten) und sehr geringen Platzbedarf. Um<br />
die benötigte Performance zu gewährleisten, ist bei der<br />
EXP5060 erstmals möglich, ein Trunking von mehreren FC-<br />
Backend-Kanälen der DS5000 zu nutzen. Mit der EXP5060<br />
soll primär der HPC- (High Performance Computing) und<br />
Archivierungsmarkt adressiert werden.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Ankündigung DS5020 – das Ende der DS4000-Ära<br />
Mitte 2009 galt es, einen Nachfolger für die DS4700 zu<br />
finden. Zum Ankündigungstermin 25.08.2009 wurde dann<br />
schließlich die DS5020 vorgestellt.<br />
Die DS5020 verfügt, ebenso wie ihr Vorgänger DS4700,<br />
über die Ausbaufähigkeit bis zu 112 Disks, die über mehrere<br />
4GbitKanäle angeschlossen werden. Als Disktypen stehen<br />
Standard FibreChannel, FDE FibreChannel und SATAPlatten<br />
zur Auswahl. Alle Plattentypen können nebeneinander in derselben<br />
Expansionseinheit betrieben werden.<br />
Um den Anforderungen vor allem von virtualisierten Umgebungen<br />
Rechnung zu tragen, wurde bei der ControllerEntwicklung<br />
ein besonderes Augenmerk auf eine ausgewogene<br />
Leistung gelegt. Auf der einen Seite steht eine hervorragende<br />
Performance bei Transaktionen, die einen maximalen<br />
Ausbau sinnvoll erscheinen lässt, und auf der anderen Seite<br />
liefert das <strong>System</strong> sehr beeindruckende Durchsatzergebnisse.<br />
Beide Werte wurden in entsprechenden SPC1 und<br />
SPC2Tests dokumentiert. Der mit Flash Memory abgesicherte<br />
Datencache ist bis auf 4 GByte erweiterbar.<br />
Eine weitere Besonderheit ist die Möglichkeit, im FrontEnd,<br />
also im Anschluss der Server verschiedene Protokolle zu<br />
nutzen. Hier stehen 4/8 Gbit FibreChannel und auch 1 Gbit<br />
iSCSI zur Verfügung. Beide Protokolle können parallel auf<br />
einem Controller betrieben werden und ermöglichen ein entsprechendes<br />
‘SAN Tiering’.<br />
Wie alle Mitglieder der DS4000/DS5000Familie unterstützt<br />
die DS5020 eine Vielzahl von Zusatzfunktionen wie:<br />
<strong>Storage</strong>-Partitionen<br />
FlashCopy<br />
VolumeCopy<br />
RemoteVolume Mirroring.<br />
Disk Encrypton etc.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
•<br />
•<br />
•<br />
•<br />
•<br />
Daten aus bestehenden DS4000<strong>System</strong>en können direkt<br />
auf neue DS5000<strong>System</strong>e, z. B. durch Remote VolumeMirroring<br />
oder in manchen Konstellationen auch durch physische<br />
Migration der Festplattengruppen übernommen werden.<br />
Nach der Ankündigung der DS5020 wird die DS4700 bis<br />
Ende 2009 verfügbar bleiben. Danach wird das Kapitel der<br />
DS4000<strong>Storage</strong>systeme geschlossen.<br />
Um eine für den Betrieb so wichtige Integration der Applikationen<br />
und deren Betriebssystemplattformen zu gewährleis ten,<br />
begleiteten beide Ankündigungen (DS5000 und DS5020)<br />
eine Vielzahl von Lösungsangeboten.<br />
109
110<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
Hier seien exemplarisch genannt:<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
Integration in VMware vCenter über ein PlugIn<br />
Unterstützung von VSS/VDS<br />
SMI-S-Integration<br />
Oracle Enterprise Manager PlugIn<br />
Lösungsangebot für DeDuplikation Lösungen (ProtecTier)<br />
TSM FlashCopy Manager<br />
Backup Integration wie z. B. mit FastBack<br />
Integration in das <strong>System</strong> <strong>Storage</strong> Productivity Center<br />
(SSPC)<br />
Für die gesamte <strong>System</strong>familie steht auch eine vollständige<br />
Integration in die <strong>IBM</strong> Virtualisierungslösung SVC (SAN<br />
Volume Controller) zur Verfügung.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Virtualisierung<br />
SAN Volume Controller SVC – Virtualisierung von Plattensystemen<br />
im SAN-Umfeld<br />
Die ersten Geräte des SAN Volume Controllers SVC waren<br />
im September 2003 verfügbar und sind in der Epoche der<br />
Multiplattform<strong>System</strong>e und des FibreChannel SAN und NAS<br />
beschrieben. Die Konzeption des SVC und die dazugehörige<br />
Software wurde über die Jahre kontinuierlich weiterentwickelt<br />
und der heutige Produktplan des SVC sieht für die nächsten<br />
Jahre viele neue Erweiterungen bezüglich der Hardware<br />
und Software vor. Deshalb ist es notwendig, die Konzeption<br />
und den SVC selbst besser zu verstehen.<br />
Die Administration von Speicherkapazitäten stellt nach wie vor<br />
einen hohen Anteil der ITKosten dar. Virtualisierte Speicherlandschaften<br />
bieten hier eine mögliche Lösung, indem sie<br />
Speichersysteme sowohl unterschiedlicher Bauarten und<br />
Hersteller gemeinsam verwalten und flexibel den Servern<br />
zuweisen können. Eine Speichervirtualisierung mit dem SAN<br />
Volume Controller begegnet diesen Herausforderungen mit<br />
einer skalierbaren Architektur. Viel Aufwand haben viele Unternehmen<br />
in den letzten Jahren betrieben, um sich von einer<br />
dezentralen Speicherlandschaft mit direkt angeschlossenem<br />
Speicher (Direct Attached <strong>Storage</strong>, DAS) hin zu einer zentralen<br />
Speicherlösung mit einem <strong>Storage</strong> Area Network (SAN)<br />
zu entwickeln. Wohl existieren <strong>Storage</strong> Area Networks nicht<br />
flächendeckend, vielfach bilden sie aber bereits den Standard.<br />
In der jetzigen Phase geht es darum, sowohl Serverumgebungen<br />
als auch Speichersysteme weitgehend zu virtualisieren.<br />
Die derzeit existierenden SANLösungen sind oft<br />
recht starre Umgebungen und bilden meist Einzellösungen<br />
für Plattformen bestimmter Hersteller und Fachbereiche. Folglich<br />
sind Änderungen aufwendig und unterbrechen meist den<br />
Anwendungsbetrieb. Falls ein ITBetreiber unterschiedliche<br />
Speichersysteme – unter Umständen mehrerer Hersteller –<br />
installiert hat, benötigt er jeweils unterschiedliche AdministrationsTools.<br />
Auch ist die hardwarebasierende Datenspiegelung<br />
zwischen Speichersystemen unterschiedlicher Bauart<br />
nicht möglich, das Gleiche gilt für Speichersysteme unterschiedlicher<br />
Hersteller.<br />
Administrationsarbeiten geraten damit sehr aufwendig, weil<br />
Plattformwissen und die zugehörige Pflege gleich mannigfach<br />
vorzuhalten ist. Weiterhin lasten heutige Speicherlö<br />
sungen ihre installierten Speicherkapazitäten schlecht aus.<br />
Weltweite Kundenumfragen ergaben, dass die effektive Nutzung<br />
bei etwa 50% liegt. Auch beim Austausch von Speichersystemen<br />
im Rahmen von BusinessContinuityMaßnahmen<br />
war hoher Aufwand notwendig, und zumeist wurde der<br />
Anwendungsbetrieb für die gesamte Migrationsdauer unterbrochen.<br />
Der <strong>IBM</strong> SAN Volume Controller (SVC) erleichert<br />
dies erheblich, indem er Migrationen bei laufendem<br />
Betrieb ermöglicht.<br />
Eine Speichervirtualisierung mit <strong>IBM</strong> SVC bietet gegenüber<br />
traditionellen Speicherlösungen den Vorteil, dass Speicherplatz<br />
weitgehend herstellerunabhängig zugeordnet werden<br />
kann. Hieraus folgt eine einfachere Administration, da<br />
sich die virtuelle Oberfläche unabhängig von den jeweils<br />
installierten Speichersystemen konfigurieren lässt. Die Grundidee<br />
besteht darin, schnell und flexibel Plattenspeicher dort<br />
zuordnen zu können, wo gerade Bedarf entsteht. Dem stand<br />
bisher im Wege, dass am SAN angeschlossene Server nur<br />
Zugriff auf die ihnen zugeordneten Speicherbereiche hatten.<br />
Eine virtualisierte Speicherlösung wie der SVC löst dieses<br />
starre Muster auf, da die Server hier nur noch Zugriff auf virtuelle<br />
Speicherbereiche haben. Die SVCSoftware entscheidet<br />
nach entsprechenden Vorgaben, wo die Daten physisch<br />
abgelegt werden. Dabei bietet die Lösung Schnittstellen zu<br />
allen marktüblichen Betriebssystemen, Hardwareplattformen<br />
und Speichersystemen und ermöglicht ein Management<br />
über eine zentrale Konsole.<br />
Einige wichtige Hardwarefunktionen verbleiben nach wie vor<br />
im Speichersystem und sind unabhängig vom SVC. So werden<br />
die <strong>System</strong>e vor dem Anschluss an den SVC wie in der<br />
Vergangenheit eingerichtet. Es werden RAIDArrays und<br />
anschließend die LUNs (Logical Units) gebildet. Dies erfolgt<br />
im Zuge der Installation mittels der vom Hersteller mitgelieferten<br />
Administrierungssoftware. Die so definierten LUNs<br />
werden dann dem SVC zugeteilt, der sie in sogenannte<br />
‘Managed Disks’ (MD) umwandelt. Eine MD hat eine feste<br />
Größe und ist nicht mehr veränderbar. Danach werden eine<br />
oder mehrere MDs in sogenannte ‘Managed Disk Groups’<br />
zusammengefasst. Für die angeschlossenen Server werden<br />
im SVC virtuelle LUNs definiert, worauf der jeweilige Server<br />
zugreift. Die Definition legt auch fest, welcher Managed Disk<br />
Group die virtuelle LUN zugeordnet wird. Dies bestimmt, wo<br />
letztlich die Daten physisch abgelegt werden.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
111
112<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
Einfache Datenmigration<br />
Eine Datenmigration von LUNs zwischen unterschiedlichen<br />
Speichersystemen führt der SVC im laufenden Arbeitsbetrieb<br />
durch. Verliert eine Applikation, deren Daten sich beispielsweise<br />
auf einem HighPerformanceSpeicher befinden,<br />
für das Unternehmen an Priorität – etwa aufgrund hoher<br />
Betriebskosten für den Fachbereich, lassen sich deren<br />
Daten online auf günstigere LowPerformanceSpeicher<br />
migrieren. Dies erfolgt durch eine Änderung der Zuordnung<br />
einer virtuellen LUN zur Managed Disk Group.<br />
Neben der Datenmigration zum Speichersystemaustausch<br />
können nun auch Pflegearbeiten während der Arbeitszeit<br />
stattfinden. Speicherinhalte der Subsysteme lassen sich im<br />
laufenden Betrieb auf andere, freie Bereiche eines anderen<br />
Subsystems verlagern. Alle Datenverlagerungen finden<br />
unter Kontrolle des Speicheradministrators statt und müssen<br />
von diesem eingeleitet werden. Der SVC bietet hierbei keine<br />
regelbasierte Datenverschiebungen aufgrund von Zugriffshäufigkeiten<br />
an. Dies können AnalyseTools übernehmen, die<br />
etwa im <strong>IBM</strong> Total <strong>Storage</strong> Productivity Center eingebettet<br />
sind. Es bietet ein komplettes SANManagement inklusive<br />
Speicherplatz und Zugriffsanalysen und kann regelbasierte<br />
Kopiervorgänge in einem hierarchischen Speichersystem<br />
(HSM) anstoßen. Dabei lassen sich alle <strong>IBM</strong> Speicherprodukte,<br />
wie auch Tape Libraries, integrieren. Eine Virtualisierung<br />
von Tape Libraries mit dem <strong>IBM</strong> SVC ist allerdings<br />
nicht möglich.<br />
SVC-Redundanz<br />
Der redundante Aufbau des SVC stellt eine höchstmögliche<br />
Verfügbarkeit der Speicherumgebung sicher. Die Linux<br />
ClusterLösung besteht aus mindestens zwei <strong>IBM</strong> <strong>System</strong> x<br />
Servern. Alle kritischen Elemente sind doppelt ausgelegt,<br />
was das Risiko von <strong>System</strong>ausfällen weitgehend minimiert.<br />
In jedem der zum Cluster gehörigen Server läuft ein Linux<br />
Kernel, das von <strong>IBM</strong> auf Virtualisierungsbedürfnisse angepasst<br />
wurde und nicht von außen modifizierbar ist. Notwendige<br />
Veränderungen werden wie ein FirmwareUpdate<br />
behandelt, das der Kunde selbst oder ein Dienstleister<br />
durchführt. Die Virtualisierungssoftware läuft genau wie optionale<br />
CopyServiceRoutinen unter Kontrolle dieses Linux<br />
Kernels.<br />
Insgesamt stellt der SVC eine vollständige Appliance-Lösung<br />
dar, die Hardware, Software und Managementkonsole beinhaltet.<br />
Jeder der zwei zu einem sogenannten NodePaar<br />
gehörigen <strong>IBM</strong> <strong>System</strong> xServer ist mit einem 2Prozessorsystem<br />
mit 2 x 2,4-GHz-Intel-Prozessoren ausgestattet, hat<br />
8 GB Cache und vier 4Gbit/sFibreChannelPorts (2145<br />
8G4). Diese neuen Prozessoren stehen seit Mai 2007 zur<br />
Verfügung und erhöhen die Leistungsfähigkeit von 160. 000<br />
I/Os auf bis zu 276 .000 I/Os. Über die Managementkonsole<br />
können alle Administrationen ausgeführt und im Fehlerfall<br />
auch notwendige Analysedaten ausgelesen werden. Enthalten<br />
sind auch zwei Komponenten zur unterbrechungsfreien,<br />
batteriegepufferten Stromversorgung (UPS).<br />
Die Implementierung des SVC vollzieht sich wie bei anderen<br />
Geräten, die neu ins SAN eingebunden werden. Anpassungen<br />
im SANZoning und die Zuweisungen der Datenpfade<br />
dürften für einen erfahrenen SANAdministrator nichts<br />
Neues bedeuten. Zur Datenaufnahme in der virtuellen<br />
Ebene führt der Administrator zunächst einen Imagemode<br />
mit jeder einzelnen LUN durch. Dies bedeutet, dass die bisherigen<br />
LUNs eines Servers dem SVC zugeordnet und von<br />
hier als virtuelle LUN an den jeweiligen Server weitergereicht<br />
werden. Im nächsten Schritt können diese LUNs einer<br />
anderen ‘Managed Disk Group’ zugeordnet werden. Das hat<br />
zur Folge, dass die Daten auf die dieser Gruppe zugeordneten<br />
MDs verlagert werden. Dies erfolgt im laufenden<br />
Betrieb und ist für den jeweiligen Server transparent.<br />
SAN Volume Controller SVC: 3 Knoten im Cluster<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Ein Highlight beim SAN Volume Controller besteht in der<br />
hohen Performance. Der SVC erfüllt alle Skalierungsanforderungen,<br />
indem ein Cluster heute auf bis zu acht Knoten<br />
erweitert werden kann. Falls ein Cluster mit einem Node<br />
Paar an Performance oder Kapazitätsgrenzen stößt, ist im<br />
laufenden Betrieb eine Erweiterung um jeweils ein weiteres<br />
NodePaar (bis zu einem Maximum von vier NodePaaren<br />
pro Cluster) möglich. Jeder Knoten des <strong>IBM</strong> SVC hat einen<br />
8 GB großen Hauptspeicher, der fast vollständig als Cache<br />
genutzt wird. Bei bis zu acht Nodes pro Cluster ergibt sich<br />
somit eine Cache-Größe von bis zu 64 GB. Die Nutzung<br />
des Cache im <strong>IBM</strong> SVC bringt PerformanceVorteile gegenüber<br />
traditionellen Speicherlösungen, da sämtliche Speicherzugriffe<br />
gegen den Cache des SVC laufen. Damit verliert die<br />
Performance der angeschlossenen Speichersysteme an<br />
Bedeutung, weil ein Großteil der I/Os durch den vorgeschalteten<br />
Cache des SVC bedient wird.<br />
Damit erfüllt der <strong>IBM</strong> SAN Volume Controller alle Performance<br />
Anforderungen von marktgängigen <strong>System</strong>en. Unterstrichen<br />
wird dies vom SPCBenchmarkTest (<strong>Storage</strong> Performance<br />
Council) der gleichnamigen Herstellervereinigung, den alle<br />
Anbieter von Speichersystemen freiwillig durchführen können.<br />
SVC Standortübergreifende Spiegelungen<br />
Eine hardwarebasierende Datenspiegelung (synchron oder<br />
asynchron) als typische Funktion zur Erfüllung von Business<br />
ContinuityVorgaben ist normalerweise herstellerübergreifend<br />
nicht möglich. Der SVC führt eine Datenspiegelung in der<br />
Virtualisierungsschicht durch. In einer virtualisierten Speicherumgebung<br />
ist damit die Datenspiegelung nun auch zwischen<br />
<strong>System</strong>en unterschiedlicher Bauart und Hersteller möglich.<br />
Im Desasterfall lässt sich schnell vom primären auf den<br />
sekundären Speicher umschalten. Dies erfordert in der Regel<br />
einen Eingriff durch den Administrator, was durch vorher<br />
erstellte Skripts unterstützt oder automatisiert werden kann.<br />
SVC Spiegelungsoptionen<br />
Insgesamt laufen beim SVC alle Spiegelungsaktivitäten<br />
zwischen verteilten Standorten zumeist über Glasfaser ab.<br />
Bei großen Entfernungen können SANRouter zum Einsatz<br />
kommen, die auf der einen Seite das FCProtokoll in ein IP<br />
Proto koll und auf der Gegenseite wieder in ein FCProtokoll<br />
umwan deln. Alternativ bieten einige Hersteller hierfür auch<br />
die DWDM (Dense Wave Division Multiplexing) oder<br />
CWDMTechnologie (Coarse Wave Division Multiplexing) an.<br />
Mit diesen Geräten ist eine Bündelung von verschiedenen<br />
Protokollen (etwa IP, FC, FICON, ESCON) auf die Mindestzahl<br />
von physischen Verbindungen (in der Regel Dark Fibre)<br />
möglich.<br />
Diese Grafik beschreibt eindrucksvoll die nahezu lineare Skalierung eines SVC Clusters von 2 Knoten über 4, 6 bis 8 Knoten. Es waren bei diesen<br />
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.<br />
Die Benchmark Ergebnisse können unter www.storageperformance.org abgerufen werden.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
113
114<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
SVC Kopierfunktionen (FlashCopies)<br />
FlashCopies eignen sich zur BackupUnterstützung von<br />
Datenbanken und Filesystemen. Ein FlashCopy wird als<br />
PointinTime Copy ausgeführt und erzeugt im Moment seiner<br />
Aktivierung eine Festplatte, die eine exakte Kopie der Quellfestplatte<br />
zum Startzeitpunkt ist.<br />
Mit dem Software Release SVC Version 4.2, das im Mai<br />
2007 zur Verfügung gestellt wurde, kam die neue Funktion<br />
Multi Target FlashCopy hinzu, die es erlaubt, 16 Kopien<br />
einer Festplatte zu erzeugen, d. h., von einer Source 16<br />
Targets abzubilden.<br />
Mit dem Software Release SVC Version 4.2.1 vom Okto-<br />
ber 2007 kündigte <strong>IBM</strong> die Funktion des Incremental<br />
FlashCopy und des Cascaded FlashCopy an. Incremental<br />
bedeutet, dass eine bestehende FlashCopy auf den aktuellen<br />
Stand gehoben werden kann. Es werden dann nur die bis<br />
dahin angefallenen Änderungen der Ursprungsfestplatte<br />
kopiert. Cascaded bedeutet, dass man auch von der Kopie<br />
weitere Kopien erzeugen kann. Das ist insbesondere dann<br />
wichtig, wenn man eine inkrementelle FlashCopy speichern<br />
möchte, bevor man sie fortführt. In Summe können bis zu 16<br />
Kopien einer Ursprungsfestplatte erzeugt werden. Konsistenzgruppen<br />
werden in allen Modi unterstützt.<br />
Die Version SVC Version 4.2.1 bietet zudem die Möglichkeit,<br />
CopyServiceKapazitäten von 256 TB per I/OGruppe auf<br />
1.024 TB zu steigern, und eröffnet jetzt die Möglichkeit, eine<br />
maximale Kapazität von 8 PetaByte (vorher war es nur 2 PB)<br />
per SVCCluster abzubilden.<br />
Im Mai 2008 kündigt <strong>IBM</strong> den SVC Release 4.3 mit Verfüg<br />
barkeit im Juni 2008 an. Der Release 4.3 enthält viele<br />
Erweiterungen und neue Funktionen, die im Folgenden<br />
beschrieben sind.<br />
Space Efficient Virtual Disk (SEV)<br />
Space Efficient Vdisk ist nichts anderes als ”Thin Provisioning”<br />
oder ”<strong>Storage</strong> Overallocation”.<br />
Anwender können virtuelle Disks erzeugen, die eine unter<br />
schiedliche reale und virtuelle Kapazität haben. Die reale<br />
Kapazität definiert, wie viel physische Kapazität tatsächlich<br />
durch eine Vdisk verwendet wird. Die virtuelle Kapazität<br />
definiert, wie groß die virtuelle Disk den angeschlossenen<br />
Servern gegenüber erscheint.<br />
Eine SEV unterscheidet sich nur minimal von normalen<br />
Disks und kann wie eine normale Disk vergrößert oder verkleinert<br />
werden. Sie wird wie andere NON SEV Disks aus<br />
jedem beliebigen Pool erzeugt. Die Umwandlung zwischen<br />
SEV und NON SEV wird über Vdisk Mirroring durchgeführt.<br />
SEVs helfen Platz einzusparen von allokierter, aber nicht<br />
genutzter Kapazität. Das Einsparungspotenzial hängt von<br />
der BetriebssystemUmgebung und der Anwendung ab (in<br />
WindowsUmgebungen oft über 50%). SEVs verbessern<br />
den Ausnutzungsgrad der physischen Disks zusätzlich<br />
(neben dem schon vom PoolingKonzept der Disk und<br />
SpareKapazität herrührenden Potenzial). SEV ist die Basis<br />
für Space Efficient FlashCopy.<br />
Space Efficient FlashCopy (auch als SnapShot bekannt)<br />
Space Efficient FlashCopy funktioniert wie Standard Flash<br />
Copy mit dem Unterschied, dass das FlashCopy Target eine<br />
Space Efficient Vdisk ist. Damit wird für den FlashCopy nur<br />
so viel Platz allokiert, wie aktuell benötigt wird.<br />
Virtual Disk Mirroring<br />
Vdisk Mirroring kann man sich wie einen internen LVM<br />
(Logical Volume Manager) in einer AIXUmgebung vorstellen.<br />
Vdisk Mirroring stellt eine neue VdiskKonfiguration dar, bei<br />
der eine ‘gespiegelte Vdisk’ zeitgleich auf zwei unterschiedliche<br />
MdiskSets geschrieben wird, die normalerweise<br />
auf zwei unterschiedlichen Disk<strong>System</strong>en liegen. Der SVC<br />
hält beide Kopien synchron. Im Versagensfall eines Spei<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
chersystems hat das keinen Einfluss auf die Verfügbarkeit<br />
einer gespiegelten Vdisk. Der Spiegel wird nach Wiederverfügbarkeit<br />
automatisch resynchronisiert. Spiegelkopien können<br />
gesplittet werden und die Mdisks können in Disk<br />
Groups mit unterschiedlichen Extent Sizes liegen. Dabei<br />
können eine oder beide Kopien Space Efficient sein. Vdisk<br />
Mirroring kann zusammen mit den SVC Copy Services<br />
genutzt werden.<br />
Normalerweise werden SVCCluster in einem Rechenzentrum<br />
aufgebaut. Mit Vdisk Mirroring besteht die Möglichkeit,<br />
einen ‘Stretched SVC Cluster’ aufzubauen (RPQ notwendig),<br />
indem die Knotenpaare auf jeweils zwei Rechenzentren verteilt<br />
werden. Die SVCKnotenpaare werden dabei über<br />
Longwave FC im Switch verbunden. Distanzen von bis zu<br />
10 km sind möglich.<br />
Erhöhung der FlashCopy Target Volumes auf 256<br />
Für die Kapazität von FlashCopy gibt es nur noch zwei<br />
Begrenzungen: Aus einem Source Volume können bis zu<br />
256 Target Volumes erzeugt werden und die maximale<br />
Kapazität von allen Spiegelaktionen darf 1 PB nicht überschreiten.<br />
Es bestehen nun keine Einschränkungen mehr<br />
bezüglich der Vermischung von CopyAktionen.<br />
Höhere Skalierbarkeit von Virtual Disks<br />
Die Skalierbarkeit in der Anzahl an Virtual Disks wurde verdoppelt<br />
und auf 8.192 Virtual Disks erhöht.<br />
SVC Entry Edition<br />
Zeitgleich mit dem Release 4.3 stellt <strong>IBM</strong> auch eine kostengünstige<br />
Einstiegslösung, die SVC Entry Edition, zur Verfügung.<br />
Diese Geräte basieren auf einem x3250 Server mit<br />
einem Intel Xeon E3110 3,0 GHz 6 MB L2 Cache DualCore<br />
Prozessor. Wie das aktuelle Modell 8G4 haben die Entry<br />
Geräte 8 GB Cache und vier 4 Gbps FibreChannel<br />
Anschlüsse. Die SVC Entry Edition ist preislich um ca. 40%<br />
günstiger positioniert und erreicht ca. 60% des Durchsatzes<br />
und der Leistungsfähigkeit des 8G4Modells.<br />
Neue leistungsstarke SVCs mit Solid State Disks (SSDs)<br />
mit SVC Release 5.1<br />
Im Oktober 2009 kündigt <strong>IBM</strong> mit Verfügbarkeit November<br />
2009 den SVC Release 5.1 an, der neben funktionalen<br />
Erweiterungen neue leistungsstärkere ProzessorHardware<br />
beinhaltet. Das neue SVC Modell 2145 CF8 basiert auf dem<br />
<strong>IBM</strong> <strong>System</strong> x3550 M2Server mit Intel Core i7 quadcore<br />
2,4 GHz Prozessoren und leistet nahezu das Doppelte wie<br />
der Vorgänger 2145 8G4. Die neuen Maschinen sind mit der<br />
dreifachen CacheGröße von 24 GB ausgestattet und eine<br />
I/OGruppe bietet damit 48 GB als CacheSpeicher an.<br />
Damit ergeben vier Knotenpaaren im Clusterverbund eine<br />
CacheGröße von 192 GB. Jeder SVCKnoten bietet zudem<br />
8 x 8 Gbps FCPorts. Das heißt, im Maximalausbau mit vier<br />
Knotenpaaren im Cluster stehen 32 x 8 Gbps FCPorts zur<br />
Verfügung. Durch die schnelleren Prozessoren und die<br />
Verdreifachung des Caches gewinnt der SVC eine ungewöhnlich<br />
hohe Leistungsfähigkeit. Per I/OGruppe, also per<br />
Knoten, werden 120.000–140.000 IOPS möglich, im Vollausbau<br />
also 480.000–540000 IOPS.<br />
Die neuen SVC Engines können mit eingebauten SSDs<br />
(Solid State Disks) ausgestattet werden. Bis zu vier SSDs<br />
mit einer Kapazität von 146 GB können in eine Engine eingebaut<br />
werden, per I/OGruppe also bis zu acht SSDs und<br />
damit einer SSDBruttokapazität von 1.168 GB per I/O<br />
Group. Dabei werden nur 600 GB genutzt, weil der Großteil<br />
der SSDs gespiegelt wird. Bei einer maximalen Konfiguration<br />
mit vier Knotenpaaren im Cluster stehen damit bis zu 2,4 TB<br />
an nutzbarer SSDKapazität zur Verfügung.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
115
116<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
iSCSI-Unterstützung<br />
Die neuen SVCGeräte können auch mit eingebauten EthernetPorts<br />
ausgestattet werden und so direkt an iSCSI angeschlossen<br />
werden. Es werden dazu die vorhandenen LAN<br />
Ports des SVC verwendet.<br />
Fällt ein Knoten des SVCs aus, wird die entsprechende IP<br />
Adresse auf den anderen Knoten übernommen. Somit ist es<br />
nicht nötig, MPIOSoftware für iSCSI auf dem Host zu installieren.<br />
Neue Funktionen<br />
Mit Release 5.1 stehen dem SVC neue Funktionen zur Verfügung.<br />
Reverse FlashCopy erlaubt FlashCopy Targets als<br />
‘Restore Point’ für die Source zu werden, ohne dass die<br />
FlashCopyBeziehung aufgebrochen wird. Dabei werden<br />
multiple Targets und multiple ‘Roll Back Points’ unterstützt.<br />
Multiples Cluster Mirroring erlaubt den Aufbau einer dreifachen<br />
Spiegelung. Vier SVCCluster bilden eine Mirror<br />
Gruppe. Jede Disk kann von jedem Cluster auf einen anderen<br />
Cluster gespiegelt werden.<br />
Installationsbasis Dezember 2009<br />
Weltweit wurden bis zum Dezember 2009 über 17.000 SVC<br />
Knoten ausgeliefert. Diese Knoten sind in mehr als 5.000<br />
SVC<strong>System</strong>en im produktiven Einsatz.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Backup-Konzepte<br />
Unabhängig von der jeweiligen Implementierung, ist die<br />
Bedeutung eines Backups von unternehmenskritischen Daten<br />
unbestritten. Zu den klassischen drei BusinessFaktoren<br />
Mensch, Boden und Kapital hat sich in den letzten Jahren ein<br />
weiterer Faktor geradezu aufgedrängt. Der Faktor Information.<br />
Informationen sind die Lebensader jedes Unternehmens<br />
und die IT ist dazu da, den Bestand und die Weiterentwicklung<br />
dieser Lebensader zu sichern und zu unterstützen.<br />
Ein Backup ist eine Datenkopie an einem je nach Implementierung<br />
lokalen oder entfernten Ort. Eine solche Datenkopie<br />
schützt vor dem totalen Verlust bei menschlichen Fehlern,<br />
HardwareFehlern, Virusinfektionen und totalem Verlust einer<br />
Lokation. Ein gut durchdachtes BackupKonzept ist eine persönliche<br />
Versicherung für den Fortbestand der Arbeitsfähigkeit<br />
und somit im Extremfall für den Fortbestand eines<br />
gesamten Unternehmens.<br />
Plattentechnologie vs. Bandtechnologie im Backup-Umfeld<br />
Eine Platte bietet direkten Zugriff und Vorteile beim Single File<br />
Restore und Filesystem Restore. Ebenso bietet sich die Möglichkeit<br />
mit „multiple Streams“ auf der Platte zu arbeiten,<br />
umso die BackupZeitfenster zu reduzieren. Platten haben<br />
aber genauso Nachteile! Sie bieten keinen Vorteil bei großen<br />
File Backups oder Full Image Backups (hier ist das Tape<br />
meis tens wesentlich schneller). Platten können nicht bewegt,<br />
also nicht als bewegliche Datenträger eingesetzt werden, sie<br />
benötigen Strom und kosten bei entsprechend hohen Kapazitäten<br />
mehr als TapeLösungen. Auch stellt sich die fundamentale<br />
Frage, welche Plattentypen setzt man für den<br />
Backup ein? Sollen es ATA, SATA, FATA, SAS oder FC<br />
Platten sein? Was ist das richtige PreisLeistungsVerhältnis in<br />
Relation zur Zuverlässigkeit und Sicherheit?<br />
Tapes dagegen sind sequentielle ‘Streaming Devices’ und<br />
heute in der Datenrate meistens schneller als Platten. Deshalb<br />
ist es in der Regel performanter, große Files oder große<br />
Datenbanken direkt auf native Tapes wegzusichern. Tapes<br />
sind ‘On Demand’, skalieren also in Performance und Kapazität,<br />
indem einer Tape Library entweder zusätzliche Laufwerke<br />
oder zusätzliche Kassetten zugeführt werden.<br />
Tapes sind austauschbare Datenträger, das heißt, sie können<br />
in Sicherheitsräume ausgelagert werden oder zwischen<br />
unterschiedlichen Lokationen ausgetauscht werden. Tapes<br />
benötigen keinen Strom, wenn sie einmal beschrieben sind,<br />
und sind wesentlich länger haltbar (LTO als ECMAStandard<br />
bis zu 30 Jahre). Neben überschreibbaren Kassetten stehen<br />
heute nahezu in allen TapeTechnologien auch WORMBänder<br />
(Write Once read Many) zur Verfügung, die sich besonders<br />
im Umfeld der Langzeitarchivierung einsetzen lassen.<br />
Welche Alternativen stehen uns heute für ein sicheres Backup zur<br />
Verfügung?<br />
Das klassische und traditionelle Backup beginnt mit einem<br />
lokal an den Server angeschlossenen Bandlaufwerk. Bei<br />
mehreren Servern wird dies sehr schnell betreuungsintensiv<br />
und skaliert daher nur begrenzt. Der nächste Schritt dazu<br />
wäre eine zentrale, LANbasierte Datensicherung z. B. über<br />
TSM und einen entsprechenden BackupServer, bei dem<br />
Disk oder Tape<strong>System</strong>e direkt an die Server angeschlossen<br />
werden. So können mehrere Server eine gemeinsame BandsicherungsInfrastruktur<br />
nutzen (z. B. eine Tape Library). Bei<br />
größeren Datenvolumen, z. B. bei DBs, bietet sich ein SANbasiertes<br />
Backup an, das die hohen DatenTransfermengen<br />
vom lokalen Netzwerk (LAN) fernhält und so insbesondere<br />
Vorteile bei der Geschwindigkeit und Zugriffsmöglichkeit realisiert.<br />
Trotz der immensen Weiterentwicklungen im Tape Bereich,<br />
immer kürzeren Zugriffszeiten mit höheren Schreibdurchsätzen<br />
und Kapazitäten sind die Daten trotzdem nicht im dauerhaften<br />
Zugriff (Online).<br />
Dies kann nur durch eine Diskspeicherinfrastruktur erreicht<br />
werden. Vor dem Hintergrund des Preisverfalls bei Festplattenlaufwerken,<br />
insbesondere bei den günstigen SATAPlatten<br />
(Serial ATA) ergeben sich mannigfaltige Möglichkeiten. Eine<br />
Möglichkeit ist, das BackupKonzept komplett von Tape auf<br />
Disk umzustellen. Dadurch wird eine hohe Verfügbarkeit und<br />
Geschwindigkeit erreicht, jedoch ist es schwierig bis unmöglich,<br />
die Daten physisch in eine entfernte Lokation zu bringen<br />
(Bergwerk, Bunker, Vault, Bank). Je nach Sensibilität der Daten<br />
wird dies empfohlen bzw. ist z.T. Bestandteil von gesetzlichen<br />
Vorgaben. Zudem entstehen sehr hohe Energiekosten sowie<br />
zusätzliche Migrationsaufwände bei einer reinen Disklösung,<br />
die den Vorteil der vermeintlich günstigen Hardware<br />
Investition schnell aufheben. Um die Vorteile beider<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
117
118<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
Technologien nutzen zu können, setzt sich zunehmend die<br />
Kombination von Disk und Tape durch für ein schnelles,<br />
hochverfügbares und trotzdem sicheres Backup. Dies ist<br />
industrieweit bekannt als DisktoDisktoTapeBackup. In diesem<br />
Konzept werden die Disks als BackupPuffer (Staging<br />
Area) benutzt, um kürzlich zurückliegende Backups für eine<br />
gewisse Zeit online zu halten und dann nach Ablauf einer<br />
gesetzten Frist auf Tape auszulagern. Dies gilt auch bei Virtualisierungslösungen<br />
von Tape: Hier werden TapeLaufwerke<br />
auf Disk emuliert, d. h., Disks stellen sich dar wie ein Bandlaufwerk.<br />
Integrierte TapeVirtualisierungslösungen kombinieren<br />
Hardware und Software zu einer einfach bedienbaren Virtuellen<br />
Tape Library (VTL). Erst die Möglichkeit, auch auf<br />
physische Tapes zu migrieren, bietet eine operative, kostengünstige<br />
und effiziente Umgebung.<br />
Wird mit einer Kombinationslösung aus Platte und Band gear<br />
beitet, stellt sich die Frage, wie groß muss das vorgeschaltete<br />
Plattensystem von der Kapazität sein, wie muss die Tape<br />
Library dahinter konfiguriert werden und wie implementiert<br />
man die Migration von Platte auf Band sinnvoll! Individuelle<br />
Sizings der vorhandenen Umgebung und der benötigten<br />
Anforderungen sind für eine sinnvolle Lösung notwendig!<br />
Es gibt VTLs auf dem Markt, die keine TapeAnbindung<br />
haben. Da stellt sich diese Frage natürlich nicht! Allerdings<br />
ist von solchen Konzeptionen dringend abzuraten, da es in<br />
eine technologische Einbahnstraße führt, aus der man nur<br />
wieder mit sehr viel Aufwand und Kosten herauskommt. VTLs<br />
ohne TapeAnbindung mit sehr günstigen ATA oder SATA<br />
Platten müssen in der Regel komplett nach drei Jahren aus<br />
Sicherheitsgründen ausgetauscht werden, um Plattenausfälle<br />
und Datenverlust zu vermeiden. Sind hier sehr große Kapazitäten<br />
betroffen, kommt es in der Regel zu einer regelrechten<br />
Kostenexplosion!<br />
Beim Einsatz von VTLs und Diskbuffern kann eine effektivere<br />
Nutzung des Plattenpuffers durch DeDuplizierungsverfahren<br />
eine große Menge an sonst benötigten Plattenplatz einsparen,<br />
weil nur noch Datenblöcke einmal abgespeichert werden<br />
und Duplikate vermieden werden. Die Einsparung ist dabei<br />
direkt vom erzielten DeDuplizierungsfaktor abhängig. Es gibt<br />
verschiedene DeDuplizierungsverfahren von unterschiedlichen<br />
Anbietern. Die wichtigste Anforderung an ein DeDuplizierungsverfahren<br />
ist die Sicherstellung einer 100%igen<br />
Datenintegrität neben skalierbarer Leistungsfähigkeit. Nur<br />
Verfahren mit 100%iger Datenintegrität stellen eine sichere<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
RestoreMöglichkeit zur Verfügung, denn Backup macht man<br />
wegen des Restores!<br />
Die erzielten DeDuplizierungsfaktoren sind von vielen Gegebenheiten<br />
abhängig: Welche Backup SW ist im Einsatz, wie<br />
wird die Sicherung durchgeführt (z. B. immer inkrementell<br />
oder jede Woche einen Full Backup etc.) und wie lange soll<br />
die Retentionperiode sein, wo die Daten im Plattenpuffer<br />
gespeichert bleiben (siehe auch unter DatenDeDuplizierung).<br />
Welches Konzept bezüglich der Anforderungen Leistung,<br />
Sicherheit, Kosten, Haltbarkeit und einfache Erweiterbarkeit<br />
die beste Effektivität bietet, ist von der vorhandenen Infrastruktur<br />
abhängig und ob die Daten klassisch über das LAN<br />
oder LANfree über das SAN oder beides gesichert werden.<br />
In den meisten Fällen bieten sich Kombinationslösungen von<br />
Platte und Band an, um die Stärken beider Technologien entsprechend<br />
für einen effektiven Backup und Restore zu nutzen.<br />
Wichtig ist, dass DatenBackup sicher und zuverlässig ist und<br />
die Wiederherstellung der Daten in jedem Fall gewährleistet<br />
wird. Das gilt für unvorhergesehene Feher wie z. B. Disaster<br />
(Naturkatastrophen, Hochwasser, technische Fehler, Disk<br />
Crash), aber auch für menschliche Fehler (versehentliches<br />
Löschen von Daten, falsches Bearbeiten von Dateien) und<br />
Application Errors (Virus, Fehler in der Software). Es ist also<br />
u. a. wichtig, dass Datenkopien an verschiedenen Lokationen,<br />
auf unterschiedlichen Medien und mit unterschiedlichen Tools<br />
bzw. Software und von verschiedenen Verantwortlichen<br />
erzeugt werden. Snaps in derselben Einheit bieten alleine keinen<br />
Schutz, Spiegelung mit derselben Software ebenfalls<br />
nicht!<br />
Der Anspruch an den Sicherheitsgrad sowie die Wiederher<br />
stellungszeit (Recovery Time Objective) spielen für die Auswahl<br />
der Komponenten respektive der BackupStrategie<br />
ebenso eine entscheidende Rolle.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
119
120<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
Virtualisierung von Bandsystemen<br />
Neue Server-basierende Tape-Virtualisierung für <strong>System</strong> z<br />
Am 29. August 2006 kündigte die <strong>IBM</strong> eine neue Virtualisierungslösung<br />
für die z/OSUmgebung an. Die TS7700 wird<br />
als Nachfolger der <strong>IBM</strong> 3494 B10 und B20 Virtual Tape<br />
Server Ende September 2006 verfügbar. Dies war insbesondere<br />
auch deshalb notwendig, weil die alten Einheiten B18,<br />
B10 und B20 nicht der ab 1. Juli gültigen EURichtlinie<br />
RoHS entsprachen. Die neue TS7700 Serie für die Bandvirtualisierung<br />
im MainframeUmfeld bildet eine neue, langfristige<br />
Basis durch eine modulare und skalierbare Server<br />
Architektur. Man spricht von einer ‘Distributed Node<br />
Architecture’.<br />
Die TS7700 besteht aus dem 3592 Gehäuse F05, der<br />
TS7740verteilten NodeArchitektur mit unterschiedlichen<br />
Nodes (siehe unten), die entsprechende Funktionen wahrnehmen,<br />
einschließlich zwei aktiv geschalteter ‘I/ODrawer’,<br />
die entsprechende FICONAnschlüsse zum Host, Fibre<br />
ChannelAnschlüsse zu den Platten und EthernetVerbindungen<br />
zum Library Manager zur Verfügung stellen, dem<br />
TS7740 Cache Controller als RAIDSteuereinheit und entsprechenden<br />
RAIDbasierenden Platteneinschüben, die den<br />
TVC (Tape Volume Cache) als Plattenpuffer reflektieren.<br />
Für die Plattenpufferkapazitäten werden RAIDArrays mit<br />
146GBPlatten eingesetzt. Der RAID Controller arbeitet mit<br />
16 integrierten Platten, eine TS7740 CacheErweiterung<br />
beinhaltet ebenfalls 16 Platten. In die Gehäuseeinheit sind<br />
neben dem RAID Controller bis zu drei Plattenerweiterungseinheiten<br />
integrierbar. Damit können bis zu 64 Platten in die<br />
Grundeinheit eingebaut werden. Die Gesamtkapazität liegt<br />
bei 6 TB (native) und 18 TB (komprimiert).<br />
Nodes sind funktionale Aufgaben, die als Applikation auf<br />
einem aus zwei DualCore 64 bit, 1,9 GHz Prozessoren<br />
bestehenden pSeriesServer laufen. Das vNode (v steht für<br />
Virtual) stellt dem Host virtuelle Laufwerke zur Verfügung<br />
und ist für die HostKommunikation verantwortlich. Das<br />
hNode (h steht für Hierarchical <strong>Storage</strong> Management) ist für<br />
die Verwaltung der logischen Volumes im Plattenpuffer<br />
zuständig. Es managt auch die Migration von Platte auf<br />
Band und ist für die gesamte Verwaltung der physischen<br />
BandRessourcen einschließlich des TapeReclamationProzesses<br />
zuständig. Die Kombination aus vNode und hNode<br />
wird als gNode (g steht für general) bezeichnet und reflek<br />
tiert die Virtualisierungseinheit des <strong>System</strong>s. Dieser Aufbau<br />
erlaubt einfache zukünftige Skalierung bezüglich der Kapazitäten<br />
und der Leistung, indem mehrere gNodes oder auch<br />
nur vNodes im Cluster miteinander gekoppelt werden.<br />
Die Ankündigung enthält ein ‘SOD’ (Statement of Direction),<br />
nachdem ein Cluster mit zwei gNodes verfügbar sein wird.<br />
Das sorgt für erhöhte Verfügbarkeit, erhöhte Performance<br />
sowie mehr virtuelle Devices innerhalb des Clusters und<br />
ermöglicht unterbrechungsfreie CodeUpdates. Bei späteren<br />
Erweiterungen können dann vNodes und hNodes auf unterschiedlichen<br />
<strong>System</strong>en laufen und so horizontal innerhalb<br />
des Clusters skalieren. Zukünftig vorstellbar ist, dass die<br />
vNodes dann unterschiedliche Aufgaben wahrnehmen, z. B.<br />
Virtualisierung für Open <strong>System</strong>s oder Datenarchivierung.<br />
<strong>IBM</strong> TS7700 Virtual Tape Server für zSeries<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Zwei Cluster können heute in einem Dual Cluster Grid<br />
(oder auch Multi Cluster Grid) zusammengeschlossen wer<br />
den und dienen dazu, entsprechende DisasterRecovery<br />
Lösungen aufzubauen. Sie sind in der Funktionsweise dem<br />
Peer to Peer VTS mit den Modellen B10 und B20 vergleichbar<br />
(synchrone und asynchrone Spiegelung). Dazu ist das<br />
neu angekündigte TS7700 Grid Communication Feature notwendig.<br />
Seit August 2007 sind Konfigurationen von drei Clustern in<br />
einem Grid möglich. Die Architektur selbst erlaubt langfristig<br />
bis zu acht Cluster in einem Grid und wird in einer späteren<br />
Ankündigung bekanntgegeben.<br />
Der Unterschied der Spiegelung liegt darin, dass bei der<br />
TS7700 dedizierte EthernetVerbindungen (IP) eingesetzt<br />
werden. Mit zwei 1GbitEthernetVerbindungen wird die<br />
Spiegelung durchgeführt, sie ist wesentlich leistungsfähiger<br />
im Vergleich zu Peer to Peer VTS mit FICON. Das senkt<br />
die Kosten, nutzt offene Standards und vereinfacht die<br />
Infrastruktur.<br />
Die Einheit bietet neben dem 6TBPlattenpuffer (18 TB<br />
komprimiert) einen maximalen Durchsatz von 600 MB/s<br />
(Peak) und damit knapp das Doppelte einer 3494B20. Es<br />
stehen bis zu vier 4GbitFICONAnschlüsse in dieser Basiseinheit<br />
zur Verfügung. Unterstützt ist die TS3500 Library<br />
(3584 Library) über die Anbindung des <strong>IBM</strong> 3953 Library<br />
Managers Modell L05. Die Einheit unterstützte im Backend<br />
TS1120 Laufwerke im EmulationMode der 3592 J1A. Seit<br />
Februar 2007 ist auch die ‚Native‘Unterstützung verfügbar.<br />
Bis zu 16 physische Bandlaufwerke TS1120 können an einer<br />
TS7700 betrieben werden.<br />
Zum z/OSHost werden wie bei den alten VTSModellen<br />
3490E Laufwerke abgebildet. Funktional bietet die neue<br />
Einheit Funktionen, die bei dem Modell 3494B20 zur Verfügung<br />
standen. Dies sind vor allem die Funktionen des APM<br />
(Advanced Policy Management) wie ‘Volume Pooling’, ‘Dual<br />
Copy’, ‘Logical Volume Sizes’ und ‘Multiple Reclamation<br />
Policies’ (Beschreibung der Funktionen unter 3494B20), die<br />
bei TS7700 als Outboard Policy Management bezeichnet<br />
werden.<br />
Die TS7740 Node emuliert zum Host viele 3490E Laufwerke,<br />
die für den Host wie physikalisch vorhandene Laufwerke<br />
sichtbar sind. Die TS7740 ist also völlig transparent<br />
zum Betriebssystem, zum Bandverwaltungssystem und zum<br />
Katalogeintrag. Die emulierten Laufwerke bezeichnet man<br />
als virtuelle Laufwerke. Die TS7700 unterstützt bis zu 256<br />
virtuelle Laufwerke sowie bis zu 100. 000 virtuelle Volumes<br />
und dies erhöht sich später durch die Bildung von Multi<br />
Node Clustern entsprechend. In einem Dual Cluster Grid<br />
(Spiegelung) stehen 512 virtuelle Laufwerke zur Verfügung.<br />
Geschrieben wird in den verfügbaren Plattenpuffer, den<br />
TS7740 Cache (ebenso wird bei Recalls aus dem Plattenpuffer<br />
gelesen). Ist ein Volume im Plattenpuffer gespeichert,<br />
wird dieses als virtuelles Volume bezeichnet. Durch einen<br />
Algorithmus, der als Premigration bezeichnet wird, werden,<br />
etwas zeitversetzt, Kopien der virtuellen Volumes auf die<br />
physischen Bandlaufwerke migriert und auf physische 3592<br />
Kassetten geschrieben. Die Kopie des virtuellen Volumes,<br />
das jetzt auf einer physikalischen Kassette gespeichert ist,<br />
wird als logisches Volume bezeichnet. Viele logische<br />
Volumes auf einer Bandkassette nennt man ‘Stacked<br />
Volumes’. Ein Stacked Volume ist also eine physikalische<br />
Kassette, die viele logische Volumes enthält.<br />
Durch den PremigrationProzess werden die Laufwerkgeschwindigkeiten<br />
der physischen Laufwerke voll genutzt.<br />
Ebenso werden die Kassetten in ihrer Kapazität maximal<br />
ausgenutzt, weil viele logische Volumes auf einer Kassette<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
121
122<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
gespeichert werden. Kommt ein Recall des Hosts auf ein<br />
logisches Volume, wird der Recall aus dem Plattenpuffer<br />
bedient, solange das Original des virtuellen Volumes dort<br />
noch verfügbar ist. Ist das virtuelle Volume im Plattenpuffer<br />
nicht mehr verfügbar, wird die physische Kassette, welche<br />
die Kopie des logischen Volumes enthält, in ein Bandlaufwerk<br />
geladen.<br />
Das angeforderte logische Volume wird dann in den Plattenpuffer<br />
zurückgeladen und der Recall wird aus dem Plattenpuffer<br />
bedient.<br />
Sollte aufgrund einer großen SchreibWorkload der Plattenpufferplatz<br />
(TS7740 Cache) knapp werden, werden im Plattenpuffer<br />
die virtuellen Volumes, die am wenigsten benutzt<br />
wurden (LRU Least Recently Used Algorithmus), zum Überschreiben<br />
freigegeben, nachdem deren Kopie bereits auf<br />
Band ‘premigriert’ wurde.<br />
Der ReclamationProzess der physischen Kassetten findet<br />
im Hintergrund von Laufwerk zu Laufwerk statt, ohne dass<br />
der Plattenpuffer belastet wird. Es erfolgt kein Zurückladen<br />
der noch validen logischen Volumes auf der Kassette in den<br />
Plattenpuffer, sondern diese werden direkt von Laufwerk zu<br />
Laufwerk auf eine neue Kassette geschrieben. Die alte Kassette<br />
geht dann automatisch in den vorhandenen Scratch<br />
Pool zurück.<br />
Die TS7700 bildet die neue Basis eines Mainframebasierenden<br />
Virtual Tape Servers. Es sind viele neue Funktionalitäten,<br />
Verbesserung in Leistung und Kapazität und größere<br />
Konfigurationen in den nächsten Monaten vorgesehen, die<br />
die TS7700 zum absoluten TapeVirtualisierungsspezialisten<br />
im MainframeUmfeld machen, der mit keiner anderen<br />
Lösung vergleichbar ist. Das war bereits mit den Modellen<br />
B10 und B20 der Fall, die als einzige <strong>System</strong>e über die APM<br />
Funktionalität eine Verbindung ins SMS (<strong>System</strong> Managed<br />
<strong>Storage</strong>) als Teil des z/OSBetriebssystems hatten. Dabei<br />
werden die SMSKonstruktnamen, wie Data Class, <strong>Storage</strong><br />
Class und Management Class, sowie die <strong>Storage</strong>Group<br />
Namen einschließlich der VolSerZuordnung automatisch in<br />
die Library Manager Data Base übernommen. Das bietet<br />
kein anderes <strong>System</strong> auf dem Markt.<br />
Sowohl für die 3494B10 und B20Modelle als auch für die<br />
neue TS7700 ist eine noch stärkere Integration in das SMS<br />
des z/OSBetriebssystems längerfristig vorgesehen.<br />
Grid-Spiegelungen mit TS7700 <strong>System</strong>en<br />
Bei einer MultiClusterGridSpiegelung ist es erforderlich zu<br />
definieren, wie jede <strong>Storage</strong> Group eines jeden Clusters im<br />
Grid zu behandeln ist. Das Setzen einer Policy auf dem LM<br />
definiert den Consistency Point für jede definierte Site im<br />
Subsystem. Aus den Policies wird ein Array aus Consistency<br />
PointWerten, wobei jedes Element des Arrays die Policy für<br />
eine bestimmte Site repräsentiert. Wenn z. B. für Site A eine<br />
Kopie zum Zeitpunkt des Unloads und für Site B eine Kopie<br />
zu einem späteren Zeitpunkt gewünscht wird, sieht das Array<br />
so aus: Site A hat RD und Site B hat RD.<br />
Die Replication Policies können auf den LMs verschieden<br />
sein. Die Policy Settings auf jedem LM diktieren, welche<br />
Aktionen ausgeführt werden, wenn ein Volume auf einem<br />
virtuellen Laufwerk, das zu diesem LM gehört, gemountet<br />
wird. Consistency Policies bestimmen die Site, welche die<br />
Daten als erste erhält (TVC Selektion), welche Sites eine<br />
Kopie der Daten erhalten und zu welchem Zeitpunkt.<br />
Consistency Policies werden über die Management Class<br />
konfiguriert. Dabei werden Policies einem Management<br />
ClassNamen zugeordnet. Policies werden über den ETL<br />
Specialist auf dem Library Manager gesetzt.<br />
Eine neue Definition ist die des ‘Copy Consistency Points’,<br />
der bestimmt, wann ein Target Volume auf einer TS7700 mit<br />
dem Source Volume konsistent ist. Bei den Consistency<br />
Policy Optionen werden für jede Site Consistency Points<br />
gesetzt. Dabei stehen drei Definitionen zur Verfügung:<br />
RUN (R) – diese Site benötigt eine valide Kopie des<br />
logischen Volumes, bevor Device End an den RUNBefehl<br />
(Rewind Unload) vom Host geliefert wird (entspricht weitgehend<br />
dem Immediate Mode beim PtP VTS).<br />
Deferred (D) – diese Site benötigt eine valide Kopie zu<br />
einem späteren Zeitpunkt, nachdem der Job beendet wurde<br />
(ähnlich wie Deferred Mode beim PtP VTS).<br />
No copy (N) – diese Site soll keine Kopie von Volumes in<br />
dieser Management Class erhalten.<br />
Durch diese neue Möglichkeit können extrem flexible<br />
Spiegel varianten in MultiClusterGridKonfigurationen<br />
realisiert werden.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
TS7700 Erweiterungen 2007<br />
Bei der Ankündigung der TS7700 machte <strong>IBM</strong> die Aussage,<br />
dass mit vier zusätzlichen Releases im Jahr 2007 in die<br />
TS7700 <strong>System</strong>e eine Vielfalt von neuen funktionalen Erweiterungen<br />
integriert werden, die weit über den Rahmen des Vorgängersystems<br />
B20 hinausgehen. So wurde jedes Quartal ein<br />
neuer Release verfügbar, R1.1 im 1., R1.2 im 2., R1.3 im 3.<br />
und R1.4 im 4. Quartal 2007. Die verfügbaren Funk tionen<br />
werden in AFbasierende Funktionen (Advanced Functions)<br />
und NichtAFbasierende Funktionen unterschieden.<br />
Advanced Functions (AF)<br />
Die Funktionalität ‘Logical Volume Pooling’ bietet die Möglichkeit,<br />
logische Volumes einzeln pro Nummernkreis in<br />
unterschiedlichen physischen KassettenPools zu verwalten.<br />
Damit ist die TS7700 mandantenfähig.<br />
Mit ‘Tape Volume Cache Management’ können logische<br />
Volumes einer Cache Management Preference Group zugeordnet<br />
werden. Es stehen zwei Preference Groups zur Verfügung.<br />
Die Preference Group steuert, wie die logischen Volumes<br />
im Plattenpuffer behandelt werden, und beeinflusst<br />
die Verweildauer von virtuellen Volumes im Tape Volume<br />
Cache (Plattenpuffer). Mit ‘Dual Selective Copy’ können zwei<br />
Kopien eines logischen Volumes in zwei unterschiedlichen<br />
TS7700<br />
Cluster 0<br />
3-Cluster-Spiegel-Grid<br />
R 0<br />
R 1<br />
D 2<br />
Host<br />
physischen Kassettenpools erzeugt werden. Die TS7700<br />
speichert dann zum Schutz vor einem Mediendefekt ein<br />
Duplikat eines logischen Volumes auf einer zweiten Kassette.<br />
‘Cross-site Replication’ wird in einer GridKonfiguration<br />
verwendet, um eine Kopie in einer zweiten Site zu erzeugen.<br />
Je nach Ein stellung erfolgt dies auf synchroner oder asyn<br />
chroner Basis. Es können aber auch ungespiegelte Volumes<br />
in einer GridKonfiguration verwaltet werden. ‘Logical Virtual<br />
Volume Sizes’ dient der Auswahl von Volume größen, die<br />
die StandardVolumegrößen von 400/800 MB übersteigen.<br />
Zur Wahl stehen 1.000, 2.000 und 4.000 MB.<br />
Secure Data Erasure mit Encryption Shredding reflektiert<br />
die Wiederkehr der bereits aus dem VTS bekannten Funktion<br />
zur vollautomatisierten ‘Zerstörung’ von Datenbeständen auf<br />
Leerkassetten (nach Reklamation). Das ist ein genialer Trick,<br />
wenn TS1120 Tape Encryption im Einsatz ist: ‘nur’ der Schlüssel<br />
wird auf der Kassette gelöscht, nicht die gesamte Band<br />
Datenstruktur! Bei einem 3-Site-Grid wird ein TS7700 Grid so<br />
erweitert, dass bis zu 3 Cluster für noch besseren Business<br />
Continuity Support zur Verfügung stehen (DreifachRemote<br />
Spiegelung). Jetzt können in einem 3SiteGrid zwei TS7700<br />
z.B. lokal synchron gespiegelt werden und beide <strong>System</strong>e<br />
dann asynchron in großer Entfernung über WAN in eine<br />
dritte TS7700.<br />
WAN<br />
TS7700<br />
Cluster 1<br />
TS7700<br />
Cluster 2<br />
Dreiseitiger TS7700 Spiegel-Grid, Cluster 0 und 1 sind synchron gespiegelt und Cluster 0 und 1 asynchron über eine WAN-Strecke auf Cluster 2<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
R 0<br />
R 1<br />
D 2<br />
R 0<br />
R 1<br />
D 2<br />
123
124<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
Copy Export (StandAlone<strong>System</strong>e in R1.3, Grid<strong>System</strong>e<br />
in R1.4) erlaubt es, eine GesamtKopie der Daten einer<br />
TS7700 zu exportieren, z. B. für Disaster RecoveryZwecke,<br />
während die originalen Daten weiterhin in der TS7700 verbleiben<br />
und für die Produktionssite verfügbar sind.<br />
Copy Export ist eine neue TS7700 Funktion zur Unterstützung<br />
des Transfers von Daten (auf Stacked Tapes) in eine<br />
regionale/überregionale Sicherheitszone für DisasterRecoveryZwecke.<br />
Dabei kann mit der Funktion Dual Selektive<br />
Copy eine Kopie von Volumes innerhalb einer TS7700<br />
erzeugt werden, die in einem separaten <strong>Storage</strong> Pool und<br />
damit separaten Kassetten abgespeichert wird. Copy Export<br />
exportiert dann eine Kopie von ausgewählten Daten (log.<br />
Volumes), die primäre Kopie verbleibt dabei allerdings in<br />
der produktiven TS7700.<br />
Die ‘Copy Exported physical Volumes’ werden weiterhin von<br />
der produktiven TS7700 verwaltet, d. h., die Volumes werden<br />
weiterhin in der TS7700 Datenbank geführt. Die TS7700<br />
managt dabei auch den ‘Offsite’ Volume ReclamationProzess<br />
(Recycling der ausgelagerten Kassetten). Informationen<br />
über die exportierten Volumes können über einen Host<br />
Console Request und einen BVIR Request initiiert werden.<br />
Ein ‘Copy Export Recovery’ wird durch das TS7700<br />
Management Interface unter dem Service und TroubleshootingMenü<br />
oder per UserId und Password mit ‘rolebased’<br />
Zugriff durchgeführt. Die TS7700 ist ‘offline’ zu den Hosts<br />
während der Recovery. Dabei wird die VolSer des Volumes<br />
benötigt, von welchem die Datenbank restored werden soll.<br />
Es besteht auch die KundenOption zur Bereinigung bestehender<br />
Datensätze in einer TS7700 für den Copy Export<br />
RecoveryVorgang (mfg cleanup). Während des Recovery<br />
Prozesses ist das einzig angezeigte Panel im Management<br />
Interface das Status Panel zum Copy Export Recovery. Wenn<br />
die Recovery abgeschlossen ist, kann die TS7700 wieder<br />
‘online’ zu den angeschlossenen Hosts genommen werden –<br />
sobald dort TCDB und TMS ebenfalls wieder restored sind.<br />
Zusätzliche Funktionen (Nicht-AF)<br />
Autonomic Ownership Takeover<br />
Ownership bedeutet, dass jedes Volume in einer GridKonfiguration<br />
einen Owner hat (Cluster). Um ein Volume auf einem<br />
bestimmten Cluster zu ‘mounten’, muss der Cluster Owner<br />
sein. Ist er es nicht, requestiert die TS7740 auf dieser Clustersite<br />
den OwnershipTransfer von der anderen Clustersite.<br />
Im Falle, dass die andere Site nicht reagiert, wird über die<br />
TSSC (Total <strong>Storage</strong> Service Console) geprüft, was mit der<br />
TS7740 auf der anderen Site los ist. Ist die TS7740 tatsächlich<br />
nicht mehr verfügbar, wird der Autonomic Ownership<br />
Takeover initiiert. Der OwnershipTransfer kann auch immer<br />
manuell angestoßen werden.<br />
Tape TS1120 Encryption Support<br />
Mit der TS7740 wird eine Verschlüsselung auf den angeschlossenen<br />
TS1120 Bandlaufwerken unterstützt (ab Release 1.2).<br />
Die virtuellen Laufwerke haben damit nichts zu tun. Encryption<br />
wird durch die existierenden <strong>Storage</strong> Pools (bis zu 32<br />
Pools) auf der TS7740 gemanagt. Der Host verwendet die<br />
existierenden <strong>Storage</strong>Konstrukte der <strong>Storage</strong> Groups und<br />
der Management Class, um festzulegen, welche logischen<br />
Volumes auf welchen Pool physischer 3592 Kassetten kommen.<br />
Ist ein Pool definiert, wo mit Encryption gearbeitet werden<br />
muss, wird er entsprechend behandelt. Dabei kann für<br />
jeden Pool definiert werden, welche ‘Public/Private’ Key<br />
Paare verwendet werden, um verschlüsselte Schlüssel auf<br />
der Kassette abzuspeichern, die mit Verschlüsselung bearbeitet<br />
wurden.<br />
Host Console Request<br />
Diese Option erlaubt einem MVS Console Operator das<br />
Durchführen von Abfragen und eine einfache Problemanalyse<br />
zum TS7700 Zustand, ohne Zugriff auf das Web Interface<br />
(MI) zu haben.<br />
Enhanced Automated Read Only Recovery (im Backend)<br />
Hier handelt es sich um die Wiederkehr der bereits im Vorgänger<br />
VTS bekannten Funktion zur vollautomatisierten<br />
Recovery von fehlerauffälligen 3592 BackendKassetten,<br />
auch unter Nutzung der 2. Kopie in einem Grid<strong>System</strong>.<br />
Remote Read and Write Pipelining<br />
Diese Funktion bringt erhebliche PerformanceVerbesserungen<br />
beim Lesen und Schreiben in den ‘remote’ Cache<br />
einer TS7700 im Grid.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
FICON<br />
Die bisherigen 128 logischen Kanäle per FICONKanal, die<br />
in sehr komlexen Konfigurationen mit vielen LPARs auf der<br />
<strong>System</strong> z Site zum Engpass werden konnten, wurden auf<br />
256 logische Kanäle erweitert. Damit dürften sich keine<br />
Engpässe mehr bezüglich der Konfigurationen ergeben.<br />
Die TS7700 ist ein TapeVirtualisierungsprodukt für das<br />
MainframeUmfeld, für das aufgrund seiner neuen Architektur<br />
in den kommenden Jahren sowohl kontinuierliche Erweiterungen<br />
als auch die Integration von völlig neuen Entwicklungen<br />
vorgesehen sind.<br />
Dynamic Link Load Balancing<br />
Der im Frühjahr 2008 angekündigte Release 1.4a bietet<br />
neben funktionaler Erweiterungen vor allem die Möglichkeit<br />
des Dynamic Link Load Balancing, das in einem Spiegelgrid<br />
dafür sorgt, das die zur Verfügung stehenden Kanalverbindungen<br />
bezüglich der Workload so ausbalanciert,<br />
dass eine ausgewogene GridPerformance reflektiert wird.<br />
Das betrifft im Wesentlichen die Laufzeitunterschiede im<br />
Netzwerk aufgrund unterschiedlicher Längen der GridVerbindungen.<br />
Um diese Unterschiede entsprechend auszugleichen,<br />
wird alle 5 Minuten ein automatischer „Check“<br />
durchgeführt, die aktuelle Auslastung bewertet und neue<br />
CopyJobs entsprechend noch verfügbaren Leistungsresourcen<br />
verteilt.<br />
Dynamic Link Load Balancing für TS7700 Spiegel Grid Konfigurationen<br />
TS7700 Library Manager Integration<br />
Im Herbst 2008 kündigt <strong>IBM</strong> den TS7700 Release 1.5 an.<br />
Einer der wesentlichen Bestandteile dieser R1.5 Erweiterung<br />
besteht darin, dass die Funktionen des externen Library<br />
Managers in die TS7700 selbst mit integriert wurde. Dieser<br />
externe Library Manager war noch ein Überbleibsel der <strong>IBM</strong><br />
3494 Tape Libary und hat die Aufgabe, das Logical und<br />
Physical Volume Inventory für den Host zu verwalten sowie<br />
die zugehörige Advanced Functions zu managen. Dies war<br />
notwendig, da die TS3500 Tape Library eine reine SCSI<br />
Medium Changer Tape Library darstellt. Da die Library<br />
Manager Plattform noch auf OS/2 basierte, kam eine Portierung<br />
1:1 in die TS7700 nicht infrage. Die Entwickler konnten<br />
sich allerdings eines anderen bereits existierenden <strong>IBM</strong><br />
Produkts bedienen: Für die Verwaltung des Physical Inventory<br />
wurde der <strong>IBM</strong> eRMM mit in den TS7700 Microcode aufgenommen.<br />
Durch diese Integration kann nun ein ganzes<br />
zusätzliches Frame eingespart werden (3953F05) und eine<br />
TS7740 Lösung besteht im einfachsten Falle aus nur noch 2<br />
Frames (TS7740 und TS3500 LFrame).<br />
TS7720 – neues Modell<br />
Diese Vereinfachung lässt dann auch erstmals das Erscheinen<br />
eines Mainframe Virtual Tape <strong>System</strong>s zu, welches rein<br />
Diskbasierend ist; d. h., es gibt im Backend kein physikalisches<br />
Tape bzw. keine Tape Library mehr. Dieses <strong>System</strong><br />
(die TS7720) hat den gleichen Aufbau und dieselben Kom<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
125
126<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
ponenten wie eine TS7740 (selbst der Ucode ist der Gleiche)<br />
mit Ausnahme des internen Plattenpuffers. Der Fibre<br />
Channel PlattenCache der TS7740 wird in der TS7720 mit<br />
einem SATAPlattensystem auf Basis der <strong>IBM</strong> DS4700 ausgestattet.<br />
Verwendet werden 1TBSATALaufwerke, die in<br />
der Maschine unter RAID6 betrieben werden. Es stehen<br />
zwei Konfigurationen mit 40 TB oder 70 TB nativer Kapazität<br />
zur Verfügung (nutzbarer Cache von 120 TB bzw. 210 TB<br />
bei 1:3 Compression). Die TS7720 bietet 2/4 FICON<br />
Anschlüsse, bietet 256 virtuelle Laufwerke ab und verwaltet<br />
bis zu 1 Million logische Volumes. Mit dem neuen Modell<br />
TS7720 können wie mit der TS7740 Gridkonfigurationen aufgebaut<br />
werden. Dabei erhöhen sich die Anzahl der virtuellen<br />
Laufwerke und die Plattenpufferkapazitäten entsprechend.<br />
In einer 3seitigen Gridkonfiguartion stehen bis zu<br />
630 TB Plattenpuffer und bis zu 768 virtuelle Laufwerke zur<br />
Verfügung.<br />
Weitere Funktionalität des R1.5 Releases waren der Support<br />
von den TS1130 (Jaguar Generation 3) Bandlaufwerken an<br />
der TS7740 sowie größere Ausbaustufen des internen<br />
TS7740 Plattenpuffers auf bis zu 14 TB.<br />
Neue Möglichkeiten mit TS7700 im Mainframe-Umfeld<br />
Im Oktober 2009 kündigt <strong>IBM</strong> für die TS7700 Familie den<br />
Release 1.6 an. Der neue Release beinhaltet viele Neuerungen,<br />
die GridComputing von TS7700 Clustern und damit<br />
verbundene neue Hochverfügbarkeitslösungen ermöglichen.<br />
4 Cluster-Grid- und Hybrid-Grid-Konfigurationen<br />
Durch den ein Jahr zuvor erschienen R1.5 sind entscheidende<br />
Grundlagen gelegt worden, um mit dem Folgerelease<br />
R1.6 die einmaligen Skalierungsmöglichkeiten einer<br />
TS7700 Umgebung entfalten zu lassen. Dazu waren im<br />
Wesentlichen noch zwei wichtige Erweiterungen notwendig:<br />
Erhöhung der maximalen Anzahl von TS7700 Cluster in<br />
einer Grid-Umgebung (von ehemals 3 auf 4)<br />
Hybrider Support von TS7740 und TS7720 innerhalb eines<br />
Grid-Verbundes<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
•<br />
•<br />
Dieser Release ist die Grundlage von Backup und Speicherarchitekturen,<br />
die bislang nicht möglich waren. So können<br />
jetzt 4StandortKonzepte realisiert werden oder z. B. ein<br />
2StandortKonzept, bei dem nun jede Lokation mit 2 <strong>System</strong>en<br />
auch im Fehlerfall hochverfügbar ausgestattet ist. Auch<br />
ist eine sogenannte ‘Hub and Spoke’ Architektur möglich,<br />
bei der 3 <strong>System</strong>e als I/OAufnahmesysteme dienen, die<br />
dann ihren Inhalt gemeinsam zu einem TS7740 als Disaster<br />
Recovery <strong>System</strong> spiegeln.
Very Large Cache<br />
Intermediate Cache<br />
Tape<br />
Noch interessanter werden diese neuen Architekturansätze<br />
durch das Mischen von TS7720 und TS7740 <strong>System</strong>en<br />
(hybride Konfigurationen). Dadurch können z. B. Kosten eingespart<br />
werden, weil ein TS7720 ohne BackendTape günstiger<br />
in der Anschaffung ist. Der wichtigere Aspekt ist allerdings<br />
die 2dimensionale Skalierbarkeit, die es erlaubt, in<br />
Richtung höhere I/OPerformanceAnforderung zu skalieren<br />
oder die Anforderung an größere interne TS7700 Caches –<br />
kostengünstig – zu befriedigen. So kann z. B. ein Kunde, der<br />
bereits eine TS7740 2ClusterGridLösung betreibt und<br />
mehr Durchsatz im FrontEnd benötigt, den Grid einfach<br />
durch das Hinzufügen von 2 x TS7720 erweitern (im Sinne<br />
von intelligeten I/OvNodes mit eigenem Cache). Die Daten<br />
können dann mit den bekannten Methoden entweder auf die<br />
andere TS7720 repliziert werden oder gleich über Kreuz auf<br />
die entfernte TS7740. Somit lässt sich bei einer 2Kopien<br />
Strategie der mögliche Durchsatz um ca. 75% steigern.<br />
Ohne diese neuen Möglichkeiten müsste sonst ein komplett<br />
neues, zweites TS77402ClusterGrid<strong>System</strong> mit Backend<br />
Tape angeschafft und administriert werden.<br />
Die zweite Skalierungsmöglichkeit einer HybridLösung<br />
besteht darin, dass der größere interne Plattenspeicher der<br />
TS7720 als größerer, aber kostengünstigerer Cache (SATA)<br />
des TS7700 Grid<strong>System</strong>s dienen kann.<br />
Das hat seinen Charme! So können jetzt z. B. drei TS7720<br />
mit einer TS7740 inklusive TapeAnbindung zusammengeschaltet<br />
werden. Damit hat die TS7740 einen riesengroßen<br />
vorgeschalteten Plattenpuffer. Bei drei TS7720 wären das<br />
bis zu 3 x 70 TB, also bis zu 210 TB native, komprimiert bis<br />
zu 630 TB (3:1) an vorgeschalteter nutzbarer Plattenpufferkapazität.<br />
Zur Optimierung der Verwaltung und Performace in Hybriden<br />
und multiplen ClusterUmgebungen wurden zwei wichtige<br />
Funktionen in den R1.6 integriert.<br />
Die ‘Cluster-Family-Funktion’ erlaubt es dem Betreiber,<br />
den TS7700 <strong>System</strong>en mitzuteilen, in welchen geografischen<br />
Positionen sie zueinander stehen. Damit können die<br />
Replizierungswege optimiert werden. So wird z. B. in einer<br />
4ClusterGridUmgebung in 2 Standorten zuerst eine Kopie<br />
zwischen den Standorten gemacht und erst danach innerhalb<br />
der Standorte eine Kopie zu dem jeweiligen <strong>System</strong><br />
innerhalb der Familie. Diese Vorgehensweise spart<br />
Leitungskapazitäten der ReplikationsStrecke zwischen<br />
den Standorten.<br />
Damit in einer hybriden TS7700 Umgebung die Plattenspeicher<br />
der TS7720 Cluster nicht überlaufen, wurde die neue<br />
Funktion ‘Automatic Volume Removal Policy’ eingeführt.<br />
Sie sorgt automatisch dafür, dass das älteste logische<br />
Volume einer TS7720 aus dem Cache entfernt wird (sofern<br />
eine Kopie auf einem anderweitigen TS7740 <strong>System</strong> existiert)<br />
und somit neuer Platz bei Bedarf freigegeben wird.<br />
Dieses intelligente Management lässt die Plattenpuffer der<br />
TS7720 in einer hybriden GridUmgebung als zusätzlichen<br />
Cache erscheinen und optimal nutzen, um noch größere<br />
Datenmengen in unmittelbarem Zugriff vorzuhalten, und entlastet<br />
das Backend von Recalls vom Band.<br />
Vorhandene 2 oder 3wayGrids sind mit Verfügbarkeit im<br />
Dezember 2009 auf einen 4wayGrid erweiterbar. Die<br />
Zusammenführung von zwei 2wayGrids zu einem 4way<br />
Grid soll ab 2010 unterstützt werden.<br />
TS7700 Logical WORM Support<br />
In Bezug auf funktionale Erweiterungen wird mit Release<br />
R1.6 der logische WORM Support bereitgestellt. Diese<br />
Funktion erlaubt es, an den ensprechenden Anwendungen<br />
auf dem Host die logischen Volumes als WORM Medien zu<br />
verwalten. Dabei sieht der Host die TS7700 als logische<br />
WORM ‘compliant’ Library. HostSoftwareErweiterungen<br />
unterstützen das Management von logischen WORM<br />
Volumes über die DataClassKonstrukte. Der Support ist<br />
sowohl für TS7720 und TS7740 verfügbar. Bereits geschriebene<br />
Volumes können allerdings nicht in logische WORM<br />
Volumes umgewandelt werden!<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
127
128<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
Neue Server-basierende Tape-Virtualisierung für Open <strong>System</strong>s<br />
Bereits im Oktober 2005 stellte <strong>IBM</strong> mit der Virtualisierungslösung<br />
TS7510 eine virtuelle Tape Library für den Open<br />
<strong>System</strong>sBereich zur Verfügung, die sich allerdings von den<br />
anderen virtuellen Tape Libraries auf dem Markt in der Funktionalität<br />
nur wenig unterschied.<br />
Im April 2007 kündigte die <strong>IBM</strong> die neue Virtuelle Tape<br />
Library TS7520 (VTL) als Nachfolger der bisherigen<br />
TS7510 an. Die TS7520 bietet neben höherer Kapazität und<br />
Leistung einen ganz neuen Funktionsumfang, der speziell<br />
für die Anforderungen im Open<strong>System</strong>sUmfeld in die<br />
Maschine integriert wurde. Bevor das neue Produkt TS7520<br />
detailliert beschrieben wird, ist es wichtig, den Trend<br />
bezüglich VTLs im Open-<strong>System</strong>sUmfeld näher zu<br />
beleuchten.<br />
Nachdem Festplatten in den letzten Jahren immer günstiger<br />
wurden, besonders durch die Einführung von neuen Technologien<br />
wie beispielsweise SATA, werden Diskbasierende<br />
BackupLösungen immer mehr propagiert. Viele Marktbeobachter<br />
und Kunden vergleichen oft DiskLösungen mit alten<br />
TapeTechnologien und finden so Vorteile bei den Disk<br />
Lösungen wie schnelleres Backup und Restore oder auch<br />
stabilerer und zuverlässigerer Betrieb als bei älteren Bandtechnologien.<br />
Aber die Zuverlässigkeit mit reinen Disk<br />
Lösungen wollte sich doch nicht so einstellen, wie von<br />
vielen gewünscht! Besonders beim Einsatz der günstigen<br />
SATALaufwerke gibt es immer wieder DiskDriveFehler bis<br />
hin zum Datenverlust, auch unter RAIDSchutz.<br />
Tape ist ein eigenständiges Medium und bietet die Vorteile<br />
von sehr schnellem Lesen und Schreiben von großen Datenmengen,<br />
lange Aufbewahrungssicherheit und braucht<br />
außerdem keinen Strom (Tape ist ‘cool’). Daneben kann Tape<br />
auch als auswechselbarer Datenträger eingesetzt werden.<br />
Disk ist ebenso ein eigenständiges Medium und bietet den<br />
Vorteil von schnellem direktem Zugriff mit kurzen Antwortzeiten<br />
und der Möglichkeit der Parallelität. Optimale maßgeschneiderte<br />
Lösungen bieten sich daher in der Kombination<br />
von beiden Technologien.<br />
Heutzutage werden DiskBackupLösungen hauptsächlich<br />
als Plattenpuffer für hochkapazitive und schnelle Tape Drives<br />
eingesetzt. Dabei werden Sicherungsdaten kurzfristig (ein<br />
bis mehrere Tage) auf diesen Disk<strong>System</strong>en gespeichert<br />
und zeitnah oder später auf Band migriert oder kopiert. Disk<br />
Backup<strong>System</strong>e kommen auch zum Einsatz, um den RestoreVorgang<br />
zu optimieren, sinnvollerweise allerdings nur<br />
dort, wo Platten Vorteile gegenüber Tape besitzen, also bei<br />
kleinen Files und Filesystemen, aber nicht bei Datenbanken<br />
oder ImageBackups.<br />
Aufgrund der Klimaveränderung, der damit verbundenen<br />
Diskussion um die Verringerung von CO2 (GreenIT) und der<br />
steigenden Energiekosten sollten DiskBackup<strong>System</strong>e nur<br />
noch mit Bedacht eingesetzt werden und nur dort, wo es<br />
wirklich nötig ist bzw. Disk echte Vorteile gegenüber Tape<br />
bietet. Dies gilt gerade für kleinere und mittelständische<br />
Unternehmen. DiskBackup<strong>System</strong>e locken mit vermeintlich<br />
günstigen Kosten, neigen aber dazu, dass die Strom und<br />
Klimakosten über einen Zeitraum von sechs Jahren deutlich<br />
höher sind als die Investitionskosten. Dazu kommen Kosten<br />
für Datenmigration, die bedingt durch den kurzen Lebenszyklus<br />
von DiskEinheiten entstehen.<br />
Neben der schon lang bestehenden Möglichkeit, den TSM<br />
(Tivoli <strong>Storage</strong> Manager) so einzusetzen, dass ein LAN-<br />
Backup auf einen Plattenpuffer läuft und später die Migration<br />
auf Tape erfolgt, bietet die <strong>IBM</strong> nun auch eine neue VTL<br />
(Virtual Tape Library) in Form des Produkts TS7520 an. Der<br />
große Vorteil der TS7520 liegt vor allem im LANfreeBereich,<br />
weil viele LANfreeClients direkt auf die TS7520 sichern<br />
können, ohne dass viele physikalische Bandlaufwerke benötigt<br />
werden (ein LANfreeClient benötigt immer ein direktes<br />
Bandlaufwerk, sei es nun physikalisch oder virtuell!). Dabei<br />
stellt prinzipiell die TS7520 den Plattenpuffer und eine Emulationssoftware<br />
zur Verfügung, die Bandlaufwerke emuliert.<br />
Geschrieben wird aber direkt in den Plattenpuffer.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Die Migration vom TS7520 Plattenpuffer auf Band kann<br />
durch die BackupSoftware (z. B. TSM) erfolgen oder auch<br />
direkt – allerdings mit entsprechenden PerformanceEinschränkungen<br />
– durch die TS7520 selbst.<br />
Zunächst sind VTLs nichts anderes als DiskBackup<br />
Lösungen. Allerdings stellen sich VTLs als Tape Libraries mit<br />
Bandlaufwerken dar. Somit bieten VTLs Vorteile, wenn die<br />
BackupApplikation kein natives DiskBackup unterstützt oder<br />
die Lizenzkosten für ein solches DiskBackup zu hoch sind.<br />
VTLs können auch dort sinnvoll eingesetzt werden, wo viele<br />
langsame LANfreeSicherungen vorhanden sind, denn hier<br />
lassen sich sonst erforderliche Tape Drives einsparen. VTLs<br />
sind aber meist auch integrierte Lösungen, die den Anwender<br />
von jeglichen administrativen Tätigkeiten, die sonst bei<br />
nativen Disk<strong>System</strong>en notwendig wären, frei hält.<br />
<strong>IBM</strong> Virtual Tape Library TS7520 für Open <strong>System</strong>-Umgebungen<br />
Ein großer Vorteil von VTL<strong>System</strong>en ist die Möglichkeit, die<br />
Daten zu komprimieren und somit die DiskKapazität besser<br />
auszunützen. Allerdings sinkt in den meisten Fällen die Performance<br />
der <strong>System</strong>e bei Einsatz von Kompression. Ein<br />
weiterer Vorteil ist, dass die Daten direkt von der VTL auf<br />
Tape migriert oder kopiert werden können und dies transparent<br />
für den BackupServer passiert.<br />
Die <strong>IBM</strong> Tape Virtualization Engine TS7520 stellt eine inte-<br />
grierte Lösung aus Hardware und Software dar, die Band<br />
virtualisierung für Open<strong>System</strong>sServer über physische<br />
FibreChannel (FC) und iSCSIVerbindungen bereitstellt.<br />
Durch <strong>System</strong> x-basierende Server (1-4) werden Bandlaufwerke<br />
emuliert. Die Emulation der TS7520 unterstützt die<br />
Laufwerksformate LTO2, LTO3 und LTO4 sowie die ‘High<br />
End’Technologien 3592 und TS1120. Der Plattenpuffer<br />
wird durch 500GB und/oder 750GBSATAPlatten reflektiert.<br />
Dabei sind die Platten in einem Einschub als RAID5-Array<br />
abgebildet. Die 16 Platten im Einschub reflektieren dabei ein<br />
6+P und ein 7+P RAID5Array (P= Parity Platte) sowie eine<br />
HotSparePlatte, die für beide Arrays im Fehlerfall als<br />
RebuildPlatte einspringt. Die Kapazitäten können mit<br />
500-GB-Platten auf bis zu 884 TB und mit 750-GB-Platten<br />
auf bis zu 1,3 PB (native Kapazitäten) ausgebaut werden.<br />
Die kleinste kapazitive Einstiegsgröße beginnt bei 6,5 TB.<br />
Erweiterungen können – je nach Plattenart – in 6,5TB<br />
Schritten oder 9,75TBSchritten erfolgen.<br />
Die TS7520 bietet eine einmalige Leistungsfähigkeit,<br />
indem bis zu 4. 800 MB/s Durchsatzmenge ermöglicht wer<br />
den (4 .800 MB/s beim Lesen vom Plattenpuffer und bis zu<br />
4 .500 MB/s beim Schreiben in den Plattenpuffer). Sowohl<br />
von der Leistungsfähigkeit als auch von den kapazitiven<br />
Möglichkeiten gibt es derzeit kein anderes VTL<strong>System</strong> auf<br />
dem Markt, das diese Möglichkeiten bietet.<br />
Die TS7520 lässt sich so konfigurieren, dass bis zu vier<br />
Server ‘geclustert’ werden können. Dabei werden bis zu 512<br />
virtuelle Libraries, bis zu 4 .096 virtuelle Bandlaufwerke und<br />
bis zu 256 .000 virtuelle Kassetten emuliert. Zu den Hosts<br />
können bis zu 32 FCAnschlüsse auf Basis von 4GbitFibre<br />
Channel konfiguriert werden. Für die TapeAnbindung stehen<br />
bis zu 16 FCAnschlüsse, auch auf Basis von 4GbitFibre,<br />
zur Verfügung.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
129
130<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
Neben der hohen Flexibilität, Leistungsfähigkeit und Kapazität<br />
bietet die TS7520 einen Funktionsumfang, die derzeit<br />
keine andere VTL auf dem Markt übertrifft. Auf diese Funktionalität<br />
wird später noch ausführlich eingegangen.<br />
Bei einer maximalen Konfiguration der TS7520 werden bis<br />
zu 12 Gehäuseeinheiten benötigt. Wichtig dabei ist die Tatsache,<br />
dass selbst bei kleinen Konfigurationen wegen<br />
Sicherheits und Leistungsanforderungen immer mit zwei<br />
PlattenControllern (SV6) gearbeitet wird (Enterprise Edition).<br />
Sowohl die PlattenController als auch die Virtualization<br />
Engines (CV6) sind über ein integriertes SAN auf Basis von<br />
4GbitFibreChannel miteinander verbunden. Dieser hochredundante<br />
Aufbau zeigt sich auch in der Stromzufuhr. Jede<br />
Gehäuseeinheit ist mit zwei Stromversorgungen ausgestattet.<br />
Aufbau einer TS7520 in einer Konfiguration mit drei Gehäuseeinheiten<br />
Als Einstiegsversion steht die TS7520 Limited Edition zur<br />
Verfügung. Diese günstige Einstiegsoption steht für Einstiegskonfigurationen<br />
mit einer Virtualization Engine (CV6)<br />
und nur einem PlattenController (SV6) zur Verfügung und<br />
unterstützt Plattenkapazitäten bis zu 29,25 TB (maximal).<br />
Die Limited Edition enthält standardmäßig nicht den ganzen<br />
Funktionsumfang. Tape Caching ist z. B. ein kostenpflichtiges<br />
Feature.<br />
Die Enterprise Edition unterstützt jede Art von TS7520<br />
Konfiguration bis zum Maximalausbau und bietet Tape<br />
Caching standardmäßig an.<br />
Die <strong>IBM</strong> TS7520 wurde als komplette Appliance entwickelt<br />
und alle EinzelKomponenten aufeinander abgestimmt. Das<br />
komplette <strong>System</strong> wurde mit allen Funktionen getestet und<br />
ausführlichen PerformanceMessungen unterworfen.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Für ITBetreiber stellt sich die <strong>IBM</strong> TS7520 als eine oder<br />
mehrere ‘virtuelle’ Tape Libraries dar und man muss sich<br />
nicht um die Anbindung sowie die Konfiguration des Disk<br />
<strong>Storage</strong><strong>System</strong>s kümmern. Die <strong>IBM</strong> TS7520 VTL ist als eine<br />
Einheit zu betrachten und auch der Support wird dementsprechend<br />
durchgeführt, d. h., es werden keine Einzelkomponenten,<br />
sondern immer die gesamte Appliance betrachtet<br />
und gewartet (z. B. für FirmewareUpdates). Somit kümmert<br />
sich auch nur ein Supportteam um die <strong>IBM</strong> TS7520. Eine<br />
zentrale Stelle nimmt die Kundenanfragen entgegen. Eine<br />
Voranalyse des Problems durch den Kunden, wie es bei<br />
Implementierungen, die aus Einzelkomponenten zusammengestellt<br />
wurden, der Fall ist, entfällt.<br />
Mit bis zu 48 x 4-Gbit-FC-Anschlüssen bietet die <strong>IBM</strong><br />
TS7520 die höchste Anzahl von ‘Connectivity’Möglichkeiten.<br />
EndtoEnd4GbitSupport bedeutet, dass die Maschine in<br />
ihrer gesamten Anbindung zu den Hosts wie auch zum Disk<br />
und Tape Backend eine ausbalancierte Leistung für Front End,<br />
Disk Cache und Tape Backend realisiert. Dabei werden bis<br />
zu 256 physische Backend TapeLaufwerke (<strong>IBM</strong> TS1120<br />
J1A/E05 Drives und/oder LTO2, LTO3 und LTO4 Drives)<br />
sowie bis zu 32 physische Backend Tape Libraries (<strong>IBM</strong><br />
TS3500 Library, <strong>IBM</strong> TS3310 Library, <strong>IBM</strong> TS3200 Library,<br />
<strong>IBM</strong> 3582 Library, <strong>IBM</strong> 3583 Library und <strong>IBM</strong> 3494 Library)<br />
unterstützt.<br />
Während manche andere VTLAnbieter für die Anzahl an<br />
emulierten Libraries, Drives und Volumes extra Lizenzkosten<br />
berechnen, ist bei der TS7520 immer alles inklusive.<br />
Die <strong>IBM</strong> TS7520 bietet eine selbstständige CallHomeFunktionalität<br />
zum <strong>IBM</strong> ServiceTeam. Vergleichbare VTLs bieten<br />
nur eine ‘EMail’CallHomeFunktionalität an, sodass nur<br />
intern, ohne Benachrichtigung des Herstellers, über Fehler<br />
informiert wird.<br />
Als großes Alleinstellungsmerkmal bietet die <strong>IBM</strong> TS7520 als<br />
einziges VTL<strong>System</strong> auf dem Markt einen Multipath Device<br />
Driver für FC Failover und Load balancing. Die Maschine<br />
kann problemlos in ein DualFabric integriert werden. Einen<br />
DualFabricSupport bieten alle auf dem Markt verfügbaren<br />
VTLs an, doch nur die <strong>IBM</strong> TS7520 bietet zusätzlich Failover<br />
und Load balancing. Dies wird durch den Multipfadtreiber<br />
gewährleistet.<br />
Ohne einen Multipath Device Driver können die einzelnen<br />
virtuellen Tape Drives zwar mühsam und manuell über die<br />
Frontend FCPorts der VTL verteilt werden, doch ein Load<br />
balancing kann dadurch nicht erreicht werden, weil die<br />
BackupApplikation, wie z. B. TSM, von der Verteilung der<br />
virtuellen Tape Drives über mehrere FCPorts keine Informationen<br />
bekommt. Alle BackupApplikationen verteilen die<br />
Workload auf die verfügbaren Tape Drives nach ‘Round<br />
Robin’ und/oder ‘last recently used’Algorithmen. Dadurch<br />
kommt es aber in Verbindung mit VTLs vor, dass einzelne<br />
FCLinks overloaded sind und gleichzeitig manche Links<br />
ohne Last sind.<br />
Besonders das Load balancing ist für eine ausgewogene<br />
und hohe Performance bei VTLs enorm wichtig. Bei Disk<br />
<strong>System</strong>en ist ein Load balancing schon seit langem eine<br />
Standardfunktion. Bei VTLs, die eigentlich ein Disk<strong>System</strong><br />
sind bzw. DiskBackup anbieten, ist dies nicht der Fall,<br />
obwohl die meisten VTLs mehrere FCPorts im Frontend<br />
anbieten. Der <strong>IBM</strong> Multipath Device Driver für Tapes verteilt<br />
die Workload auf die verfügbaren FCLinks, so dass die<br />
einzelnen Links eine ausgewogene Workload-Verteilung<br />
haben. Zusätzlich ermöglicht der <strong>IBM</strong> Multipath Device Driver<br />
ein automatisches Failover, falls ein Link oder eine Fabric<br />
ausfällt oder auch nur für Wartungsarbeiten offline ist.<br />
Spezielle Disk Caching Algorithmen beschleunigen den<br />
Recall von Tape, wenn das logische Volume sich nicht mehr<br />
im Plattenpuffer befindet. Werden VTLs eingesetzt, schreibt<br />
die BackupSoftware die einzelnen Files in einen Plattenpuffer.<br />
Im Falle einer Migration von Platte auf Band wird<br />
das logische Volume in einer 1:1Kopie auf eine Kassette<br />
gespeichert. Im Falle eines Restores einer einzelnen File,<br />
die sich nicht mehr im Plattenpuffer befindet, müssen viele<br />
VTLs das komplette logische Volume in den Plattenpuffer<br />
zurückladen, um von dort den HostRequest zu bedienen.<br />
Das kann je nach emulierter Kassette (man bedenke: eine<br />
LTO4Kassette fasst 800 GB Kapazität) sehr lange dauern,<br />
oft bis zu zwei Stunden und länger! Der Caching-Algorithmus<br />
der TS7520 arbeitet in solchen Fällen wesentlich intelligenter!<br />
Anstatt des Zurückladens des gesamten logischen<br />
Volumes in den Plattenpuffer wird die zu ‘restorende’ File<br />
direkt von Tape ausgelesen (ohne Zurückladen) und dem<br />
Host zur Verfügung gestellt. Das spart wertvolle Zeit bei<br />
RestoreAktivitäten.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
131
132<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
Es besteht die Möglichkeit, mehrere TS7520 VTLs über IP-<br />
Verbindungen asynchron zu spiegeln. Dabei wird nach dem<br />
‘demount’ einer Kassette, zu einem bestimmten Zeitpunkt<br />
oder intervallmäßig, eine Kopie des logischen Volumes über<br />
IP zu einer anderen TS7520 übertragen. Bevor auf erzeugte<br />
kopierte Volumes zugegriffen werden kann, müssen diese<br />
Volumes durch einen administrativen Eingriff freigegeben<br />
werden, damit aktiv mit ihnen gearbeitet werden kann.<br />
IP Replication kann nicht gleichzeitig mit Tape Caching<br />
durchgeführt werden.<br />
TS7530 – neues Modell<br />
Im Mai 2008 kündigt <strong>IBM</strong> die leistungsstärkere <strong>IBM</strong> Tape<br />
Virtualization Engine TS7530 an, die vom Funktionsumfang<br />
der TS7520 entspricht, allerdings neben höherer Leistung<br />
auch die Möglichkeit von RAID6 und den Einsatz von<br />
1TBSATAPlatten bietet und eine Ausbaustufe von bis zu<br />
1,7 PB (Petabyte) erlaubt. Die kleinste kapazitive Einstiegsgröße<br />
beginnt bei 6,5 TB. Erweiterungen können – je nach<br />
Plattenart – in 6,5TBSchritten, in 9,75TBSchritten und in<br />
13TBSchritten erfolgen.<br />
Die TS7520 und TS7530 unterstützen die Encryption-Mög-<br />
lichkeiten für Backend Tape Drives (TS1120 oder LTO4).<br />
Bei dieser HWEncryption, die in diese Laufwerke integriert<br />
ist, sind keine Leistungsbeeinträchtigungen zu erwarten. Für<br />
TapeLaufwerke, die nicht mit Verschlüsselungstechnik<br />
arbeiten, bietet die TS7520 die Möglichkeit, die Daten auch<br />
über SoftwareEncryptionMethoden zu verschlüsseln, bevor<br />
sie auf das physikalische Tape geschrieben werden.<br />
Die TS7520 ermöglicht neben FCAnbindungen auch iSCSI<br />
Anbindungen, wenn Kunden iSCSI im Einsatz haben oder<br />
haben wollen.<br />
Über die Funktionalität des Hosted Backups besteht die<br />
Möglichkeit, die BackupSoftware auch direkt auf der TS7520<br />
zu installieren. Dies ist allerdings nur zu empfehlen, wenn<br />
keine allzu großen Leistungsanforderungen an den Backup<br />
Server gestellt werden.<br />
Im Juli 2009 zieht <strong>IBM</strong> alle Modelle der TS7500 Familie von<br />
Marketing zurück. Einer der Hauptgründe dürfte die fehlende<br />
Möglichkeit der DatenDeDuplizierung sein. Durch die Aquisition<br />
der Firma Diligent im April 2008 und die schnelle<br />
Umsetzung dieser Technologie in der <strong>IBM</strong> Hardware setzt<br />
<strong>IBM</strong> auf die ProtecTIER VTL, die ein einzigartiges DatenDe<br />
Duplizierungsverfahren bietet und dadurch wesentlich weniger<br />
physischen Plattenplatz benötigt, um diesselbe Kapazität<br />
abzubilden (siehe unter <strong>IBM</strong> ProtecTIER VTL mit Hyperfactor).<br />
Data De-Duplication<br />
Das Thema DeDuplication wurde im Jahr 2007 zu einem oft<br />
diskutierten Thema. DeDuplication ist nichts Neues. Es handelt<br />
sich um einen mathematischen Algorithmus, der Bit<br />
BlockVergleiche durchführt. Das einzige Ziel ist die Vermeidung<br />
von Duplikaten. Dabei gibt es die unterschiedlichsten<br />
Ansätze und Verfahrensmöglichkeiten. Man kann solche<br />
Verfahren im Betriebssystem etablieren. Ein Beispiel dafür<br />
ist das z/OS mit der Funktion Hyper PAV. Auch über SoftwareTools<br />
sind solche Verfahren möglich, wie z. B. Analyse<br />
Tools, ILM, TPC oder Common Store oder über Vergleichsalgorithmen<br />
in SW und HW. Heutige DeDuplicationVerfahren<br />
werden vor allem beim Backup auf Virtuelle Tape Libraries<br />
(VTLs) eingesetzt, weil die meisten Duplikate beim Backup<br />
und bei der Archivierung erzeugt werden.<br />
Das erste professionelle DeDuplicationVerfahren führte<br />
<strong>IBM</strong> bereits im Jahr 2006 für das Produkt <strong>IBM</strong> Common<br />
Store ein. Common Store führt diese Vergleiche bei der<br />
EMailArchivierung auf MailBasis und/oder Attachment<br />
Basis durch und stellt sicher, dass eine EMail und/oder ein<br />
Attachment nur einmal archiviert wird. DeDuplication ist ein<br />
Feature von Common Store und ist nur in Verbindung mit dem<br />
<strong>IBM</strong> Content Manager als Backend Repository verfügbar.<br />
Der DeDuplicationAnsatz findet vor allem Freunde bei Vir-<br />
tuellen Tape Libraries (VTLs). Der mathematische<br />
Vergleichs algorithmus läuft dabei auf der VTL mit und führt<br />
BitBlockVergleiche durch. Die Einsparungen an Plattenplatz<br />
können dabei durchaus den Faktor 10 – 20 erreichen.<br />
Es sind verschiedene Ansätze verfügbar: über Software,<br />
über Microcode mit Hardware oder eine Kombination von<br />
Software und Hardware. Man unterscheidet grundsätzlich<br />
zwei Verfahren. Beim Inline-Verfahren werden die Vergleiche<br />
durchgeführt, bevor der BitBlock auf Platte abgespeichert<br />
wird. Hier ergibt sich das Problem der Skalierbarkeit und<br />
Leistung. Werden zu viele TB mit DeDuplication bearbeitet,<br />
gehen die VTLs sehr schnell in der Leistungsfähigkeit<br />
zurück, weil der Rechner nur noch den DeDupAlgorithmus<br />
durchführt. Die Empfehlung der Anbieter ist allgemein, nicht<br />
mehr als 15 – 20 TB mit DeDup zu bearbeiten. Das andere<br />
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<br />
Beispiel an:<br />
Unsere abzuspeichernde File ist das hier abgebildete Häuschen (1). Es wird<br />
in seine Bauteile zerlegt (2). Es besteht aus roten Würfeln, grünen Zylindern<br />
und blauen Dächlein. De-Duplication speichert jetzt jedes Bauteil nur einmal<br />
ab. Den drei Bausteinen wird noch eine Aufbauanleitung beigefügt, wie das<br />
Haus wieder aufzubauen ist und wie viele Bausteine dafür von jedem Element<br />
benötigt werden (3).<br />
Verfahren ist das Post-Processing-Verfahren, wobei der<br />
Algorithmus nachgelagert stattfindet. Man schreibt die Blöcke<br />
zuerst ohne DeDup auf Platte und führt die Vergleiche<br />
anschließend durch. Dafür wird dann aber zusätzlicher<br />
Speicherplatz benötigt.<br />
DeDuplicationVerfahren werden heute von den Firmen<br />
<strong>IBM</strong> (Diligent), EMC 2 (Data Domain), Quantum, FalconStor,<br />
Sepaton und Network Appliance angeboten. Auch für die<br />
<strong>IBM</strong> Nseries steht DeDuplication in Form der Funktion ASIS<br />
(Advanced Single Instance <strong>Storage</strong>) zur Verfügung.<br />
Die <strong>IBM</strong> beschäftigt sich schon seit einigen Jahren mit dem<br />
Thema DatenDeDuplizierung. Bereits im Januar 2004<br />
wurde im <strong>IBM</strong> Labor Almaden in Kalifornien das Projekt ‘Bit<br />
Block Mathematics’ ins Leben gerufen. Die Gruppe bestand<br />
aus MicrocodeSpezialisten und Mathematikern. Ziel war es,<br />
Unsere zweite abzuspeichernde File ist in Form einer Lokomotive (1)<br />
dargestellt:<br />
Hier finden wir dieselben Bauteile, die bei der ersten File enthalten waren:<br />
der rote Würfel, der grüne Zylinder und das blaue Dächlein. Ein weiteres<br />
zusätzliches Element kommt hinzu, das gelbe Rad. Allen vier Bauteilen wird<br />
wieder eine Aufbauanleitung beigefügt (2). Da der rote Würfel, der grüne<br />
Zylinder und das blaue Dächlein bereits abgespeichert sind, müssen wir nur<br />
noch das gelbe Rad und die Aufbauanleitung abspeichern (3). Für beide<br />
Files, das ‘Haus’ und die ‘Lokomotive’, wurden nur vier Bauelemente und<br />
zwei Aufbauanleitungen abgespeichert. Das Kritische an diesem Verfahren<br />
ist: Wenn eine Aufbauanleitung verloren geht, gibt es keine Möglichkeit der<br />
Rekonstruktion!<br />
einen leistungsfähigen und hochskalierbaren Algorithmus zu<br />
entwickeln, der sowohl in Hardware als auch in Software<br />
Lösungen integrierbar ist. Im Herbst 2008 wird ein DeDuplicationVerfahren<br />
als PostProcessingVerfahren in die<br />
BackupSoftware TSM (Tivoli <strong>Storage</strong> Manager) integriert<br />
und steht mit dem TSM Release 6.1 zur Verfügung.<br />
Im April 2008 aquiriert <strong>IBM</strong> die israelische Firma Diligent,<br />
um mit der DILIGENTTechnologie namens ProtecTIER die<br />
Herausforderungen Datenwachstum und den Wunsch nach<br />
längerer plattenbasierter Datenvorhaltung innerhalb der<br />
Datensicherung zu adressieren. ProtecTIER ist eine für den<br />
EnterpriseMarkt prämierte und seit fünf Jahren bewährte<br />
Softwarelösung, die die Technologien Virtuelle Tape Library<br />
(VTL) und DatenDeDuplizierung (DDD) vereint. Die DDD<br />
Engine innerhalb der ProtecTIERVTLLösung heißt Hyperfactor.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
133
134<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
<strong>IBM</strong> Daten-De-Duplizierung mit ProtecTIER und Hyperfactor<br />
Nach der Übernahme von Diligent etabliert <strong>IBM</strong> einen Produktplan,<br />
um die ProtecTIERVTLLösung mit Hyperfactor in<br />
geeignete <strong>IBM</strong> HardwareProdukte umzusetzen. Bereits im<br />
August 2008 erfolgt die erste Ankündigung der Gateway<br />
Lösungen, also xSeriesbasierende Server, die Plattensystemen,<br />
die als BackupRepository dienen, vorgeschaltet werden<br />
und mit dem ProtecTIER und HyperfactorAlgorithmus<br />
arbeiten. Im Februar 2009 kündigt <strong>IBM</strong> die entsprechenden<br />
Lösungen als Appliances an und im Juli 2009 erfogt die<br />
Ankündigung der direkten Replikationsmöglichkeit der Gateways.<br />
HyperFactor als Data DeDuplizierung ist ein mathematischer<br />
Algorithmus, der auf variable BitBlockVergleiche<br />
schon gespeicherte Blöcke herausfiltert, sodass sie nicht<br />
doppelt abgespeichert werden. Hyperfactor vermeidet also<br />
die Abspeicherung von Duplikaten. Die Einsparung ist dabei<br />
direkt vom erzielten DeDuplizierungsfaktor abhängig, der<br />
bis zu Faktor 25 gehen kann. Vor allem bei BackupVerfahren,<br />
die viele Full Backups beinhalten und eine relativ lange<br />
RetentionPeriode haben, werden die höchsten DeDuplizierungsfaktoren<br />
erreicht. Bei TSM sind die Faktoren wesentlich<br />
kleiner, weil TSM schon auf ‘incremental’ Basis arbeitet und<br />
nur die entstandenen Änderungen im Backup wegschreibt.<br />
Speicherung auf dem ProtecTIER Repository<br />
ProtecTIER Gateway TS7650G<br />
Nachdem das ProtecTier Gateway zwischen den Servern<br />
und den Disksystemen, auf die der Backup gemacht werden<br />
soll, installiert ist, werden die HyperfactorAlgorithmen<br />
dazu verwendet, redundante Daten herauszufiltern. Dazu ist<br />
ein Index notwendig, über den festgestellt werden kann,<br />
welche Datenblöcke bereits im Repository, d.h. auf den<br />
Disksystemen abgespeichert sind. Der Algorithmus analysiert<br />
den ankommenden Datenstrom und stellt über den<br />
Index Ähnlichkeiten fest (agnostisches Verfahren). Werden<br />
keine Ähnlichkeiten gefunden, wird der entsprechende<br />
Block direkt im Repository gespeichert. Bei Ähnlichkeiten<br />
werden die entsprechenden Blöcke vom Repository eingelesen<br />
und mit den neuen Daten verglichen. Dabei werden die<br />
identischen Daten herausgefiltert und nur die verbleibende<br />
Differenz wird im Repository neu abgespeichert. Über diese<br />
Methode ist eine 100%ige Datenintegrität gewährleistet. Der<br />
Index hat eine feste Größe von 4 GB und wird permanent im<br />
Hauptspeicher des Gateways (xSeries) gehalten.<br />
Das Verhältnis der gespeicherten Daten zum Index (Ratio of<br />
Repository to Index) spiegelt die Effizienz des Index wider.<br />
Die Zahl von 250.000:1 beim HyperfactorVerfahren sagt<br />
aus, dass ProtecTier mit einem festen Memory Index von 4<br />
GB das 250.000fache, d.h. 1 PetaByte an Daten verwalten<br />
Metadata<br />
Metadata<br />
Metadata<br />
Metadata<br />
Metadata<br />
Metadata<br />
User Data User Data<br />
User Data<br />
User Data User Data<br />
User Data<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
kann. Dabei ist der DeDuplizierungsfaktor noch nicht<br />
berücksichtigt. Wäre der erzielte Faktor bei 25, könnten 25<br />
PetaByte an Daten verwaltet werden. Dies ist der große<br />
Vorteil dieser Lösung, weil die verwalteten Kapazitäten ohne<br />
Leistungsverlust in diese hohe Dimension skaliert werden<br />
können (im Vergleich: Hashbasierende Verfahren erzielen in<br />
der Regel nur ein Ratio von etwa 400:1. Das bedeutet, dass<br />
die Anforderung an die Hauptspeichergröße im Rechner<br />
wesentlich höher ist und ab einer bestimmten Datenmenge<br />
der Index nicht mehr komplett im Hauptspeicher gehalten<br />
werden kann. Dann kommt es sofort zum PerformanceEinbruch!<br />
Die ProtecTierLösung ist daher deutlich besser für<br />
sehr hohe Kapazitäten bei hoher Leistungsfähigkeit im Vergleich<br />
zu Hashbasierenden Verfahren geeignet und bildet<br />
eine echte ‘Enterprise’Lösung ab).<br />
Das ProtecTier Repository beinhaltet sowohl die Backup<br />
Daten als auch die dazugehörigen MetaDaten. Die Meta<br />
Daten beinhalten 2 Kopien des Hyperfactor Index, alle virtuellen<br />
Volume Files, die Konfigurationsdaten der virtuellen<br />
Libraries und <strong>Storage</strong> Management Daten (PointerTabellen,<br />
Referenz Counter etc.).<br />
Dabei werden die Datenblöcke selbst im Repository RAID5<br />
basierend abgespeichert, während die MetaDaten aus<br />
Sicherheitsgründen RAID10 basierend, also doppelt, abgespeichert<br />
werden.<br />
Das Repository kann auf einem einzigen RAIDArray gehalten<br />
werden oder über viele RAIDArrays verteilt werden.<br />
LUNs, die für das ProtecTier Repository benutzt werden,<br />
dürfen nicht von einer ArrayGruppe kommen, die von anderen<br />
Applikationen benutzt werden. Es wird empfohlen, dass<br />
für das Repository eine LUN so angelegt wird, dass sie die<br />
gesamte RAIDGruppe umfasst.<br />
<strong>IBM</strong> Hyperfactor kann bis zu einer Datenreduzierung 25:1<br />
führen und skaliert bis auf 1 PB native Plattenkapazität. Bei<br />
einem erreichten DeDuplicationFaktor 25:1 können bei<br />
einer nativen 1PBPlattenkapazität 25 PB an Daten verwaltet<br />
werden. Das Gateway ist als Single Note Gateway oder in<br />
einer Clusterkonfiguration mit zwei Nodes verfügbar.<br />
Die Leistung liegt bei einer Clusterkonfiguration bei bis zu<br />
1.000 MB/s, ist aber direkt abhängig von der dahinterliegenden<br />
Platteninfrastruktur und Plattenart (FCPlatten<br />
oder SATA, FATAPlatten).<br />
Die hohe Leistungsfähigkeit von Hyperfactor kommt von der<br />
Tatsache, dass der Algorithmus auf dynamischer Blockbasis<br />
arbeitet und identifizierte kleine Blöcke, die kleiner als 8 KB<br />
sind, nicht betrachtet werden und sofort als ‘neu’ im Repository<br />
gespeichert werden. Würde man diese kleinen Blöcke<br />
wie die großen Blöcke behandeln, wäre eine Skalierbarkeit<br />
in diese hohe Leistungsklasse nicht möglich.<br />
Als BandLaufwerksemulation verwendet ProtecTier virtuelle<br />
LTOLaufwerke (LTO3). Neben LTO ist auch die Emulation<br />
von DLT (DLT7000) möglich. Unterstützt sind bis zu 256 virtuelle<br />
Laufwerke per Node und 512 Laufwerke per Cluster.<br />
In einer Clusterkonfiguration können bis zu 16 virtuelle<br />
Libraries abgebildet und bis zu 500.000 virtuelle Kassetten<br />
emuliert werden.<br />
Das HyperfactorDeDuplicationVerfahren stellt derzeit auf<br />
dem Markt als einziges Verfahren eine 100%ige Dateninte-<br />
grität sicher. Im Backend, also hinter dem Gateway, sind alle<br />
aktuellen <strong>IBM</strong> Plattensysteme unterstützt. Auch <strong>IBM</strong> Nicht<br />
<strong>System</strong>e von HDS, EMC und HP können betrieben werden.<br />
ProtecTIER neue Prozessoren für das TS7650G Gateway<br />
Im 1. Quartal 2009 führt <strong>IBM</strong> neue Prozessoren für die<br />
TS7650G Gateways ein. Zum Einsatz kommt der x3850 M2<br />
MT7233 Prozessor. Hierbei handelt es sich um einen 4 x 6<br />
Core Prozessor mit 2,6 GHz und 32 GB RAM mit zwei integrierten<br />
RAID1betriebenen 146 GB SAS DiskLaufwerken, 2<br />
Emulex Dual Port FC Adapter für die Hostanbindung und<br />
zwei Qlogic Dual Port FC HBAs für die Anbindung des<br />
BackendPlattenRepositories. Für die Replizierung stehen<br />
Dual Port Gigabit Ethernet Adapter zur Verfügung. Der neue<br />
Prozessor steigert die GatewayLeistungsfähigkeit um ca.<br />
30%. Dies wird durch den 4 x 6 Core Prozessor möglich,<br />
der jetzt gleichzeitig 24 Datenströme mit DeDuplizierung<br />
bearbeiten kann.<br />
TS7650G Disk Backend als Repository<br />
Im Backend des TS7650G Gateways werden die <strong>IBM</strong> Plattensysteme<br />
DS3400, die DS4000 und DS5000Modelle, die<br />
DS8000, XIV <strong>Storage</strong>, SVC und Nseries unterstützt. Ebenso<br />
können die Nicht<strong>IBM</strong>Plattensysteme HDS AMS1000, EMC<br />
CX und HP EVA betrieben werden.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
135
136<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
ProtecTIER Replikation<br />
Für die GatewayLösung besteht seit September 2009 (Verfügbarkeit)<br />
die Möglichkeit der IPbasierten Replikation.<br />
Damit können virtuelle Bänder in eine andere Lokation direkt<br />
kopiert werden, um auf diese Weise die Notwendigkeit von<br />
physikalischen Bandtransporten zu vermeiden. Da bei der<br />
Replikation nur die geänderten Blöcke übertragen werden,<br />
hält sich die benötigte Bandbreite der IPVerbindungen in<br />
Grenzen. Die Anforderung für eine dritte, ‘sichere’ Kopie<br />
besteht bei vielen ITUmgebungen schon lange, doch bisher<br />
konnte dies technisch nicht umgesetzt werden, weil entsprechende<br />
Leitungskapazitäten nicht vorhanden oder nicht<br />
bezahlbar waren. Jetzt steht dem nichts mehr im Wege und<br />
solche Konzepte können ohne die Notwendigkeit riesiger<br />
Übertragungsbandbreiten realisiert werden.<br />
Pro Node stehen zwei EthernetIPPorts zur Verfügung.<br />
Ältere <strong>System</strong>e können durch eine zweite EthernetKarte<br />
nachgerüstet werden. Das Besondere dieser Replikationsfunktion<br />
ist der automatische Failover und Failback. Fällt die<br />
primäre Seite aus, kann die Disaster/RecoverySeite per<br />
Knopfdruck zur ‘Primary’ gemacht werden und der Betrieb<br />
läuft weiter. Steht die primäre Seite dann wieder zur Verfügung,<br />
wird ein Failback durchgeführt und die Daten werden<br />
zur primären Seite zurückrepliziert.<br />
Die Replikation kann Policybasierend betrieben werden.<br />
Dabei kann die Replikation ständig und sofort durchgeführt<br />
werden (Immediate Mode). Man kann die Replikation aber<br />
auch in einem geplanten Zeitfenster durchführen (Replication<br />
Window). Die Policies können sowohl einzelne Kassetten<br />
als auch einen Pool von vielen Kassetten administrieren.<br />
Dabei gibt es zwei BetriebsModi: Der VisibilityControl<br />
Modus importiert bzw. exportiert die Kassetten, die über die<br />
BackupApplikation gesteuert werden (CheckOut). Kassetten,<br />
die exportiert werden, werden in die TargetVTL repliziert.<br />
Beim BasicDRModus (Disaster Recovery) läuft die<br />
Replikation ständig und transparent zur BackupApplikation<br />
mit und die Kassetten stehen sowohl auf der primären Seite<br />
als auch auf der RemoteSeite zur Verfügung.<br />
Multipathing und Control Path Failover<br />
Das TS7650G Gateway und die TS7650 Appliances bieten<br />
zusammen mit der TS7500 Familie derzeit als einzige VTL<br />
<strong>System</strong>e auf dem Markt einen MultipfadDeviceTreiber für<br />
FC Failover und Load Balancing an. Damit lassen sich die<br />
VTLLösungen redundant in SAN FabricInfrastrukturen<br />
betreiben. Fallen Adapter, Pfade oder ganze SANSwitche<br />
aus, läuft der Betrieb unterbrechungsfrei weiter, weil die<br />
‘Commands’ für die virtuelle Library und Laufwerke automatisch<br />
über die verbleibenden Adapter, Pfade und SANSwitche<br />
übertragen werden können (Control Path Failover und<br />
Data Path Failover).<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Zusätzlich bietet der Data Path Failover ein Load Balancing<br />
auf den redundanten Pfaden vom Server zu den virtuellen<br />
Laufwerken an. Dadurch wird eine gleichmäßige Auslastung<br />
der physikalischen FibreChannelLinks und den FCPorts<br />
ermöglicht.<br />
ProtecTIER TS7650 Appliances<br />
Neben der GatewayLösung stehen auch Appliance<br />
Lösungen im Sinne von ‘allinone’ zur Verfügung.<br />
Mit den Appliances adressiert <strong>IBM</strong> vor allem Mittelstands<br />
kunden, die jetzt auch die Möglichkeit haben, eine Enter<br />
priseLösung für DeDupVTLs kostengünstig zu etablieren.<br />
<strong>IBM</strong> hat den HyperfactorDeDuplizierungsalgorithmus nach<br />
allen Regeln der Kunst darauf überprüft, ob tatsächlich eine<br />
100%ige Datenintegrität gewährleitet ist. Dafür wurden auch<br />
Fremdfirmen und ‘Hacker’ beauftragt. Es konnten keine<br />
Schwachstellen aufgedeckt werden. Es ist deshalb davon<br />
auszugehen, dass <strong>IBM</strong> DatenDeDuplizierung über die Zeit<br />
auf das ganze <strong>IBM</strong> Speicherportfolio und alle Betriebssystemplattformen<br />
adaptieren wird. ProtecTier ist für die MainframeUmgebung<br />
(<strong>System</strong> z) bereits in 2010 vorgesehen.<br />
TS1130 Bandlaufwerk der ‘Enterprise’-Klasse<br />
<strong>IBM</strong> TS1130 Bandlaufwerk der ‘Enterprise’-Klasse –<br />
der Durchbruch in der Tape-Technologie<br />
Im Juli 2008 kündigt <strong>IBM</strong> mit Verfügbarkeit September 2008<br />
das neue Bandlaufwerk TS1130 an und leitet damit eine<br />
neue Technologiebasis für die TapeWeiterentwicklung ein!<br />
Das technologische Highlight des TS1130 Laufwerks spiegelt<br />
sich in den neuen Schreib/Leseelementen wider. Erstmalig<br />
wird in einer TapeLaufwerkstechnologie neben den<br />
induktiven Schreibköpfen als Lesekopf ein GMR-Lesekopf<br />
(Giant Magneto Resistance) eingesetzt. GMR war im Jahr<br />
2007 in aller Munde, als für die Entdeckung des GMR<br />
Effekts Peter Grünberg und Albert Fert mit dem Nobelpreis<br />
für Physik ausgezeichnet wurden. Ohne diese Entdeckung<br />
wären die hohen Kapazitäten bei Festplatten nicht möglich<br />
geworden. Die Umsetzung dieses Effekts in ein Produkt<br />
wurde durch den <strong>IBM</strong> Forscher Stuart Parkin ermöglicht, der<br />
dazu noch sieben Jahre benötigte und Ende 1997 den<br />
ersten GMRLesekopf in ein Plattenlaufwerk integrierte. Nun<br />
hält diese Technologie auch Einzug im TapeBereich!<br />
GMRLeseköpfe sind in der Lage, kleinste Streufelder von<br />
Bits auszulesen und das in einer Geschwindigkeit, wie es<br />
mit keiner anderen Technologie möglich ist. Dem GMRKopf<br />
ist es zu verdanken, dass jetzt in der TS1130 die ‘High<br />
Speed Search’-Geschwindigkeit von bisher 10 m/s (bei<br />
TS1120) auf sagenhafte 12,4 m/s gesteigert werden konnte,<br />
also von 36 km/h auf 45 km/h. Beim High Speed Search<br />
werden die Tape Marks auf dem Band beim Vorspulen ausgelesen<br />
und das geht jetzt mit dem GMRKopf wesentlich<br />
schneller, sodass damit die Zugriffsgeschwindigkeit auf eine<br />
auszulesende File beträchtlich gesteigert wird.<br />
Neben den Highlights, die schon die Vorgängertechnologie<br />
TS1120 integriert hatte, sind viele zusätzliche Einrichtungen<br />
verbessert worden, um eine noch höhrere Verfügbarkeit und<br />
Zuverlässigkeit zu gewährleisten.<br />
Die VorgängerLaufwerke TS1120 sind zudem auf die neuen<br />
TS1130 Laufwerke hochrüstbar, was jeden TS1120 Nutzer<br />
freuen wird. Die Medien, also die Kassetten, bleiben dieselben,<br />
d. h. kein Medienwechsel.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
137
138<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
3592 Kassetten Bandlänge Kassetten-Type Gen. 1 3592 Gen. 2 TS1120 Gen. 3 TS1130<br />
JJ 200 m Read Write 60 GB 100 GB 128 GB<br />
JA 609 m Read Write 300 GB 500 GB 640 GB<br />
JB 825 m Read Write 700 GB 1.000 GB<br />
JR 200 m WORM 60 GB 100 GB 128 GB<br />
JW 609 m WORM 300 GB 500 GB 640 GB<br />
JX 825 m WORM 700 GB 1.000 GB<br />
<strong>IBM</strong> 3592 Bandkassettenformate<br />
Das TS1130 Laufwerk arbeitet mit der zur Zeit höchsten<br />
Datenrate (160 MB/s native) und benötigt für die Sicherung<br />
von komprimierten Daten (2,3:1) mit bis zu 1.296 GB nur<br />
eine Stunde. Die maximale Kapazität pro Kassette beträgt<br />
1 Terabyte (JB und JXKassetten). Dabei werden 1.152<br />
Spuren auf der Kassette aufgezeichnet (288 per Datenband<br />
x 4 = 1.152 Spuren).<br />
Bandformate und Kompatibilität<br />
Die 1. Laufwerksgeneration 3592J1A schrieb im Gen1Format<br />
300 GB auf die JAKassette und 60 GB auf die JJKassette.<br />
Die 2. Laufwerksgeneration TS1120 (3592E05) schreibt im<br />
Gen2Format 500 GB auf die JAKassette und 100 GB auf<br />
die JJKassette. Das TS1120 Laufwerk kann auch im Gen1<br />
Format 300 GB auf die JA und 60 GB auf die JJKassette<br />
schreiben. Seit Verfügbarkeit der JBKassette schreibt das<br />
TS1120 Laufwerk im Gen2Format 700 GB auf die JB<br />
Kassette.<br />
Die 3. Laufwerksgeneration TS1130 (3592E06/EU6) schreibt<br />
im Gen3Format 1.000 GB und im Gen2Format 700 GB auf<br />
die JBKassette; 640 GB im Gen3Format und 500 GB im<br />
Gen2Format auf die JAKassette und 128 GB im Gen3Format<br />
und 100 GB im Gen2Format auf die JJKassette.<br />
Der Formatfaktor des Laufwerks und der Kassetten ermöglicht<br />
den Einsatz des Laufwerks in den Tape Libraries <strong>IBM</strong> 3494<br />
und <strong>IBM</strong> TS3500, TS3400 oder in StandaloneRack<br />
Lösungen. Unternehmensweite Anschlussmöglichkeiten<br />
sind gegeben: FibreChannel 4 Gb/s über Switched Fabric<br />
mit zwei Ports für Open<strong>System</strong>sServer und FICON oder<br />
ESCONUnterstützung (2 Gb) über A60 u J70 und (4 Gb)<br />
über C06 für Server mit zOS.<br />
Die EncryptionMöglichkeit, <strong>IBM</strong> 3592 Kassetten so zu<br />
beschreiben, dass nur die Instanz sie wieder auslesen kann,<br />
die den dazugehörigen Encryption Key kennt und hat, ist<br />
wie beim Vorgänger TS1120 gegeben.<br />
Mit den Durchsatz/Kapazitätsmerkmalen und den schnellen<br />
Spul und FastSearchZeiten, ist das <strong>IBM</strong> TS1130 Laufwerk<br />
einzigartig im Markt. Ein BackupFenster kann mit dem Einsatz<br />
von TS1130 Laufwerken bei gleicher Laufwerksanzahl<br />
auf 80% reduziert werden (z. B. Im Vergleich zu Generation 1).<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Das Laufwerk ist mit zwei ControlProzessoren ausgestattet.<br />
Das führt zu enormer Performance und Ausfallsicherheit.<br />
Um den enormen Durchsatz von 160 MB/s auch nutzen zu<br />
können, sind die TS1130 Laufwerke mit zwei 4GbitFC<br />
Schittstellen ausgerüstet. Bereits mit den 3592Laufwerken<br />
konnte <strong>IBM</strong> den Weltrekord in Sachen Spulgeschwindigkeit<br />
(‘High Speed Search’ von 8 m/s.) für sich beanspruchen.<br />
Mit den neuen TS1130 Laufwerken übertrifft <strong>IBM</strong> ihren eigenen<br />
Rekord und spult mit 12,4 m/s. Das entspricht 45 km/Stunde –<br />
atemberaubend für ein Bandlaufwerk! Ohne GMRTechnik<br />
hätte das nie realisiert werden können!<br />
<strong>IBM</strong> 3592/TS1120/TS1130 Laufwerkspezifikationen im Überblick<br />
Der Pufferspeicher wurde zum Vorgänger (TS1120) auf<br />
1 GB verdoppelt. Dadurch wird eine wesentliche Leistungssteigerung<br />
bezüglich Virtual Backhitch erreicht, da das<br />
Laufwerk noch länger am ‘Streamen’ bleibt. Für die Optimierung<br />
der Verarbeitung von großen Files wurde ein<br />
SkipSyncFeature eingeführt, das eine bis zu 80 %ige<br />
Leistungsverbesserung für diese Worloads bewirkt. Trotz<br />
der höheren kapazitiven Nutzung der Kassetten (bis 1 TB)<br />
ist das TS1130 Laufwerke in allen Bereichen wesentlich<br />
schneller als sein Vorgänger.<br />
Laufwerk Feature <strong>IBM</strong> 3592 <strong>IBM</strong> TS1120 <strong>IBM</strong> TS1130<br />
Max. Kassettenkapazität 300 GB 700 GB 1.000 GB<br />
Datenrate (native) 40 MB/s 104 MB/s 160 MB/s<br />
<strong>System</strong> z-Anschluss 2 Gb FICON/ESCON 4 Gb FICON/ESCON 4 Gb FICON/ESCON<br />
Open-<strong>System</strong>-Anschluss 2 Gbps FibreChannel 4 Gbps FibreChannel 4 Gbps FibreChannel<br />
Virtual Backhitch Ja Ja Ja (erweitert)<br />
Pufferspeicher 128 MB 512 MB 1 GB<br />
Speed Matching 6 Geschwindigkeiten 6 Geschwindigkeiten 6 Geschwindigkeiten<br />
Load-Thread-Zeiten 16 Sekunden 13 Sekunden 13 Sekunden<br />
Durchschnittliche Zugriffszeit inkl.<br />
Laden<br />
60 Sekunden 47 Sekunden 38 Sekunden<br />
Verschlüsselung nein Ja (kein Aufpreis) Ja (kein Aufpreis)<br />
Stromverbrauch 42 Watt 42 Watt 46 Watt<br />
Standby 27 Watt 27 Watt 17 Watt<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
139
140<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
Virtualisierung von Tape Libraries<br />
TS3500 (3584) Library-Virtualisierung mit ALMS<br />
(Advanced Library Management <strong>System</strong>)<br />
Eine einmalige Funktionalität bietet die TS3500 mit ALMS<br />
(Advanced Tape Library Management <strong>System</strong>). ALMS steht<br />
für die TS3500 schon seit April 2006 zur Verfügung, wurde<br />
aber erst richtig im Jahr 2007 genutzt. Mit ALMS wird die<br />
physische Library virtualisiert, d. h., die HW wird von den Hosts<br />
abgekoppelt. Zu den Hosts werden virtuelle Laufwerke und<br />
virtuelle Kassettenslots dargestellt. Dies ermög licht eine<br />
noch nie dagewesene Flexibilität, weil logische Partitionen<br />
als logische Libraries im laufenden Betrieb dynamisch verändert,<br />
also verkleinert oder vergrößert, werden können.<br />
<strong>Storage</strong> Slot und Drive-Virtualisierung mit ALMS<br />
Die Hosts, also die BackupApplikationen, sehen völlig<br />
transparent virtuelle Laufwerke und virtuelle Kassettenslots<br />
so, als ob sie physisch vorhanden wären. ALMS zieht<br />
zwischen der LibraryHardware und den Hosts eine virtuelle<br />
Schicht ein, die es erlaubt, im laufenden Betrieb Hardware<br />
Erweiterungen vorzunehmen, logische Partitionen umzukonfigurieren,<br />
zu verkleinern und zu vergrößern, ob es nun die<br />
Laufwerke oder die Slots betrifft. ALMS ist eine einmalige<br />
Funktionalität, die es nur mit der TS3500 Library gibt. ALMS<br />
bietet vier wichtige Funktionalitäten für die TS3500 Library.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
1.) Dynamisches Partitioning<br />
Mit ALMS können im laufenden Betrieb Partitionen erstellt oder<br />
verändert werden. Die physische Position in der Library ist<br />
dabei nicht mehr relevant. Dies bezieht sich auf Kassettenund<br />
Laufwerksstellplätze.<br />
2.) Laufwerkssharing<br />
Mit ALMS können Laufwerke verschiedenen BackupServern<br />
zugeordnet werden und für den BackupServer online gesetzt<br />
werden, der sie gerade benötigt.<br />
3.) Virtual I/O<br />
ALMS bietet eine größere logische I/OStation. Die Funktion<br />
‘Virtual I/O’ ermöglicht es, dem BackupServer eine virtuelle<br />
I/OStation von bis zu 255 Slots darzustellen. Das vereinfacht<br />
das Kassettenmanagement beim Ein und Auschecken.<br />
4.) Overallocation/Underallocation<br />
Mit ALMS ist eine flexible Darstellung der LibraryGröße<br />
möglich und somit Over und Underallocation. Overallocation<br />
verringert den Administrationsaufwand bei einer Library<br />
Erweiterung. Underallocation spart Lizenzkosten, z. B. im<br />
LegatoUmfeld.<br />
TS3500 Library Hardware-Erweiterungen 2007<br />
Neben der Virtual I/OOption des ALMS besteht seit Juni<br />
2006 die Möglichkeit, DFrames mit zusätzlichen physischen<br />
I/O-Stations zu versehen. Bis zu vier I/OStations<br />
mit jeweils bis zu 16 I/OSlots können in eine DFrameTür<br />
integriert werden.<br />
Die TS3500 unterstützt drei solchermaßen ausgestattete<br />
DFrames innerhalb der Library. Zusammen mit der I/O Station<br />
im LFrame mit 32 I/OSlots, drei DFrames mit bis zu<br />
64 I/OSlots bietet die TS3500 die Möglichkeit, 224 physische<br />
Kassetten in die Library als ‘Bulk’ einzulagern oder<br />
als ‘Bulk’ aus der Library zu entnehmen.<br />
Für die TS3500 stehen flexible Modellkonvertierungen zur<br />
Verfügung. So können alte Frames wie z. B. L22 und D22<br />
mit TS1120 Laufwerken in die neuen L23 und D23Frames<br />
umgebaut werden. Dasselbe gilt für die alten LTOFrames<br />
L52 und D52, die in die neuen LTOFrames L53 und D53<br />
umgebaut werden können.<br />
TS3500 Library 4 I/O Station D-Frame<br />
Bei den neuen Frames können nun TS1120 Frames (L23,<br />
D23) in LTOFrames (L53, D53) umgebaut werden. Ebenso<br />
können die neuen LTOFrames (L53, D53) in neue TS1120<br />
Frames (L23, D23) konvertiert werden. Damit bietet die<br />
TS3500 eine sehr flexible Möglichkeit, bestehende Frames<br />
auf neu gewünschte ZielFrames zu konvertieren.<br />
Die TS3500 Library bietet mit der Funktionalität des Data<br />
Gatherings die Möglichkeit, Informationen über die unter<br />
schiedlichsten Dinge, die in der Library ablaufen, zu erhalten.<br />
Die Laufwerk-Statistik enthält Informationen über die letz<br />
ten Mounts jedes Laufwerks (nicht mit LTO1 möglich), die<br />
Port Statistic enthält FibreChannelPortInformationen der<br />
letzten Mounts (nicht mit LTO1 möglich), die Mount History<br />
zeigt die MountStatistik der letzten 100 Kassetten, die ‘demounted’<br />
wurden, und die Library Statistics gibt Aufschluss<br />
über eine effektive Auslastung der logischen Libraries, d. h.,<br />
es wird deutlich, ob manche logischen Libraries überdurchschnittlich<br />
genutzt werden. Dadurch können die Partitionen<br />
geändert werden, um die Library Performance zu verbessern.<br />
Dies ist nur mit den neuen Frames möglich. Zusätzlich kann<br />
eine Vielzahl von Informationen wie Residency Max Time<br />
(maximale Mountzeit einer Kassette), Residency Avg Time<br />
(durchschnittliche Mountzeit einer Kassette), Mounts Total<br />
(Anzahl der gesamten Mounts), Mounts Max Time<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
141
142<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
(Maximalzeiten der Mounts), Mounts Avg Time (Durch<br />
schnittszeiten der Mounts), Ejects Total (Anzahl der Kasset<br />
tenausgaben), Ejects Max Time (Maximalzeiten von Kasset<br />
tenausgaben), Ejects Avg Time (Durchschnittszeiten von<br />
Kassettenausgaben) und Total Inputs (Anzahl der Kasset<br />
tenInserts, die über die I/OStation der Library zugeführt<br />
werden) jeweils der letzten Stunde abgerufen werden.<br />
<strong>IBM</strong> TS3500 Library – neue Erweiterungen und HD-Technologie<br />
(High Density)<br />
Im Juli und August 2008 kündigt <strong>IBM</strong> für die High End<br />
Library TS3500 (3584) massive Erweiterungen an.<br />
Mit dem am 15.07.2008 angekündigten neuen Release 8A<br />
unterstützt die TS3500 Tape Library die neuen TS1130 Laufwerke.<br />
Der Mischbetrieb mit den Vorgängerlaufwerken ist<br />
auch gewährleistet. Voraussetzung für den Einsatz der<br />
neuen TS1130 Laufwerke ist ALMS (Advanced Library<br />
Management <strong>System</strong>). Neben der Unterstützung der<br />
TS1130 Laufwerke bietet der neue Release 8A die Möglichkeit<br />
der SSLFunktionalität (Secure Socket Layer). Dieser<br />
stellt sicher, dass, wenn die Library über das Web administiert<br />
wird, kein anderer sich „dazwischenhacken“ kann, und<br />
gewährleistet so absolute Administrationssicherheit. Ebenso<br />
wurde bezüglich der Standardisierung die IPv6Unterstützung<br />
zur Verfügung gestellt (in USA eine wichtige Anforderung)<br />
und die standardisierte SMISSchnittstelle integriert.<br />
Ein neues Tool ist der TSR, der ‘Tape <strong>System</strong> Reporter’.<br />
Dieser erlaubt es mit Windows basierenden <strong>System</strong>en (also<br />
z. B. mit dem Laptop), aktuelle StatusAbfragen der Library<br />
zu bekommen und zu sammeln (auch über einen längeren<br />
Zeitraum). Alle Updates und Neuerungen sind über einen<br />
MicrocodeUpdate verfügbar.<br />
Für alle Sx4Gehäuseeinheiten stehen jetzt auch LEDs als<br />
Beleuchtung zur Verfügung (Bild rechts). So kann ein Beobachter<br />
genauer sehen, was der Roboter und die Kassetten<br />
machen, und kann den Betriebsablauf in der Library sichtbar<br />
verfolgen. Interessant ist, dass diese Anforderung von<br />
vielen TS3500Nutzern gestellt wurde!<br />
Mit dem am 26.08.08 angekündigten neuen Release 8B<br />
stehen der Library ganz neue, sogenannte High Density<br />
(HD) Frames, zu Verfügung, die es erlauben, über die dreifache<br />
Menge an physischen Kassetten in einem Frame zu<br />
<strong>IBM</strong> TS3500 – schnellstes Bandarchiv im Markt<br />
lagern. Für die 3592Kassetten wird das neue S24 Frame<br />
verwendet, für die LTOKassetten das neue S54 Frame.<br />
Voraussetzung für den Betrieb der neuen Frames in der<br />
TS3500 Library ist ALMS (Advanced Library Management<br />
<strong>System</strong>) und ein neuer Gripper. Die Kassetten werden in<br />
mehreren SlotReihen hintereinander abgelegt. Greift der<br />
Gripper, der diesem neuen Handling angepasst wurde, eine<br />
Kassette aus der ersten Reihe, rutschen die dahinterliegenden<br />
Kassetten um einen Slot nach vorne und umgekehrt!<br />
Eine geniale und <strong>IBM</strong> patentierte Konstruktion, um auf allerkleinstem<br />
Raum viele Kassetten unterzubringen und dabei<br />
Vollautomation sicherzustellen.<br />
<strong>IBM</strong> TS3500 – LED-Beleuchtung<br />
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<br />
als LTOKassetten sind, sind 5 Tierstufen etabliert, d. h., auf<br />
der Rückseite des Frames sind hinter jeder Slotreihe nochmals<br />
3 zusätzliche Slotreihen untergebracht. Ein S24 Frame<br />
kann damit bis zu 1.000 Kassetten ablegen. Für die<br />
kleineren LTOKassetten stehen sogar 6 Tierstufen zur Verfügung,<br />
d. h., hinter jeder Slotreihe auf der Rückseite sind<br />
nochmals 4 zusätzliche Slotreihen untergebracht. Ein S54<br />
Frame kann somit bis zu 1.320 Kassetten ablegen.<br />
<strong>IBM</strong> TS3500 – HD-Frame S54 für LTO-Kassetten<br />
Die Hardware in Form von HDFrames ist die eine Sache,<br />
doch jetzt gilt es, diese HDFrames effektiv zu verwalten.<br />
Dazu stehen neue Funktionen für die TS3500 Library zur<br />
Verfügung.<br />
Hier ist am Beispiel des S54 Frames (siehe Abbildung) mit<br />
bis zu 5 Tierstufen das HD Slot Management beschrieben.<br />
Alle Tiers und damit alle HDSlots sind völlig transparent zu<br />
den Hosts. Drei KeyElemente sind für das HD Slot Management<br />
zuständig. Die Funktion Floating Home Cell optimiert<br />
die Kassettenbelegung in den Slots der Tierstufen 0 und 1.<br />
Darüber hinaus werden die Slots der Tierstufe 0 als Cartridge<br />
Cache behandelt, d.h. alle Kassetten, die sich in<br />
Slots der Tierstufe 0 befinden, werden einem LRUCaching<br />
Algorithmus (Least Recently Used) unterzogen. Werden die<br />
Kassetten länger nicht gebraucht (im Vergleich zu anderen<br />
Kassetten der Tierstufe 0), werden sie von Tierstufe 0 in<br />
Slots der Tierstufe 1 verlagert. Werden sie dort im Vergleich<br />
zu anderen Kassetten der Tierstufe 1 nicht benutzt, werden<br />
sie in Slots der Tierstufe 2 verlagert. Das geht je nach Füllgrad<br />
der HDSlots bis in die letzte Tierstufe. Das Cartridge<br />
Caching stellt also sicher, dass Kassetten, die häufig benötigt<br />
werden, immer im direkten Zugriff des Roboters stehen,<br />
also in Tierstufe 0 und 1.<br />
Sind nun mehrere HDFrames innerhalb einer Library in<br />
Betrieb, sorgt die Funktion Tier Load Balancing dafür, dass<br />
alle HDSlots vom Kassettenfüllgrad über alle HDFrames<br />
gleichmäßig benutzt werden (ausbalancierte Slotausnutzung<br />
über alle HDFrames). So wird sichergestellt, dass sich die<br />
Kassetten möglichst in den Slots der kleineren Tierstufen<br />
befinden und alle HDFrames bezüglich ihrer Tierbenutzung<br />
gleichmäßig optimiert werden.<br />
Über eine SCSI Command Option kann für bestimmte Kas<br />
setten der Cartridge Caching Algorithmus umgangen wer<br />
den. Die Option lässt zu, ausgewählte Kassetten immer im<br />
Cache, also immer in der Tierstufe 0 zu lagern oder auch<br />
nicht. Der Command steuert das gezielte Prestaging und<br />
Destaging von ausgewählten Kassetten in und aus dem<br />
Cache (Tierstufe 0).<br />
Für die neuen HDFrames steht eine „Capacity on Demand“<br />
Option (CoD) zur Verfügung. Standardmäßig werden die<br />
neuen S24 und S54 Frames so ausgeliefert, dass 3 vertikale<br />
Tierreihen aktiviert sind. Tier 0 auf der Frontseite und die<br />
ersten beiden Tiers 1 und 2 auf der Rückseite des Frames.<br />
Mit dieser Aktivierung kann ein S24 Frames 600 Slots und<br />
ein S54 Frames 660 Slots nutzen.<br />
Über eine ‘On Demand’Aktivierung können die noch nicht<br />
genutzten Slots freigeschaltet werden, d. h., bei dem S24<br />
Frame werden die Tiers 3 und 4 freigeschaltet und bei dem<br />
S54 Frame die Tiers 3, 4 und 5. Mit dieser Freischaltung<br />
können alle Slots im Frame genutzt werden und damit die<br />
maximale Anzahl an Kassetten und damit die höchste Kapazität<br />
abgebildet werden.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
143
144<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
Modellkonvertierungen der neuen Frames, also der Umbau<br />
von S24 nach S54 oder von S54 nach S24 stehen seit dem<br />
20. Februar 2009 zur Verfügung.<br />
Mount-Zeiten HD-Frames<br />
Die Roboter MountZeiten wurden für die HDFrames in<br />
einer 6FrameKonfiguration der TS3500 unter Produktionsbedingungen<br />
bei einem Kunden ermittelt (siehe Grafik<br />
‘Roboter MountZeiten HDFrames’).<br />
Roboter Mount-Zeiten HD-Frames<br />
Der Zugriff auf Kassetten in der Tierstufe 0 ist am schnellsten,<br />
da der Greifer des Roboters in seiner Grundstellung in Richtung<br />
Tierstufe 0 ausgerichtet ist. Der Zugriff auf die Tierstufe<br />
1 ist 760 ms langsamer, da jetzt der Greifer sich um 180<br />
Grad drehen muss, um sich in Richtung Tierstufe 1 auszurichten.<br />
Kassetten in der Tierstufe 2 benötigen nochmals zusätzliche<br />
2 Sekunden. Diese kommen zustande, da der Roboter<br />
zuerst die Kassette in der Tierstufe 1 herausnehmen muss.<br />
Dann rutscht die Kassette in der Tierstufe 2 nach vorne in<br />
die Tierstufe 1. Der Roboter greift dann diese Kassette mit<br />
seinem zweiten Greifer (Dual Gripper Standard) ab. Die<br />
große Zeitspanne ergibt sich zwischen Tierstufe 2 und 3.<br />
Die 10,9 Sekunden kommen zustande, weil der Roboter<br />
zuerst die Kassetten der Tierstufe 1 und 2 herausnehmen<br />
und an einen anderen Platz bringen muss. Dies wird aufgrund<br />
der zwei Gripper in einem Vorgang durchgeführt.<br />
Inzwischen sind die Kassetten von Tierstufe 3 und 4 in die<br />
Tierstufen 1 und 2 vorgerutscht. Der Roboter kann sie dann<br />
dort in einer zweiten Aktion abholen.<br />
Tape Library-Virtualisierung mit dem Enterprise Removable<br />
Media Manager (eRMM, iRMM)<br />
Der Enterprise Removable Media Manager bildet einen Virtualisierungslayer<br />
zwischen DatensicherungsAnwendungen<br />
und der Tape LibraryHardware. Durch die Entkoppelung<br />
von Datensicherungsanwendungen und Tape LibraryHardware<br />
wird größtmögliche Flexibilität und Skalierbarkeit der<br />
Tape LibraryInfrastruktur erreicht und der Funktionsumfang<br />
von Libraries mit SCSI Media Changer wie z. B. <strong>IBM</strong> TS3500,<br />
durch erweitertes Media Management ergänzt. eRMM (seit<br />
August 2007 als Programmpaket iRMM – integrated<br />
Removable Media Manager – verfügbar) bietet die effizientere<br />
Nutzung von Drives und Libraries durch dynamisches<br />
Sharing und Pooling der Bandlaufwerke. Es erlaubt zentrales<br />
Management von Bändern und Bandlaufwerken, die von<br />
verschiedenen Anwendungen genutzt werden, und bietet so<br />
größtmögliche Flexibilität und Skalierbarkeit der Tape Library<br />
Infrastruktur. Das Ergebnis sind verkürzte BackupLaufzeiten<br />
durch flexible Tape DeviceZuordnung und eine deutliche<br />
Ressourceneinsparung bei der Tape LibraryInfrastruktur.<br />
In modernen Umgebungen mit Speichernetzen sind Server<br />
und Tape Libraries über ein Speichernetz miteinander verbunden.<br />
Damit sind die technischen Voraussetzungen für<br />
das effiziente Sharing von TapeRessourcen zwischen verschiedenen<br />
Backup und Archivierungsservern nur bedingt<br />
erfüllt. Für Tapes fehlt eine Abstraktionsschicht, die mit<br />
einem Volume Manager (SAN Volume Controller) oder einem<br />
Dateisystem (SAN File <strong>System</strong>) vergleichbar ist. Das führt<br />
dazu, dass TapeRessourcen nur sehr eingeschränkt von<br />
mehreren Anwendungen gemeinsam genutzt werden können.<br />
Die Datensicherungsanwendungen verlangen meist exklusiven<br />
Zugriff auf einen Teil der Ressourcen. Es fehlte bisher<br />
eine zentrale Verwaltung von TapeRessourcen, welche die<br />
Voraussetzung für ein anwendungsübergreifendes Sharing<br />
ermöglichen. Mit eRMM (iRMM) macht <strong>IBM</strong> eine Lösung<br />
ver fügbar, die genau diese Anforderung erfüllt. Dieses<br />
Programm produkt wurde in der <strong>IBM</strong> Lokation in Mainz ent<br />
wickelt. iRMM ist jetzt auch in modifizierter Form integraler<br />
Bestandteil der TS7700 Virtual Tape Server <strong>System</strong>e und<br />
ersetzt den bisher benötigten Library Manager in <strong>System</strong> z<br />
Umgebungen.<br />
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 <strong>System</strong>s<br />
TS3400 Mini-Library für High-End-Tape-Technologie<br />
Im Februar 2007 kündigte <strong>IBM</strong> eine kleine Library TS3400<br />
an, die wie die große TS3500 mit den TS1120 und TS1130<br />
HighEndLaufwerken arbeitet. Die Library wurde speziell für<br />
die HighEndTapeLaufwerke TS1120 (JaguarTechnologie)<br />
als Einstiegslösung konzipiert. Diese kleine Library kann<br />
sowohl im Open<strong>System</strong>sUmfeld als auch im Mainframe<br />
Umfeld (über den TS1120 FICON Controller seit August 2007)<br />
betrieben werden. Die TS3400 bietet eine native Kapazität<br />
von 12,6 TB (TS1120) und 18 TB (TS1130) an.<br />
In die TS3400 können 1 bis 2 TS1120 und TS1130 FC-<br />
Bandlaufwerke mit 4GB/sDualPortFibreChannel<br />
Anschlüssen integriert werden. Man kann alle Kassetten,<br />
die ein TS1120 und TS1130 Laufwerk verarbeitet, verwenden<br />
(100, 500 und 700GBKassetten bei TS1120 und 128,<br />
640 und 1.000GBKasetten bei TS1130). Die Library unterstützt<br />
sowohl überschreibbare als auch WORMKassetten<br />
und bietet direkte Encryption und Encryption Key ManagementUnterstützung<br />
an, eine Verschlüsselungstechnik, die<br />
für die TS1120 Laufwerke im Herbst 2006 zur Verfügung<br />
gestellt wurde und ebenso in die TS1130 Laufwerke integriert<br />
ist. Die Library hat 2 herausnehmbare austauschbare<br />
Kassettenmagazine. Jedes Magazin kann bis zu 9 Kassetten<br />
aufnehmen. Das untere Magazin kann so konfiguriert<br />
werden, dass 3 Slots im Magazin als I/OStation dienen. Das<br />
obere Magazin ist mit zwei Reinigungskassettenslots konfigurierbar.<br />
Die Ausstattung mit BarcodeLeser ist Standard.<br />
Die TS3400 bietet eine Partitionierung von bis zu 2 logischen<br />
Libraries. Jede logische Library enthält ein Laufwerk und ein<br />
Magazin und kann im SequentialMode (Autoloader) oder<br />
RandomMode (Library) arbeiten. Die TS3400 ist über das<br />
lokale Operator Panel oder remote über ein Web GUI admi<br />
nistrier und managebar. Die Library kann ‘Stand Alone’ oder<br />
‘Rack Mounted’ (5U) betrieben werden. Die Speicherkapazität<br />
bei Verwendung der 700GBKassetten geht bis 12,6 TB<br />
(bis 37,8 TB mit 3:1 Kompression) und bei Verwendung<br />
der 1.000GBKassetten bis 18 TB (bis 54 TB mit 3:1 Kompression).<br />
Die TS3400 ist eine hochredundante Library und mit redundanter<br />
Stromversorgung, ‘Hot Swappable’Laufwerken und<br />
Netzteilen, einem doppelten Stromanschluss sowie Control<br />
Path und Data Path FailoverMöglichkeit ausgestattet. Die<br />
Library kann an <strong>IBM</strong> <strong>System</strong>e i, p, x und zLinux sowie an z/OS<br />
via TS1120 Controller angeschlossen werden. Außer den<br />
<strong>IBM</strong> <strong>System</strong>en werden die BetriebssystemPlattformen von<br />
HP, Sun und Microsoft Windows unterstützt.<br />
Damit stellt <strong>IBM</strong> die Möglichkeit zur Verfügung, große<br />
TS3500 Libraries mit TS1120 und TS1130 Laufwerken in<br />
einem zentralen Rechenzentrum zu betreiben, während<br />
Außenstellen mit derselben Technologie in Form einer Mini<br />
Library arbeiten können. Dies ermöglicht den Datenträgeraustausch<br />
in Form von 3592 Kassetten zwischen Rechenzentrum<br />
und Außenstellen. Um hier höchste Sicherheitsaspekte<br />
zu gewährleisten, bieten die TS1120 und TS1130 Laufwerke<br />
die Möglichkeit, die Kassetten in verschlüsselter Form zu<br />
beschreiben (siehe auch unter Tape Encryption).<br />
Mit der Verfügbarkeit der TS3400 erweitert sich das <strong>IBM</strong><br />
LibraryPortfolio in der Weise, dass kleine bis ganz große<br />
Lösungen sowohl mit TS1120 und TS1130 Technologie als<br />
auch mit LTOTechnologie ermöglicht werden.<br />
TS2900 Autoloader mit HD-Technologie (High Density)<br />
<strong>IBM</strong> kündigt im August 2008 (zusammen mit der HDFrame<br />
Ankündigung der TS3500) eine neue LibraryEinstiegslösung<br />
TS2900 an, die Kapazitäten von 3,6 TB bis 7,2 TB (native)<br />
bietet und mit einem halbhohen LTO3Laufwerk oder einem<br />
halbhohen LTO4Laufwerk ausgestattet werden kann. Die<br />
älteren LTOTechnologien LTO1 und LTO2 sind in dieser Einstiegslösung<br />
nicht unterstützt.<br />
Der neue Autoloader steht seit September 2008 für den Einstiegsbereich<br />
zur Verfügung. Er hat nur eine Bauhöhe von<br />
1U und sieht damit fast wie eine dünne „Pizzascheibe“ aus.<br />
Wegen dieser geringen Bauhöhe sind nur LTOLaufwerke in<br />
halber Bauhöhe integrierbar. Die TS2900 lässt sich mit<br />
einem Laufwerk HH LTO 4 SAS oder einem HH LTO 3 SAS<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
145
146<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
konfigurieren und bietet Platz für bis zu neun LTOKassetten,<br />
die in einem austauschbaren Magazin dem Autoloader zur<br />
Verfügung gestellt werden. Ein Slot des Magazins dient als<br />
I/OStation. Trotz der kleinen Baugröße bietet der Autoloader<br />
beträchtliche Kapazitäten. Mit LTO4 erreicht man bis zu<br />
14,4 TB (mit 2:1 Kompression). Diese kleine MiniLibrary<br />
bietet direkten Zugriff auf jede Kassette und kann über das<br />
Web administriert werden.<br />
Die TS2900 MiniLibrary ist eine geniale Konstruktion auf<br />
kleinstem Raum, weil man in der Konstruktion von 1U Höhe<br />
ein halbhohes LTO3 oder LTO4Laufwerk untergebracht<br />
hat, ein Greifersystem, das direkten Zugriff auf alle neun<br />
Kassetten im Magazin hat, Netzteil, die ganze Elektronik<br />
einschließlich des Gebläses sowie ein herausnehmbares<br />
Magazin mit zehn KassettenStellplätzen, von denen nur<br />
neun Stellplätze mit Kassetten belegt werden können.<br />
Auf dieser niedrigen Bauhöhe neun Kassetten unterzubringen<br />
und die im direkten Zugriff des Greifers zu haben, ist nur<br />
durch die neue patentierte HD-Technologie (High Density)<br />
von <strong>IBM</strong> möglich.<br />
Das Magazin, das herausgenommen werden kann, ist mit<br />
dieser HDTechnik ausgestattet. Es fasst eigentlich zehn<br />
Kassetten, immer zwei in fünf aneinanderliegenden Reihen<br />
von jeweils zwei Kassetten und darf nur mit neun Kassetten<br />
bestückt werden – damit ist ein Stellplatz im Magazin immer<br />
frei und wird als ‘Cartride Caching’Slot eingesetzt.<br />
Links auf dem Bild ist das Greifersystem abgebildet, das auf<br />
dem rechten Bild vorne hin und herfährt. Muss nun ein<br />
Zugriff auf eine Kassette erfolgen, die in einem der fünf<br />
Schächte hinten abgelegt ist, nimmt der Roboter die erste<br />
Kassette heraus und stellt sie in dem Schacht ab, wo nur<br />
eine Kassette liegt! Die dahinterliegende Kassette rutscht<br />
automatisch einen Stellpatz vor und wird dann in einem<br />
zweiten Schritt vom Roboter geholt und dann zum Laufwerk<br />
gebracht, das sich ganz rechts vom Magazin befindet.<br />
Damit ist der Greifer immer in der Lage, jede Kassette auf<br />
Anforderung zum Laufwerk zu bringen. Einfach faszinierend,<br />
wie sich mit Ideen ganz neue Dinge umsetzen lassen!<br />
Unten stehende Grafik zeigt im Überblick das komplette<br />
LibraryAngebot der <strong>IBM</strong> im Jahr 2009/ 2010, von der Mini<br />
Library TS2900 bis zur High End Library TS3500. TS2900<br />
und TS3400 sind <strong>IBM</strong> Eigenentwicklungen und werden von<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
der Firma NEC als OEMProdukt für <strong>IBM</strong> produziert. Die Einstiegslösungen<br />
TS3100 und TS3200 kommen von der Firma<br />
BDT und werden als <strong>IBM</strong> LogoProdukte vertrieben. Als<br />
Midrange Library für LTOLaufwerke hat die <strong>IBM</strong> die TS3310<br />
im Portfolio, eine Library, die von Quantum/Adic gebaut wird<br />
und per OEM als <strong>IBM</strong> LogoProdukt vetrieben wird. Quantum<br />
selbst vertreibt diese Library als Scalar 500i auch<br />
selbst. Der Produktunterschied liegt darin, dass die <strong>IBM</strong><br />
TS3310 ‘End to End’ Path Failover unterstützt. Im HighEnd<br />
Bereich verwendet die <strong>IBM</strong> die TS3500, die <strong>IBM</strong> selbst produziert<br />
und konstant weiterentwickelt. Die TS3500 ist derzeit<br />
die schnellste Library auf dem Markt und bietet viele Alleinstellungsmerkmale<br />
und Vorteile gegenüber vergleichbaren<br />
Libraries. Das angebotene LibraryPortfolio ist für einen Hersteller/Anbieter<br />
einmalig und bietet Tape Automation für alle<br />
Anforderungen.<br />
File Virtualisierung und File Area Networks (FAN)<br />
Global Parallel File <strong>System</strong> (GPFS) und Scale Out File Services<br />
(SOFS)<br />
Unter Verwendung von erprobten <strong>IBM</strong> Baugruppen wie GPFS,<br />
BladeCenter und <strong>Storage</strong> stellte <strong>IBM</strong> im November 2007 ein<br />
hochskalierbares und hochperformantes Dateisystem mit<br />
integrierten ILMFunktionalitäten vor. Das <strong>System</strong> ist in der<br />
Lage, linear mit den Anforderungen an Speicherplatz und<br />
Durchsatz zu wachsen, und bietet neben extremer Hochverfügbarkeit<br />
eine einfache Administrierbarkeit. Im Frühjahr<br />
2010 kommt als Lösungsnachfolger von SOFS die <strong>IBM</strong><br />
SPSCLösung zur Anwendung. SPSC steht für Smart Private<br />
<strong>Storage</strong> Cloud.<br />
<strong>IBM</strong> SPSC – Smart Private <strong>Storage</strong> Cloud (vormals SOFS Scale<br />
Out File Services)<br />
Lösungsüberblick<br />
Die <strong>IBM</strong> SPSCLösung wurde entwickelt, um einfach und<br />
performant unstrukturierte Daten in Kundenumgebungen zur<br />
Verfügung zu stellen und bekannte Engpässe (Administration,<br />
Wachstum, Durchsatz, z.B bei WebAnwendungen) in<br />
aktuellen Network Attached <strong>Storage</strong>Lösungen – kurz NAS –<br />
zu beseitigen.<br />
Als Basis der <strong>IBM</strong> SPSCLösung dienen erprobte <strong>IBM</strong> HardwareKomponenten<br />
– <strong>IBM</strong> Bladecenter mit <strong>IBM</strong> <strong>Storage</strong><br />
Produkten – und das <strong>IBM</strong> General Parallel File <strong>System</strong> – kurz<br />
GPFS, das seit 1996 in HighPerformanceComputing <br />
Umgebungen sehr erfolgreich eingesetzt wird. <strong>IBM</strong> GPFS<br />
stellt eine stabile GridPlattform mit erprobten Skalierungsmöglichkeiten<br />
und integrierten Hochverfügbarkeitsfunktionen<br />
zur Verfügung.<br />
Durch Erweiterungen mit bewährten Bausteinen (Redhat<br />
Linux, Samba) verfügt SPSC über eine hochmoderne und<br />
eine offene <strong>System</strong>plattform. Dieses Gridbasierte Lösungskonzept<br />
stellt eine stabile ScaleOutPlattform für zukünftige<br />
<strong>Storage</strong>Anforderungen zur Verfügung. Durch Fokussierung<br />
der SPSCEntwicklung auf eine optimierte Betriebsführung<br />
und reduzierte Komplexitätsanforderungen integriert <strong>IBM</strong><br />
bereits im SPSCStandard viele Funktionalitäten und unterstützt<br />
diese mit Prozessen. Diese Funktionalitäten beinhalten<br />
Trendanalysen, Datenmigrationsprozesse und Information<br />
Lifecycle Management Prozesse.<br />
Ebenso wie die in der <strong>IBM</strong> SPSCLösung integrierten<br />
ManagementFunktionalitäten wie Monitoring, Administration<br />
und Operation erlauben Schnittstellen eine einfache Integration<br />
in die ITÜberwachung und garantieren geringe Administrationsaufwände.<br />
Zur Steigerung der Backup/Restore<br />
Zeiten erfolgte eine Integration von <strong>IBM</strong> Tivoli <strong>Storage</strong><br />
Manager – kurz TSM – in die Lösung. Unter Verwendung<br />
der SPSCMechanismen reduzieren sich die ScanZeiten<br />
erheblich, Gleiches gilt für den Restore.<br />
<strong>IBM</strong> SPSC bietet:<br />
einen globalen Namensbereich für alle Verzeichnisse<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
(File-Virtualisierung)<br />
einfachste Betriebsführung und Administration<br />
Hochverfügbarkeitsmechanismen eines Clusters mit Grid-<br />
Mechanismen<br />
dynamische Erweiterung/Reduzierung ohne Betriebsunterbrechung<br />
integrierte Information Lifecycle Funktionalitäten mit automatisierten<br />
Regeln auf File-Ebene, in Kombination mit TSM<br />
HSM eine Integration bis auf Band<br />
flexible Kopplung von Anwendungsservern durch CIFS,<br />
NFS, GPFS Cross Cluster Mount<br />
sehr große Speichervolumen in einem <strong>System</strong> (>10 Peta-<br />
Byte)<br />
integrierte Datenmigrationsmechanismen<br />
147
148<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
Lösungskomponenten<br />
Im Bild ‘SPSCLösungskomponenten’ wird der schematische<br />
Aufbau der Lösung im Gesamtüberblick dargestellt. Die<br />
Bausteine HSM, TSM sind hierbei Optionen, die auf Wunsch<br />
in die Lösung integriert werden können. Die SPSCLösung<br />
besteht immer aus <strong>IBM</strong> Komponenten und Erweiterungen<br />
von GNUKomponenten.<br />
<strong>IBM</strong> Lösungskomponenten:<br />
•<br />
•<br />
•<br />
•<br />
<strong>IBM</strong> Hardware (BladeCenter, <strong>Storage</strong>)<br />
<strong>IBM</strong> Software (GPFS, TSM, HSM, SPSC Lizenzmaterial)<br />
inklusive Subscribtion<br />
Zusätzliche SW – Redhat Linux, CIFS, Samba ..<br />
inklusive Subscribtion, soweit nötig<br />
<strong>IBM</strong> Implementierungsservice<br />
<strong>IBM</strong> Server und <strong>Storage</strong>-Hardware<br />
Basierend auf <strong>IBM</strong> HWBausteinen wird für jede Anforderungen<br />
ein <strong>System</strong> zusammengestellt. Die Konfiguration<br />
wird bestimmt aus der benötigten Leistung (Durchsatzanforderungen,<br />
Speicherbedarf, Verfügbarkeits und Erweiterungsanforderungen).<br />
Durch Nutzung des <strong>IBM</strong> SAN Volume<br />
Controllers besteht die Option, vorhandene Plattensysteme<br />
anderer Hersteller zu integrieren (Investitionsschutz) und die<br />
Vorteile einer Blockvirtualisierung zu nutzen.<br />
<strong>IBM</strong> Software<br />
GPFS bildet und stellt die Laufzeitumgebung der Lösung<br />
bereit. Optional kann die Lösung mit TSM und/oder um effiziente<br />
Backup und RecoveryMechanismen und/oder<br />
hierarchisches SpeicherManagement erweitert werden.<br />
<strong>IBM</strong> Implementation Service<br />
Mit dem <strong>IBM</strong> Implementation Service wird die SPSCLösung<br />
in bestehende ITUmgebungen integriert:<br />
Konfigurations- und Anbindungsplanung<br />
Installation aller <strong>IBM</strong> HW -und SW-Komponenten<br />
In Vertretung die Installation der Open-Source-Produkte<br />
Inbetriebnahme der SPSC und Unterstützung bei<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
Einbindung in die IT-Infrastruktur<br />
Überführung der SPSC-Lösung an das Operating Team<br />
Dokumentation der Implementierung<br />
Projektleitung<br />
<strong>IBM</strong> Basis Support Service<br />
Der Service beinhaltet Solutionorientierten Support mit<br />
zentraler Call Entry für alle Fragen und Probleme mit der<br />
SPSCLösung. Diese SupportStruktur beinhaltet die Problemlösung<br />
der OpenSourceKomponenten und stellt höchste<br />
Verfügbarkeit der Lösung sicher.<br />
•<br />
•<br />
•<br />
•<br />
Zentrales Customer Care Center für Fehlermeldung<br />
Bereitstellung von Informationen zu Fehlerkorrekturen,<br />
Programmkorrekturen für bekannte Fehler<br />
Updates des SPSC-Codes und der zugehörigen<br />
Dokumentation<br />
Bereitstellung von Unterstützung für das aktuelle und das<br />
vorhergehende Release des SPSC-Codes<br />
<strong>IBM</strong> Premium Service (beinhaltet Basis Support Service)<br />
Der Premium Service erweitert den BasisSupport mit der<br />
Übernahme von BasisBetriebsaufgaben wie Füllstandsüberwachung,<br />
Change und aktive Problembeseitigung und<br />
Pflege des <strong>System</strong>s mit SWUpdates, Optimierungen und<br />
technischer Administation der Lösung.
Der <strong>IBM</strong> SPSC Premium Service unterstützt bei den<br />
Betriebsleistungen auf Basis 7 Tage x 24 Stunden und beinhaltet<br />
folgende Tätigkeiten der <strong>IBM</strong>:<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
Zentrales Customer Care Center für alle Kundenanfragen<br />
Regelmäßige Überwachung der Lösung und aktives Operating<br />
Bereitstellung von Patches/Updates und Einspielen in die<br />
SPSC-Umgebung nach Absprache mit dem Kunden<br />
Lösungsunterstützung bei Problemen (Problem Ownership<br />
inklusive der Einbindung notwendiger Funktionen,<br />
z. B. HW-Maintenance)<br />
Regelmäßige Betreuung zur Betriebsoptimierung und<br />
Nutzung<br />
<strong>IBM</strong> Projektverantwortliche für alle Betriebsanfragen<br />
Regelmäßiger Statusreport (Nutzungskenngrößen,<br />
Auslastung, Durchsatz)<br />
Optimierung der SPSC-Lösung auf Basis der Betriebserfahrungen<br />
Planung von Änderungen (neue Kundenprojekte einführen,<br />
Leistungsparameter)<br />
Strategische Weiterentwicklung der Lösung für geplante<br />
Projekte<br />
SPSC-Standard-Funktionalitäten<br />
SPSC stellt eine skalierbare Plattform für alle Anforderungen<br />
von Fileservices zur Verfügung. Durch den sehr modularen<br />
Aufbau passt sich die SPSCLösung leicht den Bedürfnissen<br />
und Anforderungen an. Veränderungen an der Konfiguration<br />
und <strong>System</strong>komponenten können in den meisten Fällen im<br />
OnlineBetrieb erfolgen.<br />
Globaler Namensbereich für alle Verzeichnisse<br />
Durch Verwendung des GPFSFilesystems ermöglicht SPSC<br />
die Repräsentation eines transparenten Filesystems innerhalb<br />
der Lösung (FilesystemVirtualisierung).<br />
Dieser Ansatz erlaubt es, Daten in unterschiedlichen Speicherklassen<br />
zu speichern, ohne ihre Repräsentation zum<br />
Benutzer zu verändern. Hierbei ist es unerheblich, ob dies<br />
ein SPSCCluster ist oder mehrere SPSCCluster zusammengeschaltet<br />
werden.<br />
Hochverfügbarkeitsmechanismen eines Grids<br />
Ein SPSCCluster kann aus bis zu 26 Blades bestehen mit<br />
einem zusätzlichen Quorum Server. Der Quorum Server<br />
erlaubt eine automatisierte Umschaltung bei Ausfall/Nichtverfügbarkeit<br />
eines Clusterteils.<br />
Die Basis hierfür bildet die Aufsplittung eines SPSCClusters<br />
in zwei BladeCenter in zwei Rechenzentren (< 20 km Entfernung).<br />
In diesem Clusteraufbau sind alle Knoten aktiv und<br />
bedienen ankommende Anfragen. Bei Ausfall eines Rechenzentrums<br />
übernimmt der verbleibende Clusterteil die<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
149
150<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
Gesamtmenge der Anfragen und erhält den Service für den<br />
Benutzer. Diese Mechanismen finden bei der Spiegelung<br />
der Filesysteme ebenfalls Anwendung.<br />
Spiegelmechanismen auf Filesystemebene<br />
Bei der Spiegelung von Dateien zur Erhöhung der Datensicherheit<br />
können, basierend auf DateiShares, Spiegelungen<br />
mittels Policies eingerichtet werden. Der Spiegel kann hierbei<br />
jeweils (und/oder) im gleichen Share, in einem anderen<br />
Share oder einem anderen Cluster definiert werden.<br />
In SPSC erfolgt die Spiegelung der definierten Dateien<br />
durch das parallele Schreiben der Dateien unter Kontrolle<br />
von GPFS. Diese erlaubt eine parallele Verarbeitung der<br />
Schreibvorgänge, speziell bei mehrfachen Spiegeln in mehreren<br />
Clustern. Hierbei ist einen Kopplung der Plattensysteme<br />
nicht notwendig.<br />
Dynamische Erweiterung ohne Betriebsunterbrechung<br />
Die SPSCLösung erlaubt die Erweiterung/Verkleinerung der<br />
Lösung unter vollem OnlineBetrieb.<br />
Veränderungen an der SPSCLösung erfolgen in voneinander<br />
unabhängigen Schritten. Die Verteilung der Daten liegt ausschließlich<br />
in Verantwortung von SPSC.<br />
Erweiterung von Speicherkapazität (Beispiel):<br />
1. Basiskonfiguration der neuen <strong>Storage</strong>-Komponenten<br />
(LUNs)<br />
2. Anbindung der <strong>Storage</strong>-Komponenten an das<br />
BladeCenter<br />
3. Übergabe der Resourcen an SPSC in Form zusätzlicher<br />
LUNs<br />
4. Mit dem SPSC-Administrationsinterface werden die LUNs<br />
Shares zugeordnet.<br />
5. SPSC übernimmt automatisch das Striping der Daten über<br />
den erweiterten Share.<br />
SPSC integrierte ILM-Funktionalitäten<br />
Mit den integrierten ILMFunktionalitäten (Information Lifecycle<br />
Management) bietet <strong>IBM</strong> SPSC eine Plattform zur effizienten<br />
und automatisierten Handhabung von unstrukturierten<br />
Daten. Durch die DefinitionRegeln auf Fileebene können<br />
automatisiert Verlagerungsprozesse auf unterschiedliche<br />
Speicherklassen angestoßen werden und in Kombination mit<br />
<strong>IBM</strong> TSM (Tivoli <strong>Storage</strong> Manager) und HSM (Hierarchical<br />
<strong>Storage</strong> Manager) erfolgt die Auslagerung bis auf Bänder,<br />
wobei die Dateieinträge transparent im Filesystem für den<br />
Benutzer dargestellt werden.<br />
Wie bereits beschrieben, können in SPSC mehrere unter<br />
schiedliche Speicherklassen definiert werden.<br />
Zur Optimierung der Nutzung der Speicherklassen verfügt<br />
SPSC bereits in Basisfunktionalität über ILMErweiterungen<br />
(Information Lifecycle). Hierbei können auf Grundlage von<br />
Policies auf ShareEbene definiert werden, auf welchem<br />
Type von Plattenspeicher Daten vorgehalten werden sollen.<br />
Optional kann eine Migration bis auf Band erfolgen:<br />
Definition von Policies für Dateien auf Share-Ebene<br />
Automatische Migration der Dateien nach den definierten<br />
Policies<br />
Transparenter Zugriff für den Benutzer (inklusive der Bandnutzung)<br />
Optional: Bei Einsatz von TSM HSM – Tivoli <strong>Storage</strong> Manager<br />
Hierarchical <strong>Storage</strong> Manager – kann bei der Migration ein<br />
Bandlaufwerk integriert werden.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
•<br />
•<br />
•<br />
•
Flexible Anbindung von Anwendungssystemen<br />
Zusätzlich zu den Protokollen CIFS/NFS steht eine hochperformante<br />
Anbindung von LinuxAnwendungsservern mittels<br />
GPFS Cross Cluster Mount zur Verfügung. Die Kopplung<br />
erfolgt hierbei mittels des <strong>IBM</strong> GPFSProtokolls, das in<br />
HPCUmgebungen sehr erfolgreich eingesetzt wird. Zur<br />
Optimierung des Datendurchsatzes unterstützt <strong>IBM</strong> SPSC<br />
die direkte Kopplung von GPFSbasierten Anwendungsservern.<br />
Diese Kopplung erlaubt durch das im GPFS implementierte<br />
Protokoll einen maximalen Datendurchsatz.<br />
Integrierte Datenmigrationsmechanismen<br />
Basierend auf den beschriebenen Verfahren für die Online<br />
Erweiterung vom Speicher kann sehr einfach und effizient<br />
eine Datemigration erfolgen. Die Datenmigration kann hierbei<br />
ohne zusätzliche Werkzeuge bei minimalen <strong>System</strong>belastungen<br />
durchgeführt werden.<br />
Die hierzu notwendigen Schritte sind:<br />
1. Bereitstellung der LUNs im SPSC<br />
2. Einrichten der Migrationsbeziehung zwischen den<br />
abzulösenden Speicherbereichen<br />
3. Migration der Daten auf die neuen LUNs<br />
4. Auflösen der Migrationsbeziehung im Speicherbereich<br />
5. Herausnahme der alten LUNs aus dem SPSC-Cluster<br />
Erweiterungspotenziale für SPSC<br />
Mit SPSC steht eine skalierbare NASPlattform zur Verfügung.<br />
Die Skalierung kann hierbei unter mehreren<br />
Geschichtspunkten erfolgen:<br />
•<br />
•<br />
•<br />
•<br />
Durchsatz bei Zugriff auf die Dateien: zusätzliche Blades<br />
Volumen: zusätzlicher Speicher<br />
Fehlbedienung/Datenintegrität: asynchroner Spiegel<br />
Höhere Verfügbarkeit: SPSC Cross Cluster Mount<br />
Alle diese Erweiterungen stehen innerhalb der Lösung zur<br />
Verfügung, egal mit welcher Variante und in welcher Umgebung<br />
gestartet wird.<br />
ILM-Prozesse mit integrierter Auslagerung auf Bänder<br />
Da Filer meist mit sehr viel Datenvolumen von inaktiven<br />
Dateien gefüllt sind (60–70% der Daten, da nicht mehr<br />
be nötigt), können diese kostengünstig auf Bänder ausgelagert<br />
werden. Auf Basis von Policies erfolgt automatisiert die<br />
Auslagerung über Speicherklassen bis auf Bandkassetten.<br />
Die Verschiebung erfolgt zunächst innerhalb des Filers auf<br />
unterschiedliche Plattentypen<br />
Die Policies wirken auf Fileebene<br />
Nach Regeln werden die Daten automatisiert an TSM-HSM<br />
übergeben und für den Windows-Benutzer als Offline-<br />
Datei markiert.<br />
Bei Öffnen der Datei wird diese automatisiert aus der<br />
TSM-HSM-Umgebung wiederhergestellt.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
•<br />
•<br />
•<br />
•<br />
Optionale Erweiterungen<br />
Asynchroner Spiegel<br />
Mit dem asynchronen Spiegel können zeitversetzt Daten<br />
online kopiert werden, um gegen ungewollte Datenlöschung<br />
oder im Katastrophenfall einen zusätzlichen Datenbestand<br />
zu haben. Hierbei können kurzfristig Daten zurückgeholt<br />
werden (innerhalb des Synchronisationszeitraums oder im<br />
KFall als Betrieb des asynchronen Clusters als Notsystem).<br />
Der asynchrone Spiegel ist hierbei ein SPSCCluster, der im<br />
Normalbetrieb als Teil des Produktionsclusters läuft. Die<br />
Spiegelungsregeln werden wie durchgängig in SPSC per<br />
Policy definiert.<br />
Weitstreckenkopplung von SPSC-Clustern durch Grid-Prozesse<br />
Mit SPSC stehen mehrere Varianten einer Kopplung von<br />
unternehmensweiten Lösungen zur Verfügung.<br />
•<br />
•<br />
Kopplung von zwei eigenständigen SPSC-Clustern unter<br />
einem Global Namespace. Jeder der Cluster hält einen Teil<br />
der Benutzerdaten.<br />
Alternativ kann ein SPSC-Cluster als asynchrone Spiegellokation<br />
genutzt werden, in der mit Zeitversatz die<br />
Betriebsdaten bereitstehen. Bei Bedarf kann diese Lokation<br />
als Notfalllokation aktiviert werden.<br />
151
152<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
Encryption für Tape<br />
Im August 2006 kündigte <strong>IBM</strong> die Verschlüsselungstechnik<br />
und ein dazugehöriges Schlüsselmanagement für die<br />
TS1120 Bandlaufwerke (Jaguar 2) an. Damit können 3592<br />
Kassetten so beschrieben werden, dass nur die Instanz sie<br />
wieder auslesen kann, die den dazugehörigen Encryption<br />
Key kennt und hat. Missbrauch von Daten, die sich auf den<br />
Kassetten befinden, kann somit ausgeschlossen werden.<br />
Fallen Kassetten aus irgendwelchen Gründen in falsche<br />
Hände, können sie nicht ausgelesen werden.<br />
EncryptionMöglichkeiten auf Tape gab es bisher in unter<br />
schiedlichen Ausprägungen. Mit speziell entwickelter<br />
EncryptionSoftware auf einem Server, mit speziell entwickelten<br />
EncryptionAnwendungen oder externen Verschlüsselungsgeräten<br />
konnte auf Tape verschlüsselt aufgezeichnet<br />
werden. Das Bandlaufwerk selbst hatte mit der eigentlichen<br />
Encryption nichts zu tun. Solche Lösungen konnten bisher<br />
immer nur in Teilbereichen zur Anwendung kommen. Eine<br />
Implementierung auf unternehmensweiter Basis, unabhängig<br />
von den unterschiedlichen BetriebssystemPlattformen<br />
und auch über Unternehmensgrenzen hinaus, war bisher<br />
nicht sinnvoll gestaltbar. Hinzu kommen noch die vielen Verschlüsselungsarten<br />
wie z.B. Mars, RC5, Serpent, Twofish,<br />
DES oder AES, um nur einige zu nennen, die das Ganze<br />
entsprechend komplex gestalten. Um Verschlüsselungen<br />
vorzunehmen, wird zum einen ein Verschlüsselungsalgorithmus<br />
benötigt und zum anderen ein sogenannter Datenschlüssel<br />
(Data Key), der die verschlüsselten Daten vor<br />
unautorisiertem Zugriff absichert. Nur über den Datenschlüssel<br />
können die verschlüsselten Daten wieder entschlüsselt<br />
werden. Zum besseren Verständnis werden im<br />
Folgenden die verschiedenen Verschlüsselungsmethoden<br />
beschrieben.<br />
Symmetrische Verschlüsselung: Um das Ausspionieren<br />
von versendeten Daten durch eine dritte Partei zu verhindern,<br />
werden im Allgemeinen kryptografische Verfahren<br />
angewendet. Bei der symmetrischen Verschlüsselung werden<br />
die Daten mittels eines geheimen Schlüssels ver bzw.<br />
entschlüsselt. Der Schlüssel muss dabei sowohl dem Sender<br />
als auch dem Empfänger bekannt sein und zu diesem<br />
Zweck vorher persönlich ausgetauscht werden.<br />
Beispiele für bekannte symmetrische Verschlüsselungsalgorithmen<br />
sind der Data Encryption Standard (DES), der von <strong>IBM</strong><br />
Anfang der 70erJahre entwickelt wurde und mit einer<br />
Schlüssellänge von 56 Bit arbeitet, sowie der International<br />
Data Encryption Algorithm (IDEA), der von den Schweizern<br />
Lai und Massey entwickelt und 1990 veröffentlicht wurde<br />
und mit einer Schlüssellänge von 128 Bit deutlich sicherer<br />
ist als der DES. Der generelle Nachteil dieses Algorithmus ist<br />
der direkte Austausch der geheimen Schlüssel, was seine<br />
Anwendung in einer KundeHändlerBeziehung erschwert.<br />
Der Vorteil besteht in der relativ geringen benötigten<br />
Rechen leistung.<br />
Asymmetrische Verschlüsselung: Ein weiteres Verschlüsselungsverfahren<br />
ist die sogenannte asymmetrische Verschlüsselung.<br />
Sie basiert auf der Verwendung eines zusammengehörenden<br />
Schlüsselpaares, wobei ein Schlüssel zur<br />
Ver und einer zur Entschlüsselung genutzt wird. Beim<br />
PublicKeyVerfahren wird nun einer der Schlüssel veröffentlicht<br />
und kann von jedem Sender dazu genutzt werden, eine<br />
Nachricht an den Empfänger zu verschlüsseln. Nur der<br />
Empfänger, der im Besitz des zweiten, privaten Schlüssels<br />
ist, kann die Nachricht dann entschlüsseln.<br />
Ein Vertreter der asymmetrischen VerschlüsselungsAlgorithmen<br />
ist der RSAAlgorithmus (RSA Data Security Inc.),<br />
benannt nach seinen Entwicklern Ron Rivest, Adi Shamir,<br />
Leonard Adleman, der in den USA 1977 entwickelt und<br />
patentiert wurde und für den Export in jedoch nur begrenzter<br />
Verschlüsselungstiefe (40 Bit) zur Verfügung steht.<br />
Die asymmetrische Verschlüsselung kann auch genutzt wer<br />
den, um das Problem der Authentifizierung zu lösen. Zu diesem<br />
Zweck werden die öffentlichen Schlüssel von Sender<br />
und Empfänger gegenseitig bekannt gemacht. Der Sender<br />
verschlüsselt die Nachricht zunächst mit seinem eigenen,<br />
privaten und dann mit dem öffentlichen Schlüssel des Empfängers.<br />
Nach Erhalt der Nachricht entschlüsselt der Empfänger<br />
die Nachricht zunächst mit seinem privaten und<br />
dann mit dem öffentlichen Schlüssel des Senders. Dieser<br />
letzte Schritt ist jedoch nur dann erfolgreich, wenn die<br />
Nachricht wirklich von dem bezeichneten Sender kam, da<br />
andernfalls der verwendete öffentliche Schlüssel nicht passend<br />
ist.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Hybride Verfahren: Der Nachteil der asymmetrischen Ver<br />
schlüsselung ist der hohe Rechenaufwand. Deswegen wird<br />
oftmals eine Kombination aus symmetrischer und asymmetrischer<br />
Verschlüsselung genutzt. Dabei wird eine Nachricht<br />
durch den Sender zunächst mit einem speziellen geheimen<br />
Schlüssel (Session Key) symmetrisch verschlüsselt.<br />
Anschließend wird dieser Schlüssel mit dem öffentlichen<br />
Schlüssel des Empfängers asymmetrisch verschlüsselt und<br />
übertragen. Der Empfänger kann nun asymmetrisch mit seinem<br />
privaten Schlüssel den Session Key und somit die<br />
eigentliche Nachricht symmetrisch entschlüsseln. Da die<br />
asymmetrische Verschlüsselung nur für die Verschlüsselung<br />
des symmetrischen Schlüssels verwendet wird, bleibt der<br />
Rechenaufwand bei der asymmetrischen Verschlüsselung<br />
relativ gering.<br />
<strong>IBM</strong> ist die erste Firma, die für Bandlaufwerke eine direkte<br />
Verschlüsselungstechnik anbietet. Um mit den TS1120 Laufwerken<br />
mit der Option Encryption arbeiten zu können, muss<br />
auf installierten TS1120 Laufwerken ein HardwareUpgrade<br />
und ein MikrocodeUpdate durchgeführt werden. TS1120<br />
Laufwerke, die seit September 2006 ausgeliefert werden,<br />
sind standardmäßig mit der Encryptionfähigkeit ausgestattet.<br />
<strong>IBM</strong> entschied sich für die AESVerschlüsselung (Advanced<br />
Encryption Standard), die mit 128, 192 und 256 Bit<br />
Schlüssellänge zur Verfügung steht und den RijndaelAlgorithmus<br />
als symmetrisches Kryptografieverfahren verwendet.<br />
AES ist der Nachfolger von DES (Data Encryption Standard<br />
mit 56 Bit Schlüssellänge). AES ist anerkannt von der US<br />
Behörde NIST (National Institute of Standards and Technology)<br />
und vom USHandelsministerium und soll anerkanntermaßen<br />
nicht ‘knackbar’ für die kommenden Jahre sein. Das<br />
Bandlaufwerk TS1120 arbeitet mit dem sicheren AES256<br />
BitVerschlüsselungsalgorithmus. Damit ist zum ersten Mal<br />
die Möglichkeit gegeben, dass das Laufwerk selbst die Verschlüsselung<br />
durchführt.<br />
Die Verschlüsselungsmethode ist die eine Seite. Genauso<br />
wichtig sind die Datenschlüssel, die vor unautorisiertem<br />
Zugriff schützen und über die sich die verschlüsselten<br />
Daten wieder entschlüsseln lassen. Im MainframeUmfeld,<br />
wo schon seit Jahren Encryption mit entsprechenden<br />
KryptoProzessoren eingesetzt wird, bildet das Herzstück für<br />
die Datenschlüsselverwaltung ein EKM Encryption Key<br />
Manager im z/OSBetriebssystem. Der im z/OS eingesetzte<br />
EKM bietet eine absolut nicht manipulierbare und hundertprozentig<br />
sichere zentrale Datenschlüsselverwaltung. Dieser<br />
EKM wurde nun auf die JAVAPlattform portiert und steht so<br />
für alle Betriebssystemplattformen zur Verfügung. Der neue<br />
EKM liefert die Keys zum TS1120 Laufwerk, kann auf unterschiedlichsten<br />
<strong>System</strong>plattformen laufen und unterstützt<br />
dabei zentralisiertes Encryption Key Management, das<br />
unternehmensweit einsetzbar ist.<br />
Der EKM steht für die Betriebssysteme z/OS 1.6 oder 1.7,<br />
AIX 5.2 oder später, I5/OS 5.2 oder später, HPUX 11.0, 11i,<br />
und 11.23Pl, Sun Solaris 8, 9 und 10, Linux – <strong>System</strong> z,<br />
<strong>System</strong> p und Intel, Red Hat Enterprise Linux 4 (REHL 4),<br />
SuSE Linux Enterprise Server 9 (SLES 9), Windows 2000<br />
und Windows 2003 zur Verfügung.<br />
Muss nun ein TS1120 Bandlaufwerk mit Encryption aufzeichnen,<br />
fordert das Laufwerk den Datenschlüssel vom<br />
EKM Encryption Key Manager an. Der EKM prüft dann, ob<br />
das Laufwerk zugelassen ist und im ‘Drive Table’ des EKM<br />
bekannt ist. Falls nicht, muss das Laufwerk über die Konfigurationsfile<br />
im Drive Table des EKM aufgenommen werden.<br />
Dann erstellt der EKM den angeforderten Datenschlüssel,<br />
der im Folgenden als ‘Data Key’ bezeichnet wird.<br />
Da die Datenschlüssel aus Sicherheitsgründen nicht unver<br />
schlüsselt über ein Netzwerk zum Bandlaufwerk übertragen<br />
werden können, arbeitet der EKM intern mit zwei verschiedenen<br />
Verschlüsselungsmethoden für den Datenschlüssel.<br />
Der eine Algorithmus ist der KEK Key Encryption Key, der<br />
ausschließlich im EKM läuft und mit dem nur der EKM etwas<br />
anzufangen weiß. Der andere Algorithmus ist der SK Session<br />
Key, der sowohl im EKM als auch im Bandlaufwerk zur<br />
Anwendung kommt. Ist zwischen EKM und Bandlaufwerk<br />
eine Session aufgebaut und wird der Data Key mit dem<br />
Session Key SK verschlüsselt und zum Bandlaufwerk übertragen,<br />
entschlüsselt das Bandlaufwerk wieder den originalen<br />
Data Key, um dann mit der AES256BitVerschlüsselung die<br />
Daten aufzuzeichnen. Bei jeder neu aufgebauten Session<br />
zwischen EKM und Bandlaufwerk kommt immer ein neuer<br />
SK Session Key zum Einsatz. Der mit dem SK verschlüsselte<br />
Data Key wird als SEDK (Session Encryption Data Key)<br />
bezeichnet. Neben dem SEDK überträgt der EKM aber auch<br />
den über den KEK (Key Encryption Key) verschlüsselten Data<br />
Key zum Laufwerk, der als EEDK (Externally Encryption<br />
Data Key) bezeichnet wird und mit dem das Laufwerk<br />
absolut nichts anfangen kann, weil ausschließlich der EKM<br />
den KEK kennt und anwenden kann. Das Laufwerk hat<br />
also keine Möglichkeit, den übertragenen EEDK zu<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
153
154<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
entschlüsseln, um an den eigentlichen Data Key zu gelangen.<br />
Das Laufwerk kann den Data Key ausschließlich über<br />
den übertragenen SEDK entschlüsseln. Hat das Laufwerk<br />
nun die verschlüsselte Aufzeichnung abgeschlossen, wird<br />
am Bandende in die Tape Volume Control Region der EEDK<br />
hinterlegt, mit dem das Bandlaufwerk nichts anzufangen<br />
weiß. Zusätzlich wird der EEDK auch im Memory Chip der<br />
Kassette gespeichert. Sollte nun unautorisiert diese Kassette<br />
auf einem Encryptionfähigen TS1120 Laufwerk ausgelesen<br />
werden, ist dies nicht möglich, weil das Laufwerk mit<br />
dem mitaufgezeichneten EEDK nichts anfangen kann. Ein<br />
nicht autorisiertes Auslesen ist nicht möglich.<br />
Zum Auslesen fordert das Laufwerk vom EKM wieder den<br />
Data Key an und überträgt den aufgezeichneten EEDK zum<br />
EKM. Der EKM sucht den zum EEDK zugehörigen KEK Key<br />
Encryption Key und entschlüsselt den EEDK. Der orginale<br />
Data Key steht also wieder zur Verfügung. Der Data Key<br />
wird nun wieder über einen neuen SK Session Key verschlüsselt<br />
und zum Laufwerk übertragen. Das Laufwerk<br />
erhält den neuen SEDK Session Encryption Data Key und<br />
entschlüsselt den SEDK, um den orginalen Data Key zu<br />
erhalten. Danach können die verschlüsselt aufgezeichneten<br />
Daten auf der Kassette entschlüsselt und ausgelesen werden.<br />
Es besteht also keine Möglichkeit, die verschlüsselten Daten<br />
ohne den originalen Data Key auszulesen. Die Raffinesse<br />
dieser Implementierung liegt in der Tatsache, dass das<br />
Laufwerk eine symmetrische Encryption über einen Data<br />
Key durchführt, während die darübergelegte KeyVerwaltung<br />
asynchron implementiert ist. Dabei kann der auf dem<br />
Tape verschlüsselt abgespeicherte Data Key (EEDK) nicht<br />
von TS1120 Laufwerken, sondern ausschließlich vom EKM<br />
(Encryption Key Manager) für die Wiederherstellung des originalen<br />
Data Keys verwendet werden. Das Laufwerk muss<br />
den abgespeicherten verschlüsselten Data Key zum EKM<br />
übertragen. Der EKM stellt den originalen Data Key wieder<br />
her und schickt ihn für das Laufwerk verständlich verschlüsselt<br />
(Session Key) zurück. Das Laufwerk ist nun in der Lage,<br />
den originalen Data Key herzustellen und damit die Daten<br />
entschlüsselt auszulesen. Die Kombination von synchroner<br />
und asynchroner Technik machen diese Verschlüsselung<br />
absolut ‘wasserdicht’.<br />
Werden Kassetten, die mit Verschlüsselung aufgezeichnet<br />
wurden, in eine andere Lokation transportiert, z.B. zu einem<br />
Geschäftspartner, müssen dort TS1120 Laufwerke mit<br />
Encryptionfähigkeit und ein EKM installiert sein. Will die<br />
Lokation nun die Daten auslesen, schickt ein TS1120 Laufwerk<br />
den auf der Kassette gespeicherten EEDK zum örtlichen<br />
EKM, der einen Private Key hat, um den auf der Kassette<br />
abgespeicherten EEDK zu entschlüsseln.<br />
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<br />
EEDKs mit zwei unterschiedlichen Private Keys abgespeichert<br />
werden. Der erste Key gehört zum EKM, der den Schlüssel<br />
erzeugt hat, und der zweite Key kann einem anderen EKM<br />
gehören, der aufgrund des dort verfügbaren Private Keys<br />
den zweiten EEDK in den orginalen Schlüssel umwandeln<br />
kann. Mit zwei Keys auf der Kassette zu arbeiten ist dann<br />
sinnvoll, wenn in verschlüsselter Form Datenträgeraustausch<br />
zwischen zwei unterschiedlichen Lokationen durchgeführt<br />
wird. Das Laufwerk schickt immer den ersten EEDK<br />
zum EKM. Kann der EKM damit nichts anfangen, wird automatisch<br />
der zweite EEDK zu dem vorhandenen EKM übertragen.<br />
Mit der Ankündigung der LTO4Laufwerke im April 2007<br />
wurde für LTO4 auch Encryption angekündigt. LTO4Lauf<br />
werke arbeiten wie TS1120 Laufwerke auch mit der AES<br />
256BitVerschlüsselungstechnik. Der Unterschied zu<br />
TS1120 liegt darin, dass keine verschlüsselten Schlüssel<br />
(EEDK) auf der LTO4Kassette abgespeichert werden, sondern<br />
nur der Key Identifier, also der Schlüsselanhänger. Die<br />
KeyVerwaltung und KeyAbspeicherung erfolgt über den<br />
EKM. Soll eine verschlüsselte Kassette ausgelesen werden,<br />
überträgt das LTO4Laufwerk den Identifier zum EKM, der<br />
dann in der Lage ist, den richtigen Originalschlüssel dem<br />
Identifier zuzuordnen.<br />
Der EKM wurde im Mai 2007 mit dem EKM Release 2 so<br />
erweitert, dass er sowohl das KeyHandling für TS1120,<br />
TS1130 als auch für LTO4 durchführen kann. Damit können<br />
beide Technologien mit demselben EKM gemanagt werden.<br />
Das neue TS1130 Bandlaufwerk, das als Nachfolger der<br />
TS1120 im September 2008 verfügbar wird, ist mit derselben<br />
Verschlüsselungstechnik ausgestattet. Die Bandkassetten<br />
bleiben gleich, d. h., das neue TS1130 Laufwerk verwendet<br />
dieselben Kassetten. Das Abspeichern der Keys auf<br />
den Kassetten ist identisch.<br />
TKLM – Tivoli Key Lifecycle Manager<br />
Im Frühjahr 2008 steht als neue Software zur Keyverwaltung<br />
der TKLM (Tivoli Key Lifecycle Manager) zur Verfügung, der<br />
denselben Funktionsumfang wie der EKM hat und darüber<br />
hinaus auch das KeyHandling für Encryption auf Platte<br />
(Disk) zur Verfügung stellt und eine einfach zu bedienende<br />
Oberfläche besitzt. Der TKLM kann als offizielles <strong>IBM</strong><br />
Programmpaket bezogen werden.<br />
<strong>IBM</strong> bietet drei EncryptionImplementierungsMöglichkeiten<br />
auf Tape an:<br />
Die Anwendung selektiert die Daten, die mit Encryption auf<br />
Band geschrieben werden müssen, und stellt die Keys<br />
dem TSM zur Verfügung. Der TSM Tivoli <strong>Storage</strong> Manager<br />
verwaltet dann als Backup-Server die Encryption-Key-<br />
Datenbank.<br />
Im Mainframe-Umfeld kann über <strong>System</strong> Utilities des<br />
DFSMS im z/OS-Betriebssystem über neue Data-Class-<br />
Parameter selektiert werden, was mit Encryption verarbeitet<br />
werden soll. Ähnlich können Policies für Encryption<br />
auch im ‘AIX Tape Device Driver’ eingerichtet werden. In<br />
beiden Fällen verwaltet der neue Enterprise Key Manager<br />
(EKM) die Encryption-Key-Datenbank.<br />
Die dritte Option geht über die Library selbst. Sowohl die<br />
3494 als auch die TS3500 Library etabliert entsprechende<br />
Policy-Regeln, welche ‘VolSers’ oder welche logischen<br />
Libraries mit Encryption verarbeitet werden sollen. Die<br />
Verwaltung der Encryption-Key-Datenbank wird durch<br />
den neuen Enterprise Key Manager (EKM) durchgeführt.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
•<br />
•<br />
•<br />
Alle drei Optionen lassen sehr flexible, unternehmensweite<br />
und über Unternehmensgrenzen hinausgehende Verschlüsselungslösungen<br />
auf Tape mit einem zentralen Key Management<br />
zu und sind einmalig in ihrer Lösungsform.<br />
Encryption auf Tape sichert die auf Bandkassetten<br />
geschriebenen Daten vor Missbrauch und bietet einen<br />
neuen Sicherheitsstandard auf Tape, der die geschriebenen<br />
Daten vor unautorisiertem Zugriff schützt.<br />
155
156<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
Archivierung<br />
Die Anforderungen an Archivierung haben sich in den letzten<br />
Jahren verändert. Neben der klassischen Aufbewahrung<br />
von Daten aufgrund von gesetzlichen oder firmeninternen<br />
Vorschriften kommen weitere Anforderungsprofile wie<br />
erhöhte Zugriffsgeschwindigkeit und eine automatische Auslagerung<br />
von nicht mehr operational genutzten Daten auf<br />
Archivsysteme dazu. Desweiteren sind heute Archivlösungen<br />
gefragt, die ein hierarchisches Speichermanagement<br />
be inhalten und damit die Möglichkeit bieten, archivierte Daten<br />
automatisch nach ILMRegulatorien (Information Lifecycle<br />
Management) auf unterschiedlichen Speichersystemen zu<br />
verwalten. Aufgrund der immmer größer werdenden Datenmengen<br />
im Archivierungsbereich sind heute sehr leistungsfähige<br />
und skalierbare Archivsysteme gefragt, die zudem<br />
die Anforderungen nach Hochverfügbarkeit und Datensicherheit<br />
gewährleisten müssen. Dies gilt sowohl für die<br />
Archivierung der klassischen Dokumenten bzw. Content<br />
Management<strong>System</strong>e als auch für Anwendungen auf<br />
FilesystemBasis. Moderne Archivlösungen müssen zudem<br />
die Migrationsanforderung hinsichtlich der Daten als auch<br />
des <strong>System</strong>s selbst erfüllen, wenn neue Technologien zur<br />
Verfügung stehen.<br />
<strong>IBM</strong> Information Archive (IIA)<br />
<strong>IBM</strong> kündigt im November 2009 das neue Archivierungssystem<br />
‘<strong>IBM</strong> Information Archive’, kurz IIA, als Nachfolger<br />
des bisherigen DR550<strong>System</strong>s an.<br />
Mit dem neuen <strong>System</strong> werden die veränderten bzw. erweiterten<br />
Anforderungen an Archivsysteme adressiert. IIA ist<br />
eine universelle Lösung zur Archivierung von strukturierten<br />
und unstrukturierten Daten, die sowohl die gesetzlichen Aufbewahrungsvorschriften<br />
erfüllt, als auch generell der vorschriftsfreien<br />
Datenhaltung im Langzeitbereich Rechnung<br />
trägt. Das <strong>System</strong> zeichnet sich dadurch aus, dass es eine<br />
hohe Flexibilität in der Datenspeicherung bietet, weil zu<br />
archivierende Anwendungen durch unterschiedliche standardisierte<br />
Zugriffsmethoden möglich werden. Die hohe<br />
Leistungsfähigkeit und Skalierbarkeit sind besondere<br />
Merkmale des <strong>System</strong>s.<br />
Architektur<br />
Das <strong>System</strong> besteht aus bis zu drei Rechnerknoten (in der<br />
IIATerminologie als ‘Collection’ bezeichnet), die intern mit<br />
den PlattenArrays durch ein FibreChannelNetz miteinander<br />
verbunden sind und sich gegenseitig durch das integrierte<br />
GPFS (Generell Parallel File <strong>System</strong>) Backup geben und<br />
damit eine hohe Verfügbarkeit gewährleisten. Per Knoten<br />
können Anwendungen zum einen via NASInterface durch<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
die NFS oder HTTPSchnittstellen oder über die klassische<br />
Schnittstelle SSAM <strong>System</strong> <strong>Storage</strong> Archive Manager (TSM<br />
API) angebunden werden. Zu einem späteren Zeitpunkt<br />
werden auch FTP und CIFS unterstützt werden. Die Knoten<br />
hinsichtlich der zu adressierenden Schnittstellen zu den<br />
Anwendungen sind frei wählbar. Dabei bieten beide Schnittstellen<br />
die Möglichkeit, andere Infrastrukturen wie z. B. Tape<br />
anzuschließen.<br />
Die Möglichkeit, mehrere Archivierungsinstanzen gleichzeitig<br />
innerhalb eines <strong>System</strong>s zu betreiben, erhöht die Leistungsfähigkeit<br />
des Gesamtsystems beträchtlich. Im Unterschied<br />
zur DR550 ist die Datenbank des SSAMServers<br />
DB2basierend (durch die Integration von TSM 6.1). Damit<br />
wird die Anzahl der zu speichernden Datenobjekte um den<br />
Faktor 3 pro Collection erhöht. Der SSAMServer sorgt für<br />
die Datenmigration auf angeschlossenen externen Speichern.<br />
Innerhalb einer Collection zur Fileanbindung (Knoten mit<br />
NASInterface) werden Daten, die auf externen <strong>Storage</strong> wie<br />
z. B. auf Tape ausgelagert werden sollen, durch den internen<br />
TSMServer mittels seiner HSMFunktionalität migriert.<br />
Das Management und die Administration des <strong>System</strong>s wird<br />
über eine einheitliche Bedieneroberfläche durchgeführt.<br />
Technischer Aufbau<br />
Die Rechnerknoten (GPFSKnoten) bestehen aus einem <strong>IBM</strong><br />
<strong>System</strong> x Server mit zwei quadcore Prozessoren, 24 GB<br />
Memory und einem LinuxBetriebssystem. Bis zu drei Knoten<br />
können innerhalb eines Clusters konfiguriert werden. Für<br />
das Management des <strong>System</strong>s wird ein <strong>IBM</strong> <strong>System</strong> x mit<br />
einem quadcore Prozessor und 4 GB Memory verwendet.<br />
Die PlattenArrays bestehen aus 1TBSATAPlatten und werden<br />
mit RAID6 an dualredundanten Active/ActivePlattensteuereinheiten<br />
betrieben. Jede Steuereinheit ist mit 2 GB<br />
Cache ausgestattet und bietet bis zu 2 x 4 Gbit FCPorts für<br />
die Serveranbindung und bis zu 2 x 4 Gbit FCPorts für die<br />
RemoteSpiegelung. Rechnerknoten und Plattensteuereinheiten<br />
sind durch ein 8 Gbit FCSAN auf Basis von 24Port<br />
Switchen miteinander verbunden, wobei der Betrieb am<br />
Anfang auf Basis von 4 Gb läuft. Jeder Plattenkontroller hat<br />
Zugriff auf jeden GPFSKnoten und umgekehrt. Die Maximalkonfiguration<br />
besteht aus zwei Gehäuseeinheiten und<br />
bildet eine Bruttokapazität von 304 TB ab. Davon sind 209 TB<br />
nutzbar. Im ersten Rack beträgt die Plattenkapazität bis zu<br />
112 TB brutto (77 TB nutzbar). Im zweiten Rack können bis<br />
zu 2 x 96 TB brutto (2 x 66 TB nutzbar) dazukonfiguriert<br />
werden. Der Anschluss von TapeLaufwerken und Tape<br />
Libraries ist voll unterstützt.<br />
Die neue Architektur des <strong>IBM</strong> Information Archive bietet<br />
zukünftig skalierbare Erweiterungsmöglichkeiten, indem das<br />
<strong>System</strong> mit zusätzlichen RechnerKnoten und zusätzlicher<br />
Plattenkapazität erweitert werden kann.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
157
158<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
SAN und IP-Networking<br />
Brocade hatte im Januar 2007 McData übernommen und<br />
eine Roadmap für die nächsten 18 – 24 Monate angekündigt.<br />
Die Architektur der übernommenen McData SAN Direktoren<br />
<strong>IBM</strong> 2027140/256 sowie die Architektur des Brocade 2109<br />
M48 SAN Direktors wird in einer gemeinsamen neuen Architektur<br />
in einem neuen Produkt, dem ‘Converged’ SAN Direktor,<br />
mit 8 Gbps abgebildet. Die Ankündigung des <strong>IBM</strong><br />
SAN768B erfolgte im Februar 2008. Dabei können dann die<br />
2027140/256 native an den neuen 8GbpsDirektor angeschlossen<br />
und weiterverwendet werden.<br />
Der <strong>IBM</strong> Direktor SAN768B wird von Brocade (Brocade DCX)<br />
gebaut und stellt eine Plattform bereit, die sich durch hochleistungsfähige<br />
IT und zukünftige FCoETechnologien<br />
(FibreChannel over Ethernet) kommenden ITEntwicklungsstufen<br />
anpasst. Es ist das erste ‘Direktorartige’ Produkt, das<br />
über FibreChannelVerbindungen Transferraten von 8 Gigabit<br />
pro Sekunde (Gbps) unterstützt, was die Geschwindigkeit<br />
beim Datentransfer in Zukunft nahezu verdoppeln kann.<br />
Der Direktor bietet die Unterstützung von FibreChannel,<br />
Fibre Channel over Ethernet (FCoE), Data Center Ethernet<br />
(DCE), Gigabit Ethernet und das iSCSIProtokoll.<br />
Der SAN768B ist das erste Produkt der Branche, das wirkliche<br />
Interoperabilität zwischen Direktoren des bTyps (Brocade)<br />
und solchen des mTyps (McDATA) in einer 8 oder<br />
10GbpsFCSANInfrastruktur unterstützt. Für Nutzer des<br />
mTyps und Großkunden, die ihre Mainframes über FICON<br />
Kanäle betreiben, bietet diese Interoperabilität eine Roadmap<br />
für die Erweiterung der bestehenden FICONStruktur.<br />
Die neue Plattform reduziert Komplexität, Ausfallrisiko und<br />
Energieverbrauch mit einer speziellen Skalierbarkeit von bis<br />
zu 768 FibreChannelPorts (externe User Ports) auf Basis<br />
von 8 Gbps über zwei Domänen.<br />
In einer großen Konfiguration mit zwei Domänen (Bild oben,<br />
Abbildung rechts) bietet der Direktor bis zu 896 Ports.<br />
Davon werden 768 Ports als ‘User Ports für externen<br />
Anschluss’ verwendet. Die restlichen 128 Ports werden über<br />
sogenannte ICL Inter Chassis Links an die Backplane der<br />
beiden Direktoren geführt und als ICLPorts bezeichnet. Die<br />
Übertragungsbandbreite zwischen den beiden Domänen<br />
(SAN868B Chassis) kann auf bis zu 1 Tbit/s gesteigert werden.<br />
<strong>IBM</strong> Direktor SAN768B (Brocade DCX) mit bis zu 896 Ports<br />
Die adaptiven Networking Services Features im SAN768B<br />
(Brocade DCX) erlauben in der Fabric eine dynamische<br />
Zuweisung verteilter Ressourcen in dem Moment, in dem<br />
die Anforderungen der virtuellen Server oder des vernetzten<br />
Speichers auftreten. Sollten Engpässe auftreten (oder vorhersehbar<br />
sein), können die Bandbreiten in der Fabric automatisch<br />
und entsprechend der vordefinierten Service Levels<br />
angepasst werden. Dies hilft dabei, Operationen mit einer<br />
höheren Priorität automatisch die benötigten Ressourcen zur<br />
Verfügung zu stellen.<br />
Das Jahr 2008 ist das Jahr der Einführung von 8Gbps<br />
Technologie in <strong>Storage</strong> Area Networks, die es erlauben<br />
8-Gbps-End-to-End-Lösungen zu implementieren. Im Jahr<br />
2009 zeigen sich neue Möglichkeiten auf, SANInfrastrukturen<br />
über IPNetze miteinander zu verbinden, und das Zauberwort<br />
heißt FcoE, FibreChannel over Ethernet.<br />
FCoE – FibreChannel over Ethernet<br />
Neben FibreChannel und iSCSI kommt mit FCoE ein neuer<br />
Standard auf den Markt mit dem Ziel, den Datenverkehr im<br />
Unternehmensnetz zu vereinheitlichen und FibreChannel<br />
SANInfrastrukturen via Ethernet miteinander zu verbinden.<br />
LAN nutzt Ethernet und das TCP/IPProtokoll für den Datentransfer.<br />
SANs, kommunizieren über FibreChannel. Dabei<br />
nutzen Server für die verschiedene NetzwerkTypen<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
getrennte InterfaceModule, die Network Interface Cards<br />
(NICs) für Ethernet und FC, ebenso separate SwitchInfrastrukturen.<br />
FCoE überträgt die Daten in einem FCSAN über<br />
das lokale produktive Netz via Ethernet. Damit können<br />
bestehende SAN<strong>System</strong>e weiterhin genutzt werden und per<br />
Ethernet in andere <strong>System</strong>e eingebunden werden, was langfristig<br />
die Betriebskosten durch eine konsolidierte Anbindung<br />
senken wird. Statt zwei parallele Netze zu pflegen, soll<br />
der gesamte Datenverkehr über ein Netz abgewickelt und<br />
administriert werden können. Dabei unterstützt FCoE ein<br />
konsistentes Verwaltungsmodell, das in FibreChannelSANs<br />
gebräuchlich ist. Diese neue konvergierte Technologie<br />
ermöglicht es, sowohl FibreChannelDaten wie auch IP<br />
Daten über denselben Transportmechanismus zu übertragen.<br />
Damit man nun FibreChannelPakete über ein Ethernet<br />
TransportProtokoll verschicken kann, haben sich verschiedene<br />
Hersteller von Speicherlösungen und Netzwerkkomponenten<br />
zusammengesetzt und einen Vorschlag zum<br />
FCoEStandard entwickelt. FCoE legt fest, wie man FC<br />
Daten verlustfrei über IP transportieren kann. Dieses ‘verlustfreie<br />
Ethernet’ besteht aus zwei Protokollen: Einmal das<br />
Protokoll zum Transport der Daten, FCoE genannt, und zweitens<br />
das Protokoll zur Kontrolle der FCoEVerbindungen, FIP<br />
(FCoE Initialisation Protocol) genannt. FIP kümmert sich um<br />
das Login und Logout von Geräten in einem FCoENetzwerk.<br />
FCoE verpackt den FCFrame in einen EthernetHeader<br />
und versendet diesen über Ethernet, wobei nun aber<br />
kein ‘traditionelles Ethernet’ zum Einsatz kommt, sondern<br />
eine verbesserte Version, die als CEE (Converged Enhanced<br />
Ethernet) bzw. DCE (Date Center Ethernet) bezeichnet wird.<br />
Was wird mit iSCSI? iSCSI verschickt SCSIBefehle über<br />
Ethernet und TCP/IP und benötigt keine teuren FCNetze.<br />
Klassisches FibreChannel verliert gegen iSCSI vor allem bei<br />
den Kosten. iSCSI nutzt die bestehende Infrastruktur, während<br />
die IT für ein FCSAN komplett neue Komponenten<br />
benötigt. Nun kommt FCoE als neue Technologie und verfügt<br />
über alle Eigenschaften, die iSCSI hat, auch bezüglich<br />
der Kosten. Es stellt sich damit die Frage, wie es mit iSCSI<br />
weitergehen wird, wenn sich FCoE als Technologie durchsetzt.<br />
Brocade hat im Juli 2009 Foundry Networks aquiriert und ist<br />
damit eine ziemlich gute Verbindung eingegangen. Brocade<br />
baut Hardware und Software für die Speicherlandschaft,<br />
Foundry ist im klassischen Unternehmensnetz unterwegs.<br />
Brocade kann sich künftig also in der FC und in der EthernetWelt<br />
ausbreiten und damit die Konvergenz erfüllen, die<br />
mit FCoE angestrebt wird.<br />
Cisco hat im April 2009 Nuova aquiriert, eine Firma, die<br />
sich schon länger mit FCoE beschäftigt.<br />
Hinter FCoE stehen nun die Firmen Brocade, Cisco, Nuova,<br />
EMC, Emulex, <strong>IBM</strong>, Intel, QLogic und Sun. Die Spezifikation<br />
für ‘FibreChannel over Ethernet’ sind dem T11-Komitee des<br />
USamerikanischen National Standards Institute (ANSI) vorgelegt,<br />
um einen gemeinsamen Standard zu etablieren. Seit<br />
Juni 2009 ist der FCoEStandard verabschiedet. Bis FCoE<br />
professionell im ITUmfeld eingesetzt werden kann, wird es<br />
noch etwas dauern! Bis Mitte bzw. Ende 2010 ist mit der<br />
Fertigstellung aller notwendigen ProtokollStandards zu<br />
rechnen.<br />
SAN & Converged Networking<br />
Nach der Ankündigung des <strong>IBM</strong> SAN768B im Feburar 2008<br />
war die Integration der Technologie von McData, die Brocade<br />
im Januar 2007 übernommen hatte, in einem neuen 8 Gbit/s<br />
DirektorProdukt komplett. Seither ist viel In der Zusammenarbeit<br />
von Brocade und <strong>IBM</strong> im Bereich <strong>Storage</strong> Networking<br />
hinzugekommen: Nach der Erweiterung der Lösungspalette<br />
mit 8 Gbit/s HBAs von Brocade steht erstmals eine durchgängige<br />
Serverzu<strong>Storage</strong>Konnektivität von einem Hersteller<br />
zur Verfügung – mit großen Vorteilen beim durchgängigen<br />
Management der Umgebung. Im Bereich der NetzwerkKonvergenz<br />
bietet <strong>IBM</strong> nun mit dem <strong>IBM</strong> ® Converged Switch<br />
B32 eine TopofRackLösung für Benutzer, die FibreChannel<br />
over Ethernet (FCoE) einsetzen und Erfahrungen mit der<br />
neuen Technologie sammeln möchten. Schließlich steht mit<br />
dem SAN384B eine weitere Core und EdgeSwitchingPlattfom<br />
für mittlere bis große SANUmgebungen zur Verfügung,<br />
mit der weitere DesignOptionen im BackboneBereich möglich<br />
sind.<br />
‘End-to-End’-Unterstützung<br />
Die 8 Gbps FibreChannel Host Bus Adapter ermöglichen<br />
es, ein hohes Maß an Robustheit und Zuverlässigkeit für die<br />
<strong>IBM</strong> <strong>System</strong> x Produktfamilie aufzubauen. Auf Basis der<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
159
160<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
hohen Leistungsfähigkeit der Brocade DCX Backbone Produktfamilie<br />
integrieren die 8 Gbit/s HBAs industrieweit erstmals<br />
wichtige Adapterfunktionen wie beispielsweise virtuelle<br />
Kanäle (Virtual Channels).<br />
Mittels der ‘Adaptive Network Services’ bieten die HBAs<br />
einen echten Quality of Service (QoS) im SAN von virtuellen<br />
Servern bis hin zum <strong>Storage</strong> Array und unterstützen Funktionen<br />
zur Datenautentifizierung, die eine schnellere und<br />
sicherere Kommunikation zwischen virtuellen Servern und<br />
dem Speicher erlaubt.<br />
Die 8 Gbit/s HBAs wurden dafür ausgelegt, die I/OLeistung<br />
am Server auf 500.000 Input/OutputOperationen pro<br />
Sekunde (IOPS) pro Port zu steigern. Damit leisten die 8 Gbit/s<br />
HBAs den doppelten Durchsatz im Vergleich zu vergleichbaren<br />
Produkten. Durch die enge Integration lassen sich die<br />
HBAs äußerst einfach installieren und in bestehende SAN<br />
Umgebungen einbinden.<br />
Erweiterte Fabric Backbone-Optionen mit dem SAN384B<br />
(Brocade DCX-4S)<br />
Der <strong>IBM</strong> SAN384B ist eine Einstiegsversion des bereits verfügbaren<br />
<strong>IBM</strong> SAN768B Backbone (Brocade DCX). Die<br />
neue SwitchingPlattform, die sowohl im Core als auch im<br />
Edge eingesetzt werden kann, ist für die Konsolidierung von<br />
Servern, <strong>Storage</strong> Area Networks (SAN) und Rechenzentren<br />
ausgelegt. Da die komplette DCXFunktionalität zur Verfügung<br />
steht, können mit dem SAN384B die Kosten für die<br />
Infrastruktur und die Administration gesenkt werden.<br />
Der <strong>IBM</strong> SAN384B skaliert in vier BladeEinschüben auf bis<br />
zu insgesamt 198 Ports mit vollen 8 Gbit/s und ist damit für<br />
Betreiber von mittleren Netzwerken geeignet. Betreiber von<br />
großen Speichernetzwerken können den <strong>IBM</strong> SAN384B<br />
auch als NetzwerkEdge einsetzen. Der <strong>IBM</strong> SAN384B ist<br />
mit der neuesten Brocade Fabric OS (FOS) Version 6.2 ausgestattet,<br />
die eine neue VirtualFabricMöglichkeit bietet, mit<br />
der die logische Partitionierung eines physischen SAN in<br />
logische Fabrics ermöglicht wird.<br />
Der <strong>IBM</strong> SAN384B unterstützt optional die Verschlüsselung<br />
von Daten auf Festplatten und Bandlaufwerken (Data at<br />
Rest) in Verbindung mit unterschiedlichen KeyManagementsystemen.<br />
Die Konvergenz im Netzwerkbereich<br />
gewährleistet der <strong>IBM</strong> SAN384B mit seiner Multiprotokoll<br />
Architektur durch die Unterstützung neu aufkommender<br />
Standards wie Converged Enhanced Ethernet (CEE) und<br />
FibreChannel over Ethernet (FCoE). Diese Protokolle werden<br />
durch einfache Ergänzung mit entsprechenden Blades zu<br />
einem vom Benutzer gewünschten Zeitpunkt ermöglicht.<br />
Die adaptiven Networking Services Features erlauben – wie<br />
auch im im SAN768B – in der Fabric eine dynamische<br />
Zuweisung verteilter Ressourcen in dem Moment, in dem<br />
die Anforderungen der virtuellen Server oder des vernetzten<br />
Speichers auftreten. Sollten Engpässe entstehen (oder<br />
vorhersehbar sein), können die Bandbreiten in der Fabric<br />
automatisch und entsprechend den vordefinierten Service<br />
Levels angepasst werden. Dies hilft dabei, Operationen mit<br />
einer höheren Priorität automatisch die benötigten Ressourcen<br />
zur Verfügung zu stellen.<br />
FibreChannel over Ethernet (FCoE) Produkte<br />
Auch wenn die Entwicklung noch nicht abgeschlossen ist –<br />
die ersten Standards für FibreChannel over Ethernet (FCoE)<br />
sind da. Mit dem <strong>IBM</strong> Converged Switch B32 sowie den<br />
dazugehörigen 10 Gb Converged Network Adaptern (CNA<br />
für <strong>IBM</strong> <strong>System</strong> x) steht eine Lösung zur Verfügung, die den<br />
Einsatz dieser neuen Technologie bereits erlauben. FCoE<br />
müsste eigentlich FCoCEE heißen, da für den verlustfreien<br />
Transport mit Converged Enhanced Ethernet (CEE) ein<br />
neues EthernetProtokoll entwickelt wurde.<br />
Der <strong>IBM</strong> Converged Switch B32 ist ein multiprotokollfähiger,<br />
Layer 2, TopoftheRack FCoE Switch mit 24 mal 10 Gigabit<br />
Ethernet (GbE) CEE Ports sowie acht FC Ports mit 8 Gbit/s.<br />
Er ermöglicht den konsolidierten Input/Output (I/O) von<br />
Speicher und NetzwerkPorts auf der ServerSeite. Die<br />
neuen Converged Netzwerkadapter (CNAs) bieten eine<br />
Leis tung von bis zu 500.000 I/Os pro Sekunde (IOPS) und<br />
stehen in zwei Varianten zur Verfügung: dem Single Port<br />
Brocade CNA 1010 und dem Dual Port Brocade CNA 1020.<br />
Die neuen BrocadeAdapter gehören zu den ersten CNAs<br />
mit SingleASIC, die klassisches Ethernet auf Basis des TCP/<br />
IP Protokolls, Converged Enhanced Ethernet sowie SpeichernetzwerkFunktionalität<br />
über einen einzigen 10 Gb/s FCoE<br />
Link von den Servern über das SAN bis hin zum LAN bieten.<br />
In Kombination ermöglichen der <strong>IBM</strong> Converged Switch B32<br />
und die 1010/1020 CNAs eine durchgängige FCoEKonnektivität<br />
vom Server bis hin zum Speicher. Die Lösungen können<br />
in existierende FCUmgebungen integriert werden und<br />
lassen sich mit einer übergreifenden ManagementPlattform,<br />
dem Data Center Fabric Manager (DCFM), administrieren.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Green IT<br />
Das Thema Energieeffizienz rückt immer mehr in den Mittelpunkt.<br />
Manche Rechenzentren können schon heute keine<br />
Server oder Speichereinheiten mehr aufnehmen, weil es klimatechnisch<br />
unmöglich ist.<br />
Laut einer IDCUmfrage von 2007 sind Themen rund um<br />
Energieverbrauch und Energieversorgung von zunehmender<br />
Bedeutung. Steigende Strompreise belasten die verfügbaren<br />
Budgets. In vielen Rechenzentren wird das Thema Energieeffizienz<br />
inzwischen zum TopThema. ‘Stromlose’ Datenträger<br />
wie Bandkassetten oder optische Platten werden in den<br />
nächsten Jahren eine Renaissance erleben. Nach einer GartnerStudie<br />
aus dem Jahr 2006 und 2008 werden mehr als<br />
70 % aller Daten auf Band abgespeichert. Wenn alle Daten,<br />
die heute im produktiven Einsatz auf Bandkassetten abgespeichert<br />
sind, auf Plattensysteme (Disk) verlagert würden,<br />
müssten ca. 40 neue Kernkraftwerke für die Stromversorgung<br />
gebaut werden. Das Internet und die steigende Nutzung<br />
des Internets erhöhen die Energieproblematik zudem<br />
immens: Vier InternetSuchanfragen benötigen so viel Strom<br />
wie eine 40WattGlühbirne mit einer Stunde Brenndauer.<br />
Im Mai 2007 kündigte <strong>IBM</strong> das Projekt ‘Big Green’ an. <strong>IBM</strong><br />
investiert seit dieser Ankündigung 1 Milliarde Dollar pro<br />
Jahr in das Projekt zur Verbesserung der ‘green’ Technologien<br />
und Services und arbeitet an einer Roadmap, um die<br />
eingetretene ITEnergieKrise für Rechenzentren zu bewältigen.<br />
Dazu hat <strong>IBM</strong> ein Team aus mehr als 850 EnergieSpezialisten<br />
aufgebaut. Der Mehrwert für ITBetriebe ergibt sich<br />
oft aus der Tatsache, dass Energiekosten für ein typisches<br />
Rechenzentrum halbiert werden können. Das entspricht im<br />
Vergleich einer Emmissionsreduzierung, die ca. 1.300 Autos<br />
erzeugen. <strong>IBM</strong> bietet dazu neben der Hardware und Software<br />
eine Vielzahl entsprechender Services für Rechenzentrumsbetriebe<br />
an. Teil dieser Services beinhalten Energie<br />
EffizienzAnalysen und/oder ‘EnergySelfAssessments’.<br />
Die beispielhaften Aktivitäten der <strong>IBM</strong> im Rahmen des Projekts<br />
‘Big Green’ und die damit verbundenen langfristigen Verpflichtungen<br />
führten dazu, dass <strong>IBM</strong> im Februar 2008 als<br />
die ‘Top Green IT Company’ des Jahres 2008 sowohl von<br />
der IDG (International Data Group) als auch von der Computerworld<br />
gewählt und ausgezeichnet wurde.<br />
Virtualisierung allgemein<br />
Virtualisierung in jeglicher Form wird für die Epoche der Serverbasierenden<br />
Speicherarchitekturen prägend sein. Neben<br />
TapeVirtualisierungen und Plattenvirtualisierungslösungen<br />
im SAN wird sich die Virtualisierung auf weit mehr Bereiche<br />
ausdehnen. Die <strong>IBM</strong> vertritt hier weltweit die Strategie ‘Virtualize<br />
Everything’. Nur so wird es möglich werden, heterogene<br />
Server und Speichereinheiten und unterschiedlichste<br />
Infrastrukturen optimal zu nutzen und ein flexibles, nach<br />
Regelwerken betriebenes Datenmanagement zu ermöglichen.<br />
Nur durch Virtualisierung in allen Bereichen werden<br />
Automationsprozesse in den heute unterschiedlichen Infrastrukturen<br />
möglich werden. Serverbasierende Speicherarchitekturen<br />
erleichtern den VirtualisierungsGesamtansatz<br />
erheblich.<br />
Mit effektiven Virtualisierungslösungen erzielt man eine möglichst<br />
maximale Nutzung der vorhandenen physikalischen<br />
Ressource, d. h., vorhandene Speicherkapazitäten werden<br />
wesentlich höher ausgenutzt. Somit liefert die Virtualisierung<br />
einen maßgeblichen positiven Beitrag zur Bewältigung der<br />
Energieproblematik im ITUmfeld.<br />
Neue Infrastrukturen und Bandbreiten<br />
Die heutigen FibreChannelNetze und IPInfrastrukturen werden<br />
in den nächsten Jahren mit Sicherheit weiterentwickelt<br />
werden. Von heutigen 4GbitSANs und 8GbitSANs geht<br />
es in Richtung 12-Gbit-SANTechnologie weiter. IPNetze<br />
heute mit bis zu 2Gbit und 10GbitEthernet könnten in den<br />
nächsten Jahren durch 100-Gbit-Ethernet-Technologie<br />
abgelöst werden. Der IPInfrastruktur, speziell dem Ethernet,<br />
wird in den nächsten Jahren noch eine besondere Bedeutung<br />
zukommen. Es ist geplant, innerhalb der nächsten<br />
fünf Jahre jedem Privathaushalt in Deutschland einen<br />
100MbitEthernetAnschluss zur Verfügung zu stellen.<br />
Damit bekommen die Privathaushalte neue, riesige Übertragungsbandbreiten.<br />
EthernetInfrastrukturen werden also zu<br />
einem maßgeblichen Faktor auch im privaten Umfeld.<br />
So wie die ersten SANInfrastrukturen zwei Jahre früher in<br />
den Hochleistungsrechenzentren der Universitäten ihre Anwendung<br />
fanden, bevor sie im kommerziellen Rechen zentrums<br />
umfeld zum Einsatz kamen, entwickeln sich heute ähn<br />
liche Tendenzen für eine neue Übertragungstechnik, die als<br />
InfiniBand bezeichnet wird. InfiniBand steht für ‘Infinite<br />
Bandwidth’. InfiniBand ist ein neues TransportProtokoll,<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
161
162<br />
2006 bis 2010<br />
Die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung<br />
das Servereinheiten, Speichereinheiten und ganze Netzwerke<br />
von Rechenzentren verbinden kann. Seit 1999 wird<br />
der Standard von der InfiniBand Trade Association vorangetrieben,<br />
nachdem damals Compaq, Dell, HP, <strong>IBM</strong>, Intel,<br />
Microsoft und SUN angekündigt hatten, ihre zukünftigen I/O<br />
Entwicklungen der InfiniBandTechnologie anzupassen. Seit<br />
Herbst 2005 ist der Standard verfügbar.<br />
InfiniBand schafft die Möglichkeit, heutige LAN, SAN, NASund<br />
IPC(Interprocessor Communication)Infrastrukturen in<br />
einem einzigen universellen Netzwerk zu vereinigen.<br />
Ebenso könnten separate InfiniBandNetze neben vorhandenen<br />
SAN und IPInfrastrukturen über iSCSI betrieben<br />
werden.<br />
Für das TransportProtokoll können Kupferkabel (Entfer<br />
nungslimitierung bei 17 m) und FibreOpticKabel (bis 10 km)<br />
verwendet werden. Die FibreOpticKabel für InfiniBand<br />
werden im Vergleich zu heutigen FibreChannelVerbindungen<br />
anders hergestellt und sind lange nicht so empfindlich.<br />
Ein Knick im Kabel verursacht fast keine Dämpfung<br />
und damit keinen Verlust. Würde man das mit dem heutigen<br />
FibreChannel machen, müssten die Kabel komplett ausgetauscht<br />
werden. Durch diese Eigenschaft ist InfiniBand Fibre<br />
Optic ideal geeignet, um für interne Verkabelungen von<br />
Maschinen zur Anwendung zu kommen.<br />
Für den externen Einsatz ist es wichtig, die FibreOptic<br />
Lösungen sowohl in der Unterstützung der seriellen Schnittstellen<br />
als auch in den Entfernungsmöglichkeiten voranzutreiben.<br />
4, 8 oder 12 ‘Physical Lanes’ können auf einen InfiniBand<br />
‘Physischen Link’ geschaltet werden, die Paketübertragung<br />
ist ‘bytemultiplexed’ über die Physical Lanes.<br />
InfiniBand repräsentiert ein extrem hohes skalierbares Link<br />
Interface SLI. Es ist möglich, die Anzahl der Physical Lanes<br />
dynamisch – abhängig von Durchsatzanforderungen und<br />
Datenverkehr – zu verändern und dynamisch anzupassen.<br />
InfiniBand bietet eine hoch skalierbare Verbindungstechnik<br />
mit ‘nX’ Multiple Lane Pairs mit einer Datenübertragungsrate<br />
von 2,5 Gbit/s (Single Data Rate SDR), 5 Gbit/s (Double<br />
Data Rate DDR) oder 10 Gbit/s (Quad Data Rate QDR) in<br />
jede Richtung. Die unten stehende Tabelle stellt die maximale<br />
Bandbreite für jede der Möglichkeiten dar:<br />
SDR DDR QDR<br />
1X 2,5 Gb/s 5,0 Gb/s 10,0 Gb/s<br />
4X 10,0 Gb/s 20,0 Gb/s 40,0 Gb/s<br />
8X 20,0 Gb/s 40,0 Gb/s 80,0 Gb/s<br />
12X 30,0 Gb/s 60,0 Gb/s 120,0 Gb/s<br />
InfiniBand hat einen weiteren wesentlichen Vorteil. Die Infini<br />
BandUpperLevelProtokolle wie SDP, SRP und iSER benützen<br />
die Methode des Remote Direct Memory Access<br />
RDMA, um direkt Daten in anwendungszugeordnete Pufferbereiche<br />
des Rechners zu schreiben und gleichzeitig auszulesen.<br />
Dies reduziert den OverheadDatentransfer zu einem Drittel<br />
und setzt CPUKapazitäten frei, die anders genutzt werden<br />
können.<br />
Nachdem die ersten InfiniBandNetze in einigen Hochleistungsrechenzentren<br />
der Universitäten etabliert sind, kann<br />
man – analog zum FibreChannel – davon ausgehen, dass<br />
die ersten InfiniBandNetze und Infrastrukturen innerhalb<br />
der nächsten 2–3 Jahre in ‘kommerziellen’ Rechenzentren<br />
implementiert werden. Beschleunigend kommt noch hinzu,<br />
dass InfiniBand im Vergleich zum FibreChannel kostengünstiger<br />
ist.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Neue Basis-Technologien<br />
Die Fachwelt im <strong>Storage</strong>bereich ist sich darin einig, dass<br />
Kunststoff das Speichermedium der Zukunft werden kann.<br />
Mit organischen Polymeren und polykristallinem Chalkogenid<br />
wird schon seit einigen Jahren experimentiert. Organische<br />
Polymere sind geeignet, durch optische Technologien<br />
für die Speicherung von Daten genutzt zu werden. Mit der<br />
neuen blauen Laser-Technik lassen sich InterferenzFelder<br />
auf dem Kunstoff erzeugen, die eine Vielzahl von Bits abbilden.<br />
Diese Technologie wird auch als holografische Speicherung<br />
bezeichnet und erlaubt viel größere Kapazitäten als<br />
mit herkömmlichen optischen Verfahren. Hierzu wird ein<br />
blauer Laser als ‘DatenStrahl’ eingesetzt. Ein Teil des<br />
Lasers wird über Spiegelverfahren durch einen Lichtmodulator<br />
geschickt, damit er eine andere Lichtbeugung bekommt.<br />
Anschließend kommen beide Strahlen auf der Polymeroberfläche<br />
wieder zusammen. Durch die unterschiedliche Lichtbeugung<br />
wird ein Interferenzfeld im Polymer erzeugt, das<br />
man heute als Hologramm bezeichnet (siehe Technologie<br />
Anhang unter HVD Holographic Versatile Disk, PCM Phase<br />
Change Memories und NanoTechnologien).<br />
Da heute noch niemand abschätzen kann, wie sich Kunststoffe<br />
und veränderte Kunststoffe im Laufe ihrer Alterung<br />
verhalten, arbeitet <strong>IBM</strong> an sinnvollen Alterungsverfahren für<br />
Kunststoffe, um genauere Aussagen zu bekommen. Heute<br />
geht man davon aus, dass ein veränderter Kunststoff einen<br />
Lebenszyklus von ca. 100 Jahren haben müsste. Diese Aussage<br />
muss aber noch durch entsprechende Alterungsverfahren<br />
belegt und bestätigt werden.<br />
Kommentar zur Epoche der Server-basierenden Speicherarchitekturen<br />
mit neuen Infrastrukturmöglichkeiten<br />
Serverbasierende Speicherarchitekturen wie DS8000, SVC,<br />
neue Archivierungslösungen, die neuen TapeVirtualisierungseinheiten<br />
ProtecTIER und TS7700, TS3500 Tape<br />
Library Virtualisierung und File Virtualisierung über File Area<br />
Networks bieten eine noch nie dagewesene Flexibilität und<br />
Skalierung in Leistung, Kapazität und Funktionalität. Sie werden<br />
die vor uns liegende Epoche maßgeblich bestimmen,<br />
weil Konsolidierungen auf einer ganz neuen Basis möglich<br />
werden. Diese neuen Architekturen schaffen die Möglichkeit,<br />
viele Server über Cluster zusammenzuschließen. Damit<br />
sind die ersten Anfänge von Grid Computing im kommerziellen<br />
Umfeld gelegt.<br />
Durch neue Bandbreiten der Datenübertragung und neue<br />
Vernetzungstechniken ergeben sich neue Ansätze für eine<br />
optimale Gestaltung der Rechenzentren und deren Infrastruktur.<br />
Virtualisierungslösungen in den unterschiedlichsten RZ<br />
Bereichen werden zu einer wesentlichen Vereinfachung der<br />
RZAbläufe führen und die Administration stark vereinfachen.<br />
Durch Standards werden die ITAnbieter gezwungen, näher<br />
zusammenzurücken, und der Endbenutzer bekommt endlich<br />
mehr Kompatibilität zwischen den unterschiedlichen <strong>System</strong>en,<br />
wie es bisher nicht der Fall war. Virtualisierung trägt<br />
hier einen ganz entscheidenden Anteil dazu bei.<br />
Neue Speichertechnologien werden rechtzeitig auf den Markt<br />
kommen, um den Anforderungen an ständig wachsende<br />
Kapazitäten Rechnung zu tragen. Kunststoffe als Speichermedium<br />
der Zukunft werden maßgeblich diese Epoche<br />
prägen. Ebenso können stromunabhängige Flashspeicher in<br />
Form von SSDs (Solid State Disks), Phasenwechselspeicher<br />
und <strong>Storage</strong> Class Memories die heutigen teuren FCPlatten<br />
verdrängen, wenn sie in den nächsten Jahren entsprechend<br />
billiger produziert werden.<br />
Das Tempo in der Entwicklung und in den Produktzyklen<br />
wird sich noch weiter verstärken. Es wird immer schwieriger<br />
werden, einen Gesamtüberblick über alle Möglichkeiten im<br />
<strong>Storage</strong>Umfeld zu behalten, die man aktiv nutzen kann, und<br />
Beratung wird eine größere Bedeutung als bisher haben.<br />
Hardware allein spielt dabei nur noch eine geringe Rolle.<br />
Die Epoche wird sicherlich die innovativste werden und vielleicht<br />
Dinge hervorbringen, an die wir heute noch gar nicht<br />
zu denken wagen. Hätte man in den 90erJahren jemandem<br />
erzählt, was heute alles verfügbar ist, wäre man sicher zum<br />
Fantasten gestempelt worden.<br />
Was wird in zehn Jahren sein? Es wird eine spannende<br />
Epoche werden und der Autor fragt sich selbst, ob seine<br />
Aussagen zutreffen werden.<br />
Vielleicht liegt unsere Vorstellungskraft noch weit hinter den<br />
Dingen, die vor uns liegen ...<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
163
164<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
<strong>IBM</strong> <strong>Storage</strong> Software<br />
<strong>IBM</strong> <strong>Storage</strong> Software<br />
Software<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 165
<strong>IBM</strong> <strong>Storage</strong> Software<br />
Der <strong>System</strong>-verwaltete Speicher im Mainframe-Umfeld – Werner Bauer<br />
Der <strong>System</strong>-verwaltete Speicher im Mainframe-Umfeld<br />
Wie der Name impliziert, wird die externe Speicherumgebung<br />
durch das <strong>System</strong>, genauer gesagt durch den<br />
angeschlossenen Server und dessen Betriebssystem,<br />
verwaltet. Verwaltet heißt in diesem Zusammenhang, dass<br />
das Betriebssystem automatisch alle Aktivitäten im Zusammenhang<br />
mit externem Speicher nach einem vordefinierten<br />
Regelwerk – Policybasierend – verwaltet. Andere oder<br />
ähnliche Begriffe für den systemverwalteten Speicher –<br />
<strong>System</strong> Managed <strong>Storage</strong> – sind Information Lifecycle<br />
Management (ILM) oder Scaleout File Services (SoFS). Solche<br />
Begriffe finden sich in ITLandschaften, die vornehmlich<br />
mit Unix und/oder Intelbasierenden Servern ausgestattet<br />
sind. <strong>System</strong> Managed <strong>Storage</strong> oder kurz SMS wurde durch<br />
die Ansätze im Mainframe und HostUmfeld in den 80er<br />
Jahren des vergangenen Jahrhunderts massiv geprägt.<br />
Dieser Ansatz wurde in den Anfängen bereits 1974 durch<br />
das Mass <strong>Storage</strong> <strong>System</strong> <strong>IBM</strong> 3850 eingeführt, wo bereits<br />
eine HSMFunktionalität zur Verfügung gestellt wurde, um<br />
Daten, die nicht oft benötigt wurden, auf einem billigen<br />
Massenspeicher systemgesteuert abzuspeichern (siehe<br />
auch unter <strong>IBM</strong> 3850).<br />
SMS hatte zum Ziel, das rasante Speicherwachstum der<br />
damaligen Zeit rasch zu adaptieren, ohne die Anzahl der<br />
Speicheradministratoren analog mitwachsen zu lassen. SMS<br />
verhält sich – fast – völlig elastisch zu dem wachsenden<br />
externen Speichervolumen, skaliert ausgezeichnet und<br />
verwaltet ein 400GBDiskbasierendes Speicherumfeld<br />
in 1990 genauso gut wie heute eine 4.000.000 GB große<br />
DiskKonfiguration.<br />
Speicherhierarchie<br />
Neben dem Abgleich der logischen Anforderungen an eine<br />
Datei mit der physisch vorhandenen Konfiguration wird von<br />
einer automatischen SpeichermanagementLösung erwartet,<br />
dass die Dateien sinnvoll in der vorhandenen Speicherhierarchie<br />
abgelegt und nach Anforderung bewegt werden.<br />
Heutige Plattensysteme können mit SSDs (Solid State<br />
Disks), FibreChannelPlatten und SATAPlatten bestückt werden<br />
und dadurch systemintern eine Speicherhierarchie<br />
abbilden. SSDs sind zwar noch sehr teuer, bieten dafür aber<br />
extrem schnellen Zugriff und extrem schnelle Antwortzeiten.<br />
166 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Die Speicherhierarchie wird bei den Magnetplatten durch<br />
zwei gegenläufige Trends bestimmt: Je schneller der Speicherzugriff<br />
und je besser und kürzer die Servicezeit ist,<br />
desto teurer ist das gespeicherte GB. Anders ausgedrückt:<br />
das gespeicherte GB wird preiswerter, wenn die Anforderungen<br />
an Zugriffszeit und Schnelligkeit geringer werden.<br />
Ein schnelles FibreChannelPlattenlaufwerk dreht mit<br />
15.000 Umdrehung pro Minute bzw. 250 Umdrehungen pro<br />
Sekunde, d. h., eine Umdrehung dauert 4 ms. Die übliche<br />
Kapazität einer FibreChannelDisk liegt heute zwischen<br />
300 GB und 650 GB mit einem Formfaktor von 3,5 Zoll<br />
Durchmesser. Die Anzahl der möglichen Zugriffe ist durch<br />
die hohe Umdrehungszahl wesentlich schneller im Vergleich<br />
zu einer preiswerten, hochkapazitiven SATAPlatte mit 7.200<br />
Umdrehungen pro Minute bzw. 120 Umdrehungen pro<br />
Sekunde mit 8,3 ms pro Umdrehung. Das dauert mehr als<br />
doppelt so lange im Vergleich zu einer FibreChannelPlatte.<br />
Die Kapazitäten bei SATAPlatten liegen heute bei 1 TB<br />
und 2 TB.<br />
Eine übliche Größe, um die Leistungsfähigkeit einer Platte<br />
einzuordnen, ist die Anzahl von Ein/AusgabeZugriffen<br />
pro Sekunde und pro GB. Das macht deutlich, dass SATA<br />
wesentlich schwächer als eine FibreChannelPlatte ist und<br />
daher für hochaktive Dateien ungeeignet ist. Die Technologie<br />
für 15.000 U/M ist auch anspruchsvoller – und damit teurer –<br />
als die notwendige Technologie, um mit nur 7.200 Um <br />
drehungen pro Minute zu rotieren.<br />
Eine spezielle Rolle im MainframeUmfeld kommt vir tuellen<br />
TapeKonfigurationen zu. Um den Vorteil des direkten<br />
Zugriffs der Platte für Backup und ausgelagerte Dateien<br />
zugänglich zu machen, aber andererseits ökonomisch mit<br />
dem genutzten Speicherplatz umzugehen, wird eine Technologie<br />
genutzt, die vermeidet, dass gleiche Datenstrukturen<br />
mehrfach gespeichert werden („Deduplication“). Dabei wird<br />
auf reale TapeLaufwerke gänzlich verzichtet und die<br />
BackupDateien und die ausgelagerten Daten („migrated<br />
data sets“) werden auf Disks abgespeichert. Ein solches<br />
<strong>System</strong> simuliert TapeLaufwerke gegenüber den angeschlossenen<br />
z/OSServern.<br />
Automatische Tape Libraries und Virtuelle Tape Server<br />
nutzen aber – sinnvoll – weiterhin reale Bandlaufwerke und<br />
Kassetten, auf denen letztlich die Dateien abgelegt werden,<br />
nachdem die geschriebenen TapeDaten durch einen<br />
vorgeschalteten Plattenpuffer gegangen sind. Über einen<br />
solchen Plattenpuffer können wieder virtuelle TapeLaufwerke<br />
emuliert werden, die viele TapeLaufwerke pro virtuellem<br />
Tape Server simulieren. Das eigentliche Backend besteht<br />
nur aus wenigen realen KassettenLaufwerken, über die<br />
hochkapazitive Kassetten beschrieben werden. Diese realen<br />
KassettenLaufwerke sind in einem virtuellen Tape Server für<br />
das z/OSBetriebssystem nicht sichtbar.<br />
Entstehung<br />
<strong>Storage</strong> Management Software<br />
DFSMS/MVS setzt heute den Standard der <strong>Storage</strong> Management<br />
Software, ohne die das Speicherwachstum in den vergangenen<br />
Jahren im MainframeUmfeld nicht administrierbar<br />
gewesen wäre.<br />
Die Anfänge von DFSMS/MVS gehen zurück bis in die<br />
frühen 80erJahre des vergangenen Jahrhunderts. Damals<br />
haben Kunden und entsprechende Benutzerorganisationen<br />
einschließlich der <strong>IBM</strong> die Notwendigkeit für ein vollautomatisches<br />
Speichermanagement erkannt:<br />
Rapides Speicherwachstum<br />
Die TCO für Speicher eskalierten bereits in den Jahren ab<br />
Anfang 1980<br />
„<strong>Storage</strong> keeps getting cheaper, but also harder<br />
to manage“, Datamation, 15.12.1985<br />
GUIDE/SHARE fordert <strong>IBM</strong> in den Jahren 1983–1985 auf,<br />
ein „policy based storage management“ anzubieten und<br />
definiert „requirements for futures of storage management“,<br />
GUIDE 1983<br />
„Without improvements in methods, or the emergence of<br />
improved automated managers, the storage management<br />
forces will have to grow exponentially as the data grows“,<br />
GUIDE Paper, 15.11.1985<br />
Internet, e-business, b-2-b interactions, life sciences, WEB<br />
2.0, etc. tragen weiterhin zu einer verstärkten Explosion<br />
der Nachfrage nach Speicherkapazität bei, die verwaltet<br />
werden muss.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
167
<strong>IBM</strong> <strong>Storage</strong> Software<br />
Der <strong>System</strong>-verwaltete Speicher im Mainframe-Umfeld – Werner Bauer<br />
Automatisches <strong>Storage</strong> und DatenManagement wurde mit<br />
DFSMS/MVS realisiert und wird in den folgenden Abschnitten<br />
beschrieben.<br />
Data Facility <strong>Storage</strong> Management Subsystem, DFSMS/MVS<br />
<strong>IBM</strong> hat 1989 mit MVS/DPF 3.0 die 2. Stufe einer Strategie<br />
realisiert, die unter dem internen Begriff „Jupiter Strategy“ in<br />
den frühen 80erJahren entstanden ist. Diese 2. Stufe ist<br />
das, was wir heute im HostUmfeld als SMS verstehen.<br />
Die JupiterStrategie war damals in drei Stufen geplant:<br />
1. Jupiter Stage I ist das, was im DFSMS/MVS bzw. z/OS als<br />
Interactive <strong>Storage</strong> Management Facility (ISMF) verstanden<br />
wird. ISMF ist ein Panel-basierendes ”Frontend“ zu dem<br />
externen Speicher und dem dazugehörigen Repository, in<br />
dem der externe Speicher in einer speziellen, sehr effektiven<br />
und effizienten Datenbank verzeichnet ist. ISMF war der<br />
erste Schritt und wurde 1987 angekündigt und im Markt<br />
eingeführt.<br />
2. Jupiter Stage II wurde 1989 als MVS/DFP 3.0 angekündigt<br />
und allgemein verfügbar. Neben dem Data Facility<br />
Product (DFP) waren auch die Komponenten Data Set Services<br />
(DSS), der Hierarchical <strong>Storage</strong> Manager (HSM) und<br />
der Removable Media Manager (RMM)<br />
integraler Bestandteil dieser Jupiter Stufe II. Das ist der<br />
Stand von SMS, wie er heute im Mainframe-Umfeld<br />
bekannt ist. Er trägt der Realisierung des Gedankens<br />
Rechnung, den Speicher durch das Betriebssystem nach<br />
einem vordefinierten Regelwerk automatisch zu verwalten.<br />
Über die Jahre hinweg wurde diese Stufe verfeinert und<br />
ergänzt und ist heute unter z/OS integraler Bestandteil<br />
der Betriebssystemsoftware.<br />
3. Jupiter Stage III war als letzte Stufe geplant. In dieser Stufe<br />
sollte die völlige Trennung von logischen Daten und physikalischer<br />
Speicherung umgesetzt werden. Dabei sollte der<br />
externe Speicher auf eine Block-Level Architektur standardisiert<br />
und die logischen Daten automatisch so plaziert<br />
werden, wie es über Regeln und Service-Levels vorge geben<br />
ist. Sollte eine Regel – oder der geforderter Service-<br />
Level – nicht mehr eingehalten werden können, sorgt das<br />
<strong>System</strong> selbst dafür, dass die betroffenen Blöcke automatisch<br />
und für die Anwendung unbemerkt in der Speicher-<br />
Hierachie so umverlagert werden, dass der geforderte<br />
Service-Level wieder eingehalten werden kann.<br />
Anfang der 90erJahre entschied <strong>IBM</strong>, diese 3. Stufe im<br />
Rahmen der JupiterStrategie nicht mehr zu verwirklichen.<br />
Man ging davon aus, dass eine entsprechende Investition<br />
eher für Unixbasierende Server gemacht werden sollte.<br />
168 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Funktionsweise<br />
Dateien im z/OS<br />
Bevor wir SMS und seine Komponenten genauer betrachten,<br />
wollen wir das Prinzip der Datei im z/OS beschreiben bzw.<br />
wie eine Datei angelegt und wiedergefunden wird.<br />
Jede Datei – vergleichbar mit einer „File“ in Unix oder<br />
Windows – bekommt im z/OS einen eindeutigen Namen<br />
bzw. genauer einen Dateinamen, ein „Data Set Name“<br />
(DSN) zugeordnet. Ein DSN kann bis zu 44 Character lang<br />
sein und besteht aus einzelnen „Qualifiern“. Diese Qualifier<br />
sind zwischen 1 und 8 Caracter lang und bestehen aus<br />
alphanumerischen Zeichen. In der Regel gibt es keine<br />
Vorschriften, wie solch ein Name ausgeprägt sein muss.<br />
Ein Beispiel: “SAP.PROD.KDNR1984.INDEX“ hat den 1.<br />
Qualifier mit SAP, der auch als High Level Qualifier (HLQ)<br />
bezeichnet wird, einen 2. Qualifier PROD, den 3. Qualifier<br />
KDNR1984 und den sogenannten Last Level Qualifier (LLQ)<br />
mit INDEX. Die Qualifier sind jeweils durch einen Punkt<br />
getrennt.<br />
Solch ein Name kann vom <strong>System</strong> genauso zerlegt und<br />
geprüft werden. Beispielsweise kann eine Regel definiert<br />
werden, die lautet . Unter &variable_llq ist bspw. INDEX, VER*,<br />
GRUPPE1 als mögliche LLQListe definiert, wobei dieser<br />
LLQ auch mit den ersten 3 Zeichen VER in die Auswahl<br />
fallen würde. Dabei wäre gleichgültig, wie die anderen<br />
Qualifier ausgeprägt sind. Also eine Datei mit DSN=TEST.<br />
D30M09.VERZ1 würde die Auswahl als gültig akzeptieren,<br />
da in der LLQListe auch VER* steht.<br />
Mit entsprechenden UNDVerknüpfungen von weiteren<br />
Regeln kann die Auswahl selektiver ausfallen wie etwa<br />
mit SAP*,PROD als Liste in der Variablen<br />
&variable_hlq. Dann fallen alle DSN mit SAP in den ersten<br />
3 Stellen des HLQ und mit den LLQ, wie in der Variablen<br />
&variable_llq definiert, in die Auswahl.<br />
Eine Datei muss in einem SMS Environment immer katalogisiert<br />
sein. Ein Katalog ist ein Verzeichnis, in dem jede<br />
einzelne Datei mit Namen verzeichnet ist und wo diese<br />
Datei zu finden ist. Das wird über ein Volume Label oder<br />
die sog. Volume Serial Number, VOLSER, bewerkstelligt.<br />
Die VOLSER ist ebenfalls eindeutig in einem SMS<strong>System</strong>.<br />
Mit Hunderttausenden oder Millionen von Dateien in einem<br />
großen <strong>System</strong> wird man nicht nur einen einzigen Katalog<br />
nutzen, sondern über den HLQ auf bestimmte Kataloge<br />
Request for<br />
existing data set<br />
DSN + Label<br />
Catalog<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
169
<strong>IBM</strong> <strong>Storage</strong> Software<br />
Der <strong>System</strong>-verwaltete Speicher im Mainframe-Umfeld – Werner Bauer<br />
zugehen. In unserem Beispiel sind alle Dateien, die SAP<br />
als HLQ ausweisen, in dem Katalog U.SAP katalogisiert. Da<br />
auch die Kataloge über einen DSN gefunden werden müssen,<br />
gibt es eine übergeordnete Instanz, die ”Master Catalog“<br />
genannt wird. Es gibt nur einen einzigen aktiven Master<br />
Catalog in einem SMS<strong>System</strong>. Dessen Inhalt wird Speicherresident<br />
im z/OS vorgehalten, da er für jedes ”Data Set<br />
Locate“ angezogen werden muss, um den zugehörigen<br />
[user] Catalog anzuziehen. Das geschieht über den HLQ<br />
und wird als ALIASBeziehung bezeichnet. Im Master Catalog<br />
wird SAP als HLQ eingetragen und der Verweis auf den<br />
user catalog U.SAP. Immer wenn ein DSN auftaucht, der<br />
SAP als HLQ ausweist, wird in dem Katalog U.SAP diese<br />
Datei definiert oder gesucht.<br />
Da der Katalog nur auf ein Volume verweist, auf dem die<br />
Datei abgelegt wird oder abgelegt ist, hat jedes Volume<br />
ebenfalls eine feste Struktur, damit die Datei letztlich auf<br />
dem Volume Level gefunden oder entsprechend eingetragen<br />
werden kann. Das ”Volume Label“ steht immer auf der gleichen<br />
Stelle eines jeden Volumes, Cylinder 1, Spur 1,<br />
Record 1. Das Label hat u. a. auch einen Zeiger zum<br />
Inhaltsverzeichnis des Volumes, die sog. Volume Table Of<br />
Content oder VTOC. Die VTOC ist funktionell grob mit einem<br />
File <strong>System</strong> in Unix oder Windows vergleichbar. In der<br />
VTOC stehen alle DSNs, die ein Zuhause auf diesem<br />
Volume haben, und die Anfangs und Endadresse dieser<br />
Datei auf dem Volume.<br />
Eine Datei oder DSN ist also ein eindeutiger Name innerhalb<br />
einer SMSKonfiguration und die zugehörige Datei muss<br />
immer katalogisiert sein. Die Anforderung, eine neue Datei<br />
anzulegen, geht durch das SMS – genauer gesagt durch<br />
das DFSMS, Allocation und Catalog Management – und<br />
sucht einen passenden Platz in der Speicherhierarchie,<br />
abhängig von dem geforderten ServiceLevel, der für diese<br />
neue Datei vorgegeben wird. Eine Anforderung für eine<br />
bereits bestehende Datei geht nur durch die Allocation und<br />
das Catalog Management, um die bestehende Datei zu<br />
lokalisieren und der Anwendung zugänglich zu machen.<br />
Übersicht über Policy-based <strong>Storage</strong> Management<br />
Policybasierendes <strong>Storage</strong> Management übernimmt die<br />
Aufgaben des SpeicherAdministrators, die zuvor manuell<br />
ausgeführt wurden. DFSMS erlaubt die Trennung der<br />
logischen Sicht der Daten von der physikalischen Speicherkonfiguration.<br />
Logisch ist hier synonym mit Service Level<br />
Agreements (SLA) gleichzusetzen und physikalisch bedeutet,<br />
wo die Daten tatsächlich abgespeichert werden. Logische<br />
Sicht heißt in der Terminologie von SMS: Data Class,<br />
<strong>Storage</strong> Class und Management Class. Die <strong>Storage</strong> Group<br />
spezifiziert letztlich den physikalischen Speicherplatz.<br />
Über die Data Class werden Angaben über den Speicherbedarf<br />
und die Daten-Attribute für eine Datei gemacht.<br />
Die <strong>Storage</strong> Class enthält Angaben zur geforderten<br />
Leistung und Antwortzeit und der Level der Verfügbarkeit<br />
für die betroffenen Dateien. Das beinhaltet die Platzierung<br />
auf einem physikalisch Volume mit schneller Zugriffszeit<br />
oder dass eine Datei über das Attribute „sequential data<br />
striping“ automatisch auf mehrere Volumes verteilt wird.<br />
Die Management Class enthält Angaben über Anzahl und<br />
Aufbewahrungsdauer der Sicherungen für eine Datei. Hier<br />
wird auch definiert, wie lange die Datei selbst bestehen<br />
bleibt, bevor sie automatisch gelöscht wird.<br />
Die <strong>Storage</strong> Group definiert den potenziell physikalischen<br />
Speicherplatz für die betroffene Datei. Eine <strong>Storage</strong> Group<br />
ist eine Gruppe von Volumes in Disk-<strong>Storage</strong>-Subsystemen<br />
oder eine Gruppe von Tape-Kassetten und Tape-Laufwerken.<br />
Die betroffenen Volumes werden von DFSMS kollektiv<br />
verwaltet.<br />
170 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
•<br />
•<br />
•<br />
•<br />
Entscheidend ist die Zuweisung dieser Attribute, die in<br />
diesen Klassen oder „Constructs“ definiert sind. Diese<br />
Aufgabe übernehmen sogenannte „Automatic Class Selection<br />
Routines“ (ACS Routinen). Basierend auf Kriterien wie DSN,<br />
Jobname, Größe der Datei und ca. weiteren 25 Kriterien,<br />
werden jeder einzelnen neuen Datei entsprechende Klassen<br />
zugewiesen. Für jede Klasse gibt es eine solche ACS Routine.<br />
Die Übersicht ”ACS Routinen und Speicherhierarchie“ zeigt<br />
die Rolle der ACS Routinen. Basierend auf diesen logischen<br />
Klassen sucht das <strong>System</strong> den optimalen Speicherplatz für<br />
die betroffene Datei in der vorhandenen Speicherhierarchie.
Die Auswahl des Platzes in der Speicherhierarchie wird<br />
”Volume Selection“ genannt. DFSMS geht durch eine Anzahl<br />
von Schritten und erstellt eine Liste von potenziellen<br />
Volumes, eine sogenannte ”candidate disk volumes“Liste,<br />
die in Frage kommen, um die neue Datei dort abzuspeichern.<br />
Diese VolumeListe basiert auf der Auswahl der entsprechenden<br />
<strong>Storage</strong>Gruppen, wie sie in der <strong>Storage</strong> Group ACS<br />
Routine zugewiesen wurden.<br />
Die sogenannte ”primary candidate“Liste enthält Volumes,<br />
die alle Kriterien erfüllen, die in der entsprechenden <strong>Storage</strong><br />
Class und Data Class spezifiziert wurden. Es gibt noch eine<br />
”secondary candidate volumes“Liste, die alle die Volumes<br />
enthält, die nicht alle Kriterien erfüllen, aber ebenfalls in der<br />
<strong>Storage</strong> Group ACS Routine zugewiesen wurden.<br />
Wenn diese ”primary candidate”Liste nicht leer ist, wird<br />
sie an die z/OSKomponente <strong>System</strong> Resource Manager<br />
(SRM) übergeben. SRM wählt dann eines oder mehrere<br />
Volumes von dieser Liste aus. Kriterien für SRM sind z. B.<br />
die kürzeste Wartezeit für eine I/O auf dem betreffenden<br />
Volume oder das Volume ist noch nicht für den momentanen<br />
Job im Einsatz. Falls die primary Liste leer ist, versucht<br />
DFSMS aus der secondary Liste direkt ein oder mehrere<br />
Volumes auszuwählen, ohne über den SRM zu gehen. Das<br />
wichtigste Kriterium ist dann der verfügbare freie Platz.<br />
Nachdem eines oder mehrere Volumes ausgewählt wurden,<br />
wird die Datei auf dem betreffenden Volume platzmäßig<br />
angelegt (Volume Allocation) und ein entsprechender<br />
Eintrag im Katalog erstellt.<br />
Sollte die Allocation nicht erfolgreich sein, wird die Volume<br />
Selection so oft wiederholt, bis entweder Volumes gefunden<br />
werden, um die Datei dort anzulegen, oder der Prozess<br />
bricht am Ende mit einer entsprechenden Nachricht ab,<br />
wenn kein eligibles Volume gefunden werden konnte.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
171
<strong>IBM</strong> <strong>Storage</strong> Software<br />
Der <strong>System</strong>-verwaltete Speicher im Mainframe-Umfeld – Werner Bauer<br />
SMS für Tape<br />
Policy-basierendes <strong>Storage</strong> Management für Tape Libraries<br />
DFSMS verwaltet nicht nur die Dateien in einem Disk<br />
<strong>Storage</strong> Subsystem, sondern auch die Daten und Einheiten<br />
in einer Tape Library. Das gilt für automatische Tape Libraries<br />
mit einem Robotorzugriff zu den Kassetten und Stellplätzen<br />
oder für sogenannte ”Manual Tape Libraries“ mit<br />
manuellem Laden der Kassetten in ein TapeLaufwerk.<br />
DFSMS gruppiert in diesem Ansatz die Kassetten und die<br />
zugehörigen KassettenLaufwerke in einer entsprechenden<br />
Tape <strong>Storage</strong> Group.<br />
<strong>System</strong>managed Tape verwaltet die Tape Libraries, die<br />
TapeLaufwerke und die TapeKassetten selbst, aber nicht<br />
die einzelnen Dateien, die auf diesen TapeKassetten stehen.<br />
Diese Funktion gewährleistet DFSMSrmm (Removable<br />
Media Manager), indem er ein Verzeichnis führt, welche<br />
Datei sich auf welcher Kassette befindet. Die Kassetten<br />
haben ebenfalls ein Label, das ähnlich ist wie bei den Disk<br />
Volumes.<br />
Die Abbildung ”<strong>System</strong>managed Tape“ zeigt, wie über<br />
die ACSRoutinen für eine bestimmte Datei auf Tape eine<br />
bestimmte Tape Library zugewiesen wird.<br />
Die Policybasierende Speicherverwaltung für Dateien auf<br />
Tapes kann auch auf die betroffenen Libraries selbst über<br />
eine sogenannte ”outboard“ Verwaltung ausgelagert werden.<br />
DFSMS weist die Konstrukte Data Class, <strong>Storage</strong> Class<br />
und Management Class von einer TapeDatei dem Tape<br />
Subsystem zu und übergibt diese KonstruktNamen<br />
(construct names) an die Library. Die Ausprägung der<br />
„Constructs“ wird in der Library selbst definiert und dann<br />
entsprechend ausgeführt – im Gegensatz zu dem zentralen<br />
Ansatz von DFSMS im Host.<br />
DFSMSrmm verwaltet die eigentlichen Dateien auf den Kassetten.<br />
Auch hier werden Attribute aus der Management<br />
Class entsprechend angewandt wie z. B. Lebensdauer und<br />
automatisches Löschen der Dateien, wenn die Dateien über<br />
einen definierten Zeitraum nicht referenziert wurden.<br />
Komponenten und Funktionen<br />
Komponenten<br />
Die Abbildung ”z/OS components for centralized storage<br />
and data management“ zeigt die <strong>System</strong>Komponenten<br />
im z/OS, die für die Allocation, also die Platzierung in der<br />
<strong>Storage</strong>Hierarchie, verantwortlich sind. Sie zeigt auch die<br />
Komponenten, die für das Space Management und die<br />
Availability angezogen werden.<br />
Neben dem DFSMSdfp kommt auch der SRM von z/OS<br />
für die „data set allocation“ zum Einsatz, wenn eine Datei<br />
neu angelegt wird.<br />
Für das Space Management und das Availability Management<br />
sind alle vier Komponenten miteinander verknüpft.<br />
Jede Komponente hat einen bestimmten Auftrag innerhalb<br />
von SMS zu erfüllen:<br />
1. DFSMSdfp – stellt das Interface zu den Policies her<br />
und instruiert die anderen Komponenten<br />
2. DFSMSdss – ist eine Art Data Mover und bewegt fast<br />
alle Dateien<br />
3. DFSMShsm – ist zuständig für das Space- und Availability<br />
Management. DFSMShsm bestimmt, welche Datei für<br />
Backup-Zwecke kopiert wird bzw. schafft freien Platz,<br />
indem nicht aktive Dateien ausgelagert und migriert werden.<br />
4. DFSMSrmm – ist für die Aufzeichnung der Kassetteninhalte<br />
bzw. für die Dateien auf Tape verantwortlich.<br />
172 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
DFSMS arbeitet mit zwei Repositories, dem Active<br />
Control Data Set (ACDS) und dem Communication Data<br />
Set (COMMDS). DFSMShsm und DFSMSrmm haben jeweils<br />
eigene Repositories, die aber über DFSMSdfp mit den<br />
DFSMSDateien ergänzt und abgeglichen werden.<br />
Funktionen<br />
Space Management<br />
Über die SMSKonstrukte und hier speziell über die<br />
Management Class werden Service Level Objectives bzgl.<br />
dem verfügbaren Platz auf Disk <strong>Storage</strong> Subsystemen bzw.<br />
den Volumes in einem solchen Subsystem spezifiziert. Das<br />
Ziel ist, dass Anwendungen nicht abbrechen, weil ein<br />
Problem mit nicht genügend freiem Platz aufgetreten ist.<br />
DFSMShsm ist die DFSMSKomponente, die die Policies<br />
für das Space Management überwacht und notwendige<br />
Aktionen ausführt, wenn die Policies nicht mehr eingehalten<br />
sind. Dabei werden neben der Management Class auch<br />
Angaben der <strong>Storage</strong> Groups herangezogen, um den Platz<br />
auf allen verwalteten Volumes in den Disk <strong>Storage</strong> Subsystemen<br />
auf DateiLevel zu verwalten. Das Kriterium sind<br />
sogenannte Thresholds auf Volume Level und auf <strong>Storage</strong><br />
Group Level, die eingehalten werden müssen, um immer<br />
genügend freien Platz für neue Dateien bereitzuhalten.<br />
Dieser Migrationsprozess erfolgt periodisch und es werden<br />
nicht aktive Dateien als Kandidaten für eine Verlagerung<br />
auf eine andere Klasse der Speicherhierarchie von<br />
DFSMShsm ausgewiesen.<br />
Auch wenn eine Datei von einem Volume in eine von<br />
DFSMShsm verwaltete Disk/TapeSpeicherhierarchie<br />
ver lagert wurde, bleibt die Datei nach wie vor katalogisiert.<br />
Wenn eine solche Datei von der Anwendung referenziert<br />
wird, führt DFSMShsm automatisch einen ”Recall“ durch<br />
und bringt die Datei zurück auf ein aktives Application<br />
Volume. Dieser Prozess ist für die betroffene Anwendung<br />
oder den Benutzer völlig transparent und unbemerkt.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
173
<strong>IBM</strong> <strong>Storage</strong> Software<br />
Der <strong>System</strong>-verwaltete Speicher im Mainframe-Umfeld – Werner Bauer<br />
DFSMShsm löscht auch automatisch Dateien, deren<br />
Lebensdauer nach ihrer zugewiesenen Management Class<br />
abgelaufen ist (deleting expired data sets). Es werden aber<br />
auch temporäre Dateien gelöscht oder es wird Platz freigegeben,<br />
der innerhalb einer Datei nicht mit Daten genutzt ist,<br />
wenn das durch die zugehörige Management Class als<br />
Attribut verlangt wird.<br />
Availability Management<br />
Availability Management verwaltet die BackupKopien von<br />
aktiven Dateien, die auf aktiven Disk <strong>Storage</strong> Volumes, auch<br />
L0Volumes genannt, liegen. Das Ziel ist, dass auf eine<br />
Sicherungskopie zurückgegriffen werden kann, wenn die<br />
OriginalDatei fehlerhaft oder beschädigt ist – oder gar ein<br />
ganzes Volume nicht mehr lesbar ist. DFSMShsm nutzt die<br />
PolicyAngaben in der Management Class und Informationen<br />
von der <strong>Storage</strong> Group, um automatisch und periodisch<br />
Sicherungskopien der OriginalDateien zu erstellen. Diese<br />
Sicherungen können auch über entsprechende<br />
Kommandos angestoßen werden.<br />
Konsolidieren von gültigen Dateien auf Tape-Kassetten<br />
Über die Management Class werden Policies festgeschrieben,<br />
wie und wann Sicherungskopien zu erstellen sind oder<br />
wann OriginalDateien ausgelagert werden sollen. In der<br />
Management Class wird auch festgeschrieben, wann eine<br />
Datei gelöscht werden soll oder wie viele SicherungsVersionen<br />
einer OriginalDatei wie lange aufbewahrt werden<br />
sollen. Auf einer TapeKassette sind oft viele Hunderte<br />
Dateien über das Space Management oder das Availability<br />
Management geschrieben worden, die zu unterschiedlichen<br />
Zeiten für eine Löschung eligibel werden.<br />
Die Abbildung ”Konsolidierung von gültigen Dateien auf<br />
TapeKassetten“ zeigt, wie über einen ”Reclamation“ oder<br />
”Recycle“Prozess nicht mehr valide Sicherungskopien oder<br />
nicht mehr benötigte und ausgelagerte Dateien<br />
entfernt werden.<br />
Dabei werden neue TapeKassetten erstellt, die anschließend<br />
wieder mit gültigen Dateien beschrieben sind. Die<br />
dadurch frei gewordenen TapeKassetten werden in einen<br />
Scratch Pool zurückgeführt und stehen damit wieder für<br />
neue Tape Requests zur Verfügung.<br />
DFSMShsm Common Recall Queue<br />
Entscheidend für die Leistungsfähigkeit von DFSMShsm ist<br />
die intelligente Nutzung von Funktionen und Services, die<br />
z/OS und Parallel Sysplex zur Verfügung stellen. Die Leistungsfähigkeit<br />
von DFSMShsm ist besonders kritisch, wenn<br />
viele Dateien aus dem DFSMShsmverwalteten Repository<br />
zurückgerufen werden müssen (über die RecallFunktion<br />
von DFSMShsm). Wenn eine Anwendung oder ein Benutzer<br />
eine Datei referenziert, die im Rahmen vom Space Management<br />
auf die DFSMShsmkontrollierte SpeicherHierarchie<br />
ausgelagert wurde, muss die Anwendung darauf warten,<br />
bis DFSMShsm die Datei auf das ApplicationVolume (L0)<br />
zurückgerufen hat (Recall). Wird diese Wartezeit minimiert<br />
und damit der Durchsatz im <strong>System</strong> erhöht, trägt das zu<br />
einer effizienteren Nutzung des gesamten <strong>System</strong>s bei.<br />
DFSMShsm optimiert deshalb diese RecallHerausforderung<br />
und nutzt die Coupling Facility als Repository für eine<br />
gemeinsame Queue von RecallAnforderungen. Die<br />
Kommunikation von den DFSMShsm<strong>System</strong>en innerhalb<br />
eines Sysplexes erfolgt über die XCFTechnologie, bei der<br />
die Coupling Facililty (Cross<strong>System</strong> Coupling Facility),<br />
praktisch einen schnellen und gemeinsam genutzten<br />
(shared) Halbleiterspeicher darstellt.<br />
174 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Eine typische Parallel Sysplex Konfiguration besteht aus<br />
einer DFSMShsmInstanz in jedem z/OS Image innerhalb<br />
eines solchen Sysplexes. Die RecallAnforderungen können<br />
sehr unterschiedlich in den verschiedenen z/OS Images<br />
eintreffen. Beispielsweise hat der HSM1 in der Abbildung<br />
”DFSMShsm – common recall queue“ für diesen Moment<br />
wesentlich mehr RecallAnforderungen abzuarbeiten als der<br />
HSM2 in dem zweiten <strong>System</strong>. Jeder DFSMShsm bearbeitet<br />
die Anforderungen in seiner lokalen Queue und weiß nichts<br />
über die Anforderungen in dem jeweils anderen <strong>System</strong>.<br />
ParallelSysplexweites Load Balancing wurde mit der<br />
Einführung einer Common Recall Queue möglich.<br />
Neben weiteren positiven Nebeneffekten ist offensichtlich,<br />
dass damit der Gesamtdurchsatz verbessert werden kann.<br />
Nebeneffekte betreffen eine optimalere Berücksichtigung<br />
von Prioritäten, effizientere Nutzung von Tape Resourcen,<br />
indem z. B. alle Requests nach TapeKassetten sortiert<br />
werden, und eine größere Flexibilität mit einer Sysplex<br />
Konfiguration.<br />
DFSMSdfp und Data Striping<br />
Ein weiteres Beispiel aus einer Vielzahl von Funktionen und<br />
Services durch DFSMS soll das Data Striping sein. Anstatt<br />
eine Datei auf ein einziges Volume zu platzieren, wird eine<br />
Datei auf mehrere Volumes verteilt oder „gestriped“. Die<br />
daraus resultierende Verbesserung der kombinierten Ein/<br />
Ausgabe trägt dazu bei, dass der „Single File“Durchsatz<br />
entsprechend erhöht werden kann. Dadurch kann die<br />
Verweildauer von Anwendungen und Jobs mit hohen Anforderungen<br />
an den Durchsatz von sequenziellen I/Os deutlich<br />
verkürzt werden. Das gilt auch in einem gewissen Maße für<br />
wahlfreie I/Os (Random I/Os), wenn die Anwendung I/Os<br />
parallel absetzen und verarbeiten kann. Dies ist die Regel<br />
bei DatenbankSubsystemen wie DB2 oder IMSDB.<br />
Die Abbildung ”DFSMSdfp – Data Set Striping“ illustriert<br />
diesen StripingEffekt für den sequenziellen Durchsatz.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
175
<strong>IBM</strong> <strong>Storage</strong> Software<br />
Der <strong>System</strong>-verwaltete Speicher im Mainframe-Umfeld – Werner Bauer<br />
Die rechte Seite der Abbildung symbolisiert den Effekt<br />
von Data Striping. Im Fall der Datei auf einem Volume ist<br />
der maximale sequenzielle Durchsatz des ZugriffsPfades<br />
100 MB/s. Wird für diese Datei über die <strong>Storage</strong> Class ein<br />
Attribute mitgegeben, das besagt, dass der sequenzielle<br />
Durchsatz 300 MB/s sein muss, dann würde DFSMS bei der<br />
Anlage dieser Datei automatisch dafür sorgen, dass diese<br />
Datei auf drei Volumes verteilt (gestriped) wird, wenn jedes<br />
Volume mit der Geschwindigkeit von 100 MB/s genutzt werden<br />
kann. DFSMS bzw. z/OS kennt genau die Möglichkeiten<br />
jedes einzelnen Volumes und nutzt diese Information bei<br />
der automatischen Auswahl der Volumes, wenn eine entsprechend<br />
neue Datei angelegt werden soll.<br />
Das <strong>System</strong> z/OS mit seinem integrierten DFSMS reagiert<br />
automatisch auf geforderte ServiceLevels und führt entsprechende<br />
Aktionen bezüglich der Datenverteilung und<br />
der Optimierung der vorgefundenen Speicherkonfiguration<br />
durch. Der <strong>System</strong>verwaltete Speicher ist heute im z/OS<br />
Umfeld die höchste Perfektionsstufe in der automatischen<br />
Datenverwaltung und Datenspeicherung.<br />
Zusammenfassung<br />
DFSMS oder der <strong>System</strong>verwaltete Speicher ist eine<br />
Softwarebasierende Lösung für z/OS. Er wurde seit der<br />
Ankündigung in 1989 kontinuierlich verbessert und nutzt<br />
automatisch neue Möglichkeiten der modernen Server und<br />
Speichertechnologie aus. Dieses Kapitel nennt nur einige<br />
Beispiele, wie DFSMS dazu beiträgt, die steigenden Anforderung<br />
an Verfügbarkeit und Leistung in modernen Rechenzentren<br />
zu gewährleisten und ständig zu verbessern.<br />
DFSMS dient auch als Vorbild für ähnliche Entwicklungen<br />
in den Open<strong>System</strong>sUmgebungen mit Unix und Intelbasierenden<br />
Betriebssystemen.<br />
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<br />
Anhang<br />
177
<strong>IBM</strong> <strong>Storage</strong> Software<br />
Tivoli <strong>Storage</strong> Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke<br />
Wie alles begann … 1983–1993<br />
Wenn man bedenkt, dass große Teile der heute verwendeten<br />
Architektur im Tivoli <strong>Storage</strong> Manager vor 20 Jahren<br />
konzipiert wurden, kann man die Leistung der damaligen<br />
Entwickler nicht hoch genug einschätzen. Besonders nachhaltig<br />
prägen dabei die ArchitekturElemente „forever incremental“,<br />
die Nutzung einer transaktional arbeitenden<br />
MetaDatenbank und die „tiered storage“Konzeption den<br />
Gesamt erfolg der TSMLösung. Gerade diese Komponenten<br />
sind heute noch wirkungsvolle Differenzierungskriterien zu<br />
anderen Angeboten auf dem Markt.<br />
Die ursprünglichen Ideen für eine Datensicherungslösung<br />
stammen ab Anfang der 1980erJahre aus Entwicklungen in<br />
Almaden von Mark Brown, Robert M. Rees und Michael D.<br />
Penner auf der Plattform VM/370. Sie entwickelten eine<br />
Anwendung für den internen Gebrauch mit dem Namen<br />
CMSback, die es erlaubte, Einzeldateien von CMSMinidisks1 im VM inkrementell zu sichern und zu restaurieren. Zu dieser<br />
Zeit konnte man mit Betriebssystemmitteln CMSMinidisks<br />
nur als DumpVolume über DDR (Data Dump Restore)<br />
sichern und rekonstruieren.<br />
Ankündigungsbroschüren DataKeep/VM (Name verworfen) und WDSF/VM<br />
Bob Rees beschreibt die Anwendungskomponenten von<br />
CMSback so:<br />
“In CMSback we explored a crawling model where:<br />
• a central process crawled user ’file systems‘ (VM minidisks)<br />
looking for files that have been changed or deleted<br />
• a framework for supporting tape drives together with disk<br />
• a restore GUI that could communicate with a central server to<br />
allow users to restore their own files.”<br />
In der Folge enstand ein internes Projekt mit Namen<br />
AMORE (Almaden MultiOperating system backup and<br />
REstore), das eine Reihe von Ideen aus CMSback, RDBMS<br />
ResearchProjekten und anderen internen Tools aufgriff.<br />
Diese Initiativen mündeten schließlich Ende der 80erJahre<br />
im formalen Projekt Datakeep/VM – einer gemeinsamen<br />
Entwicklung zwischen den Labors in Almaden und Endicott.<br />
Parallel dazu gab es eine weitere Entwicklung zu diesem<br />
Thema in Tucson/Boulder mit Namen ESMS.<br />
1 CMS = Cambridge Monitoring <strong>System</strong> – die Realisierung eines virtualisierten<br />
Single-User <strong>System</strong>s im Mainframe-Betriebssystem VM, in dem ein<br />
Benutzer in einer eigenständigen <strong>System</strong>-Umgebung interaktiv arbeiten kann<br />
und als Speicherressourcen „Minidisks“ bereitstehen, die er beliebig mit<br />
Daten oder Programmen verwenden oder mit anderen teilen kann – analog<br />
zu den Möglichkeiten, die heute ein PC/Laptop-Benutzer oder ein VMware-<br />
Benutzer auch hat.<br />
178 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
In ersten Pilotprojekten erwies sich die DataKeep/VM<br />
Lösung als stabiler als ESMS und führte am 1. November<br />
1990 zur Ankündigung des WDSF/VMSoftwareProdukts<br />
(Workstation DataSave Facility Release 1). Die Namensänderung<br />
von „DataKeep/VM“ hin zu „WDSF/VM“ war durch<br />
Vorbehalte der <strong>IBM</strong> Rechtsabteilung kurz vor der Ankündigung<br />
notwendig geworden, obwohl schon die gesamte<br />
Produktdokumentation gedruckt worden war.<br />
WDSF/VM Release 1 war die erste Cliet/Server Anwendung<br />
der <strong>IBM</strong> für die Sicherung von PC/WorkstationDaten der<br />
Betriebssysteme MSDOS, OS/2 und AIX. Das Produkt war<br />
konzipiert nach den noch heute gültigen Prinzipien von<br />
transaktionsbasierter Operation, regelgesteuerter Datenspeicherung,<br />
einem rein inkrementellen Datensicherungszyklus<br />
für Filesystemdaten und der Verwendung von<br />
hierarchischen Speicherpools für den kombinierten Einsatz<br />
unterschiedlicher Speichertechnologien (DisktoDisk oder<br />
DisktoDisktoTape).<br />
Die Entwicklungsmannschaft hat sich auch selbst ein Denkmal<br />
gesetzt in den Tiefen des TSMServers. Wenn man den<br />
undokumentierten Befehl „show developers“ in der Admin<br />
Commandline des TSMServers absetzt, bekommt man die<br />
Protagonisten aufgelistet (siehe Screenshot unten).<br />
Die Entwickler setzen sich ein Denkmal – „show developers“-Befehl im TSM-Server<br />
Die MetadatenVerwaltung wurde in der WDSF/VMServer<br />
Komponente in einer Datenbank realisiert, die Grundlagen<br />
aus der ARIESArchitektur verwendete. ARIES = Algorithms<br />
for Recovery and Isolation Exploiting Semantics war u. a.<br />
vom <strong>IBM</strong>Fellow Dr. Mohan aus Almaden entwickelt worden.<br />
Die in ARIES definierten Prinzipien der „writeahead logging<br />
based recovery method“ sind heute noch die Grundlage<br />
von TSM und einer Vielzahl von anderen <strong>IBM</strong> Anwendungen<br />
(DB2, MQSeries, Domino etc.) und die Basis relationaler<br />
Datenbanksysteme überhaupt.<br />
Die Implementierung basierte auf einer hierarchischen<br />
DatenbankArchitektur (B+ Tree), die den Anspruch erfüllte,<br />
auf allen Betriebssystemen der geplanten ServerPlattformen<br />
lauffähig zu sein, was zu diesem Zeitpunkt DB2 nicht<br />
erfüllte. Erst jetzt – fast 20 Jahre später – hat das verwaltete<br />
MetadatenVolumen in TSMServern unserer Kunden Größenordnungen<br />
erreicht, die mit der bisherigen DatenbankArchitektur<br />
nicht mehr skalierbar verarbeitet werden können.<br />
Deshalb hat man TSM in seiner aktuellen Version 6.1 auf<br />
DB2 als Datenbanktechnologie umgestellt.<br />
Das Konzept sah weitblickend auch vor, die Funktionen<br />
von Datensicherung in allgemeine <strong>System</strong>s Management<br />
Lösungen integrieren zu können, z.B. durch die Bereitstellung<br />
einer übergreifenden ManagementKonsole und Schnittstellen<br />
zur Erstellung von Berichten, zum Sammeln von Verrechnungsinformationen<br />
und zum Weiterleiten von Fehlerkonditionen.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 179
<strong>IBM</strong> <strong>Storage</strong> Software<br />
Tivoli <strong>Storage</strong> Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke<br />
Die wichtigsten Designprinzipien der neuen DatensicherungsSoftware<br />
waren:<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
Platform Independent Code<br />
Enable the server to preserve the physical locality that data<br />
has at its source even when clients deliver this data over long<br />
periods of time.<br />
Estimate the target workload and develop the system to<br />
accommodate them.<br />
Deploy the system in many computing platforms.<br />
Provide lights-out, unattended operation with unattended<br />
recovery from failures.<br />
Provide continuous operation<br />
Accommodate the peculiarities of a wide variety<br />
of storage devices<br />
Manage the storage system through user controlled policies<br />
Minimize the periods of time in which an entity in the system<br />
cannot be retrieved<br />
Use additional temporary storage space to gain<br />
concurrency and to increase the availability of user data<br />
Quelle: „Applying Database Technology in the ADSM Mass<br />
<strong>Storage</strong> <strong>System</strong>“ von Luis-Felipe Cabrera, Robert Rees and<br />
Wayne Hineman <strong>IBM</strong> Almaden Research<br />
Center 1995.<br />
Policy Manager<br />
Transaction<br />
Manager<br />
Logical Volume Manager<br />
Communication<br />
Driver<br />
Session Manager<br />
Administration<br />
Manager<br />
Transaction and Metadata Support<br />
LOG<br />
Index<br />
Manager<br />
Block Disk Driver<br />
ADSM-Server: Principal Software Components<br />
Central Scheduler<br />
Inventory<br />
Manager<br />
Pseudo Kernel<br />
Bitfile <strong>Storage</strong><br />
<strong>Storage</strong> Segments<br />
Export Import<br />
Manager<br />
<strong>Storage</strong> Subsystem<br />
Development Driver<br />
Physical Volume<br />
Repository<br />
Hier ein weiterer Auszug aus der gleichen Veröffentlichung<br />
mit einer Strukturdarstellung der Anwendungskomponenten<br />
und einer Beschreibung des Zusammenspiels der Module<br />
beim „incremental backup“:<br />
For incremental backup, the session begins by the client requesting<br />
from the server the corresponding policies from the Policy<br />
Manager. Policies are stored in system catalogues administered<br />
by the Index Manager. The client then builds the candidate list<br />
of files for backup and requests the server to send, from the<br />
Inventory Manager, the latest information for each of the<br />
candidate files. The Inventory Manager stores all its information<br />
in catalogues administered by the Index Manager. The client<br />
then sends to the server, optionally compressing them, only those<br />
user files that have changed or have been created since the last<br />
incremental backup. The server constructs appropriate entries<br />
in the Inventory Manager and appropriate bitfile using the<br />
Bitfile <strong>Storage</strong> component. Bitfiles are stored using the<br />
<strong>Storage</strong> Segment Manager.<br />
At the end of sending all the user files the client also sends the<br />
server the list of user files that have been deleted since the last<br />
incremental backup allowing the server to mark them and, eventually,<br />
to expire them from the system. The client then commits<br />
the transaction and disconnects from the server […]<br />
[…] Database technology has been applied before to distributed<br />
systems, to file systems, operating systems, to message queuing<br />
systems and to network I/O subsystems.<br />
To our knowledge we are the first ones to apply transactions<br />
to a mass storage system that administers a<br />
storage hierarchy. The fundamental difference with all<br />
other systems is the need to support high degrees of concurrency<br />
for a variety of transactions in the presence of<br />
devices with enormous latency times. A second difference<br />
is that our server can replicate its metadata with up to three<br />
copies. No other backup system or file system we know of has this<br />
function […].<br />
180 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Auszug aus dem WDSF/VMAnkündigungsschreiben am<br />
1. November 1990:<br />
Workstation Data Save Facility/VM turns VM host into a server<br />
WDSF/VM Release 1 is a client-server licensed program for<br />
backing up, archiving, and restoring disk data files. It enables<br />
a VM system to act as a server for workstations and personal computers,<br />
and moves the responsibilities of back-up archive media<br />
management to VM, while providing client applications to several<br />
workstation-based environments including MS-DOS, OS/2<br />
Extended, AIX/RT and AIX Version 3.<br />
It consists of a server program that runs under VM and one of<br />
the above environments, and while the archive function is userinitiated,<br />
the back-up function may be automated through<br />
scheduling. Backups may be performed from either end-user<br />
workstations or from workstation-based servers. Incremental<br />
backups may be run as background tasks under OS/2 and AIX,<br />
and when files are backed to VM-attached disks, older and larger<br />
files are automatically moved to tape. Archival functions enable<br />
the use of host storage resources as a off-line storage pool and<br />
WDSF/VM uses TCP/IP, NetBIOS or 3270 data stream support<br />
for communications.<br />
There is an optional facility for compressing data in the workstation<br />
client program. It operates on any <strong>System</strong> 370 or <strong>System</strong><br />
390 processor and requires a 1,600bpi or 6,250bpi tape drive,<br />
a 3480 or 3490 magnetic tape subsystem, 10 cylinders of 3380<br />
disk space and 6Mb of virtual storage.<br />
[ … ] WDSF/VM will be available March 29, and AIX 3 Client,<br />
September 27, 1991<br />
Die erste WDSF/VMVersion beinhaltete die ClientUnterstützung<br />
der damals marktüblichen <strong>IBM</strong> PC/Workstation<br />
Plattformen OS/2, AIX/RT, AIX V3 und MSDOS mit der<br />
Anbindung über die LANKommunikationsprotokolle TCP/IP,<br />
NetBIOS und 3270 LU2.0. Hinzu kamen im Laufe der Zeit<br />
noch die Protokolle SNA LU 6.2, IPX/SPX, CLIOS und<br />
Named Pipes. Die Unterstützung dieser ProtokollVielfalt<br />
hatte Bestand bis zur TSM Version 4.1 in 2001. Heute<br />
unterstützt TSM nur noch TCP/IP, SNMP für verteilte Umgebungen<br />
und Shared Memory und NamedPipe Protokoll für<br />
Client/ServerLösungen auf dem gleichen physischen <strong>System</strong>.<br />
Eine erste Erweiterung war im November 1991 die Ankündigung<br />
von WDSF/VM Release 1 Enhanced mit der Verfügbarkeit<br />
von zusätzlichen Clients auf SunOS und Apple MacOS.<br />
Damit begann auch die Ära der weitreichenden Unterstützung<br />
von anderen Open<strong>System</strong>Betriebssystemplattformen.<br />
In der Blütezeit wies die ClientUnterstützungsliste etwa 40<br />
<strong>System</strong>umgebungen auf.<br />
Workstation Data Save Facility/VM Release 1 Enhanced<br />
Workstation Data Save Facility/VM is enhanced to provide support<br />
for Sun Microsystems Inc‘s SunOS Version 4.0.1 and Version<br />
4.1.1, and Apple Computer Inc MacOS Version 6.0.7 and <strong>System</strong><br />
7 clients.<br />
AIX Version 3 for RS/6000 client will be available September 27,<br />
while WDSF/VM Programmer‘s Reference, SunOS Client, and<br />
MacOS Client will ship June 26, 1992.<br />
Der allgemeine Trend in Richtung von verteilten <strong>System</strong>en<br />
war der Grund für den nächsten Schritt, den Tivoli <strong>Storage</strong><br />
Manager in seiner Produkthistorie nahm. Im Jahr 1992<br />
wurde einmal die Anwendung von Chip Coy und Bill Fischofer<br />
in Endicott auf MVS portiert und für die Plattformen VM und<br />
MVS in DFDSM umbenannt – somit war das neue Datensicherungsmodul<br />
für Workstations ein Mitglied der S/370<br />
DFxxx SpeichersoftwareFamilie geworden.<br />
Parallel dazu trieben Norm Pass (RINGMASTER Projekt)<br />
und Mike Kaczmarski mit ihren Teams in Kalifornien die<br />
Portierung auf AIX und OS/2 als Server voran. Das neue<br />
DFDSMProdukt wurde auch gleich 1992 auf der COMDEX<br />
in Las Vegas gezeigt, allerdings unter etwas fragwürdiger<br />
Schwerpunktsetzung, wie der Entwickler Barry Fruchtman<br />
als Messeteilnehmer beschreibt.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 181
<strong>IBM</strong> <strong>Storage</strong> Software<br />
Tivoli <strong>Storage</strong> Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke<br />
Eingangsbildschirm ADSM V1.2 MS-DOS-Client<br />
Barry Fruchtman: „One item that may be interesting is that<br />
<strong>IBM</strong> <strong>Storage</strong> made an appearance at COMDEX in 1992 in Las<br />
Vegas with a demonstration of the DFDSM. We demonstrated,<br />
AIX, OS/2, and DOS clients backing up and restoring to VM,<br />
MVS, AIX and OS/2 servers; The OS/2 clients were running<br />
a video at the same time that they were in a loop backing<br />
up and restoring. For the few people which looked at the<br />
DFDSM sign and stopped to watch, it was an amazing demo,<br />
given the capabilities of the time. It was located in the multimedia<br />
area of COMDEX, however, so there was a mismatch with<br />
the intended audience…“.<br />
Die Anekdote dokumentiert augenzwinkernd, dass die <strong>IBM</strong><br />
Messeplaner damals die Bedeutung von Workstation Datensicherung<br />
der Tatsache unterordneten, dass zu gleicher Zeit<br />
ein MultimediaVideo auf dem OS/2PC ablief.<br />
Wie aus dem Augenzeugenbericht ersichtlich, gab es 1992<br />
schon die ersten internen Portierungen der DFDSMServer<br />
Komponente auf die Plattformen AIX und OS/2, die aber erst<br />
ein Jahre später als käufliche Produkte unter dem neuen<br />
Namen ADSM V1.2 verfügbar wurden.<br />
In dieser Zeit gab es noch weitere Entwicklungen und Produkte,<br />
die VM und MVS als Serverplattform für Datendienste<br />
der Open <strong>System</strong> Workstations nutzten:<br />
• WLFS/VM – Workstation LAN File Services (Ankündigung<br />
Dezember 1992 – später wegen Verfügbarkeit auf MVS in<br />
LAN File Services/ESA umbenannt) – eine Anwendung, die<br />
einen OS/2 LAN-Server über eine S/370 BMPX-Bus/Tag<br />
Adapterkarte an den VM-Server verband und transparent<br />
CMS-Minidisks als Laufwerks-Ressourcen für den OS/2<br />
LAN-Server verfügbar machte. Das geschah mit dem Hintergedanken,<br />
die Zuverlässigkeit der Mainframe-Datenhaltung<br />
mit den neuen interaktiven und grafischen Möglichkeiten<br />
der Workstations synergetisch zu verbinden.<br />
• LANRES/VM und LANRES/MVS (LAN Resource Extension<br />
and Services 1992) – die analoge Lösung zu WLFS/VM für<br />
Novell Netware Fileserver mit Anschluss entweder über<br />
eine BMPX-Kanalkarte, TCP/IP oder eine SNA LU6.2 Kommunikationsverbindung.<br />
Hierbei waren nicht nur Fileservices<br />
unterstützt, sondern auch bi-direktionales Drucken.<br />
182 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Alle diese Lösungen wurden damals in der Computer<br />
Presse als ein Versuch gewertet, den bevorstehenden<br />
Untergang des MainframeRechners als zentralen Anwendungsserver<br />
durch die Verwendung als Open <strong>System</strong><br />
Server Ressource zu verhindern.<br />
Dass die Nutzung des Mainframes als Server bis heute<br />
Bestand hat für eine Vielzahl von unternehmenskritischen<br />
und plattformübergreifenden Anwendungen (z. B. SAP,<br />
Domino, ContentManager etc.) und Diensten (wie TSM),<br />
hätte die damaligen „Branchenkenner“ in ihrem Weltbild<br />
wohl nachhaltig erschüttert.<br />
CW-Artikel (Auszug) vom 22.1.1993 zur Ankündigung von LANRES<br />
(Quelle: http://www.computerwoche.de/heftarchiv/1993/4/1125617/)<br />
Aufbruch in die Open-<strong>System</strong>-Welt<br />
ADSM V1.1 – 29. Juli 1993 und ADSM V1.2 16. November 1993<br />
Der in MainframeKreisen gängige Name DFDSM konnte<br />
nicht für den Zielmarkt der Open <strong>System</strong>s benutzt werden,<br />
weil in dieser Zeit die Polarisierung zwischen Befürwortern<br />
von Mainframe<strong>System</strong>en und Open Distributed <strong>System</strong>s<br />
schon klassenkämpferische Dimensionen annahm und man<br />
um den Produkterfolg fürchtete.<br />
<strong>IBM</strong>intern hatte man kurz nach der Verfügbarkeit von<br />
DFDSM entschieden, die ServerKomponente auch auf<br />
PC/WorkstationBetriebssysteme zu portieren und den<br />
Namen auf ADSM (ADSTAR Distributed <strong>Storage</strong> Manager)<br />
zu ändern.<br />
AdStaR-Ankündigung – New York Times 1992<br />
(Quelle: http://www.nytimes.com/1992/03/20/business/company-news-newibm-name-for-storage-unit.html)<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 183
<strong>IBM</strong> <strong>Storage</strong> Software<br />
Tivoli <strong>Storage</strong> Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke<br />
ADSTAR<br />
Wie im Artikel beschrieben, ist AdStaR das Akronym von<br />
„ADvanced STorage And Retrieval“ und wurde als Brandname<br />
eingeführt für die <strong>IBM</strong> <strong>Storage</strong> <strong>System</strong>s Division<br />
(<strong>IBM</strong> ADSTAR <strong>Storage</strong> <strong>System</strong>s Division). Grund für diese<br />
Umbenennung waren Gedankenspiele des damaligen <strong>IBM</strong><br />
Managements, <strong>IBM</strong> Divisionen als selbstständige Unternehmensteile<br />
auszugliedern und sie über eigene Warenzeichen<br />
zu individualisieren (siehe auch MagStaR). Diese Pläne<br />
wurden jedoch in der Folge nicht umgesetzt, aber das<br />
Warenzeichen ADSM blieb bis 1999.<br />
Das „Safeman“Logo hat der ehemalige <strong>IBM</strong> Grafik<br />
Designer Mike Welkley entworfen, der die Entstehungsgeschichte<br />
so beschreibt:<br />
Here‘s a little history on how the Safeman came about... I was<br />
working on the ADSM GUI back in 1993. Periodically we would<br />
bring in prospective customers to test the product and the software<br />
team asked if I would create a mouse pad that could be given to<br />
the customers as a complimentary gift. Given a blank canvas to<br />
create whatever I wanted for the design, I decided to create a<br />
cartoon character that represented ADSM <strong>Storage</strong>.<br />
Brandname und Identifikation –<br />
Das Original des ersten ADSM „Safeman“-Logos<br />
The mouse pad with the ADSM Safeman character on it, for<br />
whatever reason, never got printed. However, the ADSM Marketing<br />
team somehow got hold of the mouse pad design and wanted to<br />
print the character on buttons as a tradeshow giveaway. This was<br />
the first use of the character.<br />
Die ADSM V1.1Ankündigung bestand aus zwei unabhängigen<br />
Komponenten, einmal den Speichermanagementfunktionen<br />
für Datensicherung/Archivierung und zum anderen<br />
aus dem Datenzugriffsteil DAS (Data Access Services),<br />
das eigentlich mit dem Thema Datensicherung oder Speicher<br />
nichts zu tun hatte. Hier der Auszug aus dem Ankündigungsschreiben:<br />
Announcement Letter Number 293-382 dated July 29, 1993<br />
US – Last Revised on July 29, 1993<br />
Brief Description of Announcement, Charges, and Availability<br />
<strong>IBM</strong> announces the availability of ADSTAR (TM) Distributed-<br />
<strong>Storage</strong> Manager Version 1 Release 1*. The ADSTAR Distributed<br />
<strong>Storage</strong> Manager provides storage management and data access<br />
capabilities. The storage management capabilities provide an<br />
automated, highly-reliable, high-performance, network-based<br />
backup and archive product for workstations and local area<br />
network (LAN) file servers. It consists of an MVS- or VM-based<br />
backup/archive server and backup/archive clients for DOS, OS/2<br />
(R), AIX (R) for RISC <strong>System</strong>/6000 (R), Microsoft Windows,<br />
Apple Macintosh, SPARC /Solaris, HP-UX, and Novell NetWare<br />
systems. The data access services (DAS) provide Distributed<br />
FileManager for OS/2 Version 2 and the Record Level Input/<br />
Output (RLIO) API. Distributed FileManager provides local or<br />
remote record level access for OS/2 Version 2 applications.<br />
These capabilities are now available as a separately orderable<br />
component…[…]<br />
ADSTAR Distributed <strong>Storage</strong> Manager Version 1<br />
Release 1 is the successor product of <strong>IBM</strong> Workstation<br />
Data Save Facility/VM (5684122)and supports<br />
existing WDSF/VM backup/archive clients.<br />
184 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Die „Data Access Services (DAS)“ waren eine Zusammenstellung<br />
aus dem „Distributed File Manager (DFM)“ für OS/2<br />
V2 und dem ZugriffsAPI RLIO (Record Level I/O). Es handelte<br />
sich also um eine AnwendungsMiddleware, die nach<br />
den Vorgaben der „<strong>IBM</strong> <strong>System</strong> Anwendungs Architektur<br />
(SAA)“ verschiedene Anwendungsteile auf unterschiedlichen<br />
Betriebssystemen miteinander kommunizieren lassen<br />
konnte, sofern die geforderte SchnittstellenKompatibilitäten<br />
vorhanden waren (DDM/LU6.22 ).<br />
In der Version ADSM V1.1 gab es eine Reihe von Anwendungen,<br />
die für die Datensicherung mit ADSM getestet<br />
waren:<br />
•<br />
•<br />
•<br />
DB2/6000 provides an online backup of log and data to<br />
a remote MVS or VM system using ADSTAR Distributed<br />
<strong>Storage</strong> Manager.<br />
<strong>IBM</strong> LAN File Services/ESA [vormals WLFS/VM d. A]<br />
Customers using LAN File Services/ESA to distribute data<br />
objects will now be able to protect their data with ADSTAR<br />
Distributed <strong>Storage</strong> Manager.<br />
<strong>IBM</strong> DFSMS/VM uses ADSTAR Distributed <strong>Storage</strong> Manager<br />
to provide migration support for its SMS-managed<br />
storage hierarchy.<br />
Data Access Services CD – Zusatzkomponente zu ADSM V1.1<br />
•<br />
•<br />
The Norton Backup for Windows. Windows V3.1 users will<br />
now be able to backup their data to ADSTAR Distributed<br />
<strong>Storage</strong> Manager using the popular Norton Backup for<br />
Windows interface.<br />
Additionally, <strong>IBM</strong> has tested the ADSTAR Distributed<br />
<strong>Storage</strong> Manager backup/archive clients with the following<br />
database products for support of offline database backup<br />
and archive<br />
- <strong>IBM</strong> DB2 OS/2 Version 1<br />
- <strong>IBM</strong> DB2 AIX/6000 Version 1<br />
- SYBASE 4.5 and 4.9 (except for raw partition support)<br />
- INFORMIX-OnLine for AIX/6000<br />
- Borland dBASE IV 1.5 for DOS<br />
- Borland PARADOX 4.0 for DOS<br />
- Borland PARADOX 1.0 for Windows<br />
- Microsoft ACCESS 1.0 for Windows<br />
- Microsoft FOXPRO 2.5 for Windows<br />
- INGRES Intelligent Database for AIX/6000<br />
- ORACLE for <strong>IBM</strong><br />
2 <strong>IBM</strong> Definition DDM:<br />
“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<br />
on remote systems. The systems must be connected by a communications network, and the remote systems must also be using DDM…. Remote systems<br />
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 <strong>System</strong>s.”<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 185
<strong>IBM</strong> <strong>Storage</strong> Software<br />
Tivoli <strong>Storage</strong> Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke<br />
Auszug aus der ADSM V1.2-Ankündigung mit OS/2 und AIX als Server-Plattformen<br />
Im November 1993 wurden mit ADSM V1.2 die ADSM<br />
Server auf OS/2 und AIX angekündigt (ADSM/2 und<br />
ADSM/6000). Damit begann die Ära der Open<strong>System</strong><br />
Plattformen für ADSM.<br />
Der BackupMarkt war in dieser Zeit gekennzeichnet<br />
durch eine starke Polarisierung zwischen den Desktop/<br />
PCbasierten BackupLösungen (DOS, OS/2, Novell Netware,<br />
Apple MacIntosh) und entsprechenden Lösungen<br />
für UNIXWorkstations. Allen diesen Lösungen war zu eigen,<br />
dass sie Magnetband als Sicherungsmedium unterstützen<br />
konnten, wegen der Vorteile als preiswerter Massenspeicher<br />
für die Langzeitspeicherung.<br />
Die folgenden Aufstellungen sind ein Auszug aus einer<br />
Marktübersicht aus dem PCMagazine vom 29. März, 1994,<br />
pp.227272 (Quelle: http://stason.org/TULARC/pc/storage2/<br />
index.html). Die Listen beinhalten ausschließlich Lösungen,<br />
bei denen der Sicherungsserver selbst auf Open<strong>System</strong><br />
Plattformen betrieben wurde, parallel dazu gab es auch<br />
Angebote, die den Mainframe als Server nutzten, wie<br />
„Harbor“ von New Era oder „FDR/Upstream“ von Innovation<br />
Data Processing:<br />
Arcada Software – <strong>Storage</strong> Exec. (NT)<br />
Avail (NT)<br />
Cheyenne Software – ArcServe (Netware)<br />
Conner <strong>Storage</strong> <strong>System</strong>s – Backup Exec (Netware)<br />
Emerald <strong>System</strong>s – Xpress Librarian<br />
Fortunet – NSure NLM/AllNet<br />
Hewlett-Packard – OmniBack II (NT)<br />
Legato – NetWorker (Netware)<br />
Mountain Network Solutions – FileSafe<br />
NovaStor (Netware)<br />
Palindrome – Backup Director und Network Archivist<br />
(Netware, OS/2, Windows)<br />
186 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
Nachfolgend die Liste der UNIXLösungen, wobei hier die<br />
Bedeutung von MagnetbandUnterstützung nicht so gravierend<br />
war wie bei den Desktops/PCs, weil UNIX durch die<br />
<strong>System</strong>funktionen tar, cpio, dd und dump schon Bandunterstützung<br />
kannte.
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
APUnix – FarTool<br />
Cheyenne – ArcServe<br />
Dallastone – D-Tools<br />
Delta Micro<strong>System</strong>s (PDC) – BudTool<br />
Epoch <strong>System</strong>s – Enterprise Backup<br />
Hewlett-Packard – OmniBack II<br />
Legato – Networker<br />
Network Imaging <strong>System</strong>s<br />
Open Vision – AXXion Netbackup 2.0 Software<br />
Software Moguls – SM-arch<br />
Spectra Logic – Alexandria<br />
Unitree Software – Unitree<br />
In diese Märkte brach nun ADSM V1.2 ein, eine unternehmensweite<br />
BackupLösung auf Open<strong>System</strong>Plattformen für<br />
Desktops und UNIXWorkstations, die sich schon unter den<br />
MainframeBetriebssystemen VM und MVS als Serverplattform<br />
bewährt hatte und die ganze Erfahrung der <strong>IBM</strong> im Verwalten<br />
großer Datenmengen einbrachte. Dies war vor allem für<br />
solche Kunden wichtig, die einerseits die neue „demokratische“<br />
Organisation von PCs und Workstations in verteilter<br />
Verarbeitung nutzten, andererseits auf die hohen Sicherheits<br />
und Verfügbarkeitsstandards der MainframeTechnologie<br />
für das zentrale Datenmanagement nicht verzichten<br />
wollten.<br />
ADSM V1.1 – Handbücher aus der „black books collection“<br />
In der Folgezeit bewährte sich für ADSM eines der obersten<br />
DesignPrinzipien von WDSF/VM, ADSM und TSM – die<br />
Nutzung von „common code“. Es musste nicht für jede<br />
Client/ServerPlattform neu entwickelt werden, sondern die<br />
Wiederverwendung von Code erwies sich als kostensparend.<br />
Das Verfahren reduziert den Aktualisierungs und Pflege<br />
Aufwand der Entwickler und beschleunigt die Entwicklungszyklen<br />
beträchtlich – ein Prinzip, das bis heute Hardwareund<br />
SoftwareEntwicklungen erst wirtschaftlich macht.<br />
Die Gründung von Internet-Forum und Benutzergruppen<br />
Die Abkürzung ADSM ist heute noch ein weitverbreitetes<br />
Synonym für Tivoli <strong>Storage</strong> Manager und man entdeckt<br />
immer wieder Bereiche im Umfeld von TSM, in denen diese<br />
alte Produktbezeichnung noch benutzt wird.<br />
So z. B. im bekannten ADSML Internet UserForum<br />
(www.adsm.org), das zu Beginn der 90erJahre vor allem<br />
aus der großen Benutzergruppe der Universitäten heraus<br />
gegründet wurde und bis heute als Wissensdatenbank und<br />
Kommunikationsplattform für alle ADSM/TSMInteressierten<br />
im Internet gepflegt wird. In dieser Zeit (1994) begannen<br />
sich auch in Deutschland Benutzergruppen zu bilden wie<br />
der GSEArbeitskreis „<strong>Storage</strong>management“ (www.gsenet.<br />
de), in den Anfängen geleitet vom Chairman FranzXaver<br />
Maier und seit 2003 aktiv gelebt von seinem Nachfolger<br />
Gerd Becker (<strong>IBM</strong> Geschäftspartner Empalis). Hier treffen<br />
sich in Deutschland zweimal im Jahr an drei aufeinander<br />
folgenden Tagen interessierte Kunden bei Vorträgen und<br />
Erfahrungsaustausch zu den Themen Mainframe <strong>Storage</strong>,<br />
Open <strong>System</strong> <strong>Storage</strong> und TSM.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 187
<strong>IBM</strong> <strong>Storage</strong> Software<br />
Tivoli <strong>Storage</strong> Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke<br />
Der erste ADSM Large European Sites (ALES) Workshop<br />
wurde 1994 in Karlsruhe abgehalten, initiiert durch die<br />
Universitäten Karlsruhe und Heidelberg, namentlich Prof.<br />
Dr. Gerhard Schneider, Klaus Dilper und Rolf Bogus, ein<br />
Erfahrungsaustausch von großen europäischen ADSM<br />
Benutzern aus dem universitären, wissenschaftlichen und<br />
kommerziellen Kundenkreis. In der Folge entstand daraus<br />
das seither alle zwei Jahre stattfindende TSM Symposium<br />
(Karlsruhe 1994–1998, Oxford 1999–2007 – Initiator<br />
Sheelagh Treweek, Königswinter/Petersberg 2009 – Initiator<br />
Claus Kalle, Uni Köln) mit mehr als 200 internationalen<br />
Teilnehmern und Sprechern aus dem Teilnehmerkreis, von<br />
Geschäftspartnern, SoftwareHerstellern und aktiver personeller<br />
Unterstützung durch die TSMLabors (u. a. Paul<br />
Bradshaw, Andy Raibeck und ab 1999 Dave Cannon).<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
März 1994 – 1. ALES Workshop Karlsruhe<br />
April 1996 – 2. ADSM Workshop Karlsruhe<br />
September 1998 – 3. ADSM Workshop Karlsruhe<br />
September 1999 – ADSM Symposium Oxford:<br />
Meeting the Challenge<br />
September 2001 – TSM Symposium Oxford:<br />
Managing The Impossible<br />
September 2003 – TSM Symposium Oxford:<br />
A New Perspective<br />
September 2005 – TSM Symposium Oxford:<br />
Facing The Future<br />
September 2007 – TSM Symposium Oxford:<br />
Preparing The Path<br />
September 2009 – TSM Symposium Köln/Petersberg:<br />
Experience The Challenge<br />
ADSM-Server auf weiteren Open-<strong>System</strong>-Plattformen – V2.1 1995<br />
CW-Artikel (Auszug) vom 31.3.1995 zur Ankündigung von ADSM V2.1<br />
(Quelle: http://www.computerwoche.de/heftarchiv/1995/13/1113172/)<br />
Durch die Verwendung von „common code“ wurde<br />
ADSM V2.1 im Laufe eines Jahres bis November 1996 um<br />
die ServerPlattform OS/400, VSE und um eine Reihe von<br />
Client und Anwendungsplattformen erweitert.<br />
Hewlett-Packard HP-UX 10.01<br />
SunOS und Sun Solaris<br />
Windows NT and Windows 95<br />
Apple Macintosh Windows 32-bit client<br />
NCR UNIX SVR4 3.0 und NCR EWS-UX/V<br />
Bull DPX/2 und Bull AIX<br />
Digital UNIX<br />
Siemens Nixdorf SINIX 386/486 und SINIX RISC<br />
SCO UNIX386 und SCO Open Desktop<br />
Sequent PTX<br />
Silicon Graphics IRIX<br />
Pyramid Nile (via SINIX RISC)<br />
Open Edition MVS<br />
AS/400 API-Client für BRMS<br />
Lotus Notes 4.1<br />
HSM-Client für AIX und Solaris 2.5<br />
Cray UNICOS und Fujitsu UXP als Service Offering<br />
188 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•
ADSM V2.1 Win 95 Client GUI und Logo<br />
Der „Lotus Notes Backup Agent“ war die erste reguläre<br />
Produkterweiterung (im Gegensatz zu optionalen Service<br />
Angeboten wie Backint/ADSM) für die OnlineAnwendungssicherung<br />
im ADSM. Sie eröffnete die Möglichkeit, konsistente<br />
OnlineBackups zu erstellen und zudem das Verfahren von<br />
„incremental forever“ für NotesDokumente anzuwenden.<br />
Dieses Verfahren hatte den Vorteil für die NotesBenutzer,<br />
auch einzelne Mails oder Anhänge sichern und rekonstruieren<br />
zu können, litt allerdings unter dem Nachteil von schlechtem<br />
Durchsatz und starker Belastung für die ADSMDatenbank,<br />
weil jedes gespeicherte Dokument auch einen MetaDaten<br />
Eintrag erzeugte. Die spätere Datenbankorientierte Architektur<br />
von Lotus Domino ab V5 hatte diese „single object<br />
backup“Schnittstelle nicht mehr und der ADSMAgent<br />
wurde entsprechend angepasst.<br />
Weitere funktionale Neuerungen von ADSM V2.1 waren<br />
unter anderem:<br />
•<br />
•<br />
die Bereitstellung des „Disaster Recovery Managers“ für<br />
die Automatisierung von Disaster Recovery Vorsorgemaßnahmen<br />
und einem strukturierten Verfahren für die Statusverfolgung<br />
der Auslagerungs-Bänder (offsite vault<br />
management)<br />
die automatisierte Erzeugung von ADSM-Datenbank-<br />
Backups und <strong>Storage</strong>-Pool-Backups (Copypool)<br />
•<br />
•<br />
•<br />
•<br />
Erweiterung des Scheduling-Verfahrens mit pre- und<br />
post-processing Optionen und die Unterstützung von<br />
Admin-Befehlen im Scheduler<br />
HSM-Clients für das Kapazitätsmanagement von<br />
UNIX-File-<strong>System</strong>en (HSM-Client für AIX V3.2/V4.1 und<br />
Solaris 2.5)<br />
Erweiterungen des ADSM-API-Clients um die Funktionen<br />
„Partial Object Retrieve“ und die Bereitstellung eines<br />
OS/400 API-Clients<br />
Ankündigung der Verfügbarkeit eines Oracle/EBU-Clients<br />
für Ende 1996<br />
In dieser Zeit erschienen auch die ersten komplementären<br />
Produkte mit ADSMAnbindungen auf dem Markt, die zum<br />
Teil im Rahmen von ResellerVerträgen durch die <strong>IBM</strong><br />
weiterverkauft wurden oder wo es mit den Herstellern Entwicklungspartnerschaften<br />
gab.<br />
• <strong>IBM</strong> Personally Safe’n Sound – <strong>IBM</strong> Datensicherungslösung<br />
für OS/2-Server für den Anschluss lokaler Speicherressourcen<br />
oder der optionalen Anbindung an den<br />
ADSM-Server.<br />
• DataTools „SQL BackTrack“ – November 1994 (Datatools<br />
wurde 1997 von BMC übernommen), eine Sicherungssoftware<br />
für verschiedenste relationale Datenbanken<br />
(DB2, Oracle, Sybase, Informix etc.) mit dem Alleinstellungsmerkmal<br />
der OBSI-Schnittstelle, die es erlaubt, alle<br />
Schnittstellen-kompatiblen Datensicherungsanwendungen<br />
als Backend verwenden zu können, ohne den Backup-<br />
Code in der Anwendung austauschen zu müssen.<br />
• Avail <strong>System</strong>s „Netspace for Netware“ (Avail wurde<br />
1995 von Wang Laboratories Inc. übernommen, das<br />
Produkt später von Kodak vertrieben) – eine HSM-Lösung<br />
für Novell Netware Server.<br />
• ETI Backhome! – Backup Integration für Tandem Guardian<br />
Hochverfügbarkeitslösungen<br />
• Core Data Inc. „Remoteworx“ (Core Data wurde 1999<br />
von Sterling übernommen) – eine Datensicherungslösung<br />
für Desktop und Laptop-Benutzer mit Windows95 und<br />
WindowsNT als Betriebssystem<br />
• <strong>Storage</strong> Solution Spezialist Inc. SSSI –<br />
„ABC OpenVMS Client“ für ADSM<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 189
<strong>IBM</strong> <strong>Storage</strong> Software<br />
Tivoli <strong>Storage</strong> Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke<br />
• Seagate „Backup Exec“ (vormals Conner <strong>Storage</strong><br />
<strong>System</strong>s – Seagate wurde 2000 von Veritas übernommen) –<br />
Datensicherungssoftware für kleine und mittlere Umgebungen<br />
mit einer ADSM-Schnittstelle für die Nutzung der<br />
hierarchischen ADSM-Speicherpools als Alternative zu<br />
direkt angeschlossenen Bandlaufwerken.<br />
• EMASS/Grau – Anschluss-Schnittstelle für AML/S, AML/E,<br />
AML/2 Tape-Libraries über das ADSM External Library<br />
Management API.<br />
• Sterling SAMS Vantage DP – Reporting-Werkzeug für<br />
ADSM-Umgebungen (Sterling wurde 2000 von CA<br />
übernommen)<br />
Es ist bemerkenswert, dass man bei entsprechender<br />
Recherche im Internet heute noch Anzeigen zu ADSM V2.1<br />
findet, wie die Abbildung „Resultat aus einer Internetsuche<br />
2009 nach dem Stichwort ADSTAR“ zeigt. Es muss allerdings<br />
bezweifelt werden, ob das Produkt unter dieser Quelle<br />
wirklich noch käuflich ist.<br />
Resultat aus einer Internetsuche 2009 nach dem Stichwort „ADSTAR“<br />
SAP R/3 Integration – eine Erfolgsgeschichte aus dem<br />
<strong>IBM</strong> Labor Böblingen<br />
Einen besonderen Stellenwert beim Erfolg von ADSM<br />
hatte die frühe Anbindung an die von SAP entwickelte<br />
„BackintSchnittstelle“. Die SAPEntwickler erachteten diese<br />
Schnittstelle deshalb für notwendig, weil die integrierten<br />
BackupFunktionen der OracleDatenbank zu dieser Zeit<br />
nicht ausreichend waren zum Erstellen von konsistenten<br />
OnlineBackups und die Anforderungen eine enge Verknüpfung<br />
von Backup mit den SAPspezifischen Management<br />
Werkzeugen vorsah. Das <strong>IBM</strong> Labor Böblingen hatte durch<br />
die geografische Nähe zur SAPEntwicklung in Walldorf<br />
einen strategischen Vorteil für diese Implementierung, weil<br />
für die Pflege einer solchen Integration kontinuierliche<br />
Absprachen und Tests mit dem Anwendungshersteller nötig<br />
sind. Neben der „Backint“Schnittstelle wurden auch weitere<br />
SAPSchnittstellen wie „Adint“ (ADABASD/MaxDB Datenbank)<br />
und die „Archint“ oder „ArchiveLink“Schnittstelle<br />
(<strong>IBM</strong> CommonStore for SAP) im Böblinger Labor aufgegriffen<br />
und in Kombinationsprodukte zu ADSM integriert.<br />
190 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Hier eine kurze tabellarische Backint/ADSMProdukthistorie<br />
der Anfangszeit:<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
Die Idee für Backint/ADSM entstand im Sommer 1993<br />
aufgrund zahlreicher Kundenanfragen.<br />
September 1993 Meeting mit SAP – Backint-Schnittstelle<br />
Markteinführung als Service Offering 1994 – V1: Aufruf<br />
der ADSM-Funktionen durch commandline – dmsc calls,<br />
AIX, Oracle<br />
Erste Kundeninstallation April 1994 – ca. 10 Kunden<br />
bis Ende 1994<br />
Erweiterungen 1995 und 1996 – parallele Sessions,<br />
Portierung auf andere Betriebssysteme (DEC, HP, SNI,<br />
SUN), erster Kunde in USA auf HP-UX<br />
Backint/ADSM V2 – API-Schnittstelle zu ADSM als Ersatz<br />
der CmdLine-Implementierung 1996 und Windows/NT<br />
Support<br />
Erweiterungen 1997–1999 – Multithreading,<br />
parallel/alternate Paths und Servers<br />
Weltweit ca. 3000 Kunden Ende 1999<br />
Jahr 2000 Transfer zu Tivoli und Ankündigung als Mitglied<br />
der TSM-Produktfamilie als Tivoli Data Protection for<br />
SAP R/3, Administration Tools<br />
V3 – Objektorientierte Implementierung mit modularem<br />
Aufbau, „common code“ für Oracle und DB2, Support<br />
für DB2, Administration Assistant<br />
Medienkollektion (3,5“ Diskette, 8 mm Bandkassette, CD, Handbuch) zu<br />
Backint/ADSM, TDP for SAP R/3 und TDP for Hardware aus verschiedenen<br />
Jahren<br />
Untypisch für die sonstige ADSMProduktstruktur war<br />
die Tatsache, dass das Backint/ADSMAngebot für SAP R/3<br />
zwar eine Schlüssellösung war, aber bis 1999 nur als<br />
ServiceOffering angeboten wurde. Grund dafür war möglicherweise<br />
die Tatsache, dass SAP R/3 anfangs nur auf<br />
dem europäischen Markt erfolgreich war. Es ist der Kreativität<br />
der Entwickler und dem Marktengagement des Entwicklungsteams<br />
zu danken, dass dieses Modul zu den wichtigsten<br />
und wirtschaftlich erfolgreichsten ADSM/TSMKomponenten<br />
insgesamt wurde. Im Jahr 2000 wurde das Modul ein formales<br />
<strong>IBM</strong> TivoliProdukt und die Böblinger Abteilung eine offizielle<br />
TSMEntwicklungslokation.<br />
Oktober 1997 ADSM V3.1 –<br />
Erweiterungen für den unternehmensweiten Einsatz<br />
ADSM V3.1 Startbildschirm<br />
Die Version V3.1 von ADSM brachte die größte Menge<br />
an substanziellen funktionalen Neuerungen in der<br />
TSMGeschichte:<br />
•<br />
•<br />
•<br />
ADSM-Server auf Windows/NT und HP-UX V3.1<br />
HSM-Client für Solaris V2.5.1 mit Veritas-Filesystem und<br />
SGI IRIX mit XFS-Filesystem (Integration über die 1997<br />
veröffentlichte X/Open DMAPI-Schnittstelle)<br />
Bereitstellung der Backup-GUI auch für UNIX-Plattformen<br />
basierend auf der „Motiv“-Anwendungsarchitektur,<br />
grafischer Editor für die Options-Datei, „estimate“-Funktion,<br />
Fortschritts-Balken für Backup/Restore, Such- und<br />
Filteroptionen<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 191
<strong>IBM</strong> <strong>Storage</strong> Software<br />
Tivoli <strong>Storage</strong> Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
„point-in-time restore“-Option für die Clients<br />
„no-query-restore“-Protokoll, bei dem der ADSM-Server<br />
und nicht der Client die optimierte Zusammenstellung der<br />
zu restaurierenden Daten vornimmt<br />
„small file aggregation“ und „server file aggregation“ – die<br />
Zusammenfassung von kleinen Dateien in Transaktionsgruppen<br />
und das Speichern in logischen Aggregaten<br />
„Restartable Restores“ – Wiederaufsetzen auf der letzten<br />
„uncommitted transaction“<br />
Der Ersatz der generischen Admin-GUIs durch den Web-<br />
Admin-Client, was zur Oberflächenvereinheitlichung führte<br />
Web-Client als Alternative zur generischen Client-GUI –<br />
damit auch die Verfügbarkeit einer GUI für Netware-Clients<br />
und die Unterstützung von zentralen Help-Desks<br />
SQL-SELECT-Abfragen gegen die Datenbank (SQL’95<br />
Befehlssatz) und ODBC-Schnittstelle<br />
Erweiterung des ADSM-Schedulers zur Definition von<br />
einmaligen Aktionsplänen oder dem Ausführen von<br />
Betriebssystem-Befehlen<br />
„migdelay“ und „migcontinue“ für die planbare Migration<br />
von Daten auf verketteten <strong>Storage</strong>pools<br />
„Space trigger“ für die automatische Erweiterung von<br />
DB- und Log-Volumes der ADSM-Datenbank<br />
Speicherung von Scripts und Macros in der ADSM-<br />
Datenbank und Bereitstellung des „run“-Befehls zur<br />
Ausführung von Makros<br />
„Client Option-Sets“ zur Vereinheitlichung und zentralem<br />
Management von Client-Konfigurationen<br />
Server-to-Server-Kommunikation – Bereitstellung des<br />
„ADSM Configuration Managers“ zur einheitlichen<br />
Script-, Policy-, Schedule-Verwaltung zwischen multiplen<br />
ADSM-Servern und der Möglichkeit, „virtual volumes“ auf<br />
einem entfernten ADSM-Server zu definieren (Peer-to-Peer<br />
Disaster Protection Szenarien)<br />
„Overflow <strong>Storage</strong>pool“ und „single-drive reclamation“<br />
für Konfigurationen mit nur einem Magnetbandlaufwerk<br />
Event Logging, Reporting und Monitoring mit Schnittstellen<br />
u. a. zu SNMP-Managern, Tivoli NetView und Netview/MVS<br />
ADSMConnect Agents für:<br />
- DB2 für AIX, HP/UX, SINIX, Solaris, OS/2, Windows NT<br />
- Informix for AIX, HP/UX, Solaris<br />
- Lotus Notes für OS/2 und AIX<br />
- OnDemand für AIX<br />
Oracle 7 (EBU) und Oracle 8 (RMAN) für AIX und Solaris<br />
192 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
-<br />
-<br />
-<br />
-<br />
SAP mit Oracle für AIX, Digital UNIX, HP/UX, NCR UNIX,<br />
SINIX, Solaris, Windows NT auf Basis der Backint-<br />
Schnittstelle<br />
SAP mit ADABAS-D für AIX, HP/UX, SINIX, Solaris,<br />
Windows NT auf Basis der Adint-Schnittstelle<br />
(Service-Offering)<br />
MS-Exchange<br />
Die Breite der funktionalen Neuerungen und die Bereitstellung<br />
zukunftsweisender Technologien und Verfahren katapultierte<br />
<strong>IBM</strong> mit dem ADSM V3.1Produktportfolio in die<br />
Königsklasse der DatenmanagementAnwendungen, was<br />
der Markt und die Analysten auch entsprechend honorierten.<br />
Synergie durch neue Kombinationen aus <strong>IBM</strong><br />
Speicher-Hardware und ADSM<br />
Auszug aus einer internen Laudatio (1997) für „Outstanding<br />
Acomplishments“ in der <strong>IBM</strong> <strong>Storage</strong> <strong>System</strong>s Division:<br />
…A major new release of ADSM (Version 3) was made generally<br />
available in October 1997, with Research contributions that<br />
include a Web administrative interface, support for SQL queries<br />
of its internal database, point-in-time restore, and improved<br />
archive file management. In addition to its sales as a separate<br />
product, ADSM is a key building block in SSD‘s Network<br />
<strong>Storage</strong> Manager and Virtual Tape Server offerings,<br />
which are integrated hardware and software solutions.<br />
Die interessante Nachricht aus dieser Ehrung ist der Hinweis,<br />
dass die kurz zuvor begonnene „Seascape <strong>Storage</strong><br />
Building Block“Initiative der <strong>IBM</strong> <strong>Storage</strong> <strong>System</strong>s Division<br />
(die Wiederverwendung von bewährten <strong>IBM</strong> Komponenten<br />
als Entwicklungsbasis für komplexe Subsysteme) auch auf<br />
die Software ADSM ausgedehnt wurde. Aus dieser Initiative<br />
entstanden in der Folge erfolgreiche Kombinationsprodukte<br />
mit ADSM wie der <strong>IBM</strong> 3494 Virtual Tape Server (VTS), der<br />
<strong>IBM</strong> 3466 Network <strong>Storage</strong> Manager (NSM) und der <strong>IBM</strong><br />
3466 WebCache Manager (WCM). Parallel dazu gab es<br />
Kooperationen mit der <strong>IBM</strong> Softwaregroup in Form der<br />
Integration von ADSM mit <strong>IBM</strong> ContentManager, Content<br />
Manager OnDemand und <strong>IBM</strong> CommonStore als komplette<br />
ECMLösung auf Open <strong>System</strong>s.
• <strong>IBM</strong> 3494 Virtual Tape Server (die Hardware-Spezifi-<br />
kationen sind im Hardware-Kapitel „Die Epoche der RAID-<br />
<strong>System</strong>e“ beschrieben) – der VTS war die Realisierung<br />
einer großen Menge von virtuellen Bandlaufwerken und<br />
virtuellen Bandkassetten und wurde auf Basis einer<br />
mo difizierten AIX ADSM-Server/HSM-Client-Lösung in der<br />
B16-Kontrolleinheit implementiert. Nach außen repräsentierten<br />
sich 3490 Laufwerke und die 3490 virtuellen<br />
Volumes (typ. 800 MB) und wurden nach Füllung mit Hilfe<br />
der ADSM/HSM-Funktionen auf physische Laufwerke der<br />
<strong>IBM</strong> Library 3494 heraus migriert. Über das „Open <strong>System</strong><br />
Attachment Feature“ konnten auch ADSM-Server auf<br />
Open-<strong>System</strong>-Plattformen die Funktionen des VTS nutzen.<br />
Diese Lösung wurde jedoch seltener verwendet, weil im<br />
Open-<strong>System</strong> Umfeld der ADSM-Server seine ganzen<br />
Stärken zur Verwaltung der Speichermedien erst ausspielt,<br />
wenn er der alleinige Verwalter aller Speichereinheiten ist.<br />
Dieser Vorbehalt gilt heute grundsätzlich auch noch für<br />
solche Open <strong>System</strong> VTLs, die intern transparente<br />
Migration auf physische Laufwerke implementiert haben.<br />
• <strong>IBM</strong> 3466 Network <strong>Storage</strong> Manager (April 1998) –<br />
die „ADSM-in-the-box“-Lösung – heute würde man sie als<br />
„Appliance“ bezeichnen – war ein fertig vorkonfigurierter<br />
ADSM-Server auf Basis einer RS6000/H50 mit Diskpool auf<br />
SSA-Platten, die entweder als JBOD (bis zu 814 GB) oder<br />
im RAID5-Modus (bis zu 610 GB) vorkonfiguriert angeliefert<br />
wurde und nach der Hardware-Installation schon in<br />
kurzer Zeit die ersten Datensicherungen prozessieren<br />
VTS mit Open <strong>System</strong> Attachment Feature und nativen Anschlüssen an die 3494<br />
<strong>IBM</strong> 3466 Network <strong>Storage</strong> Manager<br />
konnte. Das erste Modell A00 hatte SCSI-Adapter integriert,<br />
an die man externe Tape-Libraries anschließen<br />
konnte, Modell A01 hatte eine eingebaute Library (entweder<br />
DLT oder Magstar MP 3570) und Modell B01 wurde<br />
mit <strong>IBM</strong> 3494/3590 geliefert. Nachfolgemodelle mit geänderten<br />
Technologiekomponenten hatten die Bezeichnungen<br />
C00, C10, C20, C30.<br />
• <strong>IBM</strong> 3466 WebCache Manager (September 1998) – diese<br />
Lösung war eine faszinierende Modifikation des NSM, die<br />
für die Spezialaufgabe als Internet Filetransfer Ressource<br />
konzipiert war. Filetransfer-Dienstleistungen über Webserver<br />
waren in dieser Zeit schon sehr gefragt, oftmals waren<br />
aber die Bandbreiten der öffentlichen Netzwerke zu den<br />
Web-Servern beschränkt (ISDN-Geschwindigkeit) und<br />
Online-Plattenspeicher war teuer.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 193
<strong>IBM</strong> <strong>Storage</strong> Software<br />
Tivoli <strong>Storage</strong> Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke<br />
Der WebCache Manager bestand – wie der NSM – aus<br />
einem RS6000/H50 Rechner mit ADSM-Server auf AIX,<br />
einem internen SSA-Plattenspeicher, dessen Dateisystem<br />
von einem AIX/HSM-Client verwaltet wurde und einer <strong>IBM</strong><br />
3494/3590 Bandlibrary.<br />
In der HSM-Implementierung von ADSM werden Stub-Files<br />
verwendet als Stellvertreter für die physisch migrierten<br />
Dateien. Üblicherweise sind die Stub-Files so groß wie ein<br />
Block des Dateisystems (4 k). Beim WCM änderte man<br />
diese Blockgröße auf einen Wert von 256 kB und größer.<br />
Falls nun ein Filetransfer einer sehr großen Datei über das<br />
Internet (ISDN) angefordert wurde, konnte sofort mit der<br />
Übertragung begonnen werden und der HSM-Agent<br />
begann im Hintergrund den Rest der Datei von Band nachzuladen.<br />
Das Nachladen geschah schneller, als die Stub-<br />
Datei zum Nutzer übertragen wurde, was dem Benutzer<br />
die Illusion vermittelte, jede noch so große Datei in unmittelbarem<br />
Zugriff zu haben.<br />
Den wirtschaftlichen Vorteil dieser Lösung beschreibt ein<br />
Auszug aus einem Artikel aus MONITOR Online 2/99 vom<br />
Kunden Deutsche Telekom AG (Quelle: http://www.monitor.<br />
co.at/index.cfm/storyid/101):<br />
… Der neue <strong>IBM</strong> 3466 Web Cache Manager ist Teil der von <strong>IBM</strong><br />
entwickelten Seascape-Speicherarchitektur und stellt eine Kombination<br />
aus führenden Speichertechnologien dar. Zu einer<br />
Gesamtlösung integriert wurden ein leistungsfähiger Speicher-<br />
Server, Platten- und Bandspeichermedien sowie die entsprechende<br />
Speichermanagement-Software. Durch eine einmalige<br />
Kombination aus hierarchisch eingesetzten Band- und Plattenspeichermedien<br />
bietet das Produkt mit bis zu zwei Terabyte ein<br />
Vielfaches der Speicherkapazität herkömmlicher Web-Proxies<br />
und kann auch sehr große Seiten und Dateien mit 10 MB und<br />
mehr zwischenspeichern. Da die Seiten und Dateien lokal vorgehalten<br />
werden, leistet der Web Cache Manager einen wichtigen<br />
Beitrag zur Verbesserung der Antwortzeiten im Internet […].<br />
[…] Unsere aktuellen Tests haben ergeben, dass wir mit dem<br />
Web Cache Manager mehr als die Hälfte des Web-Traffics in<br />
Bytes sparen können. Im Gegensatz zu anderen Web-Proxies<br />
arbeitet der Web Cache Manager mit einer Hierarchie zweier<br />
Speichermedien, die deutliche Kostenreduktionen auf der Hardware-Seite<br />
ermöglicht. Eingesetzt werden SSA-Platten (Serial<br />
<strong>Storage</strong> Architecture) und Magstar-Bänder. Diese Wahlmöglichkeit<br />
für die Speicherung von Daten bietet ISPs das bestmögliche<br />
Preis-Leistungs-Verhältnis und den größten derzeit erhältlichen<br />
Cache. Bandspeicher sind um das Fünf- bis Zehnfache preiswerter<br />
als Plattenspeicher und damit der kosteneffizienteste Weg,<br />
größere Web-Objekte mit einem Megabyte oder mehr zu speichern<br />
– denn rund 50 Prozent des Web-Verkehrs besteht mittlerweile aus<br />
Inhalten dieser Größenordnung…<br />
<strong>IBM</strong> ContentManager, ContentManager OnDemand,<br />
Commonstore, Admira – die effizienten Medienverwaltungs-Funktionen<br />
von ADSM wurden ab Mitte der 90er-<br />
Jahre auch als Backend für die <strong>IBM</strong> Archivanwendungen<br />
auf Open <strong>System</strong>s eingesetzt. Dazu wurde der ADSM-API<br />
Client verwendet, der Grundlage für alle Anwendungsintegrationen<br />
ist. In dieser Zeit wurden als Backendspeicher<br />
für ECM-Archivlösungen bevorzugt optische Medien mit<br />
WORM-Funktionen am ADSM-Server verwendet (z. B.<br />
<strong>IBM</strong> 3995).<br />
194 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
•
1999–2002: Aus ADSM wird Tivoli ADSM und schließlich<br />
Tivoli <strong>Storage</strong> Manager<br />
Im März 1996 übernahm <strong>IBM</strong> den <strong>System</strong>sManagement<br />
Entwickler Tivoli Software Inc. Diese Übernahme hatte<br />
Folgen für die weitere Produktheimat von ADSM innerhalb<br />
der <strong>IBM</strong>. Im Zeitraum Januar bis Oktober 1999 wurde Vertrieb,<br />
Marketing und Entwicklung des Produktes in die Verantwortung<br />
des Unternehmensbereichs <strong>IBM</strong> Tivoli übertragen und<br />
das Produkt zuerst in <strong>IBM</strong> Tivoli ADSM umbenannt (Januar<br />
1999). Im September 1999 erschien das Produkt dann als<br />
Tivoli <strong>Storage</strong> Manager Version 3.7 unter neuem Namen<br />
und das SafemanLogo veränderte sich.<br />
ADSM Safeman im Tivoli-Look<br />
Auszug aus der Presseankündigung zur Übertragung der<br />
Marketing und Vertriebsverantwortung für ADSM von der<br />
<strong>IBM</strong> <strong>Storage</strong> <strong>System</strong>s Division zu <strong>IBM</strong> Tivoli <strong>System</strong>s:<br />
Tivoli <strong>System</strong>s Announces Next-Generation Applications<br />
Management <strong>Storage</strong> Product Line<br />
Customers Gain ADSM Enhanced Benefits for <strong>Storage</strong><br />
Management<br />
SAN JOSE, Calif. – Dec. 2, 1998 – Tivoli <strong>System</strong>s Inc. and <strong>IBM</strong>’s<br />
<strong>Storage</strong> <strong>System</strong>s Division (SSD), both part of the <strong>IBM</strong><br />
company, announced today the transfer of ADSTAR Distributed<br />
<strong>Storage</strong> Manager (ADSM) to Tivoli. Responsibilities for the<br />
industry leading cross-platform application and data storage<br />
management solution will be transferred to Tivoli, effective<br />
January 1, 1999.<br />
With the transfer, customers will gain a broader, more tightly<br />
integrated application and data management solution for their<br />
enterprise storage management needs. The move is also designed<br />
to significantly increase <strong>IBM</strong>’s share of the growing distributed<br />
storage management market by combining the strength and<br />
technology of two of <strong>IBM</strong>’s most successful divisions. ADSM will<br />
also provide customers with next-generation application-centric<br />
storage management solutions, supporting more platforms and<br />
operating systems than any other product available on the<br />
market today.<br />
Today’s announcement underscores the importance of this new<br />
Tivoli business segment. The company plans to further enhance<br />
its enterprise solutions with significant investments in integrated<br />
storage solutions spanning mainframes to notebooks. Plans<br />
include additional investment in cross-platform storage area<br />
networks (SANs) and application-centric solutions.<br />
Die Versionen V3.7 (September 1999) und V4.1 (Juli 2000)<br />
folgten schnell aufeinander. Die „krumme“ Versionsnummer<br />
3.7 war vor allem verursacht durch die Namensänderung<br />
von Tivoli ADSM nach Tivoli <strong>Storage</strong> Manager, zusätzlich<br />
brachten diese Versionen einige wichtige funktionale Erweiterungen<br />
zur Version 3.1. Erwähnenswert ist vor allem der<br />
Einstieg in die Welt der <strong>Storage</strong> Area Networks durch die<br />
Bereitstellung von Tape Library Sharing, LANfreeDatentransfer<br />
und die SAN DatasharingOptionen, die man<br />
durch die SanergyProdukt akquisition von der Firma<br />
Mercury Computer <strong>System</strong>s erhielt.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 195
<strong>IBM</strong> <strong>Storage</strong> Software<br />
Tivoli <strong>Storage</strong> Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke<br />
Tivoli <strong>Storage</strong> Manager V3.7 – neuer Name und neues Logo bis V4.2<br />
•<br />
•<br />
•<br />
Verbesserungen im TSM-Server V3.7:<br />
-<br />
-<br />
-<br />
-<br />
-<br />
-<br />
No-Log Database Load & Audit<br />
Snapshot database backup<br />
SAN Tape Library Sharing zwischen TSM-Server Syste-<br />
men AIX, Windows 2000 und Solaris unter Verwendung<br />
von SAN Data Gateways für SCSI Libraries<br />
Secure Web Admin Proxy<br />
Einführung der Backupsets (Instant Archive und Rapid<br />
Restore)<br />
Windows 2000 mit Cluster-Support<br />
Verbesserungen bei den TSM-Clients V3.7:<br />
-<br />
-<br />
-<br />
-<br />
-<br />
-<br />
Subfile Backup für Windows-Clients<br />
Multi-Session Client (multithreaded backup)<br />
Windows 2000-Support mit Unterstützung von<br />
Cluster, <strong>System</strong> Objects, Active Directory, Journaling,<br />
Encryption, DFS<br />
Linux Clients auf Redhat, Suse, Caldera und TurboLinux<br />
LAN-free Client Transfer für den TSM API-Client<br />
(Application LAN-free)<br />
Client Encryption DES 56-bit<br />
Neue Produkte und Namensänderungen:<br />
-<br />
Umbenennung der ADSMConnect Agents in Tivoli<br />
Data Protection for …<br />
- Umbenennung der TSM/HSM UNIX Clients in Tivoli<br />
Space Manager<br />
- Tivoli Data Protection for <strong>IBM</strong> ESS und EMC<br />
Symmetrix für Oracle und SAP/Oracle<br />
- Anbindung an Tivoli Decision Support for <strong>Storage</strong><br />
Management Analysis (12/99) – Reporting und Analyse<br />
von TSM-Server-Operationen<br />
- Tivoli SANergy Filesharing (04/00) – LAN-free-to-disk<br />
Backup-Technologie als Resultat aus der Übernahme<br />
der „Shared <strong>Storage</strong> Unit“ von Mercury Computer<br />
<strong>System</strong>s<br />
- Tivoli Removable Media Manager (07/00)<br />
- Tivoli Data Protection for Workgroups (TDPfW) –<br />
Bare Machine Recovery für Windows NT, Windows 2000<br />
und Netware durch Entwicklungspartnerschaft (Juni<br />
1999) mit STAC Software über die Verwendung des<br />
STAC/Replica Moduls.<br />
- Tivoli Plus Module für TSM und TDPfW zur Integration<br />
in das Tivoli Framework (Reporting, Monitoring,<br />
Software-Verteilung)<br />
Die Wende vom 20. zum 21. Jahrhundert war in der<br />
Speichertechnologie gekennzeichnet durch die Einführung<br />
der FibreChannel <strong>Storage</strong> Area Networks für die offenen<br />
<strong>System</strong>e mit großen Konsequenzen hinsichtlich der<br />
„Sozialisierung“ von Ressourcen und der Basis für die<br />
heute gängigen Speichervirtualisierungstechniken. Die<br />
bewusst konservative Herangehensweise der TSMEntwickler<br />
bei der Integration dieser – für Open <strong>System</strong>s – neuen<br />
Technologie wurde entsprechend kritisch von der den Markt<br />
begleitenden Presse kommentiert.<br />
CW-Artikel (Auszüge) vom 17.9.1999 zur TSM V3.7-Ankündigung<br />
(Quelle: http://www.computerwoche.de/heftarchiv/1999/37/1088572/)<br />
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<br />
Der Seitenhieb des Artikels über „ADSM als Beigabe zu<br />
Bandlaufwerken“ war bezeichnend für den Zeitgeist, da der<br />
Redakteur komplette InfrastrukturLösungen offensichtlich<br />
nicht als erstrebenswertes Ziel für Unternehmen bewertete.<br />
Die <strong>IBM</strong> gewann allerdings mit diesen Kombinationsangeboten<br />
aus Hardware, Software und Services stetig Marktanteile<br />
hinzu. Diese Lösungen sind abgestimmt und getestet<br />
und bieten den Kunden Unterstützung im Fehlerfall aus<br />
einer Hand.<br />
Die behutsame Herangehensweise bei der Implementierung<br />
von SANTechniken im TSM wie LibrarySharing und LANfree<br />
Backup erwies sich als berechtigt, weil der Weg hin zu<br />
zuverlässigen SANUmgebungen durch die fehlende Kompatibilität<br />
von Infrastrukturkomponenten und Protokollen holperig<br />
war. Zudem waren die für das Verwalten und Überwachen<br />
von <strong>Storage</strong> Area Networks erforderlichen<br />
Managementfunktionen nur rudimentär verfügbar. Die<br />
notwendige Standardisierung (Bluefin, SMIS) wurde durch<br />
konkurrierende StandardisierungsKonsortien (FibreChannel<br />
Association, SNIA etc.) anfangs eher behindert als<br />
beschleunigt.<br />
Für TSM bedeuteten die neuen Möglichkeiten der <strong>Storage</strong><br />
Area Networks einen Quantensprung in der Realisierung<br />
von verteilten BackupInstanzen und DisasterProtection<br />
Lösungen. Allerdings beinhalteten manche Werbeaussagen<br />
zu SAN auch Heilsversprechen, die diese Technologie nicht<br />
einlösen konnte:<br />
„Ihr LAN-Backup dauert heute 8 Stunden, mit LAN-free wird<br />
er 2 Stunden dauern und mit Server-free sind Sie nach 20<br />
Minuten fertig.“ (Originalton aus einer Marketing-Veranstaltung<br />
dieser Zeit).<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 197
<strong>IBM</strong> <strong>Storage</strong> Software<br />
Tivoli <strong>Storage</strong> Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke<br />
Nicht ganz ernst gemeinte Abschlussfolie eines TSM4.1 Vortrags<br />
Die Sicherungsmethoden LANfree und Serverfree waren<br />
die beherrschenden Themen in dieser Zeit. Wie bei Modethemen<br />
üblich, wurde in Veröffentlichungen häufig eher<br />
plakativ als präzise mit den Einsatzmöglichkeiten der neuen<br />
Technologien umgegangen.<br />
Der am häufigsten beworbene ServerfreeAnsatz war die<br />
Umsetzung des 1996 entwickelten SCSI3 T10 extended<br />
copy/3rd party copy Standards (auch unter SNIA 143R1<br />
standardisiert).<br />
Hier war definiert, wie man innerhalb von SANInfrastruktur<br />
komponenten (z. B. SAN Data Gateways erweitert um<br />
MicrocodeFunktionen) eine „data mover“Instanz abbilden<br />
konnte, die in der Lage war, Daten im SAN direkt von Disk<br />
nach Tape zu kopieren, ohne den „zeitraubenden“ Umweg<br />
über den ApplikationsServer nehmen zu müssen.<br />
Diese Lösung war nur realisierbar durch Einhaltung einer<br />
Reihe von Rahmenbedingungen und setzte eine Kette T10kompatibler<br />
und getesteter Hardware und SoftwareKomponenten<br />
voraus. Die Anzahl der Hersteller für „data mover“<br />
Instanzen (SAN Data Gateways) war begrenzt u. a. mit den<br />
Herstellern Pathlight und Crossroads. Es fehlte zudem<br />
die Möglichkeit, mit diesem Verfahren Einzeldateien zu<br />
sichern oder zu rekonstruieren, weil der Kopiervorgang eine<br />
Volume BlockLevel Operation war. Die notwendige Öffnung<br />
der FilesystemHersteller blieb aus, die nötig gewesen wäre,<br />
um über standardisierte APISchnittstellen die logischen<br />
Dateien auf die physischen Blöcke abbilden zu können<br />
(LBM = Logical Block Mapping List). Für VolumeDumps<br />
brauchte man die LBMs nicht. Legato unternahm mit dem<br />
Produkt Celestra einen Versuch, dies selbst über ReengineeringVerfahren<br />
umzusetzen, scheiterte dann aber mittelfristig<br />
am notwendigen Pflegeaufwand durch mangelhaft<br />
publizierte Änderungen der FilesystemHersteller. Andere<br />
Ansätze wie die VertexInitiative von Veritas versuchten<br />
das Problem auf der Basis ihres eigenen proprietären<br />
Volume Managers bzw. Filesystems zu lösen.<br />
Das Thema SCSI3 T10 beschäftigte die ITWelt einige Jahre<br />
und war offensichtlich für die Marktpräsenz so wichtig, dass<br />
TSM mit der Version V5.1. eine entsprechende Implementierung<br />
für Windows 2000Client, <strong>IBM</strong> SAN Data Gateway 2108<br />
(Pathlight) und TSMServer auf Windows 2000 verfügbar<br />
machte (das TSM DemoHighlight auf der CeBIT 2002).<br />
Heute definieren sich „Application Serverfree“Lösungen<br />
über andere technische Möglichkeiten, wobei nach wie vor<br />
das Prinzip von „workload offloading“ das Herz des Verfahrens<br />
ist, wie z. B. das „Copy Backup“Verfahren DisktoDisk<br />
über die SnapshotFunktionen von Betriebssystemen, Filesystemen,<br />
Plattensubsystemen oder ProxyLösungen wie<br />
VMware Consolidated Backup.<br />
Kritisch bei allen OnlineBackupLösungen, die über Ersatzinstanzen<br />
arbeiten (Serverfree und Copy Backup), ist die<br />
notwendige Anwendungsintegration zur Sicherstellung von<br />
Datenkonsistenz beim Backup. Dies muss entweder über<br />
Skriptbasierte Verfahren geschehen oder über bereitgestellte<br />
Betriebssystem oder Applikationsschnittstellen, z. B.<br />
Microsoft Volume Shadowcopy Services oder SAP „Splitint“.<br />
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)<br />
TSM V4.2 erschien im Juni 2001 mit den Neuerungen:<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
Die Erweiterung der LAN-free-Unterstützung für weitere<br />
Plattformen und die Palette der TDP-Clients<br />
Journal-based Backup für Windows-Clients<br />
zLinux-Client, USS-Client (zOS Unix <strong>System</strong> Services)<br />
Tivoli Data Protection for NDMP (filer-to-tape)<br />
Tivoli Data Protection for Websphere Application Server<br />
TSM Management Console als MMC Plugin<br />
Unicode Support für Windows NT und 2000<br />
Die Jahre 2000 bis 2003 waren gekennzeichnet durch eine<br />
wachsende Anzahl von Entwicklungspartnerschaften und<br />
ResellerAbkommen zwischen <strong>IBM</strong> Tivoli mit unabhängigen<br />
Softwarehäusern, die KomplementärSoftware zu TSM entwickelt<br />
hatten. Hier die wichtigsten Kooperationen und Produkte:<br />
• „The Kernel Group“ (TKG) – Das „Bare Metal Restore“-<br />
Produkt von TKG wurde als „Tivoli Bare Metal Recovery<br />
Manager“ bzw. als „Tivoli Disaster Recovery for Servers“<br />
ab 2000 von <strong>IBM</strong> weiterverkauft. Es handelte sich dabei<br />
um Software, die die Anforderungen von Betriebssystem-<br />
Rekonstruktion umsetzte und dabei auf den gesicherten<br />
Daten des TSM-Servers aufsetzte. Unterstützt waren die<br />
Betriebssysteme AIX, HP-UX, Solaris, Windows NT und<br />
später Windows 2000 und Novell Netware. Im Januar 2002<br />
wurde TKG von Veritas gekauft, der TSM-Support wurde<br />
von Veritas im Juni 2003 gekündigt.<br />
• Cristie PC-BaX und später Cristie Bare Machine<br />
Re covery (CBMR) Juni 2003 – Die Partnerschaft und das<br />
Produkt, das die Funktionslücke zur Betriebssystemrekonstruktion<br />
im TSM-Portfolio wieder schloss und bis heute als<br />
CBMR und TBMR (Tivoli Bare Machine Recovery – Rekonstruktion<br />
von Betriebssystem allein durch Verwendung der<br />
im TSM gespeicherten Daten) wichtiger Baustein einer<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 199
<strong>IBM</strong> <strong>Storage</strong> Software<br />
Tivoli <strong>Storage</strong> Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke<br />
ganzheitlichen Datensicherungsstrategie in der<br />
TSM-Architektur ist für die Betriebssysteme Windows<br />
2003/2008, Linux, Solaris und HP-UX.<br />
• St. Bernhard Open File Manager (OFM) – Die Zusatzlösung,<br />
die notwendig war, um Filesysteme (Windows, Netware)<br />
oder Anwendungen aus Filesystemsicht (Exchange,<br />
Groupwise etc.) konsistent online sichern zu können.<br />
• Gresham Computing plc. Enterprise DistribuTape<br />
(EDT) – vormals Open Microsystems (Übernahme durch<br />
Gresham 1998) – Die Anbindung von ACSLS-Tape-Libraries<br />
(<strong>Storage</strong>Tek und andere) an das TSM External Library<br />
Management (ELM) Interface. Der Reseller-Vertrag wurde<br />
im Juni 2001 geschlossen.<br />
• Open Technology Group (OTG) – DiskXtender – Die<br />
Windows 2000 HSM-Lösung für TSM. Die Kooperation<br />
zwischen <strong>IBM</strong> und OTG begann im Jahr 2000 und endete<br />
im Dezember 2004, weil Legato im Juni 2002 OTG übernommen<br />
hatte und zwischenzeitlich von EMC gekauft<br />
worden war.<br />
• Monitoring und Reporting-Lösungen für TSM-Umgebungen<br />
– Servergraph Professional, JamoDat TSMManager,<br />
STORServer Manager<br />
TSM-Client für PalmOS in V4.2<br />
(Prototyp – war nie ein offizielles Produkt)<br />
2002–2008 TSM V5.x – die Ära von Server-Konsolidierung,<br />
Virtualisierung und NAS<br />
Ab der Version V5.1 wurde die Lizenzstruktur des TSM<br />
geändert. Dazu wurden die vorher verwendeten Umgebungslizenzen<br />
(Desktop Environment, Workstation Environment,<br />
Extended Device Support Module) zugunsten eines<br />
Prozessorbasierten Preismodells ersetzt. Dazu definierte<br />
man zwei Basislizenzmodelle für eine TSMUmgebung:<br />
Tivoli <strong>Storage</strong> Manager mit Tape-Library bis zu 2 Bandlaufwerken<br />
und 40 Kassetten<br />
TSM Extended Edition für größere Konfigurationen inklusive<br />
TSM Disaster Recovery Manager und NDMP Support als<br />
Ersatz für die kostenpflichtigen Module Extended Device<br />
Support, TDP for NDMP und DRM.<br />
200 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
•<br />
•<br />
Die Versionen V5.1 (April 2002), V5.1.5 (Oktober 2002) und<br />
V5.2 (Oktober 2003) erweiterten den TSMFunktionsumfang<br />
um folgende Schwerpunkte:<br />
TSM V5.1 – April 2002<br />
•<br />
Server-free Data Movement auf Basis der SCSI3 T10 Proto-<br />
kollimplementierung, Windows 2000-Client full-volume<br />
Backup/Restore<br />
• Simultaneous Writes to Copy <strong>Storage</strong> Pools – synchrones<br />
Schreiben von Auslagerungskopien direkt beim Backup<br />
• Multithreaded Restore – Restauration über mehrere parallele<br />
Sessions, sofern der Backup auch multithreaded auf<br />
unterschiedliche Backup-Volumes gespeichert war<br />
• Windows 2000 Image Backup und Open File Backup mit<br />
Hilfe des TSM Logical Volume Snapshot Agents (LVSA)<br />
• ”MOVE NODEDATA“<br />
zum selektiven Verschieben von<br />
Sicherungsdaten eines Clients von einem <strong>Storage</strong>pool<br />
zu einem anderen<br />
• CRC (Cyclic Redundancy Check) – Quersummen-Prüfung<br />
für TSM-Client und TSM-Server zur Sicherstellung von<br />
konsistentem Datentransfer über Netzwerke (LAN, WAN<br />
und SAN)
•<br />
•<br />
Image Backup für Filesystem und Raw-Devices von<br />
AIX, HP-UX und Solaris<br />
Neuorganisation der TSM Application Clients in:<br />
- TSM for Databases (Oracle, MS-SQL, Informix)<br />
- TSM for Mail (Exchange, Domino)<br />
- TSM for ERP (SAP/Oracle und SAP/DB2)<br />
- TSM for Application Servers (Websphere)<br />
- TSM for Hardware (Copy Backup für Oracle, DB2<br />
und SAP/Oracle, SAP/DB2)<br />
TSM V5.1.5 – Oktober 2002<br />
• Volle Linux/x86-Unterstützung inkl. TSM-Server, LAN-free,<br />
NDMP und Domino-Client<br />
• Server-to-Server Import/Export – die gravierende Vereinfachung<br />
von <strong>System</strong>migration und Teilungsprozessen der<br />
TSM-Datenbank zur verbesserten horizontalen Skalierung<br />
• Exchange Single Mailbox Restore über Skript-Integration<br />
in das Xmerge-Utility von Microsoft<br />
• TSM-Server auf OS/400 PASE<br />
TSM V5.2 – Oktober 2003 und V5.2.2 – Dezember 2003<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
TSM-Server auf zLinux<br />
TSM zOS LAN-free<br />
Flashback-Funktionen für TSM for ERP/DB2 zusammen<br />
mit TSM for Hardware<br />
Verbesserte Firewall-Unterstützung (server initiated<br />
sessions, single port communication)<br />
SAN-Einheiten-Erkennung für Windows 2000 TSM-Server<br />
NAS-Umgebungen: File-Level Restore durch NDMP Table<br />
of Contents (TOC) und EMC Celerra-Support<br />
Mixed-Media Libraries<br />
•<br />
•<br />
•<br />
•<br />
TSM for <strong>System</strong> Backup and Recovery (Betriebssystemrekonstruktion<br />
für AIX auf Basis der <strong>IBM</strong> Service-Lösung<br />
Sysback6000)<br />
Erweiterung der Aufbewahrungszeit für archivierte Daten<br />
von 9.999 Tagen (ca. 27 Jahre) auf 30.000 Tage (ca. 83<br />
Jahre) ohne Abhängigkeit zum Jahr-2038 Problem – auch<br />
„The Friday 13th Bug“ genannt – (http://www.2038bug.<br />
com/index.html).<br />
Tivoli <strong>Storage</strong> Manager for Data Retention – die Software-<br />
WORM-Variante des TSM für den Einsatz bei revisionssicherer<br />
Archivierung<br />
TSM-Unterstützung für EMC Centera und NetApp<br />
Snaplock (TSM for DR)<br />
Das TSM-Logo der Versionen V5.1 bis V5.3<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 201
<strong>IBM</strong> <strong>Storage</strong> Software<br />
Tivoli <strong>Storage</strong> Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke<br />
Tivoli <strong>Storage</strong> Manager for Data Retention und DR450/550<br />
(Oktober 2003)<br />
Mit TSM for Data Retention wurde eine spezielle Variante<br />
des TSM bereitgestellt für die revisionssichere Archivierung<br />
von Daten. Diese Software hat besondere Bedeutung auch<br />
für die <strong>IBM</strong> Speicherlandschaft, weil sie SoftwareBasis ist<br />
für die ArchivBackendLösungen DR450, DR550 und <strong>IBM</strong><br />
Integrated Archive (Oktober 2009).<br />
Hardwaredetails zur DR450/DR550 und eine Beschreibung<br />
der rechtlichen Rahmenaspekte sind im HWKapitel „Die<br />
Epoche der Multiplattform<strong>System</strong>e und des FibreChannel<br />
SAN und NAS“ ausführlich beschrieben.<br />
Der Grund für die Entwicklung solcher Archiv Backendlösungen<br />
war einerseits die mangelhafte Zukunftsperspektive<br />
der optischen Speichermedien generell, die bis dahin<br />
die maßgebliche Technologie für die gesetzeskonforme<br />
Langzeitarchivierung waren, andererseits die verschärften<br />
gesetzlichen Regularien, die nach einigen Fällen von Bilanzfälschung<br />
vor allem in USA erlassen wurden (u. a. als<br />
Antwort auf die ENRON/WorldcomPleite).<br />
Die Faszination von TSM for Data Retention besteht in der<br />
simplen Funktion, dass man unter seiner Kontrolle wieder<br />
beschreibbare Datenträger (Magnetplatte, Magnetband) im<br />
SoftwareWORMModus (writeoncereadmany) betreiben<br />
und zusätzlich neue physische WORMMedien wie WORM<br />
Tapes (<strong>IBM</strong> 3592, LTO3 und LTO4) nutzen kann. WORM<br />
bedeutet das Verhindern von Überschreiben und das<br />
Sicherstellen von Löschen erst nach Ablauf vorgegebener<br />
Sperrfristen.<br />
Die Idee dazu entstand aus der ArchivFunktion, die<br />
TSM schon immer parallel zum Backup angeboten hat. Im<br />
„Archiv“Modus überschreibt TSM keine Daten, sondern<br />
schreibt jedes Objekt neu, auch wenn das Objekt mit all seinem<br />
Inhalt und Attributen schon einmal gespeichert wurde.<br />
Gleichnamige Objekte unterscheiden sich über eine eindeutige<br />
ObjektId und durch Datum/Uhrzeit der Speicherung<br />
und sind darüber auch wieder eindeutig zugreifbar. Die<br />
prinzipielle Arbeitsweise des „ArchiveMode“ entspricht also<br />
der ersten Forderung von revisionssicherer Archivierung,<br />
dem Verhindern von „Überschreiben“. Die zweite Kardinalforderung<br />
ist die Sicherstellung von Löschoperationen nur<br />
unter Kontrolle der steuernden Archivanwendung, die die<br />
Sperrfristen vorgibt und steuert. Dazu wurde im TSM ein<br />
zusätzliches „retention“Verfahren implementiert, das es<br />
ermöglicht, die traditionelle Verfallssteuerung des TSM<br />
(„chronological retention“) alternativ durch eine von der<br />
Archivanwendung kontrollierte mehrstufige Verfallssteuerung<br />
zu ersetzen („eventbased retention“ und „deletion hold/<br />
release“). Der Löschschutz im TSM for Data Retention wird<br />
zusätzlich durch Maßnahmen komplettiert, die es verhindern,<br />
dass der TSMAdministrator Archivdatenträger löschen<br />
oder die Bindung von Aufbewahrungsregeln an Objekte<br />
verändern kann.<br />
Schnittstelle für die Datenübergabe ins TSM for Data Retention<br />
ist entweder der ArchiveClient oder die Archivfunktion der<br />
TSMAPISchnittstelle ab V5.2.2, die im Laufe der folgenden<br />
Jahre in eine Vielzahl von DMS und Archivanwendungen<br />
innerhalb der <strong>IBM</strong> (<strong>IBM</strong> ContentManager, <strong>IBM</strong> Commonstore,<br />
<strong>IBM</strong> Filenet und <strong>IBM</strong> Optim) und in Lösungen von<br />
unabhängigen Softwarehäusern eingebaut wurde (u.a.<br />
OpenText, SER, Saperion, d.velop, Easy, Ceyoniq, Waters,<br />
PBS und viele andere).<br />
Logo für die Tivoli-Schnittstellen-Zertifizierung von externen Anwendungen<br />
Im Jahr 2005 wurde „Tivoli <strong>Storage</strong> Manager for Data<br />
Retention“ in „<strong>IBM</strong> <strong>System</strong> <strong>Storage</strong> Archive Manager“<br />
umbenannt, vor allem wegen des geänderten Lizenzierungsverfahrens<br />
(TBLizenz auf Basis des verwalteten<br />
Archivdatenbestandes).<br />
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<br />
folgenden wichtigen Neuerungen:<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
Einführung der Integrated Service Console als Resultat<br />
einer allgemeinen Oberflächenkonsolidierung bei Tivoli-<br />
Produkten für die grafische Administration<br />
Erweiterungen für tagesgenaue Definitionen im TSM-<br />
Scheduler<br />
Multiple Prozesse bei Reclamation und Migration<br />
Durchsatzverbesserungen im TSM File-Pool<br />
Group-Collocation zur verbesserten Nutzung hochkapazitiver<br />
Bandkassetten<br />
Automatische SAN-Device Erkennung und Re-Konfi guration<br />
Generische Unterstützung von ACSLS-Libraries ohne<br />
externe Software<br />
Segmentieren von NDMP-Backups, NDMP-Dumps<br />
von Snapshots oder Quota-Trees bei NetApp NAS<br />
Neue Verschlüsselungsmethode für Clients AES 128-bit<br />
Einführung des Proxy-Node Supports für die Unterstützung<br />
von virtualisierten <strong>System</strong>-Umgebungen<br />
Windows Open File Support und online Image Support<br />
über den TSM Logical Volume Snapshot Agent (LVSA)<br />
Unterstützung von TSM-Clients in VMware-Gastsystemen<br />
und Unterstützung des Linux B/A-Clients für die Sicherung<br />
von ESX/GSX<br />
Administration Assistant für TSM for mySAP<br />
TSM HSM for Windows – als Resultat eine Firmenkooperation<br />
mit der Intercope GmbH in Hamburg (OpenStore for<br />
File Server OS4FS)<br />
Mit der Version TSM 5.4 (Januar 2006) änderten sich die<br />
zugesagten Wartungsintervalle pro Release von 3 Jahren<br />
auf 5 Jahre, was solchen TSMKunden sehr entgegenkommt,<br />
die Aufrüstungen längerfristig planen. Die<br />
wichtigsten funktionalen Neuerungen:<br />
•<br />
•<br />
•<br />
Unterstützung von TS1120 Encryption und die Implementierung<br />
des Encryption Managers im TSM für den Encryption-Modus<br />
„application managed“<br />
Implementierung der NDMP-Copy-Funktion zur Erstellung<br />
von Kopien für NDMP-Dump-Tapes<br />
NDMP „Filer-to-Server“-Modus – NAS Filer schickt seine<br />
Volume Dumps über LAN an den TSM-Server, dort können<br />
die Daten im TSM-Format auf allen Speicherhierarchiestufen<br />
gespeichert werden inklusive der Erstellung von<br />
Copypool-Tapes.<br />
•<br />
•<br />
•<br />
•<br />
„Data Shredding“-Funktion für Diskpools – das mehrfache<br />
Überschreiben von gelöschten Daten mit zufälligen HEX-<br />
Werten<br />
Backupset-Verbesserungen (Point-in-Time, Kombination<br />
mit Image Backup, Einzeldatei-Restauration über TOC,<br />
multiple Backupsets auf gleichem Medium)<br />
„Active Datapool“ – die Möglichkeit, das Abbild der letzten<br />
Full-Backups auf einem separaten Speicherpool zu erstellen<br />
oder zu bevorraten<br />
TSM for Copy Services – Nutzung der Microsoft Volume<br />
Shadowcopy Services für die konsistente Snapshot-Sicherung<br />
von Exchange und MS-SQL inklusive der „Instant<br />
Restore“-Funktion bei der Nutzung von <strong>IBM</strong> Diskspeicher<br />
(<strong>IBM</strong> DS6000/DS8000) oder <strong>IBM</strong> SAN Volume Controller.<br />
TSM V5.5 wurde im November 2007 angekündigt, dies war<br />
das letzte Release mit der Nutzung der proprietären Datenbank.<br />
Die wichtigsten Neuerungen:<br />
• Encryption-Key-Management durch den TSM-Server,<br />
dadurch auch die Möglichkeit, dass Anwendungs-Clients<br />
(TSM for… Clients) ihre Daten verschlüsselt über Netzwerke<br />
schicken können, ohne dass die Verwaltung der<br />
Keys von der Anwendung unterstützt sein muss<br />
• Verbesserungen bei sequenziellen Diskpools (u. a. multithreaded<br />
read im gleichen Volume)<br />
• Import- und Export-Prozesse sind wiederanlauffähig<br />
• Integration des VMware „VCB Integration Moduls“ in<br />
den Windows B/A-Client zur Unterstützung von VMware<br />
Consolidated Backup VCB<br />
• TSM for Advanced Copy Services – Erweiterungen in der<br />
Einheitenunterstützung und Nutzung für DB2 Snapshots<br />
• NetApp „Snapmirror to tape“-Unterstützung als alternatives<br />
Protokoll zu NDMP mit verbesserter Skalierung<br />
TSM B/A Client Logo V5.4 und V5.5<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 203
<strong>IBM</strong> <strong>Storage</strong> Software<br />
Tivoli <strong>Storage</strong> Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke<br />
2005-2008 Lösungen für Endbenutzer, kleine mittelständische<br />
Betriebe und Niederlassungen von Großkunden<br />
Tivoli Continuous Data Protection CDP (2005) war die<br />
Produktumsetzung des intern in der <strong>IBM</strong> schon seit 2004<br />
verfügbaren Werkzeugs „Vitalfile“ mit der Zielgruppe der<br />
LaptopBenutzer im Unternehmen. Interessant vor allem für<br />
solche Benutzer, die nur sporadisch Zugang zu Sicherungsdiensten<br />
ihres Unternehmens haben.<br />
CDP führte eine revolutionäre Neuerung in der Datensicherung<br />
ein, die Sicherung von geänderten Dateien direkt beim<br />
Abspeichern (continuous data protection). Zielmedium für<br />
die Datenkopie ist zuerst lokaler Speicher am Laptop wie<br />
z. B. ein anderes logisches Laufwerk der partitionierten Festplatte<br />
oder lokal angeschlossener externer Speicher (USB).<br />
Zusätzlich kann man eine zweite Kopie auf ein entferntes<br />
Netzwerklaufwerk oder ins TSM schreiben, wobei CDP den<br />
Datentransfer so lange versucht, bis eine gültige Netzwerkverbindung<br />
aufgebaut ist.<br />
Ende 2009 wurde CDP umbenannt in TSM Fastback for<br />
Workstations und um zentrale Konfigurationsfunktionen<br />
erweitert.<br />
TSM Express wurde im März 2006 angekündigt als die<br />
Einstiegslösung für TSM bei kleinen <strong>System</strong>umgebungen.<br />
Die Modifikationen zum StandardTSM waren:<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
Datensicherung nur auf Disk<br />
Optionaler Anschluss von Magnetband für die Erzeugung<br />
von auslagerungsfähigen Kopien über TSM-Backupsets<br />
für Filedaten und Exchange/SQL<br />
Sehr einfache Installation und Bedienung<br />
Integriertes Reporting<br />
Unterstützung ausschließlich für Windows-Umgebungen<br />
mit zwei spezifischen Anwendungsagenten für Exchange<br />
und MS-SQL<br />
Migrations-Option zum Standard-TSM<br />
TSM Fastback entstammt der Firmenakquisition der<br />
amerikanisch/israelischen Firma FilesX Inc. durch <strong>IBM</strong> im<br />
April 2008. TSM Fastback löst TSM Express ab und stellt<br />
ganz neue Funktionen für die Sicherung von kleinen<br />
<strong>System</strong>umgebungen bereit – den ausschließlichen Backup<br />
von Fileservern oder Anwendungsservern über Snapshot<br />
Verfahren. Durch die Implementierung eines Snapshot<br />
FilterTreibers auf dem Client ist es möglich, alle Datensicherungen<br />
über Snapshots umzusetzen, die – ganz in der<br />
Tradition des TSM – rein blockinkrementell ablaufen. Die<br />
wichtigsten Eigenschaften:<br />
Disk-only Backup auf dem lokalen Fastback-Sicherungsserver<br />
Online-Snapshots für Fileserver und Anwendungsserver<br />
durch die Verwendung von bereitgestellten Konsistenzfunktionen<br />
Windows und Linux-Clients (ab Anfang 2010)<br />
Die Möglichkeit, jeden gespeicherten Snapshot entweder<br />
als komplettes Volume zu restaurieren oder sich den<br />
Snapshot als Netzwerklaufwerk verfügbar zu machen, um<br />
selektiv Einzeldateien zurückzuschreiben.<br />
Item-Level Recovery/Single Mailbox Recovery von Microsoft<br />
Exchange-Objekten<br />
Wiederherstellung der Betriebssystem-Partition aus den<br />
Snapshots durch Verwendung einer Lade-CD<br />
Replikation von selektiven Snapshots von vielen entfernten<br />
Fastback-Servern auf einen zentralen Fastback-Server<br />
über WAN-Leitungen<br />
Anbindung des zentralen Fastback-Servers an den zentralen<br />
TSM-Server zur Erstellung von Auslagerungsbändern.<br />
204 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
April 2009 –TSM V6.1 mit neuer Datenbankarchitektur<br />
und Deduplizierung<br />
Fast 20 Jahre hatte die DatenbankArchitektur auf Basis der<br />
B+ Tree Technologie Bestand. Die steigenden Sicherungsvolumina<br />
und vor allem die steigende Anzahl von SicherungsObjekten<br />
machten eine Architekturänderung nötig,<br />
um besser zu skalieren und die OnlineVerfügbarkeit den<br />
erhöhten Anforderungen anzupassen. Deshalb wurde in<br />
V6.1 DB2 als Datenbanktechnologie für die Verwaltung der<br />
TSMMetadaten eingeführt.<br />
Die DB2-Technologie erfüllt einerseits die erhöhten Skalier<br />
barkeitsanforderungen moderner Umgebungen, ermöglicht<br />
andererseits die Nutzung neuer Verfahren wie die online<br />
Konsistenzprüfung, online Reorganisation und umfassende<br />
IndexGenerierung und eröffnet der TSMArchitektur zusätzliche<br />
Freiheitsgrade für zukünftige Erweiterungen.
Die Portierung auf die neue Datenbanktechnologie wurde<br />
in enger Zusammenarbeit mit dem DB2Labor in Toronto<br />
geplant und umgesetzt und den Entwicklern gelang es, alle<br />
spezifischen Funktionen, die technologisch an die ursprüngliche<br />
Datenbank gebunden waren, auch in die neue DB2<br />
Umgebung zu portieren.<br />
Deduplizierung ist nach Meinung von selbst ernannten<br />
Brachenkennern „…the biggest thing in backup since the<br />
incremental.“ (W. Curtis Preston im Februar 2009 in „TSM<br />
6,1, dedupe & DB2“ auf www.backupcentral.com). Bei der<br />
Deduplizierung handelt es sich im Grunde genommen nur<br />
um ein neues Verfahren von Datenkompression mit der<br />
Eigenschaft, Datenobjekte in Blöcke zu zerlegen und über<br />
diese Blöcke Vergleichsoperationen laufen zu lassen, mit<br />
dem ZielRedundanzen zu erkennen. Redundante Blöcke<br />
werden in den Metadaten referenziert und dann gelöscht.<br />
Die Menge der gelöschten redundanten Blöcke ist dann<br />
das Maß für die Speicherersparnis (= Kompressionsfaktor =<br />
DedupRatio).<br />
TSM V6.1 neues Layout des B/A-Clients<br />
TSM V6.1 stellt Deduplizierungsfunktionen optional für<br />
seine Diskpools zu Verfügung und arbeitet asynchron, d. h.,<br />
die Sicherungsdaten werden zuerst unmodifiziert gespeichert,<br />
dann in Folgeprozessen analysiert und dedupliziert. Es ist<br />
geplant, das Verfahren in Folgereleases von TSM V6.1 auch<br />
auf die TSMClients zu erweitern, was einmal die Berechnungslast<br />
verteilt und vor allem die Datenmengen reduziert,<br />
die von den Clients z. B. über öffentliche Netze verschickt<br />
werden müssen. Das Verfahren ist höchst effizient, weil die<br />
Vergleichsoperationen auf dem zentralen TSM Sicherungsserver<br />
stattfinden und die Datenmenge aller Clients als<br />
Basis für die Redundanzerkennung verwendet wird.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 205
<strong>IBM</strong> <strong>Storage</strong> Software<br />
Tivoli <strong>Storage</strong> Manager – die Erfolgsgeschichte der ersten 20 Jahre – Klemens Poschke<br />
Zusammenfassung und Schlusswort:<br />
Hier die historische Entwicklung von Tivoli <strong>Storage</strong> Manager<br />
von 1990 bis 2009 nochmals in Kurzform:<br />
• 1. November 1990 – WDSF/VM R1 mit Clients auf OS/2,<br />
DOS und AIX<br />
• November 1991 – WDSF/VM R1 Enhanced – Sun,<br />
Apple Clients<br />
• Mai 1992 – DFDSM/VM und DFDSM/MVS<br />
• 29. Juli 1993 und 16. November 1993 – <strong>IBM</strong> ADSTAR<br />
Distributed <strong>Storage</strong> Manager V1.1 und V1.2 mit OS/2<br />
und AIX als Serverplattformen<br />
• Frühjahr 1995 – ADSM V2.1 – OS/400, VSE, Sun und<br />
HP als Plattformen für ADSM-Server und eine Vielzahl von<br />
unterstützten Client-Plattformen, DRM und Copypool<br />
• Oktober 1997 – ADSM V3.1 – ADSM-Server auf<br />
Windows NT, Server-to-Server Kommunikation, Web<br />
Admin-GUI, Web-GUI für Clients, SQL-Queries und<br />
Integration in <strong>System</strong>s Management Anwendungen<br />
• Januar 1999 – <strong>IBM</strong> ADSM Marketing wechselt zu Tivoli,<br />
neuer Name Tivoli ADSM<br />
• September 1999 – Tivoli <strong>Storage</strong> Manager (TSM) V3.7<br />
ersetzt Tivoli ADSM, LAN-free, Tape-Library Sharing<br />
• Juli 2000 – TSM V4.1 – subfile backup, Linux Clients<br />
und Windows 2000 Support<br />
• Juni 2001 – TSM V4.2 – Journal-based backup, LAN-free<br />
backup für den Backup-Archive Client, NDMP und<br />
SANergy<br />
• März 2002 – TSM V5.1 – Windows Server-free Backup und<br />
online Image Backup/Open File Backup für Windows 2000<br />
mit LVSA<br />
• Oktober 2002 – TSM V5.1.5 – Linux/x86 und<br />
Windows 2000 als Server, Server-to-Server Import/Export,<br />
TSM auf OS/400 PASE<br />
• Juli 2003 – TSM V5.2 – TSM-Server auf zLinux, TSM/zOS<br />
LAN-free, TSM for Data Retention, NDMP TOC<br />
• Dezember 2004 – TSM V5.3 – Einführung ISC als<br />
Admin-Konsole, AES128-bit, Proxy-Node Support,<br />
Group Collocation<br />
• Januar 2006 – TSM V5.4 – NDMP Filer-to-Server,<br />
Data-Shredding, Active Datapool, TSM for Copy Services<br />
• November 2007 – TSM V5.5 – VMware Consolidated<br />
Backup<br />
• Juli 2008 – TSM Fastback<br />
• April 2009 – TSM V6.1 – DB2 als Datenbank,<br />
<strong>Storage</strong>pool-Deduplication<br />
Die TSM Versions und Funktionsliste der letzten 20 Jahre ist<br />
auch ein Abbild der technologischen Entwicklung in der IT.<br />
Die Datenverarbeitung hat sich in vergleichbaren Phasen<br />
entwickelt, von der Mainframezentrischen IT über die Ära,<br />
in der die verteilte Verarbeitung auf möglichst vielen heterogenen<br />
<strong>System</strong>en schon Prinzip schien, wieder hin zu zentralen<br />
konsolidierten Strukturen auf virtualisierter Hardware.<br />
Die Anforderungen, für die TSM ursprünglich einmal konzipiert<br />
wurde, haben sich über diese Zeit nicht geändert:<br />
Datensicherung ist ein notwendiges Übel, das Kosten verursacht<br />
und dauernder Pflege bedarf, zu dem es aber keine<br />
Alternative gibt. Deshalb bin ich sicher, dass Tivoli <strong>Storage</strong><br />
Manager auch weiterhin gebraucht wird und erfolgreich sein<br />
wird. Im November 2010 feiert <strong>IBM</strong> Tivoli <strong>Storage</strong> Manager<br />
20. Geburtstag, dazu jetzt schon meine besten Wünsche für<br />
ein langes erfolgreiches Produktleben.<br />
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<br />
Anhang 207
<strong>IBM</strong> <strong>Storage</strong> Software<br />
BRMS für <strong>System</strong> i – Edelgard Schittko<br />
1. BRMS – Überblick<br />
Das Lizenzprogramm „Backup, Recovery and Media Services<br />
for <strong>IBM</strong> i“ (BRMS) ermöglicht die Implementierung<br />
einer Sicherungsstrategie für <strong>IBM</strong> POWER <strong>System</strong>e mit<br />
Betriebssystem <strong>IBM</strong> i (ehemals i5/OS).<br />
Dabei können komplexe Szenarien voll automatisiert abgebildet<br />
werden, wie z. B. die OnlineSicherung von LotusServern<br />
(Domino) in einer iUmgebung. Damit stehen mit BRMS<br />
mehr Möglichkeiten zur Verfügung als bei Verwendung der<br />
BackupBefehle vom native Betriebssystem <strong>IBM</strong> i.<br />
Das aktuelle Lizenzprogramm 5761BR1 „Backup, Recovery<br />
and Media Services for <strong>IBM</strong> i“ für Version i 6.1 besteht aus<br />
drei kostenpflichtigen Features: *BASE, Network Feature,<br />
Advanced Feature, die in Bild 1 vorgestellt werden und im<br />
Nachfolgenden ausführlich erläutert werden.<br />
Bild 1<br />
Nützliche Links:<br />
<strong>IBM</strong> i InfoCenter – BRMS<br />
http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/<br />
index.jsp?topic=/rzai8/rzai8overview.htm<br />
BRMS HomePage<br />
http://www03.ibm.com/systems/i/support/brms<br />
2. BRMS – aktuelle Features<br />
Die meisten <strong>IBM</strong> i Kunden, die BRMS verwenden, haben<br />
„nur“ das Feature *BASE lizenziert von 5761BR1. Bereits<br />
mit diesem Feature *BASE sind vier umfangreiche Module<br />
Backup, Recovery, Media Management und Tape Library<br />
Support verfügbar, siehe Bild 2.<br />
208 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Bild 2<br />
Weitere Details zu den im Bild 2 genannten vier Modulen<br />
Backup, Recovery, Media Management und Tape Library<br />
Support vom *BASE Feature siehe:<br />
Bild 3<br />
http://www.redbooks.ibm.com/redbooks/pdfs/sg244840.pdf<br />
http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/<br />
topic/rzai8/sc415345.pdf<br />
Für BRMS stehen mit i 6.1 drei verschiedene Schnittstellen<br />
(Interfaces) für die Implementierung und das Management<br />
zur Verfügung:<br />
• traditionell „green Screen“ (5250-Interface), siehe Bild 3<br />
• BRMS PlugIn im <strong>System</strong> i Navigator, siehe Bild 4<br />
• BRMS PlugIn im <strong>IBM</strong> <strong>System</strong>s Director Navigator für <strong>IBM</strong> i<br />
(ehemals i5/OS), siehe Bild 5<br />
Die Verwendung des 5250Interfaces (Bild 3) hat<br />
zwei Vorteile:<br />
•<br />
•<br />
eine ausgeprägte Menüstruktur, sinnvoll für BRMS-<br />
„Anfänger“<br />
eine Vielzahl von BRMS-Befehlen, die sich leicht in<br />
beim Kunden vorhandene Programme integrieren lassen,<br />
sinnvoll für den BRMS-„Experten“<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 209
<strong>IBM</strong> <strong>Storage</strong> Software<br />
BRMS für <strong>System</strong> i – Edelgard Schittko<br />
Bild 4<br />
Die Verwendung der beiden in Bild 4 und Bild 5 vorge<br />
stellten GUISchnittstellen für BRMS hat den Vorteil, dass<br />
GUIorientierte und/oder mit dem Betriebssystem <strong>IBM</strong> i nur<br />
wenig vertraute Anwender auch mit BRMS arbeiten können.<br />
GUI = Graphical User Interface<br />
Im Bild 4 sind ein paar Beispiele für sogenannte „Backup<br />
Control Groups (Sicherungssteuergruppen)“ zu sehen. Sie<br />
sind Definitionen für automatische Sicherungen. Hier nicht<br />
sichtbar, aber im Hintergrund vorhanden, ist das Scheduling<br />
für die Sicherungen.<br />
Bild 4 wurde mit einer <strong>System</strong> i Navigator Installation auf<br />
einem Laptop mit englischem Windows XP erstellt. <strong>System</strong> i<br />
Navigator ist auch auf Deutsch verfügbar.<br />
Die Beispiele für die Backup Control Groups sind von einer<br />
relativ kleinen <strong>IBM</strong> i Partition (Name „DEBER520“) eines<br />
POWER <strong>System</strong>s mit ca. 700 GB Plattenkapazität. Selbstverständlich<br />
ist BRMS bei den <strong>IBM</strong> i Kunden auch in Verwendung<br />
größerer Partitionen mit mehreren TB Platten kapazität<br />
im Einsatz.<br />
210 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Bild 5<br />
Neu mit <strong>IBM</strong> i 6.1 ist das Web Browser Interface „<strong>IBM</strong><br />
<strong>System</strong>s Director Navigator for i“ (frühere Bezeichnung<br />
„... for i5/OS“). Mit dem vorherigen Release <strong>IBM</strong> i 5.4<br />
(ehemals i5/OS V5R4) ist dieses Interface noch nicht verfügbar<br />
ge wesen.<br />
In diesem Web Browser Interface mit i 6.1 gibt<br />
es auch ein BRMS PlugIn, siehe Bild 5. Details zum<br />
BRMS PlugIn im „<strong>IBM</strong> <strong>System</strong>s Director Navigator for i“<br />
siehe Chapter 12.1 im Redbook „<strong>IBM</strong> <strong>System</strong>s Director<br />
Navigator for i (SG24778900)“:<br />
http://www.redbooks.ibm.com/redbooks/pdfs/sg247789.pdf<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 211
<strong>IBM</strong> <strong>Storage</strong> Software<br />
BRMS für <strong>System</strong> i – Edelgard Schittko<br />
Bild 6<br />
Im obigen Bild 6 sieht man einen Vergleich zwischen den<br />
Möglichkeiten (Befehle, Menüs, Backup Control Group<br />
Special Values) zum Sichern (to save) bzw. Zurückspeichern<br />
(to recover) in einer native <strong>IBM</strong> i Betriebssystemumgebung<br />
und einer BRMSUmgebung.<br />
Das Bild ist dem Poster „Are you saving the right stuff?“<br />
(<strong>IBM</strong> Form Number G325632805, http://publibfp.dhe.ibm.<br />
com/epubs/pdf/32563285.pdf) entnommen.<br />
212 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Bild 7<br />
Das lizenzpflichtige BRMS Network Feature ermöglicht es –<br />
siehe Bild 7, über mehrere Partitionen oder POWER <strong>System</strong>e<br />
mit <strong>IBM</strong> i und BRMS eine gemeinsame Tape Library zu<br />
verwenden, mit einem gemeinsamen Bandpool und einer<br />
bestimmen Anzahl von Bandlaufwerken. Dabei muss jede<br />
Partition/jedes <strong>System</strong> mit der Tape Library verbunden sein.<br />
Dadurch werden i.a. weniger Kassetten und auch weniger<br />
Bandlaufwerke benötigt als bei dedizierter Zuordnung.<br />
Außerdem können systemübergreifende Restores (Zurückspeicherungen)<br />
oder Duplizierungen durchgeführt werden,<br />
was z. B. bei zwei <strong>System</strong>en üblich ist, wo eines das Produktionssystem<br />
ist und das andere das Backup<strong>System</strong>.<br />
Bei partitionierten <strong>System</strong>en kann das BRMS Network auch<br />
zwischen den Partitionen eingerichtet werden. Hier ist die<br />
Verwendung des in allen partitionierten POWER <strong>System</strong>en<br />
vorhandenen virtuellen Ethernets als interne TCP/IPSchnittstelle<br />
für das BRMS Network sinnvoll.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 213
214<br />
<strong>IBM</strong> <strong>Storage</strong> Software<br />
BRMS für <strong>System</strong> i – Edelgard Schittko<br />
Bild 8<br />
Das lizenzpflichtige BRMS Advanced Feature – siehe Bild 8 –<br />
beinhaltet neben HSM (Hierachical <strong>Storage</strong> Management)<br />
seit 21.03.2008 in der Version 5761BR1 mit i 6.1 noch<br />
zwei weitere Möglichkeiten, einerseits einen individuellen<br />
BRMS<strong>System</strong>Namen zu vergeben („BRMS user defined<br />
system name“) und andererseits die Softwarebasierende<br />
Verschlüsselung („BRMS Software-based encryption“).<br />
Während HSM im BRMS und damit das bisherige BRMS<br />
Advanced Feature kaum verbreitet war, wird mit den beiden<br />
neuen Funktionen im BRMS Advanced Feature mit i 6.1 die<br />
Nutzung sicherlich steigen. So wird z. B. die Möglichkeit,<br />
einen individuellen BRMS<strong>System</strong>Namen zu vergeben, in<br />
Zusammenhang mit Hochverfügbarkeitsszenarien benötigt.<br />
Hinweis: Die sogenannte „Hardwarebased encryption“,<br />
auch bezeichnet als „Tape Drive Encryption“, ist schon seit<br />
Oktober 2006 als „Library Managed Encryption“ im BRMS<br />
unterstützt, siehe http://www03.ibm.com/systems/i/support/<br />
brms/tapeEncrypt.html<br />
Die oben beschriebenen BRMSFeatures beinhalten auch<br />
den Support für sogenannte „spezielle Umgebungen“,<br />
nachfolgend aufgezählt mit weiteren Links:<br />
BRMS Application Client zu einem <strong>IBM</strong> TSM Server,<br />
siehe Chapter 9 in<br />
http://www.redbooks.ibm.com/redbooks/pdfs/sg247031.pdf<br />
BRMS und FlashCopy, siehe Chapter 15 in<br />
http://www.redbooks.ibm.com/redbooks/pdfs/sg247103.pdf<br />
BRMS und WORM tapes, siehe Chapter 6 in<br />
http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/<br />
topic/rzai8/sc415345.pdf<br />
BRMS und SAP, siehe Chapter 23 in<br />
http://www.redbooks.ibm.com/redbooks/pdfs/sg247166.pdf<br />
BRMS und Domino, siehe u. a.<br />
http://www-03.ibm.com/systems/i/support/brms/domino.html<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
•<br />
•<br />
•<br />
•<br />
•<br />
Neu mit <strong>IBM</strong> i 6.1.1 (verfügbar seit 23.10.2009) auf POWER6<br />
oder POWER6+ <strong>System</strong>en oder entsprechenden POWER<br />
Blades gibt es einen NPIV Support (NPIV = N_Port ID<br />
Vir tualization) für bestimmte Tape Libraries (Bandroboter),<br />
siehe Informational APAR II14526:<br />
http://www912.ibm.com/n_dir/nas4apar.nsf/c79815e083182f<br />
ec862564c00079d117/02327e067599839e86257659003c6d<br />
66?OpenDocument&Highlight=2,NPIV<br />
Diese Tape Libraries mit ihren LTO4Laufwerken sind,<br />
obwohl sie „nur“ über eine virtuelle FibreVerbindung von<br />
der <strong>IBM</strong> i 6.1.1 Partition erreichbar sind, im BRMS voll<br />
unterstützt.
3. BRMS – Geschichte<br />
BRMS wurde erstmals am 01.09.1992 angekündigt (EMEA<br />
Announcement Letter ZP920587) unter der damaligen<br />
Bezeichnung „Backup, Recovery and Media Services/400“<br />
mit LizenzprogrammNummer 5798RYT mit genereller<br />
Verfügbarkeit am 15.01.1993. Das „Lizenzprogramm“ BRMS<br />
hatte 1992/1993 die „exotische“ LizenzprogrammNummer<br />
5798RYT, weil es damals noch als Ergebnis einer Allianz<br />
mit der Firma MerschBacher & Associates, Inc. vermarktet<br />
wurde und kein „vollwertiges“ Lizenzprogramm war, sondern<br />
„nur“ ein LPO (Licensed Program Offering).<br />
Am 03.05.1994 wurde BRMS als „vollwertiges“ Lizenzprogramm<br />
5763BR1 (Version 3, EMEA Announcement Letter<br />
ZP940348) angekündigt mit genereller Verfügbarkeit am<br />
25.11.1994 und damit in das normale Lizenzprogramm<br />
Prozedere von <strong>IBM</strong> Rochester für (damals noch) AS/400<br />
<strong>System</strong>e mit Betriebssystem OS/400 integriert. Ab diesem<br />
Zeitpunkt hat BRMS jeweils die „normale“ Lizenzprogramm<br />
Bezeichnung 57xxBR1 bekommen.<br />
Mit JEDER Betriebssystemversion von OS/400 bzw. i5/OS<br />
bzw. <strong>IBM</strong> i wurde ab 1994 auch eine neue Version von<br />
BRMS mit diversen Verbesserungen und Funktionserweiterungen<br />
herausgebracht. Anbei ein Link zu einer Übersicht<br />
aller Betriebssystemversionen von OS/400 bzw. i5/OS bzw.<br />
<strong>IBM</strong> i seit 1988. Für BRMS ist der Zeitraum ab 1994 wichtig:<br />
http://www947.ibm.com/systems/support/i/planning/<br />
upgrade/suptschedule.html<br />
Die genauen Features vom aktuellen BRMS mit <strong>IBM</strong> i 6.1<br />
(5761BR1) sind im Handbuch zu finden:<br />
http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/<br />
topic/rzai8/sc415345.pdf<br />
4. BRMS – Zusammenfassung und Ausblick<br />
Mit BRMS steht ein mächtiges Werkzeug für <strong>IBM</strong> iUmgebungen<br />
zur Verfügung, um komplexe Sicherungserfordernisse<br />
umzusetzen und um durch die sechs verschiedenen<br />
Module (Backup, Recovery, Media Management,<br />
Tape Library Support, Network Feature, Advanced Feature)<br />
sowohl für diverse Zurückspeicherungen einschließlich der<br />
kompletten Widerherstellung des gesamten <strong>System</strong>s aus<br />
einer Sicherung „gewappnet“ zu sein als auch um spezielle<br />
Anforderungen aus kundenindividuellen Implementierungen<br />
(z.B. Domino, SAP, FlashCopy) zu berücksichtigen.<br />
Bei einer kompletten Widerherstellung des gesamten<br />
<strong>System</strong>s wird der sogenannte „Recovery Report“ verwendet,<br />
eine nach der letzten Sicherung automatisch erstellte Anleitung<br />
über die durchzuführenden RückspeicherungsSchritte.<br />
Die für 2010 geplanten(*) Ankündigungen zu POWER7 und<br />
<strong>IBM</strong> i 7.1 und die damit geplanten Erweiterungen wie z.B.<br />
den Ausbau des bereits mit <strong>IBM</strong> i 6.1.1 möglichen „<strong>IBM</strong> i<br />
Network Upgrade“ auch für eine ScratchInstallation eines<br />
<strong>System</strong>s mit <strong>IBM</strong> i werden auch auf BRMS Auswirkungen<br />
haben.<br />
Man kann für BRMS in 2010 mit erfreulichen Neuerungen<br />
rechnen.<br />
Bereits existierende Links dazu (*):<br />
www.ibm.com/systems/power/hardware/sod.html<br />
www.ibm.com/systems/power/hardware/sod2.html<br />
(*) Disclaimer: All statements regarding <strong>IBM</strong>‘s future direction and intent are<br />
subject to change or withdrawal without notice, and represent goals and<br />
objectives only. Any reliance on these Statements of Direction is at the relying<br />
party‘s sole risk and will not create liability or obligation for <strong>IBM</strong>.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
215
216<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Technologie-Anhang<br />
Technologie-Anhang<br />
Anhang<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 217
Technologie-Anhang<br />
Die Vorgänger der heutigen Massenspeicher<br />
Lochkarten<br />
Lochkarten als Massenspeicher existierten lange vor den<br />
Computern. Bereits Holleriths Volkszählungsmaschine setzte<br />
1891 Lochkarten ein. Lochkarten stellen Binärdaten dar,<br />
indem eine bestimmte Stelle auf der Karte gelocht (oder<br />
eben nicht gelocht) war. Beim Aufkommen der Computer in<br />
den 50erJahren beherrschte man diese Technik inzwischen<br />
sehr gut: Die Karten konnten sortiert, gezählt und in jeder<br />
erdenk lichen Form ausgewertet werden.<br />
Hergestellt wurden die Karten mit sogenannten Lochkartenstanzern.<br />
Mit den fertig codierten Karten fütterte man über<br />
einen Leser den Computer und führte ihm auf diese Weise<br />
die gewünschten Programm und Verarbeitungsdaten zu.<br />
Statt einzelner Karten wurden später auch Lochstreifen<br />
verwendet, die eine höhere mechanische Verarbeitungsgeschwindigkeit<br />
gestatteten.<br />
Lochkarten<br />
Lochstreifen<br />
Trommelspeicher<br />
Die ersten elektrischen Massenspeicher, die im Zusammenhang<br />
mit Computern eingesetzt wurden, waren 1947/48 die<br />
sogenannten Trommelspeicher. Auf einer massiven Trommel<br />
wurde eine Beschichtung aus einem magnetischen Material<br />
aufgebracht. Dieses konnte induktiv durch einen Strom magnetisiert<br />
werden oder erzeugte beim Auslesen einen induzierten<br />
Strom. Durch die kleineren Ausmaße der Trommelspeicher<br />
verringerte sich auch die Größe der damaligen Computer<br />
erheblich. Bereits ab 1950 wurden vereinzelt Trommelspeicher<br />
eingesetzt, um Programme oder Daten zu laden und zu<br />
speichern.<br />
Trommelspeicher 1947<br />
218 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
1 st tape<br />
system<br />
1 st read/write<br />
drive<br />
1 st read/back<br />
drive<br />
1 st cartridge<br />
drive<br />
MP<br />
Beschichtung<br />
Magnetband<br />
Ab 1952 verdrängte das Magnetband (<strong>IBM</strong> 726, <strong>IBM</strong> 727)<br />
die Lochkarten als Massenspeicher. Dabei handelte es sich<br />
um ein 12,4 mm breites Plastikband, bei dem eine Seite mit<br />
einer magnetisierbaren Beschichtung überzogen war. Die<br />
Datenaufzeichnung bestand darin, dass die auf dem Band<br />
enthaltenen Ferritstreifen magnetisiert oder nicht magnetisiert<br />
waren und so die Informationen in dem für den Computer<br />
benötigten Binärsystem darstellten. Auf einer zusätzlichen<br />
Bandspur konnten später sogenannte Paritätsbits untergebracht<br />
werden, wodurch eine hohe Datensicherheit gewährleistet<br />
wurde. Der Vorteil der Magnetbänder lag neben einer<br />
hohen Verarbeitungsgeschwindigkeit vor allem in der hohen<br />
Speicherkapazität. Allerdings konnten Daten auf einem Band<br />
immer nur sequenziell (also hintereinander) abgelegt und<br />
wieder gelesen werden. Trotzdem findet das Magnetband bei<br />
Großrechner<strong>System</strong>en mit hohem Archivierungsbedarf und<br />
als billiger Massenspeicher (heute in Form von Bandkassetten)<br />
Zeitgesteuerte<br />
Spurnachführung<br />
Kassetten-Memory-Chips<br />
1 st to deliver<br />
LTO<br />
1 st with FICON<br />
and Fibre<br />
Parity<br />
Aufzeichnung<br />
1 st with LTO<br />
Fibre<br />
1 st tape encryption<br />
Flat Lap Köpfe<br />
PRML Dünnfilm<br />
Virtual<br />
Backhitch<br />
1 st with LTO4<br />
1 st 1TB capacity<br />
bis heute Verwendung. Zukünftig dürfte das Magnetband<br />
aufgrund der EnergieEffizienzProblematik und der „Green<br />
IT“Diskussionen eine Renaissance erfahren. Magnetbänder<br />
brauchen keinen Strom. Tape ist „cool“!<br />
Tape hat als Medium im Vergleich zu allen anderen Speichermedien<br />
die längste Geschichte. Heute bietet Tape als<br />
Medium im Vergleich zu allen vorhandenen Technologien<br />
wie Platte, optische Speicher, RAM, Flashspeicher oder<br />
PCMs das höchste Entwicklungspotenzial bezüglich Kapazität<br />
und Leistung in den nächsten Jahren. Dies wurde mit der<br />
konsequenten technischen Weiterentwicklung von Tape<br />
erreicht (siehe Bild „<strong>IBM</strong> Tape Historie im Überblick“).<br />
Bereits mit der ersten Kassettentechnologie, der <strong>IBM</strong> 3480,<br />
wurde MPBeschichtung (Metall Partikel) eingeführt. Mit der<br />
3590 wurde 1999 ParityAufzeichnung eingeführt, wo immer<br />
nach sieben Datenblöcken der dazugehörige ParityBlock<br />
mitaufgezeichnet wurde, was eine wesentlich höhere Fehler<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 219<br />
GMR
Technologie-Anhang<br />
korrektur ermöglicht. Mit der Einführung von LTO im Jahr<br />
2000 kam etwas ganz entscheidend Neues: die zeitgesteuerte<br />
Spurnachführung über Servobänder, die es erlaubt, die<br />
Schreib/Leseköpfe exakt – selbst bei sehr dünnen Spuren –<br />
über dem Spurset zu führen. Dies führte zu einer Kapazitäts<br />
und Leistungssteigerung von Faktor 20 in nur 10 Jahren<br />
(von 2000 bis 2010). Mit Einführung der 3592Technologie<br />
(Jaguar) im Jahr 2003 für den EnterpriseBereich wurden<br />
Techniken aus der Plattentechnologie in die Bandlaufwerke<br />
übernommen. Eine neue Kopftechnik kommt zur Anwendung,<br />
die es erlaubt, in Verbindung mit der ersten Dünnfilmbeschichtung<br />
auf dem Medium selbst mit wesentlich<br />
höherer Induktion auf den Köpfen aufzuzeichnen und so<br />
wesentlich stabilere Bits auf dem Medium zu reflektieren.<br />
PRML wurde bei den Platten erstmals 1991 eingeführt und<br />
hält mit der 3592 Einzug in die TapeTechnologie (siehe<br />
auch unter PRML im TechnologieAnhang). Neue Funktionen<br />
wie Virtual Backhitch kommen zum Tragen, die das Band im<br />
Laufwerk am „Streamen“ halten, auch wenn nur kleine<br />
Datenmengen zum Laufwerk transferiert werden.<br />
Das Jahr 2008 allerdings schreibt große Geschichte in der<br />
TapeHistorie. Mit dem Jaguar 3Laufwerk, das sich jetzt<br />
TS1130 nennt, gelingt der erste Einsatz von GMRLeseköpfen<br />
(GiantMagnetoResistance). GMRLeseköpfe kamen<br />
erstmals bei den Platten 1997 zum Einsatz und ohne diese<br />
Technologie wären unsere heutigen Festplattenkapazitäten<br />
nie möglich geworden. Jetzt ist die Basis von GMR auch bei<br />
Tape eingeführt, eine Basis, die völlig neue kapazitive Möglichkeiten<br />
schafft. Die Einführung von Dünnfilmbeschichtung<br />
und hochinduktiven Schreibköpfen lassen es zu, extrem<br />
dünne Spuren aufzuzeichen. Dies geschieht so, dass eine<br />
relativ dicke Spur hochinduktiv vom Bandanfang bis zum<br />
Bandende erzeugt wird. Beim Zurückschreiben vom Bandende<br />
zum Bandanfang wird ein Teil der geschriebenen Spur<br />
wieder überschrieben. Mit dieser Überschreibtechnik, die<br />
auch als „Shingling“ bezeichnet wird, ist es möglich,<br />
hauchdünne Spuren zu erzeugen. Das Problem ist jetzt das<br />
Auslesen. Wie können die kleinen magnetischen Streufelder<br />
auf einer so dünnen Spur wieder ausgelesen werden? Die<br />
Lösung hierfür sind die jetzt eingeführten GMRLeseköpfe.<br />
GMRLeseköpfe können selbst bei extrem hohen<br />
Geschwindigkeiten problemlos kleinste Streufelder<br />
ab greifen und auslesen. Damit ist eine neue Basis für die<br />
TapeWeiterentwicklung geschaffen.<br />
Bereits im Mai 2006 wurde im <strong>IBM</strong> Labor in Almaden, Kalifornien,<br />
der Einsatz von GMRLeseköpfen in einem Prototyp<br />
auf Basis der 3592 JaguarTechnologie vorgestellt und eine<br />
Aufzeichnungsdichte von 1 Gigabit pro cm2 erreicht. Die<br />
Grafik „GMREinsatz bei Tape“ zeigt die auf dem Band<br />
erzeugten Spuren mit GMR mit einer Spurbreite von 1,5 µm<br />
im Vergleich zu einer LTO3Spur mit 15 µm.<br />
Almaden: 16. Mai 2006, GMR-Einsatz bei Tape<br />
1 Gigabit pro cm 2 , 8 TB pro Kassette<br />
Magnetplatten<br />
Magnetplatten sind die Nachfolger der voluminösen Trommelspeicher<br />
und gelten als die direkten Vorläufer der heutigen<br />
Festplatten. Am 13. September 1956 stellte <strong>IBM</strong> die erste<br />
Magnetplatte mit der Bezeichnung RAMAC 350 (Random<br />
Access Method of Accounting and Control) als Teil des<br />
RAMAC 305<strong>System</strong>s und mit einer Kapazität von 5 MB der<br />
Öffentlichkeit vor. Diese Kapazität verteilte sich auf 51<br />
Scheiben mit je 24 Zoll (60 cm) Durchmesser. Die Abtastung<br />
der Informationen erfolgte durch einen SchwebeSchreib/<br />
Lesekopf (siehe unter RAMAC 305).<br />
220 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Entwicklung des <strong>IBM</strong> <strong>System</strong>s 305 und des ersten Magnetplattenspeichers<br />
<strong>IBM</strong> 350<br />
Der <strong>IBM</strong> Mitarbeiter Reynold B. Johnson erhielt Anfang der<br />
50erJahre die Aufgabenstellung, ein Rechnersystem zu<br />
konzipieren, das die Möglichkeit hatte, jeden Geschäftsvorfall<br />
dann zu bearbeiten, wenn er anfällt mit einer Leistung<br />
von etwa 10.000 Fällen pro Tag (ohne Stapelverarbeitung,<br />
wie es die bis dahin verwendeten Lochkarten und Lochstreifen<br />
machten). Reynold B. Johnson stellte sich ein einzigartiges<br />
Team aus Entwicklern und Experten zusammen, um<br />
diese schwierige Aufgabe zu starten. Um eine möglichst<br />
angenehme Umgebung für diese Aufgabe zu haben, die<br />
möglichst viele Innovationen hervorbringen sollte, startete er<br />
das Projekt 1952 in San Jose, im sonnigen Kalifornien. Das<br />
Projekt trug damals den Namen „source recording“. Im<br />
Team von Johnson waren A.J. Critchlow, W.A. Goddard,<br />
J.W. Haanstra, H.P. Luhn, J. Ratinow und C.D. Stevens.<br />
Bereits ein Jahr später, 1953, fällte Johnson die Entscheidung,<br />
dass der Datenspeicher eine mit Magnetspeicherplatten<br />
arbeitende Dateianlage sein sollte.<br />
Damals war gerade die Entwicklungsarbeit der <strong>IBM</strong> Magnetbandeinheit<br />
726 abgeschlossen und das Team von Reynold<br />
B. Johnson erkannte schnell, dass Magnetbandeinheiten<br />
zwar sehr schnell im seqenziellen Bereich arbeiten konnten,<br />
sich allerdings bei direkten Zugriffen bezüglich der Zugriffszeit<br />
langsam verhielten. Die Zugriffszeiten bewegten sich in<br />
den Minutenbereich hinein und daher waren die Bänder für<br />
Sofortzugriffe bei ganz bestimmten Anwendungen nicht<br />
geeignet. Ein neuer Speicher, der diese Anforderungen<br />
erfüllen konnte, musste entwickelt werden. Die Lösung<br />
bestand aus 51 beidseitig beschichteten Aluminiumplatten,<br />
die auf einer vertikalen Welle montiert wurden und mit einer<br />
Geschwindigkeit von 1.200 Umdrehungen pro Minute<br />
rotierten. Man begnügte sich mit einem Paar von Schreib/<br />
Leseköpfen, die mittels eines Stahlseilantriebs zweidimensional<br />
positioniert wurden gemäß dem Inhalt eines Adressregisters.<br />
Dieser Vorgang dauerte maximal 800 ms. Damit<br />
konnte die Forderung erfüllt werden, etwa 10.000 Transaktionen<br />
pro Tag, jede sofort beim Eintreffen des Falles, zu<br />
bearbeiten. 1956 war es dann soweit, dass das neue Rechnersystem<br />
RAMAC 305 mit dem dazugehörigen Plattenspeicher<br />
RAMAC 350 auf den Markt gebracht werden konnte.<br />
RAMAC 350 als Teil des RAMAC 305-Rechnersystems<br />
Reynold B. Johnson, der kurz „Rey“ genannt wurde, hatte<br />
bis zu seiner Pensionierung 1971 die Zahl von 90<br />
U.S.Patenten angemeldet, fast ausschließlich Patente, die<br />
die Plattenweiterentwicklung betrafen.<br />
Mit der RAMAC 350 erblickte der erste Magnetplattenspeicher<br />
das Licht der Welt und es folgten ohne Unterbrechung<br />
über Jahrzehnte weitere Entwicklungen des Plattenspeichers<br />
mit dem ständigen Ziel, Kapazitätssteigerungen,<br />
Zugriffszeitverkürzungen, höhere Datenraten und geringere<br />
Kosten pro gespeichertes Megabyte zu erreichen. Dieser<br />
Entwicklungsgang wurde durch die American Society of<br />
Mechanical Engineers in 1984 gewürdigt, indem sie den<br />
RAMACPlattenspeicher zur „International Historic Mechanical<br />
Engineering Landmark“ (Landmark steht für Meilenstein)<br />
erklärte, in Anerkennung des andauernden Einflusses<br />
auf die Speichertechnologie.<br />
Reynold B. Johnson<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 221
Technologie-Anhang<br />
Funktionsweise des Magnetplattenspeichers <strong>IBM</strong> 350 (1956)<br />
und <strong>IBM</strong> 355 (1957)<br />
Wie arbeitet nun die Magnetplatte RAMAC 350 und wie<br />
erfolgt die Positionierung? Der Prozessor stellt mit dem<br />
Suchkommando die anzusteuernde Adresse zur Verfügung.<br />
Diese Adresse wird in Adressrelais gesetzt, danach sorgt<br />
ein Startsignal für die Zugriffssteuerung. Ausgehend von der<br />
IstPosition des Vertikalwagens ist die Zielposition durch die<br />
Aktivierung einer der beiden Magnetpulverkupplungen<br />
anzufahren (siehe Bild „RAMAC Zugriffsmechanismus“).<br />
Ganz unten hängt der Antriebsmotor mit Vförmigem<br />
Antriebspulli, einem Stahlkegel, der mit einer Gummiobe r<br />
fläche versehen ist. Dieser Kegel treibt zwei Magnetpulver<br />
kupplungen an, d.h., die eine läuft rechts, die andere links<br />
herum. Die beiden Kupplungen laufen auf einer Welle.<br />
Wenn keine der beiden Kupplungen aktiviert ist, steht die<br />
Ausgangs seilantriebsrolle still (rechts unten). Wird eine der<br />
Kupplungen aktiviert, bewegt sich der Vertikalwagen, der<br />
den Zugriffsarm bewegt (Bildmitte), nach oben oder nach<br />
unten, je nachdem, welche Kupplung aktiviert wurde.<br />
Die Adressrelais repräsentieren die Zielposition als Soll<br />
Position. Der Kontakt vom Vertikalwagen zu einem von 50<br />
Kontakten (Abbildung „RAMAC 350 Vertikalpositionierung“,<br />
kupferfarbige Kontaktleiste) zeigt die VertikalwagenIst<br />
Position. Eine ohmsche Messbrücke stellt die Größe der<br />
Differenz von Ist zu SollPosition fest und erzeugt ein entsprechendes<br />
Startsignal. Der Vertikalwagen bewegt sich<br />
jetzt entweder nach oben oder unten.<br />
Dadurch ändert sich laufend der IstWiderstand in der<br />
Messbrücke, bis er den Wert Null (Brückengleichheit)<br />
erreicht hat. Trifft dies zu, wird die antreibende Kupplung<br />
stromlos (entweder die eine oder die andere) und damit<br />
wird die Bewegung gestoppt. Damit ist die Vertikalbewegung<br />
abgeschlossen. Um diese Position mechanisch präzise<br />
zu halten, wird ein Präzisionskonus druckluftgesteuert<br />
in eines der Konuslöcher zur Verriegelung eingefahren<br />
(Abbildung „RAMAC 350 Vertikalpositionierung“, Lochschiene<br />
rechts neben der kupferfarbigen Kontaktleiste).<br />
222 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Der Vertikalwagen wird dadurch fest an der Vförmigen<br />
Bewegungsschiene arretiert.<br />
Um die auftretenden Kräfte beim Stoppvorgang zu beherr<br />
schen, läuft ein Tachogenerator mit (Abbildung „RAMAC<br />
350 Zugriffsmechanismus“ unten links), der die Geschwindigkeit<br />
in Form der abgegebenen Spannung anzeigt. Je<br />
näher der Vertikalwagen zu seiner Zielposition kommt, umso<br />
weniger Kupplungsstrom steht zur Verfügung, und damit<br />
verlangsamt sich die Bewegung.<br />
Ist die Suchposition erreicht, d.h., die Vertikalverriegelung<br />
durch den Präzisionskonus in der Lochschiene ist erfolgt,<br />
wird das Steuersignal für die Phase der Horizontalbewegung<br />
des Zugriffsarmes gestartet (Bild „RAMAC 350<br />
Horizontalpositionierung“).<br />
Die Horizontalpositionierung läuft ähnlich ab wie die Vertikalpositionierung.<br />
Der Zugriffsarm wird in seiner Position<br />
begleitet von dem oben rechts sichtbaren Potentiometer<br />
(Zahnradantrieb) und liefert über die Messbrücke die Soll<br />
IstDifferenz für die weitere Ablaufsteuerung. Beim Erreichen<br />
der Zielposition (Spuradresse) wird die präzise Spurposition<br />
mittels pneumatisch betätigter Klinke auf die Präzisionszahnstange<br />
verriegelt. Damit ist die mechanische Positionierung<br />
in beiden Zugriffsachsen abgeschlossen. Ein „End of<br />
Access“Signal steuert das pneumatische Ausfahren des<br />
S/LKopfes auf Schwebehöhe. Die Präzisionszahnstange<br />
enthält 100 Einkerbungen, wo sich die Klinke einrasten<br />
kann, weil die Platte insgesamt 100 Spuren reflektiert.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 223
224<br />
Technologie-Anhang<br />
Wie schwebte der S/LKopf wirklich?<br />
Der Kopf befindet sich im nicht aktivierten Zustand in eingefahrener<br />
Position durch Federkraft (siehe Abbildung 350/355<br />
S/LKopfgehäuse, F links und rechts). In dieser Position hat<br />
der Kopf einen beträchtlichen Abstand zu den Plattenoberflächen.<br />
Wird das Ladeventil aktiviert, strömt Druckluft (siehe<br />
Bild „DL“) in die drei Zylinderräume der Kolben K. Dadurch<br />
wird der Kopf nach unten hin zur Plattenoberfläche (Speicheroberfläche)<br />
bewegt. Die gesteuerte Druckluft tritt<br />
gleichzeitig aus sechs im Sechseck angeordneten (im Bild<br />
nur vier sichtbar), mit nur 0,1 mm Durchmesser großen Bohrungen<br />
aus. Dadurch lässt sich der Kopf nicht tiefer drücken,<br />
weil das Luftpolster unter den sechs Löchern sich nur<br />
auf eine Höhe von 0,02 mm bringen lässt (konstruktionsbedingt).<br />
Dieser Schwebezustand des Kopfes in dieser Höhe<br />
wird kontinuierlich beibehalten, auch wenn geringfügige<br />
Schwankungen der Platten bei einem Durchmesser von 24 Zoll<br />
(ca. 60 cm) im äußeren Bereich stattfinden (Bernoullisches<br />
Gesetz). Damit ist der S/LKopf bereit zu lesen oder zu<br />
schreiben.<br />
Die Solenoide (siehe Abbildung „RAMAC 350 Zugriffsmechanismus“<br />
kleines Bild links, 5 Stück) steuern per Pressluft<br />
das Arretieren und Lösen des Wagenverriegelungsbolzens<br />
bei der Vertikalpositionierung und per Pressluft die Armverriegelungsklinke<br />
auf der Präzisionszahnstange bei der Hori<br />
zontalpositionierung. Sie steuern ebenso die Druckluftzufuhr<br />
zum 350/355 Kopfgehäuse, um das Ausfahren der Köpfe<br />
auf Schwebedistanz zur Platte durchzuführen. Solenoide<br />
sind röhrenförmige zylindrische Metallspulen, die bei Stromdurchfluss<br />
wie ein Stabmagnet wirken. Im Falle der RAMAC<br />
350/355 arbeiten Solenoide als schnelle Nadelventile für<br />
Pressluft, die per Magnetfeld geöffnet werden und per<br />
Federkraft geschlossen werden.<br />
Hinweis: Es gibt oft Irritationen, ob der RAMAC 350 Plattenstapel<br />
50, 51 oder 52 Platten hatte! Bei der RAMAC 350<br />
wurden 50 Platten, also 100 Plattenoberflächen zur Aufzeichnung<br />
verwendet. Der Stapel selbst umfasste 51 Platten.<br />
Dabei wurden die beiden Außenoberflächen der beiden<br />
äußeren Platten (ganz oben und ganz unten) nicht für die<br />
Aufzeichnung verwendet. Bei der RAMAC 355, die ein Jahr<br />
später, 1957, auf den Markt kam, umfasste der Plattenstapel<br />
52 Platten, 50 für die Aufzeichnung. Die Außenplatten<br />
dienten nur zur Stabilisierung und zum Schutz für die innen<br />
liegenden 50 Platten, die zur Aufzeichnung dienten.<br />
Der druckluftgesteuerte Schwebekopf lernte erst 1961 das<br />
Fliegen und wurde mit dem Produkt <strong>IBM</strong> 1301 eingeführt<br />
(siehe auch unter <strong>IBM</strong> 1301). Dabei wurden im Außenbereich<br />
der Platten „Landebahnen“ eingeführt und der Kopf<br />
wurde so aerodynamisch gestaltet, dass er bei einer<br />
Umdrehung von knapp 1.800 Umdrehungen pro Minute<br />
seine Flughöhe erreichte, die damals bei 0,0635 mm lag.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Hinweis: Im Anhang des Kapitels Magnetplatten finden Sie<br />
ein Interview, das der Autor mit den <strong>IBM</strong> RAMAC 350/355<br />
Spezialisten Hans W. Spengler und Heinz Graichen vom<br />
<strong>IBM</strong> Museum in Sindelfingen geführt hat. Hier wird der <strong>IBM</strong><br />
RAMAC 350/355 Zugriff in allen technischen Einzelheiten<br />
erläutert.<br />
Noch immer dominieren Magnetplattenspeicher die Informationstechnologie,<br />
obwohl auch die optischen Speicher in<br />
Form der wiederbeschreibbaren Compact Discs sich einen<br />
gewichtigen Anteil am Massenspeichermarkt erobert haben.<br />
Magnetplattenspeicher funktionieren alle nach dem gleichen<br />
Grundprinzip: Als Speichermedium dient eine runde Scheibe,<br />
auf der sich eine Schicht aus hartmagnetischem Material<br />
(früher verschiedene Ferrite, heute Dünnfilm) befindet. Die<br />
Platte ist in konzentrische Spuren unterteilt. Ein beweglicher<br />
Magnetkopf wird radial über diese Platte bewegt, um die<br />
nadelförmigen Ferrite auf den einzelnen Spuren so zu<br />
magne tisieren, dass Binärdaten abgebildet werden. Er ist<br />
auch in der Lage, durch Verschiebung des Laufwerksarms<br />
schnell von der einen in die andere Spur zu wechseln. Die<br />
Spuren wiederum sind in Sektoren unterteilt. Die Lage und<br />
Ausdehnung der einzelnen Sektoren werden durch die<br />
sogenannte Formatierung festgelegt.<br />
Prinzipiell sind Magnetplattenspeicher auf wahlfreien Zugriff<br />
ausgelegt. Dies bedeutet, dass das Medium nicht – wie z. B.<br />
bei Bandlaufwerken – von Beginn an sequenziell durchsucht<br />
werden muss, um eine bestimmte Stelle (Datei) zu finden.<br />
Die Köpfe der Magnetplatten können – vergleichbar mit<br />
dem Tonarm eines Plattenspielers und dem Anwählen eines<br />
bestimmten Musikstücks – direkt zu der Stelle springen, an<br />
der die gewünschte Datei angelegt ist.<br />
Disketten<br />
Alan Shugart, der in den späten 60erJahren für <strong>IBM</strong> arbeitete,<br />
wird die Erfindung der 8ZollDiskette im Jahr 1971<br />
zugeschrieben. Die Diskette besteht aus einer Kunstofffolie,<br />
die mit einer nichtorientierten Magnetschicht versehen ist.<br />
Die Datenaufzeichnung erfolgt entweder einseitig (SS) oder<br />
doppelseitig (DS). Zum Schutz und zur besseren Handhabung<br />
befindet sich die Scheibe in einer rechteckigen Kunststoffhülle,<br />
die mit einem Gleit und Reinigungsvlies ausgekleidet<br />
ist. Die Hülle besitzt Öffnungen für den Arbeitskonus<br />
(über den die Scheibe angetrieben wird), das Indexloch<br />
und den Schreib/Lesekopf. Zusätzlich besitzt die Hülle<br />
noch eine Aussparung für das Setzen eines Schreibschutzes.<br />
Je nach <strong>System</strong> wird der Schreibschutz durch<br />
Abdecken oder Freilassen dieser Aussparung gesetzt. Der<br />
Schreib/Lesekopf berührt beim Schreiben und Lesen die<br />
Diskettenoberfläche, ansonsten ist der Kopf angehoben.<br />
1971 stellte <strong>IBM</strong> das erste 8ZollDiskettenlaufwerk der<br />
Öffentlichkeit vor. Damit wird zum ersten Mal bei einem<br />
beweglichen Datenträger der wahlfreie Zugriff realisiert,<br />
denn der Schreib/Lesekopf kann auf jeder Stelle des<br />
Datenträgers positioniert werden.<br />
Disketten<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
225
Technologie-Anhang<br />
Seine eigene Firma, Shugart Associates, gründete Alan<br />
Shugart dann 1973 zur Entwicklung und Herstellung von<br />
Diskettenlaufwerken. Schon lange wollte er Prozessoren und<br />
Diskettenlaufwerke als Teile in komplette Computersysteme<br />
integrieren. 1976 ist es Alan Shugarts Firma, die das erste<br />
5,25ZollDiskettenlaufwerk (Auftraggeber war die Fa. Wang<br />
Laboratories) auf den Markt bringt. 1978 stellten bereits<br />
zehn Firmen 5,25ZollLaufwerke her. 1980 stellt Sony die<br />
3,5ZollDiskette der Öffentlichkeit vor. Dieses Diskettenformat<br />
mit der gesteigerten Kapazität von 1,44 MB ist heute<br />
noch in sehr alten PCs gebräuchlich. Die Miniaturisierung<br />
bei den Diskettenlaufwerken brachte es u. a. mit sich, dass<br />
eine Kombination von 5,25Zoll und 3,5ZollFloppy in einem<br />
halbhohen Gehäuse unter gebracht werden konnte. Verschie<br />
dene 3Zoll(Amdisk) und 2ZollFormate wie auch die LS120<br />
Diskette (Panasonic, sogar abwärts kompatibel zur 1,44 MB<br />
Diskette) und die ZipDiskette (Iomega, 1994, 100 MB – 750<br />
MB) konnten sich nicht mehr als Standard durchsetzen.<br />
Festplatten<br />
Die ersten Ansätze für mobile Festplatten sah man 1973.<br />
<strong>IBM</strong> stellte 1973 die Festplatte „Winchester 3340“ vor. Kapazität:<br />
35 MB. Der Entwicklungsname „Winchester“ verbindet<br />
die damals angestrebte Speicherkapazität von ca. 30 MB pro<br />
Module und einer Zugriffszeit von 30 ms mit dem amerikanischen<br />
Gewehrtyp „Winchester 3030“. Dieses Plattenmodul<br />
war leicht zu transportieren, da es im Vergleich zum Vorgänger<br />
<strong>IBM</strong> 3330 kleiner war und nur etwa die Hälfte wog<br />
(siehe auch unter <strong>IBM</strong> 3340).<br />
Wie funktionieren nun Festplatten? Eigentlich bis heute nach<br />
dem gleichen Prinzip. Im einem luftdicht verschlossenen<br />
Gehäuse (beinahe luftdicht, denn ein gewisser Luftaustausch<br />
findet statt) sind mehrere übereinander rotierende Magnetplatten<br />
montiert. Bei neueren Festplatten sind das – zur<br />
Redu zierung der Bauhöhe – nur noch wenige Magnetplat<br />
ten. 1977 brachte Shugart das erste preiswerte Laufwerk<br />
auf den Markt (14 Zoll, 30 MB). Die weitere Entwicklung<br />
führte zu kleineren Platten. Seagate baute 1979 die erste<br />
Festplatte im 5,25ZollFormat. 1981 kam SCSI und 1982<br />
gab es die ST506Schnittstelle von Seagate, aus der sich<br />
IDE, EIDE, ATA und ATAPI entwickelt haben. Das Seagate<br />
ST506Laufwerk, nach dem die Schnittstelle benannt wurde,<br />
verfügte (wie das RAMACLaufwerk aus dem Jahr 1956)<br />
über eine Kapazität von 5 MB.<br />
1996 hatte Seagate mit der CheetahSerie erste Festplatten<br />
mit 10. 000 U/min präsentiert. 1998 bot die SeagateBarracuda<br />
Serie eine Maximalkapazität von 50 GB. Nur zwei Jahre später<br />
waren es schon fast 200 GB. Dies übertraf die bis lang<br />
übliche Steigerung von 60% in einem Jahr oder die Verdoppelung<br />
in 18 Monaten bei Weitem. Zwischen 1957 und 1990<br />
lag die Steigerungsrate noch bei etwa 25% im Jahr. Die<br />
Flächendichte auf den Festplattenscheiben stieg von 2.000<br />
Bit/inch2 im Jahr 1957 auf über 1 Gbit/inch2 in den Jahren<br />
1995 bis 1997.<br />
1973: <strong>IBM</strong> 3340 Winchester-Wechselplatte 1990: <strong>IBM</strong> 3390 Montage der Zugriffsarme<br />
226 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Im Schnitt: <strong>IBM</strong> 3390 Laufwerk<br />
Die Datentransferraten der Festplatten waren mindestens um<br />
das Zehnfache höher als bei Disketten, weil sich die Platten<br />
mit bis zu 20facher Geschwindigkeit einer Diskette drehten,<br />
je nach Typ zwischen 3.500 und 15.000 U/min. Jede Platte<br />
besitzt mindestens zwei Lese und Schreibköpfe, die die<br />
Platten auf der Ober oder Unterseite abtasten. Es gibt allerdings<br />
auch Festplatten, die über mehrere Sets an Schreib/<br />
Leseköpfen verfügen, z. B. Festplatten in Hochleistungsrechnern<br />
oder SCSIFestplatten mit vier R/WKöpfen,<br />
wodurch die Zugriffszeit verringert wird. Durch das Rotieren<br />
der Magnet scheiben entsteht ein Luftpolster, auf dem sich<br />
dann die Schreib/Leseköpfe bewegen. Diese sind mechanisch<br />
über den Schreib/Lesearm (Kamm) auch mit den<br />
anderen Köpfen verbunden, sodass ein Spurwechsel für alle<br />
Platten gleichzeitig vollzogen wird. Um die Bewegung von<br />
Kopf zu Kopf zu beschreiben, hat man den Begriff des<br />
1987: <strong>IBM</strong> 3380 Fertigung im <strong>IBM</strong> Werk Berlin 1990: <strong>IBM</strong> 3390 Montage<br />
Zylinders eingeführt. Dieser umfasst alle Spuren, die die<br />
gleiche Spurnummer tragen. Jede Platte ist also in Spuren<br />
aufgeteilt, die in konzentrischen Kreisen um den Mittelpunkt<br />
angeordnet sind (ähnlich einer Schallplatte). Spuren werden<br />
mit den Nummern von 0 bis N bezeichnet, wobei N die<br />
Gesamtzahl der Spuren minus 1 darstellt. Die äußere Spur<br />
trägt die Nummer 0, die darauffolgende die Nummer 1.<br />
Jede Spur nimmt dabei eine konstante Anzahl von Sektoren<br />
auf, die die Spur in einzelne Abschnitte gleicher Größe<br />
unterteilen. Der Aufbau gleicht also dem einer Diskette.<br />
Jeder Sektor beinhaltet 512 Bytes an Daten (Fixed Block<br />
Architecture FBA) und stellt zugleich die kleinste Zugriffseinheit<br />
dar. Jede Festplatte verfügt über wesentlich mehr konzentrische<br />
Spuren als eine Diskette, die Positionierungsgenauigkeit<br />
ist höher und somit wird auch die mögliche<br />
Speicherdichte größer.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 227
Technologie-Anhang<br />
MFM (Modified Frequenz Modulation)<br />
MFM setzte sich als neues Verfahren zur Übertragung von<br />
Daten über den Schreib/Lesekopf auf die Oberfläche der<br />
Festplatte durch. MFMFestplatten waren bis Mitte der 80er<br />
Jahre der Standard bei den PCFestplatten. Sehr verbreitet<br />
waren zuerst Festplatten mit einer Kapazität von 20, später<br />
von 40 MB. Man bedenke: Zur gleichen Zeit passte ein komplett<br />
lauffähiges MSWord 2.0 auch noch auf eine 360KDiskette.<br />
Aktuelle Motherboards haben keine Anschlüsse mehr<br />
für diese Art von Festplatten, entsprechende 8 und 16Bit<br />
ISAController können aber noch auf Flohmärkten erworben<br />
werden.<br />
Entwicklung Speicherdichte pro Produkt von 1956 bis 2000<br />
RLL (Run Length Limited)<br />
Prinzipiell ist der Aufbau mit dem der MFMFestplatte identisch,<br />
nur die Speicherkapazitäten waren größer. Das ergab<br />
sich aus der verbesserten Oberfläche der Platten. Auch die<br />
Steuerung der Laufwerke verbesserte sich sehr stark.<br />
Dadurch wurden pro Spur 26 Sektoren möglich, was eine<br />
erhebliche Erhöhung der Speicherdichte bedeutete. Von<br />
RLLPlatten ist allerdings heute nur noch die Art und Weise<br />
des Aufzeichnungsverfahrens übrig geblieben. Ansonsten<br />
sind sie – wie die MFMFestplatten – veraltet.<br />
Jahr Produkt Bits/Inch (bpi) Tracks/inch (tpi) Areal Density<br />
(MBit/inch2 Areal Density<br />
)<br />
(MBit/cm2 Kopftechnik<br />
)<br />
1956 350 100 20 0,002 0,00031 Schwebekopf<br />
1957 355 100 20 0,002 0,00031<br />
1961 1405 220 40 0,009 0,00140<br />
1962 1301 520 50 0,026 0,00400 Flugkopf<br />
1963 1311 1 025 50 0,051 0,00790<br />
1964 2311 1 100 100 0,110 0,01700<br />
1966 2314 2 200 100 0,220 0,03400<br />
1971 3330 4 400 192 0,780 0,12100<br />
1973 3340 5 636 300 1,690 0,26200<br />
1976 3350 6 425 478 3,070 0,47600<br />
1979 3370 12 134 635 7,800 1,20000 Dünnfilmkopf<br />
1981 3380-D 15 200 840 12,000 1,86000<br />
1985 3380-E 1 400 19,290 2,99000<br />
1987 3380-K 15 240 2 083 36,000 5,47000<br />
1989 3390-1/2 27 483 2 235 60,510 9,38000<br />
1991 3390-3 29 718 90,000 13,50000 DFpl + MR<br />
1991 9340/9345 24 130 4 450 111,000 16,00000<br />
1993 3390-9 2 921 270,000 41,85000<br />
1994 RAMAC 1 260,000 40,30000<br />
1995 RAMAC 2 544,000 84,32000<br />
1996 RAMAC 3 829,000 129,20000<br />
1999 2105 ESS 2 758,000 427,50000 GMR-Lesekopf<br />
2000 2105 ESS 5 516,000 855,00000<br />
DFpl + MR = Dünnfilmplatte und Magnetoresistiver Schreib-/Lesekopf, GMR = Giant Magnetoresistiver Lesekopf<br />
228 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
<strong>IBM</strong> Travelstar 60-GB-Serial-ATA-Laufwerk mit 7.200 RPM <strong>IBM</strong> Ultrastar 146-GB-Laufwerk mit 10 .000 RPM<br />
Festplatten in den ersten <strong>IBM</strong> PCs<br />
Der erste SchnittstellenStandard für Festplatten wurde 1980<br />
von Seagate entwickelt: ST506. Dieser wurde in einer 5 MB<br />
großen Festplatte mit eben dieser Modellbezeichnung verwendet.<br />
Bereits ein Jahr später entstand – ebenfalls von<br />
Seagate – der ST412 Standard. Diese 10 MB große Festplatte<br />
wurde u. a. im populären <strong>IBM</strong> XT (5160) verbaut. Diese<br />
beiden frühen Standards unterschieden sich in einem<br />
wesent lichen Aspekt von ihren Nachfolgern IDE/ATA und<br />
SCSI: Sie hatten keine eigene Intelligenz. Die komplette<br />
Steuerung wurde von einem komplex aufgebauten Controller<br />
erledigt, an den sie mit zwei Kabeln angeschlossen<br />
waren. Für die Steuerung der Plattenmechanik wurde der<br />
Controller über ein 34adriges Kabel mit der Platte verbunden,<br />
für den Daten transport mit einem 20adrigen Kabel. Die<br />
ganze Sache war noch sehr fehlerträchtig und langsam,<br />
denn die von den Schreib/Leseköpfen verarbeiteten Daten<br />
mussten erst auf den Controller transportiert werden, bevor<br />
ein Fehler festgestellt werden konnte. Zudem waren diese<br />
frühen Festplattenstandards aufwendig in der Installation.<br />
Viele komplizierte Parameter (z. B. der „InterleaveFaktor“)<br />
und die gesamte Geo metrie der Festplatte mussten von<br />
Hand eingestellt werden, denn es gab noch kein BIOS, in<br />
dem diese Werte voreingestellt gewesen wären. Und<br />
Plug&Play (also die automatische Erkennung der Festplattengeometrie),<br />
so wie wir es heute kennen, kam erst Mitte<br />
der 90erJahre.<br />
Der Nachfolger der MFM/RLLFestplatten war die IDEFestplatte<br />
(Integrated Drive Electronics) von <strong>IBM</strong>. Aber auch<br />
diese werden heute eigentlich nicht mehr verwendet, denn<br />
die Kapazität war auf netto 504 MB begrenzt. Die heute verwendeten<br />
Festplattenarten sind EIDE (Enhanced Integrated<br />
Drive Electronics), SCSI (Small Computer <strong>System</strong>s Interface)<br />
und aktuell SATA (Serial Advanced Technology Attachment),<br />
eine erst im Jahr 2001 definierte Weiterentwicklung von ATA<br />
(Advanced Technology Attachment).<br />
Der Unterschied lag bei diesen neueren Standards hauptsächlich<br />
im Controllerbereich. SCSIFestplatten waren zu der<br />
Zeit noch etwas schneller, aber auch wesentlich teurer. Der<br />
Vorteil von SCSI lag in seiner Flexibilität, denn so ziemlich<br />
alle Arten von Geräten (Floppy, Streamer, CDROM, Festplatte,<br />
Scanner etc.) können an einen SCSI Controller angeschlossen<br />
werden, und zwar bis zu sieben Stück pro Controller<br />
(Weiterentwicklung dann 16 pro Kanal). Ein EIDE Controller<br />
konnte dagegen nur zwei Geräte verwalten, denn diese<br />
Schnittstelle war eigentlich ausschließlich auf den Betrieb<br />
mit Festplatten ausgelegt. Trotzdem gibt es auch für EIDE<br />
mittlerweile CDLaufwerke oder Streamer. Moderne Motherboards<br />
enthielten oft bereits zwei integrierte EIDE Controller.<br />
Dadurch konnten vier entsprechende Geräte betrieben werden,<br />
was für die meisten Nutzer vollständig ausreichte. SATA<br />
über trägt die Daten im Gegensatz zu allen anderen <strong>System</strong>en<br />
seriell, d. h. Bit für Bit. Trotzdem werden Übertragungsraten<br />
von bis zu 600 MB je Sekunde erreicht. SATA ist kompatibel<br />
zum ATAPIStandard und den verschiedenen ATAVorgängern.<br />
Ein weiterer großer Vorteil: Eine Konfiguration entfällt fast<br />
vollständig und Geräte können bei eingeschaltetem Rechner<br />
ein und ausgesteckt werden (HotPlugging).<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 229
Technologie-Anhang<br />
In den 80erJahren bis 1991 wurden groß dimensionierte<br />
braune Platten gebaut. Die <strong>IBM</strong> 3380 Technologie mit 14Zoll<br />
Platten, die später von 10,5ZollPlatten, der 3390 Technologie,<br />
abgelöst wurden, beschäftigte sich konstant mit der Frage,<br />
wie viel Kapazität unter einem Actuator, also unter einem<br />
Schreib/Lesekopf, verwaltet werden kann, ohne dass es zu<br />
Warteschlangen kommt und die Leistungsfähigkeit des<br />
Lauf werks beeinträchtigt wird. Aufgrund dieser Problematik<br />
wurden auf dem Zugriff in der Regel 2 Schreib/Leseköpfe aufgebracht.<br />
Dabei war ein Kopf für den Innenbereich und der<br />
andere für den Außenbereich der Platte zuständig.<br />
Die induktive Aufzeichnung wurde bis 1991 verfolgt und<br />
eingesetzt. Stellen wir uns einen solchen Aufzeichnungs<br />
Schreib/Lesekopf als aufgeschnittenen Transformator mit<br />
einer entsprechenden Kupferspule vor. Der Schreibvorgang<br />
verlangt nun eigentlich wenige Kupferwindungen bei Verwendung<br />
eines möglichst dicken Drahtes, damit möglichst viel<br />
Strom transportiert werden kann und ein gut durchmagnetisiertes<br />
Bit auf der Magnetschicht erzeugt wird. Das Lesen<br />
eines Bits verlangt aber genau das Gegenteil, nämlich möglichst<br />
viele Kupferwindungen bei einem möglichst dünnen<br />
Kupferdraht, damit das Streufeld einer Informationseinheit<br />
eine möglichst hohe induktive Spannung hervorruft, die dann<br />
als eindeutiges Lesesignal abgegriffen werden kann. Der<br />
Kopf wurde aufgrund der gegensätzlichen Anforderungen<br />
bei der Anzahl der Windungen und der Dicke des Kupferdrahtes<br />
so gestaltet, dass beide Vorgänge möglich waren.<br />
Dieser Kompromiss schaffte aber eine direkte Abhängigkeit<br />
bezüglich der Geschwindigkeit zwischen Kopf und Platte.<br />
Drehte man zu schnell, wurde der Schreibvorgang schwierig,<br />
drehte man zu langsam, reichte die Drehgeschwindigkeit<br />
nicht aus, um eine entsprechend hohe induktive Spannung<br />
zu generieren, die dann als sauberes Lesesignal abgegriffen<br />
werden konnte. Der komplexeste Fertigungsprozess in dieser<br />
Zeit war die Herstellung der Platte selbst.<br />
Als Magnetisierungsträger wurden Eisenoxydpartikel, also<br />
Rostpartikel, verwendet und die Kunst war es, diese Rostpartikel<br />
möglichst homogen in einer Kunstharzmasse zu verteilen,<br />
um dann einigermaßen gleichmäßig magnetisieren zu<br />
können. Der Herstellprozess der Köpfe war im Vergleich dazu<br />
einfacher.<br />
Diese braunen Platten bereiteten Anfang der 90erJahre<br />
(1990–1993) enorme Probleme, speziell bei den Modellen 1,<br />
2 und 3 der 3390Familie, weil sich nach langjähriger Benutzung<br />
die Eisenoxydpartikel durch die andauernden Drehkräfte<br />
aus der Kunstharzmasse herausarbeiteten und sich an<br />
den Köpfen anlagerten. Die Anlagerung dieser Rostpartikel<br />
erzeugte dann den berühmten Flugeffekt, d.h., der Abstand<br />
zwischen den Köpfen und der Plattenoberfläche wurde<br />
immer größer, bis eine Höhe eintrat, die es nicht mehr erlaubte,<br />
dass geschrieben oder gelesen werden konnte. In einer einzigartigen<br />
Aktion, die über zwei Jahre in Anspruch nahm,<br />
tauschte die <strong>IBM</strong> damals alle weltweit installierten Plattenstapel<br />
aus.<br />
Bei der induktiven Aufzeichnungstechnik wurden lineare<br />
Zugriffsmechanismen eingesetzt, die von der Mechanik<br />
sehr aufwendig gestaltet waren, um den Kopf, der ja sowohl<br />
für das Schreiben als auch das Lesen zuständig war, exakt<br />
über einer Spur zu positionieren.<br />
1991 verabschiedete sich <strong>IBM</strong> von der damals eingesetzten<br />
induktiven Aufzeichnung und führte als erstes Unternehmen<br />
MR-Technologie für die Kopftechnik (magnetoresistive<br />
Aufzeichnung) bei den Produkten 3390 Modell 3 und 9 sowie<br />
bei dem 9340 <strong>System</strong> mit seinen 5,25ZollPlatten ein. Heute<br />
arbeitet jeder Hersteller mit dieser Technologie, die <strong>IBM</strong> entwickelt<br />
hat. Die MRKopftechnik hatte so viel Potenzial für die<br />
Weiterentwicklung, dass uns diese Technologie bis in die<br />
heutige Zeit begleitet (2008). Der Unterschied zur induktiven<br />
Aufzeichnung liegt darin, dass man nicht mehr mit einem<br />
Prinzip der induktiven Aufzeichnungstechnik Prinzip der magnetor-resistiven Aufzeichnungstechnik<br />
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<br />
der Kupferspulen so ausgelegt sein muss, dass sowohl das<br />
Schreiben als auch das Lesen möglich wird. Der MRKopf<br />
verwendet nach wie vor für den Schreibvorgang einen<br />
induk tiven Kopf, bei dem Anzahl und Dicke der Kupferspulen<br />
jetzt aber so ausgelegt sind, dass ein optimaler Schreibvorgang<br />
stattfinden kann. Mit dem Lesen hat dieser Kopf<br />
nichts mehr zu tun. Damit werden wesentlich schnellere<br />
Drehgeschwindigkeiten möglich. Für den Lesevorgang<br />
macht man sich den „magnetoresistiven Effekt aus der Physik“<br />
zunutze, dass Metalle oder Legierungen ihren Widerstand<br />
verändern können, wenn sie in den Einfluss eines Magnetfelds<br />
geraten. Gearbeitet wird in der Regel mit einem Nickel<br />
EisenFilm, der an Schwachstrom angeschlossen ist. Gerät<br />
dieser Slider in den Einflussbereich eines Magnetfelds,<br />
ändert sich die Ausrichtung der Elektronen. Wenn man das<br />
entsprechend verstärkt, bekommt man ein klares, eindeutiges<br />
Lesesignal. Mit diesem Verfahren können selbst<br />
kleinste Streufelder einzelner Informationseinheiten abgegriffen<br />
werden. Auf diese Weise schafft man einen Spezialisten<br />
für den Schreibvorgang und einen Spezialisten für den<br />
Lesevorgang.<br />
Parallel dazu, als zweites wichtiges Element, änderte sich die<br />
Plattenherstellung. Die Laminierverfahren und Vakuumprozesse<br />
waren inzwischen so weit, dass auf der Platte mit Dünnfilmbeschichtung<br />
(Legierungen) gearbeitet werden konnte und<br />
anstelle von Eisenoxyd nun ein Metallfilm zum Einsatz kam.<br />
Der Metallfilm wird unter Vakuum auf eine speziell gehärtete<br />
Glasplatte gesprüht (dieser Vorgang wird als Kathodenzerstäubung<br />
bezeichnet). Anschließend läuft die Platte direkt<br />
vom Vakuum in einen Ofen, um „gebacken“ zu werden (dieser<br />
Vorgang wird als Sputtern bezeichnet). Durch den<br />
Erhitzungs prozess (Sputtern) entstehen im Dünnfilm „Grains“,<br />
also Körner strukturen, und die einzelnen Grains stellen die<br />
Magnetisierungsträger der Platte dar. Die Herstellung solcher<br />
Dünnfilm platten ist vom Prinzip bis in die heutige Zeit beibe<br />
halten worden und wird etwas später im Teil der AFCTechnik<br />
näher beschrieben. Mit der Kombination von MRKopftechnologie<br />
und Dünnfilmplatten war es möglich, die Aufzeichnungsdichte<br />
von damals – 1991, bei der Einführung – 16<br />
Millionen Bits auf dem Quadratzentimeter auf über 5 Milliarden<br />
Bits auf dem Quadratzentimeter zu steigern. Das entspricht<br />
einer Steigerung von über Faktor 300 und stellt eine<br />
einmalige technologische Evolution dar, wie sie in<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 231
Technologie-Anhang<br />
keinem anderen tech nologischen Segment vom Steige<br />
rungsfaktor her jemals erzielt wurde.<br />
Der dritte treibende Faktor 1991 war die Einführung neuer<br />
Subsystemarchitekturen, der RAIDbasierenden <strong>System</strong>e.<br />
Die RAID-Architekturen leiteten den Schritt ein, von großen<br />
Plattengrößen in kleinere Formfaktoren zu wechseln. Die<br />
kleinen Platten hatten zwar nicht den vergleichbaren Zuverlässigkeitsfaktor<br />
wie die großen braunen Platten, die sogenannten<br />
SLEDs (Single Large Expensive Disk), wie sie am<br />
Schluss ihrer Lebensperiode bezeichnet wurden, benötigten<br />
diesen aber auch nicht, weil Laufwerkausfälle in einem Array<br />
durch RAID abgesichert waren (siehe auch unter RAID).<br />
Im Jahr 1990 integrierte <strong>IBM</strong> in die damals gefertigten 5,25<br />
und 3,5ZollLaufwerke ein neues EncodingVerfahren, das<br />
als PRML Encoding bezeichnet wird und heute noch im<br />
Einsatz ist. Partial Response/Maximum Likelyhood<br />
(PRML) ist ein Schreibverfahren, um Daten möglichst platzsparend<br />
auf magnetische Datenträger zu schreiben. Dazu<br />
werden diese Daten vorher codiert. Durch diesen Trick<br />
erhält man eine höhere Datendichte auf der Oberfläche<br />
einer Festplatte. Dies geschieht vom Nutzer völlig unbemerkt<br />
durch den Controller der Festplatte. Im Gegensatz zu<br />
älteren Verfahren wie MFM (Modified Frequence Modulation)<br />
werden beim Lesen des Datenträgers keine einzelnen<br />
MagnetfeldUmkehrungen im analogen Signalstrom identifiziert<br />
und deren Abfolge als Sequenz von Daten und Synchronisierungsbits<br />
interpretiert. Stattdessen wird das analoge<br />
Signal in Abschnitte zerlegt, diese aufbereitet („Partial<br />
Response“) und das Ergebnis mit vorgegebenen Mustern<br />
verglichen, um das ähnlichste zu finden („Maximum Likelyhood“).<br />
Jedes der vorgegebenen Muster steht für eine<br />
Einführung von PRML-Kanälen in <strong>IBM</strong> Platten<br />
Platte Kapazität<br />
Redwing 0681<br />
Feb. 1990<br />
Corsair 0663<br />
Sep. 1991<br />
Allicat 0664<br />
Nov. 1992<br />
Spitfire 0662<br />
März 1993<br />
Starfire-Reihe<br />
0667/0668<br />
Nov. 1993<br />
GB<br />
Durchmesser<br />
Zoll<br />
Datenrate<br />
MB/S<br />
bestimmte Bitfolge. PRML erlaubt eine 30 – 40 % höhere<br />
Datendichte als MFM. PRML wird heute noch bei modernen<br />
Festplatten eingesetzt, aber mehr und mehr von EPRML<br />
(Enhanced) verdrängt, das wegen seiner verbesserten<br />
Algorithmen und Signalverarbeitung 20 bis 70 % höhere<br />
Datendichten ermöglicht.<br />
PRML wurde 1990 erstmals für Platten der <strong>System</strong>e <strong>IBM</strong><br />
RS/6000 und AS/400 eingesetzt, weiterentwickelt und<br />
danach auch bei damals vorrangig gefertigten 3,5ZollLaufwerken<br />
aller <strong>IBM</strong> Produktreihen genutzt, ebenso in vielen<br />
Folgeprodukten. Entwickelt wurde das Verfahren im <strong>IBM</strong><br />
Labor in Rüschlikon bei Zürich.<br />
Ein Beispiel: Wurden herkömmlich etwa 800– 900 durchma<br />
gnetisierte Grains benötigt, um eine stabile Informationseinheit<br />
abzubilden, konnte durch das PRMLVerfahren im Laufe<br />
der Jahre die Anzahl der Grains auf 200– 250 reduziert werden,<br />
d. h. vierfach höhere Kapazitäten.<br />
Die kapazitiven Auswirkungen von PRML sah man vor allem<br />
von 1995 bis 1997, wo sich die Kapazitäten der damals produzierten<br />
3,5ZollLaufwerke innerhalb von 12 bis 15 Monaten<br />
verdreifachten.<br />
1997 wurde als Weiterentwicklung der MRKöpfe die GMR-<br />
Technologie, die giantmagnetoresistance Lesekopftechnik,<br />
einge führt, die vor allem das Auslesen von kleinsten Streu<br />
feldern erlaubte. Den GMR-Effekt entdeckten Ende der<br />
1980erJahre unabhängig voneinander Peter Grünberg an<br />
der KFA in Jülich und Albert Fert an der Universität Paris<br />
Süd. Bei beiden Entdeckungen wurden extrem niedrige<br />
Temperaturen und starke magnetische Felder zur Erzeu<br />
Aufzeichnung<br />
Dichte Mb/sq“<br />
Kopftype<br />
Plattenart<br />
232 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
PRML<br />
0.857 5¼ 3 63 MIG Dünnfilm 1. Gen.<br />
1.0/1.2 3½ 3 132 MR Dünnfilm 1. Gen.<br />
2.0 3½ 5.2 264 MR Dünnfilm 2. Gen<br />
1.0 3½ 5.2 354 MR Dünnfilm 2. Gen<br />
1.0 – 5.2 3½ 12.2 564 MR Dünnfilm 3. Gen
gung des Effekts benötigt. Einige Zeit nach diesen Arbeiten<br />
begannen Stuart Parkin und andere Forscher im Almaden-<br />
Forschungs zentrum von <strong>IBM</strong> in San Jose, Kalifornien, mit<br />
dem Versuch, den Effekt bei Normaltemperatur und mit<br />
weniger exotischen Materialzusammensetzungen für die<br />
Massenfertigung weiterzuentwickeln. Sie benötigten dazu<br />
viele Jahre und erforschten mehr als 30.000 unterschiedliche<br />
MultilayerMaterialkombinationen. 1997 erhielten die<br />
drei genannten Forscher gemeinsam den Europhysik-Preis<br />
für die GMREntwicklung. Peter Grünberg und Albert Fert<br />
wurden zudem 2007 mit dem Nobelpreis für Physik ausgezeichnet.<br />
Der GMREffekt (engl. giant Magnetoresistance, dt. Riesenmagnetwiderstand)<br />
wird in Strukturen beobachtet, die aus<br />
sich abwechselnden magnetischen und nichtmagnetischen<br />
dünnen Schichten mit einigen Nanometern Schichtdicke<br />
bestehen. Der Effekt bewirkt, dass der elektrische Widerstand<br />
der Struktur von der gegenseitigen Orientierung der<br />
Magnetisierung der magnetischen Schichten abhängt, und<br />
zwar ist er bei Magnetisierung in entgegengesetzte Richtungen<br />
deutlich höher als bei Magnetisierung in die gleiche<br />
Richtung.<br />
Dabei handelt es sich um einen quantenmechanischen<br />
Effekt, der durch die Spinabhängigkeit der Streuung von<br />
Elektronen an Grenzflächen erklärt werden kann. Elektronen,<br />
die sich in einer der beiden ferromagnetischen Schichten<br />
gut ausbreiten können, weil ihr Spin günstig orientiert ist,<br />
werden in der zweiten ferromagnetischen Schicht stark<br />
gestreut, wenn diese entgegengesetzt magnetisiert ist. Sie<br />
durchlaufen die zweite Schicht aber wesentlich leichter,<br />
wenn die Magnetisierung dieselbe Richtung aufweist wie in<br />
der ersten Schicht.<br />
Werden zwei Schichten eines ferromagnetischen Materials<br />
durch eine dünne nichtmagnetische Schicht getrennt, so<br />
richten sich die Magnetisierungen bei bestimmten Dicken<br />
der Zwischenschicht in entgegengesetzten Richtungen aus.<br />
Schon kleine äußere magnetische Felder reichen aber aus,<br />
um diese antiferromagnetische Ordnung wieder in die ferromagnetische<br />
Ordnung zurückzuführen.<br />
In Verbindung mit dem GMREffekt bewirken Variationen des<br />
äußeren Magnetfelds in geeigneten Strukturen daher große<br />
Änderungen des elektrischen Widerstands der Struktur.<br />
Die Möglichkeiten, den Effekt in einem Sensor für ein<br />
magnetisches Feld einzusetzen (und damit als einen neuen<br />
Typ von Lesekopf in einer Festplatte), wurden schnell durch<br />
ein von Stuart Parkin geleitetes <strong>IBM</strong> Forschungsteam entdeckt,<br />
indem er zeigte, dass der Effekt auch in polykristallinen<br />
Schichten auftritt.<br />
<strong>IBM</strong> stellte im Dezember 1997 das erste kommerzielle Lauf<br />
werk her, das diesen Effekt nutzte. GMR ist bis heute im Einsatz.<br />
Neben der Anwendung in Festplatten wird der GMR<br />
Effekt auch in Magnetfeldsensoren der Automobilindustrie<br />
und Automatisierungsindustrie ausgenutzt.<br />
1999 konnten die ersten Micro-Drives – damals mit einer<br />
Kapazität von 340 MB – auf dem kommerziellen Markt einge<br />
führt werden. Die Kapazitäten der MicroDrives entwickelten<br />
sich rasch weiter und heute, im Jahr 2008, werden bereits<br />
Kapazitäten von 6 GB und 8 GB angeboten.<br />
<strong>IBM</strong> Micro-Drive<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 233
Technologie-Anhang<br />
Durch einen glücklichen Zufall entdeckten die <strong>IBM</strong> Entwickler<br />
in der 2. Hälfte des Jahres 1999 die Möglichkeit einer neuen<br />
Aufzeichnungstechnik. Man sprach und spricht heute noch<br />
von der Entdeckung des paramagnetischen Effekts. Schon<br />
am 4. Oktober 1999 konnte das <strong>IBM</strong> Labor in Almaden eine<br />
HardDiskLaborversion in dieser neuen Technik demonstrieren.<br />
In einer Presseveröffentlichung am 4. Oktober 1999<br />
wurde von einer Aufzeichnungsdichte von 35,3 Gbits/inch2 gesprochen – das sind über 5 Milliarden Bits auf den<br />
Quadratzentimeter. Damit war die Sprengung der bis dahin<br />
für MRTechnik gesehenen physikalischen Grenzen eingeleitet.<br />
Mit dieser Technik lassen sich vierfach höhere Kapazitäten<br />
auf demselben Raum realisieren!<br />
Um die magnetische Beschichtung einer Festplatte heute zu<br />
fertigen, wird unter Vakuum eine komplexe Legierung auf<br />
eine GlasscheibenOberfläche gesprüht (Kathodenzerstäubung),<br />
die anschließend „gebacken/gebrannt“ wird (Sputtern).<br />
Dabei entstehen ca. 80–100 Nanometer große magnetische<br />
Körner (MRTechnik). Für das Speichern von einem<br />
Bit richtet ein induktiver Schreibkopf die magnetische Orientierung<br />
von einigen Hundert solcher Partikel aus. Um Speicherdichten<br />
zu vergrößern, versuchte man, die Zahl der Körner<br />
zu reduzieren, die ein Bit bilden. Das hatte jedoch den<br />
gravierenden Nachteil, dass sich das SignalRauschVerhältnis<br />
verschlech terte. Deshalb versuchte man, die Körner zu<br />
verkleinern und die Anzahl beizubehalten, die ein Bit bilden.<br />
Kommt allerdings die Korngröße unter ein bestimmtes Limit,<br />
verlieren die Par tikel ihre ferromagnetischen Eigenschaften<br />
(paramagnetisches Limit). Diesen Effekt kann man teilweise<br />
ausgleichen, indem man „härtere“ magnetische Materialien<br />
mit einer höheren Koerzitivfeldstärke verwendet. Problem<br />
hier ist die Tatsache, dass „härtere“ Materialien wiederum<br />
schwieriger zu magnetisieren sind und damit wesentlich<br />
mehr Energie für die Magnetisierung benötigen.<br />
Mit der Entdeckung des paramagnetischen Effekts und der<br />
paramagnetischen Aufzeichnungsmöglichkeit wurde eine<br />
Korngröße von ca. 25–30 Nanometer möglich, ohne dass<br />
auf härtere Materialien ausgewichen werden musste. Das<br />
bedeutete für die Aufzeichnungsdichte eine Vervierfachung<br />
der Kapazitäten, die auf demselben Raum abgebildet werden<br />
konnten.<br />
Dem MRKopf wird ein Spezialkopf vorgeschaltet, der ein vertikales<br />
Bit in der Metallkörnerstruktur erzeugt. Gleich danach<br />
wird das horizontale Datenbit geschrieben. Beide Bits<br />
stabi lisieren sich bei bestimmten Legierungen und lassen<br />
es zu, das horizontale Datenbit wesentlich kleiner zu gestalten<br />
und mit wesentlich höheren Drehgeschwindigkeiten und<br />
Datenraten auf der Platte zu arbeiten.<br />
Die Massenproduktion dieser Technik wäre sehr komplex<br />
und kostenintensiv geworden. Deshalb beschritten die Entwickler<br />
andere Wege. Dies führte dazu, dass <strong>IBM</strong> die<br />
Massenproduk tion der sogenannten Pixie-Dust-Technologie<br />
im Mai 2001 einleitete, was damals die gesamte Fachpresse<br />
aufrüttelte, weil noch wesentlich höhere Kapazitäten bei noch<br />
schnelleren Drehgeschwindigkeiten realisiert werden konnten.<br />
Im Jahr 2000 erhielt die <strong>IBM</strong> als erste Firma die National<br />
Medal of Technology for Innovations in <strong>Storage</strong> von der<br />
amerikanischen Regierung, eine Auszeichnung, die bisher<br />
ausschließlich an Einzelpersonen verliehen wurde. Grund für<br />
die Auszeichnung: die Massenproduktion von MicroDrives<br />
und die Entdeckung des paramagnetischen Effekts. Sie ist<br />
eine der höchsten technologischen Ehrungen.<br />
Die AFCAufzeichnungstechnik (Pixie Dust) erlaubt es, bei<br />
mittleren Korngrößen von 4–8 Nanometer im Dünnfilm eine<br />
wesentlich höhere thermische Langzeitstabilisierung zu erzielen,<br />
ohne dafür eine höhere Koerzitivfeldstärke des Materials<br />
in Kauf nehmen zu müssen. Das heißt: Verwendung von<br />
wesentlich kleineren Körnern als Magnetisierungsträger bei<br />
weicheren Materialien. Dazu wird dem bisher verwendeten,<br />
klassischen Metallfilm aus Kobalt, Platin und Chrom noch Bor<br />
zugesetzt.<br />
Prinzip der AFC(AntiFerromagnetically Coupled)-Aufzeichnungstechnik<br />
234 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Diese Technologie nennt sich AFC (AntiFerromagnetically<br />
Coupled) oder, von den <strong>IBM</strong> Forschern in Almaden geprägt,<br />
„Pixie Dust“. AFCMedien bestehen aus drei Schichten.<br />
Zwischen zwei magnetischen Lagen, die aus einer komplexen<br />
KobaltPlatinChromBorLegierung bestehen, befindet<br />
sich eine nur drei Atomlagen (6 Angström) dicke Schicht<br />
aus dem nichtmagnetischen Metall Ruthenium. Bei<br />
genau dieser Dicke sorgt die RutheniumSchicht dafür, dass<br />
die Magnetisierungsausrichtungen der beiden anderen<br />
magnetischen Schichten antiparallel gekoppelt sind. Das<br />
heißt, die untere magnetische Schicht ist stets andersherum<br />
magnetisiert als die obere Schicht. Dies führt zu einer<br />
enormen Stabilisierung der beiden Bits und lässt erheblich<br />
höhere Schreibdichten (bis zu 100 Gigabits pro<br />
Quadratzoll und mehr – ca.15–20 Milliarden Bits auf<br />
dem Quadratzentimeter) bei wesentlich höheren<br />
Drehgeschwindig keiten und Datenraten zu. Wegen der<br />
wundersamen Wirkung der RutheniumSchicht tauften<br />
die <strong>IBM</strong> Forscher in Almaden diese neue Technik „Pixie<br />
Dust“, also Feenstaub, angelehnt an Peter Pans Märchen.<br />
Ein weiterer Vorteil liegt in der Tatsache, dass mit der heu<br />
tigen MRSchreib/Lesekopftechnologie weitergearbeitet<br />
werden kann. Die Miniaturisierung dieser Köpfe ist heute<br />
bereits so weit, dass Schreib/Lesespaltbreiten von<br />
1– 2 Nanometer als Laborversionen ermöglicht werden.<br />
Dies stellt ein weiteres Potenzial dar, die Aufzeichnungsdichte<br />
voranzutreiben.<br />
Die Plattenaufzeichnungstechnologien werden sicherlich mit<br />
der neuen AFCTechnik in kapazitive Bereiche von über 1 TB<br />
in den Jahren 2010–2011 gehen können.<br />
Wegen der Hitzeentwicklung in den Laufwerken muss man<br />
sich immer mehr über das Packaging, im Speziellen die<br />
Kühlung dieser Platten Gedanken machen. Wassergekühlte<br />
Racks könnten eine Alternative darstellen. In der Entwicklung<br />
befinden sich auch Möglichkeiten einer „Alttechnologie“, wie<br />
sie bei den 3380 Platten eingesetzt wurde, allerdings in entsprechend<br />
miniaturisierter Form. Dabei wird mit zwei Köpfen<br />
auf dem Arm gearbeitet, der eine kontrolliert den Innenbereich<br />
der Platte, der andere den Außenbereich. Dies ist eine<br />
Möglichkeit, die Mehrkapazität unter dem Aktuator leistungsmäßig<br />
auszugleichen, ohne die Drehgeschwindigkeit des<br />
Plattenstapels massiv erhöhen zu müssen. Es bestehen also<br />
Möglichkeiten, die Kapazitäten in den nächsten Jahren voranzutreiben.<br />
Im Jahr 2003 gründeten <strong>IBM</strong> und Hitachi eine gemeinsame<br />
Entwicklungs- und Fertigungs-Allianz für Plattenlaufwerke.<br />
In dieser Allianz ist <strong>IBM</strong> für die Weiterentwicklung der Plattentechnologie<br />
zuständig und Hitachi für die Massenproduktion.<br />
Diese Allianz hat sich bis heute bewährt und es ist davon<br />
auszugehen, dass sie noch viele Jahre Bestand haben wird<br />
und auf andere technologische Bereiche ausgedehnt wird.<br />
Inzwischen ist Hitachi der drittgrößte Plattenlieferant weltweit.<br />
Das zweitgrößte Produktionsvolumen wird durch Western<br />
Digital abgedeckt. Der größte ist nach wie vor die Firma<br />
Seagate, die etwa 40 % des weltweiten Gesamtvolumens<br />
produziert. Heute, im Jahr 2010, werden zwei Formfaktoren<br />
produziert: 2,5Zoll und 3,5ZollLaufwerke.<br />
Spätestens innerhalb der nächsten zwei Jahre – da sind<br />
sich alle Plattenhersteller einig – wird generell nur noch mit<br />
einem Formfaktor gearbeitet werden, weil sich kein Hersteller<br />
bei Preisverfällen von etwa 40 % pro Jahr die Fertigung<br />
von zwei unterschiedlichen Formfaktoren leisten kann. Die<br />
3,5ZollLaufwerke, die bisher vor allem in Plattensubsystem<br />
Architekturen eingebaut sind, werden durch 2,5ZollLaufwerke<br />
ersetzt.<br />
Voraussetzung für diese Strategie ist die Produktion von<br />
leis tungsstarken 2,5ZollLaufwerken. Es kristallisiert sich<br />
heraus, dass dann innerhalb der 2,5ZollBauweise drei<br />
unterschiedliche Techniken eingesetzt werden: die AFC-<br />
Technik, eine neue Technik mit Perpendicular Recording<br />
und IDEPlatten, die als ATA, SATA oder FATAPlatten<br />
bekannt sind. Diese Vorgehensweise macht die Welt einfacher.<br />
Nur noch ein Formfaktor, das bedeutet:<br />
AFC als hochpreisiges Hochleistungslaufwerk mit extremer<br />
Zuverlässigkeit, Laufwerke mit Perpendicular Recording als<br />
mittelpreisiges Laufwerk mit guter Leistung und vergleichbarer<br />
Zuverlässigkeit wie AFC und die billigen SATA/FATAPlatten,<br />
die vom Aufbau her IDEPlatten entsprechen.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 235
Technologie-Anhang<br />
Perpendicular Recording<br />
Bei Perpendicular Recording stehen die magnetischen<br />
Momente, die zusammen mit den verwendeten logischen<br />
Schreibverfahren wie PRML jeweils ein logisches Bit repräsentieren,<br />
nicht parallel zur Rotationsrichtung des Datenträgers,<br />
sondern senkrecht dazu. Dies führt zu einer potenziell<br />
wesentlich höheren Datendichte, womit auf der gleichen<br />
Ober fläche mehr Daten gespeichert werden können. Fest<br />
gestellt wurde dies erstmals bereits 1976 von Professor<br />
Shunichi Iwasaki am Tohoku Institute of Technology in<br />
Japan.<br />
Nachteilig ist, dass die kleineren WeißBezirke auch einen<br />
kürzeren Abstand zwischen Schreib/Lesekopf und der<br />
Magnetoberfläche bedingen, um die Daten noch schreiben<br />
und lesen zu können. Daher ist diese Aufzeichnungstechnik<br />
technisch schwieriger zu realisieren. Das Gegenstück zum<br />
Perpendicular Recording ist das bisher eingesetzte Longitudinal<br />
Recording (englisch für Längsaufnahme). Hier tritt<br />
jedoch bei zu enger Aneinanderreihung der Magnetpartikel<br />
(zu hohe Datendichte) der sogenannte superparamagnetische<br />
Effekt auf, d. h., die einzelnen Bits verlieren ihre<br />
magnetische Richtung und beginnen zu „kippen“, was zu<br />
Datenverlust führt. 3,5ZollFestplatten erreichen somit eine<br />
maximale Kapazität von derzeit 1 TB, 2,5ZollFestplatten<br />
kommen auf derzeit 320 GB. Das entspricht einer durchschnittlichen<br />
Datendichte von 132 Gbit pro Quadratzoll<br />
bzw. 20,46 Gbit pro Quadratzentimeter.<br />
Die Festplattenkapazitäten können durch diese neue Aufzeichnungstechnik<br />
um das maximal Zehnfache gesteigert<br />
werden. Zudem wird durch die deutlich höhere Datendichte<br />
ein Zuwachs der Lese/Schreibgeschwindigkeit erreicht, da<br />
der Lesekopf pro Umdrehung mehr Daten liest und damit<br />
bei gleicher Umdrehungszahl die Datenrate steigt. Seagate<br />
liefert bereits seit 2006 Platten mit Perpendicular Recording<br />
aus.<br />
Aufzeichnungsverfahren im Vergleich<br />
HAMR (Heat Assisted Magnetic Recording)<br />
HAMR (Heat Assisted Magnetic Recording) bezeichnet ein<br />
Verfahren, das noch größere Datendichten bei Festplatten<br />
erlaubt als das neue Verfahren mit Perpendicular Recording,<br />
welches bereits die Marktreife erreicht hat. Somit sollen<br />
künftig Festplatten mit Volumina im mittleren einstelligen<br />
Terabytebereich möglich sein. Mit Hilfe von HAMR gelingt<br />
das Schreiben von Daten auch auf Materialien mit einem<br />
schwach ausgeprägten superparamagnetischen Effekt. Der<br />
sogenannte Effekt tritt bei heutigen Festplatten auf, wenn<br />
man die Datendichte zu sehr vergrößert. Dies bedeutet,<br />
dass die Domänen, in die Daten geschrieben werden, ihre<br />
ferromagnetischen Eigenschaften verlieren und superparamagnetisch<br />
werden, wodurch die Bits zerstört werden.<br />
Mit HAMR wird die Domäne, in welche Daten geschrieben<br />
werden sollen, zunächst lokal durch einen Laser erhitzt, um<br />
das für einen Schreibvorgang nötige Magnetfeld möglichst<br />
klein zu halten und das Schreiben trotz eines schwach ausgeprägten<br />
superparamagnetischen Effekts zu ermöglichen.<br />
Da beim Erhitzen aber das schützende Schmiermittel der<br />
Festplatte verdampft, will der Festplattenhersteller Seagate<br />
Nachschub in nanometerdünnen Kohlenstoffröhrchen speichern,<br />
welchen letztere bei Bedarf auf die betroffenen<br />
Domänen sprühen sollen.<br />
Es wird bereits spekuliert, welche Speicherkapazität mittels<br />
dieser Technologie erreicht werden kann. So berichtet<br />
itwire.com am 4. Januar 2007, dass es vielleicht bereits im<br />
Jahr 2010, also heute, Kapazitäten von 37,5 TB von Seagate<br />
geben könnte. Das wäre 37,5mal so viel wie die zur Zeit<br />
größte Festplatte von Hitachi mit rund 1 TB. Allerdings wird<br />
auch berichtet, dass sich mittels dieser Technologie die<br />
Anzahl der HeadCrashes erhöhen könnte und somit die<br />
Qualität der Festplatte darunter leiden würde. Diese Spekulation<br />
steht jedoch im Widerspruch zu der auf Techworld<br />
zitierten Aussage von Seagate, wonach heute im Jahr 2010<br />
mit 3TBFestplatten zu rechnen sei.<br />
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<br />
Anhang 237
Technologie-Anhang<br />
Plattenrotunde im <strong>IBM</strong> Museum Sindelfingen<br />
Das Haus zur Geschichte der <strong>IBM</strong> Datenverarbeitung in<br />
Sindelfingen, Bahnhofstraße 43<br />
Im <strong>IBM</strong> Museum können heute zwei einzigartige <strong>System</strong>e<br />
besichtigt werden, die Speichereinheit <strong>IBM</strong> RAMAC 355,<br />
die 1957 auf den Markt kam, und das legendäre EDV<br />
<strong>System</strong> <strong>IBM</strong> 1401 mit Plattenspeicher <strong>IBM</strong> 1311, das im<br />
Oktober 1959 angekündigt wurde und letztes Jahr 2009<br />
den 50. Jahrestag feierte.<br />
Besonders bemerkenswert ist die jetzt fertiggestellte Plattenrotunde,<br />
die die <strong>IBM</strong> Geschichte der Magnetplatten von<br />
1956 bis ins Jahr 2000 aufzeigt und viele Exponate der<br />
unterschiedlichsten Technologien in diesem Zeitraum präsentiert.<br />
Man kann sich im <strong>IBM</strong> Museum auf eine faszinierende<br />
Zeitreise durch die Welt der <strong>IBM</strong> Magnetplattenspei<br />
<strong>IBM</strong> Plattenrotunde im <strong>IBM</strong> Museum Sindelfingen<br />
cher begeben. Das absolute „Highlight“ der Rotunde sehen<br />
Sie ganz links in der Plattenrotunde unter Plexiglas: Der<br />
Zugriffsmechanismus der RAMAC 355, der funktional vorgeführt<br />
werden kann. Dazu befindet sich direkt hinter der<br />
Rotundenwand der dazu notwendige Kompressor (im Bild<br />
nicht sichtbar).<br />
238 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Die Initiatoren und Erbauer der Plattenrotunde im <strong>IBM</strong><br />
Museum waren die Herren Hans W. Spengler und Heinz<br />
Graichen. Es dauerte über zehn Jahre, bis diese Arbeit fertiggestellt<br />
und zur Besichtigung freigegeben werden konnte.<br />
Allein schon die Datensammlung benötigte viele Jahre, die<br />
vor allem von Hans W. Spengler vorangetrieben wurde. Er<br />
hat dazu von jeder <strong>IBM</strong> Magnetplatte von 1956 bis ins Jahr<br />
2000 ein Plattenprofil mit allen technischen Einzelheiten<br />
erstellt und erfreulicherweise diese Profile für den Update<br />
des <strong>IBM</strong> <strong>System</strong> <strong>Storage</strong> <strong>Kompendium</strong>s 2010 zur Verfügung<br />
gestellt. Sie finden diese Profile auf den nächsten Seiten.<br />
Der Autor des <strong>Kompendium</strong>s trug dazu bei, dass die im<br />
<strong>IBM</strong> Werk Mainz gesammelten Ausstellungsstücke an das<br />
<strong>IBM</strong> Museum vor ein paar Jahren überführt wurden, damit<br />
mit dem Aufbau der Plattenrotunde begonnen werden<br />
konnte. Ebenso finden Sie im Anschluss ein Interview, bei<br />
dem der Autor die damaligen Fachleute Heinz Graichen und<br />
Hans Spengler über den <strong>IBM</strong> RAMAC 350/355 Plattenspeicher<br />
befragt, wie die Zugriffseinheit mit dem Schreib/Lesekopf<br />
nicht prinzipiell, sondern real arbeitete.<br />
Hans W. Spengler<br />
Heinz Graichen<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 239
Technologie-Anhang<br />
Magnetplatten-Exponatesammlung Plattenrotunde <strong>IBM</strong> Museum in Sindelfingen<br />
Anfangsepoche der elektromagnetischen Speicherung<br />
Teilrotunde RAMAC 350/355 Zugriff und <strong>IBM</strong> 1301<br />
Darstellung von 1956–1961<br />
<strong>IBM</strong> RAMAC 350/355 Platte mit 24 Zoll Durchmesser<br />
Jahre 1956–1957<br />
<strong>IBM</strong> 1311 Zugriff 1962<br />
240 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Epoche der Wechselplatten<br />
Teilrotunde <strong>IBM</strong> 2314 offen (siehe unten) und <strong>IBM</strong> 3330<br />
Darstellung 1965–1972<br />
Epoche der Wechselplatten (Winchester-Zeit) und Epoche der fest<br />
eingebauten Platten mit externen Kontrolleinheiten<br />
Teilrotunde <strong>IBM</strong> 3340, 3350 und 3370<br />
Darstellung 1973–1979<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 241
Technologie-Anhang<br />
<strong>IBM</strong> 3340 Laufwerksdatenmodule 1973 <strong>IBM</strong> 3350 Festplatte 1975<br />
<strong>IBM</strong> 3370 Laufwerk 1979<br />
242 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Epoche der fest eingebauten Platten mit externen Kontrolleinheiten<br />
Teilrotunde <strong>IBM</strong> 3380 und <strong>IBM</strong> 3390<br />
Darstellung von 1981–1994<br />
<strong>IBM</strong> 3380 Laufwerk 1981<br />
<strong>IBM</strong> 3390 Laufwerk 1989<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 243
Technologie-Anhang<br />
PC XT Festplatte 5 ¼ Zoll 1980<br />
<strong>IBM</strong> Piccolo Laufwerk Hursley 1978<br />
<strong>IBM</strong> 0681 – Laufwerk 5 ¼ Zoll mit PRML 1990<br />
<strong>IBM</strong> RAMAC 9345 Laufwerkseinschub 1991<br />
244 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Epoche der RAID-<strong>System</strong>e und Anfänge der Epoche der<br />
Multiplattform-<strong>System</strong>e<br />
Teilrotunde <strong>IBM</strong> RAMAC und <strong>IBM</strong> ESS<br />
Darstellung von 1994–2000<br />
<strong>IBM</strong> RAMAC 1, 2, 3 Platten 1994–1998<br />
<strong>IBM</strong> ESS 9 GB SSA Laufwerke 1999–2000<br />
<strong>IBM</strong> Travelstar 1996–1998 als mobile Platte in Laptops<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 245
<strong>IBM</strong> Magnetplattenprofile<br />
Technische Spezifikationen<br />
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<br />
Anhang 247
<strong>IBM</strong> Magnetplattenprofile<br />
Technische Spezifikationen<br />
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<br />
Anhang 249
<strong>IBM</strong> Magnetplattenprofile<br />
Technische Spezifikationen<br />
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<br />
Anhang 251
<strong>IBM</strong> Magnetplattenprofile<br />
Technische Spezifikationen<br />
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<br />
Anhang 253
<strong>IBM</strong> Magnetplattenprofile<br />
Technische Spezifikationen<br />
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<br />
Anhang 255
<strong>IBM</strong> Magnetplattenprofile<br />
Technische Spezifikationen<br />
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<br />
Anhang 257
<strong>IBM</strong> Magnetplattenprofile<br />
Technische Spezifikationen<br />
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<br />
Anhang 259
<strong>IBM</strong> Magnetplattenprofile<br />
Technische Spezifikationen<br />
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<br />
Anhang 261
<strong>IBM</strong> Magnetplattenprofile<br />
Technische Spezifikationen<br />
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<br />
Anhang 263
<strong>IBM</strong> Magnetplattenprofile<br />
Technische Spezifikationen<br />
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<br />
Anhang 265
<strong>IBM</strong> Magnetplattenprofile<br />
Technische Spezifikationen<br />
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<br />
Anhang 267
<strong>IBM</strong> Magnetplattenprofile<br />
Technische Spezifikationen<br />
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<br />
Anhang 269
Interview des Autors Kurt Gerecke<br />
mit den RAMAC-Experten Heinz Graichen und Hans W. Spengler<br />
Kurt Gerecke:<br />
Warum war die Erfindung des Produktes RAMAC 305/350<br />
so bedeutend?<br />
Hans Spengler:<br />
Dem ersten Produkt RAMAC 305 mit dem Magnetplattenspeicher<br />
RAMAC 350 folgten ohne Unterbrechung über<br />
Jahrzehnte weitere Entwicklungen von Plattenspeichern mit<br />
dem Ziel, Kapazitätssteigerungen, Zugriffszeitverkürzungen,<br />
höhere Datenraten und geringere Kosten pro gespeichertem<br />
Megabyte zu erreichen. Den Startschuss für diese Entwicklung<br />
leitete die RAMAC 350 ein. Diese Entwicklungsgeschichte<br />
würdigte die American Society of Mechanical Engineers<br />
1984 dadurch, dass sie den RAMAC Plattenspeicher<br />
in Anerkennung des andauernden Einflusses auf die Plattenspeichertechnologie<br />
zur „International Historic Mechanical<br />
Engineering Landmark*“ erklärte (*Meilenstein).<br />
Abb. 1<br />
Kurt Gerecke:<br />
Wie arbeitete der Zugriffsmechanismus der RAMAC<br />
Plattenspeicher 350 (1956) und 355 (1957)? Ein einziges<br />
Schreib/Lesekopfpaar bediente alle 100 Speicherflächen.<br />
Wie muss man sich die Positionierung des Schreib/<br />
Lesekopfpaares vorstellen?<br />
Heinz Graichen:<br />
Positionieren bedeutet, einen Weg zurückzulegen. Die 100<br />
Speicheroberflächen sind auf 50 Trägerplatten aufgebracht<br />
und deren Stapelhöhe beträgt etwa 53 cm. Auf jeder<br />
Speicheroberfläche sind 100 Speicherspuren definiert. Die<br />
äußerste Spur (00) ist von der innersten (99) etwa 12,7 cm<br />
entfernt (Maximalweg = 78,4 cm). Das „in Position bringen“<br />
des S/LKopfpaares lösten die Kontrukteure mittels eines<br />
Wagens, der einen Zugriffsarm zunächst vertikal zur<br />
gewünschten Platte bringt und dort in dieser Position fest<br />
verriegelt. Danach wird in einer weiteren Phase der Zugriffsarm<br />
horizontal bis zur gewünschten Spur bewegt und eben<br />
270 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
falls fest verriegelt. Die Grafik „Zugriffsstation als Zeichnung“<br />
(Abb.1) lässt jeweils eingefärbt in Rot den Wagen<br />
und in Grün den Zugriffsarm erkennen.<br />
Hans Spengler:<br />
Damit hat Kollege Graichen den Weg beschrieben, doch<br />
dieser muss jetzt noch vollzogen werden. Ein raffiniert ausgedachter<br />
Stahlseilantrieb mit Seilantriebsrolle (siehe Abb. 1<br />
unten), Laufrolle (siehe Abb. 1 ganz oben) und zwei weitere<br />
Rollen am Wagen selbst bewirken sowohl das Auf und Ab<br />
des Wagens als auch das Rein und Raus des Zugriffsarmes.<br />
Dazu muss die Seilantriebsrolle vor und rückwärts<br />
laufen können. Dies bewirkt eine MagnetpulverDoppelkupplung<br />
für die eine oder die entgegengesetzte Drehrichtung.<br />
Beide Hälften laufen auf einer gemeinsamen Welle,<br />
die einen TachoGenerator (siehe Abb. 1 links) und die Seilantriebsrolle<br />
(siehe Abb. 1 rechts) treibt. Beide Kupplungshälften<br />
sind konusförmig ausgebildet, damit der mit Gummi<br />
belegte Konus des Zugriffsstationantriebsmotors die beiden<br />
Hälften entgegengesetzt antreiben kann. Der Abtrieb zur<br />
Seilantriebsrolle ist abhängig von der elektronischen Aktivie<br />
Abb. 2<br />
rung einer der beiden Hälften. Der Zugriffsstationantriebsmotor<br />
läuft ständig.<br />
Kurt Gerecke:<br />
Die Mechanik ist damit soweit klar. Doch wie setzt die Rechnerinstruktion<br />
„Suchen“ die Zugriffsstation in die Lage, mittels<br />
der Angaben zu Plattenoberfläche und Spur automatisch<br />
entsprechende Bewegungen durchzuführen und umzusetzen?<br />
Heinz Graichen:<br />
Auf Basis der bisherigen Erklärung betrachten wir die Zeichnung<br />
„Ablaufschema“ (Abb. 2). Ganz unten links finden wir<br />
die Seilantriebsrolle, den TachoGenerator und als „Black<br />
Box“ die elektronischen Steuerstufen für beide Antriebskupplungshälften.<br />
Die in die Box eingehende Steuerspannung<br />
kann positiv oder negativ sein. Ist sie positiv, wird der<br />
Wagen in die eine Richtung zur gewünschten Platte bewegt.<br />
Ist sie negativ, wird der Wagen in die andere Richtung zur<br />
ge wünschten Platte bewegt („rauf/runter“). Dies gilt sinngemäß<br />
ebenso für die Bewegungsrichtung des Zugriffsarmes<br />
(„rein/raus“).<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 271
Interview des Autors Kurt Gerecke<br />
mit den RAMAC-Experten Heinz Graichen und Hans W. Spengler<br />
Damit kennen wir bereits das Steuerungsprinzip der<br />
Antriebs kupplungen, doch noch nicht die Umsetzung der<br />
adressierten Speicherplatte (eine von 50) und adressierten<br />
Speicherspur (eine von 100) in entsprechende Abläufe<br />
und Bewegungswege.<br />
Hans Spengler:<br />
Für die Umsetzung des Steuerungsprinzips in Bewegungswege<br />
sind weitere Elemente erforderlich, die Heinz Graichen<br />
und ich aus umfänglichen Schaltbildern zu einem vereinfachten<br />
Schema (siehe Abb. 2 „Ablaufschema“)<br />
verdichtet haben. Das Wesentliche daran sind ein AdressrelaisSatz,<br />
zwei Widerstandsketten, jede mit Relaiskontakt<br />
Kette, ein Nulldetektor und eine Schaltlogik, die die Abläufe<br />
steuert, inklusive der AntriebskupplungSteuerstufen.<br />
Der AdressrelaisSatz: speichert die DiskPlattenseite<br />
(0099), die RelaiskontaktKetten stellen Nullpotenzial für die<br />
Zieladresse bereit und steuern die spätere S/LKopfauswahl.<br />
Ebenso speichern Relais die Spuradresse (0099). Die<br />
Adressrelais sind „2 von 5kodiert“ zwecks Gültigkeitsprüfung.<br />
Widerstandsketten: Jeder Bewegungsschritt wird durch<br />
einen Widerstand dargestellt. Hintereinandergeschaltet wird<br />
damit jeder Bewegungsweg in Widerstandsgrößen repräsentiert.<br />
An jede Widerstandskette ist eine nicht geerdete<br />
Gleichspannung (150 V) angelegt. Jede Kette hat einen<br />
Schleifkontakt, der die IstPosition in Form einer Spannung<br />
und deren Polarität abnimmt. Eine Kette dient der Disk und<br />
eine Kette der SpurDarstellung. Die AdressrelaisKontaktkette<br />
legt Nullpotenzial an die Zielposition an.<br />
Nulldetektor: Wenn IstPosition und Zielposition als Spannungsdifferenz<br />
und Polarität am Nulldetektor anliegen, liefert<br />
dieser das Signal „Nicht Null“, d. h., Bewegung in Richtung<br />
Ziel ist einzuleiten. Wir betrachten das Beispiel Wagenbewegung.<br />
Letzterer darf nur bewegt werden bei „Arm in Grundstellung“,<br />
wenn dieser also „ganz ausgefahren“ ist. Danach<br />
wird der Wagen erst entriegelt und dann solange bewegt,<br />
bis das „Null Signal“ die Bewegung stoppt, den Wagen verriegelt<br />
und dann über leitet zur Spurauswahl. Für letzteres<br />
gilt analog dasselbe. Das „Null Signal“ stoppt die Armbewegung,<br />
der Arm wird verriegelt, das Signal „Position gefunden“<br />
wird generiert und die Schreib/Leseköpfe werden geladen.<br />
Kurt Gerecke:<br />
Warum hat man die Widerstandskette für Disk und Arm nicht<br />
einheitlich gestaltet?<br />
Heinz Graichen:<br />
Aus konstruktiven Gründen war es damals nicht möglich,<br />
die Widerstandskette für Disk und Arm einheitlich zu gestalten.<br />
Für den Arm kam ein Spezialpotentiometer mit 10 präzisen<br />
Anzapfungen zusammen mit einer Messbrücke zum<br />
Einsatz, um die Spuren 00 bis 99 per Widerstandskette<br />
nachzubilden. Dies änderte jedoch nichts am angewandten<br />
Prinzip. Das Potentiometer ist am Wagen befestigt und wird<br />
durch die Zahnstange am Zugriffsarm und einem ebenfalls<br />
am Wagen befestigten Zahnrad betätigt. Die Zahnstange<br />
des Armes wird für ungeradzahlige Spuren durch einen<br />
„odd detent“ verriegelt. Die geradzahligen Spuren verriegelt<br />
der „even detent“. Dies verdoppelt die Zahngröße, die<br />
Stabilität und damit die Zuverlässigkeit.<br />
Kurt Gerecke:<br />
Jetzt haben wir sowohl die adressierte Speicherfläche als<br />
auch die adressierte Speicherspur erreicht. Der Zugriffsarm<br />
trägt das Schreib/Lesekopfpaar. Wie ist dieser „Pionier<br />
Schreib/Lesekopf“ aufgebaut?<br />
272 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Hans Spengler:<br />
Der Kopfaufbau ist im Bild „350/355 SchreibLesekopf“ zu<br />
erkennen: die Schreib/Lesespule mit Joch (schwarz) sitzt<br />
links und die Löschspule mit Joch liegt rechts. Die Jochflächen<br />
sind gegen die Speicherplatte nach unten projiziert<br />
und zeigen das Luftspaltmaß von 0,0254 mm und das<br />
angewandte Prinzip „erase wide and read narrow“.<br />
Das ganze magnetische Element wird durch eine konische<br />
Bohrung im ZugriffsarmRahmen geführt (siehe Abbildung<br />
„350/355 Schwebetechnik“ in Hellblau). Eine Haarnadelfeder<br />
greift in beide Bohrungen der Kopfführungsstifte (F) ein und<br />
drückt den Kopf an die Abdeckplatte, bis seine Führungsstifte<br />
dort anschlagen. Dieser Zustand wird als „Kopf entladen“<br />
bezeichnet. Um Lesen oder Schreiben vorzubereiten,<br />
erzeugt die Steuerelektronik das Signal „Head Load“ (siehe<br />
Abb. 2 „Ablaufschema“ unten rechts). Damit wird der „Head<br />
Load Solenoid“ erregt. Dieser lässt Druckluft (DL) sowohl an<br />
den sechs 0,1 mm großen, in sechskantform angeordneten<br />
Bohrungen in der Gleitfläche des Elementes austreten als<br />
auch gleichzeitig auf drei im 120GradWinkel angeordnete<br />
Zylinder mit Kolben wirken. Dadurch bewegt sich das<br />
magnetische Element nach unten. Die ausströmende Luft<br />
bewirkt an der planen Fläche den „BernoullyEffekt“, der<br />
die Schwebehöhe konstant auf 1/800 Zoll (0,02 mm) hält.<br />
Zusammenfassung:<br />
CPU (305):<br />
•<br />
•<br />
•<br />
Im Instruktionsstrom der zentralen Recheneinheit wird der<br />
Suchbefehl dekodiert.<br />
Transfer des Suchbefehls (Steuerwort) und der<br />
Adresskomponenten zur Steuereinheit 652 und weiter zur<br />
350/355.<br />
Die zentrale Recheneinheit beendet die Einleitung der<br />
Suchen-Instruktion und fährt im Instruktionsstrom fort.<br />
350/355:<br />
•<br />
•<br />
•<br />
•<br />
•<br />
•<br />
startet mit „Setzen Adressrelais“ die Abfolge der erforderlichen<br />
Sequenzen.<br />
Nullpotenzial aktivieren am Adress-äquivalenten Kontakt<br />
der Widerstandskette „Disk“.<br />
Entsprechend Nulldetektorausgang a) Nicht-Null = Arm<br />
entriegeln und in Grundstellung bewegen. Anschließend<br />
Wagen entriegeln und vertikal bewegen Richtung Zielplatte,<br />
b) wenn „Disk-Null“-Ergebnis erreicht ist, den<br />
Wagen verriegeln und Überleiten zum Start „Spursuche“.<br />
Spursuche, mit dem Zugriffsarm horizontal, solange der<br />
Null-Detektor „Nicht-Null“ abgibt, fahren. Wenn „Disk-Null“<br />
erreicht ist, Arm verriegeln. Das Signal „Position gefunden“<br />
generieren und Köpfe laden.<br />
Damit ist die Zugriffsstation für eine Lese- oder Schreiboperation<br />
vorbereitet. Dann wird durch die gehaltenen<br />
Adressrelais der obere oder untere S/L-Kopf elektronisch<br />
aktiviert.<br />
Die Bewegungswege determinieren die Zugriffszeit. Minimalzeiten<br />
ergeben sich bei Spurwechsel auf gleicher<br />
Speicheroberfäche (11 ms). Mehr Zeit erfordern Vertikalbewegungen<br />
des Wagens. Maximale Zeit wird von „oben<br />
innen nach unten innen“ gebraucht (800 ms). Dabei fallen<br />
zwei Zwischenstopps durch die Übergänge horizontal/<br />
vertikal und folgend vertikal/horizontal an.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 273
Technologie-Anhang<br />
Optische Speichertechnologien<br />
CD-ROM (Compact Disc Read Only Memory)<br />
1983 stellten Philips und Sony die CDROM vor, quasi ein<br />
Ableger der MusikCD. Das Medium ist auch ähnlich aufgebaut<br />
wie die MusikCD. Die Datenspeicherung erfolgt<br />
während der Herstellung der Platte und die Daten können<br />
nur gelesen werden (Analogie: ROM). Im Gegensatz zu<br />
Magnetplatten erfolgt die Aufzeichnung – wie bei einer<br />
Schall platte – in einer einzigen, spiralförmigen Spur. In<br />
diese vorgeprägte, reflektierende Schicht werden bei der<br />
Herstellung der Masterplatte mit einem Laser Löcher (Pits)<br />
eingebrannt. Von der Masterplatte lassen sich dann<br />
beliebig viele Kopien herstellen.<br />
Die Kopie wird vom Laserstrahl abgetastet, der durch die<br />
unterschiedliche Struktur der Speicherfläche mit einer digitalen<br />
Information moduliert wird. Die Spurdichte beträgt bis<br />
zu 16.000 Spuren/Zoll. Als Aufzeichnungsstandard hat sich<br />
das Format ISO 9660 durchgesetzt (Transferrate: 1,2 MBit/s,<br />
Kapazität: ca. 600 MB). Die CDROM dient hauptsächlich<br />
der Verbreitung größerer Datenmengen, als FotoCD und<br />
jüngst auch als Videoträger. Die erste CDROMApplikation,<br />
die auf CDROM ausgeliefert wird, ist 1987 Microsoft Bookshelf.<br />
1990 kommt der Commodore CDTV auf den Markt, ein<br />
auf dem Amiga 500 basierender Computer mit integriertem<br />
CDROMLaufwerk. 1993 und 1994 gibt NEC den Takt mit<br />
Dreifach (Triple Speed) bzw. VierfachCDROMLaufwerk<br />
(Quad Speed) an.<br />
Bei der beschreibbaren CDR ist der Aufbau komplexer als<br />
bei der CDROM. Unten liegt die Trägerschicht aus Polycarbonat,<br />
darauf folgt eine lichtempfindliche organische Substanz,<br />
die durchscheinend ist. Dann kommt eine reflektierende<br />
Goldschicht und schließlich eine LackSchutzschicht.<br />
Mit erhöhter Laserenergie kann das organische Material verfärbt<br />
bzw. verschmolzen werden und es erhält so eine<br />
andere Reflexionseigenschaft. Die Platte kann danach wie<br />
eine CDROM gelesen werden.<br />
WORM (Write Once Read Many)<br />
WORMPlatten lassen sich vom Anwender beschreiben,<br />
jedoch nur einmal (Analogie: PROM). Bei 5,25ZollPlatten<br />
sind Speicherkapazitäten von weit über 1 GB (Plasmon bietet<br />
heute im ITUmfeld basierend auf blauer LaserTechnik<br />
60GBPlatten an) möglich. WORM kann zur Archivierung<br />
von Daten aller Art verwendet werden (BackupMedium).<br />
Die Platte arbeitet wie ein Magnetplattenlaufwerk und kann<br />
genauso angesprochen werden, die Treibersoftware sorgt<br />
dafür, dass bei mehrfacher Speicherung einer Datei immer<br />
die jüngste Version angesprochen wird (ältere Versionen<br />
lassen sich über spezielle Programme lesen) —> Speicherung<br />
einer Dateichronologie. Beim Schreiben wird durch<br />
hohe Laserenergie die Plattenstruktur dauerhaft verändert.<br />
Beim Lesen wird diese Veränderung mit niedriger Laserenergie<br />
abgetastet und detektiert. Man unterscheidet zwei<br />
Speichertechniken:<br />
Bei der Blasenerzeugung wird durch den Laserstrahl eine<br />
Polymerschicht erhitzt, die unter einem dünnen Metallfilm<br />
liegt. Es kommt zur Bildung einer Blase, die den Metallfilm<br />
dauerhaft verformt. Bei der Abtastung mit geringer Laserenergie<br />
kann die geänderte Streuung ausgewertet werden.<br />
Bei der PitErzeugung durchbrennt der Laserstrahl eine<br />
lichtundurchlässige Schicht, die über einer Reflexionsschicht<br />
liegt (Pit entsteht). Beim Lesen werden die so<br />
entstandenen HellDunkelZonen ausgewertet.<br />
Ende der 90erJahre wurde die Haltbarkeit von Daten auf<br />
WORMPlatten auf ca. 300 Jahre geschätzt.<br />
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<br />
CCW)<br />
MOD (Magneto Optical Disc)<br />
Mit WORM verwandt ist die MOD, ein modernes Speichermedium<br />
für Computer auf magnetischoptischer Basis. Sie<br />
erlaubt das digitale Aufnehmen und Löschen über Laser.<br />
Die MOD enthält in Aufzeichnungsspuren geordnet bis zu<br />
einer Milliarde Mikromagnete. Diese sind in einer<br />
bestimmten Richtung vormagnetisiert. An den mit einem<br />
Laserstrahl erwärmten Stellen lassen sich diese Mikromagnete<br />
durch ein angelegtes Magnetfeld umpolen. Beim<br />
Abtasten wird der Laserstrahl durch die nun verschieden<br />
gepolten Magnete zirkular entweder rechts oder linksdrehend<br />
zurückgeworfen (magnetooptischer KerrEffekt). Die<br />
Änderung der Polari sation kann über eine entsprechende<br />
Optik gelesen werden. Die MOD ist weniger lichtempfindlich<br />
als die CDR, kann schneller beschrieben werden, ist<br />
unempfindlich gegen Nässe, hat eine hohe Lebenserwartung<br />
und bietet hohe Datensicherheit.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 275
Technologie-Anhang<br />
CCW (Continuous Composite WORM) basiert auf der MO<br />
Technik. Die Platte erhält bei der Produktion eine Kennzeichnung,<br />
damit sie nicht überschrieben werden kann. Zusätzlich<br />
schützt eine Software im Laufwerk die Platte vor dem<br />
Überschreiben. CCW ist also eine „Schein“WORMPlatte,<br />
die auf der MODTechnologie basiert.<br />
Im ITUmfeld wurden Anfang der 90erJahre die Technolo<br />
gien auf 120mmBasis (5,25 Zoll) als MO, CCW und<br />
WORMPlatten standardisiert. Die 120mmTechnologie<br />
findet bis heute ihren Einsatz im ITUmfeld für Archivierungszwecke.<br />
Optische Platten auf 90mmBasis (3,25 Zoll)<br />
werden vorrangig im ConsumerUmfeld eingesetzt.<br />
UDO (Ultra Density Optical Disk)<br />
In den Jahren 2003 und 2004 wurde die 120mmTechnologie,<br />
die bis dahin mit einem roten Laser arbeitete, durch<br />
einen neuen Standard ersetzt, die UDOTechnologie (Ultra<br />
Density Optical). Die UDOTechnologie ist nicht rückwärtskompatibel<br />
zur alten 120mmTechnologie und arbeitet mit<br />
einem blauvioletten Laser mit 405nmWellenlänge. Die<br />
Plattenformate WORM, MO und CCW wurden beibehalten.<br />
UDO bietet ein „Phase Change“ WORM und „Phase Change“<br />
RewritableMedium zum Einsatz an. Die ersten Platten auf<br />
dieser neuen LaserBasis als neuer 1xStandard boten eine<br />
Kapazität von 30 GB. Die Zweitgeneration als 2xStandard,<br />
der 2006 verfügbar wurde, bot das Doppelte an Kapazität,<br />
also 60 GB. Die UDOTechnologie als neuer 120mmStandard<br />
wird gemäß einer Roadmap weiterentwickelt, die im<br />
UDOStandard verankert wurde.<br />
UDO Roadmap<br />
Generation 1 Generation 2 Generation 3<br />
Capacity 30 GB 60 GB 120 GB<br />
Transfer Rate 8 MB/s 12 MB/s 18 MB/s<br />
RPM 2 000 3 000 3 600<br />
Avg Seek Time 25 ms 25 ms 25 ms<br />
Numerical<br />
Aperture<br />
0.7 0.7 0.85<br />
Media Layers 1 2 2<br />
Encoding 1,7 1,7 ML<br />
Sector Size 8 KB 8 KB 8 KB<br />
SCSI Transfer<br />
Rate<br />
80 MB/s 80 MB/s 80 MB/s<br />
Load Time 5 s 5 s 5 s<br />
Unload Time 3 s 3 s 3 s<br />
MSBF 750 000 750 000 750 000<br />
DVD (Digital Versatile Disk)<br />
DVD steht für „Digital Versatile Disk“ (ehemals „Digital Video<br />
Disk“). Das Medium ist so groß wie eine normale CDROM,<br />
jedoch wird mit einer wesentlich höheren Speicherdichte<br />
gearbeitet. Dabei unterscheidet man vier verschiedene<br />
Medien. Die einfache einseitige DVD kann 4,7 GB auf einer<br />
Schicht speichern. Es gibt aber auch zweischichtige DVDs.<br />
Dabei wird die Information auf zwei übereinanderliegenden<br />
Schichten gespeichert, eine davon ist durchsichtig.<br />
Durch unterschiedliche Fokussierung des Lasers wird die<br />
richtige Schicht angesteuert. Damit sind 8,5 GB möglich. Und<br />
dann gibt es das Ganze noch zweiseitig. Damit sind 17 GB<br />
Daten auf einer einzigen DVD möglich. Die ersten Laufwerke<br />
kamen in den 90erJahren auf den Markt und können einschichtige,<br />
einseitige DVDs lesen. Leider gab es zu diesem<br />
Zeitpunkt noch wenig DVDTitel mit Videos. Die Videos wurden<br />
in MPEG2 kodiert, was eine sehr gute Qualität bei der<br />
Wiedergabe ergibt. Auch die ersten Brenngeräte für einseitige,<br />
einschichtige DVDs waren in den 90erJahren bereits<br />
vorgestellt worden, der Brenner von Pioneer wurde im<br />
Herbst 1997 für etwas über 10.000 DM angeboten. Aufgenommen<br />
wurde mit ca. 1 – 2 MB/s und speichern konnte er<br />
maximal 3,9 GB.<br />
Die Lesegeräte können auch normale CDs lesen, jedoch<br />
meist keine CDRs, also die beschreibbaren CDs. Dies<br />
kommt daher, dass ein Laser mit einer kürzeren Wellenlänge<br />
verwendet wird, der die selbst gebrannten CDs nicht mehr<br />
richtig lesen kann. Sony hatte dazu ein Laufwerk mit zwei<br />
LaserDioden entwickelt, mit dem man dann auch die CDRs<br />
wieder lesen kann.<br />
HD DVD<br />
Die HD DVD (High Density Digital Versatile Disk, zuvor:<br />
Advanced Optical Disk, kurz: AOD) ist ein Datenträgerformat<br />
und wurde von 2005 bis Februar 2008 neben Bluray<br />
Disc und VMD als ein mögliches Nachfolgeformat der DVD<br />
gehandelt.<br />
276 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Die HD DVD wurde durch das Advanced Optical DiscKonsortium<br />
(AOD) spezifiziert, dem u. a. NEC, Microsoft, Toshiba,<br />
Intel, <strong>IBM</strong> und HewlettPackard angehörten. Danach haben<br />
sich diese Firmen zur HD DVD Promotion Group zusammengeschlossen,<br />
um die HD DVD effizienter bekannt zu machen.<br />
Das DVDForum hatte im November 2003 die HD DVD als<br />
HDNachfolger der DVD nach den HDDVDSpezifikationen<br />
für ReadOnlyDiscs verabschiedet. Für die HD DVD wurde<br />
der Kopierschutz Advanced Access Content <strong>System</strong> (AACS)<br />
aus dem Bereich des Digital Rights Management (DRM)<br />
vorgesehen.<br />
Im März 2006 kam mit dem HDXA1 von Toshiba der erste<br />
HDDVDPlayer in Japan auf den Markt. Im August 2006<br />
erschien mit Elephants Dream die erste HD DVD in deutscher<br />
Sprache.<br />
Im Februar 2008 erklärte Toshiba, dass man die Entwicklung,<br />
Herstellung und Vermarktung der Technologie Ende März<br />
2008 einstellen werde.<br />
Die HD DVD basierte auf einem blauvioletten Laser mit<br />
405 nm Wellenlänge. Die Dicke der Trägerschicht ist mit<br />
0,6 mm identisch mit der der DVD. Die numerische Apertur<br />
(NA) beträgt dagegen 0,65 im Vergleich zu 0,6 bei der DVD<br />
und 0,85 bei der Bluray Disc.<br />
Die HD DVD hatte mit einer Schicht ausgestattet eine Speicherkapazität<br />
von:<br />
•<br />
•<br />
•<br />
15 GB (bei HD DVD-ROMs – gepresste Medien) bzw.<br />
15 GB (bei HD DVD-R/RWs – einmal und wiederbeschreibbare<br />
Medien) bzw.<br />
20 GB (bei HD DVD-RAM – wiederbeschreibbare Medien<br />
mit wahlfreiem Sektorzugriff)<br />
und bei zwei Schichten eine Speicherkapazität von<br />
•<br />
30 GB (bei HD DVD-ROMs – gepresste Medien).<br />
Zusätzlich wurde im August 2007 eine dreilagige Variante<br />
durch das DVDForum verabschiedet, bei der pro Schicht<br />
17 GB Platz fanden und die somit eine Gesamtkapazität von<br />
51 GB hatte. Der endgültige Standard für Filme auf HD DVD<br />
umfasste zunächst die 15GB und die 30GBVariante,<br />
wobei für Filme fast immer die zweischichtige 30GBVariante<br />
verwendet wurde.<br />
Im Januar 2008 gab Time Warner bekannt, dass seine<br />
Studios Warner Bros. und New Line Cinema zukünftig keine<br />
weiteren Filme für die HD DVD veröffentlichen werden, sondern<br />
ausschließlich auf die Bluray Disc setzen. Dies wurde<br />
von einigen Medien als Entscheidung des Formatkrieges<br />
bezeichnet. In den darauffolgenden nächsten Tagen folgten<br />
weitere Anbieter, so am 10. Januar der große europäische<br />
Filmverleih Constantin Film, am 12. Januar der USPornoanbieter<br />
Digital Playground und die deutsche Senator Film.<br />
Die USAnbieter Universal Studios und Paramount Pictures<br />
dementierten hingegen Gerüchte, ihre Verträge mit HD DVD<br />
aufzugeben, sie gelten als die letzten verbliebenen großen<br />
Anbieter. Nachdem Toshiba, von denen ein Großteil der HD<br />
DVDPlayer stammt, am 15. Januar die Preise der Geräte in<br />
den USA teilweise drastisch reduziert hatte, sprachen einige<br />
Medien von einem „Ausverkauf“. Auf der anderen Seite nahm<br />
der Druck auf die HD DVD weiter zu: Anfang 2008 nahmen<br />
Märkte der MediaSaturnHolding beim Kauf eines Bluray<br />
Abspielgerätes den HDDVDPlayer in Zahlung. Weitere<br />
Rückschläge musste das Format im Februar 2008 hinnehmen.<br />
Die USElektronikkette Best Buy teilte am 12. Februar 2008<br />
mit, sich zukünftig nur noch auf das BlurayFormat zu konzentrieren.<br />
Einen Tag zuvor kündigte schon der größte US<br />
OnlineVideoverleih Netflix an, dass er bis zum Jahresende<br />
die HD DVD aus dem Sortiment nehmen wird. Am 15.<br />
Februar 2008 kündigte zudem WalMart, größter Einzelhändler<br />
der USA, an, HDDVDBestände auszuverkaufen und somit<br />
in Zukunft nur noch auf Bluray setzen zu wollen. Am 19.<br />
Februar 2008 gab Toshiba eine Pressemitteilung heraus, in<br />
der bekannt gegeben wurde, dass die Entwicklung, Herstellung<br />
und der Vertrieb der HD DVD sowie entsprechender<br />
Geräte nicht weiter vorangetrieben wird und Ende März<br />
2008 endgültig eingestellt wird. Daraufhin gaben die Universal<br />
Studios noch am selben Tag bekannt, von der HD DVD<br />
auf das BlurayFormat zu wechseln.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 277
Technologie-Anhang<br />
Blu-ray Disc<br />
Die Bluray Disc (abgekürzt BD oder seltener BRD) ist ein digitales<br />
optisches Speichermedium. Sie wurde neben HD DVD<br />
und VMD als ein möglicher Nachfolger der DVD beworben.<br />
Nachdem Toshiba im Februar 2008 die Einstellung von<br />
Produktion und Weiterentwicklung der HDDVDTechnik –<br />
einschließlich der Geräte – für März 2008 angekündigt hatte,<br />
gilt die Bluray Disc als Sieger im Formatkrieg. Der Name<br />
Bluray ist englischen Ursprungs. Blue ray bedeutet wörtlich<br />
soviel wie „Blauer Lichtstrahl“, was sich auf den verwendeten<br />
blauen Laser bezieht. Die bewusste Abweichung von<br />
der orthografisch korrekten Schreibweise „blue ray disc“<br />
zielt darauf ab, eine Registrierung des Ausdrucks als Marke<br />
zu begünstigen.<br />
Die Spezifikationen für die Bluray Disc wurden am 19.<br />
Februar 2002 durch die neun Unternehmen der Bluray<br />
Group, Panasonic, Pioneer, Philips, Sony, Thomson, LG<br />
Electronics, Hitachi, Sharp und Samsung, beschlossen; dieser<br />
Gruppierung schlossen sich Ende Januar 2004 zusätzlich<br />
noch Dell und HewlettPackard sowie Mitte März 2005<br />
Apple an. HewlettPackard trat allerdings 2005 wieder aus<br />
dem BlurayKonsortium aus, nachdem einige Verbesserungsvorschläge<br />
abge wiesen worden waren, und wechselte<br />
in das HDDVDLager.<br />
Die Bluray Disc gibt es in drei Varianten: als nur lesbare<br />
BDROM (vergleichbar mit DVDROM), als einmal<br />
beschreib bare Variante BDR (vergleichbar mit DVD±R) und<br />
als wieder beschreibbare BDRE (vergleichbar mit DVD±RW).<br />
Durch den Einsatz eines blauvioletten Lasers und dessen<br />
kurzer Wellenlänge (405 Nanometer) lassen sich höhere<br />
Datendichten erreichen als bei einer DVD. Pro Datenschicht<br />
lassen sich 25 GB Daten auf einer BDROM speichern,<br />
sodass sich bei zweischichtigen Medien eine Kapazität von<br />
bis zu 50 GB ergibt.<br />
Eine vierlagige Version der Bluray Disc, die auf einer Seite<br />
um 100 GB fassen soll, wurde von TDK vorgestellt. TDK ist<br />
es gelungen, auf einer sechslagigen Scheibe 200 GB unterzubringen.<br />
Dabei wurde die Kapazität einer Lage auf 33,3 GB<br />
erhöht. Dies sind jedoch in erster Linie Machbarkeitsstudien.<br />
Von vornherein sind auch beschreibbare Medien vorgesehen,<br />
soll die Bluray Disc doch vor allem in der Unterhaltungselektronik<br />
ihre Heimat finden und als Speichermedium für<br />
hochauflösende Filme dienen. Die wiederbeschreibbare<br />
Bluray Disc arbeitet mit der PhaseChangeTechnik.<br />
Die neue PhaseChangeTechnik soll eine doppelt so hohe<br />
Übertragungsrate (Datentransferrate) von 9,0 MB/s (72 Mbit/s)<br />
beim Beschreiben anstatt der ursprünglich maximal spezifizierten<br />
einfachen 4,5 MB/s (36 Mbit/s) ermöglichen. Ein<br />
wichtiger Bestandteil der Spezifikation ist auch ein Kopierschutz<br />
in Form einer eindeutigen Identifikationsnummer.<br />
Außerdem eignen sich Bluray Discs besonders gut für Full<br />
HDVideos, die dank der hohen Auflösung eine bessere<br />
Qualität als die gängigen <strong>System</strong>e wie PAL und NTSC bieten,<br />
aber auch dementsprechend mehr Speicherplatz benötigen.<br />
BDSpieler unterstützen in der Regel das zuerst von Panasonic<br />
und Sony eingeführte hochauflösende AVCHDFormat.<br />
Eine weitere Neuerung gegenüber der DVD ist der verkleinerte<br />
Abstand des Lasers zum Datenträger sowie die geringere<br />
Wellenlänge (und daher andere Farbe) des Laserstrahls.<br />
Weiterhin ist die Schutzschicht auf der LaserSeite mit 0,1 mm<br />
im Vergleich zu 0,6 mm der DVD deutlich kleiner. Aufgrund<br />
der daraus resultierenden größeren Anfälligkeit gegen<br />
Kratzer und Staub war zunächst geplant, die Bluray Disc<br />
nur in einer Cartridge anzubieten. Stattdessen wurde jedoch<br />
eine Beschichtung namens „Durabis“ entwickelt, die den<br />
Gebrauch einer Cartridge nicht mehr notwendig macht.<br />
Wegen des geringeren Abstands zwischen Medium und<br />
Laseroptik sowie der dünneren Schutzschicht kann ein<br />
Objektiv mit günstigerer numerischer Apertur eingesetzt<br />
werden, das den Strahl effizienter bündeln kann. Somit werden<br />
Schreibfehler und stärkere Streuungen verringert und<br />
es ist möglich, eine Bluray Disc zum Beispiel aus Metall oder<br />
anderen stabilen, undurchsichtigen Materialien kombiniert<br />
278 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
mit einer dünnen durchsichtigen Trägerschicht zu bauen,<br />
die mit erheblich höheren Drehzahlen als eine Scheibe aus<br />
Polycarbonat betrieben werden können, woraus dann<br />
höhere Übertragungsraten resultieren. Zudem erlaubt die<br />
gegenüber der DVD kleinere Wellenlänge des Laserstrahls<br />
eine wesentlich höhere Datendichte und damit eine erhöhte<br />
Speicherkapazität.<br />
Die Firma Verbatim stellte auf der IFA 2005 eine „Bluray<br />
Disc Rewriteable“ vor. Dieses Medium soll laut Hersteller<br />
eine Speicherkapazität von 25 Gigabyte erlauben (also<br />
ca. 135 Minuten Video in MPEG2 HDQualität). Außerdem<br />
soll die BDRE mit einer besonders stoß und kratzfesten<br />
Schutz schicht versehen sein. Neben der unmittelbaren<br />
Verfügbarkeit von 25GBRohlingen hat TDK für Oktober<br />
2006 auch 50GBDiscs in Aussicht gestellt. TDK ist eines<br />
der Gründungsmitglieder der Bluray Disc Association<br />
(BDA) und war maßgeblich an der Entwicklung beteiligt.<br />
Holographic Versatile Disc (HVD)<br />
Die Holographic Versatile Disc, auch HVD genannt, wird<br />
bereits heute in Fachkreisen als Nachfolger der heutigen<br />
HDDVD und BlurayTechnologie gehandelt. HVDs haben<br />
eine Kapazität von bis zu 3,9 TB und damit um ein Vielfaches<br />
mehr als die größte heute zur Verfügung stehende<br />
BlurayPlatte mit 200 GB. Auch die Transferrate ist um ein<br />
Vielfaches höher und erreicht 1 Gbit/s im Vergleich zu<br />
36 bzw. 72 Mbit/s bei der BlurayPlatte. Zudem ist die HVD<br />
dabei noch lange nicht ausgereizt und es sind neue<br />
Laufwerke mit noch höherer Rotationsgeschwindigkeit<br />
denkbar. Die Spezifikation für die HVD wurde im Dezember<br />
2004 durch das TC44 Committee der Ecma International<br />
beschlossen. Bereits im Februar 2005 wurde die „HVD<br />
Alliance“ gegründet, um die Entwicklung der HVD voranzutreiben.<br />
Inzwischen gehören der Alliance 19 Firmen an:<br />
Alps Electric Corporation, CMC Magnetics, Dainippon Ink<br />
and Chemicals, EMTEC International, Fuji Photo Film,<br />
Konica Minolta Holdings, LiteOn Technology, Mitsubishi<br />
Kagaku, Nippon Kayaku, Nippon Paint, Optware Corporation,<br />
Pulstec Industrial, Shibaura Mechatronics, Software Architects,<br />
Suruga Seiki, Targray Technology, Teijin Chemicals,<br />
Toagosei Company und die Tokiwa Optical Corporation.<br />
Zwei überlagerte Laser mit unterschiedlicher Wellenlänge,<br />
ein blaugrüner Schreib/Leselaser mit 532 nm und ein roter<br />
Positionierungslaser mit 650 nm, werden auf zwei unterschiedlichen<br />
Lagen in der Platte reflektiert und erzeugen in<br />
der photopolymeren Schicht ein Interferenzfeld, ein sogenanntes<br />
Hologramm. In der schematischen Zeichnung sind<br />
die beiden Laser zur Vereinfachung nicht überlagert dargestellt,<br />
um das Prinzip der unterschiedlichen Reflexion besser<br />
darzustellen.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 279
Technologie-Anhang<br />
Beim Auslesen liest der blaugrüne Laser das Hologramm der<br />
als LaserInterferenzMuster codierten Daten in der Polymer<br />
schicht im oberen Bereich des Mediums aus, während der<br />
rote Laser dazu dient, Hilfsinformationen von einer CDvergleichbaren<br />
Aluminiumschicht im unteren Bereich auszulesen.<br />
Die Hilfsinformationen dienen zur exakten Positionierung, wo<br />
man sich gerade auf der Platte befindet (vergleichbar mit<br />
Sektor, Kopf und Segmentinformationen einer Festplatte).<br />
Eine dichroitische Spiegelschicht (Reflexionsschicht), die sich<br />
zwischen der Polymerschicht und der Aluminiumschicht<br />
(Basisschicht) befindet, lässt den blaugrünen Laser reflektieren,<br />
während der rote Laser hindurchgeht. Durch diesen<br />
Trick wird die Interferenz durch Refraktion des blaugrünen<br />
Lasers von den Hilfsdaten„Pits“ verhindert und beide Informationen<br />
(Hologramm und Hilfsdaten) können unabhängig<br />
voneinander sauber angesteuert werden.<br />
Polymere, also Kunststoffe, sind lange Kettenmoleküle, die<br />
aus den immer gleichen Bausteinen bestehen. Sie haben<br />
gegenüber Kristallen den Vorteil, nahezu unbegrenzt modifizierbar<br />
zu sein. Polymere sind extrem lichtempfindlich,<br />
hoch transparent und unempfindlich gegen Temperaturschwankungen.<br />
Sie verändern auch nach häufigem Auslesen<br />
ihre Leistungsfähigkeit nicht und sind ideal für die<br />
Laserbearbeitung. Nach der Bestrahlung mit Laserlicht verändern<br />
die lichtempfindlichen Moleküle im Polymer ihre<br />
Ausrichtung. An den belichteten Stellen lenkt das Material<br />
Licht stärker ab als an den unbelichteten Stellen. In dieser<br />
als Interferenzfeld gezielten Veränderung der molekularen<br />
Ordnung steckt die „holografische“ Information. Da die<br />
Daten nicht als einzelne Bits, sondern als ganze Bitmuster<br />
aufgezeichnet und gelesen werden, lassen sich mit einem<br />
einzigen Laser„Blitz“ extrem viele Bits gleichzeitig abrufen.<br />
Je nach Polymerart und Polymerdicke können das mehrere<br />
hunderttausend Bits sein. Die Übertragungsraten werden<br />
gigantisch. Ein Spielfilm, der heute auf eine DVD passt,<br />
könnte in etwa 30 Sekunden ausgelesen werden. Die große<br />
Speicherkapazität kommt daher, dass die Hologramme nicht<br />
nur auf die Oberfläche eines Speichermaterials geschrieben<br />
werden, sondern in das gesamte Volumen.<br />
Besonders sensible Daten könnten zusätzlich durch eine<br />
spezielle Maske verschlüsselt werden, die zwischen das<br />
Speichermaterial gesetzt wird. Im Gegensatz zu Informationen<br />
(z. B. auf Chips), die über eine Software verschlüsselt<br />
sind, ließe sich die HardwareVerschlüsselung von Hologrammen<br />
prinzipiell nicht knacken. Aus denselben Gründen<br />
ist ein Hologramm auch schwer zu fälschen. Die Haltbarkeit<br />
von Informationen in holografischen Speichern wird heute<br />
auf etwa 50 Jahre geschätzt.<br />
Flash-Speicher – Kurzgeschichte<br />
Die Entwicklung des heutzutage bekannten FlashSpeichers<br />
hat sich erst relativ spät in den 90erJahren zugetragen. Die<br />
treibende Kraft war die digitale Fotografie. Schließlich ist es<br />
praktisch unmöglich, in eine kleine Digitalkamera einen CD,<br />
Brenner einzubauen, der die geschossenen Bilder direkt auf<br />
die CD brennt. Ebenso wenig war die Diskette tauglich, da<br />
sie einfach zu wenig Daten zu langsam speicherte. Die<br />
Ende der 90erJahre von <strong>IBM</strong> entwickelten Microdrives, die<br />
ein paar Jahre zu den FlashSpeicherkarten eine Alternative<br />
bildeten, verbrauchten im Einsatz viel Strom, sodass der<br />
Akku einer Digitalkamera häufig aufgeladen werden musste.<br />
Auf Dauer waren deshalb die Microdrives keine sinnvolle<br />
Alternative in der digitalen Fotografie.<br />
Der erste FlashSpeicher wurde von Sandisk 1994 auf<br />
den Markt gebracht. Er umfasste damals 4MBSpeicher.<br />
Mittlerweile ist diese Form der Datensicherung viele Technologieschritte<br />
weiter, da man mit 4 MB Speicherkapazität<br />
kaum etwas anfangen konnte. Heutzutage sind USB<br />
Sticks, die auf dieser Technologie basieren, mit mehreren<br />
Gigabyte erhältlich.<br />
Die Bezeichnung FlashSpeicher kam in den Laboren von<br />
Toshiba zustande, wo der Forscher Shoji Ariizumi diesen<br />
Namen vorschlug, da ihn das Löschen der Datenblöcke an<br />
ein Blitzlicht (in Englisch: „Flash“) erinnerte.<br />
Flash-Speicher einer Compact-Flash-Speicherkarte (Foto: SANDISK)<br />
280 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Beschreibung und Funktionsweise<br />
FlashSpeicher basieren auf Halbleitertechnologie und kommen<br />
in allen heute verbreiteten Speicherkarten vor. Sie werden<br />
in HybridFestplatten oder FlashFestplatten in Personal<br />
Computern eingesetzt, aber auch in Speicherkarten für<br />
Arbeitsrechner oder in schnellen Zwischenspeichern von<br />
Großrechnern; darüber hinaus aber vor allem in SIMMs, PC<br />
Cards und PCMCIAKarten, in Digitalkameras und MP3Playern,<br />
in USBSticks, Camcordern und Druckern, Notebooks<br />
und Handhelds. Es gibt spezielle FlashModule für Notebooks,<br />
Laptops, PDAs, Drucker und andere Peripheriegeräte<br />
wie Digitalkameras. Die verschiedenen Ausführungen<br />
haben eine geschützte Bezeichnung und Schreibweise: Beispiele<br />
sind die CompactFlashKarte (CF), die Smart Media<br />
Card, Memory Sticks, die Multi Media Card (MMC), die SD<br />
Karte und andere mit Speicherkapazitäten von mehreren<br />
Gigabyte (GB). Das Lesen von Flash Memorys kann in speziellen<br />
Kartenlesegeräten durchgeführt werden, die über ein<br />
Schnittstellenkabel wie USB mit dem Personal Computer<br />
(PC) verbunden sind. Darüber hinaus können die Flash<br />
Memorys auch über PCCardAdapter betrieben werden.<br />
Die prinzipiellen Anforderungen an eine Speicherkarte<br />
sind neben einer sehr kompakten Bauweise hohe Speicher<br />
kapazitäten, die Wiederbeschreibbarkeit, der Einsatz von<br />
Strom unabhängigen Speicherbausteinen sowie eine möglichst<br />
geringe Störanfälligkeit im mobilen Einsatz. Diese<br />
Anforderungen waren und sind vor allem durch die digitale<br />
Fotografie definiert.<br />
Aufbau einer Flash-Speicherzelle mit Floating Gate<br />
Im Gegensatz zu Festplatten haben FlashSpeicher keine<br />
beweglichen Teile mehr integriert, das heißt mechanische<br />
Komponenten einer Festplatte sind ausgeschlossen und<br />
werden durch Halbleiter, also von elektrotechnischen Bauelementen,<br />
bezüglich der Funktionsweise übernommen.<br />
Diese müssen in der Lage sein, Daten dauerhaft und nicht<br />
flüchtig, also Stromunabhängig, zu speichern. Auch wenn<br />
die Stromversorgung abgebrochen wird, dürfen die Informationen<br />
nicht verloren gehen.<br />
Eine FlashZelle besteht aus einem modifizierten MOSFET<br />
Transistor (MetallOxidFeldEffektTransistor), der mit einer<br />
zusätzlichen Elekrode, dem sogenannten „Floating Gate“,<br />
ausgestattet ist. Diese Elektrode wird zwischen der Steuerelektrode<br />
(Control Gate) und dem aktiven Transistorkanal<br />
platziert und mit einer dünnen halbdurchlässigen Trennschicht<br />
umgeben. Werden nun freie Elektronen mithilfe von<br />
höherer Spannung (Schreibspannung) durch die Barriere,<br />
meist eine Oxidschicht, hindurch auf das Floating Gate<br />
„gepresst“, ändert sich das Transistorverhalten.<br />
Jeder Transistor kann eine elektrische Ladung in Form von<br />
Elektronen entweder leiten oder sperren. Dies entspricht<br />
genau den binären Informationszuständen eines Bits, also<br />
„0“ und „1“. Der Transistor gibt die gespeicherte Information<br />
dann preis, wenn eine Spannung angelegt wird und je<br />
nachdem, ob Strom fließt oder nicht, besitzt er die logische<br />
Information „0“ oder „1“.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 281
Technologie-Anhang<br />
Das Floating Gate ist elektronisch vollständig von allen<br />
anderen Komponenten durch eine Oxydschicht isoliert,<br />
damit die gespeicherte Ladung, also die Information auf der<br />
Datenzelle darunter, auch wirklich in ihr gespeichert bleibt<br />
und auch über längere Zeit nicht verloren gehen kann.<br />
Unter normalen Umständen wäre durch diese Isolation eine<br />
Übertragung nicht möglich, da die Isolation sie blockieren<br />
würde. Der FlashSpeicher bedient sich deshalb des sogenannten<br />
Tunneleffekts aus der Quantenmechanik, der es<br />
ermöglicht, Ladungen auch durch ein nichtleitendes Material<br />
zu übertragen. Das Floating Gate wird je nach Menge<br />
der aufgenommenen Elektronen zu einem elektronischen<br />
Drosselventil für die Transistorfunktion. Beim Auslesen einer<br />
TransistorSpeicherzelle wird der resultierende Strom als<br />
Indikator für logisch „0“ (viele Elektronen im Floating Gate)<br />
und logisch „1“ (wenige oder fast keine Elektronen im Floating<br />
Gate) ausgewertet. Ein geladenes „Floating Gate“<br />
reflektiert also „0“ und ein ungeladenes wird als „1“ gewertet.<br />
Eine andere Zuordnung wäre möglich, wurde aber nie<br />
angewandt. Jedes einzelne Bit wird damit über das „Floating<br />
Gate“ übertragen. Für das erneute Beschreiben einer<br />
bereits mit Information bestückten Datenzelle ist das vorhergehende<br />
Löschen dieser notwendig. Der Grund hierfür ist,<br />
dass man die Bits in einem FlashSpeicher immer nur von 1<br />
nach 0 verändern kann. Nur ein Löschvorgang ermöglicht<br />
es, diesen Zustand in die andere Richtung zu ändern.<br />
Die schematische Abbildung „Aufbau einer FlashSpeicher<br />
zelle mit Floating Gate“ zeigt, wie das Floating Gate eine<br />
Ladungsfalle bildet, in der die elektrische Ladung gespeichert<br />
wird. Es liegt in einer Oxidschicht unterhalb des Control<br />
Gates und verhindert im Normalfall den Ladungsabfluss<br />
zu den N und PSchichten (N = stark negativ dotierte Elektroden<br />
Drain und Source, P = stark positiv dotiertes Substrat).<br />
Die Ladung auf dem Floating Gate bildet über ihr<br />
elektrisches Feld einen leitenden Kanal zwischen Drain und<br />
Source, über den die Ladung ausgelesen wird. Das<br />
Löschen erfolgt blockweise. Durch Anlegen einer negativen<br />
Löschspannung werden die Ladungsträger aus dem Floating<br />
Gate herausgetrieben.<br />
Weitere Überlegungen<br />
FlashSpeicher sind stromunabhängig und unterscheiden<br />
sich deshalb grundsätzlich von stromabhängigen (volatile)<br />
RAMBausteinen (Random Access Memory), denn die im<br />
RAMHauptspeicher eines Computers gespeicherte Informationen<br />
bleiben immer nur solange erhalten, wie der<br />
Computer läuft. Ist der Computer ohne Strom, verlieren<br />
RAMModule die Fähigkeit, Daten zu speichern.<br />
Ein klassich bipolarer Transistor benötigt Strom für mehrere<br />
Funktionen. Zum einen werden Elektronen aus Siliziumflächen<br />
des Transistors herausgelöst, um damit den Schaltzustand<br />
zu verändern. Informationen werden auf diese Weise<br />
gespeichert oder gelöscht. Zum anderen wird der Strom in<br />
Form von „Refresh“Impulsen benötigt, um den erreichten<br />
Zustand zu stabilisieren.<br />
MOSFETs hingegen sind in der Lage, mittels einer dünnen<br />
Oxidschicht einen kleinen Kondensator aufzubauen, der<br />
über ein einmal aufgebautes elektrisches Feld Ladungsträger<br />
zwischen den Siliziumschichten transportiert. Dadurch<br />
baut sich Spannung auf, bis ein Grenzwert erreicht wird. In<br />
der Folge entsteht ein dünner leitender Kanal, der ohne<br />
„Refresh“Impulse stabil bleibt. MOSFETs benötigen also nur<br />
Strom, um den Kondensator zu laden oder zu entladen,<br />
während im anderen Fall Strom dauerhaft zugeführt werden<br />
muss, um die Leitfähigkeit in einem stabilen Zustand zu halten<br />
und die gespeicherte Information zu erhalten.<br />
NAND-Architektur<br />
Die Bezeichnung NAND, die den NANDFlashSpeicher<br />
beschreibt, kommt eigentlich aus der Aussagenlogik. Hier<br />
wird ein Gatter beschrieben, das eine bestimmte UNDVerknüpfung<br />
darstellt (Not AND = NAND). In die Welt der Elektronik<br />
umgewälzt bedeutet es, dass die Speicherzellen auf<br />
einem FlashSpeicher seriell geschaltet sind, also auf verschiedenen<br />
Datenleitungen hintereinander gereiht sind.<br />
Dabei werden die MetallOxidHalbleiterFeldtransistoren<br />
über ein NANDGatter miteinander verbunden. Der große<br />
Vorteil dieser Architektur ist, dass nur eine geringe Anzahl<br />
an Datenspuren benötigt werden, da eine Spur mehrere<br />
Speicherzellen enthält. Im Vergleich zur NORArchitektur<br />
kann somit eine Platzersparnis der Speicherzellen von weit<br />
über 50 % erzielt werden.<br />
282 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Die Zugriffszeiten der NANDArchitektur sind relativ hoch,<br />
da man nicht auf einzelne Speicherzellen zugreifen, sondern<br />
immer nur die ganze Leitung herauslesen kann. Man muss<br />
die Daten also blockweise lesen. Dabei bedient man sich<br />
der page und blockorientierten Arbeitsweise. Eine Page<br />
besteht aus 512 bzw. 2.048 Bytes, die ihrerseits wieder zu<br />
Blöcken zusammengefasst werden, die zwischen 16 und<br />
128 KB liegen.<br />
Wie bereits ausgeführt, kann man ein erneutes Beschreiben<br />
eines Speicherbereichs, also einer Page, nur dann durchführen,<br />
wenn man sie zuvor löscht. Da die Datenzellen seriell<br />
geschaltet sind, muss man gleich den ganzen Block<br />
löschen, in dem sich die jeweilige Page befindet.<br />
Man verwendet NANDFlashs in jenen Bereichen, wo<br />
relativ viel Speicher gebraucht wird und das FlashModule<br />
klein und sehr kompakt gebaut sein soll. Etwas nachteilig<br />
sind die langsameren Zugriffszeiten im Vergleich zur<br />
NORArchitektur.<br />
NANDSpeicher oder auch SLCFlash genannt (Single Level<br />
Cell) haben sich aufgrund ihrer hohe Speicherdichte und<br />
der kostengünstigen Produktionsweise gegenüber NOR<br />
Speichern weitgehend durchgesetzt.<br />
NOR-Architektur<br />
Als Gegenstück zum NANDSpeicher existiert der sogenannte<br />
NORSpeicher. Wie der Name schon vermuten<br />
lässt, besteht dieser Speichertyp anstatt aus NAND aus<br />
NORGattern (Not OR). Dabei ergibt sich auch der Umstand,<br />
dass die Speicherzellen eines NORFlashs parallel zueinander<br />
geschaltet sind, wodurch ein paralleler und somit<br />
wahlfreier Zugriff möglich wird. Man muss also beim Lesen<br />
nicht Block für Block vorgehen.<br />
Der parallele NORFlash verfügt über geringere Speicher<br />
dichte und ist vergleichsweise teuer, führt aber Abrufvor<br />
gänge wesentlich schneller aus. NORSpeicher werden<br />
auch als MLCSpeicher (Multi Level Cell) bezeichnet und<br />
können aufgrund ihrer „Gitter“Struktur flexibl angesprochen<br />
werden. Durch ihren Aufbau verfügen sie verglichen mit<br />
NANDSpeichern über relativ wenig Speicherplatz, da durch<br />
die Parallelität einfach mehr Platz beansprucht wird.<br />
Generell<br />
NAND wird in großen Datenspeichern in kommerziellen<br />
<strong>System</strong>en genutzt, weil damit kompaktere, schnellere und<br />
preiswertere Speichersysteme gebaut werden können. Im<br />
NORSpeicher sind die Speicherzellen parallel auslesbar,<br />
daher sind solche Speicher bei einem überwiegenden Lesebetrieb<br />
besonders schnell und z. B. als Programm oder<br />
Codespeicher sehr gut geeignet. NANDSpeicherzellen können<br />
dichter gepackt werden. Dabei sind aber viele Speicherzellen<br />
in Reihe geschaltet. Daher ist der wahlweise<br />
Lesezugriff langsamer. Löschen und Schreiben gehen bei<br />
NANDSpeichern schneller, wenn blockweise gearbeitet<br />
wird. Die Speicherdichten bei NAND und NORTechniken<br />
für EinbitZellen unterscheiden sich. Üblicherweise verwendet<br />
NAND EinbitZellen und NOR MehrbitZellen. Allerdings<br />
gibt es beide Techniken inzwischen auch in MehrbitVarianten<br />
mit zwei, drei oder vier Bits in einer Zelle. Generell sind<br />
MehrbitZellen langsamer und störanfälliger als EinbitZellen.<br />
MehrbitZellen (Multi Level Cell) haben dieselbe Zellgröße<br />
und die Bits in der Zelle werden durch unterscheidbare<br />
Spannungspegel definiert. Das erklärt die Kostenreduktion<br />
von MLCSpeichern gegenüber dem SLCSpeicher (Single<br />
Level Cell). Allerdings gibt es immer wieder Schwierigkeiten,<br />
die geringen Spannungsunterschiede präzise auszulesen.<br />
Deshalb sollte beim heutigen Stand der Technik im professionellen<br />
ITBetrieb aus Zuverlässigkeits und Geschwindigkeitsgründen<br />
SLCFlash in NANDTechnik eingesetzt werden.<br />
Lebensdauer<br />
Aufgrund ihrer Funktionsweise sind FLASHSpeicher nicht<br />
unbegrenzt haltbar. Jeder Schreib und Löschvorgang verursacht<br />
einen gewissen Verschleiß in den Oxidschichten<br />
der Zellen, sodass die Hersteller von FlashSpeicherkarten<br />
eine Art Mindesthaltbarkeit für ihre Produkte angeben, die<br />
auf der Anzahl der durchgeführten Löschzyklen basiert.<br />
Bei NAND (SLC) beträgt dieser Wert 100.000 Zyklen, bei<br />
NOR (MLC) nur 10.000 Zyklen. Dabei wird immer ein<br />
großzügiger Sicherheitspuffer mit einkalkuliert, d. h., NAND<br />
Speicherkarten können in der Regel auch nach einer Million<br />
und mehr Löschzyklen funktionsfähig sein.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 283
Technologie-Anhang<br />
Eine Art Defektmanagement erhöht zusätzlich die Lebensdauer<br />
von FlashSpeicherkarten. Sobald der Verschleiß<br />
innerhalb eines Blocks die Integrität der Daten beeinträchtigt,<br />
wird dieser Block als defekt gekennzeichnet und die<br />
dort abgelegten Daten auf einen Reserveblock umgelagert.<br />
Diese Blockverwaltung kümmert sich zudem von Anfang an<br />
um eine gleichmässige Verteilung der Schreibzugriffe, damit<br />
die Blöcke möglichst gleichmässig und einheitlich abgenutzt<br />
werden.<br />
Steuerung<br />
Die Steuerung, die das Defektmanagement durchführt, hat<br />
maßgeblichen Einfluss auf die Leistungsfähigkeit einer<br />
Flash Speicherkarte. Sie kümmert sich neben der Wartung<br />
der FlashZellen vor allem um die Kommunikation der Speicherkarte<br />
mit dem Endgerät und ist damit maßgeblich für<br />
die Datentransferraten verantwortlich, die beim Lesen von<br />
und beim Schreiben auf eine FlashZelle erreicht werden.<br />
Die Zugriffszeiten liegen bei etwa 100 µs, die Lesegeschwindigkeit<br />
liegt bei 25 MB/s und geht bis über 50 MB/s.<br />
Neben der Geschwindigkeit ist auch die Zuverlässigkeit<br />
bei der Datenkommunikation sowie das Protokoll, das für<br />
ein reibungsloses An und Abmelden der Speicherkarte<br />
beim Betriebssystem sorgt, Sache der Steuerung. Für diese<br />
Steuerung werden Controller eingesetzt.<br />
Bei den meisten heute verfügbaren Speicherkarten ist der<br />
Controller in der Datenträgereinheit integriert, bei einigen<br />
Modellen wird er aber auch extern eingesetzt, um eine noch<br />
kompaktere Bauform zu erreichen. Der Nachteil der externen<br />
Variante liegt darin, dass außen liegende Controller oftmals<br />
mehr als ein Kartenmodell verwalten müssen und nicht<br />
optimal auf die Anforderung jedes einzelnen abgestimmt<br />
sind. Leistungsverlust und Kompatibilitätsprobleme können<br />
dann die Folge sein.<br />
Ausblick<br />
Man geht heute von einer Zeitspanne von vier bis fünf Quartalen<br />
zwischen zwei FlashGenerationen aus, bei der die<br />
Kapazität mindestens um 50 % gesteigert oder in vielen<br />
Fällen verdoppelt werden kann. Dies kann in den nächsten<br />
Generationen ähnlich weitergehen, die Kurve könnte aber<br />
stark abflachen! Deshalb wird bereits heute an neuen und<br />
anderen FlashSpeichertechniken gearbeitet. IDC erwartet,<br />
dass der Einsatz von FlashSpeichern in mobilen PCs von<br />
heute fast 0 auf 20 % im Jahr 2011 steigen wird.<br />
RAM – Random Access Memory<br />
RAM ist die Abkürzung für Random Access Memory. RAM<br />
wird auch als Arbeitsspeicher oder Hauptspeicher bezeichnet<br />
und ist ein Speichertyp, dessen Speicherzellen über ihre<br />
Speicheradressen direkt angesprochen werden können. In<br />
diesem Zusammenhang wird auch von „wahlfrei“ gesprochen,<br />
was sich auf „random“ bezieht und nichts mit „Zufall“<br />
oder „zufälligem Zugriff“ zu tun hat. In diesem Zusammenhang<br />
spricht man von „Speicher mit wahlfreiem Zugriff“ oder<br />
„Direktzugriffsspeicher“.<br />
RAM erlaubt den Zugriff auf jede einzelne Speicherzelle<br />
sowohl lesend, wie auch schreibend. RAM Speicher benötigen<br />
immer Stromzufuhr. Wird die Stromversorgung abgeschaltet,<br />
gehen die Daten im RAM verloren.<br />
RAM wird in Computer und Mikrocontroller<strong>System</strong>en als<br />
Arbeitsspeicher eingesetzt. In diesen Arbeitsspeichern wer<br />
den Programme und Daten von externen Speicherträgern<br />
und Festplatten geladen. Zur schnellen Verarbeitung kann<br />
der Prozessor darauf zugreifen, verarbeiten und danach<br />
wieder in den Arbeitsspeicher schreiben.<br />
Kurzgeschichte<br />
Die Entstehung des Begriffs geht in die Anfangszeit der<br />
Computer zurück, bei denen alle Daten auf sequenziell zu<br />
lesenden Speicherformen wie Lochkarten, magnetischen<br />
Trommelspeichern und Magnetbändern vorlagen, die zur<br />
Verarbeitung in schnelle Rechenregister geladen wurden.<br />
Um Zwischenergebnisse schneller als diese blockorientierten<br />
Geräte bereitzuhalten, wurden zeitweise Verzögerungsleitungen<br />
(engl. delay line) für Zwischenwerte eingesetzt,<br />
bis dann die Ferritkernspeicher eingeführt wurden.<br />
Diese beschreibbaren Speicher hatten schon die gleiche<br />
Form des Matrixzugriffs wie heutige RAMs. Zu jener Zeit<br />
waren die schnellen Speichertypen alle beschreibbar und<br />
die wesentliche Neuerung bestand im wahlfreien Zugriff der<br />
magnetischen Kernspeicher und der dann auf Halbleiterspeichern<br />
aufsetzenden RAMBausteine.<br />
Funktionsweise<br />
RAMs sind HalbleiterSpeicher und es gibt prinzipiell zwei<br />
Arten von RAM: SRAM als statisches RAM und DRAM als<br />
dynamisches RAM. Bei statischen RAMs wird die Information<br />
in rückgekoppelten Schaltkreisen (sogenannten Flipflops)<br />
gespeichert, bei dynamischen RAMs in Kondensatoren,<br />
deren Ladung periodisch aufgefrischt wird. Während<br />
284 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
des Wiederaufladens hat der Prozessor (CPU) keinen Zugriff<br />
auf den DRAM. Deswegen arbeiten Computer mit DRAMs<br />
oft langsamer als solche mit SRAMs. Die Speicherkapazität<br />
der DRAMs liegt jedoch deutlich über den von SRAMs.<br />
SRAM ist statisch. Das bedeutet, dass der Speicherinhalt<br />
mittels Flipflops gespeichert wird und so nach dem Abruf<br />
des Speicherinhalts erhalten bleibt. Dadurch ist der Stromverbrauch<br />
sehr hoch, was aber zu einem schnellen Arbeiten<br />
innerhalb des Speichers führt. Aufgrund seines hohen<br />
Preises und des großen Stromverbrauchs wird SRAM nur<br />
als Cache oder Pufferspeicher mit geringen Kapazitäten<br />
verwendet (z. B. L1, L2 und L3Cache von großen Rechner <br />
systemen). Sein Inhalt ist flüchtig (volatile), d. h., die<br />
ge speicherte Information geht bei Abschaltung der Betriebsspannung<br />
verloren. In Kombination mit einer Pufferbatterie<br />
kann aus dem statischen RAM eine spezielle Form von<br />
nicht flüchtigen SpeicherNVRAM realisiert werden, da<br />
SRAMZellen ohne Zugriffzyklen nur einen sehr geringen<br />
Leistungsbedarf aufweisen und die Pufferbatterie über<br />
mehrere Jahre den Dateninhalt im SRAM halten kann.<br />
DRAM ist im Vergleich einfacher und langsamer. Lange Zeit<br />
war im ComputerBereich für den Arbeitsspeicher nur dieser<br />
eine Speichertyp mit seinen verschiedenen Varianten bekannt.<br />
Eine DRAMSpeicherzelle besteht aus einem Transistor und<br />
einem Kondensator, der das eigentliche Speicherelement<br />
ist. Die Informationen werden in Form des Ladezustands<br />
eines Kondensators gespeichert. Dieser sehr einfache<br />
Aufbau macht die Speicherzelle zwar sehr klein, allerdings<br />
entlädt sich der Kondensator bei den kleinen möglichen<br />
Kapazitäten durch die auftretenden Leckströme schnell, und<br />
der Informationsinhalt geht verloren. Daher müssen die<br />
Speicherzellen regelmäßig wieder aufgefrischt werden.<br />
Im Vergleich zum SRAM ist DRAM wesentlich preiswerter.<br />
Deshalb verwendet man DRAM vornehmlich für den Arbeitsspeicher<br />
eines PCs.<br />
Phase Change Memories (PCM) – Phasenwechselspeicher<br />
Schon in den 1920erJahren wurde beobachtet, dass sich<br />
die elektrische Leitfähigkeit durch eine Strukturänderung<br />
an einem Chalkogenid verändert. In den 1950erJahren<br />
erforschte man die Halbleitereigenschaften kristalliner und<br />
amorpher Chalkogenide. In den 1960erJahren fing man an,<br />
reversible phasenwechselnde Materialien auf ihre elek<br />
trischen und dann auch optischen Eigenschaften zu untersuchen.<br />
Chalkogenide sind chemische Verbindungen aus einem<br />
oder mehreren ChalkogenElementen wie Sauerstoff,<br />
Schwefel, Selen und Tellur, die mit anderen Bindungspartnern<br />
(wie Arsen, Germanium, Phosphor, Blei, Aluminium und<br />
andere) Feststoffe mit ionischem oder kovalentem Charakter<br />
bilden. Die Feststoffe treten meist kristallin auf.<br />
1968 wurden erstmals Phase Change Memories als mögliches<br />
Speichermedium in Betracht gezogen. Jedoch war zu<br />
diesem Zeitpunkt die Technologie noch nicht so weit, um mit<br />
anderen Speichermedien wie DRAM und SRAM mitzuhalten.<br />
Die Chalkogenide wurden jedoch speziell in der optischen<br />
Speicherung weiter erforscht und fanden mit der CD/DVD<br />
RW ihren Markt. Dabei wird mit einem Laser ein Punkt auf<br />
einer CD erhitzt, sodass dieser seinen Zustand ändert<br />
(amorph zu kristallin und wieder zurück).<br />
Erst als im Zuge dieser Entwicklungen Materialien entdeckt<br />
wurden, die bezüglich Schreibzeiten und strömen in interessante<br />
Regionen kamen, bekam auch die PhaseChange<br />
RAMEntwicklung wieder Fahrt.<br />
Beim Phase Change Memory wird das Chalkogenid im<br />
Gegensatz zur optischen Anwendung mit einem Stromimpuls<br />
zur Phasenänderung angeregt. Durch das Wechseln<br />
des Zustands ändert sich der elektrische Widerstand. Dabei<br />
kann zwischen zwei oder auch mehr Zuständen unterschieden<br />
werden und damit noch mehr in einer Zelle gespeichert<br />
werden.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 285
Technologie-Anhang<br />
PCM – Funktionsweise<br />
Im Inneren eines PhaseChangeSpeichers befindet sich<br />
eine winzige Menge einer Halbleiterlegierung, die schnell<br />
zwischen einer geordneten kristallinen Phase mit einem<br />
niedrigeren elektrischen Widerstand und einer ungeordneten<br />
amorphen Phase mit einem viel höheren elektrischen<br />
Widerstand wechseln kann. Da die Aufrechterhaltung beider<br />
Phasenzustände keine Stromzufuhr erfordert, ist der<br />
Phasenwechselspeicher nicht flüchtig.<br />
Der Phasenzustand des Materials wird durch die Amplitude<br />
und Dauer des elektrischen Stromstoßes bestimmt, der für<br />
die Erwärmung des Materials genutzt wird. Wenn die Temperatur<br />
der Legierung bis etwas über den Schmelzpunkt<br />
erhöht wird, verteilen sich die durch Energiezufuhr angeregten<br />
Atome in einer zufälligen Anordnung. Wird die Stromzufuhr<br />
dann abrupt unterbrochen, erstarren die Atome in<br />
dieser willkürlich angeordneten, amorphen Phase. Wird die<br />
Stromzufuhr über einen längeren Zeitraum – ungefähr 10<br />
Nanosekunden – reduziert, bleibt den Atomen genug Zeit,<br />
um in die bevorzugte, gut geordnete Struktur der kristallinen<br />
Phase zurückzukehren.<br />
PCM versus Flash<br />
PCM schließt technologisch dort an, wo NANDFlash an die<br />
Grenzen der Machbarkeit stößt. Nach Ansicht vieler Experten<br />
stehen der FlashTechnologie wegen ihrer beschränkten<br />
Skalierbarkeit in naher Zukunft bereits große Probleme<br />
bevor.<br />
In den AlmadenForschungslabors von <strong>IBM</strong> wurde in<br />
Ko operation mit Macronix und Qimoda an neuen Speichertechniken<br />
gearbeitet, die FlashMemories ablösen können.<br />
Die „Phase Change Memory“Technologie (PCM) ermöglicht<br />
bei kleineren Baugrößen deutlich höhere Geschwindigkeiten.<br />
So verbessern sich die Eigenschaften von PCMs mit<br />
kleiner werdender Größe. Es wird weniger Strom benötigt,<br />
da weniger Material erhitzt werden muss, und es erhöht sich<br />
aufgrund der kleinen Wege die Geschwindigkeit. Alles<br />
Vorteile, die mit dem Kleinerwerden von PCMZellen erzielt<br />
werden können. Allerdings schrumpft auch der elektrische<br />
Widerstand mit dem Kleinerwerden der Zellen und es<br />
wird dadurch schwieriger, die Zustände voneinander zu<br />
unterscheiden. Deshalb ist es wichtig, hier eine gute<br />
Balance zu finden.<br />
„Gemeinsam ist es uns jetzt gelungen, ein neues Material<br />
für PhaseChangeSpeicher zu entwickeln, das auch<br />
bei extremer Miniaturisierung hohe Leistung bietet“, sagt<br />
Rolf Allenspach, Leiter der Gruppe Nanophysik am <strong>IBM</strong><br />
Forschungslabor Rüschlikon bei Zürich.<br />
NANDFlash ist derzeit zwar weiterhin im Kommen, jedoch<br />
ist die Technologie noch teuer, die Kapazitäten für einen<br />
alleinigen Einsatz in Computern zu gering und sie machen<br />
bereits nach 100.000 Lese und Schreibzyklen schlapp.<br />
Diese relativ schnelle Materialermüdung ist zwar bei ComsumerAnwendungen<br />
unproblematisch, sie disqualifiziert die<br />
Module jedoch für den Einsatz als Haupt sowie Pufferspeicher<br />
in Network oder <strong>Storage</strong>systemen. Auf den Markt<br />
drängen auch vermehrt HybridLösungen, die eine herkömmliche<br />
Harddisk mit FlashModulen kombinieren, um<br />
einen schnelleren Datenzugriff zu ermöglichen.<br />
Die FlashMemoryTechnik dürfte ein künftiges Opfer der<br />
Miniaturisierung werden. Neue Produktionsprozesse<br />
machen in Chips zwar immer kleinere Leiterbahnen möglich,<br />
beim FlashSpeicher ist nach aktuellen Forschungen jedoch<br />
bei 45 Nanometer Schluss. Darunter verhindern Streuverluste,<br />
dass sich ohne Stromzufuhr noch Daten speichern<br />
lassen.<br />
Die PCMModule hingegen soll Produktionsprozesse bis<br />
20 Nanometer und sogar darunter ermöglichen. Die theoretische<br />
Grenze der Skalierbarkeit von PCMs liegt bei unter<br />
5 Nanometer. Dabei verwenden die Entwickler für ihre<br />
Speicher als neues Material eine GermaniumLegierung.<br />
PCM – klein und universell einsetzbar<br />
Zusammen mit hoher Leistung und Zuverlässigkeit könnte<br />
PCM daher zur Basistechnologie für Universalspeicher in<br />
mobilen Applikationen werden, denn Phasenwechelspeicher<br />
sind wie Flash nicht flüchtig. Das bedeutet, sie merken sich<br />
die Informationen auch dann, wenn kein Strom zugeführt<br />
wird. Darüber hinaus weist der PCMPrototyp von <strong>IBM</strong> sehr<br />
vorteilhafte technische Werte auf: Er ist 500 Mal schneller<br />
beschreibbar und benötigt dabei nur die Hälfte an Energie.<br />
286 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Zudem seien deutlich mehr Lese und Schreibzyklen möglich<br />
und die Bauelemente sind mit einem Querschnitt von<br />
drei mal 20 Nanometer erheblich kleiner als die kleinsten<br />
heute herstellbaren FlashSpeicher. „Sobald die Skalierbarkeit<br />
von Flash endgültig an ihre Grenzen stößt, wird sich<br />
eine neue Technik wie PCM durchsetzen“, ist Allenspach,<br />
vom <strong>IBM</strong> Labor in Zürich, überzeugt. Dies könnte schon<br />
bald möglich werden.<br />
Heutige PCMs sind etwa 30 Mal schneller im Vergleich zu<br />
Flash und bewegen sich im Bereich von 100 bis 200<br />
Nanometer. Betrachtet man aber die schnelle Entwicklung<br />
bzgl. Schreib und Lesegeschwindigkeit, eignet sich PCM<br />
auch als Ersatz für heute übliches RAM. Mit PCM als Ersatz<br />
von RAM würde das bisherige Booten von Computern<br />
entfallen, allerdings könnten sich Sicherheitsprobleme<br />
ergeben, da die PCMs nicht flüchtig sind (man könnte die<br />
vertraulichen Daten im RAM wie z. B. Passwörter etc.<br />
auslesen). Zudem hat PCM viel weniger Abnutzungserscheinungen,<br />
wie sie etwa bei Flash durch den Verschleiß<br />
der Oxidschicht am Floating Gate auftreten. PCM bietet<br />
also eine lange Datenhaltbarkeit sowie einen nicht allzu<br />
hohen Energieverbrauch beim Betrieb.<br />
Millipede-Nano-Technologie<br />
Mitte der 90erJahre wurde im <strong>IBM</strong> Grundlagenforschungslabor<br />
in Rüschlikon das Projekt „Millipede“ gestartet. Das<br />
Projekt hatte zum Ziel, NanoTechnologie und Nanospeicherarchitekturen<br />
für die Datenspeicherung zu nutzen und in<br />
Speichersubsysteme zu integrieren. Projektleiter in Rüschlikon<br />
war der <strong>IBM</strong> Mitarbeiter Peter Vettinger und die technologisch<br />
treibende Kraft war der <strong>IBM</strong>er und Nobelpreisträger<br />
Gerd Binnig. Die Entwicklung von Millipede brachte <strong>IBM</strong><br />
viele neue Patente im Bereich der NanoTechnologie und<br />
NanoMechanik ein und ergab viele neue Erkenntnisse über<br />
Polymerstrukturen und die Möglichkeit, Kunststoffe als<br />
Datenträger einzusetzen. Die MillipedeEntwicklung ist deshalb<br />
für zukünftige Technologien von maßgeblicher Bedeutung.<br />
Deshalb wurde das Projekt Millipede mit großem<br />
finanziellem Aufwand bis ins Jahr 2007 aktiv weitergetrieben.<br />
Grundprinzip<br />
Das Grundprinzip ist simpel und ist mit dem der früheren<br />
Lochkarte vergleichbar, nun aber mit Strukturgrößen im Bereich<br />
von Nanometern. Ein weiterer entscheidender Unter<br />
schied: mithilfe der eingesetzten Technologie lassen sich Bits<br />
löschen und überschreiben. Winzige Hebelchen mit einer<br />
feinen Spitze aus Silizium schmelzen ebenso winzige Vertiefungen<br />
in ein PolymerMedium, um Bits zu schreiben.<br />
Diesel ben Spitzen kann man auch verwenden, um diese Vertiefungen<br />
nachzuweisen, also die Bits wieder auszulesen.<br />
Dazu bringt man die Spitze in die Nähe des Polymerfilms<br />
und erwärmt sie. Taucht die Spitze in einen BitKrater, erhöht<br />
sich der Wärmeaustausch zwischen ihr und dem Speichermedium,<br />
wodurch der elektrische Widerstand des Hebelchens,<br />
auch Kantilever genannt, abnimmt. Um ein Bit wieder<br />
zu überschreiben, erzeugt man mit der Spitze auf dem<br />
Kraterrand neue Vertiefungen, deren Ränder die alte Vertiefung<br />
überlappen und so das PolymerMaterial in Richtung<br />
Krater drängen.<br />
Weil die Löcher so enorm klein sind, kann man sie sehr dicht<br />
nebeneinandersetzen und so fantastische Datendichten erreichen:<br />
Mit revolutionärer Nanotechnologie ist es <strong>IBM</strong> Wissenschaftlern<br />
im Forschungslabor Rüschlikon gelungen, in<br />
den Bereich der Millionstelmillimeter vorzudringen. So konnte<br />
bei der Speicherung von Daten eine Aufzeichnungsdichte<br />
von 1 Terabit pro Quadratzoll überschritten werden – was<br />
etwa dem Inhalt von 25 DVDs auf der Fläche einer Briefmarke<br />
entspricht. Die TerabitDichte wurde mit einer einzelnen SiliziumSpitze<br />
erreicht, die Vertiefungen mit einem Durchmesser<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 287
Technologie-Anhang<br />
von ca. 10 Nanometern erzeugt. Um die Datenrate, also die<br />
Schreib und Lesegeschwindigkeit, zu erhöhen, wird nicht<br />
nur eine Spitze verwendet, sondern eine ganze Matrix von<br />
Hebelchen, die parallel arbeiten. Die neue Version verfügt<br />
über mehr als 4.000 solcher Spitzen, die in einem kleinen<br />
Quadrat von 6,4 Millimetern Seitenlänge angeordnet sind.<br />
Diese Dimensionen ermöglichen es, ein komplettes Speichersystem<br />
hoher Kapazität in das kleinste standardisierte Format<br />
für FlashSpeicher zu packen.<br />
Ein Kantilever im Millipede schreibt und liest aus einer ihm<br />
zugeordneten rund 100 mal 100 Mikrometer kleinen Zelle.<br />
Während sich beispielsweise bei Festplatten der Schreib und<br />
Lesekopf und auch das Speichermedium bewegen, wird beim<br />
MillipedeSpeicher nur das Medium bewegt. Zwei winzige<br />
Spulen, die zwischen Magneten platziert sind, treiben die<br />
Bewegung des Plättchens an: Der Mikroscanner kann mit<br />
einer Genauigkeit von bis zu 2 Nanometern positioniert<br />
werden. Aus der überlappenden Fläche von streifenförmigen<br />
Sensoren kann man die Position jederzeit präzise bestimmen.<br />
Kantilever-Array<br />
Kern der MillipedeTechnologie ist eine zweidimensionale<br />
Anordnung von vförmigen SiliziumFederzungen (Kantilever),<br />
die 70 Mikrometer (Tausendstelmillimeter) lang sind. Am Ende<br />
jeder „Zunge“ befinden sich ein Sensor zum Lesen und ein<br />
Widerstand oberhalb der Spitze zum Schreiben. Die Spitze ist<br />
knapp 1 Mikrometer lang und der Radius beträgt nur wenige<br />
Nanometer. Die Zellen mit den Kantilevern sind auf einem<br />
KantileverArrayChip angeordnet. Der Chip ist 7 x 14 mm<br />
groß. Im Zentrum sitzt das Array, das momentan aus insgesamt<br />
4.096 (64 x 64) Kantilevern besteht, die aus dem Silizium<br />
herausgeätzt sind. Der eigentliche Datenträger besteht<br />
aus einem nur wenige Nanometer dünnen Polymerfilm auf<br />
einem SiliziumSubstrat. Über Multiplexer einzeln angesteuert<br />
lesen, schreiben oder löschen die Köpfe das gewünschte<br />
Bit. Bis zu 100.000 Schreib und ÜberschreibZyklen sind<br />
bisher erfolgreich getestet worden. Obwohl in der Konstruktion<br />
Mech a nik eingesetzt wird, kann die Übertragungsgeschwindigkeit<br />
von bis zu 20 bis 30 Megabit pro Sekunde erreicht<br />
werden (beim Chip der 2. Generation mit 64 x 64 Tips).<br />
Mikroscanner<br />
Die Bewegung des Speichermediums relativ zu dem<br />
KantileverArray wird mithilfe des siliziumbasierten x/y<br />
Mikro scan ners realisiert. Der Scanner besteht aus ca.<br />
6,8 x 6,8 mm² Scan Table, der das PolymerMedium und<br />
zwei elektromagnetische Auslöser trägt. Der ScannerChip<br />
wird auf der Siliziumplatte montiert, die als mechanischer<br />
Grund des <strong>System</strong>s dient. Der Abstand zwischen seiner<br />
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<br />
Scanners beträgt ca. 20 µm. Die Scan Table kann durch<br />
Auslöser in xund yRichtungen um 120 µm bewegt werden.<br />
Jeder Auslöser besteht aus zwei Permanentmagneten, die<br />
in die Siliziumplatte eingebaut sind, und einer kleinen Spule,<br />
die sich zwischen den Magneten befindet. Um die Vibrationen<br />
von außen zu löschen, wird ein sogenanntes Pivot verwendet,<br />
das mit den Auslösern gekoppelt ist.<br />
Positionsbestimmung<br />
Die Informationen über die Positionierung werden durch vier<br />
thermische Sensoren zur Verfügung gestellt. Diese Sensoren<br />
befinden sich direkt über der Scan Table, auf dem Kantilever<br />
Array. Die Sensoren haben thermisch isolierte Erhitzer. Jeder<br />
Sensor wird über einen Rand der ScanTabelle in Position<br />
gebracht und wird durch Strom erhitzt. Ein Teil dieser Wärme<br />
wird durch die Luft auf die Scan Table geleitet, die nun<br />
als Kühler dient. Eine Versetzung der Scan Table verursacht<br />
eine Änderung der Effizienz dieses Kühlsystems, was<br />
zur Änderung der Temperatur des elektrischen Widerstands<br />
vom Erhitzer führt.<br />
Ein raffiniertes Design gewährleistet die exakte Nivellierung<br />
der Spitzen über dem Speichermedium und dämpft Vibrationen<br />
und Stöße von außen. ZeitmultiplexingElektronik, wie<br />
sie in ähnlicher Art in Speicherchips (DRAM) verwendet wird,<br />
ermöglicht die Adressierung jeder einzelnen Spitze im Parallelbetrieb.<br />
Elektromagnetische Aktuation bewegt das Substrat<br />
mit dem Speichermedium auf dessen Oberfläche sehr präzise<br />
in x und yRichtung, sodass jede Spitze in ihrem Speicherfeld<br />
von 100 Mikrometern Seitenlänge lesen und schreiben<br />
kann. Die kurzen Distanzen tragen wesentlich zu einem<br />
geringen Energieverbrauch bei.<br />
Für die Funktionen des Gerätes, d. h. Lesen, Schreiben,<br />
Löschen und Überschreiben, werden die Spitzen mit dem<br />
Polymerfilm auf dem Siliziumsubstrat in Kontakt gebracht.<br />
Schreibtechnologie<br />
Das Schreiben von Bits erfolgt durch Aufheizen des in den<br />
Kantilever integrierten Widerstands auf typischerweise 400<br />
Grad Celsius. Die dadurch ebenfalls aufgeheizte Spitze weicht<br />
das Polymer auf, sinkt ein und hinterlässt eine Vertiefung<br />
von wenigen Nanometern. Zum Lesen wird der LeseSensor<br />
des Kantilevers erhitzt, ohne den Polymerfilm aufzuweichen.<br />
„Fällt“ nun die Spitze in eine Vertiefung, kühlt sich der Lese<br />
Sensor wegen des geringeren Abstands zum Substrat geringfügig<br />
ab, was aber zu einer messbaren Veränderung<br />
des Widerstands führt. Um Daten zu überschreiben, setzt<br />
die Spitze Vertiefungen in die Oberfläche. Deren äußere<br />
Ränder überlappen die alten Vertiefungen und löschen so<br />
die alten Daten. Mehr als 100.000 Schreib und Überschreib<br />
Zyklen haben den Nachweis erbracht, dass sich das Konzept<br />
für einen wiederbeschreibbaren Speichertyp eignet.<br />
Um die Daten schneller in den Speicher und wieder hinaus<br />
zu bekommen, bearbeitet eine komplette MatrixAnordnung<br />
an Hebelchen das Medium gleichzeitig. Es stellte sich allerdings<br />
heraus, dass es enorm schwierig ist, Mechanik und<br />
Elektronik in einem Stück auf einem Chip zu fertigen. Die<br />
Wissenschaftler entschlossen sich also, den Aufbau in zwei<br />
Stücken zu realisieren:<br />
1. Die Matrix der Mikrospitzen wird mit winzigen Kontaktstiften<br />
versehen, die unter dem Elektronenmikroskop aussehen<br />
wie die Noppen von Lego-Steinchen.<br />
2. Diese Studs werden dann mit den Gegenstücken auf der<br />
elektronischen Platine kontaktiert.<br />
Mit den gezeigten Prototypen wurde unlängst die technische<br />
Machbarkeit eines Produktes etwa hinsichtlich Speicherdichte,<br />
Leistung und Verlässlichkeit demonstriert. Während<br />
die heute eingesetzten Speichertechnologien allmählich an<br />
fundamentale Grenzen stoßen, hat der nanomechanische<br />
Ansatz ein enormes Entwicklungspotenzial für eine tausendfach<br />
höhere Speicherdichte. Dieser nanomechanische Datenträger<br />
entwickelt nahezu keine Wärme, nimmt nur wenig<br />
Strom auf und ist völlig schockresistent.<br />
Millipede-Projektphasen<br />
Während der gesamte Projektlaufzeit wurden Chips in drei<br />
Generationen entwickelt. Der letzte fertiggestellte Chip<br />
im Jahr 2007 arbeitet mit 128 x 128 Tips, hat eine kapazitive<br />
Speichermöglichkeit von 160 Gbytes und eine Datenrate<br />
von 120 Mbit/s. <strong>IBM</strong> überlegt derzeit, wie und auf welche<br />
Weise MillipedeChips sinnvoll zum Einsatz kommen können.<br />
Es bleibt also spannend, auf welche Weise NanoTechnologien<br />
und NanoMechanik in die Welt der Datenspeicherung<br />
Einzug halten werden.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 289
Technologie-Anhang<br />
Revolutionäre Speichertechnologie aus der <strong>IBM</strong> Forschung rückt<br />
näher an die Realisierung<br />
„Racetrack Memory“ eröffnet neue Dimensionen in<br />
Speicherdichte, Geschwindigkeit und Zuverlässigkeit<br />
11. April 2008: <strong>IBM</strong> Forscher berichten im renommierten<br />
Wissenschaftsjournal Science über einen Durchbruch in der<br />
Erforschung einer neuen Speichertechnologie, die unter<br />
dem Namen „Racetrack“ (deutsch: Rennstrecke) bekannt<br />
geworden ist. Die Technologie könnte eine neue Klasse von<br />
Speichern hervorbringen, die die hohe Leistungsfähigkeit<br />
von FlashSpeichern mit der großen Kapazität und den niedrigen<br />
Kosten von Festplattenspeichern auf sich vereint.<br />
In der aktuellen Ausgabe von Science beschreiben <strong>IBM</strong><br />
Fellow Stuart Parkin und seine Kollegen vom <strong>IBM</strong> Almaden<br />
Research Center, USA, einen bedeutenden Schritt in der<br />
Entwicklung von Speicherbausteinen auf Basis des „RacetrackVerfahrens“.<br />
Innerhalb der nächsten zehn Jahre<br />
könnte die Technologie zum Einsatz kommen und neue<br />
Größenordnungen von Speicherkapazitäten eröffnen, ein<br />
extrem schnelles Einschalten von elektronischen Geräten<br />
ermöglichen und dabei wesentlich kostengünstiger,<br />
energieeffizienter und robuster als heutige <strong>System</strong>e sein.<br />
Stuart Parkin, <strong>IBM</strong> Fellow und einer der größten Speicher-Forscher und Entwickler bei <strong>IBM</strong><br />
Stuart Parkin war es zu verdanken, dass der GMREffekt<br />
(Plattentechnologie, siehe unter GMR) zu einem Produkt in<br />
Form eines GMRLesekopfes umgesetzt wurde, und er<br />
benötigte sieben Jahre dazu. Ihm und seinem Team ist es<br />
zu verdanken, dass die hohen Festplattenkapazitäten heute<br />
möglich wurden. Der Autor findet es nicht richtig, dass<br />
Stuart Parkin bei der Vergabe des Nobelpreies für Physik im<br />
Jahr 2007 unberücksichtigt blieb, zumal der Nobelpreis an<br />
drei Personen hätte verliehen werden können. Mit Racetrack<br />
Memories wird er wirkliche Geschichte im Speicher bereich<br />
schreiben! Davon ist der Autor überzeugt!<br />
Universalspeicher der Zukunft<br />
Das revolutionäre Konzept beruht auf der Speicherung von<br />
Informationen in Form von winzigen, gegensätzlich magnetisierten<br />
Regionen (Domänen) in einem Nanodraht. Bei der<br />
herkömmlichen als Speichermedium verwendeten Festplatte<br />
werden das Medium und ein Schreib/Lesekopf bewegt, um<br />
Daten zu lesen, zu schreiben oder zu löschen. Anders beim<br />
„RacetrackVerfahren“: Hier werden die magnetischen Domänen<br />
zu den zentralen Lese und Schreibeinheiten, die in der<br />
Mitte des Nanodrahtes angebracht sind, hin verschoben –<br />
und dies mit extrem hoher Geschwindigkeit. Die gespeicherten<br />
Datenbits scheinen durch den Datenleiter zu „rasen“, daher<br />
der Name „Racetrack“.<br />
290 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
Da ein einzelner ‘Racetrack’ nur wenige Nanometer groß ist<br />
und zwischen 10 und 100 Bits speichern kann, erlaubt die<br />
Technologie extrem hohe Speicherdichten. Im Vergleich zu<br />
FlashSpeichern könnte ein ‘RacetrackSpeicher’ eine 100mal<br />
größere Datenmenge auf derselben Fläche aufzeichnen.<br />
Das entspräche rund 500 000 Musiktiteln oder 3 500 Filmen.<br />
Durch den minimalen Stromverbrauch eines ‘Racetrack<br />
Speichers’ könnte ein MP3Gerät zudem wochenlang mit<br />
einer einzigen Batterie betrieben werden.<br />
Darüber hinaus benötigt das Verfahren keine beweglichen<br />
Teile, wodurch nahezu keine Abnutzungs oder Verschleißerscheinungen<br />
auftreten. Das macht den ‘RacetrackSpeicher’<br />
widerstandsfähiger als alle existierenden Speichertechnologien<br />
und verleiht ihm eine quasi unbegrenzte Lebensdauer.<br />
„Die Verbindung zwischen der Erforschung von neuen<br />
physi kalischen Phänomenen, die auf der molekularen und atomaren<br />
Ebene auftreten, und dem NanoEngineering – der<br />
Fähigkeit, gezielt Materialstrukturen aus einzelnen Atomen<br />
Da ein einzelner „Racetrack“ nur wenige Nanometer groß ist<br />
und zwischen 10 und 100 Bits speichern kann, erlaubt die<br />
Technologie extrem hohe Speicherdichten. Im Vergleich zu<br />
FlashSpeichern könnte ein „RacetrackSpeicher“ eine 100mal<br />
größere Datenmenge auf derselben Fläche aufzeichnen.<br />
Das entspräche rund 500.000 Musiktiteln oder 3.500 Filmen.<br />
Durch den minimalen Stromverbrauch eines „Racetrack<br />
Speichers“ könnte ein MP3Gerät zudem wochenlang mit<br />
einer einzigen Batterie betrieben werden.<br />
Darüber hinaus benötigt das Verfahren keine beweglichen<br />
Teile, wodurch nahezu keine Abnutzungs oder Verschleißerscheinungen<br />
auftreten. Das macht den „RacetrackSpeicher“<br />
widerstandsfähiger als alle existierenden Speichertechnologien<br />
und verleiht ihm eine quasi unbegrenzte Lebensdauer.<br />
„Die Verbindung zwischen der Erforschung von neuen<br />
physi kalischen Phänomenen, die auf der molekularen und<br />
atomaren Ebene auftreten, und dem NanoEngineering –<br />
der Fähigkeit, gezielt Materialstrukturen aus einzelnen<br />
Atomen und Molekülen zu erschaffen – birgt immer neue,<br />
spannende Herausforderungen“, erklärt Stuart Parkin.<br />
Er führt weiter aus:<br />
„Ein Ausschöpfen des Potenzials, das in unserer<br />
„RacetrackTechnologie“ liegt, könnte zu faszinierenden<br />
neuen Anwendungen führen – Anwendungen, die heute<br />
noch unvorstellbar sind.“<br />
Schematische Darstellung der Racetrack-Memory-Speicherung<br />
Bereits mehrmals in der Geschichte der <strong>IBM</strong> wurden<br />
durch radikale technische Innovationen, die in der Grundlagenforschung<br />
ihren Anfang nahmen, neue Märkte und<br />
Anwendungs felder erschlossen. Hierzu zählen etwa der<br />
Memory Chip, die relationale Datenbank oder die Festplatte.<br />
Die „Racetrack-Methode“<br />
Seit rund 50 Jahren versuchen Wissenschaftler, digitale<br />
Informationen durch sogenannte magnetische Domänenwände<br />
– die Grenzflächen zwischen zwei gegensätzlich<br />
magnetisierten Regionen in einem magnetischen Material –<br />
zu speichern. Bis jetzt war die Manipulation von Domänenwänden<br />
nur durch kostspielige, komplexe und energieintensive<br />
Verfahren möglich.<br />
In ihrer nun veröffentlichten Arbeit „CurrentControlled<br />
Magnetic DomainWall Nanowire Shift Register“ demonstrieren<br />
Parkin und seine Teamkollegen eine neue, sehr effiziente<br />
Methode. Hierbei werden die Domänenwände durch einen<br />
spinpolarisierten Strom bewegt, der die Magnetisierung in<br />
der Wand drehen kann. Ursache hierfür ist der Spintransfer<br />
Effekt, der die Speichertechnologie erheblich vereinfacht,<br />
weil der Strom direkt durch die Domänenwände fließt und<br />
keine zusätzlichen Magnetfelder generiert werden müssen.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 291
Technologie-Anhang<br />
In der zweiten Arbeit „Magnetic DomainWall Racetrack<br />
Memory“ fassen die Forscher die Grundprinzipien der<br />
„RacetrackTechnologie“ zusammen. Diese beruht auf der<br />
Speicherung von Daten in winzigen magnetischen Regionen<br />
innerhalb eines Datenleiters. Als Datenleiter verwenden die<br />
Forscher kleine Nanodrähte, die magnetisch mit Informationen<br />
beschrieben werden. Diese werden der Länge nach<br />
waagerecht oder in Form einer Schlaufe senkrecht auf einer<br />
Siliziumfläche angebracht. Wenn eine Spannung angelegt<br />
wird, bewegen sich dabei weder die Drähte noch das<br />
Silizium, sondern nur die magnetischen Domänenwände,<br />
in denen die Information gespeichert wird.<br />
Jede magnetische Domäne, die ein Bit repräsentiert, verfügt<br />
über einen „Head“, einen magnetischen Nordpol, und einen<br />
„Tail“, einen magnetischen Südpol. Die Domänenwände,<br />
die sich an den Grenzflächen formen, wechseln sich so im<br />
Datenleiter zwischen „HeadtoHead“ und „TailtoTail“<br />
Konfigurationen ab. Die Abstände zwischen zwei hintereinander<br />
folgenden Domänenwänden gleichen der BitLänge<br />
und werden durch Markierungen entlang des Nanodrahtes,<br />
so genannte Pinningzentren, bestimmt.<br />
In ihrem Experiment verwendeten die Forscher Nanodrähte<br />
aus Permalloy (einer FeNiLegierung) und zeigten, wie<br />
sie Domänenwände gezielt kreieren, verschieben und auslesen,<br />
indem sie Stromimpulse von präzise kontrollierter<br />
Dauer im Nanosekundenbereich verwenden. Der Schreibund<br />
Verschiebe zyklus benötigt gerade einmal einige<br />
10 Nanosekunden.<br />
Ziel ist es, viele Tausende dieser NanodrahtSpeicher, die<br />
zwischen 10 und 100 Bits speichern können, dicht auf einer<br />
Fläche anzuordnen. Die senkrechte Anordnung von Nanodrähten<br />
eröffnet zudem neuartige dreidimensionale Architekturen<br />
– ein Paradigmenwechsel im Vergleich zu derzeitigen<br />
zweidimensionalen Chip und Speichertechnologien.<br />
Die Ausnutzung der dritten Dimension schafft neue Spielräume<br />
für Leistungssteigerungen und Kostenreduktionen,<br />
die nicht mehr nur – wie bis jetzt – durch Miniaturisierung<br />
erzielt werden.<br />
Stuart Parkin darf sich zu Recht freuen, er hat es geschafft und Racetrack<br />
kann die Welt verändern<br />
292 1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
IUPAP Magnetism Award und Louis Neel Medaille<br />
Am 27 Juli 2009 erhält <strong>IBM</strong> Fellow Dr. Stuart Parkin eine der<br />
höchsten Auszeichnungen, die auf dem Gebiet der Erforschung<br />
des Magnetismus vergeben werden. Er wird in<br />
Karlsruhe auf der „International Conference on Magnetism“<br />
mit dem „International Union of Pure and Applied Physics<br />
Magnetism Award (IUPAP) und der Louis Neel Medaille für<br />
seine fundamentalen Erforschungs und Entwicklungsergebnisse<br />
im Bereich des NanoMagnetismus ausgezeichnet.<br />
Diese Auszeichnung wird durch das IUPAP Magnetism<br />
Committee nur alle drei Jahre vergeben. Vor allem wurde<br />
er für seine letzten Forschungsergebnisse bezüglich der<br />
Racetrack Memories geehrt. Die Louis Neel Medaille geht<br />
zurück auf den Wissenschaftler Louis Eugene Felix Neel,<br />
der 1970 den NobelPreis für Physik für die Entdeckung des<br />
Antiferromagnetismus erhielt.<br />
Nanotechnologie – Schlüsseltechnologie des 21. Jahrhunderts<br />
Nanotechnologie stellt eine neue Technologie dar, die Funktionen<br />
in einem außerordentlich kleinen Maßstab anwendet.<br />
Sie konzentriert sich auf Strukturen und Prozesse in Dimensionen<br />
unter 100 Nanometer – ungefähr 400mal dünner als<br />
ein menschliches Haar. Im Größenbereich der Nanometer<br />
spielen sich viele grundlegende Prozesse der Biologie, Chemie<br />
und Physik ab, die in bislang ungekanntem Maß kontrolliert<br />
werden können und neue Perspektiven in vielen<br />
Bereichen eröffnen. Dazu gehören hochentwickelte funktionale<br />
Materialien, Nanoelektronik, Informations und Kommunikationstechnologie,<br />
Sensorik, Life Sciences sowie Energietechnologie.<br />
NanotechAnwendungen könnten zur<br />
effizienteren Nutzung von Solarenergie beitragen oder zu<br />
neuen Arten der Wasseraufbereitung.<br />
Durch die Forschung an der ETH Zürich (Eidgenössische<br />
Technische Hochschule) und am <strong>IBM</strong> Forschungslabor in<br />
Rüschlikon ZRL (Zürich Research Laboratory) sind von<br />
Zürich immer wieder entscheidende Impulse in der Quantenmechanik<br />
und Nanoforschung ausgegangen. Dies sind<br />
zum Beispiel die bahnbrechenden Konzepte der Quantenmechanik<br />
durch den ETHPhysiker und Nobelpreisträger<br />
Wolfgang Pauli oder die Entwicklung des Rastertunnelmikroskops<br />
(RTM) durch Gerd Binnig und Heinrich Rohrer am<br />
<strong>IBM</strong> Forschungslabor in Rüschlikon. Dafür erhielten die<br />
Forscher 1986 den Nobelpreis für Physik. Dieses Gerät<br />
ermöglichte den ersten Blick in die Welt der Atome. Kurz<br />
darauf wurde es möglich, einzelne Atome zu manipulieren,<br />
wodurch die Tür zur Nanotechnologie weit aufgestoßen<br />
wurde. Das RTM wird generell als das Instrument angesehen,<br />
das das Tor zum Nanokosmos öffnete. Das Rasterkraftmikroskop<br />
(RKM), das eng mit dem RTM verwandt ist,<br />
wurde 1986 von Gerd Binnig erfunden.<br />
Das Rastertunnelmikroskop (RTM) wird im Englischen<br />
als STM (Scanning Tunnelling Microscope) bezeichnet,<br />
das Rasterkraftmikroskop (RKM) als AFM (Atomic Force<br />
Microscope).<br />
<strong>IBM</strong> und ETH Zürich gründen neues gemeinsames<br />
Nanotech-Forschungszentrum<br />
Rund 6.000 Quadratmeter umfasst das neue Nanotech<br />
Forschungszentrum von <strong>IBM</strong> und ETH Zürich. Die beiden<br />
Institutionen verbindet eine langjährige Tradition wissenschaftlicher<br />
Zusammenarbeit. An einer gemeinsamen Medienkonferenz<br />
in Zürich kündigten Ralph Eichler, Präsident der<br />
ETH Zürich, und John E. Kelly, Senior VicePresident und<br />
Direktor für Forschung bei <strong>IBM</strong>, die geplante Zusammenarbeit<br />
an. Zentrales Element dieser Zusammenarbeit ist ein neues<br />
Gebäude, das auf dem Gelände des ZRL in Rüschlikon<br />
gebaut wird. Die Grundsteinlegung erfolgt im Frühjahr 2009.<br />
Nanoforschung auf dem allerhöchsten Niveau wird das<br />
neue Forschungszentrum auf dem Campus der <strong>IBM</strong> in<br />
Rüschlikon ermöglichen. Das „Nanoscale Exploratory Technology<br />
Laboratory“ ist Teil einer wichtigen strategischen<br />
Partnerschaft in Nanotechnologie mit der Eidgenössischen<br />
Technischen Hochschule Zürich (ETHZ). Die Forschungsaktivitäten<br />
werden 2011 aufgenommen.<br />
<strong>IBM</strong> Forschungsstandort Rüschlikon: neues Labor für Nano-Technologie<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 293
Technologie-Anhang<br />
Forschungsschwerpunkte der beiden Institutionen reichen<br />
von der Grundlagenforschung bis hin zu angewandter<br />
Forschung. Gemeinsam wird in verschiedenen Bereichen<br />
geforscht, wie zum Beispiel kohlenstoffbasierte Materialien,<br />
NanoPhotonics, Spintronics, Nanodrähte und Tribologie.<br />
Neuer Durchbruch in der Nanotechnologie –<br />
<strong>IBM</strong> Forscher messen den Ladungszustand von einzelnen<br />
Atomen mit dem Rasterkraftmikroskop<br />
In Zusammenarbeit mit Wissenschaftlern der Universitäten<br />
Regensburg und Utrecht erzielten im Juni 2009 <strong>IBM</strong> Forscher<br />
einen Durchbruch auf dem Gebiet der Nanotechnologie.<br />
Sie konnten zum ersten Mal den Ladungszustand von<br />
einzelnen Atomen direkt mittels Rasterkraftmikroskopie<br />
(RKM) messen. Die Präzision, mit der sie dabei zwischen<br />
ungeladenen bzw. positiv oder negativ geladenen Atomen<br />
unterscheiden konnten, betrug eine einzelne Elektronenladung<br />
bei einer nanometergenauen räumlichen Auflösung.<br />
Dies eröffnet neue Möglichkeiten für die Erforschung von<br />
Nanostrukturen und Bausteinen auf atomarer und molekularer<br />
Skala in Anwendungsbereichen wie etwa der molekularen<br />
Elektronik, der Katalyse oder der Photovoltaik.<br />
Für ihre Experimente verwendeten die Forscher eine Kombination<br />
aus Rastertunnel (RTM) und Rasterkraftmikroskop<br />
(RKM), betrieben im Ultrahochvakuum und bei tiefen Temperaturen<br />
(5 Kelvin), um die für die Messungen notwendige<br />
Stabilität zu erreichen.<br />
Ein RKM misst mittels einer atomar feinen Spitze, die auf<br />
einem schwingenden Federbalken angebracht ist, die<br />
Kräfte, die zwischen dieser Spitze und den Atomen auf dem<br />
Substrat auftreten. In der vorliegenden Arbeit verwendeten<br />
die Forscher einen sogenannten qPlusKraftsensor, bei dem<br />
die Spitze auf einem Zinken einer Stimmgabel, wie man sie<br />
in mechanischen Uhrwerken von Armbanduhren findet,<br />
angebracht ist, während der andere Zinken fixiert ist. Die<br />
Stimmgabel wird mechanisch angeregt und schwingt mit<br />
einer Amplitude von 0,02 Nanometer. Dies entspricht nur<br />
etwa einem Zehntel des Durchmessers eines Atoms. Wird<br />
die RKMSpitze nun sehr nah über der Probe, etwa über<br />
einem einzelnen Atom, platziert, verändert sich die Resonanzfrequenz<br />
der Stimmgabel aufgrund der Kräfte, die zwischen<br />
Probe und Spitze auftreten.<br />
Mit dieser Methode und unter extrem stabilen Bedingungen<br />
konnten die <strong>IBM</strong> Forscher nun die minimalen Unterschiede<br />
in der Kraft messen, die zwischen Spitze und einzelnen,<br />
unterschiedlich geladenen Atomen herrscht. Die Kraftdifferenz<br />
zwischen einem neutralen Goldatom und einem Goldatom<br />
mit einem zusätzlichen Elektron, beträgt nur etwa<br />
11 PikoNewton, gemessen bei einer minimalen Distanz<br />
zwischen Spitze und Probe von ungefähr einem halben<br />
Nanometer. Die Messgenauigkeit dieser Experimente liegt<br />
im Bereich von 1 PikoNewton, was der Gravitationskraft<br />
entspricht, die zwei Menschen in einem Abstand von mehr<br />
als einem halben Kilometer aufeinander ausüben. Die<br />
Forscher bestimmten zudem, wie sich die Kraft mit der<br />
zwischen Spitze und Probe angelegten Spannung veränderte.<br />
Dies erlaubte die Unterscheidung, ob das entsprechende<br />
Atom negativ oder positiv geladen war.<br />
Dieser Durchbruch ist ein weiterer, wichtiger Fortschritt auf<br />
dem Gebiet der Nanoforschung. Im Gegensatz zum RTM,<br />
das auf elektrisch leitfähige Proben angewiesen ist, kann<br />
das RKM auch für nicht leitende Proben verwendet werden.<br />
In der molekularen Elektronik, in der die Verwendung von<br />
Molekülen als funktionale Bausteine in zukünftigen Schaltkreisen<br />
und Prozessoren erforscht wird, werden nicht<br />
leitende Trägersubstanzen (Substrate) benötigt. Deshalb<br />
würde bei solchen Experimenten bevorzugt die Rasterkraftmikroskopie<br />
zum Einsatz kommen.<br />
„Das Rasterkraftmikroskop mit einer Messgenauigkeit von<br />
einer Elektronenladung ist hervorragend dazu geeignet,<br />
den Ladungstransfer in Molekülkomplexen zu untersuchen,<br />
was uns wertvolle, neue Erkenntnisse und physikalische<br />
Grundlagen liefern könnte und zudem eines Tages zu neuen<br />
Bauelementen in der Informationstechnologie führen könnte“,<br />
erklärt Gerhard Meyer, der die Forschung im Bereich Rastertunnel<br />
und Rasterkraftmikroskopie am <strong>IBM</strong> Forschungslabor<br />
Zürich leitet. Computerbausteine auf der molekularen Skala<br />
haben das Potenzial, um Größenordnungen kleiner, schneller<br />
und auch energieeffizienter zu sein als heutige Transistoren<br />
und Speicherbausteine.<br />
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<br />
vorstellen, Verbindungen aus einzelnen metallischen Atomen<br />
und Molekülen herzustellen, diese mit Elektronen zu laden<br />
und deren Verteilung direkt mit dem RKM zu messen.<br />
<strong>IBM</strong> Forscher Leo Gross weist auch auf die Bedeutung ihrer<br />
Arbeit für andere Bereiche hin: „Ladungszustand und<br />
Ladungsverteilung sind kritische Größen in der Katalyse<br />
und bei der Umwandlung von Licht in elektrische Energie.<br />
Das Abbilden der Ladungsverteilung auf atomarer Skala<br />
könnte zu einem besseren Verständnis der grundlegenden<br />
Abläufe auf diesen Gebieten führen.“<br />
Die jüngsten Ergebnisse schließen sich einer Reihe grundlegender<br />
wissenschaftlicher Durchbrüche an, die <strong>IBM</strong><br />
Forschern in den letzten Jahren gelungen sind: 2008 gelang<br />
es Wissenschaftlern am <strong>IBM</strong> Almaden Research Center in<br />
Kalifornien, mit einem qPlusRKM erstmals die Kraft zu<br />
messen, die benötigt wird, um ein Atom auf einer Oberfläche<br />
zu verschieben. Dies bahnte den Weg für die aktuellen<br />
Experimente. 2007 demonstrierte das Team um Gerhard<br />
Meyer am <strong>IBM</strong> Forschungslabor Zürich ein Molekül, das<br />
kontrolliert zwischen zwei Zuständen geschaltet werden<br />
konnte, ohne Veränderung seiner äußeren Form. Schon<br />
2004 war der gleichen Gruppe ein Experiment gelungen,<br />
in dem sie gezielt den Ladungszustand eines einzelnen<br />
Goldatoms mit einem RTM manipulieren konnte. Indem sie<br />
Spannungspulse an die RTMSpitze anlegten, konnten die<br />
Forscher ein zusätzliches Elektron auf ein einzelnes Atom,<br />
das sich auf einem isolierenden Substrat befand, aufbringen.<br />
Dieses negativ geladene Atom blieb stabil, bis mittels<br />
der RTMSpitze ein entsprechender Spannungspuls mit<br />
umgekehrtem Vorzeichen erfolgte. Diese Methode verwendeten<br />
die Forscher auch in ihren aktuellen Experimenten,<br />
um die einzelnen Atome zu laden.<br />
<strong>IBM</strong> Forscher zeigen erstmals die innere Struktur von<br />
Molekülen mit atomarer Auflösung<br />
<strong>IBM</strong> Forscher im <strong>IBM</strong> ZRL Rüschlikon gelang es im August<br />
2009, erstmals die vollständige chemische Struktur eines<br />
Moleküls mit einem Rasterkraftmikroskop atomar aufzulösen.<br />
Den Wissenschaftlern gelang damit ein Durchbruch auf dem<br />
Gebiet der Nanowissenschaften, der auch der Erforschung<br />
neuartiger elektronischer Bauelemente auf der atomaren<br />
und molekularen Skala neue Möglichkeiten eröffnen könnte.<br />
In den letzten Jahren wurden in der Charakterisierung von<br />
Nanostrukturen auf der atomaren Skala mittels Rasterkraftmikroskopie<br />
erstaunliche Fortschritte erzielt. Der Blick auf<br />
die innere Struktur eines Moleküls mit atomarer Auflösung<br />
blieb der Wissenschaft jedoch bis jetzt verwehrt.<br />
In der Ausgabe des Wissenschaftsjournals Science vom<br />
28. August 2009 berichten die <strong>IBM</strong> Forscher Leo Gross,<br />
Fabian Mohn, Nikolaj Moll und Gerhard Meyer sowie Peter<br />
Liljeroth von der Universität in Utrecht, wie sie mithilfe eines<br />
RKMs die vollständige, chemische Struktur von Pentazen<br />
Molekülen (C22H14) mit atomarer Auflösung abbilden konnten.<br />
Die Experimente wurden im Ultrahochvakuum und bei<br />
sehr tiefen Temperaturen (5 Kelvin oder –268°C) durchgeführt.<br />
Die erzielten Abbildungen haben in gewisser Weise<br />
Ähnlichkeit mit Röntgenaufnahmen, die einen Blick ins<br />
Innere des menschlichen Körpers erlauben. Das „RKM mit<br />
Röntgenblick“ der <strong>IBM</strong> Forscher kann durch die Elektronenwolke<br />
schauen, die das Molekül umhüllt, und das atomare<br />
Rückgrat eines Pentazens abbilden.<br />
Diese Publikation folgt nur gerade zwei Monate nach einer<br />
weiteren Arbeit der gleichen Gruppe, die am 12. Juni 2009<br />
in Science veröffentlicht wurde. In dieser wurde die<br />
Ladungsmessung einzelner Atome mittels RKM beschrieben.<br />
„Rastersondentechnologien bieten ein unvergleichliches<br />
Potenzial, um auf der atomaren Skala Prototypen<br />
komplexer funktionaler Strukturen zu bauen und damit deren<br />
elektronischen und chemischen Eigenschaften gezielt maßzuschneidern<br />
und zu untersuchen“, erklärt Gerhard Meyer,<br />
der die Forschung im Bereich Rastertunnelmikroskopie und<br />
Rasterkraftmikroskopie bei <strong>IBM</strong> in Rüschlikon leitet.<br />
Die Ergebnisse der beiden Forschungsarbeiten eröffnen<br />
neue Möglichkeiten, um die Ladungsverteilung in spezifischen<br />
Molekülen oder Molekülnetzwerken zu untersuchen.<br />
Das Wissen um diese Vorgänge ist generell sehr wichtig<br />
für die Entwicklung von elektronischen Bauelementen auf<br />
der atomaren und molekularen Skala. Solche Bauelemente<br />
könnten in der Zukunft schnellere, leistungsfähigere<br />
und energieeffizientere Prozessoren und Speicherchips<br />
ermöglichen, wenn die Grenzen heutiger Chiptechnologien<br />
ausgereizt sind.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang 295
Technologie-Anhang<br />
Das RKM verwendet eine winzige, sehr scharfe Metallspitze,<br />
um die minimalen Kräfte zu messen, die auftreten, wenn<br />
diese Spitze sehr nah an eine Probe, wie etwa ein Molekül,<br />
herangeführt wird. Mit einer PunktfürPunktMessung dieser<br />
Kräfte kann daraus ein Abbild der Oberfläche erstellt<br />
werden. Die PentazenMoleküle, die die <strong>IBM</strong> Forscher in der<br />
vorliegenden Arbeit verwendeten, bestehen aus 22 Kohlenstoffatomen<br />
und 14 Wasserstoffatomen und haben eine<br />
Länge von nur 1,4 Nanometern (Millionstelmillimeter).<br />
Die Abstände der in Sechsecken angeordneten Kohlenstoffatome<br />
sind dabei noch rund zehnmal kleiner. Auf den<br />
RKMAufnahmen sind diese hexagonalen Kohlenstoffringe<br />
be stechend klar aufgelöst und selbst die Positionen der<br />
Wasserstoffatome können eindeutig identifiziert werden.<br />
<strong>IBM</strong> Forscher Leo Gross betont: „Ausschlaggebend für<br />
die Auflösung waren eine atomar scharfe Spitze mit einem<br />
definierten Aufbau sowie eine sehr hohe Stabilität des<br />
Gesamtsystems.“ Damit die chemische Struktur eines<br />
Moleküls sichtbar wird, ist es notwendig, die Spitze äußerst<br />
nah – weniger als einen Nanometer – an das Molekül<br />
heranzuführen. Nur in diesem Bereich treten Kräfte auf, die<br />
maßgeblich durch chemische Wechselwirkung bestimmt<br />
werden. Um dies zu erreichen, mussten die Forscher die<br />
Empfindlichkeit der Spitze verbessern und eine große Hürde<br />
überwinden: Ähnlich wie zwei nebeneinander liegende<br />
Magnete, die sich anziehen oder abstoßen, verschiebt sich<br />
das Molekül oder heftet sich an die Spitze, wenn diese<br />
zu nahe kommt. Geschieht dies, können keine weiteren<br />
Messungen durchgeführt werden.<br />
Beide Probleme konnten durch die Wahl eines geeigneten<br />
Atoms oder Moleküls an der RKMSpitze gelöst werden.<br />
„Um unsere Spitze zu schärfen, haben wir gezielt Atome<br />
und Moleküle durch Manipulationstechniken an die Spitze<br />
angefügt. Unsere Messungen mit unterschiedlich präparierten<br />
Spitzen zeigen deutlich, dass das vorderste Atom<br />
oder Molekül der Spitze die Auflösung entscheidend beeinflusst“,<br />
konstatiert Leo Gross. Ein Kohlenstoffmonoxid<br />
Molekül (CO) an der Spitze brachte den Durchbruch und<br />
sorgte, bei einem Abstand von etwa einem halben Nanometer<br />
zum Pentazen, für optimale Auflösung der einzelnen<br />
Atompositionen und deren chemische Verbindungen.<br />
Den Wissenschaftern gelang es außerdem, eine<br />
vollständige dreidimensionale, topografische Abbildung der<br />
Kräfte über dem Molekül zu erstellen. „Die Datenerhebung<br />
beanspruchte mehr als 20 Stunden. Dies stellte höchste<br />
Ansprüche an die thermische und mechanische Stabilität<br />
unseres <strong>System</strong>s, um zu gewährleisten, dass die Spitze<br />
und das Molekül während der gesamten Zeit unverändert<br />
blieben“, beschreibt Fabian Mohn, Doktorand bei <strong>IBM</strong><br />
Research in Rüschlikon.<br />
Theoretische Rechnungen, durchgeführt von <strong>IBM</strong> Forscher<br />
Nikolaj Moll, bestätigten die experimentellen Ergebnisse<br />
und gaben Aufschluss über die genaue Natur des Abbildungsmechanismus.<br />
Nikolaj Moll erklärt hierzu: „Die Berechnungen<br />
zeigen, dass die sogenannte PauliAbstoßung<br />
zwischen dem COMolekül an der Spitze und dem Pentazen<br />
für den atomaren Kontrast verantwortlich ist.“ Diese abstoßende<br />
Kraft geht auf einen quantenmechanischen Effekt<br />
zurück, der verhindert, dass sich zwei identische Elektronen<br />
zu stark aneinander annähern.<br />
Für die Leser, die noch mehr über die beiden Experimente<br />
und Forschungsarbeiten wissen möchten, ist die wissenschaftliche<br />
Arbeit von L. Gross, F. Mohn, N. Moll, P. Liljeroth<br />
und G. Meyer mit dem Titel „The Chemical Structure of a<br />
Molecule Resolved by Atomic Force Microscopy”, erschienen<br />
in Science, Vol. 325, Nr. 5944, S. 1110 – 1114<br />
(28. August 2009) zu empfehlen.<br />
Nanotechnologien werden in großem Maße in den nächsten<br />
Jahren in der Speichertechnologie ihren Einzug halten und<br />
Speicherchips ermöglichen, die die Grenzen heutiger Chiptechnologien<br />
sprengen – davon ist der Autor überzeugt!<br />
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<br />
Anhang 297
298<br />
Ein ganz herzlicher Dank gilt auch den Sponsoren dieses <strong>IBM</strong> <strong>System</strong> <strong>Storage</strong><br />
<strong>Kompendium</strong>s, welche die Druckauflage unterstützt haben:<br />
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<br />
Anhang<br />
299
300<br />
Ein ganz herzlicher Dank gilt auch den Sponsoren dieses <strong>IBM</strong> <strong>System</strong> <strong>Storage</strong><br />
<strong>Kompendium</strong>s, welche die Druckauflage unterstützt haben:<br />
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<br />
Anhang<br />
301
302<br />
Ein ganz herzlicher Dank gilt auch den Sponsoren dieses <strong>IBM</strong> <strong>System</strong> <strong>Storage</strong><br />
<strong>Kompendium</strong>s, welche die Druckauflage unterstützt haben:<br />
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<br />
Anhang<br />
303
304<br />
Ein ganz herzlicher Dank gilt auch den Sponsoren dieses <strong>IBM</strong> <strong>System</strong> <strong>Storage</strong><br />
<strong>Kompendium</strong>s, welche die Druckauflage unterstützt haben:<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang
INteLLIgeNte uNd INtegRAtIve<br />
LöSuNgeN füR IhR RecheNzeNtRuM<br />
<strong>Storage</strong>- und Servervirtualisierung<br />
Backup- und Recovery-Lösungen<br />
Information Lifecycle Management<br />
Kontakt:<br />
Bechtle Ag<br />
Bechtle Platz 1, 74172 Neckarsulm<br />
www.bechtle.com<br />
Bechtle – Ihr starker It-Partner. heute und morgen.<br />
Martin Schneider<br />
telefon: +49 7132 981-3676<br />
e-Mail: ibmstorage@bechtle.com<br />
skalierbares <strong>Storage</strong> Networking<br />
gesetzeskonforme Archivierung<br />
hierarchische <strong>Storage</strong>konzepte<br />
die Bechtle Ag ist mit einem umsatz von rund 1,43 Mrd. € und rund 4.400 Mitarbeitern<br />
führendes deutsches <strong>System</strong>haus. An über 50 Standorten in deutschland, österreich und<br />
der Schweiz bieten wir unseren Kunden herstellerübergreifend ein lückenloses Angebot<br />
rund um It-Infrastruktur und It-Betrieb aus einer hand.<br />
1952 – 1961 1962 – 1974 1975 – 1993 1994 – 1998 1999 – 2005 2006 – 2010 Software Anhang<br />
305
306<br />
Ein ganz herzlicher Dank gilt auch den Sponsoren dieses <strong>IBM</strong> <strong>System</strong> <strong>Storage</strong><br />
<strong>Kompendium</strong>s, welche die Druckauflage unterstützt haben:<br />
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<br />
Anhang<br />
307
308<br />
Ein ganz herzlicher Dank gilt auch den Sponsoren dieses <strong>IBM</strong> <strong>System</strong> <strong>Storage</strong><br />
<strong>Kompendium</strong>s, welche die Druckauflage unterstützt haben:<br />
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<br />
Anhang<br />
309
310<br />
Ein ganz herzlicher Dank gilt auch den Sponsoren dieses <strong>IBM</strong> <strong>System</strong> <strong>Storage</strong><br />
<strong>Kompendium</strong>s, welche die Druckauflage unterstützt haben:<br />
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<br />
Anhang<br />
311
312<br />
Ein ganz herzlicher Dank gilt auch den Sponsoren dieses <strong>IBM</strong> <strong>System</strong> <strong>Storage</strong><br />
<strong>Kompendium</strong>s, welche die Druckauflage unterstützt haben:<br />
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<br />
Anhang<br />
313
314<br />
Ein ganz herzlicher Dank gilt auch den Sponsoren dieses <strong>IBM</strong> <strong>System</strong> <strong>Storage</strong><br />
<strong>Kompendium</strong>s, welche die Druckauflage unterstützt haben:<br />
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<br />
Anhang<br />
315
316<br />
Ein ganz herzlicher Dank gilt auch den Sponsoren dieses <strong>IBM</strong> <strong>System</strong> <strong>Storage</strong><br />
<strong>Kompendium</strong>s, welche die Druckauflage unterstützt haben:<br />
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<br />
Anhang<br />
317
318<br />
Ein ganz herzlicher Dank gilt auch den Sponsoren dieses <strong>IBM</strong> <strong>System</strong> <strong>Storage</strong><br />
<strong>Kompendium</strong>s, welche die Druckauflage unterstützt haben:<br />
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<br />
Anhang<br />
319
<strong>IBM</strong> Deutschland GmbH<br />
<strong>IBM</strong>-Allee 1<br />
71139 Ehningen<br />
ibm.com/de<br />
<strong>IBM</strong> Österreich<br />
Obere Donaustraße 95<br />
1020 Wien<br />
ibm.com/at<br />
<strong>IBM</strong> Schweiz<br />
Vulkanstrasse 106<br />
8010 Zürich<br />
ibm.com/ch<br />
Die <strong>IBM</strong> Homepage finden Sie unter:<br />
ibm.com<br />
<strong>IBM</strong>, das <strong>IBM</strong> Logo und ibm.com sind eingetragene<br />
Marken der <strong>IBM</strong> Corporation.<br />
Weitere Unternehmens-, Produkt- oder Servicenamen<br />
können Marken anderer Hersteller sein.<br />
Java und alle Java-basierenden Marken und<br />
Logos sind Marken von Sun Microsystems, Inc. in<br />
den USA und/oder anderen Ländern.<br />
Microsoft, Windows, Windows NT und das Windows-Logo<br />
sind Marken der Microsoft Corporation<br />
in den USA und/oder anderen Ländern.<br />
Intel, Intel logo, Intel Inside, Intel Inside logo, Intel<br />
Centrino, Intel Centrino logo, Celeron, Intel Xeon,<br />
Intel SpeedStep, Itanium, and Pentium sind Marken<br />
der Intel Corporation in den USA und/oder<br />
anderen Ländern.<br />
UNIX ist eine eingetragene Marke von The Open<br />
Group in den USA und anderen Ländern.<br />
Linux ist eine Marke von Linus Torvalds in den<br />
USA und/oder anderen Ländern.<br />
Gedruckt in Deutschland.<br />
© Copyright <strong>IBM</strong> Corporation 2010<br />
Alle Rechte vorbehalten.<br />
€ 49,90 – unverbindliche Preisempfehlung