PlanetLab

2011年07月17日

PlanetLabのイケてない部分として
・仮想化がVServerなので変更できない箇所が出てくる
・どのPort番号が使えるのかわからない
という点がありました。

IPv6に対応させて、Sliverごとに固有のIPを割り当てて解決しようという
試みもあるのですが
・割り当てるIPv6アドレスをどうやって決めるか
・そもそも/128あればいいのか
といった検討課題が残っています。

これを、仮想化技術をKVMに置き換えれば解決できるんじゃないかと
思っていたのでメモがてら書いてみる。
ちなみに2番については大して考えてません(

KVMって?


Kernel based Virtual Machine。
Linuxでサポートしている仮想化技術です。
VTとか、ハードウェア側での対応が必要です。
でもなんか非対応CPUでも動かすためのモードがあるそうな

Kerboard Video Mouseと混同しやすいのが一番の問題←

KVMでやることで
・listenする番号の重複回避
・Kernelの変更
といったことができます。

んで割り当てるIPv6アドレスをどうやって決めるかという問題ですが
IPv6では、MacアドレスをベースにIPv6アドレスを生成することができるのでこれを利用します。
KVMだと、使用するMacアドレスを自分で決められるので
SliverごとにMacアドレスを決めて割り当てれば
そのままIPv6アドレスを決められるわけです。

Macアドレスをどうするのかという問題は残りますけどね。
PLC側での管理が必要になりますね。

後、そんな風に自動生成されたIPv6アドレスに対して
DNS用の名前を割り当てる仕組みも欲しいところですね。
.<元々のhost名>みたいに。

あと、KVMだとマイグレーションもできますね。


なんてことを1年くらい前に考えていたんですが



既にCoreLabというPlanetLabの発展版がありましたとさ\(^o^)/
そっちはKVMベース。まぁ考えることは同じですよねー。
CoreLab自体はまだPLCとかを公開する段階ではないらしいですが
今後が気になるところです。


nanodayo at 18:09コメント(3)トラックバック(0) 

2011年04月02日

PlanetLabでは、VServerを用いて
仮想的に1人の実験者が1台のOSを使っているように見せかけています。

chrootをベースにしているので
大元のkernelの設定やネットワークの設定は共有しています。
なので、他の実験のトラフィックを覗いたりできるんじゃないかと思えますが
見えないようにするための仕組みが備わっています。

sliverが使用しているトラフィックを適切に渡すのが、VNETという仕組みです。
開いているPort番号を元に、対応するSliverへディスパッチしていますが
Port番号を使わないicmpとか、GREにも対応しているみたいです。
他にもロギングのために使われたり
tcpdumpしたときに、他のsliverのパケットを拾わないようにするといった機能もあるようです。
後はいわゆるダークネットのトラフィックを受信するための機能もあるそうで
同一セグメント内で、使われていないIP宛のトラフィックを受信したりもできるそうです。

APIは既存のLinux Socket APIと互換性があるそうで
既存のネットワークアプリケーションもそのまま動かせます。

Port番号の問題


PLノードのやり方だと、落とし穴があって
他の実験者が使っているPort番号を使えません。

これが結構な曲者です。
サービスのPort番号なんて、適当な値を使えばいいのですが
いちいち確認しないといけません。
おまけにプロセス空間を区切っているせいか
netstatとかしても見えないし


\(^o^)/

PlanetLab側では、IPv6に対応させることで解決を図っています。
Sliverごとに、専用のIPv6アドレスを割り当ててやれば
そのアドレス+port番号という形で、Sliverごとに違うソケットが使えるようになるそうな。

で、どの程度の空間を割り当てればいいのかという議論もされてるそうです。
・・・結構前から(

IPv6対応版自体は出ていますが
単にIPv6が有効なだけでSliverへの割り当て等はやってないようです。



nanodayo at 11:53コメント(0)トラックバック(0) 

2011年01月26日

今回紹介するのはCoDeployです。
Codeployは、複数のPCに対して
同じファイルを配布するためのツールです。
また同じコマンドを実行させたりできるプログラムも含まれています。

用途としては、同じ設定ファイルを持つ分散環境を構築するとか
P2Pみたいなアプリケーションのテストをするとかですね。

PlanetLab向けのツールですが
単にSSH/SCPを使っているところもあるので
SSHの設定(公開鍵の配置)をしてある環境なら同じように使えます。

入手方法


CoDeployのページからダウンロードできます。
公式はこちら

ダウンロード・インストール・設定


公式からダウンロードして解凍、makeします。
ここでは省略していますがsolarisの場合は
solaris用のmakeファイル(中に入っている)でmakeします。
# wget http://codeen.cs.princeton.edu/codeploy/codeploy.tar.gz
# tar zxf codeploy.tar.gz
# cd codeploy
# make
# echo "StrictHostKeyChecking no" >> ~/.ssh/config

最後のはSSH自体の設定です。
SSHでは初めて接続するホストの鍵を登録するかどうか聞かれます。
しかし100台分とか聞かれるとしんどいので
このオプションで聞かないように設定します。

CoDeployは設定ファイルは必要ないのですが、
環境変数を設定する必要があります。
MQ_NODESがノードのリスト(を書いたファイル)で、MQ_SLICEはユーザ名です。
PlanetLabでの使用を想定しているので、変数名がこのようなになっています。
#!/bin/bash
export MQ_NODES='/home/user/nodes.txt'
export MQ_SLICE='user'

これを予めファイルにしておいて
# source ~/.codeploy.env

とかして読み込ませてやると楽です。

/home/user/nodes.txtは、単にIPアドレスのリストを書いておけばOKです。
192.168.0.1
192.168.0.2
192.168.0.3

また各ホストにログインする際の、SSHのパスフレーズを省略するために
ssh-agentも実行しておきます。
eval `ssh-agent`
ssh-add

codeploy


CoDeeNを使用して、各ホストにファイルを転送します。
CoDeeNというのは、PlanetLab上に展開されているCDNサービスです。
CoDeeNについての細かいことはまたそのうち。

codeployコマンドを使う場合は、実行するホストが
Webサーバとして動作している必要があります。

使い方は
codeploy ~/public_html/file http://www.example.edu/~tupac/file test

こんな感じで、~/public_html/に配布したいファイルがあります。
~/public_html/がWebサーバとして公開するファイルを置く場所でもあって、http://www.example.edu/~tupac/fileとして外からアクセスできる状態です。
最後のtestは、コピー先のホストのディレクトリ名です。

-aとか付けるとtarで圧縮とかもしてくれるそうです。

大きなファイルの転送には適しているのですが
小さなファイルを転送するだけだと、ちょっと大げさだったり
下準備が面倒な印象があります。
そこで、もうちょっとシンプルなmulticopyというプログラムも付属しています。

multicopy


各ノードへファイルを転送します。
codeployの簡易版みたいなもので、単純にscpでコピーしています。
multicopy ファイル名 @:転送先ディレクトリ

@はそれぞれのセッションでの、相手のIPアドレスに変換されると考えていいようです。

反対に、各ノードからファイルを転送してもらうには
multicopy @:ディレクトリ名 @

ファイルの名前はIPアドレスになります。

multiquery


リストに書かれたノード全てにコマンドを実行させます。
内部的にはSSHを使っています。
# multiquery コマンド

結果がそのまま標準出力に出てきます。
一応、どのホストで実行した結果なのかも表示されます。

実行させるグループを小分けにする


ちょっと難しい。\(^o^)/
ファイルをグループ毎に用意して、環境変数を設定しなおす必要がある。

ユーザ名が異なるノードを同時に使いたい


指定方法上、無理です。

このあたりはpsshなら対応しています。


nanodayo at 22:34コメント(4)トラックバック(0) 

2010年12月01日


PlanetLabの、実験用ノードで使われている技術についてです。
※PlanetLabノードとかだと長いので、単にPLノードと表記しています。

前回のおさらい


  1. PLノードはsshでログインして使う
  2. 複数人で同時に使える

2番目はちょっとだけ触れましたね。
PLノードは、複数人で同時に使えるようになっています。
で、そのためのメカニズムとして、各PLノードで仮想マシンを起動して、実験者に割り当てています。

Slice/Sliver


用語の説明です。
Sliceというのは、実験者に割り当てられたリソースの集合と定義されていて
Sliverというのは、Sliceが1台のノードに割り当てられた単位です。

「正直に言おう、さっぱりわからない」

ですよねー\(^o^)/

もうちょっと実際の物に即して説明すると
SliverはPLノード上で起動している仮想マシンを指していて
Sliceは実験者のアカウントを意味しています。

※厳密にはSlice/Sliverという概念があって、実現方法としてユーザアカウントやら仮想マシンやらがあるのかもですが。

仮想マシン


さて、ここで仮想化技術の話です。
最近だらし・・・最近ホットな話題ですよね。
KVMとか、xenとか、VMWareとか。



PLノードで使っているのは、どれでもなくてVServerです。

VServer


VServerは正しくはLinux Virtual Serverという名前だったかな。まぁいい。

ハードウェアの仮想化とかよりもっと単純な仕組みで
chrootを使って、ユーザに提供するスペースを区切っています。

chrootって何?


これ説明要るのかなぁ…

ファイルシステムにおける、トップ階層の位置を変えるコマンドです。
Linuxのファイルシステムだと、こんな風に階層構造で区切られています。

/
/bin
/usr
/usr/bin/

でこれで例えば/vserver/nanodayoとか、/vserver/nanodayo/bin/なんてディレクトリを作って、
/vserver/nanodayo/にchrootすると、/vserver/nanodayo/bin//binとして扱われるわけです。

chrootした後の/binは、実際には/vserver/nanodayo/bin/です。
なので実験用のプログラムとかを入れても、他の実験者や大元のPLノードのシステムに影響を与えません。

/vserver/nanodayo/と同じノリで/vserver/donaldとか作れば、他の実験者用のスペースが確保できるわけです。
こんな風にファイルシステムのスペースを区切って、同時に使えるようにしています。

他にはプロセス空間なんかも区切られています。

VServerによる不都合


仮想化といっても、ファイルスペースとプロセス空間を区切っているだけです。
なので、カーネルとかは共有しています。

そうなると
  1. IPアドレスやルーティングテーブルは変更できない
  2. カーネルに変更を加える実験ができない

などなど、大元のノードの管理者権限が必要になるような操作はできません。
むしろできたらPlanetLabの中の人が困りますからね。
実験上どうしても必要な処理などを、例外的に許可するための仕組みとしてvsysというのもあるみたいです。

他には一人の実験者がリソースをバカ食いしないように、Sliverごとに、資源の上限が定められていたりもします。

VServerであるメリット


軽いらしいです。
そりゃあまぁ、単なるPCに複数人でログインするくらいの負荷でしょうしね。

後は、実験者の操作を制限することで
実験環境の管理運用に必要な機能を、ちゃんと守れるということでしょうか。
単なる副産物だと思いますが





他にもネットワークに関する技術などありますが
ネットワーク編ということでまた今度にでも。

nanodayo at 01:52コメント(2)トラックバック(0) 

2010年11月26日


PlanetLabに関する研究をしていたので、紹介してみる。
公式サイトはこちら
大学とか企業からPCを出し合って、みんなで使える実験環境を作るプロジェクトであり、テストベッドです。

OSは専用のもの(Fedoraベース)がインストールされているので、広義のPaaS。
ただし利用するPCは自分で選ぶので、クラウドらしさはない。
規模としては、現在1138台が提供されていて、参加している組織の数は520です。

用途とか


広域に分散配置されたPCが使える点が特徴です。
日本-アメリカ間のスループットを計測してみるとかトラフィックを計測して自分の学校以外の傾向を見てみるといったことが出来ます。

またPlanetLabノード自体はインターネットに直接繋がっています。
なのでPlanetLabとは何の関係もない、インターネット上の他のホストと通信できます。
「実験環境なのに外と繋がっていていいの?」とか思うんですけど、そうなっているんだから仕方ない。
なので既存のサービスを利用しつつ実験したり、βテスト的にサービスを公開する場として使うことが出来ます。
たまに間違えてDDoSまがいなこともしちゃいます。てへっ☆

利用方法


最初に言っておく!
PlanetLabを使えるのは、PCを提供している組織の人間だけだ!

\(^o^)/
ちなみにうちは提供している組織の人間です(

とまあちょっと敷居が高いので、マシンを提供しなくてもお試しで使えるPlanetLabといったプロジェクトもあります。
・・・昔はPlanetLab Japanがそうだったんですが、今はもう参加組織だけに閉じちゃっているのかな。

ちなみに参加組織の人間であれば、こんな感じになります。

  1. フォームに沿ってアカウントを申請する
  2. 自分の組織のPlanetLab管理者にメールが行くので承認を待つ
  3. 承認後、アカウントが発行される
  4. 発行されたアカウントでPlanetLabのWebサイトにログインする
  5. SSHの公開鍵を登録する
  6. 秘密鍵を使いSSHでログインする
  7. 実験開始


出来ないこと


PlanetLabのPCは、インターネットに接続している前提で、複数人が同時に利用する可能性があります。
勝手にIPアドレスとかを変えられると突然使えなくなるので、実験者がIPアドレスの変更などを行えないようになっています。
このあたりは実はVServerの仮想マシンが割り当てられているからとか、実装上の理由や仕組みもあるのですが今回は割愛します。
同じような理由で、root権限が必要な操作は原則できません。

コンセプト


コンセプトとしては、新しいサービスの開発者と利用者の両方を支援しようということらしいです。
また設計思想としては、オーバレイ・インターネットとでも言うべきな概念があります。
インターネット自身はそのままで、新しいインターネットを覆い被せて作ろうとか
インターネットに新しい機能を追加していこうとか。

まとめ


とりあえず今回は概要だけです。
実装等については次回以降書きます。

nanodayo at 22:38コメント(2)トラックバック(0)