-
FELD DER ERFINDUNG
-
Die
Erfindung befindet sich im Bereich von Methoden und Systemen von
Nachrichtenlieferung zwischen Computerprogrammen über einen
Nachrichtenserver. Diese Erfindung betrifft insbesondere das Feld
der Nachrichtenorientierten Middleware (Message Oriented Middleware – MOM).
-
HINTERGRUND
DER ERFINDUNG
-
MOM
ermöglicht
zahlreichen Computerprogrammen, diskrete Nachrichten miteinander über ein Kommunikationsnetz
auszutauschen. MOM kennzeichnet sich durch eine „lose Kupplung" von Nachrichtenherstellern
und Nachrichtenbenutzern, wobei der Hersteller einer Nachricht nicht
braucht, die Identität,
die Lokalisierung sowie die Anzahl von Benutzern dieser Nachricht
zu kennen. Darüber
hinaus, wenn ein vermittelnder Nachrichtenserver eingesetzt wird,
kann die Nachrichtenlieferung sichergestellt werden, sogar wenn
die endgültigen
Benutzer der Nachricht in der Zeit deren Herstellung unerreichbar sind.
Das kann der Verbindungsorientierten Middleware (Connection Oriented
Middleware) entgegengestellt werden, wobei es erforderlich ist,
dass ein Computerprogramm über
Details der Identität
und der Netzlokalisierung eines anderen Computers verfügt, um eine
Verbindung mit diesem Computer erstellen zu können, bevor Daten mit ihm ausgetauscht werden.
Um eine Verbindung zu erstellen, müssen beide Computer über die
ganze Zeit, wenn die Verbindung aktiv ist, erreichbar und ansprechbar
sein.
-
EP-A
0 853 277 beschreibt eine modulare Middleware/Anwendungssoftware
zur Bereitstellung der nachrichtenorientierten Kommunikation zwischen Anwendungen.
Sie besteht aus einem Cluster von individuellen, netzverbundenen
Nachrichtenservern, die eine Vielfalt von Außenverbindungen umfassen, die
den Anwendungen ermöglichen,
miteinander zu verbinden und zu kommunizieren. Für die verbindende Anwendung
ist der Cluster von Nachrichtenservern transparent, d.h. er scheint
ein einzelner, zentralisierter Nachrichtenserver zu sein. Während des Empfangs
von Nachrichten aus einer veröffentlichenden
Anwendung über
eine der Außenverbindungen selektiert
die Nachrichtenmiddleware einen oder mehr Empfänger der Nachricht und bewirkt,
dass die Nachrichten an eine oder mehr korrespondierende Anwendungen über die
Verbindung, an der diese Anwendungen) angeschlossen ist/sind, geliefert
werden. Die Nachrichtenmiddleware unterstützt die Veröffentlicher, die spezifizieren
können,
dass ihre veröffentlichten
Nachrichten dauerhaft gespeichert werden, um der Speicher aus fehlertoleranten Gründen stabil
zu machen. Sie ermöglicht
auch einem Empfänger,
Nachrichten zu empfangen, die während
seiner vorübergehenden
Abwesenheit gesendet worden sind. Die Nachrichtenmiddleware unterstützt auch atomare
Veröffentlichung
und/oder Empfangung von einem Nachrichtensatz im Rahmen von Transaktionen.
Während
einer Transaktion erfasst die Nachrichtenmiddleware Aktionen und
kompensierende Aktionen für
jede erfasste ungetane Aktion. Nachdem ein Fehler detektiert worden
ist, wird die Transaktion gestoppt und die so weit ausgeführten Aktionen
werden annulliert. Ereignisse (d.h. der Empfang einer Nachricht
bzw. die Sendung einer Nachricht an eine Anwendung) innerhalb des
Clusters von Nachrichtenservern sowie Ereignisse, die durch Verbindungen
generiert werden, werden über
den Cluster von Nachrichtenservern mittels eines unterliegenden,
betriebssicheren Nachrichtensystems verteilt.
-
Diese
Erfindung betrifft insbesondere den Fall, wenn ein vermittelnder
Nachrichtenserver eingesetzt wird, um Nachrichten zu speichern und
diese an Benutzer zu verteilen. Obwohl Hersteller und Benutzer (gemeinsam „Kunden" genannt) miteinander auf
lose Weise während
der Kommunikation über MOM
gekuppelt sind, werden normalerweise die vermittelnden Nachritenserver
zur Kommunikation mit diesen Kunden auf eine verbindungsorientierte
Weise benötigt.
Diese Ermöglichung,
Absender und Empfänger
miteinander zu kommunizieren, ohne dass beide zur gleichen Zeit
erreichbar sind, setzt voraus, dass der Server ganze Zeit erreichbar
ist. Darüber
hinaus müssen
alle Kunden, die beabsichtigen, Nachrichten auszutauschen, mit demselben
Server bzw. mit verschiedenen Servern verbunden sein, die fähig sind
bzw. zusammenarbeiten, um die äquivalente
Funktionalität
von einem Einzelserver zu erreichen. d.h. als ein einzelner logischer
Server zu dienen. MOM wird oft bei Systemen verwendet, bei denen
eine große
Anzahl von Servern als ein logischer Server zu dienen hat. Ein der
Gründe
für den
Einsatz von MOM besteht darin, dass die Anforderung erleichtert
wird, um a priori zu definieren, welche Programme Daten miteinander
austauschen dürfen.
Das bedeutet, dass große
Organisationen, die MOM bei den in der ganzen Organisation verbreiteten
Computeranwendungen verwenden, bzw. Organisationen, die MOM verwenden,
um Dienstleistungen der breiten Öffentlichkeit über Internet
zur Verfügung
zu stellen, bereit sein müssen,
viele Tausende von Programmen, die über einen einzelnen logischen
Server kommunizieren, zu berücksichtigen.
-
Diese
Erfindung betrifft insbesondere den Fall, in welchem ein MOM-Server
als ein Cluster von zahlreichen Computern realisiert wird. Im Kontext dieses
Dokuments definieren wir einen Cluster als eine Gruppe von Computern,
die zusammenarbeiten, um eine einzelne Dienstleistung mit einer
höheren Kapazität und einer
höheren
Betriebssicherheit bereitzustellen, als diese, die unter Einsatz
eines Einzelcomputers erreicht werden können. Um eine hohe Betriebssicherheit
beim Ausfall von einem oder mehreren Maschinen im Cluster zu sichern,
müssen
die durch den Server gehaltenen Nachrichten und deren zugehörigen Zustandinformationen
auf vielen Computern redundant gespeichert werden. Das stellt sicher,
dass die Daten für
den Cluster stets erreichbar sind, wenn ein Computer ausfällt.
-
Die
Erfindung betrifft den betriebssicheren Cluster, der eine Haupt-
und Backupmethode von der redundanten Speicherung verwendet. In
diesem Fall ist ein Computer für
eine Menge von Nachrichten, die durch den Nachrichtenservercluster
ausgeführt
werden, als der Hauptknoten tätig.
Der Hauptknoten ist für
Speicherung von Nachrichten und deren aktiven Lieferung an Nachrichtenbenutzer
verantwortlich. Ein oder mehrere andere Computer sind als Backupknoten
für den
Hauptknoten tätig.
Die Backupknoten sind für
Speicherung von einer identischen Kopie der Daten, die im Hauptknoten
gespeichert sind, verantwortlich, aber sie werden die aktive Lieferung
von gespeicherten Nachrichten an Benutzer nicht vornehmen. Sollte
der Hauptknoten ausfallen, so muss/müssen der/die Backupknoten diesen
Ausfall detektieren und sicherstellen, dass exakt ein Backupknoten
promoviert wird, um die Rolle des Hauptknotens abzuspielen, und
beginnt, Nachrichten an Benutzer aktiv zu liefern. Der/die Backupknoten
identifiziert/identifizieren den Ausfall des Hauptknotens durch
die Tatsache, dass sie nicht länger
fähig sind, mit
diesem zu kommunizieren. Um das richtige Verhalten des Nachrichtensystems
zu gewährleisten,
ist es wichtig, dass exakt ein Knoten im Cluster als der Hauptknoten
für eine
gegebene Menge von Nachrichten jeweils tätig ist. Die exakte Bedeutung
des „richtigen
Verhaltens" wird
unten beschrieben.
-
Zusätzlich zu
dem Ausfall von individuellen Computern kann bei solchem Cluster
eine andere Art des Ausfalls auftreten, d.h. eine Netzteilung. Der
Begriff „Netzteilung" betrifft die Situation,
in welcher das Datennetz, das die Computer im Cluster verbindet,
in zwei oder mehrere getrennte Unternetze aufgeteilt wird. Jede
dieser getrennten Unternetze wird „Partition" genannt. Jede Partition funktioniert
richtig, ausgenommen der Tatsache, dass die Computer in einer Partition
mit den Computern in anderer Partition nicht kommunizieren können. Das
Symptom der Netzteilung ist dasselbe, wie bei dem Knotenausfall,
und zwar werden ein oder mehrere Computer für die Kommunikation unerreichbar.
Aus diesem Grunde ist generell nicht möglich, dass der Backupknoten
zwischen dem Ereignis, in welchem sein korrespondierender Hauptknoten
ausfällt,
und dem Ereignis, in welchem das Netz aufgeteilt wird und der korrespondierende
Hauptknoten weiter funktioniert, aber in einer differenten Partition,
unterscheidet.
-
Es
entsteht dabei ein fundamentales Dilemma im Bereich der Betriebssicherheit
von Servern bei der Haupt- und Backupmethode. Wenn ein Hauptknoten
von einem Backupknoten infolge einer Netzteilung getrennt wird,
aber der korrespondierende Backupknoten geht davon aus, dass dieser
ausfällt, so
wird der der Backupknoten zu einem Hauptknoten. Das hat zur Folge,
dass der Cluster über
zwei Hauptknoten für
denselben Nachrichtensatz gleichzeitig verfügt. Sollten beide dieser Hauptknoten
im Kontakt mit Nachrichtenbenutzern sein, so wird nicht länger möglich, das
richtige Verhalten des Nachrichtenservers zu gewährleisten. Anderseits, wenn
der Hauptknoten nicht ausfällt,
aber der korrespondierende Backupknoten geht davon aus, dass dieser sich
in einer differenten Netzpartition befindet, so wird der Backupknoten
nicht zu einem Hauptknoten und die Betriebssicherheit des Nachrichtenserverclusters
wird nicht erreicht, d.h. Nachrichten werden dann nicht geliefert.
-
Die
Implementierungen von Nachrichtenserverclustern gehen gemäß dem Stand
der Technik davon aus, dass der Ausfall der Kommunikation mit einem
oder mehreren Computern indiziert, dass diese Computer ausgefallen
sind. Das ist verständlich, wenn
man bedenkt, dass Computerausfälle
häufiger als
Netzteilungen auftreten. Im Fall des Haupt-/Backupschemas der Betriebssicherheit
führt das
zu einem unrichtigen Systemverhaltens während der Netzteilung wegen
der Tatsache, dass zwei Computer zu einem Hauptknoten für denselben
Nachrichtensatz gleichzeitig werden können. Diese Erfindung ist einzigartig
dadurch, dass sie eine Maßnahme
bereitstellt, um das richtige Verhalten des Nachrichtenclustersystems,
das die Haupt-/Backupmethode
der Betriebssicherheit verwendet, sogar während der Netzteilung zu gewährleisten.
Sie kann das tun, ohne zu brauchen, zu entdecken, ob der Ausfall
der Kommunikation infolge des Computerausfalls bzw. der Netzteilung
aufgetreten ist. Diese Erfindung als solche stellt keine neuartige
Maßnahme
zur Entdeckung der Natur des Ausfalls bereit, sondern stellt eine
Maßnahme
zur Sicherstellung der hohen Erreichbarkeit im Rahmen der Haupt-/Backupmethode zur
Verfügung,
wobei das richtige Verhalten gewährleistet wird,
ohne zu brauchen, beide Arten des Ausfalls auf differente Weise
zu behandeln.
-
Es
ist wichtig, das Verhalten zu definieren, das der Nachrichtenservercluster
aufweisen muss, um als richtig betrachtet zu werden. Diese Erfindung gewährleistet
das richtige Verhalten des Nachrichtensystems gemäß der Version
1.0.2 der Spezifikation der Programmierschnittstelle (API) Java
Message Service (JMS), die von Sun Microsystems Inc. veröffentlicht
worden ist. Die Definition dieser Schnittstelle ist unter http://java.sun.com/products/jms/docs.html zugänglich.
Es gibt folgende Schlüsselaspekte
dieses Verhaltens:
- – Gewährleistete Nachrichtenlieferung:
JMS definiert zwei Nachrichtenlieferungsmodi: beständig und
unbeständig.
Es ist zulässig,
unbeständige Nachrichten
beim Ereignis des Systemausfalls loszulassen. Ein JMS-verträgliches
Nachrichtensystem muss jedoch gewährleisten, dass beständige Nachrichten
immer nach dem Systemausfall wiederhergestellt werden können und
dass diese eventuell an beabsichtigte Empfänger geliefert werden. Computerprogramme,
die ein Nachrichtensystem mit einem beständigen Lieferungsmodus verwenden,
um Nachrichten zu senden, sollten keine zusätzlichen Maßnahmen brauchen, um sicherzustellen,
dass die Nachricht an einen entsprechenden Empfänger erfolgeich geliefert worden
ist. Das Ziel dieser Erfindung ist es, eine gewährleistete, beständige Nachrichtenlieferung
bereitzustellen, sogar im Fall der Netzteilung, die die Computer
separiert, die den Nachrichtenservercluster bilden. (Die Erfindung
verhindert auch den Verlust von unbeständigen Nachrichten beim Ereignis
der Netzteilung, sogar wenn solcher Verlust aktuell zulässig ist).
- – Gewährleistete
Einmalige Lieferung: JMS definiert zwei Nachrichtendomänen: Punkt-zu-Punkt und
Veröffentlichen/Subskribieren. Punkt-zu-Punkt-Nachrichten
müssen
exakt einmal exakt an einen infrage kommenden Empfänger geliefert
werden. Das entspricht generell solchen Handlungen, wie Deponierung
von Geld auf einem Bankkonto, was nicht mehr als nur einmal ausgeführt werden
kann. Veröffentlichte/subskribierte
Nachrichten müssen
exakt einmal an jeden infrage kommenden Subskribenten geliefert
werden. Solche Nachrichten enthalten Informationen, welche an eine
beliebige Anzahl von Empfängern verbreitet
werden dürfen,
aber müssen
exakt einmal an jeden Empfänger
geliefert werden. (Bei beiden Lieferungsmodi hat der Kunde die Möglichkeit,
zu spezifizieren, dass doppelte Lieferungen an einen Benutzer zulässig sind).
Wenn der Nachrichtenbenutzer die Nachricht empfängt und dann unerwartet die
Funktion abbricht, bevor der Empfang der Nachricht bestätigt wird,
so wird die Nachricht gem. JMS als ungeliefert betrachtet. Ein weiteres
Ziel dieser Erfindung ist es, sowohl richtige Punkt-zu-Punkt-Lieferung von Nachrichten, als
auch richtige Lieferung von veröffentlichten/subskribierten
Nachrichten trotz der Netzteilung, die die Computer separiert, die
den Nachrichtenservercluster bilden, zu gewährleisten.
- – Ordnungsmäßige Nachrichtenlieferung:
Ein Kunde des JMS-Nachrichtensystems darf zahlreiche Hersteller
und Benutzer haben. Diese Hersteller und Benutzer werden in eine
oder mehrere Sessionen gruppiert, wobei jede Session keinen oder
mehrere Hersteller bzw. keinen oder mehrere Benutzer enthält. Alle
Nachrichten, die innerhalb einer Session hergestellt werden, müssen an Benutzer
in derselben Ordnung geliefert werden, in welcher diese hergestellt
worden sind. Die JMS-Spezifikation identifiziert deutlich Ausfallbedingungen,
bei welchen es nicht möglich
ist, beide gewährleistete
Lieferungsarten sicherzustellen und ordnungsmäßig Nachrichten zu liefern,
d.h. wenn eine Nachricht an einen Benutzer geliefert wird, und dieser
Benutzer ausfällt,
bevor der Empfang der Nachricht bestätigt wird, aber nachdem anschließende, in
derselben Session hergestellte Nachrichten an andere Benutzer geliefert
worden sind. In solchem Fall ist es zulässig, die fragliche Nachricht
an andere Benutzer zu liefern, obwohl es nicht ordnungsmäßig ist.
- – Transaktionen:
Wie im vorigen Punkt erwähnt, darf
eine beliebige Anzahl von Herstellern und Benutzern von einem Kunden
zusammen in eine Session gruppiert werden. Jede Session darf optional
als „transaktioniert" spezifiziert werden.
Der Kunde muss eine Transaktionssession anweisen, alle Nachrichten,
die seit der letzten Abwicklung hergestellt und benutzt worden sind,
abzuwickeln, bevor die Lieferung dieser Nachrichten erfolgreich wird.
Jegliche Herstellung und Benutzung von Nachrichten, die zwischen
nacheinander folgenden Abwicklungen auftritt, muss als eine Einzeleinheit
gelungen bzw. misslungen sein. Das bedeutet, dass es trotz irgendeines
Systemausfalls, der auftreten kann, zwei mögliche Ergebnisse für den Satz
von Nachrichten, die innerhalb einer Transaktionssession zwischen
zwei nacheinander folgenden Abwicklungen hergestellt und benutz
werden, gibt: 1) die Benutzung von allen empfangenen Nachrichten
wird für
das Nachrichtensystem zur Zeit der Abwicklung bestätigt und hergestellte
Nachrichten werden für
Lieferung an Benutzer zur Zeit der Abwicklung zugänglich, oder
2) alle hergestellten Nachrichten werden abgebrochen und alle benutzten
Nachrichten werden verweigert, was die Session wirksam zu einem
Zustand zurückbringt,
der unmittelbar nach der vorigen Abwicklung war. Also, wenn zwei Nachrichten
innerhalb derselben Transaktion erstellt werden, d.h. einerseits
die Anordnung der Entnahme eines Geldbetrags aus einem Bankkonto
und anderseits die Anordnung der Deponierung desselben Betrags in
einem anderen Bankkonto, so ist es niemals möglich, dass die Entnahme ohne
die korrespondierende Deponierung auftritt. Ein anderes Ziel der
Erfindung ist es also, eine richtige Transaktionssemantik trotz
der Netzteilung, die auftreten kann, bevor die Transaktion erfolgreich
abgewickelt worden ist, bereitzustellen.
-
Zusätzlich zum
Obigen beabsichtigen wir, dass diese Erfindung einen zusätzlichen
Aspekt des Verhaltens bereitstellt, welcher von JMS nicht spezifiziert
worden ist, aber für
Erfüllung
der grundsätzlichen
Bestimmung eines Nachsichtensystems kritisch ist:
- – Das Nachrichtensystem
ist ganze Zeit zugänglich,
um Nachrichten von Nachrichtenherstellern zu akzeptieren: JMS stellt
deutlich keine Anforderungen hinsichtlich der Zugänglichkeit
des Nachrichtensystems fest. Ein serverbasiertes Nachrichtensystem
ist jedoch beabsichtigt, um bei Computerprogrammen den Bedarf für Implementierung
der Nachrichtenspeicherung und -absendung zu verringern. Das Nachrichtensystem
kann diese Beabsichtigung nicht erfüllen, ohne Zugänglichkeit
zu gewährleisten.
Die permanente Zugänglichkeit
für Akzeptierung
von Nachrichten von Nachrichtenherstellern ist in dieser Hinsicht mehr
kritisch als die Zugänglichkeit
für Verteilung von
Nachrichten an Benutzer. Die JMS-Spezifikation sowie Nachrichtensysteme
im Allgemeinen gewährleisten
keine minimale Zeit der Lieferung von einem Hersteller an einen
Benutzer. Das ist außerhalb
der Kontrolle des Nachrichtensystems, weil man nicht voraussetzen
kann, dass Benutzer ganze Zeit erreichbar sind, um Nachrichten zu empfangen.
Aus diesem Grunde müssen
sich Nachrichtenbenutzer dadurch kennzeichnen, dass sie hinsichtlich
Verspätungen
bei Nachrichtenlieferungen geduldig sind. Anderseits ist es zu beachten,
dass ein einfacher Nachrichtenhersteller, der interaktiv Auftragsinformationen
von menschlichen Benutzern versammelt, diese als eine Nachricht
verpackt, an das Nachrichtensystem absendet, die Auftragsabwicklung
an den Benutzer bestätigt,
nur nach Erledigung dieser Tätigkeiten
bereit ist, einen anderen Auftrag auszuführen. Wenn das Nachrichtensystem
nicht bereit ist, die Verantwortlichkeit für die Nachricht während dieses
Zyklus zu übernehmen,
dann entweder: 1) muss der Benutzer eine unbestimmte Zeitmenge warten,
bis das Nachrichtensystem zugänglich
ist, bevor er eine Bestätigung
empfängt,
dass der Auftrag abgewickelt worden ist, oder 2) muss der Nachrichtenhersteller
eine betriebssichere, wiederherstellbare Speicherung der Nachricht
bereitstellen, bis das Nachrichtensystem zugänglich ist. Beide dieser Optionen
vernichten die Nutzungsbestimmung eines Nachrichtensystems bei solchem
Szenario. Deswegen setzen wir voraus, dass die Fähigkeit, hergestellte Nachrichten
jederzeit zu akzeptieren, ein Kriterium für die Zugänglichkeit des Nachrichtenservers
bildet. Ein anderes Ziel der Erfindung ist es also, sicherzustellen,
dass ein Nachrichtenservercluster immer zugänglich ist, um Nachrichten
von Nachrichtenherstellern zu akzeptieren und eine richtige Lieferung
dieser Nachrichten zu gewährleisten,
sogar wenn der Cluster der Netzteilung unterliegt.
-
Diese
Erfindung stellt eine Beständigkeit
gegen Netzteilung, insbesondere bei einem Nachrichtenservercluster
gemäß der Patentanmeldung 09/750,009 „Scaleable
Message System",
bereit. Für Details über dieses
Nachrichtensystem verweisen wir auf die Veröffentlichung dieser Anmeldung,
wobei die Anmeldung hier als Referenzmaterial berücksichtigt
wird. Es wird hier nur eine kurze Beschreibung präsentiert.
Das skalierbare Nachrichtensystem ist in 1 dargestellt.
Das skalierbare Nachrichtensystem besteht aus zwei oder mehreren
logischen Knoten. Jeder Knoten kann auf einem getrennten Computer
betrieben werden bzw. zahlreiche Knoten können auf demselben Computer
betrieben werden. Es gibt zwei Knotenarten: Kundenmanager (Client
Manager – CM)
und Nachrichtenmanager (Massage Manager – MM). Nachrichtenmanagerknoten
sind für Speicherung
und Verteilung von Nachrichten verantwortlich. Sie sind nicht direkt
für Kunden
zugänglich. Kunden
müssen
sich mit Kundenmanagerknoten verbinden, und die Kundenmanagerknoten
leiten Kundenanfragen an die Nachrichtenmanagerknoten über einen
betriebssicheren, atomaren Multicast-Nachrichtenbus weiter. Der
Nachrichtenbus ermöglicht, Daten
aus einem Knoten an einzelne andere Knoten gleichzeitig zu übersenden,
ohne mehr Netzressourcen zu benutzen, als bei Übersendung von denselben Daten
nur an eine Maschine. Individuelle Kundenmanagerknoten enthalten
keine Zustandinformationen, was für die kontinuierliche Funktion
des Systems kritisch ist, sodass der Ausfall von einem oder mehreren
Kundenmanagerknoten toleriert werden kann, ohne zu brauchen, einen
Backupknoten einzusetzen. Wenn ein Kundenmanagerknoten ausfällt, verbinden
sich die Kunden, die mit ihm verbunden waren, automatisch mit einem
anderen Kundenmanagerknoten und setzen die normale Operation fort. 1 zeigt
einen Cluster von zusammen verbundenen Kundenmanagern und Nachrichtenmanagern.
-
Nachrichtenmanagerknoten
enthalten Zustandinformationen, die für die kontinuierliche Funktion
des Systems kritisch sind. Aus diesem Grunde müssen ihre Zustandinformationen
auf zahlreichen Knoten redundant gespeichert werden. Es gibt zwei Nachrichtenmanagerknotenarten:
Haupt und Backup. Jederzeit ist jeder der Nachrichtenmanager-Hauptknoten
für Speicherung
und Verteilung von einem Nachrichten-Untersatz, der von dem Nachrichtensystem
transferiert wird, verantwortlich. Zusammen sind alle Nachrichtenmanager-Hauptknoten für den kompletten
Nachrichtensatz, der von dem Nachrichtensystem transferiert wird,
jederzeit verantwortlich. Für
jeden Nachrichtenmanager-Hauptknoten gibt es eine beliebige Anzahl
von Nachrichtenmanager-Backupknoten.
Jeder Nachrichtenmanager-Backupknoten ist für Aufbewahrung einer exakten
Kopie von dem Zustand seiner korrespondierenden Nachrichtenmanager-Hauptknoten
verantwortlich und muss bereit sein, die Rolle des Nachrichten-Hauptmanagers
zu übernehmen,
wenn der originelle Nachrichten-Hauptmanager ausfällt. Jeder Nachrichtenmanager-Hauptknoten
wirkt eng mit seinem korrespondierenden Nachrichtenmanager-Backupknoten
zusammen, aber weist eine geringe Interaktion mit anderen Nachrichtenmanagerknoten
auf. Aus diesem Grunde wird jede Gruppe von einem Nachrichtenmanager-Hauptknoten
und seinen Nachrichtenmanager-Backupknoten
als Untercluster bezeichnet.
-
Der
oben beschriebene Nachrichtenservercluster besteht aus zwei unterschiedlichen
Knotenarten und es gibt ein paar Vorteile, um diese zwei Knoten
auf zwei physisch unterschiedlichen Computern unterzubringen. Es
ist wichtig, zu beachten, dass diese Art des Nachrichtenserverclusters
mittels einer einzelnen Art des Knotens durch Kombinierung der Funktionalität des Kundenmanagers
mit dem Nachrichtenmanager in eine einzelne Knotenart ausgeführt werden
kann. Die Beschreibung dieser Erfindung wird jedoch durch Verwendung
des Modells, in welchem diese Knotenarten physisch getrennt sind, erleichtert
und deswegen wird dieses Modell in dem ganzen Dokument genutzt.
-
Die
Erfindung beruht auf dem Konzept von einem synchronischen Netzsichtfeld.
Das Sichtfeld ist eine Liste von Maschinen, mit welchen ein gegebener
Knoten über
das Datennetz zum bestimmten Zeitpunkt kommunizieren kann. Diese
Erfindung setzt voraus, dass alle Knoten, die sich im Sichtfeld von
einem gegebenen Knoten befinden, über dasselbe Sichtfeld verfügen; d.h.:
wenn A im Sichtfeld von B, aber C nicht im Sichtfeld von B ist,
dann ist C nicht im Sichtfeld von A. Also, wenn keine Netzteilung
vorhanden ist, verfügen
alle Knoten über
alle anderen Knoten in ihrem Sichtfeld, und wenn das Netz aufgeteilt
ist, verfügen
alle der Knoten in einer Partition über dasselbe Sichtfeld, aber
das Sichtfeld enthält keinen
Knoten, der sich in einer anderen Partition befindet. Bei der bevorzugten
Ausführungsform
wird die Verantwortlichkeit für
Detektierung des Sichtfelds und Anmeldung von Änderungen im Sichtfeld an den Nachrichtenbus
delegiert, der die Multicastkommunikation innerhalb des Clusters
bereitstellt. Die bevorzugte Ausführungsform benutzt dazu das
Produkt Ibus//MessageBus der Fa. Softwired AG (www.softwired-inc.com),
weil es sowohl eine betriebssichere, atomare, ordnungsmäßige Multicastkommunikation, als
auch Sichtfeldmanagement zur Verfügung stellt.
-
ZUSAMMENFASSUNG
DER ERFINDUNG
-
Diese
Erfindung stellt eine Maßnahme
für einen
Nachrichtenservercluster bereit, um Nachrichten von Nachrichten
herstellenden Kunden zu akzeptieren und diese Nachrichten an Nachrichten
benutzende Kunden zu verteilen, unter Berücksichtigung von Bedingungen
der aktuellen JMS-Spezifikationsversion, wie die JMS-Spezifikationsversion
1.0.2 und folgende Versionen, und stellt sicher, dass der Cluster für zu akzeptierende
Nachrichten hoch zugänglich ist,
sogar wenn Computer im Cluster ausfallen oder das Datennetz, das
die Computer verbindet, in einzelne Netzpartitionen aufgeteilt wird.
-
Diese
Erfindung ist z.B. anwendbar für
die Nachrichtenserverclusterart, die in der US-amerikanischen Patentanmeldung 09/750,009, „Scaleable Message
System", spezifiziert
und vorher in der Hintergrundsektion beschrieben worden ist. Die US-amerikanische
Patentanmeldung 09/750,009 beschreibt die neue Art des Nachrichtenserverclusters ausführlicher
und wird hier als Referenzmaterial berücksichtigt. Diese Art des Nachrichtenserverclusters wird
als hoch zugänglich
bezeichnet, weil alle Nachrichten und zugehörige Zustandinformationen,
die der Server speichern muss, um den richtigen Betrieb sicherzustellen,
auf vielen differenten Computern redundant gespeichert werden können. Das
ermöglicht dem
Nachrichtenservercluster, normale Operationen ohne Unterbrechungen
sowie ohne Nachrichtenverlust fortzusetzen, falls ein oder mehrere
Computer im Cluster unerwartet ausfallen.
-
Die
Erfindung ist jedoch auch nutzbar für Nachrichtenclustersysteme
mit einer Architektur, die von der Knotenarchitektur gem. der oben
erwähnten US-amerikanischen
Patentanmeldung 09/750,009 abweicht. Eine einzige Voraussetzung
für den
Cluster besteht darin, dass eine Vielzahl von Nachrichtenmanagern
vorhanden ist. Die Nachrichtenmanager können grundsätzlich auch als Kundenmanager gleichzeitig
funktionieren.
-
Bei
Punkt-zu-Punkt-Nachrichten setzen die Anforderungen der Spezifikation
voraus, dass jede beständige
Nachricht exakt an einen der infrage kommenden Empfänger geliefert
wird. Bei veröffentlichten/subskribierten
Nachrichten setzen die Anforderungen der Spezifikation voraus, dass
jede Nachricht exakt einmal an jeden infrage kommenden Subskribenten
geliefert wird. Diese Anforderungen implizieren Handlungen, die
zu zeitraubend sind, um zwischen Knoten auf vielen physischen Maschinen
koordiniert zu werden. Diese Handlungen inkludieren die Entscheidung,
welcher infrage kommende Empfänger
eine Nachricht in der Punkt-zu-Punkt-Domäne empfangen soll, sowie wenn
Nachrichten an alle Subskribenten geliefert worden sind und in der
Veröffentlichungs-/Subskribierungsdomäne sicher
gelöscht
werden dürfen.
Um diese Handlungen auf eine effiziente Weise zur gegebenen Zeit
auszuführen, sollte
nur ein Nachrichtenmanagerknoten im Cluster für die Lieferung der gegebenen
Nachricht verantwortlich sein. Dieser wird als ein Nachrichtenmanager-Hauptknoten
bezeichnet. Alle anderen Nachrichtenmanagerknoten, die dieselbe
Nachricht speichern, sind Backupnachrichtenmanager und spielen eine
passive Rolle ab. Das richtige Systemverhalten wird sichergestellt,
wenn es nur ein Nachrichten-Hauptmanager für einen gegebenen Satz von Nachrichten
jeweils besteht. Also, ein Backupnachrichtenmanager sollte zu einem
Nachrichten-Hauptmanager nur dann werden, wenn es festgestellt worden
ist, dass es kein Nachrichten-Hauptmanager aktuell besteht.
-
Das
Haupt-/Backupschema kann nicht sicherstellen, dass es nur einen
einzelnen Nachrichten-Hauptmanager gibt, wenn das Netz, das Computer
verbindet, aufgeteilt wird. Daraus ergibt sich die Tatsache, dass
die Computer in den Partitionen nicht wissen können, ob die Computer, mit
welchen sie den Kontakt verloren haben, aufgehört haben zu operieren bzw.
in einer anderen Netzpartition Operierung fortsetzen. Diese Erfindung
stellt ein Schema bereit, in welchem jede Netzpartition einen Nachrichten-Hauptmanager
für denselben
Satz von Nachrichten enthalten darf, ohne die Anforderungen der JMS-Spezifikation
zu verletzen sowie ohne Übersendung
von neuen Nachrichten an den Nachrichtenservercluster zu verhindern.
-
Um
jeder Netzpartition zu ermöglichen,
einen Nachrichten-Hauptmanager zu haben, der für denselben Satz von Punkt-zu-Punkt-Nachrichten verantwortlich
ist, wie Nachrichten-Hauptmanager in anderen Partitionen, definieren
wir zwei Arten von Nachrichten-Hauptmanagern für die Punkt-zu-Punkt-Domäne: normal und beschränkt. Ein
normaler Nachrichten-Hauptmanager ist berechtigt, den vollen Bereich
von Funktionen auszuführen, die
mit einem Nachrichten-Hauptmanager für Punkt-zu-Punkt-Nachrichten
verbunden sind. Ein beschränkter
Nachrichten-Hauptmanager ist nicht berechtigt, Punkt-zu-Punkt-Nachrichten
zu erledigen, die gesendet worden waren, bevor der aktuelle Netzausfall
entstanden ist. Es ist genügend,
sicherzustellen, dass es nicht mehr als einen normalen (unbeschränkten) Nachrichten-Hauptmanager
in einem Cluster gibt, um eine richtige JMS-Semantik in der Punkt-zu-Punkt-Domäne zu gewährleisten.
-
Bei
der Veröffentlichungs-/Subskribierungsdomäne ist es
nicht erforderlich, die Lieferung von Nachrichten durch Nachrichten-Hauptmanager
zu beschränken.
Es ist jedoch notwendig, sicherzustellen, dass veröffentlichte/subskribierte
Nachrichten nicht aus den Nachrichtenmanagern gelöscht werden
(ausgenommen wegen Nachrichtenverfallfrist), bis die Netzteilung
bzw. den Computerausfall beseitigt wird, um sicherzustellen, dass
eventuelle benutzende Kunden in anderen Partitionen alle für sie bestimmten
Nachrichten ultimativ empfangen können. Bei diesem Operationsmodus
muss der Nachrichten-Hauptmanager alle veröffentlichte/subskribierten Nachrichten
und deren zugehörigen
Lieferungszustand aufbewahren und wird als einen aufbewahrenden
Nachrichten-Hauptmanager bezeichnet. Es ist zu beachten, dass immer,
wenn eine Teilung Nachrichtenmanager aus demselben Untercluster
separiert, alle Nachrichten-Hauptmanager aus diesem Untercluster
beginnen, veröffentlichte/subskribierte Nachrichten
aufzubewahren, während
höchstens
ein normaler Nachrichten-Hauptmanager für Punkt-zu-Punkt-Nachrichten
vorhanden sein kann.
-
Nachdem
die Netzteilung beseitigt ist, müssen
zahlreiche Nachrichten-Hauptmanager, die vorher in unterschiedlichen
Partitionen separiert waren, ihre Zustände synchronisieren, sodass
alle aktualisiert sind, um die Aktivitäten, die in anderen Partitionen
ausgeführt
worden waren, zu widerspiegeln. Dann müssen alle Nachrichten-Hauptmanager,
ausgenommen eines, zur Rolle des Backupnachrichtenmanagers zurückkehren
und der einzelne, aufbewahrende Nachrichten-Hauptmanager übernimmt die volle Verantwortlichkeit
für Nachrichten
von diesem Untercluster.
-
Um
zuverlässig
zu bestimmen, wenn ein Ausfall aufgetreten ist und über welches
Funktionalitätsniveau
der Nachrichten-Hauptmanager in einer partikulären Partition verfügen kann
(normal, aufbewahrend bzw. aufbewahrend beschränkt), müssen folgende Informationen
für alle
Knoten zugänglich sein:
- – Clusterkonfiguration:
Das ist die Konfiguration des Clusters, die von dem Systemverwalter
definiert worden ist. Sie enthält
die komplette Beschreibung, welche Knoten vorhanden sein können, welcher
Art sie sind (Kundenmanager bzw. Nachrichtenmanager), wie diese
in Untercluster gruppiert sind sowie auf welchen Computer sie betrieben
werden sollten. Die Konfiguration ist gewöhnlich ganze Zeit dieselbe
für alle
Knoten.
- – Netzsichtfeld
(Sichtfeld): Das ist eine Liste von Computern, die über den
Multicast-Nachrichtenbus
erreichbar sind. Wenn kein Ausfall vorhanden ist, besitzen alle
Computer dasselbe Sichtfeld und dieses sollte mit der Clusterkonfiguration übereinstimmend
sein. Wenn ein Ausfall aufgetreten ist, dann ist das Sichtfeld mit
der Clusterkonfiguration nicht übereinstimmend.
Wenn der Ausfall durch die Netzteilung verursacht worden ist, dann
besitzen die Computer innerhalb jeder Partition dasselbe Sichtfeld,
aber das Sichtfeld ist natürlich
unterschiedlich in jeder Partition.
-
Die
Erfindung verwendet ein diskretes Zustandmodell, um zu bestimmen,
ob der Nachrichten-Hauptmanager in einem partikulären Untercluster
aufbewahrend und/oder beschränkt
sein sollte. Dieser Partitionszustand hat vier mögliche Werte, welche mit den
Buchstaben A, B, C und D kennzeichnet werden. Jederzeit, wenn eine Änderung
des Sichtfelds auftritt, wird der Zustand des Knotens auf Basis
von der Anzahl und dem vorherigen Partitionszustand von Kundenmanagern
und Nachrichtenmanagern hinsichtlich sowohl des neuen Netzsichtfelds, als
auch der beabsichtigen Clusterkonfiguration neu evaluiert. Zustand
A repräsentiert
den normalen Betrieb mit keinen Ausfällen bzw. nur mit Ausfällen von Kundenmanagern.
Im Zustand B und C ist der Nachrichten-Hauptmanager „aufbewahrend", aber nicht „beschränkt". Im Zustand D ist
der Nachrichten-Hauptmanager „aufbewahrend" und „beschränkt". Das Zustandmodell
ermöglicht
sowohl einen hohen Grad des kontinuierlichen Betriebs, als auch
gewährleistet
die JMS-Konformität, sogar
wenn zahlreiche, sukzessive, komplexe Netzteilungen auftreten.
-
Bei
veröffentlichten/subskribierten
Nachrichten wird der aufbewahrende Nachrichten-Hauptmanager fast wie ein normaler Nachrichten-Hauptmanager
funktionieren. Der einzelne Unterschied beruht darauf, dass der
aufbewahrende Nachrichten-Hauptmanager nicht wissen kann, ob es
Subskribenten in anderen Partitionen gibt, die noch eine gegebene Nachricht
nicht empfangen haben, sodass dieser Nachrichten nicht löschen sollte,
bis der Ausfall beseitigt wird und alle Nachrichten-Hauptmanager
für diesen
Untercluster ihren Zustand abstimmen können, ausgenommen im Fall,
dass Nachrichten verfallen, bevor der Ausfall beseitigt wird.
-
Bei
Punkt-zu-Punkt-Nachrichten wird ein beschränkter Nachrichten-Hauptmanager
bei auszuführenden
Handlungen im Vergleich zu einem unbeschränkten Nachrichten-Hauptmanager
mehr limitiert. Ein beschränkter
Nachrichten-Hauptmanager darf einkommende Nachrichten jederzeit
akzeptieren. Er darf aber nur Nachrichten verteilen, die nach der
letzten Änderung
des Sichtfelds empfangen worden sind, weil es dann gewährleistet
ist, dass diese Nachrichten in keiner anderen Partition vorhanden sind.
Da alle Nachrichten, die durch eine einzelne Session hergestellt
worden sind, ordnungsgemäß geliefert
werden müssen,
ist es möglich,
dass Nachrichten, die durch eine Destination empfangen worden sind,
im aktuellen Sichtfeld nach den Nachrichten aus derselben Kundensession,
die während
des vorigen Sichtfelds empfangen worden waren, rangiert werden und
für Verteilung
nicht zugänglich
sind, bis die Teilung beseitigt wird.
-
Die
Erfindung setzt nicht voraus, dass Änderungsereignisse des Sichtfelds
unmittelbar nach der Auftretung des Ausfalls verwirklicht werden.
Es gibt gewöhnlich
eine Zeitverzögerung,
bevor der Sichtfeldsmanager (der Multicast-Nachrichtenbus im Fall der
bevorzugten Implementierung) schließlich bestimmen kann, dass
ein Ausfall aufgetreten ist, ohne exzessive, falsche Alarme zu riskieren.
Es ist möglich,
dass nach der Auftretung der Netzteilung jede Partition den Ausfall
zu einer unterschiedlichen Zeit detektiert. Daraus können sich
gefährliche
Szenarios ergeben, bei welchen eine Partition einen Backupnachrichtenmanager
als einen unbeschränkten Nachrichten-Hauptmanager bereitstellt,
bevor der Nachrichten-Hauptmanager in einer anderen Partition detektiert,
dass er den beschränkten
Betrieb anordnen muss.
-
Um
die Lieferung von doppelten Nachrichten während des Intervalls zwischen
der Auftretung eines Ausfalls und der Änderung des Sichtfelds zu verhindern,
erfolgt eine extra Prüfung
durch den Kundenmanager während
der Absendung. Jederzeit wird eine Nachricht von einem Nachrichtenmanager
an die Kundenmanager für
Absendung gesendet. Jeder Kundenmanager, der die Nachricht empfängt, sendet an
alle anderen Kundenmanager eine Bestätigung, die bestätigt, dass
er die Nachricht gesehen hat. Der Kundenmanager, der aktuell für Weiterleitung
der Nachricht an einen Kundenbenutzer verantwortlich ist, wird die
Nachricht halten, bis er Bestätigungen von
einer Mehrheit der anderen Kundenmanager in demselben Netzsichtfeld
empfängt.
Wenn ein Ausfall aufgetreten ist, der potentiell zur Lieferung von
doppelten Nachrichten führen
kann, bevor die Änderung des
korrespondierenden Sichtfelds festgestellt wird, kann keine Mehrheit
von Bestätigungen
empfangen werden und die Nachricht wird durch den Kundenmanager
zurückgewiesen.
-
Generell
beruht eine wichtige Idee dieser Erfindung darauf, dass im Fall
einer Netzteilung jeder Knoten Partitionszustandinformationen evaluiert.
Es besteht eine wichtige Unterscheidung zwischen zwei operationellen
Zuständen: „beschränkt" und „unbeschränkt". Das hat sicherzustellen,
dass zwei Nachrichtenmanager dieselbe Punkt-zu-Punkt-Nachricht nicht
absenden können.
Also, ein Kriterium ist entstanden, um sicherzustellen, dass bei
zwei Nachrichtenmanagern, die sich gegenseitig nicht „sehen", z.B. nicht fähig sind,
wegen der fehlenden (Hardware- bzw. Software-) Netzverbindung zu
kommunizieren, und für
Absendung von denselben Punkt-zu-Punkt-Nachrichten verantwortlich sind, nur ein
Nachrichtenmanager unbeschränkt
sein kann. Nur Nachrichtenmanager mit dem unbeschränkten Zustand
können
Nachrichten absenden, die geschaffen worden waren, bevor die Netzteilung
aufgetreten ist.
-
Es
gibt unterschiedliche Möglichkeiten,
um ein Kriterium zur Bestimmung festzustellen, ob ein Nachrichtenmanager
in eine Kategorie „beschränkt" oder „unbeschränkt", d.h. in den beschränkten oder unbeschränkten operationellen
Zustand, eingeschlossen werden sollte. Gemäß dem Vierzustandmodell, das
oben erwähnt
ist und im Folgenden ausführlicher
dargestellt wird, beruht das Kriterium darauf, dass der Nachrichtenmanager
den Partitionszustand A, B oder C haben sollte, um den unbeschränkten Zustand
zu haben. Ob einem Server der Partitionszustand A, B oder C zugeschrieben
wird, ist sowohl von der Anzahl und Art von Knoten, die für die Kommunikation
zugänglich
sind, als auch von der Geschichte, d.h. davon, welcher Partitionszustand vorhanden
war, bevor das letzte Sichtfeld geändert worden ist, abhängig.
-
Das
Vierzustandmodell oder seine vereinfachte bzw. sogar mehr komplizierte
Version kann sowohl bei Architekturen mit zwei unterschiedlichen Knotenarten,
d.h. Nachrichtenmanagern und Kundenmanagern, gemäß der oben erwähnten US-amerikanischen
Patentanmeldung, als auch z.B. bei konventionellen Architekturen,
wo jeder Server sowohl als Kundenmanager, als auch als Nachrichtenmanager
agiert, eingesetzt werden. Ein weiteres mögliches Kriterium ist es, z.B.
einen Serverknoten als einen partikulären (Alpha- bzw. Entscheidungs-)Server zu
designieren. Alle Server, die in der Partition des Alphaservers
enthalten sind, sind „unbeschränkt"; alle anderen Server
sind dagegen „beschränkt". Weitere Kriterien
können
Informationen über
partikuläre Kundenverbindungen
etc. benutzen. Es ist jedoch wichtig, dass immer nur eine Partition
unbeschränkt sein
darf.
-
Eine
zweite, wichtige Unterscheidung ist zwischen zwei operationellen
Zuständen
zu machen: aufbewahrend und nicht aufbewahrend. Gemäß dem Vierzustandmodell
hat ein Nachrichtenmanager den „nicht aufbewahrenden" operationellen Zustand, wenn
er den Partitionszustand A hat, sonst hat er den „aufbewahrenden" operationellen Zustand.
Gemäß diesem
Modell wird der Zustand A erreicht, wenn alle Nachrichtenmanager
innerhalb des Unterclusters zugänglich
sind und wenn wenigstens ein Kundenmanager zugänglich ist.
-
Bei
einer speziellen Ausführungsform
können
eventuell weitere Partitionszuständen
in Abhängigkeit
von der Anzahl von zugänglichen
Nachrichtenserverknoten entstehen. Diese Ausführungsform wird auch unter
Bezugnahme von dem erwähnten Vierzustandmodell
erklärt.
-
Diese
Erfindung wird durch den Wunsch motiviert, eine Methode zu erhalten,
die die JMS-Semantik
während
einer Netzteilung bzw. eines Knotenausfalls gewährleistet, in Betracht dessen,
dass diese zwei Ereignisse durch einen Server des Clusters nicht
unterschieden werden können.
Die Erfindung eignet sich jedoch auch dafür, um den richtigen Betrieb
zu gewährleisten,
falls ein Netz eine differente Middleware, insbesondere eine nachrichtenorientierte
Middleware, einsetzt. Der Fachmann erkennt sofort, dass das Konzept
dieser Erfindung nicht auf einer spezifischen Computersoftware bzw.
Computersprache basiert, aber eher sich auf Netzarchitekturen als
solche bezieht.
-
KURZBESCHREIBUNG
VON ABBILDUNGEN
-
1 zeigt
ein Nachrichtenübertragungsclustersystem.
-
2 schildert
ein Partitionszustand-Übergangsdiagramm,
bestehend aus Knoten und unidirektionalen Pfeilen, die Knoten zusammen
verbinden.
-
3 zeigt
ein Nachrichtenübertragungsclustersystem
nach der Auftretung einer Netzteilung.
-
4 schildert
die Ausführung
einer einfachen Transaktion in einem Nachrichtenübertragungsclustersystem.
-
5 schildert
die Ausführung
einer Transaktion im Zeitablauf.
-
BESCHREIBUNG
VON BEVORZUGTEN AUSFÜHRUNGSFORMEN
-
Im
Folgenden sind bevorzugte Ausführungsformen
der Erfindung unter Bezugnahme von Abbildungen beschrieben.
-
Der
in 1 dargestellte Cluster enthält zwei Untercluster 1 und
2, die jeweils drei Nachrichtenmanager MM (Message Managers) und
fünf Kundenmanager
CM (Client Managers) enthalten. Jeder der fünf Kundenmanager verfügt über eine
Anzahl von verbundenen Kunden. In jedem der Untercluster gibt es
einen Nachrichten-Hauptmanager und zwei Backupnachrichtenmanager.
Die Abbildung zeigt, wie die Knoten (Kundenmanager und Nachrichtenmanager)
auf einem clusterweiten Nachrichtenbus verbunden sind.
-
Gemäß dem Modell,
das in der 2 dargestellt ist, werden vier
unterschiedliche, durch Knoten repräsentierte Zustände A, B,
C und D vorausgesetzt. Jeder Knoten repräsentiert einen Partitionszustand
und dieser Partitionszustand wird für jeden Untercluster in jeder
Netzpartition unabhängig
bestimmt. Unidirektionale Pfeile repräsentieren ein Ereignis, das
sich aus dem Übergang
von einem Partitionszustand zu einem anderem ergibt. Übergänge treten
als ein Ergebnis von Änderungen
des Sichtfelds auf. Im Folgenden wird jedes der Ereignisse, die zu
einem Übergang
von einem Partitionszustand zu einem anderem (oder zu demselben)
Zustand führen,
beschrieben:
- – Spitze aa – Alle Nachrichtenmanager
innerhalb desselben Unterclusters bleiben zugänglich sowie ein oder mehrere
Kundenmanager sind für diese
Nachrichtenmanager zugänglich.
- – Spitze
ab – Alle
Nachrichtenmanager innerhalb des Unterclusters, ausgenommen eines,
werden unzugänglich
und eine Mehrheit von Kundenmanagern ist für den verbleibenden Nachrichtenmanager
zugänglich.
- – Spitze
ba – Alle
anderen Nachrichtenmanager innerhalb desselben Unterclusters sind
zugänglich
geworden sowie ein oder mehrere Kundenmanager sind für diese
Nachrichtenmanager zugänglich.
- – Spitze
bd – Ein
oder mehrere, aber nicht alle Nachrichtenmanager aus demselben Untercluster,
die aktuell den Partitionszustand D haben, sind zusammen mit dem
einzelnen Nachrichtenmanager aus diesem Untercluster (welcher vorher den
Partitionszustand B hatte), der bereits in dieser Partition war,
in dieser Partition zugänglich
geworden sowie ein oder mehrere Kundenmanager sind für diese
Nachrichtenmanager zugänglich.
- – Spitze
bb – Der
einzelne Nachrichtenmanager aus diesem Untercluster (welcher vorher
den Partitionszustand D hatte), der bereits in dieser Partition
war, bleibt der einzige Nachrichtenmanager aus diesem Untercluster,
der in dieser Partition zugänglich
ist, sowie ein oder mehrere Kundenmanager sind für diesen Nachrichtenmanager
zugänglich.
- – Spitze
ac – Zwei
oder mehrere, aber nicht alle Nachrichtenmanager aus diesem Untercluster bleiben
zugänglich
sowie eine Mehrheit von Kundenmanagern ist für diese Nachrichtenmanager zugänglich.
- – Spitze
ca – Alle
anderen Nachrichtenmanager innerhalb desselben Unterclusters sind
zugänglich
geworden sowie ein oder mehrere Kundenmanager sind für diese
Nachrichtenmanager zugänglich.
- – Spitze
cb – Alle
Nachrichtenmanager innerhalb des Unterclusters, ausgenommen eines,
sind unzugänglich
geworden sowie eine Mehrheit von Kundenmanagern ist für den verbleibenden
Nachrichtenmanager zugänglich.
- – Spitze
cc – Zwei
oder mehrere Nachrichtenmanager aus diesem Untercluster bleiben
zugänglich,
eine Mehrheit von Kundenmanagern bleibt für diese Nachrichtenmanager
zugänglich
sowie wenigstens ein Nachrichtenmanager aus diesem Untercluster
bleibt unzugänglich.
- – Spitze
cd – Eine
Mehrheit von Kundenmanagern ist unzugänglich geworden sowie wenigstens
ein Nachrichtenmanager aus diesem Untercluster bleibt unzugänglich oder
andere, aber nicht alle Nachrichtenmanager aus demselben Untercluster,
die aktuell den Partitionszustand D haben, sind zugänglich geworden.
- – Spitze
ad – Eine
Mehrheit von Kundenmanagern ist unzugänglich geworden sowie wenigstens
ein Nachrichtenmanager aus diesem Untercluster ist unzugänglich geworden.
- – Spitze
da – Alle
Nachrichtenmanager sind innerhalb des Unterclusters zugänglich sowie
ein oder mehrere Kundenmanager sind für diese Nachrichtenmanager
zugänglich.
- – Spitze
dd – Wenigstens
ein Nachrichtenmanager aus diesem Untercluster bleibt unzugänglich.
-
Wie
in der Abbildung dargestellt, kann eine Partition, die Nachrichtenmanager
und Kundenmanager enthält,
die den Partitionszustand A, B bzw. C haben, über einen Nachrichten-Hauptmanager verfügen, der
im „unbeschränkten" Modus in Bezug auf Punkt-zu-Punkt-Nachrichten operiert
und normal Punkt-zu-Punkt-Nachrichten absenden darf. Anderseits
operiert ein Nachrichten-Hauptmanager beim Partitionszustand D in
Bezug auf Punkt-zu-Punkt-Nachrichten im „beschränkten" Modus. Hinsichtlich veröffentlichter/subskribierter
Nachrichten operiert der Nachrichten-Hauptmanager im „nicht
aufbewahrenden" Modus
und kann beim Partitionszustand A normal betrieben werden. Beim
Partitionszustand B, C und D operiert der Nachrichten-Hauptmanager im „aufbewahrenden" Modus und darf Nachrichten
nicht löschen,
bevor diese verfallen.
-
Bei
jeder Netzteilung wird eine Partition in den Partitionszustand B
oder C und alle anderen Partitionen in den Partitionszustand D gebracht.
Um aus dem Partitionszustand D zurückgezogen zu werden, müssen alle
Nachrichtenmanager innerhalb derselben Partition zugänglich sen.
Also, nur eine Partition kann den Partitionszustand B oder C jederzeit
haben.
-
Gemäß einer
weiteren, vereinfachten Ausführungsform
der Erfindung darf ein Dreizustandmodell, das Zustände A, C
und D kombiniert, eingesetzt werden. Analogisch zu dem obigen Modell
wird dem Nachrichtenmanager ein „unbeschränkter" operationeller Zustand zugeschrieben,
wenn dieser den Partitionszustand A oder C hat, und ein „beschränkter" operationeller Zustand,
wenn dieser den Partitionszustand D hat. Dem Nachrichtenmanager
wird auch ein „nicht
aufbewahrender" operationeller
Zustand zugeschrieben, wenn dieser den Partitionszustand A hat,
und ein „aufbewahrender" operationeller Zustand
in sonstigen Fällen.
Gemäß diesem
vereinfachten Modell entscheidet nur die Anzahl und Art von Knoten,
die für
die Kommunikation zugänglich sind,
welcher Partitionszustand einem Server zugeschrieben wird, und nicht
seine „Geschichte":
- – Zustand
A: alle Nachrichtenmanager innerhalb des Unterclusters sind zugänglich.
- – Zustand
C: nicht alle Nachrichtenmanager innerhalb des Unterclusters sind
zugänglich,
eine Mehrheit von Kundenmanagern ist zugänglich.
- – Zustand
D: nicht alle Nachrichtenmanager innerhalb des Unterclusters sind
zugänglich
sowie nicht eine Mehrheit von Kundenmanagern ist zugänglich.
-
Auch
dieses vereinfachte Modell stellt die JMS-Semantik sicher. Das Vierzustandmodell
enthält jedoch
im Vergleich dazu mehr Situationen (siehe Spitze bb), wo dem Server
ein „unbeschränkter" operationeller Zustand
zugeschrieben wird.
-
Das
ultimative Ziel des Vierzustandmodells oder dessen mehr komplizierten
bzw. einfacheren Versionen ist die Fähigkeit, den Fall von zahlreichen, sukzessiven
Netzteilungen zu behandeln. Das kann der Fall sein, wenn ein unerfahrener
Techniker unrichtig versucht, die originelle Partition zu reparieren, oder
wenn die Firmware in einem Switch verrückt wird und beginnt, Computer
wahllos zu segregieren. Das Zustandmodell stellt einen sehr hohen
Grad der Zuverlässigkeit
bereit und verhütet,
dass das System nicht durch einen totalen Ausfall gefährdet wird, nachdem
die erste Teilung aufgetreten ist.
-
Analogisch
zu dem in der 1 dargestellten Cluster enthält der Cluster
aus der 3 zwei Untercluster 1 und 2,
die jeweils drei Nachrichtenmanager und fünf Kundenmanager enthalten.
Jeder der fünf
Kundenmanager verfügt über eine
Anzahl von verbundenen Kunden.
-
Die
Abbildung zeigt, wie infolge einer Netzteilung die Untercluster
aufgeteilt sind, sodass der Untercluster 1 durch die Teilung nicht
beeinträchtigt ist,
ausgenommen der Tatsache, dass zwei Kundenmanager unzugänglich sind.
Die Knoten im Untercluster 1 haben stets den Partitionszustand A.
Anderseits ist der Untercluster 2 auf solche Weise aufgeteilt geworden,
dass der Nachrichten-Hauptmanager
von seinen Backupnachrichtenmanagern abgetrennt worden war. Der
originelle Nachrichten-Hauptmanager residiert innerhalb der Partition,
die über
eine Mehrheit von Kundenmanagern verfügt, während die andere zwei Nachrichtenmanager über eine
Minderheit von Kundenmanagern verfügen. In Abwesenheit von einem
Nachrichten-Hauptmanager hat die Partition des Unterclusters 2,
der originell zwei Backupnachrichtenmanager hat, einen der Backupnachrichtenmanager
zu einem Nachrichten-Hauptmanager promoviert.
-
Dieser
neue Nachrichten-Hauptmanager hat jedoch den Partitionszustand D
und ist damit „beschränkt" und „aufbewahrend". Der originelle
Nachrichten-Hauptmanager hat den Partitionszustand B und ist „aufbewahrend".
-
4 schildert
die Ausführung
einer einfachen Transaktion in einem Nachrichtenübertragungsclustersystem. Wie
gesehen, umfasst die Transaktion zwei Untercluster, die durch Grautönung kenntlich gemacht
sind, und besteht aus einer Nachricht, die gesendet wird, und einer
Nachricht, die empfangen wird.
-
In
der 4 hat ein Kunde, der mit dem Kundenmanager verbunden
ist, eine Transaktionssession geschaffen. Der Kundenmanager agiert
als ein Transaktionsmanager. Der Kunde sendet dann eine Nachricht,
deren Destination sich im Untercluster 1 befindet, und empfängt eine
Nachricht, die in einer Destination im Untercluster 2 lokalisiert
ist. Der Kunde beantragt dann die Abwicklung der Transaktion, welche
der Transaktionsmanager über
den Multicastbus „multicastet", und erhält das Ergebnis
dieser Operation zurück.
-
5 schildert
die Ausführung
einer Transaktion im Zeitablauf. Die Nachrichten von einer Transaktion
schließen
Nachrichten ein, die in einer Transaktionssession ab dem letzten
Abbruch/der letzten Abwicklung gesendet bzw. empfangen worden sind.
Wie in der Abbildung dargestellt, umfasst die Transaktion drei Nachrichtenoperationen – die Seindung
einer Nachricht und der Empfang von zwei Nachrichten – sowie
eine Abwicklung.
-
Weder
verhindert die Erfindung die Auftretung von Knotenausfällen und
Netzteilungen, noch beseitigt diese. Stattdessen erkennt die Erfindung an,
dass diese Ereignisse möglich
sind, und präsentiert
eine Lösung,
die ermöglicht,
dass der Cluster stets fähig
ist, die JMS-Semantik sogar während
der Periode nach der Auftretung von solchen Ereignissen zu gewährleisten,
bevor diese beseitigt werden. Das wird dadurch gemacht, dass allen
Kundenmanagern und Nachrichtenmanagern, und damit der ganzen Partition,
ermöglicht
wird, zu detektieren und zu identifizieren, wenn ein Cluster (bzw.
eine Partition) in der Situation ist, wo die Ausführung von
bestimmten Operationen zu einem Bruch in der JMS-Semantik führen könnte. Insbesondere,
wenn solche Situation detektiert und identifiziert worden ist, ist
jeder Knoten fähig
zu konkludieren, ob eine gegebene Operation – in Bezug auf die Granularität von Nachrichten – dazu führen könnte, dass
die JMS-Semantik verletzt wird, und hält also mit der Ausführung der
Operation zurück,
bis diese semantisch sicher ist, um gemacht zu werden.
-
Die
Erfindung unterstützt
den richtigen Betrieb, wenn der Cluster gleichzeitig in eine Anzahl
von Netzpartitionen zersplittert. Die Erfindung setzt jedoch voraus,
dass der Cluster auf solche Weise konfiguriert ist, dass alle Kundenmanager
niemals von allen Nachrichtenmanagern abgetrennt werden können. Die
Konsequenz davon wäre
es, dass der Cluster stoppen würde,
zu funktionieren. Das kann einfach durch gemeinsame Lokalisierung
von Kundenmanagern und Nachrichtenmanagern auf denselben Maschinen
gewährleistet
werden.
-
Die
Erfindung unterstützt
auch die Unterclusterabstraktion, was bedeutet, dass der Cluster über einen
oder mehrere Untercluster verfügen
kann, die jeweils einen Nachrichten-Hauptmanager und keinen oder
mehrere Backupnachrichtenmanager enthalten. Jeder Untercluster ist
für Lieferung von
einem disjunkten Untersatz von Nachrichten verantwortlich, wie es
durch die Lastausgleichslogik bestimmt wird. Wenn ein Nachrichten-Hauptmanager
sowie alle seine Backupnachrichtenmanager in einem einzelnen Untercluster
lokalisiert sind, werden Knotenausfälle und Netzteilungen in jedem
Untercluster getrennt behandelt. Der Fall, in welchem sich die Verantwortlichkeit
für Nachrichten
nicht über
zahlreiche Untercluster erstreckt und alle Nachrichten durch einen
einzelnen Cluster von Nachrichtenmanagern behandelt werden, ist
ein besonderer Fall der Unterclusterabstraktion, in welchem die
Anzahl von Unterclustern gleich eins ist.
-
Endlich
unterstützt
die Erfindung den Transaktionsprozess, d.h. die atomare Ausführung von zahlreichen
Nachrichtenoperationen (Senden/Empfangen), und gewährleistet
die JMS-Semantik sogar während
Knotenausfälle
und Netzteilungen bei der Ausführung
von Transaktionen.
-
Die
Erfindung beruht darauf, dass jeder Kundenmanager und Nachrichtenmanager
in einem Cluster fähig
ist, den Zustand des Clusters (oder einer Partition) zu detektieren
und zu identifizieren, dadurch dass verschiedene Zustandinformationen
gehalten werden. Diese Zustandinformationen werden benutzt, um jeden
Knoten mit dem erwarteten und dem aktuellen Zustand des Clusters
bekanntzumachen, was ein wichtiger Aspekt ist, um die Knoten darauf
hinzuweisen, wenn semantische Fehler potentiell auftreten können, und
ihnen zu ermöglichen, die
Verletzung der JMS-Semantik zu verhindern. Es gibt folgende, für die Erfindung
relevante Zustände, die
von den Kundenmanagern und Nachrichtenmanagern aufbewahrt werden:
- – Konfigurationszustand – definiert,
wie der Cluster konfiguriert ist, d.h. wie viel Kundenmanager und
Nachrichtenmanager es gibt, sowie definiert die Gruppierung in die
Untercluster, welche der Verwalter im Rahmen des ganzen Clusters
konfiguriert hat. Jederzeit, wenn der Verwalter einen Knoten addiert
oder einen Knoten aus dem Cluster entfernt, ändert sich der Zustand. Der
Zustand, der Informationen über
Kundenmanager, Nachrichtenmanager und deren Gruppierung in einen oder
mehrere Untercluster enthält,
wird durch eine Zustandssequenzzahl identifiziert, welche jederzeit
zunimmt, wenn der Zustand aktualisiert wird. Um richtig im Cluster
funktionieren, müssen die
Knoten über
ein konsistentes Sichtfeld von dem Konfigurationszustand verfügen. Um
das höchste
Niveau der Flexibilität
durch Ermöglichung
dem Verwalter, den Zustand während
Knotenausfälle
und/oder Netzteilungen zu ändern, und
gleichzeitig die Konsistenz bei Knoten sicherzustellen, wird einen
Mehrheitsgrundsatz angewendet, wenn sich der Zustand ändert. Der
Mehrheitsgrundsatz erlaubt dem Verwalter, den Konfigurationszustand
zu ändern, insoweit
eine Mehrheit von Knoten zugänglich
ist. Knoten, die unzugänglich
sind, wenn der Verwalter den Konfigurationszustand ändert, sind
damit inkonsistent und werden aktualisiert, wenn sie mit dem Rest
des Clusters abgestimmt werden.
- – Sichtfeldzustand – definiert
das aktuelle Sichtfeld des Clusters, wie dieses aus der grundlegenden
Multicast-Ebene gesehen wird, d.h. wie der Cluster aktuell in Bezug
auf Kundenmanager und Nachrichtenmanager sowie die Gruppierung in die
Untercluster erscheint. Im Gegensatz zu dem Konfigurationszustand
enthält
der Sichtfeldszustand jedes Knotens nur diese Knoten, die aktuell für den Knoten über die
Multicast-Schicht erreichbar sind. Der Zustand wird durch eine Zustandssequenzzahl
identifiziert, welche eine Datenstruktur repräsentiert, die Informationen über Kundenmanager,
Nachrichtenmanager und die Gruppierung in die Untercluster innerhalb
des Sichtfelds enthält.
Weil zwei Partitionen die gleiche Zustandssequenzzahl haben dürfen, aber
der Kontext von dieser zwei Zustände
unterschiedlich ist, widerspiegelt die Zustandssequenzzahl eine
Datenstruktur eindeutig nicht. Der Zustand ändert sich jederzeit, wenn
ein oder mehrere Knoten zugänglich
bzw. unzugänglich
für den
Cluster werden. Der Sichtfeldszustand ändert sich sowohl infolge Knotenausfälle sowie
Rückgewinnung,
Teilung bzw. Sanierung des Netzes, als auch, wenn der Verwalter
einen Knoten an den Cluster addiert oder aus dem Cluster entfernt,
d.h. wenn er den Konfigurationszustand ändert.
- – Partitionszustand – definiert
die Partition – in
Abhängigkeit
davon, wie der Cluster/Untercluster aktuell gemäß dem Sichtfeldszustand im
Vergleich zu dem Konfigurationszustand erscheint – oder den
ganzen Cluster, wenn keine Ausfälle
aufgetreten sind, in Bezug auf eine Nachricht, deren Behandlung
erlaubt wird. Alle Knoten innerhalb eines Unterclusters haben denselben
Partitionszustand, wenn keine Ausfälle aufgetreten sind. Es kann
eventuell die Inkonsistenz zwischen den Knoten in Bezug auf den
Partitionszustand bestehen, aber das wird aufgelöst, wenn sich ein Sichtfeldszustand ändert, was
zu erfolgen hat, und sich Auslöser
und Knoten miteinander synchronisieren. Während der Konfigurationszustand
und der Sichtfeldszustand über
unendliche Zustandssequenzzahlen verfügen, nimmt der Partitionszustand
einen endlichen Wert A, B, C oder D, der von der Anzahl von Kundenmanagern
sowie Nachrichtenmanagern im aktuellen Sichtfeldszustand im Vergleich
zu dem aktuellen Konfigurationszustand abhängig ist. Eine Änderung
von dem Partitionszustand wird durch eine Änderung im Sichtfeldzustand über die
Multicast-Schicht ausgelöst. Weil
die Kundenmanager mit zahlreichen Unterclustern geteilt werden und
die Kundenmanager brauchen, den Partitionszustand von einem gegebenen
Untercluster zu kennen, bedeutet das, dass die Kundenmanager fähig sein
sollten, zahlreiche Partitionszustände, einen für jeden
Untercluster, der im aktuellen Sichtfeldszustand repräsentiert
wird, aufzubewahren. Der Grund, wofür Kundenmanager brauchen, den
Partitionszustand zu kennen, ist es, dass diese fähig sein
müssen, Nachrichten
im Notfall gegen Sendung durch einen gegebenen Untercluster zu blockieren,
was später
beschrieben wird.
- – Destinationszustand – definiert
den internen Zustand jeder Destination per Nachrichtenmanager, wobei
Nachrichten, die aktuell in der Destination gespeichert sind, mit
ihrer globalen Identifikation, Priorität, Lieferungsmodus, Veröffentlichern,
Lieferungszustand, Schlössern,
Subskriptionsdefinitionen, individuellen Subskriptionszuständen etc. eingeschlossen
werden. Ein Destinationszustand verfügt über keine identifizierende
Sequenzzahl, aber wird durch seine Datenstruktur definiert, die die
oben erwähnten
Informationen repräsentiert.
-
Die
Knoten im Untercluster tauschen die Informationen über den
Zustand während
der Sichtfeldänderungen
aus. Bei so einer Auffassung werden die Zustandskonflikte, d.h.
Situationen wo bei mehreren Knoten verschiedene Konfigurations-,
Sichtfeld-. Partitions- bzw. Zielortszustände vorliegen, während einer
Sichtfeldänderung
erkannt. Ist eine Inkohärenz erkannt
worden, wird sie durch die Zustandssynchronisierung laut nachstehender
Beschreibung beseitigt.
-
Während des
Lebenszyklus eines Clusters/Unterclusters kann sich der Zustand
seiner Partition sowie der Zustand dessen Knoten infolge von Sichtfeldänderungen
je nach Häufigkeit
der Netzteilungen und der Knotenausfälle mehrmals verändern. Diese
Erfindung nutzt den Zustandsmechanismus aus, um mögliche Zustandsübergänge für die Partitionszustände zu definieren.
In der 2 werden die möglichen,
als Knoten vertretenen Partitionszustände sowie die als Spitzen vertretenen
potentiellen Übergangsereignisse
dargestellt. Der Ausgangspunkt für
den Übergangsgraph
ist der Partitionszustand A, wo davon ausgegangen wird, dass alle
Kundenmanager und Nachrichtenmanager anfangs bei dem Systemfunktionsantritt
zugänglich
sind. Wie aus der 2 ersichtlich ist, verfügt die die
Kundenmanager und Nachrichtenmanager enthaltene Partition, welche
sich im Partitionszustand A befinden, über einen Nachrichten-Hauptmanager,
der normal funktioniert. Andererseits kann der Hauptmanager von Nachrichten
in den Partitionszuständen
B, C bzw. D kaum normal funktionieren, weil er:
- – beschränkt in Bezug
auf die Punkt-zu-Punkt-Nachrichten ist; der Hauptmanager ist beschränkt im Artbereich
der Punkt-zu-Punkt-Nachrichten. Der Hauptmanager ist dabei beschränkt im Partitionszustand
und/oder
- – aufbewahrend
in Bezug auf die veröffentlichte/subskribierte
Nachrichten; der Hauptmanager muss die veröffentlichte/subskribierte Nachrichten aufbewahren,
die in anderen Situationen beseitigt wären. Der Hauptmanager ist aufbewahrend
in den Partitionszuständen
B, C und D
-
Die
Semantik des Beschränktseins
und des Aufbewahrendseins wurde nachstehend beschrieben. Taucht
eine beliebige Partition ohne Hauptmanager während der Übergänge zwischen allen Zuständen auf,
wird der Nachrichten-Backupmanager zum neuen – und wahrscheinlich einen
beschränkten/aufbewahrenden – Hauptmanager
erhoben; kommt dagegen eine beliebige Partition vor, die einen ordentlichen
Hauptmanager besitzt, wird dieser zum beschränkten Hauptmanager nach Eintreten des
Partitionszustands D bzw. zum aufbewahrenden Hauptmanager nach Eintreten
der Partitionszustände
B, C bzw. D degradiert.
-
Eine
andere wichtige Beobachtung aus 2 besteht
darin, dass ein Cluster/Untercluster den Partitionszustand D ausschließlich verlassen kann,
indem er in den Partitionszustand A übergeht. Diese Situation kann
nur dann auftreten, wenn alle im Konfigurationszustand definierten
Nachrichtenmanager innerhalb eines Clusters/Unterclusters zugänglich sind,
was wiederum bedeutet, dass sich ein Cluster/Untercluster nach einer
Netzteilung bzw. Knotenausfall völlig
erholen soll. In Zustandskategorien bedeutet es, dass der aktuelle
Sichtfeldzustand des Clusters/Unterclusters in Bezug auf die im
Untercluster gruppierten Nachrichtenmanager mit der vom Verwalter
festgelegten und im Konfigurationszustand dargestellten Konfiguration übereinstimmt.
-
Aus
solcher Kategorisierung des Partitionszustands ergibt sich Folgendes:
Erfolgt eine Netzteilung in zwei trennbaren Partitionen, muss eine
davon den Partitionszustand D, und die andere den Partitionszustand
B, C bzw. D übernehmen.
Für die Übernahme
des Partitionszustands B oder C spricht die Möglichkeit unnötige Beschränkungen
bei weiteren Netzteilungen zu vermeiden. In der 3 ist
ein geteilter Cluster/Untercluster mit bezeichneten Partitionszuständen beispielsweise
dargestellt.
-
Nachstehend
sind Folgen aus dem Bestehen eines beschränkten/aufbewahrenden Hauptmanagers
im Partitionszustands D für
die Warteschlangen- und die thematischen Zielorte dargestellt:
Für die Punkt-zu-Punkt-Zielorte
bedeutet es, dass der beschränkte
Hauptmanager bezüglich
Sendung der Nachrichten beschränkt
ist, die in einem beliebigen vorherigen Sichtfeldzustand empfangen
sind. Stattdessen werden die Punkt-zu-Punkt-Nachrichten gesperrt,
denn es kann sich bei denen um potentielle vervielfältigte Nachrichten
handeln. Dies ergibt sich aus der Tatsache, dass ein anderer, ordentlicher
und dadurch unbeschränkter
Hauptmanager innerhalb einer Netzposition handeln könnte, indem
er möglicherweise
Nachrichten senden würde.
Außer
von Sperrung der in einem beliebigen vorherigen Sichtfeldzustand
empfangenen Punt-zu-Punkt-Nachrichten sperrt der beschränkte Hauptmanager
auch Warteschlangen-Nachrichten, was in der Nachrichtensperrung
am Zielort resultiert, soweit sie derselben Session entstammen.
Auf diese Weise ist eine teilweise Durchordnung der Nachrichten
sichergestellt. Die gesperrten Punkt-zu-Punkt-Nachrichten können solange nicht gesendet
werden, bis sich der Untercluster nach erfolgter Netzteilung bzw.
Knotenausfall soweit erholt hat, dass er in den Partitionszustand
A übergeht.
Sollte
trotzdem der Nachrichtenmanager versuchen, eine wegen Zustandsinkoheränz während der
Netzteilung potentiell vervielfältigende
Nachricht abzusenden, wird dann die Nachricht dem Nachrichtenmanager
vom Kundenmanager mit der Anmerkung zurückgesendet, dass der Hauptmanager
es zu einstellen hat, Nachrichten vom vorherigen Sichtfeldzustand
her zu senden. Solche Nachrichten werden zurückgesendet, weil der empfangende
Kundenmanager es verlangt – als
eine teilweise Prüfmaßnahme gegen
Versendung potentiell vervielfältigender
Nachrichten – eine
Empfangsbestätigung
zu bekommen, die er von den meisten sonstigen Kundenmanagern im
aktuellen Sichtfeldzustand nicht erhalten wird, welcher eine Nachrichtensendung
an den Kunden erlaubt. Er kann niemals eine Empfangsbestätigung von
den meisten sonstigen Kundenmanagern im aktuellen Sichtfeldzustand
bekommen, weil nur eine einzige Partition einen Nachrichtenmanager
enthalten kann, welcher nicht im Zustand D ist. Ist diese Partition
geteilt, kann dann höchstens
eine der sich aus der Teilung ergebenden Partitionen die meisten Kundenmanager
enthalten.
-
Enthält der Zielort
in der Punkt-zu-Punkt-Kommunikation zum Zeitpunkt der Netzteilung
keine zu verarbeitenden Nachrichten, erkennt der „beschränkte" Hauptmanager keine
Einschränkungen
in neuem Sichtfeldzustand. Unter solchen Umständen kann der beschränkte Hauptmanager
weiterhin fungieren, ohne die JMS-Semantik zu brechen.
-
Für die Zielorte
in der Veröffentlicher/Subskribent-Kommunikation
sind die Auswirkungen des aufbewahrenden Hauptmanager-Seins anders,
denn der Begriff Vermeidung der Nachrichtenvervielfältigung
im Bereich Veröffentlicher/Subskribent
keinen Sinn mehr hat. In Bezug darauf werden keine Nachrichten an
Zielorte vom aufbewahrenden Hauptmanager in der Veröffentlicher/Subskribent-Kommunikation
gesperrt. Die Semantikanforderung für die Zielorte in einer Veröffentlicher/Subskribent-Kommunikation
spezifisiert, dass sämtliche
an einen Zielort gesendeten Nachrichten an alle Subskribenten dieses
Zielortes geliefert werden. Zum Zeitpunkt, wo eine veröffentlichte/subskribierte
Nachricht (eine dauerhafte bzw. nicht dauerhafte) an alle interessierten
Subskribenten angeliefert worden ist, kann diese vom Nachrichtenmanager
beseitigt werden. Dies hat ein Problem bei der Netzteilung zur Folge,
denn die Kunden (Subskribent) mit Anschluss an eine Partition können aufgrund
der Aufteilung keine Nachrichten bekommen, die in einer anderen
Partition gesendet wurden. Deswegen ist die Ermittlung kaum möglich, wann
die betreffende veröffentlichte/subskribierte Nachricht
an sämtliche
Subskribent innerhalb des Clusters zugestellt wurde. Um dem abzuhelfen, schlägt die Erfindung
vor, die Beseitigung sämtlicher veröffentlichter/subskribierter
Nachricht in allen Nicht-A-Partitionszuständen einzustellen – es werden
ausschließlich
veröffentlichte/subskribierte Nachricht
im Partitionszustand A beseitigt. Stattdessen werden die veröffentlichten/subskribierten
Nachrichten an Zielorten bis zur Ausbesserung der Netzteilung so
aufbewahrt, dass der gesamte Cluster wieder in den Partitionszustand
A übergeht.
Weil keiner der Hauptmanager, abgesehen von seinem Partitionszustand,
wegen der Netzteilung imstande ist mit allen Subskribenten zu kommunizieren,
müssen
die veröffentlichten/subskribierten
Nachrichten von allen aufbewahrt anstatt zu beseitigt werden. Ausgenommen
davon ist Überfälligkeit
der Nachricht. Die Erfindung setzt voraus, dass eine Überfälligkeit
der Nachricht den Vorrang vor der Lieferung an alle Subskribenten
während
der Knotenausfälle
und Netzteilungen hat, was mit der JMS-Semantik übereinstimmt.
-
Nach
Ausbesserung der Netzteilung schließen sich die Cluster/Untercluster
wieder zusammen, wobei ein Übergang
des Partitionszustands aufgrund der Änderung des Sichtfeldzustands
erfolgt. Eine Sichtfeldzustandsänderung
findet auch dann statt, wenn auf eine Netzteilung unmittelbar die
nächste Teilung
folgt. In beiden Fällen
können
die Knoten verschiedene Konfigurations-, Partitions- und Sichtfeldzustände aufweisen,
trotzdem bleiben diese Zustände
im Partitionsrahmen kohärent.
Voraussetzung für eine
Abstimmung des Konfigurationszustands ist die Knotenmehrheit. Damit
die Netzpartitionen zusammengeschlossen werden können, muss die neue Sequenznummer
des Sichtfeldzustands für
einen geteilten bzw. ungeteilten Cluster/Untercluster zuerst von allen
Knoten im neuen Sichtfeld abgestimmt und festgelegt werden, die
die höchste,
im neuen Sichtfeld gefundene Sequenznummer des Sichtfeldzustands um
1 überragt,
sowie der Datenaufbau des Sichtfeldzustands entsprechend aktualisiert
werden.
-
Nach
erfolgter Aktualisierung des Sichtfeldzustands tauschen alle Knoten
im neuen Sichtfeld die Konfigurations- und Partitionszustände untereinander,
welche sie vor der Sichtfeldänderung
hatten, wie auch Informationen darüber, ob sie Hauptmanager sind
oder nicht. Diese Zustandsmitteilung wird durch eine Nachrichtenveröffentlichung
für den
Empfang durch alle sonstigen Knoten ausgetauscht. Nach Empfang dieser
Nachricht von allen sonstigen Knoten im neuen Sichtfeld aktualisiert
jeder Knoten die ihm vorliegenden Zustandsinfos gemäß folgenden Regeln:
- – Die
höchste
Sequenznummer des Konfigurationszustands unter allen Knoten im Sichtfeldzustand
erhält
den Vorrang vor den niedrigeren Sequenznummern des Konfigurationszustands.
Die Knoten im neuen Sichtfeld eines geteilten bzw. ungeteilten Clusters
stimmen die höchste
Konfigurationszustandnummer unter allen Knoten ab und, soweit erforderlich,
nehmen deren Konfigurationsaktualisierung gemäß dem neuen Konfigurationszustand
vor.
- – Aus
dem aktuellen Partitionszustand sowie dem neuen Sichtfeldzustand,
vergleichbar mit dem Konfigurationszustand ausgehend, wird der Partitionszustand
nach dem Übergangszustandsgraph – siehe 2 – von jedem
Knoten aktualisiert. Dies führt
dazu, dass sämtliche
Knoten im Sichtfeld den gleichen Partitionszustand aufweisen.
-
Sind
diese Zustände
synchronisiert worden, müssen
die Nachrichtenmanager über
geltenden Hauptmanager in jedem Cluster einig werden, in dem eine
Zustandsänderung
eingetreten ist. Aus der veröffentlichten
Information kann jeder Nachrichtenmanager schließen, ob die anderen Nachrichtenmanager
es angeben Hauptmanager zu sein. Gibt keiner der Nachrichtenmanager
an, Hauptmanager innerhalb des Unterclusters zu sein, erhebt sich
der jeweils höchstrangige
Nachrichtenmanager in einem jeden Cluster zum Hauptmanager. Sollten
mehrere Nachrichtenmanager angeben Hauptmanager zu sein, degradieren
sich alle Hauptmanager außer
von dem des höchsten
Grades, wobei die Erfassungsfolge im Cluster für die Gradstufung maßgebend
ist. Während
dieser Aktion überprüft der Hauptmanager, in
welchem Partitionszustand er sich befindet. Sollte der Partitionszustand
B, C bzw. D bei ihm vorliegen, degradiert er sich ausschließlich zu
der Stelle des aufbewahrenden Hauptmanagers und beim Vorliegen des
Partitionszustands D stuft er sich sogar zum beschränkten Hauptmanager
herab.
-
Nach
erfolgter Abstimmung der Hauptmanager-Zuständigkeit in jedem Cluster synchronisieren die
Nachrichtenmanager ihren jeweiligen Zielortzustand, um deren Kohärenz zu
erreichen, d.h. sie tauschen die Infos über die Nachrichten aus, die
in jeder Partition von den Nachrichtenherstellern empfangen bzw.
an die Nachrichtenbenutzer während
der Netzteilung bzw. des Knotenausfalls gesendet werden konnten.
Dies wird nach einem Verfahren durchgeführt, welches auf dem Prinzip
der Antientropie, d.h. durch Abstimmung von zwei Nutzeinheiten – in diesem
Fall von Partitionen – beruht.
Nach erfolgter Zustandssynchronisierung der Zielorte beurteilt der Hauptmanager
in jedem Cluster, ob irgendwelche Warteschlangen- bzw. thematische
Nachrichten vorliegen, die gesendet werden müssen. Der Hauptmanager in jedem
Cluster beurteilt auch, ob irgendwelche gesperrte Nachrichten vorliegen
und ob diese gesendet worden sind oder nicht und schließlich ob sie
jetzt gesendet werden können.
Zum Schluss beurteilt der Hauptmanager in jedem Cluster, ob thematische
Nachrichten vorliegen, die bereits beseitigt werden können.
-
Die
Knotenzustände
und deren deterministisches Verhalten schafft solide Grundlagen
dafür, dass
die Funktion Nachrichtenlieferung auch während der Knotenausfälle bzw.
Netzteilungen auf eine semantisch richtige Art und Weise umgesetzt
werden kann. Damit dies jedoch erfolgreich wird, ist ein System
der Nachrichtenlieferung anzunehmen und zu verwenden.
-
Im
Allgemeinen erfolgt die Nachrichtenübermittlung auf dem Prinzip,
dass die Nachricht an denjenigen Kundenmanager vom Kunden abgesendet wird,
mit welchen er verbunden ist. Ist die Nachricht empfangen worden,
wird sie mit der laufenden Sequenznummer des Sichtfeldzustands vom
Kundenmanager gekennzeichnet. Zweck dieses Merkers ist, die während eines
bestimmten Sichtfeldzustands empfangenen sowie die während eines
anderen Sichtfeldzustands abgesendeten Nachrichten identifizieren
zu können.
Genau genommen handelt es sich dabei um potentiell sich vervielfältigende
Nachrichten, weil die Hauptmanager in beiden Netzpartitionen nach
einer Sichtfeldänderung
aufgrund Netzteilung immer es versuchen werden dieselbe Nachricht abzusenden,
indem sie davon ausgehen jeweils der einzige Sender zu sein. So
kann man durch die Kennzeichnung der Nachrichten es möglich machen diese
zu identifizieren und deren Vervielfältigung zu verhindern.
-
Danach
sendet der Kundenmanager die Nachricht an ihren Zielort, d.h. an
eine Warteschlange bzw. eine thematische Gruppe in den Nachrichtenmanagern
ab. Sämtliche Kundenmanager
kennen alle möglichen
Zielorte, so stempeln sie die Nachricht mit dem gewählten Zielort
ab, bevor sie diese an die Sendeschicht des Unterclusters versenden.
Ist die Nachricht empfangen worden, wird der Empfang der Nachricht
ausschließlich
vom Hauptmanager bestätigt.
Die Backup-Nachrichtenmanager geben keine Bestätigung ab, sie horchen dagegen,
ob der Hauptmanager den Empfang bestätigt hat. Hat dies erfolgt, erfassen
die Backupmanager diese Tatsache. Dies ist dann von Nutzen, wenn
der Hauptmanager nach dem Nachrichtempfang, jedoch noch vor deren
Bestätigung
nicht erreichbar wurde; so kann der neue Hauptmanager wissen, ob
die Nachricht doch noch einer Bestätigung für den Kundenmanager bedarf bzw.
nicht mehr. Nach Erhalt der Empfangsbestätigung der Nachricht bestätigt der
Kundenmanager den Empfang dem Kunden und löscht diese vom Speicher.
-
Der
Hauptmanager wählt
dann den einzelnen Kunden, der eine Warteschlangen-Nachricht bekommen
soll bzw. mehrere Kunden für
die betreffende thematische Nachricht. Ist diese Tätigkeit
vollzogen, wird die Nachricht mit der Session-ID-Nummer vom Hauptmanager
gestempelt und dann an den Unterclusterkanal gesendet, damit die
Kundenmanager und die Nachrichtenmanager diese bekommen können. Ist
die Nachricht gesendet worden, bekommen alle Nachrichtenmanager
(Haupt- und Backup-Manager) die vom Hauptmanager gesendete Nachricht und
dann wird bei allen registriert, dass die Nachricht vom Hauptmanager
gesendet wurde. Noch bevor der Kundenmanager die tatsächliche
Nachrichtensendung an den Kunden durchführt, muss er die Bestätigungen
von den meisten Kundenmanagern im aktuellen Sichtfeldzustand bekommen.
Jeder Kundenmanager, der die Nachricht zum Senden bekommen hat – einschließlich des
für die
tatsächliche
Veröffentlichung
verantwortlichen – bestätigt den
Empfang durch Signalveröffentlichung
an die Sendeschicht des Unterclusters. Die Bestätigung durch den für die Nachrichtsendung
verantwortlichen Kundenmanager wird von allen Nachrichtenmanagern
empfangen und erfasst. Hat der verantwortliche Kundenmanager die meisten
Bestätigungen
von den sonstigen Kundenmanagern- mit Berücksichtigung seiner eigenen
Bestätigung – empfangen,
wird die Nachricht an den Kunden gesendet und der Kundenmanager
wird nunmehr auf die Bestätigung
vom Kunden warten. So ein Bestätigungsablauf
wurde dazu verwendet, damit die Nachricht nicht an die Partition
mit der Minderheit der Kundenmanager im aktuellen Sichtfeldzustand,
auch vor dessen Änderung,
gesendet wird.
-
Nach
Erhalt der Kundenbestätigung
wird die Bestätigung
vom Kundenmanager an die Sendeschicht veröffentlicht, damit sie von allen
Kundenmanagern im Untercluster empfangen werden kann. Dann erfassen
die Nachrichtenmanager und die sendenden Kundenmanager die Tatsache,
dass die Nachricht vom Kunden empfangen worden ist, sie markieren
auch die Nachricht für
deren Beseitigung.
-
Ist
die Kundensession zum Zeitpunkt der Nachrichtsendung durch den Hauptmanager
beim Kundenmanager nicht mehr erreichbar, wird diese vom Kundenmanager
mit entsprechender Mitteilung zurückgesendet, was darin resultiert,
dass die Nachrichtenmanager die Kennzeichnung der Nachrichtensendung
an den Kundenmanager zurücknehmen, wonach
diese – bei
einer Punkt-zu-Punkt-Nachricht – erneut
versendet werden kann; bei einer unbeständigen veröffentlichten/subskribierten
Nachricht wird die Nachricht von den Kundenmanagern mit der Anweisung
schlicht zurückgeschickt,
diese an einen bestimmten Kunden nicht mehr zu senden; keine zusätzliche
Handlung wird vorgenommen. Bei beständigen [fixen) Subskribenten
wird die Nachricht samt Mitteilung zurückgesendet, dass die Nachricht
vom Kunden nicht empfangen wurde, so müsse sie mindestens bis zum
Zeitpunkt der erneuten Verbindung des unbeständigen Subskribenten mit dem
Nachrichtenservercluster aufbewahrt werden.
-
Aus
verschiedenen Gründen
können
die Zielorte jederzeit Nachrichten aus einer bestimmten Kundensession
reihenfolgewidrig bekommen. Einer der Gründe kann z.B. darin bestehen,
dass die Session eine bzw. mehrere Nachrichten aus der Kundensession
verliert. In einem Sonderfall könnte
die Empfangsanmeldung einer Nachricht mit der Sequenznummer X+10
an den Zielort gesendet werden, während noch nicht alle vorherigen
Nachrichten dort angelangt sind. So eine Situation wäre nur auf
einen Clusterausfall zurückzuführen, währenddessen
der über
den Bestimmungsort in einem Untercluster informierende Kunde versetzt
wurde, um über
denselben Bestimmungsort in einem anderen Untercluster zu informieren.
Dies könnte
möglicherweise
zu einer reihenfolgewidrigen Lieferung führen, falls der Hauptmanager
die für
einen Zielort in einem Untercluster bestimmte Nachricht X+10 an
den Kunden senden würde,
noch bevor der Hauptmanager die für denselben Zielort in einem
anderen Untercluster bestimmte Nachricht X+9 gesendet hat.
-
So
ein Vorfall kann dann auftreten, wenn der Kunde die Verbindung mit
demjenigen Kundenmanager verloren hat, über welchen er Nachrichten
für die Zielorte
hergestellt hat, worauf er wieder mit dem Cluster von einem anderen
Kundenmanager verbunden wird. Normalerweise ist das unproblematisch, weil
der neue Kundenmanager aufgrund der Anforderung einer neuen Verbindung
durchaus feststellen kann, über
welchen Untercluster der Kunde an den Zielort gesendet hat. Dabei
besteht jedoch die Gefahr einer semantischen Unstimmigkeit, vorausgesetzt der
Cluster/Untercluster ist geteilt worden und der neue als Zugriffstelle
zum Cluster/Untercluster benutzte Kundenmanager befindet sich in
einer anderen Partition als der vorherige Kundenmanager. Das Problem
besteht darin, dass die Nachrichtenlieferung innerhalb einer Session
als teilweise geordnet gehalten werden muss. Dies ergibt sich aus
der Tatsache, dass der Zielort in mehrere Untercluster eingeteilt werden
kann, wobei jeder davon eine Teilmenge der gesamten Nachrichtenmenge
enthält,
so würden
die Kundensessionen bei einem Ausfall an denselben Zielort in verschiedenen
Unterclustern senden.
-
Aus
der Kundenanforderung einer Neuverbindung kann man schließen, dass
der Kunde seine Nachrichten an einen anderen Untercluster vorab
gesendet hat. Trifft dies zu, versucht der Kundenmanager den Kunden
mit dem vorherigen Untercluster zu verbinden, um jegliche Semantikprobleme
zu vermeiden. Sollte dies nicht möglich sein, wird der Kundenmanager
die Anforderung der erneuten Verbindung akzeptieren und diese an
den Hauptmanager zwecks Beseitigung jeglicher Semantikprobleme weiterleiten.
-
Damit
mögliche
Semantikprobleme beseitigt werden können, ist jede vom Kunden an
den Zielort gesendete Nachricht mit vom Kunden selbst zugeteilten
Identifikationsdaten inkl. Bezeichnung der Session und des Zielortes
sowie mit der Sequenznummer der Nachricht als Kombination von Zielort
und Session versehen und zwar abgesehen davon, ob die Nachricht
einen Teil der einzigartigen Identifikationsdaten darstellt oder
nicht. Aufgrund dieser Informationen beurteilt der Hauptmanager,
ob die Nachrichtenfolge für
einen Zielort Lücken
aufweist. Hat der Hauptmanager erkannt, dass irgendwelche Nachrichten
von der betreffenden Session fehlen, werden die weiteren Nachrichten
gesperrt, d.h. sie werden nicht vor der Synchronisierung der Zielorte
versendet, was in kompletter Nachrichtenfolge sowie richtiger Reihenfolge
am Zielort und demnach der Umsetzung der teilweisen Durchordnung
resultiert.
-
Diese
Erfindung garantiert auch eine semantisch ordnungsmäßige Verarbeitung
von Transaktionen, d.h. atomare Vollziehung mehrmaliger Nachrichtenlieferungen
während
der Netzteilungen und Knotenausfälle.
Die Erfindung unterstützt
die Verarbeitung von Transaktionen, die mehrere Untercluster enthalten
wie aus der Ab. 4 ersichtlich ist. Unter dem Gesichtspunkt der Transaktionsverarbeitung
fungiert der Kundenmanager als Transaktionsmanager, wonach der Kundenmanager,
mit dem der jeweilige Kunde verbunden ist, auch für die Koordinierung
und Durchführung
verschiedener Transaktionsetappen in diversen Unterclustern zuständig ist.
Bei der Erfindung wird der Algorithmus der zweiphasigen Transaktionsdurchführung verwendet.
-
Damit
die Transaktion zustande kommt, muss der Kunde seine zu unterstützende Session spezifizieren.
Dazu muss der Kunde die komplette zu sendende bzw. vom Cluster erhaltene Nachrichtenmenge
zu einem gewissen Zeitpunkt anvertrauen oder abbrechen. Der zweiphasige
Durchführungsvorgang
wird komplett vom Transaktionsmanager im Kundenmanager unterstützt und
ist für
den Kunden transparent. Es gibt keine Anforderung darüber, wie oft
der Kunde eine Transaktion anvertrauen bzw. abbrechen kann. Weil
der Kunde eine Transaktionsfolge mehrmals während der Lebenszyklus anvertrauen bzw.
abbrechen kann, kann theoretisch angenommen werden, dass eine Transaktionssession
mehrfache autonome Transaktionen enthält, die durch Kundenanweisungen
Durchführung/Abbrechung
getrennt werden. Wird eine Transaktion abgebrochen bzw. abgelehnt,
beeinflusst dies keineswegs die vorhergehenden oder die nächsten Transaktionen.
Die 5 zeigt eine Transaktion, die drei Nachrichten sowie
einen innerhalb einer gewissen Zeit umgesetzten Durchführungsbefehl
enthält.
Nachdem die Transaktionssession definiert worden ist, kann der Kunde
eine bestimmte Nachrichtenanzahl an den Transaktionsmanager senden
bzw. Nachrichten empfangen, die vom Hauptmanager über den
Transaktionsmanager gesendet wurden.
-
Zu
einem gewissen Zeitpunkt sendet der Kunde den Durchführungsbefehl
an den Transaktionsmanager. Nach Empfang der Durchführungsforderung
wandelt der Transaktionsmanager diese in einen Bereitstellungsbefehl
um, welcher dann in den an der Transaktion beteiligten Unterclustern
veröffentlicht
wird, worauf der nächste
Durchführungs- bzw.
Abbrechbefehl je nach dem Ergebnis der Bereitstellungsforderung
folgt. Die Bereitstellungsforderung enthält die Identifikationsdaten
aller abgesendeten und empfangenen Nachrichten, die unter die an der
Transaktion beteiligten Untercluster eingeteilt sind. Nach Empfang
der Bereitstellungsforderung prüfen
die Nachrichtenmanager in den beteiligten Unterclustern nach, ob
sie alle Nachrichten empfangen haben, die sie gemäß den in
der Bereitstellungsforderung enthaltenen Nachrichten-ID-Daten zu empfangen
hatten. Falls dies zutrifft, geben die Nachrichtenmanager dem Transaktionsmanager
die positive und falls nicht – die
negative Antwort ab.
-
Sollte
auch nur noch einer der Nachrichtenmanager, sei es der Haupt-, sei
es der Backupmanager, die Bereitstellungsforderung negativ beantwortet haben,
bricht der Transaktionsmanager die Transaktion ab, indem er entsprechende
Information an die Untercluster veröffentlicht und den Kunden über den Abbruch
informiert. Sollten alle Nachrichtenmanager positiv beantwortet
haben, veröffentlich
der Transaktionsmanager den Durchführungsbefehl an die Nachrichtenmanager
in den an der Transaktion beteiligten Unterclustern und informiert
dann den Kunden, dass der Durchführungsbefehl
zur Umsetzung angenommen wurde. Nach Erhalt des Durchführungsbefehls aktualisieren
alle Nachrichtenmanager den Nachrichtenspeicher insoweit, dass die
Sendebefehle offenbart und die erhaltenen Nachrichten als geliefert
betrachtet werden.
-
Die
durch Knotenausfälle
und Netzteilungen herbeigeführten
Zustandsänderungen
gefährden
die Durchführung
von Transaktionen. Während
der Zustandsänderungen
kann sich das Umfeld der Transaktionsdurchführung insoweit verändern, dass
die Semantik der Nachrichtenbearbeitung im Falle einer unsachgemäßen Handhabung
zum Bruch gehen kann. Dies könnte
z.B. dann vorkommen, wenn der Transaktionsmanager vom Cluster/Untercluster
samt Hauptmanager abgetrennt würde,
wobei der letztere zum beschränkten/aufbewahrenden
Hauptmanager degradiert worden wäre.
Um einen Semantikbruch zu vermeiden, löst eine Zustandsänderung
im beteiligten Untercluster bzw. Gesamtcluster den Transaktionsabbruch
durch die an der Transaktion beteiligten Nachrichtenmanager in folgenden
Fällen
aus:
- – eine
Zustandsänderung
hat den Übergang
der den Transaktionsmanager enthaltenden Partition in den Partitionszustand
D zur Folge (auch wenn D bereits gewesen wäre)
oder
- – der
Transaktionsmanager ist für
den/die an der Transaktion beteiligten Cluster/Untercluster nicht zugänglich,
d.h. er wird beschädigt
bzw. einer anderen Partition angeschlossen.
-
In
allen sonstigen Fällen
wird die Transaktion ab der Übergangsstelle
des Clusters bis zum neuen Zustand unabgebrochen fortgesetzt.
-
In
jedem Nachrichtenmanager innerhalb des Clusters werden die empfangenen
und die zu sendenden Nachrichten mit einem Etikett versehen, dass
sie als ein Teil der Transaktionssession gesperrt sind und noch
nicht durchgeführt
wurden. Die angewendeten Transaktionen verursachen keine Sperren und
die den vom Transaktionsmanager erhaltenen Nachrichten auferlegten
Absicherungen werden zurückgenommen,
sobald eine Zustandsänderung
den Transaktionsabbruch erzwungen hat. Dies bedeutet, dass die an
der Transaktion beteiligten Knoten sich durch eine gewisse Wartezeit
auszeichnen, welche von der unterliegenden Sendeschicht zur Erkennung von
Defekten verwendet wird. Es gibt jedoch keine andere Wartezeiten,
die die Transaktionsumsetzung beeinflussen könnten.
-
Sollte
der Transaktionsmanager beschädigt bzw.
von den Nachrichtenmanagern während
der Transaktion noch vor deren Abschluss bzw. Abbruch abgetrennt
werden, brechen dann alle an der Transaktion beteiligten Nachrichtenmanager
nach Erhalt der Information über
das Ereignis durch eine Sichtfeldzustandsänderung die Transaktion ab.
In einem Beschädigungsfall
des Transaktionsmanagers erhält der
die Transaktion einleitende Kunde die Absage samt Mitteilung über Verbindungsausfall
mit dem Transaktionsmanager und über
die Transaktionsscheiterung. Dasselbe erfolgt, wenn der die Transaktion
einleitende Kunde vom Transaktionsmanager getrennt wird. Die Absage
wird jeweils die Transaktionssequenznummer enthalten. Bei Anwendung
der Transaktionssequenznummer wird der Kunde nach einer gewissen
Zeit mit einem anderen Kundenmanager verbunden und leitet erneut
seine Transaktion ein, die dann anhand von neuem Transaktionsmanager
erneut gestartet wird.
-
Sollte
der Transaktionsmanager sofort nach Erhalt des Durchführungsbefehls
vom Kunden nicht zugänglich
werden, bekommt der Kunde die Absage mit der Info über den
Verlust der Verbindung mit dem Transaktionsmanager – dem Kundenmanager.
Der Kunde weiß dann
jedoch nicht, was aus der Transaktion geworden ist, ob sie zustande
gekommen ist oder nicht. Durch den Aufbau einer neuen Verbindung
mit einem anderen Kundenverwalter wird der Kunde versuchen die Transaktion
wieder herzustellen. Der Kunde kann die Transaktion in dieser Etappe nicht
abbrechen, weil die Nachrichten in der Öffentlichkeit zugänglich sein
und z.B. von anderen Kunden ausgenutzt werden könnten, soweit der frühere Durchführungsbefehl
nicht umgesetzt wurde. Vorausgesetzt dem Kunden ist nicht bekannt,
ob der frühere
Durchführungsbefehl
umgesetzt wurde, wird er es versuchen, die Transaktionsdurchführung durch den
neuen Transaktionsmanager -Kundenmanager einzuleiten. Zwecks Aufrecherhaltung
der semantischen Gültigkeit
ist der Durchführungsablauf
idempotent, demnach besteht keine Gefahr, auch wenn der frühere Durchführungsbefehl
tatsächlich
umgesetzt wurde und dieselbe Transaktion wieder angewiesen wird.
-
Die
erneute Einleitung des Durchführungsbefehls
erfolgt, indem man zuerst die Transaktion und deren auszuführenden
Teil, d.h. die ab dem letzten Durchführungsbefehl gesendeten und
empfangenen Nachrichten identifiziert, damit der richtige Transaktionsteil
ausgeführt
wird. Der Grund weshalb jeder Teil Durchführung/Abbruch der Transaktion
eindeutig identifizierbar sein muss, besteht in der notwendigen
Sicherstellung, dass ein erneuter Durchführungsbefehl nicht dazu führen kann,
einen falschen Transaktionsteilumzusetzen.
-
Nach
Erhalt eines neuen Durchführungsbefehls
wird er von neuem Transaktionsmanager in einen Bereitstellungsbefehl
umgewandelt, der danach den Durchführungs- bzw. Abbruchsbefehl
sendet. Diese Umwandlung ist mit der zweiphasigen Transaktionsumsetzung
konform. Bei positivem Bereitstellungsbefehl, d.h. wenn alle an
der Transaktion beteiligten Nachrichtenmanager- die Haupt- bzw.
Backupmanager – den
Bereitstellungsbefehl positiv beantwortet haben, wird bekannt, dass
die vorherige Durchführung
erfolgreich umgesetzt wurde. Wenn dagegen der Durchführungsbefehl
von den an der Transaktion beteiligten Nachrichtenmanagern negativ
beantworte wurde, bedeutet es, dass die vorhergehende Durchführung nicht
umgesetzt wurde und die Aktion infolge einer Zustandsänderung
aufgrund Beschädigung
des vorherigen Transaktionsmanagers abgebrochen wurde. Das Obige
betrifft auch den Fall, wo der Transaktionsmanager nach Erhalt des
Abbruchbefehls vom Kunden beschädigt
wird.
-
Damit
diese Szenarios erfüllt
werden können,
muss jeder an der Transaktion beteiligte Nachrichtenmanager – so die
Haupt- wie die Backupmanager – die
Sequenznummer der zuletzt durchgeführten Transaktion sowie deren
Ergebnis in Bezug auf jede Transaktionssession kennen. Diese Information
wird von jedem Nachrichtenmanager – so die Haupt- wie die Backupmanager – aufrechterhalten.
-
Zusammenfassend
weist die Erfindung folgende Vorteile auf
- – Das Verfahren
nach der Erfindung garantiert die JMS-Semantik während der Knotenausfälle und Netzteilungen
eines Clustersystems der Nachrichtenübermittlung
- – Die
Erfindung garantiert insbesondere, dass jede Nachricht höchstens
einmal an die Kundenapplikation während der Knotenausfälle bzw. Netzteilungen
eines Clustersystems der Nachrichtenübermittlung, ausgenommen die
in der JMS-Spezifikation angeführten
Fälle,
geliefert wird
- – Die
Erfindung garantiert insbesondere, dass keine Nachricht während der
Knotenausfälle
bzw. Netzteilungen eines Clustersystems der Nachrichtenübermittlung,
ausgenommen die zulässigen,
in der JMS-Spezifikation angeführten
Fälle, verloren
geht
- – Die
Erfindung garantiert insbesondere, dass alle thematischen Nachrichten
zu einem gewissen Zeitpunkt an alle Kundenapplikationen während der
Knotenausfälle
bzw. Netzteilungen eines Clustersystems der Nachrichtenübermittlung
geliefert wird, ausgenommen die Fälle wo thematische Nachrichten
noch vor der Beseitigung der Knotenausfälle bzw. Netzteilungen überfällig werden
- – Durch
die Garantierung der JMS-Semantik stellt die Erfindung gleichzeitig
sicher, dass ein Clustersystem der Nachrichtenübermittlung immer erreichbar
ist, um die Nachrichten von den Nachrichtenherstellern zu empfangen,
wobei auch eine ordnungsgemäße Lieferung
dieser Nachrichten garantiert wird, auch wenn der Cluster von Netzteilung
betroffen ist. Dabei wird selbstverständlich vorausgesetzt, dass
nicht alle Knoten des Clustersystems der Nachrichtenübermittlung
beschädigt wurden.
-
GLOSSAR
-
- – Cluster:
Eine Gruppe der an mehreren Computern umzusetzenden und derart voneinander
abhängigen
Aktionen, dass sie sich wie ein Einzelserver der Nachrichtenübermittlung
jedoch mit erhöhter
Leistung und Zuverlässigkeit
verhalten. Unter dem Kundengesichtspunkt entspricht ein Cluster
funktionsmäßig einem
monolithischen Server und demnach erscheint er für den Kunden transparent.
- – Knoten:
Logische Einzelaktion innerhalb des Clusters. Öfters entspricht ein Knoten
einem Einzelcomputer, dies trifft aber nicht ganz exakt zu. Zahlreiche
an einem Computer laufende Knoten werden sich gegenseitig so beeinflussen,
als befänden
sie sich an separaten und nur durch ein Netz verkoppelten Computern.
- – Monolithischer
Server: Ein voller Nachrichtenserver, der wie ein Einzelknoten funktioniert.
- – Server:
Allgemeiner Begriff, der einen einzelnen logischen Nachrichtenserver
bedeutet. Es kann sich dabei um einen monolithischen Server bzw. um
einen Cluster nach der obigen Beschreibung handeln.
- – Kunde:
Eine an einen Clusterknoten angeschlossene Anwendung zwecks Nachrichtensendung
(Veröffentlichung)
bzw. Nachrichtenempfang (Benutzung) vom Server.
- – JMS:
(Java Message Service) – Standardschnittstelle
von Applikationen (API) für
die in der Java-Sprache erstellten Programme, sie wird zwecks Zugriff
an die Dienstleistungen des Nachrichtensystems eingesetzt.