Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

31.01.1986

Konzepte und Beispiele paralleler Rechnerarchitekturen (Xl):Schnelle Transaktionen mit Requestoren und Servern

Spricht man heute von Parallel-Processing, so taucht spontan die Vision von komplizierten Netzstrukturen mit vielen Hunderten, ja Tausenden kleiner Prozessoren auf. Doch so sehr diese Ideen Wissenschaftler und Techniker begeistern und faszinieren - parallele Systeme für die kaufmännische Datenverarbeitung können auch ganz anders konzipiert werden.

Darauf weist mit Nachdruck Harald Sammer hin, der beim US-Computerkonzern Tandem in Frankfurt das "Studio für Höchstgeschwindigkeitsanwendungen" leitet. Er findet, man sollte, anhand von Zahlenspielen, doch auch einmal über Systeme reden, wie man sie etwa in der Fluglinien-Platzreservierung benötigt. Dort geht es darum, große Mengen von Terminals laufend auf große Datenbestände zugreifen zu lassen und dabei relativ komplizierte Transaktionen abzuwickeln. Der Ansatz, den Sammer in in einer Studie wählt, betrifft ein Parallelrechner-System, das jede Sekunde 1000 Transaktionen verarbeiten soll. Dabei geht er "von vollwertigen Geschäftstransaktionen" aus, nicht etwa nur von einzelnen logischen oder gar bloß physischen Plattenzugriffen. Er kommentiert: So eine Leistung stehe "heute noch außerhalb des allgemeinen Stands der Technik".

Beachtliche Forderung

Als Modelltransaktion für seine Berechnungen, und dabei könnte man wohl an den typischen Geschäftsvorfall an einem Bankschalter denken, definiert Sammer nun folgendes Geschehen: 100 Zeichen Eingabevolumen, 200 Zeichen Ausgabe Volumen, 100 000 Instruktionen an computerinterner Verarbeitung und "5 Magnetplattenzugriffe auf die Datenbank mit zusammen 20 KB Datenfluß" von der oder zur Platte, wobei aus denen dann letztlich an relevanter Information "2 KB extrahiert werden". Und Sammer fordert von seinem Parallelsystem, es solle doch nun bitteschön jede Sekunde 1000 dieser Transaktionen abwickeln. Was ja allein schon von Plattenzugriffen her eine beachtliche Forderung ist. . .

Der Mann von Tandem rechnet nun vor, wie das skizzierte System auszulegen wäre. Er stellt fest, daß die Ein- und Ausgabe "auf der Kommunikationsseite" auf 300 KB pro Sekunde kommt, nämlich auf (100 + 200) x 1000 Byte, und daß man dabei "2000 Messages pro Sekunde" zählt.

Diese Last, so Sammer weiter, "muß auf das Prozessorsystem gegeben werden, das ja nun 1000x100 000 Instruktionen pro Sekunde, also 100 Mips, bewältigen muß. Und weil die Wartezeiten bei einem zu mehr als etwa 80 Prozent ausgelasteten System sehr stark in die Höhe sehen, sei es vorsichtshalber korrekt, mit einem nur zu 70 Prozent ausgelasteten System zu rechnen. Was wiederum bedeutet: Sollen, bei 70 Prozent Auslastung, 100 Mips geleistet werden, so ist der ganze Computer auf etwa 140 Mips auszulegen.

Gut, aber ist die Zahl von 100 000 Instruktionen pro Transaktion denn überhaupt realistisch? Der Parallelrechner-Fachmann meint "ja" und verweist dazu auf einige Beispiele: Bei spezialisierten und "extrem ausgeknautschten Systemen" wie etwa dem Airline Control Program (ACP) könne man mit 20 000 Instruktionen pro Transaktion und mit knapp mehr als 90 Prozent Auslastung rechnen; bei generelleren IMS (Information Management Systemen) aber rechnet man mit 250 000 Instruktionen pro Anfrage. Und wenn auch die IMS-Variante "Fastpass" mit nur 100 000 Instruktionen arbeite sowie mit etwa 60 bis 70 Prozent Auslastungsfaktor, so brauche ein DB2-Befehl - immer laut Sammer - doch sogar 750 000 Instruktionen. Und er findet mithin, seine Rechnung mit 100 000 Instruktionen und 70 Prozent Auslastung sei "durchaus konservativ " . . .

Nun zu den Plattenzugriffen. Hier kommt Sammer auf eine Bandbreite von 1000x20 KByte gleich 20 MB pro Sekunde bei 5000 Ein- und Ausgaben je Sekunde.

Nun sollen all diese Dinge aber nicht von einem Prozessor allein erledigt werden, sondern von einer größeren Zahl, beispielsweise 100, rechnet Sammer weiter. Kalkuliere man mit dieser Zahl, dann komme man auf an sich ganz verknüpfte Größenordnungen von etwa - pro Prozessor gerechnet - 10 Transaktionen pro Sekunde, 1,4 Mips Nennleistung und 50 Plattenzugriffen pro Sekunde. Doch leider müssen bei so einem Parallelrechner-System nun noch "die Anforderungen untereinander ausgetauscht werden", was zum bekannten Problem des sogenannten "Querverkehrs" führe. Denn der trete ja immer dann auf, wenn Prozessor A eine Anfrage erhalte, die sich auf Daten beziehe, die "an Prozessor B hängen".

Es sind nun in der Theorie mehrere Möglichkeiten vorstellbar, wie dieser Querverkehr bewältigt werden kann. So sei es beispielsweise möglich, meint Sammer, die Systeme eingangsseitig zu vernetzen. Doch dann müßte man eigens wieder besondere Front-end-Prozessoren vorsehen, denn bei so einer Art von Vernetzung müsse ja irgendwie "schon eingangs erkannt werden, wohin die Anfrage zielt". Und außerdem seien bei derart vernetzten Systemen "gemischte Transaktionen nicht möglich"; darunter versteht Sammer die typische Anfrage, die sich eben nicht lupenrein auf eine einzige Datei bezieht, sondern ihre Erfüllung erst in mehreren Dateien findet.

Verknüpfung hinter den Rechnern

Gerade diese "echten" Anfragen, meint Sammer, also jene, bei denen beispielsweise "Hotel plus Flug Ferientermin" herangezogen werden müssen, seien nun "mit Front-end-Verteilung problematisch". Und er rechnet kurz noch vor, daß das Bindeglied, also der Bus, beim Systemverbund auf der Ein/Ausgang-Seite eine Bandbreite haben müßte, die "den gesamten Ein/Ausgabe-Verkehr als Querverkehr verschicken kann". Also 300 KB pro Sekunde.

Sammer findet nun aber, es sei doch gar nicht nötig, Front-end-Prozessoren einzusetzen und die Systeme eingangsseitig zu verknüpfen, denn man könne, alternativ, ja auch "hinter den Rechnern", also im Bereich der Plattenzugriffe, eine Systemverknüpfung vorsehen. Und er rechnet aus, daß man in so einem Falle, bezogen auf das hier zur Debatte stehende Exempel mit 1000 mal 2 KB Nutzdaten, mit einer "Querverbindungskapazität" von 2 MB auskommen müßte. Also mit einer durchaus noch tragbaren Größe.

Geht man gedanklich nun noch einen Schritt weiter, so kommt man auf die Idee, in ein und demselben System einfach gleich beide Verknüpfungsarten nebeneinander einzusetzen und diese beiden Verbindungen, einschließlich gewisser zusätzlicher Kommunikationswege, dann "zur echten Busstruktur" zu verschmelzen. Dabei reiche dann ein Bus von etwas mehr als 2,3 MB pro Sekunde Transferrate rein rechnerisch aus, "beliebigen Querverkehr an beliebiger Stelle für 1000 Transaktionen pro Sekunde" zu bedienen.

Diese Konzeption biete nun noch einen ganz besonderen Vorteil, spinnt Sammer den Faden weiter. Und zwar den, daß man "die Software, die die Transaktionen bearbeitet, beliebig modular" aufbauen könne. Es sei also möglich, statt mit einem "monolithischen Bearbeitungs- und Verteilprogramm" mit einer Lösung zu operieren, bei der die Aufgabenstellung nun von einzelnen. "Requestoren" und "Servern" bewältigt werde. Also von einzelnen Softwaremodulen.

Diese Requestoren und Server - das Thema kann hier leider nur knapp gestreift werden - können laut Sammer "in beliebiger Zeit" auftreten, wobei man sie, in Parallelrechnersystemen, aber "typischerweise in Form von identischen Kopien in den einzelnen Rechnern, und dort auch wieder jeweils zu mehreren" vorsieht. Eine typische, praxisbewährte Zahl seien etwa fünf Requestoren pro CPU sowie eine gewisse Zahl von Servern. Sammer: Es gibt praktische Fälle in Europa, in denen bis zu 2000 Server in einem System mit zirka 30 parallelen Rechnern laufen.

Wie Untersuchungen gezeigt haben, ist die Lastverteilung bei "vielen modularen Servern viel leichter" zu bewerkstelligen als bei den wenigen großen, und man habe gelernt, meint Sammer, daß "etwa 50 Server pro CPU ein guter Wert" seien. Außerdem sei bei solchen Berechnungen im Auge zu behalten, daß "die Zahl der Server ja auch das erwartete Antwortverhalten" bestimme, meint Sammer, denn soll ein Server bei einem mit 1000 Transaktionen pro Sekunde belasteten System nach, beispielsweise, zwei Sekunden wieder zur Verfügung stehen, so benötige man eben insgesamt 500 Server.

Bei der Diskussion über diese Requestoren und Server darf übrigens ein wichtiger Aspekt nicht aus den Augen verloren werden. Und zwar der, daß man nur die Server frei im System verteilen könne, meint Sammer, mitnichten aber die Requestoren. Denn jene haben natürlich da präsent zu sein, wo die Anforderungen der Benutzer einlaufen, wo also konkret die Leitungen zu den Terminals angeschlossen sind.

Und außerdem ist vielleicht noch interessant, daß es, nach Sammers Beobachtungen, keinen rechten Sinn ergibt, die "Modularität zu hoch" zu wählen, denn das bewirke dann wiederum eine schlechte Ausnutzung des Zentralspeichers. Und fernerhin, aber weiter sollen diese Details hier nun wirklich nicht mehr diskutiert werden, steige bei einem zu hohen Maß an Modularität auch noch die Zeit, die man zum Hochfahren des Systems benötige, deutlich an.

Zwei Verknüpfungsarten nebeneinander

Verlassen wir nun an dieser Stelle das Thema Software wieder und kehren wir zurück zu Sammers Konzept des gemeinsamen, die "Vorder"- wie die "Rück"-Seite der CPU umgreifeden und verbindenden Busse vor wie errechnet, mindestens 2,3 MB pro Sekunde Übertragungskapazität. So etwas zu realisieren scheint keinerlei Problem zu sein, gibt es doch Parallelrechner, die, wie der Fachmann hervorhebt, innerhalb jeweils eines sogenannten Knotens Bus-Verbindungen von 26 MB pro Sekunde und von Knoten zu Knoten Lichtwellenleiterstrecken von immerhin noch 15 MB pro Sekunde Datenrate aufweisen. Also glatt mehr als das Sechsfache der im Beispiel geforderten Leistung. Wobei diese Glasfasern übrigens in einer Ringtopologie von Knoten zu Knoten jeweils bis zu einem Kilometer überspannen können.

Nicht nur theoretisch können Rechner im Transaktionsbetrieb parallel eingesetzt werden, auch in der Praxis scheinen sie sich zu bewähren, wie ein von Sammer speziell a...gewähltes Beispiel belegen soll. Und zwar geht es dabei um einen Fall, wo man aus "40 typischen Bank-Transaktionen" fünf kennzeichnende ausgewählt hat - Geldeinlage beziehungsweise -abhebung, Überweisung, Geldausgabe am Automaten und eine komplexere "Point-of-Sale-Transaktion", bei der noch einige zusätzliche Teil-Transaktionen anfallen; etwa die Abfrage der Stammdaten sowie des Kontostands des Kunden.

In diesem Beispiel soll ein kleineres Parallelsystem mit vier Prozessoren und acht Platten als "Modul" angesehen werden und dieses Modul nun wird mehrfach eingesetzt, untereinander werden diese Module über Flachband- oder auch Glasfaserkabel gekoppelt.

Nachrichtenorientierte BS-Software

Laut Sammer kann man an diesem Beispiel nun demonstrieren, daß selbst die - für Rechnerkopplungen ja "relativ langsame" Glasfaser mit ihrer Transferrate von 15 MB pro Sekunde keinerlei Engpaß bildet, denn das werde eben durch die "nachrichtenorientierte" Betriebssystem-Software verhindert. Und man könne an diesem Beispiel auch die Beobachtung machen, daß, so hätten "echt gemessene Tests" gezeigt, der Leistungsausbau (bei einer gleichbleibenden Antwortzeit von etwa acht Zehntelsekunden) sehr linear erfolge.

So erzielen vier CPUs einen Durchsatz von 16,34 Transaktionen pro Sekunde, acht erreichen 32,07, ein Dutzend CPUs bringt es auf 47,33 und 16 CPUs schließlich leisten 62,51 Transaktionen pro Sekunde. Rechnet man diese Daten nun auf die pro CPU geleisteten Transaktionen um, so ergibt sich, daß in der Vierer-Gruppe jede CPU 4,09 Transaktionen pro Sekunde leistet, in der Achter-Gruppe jede 4,01, im Zwölfer-Verbund jede ...4 und im 16er-Cluster dann jede immerhin noch 3,91 Transaktionen pro Sekunde.

Das heißt, auch in der Kopplung von 16 CPUs leistet jede einzelne CPU immer noch mehr als 95 Prozent dessen an Transaktionen, was man im kleinen Vierer-Block von ihr gewohnt ist . . .

Es scheint also - zumindest, wenn man den hier angegebenen Zahlen folgt - doch an der Idee einiges dran zu sein, Parallelrechner auch im kaufmännisch-administrativen Bereich ins Auge zu fassen. Zumal ja hier noch ein weiterer Aspekt hinzukommt, der bisher nicht weiter erwähnt wurde: Die parallelen Rechner lassen sich schön modular dem steigenden Arbeitsanfall anpassen, und da sie bei Defekten quasi füreinander einspringen können, ist auch das Ziel der Fehlertoleranz als durchaus erreichbar einzuschätzen.

Was tut ein Server eigentlich? Zum etwas besseren Verständnis des Konzepts der Requestoren und der mit ihnen kooperierenden Server sei hier knapp einmal dargestellt, was typische, beim Abarbeiten einer Anwendung vorkommende und den Requestoren und den Servern übertragene Teilaufgaben sind.

Da wäre beispielsweise der Request "Lies Konten-Satz" zu nennen, woraufhin der Requestor vom Server eben diese gewünschten Daten übermittelt bekommt. Eine andere Anforderung kann lauten "Schreib den geänderten Konten-Satz zurück in den Speicher"; hier erhält der Requestor dann vom Server eine einfache Vollzugsmeldung, nach deren Einlaufen er in seiner Arbeit weiterfahren kann.

Quer-Kommunikation auf logischem Bus

Andere Requests wiederum können zum Beispiel das Aktualisieren der Log-Datei zum Inhalt haben oder auch die Ausgabe einer Antwort an einen Benutzer am Bildschirm; und auch diese beiden Anforderungen müssen dem Requestor dann jeweils mit einer Vollzugsmeldung quittiert, also als "ausgeführt" bestätigt werden, ehe er in seinem Programm weiterfährt.

Da hier die Kommunikation zwischen Requestoren und Servern angesprochen ist, sei an dieser Stelle kurz noch erwähnt, daß zu den im Haupttext erwähnten, beiden logischen Bussen noch ein dritter tritt der der Quer-Kommunikation zwischen Requestoren und Servern dient und der laut Sammer eine Bandbreite von 160 KB pro Sekunde aufweist. Doch auch dieser Bus ist nur "logisch" von den beiden anderen getrennt; in der realen Implementierung ist es stets nur ein und derselbe Bus, der alle Rechner miteinander koppelt und über den der gesamte Verkehr der drei scheinbar getrennten Busse abgewickelt wird.

An dieser Stelle könnte vielleicht die Frage auftauchen, ob ein Mehrrechnersystem mit einem Bus der hier zur Debatte stehenden hohen Bandbreite nicht eine letztlich recht teure Lösung darstelle und ob man nicht doch besser auf hochgezüchtete Mono-Prozessoren setzen sollte? - Doch solchen Einwänden könne man, meint Sammer, entgegenhalten, daß die einzelnen Einheiten des Mehrrechnersystems ja nun nicht aus teurer, hochgezüchteter und nur in vergleichsweise kleiner Stückzahl gefertigter Hardware bestehen, sondern aus Komponenten, die kostengünstige Serienprodukte sind. Und das sei unterm Strich wohl vorteilhafter. Was allerdings noch zu beweisen wäre . . .