Exemple d'attribution de parts

Structure de l'arbre d'ordonnancement

Les paragraphes ci-après traitent de la structure de l'arbre d'ordonnancement, sujet auquel l'administrateur central doit porter une attention particulière :

• L'arbre d'ordonnancement est la structure utilisée par Solaris Resource Manager pour mettre en oeuvre une hiérarchie de contrôle des ressources et des privilèges. Si un sous-administrateur obtient le contrôle d'un sous-arbre de l'arbre d'ordonnancement auquel il n'a normalement pas accès, il peut accéder à des ressources et privilèges additionnels sans l'approbation de l'administrateur central. Cela peut se produire lorsque l'administrateur supprime un noeud limite en laissant un sous-arbre orphelin.

• L'administrateur central peut exécuter la commande limreport(1SRM) pour repérer les sections orphelines de l'arbre par l'intermédiaire de l'identificateur d'orphelin intégré. Tout orphelin détecté doit être relié immédiatement.

• Lorsqu'un noeud limite est créé, il est constitué en grande partie de zéros, forçant ainsi la plupart des indicateurs à adopter la valeur par défaut inherit (héritage). Il s'agit du résultat souhaité pour la plupart des indicateurs, puisqu'ils sont utilisés pour indiquer les privilèges de périphérique. Deux indicateurs sont mis à zéro de façon explicite lors de la création d'un noeud limite : uselimadm et admin. Cette mesure vise à empêcher que les nouveaux utilisateurs obtiennent automatiquement des privilèges administratifs.

Description de l'arbre

L'arbre ci-dessous illustre une structure comportant plusieurs chefs de groupe et utilisateurs. La racine de l'arbre est l'utilisateur root. Un noeud limite de chef de groupe est indiqué par deux nombres entiers qui représentent les valeurs de ses attributs copu.shares et cpu.myshares respectivement. Un noeud limite feuille est indiqué par un seul nombre entier, la valeur de son attribut shares.

Figure 6-1 Structure de l'arbre d'ordonnancement

Calcul de la part attribuée

Dans la figure précédente, des processus sont reliés aux noeuds limites A, C et N. Au niveau supérieur, il suffirait de partager l'unité centrale entre A et M du fait qu'il n'y a aucun processus pour W ou un membre de ce groupe. Le rapport des parts entre A et M étant de 3:1, la part attribuée au niveau supérieur serait de 75% au groupe A et 25% au groupe M.

La part de 75% accordée au groupe A serait partagée entre les utilisateurs actifs (A et C) en fonction du rapport de leurs parts au sein du groupe A (1:2). Notez que l'attribut myshares est utilisé pour déterminer les parts de A par rapport à ses enfants. Par conséquent, l'utilisateur A obtiendrait un tiers de la part attribuée au groupe, et C les deux tiers. Le total attribué au groupe M serait accordé au noeud N, car il est le seul à comporter des processus.

La distribution globale des parts d'UC disponibles serait donc de 0,25 pour A, 0,5 pour C et 0,25 pour N.

Maintenant, supposons que les processus de A, C et N ont toujours besoin de l'UC et que le système dispose d'un maximum de deux processeurs. Dans un tel cas, Solaris Resource Manager ferait en sorte que chaque processus reçoive les pourcentages ci-après du total des ressources de l'UC :

• pour les deux processus de A : 12,5% chacun

• pour le processus de C : 50%

• pour les trois processus de N : 8,3% chacun

Le taux de progression de chaque processus est contrôlé de façon que la cible soit atteinte pour chaque noeud limite. Sur un système doté de plus de deux unités centrales mais de seulement ces six processus exécutables, le processus de C ne parviendra pas à consommer sa part de 50%, et le reste sera réparti proportionnellement entre A et N.