Chapitre 9 Utilisation évoluée

Ce chapitre décrit en détail les méthodes d'établissement des priorités et de gestion d'applications différentes se retrouvant dans un système. On présente un exemple de ces capacités et d'autres concepts cruciaux associés au logiciel Solaris Resource Manager. La dernière partie du chapitre porte sur la configuration de Solaris Resource Manager dans un environnement Sun Cluster 2.2.

Traitements par lot

La plupart des applications commerciales exigent un traitement par lot. Le traitement par lot est en général effectué la nuit, à un moment où la charge de travail est inférieure à celle qui prévaut durant le jour. On procède ainsi pour deux raisons : pour regrouper les transactions de la journée à l'aide de rapports et pour éviter que les traitements par lot n'influent sur les travaux exécutés en ligne.

Pour un exemple de hiérarchie servant à contrôler l'environnement d'exécution de travaux par lot, consultez la section "Exemples". Cette section aborde également les commandes de Solaris Resource Manager qui sont utilisées pour ce processus.

Ressources utilisées pour les traitements par lot

Les traitements par lot se situent entre un système de traitement des transactions en ligne (OLTP) et un système d'aide à la décision. De même, leur incidence sur le système se situe entre ces deux notions. Un traitement par lot peut comporter de nombreuses transactions répétitives, comprenant des calculs complexes, portant sur une base de données. À titre d'exemple simple, mentionnons le calcul des ventes totales de la journée. En tel cas, le processus par lot vérifie toutes les transactions de vente de la journée reportées dans la base de données, puis il extrait le montant des ventes et il calcule la somme cumulative.

En général, le traitement par lot est très exigeant pour le processeur et les ressources d'E/S, car ce traitement et la base de données font grand usage de l'UC. En outre, un nombre élevé d'opérations d'E/S sont générées, à partir de la base de données d'arrière-plan, pour chaque transaction récupérée.

Pour contrôler le traitement par lot, on restreint le taux de consommation de l'UC et des E/S. Solaris Resource Manager permet un contrôle précis des ressources de l'UC, mais on doit toutefois gérer les ressources d'E/S en affectant différents périphériques d'E/S à chaque traitement.

On se sert en général de deux méthodes pour déterminer l'incidence sur les ressources du traitement par lot :

• On effectue une copie de la base de données sur un système distinct puis on exécute le traitement par lot et on établit la charge de travail imposée à ce système. (Précisons toutefois que dans la plupart des cas, le traitement par lot met à jour des parties de la base de données en ligne et ne peut donc pas être séparé de celle-ci.)

• On utilise le contrôle des ressources de l'UC.

Étant donné que le nombre d'opérations d'E/S générées par un traitement par lot est proportionnel à la part de l'UC qui est consommée, les limites imposées aux cycles de l'UC peuvent servir à contrôler indirectement le taux d'usage des E/S par le traitement par lot. Il est toutefois à noter qu'on doit prendre garde afin que les travaux qui font très peu appel à l'UC ne génèrent pas un nombre excessif d'opérations d'E/S.

Problèmes associés au traitement par lot

Par définition, un traitement par lot est un travail qui s'exécute sans contraintes et qui vise à se terminer dans les plus brefs délais possibles. Ainsi, ce type de travail est le plus grand consommateur de ressources, car il s'approprie toutes les ressources dont il a besoin jusqu'à ce qu'il soit interrompu par un goulot d'étranglement dans le système (il s'agit habituellement du plus petit point de cheminement des données).

Le traitement par lot pose deux problèmes aux gestionnaires de système. En effet, il peut influer sur les autres travaux par lot qui s'exécutent en même temps et il ne peut jamais être lancé en même temps que la partie en ligne des travaux durant les heures de bureau.

Même si l'exécution des travaux par lot est prévue en dehors des heures normales, par exemple entre minuit et six heures du matin, si une anomalie survient dans le système ou si le nombre de ventes a été très élevé durant la journée, le traitement par lot risque de se prolonger durant les heures de bureau. L'exécution d'un traitement par lot le matin suivant n'est pas aussi perturbante qu'une panne, mais elle peut causer une attente de plusieurs minutes pour chacune des transaction des clients en ligne, ce qui entraînera en bout de ligne une réduction du nombre de transactions traitées.

Le recours à l'attribution des ressources permet de restreindre la quantité de ressources disponibles pour les traitements par lot et ainsi, d'une certaine façon, de les contrôler.

Regroupement

Solaris Resource Manager permet l'attribution des ressources au niveau du système, parfois selon les décisions quant à la répartition de l'usage entre les services. "Exemples" indiquent comment se servir de la hiérarchie de Solaris Resource Manager à cette fin.

Bases de données

Solaris Resource Manager permet de gérer les ressources de base de données dans certains cas, selon le type de base de données et la façon dont elle est utilisée.

Topologies de base de données

Les bases de données peuvent s'exécuter selon deux modes : 2n ou serveur à plusieurs unités d'exécution (MTS). En mode 2n, chaque utilisateur de la base de données dispose d'un processus distinct. En mode à plusieurs unités d'exécution, un seul processus est disponible pour de nombreux utilisateurs. Il est impossible d'utiliser Solaris Resource Manager pour gérer une base de données exécutée comme processus unique à unités d'exécution multiples, telle que Oracle MTS.

On ne peut contrôler une base de données qui est en mode MTS, à l'aide de Solaris Resource Manager, qu'au niveau de base de données, car tous les utilisateurs consomment l'UC en vertu de la même UID, dans ce cas "oracle". Solaris Resource Manager permet de regrouper les bases de données, mais il n'offre pas un contrôle précis des utilisateurs de la base de données.

Certaines bases de données, comme Oracle 8i, offrent certaines fonctions de contrôle des ressources, notamment la possibilité d'imposer des restrictions quant à l'attribution de l'UC aux interrogations ou aux utilisateurs. Dans ce cas, les politiques de gestion des ressources et l'administration sont séparées de Solaris Resource Manager et doivent être assurées à l'aide d'un ensemble d'outils différent.

Les ressources d'une base de données tournant en mode 2n sont bien plus faciles à contrôler. En effet, plutôt que d'exécuter toutes les opérations de base de données sous une seule identité, les utilisateurs se servent chacun d'une UID différente.

Le mode 2n est en général compatible avec Solaris Resource Manager, car il se sert d'un processus distinct pour chaque utilisateur ; de plus, un noeud limite unique dans la hiérarchie est attribué à chaque utilisateur.

Oracle en mode 2n avec Solaris Resource Manager

Oracle présente un bon exemple de gestion des ressources d'une base de données 2n. Oracle en mode 2n lance un processus distinct, soit le "processus Oracle en double," pour chaque utilisateur qui se relie à la base de données. Ce processus en double se relie à la mémoire partagée centrale et exécute les opérations d'E/S directement avec les fichiers de la base de données. Même si les processus en double Oracle sont des programmes setuid Oracle, ils ne correspondent pas à un noeud limite Solaris Resource Manager différent. En effet, le noeud limite est précisé au moment de l'établissement de la connexion par l'appel système setuid() et il n'est pas transféré au lancement du programme setuid(), sauf si le programme cible appelle setuid().

Le schéma ci-après présente l'utilisation de Solaris Resource Manager par Oracle en mode 2n.

Oracle en mode 2n client-serveur

En mode client-serveur, un processus supplémentaire, le récepteur d'événements réseau Oracle, prend part à l'établissement de la connexion et il peut provoquer la perte de l'information contextuelle de l'utilisateur. Le récepteur d'événements réseau accepte une connexion de l'ordinateur client et il lance le processus en double Oracle pour cet utilisateur.

Des modifications peuvent s'avérer nécessaires pour que le récepteur d'événements Oracle fasse correspondre le processus en double au bon noeud limite.

Mémoire virtuelle et bases de données

Solaris Resource Manager permet en outre de limiter la quantité de mémoire virtuelle utilisée par les utilisateurs et les travaux. Il ne s'agit pas d'une gestion de la mémoire physique, mais plutôt d'une restriction imposée quant à l'ampleur de la zone de swap globale employée par chaque utilisateur.

Lorsqu'un utilisateur ou un travail atteint la limite de mémoire virtuelle définie pour leur noeud limite, le système envoie une erreur d'attribution de mémoire à l'application. Ainsi, les appels à malloc() échouent. Ce code d'erreur indique à l'application que sa zone de swap est épuisée.

Peu d'applications réagissent correctement aux erreurs d'attribution de mémoire. Ainsi, on doit faire en sorte qu'un serveur de base de données n'atteigne jamais sa limite de mémoire virtuelle. Si cette limite est atteinte, le moteur de la base de données risque de tomber en panne, ce qui pourrait entraîner une altération de la base de données.

On doit définir des limites de mémoire virtuelle élevées afin qu'elles ne soient pas atteintes dans des circonstances normales. De plus, la limite de mémoire virtuelle peut servir à imposer un plafond pour le serveur de base de données. Ainsi, une base de données en panne qui ne dispose pas d'une mémoire suffisante n'aura pas des répercussions négatives sur les autres bases de données et sur les travaux du système.

Gestion du NFS

NFS, l'environnement informatique réparti de Sun, s'exécute sous la forme d'unités d'exécution de noyau et utilise la classe d'ordonnancement de noyau SYS. Étant donné que l'attribution de l'ordonnancement pour le NFS n'est pas gérée par la classe SHR de Solaris Resource Manager, aucun contrôle de l'usage des ressources d'UC par le NFS n'est possible. La capacité de Solaris Resource Manager à attribuer des ressources de processeur peut être réduite sur les systèmes offrant un service NFS étendu.

On peut toutefois contrôler le NFS à l'aide de la gestion des ports réseau. Par exemple, on peut faire appel à Sun Bandwidth Allocator pour contrôler le nombre de paquets NFS qui se trouvent sur le serveur. On peut également gérer le NFS, dans certains cas, en utilisant les groupes de processeurs pour limiter le nombre d'UC qui sont disponibles dans la classe système.

Gestion des serveurs Web

Solaris Resource Manager permet de gérer les ressources de serveurs Web par le contrôle de la quantité d'UC et de mémoire virtuelle. On se sert de trois topologies de base sur les systèmes qui hébergent des serveurs Web.

Gestion des ressources d'un serveur Web regroupé

On peut gérer un serveur Web en contrôlant la quantité de ressources qu'il peut utiliser. Cet aspect est fort utile dans un environnement où un serveur Web est regroupé avec d'autres travaux. Il s'agit du type de gestion des ressources le plus élémentaire. Il permet d'éviter que d'autres travaux nuisent aux performances du serveur Web et vice versa. Par exemple, si un script CGI du serveur Web s'emballe et manque de mémoire, le système n'aura pas de problème de zone de swap : seul le serveur Web sera touché.

Dans cet exemple, on attribue 20 parts à un serveur Web. Ainsi, celui-ci disposera au moins de 20 % des ressources du processeur, si la base de données impose des lourdes exigences au processeur.

Voir "Mise en place d'un processus Web frontal " pour un autre exemple de serveur Web.

Gestion plus précise des ressources d'un serveur Web individuek

Souvent, on doit faire appel à la gestion des ressources pour contrôler le comportement d'un serveur Web individuel. Par exemple, un serveur Web individuel peut être partagé entre plusieurs utilisateurs, chacun avec ses propres programmes cgi-bin.

Ainsi, une erreur dans un seul programme cgi-bin peut ralentir tout le serveur Web ou, dans le cas d'un manque de mémoire, le serveur Web peut même tomber en panne. Pour prévenir de telles situations, on peut définir des limites par processus.

Gestion des ressources de plusieurs serveurs Web virtuels

On se sert souvent d'un seul ordinateur pour héberger plusieurs serveurs Web virtuels de manière regroupée. En tel cas, plusieurs instances du processus httpd du serveur Web sont présentes et on peut tirer bien davantage profit du contrôle des ressources par l'entremise de Solaris Resource Manager.

On peut lancer chaque serveur Web à titre d'UID UNIX différente en définissant un paramètre dans le fichier de configuration du serveur Web. Ainsi, on fait correspondre chaque serveur Web à un noeud limite différent dans la hiérarchie de Solaris Resource Manager.

Par exemple, le Sun WebServer^TM comporte les paramètres suivants dans le fichier de configuration /etc/http/httpd.conf :

# Server parameters
 server  {
   server_root                   "/var/http/"
   server_user                   "webserver1"
   mime_file                     "/etc/http/mime.types"
   mime_default_type             text/nlain
   acl_enable                    "yes"
   acl_file                      "/etc/http/access.acl"
   acl_delegate_depth            3
   cache_enable                  "yes"
   cache_small_file_cache_size   8                       # megabytes
   cache_large_file_cache_size   256                     # megabytes
   cache_max_file_size           1                       # megabytes
   cache_verification_time       10                      # seconds
   comment                       "Sun WebServer Default Configuration"

   # The following are the server wide aliases

   map   /cgi-bin/               /var/http/cgi-bin/              cgi
   map   /sws-icons/             /var/http/demo/sws-icons/
   map   /admin/                 /usr/http/admin/

 # To enable viewing of server stats via command line,
 # uncomment the following line
   map   /sws-stats              dummy                           stats
 }

En configurant chaque serveur Web en vue d'une exécution selon une UID UNIX distincte, il est possible de définir des limites différentes pour chaque serveur Web. Cet aspect s'avère particulièrement utile si on souhaite contrôler et comptabiliser la consommation des ressources sur un ordinateur qui héberge plusieurs serveurs Web.

On peut ainsi se servir de plusieurs ou de tous les contrôles et limites des ressources de Solaris Resource Manager :

Shares [cpu.shares]

On peut se servir de cpu.shares pour attribuer proportionnellement les ressources à différents serveurs Web.

Mem limit [memory.limit]

On peut utiliser memory.limit pour limiter la quantité de mémoire virtuelle dont le serveur Web peut se servir. On évite ainsi qu'un serveur Web provoque la panne d'un autre serveur en raison d'une erreur d'attribution de mémoire.

Proc mem limit [memory.plimit]

La limite de mémoire par processus sert à limiter la quantité de mémoire virtuelle qu'un processus cgi-bin peut utiliser. Ainsi, un processus cgi-bin ne pourra jamais faire tomber en panne son serveur Web respectif.

Process limit [process.limit]

En précisant le nombre total maximal de processus qui peuvent se relier à un serveur Web, on peut restreindre le nombre de processus cgi-bin qui s'exécutent simultanément.

Rôle et effet des groupes de processeurs

Même lorsque Solaris Resource Manager tourne, les groupes de processeurs peuvent jouer un rôle important dans l'attribution des ressources. En effet, dans certains cas, un système peut imposer des limites strictes en matière de ressources. Par exemple, une entreprise peut se doter d'un système à 24 processeurs, qui doit prendre en charge deux unités fonctionnelles.- Chacune de ces unités fonctionnelles assume les coûts d'une partie de l'ordinateur, 40 et 60 % par exemple. Puis, l'administrateur peut souhaiter faire en sorte que le service qui paye 40 % de l'ordinateur ne reçoive jamais plus que cette part.

Avec les groupes de processeurs, on peut subdiviser les charges de travail (40 et 60 %) en attribuant 10 processeurs à l'unité disposant de la part de 40 % et 14 processeurs à celle détenant 60 %.

Lorsqu'on utilise des groupes de processeurs avec Solaris Resource Manager, on doit comprendre l'interaction entre ces deux éléments. Dans certains cas, l'effet produit peut être différent de ce qu'on escomptait.

Exemple simple

La figure ci-après présente un ensemble simple comprenant Solaris Resource Manager et des groupes de processeurs. Dans cet exemple, les parts d'UC des groupes de processeurs et de Solaris Resource Manager sont mixtes.

Ainsi, l'utilisateur 1 dispose de 25 parts de Solaris Resource Manager et il est limité au groupe de processeurs A (1 UC). L'utilisateur 2 dispose de 75 parts de Solaris Resource Manager et il est limité au groupe de processeurs B (1 UC).

Dans cet exemple, l'utilisateur 2 consomme tout son groupe de processeurs (soit 50 % du système). Puisque l'utilisateur 2 n'emploie que 50 % des ressources (plutôt que les 75 % qui lui sont attribués), l'utilisateur 1 peut utiliser les 50 % qui restent. En résumé, chaque utilisateur est autorisé à employer 50 % du système.

Exemple plus complexe

L'exemple ci-après présente une situation plus complexe, dans laquelle les parts d'UC des groupes de processeurs et de Solaris Resource Manager sont mixtes.

Les utilisateurs 1 et 3 disposent de 10 parts de Solaris Resource Manager chacun et ils sont limités au groupe de processeurs A (1 UC). L'utilisateur 2 dispose de 80 parts de Solaris Resource Manager et il est limité au groupe de processeurs B (1 UC).

Dans cet exemple, l'utilisateur 2 consomme tout son groupe de processeurs (soit 50 % du système). Puisque l'utilisateur 2 n'emploie que 50 % des ressources (plutôt que les 80 % qui lui sont attribués), les utilisateurs 1 et 3 peuvent utiliser les 50 % qui restent. Ainsi, les utilisateurs 1 et 3 disposent de 25 % du système, même si seulement 10 parts sont attribuées à chacun d'eux.

Situation à éviter

On doit éviter le scénario ci-après.

Dans cette situation, un utilisateur dispose de processus dans les deux groupes de processeurs. L'utilisateur 1 détient 20 parts de Solaris Resource Manager et emploie des processus dans chaque groupe de processeurs. L'utilisateur 2 dispose de 80 parts de Solaris Resource Manager et il est limité au groupe de processeurs B (1 UC).

Dans cet exemple, le premier processus de l'utilisateur 1 consomme tout son groupe de processeurs (soit 50 % du système). Puisque l'utilisateur 2 détient 80 parts, le processus de l'utilisateur 2 consomme tout son groupe de processeurs (soit 50 %). Ainsi, le second processus de l'utilisateur 1 ne reçoit aucune part de l'UC.

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, en 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 bd1 et bd2. Pour ce faire, il faut créer trois nouveaux utilisateurs de paramètres substituables administratifs, par exemple 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 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 de l'utilisateur.

Figure 9-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, 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 db1 /usr/bin/database1/init.db1
# srmuser db2 /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.bd1 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 (voir "Serveur d'applications type") et srmstat dans des fenêtres distinctes. Précisons que srmstat présente un affichage régulièrement mis à jour. Pour de plus amples informations sur srmstat, voir 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 ( 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 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) 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=batch joe

Figure 9-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 (Jean 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, Jean recevra plus que sa part de 4,8 %. Si les bases de données sont inactives, l'attribution de Jean 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 peut être accompli en insérant 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

À 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 jean

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 Jean é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, Jean peut ouvrir une session et exécuter son travail uniquement durant la nuit. Vu que Jean (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.

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

Figure 9-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 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 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 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 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

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, Julie, 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 Julie, en termes d'usage total et par processus.

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

Figure 9-4 Ajout d'utilisateurs

Si l'application de Julie 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 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

Remarque : 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 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 le chemin 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 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 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 9-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 racine, car il n'a pas de limites.

Figure 9-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'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 bd1

Résultat :

Figure 9-7 liminfo Listage

Les parties qui suivent décrivent la sortie de liminfo présentée à la figure 9-7. Pour de plus amples informations sur les champs décrits ci-après, reportez-vous à liminfo(1SRM) et srm(5SRM).

• Les deux premières lignes de la sortie de la commande liminfo 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 recommandé de créer un compte système pour l'UID de chaque noeud limite. Dans cet exemple, une UID substituable, bd1, est utilisée pour la Base de données 1.

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 le superutilisateur ou par un utilisateur avec l'indicateur uselimadm activé sont créés avec le noeud limite srmother comme père, ou s'il n'existe pas, avec le noeud limite root 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.

GID

La GID du noeud limite correspondant au processus en cours.

R,Euid et R,Egid

L'UID et la GID réelles et effectives 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 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 trois lignes suivantes de l'affichage de liminfo 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 vous permet de visualiser 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é le plus facilement par sa demi-vie, laquelle peut être consultée au moyen de la commande srmadm.

Accrued usage [cpu.accrue]

Cette mesure cumulative est identique à celle de l'usage ( cpu.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 l'administration à 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 en blanc, les quatre lignes suivantes de l'affichage de la commande liminfo présentent des champs relatifs à la mémoire virtuelle et à l'usage du terminal :

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. 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 zéro (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]

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

Term usage [terminal.usage]

Il s'agit du nombre de secondes de temps de connexion actuellement imputées au groupe.

Term accrue [terminal.accrue]

Il s'agit du nombre de secondes de temps de connexion utilisées par le groupe.

Term limit [terminal.limit]

C'est la valeur maximale permise pour l'attribut terminal.usage. Si elle est de zéro, aucune limite n'est imposée, à moins qu'une restriction découlant de l'héritage prévale.

• Après la troisième ligne en blanc, les deux lignes suivantes de l'affichage de la commande liminfo 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 celle de l'utilisateur actuel seulement.

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 du système (y compris login(1), rlogin(1)-- en fait, 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.

• Après la quatrième ligne en blanc, les quatre lignes suivantes de l'affichage de la commande liminfo présentent ces champs :

Last used [lastused]

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

Répertoire

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

Nom

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

• Après la quatrième ligne en blanc, la dernière ligne de l'écran liminfo affiche ce champ :

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é [^]).

Configuration de Solaris Resource Manager dans un environnement Sun Cluster 2.2

Topologies valides

Vous pouvez installer Solaris Resource Manager sur n'importe quelle topologie Sun Cluster valide, dans des grappes comportant deux noeuds ou plus. Les topologies valides comprennent notamment :

• Symétrique -- deux noeuds configurés de façon identique. Ces deux noeuds offrent des services de données dans des conditions normales.

• Asymétrique -- Configuration à deux noeuds où un noeud agit en qualité de mécanisme de relève pour l'autre noeud.

• N+1 (étoile) -- Deux noeuds ou plus. Un noeud fait office de mécanisme de relève pour les autres noeuds.

• N à N (évolutive) -- Tous les serveurs sont directement connectés à un groupe de disques partagés. Ainsi, n'importe quel serveur peut prendre la relève en ce qui concerne les services de données.

Ces topologies sont décrites en détail au chapitre 1 du Guide d'installation du logiciel Sun Cluster 2.2, qui est accessible à l'adresse docs.sun.com.

Définition des besoins

Avant de configurer Solaris Resource Manager dans un environnement Sun Cluster, vous devez décider du type de contrôle et de suivi des ressources à préconiser pour les passages et les reprises en cas de panne. Si vous configurez tous les noeuds de grappe de la même façon, les limites quant à l'usage seront appliquées de manière identique pour les noeuds principaux et les noeuds de secours.

Certes, les paramètres de configuration ne doivent pas être identiques pour toutes les applications, dans les fichiers de configuration de tous les noeuds, mais toutes les applications doivent au moins être représentées dans les fichiers de configuration de tous les maîtres éventuels de cette équation. Par exemple, si l'application 1 a pour maître phys-host1 mais si elle peut, suite à un passage ou une reprise en cas de panne, passer à phys-host2 ou à phys-host3, cette application doit figurer dans les fichiers de configuration de ces trois noeuds ( phys-host1, phys-host2 et phys-host3).

Solaris Resource Manager est très souple en ce qui concerne la configuration des paramètres d'usage et cumulatifs : très peu de restrictions sont imposées par Sun Cluster. Les choix de configuration sont tributaires des besoins du site. Tenez compte des indications précisées aux sections suivantes pour la configuration de vos systèmes.

Configuration des paramètres de limites de mémoire

Lorsque vous utilisez Solaris Resource Manager avec Sun Cluster, vous devez configurer adéquatement les limites de mémoire, afin de prévenir une reprise en cas de panne, et donc un va-et-vient, inutiles des applications. En général :

• Ne définissez pas de limites de mémoire trop basses. Lorsqu'une application atteint sa limite de mémoire, elle fait l'objet d'une reprise. Cet aspect est particulièrement important pour les applications de base de données, pour lesquelles l'atteinte de la limite de mémoire virtuelle risque d'avoir des conséquences imprévues.

• Ne définissez pas des limites de mémoire identiques pour les noeuds principaux et les noeuds de secours. En effet, un va-et-vient risque de se produire si une application atteint sa limite de mémoire et fait l'objet d'une reprise dans un noeud de secours présentant une limite de mémoire identique. Définissez une limite de mémoire légèrement plus élevée pour le noeud de secours (cette différence dépend des applications, des ressources et des préférences qui prévalent au site). Vous prévenez ainsi le va-et-vient et l'administrateur du système dispose d'un délai pour modifier les paramètres selon les besoins.

• Définissez des limites de mémoire Solaris Resource Manager en vue de l'équilibrage approximatif de la charge des situations à problèmes -- par exemple, pour éviter qu'une application qui s'emballe ne consomme une quantité excessive de ressources.

Utilisation des paramètres d'usage cumulatif

Plusieurs paramètres de Solaris Resource Manager servent à assurer le suivi de la consommation cumulative des ressources système : parts d'UC, nombre de connexions et temps de connexion. Toutefois, en cas de passage ou de reprise après une panne, les données cumulatives sur l'usage (usage de l'UC, nombre de connexions et temps de connexion) sont remises à zéro par défaut sur le nouveau maître, pour toutes les applications qui ont fait l'objet d'un passage ou d'une reprise. Les données cumulatives ne sont pas transférées dynamiquement d'un noeud à un autre. Pour éviter de nuire à l'exactitude de la fonction de cumul de l'usage de Solaris Resource Manager, vous pouvez créer des scripts qui recueillent l'information cumulative des noeuds de la grappe. Étant donné qu'une application peut tourner sur n'importe lequel de ses maîtres éventuels durant une période de cumul, les scripts doivent recueillir l'information cumulative de tous les maîtres possibles d'une application. Pour de plus amples informations, voir Chapitre 8.

Situations de reprise en cas de panne

Sur Sun Cluster, on peut configurer Solaris Resource Manager de sorte que la méthode heuristique pour l'attribution des ressources qui est décrite dans la base de données des limites ( /var/srm/srmDB) demeure inchangée en cas de fonctionnement normal de la grappe ainsi que dans les cas de commutation et de reprise.

Passez en revue les exemples suivants.

Grappe à deux noeuds avec deux applications

Vous pouvez configurer deux applications dans une grappe à deux noeuds, de sorte que chaque hôte matériel fasse office de maître par défaut pour une application. Chaque hôte matériel agit en qualité de noeud de secours pour l'autre hôte matériel. Toutes les applications doivent être représentées dans les fichiers de base de données des limites de Solaris Resource Manager des deux noeuds. Lorsque la grappe fonctionne normalement, chaque application tourne sur son maître par défaut, où toutes les parts lui sont attribuées (car Solaris Resource Manager attribue toutes les ressources disponibles). Lorsqu'un passage ou une reprise a lieu, les deux applications tournent sur un seul noeud, où les parts précisées dans le fichier de configuration leur sont attribuées. Par exemple, l'exemple de fichier de configuration suivant précise que lorsque les deux applications tournent sur le même noeud, 80 parts sont attribuées à l'application 1, tandis que l'application 2 reçoit 20 parts :

#limadm set cpu.shares=80 app1
#limadm set cpu.shares=20 app2
...

Le schéma ci-après présente le fonctionnement normal et en cas de reprise de cette configuration.

Grappe à deux noeuds avec trois applications

Vous pouvez configurer une grappe à deux noeuds avec trois applications de sorte qu'un hôte physique ( phys-host1) soit le maître par défaut d'une application et le second hôte physique ( phys-host2) le maître par défaut des deux autres applications. Dans l'exemple suivant, supposons que le fichier de base de données des limites se trouve dans chaque noeud. Le fichier de base de données des limites ne change pas lorsqu'un passage ou une reprise a lieu :

#limadm set cpu.shares=50	 app1
#limadm set cpu.shares=30	 app2
#limadm set cpu.shares=20	 app3
...

Lorsque la grappe fonctionne normalement, l'application 1 se voit attribuer toutes les parts disponibles sur son maître par défaut, soit phys-host1. Les applications 2 et 3 reçoivent 60 et 40 parts, respectivement, sur leur maître par défaut, soit phys-host2, car une partie proportionnelle de toutes les ressources disponibles est attribuée à chaque application. Si une reprise ou un passage a lieu et si l'application 1 passe à phys-host2, les parts des trois applications sont réattribuées conformément au fichier de base de données des limites. Ainsi, l'application 1 reçoit 50 parts, l'application 2 en obtient 30 et l'application 3 recueille 20 parts.

Le schéma ci-après présente le fonctionnement normal et en cas de reprise de cette configuration.

Reprise de l'hôte logique seulement

Dans une configuration pour laquelle plusieurs hôtes logiques ont le même maître par défaut, il est possible pour un hôte logique (et ses applications associées) d'effectuer une reprise ou de passer à un noeud de secours, tandis que le maître par défaut continue à tourner dans la grappe. En tel cas, l'application qui est transférée se voit attribuer les ressources disponibles qui sont précisées dans le fichier de configuration figurant dans le noeud de secours. Le comportement est identique à celui décrit pour les grappes à deux noeuds.

Le schéma ci-après présente le fonctionnement normal et en cas de reprise de cette configuration.