Condorの汎用グリッドインターフェイスの設計とUNICOREへの適用

全文

(1)2004−ARC−157 （7） 2004−HPC− 97 （7） 2004／3／1. 社団法人情報処理学会研究報告 IPSJ SIG Technical Report. の汎用グリッドインターフェイスの設計とへの適用中田伊藤. 秀基泰善. ÝÝ Ý. 中野. Ý. 恭成. Ý. 山田基弘松岡聡. Ý ÝÝ. 本稿では、システムにおける、汎用の外部グリッドシステムへのインターフェイス機構の設計および実装に関して述べる。システムは特定の外部グリッドシステムに対するインターフェイスを持っているが、これを使用するにはシステム内部の変更が必要になり、新たな外部グリッドシステムのサポートを追加することが難しかった。われわれは、任意の外部グリッドシステムへのインターフェイスを容易に構築するための汎用インターフェイスを設計し、この問題を解決した。さらに、この汎用インターフェイスを用いて、

(2) システムを外部グリッドシステムとして利用するブリッジを実装し、汎用インターフェイスによる手法の有効性を確認した。.

(3)

(4)

(5) . ÝÝ. Ý. Ý. Ý. Ý. ÝÝ. ! " #$ % & $ $ '( & . & )$ % " * $ $ & $ & % " *

(6) & + $ ,+". はじめにはウィスコンシン大学で開発された、スケジューリングシステムで、キャンパス内での遊休資源の有効利用による、ハイスループットコンピューティングを指向している。は通常のジョブ起動方法以外に、

(7)

(8) の

(9) をはじめとするいくつかのジョブ起動システムに対するインターフェイス機構を持っており、これらのグリッドシステムを経由してジョブを起動することができる。しかし、このインターフェイス機構は個々のグリッドシステムに応じてのシステム内部に作りこまれており、新たなグリッドシステムへの対応を行うには、の内部を変更する必要があり煩雑である。われわれは、システムに外部のジョブ起動システムに対する汎用のインターフェイスを追加した。さらに、外部ジョブ起動システムとして Ý 産業技術総合研究所

(10)

(11) Ý Ý Ý# Ý%.

(12)

(13)

(14) . ウィスコンシン大学

(15) 富士通株式会社 !"

(16) 東京工業大学 $

(17)

(18) 国立情報学研究所

(19) ". をターゲットとし、このインターフェイス機構を利用したブリッジを作成した。この結果、汎用インターフェイスの有効性を確認した。本稿の構成は次のとおりである。節と節で本稿の対象システムであるとについて概要を述べる。節で汎用グリッドインターフェイスの設計を説明する。節でこのグリッドインターフェイスを用いたへのブリッジを詳述する。節でまとめと今後の課題を述べる。. の概要は、米国ウィスコンシン大学のグループが開発したハイスループットコンピューティングを指向したキューイングシステムである。当初はキャンパス内の遊休計算機を有効利用することを目的としていたが、現在では後述する ! の機能により、. のメタスケジューラとしても広く使用されている。は、計算可能な計算機の集合をプールと呼び、ユーザがサブミットしたジョブに対して、プールに属する計算機に割り当て、実行する "図 #。このジョブに対して計算機を割り当てる方法に、マッチメイキングと呼ばれる方法が使用される。. −37−.

(20) セントラルセントラルマネージャマネージャ. サブミットマシン. クラスタ. Condor Submit Machine. Globus Execute Machine. Schedd. GateKeeper. ジョブを実行する計算機を決定 Grid Manager. Submit. Job. Globus GAHP Globus GAHP Server. 実行マシン. Job. JobManager. Batch System. Job. クラスタ. サブミットマシン. 図. Condor Pool 図. セントラルマネージャ. . Collector. Schedd. Startd. Starter Shadow. サブミットマシン. 図. Job Condor Syscall Lib. 実行マシン. & のデーモン. さらに、計算が適宜チェックポイントされ、サーバフェイル時の再実行や優先順位の高いジョブによるプリエンプションがサポートされていることが、の特徴である。によるジョブの実行図に $ システムを構成するデーモンの相関図を示す。ユーザはのシステムコールライブラリとリンクされたジョブを用意する。次にジョブを記述したサブミットファイルを用意し、コマンドを用いてサブミットマシンの %$&"%$& '(# に投入する。%$& は定期的にサブミットされたジョブの情報をセントラルマネージャの $

(21) に送信する。実行マシンでは、%

(22)

(23) が自らの状態をモニタし、定期的に $

(24) に報告する。

(25) では、$

(26) に集まった情報を用いて、定期的に、ジョブと実行マシンの「相性」を判定し、相性がよい組み合わせで実行を行うように、サブミットマシンと実行マシンに指令する。相性を判定する過程はマッチメイキングと呼ばれる。 %$& は、%

(27)

(28) に対してジョブを送信し、実行を依頼する。実行マシン上で起動したジョブは、システムコールライブラリによって適宜チェックポイントがとられる。.

(29) . &' によるジョブの起動. れる。は属性に対する制約を記述する記述形式で、ユーザによるアドホックな拡張が可能であることが特徴である。を用いることによって、柔軟なマッチメイキングが可能となっている。. & の概要. Negotiator. Submit. GRAM Protocol. では上述のマッチメイキングを、と呼ぶデータ構造に基づいて行う。%$& や %

(30)

(31) が $

(32) に送信する情報はすべてで行わ. は、 )

(33) のジョブ起動サービスであるを用いて管理されているホストに対して、ジョブを起動する機能を持っている。この機能を ! と呼ぶ。 ! によるジョブ起動の様子を図に示す。 ! によるジョブ起動は、通常のジョブ起動の方法とまったく異なり、%$& が主導する。まず、 %$& はと呼ぶプロセスを起動し、このプロセスにジョブの起動を依頼する。! はさらに、実際にのプロトコルを実行する !*+ サーバと呼ばれるプロセスを起動する。と !*+ サーバは後述する *+ と呼ばれるプロトコルで通信を行う。 !*+ サーバは、の

(34) と通信を行い、ジョブの起動を依頼する。

(35) は , ( を経由してバッチシステムにジョブをサブミットし、バッチシステムがジョブを実際に起動する。

(36) の概要 *+" % * +

(37) $# は、の内部で用いられているテキストベースのプロトコルの枠組みである。 *+ では、クライアントとサーバの間で、行ずつの文字列を交換する。クライアントからサーバへはが送られ、サーバからは、とが送られる。

(38) - は、 .

(39) - が有効であるかどうかを示すもので、 .

(40) - のパーズが完了すると即座に返送される。これに対して、

(41) - は、.

(42) の処理が終わった際にリクエストとは非同期に返却される "図 #。.

(43) - と

(44) - の対応をつけるために ' を用いる。.

(45) - にはクライアントが定めた ' が付与される。サーバはこの ' を

(46) - に含めて返送する。各 - はスペースで分割された文字列コマンドから構成され、で終端される。文字列コマンド. −38−.

(47) GridManager. GAHP Server. Client. Request Return. Gateway. Firewall. Result. 図. NJS. '() のメッセージパッシング. 自身にスペースを含む場合には、スペースをバックスラッシュでエスケープする。バックスラッシュ自身もバックスラッシュでエスケープする。 *+ 自身はプロトコルのフレームワークであり、実際に使用されるコマンドのセットを規定しない。 !*+ では、用のコマンドセットを定義し、それを使用している。. . ! によって、で管理されている資源に対してもからのジョブ起動が可能になるが、そこで使用できるの機能は非常に限定されたものになる。

(48) によるスケジューリング機能は限定的になり、リモートシステムコールやチェックポインティングなどはサポートされない。この問題を解決する手法としてが実装されている。これは、! の仕掛けを利用しての実行マシンの機能をサーバ側に起動し、の資源を正式なプールの一部にしてしまうという方法である。実際に計算を行うジョブは、改めて通常の経路でサブミットされることになる。この方法はのジョブが起動される実行マシンが、グローバルアドレスを持つ場合にしか機能しないという問題点があるが、スケジューリングやチェックポイントを利用できるため非常に有用である。.

(49) の概要は、欧州富士通研究所が中心となって開発したグリッドミドルウェアである。は、スーパーコンピューティングセンターをのスーパーコンピュータを、遠隔地からシームレスに利用することを目的に設計されており、この使用法に対する要請から、ファイアウォールに対する配慮が十分になされている。の概要を図に示す。では、ファイアウォールに囲まれたサイトを

(50) " %

(51) # と呼ぶ単位で抽象化している。各

(52) の中には、実際に計算を行う /

(53) "/

(54) %

(55) # と呼ばれる単位がつ以上存在する。

(56) がスーパーコンピュータセンタに、/

(57) がスーパーコンピュータや、計算機クラスタなどの計算システムに相当する。ではユーザのサブミットするジョブが、単一のタスクではなく、複数の依存関係を持つタスクからなるワークフローとなっている。このワークフ. NJS. TSI. TSI. Batch Subsystem. Batch Subsystem. Vsite. Vsite Usite. 図. &*+, の概要. ローは 01 のオブジェクトとして記述されており、このオブジェクトをシリアライズしたものをモジュール間でやり取りすることで、ジョブのサブミッションを行う。このワークフローを表現したオブジェクトを 0"

(58) $

(59) 0 ,$

(60) # と呼ぶ。各

(61) には、

(62) 23 と呼ばれるデーモンプロセスがつ存在する。この

(63) 23 が外部からの通信すべてを中継する。このため、

(64) 23 だけを 4! 5 上に露出しておくだけで、

(65) に含まれるすべての /

(66) の計算機資源を外部から使用可能になる。

(67) にはつ以上の /

(68) があり、各 /

(69) には 0%"

(70) 2 0 % 1 # と呼ばれるデーモンが存在する。0% は実際にタスクを実行するモジュールで、ワークフローを解釈するワークフローエンジンであると同時に、後述の )% と連動して、各タスクを処理するエンジンとしての役割も果たす。 )%")

(71) %3

(72) (

(73) 6$# は、バッチサブシステムと 0% の間を取り持つモジュールである。バッチサブシステムとしては、+7% や -%4 などのバッチジョブキューイングシステムの他、4 による直接の起動も使用できる。. 汎用グリッドインターフェイスの設計インターフェイスの問題点. 前節で述べたとおり、! ではと *+ サーバが分離されており、のプロトコルを実際に処理する部分は *+ サーバに分離されている。したがって、理論的には、他のグリッドシステムでのジョブサブミッションを可能にするためには、 !*+ サーバ部のみを他のグリッドシステム向けに書き直せばよい。ここで問題になるのは、 !*+ のプロトコルである。 !*+ のコマンドセットのセマンティクスは、の + のセマンティクスに緊密に束縛されている。実際にと通信するのは *+ サーバであるが、+ のセマンティクスをハンドルするロジックはに収めら. −39−.

(74) 表. . 汎用 '() コマンドセット. 名称. -*. &+,,. +

(75) /

(76) +

(77) +

(78) .

(79) !. 意味. ジョブを作成し、そのジョブに対するハンドルを返す。ジョブの作成に必要な情報は &. で与えられる。. 名称. -*. +. +

(80) /

(81) +

(82) +

(83) .

(84)

(85) !. 意味. 指定されたジョブハンドルの指すジョブを起動し、その成否を返す。. 名称. -*. . +

(86) /

(87) +

(88) +

(89) .

(90)

(91) " # !. 意味. 指定されたジョブハンドルの指すジョブのステイタスを返す。ステイタスは &. として表現される。. 名称. -*. 0,+*1. +

(92) /

(93) +

(94) +

(95) . $

(96) % !. 意味. 指定されたジョブハンドルの指すジョブを破棄する。この際 '() サーバ内のジョブ関連情報だけではなく、対象グリッドシステム内部の情報も破棄する。. Gateway. Condor Submit Machine Schedd. Submit. UNICORE UNICORE Protocol Protocol. NJS TSI. Grid Manager. Batch Subsystem. UNICORE GAHP. Job. UNICORE GAHP Server. Usite. 図. Firewall. Vsite. &*+, ブリッジを用いたジョブ起動. 時のジョブ記述やジョブの状態としては、のを使用する。この理由としては、内部でが用いられているため既存部分との親和性が高い、入出力ライブラリが用意されているため実装が容易、任意の属性を追加できるため拡張性が高い、が挙げられる。には 8- 表記と独自のテキスト表記のつの表現方法があるが、われわれは 8- 表記を採用した。. 汎用コマンドを用いた

(97) ブリッジの実装. れているのである。このため、このコマンドセットを維持したまま他のグリッドシステムに適用することは非常に難しい。そもそも、外部グリッドシステムのロジックをに持つことは望ましいとはいえない。新たにグリッドシステムを追加するたびに、比較的複雑な構造を持つに手を入れなければならないからである。汎用

(98) コマンドセット上に示した問題点を解決するために、すべてのグリッドシステムを統一的に扱う枠組みとして、われわれは汎用の *+ コマンドセットを定義した。汎用 *+ コマンドセットはグリッドシステムに対してニュートラルに設計されているため、*+ サーバ側を書き直すだけでさまざまなグリッドシステムに対応することができる。表に、汎用 *+ コマンドセットを示す。表中のは文字列もしくはを示す。も同様である。% は % $$ を、4 は 4 を、はを示す。コマンド名にという名前が現れているものの、コマンドセットの設計はのプロトコルにはまったく依存していないことに注意されたい。汎用コマンドセットは、ジョブの生成、起動、状態検出、破棄のつのコマンドからなる。ジョブ生成. 汎用 *+ コマンドを用いて、他グリッドシステムへのブリッジを作成するには、まず、ジョブサブミッションに用いるの属性値を定義し、その ! を解釈して、実際に他のグリッドシステムにジョブを発行する *+ サーバを作成すればよい。 *+ プロトコルはテキストフォーマットであるため、*+ サーバは実装する言語を選ばない。! のプロトコルは 01 に強く依存しているため、本研究では、 *+ サーバを 01 で実装した。ブリッジを用いたからのジョブ起動の様子を図に示す。

(99) の設計には、ジョブの実行と情報の伝達に十分なだけの情報が含まれていなければならない。表に *+ で使用するの属性を示す。上段はが標準で使用している属性、下段が今回用意した属性である。 !*+ サーバはジョブのステイタスをに返さなければならない。しかし、! のジョブステイタスは層からなる比較的複雑な構造をとっているのに対し、のジョブステイタスはつの状態からなる単純な構造で、セマンティクスにギャップがある。!*+ サーバは、のジョブステイタスを表に示すマッピングにしたがって、のジョブステイタスにマップし、に返している。. −40−.

(100) 表. -2 . の属性値. 属性. 意味. 例. &" . , 0 * ,

(101) 8

(102) * 8 -2. ,9

(103).

(104) +

(105) "

(106) &$"

(107) .

(108)

(109) .

(110) +

(111) ,5. ,5&

(112) ,5. 実行ファイルのパス名実行ファイルに渡す起動時の引数実行時にセットする環境変数クライアント側のベースディレクトリ標準入力に与える入力ファイル標準出力からの出力を収めるファイル標準エラーからの出力を収めるファイルステージインするファイル名ステージアウトするファイル名 & におけるジョブのステイタスエラーメッセージジョブの実行時間総送信バイト数総受信バイト数実行プロセスがシグナルで終了したか実行プロセスの ,5 コード実行プロセスの終了シグナル. 3"

(113) 3 34

(114) 5

(115) 6 !'7

(116) 3"

(117) 3$3 8 4 8 4 ,4 4

(118) 5

(119) 6 8 4 4 表第カラム参照 8

(120) 8

(121)

(122) . 4: :::# :::# +, ;.

(123)

(124)

(125) ?

(126) @

(127)

(128)

(129) ). 8

(130)

(131)

(132) -2

(133) -2.

(134) !. 上 & 汎用 3 下 &*+, 依存

(135) の

(136) の

(137) < の =0 とポート名 4"># 上記

(138) 内の ?

(139) の名前 +

(140) ' キーストアファイル名 3"

(141) 3 3$

(142) パスフレーズファイル名 3"

(143) 3 38. < ハンドルとなるジョブの 0 4">#3+

(144) ' 3A#:B;; &*+, におけるジョブのステイタス表第カラム参照 &*+, のファイルのファイル名 333

(145) 4. 表. . ジョブステイタスのマッピングコ &*+, ジョブステイタスージョブステイタスド. &.

(146) . . + + C +

(147) "

(148) & &"8

(149)

(150) . #. ( (

(151)

(152) 58

(153)

(154) . % :. &* ',0 ),0 ' +,01 ,C,& ' =,,0 ),0,0 + ' &&,! !,0 ,C,& * @ !!,0 !,0 &+ * !,0 &* ' ,?,+ @, (,!0. パスフレーズの管理. ではクライアントとサーバ間の認証に 89:; 形式の証明書を用いている。 *+ サーバはのクライアントとして機能するため、キーストアに格納された証明書にアクセスする。このキーストアを開くためにはパスフレーズが必要である。 *+ サーバは、クライアントマシンがクラッシュした際などにも自動的に再起動できなければならない。. この場合、ユーザにパスフレーズを入力させることはできないので、何らかの方法でパスフレーズを管理しなければならない。本実装では、キーストアのパスフレーズをユーザアカウントでのみ読み出し可能なファイルに書き込むこととしている。*+ サーバはこのパスフレーズファイルからパスフレーズを読み出し、それを用いてキーストアから証明書を取得する。プログラム実行の概要サブミットファイルの記述経由でにジョブを投入する際には、通常のシステムの場合と同様に、のサブミットファイルを記述する。この際に、! に特有の属性を書く必要がある。サブミットファイルは、内容的にはと類似しているが、属性名は微妙に異なる。固有の属性は、システムのサブミットファイル解釈部には認識されない。しかし、属性名の前に << をつけることで、に直接反映されることができる。サブミットファイルの例を図 = に示す☆ 。ジョブのサブミットジョブのサブミットも通常のと同様に ☆. −41−.

(155)

(156) が '2 となっているが、これは歴史的経緯で、現在のところ '() サーバを経由する起動はすべて 2 ユニバースに分類されているためである。この点は、今後修正される予定である.

(157) の再接続を行う。は *+ サーバを起動し、0 ' を渡してジョブ %

(158)

(159) の検出を行う。 *+ サーバはこの動作をトリガとして、外部グリッドシステムと接続して、ジョブとの再接続を行う。.

(160)

(161)

(162)

(163)

(164)

(165)

(166)

(167)

(168)

(169) !"#

(170) $

(171) %&

(172) '( )

(173) *

(174)

(175) +,

(176) ++-

(177) * .,

(178)

(179) +,

(180) ++/0 1

(181)

(182) 図. . おわりに. サブミットファルの例. 0 23 コマンドを用いて行う。この際、事前にパスフレーズファイルを用意する必要がある。 %$& はジョブサブミットファイルを受け取ると、に変換する。次に、を起動し、がさらに *+ サーバを起動する。は、%(4&25624&78 コマンドでジョブを作成を指令する。 *+ サーバは、コマンドの引数として渡されるを解釈してパスフレーズファイルを取り出し、キーストアを開いて証明書を取り出す。今後 *+ サーバがシステムにアクセスする際には、この証明書を用いる。次に、*+ サーバはジョブを表現したからそれに対応する 0 を作成する。この 0 の ' を用いての 0 ' を作成し、! に返却する。は、0 ' を受け取ると、次に %(4&256287&8 コマンドで 0 の実行を指令する。*+ サーバは該当するジョブを $ システムにサブミットする。ジョブの管理 *+ サーバは、%(4&2562878 コマンドを用いて定期的にシステムにアクセスし、ジョブのステイタスを取得する。ジョブの実行が終了していた場合には、ジョブの出力ファイルをクライアント側に転送する。一方、は、定期的に *+ サーバにアクセスし、ジョブのステイタスを取得する。ジョブが終了した場合、%$& にジョブの終了を報告する。最後に、%(4&256298&: コマンドで、*+ サーバ内の状態、および、システム内の状態を破棄する。クライアントクラッシュからのリカバリはクライアントマシンがクラッシュし、リブートした際にもサーバ側で実行中のジョブを管理することができる。%$& は実行中のジョブをファイルで管理しているため、リブート時にも、外部グリッドシステム上で実行中のジョブがあることを検出できる。%$& はを再起動し、ジョブへ. 本稿では、システムにおける、汎用の外部グリッドシステムへのインターフェイス機構の設計および実装に関して述べた。さらに、この汎用インターフェイスを用いて、システムを外部グリッドシステムとして利用するブリッジを実装し、汎用インターフェイスによる手法の有効性を確認した。今後の課題としては以下が挙げられる。 ¯ パスフレーズ格納法の検討現在は、キーストアのパスフレーズはファイルに格納されているが、これはセキュリティ的には望ましい方法ではない。自動的な再起動が可能である、という要件を満たしつつより安全な手法を検討する。 ¯ 汎用 *+ コマンドの有効性の検証本稿で提案した汎用 *+ コマンドを他のグリッドシステムに適用し、その有効性を確認する。. 謝. 辞. 本研究の一部は文部科学省「経済活性化のための重点技術開発プロジェクト」の一環として実施している超高速コンピュータ網形成プロジェクト "：!

(183) $&

(184)

(185) 1# によるものである。. 参考. 文. 献. # -13 9 7 3 09 ( 9 )! ( )9> $& ( 6 *& )& &!

(186) (

(187)

(188) /9 9 ";;=#9 # 4

(189) 9 ? ( 9> > (

(190) $(

(191) 6

(192) $

(193)

(194)

(195) 9 .

(196) . ";; #9 # ( 9> )& $&

(197) $

(198) ! %( $$

(199) '

(200)

(201) $ .

(202) ! "# $ % # &"% ' 9 @=A; ";;;#9. # 9 &

(203)

(204) >BB2229 $9B9 # )& '9 ) ( )9 -13 9>

(205) & ( % #) # (

(206) $

(207) *

(208) ! "7( 49 4C 9 *3 )9" 9## 0& 53 D % $9 "::#9 # % * +

(209) $9 &

(210)

(211) >BB2229$ 92 $9 B$B&B9. −42−.

(212)