Das Bestreben, den Durchsatz eines Computers zu steigern, führt mehr oder weniger zwangsläufig zur Entwicklung paralleler Architekturen. Dazu gibt es mehrere Ansätze. Der vorliegende Artikel beleuchtet zwei davon und erläutert, warum Unix aus der Sicht des Autors als Ideales Betriebssystem für solche Zwecke gelten kann.
Computer mit einer inkrementellen Rechnerarchitektur geben dem System-Designer die Möglichkeit die Verarbeitungsleistung einer EDV-Anlage schrittweise zu steigern. Bei herkömmlichen Uniprozessor-Anlagen werden sowohl die System- als auch die Applikationsoperationen von einem einzigen Prozessor ausgeführt. Der Gesamtdurchsatz eines Rechners ist somit eindeutig durch die Leistungsfähigkeit dieses Prozessors beschränkt. Am seriellen Charakter der internen Verarbeitung ändern dabei auch die softwaregestützten Multitasking- und Multiusereigenschaften des Betriebssystems nichts. Bei Mehrprozessor-Konfigurationen läßt sich die Last dagegen auf mehrere Rechner verteilen, so daß einzelne Aufgaben beziehungsweise Teilaufgaben nicht länger seriell, sondern parallel zueinander abgearbeitet werden können, was zu einer Steigerung des Durchsatzes führt.
Generationenwechsel bei Mikroprozessoren
In den letzten Jahren haben die Entwicklungsingenieure der führenden EDV-Hersteller versucht, größere Leistungssteigerungen ihrer mikroprozessorgestützten Computersysteme über die Verwendung neuer, schnellerer und mächtigerer Prozessoren sicherzustellen. So sind beispielsweise die 8-Bit-Mikroprozessoren Motorola 6800 und Intel 8080 der ersten professionellen PC-Generation mittlerweile aus der Produktpalette der meisten Anbieter verschwunden. Sie wurden nach und nach durch den MC-68000- beziehungsweise 68020- und den Intel-80286- beziehungsweise 80386-Chip ersetzt, was zu wesentlichen Verbesserungen der Rechengeschwindigkeit, der direkten Adressierungsmöglichkeiten und damit letztlich des Verarbeitungsdurchsatzes geführt hat.
Allerdings ist es nicht mit dem Austausch der Prozessoren allein getan. Die gesamte Systemarchitektur eines Minicomputers muß auf die neuen "Arbeitstiere" abgestimmt werden, damit diese ihre ganze Leistungsfähigkeit erreichen und ihr potentielles Funktionsspektrum von zur Verfügung stellen können. Somit ist mit dem Wechsel von einer Prozessorgeneration zur nächsten in der Regel auch ein Kompatibilitätsproblem verbunden. Zur Absicherung der Software-Investitionen der Anwender sehen sich die Hersteller daher nicht selten zu einer "Second-best-Lösung" gezwungen. Der leistungsfähigere Rechner emuliert den älteren, schwächeren Prozessor - eine schlichte Vergeudung von Ressourcen!
Heute, da Prozessoren mit einer echten 32-Bit-Adressierung in den meisten hochleistungsfähigen Minis zum Einsatz kommen, dürften die nächsten Schritte zu weiteren Leistungsverbesserungen kleiner und seltener werden. Sie werden nach Ansicht von Hardware-Spezialisten zudem eher aus der Weiterentwicklung der bereits eingeführten DEC-, Intel- oder Motorola-Familien resultieren als auf völlig neue Typen zurückzuführen sein.
Fortschrittliche Einzelplatz-Mikros auf Basis der genannten Prozessoren stellen derzeit weit mehr Leistung zur Verfügung, als ein einzelner Benutzer sinnvoll nutzen kann. Sollen aber 8,32 oder gar 100 und mehr Anwender an einen Mikroprozessor angeschlossen werden, dann verringert sich bei vielen Applikationen der Datendurchsatz so drastisch, daß die Antwortzeiten dem Benutzer kaum noch zuzumuten sind. Monoprozessoren werden nämlich mit steigender Benutzerzahl allmählich ineffizienter. Da der Rechner neben der Verarbeitung des System- und Applikationscodes auch die Synchronisierung und Verwaltung der Gesamtkonfiguration übernehmen muß, nimmt die tatsächliche für den Anwender zur freien Verfügung stehende Computerleistung überproportional mit dem Anteil dieser "Overhead-Arbeiten" ab.
Der Markt wird aber auch in Zukunft nicht aufhören, mehr Leistung zu fordern, und so werden sich die Entwickler wohl verstärkt neuen Rechnerarchitekturen zuwenden müssen, um der Nachfrage gerecht zu werden. Hier könnte die Alternative, verschiedene Arbeitsschritte parallel durchzufahren, anstatt die Verarbeitungsressourcen einer einzigen CPU in immer kleinere Zeittakte zu zerstückeln, einen effizienten Ausweg darstellen. Die Multiprozessor-Technik ist in erster Linie deshalb attraktiv, weil im Zuge von BK- und CIM-Anwendungen (BK = Bürokommunikation, CIM = Computer Integrated Manufacturing) immer leistungsfähigere dezentrale Rechnerkonfigurationen immer mehr Benutzer an direkt angeschlossenen Arbeitsplätzen unterstützen sollen.
Die Vorzüge einer Multiprozessor-Architektur gegenüber monolitischen Systemen liegen auf der Hand. Ein Einprozessor-System, auf dem der gesamte Systemcode abgearbeitet wird, steht nicht selten lediglich zu 50 Prozent der Zeit für die eigentlichen Rechenaufgaben zur Verfügung. Die restlichen 50 Prozent beschäftigt sich der Prozessor unter anderem mit I/O-Operationen, Zeichenverarbeitung, Interrupt-Verwaltung und anderem Overhead. Mit anderen Worten, er beschäftigt sich mit sich selbst. Bei Multiprozessoren läßt sich dagegen die Systemlast auf mehrere Rechner verteilen, wodurch sich der Datendurchsatz, selbst bei einer größeren Benutzerzahl, deutlich erhöht.
Lose versus starre Prozessor-Koppelung
Für die Auslegung von Mehrprozessor-Systemen gibt es zwei Ansätze: Die starre und die lose Koppelung der Prozessoren. Bei der starren Koppelung greifen mehrere Prozessoren über zentrale Dateisteuerungs-Strukturen, wie Puffer- und Cachespeicher, auf den gemeinsamen Hauptspeicher zu. Die Zugriffssicherung wird dabei mittels Prioritätsvergabeverfahren, wie zum Beispiel Semaphoren, geregelt. Bevor also ein Prozeß Daten im gemeinsamen Speicher verändern kann, blockiert er den Zugriff, so daß alle anderen Prozesse warten müssen, bis der Zugang zum gemeinsamen Speicher wieder frei ist. Die Zugangssperre sichert die Datenintegrität, verhindert aber gleichzeitig eine Parallelisierung der Verarbeitung auf der Dateiebene.
Starr gekoppelte Systeme weisen aber auch eine Reihe von Vorteilen auf. Da das gesamte Betriebssystem im gemeinsamen Speicher gehalten wird, müssen nur geringfügige Änderungen am Unix-Kern vorgenommen werden, um mehrere Prozessoren einzubinden. Und da der Kern der Systemsoftware erhalten bleibt, besteht kaum Bedarf, die Utilities (Hilfsprogramme) umzuschreiben. Auf diese Weise bleibt die Kompatibilität beim Übergang von einem monolitischen System zu einer Mehrprozessor-Architektur erhalten. Investitionen in System- und Applikationssoftware sind gesichert.
Starre Koppelung erleichtert Load Balancing
Die dynamische Verteilung der Arbeitslast über die gesamte Systemkonfiguration hinweg wird über einen Scheduler geregelt. Tatsächlich ist die Austarierung der Auslastung der einzelnen Ressourcen, das sogenannte Load Balancing, bei den meisten bisher im Markt eingeführten starr gekoppelten Systemarchitekturen recht gut gelöst. Positiv dabei ist, daß für die Systemsynchronisation keine zusätzliche Software erforderlich ist.
Da allerdings alle Prozessoren immer wieder auf den gemeinsamen Hauptspeicher zugreifen müssen, wird der Datenverkehr auf dem Bussystem stark aufgebläht. Außerdem verbringen die Prozessoren einen Großteil der Zeit damit, auf die Zugangsberechtigung zu warten beziehungsweise anzufragen, ob die Zugangssperre aufgehoben ist. Dies führt in der Regel zu erheblichen Engpässen und damit zu einer Beeinträchtigung der Verarbeitungsleistung. Versucht man, den Datenverkehr auf dem Bus zu minimieren und/oder die Konkurrenzsituation beim, Speicherzugriff zu entschärfen, indem man den einzelnen Prozessoren zusätzliche Cache-Speicherkapazität zuordnet, kommt es nicht selten zu Problemen bei der Cache-Kohärenz. Der hier aufgezeigte Flaschenhals wirkt sich im allgemeinen als faktische Begrenzung der Leistung und Erweiterbarkeit von Multiprozessor-Systemen mit starr gekoppelten Architekturen aus.
Systembus bleibt Flaschenhals
Solche Systeme sind bei dyadischer oder triadischer Auslegung zwar noch recht effektiv, lassen aber stark zu wünschen übrig, wenn mehr als drei oder vier Prozessoren in eine Minicomputer-Konfiguration integriert werden sollen. Starr gekoppelte Konfigurationen können daher in der Praxis nur einen Bruchteil der Möglichkeiten realisieren, die ein verteiltes Betriebssystem beim Einsatz auf Multiprozessoren eröffnet,
Erweitert man ein starres Mehrprozessor-System um eine Prozeß-Kommunikation, wie sie durch das Multibus II Interface gewährleistet wird, und verteilt man wesentliche Funktionen des Betriebssystems auf die einzelnen Rechner, so erhält man ein sogenanntes, LCA-System (LCA = Losely Coupled Architekture). Da in diesem Falle die inhärente Beschränkung des gemeinsamen Speicherzugriffs entfällt, kann eine größere Zahl von Prozessoren integriert werden, ohne daß es zu dem befürchteten Flaschenhals beim Master - den gibt es eigentlich gar nicht - und damit zu Leistungseinbußen kommt. Die Verteilung dedizierter Betriebssystemfunktionen auf einzelne Prozessoren macht es darüber hinaus relativ einfach, funktionsspezifische Module zu entwickeln und zu optimieren.
Bei einer LCA-Konfiguration sind die Prozessoren weitaus unabhängiger voneinander als bei TCA-Systemen (TCA = Tightly Coupled Architecture), denn sie verarbeiten ihre eigenen Instruktionsketten aus dem eigenen Speicher. Die Kommunikation zwischen den Prozessoren gewährleistet die Synchronisation der Tasks.
Lose gekoppelte Multiprozessoren weisen klare Vorteile gegenüber einer starren Architektur auf. Da sich die Applikationsprozessoren hier nicht gegenseitig blockieren, kann die Leistung mehrerer lose gekoppelter Prozessoren weit über der von starr gekoppelten Konfigurationen liegen. Dieser Vorteil wird mit zunehmender Zahl von Prozessoren immer gravierender.
LCA erlaubt Spezialisierung der Prozessoren
LCA-Systeme können ebenso gut homogene wie funktionsspezifische Prozessoren integrieren. Mit der Implementierung von intelligenten, funktionsspezifischen Modulen, die den Hauptprozessor zum Beispiel von den gesamten Ein-/Ausgabe-Operationen entlasten, haben einige Minicomputer-Anbieter bereits bei erweiterten monolitischen Systemen erhebliche Leistungsverbesserungen erzielen können. Um allerdings den Durchsatz bei der Verarbeitung von Anwendungsprogrammen zu erhöhen, ist es notwendig, mehrere Applikationsprozessoren parallel zu schalten.
Beim neuen NCR Tower 32/800 wurde dieser Weg beschnitten. Bis zu vier Applikationsprozessoren (APs) und die dazugehörigen Speichermodule mit einer physikalischen Kapazität von maximal je 16 MB können in das System integriert und über den parallelen Bus (Multibus 10 miteinander verbunden werden. Ein Applikationsprozessor wird als "temporärer" Master-AP konfiguriert, der das Betriebssystem lädt, und daher mit einem System Control Processor (SCP) ausgestattet. In seiner Eigenschaft als Master ist dieser Rechner jedoch lediglich in der Startphase und beim Re- beziehungsweise Dekonfigurieren tätig, ansonsten arbeitet er wie ein "gewöhnlicher" Anwendungsprozessor.
An den Multibus II angeschlossen sind ferner bis zu vier spezielle Dateiprozessoren, die über einen integrierten SCSI-Bus und über spezielle Kommunikationsprozessoren mit je zwei synchronen/asynchronen Kanälen die Festplatten- und Bandspeicher steuern, Außerdem lassen sich bis zu acht Terminalprozessoren mit je acht TTY-Terminalanschlüssen integrieren.
Mehrplatzfähige Computer brauchen ein entsprechendes Betriebssystem. Nach Ansicht fahrender Software-Experten könnte eine solche Systemsoftware Unix heißen.
Unix zeichnet sich sowohl in Hinblick auf seine Multiuser- und Multitasking-Fähigkeiten als auch in bezug auf seine I/O-Mechanismen durch eine systemimmanente Parallelität aus. Diese "Mehrgleisigkeit" in der Verarbeitung kann allerdings nur dann von ausgeschöpft werden, wenn dem Benutzer das Leistungs- und Funktionsspektrum mehrerer Prozessoren gleichzeitig zur Verfügung steht, ohne daß dabei die Kompatibilität seiner bisherigen Anwendungssoftware in Frage gestellt wird. Das heißt, sowohl auf der Ebene des Quellcodes als auch auf jener des Objektcodes muß volle Kompatibilität mit vorhandenen Uniprozessoren aus derselben Produktfamilie gewährleistet sein. Da Unix nun aber in seinem eigentlichen Systemkern für monolitische Systeme konzipiert wurde, ist eine Modifikation dieses Unix-Kerns sowie einiger Utilities (Hilfsprogramme) unumgänglich. Daher sind lose gekoppelte Systeme mit funktionsspezifischen Prozessoren wesentlich schwieriger zu implementieren als TCA-Konfigurationen.
Zu den Veränderungen am Unix-Betriebssystem gehört idealerweise auch die Duplizierung wesentlicher Steuerungsstrukturen, um den "Konkurrenzbetrieb" der einzelnen Prozessoren möglichst gering zu halten. Dazu wird in aller Regel der Systemkern aufgesplittet werden müssen, um die entsprechenden Komponenten unabhängig voneinander und bei Bedarf auch mehrere Kopien einer Systemroutine zur Verfügung zu stellen. Die Synchronisation der Tasks, Prozesse und Prozessoren untereinander kann dann durch die Übermittlung von "Nachrichten" (Message) sichergestellt werden. Systemaufrufe, die über den Funktionsbereich des jeweiligen Prozessors hinausgehen, werden in Nachrichten umgesetzt und gezielt an einen anderen Baustein weitergeleitet. Dort wird die Nachricht decodiert und die gewünschte Transaktion gestartet.
Bei der Verteilung des Unix-Kernels auf unterschiedliche Prozessoren muß möglichen Konfliktsituationen beim Zugriff auf gemeinsam genutzte Ressourcen besondere Aufmerksamkeit gewidmet werden. Jeder Prozessor sollte daher mit einem eigenen Pufferspeicher ausgestattet werden, um eine verstärkte Überlappung der "lokalen" Ein-/Ausgabeoperationen zu erreichen. Die Synchronisation und die Ablaufsteuerung des Gesamtsystems kann allerdings nur bedingt verteilt werden. Beim LCA-Rechnerkonzept muß in Kauf genommen werden, daß für fast alle Operationen ein Verteilungs- und Synchronisierungs-Overhead entsteht und daß der Roh-Input etwas weniger effizient als bei TCA-Strukturen ist.
Auch Betriebssystem wird aufgeteilt
Zur softwareseitigen Unterstützung solcher Multiprozessor-Architekturen werden Teile des Unix-Kerns auf die spezifischen Prozessoren verteilt. So übernimmt beim vorliegenden Beispiel der Applikationsprozessor die Ausführung der eigentlichen Anwendung, was natürlich entsprechende System- und E/A-Aufrufe einschließt. Daneben verwaltet er die Anwendungs-E/A-Puffer und sorgt für eine gleichmäßige Verteilung der Arbeitslast. Im Dateiprozessor, der alle Block-Ein- und Ausgabeoperationen verwaltet, sind der Plattensubsystem-Code, der SCSI-Treiber (Small Computer System Interface), die System-I/O-Puffer und der I/O-Core-Scheduler untergebracht. Der Terminalprozessor übernimmt als TTY-Server die Ein-/Ausgabe auf Zeichenbasis. Hier befinden sich jene Teile des Unix-Kerns, die für die Steuerung des TTY-Subsystems verantwortlich sind, sowie die TTY-Treiber und eine Kopie des I/O-Core Schedulers.
Der Kommunikationsprozessor steuert prioritäre Ein-/Ausgaben. Zu den auf diesen Prozessor geladenen Betriebssystem-Komponenten zählen das Kontrollprogramm für das Kommunikationssubsystem, die Kommunikationstreiber und der bei allen dedizierten I/O-Prozessoren vorhandene I/O-Core-Scheduler.
Dieses Design der Unix-Mehrprozessor-Architektur gewährleistet eine stärkere Überlappung und einen höheren Parallelitätsgrad der Verarbeitung und forciert damit den Datendurchsatz ganz wesentlich. Außerdem ist durch die Redundanz einzelner Module eine größere Verfügbarkeit des Gesamtsystems gesichert. Auch die Aufrüstung um neue Prozessoren ist denkbar einfach: Der Rechner wird ausgeschaltet und eine zusätzliche Platine eingeschoben. Danach wird das System wieder eingeschaltet, und der Computer nimmt automatisch eine Neukonfigurierung vor, um die zusätzlichen Ressourcen des neuen Prozessors auch von ausschöpfen zu können. Hierzu ist kein Sysgen erforderlich.
Erhöhte Verfügbarkeit durch Teilredundanz
Fällt nun in einem Mehrprozessor-System mit inkrementeller Architektur einmal ein Prozessor aus, so kann der Operator sofort einen Neustart (Reboot) durchführen, der das Multiprozessor-System innerhalb weniger Minuten wieder ans Laufen bringt. Der ausgefallene Prozessor wird als solcher identifiziert und automatisch (logisch) aus dem Verarbeitungsprozeß ausgegliedert.
In einer nach Abteilungen dezentralisierten Rechnerumgebung kann es aber auch passieren, daß sich die Rechnerauslastung in einer Abteilung drastisch verändert. In einem solchen Falle kann ein überflüssiger Prozessor herausgenommen und an anderer Stelle im Unternehmen sinnvoller eingesetzt werden.
Innerhalb der jeweiligen systemimmanenten Grenzen lassen sich LCA-Konfigurationen um zusätzliche Speicherkomponenten erweitern. Der Vorteil der inkrementellen Unix-Architektur besteht dabei vor allem darin, daß der zusätzliche Speicher dediziert in jenen Applikationsprozessoren installiert wird, in denen er am dringendsten benötigt wird. Und, wenn mehr Verarbeitungsleistung für die Ausführung bestimmter Anwendungsprogramme gebraucht wird, können auch ganze Applikationsprozessoren hinzugefügt werden.
Konfiguration kann leicht angepaßt werden
Dementsprechend lassen sich auch zusätzliche Terminal- und Dateiprozessoren in ein inkrementelles System integrieren und sofort nutzen, wenn in diesen Bereichen zusätzliche Ressourcen benötigt werden. Der Systemverwalter muß dabei entscheiden, welche Plattenlaufwerke an den neuen Dateiprozessor angeschlossen werden sollen. Zusätzlich sind ein paar Konfigurationsentscheidungen zu treffen. Insgesamt ist die Aufrüstung jedoch im Vergleich zu Monoprozessormaschinen relativ einfach durchzufahren.
In der Vergangenheit, war das "Ausbalancieren" der Systemlast bei Rechnern mit starr gekoppelten Prozessoren ein hervorragendes Leistungsmerkmal. Inkrementelle Systeme mit lose gekoppelten Prozessoren gestatten dagegen keine automatische Verteilung der Arbeitslast. Für verteilte Unix-Systeme sind jedoch in den letzten Jahren Tuning-Mechanismen entwickelt worden, die auf der Task-, Prozeß- und Prozessor-Kommunikation aufbauen, und eine dynamische Verteilung der Auslastung der einzelnen Systemmodule ermöglichen, die nahezu optimal ist. Gleichzeitig verhindern sie Engpässe und Flaschenhälse, wie sie bei starrer Prozessorkoppelung nicht zu vermeiden sind.
Das dynamische Tuningverfahren ist einfach. Beim Systemstart werden die Dateiprozessoren und TTY-Verbindungen nach einem vorgegebenen Schema, zum Beispiel gleichmäßig, allen vorhandenen Applikationsprozessoren zugeordnet. Während die Benutzer dann ihre verschiedenen Anwendungen fahren, überprüft der modifizierte Unix-Kern in jedem Applikationsprozessor alle übrigen APs im System und schiebt anfallende Aufgaben dem am wenigsten ausgelasteten Rechner zu. Auf diese Weise wird die Arbeitslast im allgemeinen automatisch gleichmäßig aufgeteilt. Ein statischer "Dämon für Ungleichgewichte" kann eine längerfristige Unausgewogenheit der Auslastung feststellen und die Prozesse je nach Bedarf von einem AP zum anderen umleiten. Die gleichmäßige Auslastung der Datei- und Terminalprozessoren ist dagegen etwas komplexen und auch theoretisch nicht so elegant zu lösen.
In einem inkrementellen System stellt jeder Dateiprozessor (FP) nahezu ein Spiegelbild aller übrigen Dateiprozessoren dar. Jeder FP beinhaltet eine vollständige Kopie des Unix-Dateisystemkerns, unterhält einen Plattenpuffer-Cachespeicher und hat eine eigene Inode-Liste. Jeder Dateiprozessor arbeitet unabhängig von seinen "Kollegen".
Wird ein zusätzlicher Dateiprozessor mit Hilfe eines Sysgen in das System integriert, so kann der Benutzer ganze Platten oder auch nur Teile von Platten angeben, die spiegelbildlich auf einer anderen Platte abgelegt werden sollen. Indem der Benutzer eine logische Platte auf mehrere physische Platten abbildet, definiert er den Parallelitätsgrad der Zugriffe auf eine einzige Datei.
Faßt man die genannten Gesichtspunkte einmal zusammen, so werden die Vorteile einer lose gekoppelten Systemarchitektur deutlich:
- Modularität,
- Flexibilität,
- Transparenz des Systemkerns.
Unix hat seit jeher eine starke Position bei technisch-wissenschaftlichen Applikationen. Aber auch bei kommerziellen Anwendungen kann Unix sich nun mehr und mehr durchsetzen. Zu den wichtigsten Erfolgsfaktoren zählt hier gewiß die Standardisierung über Hardware- und Herstellergrenzen hinweg. Die Hardwareunabhängigkeit bedeutet letztlich, daß der Kunde weniger an einen bestimmten Anbieter gebunden ist, als dies bei spezifischer Systemsoftware der Fall ist.
Der Zielmarkt ist lösungsorientiert. Dies bietet zusätzliche Chancen, neben Unix auch herstellerspezifische Betriebssysteme zu vertreiben und durchzusetzen, wo immer dies Sinn macht. Insofern kann Unix gewisse Türöffner-Funktionen übernehmen.
Markt findet unterhalb der Mainframeebene statt
Bei den sogenannten. "Major Accounts" - zu neudeutsch Großkunden - ist eine geänderte Beschaffungspolitik festzustellen:
- Die meisten Anwender von Großrechnern sind auf "ihre" Hersteller festgeschrieben. Ablösungen finden äußerst selten statt. Unterhalb der Mainframeebene besteht jedoch ein breites Operationsfeld, das Anbietern, die eine Brücke zwischen dem Personal Computing einerseits und der batchorientierten Massendatenverarbeitung andererseits bauen können, riesige Nachfragereserven in Aussicht stellt. Dies aber ist eine typische Unix-Domäne.
- Bei Ein- und Mehrplatzmikros erscheint Unix in einer stetig wachsenden Anzahl von Ausschreibungen insbesondere bei der öffentlichen Hand als K.-o.-Kriterium, was auch für den privaten Anwender sehr bald schon Signalwirkung haben dürfte.
- Immer mehr Benutzer sehen sich mit dem Problem der Einbeziehung von Arbeitsplatzrechnern und Personalcomputern in unternehmensweite DV-Umgebungen konfrontiert. Dies gilt insbesondere für Applikationen wie Bürokommunikation oder CIM. Hier bietet Unix durch seine Integrationsfähigkeit ein effizientes und einfach zu handhabendes Instrumentarium.