DE69907824T2 - Verfahren und Vorrichtung zur Fehlererkennung und Wiederherstellung mit vorbestimmtem Replikationsgrad für verteilte Anwendungen in einem Netzwerk - Google Patents

Verfahren und Vorrichtung zur Fehlererkennung und Wiederherstellung mit vorbestimmtem Replikationsgrad für verteilte Anwendungen in einem Netzwerk Download PDF

Info

Publication number
DE69907824T2
DE69907824T2 DE69907824T DE69907824T DE69907824T2 DE 69907824 T2 DE69907824 T2 DE 69907824T2 DE 69907824 T DE69907824 T DE 69907824T DE 69907824 T DE69907824 T DE 69907824T DE 69907824 T2 DE69907824 T2 DE 69907824T2
Authority
DE
Germany
Prior art keywords
application module
copy
running
host computer
backup
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE69907824T
Other languages
English (en)
Other versions
DE69907824D1 (de
Inventor
Pi-Yu Bellevue Chung
Yennun Bridgewater Huang
Deron Liang
Chia-Yen Murray Hill Shih
Shalini Scotch Plains Yajnik
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Academia Sinica
Nokia of America Corp
Original Assignee
Academia Sinica
Lucent Technologies Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Academia Sinica, Lucent Technologies Inc filed Critical Academia Sinica
Application granted granted Critical
Publication of DE69907824D1 publication Critical patent/DE69907824D1/de
Publication of DE69907824T2 publication Critical patent/DE69907824T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1438—Restarting or rejuvenating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751—Error or fault detection not based on redundancy
    • G06F11/0754—Error or fault detection not based on redundancy by exceeding limits
    • G06F11/0757—Error or fault detection not based on redundancy by exceeding limits by exceeding a time limit, i.e. time-out, e.g. watchdogs

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Hardware Redundancy (AREA)
  • Retry When Errors Occur (AREA)
  • Multi Processors (AREA)

Description

  • TECHNISCHES GEBIET
  • Diese Erfindung betrifft die Erkennung eines Ausfalls eines Anwendungsmoduls, das auf einem Hostcomputer in einem Netzwerk läuft, sowie die Wiederherstellung nach diesem Ausfall.
  • HINTERGRUND DER ERFINDUNG
  • Damit ein Anwendungsmodul, das auf einem Hostcomputer in einem Netzwerk läuft, den darauf zugreifenden Clients akzeptable Leistung zur Verfügung stellen kann, muss das Anwendungsmodul sowohl zuverlässig als auch verfügbar sein. Um akzeptable Leistung zur Verfügung zu stellen, sind Schemata zur Erkennung eines Ausfalls eines Anwendungsmoduls oder des gesamten Hostcomputers, auf dem es läuft, und zur anschließenden raschen Wiederherstellung nach einem derartigen erkannten Ausfall erforderlich. Die Replikation des Anwendungsmoduls auf anderen Hostcomputern in dem Netzwerk ist eine wohl bekannte Technik, die zur Verbesserung von Zuverlässigkeit und Verfügbarkeit des Anwendungsmoduls verwendet werden kann.
  • Im Stand der Technik sind drei Strategien zum Betreiben und Konfigurieren des Ersatzschaltprozesses in Anwendung auf die Replikas oder Backup-Kopien eines Anwendungsmoduls bekannt, die einen Vorbereitungsgrad für diese Backups definieren. In der ersten Strategie, die als "kaltes Backup"-Format bekannt ist, läuft nur die primäre Kopie eines Anwendungsmoduls auf einem Hostcomputer, und andere Backup-Kopien bleiben auf anderen Hostcomputern in dem Netzwerk im Leerlauf. Wenn ein Ausfall der primären Kopie des Anwendungsmoduls erkannt wird, wird die primäre Kopie des Anwendungsmoduls entweder auf demselben Hostcomputer erneut gestartet, oder eine der Backup-Kopien des Anwendungsmoduls wird auf einem der anderen Hostcomputer gestartet, wobei die Backup-Kopie dann die neue primäre Kopie wird. Durch Verwendung einer Fixpunktfestlegungstechnik, die periodisch "Aufnahmen" des Laufzustands des primären Anwendungsmoduls macht und diesen Zustand auf einem stabilen Speichermedium speichert, werden die Fixpunktdaten des letzten derartigen gespeicherten Zustands des ausgefallenen primären Anwendungsmoduls dem Backup-Anwendungsmodul zur Verfügung gestellt, damit es die Arbeit als primäres Anwendungsmodul übernehmen und die Verarbeitung ausgehend von diesem zuletzt gespeicherten Zustand des ausgefallenen primären Anwendungsmoduls fortsetzen kann, wenn ein Ausfall des primären Anwendungsmoduls erkannt worden ist.
  • Die zweite Strategie ist als "warmes Backup"-Format bekannt. Im Unterschied zu dem kalten Backup-Format, bei dem kein Backup eines Anwendungsmoduls zur gleichen Zeit wie das primäre Anwendungsmodul läuft, laufen beim warmen Backup-Format eine oder mehrere Backup-Anwendungsmodule gleichzeitig mit dem primären Anwendungsmodul. Die Backup-Anwendungsmodule erhalten jedoch keine Anfragen irgendeines Clients und reagieren nicht auf diese, sondern erhalten periodisch Zustandsaktualisierungen von dem primären Anwendungsmodul. Nachdem ein Ausfall des primären Anwendungsmoduls erkannt worden ist, wird rasch eines der Backup-Anwendungsmodule aktiviert, um die Verantwortung des primären Anwendungsmoduls zu übernehmen, ohne dass Initialisierung oder Neustart erforderlich ist, welche die Zeit verlängern, die das Backup benötigt, um die Verarbeitungsfunktionen der ausgefallenen primären Kopie zu übernehmen.
  • Die dritte Strategie ist als ein "heißes Backup"-Format bekannt. Gemäß diesem Format sind zwei oder mehr Kopien eines Anwendungsmoduls zu Laufzeit aktiv. Jede laufende Kopie kann Anfragen von Clients verarbeiten, und die Zustände werden unter den mehreren Kopien synchronisiert. Nachdem ein Ausfall in einem der laufenden Anwendungsmodule erkannt worden ist, ist jede der anderen laufenden Kopien in der Lage, die Last der ausgefallenen Kopie sofort zu übernehmen und den Betrieb fortzusetzen.
  • Im Unterschied zu der kalten Backup-Strategie, bei der zu jeder gegebenen Zeit nur eine primäre Kopie läuft, können sowohl die warme Backup- als auch die heiße Backup-Strategie vorteilhaft den gleichzeitigen Ausfall von mehr als einer Kopie eines speziellen Anwendungsmoduls tolerieren, das im Netzwerk läuft, da auf dem Netzwerk mehrere Kopien dieses Anwendungsmodultyps simultan laufen.
  • Jede der drei Replikationsstrategien bringt unterschiedlichen Verwaltungsaufwand zur Laufzeit mit sich, und sie haben unterschiedliche Wiederherstellungszeiten. Ein auf einem Netzwerk laufendes Anwendungsmodul benötigt möglicherweise auf Grundlage seiner Verfügbarkeitsanforderungen und seiner Laufzeitumgebung eine andere Replikationsstrategie als ein anderes Anwendungsmodul, das auf dem gleichen Hostcomputer oder einem anderen Hostcomputer in dem Netzwerk läuft. Da verteilte Anwendungen oft auf heterogenen Hardware- und Betriebssystemplattformen laufen, müssen die Techniken zur Verbesserung der Zuverlässigkeit und Verfügbarkeit eines Anwendungsmoduls in der Lage sein, sich allen möglichen Replikationsschemata anzupassen.
  • In US-A-5,748,882 sind eine Vorrichtung und ein Verfahren für fehlertolerante Datenverarbeitung offenbart. In diesem Patent ist beschrieben, dass eine Anwendung oder ein Prozess in einem "Wächter"-Dämonprozess registriert wird, der dann die Anwendung oder den Prozess auf Ausfall oder Aufhängen "überwacht". Falls Ausfall oder Aufhängen der überwachten Anwendung erkannt wird, startet der Wächter die Anwendung oder den Prozess neu. In einem verteilten System mit mehreren Hosts in einem Netzwerk überwacht ein Wächterdämon auf einem Host computer registrierte Anwendungen oder Prozesse auf seinem eigenen Hostcomputer sowie Anwendungen oder Prozesse auf einem anderen Hostcomputer. Falls ein überwachter Hostcomputer ausfällt, startet der Wächterdämon, der den ausgefallenen Hostcomputer überwacht, die registrierten Prozesse oder Anwendungen, die auf dem ausgefallenen überwachten Knoten gelaufen sind, auf seinem eigenen Knoten neu. In Ausführungsformen mit einem einzigen Knoten sowie solchen mit mehreren Knoten ist die Replikationsstrategie zum Neustart des ausgefallenen Prozesses oder der ausgefallenen Anwendung das kalte Backup-Format, d. h. ein neuer Replikaprozess oder eine neue Replikaanwendung wird nur nach Ausfall des primären Prozesses oder der primären Anwendung gestartet.
  • Fehlertolerante Methoden des Standes der Technik konnten leider nicht mehrere unterschiedliche Replikationsstrategien handhaben, wie die oben beschriebenen kalten, warmen und heißen Backup-Formate, die am besten jeder individuellen Anwendung von einer Vielzahl unterschiedlicher Anwendungen, die auf einem oder mehreren Rechnern in einem Netzwerk laufen können, zugeordnet werden können, und lassen sich dafür nicht anpassen. Außerdem gibt es im Stand der Technik keine Methode, um für die warmen und heißen Backup-Replikationsformate eine konstante Anzahl laufender Anwendungen in dem Netzwerk aufrechtzuerhalten.
  • In US-A-5,408,649 wird eine einzige Datenbankcomputereinrichtung auf Bereitschaftsbasis (Standby) in einem System mit verteiltem Datenzugriff zur Verfügung gestellt, das eine Vielzahl derartiger Datenbankcomputereinrichtungen einschließt. Die Standby-Computereinrichtung übernimmt den Betrieb von jeder der Vielzahl von Computereinrichtungen, bei der ein Ausfall erkannt wird. Eine willkürliche Computereinrichtung, die an alle Datenbankcomputereinrichtungen gekoppelt ist, ist in der Lage, einen Ausfall von jeder der Datenbank computereinrichtungen zu erkennen und die Reservedatenbankcomputereinrichtung anstelle der ausgefallenen als Ersatz zu nehmen.
  • In einem Artikel von Silvano Maffeis mit dem Titel "Piranha: A CORBA Tool For High Availability", IEEE Computer, April 1997, Seiten 59 bis 66, wird ein Tool auf CORBA-Basis (CORBA steht für Common Object Request Broker Architecture) für ein verteiltes System offenbart, das als Netzwerk-Monitor wirkt, der Ausfälle durch eine graphische Benutzeroberfläche übermittelt und als Manager wirkt, um solche Funktionen wie automatischen Neustart ausgefallener CORBA-Objekte und Durchsetzen festgelegter Replikationsgrade auf Gruppen von Objekten durchzuführen.
  • In einem Artikel von Rudi Cuyvers et al. mit dem Titel "A Kernel for Multi-Level Fault-Tolerant Multiprocessing", IEEE Proceedings of the Southeastcon, 1991, Seiten 248 bis 252, wird ein Laufzeit-Kernel offenbart, der die Auswahl der Anzahl von kalten, warmen, heißen und aktiven Backups für jeden Task von unterschiedlichen parallelen Programmen ermöglicht. Mehrere Prozesse mit unterschiedlichen Hardware-Fehlertoleranzniveaus können gleichzeitig auf demselben Multiprozessor laufen, was zu kostengünstiger fehlertoleranter Mehrprogrammverarbeitung führt.
  • KURZFASSUNG DER ERFINDUNG
  • Die erfindungsgemäße Vorrichtung und ein erfindungsgemäßes Verfahren sind in den unabhängigen Ansprüchen beschrieben. Bevorzugte Formen sind in den abhängigen Ansprüchen beschrieben.
  • Erfindungsgemäß wird ein auf einem Hostcomputer laufendes Anwendungsmodul zuverlässig gemacht, indem es zuerst seine eigenen Ausfall- und Wiederherstellungsprozesse registrieren lässt. Ein Replikamanagerdämon prozess, der auf demselben Hostcomputer läuft, auf dem das Anwendungsmodul läuft, oder auf einem anderen Hostcomputer läuft, der mit dem Netzwerk verbunden ist, mit dem der Rechner des Anwendungsmoduls verbunden ist, empfängt eine Registrierungsnachricht von dem Anwendungsmodul. Diese Registrierungsnachricht schließt zusätzlich zu der Identifizierung des sich registrierenden Anwendungsmoduls und des Hostrechners, auf dem es läuft, die spezielle Replikationsstrategie (kaltes, warmes oder heißes Backupformat) und den Replikationsgrad ein, der dem registrierten Anwendungsmodul zugeordnet werden soll, wobei die registrierte Replikationsstrategie von dem Replikamanager verwendet wird, um den Betriebszustand von jeder Backupkopie des Anwendungsmoduls zu setzen sowie die Anzahl der Backup-Kopien gemäß dem Replikationsgrad zu halten. Ein Wächterdämonprozess, der auf demselben Hostcomputer wie das registrierte Anwendungsmodul läuft, überwacht dann periodisch das registrierte Anwendungsmodul, um Ausfälle zu erkennen. Wenn der Wächterdämon einen Absturz oder ein Aufhängen des überwachten Anwendungsmoduls erkennt, teilt er den Ausfall dem Replikamanager mit, der wiederum einen Ersatzschaltprozess bewirkt. Wenn somit das Replikationsformat warm oder heiß ist und das ausgefallene Anwendungsmodul nicht auf seinem eigenen Hostcomputer neu gestartet werden kann, wird eine der laufenden Backup-Kopien des primären Anwendungsmoduls als das neue primäre Anwendungsmodul ernannt, und einem Hostcomputer, auf dem sich eine Leerlaufkopie des Anwendungsmoduls befindet, wird über das Netzwerk signalisiert, diese Leerlaufanwendung auszuführen. Der Replikationsgrad bleibt somit erhalten, wodurch Schutz gegen mehrfache Ausfälle dieses Anwendungsmoduls gewährleistet ist. Falls das Replikationsformat kalt ist und die ausgefallene Anwendung nicht auf ihrem eigenen Hostcomputer neu gestartet werden kann, dann wird einem Hostcomputer, auf dem sich eine Leerlaufkopie des Anwendungsmoduls befindet, über das Netzwerk signalisiert, diese Leerlaufkopie auszuführen.
  • Um den Ausfall eines Hostcomputers oder des Wächterdämons zu erkennen, der auf einem Hostcomputer läuft, erhält ein Superwächterdämonprozess, der auf demselben Hostcomputer wie der Replikamanager läuft, Eingaben von jedem Hostcomputer. Nachdem ein Ausfall eines Hostcomputers durch den Superwächterdämon infolge des Fehlens einer Eingabe von diesem Hostcomputer erkannt worden ist, wird auf den Replikamanager zugegriffen, um die Anwendungsmodule zu ermitteln, die auf diesem Hostcomputer gelaufen sind. Diese Anwendungsmodule werden dann individuell in der in dem Replikamanager eingerichteten und gespeicherten Weise vor Ausfall geschützt.
  • KURZE BESCHREIBUNG DER ZEICHNUNG
  • 1 ist ein Blockdiagramm eines Computernetzwerks, das in veranschaulichender Weise eine Vielzahl von Hostcomputern zeigt, auf denen Anwendungsmodule laufen, die erfindungsgemäß vor Ausfall geschützt sind; und
  • 2 zeigt eine Tabelle, die in dem Replikamanagerdämon gespeichert ist und auf einem Hostcomputer in dem Netzwerk von 1 läuft, die für jeden Anwendungsmodultyp Informationen zuordnet, die zum erfindungsgemäßen Bewirken von Ausfallschutz verwendet werden.
  • DETAILLIERTE BESCHREIBUNG
  • In Bezug auf 1 ist ein Netzwerk 100 gezeigt, mit dem eine Vielzahl von Hostcomputern verbunden sind. Das Netzwerk 100 kann ein Ethernet, ein ATM-Netzwerk oder jeder andere Typ von Datennetzwerk sein. Lediglich zu veranschaulichenden Zwecken sind sechs Hostcomputer H1, H2, H3, H4, H5 und H6, mit Ziffern als 101, 102, 103, 104, 105 beziehungsweise 106 bezeichnet, mit dem Netzwerk 100 verbunden. Jeder Hostcomputer weist eine Vielzahl unterschiedlicher Anwendungsmodule auf, die sich in seinem Arbeitsspeicher befinden. Diese An wendungsmodule, die in 1 als vom Typ A, B und C bezeichnet werden, weisen jeweils eine primäre Kopie auf, die auf mindestens einem dieser sechs Hostcomputer ausgeführt wird und läuft. Speziell läuft in diesem veranschaulichenden Beispiel eine primäre Kopie des Anwendungsmoduls vom Typ A, Anwendungsmodul A1, auf Hostcomputer H1, eine primäre Kopie des Anwendungsmoduls vom Typ B, Anwendungsmodul B1, läuft auf Hostcomputer H4, und eine primäre Kopie des Anwendungsmoduls vom Typ C, Anwendungsmodul C1, läuft auf Hostcomputer H3. Andere Kopien von jedem Anwendungsmodultyp sind entweder, wie nachfolgend beschrieben wird, gespeichert und aus dem Arbeitsspeicher auf mindestens einem der anderen Hostcomputer in einem Leerlaufzustand verfügbar, der auf die spätere Ausführung wartet, oder laufen als Backup-Kopien oder zweite primäre Kopien von Anwendungsmodulen.
  • Ein Anwendungsmodul, das wie zuvor beschrieben auf einem Hostcomputer läuft, wird durch eine oder mehrere Backupkopien des Anwendungsmoduls vor Ausfall geschützt, die im Zustand der Vorbereitung betrieben werden, der durch eine von drei bekannten Replikationsformaten definiert ist. Jedes Replikationsformat hat sein eigenes Verfahren, einem Anwendungsmodul, das mittels Absturz oder Aufhängen ausfällt, oder allen jenen Anwendungsmodulen, die sich auf einem Hostcomputer befinden, der seinerseits ausfällt, Backup zur Verfügung zu stellen. Erfindungsgemäß wird jeder Anwendungsmodultyp durch das spezielle Replikationsformat (kaltes Backup, warmes Backup, heißes Backup) vor Ausfall geschützt, das für seine eigenen Verarbeitungsanwendungen am besten geeignet ist. Zudem wird erfindungsgemäß jeder Anwendungsmodultyp mit einem Replikationsgrad vor Ausfall geschützt, der für dieses Anwendungsmodul spezifiziert ist, wodurch eine konstante Anzahl von Kopien dieses Anwendungsmoduls zum Schutz gegen mehrere Ausfälle dieses Anwendungsmodultyps in einem laufenden Zustand gehalten wird.
  • Damit ein im Leerlauf befindliches oder Backup-Anwendungsmodul die Funktion eines ausgefallenen primären Anwendungsmoduls nach Erkennung eines Ausfalls mit einer minimalen Unterbrechung die Verarbeitung übernehmen kann, muss dem Backup- oder im Leerlauf befindlichen Anwendungsmodul nach seiner Ausführung vom Leerlauf zustand oder nach seiner Ernennung als neues primäres Anwendungsmodul der letzte Betriebszustand des ausgefallenen Anwendungsmoduls zur Verfügung gestellt werden. Ein Fixpunktserver 110, der mit Netzwerk 110 verbunden ist, erhält periodisch von jedem vor Ausfall geschützten Anwendungsmodul, das auf dem Netzwerk läuft, den aktuellsten Zustand dieser Anwendung, wobei der Zustand dann in seinem Arbeitsspeicher gespeichert wird. Nach Erkennung eines Ausfalls eines Anwendungsmoduls wird der zuletzt gespeicherte Zustand dieses ausgefallenen Anwendungsmoduls von dem Speicher eines Fixpunktservers 110 abgerufen und dem neuen primären Anwendungsmodul für eine Fortsetzung der Verarbeitung zur Verfügung gestellt.
  • Erfindungsgemäß wird ein Anwendungsmodul zuverlässig gemacht, indem es selbst seine eigene Ausfallerkennung und Wiederherstellung registrieren lässt. Speziell erhält ein zentralisierter Replikamanagerdämonprozess 112, der auf einem der Hostcomputer (Hostcomputer H2 in 1) in dem Netzwerk läuft, eine Registrierungsanforderung von jedem gegen Ausfall geschützten Anwendungsmodul. Die Registrierungsanforderung schließt für dieses spezielle Anwendungsmodul das Replikationsformat (d. h. heiß, warm und kalt), den Replikationsgrad, eine Liste der Hostcomputer, auf denen sich das Anwendungsmodul befindet, und den Ort, an dem sich auf jedem derartigen Hostcomputer das ausführbare Programm befindet, und ein Umschaltformat ein. Der Replikationsgrad spezifiziert die Gesamtanzahl der Kopien eines Anwendungsmoduls. Bei einem heißen oder warmen Replikationsformat definiert der Replika tionsgrad die Gesamtanzahl der laufenden Kopien eines Anwendungsmoduls, die in dem Netzwerk gehalten werden sollen. Bei einem kalten Replikationsformat spezifiziert der Replikationsgrad die Anzahl der Hostcomputer in dem Netzwerk, von denen aus das Anwendungsmodul ausgeführt werden kann. Das Umschaltformat spezifiziert eine Ersatzschaltstrategie, die festlegt, wann ein Anwendungsmodul von einem Hostcomputer auf einen anderen Hostcomputer migriert werden soll. In Bezug auf das letztere kann, wenn ein Ausfall eines Anwendungsmoduls erkannt worden ist, es entweder auf demselben Hostcomputer, auf dem der Ausfall stattgefunden hat, neu gestartet werden, oder es kann auf einen anderen Hostcomputer migriert werden, auf dem sich eine im Leerlauf befindliche oder laufende Backup-Kopie befindet. Zwei Ersatzschaltstrategien können bei Registrierung des Anwendungsmoduls mit dem Replikamanager spezifiziert werden. Bei der Ersten, die als OnOverThreshold (über dem Schwellenwert liegend) bekannt ist, wird ein Anwendungsmodul auf einen anderen Hostcomputer migriert, nachdem die Anzahl der Ausfälle des Anwendungsmoduls auf einem gegebenen Hostcomputer einen gegebenen Schwellenwert überschritten hat. Bei dieser Strategie wird das ausgefallene Anwendungsmodul daher auf seinem eigenen Hostcomputer neu gestartet, bis die Anzahl der Ausfälle dieses Anwendungsmoduls die Schwellenwertzahl erreicht hat. Danach wird das ausgefallene Anwendungsmodul auf einen anderen Hostcomputer migriert. Bei der zweiten Ersatzschaltstrategie, die als OnEachFailure (bei jedem Ausfall) bekannt ist, wird ein ausgefallenes Anwendungsmodul bei jedem Auftreten eines Ausfalls auf einen anderen Hostcomputer migriert.
  • Der Replikamanagerdämonprozess 112 hat in seinem Speicher die Replikationsinformationen für alle registrierten Anwendungsmodule in dem Netzwerk vereinigt. Für jeden im Netzwerk laufenden Anwendungsmodultyp speichert der Replikamanager die notwendigen Informationen, um die Wiederherstellung eines laufenden An wendungsmoduls oder eines ganzen Hostcomputers zu bewirken, auf dem mehrere unterschiedliche Anwendungsmodule laufen. 2 veranschaulicht im Format einer Tabelle 200 den Typ der gespeicherten Information für die drei Typen von Anwendungsmodulen, die auf den sechs Hostcomputern in 1 laufen. Als Beispiel wird Anwendungsmodul vom Typ A in Eintrag 201 mit einem warmen Backupformat mit einem Replikationsgrad von drei registriert. Ein primäres Anwendungsmodul läuft somit immer zusammen mit zwei Backup-Kopien, wobei jede beliebige der Backup-Kopien in der Lage ist, die Funktion als primäre Kopie nach Ausfall der primären Kopie zu übernehmen. Wie aus den 1 und 2 hervorgeht, ist die primäre Kopie (die in Block 202 mit "P" bezeichnet ist), A1, veranschaulichend als auf H1 laufend gezeigt, und die Backup-Kopien (die in Blöcken 203 und 204 mit "B" bezeichnet sind), A2 und A3, sind als auf H2 beziehungsweise H3 laufend gezeigt. Eine weitere Kopie von Anwendungsmodul vom Typ A, A4, ist als im Speicher von H4 befindlich im Leerlaufzustand (in Block 205 mit "I" bezeichnet) gezeigt. Die Pfadbezeichnung von jeder Kopie des Anwendungsmoduls auf dem Hostcomputer ist veranschaulichend gezeigt. Anwendungsmodul vom Typ B ist in Eintrag 206 mit einem heißen Backupformat mit einem Grad von zwei registriert und gespeichert. Daher werden zwei primäre Kopien dieses Anwendungsmoduls aktiv und laufend gehalten, wobei jede Client-Anfragen verarbeitet und ihre Zustände synchronisiert werden. Die erste primäre Kopie, B1, ist veranschaulichend als auf H4 befindlich gezeigt, und die zweite primäre Kopie, B2, ist als auf H1 befindlich gezeigt. Eine Leerlaufkopie, B3, befindet sich auf H5. Das dritte Anwendungsmodul, Typ C, ist in Eintrag 207 mit einem kalten Backupformat mit einem Grad von zwei registriert. Eine primäre Kopie, C1, ist veranschaulichend als auf H3 laufend gezeigt, und eine einzige Leerlaufkopie ist veranschaulichend als auf H6 befindlich gezeigt.
  • Wie erörtert wird, wird nach Erkennung eines Ausfalls eines primären Anwendungsmoduls mit einem OnEachFailure-Umschaltformat oder einem OnOverThreshold-Umschaltformat, bei dem der Schwellenwert erreicht worden ist, in Tabelle 200 ein Backup-Anwendungsmodul als neues primäres Anwendungsmodul ernannt. Falls das ausgefallene Anwendungsmodul ein warmes oder heißes Backupformat hat, wird eine Leerlaufkopie dieses Anwendungsmodultyps auf seinem als Host dienenden Computer ausgeführt, um dasselbe Replikationsniveau in dem Netzwerk aufrechtzuerhalten. Falls in ähnlicher Weise ein Ausfall einer laufenden Backup-Kopie eines Anwendungsmoduls erkannt worden ist, wird eine Leerlaufkopie dieses Anwendungsmoduls auf einem anderen Hostcomputer gestartet, um dieselbe Anzahl laufender Kopien in dem Netzwerk aufrechtzuerhalten, wie durch den registrierten Replikationsgrad spezifiziert ist. Nach Erkennen eines Ausfalls auf einem Hostcomputer wird, wie weiterhin erörtert wird, auf Tabelle 200 zugegriffen, um die Identitäten der Anwendungsmodule zu ermitteln, die auf diesem Computer als entweder primäre Kopien oder Backup-Kopien laufen. Jede derartige primäre oder Backup-Kopie auf dem ausgefallenen Hostcomputer wird dann in der gleichen Weise vor Ausfall geschützt, als wenn jede individuell ausgefallen wäre.
  • Wiederun in Bezug auf 1 wird die Erkennung eines Ausfalls über einen Wächterdämonprozess bewirkt, der auf jedem Hostcomputer läuft. Jeder derartige Wächterdämonprozess führt die Funktion der Überwachung dieses laufenden Anwendungsmoduls und aller anderen registrierten und laufenden Anwendungsmodule auf seinem Hostcomputer durch, nachdem ein Anwendungsmodul in dem Replikamanager 112 registriert worden ist. Demzufolge überwacht Wächterdämon 113-1 die registrierten Anwendungsmodule A1 und B2, die auf Hostcomputer H1 laufen; Wächterdämon 113-2 überwacht das registrierte Anwendungsmodul A2, das auf Hostcomputer H2 läuft; Wächter dämon 113-3 überwacht die registrierten Anwendungsmodule A3 und C1, die auf Hostcomputer H3 laufen; und Wächterdämon 113-4 überwacht das Anwendungsmodul B1, das auf Hostcomputer H4 läuft. Da Anwendungsmodul A4 im Speicher von Hostcomputer H4 im Leerlauf ist, überwacht Wächterdämon 113-4 es erst dann, wenn es später aktiv gemacht wird. Leerlaufanwendungsmodul B3 auf Hostcomputer H5 und Leerlaufanwendungsmodul C2 auf Hostcomputer H6 werden in ähnlicher Weise von Wächterdämonen 113-5 beziehungsweise 113-6 erst dann überwacht, wenn sie ausgeführt werden.
  • Die auf jedem Hostcomputer laufenden Wächterdämonen 113 unterstützen zwei Ausfallerkennungsmechanismen: Abrufbetrieb (Polling) und Herzschlag. Beim Abrufbetrieb schickt der Wächterdämon periodisch eine Ping-Nachricht an das Anwendungsmodul, das er überwacht. Wenn das Ping fehlschlägt, wird angenommen, dass das Anwendungsmodul abgestürzt ist. Der Abrufbetrieb kann auch verwendet werden, um die Unversehrtheit eines Anwendungsmoduls zu prüfen, indem eine Unversehrtheitsprüfungsmethode im Inneren des Anwendungsmoduls aufgerufen wird. Im Herzschlagmechanismus sendet ein Anwendungsmodul aktiv Herzschlagsignale auf entweder periodischer Basis oder auf-Anfrage-Basis an den Wächterdämon. Falls der Wächterdämon nicht innerhalb eines bestimmten Zeitintervalls ein Herzschlagsignal erhält, wird das Anwendungsmodul als aufgehängt angesehen. Der Herzschlagmechanismus ist in der Lage, Ausfälle durch Absturz sowie durch Aufhängen eines Anwendungsmoduls oder eines Hostcomputers zu erkennen, während der Abrufbetrieb nur Ausfall durch Absturz erkennen kann. Ein Anwendungsmodul kann auf Basis seiner Zuverlässigkeitsanforderungen einen dieser beiden Ansätze auswählen.
  • Wenn ein Wächterdämon einen Absturz oder ein Aufhängen eines Anwendungsmoduls erkennt, das er "überwacht", teilt er den Ausfall dem Replikamanager 112 mit, um eine Ersatzschaltaktion zu bewirken. Falls das ausge fallene Anwendungsmodul sich, wie bereits gesagt, mit einer OnEachFailure-Ersatzschaltstrategie registriert hat, wird das ausgefallene Anwendungsmodul auf einen anderen Host migriert. Falls das ausgefallene Anwendungsmodul eine primäre Kopie ist, wird eine der Backup-Anwendungsmodule als neue primäre Kopie ernannt und ein im Leerlauf befindliches Anwendungsmodul wird ausgeführt, um denselben Replikationsgrad aufrechtzuerhalten, der für den Anwendungsmodultyp eingetragen worden ist. Nach Beförderung eines Anwendungsmoduls vom Backup-Zustand zum primären Zustand wird seine Bezeichnung in Tabelle 200 geändert, ebenso wie bei der im Leerlauf befindlichen Anwendung, die ausgeführt wird. Falls das ausgefallene Anwendungsmodul eine Backup-Kopie ist, dann wird eine im Leerlauf befindliche Kopie ausgeführt, und seine Bezeichnung in Tabelle 200 wird geändert, um diese Änderung wiederzugeben.
  • Wie in 1 dargestellt ist, ist Replikamanager 112 zentralisiert, d. h. nur eine Kopie des Replikamanagers läuft in dem Netzwerk. Die Replikationsinformationen für das Anwendungsmodul, das in dem Netzwerk läuft, laufen in Tabelle 200 zusammen, die im Speicher von Replikamanager 112 gehalten wird. Um den Verlust dieser Informationen im Fall von Ausfällen zu vermeiden, setzt diese Replikamanagertabelle Fixpunkte in Fixpunktserver 110.
  • Zusätzlich zu der Funktionalität der Wächterdämonen, die auf jedem Hostcomputer laufen, wird ein zentralisierter Superwächterdämonprozess 115-1 verwendet, um Absturz des Hosts zu erkennen und die Wiederherstellung durchzuführen. Alle Wächterdämonen lassen sich bei dem Superwächterdämon auf Erkennung von Hostabstürzen registrieren. Ausfallschutz wird durch eine Herzschlagerkennungsstrategie bewirkt. Jeder der Wächterdämonen 113 sendet periodisch ein Herzschlagsignal an den Superwächterdämon 115-1. Falls der Superwächter dämon 115-1 kein Herzschlagsignal von irgendeinem der Wächter 113 erhält, geht er davon aus, dass der Wächter und der Hostcomputer, auf dem er läuft, ausgefallen sind. Dann leitet er die Wiederherstellung nach dem Ausfall ein, indem der Replikamanager 112 über den Ausfall dieses Hostcomputers informiert wird. Da ein zentralisierter Superwächterdämon selbst zu einem Einzelausfallpunkt werden kann, repliziert er sich selbst, und die Replikas werden in einem warmen Replikationsformat gehalten. In 1 sind Superwächter-Backup-Kopien 115-2 und 115-3 von Superwächter 115-1 als auf Hostcomputern H5 beziehungsweise H6 befindlich gezeigt. Die drei Superwächterdämonen bilden eine logische Ringstruktur. Jeder Superwächterdämon sendet periodisch Herzschlagssignale an einen benachbarten Superwächter. In 1 sendet der primäre Superwächter 115-1 somit periodisch ein Herzschlagsignal an Superwächter 115-2, der wiederum periodisch ein Herzschlagsignal an Superwächter 115-3 sendet, der wiederum periodisch ein Herzschlagsignal zurück an Superwächter 115-1 sendet. Falls ein Superwächter kein Herzschlagsignal von seinem Nachbarn in dem Ring erhält, geht er davon aus, dass ein Ausfall stattgefunden hat. Eine Ersatzschaltprozedur für einen ausgefallenen Superwächter wird nachfolgend beschrieben.
  • Als Beispiel für die Wiederherstellung eines abgestürzten oder aufgehängten Anwendungsmoduls beziehen wir uns auf Anwendungsmodul A, das von Replikamanager 112 mit einem warmen Replikationsformat mit einem Grad von drei und einem Umschaltformat von OnEachFailure registriert worden ist. Am Anfang läuft Anwendungsmodul A1 auf Hostcomputer H1, wobei Backups A2 und A3 auf Hostcomputern H2 beziehungsweise H3 laufen. Anwendungsmodul A1 wird bei seinem lokalen Wächter 113-1 mit dem Erkennungsformat Abrufbetrieb registriert, so dass Wächter 113-1 Anwendungsmodul A1 periodisch abfragt. Zu irgendeiner Zeit stürzt Anwendungsmodul A1 auf Hostcomputer H1 ab, wobei der Ausfall von Wächter 113-1 erkannt wird. Wächter 113-1 teilt diesen Ausfall Replikamanager 112 mit, der in seiner internen Tabelle 200 nachschlägt und feststellt, dass ein primäres Anwendungsmodul vom Typ A ausgefallen ist und Backup-Anwendungen auf Hostcomputern H2 und H3 laufen. Es stuft eines dieser Backups (beispielsweise A2) hinauf auf den primären Zustand und ändert den Zustand von A2 in Tabelle 200 von Backup auf primär. Er stellt dann fest, dass eine Leerlaufkopie, A4, sich auf Hostcomputer H4 an der Pfadbezeichnung /home/chung/A.exe befindet, und startet dieses neue Backup, indem der Wächter 113-4 auf Hostcomputer H4 angewiesen wird, diese Kopie auszuführen. Somit laufen in dem Netzwerk nach Erkennen des Ausfalls von Anwendungsmodul A1 auf Hostcomputer H1 und dessen Wiederherstellung insgesamt drei Kopien von Anwendungsmodul A weiter, wodurch die Anzahl der laufenden Anwendungsmodule in dem Netzwerk auf drei entsprechend dem registrierten Replikationsgrad gehalten wird. Die Ausfallerkennung und Wiederherstellung eines aufgehängten Anwendungsmoduls ist genau gleich, außer dass in diesem Fall Herzschlagsignale anstelle von Abrufbetrieb als Mittel zur Ausfallerkennung verwendet werden.
  • Der auf jedem Hostcomputer laufende Wächter sendet Herzschlagsignale an den primären Superwächter in dem Netzwerk. Wächter 113-1 bis 113-6 senden somit Herzschlagsignale an Superwächter 115-1. Wenn ein Hostabsturz stattfindet, stürzt der darauf laufende Wächter ab, und Superwächter 115-1 erhält keine weiteren Herzschlagsignale von diesem Wächter. Falls beispielsweise Rost H1 abstürzt, erhält Superwächter 115-1 keine weiteren Herzschlagsignale von Wächter 113-1. Dann erklärt er Hostcomputer H1 für tot und teilt diesen Ausfall Replikamanager 112 mit. Replikamanager 112 greift auf Tabelle 200 zu, um zu ermitteln, dass Anwendungsmodule A1 und B2 auf Hostcomputer H1 gelaufen sind. Die Wiederherstellung für A1 wird wie zuvor beschrieben eingeleitet. Anwendungsmodul B2 wird als primäre Kopie eingesetzt. Die Leerlaufkopie B3, die sich auf Hostcomputer H5 befindet, wird dann ausgeführt, wodurch zwei laufende primäre Kopien von Anwendungsmodultyp B in dem Netzwerk aufrechterhalten werden. Der Zustand von B3 wird dann in Tabelle 200 von Leerlauf auf primär aktualisiert. Der Ausfall eines Wächterdämons, der auf einem Hostcomputer läuft, wird in der gleichen Weise wie ein Hostabsturz behandelt.
  • Wenn der Hostcomputer, auf dem ein Superwächterdämon läuft, abstürzt, erhält der Superwächter auf dem nächsten Hostcomputer des logischen Rings keine Herzschlagsignale mehr. Falls somit Hostcomputer H6 ausfällt oder Superwächter 115-3 auf dem Hostcomputer abstürzt, erhält Superwächter 115-1 auf Hostcomputer H2 keine weiteren Herzschlagsignale von Superwächter 115- 3. Er erklärt Superwächter 115-3 für tot und prüft, ob der tote Superwächter 115-3 ein primärer Superwächter war. Da Superwächter 115-3 ein Backup ist, muss er im Namen dieses Superwächters keine Aktionen durchführen. Der Superwächter 115-2 erhält dann eine Ausnahme (Exception), wenn er versucht, sein Herzschlagsignal an den Superwächter auf Hostcomputer H6 zu senden. Als Teil der Ausnahmebehandlung ermittelt Superwächter 115- 2 den Handle für Superwächter 115-1 auf Hostcomputer H1, registriert sich selbst darin und fängt an, Herzschlagsignale daran zu senden.
  • Falls Hostcomputer H2 ausfällt oder Superwächter 115-1 abstürzt, erkennt dann Superwächter 115-2 auf Hostcomputer H5 den Ausfall und ermittelt, dass der primäre Superwächter ausgefallen ist. Backup-Superwächter 115-2 übernimmt dann die Rolle des primären und startet den Replikamanagerdämon auf Hostcomputer H5. Die Wächter 113-1 bis 113-6 auf Hostcomputern H1 bis H6 erhalten jeweils Ausnahmen, wenn sie versuchen, Herzschlagsignale an den Superwächter 115-1 auf Hostcomputer H2 zu senden (der primär war). Als Teil der Ausnahmebehandlungsroutine ermittelt jeder Wächterdämon den neuen primären Superwächter 115-2, und Replikamanager 112 registriert sich selbst bei dem neuen primären Superwächter 115-2 und beginnt, ihm periodisch Herzschlagsignale zu senden. Da in dem Netzwerk nur eine Kopie des Replikamanagers läuft, wird der Zustand des Replikamanagers persistent gemacht, indem die Tabelle 200 in dem Fixpunktserver 110 gespeichert wird. Wenn somit der Replikamanager mit dem neuen primären Superwächter 115-2 auf Hostcomputer H5 migriert wird, lädt der auf diesem Host gestartete Replikamanager seinen Zustand von dem Fixpunktserver 110 und initialisiert seine interne Tabelle aus seinem gespeicherten Zustand neu. Wenn Replikamanager 112 ausfällt, wird in ähnlicher Weise sein Ausfall durch Superwächter 115-1 durch das Fehlen von Herzschlagsignalen erkannt. Superwächter 115-1 startet dann Replikamanager 112 auf demselben Hostcomputer neu, lädt seinen Zustand von dem Fixpunktserver 110 und initialisiert erneut seine interne Tabelle 200 aus seinem gespeicherten Zustand.
  • Die oben beschriebene Ausführungsform veranschaulicht die Prinzipien der vorliegenden Erfindung. Andere Ausführungsformen können von Fachleuten ersonnen werden, ohne von dem Umfang der vorliegenden Erfindung abzuweichen.

Claims (8)

  1. Fehlermanagementcomputervorrichtung, umfassend: einen Wächterdämonprozess (113-1), der auf einem ersten Hostcomputer (101) läuft, der in einem Netzwerk (100) mit anderen Hostcomputern (102, 103, 104, 105, 106) verbunden ist, auf denen jeweils ihr eigener Wächterdämonprozess (113-2, 113-3, 113-4, 113-5, 113-6) läuft, wobei der auf dem ersten Hostcomputer laufende Wächterdämonprozess eine Kopie von mindestens einem Anwendungsmodul (A-1) überwacht, die auf dem ersten Hostcomputer läuft, um einen Ausfall dieser Kopie des Anwendungsmoduls zu erkennen, wobei mindestens einer der anderen Hostcomputer eine Backup-Kopie (A2, A3, A4) des Anwendungsmoduls hat, die entweder läuft oder sich im Leerlauf zustand befindet, wobei die auf den anderen Hostcomputern laufenden Wächterdämonprozesse jegliche Backup-Kopie des auf ihnen laufenden Anwendungsmoduls überwachen, ein Replikationsgrad die Gesamtanzahl der Kopien des Anwendungsmoduls auf den Hostcomputern in dem Netzwerk spezifiziert, die in einem laufenden Zustand gehalten werden sollen; und einen Replikamanagerdämonprozess (112), der auf einem der Hostcomputer (102) in dem Netzwerk läuft, wobei der Replikamanagerdämonprozess so arbeitet, dass er eine Angabe von dem Wächterdämonprozess des ersten Hostcomputers erhält, dass die auf den ersten Hostcomputer laufende Kopie des Anwendungsmoduls ausgefallen ist, und/oder eine Angabe von dem auf beliebigen der anderen Hostcomputern laufenden Wächterdämonprozess erhält, dass die darauf laufende Backup-Kopie des Anwendungsmoduls ausgefallen ist, wobei der Replikamanagerdämonprozess als Reaktion auf das Erhalten einer Angabe des Ausfalls der auf beliebigen der Hostcomputer laufenden Kopie des Anwendungsmoduls die Wiederherstellung mit der Backup-Kopie auf minde stens einem der anderen Hostcomputer einleitet, auf dem sich eine Backup-Kopie des Anwendungsmoduls befindet, dadurch gekennzeichnet, dass der Replikamanagerdämonprozess automatisch mindestens eine der im Leerlauf befindlichen Backup-Kopien des Anwendungsmoduls auf mindestens einem Hostcomputer ausführt, wenn ein Ausfall einer auf beliebigen der Hostcomputer laufenden Kopie des Anwendungsmoduls erhalten worden ist, um die Gesamtanzahl der laufenden Kopien des Anwendungsmoduls auf den Hostcomputern in dem Netzwerk auf einem Replikationsgrad zu halten, der in einer Registrierungsnachricht spezifiziert ist, die der Replikadämonprozess von der auf dem ersten Hostcomputer laufenden Kopie des Anwendungsmoduls erhalten hat.
  2. Fehlermanagementcomputervorrichtung nach Anspruch 1, die weiterhin einen Fixpunktserver (110) umfasst, der mit dem Netzwerk verbunden ist, wobei der Fixpunktserver periodisch die Zustände der auf dem ersten Hostcomputer laufenden Kopie des Anwendungsmoduls und des Replikamanagerdämonprozesses speichert.
  3. Fehlermanagementcomputervorrichtung nach Anspruch 2, bei der die Wiederherstellung mit einer Backup-Kopie nach einem erkannten Ausfall der auf dem ersten Hostcomputer laufenden Kopie des Anwendungsmoduls eingeleitet wird, wobei die Backup-Kopie die Verarbeitungsfunktionen der ausgefallenen Kopie des Anwendungsmoduls übernimmt und von dem Fixpunktserver den letzten gespeicherten Zustand der ausgefallenen Kopie des Anwendungsmoduls abruft.
  4. Fehlermanagementcomputervorrichtung nach Anspruch 3, die weiterhin einen Superwächterdämonprozess (115-1) umfasst, der auf demselben Hostcomputer wie der Replikadämonprozess läuft, wobei der Superwächterdämonpro zess den ersten Hostcomputer auf Ausfall überwacht.
  5. Fehlermanagementcomputervorrichtung nach Anspruch 4, bei der, nachdem der Superwächterdämonprozess einen Ausfall des ersten Hostcomputers erkannt hat, einer Backup-Kopie der auf dem ausgefallenen ersten Hostcomputer laufenden Kopie des Anwendungsmoduls signalisiert wird, die Verarbeitungsfunktionen dieser Kopie des Anwendungsmoduls zu übernehmen, wobei die Backup-Kopie von dem Fixpunktserver den letzten gespeicherten Zustand dieser Kopie des Anwendungsmoduls abruft.
  6. Fehlermanagementcomputervorrichtung nach Anspruch 5, bei der die Registrierungsnachricht, die der Replikamanagerdämonprozess von dem Anwendungsmodul erhält, weiterhin eine Ersatzschaltstrategie spezifiziert, die angibt, ob die Backup-Kopie des Anwendungsmoduls die Verarbeitungsfunktionen der auf dem ersten Hostcomputers laufenden Kopie des Anwendungsmoduls jedes Mal übernehmen soll, wenn der Replikamanager einen Ausfall dieser Kopie feststellt, oder ob die Backup-Kopie diese Verarbeitungsfunktionen nur nach einer festgelegten Anzahl von Ausfällen dieser Kopie übernehmen soll.
  7. Verfahren zur fehlertoleranten Datenverarbeitung in einem Netzwerk (100), in dem mehrer Hostcomputer (101, 102, 103, 104, 105, 106) verbunden sind, das die Schritte umfasst, in denen auf einem ersten Hostcomputer (101) mindestens ein auf dem ersten Hostcomputer laufendes Anwendungsmodul (A1) überwacht wird, um einen Ausfall dieser Kopie des Anwendungsmoduls zu erkennen, wobei mindestens einer der anderen Hostcomputer eine laufende oder im Leerlauf befindliche Backup-Kopie (A2, A3, A4) des Anwendungsmoduls hat, wobei die laufende Backup-Kopie des Anwendungsmoduls auf dem anderen Hostcomputer überwacht wird, um einen Ausfall dieser Backup-Kopie zu erkennen, wobei ein Replikationsgrad die Gesamtanzahl der laufenden Kopien des Anwendungsmoduls auf den Hostcomputern in dem Netzwerk spezifiziert; auf einem der Hostcomputer eine Angabe erhalten wird, dass die auf dem ersten Hostcomputer laufenden Kopie des Anwendungsmoduls ausgefallen ist, und/oder eine Angabe erhalten wird, dass die auf einem der anderen Hostcomputer laufende Backup-Kopie des Anwendungsmoduls ausgefallen ist; und von dem Hostcomputer, auf dem die Angabe des Ausfalls einer Kopie des Anwendungsmoduls erhalten worden ist, die Wiederherstellung der ausgefallenen Kopie des Anwendungsmoduls mit der Backup-Kopie auf mindestens einem der anderen Hostcomputer eingeleitet wird, auf dem sich eine Backup-Kopie befindet; dadurch gekennzeichnet, dass das Verfahren weiterhin die Schritte umfasst, in denen auf dem Hostcomputer, von dem die Wiederherstellung von der auf dem ersten Hostcomputer laufenden Kopie des Anwendungsmoduls eingeleitet wird, eine Registrierungsnachricht erhalten wird, die einen Replikationsgrad für das Anwendungsmodul spezifiziert; und als Reaktion auf die Angabe des Ausfalls der auf einem beliebigen der Hostcomputer laufenden Kopie des Anwendungsmoduls automatisch mindestens eine der im Leerlauf befindlichen Backup-Kopien des Anwendungsmoduls auf mindestens einem Hostcomputer ausgeführt wird, auf dem sich eine im Leerlauf befindliche Kopie des Anwendungsmoduls befindet, um die Gesamtanzahl der laufenden Kopien des Anwendungsmoduls in dem Netzwerk auf dem Replikationsgrad zu halten, der in der erhaltenen Registrierungsnachricht spezifiziert ist.
  8. Verfahren nach Anspruch 7, bei dem die Registrie rungsnachricht weiterhin eine Ersatzschaltstrategie spezifiziert, die angibt, ob die Backup-Kopie des Anwendungsmoduls die Verarbeitungsfunktionen der auf dem ersten Hostcomputer laufenden Kopie dieses Anwendungsmoduls des Anwendungsmoduls jedes Mal übernehmen soll, wenn ein Ausfall dieser Kopie dieses Anwendungsmoduls erkannt wird, oder ob diese Backup-Kopie diese Verarbeitungsfunktionen nur nach einer festgelegten Anzahl von Ausfällen übernehmen soll.
DE69907824T 1998-07-20 1999-07-12 Verfahren und Vorrichtung zur Fehlererkennung und Wiederherstellung mit vorbestimmtem Replikationsgrad für verteilte Anwendungen in einem Netzwerk Expired - Lifetime DE69907824T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/119,140 US6195760B1 (en) 1998-07-20 1998-07-20 Method and apparatus for providing failure detection and recovery with predetermined degree of replication for distributed applications in a network
US119140 1998-07-20

Publications (2)

Publication Number Publication Date
DE69907824D1 DE69907824D1 (de) 2003-06-18
DE69907824T2 true DE69907824T2 (de) 2004-04-15

Family

ID=22382756

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69907824T Expired - Lifetime DE69907824T2 (de) 1998-07-20 1999-07-12 Verfahren und Vorrichtung zur Fehlererkennung und Wiederherstellung mit vorbestimmtem Replikationsgrad für verteilte Anwendungen in einem Netzwerk

Country Status (7)

Country Link
US (1) US6195760B1 (de)
EP (1) EP0981089B1 (de)
JP (1) JP2000105756A (de)
KR (1) KR20000011834A (de)
AU (1) AU752846B2 (de)
CA (1) CA2273708A1 (de)
DE (1) DE69907824T2 (de)

Families Citing this family (104)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6477663B1 (en) 1998-04-09 2002-11-05 Compaq Computer Corporation Method and apparatus for providing process pair protection for complex applications
US6449734B1 (en) 1998-04-17 2002-09-10 Microsoft Corporation Method and system for discarding locally committed transactions to ensure consistency in a server cluster
US6360331B2 (en) * 1998-04-17 2002-03-19 Microsoft Corporation Method and system for transparently failing over application configuration information in a server cluster
US6615244B1 (en) * 1998-11-28 2003-09-02 Tara C Singhal Internet based archive system for personal computers
US6393590B1 (en) * 1998-12-22 2002-05-21 Nortel Networks Limited Method and apparatus for ensuring proper functionality of a shared memory, multiprocessor system
US7376864B1 (en) * 1998-12-30 2008-05-20 Oracle International Corporation Method and system for diagnostic preservation of the state of a computer system
US6654801B2 (en) * 1999-01-04 2003-11-25 Cisco Technology, Inc. Remote system administration and seamless service integration of a data communication network management system
US6622257B1 (en) * 2000-02-11 2003-09-16 Micron Technology, Inc. Computer network with swappable components
GB2359384B (en) * 2000-02-16 2004-06-16 Data Connection Ltd Automatic reconnection of partner software processes in a fault-tolerant computer system
GB2359385B (en) * 2000-02-16 2004-04-07 Data Connection Ltd Method for upgrading running software processes without compromising fault-tolerance
US20010027457A1 (en) * 2000-03-22 2001-10-04 Terrence Yee Method and apparatus for storing changes to file attributes without having to store an additional copy of the file contents
US20010044834A1 (en) * 2000-03-22 2001-11-22 Robert Bradshaw Method and apparatus for automatically deploying data in a computer network
US6735717B1 (en) * 2000-04-13 2004-05-11 Gnp Computers, Inc. Distributed computing system clustering model providing soft real-time responsiveness and continuous availability
US7657887B2 (en) 2000-05-17 2010-02-02 Interwoven, Inc. System for transactionally deploying content across multiple machines
US7225244B2 (en) * 2000-05-20 2007-05-29 Ciena Corporation Common command interface
US7280529B1 (en) 2000-05-20 2007-10-09 Ciena Corporation Providing network management access through user profiles
US7181743B2 (en) * 2000-05-25 2007-02-20 The United States Of America As Represented By The Secretary Of The Navy Resource allocation decision function for resource management architecture and corresponding programs therefor
WO2002001347A2 (en) * 2000-06-30 2002-01-03 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for automatic re-assignment of software components of a failed host
US6879820B2 (en) 2000-07-12 2005-04-12 Telefonaktiebolaget Lm Ericsson (Publ) Charging in communication networks having split control planes and user planes
US7103002B2 (en) * 2000-07-12 2006-09-05 Telefonktiebolaget Lm Ericsson (Publ) Communication management in networks having split control planes and user planes
US6990606B2 (en) 2000-07-28 2006-01-24 International Business Machines Corporation Cascading failover of a data management application for shared disk file systems in loosely coupled node clusters
GB2368411B (en) 2000-10-25 2004-01-28 Proksim Software Inc Sharing data over a network
US6973054B2 (en) * 2001-01-05 2005-12-06 Telefonaktiebolaget Lm Ericsson (Publ) Communication management in mobile networks having split control planes and user planes
DE10101754C2 (de) 2001-01-16 2003-02-20 Siemens Ag Verfahren zur automatischen Wiederherstellung von Daten in einer Datenbasis
US10298735B2 (en) 2001-04-24 2019-05-21 Northwater Intellectual Property Fund L.P. 2 Method and apparatus for dynamic configuration of a multiprocessor health data system
US7146260B2 (en) 2001-04-24 2006-12-05 Medius, Inc. Method and apparatus for dynamic configuration of multiprocessor system
US7120693B2 (en) * 2001-05-08 2006-10-10 International Business Machines Corporation Method using two different programs to determine state of a network node to eliminate message response delays in system processing
US20050160088A1 (en) * 2001-05-17 2005-07-21 Todd Scallan System and method for metadata-based distribution of content
DE10138658B4 (de) * 2001-08-07 2005-08-11 Fujitsu Siemens Computers Gmbh Datenverarbeitungsvorrichtung und Kopplungsmittel für eine Datenverarbeitungsvorrichtung
US7389332B1 (en) 2001-09-07 2008-06-17 Cisco Technology, Inc. Method and apparatus for supporting communications between nodes operating in a master-slave configuration
US6766482B1 (en) 2001-10-31 2004-07-20 Extreme Networks Ethernet automatic protection switching
US6983397B2 (en) * 2001-11-29 2006-01-03 International Business Machines Corporation Method, system, and program for error handling in a dual adaptor system where one adaptor is a master
US7035595B1 (en) * 2002-01-10 2006-04-25 Berkana Wireless, Inc. Configurable wireless interface
US7020800B2 (en) * 2002-01-24 2006-03-28 Hewlett-Packard Development Company L.P. System and method for memory failure recovery using lockstep processes
US7043550B2 (en) * 2002-02-15 2006-05-09 International Business Machines Corporation Method for controlling group membership in a distributed multinode data processing system to assure mutually symmetric liveness status indications
US7421478B1 (en) 2002-03-07 2008-09-02 Cisco Technology, Inc. Method and apparatus for exchanging heartbeat messages and configuration information between nodes operating in a master-slave configuration
US7165258B1 (en) 2002-04-22 2007-01-16 Cisco Technology, Inc. SCSI-based storage area network having a SCSI router that routes traffic between SCSI and IP networks
US7587465B1 (en) 2002-04-22 2009-09-08 Cisco Technology, Inc. Method and apparatus for configuring nodes as masters or slaves
US7415535B1 (en) * 2002-04-22 2008-08-19 Cisco Technology, Inc. Virtual MAC address system and method
US7433952B1 (en) 2002-04-22 2008-10-07 Cisco Technology, Inc. System and method for interconnecting a storage area network
US7200610B1 (en) 2002-04-22 2007-04-03 Cisco Technology, Inc. System and method for configuring fibre-channel devices
US7188194B1 (en) * 2002-04-22 2007-03-06 Cisco Technology, Inc. Session-based target/LUN mapping for a storage area network and associated method
US7178049B2 (en) 2002-04-24 2007-02-13 Medius, Inc. Method for multi-tasking multiple Java virtual machines in a secure environment
US7240098B1 (en) 2002-05-09 2007-07-03 Cisco Technology, Inc. System, method, and software for a virtual host bus adapter in a storage-area network
US7385971B1 (en) 2002-05-09 2008-06-10 Cisco Technology, Inc. Latency reduction in network data transfer operations
US7509436B1 (en) 2002-05-09 2009-03-24 Cisco Technology, Inc. System and method for increased virtual driver throughput
US8447963B2 (en) 2002-06-12 2013-05-21 Bladelogic Inc. Method and system for simplifying distributed server management
US20040103185A1 (en) * 2002-11-21 2004-05-27 Combs Nathan Hideaki Adaptive self-repair and configuration in distributed systems
US7624158B2 (en) * 2003-01-14 2009-11-24 Eycast Inc. Method and apparatus for transmission and storage of digital medical data
US6973486B2 (en) * 2003-01-31 2005-12-06 Blakeney Kenneth M Alternate server system
US7831736B1 (en) 2003-02-27 2010-11-09 Cisco Technology, Inc. System and method for supporting VLANs in an iSCSI
US7295572B1 (en) 2003-03-26 2007-11-13 Cisco Technology, Inc. Storage router and method for routing IP datagrams between data path processors using a fibre channel switch
US7433300B1 (en) 2003-03-28 2008-10-07 Cisco Technology, Inc. Synchronization of configuration data in storage-area networks
US7904599B1 (en) 2003-03-28 2011-03-08 Cisco Technology, Inc. Synchronization and auditing of zone configuration data in storage-area networks
US7526527B1 (en) 2003-03-31 2009-04-28 Cisco Technology, Inc. Storage area network interconnect server
US7287179B2 (en) * 2003-05-15 2007-10-23 International Business Machines Corporation Autonomic failover of grid-based services
US7451208B1 (en) 2003-06-28 2008-11-11 Cisco Technology, Inc. Systems and methods for network address failover
US7359335B2 (en) * 2003-07-18 2008-04-15 International Business Machines Corporation Automatic configuration of network for monitoring
CN1292346C (zh) * 2003-09-12 2006-12-27 国际商业机器公司 用于在分布式计算体系结构中执行作业的系统和方法
CN1890990B (zh) * 2003-12-12 2011-04-06 诺基亚西门子通信有限责任两合公司 替代切换在空间上分开的交换系统的方法
US9213609B2 (en) * 2003-12-16 2015-12-15 Hewlett-Packard Development Company, L.P. Persistent memory device for backup process checkpoint states
JP2005196683A (ja) * 2004-01-09 2005-07-21 Hitachi Ltd 情報処理システム、情報処理装置、及び情報処理システムの制御方法
US20050216552A1 (en) * 2004-03-24 2005-09-29 Samuel Fineberg Communication-link-attached persistent memory system
US7711977B2 (en) 2004-04-15 2010-05-04 Raytheon Company System and method for detecting and managing HPC node failure
US9178784B2 (en) 2004-04-15 2015-11-03 Raytheon Company System and method for cluster management based on HPC architecture
US8190714B2 (en) 2004-04-15 2012-05-29 Raytheon Company System and method for computer cluster virtualization using dynamic boot images and virtual disk
US8335909B2 (en) 2004-04-15 2012-12-18 Raytheon Company Coupling processors to each other for high performance computing (HPC)
US8336040B2 (en) 2004-04-15 2012-12-18 Raytheon Company System and method for topology-aware job scheduling and backfilling in an HPC environment
US7680904B2 (en) * 2004-08-06 2010-03-16 Logic Controls, Inc. Diagnostic method and apparatus for detecting and locating computer network discontinuities
JP2006079418A (ja) * 2004-09-10 2006-03-23 Fujitsu Ltd 記憶制御装置、制御方法及びプログラム
US7818615B2 (en) 2004-09-16 2010-10-19 Invensys Systems, Inc. Runtime failure management of redundantly deployed hosts of a supervisory process control data acquisition facility
US20060056285A1 (en) * 2004-09-16 2006-03-16 Krajewski John J Iii Configuring redundancy in a supervisory process control system
US7561544B2 (en) * 2004-10-27 2009-07-14 Honeywell International Inc. Machine architecture for event management in a wireless sensor network
US8027280B2 (en) * 2004-10-27 2011-09-27 Honeywell International Inc. Layered architecture for data management in a wireless sensor network
US7590098B2 (en) * 2004-10-27 2009-09-15 Honeywell International Inc. Publish/subscribe model in a wireless sensor network
US7664080B2 (en) * 2004-10-27 2010-02-16 Honeywell International Inc. Discreet event operators for event management in a wireless sensor network
US7630336B2 (en) * 2004-10-27 2009-12-08 Honeywell International Inc. Event-based formalism for data management in a wireless sensor network
US7475274B2 (en) 2004-11-17 2009-01-06 Raytheon Company Fault tolerance and recovery in a high-performance computing (HPC) system
US8244882B2 (en) 2004-11-17 2012-08-14 Raytheon Company On-demand instantiation in a high-performance computing (HPC) system
US7433931B2 (en) 2004-11-17 2008-10-07 Raytheon Company Scheduling in a high-performance computing (HPC) system
US7715308B2 (en) * 2004-12-09 2010-05-11 Honeywell International Inc. Fault tolerance in a wireless network
US7320088B1 (en) 2004-12-28 2008-01-15 Veritas Operating Corporation System and method to automate replication in a clustered environment
US7941507B1 (en) * 2005-01-21 2011-05-10 Network Engines, Inc. High-availability network appliances and methods
US7478278B2 (en) * 2005-04-14 2009-01-13 International Business Machines Corporation Template based parallel checkpointing in a massively parallel computer system
KR100844101B1 (ko) * 2005-11-16 2008-07-07 성균관대학교산학협력단 동적 윈도우 기반 고장 모니터링 시스템 및 모니터링 방법
JP5235292B2 (ja) * 2006-09-29 2013-07-10 富士通株式会社 コンピュータシステム、バックアップシステムへの移行方法、バックアップシステムへの移行プログラム、監視装置、端末装置及びバックアップシステム
US8166156B2 (en) * 2006-11-30 2012-04-24 Nokia Corporation Failure differentiation and recovery in distributed systems
JP5251002B2 (ja) * 2007-05-25 2013-07-31 富士通株式会社 分散処理プログラム、分散処理方法、分散処理装置、および分散処理システム
US7827444B2 (en) * 2007-09-28 2010-11-02 Intel Corporation Application crash resist method and apparatus
US8626954B2 (en) * 2008-08-28 2014-01-07 Alcatel Lucent Application-aware M:N hot redundancy for DPI-based application engines
JP4648447B2 (ja) 2008-11-26 2011-03-09 株式会社日立製作所 障害復旧方法、プログラムおよび管理サーバ
US8880473B1 (en) 2008-12-15 2014-11-04 Open Invention Network, Llc Method and system for providing storage checkpointing to a group of independent computer applications
US9358924B1 (en) 2009-05-08 2016-06-07 Eagle Harbor Holdings, Llc System and method for modeling advanced automotive safety systems
US20110179303A1 (en) * 2010-01-15 2011-07-21 Microsoft Corporation Persistent application activation and timer notifications
US9002946B2 (en) * 2010-08-25 2015-04-07 Autodesk, Inc. Dual modeling environment in which commands are executed concurrently and independently on both a light weight version of a proxy module on a client and a precise version of the proxy module on a server
US8621274B1 (en) * 2011-05-18 2013-12-31 Netapp Inc. Virtual machine fault tolerance
US8856585B2 (en) * 2011-08-01 2014-10-07 Alcatel Lucent Hardware failure mitigation
US9037897B2 (en) 2012-02-17 2015-05-19 International Business Machines Corporation Elastic cloud-driven task execution
US10365964B1 (en) 2018-05-31 2019-07-30 Capital One Services, Llc Data processing platform monitoring
JP7038016B2 (ja) * 2018-07-05 2022-03-17 本田技研工業株式会社 水素ステーション
CN109871299A (zh) * 2019-01-23 2019-06-11 西安微电子技术研究所 一种基于物理隔离的双机冷备份共享存储系统及方法
CN110471672A (zh) * 2019-08-13 2019-11-19 天津津航计算技术研究所 一种基于逻辑芯片的dsp烧写防密码锁死电路
CN110688427B (zh) * 2019-09-11 2022-03-04 北京控制工程研究所 一种四机热备份实时系统的异步数据同步方法
US11683348B2 (en) 2020-07-10 2023-06-20 International Business Machines Corporation Bypassing security vulnerable and anomalous devices in multi-device workflow

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2560510B2 (ja) * 1990-03-06 1996-12-04 日本電気株式会社 ネットワーク管理マネージャ切り替え方式
CA2106280C (en) * 1992-09-30 2000-01-18 Yennun Huang Apparatus and methods for fault-tolerant computing employing a daemon monitoring process and fault-tolerant library to provide varying degrees of fault tolerance
US5408649A (en) * 1993-04-30 1995-04-18 Quotron Systems, Inc. Distributed data access system including a plurality of database access processors with one-for-N redundancy
US5664090A (en) * 1993-12-15 1997-09-02 Kabushiki Kaisha Toshiba Processor system and method for maintaining internal state consistency between active and stand-by modules
US5440726A (en) * 1994-06-22 1995-08-08 At&T Corp. Progressive retry method and apparatus having reusable software modules for software failure recovery in multi-process message-passing applications
JP3865775B2 (ja) * 1995-04-11 2007-01-10 キネテック インコーポレイテッド データ処理システムにおけるデータの識別
US5666486A (en) * 1995-06-23 1997-09-09 Data General Corporation Multiprocessor cluster membership manager framework

Also Published As

Publication number Publication date
DE69907824D1 (de) 2003-06-18
KR20000011834A (ko) 2000-02-25
US6195760B1 (en) 2001-02-27
CA2273708A1 (en) 2000-01-20
AU752846B2 (en) 2002-10-03
EP0981089B1 (de) 2003-05-14
EP0981089A2 (de) 2000-02-23
AU4020499A (en) 2000-02-10
JP2000105756A (ja) 2000-04-11
EP0981089A3 (de) 2001-06-06

Similar Documents

Publication Publication Date Title
DE69907824T2 (de) Verfahren und Vorrichtung zur Fehlererkennung und Wiederherstellung mit vorbestimmtem Replikationsgrad für verteilte Anwendungen in einem Netzwerk
DE69907818T2 (de) Verfahren und Vorrichtung zur Fehlererkennung und Wiederherstellung mit vorbestimmter Replikationsart für verteilte Anwendungen in einem Netzwerk
DE60224274T2 (de) Wiederherstellungsrechner für eine mehrzahl von vernetzten rechnern
DE69918467T2 (de) Servervorrichtung und Verfahren deren Verwendung
DE10124482B4 (de) Fehlertolerante Systemressource mit niedriger Latenzzeit, mit übergeordneter Protokollierung von Systemressourcentransaktionen und serverübergreifend gespiegelter Protokollierung von übergeordneten Systemressourcentransaktionen
DE602004002858T2 (de) Vorrichtung und Verfahren zur Datenarchivierung in einem Clustersystem
DE60220263T2 (de) Server-duplexverfahren und geduplextes serversystem
DE112016001295T5 (de) Neusynchronisieren auf ein erstes Speichersystem durch Spiegeln des ersten Speichersystems nach einem Failover zu einem zweiten Speichersystem
DE10123067B4 (de) Synchrone Vervielfältigung von Transaktionen in einem verteilten System
DE102004027672A1 (de) Speicherplattenarraysystem
DE69907709T2 (de) Prozessüberwachung in einem rechnersystem
DE112011104471T5 (de) Verfahren zur Failover-Verwaltung von virtuellen Maschinen und System zum Unterstützen desselben
DE60313468T2 (de) Speicherdienste und -systeme
DE3727850A1 (de) Fehler-pruefsystem
DE102012109614A1 (de) Fehlerbehebung bei Stapel-Korruption in eingebetteten Softwaresystemen
EP1358554B1 (de) Automatische inbetriebnahme eines clustersystems nach einem heilbaren fehler
DE69907852T2 (de) Hochverfügbare asynchrone Ein/Ausgabe für gruppierte Rechnersysteme
DE112004000334T5 (de) Auf Richtlinien basierende Reaktion auf Systemfehler, die während der Betriebssystemlaufzeit eintreten
US6973486B2 (en) Alternate server system
US7120821B1 (en) Method to revive and reconstitute majority node set clusters
EP1820307B1 (de) Verfahren zum nachweis der verf]gbarkeit von systemkomponenten eines redundanten kommunikationssystems
Lin et al. PacificA: Replication in log-based distributed storage systems
DE112012006736T5 (de) Empfangen eines Update-Moduls durch Zugreifen auf eine Netzwerkstelle
US7469268B2 (en) Managing data received from processes of a distributed computing arrangement
DE102021127286A1 (de) Benachrichtigung über den abschluss einer schreibanforderung als reaktion auf die teilweise härtung von schreibdaten

Legal Events

Date Code Title Description
8364 No opposition during term of opposition