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.

Regroupement des serveurs

Le premier exemple illustre les commandes suivantes :

liminfo

Affiche, dans une fenêtre de terminal, les attributs d'utilisateur et l'information sur les limites d'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.

srmadm

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, sur une seule machine. Le simple fait d'exécuter les deux applications sur la machine résulte en un système utilisable ; sans Solaris Resource Manager, le système Solaris attribue les ressources de façon égale et il ne protège pas une application des exigences concurrentielles de l'autre application. Toutefois, Solaris Resource Manager comporte des mécanismes empêchant les applications de manquer de ressources. Avec Solaris Resource Manager, il suffit de lancer chaque base de données à laquelle correspondent les noeuds limites faisant référence aux bases de données, db1 et db2. Pour ce faire, il faut créer trois nouveaux utilisateurs de paramètres fictifs substituables, par exemple bases_de_données, bd1 et bd2. Ces paramètres sont ajoutés à la base de données des limites. Etant donné que les noeuds limites correspondent à des UID UNIX, ces derniers doivent aussi être ajoutés 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és au fichier passwd ou à la table des mots de passe, les utilisateurs des paramètres fictifs bd1 et bd2 sont assignés au groupe de noeuds limites bases_de_données à l'aide des commandes suivantes :

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

Cela suppose que le répertoire /usr/srm/bin se situe dans le chemin d'accès de l'utilisateur.

Figure 10-1 Regroupement des serveurs

Comme il n'y a pas d'autre groupe défini, 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 d'exécution et les processus qui exécutent actuellement les applications de base de données sont reliés aux noeuds limites appropriés à l'aide de la commande srmuser dans le script de démarrage pour les instances de base de données, par exemple :

# srmuser db1 /usr/bin/database1/init.db1
# srmuser db2 /usr/bin/database2/init.db2

Lorsque la 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 qu'elle est correctement chargée (srmuser n'influence pas la propriété du processus lors de cette opération). Pour exécuter la commande ci-dessus, l'utilisateur doit posséder les autorisations UNIX requises pour exécuter init.db1 ainsi que l'autorisation administrative nécessaire pour 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'utilisation 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 de 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 bénéficie également de l'allocation par défaut d'une part. Dans le groupe bases_de_données, deux parts sont disponibles, donc bd1 et bd2 reçoivent une allocation égale des ressources de bases_de_données (dans cet exemple exemple, il n'y a pas d'allocations concurrentielles et bases_de_données a ainsi accès à la totalité du système).

Si l'activité de la base de données 1 venait à exiger 60 % de la capacité de l'UC de la machine et que la base de données 2 venait à exiger 20 % de la capacité, l'administrateur pourrait spécifier au système de fournir au moins cette proportion (en supposant que l'application l'exige) en augmentant le nombre de parts de l'UC (cpu.shares attribué à db1 :

# 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'utilisation dans le temps. Toutefois, selon le paramètre global de décroissance, cette période est assez courte.

Pour surveiller cette activité à tout moment, utilisez les commandes liminfo (reportez-vous à la rubrique Serveur d'applications type) et srmstat dans des fenêtres distinctes. Veuillez noter que srmstat présente un affichage qui est régulièrement mis à jour. Pour de plus amples informations sur srmstat, reportez-vous à la page srmstat(1SRM).

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 (root) est le chef de groupe au niveau le plus élevé. Les processus exécutés en tant que root 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 root de monopoliser l'ensemble de la machine, comme ils pourraient le faire s'ils étaient exécutés en mode traditionnel.

Ajout d'un utilisateur d'applications 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 par lot 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) à la base de données de noeuds limites, 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=batch joe

Figure 10-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 complètement 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 tout de même s'assurer que Joe ne pourra pas ouvrir de session durant les heures de bureau. Cela est possible en ajoutant certains contrôles de connexion dans le groupe lot. Comme les contrôles tiennent compte de l'heure, on peut exécuter un script qui ne permet au groupe lot de réaliser une connexion qu'à des moments particuliers. Par exemple, des entrées crontab pourraient être employées :

0 6 * * * /usr/srm/bin/limadm set flag.nologin=set batch
0 18 * * * /usr/srm/bin/limadm set flag.nologin=clear batch

A 6 h 00, le groupe lot n'est pas autorisé à se connecter, mais à 18 h 00 cette interdiction est levée.

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( 1MSRM) pour détruire tout processus relié au noeud limite Joe à 6 h 01. 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.

A 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 indispensables du service.

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.

Commencez par créer 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 auxquels il a accès, et donc le nombre de sessions http actives.

Figure 10-3 Ajout d'un processus Web frontal

Etant donné que le serveur Web fait partie de l'application de 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 base de données 1 :

# limadm set cpu.shares=6 ws1
# limadm set sgroup=db1 ws1
# limadm set cpu.myshares=4 db1
# srmuser ws1 /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 définie sur 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 ws1

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 des ressources disponibles 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

Administre Solaris Resource Manager

limreport

Génère des informations sur des utilisateurs

limdaemon

Indique 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 une utilisation intensive de l'UC, pour empêcher que l'application de Joe n'en souffre, vous devez imposer une limite à l'utilisation de la mémoire virtuelle par Sally, en termes d'utilisation totale et par processus.

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

Figure 10-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 système, par l'intermédiaire de la console, que sa limite a été dépassée.

Utilisez la commande limreport pour générer un rapport sur les utilisateurs actuels du système et sur leur utilisation cumulative. 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 que doit être utilisée 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 défini sur 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 le chemin et les autorisations appropriés peut vérifier le statut 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 ainsi que tous les paramètres de contrôle sont actifs. 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 cela, vous devez créer 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 10-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, puis chacun 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 root, car il n'a pas de limites.

Figure 10-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 prend en charge 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'utilisation des ressources entre les applications et les groupes, à des fins de planification de la capacité et de facturation.