test

Systemverwaltungshandbuch: Oracle Solaris Container - Ressourcenverwaltung und Solaris Zones

Kapitel 12 Einführung in Resource Pools

In diesem Kapitel werden die folgenden Themen behandelt:

Ab Solaris-Release 10 11/06 sind Resource Pools und Dynamic Resource Pools Services der Solaris Service Management-Funktion (SMF). Jeder dieser Services wird separat aktiviert.

In diesem Kapitel werden folgende Themen behandelt:

Verfahren zur Nutzung dieser Funktionen finden Sie in Kapitel 13Erstellen und Verwalten von Resource Pools (Vorgehen).

Neuerungen bei den Resource Pools und den Dynamic Resource Pools

Solaris 10: Resource Pools umfassen jetzt einen Mechanismus zum Einstellen der Ressourcenzuweisungen jedes Pools als Reaktion auf Systemereignisse und Änderungen bei den Arbeitslasten der Anwendungen. Dynamic Resource Pools vereinfachen und reduzieren die Anzahl der Entscheidungen, die ein Administrator treffen muss. Einstellungen werden automatisch vorgenommen, um die von einem Administrator festgelegten Leistungsziele des Systems einzuhalten.

Sie können jetzt den Befehl projmod verwenden, um das Attribut project.pool in der Datei /etc/project einzurichten.

Eine vollständige Liste der neuen Funktionen in Solaris 10 sowie eine Beschreibung der Solaris-Releases finden Sie in Neuerungen in Oracle Solaris 9 10/10.

Solaris 10 11/06: Resource Pools und Dynamic Resource Pools sind jetzt SMF-Services.

Einführung in Resource Pools

Resource Pools ermöglichen Ihnen, bestimmte Arbeitslasten voneinander zu trennen, so dass sich der Arbeitslast-Verbrauch bestimmter Ressourcen nicht überschneidet. Diese Ressourcenreservierung hilft dabei, eine vorhersagbare Performance bei Systemen mit gemischten Arbeitslasten zu erreichen.

Resource Pools bieten einen persistenten Mechanismus für die Konfiguration eines Prozessorsets (pset) und optional für die Zuweisung einer Scheduling-Klasse.

Abbildung 12–1 Resource Pool-Framework

Die Abbildung zeigt einen Pool, der aus einem Prozessorset und optional einer Scheduling-Klasse besteht.

Sie können sich einen Pool als eine besondere Art der Bindung von verschiedenen Ressourcensets vorstellen, die auf einem System zur Verfügung stehen. Sie können Pools erstellen, die verschiedene Arten von möglichen Ressourcenkombinationen darstellen:

pool1: pset_default

pool2: pset1

pool3: pset1, pool.scheduler="FSS"

Durch Gruppieren mehrerer Partitionen bieten Pools einen Handle, der bestimmten benannten Arbeitslasten zugewiesen werden kann. Jedem Projekteintrag in der Datei /etc/project kann ein bestimmter Pool zugewiesen sein. Dies wird mit dem Attribut project.pool angegeben.

Wenn Pools aktiviert sind, bilden ein Standard-Resource Pool und ein Standard-Prozessorset die Basiskonfiguration. Weitere benutzerdefinierte Pools und Prozessorsets können erstellt und der Konfiguration hinzugefügt werden. Eine CPU kann nur einem Prozessorset angehören. Benutzerdefinierte Pools und Prozessorsets können permanent gelöscht werden. Der Standard-Resource Pool und das Standard-Prozessorset können nicht permanent gelöscht werden.

Beim Standard-Resource Pool ist die Eigenschaft pool.default auf true gesetzt. Beim Standard-Prozessorset ist die Eigenschaft pset.default auf true gesetzt. Somit können der Standard-Resource Pool und das Standard-Prozessorset auch dann identifiziert werden, wenn ihre Namen geändert wurden.

Der Mechanismus der benutzerdefinierten Pools dient primär für große Computer mit mehr als vier CPUs. Jedoch können auch kleine Computer von dieser Funktion profitieren. Auf kleinen Computern können Sie Pools erstellen, die nicht-kritische Ressourcenpartitionen gemeinsam nutzen. Die Pools sind nur basierend auf kritischen Ressourcen getrennt.

Einführung in die Dynamic Resource Pools

Dynamic Resource Pools bieten einen Mechanismus zum Einstellen der Ressourcenzuweisungen jedes Pools als Reaktion auf Systemereignisse und Änderungen bei den Arbeitslasten der Anwendungen. DRPs vereinfachen und reduzieren die Anzahl der Entscheidungen, die ein Administrator treffen muss. Einstellungen werden automatisch vorgenommen, um die von einem Administrator festgelegten Leistungsziele des Systems einzuhalten. Änderungen an der Konfiguration werden protokolliert. Diese Funktionen werden primär über den Ressourcen-Controller poold ausgeführt, einem Systemdaemon, der immer dann aktiv sein sollte, wenn eine dynamische Ressourcenzuweisung erforderlich ist. poold ermittelt in regelmäßigen Abständen die Systemlast und stellt fest, ob eine Intervention erforderlich ist, damit das System die optimale Leistung hinsichtlich des Ressourcenverbrauchs beibehalten kann. Die poold-Konfiguration befindet sich in der libpool-Konfiguration. Weitere Informationen zu poold finden Sie in der Manpage poold(1M).

Allgemeine Informationen zum Aktivieren und Deaktivieren von Resource Pools und Dynamic Resource Pools

Wie Sie Resource Pools und Dynamic Resource Pools aktivieren bzw. deaktivieren, können Sie unter Aktivieren und Deaktivieren von Pools nachlesen.

In Zonen verwendete Resource Pools

Tipp –

Solaris 10 8/07: Alternativ zum Zuweisen einer Zone zu einem konfigurierten Resource Pool auf dem System können Sie den Befehl zonecfg eingeben, um einen temporären Pool zu erstellen, der nur über die Ausführung der Zone wirksam ist. Weitere Informationen finden Sie unter Solaris 10 8/07: dedicated-cpu-Ressource.

Auf einem System mit aktivierten Zonen kann eine nicht-globale Zone einem Resource Pool verbunden werden, obwohl der Pool nicht unbedingt exklusiv einer bestimmten Zone zugewiesen sein muss. Darüber hinaus können Sie einzelne Prozesse in nicht-globalen Zonen nicht mit dem Befehl poolbind aus der globalen Zone heraus an einen anderen Pool binden. Wie Sie eine nicht-globale Zone mit einem Pool verbinden, lesen Sie unter Konfigurieren, Prüfen und Übernehmen einer Zone.

Wenn Sie eine Scheduling-Klasse für einen Pool einrichten und dann eine nicht-globale Zone mit diesem Pool verbinden, verwendet die Zone standardmäßig diese Scheduling-Klasse.

Wenn Sie Dynamic Resource Pools verwenden, ist der Geltungsbereich einer ausführenden Instanz von poold auf die globale Zone beschränkt.

Das in einer nicht-globalen Zone ausgeführte Dienstprogramm poolstat zeigt nur Informationen zu dem Pool an, der mit der Zone verbunden ist. Wenn der Befehl pooladm ohne Argumente in einer nicht-globalen Zone ausgeführt wird, werden nur Informationen zu dem Pool angezeigt, der mit der Zone verbunden ist.

Weitere Informationen zu den Resource Pool-Befehlen finden Sie unter Mit Resource Pools verwendete Befehle.

Verwenden von Pools

Resource Pools stellen einen vielseitigen Mechanismus dar, der für viele verschiedene administrative Szenarios verwendet werden kann.

Stapelrechner-Server

Nutzen Sie die Funktionen von Pools, um einen Server in zwei Pools aufzuteilen. Ein Pool dient für Anmeldesitzungen und interaktives Arbeiten durch das Timesharing von Benutzern. Der andere Pool dient für Jobs, die über das Stapelsystem übermittelt werden.

Anwendungs- oder Datenbankserver

Partitionieren Sie die Ressourcen für interaktive Anwendungen gemäß den Anforderungen der Anwendungen.

Phasenweises Einschalten von Anwendungen

Bestimmen Sie die Erwartungshaltung von Benutzern.

Sie können zunächst einen Computer bereitstellen, der nur einen Teil der Services ausführt, die dieser Computer letztlich bereitstellen soll. Wenn die auf Reservierungen basierenden Mechanismen der Ressourcenverwaltung beim online schalten des Computers nicht hergestellt sind, könnten sich Probleme bei den Benutzern einstellen.

Beispielsweise optimiert der Fair Share Scheduler die CPU-Auslastung. Die Reaktionszeiten eines Computers, der nur eine Anwendung ausführt, können fälschlich als sehr schnell interpretiert werden. Benutzer erfahren diese Reaktionszeiten nicht mehr, wenn mehrere Anwendungen geladen werden. Mit separaten Pools für jede Anwendung können Sie einen Grenzwert für die Anzahl der CPUs einrichten, die einer Anwendung zur Verfügung stehen, bevor Sie alle Anwendungen bereitstellen.

Komplexe Timesharing-Server

Partitionieren Sie einen Server, der große Benutzerzahlen unterstützt. Die Serverpartitionierung bietet einen Isolationsmechanismus, der zu einer besser vorhersehbaren Reaktionszeit für den einzelnen Benutzer führt.

Durch das Aufteilen von Benutzern in Gruppen, die an separate Pools gebunden sind, und das Verwenden des Fair Share Schedulers (FSS) können Sie CPU-Zuweisungen so anpassen, dass sie bestimmte Benutzergruppen mit einer höheren Priorität bevorzugen. Diese Zuweisung kann auf der Benutzerrolle, auf dem Accounting Chargeback oder anderen basieren.

Arbeitslasten, die sich saisonal ändern

Mit Resource Pools können Sie Anpassungen für einen sich ändernden Bedarf vornehmen.

Vielleicht treten am Standort vorhersagbare Änderungen des Arbeitslastbedarfs über längere Zeiten ein, z. B. monatlich, vierteljährlich oder jährlich. In diesem Fall können Sie durch Aufrufen von pooladm von einem cron-Job aus zwischen mehreren Pool-Konfigurationen wechseln. (Lesen Sie dazu Resource Pools-Framework.)

Echtzeitanwendungen

Erstellen Sie mithilfe des RT-Scheduler und zugewiesenen Prozessorressourcen einen Echtzeit-Pool.

Systemauslastung

Setzen Sie von Ihnen eingerichteten Systemziele durch.

Mit dem automatisierten Pools-Daemon können Sie die verfügbaren Ressourcen identifizieren und Arbeitslasten überwachen, um festzustellen, wenn die von Ihnen angegebenen Ziele nicht mehr eingehalten werden. Der Daemon führt, sofern möglich, korrigierende Maßnahmen durch. Andernfalls kann der Zustand protokolliert werden.

Resource Pools-Framework

Die Konfigurationsdatei /etc/pooladm.conf enthält die Beschreibung der Static Pool-Konfiguration. Eine statische Konfiguration stellt dar, wie ein Administrator ein System unter Berücksichtigung der Resource Pools konfigurieren möchte. Es kann ein alternativer Dateiname verwendet werden.

Wenn die Service Management Facility (SMF) oder der Befehl pooladm - e zum Aktivieren des Resource Pools-Framework verwendet wird und die Datei /etc/pooladm.conf vorhanden ist, wird die in dieser Datei enthaltene Konfiguration für das System angewendet.

Der Kernel enthält Informationen zur Disposition von Ressourcen innerhalb des Resource Pools-Framework. Dies wird als dynamische Konfiguration bezeichnet. Sie repräsentiert die Resource Pools für ein bestimmtes System zu einem bestimmten Zeitpunkt. Die dynamische Konfiguration kann mit dem Befehl pooladm angezeigt werden. Beachten Sie, dass die Reihenfolge, in der die Eigenschaften für Pools und Ressourcensets angezeigt werden, variieren kann. Änderungen an der dynamischen Konfiguration können wie folgt vorgenommen werden:

Es können mehrere Konfigurationsdateien für statische Pools vorhanden sein, die zu unterschiedlichen Zeiten aktiviert werden. Mit dem Befehl pooladm von einem cron-Job aus können Sie zwischen den verschiedenen Pool-Konfigurationen wechseln. Weitere Informationen zum Dienstprogramm cron finden Sie in der Manpage cron(1M).

In der Standardeinstellung ist das Resource Pools-Framework nicht aktiviert. Zum Erstellen oder Ändern einer dynamischen Konfiguration müssen Resource Pools aktiviert sein. Statische Konfigurationsdateien können auch dann mit dem Befehl poolcfg oder libpool bearbeitet werden, wenn das Resource Pools-Framework deaktiviert ist. Wenn keine Pools aktiv ist, können auch keine statischen Konfigurationsdateien erstellt werden. Weitere Informationen zur Konfigurationsdatei finden Sie unter Erstellen von Pool-Konfigurationen.

Die Befehle, die mit Resource Pools und dem Systemdaemon poold verwendet werden können, sind in den folgenden Manpages beschrieben:

/etc/pooladm.conf – Inhalt

Alle Resource Pool-Konfigurationen, einschließlich der dynamischen Konfiguration, können die folgenden Elemente enthalten.

system

Eigenschaften, die sich auf das Gesamtverhalten des Systems auswirken

pool

Eine Resource Pool-Definition

pset

Eine Prozessorset-Definition

cpu

Eine Prozessor-Definition

Alle diese Elemente besitzen Eigenschaften, die geändert werden können, um Status und Verhalten des Resource Pools-Frameworks zu manipulieren. Beispielsweise gibt die Pool-Eigenschaft pool.importance die relative Wichtigkeit eines bestimmten Pools an. Diese Eigenschaft wird zur Auflösung eines möglichen Konflikts um Ressourcen verwendet. Weitere Informationen finden Sie unter libpool(3LIB).

Eigenschaften von Pools

Die Funktion Pools unterstützt benannte, typisierte Eigenschaften, die für einen Pool, eine Ressource oder eine Komponente eingerichtet werden können. Administratoren können für verschiedene Pool-Elemente zusätzliche Eigenschaften speichern. Dabei wird der Namespace einer Eigenschaft ähnlich einem Projektattribut verwendet.

Beispielsweise kennzeichnet der folgende Kommentar, dass ein bestimmtes pset einer bestimmten Datatree-Datenbank zugewiesen wurde.

Datatree,pset.dbname=warehouse

Weitere Informationen zu Eigenschaftentypen finden Sie unter poold-Eigenschaften.

Hinweis –

Eine Reihe von speziellen Eigenschaften ist für die interne Verwendung reserviert und kann nicht geändert oder entfernt werden. Weitere Informationen finden Sie in der Manpage libpool(3LIB).

Implementieren von Pools auf einem System

Benutzerdefinierte Pools können mithilfe einer der folgenden Methoden auf einem System implementiert werden.

Weitere Informationen zum Aktivieren und Deaktivieren von Resource Pools finden Sie unter Aktivieren und Deaktivieren von Pools. Pools können nicht deaktiviert werden, wenn benutzerdefinierte Pools oder Ressourcen verwendet werden.

Zum Konfigurieren von Resource Pools müssen Sie als Superuser angemeldet sein oder über das Process Management-Profil verfügen. Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil.

Der Ressource-Controller poold wird mit den Dynamic Resource Pools gestartet.

project.pool – Attribut

Das Attribut project.pool kann einem Projekteintrag in der Datei /etc/project hinzugefügt werden, um diesem Eintrag einem bestimmten Pool zuzuweisen. Neue Arbeiten, die im Rahmen eines Projekts gestartet werden, sind dann an diesen Pool gebunden. Weitere Informationen finden Sie in Kapitel 2Einführung in Projekte und Aufgaben.

Beispielsweise können Sie den Befehl projmod eingeben, um das Attribut project.pool für das Projekt sales in der Datei /etc/project einzurichten:


# projmod -a -K project.pool=mypool sales

SPARC: Dynamic Reconfiguration-Vorgänge und Resource Pools

Mit der Dynamic Reconfiguration (DR) können Sie Hardware bei laufendem System neu konfigurieren. Ein DR-Vorgang kann einen bestimmten Ressourcentyp vergrößern, verkleinern oder keine Auswirkungen zeigen. Da die DR verfügbaren Ressourcenmengen beeinflussen kann, müssen die Pools in diese Vorgänge mit einbezogen werden. Wenn ein DR-Vorgang initiiert wird, wird die Konfiguration vom Pools-Framework validiert.

Wenn der DR-Vorgang fortgesetzt werden kann, ohne dass die aktuelle Pool-Konfiguration ungültig wird, wird die private Konfigurationsdatei aktualisiert. Eine ungültige Konfiguration kann von den verfügbaren Ressourcen nicht unterstützt werden.

Wird die Pool-Konfiguration durch den DR-Vorgang ungültig, schlägt der Vorgang fehl und Sie werden über eine Nachricht an das Nachrichtenprotokoll informiert. Wenn Sie den Abschluss der Konfiguration erzwingen möchten, müssen Sie die DR-Durchsetzungsoption verwenden. Die Pool-Konfiguration wird dann so modifiziert, dass sie der neuen Ressourcenkonfiguration entspricht. Weitere Informationen zum DR-Prozess und der Durchsetzungsoption finden Sie im Benutzerhandbuch zur Dynamic Reconfiguration der Sun-Hardware.

Wenn Sie Dynamic Resource Pools verwenden, kann eine Partition die Resource Control poold bei aktivem Daemon verlassen. Weitere Informationen finden Sie unter Identifizieren eines Ressourcenmangels.

Erstellen von Pool-Konfigurationen

Die Konfigurationsdatei enthält eine Beschreibung der auf dem System zu erstellenden Pools. Die Datei beschreibt die Elemente, die manipuliert werden können.

Weitere Informationen zu den manipulierbaren Elementen finden Sie in der Manpage poolcfg(1M).

Wenn Pools aktiviert sind, können Sie auf zwei Arten eine strukturierte /etc/pooladm.conf-Datei erstellen.

Geben Sie den Befehl poolcfg oder libpool ein, um die Datei /etc/pooladm.conf zu bearbeiten. Bearbeiten Sie diese Dateien nicht direkt.

Direktes Bearbeiten der dynamischen Konfiguration

Sie können die CPU-Ressourcentypen in der dynamischen Konfiguration direkt bearbeiten, indem Sie den Befehl poolcfg mit der Option -d eingeben. Zur Übertragung von Ressourcen gibt es zwei Methoden.

Ein Beispiel finden Sie unter Übertragen von Ressourcen.

Beachten Sie, dass die Übertragung einer Ressource eine Aktion vonpoold auslösen könnte. Weitere Informationen finden Sie unter poold – Übersicht.

poold – Übersicht

Der Ressourcen-Controller für Pools, poold, verwendet die Systemziele und überwachbare Statistiken, um die von Ihnen angegebenen Ziele bei der Systemleistung einzuhalten. Dieser Systemdaemon muss stets aktiv sein, wenn eine dynamische Zuordnung von Ressourcen erforderlich ist.

Der Ressourcen-Controller poold identifiziert verfügbare Ressourcen und überwacht dann Arbeitslasten, um festzustellen, wenn die Systemauslastungsziele nicht mehr eingehalten werden. poold berücksichtigt in diesem Fall alternative Konfigurationen und leitet Korrekturmaßnahmen ein. Wenn möglich, werden die Ressourcen neu konfiguriert, so dass die Ziele eingehalten werden können. Ist dies nicht möglich, protokolliert der Daemon, dass die benutzerdefinierten Ziele nicht mehr eingehalten werden können. Nach einer Neukonfiguration setzt der Daemon die Überwachung der Arbeitslastziele fort.

poold verwaltet ein Protokoll über den Verlauf der Entscheidungen. Mithilfe dieses Verlaufsprotokolls werden mögliche Neukonfigurationen eliminiert, die in der Vergangenheit zu keinen Verbesserungen geführt haben.

Beachten Sie, dass eine Neukonfigurationen auch asynchron ausgelöst werden kann, wenn die Arbeitslastziele oder die auf dem System verfügbaren Ressourcen geändert wurden.

Verwalten von Dynamic Resource Pools

Der DRP-Service wird von der Service Management Facility (SMF) unter der Servicebezeichnung svc:/system/pools/dynamic verwaltet.

Administrative Maßnahmen an diesem Service, z. B. Aktivieren, Deaktivieren oder Anfordern eines Neustart können mithilfe des Befehlssvcadm vorgenommen werden. Der Status des Services kann mithilfe des Befehls svcs abgefragt werden. Weitere Informationen finden Sie in den Manpages svcs(1) und svcadm(1M).

Die SMF-Schnittstelle ist die bevorzugte Methode zur Steuerung der DRP, aus Gründen der Abwärtskompatibilität können aber auch die folgenden Methoden verwendet werden.

Konfigurationseinschränkungen und -ziele

Wenn Sie Änderungen an einer Konfiguration vornehmen, hält sich poold an Ihre Anweisungen. Sie geben diese Anweisungen als Einschränkungen und Ziele ein. poold ermittelt anhand Ihrer Angaben den relativen Wert verschiedener Konfigurationsmöglichkeiten in Relation zur vorhandenen Konfiguration. poold ändert dann die Ressourcenzuweisungen der aktuellen Konfiguration, und erstellt so neue Konfigurationen, die als Kandidaten zur Übernahme gelten.

Konfigurationseinschränkungen

Einschränkungen reduzieren die Anzahl möglicher Konfigurationen, indem sie einige potentielle Änderungen eliminieren, die an einer Konfiguration vorgenommen werden können. Die folgenden Einschränkungen stehen zur Verfügung. Sie werden in der libpool-Konfiguration angegeben.

Weitere Informationen zu den Pools-Eigenschaften finden Sie in der Manpage libpool(3LIB) und unter Eigenschaften von Pools.

pset.min-Eigenschaft und pset.max-Eigenschafteneinschränkungen

Diese beiden Eigenschaften legen Grenzwerte (Maximum und Minimum) für die Anzahl der Prozessoren fest, die einem Prozessorset zugewiesen werden können. Weitere·Informationen zu diesen Eigenschaften finden Sie in Tabelle 12–1.

Im Rahmen dieser Einschränkungen können die Ressourcen einer Ressourcenpartition beliebigen anderen Ressourcenpartitionen in der gleichen Solaris-Instanz zugeordnet werden. Der Zugriff auf diese Ressourcen erfolgt durch das Binden an einen Pool, der dem Ressourcenset zugewiesen ist. Das Binden erfolgt entweder bei der Anmeldung oder manuell durch einen Administrator, der über die Berechtigung PRIV_SYS_RES_CONFIG verfügt.

cpu.pinned-Eigenschafteneinschränkung

Die Eigenschaft cpu-pinned kennzeichnet, dass eine bestimmte CPU nicht durch DRP aus dem aktuellen Prozessorset verschoben werden darf. Sie können diese libpool-Eigenschaft einrichten, um die Cache-Auslastung für eine bestimmte Anwendung zu maximieren, die innerhalb eines Prozessorsets ausgeführt wird.

Weitere Informationen zu dieser Eigenschaft finden Sie in Tabelle 12–1.

pool.importance-Eigenschafteneinschränkung

Die Eigenschaft pool.importance beschreibt die relative Wichtigkeit eines Pools gemäß der Definition durch den Administrator.

Konfigurationsziele

Ziele werden ähnlich wie Einschränkungen angegeben. Das vollständige Ziel-Set ist in Tabelle 12–1 dokumentiert.

Es gibt zwei Kategorien von Zielen.

Arbeitslastabhängig

Ein arbeitslastabhängiges Ziel ändert sich mit der Arbeitslast, die auf einem System ausgeführt wird. Ein Beispiel wäre das Ziel utilization. Der Wert für die Auslastung (utilization) eines Ressourcensets ändert sich je nach der im Set aktiven Arbeitslast.

Arbeitslastunabhängig

Ein arbeitslastabhängiges Ziel ändert sich nicht mit der Arbeitslast, die auf einem System ausgeführt wird. Ein Beispiel wäre das CPU-Ziel locality. Die ausgewertete Messung der Lokalität (locality) eines Ressourcensets ändert sich nicht mit der Arbeitslast, die auf einem System ausgeführt wird.

Sie können drei Arten von Zielen definieren.

Name 

Gültige Elemente 

Operatoren 

Werte 

wt-load

system

entf. 

entf. 

locality

pset

entf. 

loose | tight | none

utilization

pset

< > ~

0–100%

Ziele werden in den Eigenschaftenstrings der libpool-Konfiguration gespeichert. Die Eigenschaftennamen lauten wie folgt:

Ziele haben die folgende Syntax:

Alle Ziele können ein optionales Präfix für die Wichtigkeit aufnehmen. Diese Wichtigkeit dient als ein Multiplikator für das Ziel und erhöht somit die Bedeutung des Beitrags zur Auswertung der Zielfunktion. Der Bereich erstreckt sich von 0 bis INT64_MAX (9223372036854775807). Wenn kein Wert angegeben ist, lautet der Standardwert für die Wichtigkeit 1.

Einige Elementtypen unterstützen mehrere Zieltypen. Ein Beispiel hierfür ist pset. Für diese Elemente können Sie mehrere Zieltypen angeben. Außerdem können Sie mehrere Auslastungsziele für ein einzelnespset-Element angeben.

Anwendungsbeispiele finden Sie unter So definieren Sie Konfigurationsziele.

wt-load-Ziel

Das Ziel wt-load begünstigt Konfigurationen, bei denen die Ressourcenzuordnungen mit den Ressourcenauslastungen übereinstimmen. Wenn dieses Ziel aktiv ist, erhält ein Ressourcenset, das mehr Ressourcen verwendet, mehr Ressourcen. wt-load bedeutet weighted load (gewichtete Last).

Verwenden Sie dieses Ziel, wenn Sie mit den Einschränkungen zufrieden sind, die Sie mithilfe der Minimum- und Maximum-Eigenschaften eingerichtet haben, und wenn der Daemon die Ressourcen innerhalb dieser Einschränkungen frei manipulieren soll.

locality-Ziel

Das Ziel locality wirkt sich auf den Einfluss aus, den die Lokalität (über die Daten der Locality Group (lgroup gemessen) auf die ausgewählte Konfiguration hat. Eine alternative Definition für Lokalität ist Latenz. Eine lgroup beschreibt CPU- und Speicherressourcen. Die lgroup wird vom Solaris-System verwendet, um den zeitlichen Abstand zwischen Ressourcen zu ermitteln. Weitere Informationen zur Locality Group-Abstraktion finden Sie unter Locality Groups Overview in Programming Interfaces Guide.

Dieses Ziel kann einen der folgenden drei Werte annehmen:

tight

Bei dieser Einstellung werden Konfigurationen bevorzugt, bei denen die Resource Locality maximiert wird.

loose

Bei dieser Einstellung werden Konfigurationen bevorzugt, bei denen die Resource Locality minimiert wird.

none

Bei dieser Einstellung hat die Resource Locality keinen Einfluss auf die bevorzugte Konfiguration. Dies ist der Standardwert für das Ziel locality.

Im Allgemeinen sollte das Ziel locality auf tight gesetzt sein. Um die Speicherbandbreite zu maximieren bzw. den Einfluss von DR-Vorgängen auf ein Ressourcenset zu minimieren, können Sie dieses Ziel auf loose setzen oder die Standardeinstellung von none beibehalten.

utilization-Ziel

Das Ziel utilization begünstigt Konfigurationen, die den Partitionen Ressourcen zuordnen, die das angegebene Auslastungsziel nicht erreichen.

Dieses Ziel wird mithilfe von Operatoren und Werten angegeben. Folgende Operatoren stehen zur Verfügung:

<

Der „Kleiner-als“-Operator gekennzeichnet, dass der angegebene Wert den maximalen Zielwert darstellt.

>

Der „Größer-als“-Operator gekennzeichnet, dass der angegebene Wert den minimalen Zielwert darstellt.

~

Der „Circa“-Operator kennzeichnet, dass der angegebene Wert ein Zielwert ist, für den eine gewisse Schwankung akzeptabel ist.

Bei einem pset kann nur ein Auslastungsziel für jeden Operatortyp festgelegt werden.

Sie können einen <- und einen >-Operator zusammen verwenden, um einen Bereich zu erstellen. Die Werte werden validiert, um sicherzustellen, dass sie einander nicht überschneiden.

Beispiel für Konfigurationsziele

In dem folgenden Beispiel wird poold zum Auswerten der folgenden Eigenschaften für das pset verwendet:

Beispiel 12–1 poold-Beispielziel

pset.poold.objectives "utilization > 30; utilization < 80; locality tight"

Weitere Nutzungsbeispiele finden Sie unter So definieren Sie Konfigurationsziele.

poold-Eigenschaften

Es gibt vier Eigenschaftenkategorien:

Tabelle 12–1 Definierte Eigenschaftennamen

Eigenschaft 

Typ 

Kategorie 

Beschreibung 

system.poold.log-level

string 

Konfiguration 

Protokollierungsebene 

system.poold.log-location

string 

Konfiguration 

Speicherort des Protokolls 

system.poold.monitor-interval

uint64 

Konfiguration 

Messintervall bei der Überwachung 

system.poold.history-file

string 

Konfiguration 

Speicherort des Entscheidungsverlaufs 

pset.max

uint64 

Einschränkung 

Maximale Anzahl der CPUs für dieses Prozessorset 

pset.min

uint64 

Einschränkung 

Minimale Anzahl der CPUs für dieses Prozessorset 

cpu.pinned

boolesch 

Einschränkung 

An dieses Prozessorset fixierte CPUs 

system.poold.objectives

string 

Ziel 

Formatierter String folgt der Syntax des poold-Zielausdrucks

pset.poold.objectives

string 

Ziel 

Formatierter String folgt der Syntax des poold-Ausdrucks

pool.importance

int64 

Zielparameter 

Vom Benutzer zugewiesene Wichtigkeit 

poold-Merkmale, die konfiguriert werden können

Die folgenden Aspekte des Daemon-Verhaltens können konfiguriert werden.

Diese Optionen werden in der Pool-Konfiguration angegeben. Sie können die Protokollierungsebene auch mit dem Befehl poold von der Befehlszeile aus ändern.

poold-Überwachungsintervall

Mit dem Eigenschaftennamen system.poold.monitor-interval geben Sie einen Wert in Millisekunden an.

poold-Protokollierungsinformationen

Mit der Protokollierung werden drei Informationskategorien bereitgestellt. In den Protokollen werden die folgenden Kategorien aufgeführt:

Mit dem Eigenschaftennamen system.poold.log-level geben Sie die Protokollierungsparameter an. Wenn diese Eigenschaft nicht angegeben ist, lautet die standardmäßige Protokollierungsebene NOTICE. Die Parameterebenen sind hierarchisch angeordnet. Bei der Protokollierungsebene DEBUG protokolliert poold alle definierten Meldungen. Die Ebene INFO stellt den meisten Administratoren alle wichtigen Informationen zur Verfügung.

Sie können den Befehl poold mit der Option -l an der Befehlszeile eingeben und einen Parameter hinzufügen, um die Ebene der erzeugten Protokollierungsinformationen festzulegen.

Die folgenden Parameter sind verfügbar:

Die Parameterebenen entsprechend direkt ihren syslog-Äquivalenten. Weitere Informationen zur Verwendung von syslog finden Sie unter Speicherort des Protokolls.

Informationen zum Konfigurieren der poold--Protokollierung finden Sie unter So richten Sie die Protokollierungsebene für poold ein.

Konfiguration der Informationsprotokollierung

Die folgenden Meldungsarten können erzeugt werden:

ALERT

Probleme beim Zugriff auf die libpool-Konfiguration oder ein anderer fundamentaler und unerwarteter Fehler bei der libpool-Funktion. Der Daemon wird beendet und es sind sofortige administrative Maßnahmen erforderlich.

CRIT

Probleme aufgrund unerwarteter Fehler. Der Daemon wird beendet und es sind sofortige administrative Maßnahmen erforderlich.

ERR

Probleme mit benutzerdefinierten Parametern, die Vorgänge steuern, zum Beispiel nicht auflösbare, widersprüchliche Auslastungsziele für ein Ressourcenset. Erfordert administrative Maßnahmen zur Berichtigung der Ziele. poold versucht Korrekturmaßnahmen einzuleiten, indem widersprüchlichen Ziele ignoriert werden, aber bestimmte Fehler führen dazu, dass der Daemon beendet wird.

WARNING

Warnungen hinsichtlich der Einstellungen von Konfigurationsparametern, die zwar technisch korrekt, für die vorgegebene Ausführungsumgebung jedoch ungeeignet sind. Ein Beispiel ist das Fixieren aller CPU-Ressourcen, so dass poold CPU-Ressourcen nicht zwischen Prozessorsets verschieben kann.

DEBUG

Es können Meldungen mit ausführlichen Informationen angezeigt werden, die zum Debuggen der Konfigurationsverarbeitung erforderlich sind. Diese Informationen werden von Administratoren nicht immer genutzt.

Überwachen der Informationsprotokollierung

Die folgenden Meldungsarten können erzeugt werden:

CRIT

Probleme aufgrund unerwarteter schwerwiegender Überwachungsfehler. Der Daemon wird beendet und es sind sofortige administrative Maßnahmen erforderlich.

ERR

Probleme aufgrund eines unerwarteten Überwachungsfehlers. Es sind eventuell Maßnahmen des Administrators erforderlich.

NOTICE

Meldungen über Wechsel der Resource Control-Region.

INFO

Meldungen zu den Ressourcen-Auslastungsstatistiken.

DEBUG

Es können Meldungen mit ausführlichen Informationen angezeigt werden, die beim Debuggen der Überwachungsverarbeitung erforderlich sind. Diese Informationen werden von Administratoren nicht immer genutzt.

Optimieren der Informationsprotokollierung

Die folgenden Meldungsarten können erzeugt werden:

WARNING

Es können Meldungen zu Problemen angezeigt werden, um optimale Entscheidungen zu treffen. Beispiele hierfür sind Ressourcensets, die durch vorgegebene Mindest- und Höchstwerte oder die Anzahl der fixierten Komponenten zu stark eingeschränkt sind.

Es können Meldungen bei Problemen angezeigt werden, wenn eine optimale Neuzuordnung aufgrund unvorhersehbarer Einschränkungen nicht durchgeführt werden kann. Beispiele hierfür sind das Entfernen des letzten Prozessors von einem Prozessorset, das einen gebundenen Ressourcenverbraucher enthält.

NOTICE

Es können Meldungen über nutzbare Konfigurationen oder Konfigurationen angezeigt werden, die durch das Überschreiben des Entscheidungsverlaufs nicht implementiert werden können.

INFO

Es können Meldungen über mögliche alternative Konfigurationen angezeigt werden.

DEBUG

Es können Meldungen mit ausführlichen Informationen angezeigt werden, die beim Debuggen der Optimierungsverarbeitung erforderlich sind. Diese Informationen werden von Administratoren nicht immer genutzt.

Speicherort des Protokolls

Mit der Eigenschaft system.poold.log-location können Sie den Speicherort der protokollierten Ausgabe von poold angeben. Sie können den Speicherort desSYSLOG für die poold-Ausgabe angeben (lesen Sie dazu syslog(3C)).

Wenn diese Eigenschaft nicht gesetzt ist, lautet der standardmäßige Speicherort der protokollierten Ausgabe von poold /var/log/pool/poold.

Erfolgt der Aufruf von poold von der Befehlszeile, wird diese Eigenschaft nicht verwendet. Protokolleinträge werden auf dem aufrufenden Terminal in stderr geschrieben.

Protokollmanagement mit logadm

Wenn poold aktiv ist, enthält die Datei logadm.conf einen Eintrag zur Verwaltung der Standarddatei /var/log/pool/poold. Dieser Eintrag lautet:

/var/log/pool/poold -N -s 512k

Weitere Informationen finden Sie in den Manpages logadm(1M) und logadm.conf(4).

So arbeitet die dynamische Ressourcenzuweisung

In diesem Abschnitt werden der Prozess und die Faktoren beschrieben, die poold zum dynamischen Zuweisen von Ressourcen verwendet.

Allgemeine Informationen zu verfügbaren Ressourcen

Verfügbaren Ressourcen sind alle Ressourcen, die innerhalb des Geltungsbereichs des poold-Prozesses zur Nutzung zur Verfügung stehen. Der Geltungsbereich einer Steuerung ist maximal eine einzelne Solaris-Instanz.

Auf einem System mit aktivierten Zonen ist der Geltungsbereich der ausgeführten poold-Instanz auf die globale Zone beschränkt.

Ermitteln der verfügbaren Ressourcen

Resource Pools umfassen alle Systemressourcen, die für den Verbrauch durch Anwendungen zur Verfügung stehen.

Bei einer ausgeführten Solaris-Instanz muss ein Ressourcentyp, z. B. eine CPU, einer einzelnen Partition zugeordnet sein. Es können eine oder mehrere Partitionen für jeden Ressourcentyp vorhanden sein. Jede Partition enthält ein einmaliges Ressourcenset.

Beispielsweise kann ein Computer mit vier CPUs und zwei Prozessorsets das folgende Setup haben:

pset 0: 0 1

pset 1: 2 3

dabei stellen 0, 1, 2 und 3 hinter dem Doppelpunkt die CPU-IDs dar. Beachten Sie, dass die zwei Prozessorsets alle vier CPUs aufnehmen.

Der gleiche Computer kann das folgende Setup nicht aufweisen:

pset 0: 0 1

pset 1: 1 2 3

Dieses Setup ist nicht möglich, da CPU 1 nur in einem pset erscheinen kann.

Ressourcen sind von anderen Partitionen als der, zu der sie gehören, nicht zugänglich.

Zum Erfassen der verfügbaren Ressourcen fragt poold die aktive Pool-Konfiguration ab, um Partitionen zu finden. Alle Ressourcen in allen Partitionen werden summiert, um die insgesamt zur Verfügung stehenden Ressourcen für jeden gesteuerten Ressourcentyp zu ermitteln.

Diese erfassten Ressourcen verwendet poold als Basiszahl für Berechnungen. Jedoch gelten bestimmte Einschränkungen für diese Zahl, die die Flexibilität von poold beim Erstellen der Zuweisungen beschränken. Informationen zu den verfügbaren Einschränkungen finden Sie unter Konfigurationseinschränkungen.

Identifizieren eines Ressourcenmangels

Der Steuerungsbereich von poold ist definiert als das verfügbare Ressourcenset, für das poold die primäre Verantwortung für effiziente Partitionierung und Verwaltung übernimmt. Es gibt jedoch noch weitere Mechanismen, die Ressourcen innerhalb dieses Steuerungsbereichs manipulieren können und sich so auf eine Konfiguration auswirken. Wenn eine Partition während poold aktiv ist, aus dem Steuerungsbereich entfernt wird, versucht poold die Steuerung durch eine vorsichtige Manipulation der verfügbaren Ressourcen wiederzustellen. Wenn poold keine zusätzlichen Ressourcen innerhalb des Geltungsbereichs lokalisieren kann, protokolliert der Daemon Informationen über den Ressourcenmangel.

Ermitteln der Ressourcenauslastung

poold wendet im Allgemeinen die meiste Zeit damit auf, die Ressourcenauslastung innerhalb des Steuerungsbereichs zu beobachten. Durch diese Überwachung wird sichergestellt, dass die arbeitslastabhängigen Ziele erreicht werden.

Beispielsweise werden bei Prozessorsets alle Messungen über alle Prozessoren in einem Set durchgeführt. Die Ressourcenauslastung zeigt den Anteil der Zeit, den die Ressource über das Messintervall genutzt wurde. Die Ressourcenauslastung wird als ein Prozentwert zwischen 0 und 100 angezeigt.

Identifizieren von Steuerungsverletzungen

Die unter Konfigurationseinschränkungen und -ziele beschriebenen Direktiven dienen zum Erfassen einer bevorstehenden Situation, bei der das System die vorgegebenen Ziele nicht mehr erreicht. Diese Ziele stehen in einem direkten Zusammenhang mit der Arbeitslast.

Eine Partition, die benutzerdefinierte Ziele nicht erreicht, wird als eine Steuerungsverletzung bezeichnet. Es gibt zwei Arten von Steuerungsverletzungen: synchrone und asynchrone.

Die folgenden Ereignisse können asynchrone Ziel-Verletzungen auslösen:

Die Beiträge von Zielen, die in keiner Beziehung zur Arbeitslast stehen, werden zwischen einzelnen Auswertungen von Zielen als gleichbleibend konstant betrachtet. Ziele, die in keiner Beziehung zur Arbeitslast stehen, werden nur dann neu ausgewertet, wenn aufgrund einer asynchronen Verletzung eine neue Auswertung ausgelöst wird.

Feststellen einer geeigneten Korrekturmaßnahme

Stellt der Ressourcen-Controller fest, dass es einem Ressourcenverbraucher an Ressourcen mangelt, werden zunächst die Ressourcen erhöht, um die Leistung zu verbessern.

Alternative Konfigurationen, mit denen sich die in der Konfiguration für den Steuerungsbereich angegebenen Ziele erreichen lassen, werden geprüft und ausgewertet.

Dieser Prozess wird über die Zeit weiter angepasst, da die Ergebnisse der Ressourcenänderungen überwacht und jede Ressourcenpartition auf deren Reaktionsfähigkeit geprüft wird. Mithilfe des Entscheidungsverlaufs können Neukonfigurationen eliminiert werden, die in der Vergangenheit zu keinen Verbesserungen geführt haben. Andere Informationen, z. B. Prozessnamen und Mengen, werden zur weiteren Auswertung der Verlaufsdaten herangezogen.

Wenn der Daemon keine Korrekturmaßnahmen ausführen kann, wird der Zustand protokolliert. Weitere Informationen finden Sie unter poold-Protokollierungsinformationen.

Verwenden von poolstat zur Überwachung der Pools und der Ressourcenauslastung

Mit dem Dienstprogramm poolstat wird die Ressourcenauslastung überwacht, wenn Pools auf dem System aktiviert sind. Dieses Dienstprogramm prüft wiederholt alle aktiven Pools auf dem System und zeichnet Statistiken basierend auf dem ausgewählten Ausgabemodus auf. Mithilfe der poolstat-Statistiken können Sie feststellen, welche Ressourcenpartitionen stark ausgelastet sind. Sie können diese Statistiken analysieren, um Entscheidungen über neue Ressourcenzuordnungen zu treffen, wenn das System mehr Ressourcen bereitstellen muss.

Das Dienstprogramm poolstat enthält Optionen, mit denen bestimmte Pools untersucht und Ressourcenset-spezifische Statistiken erstellt werden können.

Wenn Zonen auf dem System implementiert sind und Sie poolstat in einer nicht-globalen Zone verwenden, werden Informationen zu den Ressourcen angezeigt, die dem Pool der Zone zugeordnet sind.

Weitere Informationen zum Dienstprogramm poolstat finden Sie in der Manpage poolstat(1M) poolstat-Aufgaben- und Nutzungsinformationen finden Sie unter Verwenden von poolstat zum Erstellen von Statistiken über Pool-bezogene Ressourcen.

poolstat-Ausgabe

In der Standardeinstellung umfass die Ausgabe von poolstat eine Überschrift und eine Zeile für jeden Pool. Eine Pool-Zeile beginnt mit der Pool-ID und dem Namen des Pools, gefolgt von einer Spalte mit statistischen Daten zu dem Prozessorset, das an den Pool angehängt ist. Ressourcensets, die an mehrere Pools angehängt sind, werden mehrmals aufgeführt, jeweils einmal für jeden Pool.

Die Spaltenüberschriften lauten wie folgt:

id

Pool-ID.

pool

Pool-Name.

rid

Ressourcenset-ID.

rset

Ressourcenset-Name.

type

Ressourcenset-Typ.

min

Minimale Ressourcenset-Größe.

max

Maximale Ressourcenset-Größe.

size

Aktuelle Ressourcenset-Größe.

used

Eine Messung, wie viel des Ressourcensets derzeit verwendet wird.

Diese Nutzung wird als Prozentsatz der Ressourcensetauslastung multipliziert mit der Größe des Ressourcensets berechnet. Falls ein Ressourcenset während des letzten Messintervalls neu konfiguriert wurde, wird dieser Wert nicht aufgeführt. Ein nicht aufgeführter Wert erscheint als Strich (-).

load

Die absolute Darstellung der Last, die auf dem Ressourcenset liegt.

Weitere Informationen zu dieser Eigenschaft finden Sie in der Manpage libpool(3LIB).

Die Ausgabe von poolstat kann wie folgt angepasst werden:

Einstellen des Intervalls der poolstat-Ausführung

Sie können Einstellen, wie häufig die von poolstat durchgeführten Vorgänge ausgeführt werden. Sie können das Messintervall für den Bericht und die Häufigkeit festlegen, wie oft Statistiken wiederholt werden:

Intervall

Sie können die Intervalle für die regelmäßig von poolstat ausgeführten Vorgänge einstellen. Alle Intervalle werden in Sekunden angegeben.

Zählung

Legt die Häufigkeit fest, wie oft Statistiken wiederholt werden. Standardmäßig erfasst poolstat Statistiken nur einmal.

Wenn Intervall und Zählung nicht angegeben sind, werden die Statistiken nur einmal erfasst. Wenn Intervall angegeben und Zählung nicht angegeben ist, werden die Statistiken unendlich erfasst.

Mit Resource Pools verwendete Befehle

Die in der folgenden Tabelle aufgeführten Befehle stellen die primäre administrative Schnittstelle zu den Pools dar. Informationen zum Verwenden dieser Befehle auf einem System mit aktivierten Zonen finden Sie unter In Zonen verwendete Resource Pools.

Manpage 

Beschreibung 

pooladm(1M)

Aktiviert oder deaktiviert die Pools auf dem System. Aktiviert eine bestimmte Konfiguration oder entfernt die aktuelle Konfiguration und setzt die zugehörigen Ressourcen auf deren Standardstatus zurück. Bei Ausführung ohne Optionen druckt pooladm die aktuelle Konfiguration der dynamischen Pools.

poolbind(1M)

Aktiviert die manuelle Bindung von Projekten, Aufgaben und Prozessen an einen Resource Pool. 

poolcfg(1M)

Bietet Konfigurationsvorgänge für Pools und Sets. Mit diesem Tool erstellte Konfigurationen werden mithilfe von pooladm auf einem Zielhost instanziiert.

Bei Ausführung mit dem Unterbefehl info für die Option -c zeigt poolcfg Informationen zur statischen Konfiguration in /etc/pooladm.conf an. Wird ein Dateiname als Argument hinzugefügt, zeigt dieser Befehl Informationen zur statischen Konfiguration in der angegebenen Datei an. Beispielsweise zeigt poolcfg -c info /tmp/newconfig Informationen zur statischen Konfiguration in der Datei /tmp/newconfig an.

poold(1M)

Der System-Daemon der Pools. Der Daemon verwendet Systemziele und überwachbare Statistiken, um die vom Administrator angegebenen Ziele hinsichtlich der Systemleistung zu erreichen. Wenn der Daemon bei nicht erreichten Zielen keine Korrekturmaßnahmen ausführen kann, erfasst poold diesen Zustand in einem Protokoll.

poolstat(1M)

Zeigt Statistiken über Pool-bezogene Ressourcen an. Vereinfacht die Leistungsanalyse und stellt Informationen bereit, die Systemadministratoren bei der Ressourcenpartitionierung und Neupartitionierung unterstützen. Optionen helfen bei der Untersuchung der angegebenen Tools und der Zusammenstellung von Ressourcenset-spezifischen Statistiken. 

Eine Bibliothek-API wird für libpool bereitgestellt (lesen Sie dazu die Manpage libpool(3LIB) Die Bibliothek kann von Programmen zur Bearbeitung von Pool-Konfigurationen verwendet werden.