Chapitre 2 Utilisations normales

Ce chapitre décrit les principes de fonctionnement de Solaris Resource Manager et ses concepts clés. Il comporte des exemples éclaircissant les descriptions et illustrant les utilisations courantes de Solaris Resource Manager.

Aperçu des noeuds limites

Solaris Resource Manager est basé sur une nouvelle composante du noyau Solaris appelée "noeud limite". Les noeuds limites correspondent aux UID (ID utilisateur) de UNIX et peuvent représenter des utilisateurs individuels, des groupes d'utilisateurs 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'usage cumulatives par processus au niveau de l'utilisateur, du groupe d'utilisateurs ou de l'application.

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 racine est le chef de groupe de l'arbre d'ordonnancement entier. Un chef de groupe peut être autorisé à gérer les politiques de ressources du groupe. Les noeuds limites sont initialement créés par analyse du fichier de l'UID. Une commande d'administration de noeuds limites ( limadm(1MSRM)) permet de créer des noeuds limites supplémentaires après l'installation de Solaris Resource Manager et d'assigner des noeuds limites aux pères. Les données de l'arbre d'ordonnancement sont enregistrées dans une base de données bidimensionnelle pouvant, au besoin, être modifiée.

Bien que les UID utilisées 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 fortement 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 de l'arbre d'ordonnancement, y compris les chefs de groupe, correspond à un utilisateur de système réel ayant une UID unique.

Limites hiérarchiques

Si une limite hiérarchique est assignée à un chef de groupe dans un arbre de noeuds limites (groupe d'ordonnancement), elle s'applique aussi au niveau d'usage de cet utilisateur et au niveau d'usage 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 attaché au noeud limite racine. Lorsque des processus sont crées au moyen de l'appel système fork(2), ils sont attaché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 racine ou par utilisateur avec les autorisations administratives pertinentes activées.

Contrôle des ressources

Solaris Resource Manager effectue le contrôle des ressources système suivantes : usage de l'UC (taux d'utilisation du processeur), mémoire virtuelle, nombre de processus, nombre de connexions et temps de connexion du terminal.

Solaris Resource Manager fait le suivi de l'usage de chaque ressource par utilisateur. Pour toutes les ressources à l'exception de l'usage de l'UC, vous pouvez assigner aux utilisateurs des limites strictes d'usage 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.

Solaris Resource Manager élimine graduellement l'usage antérieur, de sorte que seul l'usage 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 un usage uniforme, convenant aux longs traitements par lots, tandis qu'une demi-vie courte favorise les utilisateurs interactifs.

Généralement, toutes les ressources système peuvent être divisées en deux classes : les ressources fixes (non renouvelables) et les ressources renouvelables. Solaris Resource Manager gère différemment ces deux types de ressources.

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 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'usage et de limite pour contrôler la consommation des ressources fixes. L'usage est défini comme la ressource en cours d'utilisation, et la limite est le niveau maximum d'usage 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. À 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 à 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'usage, de limite et de décroissance pour contrôler le taux de consommation d'une ressource renouvelable par un utilisateur. L'usage est défini comme la quantité totale de ressources utilisées ; une limite fixe le taux maximum d'usage par rapport aux autres utilisateurs. La décroissance désigne la période de réduction de l'usage historique. Le quantum de ressource suivant, par exemple un top d'horloge, sera attribué au noeud limite actif ayant la valeur d'usage décrue la plus faible par rapport à sa part attribuée. La valeur d'usage décrue mesure l'utilisation totale dans le temps, moins une partie de l'usage historique déterminée selon un modèle de décroissance à demi-vie.

Les ressources de l'UC sont contrôlées par l'ordonnanceur SHR de Solaris Resource Manager. Le temps de processeur est attribué dynamiquement aux utilisateurs proportionnellement au nombre de parts qu'ils détiennent (par analogie avec les parts d'une compagnie), et en proportion inverse de leur usage récent. L'ordonnanceur joue un autre rôle important : 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.

Chaque utilisateur possède également 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'usage, les limites et les indicateurs peuvent être consultés par tout utilisateur, mais ne peuvent être modifiés que par les utilisateurs détenant des privilèges administratifs.

Gestion des ressources de l'UC

L'attribution du service d'UC renouvelable est contrôlé au moyen d'un ordonnanceur à partage équitable. Un certain nombre de parts d'UC, comparables aux parts d'une compagnie, 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 en cours d'exécution et exigent du temps de processeur. À mesure qu'un processus consomme des tops d'horloge d'UC, l'attribut d'usage de l'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'usage de l'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. 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 usages comparatifs 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 lui fait "oublier" l'usage antérieur. 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. 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 l'abandon (la privation de ressources) et d'assurer un comportement raisonnable, même dans les situations extrêmes.

Le principal avantage de l'ordonnanceur 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, peu importe 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.

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

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.

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

Administration des utilisateurs

L'administrateur du système peut définir des privilèges administratifs pour tout noeud limite, y compris l'attribution sélective de privilèges administratifs aux utilisateurs. Un utilisateur détenant des privilèges administratifs hiérarchiques est appelé sous-administrateur. Un sous-administrateur peut créer, supprimer et modifier les noeuds limites des utilisateurs dans le sous-arbre dont il est le chef.

Toutefois, le sous-administrateur ne peut normalement pas modifier ses propres limites ou indicateurs, et ne peut pas non plus contourner ses propres indicateurs et limites en modifiant les indicateurs ou les taux d'usage de son groupe.

L'administrateur central (ou superutilisateur) peut modifier les limites, les taux d'usage et les indicateurs de chaque utilisateur, y compris lui-même. Les utilisateurs ordinaires peuvent aussi obtenir ce privilège si l'indicateur correspondant est activé.

Aperçu des données d'usage

Solaris Resource Manager conserve des informations (principalement sur l'usage courant et cumulatif des ressources) dont les administrateurs peuvent se servir pour comptabiliser 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 renseignements sur les procédures de comptabilité, voir Chapitre 8.

Exemples

Les exemples de cette section illustrent les fonctions de Solaris Resource Manager utilisées pour contrôler et attribuer des ressources système, et pour afficher des informations.

Exemple de regroupement de serveurs

Le premier exemple illustre les commandes suivantes :

liminfo

Affiche dans une fenêtre de terminal les attributs de mot de passe et les informations sur les limites pour un ou plusieurs utilisateurs.

limadm

Permet de modifier les attributs de limite ou de supprimer des entrées dans la base de données des limites pour une liste d'utilisateurs.

srmuser

Permet d'afficher et de régler les modes de fonctionnement et certains paramètres système de Solaris Resource Manager.

srmstat

Affiche des informations sur l'activité des noeuds limites.

Considérons le cas d'un regroupement de deux serveurs exécutant chacun une application de base de données, en une seule machine. Le simple fait d'exécuter les deux applications sur une seule machine résulte en un système utilisable ; mais sans Solaris Resource Manager, le système d'exploitation Solaris attribue les ressources aux applications sur une base égale, et ne protège pas chaque application contre les exigences concurrentielles de l'autre. Toutefois, Solaris Resource Manager comporte des mécanismes empêchant les applications de manquer de ressources. Solaris Resource Manager accomplit cela en liant chaque base de données à des noeuds limites correspondants, bd1 et bd2. Pour ce faire, trois nouveaux paramètres substituables d'utilisateur administratif doivent être créés. Dans cet exemple, nous utiliserons les bases de données bd1 et bd2. Ces paramètres sont ajoutés à la base de données des noeuds limites. Étant donné que les noeuds limites correspondent à des UID UNIX, celles-ci doivent aussi être ajoutées au fichier passwd (ou à la table des mots de passe, si le système utilise un service de nom tel que NIS ou NIS+). En supposant que les UID sont ajoutées au fichier passwd ou à la table des mots de passe, les utilisateurs des paramètres substituables bd1 et bd2 sont attribués au groupe de noeuds limites bases de données au moyen de la commande suivante :

 % limadm set sgroup=0 databases
 % limadm set sgroup=databases db1 db2

Cela suppose que le répertoire /usr/srm/bin se situe dans la route de l'utilisateur.

Figure 2-1 Regroupement des serveurs

Comme il n'existe pas d'autres groupes définis, le groupe bases de données a actuellement un accès complet à la machine. Deux noeuds limites associés aux bases de données sont en cours, et les processus exécutant les applications de base de données sont reliés aux noeuds limites appropriés au moyen de la commande srmuser dans le script de démarrage pour les instances de base de données, par exemple :

 % srmuser bd1 /usr/bin/database1/init.db1
 % srmuser bd2 /usr/bin/database2/init.db2

Lorsque l'une des base de données, bd1 ou bd2, est lancée, utilisez la commande srmuser pour vous assurer que la base de données est reliée au noeud limite approprié et correctement chargée ( srmuser n'influence pas la propriété de processus lors de cette opération). Pour exécuter la commande ci-dessus, l'utilisateur doit détenir les autorisations UNIX requises pour exécuter init.db1 et l'autorisation administrative de lier des processus au noeud limite bd1. Lorsque les utilisateurs ouvrent une session et utilisent les bases de données, les activités effectuées par les bases de données sont cumulées dans les noeuds limites bd1 et bd2.

En utilisant l'attribution par défaut d'une part par noeud limite, le taux d'usage du groupe bases de données à long terme fera en sorte que les bases de données bd1 et bd2 reçoivent une part égale des ressources de la machine. Plus particulièrement, il y a une part disponible--dans le groupe bases de données--, et bases de données la détient. Chacun des noeuds limites bd1 et bd2 reçoit également l'attribution par défaut d'une part. Dans le groupe bases de données, deux parts sont disponibles, donc bd1 et bd2 reçoivent une attribution égale des ressources de bases de données (dans ce simple exemple, il n'y a pas d'attributions concurrentielles, et bases de données a ainsi accès à la totalité du système).

S'il se trouve que l'activité de la Base de données 1 exige 60 % de la capacité de l'UC de la machine et que la Base de données 2 exige 20 % de la capacité, l'administrateur peut spécifier que le système doit fournir au moins cette proportion (en supposant que l'application l'exige) en augmentant le nombre de parts de l'UC ( cpu.shares) attribué à bd1 :

% limadm set cpu.shares=3 db1

Quatre parts sont maintenant disponibles dans le groupe bases de données ; bd1 en détient trois, et bd2 une. Ce changement est effectué dès l'exécution de la commande ci-dessus. Durant la période d'uniformisation qui suit, le noeud limite bd1 (Base de données 1) reçoit plus que sa juste part de 60 % des ressources de la machine, étant donné que Solaris Resource Manager étale l'usage dans le temps. Toutefois, selon le paramètre global de décroissance, cette période est assez courte.

Pour surveiller cette activité en tout temps, utilisez les commandes liminfo et srmstat dans des fenêtres distinctes :

% liminfo -c db1
 # limit information shows all the data and
 # settings for the lnode db1.

Voir "Serveur d'applications type".

Par contre, srmstat fournit un affichage régulièrement mis à jour :

% srmstat -ac   # srmstat shows the server activity and the
 # flag -ac sets a screen default update period 
 # of 4 seconds to display the results.

La machine exécute maintenant deux applications de base de données, dont l'une reçoit 75 % des ressources, et l'autre 25 %. N'oubliez pas que le superutilisateur (racine) est le chef de groupe au niveau le plus élevé. Les processus exécutés en tant que racine ont donc accès à la totalité du système, s'ils le demandent. De même, des noeuds limites supplémentaires devraient être créés pour l'exécution de sauvegardes, de démons et d'autres scripts afin d'empêcher les processus racine de monopoliser toute la machine, comme ils pourraient le faire dans le mode traditionnel.

Ajout d'un utilisateur d'application de calcul par lots

Cet exemple illustre la commande suivante :

srmkill

Détruit tous les processus actifs reliés à un noeud limite.

Le service des finances est propriétaire du système de base de données, mais un utilisateur (Joe) du service de génie doit exécuter un travail de calcul et voudrait utiliser la machine des finances durant les heures où le système est généralement inactif. Le service des finances considère le travail de Joe comme moins important que les bases de données, et accepte d'exécuter son travail uniquement s'il ne perturbe pas le rôle principal du système. Pour mettre cette politique en oeuvre, ajoutez un nouveau groupe ( lot) au noeud limite base de données, et ajoutez Joe au nouveau groupe lot dans la hiérarchie de noeuds limites du serveur.

 % limadm set cpu.shares=20 databases
 % limadm set cpu.shares=1 batch
 % limadm set cpu.shares=1 joe
 % limadm set sgroup=lot joe

Figure 2-2 Ajout d'une application de calcul par lots

Cette série de commandes permet de modifier l'attribution des parts afin que le groupe bases de données possède 20 parts, et le groupe lot une seule. Ainsi, les membres du groupe lot (Joe seulement) utiliseront au plus 1/21 des ressources de la machine si le groupe bases de données est actif. Le groupe bases de données reçoit 20/21, ou 95,2 %, ce qui dépasse la proportion de 60 % + 20 % = 80 % antérieurement déterminée comme étant suffisante pour exécuter les applications de base de données. Si les bases de données ne demandent pas leur attribution entière, Joe recevra plus que sa part de 4,8 %. Si les bases de données sont inactives, l'attribution de Joe pourrait atteindre 100 %. Lorsque le nombre de parts disponibles attribué aux bases de données est augmenté de 1 à 20, il n'est pas nécessaire de modifier l'attribution des parts de bd1 et bd2. Dans le groupe bases de données, quatre parts sont toujours disponibles, attribuées à raison de 3/1. Les différents niveaux de l'arbre d'ordonnancement sont complètement indépendants ; seul le rapport du nombre de parts entre les groupes homologues importe.

Même avec ces assurances, le service des finances souhaite s'assurer que Joe ne pourra pas ouvrir de session durant les heures de bureau. Cela peut être accompli en insérant certains contrôles de connexion dans le groupe lot. Comme les contrôles tiennent compte de l'heure, l'objectif peut être réalisé en exécutant un script modifiant le nombre de connexions accordées au groupe lot au début et à la fin de la journée. Par exemple, des entrées crontab pourraient être employées :

 0 6 * * * /usr/srm/bin/limadm set logins=0 batch
 0 18 * * */usr/srm/bin/limadm set logins=100 batch

À 6h00, la limite de connexions de lot passe à 0, et à 18h00, elle est augmentée de manière à permettre 100 connexions.

Une politique encore plus stricte peut être mise en oeuvre en ajoutant une autre ligne à l'entrée crontab :

01 6 * * * /usr/srm/bin/srmkill joe

Cette ligne utilise la commande srmkill pour détruire tout processus relié au noeud limite Joe à 6h01. Cela ne sera pas nécessaire si les seules ressources requises par le travail sont contrôlées par Solaris Resource Manager. Cette action pourrait toutefois être utile si le travail de Joe était susceptible d'accaparer des ressources qui nuiraient aux opérations normales, par exemple un travail pouvant bloquer une base de données ou dominant un canal d'E-S.

À présent, Joe peut ouvrir une session et exécuter son travail uniquement durant la nuit. Vu que Joe (et le groupe lot) détient beaucoup moins de parts que les autres applications, l'exécution de son application utilisera moins de 5 % des ressources de la machine. De même, la commande nice(1) peut être utilisée pour réduire la priorité des processus reliés à ce travail, afin que sa priorité d'exécution soit inférieure à celle des autres travaux ayant le même nombre de parts dans Solaris Resource Manager.

Maintenant, le service des finances a fait le nécessaire pour que ses applications de base de données aient un accès suffisant au système et ne se nuisent pas mutuellement. En outre, les besoins de traitement par lot nocturnes de Joe sont satisfaits, tout en s'assurant qu'ils ne perturberont pas les applications critiques.

Mise en place d'un processus Web frontal

Supposons qu'il a été décidé de mettre en place un processus frontal sur la Base de données 1, mais que l'accès à cette application doit être limité à 10 utilisateurs simultanés. Pour ce faire, utilisez la fonction de limites de processus.

D'abord, créez un noeud limite appelé sw1. En lançant l'application de serveur Web sous le noeud limite sw1, vous pouvez contrôler le nombre de processus auquel il a accès, et donc le nombre de sessions http actives.

Figure 2-3 Ajout d'un processus Web frontal

Étant donné que le serveur Web fait partie de l'application de la Base de données 1, vous pourriez lui attribuer une part du noeud limite bd1 et lui permettre de concurrencer la Base de données 1 quant à l'accès aux ressources. Attribuez 60 % des ressources informatiques au serveur Web, et 40 % à l'application de la Base de données 1 :

 # limadm set cpu.shares=6 sw1
 # limadm set sgroup=bd1 sw1
 # limadm set cpu.myshares=4 bd1
 # srmuser sw1 /etc/bin/Webserver1/init.webserver 

La dernière ligne démarre le serveur Web et charge l'application dans le noeud limite sw1. Remarquez que pour la Base de données 1, la variable cpu.myshares est réglée à 4. Cela définit la proportion de parts pour lesquelles bd1 va concurrencer son processus enfant, c'est-à-dire le serveur Web, à raison de 4/6.

cpu.shares indique le rapport d'attribution des ressources au niveau homologue dans une hiérarchie, tandis que cpu.myshares indique le rapport d'attribution des ressources au niveau père/enfants lorsque le père exécute des applications. Solaris Resource Manager attribue les ressources en fonction de la proportion des parts disponibles de tous les noeuds limites actifs à leur niveau correspondant, ce dernier incluant la valeur my.shares du père du groupe et de tous ses enfants.

Pour spécifier le nombre de processus pouvant être exécutés par le serveur Web, imposez une limite de processus au noeud limite sw1. L'exemple emploie la valeur 20, car une interrogation de serveur Web engendre habituellement 2 processus, ce qui limite le nombre d'interrogations actives du serveur Web à 10 :

# limadm set process.limit=20 sw1

Une autre application a maintenant été ajoutée à l'arbre d'ordonnancement en tant que noeud feuille sous un noeud limite actif. Pour distribuer les ressources de l'UC entre le père actif et l'enfant, utilisez la variable cpu.myshares de manière à attribuer une partie de la ressource disponible au père, et une partie à l'enfant. Les limites de processus servent à restreindre le nombre de sessions actives dans un noeud limite.

Ajout d'utilisateurs ayant des besoins de mémoire spéciaux

Cet exemple illustre les mécanismes de contrôle des ressources, le partage de l'UC, les limites de processus et les contrôles de connexion, ainsi que les outils d'affichage permettant l'impression de noeuds limites et la visualisation des noeuds limites actifs.

srmadm

Administrer Solaris Resource Manager.

limreport

Générer des informations sur des utilisateurs.

limdaemon

Indiquer au démon d'envoyer des messages lorsqu'une limite est atteinte.

Un autre utilisateur, Sally, veut également utiliser la machine durant la nuit afin d'exécuter son application. Vu que son application fait un usage intensif de l'UC, pour empêcher que l'application de Joe n'en souffre, imposons une limite à l'usage de la mémoire virtuelle par Sally, en termes d'usage total et par processus.

 % limadm set memory.limit=50M sally
 % limadm set memory.plimit=25M sally

Figure 2-4 Ajout d'utilisateurs

Si l'application de Sally tente de dépasser sa limite totale de mémoire virtuelle ou de processus, la commande limdaemon lui signalera, ainsi qu'à l'administrateur de système, par l'intermédiaire de la console, que sa limite a été dépassée.

Utilisez la commande limreport(1MSRM) pour générer un rapport sur les utilisateurs actuels du système et sur leur usage cumulatif. On utilise généralement la commande limreport pour savoir qui utilise la machine à un moment donné et où ces personnes se situent dans la hiérarchie des utilisateurs.

% limreport 'flag.real' - uid sgroup lname cpu.shares cpu.usage |sort +1n +0n

limreport comporte plusieurs paramètres. Dans cet exemple, la vérification porte sur "flag.real" (seuls les "vrais" noeuds limites/UID sont recherchés), puis un trait d'union (-) est employé pour indiquer d'utiliser la meilleure estimation du format de sortie, et la liste " uid sgroup lname cpu.shares cpu.usage" signifie que la commande limreport doit fournir ces cinq paramètres pour chaque noeud limite dont l'indicateur "flag.real" est fixé à TRUE. La sortie fait l'objet d'un tri primaire UNIX de la deuxième colonne et d'un tri secondaire de la première colonne afin de générer un rapport simple sur les utilisateurs du serveur.

Tout utilisateur ayant la route et les autorisations appropriés peut vérifier l'état de Solaris Resource Manager en tout temps à l'aide de la commande srmadm show. Cette commande produit un rapport formaté indiquant l'état actuel des opérations de Solaris Resource Manager, ainsi que ses principaux paramètres de configuration. Ce rapport constitue un moyen pratique de vérifier que Solaris Resource Manager est actif et que tous les paramètres de contrôle sont correctement réglés. Il indique également la valeur des paramètres globaux tels que le taux de décroissance et l'emplacement de la banque de données de Solaris Resource Manager.

Il est possible d'exécuter Solaris Resource Manager sans limites actives et sans ordonnancement de l'UC, ce qui peut être utile lors du démarrage, à des fins de dépannage et de configuration initiale de Solaris Resource Manager :

# srmadm set share=n:limits=n, -

Partage d'une machine entre plusieurs services

Un autre groupe de développement voudrait acheter une mise à niveau pour cette machine (plus de processeurs et de mémoire) en échange d'un accès au système lorsqu'il est libre. Les deux groupes bénéficieront de la transaction. Pour configurer cela, créez un nouveau groupe appelé développement au même niveau que bases de données et lot. Attribuez au groupe développement 33 % de la machine, car il a augmenté de 50 % la puissance de l'UC et la mémoire du système.

Figure 2-5 Partage d'une machine, étape 1

Le groupe Développement comporte des centaines d'utilisateurs. Pour éviter de définir la distribution de ses ressources, utilisez l'indicateur d'administration de Solaris Resource Manager afin de permettre à l'administrateur de système du groupe Développement d'attribuer ses propres ressources. Vous définissez alors les limites au niveau des opérations et du développement selon l'entente conclue avec l'autre groupe, puis chaque groupe contrôle sa propre part de la machine.

Pour ajouter le nouveau niveau à la hiérarchie, ajoutez le groupe opérations en tant que nouveau noeud limite et remplacez les groupes père de lot et bases de données par opérations :

% limadm set sgroup=operations batch databases

Pour régler l'indicateur d'administration :

% limadm set flag.admin=set operations development

Puisque, dans des circonstances normales, tous les serveurs ont des démons et des processus de sauvegarde à exécuter, ceux-ci devraient être ajoutés dans un noeud limite distinct de haut niveau.

N'employez pas le niveau racine, car il n'a pas de limites.

Figure 2-6 Partage d'une machine, étape 2

Comme nous l'avons vu dans les exemples, Solaris Resource Manager vous permet de regrouper divers types d'utilisateurs et d'applications dans la même machine. En utilisant judicieusement les contrôles de partage de l'UC, les limites de mémoire virtuelle, les limites de processus et les contrôles de connexion, vous pouvez vous assurer que les diverses applications ne recevront que les ressources dont elles ont besoin. Grâce aux limites, aucune application et aucun utilisateur ne peut perturber les applications des autres utilisateurs ou groupes d'utilisateurs. Solaris Resource Manager est compatible avec des utilitaires de production de rapports simples permettant aux utilisateurs et aux administrateurs de système de savoir exactement ce qui se passe à un instant donné et durant une certaine période. La production de rapports peut servir à visualiser la répartition de l'usage des ressources entre les applications et les groupes, à des fins de planification de la capacité et de facturation.

Serveur d'applications type

Le texte suivant serait affiché suite à un listage liminfo de bd1 à la fin de l'exemple de la section précédente. Texte tapé :

# liminfo -c db1

Résultat :

Figure 2-7 liminfo Listage

Pour de plus amples renseignements sur les champs décrits ci-après, reportez-vous à liminfo(1SRM).

Les deux premières lignes de la sortie de la commande liminfo(1SRM) concernent les aspects de l'UID du noeud limite et sa position dans l'arbre des noeuds limites.

Nom de connexion

Le nom de connexion et la GID initiale de la table des mots de passe correspondant à l'UID du noeud limite associé. Une UID système est associée à chaque noeud limite. Il est fortement recommandé de créer un compte système pour l'UID de chaque noeud limite. Dans cet exemple, une UID substituable est utilisée pour la Base de données 1 de bd1.

Il faut noter que la configuration par défaut du module PAM sous Solaris Resource Manager crée un noeud limite pour tout utilisateur qui ouvre une session sans noeud limite. Par défaut, les noeuds limites créés par un superutilisateur (racine) ou par un utilisateur dont l'indicateur uselimadm est activé sont crées avec le noeud limite de l'utilisateur comme père, ou, si ce dernier n'existe pas, avec le noeud limite racine comme père. Les noeuds limites crées par un utilisateur dont l'indicateur d'administration est activé sont crées avec cet utilisateur comme père. Le père d'un noeud limite peut être changé au moyen de la commande générale de modification des attributs des noeuds limites, limadm.

UID

L'UID du noeud limite relié au processus en cours. Normalement, cette UID est identique à l'UID réelle du processus (l'utilisateur en session), mais dans certains cas (décrits plus loin), elle peut être différente.

R,Euid et R,Egid

L'UID et la GID réelles et effectifs du processus en cours. Il s'agit des mêmes informations que celles fournies par la commande système standard id(1M). Ces champs ne sont pas strictement reliés à Solaris Resource Manager, mais sont affichés à des fins de commodité. Ces champs ne sont toutefois pas affichés si la commande liminfo(1SRM) affiche des informations sur un utilisateur autre que celui par défaut (c.-à-d. si vous avez spécifié un nom de connexion ou une UID comme argument).

Sgroup (uid) [sgroup]

Le nom et l'UID du noeud limite père dans la hiérarchie des noeuds limites. Ce champ est vide dans le cas du noeud limite racine. Plusieurs fonctions de Solaris Resource Manager dépendent de la position d'un noeud limite dans la hiérarchie de l'arbre. Il est donc utile pour un utilisateur de retracer les noeuds limites père successifs jusqu'à la racine de l'arbre.

Après la ligne en blanc, les deux lignes suivantes de l'affichage de liminfo(1SRM) comportent des champs relatifs à l'ordonnancement de l'UC.

Shares [cpu.shares]

Il s'agit du nombre de parts d'UC attribué à cet utilisateur. Ce nombre ne peut être comparé directement qu'à celui des autres utilisateurs ayant le même noeud limite, ainsi qu'à la valeur "Myshares" du noeud limite père lui-même. Généralement, l'administrateur répartit également les parts entre tous les utilisateurs appartenant à un groupe d'ordonnancement particulier (afin de donner les mêmes privilèges à tous les utilisateurs). Cette valeur étant normalement supérieure à 1, l'administrateur dispose d'une certaine latitude pour diminuer, au besoin, les parts de certains utilisateurs.

Myshares [cpu.myshares]

Cette valeur n'est utilisée que si l'utilisateur possède des noeuds limites enfants (c.-à-d. s'il existe d'autres noeuds limites ayant la valeur sgroup de cet utilisateur) qui sont actifs (reliés à des processus). Le cas échéant, cette valeur représente la part relative de l'UC attribuée aux processus associés à ce noeud limite, par opposition à ceux qui sont associés à ses noeuds limites enfants.

Share

Pourcentage calculé des ressources d'UC attribué à l'utilisateur actuel. À mesure que d'autres utilisateurs ouvrent et ferment une session (ou que des noeuds limites deviennent actifs ou inactifs), cette valeur change, car seuls les utilisateurs actifs sont inclus dans le calcul. L'usage récent de l'utilisateur actuel n'est pas compris dans ce calcul.

E-Share

Il s'agit de la part effective de cet utilisateur (c.-à-d. le pourcentage des ressources de l'UC qui serait attribué à cet utilisateur à court terme s'il en avait besoin et si tous les autres utilisateurs actifs exigeaient également leur part). En d'autres termes, il s'agit de la disposition de Solaris Resource Manager à allouer des ressources d'UC à ce noeud limite. Cette valeur varie dans le temps à mesure que l'utilisateur consomme (ou ne consomme pas) des ressources de l'UC. Les noeuds limites actifs mais non actuellement en usage (dont les processus connexes sont au repos) ont une part effective élevée. Réciproquement, la part effective des utilisateurs associés à des processus utilisant actuellement l'UC peut être très faible.

Usage [cpu.usage]

Il s'agit de l'usage cumulatif des ressources système servant à déterminer la priorité d'ordonnancement. Généralement, cette valeur indique l'usage récent de l'UC, bien que d'autres paramètres puissent être pris en compte. La commande srmadm(1MSRM) vous permet de connaître les paramètres employés. Chaque accroissement de cette valeur diminue exponentiellement dans le temps, de sorte que Solaris Resource Manager "oublie" l'usage des ressources après un certain temps. Le taux de cette décroissance est représenté par sa demi-vie, laquelle peut être consultée au moyen de la commande srmadm(1MSRM).

Accrued usage [cpu.accrue]

Cette mesure cumulative est identique à l'"usage", mais n'est jamais réduite. Cette valeur n'est pas directement employée par Solaris Resource Manager, mais peut être utile au personnel de gestion à des fins de comptabilité. Contrairement à l'usage, cette valeur indique l'usage cumulatif de tous les noeuds limites appartenant au groupe, ainsi que celle du noeud limite actuel.

Après la deuxième ligne vierge, les quatre lignes suivantes de l'affichage de la commande liminfo(1SRM) présentent quatre champs relatifs à la mémoire virtuelle :

Mem usage [memory.usage][memory.myusage]

Il s'agit de l'usage de mémoire combiné de tous les processus reliés à ce noeud limite.

Si deux valeurs séparées par une barre oblique (/) sont affichées, ce noeud limite est un chef de groupe, et la première valeur indique l'usage de tout le groupe d'ordonnancement, tandis que la deuxième valeur indique seulement celle de l'utilisateur actuel.

Mem limit [memory.limit]

Usage maximal de mémoire autorisé pour tous les processus reliés à ce noeud limite et ses membres (s'il y en a). Il s'agit de la somme maximale permise d'usage de mémoire par tous les processus appartenant au groupe et reliés au chef de groupe. Il faut noter que la valeur "0" signifie qu'il n'y a pas de limite.

Proc mem limit [memory.plimit]

Cette valeur indique l'usage maximal de mémoire autorisée pour tout processus individuel relié à ce noeud limite et à ses membres.

Mem accrue [memory.accrue]

Cette valeur cumulative est exprimée en octets/seconde et indique l'usage global des ressources de mémoire par unité de temps.

Après la troisième ligne vierge, les quatre lignes suivantes de l'affichage de la commande liminfo(1SRM) présentent des champs relatifs à l'utilisateur et aux processus.

Processes [process.usage][process.myusage]

Il s'agit du nombre de processus reliés à ce noeud limite. Il faut noter que cette valeur ne tient pas compte du nombre d'unités d'exécution comprises dans un processus.

Si deux valeurs séparées par une barre oblique (/) sont affichées, ce noeud limite est un chef de groupe, et la première valeur indique l'usage de tout le groupe d'ordonnancement, tandis que la deuxième valeur indique seulement celle de l'utilisateur actuel.

Process limit [process.limit]

Nombre total maximum autorisé de processus reliés à ce noeud limite et à ses membres.

Current logins [logins]

Nombre actuel de sessions simultanées de Solaris Resource Manager pour cet utilisateur. Lorsqu'un utilisateur ouvre une session à l'aide d'un des mécanismes standard (y compris login(1), rlogin(1), etc., ou toute méthode utilisant un module PAM pour l'authentification et créant une entrée utmp(4)), ce compteur est incrémenté. À la fin de la session, le compte est décrémenté.

Si l'indicateur flag.onelogin d'un utilisateur est activé, cet utilisateur ne peut ouvrir qu'une seule session de Solaris Resource Manager.

Last used [lastused]

Ce champ indique la dernière fois où le noeud limite a été actif. Il s'agit normalement de la dernière fermeture de session effectuée par l'utilisateur.

Directory

Répertoire d'accueil de l'utilisateur (les articles relatifs à la table des mots de passe plutôt qu'à Solaris Resource Manager sont indiqués à des fins de commodité).

Name

Informations relatives à bd1 (servant au repérage). Il s'agit généralement du nom de l'utilisateur (les articles relatifs à la table des mots de passe plutôt qu'à Solaris Resource Manager sont indiqués à des fins de commodité).

Shell

Shell de connexion initial de l'utilisateur (les articles relatifs à la table des mots de passe plutôt qu'à Solaris Resource Manager sont indiqués à des fins de commodité).

Flags

Les indicateurs activés ou ayant la valeur d'un groupe dans le noeud limite sont affichés ici. Chaque indicateur affiché est suivi de caractères indiquant la valeur et la manière dont l'indicateur a été activé (par exemple, s'il a été activé explicitement depuis ce noeud limite [+] ou s'il a été hérité [^]).