Ein Testbett hat mit einer Schlafstatt nichts gemein. In ihrem Beitrag beschreiben Karl-H. Glässer* und Edgar Nett* die Wirkungsweise von echten verteilten Systemen und noch nicht gelöste Probleme.
DV-Systeme werden gewöhnlich schon als verteilt angesehen, falls Aspekte wie Benutzerzugriff, Systemgeographie, Verarbeitung oder Daten dezentralisiert sind. Letztlich wird ein System jedoch als verteilt bezeichnet, wenn es die Eigenschaft der verteilten Systemkontrolle besitzt.
Hierunter versteht man, daß der Zustand des Gesamtsystems in Stücke aufgespalten wird, die in den verschiedenen Systemknoten residieren und deren Kommunikation untereinander unter variablen und unbekannten Zeitverzögerungen abläuft. Solche System können nicht garantieren, daß verschiedene Systemknoten eine auftretende Folge von Ereignissen identisch wahrnehmen.
Unter diesen Bedingungen erlauben die gegenwärtig bekannten Konzepte und Techniken keine geeignete Kontrolle über das Gesamtsystem. Anstelle eines einzelnen Systems hat man nun eine Vielzahl von individuellen Systemen, die miteinander verbunden sind, aber lokal kontrolliert werden.
Man erwartet, daß solche Systeme wesentliche Vorteile bieten, so zum Beispiel
- verbesserte Modularität
- erhöhte Robustheit
- Leistungssteigerung
- einfachere Test- und Wartbarkeit.
Aufgrund dieser erwarteten Vorteile werden gegenwärtig zahlreiche Forschungsarbeiten auf dem Gebiet der verteilten DV-Systeme durchgeführt. Ein wichtiges Hilfsmittel zur Entwicklung und Erprobung derart komplexen Multicomputerarchitekturen besteht in dem Aufbau eines sogenannten experimentellen Testbetts.
Dieses soll in der Lage sein, eine Vielzahl von unterschiedlichen Rechnerarchitekturen, Verbindungsstrukturen, Protokollen etc. zu modellieren, zu simulieren und zu evaluieren.
Solche Testbett-Entwicklungen haben vor allem in den USA große Beachtung gefunden und erfreuen sich dort entsprechend ihrer Bedeutung starker finanzieller Unterstützung. Eher sind vor allem das "Distributed Data Processing" (DDP) - Projekt des U. S. Army "Ballistic Missile Defense Advanced Technology Center" (BMDATC) in Huntsville, Alabama, sowie Forschungsprojekte bei Honeywell in Minneapolis, Minnesota, und bei der Carnegie-Mellon University in Pittsburgh, Pennsylvania, zu nennen.
Das "Ballistic Missile Defense Advanced Technology Center" betreibt Forschung und Entwicklung auf dem Sektor der modernen Datenverarbeitungstechnologie, insbesondere zur Unterstützung von "Ballistic Missile Defense"-(BMD-)Anwendungen. Zur Erforschung und Entwicklung von, derart großen, computergesteuerten Waffensystemen wie dem BMD benötigte man eine komplexe Experimentier- und Testumgebung.
Deshalb wurde mit großem Aufwand eine flexible Testbettkonfiguration geschaffen. Diese soll von einer Vielzahl von Vertragsnehmern des "Ballistic Missile Defense Advanced Technology Center" dazu benutzt werden, Experimente aufzubauen und durchzufahren, die unter dem Blickpunkt ihrer militärischen Anwendung zu Erkenntnissen auf Gebieten wie neue Hardwarekonzepte und-Architekturen, Software-Engineering sowie Algorithmenentwicklung führen sollen.
Szenario-Simulation
Das Testbett ist ein verteiltes System. Es liefert die Rechnerkapazitäten, Verbindungsnmechanismen und Systemdienstleistungen zur Unterstützung der Emulation von "target"- Prozessoren und zur Simulation von "target"-Computersystemen.
Das Testbett besteht aus zwei Hauptkomponenten:
- einem Control Data 6400/7600 System und
- dem sogenannten Testbett-Nukleus,
Das CDC-System war schon vor dem Testbett-Nukleus in Betrieb und stellte ein zentrales Organisationskonzept zur Simulation von "target data processing systems" des "Ballistic Missile Defense" dar. Eingebettet in das neue verteilte Testbett dient es vorwiegend zur Erzeugung der benötigten großen Anzahl von Daten zur Simulation des militärischen Szenarios.
Host mit reichlicher Hardware
Der Testbett-Nukleus ist ein Netzwerk, welches sich aus acht VAX11/780-Rechnern zusammensetzt. Einer dieser Rechner, in der Abbildung mit der Nummer 1 versehen, zeichnet sich gegenüber den restlichen sieben dadurch aus, daß er der "host" für das Software-Entwicklungssystem des Nukleus ist.
Er ist deshalb auch reichlicher mit Hardware ausgestattet worden, nämlich mit einem 2,5-MB-MOS-Speicher mit fehlerkorrigierendem Code und drei 67-MB-Platten. Die restlichen sieben Rechner besitzen 768 bis 1024 KB starke Hauptspeicher und zwei 28 MB leistende "cartridge disks".
Im Netzwerk sind drei verschiedene Verbindungen vorgesehen.
- PCL11-B Link: Alle acht VAX11/ 780-Rechner sind durch diese DEC-Parallelschnittstelle verbunden.
Das Multiplexen erfolgt in Einheiten von 16-Bit Worten. Die maximale Datenübertragungsrate auf dem Bus beträgt 8 MBits pro Sekunde. Die Bandbreite wird dynamisch zugeteilt, daß heißt, Prozessoren mit hohem Datenausstoß bekommen einen entsprechend hohen Anteil an der insgesamt verfügbaren Bandbreite.
- DMC11-Link: Vier der acht Rechner sind zusätzlich noch durch den DEC DMC11-Link sequentiell miteinander verbunden. Es handelt sich um eine Punkt-zu-Punkt-Verbindung mit "built-in protocols" und Fehlererkennungsmöglichkeiten. Die Transferrate beträgt 0,95 MBits pro Sekunde.
- NSC Hyperchannel: Als Kommunikationsmedium dient dem Hyperchannel ein serielles Koxialkabel mit einer Datenrate von bis zu 50 MBits pro Sekunde. Alle Funktionen im Zusammenhang mit dem Nachrichtenaustausch über dieses Medium werden auf beiden Seiten von Adaptern ausgeführt. Dazu gehören die Festlegung des Sender/Empfängerpaares, die Fehlererkennung sowie das nochmalige Senden der Daten im Fehlerfalle.
Mailbox-Konzept
Das Testbett benutzt die VAX/ VMS-Systemsoftware. Hinzu kommen unter anderem eine Netzwerksprache, Kommunikationsmechanismen zwischen Prozessoren und virtuelle Terminaloperationen.
Mit Hilfe einer speziellen "Network Configuration Language" (NCL) wird es, dem Benutzer ermöglicht, logische Kommunikationsnetzwerke zu definieren und auf das physikalische Testbett abzubilden. Somit kann der Benutzer sich seine eigene Hardware-Konfiguration für ein Experiment spezifizieren.
Virtuelle Terminaloperationen erlauben, jedes an einen VAX-Rechner angeschlossene Terminal mit jedem beliebigen anderen Rechner des Netzwerks logisch zu verbinden. Vom Benutzerstandpunkt erscheint das Terminal mit dem von ihm spezifizierten VAX-Rechner physikalisch verbunden, obwohl dies real durch die Kommunikation innerhalb des Netzwerks geschieht.
Die Kommunikation zwischen Prozessen auf verschiedenen Prozessoren basiert auf einer Erweiterung des sogenannten "Mailbox"-Konzeptes innerhalb des VAX/VMS-Betriebssystems. Eine "Mailbox" ist eine virtuelle Ein-/Ausgabeeinheit, eine Software-Konstruktion, die Lese-/ Schreiboperationen zwischen den miteinander kommunizierenden Prozessen durchführt.
Mangel an Fehlertoleranz
Ein großes und mehrere kleine Experimente wurden bisher auf dem beschriebenen Testbett ausgeführt. Dabei stellte sich heraus, daß die meisten der aufgetretenen Probleme auf den Mangel an Fehlertoleranz und der geringen Zuverlässigkeit der Software zurückzuführen waren.
Dies wurde besonders virulent, wenn sich mehrere Benutzer das System für die Ausführung ihrer Experimente teilten. So führt das Auftreten eines Fehlers bei einem Benutzer dazu, daß das ganze System auf Kosten aller anderen Benutzer gestoppt werden muß.
Wegen des Fehlens von geeigneten "debugging tools" kann der Benutzer anhand einer Fehlermeldung nicht unterscheiden, ob die Ursache hierfür in seinem Experiment liegt oder ob es sich um einen Hardware- beziehungsweise Softwarefehler des Systems handelt. In jedem Fall muß sowohl das System als auch das entsprechende Benutzerexperiment getestet und anschließend das Testbett neu gestartet werden.
Aufgrund dieser ersten Erfahrungen wurde schon deutlich, daß unter den Randbedingungen einer verteilten Systemumgebung, im Bereich der Entwicklung zuverlässiger Software sowie der Fehlerbehandlung weitere Forschungsaktivitäten notwendig erscheinen.
*Karl-H. Glässer und Edgar Nett, Gesellschaft für Mathematik und Datenverarbeitung (GMD), St. Augustin.
Der Beitrag erschien im GMD-Spiegel 2/81.