Chapitre 10 Utilisation avancé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. Il y est présenté 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 3.0 12/01 (et supérieur).

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 obtenir un exemple de hiérarchie servant à contrôler l'environnement d'exécution de travaux par lot, reportez-vous à la rubrique Exemples. Cette rubrique porte également sur 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 le traitement transactionnel en ligne (OLTP) et le système d'aide à la décision (SAD). De même, leur incidence sur le système figure à mi-chemin entre ces deux éléments. Un traitement par lot peut comporter de nombreuses transactions répétitives, comprenant des calculs complexes, portant sur une base de données. A 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.

En principe, deux méthodes sont utilisées pour déterminer l'incidence sur les ressources du traitement par lot :

• Une copie de la base de données est effectuée sur un système distinct puis le traitement par lot est exécuté. Ensuite, la charge de travail imposée à ce système est établie. (Veuillez noter 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.)

• Le contrôle des ressources de l'UC est utilisé.

Etant 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'utilisation des E/S par le traitement par lot. Prenez toutefois garde à ce 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 goulet d'étranglement dans le système (il s'agit habituellement du plus petit point d'acheminement 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, le traitement par lot risque de se prolonger durant les heures de bureau lorsqu'une anomalie survient dans le système ou que le nombre de ventes a été très élevé durant la journée. 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 transactions 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 gère l'attribution des ressources au niveau du système, parfois selon les décisions quant à la répartition de l'utilisation entre les services. La rubrique Exemples indique comment se servir de la hiérarchie de Solaris Resource Manager à cette fin.

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. C'est pourquoi il convient de 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.

Les limites de mémoire virtuelle doivent être fixées à un niveau élevé, afin de ne pas être 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. Etant 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'utilisation faite 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.

Il est toutefois possible de contrôler le NFS à l'aide de la gestion des ports réseau. Par exemple, vous pouvez faire appel à Solaris Bandwidth Manager pour contrôler le nombre de paquets NFS qui se trouvent sur le serveur. Vous pouvez é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. Trois topologies de base sont utilisées sur les systèmes qui hébergent des serveurs Web.

Gestion des ressources d'un serveur Web regroupé

Il est possible de 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, 20 parts sont attribuées à un serveur Web. Ainsi, celui-ci disposera au moins de 20 % des ressources du processeur, si la base de données impose de lourdes exigences au processeur.

Pour un autre exemple de serveur Web, consultez la rubrique Mise en place d'un processus Web frontal.

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

Souvent, on doit faire appel à la gestion des ressources pour contrôler le comportement d'un serveur Web individuel. Par exemple, de nombreux utilisateurs peuvent se partager un serveur Web et chacun d'eux peut lancer son propre programme 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, vous pouvez définir des limites par processus.

Gestion des ressources de plusieurs serveurs Web virtuels

Souvent, un seul ordinateur est utilisé pour héberger plusieurs serveurs Web virtuels de manière regroupée. Dans une telle circonstance, plusieurs instances du processus du serveur Web httpd sont présentes et un profit accru peut être tiré du contrôle des ressources par l'entremise de Solaris Resource Manager.

Chaque serveur Web peut être exécuté à titre d'UID UNIX différent en définissant un paramètre dans le fichier de configuration du serveur Web. Cela permet de faire 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 un UID UNIX distinct, vous pouvez définir des limites différentes pour chaque serveur Web. Cet aspect s'avère particulièrement utile pour contrôler et comptabiliser la consommation des ressources sur un ordinateur qui héberge plusieurs serveurs Web.

Dans ce cas, vous pouvez vous servir de plusieurs contrôles et limites des ressources de Solaris Resource Manager ou de leur totalité :

Parts [cpu.shares]

cpu.shares permet d'allouer de façon proportionnelle les ressources à différents serveurs Web.

Quantité limite de mémoire [memory.limit]

memory.limit permet de limiter la quantité de mémoire virtuelle dont le serveur Web peut se servir. Cela évite qu'un serveur Web provoque la panne d'un autre serveur suite à une erreur d'allocation de mémoire.

Quantité limite de mémoire par processus [memory.plimit]

Limite de la mémoire par processus permet de limiter la quantité de mémoire virtuelle pouvant être utilisée par un processus cgi-bin. Ainsi, un processus cgi-bin ne pourra jamais faire tomber en panne son serveur Web respectif.

Nombre limite de processus [process.limit]

Nombre total maximal de processus autorisés à se relier à un serveur Web 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 et héberger deux unités fonctionnelles différentes à partir d'une même machine. Chacune de ces unités fonctionnelles assume les coûts d'une partie de l'ordinateur, 40 et 60% par exemple. Dans ce cas de figure, l'administrateur peut souhaiter faire en sorte que le service qui paie 40% de l'ordinateur ne reçoive jamais plus que cette part.

Avec les groupes de processeurs, il est possible de subdiviser les charges de travail (40 et 60%) en attribuant 10 processeurs à l'unité disposant des 40% et 14 processeurs à celle détenant les 60% restant.

Lorsque sont utilisés des groupes de processeurs avec Solaris Resource Manager, il est primordial de bien 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'entre eux.

Situation à éviter

La situation ci-après doit être évitée.

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

Serveur d'applications type

Le texte suivant s'affiche suite à une inscription liminfo de bd1 à la fin de l'exemple de la rubrique précédente. Texte entré :

# liminfo db1

Résultat :

Figure 10-7 Inscription liminfo

Les parties qui suivent décrivent la sortie 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.

Login name

Il s'agit du nom de connexion et du GID initial de la table des mots de passe correspondant à l'UID du noeud limite associé. Un UID système est associé à chaque noeud limite. Il est recommandé de créer un compte système pour l'UID de chaque noeud limite. Dans cet exemple, un UID substituable, bd1, est utilisé 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, cet UID est identique à l'UID réel du processus (l'utilisateur en session), mais dans certains cas (décrits plus loin), il peut être différent.

Gid

Le GID du noeud limite correspondant au processus en cours.

R,Euid et R,Egid

L'UID et le GID réels 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 affiche des informations sur un utilisateur autre que celui par défaut (c'est-à-dire si vous avez spécifié un nom de connexion ou un 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 root. 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 vide, 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'est-à-dire 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. Cette valeur change à mesure que d'autres utilisateurs ouvrent et ferment une session (ou que des noeuds limites deviennent actifs ou inactifs), car seuls les utilisateurs actifs sont inclus dans le calcul. L'utilisation récente de l'utilisateur actuel n'est pas comprise dans ce calcul.

E-share

Il s'agit de la part effective de cet utilisateur (c'est-à-dire le pourcentage réel de 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 au fur et à mesure que l'utilisateur consomme (ou ne consomme pas) de ressources de l'UC. Les noeuds limites actifs mais inactifs (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'utilisation cumulative des ressources système servant à déterminer la priorité d'ordonnancement. Généralement, cette valeur indique l'utilisation récente de l'UC, bien que d'autres paramètres puissent être pris en compte. La commande srmadm 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'utilisation 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 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'utilisation, cette valeur indique l'utilisation cumulative de tous les noeuds limites appartenant au groupe, ainsi que celle du noeud limite actuel.

• Après la deuxième ligne vides, les quatre lignes suivantes de l'affichage de la commande liminfo présentent des champs relatifs à la mémoire virtuelle et à l'utilisation du terminal :

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

Il s'agit de l'utilisation de mémoire combinée 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'utilisation de tout le groupe d'ordonnancement, tandis que la deuxième valeur indique seulement celle de l'utilisateur actuel.

Mem limit [memory.limit]

Utilisation maximale de mémoire autorisée pour tous les processus reliés à ce noeud limite et ses membres (s'il y en a). Il s'agit de la somme d'utilisation de mémoire maximale de 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'utilisation maximale 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'utilisation globale des ressources de mémoire pendant une période donnée.

Term usage [terminal.usage]

Il s'agit du temps de connexion exprimé en secondes actuellement imputé au groupe.

Term accrue [terminal.accrue]

Il s'agit du temps de connexion exprimé en secondes utilisé par le groupe.

Term limit [terminal.limit]

Il s'agit de 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.

• Les deux lignes de l'affichage de la commande liminfo suivant la troisième ligne vide 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. Veuillez noter que cette valeur renvoie aux processus et qu'il ne s'agit pas d'un calcul du nombre de threads qui constituent 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'utilisation de l'ensemble du groupe d'ordonnancement, tandis que la deuxième valeur indique celle de l'utilisateur actuel seulement.

Process limit [process.limit]

Il s'agit du nombre total maximum autorisé de processus reliés à ce noeud limite et à ses membres.

Current logins [logins]

Il s'agit du 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é. A 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 vide, les quatre lignes suivantes de l'affichage de la commande liminfo présentent les champs suivants :

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.

Directory

Il s'agit du 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

Il s'agit des informations sur la base de données bd1 (finger) et qui sont généralement constituées 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

Il s'agit du 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 vide, la dernière ligne de l'écran liminfo affiche le champ suivant :

Flags

Ce sont les indicateurs activés ou ayant la valeur d'un groupe dans le noeud limite. 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 3.0 mis à jour

Topologies valides

Vous pouvez installer Solaris Resource Manager sur n'importe quelle topologie Sun Cluster 3.0 mis à jour valide. Pour une description détaillée des topologies valides, reportez-vous à la rubrique Sun Cluster 3.0 12/01 Concepts.

Définition des besoins

Avant de configurer le produit 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 commutations et les basculements. Si vous configurez tous les noeuds de grappe de la même façon, les limites quant à l'utilisation 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 application. Par exemple, si l'application 1 a pour maître schôte_phys_1 mais si elle peut, suite à un passage ou une reprise en cas de panne, passer à schôte_phys_2 ou à schôte_phys_3, cette application doit figurer dans les fichiers de configuration de ces trois noeuds ( schôte_phys_1, schôte_phys_2 et schôte_phys_3).

Solaris Resource Manager est très souple en ce qui concerne la configuration des paramètres d'utilisation et paramètres 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 dans les rubriques suivantes pour la configuration de vos systèmes.

Configuration des paramètres de limites de mémoire

Lorsque vous utilisez le produit Solaris Resource Manager avec Sun Cluster, vous devez configurer adéquatement les limites de mémoire, afin de prévenir un basculement, 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 peut faire 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 sur le site). Vous prévenez ainsi le va-et-vient et l'administrateur 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'utilisation cumulative

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 commutation ou de basculement, les données cumulatives sur l'utilisation (utilisation 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'utilisation de Solaris Resource Manager, vous pouvez créer des scripts qui recueillent l'information cumulative des noeuds de la grappe. Etant 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 donnée. Pour de plus amples informations, reportez-vous au Chapitre 9.

Situations de basculement

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 ou dans des situations de commutation et de basculement. Pour de plus amples informations, reportez-vous à la rubrique Exemple d'attribution de parts.

Les rubriques qui suivent présentent des exemples de scénarios.

• Les deux premières rubriques, Grappe à deux noeuds avec deux applications et Grappe à deux noeuds avec trois applications, présentent des scénarios de basculement pour des noeuds entiers.

• La rubrique Basculement du groupe de ressources seulement illustre le basculement d'une application seule.

Dans un environnement de grappe, une application est configurée comme un élément d'un groupe de ressources (GR). Lorsqu'une panne se produit, le groupe de ressources ainsi que les applications qui lui sont associées basculent sur un autre noeud. Dans les exemples qui suivent, l'Application 1 (App-1) est configurée dans le groupe de ressources GR-1, l'Application 2 (App-2) dans le groupe de ressources GR-2 et l'Application 3 (App-3) dans le groupe de ressources GR-3.

Bien que les nombres de parts attribuées restent les mêmes, le pourcentage de ressources d'UC alloué à chaque application change après le basculement, en fonction du nombre d'applications tournant sur le noeud et du nombre de parts attribué à chaque application active.

Dans ces scénarios, prenons les configurations suivantes :

• Toutes les applications sont configurées sous un noeud limite père commun.

• Les applications sont les seuls processus actifs sur les noeuds.

• Les bases de données de limites sont configurées de la même manière sur chaque noeud de la grappe.

Grappe à deux noeuds avec deux applications

Vous pouvez configurer deux applications dans une grappe à deux noeuds, de sorte que chaque hôte physique (schôte_phys_1, schôte_phys_2) fasse office de maître par défaut pour une application. Chaque hôte physique agit en qualité de noeud de secours pour l'autre hôte physique. 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 ressources de l'UC lui sont attribuées par Solaris Resource Manager.

Lorsqu'un passage ou un basculement 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, le fichier de configuration suivant précise que 80 parts sont attribuées à l'application 1, contre 20 pour l'application 2.

# limadm set cpu.shares=80 App-1 
# limadm set cpu.shares=20 App-2 
...

Le schéma ci-après présente le fonctionnement normal ainsi que le fonctionnement d'un basculement de cette configuration. Notez que, bien que le nombre de parts attribué ne change pas, le pourcentage de ressources d'UC disponibles pour chaque application peut changer, selon le nombre de parts attribué à chaque processus réclamant du temps d'UC.

Grappe à deux noeuds avec trois applications

Vous pouvez configurer une grappe à deux noeuds avec trois applications de sorte qu'un hôte physique (schôte_phys_1) soit le maître par défaut d'une application et le second hôte physique (schôte_phys_2) 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'une commutation ou qu'un basculement a lieu :

# limadm set cpu.shares=50	 App-1
# limadm set cpu.shares=30	 App-2
# limadm set cpu.shares=20	 App-3
...

Lorsque la grappe fonctionne normalement, l'application 1 se voit attribuer toutes les parts disponibles sur son maître par défaut, soit schôte_phys_1. Cela équivaut à 100 pour cent des ressources de l'UC, étant donné qu'il s'agit de la seule application à demander des ressources de l'UC sur ce noeud. Les applications 2 et 3 reçoivent respectivement 30 et 20 parts sur leur maître par défaut, schôte_phys_2. L'Application 2 recevrait donc 60 pour cent et l'Application 3, 40 pour cent des ressources de l'UC pendant un fonctionnement normal.

Si un basculement ou une commutation se produit et que l'Application 1 bascule vers schôte_phys_2, les parts des trois applications restent les mêmes, mais les pourcentages de ressources de l'UC sont réattribués en fonction du fichier de base de données des limites.

• L'application 1, avec 50 parts, reçoit 50 pour cent de l'UC.

• L'application 2, avec 30 parts, reçoit 30 pour cent de l'UC.

• L'application 3, avec 20 parts, reçoit 20 pour cent de l'UC.

Le schéma ci-après présente le fonctionnement normal ainsi que le fonctionnement d'un basculement de cette configuration.

Basculement du groupe de ressources seulement

Dans une configuration où plusieurs groupes de ressources ont le même maître par défaut, il est possible pour un groupe de ressources (et ses applications associées) d'effectuer un basculement ou d'être commuté vers un noeud de secours, tandis que le maître par défaut continue à tourner dans la grappe.

en tel cas, l'application qui bascule se voit attribuer des ressources tel que précisé dans le fichier de configuration figurant sur le noeud de secours. Dans cet exemple, les fichiers de bases de données des limites ont la même configuration sur le noeud principal et sur le noeud secondaire.

Par exemple, ce fichier de configuration spécifie que l'Application 1 reçoit 30 parts, l'Application 2, 60 parts et l'Application 3, 60 parts.

# limadm set cpu.shares=30 App-1
# limadm set cpu.shares=60 App-2
# limadm set cpu.shares=60 App-3
... 

Le diagramme qui suit illustre les opérations normales et de basculement de cette configuration, où GR-2, qui contient l'Application 2, bascule vers schôte_phys_2. Notez que, bien que le nombre de parts attribué ne change pas, le pourcentage de ressources d'UC disponibles pour chaque application peut varier, selon le nombre de parts attribué à chaque application réclamant du temps d'UC.