ワタナベのブログ

自宅のサーバ環境の稼働状況を監視するツールを仕込みました。

監視ツールというと大御所は MRTG(Multi Router Traffic Grapher)というもので、SNMPエージェントから取得したデータを加工し、画像としてグラフを生成します。

サンプル画像

いろいろできる分、設定項目が多く導入が面倒(らしいです)。
そこで、cacti (カクチ)という RRDToolフロントエンドを採用してみました。cacti は、

* 監視機器やインタフェースの追加・変更が非常に簡単
* 過去のグラフを参照出来る
* グラフを分類して表示可能 (ツリー表示、一覧表示など)
* グラフタイトルが簡単に編集可能
* ユーザ管理が可能
* テンプレートを使用して、様々なグラフが追加可能

といった特徴を備え、ビジュアル的にもグッドです。

仮想環境が増えていったときに、それぞれの環境がどういう状態にあるのかを把握することはとても重要になってきます。このようなツールを用いると一目で状況が把握できて有効だと思います。

いままで、というかネットでIntel VTを調べるとVanderpool TechnologyだったりVirtualization Technologyだったり、「いったいどっちなの？」と思っていましたが、Vanderpoolのほうは開発コード名で、今回のIDFで正式に発表された名前がVirtualizationのほうらしいです。

省略してしまうと、開発コード名も正式名称も同じになってしまって混乱の元。
いや、むしろいろんなところに Intel VT で露出していて浸透していたから、正式名称で変わってしまわないように、敢えてあらかじめ同じになりそうな開発コード名にしたのかも。

以上、どうでもいい話でした。

一応、再整理しておきます。
仮想化技術と一口に言っても、実にさまざまな種類があります。

それは「何を仮想化」するかによっては、ある領域ではずいぶん昔から存在していました。たとえば、メインフレームの論理パーティショニング機能だったり、CPUであれば対称型マルチプロセッサ(SMP: Symmetric Multiple Processor)、ディスクであればRAID(Redundant Arrays of Inexpensive Disks)、SAN(Storage Area Network)など。

そして最近特に話題となっている Xen ですが、
これは仮想マシンを作り出す種類のソフトウェアです。
つまり、ホストOSの上に、仮想的なコンピュータを作り出す技術です。製品ではVMWareやVirtual PCが有名ですね。
オープンソース系であれば、Bochs、QEMUなど。これらはPCエミュレータと言われることもありますが、ホストOS上に独立したマシン環境を作って、その上に任意(※)のOS(ゲストOS)をインストール出来るといういみでは仮想マシンといってよいと思います。

（※といってもサポートされるOSに限りがありますが）

以前ご紹介した coLinux は、仮想OS といって、Windows(ホストOS)上に、ゲストOSとして独立したLinuxを起動します。

まとめると、

仮想マシン：再現できるもの ＝ 仮想的なマシン ＋ 任意のOS環境
仮想ＯＳ　：再現できるもの ＝ 仮想的なOS環境 (固定的)

ということですね。

仮想マシンの実現方法にもいろいろトレンドというか、本命が出てきています。
それが、Xen が採用している仕組みである、仮想マシンモニタ方式です。この方式を表している言葉としては、VMM(Virtual Machine Monitor) や Hypervisor というのが聞かれます。

この仮想マシンモニタ方式は、物理的なハードウェアに一番近いところで複数のゲスト環境の調停を行うので、CPUの命令を変換しながら実行したり、ホストOSのデバイス制御のレイヤを経由することも無いためパフォーマンス的に有利だという特徴があります。
また、同時にゲスト環境間の独立性、ホスト環境とゲスト環境の間の独立性も高く保たれ、セキュリティの考慮が必要な場合にも良い方式であるといえます。

ただし、仮想マシンといっても完全に物理ハードウェアではないのでゲストOS(のカーネル)側に多少の対応が必要です。Xen 2.0 までは、Xen上で実行するための専用カーネルが必要でした。これに迅速に対応できたのは、やはりLinuxやFreeBSDなどのオープンソース系のカーネルです。

しかし、Xenや仮想環境の可能性に注目している大手ベンダが増えていき、Intelも仮想化技術(Intel VT)をCPUに取り入れてきました。これに対応した Xen 3.0からはカーネルによる特別な対応が無くても、ゲストOSとしてさまざまなOSが動くようになっていて、WindowsもXenの上で動いたことが各所から報告されています。

というわけで、Xenはこれからも目が離せない重要なソフトウェアとなっています。

今日のハマリ。

Rinza Software FamilyのうちいくつかのソフトウェアはSubversionというバージョン管理システムで管理しているのですが、いろんなプロジェクトがひとつのSubversionリポジトリに混在していたので、１プロジェクト１リポジトリとなるように再構成しました。

手順としては、ここにあるように svnadmin dump した論理形式の
リポジトリをsvndumpfilterを使って、いらないディレクトリを消していきます。

repoX --> projectA
　　　|
　　　+-> projectB
　　　|
　　　+-> projectC

という感じ。
で、最終的には分割された複数の論理形式を svnadmin load します。

load が完了したら、正しくチェックアウトできるかを確認。

svn co file:///srv/svn/repo-projectA
svn co file:///srv/svn/repo-projectB
svn co file:///srv/svn/repo-projectC

よしOK。
ということで再び Apache 経由で参照できるように httpd.conf を書き換え。
以前からApacheを経由して WebDAV プロトコルでリポジトリにアクセスしていたので

以前： http://hostname/repoX/projectA
今回： http://hostname/projectA

という感じでURLが変わります。

複数のリポジトリが /srv/svn にできたので便利な方法があります。

SVNParentPath /srv/svn

これをやると個別にリポジトリのパスを SVNPath で指定する
(Location ディレクティブをリポジトリの数だけ書かないといけない)
ところを、親ディレクトリだけの指定で配下のリポジトリをすべて
公開することができます。

ということで、

引用：

などとやってすんなりと移行完了。
Webブラウザから http://hostname/porjectA を参照すると確かにリポジトリの内容が見えます。

ここでやめておけばよかったのですが、せっかくなので Trac という Wiki + Bugトラッキング + Subversionリポジトリブラウザ なんてのをいれてみました。開発プロジェクトのポータルのような感覚で利用でき、オープンソースの開発プロジェクトで最近よく見かけます。

trac

trac を置くURLをLocationで作り出すのですが、svnリポジトリではURLをルート( / )にしていて同じく Location で指定しているので、Location の設定がバッティングしてしまい、うまく表示してくれません。

いろいろ試行錯誤の結果、svnのほうをDirectoryディレクティブで指定し、DocumentRoot でsvnのリポジトリを含むディレクトリを指定したら、めでたく両方の指定が有効になりました。

引用：

Webブラウザで http://hostname/porjectA と http://hostname/trac/porjectA を確認することができました。

しかし、ここからハマリが始まります。

ブラウザで確かにリポジトリが見えるのに、なぜか svn コマンドからはチェックアウトできなくなってしまいました。
いろいろ試してもダメ。

もうあきらめかけてた頃に以下のサイトを見つけて終了。

http://www.hinet.mydns.jp/~hiraku/tDiary/20050317.html

というわけで DocumentRoot が原因でした。

産総研のグリッド研究センターが分散ハッシュ表 (DHT) などを使ってオーバレイネットワークを簡単に構築できるツールキット Overlay Weaver を発表しました。

http://overlayweaver.sourceforge.net/

オーバレイネットワークとは、例えばSkypeなどのアプリケーション・ソフトウェアが自らの処理を効率的に流すために、インターネットなどの物理ネットワークの上に構成した独自のネットワークのことを指します。

主にP2Pの研究のなかで使われている用語ですが、(下位)ネットワークの上に被せて(オーバレイ)構築された別の論理的なトポロジを持ったネットワークのことを総称して一般的に使われているようです。

Overlay Weaver は、DHTのいくつかの代表的なアルゴリズム Chord、Kademlia、Pastry、Tapestry の実装を提供しています。ルーティングアルゴリズムとして抽象化されているので、アプリケーションから切り替えて利用することができます。

また、一台のマシン内で数千ノードのP2Pノードをシミュレートして、メッセージの流れを視覚的に確認するツールも同梱されているので、アプリケーションの処理に最適なルーティングアルゴリズムを、シミュレータで確認しながら容易に選択することができます。

これから P2Pソフトウェア、分散型アプリケーションを研究しようとする方には最適なツールキットではないでしょうか。

開発は同センターの首藤さんらが行っているようです。

P2PやDHTについては、首藤さんのウェブサイト http://www.shudo.net/ や http://toremoro.tea-nifty.com/tomos_hotline/ が参考になります。

大規模配信に利用できないかなぁ。

トラックバックスパムですか。。
ブログサービス各社も対応に追われているようですね。

アメーバブログ運営局　スタッフブログ：スパムトラックバック対応のお知らせ
http://ameblo.jp/staff/entry-10007101704.html

livedoor Blog ：トラックバックスパム防止策導入について
http://blog.livedoor.jp/staff/archives/50302411.html

トラックバック（以下、ＴＢ) 元のＵＲＬやＩＰをBlack Listに登録して弾くといった方法が手っ取り早そうですが、リストをメンテナンスしようと思うと大変です。やはり、satoさんのおっしゃるとおり、ＴＢがスパムかどうか判別するにはＴＢ元のページを取得して、判別するのがよさそうです。

Livedoor Blog では、上記の記事のように元記事にＴＢ先のURLが含まれていない場合はＴＢを拒否するという方法が採られるようです。
ＴＢするときは、記事内にＴＢ先への参照を書くのが普通ですから、チェックの負荷とチェックの確かさの観点ではＧｏｏｄな方法だと思います。

でも、ここはやはり技術で解決。

ということで、スパムといえばスパムメールフィルタの仕組みとして効果をあげているベイジアンネット。
ＴＢ ｐｉｎｇを受けたら、送信元の記事を取得して、ベイジアンでちょちょいのちょいっ、とチェックできないでしょうか。

＃ と言って詳しい人の登場を待ってみる．．．

Skype APIをJavaのクラスライブラリとしてラップする試みが進んでいます。
http://skype.sourceforge.jp/

引用：

ということで、Hunterと連携させてみようかな。
Google Talks の APIもリリースされていますし、IMやIP Phoneの普及度がたかっくなっている中、人々にリーチする手段としてひとつの大きなドメインを作りそうです。

■ Google TalkのAPIとソースコードのリリース
http://japan.linux.com/desktop/06/01/16/0225204.shtml?topic=1

１件のデータは少量ながら５００万のあて先に一斉に配信したい場合、みなさんならどのようなシステム構成を考えますか？

1件1件の配信はメールだったりFAXだったりと、すべてが同じ配信方法でなく（数種類）、送信先ユーザの設定に応じて配信する or しないを判断して配信します。

単純にシリアルで処理すると、１件の配信（データの加工、送信先の取得、送信処理）を１ミリ秒で捌いたとしても、５００万件では ５０００秒 ≒ ８３分掛かってしまいます。

そうすると何とかして多重度を上げて並列に捌くしかありません。
１サーバで仮に１００件すべてを１ミリ秒で捌いたとしても５０秒掛かります。そうすると５０台並べれば１秒ですべて送れるか...
どちらも簡単には出来そうにありません。

アプローチとしては、

・１サーバ内での多重度を上げる
　ー 出来ることは事前にやっておく（TRXごとに可変な部分を極力排除）
　? 同じ計算はまとめて１回にする
　? すべてメモリ上で行う
　? リアルタイム性の求められない処理(ログの書き込みなど)は非同期で実施

・サーバを増やす（スケールアウト）
　? 同一構造で横一線並べる
　? 階層構造にして、配信先ごと／配信手段ごとに分配していく

などが考えられますが、並列化の手法、並列化の際に気をつけないといけないこと、なんでもかまいません。お知恵拝借したく。

＃ 最近はいろいろ手をつけていて、自分が何をメインテーマに
＃ しているのか分からなくなってきています。でもそれぞれ面白い。
＃ そしてまた、ハマっていく...

今日のハマリどころ。

FreeBSD環境でMySQLを稼動しています。
そしてWebアプリケーションからのJDBCアクセス時に文字化け。

Webアプリの文字コード SJIS です。
フォーム送信後のページには正しく表示される（セッションに載っている文字列は正常）のですが、DBに書き込んだ文字列を再表示しようとすると化けます。なので、よくあるフォームの送信の際の文字化けではなく、DBとのエンコーディングが合っていないことが分かります。

通常はJDBCの接続パラメータである URL に

jdbc:mysql://localhost/test?useUnicode=true&characterEncoding=Shift_JIS

のようにエンコーディングを指定すれば万事OKなのですが...
Shift_JIS、EUC-JP、sjis、ujis とどれを指定してもエラーメッセージが表示され、接続に失敗してしまいます。

＃ 作業しているターミナルが日本語表示できず、
＃ エラーメッセージが読み取れないのが痛いところです

サーバのデフォルトのエンコーディングを調べてみると、
引用：

やっぱり。

デフォルトのエンコーディングが utf8 になっています。
これでは多バイト文字の扱いに問題が生じます。

これに対応する手っ取り早い策は default-character-set を
設定して、mysqldを再起動することです。

しかし、、、

引用：

なんと sjis、ujis ともサポートしている言語に入っていません。
＃ 先ほどのエラーメッセージの理由がなんとなく分かりました。

結局 utf8 でDBを統一することに決め、
my.cnf をいじるのも面倒なので以下のように起動しました。

/usr/local/bin/mysqld_safe --default-character-set=utf8 &

あとはJDBCのパラメータを調整して

jdbc:mysql://localhost/test?useUnicode=true

すべて解決しました。
デフォルトで utf8 にしておいて欲しい。。。

以前 Xen を導入してみようと言うことで、やりだそうとしたのですが、２年位前に一度触ったことのある coLinux (Cooperative Linux)というWindows上で動作する仮想Linuxをまずは試してみようと思います。

仮想環境といってもゲストとなる環境のセットアップまでできれば、あとは通常のPCとほとんど変わりませんから、基本的にはどんな仮想化技術を使ってもやりたいことはできそうです。

まずは、coLinuxのインストールを済ませ、ゲスト環境としてDebian環境を構築。
あらかじめいくつかのディストリビューションのイメージファイルが配布されているので、coLinuxのダウンロードからゲストを立ち上げるまでには１時間もかかりませんでした。

国内ではERROR STORMが情報豊富です。手元のWindowsマシンでLinuxマシンがもう一台、手軽に用意できるので、ちょっとLinux環境がほしいという方、お勧めです。

RDFに関する豊富な情報源、kanzaki.com にて、RDFの使い方に関する考察が述べられています。

・セマンティック・ウェブとWeb2.0が出会うところ
・RDFとRDBMSの共存関係
・セマンティック・ウェブ、あるいはルーズさを生かした構造

Rinza RDF Repository が目指しているところのものがまた近く感じられました。

RDFによるデータ表現。
SPARQLによるデータ検索とサービス連携。
そして、Web as Platform。

なんかいろいろ繋がってきました。

情報システムは社会経済活動を支える重要なインフラとなっており、企業の活動ばかりでなく、個人の活動も情報システムに大きく依存しています。

一方で、災害や事故の発生に対する情報システムの危機管理が十分に追いついていないと言わざるを得ません。災害時の復旧についてはこれまでも取り組まれてきていて、いわゆるディザスタリカバリといいます。それらについて備えるべき要件は認知されつつあります。

そんななかで最近注目されている技術として、システムの仮想化技術というのがあります。

いままではサーバ(システム)とハードウェア(H/W)は一対一で対応していたのですが、仮想化技術を使うことでシステムをH/Wから分離し、特定のH/W環境に縛られないシステム稼働環境を作り上げることができます。

仮想化技術というと、VMWare、User Mode Linux(UML) などなど製品からオープンソースソフトウェアまで新旧さまざまなものがありますが、そのなかでも最近特に話題となっているのはXenというアーキテクチャです。もともとUniversity of Cambridge で研究されてきたものですが、オープンソースコミュニティで注目度があがっているばかりでなく、IBM、Sun Microsystems、Hewlett-Packard(HP)、Novell、Red Hat、Intel、Advanced Micro Devices（AMD）、Voltaireといった名だたる大手企業もサポートを表明しています。

ということで、習うより慣れろ。
Xenの導入を計画しております。
＃ どなたか一緒にチャレンジする方いませんか？