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

What's hot

Similar to InfiniBand on Debian

More from Taisuke Yamada

InfiniBand on Debian