DE60016283T2

DE60016283T2 - Arbeitsbelastungsverwaltung in einer rechnerumgebung

Info

Publication number: DE60016283T2
Application number: DE60016283T
Authority: DE
Inventors: Jeffrey Kubala; Jeffrey Nick; Peter Winchester YOCOM; Catherine Eilert
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1999-09-28
Filing date: 2000-09-28
Publication date: 2005-12-01
Anticipated expiration: 2020-09-29
Also published as: HU228286B1; HUP0301326A2; ATE283512T1; BR0014350A; CN100397341C; CA2382017C; BRPI0014350B1; EP1256039B1; JP3872343B2; CA2382017A1; PL365894A1; WO2001023974A2; DE60016283D1; IL148728A; IL148728A0; AU7437600A; JP2003514270A; WO2001023974A3; CZ20021093A3; CN1391671A

Description

Die vorliegende Erfindung betrifft allgemein die Verwaltung der Arbeitbelastung (Workload) in einem Rechnersystem und insbesondere in einem partitionierten System.
Die logische Partitionierung ermöglicht die Einrichtung einer Vielzahl von Systemabbildern innerhalb einer einzelnen physischen Maschine oder einem Zentralprozessorkomplex (central processor complex, CPC). Jedes Systemabbild kann so arbeiten wie ein separates Rechnersystem. Das heißt, jede logische Partition kann unabhängig von anderen zurückgesetzt, zu Anfang mit einem Betriebssystem, welches für jede logische Partition verschieden sein kann, geladen werden, und mit verschiedenen Softwareprogrammen laufen, welche unterschiedliche Eingabe-/Ausgabe-Einheiten (E/A) verwenden.
Beispiele für logisch partitionierte Rechnersysteme werden zum Beispiel in der US-Patentschrift 4 564 903 vom 14. Januar 1986, der US-Patentschrift 4 843 541 vom 27. Juni 1989 und der US-Patentschrift 5 564 040 vom B. Oktober 1996 sowie der Europäischen Patentanmeldung EP-A2-0917056 beschrieben, welche ein Rechnersystem mit einer Vielzahl von Partitionen beschreibt, deren Ressourcen verteilt und skaliert werden können..
Handelsübliche Ausführungen von logisch partitionierten Systemen sind zum Beispiel IBM S/390^®-Prozessoren, die mit dem Merkmal Prozessorressourcen-/Systemmanager (Processor Resource/Systems Manager^TM, PR/SM^TM) ausgestattet sind, welches zum Beispiel in der Veröffentlichung „Processor Resource/Systems Manager Planning Guide", GA22-7236-04, März 1999, beschrieben wird.
Ein wichtiger Aspekt eines logisch partitionierten Systems besteht in der Verwaltung der innerhalb der Partitionen dieses Systems herrschenden Arbeitsbelastung. In S/390-Systemen zum Beispiel dienen Workload-Manager zur Verwaltung der Arbeitsbelastung innerhalb der einzelnen Partitionen und zwischen ihnen. Die Workload-Manager versuchen, die Arbeitsbelastung der einzelnen Partitionen untereinander auszugleichen, indem sie Arbeitsaufgaben auf die physischen Ressourcen des Systems umverteilen. Zur Umverteilung der Arbeitsaufgaben muss jedoch sichergestellt werden, dass sich die für die umgelagerte Arbeit benötigten Daten an diesem Standort befinden. Durch dieses Erfordernis wird die Arbeitsverlagerung oft eingeschränkt. Somit ist es wünschenswert, die Verwaltung der Arbeitsbelastung in Rechnersystemen weiter zu verbessern.
Demzufolge stellt die Erfindung ein Verfahren, ein System und ein Computerprogramm gemäß den beiliegenden Ansprüchen bereit.
Bei einer Ausführungsart beinhaltet das Verfahren die Verwaltung der Arbeitsbelastung zwischen zwei oder mehr Partitionen aus einer Vielzahl von Partitionen der Rechnerumgebung, wobei das Verwalten die dynamische Anpassung der Zuordnung einer gemeinsam zu nutzenden Ressource mindestens einer der beiden oder mehr Partitionen in der Weise beinhaltet, dass die Zielwerte für die Arbeitsbelastung der beiden oder mehr Partitionen ausgeglichen werden.
Bei einer anderen Ausführungsart der vorliegenden Erfindung beinhaltet ein Verfahren zur Verwaltung der Arbeitsbelastung einer Rechnerumgebung das Verwalten der Arbeitsbelastung zwischen zwei oder mehr Partitionen aus einer Vielzahl von Partitionen der Rechnerumgebung, wobei die beiden oder mehr Partitionen eine gemeinsam zu nutzende Ressource gleichzeitig nutzen. Das Verwalten beinhaltet das dynamische Anpassen der Zuweisung der gemeinsam zu nutzenden Ressource mindestens einer Partition der beiden oder mehr Partitionen.
Eine bevorzugte Ausführungsart der Erfindung ermöglicht die dynamische Umverteilung gemeinsam zu nutzender Ressourcen zwischen logischen Partitionen unter der Regie eines Workload-Managers. Zu diesen Ressourcen gehören beispielsweise CPU-Ressourcen, logische Prozessorressourcen, E/A-Ressourcen, Coprozessoren, Kanalressourcen, Netzwerkadapter und Speicherressourcen. Üblicherweise erfolgt die dynamische Anpassung der physischen Ressourcen entsprechend den Zielwerten für die Arbeitsbelastung mittels eines Workload-Managers (WLM), Sysplex und PM/SM-Integration, ohne dass eine parallele Sysplex-Datennutzung erforderlich ist.
Außerdem erfolgt bei der bevorzugten Ausführungsart mittels des WLM die dynamische Verwaltung von CPU-Ressourcen zwischen logischen Partitionen (LPARs); die dynamische Verwaltung der Kanalpfade (CHPID) zwischen den hPARs; das Einordnen der E/A-Prioritäten im Kanal-Teilsystem durch Warteschlangen; und die dynamische Verwaltung der Speicher zwischen LPARs. Bei einer Ausführungsform ermöglichen LPAR-Gruppen die gemeinsame Nutzung von Ressourcen durch die Zuweisung der Ressourcen entsprechend der Priorität.
Eine andere Ausführungsart der Erfindung stellt ein Verfahren zur Verwaltung von Partitionsgruppen einer Rechnerumgebung und gleichzeitig das Kennzeichnen einer Gruppe aus einer Vielzahl von Partitionen der Rechnerumgebung bereit. Das Verfahren beinhaltet ferner das Ermitteln einer gemeinsam zu nutzenden Ressource, welche der Gruppe zugewiesen werden soll, wobei mindestens ein Teil der gemeinsam zu nutzenden Ressource der Vielzahl der Partitionen der Gruppe zugewiesen wird.
Eine weitere Ausführungsart stellt ein Verfahren zur Verwaltung von Partitionsgruppen einer Rechnerumgebung bereit, bei welchem ermittelt wird, ob eine Gruppe der Rechnerumgebung sich verändert hat, und die Gruppe eine Vielzahl von Partitionen der Rechnerumgebung beinhaltet; und bei welchem die Zuweisung einer Ressource der Gruppe als Reaktion auf das Ermittlungsergebnis innerhalb der Gruppe dynamisch angepasst wird.
Bei der bevorzugten Ausführungsart werden die für diese Gruppen bestimmten Ressourcen überwacht, um zu festzustellen, welche Ressourcen einer bestimmten Gruppe zugewiesen werden sollen, und um die Zuweisung dieser Ressourcen durchzuführen. Die Überwachung liefert ein Indiz bezüglich der Ressourcen, welche geändert werden dürfen, sodass der WLM richtige Entscheidungen bezüglich der nächsten Aktionen fällen kann. Durch die Überwachung können Untergruppen von Ressourcen der Maschine in der Weise bereitgestellt werden, dass die Maschine darüber im Klaren ist, was die Software zu tun beabsichtigt, und die Software die Konfiguration der Maschine kennt.
Eine weitere bevorzugte Ausführungsart der Erfindung stellt ein Verfahren zum Verwalten von CPU-Ressourcen (Central Processing Unit, Zentraleinheit) in einer Rechnerumgebung und zum Ermitteln, ob eine Zuweisung von CPU-Ressourcen zu einer Partition der Rechnerumgebung angepasst werden soll, sowie zum dynamischen Anpassen der Zuweisung zwischen der Partition und einer anderen Partition der Rechnerumgebung bereit.
Vorzugsweise erfolgt die dynamische Anpassung entsprechend den Zielwerten der Arbeitsbelastung mindestens der einen Partition und wird zwischen einer Vielzahl von Partitionen der Rechnerumgebung durchgeführt.
Bei der bevorzugten Ausführungsart verteilt ein Workload-Manager die CPU-Ressourcen zwischen den logischen Partitionen durch die dynamische Anpassung der den logischen Partitionen zugewiesenen CPU-Prozessorgewichtungen. Der WLM erkennt beispielsweise, wann eine wichtige Arbeit verzögert wird, weil das Gewicht der Partition, in welcher diese läuft, zu gering ist. Der WLM kann diese Arbeit beschleunigen, indem er zum Beispiel das Gewicht der betreffenden Partition erhöht und das Gewicht einer anderen Partition verringert, sodass der wichtigen Arbeit zusätzliche CPU-Kapazität zur Verfügung steht. Dadurch kann man bei veränderten Anforderungen an die Arbeitsbelastung den Partitionen mit höherem Bedarf dynamisch CPU-Ressourcen zuteilen.
Die vorliegende Erfindung stellt ferner Computerprogramme zum Realisieren der obigen Verfahren bereit. Solche Computerprogramme umfassen im Allgemeinen durch eine Maschine ausführbare Anweisungen, die in einem durch den Computer verwendbaren Medium oder einer maschinenlesbaren Programmspeichervorrichtung codiert sind, und können entweder Bestandteil eines Computersystems sein oder separat geliefert werden (eventuell durch Übertragung über ein Netzwerk).
Die vorliegende Erfindung stellt auch Systeme für die obigen Verfahren bereit, welche üblicherweise aus einer Kombination aus einem Computerprogramm zum Durchführen eines Verfahrens und einer geeigneten Hardware bestehen.
Es ist klar, dass solche Computerprogramme und -systeme von denselben bevorzugten Merkmalen wie die Verfahren der Erfindung profitieren.
Im Folgenden werden lediglich als Beispiel verschiedene bevorzugte Ausführungsarten der Erfindung unter Bezug auf die folgenden Zeichnungen detailliert beschrieben:
1a stellt ein Beispiel einer Rechnerumgebung dar;
1b stellt eine weitere Ausführungsart einer Rechnerumgebung dar;
2 stellt weitere Komponenten einer Rechnerumgebung dar;
3 stellt ein Beispiel von Gruppen mit logischen Partitionen dar;
4a bis 4b zeigen ein Beispiel der Logik einer Partition, welche Bestandteil einer Gruppe wird;
5 zeigt eine Ausführungsart der Logik für das Ausscheiden einer Partition aus einer Gruppe;
6 zeigt eine Ausführungsart der Logik zum Ermitteln, ob die Gewichtung einer Partition erhöht werden kann, um eine Empfänger-Betriebsklasse der Partition zu unterstützen;
7 zeigt eine Ausführungsart der Logik zum dynamischen Anpassen der Konfiguration von logischen Prozessoren;
8 zeigt eine Ausführungsart eines Kanal-Teilsystems;
9 zeigt eine Ausführungsart der Logik zum Auswählen einer zu verarbeitenden E/A-Operation;
10 zeigt eine Ausführungsart der Logik zum Ermitteln, ob eine E/A-Konfiguration angepasst werden muss;
11 zeigt eine Ausführungsart der Logik zum Erfassen von Daten von 10;
12 zeigt eine Ausführungsart der Logik zum Prüfen der Lastausgleichung von 10;
13a und 13b zeigen eine Ausführungsart der Logik zum Korrigieren des Lastungleichgewichts einer E/A-Konfiguration;
14 zeigt eine Ausführungsart der Logik zum Ermitteln der betroffenen Teilsysteme;
15 zeigt eine Ausführungsart der Logik zum Festlegen eines bestimmten Zielwertes für die E/A-Geschwindigkeit; und
16a bis 22c zeigen verschiedene Beispiele von E/A-Konfigurationen, die zur Entropiebestimmung verwendet werden.
Es werden Mittel zur Verwaltung der Arbeitsbelastung bereitgestellt, welche die dynamische Anpassung der Zuweisung von Ressourcen einer Rechnerumgebung ermöglichen, um die Arbeitsbelastung dieser Umgebung auszugleichen. Bei einem Beispiel beinhaltet die Rechnerumgebung eine Vielzahl logischer Partitionen, und die Arbeitsbelastung von zwei oder mehreren dieser Partitionen wird verwaltet.
Eine Ausführungsart einer Rechnerumgebung, welche Mittel zur Verwaltung der Arbeitsbelastung verwendet, wird unter Bezug auf 1a beschrieben. Eine Rechnerumgebung 100 basiert zum Beispiel auf der Enterprise Systems Architecture (Unternehmens-Systemarchitektur, ESA)/390 von International Business Machines Corporation, Armonk, New York. Die Architektur ESA/390 wird in einer Publikation von IBM mit dem Titel „Enterprise Systems Architecture/390 Principles of Operation", IBM Publications Nr. SA22-7201-04, Juni 1997, beschrieben. Ein Beispiel für eine Rechnerumgebung auf Grundlage der ESA/390 ist der von der International Business Machines Corporation angebotene 9672 Parallel Enterprise Server.
Die Rechnerumgebung 100 beinhaltet zum Beispiel einen Zentralprozessorkomplex (CPC) 102 mit einem oder mehreren Zentralprozessoren 106 (z.B. CP1 bis CP4), eine oder mehrere Partitionen 108 (z.B. die logischen Partitionen LP1 bis LP4) und mindestens einen Manager 110 für logische Partitionen, wobei jede dieser Komponenten im Folgenden beschrieben werden.
Die Zentralprozessoren 106 sind physische Prozessorressourcen, welche den logischen Partitionen zugeordnet sind. Insbesondere weist jede logische Partition 108 einen oder mehrere logische Prozessoren auf (die zur Vereinfachung nicht dargestellt sind), wobei jeder den gesamten einer Partition zugeordneten physischen Prozessor 106 oder einen Teil davon darstellt. Die logischen Prozessoren einer bestimmten Partition 108 können entweder ausschließlich für diese Partition bestimmt sein (sodass die zugehörige Prozessorressource 106 für diese Partition reserviert ist) oder gemeinsam mit einer anderen Partition genutzt werden (sodass die zugehörige Prozessorressource bei Bedarf auch einer anderen Partition zur Verfügung steht).
Bei dem gezeigten speziellen Beispiel fungiert jede der logischen Partitionen LP1 bis LP4 als separates System mit einem eigenen Betriebssystem 112 (das bei jeder logischen Partition ein anderes sein kann) und einer oder mehreren Anwendungen 114. Bei einer Ausführungsart handelt es sich bei dem Betriebssystem um die von International Business Machines Corporation angebotenen Betriebssysteme OS/390^TM oder MVS/ESA^TM.
Außerdem beinhaltet jedes Betriebssystem (oder eine Untergruppe davon) einen Workload-Manager 116 zum Verwalten der Arbeitsbelastung innerhalb einer Partition und zwischen den Partitionen. Ein Beispiel für einen Workload-Manager ist der von International Business Machines Corporation angebotene WLM. Der WLM wird zum Beispiel in den-US-Patentschriften 5 473 773 vom 5. Dezember 1995 und 5 675 739 vom 7. Oktober 1997 beschrieben.
Die logischen Partitionen 108 werden durch einen Logikpartitionsmanager 110 verwaltet, der durch einen in den Prozessoren 106 laufenden Mikrocode ausgeführt wird. Die logischen Partitionen 108 (LP1 bis LP4) und der Logikpartitionsmanager 110 umfassen jeweils ein oder mehrere Programme, die sich in entsprechenden für die Zentralprozessoren vorgesehenen Teilen des Zentralspeichers befinden. Ein Beispiel für den Logikpartitionsmanager 110 ist der PR/SM.
Bei einer weiteren Ausführungsart einer Rechnerumgebung sind zwei oder mehrere Zentralprozessorkomplexe miteinander verbunden und bilden einen Sysplex, der in 1b dargestellt ist. In diesem Beispiel ist der Zentralprozessorkomplex (CPS) 102 mit einem oder mehreren anderen CPCs 120 zum Beispiel über eine Verbindungseinheit 122 verbunden.
Bei dem gezeigten Beispiel beinhaltet der CPC 120 eine Vielzahl von logischen Partitionen 124 (z.B. LP1 bis LP4), die durch einen Logikpartitionsmanager 126 verwaltet werden. Eine oder mehrere der logischen Partitionen beinhalten ein Betriebssystem, welches über einen Workload-Manager und ein oder mehrere (in diesem Beispiel der Klarheit halber nicht gezeigte) Anwendungsprogramme verfügen kann. Außerdem beinhaltet der CPC 120 eine Vielzahl von Zentralprozessoren 128 (z.B. CP1 bis CP3), deren Ressourcen der Vielzahl der logischen Partitionen zugewiesen werden. Insbesondere werden die Ressourcen einem oder mehreren logischen Prozessoren 130 jeder Partition zugewiesen. (Bei anderen Ausführungsarten kann jeder CPC über eine oder mehrere logische Partitionen und einen oder mehrere Zentralprozessoren verfügen.) Die Verbindungseinheit 122 (auch unter der Bezeichnung SES – strukturierter externer Speicherprozessor – bekannt) enthält einen Speicher, auf den die Zentralprozessorkomplexe zugreifen können, und führt Operationen aus, die durch die Programme in den CPCs angefordert werden. Die Verbindungseinheit dient zur allgemeinen Bereitstellung von Statusinformationen zum Fällen von Entscheidungen zur Umverteilung der gemeinsam genutzten Ressourcen. (Bei einer Ausführungsart ist jeder Zentralprozessorkomplex mit einer Vielzahl von Verbindungseinheiten verbunden.) Aspekte der Arbeitsweise einer Verbindungseinheit sind in den US-Patentschriften 5 317 739 vom 31. Mai 1994, 5 561 809 vom 1. Oktober 1996 und 5 706 432 vom 6. Januar 1998 von Elko et al. sowie den darin zitierten Patentschriften und Patentanmeldungen genauer beschrieben.
Bei einer Ausführungsart sind ein oder mehrere Zentralprozessoren mit mindestens einem Kanal-Teilsystem verbunden, das zum Datenaustausch mit den E/A-Einheiten dient. Zum Beispiel ist ein Zentralprozessor 200 (2) mit dem Hauptspeicher 202 und mindestens einem Kanal-Teilsystem 204 verbunden. Dieses Kanal-Teilsystem 204 wiederum ist mit einer oder mehreren Steuereinheiten 206 verbunden. Diese Steuereinheiten sind dann mit einer oder mehreren E/A-Einheiten 208 verbunden.
Das Kanal-Teilsystem steuert den Datenfluss zwischen den Eingabe-/Ausgabeeinheiten und dem Hauptspeicher. Es übernimmt für die Zentraleinheiten die Aufgabe der direkten Kommunikation mit den Eingabe-/Ausgabeeinheiten und ermöglicht dadurch, dass die Datenverarbeitung gleichzeitig mit der Verarbeitung der Eingabe-/Ausgabeprozeduren erfolgt. Das Kanal-Teilsystem verwendet einen oder mehrere Kanalpfade 214 als Übertragungsleitungen zur Steuerung des Datenflusses von oder zu den Eingabe-/Ausgabeeinheiten 208.
Jeder Kanalpfad 214 beinhaltet zum Beispiel einen Kanal 210 des Kanal-Teilsystems 204, eine Steuereinheit 206 und eine Leitung 212 zwischen dem Kanal und der Steuereinheit. Bei anderen Ausführungsarten kann ein Kanalpfad mehrere Kanäle, Steuereinheiten und/oder Leitungen aufweisen. Bei einem anderen Beispiel ist es ferner auch möglich, dass ein oder mehrere dynamische Schalter Bestandteil des Kanalpfades sind. Ein dynamischer Schalter ist mit einem Kanal und einer Steuereinheit verbunden und ermöglicht so die Herstellung einer physischen Verbindung zwischen zwei an diesen Schalter angeschlossenen Leitungen. Weitere Einzelheiten zu Kanal-Teilsystemen sind in der US-Patentschrift 5 526 484 vom 11. Juni 1996 beschrieben.
Bei einer bevorzugten Ausführungsart der vorliegenden Erfindung werden unter der Regie eines oder mehrerer Workload-Manager diverse physische Ressourcen dynamisch auf die logischen Partitionen einer Rechnerumgebung aufgeteilt. Diese dynamische Aufteilung ist für die Anwendungs-Teilsysteme transparent.
Beispiele für die aufzuteilenden physischen Ressourcen sind CPU-Ressourcen, Logikprozessorressourcen, Coprozessoren, Kanalressourcen, Netzwerkadapter und Speicherressourcen. Beispielsweise ist ein Coprozessor ein (von der CPU verschiedener) Mikroprozessor innerhalb eines CPC, der eine spezielle Funktion hat. Beispiele für Coprozessoren sind Kanal-Teilsysteme, Netzwerkadapterkarten und Verschlüsselungs- Coprozessoren. Die oben genannten physischen Ressourcen dienen nur als Beispiele, und es können auch andere gemeinsam zu nutzende Ressourcen aufgeteilt werden.
Um die dynamische Verteilung von Ressourcen zu ermöglichen, werden bei einer Ausführungsart logische Partitionen zu Gruppen zusammengefasst, um die Ressourcen durch die Partitionen der jeweiligen Gruppe gemeinsam zu nutzen. Die Größe jeder Gruppe kann von einer bis zu n Partitionen betragen. (Bei einem Beispiel enthalten eine oder mehrere der Gruppen eine oder mehrere Partitionen, jedoch weniger als die Gesamtzahl der Partitionen der Rechnerumgebung.) Insbesondere beinhaltet jede Gruppe zum Beispiel ein oder mehrere Betriebssystemabbilder, die in unabhängigen Bereichen einer Maschine laufen und durch eine gemeinsame Workload-Manager-Funktion zur Verteilung der Arbeitsbelastungen und Ressourcen verwaltet werden. Bei einem Beispiel handelt es sich bei diesen Bereichen um logische Partitionen, die in einem logisch partitionierten Modus laufen, und bei den Betriebssystemen um das OS/390, das in den logischen Partitionen läuft. Die logischen Partitionen einer Gruppe können eine Untergruppe von Partitionen eines Systems (z.B. eines CPC) oder eines Sysplex, ein ganzes System oder einen ganzen Sysplex oder Partitionen verschiedener Sysplexe (zum Beispiel in einem einzelnen CPC) oder verschiedener Systeme darstellen.
3 zeigt eine Ausführungsart von zwei Logikpartitionsgruppen (oder -clustern) eines Zentralprozessorkomplexes. 3 zeigt eine Logikpartitionsgruppe A 300 und eine Logikpartitionsgruppe B 302, welche jeweils eine oder mehrere logische Partitionen enthalten. Durch das Zusammenfassen der logischen Partitionen zu Gruppen können die Ressourcen durch Zuweisung (z.B, nach Prioritäten) auf die Partitionen einer Gruppe gemeinsam genutzt werden.
Bei den gemeinsam zu nutzenden Ressourcen handelt es sich zum Beispiel um CPU-Ressourcen, E/A-Ressourcen, um Speicher sowie Coprozessoren oder andere durch die Maschine bereitgestellte gemeinsam zu nutzende Ressourcen. Eine bestimmte LPAR-Gruppe (Logikpartitionsgruppe) kann auf alle oder nur einige Ressourcen einer bestimmten Maschine zugreifen. Mehrere LPAR-Gruppen können tatsächlich so definiert werden, dass sie auf einer bestimmten Maschine gleichzeitig arbeiten. Um jede LPAR-Gruppe wirksam zu verwalten, werden die für eine bestimmte LPAR-Gruppe vorgesehenen Ressourcen speziell dieser Gruppe gewidmet.
Die Überwachung beinhaltet das Ermitteln, welche Ressourcen jeder Gruppe zugewiesen werden können. Insbesondere wird durch die Überwachung definiert, welche Ressourcen nur für diese Gruppe vorgesehen sind und für die Gruppe verwaltet werden können. Die logischen Partitionen, aus denen eine LPAR-Gruppe besteht, lassen sich als Container verstehen, der die Ressourcen enthält. Diese Container liegen innerhalb des Rahmens einer Gesamtmenge von Ressourcen, die den logischen Partitionen zur Verfügung stehen. Bei einem Beispiel ist dies die Gesamtmenge von Ressourcen, die einem bestimmten CPC zur Verfügung stehen.
Den logischen Partitionen, aus denen eine bestimmte LPAR-Gruppe (z.B. die LPAR-Gruppe A) besteht, wird ein bestimmter Anteil der Gesamtheit der gemeinsam zu nutzenden Ressource zugewiesen. Beispielsweise möge die gemeinsam zu nutzende Ressource eine CPU-Ressource sein. Bei gemeinsam genutzten CPU-Ressourcen wird den logischen Partitionen in der LPAR-Gruppe A ein bestimmter Anteil der gesamten CPU-Ressource des Zentralprozessorkomplexes zugewiesen. Diese Ressourcen werden durch die logischen Partitionen innerhalb einer bestimmten Gruppe sowie möglicherweise durch logische Partitionen in anderen LPAR-Gruppen und logische Partitionen gemeinsam genutzt, die in keiner der LPAR-Gruppen enthalten sind. Somit muss ein Workload-Manager, der Entscheidungen zur Umverteilung von Ressourcen innerhalb einer Gruppe (zum Beispiel von einer Partition in der LPAR-Gruppe zu einer anderen Partition in der Gruppe) treffen will, wissen, welche Ressourcen die Gruppe umfasst und was der größere Container (z.B. der CPC) noch enthält. Zum Verständnis der oben erwähnten benutzerdefinierten Container dürfte zum Treffen von Entscheidungen zur Ressourcenverwaltung eine Messwertrückkopplung (z.B. in der Verbindungseinheit gespeicherte Statusinformationen) ausreichen.
Sobald der Workload-Manager diese Kenntnis erlangt hat, ändert er die Zuweisung der Ressourcen auf die logischen Partitionen einer bestimmten Gruppe üblicherweise so, dass die Containergröße (d.h. der Umfang der dieser LPAR-Gruppe zugewiesenen Ressourcen) konstant bleibt. Beispielsweise soll die zu verwaltende Ressource eine CPU-Ressource sein und jeder logischen Partition eine Gewichtung für die CPU-Verarbeitung zugewiesen sein, welche eine Priorität anzeigt. Um die relativen CPU-Gewichtungen zu verwalten, muss die Summe der relativen Gewichtungen für die logischen Partitionen einer bestimmten Gruppe zum Beispiel durch einen Workload-Manager vor und nach der vorgenommenen Änderung konstant gehalten werden. Dadurch wird die durch den Benutzer vorgenommene Zuweisung der Ressourcen zu den Gruppen und anderen logischen Partitionen der Maschine aufrechterhalten.
Ungeachtet dessen kann es in manchen Fällen wünschenswert und möglich sein, dass die Gruppe der Partitionen Ressourcen nutzt, welche den durch den Container definierten Umfang überschreiten, wenn diese Ressourcen durch die ihnen zugewiesenen Benutzer gerade nicht genutzt werden. Wenn es jedoch zu Konflikten über die Ressourcen kommt, werden diese durch den Manager für die logischen Partitionen (LPAR) im Rahmen der definierten Containergröße (hier z.B. entsprechend den festgelegten Verarbeitungsgewichtungen) geregelt. In anderen Fällen hingegen darf die Gruppe möglicherweise nicht über den Umfang ihres Containers hinausgehen. Das kann auch auf die Überwachung zutreffen. Andere Ressourcen müssen möglicherweise bezüglich einer einzelnen Gruppe vollständig überwacht werden, um einen genauen Überblick über die Ressourcenauslastung zu erhalten. Durch eine derartige Begrenzung wird verhindert, dass logische Partitionen außerhalb einer bestimmten Gruppe keinen Zugriff auf diese Ressource erlangen.
Außer dem oben Gesagten werden in die Betrachtungen auch die Auswirkungen äußerer Einwirkungen auf die Verfügbarkeit von Ressourcen innerhalb einer LPAR-Gruppe einbezogen. Zum Beispiel kann ein Benutzer durch bestimmte äußere Mittel (ohne den Workload-Manager) die Ressourcenzuweisung verändern. Das kann erforderlich sein, wenn sich die momentane Arbeitsbelastung in einer Maschine verändert oder sich die Arbeitsprioritäten zwischen Gruppen und/oder anderen logischen Partitionen verschieben. Diese Veränderungen werden durch den Workload-Manager erkannt und müssen durch ihn in vernünftiger Weise umgesetzt werden. Zu Veränderungen kann es kommen, wenn eine logische Partition zu einer Gruppe hinzugefügt oder aus ihr entfernt wird; wenn eine andere logische Partition von außerhalb der Gruppe hinzugefügt oder aus ihr entfernt wird; oder einfach, wenn durch äußere Mittel eine Veränderung der Verarbeitungsgewichtung vorgenommen wird. Wenn diese externen Veränderungen stattfinden, kann sich die Containergröße ändern, sodass der Workload-Manager nun diesen neu dimensionierten Container verwalten muss.
Wenn die einer bestimmten logischen Partition einer Gruppe zugewiesenen Ressourcen von außen verändert werden, kann eine Neuverteilung der Ressourcen innerhalb einer Gruppe erforderlich werden. Wenn zum Beispiel eine logische Partition aus einer Gruppe entfernt wird, wird dieser Gruppe die dieser logischen Partition zugewiesene Verarbeitungsgewichtung entzogen. Wenn die durch den Workload-Manager aktuell zugewiesene Gewichtung der logischen Partition größer ist als die gerade entfernte Gewichtung der logischen Partition (d.h., die anfänglich der logischen Partition zugewiesene Verarbeitungsgewichtung), wird die Gewichtungsdifferenz anderen logischen Partitionen der Gruppe zugewiesen. Das erfolgt zum Beispiel proportional zur vorhandenen Gewichtungsverteilung auf die anderen logischen Partitionen der Gruppe. Wenn die durch den Workload-Manager der logischen Partition aktuell zugewiesene Gewichtung kleiner ist als die anfängliche Gewichtung der logischen Partition, wird die Gewichtungsdifferenz den anderen logischen Partitionen der Gruppe entzogen. Auch dies erfolgt beispielsweise proportional zu den Gewichtungszuweisungen der anderen logischen Partitionen.
Gemäß der obigen Beschreibung wird eine Gruppe überwacht, um einen Überblick über die einer Gruppe zugewiesenen Ressourcen und diejenigen Ressourcen zu erhalten, die verändert werden können, sodass der Workload-Manager anstehende Entscheidungen auf vernünftige Weise treffen kann. Durch die Überwachung werden die Gruppen identifiziert und Informationen zum Programm zurückgeliefert, die durch dieses verarbeitet werden können. Wenn eine Gruppe verändert wird, werden die Ressourcen dynamisch angepasst, um dieser Veränderung Rechnung zu tragen.
Bei einer Ausführungsart kann es für jede Ressource separate Gruppen (Cluster) geben. Zum Beispiel kann die LPAR-Gruppe A zu den CPU-Ressourcen und die LPAR-Gruppe B zu den E/A-Ressourcen gehören. Bei einer anderen Ausführungsart hingegen kann eine LPAR-Gruppe zu einer Untergruppe oder zu allen Ressourcen gehören.
Zur Durchführung der Überwachung der LPAR-Gruppen geben sich die logischen Partitionen als zu einer oder mehreren Partitionsgruppen zugehörig zu erkennen. Eine Ausführungsart der Logik zum Aufnehmen in eine Gruppe wird unter Bezug auf 4a bis 4b beschrieben. Um zum Beispiel eine Partition in eine LPAR-Gruppe aufzunehmen, zeigt das in einer logischen Partition laufende Betriebssystem (z.B. OS/390) dem LPAR-Manager an, in welche LPAR-Gruppe diese logische Partition aufgenommen werden soll (SCHRITT 400). Zum Beispiel wird der Name der LPAR-Gruppe dem LPAR-Manager mittels einer Anweisung mitgeteilt. Das Betriebssystem gibt für jede Ressourcenart einen Namen an, die innerhalb der LPAR-Gruppen verwaltet werden soll. Wenn es noch andere Ressourcen gibt (ANFRAGE 402), werden daher andere Namen angegeben. Zum Beispiel wird für die CPU-Ressourcen ein Gruppenname und für die E/A- Ressourcen ein anderer Name mitgeteilt. Wenn dies gewünscht wird, kann für jede Ressourcenart derselbe Name der LPAR-Gruppe angegeben werden.
Aufgrund dieser Erklärung durch das Betriebssystem OS/390 wird in der Maschine entweder eine neue LPAR-Gruppe eingerichtet (wenn die logische Partition diesen Namen als erste logische Partition verwendet), oder diese logische Partition wird in eine vorhandene LPAR-Gruppe mit demselben Namen für diese Ressourcenart aufgenommen. Wenn der Gruppenname angegeben wird (SCHRITT 404) (4b), wird zum Beispiel geprüft, ob es sich um einen neuen Namen handelt (ANFRAGE 406). wenn dies der Fall ist, wird eine neue Gruppe erzeugt, SCHRITT 408. Ansonsten wird in SCHRITT 410 die logische Partition in eine bereits vorhandene Gruppe aufgenommen. Anschließend werden in SCHRITT 412 die Ressourcen der Gruppe zugeordnet.
Insbesondere werden nun die mit der LPAR-Gruppe verknüpften Ressourcen mit dem Gruppentyp dieser logischen Partition zur Nutzung freigegeben, wenn der in der LPAR-Gruppe laufende WLM zu diesem Ergebnis kommt. Mindestens zwei Ressourcenarten für eine LPAR-Gruppe müssen überwacht werden: additive und fest installierte Ressourcen.
Additive Ressourcen: In manchen Fällen werden durch die Aufnahme einer logischen Partition auch Ressourcen zur LPAR-Gruppe hinzugefügt. Ein Beispiel hierfür ist die CPU-Verarbeitungsgewichtung, welche beispielsweise einer logischen Partition durch den Benutzer an einer Hardwarekonsole zugewiesen wurde. Die aktuelle (gerade verwendete) Verarbeitungsgewichtung der logischen Partition wird mit dieser durch den Benutzer zugewiesenen Gewichtung initialisiert, wenn die logische Partition aktiviert wird. Wenn die logische Partition in eine LPAR-Gruppe für CPU-Ressourcen aufgenommen wird, wird die durch den Benutzer der logischen Partition zugewiesene Verarbeitungsgewichtung Teil der gesamten Verarbeitungsgewichtung, welche innerhalb der gesamten LPAR-Gruppe verfügbar ist, und kann somit durch den WLM innerhalb der LPAR-Gruppe neu zugewiesen werden. Die soeben in die LPRR-Gruppe aufgenommene logische Partition verfügt nun über die Möglichkeit, das größere Angebot an Ressourcen der LPAR-Gruppe zu nutzen, die gerade erweitert wurde.
Fest installierte Ressourcen: In manchen Fällen wird eine Gruppe von Ressourcen definiert, die zu einer bestimmten LPAR-Gruppe gehören. Ein Beispiel hierfür sind verwaltete (variable) Kanalpfade. Bei einem verwalteten Kanalpfad können die Ressourcen neu verteilt werden, um die Zielwerte der Arbeitsbelastung zu erreichen. Die Gruppe der einer bestimmten LPAR-Gruppe zur Verfügung stehenden verwalteten Kanalpfade wird zu Anfang mittels eines E/A-Konfigurationsdefinitionsprozesses definiert, welcher die Kanalpfade (CHPIDs) einer LPAR-Gruppe zuordnet. Wenn eine logische Partition in diese LPAR-Gruppe aufgenommen wird, darf sie nun auf diese Gruppe von Kanalpfaden zugreifen. Die logische Partition selbst hat zu diesem Ressourcenpool in keiner Weise beigetragen. (Dieser Ressourcenpool kann zwar immer noch dynamisch verändert werden, ausschlaggebend ist aber, dass die Ressourcen nicht in dem Maße kommen und gehen, wie die logischen Partitionen in eine LPAR-Gruppe aufgenommen werden oder diese verlassen.) Die logischen Partitionen können je nach Ressourcenart auch unterschiedlich intensiv überwacht werden.
Additive Ressourcen: Das Betriebssystem in einer LPAR-Gruppe muss in der Lage sein, die ganze Ressourcengruppe dieser Art für die LPAR-Gruppe abzufragen. Bei CPU-Verarbeitungsgewichtungen erfolgt dies beispielsweise durch eine Anweisung. Das Betriebssystem erlangt Kenntnis über die gesamte Gruppe dieser Ressourcenart innerhalb der LPAR-Gruppe, die Zuweisung der Ressourcen zu den logischen Partitionen in der Gruppe und die Gesamtgröße des in der betreffenden Maschine verfügbaren Ressourcenpools. Anhand all dieser Komponenten wird festgelegt, welcher Anteil an der gesamten physischen Ressource einer logischen Partition zugewiesen werden kann. Dann aktualisiert das Betriebssystem die Zuweisungen zu den logischen Partitionen in der LPAR-Gruppe, um die Ressourcen innerhalb der Gruppe neu zu verteilen. Bei einem Beispiel darf das Betriebssystem den Gesamtumfang der der LPAR-Gruppe zugewiesenen Ressource nicht verändern. Der Logikpartitionsmanager unterstützt dies, indem er sicherstellt, dass alle Teile der LPAR-Gruppe bei einer Aktualisierung berücksichtigt und die Ressourcen keiner der logischen Partitionen außerhalb der LPAR-Gruppe betroffen werden.
Fest installierte Ressourcen: Das Betriebssystem in einer LPAR-Gruppe fragt die Ressourcen ab, welche der LPAR-Gruppe für diese Ressourcenart zugeordnet sind. Bei verwalteten Kanalpfaden beispielsweise kann durch eine Anweisung eine Liste der für eine bestimmte LPAR-Gruppe definierten verwalteten Kanalpfade vom Logikpartitionsmanager abgerufen werden. Der Logikpartitionsmanager überprüft diese Ressourcen auch, um sicherzustellen, dass diese nur durch die richtige LPAR-Gruppe genutzt werden. Bei verwalteten Kanalpfaden bedeutet dies, dass ein verwalteter Kanalpfad online nur für eine logische Partition konfiguriert werden kann, welche für die LPAR-Gruppe einen Namen angegeben hat, der mit dem für den verwalteten Kanalpfad definierten Namen übereinstimmt.
Wenn bei einer logischen Partition als Bestandteil einer LPAR-Gruppe ein Systemreset (Zurücksetzen), ein Neustart oder eine Deaktivierung erfolgt, gehen alle Verknüpfungen dieser logischen Partition mit einer oder mehreren LPAR-Gruppen verloren. Eine Ausführungsart der Logik zum Entfernen einer logischen Partition aus einer Gruppe wird unter Bezug auf 5 beschrieben. Als Teil des Zurücksetzens entfernt der Logikpartitionsmanager in SCHRITT 500 einen angegebenen Namen der LPAR-Gruppe aus der logischen Partition. Dann erfolgen ein oder mehrere Schritte, um je nach der Ressource (ANFRAGE 502) die Zurücknahme der Ressourcenzuweisung der LPAR-Gruppe für die logische Partition abzuschließen.
Wenn es sich um eine additive Ressource handelt, passiert Folgendes: solche Ressourcen, die bei Aufnahme einer logischen Partition in die LPAR-Gruppe zu dieser Partition hinzugekommen sind, werden in SCHRITT 504 wieder entfernt. Dazu kann eine Anpassung der aktuellen Zuweisung dieser Ressourcenart zu den restlichen Gliedern der LPAR-Gruppe gehören. Beim Fall der Verarbeitungsgewichtungen wird zum Beispiel die anfängliche Verarbeitungsgewichtung der aus der Gruppe ausscheidenden logischen Partition aus der Überwachung der LPAR-Gruppe herausgenommen. Wenn der WLM die aktuelle Verarbeitungsgewichtung der logischen Partition verändert hatte, müssen Anpassungen vorgenommen werden. Wenn die aktuelle Verarbeitungsgewichtung der logischen Partition größer ist als ihre anfängliche Verarbeitungsgewichtung, wird die Differenz zwischen beiden auf die restlichen Glieder der LPAR-Gruppe proportional zu ihren aktuellen Verarbeitungsgewichtungen verteilt. Wenn die Verarbeitungsgewichtung der logischen Partition kleiner ist als ihre anfängliche Verarbeitungsgewichtung, wird die Differenz zwischen beiden von den restlichen Gliedern der LPAR-Gruppe proportional zu ihren aktuellen Verarbeitungsgewichtungen abgezogen. Im Ergebnis dieser Anpassungen ist der Container mit den Verarbeitungsgewichtungen für die entstandene LPAR-Gruppe wiederhergestellt.
Wenn es sich hingegen um eine fest installierte Ressource handelt, passiert Folgendes: solche Ressourcen werden einfach durch Zurücksetzen in SCHRITT 506 aus der Konfiguration der logischen Partition entfernt. Verwaltete Kanalpfade werden zum Beispiel durch Zurücksetzen aus der Konfiguration der logischen Partition entfernt. Auch hier wird durch die Wiederherstellung erreicht, dass nur noch die Glieder der LPAR-Gruppe Zugriff auf die Ressource dieser Gruppe haben.
Dabei ist anzumerken, dass bei manchen durch den WLM verwalteten Ressourcen einer LPAR-Gruppen-Umgebung keine Gruppenüberwachung erforderlich ist. Ein Beispiel hierfür ist die Anzahl der logischen Zentralprozessoren (CP), die mit einer logischen Partition online sind. Das tatsächliche Verhalten einer einzelnen logischen Partition in einer LPAR- Gruppe kann durch die Anzahl der logischen CPs deutlich beeinflusst werden, die mit der logischen Partition online sind. Die Anzahl der logischen CPs, welche eine logische Partition definiert und/oder online haben kann, stellt ein Merkmal einer logischen Partition dafür dar, ob sie Bestandteil einer LPAR-Gruppe ist, sodass diese Ressource nicht wirklich Teil eines größeren Ressourcenbestands wird. In einer LPAR-Gruppe wirkt sie sich jedoch so aus, dass sie die Art der tatsächlich in einem Glied der LPAR-Gruppe laufenden Arbeitsbelastung gegenüber einem anderen Glied der Gruppe ändern kann.
Bei einem Beispiel stellt eine CPU-Ressource eine gemeinsam zwischen einer Vielzahl von logischen Partitionen zu nutzende Ressource dar. Der Workload-Manager des Betriebssystems OS/390 verteilt die CPU-Ressourcen durch dynamisches Anpassen einer oder mehrerer den logischen Partitionen zugeordneter relativer Prozessorgewichtungen neu auf die logischen Partitionen. Der WLM erfährt, ob eine wichtige Arbeit verzögert wird, weil die Gewichtung der Partition, in welcher diese Arbeit läuft, zu gering ist. Der WLM kann diese Arbeit unterstützen, indem er die Gewichtung dieser Partition erhöht und die Gewichtung einer anderen Partition verringert und so der wichtigen Arbeit zusätzliche CPU-Kapazität zukommen lässt. Die CPU-Ressourcen werden bei veränderten Anforderungen an die Arbeitsbelastung dynamisch zu den Partitionen verlagert, an denen sie benötigt werden.
Bei einer Ausführungsart umfasst der Verwaltungsbereich des WLM für die Gewichtungen der logischen Partitionen eine Gruppe von logischen Partitionen. Zum Beispiel passt der WLM die Gewichtungen der logischen Partitionen an und lässt dabei die Summe der Gewichtungen der Partitionen in der Gruppe konstant. Durch dieses Konstanthalten der Summe der Gewichtungen bleiben die dieser Gruppe insgesamt zugewiesenen CPU-Ressourcen gegenüber den anderen unabhängigen Gruppen in demselben physischen Rechner unverändert. Wenn also der WLM die Gewichtung einer Partition erhöht, verringert er die Gewichtung einer anderen Partition in derselben Gruppe.
Die Verwaltung der Gewichtungen der logischen Partitionen stellt eine Verbesserung der auf die Zielwerte ausgerichteten Ressourcenzuweisungsverfahren durch den WLM dar, die zum Beispiel in den US-Patentschriften 5 473 773 vom 5. Dezember 1995 und 5 675 739 vom 7. Oktober 1997 beschrieben werden.
In diesen Patentschriften wird beschrieben, wie der WLM die Zuweisung von CPU-Ressourcen innerhalb einer logischen Partition durch Anpassung der CPU-Zuweisungsprioritäten steuert. Die CPU-Zuweisungsprioritäten werden so zugeteilt, dass sie auf Betriebsklassenebene wirksam werden. Es gibt jedoch zahlreiche Situationen, in denen die Anpassung der Zuweisungsprioritäten für die Betriebsklasse nicht hilfreich ist. Zum Beispiel:

1) Die Betriebsklasse hat bereits allein die für systemfremde Arbeiten höchstzulässige CPU-Zuweisungspriorität.
2) Die Veränderung der CPU-Zuweisungsprioritäten zur Unterstützung der Betriebsklasse wirkt sich zu nachteilig auf andere Betriebsklassen auf, deren Wichtigkeit gleich oder höher ist.

Wenn also der WLM erkennt, dass eine Betriebsklasse ihre Zielwerte infolge einer CPU-Verzögerung nicht erreicht und dies durch Anpassung der CPU-Prioritäten nicht behoben werden kann, passt er die Gewichtung der Partition mit der verzögerten Betriebsklasse an.
Diejenige Betriebsklasse, welcher der WLM zusätzliche Ressourcen zuweisen will, wird als Empfänger-Betriebsklasse bezeichnet. Wenn der WLM in einer bestimmten Partition eine Empfänger-Betriebsklasse gefunden hat, deren Zielwerte infolge einer CPU-Verzögerung nicht erfüllt werden, und dies aus einem der oben angegebenen Gründe nicht behoben werden kann, erhöht der WLM die Gewichtung der Partition. Im Folgenden wird unter Bezug auf 6 eine Ausführungsart der Logik beschrieben, durch welche der WLM ermittelt, ob die Gewichtung einer Partition erhöht werden kann, um die Empfänger-Betriebsklasse zu unterstützen:

1. Die Auswirkung der Erhöhung der Gewichtung der Partition auf die Empfänger-Betriebsklasse wird in SCHRITT 600 abgeschätzt. Durch die Erhöhung der Gewichtung der Partition wird die CPU-Kapazität der Partition erhöht. Da der CPU-Bedarf der Arbeit in der Empfänger-Betriebsklasse als konstant angenommen wird, verringert sich durch die Erhöhung der prozentuale Anteil der durch die Empfänger-Betriebsklasse angeforderten Kapazität an der CPU-Kapazität der Partition. Die Abschätzung des Nutzens für die Empfänger-Betriebsklasse beruht auf dieser Verringerung des prozentualen Anteils der verfügbaren CPU-Kapazität sowohl der Empfänger-Betriebsklasse als auch der anderen Arbeiten am Systembedarf.
2. In SCHRITT 602 wird eine andere Partition in der Gruppe der logischen Partitionen gesucht, deren Gewichtung verringert werden kann. Diese Partition ist unter der Bezeichnung potenzielle Geberpartition bekannt. Die potenzielle Geberpartition wird durch Suchen nach derjenigen Partition ermittelt, bei der durch die Verringerung der Gewichtung der Partition aller Wahrscheinlichkeit nach die Arbeit mit der geringsten Wichtigkeit betroffen wird.
3. In SCHRITT 604 wird die Auswirkung der Verringerung der Gewichtung der potenziellen Geberpartition auf alle in dieser Partition laufenden Betriebsklassen abgeschätzt. Durch die Verringerung der Gewichtung der potenziellen Geberpartition wird die CPU-Kapazität dieser Partition verringert. Diese Verringerung der CPU-Kapazität führt dazu, dass der prozentuale Anteil des CPU-Bedarfs der Betriebsklassen der in der potenziellen Geberpartition laufenden Arbeit an der Gesamtkapazität der potenziellen Geberpartition zunimmt. Die Abschätzung der negativen Auswirkung der Verringerung der Gewichtung der potenziellen Geberpartition beruht auf diesem prozentualen Anstieg der Anforderung dieser Betriebsklassen an der verfügbaren CPU-Kapazität.
4. In ANFRAGE 606 wird ermittelt, ob diese Gewichtungsänderung zu einem Nettoergebnis führt. Das heißt, der Nutzen für die Empfänger-Betriebsklasse kompensiert die negative Auswirkung auf die Arbeit in der potenziellen Geberpartition, gemessen an den Zielwerten und der Wichtigkeit der betreffenden Betriebsklassen.
5. Wenn die Anpassung der Gewichtungen einen Nettowert ergibt, wird die vorgeschlagene Änderung an den Gewichtungen der Partition in SCHRITT 608 durchgeführt. Wenn sich kein Nettowert ergibt, wird in ANFRAGE 610 ermittelt, ob es noch andere potenzielle Geberpartitionen gibt. Wenn dies der Fall ist, wird in SCHRITT 612 eine andere potenzielle Geberpartition ausgewählt und die Verarbeitung unter Punkt 3 mit SCHRITT 604 fortgesetzt. Wenn es keine weiteren potenziellen Geberpartitionen mehr gibt, endet die Verarbeitung in SCHRITT 614.

Damit der WLM in einer Partition laufen kann, um eine Abschätzung der Auswirkung der veränderten Gewichtungen einer Partition auf eine in einer anderen Partition laufende Arbeit durchzuführen, kann jede Partition auf eine gemeinsam genutzte Datenstruktur zugreifen, welche Leistungsdaten zu jeder logischen Partition in der Gruppe enthält. Zu diesen Leistungsdaten auf Partitionsebene gehören zum Beispiel:

CPU-Anforderungen der in der Partition laufenden Arbeit je Betriebsklasse;
wie gut jede Betriebsklasse ihre Zielwerte in der Partition erreicht;
CPU-Auslastung entsprechend der CPU-Zuweisungspriorität der Partition.

Bei einer bevorzugten Ausführungsart der vorliegenden in einem Betriebssystem OS/390 umgesetzten Erfindung wird die gemeinsam genutzte Datenstruktur in einer Verbindungseinheit geschaffen und unterhalten. Zur Realisierung dieser Datenstruktur können jedoch auch andere Lösungsansätze zur gemeinsamen Datennutzung wie zum Beispiel die Übermittlung von Nachrichten oder eine gemeinsam genutzte Datenplatte genutzt werden.
Oben wurde eine Einrichtung zur dynamischen Umverteilung von CPU-Ressourcen in einer Rechnerumgebung beschrieben. Die Ressourcen werden gemäß einem Beispiel durch dynamische Anpassung der Gewichtungen der logischen Partitionen auf alle logischen Partitionen verteilt.
Nicht nur die CPU-Ressourcen einer Rechnerumgebung, sondern auch die Ressourcen logischer Prozessoren können dynamisch angepasst werden.
Eine logische Partition ist mit einem oder mehreren logischen Prozessoren konfiguriert, die in den physischen Zentraleinheiten der Zentralprozessorkomplexe zur Ausführung der Arbeit eingesetzt werden. Damit eine Partition die ihr zugewiesene CPU-Kapazität in Anspruch nehmen kann, müssen für diese logische Partition ausreichend logische Prozessoren konfiguriert werden. Beispielsweise soll der Fall einer logischen Partition A betrachtet werden, die in einem CPC mit zehn CPUs läuft. Wenn ein Workload-Manager der logischen Partition A 50 % der CPC-Kapazität zuweist, müssen für diese logische Partition A mindestens fünf logische Prozessoren konfiguriert werden. (Fünf logische Prozessoren könnten auf fünf der CPUs oder 50 % der CPC-Kapazität laufen.) Wenn der logischen Partition A später 95 % der CPC-Kapazität zugewiesen würden, dann würden für sie zehn logische Prozessoren konfiguriert. Da der WLM die der logischen Partition A mit einer statisch definierten Konfiguration von logischen Prozessoren zugewiesene Kapazität dynamisch anpassen kann, werden für die logische Partition A zehn logische Prozessoren konfiguriert, um alle möglichen Kapazitätszuweisungen zu befriedigen. Wenn der logischen Partition A jedoch beispielsweise nur 20 % der CPC-Kapazität zugewiesen würde, käme es wegen der statisch definierten logischen Prozessoren zu zwei Problemen: 1) Im Durchschnitt darf jeder der zehn logischen Prozessoren die physischen CPU-Ressourcen zu einem Anteil von lediglich 0,2 der Kapazität einer physischen CPU (20 % von zehn CPUs, geteilt durch zehn logischen Prozessoren ergibt 0,2 CPUs je logischem Prozessor) auslasten. Das kann zu einer ernsthaften Einschränkung der Arbeitsbelastungen führen, deren Durchsatz durch eine einzelne Task eingesteuert wird, da diese einzelne Task nur mit 0,2 der Kapazität der physischen CPU arbeiten kann – das wird oft als Maschinenengpass (Maschinendrosseleffekt) bezeichnet; 2) Der Wirkungsgrad von Software und Hardware geht stark zurück, wenn zehn logische Prozessoren verwaltet werden müssen, obwohl nur zwei logische Prozessoren benötigt werden.
Zur Behebung der oben genannten Mängel wird die Konfiguration einer logischen Partition nicht statisch definiert, sondern dynamisch angepasst. Bei einem Beispiel verwaltet der WLM die Partition und nimmt die dynamische Anpassung vor. Der WLM kann dies für jede logische Partition einer Rechnerumgebung (oder innerhalb einer LPAR-Gruppe) erledigen. Eine Ausführungsart der Logik zur dynamischen Anpassung der Konfiguration von logischen Prozessoren wird unter Bezug auf 7 beschrieben.
Zu Anfang wird in SCHRITT 700 für eine logische Partition eine Mindestanzahl von logischen Prozessoren konfiguriert, die zum Auslasten der durch den Workload-Manager der logischen Partition zugewiesenen Kapazität (oder der im Augenblick in Anspruch genommenen Kapazität, wenn diese größer ist) erforderlich ist. Da die Kapazitätszuweisung (oder die in Anspruch genommene Kapazität) veränderlich ist, wird durch die ANFRAGE 702 geprüft, ob die Anzahl der für die logische Partition konfigurierten logischen Prozessoren geändert werden soll (SCHRITT 704). Bei einem Beispiel bleibt die Anzahl der für eine logische Partition konfigurierten logischen Prozessoren etwa bei der Anzahl der physischen CPUs, die zum Bereitstellen der einer logischen Partition zugewiesenen (oder von ihr in Anspruch genommenen) CPC-Kapazität erforderlich ist. Somit arbeitet jeder logische Prozessor etwa bei der Kapazität einer physischen CPU, und es brauchen nicht mehr logische Prozessoren als nötig verwaltet zu werden.
Zur Prüfung, ob die logische Konfiguration geändert werden muss, dient bei einem Beispiel in SCHRITT 705 die folgende Gleichung:
L = Basis[max(W,U) × P +1,5] mit einem Maximum von L = P, wobei L = Anzahl der für eine logische Partition konfigurierten logischen Prozessoren; W = der der logischen Partition zugewiesene prozentuale Anteil der CPC-Kapazität; U = der im Augenblick durch die logische Partition in Anspruch genommene prozentuale Anteil der CPC-Kapazität; und P = die Anzahl der physischen CPUs eines CPC ist.
Der Wert L wird durch den Workload-Manager in beispielsweise regelmäßigen und kurzen Intervallen (z.B. alle 10 Sekunden) auf der Grundlage der gerade gültigen Werte von P, W und U ermittelt. Zur Ermittlung, ob der aktuelle Wert von L (L-act) für die logische Partition erhöht oder verringert werden soll, werden Schwellenwerte verwendet. Wenn der neu berechnete Wert von L (L-calc) in ANFRAGE 706 größer als der aktuelle Wert von L-act ist, wird L-act in SCHRITT 708 auf L-calc angehoben. Wenn hingegen L-calc in ANFRAGE 710 um mindestens zwei kleiner als L-act ist, wird L-act in SCHRITT 712 gleich L-calc minus eins gesetzt. Wenn L-calc gleich oder nur um eins kleiner als L-act ist, bleibt in SCHRITT 714 der Wert L-act für die logische Partition unverändert. Durch Anwendung dieser Schwellenwerte werden unnötige Änderungen des Wertes L-act infolge geringfügiger Schwankungen der Arbeitsbelastung vermieden, wobei das System trotzdem schnell auf Anforderungen seitens der Arbeitsbelastungen nach Kapazitätserhöhung reagieren kann.
Zur weiteren Veranschaulichung soll das folgende Beispiel dienen: Angenommen, es seien P = 10 und W = U 24 %. Für den Fall, dass W über 90 % ansteigen sollte, würde eine statische Konfiguration der logischen Prozessoren einen Wert von L(statisch) = 10 erfordern. Bei einer bevorzugten Ausführungsart der vorliegenden Erfindung ist jedoch L(dynamisch) = Basis[max(0,24, 0,24) × 10 + 1,5] = 3. Bei diesem Beispiel würde also der Wert L(statisch) eine Einzeltask auf lediglich 0,24 einer physischen CPU beschränken, während der Wert L(dynamisch) einer Einzeltask die Auslastung einer physischen CPU zu 0,80 gestatten und somit eine Erhöhung des Durchsatzes für Arbeitsbelastungen einer Einzeltask um 233 % bewirken würde. Außerdem wird die Leistung der Software und der Hardware deutlich gesteigert, da anstelle der für L(statisch) erforderlichen zehn logischen Prozessoren nur drei logische Prozessoren verwaltet werden müssen.
Eine andere zu verwaltende gemeinsam zu nutzende Ressource einer Rechnerumgebung ist eine asynchrone Ressource wie z.B. eine E/A-Ressource. Insbesondere sollen E/A-Operationen oder – Anforderungen in einem Coprozessor (z.B. einem Kanal-Teilsystem) verwaltet werden. Diese Verwaltung beinhaltet die Zuordnung von Prioritäten zu den E/A-Operationen, sodass E/A-Operationen mit einer höheren Priorität schneller abgearbeitet und/oder diesen E/A-Operationen eine größere Bandbreite des Kanals zugewiesen wird.
In großen modernen Mehrprogramm-Rechnersystemen erfolgen das Starten und die Ausführung lange andauernder Prozesse wie beispielsweise E/A-Operationen zum Lesen, Schreiben und Steuern angeschlossener E/A-Einheiten üblicherweise mittels verschiedener unabhängig voneinander arbeitender Rechenelemente (siehe 8). Zum Beispiel kann ein in einem Zentralprozessor 800 ausgeführtes Programm eine E/A-Operation mit einer angeschlossenen Einheit 804 anfordern; das eigentliche Starten und Ausführen der E/A-Operation mit der angeschlossenen Einheit wird jedoch durch einen oder mehrere separate und unabhängig voneinander gemeinsam arbeitender Prozessoren durchgeführt, die normalerweise als Kanal-Teilsystem 802 bezeichnet werden. Die Methodik der asynchronen E/A-Verarbeitung dient im Allgemeinen dazu, den Zentralprozessor zu optimieren und parallel zum Betrieb der relativ lange laufenden E/A-Einheiten wirksam einzusetzen. Das heißt, der Gesamtaufwand an Prozessorleistung, die Verarbeitungsdauer und die Prozessorwartezeit, welche ansonsten für den Zugriff und das Lesen/Schreiben auf die angeschlossenen E/A-Einheiten erforderlich wären, sollen möglichst stark verringert werden. Eine solche Vorgehensweise soll zu einer möglichst großen Überlappung bzw. Gleichzeitigkeit der Ausführung von E/A-Operationen während der Arbeit anderer Prozessoren in einem großen Mehrprogrammsystem führen.
Bei solchen asynchronen E/A-Verarbeitungssystemen löst der Zentralprozessor mittels einer E/A-Anweisung wie beispielsweise der S/390-Anweisung START SUBCHANNEL die Ausführung einer durch ein Programm angeforderten E/A-Operation aus. Eine solche Anweisung ist normalerweise zuständig für:

1. Einstellen (Hinzufügen) der Anforderung für eine E/A-Operation in eine E/A-Arbeitswarteschlange des Kanal-Teilsystems; und
2. ein Signal an das asynchron arbeitende Kanal-Teilsystem senden, damit die E/A-Arbeitswarteschlange abgearbeitet wird.

Daraufhin ist der Zentralprozessor hiervon entlastet und kann andere Arbeiten/Anweisungen ausführen und ist nicht mehr direkt mit der eigentlichen Ausführung der angeforderten E/A-Operationen mit der E/A-Einheit befasst.
Aufgrund 1) der asynchronen Natur dieses Prozesses, 2) der voneinander unabhängigen Arbeitsweise des Zentralprozessors und der Prozessoren des Kanal-Teilsystems, 3) der im Vergleich zur Verarbeitungsgeschwindigkeit der Zentralprozessoren relativ zeitaufwendigen E/A-Operationen und 4) der Tatsache, dass einige oder alle Ressourcen des Kanal-Teilsystems wie beispielsweise die Kanalpfade zwischen der Einheit und dem Kanal-Teilsystem gerade durch andere Operationen ausgelastet sein können, wenn durch ein Programm eine E/A-Operation angefordert wird, besteht eine hohe Wahrscheinlichkeit dafür, dass mehrere E/A-Anforderungen gleichzeitig in die E/A-Arbeitswarteschlange des Kanal-Teilsystems eingestellt werden. Das heißt, die Anweisung START SUBCHANNEL wird durch die Zentralprozessoren mit einer höheren Geschwindigkeit ausgeführt als das Kanal-Teilsystem in der Lage ist, die angeforderten E/A-Operationen auszuführen, sodass ständig lange E/A-Arbeitswarteschlangen auf N-Ebene mit anstehenden E/A-Operationsanforderungen entstehen.
Um die anstehenden E/A-Anforderungen abzuarbeiten, durchsuchen die das Kanal-Teilsystem umfassenden Mikroprozessoren die zu ihnen gehörenden E/A-Arbeitswarteschlangen (siehe 8), holen eine oder mehrere E/A-Anforderungen aus diesen Warteschlangen und versuchen, diese aus den Warteschlangen geholten E/A-Anforderungen für ihre jeweiligen E/A-Einheiten zu initialisieren. Diese Aktivität wird durch den jeweiligen Mikroprozessor und die zugehörigen Arbeitswartschlangen im Kanal-Teilsystem ausgelöst. Der mit dem Zentralprozessor zusammenarbeitende E/A-Prozessor des Kanal-Teilsystems könnte diesen Prozess zum Beispiel periodisch starten, wenn er nicht durch andere Aufgaben ausgelastet ist bzw. als Reaktion auf ein oder mehrere Signale START SUBCHANNEL vom Zentralprozessor oder als Kombination von beiden.
Unter Bezug auf 8 wird ein Beispiel der unterschiedlichen Arbeitswarteschlangen eines Kanal-Teilsystems beschrieben. Die E/A-Anforderungen werden, wie oben erwähnt, zum Beispiel durch die Anweisung START SUBCHANNEL in eine E/A-Prozessorarbeitswarteschlange 806 eingestellt. Dann werden die E/A-Anforderungen durch einen E/A-Prozessor 808 aus der E/A-Prozessorarbeitswarteschlange geholt. Die aus der Warteschlange geholten Anforderungen werden durch den E/A-Prozessor in eine Kanalprozessor-Arbeitswarteschlange 810 eingestellt. Anschließend werden diese Anforderungen durch einen Kanalprozessor 812 aus der Warteschlange geholt und in eine Steuereinheit-Warteschlange 814 eingestellt. Dann holt der Kanalprozessor die Anforderungen aus der Steuereinheit-Warteschlange und sendet sie über den Kanalpfad zur Steuereinheit und schließlich zur E/A-Einheit.
Innerhalb der Produktfamilie der S/390-Systeme erfolgen die Prozesse des Entnehmens aus der Warteschlange des Kanal-Teilsystems und des Ausführungsstarts gegenwärtig auf FIFO-Basis (First-In, First-Out). Dieser Prozess lässt sich logisch am einfachsten realisieren, er soll den Datendurchsatz optimieren und hat sich in der Vergangenheit als eine geeignete Strategie zur Aufgabenverteilung zwischen den verschiedenen asynchronen Verarbeitungselementen erwiesen, solange die mittlere Länge der Warteschlangen mit anstehenden Aufgaben relativ klein und die Wartezeit der E/A-Aufgaben relativ kurz bleibt (d.h., dass die mittlere Anzahl der anstehenden E/A-Anforderungen in den diversen E/A-Arbeitswarteschlangen keine wesentliche Verlängerung der gesamten E/A-Reaktionszeit der E/A-Operationen für besonders wichtige und/oder kritische Echtzeitprogrammen bewirkt).
Bei Betriebssystemen hingegen, welche Prioritätsfunktionen für Anwendungen/Programme bieten, um Benutzeranforderungen zur möglichst schnellen Verarbeitung von kritischen oder zeitabhängigen Arbeitsaufgaben zu unterstützen, erweist sich eine FIFO-Strategie zur Verarbeitung anstehender E/A-Anforderungen in dem Maße immer weniger als vorteilhaft, wie die mittlere Länge der FIFO-Arbeitswarteschlangen zunimmt. Zum Beispiel wird die mittlere Länge der Warteschlangen im Kanal-Teilsystem durch parallele Zugriffsvolumina in Verbindung mit dem IBM Enterprise Storage Server vergrößert. Das ist typisch, da E/A-Anforderungen mit geringerer Wichtigkeit oder weniger zeitkritische E/A-Anforderungen vor wichtigeren Anforderungen in die FIFO-Arbeitswarteschlangen eingestellt und deshalb vor diesen kritischeren E/A-Anforderungen gestartet würden. Es kommt oft vor, dass weniger kritische Arbeitsaufgaben E/A-Operationen ausführen, welche die Ressourcen für längere Zeit beschäftigen und die wichtigeren Arbeitsaufgaben stärker verzögern. Das führt üblicherweise zu einer erhöhten Wahrscheinlichkeit für die Verzögerung der wichtigeren E/A-Anforderungen.
Eine verlängerte Verzögerungszeit, die auch als E/A-Wartezeit bezeichnet wird (bei der es sich entweder um eine Gesamtverzögerung in Echtzeit handeln kann oder um eine im Vergleich zur Geschwindigkeit des Zentralprozessors relative Verzögerung), ist oft darauf zurückzuführen, dass das Kanal-Teilsystem und die angeschlossenen Einheiten nicht in der Lage sind, eine E/A-Ausführungsgeschwindigkeit aufrechtzuerhalten, welche die rechtzeitige Beendigung der kritischen E/A-Anforderungen nicht beeinträchtigt (anders ausgedrückt, das Unvermögen, eine Ausführungsgeschwindigkeit aufrechtzuerhalten, die nicht zu einer unannehmbaren Verlängerung der Ausführungszeit von Programmen führt, die besonders wichtig bzw. zeitkritisch sind). Die Wahrscheinlichkeit einer unannehmbaren Verlängerung der E/A- Gesamtreaktionszeit für kritische E/A-Anforderungen nimmt im Allgemeinen wie oben erwähnt zu, wenn eine FIFO-Strategie angewendet wird. Diese Wahrscheinlichkeit einer Verzögerung steigt weiter an, wenn die Geschwindigkeit und die Anzahl der Zentralprozessoren noch stärker zunimmt als die Geschwindigkeit der angeschlossenen E/A-Einheiten und anderer erforderlicher Elemente des Kanal-Teilsystems wie beispielsweise der Kanalpfade, über welche diese Einheiten angeschlossen sind. Allgemein nimmt diese Diskrepanz der Geschwindigkeitserhöhung zwischen dem Zentralprozessor und den E/A-Einheiten bei modernen Großrechnersystemen immer mehr zu und führt zu einer immer höheren Wahrscheinlichkeit für Warteschlangenverzögerungen und längeren E/A-Wartezeiten (entweder Echtzeit oder Relativzeit) für kritische Arbeitsaufgaben.
Um zum Beispiel durch Warteschlangenverzögerungen im Kanal-Teilsystem bedingte längere E/A-Reaktionszeiten für besonders wichtige und zeitkritische E/A-Operationen möglichst zu vermeiden, wird zur Verarbeitung einer oder mehrerer anstehender E/A-Arbeitswarteschlangen im Kanal-Teilsystem ein auf Prioritäten beruhendes Verfahren definiert.
Folgende Beispiele betreffen die Realisierung eines auf Prioritäten beruhenden Verarbeitungsverfahrens zwischen zwei unabhängig voneinander arbeitenden Prozessoren oder Prozessen:

1. Ein Warteschlangenprozessor (oder -prozess) stellt mittels eines Prioritätssequenzierungsverfahrens, das auf einer durch ein Programm (z.B. durch den WLM) angegebenen Prioritätszahl beruht, E/A-Anforderungen in eine E/A-Arbeitswarteschlange des Kanal- Teilsystems ein (wobei die jeweilige Warteschlange von der Verarbeitungsstufe abhängt). Anschließend holt das Kanal-Teilsystem mittels eines FIFO-Verfahrens die erste E/A-Anforderung mit der höchsten Priorität aus der Arbeitswarteschlange; oder
2. ein Warteschlangenprozessor (oder -prozess) stellt E/A-Anforderungen mittels eines FIFO-Warteschlangenverfahrens an das Ende der E/A-Arbeitswarteschlange. Anschließend durchsucht das Kanal-Teilsystem mittels eines Prioritätsauswahlverfahrens alle E/A-Anforderungselemente in der Arbeitswarteschlange und holt die E/A-Anforderung mit der höchsten durch das Programm festgelegten Prioritätszahl aus der Warteschlange und verarbeitet sie.

Das FIFO-Warteschlangenverfahren (Verfahren Nr. 2) benötigt weniger Anweisungen und ermöglicht deshalb dem Zentralprozessor die schnellere Abarbeitung des Sortierprozesses der E/A-Anforderungen. Dadurch wird der Zentralprozessor in die Lage versetzt, andere Arbeitsaufgaben schneller zu erledigen. Das für den Prozess zum Einstellen in die Warteschlange bzw. zum Herausholen aus der Warteschlange zwischen den das Kanal-Teilsystem umfassenden verschiedenen Mikroprozessoren zu wählende Verfahren hängt normalerweise davon ab, welcher der beteiligten Prozessoren bezüglich seiner Verarbeitungskapazität und der zeitlichen Anforderungen am stärksten belastet ist. Wenn also der Warteschlangenprozessor am stärksten belastet ist, wird das zweite Verfahren gewählt. Wenn hingegen der Prozessor zum Herausholen aus der Warteschlange am stärksten belastet ist, wird normalerweise das erste Verfahren gewählt.
Das Ergebnis besteht unabhängig vom verwendeten Verfahren darin, dass das Kanal-Teilsystem den Start und die Ausführung anstehender E/A-Anforderungen nach Prioritäten und nicht nach der Reihenfolge des Eintreffens bzw. dem FIFO-Verfahren bestimmt.
Bei einer Ausführungsart werden ferner unabhängig vom eingesetzten Warteschlangen- und Auswahlverfahren zum Festlegen der Priorität und/oder zum Auswählen einer zu verarbeitenden Anforderung verschiedene Kriterien herangezogen. Bei einem Beispiel betrifft dies die folgenden Kriterien:

1. Die Auswahl anstehender E/A-Anforderungen anhand einer durch ein Programm festgelegten Prioritätszahl, wobei jede einzelne Zahl einer bestimmten Prioritätsstufe entspricht. Zum Beispiel muss ein Bereich aufeinanderfolgender einzelner Zahlen bereitgestellt werden, welcher größer ist als die Anzahl aller unterschiedlichen nach Priorität zu ordnenden Arbeitskategorien. Wenn das System zum Beispiel die Möglichkeit bietet, gleichzeitig mit N verschiedenen Betriebssysteme zu arbeiten, wie dies mit einem typischen S/390-System möglich ist, müssen die Prioritätsverfahren des Kanal-Teilsystems N oder mehr verschiedene Prioritätsstufen vorsehen. Jede Prioritätsstufe würde dann von der niedrigsten bis zur. höchsten Stufe oder umgekehrt durch eine eindeutige Zahl im Bereich von 0 bis N-1 dargestellt.
2. Die Prioritätsauswahl anstehender E/A-Anforderungen mittels eines Verfahrens, welches allen Anforderungen in der Warteschlange unabhängig von ihrer Priorität auch „Gerechtigkeit" zukommen lässt. Das ist besonders dann wünschenswert, wenn die Wahrscheinlichkeit möglichst gering gehalten werden soll, dass Anforderungen mit niedriger Priorität längere Zeit nicht verarbeitet werden, wenn zum Beispiel das Kanal-Teilsystem längere Zeit mit einer übergroßen Anzahl von Anforderungen mit höherer Priorität konfrontiert wird. Eine gerechte Auswahl anstehender Anforderungen mit gleicher Priorität kann auch nach anderen Gesichtspunkten erfolgen. Zum Beispiel, um anstehende Anforderungen gleichberechtigt zu behandeln, welche bereits einmal oder mehrmals aus der Warteschlange geholt, vergeblich gestartet und zusammen mit anderen Anforderungen gleicher Priorität wieder in die Warteschlange mit noch nicht ausgewählten Anforderungen eingestellt worden sind. Ein solches Verfahren wird unter Bezug auf 9 beschrieben. Dieses Verfahren richtet sich bei der Auswahl anstehender Anforderungen mit einer Vielzahl unterschiedlicher Kategorien nicht nur nach der Priorität, sondern bietet auch Chancengleichheit.
3. Externe Benutzer-/Operatorsteuerung: 1. für das globale Aktivieren/Deaktivieren der Prioritätsverarbeitungsverfahren. Diese Steuerung kann erforderlich sein, um die FIFO-Verarbeitung der anstehenden Anforderungen zu bevorzugen, wenn die Prioritätsverfahren entweder nicht erforderlich oder nicht in der Lage sind, eine atypische Programmausführungsumgebung angemessen darzustellen. 2. die dem Benutzer das Festlegen eines „Standard"-Prioritätswertes für zu einer bestimmten logischen Partition gehörende E/A-Anforderungen in Systemen ermöglicht, welche die parallele Ausführung mehrerer logischer Partitionen bieten. Davon wird Gebrauch gemacht, wenn das in der logischen Partition laufende Betriebssystem nicht dafür ausgelegt ist, für seine E/A-Anforderungen einen Prioritätswert festzulegen, aber trotzdem erfolgreich mit anderen Betriebssystemen in anderen logischen Partitionen konkurrieren soll, welche E/A-Prioritäten festlegen. 3. die dem Benutzer in Systemen, welche die parallele Ausführung mehrerer logischer Partitionen bieten, das Festlegen eines kleinsten und eines größten Teilbereichs von Prioritätswerten für jede logische Partition aus der Gesamtmenge durch das Kanal-Teilsystem bereitgestellter Werte ermöglicht. Von dieser Steuerung wird Gebrauch gemacht, wenn mehrere Betriebssysteme in separaten logischen Partitionen laufen und unabhängig voneinander und ohne Kenntnis der anderen aktiven Partitionen auf Grundlage von Prioritäten arbeiten. Dadurch soll jede aktive Partition die Auswahl der Anforderungen auf Grundlage von Prioritäten starten können.

Entsprechend den oben genannten Punkten 3.2 und 3.3 weist der Zentralprozessor jedenfalls dem in der logischen Partition laufenden Programm den vom Benutzer festgelegten Standardprioritätswert oder die vom Benutzer festgelegte mindest-/höchstzulässige Priorität in einer Weise zu, die für das in der Partition laufende Programm transparent ist. Bei S/390-Systemen kann das durch den Logikpartitionsmanager (Kontrollorgan) und die Anweisung START SUBCHANNEL des Zentralprozessors gemeinsam erfolgen.
Wenn das in der logischen Partition laufende Programm die Anweisung START SUBCHANNEL ausführt, um eine E/A-Operation zu starten, werden bei der interpretierenden Ausführung der Anweisung START SUBCHANNEL im Zentralprozessor auf jeden Fall sowohl die Standardprioritätszahl als auch die mindest-/höchstzulässigen Prioritätszahlen aus einer Statusbeschreibungstabelle (State Description, SD) für die interpretierende Startausführung (Start Interpretive Execution, SIE) gelesen. Diese Tabelle wird durch den Logikpartitionsmanager erzeugt und in den Zentralprozessor geladen, wenn er die SIE-Anweisung ausführt, um die Partition in einen Ausführungsstatus zu versetzen. Die interpretierende Ausführung der Anweisung START CUBCHANNEL bedient sich dann der Standardprioritätswerte und der mindest-/höchstzulässigen Prioritätswerte der SIE-Statusbeschreibungstabelle, um die E/A-Anforderung unbedingt mit dem entsprechenden Prioritätswert zu versehen, ohne dass das in der logischen Partition laufende Programm daran beteiligt ist.
Wenn durch das in der logischen Partition laufende Programm kein Prioritätswert festgelegt worden ist, wird der E/A-Anforderung durch die Interpretation der Anweisung START SUBCHANNEL der durch den Benutzer festgelegte Standardprioritätswert zugewiesen. Wenn das in einer logischen Partition laufende Programm während der Ausführung der Anweisung START SUBCHANNEL eine Prioritätszahl festlegt, vergleicht die Anweisung START SUBCHANNEL durch ihre interpretierende Ausführung den durch das Programm festgelegten Prioritätswert mit den durch das Kontrollorgan (Logikpartitionsmanager) festgelegten mindest-/höchstzulässigen Prioritätswerten in der Statusbeschreibungstabelle. Wenn die durch das Programm festgelegte Priorität kleiner ist als der durch das Kontrollorgan festgelegte Mindestwert, wird der durch das Programm festgelegte Wert sofort durch den Mindestwert aus der Statusbeschreibungstabelle ersetzt. Wenn der durch das Programm festgelegte Prioritätswert größer ist als der durch das Kontrollorgan festgelegte Höchstwert, wird der durch das Programm festgelegte Wert durch den höchstzulässigen Prioritätswert aus der Statusbeschreibungstabelle ersetzt.
Es kann ein Prioritätsauswahlverfahren angegeben werden, das auf der Verwendung von keinen oder mehreren der oben genannten Kriterien beruht. Eine Ausführungsart eines Verfahrens zum Auswählen einer zu verarbeitenden Anforderung, welches sich mindestens einiger der oben genannten Kriterien bedient, wird unter Bezug auf 9 beschrieben.
Zuerst wird in SCHRITT 900 auf eine anstehende Arbeitswarteschlange, zum Beispiel auf die E/A-Prozessor-Arbeitswarteschlange, die Kanalprozessor-Arbeitswarteschlange oder die Steuereinheit-Arbeitswarteschlange zugegriffen. Anschließend wird in SCHRITT 902 der Zählerstand der aus der Warteschlange entnommenen anstehenden Anforderungen um eins erhöht (z.B. DQCOUNT = DQCOUNT + 1).
Anschließend wird in SCHRITT 904 ermittelt, welche Kategorie anstehender Anforderungen verarbeitet werden soll. Bei einem Beispiel ist die ausgewählte Kategorie gleich DQCOUNT modulo Anzahl der Kategorien. Da es beim vorliegenden Beispiel vier Kategorien gibt, ist die ausgewählte Kategorie gleich DQCOUNT modulo 4. Wenn das Ergebnis null lautet, wird in SCHRITT 906 die erste Anforderung mit einer beliebigen Priorität aus der Warteschlange geholt. Wenn die ausgewählte Kategorie jedoch gleich eins ist, wird in SCHRITT 908 die erste Anforderung mit der höchsten Priorität ausgewählt, die nicht zuvor aus der Warteschlange geholt worden ist. Wenn die ausgewählte Kategorie gleich 2 ist, wird in SCHRITT 910 die erste zuvor aus der Warteschlange geholte und erfolglos gestartete Anforderung mit der höchsten Priorität ausgewählt. Wenn das Ergebnis jedoch gleich 3 ist, wird in SCHRITT 912 die erste nicht zuvor aus der Warteschlange genommene Anforderung mit beliebiger Priorität ausgewählt. Anschließend wird die ausgewählte Anforderung in SCHRITT 914 aus der Warteschlange geholt und verarbeitet.
Oben wird ein Prioritätsmechanismus für asynchrone Anforderungen innerhalb eines Coprozessors ausführlich beschrieben. Obgleich die Beispiele unter Bezug auf E/A-Anforderungen und Kanal-Teilsysteme beschrieben werden, handelt es hierbei lediglich um Beispiele. Dieser Lösungsansatz lässt sich ebenso auch auf andere asynchrone Anforderungen und Coprozessoren anwenden. Obwohl das obige Beispiel unter Bezug auf Warteschlangen beschrieben wird, kann ein ähnlicher Prioritätsmechanismus auch zum Anpassen der Zuweisung von Ressourcen (z.B. der Bandbreite) in einem Kanal dienen, der in der Lage ist, gleichzeitig mehrere Operationen auszuführen, indem der Mechanismus die Kanalressourcen nicht gleichmäßig, sondern vorzugsweise an diejenigen Operationen mit einer höheren Priorität verteilt.
Obwohl verschiedene Beispiele hierin unter Bezug auf ein System mit logischen Partitionen beschrieben werden, können die E/A-Prioritätsmittel auch in einem System eingesetzt werden, welches keine logischen Partitionen aufweist oder unterstützt.
Ein weiterer Vorteil besteht darin, dass die E/A-Konfiguration (z.B. die Kanalpfadkonfiguration) einer Rechnerumgebung dynamisch verändert werden kann, um ohne menschliches Eingreifen freie Kanalressourcen dorthin zu bringen, wo sie benötigt werden, oder überschüssige Kanalressourcen abzuziehen. Dadurch werden zum Konfigurieren der E/A-Einheiten weniger Kenntnisse benötigt, die Gesamtleistung des Systems verbessert, die installierten Kanäle bestmöglich ausgenutzt und die verfügbare E/A-Kapazität entsprechend den relativen Prioritäten der Arbeitsbelastung verteilt. Bei einer Ausführungsart werden vor dem Ausführen einer Veränderung ein oder mehrere Faktoren in Betracht gezogen, um die „beste" Veränderung vorzunehmen. Zu diesen Faktoren gehören beispielsweise die Auswirkung auf die Reaktionszeit oder die E/A-Geschwindigkeit; die Auswirkung auf die Reaktionszeit zum Erreichen bestimmter Zielwerte für die Arbeitsbelastung; ob der Zielanschluss belegt ist; die sich daraus ergebenden Verfügbarkeitseigenschaften (z.B. Pfade ohne gemeinsame Fehlerpunkte hinzufügen); und die sich ergebende Komplexität (oder Entropie) der E/A-Konfiguration.
Eine Ausführungsart der Logik im Zusammenhang mit dem dynamischen Anpassen einer E/A-Konfiguration wird unter Bezug auf 10 bis 14 ausführlich beschrieben. Zuerst wird zu Beginn von regelmäßig wiederkehrenden Zeitintervallen, z.B. alle 10 Sekunden, beispielsweise durch eine Workload-Manager- Komponente der Rechnerumgebung eine ausgeglichene Grundverarbeitung abgerufen. Die Funktion der ausgeglichenen Grundverarbeitung besteht darin, die E/A-Geschwindigkeit (durch Umverteilen (d.h. Verwalten) definierter Kanäle) ständig gleichmäßig zwischen den Teilsystemen (z.B. den Logiksteuereinheiten) zu verteilen; sicherzustellen, dass auf alle Einheiten über zwei oder mehr Pfade zugegriffen werden kann, welche keinen Fehlerpunkt gemeinsam haben; und das Gleichgewicht zwischen den Teilsystemen nach einem Hardwareausfall wiederherzustellen. Diese Verarbeitung beinhaltet zwei Komponenten: die Datenerfassung in SCHRITT 1000 (10) und die Gleichgewichtsprüfung in SCHRITT 1002. Die Datenerfassung erfolgt in jedem Intervall einmal in jeder logischen Partition (wenn die Rechnerumgebung logisch partitioniert ist) oder in jedem System (wenn es nicht logisch partitioniert ist), während die Gleichgewichtsprüfung in jedem Intervall nur einmal für jede LPAR-Gruppe erfolgt (wenn diese Partitionen in Gruppen zusammengefasst sind).
Die serielle Anordnung des Datenerfassungsteils bei der Datenverarbeitung wird dadurch erreicht, dass der Workload-Manager das Grundgleichgewicht in jedem System nur einmal je Intervall abruft. Außerdem wird beim Aktualisieren der erfassten Daten die Versionsnummer überprüft. Zum Beispiel werden in der Verbindungseinheit gespeicherte Steuerblöcke seriell angeordnet, um die erfassten Daten zu aktualisieren. Diese Steuerblöcke ermöglichen die Datenerfassung auf Gruppenebene und damit die Aufteilung der Kanäle auf die Glieder einer Gruppe in ein und demselben CPC.
Zur seriellen Ausführung der Gleichgewichtsprüfung wird ein serielles Verfahren mit einer speziell für diesen Zweck vorgesehenen Gruppenüberwachung angewendet. Üblicherweise wird eine die ganze Gruppe umfassende Serialisierung angefordert, wenn das Gleichgewicht sofort nach der Datenerfassung abgerufen wird. Wenn die Serialisierung erreicht ist, wird die Gleichgewichtsprüfung fortgesetzt; im gegenteiligen Falle läuft die Gleichgewichtsprüfung bereits innerhalb der LPAR-Gruppe ab und braucht während dieses Intervalls nicht noch einmal durchgeführt zu werden.
Die Verarbeitung der Datenerfassung von 10 wird ferner unter Bezug auf 11 beschrieben. Bei einer Ausführungsart werden die Messdaten in SCHRITT 1100 für jedes definierte Teilsystem (z.B. die Logiksteuereinheit) erfasst und aktualisiert. Zu den Messdaten gehören zum Beispiel die Verbindungszeit, die Wartezeit, die Besetztzeit des Teilsystems und der Einheit sowie die Besetztzeit und die Besetztzählwerte des Zielanschlusses. Die aktualisierten Messdaten werden in Steuerblöcken im Prozessorspeicher zusammen mit Steuerblöcken in einem gemeinsam genutzten Speicher wie der Verbindungseinheit gespeichert.
Nach dem Aktualisieren der Messdaten wird in SCHRITT 1102 eine E/A-Standardzielgeschwindigkeit für jedes Teilsystem berechnet. Die E/A-Geschwindigkeit zeigt an, ob noch zusätzliche Kanalbandbreite benötigt oder gewünscht wird. Bei einem Beispiel wird die E/A-Standardzielgeschwindigkeit nach der Verbindungsdauer gewichtet. Für diese Berechnung werden bei einem Beispiel die folgenden Schritte ausgeführt: Für jedes durch die DCM (dynamische Verwaltung der Kanalpfade) verwaltete Teilsystem wird die aktuelle oder tatsächliche Geschwindigkeit zusammen mit der während des letztert Intervalls durch dieses Teilsystem in Anspruch genommenen Verbindungsdauer ermittelt. Dann wird die E/A-Geschwindigkeit mit der Verbindungsdauer multipliziert, um ein Ergebnis zu erhalten. Die Ergebnisse der Teilsysteme werden dann addiert, um eine Summe zu erhalten. Diese Summe wird dann durch die Gesamtverbindungsdauer dividiert, um eine nach der Verbindungsdauer gewichtete E/A-Standardzielgeschwindigkeit zu ermitteln.
Nach der Datenerfassung in 10 wird in SCHRITT 1002 die hier beschriebene Gleichgewichtsprüfung durchgeführt. Eine Ausführungsart der Logik zur Gleichgewichtsprüfung wird unter Bezug auf 12 beschrieben. Zuerst wird die Serialisierung durchgeführt, um in ANFRAGE 1200 zu ermitteln, ob in diesem Fall eine Gleichgewichtsprüfung durchgeführt werden soll. Wenn der Versuch einer die ganze Gruppe umfassenden Serialisierung fehlschlägt, wird die Logik zur Gleichgewichtsprüfung nicht durchlaufen, und die Verarbeitung springt zu SCHRITT 1202. Wenn die Serialisierung jedoch erfolgreich ist, werden in SCHRITT 1204 die Teilsysteme nach solchen Teilsystemen durchsucht, welche außerhalb ihres Zielbereichs liegen.
Beispielsweise erhält man für alle Teilsysteme die tatsächliche E/A-Geschwindigkeit und bildet davon den Mittelwert. (Bei einem Beispiel werden nur diejenigen Teilsysteme in den Mittelwert einbezogen, die durch die dynamische Verwaltung der Kanalpfade (DCM) verwaltet werden.) Nach der Bestimmung des Mittelwertes wird ein Bereich festgelegt. Bei einem Beispiel liegt der Bereich bei plus oder minus 5 % vom Mittelwert. Anschließend wird die E/A-Zielgeschwindigkeit jedes Teilsystems mit dem Zielbereich verglichen. Wenn keine E/A-Zielgeschwindigkeit festgelegt wurde, wird die E/A-Standardzielgeschwindigkeit genommen. Als Ergebnis dieser Vergleiche in SCHRITT 1206 ergeben sich zwei Listen. In einer Liste sind diejenigen Teilsysteme, welche über den Zielbereich hinausgehen, und in der anderen Liste diejenigen Teilsysteme ohne Zielbereich enthalten. Auf jeden Fall werden die gerade erst (z.B. während der letzten 10 Sekunden) geänderten Teilsysteme nicht in die Listen auf genommen.
Anschließend wird die Liste der Teilsysteme ohne Zielbereich in SCHRITT 1208 sortiert. Bei einem Beispiel wird diese Liste mittels des WLM sortiert, da dieser beurteilen kann, welche Teilsysteme am wichtigsten sind. Somit bringt der WLM die Teilsysteme in die Reihenfolge, in welcher sie berücksichtigt werden sollen.
Nach dem Sortieren der Liste werden in SCHRITT 1210 ein oder mehrere der Teilsysteme aus der Liste zum Beispiel dadurch berücksichtigt, dass Kapazität von weniger ausgelasteten zu überlasteten Teilsystemen verlagert wird. Während der zur Verfügung stehenden Zeit werden so viele Teilsysteme wie möglich angepasst.
Eine Ausführungsart der Logik zur Kapazitätsanpassung wird unter Bezug auf 13a bis 13b beschrieben. Zuerst wird in SCHRITT 1300 (13a) ein Teilsystem aus der Liste ausgewählt. Bei einem Beispiel wird das erste Teilsystem in der Liste ausgewählt. Anschließend wird in ANFRAGE 1302 ermittelt, ob das Problem in einem besetzten Zielanschluss besteht. Insbesondere wird ermittelt, ob der Konflikt (z.B. die Besetzungsdauer des Zielanschlusses) gravierend ist und ob er sich in diesem Fall für die einzelnen mit dem Anschluss verbundenen Schnittstellen unterscheidet. Wenn der Belegungsgrad des Zielanschlusses an allen Schnittstellen hoch ist, bedeutet dies, dass noch ein weiterer Kanalpfad zugeschaltet werden muss. Wenn er jedoch nur an einer Schnittstelle hoch ist, wird in SCHRITT 1314 ein Kanalpfad einer anderen Schnittstelle zugeordnet. Somit wird ein vorhandener Pfad von der Schnittstelle mit einer zu großen Auslastung am Zielanschluss abgezogen und einer anderen Schnittstelle zugeordnet, und die Verarbeitung wird in SCHRITT 1306 (13b) mit der Umsetzung der Veränderung fortgesetzt. Beispiele für die Umsetzung der Veränderung werden in den US-Patentschriften 5 257 379 vom Oktober 1993, 5 257 368 vom Oktober 1993 und 5 220 654 vom Juni 1993 beschrieben.
Nach dem Umsetzen der Veränderung wird in ANFRAGE 1308 ermittelt, ob es noch weitere Teilsysteme gibt, die sich nicht im Zielbereich befinden. Ein negatives Ergebnis bedeutet, dass die Verarbeitung der Gleichgewichtskorrektur abgeschlossen ist. Wenn es jedoch noch weitere Teilsysteme außerhalb des Zielbereichs gibt, wird die Verarbeitung in SCHRITT 1300 „NÄCHSTES TEILSYSTEM IN DER LISTE AUSWÄHLEN" (13a) fortgesetzt.
Wenn in ANFRAGE 1302 das Problem nicht in einer Konfliktsituation besteht, wird die Verarbeitung wie folgt fortgesetzt.
Insbesondere werden bei einem Beispiel in SCHRITT 1310 diejenigen Kanalpfade ermittelt, die zum Teilsystem hinzugefügt werden können. Zu dieser Ermittlung gehört die Prüfung aller Kanäle innerhalb der physischen Topologie, die für das betreffende Teilsystem in Frage kommen, und dann für jeden Kanal die Ermittlung aller möglichen Wege (Pfade) für den Zugang zu diesem Teilsystem. Ein Pfad stellt eine Permutation der Verbindungsmöglichkeiten durch die Hardwareelemente dar, welche den Kanal und das STeilsystem miteinander verbinden und beinhalten. Alle diese Pfade (oder eine Teilmenge davon, wenn dies gewünscht ist) sind Bestandteil der möglichen Pfade.
Ebenso wird in SCHRITT 1312 ermittelt, welche Pfade beseitigt werden können. Wenn zum Beispiel mehrere Teilsysteme denselben Kanal gemeinsam nutzen, wird einer der Pfade zur Beseitigung vorgesehen, der mit dem betreffenden Teilsystem verbunden ist.
Anschließend wird in SCHRITT 1314 ermittelt, welches Teilsystem durch die Änderung betroffen ist. Ferner wird im Folgenden beschrieben, wie ein Entropieindex ermittelt wird, welcher die Komplexität einer zu verändernden Konfiguration anzeigt.
Eine Ausführungsart der Logik zur Ermittlung der betroffenen Teilsysteme wird unter Bezug auf 14 beschrieben. Zuerst werden in SCHRITT 1400 eine Liste der Teilsystemsteuerblöcke (subsystem control block, SSCB) für Teilsysteme und eine CHPID-Liste der Kanalpfade für die Kanäle zur späteren Verwendung gelöscht. Anschließend in SCHRITT 1402 wird aus einem zu dem vorgeschlagenen Kanal gehörenden Entscheidungsauswahlblock (decision selection block, DSB) eine Kanalpfadkennung (CHPID) abgerufen und in die CHPID-Liste eingetragen. Insbesondere gehört zu jedem Pfad ein Entscheidungsauswahlblock. Der Entscheidungsauswahlblock ist ein Steuerblock, in dem verschiedene Daten enthalten sind, zum Beispiel die Kennung des Kanalpfades (CHPID), ein Zeiger des Teilsystemsteuerblocks (SSCB), der die zu dem Kanalpfad gehörende Logiksteuereinheit anzeigt, und eine Anordnung betroffener SSCBs. Jeder SSCB enthält alle mit dem Teilsystem verbundenen Kanäle.
Anschließend werden in SCHRITT 1404 auch alle CHPIDs des betroffenen SSCB in die CHPID-Liste eingetragen. Insbesondere wird aus dem DSB der SSCB-Zeiger abgerufen, welcher den betroffenen SSCB anzeigt. Danach werden alle CHPIDs im SSCB in die CHPID-Liste eingetragen.
Anschließend werden in SCHRITT 1406 für jede CHPID in der Liste die zum Kanalpfad gehörenden SSCBs in die SSCB-Liste eingetragen. Bei einem Beispiel wird diese Information aus einer Kanalpfadtabelle gewonnen, welche die mit jeder CHPID verbundenen SSCBs anzeigt.
Anschließend wird in ANFRAGE 1408 ermittelt, ob SSCBs in die Liste eingetragen wurden. Wenn dies der Fall ist, werden in SCHRITT 1410 für jeden SSCB in der Liste die in der CHPID-Liste noch nicht enthaltenen CHPIDs eingetragen, was oben bereits bei SCHRITT 1404 beschrieben wurde.
Anschließend wird in ANFRAGE 1412 noch ermittelt, ob CHPIDs in die Liste eingetragen wurden. Wenn weitere CHPIDs in die Liste eingetragen wurden, wird die Verarbeitung mit SCHRITT 1406 fortgesetzt. Wenn jedoch die ANFRAGEN 1408 und 1412 ergeben, dass weder SSCBs noch SHPIDs in die Listen eingetragen wurden, wird in SCHRITT 1414 für jeden SSCB in der Liste ein DSB-Tabellenelement erzeugt. Das heißt, jeder der SSCBs wird in die Tabelle der betroffenen SSCBs eingetragen. Außerdem wird in SCHRITT 1416 jedes Tabellenelement durch die tatsächlichen und die E/A-Zielgeschwindigkeiten, die aktuelle Differenz zwischen diesen beiden und einen SSCB-Zeiger aktualisiert.
Zusätzlich wird in SCHRITT 1316 von 13a für jeden Pfad der Verfügbarkeitsindex berechnet. Bei einem Beispiel stellt dieser Verfügbarkeitsindex eine Zahl dar, welche anzeigt, wie viele einzelne Fehlerpunkte der vorgeschlagene Pfad mit vorhandenen Pfaden des Teilsystems gemeinsam hat. Wenn ein Kanalpfad hinzugefügt werden soll, sollte dieser keine Fehlerpunkte aufweisen. Wenn ein Kanalpfad entfernt werden soll, wird normalerweise derjenige Pfad ausgewählt, der die meisten Fehlerpunkte aufweist.
Anschließend wird in SCHRITT 1318 die Auswirkung auf die betroffenen Systeme abgeschätzt. Bei einem Beispiel wird insbesondere die aktuelle Auslastung jedes Teilsystems bewertet, um zu ermitteln, wie diese nach der Änderung sein wird. Anhand dieser Information wird in SCHRITT 1320 die bestmögliche Auswahl getroffen. Um die bestmögliche Auswahl zu treffen, können verschiedene Faktoren berücksichtigt werden, zum Beispiel:

– Durch welche Auswahl erreicht das Teilsystem den Zielwert am besten?
– Welche Auswahl führt zur besten Verfügbarkeit? Welche Auswahl führt zur besten Symmetrie (zur geringsten Entropie)?
– Verringert diese Auswahl die Gesamtzahl der Pfade auf weniger als zwei?
– Verletzt diese Auswahl festgelegte Zielwerte (der WLM kann Zielwerte festlegen, die anstelle der Standardzielwerte zu verwenden sind)?
– Stößt diese Auswahl auf durch die Architektur gesetzte Grenzen?
– Verletzt diese Auswahl die durch die Installation definierte Konfiguration?
– Versucht diese Auswahl, Ressourcen zu nutzen, die im Augenblick nicht zur Verfügung stehen?

Bei einem bestimmten Beispiel werden zuerst alle Entscheidungsauswahlblöcke (DSBs) entfernt, die sich auf keinen Fall ausführen lassen. Insbesondere betrifft dies solche Blöcke, die auf Architekturgrenzen stoßen, die die Gesamtzahl der Pfade auf weniger als zwei verringern, die die durch die Installation definierte Konfiguration verletzen (indem sie z.B. mehr Kanalpfade verwenden als der durch die Definition maximal festgelegten Anzahl wechselnder Kanalpfade entspricht) und die Ressourcen zu nutzen versuchen, welche gerade nicht zur Verfügung stehen (z.B. indem sie Anschlüsse zu nutzen versuchen, welche von der Nutzung ausgenommen wurden). (Diese Funktion könnte in der Verarbeitung bereits vorgezogen werden, sodass der Verfügbarkeitsindex und die voraussichtliche Auswirkung auf die Teilsysteme für diejenigen DSBs nicht berechnet werden, welche überhaupt nicht ausgewählt werden können.)
Wenn im Augenblick gerade nur ein Pfad zum Teilsystem führt (möglicherweise kurz nach dem Systemstart oder nach einem Fehler), wird ein Pfad mit dem besten Verfügbarkeitsindex ausgewählt. Wenn es mehrere Pfade mit gleichem Verfügbarkeitsindex gibt, wird derjenige Pfad mit dem kleinsten Entropieindex ausgewählt, der das Zielteilsystem in den Zielbereich der E/A-Geschwindigkeit bringt. Wenn es davon mehrere gibt, wird derjenige mit der kleinsten voraussichtlichen Differenz („F voraussichtliche Differenz" vom DSB) ausgewählt.
Wenn im Augenblick gerade mehr als ein Pfad zum Teilsystem führt, muss nach den DSBs mit dem besten Verfügbarkeitsindex gesucht werden. Dabei ist nach denjenigen Auswahlmöglichkeiten zu suchen, welche das Zielteilsystem innerhalb der Toleranz der E/A-Zielgeschwindigkeit erreichen und den kleinsten Entropieindex aufweisen. Wenn es davon mehrere gibt, ist derjenige auszuwählen, dessen voraussichtliche Gesamtdifferenz („Σ voraussichtliche Differenz" vom DSB) am kleinsten ist.
Wenn sich keine Auswahlmöglichkeit ergibt, muss in einem weiteren Versuch nach einer Gruppe von Pfaden mit dem nächstbesten Verfügbarkeitsindex gesucht werden.
Wenn es überhaupt keine Auswahlmöglichkeit gibt, welche das Teilsystem innerhalb der Toleranz erreicht, ist unabhängig vom Verfügbarkeitsindex oder vom Entropieindex diejenige auszuwählen, die das Teilsystem möglichst nahe am Zielbereich erreicht. (Die oben beschriebene Technik zum Treffen der besten Auswahl stellt nur ein Beispiel dar. Um die bestmögliche Auswahl zu treffen, können verschiedene Ergänzungen, Auslassungen und Änderungen angebracht sowie weitere geeignete Techniken verwendet werden.) Nach diesen Versuchen zur bestmöglichen Auswahl wird in ANFRAGE 1322 ermittelt, ob der neue Zielwert ohne Beeinträchtigung der Teilsysteme mit festgelegten Zielwerten erreicht werden kann. Mit anderen Worten, werden durch die beste Auswahl die Teilsysteme mit durch den WLM festgelegten Zielwerten beeinträchtigt? Wenn dies der Fall ist, muss der Workload-Manager in SCHRITT 1324 den geeigneten Pfad auswählen. Dabei sucht der Workload-Manager den Pfad aus und legt für den Geber neue Zielwerte fest.
Danach oder wenn das neue Ziel ohne negative Auswirkungen auf Teilsysteme mit festgelegten Zielwerten erreicht werden kann, wird die Änderung in SCHRITT 1306 vorgesehen, und in der weiteren Verarbeitung wird in ANFRAGE 1308 ermittelt, ob es noch andere Teilsysteme gibt, welche außerhalb des Zielbereichs liegen.
Oben wurde beschrieben, dass der WLM einen bestimmten Zielwert der E/A-Geschwindigkeit festlegen kann, der anstelle des mittleren Standardwertes der E/A-Geschwindigkeit zu verwenden ist. Bei einer Ausführungsart legt der WLM einen bestimmten Zielwert fest, wenn er erkennt, dass die Betriebsklasse nicht seinen Zielvorgaben entspricht. Unter Bezug auf 15 wird eine Ausführungsart der Logik zum Festlegen des bestimmten Zielwertes der E/A-Geschwindigkeit des Teilsystems beschrieben.
Zuerst wird in ANFRAGE 1500 ermittelt, ob die Ein-/Ausgabe die größte Verzögerung verursacht. Wenn dies nicht zutrifft, ist die Verarbeitung hier bereits abgeschlossen. Wenn jedoch die Ein-/Ausgabe die größte Verzögerung verursacht, wird in SCHRITT 1502 versucht, die Priorität anzupassen. Anschließend wird in ANFRAGE 1504 ermittelt, ob die Betriebsklasse zum Erreichen der Zielwerte geeignet ist. Wenn die Zielwerte für diese Betriebsklasse erreicht werden können, ist die Verarbeitung nun abgeschlossen. Wenn die Zielwerte jedoch für die Betriebsklasse noch nicht erreicht werden können, wird in SCHRITT 1506 nach Teilsystemen gesucht, welche gerade durch die Betriebsklasse genutzt werden und eine niedrige E/A-Geschwindigkeit aufweisen. Für ein oder mehrere auf diese Weise gefundene Teilsysteme werden nun neue Zielwerte der E/A-Geschwindigkeit festgelegt. Bei einem Beispiel wird der neue Zielwert durch Erhöhung des aktuellen Zielwertes um einen definierten Betrag festgelegt und anschließend die voraussichtliche Auswirkung auf das Teilsystem abgeschätzt. Wenn diese Auswirkung groß genug ist, (z.B. größer als ein Empfängerwertes ist), ist die Verarbeitung abgeschlossen. Anderenfalls wird der Zielwert erneut erhöht und die Verarbeitung wiederholt.
Oben wird die dynamische CHPID-Verwaltung der Kanalpfade (DCM) ausführlich beschrieben, welche eine dynamische Anpassung der E/A-Konfigurationen bietet. Die DCM lässt sich vorteilhaft mit dem WLM integrieren, sodass Entscheidungen ausgehend von den Arbeitsbelastungen und den Zielwerten getroffen werden können. Ferner ermöglich die DCM die Verwaltung von Kanälen für mehrere Partitionen (z.B. eine Gruppe von Partitionen). Auf diese Weise können Ressourcen dort hinzugefügt werden, wo sie benötigt werden, und überschüssige Ressourcen wieder entfernt werden.
Durch die dynamische CHPID-Verwaltung der Kanalpfade (DCM) gemäß der obigen Beschreibung kann der „am besten geeignete" Kanal ausgewählt werden, der zum Teilsystem hinzugefügt (oder wieder von ihm entfernt) werden soll. Hierzu werden ein oder mehrere Attribute geprüft, unter anderem beispielsweise die Komplexität (oder Entropie) der entstehenden E/A-Konfiguration.
Eine höhere Entropie führt zu einer übermäßig komplizierten E/A-Konfiguration, wodurch die DCM-Verarbeitungszeit zu stark zunimmt, die Ergebnisse wegen der zu großen Anzahl betroffener Teilsysteme ungenau werden, und die Komplexität der Leistungsermittlung und der Problemsuche zunimmt. Bei einer bevorzugten Ausführungsart der vorliegenden Erfindung wird daher ein Mittel zur Ermittlung der relativen Entropie verschiedener Alternativen bereitgestellt, sodass zur Wahl einer Anpassung der Konfiguration neben anderen Erwägungen wie zur E/A-Geschwindigkeit und -Verfügbarkeit auch die relative Entropie in Betracht gezogen werden kann.
Zur Ermittlung der relativen Entropie wird ein Entropieindex berechnet. Wenn beispielsweise ein Pfad hinzugefügt wird, besteht der Entropieindex in der Summe der Kanäle und Teilsysteme der entstehenden Konfiguration. Wenn hingegen ein Pfad entfernt wird, spiegelt der Entropieindex ferner die Anzahl der nach dem Entfernen des Pfades mit dem Zielteilsystem verbundenen Kanäle und Teilsysteme wider. Er berücksichtigt keine Kanäle und Teilsysteme, die nicht mehr Bestandteil der Konfiguration sind.
Zur Berechnung des Entropiegrades für jede Alternative wird die Anzahl der miteinander verbundenen Kanäle und Teilsysteme unter der Annahme herangezogen, dass sie bereits realisiert wurde. Eine Grundvoraussetzung für das Entropieverfahren besteht in der Berechnung eines Indexes, mittels dessen zwei oder mehrere vorgeschlagene Topologien verglichen und deren symmetrischere (oder diejenige, die die geringste Entropie aufweist) ermittelt werden kann. Hierdurch sollen große miteinander vernetzte Topologien vermieden werden, durch welche aufgrund der erhöhten Komplexität das E/A- Geschwindigkeitsverfahren ungenauer wird und Leistungsprobleme schwieriger analysiert werden können.
Eine Ausführungsart des Verfahrens zur Entropieermittlung wird unter Bezug auf verschiedene Beispiele beschrieben. So zeigt 16a zeigt ein Beispiel einer Konfiguration 1600 mit zwei Kanälen 1602, die mit zwei Teilsystemen 1604 verbunden sind: Wenn das Teilsystem 22 eine zusätzliche Ressource benötigt, kann es diese von mindestens zwei Stellen erhalten, entweder von Kanal 1 oder von Kanal 3. Wenn es die zusätzliche Ressource von Kanal 3 erhält, besteht die entstehende Konfiguration nunmehr aus drei Kanälen und zwei Teilsystemen (16b). Daraus ergibt sich für die Konfiguration ein Entropieindex von fünf (3 + 2). Wenn das Teilsystem 22 die zusätzliche Ressource jedoch von Kanal 1 erhält (16c), weist die entstehende Konfiguration nicht mehr Kanäle oder Teilsysteme als zuvor auf, und der Entropieindex beläuft sich nun auf zwei. Bei diesem Beispiel weist die zweite Alternative die niedrigste Entropie auf.
Bei einem weiteren in 17a gezeigten Beispiel benötigt das Teilsystem 23 eine weitere Ressource. Diese kann es von Kanal 2 oder von Kanal 4 erhalten. Wenn Kanal 2 genutzt wird (17b), ergibt sich ein Entropieindex von fünf (d.h. bei einer Konfiguration von drei Kanälen, die mit zwei Teilsystemen verbunden sind; Kanal 4 wird hierbei nicht mitgezählt, da er nicht angeschlossen ist). Wenn Kanal 4 genutzt wird (17c), ergibt sich ein Index von drei. Somit weist die zweite Alternative die niedrigste Entropie auf.
Im Folgenden sollen Fälle mit geteilter Konfiguration betrachtet werden, um den Einfluss auf die Entropie zu ermitteln.
Wenn das Teilsystem 23 in 18a über ungenutzte Kapazitäten verfügt, könnte der Kanal 2 oder der Kanal 3 entfernt werden. Bei Entfernen von Kanal 2 (18b) wird die Konfiguration in zwei Konfigurationen geteilt, deren Entropieindex kleiner ist. Bei Entfernen von Kanal 3 (18c) ist immer noch eine Konfiguration vorhanden, jedoch ist ihr Entropieindex kleiner als der ursprüngliche Entropieindex. Es zeigt sich, dass bei einer Ausführungsart die Aufteilung der Konfiguration in zwei etwa gleiche Teile zu zwei weniger komplizierten Netzwerken führt, welche sich als günstiger erweisen.
Wenn beim Entfernen eines Kanals der Index der gegenwärtigen Konfiguration (19a) sowie der Index der vorgeschlagenen Konfiguration mit dem betrachteten Teilsystem (rechte Seite von 19b) bekannt sind, kann der Index der anderen Konfiguration (linke Seite von 19b) durch Subtraktion berechnet werden. Im vorliegenden Beispiel ist der Index dieser anderen Konfiguration gleich 2 (4 – 3 = 1 und 2 – 1 = 1, sodass 1 + 1 = 2 ergibt). Wenn die Subtraktion für die Anzahl der Teilsysteme oder Kanäle in 19c einen Wert von null ergibt, ist die Entropie ohne Teilung der Konfiguration verringert worden. (z.B. 2 Teilsysteme – 2 Teilsysteme = 0.) Bei einer Ausführungsart wird die Teilung bevorzugt.
Im folgenden Beispiel verfügt das. Teilsystem 23 über freie Ressourcen (20a). Die Kanäle 2 oder 3 können entfernt werden. Wenn der Kanal 3 entfernt wird (20b), ergibt sich ein Entropieindex von 7. Wenn der Kanal 2 entfernt wird (20c), wird die Konfiguration in zwei Konfigurationen aufgeteilt, wobei die betrachtete Konfiguration (die Konfiguration mit dem Teilsystem 23) einen Entropieindex von 5 und die entstandene zweite Konfiguration einen Entropieindex von 3 hat. Bei einer Ausführungsart wird die Aufteilung der Konfiguration bevorzugt.
Im Folgenden werden weitere Beispiele betrachtet, um zu ermitteln, ob es beim Entfernen eines Kanals wünschenswert sein kann, nur auf die Teilung der Konfiguration zu achten und nicht auf den sich ergebenden Entropiewert.
Bei dem in 21a gezeigten Beispiel verfügt das Teilsystem 23 über zuviel Bandbreite. Nun kann man entweder Kanal 2 oder Kanal 4 entfernen. Wenn der Kanal 2 entfernt wird (21b), führt dies zu einem neuen Entropieindex von 6 und bei der zweiten Konfiguration zu einem Entropieindex von 3. Wenn der Kanal 4 entfernt wird (21c), führt dies zu einem neuen Entropieindex von 5 und bei der entstehenden zweiten Konfiguration zu einem Entropieindex von 4. Die Konfiguration mit den Entropieindizes von 5 und 4 stellt die bessere Alternative dar. Somit ist bei einer Ausführungsart die Art und Weise der Aufteilung von Bedeutung.
Bei dem in 22a gezeigten Beispiel verlangt das Teilsystem 23 nach zusätzlichen Ressourcen. Das Teilsystem 21 kann vom Kanal 2 getrennt werden (22b), sodass sämtliche Ressourcen von Kanal 2 nun dem Teilsystem 23 zur Verfügung stehen; oder das Teilsystem 25 kann vom Kanal 4 getrennt werden (22c), sodass das Teilsystem 23 alle Ressourcen von Kanal 4 erhält.
Wenn das Teilsystem 21 vom Kanal 2 getrennt wird, beträgt der Entropieindex der betrachteten Konfiguration nunmehr 7 und der Entropieindex der entstandenen zweiten Konfiguration 2. Wenn das Teilsystem 25 vom Kanal 4 getrennt wird, ergeben sich entsprechend ein Entropieindex von 6 und für die zweite Konfiguration von 3. Diese zweite Alternative scheint sich bei einer Ausführungsart als besser zu erweisen, da die Aufteilung der Halbierung am nächsten kommt.
Zur Berechnung, welche Alternative der Halbierung am nächsten kommt (d.h. „gleichmäßig" ist), wird die Differenz der Anzahl der Kanäle und Teilsysteme zwischen dem neuen Entropieindex und dem Entropieindex der neu entstandenen Konfiguration ermittelt. Im vorliegenden Beispiel führt die erste Alternative zu den Entropieindizes 7 und 2 und somit zu einer Differenz (bzw. dem Symmetrieindex) von 5. Die zweite Alternative führt zu den Entropieindizes 6 und 3, sodass die Differenz 3 beträgt. Die Variante mit der kleinsten Differenz stellt bei dieser Ausführungsart die bessere Alternative dar.
Daraus ergibt sich, dass bei einer Ausführungsart diejenigen Alternativen, welche das Teilsystem nicht näher an den Zielwert der E/A-Geschwindigkeit heranführen, ausgeschlossen werden müssen. Ferner wird der Entropieindex durch Addition der Gesamtzahl der in der entstehenden Konfiguration miteinander verbundenen Kanäle und Teilsysteme berechnet. Wenn sich der Entropieindex nicht ändert, ist die Änderung symmetrisch. Üblicherweise wird die Konfiguration mit dem kleinsten Entropieindex ausgewählt. Man sollte keine Konfiguration mit mehr als acht Kanälen auswählen, auch wenn man deswegen eine Konfiguration mit einem größeren Entropieindex wählen muss. Sollte es jedoch keine Alternative geben, muss man in diesem Fall eine Konfiguration mit mehr als acht Kanälen wählen und darauf hoffen, dass die Konfiguration während des nächsten Intervalls geteilt wird.
Obwohl die Varianten der obigen Ausführungsarten unter Bezug auf E/A-Konfigurationen beschreiben wurden, eignen sich die hier beschriebenen Mittel auch für die Anwendung auf andere Netzwerke wie zum Beispiel Speichernetze und andere.
Oben werden verschiedene Mechanismen zum Verwalten von Ressourcen einer Rechnerumgebung beschrieben. Dabei werden physisch gemeinsam zu nutzende Ressourcen für mehrere logische Partitionen einer Rechnerumgebung verwaltet. Die logischen Partitionen werden zu Gruppen zusammengefasst, um die jeweilige Ressource beispielsweise durch Zuweisung auf Grundlage von Prioritäten gemeinsam zu nutzen. Diese gemeinsame Nutzung der Ressource kann zum Beispiel durch dynamische Verwaltung von CPU-Ressourcen für mehrere logische Partitionen; durch dynamische CHPID-Verwaltung der Kanalpfade für mehrere Partitionen; durch Warteschlangen der E/A-Prioritäten im Kanal-Teilsystem; und durch die dynamische Verwaltung von Speichern für mehrere Partitionen erfolgen.
Bei einem Beispiel ist der Workload-Manager des Systems zumindest teilweise für diese Verwaltung zuständig. Die gemeinsam zu nutzenden Ressourcen werden in einer für die Teilsysteme der Anwendungen transparenten Weise unter der Regie des Workload-Managers dynamisch auf die logischen Partitionen aufgeteilt. Die Ressourcen werden den Partitionen entsprechend deren gemessener Aktivität und den Zielstellungen der Benutzer zugeteilt. Außerdem erfolgt die dynamische Anpassung der physischen Ressourcen gemäß den Zielwerten der Arbeitsbelastung zum Beispiel durch den workload-Manager, den Sysplex und die PR/SM-Integration, ohne eine parallele Sysplexdatennutzung zu erfordern.
Bei den oben beschriebenen Ausführungsarten werden verschiedene Rechnerumgebungen und -systeme beschrieben. Es ist jedoch klar, dass diese nur als Beispiele dienen und nicht den Geltungsbereich der vorliegenden Erfindung einschränken sollen. Ebenso dienen auch die hier dargestellten Ablaufdiagramme lediglich als Beispiele. An diesen Diagrammen oder an den Schritten (Operationen) können viele Änderungen vorgenommen werden. Zum Beispiel können die Schritte im Rahmen des Geltungsbereichs der beiliegenden Ansprüche, wenn dies von Vorteil ist, in einer anderen Reihenfolge ausgeführt werden, oder es können Schritte hinzugefügt, weggelassen oder abgeändert werden.

Claims

Verfahren zur Verwaltung einer Arbeitsbelastung in einer Rechnerumgebung, wobei das Verfahren Folgendes umfasst: Ermitteln, ob eine Zuordnung von CPU-Ressourcen zu einer Partition der Rechnerumgebung angepasst werden muss; und dynamische Anpassung der Zuordnung für diese Partition sowie eine weitere Partition in der Rechnerumgebung; wobei die Partition eine oder mehrere Betriebsklassen umfasst und wobei die Ermittlung dadurch gekennzeichnet ist, dass sie Folgendes umfasst: Abschätzen einer Auswirkung der Erhöhung einer mit dieser Partition (600) verbundenen Prozessorgewichtung auf eine ausgewählte Betriebsklasse der einen oder mehreren Betriebsklassen; Abschätzen einer Auswirkung der Verringerung einer Prozessorgewichtung der anderen Partition (604) auf eine der einen oder mehreren Betriebsklassen der anderen Partition; und Ermitteln, ob der Nutzen der ausgewählten Betriebsklasse die negative Auswirkung auf die Arbeit der anderen Partition (606) kompensiert; wobei die Anpassung durchzuführen ist, wenn der Nutzen die negative Auswirkung kompensiert.
Verfahren nach Anspruch 1, wobei die dynamische Anpassung als Reaktion auf die Ziele der Arbeitsbelastung mindestens der einen Partition erfolgt.
Verfahren nach Anspruch 1 oder 2, wobei die dynamische Anpassung die Änderung der mit der Partition verbundenen ersten Gewichtung des CPU-Prozessors und der mit der anderen Partition verbundenen zweiten Gewichtung des CPU-Prozessors umfasst.
Verfahren nach Anspruch 3, wobei die Anpassung Folgendes umfasst: Erhöhen der ersten Gewichtung des CPU-Prozessors; und Verringern der zweiten Gewichtung des CPU-Prozessors.
Verfahren nach Anspruch 4, wobei die erste Gewichtung des CPU-Prozessors um denselben Betrag erhöht wird, wie die zweite Gewichtung des CPU-Prozessors verringert wird, wobei die Summe der ersten Gewichtung und der zweiten Gewichtung des CPU-Prozessors konstant bleibt.
Verfahren nach einem der Ansprüche 1 bis 5, wobei die eine Partition und die andere Partition sich innerhalb einer Gruppe von Partitionen befinden.
Verfahren nach einem der Ansprüche 1 bis 6, welches ferner das Auswählen einer anderen Partition umfasst, wobei das Auswählen auf der Wichtigkeit der in der anderen Partition auszuführenden Arbeit beruht.
Computerprogrammprodukt, welches einen auf einem computerlesbaren Speichermedium gespeicherten Computerprogrammcode umfasst, der bei Ausführung in einem Datenverarbeitungssystem das Datenverarbeitungssystem anweist, das Verfahren nach Anspruch 1 auszuführen.
System zur Verwaltung der Arbeitsbelastung (116) in einer Rechnerumgebung, wobei das System Folgendes umfasst: ein Mittel zur Ermittlung, ob eine Zuordnung von CPU-Ressourcen zu einer Partition der Rechnerumgebung angepasst werden muss; und ein Mittel zur dynamischen Anpassung der Zuordnung zwischen der einen Partition und einer anderen Partition der Rechnerumgebung; und wobei die eine Partition eine oder mehrere Betriebsklassen umfasst, und gekennzeichnet durch das Ermittlungsmittel, welches Folgendes umfasst: ein Mittel zum Abschätzen einer Auswirkung der Erhöhung einer mit dieser Partition (600) verbundenen Prozessorgewichtung auf eine ausgewählte Betriebsklasse der einen oder mehreren Betriebsklassen; Mittel zum Abschätzen einer Auswirkung der Verringerung einer Prozessorgewichtung der anderen Partition (604) auf eine oder mehrere Betriebsklassen der anderen Partition; und Ermitteln, ob der Nutzen der ausgewählten Dienstklasse die negative Auswirkung auf die Arbeit der anderen Partition (606) kompensiert; wobei die Anpassung durchzuführen ist, wenn der Nutzen die negative Auswirkung kompensiert.
System nach Anspruch 9, wobei das Mittel zur dynamischen Anpassung als Reaktion auf die ziele der Arbeitsbelastung mindestens der einen Partition in Aktion tritt.
System nach Anspruch 8 oder 9, wobei das Mittel zur dynamischen Anpassung Folgendes umfasst: ein Mittel zur Änderung der mit der einen Partition verbundenen ersten Gewichtung des CPU-Prozessors und der mit der anderen Partition verbundenen zweiten Gewichtung des CPU-Prozessors.
System nach Anspruch 11, wobei das Änderungsmittel Folgendes umfasst: ein Mittel zum Erhöhen der ersten Gewichtung des CPU-Prozessors; und ein Mittel zum Verringern der zweiten Gewichtung des CPU-Prozessors.
System nach einem der Ansprüche 9 bis 13, welches ferner Folgendes umfasst: ein Mittel zum Auswählen der anderen Partition, wobei das Auswählen auf der Wichtigkeit der in der anderen Partition auszuführenden Arbeit beruht.