-
Querverweise auf verwandte
Anmeldungen
-
Diese
Anmeldung enthält
einen Erfindungsgegenstand, der sich auf den Erfindungsgegenstand
der folgenden Anmeldungen bezieht, von denen alle demselben Rechtsnachfolger
wie diese Anwendung übertragen
wurden, wobei auf jede von ihnen hiermit in ihrer Gesamtheit Bezug
genommen wird:
- "METHOD,
SYSTEM AND PROGRAM PRODUCTS FOR MANAGING PROCESSING GROUPS OF A
DISTRIBUTED COMPUTING ENVIRONMENT", Novaes et al., Serien-Nr. 09/584259,
eingereicht am 31. Mai 2000.
- "METHOD,
SYSTEM AND PROGRAM PRODUCTS FOR RECOVERING FROM FAILURES WITHIN
A SHARED NOTRING DISTRIBUTED COMPUTING ENVIRONMENT", Novaes et al.,
Serien-Nr. 09/583784, eingereicht am 31. Mai 2000.
- "METHOD,
SYSTEM AND PROGRAM PRODUCTS FOR SERIALIZING REPLICATED TRANSACTIONS
OF A DISTRIBUTED COMPUTING ENVIRONMENT", Novaes et al., Serien-Nr. 09/584481,
eingereicht am 31. Mai 2000; und
- "METHOD,
SYSTEM AND PROGRAM PRODUCTS FOR MANAGING A CLUSTERED COMPUTING ENVIRONMENT", Novaes et al.,
Serien-Nr. 09/583677, eingereicht am 31. Mai 2000.
-
Technisches Gebiet
-
Diese
Erfindung bezieht sich allgemein auf verteilte Systeme und insbesondere
auf die Verwaltung eines verteilten synchronen Transaktionssystems.
-
Vorgeschichte
-
Verteilte
Systeme sind skalierbare Systeme mit hoher Verfügbarkeit, die in verschiedenen
Situationen verwendet werden, einschließlich solcher Situationen,
die einen hohen Arbeitsdurchsatz oder ununterbrochene oder fast
ununterbrochene Verfügbarkeit
des Systems erfordern.
-
Das
US-Patent Nr. 5,924,094 ,
betrifft ein Datenbanksystem, bei dem an einer Vielzahl von Stellen
bestimmte Benutzer an ihren Plätzen
arbeiten können,
um offline ihre lokalen Daten zu bedienen. Sämtliche Transaktionen, die
die Benutzer dort auslösen,
werden auf den lokalen Datenbeständen
durchgeführt.
Ein Datenabgleich findet im Hintergrund statt, insbesondere werden
keine parallelen Transaktionen durchgeführt. Sämtliche, für eine Anwendung benötigten Daten
werden lokal gehalten. Es werden die immer notwendigen Synchronisierungstransaktionen
im Hintergrund durchgeführt,
ohne dass die an den verteilten Datenstationen liegenden Benutzer
etwas davon sehen, wobei nur die geänderten Daten zwischen den
Systemen übermittelt werden
und die nicht geänderten
Daten nicht übermittelt
werden. die Daten werden im Hintergrund durch entsprechende Datenübertragungsvorgänge möglichst
auf einem Stand gehalten, der am ehesten dem aktuellen Stand entspricht.
Dieses Konsistenthalten von Daten geschieht im Hintergrund und unabhängig von
irgendwelchen Transaktionen, die auf den Daten selbst arbeiten.
-
Daher
besteht die Aufgabe der Erfindung darin, ein verteiltes Datensystem
so zu betreiben, dass es insbesondere bei überproportional häufigem Lesezugriff
eine bessere Performance zeigt.
-
Zusammenfassung der Erfindung
-
Die
Unzulänglichkeiten
des Standes der Technik werden überwunden und
zusätzliche
Vorteile werden bereitgestellt, indem ein Verfahren zur Ausführung synchroner
Vervielfältigung
von Transaktionen einer verteilten Rechnerumgebung bereitgestellt
wird. Das Verfahren beinhaltet zum Beispiel das Einleiten einer
Transaktion innerhalb der verteilten Rechnerumgebung durch eine
Instanz einer Client-Anwendung der verteilten Rechnerumgebung; und
das Vervielfältigen
der Transaktion zu mindestens einer anderen Instanz der Client-Anwendung,
wobei das Vorhandensein der anderen Instanz vor der Instanz verborgen
wird, welche die Transaktion einleitete.
-
System
und Computerprogrammprodukte entsprechend den oben zusammengefassten
Verfahren werden hierin ebenfalls beschrieben und beansprucht.
-
Durch
die Techniken der vorliegenden Erfindung werden zusätzliche
Merkmale und Vorteile ausgeführt.
Andere Ausführungsformen
und Aspekte der Erfindung werden hierin im Einzelnen beschrieben
und als Teil der beanspruchten Erfindung betrachtet.
-
Kurze Beschreibung der Zeichnungen
-
Der
Erfindungsgegenstand wird in den Ansprüchen am Ende der Spezifikation
speziell ausgeführt
und deutlich beansprucht. Die vorhergenannten und andere Aufgaben,
Merkmale und Vorteile der Erfindung werden aus der folgenden ausführlichen
Beschreibung in Verbindung mit den beiliegenden Zeichnungen ersichtlich,
in denen:
-
1 ein
Beispiel einer Rechnerumgebung zeigt, die Aspekte der vorliegenden
Erfindung einbezieht und verwendet;
-
2 ein
Beispiel verschiedenen Komponenten von mehreren Netzknoten von 1 gemäß einem Aspekt
der vorliegenden Erfindung zeigt;
-
3 eine
Ausführungsform
einer Rechnerumgebung zeigt, in der eine Client-Anwendungsinstanz auf
eine Anforderung einer Drittanwendung gemäß einem Aspekt der vorliegenden
Erfindung antwortet, ohne einen DSTS-Server zu verwenden;
-
4 eine
Ausführungsform
einer Rechnerumgebung zeigt, in der eine Client-Anwendungsinstanz
einen DSTS-Server verwendet, um auf eine Anforderung der Anwendung
einer dritten Partei gemäß einem
Aspekt der vorliegenden Erfindung zu antworten;
-
5 ein
Beispiel der Verarbeitungsgruppe zeigt, die gemäß einem Aspekt von vorliegenden
Erfindung verwendet wird;
-
6a ein
Beispiel der Komponenten zeigt, die einem Gruppenaktivierungsprotokoll
gemäß einem Aspekt
der vorliegenden Erfindung zugeordnet sind;
-
6b–6d eine
Ausführungsform
der Logik zeigen, der dem Ausführen
der Gruppenaktivierung gemäß einem
Aspekt der vorliegenden Erfindung zugeordnet ist;
-
7 ein
Beispiel der Felder zeigt, die einer Initialisierungsnachricht gemäß einem
Aspekt der vorliegenden Erfindung zugeordnet sind;
-
8 eine
Ausführungsform
der Komponenten zeigt, die einem Gruppenverknüpfungsprotokoll gemäß einem
Aspekt der vorliegenden Erfindung zugeordnet sind;
-
9a–9b eine
Ausführungsform
der Logik zeigen, der dem Verknüpfen
einer Verarbeitungsgruppe gemäß einem
Aspekt der vorliegenden Erfindung zugeordnet ist;
-
10 ein
Beispiel der Felder zeigt, die einer Stilllegungsnachricht gemäß einem
Aspekt der vorliegenden Erfindung zugeordnet sind;
-
11 eine
Ausführungsform
der Felder zeigt, die einer Archivierungsnachricht gemäß einem
Aspekt der vorliegenden Erfindung zugeordnet sind;
-
12 eine
Ausführungsform
der Felder zeigt, die einer Dearchivierungsnachricht gemäß einem
Aspekt der vorliegenden Erfindung zugeordnet sind;
-
13 ein
Beispiel der Felder enthält,
die einer Aufzählungskennzeichennachricht
gemäß einem
Aspekt der vorliegenden Erfindung zugeordnet sind;
-
14 ein
Beispiel der Felder zeigt, die einer Kennzeichenaufzählungsnachricht
gemäß einem
Aspekt der vorliegenden Erfindung zugeordnet sind;
-
15 eine
Ausführungsform
der Logik zeigt, der dem Ausschließen eines Mitglieds von einer
Verarbeitungsgruppe gemäß einem
Aspekt der vorliegenden Erfindung zugeordnet ist;
-
16 ein
Beispiel der Felder zeigt, die einer Quorumhinweisnachricht gemäß einem
Aspekt der vorliegenden Erfindung zugeordnet sind;
-
17 ein
Beispiel der Felder zeigt, die einer Vervielfältigungsanforderungsnachricht
gemäß einem Aspekt
der vorliegenden Erfindung zugeordnet sind;
-
18 ein
Beispiel der Felder zeigt, die einer Vervielfältigungsrückrufnachricht gemäß einem
Aspekt der vorliegenden Erfindung zugeordnet sind;
-
19 ein
Beispiel der Felder zeigt, die einer Vervielfältigungsrückrufergebnisnachricht gemäß einem Aspekt
der vorliegenden Erfindung zugeordnet sind;
-
20 ein
Beispiel der Felder zeigt, die einer Vervielfältigungsabschlussnachricht
gemäß einem
Aspekt der vorliegenden Erfindung zugeordnet sind;
-
21 ein
Beispiel der Felder zeigt, die einer Systemabschaltnachricht gemäß einem
Aspekt der vorliegenden Erfindung zugeordnet sind;
-
22a–22b eine Ausführungsform
des Nachrichtenflusses zeigen, welcher der Verarbeitung einer synchronen
Transaktion gemäß einem
Aspekt der vorliegenden Erfindung zugeordnet ist;
-
23 eine
Ausführungsform
des Nachrichtenflusses zeigt, der einer Vorbereiten-zum-Festschreiben-Operation
gemäß einem
Aspekt der vorliegenden Erfindung zugeordnet ist;
-
24 eine
Ausführungsform
des Nachrichtenflusses zeigt, der einer Festschreibeoperation gemäß einem
Aspekt der vorliegenden Erfindung zugeordnet ist;
-
25 ein
Beispiel einer Momentaufnahme eines verteilten Systems zu einem
bestimmten Zeitpunkt gemäß einem Aspekt
der vorliegenden Erfindung zeigt; und
-
26 eine
Ausführungsform
der Logik zeigt, der einer Wiederherstellungsprozedur gemäß einem Aspekt
der vorliegenden Erfindung zugeordnet ist.
-
Bester Modus zum Ausführen der
Erfindung
-
Gemäß den Aspekten
der vorliegenden Erfindung werden verteilte synchrone Transaktionen
ausgeführt
und verwaltet. Die verteilten synchronen Transaktionen werden von
verteilten Client-Anwendungen
einer verteilten Rechnerumgebung verwendet.
-
Ein
Beispiel einer verteilten Rechnerumgebung, die Aspekte der vorliegenden
Erfindung einbezieht und verwendet, wird in 1 gezeigt
und hierin beschrieben. Eine verteilte Rechnerumgebung 100 enthält zum Beispiel
eine Vielzahl von Rahmen 102, die miteinander über eine
Vielzahl von LAN-Überleitungseinrichtungen 104 verbunden
sind. Die Rahmen 102 und LAN-Überleitungseinrichtungen 104 werden
weiter unten im einzelnen beschrieben.
-
In
einem Beispiel enthält
die verteilte Rechnerumgebung 100 acht (8) Rahmen, von
denen jeder eine Vielzahl von Verarbeitungsnetzknoten 106 enthält. In einem
Beispiel enthält
jeder Rahmen sechzehn (16) Verarbeitungsnetzknoten (wobei jeder
einen oder mehrere Prozessoren aufweist). Jeder Verarbeitungsnetzknoten
ist zum Beispiel ein RISC/6000 Computer unter AIX, einem UNIX-basierten
Betriebssystem. Jeder Verarbeitungsnetzknoten innerhalb eines Rahmens
ist mit den anderen Verarbeitungsnetzknoten des Rahmens beispielsweise über eine
interne LAN-Verbindung verbunden. Zusätzlich wird jeder Rahmen über die
LAN-Überleitungseinrichtungen 104 mit
den anderen Rahmen verbunden.
-
Beispielsweise
enthält
jedes LAN-Überleitungseinrichtungen 104 entweder
einen RISC/6000-Computer, irgendeine Computernetzwerkverknüpfung zum
LAN oder ein Netzleitwegprogramm. Dies sind jedoch nur Beispiele.
Es wird für
den Fachmann ersichtlich sein, dass es andere Typen von LAN-Überleitungseinrichtungen gibt
und dass auch andere Mechanismen verwendet werden können, um
die Rahmen miteinander zu verknüpfen.
-
Die
verteilte Rechnerumgebung von 1 ist nur
ein Beispiel. Es ist möglich,
mehr oder weniger als acht Rahmen oder mehr oder weniger als sechzehn
Netzknoten pro Rahmen zu haben. Weiterhin müssen die Verarbeitungsnetzknoten
keine RISC/6000-Computer unter AIX sein. Einige oder alle der Verarbeitungsnetzknoten
können
andere Typen von Computern und/oder andere Betriebssysteme enthalten.
Weiterhin kann eine heterogene Umgebung die Erfindung einschließen und
verwenden, in der ein oder mehrere der Netzknoten und/oder Betriebssysteme
der Umgebung von anderen Netzknoten oder Betriebssystemen der Umgebung verschieden
sind. Die Netzknoten einer derartigen heterogenen Umgebung arbeiten
zusammen, indem sie zusammenwirken und Ressourcen gemeinsam benutzen,
wie hierin beschrieben.
-
Weitere
Einzelheiten hinsichtlich der Netzknoten einer verteilten Computerumgebung
werden mit Bezug auf 2 beschrieben. In einem Beispiel
wird eine verteilte Client-Anwendung 200 auf
einer Vielzahl von Netzknoten 202 ausgeführt. Insbesondere
wird eine Instanz der Client-Anwendung weitgehend gleichzeitig auf jedem
der Vielzahl von Netzknoten ausgeführt, die in diesem speziellen
Beispiel drei Netzknoten enthält.
(Der Fachmann wird erkennen, dass die Client-Anwendung auf irgendeiner
Anzahl von Netzknoten der Umgebung einschließlich nur eines Netzknotens
ausgeführt
werden kann.)
-
In
einer Ausführungsform
werden die Client-Anwendungsinstanzen mit einem verteilten synchronen Transaktionssystem
(distributed synchronous transaction system, DSTS) verbunden, das
die Anwendungsinstanzen gemäß einem
Aspekt der vorliegenden Erfindung aktiviert, um an der synchronen
Vervielfältigung
von Transaktionen teilzunehmen. Durch Verwenden des verteilten synchronen
Transaktionssystems kann eine Client-Instanz an der synchronen Vervielfältigung
von Transaktionen teilnehmen, sogar wenn die Client-Anwendungsinstanz
kein direktes Wissen über
irgendwelche anderen Instanzen der Anwendung hat. Das verteilte synchrone
Transaktionssystem enthält
eine oder mehrere DSTS-Instanzen
(z.B. Computerprogramme) 204, die auf einem oder mehreren
Netzknoten ausgeführt
werden. In einem Beispiel wird eine DSTS-Instanz auf jedem Netzknoten
ausgeführt,
der eine Client-Anwendungsinstanz hat, die daran interessiert ist,
an einer verteilten Transaktion teilzunehmen. Jede DSTS-Instanz
wird mit einer oder mehreren Instanzen von einer oder mehreren Client-Anwendungen
verbunden.
-
Wenn
die DSTS-Instanz in den Speicher eines Netzknotens geladen und ausgeführt wird,
wird sie als ein Serverprozess wahrgenommen, der seinem entsprechenden
Client-Anwendungsprozess (oder Prozessen) dient. Das DSTS-System
führt eine
verteilte synchrone Transaktion im Namen einer Client-Anwendung aus.
Wenn die Transaktion durch den Client angefordert wird, wird sie
im Wesentlichen sofort durch einen DSTS-Server eingeleitet. Weiterhin
wird der Client nach Abschluss der Transaktion im Wesentlichen sofort über das
Ergebnis (z.B. Erfolg, Fehler) der Transaktion benachrichtigt.
-
Eine
Sammlung einer oder mehrerer Client-Anwendungsinstanzen, die an
der Ausführung
einer verteilten synchronen Transaktion teilnehmen, wird als eine
vervielfältigte
Gruppe von Client- Anwendungsinstanzen
bezeichnet. Diese Gruppe unterscheidet sich von anderen Formen von
Gruppen in einem verteilten System, da die Mitglieder der vervielfältigten
Gruppe kein direktes Wissen voneinander haben. Stattdessen wird die
Gruppe implizit gebildet, wenn eine Client-Anwendungsinstanz einen
Fluss von Aktualisierungsoperationen umleitet, um an einer anderen
Client-Anwendungsinstanz
oder mehreren anderen Client-Anwendungsinstanzen
vervielfältigt
zu werden.
-
Insbesondere
leitet die Client-Anwendung den Fluss von Operationen um, die ihren
permanenten (gespeicherten) oder Laufzeit- (nicht gespeicherten)
Status modifizieren. Diese Aktualisierungsoperationen werden als
Schreiboperationen klassifiziert. Irgendeine andere Transaktion,
die den Status der Client-Anwendung nicht modifiziert, kann als
eine Abfrage- oder Lesetransaktion bezeichnet werden. Gemäß einem
Aspekt der vorliegenden Erfindung führen Client-Anwendungen Schreiboperationen
als verteilte synchrone Transaktionen aus, die jeder Kopie der Client-Anwendung
einen konsistenten oder identischen Status liefern. Eine derartige Fähigkeit
macht es wiederum möglich,
für irgendeine
Kopie der Anwendung auf Abfragen (Leseoperationen) zu ihrem Status
zu antworten, ohne die Abfrage an irgendeine der anderen Nachbildungen
umleiten zu müssen.
Anders gesagt, Client-Anwendungen können Leseoperationen lokal
bedienen, ohne einen DSTS-Server zu verwenden (siehe 3),
während
Schreiboperationen an andere Instanzen der Client-Anwendung vervielfältigt werden
und somit das DSTS verwenden (siehe 4), wie
unten in weiteren Einzelheiten beschrieben wird. Diese Architektur
ist optimal für
leseintensive Systeme und Systeme, die eine niedrige Rate von Schreiboperationen
zeigen, jedoch nicht auf diese beschränkt.
-
Der
Fluss von Aktualisierungsoperationen wird durch eine Client- Anwendung zum Beispiel über ein DSTS
Protokoll umgeleitet, das von der Client-Anwendung verwendet wird.
Ein Merkmal dieses Protokolls enthält gemäß einem Aspekt der vorliegenden
Erfindung die Mitgliedschaft in einer oder mehreren Verarbeitungsgruppen.
Eine Verarbeitungsgruppe 500 (5) enthält ein oder
mehrere Mitglieder 502. In diesem Beispiel ist jedes Mitglied
ein DSTS-Server.
So gibt es für
jede Client-Anwendungsinstanz einer vervielfältigten Gruppe einen entsprechenden
DSTS-Server in einer gegebenen Verarbeitungsgruppe (auch bekannt
als eine Gruppe). Wenn zum Beispiel eine vervielfältigte Gruppe
Client-Anwendungsinstanzen
A und B enthält,
dann enthält eine
Verarbeitungsgruppe DSTS-Server A und B, die mit den Anwendungsinstanzen
A beziehungsweise B verbunden sind. Dies gestattet der Verarbeitungsgruppe,
die Vervielfältigung
von Transaktionen für
die Client-Anwendungen der vervielfältigten Gruppe zu bearbeiten
und ermöglicht,
dass die Vervielfältigung
jenen Client-Anwendungen transparent wird.
-
Jedem
Mitglied einer Verarbeitungsgruppe wird eine konsistente Sicht der
Gruppenstatusdaten gesichert. Die Daten werden konsistent gehalten,
da sie nur durch gutdefinierte Gruppenprotokolle aktualisiert werden.
Beispiele der Protokolle enthalten Aufnahme in eine Gruppe, einschließlich Aktivierung
der Gruppe und Verknüpfen
der Gruppe, und Ausschluss von der Gruppe, die alle weiter unten
detailliert beschrieben werden. Weitere Einzelheiten hinsichtlich
der Verwaltung einer Verarbeitungsgruppe werden in der
US-Patentschrift No. 5 748 958 mit
dem Titel "System
For Utilizing Batch Requests To Present Membership Changes To Process
Groups" besprochen,
veröffentlicht
am 5. Mai 1998, auf die hiermit in ihrer Gesamtheit Bezug genommen wird.
-
Eine
Ausführungsform
der Logik, die dem Eintritt in eine Gruppe zugeordnet ist, wird
mit Bezug auf die 6a–6d beschrieben.
Insbesondere zeigt 6a ein Beispiel der Komponenten,
die am Aktivieren einer Gruppe beteiligt sind; und 6b–6d zeigen
eine Ausführungsform
der Logik. Im anfänglichen
Fall der Gruppenaktivierung gibt es keine Mitglieder in der Verarbeitungsgruppe.
Es wird angenommen, dass die Gruppe vorher definiert wurde, aber
keine der Kopien (d.h. DSTS) der Gruppe zur Zeit ausgeführt wird.
Die Ausführung
einer DSTS-Kopie beginnt, wenn sie mit einer Client-Anwendung verbunden
wird.
-
In
einem Beispiel verbindet eine Client-Anwendung 602 einen
DSTS-Server 604 über
eine Initialisierungsnachricht, SCHRITT 600 (6a, 6b).
Die Initialisierungsnachricht wird von der Client-Anwendungsinstanz 602 an
den DSTS-Server 604 gesendet, um ihn mit dem DSTS-System
zu verbinden. Insbesondere verbindet sich in einem Beispiel die
Client-Anwendungsinstanz mit dem DSTS-Server auf demselben Netzknoten
wie die Client-Anwendungsinstanz.
Ein Beispiel der Initialisierungsnachricht wird mit Bezug auf 7 beschrieben.
-
Eine
Initialisierungsnachricht 700 enthält zum Beispiel einen Operationscode 702,
der den Typ der Operation kennzeichnet (z.B. Initialisieren), die
angefordert wurde, und einen Namen 704 der Client-Anwendung,
welche die Anforderung absetzt. Das DSTS-System verwendet den Anwendungsnamen,
um Transaktionen an die anderen Instanzen der Anwendung (d.h. die
Mitglieder der vervielfältigten
Gruppe) mit demselben Namen weiterzuleiten.
-
Es
wird nochmals auf 6a–6b Bezug
genommen, als Antwort auf diese Nachricht schlägt der DSTS-Server vor, in
eine Gruppe einzutreten (gekennzeichnet durch Anwendungsname 704 (7), SCHRITT 606 (6b)).
Wenn er vorschlägt,
in die Gruppe einzutreten, liest der DSTS-Server den Gruppenstatus
vom permanenten Speicher 608 (6a). Der
Gruppenstatus 610 enthält
zum Beispiel die Gruppenfolgenummer und den Aktivierungsstatus.
Wenn der Gruppenstatus aktiv ist, ABFRAGE 612 (6b),
führt die eintretende
Kopie ein Eintrittsprotokoll aus, SCHRITT 614, wie unten
beschrieben. Anderenfalls ist der Status inaktiv, und die Kopie
kann der Gruppe sofort beitreten, ohne das unten definierte Eintrittsprotokoll
auszuführen,
SCHRITT 616.
-
Wenn
der DSTS-Server in die Gruppe eintritt, vergleicht die Kopie die
Gruppenreihenfolgenummer mit ihrer eigenen Reihenfolgenummer, SCHRITT 618.
Wenn die Gruppenreihenfolgenummer kleiner als ihre eigene ist, aktualisiert
die Kopie die Gruppenreihenfolgenummer, SCHRITT 620. Danach,
oder wenn die Gruppenreihenfolgenummer gleich oder größer als
die Reihenfolgenummer der Kopie ist, erfolgt eine Feststellung,
ob (in diesem Beispiel) ein Quorum von Mitgliedern erreicht wurde,
ABFRAGE 622.
-
Wenn
kein Quorum erreicht wurde, fährt
die Verarbeitung mit SCHRITT 600 für ein anderes Mitglied fort,
bis mindestens ein Quorum erreicht wird. Da ein Quorum von Mitgliedern
der Gruppe beitritt, wissen die Kopien, die Mitglieder der Verarbeitungsgruppe
sind, dass das Quorum erreicht wurde. An diesem Punkt wird die Gruppenreihenfolgenummer
auf den höchsten
Mitgliederbestand gesetzt, SCHRITT 624. Die Mitglieder, deren
Reihenfolgenummer mit der der Gruppe übereinstimmt, wenn dieser Punkt
erreicht wird, leiten ein Aktivierungsprotokoll durch Senden einer
Gruppenaktivierungsnachricht ein, SCHRITT 626. Die Gruppenaktivierungsnachricht
leitet ein Mehrphasenprotokoll ein.
-
In
der ersten Phase der Aktivierung empfangen die Mitglieder der Gruppe
die Gruppenaktivierungsnachricht, welche die Knotenadresse des Mitglieds
enthält,
das die Nachricht gesendet hat, SCHRITT 628 (6c).
Dann bitten die Mitglieder der aktuellen Gruppe, deren Reihenfolgenummern
kleiner als die Reihenfolgenummer der aktuellen Gruppe sind, den
Absender der Aktivierungsnachricht um eine Kopie des Gruppenstatus,
die der Reihenfolgenummer der Gruppe zugeordnet ist, SCHRITT 630.
Diese Mitglieder initialisieren sich selbst erneut unter Verwendung
des neuen Gruppenstatus, SCHRITT 632, und schlagen dann
vor, mit der zweiten Phase der Gruppenaktivierung fortzufahren,
SCHRITT 634. Ein Mitglied, dessen Initialisierung scheitert,
stimmt an diesem Punkt für
den Abbruch des Protokolls.
-
Die
Mitglieder, deren Reihenfolgenummern mit denen der Gruppe übereinstimmen,
schlagen auch vor, zur zweiten Phase zu gehen. Wenn alle aktuellen
Mitglieder vorschlagen, zur zweiten Phase zu gehen (keine Abbrüche), beginnt
die zweite Phase.
-
Wenn
die erste Phase der Gruppenaktivierung endet, prüfen die aktuellen Mitglieder
der Verarbeitungsgruppe, ob eine Mehrzahl der Mitglieder aufrechterhalten
wurde, SCHRITT 636 (6d).
Weiterhin hat nun jedes Mitglied dieselbe konsistente Reihenfolgenummer
und Kopie des verteilten Status.
-
Die
Mitglieder ändern
jetzt die Gruppenreihenfolgenummer, indem sie z.B. 1 dazuaddieren,
SCHRITT 638. Die Mitglieder speichern dann die neue Reihenfolgenummer
im Gruppenstatus und schlagen vor, das Protokoll zu schließen, SCHRITT 640.
Ein Mitglied, das auf dieser Stufe scheitert, schlägt vor,
das Protokoll abzubrechen.
-
Wenn
bei Protokollabschluss kein aktuelles Mitglied abgebrochen hat,
ABFRAGE 642, hat die Gruppe die Garantie, dass die aktuellen
Mitglieder der Gruppe denselben konsistenten Gruppenstatus und Reihenfolgenummer
haben und dass die neue Reihenfolgenummer von einer Mehrzahl der
Mitglieder der Gruppe gespeichert wurde. Der Gruppenstatus wird
dann zu aktiv geändert,
SCHRITT 644.
-
Jedesmal,
wenn ein Mitglied einer aktiven Gruppe beitritt, leitet es ein Mehrphasengruppeneintrittsprotokoll
ein, wovon eine Ausführungsform
mit Bezug auf die 8 und 9a–9b beschrieben
wird. Insbesondere zeigt 8 die Komponenten des Beitrittsprozesses,
während
die 9a–9b eine
Ausführungsform
der Logik zeigen. In der ersten Phase des Protokolls sendet das
eintretende Mitglied (800 von 8) eine Eintrittsvorschlagsnachricht
mit der Reihenfolgenummer, die es aus dem permanenten Speicher abgerufen hat,
oder negativ Unendlich, wenn es nicht in der Lage war, die Reihenfolgenummer
abzurufen, SCHRITT 900 (9a). Beispielsweise
können
sowohl die Reihenfolgenummer als auch andere Gruppenstatus nicht
verfügbar
sein, wenn die Platte, auf welcher der Status gespeichert wurde,
zerstört
oder anderweitig nicht verfügbar ist
oder wenn die Kopie des Mitglieds unter irgendeinem bestimmtem Prozessor
tatsächlich
erstmalig ausgeführt
wird.
-
Als
Antwort auf das Empfangen der Eintrittsvorschlagsnachricht unterbrechen
die anderen Mitglieder der Gruppe (802, 8)
Aktualisierungen auf den verteilten Daten, SCHRITT 902.
In einer Ausführungsform sendet
jedes Mitglied der Gruppe seiner entsprechenden Client-Anwendungsinstanz
eine Stilllegungsnachricht, um die Aktualisierungen einzustellen.
Ein Beispiel für
die Stilllegungsnachricht wird mit Bezug auf 10 beschrieben.
-
Eine
Stilllegungsnachricht 1000 enthält zum Beispiel einen Operationscode 1002,
der kennzeichnet, dass dies eine Stilllegungsoperation ist. Die
Stilllegungsnachricht fordert die Client-Anwendungen auf, das Senden
von Aktualisierungsanforderungen zu beenden (z.B. Vervielfältigungsanforderungsnachrichten,
wie unten beschrieben), so dass der globale Status der Anwendung
stabilisiert wird.
-
Danach
wird jede Kopie der Anwendung aufgefordert, eine Momentaufnahme
des aktuellen Status der Anwendung zu erzeugen und diesen Status
im permanenten Speicher zu speichern, SCHRITT 904. Diese
Anforderung wird durch Senden einer Archivnachricht an die Kopien
der Anwendung ausgeführt.
Ein Beispiel einer Archivnachricht wird mit Bezug auf 11 beschrieben.
In einem Beispiel enthält
eine Archivnachricht 1100 einen Operationscode 1102,
der kennzeichnet, dass dies eine Archivanforderung ist.
-
Alle
Mitglieder empfangen eine Kopie des Eintrittsvorschlags, einschließlich des
eintretenden Mitglieds. Das eintretende Mitglied vergleicht dann
die Reihenfolgenummer des Vorschlags mit der derzeitigen Gruppenmitgliedschaft
oder negativ Unendlich, wenn keine anderen Mitglieder Teil der Gruppe
sind, ABFRAGE 906. Wenn die Reihenfolgenummer des eintretenden
Mitglieds kleiner als die Reihenfolgenummer der Gruppe ist, erfolgt
eine Feststellung, ob die Gruppe aktiv ist, ABFRAGE 908.
In einem Beispiel erfolgt diese Feststellung durch Prüfen des
Aktivierungsstatus im Gruppenstatus (804, 8).
-
Wenn
die Gruppe noch aktiv ist, stellt das eintretende Mitglied Kontakt
zu einem der Mitglieder her, das die größere Reihenfolgenummer hat,
und fragt den permanenten Status des verteilten Systems von dem
Netzknoten dieses Mitglieds ab und verschiebt ihn zum Anwendungsspeicherbereich,
SCHRITT 910. Insbesondere in einem Beispiel verwendet das
DSTS-System eine Dearchivierungsnachricht, um die Momentaufnahme
vom Speicher abzurufen und die überholte
Kopie der Anwendung aufzufordern, die zuletzt aktualisierte Momentaufnahme
zu laden.
-
Ein
Beispiel der Dearchivierungsnachricht wird mit Bezug auf 12 beschrieben.
Eine Dearchivierungsnachricht 1200 enthält einen Operationscode 1202,
der kennzeichnet, dass dies eine Dearchivierungsnachricht ist, und
ein Archivpositionsfeld 1204, das zeigt, von wo die Daten
abgerufen werden sollen.
-
Zusätzlich zum
Absetzen der Dearchivierungsnachricht setzt der DSTS-Server auch
eine Aufzählungskennzeichennachricht
ab, die zum Beispiel sofort ausgeführt wird, nachdem die Client-Anwendung eine Momentaufnahme
des permanenten Status lädt.
Eine Aufzählungskennzeichennachricht 1300 (13)
enthält
zum Beispiel einen Operationscode 1302, der anzeigt, dass
dies eine Aufzählungskennzeichennachricht ist.
Nach Empfang dieser Nachricht sendet die Client-Anwendung dem DSTS-System
eine Kennzeichenaufzählungsnachricht
zurück,
welche die Namen der Ressourcen, welche die Anwendung erzeugt hat,
den Ressourcenkennzeichen zuordnet.
-
Ein
Beispiel der Kennzeichenaufzählungsnachricht
wird mit Bezug auf 14 beschrieben und enthält zum Beispiel
einen Operationscode 1402, der kennzeichnet, dass dies
die Kennzeichenaufzählungsnachricht ist,
und eine Ressourcenkennzeichenzuordnung 1404, die ein oder
mehrere Paare von Ressourcennamen und Kennzeichen enthält. Diese
Kennzeichen sind eindeutige Namen, die zum Beispiel verwendet werden,
um Anwendungen von dritten Parteien über Änderungen des Status der Client-Anwendung
zu benachrichtigen und gleichzeitige Aktualisierungsanforderungen
an dieselben Ressourcen zu serialisieren, wie unten beschrieben.
-
Nach
erfolgreichem Neuinitialisieren ihrer selbst durch Laden der Momentaufnahme
wird der neuen Kopie gestattet, am DSTS-System teilzunehmen, und es wird eine
Zusammenfassungsnachricht an alle Kopien gesendet, so dass das DSTS-System
seinen normalen Betrieb wiederaufnehmen kann. Weiterhin schlägt die neue
Kopie vor, die zweite Phase des Eintretens zu beginnen, SCHRITT 912.
-
Es
wird auf ABFRAGE 908 Bezug genommen, wenn die Gruppe inaktiv
wird, bemerkt das eintretende Mitglied die Tatsache, dass seine
Reihenfolgenummer überholt
ist, SCHRITT 916, und wartet auf eine Aktivierungsnachricht
für weitere
Aktionen, SCHRITT 918. Das eintretende Mitglied nimmt an
dieser zweiten Phase der Verknüpfung
nicht teil.
-
Es
wird auf ABFRAGE 906 Bezug genommen, wenn die Reihenfolgenummer
des eintretenden Mitglieds gleich der Reihenfolgenummer der Gruppe
ist, ist die Gruppe inaktiv. Diese Tatsache ist aufgrund des Gruppenaktivierungsprotokolls
(z.B. in diesem Beispiel eine Quorum-Politik) und durch die Eigenschaft
der Quorum-Durchsetzung gegeben. So wartet das eintretende Mitglied,
dass sich eine Aktivierungsnachricht auswirkt, SCHRITT 918,
und es gibt keine zweite Eintrittsphase. Ähnlich folgt auch, wenn die
Reihenfolgenummer des eintretenden Mitglieds größer ist, ABFRAGE 906,
dass die Gruppe inaktiv ist, und so wartet das eintretende Mitglied
auf eine Aktivierungsnachricht, SCHRITT 918.
-
Wenn
das eintretende Mitglied vorgeschlagen hat, zur zweiten Phase überzugehen,
hat es die neue Reihenfolgenummer und den verteilten Status. So ändern nun
die Mitglieder (einschließlich
des eintretenden Mitglieds) die Gruppenreihenfolgenummer, indem
sie zum Beispiel eins addieren, SCHRITT 922 (9b).
Die Mitglieder speichern dann die neue Reihenfolgenummer und den Gruppenstatus,
SCHRITT 924, und schlagen weiterhin vor, das Protokoll
zu schließen,
SCHRITT 926. Irgendein Mitglied, das auf dieser Ebene scheitert, schlägt vor,
das Protokoll abzubrechen. Wenn kein Mitglied abbricht, wird der
Gruppe garantiert, dass die aktuellen Mitglieder der Gruppe denselben
konsistenten Gruppenstatus und Reihenfolgenummer haben und dass
die neue Reihenfolgenummer für
eine Mehrzahl von Mitgliedern der Gruppe gespeichert wurde.
-
Zusätzlich zu
Obengenanntem kann ein Mitglied aus einer Gruppe ausgeschlossen
werden. Insbesondere bemerken die verbleibenden Mitglieder der Gruppe
jedesmal, wenn ein Knoten oder die DSTS-Kopie, die auf dem Netzknoten ausgeführt wird,
scheitert, dass ein Mitglied gescheitert ist, SCHRITT 1500 (15). Wenn
die Gruppe inaktiv ist, ABFRAGE 1502, wird keine Aktion
ausgeführt,
SCHRITT 1504. Wenn weiterhin die Gruppe aktiv ist, aber
keine Mehrzahl von Mitgliedern hat, ABFRAGE 1506, wird
keine Aktion ausgeführt.
-
Wenn
die Gruppe jedoch aktiv ist und die Mehrheit behält, ABFRAGE 1506,
stoppt jedes Mitglied alle weiteren Aktualisierungen am verteilten
Status, SCHRITT 1507. Zusätzlich ändert jedes Mitglied die Gruppereihenfolgenummer,
beispielsweise durch Addieren von 1, SCHRITT 1508, und
lädt die
neue Reihenfolgenummer und den Gruppenstatus, SCHRITT 1510.
Dann schlagen die Mitglieder vor, das Protokoll zu schließen, SCHRITT 1512.
Jedes Mitglied, das auf dieser Stufe scheitert, schlägt vor,
das Protokoll abzubrechen.
-
Wenn
kein Mitglied abbricht, hat die Gruppe eine Garantie, dass die aktuellen
Mitglieder der Gruppe denselben konsistenten Gruppenstatus und Reihenfolgenummer
haben, und dass die neue Reihenfolgenummer durch eine Mehrzahl von
Mitgliedern der Gruppe gespeichert wurde.
-
Das
DSTS-System benachrichtigt die Client-Anwendungsinstanzen, wenn
ein Quorum (Mehrzahl) von DSTS-Servern verfügbar ist oder verloren wurde,
beispielsweise durch Verwenden einer Quorumhinweisnachricht. In
einem Beispiel enthält
eine Quorumhinweisnachricht 1600 (16) einen
Operationscode 1602, und die Quoruminformation 1604 zeigt
an, ob die Gruppe ein Quorum hat.
-
Wie
hier beschrieben, werden Mitglieder einer Verarbeitungsgruppe verwendet,
um verteilte synchrone Transaktionen zu vervielfältigen, die durch Client-Anwendungsinstanzen
eingeleitet werden, die mit den Mitgliedern der Gruppe verbunden
sind. Um die Übertragung
zwischen den Client-Instanzen und den Server-Mitgliedern der Gruppe
zu unterstützen,
werden verschiedene Nachrichten verwendet. In einem Beispiel enthalten
diese Nachrichten (zusätzlich
zu den oben beschriebenen Nachrichten) eine Vervielfältigungsanforderungsnachricht,
eine Vervielfältigungsrückrufnachricht,
eine Vervielfältigungsrückrufergebnisnachricht,
eine Vervielfältigungsabschlussnachricht
und eine Systemabschlussnachricht, die alle weiter unten beschrieben werden.
-
Ein
Beispiel einer Vervielfältigungsanforderungsnachricht
wird mit Bezug auf 17 beschrieben. Eine Vervielfältigungsanforderungsnachricht 1700 ist
eine Nachricht, welche die verteilte Transaktion einleitet. In einem
Beispiel enthält
sie einen Operationscode 1702, der zeigt, dass dies eine
Vervielfältigungsanforderungsnachricht
ist; eine Liste der neuen Ressourcennamen 1704, die erzeugt
werden, wenn vorhanden; eine exklusive Zugriffsgruppe 1706,
die null oder mehr exklusive Ressourcen der Client-Anwendung kennzeichnet; eine
gemeinsam verwendete Zugriffsgruppe 1708, die null oder
mehr gemeinsam verwendete Ressourcen der Client-Anwendung kennzeichnet;
eine Vervielfältigungsstrategie 1710,
die Regeln bereitstellt, die während
der Vervielfältigung
einzuhalten sind (z.B. ein Quorum der Gruppe, das zum Fortfahren
mit bestimmten Aufgaben notwendig ist); eine Anforderung 1712,
welche die zu vervielfältigende
und auszuführende
Transaktion (z.B. eine Erzeugungs- oder Aktualisierungsanforderung)
kennzeichnet; und eine Anforderungsgröße 1714, welche die
Größe der Anforderung
kennzeichnet.
-
Die
Vervielfältigungsanforderungsnachricht
wird durch eine einzelne Client-Anwendungsinstanz (auch bekannt
als der Initiator) an einen Serverprozess des DSTS-Systems gesendet.
Bei Empfang der Nachricht (oder irgendwann danach) verteilt der
Serverprozess die Nachricht an einen oder mehrere andere Serverprozesse
der verteilten Rechnerumgebung. Insbesondere wird er in einem Beispiel
an alle anderen aktuellen Serverprozesse der Verarbeitungsgruppe
gesendet.
-
Als
Antwort sendet jeder der Serverprozesse eine Vervielfältigungsrückrufnachricht
an die entsprechenden Instanzen (Gleichartige) der Client-Anwendung.
Ein Beispiel einer Vervielfältigungsrückrufnachricht wird
mit Bezug auf 18 beschrieben. Eine Vervielfältigungsrückrufnachricht 1800 enthält zum Beispiel
einen Operationscode 1802, der kennzeichnet, dass dies
eine Vervielfältigungsrückrufnachricht
ist; ein Feld der neuen Ressourcennamen 1804, falls irgendwelche
zu erzeugen sind; eine exklusive Zugriffsgruppe 1806, die null
oder mehr exklusive Ressourcen der Client-Anwendung kennzeichnet;
eine gemeinsam genutzte Zugriffsgruppe 1808, die null oder
mehr gemeinsam verwendete Ressourcen der Client-Anwendung kennzeichnet; eine Anforderung 1810,
welche die zu vervielfältigende
und auszuführende
Transaktion kennzeichnet; und eine Anforderungsgröße 1812,
welche die Größe der Anforderung
kennzeichnet.
-
Zusätzlich zu
Obengenanntem wird eine Vervielfältigungsrückrufergebnisnachricht
von der Client-Anwendung
an den DSTS-Server gesendet, nachdem die angeforderte Transaktion
bearbeitet wurde. Ein Beispiel einer Vervielfältigungsrückrufergebnisnachricht wird
mit Bezug auf 19 beschrieben. Eine Vervielfältigungsrückrufergebnisnachricht 1900 enthält einen
Operationscode 1902, der kennzeichnet, dass dies eine Vervielfältigungsrückrufergebnisnachricht
ist; ein Feld der neuen Ressourcennamen 1904, falls vorhanden,
zusammen mit ihren Kennzeichen (z.B. eindeutigen Bezeichnern); einer
modifizierten Ressourcengruppe 1906, einschließlich der
Kennzeichen irgendwelcher modifizierter Ressourcen; und eine Gruppe
gelöschter
Ressourcen 1908, einschließlich der Kennzeichen irgendwelcher
gelöschter
Ressourcen.
-
Nachdem
die Serverprozesse die Vervielfältigungsrückrufergebnisse
empfangen, prüfen
sie, ob die Transaktion abgeschlossen wurde, indem sie eine Vervielfältigungsabschlussnachricht 2000 (20)
weiterleiten. In einem Beispiel enthält eine Vervielfältigungabschlussnachricht 2000 einen
Operationscode 2002, der kennzeichnet, dass dies eine Vervielfältigungsabschlussnachricht
ist; und einen Operationsstatus 2004, der kennzeichnet,
ob die Transaktion erfolgreich ausgeführt wurde.
-
Sollte
das System heruntergefahren werden, verwendet das DSTS-System eine Systemabschaltnachricht,
welche die Kopien der Client-Anwendung benachrichtigt, dass das
System im Begriff ist, heruntergefahren zu werden. In einem Beispiel
enthält
eine Abschaltnachricht 2100 (21) einen
Operationscode 2102, der kennzeichnet, dass das Herunterfahren
ausgeführt
werden soll. Diese Nachricht hat das Ziel, den Kopien der Client-Anwendung
zu gestatten, eine elegante Abschlussprozedur auszuführen, wobei
irgendwelche ausstehenden Transaktionen beendet werden. Wenn die
Client-Anwendungen den Systemabschaltprozess beenden, antworten
sie mit einer Systemabschaltbestätigung
an das DSTS-System.
-
Die
Verwendung der oben beschriebenen Vervielfältigungsnachrichten wird unten
mit Bezug auf 22a und 22b weiter
beschrieben. Es wird auf 22a Bezug
genommen, dort wird eine Vervielfältigungsanforderungsnachricht 2200 durch
eine einzelne Client-Anwendungsinstanz 2202 an einen Serverprozess 2204 des
DSTS-Systems gesendet. Der Server verteilt dann, 2206,
die Vervielfältigungsanforderungsnachricht
an die anderen Server 2208a, 2208b der Verarbeitungsgruppe.
In diesem Beispiel sendet dann jeder der Server eine Vervielfältigungsrückrufnachricht 2210 an
seine entsprechende Instanz der Client-Anwendung. Zum Beispiel sendet
Server 2204 die Vervielfältigungsrückrufnachricht 2210 an
die in Netzknoten 1 befindliche Client-Anwendungsinstanz. Ähnlich sendet
Server 2208a eine Vervielfältigungsrückrufnachricht an die in Netzknoten
2 befindliche Client-Anwendungsinstanz usw.
-
Danach
verarbeitet jede Kopie der Client-Anwendung 2202 (22b) die angeforderte Transaktion, schreibt den
Rückruf
fest und sendet eine Vervielfältigungsrückrufergebnisnachricht 2212 an
ihren entsprechenden Server. Eine Kopie der Rückrufergebnisnachricht wird
dann von den Servern der Clients, die nicht Initiatoren sind (z.B. 2208a, 2208b),
an den Server des Anforderungs-Initiators weitergeleitet (z.B. 2208).
-
Danach
prüft der
DSTS-Server des Anforderungs-Initiators (z.B. Server 2208),
ob die Transaktion von einer Mehrheit von Kopien der Anwendung abgeschlossen
wurde. Eine Mehrheit wird definiert als der ganzzahlige Quotient
der Anzahl der Server durch zwei, Vernachlässigen des Dezimalteils und
Addieren von eins zum Ergebnis. Zum Beispiel ist die Mehrheit von
drei Client-Instanzen
3/2 + 1, d.h. 2. Wenn die Mehrheit der Client-Anwendungen beim Ausführen der
Transaktion erfolgreich ist, wird die Transaktion festgeschrieben, und
eine Vervielfältigungsabschlussnachricht
wird von Server 2208 an seine entsprechende Anwendungsinstanz
weitergeleitet. Anderenfalls wird die Transaktion abgebrochen. Der
Abschluss der Transaktion durch eine Mehrheit von Kopien der Anwendung
stellt die Permanenz der Operation sicher. Irgendeine Kopie der
Anwendung, die nicht in der Lage ist, eine Transaktion auszuführen, wird
von der DSTS-Gruppe ausgeschlossen, wie oben beschrieben.
-
Gemäß einem
Aspekt der vorliegenden Erfindung werden die vervielfältigten
verteilten Transaktionen unter Verwendung eines Zweiphasenfestschreibeprotokolls
festgeschrieben. Weiterhin wird, wenn eine Transaktion durch eine
Kopie des Servers festgeschrieben wird, sie auch durch die anderen
Kopien der Verarbeitungsgruppe festgeschrieben.
-
Jede
synchrone vervielfältigte
Transaktion wird einer Gruppe von Zeichen (Kennzeichen) zugeordnet, für die entweder
exklusiver oder gemeinsamer Zugriff während der Verarbeitung der
Transaktion angefordert wird. Obwohl die Transaktionen nicht erfordern,
dass vor der Einleitung irgendwelche Sperren bezüglich der Zugriffszeichen erhalten
werden müssen,
werden Transaktionen, die auf dieselben exklusiven Zugriffszeichen zugreifen,
serialisiert. D.h., die Mitglieder einer Verarbeitungsgruppe schreiben
eine Transaktion (dieselbe Transaktion) fest, ehe das Festschreiben
einer anderen Transaktion gestattet wird.
-
Gemäß einem
Aspekt der vorliegenden Erfindung wird eine Serialisierungstechnik
bereitgestellt, die das parallele Einleiten von Transaktionen gestattet,
die dieselben Ressourcen benutzen. Der Initiator einer Transaktion
zählt auf,
welche Zeichen (z.B. Kennzeichen) die Transaktion für exklusive
und gemeinsam Benutzung benötigt.
Als eine Alternative kann eine zentrale Zeichenzuteilungseinheit
(Server) verwendet werden. Der Initiator würde Zeichen von der zentralen
Zeichenzuteilungseinheit erhalten, ehe die Transaktion eingeleitet
wird. Aber für
eine Mehrzahl von Fällen
haben die Zeichen keinen Konflikt, somit gibt es eine große Verbesserung
der Leistung gegenüber
einem Verfahren mit Zeichenzuteilungsserver. Falls aber Zeichen
einen Konflikt haben, wird die Serialisierungstechnik der vorliegenden
Erfindung ausgeführt,
um die Konsistenz der Daten in jedem Mitglied der Verarbeitungsservergruppe
zu erhalten.
-
Zum
Beispiel sei angenommen, dass zwei Transaktionen gleichzeitig eingeleitet
werden, die exklusiven Zugriff auf ein Zeichen mit der Bezeichnung "A" anfordern. Weiterhin sei angenommen,
dass Server 1 eine Transaktion T1 einleitet und Server 2 eine Transaktion
T2 einleitet. Angenommen, T1 soll A = 1 setzen und T2 soll A = 2
setzen. Weiterhin sei angenommen, dass es drei Mitglieder in der
Verarbeitungsgruppe gibt, die diese Transaktionen ausführen sollen.
Da die Transaktionen gleichzeitig eingeleitet werden, ist ihre Reihenfolge nicht wichtig,
aber sie müssen
von allen Mitgliedern in derselben Reihenfolge ausgeführt werden.
-
Die
synchron vervielfältigten
Transaktionen werden unter Verwendung eines Zweiphasenfestschreibeprotokolls
ausgeführt.
So werden die Daten in einer ersten Phase übertragen, Festschreibevorbereitungsphase
(Prepare to Commit, PTC) genannt, und die Transaktion wird in einer
zweiten Phase festgeschrieben, Festschreibephase (Commit, CMT) genannt.
Die Zweiphasenfestschreibung kann parallel weitergehen (d.h., die Transaktionen
T1 und T2 können
parallel eingeleitet werden), wodurch die Vervielfältigung
von Transaktionen leistungsfähiger
wird. Aber an irgendeinem Punkt in dem Zweiphasenfestschreibeprotokoll
müssen
die Transaktionen serialisiert werden. Wenn nicht, treten Probleme
auf, wie unten beschrieben.
-
Wenn
der Zweiphasenfestschreibung die parallele Verarbeitung ohne Serialisierung
gestattet wird, könnte
das zu inkonsistenten Ergebnissen führen, wie unten dargestellt:
Server
1 | Server
2 | Server
3 |
PTC(T1) | PTC(T2) | PTC(T2) |
PTC(T2) | TC(T1) | PTC(T1) |
//** der Server wartet auf Bestätigung,
dass die PTCs empfangen wurden, ehe die Festschreibephase bearbeitet
wird:
CMT(T1) | CMT(T1) | CMT(T2) |
CMT(T2) | CMT(T2) | CMT(T1) |
-
Das
Problem hierbei ist, dass Server 1 und Server 2, die T1, T2 ausgeführt haben,
in diesen Servern A = 1 setzen. Server 3 hat jedoch T2, T1 ausgeführt, und
setzt als Endergebnis A = 2. Der Wert von "A" ist
jetzt in der Verarbeitungsgruppe inkonsistent, und das ist in einem
synchron vervielfältigten
Transaktionssystem nicht akzeptabel.
-
Um
dieses Problem zu überwinden,
wird der ersten Phase des Zweiphasenfestschreibeprozesses (der PTC-Phase)
gestattet, parallel zu arbeiten, und dann wird die Festschreibephase
basierend auf den in der PTC gesendeten Zeicheninformationen gemäß einem
Aspekt der vorliegenden Erfindung serialisiert. Das PTC-Protokoll
wird so erweitert, dass es Informationen darüber liefert, welche Zeichen
für exklusiven/gemeinsamen
Zugriff für
jede Transaktion notwendig sind. Da eine Zuordnung (A = 1) exklusiven
Zugriff erfordert, wird das Zeichen "A" für exklusiven
Zugriff in der PTC sowohl von T1 als auch T2 aufgezählt.
-
Weitere
Einzelheiten bezüglich
des Zweiphasenfestschreibeprotokolls werden mit Bezug auf die 23 und 24 beschrieben.
Insbesondere wird ein Beispiel der ersten Phase des Zweiphasenfestschreibeprotokolls,
der Festschreibevorbereitungsphase, mit Bezug auf 23 beschrieben
und ein Beispiel der zweiten Phase, der Festschreibephase, wird
mit Bezug auf 24 beschrieben.
-
Es
wird auf 23 Bezug genommen, zuerst wird
eine Vervielfältigungsanforderungsnachricht 2300 von
der Client-Anwendungsinstanz 2302 an
den Server 2304 gesendet, die kennzeichnet, dass eine PTC
ausgeführt
werden soll. Als Antwort auf den Empfang der PTC-Anforderung sendet
Server 2304 eine PTC-Nachricht 2306 an
die anderen Server der Gruppe (z.B. Server 2308a und 2308b).
In einem Beispiel enthält
die PTC-Nachricht dieselben Felder wie die Vervielfältigungsanforderungsnachricht sowie
einen Bezeichner der Anforderung. Da Server 2304 die PTC
einleitet, wird er als der Protokoll-Initiator bezeichnet.
-
Danach
antwortet jeder Server, der nicht Initiator ist, auf die PTC-Anforderung
mit einer PTC-Bestätigungsnachricht
(PTC_ACK-Nachricht) 2310.
Insbesondere sendet Server 2308a eine Bestätigung,
die einen Operationscode sowie den Anforderungsbezeichner enthält. Ähnlich sendet
Server 2308b eine Bestätigung, aber
erst nach dem Serialisieren irgendwelcher Konflikte. Das heißt, in diesem
Beispiel wird Server 2308b als ein Koordinator der Gruppe
gewählt.
So überwacht
er alle PTC-Anforderungen,
die er empfängt
und sendet eine PTC_ACK-Nachricht 2310, die irgendwelche
unverträglichen
Anforderungen serialisiert. Wenn er bemerkt, dass zwei oder mehr
PTCs für
dieselbe exklusive Zugriffsressource (oder für eine exklusive Anforderung,
die einer gemeinsam genutzten widerspricht) abgesetzt wurden, wählt der
Gruppenkoordinator, eine von ihnen zuerst festzuschreiben, wartet
auf die Bestätigung,
dass die Aktualisierung abgeschlossen ist, schreibt dann die zweite
fest und so weiter.
-
Der
Protokoll-Initiator (z.B. Server 2304) empfängt die
PTC_ACK-Nachrichten
von den anderen Servern. Nachdem er alle PTC_ACK-Nachrichten für eine bestimmte Nachricht
empfangen hat, sendet er eine Festschreibenachricht und leitet so
die zweite Phase des Zweiphasenfestschreibeprotokolls ein.
-
Ein
Beispiel der zweiten Phase des Zweiphasenfestschreibeprotokolls
wird mit Bezug auf 24 beschrieben. Am Anfang empfängt der
Protokoll-Initiator 2400 PTC_ACK-Nachrichten von allen
Mitgliedern der Gruppe und sendet dann eine Festschreibenachricht 2402 an
jeden der anderen Server der Verarbeitungsgruppe. Jeder Server der
Gruppe sendet eine Vervielfältigungsrückrufnachricht 2404 an
seine entsprechende Anwendung, um die Anwendung aufzufordern, die
Operation festzuschreiben. Nach Festschreiben der Operation wird
eine Vervielfältigungsrückrufergebnisnachricht 2406 von
der Client-Anwendung
an den DSTS-Server gesendet.
-
Danach
wird eine Festschreibebestätigungsnachricht 2408 von
jedem DSTS-Server an den Protokoll-Initiator gesendet (z.B. Server 2400).
Der Protokoll-Initiator empfängt
die Festschreibebestätigungsnachrichten
von allen Mitgliedern der Gruppe und sendet eine Vervielfältigungsabschlussnachricht 2410 an
den einleitenden Client, wenn mindestens eine Mehrheit der Mitglieder
die Anforderung abgeschlossen hat.
-
Gemäß einem
Aspekt der vorliegenden Erfindung wird diese implizite Serialisierung
ohne irgendwelche weiteren Nachrichten einschließlich expliziter Sperrnachrichten
der Ressourcen ermöglicht.
Stattdessen leitet ein Mitglied der Verarbeitungsgruppe eine Transaktion
mit der PTC-Nachricht ein. Es wartet dann auf die Bestätigung,
dass die anderen Mitglieder die PTC-Nachricht empfangen haben, und
diese Bestätigung
wird PTC_ACK-Nachricht genannt. Wenn das einleitende Mitglied alle
PTC_ACKs empfängt,
kann es die Festschreibenachricht absetzen. Daher werden konkurrierende
Transaktionen serialisiert, indem der Gruppenkoordinator seine Bestätigung zurückhält, wenn
er in der PTC-Phase Konflikte feststellt.
-
Somit
wurde der im vorhergehenden Beispiel geschilderte Konflikt wie folgt
gelöst
(angenommen Server 3 ist der Koordinator):
Server 1 | Server
2 | Server 3 |
PTC(T1{A}) | PTC(T1{A}) | PTC(T2{A}) |
PTC(T2{A}) | PTC(T2{A}) | PTC(T1{A})*Koordinator stelltgleichzeitige
Verwendung des Zeichens "A" fest |
//** Die Server warten auf die Bestätigung,
dass die PTCs empfangen wurden
| | PTC_ACK
(T2{A}) *Koordinator |
| | bestätigt nur
Empfang T2, obwohl er |
| | T1
schon empfangen hat |
CMT(T2) | CMT(T2) | CMT(T2)
*alle Mitglieder schreiben |
| | T2
PTC_ACK (T1{A}) fest |
| | *Koordinator
bestätigt
jetzt den |
| | Empfang
von T1 |
CMT(T1) | CMT(T1) | CMT(T1)
*alle Mitglieder schreiben |
| | T1
fest |
-
Während des
Zweiphasenfestschreibeprozesses (und anderer Verarbeitung) einer
verteilten Transaktion kann ein Fehler auftreten. Wenn ein derartiger
Fehler auftritt, stehen Prozeduren zur Wiederherstellung davon gemäß einem
Aspekt der vorliegenden Erfindung zur Verfügung. In einem Beispiel wird
eine transparente Wiederherstellung des DSTS-Systems ausgeführt, und
es gehen während
des Wiederherstellungsprozesses keine ausstehenden Transaktionen
verloren. Als ein Beispiel werden die ausstehenden Transaktionen abgeschlossen,
ohne das Neuschicken der Transaktionen zu erfordern, selbst wenn
eine Anzahl von Mitgliedern der DSTS-Gruppe scheitert.
-
Gemäß einem
Aspekt der vorliegenden Erfindung wird eine Möglichkeit bereitgestellt, die
den Abschluss einer ausstehenden Transaktion ermöglicht, falls bei irgendeinem
Mitglied der DSTS-Gruppe
ein Fehler auftritt. Da das DSTS-System den Fehler einer oder mehrerer
der Mitgliederkopien des Systems beheben kann, wird gesagt, das
dass System eine hohe Verfügbarkeit
hat. Die Lösung
dieses Problems wird durch die Tatsache kompliziert, dass die Ankunft
der Nachrichten in einem Zweiphasenfestschreibeprotokoll nicht synchron
ist, obwohl das DSTS-System garantiert, dass Transaktionen synchron
abgeschlossen werden. Das heißt,
nicht alle Mitglieder empfangen die PTC- und CMT-Nachrichten gleichzeitig,
und als eine Konsequenz kann zu irgendeinem Zeitpunkt jedes Mitglied
eine andere Gruppe von Nachrichten bezogen auf ein Protokoll empfangen
haben, und die Nachrichten können
in unterschiedlicher Reihenfolge empfangen worden sein.
-
Es
wird beispielsweise eine Momentaufnahme des DSTS betrachtet, die
während
der normalen Operation bei T = 4 in
25 aufgenommen
wurde. An diesem Punkt hat jeder Server die folgende Gruppe von Nachrichten
empfangen:
Server
1 | Server
2 | Server
3 |
PTC
(A) | PTC
(B) | PTC
(C) |
PTC
(B) | PTC
(A) | PTC
(A) |
CMT
(A) | PTC
(C) | |
-
Nun
sei angenommen, dass Server 2 bei T = 4 scheitert.
-
Im
Fall eines Fehlers wird eines der verbleibenden Mitglieder als Gruppenkoordinator
gewählt.
In diesem Beispiel wird angenommen, dass Server 1 als Gruppenkoordinator
gewählt
wird. Der Gruppenkoordinator nimmt an der Wiederherstellung teil,
wie hier beschrieben.
-
Eine
Ausführungsform
des mit einer Wiederherstellungsmöglichkeit verbundenen Logik
wird mit Bezug auf 26 beschrieben. Zu Anfang sendet
jedes verbleibende Mitglied dem Gruppenkoordinator eine Liste der
Transaktionsbezeichner, für
welche die PTCs seit dem letzten Synchronisationspunkt überwacht
wurden, SCHRITT 2600. In diesem Beispiel sendet Server
3 PTC(C) und PTC(A). Anschließend
vergleicht der Gruppenkoordinator die PTC-Bezeichner, die durch ein oder mehrere
andere verbleibende Mitglieder mit ihrer eigenen Liste von PTCs
gesendet wurden, SCHRITT 2602. In diesem Beispiel wird
die Liste von Server 3 mit {PTC(B) und PTC(A)} verglichen.
-
Als
Nächstes
fordert der Gruppenkoordinator die tatsächliche PTC- Nachricht für irgendeine
Nachricht an, die durch andere Mitglieder gemeldet, aber vom Koordinator
nicht empfangen wurde, SCHRITT 2604. Zum Beispiel fordert
der Gruppenkoordinator, Server 1, eine PTC(C)-Nachricht von Server
3. An diesem Punkt sind dem Gruppenkoordinator alle ausstehenden
Transaktionen seit dem letzten Synchronisationspunkt bekannt. Der
Gruppenkoordinator übernimmt
jetzt die Rolle des Protokoll-Initiators
für alle
ausstehenden Protokolle. Die anderen Mitglieder der Gruppe wissen,
dass die Rolle des Protokoll-Initiators
geändert
wurde, da das System in den Wiederherstellungsmodus geht, wenn ein
Fehler auftritt.
-
Der
Gruppenkoordinator sendet PTC-Nachrichten an alle der anderen verbleibenden
Mitglieder für
alle PTC-Nachrichten, die in der Gemeinschaft seiner PTC-Liste sind
und der anderen PTC-Liste,
die er in SCHRITT 2600 empfangen hat, SCHRITT 2606.
Zum Beispiel sendet der Gruppenkoordinator {PTC(A), PTC(B), PTC(C)}.
Die verbleibenden Gruppenmitglieder empfangen die ausstehenden PTCs
und speichern die noch nicht empfangenen, SCHRITT 2608.
Zum Beispiel speichert Server 3 PTC(B).
-
Anschließend senden
die verbleibenden Mitglieder PTC_ACK-Nachrichten für jede der PTCs, die empfangen
wurden, SCHRITT 2610. Wenn die PTC_ACKs für die Gruppenmitglieder
für jede
PTC empfangen wurden, sendet der Gruppenkoordinator eine Festschreibenachricht
(CMT-Nachricht), SCHRITT 2612. Wenn die verbleibenden Mitglieder
die Festschreibenachricht empfangen, senden sie CMT_ACK-Nachrichten, SCHRITT 2614.
Wenn die CMT_ACK-Nachrichten
für die
ausstehenden Transaktionen empfangen wurden, hat das DSTS-System
einen anderen Synchronisationspunkt erreicht (d.h. keine ausstehenden
Transaktionen).
-
Vorteilhafterweise
sind die Einzelheiten des Zweiphasenfestschreibeprozesses vor der
Client-Anwendung verborgen. Insbesondere hat die Client-Anwendung
keine Kenntnisse darüber,
dass es andere Kopien der Anwendung gibt, die an dem Festschreibeprozeß beteiligt
sind.
-
Weiterhin
kann die oben beschriebene Wiederherstellungstechnik vorteilhafterweise
mehr als einen Fehler aufnehmen. D.h., sie kann erfolgreich Transaktionen
abschließen,
selbst wenn Gruppenmitglieder weiterhin scheitern, und sogar, wenn
die Wiederherstellung schon im Gange ist, beispielsweise so lange,
wie ein Quorum der Gruppenmitglieder aufrechterhalten wird. Wenn
ein Fehler bemerkt wird, wird die Technik von Anfang an neu gestartet.
Eine Transaktion kann jedoch verloren gehen, wenn der Initiator
der Transaktion scheitert, ehe er irgendwelche PTC-Nachrichten versenden
kann, oder wenn alle einer Mehrheit von Empfängern einer PTC-Nachricht nach
Empfang der Nachricht scheitern. Die Wiederherstellungstechnik ist
auf alle Typen von Anwendungen anwendbar, sogar für Anwendungen,
die keine Rückkehroperationen
unterstützen.
Weiterhin ist es ein nützliches Übertragungsprotokoll
für gemeinsam
benutzte nicht verteilte Systeme.
-
Zusätzlich zu
Obengenanntem kann ein gescheitertes Mitglied wieder in die Gruppe
eintreten, indem das gescheiterte Mitglied den letzten Synchronisationspunkt
feststellt, der beobachtet wird, und von der aktuellen Gruppe das
Delta von Transaktionen erhält,
die es benötigt,
um den letzten Synchronisationspunkt des DSTS-Systems zu erreichen.
-
In
einer Ausführungsform
werden Gruppenmitgliedschaft und Gruppenstatus zur Wiederherstellung des
DSTS-Systems verwendet.
-
Oben
beschrieben wurden verschiedene Aspekte der Verwaltung vervielfältigter
verteilter synchroner Transaktionen. Vorteilhafterweise werden die
Details der Vervielfältigung
vor den Client-Anwendungen verborgen (z.B. keine Abstimmung bei
der Zweiphasenfestschreibung, keine Teilnahme an Gruppenprotokollen).
Ein oder mehrere der Aspekte der vorliegenden Erfindung sind sowohl
auf homogene Systeme als auch heterogene Systeme anwendbar. Als
ein Beispiel werden Möglichkeiten
bereitgestellt, um das Zusammenwirken der Systeme einer heterogenen
Umgebung zu unterstützen.
-
Die
vorliegende Erfindung kann in einem Herstellungsartikel enthalten
sein (z.B. ein oder mehrere Computerprogrammprodukte), beispielsweise
mit computernutzbarem Medium. Das Medium enthält hierin zum Beispiel ein
computerlesbares Programmcodemittel zum Bereitstellen und Unterstützen der
Möglichkeiten
der vorliegenden Erfindung. Der Herstellungsartikel kann als ein
Teil eines Computersystems enthalten sein oder getrennt verkauft
werden.
-
Zusätzlich kann
mindestens eine maschinenlesbare Programmspeichereinheit bereitgestellt
werden, die deutlich mindestens ein Programm von Instruktionen verkörpert, das
von der Maschine ausführbar
ist, um die Möglichkeiten
der vorliegenden Erfindung auszuführen.
-
Die
hierin gezeigten Flussdiagramme sind nur Beispiele. Es kann viele
Variationen zu diesen Diagrammen oder den darin beschriebenen Schritten
(oder Operationen) geben, ohne vom Umfang der Erfindung abzuweichen.
Zum Beispiel können
die Schritte in einer anderen Reihenfolge ausgeführt werden oder es können Schritte
hinzugefügt,
gelöscht
oder modifiziert werden. Alle diese Variationen werden als Teil
der beanspruchten Erfindung betrachtet.
-
Obwohl
hierin bevorzugte Ausführungsformen
detailliert gezeigt und beschrieben wurden, wird es dem Fachmann
offensichtlich sein, dass verschiedene Modifikationen, Ergänzungen,
Ersetzungen und Ähnliches erfolgen
können,
ohne vom Wesen der Erfindung abzuweichen und diese werden daher
als innerhalb des Umfangs der Erfindung betrachtet, wie in den folgenden
Ansprüchen
definiert.