DE69629630T2

DE69629630T2 - Struktur zur Gruppenzugehörigkeitsverwaltung in einem Mehrfachrechnersystem

Info

Publication number: DE69629630T2
Application number: DE69629630T
Authority: DE
Inventors: Robert A. Menlo Park Alfieri; James T. Durham Compton; Andrew R. Monroeville Huber; Paul T. Raleigh McGrath; Khaled S. Durham Soufi; Brian J. Cary Thorstad; Eric R. Chapel Hill Vook
Original assignee: Data General Corp
Current assignee: EMC Corp
Priority date: 1995-06-23
Filing date: 1996-06-20
Publication date: 2004-06-03
Anticipated expiration: 2016-06-21
Also published as: JP3953549B2; EP0750256B1; EP0750256A2; US5666486A; JPH09171502A; AU713372B2; AU5601396A; DE69629630D1; CA2179473A1; EP0750256A3

Description

Die vorliegende Erfindung betrifft im Allgemeinen Multiprozessorsysteme und im Besonderen Clustersysteme mit gemeinsamem Datenträger. Insbesondere betrifft die Erfindung einen Rahmen zum Anschließen und Lösen von Knoten in einem Multiprozessor-Cluster-System.
Ein Multiprozessor-Cluster-System weist im typischen Fall mehrere Knoten auf, die durch eine private Kommunikationsverbindung miteinander verbunden sind. Das Clustersystem hat außerdem eine gemeinsame Cluster-Ressource, wie z. B. einen virtuellen Datenträger, der für alle Knoten zugänglich ist, die ein Betriebssystem abarbeiten, das koordinierten Zugang zu der gemeinsamen Ressource unterstützt. Clustersysteme haben viele Vorteile. Sie verleihen dem Benutzer hohe Verfügbarkeit, weil die Verfügbarkeit nicht davon abhängt, dass alle Knoten aktive Teilnehmer im Cluster sind. Ein oder mehrere Knoten können das Cluster verlassen, ohne notwendigerweise die Verfügbarkeit zu beeinträchtigen. Neue Knoten können zu dem System hinzugefügt werden, ohne dass das System heruntergefahren und neu gestartet werden muss. Außerdem können Knoten voneinander verschiedene Prozessordesigns aufweisen, die die Erweiterung des Systems ermöglichen. Auf diese Weise sorgt das Clustersystem für eine hohe Gesamtleistung.
Clustersysteme mit gemeinsamem Datenträger werden meist für Datenbankdienste verwendet, die ein verteiltes Sperrensystem benötigen, um eine Verletzung der Integrität von Daten auf dem gemeinsamen virtuellen Datenträger zu vermeiden. Das Mitgliedschaftsmanagement in einem solchen Clustersystem erforderte, dass dem verteilten Sperrensystem Clusterbewusstsein verliehen wurde. Derartige Clustersysteme mit gemeinsamem Datenträger sind aber begrenzt, weil sich das Clusterbewusstsein auf nur eine Subsystemschicht erstreckt. Bestimmte Betriebssysteme haben mehrere Subsysteme, die so geschichtet sind, dass ein höheres Subsystem vom Betrieb niedrigerer Subsysteme abhängen muss. Bekannte Methoden des Cluster-Mitgliedschaftsmanagements sind nicht in der Lage, derartige geschichtete Subsysteme durch Clusterübergänge von sich dem Cluster anschließenden und aus ihm ausscheidenden Knoten zu führen.
Client-Dienste sind im typischen Fall auf die Knoten des Clusters verteilt, was eine ausgedehnte Koordination dessen erfordert, welcher Knoten welchen Dienst implementiert. Dies ist während Knotenübergängen eines sich dem Cluster anschließenden oder aus ihm ausscheidenden Knotens besonders schwierig. Grund dafür ist, dass den meisten Diensten die Clusterumgebung nicht bewusst ist. Die Client-Dienste würden im typischen Fall selbstständig den besten Knoten für die Ausführung bestimmen. Es würde ein Recovery-Mechanismus zum Einleiten der Wiederherstellung benötigt, wenn der derzeit den Dienst ausführende Knoten das Cluster verlässt. Einzelne Dienste ihren eigenen Mechanismus für diese Koordination implementieren zu lassen, erfordert detaillierte Modifikationen an den Client-Diensten, damit sie auf einem Clustersystem abgearbeitet werden können, was die Verwaltung des Clusters mühsam und schwierig macht, weil eventuell unkonsistente Mechanismen verwendet werden.
Das US-Patent US-A-5.287.453 offenbart ein Cluster-Computersystem, das ein Cluster miteinander verbundener, unabhängig betriebener Computersysteme hat, die durch einen Cluster-Controller Informationen austauschen. Die Mitglieder des Clusters tauschen eine Liste aller clusterweit gemeinsam zu nutzenden Platten, Bänder und Drucker aus. Wenn ein Operator auf ein benanntes Disk- Volume in dem System Bezug nehmen will, setzt er den Plattensatz oder das Datenträgervolume in das Plattenlaufwerk von einem der Mitglieder des Clusters ein. Das System erkennt das Volume lokal und sendet eine Nachricht an alle anderen Mitglieder, dass das benannte Volume eingesetzt worden ist.
Die Erfindung in ihren diversen Aspekten ist in den unabhängigen Ansprüchen unten definiert, auf die jetzt Bezug zu nehmen ist. Vorteilhafte Merkmale sind in den anhängigen Ansprüchen dargelegt.
Eine bevorzugte Ausgestaltung der Erfindung, die unten mit Bezug auf die Zeichnungen ausführlicher beschrieben wird, sieht ein Verfahren und eine Vorrichtung zum Kombinieren bestimmter Prozessoren, oder Knoten, eines Multiprozessorsystems in einem Cluster vor, das Benutzern des System im Wesentlichen als ein vereintes System erscheint. Mehrere Subsysteme, die auf gegenwärtig in dem Cluster befindlichen Knoten abgearbeitet werden, werden über Übergänge von sich dem Cluster anschließenden und aus ihm ausscheidenden Knoten benachrichtigt. Dies stellt den Subsystemen der Cluster-Knoten eine konsistente Ansicht der aktiven Mitgliedschaft in dem Cluster bereit, wodurch alle Knoten-Subsysteme durch die Knotenübergänge geführt werden können. Dieses Merkmal ist besonders nützlich bei Subsystemen, die in Ebenen interdependent sind, wobei die Subsysteme höherer Ebenen von dem Betrieb von Subsystemen niedrigerer Ebenen abhängig sind. Ein spezieller Übergang wird dem Subsystem der gleichen Ebene an allen Knoten mitgeteilt. Die Benachrichtigung wird nicht auf eine weitere Subsystemebene weitergeleitet, bis das benachrichtigte Subsystem jedes Knotens diese Benachrichtung bearbeitet und bestätigt, dass eine solche Bearbeitung abgeschlossen ist. Wenn der Übergang ein sich dem Cluster anschließender Knoten ist, werden Subsysteme, angefangen mit Subsystemen niedrigerer Ebene und der Reihe nach durch höhere Subsystemebenen fortschreitend, benachrichtigt. Wenn der Übergang ein das Cluster kontrolliert verlassender Knoten ist, werden Subsysteme, angefangen mit Subsystemen höherer Ebene und der Reihe nach durch niedrigere Subsystemebenen fortschreitend, benachrichtig. Wenn der Übergang ein von anderen Knoten unkontrolliert aus dem Cluster gedrängter Knoten ist, werden Subsysteme, angefangen mit Subsystemen niedrigerer Ebene und der Reihe nach durch höhere Subsystemebenen fortschreitend, benachrichtigt.
Es ist eine Registrierungs- und Start-Funktion vorgesehen, bei der Client-Dienste, einschließlich Benutzeranwendungen, auf speziellen Knoten in einem Cluster so eingeleitet werden, dass das Cluster den Client-Diensten im Wesentlichen als eine einheitliche Einheit erscheint. Für jeden Client-Dienst wird ein Knoten gewählt und dieser Client-Dienst wird bei dem Knoten registriert. Gegenwärtig in dem Cluster befindliche Knoten werden darüber benachrichtigt, dass der spezielle Dienst bei dem betreffenden Knoten registriert ist. Auf diese Weise können Client-Dienste auf einen anderen Knoten übertragen werden, wenn der Knoten, an dem dieser Dienst registriert ist, das Cluster verlässt. Der Client-Dienst kann an einem Knoten gemäß einem in dem Dienst enthaltenen Aktionsparameter in Reaktion auf das Registrieren dieses Dienstes bei diesem Knoten gestartet werden. Dies versieht Client-Dienste mit clusterweiter Verfügbarkeit, weil sie sich nicht jedesmal, wenn sie übertragen werden, ausdrücklich selbst einleiten müssen. Client-Dienste können vorteilhaft als Parent-Dienst (Eltern-Dienst) und einem oder mehreren Child-Diensten (Kind-Diensten) gruppiert werden.
Gruppierte Client-Dienste sind bei dem gleichen Knoten registriert und nutzen in dem Parent-Dienst enthaltene Aktionsparameter für alle Startaktivitäten innerhalb der Gruppe. Das Wählen eines Knotens für jeden Client-Dienst kann das Bereitstellen einer Datenbank von Wählfaktoren für den Client-Dienst und das Anwenden der Wählfaktoren auf Informationen bezüglich der Verfügbarkeit der Knoten in dem Cluster aufweisen. Die Wählfaktoren legen Regeln fest, die Knoten mit dem Client-Dienst in Bezug setzen.
Eine solche Registrierungs- und Startfunktion ist vorzugsweise eine Komponente eines Ereignismanagers, der ein Subsystem ist, das vom Cluster-Mitgliedschaftsmanager Benachrichtigungen über Knotenübergänge erhält. Der Ereignismanager überwacht bei einem bestimmten Knoten registrierte Client-Dienste mit Hilfe einer Ereignisüberwachung (Event-Watcher) und sorgt für Bedienungsvorgänge, die in Reaktion auf das Stattfinden eines Ereignisses, wie eines Knotenübergangs, ausgeführt werden. Die Ereignisüberwachung kann in Reaktion auf das Registrieren eines Client-Dienstes aktiviert und in Reaktion auf das Deregistrieren des Client-Dienstes deaktiviert werden.
Im Folgenden wird die bevorzugte Ausgestaltung der vorliegenden Erfindung mit Bezug auf die Zeichnungen beispielhaft ausführlicher beschrieben. Dabei zeigt bzw. zeigen:
1 ein Blockdiagramm eines die Erfindung ausgestaltenden Multiprozessor-Cluster-Systems;
2 ein Zustandsübergangsdiagramm eines Übergangsbenachrichtigungsrahmens für eine einzelne Subsystemebene;
3 bis 10 Diagramme von Subsystemzuständen in einem Zwei-Knoten-Cluster, das sich dem Cluster anschließende Knoten illustriert;
11 und 12 Diagramme von Subsystemzuständen in einem Zwei-Knoten-Cluster, die das kontrollierte Ausscheiden eines Knotens aus dem Cluster illustrieren;
13 bis 15 Diagramme von Subsystemzuständen in einem Zwei-Knoten-Cluster, die ein unkontrolliertes erzwungenes Ausscheiden eines Knotens aus dem Cluster illustrieren;
16 ein Blockdiagramm, das die Gruppierung von Client-Diensten illustriert;
17 ein 15 ähnliches Diagramm, das mehrere Generationen von Client-Dienst-Gruppierungen illustriert;
18 ein Zustandsübergangsdiagramm, das das Starten eines Client-Dienstes illustriert;
19 ein Zustandsübergangsdiagramm, das die Übergangszustände eines Client-Dienstes illustriert;
20 eine 18 ähnliche Darstellung, die zusätzliche Übergangszustände illustriert, und
21 ein Blockdiagramm eines Ereignismanager-Subsystems.
HARDWARE
Ein Multiprozessor-Cluster-System 25, wobei jetzt speziell auf die Zeichnungen und die darin abgebildeten veranschaulichenden Ausgestaltungen Bezug genommen wird, hat mehrere Knoten 26 und eine gemeinsame Cluster-Ressource, wie z. B. einen physikalischen Datenträger 28, der aus mehreren physikalischen Plattenlaufwerken bestehen könnte (1). Jeder Knoten 26 hat einen Prozessor (Zentraleinheit, CPU), einen physikalischen Speicher, Caches, gemeinsame und private Busschnittstellen und wahlweise dedizierte Geräte. Jeder Knoten arbeitet eine Kopie eines auf UNIX gestützten Betriebssystems, wie z. B. das von der Data General Corporation von Westborn, Massachusetts, USA, vertriebenen Betriebssystem DG/UX 5.4, ab, das auf jeder beliebigen Hardwarekonfiguration fährt, die ein derartiges Betriebssystem unterstützt. Ein Beispiel für eine solche Hardwarekonfiguration ist die von Data General vermarktete AViiON^®-Familie.
Cluster-System 25 hat außerdem ein Interconnect 36, das ein dediziertes gemeinsames Cluster-Kommunikationsmittel ist, über das Knoten 26 direkt mit allen anderen Knoten im gleichen Cluster sprechen können, und einen gemeinsamen Cluster-E/A-Bus 32, über den alle Knoten alle physikalisch an den gemeinsamen Bus angeschlossenen Geräte, wie z. B. Datenträger 28, gemeinsam nutzen können. In der illustrierten Ausgestaltung ist der gemeinsame Bus 32 ein SCSI-Standardbus.
SOFTWARE
Cluster-System 25 hat eine einzelne Mitgliedschaftsdatenbank 34, die einen dedizierten virtuellen gemeinsamen Cluster-Datenträger hat, der neben einem clusterbewussten Urlader 38 auf dem physikalischen Datenträger 28 wohnt. Die Mitgliedschaftsdatenbank 34 verwaltet beständige Knotenkonfigurationsinformationen 40, die zum Urladen, Ausschalten oder Notausschalten (Panik) eines Knotens 26 benötigt werden. Zu derartigen beständigen Informationen gehört die Identifizierung der Anzahl von Knoten, die in dem System konfiguriert sind, sowie Konfigurationsdaten über jeden Knoten, die mit einer Knotenkennnummer indexiert sind. Die Mitgliedschaftsdatenbank 34 hat außerdem eine Datenbank für den aktiven Mitgliedschaftszustand 42, die flüchtige Informationen über Knotenzustände enthält. Derartige flüchtige Informationen ändern sich dynamisch, wenn Knoten sich dem Cluster kontrolliert anschließen, das Cluster kontrolliert verlassen oder unkontrolliert aus dem Cluster gedrängt werden. Ein Knoten kann irgendeinen der folgenden Zustände aufweisen: Inaktiv – der Knoten ist nicht konfiguriert oder er ist kein aktives Mitglied des Clusters.
Anschließend – der Knoten ist dabei, sich an ein Cluster anzuschließen, was bedeutet, dass der Knoten andere Knoten über seine Absicht, sich dem Cluster kontrolliert anzuschließen, informiert hat, aber noch nicht alle der registrierten Knoten-Subsysteme im Cluster die Übergänge abgeschlossen haben, um den neuen Knoten kontrolliert aufzunehmen.
Angeschlossen – der Knoten hat sich dem Cluster völlig angeschlossen und alle registrierten Knotensubsysteme im Cluster akzeptieren den neuen Knoten als ein Mitglied des Clusters und haben ihre Übergänge zum Aufnehmen des neuen Knotens abgeschlossen.
Ausscheidend – der Knoten ist dabei, den Cluster zu verlassen, was bedeutet, dass der Knoten andere Knoten über seine Absicht, das Cluster kontrolliert zu verlassen, informiert hat; aber noch nicht alle registrierten Knoten-Subsysteme der Knoten im Cluster Übergänge zum kontrollierten Ausschließen des neuen Knotens abgeschlossen haben.
Zwangsausscheidung – andere Knoten sind dabei, diesen Knoten aus dem Cluster zu drängen. Andere Knoten können einen Knoten hinausdrängen, wenn dieser Knoten nicht richtig funktioniert, z. B. wenn er nicht mit anderen Knoten kommuniziert. Nachdem die anderen Knoten das Bearbeiten der Zwangsausscheidung abgeschlossen haben, was das Ausführen von Recovery-Prozeduren umfasst, markieren die anderen Knoten diesen Knoten als inaktiv. Der hinausgedrängte Knoten reagiert panisch, nachdem er bemerkt hat, dass die anderen Knoten ihn ausgeschlossen haben. Ein Knoten reagiert panisch, indem er weiteres Bearbeiten abbricht, um eine Verfälschung gemeinsamer Cluster-Ressourcen zu vermeiden.
A. MITGLIEDSCHAFTSMANAGER
Das Clustersystem 25 hat einen Mitgliedschaftsmanager-Rahmen mit einem Übergangsbenachrichtigungsrahmen 44, der Benachrichtigungen an alle Subsysteme auf Kernel-Ebene und Benutzerebene bereitstellt, die über Clusterübergänge benachrichtigt werden müssen (2 bis 15). Zweck des Übergangsbenachrichtigungsrahmens 44 ist es, clusterbewusste Subsysteme bereitzustellen, eine kohärente Methode zum Bearbeiten von Clusterübergangsinformationen unter den Knoten. Clusterbewusste Subsysteme sind Subsysteme, die bei einem Cluster-Mitgliedschaftsmanager-Subsystem 46 eines Knotens registriert sind. In der illustrierten Ausgestaltung hat jeder Knoten 26 vier Subsysteme auf Kernel-Ebene, darunter Cluster-Mitgliedschaftsmanager-Subsystem 46, die zusammen den Übergangsbenachrichtigungsrahmen 44, ein Verteilter-Sperrenmanager-(DLM-)Subsystem 48, ein Virtueller-Diskmanager-(VDM-)Subsystem 50 und ein Gemeinschaftsdateisystem-(SFS-)Subsystem 52 bereitstellen. Jeder Knoten 26 hat außerdem wenigstens ein Subsystem auf Benutzerebene, nämlich ein Ereignismanager-Subsystem 54. Derartige Subsysteme 46 bis 54 sind untereinander in Ebenen voneinander abhängig. In der illustrierten Ausgestaltung ist der Mitgliedschaftsmanager 46 das Subsystem niedrigster Ebene und der Ereignismanager 54 das Subsystem höchster Ebene. Es könnten aber auch noch andere. höhere Subsysteme bereitgestellt werden. Für die Subsysteme ist eine globale Übergangsrangordnung vorgesehen, wobei niedrigere Subsysteme kleinere Werte und höhere Subsysteme größere Werte erhalten.
Der Übergangsbenachrichtigungsrahmen 44 funktioniert wie folgt. Bevor ein Knoten sich einem Cluster anschließt, registrieren interessierte Subsysteme dieses Knotens ihre Absicht, Benachrichtigungen über Clusterübergänge zu erhalten. Ein registriertes Subsystem muss auch einen Steuerthread liefern, der Warten-auf-Übergang-Benachrichtigungen vom Mitgliedschaftsmanager-Subsystem 46 dieses Knotens sperrt. Während kontrollierter Anschlüsse und Zwangsausschlüsse von Knoten koordinieren die Mitgliedschaftsmanager-Subsysteme 46 aller Knoten, um die registrierten Subsysteme des Knotens mit Bezug auf das globale Übergangsrangordnungsschema von unten nach oben zu benachrichtigen, wie unten noch ausführlicher illustriert wird. Die Mitgliedschaftsmanager-Subsysteme benachrichtigen also zunächst die rangniedrigsten Subsysteme aller Knoten, gefolgt von den rangmäßig nächsthöheren bis zu den ranghöchsten. Umgekehrt koordinieren während des kontrollierten Ausscheidens von Knoten die Mitgliedschaftsmanager-Subsysteme 46 aller Knoten, um die registrierten Subsysteme des Knotens von oben nach unten zu benachrichtigen, wobei sie zunächst die ranghöchsten Subsysteme aller Knoten benachrichtigen, gefolgt von den rangmäßig nächsthöchsten bis zu den rangniedrigsten. Diese Rangordnung hat den Zweck, dass Abhängigkeiten höherer Subsysteme von niedrigeren Subsystemen erfüllt werden. Das heißt, dass ein Knotenanschlussübergang zuerst von einem Subsystem niedrigerer Ebene bearbeitet wird, sodass Subsysteme höherer Ebene versichert sein können, dass die Subsysteme, von denen sie abhängen, nämlich niedrigerere Subsysteme, sich des Anschließens bewusst sind und seine Bearbeitung abgeschlossen haben. Umgekehrt muss ein kontrolliertes Verlassen zuerst von einem Subsystem höherer Ebene bearbeitet werden, sodass die untereren Subsysteme in dem ausscheidenden Knoten während des Ausscheidungsübergangs betriebsfähig bleiben. Ein unkontrolliertes Ausscheiden wird von unten nach oben bearbeitet, um sicherzustellen, dass alle Fehlerbedingungen nach oben fortgepflanzt werden, bevor auf der nächsthöchsten Ebene die Wiederherstellung versucht wird.
Das Mitgliedschaftsmanager-Subsystem jedes, Knotens schreitet mit der Benachrichtigung des der Reihe nach nächsten Subsystems erst dann fort, wenn das Subsystem jedes Knotens, das derzeit an der Reihe ist, seine Beendigung der Bearbeitung für den Übergang bestätigt. Das Mitgliedschaftsmanager-Subsystem jedes Knotens kann aber ein registriertes Subsystem benachrichtigen, um mehrerer Übergänge für verschiedene Knoten gleichzeitig zu bearbeiten. Jeder dieser Übergänge kann anderer Art sein. Dies verbessert die Leistungsfähigkeit in Situationen, in denen viele Knoten gleichzeitig Übergänge durchlaufen, wie z. B. dann, wenn viele Knoten nach einem Stromausfall, der das gesamte Cluster ausgeschaltet hat, urladen. Der Mitgliedschaftsmanager jedes Knotens benachrichtigt aber keine Subsysteme, die für einen bestimmten Übergangsknoten außer Betrieb sind. Als Folge dessen können mehrere Übergänge für verschiedene Knoten zur gleichen Zeit auf verschiedenen Subsystemebenen bearbeitet werden, aber der Mitgliedschaftsmanager-Rahmen des Clusters gewährleistet das richtige Subsystemordnen für jeden Übergangsknoten.
Für Beispiele der Verwendung von Clustersubsystemen zur Beteiligung an kontrolliertem Anschließen, kontrolliertem Verlassen und unkontrolliertem Zwangsausscheiden unter Verwendung des Übergangsbenachrichtigungsrahmens 44 wird auf die 2 bis 15 Bezug genommen, die ein Clustersystem illustrieren, das potenziell ein Zwei-Knoten-Cluster hat. Die in den 3 bis 15 illustrierten Beispiele können auf drei oder mehr Knoten verallgemeinert werden, wobei jeder Knotenübergang sequenziell nacheinander jedes Subsystem an allen Knoten durchläuft. Jeder Mitgliedschaftsmanager würde den gleichen Knotenübergang nicht zum nächsthöheren Subsystem weiterleiten, bis alle Knoten auf der aktuellen Ebene ihren Abschluss der Übergangsbearbeitung für den neuen Knoten bestätigt haben.
In dem in 3 illustrierten Zustand enthält das Cluster keine aktiven Mitglieder. Der Systemverwalter schaltet Knoten N0 ein und beginnt sein Urladen. Knoten N1 bleibt abgeschaltet. Um sich als das erste aktive Mitglied kontrolliert an den Cluster anzuschließen, öffnet Knoten NO die Mitgliedschaftsdatenbank 34 des Clusters und ruft seine Konfigurationsinformationen ab. Knoten N0 initialisiert seine Kernel-Subsysteme 46–52, die sich jeweils für die Übergangsbenachrichtigung registrieren (4). Die Subsysteme erzeugen (spawn) einen Thread, der einen Kernelaufruf durchführt, der blockiert, weil zu diesem Zeitpunkt keine Clusterübergänge stattgefunden haben. Das INIT-Subsystem (nicht gezeigt) des Knotens N0 leitet das kontrollierte Anschließen von Knoten N0 durch das höchste derzeit registrierte Subsystem ein. Das Mitgliedschaftsmanager-Subsystem 46 von Knoten N0 bildet den Cluster und markiert den aktiven Zustand des Knotens N0 als anschließend. Mitgliedschaftsmanager 46 des Knotens NO benachrichtigt sein DLM-Subsystem 48, dass der Knoten NO sich dem Cluster anschließt (5). Der Thread des DLM- Subsystems 48 des Knotens N0 wird aufgeweckt, bemerkt den Neuanschlusszustand des Knotens NO, gibt die gemeinsame Bearbeitung an einen anderen DLM-Thread ab, und schließt dann sein Anschließen ab. Das DLM-Subsystem des Knotens NO markiert den Zustand des Knotens N0 als angeschlossen und informiert den Mitgliedschaftsmanager 46 des Knotens NO, dass DLM seine gemeinsame Bearbeitung für Knoten NO abgeschlossen hat. Der gleiche Vorgang wird für das VDM-Subsystem 50 und das SFS-Subsystem 52 des Knotens NO wiederholt (6).
Nachdem der Knoten N0 sich dem Cluster auf der Kernelebene angeschlossen hat, geht er zum Benutzerraum über (7a–7c). Das INIT-Subsystem (nicht gezeigt) des Knotens N0 erzeugt Ereignismanager-Subsystem 54, das einen Thread erzeugt, der sofort zurückkehrt, weil der Ereignismanager 54 des Knotens N0 das kontrollierte Anschließen des Knotens N0 noch nicht bearbeitet hat. Nachdem der Ereignismanager 54 des Knotens N0 das kontrollierte Anschließen des Knotens NO bearbeitet hat, markiert er den Zustand des Knotens NO als angeschlossen und informiert den Mitgliedschaftsmanager 46 des Knotens NO, dass er das kontrollierte Anschließen des Knotens N0 bearbeitet hat.
In 8 schaltet der Administrator den Knoten N1 ein und urlädt ihn, was bewirkt, dass die Knoten N0 und N1 ein kontrolliertes Anschließen des Knotens N1 durchführen. Der Knoten N1 öffnet die Mitgliedschaftsdatenbank 34, ruft seine Konfigurationsinformationen ab und initialisiert seine Kernel-Subsysteme 46–52, die sich für Übergangsbenachrichtigungen registrieren. Der Mitgliedschaftsmanager von sich anschließenden Knoten muss mit dem Cluster-Hauptknoten verhandeln, um sich dem Cluster anzuschließen. Wenn sich mehrere Knoten in dem Cluster befinden, wird ein Knoten unter Verwendung des Decker-Algorithmus, der in der Technik bekannt ist, zum Hauptknoten. Der Hauptknoten schreibt sein Heartbeat-Signal in einem bestimmten Bereich der Mitgliedschaftsdatenbank 34. Sich anschließende Knoten untersuchen einen derartigen Bereich auf das Heartbeat-Signal, um den Hauptknoten zu identifizieren. Das Mitgliedschaftsmanager-Subsystem 46 des Knotens N1 verhandelt mit dem Mitgliedschaftsmanager des Knotens NO, der der Hauptknoten sein muss, weil er der einzige Knoten im Cluster ist, um sich dem Cluster anzuschließen. Die Mitgliedschaftsmanager der Knoten N0 und N1 markieren den Zustand des Knotens N1 als sich dem Cluster anschließend. Die Mitgliedschaftsmanager der Knoten N0 und N1 benachrichtigen ihre jeweiligen DLM-Subsysteme 48, dass Knoten N1 sich dem Cluster anschließt. Beide DLM-Subsysteme werden durch ihre Aufrufe aufgeweckt und beginnen mit der Bearbeitung des kontrollierten Anschließens des Knotens N1. Nachdem beide DLM-Subsysteme in der Bearbeitung des kontrollierten Anschließens des Knotens N1 koordiniert haben, markieren die DLM-Subsysteme den Zustand des Knotens N1 als angeschlossen und senden dem Mitgliedschaftsmanager eine Bestätigung. Nachdem sie die Bestätigungen beider DLM erhalten haben, benachrichtigen die Mitgliedschaftsmanager der Knoten NO und N1 das entsprechende VDM-Subsystem 50, dass der Knoten N1 sich dem Cluster anschließt (9). Nachdem beide VDM-Subsysteme das Anschließen des Knotens N1 bearbeitet haben, markieren beide Subsysteme den Zustand des Knotens N1 als angeschlossen und senden jeweils eine Bestätigung dessen an ihren Mitgliedschaftsmanager.
Nachdem sich der Knoten N1 dem Cluster auf der Kernel-Ebene angeschlossen hat, geht der Knoten N1 zum Benutzerraum über, wobei sein INIT-Subsystem (nicht gezeigt) Ereignismanager 54 erzeugt. Der Ereignismanager des Knotens N1 registriert sich bei den Mitgliedschaftsmanagern. Der Ereignismanager des Knotens N1 erzeugt einen Thread, der einen Kernelaufruf durchführt, der sofort zurückgegeben wird, weil der Ereignismanager des Knotens N1 das kontrollierte Anschließen des Knotens N1 bearbeiten muss. Der Ereignismanager des Knotens N0 wacht auf und bearbeitet das kontrollierte Anschließen des Knotens N1. Nachdem beide Ereignismanager 54 in der Bearbeitung des kontrollierten Anschließens des Knotens N1 koordiniert haben, markieren sie den Zustand des Knotens N1 als angeschlossen und senden jeweils ihrem Mitgliedschaftsmanager eine Bestätigung des kontrollierten Anschließens. Der Knoten N1 ist wie in 10 illustriert angeschlossen.
Es ist möglich, dass ein Knoten ein kontrolliertes Ausscheiden einleitet, während sich der Knoten noch im anschließenden Zustand befindet. Ein sich anschließendes Subsystem setzt die anschließenden Zustände aber nicht direkt in einen ausscheidenden oder einen inaktiven Zustand um. Das sich anschließende Subsystem muss den Angeschlossen-Übergang abschließen und bestätigen. Der Mitgliedschaftsmanager kehrt den anschließenden Zustand nur zwischen Benachrichtigungen an registrierte Subsystemebenen in den ausscheidenden Zustand um.
Eine Bearbeitung, durch den Übergangsbenachrichtigungsrahmen 44, eines kontrollierten Ausscheidens eines Knotens, wie sie während eines Herunterfahrens eines Knotens stattfinden würde, wird unter Bezugnahme auf 11 und 12 illustriert. Der Knoten N0 leitet sein Herunterfahren ein, indem er den entsprechenden Aufruf zum Einleiten eines kontrollierten Ausscheidens durchführt. Die Mitgliedschaftsmanager- Subsysteme der Knoten N0 und N1 markieren den Knoten N0 als ausscheidend. Die Mitgliedschaftsmanager der Knoten NO und N1 wecken beide Ereignismanager 54 mit dem Übergang des Knotens N0 auf. Beide Ereignismanager 54 notieren den Zustand des Knotens N0 als ausscheidend und beginnen ihre koordinierte Bearbeitung des kontrollierten Ausscheidens des Knotens NO. Wie unten noch ausführlicher beschrieben wird, kann das Bearbeiten des kontrollierten Ausscheidens des Knotens N0 durch beide Ereignismanager ein beträchtliches Maß an Herunterfahren auf Anwendungsebene beinhalten, wonach beide Ereignismanager den Knoten N0 als inaktiv markieren und ihre betreffenden Mitgliedschaftsmanager benachrichtigen. Der Mitgliedschaftsmanager des Knotens N0 deregistriert den Ereignismanager des Knotens N0 automatisch für die Übergangsbenachrichtigung, wodurch der Ereignismanager des Knotens N0 keine weiteren Benachrichtigungen erhält. Als nächstes führt der Mitgliedschaftsmanager der Knoten NO und N1 jeweils die gleiche Iteration mit den SFS-Subsystemen 52 beider Knoten, dann mit beiden VDM-Subsystemen 50 und dann mit den DLM-Subsystemen 48 durch. Schließlich markiert der Mitgliedschaftsmanager beider Knoten jeweils den Knoten N0 als inaktiv, was auch das Ende des kontrollierten Ausscheidens des Knotens N0 ist. Knoten N0 führt die Bearbeitung des Herunterfahrens auf Kernelebene durch und kehrt zur Urladebefehlszeile zurück.
Es ist zu beachten, dass ein Knoten kein kontrolliertes Anschließen durchführen kann, während andere Knoten das kontrollierte Ausscheiden des Knotens bearbeiten. In der Praxis kann diese Situation eintreten, wenn der ausscheidende Knoten abnormal gestorben ist und wieder bootet, bevor andere Knoten die Chance hatten zu bemerken, dass dieser ausscheidende Knoten gestorben ist.
Sobald die anderen Knoten bemerken, dass der ausscheidende Knoten eigentlich gestorben ist, drängen die anderen Knoten den toten Knoten aus dem Cluster, wobei sie ihre Bearbeitung des kontrollierten Ausscheidens abbrechen. Anschließend akzeptieren die anderen Knoten die Anforderung eines kontrollierten Anschließens des neuen Knotens.
Ein unkontrolliertes (abruptes) Zwangsausscheiden ist eine abnormale Situation; z. B. wenn ein Knoten nicht mehr fähig ist, mit den anderen Clusterknoten zu kommunizieren. Wenn der hinausgedrängte Knoten bemerkt, dass die anderen Knoten diesen Knoten aus dem Cluster gedrängt haben, reagiert der hinausgedrängte Knoten panisch. Der Übergangsbenachrichtigungsrahmen 44 stellt sicher, dass der hinausgedrängte Knoten keine gemeinsamen Cluster-Resourcen verfälscht. Wenn ein registriertes Subsystem sich mitten in der Bearbeitung eines kontrollierten Anschließens oder Ausscheidens des hinausgedrängten Knotens befindet, könnte der Mitgliedschaftsmanager jedes Knotens das bearbeitende Subsystem erneut benachrichtigen, damit es seine kontrollierte Bearbeitung für den Knoten abbricht und die Bearbeitungswiederherstellung beginnt.
Ein Beispiel eines Zwangsausscheidens wird mit Bezug auf die 13 bis 15 illustriert, was damit beginnt, dass der Knoten N1 an das Cluster angeschlossen ist und der Knoten N0 urlädt und sich dem Cluster kontrolliert anschließt. Wenn beispielsweise die Mitgliedsmanager der Knoten N0 und N1 das kontrollierte Anschließen des Knotens N0 aufwärts durch die VDM-Subsysteme 50 bearbeitet haben, aber von den SFS-Subsystemen 52 noch keine Bestätigung erhalten haben, dass sie das Bearbeiten des kontrollierten Anschließens des Knotens N0 abgeschlossen haben, weil die SFS-Subsysteme der Knoten NO und N1 aufgrund eines Interconnect-Ausfalls an Knoten NO nicht kommunizieren können, wird das kontrollierte Anschließen des Knotens N0 als in einem hängenden Zustand befindlich notiert (13). Der Mitgliedschaftsmanager des Knotens N1 bemerkt, dass der Knoten N1 nicht mehr mit dem Knoten N0 kommunizieren kann. Knoten 1 drängt Knoten NO aus dem Cluster, indem er den Zustand des Knotens NO als zwangsausscheidend markiert. Der Mitgliedschaftsmanager des Knotens N0 bemerkt, dass der Knoten N1 den Knoten N0 hinausgedrängt hat, und reagiert sofort panisch (14). Der Mitgliedschaftsmanager des Knotens N1 leitet die Zwangsausscheidungsbearbeitung ausgehend vom untersten Subsystem und aufwärts weiter bis zum höchsten registrierten Subsystem ein. Das DLM-Subsystem 48 des Knotens N1 markiert den Knoten N0 als zwangsausscheidend, bemerkt den abrupten Übergang aus dem angeschlossenen Zustand und beginnt die Recovery-Bearbeitung, wie. in 14 illustriert. Nachdem das DLM-Subsystem des Knotens N1 seine Beendigung der Recovery-Bearbeitung für das Zwangsausscheiden des Knotens NO durch Markieren des Zustands des Knotens N0 als inaktiv bestätigt hat, führt der Mitgliedschaftsmanager des Knotens N1 die gleiche Iteration mit Bezug auf das VDM-Subsystem 50 durch.
Der Knoten N0 kann sich dem Cluster erst dann wieder kontrolliert anschließen, wenn alle Subsysteme des Knotens N1 ihre Bearbeitung der Zwangsausscheidung des Knotens N0 abgeschlossen haben. Wenn der Mitgliedschaftsmanager des Knotens N1 das SFS-Subsystem 52 des Knotens N1 schließlich eingeholt hat, bricht dieses Subsystem seine Bearbeitung des ursprünglichen kontrollierten Anschließens des Knotens N0 ab und führt die Recovery-Bearbeitung durch gefolgt von einer Bestätigung seiner Beendigung der Zwangsausscheidungsbearbeitung für Knoten N0 durch Markieren des Zustands des Knotens N0 als inaktiv. Der Mitgliedschaftsmanager des Knotens N1 würde die Zwangsausscheidungsbenachrichtigung normalerweise durch das höchste registrierte Subsystem, Ereignismanager 54, weiter iterieren. Weil aber das SFS-Subsystem 52 das höchste Subsystem war, das über den Versuch eines kontrollierten Anschließens durch den Knoten N1 benachrichtigt wurde, durchläuft die Zwangsausscheidungsbearbeitung nur das SFS-Subsystem. Nach der Bearbeitung der Zwangsausscheidungsbenachrichtigung durch das höchste zutreffende Subsystem, in diesem Fall das SFS-Subsystem, markiert der Mitgliedschaftsmanager des Knotens N1 den Zustand von Knoten N0 als inaktiv (15).
Tabelle 1 zeigt die Typen der Benachrichtigungen, die der Mitgliedschaftsmanager an ein registriertes Subsystem sendet, und die entsprechenden Bestätigungen, deren Erhalt der Mitgliedschaftsmanager von dem registrierten Subsystem erwartet, nachdem das registrierte Subsystem seine Bearbeitung des Übergangs abgeschlossen hat, für einen bestimmten Übergangsknoten. Tabelle 1 führt auch die erneuten Benachrichtigungen auf, die, dieser Mitgliedschaftsmanager an das registrierte Subsystem senden kann, während das registrierte Subsystem noch die ursprüngliche Benachrichtigung für den im Übergang befindlichen Knoten bearbeitet.
Einige registrierte Subsysteme müssen eventuell eine Zwei- oder Mehrphasen-Commit-Operation für einen der bestimmten Knotenübergänge durchführen. Um ein solches Mehrphasen-Commit bereitzustellen, stellt der Mitgliedschaftsmanager 46 Barrieren-Synchronisation bereit. Jedes registrierte Subsystem kann eine Anzahl von Schranken angeben, die das Subsystem für jeden Knotenübergangstyp wünscht. Die Mitgliedschaftsmanager senden dann Benachrichtigungen, die Barrieren-Synchronisation mit Subsystemebenen aufweisen. Alle Knoten auf einer bestimmten Subsystemebene müssen ihren Abschluss der Übergangsbearbeitung für die bestimmte Schranke bestätigen, bevor der Mitgliedschaftsmanager zu dem Subsystem übergeht, das als nächstes an der Reihe ist. Wenn beispielsweise das DLM-Subsystem während eines Anschlussübergangs zwei „Anschluss"-Schranken verlangt, müssen alle DLM-Subsysteme Anschlusschranke 0 bestätigen, bevor sie über Schranke 1 benachrichtigt werden. Nachdem sie Schranke 1 bestätigt haben, schreitet der Anschlussübergang zum VDM-Subsystem weiter, das eine andere Schrankenzahl haben kann. Auch müssen sich alle Subsysteme auf einer bestimmten Ebene für jeden Übergangstyp mit der gleichen Schrankenzahl registrieren.
In 1 wird ein Zustandsdiagramm für das Übergangsbenachrichtigungsnetzwerk 44 illustriert, um die Benachrichtigungstypen zu veranschaulichen, die ein einzelnes registriertes Subsystem für einen Knotenübergang erhalten kann. Wie in 2 beobachtet, kann der Übergang für jeden Übergangstyp durch mehrere Schranken verlaufen. Zur Verdeutlichung wird nur eine Schranke für das Zwangsausscheiden dargestellt. Es sind aber mehrere Schranken erlaubt. Gestrichelte Linien stellen Übergangsbenachrichtigungen dar. Durchgezogene Linien stellen Bestätigungen vom einzelnen Subsystem auf einem einzelnen Knoten oder über alle Knoten dar.
BENACHRICHTIGUNGEN VON EINEM MITGLIEDSCHAFTSMANAGER ÜBER ÜBERGÄNGE FÜR EINEN BESTIMMTEN KNOTEN AN EIN REGISTRIERTES SUBSYSTEM UND ERWARTETE BESTÄTIGUNGEN VON DEM REGISTRIERTEN SUBSYSTEM
TABELLE 1
B. EREIGNISMANAGER
Das Ereignismanager-Subsystem 54 ist ein Benutzerraum-Subsystem, das clusterweite Verfügbarkeit für Client-Dienste bereitstellt. Diese letztere Funktion wird von einem Registrierungs- und Startdienst 56 (16–21) durchgeführt, der eine Komponente des Ereignismanager-Subsystems 54 (21) ist. Das Ereignismanager-Subsystem 54 hat einen Ereignismanager-Dämon 58 mit mehreren Überwachungen (Watcher) 60a bis 60g, die bestimmte Bedingungen überwachen. Wenn eine Überwachung ein Problem feststellt, löst das Ereignismanager-Subsystem 54 das Problem über Aktionsfunktionen 62. Registrierungs- und Startdienst 56 kann als eine Überwachung des Ereignismanagerdämons 58 betrachtet werden, führt aber zusätzliche nützliche Funktionen durch, die unten noch ausführlicher beschrieben werden.
Ein Client-Dienst ist jede Rechentätigkeit, einschließlich Benutzeranwendungen, die auf einem Knoten oder auf mehr als einem Knoten in einem Cluster durchgeführt wird. Eine Schwierigkeit besteht darin, zu bestimmen, welcher Knoten bzw. welche Knoten jeden Client-Dienst anfänglich bereitstellen sollte(n). Außerdem muss koordiniert sein, welcher Knoten welche Dienste während eines Ausfallszenarios implementiert. Wenn einzelne Client-Dienste ihre eigenen Mechanismen zum Bestimmen des besten Ortes zum Ausführen und zum Iniitiieren der Wiederherstellung (Revocery), wenn der die Dienste derzeit bereitstellende Knoten das Cluster verlässt, bestimmen sollten, würde der administrativen Verwaltung des Clusters eine schwere Bürde aufgelastet. Registrierungs- und Startdienst 56 verleiht nichtclusterbewussten Anwendungen Clusterbewusstsein, indem er wählt, auf welchem Knoten ein Client-Dienst ausführt, den Client-Dienst bei diesem Knoten registriert und derzeit im Cluster befindliche Knoten benachrichtigt, dass der betreffene Client-Dienst bei diesem Knoten registriert ist. Registrierungs- und Startdienst 56 stellt außerdem ein fakultatives Start- oder Ausführungsleistungsmerkmal bereit, das aufgerufen wird, wenn der Dienst an einem bestimmten Knoten registriert wird. Das Start-Leistungsmerkmal kann außerdem zum kontrollierten Übertragen eines Dienstes von einem Knoten auf einen anderen verwendet werden. Das Start-Leistungsmerkmal, das „Aktionsfunktionen" genannt wird, verbessert die clusterweite Verfügbarkeit, indem es die Fähigkeit zum Einleiten, zur Migration und zur Beendigung von Client-Diensten verleiht. Derartige Übertragungen des Client-Dienstes können beispielsweise das Ergebnis von sich dem Cluster anschließenden und ihn verlassenden Knoten sein. Beispiele der Dienste, die prinzipiellen Gebrauch vom Registrierungs- und Startdienst machen, sind beispielsweise Drucken-Subsysteme, fließendes Internetprotokoll (IP), Vernetzungsdienste und Lizenzserver, obwohl auch andere Dienste den Registrierungs- und Startdienst vorteilhaft nutzen können.
1. Registrierung
Registrierung ist der Prozess, bei dem ein Knoten oder mehr als ein Knoten in einem Cluster die Verantwortung für einen zuvor definierten Client-Dienst beanspruchen kann/können oder sie ihm/ihnen zugewiesen wird. Sie wird auf clusterweiter atomischer Basis durchgeführt. Eine Registrierung zeigt einen Verantwortungsanspruch an, dass der registrierte Knoten die Verpflichtungen des spezifizierten Client-Dienstes erfüllt. Als Folge der Registrierung oder Deregistrierung werden fakultative Dienststart-, Benachrichtungs- oder Herunterfahrbefehle, „Aktionsfunktionen" genannt, aufgerufen. Auf diese Weise kann die Registrierung den Client-Dienst einleiten oder starten und dem Benutzerdienst Clusterbewusstsein verleihen. Clusterbewusstsein ist ein Ergebnis der Benachrichtigung anderer Knoten in dem Cluster sowie von Knoten, die sich später dem Cluster anschließen, bei Registrierungsabschluss über die Registrierung.
2. Wählen
Die Wahl, welchem Knoten als Teil einer Registrierungsoperation eine bestimmte Verantwortung zugewiesen wird, wird von einem Satz von Wählparametern oder Datenbankelementen 64 gelenkt. Diese Wählparameter können einen Satz Datenbankelemente aufweisen, die angeben, wann, wo und unter welchen Bedingungen ein Dienst registriert werden sollte. Es können aber auch zusätzliche Kriterien in die Wählfunktion eingeschlossen. sein, z. B. die jüngste Leistungsstatistik bestimmter Knoten. Vom Administrator bereitgestellte Prioritätsfaktoren wie folgt können ausgewählt werden:
Zulässige Knoten (Allowable_Nodes) – die Knoten aus dem Cluster, bei denen die Registrierung erlaubt ist. Alle Knoten müssen potenzielle Mitglieder des Clusters sein, obwohl sie nicht hochgefahren sein müssen. Zum Bezeichnen aller potenziellen Knoten des Clusters kann ein einzelnes Stellvertreterzeichen benutzt werden.
Knotenpräferenzen (Node_Preferences) – Knotenpräferenzen ergeben sich aus der Tatsache, dass nicht alle Knoten alle Client-Dienste gleich gut unterstützen. Knotenpräferenzen können als eine ungeordnete Liste oder als eine geordnete Liste angegeben. werden. Die Auswahl unter ungeordneten Elementen wird von der jüngsten Leistungscharakteristik des Clusters beeinflusst. Geordnete Listen werden angefangen mit dem ranghöchsten Element bearbeitet.
Unzulässige Knoten (Disallowable_Nodes) – die Knoten aus dem Cluster, bei denen keine Registrierung zulässig ist. Das Hinzufügen eines Knotens zu dem Feld der unzulässigen Knoten eines Client-Dienstes leitet aber nicht automatisch auch eine Übertragung des Dienstes ein.
Automatische Registrierung (Auto_Register) – wird verwendet, wenn das Cluster anfänglich hochgefahren wird, wobei jeder Benutzer-Client-Dienst potenziell registriert und gestartet werden muss. Das Feld für automatisches Registrieren erlaubt es dem Administrator zu definieren, unter welchen Bedingungen ein Dienst registriert werden sollte.
Platzierungsrichtlinien (Placement_Policy) – zeigen an, welche Art von Registrierungsphilosophie angewendet wird, nämlich, ob der Client-Dienst auf genau einem Knoten zu registrieren ist oder ob er auf jedem zulässigen Knoten registriert und gestartet werden soll.
Wie in 18 illustriert, kann ein Client-Dienst entweder von einem automatischen Start 66 oder einem externen Start 68 gestartet werden. Der Registrierungsund Start-Dienst eines entscheidungstreffenden Knotens wählt unter Verwendung der Wählparameter, wie bereits dargelegt, den besten Knoten an 64 aus. Der entscheidungstreffende Knoten kann jeder beliebige Knoten im Cluster sein. Er wird durch den Besitz einer Dateisperre bestimmt und mit Hilfe einer clusterweiten Semaphore bearbeitet. Wenn Reife (Maturity) auf den Client-Dienst angewendet wird, überträgt der Registrierungs- und Start-Dienst auf einen auf Reife wartenden Zustand 70. Reif e. bezieht sich auf die Reif e des Clusters. Ein Cluster ist reif bezüglich einem bestimmten Client-Dienst, wenn wenigstens ein Knoten aus der Liste der zulässigen Knoten up ist und (a) ein primärer Knoten verfügbar ist, (b) genug Knoten up sind oder (c) genug Zeit verstrichen ist. Sobald das Cluster reif ist (70) oder wenn Reife nicht zutrifft, benachrichtigt (72) der Registrierungs- und Start-Dienst den ausgewählten Knoten, damit er den Dienst startet, und die anderen Knoten, dass der Client-Dienst einem bestimmten Knoten zugewiesen worden ist. Der Client-Dienst wird dann aktiviert oder gestartet (74). Mit Ausnahme des unten Beschriebenen (Gruppierung) hat jeder Registrierungs- und Start-Client-Dienst unabhängige Wählfaktoren.
3. Gruppierung
Der Registrierungs- und Startdienst 56 erlaubt es Client-Diensten, miteinander in einer als Gruppierung 76 bekannten Verbindung assoziiert zu sein (16 und 17). Der Gruppierungsmechanismus ist eine Beziehung zwischen einem Parent-Client-Dienst 78 und einem oder mehreren Child-Client-Diensten 80. Zweck dieser Gruppierungsanordnung ist es, den Administrator dann Verbindungen spezifizieren zu lassen, wenn spezifische Dienste zusammen platziert werden müssen. Das Child (Kind) wird immer dort platziert, wo das Parent (Eltern) platziert ist. Child-Dienste haben keine Wählfaktoren; es werden nur die Wählfaktoren der Parents verwendet. Eine Gruppierung 76' kann Child-Dienste 80 aufweisen, die Child-Dienste eines anderen Dienstes 80' sind, der, wiederum das Child von Parent-Dienst 78 ist, wie in 17 illustriert, wären alle Child-Dienste (80 und 80') unter der Platzierung des Parent-Dienstes 78.
Die Registrierung für jedes Child 80 wird ausgesetzt, bis sein Parent-Dienst erfolgreich registriert und sein Startbefehl (start_command), wenn überhaupt, erfolgreich abgeschlossen wurde. Nachdem der Parent-Dienst fertig ist, wird jedes Child bearbeitet. Desgleichen impliziert eine Deregistrierung eines Parent- Dienstes die Deregistrierung der Child-Dienste. Child-Dienste werden zuerst mit Stoppbefehlen (stop_command) deregistriert, die entsprechend aufgerufen werden. Beim Übertragen einer Gruppierung 76 werden gruppierte Child-Dienste 80 immer zuerst gestoppt und zuletzt gestartet.
4. Aktionsfunktionen
Registrierungs- und Startdienst 56 unterstützt veschiedene Aktionen, die als eine Folge von Registrierungstransaktionen stattfinden sollen. Aktionen sind der „Start"-Aspekt des Registrierungs- und Startdienst. Wenn sie mit Gruppierungen 76 und Auswahlparametern 64 kombiniert sind, sorgen Aktionen dafür, dass viele Client-Dienste sich für clusterweite Verfügbarkeit vollständig vom Registrierungs- und Startdienst abhängen können. Einleiten, Migration und Beendigung können mit dem Registrierungs- und Startdienst 56 alle direkt durchgeführt werden.
Der Registrierungs- und Startdienst 56 in der illustrierten Ausgestaltung hat vier Aktionsfunktionen:
Startbefehl (Start_Command) – Die Datenbank wird bei erfolgreicher Registrierung des Client-Dienstes geprüft, um zu bestimmen, ob ein solcher Befehl mit dem Dienst assoziiert ist. Wenn ein solcher Befehl vorliegt, wird der Client-Dienst an dem registrierten Knoten ausgeführt. Die Registrierung ist erst dann vollständig, wenn der Start erfolgreich abgeschlossen wurde. Wenn eine Startoperation erfolglos ist, wird versucht, den Client-Dienst an einem anderen Knoten in der Liste der zulässigen Knoten zu starten.
Stoppbefehl (Stop_Command) – Die Datenbank wird geprüft, um die Anwesenheit dieses Befehls zu bestimmen, wenn ein Client-Dienst seine Beendigung beabsichtigt. Die Deregistrierung ist erst dann vollständig, wenn der Stoppbefehl endet.
Benachrichtigungsbefehl (Notify_Command) – Dieser Befehl stellt einen Mechanismus bereit, wodurch andere Knoten darüber informiert werden, dass der Client-Dienst einem bestimmten Knoten zugewiesen worden ist. Wenn ein Client-Dienst erfolgreich registriert ist, wird die Datenbank geprüft, um zu bestimmen, ob dieser Befehl mit dem Dienst assoziiert ist. Ist dies der Fall, wird er an allen Knoten in der Liste der zulässigen Knoten außer dem registrierten Knoten ausgeführt. Wenn ein Knoten in der Liste der zulässigen Knoten sich dem Cluster anschließt, nachdem ein Dienst registriert worden ist, und der Dienst einen Benachrichtigungsbefehl hat, wird der Befehl an dem neuen Knoten eingeleitet. Das schließt Knoten ein, die das Cluster verlassen und sich ihm später wieder anschließen. Wenn ein Startbefehl vorliegt, wird die Benachrichtigung bis zum erfolgreichen Start ausgesetzt.
Recovery-Befehl (Recovery_Command) – Dieser wird benutzt, wenn ein Knoten das Cluster unkontrolliert verlässt. Für jeden an dem hinausgedrängten Knoten registrierten Dienst wird die Datenbank geprüft, um zu bestimmen, ob mit dem Dienst ein Recovery-Befehl assoziiert ist. Ist dies der Fall, wird er ausgeführt. Der Knoten für den Recovery-Vorgang wird mit Hilfe der Wählparameter 64 bestimmt. Wenn die Wiederherstellung abgeschlossen ist, wird der Dienst deregistriert. Im typischen Fall wird der Dienst dann an einem der überlebenden Knoten registriert und gestartet.
Ein eng mit einer Aktionsfunktion verwandtes Konzept ist das der Übertragung. Die Übertragung eines Dienstes wird durch eine Kombination von zwei Aktionsfunktionen bewerkstelligt. Zunächst wird der Dienst ausgemacht und deregistriert. Zweitens wird er registriert und gestartet. Eine Dienstübertragung kann unter verschiedenen Umständen sehr hilfreich sein. Unter bestimmten Umständen wünscht eventuell der Administrator die Versetzung eines Dienstes. Unter anderen Umständen wird die Übertragungsfunktion zum Übertragen aller Dienste für einen Knoten verwendet, der kontrolliert heruntergefahren wird. Unter noch anderen Umständen kann die Versetzung des Dienstes seiner Art gemäß trivial sein. Weil seine Versetzung keine Auswirkungen hat, kann ein solcher Dienst automatisch übertragen werden, wenn ein bevorzugter Knoten sich dem Cluster anschließt, wenn der Dienst an einem anderen Knoten als einem bevorzugten Knoten platziert ist.
Beim Übertragen eines Client-Dienstes von einem Knoten auf einen anderen wird von dem übertragenen Knoten ein „Transferabsicht"-Flag gesetzt. Die Wirkung des Transferabsicht-Flags auf die Übergänge des Registrierungs- und Startdienstes 56 ist unter Bezugnahme auf 19 zu sehen. Der Registrierungs- und Startdienst 56 hat einen Startzustand 82, einen registrierten Zustand 84, einen Stoppzustand 86, einen deregistrierten Zustand 88 und einen Wiederherstellungszustand 90. Jeder der Stopp-, Start- und Wiederherstellungszustände wird übersprungen, wenn ihr jeweiliger Befehl nicht existiert. Der Startzustand 82 zeigt an, dass der Dienst gerade gestartet wird. Bei erfolgreichem Start schaltet der Dienst in einen registrierten Zustand 84, der anzeigt, dass der Dienst behauptet, an irgendeinem Knoten betriebsfähig zu sein. Der registrierte Dienst transferiert zum Stoppzustand 86, wenn das Transferabsicht-Flag bei einem kontrollierten Verlassen des betriebsfähigen Knotens als Teil der Übertragung zu einem anderen Knoten gesetzt wird. Der registrierte Dienst transferiert als Teil einer externen Deregistrierung oder einer Übertragungsoperation zum Stoppzustand 86. Nach Abschluss des Stoppbefehls geht der Dienst vom Stoppzustand 86 in den deregistrierten Zustand 88 über, was anzeigt, dass der Dienst derzeit nicht registriert ist und dass derzeit keine Knotenübergänge ablaufen. Ein Dienst, der übertragen wird, geht normalerweise unmittelbar vom deregistrieren Zustand 88 in den Startzustand 82 über. Der Wiederherstellungszustand 90 findet nur statt, wenn ein Knoten das Cluster unkontrolliert verlässt, während der Dienst im registrierten Zustand 84 oder im Stoppzustand 86 war. Ein ausführlicheres Zustandsübergangsdiagramm ist in 20 dargestellt und illustriert verschiedene Zwischenzustände.
Tabelle 2 illustriert ein Beispiel eines Zustandsübergangs in einem Drei-Knoten-Cluster mit Knoten NO, N1 und N2. Das Beispiel basiert darauf, dass Knoten NO und Knoten N1 die zulässigen Knoten sind mit einem Maturity_Count (Reifezahl) gleich 2 und einer Maturity_Time (Reifezeit) gleich 5. Auto Register ist auf automatisch eingestellt. Das Beispiel gilt für einen Einzel-Client-Dienst. Im Beispiel sind anfänglich alle Knoten heruntergefahren. Zum Zeitpunkt t₁ bootet der Knoten N2, sodass der Status des Knotens auf einen up-Zustand wechselt. Für den Dienst findet keine Änderung statt, weil Knoten N2 nicht in der Liste der zulässigen Knoten ist. Zum Zeitpunkt t₂ wartet der Dienst auf Cluster-Reife und Knoten N0 bootet. Zum Zeitpunkt t₃ verstreicht die Reifezeit und der Dienst-Startbefehl wird an Knoten N0 ausgeführt. Der Start wird am Zeitpunkt t₄ abgeschlossen und der Dienst wird am Knoten NO registriert. Zum Zeitpunkt t₅ bootet Knoten N1. Weil der Dienst bereits registriert ist, findet keine Aktion statt. Wenn aber eine „Benachrichtigungsaktion" definiert ist, würde sie zu diesem Zeitpunkt am Knoten N1 ausgeführt werden. Am Zeitpunkt t₆ scheidet der Knoten N2 kontrolliert aus dem Cluster aus, was auch keinen Einfluss auf den Dienst hat. Zum Zeitpunkt t₇ beginnt der Knoten N0 ein kontrolliertes Ausscheiden. Dies hat zur Folge, dass der Dienst im Stoppzustand mit gesetzter Transferabsicht ist. Das Stoppen ist zum Zeitpunkt t₈ abgeschlossen. Der Dienst wird zum Zeitpunkt t₉ auf den Knoten N1 im Startzustand übertragen. Der Dienst wird zum Zeitpunkt t₁₀ an N1 registriert, wenn der Start abgeschlossen wird. Zum Zeitpunkt t₁₁ schließt der Knoten N0 das kontrollierte Ausscheiden ab und wird heruntergefahren. Dies stellt keine Änderung in der Datenbank dar, weil der up/down-Zustand eines Knotens kein in der Datenbank geführter Zustand ist. Am Zeitpunkt t₁₂ beginnt der Knoten N1 ein kontrolliertes Ausscheiden, was den Dienst in einen Stoppzustand versetzt. Wenn Stopp zum Zeitpunkt t₁₃ abgeschlossen ist, wird der Dienst deregistriert und das Transferabsicht-Flag wird gelöscht.
TABELLE 2 ZUSTANDSÜBERGANGSBEISPIEL A
In einem in Tabelle 3 illustrierten Beispiel wird Knoten N0 als ein bevorzugter Knoten definiert und die übrigen Knoten als zulässig. Maturity_Count ist auf 2 gesetzt. Auto_Register ist auf automatisch gesetzt. Placement_Policy ist auf register_on_one gesetzt. Transfer_cost ist frei. Zu Anfang des Beispiels sind die drei Knoten N0, N1 und N2 im Cluster alle down. An Zeitpunkt t₁ bootet der Knoten N0 und der Dienst tritt an Knoten N0 in den Startzustand ein. An Zeitpunkt t₂ kommt der Start zum Abschluss und der Dienst wird an Knoten NO registriert. An Zeitpunkt t₃ bootet der Knoten N1 und wird benachrichtigt, dass der Dienst an Knoten N0 registriert ist. Zwischen den Zeitpunkten t₄ und t, scheidet der Knoten N0 kontrolliert aus dem Cluster aus. Der Dienst wird auf Knoten N1 übertragen und dort registriert. An Zeitpunkt t₈ bootet der Knoten N2 und wird benachrichtigt, dass der Dienst an Knoten N1 registriert ist. An Zeitpunkt t₉ bootet der Knoten N0 und wird benachrichtigt, dass der Dienst an Knoten 1 registriert ist. An Zeitpunkt t₁₀, kurz nach seinem Booten, bemerkt der Knoten NO, dass freie Übergänge erlaubt sind und dass er gegenüber Knoten N1 bevorzugt wird. Der Knoten N0 leitet automatisch eine Übertragung ein. Der Dienst tritt in den Stoppzustand 86 ein und das Stoppen kommt am Zeitpunkt t₁₁ zum Abschluss. An Zeitpunkt t₁₂ tritt der Dienst am Knoten N0 in den Startzustand ein. Der Start kommt am Zeitpunkt t₁₃ zum Abschluss, und der Dienst wird am Knoten N0 registriert. Die Knoten N1 und N2 werden benachrichtigt, dass der Dienst am Knoten N0 registriert ist.
TABELLE 3 ZUSTANDSÜBERGANGSBEISPIEL B
5. Ereignismanager-Dämon
Registrierungs- und Startdienst 56 fordert automatisch den Ereignismanager-Dämon 58 zum Überwachen auf einen Zustand an, der sich auf einen Client-Dienst bezieht. Der Registrierungs- und Startdienst fordert den Ereignismanager-Dämon zum Aktivieren dieser Ereignisgruppe (Event Group) bei der Registrierung des Dienstes und zum Deaktivieren der Ereignisgruppe in Reaktion auf die Deregistrierung des Dienstes an. Wenn der Ereignismanager-Dämon 58 ein Problem feststellt, wird eine Ereignisaktion 62 zum Lösen des Problems aufgerufen.
An den Registrierungs- und Startdienst wird keine direkte Kommunikation zurückgesendet.
Tabelle 4 illustriert die Felder, die mit einem vom Ereignismanager-Dämon 58 überwachten Ereignis assoziiert sind. Zusätzlich zum Ereignisnamensfeld gibt es Felder für IN-Parameter und OUT-Parameter, die das Ereignis definieren, auf dessen Feststellung die zutreffende Ereignisüberwachung eingestellt ist, und die OUT-Parameter werden ausgefüllt, wenn das Ereignis stattfindet. Die Ausgabe wird für die Aktionsfunktion 62 verfügbar gemacht, die mit dem betreffenden Ereignis assoziiert ist. Ereignisgruppen (Event_Groups) werden verwendet, um ansonsten unabhängige Ereignisse logisch zu assoziieren, um anzugeben, wann, wo und unter welchen Bedingungen sie zu aktivieren sind.
TABELLE 4 EREIGNISMANAGER-DÄMON
Im Ereignismanager-Subsystem 54 ist der Ereignismanager-Dämon 58 das Steuerzentrum. Alle Überwachungen 60a–60g sind über eine Kommunikationsbibliothek mit dem Ereignismanager-Dämon verbunden. Eine der Überwachungen im Ereignismanager-Subsystem 54 ist die Mitgliedschaftsmanager-Überwachung 60e, die auf die zuvor beschriebene Weise Benachrichtigungen über Knotenübergänge vom Mitgliedschaftsmanager-Subsystem 46 erhält und eine. Schnittstelle zum Übergangsbenachrichtigungsrahmen 44 bereitstellt. Das Ereignismanager-Subsystem 54 sorgt dafür, dass dem Registrierungs- und Startdienst 56 derartige Knotenübergänge bewusst sind.
Ein Beispiel einer Anwendung, für die der Registrierungs- und Startdienst 56 besonders zutreffend ist, ist die Bereitstellung eines Server mit fließender Lizenz am Cluster-System. Die lizenzierte Software könnte als ein Dienst eingerichtet werden und auf einer bestimmten Zahl von Knoten im Cluster ausführen dürfen. Der Registrierungs- und Startdienst arbeitet das Startprogramm ab, das die lizenzierte Software auf einem der Knoten aufruft. Wenn dieser Knoten kontrolliert oder unkontrolliert heruntergefahren wird, überträgt der Registrierungs- und Startdienst die lizenzierte Software nach der Wiederherstellung, wenn das Ausscheiden unkontrolliert war, auf einen neuen Knoten.
So ist zu sehen, dass die vorliegende Erfindung einen eng koordinierten Cluster-Mitgliedschaftsmanager-Rahmen bereitstellt, der das Anschließen oder Ausscheiden unter allen Knoten in einem Cluster koordiniert, einschließlich dem Hindurchführen der mehreren Schichten von beteiligten Subsysteme durch die Übergänge. Eines der Subsysteme kann im Benutzerraum sein und führt die Übertragungen von Client-Diensten durch, einschließlich Benutzeranwendungen, die sich aus dem Anschließen von Knoten an das Cluster und dem Ausscheiden von Knoten aus dem Cluster ergeben. Andere Benutzerraumanwendungen können sich während der Laufzeit beim Mitgliedschaftsmanager-Übergangsbenachrichtigungsrahmen registrieren. Somit wird ein robustes System bereitgestellt, das die hohe Gesamtleistung der Multiprozessor-Cluster-Technologie verbessert.
Die vorliegende Ausgestaltung erleichtert die Verwendung von Multiprozessor-Clustersystemen mit Betriebssystemen, die mehrere Subsysteme haben, die in Schichten angeordnet sind, indem sie alle beteiligten Subsysteme durch Knotenübergänge führt. Außerdem verleiht sie nicht clusterbewussten Client-Diensten, zu denen eine Vielfalt verschiedener Rechenaktivitäten einschließlich Benutzeranwendungen zählen, Clusterbewusstsein. Dies erlaubt es Benutzern, das Clustersystem als eine einzelne Einheit zu behandeln, wobei das Clustersystem dem Client-Dienst clusterweite Verfügbarkeit verleiht, einschließlich der Einleitung des Client-Dienstes an einem bestimmten Knoten, der Migration des Client-Dienstes zwischen Knoten und der Beendigung des Client-Dienstes.
Änderungen und Modifikationen in den speziell beschriebenen Ausgestaltungen können ohne Abweichen von den Grundsätzen der Erfindung durchgeführt werden, deren Begrenzung nur durch den Umfang der anhängigen Ansprüche vorgesehen ist.

Claims

Betriebsverfahren für ein Multiprozessorsystem mit mehreren Knoten, einer gemeinsamen, für alle Knoten zugänglichen Ressource und mehreren interdependenten Ebenen von Betriebssystem-Subsystemen auf jedem der genannten Knoten, wobei das Verfahren die folgenden Schritte umfasst: Kombinieren spezieller der genannten Knoten in einem Cluster, der Benutzern des genannten Systems im Wesentlichen als ein vereintes System erscheint, und Benachrichtigen der Ebenen von Subsystemen, die auf gegenwärtig in dem Cluster befindlichen Knoten abgearbeitet werden, über Übergänge von sich dem Cluster anschließenden und es verlassenden Knoten, um eine konsistente Ansicht aktiver Mitgliedschaft in dem Cluster bereitzustellen.
Verfahren nach Anspruch 1, bei dem die Subsysteme in Ebenen interdependent sind, wobei Subsysteme höherer Ebenen von dem Betrieb von Subsystemen niedrigerer Ebenen abhängig sind.
Verfahren nach Anspruch 2, das die Benachrichtigung von einem der genannten Subsysteme auf allen der genannten, gegenwärtig in dem Cluster befindlichen Knoten über einen Übergang und das Verarbeiten dieser Benachrichtigung an dem genannten einen der genannten Subsysteme, bevor ein weiteres der genannten Subsysteme auf allen der genannten, gegenwärtig in dem Cluster befindlichen Knoten über den Übergang benachrichtigt wird, aufweist.
Verfahren nach Anspruch 3, das das Benachrichtigen von Subsystemen, angefangen mit Subsystemen niedrigerer Ebene und der Reihe nach durch höhere Subsystemebenen fortschreitend, über einen Übergang eines sich dem Cluster anschließenden Knotens aufweist.
Verfahren nach Anspruch 3, das das Benachrichtigen von Subsystemen, angefangen mit Subsystemen höherer Ebene und der Reihe nach durch niedrigere Subsystemebenen fortschreitend; über einen Übergang eines das Cluster kontrolliert verlassenden Knotens aufweist.
Verfahren nach Anspruch 3, das das Benachrichtigen von Subsystemen, angefangen mit Subsystemen niedrigerer Ebene und der Reihe nach durch höhere Subsystemebenen fortschreitend, über einen Übergang eines von anderen Prozessoren aus dem Cluster gedrängten Knotens aufweist.
Verfahren nach einem der Ansprüche 2 bis 6, bei dem die genannten Subsysteme ein Subsystem höherer Ebene aufweisen, das mit Benutzerprogrammen interagiert.
Verfahren nach Anspruch 7, bei dem das genannte Subsystem höherer Ebene einen Dienst aufweist, der Benutzerprogramme automatisch und atomisch zu anderen Knoten transferiert, wenn der die Benutzerprogramme ausführende Knoten das Cluster verlässt.
Verfahren nach einem der Ansprüche 2 bis 8, bei dem die genannten Subsysteme ein Verteilter-Sperrenmanager-Subsystem, ein Virtueller-Diskmanager-Subsystem und ein Gemeinschaftsdatei-Subsystem aufweisen.
Verfahren nach einem der Ansprüche 1 bis 9, bei dem das genannte Verfahren für einen Übergang eines sich dem Cluster anschließenden Knotens die folgenden Schritte aufweist: a) Registrieren von Subsystemen des sich anschließenden Knotens zum Empfangen von Übergangsbenachrichtigungen, b) Anschließen des Knotens an das Cluster und c) Benachrichtigen registrierter Subsysteme in dem Cluster darüber, dass der sich anschließende Knoten sich dem Cluster angeschlossen hat.
Verfahren nach einem der Ansprüche 1 bis 10, bei dem das genannte Verfahren für einen Übergang eines von einem anderen Knoten aus dem Cluster gedrängten Knotens die folgenden Schritte aufweist: a) Benachrichtigen registrierter Subsysteme durch den anderen Knoten darüber, dass der eine Knoten aus dem Cluster gedrängt wird, und b) Übertragen registrierter Programme, die auf dem genannten einen Knoten ausgeführt werden, atomisch auf einen anderen Knoten und Wiederherstellen der Programme zum Ausführen auf dem genannten anderen Knoten.
Verfahren nach einem der Ansprüche 1 bis 11 einschließlich Initiieren von Client-Diensten auf speziellen der genannten Knoten in einem Cluster auf eine Weise, die den Client-Diensten im Wesentlichen als ein vereintes System erscheint, Wählen eines Knotens für jeden Client-Dienst, Registrieren des Client-Dienstes bei diesem Knoten und Benachrichtigen von gegenwärtig in dem Cluster befindlichen Knoten darüber, dass der spezielle Client-Dienst bei dem speziellen Knoten registriert ist, wodurch der spezielle Dienst auf einen anderen Knoten übertragen werden kann, wenn der spezielle Knoten das Cluster verlässt.
Verfahren nach Anspruch 12, das ferner das Starten eines Client-Dienstes auf einem Knoten gemäß einem in dem Client-Dienst enthaltenen Aktionsparameter in Reaktion auf das Registrieren dieses Client-Dienstes bei diesem Knoten aufweist.
Verfahren nach Anspruch 13, das ferner das Gruppieren von Client-Diensten als Eltern-Client-Dienst und wenigstens einen Kind-Client-Dienst, das Registrieren gruppierter Client-Dienste bei dem gleichen Knoten und das Starten gruppierter Client-Dienste gemäß einem in dem Eltern-Client-Dienst enthaltenen Aktionsparameter aufweist.
Verfahren nach Anspruch 12, 13 oder 14, bei dem das genannte Wählen eines Knotens das Bereitstellen einer Datenbank von Wählfaktoren für den Client-Dienst und das Anwenden der genannten Wählfaktoren auf die gegenwärtig in dem Cluster befindlichen Knoten aufweist, wobei die genannten Wählfaktoren Regeln festlegen, die Knoten mit dem Client-Dienst in Bezug setzen.
Verfahren nach Anspruch 15, bei dem die genannten Wählfaktoren aus der Gruppe ausgewählt werden, die zulässige Knoten, nicht zulässige Knoten und Knotenpräferenzen aufweist.
Verfahren nach einem der Ansprüche 12 bis 16, das ferner das Benachrichtigen vor sich an das Cluster anschließenden Knoten darüber aufweist, dass der spezielle Client-Dienst bei den speziellen Knoten registriert ist.
Verfahren nach einem der Ansprüche 12 bis 17, das die Überwachung eines bei einem Knoten registrierten Client-Dienstes unter Verwendung einer Ereignisüberwachung an diesem Knoten aufweist.
Verfahren nach Anspruch 18, das das Aktivieren der Ereignisüberwachung in Reaktion auf das Registrieren des Client-Dienstes und das Deaktivieren der Ereignisüberwachung in Reaktion auf das Deregistrieren des Client-Dienstes aufweist.
Verfahren nach einem der Ansprüche 12 bis 19, bei dem die genannten mehreren Subsysteme einen Cluster-Mitgliedschaftsmanager haben, der bestimmt, welche der genannten Knoten gegenwärtig in dem Cluster sind, und bei dem der genannte Cluster-Mitgliedschaftsmanager Benachrichtigung darüber bereitstellt, welche Knoten in dem Cluster sind.
Verfahren nach Anspruch 20, bei dem das genannte Initiieren von Diensten auf einem speziellen der genannten Knoten von einem anderen der genannten mehreren Subsysteme durchgeführt wird.
Verfahren nach einem der Ansprüche 1 bis 21, das das Initiieren von Client-Diensten auf speziellen der genannten Knoten in einem Cluster auf eine Weise, die dem Client-Dienst im Wesentlichen als ein vereintes System erscheint, das Registrieren eines Client-Dienstes bei einem der genannten Knoten und das Starten des Client-Dienstes auf diesem Knoten gemäß einem von dem Client- Dienst aufgewiesenen Aktionsparameter in Reaktion auf das Registrieren dieses Benutzer-Dienstes bei diesem Knoten aufweist.
Verfahren nach Anspruch 22, das das Transferieren des Client-Dienstes zu einem anderen Knoten aufweist, wenn dieser Knoten das Cluster verlässt.
Verfahren nach Anspruch 23, bei dem das genannte Transferieren das Neustarten des Client-Dienstes auf dem anderen Knoten gemäß dem genannten Aktionsparameter aufweist.
Multiprozessor-Cluster-System, umfassend: mehrere Knoten (26), eine gemeinsame Ressource (28), die für alle Knoten zugänglich ist, ein Cluster-Kommunikationsmedium (36) zwischen den genannten Knoten, mehrere interdependente Ebenen von Betriebssystem-Subsystemen (46–54) auf jedem der genannten Knoten, wobei die genannten Subsysteme ein Cluster-Mitgliedschaftsmanager-Subsystem (46) zum Benachrichtigen von Subsystemen, die auf gegenwärtig in dem Cluster befindlichen Knoten abgearbeitet werden, über sich dem Cluster anschließende und es verlassende Knoten aufweist, um eine konsistente Ansicht aktiver Mitgliedschaft in dem Cluster bereitzustellen, und ein Registrierungs- und Start-Subsystem (56) zum Initiieren von Client-Diensten auf speziellen der genannten Knoten in einem Cluster auf eine Weise, die den Client-Diensten im Wesentlichen als ein vereinter Knoten erscheint, wobei das genannte Registrierungs- und Start-Subsystem einen Knoten für jeden Client-Dienst wählt, den Client-Dienst bei diesem Knoten registriert und gegenwärtig in dem Cluster befindliche Knoten darüber benachrichtigt, dass der spezielle Dienst bei dem speziellen Knoten registriert ist.
Multiprozessor-Cluster-System nach Anspruch 25, bei dem die Subsysteme in Ebenen interdependent sind, wobei Subsysteme höherer Ebenen von dem Betrieb von Subsystemen niedrigerer Ebenen abhängig sind.
Multiprozessor-Cluster-System nach Anspruch 26, bei dem das genannte Mitgliedschaftsmanager-Subsystem (46) eines der genannten Subsysteme auf allen der genannten, gegenwärtig in dem Cluster befindlichen Knoten über einen Übergang benachrichtigt und dieses genannte eine der genannten Subsysteme auf allen Knoten diese Benachrichtigung verarbeitet, bevor das genannte Mitgliedschaftsmanager-Subsystem ein weiteres der genannten Subsysteme auf allen der genannten, gegenwärtig in dem Cluster befindlichen Knoten über den Übergang benachrichtigt.
Multiprozessor-Cluster-System nach Anspruch 27, bei dem das genannte Mitgliedschaftsmanager-Subsystem (46) Subsysteme angefangen mit Subsystemen niedrigerer Ebene und der Reihe nach durch höhere Subsystemebenen fortschreitend über einen Übergang eines sich dem Cluster anschließenden Knotens benachrichtigt.
Multiprozessor-Cluster-System nach Anspruch 27 oder Anspruch 28, bei dem das genannte Mitgliedschaftsmanager-Subsystem (46) Subsysteme angefangen mit Subsystemen höherer Ebene und der Reihe nach durch niedrigere Subsystemebenen fortschreitend über einen Übergang eines das Cluster kontrolliert verlassenden Knotens benachrichtigt.
Multiprozessor-Cluster-System nach Anspruch 27, 28 oder 29, bei dem das genannte Mitgliedschaftsmanager-Subsystem (46) Subsysteme angefangen mit Subsystemen niedrigerer Ebene und der Reihe nach durch höhere Subsystemebenen fortschreitend über einen Übergang eines von anderen Prozessoren aus dem Cluster gedrängten Knotens benachrichtigt.
Multiprozessor-Cluster-System nach einem der Ansprüche 25 bis 30, bei dem das genannte Registrierungs- und Start-Subsystem (56) einen Client-Dienst auf einem Knoten gemäß einem in den Client-Dienst eingeschlossenen Aktionsparameter in Reaktion auf das Registrieren dieses Client-Dienstes bei diesem Knoten startet.
Multiprozessor-Cluster-System nach Anspruch 31, bei dem das genannte Registrierungs- und Start-Subsystem (56) zum Gruppieren von Client-Diensten als einen Eltern-Client-Dienst und wenigstens einen Kind-Client-Dienst ausgeführt ist und bei dem das genannte Registrierungsund Start-Subsystem ferner gruppierte Client-Dienste bei dem gleichen Knoten registriert und gruppierte Client-Dienste gemäß einem in den Eltern-Client-Dienst eingeschlossenen Aktionsparameter startet.
Multiprozessor-Cluster-System nach einem der Ansprüche 25 bis 32, bei dem das genannte Registrierungsund Start-Subsystem (56) eine Datenbank mit Wählfaktoren für den Client-Dienst aufweist und die genannten Wählfaktoren auf die gegenwärtig in dem Cluster befindlichen Knoten anwendet, um den Knoten zum Registrieren eines Client-Dienstes zu wählen, wobei die genannten Wählfaktoren Regeln festlegen, die Knoten mit dem Client-Dienst in Bezug setzen.
Multiprozessor-Cluster-System nach einem der Ansprüche 25 bis 33, bei dem das genannte Registrierungsund Start-Subsystem (56) ferner sich an das Cluster anschließende Knoten darüber benachrichtigt, dass der spezielle Client-Dienst bei dem speziellen Knoten registriert ist.
Multiprozessor-Cluster-System nach einem der Ansprüche 25 bis 34, das ein Ereignismanager-Subsystem (54) zum Feststellen von Clusterfehlern und zum Reagieren auf sie aufweist und bei dem das Registrierungs- und Start-Subsystem (56) auf das Ereignismanager-Subsystem reagiert.
Multiprozessor-Cluster-System nach Anspruch 35, bei dem das genannte Ereignismanager-Subsystem (54) eine Ereignisüberwachung (60) zum Überwachen eines bei einem Knoten registrierten Client-Dienstes an diesem Knoten aufweist.
Computer-geeignetes Medium, in das Programmcode eingegliedert ist, wobei der genannte Programmcode ein Betriebssystem für ein Multiprozessor-Cluster-System definiert, das mehrere Knoten (26) hat, eine gemeinsame, für alle Prozessoren zugängliche Ressource (28) und mehrere interdependente Ebenen von Subsystemen (46–54) aufweist, wobei eines der genannten Subsysteme ein Cluster-Mitgliedschaftsmanager-Subsystem (46) zum Kombinieren spezieller der genannten Knoten in einem Cluster ist, das Benutzern des genannten Systems im Wesentlichen als ein vereintes System erscheint, wobei der genannte Cluster-Mitgliedschaftsmanager zum Benachrichtigen der Ebenen von Subsystemen, die auf gegenwärtig in einem Cluster befindlichen Knoten abgearbeitet werden, über Übergänge von sich dem Cluster anschließenden und es verlassenden Knoten ausgeführt ist, um eine konsistente Ansicht aktiver Mitgliedschaft in dem Cluster bereitzustellen.
Computer-geeignetes Medium nach Anspruch 37, wobei das Betriebssystem ferner einen Registrierungs- und Start-Dienst (56) hat zum Initiieren von Client-Diensten an speziellen von Knoten in einem Cluster auf eine Weise, die den Client-Diensten im Wesentlichen als ein vereintes System erscheint, wobei der genannte Registrierungs- und Start-Dienst einen Knoten für jeden Client-Dienst wählt, den Client-Dienst bei diesem Knoten registriert und gegenwärtig in dem Cluster befindliche Knoten darüber benachrichtigt, dass der spezielle Dienst bei dem speziellen Knoten registriert ist.
Betriebsverfahren für ein Multiprozessorsystem mit mehreren Knoten, einer gemeinsamen, für alle Knoten zugänglichen Ressource und mehreren interdependenten Ebenen von Betriebssystem-Subsystemen auf jedem der genannten Knoten, wobei das Verfahren die folgenden Schritte umfasst: Kombinieren spezieller der genannten Knoten in einem Cluster, der Benutzern des genannten Systems im Wesentlichen als ein vereintes System erscheint, und Benachrichtigen der Ebenen von Subsystemen, die auf gegenwärtig in dem Cluster befindlichen Knoten abgearbeitet werden, über Übergänge von sich dem Cluster anschließenden und es verlassenden Knoten, um eine konsistente Ansicht aktiver Mitgliedschaft in dem Cluster bereitzustellen.
Verfahren nach Anspruch 1, bei dem die Subsysteme in Ebenen interdependent sind, wobei Subsysteme höherer Ebenen von dem Betrieb von Subsystemen niedrigerer Ebenen abhängig sind.
Verfahren nach Anspruch 2, das die Benachrichtigung von einem der genannten Subsysteme auf allen der genannten, gegenwärtig in dem Cluster befindlichen Knoten über einen Übergang und das Verarbeiten dieser Benachrichtigung an dem genannten einen der genannten Subsysteme, bevor ein weiteres der genannten Subsysteme auf allen der genannten, gegenwärtig in dem Cluster befindlichen Knoten über den Übergang benachrichtigt wird, aufweist.
Verfahren nach Anspruch 3, das das Benachrichtigen von Subsystemen, angefangen mit Subsystemen niedrigerer Ebene und der Reihe nach durch höhere Subsystemebenen fortschreitend, über einen Übergang eines sich dem Cluster anschließenden Knotens aufweist.
Verfahren nach Anspruch 3, das das Benachrichtigen von Subsystemen, angefangen mit Subsystemen höherer Ebene und der Reihe. nach durch niedrigere Subsystemebenen fortschreitend, über einen Übergang eines das Cluster kontrolliert verlassenden Knotens aufweist.
Verfahren nach Anspruch 3, das das Benachrichtigen von Subsystemen, angefangen mit Subsystemen niedrigerer Ebene und der Reihe nach durch höhere Subsystemebenen fortschreitend, über einen Übergang eines von anderen Prozessoren aus dem Cluster gedrängten Knotens aufweist.
Verfahren nach einem der Ansprüche 2 bis 6, bei dem die genannten Subsysteme ein Subsystem höherer Ebene aufweisen, das mit Benutzerprogrammen interagiert.
Verfahren nach Anspruch 7, bei dem das genannte Subsystem höherer Ebene einen Dienst aufweist, der Benutzerprogramme automatisch und atomisch zu anderen Knoten transferiert, wenn der die Benutzerprogramme ausführende Knoten das Cluster verlässt.
Verfahren nach einem der Ansprüche 2 bis 8, bei dem die genannten Subsysteme ein Verteilter-Sperrenmanager-Subsystem, ein Virtueller-Diskmanager-Subsystem und ein Gemeinschaftsdatei-Subsystem aufweisen.
Verfahren nach einem der Ansprüche 1 bis 9, bei dem das genannte Verfahren für einen Übergang eines sich dem Cluster anschließenden Knotens die folgenden Schritte aufweist: a) Registrieren von Subsystemen des sich anschließenden Knotens zum Empfangen von Übergangsbenachrichtigungen, b) Anschließen des Knotens an das Cluster und c) Benachrichtigen registrierter Subsysteme in dem Cluster darüber, dass der sich anschließende Knoten sich dem Cluster angeschlossen hat.
Verfahren nach einem der Ansprüche 1 bis 10, bei dem das genannte Verfahren für einen Übergang eines von einem anderen Knoten aus dem Cluster gedrängten Knotens die folgenden Schritte aufweist: a) Benachrichtigen registrierter Subsysteme durch den anderen Knoten darüber, dass der eine Knoten aus dem Cluster gedrängt wird, und b) Übertragen registrierter Programme, die auf dem genannten einen Knoten ausgeführt werden, atomisch auf einen anderen Knoten und Wiederherstellen der Programme zum Ausführen auf dem genannten anderen Knoten.
Verfahren nach einem der Ansprüche 1 bis 11 einschließlich Initiieren von Client-Diensten auf speziellen der genannten Knoten in einem Cluster auf eine Weise, die den Client-Diensten im Wesentlichen als ein vereintes System erscheint, Wählen eines Knotens für jeden Client-Dienst, Registrieren des Client-Dienstes bei diesem Knoten und Benachrichtigen von gegenwärtig in dem Cluster befindlichen Knoten darüber, dass der spezielle Client-Dienst bei dem speziellen Knoten registriert ist, wodurch der spezielle Dienst auf einen anderen Knoten übertragen werden kann, wenn der spezielle Knoten das Cluster verlässt.
Verfahren nach Anspruch 12, das ferner das Starten eines Client-Dienstes auf einem Knoten gemäß einem in dem Client-Dienst enthaltenen Aktionsparameter in Reaktion auf das Registrieren dieses Client-Dienstes bei diesem Knoten aufweist.
Verfahren nach Anspruch 13, das ferner das Gruppieren von Client-Diensten als Eltern-Client-Dienst und wenigstens einen Kind-Client-Dienst, das Registrieren gruppierter Client-Dienste bei dem gleichen Knoten und das Starten gruppierter Client-Dienste gemäß einem in dem Eltern-Client-Dienst enthaltenen Aktionsparameter aufweist.
Verfahren nach Anspruch 12, 13 oder 14, bei dem das genannte Wählen eines Knotens das Bereitstellen einer Datenbank von Wählfaktoren für den Client-Dienst und das Anwenden der genannten Wählfaktoren auf die gegenwärtig in dem Cluster befindlichen Knoten aufweist, wobei die genannten Wählfaktoren Regeln festlegen, die Knoten mit dem Client-Dienst in Bezug setzen.
Verfahren nach Anspruch 15, bei dem die genannten Wählfaktoren aus der Gruppe ausgewählt werden, die zulässige Knoten, nicht zulässige Knoten und Knotenpräferenzen aufweist.
Verfahren nach einem der Ansprüche 12 bis 16, das ferner das Benachrichtigen von sich an das Cluster anschließenden Knoten darüber aufweist, dass der spezielle Client-Dienst bei den speziellen Knoten registriert ist.
Verfahren nach einem der Ansprüche 12 bis 17, das die Überwachung eines bei einem Knoten registrierten Client-Dienstes unter Verwendung einer Ereignisüberwachung an diesem Knoten aufweist.
Verfahren nach Anspruch 18, das das Aktivieren der Ereignisüberwachung in Reaktion auf das Registrieren des Client-Dienstes und das Deaktivieren der Ereignisüberwachung in Reaktion auf das Deregistrieren des Client-Dienstes aufweist.
Verfahren nach einem der Ansprüche 12 bis 19, bei dem die genannten mehreren Subsysteme einen Cluster-Mitgliedschaftsmanager haben, der bestimmt, welche der genannten Knoten gegenwärtig in dem Cluster sind, und bei dem der genannte Cluster-Mitgliedschaftsmanager Benachrichtigung darüber bereitstellt, welche Knoten in dem Cluster sind.
Verfahren nach Anspruch 20, bei dem das genannte Initiieren von Diensten auf einem speziellen der genannten Knoten von einem anderen der genannten mehreren Subsysteme durchgeführt wird.
Verfahren nach einem der Ansprüche 1 bis 21, das das Initiieren von Client-Diensten auf speziellen der genannten Knoten in einem Cluster auf eine Weise, die dem Client-Dienst im Wesentlichen als ein vereintes System erscheint, das Registrieren eines Client-Dienstes bei einem der genannten Knoten und das Starten des Client-Dienstes auf diesem Knoten gemäß einem von dem Client- Dienst aufgewiesenen Aktionsparameter in Reaktion auf das Registrieren dieses Benutzer-Dienstes bei diesem Knoten aufweist.
Verfahren nach Anspruch 22, das das Transferieren des Client-Dienstes zu einem anderen Knoten aufweist, wenn dieser Knoten das Cluster verlässt.
Verfahren nach Anspruch 23, bei dem das genannte Transferieren das Neustarten des Client-Dienstes auf dem anderen Knoten gemäß dem genannten Aktionsparameter aufweist.
Multiprozessor-Cluster-System, umfassend: mehrere Knoten (26), eine gemeinsame Ressource (28), die für alle Knoten zugänglich ist, ein Cluster-Kommunikationsmedium (36) zwischen den genannten Knoten, mehrere interdependente Ebenen von Betriebssystem-Subsystemen (46–54) auf jedem der genannten Knoten, wobei die genannten Subsysteme ein Cluster-Mitgliedschaftsmanager-Subsystem (46) zum Benachrichten von Subsystemen, die auf gegenwärtig in dem Cluster befindlichen Knoten abgearbeitet werden, über sich dem Cluster anschließende und es verlassende Knoten aufweist, um eine konsistente Ansicht aktiver Mitgliedschaft in dem Cluster bereitzustellen, und ein Registrierungs- und Start-Subsystem (56) zum Initiieren von Client-Diensten auf speziellen der genannten Knoten in einem Cluster auf eine Weise, die den Client-Diensten im Wesentlichen als ein vereinter Knoten erscheint, wobei das genannte Registrierungs- und Start-Subsystem einen Knoten für jeden Client-Dienst wählt, den Client-Dienst bei diesem Knoten registriert und gegenwärtig in dem Cluster befindliche Knoten darüber benachrichtigt, dass der spezielle Dienst bei dem speziellen Knoten registriert ist.
Multiprozessor-Cluster-System nach Anspruch 25, bei dem die Subsysteme in Ebenen interdependent sind, wobei Subsysteme höherer Ebenen von dem Betrieb von Subsystemen niedrigerer Ebenen abhängig sind.
Multiprozessor-Cluster-System nach Anspruch 26, bei dem das genannte Mitgliedschaftsmanager-Subsystem (46) eines der genannten Subsysteme auf allen der genannten, gegenwärtig in dem Cluster befindlichen Knoten über einen Übergang benachrichtigt und dieses genannte eine der genannten Subsysteme auf allen Knoten diese Benachrichtigung verarbeitet, bevor das genannte Mitgliedschaftsmanager-Subsystem ein weiteres der genannten Subsysteme auf allen der genannten, gegenwärtig in dem Cluster befindlichen Knoten über den Übergang benachrichtigt.
Multiprozessor-Cluster-System nach Anspruch 27, bei dem das genannte Mitgliedschaftsmanager-Subsystem (46) Subsysteme angefangen mit Subsystemen niedrigerer Ebene und der Reihe nach durch höhere Subsystemebenen fortschreitend über einen Übergang eines sich dem Cluster anschließenden Knotens benachrichtigt.
Multiprozessor-Cluster-System nach Anspruch 27 oder Anspruch 28, bei dem das genannte Mitgliedschaftsmanager-Subsystem (46) Subsysteme angefangen mit Subsystemen höherer Ebene und der Reihe nach durch niedrigere Subsystemebenen fortschreitend über einen Übergang eines das Cluster kontrolliert verlassenden Knotens benachrichtigt.
Multiprozessor-Cluster-System nach Anspruch 27, 28 oder 29, bei dem das genannte Mitgliedschaftsmanager-Subsystem (46) Subsysteme angefangen mit Subsystemen niedrigerer Ebene und der Reihe nach durch höhere Subsystemebenen fortschreitend über einen Übergang eines von anderen Prozessoren aus dem Cluster gedrängten Knotens benachrichtigt.
Multiprozessor-Cluster-System nach einem der Ansprüche 25 bis 30, bei dem das genannte Registrierungsund Start-Subsystem (56) einen Client-Dienst auf einem Knoten gemäß einem in den Client-Dienst eingeschlossenen Aktionsparameter in Reaktion auf das Registrieren dieses Client-Dienstes bei diesem Knoten startet.
Multiprozessor-Cluster-System nach Anspruch 31, bei dem das genannte Registrierungs- und Start-Subsystem (56) zum Gruppieren von Client-Diensten als einen Eltern-Client-Dienst und wenigstens einen Kind-Client-Dienst ausgeführt ist und bei dem das genannte Registrierungsund Start-Subsystem ferner gruppierte Client-Dienste bei dem gleichen Knoten registriert und gruppierte Client-Dienste gemäß einem in den Eltern-Client-Dienst eingeschlossenen Aktionsparameter startet.
Multiprozessor-Cluster-System nach einem der Ansprüche 25 bis 32, bei dem das genannte Registrierungsund Start-Subsystem (56) eine Datenbank mit Wählfaktoren für den Client-Dienst aufweist und die genannten Wählfaktoren auf die gegenwärtig in dem Cluster befindlichen Knoten anwendet, um den Knoten zum Registrieren eines Client-Dienstes zu wählen, wobei die genannten Wählfaktoren Regeln festlegen, die Knoten mit dem Client-Dienst in Bezug setzen.
Multiprozessor-Cluster-System nach einem der Ansprüche 25 bis 33, bei dem das genannte Registrierungsund Start-Subsystem (56) ferner sich an das Cluster anschließende Knoten darüber benachrichtigt, dass der spezielle Client-Dienst bei dem speziellen Knoten registriert ist.
Multiprozessor-Cluster-System nach einem der Ansprüche 25 bis 34, das ein Ereignismanager-Subsystem (54) zum Feststellen von Clusterfehlern und zum Reagieren auf sie aufweist und bei dem das Registrierungs- und Start-Subsystem (56) auf das Ereignismanager-Subsystem. reagiert.
Multiprozessor-Cluster-System nach Anspruch 35, bei dem das genannte Ereignismanager-Subsystem (54) eine Ereignisüberwachung (60) zum Überwachen eines bei einem Knoten registrierten Client-Dienstes an diesem Knoten aufweist.
Computer-geeignetes Medium, in das Programmcode eingegliedert ist, wobei der genannte Programmcode ein Betriebssystem für ein Multiprozessor-Cluster-System definiert, das mehrere Knoten (26) hat, eine gemeinsame, für alle Prozessoren zugängliche Ressource (28) und mehrere interdependente Ebenen von Subsystemen (46–54) aufweist, wobei eines der genannten Subsysteme ein Cluster-Mitgliedschaftsmanager-Subsystem (46) zum Kombinieren spezieller der genannten Knoten in einem Cluster ist, das Benutzern des genannten Systems im Wesentlichen als ein vereintes System erscheint, wobei der genannte Cluster-Mitgliedschaftsmanager zum Benachrichtigen der Ebenen von Subsystemen, die auf gegenwärtig in einem Cluster befindlichen Knoten abgearbeitet werden, über Übergänge von sich dem Cluster anschließenden und es verlassenden Knoten ausgeführt ist, um eine konsistente Ansicht aktiver Mitgliedschaft in dem Cluster bereitzustellen.
Computer-geeignetes Medium nach Anspruch 37, wobei das Betriebssystem ferner einen Registrierungs- und Start-Dienst (56) hat zum Initiieren von Client-Diensten an speziellen von Knoten in einem Cluster auf eine Weise, die den Client-Diensten im Wesentlichen als ein vereintes System erscheint, wobei der genannte Registrierungs- und Start-Dienst einen Knoten für jeden Client-Dienst wählt, den Client-Dienst bei diesem Knoten registriert und gegenwärtig in dem Cluster befindliche Knoten darüber benachrichtigt, dass der spezielle Dienst bei dem speziellen Knoten registriert ist.