XenのDom間のLAN速度を測定。
まず、DomU→dom0通信
[root@p01 kfs]# netperf -H alpha -fM
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to alpha.hoge.com (192.168.0.2) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. MBytes/sec
87380 16384 16384 10.01 114.79
Dom0間通信(110MB/Sec)より速いので、これはGJ。CPUパワーを全力で食ってますが。
あ、ちなみに
Dom0のlocalhostでベンチ取ったら234MB/Secでした。
DomUのlocalhostでベンチ取ったら337MB/Secでした。
DomUのほうが速いという不思議。
次に、同一Dom0上にあるDomU→DomU通信。理屈的にはDomU→Dom0→DomUとなるはず。
[root@p01 kfs]# netperf -H 192.168.0.105 -fM
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.0.105 (192.168.0.105) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. MBytes/sec
87380 16384 16384 10.01 68.15
68MB/Sec。さっきの半分近い。
ローカル通信のくせに遅いのね。xm topで監視してたら、CPUパワーも全力食ってたようだし。
CPUパワーに依存する＆現在の環境では、Domをまたぐごとに50％のオーバーヘッドがあるらしい。
続いて異なるDom0間でのDomU→DomU通信の場合。理屈的にはDomU→Dom0→Dom0→DomUになるかな？
[root@p01 kfs]# netperf -H 192.168.0.105 -fM
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.0.105 (192.168.0.105) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. MBytes/sec
87380 16384 16384 10.01 33.04
33MB/Sec。
やはり通過するDomが増えた事によるオーバーヘッドだろうか。こちらも50％ダウンである。
受信側のほうがCPUめいっぱい、送信は70％くらいの負荷でした。
2008年3月29日土曜日
XenのHDDベンチマーク取ってみた。
とりあえずXenのHDDベンチマーク取ってみた。
alpha(Dom0)のベンチ
[root@alpha ~]# hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 3108 MB in 2.00 seconds = 1556.04 MB/sec
Timing buffered disk reads: 196 MB in 3.02 seconds = 64.86 MB/sec
beta(Dom0)のベンチ
[root@beta ~]# hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 3104 MB in 2.00 seconds = 1552.36 MB/sec
Timing buffered disk reads: 192 MB in 3.00 seconds = 63.90 MB/sec
p01(共有ストレージ＝alpha、稼働＝alpha)
[root@localhost ~]# hdparm -Tt /dev/xvda
/dev/xvda:
Timing cached reads: 3188 MB in 2.00 seconds = 1595.82 MB/sec
Timing buffered disk reads: 166 MB in 3.03 seconds = 54.85 MB/sec
p02(共有ストレージ＝alpha、稼働＝beta) ←1GbpsのLAN、NFSで共有
[root@localhost ~]# hdparm -Tt /dev/xvda/dev/xvda:
Timing cached reads: 3160 MB in 2.00 seconds = 1580.61 MB/sec
Timing buffered disk reads: 62 MB in 3.01 seconds = 20.59 MB/sec
○結論
alpha、betaはほぼ同水準で65 MB/sec。そりゃまぁ、買ったばっかりの同一モデルだし、差が出る訳がない。
Dom0(alpha)の上でDomUを動かした場合、55 MB/sec。20％弱のオーバーヘッド。
Dom0(alpha)にストレージを残したままbetaにライブマイグレーションした場合、20.59 MB/sec。もうね、70％ダウンですよ。
ネットワーク越しにしたことでモロに影響が出ているわけですが、では私の環境のネットワーク速度はどんなもんでしょう。
[root@beta ~]# netperf -H alpha -fM
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to alpha (192.168.0.2) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. MBytes/sec
87380 16384 16384 10.01 110.31
はい、110MB/Secと出ました。
でも同じネットワーク上でWin同士でデータをやり取りしたり、SCP転送したりすると、速くて20MB/sec程度のもんなので、先のHDDベンチの水準は妥当な感じがします。
やっぱりライブマイグレーションしてHDDにガリガリアクセスするのは無理があるなぁ。
alpha(Dom0)のベンチ
[root@alpha ~]# hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 3108 MB in 2.00 seconds = 1556.04 MB/sec
Timing buffered disk reads: 196 MB in 3.02 seconds = 64.86 MB/sec
beta(Dom0)のベンチ
[root@beta ~]# hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 3104 MB in 2.00 seconds = 1552.36 MB/sec
Timing buffered disk reads: 192 MB in 3.00 seconds = 63.90 MB/sec
p01(共有ストレージ＝alpha、稼働＝alpha)
[root@localhost ~]# hdparm -Tt /dev/xvda
/dev/xvda:
Timing cached reads: 3188 MB in 2.00 seconds = 1595.82 MB/sec
Timing buffered disk reads: 166 MB in 3.03 seconds = 54.85 MB/sec
p02(共有ストレージ＝alpha、稼働＝beta) ←1GbpsのLAN、NFSで共有
[root@localhost ~]# hdparm -Tt /dev/xvda/dev/xvda:
Timing cached reads: 3160 MB in 2.00 seconds = 1580.61 MB/sec
Timing buffered disk reads: 62 MB in 3.01 seconds = 20.59 MB/sec
○結論
alpha、betaはほぼ同水準で65 MB/sec。そりゃまぁ、買ったばっかりの同一モデルだし、差が出る訳がない。
Dom0(alpha)の上でDomUを動かした場合、55 MB/sec。20％弱のオーバーヘッド。
Dom0(alpha)にストレージを残したままbetaにライブマイグレーションした場合、20.59 MB/sec。もうね、70％ダウンですよ。
ネットワーク越しにしたことでモロに影響が出ているわけですが、では私の環境のネットワーク速度はどんなもんでしょう。
[root@beta ~]# netperf -H alpha -fM
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to alpha (192.168.0.2) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. MBytes/sec
87380 16384 16384 10.01 110.31
はい、110MB/Secと出ました。
でも同じネットワーク上でWin同士でデータをやり取りしたり、SCP転送したりすると、速くて20MB/sec程度のもんなので、先のHDDベンチの水準は妥当な感じがします。
やっぱりライブマイグレーションしてHDDにガリガリアクセスするのは無理があるなぁ。
Xenで遊ぶぞ
とりあえずXen入れて、ライブマイグレーションしてみる。
「OSとはインストールするものではなく、コピーするものである」という哲学に沿って、使い回せるイメージの作成を目指します。
# virt-install -n hoge -r 256 -f /kfs/hoge -s 4 --nographics -l ftp://ftp.riken.go.jp/Linux/centos/5.1/os/x86_64
hogeという識別子をつける(-n)
256MBのメモリを割り当て(-r)
/kfs/hogeというファイル名で仮想ファイル[xvd形式]を作成する(-f) ←これは識別子と揃えておいたほうがいいぞ
4GBの仮想ファイルを作成する(-s)
GUIは利用しない(--nographics)
指定ftpからインストール(-l)
Domain-0のメモリが足りないとき、無理矢理圧縮する方法
# xm mem-set Domain-0 128
インスコ時はDHCPにしとくと、後でイメージコピーできて便利だぞ
とりあえずオプションはデフォルトで進める。
ソフトパッケージはカスタムして空っぽにする。（コピーして使い回すため）
あと普通にカスタム。
# yum install yum-fastestmirror
# yum -y update
# wget http://prdownloads.sourceforge.net/webadmin/webmin-1.410-1.noarch.rpm
# rpm --install webmin-1.410-1.noarch.rpm
# rm webmin-1.410-1.noarch.rpm
webmin設定する。
いらないスタートアップも消す。
こんなもんかしら。
DHCPで割り当てられたipは
# ifconfig
で調べられるぞ。
Xen自体は、
XenのHTTPインターフェースを有効化
# vi /etc/xen/xend-config.sxp
(xend-http-server yes) #どうも落ちる。原因不能。
(xend-port 8000)
(xend-address '192.168.1.100') # 接続元を限定
# service xend restart
Xenのマイグレーション有効化
# vi /etc/xen/xend-config.sxp
(xend-relocation-server yes)
(xend-relocation-port 8002)
(xend-relocation-hosts-allow '')
# service xend restart
ライブマイグレーションする
# xm migrate moge hoge.com --live
ネットワークコネクションも切れず、数秒で移動させられる。かなり実用的な機能のようだが、しかし使い道が思いつかない・・・
1:超RAIDで可用性バリバリだがCPUが弱い共有ストレージを用意する
2:OSを数台のPCで動かし、メンテ時や過負荷時にマイグレしたりしてみる
そうするとディスクのメンテナンスコストは抑えられそうだが、一台壊れると影響範囲が極めて広く、それって結局可用性が下がっちゃって意味ないような気がする。
読み書きが集中したらパフォーマンス落ちるし。
うーん・・・ 一体、何に使うんだろう・・・。。。
DHCP、オンメモリ運用、書き込み無しを前提に、サーバをポコポコ増やしまくる用途なら効くような気がするが、それってライブマイグレーションなんか実はどうでもよくて、ディスクのイメージ化のほうが重要だったり。あー、しかしDHCPだとトラブったサーバを特定できないから、ポコポコ増やすにも向いてないね、やっぱり。
「OSとはインストールするものではなく、コピーするものである」という哲学に沿って、使い回せるイメージの作成を目指します。
# virt-install -n hoge -r 256 -f /kfs/hoge -s 4 --nographics -l ftp://ftp.riken.go.jp/Linux/centos/5.1/os/x86_64
hogeという識別子をつける(-n)
256MBのメモリを割り当て(-r)
/kfs/hogeというファイル名で仮想ファイル[xvd形式]を作成する(-f) ←これは識別子と揃えておいたほうがいいぞ
4GBの仮想ファイルを作成する(-s)
GUIは利用しない(--nographics)
指定ftpからインストール(-l)
Domain-0のメモリが足りないとき、無理矢理圧縮する方法
# xm mem-set Domain-0 128
インスコ時はDHCPにしとくと、後でイメージコピーできて便利だぞ
とりあえずオプションはデフォルトで進める。
ソフトパッケージはカスタムして空っぽにする。（コピーして使い回すため）
あと普通にカスタム。
# yum install yum-fastestmirror
# yum -y update
# wget http://prdownloads.sourceforge.net/webadmin/webmin-1.410-1.noarch.rpm
# rpm --install webmin-1.410-1.noarch.rpm
# rm webmin-1.410-1.noarch.rpm
webmin設定する。
いらないスタートアップも消す。
こんなもんかしら。
DHCPで割り当てられたipは
# ifconfig
で調べられるぞ。
Xen自体は、
XenのHTTPインターフェースを有効化
# vi /etc/xen/xend-config.sxp
(xend-http-server yes) #どうも落ちる。原因不能。
(xend-port 8000)
(xend-address '192.168.1.100') # 接続元を限定
# service xend restart
Xenのマイグレーション有効化
# vi /etc/xen/xend-config.sxp
(xend-relocation-server yes)
(xend-relocation-port 8002)
(xend-relocation-hosts-allow '')
# service xend restart
ライブマイグレーションする
# xm migrate moge hoge.com --live
ネットワークコネクションも切れず、数秒で移動させられる。かなり実用的な機能のようだが、しかし使い道が思いつかない・・・
1:超RAIDで可用性バリバリだがCPUが弱い共有ストレージを用意する
2:OSを数台のPCで動かし、メンテ時や過負荷時にマイグレしたりしてみる
そうするとディスクのメンテナンスコストは抑えられそうだが、一台壊れると影響範囲が極めて広く、それって結局可用性が下がっちゃって意味ないような気がする。
読み書きが集中したらパフォーマンス落ちるし。
うーん・・・ 一体、何に使うんだろう・・・。。。
DHCP、オンメモリ運用、書き込み無しを前提に、サーバをポコポコ増やしまくる用途なら効くような気がするが、それってライブマイグレーションなんか実はどうでもよくて、ディスクのイメージ化のほうが重要だったり。あー、しかしDHCPだとトラブったサーバを特定できないから、ポコポコ増やすにも向いてないね、やっぱり。
登録:
投稿 (Atom)