lxc で SR-IOV ハマり道
SR-IOV で出現した VF は lxc から見たら普通のネットワークインターフェースに見えるので
lxc.network.type=phys lxc.network.link=eth3 lxc.network.flags=up
とか書けば普通に使えるんですが，「あれ〜？ネットワーク通じないなあ」とハマっていたら，なんということはない，コンテナ内でもそのまま eth3 という名前で起動するので，/etc/network/interfaces で何も考えず eth0 の定義とかしてたら eth3 にはアドレスも割り当たりませんとさ...
lxc.network.name=eth0
と書いて無事開通．
ドコモ sp モードの障害
まあ，良く中身を分かってないので，ボケた事や間違えを書いているかもしれませんが，なんとなく... (以下，想像を交えてますので間違いのある可能性があります ^^;)
障害の原因ですが，
一部のサーバーが処理能力不足に陥ったことが、なぜ「自分のメールアドレスが他人のものに置き換わる」という通信の秘密にかかわる事故に発展したのか。大きな理由の1つは、メールアドレスが端末固有のIDでなく、端末に振り出されたIPアドレスとひも付いていた点にある。
http://itpro.nikkeibp.co.jp/article/NEWS/20111222/377225/
という単純なものでもないような．
まず IP アドレスとユーザの紐付けは必要な気がします．ただし，メールの送受信に必要なのではなく，サーバ側にメールが届いたことを端末に push する必要がありますので，この時に必要かもしれません．(他に携帯電話特有の仕組みで可能なのかもしれませんが，その辺りはしりませんので)
sp モードメールの場合，
- メールの仕組み自体は SMTPS/POP3S を使っている．
- sp モードの公式アプリからのみアクセスを許可する必要がある．
という仕組みのため
- 設定はドコモのサポートサイトで行い，設定情報はインフラ側に保存されている
- sp モードメールクライアントが送受信を開始するときに，独自の認証を使って認証を行い，サーバから SMTPS/POP3Sの送受信の認証時に必要な認証情報を取得する．
ということになっているようです．
問題なの(/今回の原因)は，この時の認証情報の送出に前述の IP アドレスとユーザの紐付けをそのまま流用している事ですね．
じゃあ，どうすれば良いのかというのは，私は携帯電話のインフラを知らないのでわからないのですが，折角クライアントがアクセスをしてきて，そこで独自の認証を行っているのですから，SIM の情報 (IMSI) 等 (も含めて複数の情報) でユーザとメールの認証情報の紐付けを行うべきだったのかもしれません．(端末固有の情報 (IMEI) だとユーザと端末は1対1で結びつかないのでダメな気がする)
(参考)
- SPモードメール障害は設計ミス (とある技術屋の戯言)
macvtap でつないだ kvm ゲストとホスト間の通信
kvm ゲストの仮想 NIC を macvtap 経由で物理 NIC に直接アタッチするとパフォーマンスが良いようですね．macvtap については
- MacVTap - Linux Virtualization Wiki
- libvirt 文書の Domain XML format のDirect attachment to physical interface セクション
- http://wiki.libvirt.org/page/Guest_can_reach_outside_network,_but_can't_reach_host_(macvtap)
- libvirtで色々な仮想NICの設定を使い分ける - かーねる・う゛いえむにっき
等が判りやすいかと．
この際，ゲスト〜ホスト間の通信はできません．まあ，きちんとしたサービスとしてやるときは必要ないかもしれませんが，手元でちょっとテストをやってる時なんかは，ゲスト〜ホスト間通信ができると便利な事もあります．
macvtap というのは Linux kernel の持つ機能で macvlan というインターフェースを作れますが，これを Tap として利用するモノのようです．ということは macvlan/macvtap 間の通信は "bridgeモード" に設定しておけば可能です(この辺りのモードについては前述の参考文書を参照) ので，ホスト上に macvlan インターフェースを作成して，そこにホストのアドレスを割り当ててしまえば，ゲスト〜ホスト間の通信は可能なはず，ということでやってみました．
ゲストVMは eth0 に作られた macvtap につながっています．
- macvlanインターフェースを作成．"macvlan0" という名前にします．
ip link add dev macvlan0 link eth0 type macvlan mode bridge
- eth0 のアドレスは削除して macvlan0 に割り当て．
ip addr del 172.16.44.18/24 dev eth0
ip addr add 172.16.44.18/24 broadcast 172.16.44.255 dev macvlan0
ip link set macvlan0 up - デフォルトルート設定．
ip route flush dev eth0
ip route add default via 172.16.44.254 dev macvlan0 proto static
ごちゃごちゃと試行錯誤しながらやってたので，ヌケがあるかもしれませんが，大体こんな感じで無事ゲスト〜ホスト間の通信が可能になりました．(後日確認します)
SR-IOV を有効にする(3)
企画第 3 弾．SR-IOV を有効にする (2) - TenForwardの日記 の続編．
きちっとギガのスイッチをはさんでリモートのホストからベンチマークを実行してみました．
ちなみにゲスト OS は CPU コアを 1 つ割り当てており，メモリは 1024MB です．
(2011/12/26: vhost-net でネットワーク構成を macvtap(bridgeモード) にした場合の結果を追記しました)
iperf
TCP
$ iperf -s (サーバ側) $ iperf -c 172.16.44.12
実行はサーバ側，クライアント側ともデフォルトです．実行中の VM が稼働しているホストの CPU 負荷も測定しました．3 回実行した時の平均値です．
| 仮想NIC | iperf(Mbits/sec) | %user | %system |
|---|---|---|---|
| e1000 | 511 | 10.91 | 15.44 |
| virtio-net | 933 | 10.66 | 16.06 |
| vhost-net | 935 | 10.50 | 15.01 |
| vhost-net(macvtap) | 936 | 10.78 | 8.80 |
| SR-IOV | 936 | 12.77 | 3.50 |
ギガのネットワーク程度では virio-net/vhost-net でも充分にスループットが得られるので，差はありませんが，SR-IOV の時の CPU 負荷が全然違います．
UDP (2011/12/14 追記，2011/12/15 更新)
UDP でパケットサイズを小さくしてやってみました．このやりかたでいいのかイマイチ iperf が判ってませんが．
(2011/12/15 更新) iperf で以下のようにテストをするとかなりパケットをロストするので，再テストをしてロストした割合も掲載しました．
$ iperf -s -u (サーバ側) $ iperf -c 172.16.44.12 -u -l 50 -b 1000M
| 仮想NIC | iperf (Mbits/sec) | %user | %system | lost(%) |
|---|---|---|---|---|
| e1000 | 12.9 | 6.06 | 16.13 | 52.7 |
| virtio-net | 20.5 | 12.0 | 17.3 | 25.0 |
| vhost-net | 13.4 | 6.62 | 13.65 | 51.7 |
| vhost-net(macvtap) | 18.47 | 9.10 | 7.12 | 32.7 |
| SR-IOV | 20.5 | 5.96 | 0.92 | 26.0 |
SR-IOV は CPU 負荷が低いというのはわかりますが，それ以外はイマイチ判らない結果... ^^;
(追記ここまで)
LMbench (lat_tcp)
LMbench - Tools for Performance Analysis (LMbench3) の lat_tcp コマンドを使ってレイテンシを測定してみました．
こちらもそのまま実行しただけです．
$ lat_tcp -s (サーバ側) $ lat_tcp 172.16.44.12 (クライアント側)
| 仮想NIC | lat_tcp(microseconds) |
|---|---|
| e1000 | 235 |
| virtio-net | 285 |
| vhost-net | 231 |
| vhost-net(macvtap) | 211 |
| SR-IOV | 491 |
なんか良くわからない結果です (^^;)．
netperf(UDP_STREAM) (2011/12/15 追記)
netperf を以下のように実行してみました．
$ netperf -t UDP_STREAM -H 172.16.44.12 -- -m 50
| 仮想NIC | netperf (Mbits/sec) | %user | %system |
|---|---|---|---|
| e1000 | 18.31 | 5.07 | 26.93 |
| virtio-net | 24.83 | 9.55 | 28.71 |
| vhost-net | 66.67 | 12.02 | 30.98 |
| vhost-net(macvtap) | 97.26 | 14.80 | 11.51 |
| SR-IOV | 55.21 | 12.69 | 1.44 |
ちゃんと測定するにはちょっとそれぞれのツールがどういう処理をしているかも調べないとダメですが，とりあえず．
LMbench
LMbench3 というものを取得してみたが，make するとエラーになる．
make[2]: *** `bk.ver' に必要なターゲット `../SCCS/s.ChangeSet' を make するルールがありません. 中止. make[2]: ディレクトリ `/home/karma/src/lmbench/lmbench3/src' から出ます make[1]: *** [lmbench] エラー 2 make[1]: ディレクトリ `/home/karma/src/lmbench/lmbench3/src' から出ます make: *** [build] エラー 2
とりあえず
$ cd lmbench3 $ mkdir SCCS $ touch s.ChangeSet $ make
で通った．
