DE69907818T2 - Verfahren und Vorrichtung zur Fehlererkennung und Wiederherstellung mit vorbestimmter Replikationsart für verteilte Anwendungen in einem Netzwerk - Google Patents

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

Info

Publication number
DE69907818T2
DE69907818T2 DE69907818T DE69907818T DE69907818T2 DE 69907818 T2 DE69907818 T2 DE 69907818T2 DE 69907818 T DE69907818 T DE 69907818T DE 69907818 T DE69907818 T DE 69907818T DE 69907818 T2 DE69907818 T2 DE 69907818T2
Authority
DE
Germany
Prior art keywords
copy
application module
running
backup
host computer
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
DE69907818T
Other languages
English (en)
Other versions
DE69907818D1 (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 DE69907818D1 publication Critical patent/DE69907818D1/de
Publication of DE69907818T2 publication Critical patent/DE69907818T2/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
    • G06F11/30—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/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2097—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements maintaining the standby controller/processing unit updated
    • 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/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • 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
    • 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/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2038—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with a single idle spare processing component

Description

  • TECHNISCHES GEBIET
  • Diese Erfindung betrifft das Erkennen 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 ge startet, 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 zur 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 demselben 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 ließen 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 Datenbankcomputereinrichtungen 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ämonprozess, 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 Anwendungsmoduls zugeordnet werden soll, wobei die registrierte Replikationsstrategie von dem Replikamanager verwendet wird, um den Betriebszustand von jeder Backup-Kopie 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 als das neue primäre Anwendungsmodul ernannt, und einem Hostcomputer, auf dem sich eine Leerlaufkopie des Anwendungsmoduls befindet, wird über das Netzwerk signalisiert, diese im Leerlauf befindliche Anwendung 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 im Leerlauf befindliche Kopie des Anwendungsmoduls befindet, über das Netzwerk signalisiert, diese im Leerlauf befindliche Kopie 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 ist. 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 Anwendungsmodule, 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 Backup-Kopien 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 Leerlaufzustand 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 Replikationsgrad 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 Anwendungsmoduls oder eines ganzen Hostcomputers zu bewirken, auf dem mehrere unterschiedliche Anwendungsmodule laufen. 2 veranschaulicht im Format einer Tabelle 200 den Typ der gespeicherten Informationen 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 vom 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.
  • Wiederum 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ächterdä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 ausgefallene 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 somit 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 jedes 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 den 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ächterdä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 Herzschlagsignale 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 einem beliebigen 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 Re plikamanager 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) auf den primären Zustand hinauf und ändert den Zustand von A2 in Tabelle 200 von Backup auf primär. Er stellt dann fest, dass eine im Leerlauf befindliche Kopie, 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 Host 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 vom 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 an ihn 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 (14)

  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 weitere Kopie (A2, A3, A4) des Anwendungsmoduls als Backup-Kopie hat, wobei die Kopien des Anwendungsmoduls auf den Hostcomputern, die in dem Netzwerk verbunden sind, in einem von mehreren unterschiedlichen Replikationsformaten gehalten werden; und einen Replikamanagerdämonprozess (112), der auf einem der Hostcomputer (162) 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 darauf laufende Kopie des Anwendungsmoduls ausgefallen ist, wobei der Replikamanagerdämonprozess als Reaktion auf das Erhalten einer Angabe des Ausfalls der auf dem ersten Hostcomputer laufenden Kopie des Anwendungsmoduls die Wiederherstellung mit der Backup-Kopie des ausgefallenen Anwendungsmoduls einleitet, die sich auf mindestens einem der anderen Hostcomputer befindet, dadurch gekennzeichnet, dass der Replikamanagerdämonprozess automatisch jede Kopie des Anwendungsmoduls in ein Replikationsformat setzt und in diesem hält, das in einer Registrierungsnachricht spezifiziert ist, die der Replikamanagerdämonprozess von der auf dem ersten Hostcomputer laufenden Kopie des Anwendungsmoduls erhält.
  2. Fehlermanagementcomputervorrichtung nach Anspruch 1, bei der das in der Registrierungsnachricht spezifizierte Replikationsformat angibt, ob die Backup-Kopie des Anwendungsmoduls simultan auf einem der anderen Hostcomputer laufen soll oder nicht, während sie auf dem ersten Hostcomputer läuft, und ob die Backup-Kopie eine Anfrage eines Clients erhalten und auf diese reagieren kann, falls die Backup-Kopie simultan laufen soll.
  3. Fehlermanagementcomputervorrichtung nach Anspruch 1, bei der die unterschiedlichen Replikationsformate kaltes Backup, warmes Backup und heißes Backup sind, wobei gemäß dem kalten Backup-Format die Backup-Kopie nicht auf einem der anderen Hostcomputer läuft, während die Kopie des Anwendungsmoduls auf dem ersten Hostcomputer läuft; gemäß dem warmen Backup-Format die Backup-Kopie auf einem der anderen Hostcomputer läuft, während die Kopie des Anwendungsmoduls auf dem ersten Hostcomputer läuft, jedoch eine Anfrage eines Clients nicht erhalten und auf diese reagieren kann; und gemäß dem heißen Backup-Format die Backup-Kopie auf einem der anderen Hostcomputer läuft, während die Kopie des Anwendungsmoduls auf dem ersten Hostcomputer läuft, und eine Anfrage eines Clients erhalten und auf diese reagieren kann.
  4. 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.
  5. Fehlermanagementcomputervorrichtung nach Anspruch 4, bei der die Wiederherstellung mit der 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 dieser Kopie des Anwendungsmoduls abruft.
  6. Fehlermanagementcomputervorrichtung nach Anspruch 4, die weiterhin einen Superwächterdämonprozess (115-1) umfasst, der auf demselben Hostcomputer wie der Replikadämonprozess läuft, wobei der Superwächterdämonprozess den ersten Hostcomputer auf Ausfall überwacht.
  7. Fehlermanagementcomputervorrichtung nach Anspruch 6, bei der, nachdem der Superwächterdämonprozess einen Ausfall des ersten Hostcomputers erkannt hat, einer Backup-Kopie der auf dem 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.
  8. Fehlermanagementcomputervorrichtung nach Anspruch 3, bei der die Registrierungsnachricht weiterhin einen Replikationsgrad spezifiziert, der bei einem heißen oder warmen Backup-Replikationsformat die Gesamtzahl der Kopien des Anwendungsmoduls angibt, die auf den Hostcomputern in dem Netzwerk in einem laufenden Zustand gehalten werden sollen.
  9. Fehlermanagementcomputervorrichtung nach Anspruch 5, bei der die Registrierungsnachricht weiterhin eine Ersatzschaltstrategie spezifiziert, die angibt, ob die Backup-Kopie die Verarbeitungsfunktionen der auf dem ersten Hostcomputer laufenden Kopie des Anwendungsmoduls jedes Mal übernehmen soll, wenn der Replikamanager einen Ausfall dieser Kopie feststellt, oder ob die Backup-Kopie die Verarbeitungsfunktionen dieser Kopie nur nach einer festgelegten Anzahl von Ausfällen übernehmen soll.
  10. Verfahren zur fehlertoleranten Datenverarbeitung in einem Netzwerk (100), in dem mehrere Hostcomputer (101, 102, 103, 104, 105, 106) verbunden sind, das die Schritte umfasst, in denen auf einem ersten Hostcomputer (101) eine auf dem ersten Hostcomputer laufende Kopie von mindestens einem Anwendungsmodul (A1) überwacht wird, um einen Ausfall dieser Kopie des Anwendungsmoduls zu erkennen, wobei mindestens einer der anderen Hostcomputer eine weitere Kopie (A2, A3, A4) des Anwendungsmoduls als Backup-Kopie hat, wobei die Kopien des Anwendungsmoduls auf den Hostcomputern in dem Netzwerk in einem von mehreren unterschiedlichen Replikationsformaten gehalten werden; auf einem der Hostcomputer eine Angabe erhalten wird, dass die auf dem ersten Hostcomputer laufende Kopie des Anwendungsmoduls ausgefallen ist; und von dem Hostcomputer, auf dem die Angabe des Ausfalls erhalten worden ist, die Wiederherstellung der ausgefallenen Kopie des Anwendungsmoduls mit der Backup-Kopie auf mindestens einem der 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 eingeleitet wird, von der auf dem ersten Hostcomputer laufenden Kopie des Anwendungsmoduls eine Registrierungsnachricht erhalten wird, die ein Replikationsformat für die Kopien des Anwendungsmoduls auf den Hostcomputern spezifiziert; und automatisch die Kopien des Anwendungsmoduls auf den Hostcomputern in dem Netzwerk in das in der Registrierungsnachricht spezifizierte Replikationsformat gesetzt und in diesem gehalten werden.
  11. Verfahren nach Anspruch 10, bei dem das in der Registrierungsnachricht spezifizierte Replikationsformat angibt, ob die Backup-Kopie des Anwendungsmoduls simultan auf einem der anderen Hostcomputer laufen soll oder nicht, während die Kopie des Anwendungsprogramms auf dem ersten Hostcomputer läuft, und ob die Backup-Kopie eine Anfrage eines Clients erhalten und auf diese reagieren kann, falls die Backup-Kopie simultan laufen soll.
  12. Verfahren nach Anspruch 10, bei dem die unterschiedlichen Replikationsformate kaltes Backup, warmes Backup und heißes Backup sind, wobei gemäß dem kalten Backup-Format die Backup-Kopie nicht auf einem der anderen Hostcomputer läuft, während die Kopie des Anwendungsmoduls auf dem ersten Hostcomputer läuft; gemäß dem warmen Backup-Format die Backup-Kopie auf einem der anderen Hostcomputer läuft, während die Kopie des Anwendungsmoduls auf dem ersten Hostcomputer läuft, jedoch eine Anfrage eines Clients nicht erhalten und auf diese reagieren kann; und gemäß dem heißen Backup-format die Backup-Kopie auf einem der anderen Hostcomputer läuft, während die Kopie des Anwendungsmoduls auf dem ersten Hostcomputer läuft, und eine Anfrage eines Clients erhalten und auf diese reagieren kann.
  13. Verfahren nach Anspruch 12, bei dem die Registrierungsnachricht weiterhin einen Replikationsgrad spezifiziert, der bei einem heißen oder warmen Backup-Replikationsformat die Gesamtzahl der Kopien des Anwendungsmoduls angibt, die auf den Hostcomputern in dem Netzwerk in einem laufenden Zustand gehalten werden sollen.
  14. Verfahren nach Anspruch 10, bei dem die Registrierungsnachricht weiterhin eine Ersatzschaltstrategie spezifiziert, die angibt, ob die Backup-Kopie die Verarbeitungsfunktionen der auf dem ersten Hostcomputer laufenden Kopie des Anwendungsmoduls jedes Mal übernehmen soll, wenn ein Ausfall dieser Kopie erkannt wird, oder ob die Backup-Kopie die Verarbeitungsfunktionen dieser Kopie nur nach einer festgelegten Anzahl von Ausfällen übernehmen soll.
DE69907818T 1998-07-20 1999-07-12 Verfahren und Vorrichtung zur Fehlererkennung und Wiederherstellung mit vorbestimmter Replikationsart für verteilte Anwendungen in einem Netzwerk Expired - Lifetime DE69907818T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/119,139 US6266781B1 (en) 1998-07-20 1998-07-20 Method and apparatus for providing failure detection and recovery with predetermined replication style for distributed applications in a network
US119139 1998-07-20

Publications (2)

Publication Number Publication Date
DE69907818D1 DE69907818D1 (de) 2003-06-18
DE69907818T2 true DE69907818T2 (de) 2004-03-04

Family

ID=22382753

Family Applications (1)

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

Country Status (7)

Country Link
US (1) US6266781B1 (de)
EP (1) EP0974903B1 (de)
JP (1) JP2000105754A (de)
KR (1) KR20000011835A (de)
AU (1) AU752844B2 (de)
CA (1) CA2273523C (de)
DE (1) DE69907818T2 (de)

Families Citing this family (116)

* 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
US6393583B1 (en) * 1998-10-29 2002-05-21 International Business Machines Corporation Method of performing checkpoint/restart of a parallel program
US6401216B1 (en) 1998-10-29 2002-06-04 International Business Machines Corporation System of performing checkpoint/restart of a parallel program
US6928469B1 (en) 1998-12-29 2005-08-09 Citrix Systems, Inc. Apparatus and method for determining a program neighborhood for a client node in a client-server network using markup language techniques
US6643690B2 (en) * 1998-12-29 2003-11-04 Citrix Systems, Inc. Apparatus and method for determining a program neighborhood for a client node in a client-server network
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
US6523130B1 (en) * 1999-03-11 2003-02-18 Microsoft Corporation Storage system having error detection and recovery
US6687847B1 (en) * 1999-04-21 2004-02-03 Cornell Research Foundation, Inc. Failure detector with consensus protocol
KR100324275B1 (ko) * 1999-07-14 2002-02-25 서평원 이중화된 프로세서의 이중화 상태 제어 방법
US6718486B1 (en) * 2000-01-26 2004-04-06 David E. Lovejoy Fault monitor for restarting failed instances of the fault monitor
US7627694B2 (en) * 2000-03-16 2009-12-01 Silicon Graphics, Inc. Maintaining process group membership for node clusters in high availability computing systems
US20020198996A1 (en) * 2000-03-16 2002-12-26 Padmanabhan Sreenivasan Flexible failover policies in high availability computing systems
US6742134B1 (en) * 2000-05-20 2004-05-25 Equipe Communications Corporation Maintaining a local backup for data plane processes
US20020026385A1 (en) * 2000-08-31 2002-02-28 Mccloskey John M. System and methods for generating an electronic purchase order for a part using a display of computer-aided design (CAD) drawing and related article and media
EP1323040A4 (de) * 2000-09-08 2005-08-03 Goahead Software Inc System und verfahren zur verwaltung von clustern mit mehreren knoten
US20020073409A1 (en) * 2000-12-13 2002-06-13 Arne Lundback Telecommunications platform with processor cluster and method of operation thereof
DE10101754C2 (de) 2001-01-16 2003-02-20 Siemens Ag Verfahren zur automatischen Wiederherstellung von Daten in einer Datenbasis
EP1360796B1 (de) * 2001-01-26 2009-12-23 American Power Conversion Corporation Verfahren und vorrichtung für netzfähige geräte, die verbunden werden können, um verbesserte zusammenarbeit, skalierbarkeit und zuverlässigkeit zu erzielen
KR100423701B1 (ko) * 2001-02-08 2004-03-18 주식회사 클래러스 가상적으로 통합된 분산파일그룹에 데이터를 백업하기위한 방법 및 시스템
US20060162639A1 (en) * 2001-03-23 2006-07-27 Costello James M Touch tunnel
US20020143914A1 (en) * 2001-03-29 2002-10-03 Cihula Joseph F. Network-aware policy deployment
US20020152425A1 (en) * 2001-04-12 2002-10-17 David Chaiken Distributed restart in a multiple processor system
US6957251B2 (en) * 2001-05-07 2005-10-18 Genworth Financial, Inc. System and method for providing network services using redundant resources
US7000100B2 (en) * 2001-05-31 2006-02-14 Hewlett-Packard Development Company, L.P. Application-level software watchdog timer
US6954884B2 (en) * 2001-06-01 2005-10-11 Lucent Technologies Inc. System and method for effecting recovery of a network
US20030037133A1 (en) * 2001-08-15 2003-02-20 Thomas Owens Method and system for implementing redundant servers
US7003775B2 (en) * 2001-08-17 2006-02-21 Hewlett-Packard Development Company, L.P. Hardware implementation of an application-level watchdog timer
US6766482B1 (en) 2001-10-31 2004-07-20 Extreme Networks Ethernet automatic protection switching
US7127512B2 (en) * 2002-02-19 2006-10-24 Qualcomm Inc. Method and apparatus for two-phase commit in data distribution to a web farm
US7392421B1 (en) * 2002-03-18 2008-06-24 Symantec Operating Corporation Framework for managing clustering and replication
US7689875B2 (en) * 2002-04-25 2010-03-30 Microsoft Corporation Watchdog timer using a high precision event timer
US7124320B1 (en) * 2002-08-06 2006-10-17 Novell, Inc. Cluster failover via distributed configuration repository
JP2004086721A (ja) * 2002-08-28 2004-03-18 Nec Corp データ複製システム、中継装置、データ送受信方法およびストレージ内のデータを複製するためのプログラム
US20040153700A1 (en) * 2003-01-02 2004-08-05 Nixon Mark J. Redundant application stations for process control systems
JP4321705B2 (ja) * 2003-07-29 2009-08-26 株式会社日立製作所 スナップショットの取得を制御するための装置及び記憶システム
US7178052B2 (en) * 2003-09-18 2007-02-13 Cisco Technology, Inc. High availability virtual switch
AU2003304502A1 (en) * 2003-10-13 2005-04-27 Illuminator (Israel) Ltd. Apparatus and method for information recovery quality assessment in a computer system
US9213609B2 (en) * 2003-12-16 2015-12-15 Hewlett-Packard Development Company, L.P. Persistent memory device for backup process checkpoint states
US7890798B1 (en) * 2004-03-22 2011-02-15 Hewlett-Packard Development Company, L.P. Computer cluster with second-node instance of application having access to state snapshot of first-node instance of application
US20050216552A1 (en) * 2004-03-24 2005-09-29 Samuel Fineberg Communication-link-attached persistent memory system
US7680904B2 (en) * 2004-08-06 2010-03-16 Logic Controls, Inc. Diagnostic method and apparatus for detecting and locating computer network discontinuities
US8042116B2 (en) * 2004-09-17 2011-10-18 Panasonic Corporation Task switching based on the execution control information held in register groups
DE102004050350B4 (de) 2004-10-15 2006-11-23 Siemens Ag Verfahren und Vorrichtung zur Redundanzkontrolle von elektrischen Einrichtungen
US7561544B2 (en) * 2004-10-27 2009-07-14 Honeywell International Inc. Machine architecture 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
US7664080B2 (en) * 2004-10-27 2010-02-16 Honeywell International Inc. Discreet event operators for event 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
US8027280B2 (en) * 2004-10-27 2011-09-27 Honeywell International Inc. Layered architecture for data management in a wireless sensor network
US20060106761A1 (en) * 2004-10-29 2006-05-18 Parthasarathy Sarangam Remote detection of a fault condition of a management application using a networked device
US7715308B2 (en) * 2004-12-09 2010-05-11 Honeywell International Inc. Fault tolerance in a wireless network
US7478278B2 (en) * 2005-04-14 2009-01-13 International Business Machines Corporation Template based parallel checkpointing in a massively parallel computer system
US7908606B2 (en) * 2005-05-20 2011-03-15 Unisys Corporation Usage metering system
US7823021B2 (en) 2005-05-26 2010-10-26 United Parcel Service Of America, Inc. Software process monitor
US8332826B2 (en) 2005-05-26 2012-12-11 United Parcel Service Of America, Inc. Software process monitor
US7558986B2 (en) * 2005-05-26 2009-07-07 United Parcel Service Of America, Inc. Software process monitor
KR100589437B1 (ko) * 2005-06-22 2006-06-14 엔에이치엔(주) 동적 서버 초기화 방법 및 시스템
US8301700B1 (en) 2010-08-06 2012-10-30 Open Invention Network Llc System and method for event-driven live migration of multi-process applications
US8621275B1 (en) 2010-08-06 2013-12-31 Open Invention Network, Llc System and method for event-driven live migration of multi-process applications
US8589953B1 (en) 2010-08-06 2013-11-19 Open Invention Network, Llc System and method for transparent consistent application-replication of multi-process multi-threaded applications
US9043640B1 (en) * 2005-08-26 2015-05-26 Open Invention Network, LLP System and method for event-driven live migration of multi-process applications
US9141481B1 (en) 2010-08-06 2015-09-22 Open Invention Network, Llc System and method for reliable non-blocking messaging for multi-process application replication
US8584145B1 (en) 2010-08-06 2013-11-12 Open Invention Network, Llc System and method for dynamic transparent consistent application-replication of multi-process multi-threaded applications
US8281184B1 (en) 2010-08-06 2012-10-02 Open Invention Network Llc System and method for reliable non-blocking messaging for multi-process application replication
US7849369B2 (en) * 2005-10-25 2010-12-07 Waratek Pty Ltd. Failure resistant multiple computer system and method
US7979460B2 (en) 2006-02-15 2011-07-12 Sony Computer Entainment America Inc. Systems and methods for server management
US8676959B2 (en) * 2006-03-27 2014-03-18 Sap Ag Integrated heartbeat monitoring and failover handling for high availability
US20080126506A1 (en) * 2006-10-05 2008-05-29 Holt John M Multiple computer system with redundancy architecture
SE0950005L (sv) * 2006-11-10 2008-05-11 Densitech Ab Tillhandahållande säkerhet i förhållande till mobilterminaler
US7757117B2 (en) * 2007-04-17 2010-07-13 International Business Machines Corporation Method and apparatus for testing of enterprise systems
TW200915062A (en) * 2007-09-20 2009-04-01 Promos Technologies Inc Method for managing application programs by utilizing redundancy and load balance
US8447940B2 (en) * 2008-05-02 2013-05-21 International Business Machines Corporation Backup copy enhancements to reduce primary version access
US8019732B2 (en) 2008-08-08 2011-09-13 Amazon Technologies, Inc. Managing access of multiple executing programs to non-local block data storage
US8626954B2 (en) * 2008-08-28 2014-01-07 Alcatel Lucent Application-aware M:N hot redundancy for DPI-based application engines
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
KR20110052289A (ko) * 2009-11-12 2011-05-18 삼성전자주식회사 소프트웨어 구조에서 커먼모듈 운용 장치 및 방법
US9135127B1 (en) 2010-08-06 2015-09-15 Open Invention Network, Llc System and method for dynamic transparent consistent application-replication of multi-process multi-threaded applications
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
US9240937B2 (en) * 2011-03-31 2016-01-19 Microsoft Technology Licensing, Llc Fault detection and recovery as a service
US8621274B1 (en) * 2011-05-18 2013-12-31 Netapp Inc. Virtual machine fault tolerance
US9047182B2 (en) 2012-12-27 2015-06-02 Microsoft Technology Licensing, Llc Message service downtime
US10223156B2 (en) 2013-06-09 2019-03-05 Apple Inc. Initiating background updates based on user activity
US9110864B2 (en) * 2013-06-25 2015-08-18 International Business Machines Corporation Fault tolerance solution for stateful applications
WO2015084726A1 (en) 2013-12-02 2015-06-11 Qbase, LLC Event detection through text analysis template models
US9223833B2 (en) 2013-12-02 2015-12-29 Qbase, LLC Method for in-loop human validation of disambiguated features
US9177262B2 (en) 2013-12-02 2015-11-03 Qbase, LLC Method of automated discovery of new topics
US9547701B2 (en) 2013-12-02 2017-01-17 Qbase, LLC Method of discovering and exploring feature knowledge
US9619571B2 (en) 2013-12-02 2017-04-11 Qbase, LLC Method for searching related entities through entity co-occurrence
US9544361B2 (en) 2013-12-02 2017-01-10 Qbase, LLC Event detection through text analysis using dynamic self evolving/learning module
US9223875B2 (en) 2013-12-02 2015-12-29 Qbase, LLC Real-time distributed in memory search architecture
US9659108B2 (en) 2013-12-02 2017-05-23 Qbase, LLC Pluggable architecture for embedding analytics in clustered in-memory databases
US9542477B2 (en) 2013-12-02 2017-01-10 Qbase, LLC Method of automated discovery of topics relatedness
US9230041B2 (en) 2013-12-02 2016-01-05 Qbase, LLC Search suggestions of related entities based on co-occurrence and/or fuzzy-score matching
US9336280B2 (en) 2013-12-02 2016-05-10 Qbase, LLC Method for entity-driven alerts based on disambiguated features
US9922032B2 (en) 2013-12-02 2018-03-20 Qbase, LLC Featured co-occurrence knowledge base from a corpus of documents
US9424524B2 (en) 2013-12-02 2016-08-23 Qbase, LLC Extracting facts from unstructured text
CN106164890A (zh) 2013-12-02 2016-11-23 丘贝斯有限责任公司 用于消除非结构化文本中的特征的歧义的方法
US9208204B2 (en) 2013-12-02 2015-12-08 Qbase, LLC Search suggestions using fuzzy-score matching and entity co-occurrence
US9317565B2 (en) 2013-12-02 2016-04-19 Qbase, LLC Alerting system based on newly disambiguated features
US9201744B2 (en) * 2013-12-02 2015-12-01 Qbase, LLC Fault tolerant architecture for distributed computing systems
US9348573B2 (en) 2013-12-02 2016-05-24 Qbase, LLC Installation and fault handling in a distributed system utilizing supervisor and dependency manager nodes
US9430547B2 (en) 2013-12-02 2016-08-30 Qbase, LLC Implementation of clustered in-memory database
US9424294B2 (en) 2013-12-02 2016-08-23 Qbase, LLC Method for facet searching and search suggestions
US9025892B1 (en) 2013-12-02 2015-05-05 Qbase, LLC Data record compression with progressive and/or selective decomposition
US9984427B2 (en) 2013-12-02 2018-05-29 Qbase, LLC Data ingestion module for event detection and increased situational awareness
US9355152B2 (en) 2013-12-02 2016-05-31 Qbase, LLC Non-exclusionary search within in-memory databases
US9361317B2 (en) 2014-03-04 2016-06-07 Qbase, LLC Method for entity enrichment of digital content to enable advanced search functionality in content management systems
WO2015147860A1 (en) * 2014-03-28 2015-10-01 Hewlett-Packard Development Company, L.P. Rescheduling a service on a node
US9652336B2 (en) 2015-03-13 2017-05-16 International Business Machines Corporation Resilient programming frameworks for handling failures in parallel programs
US10491708B2 (en) 2015-06-05 2019-11-26 Apple Inc. Context notifications
CN108432219B (zh) * 2016-10-25 2020-09-11 华为技术有限公司 终端设备开机失败的恢复方法和终端设备
TWI635722B (zh) * 2018-01-02 2018-09-11 中華電信股份有限公司 應用網路功能虛擬化叢集技術之備援系統及其方法
US10140184B1 (en) * 2018-03-14 2018-11-27 Capital One Services, Llc Node recovery in static distributed networks
EP3779699A1 (de) * 2019-08-16 2021-02-17 Aptiv Technologies Limited Verfahren zur kontrolle der programmausführung eines mikrosteuergeräts, externe vorrichtung, system und nichttransitorisches computerlesbares medium
US20220197623A1 (en) * 2019-09-12 2022-06-23 Hewlett-Packard Development Company, L.P. Application presence monitoring and reinstillation
EP4063974A1 (de) * 2021-03-23 2022-09-28 ABB Schweiz AG Steuerung eines industriellen prozesses unter verwendung virtualisierter instanzen einer steuerungssoftware
US20230393890A1 (en) * 2022-06-03 2023-12-07 Snap Inc. Auto-recovery for ar wearable devices

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5271013A (en) * 1990-05-09 1993-12-14 Unisys Corporation Fault tolerant computer system
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
US5572709A (en) * 1993-06-18 1996-11-05 Lucent Technologies Inc. Using dynamically-linked libraries to add side effects to operations
US5812748A (en) * 1993-06-23 1998-09-22 Vinca Corporation Method for improving recovery performance from hardware and software errors in a fault-tolerant computer system
US5978565A (en) * 1993-07-20 1999-11-02 Vinca Corporation Method for rapid recovery from a network file server failure including method for operating co-standby servers
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
US5621885A (en) * 1995-06-07 1997-04-15 Tandem Computers, Incorporated System and method for providing a fault tolerant computer program runtime support environment
US5819020A (en) * 1995-10-16 1998-10-06 Network Specialists, Inc. Real time backup system
US5815649A (en) * 1995-10-20 1998-09-29 Stratus Computer, Inc. Distributed fault tolerant digital data storage subsystem for fault tolerant computer system
US5737514A (en) * 1995-11-29 1998-04-07 Texas Micro, Inc. Remote checkpoint memory system and protocol for fault-tolerant computer system
GB9601584D0 (en) * 1996-01-26 1996-03-27 Hewlett Packard Co Fault-tolerant processing method
GB9601585D0 (en) * 1996-01-26 1996-03-27 Hewlett Packard Co Fault-tolerant processing method
GB2311391A (en) * 1996-03-19 1997-09-24 Ibm Restart and recovery of OMG compliant transaction systems
US5822531A (en) * 1996-07-22 1998-10-13 International Business Machines Corporation Method and system for dynamically reconfiguring a cluster of computer systems
KR19980024086A (ko) * 1996-09-03 1998-07-06 니시무로 타이조 컴퓨터 시스템 및 화일 관리 방법
JPH10187638A (ja) * 1996-10-28 1998-07-21 Mitsubishi Electric Corp クラスタ制御システム
US5941999A (en) * 1997-03-31 1999-08-24 Sun Microsystems Method and system for achieving high availability in networked computer systems

Also Published As

Publication number Publication date
EP0974903A3 (de) 2001-06-13
AU752844B2 (en) 2002-10-03
AU4020299A (en) 2000-02-10
EP0974903B1 (de) 2003-05-14
CA2273523A1 (en) 2000-01-20
EP0974903A2 (de) 2000-01-26
CA2273523C (en) 2003-03-18
DE69907818D1 (de) 2003-06-18
US6266781B1 (en) 2001-07-24
KR20000011835A (ko) 2000-02-25
JP2000105754A (ja) 2000-04-11

Similar Documents

Publication Publication Date Title
DE69907818T2 (de) Verfahren und Vorrichtung zur Fehlererkennung und Wiederherstellung mit vorbestimmter Replikationsart für verteilte Anwendungen in einem Netzwerk
DE69907824T2 (de) Verfahren und Vorrichtung zur Fehlererkennung und Wiederherstellung mit vorbestimmtem Replikationsgrad für verteilte Anwendungen in einem Netzwerk
DE10134492B4 (de) Ausfallübernahme des Dateimanagementsystems in einem Rechnercluster
DE69918467T2 (de) Servervorrichtung und Verfahren deren Verwendung
DE60224274T2 (de) Wiederherstellungsrechner für eine mehrzahl von vernetzten rechnern
DE602004005344T2 (de) Verfahren, system und programm zur handhabung eines failover zu einem fernspeicherort
DE60220263T2 (de) Server-duplexverfahren und geduplextes serversystem
DE10124482B4 (de) Fehlertolerante Systemressource mit niedriger Latenzzeit, mit übergeordneter Protokollierung von Systemressourcentransaktionen und serverübergreifend gespiegelter Protokollierung von übergeordneten Systemressourcentransaktionen
DE19836347C2 (de) Fehlertolerantes Computersystem
DE602004002858T2 (de) Vorrichtung und Verfahren zur Datenarchivierung in einem Clustersystem
DE69811148T2 (de) Mitgliedschaft in einem unzuverlässigen verteilten Rechnersystem
DE60016371T2 (de) Vorrichtung und verfahren um die übereinstimmung der daten in einer gruppe von einspiegelungseinrichtungen gespeichert zu behalten
DE69907709T2 (de) Prozessüberwachung in einem rechnersystem
DE10123067B4 (de) Synchrone Vervielfältigung von Transaktionen in einem verteilten System
DE112016001295T5 (de) Neusynchronisieren auf ein erstes Speichersystem durch Spiegeln des ersten Speichersystems nach einem Failover zu einem zweiten Speichersystem
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
EP1844598B1 (de) Verfahren und vorrichtung zur zuordnung von paketadressen einer mehrzahl von einrichtungen
EP1820307B1 (de) Verfahren zum nachweis der verf]gbarkeit von systemkomponenten eines redundanten kommunikationssystems

Legal Events

Date Code Title Description
8364 No opposition during term of opposition