VirtualMachineからのネットワークの性能
第1回〜第3回では、どちらかというとドメインU単体での使用を想定して検証を行ってきました。しかし、よほどのことがない限りは、スタンドアロン でVM（VirtualMachine）を使うということはあまりないでしょう。そこで第4回では、VMから見たネットワークの性能を測定します。
環境の作り方
今回の環境もまた、XenでドメインUが動作している環境が必要になります。基本はドメインUが動作している環境なので、今回も前回までの環境をそ のまま使います。前回までのドメインU環境は、普通にネットワークが利用できるので、そのまま使って差し支えありません。
なおI/Oは、/dev/nullに向けて発生させます。こうすることで、物理的なI/Oは発生せず、純粋にネットワーク単体の性能に近い結果を得ることが可能になります。
また物理的な構成ですが、Xenが動作しているコンピュータと、それ以外のコンピュータを100MbaseTで接続した構成になります。本来なら ば、異なるVMからネットワークを経由して、それぞれ異なるコンピュータにアクセスさせるのがよいのですが、トータルのバンド幅が100Mbpsなので、 最大でも100Mbps以上はだせません。このため物理的なコンピュータは、Xenを動かすマシンと取得データを置くマシンの2台になります。
なお、sample.file（10MBのファイル）の中身は何であってもよいのですが、以下のようにして作成しました。
sample.fileの作り方
$ dd if=/dev/null of=sample.file bs=1024k count=10性能の測定の仕方〜wgetコマンドを使う〜
先にも記述しましたが、/dev/nullに対するI/Oを実施することで、ディスクI/Oなどの物理的な性能を気にすることなく、ネットワーク関連の部分についての性能を測定できるようになります。
性能測定方法は、wgetコマンドにおけるデータ転送速度をチェックするということで実施します。
測定用コマンドの選定〜wgetコマンドを使うまでの道のり
今回の性能測定にあたり、wgetコマンドとDebian GNU/Linux 3.1（sarge）のftpコマンドの2つを比較しましたが、wgetで充分と判断しました。これは、OSの種類が異なってもwgetコマンドの出力は同様であったためです。
ftpコマンドは、Linuxディストリビューションによって異なる動作を示したため、今回は用いません。ftpコマンドで取れる情報は、CentOSとDebianでは以下のようになります。
CentOS4.4のftpコマンドではdebugモードにおいても詳細な性能値が得られない
ftp> debug
Debugging on (debug=1).
ftp> get sample.file
local: sample.file remote: sample.file
ftp: setsockopt (ignored): Permission denied
---> PASV
227 Entering Passive Mode (61,197,226,214,217,200).
---> RETR sample.file
150 Opening BINARY mode data connection for sample.file (10485760 bytes).
226 Transfer complete.
10485760 bytes received in 1.7 seconds (6e+03 Kbytes/s)
Debian GNU/Linux 3.0や3.1のFTPコマンドではdebugモードにおいて詳細な性能値が取れる
ftp> debug
Debugging on (debug=1).
ftp> get sample.file
local: sample.file remote: sample.file
---> TYPE I
200 Type set to I.
ftp: setsockopt (ignored): Permission denied
---> PASV
227 Entering Passive Mode (61,197,226,214,217,187).
---> RETR sample.file
150 Opening BINARY mode data connection for sample.file (10485760 bytes).
226 Transfer complete.
10485760 bytes received in 1.17 secs (8715.7 kB/s)
wgetコマンドの場合
[wakatono@jannedaarc ~]$ wget http://www.example.com/~wakatono/sample.file -O /dev/null
--18:00:38-- http://www.example.com/~wakatono/sample.file
=> `/dev/null'
Resolving www.example.com... 192.168.0.214
Connecting to www.example.com|192.168.0.214|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10,485,760 (10M) [text/plain]
100%[====================================>] 10,485,760 11.22M/s
18:00:38 (11.22 MB/s) - `/dev/null' saved [10485760/10485760]
本来であれば、ディストリビューションも同様にすべきですが、根本的にほとんど何も動作していない状況であり、かつカーネルもドメイン0用とドメイ ンU用で異なることがある以外は同じものであるため、環境が測定結果に与えるインパクトは小さいだろうと判断し、今回の環境は混合環境にしました。
出力ファイルの指定〜wgetコマンドで、ローカルのファイルを/dev/nullに指定
wgetコマンドの書式を以下のようにします。「remote_file_url」のところには、取得するファイルに対応したURLを指定します。
wgetコマンドの書式
wget remote_file_url -O /dev/null ここでlocal_fileに/dev/nullを指定することで、ローカルファイルに対する書き込み速度を気にする必要がなくなります。
なお、incomingだけでなくoutgoingについても測定できるという点ではftpコマンドの方がよいのですが、FTPクライアントの putコマンドで、次のようにremote_fileにてFTPサーバ上のファイルを指定可能（当然省略は可能）でも、/dev/nullを指定した場合 でも、「通常ファイルではない」とのエラーが出力されるため、wgetの方が簡易であると判断しました。
ftpコマンドでremote_fileを指定
ftp> put local_file remote_file ftpコマンドで/dev/nullを指定とエラー
ftp> put sample.file /dev/null
local: sample.file remote: /dev/null
200 PORT command successful.
550 /dev/null: Not a regular file取得ファイルは事前に何度か取得しておき、当該ファイルを（サーバ側の）バッファキャッシュに格納するようにしておく
VM側で物理I/Oが発生しなくても、通信する相手で物理I/Oが発生すると、トータルの性能が下がります。このため、物理I/Oを発生させないた めに、ある程度予備的なI/Oを発生させ、ファイルアクセス時に物理的なディスクアクセスが起きにくいよいにします。
バックナンバー
この記事の筆者
筆者の人気記事
Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。
