[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gfarm-discuss-ja:00666] Re: 並列分散処理のプロセス数の制御とスプールディレクトリの共有



筑波大 建部様

愛媛大学の山本です。
お返事頂き、ありがとうございます。

以下、インラインで返信いたします。

>山本さま:
>
>今回のご質問以外では,衛星観測データの解析環境の構築は順調でしょうか?
>  
>
はい、今のところは順調です。

>まず,質問1に関してです.
>
>
>2. 添付のスクリプト gfq.sh を利用する方法
>
>まず,このスクリプトは,システムコールフックライブラリ(libgfs_hook.so)
>の利用を前提としていますので注意してください.
>
>添付の三つのスクリプトを PATH の通っているディレクトリに保存して,実行
>ビットを立てて,以下のように実行します.
>
>	% gfq.sh file cmd arg ...
>
>file は,ファイル・アフィニティ・スケジューリングで指定するファイルです.
>
>このとき,例えば file が 356 フラグメントからなる場合,最終的には計
>356 プロセスが実行されますが,それぞれのノードでは同時には高々一つのプ
>ロセスしか実行されません.
>
>これらのスクリプトで要求が満たされれればと思いますが,どうでしょうか?
>  
>
添付して頂きました gfq.sh は、クライアントノードのみに置けばよろしいで
しょうか?
また、システムコールフックライブラリ(libgfs_hook.so)の利用について、
具体的な利用が分からなかったのですが、
glibc-not-hidden パッケージをインストールし、
以下の環境変数を設定しておけばよろしいでしょうか?
LD_PRELOAD=/usr/lib/libgfs_hook.so.0
/usr/lib/gfarm/libpthread-not-hidden.so /usr/lib/gfarm/libc-not-hidden.so

gfq.shへのPATHを通した後に、以下のように教えて頂いた方法で実行してみたの
ですが、
エラーが表示されて止まってしまいます。

[yamamoto@node2 ~]$ gfq.sh gfarm:geotail_1month.cdf gfrun
gfarm:geotail.exe gfarm:geotail_1month.cdf -20 -10 -10 10 -10 10
: bad interpreter: No such file or directory

上記のコマンド例と教えて頂いたコマンドの対応は以下のとおりです。
gfq.shの使用方法に問題がありましたら、すみませんがご教示のほどよろしくお
願いします。

file -> gfarm:geotail_1month.cdf (1ヶ月の観測データを1つのGfarmファ
イルにインポートしたもの)
cmd -> gfrun
arg -> gfarm:geotail.exe gfarm:geotail_1month.cdf -20 -10 -10 10 -10 10
(左から、並列分散処理する実行ファイル、実行ファイルで読み込むGfarmファ
イル、プログラム中で使用する引数6つ)

>次に,質問2に関してです.
>
>スプールディレクトリを NFS 上に設定することは可能は可能ですが,一般的に
>は,それぞれのファイルシステムノードのスプールディレクトリは別々のディ
>レクトリにする必要があります.ファイル複製を絶対に作成しない,というの
>であれば,ディレクトリを分けなくても動作しますが,なにかのきっかけでファ
>イル複製を作成してしまったときにファイルを失ってしまうと思います.また,
>いずれにしても他のファイルシステムノードが担当するファイルをアクセスす
>るのに,NFS のオーバヘッドに,Gfarm のオーバヘッドが加わってしまうため,
>オトクではありません.
>
>  
>
この件について質問させて頂きましたのは、
Gfarmの可能性として、
NFSでファイルシステムノードのスプールディレクトリを共有することにより、
フラグメントのファイルも共有され、
通信のトラフィックは生じるが
リプリケートせずとも全ノードにファイル複製されているような状態が
仮想的に作り出せるのではないかと思ったからなのですが、
このようなことは可能でしょうか?

gfwhereコマンドに見られるように、
フラグメントの識別番号とホストが対になってメタデータに格納されているので
しょうか?
もし、そうであれば物理的には同じディスクにフラグメントのファイルが存在し
ても、
メタデータサーバではそのように管理されておらず、
リプリケートした際にもともとあるフラグメントのファイルを上書きすることに
なるのでしょうか?
また、そうだとした場合に、ファイル自体は存在しますので動作上は問題はない
でしょうか?

また、リプリケート機能についてもお聞きしたいのですが、
この機能を使用した場合、
一度目の処理はリプリケートする時間がかかるが、
二度目からはローカルディスクに存在するので処理が短縮できるという考えでよ
ろしいでしょうか?

このような場合に、膨大な数のセグメントからなるGfarmファイルを並列分散処
理しようとした際に、
・2度目の処理もリプリケートされたノードで行われ保証はあるのか?
・この方法では、ローカルI/Oでの処理を可能とする代わりに、
 最終的には全ノードにファイルが複製される(ディスク容量を必要とする)こ
とになるのか?
といった点が気になるのですが、如何でしょうか?

>恐らく,今回期待されているような動作のためには,ファイルを作成した=全
>ノードにファイル複製が作成された,というような動作にすればよいように思
>います.そのように Gfarm を修正することは容易ですので,必要であればパッ
>チを送付します.
># ちなみに,この場合,ファイルアクセスに関して Gfarm のオーバヘッドは
># 殆んど無視できると思います.
>
>ただ,ファイルアクセス性能がその共有されているファイルシステムの性能に
>おさえられてしまいスケールしない,という点はご了承ください.
>  
>
文章が長々となってしまい申し訳ございませんが、
よろしくお願いいたします。

>建部@筑波大
>
>  
>
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
山本 和憲  Kazunori YAMAMOTO
yamamoto@xxxxxxxxxxxxxxxxxxxxxxx
愛媛大学大学院 理工学研究科 電子情報工学専攻
応用情報工学講座 情報ネットワーク分野
http://www.infonet.cite.ehime-u.ac.jp/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~