DE69919632T2

DE69919632T2 - Fehlertoleranz durch N-modulare Softwareredundanz unter Verwendung von indirekter Instrumentierung

Info

Publication number: DE69919632T2
Application number: DE69919632T
Authority: DE
Inventors: Timothy North Plainfield Tsai
Original assignee: Lucent Technologies Inc
Current assignee: Nokia of America Corp
Priority date: 1998-06-19
Filing date: 1999-06-08
Publication date: 2005-09-15
Anticipated expiration: 2019-06-09
Also published as: EP0965922A3; JP3624119B2; DE69919632D1; EP0965922B1; US6161196A; JP2000081996A; EP0965922A2

Description

Technisches Gebiet
Die vorliegende Erfindung betrifft allgemein Datenverarbeitungssysteme und insbesondere Techniken zur Bereitstellung von Fehlertoleranz in solchen Systemen.
Allgemeiner Stand der Technik
Sowohl in verteilten als auch in nichtverteilten Datenverarbeitungssystemen ist es häufig erwünscht, einen Mechanismus bereitzustellen, durch den das System gegenüber Fehlern, wie zum Beispiel Prozeßausfällen und Maschinenausfällen, tolerant wird. Die wichtigsten Aspekte solcher Fehlertoleranzmechanismen sind im allgemeinen die Fehlererkennung und die Fehlerbehebung. Es wurden herkömmliche Datenverarbeitungssysteme implementiert, die in Verbindung mit Wahlen eine Prozeßduplikation verwenden, um Fehlerdetektion und Prüfpunkte zur Durchführung der Fehlerbehebung durchzuführen. Die Prozeßduplikation umfaßt im allgemeinen das Ausführen mehrerer Kopien eines gegebenen Zielprogramms auf verschiedenen Maschinen und wird auch als Programmierung des Typs "N-Version" oder "N-Modular" bezeichnet. Jede der Kopien des Programms gibt an spezifizierten Haltepunkten Datenwerte zurück und der Wahlprozeß wird dazu verwendet, zu bestimmen, ob etwaige der Prozesse oder Maschinen ausgefallen sind. Wenn zum Beispiel die zurückgegebenen Daten aus allen außer einer der Kopien dieselben sind, kann angenommen werden, daß es bei der Minderheitskopie zu einem Ausfall gekommen ist. Bei einem solchen Ausfall wird unter Verwendung einer der ordnungsgemäß ausgeführten Kopien ein Prüfpunkt genommen und der ausgefallene Prozeß wird von dem Prüfpunkt an neu gestartet. Einzelheiten bezüglich dieser und anderer herkömmlicher Techniken werden zum Beispiel in J. Long, W.K. Fuchs und J.A. Abraham, "Forward recovery using checkpointing in parallel systems", Proc. IEEE International Conference on Parallel Processing, S. 272-275, 1990; D.K.Pradhan und N.H. Vaidya, "Roll-forward and rollback recovery: Performance-reliability trade-off", Proc. 24^th Fault-Tolerant Computing Symposium, S. 186-195, 1994; D.K. Pradhan und N.H. Vaidya, "Roll-forward checkpointing scheme: A novel fault-tolerant architecture", IEEE Transactions on Computers, 34(10):1163-1174, Oktober 1994; D.K.Pradhan und N.H. Vaidya, "Roll-forward and rollback recovery:Performance-reliability trade-off", Proc. 24^th Fault-Tolerant Computing Symposium, Seiten 186-195, 1994; und in Algirdas A. Avizienis, "The Methodology of N-Version Programming", in Michael R.Lyu, Hersg., Software Fault Tolerance, S. 23-46, John Wiley & Sons Ltd., 1995, beschrieben.
Herkömmliche Fehlertoleranztechniken erfordern im allgemeinen die Modifikation entweder von Quellcode oder binärem ausführbarem Code, um die oben erwähnte Fehlerdetektions- und Behebungsfunktionalität hinzuzufügen. Diese Modifikationen werden in der Regel vor der Ausführung des Zielprogramms durchgeführt und erfordern häufig vom Benutzer, Dateien zu editieren oder direkte Instrumentationssoftware auszuführen, was ineffizient sein kann. Außerdem haben herkömmliche Techniken, die ein Betriebssystem verwenden, um Fehler zu erkennen, den Nachteil, daß sie nicht in der Lage sind, die Datenintegrität zu erhalten, wenn keine Betriebssystemprogrammausnahme ausgelöst wird. Andere herkömmliche Methoden verwenden Detektionsverfahren auf Algorithmusbasis, die im allgemeinen für viele Arten von Programmen nicht anwendbar sind.
Aus Bondavallia et al.: "State restoration in a COTS-based N-modular architecture", Object-oriented realtime-distributed computing, 1998 (ISORC 98), Proceedings 1998 First International Symposium On, Kyoto, Japan, 20.-22.4.1998, Los Alamitos, CA, USA, IEEE Comput. Soc., US, 20.4.1998, Seiten 174-183, ISBN: 0-8186-8430-5, ist ein Verfahren für ein fehlertolerantes System bekannt, bei dem Duplikate eines Programms unter der Kontrolle einer Steuerung ausgeführt und Werte von Variablen am Ende einer Iteration verglichen werden, um Fehler zu erkennen.
Kurze Darstellung der Erfindung
Die in den Ansprüchen definierte Erfindung verwendet eine als indirekte Softwareinstrumentation bezeichnete Technik, um Fehlertoleranz in einem Datenverarbeitungssystem zu erreichen. Ein Ausführungsbeispiel wird in einem System implementiert, das eine Anzahl von Computern oder anderen Maschinen enthält. Verschiedene Kopien eines gegebenen Zielprogramms werden auf verschiedenen Maschinen in dem System ausgeführt. Jede der Maschinen, die eine Kopie des Zielprogramms ausführt, enthält eine Steuerung, die die Ausführung dieser Kopie steuert. Die Steuerungen kommunizieren mit einer Benutzerschnittstelle eines Instrumentationswerkzeugs, das auf einer anderen Maschine implementiert sein kann. Ein Benutzer führt einen Dialog mit der Schnittstelle, um folgendes zu spezifizieren: die Variablen, die überwacht oder "gewählt" werden sollen, Haltepunkte, an denen das Wählen stattfindet, Wahl- und Behebungsparameter und andere Informationen, und das Werkzeug übermittelt entsprechende Befehle zu jeder der Steuerungen. Ein Fehler in einer der Kopien wird erkannt, indem Werte einer oder mehrerer der benutzerspezifizierten Variablen, die durch die verschiedenen Kopien an den gekennzeichneten Haltepunkten erzeugt werden, verglichen werden. An einem gegebenen Haltepunkt melden die Steuerungen diese Werte einem Wahlverarbeitungsmechanismus, der auf einer oder mehreren der Maschinen des Systems implementiert werden kann, und der Wahlverarbeitungsmechanismus bestimmt, ob ein Fehler aufgetreten ist. Bei Erkennung eines Fehlers in einer gegebenen der Kopien wird ein Prüfpunkt einer anderen der Kopien genommen, von der bestimmt wurde, daß sie fehlerfrei ist, und eine neue Kopie wird von dem Prüfpunkt an neu gestartet. Die Verwendung getrennter Steuerungen zur Steuerung der Ausführung jeder der Kopien des Zielprogramms auf der Basis von benutzerspezifizierten Informationen ermöglicht es, Fehler zu erkennen und entsprechende Behebungsmaßnahmen zu treffen, ohne Zielprogrammcode zu modifizieren. Andere Ausführungsformen können unter Verwendung einer einzigen Maschine zur Ausführung jeder der Kopien implementiert werden oder können mehrere Kopien auf bestimmten Maschinen ausführen.
Die Erfindung stellt eine allgemeine Fehlererkennungs- und -Behebungstechnik bereit, die Datenintegrität für kritische Daten sicherstellt, ohne daß jegliche Modifikationen von Quellcode oder ausführbarem Code notwendig sind, während außerdem ein hoher Grad an Automation und Transparenz für fehlertolerante Konfiguration und fehlertoleranten Betrieb bereitgestellt wird. Die Erfindung eignet sich zur Verwendung mit vielen verschiedenen Arten von Programmen. Zusätzlich gibt die Erfindung die Möglichkeit, eine Fehlererkennung für Anwendungen durchzuführen, für die kein Quellcode oder nur eine minimale Kenntnis des Codes verfügbar ist, darunter sogenannte "Legacy-Anwendungen". Zu den Arten von Fehlern, die in dem Ausführungsbeispiel toleriert werden, gehören transiente und permanente Hardwarefehler auf einer einzigen Maschine und bestimmte Arten von Anwendungs- und Betriebssystemsoftwarefehlern, obwohl andere Ausführungsformen andere Arten von Fehlertoleranz liefern können.
Kurze Beschreibung der Zeichnungen
1 ist ein Blockschaltbild eines Ausführungsbeispiels für ein indirektes Instrumentationssoftwarewerkzeug, das zur Implementierung und Fehlertoleranz gemäß der vorliegenden Erfindung verwendet werden kann;
2 zeigt verschiedene Betriebsarten, die von der Ausführungsform von 1 unterstützt werden;
3 und 4 zeigen graphische Erzeugungs- bzw. erzeugte Benutzeroberflächen (GUIs);
5 und 6 zeigen ausführlichere Ansichten des Frontend- bzw. des Backend-Teils des Instrumentationswerkzeugs von 1;
7 zeigt ein Ausführungsbeispiel für ein Datenverarbeitungssystem gemäß der Erfindung, das indirekte Instrumentation zur Bereitstellung von Fehlertoleranz verwendet;
8 zeigt Prüfpunkte in der Ausführungsform von 7; und
9 ist ein Impulsdiagramm der Funktionsweise der Ausführungsform von 7.
Ausführliche Beschreibung der Erfindung
Die vorliegende Erfindung wird nachfolgend in Verbindung mit einem beispielhaften Datenverarbeitungssystem erläutert. Es versteht sich jedoch, daß die Erfindung nicht auf die Verwendung mit irgendeiner bestimmten Art von Datenverarbeitungssystem beschränkt ist, sondern statt dessen allgemeiner auf jede Datenverarbeitungsumgebung oder -Anwendung anwendbar ist, bei der es erwünscht ist, Fehlertoleranz auf effizientere Weise als bisher möglich bereitzustellen. Die offengelegten Techniken können mit Computern oder andern Maschinen verwendet werden, die in lokalen Netzwerken, großflächigen Netzwerken, städtischen Netzwerken, Intranets, Extranets und globalen Netzwerken, wie zum Beispiel dem Internet, angeordnet sind. Der Begriff "Programm" soll hier jede Art von Anweisung, Code, Prozeß, Thread oder dergleichen bedeuten, die auf einem Computer oder einer anderen Maschine in einem Datenverarbeitungssystem abläuft. Der Begriff "verteiltes System" soll jedes System bedeuten, das zwei oder mehr Computer oder andere Maschinen enthält. Der Begriff "Maschine" soll hier einen Computer, eine Workstation oder eine beliebige andere Art von Datenverarbeitungseinrichtung sowie verschiedene Komponenten solcher Einrichtungen bedeuten. Der Ausdruck "abgesetzte Maschine" soll hier allgemein einen beliebigen Computer, eine beliebige Workstation oder eine beliebige andere Datenverarbeitungseinrichtung bedeuten, der bzw. die im Namen einer anderen Maschine einen Prozeß ausführt. Eine abgesetzte Maschine gemäß der Erfindung muß deshalb nicht geographisch von der Hostmaschine abgesetzt sein. Der Ausdruck "indirekte Instrumentation" bedeutet eine Instrumentation, die implementiert werden kann, ohne entweder den Quellcode oder den ausführbaren Code eines instrumentierten Zielprogramms direkt zu verändern. Ein "Instrumentationswerkzeug" bedeutet allgemein ein beliebiges Softwareprogramm, das mindestens einen Teil eines Instrumentationsprozesses implementiert. Der Begriff "Steuerung" bedeutet allgemein ein beliebiges Softwareprogramm oder einen anderen Mechanismus, das bzw. der eine oder mehrere der hier als einem Backend eines Instrumentationswerkzeugs zugeordneten Funktionen bereitstellt und kann das gesamte Backend oder auch ein Element oder Elemente des Backend bedeuten.
Softwareinstrumentation bedeutet allgemein den Vorgang des Modifizierens eines Programms, um zusätzlichen Code, der als Instrumentationscode bezeichnet wird, der verschiedene Arten von Überwachung und Analyse der Programmleistung während der Programmausführung bereitstellen soll, hinzuzufügen. Zusätzlich zu der Überwachung und Analyse der Programmleistung umfaßt Instrumentation auch andere Aktivitäten, wie zum Beispiel Modifikationen für Fehlertoleranz, z.B. Prüfpunkte und Fehlerinjektion. Instrumentation umfaßt also in der Regel eine bestimmte Modifikation eines Zielprogramms, um Funktionalität zu verändern oder hinzuzufügen. Zum Beispiel kann man mit Instrumentationscode Anzeigen bereitstellen, ob bestimmte Zweige genommen werden oder nicht, wenn ein Programm mit einer gegebenen Menge von Eingaben ausgeführt wird, oder einen Prozessor während der Ausführung unterbrechen, um dabei zu helfen, Fehler zu finden.
1 zeigt die allgemeine Architektur eines indirekten Instrumentationssoftwarewerkzeugs, mit dem gemäß der vorliegenden Erfindung Fehlertoleranz bereitgestellt werden kann. Diese Ausführungsform wird in einem verteilten System 10 implementiert, das eine Benutzermaschine 12 und eine abgesetzte Maschine 14 enthält. Die Benutzermaschine 12 und die abgesetzte Maschine 14 kommunizieren über ein Kommunikationsmedium 15, das bei dieser Ausführungsform eine webeingebettete Anwendungsschicht 16 und eine herkömmliche TCP/IP-Schicht (Transmission Control Protocol/Internet Protokol) 18 enthält. Die web-eingebettete Anwendungsschicht 16 kann ein beliebiger geeigneter Nachrichtenweiterleitungsmechanismus sein, der so konfiguriert ist, daß er mit der TCP/IP-Schicht 18 zusammenwirkt. In alternativen Ausführungsformen können andere Arten von Kommunikationsmedien verwendet werden. Außerdem können andere Ausführungsformen des indirekten Instrumentationswerkzeugs mit nur einer Maschine oder mit mehr als zwei verschiedenen Maschinen implementiert werden.
Das indirekte Instrumentationssoftwarewerkzeug enthält einen "Frontent"-Teil und einen "Backend"-Teil. Das Frontend wird auf der Benutzermaschine 12 implementiert und enthält unter anderen Elementen eine graphische Benutzeroberfläche (GUI) 20 des Typs "Erzeugung". Bei dem Frontend kann es sich zum Beispiel um eines oder mehrere Java-Applets handeln, die auf einem Computer mit Java-Fähigkeit oder einer anderen geeigneten Maschine ausgeführt werden. Das Backend wird auf der abgesetzten Maschine 14 implementiert und enthält zwei Softwareprozesse: ein Zielprogramm 22, d.h. das Programm, das instrumentiert werden soll, und Backend-Software 24, die die Instrumentation an dem Zielprogramm 22 durchführt. Wie später ausführlicher beschrieben wird, kann die Backend-Software 24 aus mehreren Prozessen und Threads bestehen. In dem Zielprogramm 22 repräsentiert das Element 25 die Steuerflußausführung des Zielprogramms und das Element 26 den Datenraum des Zielprogramms. Die Backend-Software 24 enthält eine Steuerung 27. Das Frontend liefert eine Schnittstelle zwischen dem Benutzer und der Backend-Software 24, die das Zielprogramm 22 steuert. Bei einer fehlertoleranten Datenverarbeitungsimplementierung dient das Frontend außerdem zur Bereitstellung von Wahlfunktionen und Koordination mehrerer Backends. Die GUI 20 des Frontend wird vorzugsweise per Zeigen-und-Klicken gesteuert und enthält Pulldown-Menüs, Fenster, Listen, Schaltflächen und Textfelder, wie in Verbindung mit 3 ausführlicher beschrieben werden wird.
Die auf der abgesetzten Maschine 14 ablaufende Steuerung 27 lenkt den Steuerfluß des Zielprogramms 22 und liefert Beobachtbarkeit in den internen Zustand des Programms 22, während es ausgeführt wird. Die Steuerung 27 hat die Fähigkeit, das Zielprogramm zu lenken, um die Ausführung an einem beliebigen Punkt zu beginnen, zu suspendieren und zu beenden. Außerdem kann sie den gesamten Datenraum des Zielprogramms, einschließlich statischer und dynamischer Daten und Prozessorregister beobachten und manipulieren. Die Steuerung 27 kann einen Debugger enthalten, wie zum Beispiel einen herkömmlichen gdb- oder dbx-Debugger, oder eine durch das Betriebssystem bereitgestellte Einrichtung auf niedriger Ebene, z.B. eine herkömmliche ptrace-Einrichtung oder das /proc-Dateisystem in UNIX, die als Teil des Backend dient, das das Zielprogramm 22 direkt steuert und mit diesem kommuniziert. Es wird angenommen, daß bei dem Ausführungsbeispiel die Steuerung 27 den gdb-Debugger enthält, so wie er in R.M. Stallman, "Debugging with GDB: the GNU Source-Level Debugger", Auflage 4.12, Januar 1994, beschrieben wird. Obwohl es Alternativen zur Verwendung in der Steuerung 27 gibt, liefert gdb die gewünschte Funktionalität und wurde umfassend geprüft und auf viele Plattformen portiert. Die Steuerung 27 erlaubt eine Automatisierung indirekter Instrumentation, sodaß die Menge an handcodiertem Instrumentationscode soweit wie möglich reduziert wird. Der Benutzer des Instrumentationswerkzeugs tritt im wesentlichen mit der GUI 20 des Frontend in Dialog, während die Instrumentation durch die Steuerung 27 des Backend durchgeführt wird. Die verteilte Konfiguration des indirekten Instrumentationssoftwarewerkzeugs erweitert seine Nützlichkeit über herkömmliche Softwareinstrumentation hinaus und ermöglicht die Implementierung verteilter Softwarefehlertoleranz auf eine später zu beschreibende Weise.
Es ist zu beachten, daß, obwohl das Instrumentationswerkzeug bei dem Ausführungsbeispiel eine Steuerung enthält, die als eine ihrer Komponenten einen Debugger aufweist, das Werkzeug selbst zusätzliche Fähigkeiten bereitstellt, die in der Regel in einem Debugger nicht angetroffen werden. Ein Debugger ist im allgemeinen dazu in der Lage, viele Tasks auf niedriger Ebene durchzuführen, wie zum Beispiel das Verwalten von Haltepunkten, das Ausführen von Debugger-Befehlen, wenn Haltepunkte angetroffen werden, und das Drucken und Modifizieren der Werte von Variablen. Im Gegensatz dazu konfiguriert das Instrumentationswerkzeug bei dem Ausführungsbeispiel den Debugger in der Steuerung 27 dafür, alle notwendigen Tasks auf automatisierte, transparente und verteilte Weise durchzuführen. Zusätzlich fügt das Instrumentationswerkzeug die Fähigkeit des Integrierens und Ausführens von benutzerspezifiziertem Code in Verbindung mit dem Zielprogramm 22 hinzu, um Tasks durchzuführen, die ein Debugger alleine nicht durchführen kann. Das Instrumentationssoftwarewerkzeug liefert außerdem weitere einzigartige Merkmale, wie zum Beispiel einen automatisierten Rückmeldemechanismus, der den oben erwähnten benutzerspezifizierten Code auslöst, wenn ein gekennzeichnetes Ereignis auftritt.
2 zeigt zwei Betriebsarten des Instrumentationswerkzeugs von 1. Wie bereits erwähnt, unterstützt das Instrumentationswerkzeug die Instrumentation eines Zielprogramms 22 durch Bereitstellen einer Erzeugungs-GUI 20. In einer interaktiven Betriebsart ermöglicht es die Erzeugungs-GUI 20 dem Benutzer, eine angepaßte "erzeugte" GUI 30 zu erzeugen, die dann wie gezeigt mit einem Backend 28 verbunden werden kann. Sowohl die Erzeugungs-GUI 20 als auch die erzeugte GUI 30 sind dem Frontend-Teil des Instrumentationswerkzeugs zugeordnet und laufen deshalb bei dem Ausführungsbeispiel auf der Benutzermaschine 12 ab. Das Backend 28 enthält die Backend-Software 24 mit der Steuerung 27 und wird auf der abgesetzten Maschine 14 implementiert. Während der Benutzer mit der Erzeugungs-GUI 20 in Dialog tritt, wird die erzeugte GUI 30 in einem separaten Fenster aufgebaut, das sofort begutachtet und gegebenenfalls modifiziert werden kann. Die Erzeugungs-GUI 20 fordert Zielprogramminformationen von dem Backend 28 an, wie durch die gestrichelte Linie angezeigt, und das Backend 28 antwortet der erzeugten GUI 30 mit den angeforderten Informationen, wie durch die durchgezogene Linie angezeigt. Wenn der Benutzer mit der Instrumentation und der erzeugten GUI 30 zufrieden ist, kann eine Endversion der erzeugten GUI 30 für einen selbständigen Betrieb erzeugt werden, bei dem diese Version unabhängig von der Erzeugungs-GUI 20 ausgeführt werden kann. In dieser selbständigen Betriebsart fordert die erzeugte GUI 30 Zielprogramminformationen während der Zielprogrammausführung direkt von dem Backend 28 an, wie durch die gestrichelte Linie angezeigt, und das Backend 28 antwortet der erzeugten GUI 30 mit den angeforderten Informationen, wie durch die durchgestrichene Linie angezeigt. Ein Benutzer tritt in der Regel zuerst in den interaktiven Modus ein, um die erzeugte GUI 30 anzupassen und die resultierende erzeugte GUI 30 dann in der selbständigen Betriebsart auszuführen.
3 und 4 zeigen Beispiele für eine Erzeugungs-GUI 20 bzw. eine erzeugte GUI 30 gemäß der Erfindung. Die Erzeugungs-GUI 20 von 3 enthält ein Quellenlistenfenster 40, eine Funktionsliste 42, eine Liste globaler Variablen 44 und eine Liste lokaler Variablen 46. Eine aus der Funktionsliste 42 ausgewählte gegebene Funktion wird in der Liste 42 hervorgehoben und wie gezeigt in einem Textfeld 52 angezeigt. Die entsprechenden globalen und lokalen Variablen für die gewählte Funktion werden in der jeweiligen Liste globaler Variablen 44 und der Liste lokaler Variablen 46 angezeigt, während der Quellcode für die Funktion in dem Quellenlistenfenster 40 angezeigt wird. Es werden mehrere Schaltflächen bereitgestellt, darunter eine Zähler-Widget-Schaltfläche 54, eine Textfeld-Widget-Schaltfläche 56 und eine Textbereichs-Widget-Schaltfläche 58. Durch diese Schaltflächen kann ein Benutzer bestimmte Widgets spezifizieren, die in der erzeugten GUI 30 erscheinen. Zum Beispiel kann man mit der Zähler-Widget-Schaltfläche 54 eine bestimmte in einem visuell wahrnehmbaren Format in der erzeugten GUI 30 zu überwachende Variable spezifizieren. Ein solches Format ist ein horizontaler Balken, dessen Länge proportional zu dem Wert der zugeordneten Variablen ist. Andere Arten von Widgets sind zum Beispiel Kreisdiagramm- Widgets, Zeitlinien-Widgets usw. Diese und andere Widget-Klassen können in einer grundlegenden graphischen Widget-Bibliothek enthalten sein, die vom Benutzer erweitert werden kann.
Obwohl es in 3 nicht gezeigt ist, können mehrere Pulldown-Menüs in der Erzeugungs-GUI 20 bereitgestellt werden. Zum Beispiel kann die Erzeugungs-GUI 20 ein Menü für Befehle enthalten, die mit dem Zielprogramm als ganzes zusammenhängen, wie zum Beispiel Befehle zum Laden, Ausführen, Unterbrechen, periodischen Unterbrechen oder Beenden des Zielprogramms. Ein anderes Menü kann Instrumentationsbefehle bereitstellen, wie zum Beispiel Befehle zum Setzen von Quellcodezeilen zugeordneten Haltepunkten oder Befehle zum Spezifizieren von Triggermechanismen für benutzerdefinierte Funktionen. Durch die Erzeugungs-GUI 20 kann ein Benutzer also durch das Instrumentationswerkzeug bereitgestellte Instrumentationsoperationen auswählen und konfigurieren. Wenn zum Beispiel ein bestimmter aus einem Pulldown-Menü ausgewählter Instrumentationsbefehl benutzerspezifizierte Parameter erfordert, kann der Benutzer diese Parameter über eine Tastatur in ein entsprechendes Textfeld eingeben. Die in den Fenstern und Listen der Erzeugungs-GUI 20 angezeigten Zielprogramminformationen können wie bereits beschrieben durch die Erzeugungs-GUI 20 von dem Backend angefordert werden.
Die erzeugte GUI 30 von 4 enthält ein Fenster 60 zum Auflisten von durch den Benutzer in der Erzeugungs-GUI 20 spezifizierten Haltepunktaktionen und ein Fenster 62 zum Auflisten von Benachrichtigungen, die als Antwort auf die Haltepunktaktionen oder andere benutzerspezifizierte Instrumentation von dem Backend empfangen werden. Die erzeugte GUI 30 enthält ferner eine Menge von variablen Beobachtungsfenstern 64, 66 und 68 zum Spezifizieren des aktuellen Status gewählter Variablen I, len bzw. time ptr. Es ist zu beachten, daß die gewählten Variablen das gewählte Zielprogramm veranschaulichen und daß viele andere Arten von Variablen überwacht werden könnten. Die variablen Beobachtungsfenster sind Beispiele für Zähler-Widgets, die durch Verwendung der Zähler-Widget-Schaltfläche 54 in der Erzeugungs-GUI 20 von 3 spezifiziert werden können. Die erzeugte GUI 30 liefert somit eine Anzeige der aus der Erzeugungs-GUI 20 erzeugten benutzerspezifizierten Instrumentation. Wie bereits erwähnt, kann die erzeugte GUI 30 in einer selbständigen Betriebsart ausgeführt werden, bei der sie mit dem Backend in Dialog treten kann, um die notwendigen Informationen bezüglich des Zielprogramms zu erhalten, während das Programm ausgeführt wird. Ein Benutzer erzeugt mit den Instrumentationserzeugungsmerkmalen der Erzeugungs-GUI 20 eine angepaßte erzeugte GUI 30, die mit dem Backend in Dialog tritt, um die für die Instrumentation erforderlichen Zielprogramminformationen bereitzustellen.
5 zeigt ein beispielhaftes Frontend 100 des Instrumentationswerkzeugs ausführlicher. Das Frontend 100 enthält die Erzeugungs-GUI 20 und die erzeugte GUI 30, wie bereits beschrieben. Die erzeugte GUI 30 enthält Textbereichscode 30A, Zähler-Widget-Code 30B und Textfeldcode 30C. Die Codemengen 30A, 30B und 30C sind für die Erzeugung entsprechender Teile der graphischen Anzeige der erzeugten GUI 30 (siehe 4) verantwortlich. Die graphische Ausgabe der Codemengen 30A, 30B und 30C wird abhängig davon, ob sich der Benutzer dafür entscheidet, das bestimmte Widget als Teil der GUI 30 zu verwenden, als Teil der erzeugten GUI 30 angezeigt. Das Frontend 100 enthält ferner ein PCP-Element (Prism Communications Protocol) 102 zur Implementierung von Übermittlungen zwischen dem Frontend 100 und einem oder mehreren Backends und einen Backend-Zuhörer 104 zum Empfangen von Übermittlungen aus einem oder mehreren Backends über das Kommunikationsmedium 15.
6 zeigt ein beispielhaftes Backend 28 ausführlicher. Um die vielfältigen, von ihm geforderten Verantwortlichkeiten abzuhandeln, ist das Backend bei dieser Ausführungsform in mehrere verschiedene Komponenten aufgeteilt. Diese Komponenten werden im allgemeinen parallel ausgeführt, wobei bestimmte als Fork-Prozesse und andere als Threads ausgeführt werden. Sofern möglich werden immer Threads verwendet, außer wenn die Komponenten selbst zusätzliche Prozesse forken müssen. Mehrere Threads können einen einzigen Prozeß bilden, da sie sich denselben Speicherraum teilen. In 6 zeigen dicke durchgezogene Pfeile ein Fork eines gegebenen Prozesses an und dünne durchgezogene Pfeile einen Thread eines gegebenen Prozesses, und gestrichelte Pfeile zeigen Kommunikation an. Das Backend 28 enthält bei dieser Ausführungsform einen main-Prozeß 110 der seine Funktionsweise steuert. Ein Debugger-Prozeß gdb und ein weiterer Prozeß surrogate werden als Forks von dem main-Prozeß gestartet und readgdb, readweasl und readsurrogate sind Threads des main-Prozesses. Der readgdb-Thread ist für das Lesen von Informationen von dem gdb-Prozeß verantwortlich, der readweasl-Thread für das Lesen von Informationen von dem Kommunikationsmedium 15 und der readsurrogate-Thread für das Lesen von Informationen von dem surrogate-Prozeß. Der gdb-Prozeß steuert durch das Backend 28 unternommene Debugger-Operationen, wie durch einen als ein Fork von dem gdb-Prozeß gestarteten target-Prozeß dargestellt. Der surrogate-Prozeß steuert durch das Backend 28 unternommene Aktionen, wie durch einen als Fork von dem surrogate-Prozeß gestarteten action-Prozeß dargestellt.
Wie bereits erwähnt, dient das Backend 28 als Steuerung für das Zielprogramm. Alle Anforderungen von dem Frontend 100 werden durch das Backend abgewickelt, und alle Ausgaben aus dem Zielprogramm 22 an das Frontend werden durch das Backend transferiert. Also ist das Backend bei dieser Ausführungsform die einzige Schnittstelle zwischen dem Frontend und dem Zielprogramm. Die Operationen, die das Backend an dem Zielprogramm durchführt, bilden die Grundlage für indirekte Instrumentation. Das Backend dient nicht nur als die Schnittstelle zwischen dem Zielprogramm und dem Frontend, sondern führt zusätzlich wichtige Funktionen durch. Erstens können immer dann, wenn eine gewünschte Triggerbedingung angetroffen wird, durch den Benutzer auszuführende Backend-Aktionen spezifiziert werden. Diese Aktionen führen Berechnungen durch, verändern die Ausführung des Zielprogramms, einschließlich Zielprogrammvariablenwerte, senden Ausgaben zu dem Frontend, fahren zusätzliche Programme herauf oder führen andere Funktionen durch. Zusätzlich zu der Implementierung von Aktionen kann das Backend außerdem seine eigenen internen Zähler enthalten, die zusätzlich zu den Zielprogrammvariablen als Variablen verwendet werden können. Diese Backend-Aktionen und -Zähler sind sehr leistungsstark und geben die Möglichkeit, die Ausführung des Zielprogramms auf vielfältige Weisen zu verändern.
Gemäß der Erfindung kann man mit dem oben beschriebenen Instrumentationswerkzeug Fehlertoleranz in einem Datenverarbeitungssystem bereitstellen. Indirekte Instrumentation ist nützlich, um Funktionalität so zu einem Programm hinzuzufügen, daß viel Transparenz und Automatisierung für den Benutzer bereitgestellt wird. Dies gilt insbesondere für das Hinzufügen von Fehlertoleranz zu einem Programm, das ohne jegliche expliziten Fehlertoleranzfähigkeiten entwickelt wurde. Mit indirekter Instrumentation kann ein solches nichtfehlertolerantes Programm nach einigen wenigen Konfigurationsminuten über eine Erzeugungs-GUI in einer fehlertoleranten Betriebsart ausgeführt werden. Es ist kein Modifizieren oder Neukompilieren von Quellcode erforderlich, da die Fehlerdetektions- oder Behebungssoftware hauptsächlich in dem Steuerungsprogramm enthalten ist. Es sollte beachtet weden, daß die Erfindung keinen Zugang zu Quellcode erfordert, sodaß durch Verwendung der Techniken der Erfindung sogar sogenannter "Legacy"-Code fehlertolerant gemacht werden kann. Wenn der Zielprogramm-Quellcode nicht verfügbar ist, kann die Instrumentation durch Verwendung einer an das Zielprogramm angebundenen Symboltabelle durchgeführt werden. Wenn keine Symboltabelle verfügbar ist, können alle Referenzen auf das Zielprogramm über virtuelle Adressen erfolgen.
Die auf indirekter Instrumentation basierende Fehlertoleranz gemäß der Erfindung kann allgemein anwendbare Fehlerdetektion bereitstellen, die die Datenintegrität für eine explizit ausgewählte Menge kritischer Daten erhält. Die bei der nachfolgend zu beschreibenden Ausführungsform tolerierten Fehlertypen umfassen alle Einzelerscheinungen transienter oder permanenter Hardwarefehler, sowie Softwarefehler, die Fehlerbedingungen in der Betriebsumgebung verursachen. In dieser Ausführungsform nicht erkannte Fehler sind zum Beispiel Kommunikationsfehler und andere Softwarefehler, die nur interne Wertfehler verursachen.
7 zeigt ein Ausführungsbeispiel für ein Datenverarbeitungssystem mit Fehlertoleranz gemäß der Erfindung. Diese Ausführungsform enthält eine Frontend 100 und drei separate Backends 28-1, 28-2 und 28-3, die auch als Backend1, Backend2 bzw. Backend3 bezeichnet werden. Das Frontend 100 und die drei Backends 28-i können jeweils auf die oben beschriebene Weise konfiguriert werden. Es wird in diesem Beispiel angenommen, daß das Frontend 100 und die Backends 28-i jeweils einer verschiedenen Maschine entsprechen, obwohl die Erfindung dies nicht erfordert. Das Plazieren des Frontends und der Backends auf verschiedenen Maschinen maximiert tendentiell die Leistung und die Fehlereingrenzung für jedes Backend. Bei anderen Ausführungsformen können eines oder mehrere des Frontend 100 und der Backends 28-i auf derselben Maschine implementiert werden. Wie bereits erwähnt, sind die wichtigsten Aspekte der Fehlertoleranz im allgemeinen Fehlererkennung und Fehlerbehebung. Fehlererkennung in der Ausführungsform von 7 wird über Duplikation eines gegebenen Zielprogramms auf drei verschiedenen Maschinen erreicht, wobei jede Kopie des Zielprogramms durch eines der separaten Backends 28-i auf einer der Maschinen gesteuert wird. Diese Backends kommunizieren mit einem einzigen Frontend 100, das als ein Koordinator für die Backends 28-i dient und wirkt, um Diskrepanzen zwischen verschiedenen Kopien des Zielprogramms zu bestimmen, während die Kopien ausgeführt werden. Die Behebung von erkannten Fehlern wird über einen Prüfpunkt- und Neustartmechanismus erreicht, der nachfolgend beschrieben wird.
Im Betrieb kann jede der Kopien des Zielprogramms am Anfang der ersten Programmanweisung vorübergehend gestoppt werden. An diesem Punkt wählt der Benutzer die gewünschten Wählparameter, z.B. Variablen, an denen gewählt werden soll, und Wählzeiten, und Behebungsparameter, unter Verwendung einer Erzeugungs-GUI des Frontend 100. Bei anderen Ausführungsformen spezifiziert der Benutzer nur eine Teilmenge dieser und anderer ähnlicher Parameter. Das Frontend 100 sendet dann die entsprechenden Befehle zu jedem der Backends 28-i. Die oben beschriebene Frontend-Erzeugungs-GUI kann auf einfache Weise modifiziert werden, um diese Benutzerspezifikation der Wählparameter und Behebungsparameter zu erlauben. Wenn die entsprechenden Haltepunkte durch die Backends 28-i eingefügt wurden, wird die Ausführung aller Kopien des Zielprogramms wieder aufgenommen. Für jeden Haltepunkt meldet jedes Backend 28-i den Wert vorgewählter kritischer Variablen dem Frontend 100. Wenn das Frontend 100 findet, daß alle gemeldeten Werte identisch sind, weist es jedes Backend 28-i an, die Ausführung seiner Kopie des Zielprogramms fortzusetzen.
8 zeigt eine Situation, in der das Frontend 100 eine Divergenz in den gemeldeten Werten aus den Backends 28-i erkennt. Das Backend mit dem Minderheitswert wird als das fehlerhafte Backend identifiziert und die Ausführung des Zielprogramms wird auf der entsprechenden Maschine beendet. Das fehlerhafte Backend ist in diesem Beispiel Backend2 (28-2). Dann wird von einem der nicht fehlerhaften Backends, z.B. Backend1 (28-1), ein Prüfpunkt genommen, und diese Prüfpunktdaten werden auf die Maschine mit dem fehlerhaften Backend, d.h. Backend2 (28-2), kopiert und ein neues Zielprogramm wird unter Verwendung der Prüfpunktdaten auf Backend2 eingeleitet. Auf diese Weise werden durch einen Prüfpunkt-Behebungsmechanismus Fehler erkannt und korrigiert.
Man beachte, daß bei dieser Ausführungsform ein Prüfpunkt nur genommen wird, wenn ein Fehler erkannt wird, was relativ selten auftreten sollte. Alternative Ausführungsformen könnten jedoch andere Arten von Prüfpunkten verwenden, darunter periodische Prüfpunkte. Das Frontend 100 wirkt bei dem Ausführungsbeispiel als Wahlzähler für Daten, die aus den duplizierten Backends 28-i gesammelt werden. Der von dem Frontend 100 verwendete Wahlverwaltungscode kann Verwaltungscode zur Synchronisation der Backends enthalten. Das libckp-Prüfpunktpaket, das in Y.M. Wang, Y. Huang, K.P. Vo, P.Y. Chung und C. Kintala, "Checkpointing and Its Applications", Proc. 25^th Fault-Tolerant Computing Symposium, S. 22-31, 1995, beschrieben wird, kann für die Behebung verwendet werden, um Neustart und Migration von Zielprogrammprozessen durchzuführen, die als fehlerhaft bestimmt wurden. Es kann eine beliebige Anzahl von Backends und deshalb jede beliebige Anzahl von Kopien des Zielprogramms unterstützt werden, obwohl im allgemeinen mindestens drei Backends erforderlich sind, um eine Fehlererkennung in dem Ausführungsbeispiel von 7 durchzuführen.
Obwohl die tatsächliche Wahlverarbeitung bei der obigen Ausführungsform auf einem einfachen Vergleich gemeldeter Werte basieren kann, sollte man eine Anzahl von Problemen berücksichtigen. Zum Beispiel werden die Kopien des Zielprogramms im allgemeinen unabhängig ausgeführt. Es kann also ein Synchronisationsmechanismus notwendig sein, um sicherzustellen, daß sich alle Kopien des Zielprogramms an dem identischen logischen Ausführungspunkt befinden, wenn die Werte gemeldet werden. Ein zweckmäßiges Verfahren, um diese Synchronisation zu garantieren, besteht darin, Haltepunkte an denselben Adressen in allen Kopien einzufügen. Die Haltepunkte dienen als eine Art von Barrierensynchronisation, wobei alle Kopien warten müssen, bis die letzte Kopie den Haltepunkt erreicht. Außerdem sollte eine Wahlverarbeitung nur an Daten durchgeführt werden, die deterministisch und daher garantiert für alle Kopien identisch sind, was gewöhnlich Daten wie zum Beispiel Maschinennamen, nichtglobale Taktzeiten und dynamische virtuelle Adressen ausschließt. Die Daten sollten in einem standardisierten Format an das Frontend 100 abgeliefert werden. Die Verwendung eines Debuggers als Backend-Steuerungsprogramm liefert ein zweckmäßiges Verfahren zum Standardisieren von Daten. Wenn symbolische Informationen für das Zielprogramm verfügbar sind, können die Daten, an denen gewählt werden soll, als variable Namen spezifiziert werden. Andernfalls können die Daten immer noch über virtuelle Adressen spezifiziert werden.
Duplizierte Eingabe und Ausgabe bei dem Ausführungsbeispiel kann zum Beispiel durch Kopieren von Eingaben in alle duplizierten Zielprogramme und Senken der Ausgabe aus allen außer einem Backend, das als primär gekennzeichnet ist, behandelt werden. Diese Art von Eingangs-/Ausgangs-(E/A-)Verwaltung könnte durch Trappen aller Read()- und Write()-Systemaufrufe durchgeführt werden. Eine solche Read()- und Write()-Technik behandelt im allgemeinen jedoch nicht die Speicherabbildungs-E/A- und ioctl()-Aufrufe. Zur Bereitstellung von E/A-Verwaltung in dem Ausführungsbeispiel könnten auch andere geeignete Techniken verwendet werden.
Außerdem sollte man in bezug auf Prüfpunkte mehrere Probleme berücksichtigen. Der Code zum Sichern des Prüfpunkt-Prozeßzustands in einer Datei und zum Neustarten eines neuen Prozesses von der Prüfpunktdaten-Datei kann entweder Teil des Zielprogramms sein oder außerhalb des Zielprogramms existieren. Wenn der Prüfpunktcode Teil des Zielprogramms sein soll, dann kann er durch Quellcodemodifikation, Linken zur Compilezeit oder Linken zur Laufzeit mit dem ursprünglichen Zielprogramm integriert werden. Wenn der Prüfpunktcode außerhalb des Zielprogramms liegt, dann kann man ein Prüfpunkt-Paket, das völlig von der Instrumentation getrennt ist, zur Durchführung der Prüfpunktoperationen verwenden oder es kann die Backend-Steuerung verwendet werden, um die Prüfpunktoperationen durchzuführen. Die letztere Möglichkeit hat den Vorteil, daß sie plattformunabhängig ist, insbesondere wenn zur Speicherung der Prüfpunkt-Daten in einem Standard-Zwischenformat symbolische Informationen verwendet werden.
Eine frisch neu gestartete Kopie des Zielprogramms sollte mit den ursprünglichen Kopien des Zielprogramms synchronisiert sein. Dies kann besonders problematisch sein, wenn der Prüfpunktcode in das Zielprogramm integriert ist. In diesem Fall führen sowohl die neu gestartete Kopie des Zielprogramms als auch das Prüfpunkt-Zielprogramm Code asymmetrisch aus. Die neu gestartete Kopie muß nicht unbedingt an derselben Stelle wie die anderen Kopien neu gestartet werden. Sie muß an einer derartigen Stelle neu gestartet werden, daß der nächste Wählpunkt, den sie erreicht, mit dem für die anderen Kopien identisch ist. Daraus folgt, daß die Menge von Wählhaltepunkten beim Neustarten der neuen Kopie des Zielprogramms erhalten werden sollte.
Es kann eine Richtlinie hergestellt werden, um die Maschine zu spezifizieren, die zum Neustarten des Zielprogramms verwendet wird. Zum Beispiel kann die neue Kopie des Zielprogramms bis zu einer maximalen Neustartschwelle von X mal auf derselben Maschine neu gestartet werden, wobei X>=0 gilt. Wenn ein Zielprogramm auf einer anderen Maschine neu gestartet wird, dann muß eine Prüfpunktdatei auf die neue Maschine kopiert werden, die der ausgefallenen Maschine ähnlich genug sein muß, damit das Zielprogramm unter Verwendung der kopierten Prüfpunktdatei neu gestartet werden kann.
9 ist ein Diagramm eines Beispiels für eine Ereignissequenz für die Fehlertoleranzimplementierung von 7. Es sind drei Zeitlinien gezeigt, um die Ereignisse für zwei der Backends 28-i und das Frontend 100 zu repräsentieren. Obwohl in der Konfiguration von 7 mehr als zwei Backends vorliegen, sind die einzigen zwei, für die Informationen in dieser beispielhaften Zeitlinie angezeigt werden, das Backend, bei dem ein Fehler auftritt, z.B. Backend2 (28-2), und das Backend, das den für die Behebung zu verwendenden Prüfpunkt erzeugt, z.B. Backend1 (28-1). Die wiederauftretenden Ereignissen zugeordneten Indizes haben die Form T_{xi_j} wobei x der Ereignistyp ist, I das Backend identifiziert und j die Ereignisse für jedes Backend unterscheidet. Für Ereignisse, die gleichzeitig stattfinden, werden gestrichelte vertikale Linien gezeichnet. Man beachte außerdem, daß das Diagramm nicht maßstabsgetreu ist.
Man nehme an, daß ein Fehler auf Backend2 auftritt und daß sich dieser Fehler auf einen Wert für eine Datenvariable, die für das Wählen ausgewählt wurde, auswirkt. Dieses Auftreten eines Fehlers ist in 9 als ein X gezeigt. Nachdem der Fehler aufgetreten ist, halten die Backends zum Zeitpunkt T_{pi_j} an, um ihre Daten zu dem Frontend 100 zu senden. Zu diesem Zeitpunkt ist das Wählen aufgrund des Fehlers nicht einstimmig. Wenn mindestens drei Backends an der Wahl teilnehmen, sollten die beiden nichtfehlerhaften Backends dem Frontend denselben Datenwert präsentieren. Auf diese Weise kann das Frontend bestimmen, welches Backend fehlerhaft ist. Dann wird der Behebungsprozeß eingeleitet. Das Frontend weist eines der nicht fehlerhaften Backends an, einen Prüfpunkt seines Zustands in Form einer Prüfpunktdatei zu erzeugen. In 9 nimmt Backend1 einen Prüfpunkt seines Zustands zum Zeitpunkt T_{ckpl_1}. Das Frontend wartet auf den Prüfpunktabschluß. Wenn Backend1 und Backend2 auf verschiedenen Maschinen verankert sind, dann wird die Prüfpunktdatei von der Backend1-Maschine zu der Backend2-Maschine kopiert. Das Frontend weist dann Backend2 an, das fehlerhafte Zielprogramm zu beenden und unter Verwendung der Prüfpunktdatei ein neues Zielprogramm neu zu starten. Nachdem das neue Zielprogramm denselben Zustand wie die nicht fehlerhaften Zielprogramme erreicht hat, gibt das Frontend zum Zeitpunkt T_{ci_j} den Fortsetzungsbefehl an alle Backends. Abhängig von der Neustartrichtlinie würde, wenn die maximale Neustartschwelle bereits erreicht wurde, das gesamte Backend2 beendet und auf einer anderen Maschine neu gestartet. Außerdem würde die neue Kopie des Zielprogramms auf der neuen Maschine neu gestartet.
Wenn sich der Fehler, der auf Backend2 auftritt, so auf das Zielprogramm auswirkt, daß es den Wählhaltepunkt nicht erreichen kann, wartet das Frontend, bis eine maximale Warteschwelle erreicht ist, und erklärt dann Backend2 als fehlerhaft. Dann wird derselbe Behebungsprozeß wie oben beschrieben eingeleitet. Diese Arten von Fehlern können verursachen, daß das Zielprogramm abstürzt, unbestimmte Zeit hängen bleibt oder die Ausführung fortsetzt, ohne auf den korrekten Wählhaltepunkt zu stoßen. In dem letzten Fall bestimmt das Frontend immer noch, daß ein Fehler aufgetreten ist, wenn ein anderer Wählhaltepunkt angetroffen wird.
Diese beispielhafte Fehlererkennungs- und- Behebungstechnik toleriert alle Einzelerscheinungen von Hardwarefehlern (transient oder permanent). Permanente Fehler führen dazu, daß Neustarts auf eine nicht fehlerhafte Maschine übergesiedelt werden. Für eine "Einzelfehlererscheinung" sollte ein zweiter Fehler erst dann auftreten, wenn der durch den ersten Fehler eingeleitete Behinderungsprozeß abgeschlossen wurde. Es können außerdem bestimmte Arten von Softwarefehlern toleriert werden. Diese Softwarefehler verursachen Fehler in der Umgebung außerhalb des Zielprogramms, die wiederum dazu führen, daß Systemaufrufe in dem Zielprogramm entweder divergente Werte zurückgeben oder eine Programmbeendigung verursachen. Zum Beispiel kann ein Speicherlecken in dem Zielprogramm letztendlich dazu führen, daß eine Anforderung zusätzlichen Speichers eine Programmbeendigung erzeugt, wenn ein nachfolgender Zugriff auf den nichtzugeteilten Speicher einen illegalen-Speicherzugriff-Fehler verursacht, der vom Betriebssystem erkannt wird. Die Auswahl der Wählparameter ist natürlich sehr wichtig. Die dem Wählen unterliegenden Daten können die Menge "kritischer" Variablen in dem Zielprogramm umfassen. Es folgen Beispiele für solche Variablen:
Steuerfluß:
Am Steuerfluß beteiligte Variablen, wie zum Beispiel Variablen in dem Bedingungsteil einer Verzweigung oder einer Schleife.
Programmausgabe:
Variablen werden als Parameter an Ausgangsfunktionen geleitet, darunter visuelle, Datei- und Ausgabezwischenprozesse.
Algorithmuseingabe und -ausgabe:
Als Eingabe verwendete oder durch Algorithmen und Funktionen als Ausgabe erzeugte Variablen, z.B. die Eingangs- und Ausgangsmatrizen einer Matrixoperation.
Es können mehrere Ansätze verwendet werden, um die Zuverlässigkeit des Frontend 100 von 7 zu verbessern, da es ein potentieller Einzelausfallpunkt ist. Zum Beispiel kann Selbstprüfungs- und Behebungscode zusammen mit einem externen Watchdog-Mechanismus zu dem Frontend 100 hinzugefügt werden, um sicherzustellen, daß das Frontend betriebsfähig bleibt. Als ein weiteres Beispiel kann der einzelne Frontend-Prozeß mit redundantem Wählen dupliziert werden. Dies würde jedoch einen verteilten Konsens zwischen mehreren duplizierten Frontend-Prozessen erfordern. Eine verteilte Wahl auf Konsens-Basis zwischen den Backends könnte verwendet werden, damit die Frontend-Wahlverarbeitung völlig überflüssig wird.
Die oben beschriebenen Fehlertoleranztechniken wurden unter Verwendung von Fehlerinjektion implementiert und getestet. Obwohl die Fehlerinjektionsprüfung zeigte, daß die Technik beim Tolerieren der beabsichtigten Fehler effektiv ist, besteht eine Auswirkung auf die Leistung. In dem Beispiel von 9 sind die folgenden Quellen von Leistungsverschlechterungen sichtbar: (1) die Zeit zum Herauffahren der Backend-Software, bevor das Zielprogramm tatsächlich mit der Ausführung beginnt. Dies ist als die Zeit T_bi-T₀ in 9 gezeigt; (2) die Synchronisationszeit bei jeder Wahl. Dies ist die Zeit, für die jedes Zielprogramm angehalten ist, während es darauf wartet, daß das Frontend die Wahlauszählung abschließt und den Fortsetzungsbefehl ausgibt. In 9 ist diese Zeit als die Zeit T_{ci_j}-T_{pi_j} für einstimmige Wahlen und die Zeit T_{ckpn_j}-T_{pi_j} für nicht einstimmige Wahlen gezeigt; und (3) die Behebungszeit, die nach dem Erkennen eines Fehlers auftritt. Diese Zeit ist als die Zeit T_{ci_j}-T_{ckpi_j} in 9 gezeigt.
Diese und andere Overheads in dem Ausführungsbeispiel sind auf verschiedene Faktoren zurückzuführen. Erstens verursacht das Backend-Steuerungsprogramm ein Overhead, weil es mit dem Zielprogramm um Prozessorzeit konkurrieren muß. Zweitens führt das Steuerungsprogramm zu einem zusätzlichen Overhead zur Verwaltung der Ausführung des Zielprogramms, einschließlich der Verwaltung von Haltepunkten. Drittens erlegt der Wählprozeß den Zielprogrammen eine bestimmte Form von Barrierensynchronisation auf. Die Wartezeit ist besonders auffällig, wenn die Verarbeitungsgeschwindigkeiten der Backend-Maschinen nicht gleich sind, weil die schnelleren Maschinen darauf warten, daß die langsame Maschine den Wahlpunkt erreicht. Da das Frontend und das Backend verteilt sind, kommt es viertens zu einem Kommunikationsoverhead. Fünftens erfordert der Behebungsprozeß endlich viel Zeit.
Es können vielfältige Aktionen unternommen werden, um in dem Ausführungsbeispiel die Overheadzeiten zu vermindern, darunter zum Beispiel die folgenden: (1) Verkleinern der Häufigkeit von Wahlen; (2) Verkleinern der Größe der Daten, an denen gewählt wird und (3) Beseitigen der Anforderung für Zielprogramme, die Ausführung anzuhalten, bis das Frontend das Ergebnis der aktuellen Wahl bestimmt hat. Die Aktion (1) würde die Zahl der Overheads des Typs T_{ci_j}-T_{pi_j} in 9 vermindern. Die Aktion (2) würde die mittlere Zeit T_{cl_j}-T_{pi_j} vermindern, aber wahrscheinlich nur geringfügig. Solange die Daten für das Wählen nicht sehr groß sind, besteht der größte Teil der Zeit T_{cl_j}-T_{pi_j} aus Synchronisations- und Kommunikationsoverheads. Die Aktion (3) würde das Overhead T_{ci_j}-T_{pi_j} vollständig beseitigen, würde aber die Komplexität des Wähl- und Behebungsprozesses vergrößern, weil die Zielprogramme nicht mehr synchronisiert wären. Somit müssen Wahldaten bis zu Benutzung gesichert werden und die Behebung würde eine teilweise Löschung bestimmter Wähldaten erfordern.
Es sollte beachtet werden, daß die oben beschriebenen Ausführungsbeispiele der Erfindung in anderen als den oben erwähnten Datenverarbeitungsanwendungen implementiert werden können, darunter andere verteilte und nicht verteilte Datenverarbeitungsanwendungen. Diese und zahlreiche andere alternative Ausführungsformen innerhalb des Schutzumfangs der folgenden Ansprüche werden Fachleuten ohne weiteres ersichtlich sein.

Claims

Verfahren zur Bereitstellung von Fehlertoleranz in einem Datenverarbeitungssystem, mit den folgenden Schritten: Ausführen mehrerer verschiedener Kopien eines Zielprogramms, wobei die Ausführung jeder der verschiedenen Kopien durch eine entsprechende Steuerung gesteuert wird; und Erkennen eines Fehlers in mindestens einer der Kopien durch Vergleichen von Werten mindestens einer Variablen, die von den verschiedenen Kopien für mindestens einen designierten Haltepunkt erzeugt werden, wobei das Verfahren dadurch gekennzeichnet ist, daß die Steuerung mit einer Benutzerschnittstelle eines Instrumentationswerkzeugs kommuniziert; und die Variable und/oder der Haltepunkt durch einen Benutzer in der Benutzerschnittstelle des Instrumentationswerkzeugs spezifiziert und aus der Benutzerschnittstelle zu den Steuerungen übermittelt werden, dergestalt, daß der Fehler ohne Modifikation des Zielprogrammcodes erkannt wird.
Verfahren nach Anspruch 1, bei dem weiterhin nach Erkennung eines Fehlers in einer gegebenen der Kopien ein Haltepunkt einer anderen der Kopien genommen und eine neue Kopie von dem Haltepunkt aus neu gestartet wird.
Verfahren nach Anspruch 1, wobei der Schritt des Ausführens weiterhin das Ausführen jeder der verschiedenen Kopien des Programms auf einer anderen Maschine umfaßt.
Verfahren nach Anspruch 1, bei dem weiterhin dem Benutzer ermöglicht wird, mindestens einen Teil mehrerer der Variablen und mehrerer der Haltepunkte in der Benutzerschnittstelle des Instrumentationswerkzeugs auszuwählen; und entsprechende Befehle an jede der Steuerungen abgeliefert werden.
Verfahren nach Anspruch 1, wobei für jeden von mehreren Haltepunkten jede der Steuerungen den Wert der mindestens einen Variablen einem Wahlverarbeitungsmechanismus in dem Instrumentationswerkzeug meldet.
Verfahren nach Anspruch 5, wobei der Wahlverarbeitungsmechanismus in einem der Benutzerschnittstelle des Instrumentationswerkzeugs zugeordneten Prozeß implementiert wird.
Verfahren nach Anspruch 5, wobei der Wahlverarbeitungsmechanismus in einer oder mehreren der Steuerungen implementiert wird.
Verfahren nach Anspruch 1, wobei eine gegebene Kopie des Zielprogramms als einen Fehler enthaltend identifiziert wird, wenn ihr gemeldeter Wert der mindestens einen Variablen von denen der anderen Kopien des Zielprogramms verschieden ist.
Verfahren nach Anspruch 1, wobei die mindestens eine Variable eine Steuerflußvariable des Zielprogramms, eine als Parameter an eine Ausgabefunktion des Zielprogramms weitergeleitete Variable und/oder eine als Eingabe verwendete oder als Ausgabe durch eine Funktion des Zielprogramms erzeugte Variable umfaßt.
Vorrichtung zur Bereitstellung von Fehlertoleranz in einem Datenverarbeitungssystem, umfassend: mindestens eine Maschine, die so ausgelegt ist, daß sie ein Verfahren nach einem der vorhergehenden Ansprüche ausführt.
Computerprogrammprodukt, das direkt in internen Speicher in einem Datenverarbeitungssystem ladbar ist, wobei das Produkt Softwarecodeteile zur Ausführung eines Verfahrens nach einem der Ansprüche 1 bis 9, wenn das Produkt in einem Datenverarbeitungssystem ausgeführt wird, umfaßt.
Computer-benutzbares Medium, das ein Computerprogrammprodukt nach Anspruch 11 speichert.