Structure suggérée de noeud limite d'administrateur de groupe

Un des problèmes auxquels les sous-administrateurs peuvent être confrontés est qu'ils partagent les mêmes limites de groupe que les membres. Par exemple, si une limite de processus est définie sur le noeud limite du chef de groupe, elle fixe le nombre de processus pouvant être utilisés par l'ensemble du groupe, incluant le chef de groupe. A moins de définir des limites additionnelles, tout utilisateur du groupe d'ordonnancement qui excède sa limite de processus empêchera l'administrateur de groupe de créer de nouveaux processus.

Pour éviter cela, l'administrateur doit définir des limites individuelles pour chaque membre du groupe. Pour que ces limites soient efficaces, il peut être nécessaire de les définir avec des contraintes excessives. De plus, le fait de forcer un administrateur de groupe à gérer des limites individuelles va à l'encontre du but de Solaris Resource Manager qui vise à contrôler les ressources de manière hiérarchique.

L'administrateur central peut contourner ce problème en modifiant la structure des noeuds limites au sein de son groupe. Au lieu de placer les utilisateurs directement sous son propre noeud limite, il peut créer un noeud limite «contrôle» sous le sien en tant que seul noeud limite enfant, puis rendre les utilisateurs enfants du noeud Contrôle, comme dans l'arbre ci-dessous.

Figure 5-1 Structure du noeud limite de l'administrateur de groupe

Dans l'exemple ci-dessus, l'UID du compte de l'administrateur de groupe correspond à celui du noeud limite «Réel», père de l'arbre. Il s'agit du noeud limite dont l'indicateur admin serait activé. Un compte fictif serait créé pour le noeud limite "Contrôle". Il n'est pas nécessaire d'autoriser une ouverture de session sur ce compte. Les noeuds limites "A", "B" et "C" correspondent aux utilisateurs placés sous le contrôle de l'administrateur de groupe.

Dans cet exemple, la limite de processus du noeud "Réel" pourrait être de 100, tandis que celle du noeud "Contrôle" pourrait être de 90, et les limites des utilisateurs individuels sont de 0. Avec cette configuration, même si les utilisateurs A, B et C utilisaient un total de 90 processus (maximum autorisé), le sous-administrateur pourrait quand même créer 10 processus.

Toutefois, des utilisateurs peuvent quand même empêcher les autres de créer des processus. La seule façon de l'éviter est de fixer des limites individuelles pour les utilisateurs visés. Toujours dans notre exemple, ces limites pourraient être de 40 pour chaque utilisateur, ce qui assurerait une certaine souplesse tout en empêchant un seul utilisateur de priver les autres de ressources.

Notez également que, dans cet exemple, l'administrateur central peut créer des noeuds limites additionnels pour des nouveaux utilisateurs en tant qu'enfants du noeud limite "contrôle" et ce, sans avoir à rééquilibrer les limites.