Chapitre 12 Pools de ressources (présentation)

Ce chapitre traite des sujet suivants :

• pools de ressources : moyens utilisés pour partitionner les ressources des machines ;

• pools de ressources dynamiques (DRP) : moyens permettant de régler de façon dynamique l'allocation des ressources pour chaque pools de ressources afin de remplir les objectifs système qui ont été fixés.

À partir de la version Solaris 10 11/06, les pools de ressources et les pools de ressources dynamiques font partie intégrante de l'utilitaire de gestion des services Solaris (SMF). Ces services sont activés indépendamment les uns des autres.

Il comprend les sections suivantes :

• Introduction aux pools de ressources

• Introduction aux pools de ressources dynamiques

• À propos de l'activation et de la désactivation des pools de ressources et des pools de ressources dynamiques

• Pools de ressources utilisés dans les zones

• Intérêt des pools

• Structure des pools de ressources

• Implémentation des pools sur un système

• Attribut project.pool

• SPARC : opérations de reconfiguration dynamique et pools de ressources

• Création de configurations de pools

• Manipulation directe de la configuration dynamique

• Présentation de poold

• Gestion des pools de ressources dynamiques

• Contraintes et objectifs de configuration

• Fonctions poold pouvant être configurées

• Mode de fonctionnement de l'allocation dynamique des ressources

• Utilisation de poolstat pour contrôler l'utilitaire des pools et l'utilisation des ressources

• Commandes utilisées avec l'utilitaire des pools de ressources

Pour connaître les procédures tirant parti de cette fonctionnalité, reportez-vous au Chapitre 13Création et administration des pools de ressources (tâches).

Nouveautés propres aux pools de ressources et aux pools de ressources dynamiques

Solaris 10 : désormais, les pools de ressources sont dotés d'un mécanisme visant à ajuster l'allocation des ressources de chaque pool en réponse aux événements système et aux modifications des charges de travail des applications. Les pools de ressources dynamiques simplifient et réduisent le nombre des décisions exigées d'un administrateur. Les ajustements s'effectuent automatiquement de façon à respecter les objectifs de performances spécifiés par un administrateur.

Il est désormais possible d'exécuter la commande projmode pour définir l'attribut project.pool dans le fichier /etc/project.

Vous trouverez une liste complète des nouvelles fonctionnalités de Solaris 10 et la description des différentes versions de Solaris dans le guide Nouveautés apportées à Oracle Solaris 10 9/10.

Solaris 10 11/06 : les pools de ressources et les pools de ressources dynamiques sont à présent des services SMF.

Introduction aux pools de ressources

Les pools de ressources permettent de séparer des charges de travail de façon à éviter la surconsommation de certaines ressources. Cette réservation de ressource contribue à atteindre les perfomances attendues sur les systèmes combinant des charges de travail hybrides.

Les pools de ressources fournissent un mécanisme de configuration persistant en vue de la configuration du jeu de processeurs (pset) et, éventuellement, de l'assignation d'une classe de programmation.

Figure 12–1 Structure de pool de ressources

Il est possible de concevoir un pool comme la liaison spécifique des différents lots de ressources disponibles sur votre système. Vous pouvez créer des pools représentant les différents types de combinaisons de ressources possibles :

En regroupant plusieurs partitions, les pools fournissent un descripteur à associer aux charges de travail étiquetées. Chaque entrée de projet figurant dans le fichier /etc/project peut posséder un seul pool associé à cette entrée, spécifié grâce à l'attribut project.pool.

Lorsque les pools sont activés, un pool par défaut et un jeu de processeurs par défaut forment la configuration de base. Il est possible de créer d'autres pools et jeux de processeurs définis par l'utilisateur et de les ajouter à la configuration. Une CPU ne peut appartenir qu'à un seul jeu de processeurs. Les pools et les jeux de processeurs définis par l'utilisateur peuvent être détruits à la différence du pool par défaut et du jeu de processeurs par défaut.

La propriété pool.default du pool par défaut a la valeur true. La propriété pset.default du processeur par défaut a la valeur true. Ainsi, le pool et le jeu de processeurs par défaut restent identifiables même après modification de leurs noms.

Le mécanisme des pools défini par l'utilisateur est initialement prévu pour les ordinateurs équipés d'au moins quatre CPU. Néanmoins, des ordinateurs de plus petites tailles peuvent tirer parti de cette fonctionnalité. Sur ces ordinateurs, la création des pools permet de partager des partitions de ressources non vitales. La séparation en pools se fait exclusivement sur la base de ressources critiques.

Introduction aux pools de ressources dynamiques

Les pools de ressources dynamiques offrent un mécanisme permettant d'ajuster de manière dynamique l'allocation des ressources de chaque pool en réponse aux événements système et aux modifications des charges de travail des applications. Les pools de ressources dynamiques simplifient et réduisent le nombre des décisions exigées d'un administrateur. Les ajustements s'effectuent automatiquement de façon à respecter les objectifs de performances spécifiés par un administrateur. Les modifications apportées à la configuration sont consignées dans un journal. Ces fonctions sont principalement du ressort du contrôleur de ressources poold, un démon système qui doit toujours être actif lorsque l'affectation dynamique de ressources est requise. poold examine régulièrement la charge du système et détermine si une intervention est nécessaire pour permettre au système de maintenir des performances optimales dans le cadre de la consommation des ressources. La configuration poold est conservée au sein de la configuration libpool. Pour plus d'informations au sujet de poold, voir la page de manuel poold(1M).

À propos de l'activation et de la désactivation des pools de ressources et des pools de ressources dynamiques

Pour activer et désactiver les pools de ressources et les pools de ressources dynamiques, reportez-vous à la section Activation et désactivation de l'utilitaire Pools.

Pools de ressources utilisés dans les zones

Solaris 10 8/07 : au lieu d'associer une zone à un pool de ressources configuré sur votre système, vous pouvez utiliser la commande zonecfg pour créer un pool temporaire qui devient actif lorsque la zone est exécutée. Pour plus d'informations, reportez-vous à la section Solaris 10 8/07 : ressource dedicated-cpu.

Dans un système dont les zones sont activées, une zone non globale peut être associée à un pool de ressources bien que le pool n'ait pas besoin d'être exclusivement assigné à une zone spécifique. Par ailleurs, vous n'êtes pas en mesure de lier des processus de zones non globales à un pool différent à l'aide de la commande poolbind depuis la zone globale. Pour associer une zone non globale à un pool, reportez-vous à la section Configuration, vérification et validation d'une zone.

Notez que si vous définissez une classe de programmation pour un pool et que vous associez une zone non globale à ce pool, la zone utilise par défaut cette classe de programmation.

Si vous utilisez des pools de ressources dynamiques, la portée d'une instance d'exécution de poold se limite à la zone globale.

L'utilitaire poolstat affiche uniquement les informations relatives au pool associé à la zone non globale dans laquelle il s'exécute. La commande pooladm exécutée sans argument dans une zone non globale affiche uniquement les informations concernant le pool associé à la zone en question.

Pour plus d'informations sur les commandes de pools de ressources, reportez-vous à la section Commandes utilisées avec l'utilitaire des pools de ressources.

Intérêt des pools

Les pools de ressources proposent un mécanisme polyvalent applicable dans de nombreux cas de figure.

Serveur de calcul à traitement par lots

Utilisez la fonctionnalité des pools pour fractionner un serveur en deux pools. Un pool est dédié aux sessions de connexion et aux opérations interactives effectuées par les utilisateurs travaillant en mode de partage de temps. L'autre pool sert aux tâches soumises via le système de traitement par lots.

Serveur d'applications ou de bases de données

Partitionnez les ressources réservées aux applications interactives conformément aux besoins des applications.

Activation des applications par phases

Définissez les attentes des utilisateurs.

Vous pouvez, au départ, déployer un ordinateur exécutant une partie des services qu'il est censé fournir. Les utilisateurs peuvent éprouver des difficultés si les mécanismes de gestion de ressources basés sur la réservation ne sont pas établis à la connexion de l'ordinateur.

Par exemple, l'ordonnanceur FSS optimise l'utilisation de la CPU. Les délais de réponse d'un ordinateur n'exécutant qu'une seule application peuvent vous induire en erreur par leur rapidité. Les utilisateurs ne bénéficieront pas de tels délais de réponse lorsque plusieurs applications sont chargées. L'utilisation de pools distincts pour chaque application permet de fixer un plafond au nombre de CPU accessibles par chaque application avant de déployer toutes les applications.

Serveur de partage de temps complexe

Partitionnez un serveur prenant en charge des populations importantes d'utilisateurs. Le partitionnement de serveur est un mécanisme d'isolement qui permet de mieux anticiper les réponses par utilisateur.

En répartissant les utilisateurs en plusieurs groupes dépendant de pools distincts et en utilisant la fonctionnalité FSS, vous pouvez ajuster les allocations de CPU pour donner la priorité à des ensembles d'utilisateurs. Vous pouvez vous baser sur le rôle utilisateur, sur des critères d'imputation comptable, etc.

Charges de travail variant d'une saison à l'autre

Servez-vous des pools de ressources pour adapter les ressources en fonction de la demande.

Il est possible que les variations des charges de travail soient prévisibles sur votre site sur de longues périodes (cycles mensuels, trimestriels ou annuels, par exemple). Si c'est le cas, vous pouvez passer d'une configuration de pools à une autre en faisant appel à la commande pooladm à partir d'une tâche cron. (Voir Structure des pools de ressources.)

Applications en temps réel

Créez un pool en temps réel en utilisant l'ordonnanceur RT et les ressources désignées du processeur.

Utilisation du système

Imposez les objectifs système que vous fixez.

Servez-vous du démon de pools automatisé pour identifier les ressources disponibles, puis contrôlez les charges de travail afin de détecter à quel moment les objectifs spécifiés ne sont plus remplis. Le démon procède à des corrections si cela est possible ; sinon, la condition est enregistrée.

Structure des pools de ressources

Le fichier de configuration /etc/pooladm.conf décrit la configuration statique des pools. Une configuration statique représente la manière dont un administrateur aimerait configurer un système en fonction du pool de ressources. Il est possible de spécifier un autre nom de fichier.

Lorsque vous vous servez de l'utilitaire de gestion des services (SMF) ou de la commande pooladm -e pour activer la structure des pools de ressources, la configuration contenue dans le fichier /etc/pooladm.conf (si celui-ci existe) est appliquée au système.

Le noyau stocke des informations au sujet de la disposition des ressources au sein de la structure des pools de ressources. Ce procédé, appelé configuration dynamique, représente les pools de ressources pour un système particulier à un moment précis dans le temps. Vous pouvez examiner la configuration dynamique à l'aide de la commande pooladm. L'ordre d'affichage des propriétés pour les pools et les lots de ressources peut varier. Vous pouvez procéder de l'une ou l'autre des façons suivantes pour modifier la configuration dynamique :

• indirectement, en appliquant un fichier de configuration statique ;

• directement, en exécutant la commande poolcfg avec l'option -d.

Vous pouvez avoir le choix entre plusieurs fichiers de configuration statique de pools et activer ponctuellement celui qui convient le mieux. Il est possible de passer d'une configuration de pools à une autre en faisant appel à la commande pooladm à partir d'une tâche cron. Pour plus d'informations sur l'utilitaire cron, voir la page de manuel cron(1M).

Par défaut, la structure des pools de ressources n'est pas active. Or, il est indispensable d'activer les pools de ressources pour créer ou modifier la configuration dynamique. Vous pouvez manipuler des fichiers de configuration statique à l'aide des commandes poolcfg ou libpool même lorsque la structure des pools de ressources est désactivée. Il est cependant impossible de créer des fichiers de configuration statique si l'utilitaire des pools n'est pas en service. Pour plus d'informations au sujet du fichier de configuration, reportez-vous à la section Création de configurations de pools.

Les commandes utilisées avec les pools de ressources et le démon système poold sont décrites dans les pages de manuel suivantes :

• pooladm(1M) 

• poolbind(1M)

• poolcfg(1M)

• poold(1M)

• poolstat(1M)

• libpool(3LIB)

Contenu du fichier /etc/pooladm.conf

Toutes les configurations de pools de ressource, y compris la configuration dynamique, peuvent contenir les éléments suivants.

system

Propriétés ayant une incidence sur le comportement global du système

Pool

Définition du pool de ressources

pset

Définition du jeu de processeurs

cpu

Définition du processeur

Tous ces éléments possèdent des propriétés sur lesquelles vous pouvez intervenir pour changer l'état et le comportement de la structure des pools de ressources. La propriété de pool pool.importance indique, par exemple, l'importance relative d'un pool donné. Elle s'avère pratique pour résoudre des conflits d'utilisation des ressources. Pour plus d'informations, voir la page de manuel libpool(3LIB).

Propriétés des pools

L'utilitaire des pools prend en charge les propriétés nommées saisies applicables à un pool, une ressource ou un composant. Les administrateurs peuvent stocker des propriétés supplémentaires au sujet des divers éléments du pool. Ils utilisent pour cela un espace de noms de propriétés similaire à l'attribut de projet.

Le commentaire suivant indique, par exemple, qu'un jeu de processeurs donné est associé à une base de données Datatree particulière.

Datatree,pset.dbname=warehouse

Pour plus d'informations au sujet des types de propriété, reportez-vous à la section Propriétés poold.

Un certain nombre de propriétés spéciales est réservé à un usage interne. Il est impossible de les configurer ou de les supprimer. Pour plus d'informations, voir la page de manuel libpool(3LIB).

Implémentation des pools sur un système

Voici comment procéder pour mettre en œuvre sur un système les pools définis par les utilisateurs.

• Au démarrage du logiciel Solaris, un script init vérifie la présence du fichier /etc/pooladm.conf. S'il détecte ce fichier et si les pools sont activés, la commande pooladm est exécutée pour rendre active cette configuration de pools. Le système crée une configuration dynamique afin de refléter l'organisation demandée dans /etc/pooladm.conf et les ressources de la machine sont partitionnées en conséquence.

• Lors de l'exécution du système Solaris, vous avez la possibilité d'activer une configuration de pools si elle n'existe pas déjà, ou de la modifier à l'aide de la commande pooladm. Par défaut, la commande pooladm s'applique à /etc/pooladm.conf. Vous pouvez, cependant, choisir un autre emplacement et un autre nom de fichier et utiliser ce fichier pour mettre à jour la configuration de pools.

Pour savoir comment activer et désactiver des pools de ressources, reportez-vous à la section Activation et désactivation de l'utilitaire Pools. Il est impossible de désactiver l'utilitaire des pools lorsque des pools ou des ressources définis par l'utilisateur sont en cours d'utilisation.

Pour configurer les pools de ressources, vous devez disposer des privilèges de superutilisateur ou posséder le profil Gestion des processus dans votre liste de profils. Ce profil fait partie des prérogatives de l'administrateur système.

Le contrôleur de ressources poold est démarré à l'aide de l'utilitaire des pools de ressources dynamiques.

Attribut project.pool

L'attribut project.pool peut être ajouté à une entrée de projet dans le fichier /etc/project afin d'associer un pool à cette entrée. Tout nouveau travail démarré pour un projet est lié au pool approprié. Pour plus d'informations, reportez-vous au Chapitre 2Projets et tâches (présentation).

Vous pouvez, par exemple, vous servir de la commande projmod pour définir l'attribut project.pool pour le projet sales dans le fichier /etc/project :

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

SPARC : opérations de reconfiguration dynamique et pools de ressources

La reconfiguration dynamique, appelée aussi opération DR (Dynamic Reconfiguration), permet de reconfigurer le matériel lorsque le système est en cours d'exécution. Ce type d'opération permet d'augmenter ou de réduire un type de ressource, mais peut aussi n'avoir aucun impact. Comme les opérations DR peuvent influer sur les quantités de ressources disponibles, il est indispensable d'y associer l'utilitaire des pools. Lors du démarrrage d'une opération DR, la structure de pools se charge de valider la configuration.

Si l'opération DR peut se poursuivre sans risque de rendre non valide la configuration de pools actuelle, le fichier de configuration privé est mis à jour. Une configuration non valide est une configuration non compatible avec les ressources disponibles.

Si l'opération DR provoque l'invalidité de la configuration de pools, elle échoue et un message est consigné dans le journal correspondant. Dans ce cas, si vous souhaitez mener la configuration à son terme, vous devez utiliser l'option DR force. La configuration de pools est alors modifiée pour se conformer à la nouvelle configuration des ressources. Pour plus d'informations sur l'opération DR et l'option DR force, reportez-vous au guide utilisateur de la reconfiguration dynamique pour votre matériel Sun.

Si vous utilisez des pools de ressources dynamiques, sachez qu'il est possible d'extraire une partition du contrôle poold pendant que le démon est actif. Pour plus d'informations, reportez-vous à la section Identification d'un manque de ressources.

Création de configurations de pools

Le fichier de configuration contient une description des pools à créer sur le système. Il présente les différents éléments qu'il est possible de manipuler.

• StorageTek

• Pool

• pset

• cpu

Pour plus d'informations au sujet des éléments susceptibles d'être manipulés, voir la page de manuel poolcfg(1M).

Lorsque les pools sont activés, vous pouvez créer un fichier /etc/pooladm.conf structuré de deux façons.

• Vous pouvez exécuter la commande pooladm avec l'option -s afin de découvrir les ressources sur le système actuel et de placer les résultats dans un fichier de configuration.

  Il s'agit de la méthode préférée. L'intégralité des ressources et des composants actifs sur le système et manipulables par l'utilitaire de pools est prise en compte. Les ressources incluent les configurations de jeux de processeurs existantes. Vous êtes libre ensuite de modifier la configuration pour renommer les jeux de processeurs ou créer des pools supplémentaires, si cela est nécessaire.

• Pour définir une nouvelle configuration de pools, vous pouvez exécuter la commande poolcfg avec l'option -c et les sous-commandes discover ou create system nom.

  Ces options ont été préservées pour assurer la compatibilité avec la version précédente.

Servez-vous de poolcfg ou de libpool pour modifier le fichier /etc/pooladm.conf. N'éditez pas directement ce fichier.

Manipulation directe de la configuration dynamique

Il est possible de manipuler directement les types de ressources CPU dans la configuration dynamique en associant la commande poolcfg à l'option -d. Il existe deux méthodes pour transférer les ressources.

• Vous pouvez effectuer une requête générale afin de déplacer les ressources identifiées disponibles d'un jeu à un autre.

• Transférez, par exemple, des ressources avec des ID spécifiques vers un jeu de destination. Notez que les ID système associés aux ressources peuvent varier en cas de modification de la configuration des ressources ou après une réinitialisation du système.

Vous trouverez un exemple à ce sujet à la section Transfert des ressources.

Il faut savoir également que le transfert de ressource peut déclencher une action de poold. Pour plus d'informations, reportez-vous à la section Présentation de poold.

Présentation de poold

Le contrôleur des ressources des pools, poold, tire parti des cibles système et des statistiques observables pour atteindre les objectifs de performances que vous avez fixés. Ce démon système doit toujours rester actif lorsque l'allocation dynamique des ressources est nécessaire.

Le contrôleur des ressources poold identifie les ressources disponibles et contrôles les charges de travail pour savoir précisément à quel moment les objectifs d'utilisation système ne sont plus remplis. poold considère ensuite des configurations alternatives en termes d'objectifs et engage des actions correctives. Les ressources sont reconfigurées de façon à pouvoir atteindre les objectifs. Si cela n'est pas possible, le démon indique dans le journal que les objectifs définis par l'utilisateur ne peuvent plus être remplis. À la suite d'une reconfiguration, le démon reprend le contrôle des objectifs des charges de travail.

poold tient à jour un historique des décisions en vue de l'examiner en cas de besoin. Cet historique sert à éviter les reconfigurations qui n'ont pas permis d'apporter de réelles améliorations dans le passé.

Une reconfiguration peut également être déclenchée de façon asynchrone en cas de modification des objectifs des charges de travail ou des ressources accessibles au système.

Gestion des pools de ressources dynamiques

Le service des pools de ressources dynamiques (DRP, Dynamic Resource Pools) est géré par l'utilitaire de gestion des services (SMF, Service Management Facility) sous l'identificateur de service svc:/system/pools/dynamic.

Les actions administratives appliquées à ce service (activation, désactivation ou demande de redémarrage, par exemple), peuvent être réalisées à l'aide de la commande svcadm. Servez-vous de la commande svcs pour connaître l'état du service. Pour plus d'informations, reportez-vous aux pages de manuel svcs(1) et svcadm(1M).

L'interface SMF est la méthode de prédilection pour contrôler le service DRP, mais pour des raisons de compatibilité ascendante, les méthodes suivantes sont également préconisées.

• Si aucune allocation dynamique des ressources n'est nécessaire, il est possible d'arrêter poold avec le signal SIGQUIT ou SIGTERM. Ces deux signaux mettent un terme progressif à poold.

• Bien que poold détecte automatiquement les changements apportés à la configuration des ressources ou des pools, vous pouvez imposer une reconfiguration en utilisant le signal SIGHUP.

Contraintes et objectifs de configuration

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.

Contraintes de configuration

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

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.

Propriété pset.min et contraintes de propriété pset.max

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 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.

Contrainte de propriété cpu.pinned

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.

Contrainte de propriété pool.importance

La propriété pool.importance décrit l'importance relative d'un pool tel qu'elle est définie par l'administrateur.

Objectifs de configuration

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.

Objectif dépendant de la charge de travail

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.

Objectif indépendant de la charge de travail

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] [valeur]

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 Établissement des objectifs de configuration propose plusieurs exemples d'utilisation.

Objectif wt-load

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.

Objectif locality

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 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 Programming Interfaces Guide.

Cet objectif peut prendre l'une des trois valeurs suivantes :

tight

Si cette valeur est définie, les configurations qui maximisent le voisinage des ressources sont favorisées.

loose

Si cette valeur est définie, les configurations qui minimisent le voisinage des ressources sont favorisées.

none

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).

Objectif utilization

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.

Exemple d'utilisation des objectifs dans une configuration

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 Évaluation des objectifs avec poold

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

La section Établissement des objectifs de configuration propose plusieurs exemples supplémentaires d'utilisation.

Propriétés poold

Il existe quatre catégories de propriétés :

• Configuration

• Contrainte

• Objectif

• Paramètre d'objectif

Fonctions poold pouvant être configurées

Voici les aspects du comportement du démon susceptibles d'être configurés.

• Intervalle de contrôle

• Niveau de consignation

• Lieu de consignation

Ces options sont spécifiées dans la configuration des pools. Vous pouvez également gérer le niveau de consignation à partir de la ligne de commande en faisant appel à poold.

Intervalle de contrôle poold

Servez-vous du nom de propriété system.poold.monitor-interval pour spécifier une valeur en millisecondes.

Informations de consignation poold

La consignation donne accès à trois catégories d'informations. Ces catégories sont identifiées dans les journaux :

• Configuration

• Contrôle

• Optimisation

Servez-vous du nom de propriété system.poold.log-level pour spécifier le paramètre de consignation. En cas d'omission de cette propriété, c'est le niveau de consignation par défaut (NOTICE) qui est appliqué. Les niveaux de paramétrage sont hiérarchiques. Le niveau de consignation DEBUG donne à poold l'instruction d'inscrire tous les messages définis dans le journal. Le niveau de consignation INFO offre un ensemble équilibré d'informations qui convient à la plupart des administrateurs.

À partir de la ligne de commande, associez la commande poold à une option -l et à un paramètre afin de définir le niveau de consignation voulu.

Voici l'ensemble des paramètres disponibles :

• ALERT

• CRIT

• ERR

• WARNING

• NOTICE

• INFO

• DEBUG

Les niveaux de paramètre sont mis directement en correspondance avec leurs équivalents syslog. Pour plus d'informations au sujet de l'utilisation de la commande syslog, reportez-vous à la section Lieu de consignation.

Pour plus d'informations au sujet de la configuration de la consignation poold, reportez-vous à la section Définition du niveau de consignation poold.

Consignation des informations de configuration

Voici les types de message susceptibles d'être générés :

ALERT

Problèmes d'accès à la configuration de libpool ou autre défaillance inopinée de l'utilitaire libpool. Provoque l'arrêt du démon et exige une attention immédiate du service administratif.

CRIT

Problèmes liés à des défaillances inopinées. Provoque l'arrêt du démon et exige une attention immédiate du service administratif.

ERR

Problèmes liés aux paramètres définis par l'utilisateur en matière de contrôle des opérations. Il peut s'agir, par exemple, d'objectifs d'utilisation conflictuels et impossible à résoudre pour un lot de ressources. Le service administratif doit intervenir pour corriger les objectifs. poold essaie de rémédier à cela en ignorant les objectifs conflictuels, mais certaines erreurs provoqueront l'arrêt du démon.

WARNING

Avertissements liés à la définition des paramètres de configuration qui, même s'ils sont techniquement corrects, risquent de ne pas convenir à l'environnement d'exécution. Le fait, par exemple, de marquer toutes les ressources CPU comme étant fixées empêche poold de transférer ces ressources d'un jeu de processeurs à un autre.

DEBUG

Messages contenant des informations détaillées nécessaires lors du débogage de la configuration. Ces informations ne sont généralement par utilisées par les administrateurs.

Consignation des informations de contrôle

Voici les types de message susceptibles d'être générés :

CRIT

Problèmes liés à des défaillances de contrôle inopinées. Provoque l'arrêt du démon et exige une attention immédiate du service administratif.

ERR

Problèmes liés à une erreur de contrôle inopinée. Le service administratif devra éventuellement intervenir pour corriger cette erreur.

NOTICE

Messages relatifs aux transitions des régions de contrôles de ressources.

INFO

Messages relatifs aux statistiques d'utilisation des ressources.

DEBUG

Messages contenant des informations détaillées nécessaires lors du débogage du contrôle. Ces informations ne sont généralement par utilisées par les administrateurs.

Consignation des informations d'optimisation

Voici les types de message susceptibles d'être générés :

WARNING

Messages concernant des décisions importantes sur l'optimisation du système. Il est possible, par exemple, que les valeurs minimum et maximum des contraintes s'appliquant aux lots de ressources soient trop proches ou que le nombre de composants rattachés ne soit pas suffisant.

Il est possible aussi que la réallocation optimale des ressources ne soit pas permise en raison de limitations inattendues. Le retrait du dernier processeur d'un jeu de processeurs contenant un consommateur de ressources restreint peut, par exemple, poser problème.

NOTICE

Messages relatifs à des configurations utilisables ou à des configurations impossibles à implémenter en raison d'historiques de décisions prioritaires.

INFO

Messages relatifs à d'autres possibilités de configurations.

DEBUG

Messages contenant des informations détaillées nécessaires lors du débogage de l'optimisation. Ces informations ne sont généralement par utilisées par les administrateurs.

Lieu de consignation

La propriété system.poold.log-location permet de désigner l'emplacement réservé à la sortie consignée de poold. Vous pouvez spécifier un emplacement de type SYSLOG pour la sortie poold (voir syslog(3C)).

En cas d'omission de cette propriété, l'emplacement par défaut de la sortie consignée de poold est /var/log/pool/poold.

Lorsque vous faites appel à poold à partir de la ligne de commande, cette propriété n'est pas utilisée. Les entrées du journal sont écrites dans stderr sur le terminal d'appel.

Gestion du journal avec logadm

Si la commande poold est active, le fichier logadm.conf offre une entrée permettant de gérer le fichier par défaut /var/log/pool/poold. Il s'agit de l'entrée suivante :

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

Reportez-vous aux pages de manuel logadm(1M) et logadm.conf(4).

Mode de fonctionnement de l'allocation dynamique des ressources

Cette section décrit les processus et les facteurs utilisés par poold pour allouer les ressources de façon dynamique.

À propos des ressources disponibles

Il s'agit de l'ensemble des ressources destinées à être utilisées dans la portée du processus poold. La portée de contrôle équivaut au plus à une seule instance Solaris.

Sur un système dont les zones sont activées, la portée d'une instance d'exécution de poold se limite à la zone globale.

Détermination des ressources disponibles

Les pools de ressources englobent toutes les ressources système réservées aux applications.

Pour une seule instance d'exécution Solaris, il est indispensable d'allouer une ressource d'un type unique, telle qu'une CPU, à une seule et même partition. Il est possible de prévoir une ou plusieurs partitions par type de ressource. Chaque partition contient un jeu unique de ressources.

Voici une configuration possible pour une machine dotée de quatre CPU et deux jeux de processeurs :

pset 0: 0 1

pset 1 : 2 3

où les chifffres 0, 1, 2 et 3 après les deux-points représentent les ID des CPU. Notez que les deux jeux de processeurs comptent pour quatre CPU.

La même machine ne peut pas avoir la configuration suivante :

pset 0: 0 1

pset 1 : 1 2 3

En effet, la CPU 1 ne peut figurer que dans un seul jeu de processeurs à la fois.

L'accès aux ressources n'est pas possible à partir d'une partition autre que la partition d'appartenance.

Pour découvrir les ressources disponibles, poold interroge la configuration de pools active afin de détecter les partitions. Toutes les ressources appartenant à l'ensemble des partitions sont additionnées pour déterminer la quantité totale de ressources disponibles pour chaque type de ressource sous contrôle.

Cette quantité correspond au chiffre de base utilisé par poold lors de ses opérations. Il existe cependant des contraintes qui limitent la souplesse dont dispose poold pour allouer les ressources. Pour plus d'informations au sujet des contraintes disponibles, reportez-vous à la section Contraintes de configuration.

Identification d'un manque de ressources

La portée du contrôle pour poold est l'ensemble des ressources disponibles dont le partitionnement et la gestion sont la principale responsabilité de poold. Cependant, d'autres mécanismes autorisés à manipuler les ressources conformément à cette portée de contrôle peuvent avoir une incidence sur une configuration. Si une partition échappe au contrôle alors que le démon poold est actif, poold essaie de rétablir le contrôle en manipulant les ressources disponibles de façon judicieuse. Si poold ne parvient pas à localiser des ressources supplémentaires à sa portée, le démon indique un manque de ressource dans le journal.

Détermination de l'utilisation des ressources

poold se consacre principalement à étudier l'utilisation des ressources qui sont dans sa portée. Ce contrôle permet de vérifier si les objectifs dépendants des charges de travail sont remplis.

Dans le cas d'un jeu de processeurs, par exemple, toutes les mesures nécessaires sont effectuées pour chacun des processeurs du jeu. L'utilisation des ressources montre le temps d'utilisation de la ressource par rapport à l'intervalle d'échantillonnage. Cette proportion est exprimée sous forme de pourcentage.

Identification des violations de contrôle

Les indications données à la section Contraintes et objectifs de configuration permettent de détecter les conditions dans lesquelles un système risque de ne pas remplir ses objectifs. Ces objectifs sont directement liés à la charge de travail.

Une partition qui ne répond pas aux objectifs fixés par l'utilisateur est considérée comme une violation de contrôle. Il existe deux types de violation de contrôle : synchrone et asynchrone.

• Une violation synchrone d'un objectif est détectée par le démon au cours du contrôle de la charge de travail.

• Une violation asynchrone d'un objectif se produit indépendamment de l'action de contrôle du démon.

Les événements suivants provoquent des violations de contrôle asynchrones :

• ajout ou retrait des ressources d'une portée de contrôle ;

• reconfiguration de la portée de contrôle ;

• redémarrrage du contrôleur de ressources poold.

On considère que les contributions des objectifs ne dépendant pas de la charge de travail sont constantes entre chaque évaluation de l'objectif. La réévaluation de ce type d'objectif est déclenchée uniquement par le biais de l'une des violations de contrôle asynchrones.

Détermination de l'action corrective appropriée

Lorsque le contrôleur de ressources se rend compte qu'un consommateur de ressources manque de ressources, la réponse initiale consiste à augmenter les ressources en considérant que cela améliore les performances.

Les autres configurations remplissant les objectifs fixés dans le cadre de la configuration prévue pour la portée de contrôle sont ensuite examinés et évalués.

Ce processus est peaufiné à mesure que parviennent les résultats sur l'analyse du transfert des ressources et sur l'évaluation de la réactivité de la partition. L'historique des décisions est consulté pour éliminer les reconfigurations n'ayant pas apporté d'améliorations significatives dans le passé. Pour mieux juger de la pertinence des données d'historique, d'autres informations sont également prises en compte, comme les noms et les quantités de processus.

Si le démon ne parvient pas à prendre de mesure corrective, la condition d'erreur est consignée dans le journal. Pour plus d'informations, reportez-vous à la section Informations de consignation poold.

Utilisation de poolstat pour contrôler l'utilitaire des pools et l'utilisation des ressources

L'utilitaire poolstat sert à contrôler l'utilisation des ressources lorsque des pools sont activés sur votre système. Cet utilitaire examine en boucle tous les pools actifs sur un système et établit des statistiques en fonction du mode de sortie sélectionné. Les statistiques poolstat vous permettent de savoir si les partitions de ressources sont exploitées de façon intensive. Il peut être intéressant de les analyser pour prendre les décisions qui s'imposent en matière de réallocation des ressources lorsque le système est soumis à une forte pression.

L'utilitaire poolstat inclut des options prévues spécialement pour examiner des pools spécifiques et obtenir des statistiques propres aux lots de ressources.

Si vous exécutez la commande poolstat dans une zone non globale et que des zones sont implémentées sur votre système, les informations relatives aux ressources associées au pool de la zone sont affichées.

Pour plus d'informations au sujet de l'utilitaire poolstat, voir la page de manuel poolstat(1M) Pour en savoir plus sur la tâche poolstat et sur son mode d'utilisation, reportez-vous à la section Création d'un état statistique pour les ressources liées au pool à l'aide de poolstat.

Sortie poolstat

Dans le format de sortie par défaut, poolstat génère une ligne d'en-tête, puis affiche une ligne pour chaque pool. Une ligne de pool commence par l'ID du pool et le nom du pool, suivis d'une colonne de données statistiques pour le jeu de processeurs rattaché au pool. Les lots de ressources s'appliquant à plusieurs pools sont répertoriés autant de fois que cela est nécessaire, à raison d'un par pool.

Les en-têtes de colonne sont les suivants :

ID

ID du pool.

pool

Nom du pool.

rid

ID du lot de ressources.

rset

Nom du lot de ressources.

type

Type du lot de ressources.

min

Taille de ressource minimum.

max

Taille de ressource maximum.

size

Taille de ressource actuelle.

used

Mesure de la quantité du lot de ressources actuellement utilisée.

Il s'agit plus précisément du pourcentage d'utilisation du lot de ressources multiplié par la taille du lot de ressources. Si un lot de ressources a été reconfiguré au cours du dernier intervalle d'échantillonnage, il est possible que cette valeur ne soit pas signalée. Une valeur non reportée est affichée sous forme d'un tiret (-).

load

Représentation absolue de la charge s'appliquant au lot de ressources.

Pour plus d'informations au sujet de cette propriété, voir la page de manuel libpool(3LIB).

Vous pouvez configurer les éléments suivants dans la sortie poolstat :

• l'ordre des colonnes ;

• les en-têtes affichés.

Réglage des intervalles d'exécution des opérations poolstat

Il est possible de personnaliser les opérations réalisées par poolstat. Vous pouvez définir l'intervalle d'échantillonnage pour le rapport et spécifier le nombre de répétitions des statistiques :

intervalle

Définissez les intervalles des opérations périodiques exécutées par poolstat. Tous les intervalles sont exprimés en secondes.

count

Indiquez combien de fois vous souhaitez répéter les statistiques. Par défaut, poolstat génère une seule fois les statistiques.

Si vous omettez de spécifier l'intervalle et le nombre de répétitions, les statistiques sont établies une seule fois. Si vous définissez l'intervalle mais pas le nombre de répétitions, les statistiques sont reproduites indéfiniment.

Commandes utilisées avec l'utilitaire des pools de ressources

Les commandes présentées dans le tableau suivant représentent l'interface d'administration principale de l'utilitaire des pools. Pour plus d'informations sur l'utilisation de ces commandes dans un système sur lequel des zones sont activées, reportez-vous à la section Pools de ressources utilisés dans les zones.

Une interface API de bibliothèque est fournie par libpool (voir la page de manuel libpool(3LIB) Cette bibliothèque peut être exploitée par les programmes pour manipuler les configurations de pools.