Ignorer les liens de navigation | |
Quitter l'aperu | |
![]() |
Administration d'Oracle Solaris 11.1 : Oracle Solaris Zones, Oracle Solaris 10 Zones et gestion des ressources Oracle Solaris 11.1 Information Library (Français) |
Partie I Gestion des ressources Oracle Solaris
1. Introduction à la gestion des ressources
2. Projets et tâches (présentation)
3. Administration des projets et des tâches
4. Comptabilisation étendue (présentation)
5. Administration de la comptabilisation étendue (tâches)
6. Contrôles de ressources (présentation)
7. Administration des contrôles des ressources (tâches)
8. Ordonnanceur FSS (présentation)
9. Administration de l'ordonnanceur FSS (tâches)
10. Contrôle de la mémoire physique à l'aide du démon de limitation des ressources (présentation)
11. Administration du démon de limitation des ressources (tâches)
12. Pools de ressources (présentation)
Introduction aux pools de ressources
Introduction aux pools de ressources dynamiques
Pools de ressources utilisés dans les zones
Structure des pools de ressources
Contenu du fichier /etc/pooladm.conf
Implémentation des pools sur un système
SPARC : opérations de reconfiguration dynamique et pools de ressources
Création de configurations de pools
Manipulation directe de la configuration dynamique
Gestion des pools de ressources dynamiques
Contraintes et objectifs de configuration
Propriété pset.min et contraintes de propriété pset.max
Contrainte de propriété cpu.pinned
Contrainte de propriété pool.importance
Fonctionnalités poold configurables
Intervalle de surveillance poold
Informations de consignation poold
Consignation des informations de configuration
Consignation des informations de surveillance
Consignation des informations d'optimisation
Gestion du journal avec logadm
Mode de fonctionnement de l'allocation dynamique des ressources
A propos des ressources disponibles
Détermination des ressources disponibles
Identification d'un manque de ressources
Détermination de l'utilisation des ressources
Identification des violations de contrôle
Détermination de l'action corrective appropriée
Utilisation de poolstat pour surveiller l'utilitaire des pools et l'utilisation des ressources
Réglage des intervalles d'exécution des opérations poolstat
Commandes utilisées avec l'utilitaire des pools de ressources
13. Création et administration des pools de ressources (tâches)
14. Exemple de configuration de la gestion des ressources
Partie II Oracle Solaris Zones
15. Introduction à Oracle Solaris Zones
16. Configuration des zones non globales (présentation)
17. Planification et configuration de zones non globales (tâches)
20. Connexion à une zone non globale (présentation)
21. Connexion à une zone non globale (tâches)
22. A propos des migrations de zones et de l'outil zonep2vchk
23. Migration de systèmes Oracle Solaris et migration de zones non globales (tâches)
25. Administration d'Oracle Solaris Zones (présentation)
26. Administration d'Oracle Solaris Zones (tâches)
27. Configuration et administration de zones immuables
28. Dépannage des problèmes liés à Oracle Solaris Zones
Partie III Oracle Solaris 10 Zones
29. Introduction à Oracle Solaris 10 Zones
30. Evaluation d'un système Oracle Solaris 10 et création d'une archive
32. Configuration de la zone marquée solaris10
33. Installation de la zone marquée solaris10
34. Initialisation d'une zone, connexion et migration de zone
Lorsque vous apportez des modifications à une configuration, poold agit dans le sens que vous indiquez, c'est-à-dire en tenant compte de la série de contraintes et d'objectifs que vous définissez. poold utilise vos spécifications pour juger de la valeur relative des différentes possibilités de configuration par rapport à la configuration existante. poold change ensuite les affectations de ressources de la configuration actuelle pour établir les nouvelles configurations candidates.
Les contraintes limitent l'étendue des configurations possibles en empêchant certaines modifications potentielles. Les contraintes suivantes, spécifiées dans la configuration libpool, sont disponibles.
Allocations minimum et maximum de la CPU
Composants rattachés non transférables d'un jeu à un autre
Importance du facteur de pool
Pour plus d'informations au sujet des propriétés des pools, reportez-vous à la page de manuel libpool(3LIB) et à la section Propriétés des pools.
Pour plus d'instructions, reportez-vous à la section Définition des contraintes de configuration.
Ces deux propriétés fixent le nombre limite de processeurs (valeurs minimum et maximum) qu'il est possible d'allouer à un jeu de processeurs. Pour en savoir plus sur ces propriétés, reportez-vous au Tableau 12-1.
En vertu de ces contraintes, les ressources d'une partition peuvent être allouées à d'autres partitions dans la même instance Oracle Solaris. Pour accéder à la ressource, il convient d'établir une liaison avec un pool associé au lot de ressources. La liaison est réalisée automatiquement au moment de la connexion ou manuellement par un administrateur doté du privilège PRIV_SYS_RES_CONFIG.
La propriété cpu-pinned stipule que le service des pools de ressources dynamiques n'est pas habilité à transférer une CPU donnée à partir de son jeu de processeurs d'origine. Vous pouvez définir cette propriété libpool pour optimiser l'utilisation du cache d'une application s'exécutant dans un jeu de processeurs.
Pour en savoir plus sur cette propriété, reportez-vous au Tableau 12-1.
La propriété pool.importance décrit l'importance relative d'un pool tel qu'elle est définie par l'administrateur.
Les objectifs sont définis de la même manière que pour les contraintes. L'ensemble complet d'objectifs est documenté dans le Tableau 12-1.
Il existe deux catégories d'objectifs.
Il s'agit d'un objectif qui varie en fonction de la nature de la charge de travail s'exécutant sur le système, à l'image de l'objectif utilization. Le chiffre d'utilisation pour un lot de ressources dépend de la nature de la charge de travail active.
Il s'agit d'un objectif qui ne varie pas en fonction de la nature de la charge de travail s'exécutant sur le système. C'est le cas de l'objectif CPU locality. L'estimation du voisinage d'un lot de ressources ne dépend pas de la nature de la charge de travail active.
Vous pouvez définir trois types d'objectif.
|
Les objectifs sont stockés dans les chaînes de propriétés dans la configuration libpool. Les noms des propriétés se présentent de la façon suivante :
system.poold.objectives
pset.poold.objectives
La syntaxe des objectifs est la suivante :
objectives = objective [; objective]*
objective = [n:] keyword [op] [value]
Tous les objectifs possèdent un préfixe relatif au niveau d'importance (facultatif). Ce niveau d'importance fait office de multiplicateur pour l'objectif et augmente par conséquent sa contribution à l'évaluation de la fonction de l'objectif. La plage d'évaluation va de 0 à INT64_MAX (9223372036854775807). Si vous omettez de spécifier le niveau d'importance, la valeur par défaut est 1.
Certains types d'élément acceptent plusieurs types d'objectif. C'est le cas, par exemple, de pset. Vous pouvez, en effet, définir plusieurs types d'objectif pour ces éléments. Il est possible également de fixer plusieurs objectifs d'utilisation pour un même élément pset.
La section Etablissement des objectifs de configuration propose plusieurs exemples d'utilisation.
L'objectif wt-load favorise les configurations faisant correspondre les allocations aux utilisations réelles des ressources. Un lot de ressources nécessitant plus de ressources bénéficiera de plus de ressources lorsque cette objectif est actif. wt-load est l'abréviation de weighted load (charge pondérée).
Utilisez cet objectif lorsque vous êtes satisfait des contraintes que vous avez établies à l'aide des propriétés minimum et maximum et souhaitez que le démon manipule librement les ressources dans les limites autorisées.
L'objectif locality change l'impact du voisinage, tel qu'il est mesuré par les données du groupe de voisinages (lgroup), sur la configuration sélectionnée. La latence est une autre définition du voisinage. lgroup décrit les ressources de la CPU et de la mémoire. lgroup est utilisé par le système Oracle Solaris pour déterminer la distance entre les ressources en fonction du facteur temps. Pour plus d'informations sur l'abstraction du groupe de voisinages, reportez-vous à la section Locality Groups Overview du manuel Programming Interfaces Guide.
Cet objectif peut prendre l'une des trois valeurs suivantes :
Si cette valeur est définie, les configurations qui maximisent le voisinage des ressources sont favorisées.
Si cette valeur est définie, les configurations qui minimisent le voisinage des ressources sont favorisées.
Si cette valeur est définie, le voisinage des ressources n'a pas d'influence sur les configurations favorisées. Il s'agit de la valeur par défaut de l'objectif locality.
En général, l'objectif locality doit être défini sur tight. Cependant, pour optimiser la bande passante de la mémoire ou minimiser l'impact des opérations de reconfiguration dynamique sur un lot de ressources, vous pouvez lui donner la valeur loose ou conserver le paramètre par défaut (none).
L'objectif utilization favorise les configurations allouant des ressources aux partitions ne satisfaisant pas l'objectif d'utilisation spécifié.
Il est défini au moyen d'opérateurs et de valeurs. Les opérateurs qu'il est possible d'utiliser sont les suivants :
L'opérateur "inférieur à" indique que la valeur spécifiée représente une valeur cible maximum.
L'opérateur "supérieur à" indique que la valeur spécifiée représente une valeur cible minimum.
Cet opérateur Indique que la valeur spécifiée est la valeur cible pour laquelle une certaine fluctuation est acceptable.
Un seul objectif d'utilisation peut être prévu pour chaque type d'opérateur dans le cadre d'un jeu de processeurs (pset).
Si vous utilisez l'opérateur ~, les opérateurs < et > ne sont pas exploitables.
De la même manière, si vous utilisez les opérateurs < et >, vous n'avez pas accès à l'opérateur ~. Les paramètres de l'opérateur < et de l'opérateur > ne peuvent pas être contradictoires.
Vous pouvez combiner un opérateur < et un opérateur > pour définir une plage. Les valeurs seront validées pour éviter tout chevauchement.
Dans l'exemple suivant, poold permet d'évaluer ces objectifs pour le jeu de processeurs (pset) :
L'objectif utilization doit être maintenu entre 30 et 80 %.
L'objectif locality doit être maximisé pour le jeu de processeurs.
Il convient d'accorder le niveau d'importance par défaut (1) aux objectifs.
Exemple 12-1 Evaluation des objectifs avec poold
pset.poold.objectives "utilization > 30; utilization < 80; locality tight"
La section Etablissement des objectifs de configuration propose plusieurs exemples supplémentaires d'utilisation.
Il existe quatre catégories de propriétés :
Configuration
Contrainte
Objectif
Paramètre d'objectif
Tableau 12-1 Noms des propriétés définies
|