test

Sun N1 Grid Engine 6.1 管理ガイド

第 5 章 ポリシーとスケジューラの管理

この章では、Grid Engine システムのポリシーを説明します。この章の内容は次のとおりです。

内容説明に加えて、この章では次のタスクの実行方法を詳細に解説します。

スケジューラの管理

この節では、Grid Engine システムが実行用にジョブをどのようにスケジューリングするかを説明します。また、さまざまな種類のスケジューリング戦略と、スケジューラを構成する方法についても説明します。

スケジューリングについて

Grid Engine システムでは、次のジョブスケジューリング処理が行われます。

Grid Engine ソフトウェアは、次の基準に基づいて、コンピュータの異機種システム混在クラスタでジョブをスケジューリングします。

スケジューリングに関する決定は、サイトの戦略と、クラスタ内の各コンピュータの瞬間的な負荷の特性に基づいて行われます。サイトのスケジューリング戦略は、Grid Engine システムの構成パラメータを介して表されます。負荷特性は、動作中のシステムのパフォーマンスデータを収集することによって確認されます。

スケジューリング戦略

管理者は、次のスケジューリング業務について戦略を立てることができます。

動的リソース管理

Grid Engine ソフトウェアは、次の 3 つのチケットに基づくポリシーの重み付けされた組み合わせを使用して、ジョブスケジューリング戦略の自動化を実現します。

Grid Engine システムを設定して、日常的に共有ベースポリシーと機能ポリシーのいずれか、またはその両方を使用するよう構成できます。これらのポリシーは、任意に組み合わせることができます。たとえば、1 つのポリシーにゼロの重みを与え、2 つ目のポリシーのみを使用することができます。また、両方のポリシーに同じ重みを与えることもできます。

日常的なポリシーとともに、管理者は共有ベースおよび機能スケジューリングを一時的に無効にしたり、エクスプレスキューなどの目的のために永続的に無効にすることができます。優先は、1 つのジョブに対して適用することも、ユーザー、部署、プロジェクト、ジョブクラス (すなわち、キュー) に関連付けられているすべてのジョブに適用することもできます。

Grid Engine システムには、すべてのジョブ間の調停をするためのこれら 3 つのポリシーのほかに、ユーザーが自分のジョブに優先順位を設定する機能もあります。たとえば、あるユーザーには、ジョブ 1 と 2 の重要性は同じであり、ジョブ 3 はジョブ 1 と 2 よりも重要である場合があります。ユーザーは、ポリシーの組み合わせに共有ベースポリシー、機能ポリシー、またはその両方が含まれる場合、独自のジョブの優先順位を設定することができます。また、ジョブには機能チケットを付与する必要があります。

チケット

共有ベース、機能、および優先スケジューリングポリシーは、チケットを使用することで実現されます。各ポリシーにはチケットのプールがあります。ジョブが複数のマシンから成る Grid Engine システムに入力された時点で、ポリシーはチケットをジョブに割り当てます。有効である日常的な各ポリシーは、一部のチケットを新しい各ジョブに割り当てます。ポリシーは、各スケジューリング間隔で、実行中のジョブにチケットを再割り当てする場合もあります。

チケットは、3 つのポリシーに重みを与えます。たとえば、機能ポリシーにチケットが割り当てられていない場合、そのポリシーは使用されません。機能チケットプールと共有ベースチケットプールに同じ数のチケットがある場合、ジョブの重要性を決定する際、両方のポリシーは等しい重みを持ちます。

チケットは、Grid Engine システム管理者によるシステム構成で、定期ポリシーに割り当てられます。管理者とオペレータは任意の時点でチケットの割り当てを変更でき、この変更はただちに効力を持ちます。優先を指示するには、システムに一時的に追加チケットを注入します。ポリシーはチケットの割り当てによって組み合わせられます。複数のポリシーにチケットが割り当てられている場合、ジョブは各ポリシーのチケットの一部を受け取ります。このことは、有効な各ポリシーにおけるジョブの重要性を示します。

Grid Engine システムは、システムに入るジョブにチケットを付与することによって、有効な各ポリシーにおけるその重要性を指示します。各スケジューリング間隔で、実行中の各ジョブはチケットを取得したり、チケットを失ったり、また同じ数のチケットを維持することができます。たとえば、ジョブは優先からチケットを取得する場合があります。ジョブは、正当なリソースの配分以上のチケットを取得しているため、チケットを失う場合があります。ジョブが保持するチケット数は、 Grid Engine システムが各スケジューリング間隔時にそのジョブに付与しようとするリソース配分を表します。

インストール時には、サイトの動的リソース管理戦略を構成します。まず、管理者は共有ベースポリシーと機能ポリシーにチケットを割り当てます。続いて、共有ツリーと機能配分を定義します。共有ベースチケットの割り当てと機能チケットの割り当ては、任意の時点で自動的に変更できます。管理者は、手動でチケットを割り当てたり、削除したりします。

キューのソート

Grid Engine システムがキューを埋める順番を決定するために、次の手段が用意されています。

ジョブのソート

Grid Engine システムがジョブの振り分けを開始する前、ジョブは優先順位の高い順に、優先順位に組み入れられます。続いてシステムは、優先順位の順番でジョブに適したリソースを見つけようとします。

管理者の操作がなければ、順序は先入れ先出し (FIFO) です。管理者には、ジョブの順序を制御する次の手段があります。

各優先順位の種類に対して、重み付け係数を指定できます。この重み付け係数は、各種類の優先順位がジョブ全般の優先順位に影響を与える程度を決定します。各優先順位の種類の値の範囲を制御しやすくするため、生のチケットの値、緊急度の値、および POSIX 優先順位の値の代わりに、正規化された値が使用されます。

ジョブの優先順位値がどのように決定されるかは、次の式で表されます。


job_priority = weight_urgency * normalized_urgency_value + 
weight_ticket * normalized_ticket_value + 
weight_priority * normalized_POSIX_priority_value

ジョブの優先順位の監視には qstat コマンドを使用できます。

緊急度ポリシーについて

緊急度ポリシーは各ジョブの緊急度の値を定義します。緊急度の値は、次の 3 つの情報の合計から得られます。

リソース要求の情報は、すべてのハードリソースの要求の合計から得られ、各要求に関する 1 つの加数になります。

リソース要求が型 numeric である場合、リソース要求の加数は、次の 3 つの要素の積になります。

リソース要求が型 string である場合、リソース要求の加数は、コンプレックスで定義されているリソースの緊急度の値になります。

待機時間の情報は、秒単位でのジョブの待機時間と、「Policy Configuration」ダイアログボックスで指定されている waiting-weight 値の積になります。

締め切りの情報は、締め切りのないジョブではゼロになります。締め切りのあるジョブの場合、締め切りの情報は、(締め切り開始時間までの) 秒単位の空き時間で除算された、「Policy Configuration」ダイアログボックスで定義されている waiting-weight 値です。

緊急度ポリシーの構成の詳細については、「緊急度ポリシーの構成」を参照してください。

リソース予約およびバックフィリング

リソース予約を使用すると、指定した保留中のジョブに、システムリソースを予約できます。ジョブに対してリソースを予約する場合、このようなリソースは優先順位の低いジョブには使用されません。

リソース要求、ジョブ優先順位、待機時間、リソース配分エンタイトルメントなどの基準に応じて、ジョブはリソースを予約できます。最も優先順位の高いジョブが一番早く使用可能なリソース割り当てを取得するよう、スケジューラは予約を強制します。これにより、「ジョブ枯渇」というよく知られた問題を回避できます。

リソース予約を使用すると、ジョブ優先順位の順序でリソースがジョブに振り分けられるようにすることができます。

次の例を考えます。ジョブ A はサイズの大きな保留中のジョブで、並列ジョブの可能性もあり、特定のリソースを大量に必要とします。比較的小さなジョブ B(i) のストリームは、同じリソースを必要としますが、比較的少量です。リソース予約がなければ、B(i) ジョブのストリームが停止しないという前提では、ジョブ A に対するリソース割り当てを保証できません。ジョブ A が B(i) ジョブよりも高い優先順位を持っている場合であっても、リソースを保証できません。

リソース予約により、ジョブ A は、低優先順位ジョブ B(i) をブロックする予約を取得します。可能なかぎり早い段階で、リソースはジョブ A に使用できるよう保証されます。

バックフィリングを使用すると、低優先順位ジョブは、リソース予約によりブロックされたリソースを使用できるようになります。バックフィリングが機能するのは、見込みの実行時間が十分短いため、元の予約に干渉することなくブロックされたリソースを使用できる、実行可能なジョブが存在する場合のみです。

上記の例では、期間が非常に短いジョブ C は、バックフィリングを使用してジョブ A の前に実行可能です。

リソース予約によりスケジューラはルックアヘッドを行うため、リソース予約を使用するとシステムのパフォーマンスに影響を与えます。小規模なクラスタでは、保留中のジョブがごく少数である場合、パフォーマンスへの影響は無視できる程度です。ただし、大規模なクラスタでは、多くの保留中のジョブがあるクラスタであれば、パフォーマンスへの影響は大きくなる場合があります。

発生しうるこのパフォーマンスの低下を相殺するために、スケジューリング間隔中に作成可能なリソース予約の総数を制限することができます。リソース予約は次の 2 つの方法で制限できます。

スケジューラを構成して、スケジューラがリソース予約によりどのような影響を受けるかを監視することができます。スケジューラを監視する場合は、各スケジューリング実行に関する情報はファイル sge-root/ cell/common/schedule に記録されます。

次の例に、スケジュール監視の実行内容を示します。グローバル license の消費可能リソースが 5 ライセンスに制限されているクラスタに、次のジョブのシーケンスが発行されると仮定します。


qsub -N L4_RR -R y -l h_rt=30,license=4 -p 100 $SGE_ROOT/examples/jobs/sleeper.sh 20
qsub -N L5_RR -R y -l h_rt-30,license=5        $SGE_ROOT/examples/jobs/sleeper.sh 20
qsub -N L1_RR -R y -l h_rt=31,license=1        $SGE_ROOT/examples/jobs/sleeper.sh 20

スケジューラ構成では、デフォルトの優先順位設定が使用されると仮定します。


weight_priority          1.000000
weight_urgency           0.100000
weight_ticket            0.010000

ジョブ L4_RR の –p 100 の優先順位は、ライセンスに基づく緊急度に取って代わるため、次の優先順位付けが行われます。


job-ID  prior    name
---------------------
   3127 1.08000 L4_RR
   3128 0.10500 L5_RR
   3129 0.00500 L1_RR

この場合、6 つのスケジュール間隔で、これらのジョブのトレースが schedule ファイルに見つかります。


::::::::
      3127:1:STARTING:1077903416:30:G:global:license:4.000000
      3127:1:STARTING:1077903416:30:Q:all.q@carc:slots:1.000000
      3128:1:RESERVING:1077903446:30:G:global:license:5.000000
      3128:1:RESERVING:1077903446:30:Q:all.q@bilbur:slots:1.000000
      3129:1:RESERVING:1077903476:31:G:global:license:1.000000
      3129:1:RESERVING:1077903476:31:Q:all.q@es-ergb01-01:slots:1.000000
      ::::::::
      3127:1:RUNNING:1077903416:30:G:global:license:4.000000
      3127:1:RUNNING:1077903416:30:Q:all.q@carc:slots:1.000000
      3128:1:RESERVING:1077903446:30:G:global:license:5.000000
      3128:1:RESERVING:1077903446:30:Q:all.q@es-ergb01-01:slots:1.000000
      3129:1:RESERVING:1077903476:31:G:global:license:1.000000
      3129:1:RESERVING:1077903476:31:Q:all.q@es-ergb01-01:slots:1.000000
      ::::::::
      3128:1:STARTING:1077903448:30:G:global:license:5.000000
      3128:1:STARTING:1077903448:30:Q:all.q@carc:slots:1.000000
      3129:1:RESERVING:1077903478:31:G:global:license:1.000000
      3129:1:RESERVING:1077903478:31:Q:all.q@bilbur:slots:1.000000
      ::::::::
      3128:1:RUNNING:1077903448:30:G:global:license:5.000000
      3128:1:RUNNING:1077903448:30:Q:all.q@carc:slots:1.000000
      3129:1:RESERVING:1077903478:31:G:global:license:1.000000
      3129:1:RESERVING:1077903478:31:Q:all.q@es-ergb01-01:slots:1.000000
      ::::::::
      3129:1:STARTING:1077903480:31:G:global:license:1.000000
      3129:1:STARTING:1077903480:31:Q:all.q@carc:slots:1.000000
      ::::::::
      3129:1:RUNNING:1077903480:31:G:global:license:1.000000
      3129:1:RUNNING:1077903480:31:Q:all.q@carc:slots:1.000000

スケジュール間隔に関して、各セクションでは、考慮されたすべてのリソース利用量が示されます。RUNNING エントリは、間隔の開始時点ですでに実行中であったジョブの利用量を示しています。STARTING エントリは、間隔内で決定された即時の利用量を示しています。RESERVING エントリは、将来計画されている使用、つまり予約を示しています。

スケジュールファイルの書式は次のとおりです。

jobID

ジョブ ID

taskID

配列タスク ID (通常のジョブの場合は 1)

状態

RUNNING、SUSPENDED、 MIGRATING、STARTING、RESERVING を取ります

開始時刻

1.1.1070 以降の秒単位での開始時刻

継続時間

想定されている秒単位でのジョブの継続時間

レベル文字

P (並列環境の場合)、G (グローバルの場合)、H (ホストの場合)、または Q (キューの場合) を取ります

オブジェクト名

並列環境、ホスト、またはキューの名前

リソース名

消費可能リソースの名前

使用率

そのジョブにより発生するリソース使用率

行 :::::::: は、新しいスケジュール間隔の開始のマークとなります。

注 –

schedule ファイルは、切り捨てられません。ファイルを切り捨てるように設定されている自動手続きがない場合は、必ず監視をオフにしてください。

スケジューラ間隔で行われる動作

スケジューラは、間隔での作業をスケジューリングします。スケジューリングアクションの間、Grid Engine システムは次の要素などの、重要なイベントに関する情報を保持します。

スケジューリングが行われる際には、スケジューラはまず次の処理を実行します。

必要に応じて、Grid Engine システムは次のタスクを実行します。

共有ベーススケジューリングが使用されている場合、そのユーザーまたはプロジェクトに対してすでに発生している利用量が、計算では考慮されます。

少なくとも一部でもスケジューリングが共有ベーススケジューリングでない場合は、計算では実行中および実行待ちのすべてのジョブがランク付けされます。クラスタ内のリソース (CPU、メモリー、および I/O 帯域幅) が可能なかぎり使用されるようになるまで、計算では最も重要なジョブが処理されます。

スケジューラの監視

ジョブが開始しない理由が不明である場合、そのジョブに対して qalter -w v コマンドを発行します。Grid Engine ソフトウェアでは、クラスタが空であることが仮定されていて、またジョブに適したキューが使用可能であるかどうかチェックされます。

詳細な情報は、qstat -j job-id コマンドを実行することで取得できます。このコマンドは、ジョブの要求プロファイルの要約を出力します。要約には、前回のスケジューリング実行でジョブがスケジューリングされなかった理由も含まれます。ジョブ ID を使用せずに qstat -j コマンドを実行すると、前回のスケジューリング間隔でスケジューリングされなかったすべてのジョブに関する理由が要約されます。

注 –

スケジューラ構成 sched_conf(5) では、ジョブスケジューリング情報の収集をオンにする必要があります。sched_conf(5) のマニュアルページの schedd_job_info パラメータの説明、または 「QMON を使用したスケジューラ構成の変更」を参照してください。

スケジューラ sge_schedd の決定に関する詳細な情報を取得するには、qconf コマンドの -tsm オプションを使用します。このコマンドを使用すると、sge_schedd は強制的にファイルにトレース出力を書き込みます。

スケジューラの構成

Grid Engine システムのリソース共有ポリシーのスケジューリング管理の詳細については、「QMON を使用したポリシーに基づくリソース管理の構成」を参照してください。次の節では、スケジューラ構成 sched_conf の管理とそれに関連する問題に焦点を当てます。

デフォルトのスケジューリング

デフォルトのスケジューリングは、FIFO 方式です。すなわち、最初に発行されたジョブが、最初にスケジューラによって調べられ、キューに振り分けられます。保留中のジョブのリストの最初のジョブが、適切で使用可能なジョブを見つけると、そのジョブがまず開始されます。最初のジョブよりも下位のランクのジョブが開始できるのは、最初のジョブが適切な空きリソースを見つけられなかった場合のみです。

デフォルト戦略では、ジョブのリソース要求に対してキューが適切なサービスを提供するかぎり、最も負荷の低いホスト上のキューインスタンスを選択します。複数の適切なキューが同じ負荷を共有する場合、どのキューが選択されるか予測できません。

そのほかのスケジューリング方法

次のようなさまざまな方法で、ジョブのスケジューリングとキュー選択の戦略を変更できます。

次では、これらの代替方法を詳しく説明します。

スケジューリングアルゴリズムの変更

スケジューラ構成パラメータ algorithm は、使用するスケジューリングアルゴリズムを選択できるようにします。詳細については、sched_conf(5) のマニュアルページを参照してください。ただし、現在指定できる設定は default だけです。

システム負荷のスケーリング

ジョブを実行するキューを選択するため、Grid Engine システムは、キューインスタンスをホスティングするマシンのシステム負荷情報を使用します。このキュー選択方式によって負荷分散状態が確立され、クラスタ内の使用可能なリソースの有効利用が保証されます。

ただし、システム負荷が常に真実を伝えるとはかぎりません。たとえば複数 CPU のマシンとシングル CPU のシステムを比較すると、通常、多くの場合マルチプロセッサシステムの方が実行しているプロセス数が多いため、マルチプロセッサシステムが報告する負荷値の方が大きくなります。システム負荷は、CPU へのアクセス権を取得しようとするプロセス数に大きく左右される測定値です。しかし、複数 CPU システムは、シングル CPU マシンに比べてはるかに大きな負荷に対処することができます。この問題は、sge_execd からデフォルトで報告される負荷値をプロセッサ数で調整することによって対処します。すなわち、生の負荷値ではなく、負荷パラメータを使用することによって、上記の問題に対処することができます。詳細については、「負荷パラメータ」 および sge-root/doc/load_parameters.asc ファイルを参照してください。

負荷値が正しく判断されない可能性があるもう 1 つの例として、システムで潜在的なパフォーマンスあるいは価格パフォーマンス比に著しい差がある場合があります。どちらの場合も、負荷値が同じであるからといって、ジョブの実行用にどちらのホストを選択してもよいわけではありません。こうした場合、管理者は、実行ホストと負荷パラメータに対する負荷スケーリング係数を定義する必要があります。「QMON を使用した実行ホストの構成」および関連の節を参照してください。

注 –

スケーリングした負荷パラメータは、負荷しきい値リストの load-thresholds および migr-load-thresholds とも照合されます。詳細については、queue_conf(5) のマニュアルページを参照してください。

負荷パラメータに関連するもう 1 つの問題は、値とその相対的な重要性を、アプリケーションおよびサイトに依存して解釈する必要があることです。特定のサイトで一般的なある種のアプリケーションでは CPU 負荷が圧倒的であるのに対し、別のサイトや、サイトの計算クラスタが専門に扱うアプリケーションプロファイルでは、メモリー負荷がずっと重要であることがあります。この問題に対処するため、Grid Engine システムでは、管理者はスケジューラ構成ファイル sched_conf で負荷の式を指定できます。詳細については、sched_conf(5) のマニュアルページを参照してください。負荷の式でサイト定義の負荷パラメータと消費可能リソースを使用することによって、リソース使用率と容量計画に関するサイト固有の情報を考慮することができます。「サイト固有の負荷パラメータの追加」および 「消費可能リソース」の各節を参照してください。

最後に、負荷パラメータの時間依存も考慮する必要があります。システムで実行中のジョブによって課される負荷は時間とともに変化します。しばしば、CPU 負荷などの負荷は、オペレーティングシステムが適切な報告するのにかなりの時間が必要になることがあります。ジョブの開始直後の場合、報告される負荷は、ジョブによってホストに課されている負荷を正確に表していないことがあります。報告される負荷は時間とともに実際の負荷に近づいていきます。しかし、報告される負荷が低すぎる間は、そのホストが過剰な予約を受ける可能性があります。Grid Engine システムでは、管理者は、スケジューラでこの問題の補正に使用される負荷調整係数を指定することができます。このような負荷調整係数の設定方法の詳細については、sched_conf(5) のマニュアルページを参照してください。

負荷調整は、ジョブが振り分けられたあとに、測定される負荷を仮想的に増加させるために使用します。過剰な予約が発生したマシンの場合、これは負荷しきい値との調整に役立ちます。負荷調整が必要でない場合は、負荷調整をオフにする必要があります。負荷調整は、ホストのソートと負荷しきい値の検証を伴って、スケジューラに追加の作業を課すことになります。

負荷調整を使用不可にするには、「Scheduler Configuration」ダイアログボックスの「Load Adjustment」でタブで「Decay Time」をゼロに設定し、テーブル内のすべての負荷調整の値を削除します。「QMON を使用したスケジューラ構成の変更」を参照してください。

連続番号によるキューの選択

デフォルトのキュー選択方法を変更するもう 1 つの方法は、グローバルクラスタ構成パラメータqueue_sort_method をデフォルトの load から seq_no に変更する方法です。この設定にすると、キュー選択の第一の手段としてシステム負荷が使用されなくなります。その代わりに、キュー構成パラメータ seq_no によりキューに割り当てられた連続番号が、キュー選択の固定順序を定義します。キューは、検討対象のジョブに適切で、使用可能である必要があります。詳細については、queue_conf(5) および sched_conf (5) のマニュアルページを参照してください。

このキュー選択方法は、サイトでバッチサービスを提供するマシンが、ジョブ 1 つあたりの単純な価格の順序でランク付けされている場合に役立ちます。たとえば、マシン A であるジョブを実行すると 1 単位のコストがかかるとします。同じジョブは、マシン B では 10 単位、マシン C では 100 単位のコストがかかります。この場合の望ましいスケジューリング方法は、最初にホスト A を一杯にして、次にホスト B、そして代わりが残っていない場合だけホスト C を使用するという方法です。

注 –

キュー選択方法を seq_no に変更して、検討対象のすべてのキューの連続番号が同じ場合、キューはデフォルトの load により選択されます。

配分量によるキューの選択

この方法の目標は、すべてのジョブに対して目標とするグロバールシステムリソース配分が達成されるようにジョブを配置することにあります。この方法では、すべてのシステムリソースとの関係で各ホストが表すリソース容量を考慮します。またこの方法では、各ホストのチケットの割合 (すなわち、ホストで実行中のすべてのジョブの総チケット数) と、特定のホストがシステムに対して表すリソース能力の割合のバランスを取ろうとします。ホストの容量の定義方法については、「QMON を使用した実行ホストの構成」を参照してください。

重要性は二次的なものとなりますが、ソートではホストの負荷も考慮されます。共有ツリーポリシーを使用しているサイトでは、このソート方法を選択してください。

ユーザー 1 人またはグループ 1 つあたりのジョブ数の制限

管理者は、ユーザーまたは UNIX グループが任意の時点で実行できるジョブ数に上限を割り当てることができます。この機能を使用するには、次のいずれかを実行します。

QMON を使用したスケジューラ構成の変更

「QMON Main Control」ウィンドウで、「Scheduler Configuration」ボタンをクリックします。

「Scheduler Configuration」ダイアログボックスが表示されます。このダイアログには、2 つのタブがあります。

一般的なスケジューリングパラメータを変更するには、「General Parameters」タブをクリックします。「General Parameters」タブは次の図のようになっています。

「General Parameters」タブを使用して、次のパラメータを設定します。

デフォルトでは、Grid Engine システムは、固定スケジュール間隔でジョブ実行をスケジューリングします。「Flush Submit Seconds」および「Flush Finish Seconds」パラメータを使用すると、ただちにスケジュールを行うよう構成できます。詳細については、「直接スケジューリング」を参照してください。

負荷調整パラメータを変更するには、「Load Adjustment」タブをクリックします。「Load Adjustment」タブは次の図のようになっています。

「Load Adjustment」タブを使用して、次のパラメータを設定します。

内容説明については、「システム負荷のスケーリング」を参照してください。スケジューラ構成の詳細については、sched_conf(5) のマニュアルページを参照してください。

ポリシーの管理

この節では、ポリシーを構成してクラスタリソースを管理する方法について説明します。

Grid Engine ソフトウェアは、管理者が管理する社内リソースポリシーに基づいて計算パワーの供給を調整します。システムでは、これらのポリシーを使用してグリッド内で使用可能なコンピュータリソースを調べます。システムは、グリッド全体でリソース使用率が最適化されるように、これらのリソースを収集し、リソースを自動的に割り当てて供給します。

グリッド内での協調を実現するため、プロジェクトの所有者は次の作業を実行する必要があります。

管理者は、サイト用にカスタマイズされたハイレベルな使用ポリシーを定義できます。次のような 4 つのポリシーが使用可能です。

目標を達成するため、ポリシー管理はクラスタ内の共有リソースの使用を自動的に制御します。優先順位の高いジョブは優先的に振り分けられます。このようなジョブは、そのほかの低優先順位のジョブと競合した場合、より多くの CPU エンタイトルメントを受け取ります。Grid Engine ソフトウェアはすべてのジョブの進行状況を監視します。その状況に応じて、またポリシーに定義されている目標に従ってその相対的な優先順位を調整します。

このポリシーに基づくリソース割り当ては、各ユーザー、チーム、部署およびすべてのプロジェクトに、システムリソースの割り当て済みの配分を付与します。このリソースの割り当ては、1 週間、1 か月、または 1 四半期などの指定した期間で行われます。

QMON を使用したポリシーに基づくリソース管理の構成

「QMON Main Control」ウィンドウで、「Policy Configuration」ボタンをクリックします。「Policy Configuration」ダイアログボックスが表示されます。

図 5–1 「Policy Configuration」ダイアログボックス

「Policy Configuration」ダイアログボックスには次の情報が表示されます。

このダイアログボックスから、3 つのチケットに基づくポリシー用の特定の構成ダイアログボックスにアクセスできます。

ポリシーの優先順位の指定

Grid Engine システムがジョブを振り分ける前に、ジョブは優先順位の高い順に、優先順位に組み込まれます。管理者の介入がなければ、この順番は FIFO (先入れ先出し) 方式です。

「Policy Configuration」ダイアログボックスでは、「Policy Importance Factor」で、ジョブのソート順を制御する、3 つの優先順位の種類の相対的な重要性を指定できます。

ジョブの優先順位の詳細については、「ジョブのソート」を参照してください。

各優先順位の種類に対しては、重み付け係数を指定できます。この重み付け係数は、各種類の優先順位がジョブ全般の優先順位に影響を与える程度を決定します。各優先順位の種類の値の範囲を制御しやすくするため、生のチケットの値、緊急度の値、および POSIX 優先順位の値の代わりに、正規化された値が使用されます。

ジョブの優先順位値がどのように決定されるかは、次の式で表されます。


ジョブ優先順位 = 緊急度 * 正規化された緊急度の値 + 
チケット * 正規化されたチケットの値 + 
優先順位 * 正規化された優先順位の値

「Priority」、「Ticket 」、および「Priority」は、「Policy Importance Factor」でユーザーが指定する 3 つの重み付け係数です。たとえば、「Priority」に 1、「Urgency」に 0.1、および「Ticket 」に 0.01 を指定した場合、qsub –p コマンドにより指定されるジョブの優先順位には最大の重みが与えられ、「Urgency Policy」により指定されるジョブの優先順位は次に考慮され、「Ticket Policy」により指定されるジョブの優先順位はもっとも低い重みが与えられます。

緊急度ポリシーの構成

「Urgency Policy」では各ジョブの緊急度の値を定義します。緊急度の値は、次の 3 つの関係要素の合計によって決定されます。

Grid Engine システムが緊急度の値の合計をどのように算出するかの詳細については、「緊急度ポリシーについて」を参照してください。

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

個別のポリシーに現在割り当てられているチケットは、「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 を最後の文字として使用する必要があります。

共有ベースポリシーの構成

共有ベーススケジューリングは、週、月、四半期などの累積期間中に、各ユーザーおよびプロジェクトに、システムリソースの割り当て済み配分を付与します。共有ベーススケジューリングは、共有ツリースケジューリングとも呼ばれます。このスケジューリングでは常に、次のスケジューリング間隔までの短い時間の間に、各ユーザーおよびプロジェクトに予定されているリソース配分が調整されます。共有ベーススケジューリングは、ユーザーやプロジェクト、またはその両方に対して定義します。

共有ベーススケジューリングにより、時間の経過とともに、共有ツリーで構成されているインスタンスに対し、定義済みの配分が保証されるようになります。システムがジョブを振り分ける場合には、過去のリソース消費量が予想より少なかった共有ツリーのブランチに関連付けられているジョブが優先されます。同時に、そのほかの共有ツリーのブランチに関連付けられている保留中のジョブに、未使用の配分比率が依然として使用可能であるため、完全なリソース使用率が保証されます。

各ユーザーまたはプロジェクトにできるかぎり目標に近い配分を付与することによって、ユーザーまたはプロジェクトのグループも目標の配分を得られるようになります。部署や部門は、そのようなグループの例です。累積期間中にリソースエンタイトルメントを持つすべてのエンティティーがリソースを得ようとした場合にのみ、すべてのエンティティーに対する公平な配分を達成できます。ユーザー、プロジェクト、またはグループが特定の期間中にジョブを発行しなかった場合、リソースはジョブの発行者の間で分配されます。

共有ベーススケジューリングはフィードバック方式です。任意のユーザー/ユーザーグループ、またはプロジェクト/プロジェクトグループにエンタイトルメントが与えられている対象のシステムの配分は、構成パラメータです。ジョブにエンタイトルメントが与えられている対象のシステムの配分は、次の要素に基づいて決定されます。

Grid Engine ソフトウェアは、ユーザーおよびプロジェクトがすでに受け取った使用率を追跡します。スケジューリング間隔のたびに、スケジューラはすべてのジョブのリソース配分を調整します。このようにして、すべてのユーザー、ユーザーグループ、プロジェクト、プロジェクトグループが、累積期間の間にできるかぎりシステムの公平な配分を受けられるようにします。言い替えれば、リソース使用率を許可したり、拒否したりすることによって、誰もがほぼ目標に近い配分を受けられるようにします。

半減期係数

半減期とは、システムがユーザーのリソース消費を「忘れる」速さです。システム管理者は、それが 6 か月前であれ 6 日前であれ、ユーザーの大きなリソース消費にペナルティーを科すかどうかを決定できます。また管理者は、どのようにしてペナルティーを科すかも決定できます。Grid Engine ソフトウェアは、共有ツリーのすべてのノードについてユーザーのリソース消費記録を維持します。

共有ベースポリシーを設定する際、システム管理者はこの記録に基づいて、ユーザーの過少利用または過大利用を判断する際、どのくらい過去にさかのぼるかを決定できます。この意味でのリソース利用量は、「スライドする時間枠」で消費されたすべてのコンピュータリソースの数学的な合計です。

この時間枠の長さは「半減期」係数で決まり、Grid Engine システムではそれは 内部減少関数です。この減少関数は、経時的に発生するリソース消費の影響を小さくします。半減期が短いほど、リソースの過大消費の影響は短期間に小さくなり、半減期が長いほど、リソースの過大消費の影響は徐々に小さくなります。

この半減期減少関数は指定された時間単位に基づきます。たとえば、1,000 単位のリソース消費に 7 日の半減期を適用した場合を考えます。この半減期減少係数を使用した場合、経時で次の使用「ペナルティー」による調整が行われます。

半減期に基づく減少は、ペナルティーの効果が無視できるまで、経時のユーザーのリソース消費の影響を小さくします。

注 –

優先チケットは別のポリシーシステムに属するため、ユーザーが受け取る優先チケットは、過去の使用ペナルティーの影響を受けません。減少関数は、共有ツリーポリシーのみの特性です。

補正係数

比較では、場合によって、実際の利用量が目標使用率を大きく下回っていることが明らかになることがあります。このような場合は、ユーザーのリソースの配分またはプロジェクトのリソースの配分を調整することで、ユーザーがシステムを優先使用できます。このような調整は、目標の配分に到達するという目的に基づいています。ただし、この優先使用は望ましくない場合があります。

補正係数を使用すると、管理者は、ユーザーまたはプロジェクトが短期にリソースを優先使用できる度合いを制限できます。

たとえば補正係数 2 は、ユーザーまたはプロジェクトの現在の配分を目標配分の 2 倍に制限します。ユーザーまたはプロジェクトが、累積期間中にシステムリソースの 20% を受けられるようになっていると仮定すると、ユーザーまたはプロジェクトが現在受けている量がそれより非常に低い場合、短期に受け取れる最大量は、40% だけになります。

共有ベースポリシーは、共有ツリーに従ってユーザーまたはプロジェクトの長期のリソースエンタイトルメントを定義します。共有ベースポリシーと補正係数を組み合わせることによって、エンタイトルメントの自動的な調整が行われます。

ユーザーまたはプロジェクトが、定義された目標のエンタイトルメントを下回っているか上回っている場合、Grid Engine システムは補正を行います。システムは、ユーザーまたはプロジェクトの短期のエンタイトルメントを長期目標よりも上げるか、下げることによって補正をします。この補正は、共有ツリーアルゴリズムにより計算されます。

補正係数は、Grid Engine システムが割り当てる補正量を制御するもう 1 つの仕組みを提供します。この追加の補正係数 (CF) 計算は、次の条件が真である場合にのみ行われます。

上記の条件の一方または両方が真ではない場合は、共有ツリーアルゴリズムによって定義および実装されている補正が適用されます。

CF 値が小さいほど、その効果は大きくなります。値が 1 より大きい場合、Grid Engine システムの補正は限られた効果しかありません。補正の上限は、長期エンタイトルメントと CF の積で計算されます。上記で定義されているように、補正係数に基づく操作が行われるには、短期エンタイトルメントがこの上限を超えている必要があります。

CF が 1 の場合、Grid Engine システムはそのままの共有ツリーアルゴリズムと同じ方法で補正をします。このため、値 1 は値 0 と似た効果になります。唯一の違いは、実装の詳細です。CF = 1 の場合は、CF 計算が行われますが、影響はありません。CF = 0 の場合は、CF 計算が抑止されます。

値が 1 より小さい場合、Grid Engine システムは過剰補正を行います。ジョブは、共有ツリーアルゴリズムに基づいて得られるよりも大幅に多くの補正量を受けます。また、補正の実施条件が低い短期エンタイトルメント値で満たされるため、ジョブは早期にこの過剰補正を受けることになります。実施条件は「短期エンタイトルメント > 長期エンタイトルメント * CF」です。

階層形式の共有ツリー

共有ベースポリシーは、共有ツリーを使用して実現されます。共有ツリーは、移動累積期間中にすべてのユーザーおよびプロジェクトの間でどのようにシステムリソースを配分するかを規定します。累積期間の長さは、構成可能な減少定数で決まります。Grid Engine システムは、共有ツリー内の各親ノードのその累積上限への到達度に基づいて、ジョブの共有エンタイトルメントを決定します。ジョブの共有エンタイトルメントは、そのリーフノードの配分割り当てに基づいて決まり、リーフノードの配分割り当てはその親ノードの割り当てに依存します。リーフノードに関連付けられているすべてのジョブ間で、関連付けられている配分が分配されます。

ジョブの最終的なエンタイトルメントは、共有ツリーから得られるエンタイトルメントと、機能ポリシーなどから得られるほかのエンタイトルメントを組み合わせることによって決定されます。共有ツリーには、共有ベーススケジューリングに対するチケットの合計数が割り当てられます。この数によって、4 通りあるスケジューリングポリシーにおける共有ベーススケジューリングの重みが決まります。

共有ツリーは、インストール中に定義し、いつでも変更することができます。共有ツリーを編集すると、次のスケジューリング間隔で新しい共有割り当てが有効になります。

QMON を使用した共有ツリーポリシーの構成

「QMON Policy Configuration」ダイアログボックス (図 5–1) で「Share Tree Policy」をクリックします。「Share Tree Policy」ダイアログボックスが表示されます。

「Node Attributes」

「Node Attributes」の下には、選択したノードの属性が表示されます。

ユーザーノードまたはプロジェクトノードを削除して、追加して戻しても、そのユーザーまたはプロジェクトの使用率は残ります。ノードは、共有ツリー内の同じ場所または別の場所に追加して戻すことができます。ノードを共有ツリーに追加して戻す前に、その使用率をゼロにすることができます。このためには、まず Grid Engine システムで構成したユーザーまたはプロジェクトからノードを削除します。続いて、その場所のユーザーまたはプロジェクトにノードを追加して戻します。

共有ツリーに存在しなかったにもかかわらず、ジョブを実行したユーザーまたはプロジェクトを、共有ツリーに追加すると、その使用率はゼロ以外の値になります。そのようなユーザーまたはプロジェクトをツリーに追加する際に、使用率をゼロにするには、Grid Engine システムで構成したユーザーまたはプロジェクトからそのユーザーまたはプロジェクトを削除します。続いて、そのユーザーまたはプロジェクトをツリーに追加します。

選択したノードの下に内部ノードを追加するには、「Add Node」をクリックします。空の「Node Info」ウィンドウが表示され、このウィンドウにノードの名前と配分の数を入力できます。任意のノード名または配分の数を入力できます。

選択したノードの下にリーフノードを追加するには、「Add Leaf」をクリックします。空の「Node Info」ウィンドウが表示され、このウィンドウにノードの名前と配分の数を入力できます。ノードの名前は、既存の Grid Engine ユーザー (「QMON を使用したユーザーオブジェクトの構成」) またはプロジェクト (「プロジェクトの定義」) でなければなりません。

リーフノードを追加する際には、次の規則が適用されます。

選択したノードを編集するには、「Modify」をクリックします。「Node Info」ウィンドウが表示されます。ウィンドウにはモードの名前と、配分の数が表示されます。

選択したノードのカットまたはバッファーへのコピーを行うには、「Cut」または「Copy」をクリックします。直前にカットまたはコピーしたノードの内容を、選択したノードの下にペーストするには、「Paste」をクリックします。

選択したノードとそのすべての子孫を削除するには、「Delete」をクリックします。

共有ツリー階層全体をクリアするには、「Clear Usage」をクリックします。共有ベースポリシーを予算に合わせて、各予算編成時期に最初からやり直す必要がある場合に、階層をクリアします。「Clear Usage」機能は、N1 Grid Engine 6.1 ソフトウェアのテスト環境を設定したり、変更したりする際にも便利です。

QMON は、「Share Tree Policy」ダイアログボックスに表示される情報を定期的に更新します。ただちに表示を更新させるには、「Refresh」をクリックします。

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

共有ツリーでノード名を検索するには「Find」をクリックしてから検索文字列を入力します。検索文字列は大文字と小文字が区別され、その文字列から始まるノード名が表示されます。次に一致する検索文字列を検索するには、「Find Next」をクリックします。

オンラインヘルプシステムを開くには、「Help」をクリックします。

共有ツリーポリシーのパラメータ

「Share Tree Policy Parameters」を表示するには、「Node Attributes」の右側にある矢印をクリックします。

特殊ユーザー default について

多数のユーザーがいるサイトでは、特殊なユーザー default を使用して、共有ツリーを保守する作業量を減らすことができます。共有ツリーポリシーにおいては、ジョブの優先順位は、ジョブが共有ツリー内で対応するノードに基づいて決定されます。共有ツリー内で明示的に名前が付けられていないユーザーは、(存在する場合) default ノードに割り当てられます。

1 つの default ノードを指定することで、シンプルな共有ツリーの作成が可能になります。このような共有ツリーにより、ユーザーに基づく公正な分配が可能になります。

また、大部分のユーザーに同じ共有エンタイトルメントが割り当てられている場合でも、default ユーザーを使用できます。同じ共有エンタイトルメントは、均等配分スケジューリングとも呼ばれます。

default ユーザーは、default ノードの下ですべてのユーザーエントリを構成し、各ユーザーに同じ配分量を与えます。ジョブを発行する各ユーザーは、default ユーザーに対して構成されているのと同じ共有エンタイトルメントを受け取ります。特定のユーザーに対してこの機能を有効にするには、Grid Engine ユーザーのリストにこのユーザーを追加する必要があります。

共有ツリーでは、default ノードに割り当てられているすべてのユーザーに関して、「仮想」ノードが表示されます。仮想ノードを表示することで、default ノードに割り当てられているユーザーに関して、使用率と、公正な配分スケジューリングのパラメータを調べることができます。

また、「ハイブリッド」の共有ツリーに対して default ユーザーを使用することもできます。このツリーでは、ユーザーは共有ツリー内のプロジェクトの従属下に置かれます。default ユーザーは、プロジェクトノードのリーフノードになることができます。

ユーザーの短期エンタイトルメントは、ユーザーが消費するリソース量の違いにより異なります。ただし、ユーザーの長期エンタイトルメントは同じままになります。

一部のユーザーにだけ低い、または高いエンタイトルメントを割り当てて、ほかのすべてのユーザーには同じ長期エンタイトルメントを維持したい場合があります。このためには、特別なエンタイトルメントを持つのユーザー用の default ユーザーの隣に、個別のユーザーエントリを含む共有ツリーを構成します。

例 A では、プロジェクト A に発行するすべてのユーザーが同じ長期エンタイトルメントを得ます。プロジェクト B に発行するユーザーは、プロジェクト B の累積リソース消費量に関係します。プロジェクト B のユーザーのエンタイトルメントは管理されません。

例 5–2 例 A

例 A と例 B を比較してください。

例 5–3 例 B

例 B では、プロジェクト A に対する扱いは、例 A のときと同じです。しかし、ユーザー A および B を除き、プロジェクト B にジョブを発行するすべてのデフォルトユーザーは、同等の長期のリソースエンタイトルメントを得ます。デフォルトのユーザーは 20 の配分を持ちます。ユーザー A の配分は 10 で、受けるエンタイトルメントはデフォルトユーザーの半分です。ユーザー B の配分は 40 で、受けるエンタイトルメントはデフォルトユーザーの 2 倍です。

コマンド行からの共有ベースポリシーの構成

注 –

階層ツリーはグラフィカルな表示と編集に適しているため、QMON を使用して共有ツリーポリシーを構成します。ただし、共有ツリーの変更をシェルスクリプトで統合する必要がある場合は、qconf コマンドとそのオプションなどを使用できます。

コマンド行から共有ポリシーを構成するには、適切なオプションを使用して qconf コマンドを使用します。

Procedureプロジェクトに基づく共有ツリースケジューリングの作成方法

この設定の目的は、経時でのすべてのクラスタリソースの配分割り当てを、異なるプロジェクトに保証することです。

  1. スケジューラ構成で、共有ツリーチケットの数 (1000000 など) を指定します。

    「QMON を使用したポリシーに基づくリソース管理の構成」、および sched_conf(5) のマニュアルページを参照してください。

  2. (オプション) スケジューリング関連のユーザーごとに、1 人のユーザーを追加します。

    「QMON を使用したユーザーオブジェクトの構成」、 および user(5) のマニュアルページを参照してください。

  3. スケジューリング関連のプロジェクトごとに、1 つのプロジェクトを追加します。

    「QMON を使用したプロジェクトの定義」、および project (5) のマニュアルページを参照してください。

  4. QMON を使用して、すべてのスケジューリング関連のプロジェクトの構造をノードとして反映する、共有ツリーを設定します。

    「QMON を使用した共有ツリーポリシーの構成」を参照してください。

  5. プロジェクトに共有ツリーの配分を割り当てます。

    たとえば、同じプロジェクトのジョブ間で優先順のスケジューリングを行う、プロジェクトに基づく共有ツリースケジューリングを作成する場合、次のようなシンプルな構造になります。

    各ユーザーに等しい配分を設定する、プロジェクトに基づく共有ツリースケジューリングを作成する場合、次のようなシンプルな構造になります。

    各プロジェクト内に個別のユーザー配分がある、プロジェクトに基づく共有ツリースケジューリングを作成する場合、プロジェクトに対するリーフとしてユーザーを追加します。続いて個別の配分を割り当てます。次のようなシンプルな構造になります。

    個別の配分をごく少数のユーザーにのみ割り当てる場合、プロジェクトノードの下に、個別ユーザーと組み合わせて、ユーザー default を指定します。たとえば、上図のツリーを次のように要約することができます。

機能ポリシーの構成

機能スケジューリングは、ジョブの重要性を決定するための、非フィードバック方法です。機能スケジューリングは、ジョブと、発行を行うユーザー、プロジェクト、部署、およびジョブクラスを関連付けます。機能スケジューリングは、プライオリティスケジューリングと呼ばれることもあります。機能ポリシーの設定により、定義済みの配分が常に各ユーザー、プロジェクト、または部署に保証されます。予定よりも少ないリソースを使用したユーザー、プロジェクト、または部署のジョブが優先されるのは、システムがアイドル状態のリソースに対してジョブを振り分けた場合のみです。

同時に、未使用の配分の比率は、リソースを必要とするユーザー、プロジェクト、および部署で分配されるため、完全なリソースの使用が保証されます。過去のリソース消費は考慮されません。

ジョブの実際のエンタイトルメントを決定する際に、システムリソースに対する機能ポリシーのエンタイトルメントは、そのほかのエンタイトルメントと結び付けられます。たとえば、機能ポリシーのエンタイトルメントは、共有ベースポリシーのエンタイトルメントと結び付けられる場合があります。

機能ポリシーに割り当てられたチケットの合計数は、3 つのスケジューリングポリシーの間での機能スケジューリングの重みを決定します。インストール時に、管理者は機能チケットの合計数を、ユーザー、部署、プロジェクト、ジョブ、およびジョブクラスの機能カテゴリに分割します。

機能共有

機能共有は、各機能カテゴリ (ユーザー、部署、プロジェクト、ジョブ、ジョブクラス) のあらゆるメンバーに割り当てられます。それらの配分は、カテゴリのメンバーに関連付けられている各ジョブが受ける資格を持つ、そのカテゴリ用のチケット全体に占める割合を示します。たとえば、ユーザー davidson が 200、ユーザー donlee が 100 の配分の場合、存在するチケット数に関係なく、davidson が発行するジョブは donlee のジョブよりも 2 倍多くの user-functional-tickets を得ることができます。

各カテゴリに割り当てられた機能チケットは、特定のカテゴリに関連付けられているすべてのジョブ間で分配されます。

QMON を使用した機能共有ポリシーの構成

「QMON Policy Configuration」ダイアログボックスの下部にある「Functional Policy」をクリックします。「Functional Policy」ダイアログボックスが表示されます。

Function Category List

機能共有を定義する対象の機能カテゴリ (ユーザー、プロジェクト、部署、またはジョブ) を選択します。

「Functional Shares」テーブル

「Functional Shares」の下にあるテーブルはスクロール可能です。テーブルには次の情報が表示されます。

QMON は、「Functional Policy」ダイアログボックスに表示される情報を定期的に更新します。ただちに表示を更新させるには、「Refresh」をクリックします。

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

機能構成の変更

「Functional Shares」テーブルの上にある曲がった矢印をクリックして、構成ダイアログボックスを開きます。

「Ratio Between Sorts Of Functional Tickets」

「Ratio Between Sorts Of Functional Tickets」を表示するには、「Functional Shares」テーブルの右側にある矢印をクリックします。

「User [%]」、「Department [%]」、「Project [%]」、「Job [%]」および「Job Class [%]」の合計は常に 100% になります。

いずれかのスライダを動かすと、変化を補うために、ロックされていないそのほかすべてのスライダが変化します。

ロックが開いている場合は、ロックが保護するスライダは自由に動きます。直接操作されることによって動くことも、別のスライダが動かされたために、動くこともあります。錠が閉じていると、錠が保護するスライダは動きません。4 つの錠が閉じていて 1 つが開いている場合は、どのスライダも動かせません。

コマンド行からの機能共有ポリシーの構成

注 –

QMON を使用する場合にのみ機能共有をジョブに割り当てることができます。この機能に関してはコマンド行インタフェースは使用できません。

コマンド行から機能共有ポリシーを構成するには、適切なオプションを指定した qconf コマンドを使用します。

Procedureユーザー、プロジェクト、および部署に基づく機能スケジューリングの作成方法

この設定を使用して、クラスタ内のすべてのリソースのある種の配分割り当てを、さまざまなユーザー、プロジェクト、または部署に対して作成します。同じユーザー、プロジェクト、または部署のジョブでは、先着順のスケジューリングが使用されます。

  1. 「Scheduler Configuration」ダイアログボックスで、「Share Functional Tickets」チェックボックスを選択します。

    「機能チケットの分配の共有」、および sched_conf(5) のマニュアルページを参照してください。

  2. スケジューラ構成で、機能チケットの数 (1000000 など) を指定します。

    「QMON を使用したポリシーに基づくリソース管理の構成」、および sched_conf(5) のマニュアルページを参照してください。

  3. スケジューリング関連の項目を追加します。

  4. 各ユーザー、プロジェクト、または部署に機能共有を割り当てます。

    「QMON を使用したユーザーアクセスリストの構成」、および access_list(5) のマニュアルページを参照してください。

    全体に対するパーセンテージとして配分を割り当てます。次に例を示します。

    ユーザーの場合

    • UserA (10)

    • UserB (20)

    • UserC (20)

    • UserD (20)

    プロジェクトの場合

    • ProjectA (55)

    • ProjectB (45)

    部署の場合

    • DepartmentA (90)

    • DepartmentB (5)

    • DepartmentC (5)

優先ポリシーの構成

優先スケジューリングでは、Grid Engine システムの管理者またはオペレータは、ユーザー、部署、プロジェクト、ジョブクラスに関連付けられている、1 つまたはすべてのジョブの相対的な重要性を動的に調整することができます。この調整では、指定されたジョブ、ユーザー、部署、プロジェクト、またはジョブクラスにチケットを追加します。優先チケットを追加すると、優先スケジューリングでは、ユーザー、部署、プロジェクト、またはジョブが受け取るチケットの合計数が増加します。その結果、リソースの全体配分が増加します。

また、優先チケットを追加すると、システムのチケットの合計数も増加します。こうした追加のチケットによって、あらゆるジョブのチケットの価値が低下します。

優先チケットは、次の 2 つの用途に使用できます。

ジョブに直接割り当てられた優先チケットは、そのジョブが完了すると消滅します。ほかのすべてのチケットは元の価値に戻ります。ユーザー、部署、プロジェクト、ジョブクラスに割り当てられた優先チケットは、管理者が明示的にチケットを削除するまで、システムに留まります。

「Policy Configuration」ダイアログボックスには、システムでアクティブな優先チケットの現在の数が表示されます。

注 –

優先エントリは「Override」ダイアログボックスに残ります。不必要になった時点で管理者がこれらのエントリを明示的に削除しなかった場合、以降の運用に影響が出ることがあります。

QMON を使用した優先ポリシーの構成

「QMON Policy Configuration」ダイアログボックスの下部にある「Override Policy」をクリックします。「Override Policy」ダイアログボックスが表示されます。

「Override Category」リスト

優先チケットを定義する対象である業務優先カテゴリ (ユーザー、プロジェクト、部署、またはジョブ) を選択します。

優先テーブル

優先テーブルはスクロール可能です。次の情報が表示されます。

QMON は、「Override Policy」ダイアログボックスに表示される情報を定期的に更新します。ただちに表示を更新させるには、「Refresh」をクリックします。

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

優先構成の変更

優先テーブルの上にある曲がった矢印をクリックして、構成ダイアログボックスを開きます。

コマンド行からの優先ポリシーの構成

注 –

QMON を使用する場合にのみ優先チケットをジョブに割り当てることができます。この機能に関してはコマンド行インタフェースは使用できません。

コマンド行から優先ポリシーを構成するには、適切なオプションを指定した qconf コマンドを使用します。