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.

12.06.1987 - 

Großrechnerleistung auf Superminis durch inkrementelle Architektur und verteiltes Betriebssystem:

Häufig Probleme bei der Cache-Kohärenz

Werden sowohl die System- als auch die Applikationsoperationen von einem einzigen Prozessor ausgeführt, hängt der Gesamtdurchsatz des Rechners allein von der Leistungsfähigkeit dieses Rechners ab. Daran ändern auch softwaregestützte Multiuser- und Multitasking-Eigenschaften des Betriebssystems nichts. Computer mit einer inkrementellen Rechnerarchitektur, meint Wolfgang Lurg*, geben dem Systemdesigner die Möglichkeit, die Verarbeitungsleistung einer DV-Anlage schrittweise zu steigern.

In den letzten Jahren haben die Entwicklungsingenieure der führenden EDV-Hersteller versucht, größere Leistungssteigerungen ihrer mikroprozessorgestützten Computersysteme über die Verwendung neuer, schneller und mächtiger 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.

Prozessor-Austausch nur der erste Schritt

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 voll zur Verfügung stellen können. Somit ist mit dem Wechsel von einer Prozessorgeneration zur nächsten in der Regel auch immer ein Kompatibilitätsproblem verbunden. Zur Absicherung der Software-Investitionen der Anwender sehen sich die Hersteller daher nicht selten zu einer "Secondbest-Lösung" gezwungen. Der leistungsfähigere Rechner emuliert den älteren, schwächeren Prozessor - oder plastischer formuliert - ein 500 SEL Jahrgang 1987 verhält sich auf einer steilen Bergstrecke so, als ob er ein VW-Käfer aus dem Jahre 47 wäre - eine schlichte Vergeudung von Ressourcen!

Leistungsverbesserung durch Weiterentwicklung

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 durchzuführen, anstatt die Verarbeitungsressourcen einer einzigen CPU in immer kleinere Zeittakte zu zerstückeln, einen effizienten Ausweg darstellen. Die Multiprozessor-Technologie 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 angeschlosenen Arbeitsplätzen unterstützen sollen.

Die Vorzüge einer Multiprozessor-Architektur gegenüber monolithischen 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.

Für die Auslegung von Mehrprozessor-Systemen gibt es zwei Ansätze: die starre und die lose Kopplung der Prozessoren. Bei der starren Koppelung greifen mehrere Prozessoren über zentrale Dateisteuerungs-Strukturen, wie Puffer- und Cache-Speicher, auf den gemeinsamen Hauptspeicher zu. Die Zugriffssicherung wird dabei mittels Prioritätsvergabeverfahren, wie zum Beispiel Semaphore, 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. Diese Zugangssperre sichert die Datenintegrität, verhindert aber gleichzeitig eine Parallelisierung der Verarbeitung auf der Dateienebene.

Lose versus starre Prozessor-Koppelung

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 monolithischen System zu einer Mehrprozessor-Architektur erhalten. Investitionen in System- und Applikations-Software sind gesichert.

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.

Zugangsberechtigung schafft Flaschenhals

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äten zuordnet, so kommt es, wie verschiedene NCR-Benchmarks es belegen, 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. Solche Systeme sind bei dyadischer oder triadischer Auslegung zwar noch äußerst 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 Bestriebssystems auf die einzelnen Rechner, so erhält man ein sogenanntes LCA-System (LCA = Losely Coupled Architecture). 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 gekoppelten Prozessoren weit über der von starr gekoppelten Konfigurationen liegen. Dieser Vorteil wird mit zunehmender Zahl von Prozessoren immer gravierender.

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 monolithischen Systemen erhebliche Leistungsverbesserungen erzielen können. Um allerdings den Durchsatz bei der Verarbeitung von Anwendungsprogrammen zu erhöhen, ist es notwendig mehrere Applikationsprozessoren parallelzuschalten.

Applikationsprozessor als temporärer Master-AP

Dieser Weg wurde beispielsweise beim Tower 32/800 beschritten. Bis zu vier Applikationsprozessoren (APs) und die dazugehörigen Speichermodule mit einer physikalischen Kapazität von maximal je 16 MByte können in das System integriert und über den parallelen Bus (Multibus II) miteinander verbunden werden. Ein Applikationsprozessor wird als "temporärer Master-AP konfiguriert, der das Betriebssystem lädt und daher mit einem System Control Processor (SPC) ausgestattet ist. 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.

Unix - Betriebssystem für Mehrprozessor-Architekturen

Mehrplatzfähige Computer brauchen ein mehrplatzfähiges Betriebssystem. Nach Ansicht führender Software-Experten könnte eine solche Systemsoftware Unix heißen.

Unix zeichnet sich sowohl im 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 voll ausgeschöpft werden, wenn dem Benutzer das Leistungs- und Funktionsspektrum mehrerer Mikroprozessoren gleichzeitig zur Verfügung steht, ohne daß dabei die Kompatibilität seiner bisherigen Anwendungs-Software 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 monolithische 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" (Messages) 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.

Verteilung auf spezifische Prozessoren

Zur softwareseitigen Unterstützung der NCR-Multiprozessor-Architektur werden Teile des Unix-Kerns auf die spezifischen Prozessoren verteilt. So übernimmt der Applikationsprozessor die Ausführung der eigentlichen Anwendung, was natürlich entsprechende System- und E/A-Aufrufe (E/A = Eingabe/Ausgabe) 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.

Höherer Parallelitätsgrad bei der Verarbeitung

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-Mehrplatzprozessor-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 voll ausschöpfen zu können. Hierzu ist kein "Sysgen" erforderlich.

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.

Problemlose Rekonfigurierung

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 problemlos herausgenommen und an anderer Stelle im Unternehmen sinnvoller eingesetzt werden.

Innerhalb der jeweiligen systemimmanenten Grenzen lassen sich LCA-Konfigurationen problemlos 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.

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. Zusätzlich sind ein paar Konfigurationsentscheidungen zu treffen. Die Aufrüstung ist jedoch einfach durchzuführen.

Optimale Verteilung der Systemlast

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.

Dynamisches Tuningverfahren

Das dynamische Tuningverfahren ist denkbar 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 komplexer und auch theoretisch nicht so elegant zu lösen.