DE69833914T2

DE69833914T2 - Architektur eines Multiprozessorrechners mit mehreren Betriebssysteminstanzen und softwaregesteuerter Betriebsmittelzuteilung

Info

Publication number: DE69833914T2
Application number: DE69833914T
Authority: DE
Inventors: Stephen H. Nashua Zalewski; Andrew H. Hollis Mason; Gregory H. Hollis Jordan; Karen L. Pembroke Noel; James R. Nashua Kaufman; Paul K. Groton Harter; Frederick G. Amherst Kleinsorge; Stephen F. Acton Shirron
Original assignee: Compaq Computer Corp
Current assignee: Compaq Computer Corp
Priority date: 1997-11-04
Filing date: 1998-11-04
Publication date: 2006-08-24
Anticipated expiration: 2018-11-05
Also published as: EP0917057A2; US20020016892A1; DE69833914D1; EP0917057B1; US6647508B2; EP0917057A3; JPH11316747A

Description

GEBIET DER ERFINDUNG
Diese Erfindung betrifft Mehrprozessor-Computer-Architekturen, in denen Prozessoren und andere Computer-Hardware-Ressourcen in Partitionen gruppiert sind, von denen jede eine Betriebssystem-Instanz aufweist, und insbesondere Verfahren und Einrichtungen zum Reservieren von Computer-Hardware-Ressourcen für Partitionen.
Der effiziente Betrieb vieler Anwendungen in gegenwärtigen Rechnerumgebungen hängt von schnellen, leistungsstarken und flexiblen Rechnersystemen ab. Die Konfiguration und Auslegung solcher Systeme ist sehr kompliziert geworden, wenn solche Systeme in einer gewerblichen "Unternehmens"-Umgebung eingesetzt werden sollen, in der es viele getrennte Abteilungen, viele verschiedene Problemtypen und ständig wechselnde EDV-Bedürfnisse geben kann. Benutzer in solchen Umgebungen möchten im Allgemeinen in der Lage sein, die Kapazität des Systems, seine Geschwindigkeit und seine Konfiguration rasch und leicht zu ändern. Sie möchten auch die System-Arbeitskapazität erhöhen und Konfigurationen ändern können, um eine bessere Nutzung der Ressourcen zu erzielen, ohne die Ausführung von Anwendungsprogrammen auf dem System zu stoppen. Außerdem möchten sie vielleicht in der Lage sein, das System zu konfigurieren, um die Ressourcenverfügbarkeit so zu maximieren, dass jede Anwendung eine optimale Rechenkonfiguration aufweist.
Herkömmlicherweise wurde die Rechengeschwindigkeit unter Verwendung einer "Shared-Nothing"-Rechenarchitektur angesteuert, in der Daten, Geschäftslogik und grafische Benutzerschnittstellen unterschiedliche Tiers sind und spezifische Rechenressourcen, die jedem Tier zugeordnet sind, aufweisen. Anfänglich wurde ein einzelner Zentralprozessor verwendet, und die Leistungsstärke und Geschwindigkeit eines solchen Rechensystems wurde erhöht, indem die Taktfrequenz des einzelnen Zentralprozessors erhöht wurde. In letzter Zeit wurden Rechensysteme entwickelt, die mehrere Prozessoren verwenden, die als ein Team arbeiten, statt eines massiven Prozessors, der alleine arbeitet. Auf diese Weise kann eine komplexe Anwendung auf viele Prozessoren aufgeteilt werden, statt darauf zu warten, dass sie von einem einzelnen Prozessor ausgeführt wird. Solche Systeme bestehen typischerweise aus mehreren Zentralprozessoren (CPUs), die durch ein einzelnes Betriebssystem gesteuert werden. In einer Variante eines Mehrprozessor-Systems, das als "symmetrischer Mehrprozessorbetrieb" oder SMP bezeichnet wird, werden die Anwendungen gleichmäßig auf alle Prozessoren verteilt. Die Prozessoren verwenden auch gemeinsam einen Speicher. In einer anderen Variante, die als "asymmetrischer Mehrprozessorbetrieb" oder AMP bezeichnet wird, arbeitet ein Prozessor als ein "Master", und alle anderen Prozessoren arbeiten als "Slaves". Daher müssen alle Operationen, einschließlich des Betriebssystems, über den Master laufen, bevor sie an die Slave-Prozessoren weitergegeben werden. Die Mehrprozessorbetriebs-Architekturen weisen den Vorteil auf, dass die Leistung durch Hinzufügen weiterer Prozessoren gesteigert werden kann, leiden jedoch unter dem Nachteil, dass die auf solchen Systemen laufende Software sorgfältig geschrieben werden muss, um die mehreren Prozessoren nutzen zu können, und es schwierig ist, die Software zu skalieren, wenn sich die Anzahl der Prozessoren erhöht. Gegenwärtige gewerbliche Auslastungen lassen sich über 8–24 CPUs hinaus nicht gut als einzelnes SMP-System skalieren, wobei die genaue Anzahl von Plattform, Betriebssystem und Anwendungs-Mix abhängt.
Zur Steigerung der Leistung bestand eine andere typische Lösungsmöglichkeit darin, die Computerressourcen (Maschinen) einer Anwendung zuzuordnen, um die Maschinenressourcen optimal auf die Anwendung abzustimmen. Dieser Ansatz wurde jedoch von der Mehrhit der Benutzer nicht übernommen, da die meisten Einsatzorte viele Anwendungen und getrennte Datenbanken aufweisen, die von unterschiedlichen Anbietern entwickelt wurden. Es ist daher schwierig und kostspielig, Ressourcen zu allen der Anwendungen zuzuordnen, insbesondere in Umgebungen, in denen sich der Anwendungs-Mix ständig verändert.
Alternativ kann ein Rechensystem mit Hardware partitioniert werden, um eine Untergruppe der Ressourcen auf einem Computer zu bilden, die für eine spezifische Anwendung verfügbar sind. Dieser Ansatz vermeidet die permanente Zuordnung der Ressourcen, da die Partitionen geändert werden können, weist aber immer noch Probleme hinsichtlich der Leistungsverbesserung mittels eines Lastausgleichs zwischen den Partitionen und der Ressourcenverfügbarkeit auf.
Die Probleme der Verfügbarkeit und Verwaltbarkeit wurden durch ein "Shared-Everything"-Modell angegangen, in dem ein großer zentralisierter robuster Server, der den größten Teil der Ressourcen enthält, im Netzwerk mit vielen kleinen, unkomplizierten Client-Netzwerk-Computern verbunden ist und sie bedient. Alternativ werden "Cluster" verwendet, in denen jedes System bzw. jeder "Knoten" seinen eigenen Speicher hat und von seinem eigenen Betriebssystem gesteuert wird. Die Systeme wirken durch die gemeinsame Benutzung von Disketten und die Übergabe von Nachrichten untereinander über eine Art Kommunikationsnetzwerk zusammen. Ein Cluster-System weist den Vorteil auf, dass zusätzliche Systeme leicht zu einem Cluster hinzugefügt werden können. Allerdings leiden Netzwerke und Cluster unter einem Mangel an gemeinsamem Speicher und einer begrenzten Verbindungsbandbreite, die der Leistung Einschränkungen auferlegen.
In vielen Unternehmens-Rechenumgebungen ist klar, dass die zwei getrennten Rechenmodelle gleichzeitig integriert werden müssen und jedes Modell optimiert werden muss. Mehrere Ansätze des Stands der Technik sind verwendet wurden, um diese Integrierung zu versuchen. Zum Beispiel verwendet eine Auslegung, die als eine "virtuelle Maschine" oder VM bezeichnet und von International Business Machines Corporation, Armonk, New York, entwickelt und vermarktet wird, eine einzelne physikalische Maschine mit einem oder mehreren physikalischen Prozessoren in Kombination mit Software, die mehrere virtuelle Maschinen simuliert. Jede dieser virtuellen Maschinen besitzt im Prinzip Zugriff auf alle physikalischen Ressourcen des zugrundeliegenden echten Computers. Die Zuweisung von Ressourcen zu jeder virtuellen Maschine wird durch ein Programm gesteuert, das als ein "Hypervisor" bezeichnet wird. Es gibt nur einen Hypervisor in dem System, und er ist für alle physikalischen Ressourcen zuständig. Demzufolge nimmt der Hypervisor, nicht die anderen Betriebssysteme, die Reservierung von physikalischer Hardware vor. Der Hypervisor fängt Ressourcen-Anforderungen von den anderen Betriebssystemen ab und bearbeitet die Anforderungen in einer im Allgemeinen korrekten Art.
Die VM-Architektur unterstützt das Konzept einer "logischen Partition" bzw. LPAR. Jede LPAR enthält einige der verfügbaren physikalischen CPUs und Ressourcen, die der Partition logisch zugewiesen sind. Die gleichen Ressourcen können zu mehr als einer Partition zugewiesen werden. LPARs werden von einem Administrator statisch eingerichtet, können aber auf Lastenänderungen dynamisch und ohne Neustart auf mehrere Arten reagieren.
Wenn zum Beispiel zwei logische Partitionen, von denen jede zehn CPUs enthält, auf einem physikalischen System gemeinsam genutzt werden, das zehn physikalische CPUs enthält, und wenn die logischen zehn CPU-Partitionen komplementäre Spitzenlasten aufweisen, kann jede Partition das gesamte physikalische Zehn-CPU-System ohne einen Neustart oder einen Eingriff der Bedienperson übernehmen, wenn sich die Arbeitslast ändert.
Des Weiteren können die CPUs, die jeder Partition logisch zugewiesen sind, über normale Betriebssystem-Operatorbefehle ohne Neustart dynamisch "Ein"- und "Aus"-geschaltet werden. Die einzige Einschränkung ist, dass die Anzahl der CPUs, die bei Systeminitialisierung aktiv sind, die maximale Anzahl von CPUs ist, die in jeder Partition "Ein"-geschaltet werden können.
Schließlich können in Fällen, in den der gesamte Arbeitslastbedarf aller Partitionen höher ist als von dem physikalischen System bereitgestellt werden kann, LPAR-Wichtungen verwendet werden, um zu definieren, wie viel von den gesamten CPU-Ressourcen an jede Partition vergeben wird. Diese Wichtungen können von den Bedienpersonen fliegend, ohne Unterbrechung, geändert werden.
Ein weiteres System des bisherigen Stands der Technik wird als "Paralleles Sysplex" bezeichnet und wird ebenfalls von der International Business Machines Corporation vermarktet und entwickelt. Diese Architektur besteht aus einer Gruppe von Computern, die über eine als "Kopplungseinrichtung" bezeichnete Hardware-Einheit, die an jeder CPU angebracht ist, zu Clustern zusammengefasst werden. Die Kopplungseinrichtungen an jedem Knoten sind über eine faseroptische Verbindung angeschlossen, und jeder Knoten arbeitet wie eine herkömmliche SMP-Maschine mit einer Höchstanzahl von 10 CPUs. Gewisse CPU-Befehle rufen die Kopplungseinrichtung direkt auf. Zum Beispiel registriert ein Knoten eine Datenstruktur in der Kopplungseinrichtung, anschließend sorgt die Kopplungseinrichtung dafür, dass die Datenstrukturen in dem lokalen Speicher jedes Knotens kohärent gehalten werden.
Der Enterprise 10000 Unix-Server, der von Sun Microsystems, Mountain View, Kalifornien, entwickelt und vermarktet wird, verwendet eine Partitionierung, die als "Dynamische Systemdomänen" bezeichnet wird, um die Ressourcen eines einzelnen physikalischen Servers in mehrfache Partitionen, oder Domänen, von denen jede als ein Stand-Alone-Server arbei tet, logisch zu unterteilen. Jede der Partitionen besitzt CPUs, Speicher und I/O-Hardware. Die dynamische Neukonfiguration gestattet es einem Systemadministrator, Domänen fliegend und ohne Neustart zu erstellen, ihre Größe anzupassen oder zu löschen. Jede Domäne bleibt von jeder anderen Domäne in dem System logisch isoliert, wodurch sie vollständig von jedem Software-Fehler oder CPU-, Speicher- oder I/O-Fehler isoliert wird, der von einer anderen Domäne generiert wird. Unter den Domänen werden keine Ressourcen gemeinsam genutzt.
Das an der Stanford University durchgeführte Hive-Projekt verwendet eine Architektur, die als eine Gruppe von Zellen strukturiert ist. Wenn das System gestartet wird, wird jeder Zelle ein Bereich von Knoten zugewiesen, zu dem sie durchgehend während der Ausführung zugehörig ist. Jede Zelle verwaltet die Prozessoren, Speicher- und I/O-Einrichtungen auf diesen Knoten so, als ob es sich um ein unabhängiges Betriebssystem handeln würde. Die Zellen arbeiten zusammen, um für Prozesse auf Benutzerebene die Illusion eines einzelnen Systems zu bieten.
Hive-Zellen sind nicht dafür zuständig, zu entscheiden, wie ihre Ressourcen zwischen lokalen und dezentralen Anforderungen aufgeteilt werden. Jede Zelle ist nur dafür zuständig, ihre internen Ressourcen zu verwalten und die Leistung innerhalb der Ressourcen zu optimieren, die für sie reserviert worden sind. Die globale Ressourcen-Reservierung wird durch einen Benutzerebenen-Prozess mit der Bezeichnung "Wax" ausgeführt. Das Hive-System versucht, eine Datenfälschung zu verhindern, indem gewisse Fehlereindämmungsgrenzen zwischen den Zellen verwendet werden. Um die enge gemeinsame Benutzung zu implementieren, die von einem Mehrprozessorsystem trotz der Fehlereindämmungsgrenzen zwischen den Zellen erwartet wird, wird die gemeinsame Ressourcennutzung durch das Zusammenwirken der verschiedenen Zellenkerne implementiert, doch wird die Richtlinie außerhalb der Kerne in dem Wax-Prozess implementiert. Sowohl Speicher als auch Prozessoren können gemeinsam genutzt werden.
Ein System mit der Bezeichnung "Cellular IRIX", das von Silicon Graphics Inc., Mountain View, Kalifornien, entwickelt und vermarktet wird, unterstützt modulares Rechnen durch Erweitern herkömmlicher symmetrischer Mehrprozess-Systeme. Die Celluar IRIX-Architektur teilt globalen Kern-Text und -Daten in optimierte Blöcke von SMP-Größe oder "Zellen" auf.
Die Zellen stellen eine Steuerdomäne dar, die aus einem oder mehreren Maschinenmodulen besteht, wobei jedes Modul aus Prozessoren, Speicher und I/O besteht. Anwendungen, die auf diesen Zellen laufen, stützen sich umfassend auf ein vollständiges Set von lokalen Betriebssystemdiensten, einschließlich lokalen Kopien des Betriebssystemtexts und der Kerndatenstrukturen. Nur eine Instanz des Betriebssystems ist auf dem gesamten System vorhanden. Die Koordinierung zwischen den Zellen ermöglicht es den Anwendungsbildern, die Verarbeitungs-, Speicher- und I/O-Ressourcen von anderen Zellen direkt und transparent zu nutzen, ohne den Overhead von Datenkopien oder zusätzliche Aufgabenumschaltungen zu übernehmen.
Eine weitere bestehende Architektur mit der Bezeichnung NUMA-Q, die von Sequent Computer Systems, Inc., Beaverton, Oregon, entwickelt und vermarktet wird, verwendet "Quads" bzw. Gruppen von vier Prozessoren pro Speicherabschnitt als den grundlegenden Funktionsbaustein für NUMA_Q SMP-Knoten. Die Erweiterung jedes Quads um I/O verbessert die Leistung zusätzlich. Daher unterteilt die NUMA-Q-Architektur nicht nur physikalischen Speicher, sondern stellt eine vorgegebene Anzahl von Prozessoren und PCI-Slots neben jeden Teil. Der Speicher in jedem Quad ist kein lokaler Speicher im üblichen Sinne. Er ist eher ein Drittel des physikalischen Speicheradressraums und weist einen spezifischen Adressbereich auf. Die Adressabbildung ist gleichmäßig über den Speicher verteilt, wobei jeder Quad einen zusammenhängenden Teil von Adressraum enthält. Es läuft nur eine Kopie des Betriebssystems, und wie in jedem SMP-System ist sie im Speicher resident und führt Prozesse ohne Unterscheidung und gleichzeitig in einem oder mehreren Prozessoren aus.
Dementsprechend, obwohl viele Versuche unternommen worden sind, ein flexibles Computersystem bereitzustellen, das eine maximale Ressourcenverfügbarkeit und Skalierbarkeit besitzt, weisen die vorhandenen Systeme jeweils beträchtliche Defizite auf. Es wäre daher wünschenswert, eine neue Computersystem-Auslegung zu haben, die eine verbesserte Flexibilität, Ressourcenverfügbarkeit und Skalierbarkeit bereitstellt.
US-A-5574914 offenbart ein Computersystem, in dem verschiedene Systemressourcen durch einen Verbindungsmechanismus elektrisch verbunden sind.
WO 97/04388 offenbart ein Computersystem mit einer Vielzahl von Systemressourcen, die Prozessoren, einen Speicher und eine I/O-Schaltung enthalten, wobei das Computersystem umfasst:
einen Verbindungsmechanismus;
einen Software-Mechanismus, der die Systemressourcen in eine Vielzahl von Partitionen unterteilt; und
wenigstens eine Betriebssystem-Instanz, die in einer Vielzahl der Partitionen läuft.
Gemäß der vorliegenden Erfindung ist ein solches System gekennzeichnet
dadurch, dass der Verbindungsmechanismus die Prozessoren, den Speicher und die I/O-Schaltung elektrisch so verbindet, dass jeder Prozessor elektrischen Zugriff auf den gesamten Speicher und wenigstens einen Teil der I/O-Schaltung hat; und
durch eine Konfigurations-Datenbank, die in dem Speicher gespeichert ist, welche die Partitionen anzeigt, die Teil des Computersystems sind, und welche Informationen enthält, die anzeigen, ob jede Betriebssystem-Instanz aktiv ist.
Die vorliegende Erfindung stellt des Weiteren ein Verfahren zum Aufbauen eines Computersystems mit einer Vielzahl von Systemressourcen bereit, die Prozessoren, einen Speicher und eine I/O-Schaltung enthalten, wobei das Verfahren die folgenden Schritte umfasst:

(a) elektrisches Verbinden der Prozessoren, des Speichers und der I/O-Schaltung so, dass jeder Prozessor elektrischen Zugang zu dem gesamten Speicher und wenigstens einem Teil der I/O-Schaltung hat;
(b) Unterteilen der Systemressourcen in eine Vielzahl von Partitionen;
(c) Ausführen wenigstens einer Betriebssystem-Instanz in einer Vielzahl der Partitionen; und
d) Erstellen einer Konfigurations-Datenbank, die Informationen dahingehend, welche der Partitionen Teil des Computersystems sind, und Informationen enthält, die anzeigen, ob jede Betriebssystem-Instanz aktiv ist.

Insbesondere partitioniert die Software logisch und adaptiv CPUs, Speicher und I/O-Ports, indem sie einander zugewiesen werden. Eine Instanz eines Betriebssystems kann dann auf eine Partition geladen werden. Zu unterschiedlichen Zeitpunkten können verschiedene Betriebssystem-Instanzen auf eine bestimmte Partition geladen werden. Diese Partitionierung, die ein System-Manager anweist, ist eine Software-Funktion; es sind keine Hardware-Grenzen erforderlich. Zu jeder einzelner Instanz sind die Ressourcen zugehörig, die sie für eine unabhängige Ausführung benötigt. Ressourcen, wie beispielsweise CPUs und Speicher, können verschiedenen Partitionen dynamisch zugewiesen und von Instanzen des Betriebssystems verwendet werden, die in der Maschine laufen, indem die Konfiguration modifiziert wird. Die Partitionen selbst können ebenfalls ohne Neustart des Systems geändert werden, indem der Konfigurationsbaum modifiziert wird. Das sich daraus ergebende adaptiv partitionierte Mehrprozessor-(APMP) System weist sowohl Skalierbarkeit als auch hohe Leistung auf.
Die oben genannten und weitere Vorteile der Erfindung lassen sich besser verstehen unter Bezugnahme auf die folgende Beschreibung in Verbindung mit den folgenden begleitenden Zeichnungen:
1 ist ein schematisches Blockschaltbild einer Hardware-Plattform, die mehrere System-Funktionsbausteine darstellt.
2 ist eine schematische Darstellung eines APMP-Computersystems, das in Übereinstimmung mit den Prinzipien der vorliegenden Erfindung aufgebaut ist und mehrere Partitionen zeigt.
3 ist eine schematische Darstellung eines Konfigurationsbaums, der Hardware-Ressourcenkonfigurationen und Software-Konfigurationen und ihre Komponententeile mit Child- und Geschwister-Adressenverweisen (sibling pointers) darstellt.
4 ist eine schematische Darstellung des Konfigurationsbaums, der in 3 gezeigt und neu angeordnet wurde, um die Zuweisung von Hardware zu Software-Instanzen durch Zugehörigkeits-Adressenverweise (ownership pointer) zu veranschaulichen.
5 ist ein Ablaufdiagramm, das Schritte in einer veranschaulichenden Routine zum Erstellen eines APMP-Computersystems in Übereinstimung mit den Prinzipen der vorliegenden Erfindung skizziert.
6 ist ein Ablaufdiagramm, das die Schritte in einer veranschaulichenden Routine zum Erstellen von Einträgen in einer APMP-Systemverwaltungs-Datenbank darstellt, die Informationen verwaltet, die das APMP-System und seine Konfiguration betreffen.
7A und 7B bilden, wenn sie zusammengelegt werden, ein Ablaufdiagramm, das im Detail die Schritte in einer veranschaulichenden Routine zum Erstellen eines APMP-Computersystems in Übereinstimmung mit den Prinzipien der vorliegenden Erfindung darstellt.
8A und 8B bilden, wenn sie zusammengelegt werden, ein Ablaufdiagramm, das die Schritte in einer veranschaulichenden Routine darstellt, denen eine Betriebssystem-Instanz folgt, um an einem APMP-Computersystem, das bereits erstellt ist, teilzunehmen.
Eine Computerplattform, die in Übereinstimmung mit den Prinzipien der vorliegenden Erfindung aufgebaut ist, ist ein Mehrprozessorsystem, das partitioniert werden kann, um die gleichzeitige Ausführung mehrerer Instanzen von Betriebssystem-Software zu gestatten. Für das System ist keine Hardware-Unterstützung für die Partitionierung seines Speichers, der CPUs und der I/O-Untersysteme erforderlich, aber einige Hardware lässt sich verwenden, um eine zusätzliche Hardware-Hilfe zum Isolieren von Fehlern und zum Minimieren der Kosten des Software-Engineering bereitzustellen. Die folgende Spezifikation beschreibt die Schnittstellen und Datenstrukturen, die zum Unterstützen der erfinderischen Software-Archi tektur erforderlich sind. Die beschriebenen Schnittstellen und Datenstrukturen sollen nicht implizieren, dass ein bestimmtes Betriebssystem verwendet werden muss, oder dass nur ein einziger Typ von Betriebssystem eine gleichzeitige Ausführung vornimmt. Jedes Betriebssystem, das die im Folgenden erläuterten Software-Anforderungen implementiert, kann an dem erfinderischen Systembetrieb teilnehmen.
System-Funktionsbausteine
Die erfinderische Software-Architektur arbeitet auf einer Hardware-Plattform, die mehrere CPUs, einen Speicher und I/O-Hardware integriert. Vorzugsweise wird eine modulare Architektur wie diejenige, die in 1 gezeigt ist, verwendet, obwohl der Fachmann verstehen wird, dass auch andere Architekturen verwendet werden können, wobei diese Architekturen nicht modular sein müssen. 1 stellt ein Rechnersystem dar, das aus vier grundlegenden System-Funktionsbausteinen (SBBs) 100–106 aufgebaut ist. In der veranschaulichenden Ausführungsform ist jeder Funktionsbaustein, wie beispielsweise Baustein 100, identisch und umfasst mehrere CPUs 108–114, mehrere Speicher-Slots, (die insgesamt als der Speicher 120 dargestellt werden), einen I/O-Prozessor 118 und einen Port 116, der einen (nicht gezeigten) Schalter enthält, der das System mit einem anderen solchen System verbinden kann. In anderen Ausführungsformen müssen die Funktionsbausteine jedoch nicht identisch sein. Große Mehrprozessor-Systeme können aufgebaut werden, indem die gewünschte Anzahl von System-Funktionsbausteinen mittels ihrer Ports verbunden werden. Es wird eine Schalter-Technologie statt einer Bus-Technologie zum Verbinden von Funktionsbaustein-Komponenten verwendet, um sowohl die verbesserte Bandbreite zu erhalten als auch nicht-einheitliche Speicher-Architekturen (NUMA) zu gestatten.
In Übereinstimmung mit den Prinzipien der Erfindung sind die Hardware-Schalter so angeordnet, dass jede CPU alle verfügbaren Speicher und I/O-Ports ansteuern kann, ungeachtet der Anzahl von konfigurierten Funktionsbausteinen, wie dies schematisch durch Leitung 122 dargestellt ist. Des Weiteren können alle CPUs mit irgendeiner oder allen anderen CPUs in allen SBBs mit herkömmlichen Mitteln kommunizieren, wie beispielsweise Interprozessor-Interrupts. Dementsprechend können die CPUs und andere Hardware-Ressourcen nur mit Software verknüpft werden. Eine solche Plattform-Architektur ist inhärent so skalierbar, dass große Mengen von Verarbeitungsleistung, Speicher und I/O in einem einzelnen Computer verfügbar sind.
Ein APMP-Computersystem 200, das in Übereinstimmung mit den Prinzipien der vorliegenden Erfindung vom Software-Standpunkt her aufgebaut ist, ist in 2 dargestellt. In diesem System wurden die Hardware-Komponenten zugewiesen, um die gleichzeitige Ausführung von mehreren Betriebssystem-Instanzen 208, 210, 212 zu gestatten.
In einer bevorzugten Ausführungsform wird diese Reservierung durch ein Software-Programm vorgenommen, das als ein "Konsolenprogramm" bezeichnet wird, weiches, wie hierin im Folgenden im Detail beschrieben wird, beim Hochfahren in den Speicher geladen wird. Konsolenprogramme werden in 2 schematisch als Programme 213, 215 und 217 gezeigt. Das Konsolenprogramm kann eine Modifizierung eines bestehenden administrativen Programms oder ein separates Programm sein, das mit einem Betriebssystem zusammenwirkt, um den Betrieb der bevorzugten Ausführungsform zu steuern. Das Konsolenprogramm virtualisiert die Systemressourcen nicht, das heißt, es erstellt keine Software-Schichten zwischen den laufenden Betriebssystemen 208, 210 und 212 und der physikalischen Hardware, wie beispielsweise dem Speicher und den I/O-Einheiten (in 2 nicht gezeigt). Auch der Zustand der laufenden Betriebssysteme 208, 210 und 212 wird nicht gewechselt, um Zugriff auf die gleiche Hardware bereitzustellen. Stattdessen unterteilt das erfinderische System die Hardware logisch in Partitionen. Es liegt in der Zuständigkeit der Betriebssystem-Instanz 208, 210 und 212, die Ressourcen entsprechend einzusetzen und eine Koordinierung der Reservierung und gemeinsamen Nutzung der Ressourcen bereitzustellen. Die Hardware-Plattform kann optional eine Hardware-Unterstützung für die Unterteilung der Ressourcen bereitstellen oder kann Fehlersperren bereitstellen, um die Möglichkeit zu minimieren, dass ein Betriebssystem den Speicher beschädigt oder sich auf Einrichtungen auswirkt, die durch eine andere Betriebssystem-Kopie gesteuert werden.
Die Ausführungsumgebung für eine einzelne Kopie eines Betriebssystems, wie beispielsweise die Kopie 208, wird als eine "Partition" 202 bezeichnet, und das ausführende Betriebssystem 208 in der Partition 202 wird als "Instanz" 208 bezeichnet. Jede Betriebssystem-Instanz ist in der Lage, unabhängig von allen anderen Betriebssystem-Instanzen in dem Computersystem zu booten und unabhängig von ihnen zu laufen und kann zusammenwir kend an der gemeinsamen Nutzung von Ressourcen zwischen Betriebssystem-Instanzen teilnehmen, wie im Folgenden beschrieben.
Zum Ausführen einer Betriebssystem-Instanz muss eine Partition einen Hardware-Neustart-Parameterblock (HWRPB), eine Kopie eines Konsolenprogramms, eine gewisse Speichermenge, eine oder mehrere CPUs und wenigstens einen I/O-Bus umfassen, der einen bestimmten physikalischen Port für die Konsole aufweisen muss. Der HWRPB ist ein Konfigurationsblock, der zwischen dem Konsolenprogramm und dem Betriebssystem übergeben wird.
Jedes der Konsolenprogramme 213, 215 und 217 ist an einen Konsolen-Port angeschlossen, der als die entsprechenden Ports 214, 216 und 218 gezeigt wird. Konsolen-Ports, wie beispielsweise die Ports 214, 216 und 218 liegen im Allgemeinen in Form eines seriellen Leitungs-Ports oder von angeschlossenen Grafik-, Tastatur- und Maus-Optionen vor. Zum Zweck des erfinderischen Computersystems ist die Fähigkeit, ein spezifisches Betriebssystem oder dazugehörige Eingabeeinrichtungen zu unterstützen, nicht erforderlich, obwohl ein spezifisches Betriebssystem dies erfordern kann. Die grundlegende Voraussetzung ist, dass ein serieller Port für jede Partition ausreichend ist. Während ein separates Endgerät oder eine unabhängige Grafikkonsole verwendet werden könnten, um die von jeder Konsole generierten Informationen anzuzeigen, können vorzugsweise die seriellen Leitungen 220, 222 und 224 alle mit einem einzelnen Multiplexer 226 verbunden werden, der an eine Workstation, einen PC oder LAT 228 zum Anzeigen von Konsolen-Informationen angeschlossen ist.
Es ist wichtig zu beachten, dass Partitionen nicht gleichbedeutend mit System-Funktionsbausteinen sind. Zum Beispiel kann die Partition 202 die Hardware in den Funktionsbausteinen 100 und 106 in 1 umfassen, während die Partitionen 204 und 206 die Hardware in den entsprechenden Funktionsbausteinen 102 und 104 umfassen könnten. Partitionen können auch einen Teil der Hardware in einem Funktionsbaustein enthalten.
Partitionen können "initialisiert" oder "nichtinitialisiert" sein. Eine initialisierte Partition weist ausreichende Ressourcen auf, um eine Betriebssystem-Instanz auszuführen, besitzt ein geladenes Konsolenprogramm-Bild und eine primäre CPU, die verfügbar und ausführend ist. Eine initialisierte Partition kann unter der Steuerung eines Konsolenprogramms stehen oder kann eine Betriebssystem-Instanz ausführen. In einem initialisierten Zustand weist eine Partition die volle Zugehörigkeit und die Steuerung der Hardware-Komponenten auf, die ihr zugewiesen sind, und nur die Partition selbst kann ihre Komponenten freigeben.
In Übereinstimmung mit den Prinzipien der Erfindung können Ressourcen von einer initialisierten Partition einer anderen neu zugewiesen werden. Die Neuzuweisung der Ressourcen kann nur durch die initialisierte Partition vorgenommen werden, welcher die Ressource gegenwärtig zugewiesen ist. Wenn sich eine Partition in einem nichtinitialisierten Zustand befindet, können andere Partitionen ihre Hardware-Komponenten neu zuweisen und sie löschen.
Eine nichtinitialisierte Partition ist eine Partition, die keine primäre CPU besitzt, die entweder unter der Steuerung eines Konsolenprogramms oder eines Betriebssystems ausgeführt wird. Zum Beispiel kann eine Partition beim Hochfahren auf Grund eines Mangels an ausreichenden Ressourcen zum Ausführen einer primären CPU nichtinitialisiert sein, oder wenn ein Systemadministrator das Computersystem neu konfiguriert. Im nichtinitialisierten Zustand kann eine Partition ihre Hardware-Komponenten neu zuweisen und kann von einer anderen Partition gelöscht werden. Nicht zugewiesene Ressourcen können von jeder Partition zugewiesen werden.
Partitionen können in "Communities" organisiert werden, welche die Basis zum Gruppieren getrennter Ausführungskontexte bereitstellt, um eine zusammenwirkende gemeinsame Ressourcen-Nutzung zu gestatten. Partitionen in der gleichen Community können Ressourcen gemeinsam nutzen. Partitionen, die sich nicht in der gleichen Community befinden, können Ressourcen nicht gemeinsam nutzen. Ressourcen können zwischen den Partitionen, die sich nicht in der gleichen Community befinden, nur manuell durch den Systemadministrator verschoben werden, in dem die Ressourcenzuweisung aufgehoben (und die Nutzung gestoppt) wird, und die Ressource manuell neu konfiguriert wird. Communities können verwendet werden, um unabhängige Betriebssystem-Domänen zu erstellen oder Benutzerrichtlinien für den Hardware-Einsatz zu implementieren. In 2 sind die Partitionen 202 und 204 in der Community 230 organisiert worden. Die Partition 206 kann in ihrer eigenen Community 205 liegen. Communities können unter Verwendung des im Folgenden beschriebenen Konfigurationsbaums aufgebaut und durch Hardware durchgesetzt werden.
Das Konsolenprogramm
Wenn ein Computersystem, das in Übereinstimmung mit den Prinzipien der vorliegenden Erfindung aufgebaut ist, auf einer Plattform aktiviert wird, müssen mehrere HWRPBs erstellt, mehrere Konsolenprogramm-Kopien geladen und Systemressourcen auf eine Weise zugewiesen werden, dass jeder HWRPB zu spezifischen Komponenten des Systems zugeordnet wird. Dazu erstellt das erste auszuführende Konsolenprogramm eine Konfigurationsbaum-Struktur im Speicher, welche die gesamte Hardware im System darstellt. Der Baum enthält auch Software-Partitionierungsinformationen, und die Zuweisungen von Hardware zu Partitionen wird im Folgenden ausführlich erläutert.
Wenn das APMP-System hochgefahren wird, wird insbesondere eine CPU als eine primäre CPU in einer herkömmlichen Weise von Hardware ausgewählt, die für die Plattform spezifisch ist, auf der das System läuft. Die primäre CPU lädt dann eine Kopie eines Konsolenprogramms in den Speicher. Diese Konsole wird als ein "Master-Konsolen"-Programm bezeichnet. Die primäre CPU arbeitet anfänglich unter der Steuerung des Master-Konsolenprogramms, um den Test- und Prüfvorgang unter der Voraussetzung durchzuführen, dass ein einzelnes System vorhanden ist, zu der die gesamte Maschine zugehörig ist. Anschließend wird ein Set von Umgebungsvariablen geladen, welche die Systempartitionen definieren. Schließlich erstellt die Masterkonsole die Partitionen basierend auf den Umgebungsvariablen. in diesem letzteren Prozess arbeitet die Masterkonsole, um den Konfigurationsbaum zu erstellen, zusätzliche HWRPB-Datenblöcke zu erstellen, zusätzliche Konsolenprogramm-Kopien zu laden und die CPUs auf den alternativen HWRPBs zu starten. Auf jeder Partition läuft dann eine Betriebssystem-Instanz, wobei die Instanz mit einer Konsolenprogramm-Kopie zusammenwirkt, die ebenfalls in der Partition läuft. In einem nichtkonfigurierten APMP-System erstellt das Master-Konsolenprogramm zuerst eine einzelne Partition, welche die primäre CPU, eine Mindest-Speichermenge und eine physikalische Konsole des Systemadministrators enthält, die auf eine plattformspezifische Weise ausgewählt wird. Konsolenprogramm-Befehle gestatten es dem Systemadministrator dann, zusätzliche Partitionen zu erstellen und I/O-Busse, Speicher und CPUs für jede Partition zu konfigurieren.
Nachdem die Zuordnungen von Ressourcen zu Partitionen durch das Konsolenprogramm vorgenommen worden sind, werden die Zuordnungen in einem nicht-flüchtigen RAM gespeichert, um eine automatische Konfiguration des Systems während anschließender Boot-Vorgänge zu gestatten. Während der anschließenden Boot-Vorgänge muss das Master-Konsolenprogramm die gegenwärtige Konfiguration mit der gespeicherten Konfiguration validieren, um das Entfernen und Hinzufügen von neuen Komponenten zu bearbeiten. Neu hinzugefügte Komponenten werden in einen nicht-zugewiesenen Zustand gesetzt, bis sie durch den Systemadministrator zugewiesen werden. Wenn das Entfernen von Hardware-Komponenten zu einer Partition mit unzureichenden Ressourcen zum Ausführen eines Betriebssystems führt, werden weiterhin Ressourcen zu der Partition hinzugefügt, doch eine Betriebssystem-Instanz kann erst auf ihr laufen, wenn ihr zusätzliche neue Ressourcen zugewiesen werden.
Wie vorher erwähnt, kommuniziert das Konsolenprogramm mit einer Betriebssystem-Instanz mittels eines HWRPB, der während des Hochfahrens des Betriebssystems an das Betriebssystem übergeben wird. Die grundlegenden Anforderungen für ein Konsolenprogramm sind, dass es in der Lage sein muss, mehrere Kopien von HWRPBs und sich selbst zu erstellen. Jede durch das Konsolenprogramm erstellte HWRPB-Kopie ist in der Lage, eine unabhängige Betriebsystem-Instanz in einen privaten Speicherabschnitt zu booten, und jede auf diese Weise gestartete Betriebssystem-Instanz kann durch einen eindeutigen Wert identifiziert werden, der in den HWRPB gestellt wird. Der Wert gibt die Partition an und wird auch als die Betriebssystem-Instanz-ID verwendet.
Des Weiteren wird das Konsolenprogramm konfiguriert, um einen Mechanismus zum Entfernen einer CPU aus den verfügbaren CPUs in einer Partition in Reaktion auf eine Anforderung durch ein Betriebssystem bereitzustellen, das in dieser Partition läuft. Jede Betriebssystem-Instanz muss in der Lage sein, auf eine Weise abzuschalten, anzuhalten oder anderweitig abzustürzen, dass die Steuerung an das Konsolenprogramm übergeben wird. Umgekehrt muss jede Betriebssystem-Instanz in der Lange sein, sich unabhängig von jeder anderen Betriebssystem-Instanz erneut in einen betriebsfähigen Modus zu booten.
Jeder HWRPB, der durch ein Konsolenprogramm erstellt wird, enthält eine slotspezifische CPU-Datenbank für jede CPU, die sich in dem System befindet oder die zu dem System hinzugefügt werden kann, ohne das gesamte System abzuschalten. Jede CPU, die physikalisch vorhanden ist, wird als "present" markiert, doch nur CPUs, die zuerst in einer spezifischen Partition ablaufen, werden in dem HWRPB für die Partition als "available" markiert. Die Betriebssystem-Instanz, die auf einer Partition läuft, ist in der Lage, über ein Bit present (vorhanden) (PP) in Feldern eines Zustands-Flag pro CPU (per-CPU state flag fields) des HWRPB zu erkennen, dass eine CPU zu einem künftigen Zeitpunkt verfügbar sein wird und kann Datenstrukturen aufbauen, um dies wiederzugeben. Wenn es gesetzt ist, zeigt das Bit available (verfügbar) (PA) in den Feldern eines Zustands-Flag pro CPU an, dass die zugehörige CPU gegenwärtig mit der Partition verknüpft ist, und kann eingeladen werden, an dem SMP-Betrieb teilzunehmen.
Der Konfigurationsbaum
Wie vorher erwähnt, erstellt das Master-Konsolenprogramm einen Konfigurationsbaum, der die Hardware-Konfiguration und die Zuweisung jeder Komponente in dem System zu jeder Partition darstellt. Jedes Konsolenprogramm identifiziert dann den Konfigurationsbaum für seine zugehörige Betriebssystem-Instanz, indem ein Adressenverweis auf den Baum in den HWRPB gestellt wird.
Unter Bezugnahme auf 3 stellt der Konfigurationsbaum 300 die Hardware-Komponenten in dem System, die Plattformbedingungen und Mindestvorgaben und die Saftware-Konfiguration dar. Das Master-Konsolenprogramm baut den Baum unter Verwendung von Informationen auf, die durch Prüfen der Hardware erfasst wurden, und von Informationen, die in dem nicht-flüchtigen RAM gespeichert sind, der die Konfigurationsinformationen enthält, die während vorheriger Initialisierungen generiert worden sind.
Die Master-Konsole kann eine einzelne Kopie des Baums generieren, dessen Kopie von allen Betriebssystem-Instanzen gemeinsam genutzt wird, oder sie kann den Baum für jede Instanz replizieren. Eine einzelne Kopie des Baums weist den Nachteil auf, dass er eine einzelne Fehlerstelle in Systemen mit unabhängigen Speichern erzeugen kann. Plattformen, die mehrere Baum-Kopien generieren, fordern von den Konsolenprogrammen jedoch, dass sie in der Lage sein müssen, Änderungen an dem Baum synchronisiert zu halten.
Der Konfigurationsbaum umfasst mehrere Knoten, einschließlich Stammknoten, Child-Knoten und Geschwister-Knoten. Jeder Knoten wird aus einem festen Header und einer Erweiterung mit variabler Länge für überlagerte Datenstrukturen gebildet. Der Baum beginnt mit einem Baum-Stammknoten 302, der die gesamte System-Box darstellt, gefolgt von Zweigen, welche die Hardware-Konfiguration (Hardware-Stammknoten 304), die Software-Konfiguration (Software-Stammknoten 306) und die Mindestanforderungen an die Partition (Masken-Stammknoten 308) beschreiben. In 3 stellen die Pfeile Child- und Geschwister-Beziehungen dar. Die Children eines Knotens stellen Komponententeile der Hardware- oder Software-Konfiguration dar. Geschwister sind Gleichgestellte einer Komponente, die nicht in Beziehung stehen können, außer dadurch, dass sie den gleichen Stamm haben. Knoten in dem Baum 300 können Informationen über die Software-Communities und Betriebssystem-Instanzen, die Hardware-Konfiguration, Konfigurationsbedingungen, Leistungseinschränkungen und Hot-Swap-Fähigkeiten enthalten. Die Knoten stellen auch die Beziehung von Hardware- zu Software-Zugehörigkeit oder der gemeinsamen Nutzung einer Hardware-Komponente bereit.
Die Knoten werden zusammenhängend im Speicher gespeichert, und der Adressen-Offset von dem Baum-Stammknoten 320 des Baums 300 zu einem spezifischen Knoten bildet eine "Kennung" (handle), die von jeder Betriebssystem-Instanz verwendet werden kann, um die gleiche Komponente auf jeder Betriebssystem-Instanz eindeutig zu identifizieren. Des Weiteren weist jede Komponente in dem erfinderischen Computersystem eine separate ID auf. Dies kann beispielsweise ein 64-Bit-Wert ohne Vorzeichen sein. Die ID muss eine eindeutige Komponente angeben, wenn sie mit den Typ- und untergeordneten Typ-Werten der Komponente kombiniert wird. Das heißt, die ID muss eine für einen vorgegebenen Komponententyp spezifische Komponente identifizieren. Die ID kann eine einfache Zahl sein, zum Beispiel die CPU-ID, sie kann irgendeine andere eindeutige Verschlüsselung oder eine physikalische Adresse sein. Die Komponenten-ID und die Kennung gestatten es jedem Element des Computersystems, einen bestimmten Teil von Hardware oder Software zu identifizieren. Das heißt, jede Parition muss unter Verwendung eines der Spezifikationsverfahren in der Lage sein, die gleiche Spezifikation zu verwenden und das gleiche Ergebnis zu erzielen.
Wie oben beschrieben, setzt sich das erfinderische Computersystem aus einer oder mehreren Communities zusammen, die wiederum aus einer oder mehreren Partitionen bestehen. Durch Unterteilen der Partitionen übergreifend über die unabhängigen Communities kann das erfinderische Computersystem in eine Konfiguration gesetzt werden, in der die gemeinsame Nutzung der Einrichtungen und des Speichers begrenzt werden kann. Die Communities und Partitionen haben IDs, die eng gepackt sind. Die Hardware-Plattform bestimmt die maximale Anzahl von Partitionen basierend auf der Hardware, die in dem System vorhanden ist, sowie auf der Plattform-Obergrenze. Partitions- und Community-IDs überschreiten diesen Wert während der Laufzeit nie. Die IDs werden für gelöschte Partitionen und Communities wiederverwendet. Die maximale Anzahl von Communities ist die gleiche wie die maximale Anzahl von Partitionen. Des Weiteren wird jede Betriebssystem-Instanz durch eine eindeutige Instanz-Kennung identifiziert, beispielsweise eine Kombination der Partitions-ID plus einer Inkarnationsnummer (incarnation number).
Die Communities und Partitionen werden durch einen Software-Stammknoten 306 dargestellt, der Community-Knoten-Children, (von denen nur der Community-Knoten 310 gezeigt ist), und Partitionsknoten-Grandchildren, (von denen zwei Knoten, 312 und 314, gezeigt sind), aufweist.
Die Hardware-Komponenten werden durch einen Hardware-Stammknoten 304 dargestellt, der Children enthält, die eine hierarchische Darstellung der gesamten Hardware zeigen, die gegenwärtig in dem Computersystem vorhanden ist. Die "Zugehörigkeit" einer Handware-Komponente wird durch eine Kennung in dem zugehörigen Hardware-Knoten dargestellt, der auf den entsprechenden Software-Knoten (310, 312 oder 314) verweist. Diese Kennungen sind in 4 dargestellt und werden im Folgenden ausführlicher erläutert. Komponenten, die zu einer spezifischen Partition zugehörig sind, weisen Kennungen auf, die auf den Knoten verweisen, der die Partition darstellt. Hardware, die von mehreren Partitionen gemeinsam genutzt wird, (zum Beispiel der Speicher), weist Kennungen auf, die auf die Community verweisen, auf welche die gemeinsame Nutzung beschränkt ist. Keiner Zugehörigkeit zugeordnete Hardware weist eine Kennung von Null auf, (die den Baum-Stammknoten 302 darstellt).
Hardware-Komponenten stellen Konfigurationsbedingungen dahingehend auf, wie eine Zugehörigkeit aufgeteilt werden kann. Eine "config"-Kennung in dem Konfigurationsbaum-Knoten, die mit jeder Komponente verbunden ist, bestimmt, ob die Komponente frei ist, um irgendwo in dem Computersystem durch Verweisen auf den Hardware-Stammknoten 304 zugeordnet zu werden. Einige Hardware-Komponenten können jedoch an einen Ancestor-Knoten gebunden sein und müssen als Teil dieses Knotens konfiguriert werden. Beispiele dafür sind CPUs, die keinerlei Einschränkungen dazu aufweisen können, wo sie ausgeführt werden, die aber einen Komponententeil eines System-Funktionsbausteins (SBB) bilden, wie beispielsweise die SBBs 322 oder 324. In diesem Fall, auch wenn die CPU ein Child des SBB ist, verweist ihre config-Kennung auf den Hardware-Stammknoten 304. Ein I/O-Bus kann jedoch nicht zu einer anderen Partition als derjenigen Partition zugehörig sein, zu deren Zugehörigkeit sein I/O-Prozessor gehört. In diesem Fall würde der Konfigurationsbaum-Knoten, der den I/O-Bus darstellt, eine config-Kennung aufweisen, die auf den I/O-Prozessor verweist. Da die Regeln, nach denen sich die Hardware-Konfiguration richtet, plattformspezifisch sind, werden diese Informationen durch die config-Kennung für die Betriebssystem-Instanzen bereitgestellt.
Jede Hardware-Komponente weist auch eine "Affinitäts"- (affinity) Kennung auf. Die Affinitätskennung ist identisch mit der config-Kennung, außer, dass sie eine Konfiguration darstellt, mit der die beste Leistung der Komponente zu erzielen ist. Zum Beispiel können eine CPU oder ein Speicher eine config-Kennung aufweisen, die es ermöglicht, sie überall in dem Computersystem zu konfigurieren, (sie verweist auf den Hardware-Knoten 304), doch sollte die CPU bzw. der Speicher so konfiguriert sein, dass sie den System-Funktionsbaustein verwenden, von dem sie ein Teil sind. Das Ergebnis ist, dass der config-Adressenverweis auf den Hardware-Stammknoten 304 verweist, der Affinitäts-Adressenverweis jedoch auf einen SBB-Knoten verweist, wie beispielsweise Knoten 322 oder Knoten 324. Die Affinität jeder Komponente ist plattformspezifisch und wird durch die Firmware bestimmt. Die Firmware kann diese Informationen verwenden, wenn die Ausbildung "optimaler" automatischer Konfigurationen gewünscht wird.
Jeder Knoten enthält auch mehrere Flags, die den Typ und Zustand des Knotens anzeigen. Zu diesen Flags gehört ein Flag node_hotswap, das anzeigt, dass die dargestellte Komponente eine "hotswap-fähige" Komponente ist und unabhängig von ihrem Parent- oder ihren Geschwister-Knoten abgeschaltet werden kann. Allerdings müssen alle Children dieses Knotens abgeschaltet werden, wenn sich diese Komponente abschaltet. Wenn sich die Children unabhängig von dieser Komponente abschalten können, muss dieses Bit auch für sie in ihren entsprechenden Knoten gesetzt sein. Ein weiteres Flag ist das Flag node_unavailable, das, wenn es gesetzt ist, anzeigt, dass die durch den Knoten dargestellte Komponente gegenwärtig nicht zur Verwendung zur Verfügung steht. Wenn eine Komponente abgeschaltet wird, (oder niemals eingeschaltet wird), wird sie als nicht verfügbar gekennzeichnet.
Zwei Flags, node_hardware und node_template, zeigen den Knotentyp an. Weitere Flags, wie beispielsweise node_initialized und node_cpu_primary, können ebenfalls bereitgestellt werden, um anzuzeigen, ob der Knoten eine Partition darstellt, die initialisiert worden ist, oder eine CPU, die gegenwärtig eine primäre CPU ist.
Der Konfigurationsbaum 300 kann sich auf die Ebene von Einrichtungs-Controllern erstrecken, die es dem Betriebssystem gestatten, Bus- und Einrichtungs-Konfigurationstabellen zu erstellen, ohne die Busse zu prüfen. Der Baum kann jedoch auf jeder Ebene enden, wenn alle darunter liegenden Komponenten nicht unabhängig konfiguriert werden können. System-Software ist noch erforderlich, um Bus- und Einrichtungs-Informationen zu prüfen, die von dem Baum nicht bereitgestellt werden.
Das Konsolenprogramm implementiert Konfigurationsbedingungen und setzt sie, sofern vorhanden, auf jeder Komponente des Systems durch. Im Allgemeinen können die Komponenten entweder ohne Bedingungen zugewiesen werden, (zum Beispiel weisen CPUs keine Bedingungen auf), oder sie sind nur als Teil einer anderen Komponente konfigurierbar, (ein Einrichtungsadapter ist zum Beispiel nur als ein Teil seines Busses konfigurierbar). Eine Partition, die, wie oben erläutert, eine Gruppierung von CPUs, Speicher und I/O-Einrichtungen zu einer eindeutigen Software-Einheit ist, weist ebenfalls Mindestanforderungen auf. Zum Beispiel sind die Hardware-Mindestanforderungen für eine Partition wenigstens eine CPU, einiger privater Speicher, (plattformabhängiger Mindestwert, einschließlich Konsolenspeicher), und ein I/O-Bus, einschließlich eines physikalischen, nicht gemeinsam genutzten Konsolen-Ports.
Die Komponenten-Mindestanforderungen für eine Partition werden durch die Informationen bereitgestellt, die in dem Masken-Stammknoten 308 enthalten sind. Der Masken-Stammknoten 308 enthält die Knoten 316, 318 und 320, welche die Hardware-Komponenten darstellen, die bereitgestellt werden müssen, um eine Partition zu erstellen, die zur Ausführung eines Konsolenprogramms und einer Betriebssystem-Instanz fähig ist. Konfigurations-Editoren können diese Informationen als die Basis für die Bestimmung verwenden, welche Typen und wie viele Ressourcen verfügbar sein müssen, um eine neue Partition auszubilden.
Während des Aufbaus einer neuen Partition wird der Masken-Unterbaum "durchgegangen", und für jeden Knoten in dem Masken-Unterbaum muss ein Knoten des gleichen Typs und Untertyps zu der neuen Partition zugehörig sein, so dass sie fähig ist, ein Konsolenprogramm zu laden und eine Betriebssystem-Instanz zu booten. Wenn mehr als ein Knoten des gleichen Typs und Untertyps in dem Masken-Baum vorhanden ist, müssen auch mehrere Knoten in der neuen Partition vorhanden sein. Das Konsolenprogramm verwendet die Masken zum Validieren dessen, dass eine neue Partition die Mindestanforderungen aufweist, bevor versucht wird, ein Konsolenprogramm zu laden und den Betrieb zu initialisieren.
Folgendes ist ein ausführliches Beispiel einer bestimmten Implementierung von Konfigurationsbaum-Knoten. Es soll nur zu beschreibenden Zwecken dienen und soll nicht einschränkend sein. Jeder HWRPB muss auf einen Konfigurationsbaum verweisen, der die gegenwärtige Konfiguration und die Zuweisungen von Komponenten zu Partitionen bereitstellt. Ein Konfigurations-Adressenverweis (im Feld CONFIG) im HWRPB wird verwendet, um auf den Konfigurationsbaum zu verweisen. Das Feld CONFIG verweist auf einen 64-Byte-Header, der die Größe des Speicher-Pools für den Baum und die ursprüngliche Prüfsumme des Speichers enthält. Unmittelbar nach dem Header befindet sich der Stammknoten des Baums. Der Header und der Stammknoten des Baums sind seitensynchronisiert (page aligned).
Die Gesamtgröße des für den Konfigurationsbaum reservierten Speichers in Byte befindet sich in dem ersten Quad-Wort des Headers. Es wird sichergestellt, dass die Größe in Vielfachen der Hardware-Seitengröße vorliegt. Das zweite Quad-Wort des Headers ist für eine Prüfsumme reserviert. Um den Konfigurationsbaum prüfen zu können, bildet eine Betriebssystem-Instanz den Baum in ihren lokalen Adressraum ab. Da eine Betriebssystem-Instanz diesen Speicher mit Lesezugriff, der für alle Anwendungen gestattet ist, abbilden kann, müssen einige Vorkehrungen getroffen werden, um eine nicht-privilegierte Anwendung daran zu hindern, Zugriff auf Konsolendaten zu erlangen, auf die sie keinen Zugriff haben soll. Der Zugriff kann eingeschränkt werden, indem der Speicher entsprechend reserviert wird. Zum Beispiel kann der Speicher seitensynchronisiert und in ganzen Seiten reserviert werden. Normalerweise bildet eine Betriebssystem-Instanz die erste Seite des Konfigurationsbaums ab, erhält die Baumgröße und bildet den Speicher, der für die Konfigurationsbaum-Nutzung reserviert ist, nochmals ab. Die Gesamtgröße kann zusätzlichen Speicher umfassen, der von der Konsole für dynamische Änderungen an dem Baum verwendet wird.
Vorzugsweise werden Konfigurationsbaum-Knoten mit festen Anfangsblöcken gebildet und können optional typspezifische Informationen enthalten, die auf den festen Teil folgen. Das Feld Größe enthält die volle Länge des Knotens, Knoten werden veranschaulichend in Vielfachen von 64 Bytes reserviert und nach Bedarf aufgefüllt. Die folgende Beschreibung definiert veranschaulichende Felder in dem festen Header für einen Knoten:
In der oben genannten Definition sind die Typ-Definitionen "uint" ganze Zahlen ohne Vorzeichen mit den entsprechenden Bitlängen. Wie vorher erwähnt, werden die Knoten durch eine Kennung aufgefunden und identifiziert, (in der Definition oben identifiziert durch die typedef DCT_HANDLE). Eine veranschaulichende Kennung ist ein 32-Bit-Offset mit Vorzeichen von der Basis des Konfigurationsbaums zu dem Knoten. Der Wert ist über alle Partitionen übergreifend in dem Computersystem eindeutig. Das heißt, eine Kennung, die auf einer Partition erhalten wird, muss zum Suchen eines Knotens oder als eine Eingabe in eine Konsolen-Rückfrage (console callback) auf allen Partitionen gültig sein. Das Feld magic enthält ein vorgegebenes Bit-Muster, das anzeigt, dass der Knoten tatsächlich ein gültiger Knoten ist.
Der Baum-Stammknoten stellt das gesamte System dar. Seine Kennung ist immer Null. Das heißt, er befindet sich immer an dem ersten physikalischen Speicherplatz in dem Speicher, der für den Konfigurationsbaum nach dem config-Header reserviert ist. Er weist die folgende Definition auf:
Die Felder in dem Stammknoten werden wie folgt definiert:
lock
Dieses Feld wird als eine einfache Sperre durch Software verwendet, die Änderungen an der Struktur des Baums und der Software-Konfiguration verhindern möchte. Wenn dieser Wert –1 ist, (alle Bits eingeschaltet), ist der Baum nicht gesperrt; wenn der Wert ≥ 0 ist, ist der Baum gesperrt. Dieses Feld wird unter Verwendung von unterbrechungsfreien Operationen modifiziert. Die Aufrufeinrichtung (caller) der Sperr-Routine übergibt eine Partitions-ID, die in das Feld Sperre geschrieben wird. Dies kann zur Unterstützung bei der Fehlerverfolgung und Wiederherstellung bei Abstürzen verwendet werden.
transient_level
Dieses Feld wird beim Start einer Baum-Aktualisierung inkrementiert.
current_level
Dieses Feld wird bei Beendigung einer Baum-Aktualisierung inkrementiert.
console_req
Dieses Feld gibt den Speicher in Bytes an, der für die Konsole im Grund-Speichersegment einer Partition erforderlich ist.
min_alloc
Dieses Feld enthält die Mindestgröße eines Speicherfragments und die Reservierungseinheit (die Fragmentgröße muss ein Vielfaches der Reservierung betragen). Es muss eine Potenz von 2 sein.
min_align
Dieses Feld enthält die Synchronisierungsanforderungen für ein Speicherfragment. Es muss eine Potenz von 2 sein.
base_alloc
Dieses Feld gibt den Mindestspeicher in Bytes an (einschließlich console_req), der für das Grund-Speichersegment für eine Partition benötigt wird. Dort werden die Konsole, Konsolenstrukturen und das Betriebssystem für eine Partition geladen. Er muss größer oder gleich minAlloc und ein Vielfaches von minAlloc sein.
base_align
Dieses Feld enthält die Synchronisierungsanforderungen für das Grund-Speichersegment einer Partition. Es muss eine Potenz von 2 sein und eine Synchronisierung von mindestens min-align sein.
max_phys_address
Dieses Feld enthält die berechnete größte physikalische Adresse, die auf dem System vorhanden sein kann, einschließlich Speicher-Subsystemen, die gegenwärtig nicht eingeschaltet und verfügbar sind.
mem_size
Dieses Feld enthält den gegenwärtigen Gesamtspeicher im System.
platform_type
Dieses Feld speichert den Plattformtyp, der aus einem Feld im HWRPB entnommen wurde.
platform_name
Dieses Feld enthält einen ganzzahligen Offset von der Basis des Baum-Stammknotens zu einer Zeichenfolge, die den Namen der Plattform darstellt.
primary_instance
Dieses Feld speichert die Partitions-ID der ersten Betriebssystem-Instanz.
first_free
Dieses Feld enthält den Offset von dem Baum-Stammknoten zu dem ersten freien Byte des Speicher-Pools, das für neue Knoten verwendet wird.
high_limit
Dieses Feld enthält die höchste Adresse, auf der ein gültiger Knoten in dem Konfigurationsbaum angeordnet werden kann. Es wird für Rückfragen verwendet, um zu validieren, dass eine Kennung gültig ist.
lookaside
Dieses Feld ist die Kennung einer verknüpften Liste von Knoten, die gelöscht worden sind und die zurückgefordert werden können. Wenn eine Community oder Partition gelöscht werden, wird der Knoten in diese Liste verknüpft, und bei der Erstellung einer neuen Partition oder Community wird diese Liste durchsucht, bevor aus freiem Speicher-Pool reserviert wird.
available
Dieses Feld enthält die Anzahl von in dem freien Speicher-Pool übrigen Bytes, auf die durch das Feld first_free verwiesen wird.
max_partitions
Dieses Feld enthält die maximale Anzahl von Partitionen, die durch die Plattform basierend auf der Menge gegenwärtig verfügbarer Hardware-Ressourcen berechnet worden sind.
partitions
Dieses Feld enthält einen Offset von der Basis des Stammknotens zu einem Array von Kennungen. Jede Partitions-ID wird als ein Indexverweis in dieses Array verwendet, und die Partitionsknotenkennung wird an der indexierten Speicherstelle gespeichert. Wenn eine neue Partition erstellt wird, wird dieses Array geprüft, um die erste Partitions-ID zu finden, die keine entsprechende Partitionsknotenkennung besitzt, und diese Partitions-ID wird als die ID für die neue Partition verwendet.
communities
Dieses Feld enthält ebenfalls einen Offset von der Basis des Stammknotens zu einem Array von Kennungen. Jede Community-ID wird als ein Indexverweis in dieses Array verwendet, und eine Community-Knotenkennung wird in dem Array gespeichert. Wenn eine neue Community erstellt wird, wird dieses Array geprüft, um die erste Community-ID zu finden, die keine entsprechende Community-Knotenkennung besitzt, und diese Community-ID wird als die ID für die neue Community verwendet. Es kann nicht mehr Communities als Partitionen geben, so dass die Array-Größe basierend auf der maximalen Anzahl von Partitionen bemessen wird.
max_platform_partition
Dieses Feld enthält die maximale Anzahl von Partitionen, die gleichzeitig auf der Plattform vorhanden sein können, selbst wenn zusätzliche Hardware hinzugefügt wird (potenziell inswapped).
max_fragments
Dieses Feld enthält eine plattformdefinierte maximale Anzahl von Fragmenten, in die ein Speicher-Deskriptor unterteilt werden kann. Es wird verwendet zur Bemessung der Größe des Arrays von Fragmenten in dem Speicher-Deskriptor-Knoten verwendet.
max_desc
Dieses Feld enthält die maximale Anzahl von Speicher-Deskriptoren für die Plattform.
APMP_id
Dieses Feld enthält eine System-ID, die durch die System-Software eingerichtet und in einem nichtflüchtigen RAM gespeichert wird.
APMP_id_pad
Dieses Feld enthält Auffüll-Bytes für die APMP-ID.
bindings
Dieses Feld enthält einen Offset zu einem Array von "Bindungen". Jeder Bindungseintrag beschreibt einen Typ von Hardware-Knoten, den Knotentyp, welcher der Parent-Knoten sein muss, die Konfigurationsbindung und die Affinitätsbindung für einen Knotentyp. Bindungen werden von der Software verwendet, um zu bestimmen, welche Knotentypen in Beziehung stehen, und Konfigurations- und Affinitätsregeln.
Eine Community stellt die Basis für die gemeinsame Nutzung von Ressourcen unter Partitionen bereit.
Während eine Hardware-Komponente jeder Partition in einer Community zugewiesen werden kann, erfolgt die tatsächliche gemeinsame Nutzung einer Einrichtung, wie beispielsweise des Speichers, nur innerhalb einer Community. Der Community-Knoten 310 enthält einen Adressenverweis zu einem Steuerabschnitt, der als eine APMP-Datenbank bezeichnet wird, der es den Betriebssystem-Instanzen gestattet, den Zugriff und die Mitgliedschaft in der Community zum Zweck der gemeinsamen Nutzung des Speichers und von Kommunikationen zwischen den Instanzen zu steuern. Die APMP-Datenbank und die Erstellung von Communities werden im Folgenden ausführlich erläutert. Die Konfigurations-ID für die Community ist ein ganzzahliger 16-Bit-Wert mit Vorzeichen, der durch das Konsolenprogramm zugewiesen wird. Der ID-Wert ist niemals größer als die maximale Anzahl von Partitionen, die auf der Plattform erstellt werden können.
Ein Partitionsknoten, wie beispielsweise der Knoten 312 oder 314, stellt eine Sammlung von Hardware dar, die in der Lage ist, eine unabhängige Kopie des Konsolenprogramms und eine unabhängige Kopie eines Betriebssystems auszuführen. Die Konfigurations-ID für diesen Knoten ist ein ganzzahliger 16-Bit-Wert mit Vorzeichen, der auf der Plattform erstellt werden kann. Der Knoten weist die folgende Definition auf:
Die definierten Felder haben die folgenden Definitionen:
hwrpb
Dieses Feld enthält die physikalische Adresse des Hardware-Neustart-Parameterblocks für diese Partition. Zum Minimieren von Änderungen an dem HWRPB enthält der HWRPB keinen Adressenverweis auf die Partition oder die Partitions-ID. Stattdessen enthalten die Partitionsknoten einen Adressenverweis auf den HWRPB. Die System-Software kann dann die Partitions-ID der Partition bestimmen, in der sie läuft, indem die Partitionsknoten nach der Partition durchsucht werden, welche die physikalische Adresse ihres HWRPB enthält.
incarnation
Dieses Feld enthält einen Wert, der jedes Mal inkrementiert wird, wenn die primäre CPU der Partition einen Boot- oder Neustart-Vorgang auf der Partition ausführt.
priority
Dieses Feld enthält eine Partitions-Priorität.
os_type
Dieses Feld enthält einen Wert, der den Typ des Betriebssystems angibt, das in die Partition geladen wird.
partition_reserved_1
Dieses Feld ist für künftige Verwendung reserviert.
instance_name_format
Dieses Feld enthält einen Wert, der das Format der Instanznamen-Zeichenfolge beschreibt.
instance_name
Dieses Feld enthält eine formatierte Zeichenfolge, die unter Verwendung des Felds instance_name_format interpretiert wird. Der Wert in diesem Feld stellt einen Pfadnamen auf höchster Ebene für die Betriebssystem-Instanz bereit, welche in der Partition ausgeführt wird. Dieses Feld wird durch die System-Software geladen und wird nicht leistungszyklusübergreifend gespeichert. Dieses Feld wird beim Einschalten und Erstellen und Löschen von Partitionen gelöscht.
Ein System-Funktionsbaustein-Knoten, wie beispielsweise der Knoten 322 oder 324, stellt ein frei wählbares Hardware-Teil oder eine konzeptionelle Gruppierung dar, die von System-Plattformen mit modularen Auslegungen verwendet werden, wie derjenigen, die in 2 dargestellt ist. Ein QBB (Quad-Funktionsbaustein) ist ein spezifisches Beispiel eines SBB und entspricht Einheiten, wie beispielsweise den Einheiten 100, 102, 104 und 106 in 1. Children der SBB-Knoten 322 und 324 umfassen die Eingabe/Ausgabe-Prozessorknoten 326 und 340.
Von CPU-Knoten, wie beispielsweise den Knoten 328–332 und 342–346, wird angenommen, dass sie als eine primäre CPU für den SMP-Betrieb arbeiten können. In dem seltenen Fall, in dem eine CPU nicht primärfähig ist, besitzt sie einen SUBTYPE-Code, der angibt, dass sie nicht als eine primäre CPU im SMP-Betrieb verwendet werden kann. Diese Information ist entscheidend, wenn Ressourcen zum Erstellen einer neuen Partition konfiguriert werden. Der CPU-Knoten enthält auch Informationen darüber, wo die CPU gegenwärtig ausgeführt wird. Für die Primär-CPU für eine Partition ist das Flag NODE_CPU_PRIMARY in dem Feld NODE_FLAGS gesetzt. Der CPU-Knoten weist die folgende Definition auf:
Ein Speicher-Subsystemknoten, wie beispielsweise der Knoten 334 oder 348, ist ein "Pseudo"-Knoten, der Knoten zusammengruppiert, welche die physikalischen Speicher-Controller und die Zuweisungen des Speichers darstellen, die von den Controllern bereitgestellt werden. Die Children dieses Knotens bestehen aus einem oder mehreren Speicher-Controller-Knoten, (wie beispielsweise den Knoten 336 und 350), welche die Konsole so konfiguriert hat, das sie (verschachtelt) zusammenarbeiten, und einem oder mehreren Speicher-Deskriptor-Knoten, (wie beispielsweise den Knoten 338 und 352), die physikalisch zusammenhängende Speicherbereiche beschreiben.
Ein Speicher-Controller-Knoten, (wie beispielsweise die Knoten 336 oder 350), wird verwendet, um eine physikalische Hardware-Komponente auszudrücken, und sie sind typischerweise zu der Partition zugehörig, die Fehler und die Initialisierung bearbeitet. Speicher-Controller können nicht zu Communities zugewiesen werden, da sie eine spezifische Betriebssystem-Instanz für Initialisierung, Prüfung und Fehler benötigen. Eine Speicherbeschreibung, die durch einen Speicher-Deskriptor-Knoten definiert wird, kann jedoch in "Fragmente" aufgeteilt werden, um es verschiedenen Partitionen oder Communities zu ermöglichen, dass spezifische Speicherbereiche in dem Speicher-Deskriptor zu ihnen zugehörig sind. Der Speicher unterscheidet sich dadurch von anderen Hardware-Ressourcen, dass er gleichzeitig gemeinsam genutzt oder in "private" Bereiche aufgeteilt werden kann. Jeder Speicher-Deskriptor-Knoten enthält eine Liste von Untergruppen-Bereichen, die es gestatten, den Speicher unter den Partitionen aufzuteilen sowie gemeinsam von Partitionen, (die zu einer Community zugehörig sind), nutzen zu lassen. Ein Speicher-Deskriptor-Knoten, (wie beispielsweise die Knoten 338 oder 352), werden definiert als:
Die Struktur mem_info besitzt die folgende Definition:
Das Feld mem_frag enthält einen Offset von der Basis des Speicher-Deskriptor-Knotens zu einem Array der GCT_MEM_DESC-Strukturen, welche die folgende Definition haben:
Die Anzahl von Fragmenten in einem Speicher-Deskriptor-Knoten, (Knoten 338 oder 352), wird durch die Plattform-Firmware begrenzt. Dies erzeugt eine Obergrenze hinsichtlich der Speicherunterteilung und schränkt die unbegrenzte Erweiterung des Konfigurationsbaums ein. Die Software kann die maximale Anzahl von Fragmenten aus dem Feld max_fragments in dem Baum-Stammknoten 302 bestimmen (oben erläutert), oder durch Aufrufen einer entsprechenden Konsolen-Rückfragefunktion zum Zurückgeben des Werts. Jedes Fragment kann jeder Partition zugewiesen werden, vorausgesetzt, die config-Bindung und die Zugehörigkeit des Speicher-Deskriptors und des Speicher-Subsystems lassen dies zu. Jedes Fragment enthält ein Feld für grundlegende physikalische Adresse, Größe und Zugehörigkeit sowie Flags, die den Typ der Verwendung angeben.
Um den Zugriff zur gemeinsamen Speichernutzung zu gestatten, müssen der Speicher-Subsystem-Parent-Knoten und der Speicher-Deskriptor-Knoten zu einer Community zugehörig sein. Die Fragmente in dem Speicher-Deskriptor können zu der Community (gemeinsame Nutzung) oder zu jeder Partition in der Community zugehörig sein.
Fragmente können Mindest-Reservierungsgrößen und in dem Baum-Stammknoten 302 bereitgestellte Synchronisierungen (alignments) besitzen. Der grundlegende Speicher für eine Partition, (die Fragmente, in denen die Konsole und das Betriebssystem geladen werden), können eine größere Reservierung und Synchronisierung als andere Fragmente aufweisen, (siehe Definition des Baum-Stammknotens oben). Wenn das Feld Zugehörigkeit des Speicher-Deskriptor-Knotens eine Partition ist, dann können die Fragmente nur zu dieser Partition zugehörig sein.
4 veranschaulicht den Konfigurationsbaum, der in 3 gezeigt ist, wenn er von der Zugehörigkeits-Perspektive aus betrachtet wird. Das Konsolenprogramm für eine Partition überlässt Zugehörigkeit und Steuerung der Partitions-Ressourcen der Betriebssystem-Instanz, die in dieser Partition läuft, wenn die primäre CPU für diese Partition mit der Ausführung beginnt. Das "Zugehörigkeits"-Konzept bestimmt, wie die Hardware-Ressourcen und CPUs zu Software-Partitionen und Communities zugewiesen werden. Der Konfigurationsbaum weist Zugehörigkeits-Adressenverweise auf, die in 3 dargestellt sind, welche die Abbildung von Hardware-Einrichtungen auf die Software bestimmen, wie beispielsweise Partitionen (ausschließlich Zugriff) und Communities (gemeinsamer Zugriff). Eine Betriebssystem-Instanz verwendet die Informationen in dem Konfigurationsbaum, um zu bestimmen, über welche Hardware-Ressourcen sie Zugriffs- und Neukonfigurations-Kontrolle besitzt.
Passive Hardware-Ressourcen, die keine Zugehörigkeit aufweisen, stehen für den Einsatz erst zur Verfügung, wenn die Zugehörigkeit eingerichtet worden ist. Sobald die Zugehörigkeit durch Verändern des Konfigurationsbaums eingerichtet worden ist, können die Betriebssystem-Instanzen beginnen, die Ressourcen zu verwenden. Wenn eine Instanz eine Anfangsanforderung stellt, kann die Zugehörigkeit geändert werden, indem das Betriebssystem mit der Zugehörigkeit veranlasst wird, die Verwendung einer Ressource zu stoppen, oder indem ein Konsolenprogramm Maßnahmen ergreift, um die Verwendung einer Ressource in einer Partition zu stoppen, in der keine Betriebssystem-Instanz ausgeführt wird. Der Konfigurationsbaum wird dann geändert, um die Zugehörigkeit der Ressource auf eine andere Betriebssystem-Instanz zu übertragen. Der erforderliche Vorgang, um ein Betriebssystem zu veranlassen, die Verwendung einer Hardware-Ressource zu stoppen, ist betriebssystemspezifisch und kann einen Neustart der Betriebssystem-Instanzen erfordern, die von der Änderung betroffen sind.
Zum Verwalten des Übergangs einer Ressource von einem zugehörigen und aktiven Zustand in einen nicht zugehörigen und inaktiven Zustand sind in jedem Knoten des Baums zwei Felder vorgesehen. Das Feld owner stellt die Zugehörigkeit einer Ressource dar und wird mit der Kennung Software-Partition oder Community mit der Zugehörigkeit geladen. Beim Hochfahren eines APMP-Systems werden die Felder owner der Hardware-Knoten aus den Inhalten des nicht-flüchtigen RAM geladen, um eine Anfangskonfiguration einzurichten.
Zum Ändern der Zugehörigkeit einer Ressource wird der Kennungswert in dem Feld owner der Hardware-Komponente und in den Feldern owner von irgendwelchen Abkömmlingen der Hardware-Komponente modifiziert, die durch ihre config-Kennungen an die Komponente gebunden sind. Das Feld current_owner stellt den gegenwärtigen Benutzer der Ressource dar. Wenn die Felder owner und current_owner den gleichen Nicht-Null-Wert enthalten, ist die Ressource zugehörig und ist aktiv. Nur über die Zugehörigkeit einer Ressource kann die Zuweisung der Ressource aufgehoben werden, (das Feld owner auf Null setzen). Eine Ressource, deren Felder owner und current_owner Null sind, befindet ist nicht zugehörig und ist inaktiv. Nur Ressourcen, deren Felder owner und current_owner Null sind, können einer neuen Partition oder Community zugewiesen werden.
Wenn die Zuweisung einer Ressource aufgehoben wird, kann über die Zugehörigkeit entschieden werden, die Zuweisung des Felds owner oder beider Felder, owner und current_owner, aufzuheben. Die Entscheidung basiert auf der Fähigkeit der besitzenden Betriebssystem-Instanz, die in der Partition läuft, die Verwendung der Ressource vor der Aufhebung der Zugehörigkeits-Zuweisung zu unterbrechen. In dem Fall, indem ein Neustart erforderlich ist, um die Zugehörigkeit aufzugeben, wird das Feld owner gelöscht, doch das Feld current_owner bleibt unverändert. Wenn die besitzende Betriebssystem-Instanz neu startet, kann das Konsolenprogramm alle Felder current_owner für Ressourcen löschen, die während der Initialisierung keine Zugehörigkeit aufgewiesen haben.
Während der Initialisierung modifiziert das Konsolenprogramm das Feld current_owner, um das Feld owner für jeden Knoten abzugleichen, der zu ihm zugehörig ist und für den das Feld current_owner Null ist. Die System-Software sollte nur Hardware verwenden, die gegenwärtig zu ihr zugehörig ist. Im Fall einer Zuweisungsaufhebung einer Ressource, die zu einer Community zugehörig ist, liegt es in der Zuständigkeit der System-Software, den Übergang zwischen den Zuständen zu verwalten. In einigen Ausführungsformen kann eine Ressource an eine andere Partition ausgeliehen werden. In diesem Fall sind die Felder owner und current_owner beide gültig, aber nicht gleich. Die folgende Tabelle fasst die mögli chen Ressourcen-Zustände und die Werte der Felder owner und current_owner zusammen:
TABELLE 1
Da CPUs aktive Einrichtungen sind und die gemeinsame Nutzung von CPUs bedeutet, dass eine CPU im Kontext einer Partition ausgeführt werden könnte, zu der sie eventuell nicht "zugehörig" ist, unterscheidet sich die Zugehörigkeit einer CPU von der Zugehörigkeit einer passiven Ressource. Der CPU-Knoten in dem Konfigurationsbaum stellt zwei Felder bereit, die angeben, zu welcher Partition eine CPU nominell zugehörig ist, und in welcher Partition die CPU gegenwärtig ausgeführt wird. Das Feld owner enthält einen Wert, der die nominelle Zugehörigkeit der CPU bzw. insbesondere der Partition angibt, in der die CPU beim Hochfahren des Systems ausgeführt wird.
Bis ein anfängliche Zugehörigkeit eingerichtet ist, (das heißt, wenn das Feld owner nicht zugewiesen ist), werden die CPUs in einen HWRPB-Kontext gestellt, der von der Master-Konsole entschieden wurde, doch wird das HWRPB-Bit available für die CPU noch in keinem HWRPB gesetzt. Diese Kombination verhindert, dass die CPU an irgendeiner Betriebssystem-Instanz im SMP-Betrieb teilnimmt. Wenn die Zugehörigkeit einer CPU eingerichtet ist, (das Feld owner ist mit einer gültigen Partitionskennung gefüllt), migriert die CPU, falls erforderlich, zu der zugehörigen Partition, setzt das Bit available in dem HWRPB, der mit dieser Partition verbunden ist, und fordert die Teilnahme an dem SMP-Betrieb der Instanz an, die in dieser Partition läuft, oder nimmt an dem Konsolenprogramm im SMP-Modus teil. Die Kombination der Bits present und available in dem HWRPB melden der Betriebssystem-Instanz, dass die CPU für den Einsatz im SMP-Betrieb zur Verfügung steht, und dass die Betriebssystem-Instanz diese Bits zum Aufbauen entsprechender Datenstrukturen pro CPU und zum Senden einer Nachricht an die CPU verwenden kann, um sie aufzufordern, an dem SMP-Betrieb teilzunehmen.
Wenn eine CPU das Bit available in einem HWRPB setzt, trägt sie auch einen Wert in das Feld current_owner ihres entsprechenden CPU-Knotens in dem Konfigurationsbaum ein. Das Feld current_owner ist die Kennung der Partition, in der die CPU das HWRPB-Bit active gesetzt hat und an dem SMP-Betrieb teilnehmen kann. Das Feld current_owner für eine CPU wird nur durch das Konsolenprogramm gesetzt. Wenn eine CPU von einer Partition zu einer anderen Partition migriert oder in einem nicht-zugewiesenen Zustand angehalten wird, wird das Feld current_owner gelöscht, (oder in den Kennungswert der neuen Partition geändert), zum gleichen Zeitpunkt, zu dem das Bit available in dem HWRPB gelöscht wird. In das Feld current_owner sollten keine direkten Einträge durch die System-Software vorgenommen werden, und es gibt nur wieder, welcher HWRPB das Bit available für die CPU gesetzt hat.
Während der Laufzeit kann eine Betriebssystem-Instanz eine CPU temporär an eine andere Partition "ausleihen", ohne die nominelle Zugehörigkeit der CPU zu ändern. Das herkömmliche Zugehörigkeitskonzept unter Verwendung der HWRPB-Bits present und available wird verwendet, um den gegenwärtigen Ausführungskontext der CPU durch Modifizieren des HWRPB und des Konfigurationsbaums in unterbrechungsfreien Operationen wiederzugeben. Das Feld current_owner kann des Weiteren durch die System-Software in einer der Partitionen verwendet werden, um zu bestimmen, in welcher Partition die CPU gegenwärtig ausgeführt wird, (andere Instanzen können die Speicherstelle einer bestimmten CPU bestimmen, indem der Konfigurationsbaum geprüft wird).
Es ist auch möglich, die Zuweisung einer CPU aufzuheben und in einen Zustand zurückzusetzen, in dem das Bit available in keinem HWRPB gesetzt ist, und das Feld current_owner in dem Konfigurationsbaum-Knoten für die CPU wird gelöscht. Dies wird erreicht, indem die Ausführung der CPU angehalten und das Konsolenprogramm veranlasst wird, das Feld owner in dem Konfigurationsbaum-Knoten sowie das Feld current_owner und das HWRPB-Bit available zu löschen. Die CPU wird dann im Konsololenmodus ausgeführt und fragt das Feld owner ab, das darauf wartet, dass eine gültige Partitionskennung eingetragen wird. Die System-Software kann dann eine neue Zugehörigkeit einrichten und die CPU die Ausführung in der neuen Partition beginnen.
Veranschaulichende Zugehörigkeits-Adressenverweise werden in 4 durch Pfeile dargestellt. Jedem der Knoten in 4, der einem ähnlichen Knoten in 3 entspricht, wird eine entsprechende Nummer zugeteilt. Zum Beispiel wird der Software-Stammknoten, der in 3 als Knoten 306 bezeichnet wird, in 4 als Knoten 406 bezeichnet. Wie in 4 gezeigt, ist die Community 410 zur "Zugehörigkeit" des Software-Stammknotens 406 zugehörig. In ähnlicher Weise sind die System-Funktionsbausteine 1 und 2 (422 und 425) zur Zugehörigkeit der Community 410 zugehörig. In ähnlicher Weise sind die Partitionen 412 und 414 ebenfalls zur Zugehörigkeit der Community 410 zugehörig.
Zur Partition 412 sind die CPUs 428–432 und der I/O-Prozessor 426 zugehörig. Der Speicher-Controller 436 ist ebenfalls ein Teil der Partition 1 (412). In ähnlicher Weise sind zur Partition 2 (414) die CPUs 442–446, der I/O-Prozessor 440 und der Speicher-Controller 450 zugehörig.
Der gemeinsame oder gemeinsam genutzte Speicher in dem System besteht aus den Speicher-Subsystemen 434 und 448 und den Speicher-Deskriptoren 438 und 452. Diese sind zu der Community 410 zugehörig. Daher beschreibt 4 den Aufbau des Systems, wie er sich den Betriebssystem-Instanzen darstellen würde.
Betriebssystem-Charaktenstiken
Wie vorher erwähnt, kann das veranschaulichende Computersystem mit mehreren verschiedenen Betriebssystemen in verschiedenen Partitionen arbeiten. Herkömmliche Betriebssysteme müssen jedoch unter Umständen in einigen Gesichtspunkten modifiziert werden, um sie mit dem erfinderischen System kompatibel zu machen, je nachdem, wie das System konfiguriert ist. Einige Beispiel-Modifizierungen für die veranschaulichende Ausführungsform sind im Folgenden aufgelistet:

1. Instanzen müssen unter Umständen modifiziert werden, um einen Mechanismus zum Auswählen einer "primären" CPU in der Partition zu enthalten, um die Konsole zu betreiben und ein Ziel für die Kommunikation von anderen Instanzen zu sein. Die Auswahl einer primären CPU kann in einer herkömmlichen Weise unter Verwendung von Entscheidungsmechanismen oder anderen herkömmlichen Einrichtungen erfolgen.
2. Für jede Instanz können Modifizierungen erforderlich sein, die es ihr gestatten, mit dem Konsolenprogramm zu kommunizieren und zusammenzuwirken, das für die Erstellung eines Konfigurations-Datenblocks zuständig ist, der die Ressourcen beschreibt, die der Partition zur Verfügung stehen, in welcher die Partition läuft. Zum Beispiel sollte die Instanz nicht die darunter liegende Hardware prüfen, um zu bestimmen, welche Ressourcen zur Verwendung durch die Instanz verfügbar sind. Stattdessen muss sie, wenn ihr ein Konfigurations-Datenblock übergeben wird, der beschreibt, auf welche Ressourcen diese Instanz zugreifen darf, mit dem angegebenen Ressourcen arbeiten.
3. Eine Instanz muss in der Lage sein können, an einer frei wählbaren physikalischen Adresse zu beginnen und kann unter Umständen nicht in der Lage sein, irgendeine spezifische physikalische Adresse zu reservieren, um eine Konfliktbildung mit anderen Betriebssystemen zu vermeiden, die auf dieser bestimmten Adresse laufen.
4. Eine Instanz muss in der Lage sein können, mehrere frei wählbare physikalische Löcher in ihrem Adressraum zu unterstützen, wenn sie Teil einer System-Konfiguration ist, in dem Speicher zwischen Partitionen gemeinsam genutzt wird. Des Weiteren muss eine Instanz physikalische Löcher in ihrem Adressraum bearbeiten können, um "hot inswap" von Speicher zu unterstützen.
5. Eine Instanz muss Nachrichten übergeben und Benachrichtigungen empfangen können, dass neue Ressourcen für Partitionen und Instanzen zur Verfügung stehen. Insbesondere wird ein Protokoll benötigt, um eine Instanz zu informieren, nach einer neuen Ressource zu suchen. Andernfalls erkennt die Instanz möglicherweise nie, dass die Ressource vorhanden und einsatzfähig ist.
6. Eine Instanz muss in der Lage sein können, völlig in ihrem "privaten Speicher" zu laufen, wenn sie in einem System verwendet wird, in dem Instanzen den Speicher nicht gemeinsam nutzen. Alternativ muss eine Instanz in der Lage sein können, physikalischen "gemeinsam genutzten Speicher" für die Kommunikation oder gemeinsame Nutzung von Daten mit anderen Instanzen zu verwenden, die in dem Computer laufen, wenn die Instanz Teil eines Systems ist, in dem Speicher gemeinsam genutzt wird. In einem solchen System mit gemeinsam genutzten Speicher muss eine Instanz in der Lage sein können, physikalischen "gemeinsam genutzten Speicher" wie im Konfigurationsbaum identifiziert in einen virtuellen Adressraum und die virtuellen Adressräume der "Prozesse" abzubilden, die in dieser Betriebssystem-Instanz laufen.
7. Jede Instanz benötigt unter Umständen einen Mechanismus zum Kontaktieren einer anderen CPU in dem Computersystem, um mit ihr zu kommunizieren.
8. Eine Instanz muss ebenfalls in der Lage sein können, andere CPUs zu erkennen, die mit ihren Operationen kompatibel sind, selbst wenn die CPUs ihrer Partition gegenwärtig nicht zugewiesen sind. Zum Beispiel muss die Instanz in der Lage sein können, CPU-Parameter zu ermitteln, wie beispielsweise die Konsolenversionsnummer und Taktgeschwindigkeit, um zu bestimmen, ob sie mit dieser CPU laufen könnte, wenn die CPU der Partition, in dem die Instanz läuft, neu zugewiesen würde.

Den Konfigurationsbaum ändern
Jedes Konsolenprogramm stellt eine Anzahl von Rückfragefunktionen bereit, um es der dazugehörigen Betriebssystem-Instanz zu gestatten, die Konfiguration des APMP-Systems zu ändern, zum Beispiel durch Erstellen einer neuen Community oder Partition oder durch Ändern der Zugehörigkeit von Speicherfragmenten. Des Weiteren stellen andere Rückfragefunktionen die Möglichkeit bereit, eine Community oder Partition zu löschen oder den Betrieb einer neu erstellten Partition zu starten.
Allerdings veranlassen Rückfragefunktionen nicht, dass auf den laufenden Betriebssystem-Instanzen Änderungen stattfinden. Auf alle an dem Konfigurationsbaum vorgenommenen Änderungen muss von jeder von der Änderung betroffenen Instanz eingewirkt werden. Die Vorgangsart, die in einer Instanz stattfinden muss, wenn der Konfigurationsbaum geändert wird, ist eine Funktion der Art von Änderung und der Fähigkeiten der Betriebssystem-Instanz. Zum Beispiel kann das Verschieben eines Eingabe/Ausgabe-Prozessors von einer Partition in eine andere erfordern, dass beide Partitionen neu gestartet werden. Die Änderung der Speicherreservierung von Fragmenten könnte andererseits durch eine Betriebssystern-Instanz bearbeitet werden, ohne dass ein Neustart erforderlich ist.
Die Konfiguration eines APMP-Systems bedingt die Erstellung von Communities und Partitionen sowie die Zuweisung von nicht-zugewiesenen Komponenten. Wenn eine Komponente von einer Partition in eine andere verschoben wird, entfernt sich die gegenwärtige Zugehörigkeit selbst als zu der Ressource zugehörig und gibt dann die neue Zughörigkeit der Ressource an. Die neue Zugehörigkeit kann die Ressource dann verwenden. Wenn eine in einer Partition laufende Instanz eine Komponente freigibt, darf die Instanz nicht mehr auf die Komponente zugreifen. Diese einfache Prozedur lässt die komplexe Synchronisierung entfallen, die erforderlich ist, um ein blindes Entwenden (blind stealing) einer Komponente von einer Instanz und mögliche Wettlaufsituationen beim Booten einer Instanz während einer Neukonfiguration zu gestatten.
Sobald sie initialisiert sind, werden Konfigurationsbaum-Knoten nie gelöscht oder verschoben, das heißt, ihre Kennungen sind immer gültig. Daher können Hardware-Knotenadressen durch die Software im Cache gespeichert werden. Rückfragefunktionen, die vorgeben, eine Partition oder eine Community zu löschen, löschen den dazugehörigen Knoten nicht wirklich oder entfernen ihn aus dem Baum, sondern kennzeichnen den Knoten als UNAVAILABLE und löschen die Zugehörigkeits-Felder jeder Hardware-Ressource, die zu der Zugehörigkeit der Software-Komponente zugehörig gewesen sind.
Um Änderungen an dem Konfigurationsbaum zu synchronisieren, führt der Stammknoten des Baums zwei Zähler (transient_level und current_level). Der Zähler transient_level wird zu Beginn einer Aktualisierung des Baums inkrementiert, und der Zähler current_level wird inkrementiert, wenn die Aktualisierug abgeschlossen ist. Die Software kann diese Zähler verwenden, um zu bestimmen, wann eine Änderung an dem Baum eingetreten ist oder gerade eintritt. Wenn eine Aktualisierung durch eine Konsole abgeschlossen wird, kann ein Interrupt für alle CPUs in dem APMP-System generiert werden. Dieser Interrupt kann dazu verwendet werden, die System-Software zu veranlassen, ihren Zustand basierend auf den Änderungen an dem Baum zu aktualisieren.
Erstellung eines APMP-Computersystems
5 ist ein Ablaufdiagramm, das eine Übersicht des Aufbaus des veranschaulichenden adaptiv partitionierten Mehrprozessor- (AMPM) Computersystems darstellt. Die Routine beginnt in Schritt 500 und fährt mit Schritt 502 fort, in dem ein Master-Konsolenprogramm gestartet wird. Wenn das APMP-Computersystem beim Hochfahren erstellt wird, wird die CPU, auf der die Master-Konsole läuft, durch einen vorgegebenen Mechanismus, wie beispielsweise Entscheidung, oder einen anderen Hardware-Mechanismus ausgewählt. Wenn das APMP-Computersystem auf Hardware erstellt wird, die bereits läuft, führt eine CPU in der ersten Partition, die versucht, an den (nicht-vorhandenen) Systemen teilzunehmen, das Master-Konsolenprogramm aus, wie im Folgenden erläutert wird.
Als Nächstes prüft das Master-Konsolenprogramm in Schritt 504 die Hardware und erstellt den Konfigurationsbaum in Schritt 506, wie oben erläutert wurde. Wenn mehr als eine Partition in dem APMP-System beim Hochfahren vorhanden ist, wird jede Partition initialisiert und ihr Konsolenprogramm gestartet (Schritt 508).
Schließlich wird eine Betriebssystem-Instanz in wenigstens einer der Partitionen gebootet, wie in Schritt 510 angegeben. Die erste zu bootende Betriebssystem-Instanz erstellt eine APMP-Datenbank und füllt die Einträge wie im Folgenden beschrieben aus. APMP-Datenbanken speichern Informationen, die sich auf den Zustand von aktiven Betriebssystem-Instanzen in dem System beziehen. Es ist zu anzumerken, dass die Teilnahme einer Instanz in einem APMP-System nicht erforderlich ist. Die Instanz kann zu einem Zeitpunkt, der lange nach dem Booten liegt, wählen, ob sie nicht teilnimmt oder teilnimmt. Diejenigen Instanzen, die teilnehmen, bilden ein "Mitbenutzungs-Set". Die erste Instanz, die entscheidet, an einem Mitbenutzungs-Set teilzunehmen, muss es erstellen. Es können mehrere Mitbenutzungs-Sets vorhanden sein, die auf einem einzelnen APMP-System arbeiten, und jedes Mitbenutzungs-Set besitzt seine eigene APMP-Datenbank.
Entscheidung zum Erstellen eines neuen APMP-Systems oder zur Teilnahme an einem vorhandenen APMP-System
Eine Betriebssystem-Instanz, die auf einer Plattform läuft, auf der auch das APMP-Computersystem läuft, muss nicht notwendigerweise ein Mitglied des APMP-Computersystems sein. Die Instanz kann zu jeder Zeit nach dem Booten versuchen, ein Mitglied des APMP-Systems zu werden. Dies kann entweder automatisch nach einem Booten erfolgen oder nachdem ein Benutzerbefehl die Teilnahme explizit initiiert. Nachdem das Betriebssystem zum Boot-Zeitpunkt geladen worden ist, wird die Betriebssystem-Initialisierungsroutine aufgerufen und prüft einen gespeicherten Parameter, um festzustellen, ob er eine unmittelbare Teilnahme angibt, und falls dies der Fall ist, führt das System eine Teilnahmeroutine aus, die Teil des APMP-Computersystems ist. Ein Benutzerbefehl würde zu einer Ausführung der gleichen Routine führen.
APMP-Datenbank
Eine wichtige Datenstruktur, welche die erfinderische Software-Reservierung von Ressourcen unterstützt, ist die APMP-Datenbank, die Betriebssystem-Instanzen verfolgt, die Mitglieder eines Mitbenutzungs-Sets sind. Die erste Betriebssystem-Instanz, die versucht, das APMP-Computersystem einzurichten, initialisiert eine APMP-Datenbank, wodurch die erfinderischen Software-Ressourcenreservierungen für das anfängliche Mitbenutzungs-Set erstellt oder instantiiert werden. Spätere Instanzen, die Teil des Mitbenutzungs-Sets werden wollen, nehmen durch Registrierung in der APMP-Datenbank teil, die mit diesem Mitbenutzungs-Set verknüpft ist. Die APMP-Datenbank ist eine gemeinsam genutzte Datenstruktur, welche die zentralisierten Informationen enthält, die für die Verwaltung von gemeinsam genutzten Ressourcen des Mitbenutzungs-Sets erforderlich sind. Eine APMP-Datenbank wird ebenfalls initialisiert, wenn das APMP-Computersystem in Reaktion auf einen nicht behebbaren Fehler neu aufgebaut wird.
Insbesondere ist jede APMP-Datenbank eine dreiteilige Struktur. Der erste Teil ist ein Header-Teil mit einer festen Größe, der grundlegende Synchronisierungsstrukturen für die Erstellung des APMP-Computersystems, Adressenabbildungs-Informationen für die Datenbank und Offsets zu den dienstspezifischen Segmenten enthält, die den zweiten Teil aus machen. Der zweite Teil ist ein Array von Datenblöcken, wobei jeder potenziellen Instanz ein Block zugewiesen wird. Die Datenblöcke werden als "Knotenblöcke" bezeichnet. Der dritte Teil ist in Segmente unterteilt, die von jedem der untergeordneten Betriebsmittel des Computersystems verwendet werden. Jedes untergeordnete Betriebsmittel ist für den Inhalt seines eigenen Segments und die Synchronisierung des Zugriffs darauf zuständig.
Der Header-Teil einer APMP-Datenbank ist der erste Teil der APMP-Datenbank, der von einer teilnehmenden Betriebssystem-Instanz abgebildet wird. Auf Teile des Headers wird zugegriffen, bevor eine Instanz an dem Mitbenutzungs-Set teilnimmt und eigentlich bevor die Instanz weiß, dass das APMP-Computersystem vorhanden ist.
Der Header-Abschnitt enthält:

1. ein Mitgliedschafts- und Erstellungssynchronierungs-Quad-Wort
2. eine Computersystem-Software-Version
3. Zustandsinformationen, Erstellungszeit, Inkamationszählung usw.
4. einen Adressenverweis (Offset) zu einer Mitgliedschafts-Maske
5. Absturz-Instanz, Absturz-Bestätigungs-Bits usw.
6. Validierungsmasken, einschließlich eines Bits für jeden Dienst
7. Speicherabbildungs-Informationen (Seiten-Frame-Nummer-Informationen) für die gesamte APMP-Datenbank
8. Offset/Länge-Paare, die jedes der Dienst-Segmente beschreiben (Längen in Bytes gerundet auf volle Seiten von Seiten und Offsets), einschließlich: gemeinsam genutzte Speicherdienste CPU-Kommunikationsdienste mitgliedschaftsdienste (falls erforderlich) Sperrdienste

Das Array von Knotenblöcken wird durch eine System-Partitions-ID, (pro Instanz ist auf der gegenwärtigen Plattform eine möglich), indexiert, und jeder Block enthält:
Instanz-Software-Version
Interruptgrund-Maske
Instanz-Zustand
Instanz-Inkarnation
Instanz-Heartbeat
Instanz-Mitgliedschafts-Zeitstempel
Little-Brother-Instanz-ID und Inaktiv-Zeit; Big-Brother-Instanz-ID
Bit Instanz-Validieruang ausgeführt.
Eine APMP-Datenbank wird im gemeinsam genutzten Speicher gespeichert. Der feste Anfangsteil von N physikalisch zusammenhängenden Seiten belegt die ersten N Seiten von einem oder zwei Speicherbereichen, die von der ersten teilnehmenden Instanz während des anfänglichen Partitionierens der Hardware reserviert werden. Die Instanz weist die Konsole an, die physikalischen Start-Adressen dieser Bereiche in dem Konfigurationsbaum zu speichern. Der Zweck der Reservierung von zwei Bereichen besteht darin, eine Ausfallsicherung im Fall eines Hardware-Speicherausfalls zu ermöglichen. Die Speicherverwaltung ist für die Abbildung des physikalischen Speichers in virtuellen Adressraum für die APMP-Datenbank zuständig.
Die einzelnen Maßnahmen, die von einer Betriebssystem-Instanz ergriffen werden, sind in 6 dargestellt. Insbesondere wenn eine Betriebssystem-Instanz ein Mitglied eines Mitbenutzungs-Sets werden möchte, muss sie vorbereitet sein, das APMP-Computersystem zu erstellen, wenn sie die erste Instanz ist, die versucht, an einem nicht-vorhandenen System "teilzunehmen". Damit die Instanz bestimmen kann, ob ein APMP-System bereits vorhanden ist, muss die Instanz in der Lage sein, den Zustand des gemeinsam genutzten Speichers wie oben beschrieben zu prüfen. Ferner muss sie in der Lage sein, sich mit anderen Instanzen zu synchronisieren, die unter Umständen versuchen, an dem APMP-System und dem Mitbenutzungs-Set zum gleichen Zeitpunkt teilzunehmen, um konfliktbildende Versuche zu verhindern. Die Master-Konsole erstellt den Konfigurationsbaum wie oben erläutert. Anschließend wird ein Speicherbereich von der ersten oder primären zu bootenden Betriebssystem-Instanz initialisiert, und dieser Speicherbereich kann für eine APMP-Datenbank verwendet werden.
Abbildung des APMP-Datenbank-Headers
Das Ziel der ersten Maßnahmen, die von allen Betriebssystem-Instanzen ergriffen werden, besteht dann, den Header-Teil der APMP-Datenbank abzubilden und eine primitive Inter-Instanz-Interrupt-Bearbeitung zu initialisieren, um die Grundlage für eine Erstellungs- oder Teilnahme-Entscheidung zu schaffen. Die verwendete Routine ist in 6 dargestellt und beginnt in Schritt 600. Die erste Maßnahme, die von jeder Instanz ergriffen wird, (Schritt 602), besteht darin, die Speicherverwaltung zu beauftragen, das Anfangssegment der APMP-Datenbank abzubilden, wie oben beschrieben. Zu diesem Zeitpunkt wird das Array von Knotenblöcken in dem zweiten Datenbank-Abschnitt ebenfalls abgebildet. Die Speicherverwaltung bildet die ersten und zweiten Segmente der APMP-Datenbank in den primären Betriebssystem-Adressraum ab und gibt die Startadresse und Länge zurück. Die Instanz informiert dann die Konsole, die Speicherstelle und Größe der Segmente in dem Konfigurationsbaum zu speichern.
Als Nächstes wird in Schritt 604 die erste virtuelle Adresse der APMP-Datenbank verwendet, um es der Initialisierungs-Routine zu gestatten, Interruptursachen-Masken in dem Knotenblock, welcher der gegenwärtigen Instanz zugewiesen ist, auf Null zu setzen.
Ein Null-Anfangswert wird dann in dem Heartbeat-Feld für die Instanz in dem Knotenblock und anderen Knotenblockfeldern gespeichert. In einigen Fällen war die Instanz, die versucht hat, ein neues APMP-Computersystem zu erstellen, vorher ein Mitglied eines APMP-Systems und hat sich aus dem APMP-System nicht zurückgezogen. Wenn diese Instanz neu gebootet wird, bevor die anderen Instanzen sie entfernt haben, bleiben ihre Bits immer noch in der System-Mitgliedschaftsmaske "eingeschaltet". Andere ungewöhnliche oder Fehler-Fälle können auch dazu führen, dass "Müll" in der System-Mitgliedschaftsmaske gespeichert wird.
Als Nächstes wird in Schritt 608 die virtuelle Adresse (VA) der APMP-Datenbank in einer privaten Zelle gespeichert, die durch einen Inter-Prozessor-Interrupt-Handler geprüft wird. Der Handler prüft diese Zelle, um zu ermitteln, ob die Interruptursachen-Maske pro Instanz in dem APMP-Datenbank-Header auf auszuführende Arbeit getestet werden soll. Wenn diese Zelle Null ist, ist die APMP-Datenbank nicht abgebildet, und es wird nichts weiter von dem Handler getan. Wie vorher erläutert, wird die gesamte APMP-Datenbank, einschließlich dieser Maske, so initialisiert, dass der Handler nichts tut, bevor die Adresse gespeichert ist. Des Weiteren kann ein Takt-Interrupt-Handler die gleiche private Zelle prüfen, um zu bestimmen, ob das instanzspezifische Heartbeat-Feld für diese Instanz in dem entsprechenden Knotenblock inkrementiert werden soll. Wenn die private Zelle Null ist, inkrementiert der Inerrupt-Handler das Heartbeat-Feld nicht.
An diesem Punkt ist die Routine beendet, (Schritt 610), und auf den APMP-Datenbank-Header kann zugegriffen werden, und die teilnehmende Instanz ist in der Lage, den Header zu prüfen und zu entscheiden, ob das APMP-Computersystem nicht vorhanden ist und die Instanz es daher erstellen muss, oder ob die Instanz an einem bereits vorhandenen APMP-System teilnimmt.
Sobald der APMP-Header abgebildet ist, wird der Header geprüft, um zu bestimmen, ob das APMP-Computersystem eingerichtet ist und funktioniert, und falls dies nicht der Fall ist, ob die gegenwärtige Instanz die APMP-Datenbank initialisieren und das APMP-Computersystem erstellen sollte. Das Problem einer Teilnahme an einem vorhandenen APMP-System wird zum Beispiel schwieriger, wenn das APMP-Computersystem zu einem bestimmten Zeitpunkt erstellt worden ist, aber keine Mitglieder hat, oder wenn das APMP-System nach einem Fehler neu aufgebaut wird. In diesem Fall ist der Zustand des APMP-Datenbankspeichers nicht im Voraus bekannt, und ein einfacher Speichertest ist nicht ausreichend. Eine Instanz, die versucht, an einem möglicherweise vorhandenen APMP-System teilzunehmen, muss in der Lage sein, bestimmen zu können, ob ein APMP-System vorhanden ist oder nicht, und falls dies nicht der Fall ist, muss die Instanz in der Lage sein, ein neues APMP-System ohne Beeinträchtigung durch andere Instanzen zu erstellen. Diese Beeinträchtigung könnte von Threads stammen, die entweder auf der gleichen Instanz oder einer anderen Instanz laufen.
Um eine solche Beeinträchtigung zu verhindern, wird die Erstellungs-/Teilnahme-Entscheidung getroffen, indem die APMP-Datenbank zuerst gesperrt und dann der APMP-Header geprüft wird, um zu bestimmen, ob ein funktionierendes APMP-Computersystem vorhanden ist. Wenn ein einwandfrei funktionierendes APMP-System vorhanden ist, nimmt die Instanz an dem System teil und hebt die Sperre auf der APMP-Datenbank auf. Wenn andererseits keine APMP-System vorhanden ist, oder wenn ein APMP-System vorhanden ist, das aber nicht funktioniert, dann erstellt die Instanz ein neues APMP-System mit sich selbst als Mitglied und hebt die Sperre auf der APMP-Datenbank auf.
Wenn es den Anschein hat, als befinde sich ein APMP-System im Übergang, dann wartet die Instanz, bis das APMP-System wieder betriebsfähig oder tot ist und geht dann wie oben beschrieben vor. Wenn ein System nicht erstellt werden kann, schlägt die Teilnahme fehl.
Ein neues APMP-Computersystem erstellen
Angenommen, ein neues APMP-System muss erstellt werden, dann ist die Ersteller-Instanz für die Reservierung des Rests der APMP-Datenbank, die Initialisierung des Headers und den Aufruf von Systemdiensten zuständig. Angenommen, die APMP-Datenbank ist gesperrt, wie oben beschreiben, dann werden die folgenden Schritte von der Ersteller-Instanz unternommen, um das APMP-System zu initialisieren (diese Schritte sind in den 7A und 7B gezeigt):
Schritt 702 Die Ersteller-Instanz setzt den Zustand des APMP-Systems und seinen Knotenblock-Zustand auf "Initialisieren".
Schritt 704 Die Ersteller-Instanz ruft eine Größenroutine für jeden Systemdienst mit der Adresse seines Längenfelds im Header auf.
Schritt 706 Die sich daraus ergebenden Längenfelder werden summiert, und die Ersteller-Instanz ruft die Speicherverwaltung auf, um Raum für die gesamte APMP-Datenbank zuzuweisen, indem eine neue Abbildung erstellt und die alte Abbildung gelöscht wird.
Schritt 708 Die Ersteller-Instanz füllt die Offsets zu den Anfängen jedes Systemdienst-Segments auf.
Schritt 710 Die Initialisierungs-Routine für jeden Dienst wird mit den virtuellen Adressen der APMP-Datenbank, des Dienst-Segments und der Segmentlänge aufgerufen.
Schritt 712 Die Ersteller-Instanz initialisiert eine Mitgliedschafts-Maske, um sich selbst zum einzigen Mitglied zu machen und inkrementiert eine Inkamationszählung. Dann richtet sie die Erstellungszeit, Software-Version und andere Erstellungsparameter ein.
Schritt 714 Die Instanz setzt sich dann selbst als ihr eigener Big Brother und Little Brother (zu Heartbeat-Überwachungszwecken, wie im Folgenden beschrieben) ein.
Schritt 716 Dann trägt die Instanz ihren Instanz-Zustand als "Mitglied" und den Zustand des APMP-Systems als "betriebsfähig" ein.
Schritt 718 Schließlich hebt die Instanz die APMP-Datenbanksperre auf.
Die Routine endet mit Schritt 720.
Teilnahme an einem bestehenden APMP-Computersystem
Angenommen, die APMP-Datenbank ist für die Instanz gesperrt, dann werden von der Instanz die folgenden (in den 8A und 8B gezeigten) Schritte unternommen, um ein Mitglied eines bestehenden APMP-System zu werden:
Schritt 802 Die Instanz prüft, um sicherzustellen, dass ihr Instanz-Name eindeutig ist. Wenn ein anderes gegenwärtiges Mitglied den vorgeschlagenen Namen der Instanz besitzt, wird die Teilnahme abgebrochen.
Schritt 804 Die Instanz setzt den Zustand des APMP-Systems und seinen Knotenblock-Zustand auf "Instanz-Teilnahme".
Schritt 806 Die Instanz ruft eine Speicherverwaltungs-Routine auf, um den variablen Teil der APMP-Datenbank in ihren lokalen Adressraum abzubilden.
Schritt 808 Die Instanz ruft Systemteilnahme-Routinen für jeden Systemdienst mit den virtuellen Adressen der APMP-Datenbank und seinem Segment und seiner Segmentlänge auf.
Schritt 810 Wenn alle Systemdienst-Teilnahmeroutinen Erfolg melden, wird die Instanzteilnahme-Routine fortgesetzt. Wenn irgendeine Systemdienst-Teilnahmeroutine fehlschlägt, muss der Instanz-Teilnahmeprozess nochmals von vorne beginnen und möglicherweise ein neues APMP-Computersystem erstellen.
Schritt 812 Angenommen, der Schritt 810 war erfolgreich, dann fügt sich die Instanz selbst zu der Systemmitgliedschafts-Maske hinzu.
Schritt 814 Die Instanz wählt einen Big Brother, um ihre Instanz-Unversehrtheit zu überwachen, wie im Folgenden dargelegt.
Schritt 816 Die Instanz trägt ihren Instanz-Zustand als "Mitglied" ein und setzt ein lokales Mitgliedschafts-Flag
Schritt 818 Die Instanz hebt die Konfigurationsdatenbanksperre auf.
Die Routine endet dann mit Schritt 820.
Der Verlust einer Instanz, entweder durch Inaktivitäts-Zeitüberschreitung oder einen Absturz, wird mittels eines "Heartbeat"-Mechanismus erfasst, der in der APMP-Datenbank implementiert ist. Die Instanzen versuchen, eine minimale Prüfung und Löschung vorzunehmen und benachrichtigen den Rest des APMP-Systems während eines Instanz-Absturzes. Wenn dies nicht möglich ist, erfassen die Systemdienste das Verschwinden einer Instanz über einen Software-Heartbeat-Mechanismus. Insbesondere ist ein Feld "Heartbeat" in der APMP-Datenbank für jede aktive Instanz reserviert. In dieses Feld werden durch die entsprechende Instanz in Zeitintervallen, die kleiner sind als ein vorgegebener Wert, beispielsweise alle zwei Millisekunden, Einträge geschrieben.
Jede Instanz kann das Heartbeat-Feld einer anderen Instanz prüfen, um eine direkte Entscheidung zu irgendeinem spezifischen Zweck zu treffen. Eine Instanz liest das Heartbeat-Feld der anderen Instanz, indem sie ihr Hearbeat-Feld zweimal im Abstand einer Zeitdauer von zwei Millisekunden liest. Wenn der Heartbeat zwischen den zwei Ablesungen nicht inkrementiert worden ist, wird die Instanz als inaktiv (verloren, an Kontroll-P (control-P) angehalten oder auf oder über Takt-Interrupt-Prioritätsebene aufgehängt) betrachtet. Wenn die Instanz über die Dauer einer vorgegebenen Zeit inaktiv bleibt, wird die Instanz als tot oder desinteressiert betrachtet.
Des Weiteren wird eine spezielle Anordnung verwendet, um alle Instanzen zu überwachen, weil es nicht für jede Instanz machbar ist, jede andere Instanz zu überwachen, vor allem, wenn das APMP-System groß wird. Diese Anordnung verwendet ein "Big Brother – Little Brother"-Konzept. Insbesondere wenn eine Instanz an dem APMP-System teilnimmt, bevor die Sperre auf der APMP-Datenbank aufgehoben worden ist, wählt sie eines der gegenwärtigen Mitglieder als ihren Big Brother aus, der die teilnehmende Instanz bewachen soll. Die teilnehmende Instanz übernimmt zunächst die Aufgaben des Big Brother für den gegenwärtigen Little Brother ihres gewählten Big Brother und weist sich dann selbst als der neue Little Brother der ausgewählten Instanz zu. Wenn umgekehrt eine Instanz das APMP-Computersystem verlässt, während sie noch in Betrieb ist, so dass sie die Beendigungs-Verarbeitung durchführen kann, und während sie die Sperre auf der APMP-Datenbank enthält, weist sie ihre Big-Brother-Aufgaben ihrem gegenwärtigen Big Brother zu, bevor sie aufhört, ihren Heartbeat zu inkrementieren.
Bei jedem Takt-Tick liest jede Instanz nach dem Inkrementieren ihres eigenen Heartbeat den Heartbeat ihres Little Brother und vergleicht ihn mit dem Wert, der beim letzten Takt-Tick gelesen worden ist. Wenn der neue Wert größer ist, oder sich die ID des Little Brother geändert hat, wird der Little Brother als aktiv betrachtet. Wenn die ID des Little Brother und sein Heartbeat-Wert jedoch die gleichen sind, wird der Little Brother als inaktiv betrachtet, und die gegenwärtige Instanz beginnt, den Little Brother ihres Little Brother ebenfalls zu beobachten. Diese Ansammlung von Zuständigkeit wird bis zu einem vorgegeben Höchstwert fortgesetzt und stellt sicher, dass der Ausfall einer Instanz nicht zum Übersehen des Ausfalls ihres Little Brother führt. Wenn der Little Brother beginnt, seinen Heartbeat wieder zu inkrementieren, werden alle zusätzlichen Zuständigkeiten eingestellt.
Wenn eine Mitglied-Instanz als tot oder desinteressiert betrachtet wird, und sie das APMP-Computersystem nicht über ihre Absicht, sich abzuschalten oder ihren Absturz benachrichtigt hat, wird die Instanz aus dem APMP-System entfernt. Dies kann zum Beispiel durch Setzen des "Bugcheck"-Bits in der primitiven Interrupt-Maske der Instanz (instance primitive interrupt mask) und Senden eines IP-Interrupts an alle CPUs der Instanz erfolgen. Im Regelfall kann auf einen gemeinsam genutzten Speicher nur unterhalb der Hardware-Priorität des IP-Interrupt zugegriffen werden. Dies stellt sicher, dass, wenn die CPUs in der Instanz versuchen sollten, auf einer Priorität unterhalb derjenigen des IP-Interrupt zu arbeiten, der IP-Interrupt zuerst eintritt und die CPU daher das "Bugcheck"-Bit sieht, bevor irgendwelche Threads mit niedrigerer Priorität ausgeführt werden. Dies stellt sicher, dass die Betriebssystem-Instanz abstürzt und keine gemeinsam genutzten Ressourcen in Mitleidenschaft zieht, wie beispielsweise den Speicher, der zu anderen Zwecken neu reserviert worden sein kann, als die Instanzen als tot beurteilt wurden. Als ein zusätzlicher oder alternativer Mechanismus kann eine Konsolen-Rückfrage, (sofern vorhanden), aufgerufen werden, um die Instanz zu entfernen. Des Weiteren führen die restlichen Instanzen in Übereinstimmung mit einer bevorzugten Ausführungsform, immer wenn eine Instanz verschwindet oder ohne Warnung aus dem APMP-Computersystem fällt, einige Unversehrtheitsprüfungen durch, um zu bestimmen, ob sie fortfahren können. Zu diesen Prüfungen gehört das Überprüfen, dass auf alle Seiten in der APMP-Datenbank immer noch zugegriffen werden kann, d.h. dass kein Speicherfehler vorgelegen hat.
Zuweisung von Ressourcen nach der Teilnahme
Eine CPU kann höchstens eine zugehörige Partition zu jedem Zeitpunkt während der Hochfahrzeit eines APMP-Systems aufweisen. Jedoch kann sich die Wiedergabe dieser Zugehörigkeit und der Einheit, die für deren Steuerung zuständig ist, als Ergebnis von Konfigurati ons- und Zustands-Übergängen, denen die Ressource selbst unterliegt, der Partition, in der sie resident ist, und der Instanz, die in dieser Partition läuft, ändern.
Die CPU-Zugehörigkeit wird auf eine Reihe von Arten in einer Reihe von Strukturen angegeben, die von der Einheit vorgegeben werden, welche die Ressource zu dem Zeitpunkt verwaltet. Im grundlegendsten Fall kann die CPU in einem nicht-zugewiesenen Zustand sein, verfügbar für alle Partitionen, die in dem gleichen Mitbenutzungs-Set resident sind wie die CPU. Schließlich wird diese CPU einer spezifischen Partition zugewiesen, die eine Betriebssystem-Instanz ausführen kann oder nicht. In jedem Fall gibt die Partition ihre Zugehörigkeit für alle anderen Partitionen über die Konfigurationsbaumstruktur und für alle Betriebssystem-Instanzen, die in dieser Partition ausgeführt werden können, über das Bit AVAILABLE in dem HWRPB-Feld Flags pro CPU wieder.
Wenn die besitzende Partition keine Betriebssystem-Instanz aufweist, die auf ihr läuft, ist ihre Konsole dafür zuständig, auf Übergangsereignisse in den darin enthaltenen Ressourcen zu reagieren und diese zu initialisieren. Die Konsole entscheidet, ob sich die Ressource in einem Zustand befindet, die eine Migration zu einer anderen Partition oder ihre Zurücksetzung in den nicht-zugewiesenen Zustand gestattet.
Wenn in der Partition jedoch gegenwärtig eine Partition läuft, gibt die Konsole die Zuständigkeit für die Initialisierung von Ressourcen-Übergängen auf und ist zuständig für die Benachrichtigung der ausführenden primären CPU der Instanz, wenn eine Konfigurationsänderung stattgefunden hat. Sie ist immer noch der Vermittler (facilitator) des grundlegenden Hardware-Übergangs, doch die Steuerung von Ressourcen-Übergängen geht auf eine Ebene höher an die Betriebssystem-Instanz über. Der Zuständigkeits-Transfer findet statt, wenn die primäre CPU ihren ersten Befehl außerhalb des Konsolenmodus in einem Systemstart ausführt.
Betriebssystem-Instanzen können Zugehörigkeitszustands-Informationen auf jede Reihe von Arten verwalten, die intern den effizientesten Einsatz der Informationen fördern. Zum Beispiel kann eine Hierarchie von Zustands-Bit-Vektoren verwendet werden, welche die instanzspezifischen Informationen sowohl intern als auch global (für andere Mitglieder, die eine APMP-Datenbank gemeinsam nutzen) wiedergeben.
Die internen Darstellung sind strikt für die Verwendung der Instanz. Sie werden zum Startzeitpunkt aus dem grundlegenden Konfigurationsbaum und HWRPB-Informationen aufgebaut, aber als strikte Software-Konstrukte für die Laufzeit der Instanz verwaltet. Sie stellen die Software-Sicht der für die Instanz verfügbaren Partitions-Ressourcen dar und können – über Software-Regelsets – die Konfiguration weiter auf eine Untergruppe von derjenigen einschränken, die durch die physikalischen Konstrukte angegeben wird. Gleichwohl sind alle Ressourcen in der Partition zu der Instanz zugehörig und werden von dieser – unter Verwendung der Konsolen-Mechanismen zum Anweisen von Zustands-Übergängen – verwaltet, bis dieser Betriebssystem-Aufruf keine durchführbare Einheit mehr ist. Dieser Zustand wird angegeben, indem die primäre CPU, die wieder in den Konsolenmodus zurückgekehrt ist, angehalten wird, ohne die Möglichkeit, ohne Neustart wieder zurückzukehren.
Die Zugehörigkeit von CPU-Ressourcen erstreckt sich nie über die Instanz hinaus. Die Zustands-Informationen jeder einzelnen Instanz werden in einer APMP-Datenbank für Nur-Lese-Entscheidungszwecke dupliziert, doch kann keine andere Instanz ein Zustands-Übergangsereignis für eine Ressource einer anderen CPU erzwingen. Jede Instanz ist dafür zuständig, ihre eigenes Ressourcen-Set zu verstehen und zu steuern; sie kann externe Anforderungen für ihre Ressourcen empfangen, aber nur sie kann die Entscheidung treffen, dass gestattet wird, die Ressourcen zu transferieren.
Wenn jede derartige CPU betriebsfähig wird, setzt sie ihr Bit AVAILABLE in den Flags pro CPU nicht. Wenn das Bit AVAILABLE nicht gesetzt ist, wird keine Instanz versuchen, zu starten oder erwarten, dass die CPU an dem SMP-Betrieb teilnimmt. Stattdessen fragt die CPU im Konsolenmodus das Feld Zugehörigkeit in dem Konfigurationsbaum ab, das auf die Zuweisung einer gültigen Partition wartet. Sobald eine gültige Partition durch die primäre CPU als Zugehörigkeit zugewiesen worden ist, beginnt die CPU mit ihrem Betrieb in dieser Partition.
Während der Laufzeit gibt das Feld current_owner die Partition wieder, in der eine CPU sich in Ausführung befindet. Das Bit AVAILABLE in dem Feld Flags pro CPU in dem HWRPB bleibt der endgültige Indikator, ob eine CPU tatsächlich verfügbar ist oder sich in Ausführung befindet, für den SMP-Betrieb mit einer Betriebssystem-Instanz und hat die gleiche Bedeutung wie in herkömmlichen SMP-Systemen.
Es ist anzumerken, dass eine Instanz kein Mitglied eines Mitbenutzungs-Sets sein muss, um an vielen der Neukonfigurationsfunktionen eines APMP-Computersystems teilzunehmen. Eine Instanz kann ihre Ressourcen zu einer anderen Instanz in dem APMP-System transferieren, so dass eine Instanz, die nicht Teil eines Mitbenutzungs-Sets ist, eine Ressource zu einer Instanz transferieren kann, die Teil des Mitbenutzungs-Sets ist. Auf ähnliche Weise kann die Instanz, die nicht Teil des Mitbenutzungs-Sets ist, eine Ressource von einer Instanz empfangen, die Teil des Mitbenutzungs-Sets ist.
Eine Software-Implementierung der oben beschriebenen Ausführungsform kann eine Reihe von Computerbefehlen umfassen, die entweder auf einem konkreten Medium, wie beispielsweise einem computerlesbaren Medium, z.B. einer Diskette, einer CD-ROM, einem ROM-Speicher oder einer Festplatte fixiert sind, oder zu einem Computersystem über ein Modem oder eine andere Schnittstelleneinrichtung über ein Medium übertragen werden können. Das Medium kann entweder ein konkretes Medium sein, einschließlich, aber nicht darauf beschränkt, optischen oder analogen Kommunikationsleitungen, oder kann mit drahtlosen Techniken implementiert werden, einschließlich, aber nicht darauf beschränkt, Mikrowellen-, Infrarot- oder anderen Übertragungstechniken. Es kann auch das Internet sein. Die Reihe von Computerbefehlen verkörpert die gesamte oder einen Teil der Funktionalität, die hierin vorher unter Bezugnahme auf die Erfindung beschrieben worden ist. Der Fachmann wird verstehen, dass solche Computerbefehle in einer Reihe von Programmiersprachen für den Einsatz in vielen Computer-Architekturen oder Betriebssystemen geschrieben werden können. Ferner können solche Befehle unter Verwendung jeder gegenwärtigen oder künftigen Speichertechnologie gespeichert werden, einschließlich, aber nicht darauf beschränkt, Halbleiter-, Magnet-, Optik- oder anderen Speichereinrichtungen, oder unter Verwendung jeder gegenwärtigen oder künftigen Kommunikationstechnologie übertragen werden, einschließlich, aber nicht darauf beschränkt, optischen, Infrarot-, Mikrowellen- oder anderen Übertragungstechnologien. Es wird in Erwägung gezogen, dass ein solches Computerprogramm-Produkt als ein entfernbares Medium mit begleitender gedruckter oder elektronischer Dokumentation vertrieben werden kann, z.B. in Folie eingeschweißte Software, vorabgeladen mit einem Computersystem, z.B. auf einem System-ROM oder einer Festplatte, oder von einem Server oder elektronischen schwarzen Brett aus über ein Netzwerk, z.B. das Internet oder World Wide Web, vertrieben.
Obwohl eine beispielhafte Ausführungsform der Erfindung offenbart worden ist, wird es für den Fachmann offensichtlich sein, dass verschiedene Änderungen und Modifizierungen vorgenommen werden können, die einige der Vorteile der Erfindung erzielen können, ohne vom Umfang der Erfindung anzuweichen. Zum Beispiel wird es für den durchschnittlichen Fachmann offenkundig sein, dass, obwohl die Beschreibung sich auf ein bestimmtes Hardware-System und Betriebssystem bezogen hat, andere Hardware und Betriebssystem-Software in der gleichen Weise wie beschrieben verwendet werden könnten. Andere Gesichtspunkte, wie beispielsweise die spezifischen Befehle, die zum Erzielen einer bestimmten Funktion verwendet werden, sowie andere Modifizierungen an dem erfinderischen Konzept sollen durch die Ansprüche im Anhang abgedeckt werden.
Beansprucht wird Folgendes:

Claims

Computer-System (200) mit einer Vielzahl von System-Ressourcen, die Prozessoren (108–114), einen Speicher (120) und eine I/O-Schaltung (118) enthalten, wobei das Computer-System umfasst: einen Verbindungsmechanismus; einen Software-Mechanismus, der die System-Ressourcen in eine Vielzahl von Partitionen (202, 204, 206) unterteilt; und wenigstens eine Betriebssystem-Instanz (208), die in einer Vielzahl der Partitionen läuft; gekennzeichnet dadurch, dass der Verbindungsmechanismus die Prozessoren, den Speicher und die I/O-Schaltung elektrisch so verbindet, dass jeder Prozessor elektrischen Zugriff auf den gesamten Speicher und wenigstens einen Teil der I/O-Schaltung hat; und durch eine Konfigurations-Datenbank, die in dem Speicher (120) gespeichert ist und die Partitionen (202, 204, 206) anzeigt, die Teil des Computer-Systems (200) sind, und die Informationen enthält, die anzeigen, ob jede Betriebssystem-Instanz (208, 210, 212) aktiv ist.
Computer-System nach Anspruch 1, des Weiteren gekennzeichnet durch wenigstens eine Instanz (208) eines anderen Betriebssystems, die in wenigstens einer der Vielzahl von Partitionen (202) läuft.
Computer-System nach Anspruch 1, wobei wenigstens ein Teil des Speichers exklusiv jeder der Partitionen (202, 204, 206) zugewiesen ist.
Computer-System nach Anspruch 1, wobei die Vielzahl von Prozessoren (108–114) physisch zwischen Partitionen (202) aufgeteilt ist und jede Partition ein Konsolenprogramm (213, 215, 217) umfasst, das die Prozessoren in der Partition steuert.
Computer-System nach Anspruch 1, des Weiteren gekennzeichnet durch eine Einrichtung, die Konfigurations-Informationen führt, die anzeigen, welche der Vielzahl von System-Ressourcen jeder Partition (202) zugewiesen ist.
Computer-System nach Anspruch 5, wobei einer der Prozessoren (108–114) ein Master-Konsolenprogramm ausführt, das die Konfigurations-Informationen erzeugt; jede Partition (202) ein Konsolenprogramm (213, 215, 217) umfasst, das die Prozessoren in der Partition steuert, und das Konsolenprogramm in jeder Partition so ausgestattet ist, dass es mit dem Master-Konsolenprogramm kommuniziert, um Konfigurations-Informationen auszutauschen.
Computer-System nach Anspruch 1, wobei der Verbindungsmechanismus einen Schalter umfasst.
Computer-System nach Anspruch 1, des Weiteren gekennzeichnet durch eine Master-Konsole, die eine Einrichtung umfasst, die die Konfigurationsdatenbank während einer Hochfahr-Sequenz des Computer-Systems erzeugt.
Computer-System nach Anspruch 1, wobei die Betriebssystem-Instanzen (208) Einrichtungen zum kontinuierlichen gegenseitigen Überwachen auf Aktivität umfassen, um eine Fehlfunktion in einer Betrieb-Instanz zu erfassen, und jede Betriebssystem-Instanz eine Einrichtung zum Überwachen einer anderen Betriebssystem-Instanz mittels eines Heartbeat-Mechanismus umfasst.
Verfahren zum Aufbauen eines Computer-Systems mit einer Vielzahl von Systemressourcen, die Prozessoren (108–114), einen Speicher (120) und eine I/O-Schaltung (118) enthalten, wobei das Verfahren die folgenden Schritte umfasst: a) elektrisches Verbinden der Prozessoren, des Speichers und der I/O-Schaltung so, dass jeder Prozessor elektrischen Zugang zu dem gesamten Speicher und wenigstens einem Teil der I/O-Schaltung hat; b) Unterteilen der System-Ressourcen in eine Vielzahl von Partitionen (202, 204, 206); c) Ausführen wenigstens einer Betriebssystem-Instanz (208) in einer Vielzahl der Partitionen; und d) Erzeugen einer Konfigurations-Datenbank, die Informationen dahingehend, welche der Partitionen Teil des Computer-Systems sind, und Informationen enthält, die anzeigen, ob jede Betriebssystem-Instanz aktiv ist.
Verfahren nach Anspruch 10, wobei Schritt c) den folgenden Schritt umfasst: c1) Ausführen wenigstens zwei verschiedener Betriebssystem-Instanzen (208) in der Vielzahl von Partitionen (202, 204, 206).
Verfahren nach Anspruch 10, wobei Schritt b) den folgenden Schritt umfasst: b1) Zuweisen wenigstens eines Teils des Speichers (120) zu jeder der Partitionen (202, 204, 206).
Verfahren nach Anspruch 10, wobei Schritt b) die folgenden Schritte umfasst: b2) physisches Aufteilen der Prozessoren (108–114) zwischen Partitionen (202, 204, 206); und b3) Ausführen eines Konsolenprogramms (213, 215, 217) auf einem Prozessor in jeder Partition (202), wobei das Konsolenprogramm die Prozessoren in der Partition steuert.
Verfahren nach Anspruch 13, wobei Schritt b) den folgenden Schritt umfasst: b4) Bestimmen eines primären Prozessors in jeder Partition; und wobei jeder Schritt c) die folgenden Schritte umfasst: c1) Ausführen jeder Betriebssystem-Instanz (208) auf einem primären Prozessor in einer der Partitionen (202, 204, 206); und c2) Steuern jeder Betriebssystem-Instanz (208) so, dass sie mit dem Konsolenprogramm für die Partition kommuniziert.
Verfahren nach Anspruch 10, das des Weiteren den folgenden Schritt umfasst: e) Führen von Konfigurations-Informationen, die anzeigen, welche der Vielzahl von System-Ressourcen jeder Partition (202) zugewiesen ist.
Verfahren nach Anspruch 15, wobei Schritt (e) die folgenden Schritte umfasst: e1) Ausführen eines Master-Konsolenprogramms auf einem der Prozessoren (108–114), wobei das Master-Konsolenprogramm die Konfigurations-Informationen erzeugt; e2) Ausführen eines Konsolenprogramms (213, 215, 217) in jeder Partition, das die Prozessoren in der Partition (202) steuert; wobei Schritt e2) den folgenden Schritt umfasst: e2a) Verwenden des Konsolenprogramms in jeder Partition zum Kommunizieren mit dem Master-Konsolenprogramm, um Konfigurations-Informationen auszutauschen; und e3) Senden der Konfigurations-Informationen von dem Master-Konsolenprogramm zu jedem der anderen Konsolenprogramme.
Verfahren nach Anspruch 10, wobei Schritt a) den folgenden Schritt umfasst: a1) Verwenden eines Schalters, um die Prozessoren (108–114), den Speicher (120) und die I/O-Schaltung (118) miteinander zu verbinden.
Verfahren nach Anspruch 10, wobei Schritt c) den folgenden Schritt umfasst: c3) Verwenden der Betriebssystem-Instanzen (208, 210, 212), um einander kontinuierlich zu überwachen und eine Fehlfunktion in einer Betriebs-Instanz mittels eines Heartbeat-Mechanismus zu erfassen.