副管理者 l ノードの推奨構造

副管理者にとって、グループの制限値をグループメンバーと共有していることが問題になる場合があります。たとえば、グループヘッダーの l ノードにプロセスの制限値が設定されている場合には、グループヘッダーを含むグループ全体で使用できるプロセス数が制御されます。さらに制限が加えられない限り、スケジューリンググループのどのユーザーも、自分のプロセスリミットを超過することによって、副管理者が新しいプロセスを作成するのを妨げることができます。

これを防ぐ 1 つの方法は、副管理者がグループメンバーのそれぞれに個別に制限を設定することです。しかし、これを効果的なものにするには、制限を過度に厳しくしなければならないかもしれません。さらに、副管理者に個別の制限値を管理させるのは、階層的資源制御という Solaris Resource Manager の目標に反しています。

この問題を解決する別の方法は、管理者がグループ内の l ノードの構造を変えることです。管理者の l ノードの下に直接ユーザーを置く代わりに、副管理者の l ノードの下に唯一の子 l ノードとして「制御」 l ノードを作成し、ユーザーを制御 l ノードの子にします。この構造を次に示します。

図 5-1 副管理者 l ノードの構造

図 5-1 で、副管理者のアカウントのユーザー ID は、「Actual」というラベルがあるツリーの親である l ノードのユーザー ID に対応します。admin フラグはこの l ノードに設定します。「Control」l ノードにはダミーアカウントを作成します。このアカウントに対してはログインを許可する必要はありません。「A」、「B」、「C」のラベルがある l ノードは副管理者の制御下にあるユーザーです。

この場合、プロセスリミットを「Actual」l ノード 100、「Control」l ノード 90、個々のユーザー 0 とするとします。そうすれば、ユーザー A、B、C が合わせて 90 のプロセスを使用しても (すべて許可されます)、副管理者はまだ 10 のプロセスを作成できます。

この場合でも、各ユーザーは他のユーザーがプロセスを作成するのを妨げることがあります。これを避ける唯一の方法は、各ユーザーに個別の制限値を設定することです。この例の場合、個別の制限値をそれぞれ 40 にすれば、1 人のユーザーが他のユーザーを完全に除外することはなく、柔軟性が保たれます。

さらに、この例では、管理者が「Control」l ノードの子として新しいユーザーの l ノードを作成しても、制限値のバランスが崩れる心配はありません。