スキップしてメイン コンテンツに移動

configfsを使った NVMe over RDMA ターゲットとイニシエータの基本的な設定

Debian 12でconfigfs を使い NVMe over RDMA ターゲット(ConnectX-3 VPI)を設定し、同じくDebian 12の イニシエータ(ConnectX-3 VPI)から接続してみました。今回は PCIe 4.0 の NVMe ドライブを PCIe 3.0 で接続して試してみたのですが、fioを使ったベンチマークでローカルとほぼ同じ速度で接続できましたので備忘録として挙げてみました。
早速ですが、以下設定です。 
#### target side
modprobe nvmet-rdma

NQN=nqn.1868-01.com.example:nvme:i50.500gb01

mkdir /sys/kernel/config/nvmet/subsystems/$NQN
cd /sys/kernel/config/nvmet/subsystems/$NQN
echo 1 > attr_allow_any_host
mkdir namespaces/10
cd namespaces/10
echo -n /dev/nvme0n1 > device_path
echo 1 > enable

mkdir /sys/kernel/config/nvmet/ports/1
cd /sys/kernel/config/nvmet/ports/1
# 全てのインターフェースでリスンする場合は 0.0.0.0 を指定
echo -n 0.0.0.0 > addr_traddr
echo rdma > addr_trtype
echo 4420 > addr_trsvcid
echo ipv4 > addr_adrfam

ln -s /sys/kernel/config/nvmet/subsystems/$NQN /sys/kernel/config/nvmet/ports/1/subsystems/$NQN

# 確認
dmesg | grep "enabling port"
[ 1342.115704] nvmet_rdma: enabling port 1 (0.0.0.0:4420)
ターゲット側は以上です。
続いてイニシエータ側から接続してみます。 
#### initiator side

apt-get install nvme-cli

# discovering
nvme discover -t rdma -a 10.1.56.50 -s 4420

# connecting
NQN=nqn.1868-01.com.example:nvme:i50.500gb01
nvme connect -t rdma -n $NQN -a 10.1.56.50 -s 4420

# 接続確認
nvme list
--snip

dmesg | tail
[ 5654.428305] nvme nvme0: creating 4 I/O queues.
[ 5654.461203] nvme nvme0: mapped 4/0/0 default/read/poll queues.
[ 5654.462550] nvme nvme0: new ctrl: NQN "nqn.1868-01.com.example:nvme:i50.500gb01", addr 10.1.56.50:4420
接続は以上です。
試しに QDR(40Gbps)のRoCE (ConnectX-3 VPI) で計測を行ってみました。 
# fio sequential read on initiator
fio --filename=/dev/nvme0n1 --size=1024M --rw=read --bs=1024K --ioengine=io_uring --direct=1 --iodepth=8 --runtime=10 --numjobs=1 --time_based --group_reporting --name=read-throughput-test-job
--snip
Run status group 0 (all jobs):
   READ: bw=3288MiB/s (3448MB/s), 3288MiB/s-3288MiB/s (3448MB/s-3448MB/s), io=32.1GiB (34.5GB), run=10002-10002msec

# fio sequential write on initiator
fio --filename=/dev/nvme0n1 --size=1024M --rw=write --bs=1024K --ioengine=io_uring --direct=1 --iodepth=8 --runtime=10 --numjobs=1 --time_based --group_reporting --name=write-throughput-test-job
--snip
Run status group 0 (all jobs):
  WRITE: bw=3212MiB/s (3368MB/s), 3212MiB/s-3212MiB/s (3368MB/s-3368MB/s), io=31.4GiB (33.7GB), run=10003-10003msec


# 参考: fio sequential read on target 
fio --filename=/dev/nvme0n1 --size=1024M --rw=read --bs=1024K --ioengine=io_uring --direct=1 --iodepth=8 --runtime=10 --numjobs=1 --time_based --group_reporting --name=read-throughput-test-job
--snip
Run status group 0 (all jobs):
   READ: bw=3391MiB/s (3556MB/s), 3391MiB/s-3391MiB/s (3556MB/s-3556MB/s), io=33.1GiB (35.6GB), run=10002-10002msec

# 参考: fio sequential wirte on target
fio --filename=/dev/nvme0n1 --size=1024M --rw=write --bs=1024K --ioengine=io_uring --direct=1 --iodepth=8 --runtime=10 --numjobs=1 --time_based --group_reporting --name=write-throughput-test-job
--snip
Run status group 0 (all jobs):
  WRITE: bw=3189MiB/s (3344MB/s), 3189MiB/s-3189MiB/s (3344MB/s-3344MB/s), io=31.2GiB (33.4GB), run=10003-10003msec

## 接続解除
nvme disconnect -n $NQN
多少のオーバーヘッドはあるかとは思いますが、PCIe x3 接続の NVMe ドライブとして見た場合、QDR接続でもローカル接続・リモート接続共にほぼ最高同程度の速度で読取・書込できているようです。
これも参考ですが、同じHCAの別ポートのIPoIB(Connected mode)で接続した場合、以下のようになりました。 
# sequential read
Run status group 0 (all jobs):
   READ: bw=3307MiB/s (3467MB/s), 3307MiB/s-3307MiB/s (3467MB/s-3467MB/s), io=32.3GiB (34.7GB), run=10003-10003msec
# sequential write
Run status group 0 (all jobs):
  WRITE: bw=3214MiB/s (3370MB/s), 3214MiB/s-3214MiB/s (3370MB/s-3370MB/s), io=31.4GiB (33.7GB), run=10003-10003msec
こちらも QDR 接続で、ほぼ最高同程度の速度で読取書込できているようです。
ついでに ConnectX-2 なIPoIBのイニシエータから接続して計測した場合は、以下のようになりました。 
# sequential read
Run status group 0 (all jobs):
   READ: bw=3132MiB/s (3284MB/s), 3132MiB/s-3132MiB/s (3284MB/s-3284MB/s), io=30.6GiB (32.8GB), run=10003-10003msec
# sequential write
Run status group 0 (all jobs):
  WRITE: bw=2829MiB/s (2966MB/s), 2829MiB/s-2829MiB/s (2966MB/s-2966MB/s), io=27.6GiB (29.7GB), run=10002-10002msec
書込が後少しですが、ターゲットが PCIe 3.0 x4 接続の NVMe な環境では ConnectX-2のイニシエータでもそこそこのスピードで接続できるようです。
今回は以上です。それでは。

コメント

コメントを投稿

このブログの人気の投稿

wsdd を使ってSamba サーバをネットワークに表示

Windows 10のアップデートで、セキュリティー対応のため、smbv1がデフォルトではインストールされなくなり、Samba serverがエクスプローラーのネットワークに表示されなくなってしまいました。そこで、いくつか方法を調べたのですが、linuxでwsdの実装がないか探したところ、 https://github.com/christgau/wsdd が、見つかりましたので、さっそくインストールしてみました。まだパッケージにはないようですが、インストール自身は簡単です。wsdd自体は以下のように取得し、linkを張っておきます。 cd /usr/local/bin/ sudo wget https://raw.githubusercontent.com/christgau/wsdd/master/src/wsdd.py sudo chmod 755 wsdd.py sudo ln -sf wsdd.py wsdd こちらのsambaサーバはDebianなので、/etc/systemd/system/wsdd.serviceは以下のようにしました。 [Unit] Description=Web Services Dynamic Discovery host daemon Requires=network-online.target After=network.target network-online.target multi-user.target [Service] Type=simple ExecStart=/usr/local/bin/wsdd -d MYDOMAIN [Install] WantedBy=multi-user.target wsdd -d MYDOMAINのところを、環境にあわせて書き換えてください。 次に、systemdに登録・起動テストを行います。 systemctl enable wsdd systemctl start wsdd 起動に成功すると、エクスプローラーのネットワークに表示されます。  なおこのwsddはpython3が必要です。一度試してみてください。SMBv1/CIFSを停止していても、大丈夫です。 cで書かれたほかのwsddの実装もあるようなので、いずれパッケージになるかも...
コメントを投稿
続きを読む

Windows デバイス暗号化 のサポートで "許可されていない dma 対応バス/デバイスが検出されました"の対処

Windows でセキュリティー関係を見ているのですが、とあるPCでmsinfo32で確認すると"デバイス暗号化のサポート"で"許可されていない dma 対応バス/デバイスが検出されました"と出ていました。このPCの場合、それ以外はOK（なにも表示されない）だったのですが、ネットでしらべるとMSのドキュメントではハードウェアベンダーに問い合わせるなどと敷居が高く具体的にどこが引っかかっているかわかりません。そこでほかに方法はないかとしらべやってみたところ、"前提条件をみたしています"まで持って行けたので、本稿を挙げた次第です。 具体的には、以下のようにします。 1-a. 許可するDMA対応バス・デバイスを指定するレジストリの所有権と書き込み設定をおこなう。 以下のレジストリキーの所有者を自分自身(管理ユーザ)のものにし、フルコントロール権を付与する。 HKLM\SYSTEM\CurrentControlSet\Control\DmaSecurity\AllowedBuses もしくは 1-b. MicrosoftよりPsExecをダウンロードし、System権限でRegeditを立ち上げ編集する。 Microsoftより、https://docs.microsoft.com/en-us/sysinternals/downloads/psexec　にある こちら をダウンロードし、解凍する。解凍すると、x64の場合、PsExec64.exeがあるので、管理者権限で以下を実行し、システム権限でregeditを立ち上げることが出来るようになる。 cd Downloads\PSTools .\PsExec64.exe -sid C:\Windows\regedit.exe 2-a. パワーシェルスクリプトを実行し、PnPデバイスのうちインスタンスがPCIで始まるものを"AllowedBuses"に追加する。 以下のパワーシェルスクリプトを作成する。たとえばDocuments\allow-dma-bus-device.ps1として作成する。( こちらの記事のものを使用させていただきました: Thank you! ) $tmpfile = "$($env:T...
コメントを投稿
続きを読む

フレッツ光クロス：MAP-E ROUTER by Debian Box (iptables)

フレッツ光クロスがようやく開通したので、Debianにてrouterを構成し接続してみました。なお、プロバイダーを選ぶにあたっては、IPoE方式がそれぞれ異なるため検討したところ、IPoEでは、MAP-Eでもv6plusとocnバーチャルコネクトがあり、前者がポート数240なのに対し、後者は約４倍のポート数が使えるようなネットの情報をみて、OCNバーチャルコネクトを選択しました。（プロバイダーとしてはぷららです。なおDS-LiteはCE側でのNATではないので今回は見送りました。）そこで、OCN バーチャルコネクトをDebian(iptables)で実現するとどうなるかと思い、ネットの情報を頼りにしつつ、設定した次第です。 実際に試した結果、とりあえず通信できていますが、MAP-Eは本来マッピングルールをマップサーバから取得するはずなので、今回のやり方が正解とはいえませんし、仕様変更されると通信できなくなる可能性があります。あくまでも参考程度ですが、本稿をUPしてみました。 2023/03/16追記： こちら にゲームコンソールNAT越え(Nintendo Switch ナットタイプ A判定)対応版を投稿しました。 2023/03/28追記：※1の記述および3行無効化によりNAT越え(Nintendo Switch ナットタイプ B判定)できるようになりました。 構成は以下の通りです。 ルーターがDebianで回線がOCNバーチャルコネクトであること以外はなにも特別なところはない構成です。 さて、いきなり設定ですが、まず、割り当てられたプレフィックスを確認します。 確認は、 dhclient -6 -d -P enp2s0 とします。出力の中に 前略 RCV: | | X-- IAPREFIX 2400:4050:5c71:af00::/56 後略 このようにプレフィックスが表示されるので、その確認したプレフィックスを書き留めておきます。これを こちらで 入力します。すると、 CE: 2400:4050:5c71:af00:99:f171:c600:2f00 IPv4 アドレス: 153.241.113.198 ポート番号：(1776-1791 2800-2815 3824-3839) 4848-4863 5872-5887 6896-...
コメントを投稿
続きを読む