タイトルどうり。せっかく契約したBBモバイルポイントがあまりにも不安定すぎるので
むしゃくしゃしてやった。それなりに安定して動いたので2chで配布した。今はビクビクしている。
ダウンロード(Ver 0.2 2009/09/01 更新)
Q:どんな場合に使えるの？
A:BBモバイルポイントで頻繁にログイン画面に飛ばされてしまうアクセスポイントの場合に有効です。
頻繁に無線自体が切断されてしまうアクセスポイントではこのソフトを使っても意味がありません。
使い方
①ActiveRubyのインストール(インストール済みの人は不要)
②接続バッチ.bat をメモ帳で開く
③ユーザー名とパスワード、アクセス先URLの箇所を編集する
(アクセス先URLで指定したURLに毎秒アクセスを行います。
空白にした場合にはデフォルト設定として毎秒私のサーバーにアクセスしにいきます。)
④保存して、接続バッチ.batを実行する。
プログラムがやっていること
毎秒、アクセス先URLにアクセスを行い
BBモバイルポイントに転送されたら、
プログラムが自動でログインを行うというもの。
ActiveRubyについて
ActiveRubyについては詳しく知りたい方は以下のURLを見てください
http://arton.hp.infoseek.co.jp/indexj.html
今後について
2009年8月時点では動作確認ができておりますが
BBモバイルポイントの契約を作者が止める予定なので、
その後の開発は継続できません。ご了承ください。
【仮想化】OpenVZが素晴らしすぎる件について
どうも。けいです。
現在サーバー復旧中です。
復旧ついでといっては何ですが、いくつかのお行儀の悪かったソフトウェアを
仮想環境で起動させるように変更しています。
以前まではパフォーマンスを重視していたため
VMWareやVirtualPCのような低速な仮想化からは大分距離を置いていたのですが
最近の仮想化は随分状況が異なってきているようです。
VMWareやVirtualPCを使っていたときは、大体３０％程度動作速度が落ちており、
メモリ・HDDの使用量もネイティブで動かすときよりも多めに見積もる必要がありました。
そのため、リソース的にはなかなか厳しいものがありました。
その後、Xenのような準仮想化が可能なソフトウェアが登場し、
仮想化の大本命と絶賛されたものです。
そして、近年OpenVZのようなOSレベルの仮想化ソフトウェアが注目されています。
私は使ってみるまではOpenVZのようなOSレベルの仮想化ソフトウェアには
懐疑的だったのですが、
OpenVZのことを、 chroot + jail にいくつかの規制を加えたものだというように説明されたときには
「・・・仕組み的にも最もシンプルだし、それでいいじゃん」と妙に納得してしまいました。
仮想化するメリットはいくつかありますが、多くの場合、OSレベルの仮想化で十分なはずです。
また、使い方次第では驚くような利点があることがわかります。
【従来の仮想化の問題点】
OpenVZは従来の仮想技術とは違い、複数の仮想OSを起動したとしても使用するカーネルは一つです。
これにより今までと何が変わるのかというと、
従来では仮想OSのカーネル+付随する環境自体がメモリを使ってしまうため、
仮想OSでありながら、複数のアプリケーションを仮想OS上で動かす場面が多くありました。
例えば従来の方法で以下のような仮想システムを組んだとします。
仮想OS１：カーネル+必要なプロセス&スワップ(200MB) + Apache(128MB) + Tomcat(256MB) + MySQL(256MB) = 合計840MB
仮想OS２：カーネル+必要なプロセス&スワップ(200MB) + メールサーバー(128MB) + DNSサーバー(32MB) = 合計360MB
この構成では仮想OS上のApacheが下品な落ち方をした場合（OSを巻き込んで落ちた場合）
TomcatやMySQLも使えなくなってしまいます。
よりよい構成を求めるならば、全てのアプリケーションを仮想OSに分けるべきです。
しかし、もし仮に分けた場合には、
カーネル+必要なプロセス&スワップ(200MB)がアプリケーションの数だけ必須となってしまうため
200MB * 5(アプリケーションの数)で合計、1000MB分もとられてしまうことになり、
アプリケーションが多くなればなるほどリソース的に圧迫されるものでした。
そのため、複数のアプリケーションを仮想環境で動かさなければならないという状況が
現実的には多かったのです。
また、見積上では仮想OS１のメモリ使用量は840MBとなっていますが、
実際には相当数のアクセスがない限り、これほど多くのメモリは使いません。
しかし、実際に仮想OSを作成する場合のメモリ使用量は何かあったときのために
多めに見積もっておくのが普通でしょう。
そして、従来の仮想化では仮想OSの840MBは占有されてしまい
ネイティブのOSのリソースがごっそりと取られてしまいます。
->OpenVZならばこれらの問題を解決することができます。
OSレベルでの仮想化であるため、「カーネル+必要なプロセス&スワップ」は
ほとんど無いに等しいからです。
試しに最低限の仮想OSを作成しプロセスを見てみました。
# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.2 1980 692 ? Ss 05:01 0:00 init [2]
root 342 0.0 0.2 1692 620 ? Ss 05:01 0:00 /sbin/syslogd
root 349 0.0 0.3 5272 1024 ? Ss 05:01 0:00 /usr/sbin/sshd
root 367 0.0 0.3 2036 876 ? Ss 05:01 0:00 /usr/sbin/cron
root 379 0.0 1.0 8016 2704 ? Ss 05:09 0:00 sshd: root@pts/0
root 381 0.0 0.5 2760 1492 pts/0 Ss 05:09 0:00 -bash
root 428 0.0 0.3 2296 896 pts/0 R+ 05:42 0:00 ps aux
initの次はもうサービスです。
最小限の環境ならば10MBもあれば十分でした。
#top
top - 05:46:49 up 45 min, 1 user, load average: 0.00, 0.00, 0.00
Tasks: 7 total, 1 running, 6 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 262144k total, 8940k used, 253204k free, 0k buffers
Swap: 0k total, 0k used, 0k free, 0k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 1980 692 592 S 0 0.3 0:00.00 init
342 root 20 0 1692 620 508 S 0 0.2 0:00.00 syslogd
349 root 20 0 5272 1024 668 S 0 0.4 0:00.02 sshd
367 root 20 0 2036 876 704 S 0 0.3 0:00.00 cron
379 root 20 0 8016 2704 2224 S 0 1.0 0:00.12 sshd
381 root 20 0 2760 1496 1184 S 0 0.6 0:00.00 bash
429 root 20 0 2256 1060 872 R 0 0.4 0:00.00 top
これだけリソースの消費が少なければ、
アプリケーションごとに仮想環境を割り当てることが十分可能です。
また、従来のように仮想環境に
メインOSのリソースがごっそり奪われるということはありません。
例えば、２Gのメモリが乗っているマシンに、
２Gのメモリを割り当てた仮想環境を複数起動したとしても
まったく問題なく動きます。
その他、ゾンビプロセス問題などが発生しても、アプリケーションごとに
システムが分かれているために、再起動もやりやすくなります。
ここまでいいことづくめで書いてきましたが、残念ながら
全てのアプリケーションが仮想化できるわけではありません。
仮想化できなかったソフトウェアもいくつかあります。
それは特定のデバイスの使用を前提に作成されたソフトウェアなどです。
例を挙げるなら、OpenVPNやAsteriskで使用するzaptelなどです。
/dev/ 以下の使用を前提としているため
OpenVPN だと /dev/net/tun が無ければ動作をすることができません。
そのため、私の環境ではいくつかのアプリケーションはメインOS上で動作させざるを得ませんでした。
理想としてはメインOSではSSH とOpenVZだけをサービスとして提供させたかったのですが、
致し方ないところですね。
※2009/09/13
一ヶ月以上使用してみたのだが、予想以上に特定のデバイスに依存しているソフトウェアが多い。
ハードが低速だった頃に作られたソフトウェアの多くが
「カーネルに組み込むことも出来るし、組み込まなくても動かせる」 という作りになっているため、
わざわざカーネルパラメータを取得しに行ってしまい、FATALエラーになるとか・・・
NFSやsambaのsmbfs, cifsなんかも、OpenVZ上で動かすのは手間であるし情報も少ないので、
OpenVZ上で動かす場合特有のトラブルを覚悟しなければなりません。
コメント(0)
2009.08.03
[
Myカテゴリ:技術の話
]
現在サーバー復旧中です。
復旧ついでといっては何ですが、いくつかのお行儀の悪かったソフトウェアを
仮想環境で起動させるように変更しています。
以前まではパフォーマンスを重視していたため
VMWareやVirtualPCのような低速な仮想化からは大分距離を置いていたのですが
最近の仮想化は随分状況が異なってきているようです。
VMWareやVirtualPCを使っていたときは、大体３０％程度動作速度が落ちており、
メモリ・HDDの使用量もネイティブで動かすときよりも多めに見積もる必要がありました。
そのため、リソース的にはなかなか厳しいものがありました。
その後、Xenのような準仮想化が可能なソフトウェアが登場し、
仮想化の大本命と絶賛されたものです。
そして、近年OpenVZのようなOSレベルの仮想化ソフトウェアが注目されています。
私は使ってみるまではOpenVZのようなOSレベルの仮想化ソフトウェアには
懐疑的だったのですが、
OpenVZのことを、 chroot + jail にいくつかの規制を加えたものだというように説明されたときには
「・・・仕組み的にも最もシンプルだし、それでいいじゃん」と妙に納得してしまいました。
仮想化するメリットはいくつかありますが、多くの場合、OSレベルの仮想化で十分なはずです。
また、使い方次第では驚くような利点があることがわかります。
【従来の仮想化の問題点】
OpenVZは従来の仮想技術とは違い、複数の仮想OSを起動したとしても使用するカーネルは一つです。
これにより今までと何が変わるのかというと、
従来では仮想OSのカーネル+付随する環境自体がメモリを使ってしまうため、
仮想OSでありながら、複数のアプリケーションを仮想OS上で動かす場面が多くありました。
例えば従来の方法で以下のような仮想システムを組んだとします。
仮想OS１：カーネル+必要なプロセス&スワップ(200MB) + Apache(128MB) + Tomcat(256MB) + MySQL(256MB) = 合計840MB
仮想OS２：カーネル+必要なプロセス&スワップ(200MB) + メールサーバー(128MB) + DNSサーバー(32MB) = 合計360MB
この構成では仮想OS上のApacheが下品な落ち方をした場合（OSを巻き込んで落ちた場合）
TomcatやMySQLも使えなくなってしまいます。
よりよい構成を求めるならば、全てのアプリケーションを仮想OSに分けるべきです。
しかし、もし仮に分けた場合には、
カーネル+必要なプロセス&スワップ(200MB)がアプリケーションの数だけ必須となってしまうため
200MB * 5(アプリケーションの数)で合計、1000MB分もとられてしまうことになり、
アプリケーションが多くなればなるほどリソース的に圧迫されるものでした。
そのため、複数のアプリケーションを仮想環境で動かさなければならないという状況が
現実的には多かったのです。
また、見積上では仮想OS１のメモリ使用量は840MBとなっていますが、
実際には相当数のアクセスがない限り、これほど多くのメモリは使いません。
しかし、実際に仮想OSを作成する場合のメモリ使用量は何かあったときのために
多めに見積もっておくのが普通でしょう。
そして、従来の仮想化では仮想OSの840MBは占有されてしまい
ネイティブのOSのリソースがごっそりと取られてしまいます。
->OpenVZならばこれらの問題を解決することができます。
OSレベルでの仮想化であるため、「カーネル+必要なプロセス&スワップ」は
ほとんど無いに等しいからです。
試しに最低限の仮想OSを作成しプロセスを見てみました。
# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.2 1980 692 ? Ss 05:01 0:00 init [2]
root 342 0.0 0.2 1692 620 ? Ss 05:01 0:00 /sbin/syslogd
root 349 0.0 0.3 5272 1024 ? Ss 05:01 0:00 /usr/sbin/sshd
root 367 0.0 0.3 2036 876 ? Ss 05:01 0:00 /usr/sbin/cron
root 379 0.0 1.0 8016 2704 ? Ss 05:09 0:00 sshd: root@pts/0
root 381 0.0 0.5 2760 1492 pts/0 Ss 05:09 0:00 -bash
root 428 0.0 0.3 2296 896 pts/0 R+ 05:42 0:00 ps aux
initの次はもうサービスです。
最小限の環境ならば10MBもあれば十分でした。
#top
top - 05:46:49 up 45 min, 1 user, load average: 0.00, 0.00, 0.00
Tasks: 7 total, 1 running, 6 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 262144k total, 8940k used, 253204k free, 0k buffers
Swap: 0k total, 0k used, 0k free, 0k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 1980 692 592 S 0 0.3 0:00.00 init
342 root 20 0 1692 620 508 S 0 0.2 0:00.00 syslogd
349 root 20 0 5272 1024 668 S 0 0.4 0:00.02 sshd
367 root 20 0 2036 876 704 S 0 0.3 0:00.00 cron
379 root 20 0 8016 2704 2224 S 0 1.0 0:00.12 sshd
381 root 20 0 2760 1496 1184 S 0 0.6 0:00.00 bash
429 root 20 0 2256 1060 872 R 0 0.4 0:00.00 top
これだけリソースの消費が少なければ、
アプリケーションごとに仮想環境を割り当てることが十分可能です。
また、従来のように仮想環境に
メインOSのリソースがごっそり奪われるということはありません。
例えば、２Gのメモリが乗っているマシンに、
２Gのメモリを割り当てた仮想環境を複数起動したとしても
まったく問題なく動きます。
その他、ゾンビプロセス問題などが発生しても、アプリケーションごとに
システムが分かれているために、再起動もやりやすくなります。
ここまでいいことづくめで書いてきましたが、残念ながら
全てのアプリケーションが仮想化できるわけではありません。
仮想化できなかったソフトウェアもいくつかあります。
それは特定のデバイスの使用を前提に作成されたソフトウェアなどです。
例を挙げるなら、OpenVPNやAsteriskで使用するzaptelなどです。
/dev/ 以下の使用を前提としているため
OpenVPN だと /dev/net/tun が無ければ動作をすることができません。
そのため、私の環境ではいくつかのアプリケーションはメインOS上で動作させざるを得ませんでした。
理想としてはメインOSではSSH とOpenVZだけをサービスとして提供させたかったのですが、
致し方ないところですね。
※2009/09/13
一ヶ月以上使用してみたのだが、予想以上に特定のデバイスに依存しているソフトウェアが多い。
ハードが低速だった頃に作られたソフトウェアの多くが
「カーネルに組み込むことも出来るし、組み込まなくても動かせる」 という作りになっているため、
わざわざカーネルパラメータを取得しに行ってしまい、FATALエラーになるとか・・・
NFSやsambaのsmbfs, cifsなんかも、OpenVZ上で動かすのは手間であるし情報も少ないので、
OpenVZ上で動かす場合特有のトラブルを覚悟しなければなりません。
Template Designed By
ぐらいんだぁ
ぐらいんだぁ