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.