トップ 新規 編集 差分 一覧 Farm ソース 検索 ヘルプ PDF RSS ログイン

F-Omegaマニュアル

[ソフトウェア,グリッド]

渡邊が開発した F-Omega ミドルウェアのマニュアルです。概念とかは論文を参照してください。

導入手順

対象とする機器構成

以下のマシンから構成されるグリッドを対象とします。

  • ユーザの作業用端末(マシンAとする)
  • グリッド化されたクラスタ・・・論文中でサーバと呼んでます。
    • ユーザからのジョブ要求を受け付ける窓口マシン(マシンBとする)・・・いわゆるゲートキーパーノード。
    • ジョブを実行するマシン(マシンCとする)・・・いわゆる計算ノード。(インストール方法以下の解説で触れない。GridRPCなので特別考慮する必要はない)
  • サーバ切り替え指示ホスト(マシンDとする)

あらかじめ必要なもの

実験ではOSに CentOS や FedoraCore を使いましたが,Globus Toolkit 4 が動作する Un*x なら動作可能と思います.

各マシンに次のソフトウェアを導入しておくこと。

  • マシンA
    • Globus Toolkit 4
      • ユーザ毎のGSIの設定。
    • Ninf-G 4
      • クライアントとしてセットアップ。
    • Json-C
      • F-Omega tarball に入っている json-c-0.6.tar.gz を使ってください.
      • 基本どおり解凍して ./configure --prefix=DIR ; make ; make install です.
  • マシンB
    • Globus Toolkit 4
      • GRAMをデーモン動作するように設定。ホスト用GSIの設定。
    • Ninf-G 4
      • サーバとしてセットアップ。
  • マシンC
    • 特になし
  • マシンD
    • SQLite2
    • Perl 5以上、さらに次のモジュールを導入しておくこと(CPANから入れられると思う)
      • DBI、DBD::SQLite2、HTTP::Date、IO::Socket、JSON、LWP::Simple、MIME::Base64、XML::DOM、XML::Parser、Time::HiRes

この時点でマシンAからマシンBに対しGlobusのGRAMが正常動作することを確認しておくことを推奨します。たとえば:

マシンA> globus-job-run マシンB /bin/date

また,同様に Ninf-G を用いてGridRPCが正常に動作できることを確認しておくことを推奨します(Ninf-Gのサンプルプログラムを使う等).

(松本追記 2009/2/10)

  • マシンAにlibtoolが必要です(F-Omega, JSON-Cが依存)
  • マシンBにhttpd(apacheやthttpdなど)が必要です。ただし、なくてもサンプルは動きます。

インストール方法

前述の「あらかじめ必要なもの」をインストールした後,マシンA上にfomega.tar.gz(15)をダウンロードして,

マシンA> tar -xzf fomega.tar.gz
マシンA> cd fomega
マシンA> configure --with-json-c=JSONCDIR

ただし,JSONCDIRには Json-C のインストール先フォルダを指定します.そして,

マシンA> make

以上で,うまくいけば lib/libfomega.a が作成されるはずです.

(追記 2009/07/02)

configureファイルの末尾にある以下の行をコメントアウトしてください。

chmod +x cgi/fomega.cgi

おまけ

渡邊はマシンAとマシンDが物理的に同じマシンで実験しました.もし,マシンAとマシンDが物理的に別の場合には,cgi フォルダをマシンDにコピーしてください.ただし,動作は未確認なので,もしかしたらどこかで参照ミスとかおこるかもしれません.

動かし方

F-Omegaアプリケーションの記述方法

F-Omega tarball 内の etc/nqueen/ フォルダ内に N-queens のサンプルアプリケーションが入っています.

サーバ側アプリケーション

Ninf-Gのやり方でリモートライブラリを作成してください.詳細は Ninf-Gウェブサイト の Documents の How to build remote libraries を参照してください.

クライアント側アプリケーション

書き方の概念レベルについては論文を参照してください.

F-Omega tarball 内の etc/nqueen/nqueen_cparallel.c にサンプルがあるので参考にしてください.

具体的に書く必要があるのは,次の4つのタイプのイベントに対するイベントハンドラです:
イベントタイプ イベントの意味
EVENT_LIBRARY_ADD Actuatorからライブラリ追加指示が来た
EVENT_LIBRARY_SUBTRACT Actuatorからライブラリ削除指示が来た
EVENT_CALL_COMPLETED 実行していたRPCが成功した
EVENT_CALL_FAILED 実行していたRPCが失敗した
イベントハンドラでは,ライブラリ起動/終了API関数を呼ぶ,アプリ固有タスクの状態を管理する,といった処理を記述します.以下にイベントループを抜粋しますので,どこでどのAPI関数を使うのか等,参考にしてください.

while (completed == 0) {
  //Fetch an event from event queue
  fomega_event_pop(&event);
  switch (event.type) {
  case EVENT_LIBRARY_ADD: //Library Add operation from Actuator
    for (i = 0;i < event.operation.amount;i++) {
      //Start remote library
      rcode = fomega_library_init(event.operation.hostname, event.operation.attr);
    }
    break;
  case EVENT_LIBRARY_SUBTRACT: //Library Substract operation from Actuator
    for (i = 0;i < event.operation.amount;i++) {
      //Stop remote library
      fomega_library_delete_by_hostname(event.operation.hostname);
    }
    break;
  case EVENT_CALL_COMPLETED: //Remote call completed
    fomega_call_get(&call, event.callid);
    //Which call finished? (CALL_INIT on library startup)
    if (strcmp("get_number_of_solutions", call.action) == 0) {
      PRINT("%d-Queens: Task[%ld] completed, %ld\n", n, call.taskid, tmpcount[call.taskid]);
    }
    //If un-dispatched task remains
    if (taskstates[taskid] == TASK_STATE_UNALLOCATED) {
      //Dispatch asynchronous RPC
      if (fomega_invoke_async(event.libraryid, "get_number_of_solutions", taskid, n, depth, fixpos[taskid], &tmpcount[taskid]) == GRPC_NO_ERROR) {
        fomega_library_state_transit(event.libraryid, SOLVER_STATE_COMPUTING);
      }
    }
    break;
  case EVENT_CALL_FAILED: //Remote call failed
    fomega_call_get(&call, event.callid);
    if (strcmp("get_number_of_solutions", call.action) == 0) {
      PRINT("%d-Queens: Task[%ld] failed\n", n, call.taskid);
    }
    break;
  case EVENT_QUIT: //Quit operation
    completed = 1;
    break;
  }
  //Release event info
  fomega_event_dispatch(event);
}

F-Omegaアプリケーションのコンパイル・リンク・配置方法

サーバ側アプリケーション

こちらも Ninf-Gウェブサイト の Documents の How to build remote libraries を参照してください.

基本的には,マシンBのIDLファイルがあるフォルダに移動して,

> $NG_DIR/bin/ng_gen hoge.idl
> make -f hoge.mak

です.

実行時にMDSを使わないようにするため,ここで自動作成されたマシンB上の *.ngdef ファイルを,マシンA上のクライアント側アプリケーションの置いてあるフォルダにコピーしておきましょう.

クライアント側アプリケーション

コンパイル・リンク手順は etc/nqueen/Makefile を参考にしてください.基本的には次のコマンドです:

libtool --tag=link ng_cc -g -o hoge `FOMEGA_DIR/makeflag.sh -cc` hoge.c `FOMEGA_DIR/makeflag.sh -ld`

F-Omega フォルダ内の makeflag.sh は configure 時に作成されるシェルスクリプトで,F-Omega 用のコンパイルオプション/リンクオプションを出力します.

次に,実行前にNinf-Gのクライアント設定ファイルを作成する必要があります.etc/nqueen/client.conf を真似してください.基本的に LOCAL_LDIF 節と SERVER 節を書くだけでOKです.

<LOCAL_LDIF>
filename hoge.hpbla1.yuba.is.uec.ac.jp.ngdef
filename hoge.hpbla2.yuba.is.uec.ac.jp.ngdef
filename hoge.hpbla3.yuba.is.uec.ac.jp.ngdef
filename hoge.hpbla4.yuba.is.uec.ac.jp.ngdef
filename hoge.hpbla5.yuba.is.uec.ac.jp.ngdef
filename hoge.hpbla6.yuba.is.uec.ac.jp.ngdef
filename hoge.hpbla7.yuba.is.uec.ac.jp.ngdef
filename hoge.hpbla8.yuba.is.uec.ac.jp.ngdef
</LOCAL_LDIF>
<SERVER>
hostname hpbla1.yuba.is.uec.ac.jp
hostname hpbla2.yuba.is.uec.ac.jp
hostname hpbla3.yuba.is.uec.ac.jp
hostname hpbla4.yuba.is.uec.ac.jp
hostname hpbla5.yuba.is.uec.ac.jp
hostname hpbla6.yuba.is.uec.ac.jp
hostname hpbla7.yuba.is.uec.ac.jp
hostname hpbla8.yuba.is.uec.ac.jp
</SERVER>

F-Omegaアプリケーションの実行方法

  1. マシンBの管理者が,サーバ運用計画ファイルを作成し,マシンB上で公開します.
    • cgi/cst/ フォルダ内にサーバ運用計画ファイル(拡張子 .cst のXMLファイル)のサンプルがあるので,参考にしてください.
    • サンプルではマシンBで公開せず、マシンDのローカルに各サーバの運用ファイルを置いてfile://で参照しています。上記どおりにマシンB上で公開するなら、httpdサービスを起動してマシンDからhttp://(マシンBアドレス)/xxx.cstのようにアクセスができるように運用方針ファイルを配置する必要があります。(松本追記 2009/2/13)
  2. マシンD上でユーザがサーバ利用方針ファイルを作成します.
    • etc/ フォルダ内にサーバ利用方針ファイル(拡張子 .plcのXMLファイル)のサンプルがあるので,参考にしてください.
  3. マシンA上でF-Omegaアプリケーションのクライアント側プログラムを起動します.
    • Actuator が自身と通信するためのIP アドレスとポート番号を標準エラー出力に表示します.
    • Actuator は既定ではポート 5912 番を使います.
      • (追記 2009/07/02)5912番が開いていなければ1つ大きい番号を使います。前のプロセスがゾンビ化している場合、このポート番号が変わるので注意。
  4. 表示されたIP アドレスとポート番号,全サーバの運用計画ファイルのURL,サーバ利用方 針ファイルのパスをコマンドライン引数として,マシンD上でユーザがサーバ選択プログラムを起動します.
    • まず,マシンD上で,
> cd cgi/
> vi joystick.sql

ここで,ファイル末尾にサーバ運用計画ファイル(拡張子 .cst)のURLを登録するSQL文があるので,それを環境に合わせて適宜修正してください.

    • 続いて,
> perl ./initialize.pl
> vi croncom.sh

ここで,cronにより定期起動させるシェルスクリプトを編集します.重要な箇所は次の文です:

> perl ./autosteer.pl "マシンAのIPアドレス:Actuatorのポート番号" サーバ利用方針ファイルのパス `./dateafter.sh 100`

dateafter.sh は現在時刻から指定秒後の「Epochからの秒数」を出力するシェルスクリプトです.この引数には,どの程度未来の状況を踏まえてサーバ選択をするかを指定します(この例では100秒後).

    • 続いて,サーバ運用計画ファイルをクローラスクリプトでダウンロードし,SQLデータベースに格納します.それには次のコマンドを実行します:
> perl ./update.pl &

このスクリプトはサーバ運用計画ファイルを定期的に(既定では60秒間隔で)読み直します.引数で間隔の秒数を指定できます.

    • 最後に,croncom.sh を cron 登録します.
> crontab -e
> crontab -l
0 * * * * /home/watanabe/experiment/fomega/cgi/croncom.sh

以上で,手作業は終了です.

cron で呼び出されたサーバ選択プログラム(croncom.sh → autosteel.pl)がサーバ運用計画・サーバ利用方針を読み込み,Actuator を介してサーバ利用状況を取得します.そして適切なサーバ切り替え指示を作成し,TCP/IP 通信により指示をActuatorに送信します.続いて,マシンAではサーバ切り替え指示に応じてサーバの変更が行われます.すなわち,受信した指示に応じて,Actuator がリモートライブラリの追加/削除指示イベントをイベントキューに挿入し,対応するイベントハンドラが,指示に応じてリモートライブラリの起動/終了を行うF-OmegaモジュールAPI を実行します.

ソースファイル構成

いじくるときに参考にしてください。

フォルダ・ファイル名 説明
cgi/
cgi/genconst.sh (実験用,期間長・サーバダウン回数・外乱ジョブ数から .cst ファイルを自動作成するシェルスクリプト)
cgi/csvout.pl (実験用,autosteel.plの出力結果からサーバ切り替え結果についてのcsvを出力するスクリプト)
config/ (configure支援ファイル群)
etc/
etc/nqueen/ N-queensサンプルアプリケーション類
etc/nqueen/nqueen.c N-queensスレーブプログラム(リモートライブラリの本体ルーチン,初期配置パターンを与えると解の個数を返す)
etc/nqueen/nqueen.idl Ninf-G用IDLファイル
etc/nqueen/nqueen_cparallel.c N-queensマスタープログラム(リモートライブラリ呼び出し側,Segmentation Fault バグの解析のためのGCを使ったメモリリーク検出コードを入れています)
etc/nqueen/nqueen_cserial.c N-queens逐次版(演算結果の照合のため,nqueen.cとリンクして使用すること)
include/fomega.h 共通ヘッダファイル
lib/libfomega.a ライブラリファイル
macros/ (configure支援ファイル群)
src/Makefile.in 要修正
src/actuator.c Actuatorや各種モジュールの初期化・終了処理を行います.
src/actuator_base64.c Base64エンコーダ/デコーダ
src/actuator_callback.cpp (もともと主にコールバック型で実装していた名残で,コールバック関数を管理/呼び出したりします)
src/actuator_tcpserver.cpp TCPサーバスレッド
src/actuator_tcpserver_worker.c TCP接続時に生成されるスレッドの処理が実装されています.
src/actuator_timer.cpp 指定日時にアクションを起こすといったタイマー処理を行います.
src/mod_callmanager.cpp STLのmap<RPC ID,fomega_call_t>でRPCセッションの情報を管理するモジュールです.
src/mod_eventmanager.cpp イベントキューモジュール.
src/mod_librarymanager.cpp STLのmap<ライブラリID,fomega_library_t>で実行中のライブラリの情報を管理するモジュールです.
src/mod_servermanager.cpp (サーバのホスト名を管理するモジュールですがあまり使ってません)
src/mod_waiter.cpp 非同期RPCの状態を数秒おきに監視し,変化をRPCセッション管理モジュールやイベント管理モジュールに伝えるモジュールです.バグの温床?
aclocal.m4 (configure支援ファイル)
configure configure.inを修正したらautoconfで作り直してください
configure.in 要修正
json-c-0.6.tar.gz Json-Cライブラリ
makeflag.sh.in
Makefile.in

to be written

fomega.tar.gz[削除] leak.html[削除]

最終更新時間:2009年07月02日 20時17分44秒