Navigationslinks überspringen | |
Druckansicht beenden | |
![]() |
SystemAdministrationshandbuch: Oracle Solaris Container - RessourcenAdministration und Solaris Zones Oracle Solaris 10 1/13 Information Library (Deutsch) |
1. Einführung in Solaris 10-RessourcenAdministration
2. Einführung in Projekte und Aufgaben
3. Verwalten von Projekten und Aufgaben (Vorgehen)
4. Einführung in das Extended Accounting
5. Verwalten des Extended Accounting (Vorgehen)
6. Einführung in die Resource Controls
7. Verwalten von Resource Controls (Vorgehen)
8. Einführung in den Fair Share Scheduler
9. Verwalten des Fair Share Scheduler (Vorgehen)
10. Einführung in die Steuerung des reellen Arbeitsspeichers mithilfe des Resource Capping Daemons
11. Verwalten des Resource Capping Daemons (Vorgehen)
12. Einführung in Resource Pools
Neuerungen bei den Resource Pools und den Dynamic Resource Pools
Einführung in die Dynamic Resource Pools
In Zonen verwendete Resource Pools
Implementieren von Pools auf einem System
SPARC: Dynamic Reconfiguration-Vorgänge und Resource Pools
Erstellen von Pool-Konfigurationen
Direktes Bearbeiten der dynamischen Konfiguration
Verwalten von Dynamic Resource Pools
Konfigurationseinschränkungen und -ziele
pset.min-Eigenschaft und pset.max-Eigenschafteneinschränkungen
cpu.pinned-Eigenschafteneinschränkung
pool.importance-Eigenschafteneinschränkung
poold-Merkmale, die konfiguriert werden können
poold-Protokollierungsinformationen
Konfiguration der Informationsprotokollierung
Überwachen der Informationsprotokollierung
Optimieren der Informationsprotokollierung
Protokollmanagement mit logadm
So arbeitet die dynamische Ressourcenzuweisung
Allgemeine Informationen zu verfügbaren Ressourcen
Ermitteln der verfügbaren Ressourcen
Identifizieren eines Ressourcenmangels
Ermitteln der Ressourcenauslastung
Identifizieren von Steuerungsverletzungen
Feststellen einer geeigneten Korrekturmaßnahme
Verwenden von poolstat zur Überwachung der Pools und der Ressourcenauslastung
Einstellen des Intervalls der poolstat-Ausführung
Mit Resource Pools verwendete Befehle
13. Erstellen und Verwalten von Resource Pools (Vorgehen)
14. Beispiel für die Konfiguration der RessourcenAdministration
15. Resource Controls in der Solaris Management-Konsole
16. Einführung in Solaris Zones
17. Einführung in die Konfiguration einer nicht-globalen Zone
18. Planen und Konfigurieren von nicht-globalen Zonen (Vorgehen)
19. Einführung in das Installieren, Anhalten, Klonen und Deinstallieren von nicht-globalen Zonen
20. Installieren, Booten, Anhalten, Deinstallieren und Klonen von nicht-globalen Zonen (Vorgehen)
21. Einführung in das Anmeldeverfahren bei einer nicht-globalen Zone
22. Anmelden bei nicht-globalen Zonen (Vorgehen)
23. Verschieben und Migrieren von nicht-globalen Zonen (Vorgehen)
24. Oracle Solaris 10 9/10: Migrieren eines reellen Oracle Solaris-Systems in eine Zone (Aufgaben)
27. Verwaltung der Oracle Solaris-Zonen (Überblick)
28. Verwaltung der Oracle Solaris-Zonen (Aufgaben)
29. Aktualisieren eines Oracle Solaris 10-Systems mit installierten nicht-globalen Zonen
30. Behebung von verschiedenen Problemen mit Oracle Solaris Zones
31. Allgemeine Informationen zu Branded Zones und der Linux Branded Zone
32. Einführung in die Planung der Konfiguration einer lx Branded Zone
33. Konfigurieren einer lx Branded Zone (Vorgehen)
34. Einführung in das Installieren, Booten, Anhalten, Klonen und Deinstallieren von lx Branded Zones
35. Installieren, Booten, Anhalten, Deinstallieren und Klonen von lx Branded Zones (Vorgehen)
36. Anmelden bei lx Branded Zones (Vorgehen)
37. Verschieben und Migrieren von lx Branded Zones (Vorgehen)
38. Verwalten und Ausführen von Anwendungen in lx Branded Zones (Vorgehen)
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.
|
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.
Beispiel 12-1 poold-Beispielziel
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
Tabelle 12-1 Definierte Eigenschaftennamen
|