Chapitre 2 Utilisations normales

Ce chapitre décrit les principes de fonctionnement de Solaris Resource Manager et présente ses concepts clés. La rubrique Configuration de la charge de travail donne un exemple éclaircissant les descriptions et illustrant une hiérarchie simple. (Pour un exemple plus complexe de la hiérarchie, reportez-vous au Chapitre 10.)

Présentation générale des noeuds limites

Solaris Resource Manager est basé sur une nouvelle composante du noyau Solaris appelée noeud limite (Inode). Les noeuds limites correspondent aux UID (ID utilisateur) de UNIX et peuvent représenter des utilisateurs individuels, des groupes d'utilisateurs, des applications et des exigences spéciales. Les noeuds limites sont indexés par UID et servent à enregistrer les politiques d'attribution des ressources et les données d'utilisation cumulatives par processus au niveau de l'utilisateur, du groupe d'utilisateurs ou de l'application.

Les noeuds limites sont désignés par un UID, mais ils sont distincts des justificatifs d'identité qui ont une incidence sur les autorisations. La structure de justificatif d'identité détermine si un processus peut lire, écrire ou modifier un fichier. La structure des noeuds limites sert à déterminer les limites et l'utilisation des ressources.

Dans certains cas, l'utilisateur peut souhaiter utiliser un ensemble de limites différent. En tel cas, il se sert de la commande srmuser( 1SRM) pour préciser un lien à un noeud limite différent. Précisons que ce changement n'influe pas sur la structure des justificatifs d'identité, qui demeure associée à l'UID initial, et que le processus conserve les mêmes autorisations.

Gestion des ressources

Structure hiérarchique

Le modèle de gestion de Solaris Resource Manager organise les noeuds limites en une structure hiérarchique appelée arbre d'ordonnancement. L'arbre d'ordonnancement est organisé par UID : chaque noeud limite fait référence à l'UID de son père dans l'arbre.

Chaque sous-arbre de l'arbre d'ordonnancement est appelé groupe d'ordonnancement et l'utilisateur situé à la racine d'un groupe d'ordonnancement est le chef de groupe. (L'utilisateur root est le chef de groupe de l'arbre d'ordonnancement entier.) L'activation de l'indicateur flag.admin délègue la possibilité de gérer les stratégies de ressources dans le groupe d'ordonnancement au chef de groupe.

Les noeuds limites sont initialement créés par l'analyse du fichier de l'UID. La commande d'administration de noeuds limites (limadm(1MSRM)) permet de créer des noeuds limites supplémentaires et de les assigner à des pères après l'installation de Solaris Resource Manager. Les données de l'arbre d'ordonnancement sont enregistrées dans une base de données bidimensionnelle pouvant, au besoin, être modifiée à l'aide de la commande limadm.

Bien que les UID utilisés par les noeuds limites ne doivent pas obligatoirement correspondre à un compte système, avec une entrée dans la table des mots de passe du système, il est recommandé de créer un compte système pour l'UID de chaque noeud limite. Dans le cas des noeuds limites qui ne sont pas des «feuilles» (ayant des noeuds limites subordonnés dans la hiérarchie), il se peut que le compte associé à ce noeud soit purement administratif et que personne n'y ouvre une session. Toutefois, il est également possible qu'il s'agisse du noeud limite d'un utilisateur réel qui y ouvre des sessions et exécute les processus reliés à ce noeud qui n'est pas une feuille.

Il est à remarquer que les groupes d'ordonnancement et les chefs de groupe de Solaris Resource Manager n'ont rien à voir avec les groupes de systèmes définis dans la base de données /etc/group. Chaque noeud limite de l'arbre d'ordonnancement, y compris les chefs de groupe, correspond à un utilisateur de système réel ayant un UID unique.

Limites hiérarchiques

Si une limite hiérarchique est assignée à un chef de groupe, elle s'applique au niveau d'utilisation de cet utilisateur et au niveau d'utilisation total de tous les membres du groupe d'ordonnancement. Cela permet d'appliquer des limites à des groupes entiers ainsi qu'à des membres individuels. Les ressources sont attribuées au chef de groupe, lequel peut les attribuer aux utilisateurs ou aux groupes d'utilisateurs appartenant au même groupe.

Processus

Chaque processus correspond à un noeud limite. Le processus init est toujours relié au noeud limite root. Lorsque des processus sont créés au moyen de l'appel système fork(2), ils sont reliés au même noeud limite que leur père. Les processus peuvent être reliés de nouveau à tout noeud limite à l'aide d'un appel système de Solaris Resource Manager, à condition que les privilèges soient suffisants. Les privilèges sont définis par l'administrateur central ou par les utilisateurs avec les autorisations administratives pertinentes activées.

Contrôle des ressources

Solaris Resource Manager effectue le contrôle des ressources système suivantes : utilisation d'UC (taux d'utilisation du processeur), mémoire virtuelle, mémoire physique (Solaris 8 uniquement), nombre de processus, nombre de connexions concurrentes d'un utilisateur et/ou d'un groupe d'ordonnancement ainsi que temps de connexion du terminal.

Solaris Resource Manager fait le suivi de l'utilisation de chaque ressource par utilisateur. Pour toutes les ressources à l'exception de l'utilisation d'UC, on peut assigner aux utilisateurs des limites strictes d'utilisation des ressources. Avec une limite stricte, les tentatives de consommation de ressources échouent si l'utilisateur atteint cette limite. Les limites strictes sont appliquées directement soit par le noyau, soit par le logiciel responsable de la gestion de la ressource en question.

Si la valeur de la limite est zéro, il n'y a pas de limite. Tous les attributs relatifs aux limites du noeud limite racine doivent être laissés à zéro.

Généralement, toutes les ressources système peuvent être divisées en deux classes : les ressources fixes (ou non renouvelables) et les ressources renouvelables. Solaris Resource Manager 1.3 utilisé dans l'environnement Solaris 8 introduit cependant une troisième classe : la limite dépassable. La façon dont les limites dépassables de taille définie par le résident (RSS) sont indirectement mises en oeuvre par le démon d'application de la capacité de ressource fait que l'utilisation peut dépasser temporairement la limite définie. Pour de plus amples informations, reportez-vous au Chapitre 8.

Solaris Resource Manager gère différemment les ressources fixes et les ressources renouvelables.

Ressources fixes

Les ressources fixes, ou non renouvelables, sont disponibles en quantité limitée. Par exemple : la mémoire virtuelle, le nombre de processus, le nombre de connexions concurrentes par un utilisateur et/ou un groupe d'ordonnancement et le temps de connexion. Les ressources fixes peuvent être consommées (attribuées) et libérées (désattribuées), mais aucune autre entité ne peut utiliser la ressource avant que son propriétaire ne la libère. Solaris Resource Manager emploie un modèle d'utilisation et de limite pour contrôler la consommation des ressources fixes. L'utilisation est définie comme la ressource en cours d'utilisation et la limite est le niveau maximal d'utilisation permis par Solaris Resource Manager.

Ressources renouvelables

Les ressources renouvelables sont celles qui sont continuellement disponibles, par exemple le temps de processeur. Les ressources renouvelables peuvent uniquement être consommées, et une fois consommées, ne peuvent plus être récupérées. A tout instant, la disponibilité d'une ressource renouvelable est limitée. Si elle n'est pas consommée immédiatement, elle ne sera plus disponible à l'avenir. (On peut faire une analogie avec la lumière du soleil. Une quantité fixe de lumière nous parvient du soleil à un instant donné, mais nous continuerons d'en recevoir durant des millions d'années.) Pour cette raison, les ressources renouvelables peuvent être réassignées à d'autres utilisateurs sans réattribution explicite afin d'éviter le gaspillage.

Solaris Resource Manager emploie un modèle d'utilisation, de limite et de décroissance pour contrôler le taux de consommation d'une ressource renouvelable par un utilisateur. L'utilisation est définie comme la quantité totale de ressources utilisées ; une limite fixe le taux maximum d'utilisation par rapport aux autres utilisateurs du groupe. La décroissance désigne la période de réduction de l'utilisation historique. Le quantum de ressource suivant, par exemple un top d'horloge, sera attribué au noeud limite actif ayant la valeur d'utilisation décrue la plus faible par rapport à sa part attribuée. La valeur de l'utilisation décrue mesure l'utilisation totale dans le temps, moins une partie de l'utilisation historique déterminée selon un modèle de décroissance à demi-vie.

Gestion des ressources de l'UC

L'attribution de la ressource d'UC (unité centrale) renouvelable est contrôlée au moyen d'un ordonnanceur à partage équitable appelé ordonnanceur SHR de Solaris Resource Manager.

Méthode de l'ordonnanceur

Un certain nombre de parts d'UC est attribué à chaque noeud limite. Des ressources d'UC sont attribuées aux processus associés à chaque noeud limite proportionnellement au nombre total de parts actives disponibles (une part est active si le noeud limite est relié à des processus en cours). Seuls les noeuds limites actifs sont pris en compte pour l'attribution d'une ressource, car ils comportent des processus actifs en cours d'exécution et exigent du temps de l'UC.

A mesure qu'un processus consomme des tops d'horloge d'UC, l'attribut d'utilisation d'UC de ce noeud limite augmente. L'ordonnanceur règle périodiquement les priorités de tous les processus afin de forcer les taux relatifs d'utilisation d'UC à converger vers les taux relatifs de parts d'UC pour tous les noeuds limites actifs à leurs niveaux respectifs. Ainsi, les utilisateurs recevront à long terme au moins leur part équitable de ressources de l'UC, quelle que soit l'activité des autres utilisateurs.

L'ordonnanceur est hiérarchique, car il fait également en sorte que les groupes reçoivent leur part équitable indépendamment de l'activité des membres. L'ordonnanceur SHR de Solaris Resource Manager est un ordonnanceur à long terme ; il fait en sorte que tous les utilisateurs et toutes les applications reçoivent leur juste part au cours de la période d'ordonnancement. Cela signifie que lorsqu'un utilisateur demande d'accéder à l'UC, cet utilisateur reçoit proportionnellement plus de ressources que les gros utilisateurs, jusqu'à ce que leurs utilisations comparatives correspondent à leur part "équitable". Plus vous dépassez votre part équitable actuellement, moins vous recevrez ultérieurement.

En outre, Solaris Resource Manager emploie une période de décroissance, réglée par l'administrateur du système, qui n'assure pas le suivi de l'utilisation passée. Le modèle de décroissance est à demi-vie : au cours d'une demi-vie, 50 % de la ressource est éliminée. Grâce à cette méthode, les utilisateurs stables ne sont pas pénalisés par les utilisateurs à court terme consommant beaucoup de ressources. La période de décroissance à demi-vie fixe la réponse ou le terme de l'ordonnanceur ; la valeur par défaut est 120 secondes. Une longue demi-vie favorise une utilisation uniforme, convenant aux longs traitements par lots, tandis qu'une demi-vie courte favorise les utilisateurs interactifs. Les valeurs plus faibles augmentent la rapidité de réaction dans le système, au détriment de la précision de calcul et de la mise à jour des attributions dans l'ensemble du système. Quels que soient les réglages administratifs, l'ordonnanceur tente d'empêcher la privation de ressources et d'assurer un comportement raisonnable, même dans les situations extrêmes.

Avantages de l'ordonnanceur

Le principal avantage de l'ordonnanceur SHR de Solaris Resource Manager par rapport à l'ordonnanceur standard de Solaris est qu'il programme des utilisateurs ou des applications plutôt que des processus individuels. Chaque processus associé à un noeud limite est soumis à un ensemble de limites. Dans le cas simple d'un utilisateur exécutant un seul processus actif, cela revient à soumettre chaque processus aux limites spécifiées dans le noeud limite correspondant. Lorsque plusieurs processus sont reliés à un noeud limite, par exemple lorsque les membres d'un groupe exécutent chacun de multiples processus, tous les processus sont collectivement soumis aux limites imposées. Cela signifie que les utilisateurs ou les applications ne peuvent pas consommer les ressources de l'UC à un taux dépassant leur part attribuée, quel que soit le nombre de processus concurrents qu'ils exécutent. Le mode d'attribution du nombre de parts est simple et compréhensible, et l'effet de la modification du nombre de parts d'un utilisateur est prévisible.

L'ordonnanceur offre un autre avantage : en plus de gérer l'ordonnancement d'unités d'exécution individuelles (en termes techniques, dans Solaris, l'entité ordonnancée est appelée processus léger), il répartit les ressources de l'UC entre les utilisateurs.

Ces concepts sont représentés par l'équation suivante :

La concordance est ensuite établie entre new_SRM_priority et la priorité du système. Plus la priorité de Solaris Resource Manager est élevée, plus la priorité du système est basse et vice versa. A chaque période période de décroissance, la valeur CPU_usage est réduite de moitié et on lui ajoute l'utilisation la plus courante.

Chaque utilisateur dispose également d'un ensemble d'indicateurs, qui sont en fait des variables booléennes permettant d'activer ou de désactiver certains privilèges système, par exemple la connexion. Les indicateurs peuvent être réglés individuellement par utilisateur ou être hérités d'un noeud limite père.

Les taux d'utilisation, les limites et les indicateurs d'un utilisateur peuvent être consultés par les autres utilisateurs, mais ces valeurs ne peuvent être modifiées que par les utilisateurs détenant les privilèges administratifs correspondants.

Elimination du gaspillage d'UC

Solaris Resource Manager ne gaspille jamais la disponibilité de l'UC. Même si la part attribuée à un utilisateur est très faible, cet utilisateur recevra toutes les ressources de l'UC s'il n'y a aucun utilisateur concurrent. Par conséquent, il est possible que les utilisateurs remarquent une baisse des performances. Si un utilisateur ayant une faible part effective exécute un processus interactif en l'absence de concurrence, il semblera être exécuté rapidement. Toutefois, dès qu'un autre utilisateur ayant une part supérieure demandera d'accéder à l'UC, il aura priorité sur le premier utilisateur, lequel remarquera un ralentissement de l'exécution de sa tâche. Néanmoins, Solaris Resource Manager fait le nécessaire pour que les utilisateurs légitimes ne restent pas sans ressources et soient en mesure de réaliser leur travail. Tous les processus programmés par Solaris Resource Manager (sauf ceux ayant une valeur nice maximale) ont périodiquement accès à l'UC. De plus, un mécanisme empêche les nouveaux utilisateurs qui viennent de s'ouvrir une session d'obtenir une proportion «équitable» de l'UC du point de vue arithmétique, mais excessive au détriment des utilisateurs existants.

Mémoire virtuelle (limites par utilisateur et par processus)

La mémoire virtuelle est gérée au moyen d'un modèle à ressources fixes. La limite de mémoire virtuelle s'applique à la mémoire totale employée par tous les processus reliés au noeud limite. Il existe également une limite de mémoire virtuelle par processus qui restreint l'espace total d'adresses virtuelles du processus, y compris toutes les bibliothèques de code, de données, de pile, de mappage de fichiers et les bibliothèques partagées. Les deux limites sont hiérarchiques. La limitation de la mémoire virtuelle est utile afin d'éviter le manque de mémoire virtuelle. Par exemple, Solaris Resource Manager arrête les applications qui consomment une quantité injustifiée de mémoire virtuelle au détriment de tous les utilisateurs. En effet, de tels processus se privent eux-mêmes de ressources, ou même les autres processus appartenant au même groupe.

Mémoire physique

Si vous utilisez Solaris Resource Manager 1.3 dans l'environnement d'exploitation Solaris 8, vous pouvez réguler la consommation des ressources de mémoire physique par des collections de processus reliés à un noeud limite ou un projet. Pour de plus amples informations sur cette fonctionnalité, reportez-vous au Chapitre 8.

Nombre de processus

Le nombre de processus que les utilisateurs peuvent exécuter simultanément est contrôlé au moyen d'un modèle à ressources fixes avec limites hiérarchiques.

Limites quant au terminal et au temps de connexion

L'administrateur de système et le chef de groupe peuvent définir des privilèges de connexion de terminal et limiter le nombre de connexions et le temps de connexion ; ces limites sont appliquées hiérarchiquement par Solaris Resource Manager. Lorsqu'un utilisateur s'approche de sa limite de temps de connexion, des messages d'avertissement sont envoyés au terminal de l'utilisateur. Lorsque la limite est atteinte, l'utilisateur en est avisé, puis sa session fermée après un court délai de grâce.

Solaris Resource Manager élimine graduellement l'utilisation antérieure de temps de connexion, de sorte que seule l'utilisation la plus récente soit significative. L'administrateur du système définit un paramètre de demi-vie qui contrôle le taux de décroissance. Une longue demi-vie favorise une utilisation uniforme, tandis qu'une demi-vie courte favorise les utilisateurs interactifs.

Administration des utilisateurs

L'administrateur du système central (ou superutilisateur) peut créer et retirer des noeuds limites d'utilisateur. Cet administrateur peut modifier les limites, les utilisations et les indicateurs de n'importe quel utilisateur, notamment les siens, et également définir des privilèges administratifs pour n'importe quel noeud limite, notamment l'affectation sélective de privilèges administratifs aux utilisateurs.

Un sous-administrateur peut se voir accorder ces privilèges par l'activation de l'indicateur flag.uselimadm. Un sous-administrateur peut exécuter n'importe quelle commande limadm comme utilisateur root, et il constitue en quelque sorte un assistant du superutilisateur.

Un utilisateur ayant reçu le privilège administratif hiérarchique par l'activation de l'indicateur flag.admin est qualifié d'administrateur de groupe. Un administrateur de groupe peut modifier les noeuds limites des utilisateurs à l'intérieur du sous-arbre dont ils sont chefs de groupe, et gère l'allocation des ressources du groupe et la stratégie d'ordonnancement. Les administrateurs de groupe ne peuvent pas modifier leurs propres limites ou indicateurs, et ne peuvent pas outrepasser leur propres indicateurs ou limites dans leur groupe.

Taille

Les administrateurs du système peuvent consulter l'information sur la consommation des ressources, qui présente deux types d'informations sur la consommation des ressources : l'information sur chaque utilisateur ainsi que la charge de travail de la consommation des ressources.

Aperçu des données d'utilisation

Solaris Resource Manager conserve des informations (principalement sur l'utilisation courante et cumulative des ressources) dont les administrateurs peuvent se servir pour comptabiliser entièrement les ressources système. Aucun programme de comptabilité n'est fourni avec Solaris Resource Manager, mais il comporte des utilitaires de base permettant le développement d'un système personnalisé de comptabilisation des ressources.

Pour de plus amples informations sur les méthodes de comptabilisation, reportez-vous au Chapitre 9.

Configuration de la charge de travail

La hiérarchie des ressources bien structurée est la clé de voûte d'une gestion efficace des ressources à l'aide de Solaris Resource Manager. Solaris Resource Manager se sert de l'arbre des noeuds limites pour mettre en oeuvre la hiérarchie des ressources.

Etablissement de la correspondance entre la charge de travail et la hiérarchie des noeuds limites

Chaque noeud de l'arbre des noeuds limites établit la correspondance avec un UID de la table des mots de passe : ainsi, les charges de travail doivent être associées aux entrées de la table des mots de passe. Dans certains cas, on peut devoir créer des utilisateurs supplémentaires afin de prendre en charge les noeuds feuilles de la hiérarchie. Ces utilisateurs spéciaux n'exécutent pas des processus ou des tâches ; ils font plutôt office de point d'administration pour le noeud feuille.

Hiérarchie bidimensionnelle simple

Cette hiérarchie simple vise à permettre le contrôle des ressources de traitement de deux utilisateurs, Chuck et Mark. Ces deux utilisateurs consomment de grandes quantités de ressources de l'UC à différents points ; ils influent donc l'un sur l'autre à divers moments de la journée.

Pour régler ce problème, on constitue une hiérarchie à un niveau, puis on attribue un nombre égal de parts d'UC à chaque utilisateur.

Figure 2-1 Hiérarchie bidimensionnelle simple de Solaris Resource Manager

Cette hiérarchie simple se définit à l'aide de la commande limadm de sorte que Chuck et Mark soient des enfants du groupe de parts root :

# limadm set sgroup=root chuck
# limadm set sgroup=root mark

Pour attribuer 50 % des ressources à chaque utilisateur, accordez à ceux-ci le même nombre de parts d'UC. (Pour simplifier, 50 parts ont été attribuées à chaque utilisateur dans l'exemple, mais l'attribution d'une part à chacun d'eux donnerait le même résultat.) La commande limadm sert à attribuer les parts :

# limadm set cpu.shares=50 chuck
# limadm set cpu.shares=50 mark

Faites appel à la commande liminfo pour afficher les modifications apportées au noeud limite de Chuck :

# liminfo -c chuck
Login name:                  chuck       Uid (Real,Eff):         2001 (-,-)
Sgroup (uid):             root (0)       Gid (Real,Eff):          200 (-,-)

Shares:                         50       Myshares:                        1
Share:                          41 %     E-share:                         0 %
Usage:                           0       Accrued usage:                   0

Mem usage:                       0 B     Term usage:                     0s
Mem limit:                       0 B     Term accrue:                    0s
Proc mem limit:                  0 B     Term limit:                     0s
Mem accrue:                      0 B.s

Processes:                       0       Current logins:                  0
Process limit:                   0

Last used: Tue Oct 4 15:04:20 1998
Directory: /users/chuck
Name:       Hungry user
Shell:      /bin/csh

Flags:

Pour de plus amples informations sur les zones affichées par la commande liminfo, reportez-vous à la rubrique Serveur d'applications type. Reportez-vous également à la page liminfo (1SRM) du manuel pour de plus amples informations sur les zones liminfo.