iSCSIが遅かった理由

先日からiSCSI + ESXiの環境を組んでいたのだがiSCSIディスクアクセスの速度が妙に遅くて困った。1000Base-Tなのに120Mbps程度しか出ていない。明らかに異常なのでトラブルシューティングをしてみた。

環境：

• iSCSI Target : D945CGLF2 + Realtek 8111D（オンボード）, NetBSD 5 Xen DOMU上のiSCSI Target
  
• iSCSI Initiator： Intel DQ45CB , Q8400, Intel 1000/PT (PCI-Express) ESXiをインストール
  
• その他：Apple Macbook Late 2007, Marbell Yukon 2, Mac OS X 10.5をインストール
  

問題は、iSCSI Targetと Initiator間の速度が出ない事。

iSCSIでベンチマークを取るとディスクアクセスに性能が引っ張られてしまうので、今回はUNIX系ではおなじみのネットワーク帯域測定ツールのnetperfを使って速度を計測した。Macbookをサーバーとし、各マザーに色々なOSを入れて計測してみたところ以下のような結果になった。

D945CGLF2 + NetBSD 5 amd64 Xen DOMU : 　120Mbps
D945CGLF2 + NetBSD 5 amd64 Xen DOM0 : 　110Mbps
D945CGLF2 + NetBSD 5 amd64 Xen GENERIC Kernel : 440Mbps
D945CGLF2 + CentOS 5 amd64 Xen DOMU : 200Mbps
D945CGLF2 + Puppy Linux 4.2 i386: 840Mbps
DQ45CB(Intel 1000/PT) + Puppy Linux 4.2 : 680Mbps

うわぁ。120Mbpsってなんだよ....NetBSD Xenとの相性が最悪じゃん。コリャダメだ。ファイルサーバーをXenにしたのは間違いだったか。NetBSD 5 + Generic kernelでもあまり速くないし、NetBSDは全般的に遅めの傾向。iSCSI TargetはLinuxで組み直そうかな。

この中ではLinux + D945CGLF2が一番速い。CPU負荷が若干高くなるような気がするけど、これだけ速度に差があるとそれも許せてしまうかも。Realtekは悪い意味で有名だったけど少し考え直そう。枚数を用意するときはコレでもいいかも。

HP Procurve Switch 1400-8G購入

100Base-TXでiSCSIを使用しているとだいたい8〜9Mbyte/Sec程度の速度しか出ない。さすがにキツいので1000Base-Tのスイッチを購入した。購入したのはHP Procurve Switch 1400-8G。通常の8ポートのノンインテリジェントスイッチでお値段は12000円。このクラスの製品では少し高い方になる。

あまり知られていないが、HPのスイッチは全製品に永久保証がついている。以前、職場の古いシャーシスイッチが故障したときは、24時間後には交換部品が到着し業務に復帰できた。特に、追加コストも保守契約の更新もなく保守が受けられるのはとてもありがたい。ちなみに、日本ではどうだか知らないが、海外ではシェアは2位なんだそうな。

さて、問題となっていたiSCSIの速度は...遅い。17MByte/Secがいいところ。まいったな。NetBSD5+ Realtek 8168B/8110Sだとジャンボフレームが使えないのか。あー、ドライバーのソースによるとこのチップのリビジョンだけMTUは1500以上は指定できないようになっとるorz...。ちなみにチップ自体は7Kbyteまでのジャンボフレームに対応しているそうなので、ドライバーの対応待ちといったところか。

NetBSDでiSCSI Targetを構築する。その2 Windowsでマウント編

前回の続き。今回はNetBSDで構築したiSCSIターゲットをWindows Server 2008でマウントする。Windows Vista / 2008では標準でiSCSIイニシエーターがインストールされているので問題はないが、Windows XP / 2003 / 2000の場合は、こちらからiSCSI Software Initiatorをダウンロード＆インストールする必要がある。

設定は超簡単で、以下の3つのみ。

1. ターゲットが接続されたマシンを探索リストに追加する。
2. ターゲットにログオンする
3. ターゲットをオンラインにして、パーティションを切り、フォーマットする

まずは、【コントロールパネル】→【iSCSIイニシエータ】→【探索】タブを選択。その後、【ポータルの追加】を選択し、ターゲットが稼働するマシンのホスト名（またはIPアドレス）を入力。ポートはデフォルトの3260でOK。

次に、【ターゲット】タブを選択して、【ターゲット】より"iqn.1994-04.org.netbsd.iscsi-target:target0"を選択。その後、【ログオン】を押して、ログオンする。ログオン時のオプションで【コンピュータの起動時にこの接続を自動的に復元する】を選択すると、起動時に自動的に接続する事ができる。

最後に、サーバーマネージャを起動して、【記憶域】→【ディスクの管理】を選択し、オフラインになっているディスクの上でコンテクストメニューを表示し、【オンライン】を選択。あとは、通常のボリューム作成＆フォーマットを行なうのみ。
さて、問題の速度は.....SandraのディスクベンチでNTFSを用いた場合は9MByte/Secだった。経験からすると100Base-TXの場合はまぁこんなていど。やっぱり自宅にも1000Base-Tを入れるか。Managedな1000Base-Tのエッジ系L2スイッチだと...Alied Telesis CentureCom GS908かな。ファンレンスだし。

次回はVMware ESXiでのiSCSIイニシエーターの使用方法を紹介する予定。

NetBSDでiSCSI Targetを構築する。その1 Target構築編

NetBSDはiSCSIのTargetソフトウェアが標準で搭載されている。VMware ESXiやWindowsのInitiatorと組み合わせるとものすごい幸せになれるので構築してみた。
今回は、ddで作成されたファイルをターゲットとして公開し、Windows Server 2008のイニシエーターでマウントしてフォーマットするところまでを紹介する。環境の構築手順はとても簡単だ。

1. NetBSDマシンでiSCSIターゲットを構成する
2. NetBSDマシンでiSCSIターゲットを起動する
3. クライアントマシン（例としてWindows Server 2008 SP1）でターゲットをマウントする。
4. クライアントマシンでターゲットをフォーマット

NetBSDではiSCSIターゲットが標準でインストールされており、その詳細はiscsi-target(8)とtargets(5)でmanを見る事ができる。iscsi-targetは少し前にはpkgsrc/devel/netbsd-iscsiとして公開されていたがいつのまにか本家にマージされていた。私の記憶が正しければ、実装は元々WASABI Systemが行なっていて、NetBSDプロジェクトに寄贈したんじゃなかったかと。2005年くらいには実装が終了していたような気がするので、割と安心して使用する事ができる。

iscsi-targetの設定は設定ファイルベースで行なわれる。設定ファイルのデフォルトの場所は、/etc/iscsiとなっており、サンプルとしてtargetsとauthsの2つのファイルが保存されている。targetsはiSCSIターゲットとして公開するファイル（またはデバイス）を記載し、authsはターゲットにアクセスする際のユーザー名とパスワードを記載する。

まずはiSCSIターゲットとして公開したいディスクイメージファイルを作成する。ここではファイル名を/iscsi-targets/testとし、ファイルサイズを500Mbyteとした。

$ dd if=/dev/zero of=/iscsi-targets/test bs=1024k count=500

作成が終了したらls -l でファイルの大きさを確認しておく。ファイルの大きさをtargetの設定ファイルに記述する必要があるためだ。

ls -l /iscsi-targets/test
-rw-r--r-- 1 root wheel 524288512 May 7 09:54 /iscsi-targets/test

次に、/etc/iscsi/targetsファイルを編集する。targetsファイルには以下の2行を追加する。

extent0 /iscsi-targets/test 0 524288512
target0 rw extent0 192.168.55.0/24

extent0の行には公開するファイルとそのファイルの開始位置と終了位置を記載する。オフセットを適切に指定する事によって、1つのファイル（やデバイス）を複数のextentとして構成する事ができる。今回は1つのファイルを1つのextentとしている。このため、offset は0となり、sizeは524288521となる。target0の行には公開するターゲットの名前とモード、ターゲットに対応するextentとtargetを公開するサブネットを記載する。
ここで注意するのは、extent0の行は"extent + numner"で表記されなければならず、hoge0などの勝手な名前は拒否される。同様にtargetの行も"target + number"の形式で表記する必要がある。

次にiSCSIターゲットを起動する。iSCSIターゲットの起動スクリプトは/etc/rc.d/iscsi-targetに保存されている。システム起動時に自動的に起動したい場合は、以下のようにrc.confに1行を追加しておく。

echo "iscsi-target=YES" >> /etc/rc.conf

次に、iSCSIターゲットを起動する。

bash-4.0# /etc/rc.d/iscsi_target start

iSCSIターゲットが正常に起動すると、以下のようにメッセージが表示される。

iscsi_target not running? (check /var/run/iscsi-target.pid).
Starting iscsi_target.
Reading configuration from `/etc/iscsi/targets'
target0:rw:192.168.55.0/24
extent0:/iscsi-targets/test:0:524288512
DISK: 1 logical unit (1024000 blocks, 512 bytes/block), type iscsi fs
DISK: LUN 0: 500 MB disk storage for "target0"
TARGET: TargetName is iqn.1994-04.org.netbsd.iscsi-target

ここで、注目するのはTARGET:の行で、これがこのターゲットを識別するための物となる。実際にターゲットをマウントする際はLUNと連結し、「iqn.1994-04.org.netbsd.iscsi-target:target0」としてマウントする事になる。

長くなったので今日はここまで。実際にWindows Server 2008を用いてマウントする方法は次回に記載する事にしよう。

NetBSD 5.0 リリース！

4/29にNetBSD 5.0がリリースされた。さっそくcvs update && make すんべさ。ついでに、NetBSDのオフィシャルブログもオープンしたそうな。

CentOS 5.2 on Xen3.3 with NetBSD 5.0RC2 amd64

NetBSD amd64 + Xenの環境で、CentOS 5.2がDomUで動作した。ググってもvert-installを用いたやり方しか出てこないので、シンプルなDomUの設定ファイルを書いておく。

設定ファイルの内容

#kernel = "/xendata/centos52/vmlinuz_64"
#ramdisk = "/xendata/centos52/initrd.img_64"
memory = 512
name = "centos52"
vif = [ 'bridge=bridge0' ]
disk = [ 'file:/xendata/centos52/disk1,xvda,w']
root = "/dev/xvda ro"

手順は、

1. Xen用のインストーラーを入手する。vmlinuzとinitrd.imgをダウンロード。
2. インストーラーを上記設定ファイルのkernel=とramdisk=の場所に配置する。設定ファイルのコメントを解除。
3. xm create -c configuration_file_for_centos52
4. そのまま普通にインストールし、インストーラーが終了したらシャットダウン。
5. 設定ファイルのkernel=とramdisk=をコメントアウト
6. 再び起動するとdisk1からブートする。
   

注意する点は以下の2つ

1. vifにmac=を使ってMACアドレスを指定すると、ネットワークインストールに失敗する。
   pingは通るがドロップが激しい。mac=は使わない事。
   
2. ディスクをhdaデバイスとして提供にすると、インストーラーがfdiskに失敗する。anacondaがGPTパーティションと誤認する。
   xvdaを使う事。

Dom0起動時にDomUを起動するためには、NetBSDの場合は、以下の設定を行なう。

1. DomU起動スクリプトxendomainsをコピー
   # cp /usr/pkg/share/examples/rc.d/xendomain /etc/rc.d
2. /etc/rc.confに以下の行を追加
   xendomains="config_file_for_centos52"
3. DomUの設定ファイルを/usr/pkg/etc/xen/config_file_for_centos52にシンボリックリンクorコピーする

今のところ問題無し。インストールしたCentOSはSELinuxの実験に使うつもり。

NetBSD 5をDOM0に使う場合のPAEサポート

NetBSD 5 RC2にXen 3を入れて遊んでいたのだがハマってしまった。どうやらDOM0にNetBSDを使うときは、PAEなしのXenを使わなければならないようだ。Port-xenのメーリングリストによると、DOM0のNetBSD + PAEは先週にcurrentにコミットがあったばかりだそうで、まだ実用には耐えないだろうな。くわしくはこちら。

その他の解決策としては、i386からamd64に移行してしまうというのもある。amd64ならば、PAEの有無は関係ないので。うーむ、またDOM0をビルドし直しか。こうやってハマるのも楽しいからいいんだけどね。

D945GCLF2でNetBSDを使う

G945GCLF2にNetBSD 5.0 RC2 + Xen を入れてみた。XenカーネルではD945GCLF2に載っているイーサーネットカードが認識しなかったので、チョイと手を入れてみた。チップは通称ギガニのRealtek 81x9シリーズ。症状は、

• Xenカーネル使用時のみ不安定になる
  
• 起動時に「re0: Unknown revision (0x3c4000000)」
  
• ifconfig re0 upとすると、「re0: reset never completed!」とコンソールに出る。
• 認識してもパケットロスが多すぎて使い物にならない。
  

と、といったところ。

NetBSD -currentのソースを見てみると、currentのドライバーならばsrc/sys/dev/ic/rtl81x9reg.hに0x3c4000000が記載されている。5.0 RC2に始めから入っているバージョンはダメっぽいので、currentのrtl81*をコピーしてカーネルをリビルド＆インストールしたらOKだった。

Linux系, Solaris, OpenBSD, FreeBSDなど、いろいろいじって来たが、NetBSDが一番使っていて自分に合ってような感じがする。ソースツリーの配置、pkgsrc、ドキュメントとかがマルチプラットフォーム対応という思想を元に一貫して作られていて、その一貫性がシプルさと信頼につながっているように思える。