test

Sun N1 Grid Engine 6.1 管理ガイド

スケジューリング戦略

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

動的リソース管理

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 は強制的にファイルにトレース出力を書き込みます。