test

Sun N1 Grid Engine 6.1 管理ガイド

チケットに基づくポリシーの構成

個別のポリシーに現在割り当てられているチケットは、「Current Active Tickets」の下に表示されます。その数字は、ポリシーの相対的な重要性を反映し、特定のポリシーが現時点でクラスタを優先使用しているかどうか、あるいはポリシー間のバランスが取られているかどうかを示します。

チケットは量的な目安を提供します。たとえば、共有ベースポリシーへのチケット割り当て量が、機能ポリシーへの割り当て量の 2 倍の場合、共有ベースポリシーには機能ポリシーの 2 倍のリソースエンタイトルメントがあることを意味します。この意味では、チケットは企業の株式に非常によく似ています。

総チケット数に特別な意味はありません。重要なのはポリシー間の関係だけです。つまり、ポリシーの相対的な重要性を細かく調整できるよう、総チケット数は通常かなり大きな数字になります。

「Edit Tickets」では、共有ツリーポリシーと機能ポリシーに割り当てられたチケットの数を変更できます。詳細については、「チケットの編集」を参照してください。

優先ポリシーにより分配される合計チケット量を制御するには、「Share Override Tickets」チェックボックスを選択します。そのほかのポリシーと優先カテゴリに使用可能なチケットプールを基準として、個別ジョブの重要性を制御するには、チェックボックスをクリアします。詳細については、「優先チケットの共有」を参照してください。

そのすべてのジョブの合計に関して一定のエンタイトルメントレベルをカテゴリメンバーに与えるには、「Share Functional Tickets」チェックボックスを選択します。カテゴリメンバーのエンタイトルメントに基づいて、各ジョブに同じエンタイトルメントレベルを付与するには、チェックボックスをクリアします。詳細については、「機能チケットの分配の共有」を参照してください。

機能ポリシーでスケジューリング可能なジョブの最大数を設定できます。デフォルト値は 200 です。

各配列ジョブに認められている保留中のサブタスクの最大数を設定できます。デフォルト値は 50 です。スケジューリングのオーバーヘッドを軽減するにはこの設定を使用します。

ポリシーが衝突するある種のケースを解決するには、「Ticket Policy Hierarchy」を指定できます。ポリシー間の衝突の解決は、特に保留中のジョブに関係します。詳細については、「チケットポリシー階層の設定」を参照してください。

表示されている情報を更新するには、「Refresh」をクリックします。

「Policy Configuration」に対して行なった変更を保存するには、「Apply」をクリックします。変更を保存することなくダイアログボックスを閉じるには、「Done」をクリックします。

チケットの編集

共有ツリーチケットと機能チケットの合計数を編集できます。優先チケットは、優先ポリシーの構成を介して直接割り当てられます。そのほかのチケットプールは、ポリシーに関連付けられているジョブ間で実際のポリシー構成に基づいて自動的に分配されます。

注 –

すべての共有ベースチケットと機能チケットは、これらのポリシーに関連付けられているジョブに分配されます。優先チケットは、現在アクティブなジョブには適用できない場合があります。その結果、優先ポリシーに定義済みのチケットがある場合であっても、アクティブな優先チケットはゼロになる場合があります。

優先チケットの共有

管理者は、優先カテゴリのさまざまなメンバー、つまり個別ユーザー、プロジェクト、部署、またはジョブにチケットを割り当てます。その結果、カテゴリメンバーに割り当てられたチケットの数が、そのカテゴリメンバーの下でジョブに割り当てられるチケットの数を決定します。たとえば、ユーザー A に割り当てられたチケットの数は、ユーザー A のすべてのジョブに割り当てられるチケットの数を決定します。

注 –

ジョブカテゴリに割り当てられたチケットの数は、そのカテゴリのジョブに割り当てられるチケットの数を決定しません。

sched_conf(5) の share_override_tickets パラメータを設定するには、「Share Override Tickets」チェックボックスを使用します。このパラメータは、カテゴリメンバーのチケット値からどのようにジョブチケット値が得られるかを制御します。「Share Override Tickets」チェックボックスを選択すると、カテゴリメンバーのチケットは、このメンバーの下でジョブに均等に分配されます。「Share Override Tickets」チェックボックスをクリアすると、各ジョブは、カテゴリメンバーに対して定義されているチケット量を継承します。すなわち、カテゴリメンバーのチケットが、そのジョブのすべてのジョブに繰り返されます。

優先ポリシーにより分配される合計チケット量を制御するには、「Share Override Tickets」チェックボックスを選択します。この設定を使用すると、多くのジョブが 1 つのカテゴリメンバーの支配下にある場合、ジョブに割り当てられるチケットの量は無視できるほど少なくなります。たとえば、多くのジョブがユーザーカテゴリの 1 メンバーに属する場合、チケット量は減少する場合があります。

そのほかのポリシーと優先カテゴリに使用可能なチケットプールを基準とした各ジョブの重要性を制御するには、「Share Override Tickets」チェックボックスをクリアします。この設定を使用すると、カテゴリメンバーの支配下にあるジョブの数は重要ではなくなります。そのジョブは常に同じ数のチケットを取得します。ただし、優先チケットを受け取る権利を持つジョブの数が大きくなるにつれ、システム内の優先チケットの合計数は大きくなります。このような場合、そのほかのポリシーは 重要性を喪失することがあります。

機能チケットの分配の共有

機能ポリシーは、機能カテゴリのエンタイトルメントの分配を定義します。さらにこのポリシーは、これらの各カテゴリのすべてのメンバーに関する分配を定義します。そのため、機能ポリシーは、2 レベルの共有ツリーに類似しています。異なる点は、ジョブは複数のカテゴリに同時に関連付けることができる、という点です。たとえば、ジョブは特定のユーザーに属するだけでなく、ジョブはプロジェクト、部署、およびジョブクラスに属することも可能です。

ただし、共有ツリーと同様に、機能カテゴリからジョブが受けるエンタイトルメントの配分は、次の要素によって決まります。

sched_conf(5) の share_functional_shares パラメータを設定するには、「Share Functional Tickets」チェックボックスを使用します。このパラメータは、ジョブの配分の決定にカテゴリメンバーの配分をどのように使用するかを定義します。特定のユーザーやプロジェクトなどのカテゴリメンバーに割り当てられた配分をすべてのジョブに繰り返すことも、カテゴリメンバーのジョブの間で配分を振り分けることもできます。

こうした配分は株式に例えることができます。このような配分は、同じカテゴリメンバーに属するジョブには何の意味もありません。どちらの場合も、同じカテゴリメンバーのすべてのジョブは同じ数の配分を受けます。しかし、同じカテゴリ内の配分量の比較では、配分数は意味を持ちます。「Share Functional Tickets」チェックボックスを選択すると、同じカテゴリメンバーに属する多くの兄弟を持つジョブが受け取る配分は比較的少なくなります。一方、「Share Functional Tickets」チェックボックスをクリアすると、すべての兄弟ジョブは、そのカテゴリーメンバーと同じ分配量を受け取ります。

そのすべてのジョブの合計に関して一定のエンタイトルメントレベルをカテゴリメンバーに与えるには、「Share Functional Tickets」チェックボックスを選択します。ただし、ジョブに多くの兄弟が存在する場合、各ジョブのエンタイトルメントは、無視できるほど小さくなることがあります。

カテゴリメンバーのエンタイトルメントに基づいて、各ジョブに同じエンタイトルメントレベルを与えるには、「Share Functional Tickets」チェックボックスをクリアします。システム内のジョブの兄弟の数は問題にはなりません。

注 –

多数のジョブを抱えるカテゴリメンバーは、機能ポリシーを優先使用する可能性があります。

share functional shares の設定は、分配される機能チケットの合計数を決定しないことに注意してください。合計数は常に、機能ポリシーのチケットプールに対して管理者により定義されたものです。share functional shares パラメータは、単に機能ポリシー内での機能チケットの分配方法に影響するだけです。

例 5–1 機能ポリシーの例

この例は、share override 機能ポリシーのチケット機能を理解することなく、SGE-5.3 スケジューラのオプション -user_sort true を N1GE 6.1 構成に変換しようとする場合の一般的なシナリオを表しています。

ユーザーに基づく単純な均等割当では、次のパラメータを使用してグローバル構成 sge_conf(5) を設定します。

-enforce_user auto

-auto_user_fshare 100

次に、スケジューラ構成 sched_conf(5) で -weight_tickets_functional 10000 を使用します。この操作によって、ユーザーごとに 100 の配分がスケジューリングされた、ユーザーに基づく均等割当に対して、機能ポリシーが使用されます。

スケジューリング実行時間のチューニング

保留中のジョブは、「ジョブのソート」で説明されているように、各ジョブが持つチケットの数に従ってソートされます。スケジューラは、保留中の各ジョブが持つチケットの数を、マスターデーモン sge_qmaster に報告します。ただし、非常に多くの数のジョブを抱えるシステムでは、チケットの報告をオフにしたい場合があります。チケットの報告をオフにすると、チケットに基づくジョブ優先順位が使用不可になります。ジョブのソート順序は、各ジョブが発行される時間にのみ基づいて行われます。

保留中のジョブチケットによる sge_qmaster への報告をオフにするには、「Policy Configuration」ダイアログボックスの「Report Pending Job Tickets」チェックボックスをクリアします。これにより、 sched_conf(5) の report_pjob_tickets パラメータが false に設定されます。

チケットポリシー階層の設定

チケットポリシー階層は、衝突するチケットポリシーの一部のケースを解決する手段を提供します。チケットポリシー間の衝突の解決は、特に保留中のジョブに関係します。

そのようなケースは、共有ベースポリシーおよび機能ポリシーと結び付いて発生する場合があります。どちらのポリシーでも、同じリーフレベルのエンティティーに属するジョブへの優先順位への割り当ては、先着順で行われます。リーフレベルのエンティティーには、次のものが該当します。

ジョブカテゴリーのメンバーは、リーフレベルのエンティティーには含まれません。そのため、同じユーザーの最初のジョブが最大量を受け取り、2 番目のジョブが 2 番目に多い量を受け取り、3 番目がそれに続く、となります。

別のポリシーが異なる順序を指定した場合に、衝突が発生する可能性があります。そのため、たとえば、優先ポリシーが 3 番目のジョブをもっとも重要なものとして定義し、発行される最初のジョブが最後に来る場合があります。

ポリシー階層は、共有ツリーポリシーや機能ポリシーよりも、優先ポリシーにより高い優先順位を与える場合があります。このようなポリシー階層により、優先ポリシーの高優先順位ジョブが、ほかの 2 つのポリシーのジョブよりも多くのエンタイトルメントを獲得します。このようなジョブは、共有ツリーで同じリーフレベルのエンティティー (ユーザーまたはプロジェクト) に属する必要があります。

チケットポリシー階層は、3 文字までの組み合わせから構成できます。これらの文字は、次の 3 つのチケットポリシーの名前の最初の文字です。

これらの文字を使用しててチケットポリシーの階層を作成します。最初の文字で、最上位のポリシーを定義します。最後の文字で、階層の最下位を定義します。ポリシー階層に存在しないポリシーは、階層に影響を与えません。ただし、階層に存在しないポリシーも、ジョブのチケットのソースとなる場合があります。ただし、これらのチケットはそのほかのポリシーにおけるチケット計算には影響しません。各ジョブが全エンタイトルメントを定義できるように、すべてのポリシーのすべてのチケットは合計されます。

次の例では、2 つの設定と、これらの設定が保留中のジョブの順序にどのように影響するかを説明します。


policy_hierarchy=OS

  1. 優先ポリシーは、保留中の各ジョブに適切な数のチケットを割り当てます。

  2. 2 つのジョブが同じユーザーまたは同じリーフレベルのプロジェクトに属する場合、チケットの数は共有ツリーでのエンタイトルメントの割り当てを決定します。続いて共有ツリーのチケットは、保留中のジョブに対して計算されます。

  3. 優先ポリシー、および共有ツリーポリシーからのチケットは、階層内にないそのほかのアクティブなポリシーとともに合算されます。結果のチケット数が最高であるジョブは、最高のエンタイトルメントを獲得します。


policy_hierarchy=OF

  1. 優先ポリシーは、保留中の各ジョブに適切な数のチケットを割り当てます。続いて優先ポリシーからのチケットが合算されます。

  2. 2 つのジョブが同じ機能カテゴリメンバーに属している場合、結果のチケット数は機能ポリシーのエンタイトルメントの割り当てに影響します。このエンタイトルメントの割り当てに基づいて、保留中のジョブに対する機能チケットが計算されます。

  3. 結果の値は、優先ポリシーのチケット量に加算されます。結果のチケット数が最高であるジョブは、最高のエンタイトルメントを獲得します。

3 つの文字は理論上どのように組み合わせることもできますが、意味がある、あるいは現実的に妥当なのは一部の組み合わせだけです。最後の文字は常に S または F にする必要があります。これは、上記の例で説明した特徴があるため、影響を受ける可能性があるポリシーは、この 2 つしかないためです。

policy_hierarchy の設定には次の形式を推奨します。


[O][S|F]

優先ポリシーが存在する場合、影響を与える可能性があるポリシーは優先ポリシーのみであるため、O は最初の文字としてのみ使用する必要があります。影響を受ける可能性があるポリシーは、共有ベースポリシーと機能ポリシーのみです。そのため、S または F を最後の文字として使用する必要があります。