Josef Sauerland
Am Hohen Kreuz 1a
59590 Geseke
Kurzfassung
Bei Multiprozessor-/Multicomputersystemen mit hunderten oder tausenden von Prozessoren ist Fehlertoleranz ein wichtiges Entwurfsziel. Aus Zeit- und Kosten-Gründen sind Ausfälle, hervorgerufen durch Hardwarefehler einzelner Komponenten, gerade bei langwierigen, rechenintensiven Anwendungen nicht akzeptabel. Neben Fehlertoleranz ist die Fehlervermeidung durch die Auswahl hochwertiger Bauteile und einen sorgfältigen Hardware-Aufbau von entscheidender Bedeutung. Eine genaue Kenntnis von Ausfallursachen und Ausfallzeiten erleichtert dabei das Auffinden von Schwachstellen im Design und ermöglicht somit qualitative Verbesserungen in zukünftigen Systemen.
Im Rahmen des ESPRIT-Projekts ''A Practical Approach to Fault-Tolerant Massively Parallel Systems'' (FTMPS) wurde eine aktive Datenbankumgebung zur Unterstützung der Zuverlässigkeitsanalyse von massiv-parallelen Systemen implementiert.
Diese Datenbankumgebung zeichnet alle für statistische Fehleranalysen aufschlußreichen Daten auf und unterstützt die Fehlerdiagnose und -behebung. Durch eine lückenlose Protokollierung von Fehlern, Auslastungs- und Temperaturwerten, Ausfallzeiten und durchgeführten Reparaturen können wertvolle Hinweise auf vorhandene Schwächen im Hardwareentwurf gewonnen und diese somit bei Weiter- oder Neuentwicklungen von Computersystemen genutzt werden.
Abstract
In multiprocessor-/multicomputer systems consisting of hundreds or thousands of processing elements fault-tolerance is one important design goal. Outage times due to faults of single hardware components are not acceptable -- even in long-running, computation intensive applications. Besides fault-tolerance fault-avoidance by means of using high-quality components and a careful hardware design is very important. Therefore, a detailed knowledge of reasons, times, and durations of faults ease the detection of weak points in the hardware and enable an increase in quality in future systems.
As part of the ESPRIT project ''A Practical Approach to Fault-Tolerant Massively Parallel Systems'' (FTMPS) an active database was designed which supports the reliability analysis of massively parallel systems.
All relevant data for fault-statistics is recorded and error-detection and fault diagnosis is supported. A complete protocol of faults, workload- and temperature data, outage-times, and maintenance actions is recorded. Thus, useful information about weak points in the hardware can be derived.
Die Leistungsfähigkeit moderner Computer konnte in den letzten Jahren immer wieder gesteigert werden. Die Steigerung erfolgte von Bauteilgeneration zu Bauteilgeneration durch Erhöhung der Taktraten und rasant zunehmende Integrationsdichten der elektronischen Komponenten. Der Erhöhung der Integrationsdichten sind jedoch beim Erreichen von Atomgrößen der Schaltungselemente natürliche Grenzen gesetzt , und Signallaufzeiten können nicht über die Lichtgeschwindigkeit hinaus gesteigert werden . Falls die bisher beobachtete exponentielle Steigerung [Mae91] anhält, werden diese Grenzen in naher Zukunft erreicht sein.
Computer sind seit ihrer Erfindung in den 40er Jahren fast immer nach dem Prinzip des Von-Neumann-Rechners gebaut worden: sie bestehen aus einem mit einem Speicher verbundenen Prozessor, wobei eine oder wenige Instruktionen zur gleichen Zeit ausgeführt werden können. Die Zukunft der Computer liegt jedoch in der Parallelverarbeitung, bei der viele Prozessoren gleichzeitig ein Problem lösen [TrW91] . Hierdurch sind enorme Geschwindigkeitssteigerungen zu erreichen. Die leistungsfähigsten Rechner dieser neuen Computergeneration arbeiten mit einigen hundert bis tausend Prozessoren.
Bei diesen massiv-parallelen Systemen (MPS)MPSMPS ergeben sich jedoch neue Schwierigkeiten. Zum einen sind neue Programmier- und Hardwarekonzepte notwendig, um die nebenläufig arbeitenden Komponenten effektiv nutzen zu können, zum anderen ist die Zuverlässigkeit dieser komplexen Systeme noch ein Problem. Zwar sind die einzelnen elektronischen Bauteile im Laufe der Zeit immer zuverlässiger geworden, doch durch die Vielzahl der Einzelkomponenten in einem MPS wird diese positive Entwicklung kompensiert.
Hinzu kommt, daß MPS insbesondere bei rechenintensiven Aufgaben wie Wissensverarbeitung (KI), Wettervorhersagen, Berechnungen von Klimamodellen und Strömungssimulationen eingesetzt werden. Trotz ihrer enormen Leistungsfähigkeit werden hierfür oft Tage oder gar Wochen benötigt. Ausfälle durch fehlerhafte Hardware sind dabei aus Zeit- und Kostengründen nicht akzeptabel. Deshalb ist Fehlertoleranz für MPS ein wichtiges Entwurfsziel [Sie91] .
Das ESPRIT-Projekt ''A Practical Approach to Fault-Tolerant Massively Parallel Systems'' (FTMPS) beschäftigt sich mit der Entwicklung von Techniken und Systemsoftware zur Erbringung von Fehlertoleranz in MPS. Der Ansatz umfaßt hierbei Fehlererkennung, Diagnose, Rekonfiguration und Fehlerstatistik.
Obwohl die Benutzer fehlertoleranter Rechner weitgehend von den Auswirkungen von Hardwarefehlern verschont bleiben, sind sowohl Systemverwalter als auch Hersteller von MPS auch weiterhin an Informationen über Fehler und deren Ursachen interessiert. Aus diesem Grunde ist auch bei fehlertoleranten Rechnern die Aufzeichnung von wichtigen Systemdaten und deren anschließende Auswertung wichtig. Darüberhinaus können Analysen wertvolle Hinweise auf vorhandene Schwächen im Hardwaredesign liefern; diese Erkenntnisse können bei Weiter- oder Neuentwicklungen von Computersystemen genutzt werden.
Gegenstand dieser Arbeit ist die Entwicklung einer aktiven Datenbankumgebung, die alle für statistische Fehleranalysen aufschlußreichen Daten aufzeichnet und Fehlerdiagnose und -behebung unterstützt. Es existieren bereits ähnliche Arbeiten, bei denen jedoch nicht alle benötigen Aspekte berücksichtigt wurden. Bei dieser Arbeit erfolgt eine lückenlose Protokollierung von Fehlern, Auslastungs- und Temperaturwerten, Ausfallzeiten und durchgeführten Reparaturen. Um die Einsatzmöglichkeit der Datenbankumgebung für ein weites Spektrum von verschiedenen MPS zu gewährleisten, wurde auf einen weitestgehend hardwareunabhängigen Ansatz geachtet. Die erste Implementierung erfolgte für den Parsytec GC-0.5exel.
Die Arbeit gliedert sich folgendermaßen: Kapitel 2 vermittelt die zum Verständnis des Arbeitsgebietes notwendigen Grundlagen und spiegelt den Stand der Technik wider. Die Ziele und das Gesamtkonzept des ESPRIT-Projekts werden in Kapitel 3 vorgestellt; des weiteren erfolgt die Einordnung der aktiven Datenbankumgebung in das Gesamtkonzept. Kapitel 4 untersucht die an die aktive Datenbankumgebung gestellten Anforderungen und stellt die Realisierung mit Hilfe von Endlichen Automaten und geeigneten Schnittstellen vor. Die Implementierung der aktiven Datenbankumgebung und deren Schnittstellen sind Gegenstand von Kapitel 5. Abschließend erfolgt in Kapitel 6 eine Zusammenfassung der Ergebnisse und ein Ausblick auf mögliche Ergänzungen.
In diesem Kapitel werden wichtige Grundlagen erläutert, die zum Verständnis des Arbeitsgebietes notwendig sind. Hierzu gehört eine Einordnung der betrachteten MPS in die Klassifikation von Parallelrechnern und die Erläuterung wichtiger Begriffe aus dem Bereich der Fehlertoleranz. Anschließend wird zum einen untersucht, welche Datenquellen für statistische Untersuchungen genutzt werden können, und zum anderen ein bewertender Überblick über bisherige Arbeiten auf diesem Forschungsgebiet gegeben.
Der Erhöhung der Integrationsdichten und der Signalgeschwindigkeit sind natürliche Grenzen gesetzt. Als Ausweg erscheinen massiv-parallele Systeme, bei denen viele parallel arbeitende Komponenten sich die Arbeit an einem Problem teilen (ab ca. 64 Prozessoren [MeS91] ).
Es existieren verschiedene Typen von Rechnern, die sich nach der recht groben Klassifikation von Flynn in folgende vier Klassen einteilen lassen [Fly66] :
Die Klasse SISD besteht aus konventionellen Von-Neumann-Rechnern. Vektorrechner sind Vertreter der SIMD-Klasse. Ein Befehlsstrom steuert mehrere Datenströme. Die parallel zu verarbeitenden Daten werden den einzelnen Prozessoren zugewiesen, die jeweils gleichzeitig auf dieser Datenmenge operieren. Jeder bearbeitet nur einen Teil der Einträge aus der Gesamtdatenmenge. Der Ansatz der nutzbaren Parallelität hängt hierbei unter anderem von der Größe der Datenmenge ab: Je größer das Problem ist, desto mehr Prozessoren können üblicherweise parallel genutzt werden. Diese DatenparallelitätDataParallelismDatenparallelität ist einfach zu verstehen, da nur ein synchroner Datenfluß existiert [BlN92] . Zu dieser Klasse gehören beispielsweise auch die CRAY-Vektorrechner [MeS91] .
Bei Computern der MIMD-Klasse steuern mehrere Befehlsströme mehrere Datenströme. Bei dieser auch als KontrollparallelitätControlParallelismKontrollparallelität bezeichneten Betriebsart wird der Algorithmus in parallele Programmsegmente aufgeteilt, die von unterschiedlichen Prozessoren parallel ausgeführt werden können. Der Grad der nutzbaren Parallelität hängt unter anderem davon ab, wie gut der jeweilige Algorithmus parallelisiert werden kann. Die Entwicklung paralleler Algorithmen ist schwieriger als die herkömmlicher, da unabhängige Kontrollflüsse asynchron miteinander in Wechselbeziehung stehen . Vertreter dieser Klasse sind Computer wie nCUBE3 [BuD92] oder CRAY T3D [Oed93] .
Welchem der beiden Computertypen SIMD oder MIMD im praktischen Einsatz der Vorzug zu geben ist, hängt von vielen Faktoren ab, so mit Sicherheit vom Verhältnis des Preises zur erbrachten Rechenleistung und der Zuverlässigkeit in der Praxis. Zwar überwiegen bei den kommerziell genutzten Supercomputern bislang die SIMD-Systeme [MeS91] , nach Bridges, Kitchel und Wehrmeister in [BKW92]
scheint der Trend neuerdings jedoch hin zu MIMD-Computern zu gehen.
[IMAGE ]
Figure: (a) Multiprozessor- (b) Multicomputersystem
Diese Arbeit beschäftigt sich mit MIMD-Systemen. Diese können in Multiprozessorsysteme und Multicomputersysteme unterteilt werden (siehe auch Bild 2.1). Bei MultiprozessorsystemenMultiprozessorsystemMultiprozessorsystem arbeiten mehrere Prozessoren mit eigener Takterzeugung zusammen. Die Kommunikation der einzelnen Prozessoren erfolgt über SpeicherkopplungSpeicherkopplungSpeicherkopplung. Hierbei können die einzelnen Prozessoren über ein Verbindungsnetzwerk auf einen gemeinsamen Speicher zugreifen (enge Kopplung). Die Kommunikation und Synchronisation erfolgt über gemeinsame Variablen (shared variables).
Bei MulticomputersystemenMulticomputersystemMulticomputersystem bilden Prozessoren und Speicher eine Einheit (PMUPMUPMU = Prozessor Memory Unit). Die einzelnen PMUs kommunizieren mittels Nachrichtenkopplung über ein Verbindungsnetzwerk (lose Kopplung). Bei der NachrichtenkopplungNachrichtenkopplungNachrichtenkopplung erfolgt die Kommunikation über den Austausch von Nachrichten (message passing).
Nach Johnson [Mae91] lassen sich MIMD-Rechner in vier Klassen einteilen, die sich jeweils in der Art des Datenzugriffs und der Datenkommunikation voneinander unterscheiden.
Hierbei können alle Prozessoren auf den globalen Speicher zugreifen. Bei verteiltem Speicher ist dieser im Rechner verteilt (z.B. lokaler Speicher pro Prozessor), wobei alle Prozessoren jedoch eine gemeinsame Sicht des gesamten (globalen) Speicherraums haben.
Im folgenden werden MPS vorgestellt und gemäß der vorgestellten Klassifikationen eingeordnet.
Der im Rahmen dieser Arbeit betrachtete Multicomputer Parsytec GC-0.5exel ist der Klasse MIMD und DMMP zuzuordnen. Er ist in weiten Grenzen skalierbar und und besteht aus bis zu 16.384 Prozessorknoten. Die installierte Rechnerleistung kann so dem Bedarf des Rechner-Betreibers angepaßt werden. Falls eine höhere Rechnerleistung erwünscht ist, kann das System bis zum Maximalausbau erweitert werden. Jeder dieser Knoten beinhaltet neben der benötigten Kontrollogik einen Transputer INMOS T805 mit gesonderten 4MByte lokalen Speicher. Der 32-/64-Bit-Prozessor kann 64 Bit breite Fließkommaoperationen durchführen und unterstützt Parallelität auf Hardwareebene. Über jeden der insgesamt vier bidirektionalen Transputer-Links können Nachrichten mit bis zu 2.35 MBytes/sec zu anderen Kommunikationspartnern übertragen werden.
[IMAGE ]
Figure: Parsytec GCel, globale hierarchische Struktur
Die Komponenten des Parsytec GC-0.5exel sind entsprechend logischer und/oder physikalischer Gegebenheiten in hierarchischer Weise zu Subsystemen zusammengefaßt (siehe hierzu auch Bild 2.2). Acht Prozessoren werden zunächst auf einem Prozessorboard zusammengefaßt, wovon zwei wiederum einen Cluster bilden. Jedem dieser aus 16 Prozessoren bestehenden Cluster wird ein zusätzlicher, als Ersatzkomponente ( Spare) nutzbarer siebzehnter Prozessor zugeordnet. Vier solcher Cluster bilden einen GigaCube (im folgenden auch als Cube bezeichnet), die physikalische Basiskomponente des Rechners. Das Gesamtsystem wird aus bis zu 256 dieser Cubes in einem dreidimensionalen Gitter zusammengesetzt.
Die Nachrichten-Kommunikation der Prozessoren untereinander erfolgt über ein logisch-zweidimensional angeordnetes Verbindungsnetzwerk[+]. Hierzu werden die Transputer-Links in Verbindung mit mehreren Routing Chips INMOS C004 genutzt. Hierbei handelt es sich um programmierbare Kreuzschienenverteiler zwischen 32 eingehenden und 32 ausgehenden Links. Damit lassen sich Link-Verbindungen zwischen zwei beliebigen Transputern herstellen.
Das Kommunikationsnetz des Parsytec GC-0.5exel läßt sich in folgende drei Teilnetze einteilen:
Das Datennetzwerk dient den Programmapplikationen zur allgemeinen Nachrichtenkommunikation zwischen den beteiligten Prozessoren. Ein zusätzliches Kontrollnetzwerk ist der System-Software zur Steuerung des Gesamtsystems vorbehalten. Hierzu gehört das Setzen der Kreuzschienenverteiler und die Steuerung und Überwachung der Hardware. Über das Ein- Ausgabenetzwerk kann das MPS synchrone Kommunikationen mit der Außenwelt unterhalten. Der genaue technische Aufbau des Parsytec GC-0.5exel wird von Tiedt in [Tie92] beschrieben.
Am Ein-/Ausgabenetzwerk werden unter anderem UNIX-Workstations als Front End Computer angeschlossen. Diese bilden die Schnittstelle zwischen dem Benutzer und dem Parsytec GC-0.5exel. Auf dem MPS steht dem Benutzer hierbei die Systemumgebung PARIX[+] zur Verfügung, die unter anderem eine UNIX-kompatible Laufzeit-Bibliothek beinhaltet . Wie auch bei anderen MPS üblich, werden, falls mehrere Benutzer am Parsytec GC-0.5exel arbeiten wollen, die Prozessoren hierzu in mehrere unabhängige Partitionen aufgeteilt.
Bei der von Thinking Machines Corporation hergestellten Connection Machine CM-5 findet man eine Kombination von SIMD und MIMD [PaS92] . Ein spezielles Kontrollnetzwerk ermöglicht die Synchronisierung aller Prozessoren, so daß ihre Instruktionen synchron abgearbeitet werden können. Hierbei können die einzelnen Prozessoren mit gleichartigen (bei SIMD) oder unterschiedlichen Instruktionen (bei MIMD) versorgt werden. Bei der CM-5 kann so je nach Anforderungsprofil die geeignetste Architekturvariante genutzt werden. Als Prozessoren werden SPARC-CPUs verwandt.
Ähnlich wie beim Parsytec GC-0.5exel sind auch bei der CM-5 mehrere Kommunikationsnetze für unterschiedliche Aufgaben vorhanden. Mit dem Datennetzwerk können lose gekoppelte Kommunikationen zwischen zwei Prozessorknoten durchgeführt werden. Das Kontrollnetzwerk mit straff gekoppelten Kommunikationen dient zur Steuerung des Systems. Ein zusätzliches Diagnosenetzwerk kann von der Systemsoftware zu Diagnose- und Fehlertoleranzzwecken genutzt werden.
Bei der CM-5 erfolgt der Nutzungszugang direkt über das auf dem MPS ablaufende Betriebssystem CMOST, eine Erweiterung des Betriebssystems UNIX. Die vorhandenen Prozessoren können in mehrere Partitionen aufgeteilt werden. Auf jeder Partition kann wie unter UNIX üblich gearbeitet werden. Es können hierauf also auch mehrere Programme selbst von unterschiedlichen Benutzern ausgeführt werden .
Es existieren auch Untersuchungen über Mischformen von SIMD und MIMD, bei denen versucht wird, die jeweils positiven Eigenschaften beider Typen zu verbinden. Dies erfolgt beispielsweise mit Autonomous SIMD (ASIMD) bei den Rechnersystemen MasPar MP-1 und MP-2 [BlN92] .
Darüberhinaus besteht die Möglichkeit, mit einen Maschinentyp den jeweils anderen zu emulieren. Hierbei können (durch die Emulation bedingt) Leistungsverluste entstehen [BKW92] .
Unabhängig von ihrem Systemtyp (SIMD oder MIMD) bestehen MPS aus wesentlich mehr Einzelkomponenten als herkömmliche Computer. Hierbei ist -- unter der Voraussetzung, daß die Ausfälle der Einzelkomponenten voneinander unabhängig sind -- die Gesamtausfallrate eines Systems direkt von der Ausfallrate der individuellen Komponenten abhängig.
Die
ÜberlebenswahrscheinlichkeitUeberlebenswahrscheinlichkeitÜberlebens-
wahrscheinlichkeit
[IMAGE ] ist die Wahrscheinlichkeit, daß das System im Zeitintervall
[IMAGE ] fehlerfrei bleibt, unter der Voraussetzung, daß es zum
Zeitpunkt t=0 intakt ist. Bei Parallelrechnern ohne Fehlertoleranz
ergibt sich für p Knoten eine Überlebenswahrscheinlichkeit von
wobei [IMAGE ] die Überlebenswahrscheinlichkeit eines einzelnen Knotens ist [Mae91] .
Unter der Voraussetzung, daß die Komponenten der oben angegebenen Gesetzmäßigkeit folgen und die mittlere Zeit zwischen zwei Ausfällen ( MTTF[+]) bei einem einzelnen Prozessorknoten 10 Jahre beträgt, ergibt sich bei einem System mit 1.024 Knoten eine MTTF von nur 85,5 Stunden. Bei einem MPS mit 16.384 Knoten beträgt die MTTF sogar nur noch 5,3 Stunden.
Aus Gründen der Wirtschaftlichkeit ist es wichtig, daß ein MPS möglichst gut ausgelastet ist und hardwarebedingte Ausfallzeiten durch Teil- oder Totalabschaltungen möglichst vermieden werden. Falls ein Hardwarefehler nicht mehr zu tolerieren und eine Reparatur unumgänglich ist, sollte dies ohne Abschaltung des gesamten Systems möglich sein. Intakte Teilbereiche des MPS können dann weiter an laufenden oder neuen Programmen arbeiten.
Fehlertolerante Systeme FehlertoleranzFehlertoleranz können ihre Aufgaben auch noch mit einer begrenzten Zahl fehlerhafter Teilsysteme erfüllen. Fehlertoleranz wird hierbei durch RedundanzRedundanzRedundanz sichergestellt. Unter Redundanz ist das funktionsbereite Vorhandensein von mehr als den für die vorgesehene Funktion notwendigen technischen Mittel zu verstehen[+] .
Redundanz kann nach der Art ihrer Aktivierung wie folgt unterschieden werden:
Bei der statischen RedundanzStatRedundanzStatische Redundanz erbringen redundante Mittel während des gesamten Einsatzzeitraums eine Funktion. Die jeweiligen Komponenten sind also mehrfach vorhanden. Die Überwachung der korrekten Funktionalität wird entweder durch zusätzliche Komponenten (Komparator) oder durch gegenseitige Überwachung durchgeführt. Diese Methode ist bei MPS, bedingt durch die große Anzahl Einzelkomponenten, jedoch in der Regel zu aufwendig und zu kostspielig.
Bei der dynamischen RedundanzDynaRedundanzDynamische Redundanz werden die redundanten Mittel erst dann aktiviert, wenn eine Einheit ausgefallen ist. Hierbei können verschiedene Methoden unterschieden werden:
Bei der ungenutzten Redundanz sind die Ersatzsysteme ( Spares) bis zur Aktivierung passiv. Dieses Verfahren mit Spare-Komponenten wird beim Parsytec GC-0.5exel angewandt . Bei fremdgenutzter Redundanz übernehmen die Ersatzsysteme Hintergrundaufgaben, die im Fehlerfall verdrängt werden. Bei gegenseitig nutzbarer Redundanz übernehmen die verbleibenden intakten Subsysteme zusätzlich die Aufgaben der defekten. Bei der CM-5 wird diese Methode verwandt.
Die Fehlerbehandlung wird im folgenden auch als Recovery bezeichnet. Bei dynamischer Redundanz kann sie in folgende drei Schritte eingeteilt werden [Mae91] :
Der Fehlerdiagnose und Rekonfiguration muß eine möglichst vollständige Fehlererkennung vorausgehen. Hierbei sollten nicht nur möglichst alle Fehler erkannt werden, sondern auch die Latenzzeit (= Zeitdifferenz zwischen dem Auftreten des Fehlers und der Erkennung) möglichst klein sein. So kann möglichst schnell durch geeignete Maßnahmen (z.B. eine elektronische Isolation der defekten Komponente) eine Ausbreitung des Fehlers im System vermieden werden. Madeira, Rela und Silva untersuchten in [MRS92] Techniken zur Fehlererkennung beim Parsytec GC-0.5exel.
Nach der Fehlererkennung kann beispielsweise durch Start von zusätzlicher Diagnosesoftware auf dem fehlertoleranten System eine genauere Diagnose des Fehlers erfolgen. Das Diagnoseergebnis sollte sowohl die Bestimmung des genaue Fehlerorts als auch eine Einteilung der Fehler in verschiedene Fehlerkategorien umfassen.
Diese Daten sind hilfreich beim nächsten Schritt der Fehlerbehandlung, der Rekonfiguration. Dabei wird das System wieder in eine fehlerfreie Konfiguration versetzt. Die Rekonfiguration kann in folgende drei Phasen unterteilt werden:
Zunächst erfolgt, wenn nicht schon bei der Fehlerdiagnose geschehen, die Ausgliederung der defekten Einheiten aus dem System.
Anschließend können Reserveeinheiten aktiviert werden, die die Aufgaben der defekten und nun ausgegliederten Komponenten übernehmen. Die genaue Vorgehensweise hängt hierbei von der angewandten Technik der dynamischen Redundanz ab. Bei ungenutzter dynamischer Redundanz werden die Ersatzkomponenten anstelle der defekten in das Gesamtsystem eingegliedert. Bei fremdgenutzter dynamischer Redundanz werden Hintergrundaufgaben verdrängt und die so freigewordenen Komponenten übernehmen die Aufgaben der defekten. Bei gegenseitig nutzbarer dynamischer Redundanz übernehmen die verbleibenden intakten Komponenten des Gesamtsystems zusätzlich die Aufgaben der defekten.
In einem weiterem Schritt wird eventuell noch eine Neuzuordnung der Prozesse auf die noch vorhandenen Prozessoren notwendig.
Nach der Rekonfiguration liegt ein fehlerfreies Teilsystem vor. Es kann nun mit dem nächsten Schritt der Fehlerbehandlung, der Fehlerbehebung begonnen werden. Hierbei werden die unterbrochenen Programme in einen fehlerfreien Zustand gebracht, so daß ein Wiederanlauf erfolgen kann. Dabei kann zwischen Vorwärts- und Rückwärtsfehlerbehebung unterschieden werden ([Lap92] , siehe hierzu auch Bild 2.3).
[IMAGE ]
Figure: Vorwärts- und
Rückwärtsfehlerbehebung
Bei der Vorwärtsfehlerbehebung wird versucht, einen fehlerfreien Zustand zu finden, von dem aus das System (oft in einem reduzierten Umfang) weiterarbeiten kann. Hierzu werden normalerweise genauere Kenntnisse der Anwendung benötigt.
Bei der Rückwärtsfehlerbehebung wird das System in einen fehlerfreien Zustand versetzt, in dem es sich bereits vor dem Auftreten des Fehlers einmal befand. Hierzu werden Rücksetzpunkte benutzt. Bei ihnen wird zu bestimmten Zeitpunkten während der Ausführung eines Programms dessen aktueller Zustand gespeichert. Falls es später (beim Auftreten eines Fehlers) erforderlich wird, kann dieser Zustand mit Hilfe des abgespeicherten Rücksetzpunktes wiederhergestellt werden.
Das Anlegen von Rücksetzpunkten kann auf verschiedene Arten durchgeführt werden. Bei der benutzergesteuerten Generierung von Rücksetzpunkten entscheidet der Benutzer des MPS, an welchen Programmstellen er durch den Aufruf einer speziellen Funktion Rücksetzpunkte erzeugen und aufzeichnen läßt. Bei der benutzertransparenten Rücksetzpunkterstellung übernimmt das Betriebssystem oder der Übersetzer die Erstellung von Rücksetzpunkten.
[IMAGE ]
Figure: Rücksetzpunkte und Latenzzeit
Bei der Wahl des Rücksetzpunktes ist zu beachten, daß ein Fehler schon vor dem letzten Rücksetzpunkt aufgetreten sein kann, obwohl er, bedingt durch die Latenzzeit zwischen Auftreten des Fehlers und Fehlererkennung, erst nach dem Rücksetzpunkt erkannt wurde (siehe auch Bild 2.4). Falls dies der Fall ist, muß ein früherer Rücksetzpunkt genutzt werden.
Da MPS aus vielen Prozessoren bestehen, die untereinander kommunizieren, ist ferner darauf zu achten, daß bei der Erstellung von Rücksetzpunkten eine konsistente Rücksetzpunktlinie vorhanden ist. Um ein Blockieren der Prozesse beim Nachrichtenaustausch zu vermeiden, darf dieser nicht durch Prozessor-Kommunikationen unterbrochen werden. Falls dies nicht beachtet wird, kann ein Domino-Effekt auftreten, bei dem bei der Suche einer geeigneten Rücksetzpunktlinie immer weiter auf zeitlich zurückliegende Rücksetzpunkte zurückgegriffen werden muß (siehe auch Bild 2.5). Der Domino-Effekt kann jedoch beispielsweise durch gleichzeitiges globales Anhalten der Partition und anschließendes Abspeichern aller relevanten Daten vermieden werden.
[IMAGE ]
Figure: Domino-Effekt bei Rücksetzpunkten
Fehlerdiagnose, Rekonfiguration und Fehlerbehebung sollten sich nach Möglichkeit automatisch und unbemerkt, also ohne Eingreifen des Systembetreuers oder des Benutzers des betroffenen Programms vollziehen. Dies entlastet den Systembetreuer und beschleunigt den Ablauf der Fehlerbehandlung. Somit können die anderenfalls möglicherweise auftretenden Leistungsverluste des Gesamtsystems vermieden werden. Eine automatische Abwicklung ist vor allem dann von Vorteil, wenn der Systembetreuer, beispielsweise während der Nacht, nicht sofort eingreifen kann. Zum Ablauf der Fehlerbehandlung siehe auch Bild 2.6.
[IMAGE ]
Figure: Fehlerbehandlung
Die Reparatur der defekten Komponenten kann, wenn das Teilsystem nach der Fehlerbehandlung wieder einsatzbereit ist, auf einen späteren, günstigeren Zeitpunkt verschoben werden. Falls beim MPS die defekten Komponenten elektronisch isoliert werden können, kann dies in einer Online-Reparatur geschehen, während der das übrige System weiterarbeitet. Anschließend können die intakten Komponenten wieder in das Gesamtsystem integriert werden. Falls keine Online-Reparatur möglich ist, muß das gesamte System zur Reparatur abgeschaltet werden.
Als Beispiel eines umfassenden Konzepts für Fehlerdiagnose und -behebung kann das in [PaS92] von Palmer und Steele beschriebene fehlertolerante MPS CM-5 dienen. Beim Nachfolgemodell des kommerziell erfolgreichen CM-2 wird der Systembetreuer durch eine Administration Software unterstützt. Ein integrierter Bestandteil ist hierbei das CM-5 Diagnosesystem. Falls Ausfälle entdeckt werden, kann der Systembetreuer den Fehler über ein zusätzliches Kontrollnetz sowohl logisch als auch elektronisch vom restlichen System isolieren. Hierdurch wird zum einen eine Fehlerausbreitung vermieden und zum anderen eine spätere Online-Reparatur ermöglicht. Mit Hilfe gegenseitig nutzbarer dynamischer Redundanz können die verbleibenden intakten Komponenten des Gesamtsystems zusätzlich die Aufgaben der defekten übernehmen. Auf dem System vorhandene Partitionen können hierzu vom Systembetreuer neu partitioniert werden. Anschließend kann durch Rückwärtsfehlerbehebung ein Wiederanlauf der vom Fehler betroffenen Programme erfolgen. Die dazu benötigten Rücksetzpunkte können benutzertransparent in regelmäßigen Abständen oder benutzergesteuert durch den Aufruf geeigneter Systemroutinen erstellt werden.
Die von der Fehlerbehandlung während des Diagnoseablaufs entdeckten Fehler sollten für spätere Fehleranalysen aufgezeichnet und in verschiedene Fehlerklassen eingeteilt werden.
Fehler können nach dem Ort ihres Entstehens in Software- und Hardwarefehler eingeteilt werden. Softwarefehler resultieren aus fehlerhaften Programmen, Hardwarefehler aus einem fehlerhaften Zustand der Hardware. Im Rahmen des ESPRIT-Projekts FTMPS -- und damit auch in dieser Arbeit -- werden ausschließlich Hardwarefehler betrachtet.
Um die Bedeutung der in dieser Arbeit verwendeten Begriffe aufzuzeigen, werden zunächst einige Definitionen wiedergegeben. Sie lehnen sich an die von Laprie in [Lap92] und von Siewiorek und Swarz in [SiS82] beschriebenen Bezeichnungen an.
Einige der in der englischsprachigen Literatur vorkommenden Begriffe bereiten bei der Übertragung ins Deutsche Probleme. So steht den Begriffen fault und error im Deutschen eigentlich nur der Begriff Fehler gegenüber, so daß eine Unterscheidung der beiden Begriffe oftmals nur noch aus dem Kontext möglich wird. Durch die Einführung von Fehlerursache für fault und Fehlerzustand für error kann die Unterscheidung erleichtert werden. Es ergeben sich dann aber Schwierigkeiten bei einigen zusammengesetzten Begriffen. Im Rahmen dieser Arbeit wird der Begriff Fehler benutzt, wenn aus dem Kontext klar hervorgeht, ob von Fehlerursache (fault) oder Fehlerzustand (error) gesprochen wird.
Bei einer Fehlerursache FehlerursacheFehlerursache (fault)faultfault handelt es sich um eine anerkannte oder hypothetische Ursache für einen Fehler. Es handelt sich um einen fehlerhaften Status der Hardware oder Software, resultierend aus Ausfällen (failure) der Komponenten, physikalischen Interferenzen der Umgebung, Systembetreuer-Fehlern (error) oder unkorrektem Design.
Ein FehlzustandFehlzustandFehlzustand (error)errorerror ist die Auswirkung einer Fehlerursache (fault) im Bereich eines Programms oder Datenstruktur. Der Fehlzustand kann hierbei mit einiger Distanz zur Fehlerursache auftreten. Er ist Teil des Systemzustandes, der dafür verantwortlich ist, daß ein Ausfall (failure) auftritt.
Ein AusfallAusfallAusfall (failure)failurefailure ist eine Abweichung der erbrachten Leistung von der in der Systemspezifikation geforderten Leistung, ein Übergang von korrekter zu fehlerhafter Leistungserbringung.
Zusätzlich können Fehler und Ausfälle nach ihrer Dauer unterschieden werden. Fehlerursachen, Fehlzustände oder Ausfälle werden als permanentPermanentPermanent bezeichnet, wenn sie fortlaufend und stabil sind. In der Hardware spiegelt eine permanente Fehlerursache eine unwiderrufliche physikalische Änderung der Hardware wider.
Fehlerursachen oder Fehlzustände werden als temporär bezeichnet, wenn sie von einer punktuellen Bedingung abhängig und daher nur während einer bestimmten Zeit vorhanden sind. Temporäre Fehler lassen sich nochmals in intermittierende und transiente Fehler unterteilen: Temporäre Fehlerursachen oder Fehlzustände werden als intermittierendIntermittierendIntermittierend bezeichnet, wenn sie eine systeminterne Ursache haben, deren Aktivierungsbedingungen nicht reproduziert werden können oder die selten auftreten. (Falls nur Hardwarefehler betrachtet werden, liegt also ein Hardwaredefekt vor.) Temporäre externe Fehlerursachen oder Fehlzustände, die von der physikalischen Umgebung stammen, werden als transientTransientTransient bezeichnet. Hier wird die Hardware beispielsweise durch Strahlung aus der Umgebung derart beeinflußt, daß sie defekt erscheint, obwohl sie für sich genommen intakt ist.
Ausfälle, Fehlerursachen und Fehlzustände bedingen sich gegenseitig. Zu den Quellen von Fehlzuständen siehe auch Bild 2.7.
[IMAGE ]
Figure: Quellen von Fehlzuständen
Diese Abhängigkeiten werden von Laprie auch als fundamentale Kette bezeichnet:
... Ausfall [IMAGE ] Fehlerursache [IMAGE ] Fehlzustand [IMAGE ] Ausfall ...
Ein Ausfall tritt auf, wenn ein Fehlzustand die Schnittstelle zwischen System und Benutzer durchdringt und die Leistung des Systems beeinträchtigt. Diesem Ausfall können Fehlerursachen und in deren Folge wiederum Fehlzustände folgen, für das System, das die ausgefallene Komponente beinhaltet, oder für die Systeme, die mit der ausgefallenen Komponente zusammenarbeiten. Den so erzeugten Fehlzuständen können so weitere Ausfälle folgen. Deshalb muß der Fehler nach seiner Erkennung isoliert werden, um eine weitere Ausbreitung zu verhindern.
Für statistische Untersuchungen von Fehlern und Ausfällen können unterschiedliche Datenquellen genutzt oder erschlossen werden:
Falls bei der Neuentwicklung eines Computersystems nicht schon die Sammlung von Daten für spätere Analysen vorgesehen wurde, liegen die für statistische Untersuchungen interessanten Daten in der Regel nur in begrenztem Umfang vor. Hier kann oftmals nur ein bereits vorhandener Fehlerreport genutzt werden. Dies gilt insbesondere dann, wenn die Daten schon gesammelt sind und auf diesen nachträglich eine Analyse durchgeführt werden soll.
Falls die Sammlung der Daten erst beginnen soll, können bestehende Aufzeichnungsroutinen so modifiziert werden, daß weitere Daten von ihnen gesammelt werden können. Eine andere Möglichkeit ist die nachträgliche Implementierung weiterer Aufzeichnungsmechanismen. Bei diesen Änderungen kann jedoch eine Modifikation des Betriebssystems notwendig werden. Nachträgliche Anpassungen sind aber in der Regel nur für einzelne Systeme und nicht für alle bereits weltweit installierten Systeme möglich.
Günstigere Voraussetzungen für statistische Untersuchungen ergeben sich, wenn bei der Neuentwicklung eines Computersystems die Sammlung von Daten für spätere Analysen schon vorgesehen wurde. Da die Sammlung der benötigten Daten in das Betriebssystem integriert werden kann, kann dies leichter und systemkonformer als bei nachträglichen Systemveränderungen geschehen. Ein zusätzlicher Vorteil ist, daß Daten weltweit bei allen installierten Systemen gesammelt und ausgewertet werden können.
Die Sammlung der Daten sollte hierbei nicht auf die lokale Ebene beschränkt bleiben, sondern alle Daten aller installierten Systeme sollten auch zentral gesammelt und ausgewertet werden können [MGM92,Gra90] . Dieses Verfahren bietet gegenüber den lokalen Einzelsammlungen und Auswertungen folgende Vorteile:
Bei der zentralen Auswertung ist eine größere Datenbasis als bei lokalen Auswertungen vorhanden. Hierdurch kann sich die statistische Sicherheit der einzelnen Analysen erhöhen. Des weiteren können bei einer zentralen Datenbasis die Einzelsysteme auch verschiedener Standorte einfach miteinander verglichen werden. So können Zusammenhänge zwischen dem bei einem Rechner aufgetretenen Fehler und dessen Einsatzumgebungen untersucht werden. Beeinflussende Faktoren könnten beispielsweise verschieden gute Rechnerbetreuungen, unterschiedlich genutzte Programmapplikationen oder vom Standort abhängige Umwelteinflüsse wie die Güte der Stromversorgung sein.
Langzeituntersuchungen können Rückschlüsse darauf geben, wie sich die Hardwarezuverlässigkeit im Laufe der Zeit verändert. Die Zuverlässigkeit kann sich bei einzelnen alternden Rechnern verschlechtern. Andererseits kann sich die über alle vorhandenen Rechner eines Computertyps berechnete Zuverlässigkeit dadurch erhöhen, daß Rechner mit jüngerem Produktionsdatum zuverlässiger sind. Dies kann auf den Einsatz ausgereifterer Einzelkomponenten oder auf eine Verbesserung der Produktion zurückzuführen sein. Auch können kleine Fehler im Design (''Kinderkrankheiten'') nachträglich korrigiert worden sein.
Alle diese Erkenntnisse aus den statistischen Analysen können bei Weiter- oder Neuentwicklungen von Computersystemen genutzt werden.
Im folgenden werden verschiedene Arbeiten, die sich mit der statistischen Analyse von Fehlerdaten befassen, kurz vorgestellt. Hierbei wird sowohl der Analyse-Technik als auch der jeweiligen Methode der Datensammlung besondere Aufmerksamkeit geschenkt.
In [IyR86] wurde von Iyer und Rossetti auf der Basis von systemweit gesammelten Daten beim Stanford Linear Accelerator Center (SLAC) die Abhängigkeit zwischen Auslastung und Fehlern bei den einzelnen Komponenten untersucht.
Der Untersuchungszeitraum an zwei IBM-Systemen (730/168s) betrug drei Jahre. Zur Analyse konnten systemeigene, automatisch generierte Fehlerreports[+] genutzt werden. In ihnen wurden verschiedenste permanente und nichtpermanente Fehler mit Maschinenstatus und Uhrzeit festgehalten. Die Aufzeichnung von verschiedenen Auslastungsdaten erfolgte durch systemeigene Routinen[+], die Daten zur Prozessorauslastung einzelner Programme sowie über die Anzahl der Dateizugriffe und die Auslastung der Ein-/Ausgabegeräte lieferten. Ein zusätzlicher Softwaremonitor[+] zeichnete verschiedene Interruptraten auf.
Vor der eigentlichen Analyse erfolgte eine Zusammenfassung der Daten in einer eigens dafür geschaffenen Datenbank. Zur Aufzeichnung der Auslastungsdaten erfolgte eine Berechnung von Durchschnittswerten über Fünf-Minuten-Intervalle[+]. Bei Fehlern wurden als Auslastungswerte die Werte aus dem letzten Intervall zugrunde gelegt.
Eine Analyse der Daten ergab, daß die Wahrscheinlichkeit CPU-verwandter Fehler mit zunehmender Auslastung steigt. Ein weiteres Resultat war, daß die Wahrscheinlichkeit von CPU-Fehlern hochgradig nichtlinear ist. Die Zuverlässigkeit der CPU verschlechterte sich mit dem Erreichen der vollen Systemauslastung zunehmend. Die Ausfallrate kann nahe der Auslastungssättigung 50--100 mal höher sein als bei niedriger oder moderater Auslastung.
Aus diesem hochgradig nichtlinearen Zusammenhang wurde gefolgert, daß es nicht ratsam ist, ein System im Bereich der maximal möglichen Auslastung zu betreiben.
Die obige Analyse weist die Bedeutung der Systemauslastung für die Anzahl der auftretenden Fehler auf. Aus diesem Grund sollten bei zukünftigen statistischen Analysen auch Auslastungsdaten ermittelt und aufgezeichnet werden.
Chillarege und Iyer untersuchten in [CiI87] Abhängigkeiten zwischen der Fehler-Latenzzeit und der Prozessorauslastung. Die Untersuchung fand an einem VAX-11/780-Rechner unter realen Einsatzbedingungen statt. Hierzu wurde die physikalische Speicheraktivität mit Hilfe eines Hardware-Monitors[+] überwacht, um so die Zeit zwischen dem Auftreten eines Fehlers und seiner Erkennung messen zu können. Die Studie fand heraus, daß ein Zusammenhang zwischen der Prozessorauslastung und der Latenzzeit besteht. Sie variierte mit einem Faktor zwischen zehn und eins zwischen niedriger und hoher Prozessorauslastung.
Diese Untersuchung zeigt, daß bei Untersuchungen zu Zusammenhängen zwischen Fehlerhäufigkeit und Prozessorauslastung auch die Fehler-Latenzzeit berücksichtigt werden muß. Diese kann dadurch verkürzt werden, daß in Phasen, in denen der Prozessor nicht voll ausgelastet ist, in regelmäßigen Abständen Testprogramme zur Überprüfung der Hardware ablaufen. So kann auch, falls gerade keine Programmapplikation läuft oder diese den Prozessor nicht voll auslastet, gewährleistet werden, daß Fehler spätestens vom Testprogramm entdeckt werden.
Morgan, Gaffney, Melody und andere untersuchten in [MGM92] mit Analysen bei VAX-Computern ebenfalls Abhängigkeiten zwischen Fehlerhäufigkeiten und Systemauslastung. Als Grundlage dienten gesammelte Daten von annähernd zwei Millionen Maschinen-Laufzeitstunden bei bis zu 600 Systemen von 300 Kunden. Hierbei sind alle seit 1985 gebauten VAX-Maschinentypen eingeschlossen.
Die Sammlung aller Daten erfolgte in einer zentralen, eigens dafür geschaffenen ESRI-Datenbank[+] unter Nutzung von Digitals relationalem Datenbankprodukt (Rdb/VMS). Der hochgradig automatisierte Sammelvorgang benötigt nur minimale Eingriffe der Systembetreuer. Es wurden Fehlerlogs, Systemkonfiguration, Modulreparaturdaten, Kundenservicemaßnahmen und teilweise Verbrauchsdaten sowie bei Systemabstürzen Speicherauszüge (Dumps) festgehalten (Bild 2.8).
[IMAGE ]
Figure: ESRI-Datenbank bei VAX-Computern
Es erfolgten Untersuchungen zur Auslastung des Rechners, zu Gründen für Abstürze, zu Abhängigkeiten zwischen einzelnen Fehlern und von Systemabstürzen voneinander. Ebenfalls wurden Langzeitstudien durchgeführt, und es wurde untersucht, wie sich die Hardwarezuverlässigkeit im Laufe der Zeit veränderte. Ergebnisse dieser Analysen flossen in die Entwicklung des Rechners VAX9000 und des fehlertoleranten Rechners VAXft9000 ein.
Der oben dargestellte Ansatz unterstreicht die nutzbringende Sammlung von Daten eines großen Anteils aller produzierten Rechner einer Produktfamilie in einer gemeinsamen zentralen Datenbank. Die Leistungsfähigkeit der genutzten Datenbank ist bei der Auswertung und Sammlung der Daten ein wichtiger Gesichtspunkt. Um nicht nur einen Teil, sondern alle installierten Rechner erfassen zu können, sollte die Sammlung der benötigten Daten schon bei der Entwicklung zukünftiger Computersysteme berücksichtigt werden.
Gray nutzte bei seinen in [Gra90]
durchgeführten Untersuchungen als Datenquelle das von Tandem eingeführte Nachrichten-Sende-System[+] Early warning Report (EWR). Beim EWS werden beim Kunden aufgetretene Hardware- oder Softwarefehler Tandem gemeldet. Im Jahr 1989 waren von insgesamt etwa 2000 Tandem-Kunden 267 an dieses System angeschlossen.
Zur Sammlung und Analyse der im Zeitraum zwischen 1985 und 1990 gesammelten Daten nutzte Gray zunächst eine Tabellenkalkulation. Ab 1989 setzte er wegen der großen Datenmenge eine Datenbank mit der Datenbank-Abfragesprache SQL[+] ein.
Tandem-Systeme setzen sich normalerweise aus vier Prozessoren, größere Systeme aus 16 Prozessoren zusammen. Systeme mit mehr als 16 Prozessoren (es existieren auch solche aus über 100 Prozessoren) werden in Subsysteme zu je zehn Prozessoren unterteilt. Ein System kann hierbei einen Fehler tolerieren.
Eine alle verschiedenen Tandem-Systeme umfassende Analyse ergab für 1989 eine mittlere Zeit bis zu einer Fehlerursache MTBF[+] von 21 Jahren. Softwarefehler waren mit 62% gefolgt von 15% Fehlern bei Systemoperationen der Hauptgrund der gemeldeten Ausfälle. Gray schloß hieraus, daß zum einen Software-Fehlertoleranz angebracht ist, zum anderen der Systembetreuer durch weitgehende Automatisierung und Vereinfachung seiner Aufgaben entlastet und Systemoperator-Fehler toleriert werden sollten.
Ähnlich wie bei der bei VAX-Rechnern eingesetzte ESRI-Datenbank werden auch beim EWS Daten vieler einzelner Tandem-Systeme zu einer zentralen Datenbank zusammengefaßt. Auch dieses Beispiel macht deutlich, daß zur Auswertung der Daten eine leistungsfähige Datenbank genutzt werden sollte. Durch das automatisierte Versenden der Reports per Electronic Mail zu einem zentralen Sammelpunkt wird sichergestellt, daß auch alle Daten in die zentrale Datenbank aufgenommen werden.
In [LIT91] beschreiben Lee, Iyer und Tang, wie mit Hilfe einer als Correlation Analysis bezeichneten Technik Abhängigkeiten zweier beliebiger Ereignisse voneinander bestimmt werden können. Mehrfachabhängigkeiten einzelner beliebiger Ereignisse untereinander wurden mit Hilfe der beiden als Factor Analysis und Cluster Analysis bezeichneten Techniken untersucht.
Als Datengrundlage dienten automatisch aufgezeichnete Ereignis-Reports von drei Tandem-Maschinen. Der Untersuchungszeitraum betrug bei den zwei Tandem-VLX-Systemen sieben Monate und bei einem Tandem-Cyclone fünf Monate. Die Reports stammen aus Tandems Diagnosesystem TMDS[+] unter Tandems Betriebssystem GUARDIAN.
Ergebnis war unter anderem die Aufdeckung von zwei verschiedenen Fehlerklassen: isolierten Einzelfehlern und Sequenzen zusammengehöriger Fehler. Beispielsweise können sich Fehler bei gemeinsam genutzten Ressourcen, etwa einer Platte oder einem Plattencontrollers, derart fortpflanzen, daß mehrere Prozessoren oder Programme hiervon betroffen werden.
Mit Hilfe der oben beschrieben statistischen Analysen können Abhängigkeiten einzelner Fehler voneinander entdeckt werden. Dieses Wissen kann bei Weiter- oder Neuentwicklungen von Computersystemen und bei Strategien zu Vermeidung der Fehlerausbreitung berücksichtigt werden.
Ein automatisches Analyseverfahren, welches versucht, bei IBM-3081-Systemen und an CYBER-Systemen (Modell 174 und 175) intermittierende Ausfälle von transienten Ausfällen zu unterscheiden, wird in [IIY90] von R.K. Iyer, P.V. Krishna Iyer und L.T. Young beschrieben. Beim IBM-System wurde der systemeigene, automatisch generierte Fehlerreport[+], bei den CYBER-Systemen ein Tagesprotokoll des Systems[+] genutzt. Bei den automatischen Analysen wurden diese Rohdaten einer vierstufigen Behandlung durch statistische Verfahren zugeführt. Am Ende dieses Verfahrens liegen transiente und intermittierende Ausfälle als getrennte Fehlerklassen vor.
Mit diesem recht aufwendigen Verfahren können zum einen Fehler in verschiedene Fehlerklassen eingeteilt, zum anderen auch transiente und intermittierende Ausfälle voneinander getrennt werden. Wegen seines großen Rechenaufwands dürfte dieses Verfahren eher für nachträgliche Analysen geeignet sein.
In [LiS90] wird von Lin und Siewiorek beschrieben, wie an der Carnegie Mellon University an 13 VICE-Fileservern der Marke SUN (2/170 und 3/280) eine als Dispersion Frame Technique (DFT) bezeichnete Technik erfolgreich eingesetzt werden konnte. Hierzu wurden während des 22 Monate dauernden Untersuchungszeitraums automatisch generierte Fehlerreports genutzt.
Mit Hilfe der DFT konnten intermittierende Fehler entdeckt und Ausfälle mit einer hohen Erfolgsrate (93,7%) richtig vorhergesagt werden. Sie benutzt hierzu fünf einfache Regeln, die jeweils nur zwischen drei und fünf zurückliegende Ereignisse der gleichen Ausfallcharakteristik benötigen. Andere Techniken benötigen mitunter für eine Analyse mehr Ereignisse (25 bis 113) und haben auch eine niedrigere Erfolgsquote (60% bis 85%).
Da die DFT nur wenige Daten und Regeln benötigt und deshalb auch Analysen in kürzester Zeit durchgeführt werden können, kann sie auch schon zur ersten Fehlerklassifikation während der Fehlerdiagnose herangezogen werden.
Die oben betrachteten Arbeiten benutzen je nach Zielrichtung der jeweiligen Untersuchung unterschiedliche Techniken und Methoden. Um eine günstige Ausgangsbasis für statistische Analysen zu erhalten, ist die Sammlung aller aufschlußreichen Daten notwendig. Welche Daten wichtig sein können, wurden in den obigen Beispielen erwähnt. Insbesondere sollten auch Auslastungsdaten gesammelt werden.
Bei der ESRI-Datenbank bei VAX-Rechnern oder der EWS-Datenbank bei Tandem-Systemen wird ein großer Teil aller installierten Systeme erfaßt. Die Daten werden zur Auswertung zentral in einer leistungsfähigen relationalen Datenbank gesammelt. Gerade bei großen Systemen ist die Leistungsfähigkeit der Datenbank von entscheidender Bedeutung. Um wirklich alle installierten Systeme einer Rechnerfamilie zu erfassen, ist es unumgänglich, dies schon bei der Entwicklung zu berücksichtigen.
Im folgenden werden das ESPRIT-Projekt FTMPS und dessen Ziele kurz vorgestellt. Um die Bedeutung und die Aufgaben der aktiven Datenbankumgebung innerhalb dieses Projekts besser einstufen zu können, werden anschließend kurz das Gesamtkonzept des Projekts und die Aufgaben der aktiven Datenbankumgebung beschrieben.
Das ESPRIT-Projekt 6731 A Practical Approach to Fault-Tolerant Massively Parallel Systems (FTMPS) beschäftigt sich mit der Erstellung von Konzepten und Systemsoftware zur Erbringung von Fehlertoleranz bei massiv-parallelen Systemen. An diesem im August 1992 mit einer Laufzeit von drei Jahren gestarteten Projekt sind folgende Partner beteiligt: Universidade de Coimbra (Portugal), Katholieke Universiteit Leuven (Belgien), Universität Erlangen-Nürnberg (Deutschland), Universität Gesamthochschule Paderborn (Deutschland), British Aerospace (Großbritannien) und Parsytec Computer (Deutschland).
Das Projekt umfaßt einen globalen Ansatz, der von der Fehlererkennung und -diagnose über die Rekonfiguration bis hin zu Statistiken des Systems reicht. Dieser Ansatz wurde mit einer auf Rücksetzpunkten basierenden Rückwärts-Fehlerbehebung kombiniert.
Ein wesentliches Ziel der Entwicklung der Software des FTMPS-Projekts ist eine weitgehende Hardwareunabhängigkeit. Diese soll über die Entwicklung eines vereinigenden Systemmodells (Unifying System Model), das eine große Klasse von parallelen Systemen überdeckt, erreicht werden [BKU93] . Da die Software auf dieses Modell aufbaut, kann sie ohne grundlegende, Änderungen bei allen MPS eingesetzt werden, die sich auf dieses Modell abbilden lassen.
Eines der ersten Zielsysteme, auf dem dieser Ansatz getestet werden soll, ist der Parsytec GC-0.5exel. (Siehe auch Abschnitt 2.1 und die technische Beschreibung [Tie92] von Frank Tiedt.)
Das vereinigende Systemmodell, das die Hardwareunabhängigkeit der FTMPS-Software sicherstellen soll, besteht mit dem C-Net und dem D-Net aus zwei logischen Teilen.
Im C-Net, dem Kontrollnetzwerk des MPS, liegen alle Komponenten, die zur Steuerung des Rechners benötigt werden. Das C-Net kann nochmals in einen globalen und und einen lokalen Teil unterteilt werden. Der globale wird von allen Partitionen des Rechners gleichzeitig benutzt, während der lokale Teil für die jeweiligen einzelnen Partitionen zuständig ist.
Das D-Net umfaßt die Menge aller Komponenten, die für den Ablauf der Benutzerapplikation benötigt werden. Mehrere Knoten können zu Rekonfigurationseinheiten (RE) zusammengefaßt werden, die jeweils eine oder mehrere Ersatzkomponenten enthalten. Eine RE ist die kleinste Einheit, die bei der Konfiguration des Systems genutzt werden kann. Die Topologie der RE ist hierbei nicht genau festgelegt, so daß sie der aktuellen Hardware-Plattform angepaßt werden kann.
Das Gesamtsystem der FTMPS-Software setzt sich aus mehreren Einzelmodulen zusammen (Bild 3.1).
[IMAGE ]
Figure: FTMPS-Projekt
Die Fehlererkennung Error Detection (ED) ist im MPS für die Erkennung aufgetretener transienter und permanenter Fehler zuständig [ABB93] . Hierbei kann zwischen hardware- und softwareunterstützten Maßnahmen unterschieden werden. Beim Parsytec GC-0.5exel sind im Speicher auf Hamming-Codes basierende Fehlererkennungs- und -korrekturverfahren ( EDC = Error Detection and Error Correction Code) installiert. Es werden hierbei acht redundante Bits für jedes 64 Bit-Wort genutzt. Hiermit können Einzelbitfehler korrigiert und Zwei-Bit-Fehler sicher, Mehrfach-Bit-Fehler zu einem großen Teil erkannt werden.
Netzwerkkommunikationen werden mit Parity-Bits überprüft. Zusätzlich erfolgt eine Kontrolle, ob Link-Verbindungen unterbrochen oder gestört werden.
Diese Maßnahmen werden von softwareunterstützte Vorkehrungen begleitet. Der Programmkontrollfluß wird überwacht, und zusätzliche Instruktionen zum Erkennen von falschen Programmverzweigungen ( ECI = Error Capturing Instructions) werden dem Anwenderprogramm hinzugefügt. Um Komponentenausfälle (insbesondere Prozessorausfälle) zu bemerken, generieren sogenannte Wachdog-Timer-Prozesse in periodischen Abständen Kontrollnachrichten ( I-am-alive-Messages).
Das Diagnosemodul Diagnosis (DIAG) empfängt die Meldungen der Fehlererkennung. Eine weitere Aufgabe ist die Überprüfung der von der Fehlererkennung generierten Kontrollnachrichten. Falls die Kontrollnachrichten einer Komponente ausbleiben, kann auf einen Ausfall geschlossen werden. Aus diesen Daten erstellt das Diagnosemodul eine genaue Fehlerdiagnose.
Es wird versucht, den Fehler zu klassifizieren und seinen genauen Ort zu ermitteln, wobei auch intermittierende Fehler erkannt werden sollen. Zur Diagnose werden zusätzliche Analyse-Programme gestartet und auch eventuell vorhandene ältere Fehlerreports genutzt. Die Verwaltung der vom Diagnosemodul benötigten und generierten Fehlerreports wird von einer innerhalb der Operator Site Software (OSS) integrierten Datenbank wahrgenommen. Hierüber können die Daten auch später statistisch ausgewertet werden.
Die Ergebnisse der Diagnose werden ebenfalls dem Modul für Rekonfiguration und Wiederanlauf Recovery Controller (RC) mitgeteilt. Dieses ist für die Rekonfigurierung und den Wiederanlauf des Systems nach einem Fehler oder Ausfall zuständig.
Bei der Rekonfigurierung werden defekte Komponenten nach Möglichkeit durch Ersatzkomponenten ersetzt. Die hiervon betroffenen Partitionen und Link-Verbindungen werden den neuen Bedingungen angepaßt. Falls eine automatische Rekonfigurierung nicht möglich ist, wird der Systembetreuer von der Operator Site Software hierüber unterrichtet.
Nach der Rekonfiguration kann mit Hilfe der zuvor zyklisch gesammelten Rücksetzpunkte des Checkpoint Managers (CM) ein Wiederanlauf des Systems erfolgen. Hierbei erfolgt ein Wiederanlauf der durch Fehler betroffenen Programme durch Rückführung in einen vor dem Auftreten des Fehlers bestehenden fehlerfreien Zustand.
Das Modul Monitor Collect (MC) sammelt in regelmäßigen Abständen Auslastungs- und Temperaturdaten der Prozessoren. Die Daten werden zu statistischen Untersuchungen innerhalb der Operator Site Software in einer integrierten Datenbank abgespeichert.
Die Operator Site Software (OSS), die sich in drei Teile aufgliedern läßt (siehe auch Bild 3.2), unterstützt den Systembetreuer (Operator) durch eine grafische Benutzeroberfläche (OPR). Zu ihrer Aufgabe gehört eine Systemvisualisierung des Ist-Zustandes beim MPS, was gerade angesichts der vielen Einzelknoten, aus denen solch ein Rechner besteht, hilfreich ist und dem Systembetreuer die Übersicht erleichtert. Neben der grafischen Darstellung des MPS können zusätzlich Fehlerlisten und Reparaturaktionen aufgelistet und bearbeitet werden.
[IMAGE ]
Figure: OSS
Falls eine automatische Fehlertoleranzbehandlung nicht in vollem Umfang möglich war, wird die FTMPS-Software von der OSS unterstützt. Von der Fehlererkennung unbemerkte Fehler können vom Systembetreuer von Hand nachgetragen werden. Wenn im Fehlerfall eine Rekonfiguration nicht automatisch ablaufen konnte, wird der Systembetreuer darüber informiert, um diese manuell abzuschließen zu können.
Die Verwaltung einzelner Komponenten des Systems (beispielsweise der einzelnen Prozessormodule) und die Aufzeichnung erfolgter Reparaturen sind ebenfalls Bestandteile der OSS. Diese Daten können den Wartungstechniker unterstützen und ebenfalls statistisch ausgewertet werden.
Statistische Auswertungen erfolgen über ein in die OSS integriertes Statistikmodul (STAT), mit dessen Hilfe alle gesammelten Daten ausgewertet und visualisiert werden können. Ergebnisse dieser Analysen können dem Systemverwalter und dem Hersteller des MPS nützliche Informationen liefern.
Die für die statistische Auswertung benötigten Daten werden von der in die OSS integrierten aktiven Datenbankumgebung (ADBE)[+] verwaltet, die auch weitere Module der FTMPS-Software unterstützt.
Die Aufgabe der aktiven Datenbankumgebung ist die Unterstützung der Zuverlässigkeitsanalyse von massiv-parallelen Systemen. Neben der Aufzeichnung von Fehler- und Auslastungsdaten für die statistische Analyse des Statistikmoduls ist auch die Unterstützung der Diagnose- und Recovery-Software Bestandteil der aktiven Datenbankumgebung.
Der Systembetreuer kann über die grafische Benutzeroberfläche der OSS manuell Datenbankeinträge verändern oder hinzufügen. Ebenfalls Bestandteil der aktiven Datenbankumgebung ist die Bereitstellung von Kommunikationsschnittstellen zwischen dieser und den zu unterstützenden Modulen. Diese können hierbei jedoch auch unabhängig von der aktiven Datenbankumgebung zur Kommunikation zwischen beliebigen Modulen des Projekts genutzt werden. Bestandteil der Erstellung der aktiven Datenbankumgebung ist auch die Spezifizierung der von der statistischen Analyse benötigten Datenformate.
Die aktive Datenbankumgebung ist die Schnittstelle zwischen der Gesamtdatenbank und den an diese angeschlossenen Programmodulen. Hierbei besteht die Gesamtdatenbank aus mehreren Teildatenbanken, die teilweise auch miteinander verknüpft sind. Im folgenden wird auch von mehreren Datenbanken oder Datenbankdateien gesprochen.
Mit den Partnern des FTMPS-Projektes wurde ein Ablaufprotokoll vereinbart, wie und in welcher Reihenfolge Daten hinzugefügt, geändert oder abgefragt werden. Die Datenbankumgebung liefert Schnittstellenfunktionen zwischen den Datenbanken und anderen Programmodulen und stellt die Einhaltung des festgelegten Protokolls sicher.
Sie bleibt hierbei jedoch nicht passiv, sondern führt auf Eingaben von außen selbständig Operationen auf den gespeicherten Daten aus und liefert anfallende Ergebnisse wieder ab. Hierbei werden nicht nur Daten ein- und ausgelesen, es finden vielmehr auch Datentransfers zwischen den einzelnen Teilen der Datenbanken statt; in bestimmten Fällen tritt die aktive Datenbankumgebung auch selbständig mit Modulen wie beispielsweise der grafischen Benutzeroberfläche des Systembetreuers in Verbindung.
Vor dem Entwurf der aktiven Datenbankumgebung wurde zunächst untersucht, welche Daten zu statistischen Zwecken oder zur Unterstützung der Fehlertoleranzsoftware gesammelt und verwaltet werden sollen.
Alle Daten werden zunächst am Standort des MPS in lokalen Datenbanken gesammelt. Zur statistischen Auswertung können die Daten aus mehreren lokalen Datenbanken verschiedener Standorte in einer zentralen Datenbank zusammengefaßt werden. Um die Zusammenlegung der Daten zu erleichtern, wurden bei der lokalen und der zentralen Datenbank die gleichen Datensatzstrukturen genutzt.
Bild 4.1 zeigt eine Übersicht der im folgenden beschriebenen, in die aktive Datenbankumgebung integrierten Datenbanken.
[IMAGE ]
Figure: Datenbanken innerhalb der aktiven Datenbankumgebung
In der Datenbank Fehlerprotokoll werden alle von der Diagnose oder vom Systembetreuer erkannten Fehlzustände aufgezeichnet. Zusätzlich werden bei den einzelnen Fehlermeldungen Daten zur Prozessorauslastung und -temperatur aufgezeichnet.
Die gesammelten Daten werden zum einen von der Diagnose selbst wiederum zu Fehlertoleranzzwecken genutzt, beispielsweise um intermittierende Fehler zu ermitteln; zum anderen können die Daten mit statistischen Methoden ausgewertet werden.
Folgende Daten werden in der Fehlerprotokoll-Datenbank aufgezeichnet:
Der Zeitpunkt des Eingangs der Daten in die Datenbank ( TIME_STAMP) wird benötigt, um die zeitliche Reihenfolge des Eingangs der von der Diagnose gelieferten Daten festzuhalten. Da nach dem Erkennen des Fehlers von der Diagnose noch genauere Tests zur Analyse des Fehlers durchgeführt werden, sind der Zeitpunkt der Fehlererkennung ( TIME_STAMP_DIAG) und der Zeitpunkt, in dem der Fehler der Datenbank übergeben wird, nicht notwendigerweise identisch. Wenn ein Fehler nicht von der Diagnose, sondern erst vom Operator entdeckt und eingetragen wurde, können hierbei größere zeitliche Differenzen auftreten.
Aus der Zeitdifferenz zwischen dem Eingang der Daten in die Datenbank und dem Zeitpunkt, zu dem der Fehler von der Diagnose oder dem Operator erkannt wurde, läßt sich bestimmen, wieviel Zeit von der Diagnose oder dem Operator zu genaueren Analysen benötigt wurde.
Ein Eintrag zum Standort des Computersystems ( LOCAL), z.B. Uni-Paderborn, hilft bei der Unterscheidung verschiedener Computersysteme. Diese Information ist hilfreich, wenn Daten aus mehreren lokalen Datenbanken von Systemen unterschiedlicher Standorte in einer zentralen Datenbank zusammengefaßt wurden. Hiermit wird die Zuordnung einzelner Einträge aus der zentralen Datenbank zu den jeweiligen Computerstandorten ermöglicht.
Bei Systemen mit mehreren Verbindungsnetzwerken wird festgehalten, in welchem Netzwerk der Fehler aufgetreten ist ( NETWORK). Beim Parsytec GC-0.5exel existieren mit dem Daten-, dem Kontroll- und dem Ein-/Ausgabenetzwerk beispielsweise drei Netzwerke.
In einem Eintrag ( COMPONENT) wird festgehalten, welche Systemkomponente ausgefallen ist. Beim Parsytec GC-0.5exel existieren beispielsweise als Systemkomponenten Prozessoren, Links, Routing-Chips (C104), Cluster oder Cubes.
Wenn an einem Steckplatz ein Board durch ein anderes ersetzt wird, können mit Hilfe der Board-Identifikationsnummer ( BOARD_ID) Datenbankeinträge, die das alte Board betreffen, von Einträgen unterschieden werden, die das neue Board betreffen.
Die Unterscheidung einzelner Boards ist notwendig, damit Anfragen der Diagnose an die Datenbankumgebung zur Ermittlung von intermittierenden Fehlern korrekt beantwortet werden können. Hierbei werden die Fehler aus der Datenbank ermittelt, die innerhalb eines angegebenen Zeitintervalls bei einer bestimmten Komponente aufgetreten sind. Bei dieser Gelegenheit dürfen jedoch nur Fehlermeldungen beachtet werden, die sich auf das momentan installierte Board beziehen. Ohne Board-Identifikationsnummer würde der Austausch eines Boards für die Datenbank unbemerkt bleiben.
Weiterhin ist eine Unterscheidung einzelner Boards notwendig, um in der Datenbank den von der Diagnose gemeldeten Fehlern die zum aktuellen Board passenden Auslastungswerte und Temperaturdaten hinzufügen zu können.
Mit Hilfe von fünf Koordinaten ( COORDINATES_0 ... COORDINATES_4) kann der Ort des Fehlers im System festgehalten werden. Fünf Koordinaten wurden gewählt, um die einzelnen Komponenten auch in mehreren hierarchischen Stufen durchnumerieren zu können. Beim Parsytec GC-0.5exel setzt sich das Gesamtsystem aus dreidimensional angeordneten Cubes zusammen. Die einzelnen Cubes enthalten wiederum Cluster und diese die einzelnen Prozessoren.
Falls bei anderen Zielsystemen nicht alle Koordinaten benötigt werden, können diese ungenutzt bleiben. Falls das Zielsystem mit mehr als fünf Koordinaten beschrieben wird, können weitere Koordinaten eingeführt oder es kann eine Konvertierung der Koordinatensysteme durchgeführt werden.
In einem Bit-Feld ( LINKNUMBERS) können Fehler für bis zu 32 Kommunikationsverbindungen zu Nachbarknoten verwaltet werden. Beim Parsytec GC-0.5exel werden hiermit defekte Transputerlinks verwaltet.
Der Name der unterbrochenen Programmapplikation ( APPLICATION_NAME) kann Rückschlüsse auf Zusammenhänge zwischen Fehlern und bestimmten Anwendungen liefern. Falls bei einem Programm signifikant mehr Fehler als bei anderen erkannt werden, kann eventuell ein Softwarefehler vorliegen. Hiermit können in begrenztem Umfang grobe Softwarefehler erkannt werden. Es kann sich allerdings auch herausstellen, daß bestimmte Applikationen den Rechner oder bestimmte Teilsysteme mehr fordern.
Im Eintrag ( PROG_MODULE_ID) wird festgehalten, von welchem Modul des FTMPS-Projekts der Fehler gemeldet wurde. Er ermöglicht eine Unterscheidung, ob der Fehler selbständig von der Diagnosesoftware entdeckt wurde oder ein zusätzlicher Eintrag vom Systemoperator erfolgte. Dies ist bisweilen erforderlich, da nicht davon auszugehen ist, daß alle Fehler von der Diagnose erkannt werden.
Im Eintrag zum Fehlertyp FAILURE_TYPE wird der Typ des Fehlers festgehalten. In Frage kommen hierbei transiente, intermittierende[+] und permanente Fehler. Ein zusätzliches Hilfsfeld ( NEW_FAILURE_TYPE) wird von der Diagnosesoftware verwendet, um nachträglich erkannte intermittierende Fehler markieren zu können.
Die durchschnittliche Auslastung ( AVERAGE_LOAD) seit Installation der fehlerhaften Komponente und der momentane Auslastungswert kurz vor dem Auftreten eines Fehlers ( LOAD_AT_ERROR) werden in zwei getrennten Einträgen festgehalten. Hiermit lassen sich Zusammenhänge zwischen Auslastung und Ausfall von Komponenten analysieren.
In zwei weiteren Einträgen werden die durchschnittliche Temperatur seit der Installation der fehlerhaften Komponente ( AVERAGE_TEMPERATURE) und die Temperatur kurz vor dem Auftreten eines Fehlers gespeichert ( TEMPERATURE_AT_ERROR). Mit Hilfe dieser Daten können Analysen zu Zusammenhängen zwischen Temperaturdaten und Fehlern durchgeführt werden. Beim Parsytec GC-0.5exel existiert für jeden Prozessor ein Temperatursensor.
Vom Operator kann zusätzlich ein Kommentar ( COMMENT) eingetragen werden, um nähere Umstände des vorgefallenen Ereignisses zu erläutern.
Um auch Auslastungsdaten in das Fehlerprotokoll aufnehmen zu können, existiert die Datenbank Auslastungsdaten, in der zu jedem Prozessor sowohl die aktuelle Auslastung innerhalb des letzten Meßintervalls als auch die durchschnittliche Auslastung seit der Installation des Prozessors abgespeichert ist. Die Daten stammen von einem Monitor-Programm, das Auslastungs- und Temperaturdaten ermittelt. Die Daten werden in dieser Datenbank jeweils zyklisch aktualisiert, so daß bei der Erzeugung eines Eintrags für das Fehlerprotokoll diese sofort aus dieser Datenbank gelesen werden können. Speziell für den Parsytec GC-0.5exel werden die Daten Cube für Cube in den folgenden Datenstrukturen verwaltet:
Für jeden der 64 Prozessorknoten eines Cubes werden folgende Daten aufgezeichnet[+]:
Zur Berechnung des arithmetischen Mittelwertes werden jeweils die Anzahl der Meßintervalle und die kumulierten Auslastungswerte festgehalten. Die durchschnittliche Auslastung errechnet sich als Quotient aus den kumulierten Auslastungswerten und der Anzahl der Meßintervalle. Falls zusätzlich zum arithmetischen Mittelwert seit der Installation der Komponenten weitere Mittelwerte berechnet werden sollen, kann die Datenbank leicht erweitert werden.
Um ermittelte Temperaturdaten bereitstellen zu können, ist analog zur Datenbank für Auslastungsdaten eine Datenbank mit Temperaturdaten geplant.
Bei der Rekonfiguration benötigt die Recovery-Software Informationen darüber, welche Komponenten schon als defekt ausgegliedert wurden und welche Komponenten, einschließlich der Ersatzkomponenten, noch einsatzbereit sind. Hierzu dient die Datenbank aktuelle Ausfälle. Falls keine Ersatzkomponenten mehr vorhanden sind, entscheidet die Recovery-Software, ob hierdurch bedingt ein noch größeres Subsystem ausfällt. Wenn beispielsweise beim Parsytec GC-0.5exel innerhalb eines Clusters für einen ausgefallenen Prozessor kein Ersatzprozessor mehr bereitsteht, ist der gesamte Cluster nicht mehr einsatzbereit. Das Resultat wird erneut in der Datenbank aktuelle Ausfälle abgelegt. Diese von der Rekonfiguration produzierten und benötigten Daten werden getrennt nach Verbindungsnetzwerken gesammelt. Beim Parsytec GC-0.5exel existieren getrennte Datenbanken für das Daten- und das Kontrollnetzwerk:
Die Bedeutung der einzelnen Einträge wurde schon zuvor beim Fehlerprotokoll erläutert.
Zusätzlich werden bei der Rekonfiguration Informationen darüber benötigt, welche Partitionen im MPS vorhanden sind und aus welchen Knoten diese bestehen. Ergänzt werden diese Daten durch eine Zuordnung zwischen den logischen und den physikalischen Knoten des Systems und dem Namen der auf der jeweiligen Partition ablaufenden Applikation. Diese Zuordnung wird auch als Mapping bezeichnet. Hierzu existiert eine aus zwei Teilen bestehende Datenbank, in der alle Partitionen und deren Ausnahmen vom normalen, fehlerfreien Zustand aufgezeichnet sind[+]. Die Rekonfiguration sorgt für die Aktualisierung der Mapping-Daten. In der folgenden Teildatenbank Mapping-Ausnahmen werden die vorhandenen Partitionen abgespeichert:
Die Größe und Form der einzelnen Partitionen wird durch zwei Eckpunkte mit den Koordinaten PART_BEGIN_COORD_0 bis PART_BEGIN_COORD_5 und PART_END_COORD_0 bis PART_END_COORD_5 festgelegt[+].
Der Eintrag P_EXEP_LIST beinhaltet einen Verweis auf das erste Listenelement mit Abweichungen vom Normalzustand. Die Abweichungen vom fehlerfreien Mapping werden als Liste in der folgenden Teildatenbank Mapping-Ausnahmen-Liste verwaltet:
Die Liste der Abweichungen wird mit Hilfe des Eintrags P_NEXT aufgebaut, der -- falls vorhanden -- auf ein weiteres Listenelement zeigt. Für diese Hinweise wird die eindeutige Seriennummer des Datensatzes genutzt, über die der Datensatz auch gesucht werden kann. In jedem Listenelement wird einer Komponente mit der logischen Nummer LOG_NR eine neue physikalische Nummer PYS_NR zugeordnet, die in der Regel die Ersatzkomponente bezeichnet. Der Eintrag P_BELONG_TO_APPLIC stellt eine Rückwärtsverkettung zum Datensatz der Teildatenbank mit den Partitionsdaten dar.
Die Datenbank Reparaturen dient zur Aufzeichnung durchgeführter Reparaturen und Diagnosen, deren Daten vom Systembetreuer eingegeben werden müssen. Sie sind auch notwendig, um statistische Daten wie MTTF[+] oder MTTR[+] korrekt ermitteln zu können. Es werden folgende Daten festgehalten:
Die Bedeutung einiger Einträge wurde schon zuvor beim Fehlerprotokoll erläutert.
Der Eintrag MODULE beinhaltet eine Modulbezeichnung, an der die Aktion stattfindet. Dieser Eintrag hängt weitestgehend vom verwendeten Zielsystem ab, insbesondere vom Grad seines modularen Aufbaus.
Beim Austausch von Modulen werden sowohl die Board-Identifikationsnummer ( BOARD_ID) des zu ersetzenden Moduls als auch die des Ersatzmoduls ( NEW_BOARD_ID) festgehalten.
In einem Eintrag ( ACTION) wird die durchgeführte Aktion festgehalten. Neben der Reparatur und dem Austausch einzelner Komponenten gibt es auch die Möglichkeit, Systemabschaltungen und anschließende Systemneustarts der von der Reparatur oder Wartung betroffenen Teilsysteme festzuhalten. Nicht in dieses Schema passende Aktionen werden unter ''Sonstiges'' abgespeichert.
Alle installierten Boards und deren Identifikationsnummern ( BOARD_ID) werden in der Datenbank aktuelle Boards verwaltet. Mit ihrer Hilfe kann sich der Wartungstechniker jederzeit einen Überblick darüber verschaffen, welche Boards gerade im System installiert sind. Die Daten aus dieser Datenbank werden auch im Zusammenhang mit einer im Anschluß noch beschriebenen Datenbank ( sonstige Boards) benötigt. In der Datenbank aktuelle Boards werden folgende Einträge zur Verfügung gestellt:
Am Standort vorhandene, aber momentan nicht im System installierte Boards werden in der Datenbank sonstige Boards verwaltet. Dies können Boards sein, die sich gerade in Reparatur befinden oder als Ersatz bereitstehen. Auch diese Datenbank hilft dem Wartungstechniker, die Übersicht zu bewahren.
Der primäre Zweck dieser Datenbank besteht jedoch darin, die bisher im System gesammelten Auslastungs- und Temperaturwerte festzuhalten. Die Datenbanken Auslastungsdaten und Temperaturdaten beinhalten nur jeweils die Daten der momentan im System installierten Boards. Falls ein Board aus dem System herausgenommen wird, werden diese Daten und die Daten aus der Datenbank aktuelle Boards in der Datenbank sonstige Boards festgehalten.
Bei einer erneuten Installation eines in der Datenbank sonstige Boards erfaßten Boards werden diese Daten den Datenbanken zu Auslastungs- und Temperaturdaten übergeben. Anschließend wird das Board erneut in der Datenbank aktuelle Boards erfaßt.
Die Datenbank sonstige Boards beinhaltet folgende Einträge:
Für die Sammlung von statistischen Daten zur Rücksetzpunkterstellung ist eine weitere Datenbank vorgesehen. Hiermit können beispielsweise Analysen der Häufigkeit und des zeitlichen Verhaltens der Rücksetzpunkterstellung gemacht werden.
Nach der Untersuchung, welche Daten gesammelt werden sollen, erfolgte eine Anforderungsanalyse an die von der aktiven Datenbankumgebung zu verwendende Datenverwaltung.
Die Entscheidung, ob zur Verwaltung der anfallenden Daten ein schon vorhandenes Datenbankprogramm benutzt werden sollte oder ob die Daten von einer eigens zu programmierenden Dateiverwaltung verwaltet werden sollten, fiel zugunsten der fertigen Datenbank aus. Ein Datenbankprogramm bietet gegenüber einer einfachen, selbstprogrammierten Dateiverwaltung mehrere Vorteile: Die Datensätze einer Datenbank können leicht erweitert oder verändert werden, um zusätzliche Einträge aufnehmen zu können; bei Datenabfragen zu Fehlertoleranzzwecken und insbesondere bei statistischen Analysen bieten Datenbanken den Vorteil, daß auch kombinierte Abfragen leicht realisiert werden können. Eine derartige kombinierte Abfrage ist beispielsweise eine Abfrage aller im Fehlerprotokoll vorhandenen permanenten Prozessorfehler aus dem Datennetz innerhalb der letzten Woche. Hierbei werden bei der Ermittlung der angeforderten Datensätze die vier Datenbankfelder FAILURE_TYPE, COMPONENT, NETWORK und TIME_STAMP genutzt.
Eine eigene Dateiverwaltung oder sogar Datenbank zu kodieren, die diesen Ansprüchen genügt, wurde angesichts der Tatsache, daß den Anforderungen entsprechende Datenbanken auf dem Markt verfügbar sind, als zu aufwendig erachtet.
Bei der Betrachtung der Anforderungen an die Datenbank bezüglich der bereitzustellenden Datentypen (siehe Abschnitt 4.1) ergab sich, daß es sich bei den meisten Datenbankfeldern um Festkommazahlen handelt. Diese werden auch für die Aufnahme von Aufzählungstypen der Programmiersprache C genutzt. Bei den Auslastungs- und Temperaturwerten werden Fließkommazahlen verwendet. Kommentare werden als Zeichenketten abgespeichert.
Über die Bereitstellung geeigneter Datentypen hinaus sollte eine Datenbank noch weiteren Ansprüchen gerecht werden. Neben Schnelligkeit und einfacher Erweiterbarkeit ist bei der Anbindung einer Datenbank an eigene Programmodule das Vorhandensein einer Schnittstelle zur verwandten Programmiersprache (hier C bzw. C++) von Wichtigkeit.
Falls -- wie im FTMPS-Projekt -- teilweise gleichzeitig mehrere Programme auf ein und dieselbe Datenbank zugreifen sollen, sind Maßnahmen zur Wahrung der Datenkonsistenz notwendig. Vorteilhaft ist eine Datenbank, die gemäß dem Client-Server-Modell arbeitet. Hierbei übernimmt ein Datenbank-Dienstprogramm (der Server) die Verwaltung aller Daten und stellt Dienste zur Verfügung. Diese können dann von Klienten-Programmen (den Clients) genutzt werden. Hierbei kann der Datenbankserver auch auf einem anderen Computer ablaufen als die dessen Dienste nutzenden Clients.
Für schnelle und umfassende Abfragen sollte eine Abfragesprache wie SQL[+] vorhanden sein. Hierbei handelt es sich um eine standardisierte Sprache, mit deren Hilfe in Datenbanken Daten ergänzt oder abgefragt werden können. Mit ihr lassen sich auch kombinierte Abfragen leicht verwirklichen. Hierdurch wird auch das die Datenbank nutzende Programm entlastet, da keine mehrstufigen Auswahlverfahren zur Ermittlung der benötigten Daten selbst programmiert werden müssen. Ferner wird die Erweiterung schon bestehender Programmteile hierdurch vereinfacht, was insbesondere bei statistischen Analysen von Vorteil ist.
Hinzu kommt, daß eine Datenbank-Abfragesprache die Möglichkeit bietet, Abfragen und Modifikationen ohne weitere Hilfsprogramme durchzuführen. Ein direkter Zugang zur Datenbank über SQL bietet die Möglichkeit, schnell und ohne größeren Aufwand Abfragen starten zu können, die bei der Realisierung des Analyseprogramms nicht berücksichtigt wurden. Dies kann notwendig werden, falls an eine bestimmte Abfragemöglichkeit bei Erstellung des Analyseprogramms noch nicht gedacht wurde oder sich die Notwendigkeit einer bestimmten Abfragemöglichkeit bei Erstellung des Analyseprogramms noch nicht ergab.
Die aktive Datenbankumgebung wurde mit Hilfe mehrerer gekoppelter Endlicher Automaten (EA) realisiert. Bei Endlichen Automaten können die einzelnen Schritte des mit den anderen Partnern des FTMPS-Projektes festgelegten Ablaufprotokolls direkt in die entsprechenden Automatenzustände und deren Zustandsübergänge umgesetzt werden. Die Ablaufstruktur des Endlichen Automaten ist gemäß dem festgelegten Protokoll entwickelt worden. Bedingt durch die strukturellen Ähnlichkeiten können später eventuell notwendig werdende Änderungen des Ablaufprotokolls leicht auf die einzelnen Endlichen Automaten übertragen werden.
Da mehrere parallel ablaufende Programmodule Zugriff zur aktiven Datenbankumgebung benötigen, wurden ebenfalls mehrere parallel ablaufende Endliche Automaten realisiert. Diese Vorgehensweise vereinfacht die Implementierung der Datenbankumgebung und läßt sich leicht erweitern. Falls ein neues Programm mit Zugriff zur Datenbank installiert werden soll, braucht in diesem Fall nur ein weiterer Endlicher Automat erstellt zu werden.
Notwendige Synchronisationen der Endlichen Automaten untereinander erfolgen über Datenkommunikationen zwischen den Automaten.
Abfragen an die Datenbankumgebung vom Systembetreuer (OPR) und dem Statistikmodul (STAT) wurden nicht als Endlicher Automat realisiert. Darüberhinaus wurden diese Module nicht als eigenständige Programme, sondern als Library implementiert.
[IMAGE ]
Figure: Module der aktiven Datenbankumgebung
Wie aus der Übersicht in Bild 4.2 zu ersehen, besteht die Datenbankumgebung aus folgenden Einzelprogrammen:
Dieser Automat sammelt Daten für den Fehlerreport. Er steht dazu mit dem Diagnosemodul (DIAG), dem Recovery Controller (RC), dem Systembetreuer (OPR) und innerhalb der Datenbankumgebung mit dem sogenannten Stress Value Handler (SVH) in Verbindung.
Mit Hilfe dieses Automaten werden Auslastungsdaten gesammelt, in die benötigten Formate konvertiert und in entsprechende Datenbanken eingetragen. Der SVH erhält die Daten zyklisch von den Modulen Monitor Collect (MC) und Temperatur Collect (TC).
Dieser Automat verwaltet Reparaturaktionen, die ihm vom Systembetreuer (OPR) gemeldet werden.
Er ist vorgesehen, um statistische Daten über die Rücksetzpunkterstellung aufzunehmen. Die Daten werden vom Checkpoint Manager (CM) geliefert.
Über dieses als Library realisierte Modul werden Anfragen des Statistikmoduls (STAT) behandelt.
Über dieses ebenfalls als Library realisierte Modul werden Anfragen des Systembetreuers (OPR) behandelt;
Ein zusätzliches Kontrollprogramm startet sowohl alle zur Datenbankumgebung gehörenden Programme als auch die an diese angeschlossenen Module. Zusätzlich gewährleistet es bei einem durch einen Programmfehler bedingten Abbruch die kontrollierte Beendigung aller anderen Modulen und ermöglicht so einen Neustart.
Sowohl zur Kommunikation zwischen den einzelnen Modulen des FTMPS-Projekts selbst als auch zur Kommunikation zwischen diesen und den Datenbanken werden Schnittstellenfunktionen benötigt.
Die von der aktiven Datenbankumgebung bereitgestellten Schnittstellen wurden als Funktionen realisiert, die zu Librarys zusammengefaßt wurden. Falls ein Modul mit einem anderen in Verbindung treten möchte, werden diese Funktionen aufgerufen, und die Library wird in das Programm eingebunden.
Zur Kommunikation zwischen den Endlichen Automaten der aktiven Datenbankumgebung und den hieran angeschlossenen Modulen (DIAG, RC, CM, MC, TC, OPR) wurde eine als Socket-Library bezeichnete Schnittstelle vorgesehen. Hierbei benutzt die Library intern eine auf UNIX-Stream-Sockets basierende Datenkommunikation. Eine Socket-Verbindung (im folgendem auch als Socket bezeichnet) ähnelt einer Verbindung über eine Pipe (siehe auch [Sun90] ). Über Sockets können in beiden Richtungen Nachrichten ausgetauscht werden. Die Sicherheit der Übertragung wird hierbei vom Betriebssystem gewährleistet. Im Gegensatz zu Pipes können mit einem bestimmten Socket-Typ (INET-Sockets) auch Verbindungen zwischen beliebigen verschiedenen Rechnern innerhalb eines Netzwerkes aufgebaut werden.
Sockets wurden gewählt, da bei einigen Zielsystemen der FTMPS-Software, wie beispielsweise dem Parsytec GC-0.5exel, keine Pipes genutzt werden können, da die Kontrollsoftware auf einem gesonderten Rechner abläuft. Socket-Kommunikationen werden jedoch von vielen MPS, so auch vom Parsytec GC-0.5exel, unterstützt.
Sockets bieten ferner den Vorteil, daß die einzelnen Programmodule nicht notwendigerweise auf ein und demselben Rechner ausgeführt werden müssen. Hiermit könnte beispielsweise die gesamte Datenbankumgebung -- und damit auch die Datenbank -- auf einen anderem Computer als die übrigen Programmodule ablaufen.
Ebenfalls können mit Hilfe der Socket-Library weitere, auch die Schnittstellen der Datenbankumgebung nicht betreffende Kommunikationen aufgebaut werden. Auf der Socket-Library basierende Kommunikationen werden von der Datenbankumgebung intern ebenfalls dazu genutzt, einzelne der Endlichen Automaten miteinander zu synchronisieren.
Bei dem in die OSS integrierten Statistikmodul erfolgt die Datenkommunikation mit der Datenbankumgebung nicht über Sockets, sondern mit Hilfe einer speziellen Statistikmodul-Library, die direkt auf die zur Abfrage benötigte Datenbank zugreift. Vom Statistikmodul können über diese Library Anfragen an die Datenbankumgebung gestellt werden, die dann von dieser bearbeitet werden. Der direkte Zugriff über eine Library ermöglicht bei umfangreicheren Abfragen an die Datenbankumgebung einen schnellen Zugriff, da zusätzliche, auf Sockets basierende Kommunikationen wegfallen. Dies ist insbesondere bei den großen zu erwartenden Datenmengen, die bei statistischen Analysen von der Datenbankumgebung zurückgeliefert werden, der Fall. Auch bei Abfragen vom Systembetreuer wird aus den gleichen Gründen eine Operator-Module-Library genutzt.
Die Entwicklungsumgebung für die FTMPS-Software, die nicht direkt auf dem MPS ausgeführt wird, besteht aus UNIX-Workstations (Sun), der Programmiersprache C (bzw. C++) und dem Grafiksystem X-Windows.
Zur Implementierung der aktiven Datenbankumgebung wurde zunächst der gcc, später der g++ von GNU als Übersetzer genutzt. Letzterer kann nicht nur eine genauere Typenprüfung als der gcc durchführen, sondern auch zur Vermeidung von Kompatibilitätsschwierigkeiten beitragen, falls später einige Module des FTMPS-Projekts objektorientiert in C++ umgesetzt werden sollten. Der Quellcode der aktiven Datenbankumgebung sollte mit jedem ANSI-C-fähigen Compiler zu übersetzen sein.
Zunächst wird in Abschnitt 5.1 die Wahl einer geeigneten Datenbank beschrieben. Die Implementierung der Kommunikationsschnittstellen behandelt Abschnitt 5.2, die Implementierung der aktiven Datenbankumgebung Abschnitt 5.3. Am Ende dieses Kapitel erfolgt in Abschnitt 5.4 eine Beschreibung, wie die korrekte Funktionsweise der einzelnen Module überprüft wurde.
Die Leistungsfähigkeit der aktiven Datenbankumgebung hängt entscheidend von der verwendeten Datenbank ab. Zu Projektbeginn stand keine geeignete kommerzielle Datenbank mit der Abfragesprache SQL zur Verfügung. Daher wurde eine nichtkommerzielle Datenbank gesucht, die den Ansprüchen genügt. Hierbei wurde insbesondere darauf geachtet, daß diese später ohne größeren Aufwand gegen eine kommerzielle Datenbank ausgetauscht werden kann.
Die Wahl fiel auf das Sharewareprogramm MetalBase 5.0 von Richid Jernigan, bei dem es sich jedoch nicht um eine relationale Datenbank handelt. Die Daten werden zwar in Tabellenform gespeichert, die eigentlichen Abfrageverknüpfungen (Relationen) fehlen jedoch. Eine Datenabfragesprache wie SQL, die bei vielen kommerziellen Datenbanken verwendet wird, steht aus diesem Grunde ebenfalls nicht zur Verfügung. Bei MetalBase kann über Schlüsselfelder nach Datensätzen gesucht werden. Es sind hierbei mehrere Schlüssel pro Datei möglich, wobei allerdings bei einer Abfrage immer nur nach einem Schlüsselfeld gesucht werden kann. Der Abfrageschlüssel kann vor der Abfrage gewechselt werden.
Kombinierte Schlüsselfeldabfragen für kombinierte Datenabfragen werden von MetalBase aus diesem Grund nicht unterstützt[+]. Diese können jedoch mit Hilfe der von MetalBase zur Verfügung gestellten C-Funktionen selbst umgesetzt werden. Für die Programmierung der Datenbankumgebung ist dies, obwohl mit Mehrarbeit verbunden, akzeptabel.
Ein Vorteil gegenüber anderen Datenbank-Programmen ist, daß MetalBase sehr kompakt ist. Der MetalBase-Kern besteht aus einer ca. 96 KByte großen Library[+] von C-Funktionen. Benutzerprogramme können diese Funktionen aufrufen und hiermit eine Datenverwaltung aufbauen. Der Datenaustausch erfolgt bei den Funktionen durch Übergabe eines Zeigers auf eine Struktur, die den Datensatz oder die Datenabfrage enthält. Bei kommerziellen Datenbanken, beispielsweise der Datenbank Sybase, werden die C-Schnittstellen ähnlich realisiert.
MetalBase wird mit einigen Hilfsprogrammen ausgeliefert, die eine Datenverwaltung auch ohne die Programmierung von Benutzerprogrammen ermöglichen: Dateien zur Verwaltung von Daten können initialisiert, verändert und gesucht werden.
Mit dem Hilfsprogramm build kann über eine MetalBase-eigene Datensatz-Beschreibungssprache eine einzelne Datei für die Datenverwaltung initialisiert werden. Zusätzlich wird eine Definitionsdatei (Headerfile) zur Einbindung in eigene C-Benutzerprogramme erzeugt. Falls mehrere verschiedenartige Datensätze verwaltet werden sollen, können mit dem Hilfsprogramm build mehrere Dateien (Teildatenbanken) angelegt werden, wobei die Gesamtdatenbank aus mehreren, teilweise wieder miteinander verknüpften Teildatenbanken besteht. Im folgenden werden die Teildatenbanken auch als Datenbanken bezeichnet.
Die so mit build generierte Datenbank kann über ein weiteres Hilfsprogramm mit dem Namen vr genutzt werden oder der Zugriff kann über ein selbst erstelltes Benutzerprogramm mit den Funktionen aus der MetalBase-Library erfolgen. Ein weiteres Hilfsprogramm zur Generierung von Ausgabelisten steht zur Verfügung. Die Hilfsprogramme werden für die Nutzung der aktiven Datenbankumgebung nicht benötigt.
MetalBase kann pro Datei bis zu [IMAGE ] Datensätze verwalten[+]. Hierbei können standardmäßig pro Datensatz bis zu 40 Datenfelder genutzt werden, wobei sich diese Grenze durch Anpassung einer Konstanten im Quellcode leicht erhöhen läßt. Es werden unter anderem folgende Datentypen unterstützt:
Genutzt werden durch die aktive Datenbankumgebung hiervon die Typen serial, long, double und string. MetalBase unterstützt mit Feldeinträgen vom Typ serial eine automatische Verwaltung eindeutiger Seriennummern. Diese wird von MetalBase automatisch jedem neuen Datensatz bei fortlaufender Inkrementierung hinzugefügt. Identifikationsnummern gelöschter Einträge werden also nicht wiederverwendet. Mit Hilfe von Identifikationsnummern werden bei der aktiven Datenbankumgebung Querverweise zwischen den einzelnen Dateien aufgebaut.
Von der Nutzung der MetalBase-spezifischen Feldtypen date und time wurde mit Blick auf mögliche Portierungen auf andere Datenbanksysteme Abstand genommen. Zum Abspeichern von Zeiten wurde der unter UNIX gebräuchliche Typ time_t[+] benutzt, der sich in den Typ long umwandeln und so mit MetalBase verarbeiten läßt.
MetalBase arbeitet nicht auf einer Client-Server-Basis, auf die einzelnen Datenbanken erfolgt vielmehr ein direkter Zugriff (ohne Datenbank-Server). Allerdings können mehrere voneinander unabhängige Benutzerprogramme gleichzeitig zugreifen. Konflikte durch gleichzeitigen Zugriff mehrerer Module auf eine Datei sollen aber ausgeschlossen sein. Dies wird durch ein benutzertransparentes Sperren (Locking) bei systeminternen Zugriffen gewährleistet. Zusätzlich kann der Benutzer von MetalBase temporäre Sperren für beliebig gewählte Programmabschnitte anlegen. Da bei dem die Fehlertoleranz unterstützenden Teil der Datenbankumgebung jeweils nur ein Programm zur gleichen Zeit auf eine Datei zugreift[+], wurden temporäre Locks bisher nicht benötigt[+]
Der Quellcode von MetalBase wurde für die Anforderungen der Datenbankumgebung leicht verändert und neu übersetzt. Innerhalb der Datei ''mbase.h'' wurden die Anzahl der maximal möglichen Felder pro Datensatz von 40 auf 60 und die maximal mögliche Länge der Feldnamen von 16 auf 20 erhöht. Das mit MetalBase gelieferte Tool vr zum Modifizieren von Datensätzen wurde innerhalb der Quelldatei ''vr.c'' verändert, um längere Feldnamen auf dem Bildschirm anzeigen und bearbeiten zu können.
MetalBase ist eine sehr einfache Datenverwaltung, deren Möglichkeiten zur Änderung des Datensatzinhaltes auch bei Datenbanken mit umfangreicheren Datenbankoperationen zur Verfügung stehen. Falls zu einem späteren Zeitpunkt eine leistungsfähigere Datenbank zur Verfügung stehen sollte, kann die Software der aktiven Datenbankumgebung leicht auf diese portiert werden. Die Technik des Datenaustausches zwischen Anwenderprogramm und Datenbank ist bei MetalBase der von konventionellen Datenbanken, wie beispielsweise der Datenbank Sybase [Syb90] , benutzten ähnlich.
Bei der gegenwärtigen Implementierung liegen die Datensätze als C-Strukturen vor. Diese müßten bei einer Portierung eventuell vor dem eigentlichen Datenbankaufruf in zur neuen Datenbank passende Strukturen konvertiert werden. Ergebnisse der Datenbankabfrage müssen unter Umständen ebenfalls umgewandelt werden. Da sich die Aufrufe der Datenbankfunktionen über eine Library ähnlich vollziehen, sind bei der Portierung nur die Aufrufstellen der Datenbankfunktionen innerhalb der Datenbank-Umgebungssoftware zu verändern. Aus Gründen der Leistungsfähigkeit und der einfacheren Wartung der Software könnte es sinnvoll sein, derzeit innerhalb der Datenbank-Umgebungssoftware realisierte kombinierte Datenabfragen durch einen neuen, mächtigeren Datenbankaufruf zu ersetzen.
Die Datenkommunikation zwischen den einzelnen Modulen erfolgt über C-Strukturen. Der Error Log Controller (ELC) wird von der Diagnose über aufgetretene Fehler und deren Diagnose anhand von Fehlerreports unterrichtet. Hierzu wird die C-Struktur mit folgenden Datenfeldern benutzt[+]:
Diese Struktur wird auch genutzt, um aktuelle Fehlerlisten zwischen dem ELC und dem RC und umgekehrt zu transferieren.
Für Anfragen von der Diagnose, wieviele Fehler in der letzten Zeit aufgetreten sind, wird die obige Struktur noch um den Eintrag INTERVAL erweitert. Dieser Eintrag enthält einen Zeitraum in der Vergangenheit, der von der aktuellen Zeit ausgehend durchsucht werden soll. Gesucht werden hierbei alle Fehler, die in das Muster des in der restlichen Struktur angegeben Fehlers passen.
Nachdem ein Fehler gemeldet wurde, fragt der ELC beim Stress Value Handler (SVH) nach Auslastungsdaten der Prozessoren und Links. Diese werden anschließend dem in der Datenbank abzuspeichernden Fehlerreport hinzugefügt. Die zugehörige Anfragestruktur beinhaltet folgende Komponenten:
Das Resultat der Anfrage, das der SVH aus einer speziellen Datenbank für Auslastungsdaten ermittelt, wird dem ELC über eine aus folgenden Komponenten bestehende Struktur zurückgeliefert:
Damit der SVH die Datenbank für Auslastungsdaten ständig aktualisieren kann, erhält er vom Modul Monitor Collect (MC) in regelmäßigen Intervallen die Auslastungsdaten aller Prozessoren und Links. Die Daten sind hierbei abhängig von der Systemarchitektur des MPS. Beim Parsytec GC-0.5exel wird folgende Systemauslastungsstruktur übertragen:
Die Anzahl der beiden Felder innerhalb der obigen Struktur beträgt je nach Systemausbau des Rechners bis zu 256. Im Feld ACTIVE_CUBES wird vermerkt, ob der jeweilige Prozessor gerade einer aktiven Partition zugeteilt ist. Hiermit kann unterschieden werden, ob der Prozessor gerade nicht ausgelastet ist, weil er keinem Programm zugeteilt ist oder obwohl er einer aktiven Partition zugeteilt ist. Es können somit verschiedene mittlere Auslastungswerte berechnet werden, wobei die Zeit, in der ein Prozessor keiner aktiven Partition angehört, wahlweise berücksichtigt werden kann[+].
Ein Eintrag des Felds CUBE_LOAD mit den Auslastungsdaten für den jeweiligen Cube, der 64 Prozessoren enthält, besteht aus der folgenden Struktur:
Jedes der so übermittelten Feldelemente ist ein Bit-Feld der Länge 32. Für jede Komponente sind hierin jeweils 32 Einzelmessungen zusammengefaßt. Das Ergebnis einer Einzelmessung ist entweder, daß der Prozessor gerade nicht ausgelastet ist oder daß er ausgelastet ist, und kann somit in einem Bit codiert werden. Der SVH berechnet aus den 32 Einzelwerten einen Durchschnittswert und legt ihn in der Datenbank Auslastungsdaten ab.
Die gebündelte Übertragung von jeweils 32 Einzelmessungen in ein Bit-Feld komprimiert die zu transferierenden Daten und minimiert die Anzahl der Datentransfers zwischen MC und SVH. Hierdurch werden die Kommunikationsverbindungen des MPS entlastet.
Zusätzlich werden bei der Rekonfiguration Informationen darüber benötigt, welche Partitionen im MPS vorhanden sind und aus welchen Knoten diese bestehen. Für den Datentransfer zwischen dem RC und dem ELC sowie dem OPR und dem ELC werden ähnliche[+] Datenstrukturen wie die in Abschnitt 4.1 vorgestellten genutzt.
Dem Repair Report Handler (RRH) werden vom Systembetreuer (OPR) Reparaturen gemeldet, die am MPS durchgeführt wurden. Hierzu dient die folgende Struktur[+]:
Mit Hilfe weiterer Strukturen kann das Statistic Modul (STAT) benötigte Daten vom Statistic Module Handler (STMH) anfordern. Die Datenkommunikation erfolgt über Strukturen, die denen der Datenbanken (beschrieben in Abschnitt 4.1) entsprechen. Analog wird mit Abfragen verfahren, die über die grafische Benutzeroberfläche (OPR) vom Systembetreuer an den Operator Module Handler (OPRMH) erfolgen[+].
Der Datenaustausch der C-Strukturen erfolgt über Schnittstellenfunktionen aus einer Library. Den Funktionen werden hierbei die Zeiger auf die zum Datenaustausch bestimmten Strukturen übergeben. Mit Hilfe der Zeiger auf die Strukturen können dann sowohl Daten in die Funktion hinein als auch Daten aus ihr heraus transferiert werden.
Wie schon in Abschnitt 4.4 erwähnt, existieren drei solcher Librarys mit Schnittstellenfunktionen. In der Socket-Library wurden Funktionen implementiert, mit denen über UNIX-Stream-Sockets zwischen verschiedenen Programmen Daten ausgetauscht werden können. Von den verschiedenen zur Verfügung stehenden Socket-Typen wurde derjenige ausgewählt (INET-Sockets), der auch eine Kommunikation zwischen zwei Rechnern über Netz (Internet) ermöglicht. Die Socket-Verbindungen werden sowohl zur Kommunikation zwischen der Datenbankumgebung und den an ihr angeschlossenen Modulen (DIAG, RC, CM, OPR, MC, TC) als auch zur internen Kommunikation zwischen den einzelnen Modulen innerhalb der Datenbankumgebung genutzt.
Bei den Kommunikationspartnern einer Socket-Verbindung kann zwischen dem dienstanbietenden Programm (Server) und dem diese Dienste anfordernden Programm (Client) unterschieden werden[+].
Beim Aufbau einer Socket-Verbindung wird zunächst der Server gestartet, danach der Client. Zusätzlich wird zum Aufbau der Kommunikation von beiden eine gemeinsame Socket-Port-Nummer benötigt, der Client benötigt zusätzlich die Internet-Adresse des Servers.
Nachdem der Socket zwischen den beteiligten Programmen geöffnet ist, können über einen File-Descriptor mit Hilfe der Funktionen write() und read() Daten ausgetauscht werden. Für Programme mit mehreren Kommunikationspartnern steht eine Funktion zur Verfügung, die noch vor dem Auslesen der Daten die Identifizierung des Kommunikationskanals ermöglicht, über den die Daten eingetroffen sind. Dies ist erforderlich, damit das die Daten lesende Programm den richtigen Kanal auslesen kann, da bei einem Leseversuch des falschen, nicht zur Kommunikation bereiten Kanals das Programm bis zum Eintreffen von Daten über diesen Kanal blockieren würde.
Die Socket-Library stellt sechs Funktionen zur Verfügung, mit denen auf einfache Art und Weise Daten über Sockets ausgetauscht werden können, ohne genauere Kenntnisse über Sockets zu benötigen:
Für das Öffnen der Socket-Verbindung stehen zwei unterschiedliche Funktionen zur Verfügung. Zunächst sollte die Socket-Verbindung vom Server mit der Funktion open_socket_on_server() geöffnet werden. Benötigt wird beim Aufruf eine für den Server und den dazugehörigen Client übereinstimmende Socket-Port-Nummer. Die gemeinsame Socket-Port-Nummer wird hierbei in einer für jeden Kommunikationspartner verfügbaren Datei festgelegt. Anschließend kann der Client mit der Funktion open_socket_on_client() die Verbindung zum Server öffnen. Er benötigt über die Socket-Port-Nummer hinaus noch den Rechnernamen des Servers. Hieraus wird innerhalb der Funktion die Internet-Adresse des Rechners ermittelt, die zum Aufbau der Verbindung zwischen Client und Server benötigt wird. Sobald sowohl der Server als auch der Client die Verbindung geöffnet haben, kommt die Socket-Verbindung zustande.
Falls der Client versucht, eine Verbindung herzustellen, obwohl der Server noch nicht zur Kommunikation bereit ist, wird der Funktion open_socket_on_client() intern vom Betriebssystem ein Fehler gemeldet. Dieser wird innerhalb der Funktion abgefangen, und nach einigen Sekunden wird ein erneuter Verbindungsaufbau versucht. Gleichermaßen wird bei der Funktion open_socket_on_server() verfahren. (Hierbei kann es allerdings in seltenen Fällen vorkommen, daß der benötigte Socket-Port noch durch eine alte, nicht vollständig abgebaute Verbindung blockiert wird.)
Da es vorkommen kann, daß beide Kommunikationspartner auf die Beseitigung der oben geschilderten Fehler warten müssen, wird der erneute Verbindungsversuch nicht nach einer festgelegten Zeitspanne, sondern nach einer mit Hilfe einer Pseudo-Zufallsfunktion berechneten Zeit erneut gestartet[+]. Erst wenn nach einer zuvor festgesetzten Zeit[+] keine Verbindung zustande gekommen ist, wird dieser Fehler von der Funktion der Socket-Library dem aufrufenden Programm gemeldet.
Da die beiden Open-Funktionen auf die Verbindung warten, muß nicht unbedingt auf die richtige Startreihenfolge der an der Kommunikation beteiligten Programme geachtet werden. Dies ist hilfreich, wenn die Module auf unterschiedlichen Rechnern gestartet werden.
Nach dem Aufbau der Socket-Verbindung können mit Hilfe des von der jeweiligen Open-Funktion zurückgelieferten File-Descriptors die restlichen Socket-Library-Funktionen genutzt und Daten in beiden Richtungen ausgetauscht werden. Hierfür wird der schreibenden Funktion write_socket() über den Descriptor hinaus sowohl ein Zeiger auf die zu übertragende Struktur als auch die Länge dieser Struktur übergeben. Die Daten werden anschließend über die Socket-Verbindung transferiert und können von der Funktion read_socket() ausgelesen werden. Der Lese-Funktion wird hierzu neben dem Descriptor ein Zeiger auf eine bereitstehende, zu füllende Struktur und die Länge der zu lesenden Daten übergeben. Hierbei ist es wichtig, daß die in den Socket geschriebenen Daten wieder ausgelesen werden, da es ansonsten zu Blockierungen kommt.
Der Datentransfer zwischen den Kommunikationspartnern findet erst dann statt, wenn beide Partner bereit sind. Diese synchrone Kommunikation wird innerhalb der Library-Funktionen durch das Versenden von Hilfsnachrichten sichergestellt. Ist einer der Partner noch nicht soweit, wartet der andere solange, bis die Kommunikation erfolgen kann; hierzu wird das wartende Programm suspendiert, bis die Kommunikation erfolgen kann[+]. Siehe hierzu auch Bild 5.1. Dieser Mechanismus wird auch genutzt, um die einzelnen Automaten der aktiven Datenbank untereinander zu synchronisieren.
[IMAGE ]
Figure: Socket-Kommunikation
Falls ein Programm zur gleichen Zeit auf den Empfang von verschiedenen Socket-Verbindungen warten soll, kann die Funktion select_read_socket() genutzt werden[+]. Dieser wird hierzu ein Feld von Deskriptoren der beteiligten Sockets und die Anzahl der Deskriptoren übergeben. Die Funktion liefert als Ergebnis einen Hinweis auf den Deskriptor, über den der auslesebereite Socket angesprochen werden kann. Anschließend kann der Socket mit der Funktion read_socket() ausgelesen werden (Bild 5.2).
[IMAGE ]
Figure: Anwendung der Funktion select_read_socket
Falls beispielsweise auf den Kommunikationsversuch eines von insgesamt zwei Sockets gewartet werden soll, kann mit
x = select_read_socket(sock_feld, 2);
bestimmt werden, welcher Socket zum Auslesen bereitsteht. Mit
read_socket(sock_feld[x-1], &data, sizeof(data));
können die Daten ausgelesen werden.
Die Sockets werden von den Open-Funktionen in einem speziellen Modus geöffnet, so daß die Sockets bis zum Schließen mit der Funktion close_socket() geöffnet bleiben und Fehler der Socket-Verbindung den Kommunikationspartnern gemeldet werden. Bei allen Socket-Library-Funktionen wird ein Fehler über den zurückgegebenen Funktionswert (-1) gemeldet. Über eine zur Socket-Library gehörende Fehlervariable ( sock_int_errnr) kann dann die genaue Fehlerursache ermittelt werden.
Zur Nutzung der Socket-Library als Schnittstelle zwischen der aktiven Datenbankumgebung und den an sie angeschlossenen Modulen wurde zusätzlich ein Kommunikationsprotokoll vereinbart, das den Versand der Daten festlegt: Die Sockets bleiben während der gesamten Laufzeit des Programms geöffnet. Dies vereinfacht bei den Programmen der aktiven Datenbankumgebung die Verwaltung der Sockets, insbesondere bei den Programmen, die die Funktion select_read_socket() nutzen.
Darüberhinaus wird vor dem Versenden der eigentlichen Nutzdaten jeweils ein Etikett versandt, im folgenden auch als Tag bezeichnet. Aus ihm geht hervor, welche Daten folgen. Dies wurde bei den als Endliche Automaten realisierten Programmen der Datenbankumgebung notwendig, da über eine Socket-Verbindung verschiedene Nachrichten empfangen werden sollen. In einigen Fällen werden die Tags auch zur Synchronisation benutzt.
Neben der Socket-Library existieren zwei weitere Librarys, die als Schnittstelle zur aktiven Datenbank dienen.
Innerhalb der OSS durchgeführte Datenbankabfragen werden aus den in Abschnitt 4.4 genannten Gründen direkt durch den Aufruf von Funktionen der STMH-Library und OPRMH-Library realisiert. Die Module für die Datensuche sind Bestandteil der Module STAT und OPR und werden mittelbar über die entsprechende Library eingebunden. Sie laufen also nicht als eigenständiges Programm[+].
Im folgendem erfolgt eine genauere Beschreibung der in Abschnitt 4.3 vorgestellten Module der aktiven Datenbankumgebung. Diese übernehmen mit Hilfe des Datenbankprogramms MetalBase die Verwaltung der im Abschnitt 4.1 beschriebenen zu sammelnden Daten. Benötigte Kommunikationen zwischen einzelnen Modulen werden über die in Abschnitt 5.2 beschriebenen Schnittstellen abgewickelt. Bild 5.3 zeigt eine Übersicht der einzelnen Module der aktiven Datenbankumgebung und der an sie angeschlossenen Datenbanken.
[IMAGE ]
Figure: Datenbanken und Module der aktiven Datenbankumgebung
Alle Endlichen Automaten der aktiven Datenbankumgebung wurden nach dem im Anschluß erläuterten gleichen Grundprinzip implementiert. Bild 5.4 zeigt das Nassi-Schneiderman-Diagramm eines Beispielautomaten mit einem Startzustand und drei weiteren Zuständen.
[IMAGE ]
Figure: Endlicher Automat
Zunächst werden die von dem Automaten benötigten Datenbanken geöffnet, danach erfolgt der Aufbau aller benötigten Socket-Verbindungen. Anschließend wird die den Automaten steuernde Funktion aufgerufen. Je nach Folgezustand des Automaten wird von hier die Funktion aufgerufen, die den folgenden Automatenzustand repräsentiert. Bei einem weiteren Zustandswechsel des Automaten liefert diese Funktion als Rückgabewert einen Verweis auf den Folgezustand an die Steuerfunktion, die von hier aus die gewünschte Funktion des Folgezustands aufrufen kann. Durch dieses Verfahren können leicht Änderungen und Ergänzungen am Automaten durchgeführt werden.
Bei allen Automaten der Datenbankumgebung repräsentiert jeder Automatenzustand auch einen Zustand im zuvor mit den FTMPS-Partnern festgelegten Ablaufprotokoll. Aus diesem Grund ist jeder Zustandswechsel durch eine Socket-Kommunikation mit einem anderen Modul verbunden.
Der ELC sammelt Daten für den Fehlerreport und aktualisiert die Mapping-Daten. Hierzu baut er Socket-Verbindungen zu den Modulen DIAG, RC, OPR und SVH auf. Hierbei dient der ELC für alle Verbindungen als Server, die Verbindungen werden also mit der Funktion open_socket_on_server() geöffnet. Der Endliche Automat des ELC besteht aus zehn Zuständen. Bild 5.5 zeigt das entsprechende Ablaufdiagramm.
[IMAGE ]
Figure: Endlicher Automat Error Log Controller (ELC)
Zustand 0 ist der Startzustand des Automaten, von dem nach den benötigten Initialisierungen sofort zu Zustand 1 gewechselt wird.
Im Zustand 1 befindet sich der Automat, wenn gerade kein Fehler beim MPS aufgetreten ist oder behandelt wird, das MPS also momentan fehlerfrei ist. Zustand 1 wartet auf eine über einen Socket übermittelte Nachricht, um den Zustand wechseln zu können. Es existieren folgende Zustandsübergänge:
Übergang: & Ereignis:
Zustand 2 fügt den von der Diagnose gemeldeten transienten Fehler und die aktuellen Auslastungswerte des betroffenen Prozessors der Datenbank für Fehlerreports hinzu. Hierzu werden die Auslastungswerte vom SVH über Socket angefordert. Anschließend wird die Ausführung an die Diagnose gemeldet, und es erfolgt ein Übergang zurück zu Zustand 1.
Die Anfrage von der Diagnose, wieviele Fehler in der letzten Zeit aufgetreten sind, wird im Zustand 3 ermittelt. Die Datenbank für Fehlerreports wird hierzu im von der Diagnose angegebenen Zeitraum nach in das angegebene Suchmuster passenden Fehlern durchsucht, wobei nur solche transienten Fehler berücksichtigt werden, die nicht im Zustand 4 markiert wurden. Das Ergebnis wird der Diagnose übermittelt, und der Automat wechselt zurück in den Zustand 1.
Von der Diagnose gemeldete permanente Fehler werden im Zustand 4 behandelt. Der Fehler und die dazu vom SVH angeforderten Auslastungsdaten werden der Datenbank für Fehlerreports hinzugefügt. Danach wird die Datenbank daraufhin durchsucht, ob bei der gerade gemeldeten Komponente seit dem letzten Ausfall bereits einmal transiente Fehler gemeldet wurden. Diese Einträge werden dann markiert, damit sie im Automatenzustand 3 nicht mitgezählt werden. Anschließend wird die Diagnose über die erfolgte Bearbeitung benachrichtigt. Die Diagnose setzt sich daraufhin mit dem RC in Verbindung, der zur Rekonfiguration des Systems die aktuelle Systemtopologie benötigt und diese vom ELC erfragt, der bei Eingang der Anfrage von Zustand 4 nach 5 wechselt.
Zustand 5 ermittelt für den RC aus der Datenbank der aktuellen Ausfälle eine Liste und schickt diese zurück zum RC, der aus ihr und dem von der Diagnose neu gemeldeten permanenten Ausfall eine neue Liste erstellt. In ihr werden nicht alle ausgefallenen Komponenten, sondern nur die wesentlichen fehlerhaften Einheiten aufgeführt. Wenn beispielsweise ein Cube ausgefallen ist, wird nur dieser Cube in die Liste aufgenommen, nicht aber alle in dem Cube enthaltenen Unterkomponenten (siehe auch Abschnitt 4.1). Beim Eintreffen der neuen Liste wechselt der ELC von Zustand 5 zu Zustand 6.
Zunächst wird im Zustand 6 die vom RC gesandte Liste dazu genutzt, die Datenbank mit den aktuellen Ausfällen auf den neuesten Stand zu bringen. Danach wird der RC hierüber unterrichtet, der wiederum den ELC darüber informiert, welcher der drei möglichen Folgezustände aufgesucht werden soll. Der Folgezustand hängt davon ab, inwieweit die physikalische Zuteilung der einzelnen Prozessorknoten auf die vom Ausfall betroffene Partition geändert werden mußte:
Übergang: & Ereignis:
Der Zustand 7 kann über zwei verschiedene Vorgängerzustände erreicht werden. In beiden Fällen werden ihm Änderungen bei der Zuteilung der Prozessoren auf die Partitionen gemeldet. Falls er über den Vorgängerzustand 8 erreicht wurde, erhält er die Änderungen vom Modul OPR; falls er über den Vorgängerzustand 6 erreicht wurde, erhält er diese vom RC. Anschließend wird mit Hilfe der Änderungsdaten die Datenbank mit den Partitionsdaten und deren Ausnahmen aktualisiert.
Im Zustand 8 wird der Systembetreuer davon benachrichtigt, daß der RC nach einem Ausfall das Mapping nicht automatisch so ändern konnte, daß die Partition wieder betriebsbereit ist. Der Systembetreuer kann beschließen, daß ein neues Mapping nicht mehr möglich ist und die zuvor auf ihr gelaufene Applikation beendet werden muß; der Automat wechselt dann in Zustand 1 über. Falls der Systembetreuer nach einiger Zeit nicht reagiert hat, da er vielleicht gerade nicht anwesend ist, wird ihm eine Nachricht hinterlassen und ebenfalls in Zustand 1 gewechselt. Falls der Systembetreuer das Mapping erfolgreich ändern konnte, werden dem ELC die neuen Daten über diesen Vorgang mitgeteilt, und der Automat wechselt zu Zustand 7.
Zustand 9 trägt vom OPR-Modul gemeldete Fehler in die Fehlerreport-Datenbank ein. Es handelt sich hierbei um die vom Systembetreuer per Hand eingetragenen Fehler. Nachdem der OPR vom Abschluß der Bearbeitung unterrichtet wurde, wird zu Zustand 1 gewechselt.
[IMAGE ]
Figure: Endlicher Automat Stress Value Handler (SVH)
Der SVH verwaltet Prozessor-Auslastungsdaten, indem er mit den Modulen MC und ELC Socket-Verbindungen aufbaut. Der Automat des SVH besteht aus vier Zuständen. Bild 5.6 zeigt das zugehörige Ablaufdiagramm.
Zustand 0 ist der Startzustand des Automaten, von dem nach den benötigten Initialisierungen sofort zu Zustand 1 gewechselt wird.
Im Zustand 1 wartet der SVH auf das Eintreffen einer Nachricht über einen der beiden Sockets:
Übergang: & Ereignis:
Der SVH empfängt in regelmäßigen Abständen[+] vom Modul MC aktuelle Auslastungsdaten. Hieraus werden im Zustand 2 mit Hilfe der in einer Datei vorhandenen alten Daten neue mittlere Auslastungswerte berechnet. Die neuen Mittelwerte[+] und die aktuellen Auslastungswerte werden anschließend in die Datei zurückgeschrieben. Da hierbei alle Dateieinträge geändert werden, wurde hierbei auch aus Gründen einer höheren Verarbeitungsgeschwindigkeit auf den Einsatz von MetalBase verzichtet[+] und stattdessen eine eigene Dateiverwaltung verwendet. Anschließend wird das Modul MC über die Beendigung dieses Vorgangs unterrichtet und wieder zu Zustand 1 gewechselt.
Zustand 3 behandelt eine Abfrage des ELC nach aktuellen Auslastungsdaten für einen bestimmten Prozessorknoten. Er ermittelt die mittlere und die aktuelle Auslastung aus der Datei mit den Auslastungswerten, für die der Wert des jeweils letzten Meßintervalls verwendet wird. Nachdem dem ELC diese Daten übermittelt worden sind, wechselt der SVH zurück in Zustand 1.
Der RRH[+] zeichnet durchgeführte Reparaturen auf und verwaltet die im MPS vorhandenen Boards. Der Automat mit drei Zuständen[+], siehe Bild 5.7, baut hierzu eine Socket-Verbindung mit dem Modul OPR auf.
[IMAGE ]
Figure: Endlicher Automat Repair Report Handler (RRH)
Zustand 0 ist der Startzustand des Automaten, von dem nach den notwendigen Initialisierungen sofort zu Zustand 1 gewechselt wird. Im Zustand 1 wartet der RRH, bis er vom Modul OPR einen Reparaturreport erhält, worauf er in den Zustand 2 wechselt.
Im Zustand 2 wird der Reparaturbericht ausgewertet, der hierzu der Datenbank für Reparaturberichte hinzugefügt wird. Falls bei der Reparatur ein Board durch ein neues oder am Standort vorhandenes ersetzt wird, werden zusätzlich die Datenbank mit den im MPS installierten Boards und die Datenbank mit den am Standort vorhandenen, aber momentan nicht im System installierten Boards aktualisiert. Bei letzterer werden zusätzlich die bisher im System gesammelten Auslastungs- und Temperaturwerte festgehalten. Bei einer erneuten Installation im System werden diese Daten der Datenbank Auslastungsdaten übergeben. Ebenfalls müssen nach der Reparatur die Datenbanken mit den derzeit im System vorhandenen Ausfällen aktualisiert werden. Der RRH wechselt zurück zu Zustand 1 und benachrichtigt hierüber das Modul OPR.
Die oben beschriebenen Endlichen Automaten bauen sowohl untereinander als auch mit weiteren Modulen Verbindungen über Sockets auf. Wie schon in Abschnitt 5.2 beschrieben, werden die einzelnen Verbindungen als Server oder als Client geöffnet. Hierbei kann ein Programm mehrere Verbindungen öffnen, wobei das Programm auch gleichzeitig für eine Verbindung Client und für eine andere Server sein kann. Da im Normalfall der Socket beim Server zuerst geöffnet werden sollte, ergeben sich hierdurch auch Abhängigkeiten in der Startreihenfolge der einzelnen Programme.
[IMAGE ]
Figure: Kontrollprogramm für Automaten der Datenbankumgebung
Um diese in der richtigen Reihenfolge starten zu können, wurde ein Kontrollprogramm implementiert. In Bild 5.8 ist die Startreihenfolge der einzelnen Module durch Linien mit einer zusätzlichen Zahl zwischen den Modulen und dem Kontrollprogramm dargestellt. Die gestrichelten Pfeile stellen Socket-Verbindungen dar, wobei diese vom Server auf den Client zeigen. Nachdem alle Module gestartet sind, laufen diese normalerweise endlos.
Eine weitere Aufgabe des Kontrollprogramms ist das kontrollierte Beenden aller Module, wenn ein Fehler aufgetreten ist. Fehler können beispielsweise bei Socket-Verbindungen auftreten, insbesondere wenn die Verbindung zwischen zwei Rechnern über ein Netzwerk aufgebaut wurde. Des weiteren könnte ein Programm der FTMPS-Software einen Fehler melden, der die Beendigung des betroffenen Programms notwendig macht. Im schlimmsten Fall könnte im Programm ein unentdeckter Software-Fehler auftreten, der ein Blockieren oder den Abbruch des Programms zur Folge hat.
Das Kontrollprogramm wartet nach dem Start der von ihm kontrollierten Programme darauf, daß eines der Programme abbricht[+]. Ob das Programm kontrolliert über eine Fehlermeldung abgebrochen wurde oder unkontrolliert abbrach, erfährt das Kontrollprogramm unmittelbar und kann dann die übrigen von ihm gestarteten Programme stoppen. Anschließend können die Programme wieder über das Kontrollprogramm gestartet werden.
Der STMH, der vom Statistikmodul an die Datenbanken gestellte Anfragen bearbeitet, wurde aus den in Abschnitt 4.4 angesprochenen Gründen nicht als eigenständiges Programm, sondern als Library implementiert, die bei der Übersetzung der OSS direkt in das Statistikmodul (STAT) eingebunden wird.
Der STMH arbeitet hierbei nicht auf der Gesamtdatenbank, wie sie von der übrigen aktiven Datenbankumgebung genutzt wird, sondern auf einer gesonderten Gesamtdatenbank. Diese kann auch Einträge mehrerer MPS (und) verschiedener Standorte beinhalten. Durch das Zusammenfassen der Daten von mehreren MPS in einer zentralen Gesamtdatenbank erhält man eine größere Datenbasis für statistische Untersuchungen und kann auch leicht einzelne MPS miteinander vergleichen. Die zentrale Gesamtdatenbank benutzt hierbei die gleichen Datensatzdefinitionen wie die lokale Gesamtdatenbank, die von der übrigen aktiven Datenbankumgebung genutzt wird[+].
Die STMH-Library stellt folgende Funktionen zur Verfügung[+]:
Vor einer Abfrage müssen die Datenbanken zunächst mit der Funktion stmh_open_database geöffnet werden. Die Funktion stmh_close_database dient zum Schließen der Datenbanken.
Eine Abfrage kann mit der Funktion stmh_start_request_db gestartet werden. Der Funktion wird über einen Verweis auf einen Musterdatensatz mitgeteilt, welche Daten gesucht werden. Hierbei muß in allen Feldern, die nicht bei der Suche berücksichtigt werden sollen, bei Zahlen der Wert (-1) und bei Zeichenketten eine leere Zeichenkette übergeben werden. Zusätzlich ist das zu durchsuchende Zeitintervall anzugeben.
Der STMH sucht alle Datensätze, die innerhalb des angegebenen Zeitraums mit dem Musterdatensatz übereinstimmen. Die so ermittelten Datensätze können mit der Funktion stmh_request_db() ausgelesen werden. Hierzu muß dieser neben Suchmuster und Zeitintervall ein Verweis auf eine bereitstehende Datensatzstruktur für das Resultat übergeben werden. Über den wiederholten Aufruf der Funktion Datensatz kann Datensatz für Datensatz abgeholt werden, bis die Funktion über den Funktionswert signalisiert, daß alle gefundenen Datensätze abgeholt worden sind.
Zur Erprobung der Module der aktiven Datenbankumgebung und ihrer Schnittstellen wurden verschiedene Programme zum Aufbau einer Testumgebung implementiert. Hierdurch konnte die aktive Datenbankumgebung unabhängig von der Fertigstellung der Module der übrigen FTMPS-Partner überprüft werden.
Mit einem Testprogramm wurden die einzelnen Zustände der Automaten der Datenbankumgebung und ihrer Schnittstellen untersucht. Hierzu wurden die Schnittstellen der Module DIAG, RC, MC, und OPR simuliert. Im Einzelschrittmodus können die einzelnen Automatenzustände der Datenbankumgebung angesteuert und getestet werden. Um die Abläufe innerhalb der einzelnen Automaten verfolgen zu können, existiert wahlweise die Möglichkeit, Testausgaben in einem Konsolenfenster darzustellen. Zusätzlich können mit dem von MetalBase mitgelieferten Hilfsprogramm vr einzelne Einträge innerhalb der Datenbanken inspiziert und verändert werden. Diese Verfahrensweise konnte insbesondere in einer frühen Implementationsphase eingesetzt werden, um Fehler gezielt aufzuspüren und zu beseitigen.
Da alle vom oben genannten Testprogramm erzeugten Ereignisse nacheinander, aber nie quasi-parallel generiert werden, wurde eine weitere, aus mehreren Einzelprogrammen bestehende Testumgebung implementiert. Zur Simulation der Module DIAG, RC, MC, und OPR wurden jeweils eigene Testprogramme erstellt, die im folgenden als DIAG-0.5ex Sim, RC-0.5ex Sim, MC-0.5ex Sim, und OPR-0.5ex Sim bezeichnet werden. Hiermit können die einzelnen Automaten der Datenbankumgebung unter Berücksichtigung des von den FTMPS-Partnern festgelegten Ablaufprotokolls auch gleichzeitig angesprochen werden.
Mit dem Modul DIAG-0.5ex Sim können dem ELC verschiedene Fehler-Reports übermittelt werden. Die Generierung der Fehlermeldungen wird hierbei über eine Zufallsverteilungsfunktion gesteuert, die den Fehlerort, die Fehlerart und die Zeitdifferenz zwischen den einzelnen Meldungen liefert. Die Fehlerreporte können im Einzelschrittmodus oder endlos generiert werden.
Der Einzelschrittmodus diente auch hier wieder dem gezielten Austesten der Module der Datenbankumgebung. Durch die endlose Erzeugung von Fehlerreporten mit Hilfe einer Zufallsfunktion wurde versucht, reale Einsatzbedingungen der aktiven Datenbank zu simulieren. Indem die Zeitdifferenz zwischen den Einzelereignissen auf annähernd null gesetzt wurde, konnte die Datenbankumgebung auch mit hohen Nachrichtenbelastungen getestet werden, die unter realen Nutzungsbedingungen nicht zu erwarten sind.
Das Modul DIAG-0.5ex Sim kommuniziert auch mit dem Modul RC-0.5ex Sim, das wiederum mit dem ELC der Datenbankumgebung kommuniziert und so auch diese Verbindung überprüft.
Mit dem MC-0.5ex Sim können dem SVH Auslastungsdaten übermittelt werden. Zum Test wurden hierbei Auslastungsdaten für einen mit maximal 256 Cubes und 16.384 Prozessorknoten ausgebauten Parsytec GC-0.5exel generiert. Die Übertragung dieser Daten und die Berechnung von neuen Mittelwerten dauerte auf dem genutzten Testrechner mehrere Sekunden[+]. Daher sollten dem SVH die Auslastungsdaten in nicht zu kurzer zeitlicher Folge übermittelt werden, es sollte vielmehr mindestens zwei Minuten bis zum Versand der nächsten Auslastungsdaten gewartet werden. Da beim Versenden der Auslastungsdaten jeweils 32 Einzelmeßwerte zusammengefaßt werden, können problemlos größere Übertragungsintervalle gewählt werden.
Da der SVH neben der Aufzeichnung von Auslastungsdaten auch zur Beantwortung von Anfragen des ELC genutzt wird, wurde die Datenbankumgebung auch bei gleichzeitiger hoher Nachrichtenbelastung aller Einzelmodule getestet. Auch hierbei ergab sich aus den bereits oben genannten Gründen, daß zu kurze Zeitintervalle zwischen den Übertragungen der Auslastungswerte nicht ratsam sind.
Das Modul OPR-0.5ex Sim nimmt Meldungen vom SVH entgegen und beantwortet sie.
Die einzelnen Module der aktiven Datenbankumgebung können auch auf unterschiedlichen Rechnern ablaufen und mit Hilfe der Sockets miteinander über ein Netzwerk kommunizieren. Daher wurde auch diese Betriebsart überprüft, indem die einzelnen Testprogramme und Module der aktiven Datenbankumgebung auf verschiedenen Rechnern gestartet wurden.
Die Suche von Datensätzen aus der Datenbank für Fehlerreports mit der STMH-Library wurde zunächst mit einem gesonderten Testprogramm überprüft. Später erfolgten Tests der STMH-Library auch direkt mit dem teilweise implementierten Statistikmodul.
Die aktive Datenbankumgebung stellt innerhalb der Operator Site Software des FTMPS-Projektes die zentrale Komponente dar. Sie unterstützt die Zuverlässigkeitsanalyse von massiv-parallelen Systemem (MPS). Hierzu werden Fehler, Auslastungs- und Temperaturwerte, Ausfallzeiten und durchgeführte Reparaturen für statistische Fehleranalysen aufgezeichnet.
Darüber hinaus unterstützt die aktive Datenbankumgebung andere FTMPS-Partner bei der Sammlung und Verwaltung aller zur Erbringung von Fehlertoleranz in massiv-parallelen Systemem benötigten Daten.
Hervorragendes Merkmal des FTMPS-Projekts ist der weitgehend hardwareunabhängige Ansatz, der sicherstellt, daß die Software des Projekts für möglichst viele Zielsysteme genutzt werden kann. Zudem wurde das Sammeln von Daten für eine spätere statistische Auswertung schon bei der Entwicklung der Fehlertoleranzsoftware und des MPS berücksichtigt. Dies bietet den Vorteil, daß alle benötigten Daten systemkonform beschafft und aufgezeichnet werden können. Somit können bei allen installierten Rechnern systemrelevante Daten lückenlos protokolliert werden.
Das auf Transputern basierende MPS Parsytec GC-0.5exel ist das erste Zielsystem, auf dem die FTMPS-Software des Projekts genutzt werden soll. Erste Tests der Software sollen bis Anfang Februar 1994 auf einem aus wenigen Transputern bestehenden System (Parsytec Xplorer) durchgeführt werden.
Zur Verwaltung der Daten nutzt die aktive Datenbankumgebung die Shareware-Datenbank MetalBase 5.0. Hierbei wurde darauf geachtet, daß diese sich bei Bedarf einfach durch eine leistungsfähigere, kommerzielle Datenbank ersetzen läßt.
Die aktive Datenbankumgebung ist eine aktiv handelnde Schnittstelle zwischen der Gesamtdatenbank und den an sie angeschlossenen Programmodulen. Um das mit den anderen FTMPS-Partnern vereinbarte Ablaufprotokoll zur Fehlerbehandlung zu gewährleisten, wurden unter anderem mehrere als Endliche Automaten realisierte Programmodule implementiert, durch deren Einsatz Änderungen oder Ergänzungen des Ablaufprotokolls leicht nachvollzogen werden können.
Die Automaten der aktiven Datenbankumgebung kommunizieren untereinander und mit den an sie angeschlossenen und zu unterstützenden Modulen über eine auf UNIX-Sockets basierende Schnittstelle. Zur einfachen Kommunikation über Sockets wurde eine Library implementiert, die von allen Partnern genutzt werden kann.
Zur statistischen Analyse können Daten von mehreren MPS unterschiedlicher Standorte zu einer zentralen Gesamtdatenbank zusammengefaßt werden. Durch das Vergrößern der Datenbasis kann die statistische Sicherheit der Analysen erhöht und verschiedene Systeme können leicht miteinander verglichen werden. Die Daten können vom Statistikmodul über den zur aktiven Datenbank gehörenden Statistic Module Handler (STMH) ausgewertet werden. Der STMH wurde hierbei als Library realisiert, die in das Statistikmodul eingebunden werden kann.
Bei der Implementierung und den ersten Tests innerhalb einer selbst generierten Testumgebung zeigte sich, daß die Leistungsfähigkeit der Shareware-Datenbank MetalBase 5.0 für die Sammlung der Daten und die Unterstützung der die Fehlertoleranz erbringenden Softwaremodule ausreicht. MetalBase bietet den Vorteil, daß für die Nutzung aus der aktiven Datenbankumgebung nur eine sehr kompakte (ca. 96KByte) Library benötigt wird.
Da bei MetalBase weder umfangreiche Abfragerelationen noch eine Datenbank-Abfragesprache wie SQL zur Verfügung steht, empfiehlt sich für die statistische Auswertung der Daten jedoch der Einsatz einer leistungsfähigeren relationalen Datenbank mit einer Datenbank-Abfragesprache wie SQL. Durch bessere Abfragerelationen kann die Abfragegeschwindigkeit gesteigert werden, was vor allem bei einer Auswertung einer zentralen Datenbank mit Daten vieler MPS von Bedeutung sein kann. Durch den Einsatz einer Datenbank-Abfragesprache sinkt zum einen der Programmieraufwand für die Schnittstelle zwischen Datenbank und Statistikmodul, zum anderen kann eine größere Flexibilität erreicht werden. Darüberhinaus wird durch den Einsatz einer standardisierten Abfragesprache gewährleistet, daß auch die möglicherweise gewünschte Anbindung weiterer Programme an die zentrale Datenbank erleichtert wird.
Da sich das Gesamtprojekt noch in der Implementationsphase befindet, konnten nicht alle geplanten Module der aktiven Datenbankumgebung vollendet werden. Ferner könnten bei bereits implementierten Modulen Änderungen erforderlich werden. Dies wurde bei der Konzipierung der Datenbankumgebung berücksichtigt.
Das Modul Error Log Controller (ELC) der aktiven Datenbankumgebung, das unter anderem zum Verwalten der Fehlermeldungen mit hinzugefügten Auslastungsdaten zuständig ist, ist in vollem Umfang einsatzbereit. Änderungen könnten jedoch bezüglich der Verwaltung der Zuordnung zwischen Prozessoren und Partitionen notwendig werden, wenn auch Partitionsformen verwaltet werden sollen, die sich nicht als zweidimensionale oder dreidimensionale Gitter über zwei Eckpunkte festlegen lassen.
Das Modul Stress Value Handler (SVH) sammelt und berechnet die Auslastungsdaten der Prozessoren. Die Sammlung von Temperaturdaten aus dem MPS wurde noch nicht im SVH implementiert, da noch nicht geklärt werden konnte, wie und von welchem Programmodul diese Daten bereitgestellt werden können.
Das für die Verwaltung von Reparaturen zuständige Modul Repair Report Handler (RRH) existiert bereits. Die Spezifizierung der zum Datenaustausch und zur Speicherung benötigten Datenstrukturen muß aber nach einer Absprache mit dem für das Modul Operator (OPR) zuständigen Projektpartner nochmals verfeinert werden.
Mit der STMH-Library (STMH = Statistic Module Handler) können die im gegenwärtigen Entwicklungsstadium des Statistikmoduls benötigten Daten ermittelt werden. Falls die Arbeitsgeschwindigkeit erhöht werden muß, kann diese Library sicherlich noch überarbeitet werden oder sogar, wie oben geschildert, eine leistungsfähigere Datenbank genutzt werden.
Das Modul Checkpoint Recorder zur Aufzeichnung statistischer Daten über die Rücksetzpunkterstellung wurde noch nicht implementiert. Dies sollte nach Absprache mit den für die Sammlung der Rücksetzpunkte zuständigen Partnern erfolgen.
Die aktive Datenbankumgebung wird durch zwei sich noch in der Entwicklung befindende Module zur Operator Site Software ergänzt. Die grafische Benutzeroberfläche übernimmt die Visualisierung des Gesamtsystems und ermöglicht dem Systembetreuer die Verwaltung des MPS. Von ihr kann das Statistikmodul aufgerufen werden, mit dem dann die von der aktiven Datenbankumgebung gesammelten Daten analysiert werden können.
TREW, Arthur, WILSON, Greg. Past, Present, Parallel. A Survey of Available Parallel Computing Systems. Berlin, Heidelberg: Springer-Verlag, 1991.
Eine aktive Datenbankumgebung zur Unterstützung der Zuverlässigkeitsanalyse von massiv parallelen Systemen
This document was generated using the LaTeX2HTML translator Version 95 (Thu Jan 19 1995) Copyright © 1993, 1994, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
The command line arguments were:
latex2html -split 0 -ps_images -ascii_mode -show_section_numbers dipl_arb.tex.
The translation was initiated by Josef Sauerland on Wed Nov 29 00:46:40 MET 1995