Exemple de regroupement de serveurs

Le premier exemple illustre les commandes suivantes :

liminfo

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

limadm

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

srmuser

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

srmstat

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

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

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

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

Figure 2-1 Regroupement des serveurs

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

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

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

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

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

% limadm set cpu.shares=3 db1

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

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

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

Voir "Serveur d'applications type".

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

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

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