分散ハッシュテーブル（DHT)コミュのP2P OS って…

今日は新入生歓迎宴会だったのですが、
新Ｍ２の連中とお話していて…

僕「修論のテーマ決まったの？」
彼「今のところ P2P OS で行く話になってます」
僕「えぇぇぇ…P2P と OS の関連性は？」
彼「それが良くわかんないんですよね…僕にも」

と、何とも良く分からない会話になってしまいました。
単に僕の勉強不足かもしれませんが、
そういうアプローチをしている
研究アクティビティって存在してるんでしょうか？

ご存知の方はコメントお願いします。

PS　世の研究者がそういう下心を持ってても
　　おかしくないとは思うんだけど、
　　現時点で修士論文のテーマにはならないように
　　僕には思えてなりません。

コメント(10)

最初
全て
最新の40件

[1] mixiユーザー 04月14日 00:32

その学生さんはどこで「P2P OS」なる言葉を拾ってきたのかな？
それともオリジナル？

[2] mixiユーザー 04月14日 00:40

どうも指導教官の受け売りのような気が…思いつきの
セリフを真に受けたようにしか思えんのですが…謎？

[3] mixiユーザー 04月14日 00:53

P2P OSは、聞いたことはありません。しかし、
「どこからともなくブートするOS」
ではないかと思いました。こちらであれば、2004年度の未踏ソフトウェア創造事業で、採択されています。
http://www.ipa.go.jp/jinzai/esp/2004mito1/gaiyou/4-4.html

ITMediaの記事で、詳しく解説されております。
http://www.itmedia.co.jp/enterprise/articles/0504/14/news078.html

確か、去年の、UNIX Magazineの秋で何回かにわたって連載されたP2P特集の中に、詳細な解説があったと記憶しています。

基本的な発想はこうです。ディスクレスクライアントで、ネットワーク上のサーバーの領域を、ネットワーク越しにマウントしてブートする、ネットワークブートは、よく行われていますね。
ところが、この方法では、数百台のディスクレスクライアントが同時にブートするような事態（例えば、授業の開始時など）では、数百台のクライアントがいっせいにサーバーにアクセスしようとするので、サーバーに大きな負荷がかかります。
そこで、一台のサーバーからブートする代わりに、P2Pネットワークを介して、ブートするためのデータをとってきて、ブートしてやれば、負荷集中を避けることができる、という発想です。

一応、P2P OSで検索したところ、一件だけひっかかりました。
http://www.tom.sfc.keio.ac.jp/~hagino/it-program/it-concept2002b.ppt#6

[4] mixiユーザー 04月14日 01:01

こういうのかな？
http://www.ipa.go.jp/jinzai/esp/2004mito1/gaiyou/4-4.html

[5] mixiユーザー 04月14日 01:13

ほぉぉ…用語として使っておられる方はいらっしゃるんですね。
僕もその記事は読みましたが、確かにネットワーク・ブートの
負荷分散手段は現実的な提案ですよね。個人的にはちょっと
面白みには欠ける気がするけど…

まぁ、かつての分散OSのアイデアはP2Pをベースに考え直すと
いろいろ可能性が見えてくるわけですが…

分かりやすい例としては分散ファイルシステム。
CFS や Ivy の事例があるぐらいですから、
これは現実的なアプローチで「P2P OS」と居直ることが
できなくもない。が、今時、分散ファイルシステムを
分散 OS と言ってしまうのはちと無理があるかと…

タネンバウム先生の amoeba のアイデアもありかな？
これはファイル・サーバー＋CPUプールという
当時としてはムリムリな分散システムだったように
記憶してますが、capability だったかな？
所有者情報などを共有するための仕掛けは
P2Pを分散システムに活用する上での今後の課題の
解決を示唆するアイデアにも思えたりします。

それから分散OSといえばMachなんですが、
こいつには External Pager という荒業があって
Page Out しているコンテキストを別のノードで
Page In するというとんでもないことができました。
なのでP2Pに応用すればプロセスのコンテキストを
DHTに退避して、オーバレイネットワーク上のいずれの
ノードでも再活性化できるみたいなとんでもないことが
できる可能性があります。まぁ研究としては面白いけど、
セキュリティ問題が指摘されている昨今では危険極まりない
技術になりそうですが…

というわけで、、、

真面目に考えれば「P2P OS はアリ」だと
僕は思うのですが、少なくとも修士論文で扱うには
無理のあるボリュームの研究だと思ってます。

[6] mixiユーザー 04月14日 02:44

あ、やはり読んでいらっしゃったのですね。有名な記事だったので、おそらくチェックしておられるのではないかと思っておりました。

＞それから分散OSといえばMachなんですが、
＞こいつには External Pager という荒業があって
＞Page Out しているコンテキストを別のノードで
＞Page In するというとんでもないことができました。

はぁ～、それは面白いですね。なんというか・・・どのノードのどのプロセスのものでもない、共有プロセスができるということですか。

直接関係ないですが、東大の戦略ソフトウェアの研究で、n台のPCをn個のプロセッサがある一台のマシンに見せかけ、その上でLinuxを動かすというのがありましたが・・それを思い出しました。

＞真面目に考えれば「P2P OS はアリ」だと
僕は思うのですが、少なくとも修士論文で扱うには
無理のあるボリュームの研究だと思ってます。

そうですね。ボリューム的に無理でも、院進学が決まっている人の卒論ぐらいであれば、どうせどんなテーマでも、ボリュームが多すぎて本質的に新しいことをやるのは無理なのだから、やってみる、ということができるかもしれませんが・・・修士論文だと、そうはいかないですよね。

[8] mixiユーザー 04月14日 11:48

> りさん
>
> ＞それから分散OSといえばMachなんですが、
> ＞こいつには External Pager という荒業があって
> ＞Page Out しているコンテキストを別のノードで
> ＞Page In するというとんでもないことができました。
>
> はぁ～、それは面白いですね。なんというか・・・どのノードの
> どのプロセスのものでもない、共有プロセスができると
> いうことですか。

はい、オーバーレイ・ネットワークの中を
「プロセスが漂う」といったらよいですかね。
オーバーレイ・ネットワーク自体を
１つの仮想システムだと考えるということですが。

> pinkgear さん
>
> P2Pで分散ファイルシステムってのはすごく魅力的な
> 気がしますね。　P2PでGoogleFS的なシステムが誰でも
> 手軽構築できて、ついでに暇なノードにはCPUリソースを
> 分けてもらうなんて事が出来たら、誰でもGoogleと
> 同じ立ち位置に立てるのでウェブ屋的にはアプリケーション
> 開発に専念出来て幸せに、熾烈な競争の末より良いモノが
> 生まれてエンドユーザーも幸せに。

でも P2P を使った実用的な分散ファイルシステムの実現って
案外辛いのかなぁというのが、ここ半年くらいの実感です。
一言で言えば「遅い!!」ってことなんですが、
DHT が遅い理由はいろいろあって…

(1) underley network の性能に依存する
(2) ハッシュ関数のエンコーディング・コストが大きい
(3) オーバーレイ・ネットワークを維持する通信コストが大きい

とかがあるそうです。

こういう問題が絡み合って、ファイルシステムの
入出力性能に大きく響いてくるので、結果的に
「むっちゃ遅い」とか「性能を計測するたびに値が
大きく違う」とか…良く言えば「研究課題に事欠かない」、
悪く言えば「バカヤロー」みたいなのが現実かと
思ったりします。

[10] mixiユーザー 04月19日 13:28

> DHTxDFS(分散FS)については、P2P(UnstructuredP2P,DHT)の得意不得意は何かを自分なりに見極め、そのうえで、どういうものを作りたいのかという目標をしっかり定める事が、ポイントになると、私は考えています。
>
> 例えば、一般的なファイルシステムのセマンティクス({部分,全体}{書き込み,読み込み}ロックやアクセス権限、ディレクトリエントリキャッシュなどの扱い)を実現するためのベースとして単純にDHTを適用する事が得策なのかどうか。

そうですねー
Google File System にしても POSIX セマンティクスを追求するようなことはしないで、実利的に、(たしか) C++ のライブラリっていう割り切ったデザインになってたと記憶してます。

ログインすると、みんなのコメントがもっと見れるよ