Die Halbleiterplatte (SSD) ist in stark transaktionsorientierten Anwendungen fester Bestandteil im RZ-Betrieb geworden. Als Spezialist für den kritischen Performancebereich hat dieses Produkt "seinen" Platz in der Speicherhierarchie erobert. Allerdings sind inzwischen fast acht Jahre vergangen, bis aus dem "Exoten" eine Selbstverständlichkeit wurde. Dazu beigetragen hat neben den Sprüngen im Preis-Leistungs-Gefüge der Chipwelt sicherlich auch die Verfügbarkeit solcher Geräte aufgrund der heutigen Produktreife.

Untersuchungen aus dem letzten Jahr zeigen eine entsprechende Klassifizierung des Marktes von Online-Speichern.

Während hier bereits 0,5 Prozent nach Einsatz von Halbleiterplatten verlangen, lassen sich auch in den anderen beiden Performance-Bereichen, durch den Einsatz von SSD, erhebliche Erleichterungen erzielen.

Dies erklärte auch die enorm anwachsende Zahl an weltweiten Installationen und das Antreten der japanischen Hersteller (in erster Linie Hitachi). Es gilt allerdings als sicher, daß der Anteil fernöstlicher Produkte außerhalb Japans deutlich unter zehn Prozent liegt.

Bereits im Herbst 1978 erfolgte die erste Ankündigung der Halbleiterplatte und wenige Monate später die Auslieferung. Ermuntert wurde die Entwicklung durch damalige Performance-Probleme im Paging-Bereich. Virtuelle Adressierung, seit den frühen 70er Jahren im Einsatz, mußte zunehmend mit den begrenzten und sehr teuren Trommeln (2305) unterstützt werden. Gleichzeitig mit der Produkteinführung stand erstmalig auch Dual Port zur Verfügung - heute der Industriestandard! Der damaligen Technologie entsprechend waren die ersten Produkte aus Charge-Coupled Device Chips (CCD) aufgebaut, die jedoch sehr bald durch 16KBit-Chips (1980) ersetzt wurden. Neben Kapazitätserweiterungen kam Data Streaming hinzu und ab 1982 bereits der Sprung auf 64-KBit-Chips. Notwendig wurde dies durch die Nachfrage nach mehr Adressen und ermöglicht durch den einsetzenden Chip-Preisverfall. Nächste Schritte waren die Einführung von 3380-Image-Emulation und DOS-Unterstützung (1984). Mit der Verfügbarkeit von 4-Kanal-Schaltern und der Verwendung von 256-KBit-Chips wurde die vorläufig letzte Runde eingeläutet. Somit beträgt die derzeit größte Speicherkapazität 768 MB per Subsystem.

Bemerkenswert ist seit der 3380-Emulation die Möglichkeit, nun auch Applikationen mit SSD zu unterstützen. Man denke hier an CICS; Datenbanken, CAD/CAM, aber auch Kontroll-/Steuerungseinrichtungen wie RACF oder Lockfile. Erfahrungen mit nahezu 1700 Installationen bestätigen denn auch voll diesen Trend. Das bedeutet nun keineswegs einen Rückzug vom Paging. Im Gegenteil, neue Ankündigungen wie VM/HPO (Swap und Page) oder DOS VSE/SP (40 MB) lassen bei diesen Betriebssystemen eine Wiederkehr von Gegebenheiten aus dem MVS-Bereich erahnen.

Datenverfügbarkeit ist wichtige Komponente

Die umfangreichen Untersuchungen zum Antwortzeitverhalten von A. Thadhani (IBM, 1981) sind inzwischen sehr bekannt geworden (siehe auch CW Nr. 32/86), und was wesentlich ist: Man hat die daraus erhaltenen Resultate als fundamental akzeptiert. Die Frage lautet damit, was kann man tun, um diese auch umzusetzen? Eine bedeutsame Komponente in unserer online-/transaktionsorientierten Zeit ist dabei sicherlich die Datenverfügbarkeit und die periphere Verwaltung. Hier lassen sich zwei Leitlinien vorgeben:

þSobald sich Produkte und Mechanismen in einer Organisation etabliert haben, erwartet man natürlich einwandfreies Funktionieren und möglichst permanente Verfügbarkeit. Ab einem bestimmten Zeitpunkt verliert aber die ausschließliche Orientierung am Maximum einzelner Hardware-Ressourcen an Gewicht. Unter Beibehalten dieser Zielverfolgung stellt sich zunehmend die Frage nach Integration der Produkte unter dem Gesichtspunkt des Gesamtverhaltens eines Systems und dem daraus resultierenden Nutzen für den Anwender - die Produktivität "draußen".

þDie Komplexität im Speicherbereich erlaubt nicht mehr, nur schlechthin an "eine Platte" zu denken. Inzwischen gibt es mit der Halbleiterplatte oder dem Cache-Controller genügend Varianten, die für spezielle Anwendungen konzipiert und dementsprechend technologisch realisiert wurden. Diese Produkte müssen heute in die Hardware-Planung miteinbezogen werden.

Man verlangt eben nach vernünftig kurzen Device-Service-Zeiten, konstanten Antwortzeiten und konsistentem Datenfluß. Bereits 200 Datenbanknutzer, 20 Applikationsentwickler und das dazugehörende Equipment kosten ein Vielfaches der Hardware-lnvestitionen. Allein durch zehn bis fünfzehn Prozent Produktivitätssteigerung amortisiert sich ein solches High-performance-Produkt in kurzer Zeit. Dabei spielen nicht nur materielle Werte eine Rolle; auch Zufriedenheit oder Image des Unternehmens und rasches Abwickeln von Aufträgen sind zu bewerten.

Natürlich beginnen dabei die Überlegungen, bedingt durch den hierarchischen Aufbau unten an der Basis, im System. Es macht eben einen Unterschied, ob für CICS der Pagedemand in 18 bis 20 Millisekunden oder zwei bis drei Millisekunden aufgelöst wird. Andere Komponenten, so zum Beispiel das Netzwerk, bleiben in diesem Zusammenhang unberücksichtigt.

Worin liegt nun die Problematik begründet?

Verschiedene Untersuchungen haben im Durchschnitt folgenden CPU-Ablauf aufgezeigt:

- 10 bis 15 Prozent wird mit Verarbeitung der Daten verbracht;

- 60 Prozent sind für Datentransport nötig;

- 30 bis 35 Prozent verpuffen im Wartezustand.

Beachtlicher Teil im klassischen Bottleneck

Selbst wenn ein gewisser Anteil dabei auf Systemoverhead und Synchronisation (wie Dispatcher) zurückzuführen ist, verbleibt doch ein beachtlicher Faktor - und damit Performance-Probleme - im Bereich Datenbewegung und klassischer I/O-Bottlenecks.

Dabei muß man gleichzeitig daran denken, daß sich der Standard-l/O-Vorgang kaum verändert hat. Sicherlich gab/gibt es da den Offline-Seek und Set-Sector sowie das RPS-Konzept (Rotational Position Sensing) zum Multiplexen auf einem Kanal, auch Dual Port, Floating Channels und Cache-Speicher. Doch wenn der Kanal zu stark belastet wird, steigt eben die Wahrscheinlichkeit für Contention beim Reconnect, und schon sind weitere 16,6 Millisekunden zu addieren. Ähnliches gilt, wenn die Daten nicht im Cachespeicher stehen. Softwareseitig wurden ergänzende Maßnahmen ergriffen, um diese mechanischen Engpäße selektiv zu umgehen: BLDL, Indexed VTOC, ausgefeilte Zugriffsmethoden (zum Beispiel Seldom Ending Channel Program, Geräteklassifizierung oder optimierender Zugriff). Letztlich auch Extended-Storage als Systemlösung und Ersatz für 3880-21. Dies stellt nur einen kleinen Auszug dar.

Dennoch sind zunehmend Tuning-Maßnahmen und seltene Spezialisten notwendig, um alles in Griff zu bekommen. Einerseits ist die Datenverarbeitung zu beachten, denn dominante Zugriffsarme stauen den Verkehr im Strang auf, Queues werden gebildet. Andererseits wächst die Kapazität beständig an - derzeit 60 bis 100 Prozent pro Jahr in großen Shops. Es ist also nicht verwunderlich, daß man ab und zu schon das Wort "Quad-Density" hört. Aber die Problemlösung Datenmenge/Stellflächeneinheit kümmert sich natürlich nicht um tag-/nachtaktive Dateien, Batch- beziehungsweise Online- oder interaktive Orientierung und High-performance-Data-Sets. Also kurze Stränge, teilweise belegte Volumen (was legt man hinter ein Page-Data-Set?) und CPU-Auslastung bei 70 bis 80 Prozent als Daumenregel? Eine Lösung, jedoch eine verschwenderische.

Selbstverständlich ist die obige Zusammenfassung immer wieder individuell zu sehen. Für manche Installationen kein Thema, sprechen viele von nichts anderem. Nur, die Problematik ist latent vorhanden und wird bei aller Weiterentwicklung zunehmen. Man denke an die wachsende CPU-Leistung, derzeit zirka 80 Mips bei einigen Prozessoren. Und Mips zieht GBs nach sich (alte Regel: 1 Mips = drei bis vier GB mit Tendenz zu sechs GB), auch wenn ein Teil der neuen Leistung für "schnelleren" Overhead verwendet wird. Auf der anderen Seite absorbieren Plattensubsysteme derzeit in der Regel 90 bis 120 I/Os, mit XA und Cache noch 20 bis 40 Prozent mehr. Balanced Systems ist daher eine der Spezialwissenschaften. Zunehmend erkannt wird aber auch, daß das Konzept der Speicherhierarchie einen dynamischen Teil von Balanced-Systems darstellt. Es handelt sich letztlich um die Erkenntnis, daß man mit dem derzeit erreichten Stand der Technik leben muß.

Doch man hat die Möglichkeit, sich für spezielle Anwendungen oder eingegrenzte Problemfälle wie Paging/ Swapping und ganz besonders in der Mehr-CPU-Umgebung (Reserve/Release) die jeweils passenden Geräte-Varianten auszusuchen.

Um es nochmals zu verdeutlichen: Der gravierende Vorteil einer Halbleiterplatte ist im Einsatz für peripheriekritische Anwendungen zu sehen. Durch den Wegfall sämtlicher Mechanik verschwinden die vorher angesprochenen Probleme. Natürlich werden die Abläufe auf dem Kanal (CCW-Ketten) und die Steuerung durch IOS wie bisher unverändert gehandhabt, doch durch die Schnelligkeit des Gerätes werden Anforderungen komplett und seriell abgearbeitet. Damit entfällt das Zerlegen in Positionieren, Lokalisieren und Datentransport, insbesondere wird der Channel wesentlich weniger belastet/unterbrochen (man denke an Search, Channel-Queuing, Device End/Channel End etc.).

Ein kurzer Überblick soll die Flexibilität hinsichtlich der Einsatzmöglichkeiten aufzeigen.

Im Systembereich sei an erster Stelle das klassische Paging erwähnt. Mit einer Pagetransferzeit von rund 1,7 Millisekunden bei Channel-Lasten von bis zu 85 Prozent lassen sich mit Dual-Port erstmalig I/O-Raten von fast 1000 "rechnen". In Realität dürfte (je nach Konfiguration) ein guter Wert für Pagetransfer bei drei bis fünf Millisekunden liegen, ein nennenswertes Queueing setzt ab zirka 70 Prozent Channel-Last ein.

Ähnliche Überlegungen gelten für Swapping, wobei hier über die Swap-Sets hochgerechnet werden kann, und neuerdings sind diese Betrachtungen auch auf VM/HPO und zum Teil auf VSE/SP zu übertragen. Damit deckt man auch Komponenten wie TSO oder CMS ab.

Neben IMS und CICS auch CAD/CAM-Systeme bedanken

Im Mehrsystembereich (Multi-CPU, Multi-SCP) lassen sich sehr interessante Leistungen beim Einsatz von Lockfiles, Labelareas, Power-Queue Files, RACF, SDSI und Kataloge erzielen. Gemeinsam ist hier der serielle Zugriff aller (Datenkonsistenz, Systemsteuerung), wobei gerade bei Reserve/Release-Mechanismen kurze Device-Service-Zeiten wichtig sind. Hier bietet sich zudem ein Dedizieren von Pfad und Volume (physikalische Zuordnung eines Moduls zum Storage-Director) an.

Die nächste Ebene wäre mit Bibliotheken, SPF, Clists und Sort-/Compile-Workbereichen angesprochen. Auch S- und Y-Disks können miteinbezogen werden.

Bei den applikationsorientierten Systemen sind neben IMS, Cics, DB2 oder Adabas mit ihren Indices, Assoziatoren, MFS-/ACB-Libs etc. vor allem CAD/CAM-Systeme zu bedenken. Mit einer Struktur, die zum Beispiel Cics ähnlich ist (Adreßraum-Queueing), sind auch hier wieder Page-Anforderungen, Roll-Files und Programmbibliotheken optimal mit einer Halbleiterplatte bedient.

Absorbieren von großen Paging-Lasten

Neben Performance-Engpässen, wie oben angesprochen, gibt es natürlich noch andere Beweggründe. Da wurde bereits die mögliche Channel-Last von zirka 80 Prozent angesprochen. Bevor eine zweite Kanalgruppe in einem eventuell älteren Modell diskutiert wird, sollte der Einsatz einer SSD ernsthaft überlegt werden. Ein dedizierter Kanal kann viel bewirken. Genauso wird das Absorbieren von großen Paging-Lasten eine Überbrückung in Zeiten von CPU-Modell-/Familienwechsel rechnerisch ebenso interessant machen wie der Gesichtspunkt, nicht einer der Ersten zu sein (Umstellungsaufwand/-erfahrung). Weiterhin kann auch Expanded-Storage IBM 3090) erwähnt werden, beispielsweise der Unterschied in der Einsatzflexibilität (Größe und Ausbau, Paging plus CICS, VM versus MVS/XA, Unabhängigkeit von CPU-Typ). So könnte überzogen ein DOS/VSE/SP-Anwender seinen Halbleiterspeicher mit Lockfile etc. auch nach dem Umstieg auf MVS/XA für Paging weiternutzen und zudem CAD/CAM zuordnen.

Anschließend eine Betrachtung zur Speichergröße. Ein Schnellspeicher soll hohe Performance-Leistungen bringen - keine Kapazitäten in GB bereitstellen.

So durften Lockfiles selten über 1 MB hinausgehen. Paging im MVS regelt sich zwischen 40 und 160 MB (wiederum je nach System und OS-Version) ein. Bibliotheken können natürlich variabel sein.

Verschiedene Größen in einem Frame

Doch dem steht eine Ausbaumöglichkeit bis 768 MB (bei übrigens bescheidenen 1,73 Quadratmeter Stellfläche) entgegen, Modulgrößen können zwischen zwölf und 96 MB variieren. Unterschiedliche Modulgrößen lassen sich in einem Frame kombinieren.

Die Vielfältigkeit aller Gesichtspunkte zeigt, daß dem Einsatz einige Gespräche vorausgehen sollten. Dazu muß der Anwender auch seine Erfahrung, Wissen und Probleme und Gegebenheiten mitbringen. Weiterhin ist der Einsatz von Software-Tools (zum Beispiel RMF) hilfreich. Von seiten des Herstellers werden dann einige Erfahrungen aus der Vielzahl seiner Installationen eingebracht und verknüpft mit Werkzeugen wie Simulations-Software-Tools und Methoden: So zum Beispiel zur Berechnung der notwendigen Modulgröße, um das derzeitige Pagen auf einen gewünschten Wert Page/Sekunde oder Page-Zugriffszeiten/Sekunde zu bringen.

Zusätzlicher Abbau von Engpässen

Neben der Optimierung einzelner Subsysteme ergibt sich oftmals als Nebenwirkung ein zusätzlicher Abbau von Engpässen auf den Plattensträngen und eine Gesamtsystemverbesserung. Dies ist einsichtig, da sich durch die Neuverteilung der Datenbewegungen die Kanallasten abbauen und damit auch die Queues. Außerdem wird ein gewisses Dedizieren von Performance und Kapazität erreicht.

Diese Vorteile lassen sich folgendermaßen zusammenfassen:

- Reduktion von Systemantwortzeiten,

- Anschluß zusätzlicher Online-Benutzer,

- bessere Auslastung von Hardware-Komponenten,

- Verbesserung der Produktivität,

- Verringerung der Overhead-Kosten.

Somit wären noch die Kostenverhältnisse zu bedenken. Unter dem Gesichtspunkt, daß die Halbleiterplatte ein Performancegerät darstellt, sollten Kosten auch unter dem Aspekt der I/O-Leistung betrachtet werden. Setzt man die relativen Kosten per I/O bei der Halbleiterplatte (höchste Performance) mit "1" an, so erreichen sie für die Double-density-Platten des Typs 3380 E (höchste Kapazität) den Wert "9".

Diese Relation bezieht sich auf eine vernünftige Konfiguration für den jeweiligen Einsatzschwerpunkt unter üblichen Annahmen (Datenverteilung, I/O-Servicezeiten etc.).

Interessant ist die Tatsache, wie unerwartet rentabel sich die scheinbar teure Halbleiterplatte unter Berücksichtigung der speziellen Leistungsfähigkeit zeigt.

Insgesamt wird nun auch verständlich, warum nur eine vernünftige Kombination aus allen Produktvarianten einen optimalen Preis-Leistungs-Faktor ergeben kann.

Letztlich sollte hier auch noch eine Abgrenzung zur Speichererweiterung (Expanded-Storage) gezogen werden. Dieser Speicher, der ja ausschließlich unter der Zentralsystemverwaltung für Paging zuständig ist, liefert, über den Daumen gepeilt, ein Drittel bis ein Viertel der Speicherkapazität vergleichbarer Halbleiterplatten - dies unter reinen Kostengesichtspunkten, also ohne Beachtung der Einsatzflexibilität (wie "shared" Nutzung und Applikationsorientierung) oder der Transferzeit für Pages.

Ein wichtiger Gesichtspunkt bei allen Produkten bleibt die Kompatibilität. Darunter sollte der Hersteller nicht nur den derzeitigen Funktionsumfang (also Performance-Vorteile an der von IBM jeweils exakt vorgegebenen Schnittstelle) berücksichtigen, oder auch die Fähigkeit besitzen, in Zukunft Architekturerweiterungen oder neue Features problemlos abzudecken; das heißt möglichst durch Austausch einer Diskette. Dies setzt allerdings eine entsprechende Gestaltung im Subsystem voraus, wie Architektur, Größe von Mikroprogrammspeichern, Kenntnisse in Mikroprogrammierung und vor allem umfangreiche Erfahrungen mit der technischen Realisierung von Funktionen.

Nur so kann gewährleistet werden, daß bei den Zugriffsmethoden, bei der Generierung oder im Umgang mit Utilities wie gewohnt gearbeitet werden kann. So sind auch beim Einsatz einer Halbleiterplatte keinerlei Modifikationen am Betriebssystem notwendig.

Bleibt noch die Frage nach der Datensicherheit. Zunächst sollte man bedenken, daß grundsätzlich jeder Speicher Datenverlust erleiden kann. Sei es durch Headcrash, Stromausfall oder auch menschliche Einwirkungen wie versehentliches Drücken von Bedienerknöpfen. Wichtige Daten sollten daher generell in die bestehenden Backup-/Recovery-Prozeduren miteinbezogen werden.

Als nächstes sollte man sich fragen, ob es sinnvoll ist, Daten bei Stromausfall auf einem internen Zwischenträger zu speichern. Für die Zeit des Ausfalls sind diese Daten, da man darauf nicht direkt zugreifen kann, nicht verfügbar.

Im übrigen sind die Daten während der Zeitdauer des Kopierens normalerweise nicht verwendbar. Letztendlich muß die Überlegung mit beinhalten, ob es ausreichend erscheint, daß nur die Speichereinheit (üblicherweise die interne Gleichstromversorgung) abgesichert wird. Eine vernünftige Lösung sollte dem entgegen auch die AC-Versorgung der Storage-Directors in der Control-Unit mitbedenken.

Dies läßt sich allerdings nur erreichen, indem eine UVS-Einheit mit Batterie über das gesamte SSD-Subsystem geschaltet wird. Dadurch können Netzspannungen durch Wandlung in Gleichstrom und anschließend Rückwandlung in Wechselstrom sowohl der SSD als auch der Batterie in gleichbleibender Qualität zugeführt werden. Das eröffnet folgende Möglichkeiten:

- kein Kopieren auf elektromechanischem Zwischenträger,

- Notversorgung des gesamten Subsystems einschließlich Control Unit über die AC-Schnittstelle,

- sofortige Datenverfügbarkeit (Unterbrechungsbeendigung),

- geregelte Netzspannungen und Frequenzen,

- Abfangen von überlagerten Störungen (Impulse etc.), Netzrückschaltungseinrichtung,

- integrierte Handumgehung (zum Beispiel für Service).

Zum Abschluß sei allerdings erwähnt, daß nahezu alle Installationen ohne Batterie/UVS betrieben werden.