OmniRPC：グリッド環境での並列プログラミングのためのGrid RPC システム

全文

(1)ハイパフォーマンス 92−７コンピューティング（２００２．１０．２５）. OmniRPC: グリッド環境での並列プログラミングのための Grid RPC システム佐藤三久. †. 朴. 泰祐. †. 高橋大介. †. グリッド環境での並列プログラミングのための Grid RPC システム OmniRPC を設計、実装した。パラメータ検索などの master-slave のグリッドアプリケーションを効率的に実行するために、 OmniRPC では再初期化可能リモート実行モジュールにより、初期化を行う手続を定義し、どこで起動されても、データをセットし初期化しておくことができる。一度起動したリモート実行プログラムとのコネクションを維持して、同じ手続への呼び出しを効率化し、初期化でセットされたデータを再利用できる。また、グリッド環境として複数のクラスタを想定し、プライベートネットワークのクラスタに対しては、リモート実行プログラムとクライアントとの通信を中継すると同時に、通信を多重化することができる。この機能を用いることによって、1000 台規模までのリモートホストが利用できる。rsh によるローカルクラスタ、globus によるグリッド環境の他、ssh によるリモートホストでも利用可能である。プログラミングの API としては、Ninf を踏襲しており、API をスレッドセーフにすることにより、OpenMP を用いることができ、簡便な並列な並列プログラミングを提供している。. OmniRPC: a Grid RPC System for Parallel Programming in Grid Environment Mitsuhisa Sato ,† Taisuke Boku. †. and Daisuke Takahashi†. We have designed and implemented OmniRPC, a Grid RPC system for parallel programming in a Grid environment. To support typical master-slave grid applications such as parametric search, OmniPRC provides “re-initialiable remote module” that defines ”initialization” procedure to send and store data to a remote executable at invocation time. Once a remote executable is invoked, it is re-used for the next call by keeping the connection to the remote executable. We assume that a typical grid consist of several clusters. For a cluster with private network, a manger process running the server host relays the communications between the client and the remote executables, and multiplex them with one connection to the client. It also enables the client to use more than a thousand remote hosts. OmniRPC supports a local environment with rsh, a grid environment with globus, and remote hosts with ssh. While OmniRPC API inherits Ninf API, the programmer can use OpenMP for parallel programming, because API is designed to be thread-safe.. 1. はじめにインターネットをはじめとする広域ネットワークの進歩により、広域ネットワーク上の計算資源やデータの共有、並列分散コンピューティング、協調作業の支援を可能にするいわゆるグリッド技術が注目されている。本稿では、グリッドにおいて複数の計算資源を用いて、簡便に並列分散プログラミングを行うための Grid RPC システム OmniRPC について述べる。現在、グリッドの標準的な環境として、Globus ToolKit3) が多く用いられている。Globus では、遠 † 筑波大学電子・情報工学系 Institute of Information Sciences and Electronics, University of Tsukuba. 隔の計算資源でのジョブ起動のコマンドインタフェースとして globusrun コマンドが提供されている。これにより、ファイル転送と組み合わせて、簡単なジョブスクリプトを記述することができる。グリッド向けのプログラミング環境としては、Globus の MPI プログラミング環境 MPICH-G がある。しかし、パラメータ検索のような比較的簡単なプログラムを記述するために面倒な MPI によるプログラミングを行わなくてはならない。また、MPICH-G では固定的で複数の計算機を占有する必要があり、計算資源の状況が変化するグリッド環境では利用が難しい場合がある。グリッドによる広域分散コンピューティングではパラメータを変化させながら類似の計算を行うことが多い。開発する並列プログラミングシステムにおいては簡便にしかも、背後にあるグリッド上の計算資源の割. 1 −37−.

(2) Local-area network Multi-threaded client in OpenMP rsh& TCP/IP OmniRPC. 2. OmniRPC システムの概要と設計 remote nodes in a cluster node node. node. node. remote nodes Globus toolkit node in a grid environment wide-area node node network. 図1. OmniRPC によるプログラミング. り当てを意識することなく、このような計算を行えることが望ましい。そのための遠隔計算機へのインターフェースとして、遠隔手続き呼び出し (RPC: Remote Procedure Call) を用いて、遠隔の計算資源でのプログラムの実行を可能にする OmniRPC システムを試作実装した。グリッドの計算資源を RPC を用いて利用する Grid RPC は、グリッドでのプログラミングインタフェースとしてこれまでもいくつか提案されている。広域ネットワーク向けの RPC として提案された Ninf1),4) の Globus 向けの実装である Ninf-G5) は、その Grid RPC の一つである。OmniRPC も、基本的な API として Ninf システムを踏襲しており、Ninf システムから派生したグリッド向け RPC である。この他にも、 netSolve や従来 LAN 内の RPC であった CORBA をグリッド環境上で利用する試みも行われている。我々の想定する典型的なグリッド環境は、複数の計算機クラスタが計算資源としてグリッド上に接続されており、これらのクラスタを相互に利用する環境である。クラスタの各計算機はローカルなネットワークで構成されている場合があり、外部のネットワークからのアクセスをサポートする機能を提供する必要がある。また、並列プログラムの開発は個々のクラスタで行うことができるようにし、大きなプログラムの変更なしに大規模な計算資源を利用できるグリッド環境に移行できることが望ましい。そのため、図 1に示すように、OmniRPC はローカルなクラスタから、グリッド環境まで、同様なプログラミングができる環境を提供する。OmniRPC では、RPC システムがスレッドセーフになっており、並列プログラミングには並列プログラミングインタフェースである OpenMP を用いることができるため、指示文による並列記述を可能にし、プログラマの負担を軽減することができる。次章において、OmniRPC システムの設計の概要を述べ、3 章において、実装について述べる。4 章にて OpenMP による OmniRPC を用いた並列プログラミングの例について述べ、簡単な実行例を示す。5 章に課題を挙げる。. 2.1 設計目標 OmniRPC の設計目標は、以下のものである。 • サポートするするプログラミングモデルとして、 master-slave 型の並列プログラミングをサポートする。 • 簡便な並列プログラミング環境を提供する。非同期呼出しによる並列プログラミングの他に、RPC をスレッドセーフにすることにより、OpenMP の指示文による並列プログラミングをサポートし、ベースとなる既存の逐次プログラムをなるべく書き換えずに並列化できるようにする。 • 遠隔の計算資源として、クラスタを想定する。特に、クラスタ内のネットワークとしてプライベートなアドレスを用いて構成されたクラスタについてもサポートする。 • 大規模なプログラムでは 100 ホストから 1000 ホスト規模までの計算資源をサポートできるようにする。 • 各計算資源の管理ポリシーを考慮したジョブ起動をサポートする。例えば、クラスタでは PBS などのバッチシステムで運用されていることが多いが、このような場合は指定された起動方法で遠隔のプログラムを起動する。 • 簡便な環境設定。あらかじめ特定のサーバなどのプログラムの設定をしなくても、利用できるようにする。 • グリッド環境においては、通信の確立に認証を行うなど、セキュリティについて配慮できるようにする。遠隔の計算機で実行されるプログラムについては個々のユーザのアカウントで実行されるようにする。 • 複数のグリッド環境のサポート。グリッド環境として、Globus で構成されたグリッド環境の他、 ssh を用いた遠隔計算機の利用環境構築も可能にする。また、プログラムの開発など、ローカルなクラスタにおいても rsh による環境を構築できるようにする。 • 動的な環境への対応。実行中に利用可能なホストの変更に対応できるようにする。また、実行中のホストの障害などに対応できるようにする。 2.2 OmniRPC の概要 OmniRPC は、ローカルホストで実行されるプログラムにおいて、指定された手続き (procedure) をリモートホスト上で実行する機構を提供する。リモートホストで実行される、その手続きを含むプログラムをリモート実行プログラム (remote executable) と呼ぶ。リモート実行プログラムを作成するためには、まず、Ninf IDL(interface description lan-. 2 −38−.

(3) guage) を用いて、遠隔呼出をする関数のインタフェースを定義する。これをリモートプログラム生成プログラム omrpc-gen を用いて、ローカルホストと通信するためのスタブルーチンを生成し、呼び出す関数や必要なライブラリとリンクすることによって、リモート実行プログラムを作る。例えば、行列積のルーチンのインタフェースは次の様に定義できる。 Module MatrixMult; ... Define dmmul(long mode_in int n, mode_in double A[n][n], mode_in double B[n][n], mode_out double C[n][n]) "... description ..." Calls "C" dmmul(n,A,B,C); mode_in と mode_out は、入力パラメータであるか、出力パラメータであるかを指定する。配列の引数に対しては入力パラメータを使ってサイズを指定することができる。リモート実行プログラムは、リモートホスト上に登録することによって、モジュール内の関数をローカルホスト上のプログラムから呼び出すことができるようになる。例えば、上の行列積のルーチンに対しては、 #define N 100 double A[N][N],B[N][N],C[N][N] ... OmniRpcCall("dmul",N,A,B,C); OmniRPC の最も基本的な API である OmniRpcCall は、その名前 dmul から、その関数が登録されているリモート実行プログラムがあるリモートホストを探し、遠隔呼び出しを行う。一つのリモート実行プログラムは複数の関数を含むことができる。このため、インタフェースを記述する IDL 記述において、複数の関数のインタフェースをまとめてモジュールとして定義する。一つのリモート実行プログラムに含まれる関数群をリモート実行モジュールと呼ぶ。 2.3 再初期化可能リモート実行モジュールと実行モジュールの persistency OmniRpcCall では遠隔手続呼び出しに関して、基本的に、persistency を保証しない。すなわち、リモート実行プログラムは一つの関数呼び出しが終ると終了することがある。これは、関数呼び出しを動的に任意のリモートホストに割り当てることができるようにするためである。しかし、複数の関数が一つのリモート実行プログラムに定義されているため、一つの関数でセットした変数を他の関数で利用するといった、persistency を利用したプログラミングが可能である。例えば、パラメータ検索のようなプログラムでも、基本的なデータをあ. らかじめリモート実行モジュールに送りセットしておき、実際のパラメータ検索は必要なパラメータのみを変えて実行することによって、不必要な通信を省くことができる。しかし、このような persistency を利用したプログラムではリモート実行プログラムの実行状態をユーザが管理しなくてはならなくなり、負荷分散をする場合にプログラムの簡便性を失うことなる。このため、OmniRPC ではリモート実行モジュールの起動時に実行される初期化手続きを定義することによって、実行モジュールを起動時に自動的に初期化する機構を提供している。このような実行モジュールを再初期化可能モジュールと呼ぶ。他のホストに手続呼び出しが割り当てられた時には、再度実行モジュールを起動し、自動的に初期化を行う。例えば、上の行列積の例において、行列 B が初期化された以降、変化しないという場合には、 Module MatrixMult; ... Initialize(long int n, double B[n][n]){ storeB(n,B); /* store B somewhere */ } Define dmmulB(long mode_in int n, mode_in double A[n][n], mode_out double C[n][n]) Calls "C" dmmulB(n,A,C); と定義しておき、呼び出し側のプログラムでは、以下のようにモジュールに対し、初期化の指定を行う。 #define N 100 double A[N][N],B[N][N],C[N][N] ... OmniRpcInitModule("MatrixMult",n,B); .... OmniRpcCall("dmulB",N,A,C); OmniRpcInitModule は初期化のデータを登録するのみで、OmniRpcCall が実行された時点で、実行されるモジュールが提供されているリモートホストを探し、リモート実行プログラム起動時に初期化を行う。負荷の状況や障害によって、リモート実行プログラムの実行を終了しても、他のリモートホストで初期化し、再実行できる。このような再初期化可能リモート実行モジュールを設けることによって、基本的なデータをリモートホストにあらかじめ転送しておき、関数ごとに必要なパラメータを指定するといったプログラミングができるようになる。この他に、リモート実行モジュールの persistency をユーザが管理する API も提供している。この場合、リモートホストを指定し、モジュールを起動し、OmniRpcHandle という構造体を得る。この handle を用いて、特定の実行中のリモート実行モジュールに対し、遠隔関数呼び出しを行うことができる。. 3 −39−.

(4) 2.4 OmniRPC の環境設定 OmniRPC の環境設定を行うためのディレクトリを、レジストリと呼ぶ。デフォールトでは、 $(HOME)/.omrpc_registry が用いられる。クライアントプログラムを実行するホストにおいては、どのホストをリモーホストとして用いるかをレジストリの hostfile で指定する。この hostfile では、以下の項目を指定する。 • リモートホストのホスト名 • 実行できるジョブの最大数 • リモートホストのレジストリのパス • リモートホストの remote shell のタイプ (rsh, ssh, globus のいずれか ) • リモートホストのジョブ起動のスケジューラ。具体的には、pbs や Sun Grid Engine などのローカルスケジューラの名前。 • リモートホストとの通信を多重化するか。リモートホストが、１台の計算機の場合には単に fork をつかってジョブを起動することになる。それに対し、リモートホストがクラスタである場合にはホストの名前としてクラスタホストを登録し、ジョブ起動の種類を指定する必要がある。プライベートアドレスで構成されたクラスタの場合は、通信の多重化の指定を行い、クラスタホストとを経由して通信を行うようにしなくてはならない。リモートホストのレジストリには、そのリモートホスト上で登録されたリモート実行プログラムと実行モジュールで提供されている手続きに関するデータベースが格納されており、omrpc-register コマンドを用いて、登録しておく。 2.5 OmniRPC の API 基本的な API として、Ninf システム (Ninf v1) の API を踏襲している。以下に、主な API を挙げる。 • int OmniRpcCall(char *proc_name,...) proc_name で指定された手続きを、この手続きが実行できる適当なリモートホストを選択して、実行する。 • OmniRpcRequest *OmniRpcCallAsync( char *proc_name,...) 非同期の呼び出しを行う。リクエストに対する handle を返す。 • int OmniRpcWait(OmniRpcRequest *req) リクエストに対応する手続き呼び出しが終了するまで、待つ。 • int OmniRpcWaitAll() これまで、発行された非同期呼び出しを待つ。 • int OmniRpcWaitAnd(int n_req, OmniRpcRequest req[]) n 個のリクエストの handle への配列を与え、全てのリクエストが終了したするまで待つ。 • int OmniRpcWaitOr(int n_req,. • •. •. •. • •. OmniRpcRequest req[],int *done_idx) n 個のリクエストの handle への配列を与え、どれかのリクエストが終了した時に、終了したリクエストに対応するインデックスをdone_idx に返す。 int OmniRpcProbe(OmniRpcRequest *req) リクエストが終了したかどうかを確かめる。 OmniRpcHandle *OmniRpcCreateHandle( char *hostname,char *module) 指定されたモジュールをリモートホストで起動し、それへの handle を得る。 OmniRpcCallbyHandle(OmniRpcHandle *handle,— char *proc_name,...) 起動しているリモート実行モジュールに対し、手続き呼び出しを行う。 OmniRpcDestroyHandle(OmniRpcHandle *handle) 起動しているリモート実行モジュールを終了させ、 handle を開放する。 OmniRpcInit(int *argc,char **argv[]) ライブラリの初期化を行う。 OmniRpcFinalize() ライブラリの finalize を行う。. 3. OmniRPC の実装 3.1 omrpc-mgr: リモート実行プログラムの起動リモートホストでのリモート実行プログラムを起動するために、ライブラリ初期化時に hostfile に登録されているリモートホストに対し、omrpc-mgr を起動してする。omrpc-mgr の起動は、rsh や ssh 、globus では GRAM を用いて行われる。omrpc-mgr は、クライアントプログラムの実行ごとに起動され、以下の機能を提供している。 • リモートホストごとに設定されている起動方法にしたがって、リモート実行プログラムを起動する。 • 実行したリモート実行プログラムのプロセスの管理。 • レジストリの情報などの、リモートホストの情報の取得。 • 通信の多重化による、ローカルアドレスクラスタとの通信の中継。 omrpc-mgr でリモート実行プログラムを起動する理由の一つは、rsh などでは短時間に多数のジョブの起動が行われるとセキュリティ管理上、サービスが拒否されて、起動できなくなってしまうからである。また、 globus 環境ではリモート実行プログラムの起動は直接 GRAM を用いて行うことができるが、GRAM ではリクエストごとに認証を行うために非常に時間がかかってしまうことがある。そのため、どの環境においても、omrpc-mgr を使うことで実装を統一した。なお、omrpc-mgr や個々のリモート実行プログラムとの通信は TCP/IP を用いているが、コネクション. 4 −40−.

(5) に関しては、クライアントプログラムにおいて、ローカルホスト上の空きポートを取得し、リモートのプログラム起動時にそのポートを指定することによって、コネクションを行っている。あらかじめ、固定のポートを必要しないため、固定ポートでのサービスにありがちなセキュリティの問題を避けることができる。また、全て、ユーザの設定で済むために、インストール、環境設定が容易になる。 3.2 コネクションの維持とスケジューリング omrpc-mgr を起動した後、クライアントプログラムは omrpc-mgr を用いて、それぞれのリモートホストで登録されているリモート実行モジュールの情報を収集する。OmniRpcCall で、手続呼び出しが行われると、指定された手続があるリモートホストを検索し、そのホストに対して、omrpc-mgr を使って、リモート実行プログラムを起動する。起動されたリモート実行プログラムに対しての手続き呼び出しは、Ninf と同様、IDL に記述されたインタフェースの情報を実行時に取得することによって、リモートプログラムの引数データの送受信を行う。初期化が必要なリモート実行モジュールに対しては、起動時に他の呼び出しと同様の手順を使って、初期化が行われる。一度起動されたリモート実行モジュールは、次の呼び出しに備えて、コネクションが維持され、待機中になる。次に、同じリモート実行モジュールの手続呼び出しがあった場合には、待機中のリモート実行モジュールに対し、呼び出しが行われる。これによって、リモート実行プログラムの起動の手間を省くことができる。リモート実行プログラムは必要に応じて、hostfile で指定されたホスト毎の最大のジョブ数まで起動される。そして、待機中になったリモート実行プログラムに対して、順次、手続呼び出しが行われる。リモート実行プログラムが終了するのは以下の場合である。 • ホスト毎のリモート実行プログラムのジョブの数が上限に達しており、手続呼び出しを行う手続がどの現在実行中のリモート実行プログラムにない場合 (つまり、別のモジュール)。この場合、適当な待機中のリモート実行プログラムを終了させ、そこに呼び出しを行おうとしているリモート実行プログラムを起動する。 • 強制的、あるいは障害で、リモート実行プログラムが停止した場合。例えば、長時間待機中のリモート実行プログラムは終了する場合も含まれる。 • クライアントプログラム終了時。 3.3 omrpc-mgr による通信の多重化 omrpc-mgr により、クライアントプログラムと複数のリモート実行プログラムとの通信を多重化し、一つのコネクションで行うことができる。これにより、次の利点が得られる： • リモートホストがクラスタであり、クラスタが. ローカルアドレスで構成されたネットワークの場合、この機能を使って、omrpc-mgr が各クラスタノードで実行されるリモート実行プログラムとの通信を中継する。 • 1000 台規模のリモートホストを用いる場合には、クライアントプログラムでは通信に対するファイルティスクプリプタが不足してしまう。この場合には、数十のホストごとにリモートホストを作り、ここに omrpc-mgr を起動し、中継させることによって、クライアントプログラムへの直接コネクションされる数を削減させることができる。 3.4 ssh による port forwarding の利用グリッド環境として、globus が利用されることが多いが、今だにインストール管理の繁雑さから利用されていない場合が多い。OmniRPC では、最も一般的に使われているリモートシェルである ssh(secure shell) を用いて、リモート手続呼び出しができるようにした。 ssh 環境では、ssh を用いて、omrpc-mgr をリモートホストで起動する。ssh が用いられている環境では通常、ポートが制限されていることが普通である。そのため、omrpc-mgr とクライアントプログラムの通信は、ssh の port forwarding の機能を用いて行う。また、omrpc-mgr が起動するリモート実行プログラムとの通信も、omrpc-mgr で多重化することによって、 omrpc-mgr が中継することになる。なお、ssh 環境では、ssh-agent による自動認証が必要となる。. 4. OmniRPC を用いた並列プログラミング OmniRPC による並列プログラミングには、非同期呼び出しを用いることもできるが、ここでは OmniRPC の一つの特徴である OpenMP による並列プログラミングについて述べる。 4.1 OpenMP による並列プログラム OmniRPC は、スレッドセーフに実装されているため、クライアントのプログラムに OpenMP を用いて並列プログラミングすることができる。本来、OpenMP は共有メモリの並列マシンにおいて並列プログラミングをするための API であるが、ここではマルチスレッドのプログラミング環境として用いる。 Omni OpenMP コンパイラ2) では、linux では pthread を用いて、- omniconfg=mutex オプションを付けることによって、pthread の同期操作を mutex で行い、オペレーティングシステム下でスケジューリングさせることができる。ローカルホストが単一 CPU のマシンであっても、複数のスレッドで実行するために、それぞれのスレッドからのリモートマシンへの関数実行要求はスレッドごとに並列に行われることになる。次に、簡単な例を示す。 OmniRpcInit(...); /* initialize RPC */ ..... 5 −41−.

(6) #pragma omp parallel for for(i = 0; i < N; i++) OmniRpcCall("work",i,...); この例では、リモート関数 work が、違う i について、スレッド数分だけ遠隔手続き呼び出しが並列に実行される。 Omni OpenMP システムの実行環境として、リモートマシンの数分だけのスレッドを指定しておくことによって、すべてのリモートマシンで並列に実行させることができる。この他にも、OpenMP の section 指示構文などを用いて、タスク並列の記述を用いることができる。 4.2 プログラムの実行例プログラム例として、0-1 ナップサック問題を取り上げる。この問題はいわゆる探索問題の一つで、組み合わせをノードとする木を探索する問題になる。OpenMP を用いて解く方法の一つはまず、最初に幅優先で検索を行い、部分問題を作り、その一つ一つの部分問題を別々のスレッドで、深さ優先で最適値を計算すればよい。この検索には分枝限定法が使えるために、並列に行う深さ優先の検索の実行時間は一定ではない。以下に、プログラムの主要な部分を示す。 main(int argc,char *argv[]){ OmniRpcInit(&argc,&argv); ... r = knap_bfs(Cap,breadth); #pragma omp parallel for private(rr) for(k=0;k<breadth;k++){ OmniRpcCall("knap_dfs", N,W,P, states[k].i,states[k].cp,states[k].M,&GLow,&rr); #pragma omp critical { if(rr > r) r = rr; } } ... OmniRpcFinalize(); }. knap_bfs で幅優先で部分問題を生成し、深さ優先検索knap_dfs を RPC で実行している。最初に幅優先で見付ける部分問題を 1000,4000,8000 にした時の実行時間を表 1に示す。実験環境の各ホストは、ADM AthonMP processor 1800+ (1.5GHz) の dual CPU で、100BaseT ethernet で接続されている。問題データは、45 個の item をほとんど同じ価値 (0-1 問題) でランダムに生成したものある。なお、OmniRPC で、4 ホスト、8 ホスト使用時には、 OpenMP のスレッド数をそれぞれ 10,20 に設定した。この問題では、それぞれの部分問題の深さ優先の探索が、1ms 以下から、4 秒とバラツキが大きく、そのために、8 ホスト (16CPU) でも、13 倍程度になっていると思われる。部分問題の数を多くすると、問題は細分化されて負荷分散がうまくいく可能性が増えるが、 RPC のオーバーヘッドは増えることになる。本稿ではローカルな環境での評価に留まったが、広. No. of hosts. seq. OpenMP 1 host. OmniRPC 4 hosts. OmniRPC 8 hosts. 1000 345.28 189.56 67.143 47.16 4000 345.36 175.12 46.10 25.08 8000 345.16 175.29 44.73 23.71 表 1 ナップサック問題の実行時間 (dual Althon MP 1.5GHz クラスタ、実行時間は秒単位). 域ネットワーク環境での評価については、評価中である。. 5. おわりに本稿では、グリッド環境での並列プログラミングのための Grid RPC システム OmniRPC の概要と実装について述べた。本稿では設計と実装、簡単な評価について述べたが、これから広域ネットワーク環境での評価を行い、実際のアプリケーションに用いて、改良を行っていく予定である。これから課題として、実行状況の確認を行うためのツールとデバック環境がある。また、リモートホストでの実行プログラムの登録などの設定を手動で行っているが、これについてもホスト数が多くなるにしたがって、適当な支援ツールが必要となる。設計目標の一つに動的な環境への対応や故障ホストの検出処置があるが、これについても課題として残されている。特に、大規模なプログラムの場合、長時間実行されることが想定されるため、リモートホストの追加、削除など設定変更は必要になると思われる。謝辞：本研究を遂行するにあたり、日頃議論頂く Ninf プロジェクトメンバー諸氏に感謝いたします。本研究の一部は、科学研究費補助金特定領域研究 (2) 課題番号 14019011「計算物理学分野の Grid アプリケーションと並列プログラミングシステムの研究」およ JST-ACT「創薬プラットフォームのためのグリッド環境の開発」による。. 参考文献 1) Ninf Project. http://ninf.apgrid.org/. 2) Omni OpenMP Compiler Project. http://www.hpcc.jp/Omni. 3) I. Foster and C. Kesselman. Globus: A metacomputing infrastructure toolkit. In Proc. of Workshop on Environments and Tools. SIAM, 1996. http://www.globus.org/. 4) M.Sato, H.NakadaS. Sekiguchi, , S.Matsuoka, U. Nagashima, and H. Takagi. Ninf: A Network based Information Library for Global WorldWide Computing Infrastructure. Proc. of HPCN’97 (LNCS 1225), pages 491–502, 1997. 5) 田中, 中田, 平野, 佐藤, 関口. Globus による Grid RPC システムの実装と評価. In 情報処理学会研究会報告 HPC87, pages 165–170, 2001.. 6 −42−.

(7)