３．スケジューラの実現方式

　図２は、数値風洞のソフトウェア概念図である。図に示されているように、ＦＥＰおよび数値風洞のコントロールプロセッサＣＰには、第２章で述べた「自動化プログラム」の他に、リクエストの流れを管理するためのＮＱＳが搭載されている。ＮＱＳは、システム内のリクエストの管理やスケジュール等を行うための数多くの関数から構成されており、表１に示すようなスケジューリング関数により、リクエストの受け付け、システム資源要求量が制限値をこえるリクエストのリジェクト、多重度による実行リクエストの制御、実行リクエストの先着順処理等をキュー毎に行うことができる。なお、これらの関数の中にはリクエスト到着時、実行終了時、キャンセル時の手続き付加や独自のスケジュールアルゴリズムの組み込みを行うために内容変更が許されている関数がある。

図２ 数値風洞のソフトウェア概念図

　数値風洞の機能は既存のＮＱＳだけでは実現できないため、ＮＱＳに足りない機能を追加して航技研独自のジョブスケジューラを構築した。本章では、これらの機能を実現するために必要となるリクエスト管理方式、リクエスト起動方式について述べる。

３．１ リクエスト管理方式

　以下に、リクエストを管理するためのキュー構成とリクエストの分類、リクエストのキュー遷移条件、リクエストのキュー内優先度を説明する。

(1)キュー構成とリクエストの分類

　図３に、ＮＱＳのリクエスト管理方式例を示す。例では、２５６ＭＢのＰＥを要求するリクエストの管理方式を示したもので、特権ジョブのリクエスト（以後、特権リクエストと呼ぶ）を処理するｊｑ００キューと一般ジョブのリクエスト（以後、一般リクエストと呼ぶ）を処理するｊｑ０１キューという２つのキューを定義した場合を示している。各キューに投入されたリクエストは、以下に述べるwaitset 、queuedset 、stageset、holdset、runset の中のいずれかの状態となり、状態別に優先度順で管理される。なお、queuedset 、stagesetのリクエストのみ起動可能である。

図３ ＮＱＳのリクエスト管理例

waitset　　:	リクエストの実行日時の指定等の条件により待ちの状態となっているリクエスト。待ち条件が解消されれば、queuedset となる。
queuedset :	stageset 、runsetに移行可能なリクエストで、スケジューラがプレステージを指示すればstagesetに、起動すればrunsetになる。
stageset :	プレステージが完了したリクエストで、スケジューラが起動すればrunset になる。
runset :	実行中のリクエスト。実行終了後はＦＥＰへのファイル転送終了後に削除される。
holdset :	waitset、queuedset 、stageset、runsetへの移行抑制中のリクエスト。

　しかし、ＮＱＳの場合、設定できる優先度のレベルには限界があり、キューへの登録時に決定した優先度はリクエストが削除されるまで変化しない。また、リクエスト到着時にはディスク上のすべての情報が参照可能であるが、到着後はメモリ内に展開された一部のデータしか参照できないためリクエストのシステム資源要求量等を参照することはできない。そのため、ＮＱＳのリクエスト管理キューとは別に、スケジューラでは以下に述べる５種類のリクエスト管理キューを使用する。これらのキューには、優先度またはリクエスト残り時間を示す情報の他に起動判定等に必要となるシステム資源要求量等の情報や、リクエストを識別するためのマシン番号とシークエンス番号が格納されている。なお、キュー名の中のpr、ge、r は特権(privilege) 、一般(general) 、残り時間(remain time) の頭文字を取っている。

prwait：	実行待ちの特権リクエスト管理キュー。
prexec：	実行中の特権リクエスト管理キュー。
gewait：	実行待ちの一般リクエスト管理キュー。リクエストを待ち時間等に応じて非優先リクエスト、優先リクエスト、最優先リクエストに分け、それぞれgewait[1],gewait[2],gewait[3] で管理する。
geexec：	実行中の一般リクエスト管理キュー。リクエストを待ち時間等に応じて、非優先リクエスト、優先リクエスト、最優先リクエストに分け、それぞれgeexec[1],geexec[2],geexec[3] で管理する。
rtime：	実行中の全リクエストの残り時間を管理するキュー

　なお、これらの管理キューは、優先度または残り時間の順に管理するが、それらのデータは時間に応じて変化する。そのため、各キューの優先度または残り時間は、先頭リクエストはそのままの値を、後続のリクエストは直前のリクエストとの差を格納する。これにより、ｔ時間経過した場合の値は残先頭のリクエストからのみｔを減算することになる。

　なお、２５６ＭＢのＰＥを要求するリクエストと１ＧＢのＰＥを要求するリクエストのように、複数のジョブグループを取り扱う場合にはその分だけ管理キューが必要となるが、数値風洞では、以下に示すように、台数の多い２５６ＭＢのＰＥを要求するリクエストのみ特権リクエストの定義を可能にしている。

　ｊｑ００：２５６ＭＢのＰＥを使用する特権リクエストのキュー
　ｊｑ０１：２５６ＭＢのＰＥを使用する一般リクエストのキュー
　ｊｑ０２：１ＧＢのＰＥを使用する一般リクエストのキュー

そのため、使用している管理キューは以下の通りである。

　prwait[ii],prexec[ii] (ii=1)
　gewait[ii][m],geexec[ii][m] (ii=1 〜2,m=1 〜3)
　rque[ii] (ii=1 〜2)

　図４に、リクエスト管理キューにおけるリクエストのキュー遷移説明図を示す。同図は、システムに投入されたリクエストが実行終了するまでに遷移するキューを図示したものである。同図からも分かるように、特権リクエストは、投入時は実行待ちリクエスト管理キューであるprwaitキューで、実行開始後は実行中リクエスト管理キューであるprexecで管理され、実行終了時にprexecキューから削除される。一般リクエストも同様に、gewaitキュー、geexecキューを経て削除される。ただし、次項に述べるキュー遷移条件を満たした場合には、より優先度の高いgewaitキューおよびgeexecキューへ移される。図には示されていないが、上記処理と平行して、特権リクエストおよび一般リクエストの実行時には、rtimeキューに登録され、実行終了時にはrtime キューから削除される。
　なお、前述したように、特権リクエストを扱うｊｑ００キューは先着順処理を行うＦＣＦＳ方式で、一般リクエストを扱うｊｑ０１、ｊｑ０２キューはシステム資源要求量と待ち時間に応じた優先度順処理を行うＰＰ方式で処理をする。しかし、ＦＥＰでは資源要求量が認識できないためにすべてのキューのリクエストをＦＣＦＳ方式で処理をする。

図４ リクエスト遷移説明図

　図５、図６に実行待ちリクエストおよび実行中リクエストの管理キュー説明図を示す。同図の丸印は管理キューに登録されているリクエストを、中の数字はシステム内の相対的なリクエスト優先順位を示しており、リクエストはキュー毎に優先度順に管理される。数値風洞では、特権リクエストを扱う prwaitキュー、prexecキューは一般リクエストを扱うgewaitキュー、geexecキューより高い優先度を設定している。

図５ 実行待ちリクエスト管理キュー

　

図６ 実行中リクエスト管理キュー

(2)リクエストのキュー遷移条件

　ＰＰ方式の場合には、待ち時間が一定値に達したリクエストをより優先度の高いキューに移すために、実行待ちリクエストおよび実行中リクエストの遷移条件を以下のように設定する。

　優先度キューへの遷移条件 ：WTj ≧WTj1
　最優先度キュー への遷移条件：WTj ≧WTj2

　ここで、WTj は、そのリクエストが現在の属性になってから現在に至るまでの待ち時間であり、高優先度ジョブのリクエスト（以後、高優先度リクエストと呼ぶ）の場合には高優先度化されてからの時間、ユーザタイムジョブのリクエスト（以後、ユーザタイムリクエストと呼ぶ）の場合にはユーザタイム開始後の時間、その他のリクエストの場合にはリクエスト投入後の時間となる。また、WTj1、WTj2は以下のように定義する。

　・高優先度リクエストの場合
　　　WTj1= WTj2 = WTSPF
　・ユーザタイムのリクエストの場合
　　　WTj1= WTj2= CPUj × √PEj × WT2F + WTUTF
　・その他のリクエストの場合
　　　WTj1= CPUj × √PEj × WT1F + userfact
　　　WTj2= CPUj × √PEj × WT2F + userfact

　ここで、PEj およびCPUjはリクエストｊの要求ＰＥ台数および要求ＣＰＵ時間（単位：秒）を、userfactはユーザ毎の優先度の調整値を表す。また、WT1F、WT2Fはシステムの混雑度に対処するための運用パラメータであり、以下の範囲で定義する。

　　　0 ＜ WT1F ≦ WT2F ＜ ∞

遷移条件の定義からも判るように、数値風洞ではＰＥ台数の多いリクエストを優遇している。また、WTSPF 、WTUTF は高優先度リクエストやユーザタイムリクエストを優先するためのパラメータであり、以下の関係式満たすものとする。

　　　WTSPF≪ WTUTF ≪０

したがって、先に述べた遷移条件から、高優先度リクエストやユーザタイムリクエストはppwait[3] につながれるが、実行可能であればppexec[3] につながれる。

(3)リクエストのキュー内優先度

　ＦＣＦＳ方式の場合には、到着順にリクエストを管理するため、キュー内優先度（以後、単に優先度と呼ぶ) の設定は行わないが、ＰＰ方式の場合には以下の様に設定する。
　gewait[1] およびgeexec[1] のリクエストの優先度 PR1、gewait[2] およびgeexec[2] のリクエストの優先度PR2 、gewait[3] およびgeexec[3] のリクエストの優先度 PR3は、それぞれ以下の関数に従って決定する。なお、キュー内優先度の値の小さいもの程優先度は高いものとする。

　　　PR1 = WTj1 - WTj
　　　PR2 = WTj2 - WTj
　　　PR3 = WTj2 - WTj

　また、gewait[3] およびgeexec[3] キューの場合、高優先度リクエストの優先度 "PR3(SPECIAL)" 、ユーザタイムリクエストの優先度 "PR3(USERTIME)"、その他のリクエストの優先度"PR3(NOMAL)"の関係は、

　　　PR3(SPECIAL) ≪ PR3(USERTIME)≪ PR3(NOMAL)

としているため、高優先度リクエストはユーザタイムリクエストより常に優先され、ユーザタイムリクエストはその他のリクエストより常に優先される。

３．２ リクエスト起動方式

(1)リクエスト実行条件

　本スケジューラでは、時間帯毎にシステム資源要求量による起動リクエスト制限、キュー毎の多重度制限、同一ジョブ内のリクエストの逐次実行を行っていることから、リクエストの実行可否の判定条件は以下の通りである。

　a)システムがスケジュール可能な状態であること。
　b)ＮＱＳの実行可能キュー(queuedsetまたはstageset) のリクエストであること。
　c)要求台数のＰＥの割り当てが可能であること。
　d)実行多重度に余裕があること。
　e)１ＰＥ使用リクエストの実行制限数以下であること。
　f)同一ユーザリクエストの実行制限数以下であること。
　g)システム資源要求量が起動リクエストの制限値以下であること。
　h)同一ジョブ内の他のリクエストが実行中でないこと。

しかし、組み込まれる計算機、処理方式（ＰＰ方式／ＦＣＦＳ方式）、処理内容（起動優先リクエストの起動／非起動優先リクエストの起動／起動優先リクエストのＰＥリザーブ／その他）等により起動判定に必要と考えられる項目が異なることから、それぞれの処理でチェックの必要な項目、不要な項目、意味のない項目に分け、必要な項目のみを条件とすることにした（表２参照）。以下に設定理由を簡単に説明する。ＣＰ用のスケジューラでは、ＰＰ方式の非起動優先リクエストを起動する際には全ての条件が必要となる。しかし、ＰＰ方式の起動優先リクエストの場合には、早急に処理するという目的から運用スケジュールの妨げとならないe)とf)の項目を除外した。ＰＥリザーブ処理では、ＰＥリザーブ開始予定時刻におけるリクエストの起動条件のうち、起動判定時まで判らない項目は除外したが、リクエストの高優先度化・非高優先度化やユーザタイム運用によりＰＥリザーブ対象のリクエストのシステム内の相対優先順位が変化することを考慮し、ＰＥリザーブ開始予定時刻に起動優先リクエストであることを確認する項目を付加した。また、ＦＣＦＳ方式のリクエストはその目的からe)からg)の起動リクエスト制限を除外した。

表２ リクエストの起動条件・ＰＥリザーブ条件

　一方、翻訳処理、結合処理を実行するＦＥＰ用のスケジューラではＦＣＦＳ方式で処理するが、これらはＣＰのＰＰ方式で処理する非起動優先リクエストの場合に準ずるものとする。しかし、ＦＥＰは並列計算機でないためＰＥの割り当てに関する項目は除外し、システム資源要求量は実行時のものが認識できないために除外した。

(2)ＰＥ割り当て可否判定条件

　リクエスト起動時およびＰＥリザーブ時のＰＥ割り当て可否判定条件を以下のように設定する。

条件：PEj ≦ free

ここで、"PEj"は起動対象リクエストの要求ＰＥ台数、"free"は割り当て可能空きＰＥ台数である。

(3)割り当て可能空きＰＥ台数算出方法

　起動優先リクエスト起動時には、他の実行待ちリクエストより優先的に起動するため、空きＰＥ台数をすべて使用できるが、使用可能ＰＥ台数が変化する場合には、その時刻と変化量を考慮しないとシステム停止等の処理を遅延させる恐れがある。さらに、ＰＥリザーブ中にはその台数と時間も考慮しなければならない。そのため、リクエスト起動時の割り当て可能な空きＰＥ台数は以下のように算出する。

図７ 空きＰＥ台数算出方法説明図

リクエストを新たに起動しないと仮定すると、システムで使用可能な空きＰＥ台数は、a)実行終了、b)使用可能最大ＰＥ台数の変更、c)ＰＥリザーブ開始、d)ＰＥリザーブ終了により変化する。最初に、ＰＥリザーブされていない場合、すなわち、a)およびb)のみを考慮した場合の例を図７に示す。図では縦軸にＰＥ台数を、横軸に時刻を採っている。説明に先立ち、以下の記号を定義する。

　jmax : 現在実行中のリクエスト数
　PEj : ｊ番目に終了予定のリクエストの使用ＰＥ台数(j=1〜jmax)
　nmax : 空きＰＥ台数変更事象の数
　t0 : 現在の時刻
　tn : ｎ番目に発生する空きＰＥ台数変更事象の発生時刻(n=1〜nmax)
　fn : 時刻tnにおける空きＰＥ台数(n=0〜nmax)
　FPEn : 時刻tnにおける空きＰＥ台数の変化量(n=1〜nmax)
　PEmax : 時刻toにおけるシステムで使用可能な最大ＰＥ台数
この場合、空きＰＥ台数の変化事象はリクエストの終了および図中の時刻t1、t4、t7で示されるような「利用可能なＰＥ台数の変更」となる。なお、時刻tnにおける空きＰＥ台数fnは次式で表される。

　同図では、起動優先リクエストを時刻t0から開始した場合と時刻t5から開始した場合の例が示されているが、free =「現在の空きＰＥ台数」と考えて時刻t1までに終了しないリクエストをt0に起動した場合には、時刻t1に予定している使用可能ＰＥ台数の削減処理が行えないことを示している。すなわち、使用可能最大ＰＥ台数が変化する場合には、free =「時刻t0から時刻t0+ELAPSj までの間の最小空きＰＥ台数」としなければならない。ここで、ELAPSjは「起動対象リクエストの経過時間」を表す。実際の起動判定処理では、表３に示す形式の表を使用して、各時刻における空きＰＥ台数を算出することができる。また、ＰＥリザーブが行われている場合には、ＰＥのリザーブ開始およびＰＥリザーブ終了をシステムの使用可能ＰＥ台数の変更事象と同様に考える事により対処できる。同様に、ＰＥリザーブの場合には free = 「時刻tnから時刻tn+ELAPSjまでの間の最小空きＰＥ台数」とすることにより、時刻tnでの起動の可否を判定することが可能になる。 なお、割り当て可能空きＰＥ台数の算出にはリクエストの経過時間が必要になるが、数値風洞ではリクエスト情報の経過時間を使用することができない。その理由は以下の通りである。
　リクエストの出力はＳＳＵを経由してＦＥＰ配下のディスクに書き込まれるが、プログラムはＳＳＵにすべて書き込んだ時点でつぎの処理に移ることが可能である。したがって、要求経過時間が十分でない場合には、ＳＳＵへの書き込みが終了し、リクエストの処理がすベて終了しても、ディスクへの書き込みが終了する前に経過時間でリクエストが打ち切られる可能性がある。したがって、リクエストの出力結果を保証するためには要求経過時間は十分大きめにセットせざるを得ない。 しかし、本スケジューラにおいて、リクエストの経過時間情報は必須であり、実運用に先立って行われたシミュレーション結果からも要求ＣＰＵ時間からの予測がかなり有効であることが実証されているため、要求ＣＰＵ時間に一定の値を掛けてもとめる方式を採っている。

表３ 割り当て可能ＰＥ台数算出表