Cette section décrit les processus et les facteurs utilisés par poold pour allouer les ressources de façon dynamique.
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.
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.
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.
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.
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.
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.