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.