In diesem Kapitel werden die folgenden Themen behandelt:
Resource Pools, die zur Partitionierung von Computerressourcen verwendet werden
Dynamic Resource Pools (DRPs), mit denen die Ressourcenzuweisung von Resource Pools dynamisch eingestellt wird, um vorgegebene Systemziele zu erreichen
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).
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.
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.
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.
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).
Wie Sie Resource Pools und Dynamic Resource Pools aktivieren bzw. deaktivieren, können Sie unter Aktivieren und Deaktivieren von Pools nachlesen.
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.
Resource Pools stellen einen vielseitigen Mechanismus dar, der für viele verschiedene administrative Szenarios verwendet werden kann.
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.
Partitionieren Sie die Ressourcen für interaktive Anwendungen gemäß den Anforderungen der 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.
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.
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.)
Erstellen Sie mithilfe des RT-Scheduler und zugewiesenen Prozessorressourcen einen Echtzeit-Pool.
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.
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:
Indirekt, durch Anwenden einer statischen Konfigurationsdatei
Direkt mit dem Befehl poolcfg und der Option -d
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:
Alle Resource Pool-Konfigurationen, einschließlich der dynamischen Konfiguration, können die folgenden Elemente enthalten.
Eigenschaften, die sich auf das Gesamtverhalten des Systems auswirken
Eine Resource Pool-Definition
Eine Prozessorset-Definition
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).
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.
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).
Benutzerdefinierte Pools können mithilfe einer der folgenden Methoden auf einem System implementiert werden.
Beim Booten der Solaris-Software prüft das Skript init, ob die Datei /etc/pooladm.conf vorhanden ist. Wenn diese Datei gefunden wurde und Pools aktiviert sind, wird pooladm aufgerufen, um diese Konfigurationsdatei als aktive Pool-Konfiguration zu übernehmen. Das System erstellt eine dynamische Konfiguration, um die in der Datei /etc/pooladm.conf angeforderte Organisation widerzuspiegeln und partitioniert die Computerressourcen entsprechend.
Wenn das Solaris-System ausgeführt wird, kann eine Pool-Konfiguration entweder aktiviert werden (falls sie noch nicht vorhanden ist) oder mit dem Befehl pooladm geändert werden. In der Standardeinstellung wirkt sich der Befehl pooladm auf die Datei /etc/pooladm.conf aus. Sie können jedoch einen alternativen Speicherort und Dateinamen angeben, um eine andere Datei zum Aktualisieren der Pool-Konfiguration zu verwenden.
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.
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 |
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.
Die Konfigurationsdatei enthält eine Beschreibung der auf dem System zu erstellenden Pools. Die Datei beschreibt die Elemente, die manipuliert werden können.
system
pool
pset
cpu
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 pooladm mit der Option -s ein, um die Ressourcen auf den aktuellen Systemen zu erfassen und die Ergebnisse in eine Konfigurationsdatei zu schreiben.
Dies ist die bevorzugte Methode. Hierbei werden alle aktiven Ressourcen und Komponenten auf dem System aufgezeichnet, die über die Pools-Funktionen manipuliert werden können. Zu diesen Ressourcen gehören auch bereits vorhandene Prozessorset-Konfigurationen. Anschließend können Sie die Konfiguration bearbeiten, um die Prozessorsets umzubenennen oder gegebenenfalls zusätzliche Pools zu erstellen.
Geben Sie den Befehl poolcfg mit der Option-c und die Unterbefehle discover oder create system name ein, um eine neue Pool-Konfiguration zu erstellen.
Diese Optionen wurden zur Abwärtskompatibilität mit früheren Versionen beibehalten.
Geben Sie den Befehl poolcfg oder libpool ein, um die Datei /etc/pooladm.conf zu bearbeiten. Bearbeiten Sie diese Dateien nicht direkt.
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.
Sie können eine allgemeine Anfrage erstellen, um alle verfügbaren identifizierten Ressourcen zwischen Sets zu übertragen.
Sie können Ressourcen mit bestimmten IDs an ein Ziel-Set übertragen. Beachten Sie, dass sich die System-IDs von Ressourcen ändern können, wenn die Ressourcenkonfiguration modifiziert oder ein System neu gebootet wird.
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.
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.
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.
Wenn keine dynamische Ressourcenzuordnung erforderlich ist, kann poold mit dem Signal SIGQUIT oder SIGTERM gestoppt werden. Jedes dieser Signale führt zum ordnungsgemäßen Beenden von poold.
Obwohl poold Änderungen an den Ressourcen- oder Pool-Konfigurationen automatisch erfasst, können Sie mithilfe des Signals SIGHUP eine Neukonfiguration erzwingen.
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.
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.
Die maximalen und minimalen CPU-Zuweisungen
Fixierte Komponenten, die nicht aus einem Set verschoben werden können
Weitere Informationen zu den Pools-Eigenschaften finden Sie in der Manpage libpool(3LIB) und unter Eigenschaften von Pools.
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.
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.
Die Eigenschaft pool.importance beschreibt die relative Wichtigkeit eines Pools gemäß der Definition durch den Administrator.
Ziele werden ähnlich wie Einschränkungen angegeben. Das vollständige Ziel-Set ist in Tabelle 12–1 dokumentiert.
Es gibt zwei Kategorien von Zielen.
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.
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:
system.poold.objectives
pset.poold.objectives
Ziele haben die folgende Syntax:
objectives = objective [; objective]*
objective = [n:] keyword [op] [value]
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.
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.
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:
Bei dieser Einstellung werden Konfigurationen bevorzugt, bei denen die Resource Locality maximiert wird.
Bei dieser Einstellung werden Konfigurationen bevorzugt, bei denen die Resource Locality minimiert wird.
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.
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.
Wenn der Operator ~ festgelegt ist, können die Operatoren < und > nicht verwendet werden.
Wenn die Operatoren < und > festgelegt sind, kann der Operator ~ nicht verwendet werden. Die Einstellungen des <-Operators und des >-Operators schließen sich gegenseitig nicht aus.
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.
In dem folgenden Beispiel wird poold zum Auswerten der folgenden Eigenschaften für das pset verwendet:
Die utilization muss zwischen 30 % und 80 % gehalten werden.
Die locality muss für jedes Prozessorset maximiert sein.
Die Ziele müssen die Standardwichtigkeit von 1 annehmen.
pset.poold.objectives "utilization > 30; utilization < 80; locality tight"
Weitere Nutzungsbeispiele finden Sie unter So definieren Sie Konfigurationsziele.
Es gibt vier Eigenschaftenkategorien:
Konfiguration
Einschränkung
Ziel
Zielparameter
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 |
Die folgenden Aspekte des Daemon-Verhaltens können konfiguriert werden.
Überwachungsintervall
Protokollierungsebene
Speicherort des Protokolls
Diese Optionen werden in der Pool-Konfiguration angegeben. Sie können die Protokollierungsebene auch mit dem Befehl poold von der Befehlszeile aus ändern.
Mit dem Eigenschaftennamen system.poold.monitor-interval geben Sie einen Wert in Millisekunden an.
Mit der Protokollierung werden drei Informationskategorien bereitgestellt. In den Protokollen werden die folgenden Kategorien aufgeführt:
Konfiguration
Überwachung
Optimierung
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:
ALERT
CRIT
ERR
WARNING
NOTICE
INFO
DEBUG
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.
Die folgenden Meldungsarten können erzeugt werden:
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.
Probleme aufgrund unerwarteter Fehler. Der Daemon wird beendet und es sind sofortige administrative Maßnahmen erforderlich.
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.
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.
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.
Die folgenden Meldungsarten können erzeugt werden:
Probleme aufgrund unerwarteter schwerwiegender Überwachungsfehler. Der Daemon wird beendet und es sind sofortige administrative Maßnahmen erforderlich.
Probleme aufgrund eines unerwarteten Überwachungsfehlers. Es sind eventuell Maßnahmen des Administrators erforderlich.
Meldungen über Wechsel der Resource Control-Region.
Meldungen zu den Ressourcen-Auslastungsstatistiken.
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.
Die folgenden Meldungsarten können erzeugt werden:
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.
Es können Meldungen über nutzbare Konfigurationen oder Konfigurationen angezeigt werden, die durch das Überschreiben des Entscheidungsverlaufs nicht implementiert werden können.
Es können Meldungen über mögliche alternative Konfigurationen angezeigt werden.
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.
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.
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).
In diesem Abschnitt werden der Prozess und die Faktoren beschrieben, die poold zum dynamischen Zuweisen von Ressourcen verwendet.
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.
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.
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.
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.
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.
Eine synchrone Ziel-Verletzung wird vom Daemon während der Arbeitslastüberwachung festgestellt.
Eine asynchrone Ziel-Verletzung erfolgt unabhängig von der Überwachungsaktion des Daemons.
Die folgenden Ereignisse können asynchrone Ziel-Verletzungen auslösen:
Ressourcen, die einem Steuerungsbereich hinzugefügt oder daraus entfernt werden.
Der Steuerungsbereich wird neu konfiguriert.
Der Ressourcen-Controller poold wird neu gestartet.
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.
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.
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.
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:
Pool-ID.
Pool-Name.
Ressourcenset-ID.
Ressourcenset-Name.
Ressourcenset-Typ.
Minimale Ressourcenset-Größe.
Maximale Ressourcenset-Größe.
Aktuelle Ressourcenset-Größe.
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 (-).
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:
Die Reihenfolge der Spalten
Die angezeigten Überschriften
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:
Sie können die Intervalle für die regelmäßig von poolstat ausgeführten Vorgänge einstellen. Alle Intervalle werden in Sekunden angegeben.
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.
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 |
---|---|
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. |
|
Aktiviert die manuelle Bindung von Projekten, Aufgaben und Prozessen an einen Resource Pool. |
|
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. |
|
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. |
|
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.