-
Die
vorliegende Erfindung bezieht sich allgemein auf die Simulation
von Systemen mit Parallelverarbeitung und insbesondere auf die Simulation von
Betriebssystemen mit mehreren Kernen in einer Cluster-Verarbeitungsumgebung.
-
HINTERGRUND
DER ERFINDUNG
-
Ein
aktueller Trend in der Computerindustrie ist die Verbindung eines
Clusters unabhängiger Rechnerknoten,
die durch eine Hochgeschwindigkeits-Kommunikationsverbindung verknüpft sind.
Jedem Knoten ist eine Anzahl von Domänen zugeordnet, wobei jede
Domäne
einen Prozeß repräsentiert, der
seinen eigenen Adreßraum
hat. Eine solche Domäne
ist das Betriebssystem oder der Kern, der ein einziges Systembild
bereitstellt, so daß der
Cluster für
den Benutzer, für
Anwendungen und für
das Netzwerk wie eine einzige Maschine aussieht. Das Bild des einzigen
Systems ermöglicht
es Benutzer- und Kernanwendungen, Prozeduren aufzurufen, ohne zu berücksichtigen,
wo die Prozeduren innerhalb des Clusters liegen. Eine Benutzeranwendung,
die auf einem Knoten läuft,
kann daher ein Objekt aufrufen, dessen Methode in einem anderen
Knoten des Clusters liegt, ohne daß es erforderlich ist, daß die Benutzeranwendung
den Ort der aufgerufenen Methode kennt.
-
Die
Fehlerüberprüfung (Debugging)
des Kerns in einer Clusterumgebung bietet eine Anzahl von Herausforderungen.
Traditionelle Fehlersuchwerkzeuge sind nicht geeignet, da sie erfordern,
daß der
Code, welcher auf Fehler überprüft wird,
gestoppt wird, um Daten zu untersuchen. Wenn der fehlerüberprüfte Code
der Kern ist, wird der Kern gestoppt, um die Daten des Kerns zu
untersuchen. Die gesamte Verarbeitung in dem Knoten wird aber beendet, wenn
der Kern gestoppt wird. Um diese Situation zu vermeiden, muß der Debugger
(das Fehlersuchprogramm) auf einem getrennten Knoten ausgeführt werden.
Oft ist jedoch diese zusätzliche
Ressource nicht verfügbar.
-
Außerdem können gewisse
Kernprozeduren nur auf einem Knoten ausgeführt werden. Um eine Clusterumgebung
mit n Knoten auf Fehler zu überprüfen, sind
n Knoten oder Computer erforderlich. Oft sind diese zusätzlichen
Ressourcen knapp und nicht einfach verfügbar.
-
Das
US-Patent 5,805,867 beschreibt eine Simulationsvorrichtung für einen
Mehrfachprozessor, die in der Lage ist, den Prozeß eines
einzelnen Prozessors und den Kommunikationsprozeß zwischen Prozessoren gleichzeitig
zu simulieren. Die Vorrichtung umfaßt einen Simulatorvorbereitungsbereich zum
Vorbereiten bzw. Herstellen einer Mehrzahl von Simulatoren, von
denen jeder unabhängig
von den anderen arbeitet, um den internen Prozeß zu simulieren, den jeder
der Prozessoren, die simuliert werden sollen, unabhängig von
den anderen durchführt,
und um auch den Kommunikationsprozeß zwischen den Prozessoren
gleichzeitig zu simulieren.
-
Ein
Artikel von Wayne A. Christopher et al. mit dem Titel "The Nachos instructional
operating system",
veröffentlicht
in den Proceedings of the Winter 1993 USENIX Conference, San Diego,
CA, USA, 25.-29. Januar 1993, Seiten 481-489 (XP002244519), siehe
Seite 1a, beschreibt ein aus Befehlen aufgebautes Betriebssystem.
-
"The Common Object
Request Broker: Architecture and Specification", Revision 2.0, Juli 1995 (XP002157374)
der Objekt Management Gruppe beschreibt einen Objektanforderungshändler (Object Request
Broker – ORB).
-
Dementsprechend
wird ein Mechanismus benötigt,
der eine effiziente Umgebung bereitstellt, in welcher die Clusterumgebung
für Zwecke
der Fehlersuche simuliert werden kann.
-
ZUSAMMENFASSUNG
DER ERFINDUNG
-
Bestimmte
und bevorzugte Ausführungsformen
der Erfindung sind in den anhängenden
unabhängigen
und abhängigen
Ansprüchen
dargelegt. Merkmale der abhängigen
Ansprüche
können
mit denen der unabhängigen
Ansprüche
nach Bedarf kombiniert werden und auch in Kombinationen, die andere
als die in den Ansprüchen
ausdrücklich
formulierten Kombinationen sind.
-
Eine
Ausführungsform
der Erfindung stellt eine Vorrichtung und ein Verfahren zum Simulieren von
Mehrfachkernvorgängen
eines einzelnen Computers bereit, wobei jeder Kernvorgang einen
Knoten repräsentiert.
Die Kernvorgänge
bzw. -prozeduren werden als Prozeduren auf Benutzerebene simuliert und
ermöglichen
es dadurch einem Benutzer, die Kernprozeduren auf Fehler zu prüfen.
-
Die
simulierte Architektur umfaßt
Cluster von Computerknoten, die durch eine Kommunikationsverbindung
miteinander verbunden sind. Jeder Cluster enthält einen oder mehrere unabhängige Computerknoten.
Jedem Knoten ist eine Anzahl von Domänen zugeordnet, wobei jede
Domäne
einen Prozeß repräsentiert,
der seinen eigenen Adreßraum
hat. Jede derartige Domäne
ist das Betriebssystem oder der Kern, der das Bild eines einzelnen
Systems bereitstellt, was den Cluster für den Benutzer, für Anwendungen
und für das
Netzwerk als eine einzige Maschine erscheinen läßt. Dieses Bild eines Einzelsystems
ermöglicht
es Benutzer- oder Kernanwendungen, Prozeduren aufzurufen, unabhängig davon, wo
die Prozeduren innerhalb des Clusters liegen.
-
Jeder
Kern verwendet eine Anzahl von Mechanismen, um das Bild eines einzelnen
Clustersystems zu erreichen: ein Türmechanismus wird für die Kommunikation
zwischen Domänen
verwendet, ein Objektanforderungshändler (ORB) wird verwendet, um
Objektaufrufe zu bearbeiten, ein Schnittstellenhändler wird verwendet, um eine
Schnittstelle zwischen den ORB und den Domänen auf Benutzerebene zu bilden.
Ein Transportmechanismus wird verwendet, um die Kommunikation zwischen
den verschiedenen Knoten zu erleichtern, eine Bibliothek des Kernmoduls
wird verwendet, um Kernanwendungen zu speichern, und eine Überwachungsprozedur der
Clustermitgliedschaft wird verwendet, um den Betriebszustand jedes
Knotens in einem Cluster zu überwachen.
-
Jeder
Kern eines Knotens wird als eine Prozedur auf Benutzerebene simuliert.
Es wird ein Mechanismus bereitgestellt, der es einem Benutzer ermöglicht,
eine Simulationsumgebung zu konfigurieren, die eine vom Benutzer
spezifizierte Anzahl simulierter Kerne hat, die einen Cluster bilden.
Falls erforderlich, können
mehrere Cluster auf derselben Maschine simuliert werden. Zusätzlich hat
ein Benutzer die Fähigkeit,
die Funktionen auszuwählen,
die simuliert werden, und zu wählen,
in welchem Knoten sie simuliert werden.
-
KURZE BESCHREIBUNG
DER FIGUREN
-
Beispielhafte
Ausführungsformen
der Erfindung werden nachstehend und lediglich beispielhaft beschrieben,
wobei auf die beigefügten
Zeichnungen bezug genommen wird, von denen:
-
1 ein
Blockdiagramm eines Computersystems ist, das die simulierte Clusterumgebung
repräsentiert,
-
2 ein
Blockdiagramm einer Simulationsumgebung für das in 1 dargestellte
Computersystem ist,
-
3 ein
Blockdiagramm des Computersystems ist, welches die Simulationsumgebung
der vorliegenden Erfindung verkörpert,
-
4 ein
Flußdiagramm
ist, welches die Schritte veranschaulicht, die verwendet werden,
um die simulierte Umgebung und die Verwendung der simulierten Umgebung
zu erzeugen.
-
BESCHREIBUNG
DER BEVORZUGTEN AUSFÜHRUNGSFORM
Simulierte Clusterarchitektur
-
Gemäß 1 ist
ein Computersystem 100 dargestellt, welches einen Cluster
von Rechnerknoten 102 repräsentiert. Ein Cluster ist ein
Satz von Computer- bzw. Rechnerknoten. Jeder Rechnerknoten 102 repräsentiert
einen unabhängigen
Computer, der über
eine Kommunikationsverbindung 104 angeschlossen ist. Es
versteht sich, daß die
vorliegende Erfindung die Fähigkeit
hat, einen oder mehrere Cluster zu simulieren. Nur zu Veranschaulichungszwecken
ist in 1 ein einzelner Cluster dargestellt.
-
Die
Kommunikationsverbindung 104 bezieht sich grundsätzlich allgemein
auf irgendeinen Typ einer Verkabelung oder einer drahtlosen Verbindung zwischen
Computern, wie z.B. auf ein lokales Netzwerk (Local Area Network),
ein Fernbereichsnetzwerk (Wide Area Network) oder Kombinationen
von Netzwerken, ohne jedoch hierauf beschränkt zu sein. Die Rechnerknoten 102 verwenden
die Kommunikationsverbindung 104, um miteinander zu kommunizieren.
In einer Ausführungsform
kann die Kommunikationsverbindung ein Systembereichsnetz (SAN) sein.
-
Jeder
Knoten 102 hat eine oder mehrere Domänen 126, 128.
Eine Domäne 126, 128 ist
als ein Prozeß mit
seinem eigenen Adreßraum
definiert. Eine Domäne 126, 128 kann
mehrere Ausführungsstränge (üblicherweise
als "Threads" bezeichnet) haben,
die Anwendungsvorgänge
des Benutzers oder des Kernes ausführen können. Eine Kerndomäne 128 bezieht
sich auf das Betriebssystem und eine Benutzerdomäne 126 bezieht sich
auf einen Prozeß anstatt
auf das Betriebssystem.
-
In
einer bevorzugten Ausführungsform
ist das Betriebssystem oder der Kern 128 das Betriebssystem
Solaris MC, welches ein Produkt von Sun Microsystems, Inc. ist.
Hintergrundinformation über
das Solaris MC-Betriebssystem kann man finden in "Solaris MC: A Multicomputer
OS", Technical Report SMLI
TR-95-48, November 1995, Sun Microsystems.
-
Eine
Benutzerdomäne 126 führt typischerweise
eine oder mehrere Benutzeranwendungsvorgänge 106 aus. Ein Benutzeranwendungsvorgang 106 kann
mit einem anderen Vorgang über
einen Türmechanismus 108 kommunizieren.
Typischerweise kann die Benutzeranwendungsprozedur 106 Objekte aufrufen,
ohne zu berücksichtigen,
wo die Methode des Objektes liegt. Eine Benutzeranwendungsprozedur 106 in
einer Domäne
kann ein Objekt aufrufen, wenn die Methode des Objektes in einer
anderen Domäne
entweder auf demselben Knoten oder auf einem anderen Knoten innerhalb
des Clusters liegt bzw. residiert.
-
Eine
Tür oder
ein Türmechanismus 108 ist ein
Mechanismus für
die Kommunikation zwischen Prozessen (EPC-Mechanismus), der es ermöglicht, daß Prozeduren
in verschiedenen Domänen
miteinander kommunizieren. Der Türmechanismus
befindet sich in der Benutzerdomäne 126 und
in der Kerndomäne 128.
Ein Benutzeranwendungsvorgang bzw. -prozedur 106 in einer
Domäne
kann einen Aufruf durch eine Tür 108 aussenden,
welche Code in einer anderen Domäne
ausführt.
In einer bevorzugten Ausführungsform
wird der Solaris-Türmechanismus
verwendet, der im einzelnen in dem Solaris 2.6 Reference Manual
beschrieben ist, welches von Sun Microsystems, Inc., seit 1997 vertrieben
wird. Die vorliegende Erfindung ist jedoch nicht auf den Türmechanismus
beschränkt.
Andere IPC-Mechanismen
können
verwendet werden, wie z.B. Steckanschlüsse, entfernte Prozeduraufrufe
von Sun (RPCs) und System V IPC, ohne jedoch hierauf beschränkt zu sein.
-
Kurz
gesagt beschreibt eine Tür 108 eine Prozedur
in einer Domäne 126, 128 und
kann irgendwelche zugehörige
Zustandsinformation enthalten. Eine Domäne, die eine Tür 108 erhält, ist
frei, diese zusammen mit ihren Fähigkeiten
an eine andere Domäne
in dem Cluster zu übergeben.
Ein Server erzeugt eine Tür
für irgendeinen
Dienst, den er bereitstellt, und exportiert die Tür 108 an
Clients. Clients, welche die Tür
erhalten, können
dann den zu der Tür 108 gehörigen Dienst
aufrufen unter Verwendung der synchronen RPC-Semantik eines Prozeduraufrufs über eine
Tür.
-
Während eines
Türaufrufs
wandert die Clientprozedur, welche die Aufrufprozedur der Tür ausgibt,
hinüber
in die Serverdomäne,
die zu der Tür
gehört,
und führt
die angeforderte Prozedur aus, während
sie sich im Adreßraum
des Servers befindet. Wenn die angeforderte Prozedur beendet ist,
wird eine Türrückgabeoperation
durchgeführt
und die Steuerung wandert zurück
an die Clientdomäne
mit den Ergebnissen, soweit vorhanden, aus dem Prozeduraufruf.
-
Eine
Aufgabe der Kerndomäne 128 besteht darin,
eine Kommunikation zwischen Domänen
in verschiedenen Knoten zu ermöglichen.
Eine Anforderung, eine Prozedur in einem anderen Knoten auszuführen, kann
durch den Kern 128 von einer Benutzer- oder Kernprozedur empfangen
werden. Die Anforderung wird in ein Format umgewandelt, das an den
Serverknoten gesendet werden kann, welcher die Information enthält, die
von dem Serverknoten benötigt
wird, um die aufgerufene Prozedur auszuführen. Verschiedene Prozeduren
in dem Kern werden verwendet, um dieses Kommunikationsprotokoll bereitzustellen,
ohne durch die Anwendungsprozedur des anfordernden Benutzers oder
Kernes einbezogen zu werden. Die verschiedenen Prozeduren, die von
dem Kern verwendet werden, um diese Kommunikation bereitzustellen,
werden nachstehend beschrieben. Eine genauere Beschreibung dieser
Prozeduren findet man in der anhängigen
Patentanmeldung mit dem Titel "Ein
System und Verfahren für entfernten
Objektaufruf" mit
der Seriennummer 08/879, 150, die am 19. Juni 1997 eingereicht wurde und
auf Sun Microsystems, Inc., überschrieben
wurde.
-
Der
Kern 128 enthält
einen ORB 114, der verwendet wird, um Objektaufrufe zu
verarbeiten. In einer bevorzugten Ausführungsform nutzt der ORB 114 die
Architektur und die Beschreibung der allgemeinen Objektanforderungshändlerarchitektur (Common
Object Request Broker Architecture – CORBRA). Eine genauere Beschreibung
von CORBRA kann man finden in The Common Obiect Request Broker:
Architecture and Specification, Objekt Management Gruppe, Inc.,
Framingham, MA, Revision 2.0, Juli 1995.
-
Anforderungen
an den ORB 114 können
von den Anwendungsprozeduren auf Benutzerniveau oder Kernniveau
erfolgen. Die Anforderungen von Anwendungsprozeduren 106 auf
Benutzerebene werden an den ORB 114 durch den Türmechanismus 108 an
eine Schnittstelle 112 gesendet. Eine Schnittstelle oder
ein Schnittstellenhandhaber 112 ist eine Erweiterung des
Türmechanismus 108,
welche verschiedene Aufgaben ausführt, um Objektaufrufe zu verarbeiten.
-
In
einigen Fällen
erfolgt der Objektaufruf für die
Methode eines Objektes, welches in einem anderen Knoten liegt bzw.
residiert. In diesem Fall wandelt der ORB 114 eine Objektaufrufsanforderung
in eine logische Nachricht um, die durch eine Transportprozedur 116 an
einen geeigneten Knoten 102 gesendet wird. Die Transportprozedur 116 verarbeitet
Nachrichten an einen Knoten, die durch eine Knotenkennung identifizierbar
sind, bestimmt eine Netzwerkadresse, die zu der Knotenkennung gehört und ruft
die Netzwerkschnittstelle 118 auf, die Nachricht zu überbringen.
Die Transportprozedur 116 kann irgendeine der wohlbekannten
Kommunikationsprotokolle der "Transportschicht" verwenden, wie z.B.
das Übertragungssteuerungsprotokoll
(Transmission Control Protocol – TCP),
das Benutzerdatagramm-Protokoll (UPD) oder dergleichen, ohne jedoch
hierauf beschränkt
zu sein. Weiterhin kann der ORB 114 durch die Transportprozedur 116 Nachrichten
von einem anderen Knoten empfangen.
-
Eine
Modulbibliothek 110 des Kernes enthält eine Anzahl ausführbarer
Module, die auf Anforderung dynamisch geladen werden können. Die
Module 110 führen
Aufgaben auf Kernniveau aus. Die Module 110 enthalten Anwendungen
auf Kernniveau bzw. Kernebene, ebenso wie auch andere Prozeduren. Die
Kernanwendungsprozeduren verwenden den ORB 114, um Objektaufrufe
durchzuführen.
-
Eine
Prozedur 120 der Clustermitgliedschaftsüberwachung (Cluster Membership
Monitor – CMM)
wird bereitgestellt, um den Ausfall eines Knotens zu erfassen. Die
CMM-Prozeduren 120 in jedem Knoten kommunizieren in regelmäßigen Intervallen miteinander,
um den Betriebszustand der Knoten in dem Cluster zu bestimmen. Die
Kommunikation wird zu einem genauen Zeitintervall durchgeführt, welches
durch einen Interrupt von einer Softwaretaktprozedur 122 ausgelöst wird.
Die CMM-Prozedur 120 informiert den ORB 114, wenn
ein Knotenausfall bzw. -fehler auftritt, und wenn ein fehlerhafter
Knoten in Betrieb genommen wird.
-
Einer
der Knoten 102a in jedem Cluster wird als Wurzelknoten
bezeichnet, da er eine Namensserverprozedur 124 enthält. Der
Namensserver (Name Server) 124 wird verwendet, um die verschiedenen Objekte,
die in dem Cluster vorhanden sind, zu identifizieren. Der ORB 114 verwendet
den Name Server 124, um die Position der Methoden des Objektes
zu bestimmen.
-
Im
Vorstehenden wurde die Clusterumgebung und die Infrastruktur beschrieben,
die simuliert werden. Wir wenden uns nun der Art und Weise zu, in
welcher die Clusterumgebung simuliert wird.
-
Simulationsumgebung
-
Die 2 und 3 veranschaulichen
die simulierten Cluster. Ein einzelnder Computer 200 kann
verwendet werden, um einen oder mehrere Cluster von Rechnerknoten
zu simulieren. Der Kern jedes Knotens repräsentiert im Ergebnis das Herz
jedes Knotens. Jeder Kern ist wiedergegeben als eine Domäne auf Benutzerebene
und wird hier als eine simulierte Kerndomäne 216 bezeichnet.
Zusätzlich
hat der Computer 200 einen Kern 208, eine oder
mehrere Benutzerdomänen 210 und
einen Fehlersuchmechanismus 230. Indem ein Knoten als eine
Domäne auf
Benutzerebene wiedergegeben wird, kann der Fehlersuchmechanismus
(Debugger) 230 verwendet werden, ein Debugging der simulierten
Kerndomäne 216 durchzuführen, ohne
den Betrieb des Kernes 208 zu unterbrechen. Zusätzlich kann
man die simulierten Cluster unter Verwendung eines einzelnen Computers
anstatt einer Mehrzahl von Computern erhalten.
-
Der
Computer 200 kann eine Workstation, ein Personal Computer,
ein Mainframe oder irgendeine andere Art von Verarbeitungseinrichtung
sein. Der Computer 200 enthält eine CPU 202, eine
Benutzerschnittstelle 204 und einen Speicher 206.
Der Computer 200 hat weitere Systemressourcen, die nicht dargestellt
sind. Der Speicher 206 des Computers kann als ein RAM (Speicher
mit wahlfreiem Zugriff) oder eine Kombination aus einem RAM und
einem nicht flüchtigen
Speicher, wie z.B. einer magnetischen Festspeicherplatte implementiert
sein. Der Speicher 206 kann die Kerndomäne 208, eine oder mehrere
Benutzerdomänen 210,
eine oder mehrere simulierte Kerndomänen 216, eine Debuggerprozedur 230 und
auch andere Daten und Prozeduren umfassen.
-
Eine
Benutzerdomäne 210 kann
eine unode_load-Prozedur 212 und eine unode_create-Prozedur 214 enthalten.
Die unode_load-Prozedur 212 wird verwendet, um Prozeduren
in einer simulierten Kerndomäne 216 durchzuführen. Die
unode_create-Prozedur 214 wird verwendet, um eine oder
mehrere simulierte Kerndomänen 216 zu
erzeugen. Die Betriebsweise beider Prozeduren wird nachstehend noch
erläutert.
-
Eine
simulierte Kerndomäne 216 enthält die folgenden
Prozeduren: eine Steuertür
oder Steuertürprozedur 218,
eine Transporttür-
oder Transporttürprozedur 220,
eine simulierte Schnittstelle oder simulierte Schnittstellenprozedur 222,
eine oder mehrere gemeinsam verwendete Objektbibliotheken 224, eine
ORB-Prozedur 114, eine CMM-Prozedur 120, einen
simulierten Takt oder eine simulierte Taktprozedur 226 und
einen simulierten Transport oder eine simulierte Transportprozedur 228.
In einer bestimmten simulierten Kerndomäne 216 gibt es einen
Name Server oder eine Name Server-Prozedur 124.
-
Ein
Kern ist von den Eingaben der zugrundeliegenden Hardware abhängig. Insofern
kann man nicht alle Kernprozeduren als Prozeduren auf Benutzerebene
ablaufen lassen. Einige Kernprozeduren wurden also durch simulierte
Prozeduren ersetzt und andere erforderten, kleine Modifikationen,
um sie als eine Prozedur auf Benutzerebene ausführbar zu machen.
-
Die
ORB-Prozedur 114, die Namensserver-Prozedur 124 und
die CMM-Prozedur 120 sind grundsätzlich dieselben Prozeduren,
die auch in der Kerndomäne
vorhanden sind. Sie sind nur geringfügig modifiziert worden, damit
sie zu einer Domäne auf
Benutzerebene wurden, indem Syntaxänderungen und dergleichen an
gewissen Funktionen innerhalb dieser Prozeduren vorgenommen wurden.
Beispielsweise verwendet der Kern die Prozedur thread_create() mit
einer gewissen Anzahl von Argumenten, um neue Threads zu erzeugen.
In dem simulierten Kern wird dieselbe Funktion thr_create() genannt
und weist eine andere Anzahl von Argumenten auf.
-
Eine
Steuertür 218 gehört zu jeder
simulierten Kerndomäne 216 und
wird verwendet, um eine Kommunikation mit den Benutzerdomänen 210 zu erleichtern
bzw. zu ermöglichen.
Die Steuertür 218 ist mit
einer simulierten Schnittstelle 222 verbunden, die einen
Befehlsstrang akzeptiert, welcher angibt, daß eine bestimmte Funktion an
der simulierten Kerndomäne 216 und
mit ihren Argumenten ausgeführt
werden soll. Die simulierte Schnittstelle 222 nimmt diesen
Befehlsstrang an und lädt
die angeforderte Funktion aus der gemeinsam verwendeten Objektbibliothek 224.
Sie wandelt dann die Befehle in Argumente um, die von der Funktion
erkannt werden können, und
führt die
Funktion mit den Argumenten aus. Die Funktion kann ihrerseits die
Methoden eines oder mehrerer Objekte aufrufen, die durch den ORB 114 verarbeitet
werden.
-
Ausführbare Module
in den simulierten Kerndomänen 216 sind
als gemeinsam verwendete Objekte wiedergegeben, die in einer gemeinsam
verwendeten Objektbibliothek 224 gespeichert sind. Die gemeinsam
verwendeten Objekte repräsentieren
Anwendungen auf Benutzerniveau und auf Kernniveau und Dienste, die
verwendet werden, um die Funktion des Kernes für Fehlersuchzwecke zu simulieren.
Ein gemeinsam verwendetes Objekt ist gekennzeichnet durch einen
Modulnamen und einen Funktionsnamen.
-
Kommunikation
zwischen den simulierten Kerndomänen 216 wird
erreicht durch die Verwendung einer simulierten Transportprozedur 228 und
einer Transporttür 220.
Die simulierte Transportprozedur 228 kann einen Befehl
von dem ORB 114 empfangen, um eine Nachricht an eine andere
simulierte Kerndomäne 216 zu
senden. Diese Anforderung kann darin bestehen, eine Methode eines
Objektes auszuführen,
welches in einer anderen simulierten Kerndomäne 216 residiert,
oder eine andere Aufgabe auszuführen.
Die simulierte Transportprozedur 228 legt die Transporttür 220 fest,
die zu der empfangenden, simulierten Kerndomäne 216 gehört. Die
simulierte Transportprozedur 228 führt dann einen Toraufruf an
die empfangene simulierte Kerndomäne 216 durch. Diese überträgt die Steuerung
auf die beabsichtigte simulierte Kerndomäne 216, welche die
angeforderte Verarbeitung durchführt.
Wenn die Verarbeitung abgeschlossen ist, wird an die anfordernde, simulierte
Kerndomäne 216 eine
Antwort zurückgegeben,
indem ein Türrückgabevorgang
durchgeführt wird.
Die Steuerung wird dann von dem anfordernden Knoten, welcher die
Antwort verarbeitet, auf die simulierte Kerndomäne 216 übertragen.
-
Zusätzlich können die
simulierte Transportprozedur 228 und die Transporttür 220 verwendet werden,
um auf den Cluster bezogene Nachrichten zwischen den simulierten
Kerndomänen 216 eines Clusters
für andere
Zwecke zu senden. Beispielsweise nutzt die Kommunikation zwischen
den CMMs jeder simulierten Kerndomäne 216 innerhalb eines Clusters
die simulierte Transportprozedur 228 und die Transporttür 220.
Diese Kommunikation wird erreicht durch Nachrichten, die über die
Transporttür 220 geleitet
werden. Die simulierte Transportprozedur 228 wird verwendet,
um die Nachricht von einem Format in ein anderes Format umzuwandeln,
welches für
einen beabsichtigten Empfänger
erkennbar ist, und um die Nachricht an einen beabsichtigten Empfänger zu
leiten.
-
Eine
simulierte Taktprozedur 226 wird bereitgestellt, um den
Kerntakt 122 zu ersetzen. Die simulierte Taktprozedur 226 wird
verwendet, um zeitgerechte Taktunterbrechungen für die CMM-Prozedur 120 zu
erzeugen, was es dieser ermöglicht,
den Zustand der simulierten Kerndomäne 216 in einem Cluster
zu überwachen.
In einer Ausführungsform läuft die
simulierte Taktprozedur 226 als ein Strang (Thread) in
Realzeit in dem Sun Solaris Betriebssystem.
-
Es
wird eine Fehlersuchprozedur 230 (Debuggerprozedur) bereitgestellt,
die verwendet werden kann, um die Ausführung der simulierten Kerndomäne 216 auf
Fehler zu untersuchen.
-
Im
Vorstehenden sind die Mechanismen beschrieben worden, um die Clusterumgebung
zu simulieren. Wir wenden uns nun den Schritten zu, die verwendet
werden, um den Betrieb der Kerne in jedem Knoten der Cluster zu
simulieren.
-
Gemäß 4 erzeugt
ein Benutzer zu Beginn einen oder mehrere Knoten, die zu einem oder mehreren
Clustern gehören
(Schritt 300). Dies wird bewerkstelligt durch Aufrufen
einer Prozedur 214 unode_create, welche eine simulierte
Kerndomäne 216 erzeugt,
die einen bestimmten Knoten in einem bestimmten Cluster repräsentiert.
Die Prozedur 214 unode_create nimmt eine Anzahl von Argumenten, wie
z.B. den Namen des Clusters, eine Kennung des Knotens und die Anzahl
von Knoten in dem Cluster. Die Prozedur 214 unode_create
stellt eine Steuertür 218 und
eine Transporttür 220 für die simulierte
Kerndomäne
bereit und führt
auch andere Initialisierungsaufgaben aus. Wenn die simulierten Kerndomänen erzeugt
sind, arbeiten sie in ähnlicher
Weise wie Kerne in realen System und kommunizieren miteinander.
-
Als
nächstes
kann eine Benutzerdomäne eine
bestimmte Funktion in einer simulierten Kerndomäne ausführen (Schritt 302).
Dies wird erreicht durch Ausführen
einer Prozedur 212 unode_load, die eine Funktion in einer
bestimmten simulierten Kerndomäne 216 ausübt. Diese
Prozedur 212 unode_load kann in eine Benutzeranwendungsprozedur
eingebettet sein. Die unode_load-Prozedur 212 gibt an,
daß eine
bestimmte simulierte Kerndomäne 216 eine
bestimmte Funktion ausführt,
die in einer gemeinsam verwendeten Objektbibliothek 224 gespeichert
ist. Die unode_load-Prozedur 212 wird von einer Benutzerdomäne 210 mit
den folgenden Argumenten aufgerufen: Name des Clusters, Knotenkennung
(bzw. -identifizierer), Name eines Moduls in der gemeinsam verwendeten
Objektbibliothek 224, ein Name einer Funktion in dem Modul,
welche ausgeführt
wird, und die Argumente der Funktion.
-
Die
unode_load-Prozedor 212 verwendet den Clusternamen und
die Knotenkennung, um die entsprechende Steuerungstürprozedur 218 zu
bestimmen. Die unode_load-Prozedur 212 ruft dann einen
Türruf
auf unter Verwendung der Steuertürprozedur 218,
welche die Steuerung zusammen mit den Argumenten in die simulierte
Schnittstelle 222 überträgt, die
zu der beabsichtigten, simulierten Kerndomäne 216 gehört. Die
unode_load-Prozedur 212 leitet an die simulierte Schnittstelle 222 den
Namen des Moduls, den Namen der Funktion in dem Modul und die Argumente
der Funktion desselben weiter. Die simulierte Schnittstelle 222 legt
den Namen des gemeinsam verwendeten Objektes fest, welches das Modul
repräsentiert,
und lädt
das entsprechende, gemeinsam verwendete Objekt dynamisch herunter, wenn
es nicht schon in den Speicher 206 geladen ist. Die simulierte
Schnittstelle 222 entpackt die Argumente und wandelt sie
in ein Format um, welches für die
Funktion, welche dann ausgeführt
wird, erkennbar ist.
-
Die
Funktion kann dann eine Anzahl von Aufgaben ausführen, die die Kommunikation
mit anderen simulierten Kerndomänen 216 umfassen
kann. In diesem Fall wird der ORB 114 verwendet, welcher
mit den anderen simulierten Kerndomänen 216 durch die simulierte
Transportprozedur 228 und die Transporttür 220 kommuniziert.
-
Wenn
die Funktion ihre Ausführung
abschließt,
wird an die unode_load-Prozedur 212 eine Antwort zurückgegeben,
welche die Ausführung
der Funktion angefordert hatte. Die Antwort wird in einem Format
von der Funktion der simulierten Schnittstelle 222 gesendet.
Die simulierte Schnittstelle 222 wandelt dann die Antwort
in ein Format um, welches von der unode_load-Prozedur 212 erkennbar
ist und führt eine
Türrückgabeoperation
durch, um die Antwort an die unode_load-Prozedur 212 zu
senden.
-
Während die
simulierte Kerndomäne 216 ausgeführt wird,
kann ein Debugger (Fehlersuchprogramm) 230 verwendet werden,
um die Ausführung des
Codes zu analysieren, welcher in der simulierten Kerndomäne 216 läuft (Schritt 304).
Das Debugging ist im Stand der Technik wohl bekannt und die vorliegende
Erfindung ist nicht auf irgendeine bestimmte Art einer Debuggingtechnik
beschränkt.
In einer Ausführungsform
kann der Debugger eine oder mehrere simulierte Kerndomänen ausführen. Der
Debugger kann die Ausführung
einer simulierten Kerndomäne anhalten,
um Speicherorte und Datenwerte zu analysieren.
-
Alternative
Ausführungsformen
-
Während die
vorliegende Erfindung unter Bezug auf wenige spezielle Ausführungsformen
beschrieben worden ist, ist diese Beschreibung nur veranschaulichend
und nicht als die Erfindung begrenzend auszulegen. Für Fachleute
liegen verschiedene Modifikationen auf der Hand, ohne daß sie vom Schutzumfang
der Erfindung abweichen.
-
Die
vorliegende Erfindung ist nicht auf das in Bezug auf die 1 bis 3 beschriebene
Computersystem beschränkt.
Sie kann ohne die speziellen Einzelheiten ausgeführt werden und kann in verschiedenen
Konfigurationen oder Herstellungsformen oder Modellen von verteilten
Rechnersystemen, eng gekoppelten Prozessoren oder verschiedenen Konfigurationen
von lose gekoppelten Mikroprozessorsystemen implementiert sein.
-
Weiterhin
sind das Verfahren und das System, welches vorstehend beschrieben
wurde, für
die Ausführung
auf verschiedenen Typen ausführbarer Medien
geeignet bzw. anpaßbar,
die nicht eine Speichereinrichtung wie z.B. ein Speicher mit wahlfreiem Zugriff
sind. Andere Typen ausführbarer
Medien können
verwendet werden, wie z.B. ein computerlesbares Speichermedium,
das irgendeine Speichereinrichtung, eine Festplatte oder eine Diskette
sein kann, ohne hierauf beschränkt
zu sein.