InfiniBand on Debian

家庭内 LAN を高速に！
～ InfiniBand on Debian ～
for 大統一 Debian 勉強会 , 2012/6/23

@tyamadajp

今日の内容
１． InfiniBand とは？（概略）
２． Debian で使ってみよう（基本セットアップ）
３．で、どんな感じ？（ SAN 、 NAS を立ててみよう）
４．管理ツールの使い方
５．プロトコル＆ API について

今日の内容
１． InfiniBand とは？（概略）
２． Debian で使ってみよう（基本セットアップ）
３．で、どんな感じ？（ SAN 、 NAS を立ててみよう）
４．管理ツールの使い方
５．プロトコル＆ API について

＝話してる人（のレベル）＝
・ eBay で wktk してぽちった。まるで反省していない…
・速さに wktk は満たされたが TLA 多すぎで涙目
・それで何するんですか？→手段が目的です（キリ

どんなもの？
1. かつて PCI/PCI-X の後継を目指した I/F
XT→ISA→EISA/MCA→PCI/PCI-X→PCIe
→ 現在は 10+GbE と競合中

2. N[Gbps] のシリアルリンクを M 本束ねる
N=2.5(SDR), 5.0(DDR), 10.0(QDR), …
M=4, 12
→ x4 な SDR (10Gbps), QDR(40Gbps) が手頃

3. ケーブルはカッパー・ファイバ各種。コネクタは
SFF-8470=CX4 (x4) と SFF-8436=QSFP の 2 種。
10+GbE や SATA/SAS と共通（のものがある）。
→ 困らないと思うけど距離は 1Km 程度まで OK
→ 最近距離を延ばす IB over WAN という話も…

こんなもの

送料がアレなのでスイッチは
オクの出物、 HCA は USA で
個人輸入業者経由がお勧め

まずは使ってみよう
必要なもの
→ OFED (OpenFabrics Enterprise Distribution)

OpenFabrics Alliance
・関係規格の参照実装のとりまとめ団体
・元々 OpenIB Alliance と IB 専門だった
・今は IB に加え、 over Ethernet, over TCP/IP での
　 RDMA 通信方式の普及や参照実装の整備へ

OFED
・ちゃんと動作するバージョンセットとしてのリリース
・これを元に各社が独自拡張するなどして製品化
　→サーバやＩＢベンダから出ている。例： MLNX_OFED
・ OFED そのものは OSS(GPL, LGPL, BSDL)
　→ Debian のはこちらがベース

余談： OFED versioning
これまで：
・ OFED-1.4
・ OFED-1.5

これから：
・ OFED-3.2 　 # ←Linux-3.2 に合わせている
・ OFED-3.5 　 # ←Linux-3.4(LTS) はどうなるの…？

今後はカーネル部分はアップストリームをベースに
使う形で、 OFED バージョンはカーネルバージョンに
揃える。そして、その上で使える範囲のパッケージ群を
収録する。

（という流れで 3.2-rc1 が先日出て、今 3.5 の話中）

IB on Debian
・ドライバ：
　…はカーネル同梱。でもロードさせる設定が必要

・ライブラリ
　上位 API 提供用とデバイスアクセス用がある
　両者は独立で、依存関係がないので入れ忘れ注意

・管理ツール
　～ L4 まで見るネットワーク管理ツールと
　～ L7 まで絡む上位プロトコル関連のものがある
　これも依存関係が相互にないもの多数なので
　入れ忘れ注意

「入れ忘れ注意」ってそのための OFED じゃないの？
→ まさにその通りで、いま色々とメンドイ状態…

IB on Debian
どの OFED/ どこの repo を使う？
linux-2.6 linux-3.0 linux-3.2
OFED-1.4 ○ △ （一部） △ （一部）
OFED-1.5 ○ ○ △ （一部）
OFED-3.2 ？？ ○ （開発中）

・ OFED-1.4 でいいなら pkg-ofed
→ これなら apt-get install ofed で全部入って楽
deb http://pkg-ofed.alioth.debian.org/apt/ofed ./
deb-src http://pkg-ofed.alioth.debian.org/apt/ofed ./
→ かなり古いので sid 混在環境などで困ったり
・ OFED-1.5 は sid へのパッケージ化の途上
→ML に freeze ヤバス！ヤバス！とメールが…

IB on Debian
・正直なところ、 RetHat より対応度で遅れている
→ コア開発者まで居るし伊達じゃない＞ RedHat
→ その関係からか OFED は基本 RPM 志向。
ソース配布が SRPM でされてるなど。

・だが、実験環境として手元で使いたいのは Debian
→ なので OFED を元にしつつ頑張る
→ 基本部分は揃っているので、取り込めていない
周辺（例えば openibd など）を自前整備する

結局、 OFED-1.5 でも使えない機能が出つつあるので
sid で入れ、更に OFED-3.2 に向かっている本家を
git からセルフビルドするのが実験にはよい。
パッケージ作るなら pkg-ofed の svn も取り込むと○。
ただし面倒度が…

入れてみよう
理想： # apt-get install ofed
今回： # apt-get install ibverbs-utils infiniband-diags
perftest libmlx4-1 libmthca1 mstflint ibutils
rdmacm-utils libsdp1 libibumad-dev
libibverbs-dev librdmacm-dev libibcm-dev

※ 今回使う分だけ。 MPI 等フルに入れる場合は
　　 ofed の依存関係見つつ個別に取捨選択して入れる
※ プリント資料と若干違いますが、 L7 相当部分の
　　利用プロトコルの部分を少し変更しました＞発表

セットアップ : モジュール周り
素 OFED の場合は /etc/infiniband/openibd.conf での
各機能の有効・無効の選択設定となるが、以下と同じ
=== /etc/modules === なぜこんなに細かいか？
mlx4_ib
ib_mthca IB のスタックは L2 相当部から
ib_uverbs
ib_umad L7 相当部まで多岐にわたり、
ib_ucm さらに in-kernel/userland 、
rdma_ucm 使用 API セットの違いで必要な
ib_ipoib 機能（モジュール）セットが別々。
#ib_srp なので上位の何かを入れたら
#svcrdma 他の関連物も芋蔓…とならない。
#xprtrdma

※OFED が openibd initscript を用意する訳だと納得

セットアップ：チューニングパラメータ
先の設定は「使える」だけで性能は出ない（ IPoIB ）。
今回は以下の追加パラメータも入れる。

=== /etc/sysctl.d/interfaces ===
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_sack = 0
net.core.netdev_max_backlog = 250000
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 16777216
net.core.wmem_default = 16777216
net.core.optmem_max = 16777216
net.ipv4.tcp_mem = 16777216 16777216 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

セットアップ：チューニングパラメータ
続き。基本的なウィンドウサイズ、バッファサイズ、
MTU を大きくするという話だが、 IB にマップした際に
最大効率で転送する形も兼ねている。
=== /etc/network/interfaces ===
iface ib1 inet …
…
# メモ：
# この順序で post-up しないとエラー。
# 通常の mtu オプションは IPoIB をうまく扱えない
post-up echo connected > /sys/class/net/ib1/mode
post-up ip link set ib1 mtu 65520

※ 以上、 openibd initscript のやっている事の Debian 流実現。
自分で openibd を持ってくるか、上の設定をする。

動作＆性能確認
■IB 的確認方法
dst# ib_read_bw -F -i 2 -a
src# ib_read_bw -F -i 2 -a 10.254.1.17
#bytes #iterations BW peak[MB/sec] BW average[MB/sec]
512 1000 580.73 576.10
1024 1000 868.08 867.74
2048 1000 930.27 930.14
4096 1000 933.33 933.31
■IP 的確認方法確認目安は
900+MB/s 位
dst# /etc/init.d/netperf start
src# netperf -H 10.254.1.17 -v 1
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 65536 65536 10.01 7859.71

動作＆性能確認 : おまけ
少しスペックの落ちる別機材の組み合わせでは
テストしたら非対称な傾向に。
→ 方向が違うと性能が全然違う（詳細は後述）
速機 # ib_read_bw -F -i 2 -a
遅機 # ib_read_bw -F -i 2 -a 10.253.1.9
512 1000 496.16 493.09
1024 1000 643.52 641.62 ← 遅いなりに
2048 1000 718.14 716.74 　　頑張る
遅機 # ib_read_bw -F -i 2 -a
速機 # ib_read_bw -F -i 2 -a 10.253.1.8
512 1000 456.12 453.39
1024 1000 550.33 548.86 ← 早々に
2048 1000 555.37 555.14 　　頭打ち

使ってみよう： SAN と NAS

使ってみよう： NFS on IB
NFS の下層を入れ替えることで高速化します。
２方式あるため、今回両方とも試して比較。
NFSoIPoIB
L7:NFS
NFS L4:TCP/IP (emu)
L4:IB (via RDMA API?)
L7:NFS
L3:IB
L4:UDP, TCP
L2:IB
L3:IP
L2:Ethernet NFSoRDMA
L7:NFS
L4:IB (via RDMA API)
L3:IB
L2:IB

NFSoRDMA
NFSoIPoIB は単なる TCP NFS なので、特別な設定は
NFSoRDMA の方のみ必要。
※nfsd.ko の reload の度に必要
NFS server
# modprobe svcrdma
# echo rdma 20049 > /proc/fs/nfsd/portlist

=== /etc/exports ===
/t -rw,insecure,... * 非標準ポートなので insecure 必須

NFS client
# modprobe xprtrdma
# mount -o rdma,port=20049 10.253.1.9:/t /mnt

※NFSoIPoIB でなくても、 IPoIB なアドレスが必要（理由後述）

NFSoIPoIB vs NFSoRDMA
local access
# mount -t tmpfs none /t
# cstream -i - -o /t/big.bin -b 32k -B 1m -n 12G -T1
11605934080 B 10.8 GB 8.00 s 1450373012 B/s 1.35 GB/s
NFSoIPoIB
# cstream -i big.bin -o - -b 32k -B 1m -n 12G -T1
6771310592 B 6.3 GB 8.04 s 842148123 B/s 803.14 MB/s

NFSoRDMA
# mount -o rdma,port=20049,rsize=4194304,
wsize=4194304 10.254.1.17:/t /t/rdma
# cstream -i big.bin -o - -b 32k -B 1m -n 12G -T1
6497370112 B 6.1 GB 7.00 s 927808176 B/s 884.83 MB/s
※TCP NFS と違い rsize/wsize は小さいままなので調整必須

NFSoIPoIB vs NFSoRDMA (2)
だがしかし、

NFSoRDMA は超！不安定
このテストを流すだけなのに、いくどのハングアップと
リブートを繰り返したことか・・・（怒
そういうわけで、結論。

幸せになるためには、
NFSoIPoIB を使いましょう
※ 安定してくれば有望なのに…

使ってみよう： SCSI on IB
SCSI も NFS 同様に over IB(RDMA) ができる。
方式は３つ：

１． iSCSI on IPoIB
２． SCSI RDMA Protocol (SRP)
３． iSCSI Extensions for RDMA (iSER)

各々に付き、 initiator と target の両側の実装が必要。
どの実装がどの方式のどちら側になれるかはマチマチ！

SCSI on Linux の現状
ターゲット機能
ietd stgt SCST LIO(→Linux)
iSCSI ○ ○ ○ ○
SRP × × ○ ○
iSER × ○ × ×

イニシエータ機能
core-iscsi open-iscsi OFED
(non-free) (→Linux) (→Linux)
iSCSI ○ ○ ×
SRP × × ○
iSER × × ○
※core-iscsi は商用とあるが LIO の所で言及多く、 OpenWRT
移植などホントに純商用？と疑問なので掲載。情報緩募。

今回の対象
以下のセットで iSCSI と SRP をテスト（ iSER は未遂…）
iSCSI SRP
iscsitarget
ietadm
ietd SCST
iscsi_trgt.ko scstadmin
SCST open-iscsi /sysfs
iscsiadm ib_srpt.ko LIO
scstadmin/sysfs sysfs
iscsid LIO
iscsi-scstd ib_srp.ko
iscsi_tcp.ko targetcli
iscsi-scst.ko /sysfs
sysfs
LIO ib_srpt.ko
targetcli/sysfs
iscsi_target
_mod.ko

上図は各テスト構成で使う関係コマンドのまとめ。
大方が CLI+daemon+kernel module の構成になっている。

補足： SRP と iSER
・どちらも SCSI over Network でブロックを晒すもの

・ SRP はより古い「生 SCSI PDU を流すだけ」に近い形
→ 後でわかるが、認証などがかなり原始的
→ でも、古い分、より枯れている（模様）

・ iSER は iSCSI PDU を RDMA で転送する
→iSCSI で整備された認証の枠組みなどが使える
→ 管理性で優れているため期待されている
→ ただ Linux 実装が手薄など SRP より開発途上

・管理性除けば、 SRP も iSER も性能は（基本的には )
　変わらない

IB-SAN の話の前に、各種 SCSI
target/initiator の構成を紹介します。

その上で IB-SAN の部分の差分を
見せる流れになります。

iscsitarget x open-iscsi （ターゲット側）
インストール for Linux-3.2+
# apt-get [-t experimental] install iscsitarget-dkms
設定と利用
# cat /etc/iet/ietd.conf
Target iqn.2012-03.org.rakugaki:storage.pool
Lun 0 Path=/dev/sdb,Type=fileio
Lun 1 Blocks=262144,BlockSize=4096,Type=nullio

もしくは
# ietadm --op new --tid 2
--params Name=iqn.2012-03.org.rakugaki:storage.null
# ietadm --op new --tid=2 --lun=0
--params="Blocks=262144,BlockSize=4096,Type=nullio"
などと各 target/lun 毎に投入する。

iscsitarget x open-iscsi （ターゲット側）
設定と利用（続き）
# /etc/init.d/iscsitarget start
状態確認
# ietadm --op show --tid 1
Wthreads=8
Type=0
...
# cat /proc/net/iet/volume
tid:2 name:iqn.2012-03.org.rakugaki:storage.null
lun:0 state:0 iotype:nullio iomode:wt blocks:...
tid:1 name:iqn.2012-03.org.rakugaki:storage.pool
lun:0 state:0 iotype:fileio iomode:wt blocks:...
lun:1 state:0 iotype:nullio iomode:wt blocks:...

iscsitarget x open-iscsi( イニシエータ側 )
インストール
# apt-get install open-iscsi
設定と利用ターゲット側 IP
# iscsiadm -m discovery -D -p 10.253.0.8
10.253.0.8:3260,1 iqn.2012-03...:storage.pool
# iscsiadm -m node -T iqn.2012-03...:storage.pool -l
Logging in to [iface: iface0, target: iqn.2012-03...
これを -u で呼ぶと unload で利用終了になる
状態確認
# iscsiadm -m session
tcp: [1] 10.253.0.8:3260,1 iqn.2012-...:storage.pool
# ls /dev/disk/by-path/
ip-10.253.0.8:3260-iscsi-iqn.2...:storage.pool-lun-0

イニシエータ側は open-iscsi を
使っている限り、ターゲットによらず同様。
よって次ページからはターゲットのみ紹介。

SCST x open-iscsi （ターゲット側）
インストール
実は Debian package はない！自前ビルドして下さい…
機能的には SCST>LIO で現状も機能マージ中なので痛い。
設定と利用
# cat scst.conf
HANDLER vdisk_blockio {
DEVICE nd00 {
filename /dev/pool/nd00
}
}
TARGET_DRIVER iscsi {
enabled 1
TARGET iqn.2012-03.org.rakugaki:storage.nd00 {
enabled 1
LUN 0 nd00

SCST x open-iscsi （ターゲット側）
設定と利用（続）
（前ページからの続き）
}
}
// 以下のコマンド群で設定が sysfs 経由で投入される
# iscsi-scstd ← 連携デーモン起動
# modprobe scst_vdisk ← 利用するモジュールをロード
# modprobe iscsi_scst
# scstadmin -f scst.conf
状態確認
# scstadmin -list_target
Driver Target
---------------------------------------------
iscsi iqn.2012-03.org.rakugaki:storage.nd00

後は、 open-iscsi 側の先程と同じ手順で利用可能です。

LIO x open-iscsi （ターゲット側）
インストール
# apt-get install lio-utils targetcli
設定と利用
# targetcli
/> ls 　↓管理シェルで階層に設定エントリを作るという方式
o- / ........................... [...]
o- backstores ................ [...]
| o- fileio .................. [0 Storage Object]
| o- iblock .................. [0 Storage Object]
| o- pscsi ................... [0 Storage Object]
| o- rd_dr ................... [0 Storage Object]
| o- rd_mcp .................. [0 Storage Object]
o- iscsi ..................... [0 Target]
o- loopback .................. [0 Target]
o- tcm_fc .................... [0 Target]
/>

LIO x open-iscsi （ターゲット側）
設定と利用 dmsetup で作成の ramdisk
# targetcli
/> cd /backstores/iblock
/backstores/iblock> create zero /dev/mapper/zero
/backstores/iblock/zero> cd /iscsi
/iscsi> create iqn.2003-01.org.linux-iscsi:zero
（以下３行では認証とデモモードの解除をしている）
/i.../tpgt1> set attribute authentication=0
/i.../tpgt1> set attribute generate_node_acls=1
/i.../tpgt1> set attribute demo_mode_write_protect=0
/i.../tpgt1> cd luns
/i.../tpgt1/luns> create /backstores/iblock/zero 0
/i.../tpgt1/luns/lun0> cd ../../portals
/i.../tpgt1/portals> create 10.254.0.17
/i.../tpgt1/portals/10.254.0.17:3260> cd /
/> saveconfig
/> exit

iSCSI ターゲットまとめ
１．イニシエータは open-iscsi の事実上一択

２．ターゲットは各種あり、それぞれ流儀が大きく違う

３．これからの主流は LIO だが、今なら SCST もよい

４．これらの手順は IPoIB 環境でならばそのまま有効

iSCSI-o-IPoIB の性能は？
ここまで、 IB を扱う前の段階まで各種ターゲット・
イニシエータの設定例を予習してきました。

この段階で IPoIB を組み合わせるとどれくらいの
性能が出るのか？

ISCSIoIPoIB (LIO)
# JOBS=4 OP=write DEV=/dev/sdd BS=1m fio bench.ini
Run status group 0 (all jobs):
WRITE: io=11950MB, aggrb=405514KB/s,
minb=101188KB/s, maxb=109958KB/s,
mint=30134msec, maxt=30176msec

ざっと 400MB/s 程度。
これを、次は SRP と比較してみます。

おまけ：今回使った bench.ini
# cat bench.ini
[global]
filename=${DEV}
blocksize=${BS}
size=128G

time_based
runtime=30

ioengine=libaio
iodepth=32
[tasks]
numjobs=${JOBS}
readwrite=${OP}
direct=1

SRP – SCSI RDMA Protocol
どちらがいいか？
SCST
scstadmin LIO
/sysfs sysfs
ib_srpt.ko ib_srp.ko （現在のお勧め）
LIO
targetcli LIO
/sysfs sysfs （未来の標準？）
ib_srpt.ko ib_srp.ko

→ 現状では機能的に上で設定もまともな SCST が
お勧め。が、将来は LIO なのでまず先に紹介。

LIO for SRP （ターゲット側）
事前準備
// ターゲット側の IPoIB I/F の Port GUID を確認
target# ibstat
....
Port 2:
....
Port GUID: 0x0008f1040399d832

// イニシエータ側の IPoIB I/F の Port GUID を確認
initiator# ibstat
....
Port 2:
....
Port GUID: 0x0008f1040399d85a

以降でアクセス先や認証対象の
ID として利用するポート固有 ID

LIO for SRP （ターゲット側）
設定と利用ターゲット側 Port GUID
# targetcli
/> cd /backstores/iblock
/backstores/iblock> create zero /dev/mapper/zero
/> cd /ib_srpt
/ib_srpt> create 0xfe800000000000000008f1040399d832
/ib_srpt/0xfe...8f1040399d832> cd luns
/ib_srpt/0xfe...0399d832/luns>
create /backstores/iblock/zero 0
/ib_srpt/0xfe...832/luns/lun0> cd ../../acls
/ib_srpt/0xfe...0399d832/acls>
create 0x00000000000000000008f1040399d85a
/ib_srpt/0xfe...8f1040399d85a> cd /
/> saveconfig
/> exit
イニシエータ側 Port GUID

メモ： LIO for SRP （ターゲット側のバグ修正）
先程の例が
Invalid argument:
'/sys/kernel/config/target/srpt/0x0000000000000000
0008f1040399d859'
のように終わる場合は、以下を修正：
=== /var/target/fabric/ib_srpt.spec ===
- wwn_from_files_filter =
"sed -e s/fe80/0x0000/ -e 's/://g'"
+ wwn_from_files_filter =
"sed -e s/fe80/0xfe80/ -e 's/://g'"
※ ib_srpt.ko が受け入れる prefix 形式が変更されたのが原因

LIO for SRP （イニシエータ側）
インストール
# apt-get install srptools
設定と利用 ib1 経由で接続の場合
# modprobe ib_srp
# ibsrpdm -c -d /dev/infiniband/umad1
id_ext=0008f1040399d858,ioc_guid=0008f1040399d858,
dgid=fe800000000000000008f1040399d85a,pkey=ffff,
service_id=0008f1040399d858
ターゲットからの応答
// 上の応答が ib_srp.ko のパラメータなので、流し込む
# for i in $(ibsrpdm -c -d /dev/infiniband/umad1)
do
echo $i
> /sys/class/infiniband_srp/srp-mlx4_0-2/add_target
done
ib1 に対応する名称

SCST for SRP （ターゲット側）
さすがに LIO は開発途上感があるため、ターゲットは
SCST で構成するのがお勧めです。
設定と利用
# cat scst.conf
HANDLER vdisk_blockio {
DEVICE zero {
filename /dev/mapper/zero
}
} iscsi と iSCSI IQN だった部分が
TARGET_DRIVER ib_srpt { SRP の名称になるだけ
enabled 1
TARGET ib_srpt_target_0 {
enabled 1
LUN 0 zero
}
} ( イニシエータ側は前述の LIO の方式で利用）
# scstadmin -config scst.conf

SRP (SCST x LIO) の性能は？
ISCSIoIPoIB (LIO)
SRP (SCST x LIO)
他は同じ条件で 400MB/s→800+MB/s に倍増。
IPoIB も詰める余地はあるが、これは魅力的！

今度は管理ツールの方を覗いてみます。

入門 IB ：基本構成

switch switch
#1 #2
ポート

p1 p2 p1 p2 p1 p2 p1 p2
HCA-0 HCA-0 HCA-0 HCA-0
node#1 node#2 node#3 node#4
IB ネットワークは HCA(TCA) とスイッチから通常
構成されます（ルータもあるが、通常考慮外）。

入門 IB ： ID とアドレシング

10 9 SM
switch switch
#1 #2
subnet prefix (64bit)
１ 2 3 4 5 6 7 8
系内では Subnet Manager という管理役が選出
され、個々のポートに L(ocal)ID を設定する他、
subnet prefix を広報しています。

LID : 1
GUID : 0x0008f1040399d819
GID : 0xfe800000000000000008f1040399d819
10 9 SM
switch switch
#1 #2
subnet prefix (64bit)
2 3 4 5 6 7 8
ポートには 64bit GUID もメーカで設定されており、
広報された prefix と合成し、 128bit の GID が
系内外で一意な ID としてセットされます (= IPv6) 。
※ 正式な IPv6 アドレスですが、 IPv6 表記はあまり見ない…

LID : 1
GUID : 0x0008f1040399d819
GID : 0xfe800000000000000008f1040399d819
10
switch Node GUID : 0x0005ad0000026dfc
#1

2
HCA-0 Node GUID : 0x0002c90200289fc4
node#1
ポート以外でも、 HCA やスイッチ自体といった
ノード自体でも 64bit GUID がメーカ設定されて
います。これを ID で NW 内要素を識別・管理します

管理ツール : saquery
これら ID の存在、状態、接続状況、そして通信内容を
調べるために各種の管理ツールがあります。
$ sudo saquery
NodeRecord dump: 系内ノードのダンプ
lid.....................0x1
....
node_type...............Channel Adapter
num_ports...............0x2
sys_guid................0x0008f1040399d81b
node_guid...............0x0008f1040399d818
port_guid...............0x0008f1040399d819
....
NodeDescription.........hn02 HCA-1
NodeRecord dump:
lid.....................0x3
....

管理ツール : iblinkinfo
系内ノードの物理接続関係のダンプ
# iblinkinfo
Switch 0x0005ad0000018826 Topspin Switch TS120:
6 1[ ] ==( … )==> 2 1[ ] "Topspin Switch" ()
2[ ] ==( … )==> [ ] "" ()
6 8[ ] ==( … )==> 4 2[ ] "hn06-mlx4_0" ()
6 9[ ] ==( … )==> 7 1[ ] "hn07-mlx4_0" ()
　 10[ ] ==( … )==> [ ] "" ()
...
例：「本スイッチ (LID:6) の物理ポート #1 が
別スイッチ (LID:2) の物理ポート #1 と接続している」

テキストだけでは接続関係が判り難いですが、
ibdiagui を使うと GUI で表示させることもできます。
が、 X が必要。

管理ツール : ib2dot.rb
そこで、物理接続図だけ作るツールを作ってみたり…
# saquery > saquery.log
# iblinkinfo > iblinkinfo.log
# ib2dot.rb saquery.log iblinkinfo.log
| dot -Tpdf -ooutput.pdf

IB では SM に問い合わせて一括で情報が取れるので、
全体構成や状況の把握が比較的容易。

管理ツール : ibdiscover
変更前後の差や設計と実際の差を見るツール
// 作業前の状態をダンプ
# ibnetdiscover | ibdiscover > /dev/null
# mv ibdiscover.topo.new ibdiscover.topo
... 何か配線作業 ...
//
# ibnetdiscover | ibdiscover
...
Delta change in topo (change between … runs)
Link change: Local/Remote Port 1/ 5
Local/Remote GUID: 5ad0000026dfc/5ad0000018826
Locations: Local/Remote
Link change: Local/Remote Port 1/ 1
Local/Remote GUID: 5ad0000026dfc/5ad0000018826
Locations: Local/Remote
→ 記録されている状態との差分を報告してくれる

管理ツール : ibdiscover
「記録」は自分で作っても OK
# cat ibdiscover.topo
8|5ad0000026dfc|2|8f1040399d858
5|5ad0000026dfc|2|8f1040399d7e8
3|5ad0000026dfc|2|2c90200289fc4
1|5ad0000026dfc|5|5ad0000018826
9|5ad0000026dfc|1|8f1040399d830
9|5ad0000018826|1|8f1040399d858
単純な
|port|NodeGUID| ←→ |port|NodeGUID|

という対応関係なので、例えば SNMP ifDesc に
対応すべきポート同士に同じキー文字を埋めて、
生成した「あるべき接続構成」と IB のディスカバリ
結果を付き合わせる、などが考えられる。

管理ツール : ibdump
tcpdump for IB
# ibdump -d -o ib.pcap
... 色々通信 ...
# tshark -V -r ib.pcap
...
クローズドバイナリなので迷ったが、どういう動作を
しているのか興味がある場合は外せない。

-b N:
2^N 個までの連続したフレームは絶対に
落とさない（ただし N は上限低い :15 とか）
--mem-mode:
オンメモリキャプチャ
--src_qp <qpn>:
QP 絞込みキャプチャ（これは未完 or 非公開かも）

管理ツール : その他色々
・シンプルだが便利な日常ツール
・あまりに深すぎて手が出ないツール
・特定用途のニーズピンポイントなツール

噛めば噛むほど…（面白い物があればぜひ知りたい）

シンプルな機能で高頻度で使うもの
ibstat, ibaddr, ibping, ib(nodes|switches|ibhosts)

Subnet Management 系
smdump, ibis, ibdmchk

Performance Counter 系
perfquery, ibdatacounts, ibclear(errors|counters)

次の話題：プロトコル＆ API

高速性の源泉： R(emote)DMA
APP APP
OS OS
HCA HCA

アプリケーション内の（仮想）メモリ領域を
ダイレクトに HCA にアクセスさせ、メモリ間コピーが
宛先側のメモリ領域に書くまで発生しない

■ 用語： OS バイパス
データ転送部分で完全にバイパス、制御部分（ HW
アクセスや、 HCA が仮想アドレスを実アドレスに
変換できるよう両アドレスペアを登録する部分など）は
OS がそれでも関与する

データ転送ではなく指令の転送
MEM M
R
connection
HCA

CPU

CPU は HCA にデータを送らず、行って欲しい
処理を指令する＝ IB Verbs

IB と Verbs はリモートノード間での RDMA 転送に
必要なリソースセット（コネクションとは具体的には？、
リージョンとは？セキュアな利用に必要なものは？）や
利用モデルに適した命令セットを規定している。
※DMA って元々そういうものだよね、ではあるけど…

チャネル vs メモリセマンティクス
SEND
SEND RECV
RECV
SEND RECV
HCA HCA

→RECV 命令が入らないと、 SEND を受信しない
② 一方的に命令発行
RDMA WRWR
RDMA WR MEM
RDMA
RDMA WR
① リージョン予約
HCA key HCA

→ アクセス権を握ったら、相手のメモリは俺のもの

まとめると
１．そもそもコピーが発生せず、 CPU バスの
　　ボトルネックが発生しにくい

２． Verb/Work Request を送り込む形式を生かし、
　　非同期かつパイプライン化された処理になり、
　　アイドル状態が発生しにくい

３．いずれのセマンティスクもゼロコピーだが、
　　メモリセマンティスクではアプリレベルの調停が
　　不要かつ更に処理を削減できる

従来 IP に親しんでいた人には興味深い＆
面白い機能で一杯。安くて旨い IB オススメ

InfiniBand on Debian

More Related Content

InfiniBand on Debian