2009年9月30日

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 を含めて以下の3台とHUBを用意し、3台とも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 利用率
ref1ref2
ref1 ⇒ ref2941.373311 %27 %
ref1 ⇐ ref2941.096616 %33 %
mtu 1500

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

target ⇔ ref1 間

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

velocitygetvia-velocity
スループット
(Mbps)
CPU 利用率スループット
(Mbps)
CPU 利用率
targetref1targetref1
target ⇒ ref1 655.217499 %12 % 340.168127 %9 %
target ⇐ ref1 738.798768 %3 % 514.590042 %2 %
mtu 1500 / モジュールパラメータは全てデフォルト値

熟考

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

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

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

DMA_lengthvelocitygetvia-velocity
(via-velocity
/velocityget)
スループット
(Mbps)
CPU 利用率スループット
(Mbps)
CPU 利用率
targetref1targetref1
target ⇒ ref1 0 369.505328 %11 % 340.182727 %10 % 0.920643
1 398.938239 %11 % 414.574740 %7 % 1.039195
2 497.400464 %9 % 494.275760 %8 % 0.993717
3 539.035684 %9 % 540.716080 %10 % 1.003117
4 610.574399 %10 % 608.103199 %10 % 0.995952
5 646.153099 %11 % 640.971199 %10 % 0.991980
6 655.484199 %11 % 646.403699 %12 % 0.986146
7 652.173299 %12 % 647.739799 %10 % 0.993201
target ⇐ ref1 0 450.885036 %2 % 502.953242 %2 % 1.115480
1 490.215038 %2 % 580.651856 %2 % 1.184483
2 599.558448 %3 % 642.568463 %2 % 1.071736
3 661.059252 %3 % 685.175374 %3 % 1.036480
4 719.696564 %3 % 709.948283 %3 % 0.986454
5 731.320969 %5 % 710.111380 %3 % 0.970998
6 741.275566 %4 % 709.246580 %3 % 0.956792
7 738.297565 %3 % 710.145982 %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 を外付けしたんだっけなぁ。なので、測定してみた。

velocitygetvia-velocity
スループット
(Mbps)
CPU 利用率スループット
(Mbps)
CPU 利用率
targetref1targetref1
target ⇒ ref1 816.054432 %7 % 816.154130 %7 %
target ⇐ ref1 989.874548 %9 % 944.481346 %8 %
mtu 9000 / DMA_length=6 / それ以外のモジュールパラメータはデフォルト値

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

追記 (2009/10/06)

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


[全文を読む]

2009年9月27日

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を内蔵して1チップ化したものが、良く知っている 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 ~ 0x0fVT3119ZX1701Z/X1702/VT6110
0x10 ~ 0x1fVT3216VT6120/VT6121/VT6122
0x20 ~ 0x7fVT3284不明
0x80 ~ VT3286VT6130/VT6132

但し書き

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


[全文を読む]

2009年9月24日

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 を買ってしまって以来、 不憫な奴が故に捨てられずに、年に1回くらいは思い出したように手を入れて使っている。。。はぁ〜

今回は 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. 上記の処理を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 の修正部分がバグってたみたいだ。なので、修正版に差し替えました。申し訳ない。


[全文を読む]

2009年9月10日

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/ローカル接続でも同じモデルを利用

測定結果

ローカルHDDGigaEtherWifi経由GigaEtherWifi経由
IPSec 無IPSec 有
SequentialUncached Write [4K blocks]58.1960.515.3413.155.48
Uncached Write [256K blocks]47.5850.827.3312.654.72
Uncached Read [4K blocks]16.166.021.464.751.38
Uncached Read [256K blocks]75.5528.863.3915.864.90
RandomUncached Write [4K blocks]1.251.361.321.351.26
Uncached Write [256K blocks]26.1924.376.1913.106.93
Uncached Read [4K blocks]0.640.610.450.580.43
Uncached Read [256K blocks]26.6823.663.2111.174.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 程度の帯域を確保できることを考えると、 目くじらを立てるものではないのかなぁ。


[全文を読む]

2009年9月8日

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/24client1

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で保護が出来そうである。気になるのは、パフォーマンスがどこまで劣化するかなのだが。。。あまり期待は出来ないのかなぁ。。。


[全文を読む]

2009年9月3日

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+のボリュームを作って指定すれば普通に使える。。。快適じゃぁ。。。


[全文を読む]