dotfiles を github に上げてみた

dotfiles を公開レポジトリに上げるのが最近の流行らしい。なので、僕も github に上げてみた。

• http://github.com/fukusaka/dotfiles

結構古くから VCS に入れて適当に履歴を記録したんだが、 「git rebase -i 」を使うと commit を修正できるので、 CVS ～ Subversion ～ git に変更する過程の履歴を 適当に整理してみた。

うん、なんとも紆余曲折がある、、、未だにちょっと壊れ気味の設定だなぁ。。。

Squeeze に移行してみる

squeeze がフリーズされて、暫く経つので安定の良い頃合いかなと、 自宅のメインのサーバを lenny から squeeze に移行してみた。

何とも、安定してる。。。

lenny ベースだと、古く使いたい機能が無いので、 適当に野良バックポートしてた netatalk と kvm/libvirt-bin とか幾つかあったのが、 標準のパッケージで済むのが良い。

ただ、１点だけ手作業が必要だった。 どうも autofs のマップファイルが LDAP を参照しているとき、 マスタでは slapd が立ち上がらないタイミング(autofs より slapd が後)なので、 うまく機能しない。。。

まだ sysvinit ベースなので、次のようにした。

update-rc.d -f slapd remove
update-rc.d slapd defaults 18 82

upstartに移行した暁には、Debian もいい感じになるのかなぁ

追記 (2011/02/12)

Debian squeeze から upstart の時代だといった奴は、、、 sysvinit と insserv の合わせ技が標準じゃないかぁ！！

なので、/etc/init.d/autofs の先頭に書かれた insserv 設定行の該当部分を下記のように書き換えると、対処ができる。

...
# Should-Start: ypbind nslcd slapd
# Should-Stop: ypbind nslcd slapd
...

Linux SCSI Target Framework を使う

Debian/Ubuntu の iSCSI Target のお話が出てくると、iSCSI Enterprise Target (IET)が必ず出てくる。

まぁ、良いんだけど kernel ソースに取り込まれていないモジュールを使うので、 時々、他の複合的な要因かもしれないが、あさっての場面で oops は吐いくれたりする。

Fedora/RHEL/CentOS とかだと、既にLinux SCSI Target Framework(tgt)に移行している。コイツは 2.6.20 頃 kernel ソースに取り込まれているので、 結構安定してるんじゃないかなと思う。

tgt の性能に関しては、2006 年頃の論文「Linuxにおけるストレージシステムフレームワークの実現(オペレーティングシステム)」を見る限り、IET と若干落ちるぐらいなので、気にしなくても良いかも。

そろそろ Debian/Ubuntu でも Linux SCSI Target Framework(tgt)に移行する時期だ。

ユーザベースのツール群 tgt パッケージは、squeeze/lucid で用意されているみたいなので、やってみた。

ハマりポイントが２点ある。

1. init スクリプトが見当たらない。バグ(#577925、BUG #574554)として登録されている。
2. tgt-admin 内で、デバイスが既に利用してるかどうかチェックする部分が上手く動いていない。と言うか、Debian/Ubuntuでは /bin/sh が dash (ash の亜種) になっているため、perl の system関数の呼び出しのスクリプト片に移植性がある書き方が要求される。コイツを踏んでる。

なので Fedoraのinitスクリプトを参考に、upstart 用のイベント設定ファイル？ /etc/init/tgtd.confを書き下し、tgt-admin の修正パッチtgt-admin.diffを作ってみた。

例として、単一ディスクをiSCSIで公開する事を考える

以下の設定ファイルを書き下し、「tgt-admin -e」とタイプすれば良い。

/etc/tgt/targets.conf

default-driver iscsi

<target iqn.2010-07.com.example:stroage.fserver.data>
	driver iscsi
	backing-store /dev/sdb
</target>

実際にiSCSIターゲット設定が上手く行ったかは、次のようにする。

# tgt-admin -s
Target 1: iqn.2010-07.com.example:stroage.fserver.data
    System information:
        Driver: iscsi
        State: ready
    I_T nexus information:
    LUN information:
        LUN: 0
            Type: controller
            SCSI ID: IET     00010000
            SCSI SN: beaf10
            Size: 0 MB
            Online: Yes
            Removable media: No
            Backing store type: rdwr
            Backing store path: None
        LUN: 1
            Type: disk
            SCSI ID: IET     00010001
            SCSI SN: beaf11
            Size: 34360 MB
            Online: Yes
            Removable media: No
            Backing store type: rdwr
            Backing store path: /dev/sdb
    Account information:
    ACL information:
        ALL

あとは、巷に溢れている tgt の設定方法が使える。 上手く設定すると、CDドライブやリムーバルディスクとかも、ネット越しで使えるようになるらしい。

追記 (2010/09/06)

気づいてみると、二番目のハマり点も修正済み(#589716)になったようである。

debian squeeze がリリースしたら、tgt をサクッと使うようになれる訳ですね。

Emacs23 の フォント設定

新し目の Emacs ではフォントエンジンの改良が進んでおり、 antialiasing が効いた奇麗な表示が出来る。また、沢山の種類のフォントを扱えるようになっている。

プログラムの編集等をしてると等幅フォントが必要である。 特に、日本人としてはASCII文字と日本語文字の幅が 1:2 である事が強く望ましい

まぁ、いくつか設定方法が流れてるので、コピペして使えば良いのだが。。。 みんなどうやって見やすい設定を探してるのだろうか？

疑問に思ったので、次のような機能のelispを書いてみた

my-sample-ascii.el

my-sample-ascii

既定のフェース default/bold/italic/bold-italic それぞれで同じメッセージを 同一のバッファに出力する

my-sample-face-size

defaultのフェースを継承し(書体を引き継ぎ)、高さが 6〜20ptのフェースを作成し、同じメッセージを 同一のバッファに出力する

適当にdefaultフェースを設定した後だが、CocoaEmacs/NTEmacs/Emacs(onUbuntu)での、 my-sample-face-sizeの結果は次のようになる

いくつか設定してみたが、全ての pt で、1:2 に揃うフォントの組み合わせはほんとに稀で、日常的に使うサイズに合わせて、サイズの微調節が必要のようである。 やはり、IPAフォントの恩恵は結構でかいなぁ。

今現在、いい感じに設定できたのは次の通り。

まとめ

なんか Emacs をガンガン使い倒したくなってきた！！

追加 (2010/11/03)

VMware 上の X で画面サイズの変化で dpi が変化し pt 単位でフォント指定すると、実際のフォントの大きさがまちまちになるので、 明示的にpixel単位？で指定する方法に切り替えてみた。

libvirtd を終了時にGuestOSを保存する方法

libvirt+QEMU/KVM を使った仮想化の運用を続けていると、どうしても気になる事がある。

libvirtd の設定には、自動起動するGuestVMは登録できるのだが、 終了時には有無を言わさず GuestVM を強制終了してしまう事である。

自前で libvirt (0.7.2)を入れているので今のバージョンでは何らかのサポートが入ってかもしれない。 ただ「libvirt: Releases」を見る限り入って無さそうである。

それにQEMU/KVMドライバだけの挙動かもしれない。他とドライバ(Xen等々)だと状況は違うかもしれない。

まぁ。。。そのうち何らかの対応が入るんだろうなぁ。。。

そうは言っても、ホストマシンを終了するときイチイチ確認するのは難儀である(とくにACPIサポートが悪く電源断しないGuestOSタイプとかねぇ)。

さて、QEMUにはVMの状態を保存復帰(save/restore)がサポートされている。コイツとストレージ共有を組み合わせると、ライブマイグレーションが一丁上がりになるので、つい何年か前に小躍りしてる人がたくさんいた気がする。

まぁ普通にサスペンド/レジュームの仕組みなので、コイツをなんとか上手く使うスクリプトを組んでみた。

指定する項目は３つで、それぞれスクリプト冒頭に書かれている。

libvirt-start-stop-vm.sh

...
SAVEVMDIR="/var/lib/libvirt/save"            # 保存するVMの置き場所
LISTVM_SHUTDOWN="linux_sid linux_fedora"     # 終了時 shutdown するもの
LISTVM_SAVE="freebsd_cur netbsd_cur solaris" # 終了時 save するもの
...

やってる事は単純で virsh コマンドを叩いてるだけである。 ただ、LISTVM_なんたらで指定し無かったり、15分以内に正常に電源断しない奴は、 最後に念のためsaveしてある。

コイツを、/etc/init.d/libvirt-binのスクリプトの必要な部分に入れ込むだけ。

うん〜、これでマシンを立ち上げると前回マシンを落とした時の状態のままのSolaris10/FreeBSDが立ち上がるようになった。。。しかし、時刻が合わん。なんか、GuestOSが共通に取れるイベントの仕組みがあるのかなぁ。。。SNMPとかで叩くんかなぁ。。。SSHとかで叩くんかいなぁ。。。順当に cron でntp引っ張ってくるが原始的でいいのかぁ。。。でも、時刻合わせの精度は低いし、常時CPUをちょっとだけ使うのはなぁ。。。ぶつぶつ

あんまり、すっきりしないが個人で使う分には用は足りそうである。

VIA EPIA EN のその後

VIA EPIA EN12000 を24時間運転してサーバ運用してる。 以前は、時々ハングアップしていたのため、保険で watchdog 設定をしていたのだが、 奇妙なことに安定動作している。

# uptime 
 16:32:08 up 48 days, 21:24,  1 user,  load average: 0.06, 0.07, 0.01

取り敢えず、１ヶ月半くらい連続運転している。

はて？
なにが効果あったのかな？

環境としては、

• VIA-EN12000EG / VIA C7 1.2GHz
• DDR2-533 1G (IO-DATA DX533-1G)
• PATA SSD 32G (TS32GSSD25-M)
• SATA HDD 1Tx2 (WDC WD10EADS-00L/WDC WD10EADS-00M)
• Debian lenny の標準的なパッケージをほぼ使ってる。

TimeMachine の バックアップ先になっており、一時間ぐらいの間隔で バースト的に Network I/O や Disk I/O が同時に発生する状況にある。

取り敢えずは、今のところ安定している。。。

まぁ、ネットワーク負荷を計測するときには、 負荷をかけるとハングアップすることが多々あった。 追っかけてみようかと思って保留して、 計測後の環境ではハングアップが全く無くなったので放置してしまった。

計測前と計測後には大きく２点の作業をしてある。

メモリのフリーページの調節

運良くコンソールにメッセージが出てきたとき「lockup」とかは見た記憶がある。 別のメッセージだったかもしれない。 色々調べて、「メモリーのフリーページの不足ぎみが NICドライバ内でのlockupを引き起こす」とか適当に結論づけて、 次の設定をした気がする

# echo "vm.min_free_kbytes = 8192" >> /etc/sysctl.conf

ただ、もっと良い設定があって次のようなスクリプトを自前のバックアップ処理の後に入れている

## pagecache clear & dirty page & inode cache clear
/sbin/sysctl -w vm.drop_caches=3
#
/sbin/sysctl -w vm.drop_caches=0

この設定は、結構気分の問題な気がする。

NIC ドライバの変更

計測中も、ベンダ提供のものか、自前で修正したものを使っている。 計測後は、自前で修正したものを使って長期運用している。。。ってその為に改良したしなぁ。

Debian 標準カーネルに含まれているvia-velocityドライバはバースト的なI/Oにはlockupするような、気がする。

まとめ

人生で初めて家の電灯の安定器のコンデンサが破裂していく音を聞いた。

「しゅるしゅるしゅる〜〜、ぷぅん」って。

VIA-EN12000EG のコンデンサが減ったった時が、VIA とのお別れですね

VIA EPIA EN の設定のまとめ 2009Q4

気がついてみると VIA EPIA EN12000 と Linux の Tips がたまったので、まとめてみた。

PadLock

1. Debian で VIA の PadLock を使ってみる
2. IPSec のスループット
3. Linux でボリュームを暗号化する (1) - swapの保護
4. Linux でボリュームを暗号化する (2) - LVMの保護
5. Linux でボリュームを暗号化する (3) - 性能比較

Watch Dog Timer

1. VIA EPIA-EN で watchdog を設定

Onboard NIC / VT6122

1. VT6122 の性能(1) - Linux のドライバの準備
2. VT6122 の性能(2) - VIA Velocity の出自
3. VT6122 の性能(3) - ネットワークスループット測定
4. VT6122 の性能(4) - ドライバの強化

VIA EPIA EN のその後 (追記2009/12/09)

性能を使い切るポイントはある程度掴めたので、再度ファイルサーバとして組み直して使う事にした。 高負荷状態になってもたいして速くない電力を食わないので好都合かなぁ。 なので、これ以上このボードに特化したTipsはおしまい。

あれ、、、なぜかGbE-PCI2とGbE-PCIe3が手元にあるのは何故なんだろう。。。

IPSec のスループット

ネットワークのスループットを測定する環境を整えたので、次いでに IPSec を通してた時のものも測定してみた。

測定の条件は

1. スループット測定ツール nuttcp の計測用データチャンネル 5001/tcp を上り／下りにそれぞれ IPSec に通す。
2. racoon ver.1 でサポートされていない暗号化スイートも測定したいので、鍵を手動で設定する。
3. ESP認証／暗号の組み合わせで計測する。(AHは使わん)
4. 追加で IPComp での圧縮の効果を見たい気がする。

複数の認証/暗号の組み合わせで測定する為にスクリプト(measure_ipsec_throughput.sh)化した。

setkey で、手動で鍵を設定する方法は多々情報(1、2)があるので、そちらを参考にして欲しい。ただ、IPComp を組み合わせる例が乏しいのでこの部分だけ。

IPComp を組み合わせて使う

IPSec設定済みで、ESPのみを使うSPDが次にようになってるだろう。

...
spdadd xx.xx.xx.xx[port] yy.yy.yy.yy tcp -P out ipsec esp/transport//require;
...

このときSPDのルールの順番が重要になる。カプセル化の下の方から、要は IPComp ⇒ ESP ⇒ AH の順に書き下していくことになる。

従ってIPCompを組み合わせるには、次のようにすればよい。

...
add xx.xx.xx.xx[port] yy.yy.yy.yy ipcomp zzzz -C deflate;
spdadd xx.xx.xx.xx[port] yy.yy.yy.yy tcp
	-P out ipsec ipcomp/transport//use esp/transport//require;

ただ、ベンチマークに流れるデータは「0」の羅列なので、いまいち効果が分からん。。。

なので計測は諦めた。

IPSec スループットの計測

前とほぼ同じ環境とmacbook pro を加えたものを用意、全ての計測に MTU 1500 / ロック周波数変更は全て無効にしMAXにした。また、TCP/IP通信に関するパラメータを修正せずにデフォルトにした。

• ref1 - M2NPV-VM / Athlon64X2 2.0GHz / DDR2-667 4GB / Intel Pro/1000PT (外付け)
• ref2 - M4A78-EM / Athlon X2 5050e 2.6GHz / DDR2-800 8GB / RTL8112
• via - VIA-EN12000EG / VIA C7 1.2GHz / DDR2-533 1G / VT6122
• osx - MacBookPro5,1 / Intel Core 2 Duo 2.4 GHz / DDR3-1066 2G x 2 / onboard Gigabit Ethernet
• hub - Gigabit Hub(GS908M)

認証/暗号		ref1⇔ref2			ref1⇔via			ref1⇔osx
		throughput (Mbps)	CPU %		throughput (Mbps)	CPU %		throughput (Mbps)	CPU %
			ref1	ref2		ref1	via		ref1	osx
no ipsec	⇒	941.3580	10	28	785.1857	6	50	936.9429	9	54
	⇐	941.2461	17	24	723.7100	12	99	938.3451	18	77
null/null	⇒	934.6834	99	38	566.8947	13	93	932.0707	31	62
	⇐	787.4495	18	46	520.2880	13	99	879.3127	25	99
null/des-cbc	⇒	229.5461	99	8	72.9094	2	95	136.6533	3	14
	⇐	197.0768	14	26	73.4657	4	99	129.1215	6	99
null/3des-cbc	⇒	110.5173	100	4	30.8918	2	87	59.2064	1	7
	⇐	76.8033	11	1	30.5976	1	99	56.5818	3	98
null/aes-cbc	⇒	466.7989	99	33	392.0739	14	91	475.7789	95	43
	⇐	472.1796	28	36	396.2264	17	99	376.3890	22	99
null/aes-ctr	⇒	495.4163	77	58	218.6071	7	71
	⇐	383.9987	16	7	258.7430	17	99
null/blowfish-cbc	⇒	316.0327	99	11	77.6054	3	74	263.7795	15	31
	⇐	244.9774	11	4	84.1580	4	99	228.4810	13	99
null/twofish-cbc	⇒	372.5317	99	19	100.8360	5	73
	⇐	289.2720	15	9	102.0088	5	99
null/camellia-cbc	⇒	340.9916	100	15	86.7841	3	60
	⇐	267.3560	18	5	84.5675	4	99
hmac-md5/null	⇒	537.2857	99	24	244.7170	7	87	578.8675	99	49
	⇐	453.2448	29	14	230.2019	11	99	572.5809	29	99
hmac-sha1/null	⇒	370.0861	100	15	360.3754	20	86	414.4706	99	41
	⇐	296.1913	11	7	350.0287	20	99	469.5587	57	98
hmac-sha256/null	⇒	307.0078	99	16	302.9315	100	41	278.9001	17	33
	⇐	240.0495	12	4	336.2512	19	96	248.9149	28	99
aes-xcbc-mac/null	⇒	447.6017	99	20	216.0013	6	80
	⇐	347.9881	13	12	271.0801	21	99
hmac-md5/3des-cbc	⇒	101.5172	100	5	29.0609	1	88	57.0069	1	7
	⇐	71.0862	11	1	28.4519	1	100	54.5636	4	98
hmac-md5/aes-cbc	⇒	326.0155	99	17	205.8441	9	79	349.0338	80	27
	⇐	266.2639	18	5	198.6511	12	99	296.4431	27	98
hmac-sha1/3des-cbc	⇒	94.1899	100	5	30.1900	1	85	56.6619	1	5
	⇐	66.1646	12	1	29.8474	2	99	52.0154	4	96
hmac-sha1/aes-cbc	⇒	259.3614	99	15	253.1157	99	56	275.3661	98	25
	⇐	202.5055	12	4	286.0077	20	93	270.1091	26	97
hmac-sha1/aes-ctr	⇒	257.3152	99	14	193.6954	4	97
	⇐	199.9059	12	3	209.8745	16	99
aes-xcbc-mac/aes-cbc	⇒	283.0864	99	15	207.2613	11	62
	⇐	225.1556	13	4	233.3907	26	99
aes-xcbc-mac/aes-ctr	⇒	281.3969	99	15	154.4989	7	70
	⇐	220.3145	12	4	178.5399	13	99

異様にたくさん計測したが、あんまり意味が無い気がしないでもない。

• 暗号化方式の性能は
  aes系 > blowfish/twofish/camellia >> DES > 3DES
  VIA C7 では aes系 >> それ以外
• 認証方式の性能は
  hmac-md5 > aes-xcbc-mac > hmac-sha1/hmac-sha256
  ただ、あまり差異はない。
  VIA C7 では hmac-sha1/hmac-sha256 >> それ以外
• des-cbc/3des-cbc は他の暗号化方法に比べて５～１０倍くらい遅い。もう、見る影が無い。
• aes 系の実装には多くの開発リソースが割かれており、x86 コードでも十分早い。VIA PadLock が圧倒的に有利という訳ではない、不利という訳でもない。
• 個々のNICドライバの個性がある。
  e1000e(Linux) / nvenet(MacOSX) に関しては送信時のCPU負荷が100%になる傾向があり、r8169 に関してはどう考えてもCPU利用率が低くなる。
  これが NIC 自体の性能か、TCPと組み合わせで何らかのビジーウェイトが起きるのかは、いまいち不明。。。nuttcp/netperf で発生するトラフィックパータンに対する適性なのだろうか。
  送信性能が上がるチューニングが必要なのだろうか？
• 普通運用する hmac-sha1/aes-cbc は 約250Mbps のスループットが出る。PadLock を使えば同様の性能が出る。

結論

VIA-EN12000EG 上の Linux で IPSec を使うと約250Mbps程度のスループットの性能があり、Athlon64X2 2.0GHz と同程度の性能である。

Intel Atom はどの程度なのだろうかぁ？

VT6122 の性能(4) - ドライバの強化

元々 via-velocity は、少し古いバージョンの velocityget ソースを整理したものだった。ただ、現在の双方のバージョンを比べると、via-velocity に含まれていない要素がある。

• EnableMRDPL (Memory-Read-Multiple)オプション
• VIA 的には「Adaptive Interrupt」と呼ばれるもの
  (txque_timer/rxque_timer/tx_intsup/rx_intsupオプションとその関連部分)

これは、分岐後にVIAによって追加されたものか、意図的に省かれたのもか、どちらなのかは正直分からない。

EnableMRDPL (Memory-Read-Multiple)オプション

最初の要素は、PCIのバースト転送のモードをなんか指定するものらしいが、ベンチマーク上は効果がなかった。 PCIに詳しくなければいまいち内容が分からないし、デフォルトが無効なので、今回は見送った。

VIA 的には「Adaptive Interrupt」と呼ばれるもの

「適応割り込み」と称しているが、単に割り込みを一定数間引いたり、一定時間遅延を入れるだけのようで、 特に割り込みの頻度に応じて動的に変更はしない。。。なんかなぁ

うんで、機能追加パッチを作ってみた。(velocitygetの処理を流用)

1. via-velocity の adaptive interrupt 関連の機能追加パッチ (debian lenny/kernel-2.6.26用) / via-velocity-adaptive-intr.patch

前出の修正パッチの後に当てればいい

# mkdir via-velocity
# cp Makefile-via-velocity-only via-velocity/Makefile
# cp /usr/src/linux-source-2.6.26/drivers/net/via-velocity.[ch] via-velocity/
# patch -p 3 -d via-velocity < via-velocity-fixed-wol.patch
# patch -p 3 -d via-velocity < via-velocity-fixed-int_works.patch
# patch -p 3 -d via-velocity < via-velocity-adaptive-intr.patch
# cd via-velocity
# make install

スループット性能の比較

前回と同じ環境で、velocityget と via-velocityの「Adaptive Interrupt」パッチ有／無の３種類の場合を測定した。

	velocityget			via-velocity パッチ無し			via-velocity パッチあり
	スループット (Mbps)	CPU 利用率		スループット (Mbps)	CPU 利用率		スループット (Mbps)	CPU 利用率
		target	ref1		target	ref1		target	ref1
target ⇒ ref1	655.4841	99 %	11 %	646.4036	99 %	12 %	724.7809	99 %	12 %
target ⇐ ref1	741.2755	66 %	4 %	709.2465	80 %	2 %	762.3420	51 %	5 %

mtu 1500 / DMA_length=6 / それ以外のモジュールパラメータはデフォルト値

	velocityget			via-velocity パッチ無し			via-velocity パッチあり
	スループット (Mbps)	CPU 利用率		スループット (Mbps)	CPU 利用率		スループット (Mbps)	CPU 利用率
		target	ref1		target	ref1		target	ref1
target ⇒ ref1	816.0544	32 %	7 %	816.1541	30 %	7 %	814.9007	31 %	7 %
target ⇐ ref1	989.8745	48 %	9 %	944.4813	46 %	8 %	989.8323	46 %	9 %

mtu 9000 / DMA_length=6 / それ以外のモジュールパラメータはデフォルト値

考察

mtu 1500 のとき、送信性能が10%程度上がった。受信性能はほぼ velocityget と同程度になったが、CPU負荷率は低くなった。mtu 9000 のときは、velocityget と同程度になった。

受信時のCPU負荷率低下は面白い。NAPI化すればより軽くなるのかなぁ。e100?系の適応なんとかの動的アルゴリズムを流用すればもっと良くなるのかなぁ。もっと送信性能を上げるにはどうすれば良いのだろう。。。

スループットのベンチマーク上の結果だけなので、レイテンシとかはどうなんだろう。。。

本来 ethtool へのインタフェース経由で設定するものを、モジュールパラメータに載せて、固定値になっているのも気になると言えば気になる。

ちまちまパッチを切るのは面倒だから、どっかにレポジトリ借りて、最新版のバニラソースに作業するのがいいのかなぁ。

ふぅむ。

近年、VIA の NIC のシェアはかなり落ちている。大抵の onboard NIC は RealTek の奴だったりする。また、Windows 64bit系の4G問題とかも敬遠される原因になっている。

廃れつつ、傾きつつ、そんなものの為に作業する奴がいないんだろうなぁ。

VIA EPIA は本当に不憫な奴だ。

今年分の作業は、この辺かなぁ、、、では

VT6122 の性能(3) - ネットワークスループット測定

スループットを計測するツールは何種類かある。

• ttcp / nttcp / nuttcp
  ttcp が古のツールでソースは色んなバージョン(1,2)が散見される、SGI の人が改良したのが nttcp (元サイトは http://www.leo.org/~elmar/nttcp/ だったらしいが、既に無くなっている)。nuttcp は、nttcp をベースに改良が続けられたもの。使うならば nuttcp かなぁ。
• iperf
  Java ベースの GUI 付きがあるので、ベンリかも
• netperf
  スループット以外にもテスト項目の種類が豊富。ただし、man ページが不完全でなので付属の HTML/PDF を参照する必要がある。
• SmartBits
  商用でよく使われている奴ですね。

まぁ、スループットの測定ならば iperf を使えば良いが、CPU の負荷状況を見たいので nuttcp を使ってみた。

VIA-EN を含めて以下の３台とHUBを用意し、３台ともhubに直結した。

• target - VIA-EN12000EG / VIA C7 1.2GHz / DDR2-533 1G / VT6122
• ref1 - M2NPV-VM / Athlon64X2 2.0GHz / DDR2-667 4GB / Intel Pro/1000PT (外付け)
• ref2 - M4A78-EM / Athlon X2 5050e 2.6GHz / DDR2-800 8GB / RTL8112
• hub - Gigabit Hub(GS908M)

また、測定自体は、clock skew を避けるため全て ref1 上で計測した。cpufreq によるクロック周波数変更は全て無効にしMAXにした。 ref2 に関しては ref1 自体の評価にのみ使った。

ref1 ⇔ ref2 間

ref1 / ref2 ともに mtu 1500 に設定して測定した。

# ssh -f ref2 -- "nuttcp -S -1"
# nuttcp -t ref2
 1123.8690 MB /  10.01 sec =  941.3733 Mbps 11 %TX 27 %RX
# ssh -f ref2 -- "nuttcp -S -1"
# nuttcp -r ref2
 1122.3750 MB /  10.00 sec =  941.0966 Mbps 33 %TX 16 %RX

これを表にすると、

	スループット (Mbps)	CPU 利用率
		ref1	ref2
ref1 ⇒ ref2	941.3733	11 %	27 %
ref1 ⇐ ref2	941.0966	16 %	33 %

mtu 1500

まぁ、順当に ref1 は送受信ともに約 940Mbps 程度の性能を持っている事が分かる。

target ⇔ ref1 間

target の ドライバ via-velocity/velocityget のそれぞれに対して、mtu 1500 かつモジュールパラメータを設定せずに(ドライバのデフォルト値で)計測した。

	velocityget			via-velocity
	スループット (Mbps)	CPU 利用率		スループット (Mbps)	CPU 利用率
		target	ref1		target	ref1
target ⇒ ref1	655.2174	99 %	12 %	340.1681	27 %	9 %
target ⇐ ref1	738.7987	68 %	3 %	514.5900	42 %	2 %

mtu 1500 / モジュールパラメータは全てデフォルト値

熟考

結果を見れば、明らかに velocityget の方が性能が高いように思われるが、ソースを見比べるとモジュールパラメータ DMA_length のデフォルト値が、それぞれのドライバで異なる (velocitygetは6/via-velocityは0)。

DMA_length は、チップ内のバッファとメインメモリの間を転送する DMA の処理サイズを指定するらしく、大きなサイズであれば PCI バスの使用効率が上がるので、スループットに影響しそうである。

なので、DMA_length を 0〜7 に振って再度計測し直してみた。

	DMA_length	velocityget			via-velocity			比 (via-velocity /velocityget)
		スループット (Mbps)	CPU 利用率		スループット (Mbps)	CPU 利用率
			target	ref1		target	ref1
target ⇒ ref1	0	369.5053	28 %	11 %	340.1827	27 %	10 %	0.920643
	1	398.9382	39 %	11 %	414.5747	40 %	7 %	1.039195
	2	497.4004	64 %	9 %	494.2757	60 %	8 %	0.993717
	3	539.0356	84 %	9 %	540.7160	80 %	10 %	1.003117
	4	610.5743	99 %	10 %	608.1031	99 %	10 %	0.995952
	5	646.1530	99 %	11 %	640.9711	99 %	10 %	0.991980
	6	655.4841	99 %	11 %	646.4036	99 %	12 %	0.986146
	7	652.1732	99 %	12 %	647.7397	99 %	10 %	0.993201
target ⇐ ref1	0	450.8850	36 %	2 %	502.9532	42 %	2 %	1.115480
	1	490.2150	38 %	2 %	580.6518	56 %	2 %	1.184483
	2	599.5584	48 %	3 %	642.5684	63 %	2 %	1.071736
	3	661.0592	52 %	3 %	685.1753	74 %	3 %	1.036480
	4	719.6965	64 %	3 %	709.9482	83 %	3 %	0.986454
	5	731.3209	69 %	5 %	710.1113	80 %	3 %	0.970998
	6	741.2755	66 %	4 %	709.2465	80 %	3 %	0.956792
	7	738.2975	65 %	3 %	710.1459	82 %	3 %	0.961869

mtu 1500 / モジュールパラメータはDMA_length以外はデフォルト値

DMA_length の値を合わせれば、送受信のスループットに関しては velocityget/via-velocity にほとんと差異は無く、強いて言えば velocityget の方が受信に関して 4〜5% 高く、処理が軽い。送信に関しては双方同じ程度に CPU を使い切って頭打ちになっている。VIA C7 では 1Gbps は吐けないのかぁ。。。

まぁ、DMA_length は velocityget のデフォルト値の 6 が推奨値かなぁ。ちなみに、NetBSDでのドライバ vge だと 4 だった。

ただ、DMA_lengthの値でスループットの差異が出るのは VT6122などのPCIベースの場合だけで、PCIe ベースの VT6130 ではどの値でも違いが無かった。。。多分省かれてしまったのでしょう。

さて、velocityget にだけあるっぽい機能を移植していけば、差異が無くなっていくのかなぁ？

MTU 9000 での測定

そういえば、mtu 9000 のスループットも測定をしたかったで Intel Pro/1000PT を外付けしたんだっけなぁ。なので、測定してみた。

	velocityget			via-velocity
	スループット (Mbps)	CPU 利用率		スループット (Mbps)	CPU 利用率
		target	ref1		target	ref1
target ⇒ ref1	816.0544	32 %	7 %	816.1541	30 %	7 %
target ⇐ ref1	989.8745	48 %	9 %	944.4813	46 %	8 %

mtu 9000 / DMA_length=6 / それ以外のモジュールパラメータはデフォルト値

受信に関しては、ほぼ 1Gbps を使い切っている！凄し！

追記 (2009/10/06)

今回使ったスループット測定用のスクリプトmeasure_net_throughput.shをバックアップとして上げておく。

VT6122 の性能(2) - VIA Velocity の出自

velocitygetのソースを眺めていると VT3119 とか VT3216とか一見全く関係無さそうなチップ名らしき物が出てくる。 VT6122 の Device ID が 0x3119 なのでVIA内部型番になっているのかなぁ。 でも、ドライバ内では Rev ID での区別らしきものがあり、それに従うと VT6122 = VT3216 (?)っぽい。

正直のところ VIA に聞かないと分からないし、検索でもホンの僅かの情報しか引っ掛からないので、 憶測程度にしかならないが、ちょっとだけ書き残しておこう。

VT6110

ここら辺の事情は、ほんとに雲をつかむような感じだ。。。

ZyXEL社の Gigabit NIC (GN650-T/GN670-T) が最初の製品っぽい。そいつが VIA 内部では Device ID と関連づけて、多分 VT3119 と呼ばれていたんだろう。コイツにはまだ PHY が内蔵されておらず、ZyXEL の製品には PHY が載っている。それが CICADA製SimpliPHY のもの。

ZyXEL へのOEM供給?でチップの型番はZX1701Z/X1702になっているが、VIA が外販する時に VT6110 と付けたんだろうと推測できる。

参照

1. BSD系のドライバ vgeには、ZyXEL 製のNICとVT3119 の記述がある。
2. ZyXELのサイトには情報は殆どないが、Download Search で検索するととドライバ(rhineget 1.10/velocityget 1.18)が見つかる。
3. ロシアでは結構流通した製品らしく、検索（"Zyxel Omni LAN PCI G1"）に出てくる。カード全体の鮮明な画像も出てくる。SimpliPHYのマークのチップが見てとれる。
4. rhineget/velocityget 内の chip_info_table には、CHIP_TYPE_VT6110 のマクロがある。
5. Gentooのフォーラムの記事に、GN650-T の lspciの出力があり、Rev 01 となっており、ソース内では REV_ID_VT3119_A1 に相当する。REV_ID_VT3119_A0 というのは開発版なのかなぁ。。。

VT6120/VT6121/VT6122

VT6110 に SimpliPHYを内蔵して１チップ化したものが、良く知っている VIA Velocity と呼ばれてる製品群で、 PCIのバスサイズが32bit/64bitのものがそれぞれがVT6120/VT6121で、VT6120 のパッケージを小型したのが VT6122 である。

内部的には VT3216 の型番が付いてると思われるが、ドライバが流用できるほど上位互換なので、Device ID が 0x3119 のままになったようである。

以後、Rev ID の範囲で区別する方針になったのか、0x00〜0x0F が ZX1701Z/X1702/VT6110 であり、0x10 〜 0x1F　が VT6120/VT6121/VT6122 のどれかにあたる。ちなみに EPIA-EN12000EG に載っているのは 0x11 になっている。

性能アップのための機能で Tx/RX キューに関するなんかのタイマーが追加されている。

Rev ID が 0x20〜0x7fのもの

該当する製品が見つけられなかった。。。内部的には VT3284 の型番が付いていると思われる。

velocityget を読む限り、PCI のバースト転送に Memory-Read-Multiple が使えるようになったっぽい。なんのコッチャ、、、

Rev ID が 0x80 〜

PCIe に対応した VT6130/VT6132 が該当する。内部的には、VT3286 の型番が付いてると思われる。

どうも PCIe 化と同時に省かれた機能があるっぽいが、ドライバでは何も対処してないっぽい気がする。

まとめ

Device ID 0x3119 のデバイスは、Rev ID の範囲でチップを区別してるらしい（もしかしたら、特定の Rev ID リストが作れるかも）。

Rev ID	内部型番	チップ名
0x00 ～ 0x0f	VT3119	ZX1701Z/X1702/VT6110
0x10 ～ 0x1f	VT3216	VT6120/VT6121/VT6122
0x20 ～ 0x7f	VT3284	不明
0x80 ～	VT3286	VT6130/VT6132

但し書き

元になるデータが凄く不確かであり、かなりの憶測が含んでいる(ほとんどが要出典)。あまり信用できる情報ではありませんのであしからず。

Linux の iSCSI

Linux で iSCSI を、やるならば先ず「iSCSI Enterprise Target (IET)」である。そして、kernel に取り込まれてる iSCSI システムが別にあるよってなる。

それって何だろう？

「Linux SCSI target framework (STGT)」がそれらしい。iSCSIに限らず Fiber Channel などの一般的な SCSI Target を対象に絶賛開発中らしい。ユーザランドのコマンドは RHEL5系でscsi-target-utils として提供されいるので、結構安定してるかも。ただ、Debian にはまだ無いっぽい。

あと、別系統として、「generic SCSI target subsystem for Linux (SCST)」てのがある。

三種類の比較表を見ると、SCST が多機能で高性能っぽい。今後が楽しみだなぁ

VT6122 の性能(1) - Linux のドライバの準備

VIA EPIA は不憫な奴だ。

去年から消費電力が低い Intel Atom ボードが出荷され、当初性能がわずかに上かなぁ〜と思われた後で、Dual-Core だとか Hyper-Threading とかが追加され、もう比べるのも可哀想なぐらい、次いでに Mini-ITX のボードの市場も荒らされまくり、踏んだり蹴ったりのボコボコにされてますなぁ、、、なんか違うかも。

何の気の迷いか EPIA-EN12000EG を買ってしまって以来、 不憫な奴が故に捨てられずに、年に１回くらいは思い出したように手を入れて使っている。。。はぁ〜

今回は NIC の性能について愚痴ってみよう。

EPIA-EN12000EG には VT6122 (Gigabit Ethernet) が搭載されている。Datasheet(pdf) を見る限り、South Bridge / VT8237R+ の下のPCIバス(32bit/33MHz)にぶら下がっている。PCIバス(32bit/33MHz) の上限 133MByte/s がボトルネックになるので期待は出来ない。PCIe 接続の VT6130/VT6132 でないなければ Gigabit の限界には迫れないが、どれくらい迫れるかが興味の有るところ。

二種類のドライバ

VT6122のLinux ドライバは二種類で、どっちも些細なバグが有る。

1. via-velocity / kernel 本家に取り込まれているもの。性能が低いのがもっぱらの噂。WOL が動かない。
2. velocityget / VIA 本家作成のドライバ。VIA AREA で公開されているが、ダウンロードページに辿り着くまでが迷路というか、ほんとに無理。現在(2009/09/23)の時点で、1.36 が安定版らしい。 rmmod/insmod を繰り返すと dmesg に 不審な oops を残す不具合あり。

で、修正パッチを作ってみた。

1. via-velocity の WOL 対応パッチ (debian lenny/kernel-2.6.26用) / via-velocity-fixed-wol.patch
2. velocityget の procエントリのリークフィックパッチ / velocityget-fixed-proc.patch

via-velocity単体で再構築

via-velocity 単体だけでも再構築できるようにしてみよう。ターゲットは、Debian lenny の 2.6.26-2-686 向けだが、他のディストロでも応用可能かなぁ。

# apt-get install linux-headers-2.6.26-2-686
# apt-get install linux-source-2.6.26

構築用ソースのかき集め

1. 適当にでっち上げた Makefile / Makefile-via-velocity-only
2. linux-source-2.6.26 パッケージからvia-velocity.[hc]

# mkdir via-velocity
# cp Makefile-via-velocity-only via-velocity/Makefile
# cp /usr/src/linux-source-2.6.26/drivers/net/via-velocity.[ch] via-velocity/
# patch -p 3 -d via-velocity < via-velocity-fixed-wol.patch

あとは再構築してモジュールをインストール。

# cd via-velocity
# make install
make -C /lib/modules/2.6.26-2-686/build SUBDIRS=/usr/src/via-velocity modules
make[1]: ディレクトリ `/usr/src/linux-headers-2.6.26-2-686' に入ります
  CC [M]  /usr/src/via-velocity/via-velocity.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /usr/src/via-velocity/via-velocity.mod.o
  LD [M]  /usr/src/via-velocity/via-velocity.ko
make[1]: ディレクトリ `/usr/src/linux-headers-2.6.26-2-686' から出ます
mkdir -p /lib/modules/2.6.26-2-686/kernel/drivers/net
*****  Move current driver via-velocity.ko to via-velocity.ko.2009-09-24-1253781710 file
mv /lib/modules/2.6.26-2-686/kernel/drivers/net/via-velocity.ko /lib/modules/2.6.26-2-686/kernel/drivers/net/via-velocity.ko.2009-09-24-1253781710

install -m 644 -o root via-velocity.ko /lib/modules/2.6.26-2-686/kernel/drivers/net
/sbin/depmod -a || true

最後に rmmod/modprobe してモジュールを更新して完了。

これで機能的には同程度になったので、性能比較でもしますかぁ。

追記 (2009/09/26)

どうも via-velocity には、ネットワーク負荷が高いときにシステムが黙りをする症状(1,2 等々)？が報告されている。velocityget を使えば症状が出ないので、velocitygetを使うべしとなってるらしい。。。

ソースを見比べると、割り込みハンドラ内の処理が問題のようだ。それぞれは、大まかに次のようになっている。

• via-velocity
  1. 未処理の割り込み要因がなくなるまでループする
  2. ループの一単位は、受信/送信ディスクリプタをそれぞれ最大15ディスクリプタ分を処理する
  3. 処理したディスクリプタ数が int_works を超えたらメッセージを出力する
• velocityget
  1. 受信/送信ディスクリプタをそれぞれ最大int_worksディスクリプタ分を処理する
  2. 上記の処理を２回繰り返す

要するに via-velocity では int_works の取り扱いが杜撰で、かつネットワーク負荷が高いと割り込みハンドラ内に捕われてしまう。なので、割り込みを共有してるデバイスの処理が滞る症状が現れる。

他のネットワークチップのドライバーを見る限り、割り込みハンドラ内で全部のディスクリプタを処理せずに抜ける実装は多々有るので、バグなんだろうなぁ。

うんで、修正パッチを作ってみた

1. via-velocity の int_works 関連の修正パッチ (debian lenny/kernel-2.6.26用) / via-velocity-fixed-int_works.patch

上のWOL対応パッチの後に当てればいい

# tar xfz via-velocity-buildpack-nosrc.tgz
# cp /usr/src/linux-source-2.6.26/drivers/net/via-velocity.[ch] via-velocity/
# patch -p 3 -d via-velocity < via-velocity-fixed-wol.patch
# patch -p 3 -d via-velocity < via-velocity-fixed-int_works.patch
# cd via-velocity
# make install

これで、本当に不具合が無い状態？になったので、性能比較でもしますかぁ。

追記 (2009/09/29)

どうも via-velocity-fixed-int_works.patch の velocity_tx_srv の修正部分がバグってたみたいだ。なので、修正版に差し替えました。申し訳ない。

Time Machine を iSCSI 経由で使う (3) - 性能比較

ボリュームをiSCSIの載せたときの性能と、IPSecで保護した場合やWiFi経由にした場合の性能劣化を測定してみた。

設定条件

接続の経路に結構余分な機器が挟まっているが、 測定用に別環境は用意していないためである。 実環境ベースと考えて勘弁してもらいたい。

Linux ターゲット側

• ASUS M2NPV-VM / Athlon64X2 3800+ (2GHz) / DDR2-533 1G x 4
• onboard Gigabit Ethernet (nVidia MCP51)を利用。

Mac OSX のイニシエータ側

• MacBookPro5,1 / Intel Core 2 Duo / 2.4 GHz / DDR3-1066 2G x 2
• onboard Gigabit Ethernet / AirMac(WiFi) を利用。
• Wifi経由では 802.11n/WPA2でアクセスポイントに接続

接続形態

• ローカルHDD
  MacBookPro
  ⇔ ExpressCard(GH-EXC-ESA2/eSATA接続) ⇔ HDDケース(LHR-DS02SAU2BU) ⇔ HDD
• 有線ネットワークでは
  MacBookPro
  ⇔ Gigabit Hub(LSW-GT-8NSR)
  ⇔ Gigabit Hub(GS908M) ⇔ Gigabit Hub(GS908M)
  ⇔ Linux マシン(SATA接続) ⇔ HDD
• Wifi経由では
  MacBookPro
  ⇔ AirMac Extreme (2007モデル？有線100Baseの奴)
  ⇔ Gigabit Hub(GS908M) ⇔ Gigabit Hub(GS908M)
  ⇔ Linux マシン(SATA接続) ⇔ HDD

測定したHDD

• SATA 320G HDD(ST3320620AS)
• 3.0Gbps が有効になる用にジャンパー設定
• iSCSI／ローカル接続でも同じモデルを利用

測定結果

		ローカルHDD	GigaEther	Wifi経由	GigaEther	Wifi経由
			IPSec 無		IPSec 有
Sequential	Uncached Write [4K blocks]	58.19	60.51	5.34	13.15	5.48
	Uncached Write [256K blocks]	47.58	50.82	7.33	12.65	4.72
	Uncached Read [4K blocks]	16.16	6.02	1.46	4.75	1.38
	Uncached Read [256K blocks]	75.55	28.86	3.39	15.86	4.90
Random	Uncached Write [4K blocks]	1.25	1.36	1.32	1.35	1.26
	Uncached Write [256K blocks]	26.19	24.37	6.19	13.10	6.93
	Uncached Read [4K blocks]	0.64	0.61	0.45	0.58	0.43
	Uncached Read [256K blocks]	26.68	23.66	3.21	11.17	4.63

測定単位は全て MByte/sec

ゴタク

iSCSI を有線／noIPSec で通す場合、シーケンシャル読込み以外はほとんど劣化が無い。 シーケンシャル読込みはキャッシュがほとんど効かない為か、iSCSIターゲット実装の良し悪しが出ていると思う。 また、チューニングを実施せずにデフォルト設定にしているので、それも影響しているのかも。

IPSec で保護すると、約120Mbps (15Mbyte/sec) 程度で頭打ちになっている。IPSec の実効帯域と思われる。Gigabit Ethernet なのに帯域が一割程度とはちょっと情けない。IPSec 固有の問題か、Linux の実装の問題か、iSCSI との組み合わせか、判然としない。何処に文句を言っていいのか分からない。

iSCSI を無線にした場合は、大きな問題は経路の帯域である。iSCSIとか、IPSec の有無とかは、もはや問題ではない。周囲の電波状況によって影響を受けるが、WPA2で50Mbpsくらいは流れるので良いのかなぁ。

結論

iSCSIをIPSecで保護することは、 無線を使って Time Machine でバックアップすることには殆ど影響しないと言えそうだ。 また、差分は一時間に一度であり、有線であっても約 120Mbps 程度の帯域を確保できることを考えると、 目くじらを立てるものではないのかなぁ。

Time Machine を iSCSI 経由で使う (2) - IPSecで保護

iSCSI はブロックデータが Network 上に流れるので気を付けなくはいけない。 専用のネットワークかVLANとかを組むのが定石らしいが、そうでない場合 IPSec が使うのが望ましいらしい。

設定が面倒で、大抵ノーガードですなぁ。

MacOSX でも普通にIPSecが使えるので、iSCSI のデータのみを保護する設定をしてみよう。

IPSec の設定内容

1. Linux と Mac OSX の相互にIPSec接続をする。
2. 既に iSCSI の設定が済んでおり、Linux側のiSCSIターゲットボリュームをMacOSX側のiSCSIイニシエータからマウントできる。
3. IPSec はトランスポートモードで使い、iSCSI のデータ(3260/tcp)に限定する。
4. IKE デーモンは racoon (IKEv1) を使う。
5. 認証は事前共有秘密鍵／aggressive mode を使う。
6. 暗号はAES/SHA1をなるべく使う。

	役割	IPアドレス	ホスト名
Linux 側	iSCSIターゲット	192.168.0.10/24 (固定)	server1
MacOSX 側	iSCSIイニシエータ	192.168.0.20/24	client1

SADの設定

基本的に、上りと下りのそれぞれで、サーバ側のIPアドレスとポート番号を指定すれば、iSCSI通信のみに限定できる。クライアント側は、DHCP等で振れる事を考えて範囲指定にする。

BSDの実装では PF tag なるものがあり「spdadd tagged」と組み合わせてフィルタルールに溶け込ませる事ができるそうなのだが、Linux側では同等の機能が実装されていないようなので残念ですなぁ。。。

Linux ターゲット側

# apt-get install ipsec-tools

/etc/ipsec-tools.conf

...
flush;
spdflush;

spdadd 192.168.0.10[3260] 192.168.0.0/24 tcp -P out ipsec esp/transport//require;
spdadd 192.168.0.0/24 192.168.0.10[3260] tcp -P in ipsec esp/transport//require;

Mac OSX のイニシエータ側

MacOSXでは、setkey 用の設定ファルの置き場がデフォルトでは用意されていないので、適当な場所に保存して、起動時に setkey コマンドで読み込み必要がある。

/etc/racoon/setkey.conf

flush;
spdflush;

spdadd 192.168.0.0/24 192.168.0.10[3260] tcp -P out ipsec esp/transport//require;
spdadd 192.168.0.10[3260] 192.168.0.0/24 tcp -P in  ipsec esp/transport//require;

racoonの設定

Linux/MacOSX ともに、racoon を使うので設定ファイル racoon.conf の内容はほぼ同じになる。ただし、事前共有秘密鍵ファイル psk.txt は、同じ鍵をそれぞれの相手側のものとして書く必要があり、ちょっと注意が必要。

Linux ターゲット側

/etc/racoon/racoon.conf

...
remote anonymous {
	exchange_mode aggressive,main;
	my_identifier fqdn "server1";	# サーバの認識情報
	dpd_delay 20;

	proposal {
		encryption_algorithm 3des;
		lifetime time 2 hour;
		hash_algorithm sha1;
		authentication_method pre_shared_key;
		dh_group 2;
	}
	generate_policy off;
}

sainfo anonymous {
	pfs_group 2;
	lifetime time 1 hour;
	encryption_algorithm aes, 3des;
	authentication_algorithm hmac_sha1;
	compression_algorithm deflate;
}

/etc/racoon/psk.txt

...
client1	secret1

Mac OSX のイニシエータ側

他にVPNなど IPSec を使うものと衝突する可能性がある気がしないでも無い。。。anonymous の部分をアドレス指定しれば、行けそうな気がするが。。。未検証。

/etc/racoon/racoon.conf

...
remote anonymous {
	exchange_mode aggressive,main;
	my_identifier fqdn "client1";	# クライアントの認識情報
	dpd_delay 20;

	proposal {
		encryption_algorithm 3des;
		lifetime time 2 hour;
		hash_algorithm sha1;
		authentication_method pre_shared_key;
		dh_group 2;
	}
	generate_policy off;
}

sainfo anonymous {
	pfs_group 2;
	lifetime time 1 hour;
	encryption_algorithm aes, 3des;
	authentication_algorithm hmac_sha1;
	compression_algorithm deflate;
}

/etc/racoon/psk.txt

...
server1	secret1

racoonは自動に起動しないので、適当名タイミングで起動する必要はある。

% sudo setkey -f /etc/racoon/setkey.conf
% sudo racoon

自動起動するには、「マスタリングIPsec 第2版」に記述の方法が簡単である。

確認

IPSec はアプリケーション側の修正の必要の無い物なので、、、普通にボリュームをマウントすると普通に使える。

まぁ気休めに、IPSec_SAをチェックすれば、

# setkey -D
192.168.0.20 192.168.0.10 
	esp mode=transport spi=131341201(0x07d41b91) reqid=0(0x00000000)
	E: aes-cbc  8250b455 59cc8799 c0d0b0b0 71b570a8
	A: hmac-sha1  6ff81843 b28130ed a5722694 32b134ee a0fc5b96
	seq=0x00000000 replay=4 flags=0x00000000 state=dying 
	created: Sep  8 14:51:43 2009	current: Sep  8 15:40:54 2009
	diff: 2951(s)	hard: 3600(s)	soft: 2880(s)
	last: Sep  8 14:51:45 2009	hard: 0(s)	soft: 0(s)
	current: 50750612(bytes)	hard: 0(bytes)	soft: 0(bytes)
	allocated: 49393	hard: 0	soft: 0
	sadb_seq=1 pid=1233 refcnt=0
192.168.0.10 192.168.0.20 
	esp mode=transport spi=17664308(0x010d8934) reqid=0(0x00000000)
	E: aes-cbc  5d2d422b fe916f6d 501fedce e3d9650d
	A: hmac-sha1  6cfbf657 2eb74cb3 b64b5074 e34148b9 7bcaf934
	seq=0x00000000 replay=4 flags=0x00000000 state=dying 
	created: Sep  8 14:51:43 2009	current: Sep  8 15:40:54 2009
	diff: 2951(s)	hard: 3600(s)	soft: 2880(s)
	last: Sep  8 14:51:45 2009	hard: 0(s)	soft: 0(s)
	current: 2142076(bytes)	hard: 0(bytes)	soft: 0(bytes)
	allocated: 26881	hard: 0	soft: 0
	sadb_seq=2 pid=1233 refcnt=0

ついでに tcpdump でサーバ側のパケットの流れを見れば、ESPパケットが飛び交ってるのが見える。。。

# tcpdump -i eth0 not port 22
...
15:38:24.183860 IP client1 > server1: ESP(spi=0x07d41b91,seq=0xc0ba), length 116
15:38:24.184162 IP server1 > client1: ESP(spi=0x010d8934,seq=0x68e6), length 116
15:38:24.184625 IP client1 > server1: ESP(spi=0x07d41b91,seq=0xc0bb), length 68
15:38:27.186886 IP client1 > server1: ESP(spi=0x07d41b91,seq=0xc0bc), length 116
...

まとめ

SADの設定をちまちま行えば、他の通信もIPSecで保護が出来そうである。気になるのは、パフォーマンスがどこまで劣化するかなのだが。。。あまり期待は出来ないのかなぁ。。。

Time Machine を iSCSI 経由で使う (1) - 設定

Leopard から実装された Time Machine は非常に使い易い。 ただ、常にノートブックに外付けのHDDをぶら下げるのは、可搬性が損なわれる。 Time Capsule を使えば良いのだが、約10M Byte/s 位しか出ないらしい。

どうも iSCSI 経由で外部ストレージを繋げてバックアップ先に指定すれば、いい感じになれるらしい。

最近 Linux でよく使われているターゲットは「iSCSI Enterprise Target」であり、Debian lenny からカーネルモジュールもパッケージ化されており、apt 一発で使える。また、ストレージ層は Linux に依存しており、フォーマット縛りが無い。そのため、HDD単体をiSCSI経由で接続して使っていた場合、そのHDDをUSB等の変換アダプタで直に接続しても、そのままで使える利点がある。

Mac OSX のイニシエータは標準では用意されていないが、サードベンダー製の「globalSAN iSCSI Initiator for OS X」が無料で制限なしで利用できる。

コイツらを組み合わせると、Time Machine の初期化やリカバリ時だけマシンに直付けして、差分バックアップ運用時はiSCSI経由で行う事が出来る。

Linux で iSCSI target 設定

設定の内容は、

1. お手軽な単方向CHAP認証を使い、ユーザ名 iscsiadmin ／パスワードは12～16文字の適当な文字列にする。
2. IQN(ISCSI Qualified Name)は iqn.YYYY-MM.domainなんたらをユニークになるように適当に付ける。
3. デバイスの名前に関しては、固定される用に /dev/sd? ではなく /dev/disk/by-id/? を使う。
4. イニシエータ制限をサブネット範囲でかけておく。

Debian lenny にバイナリパッケージが用意されている。

# apt-get install iscsitarget iscsitarget-modules-2.6-amd64

/etc/default/iscsitarget

ISCSITARGET_ENABLE=true

/etc/ietd.conf

IncomingUser iscsiadmin 123456789012

Target iqn.2009-09.com.example:stroage.fileserver.timemachine
	IncomingUser iscsiadmin 123456789012
	Lun 0 Path=/dev/disk/by-id/scsi-XXXXXX,Type=blockio

/etc/initiators.allow

ALL xx.xx.xx.xx/24

うんで、/etc/init.d/iscsitargt start で、iSCSI ターゲットのサービスを有効化する。

Linux の Open-ISCSIを使って確認

適当な iSCSI イニシエータが必要なので、Open-iSCSI を設定して確認する。

# apt-get install open-iscsi

/etc/iscsi/iscsid.conf

...
node.session.auth.authmethod = CHAP
node.session.auth.username = iscsiadmin
node.session.auth.password = 123456789012
...
discovery.sendtargets.auth.authmethod = CHAP
discovery.sendtargets.auth.username = iscsiadmin
discovery.sendtargets.auth.password = 123456789012
...

うんで、/etc/init.d/open-iscsi start で、iSCSI イニシエータのサービスを有効化する。

取り敢えず、検索すると

# iscsi_discovery xx.xx.xx.xx
iscsiadm: No active sessions.
Set target iqn.2009-09.com.example:stroage.fileserver.timemachine to automatic login over tcp to portal xx.xx.xx.xx:3260
Logging out of session [sid: 5, target: iqn.2009-09.com.example:stroage.fileserver.timemachine, portal: xx.xx.xx.xx,3260]
Logout of [sid: 5, target: iqn.2009-09.com.example:stroage.fileserver.timemachine, portal: xx.xx.xx.xx,3260]: successful
discovered 1 targets at xx.xx.xx.xx

何となく、ターゲットが発見できる。

ついでに、ノードに接続して確認すると

# iscsiadm -m node -p xx.xx.xx.xx -l
Logging in to [iface: default, target: iqn.2009-09.com.example:stroage.fileserver.timemachine, portal: xx.xx.xx.xx,3260]
Login to [iface: default, target: iqn.2009-09.com.example:stroage.fileserver.timemachine, portal: xx.xx.xx.xx,3260]: successful
# cat /proc/scsi/scsi
...
Host: scsi27 Channel: 00 Id: 00 Lun: 00
  Vendor: IET      Model: VIRTUAL-DISK     Rev: 0   
  Type:   Direct-Access                    ANSI  SCSI revision: 04
...
# iscsiadm -m node -p xx.xx.xx.xx -u
Logging out of session [sid: 7, target: iqn.2009-09.com.example:stroage.fileserver.timemachine, portal: xx.xx.xx.xx,3260]
Logout of [sid: 7, target: iqn.2009-09.com.example:stroage.fileserver.timemachine, portal: xx.xx.xx.xx,3260]: successful

まぁ、ディスクが見える！

Mac OSX 上での設定

globalSAN iSCSI Initiator for OS Xから、パッケージをインストールして再起動し、GUIに従って設定すれば良い。

1. 「システム環境設定」から「globalSAN iSCSI」を選択
2. 「Portals」タブで、ターゲットマシンのIPを追加する。このとき、「Advanced Settings」で、CHAP認証を有効にして、User Name/Target Secret をISCSIターゲットで設定したものにする。
3. 「Targets」タブにISCSIターゲットのIQNが見えるようになる。
4. ISCSIターゲットのIQNを選択して「Log On」をする。
5. 後の扱いはローカル接続のHDDと同じで、必要に応じて「ディスクユーティリティ」で初期化する。

Time Machine の設定は、ローカル接続のHDDと同じような扱いで、HFS+のボリュームを作って指定すれば普通に使える。。。快適じゃぁ。。。

Linux でボリュームを暗号化する (3) - 性能比較

ボリュームを暗号化する上で気になることは、どれくらいIOの性能が落ちるかである。

普通にそこら辺にある２台でベンチを取ってみた。

• ASUS M2NPV-VM / Athlon64X2 3800+ (2GHz) / DDR2-533 1G x 4
• EPIA-EN12000EG (C7 1.2GHz) / DDR2-533 1G

暗号化するのは、ちゃっと起動用とは別に確保してた SATA 320G HDD(ST3320620AS) を使った。次いでなので、VIA PadLock の有無も比較してみた。

測定は hdparm -t を使って３回で最も良い値を使った。

	読み込み速度(MB/sec)	比
M2NPV-VM (2GHz) - 素	74.82
M2NPV-VM (2GHz) - cryptoあり	71.65	0.96
M2NPV-VM (1GHz) - cryptoあり	36.10	0.48
EPIA-EN12000EG - 素	76.04
EPIA-EN12000EG - cryptoあり/PadLock 有	43.26	0.57
EPIA-EN12000EG - cryptoあり/PadLock 無	12.64	0.17

格段に劣化する訳では無さそうで、 ファイルシステムが絡めば DiskIO と暗号化処理が並列化しそうなので、 気にならない程度に落ち着くのかなぁ。。。

あと VIA PadLock は結構効果があり、in-order 1.2G だけだと非力なのかぁ？

Intel Atom だとどの程度になるか気になるなぁ〜。。。それとも Atom 系に AES-NIが実装されるのを気長に待つ方がいいのかなぁ。。。

修正(2009/09/08)

Athlon64X2 は cpufreq の ondemand governor を使ってたため、どうも結果が怪しかったので、クロックを固定して再度計測し直した。

結果、Athlon64X2に関しては 結構クロック周波数に比例した性能であり、2GHz 程度の性能があれば汎用CPUには苦にならないようである。C7は PadLock を使うとやっと一人前であるが、他を凌駕する性能とかは無さそうだなぁ。。。

Linux でボリュームを暗号化する (2) - LVMの保護

最近は、起動用の小容量HDD/SSDと複数データ用の大容量HDDの組み合わせでPCを組んでいる。SSDが手頃な価格になれば、その傾向も大きくなると思う。起動用のHDDの暗号化は、手法が多く、それぞれに結構面倒設定が多いし、どんどん新しい手法が出てきそうだし、枯れるまで様子見の方がいいかなと思う。なので、データ用の大容量HDDを暗号化することのみを考える。

次のサイトを参考に設定した。

• LinuxでLVM領域を暗号化: 導入

PC
- 起動用 HDD/SDD
  /dev/sda
- データ用 大容量HDD (今はこっちだけ暗号化)
  /dev/sdb

古いデータの消去とパーティションの作成

新品のHDDを買ってきたのならば必要は無いが、念のため古いデータを乱数で上書きする。全容量を一つのパーティションに割り当てる構成にする。

# shred -n 3 -v /dev/sdb
# echo "0,,8e" | sfdisk -D /dev/sdb

LUKSパーティションの作成

LUKSパーティションには２種類のキースロットを割り当てる

1. パスフレーズ(難解で長文なもの)を使う奴 -- 運用上何かと必要
2. キーファイルを使う奴

# cryptsetup --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sdb1
...
Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase: <= パスフレーズを入力
Verify passphrase: <= パスフレーズを入力
...
# mkdir -m 700 /etc/luks
# dd if=/dev/random of=/etc/luks/data01.key bs=1 count=32
# chmod 400 /etc/luks/data01.key
# cryptsetup luksAddKey /dev/sdb1 /etc/luks/data01.key
Enter LUKS passphrase: <= パスフレーズを入力
key slot 0 unlocked.
...

起動時にキーファイルを使って自動的に開始する設定

/etc/crypttab

# <target> <source>  <key file>  <options>
crypt-sdb1 /dev/sdb1 /etc/luks/data01.key luks
...

後は再起動するか、次のコマンドで暗号化を開始しとく。

# cryptdisks_start crypt-sdb1

VGの作成

出来上がったブロックデバイスを使って、LVMを組めば良く。

# pvcreate /dev/mapper/crypt-sdb1
  Physical volume "/dev/mapper/crypt-sdb1" successfully created
# vgcreate Data01 /dev/mapper/crypt-sdb1
  Volume group "Data01" successfully created

Volume Group が作成まで出来れば、あとは普通のLVMの使い方そのものなので、略。。。

まとめ

キーファイルを起動用ディスク内に保存することで、データ用ディスクが単体で切り離された場合にデータが保護できるようになるし、先頭ブロックの1MBくらいを消去することで完全に破棄することも可能になる。

これで 1T級HDD の破棄する場合のデータ消去が簡単になるんかいなぁ！？

Linux でボリュームを暗号化する (1) - swapの保護

Linux のブロックデバイスの暗号化は結構昔から行われている。鍵の管理が貧弱なので、使ってはいなかった。初回に選んだパスワードを未来永劫使うのは、どう考えても高リスクだろう。

諸々の要求に応える為に、Linuxでは LUKS(Linux Unified Key Setup) という珠玉の成果がある。コイツを使えば、パスワードの変更だけでなく、複数のパスワードを持つことも出来るという有り難い代物。

再三設定してるので、ちょっとメモっとかないと、禿げの進行が年2ミリ位 早くなってしますので、取り敢えず書いとく。

swapの暗号化

LUKSと言いながら、そうでないものを最初に書くのは何だが、メモリのベタ情報を swap から平文で読まれたくない人は、必ずすべき設定ですね。。。

Debian の cryptsetup 付属の文書 /usr/share/doc/cryptsetup/README.Debian.gz のそのまんまですねぇ。

現在のスワップの無効化

先ず、現在のシステムで /dev/sda2 が swap デバイスとして、swapを無効化し、中身を全消去する(新品で何にも書かれていない場合は、消さなくても構わない)。

# swapoff -a
# shred -n 1 /dev/sda2

設定ファイルを変更する

/etc/crypttab

# <target> <source>  <key file>  <options>
crypt-swap /dev/sda2 /dev/random swap,cipher=aes-cbc-essiv:sha256,size=256,hash=sha256
...

/etc/fstab

...
/dev/mapper/crypt-swap none swap sw 0 0
...

暗号化スワップの有効化

# cryptdisks_start crypt-swap
# swapon -a

仮想化環境のゲストOSはメモリ割当が少ない場合が多々あるので、要設定かと思う。

何でも無いが、Linux KVM 上のゲストOSの乱数エントロピーが溜まるの遅くないかぁ。時々、暗号化スワップの開始で４〜５分くらい止まることがときどきある。。。

おやぁ、virtio_rng とか言うモジュールがあるなぁ。。。あるよなぁ。。。コイツが kvm-85 ではまだサポートされていないからなのかぁ。。。KVM に virtio_blk, virtio_net, kvm-clock, virtio_rng の四つ揃えば、準仮想化と変わらんなぁ。。。取り敢えず、待つべし！

debian lenny の kvm はバグってる?

以前 Ubuntu に乗り換え宣言したのだが、マイナーなパッケージが無かったり、古いままだったり(まぁコミュニティーベースだから仕方ない)で、Debian lenny に再度乗り換えた。

一番の難点は、、、言わないのが約束だなぁ。

Debian lenny だと kvm-72 がパッケージングされているので、サクサクインストールして使えるのだが、どうも２個以上のゲストOSを立ち上げると何故だか次のメッセージをだしてゲストOSがフリーズしてしまう。

 BUG: soft lockup - CPU#0 stuck for 4096s!

なんすかねぇ？

症状としては、下記のバグ報告と同じっぽい。

• BUG: soft lockup - CPU#1 stuck for 4096s! [java:3174] and crash (kvm guest)

で、kvm-84 だと直ってるらしい。。。

ぐふぅ。取り敢えずは、適当に sid からkvm/libvirtのソースパッケージを取ってきてビルドして諸々更新したら、複数のゲストOSがフリーズせずに安定した、、、気がする。

またもや debian squeeze 待ちかなぁ