2011年01月

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) 
PlanetLab | テストベッド

2011年01月20日

2011/01/20 12:34:24 @ インドダイニング シャルマ 金沢フォーラス店

インドダイニング シャルマ 金沢フォーラス店にタッチ!

住所:石川県金沢市堀川新町3-1 金沢フォーラス 6F



nanodayo at 12:34 
ライフログ | ロケタッチ

2011年01月19日

2011/01/19 15:31:44 @ penelope

penelopeにタッチ!

住所:東京都新宿区



nanodayo at 15:31 
ライフログ | ロケタッチ

2011年01月18日

分散オブジェクトストレージ。
要するにファイル置き場です。
類似のサービスとしてはFTPとかですが
大容量オンラインストレージという位置づけでは、AmazonS3が類似サービスです。

元々はRackspaceという会社がサービスしていた物ですが、
オープンソース版として提供されてます。

OpenStackがクラウド基盤ソフトウェアでして
その中のコンポーネントの1つがSwiftという位置づけです。

公式サイトはこちら
Swiftのページはこちら
日本語の情報もこの辺見たほうがいいんじゃないだろうか

構成


Swiftを構成するコンポーネントはこんな感じ。

  • Auth Server
    アカウントの管理と認証を行う。

  • Proxy Server
    ユーザからの利用窓口。
    適切なサーバにリクエストを転送する。
    転送先候補はRingファイルを元に決める。

  • Object Server
    オブジェクトを保存する。メタデータ対応。
    オブジェクト=ファイルという認識でいい模様。

  • Container Server
    定義上はオブジェクトのリストらしいです。
    ディレクトリと考えて良い様子。

  • Account Server
    コンテナほとんど同じだけど、コンテナのリストを扱うらしいです。
    なんのこっちゃという感じでしたが


URLの構造は
http://サーバ/~ユーザ名/フォルダ/ファイル

みたいになっているわけですが
Swiftの場合は
http://proxy/Account/Container/Object

という構造になっているようです。なるへそ。
コンテナはフォルダだから、中にはいってるオブジェクトのリストを持っていて
アカウントは、フォルダのフォルダだから中に入っているコンテナのリストを持っているわけですね。

メリット



Swiftのメリットとしては
まず複数台のサーバから構成できるので
・障害で何台か落ちてもサービスが続行できる
・負荷分散ができる
・大容量のストレージにできる
と、良くある分散システムのメリットもあるわけですが

Swiftならではのメリットとしては
負荷分散やら、増設やらで台数を増やす場合に楽だということです。
Swiftの場合は、Object ServerやらContainer Serverを増やすだけでサーバが増設できて
クライアントからはProxy Serverにアクセスするだけなので
変更があってもサービスの見た目(URLとか)が変わらないわけです。

そうなるとProxy Serverに負荷が集中するわけですが
Proxy Server自体を複数用意できるので
この点はカバーできます。

・・・といってもロードバランサやらDNSラウンドロビンやらを使うらしいので
従来のサービスとあんまり変わらなくなってくるのかな・・・?

nanodayo at 22:23コメント(1)トラックバック(0) 
swift 

2011年01月15日

2011/01/15 13:36:52 @ 鳥ふじ

鳥ふじにタッチ!

住所:東京都中央区日本橋茅場町3-4-6 本橋ビル2F



nanodayo at 13:36 
ライフログ | ロケタッチ