infiniband on debian

家庭内 LAN を高速に！～ InfiniBand on Debian ～

@tyamadajp

for 大統一 Debian 勉強会 , 2012/6/23

１． 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 じゃないの？→ まさにその通りで、いま色々とメンドイ状態…

・ 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ヤバス！ヤバス！とメールが…

linux-2.6 linux-3.0 linux-3.2

OFED-1.4 ○ △ （一部） △ （一部）

OFED-1.5 ○ ○ △ （一部）

OFED-3.2 ？？ ○ （開発中）

IB on Debianどの OFED/ どこの repo を使う？

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

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

IB on Debian

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

ただし面倒度が…

入れてみよう

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

# apt-get install ofed理想：

# apt-get install ibverbs-utils infiniband-diagsperftest libmlx4-1 libmthca1 mstflint ibutilsrdmacm-utils libsdp1 libibumad-devlibibverbs-dev librdmacm-dev libibcm-dev

今回：

セットアップ : モジュール周り

=== /etc/modules ===mlx4_ibib_mthcaib_uverbsib_umadib_ucmrdma_ucmib_ipoib

#ib_srp#svcrdma#xprtrdma

素OFED の場合は /etc/infiniband/openibd.conf での各機能の有効・無効の選択設定となるが、以下と同じ

なぜこんなに細かいか？

IB のスタックは L2相当部からL7相当部まで多岐にわたり、さらに in-kernel/userland 、使用 API セットの違いで必要な機能（モジュール）セットが別々。

なので上位の何かを入れたら他の関連物も芋蔓…とならない。

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

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

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

セットアップ：チューニングパラメータ

=== /etc/network/interfaces ===iface ib1 inet …

…#メモ：#この順序でpost-upしないとエラー。#通常のmtuオプションはIPoIBをうまく扱えないpost-up echo connected > /sys/class/net/ib1/modepost-up ip link set ib1 mtu 65520

続き。基本的なウィンドウサイズ、バッファサイズ、MTU を大きくするという話だが、 IB にマップした際に最大効率で転送する形も兼ねている。

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

動作＆性能確認

dst# /etc/init.d/netperf startsrc# netperf -H 10.254.1.17 -v 1Recv Send SendSocket Socket Message ElapsedSize Size Size Time Throughputbytes bytes bytes secs. 10^6bits/sec 87380 65536 65536 10.01 7859.71

■IB 的確認方法

■IP 的確認方法

dst# ib_read_bw -F -i 2 -asrc# 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

確認目安は900+MB/s位

動作＆性能確認 :おまけ

速機 # ib_read_bw -F -i 2 -a遅機 # ib_read_bw -F -i 2 -a 10.253.1.9#bytes #iterations BW peak[MB/sec] BW average[MB/sec] 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#bytes #iterations BW peak[MB/sec] BW average[MB/sec] 512 1000 456.12 453.39 1024 1000 550.33 548.86 2048 1000 555.37 555.14

←早々に　　頭打ち

←遅いなりに　　頑張る

使ってみよう： SAN と NAS

使ってみよう： NFS on IBNFS の下層を入れ替えることで高速化します。２方式あるため、今回両方とも試して比較。

L7:NFSL4:UDP, TCPL3:IPL2:Ethernet

L7:NFSL4:IB (via RDMA API)L3:IBL2:IB

L7:NFSL4:TCP/IP (emu)L4:IB (via RDMA API?)L3:IBL2:IB

NFSoRDMA

NFSoIPoIB

NFS

NFSoRDMANFSoIPoIB は単なる TCP NFS なので、特別な設定はNFSoRDMA の方のみ必要。

NFS client

NFS server

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

# modprobe svcrdma# echo rdma 20049 > /proc/fs/nfsd/portlist

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

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

※nfsd.ko の reload の度に必要

NFSoIPoIB vs NFSoRDMA

NFSoIPoIB# cstream -i big.bin -o - -b 32k -B 1m -n 12G -T16771310592 B 6.3 GB 8.04 s 842148123 B/s 803.14 MB/s

local access # mount -t tmpfs none /t# cstream -i - -o /t/big.bin -b 32k -B 1m -n 12G -T111605934080 B 10.8 GB 8.00 s 1450373012 B/s 1.35 GB/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 -T16497370112 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(non-free)

open-iscsi(→Linux)

OFED(→Linux)

iSCSI ○ ○ ×SRP × × ○

iSER × × ○

イニシエータ機能

※core-iscsi は商用とあるが LIO の所で言及多く、 OpenWRT 移植などホントに純商用？と疑問なので掲載。情報緩募。

今回の対象以下のセットで iSCSI と SRP をテスト（ iSER は未遂…）

iscsi_target_mod.ko

iscsidiscsiadm

scstadmin/sysfs

ietdietadm

ib_srpt.kosysfs

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

iscsi_trgt.ko

iscsi_tcp.koiscsi-scst.ko

targetcli/sysfs

sysfsib_srp.ko

iSCSI SRP

LIO

ib_srpt.ko

targetcli/sysfs

ib_srpt.ko

scstadmin/sysfs

SCST

open-iscsi

LIO

iscsitarget

LIO

SCST

iscsi-scstd

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

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

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

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

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

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

# apt-get [-t experimental] install iscsitarget-dkmsインストール

# cat /etc/iet/ietd.confTarget iqn.2012-03.org.rakugaki:storage.pool

Lun 0 Path=/dev/sdb,Type=fileioLun 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毎に投入する。

設定と利用

for Linux-3.2+

iscsitarget x open-iscsi （ターゲット側）

iscsitarget x open-iscsi （ターゲット側）

設定と利用（続き）# /etc/init.d/iscsitarget start

# ietadm --op show --tid 1Wthreads=8Type=0...# cat /proc/net/iet/volumetid: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インストール

# iscsiadm -m discovery -D -p 10.253.0.810.253.0.8:3260,1 iqn.2012-03...:storage.pool# iscsiadm -m node -T iqn.2012-03...:storage.pool -lLogging in to [iface: iface0, target: iqn.2012-03...

設定と利用ターゲット側 IP

# iscsiadm -m sessiontcp: [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

状態確認

これを -u で呼ぶと unload で利用終了になる

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

SCST x open-iscsi （ターゲット側）

# cat scst.confHANDLER vdisk_blockio {

DEVICE nd00 {filename /dev/pool/nd00

}}TARGET_DRIVER iscsi {

enabled 1TARGET iqn.2012-03.org.rakugaki:storage.nd00 {

enabled 1LUN 0 nd00

設定と利用

実は Debian package はない！自前ビルドして下さい…機能的には SCST>LIO で現状も機能マージ中なので痛い。

インストール

SCST x open-iscsi （ターゲット側）

（前ページからの続き）}

}// 以下のコマンド群で設定が sysfs 経由で投入される# iscsi-scstd ←連携デーモン起動# modprobe scst_vdisk ←利用するモジュールをロード# modprobe iscsi_scst# scstadmin -f scst.conf

設定と利用（続）

# scstadmin -list_targetDriver Target---------------------------------------------iscsi iqn.2012-03.org.rakugaki:storage.nd00

状態確認

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

LIO x open-iscsi （ターゲット側）

# 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]/>

設定と利用

# apt-get install lio-utils targetcliインストール

LIO x open-iscsi （ターゲット側）

# 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

設定と利用 dmsetup で作成の ramdisk

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

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

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

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

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

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

ISCSIoIPoIB (LIO)# JOBS=4 OP=write DEV=/dev/sdd BS=1m fio bench.iniRun 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_basedruntime=30

ioengine=libaioiodepth=32

[tasks]numjobs=${JOBS}readwrite=${OP}direct=1

SRP – SCSI RDMA Protocol

sysfsib_srp.ko

LIO

ib_srpt.ko

scstadmin/sysfs

SCST

どちらがいいか？

sysfsib_srp.ko

LIO

ib_srpt.ko

targetcli/sysfs

LIO

→ 現状では機能的に上で設定もまともな 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 （ターゲット側）

# 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

イニシエータ側 Port GUID

メモ： LIO for SRP （ターゲット側のバグ修正）

Invalid argument:'/sys/kernel/config/target/srpt/0x00000000000000000008f1040399d859'

先程の例が

のように終わる場合は、以下を修正：

- wwn_from_files_filter = \ "sed -e s/fe80/0x0000/ -e 's/\://g'"+ wwn_from_files_filter = \ "sed -e s/fe80/0xfe80/ -e 's/\://g'"

=== /var/target/fabric/ib_srpt.spec ===

Invalid argument:'/sys/kernel/config/target/srpt/0x00000000000000000008f1040399d859'

※ ib_srpt.ko が受け入れる prefix形式が変更されたのが原因

LIO for SRP （イニシエータ側）

# apt-get install srptoolsインストール

# modprobe ib_srp# ibsrpdm -c -d /dev/infiniband/umad1id_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_targetdone

設定と利用 ib1 経由で接続の場合

ターゲットからの応答

ib1 に対応する名称

SCST for SRP （ターゲット側）

さすがに LIO は開発途上感があるため、ターゲットはSCST で構成するのがお勧めです。

# cat scst.confHANDLER vdisk_blockio {

DEVICE zero {filename /dev/mapper/zero

}}TARGET_DRIVER ib_srpt {

enabled 1TARGET ib_srpt_target_0 {

enabled 1LUN 0 zero

}}# scstadmin -config scst.conf

設定と利用

iscsi と iSCSI IQN だった部分がSRP の名称になるだけ

( イニシエータ側は前述の LIO の方式で利用）

SRP (SCST x LIO) の性能は？

SRP (SCST x LIO)# JOBS=4 OP=write DEV=/dev/sdd BS=1m fio bench.iniRun status group 0 (all jobs):WRITE: io=24441MB, aggrb=832753KB/s,


他は同じ条件で 400MB/s→800+MB/s に倍増。IPoIB も詰める余地はあるが、これは魅力的！

ISCSIoIPoIB (LIO)# JOBS=4 OP=write DEV=/dev/sdd BS=1m fio bench.iniRun status group 0 (all jobs):WRITE: io=11950MB, aggrb=405514KB/s,


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

入門 IB ：基本構成

switch#1

HCA-0

switch#2

ポート

HCA-0 HCA-0 HCA-0node#4node#2 node#3node#1

p1 p1 p1 p1 p2p2p2p2

IB ネットワークは HCA(TCA) とスイッチから通常構成されます（ルータもあるが、通常考慮外）。

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

switch#1

HCA-0

switch#2


系内では Subnet Manager という管理役が選出され、個々のポートに L(ocal)ID を設定する他、subnet prefix を広報しています。

１

SM

876543

9

2

10

subnet prefix (64bit)


switch#1

HCA-0

switch#2


ポートには 64bit GUID もメーカで設定されており、広報された prefix と合成し、 128bit の GID が系内外で一意な ID としてセットされます (= IPv6) 。

SM

876543

910

subnet prefix (64bit)

LID : 1GUID : 0x0008f1040399d819GID : 0xfe800000000000000008f1040399d819

※正式な IPv6 アドレスですが、 IPv6表記はあまり見ない…

2


HCA-0node#1

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

LID : 1GUID : 0x0008f1040399d819GID : 0xfe800000000000000008f1040399d819

switch#1

10Node GUID : 0x0005ad0000026dfc

2

Node GUID : 0x0002c90200289fc4

管理ツール : saqueryこれら ID の存在、状態、接続状況、そして通信内容を調べるために各種の管理ツールがあります。

$ sudo saqueryNodeRecord dump: lid.....................0x1 .... node_type...............Channel Adapter num_ports...............0x2 sys_guid................0x0008f1040399d81b node_guid...............0x0008f1040399d818 port_guid...............0x0008f1040399d819 .... NodeDescription.........hn02 HCA-1NodeRecord dump: lid.....................0x3 ....

系内ノードのダンプ

管理ツール : iblinkinfo

# iblinkinfoSwitch 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[ ] ==( … )==> [ ] "" () ...

系内ノードの物理接続関係のダンプ

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

例：「本スイッチ (LID:6) の物理ポート #1 が別スイッチ (LID:2) の物理ポート #1 と接続している」

管理ツール : 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/RemoteLink change: Local/Remote Port 1/ 1 Local/Remote GUID: 5ad0000026dfc/5ad0000018826 Locations: Local/Remote

変更前後の差や設計と実際の差を見るツール

→記録されている状態との差分を報告してくれる

管理ツール : ibdiscover

# cat ibdiscover.topo8|5ad0000026dfc|2|8f1040399d8585|5ad0000026dfc|2|8f1040399d7e83|5ad0000026dfc|2|2c90200289fc41|5ad0000026dfc|5|5ad00000188269|5ad0000026dfc|1|8f1040399d8309|5ad0000018826|1|8f1040399d858

「記録」は自分で作っても OK

単純な

|port|NodeGUID| ←→ |port|NodeGUID|

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

管理ツール : ibdump

# ibdump -d -o ib.pcap...色々通信 ...# tshark -V -r ib.pcap...

tcpdump for IB

クローズドバイナリなので迷ったが、どういう動作をしているのか興味がある場合は外せない。

-b N:2^N 個までの連続したフレームは絶対に落とさない（ただし N は上限低い :15 とか）

--mem-mode:オンメモリキャプチャ

--src_qp <qpn>:QP絞込みキャプチャ（これは未完 or非公開かも）

管理ツール : その他色々

ibstat, ibaddr, ibping, ib(nodes|switches|ibhosts)

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

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

シンプルな機能で高頻度で使うもの

smdump, ibis, ibdmchk

Subnet Management系

perfquery, ibdatacounts, ibclear(errors|counters)

Performance Counter系

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

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

OSHCA

APPOS

HCA

APP

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

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

データ転送ではなく指令の転送

MEM

CPU

※DMA って元々そういうものだよね、ではあるけど…

HCA

MR

connection

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

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

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

HCA HCA

SENDSENDSEND RECV

RECVRECV

→RECV命令が入らないと、 SEND を受信しない

HCA HCA

MEM

①リージョン予約RDMA WRRDMA WRRDMA WRRDMA WR

②一方的に命令発行

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

key

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

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

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

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

infiniband on debian

Technology