Symmetrische Multiprozessor-Systeme sind im kommerziellen Bereich asymmetrischen überlegen, meint Thomas Woywod. Im folgenden Beitrag stellt er die unterschiedliche Arbeitsweise der beiden Architekturen, zum Beispiel bei Datenbankanwendungen, gegenüber. Ferner beschreibt der Fachmann die Entwicklung von Unix System V bis hin zum Betriebssystem für symmetrisches Multiprocessing.
"Mainframe meets Mikro - and gets eaten alive" - mit dieser Uberschrift veröffentlichte das Marktforschungsunternehmen IDC bereits 1987 einen Bericht über das unbekannte und unerschlossene Potential von Mikroprozessoren. Darin heißt es: "Die wichtigste Auswirkung der Mikroprozessoren auf die Computerindustrie ist bisher verborgen geblieben. Wie die 90 Prozent des unter der Wasseroberfläche liegenden Eisberges wird auch der bisher unentdeckte Teil der Mikroprozessor-Revolution für den Titanic-gleichen Untergang der Mainframes sorgen." Zu diesem noch unbekannten Bereich zählen laut IDC die Multiprozessor-Systeme.
Dabei analysierte die Gartner Group bereits ein Jahr zuvor, im März 1986, deren Entwicklung: " Bis 1990 wird sich der Markt für Multiuser-Systeme in nahezu allen Produktkategorien auf Multiprozessor-Systeme umgestellt haben." Und selbst Gordon Bell sagte im Februar 1986: " Der wichtigste Durchbruch im Computerbereich seit dem Konzept der virtuellen Speicher sind Multiprozessor-Systeme."
Wie aus diesen Zitaten ersichtlich ist, waren bereits Mitte der 80er Jahre die Weichen gestellt, um die letzte und entscheidene Umwälzung im Computermarkt einzuleiten: die Ablösung proprietärer Großrechner-Architekturen durch Computer-systeme, die folgende gemeinsame Merkmale aufweisen:
- Multiprozessor-Architektur,
- Standard-Mikroprozessoren,
- offenes Betriebssystem und
- kanalorientiertes I/O- Subsystem.
Der Begriff Multiprocessing trifft zunächst auf alle Rechner zu, die mehr als einen Prozessor nutzen. Dabei kommen zwei grundsätzlich unterschiedliche Ansätze zum Tragen:
- eng gekoppelte Architekturen (Shared Memory) und
- lose gekoppelte Architekturen (Private Memory).
Bei lose gekoppelten Architekturen handelt es sich um Multiprozessor-Systeme, die typischerweise von acht bis zu mehreren tausend CPUs integrieren. jede Zentraleinheit ist mit einem eigenen Hauptspeicher ausgestattet. Konfigurationen für diese Art von Systemen sind zum Beispiel verteilte Netze, Cluster, Hypercubes, " Butterfly"- Netze oder Connection-Machines. Zu den kommerziell verfügbaren Produkten zählen etwa die Modelle "NCR 32/850" oder" Tandem VLX". Der Nachteil dieser Systeme liegt oftmals darin, daß sie aufgrund der komplexen Verbindungsschemata teuer sind. Außerdem müssen beim Einsatz eines solchen Systems die meisten kommerziellen Anwendungen umgeschrieben werden, um die Vorteile von lose gekoppelten Architekturen zu nutzen. Diese Multiprozessor-Architekturen sind eher als massiv-parallele Systeme im rechenintensiven Anwendungsbereich zu finden, quasi als" Supercomputer".
Wesentlich weiter verbreitet sind inzwischen die eng gekoppelten Architekturen. Solche Systeme integrieren üblicherweise zwei bis 30 Standard-Mikroprozessoren, die sich einen gemeinsam genutzten Hauptspeicher teilen und über einen einzigen Hochgeschwindigkeits-Bus miteinander verbunden sind. Diese Architektur erfordert einen schnellen System-Bus und einen zusätzlichen Cache-Speicher pro CPU, um über intelligente Cache-Algorithmen die Hauptspeicherzugriffe zu begrenzen, was für einen minimierten Verkehr auf dem System-Bus sorgt.
Der Vorteil dieser Architektur liegt zum einen darin, daß preiswerte Standard-Mikroprozessoren zum Einsatz kommen können. Zum anderen werden das Standard-Betriebssystem Unix, relationale Datenbanken (etwa Oracle, Informix, Ask/Ingres, Sybase, Unify, Focus) und kommerzielle Anwendungen unterstützt.
In der Vergangenheit gab es nur Computer mit einem Prozessor, der alle Aufgaben ausgeführt hat. Multiprozessor-Systeme bieten demgegenüber eine Reihe von Vorteilen, wobei die Geschwindigkeitsverbesserung mit zu den sichtbarsten zählt. Im Idealfall kann der Einsatz eines Zwei-Prozessor-Systems die Vorgangszeit eines Monoprozessor-Systems halbieren. In einer Multiuser-Umgebung mit zwei CPUs können, ähnlich idealisiert, doppelt so viele Prozesse gleichzeitig ablaufen.
In der Praxis läßt sich dieses Ergebnis nicht erreichen. Durch das Hinzufügen von CPUs steigt die Leistung des Gesamtsystems fast linear an. Dies setzt jedoch voraus, daß es sich um symmetrische Multiprocessing-Systeme handelt.
Symmetrisches Multiprocessing bedeutet: Alle CPUs können gleichberechtigt jede Aufgabe übernehmen. Im Gegensatz dazu gibt es asymmetrische Multiprozessing-Systeme, bei denen beispielsweise Betriebssystem-Prozesse immer von einer bestimmten CPU ausgeführt werden. Man spricht hier vom Master-Slave-Prinzip.
Als im November 1989 die Quellcodes für Unix System V.4 (SVR4) an die Mitglieder von Unix International (UI) ausgeliefert wurden, war nicht abzusehen, welche Unix-Variante sich künftig in der Industrie durchsetzen würde. Die Open Software Foundation (OSF) stellte ebenfalls zu diesem Zeitpunkt einen ersten Snapshot von OSF/1 vor, der sich aller. dings noch nicht zur Implementierung eignete. Die Grundlage für OSF/1 war zu diesem Zeitpunkt noch AIX von IBM - bedingt durch die Entstehungsgeschichte der OSF. Heute basiert OSF/1 auf einer objektorientiert geschriebenen Version von Unix, auf einem Mach-Kernel.
Der Vorteil von OSF/1 gegenüber Unix V.4 war die von Anfang an geplante Unterstützung für symmetrische Multiprozessor-Architekturen. Schon bald nach Auslieferung durch die Unix System Laboratories (USL), einer Unix-Tochter von AT&T, war jedoch abzusehen, daß sich viele namhafte Unix-Anbieter für System V entscheiden würden. Dazu gehörten auch Unter. nehmen wie Sun, HP, Unisys und Sequent, also Mitglieder der OSF-Vereinigung. UM die Erweiterungen, die auch symmetrisches Multiprocessing umfassen, zeitlich und im Funktionsumfang zu definieren, wurde von allen Ul-Mitgliedern in Zusammenarbeit mit AT&T die System-V-Roadmap entwickelt.
Die Zukunftsplanung für Unix System V
Die Roadmap legt die Funktionserweiterungen für SVR4 für die nächsten Jahre fest. Alle Mitglieder von Ul arbeiten gemeinsam mit Standardisierungsgremien wie X/Open und IEEE daran, dieses Dokument ständig zu aktualisieren. Dies beinhaltet den ersten Schritt eines Prozesses, der auf ein standardisiertes Unix-Betriebssystem zielt, auf das Systemanbieter genauso wie unabhängige Software-Entwickler zurückgreifen können. Auch Anwender werden in ihrer strategischen Planung durch die System-V-Roadmap unterstützt, weil sie die Chance haben, geplante Funktionalitäten und Erweiterungen zu berücksichtigen.
Die UI hat die System-V-Roadmap erstmals 1990 veröffentlicht. Es ist das erste Dokument einer Open-Systems-Organisation, das sich langfristig mit der Entwicklung eines Standard-Betriebssystems befaßt. Die enge Einbeziehung aller Ul-Mitglieder in die Planung von System V garantiert dem Anwender eine breite Verfügbarkeit des Betriebssystems mit allen Erweiterungen auf verschiedenen Hardwareplattformen.
Der Zeitrahmen, in dem die einzelnen Mitglieder von Ul diese Erweiterungen entwickeln sollen, ist genau festgelegt. Dennoch müssen ständig Änderungen vorgenommen werden, weil etwa Systemanbieter Entwicklungen integrieren.
Seit November 1989 haben sich 70 Prozent der Unix-Systemanbieter für System V.4 entschieden oder bieten bereits ein Produkt an, das darauf basiert. Dieses Release vereint die Eigenschaften von System V (bis Release 3.2), Berkeley-Unix (BSD), Sun-OS und Microsoft-Xenix.
Außerdem werden "Application Binary Interfaces" (ABIs) für verschiedene Prozessorfamilien unterstützt und ermöglichen damit den Einsatz von Shrink-wrapped-Software. Der "Window Manager XII.4" ist heute bereits Bestandteil von SVR4. Erweiterungen, die "Lokalisierung l" genannt werden, sind im ersten Quartal 1992 verfügbar. Darunter versteht man, daß alle Utilities und Tools von Unix 8-Bit-fähig gemacht werden. Dann sind länderspezifische Sonderzeichen wie die deutschen Umlaute auch im" vi" editierbar.
Nicht zu verwechseln ist dieser Teil der Lokalisierung mit "Lokalisierung 11" aus "SVR4 ES/MP", die für nächstes Jahr geplant ist. Hier stehen Möglichkeiten zur Verfügung, Dokumentation und Systemmeldungen in einer gewünschten Sprache auszugeben. Das erfordert ein Auslagern der im Unix-Kern als Strings fest programmierten Fehlermeldungen in Tabellen, die dann einfach übersetzt wer den können, ohne länderspezifische Versionen verwalten zu müssen. Anwenderprogramme können ebenfalls auf diese Tabellen zugreifen und den Dialog mit dem Benutzer in einer gewünschten Sprache führen.
Bei der Version SVR4 ES (Enhanced Security) handelt es sich um eine vorübergehende, symmetrische Multiprozessor-Implementierung von SVR4, der ersten Phase zu SVR4 ES/MP. Die Unix-Variante wird von USL in Zusammenarbeit mit dem Intel-Konsortium entwikkelt und soll bis Mitte 1992 fertiggestellt sein. Mit diesem Release werden auch die Sicherheitsanforderungen nach B2, wie sie im Orange Bock des DoD (Department of Defense) definiert sind, erfüllt.
Parallelprogrammierung für das Multiprocessing
SVR4 ES unterstützt jedoch nur bis zu zehn symmetrische Prozessoren. SVR4 ES/MP dagegen wird ein Vielfaches an Prozessoren unterstützen und basiert auf Entwicklungen von Sequent für die symmetrische multiprozessor-Version Dynix/ptx der UNIX-Variante für die Symmetry-2000-Systeme. Diese Plattform hat USL auch als Refenzplattform für SVR4 ES/MP auf Basis der Intel-Prozessoren 386 und 486 ausgewählt. Die Freigabe ist für Mitte 1992 vorgesehen.
Sequent überläßt den USL die Lizenz für die Betriebssystem-Technologie. Damit hat die AT&T-Division Zugang zu allen Schlüsselelementen des Sequent-Betriebssystems, einschließlich der Dateiverwaltung, des 1/0-Subsystems, des Prozeß-und Speicher-Managements und der Parallel-Streams-Möglichkeiten.
Die hardwaretechnische Erweiterung von Monoprozessor-Architekturen zu Multiprozessor-Systemen bedeutet nur einen Teil der erforderlichen Entwicklungsarbeit. Zugleich ist das Prozeß- und Speicher-Verwaltungsmodell für Einzelprozesse an die Parallelarchitektur anzupassen. Im folgenden werden die Erweiterungen des Unix-Prozeß- und -Speicherverwaltungsmodells beschrieben, die Sequent entwickelt hat und die in Unix System V.4 ES/MP einfließen werden.
Obwohl bei oberflächlicher Betrachtung das Konzept der Parallelprogrammierung sehr einfach zu implementieren erscheint, sind einige Details doch ziemlich komplex. Auch Sprachen, die bereits parallele Algorithmen besitzen, wie Ada und Concurrent C, setzen Basismechanismen voraus. Standards existieren in diesem Bereich noch nicht, und Literatur über diesen Themenkomplex gibt es ebenfalls kaum.
In SVR4 ES/MP wird ein Prozeßmodell implementiert, mit dem sich Parallelprogramme auf Shared-Memory-Systemen mit dem Betriebssystem Unix entwickeln und ausführen lassen.
Diese Variante enthält einige einfache Erweiterungen gegenüber dem Standard-Unix-Prozeßmodell sowie einige Sprachzusätze.
Der Entwickler kann sich auf parallele Algorithmen konzentrieren, anstatt sich mit Implementierungsfragen abzumühen. Außerdem verspricht diese Implementierung in SVR4 ES/MP eine gute Performance.
Gerade Datenbankanwendungen stellen hohe Anforderungen an eine performante Umgebung. Bei relationalen Datenbanken sind die Prozesse meist nach dem Client-Server-Prinzip aufgebaut. Als Client oder auch Front-end wird eine Anwendung verstanden, die entweder aus rein SQL-basierten Anfragen besteht oder aus Programmen die (embedded) SQL-Statements enthalten. Diese Clients bilden das für den Benutzer "sichtbare" Interface zur Datenbank.
Der Client richtet seine Datenbank-Anfragen mittels Unixeigener Interprozeß-Kommunikationsmechanismen an den Server - auch Back-end genannt-, der die eigentliche Schnittstelle zur Datenbank darstellt. Von hier wird auf die Dateien zugegriffen und mit Hilfe von Locking-Verfahren die Datenbank-Integrität gesichert. Der Server-Prozeß ist meist CPU-intensiv und besteht zu großen Teilen aus System-Calls.
Da dieser Vorgang meist im Kernel-Mode abläuft, wird bei Multiprozessor-Systemen mit Master-Slave-Architektur nur der Master genutzt, womit sich der Engpaß dieser Rechnersysteme verschärft.
Hohe Durchsatzwerte, wie sie heute im Online-Transaction-Processing (OLTP) notwendig sind, kann diese Architektur nur schwer erreichen.
Symmetrische Multiprozessor-Systeme bieten hier die weit höhere Leistung, da Server, Client und das Betriebssystem auf jeder CPU ablaufen können. Dadurch wird eine optimale Lastverteilung erreicht. Mit verschiedenen Ansätzen haben die Hersteller neuerer Versionen der relationalen Datenbanken ihre Implementierungen auf die symmetrischen Multiprozessor-Systeme zugeschnitten und dabei Leistungssteigerungen gegenüber den Vorgängerversionen erzielt.
Bei Datenbankanwendungen mit hohen Transaktionsleistungen erweisen sich die notwendigen Plattenzugriffe als ein weiterer kritischer Punkt. Die heute eingesetzten Platten arbeiten mit zirka 50 Zugriffen pro Sekunde. Um diese Werte optimal auszunutzen, werden die Plattenzugriffe durch Zugriffe auf spezielle Datenbank-Cache-Bereiche im Shared Memory ersetzt. Durch dieses Verfahren läßt sich die Anzahl der Plattenzugriffe gewaltig verringern.
Da der bei jeder Transaktion notwendige "Commit" mindestens einen Schreibbefehl auf der Platte bewirkt, wurden sogenannte Group-Commits implementiert, die anlaufende "Commits" zwischenspeichern und dann gruppenweise mit einem Plattenzugriff wegschieben. Spezielle Hintergrundprozesse, die beim Schreiben der Datenbankinformation vom Cache-Bereich auf die Platte ablaufen, steigern den Plattendurchsatz zusätzlich. Außerdem kann beim Datenbankdesign eine Reihe von Zugriffsengpässen durch das Verteilen der einzelnen Dateien vermieden werden.
Diese Eigenschaften lassen sich jedoch nicht global für jeden beliebigen Einsatz vorhersehen und somit optimal einstellen. Eine moderne Datenbank ist vielmehr dadurch gekennzeichnet, daß diese Funktionen angeboten werden und über Konfigurationsparameter flexibel auf die jeweilige Applikation einstellbar sind.
Optimierung der Datenbank-Systeme
So führt zum Beispiel die Verwendung von Group-Commits mit großen Pufferbereichen im Falle eines Rechnerabsturzes zu einer erhöhten Rekonstruktionszeit. Es bleibt jedoch dem Anwender überlassen, diese eventuellen Nachteile zugunsten besserer Performance in Kauf zu nehmen. Mit den speziell auf Multiprozessor-Architektur zugeschnittenen Datenbanken lassen sich heute Durchsatzwerte erreichen, die zwar im Mainframe-Bereich kein Problem darstellen, dort aber mit sehr hohen Hardwarepreisen erkauft werden müssen.