普段便利に使っているESXiの環境ですが、ESXi7x以降になるとvmkAPIのバージョンが上がり、ネイティブドライバが配布されていないとドライバの認識ができないため、古いマイナーなハードウェアがだいぶ認識できなくなります。こちらの環境では未だにストレージがInfinibandとSRPに依存しているので6.7から進めずにいます。
そんな中、普段動いているストレージのIB接続がESXiからみてesxtopでFCMD/sが跳ね上がるときがあり、なんかストレージが調子が悪い、ということが稀に起きるようになってきました。問題が起きるとストレージ自体の再起動をしてもだめな時があり、VMホストを再起動しても解消しないことがありました。いろいろな検証の結果、どうやらVMホストに刺さっているHCAは問題ないようで、ストレージホストに刺さっているHCAがなにか悪そうな感じでした。
このIB HCAも相当長く使っているので、そろそろ交換してみようと思い、手元にCX2の在庫があるもののebayを見てみたら、FDRなHCAが9ドルで売っていたので買ってしまいました。もうIBは買わないと思っていたのですが…。
ハードウェアについて
対象のHCAはEC33という型番で売られており、Connect-IBのDPモデルのようです。ちなみにCX2とブラケットの互換があったため、DDRなCX2からブラケットをはいで使いまわしました。
燦然と輝くFRU PN / NAの文字。謎が多いです。
Connect-X4などはEtherとしても動かせるためまだ需要があるのですが、Connect-IBは完全にIB専用のため、かなり不人気です。9ドルでもいらないというのが全てですが、こちらの環境だと逆にスイッチがEtherを使えないので都合が良いです。
IBについて
IBは基本は広大なL2で使うという単純な作りがゆえ、QDRな32ポート40Gスイッチ(Voltaire Grid Director)であってもポートをたくさん使っても消費電力が70-100W程度と非常に低く、ストレージインターコネクトとして使うにはとても優秀です。
ただ、IBにはL3ルーティングやVLANなどがない(パーティションを分けるためのP keyがあるといえばあるものの…)うえ、SubnetManagerなど独特な作法があり使いづらいし、ネットワーク的にみんなほしいのは結局Etherだよね、となり、EtherでRoCEなどを使うのが今どきのRDMAですが、自宅環境で使おうとすると新しくスイッチとNICを買わないといけない、スイッチを買っても40GだとIBからそこまで変わらない、40Gスイッチで多ポートのものになると消費電力がかなり上がる、などの理由があり、用途次第では未だにIBにはメリットがあります。
FCがそこそこまともに動けばよいのですが、8G-FCでLinuxターゲットを作ったときにはあまりパフォーマンスが出なかったので、結局全て売ってしまいました。その時はLIO+targetcliで検証しましたが、32G-FCとCSCTならもしかしたら改善しているのかもしれません。しかし、FC HBAをイニシエーターではなくターゲットとして動かすには多少の手間があり、かつまだそこまで32G-FCが出回っていないので現在どの程度出るのかは不明です。ただ、RDMAの高速性、低負荷性を見てしまうと微妙な気がします。
SCSTでSRPターゲットが動くのか2022
現在動いているストレージはDebian9までは上げましたが、それからは塩漬けになっています。現在のDebian11はカーネルが5.10となり、カーネルモジュールとしてib_srptを読み込むSCSTはカーネルとの兼ね合いがありそうで無事に使えるのか、Connect-IBはドライバとしてmlx5をつかむのでこれもいけるのか、という疑問がありました。LinuxはINBOXでib_sprtドライバを持っているのですが、LIO+targetcliだとずっと使っているとSRPがなにかのタイミングで刺さるということが多々あり、パフォーマンスもSCSTのほうがかなり良かったので過去の経験からSCSTを使っています。LIOももしかしたら良くなっているのかもしれませんが、過去から現在の実績があるのでSCSTにこだわります。
様々な検証をした結果、結論から言いますと無事に動いています。以下にSCSTのビルド方法などを書きます。
SCSTのビルド
昔は小細工が色々必要でしたが、今は素直にビルドできるようになっています。まずはgit,make,gcc,linux-headersを入れます。
root@debian:~# apt install git make gcc linux-headers-amd64
次に、gitからソースをダウンロードし、makeします。make allでもいいのですが、FCターゲットなど通常使わないものも含まれているため、一つ一つ指定して作ったほうが早く終わります。今回はSCSTに必要なパッケージ、srpt、iscsiモジュールをビルドします。ここで注意が必要なのは、順番的にscst_installを先に持ってこないと他のビルドがコケます
root@debian:~# git clone https://github.com/SCST-project/scst.git
root@debian:~# cd scst/
root@debian:~/scst# make scst_install scstadm_install iscsi_install srpt_install
ビルドが終わったら、depmodで新しく追加されたモジュールを反映します。
root@debian:~/scst# depmod -a
これで、SCSTの前準備が完了しました。正しくモジュールが入ったか、modinfoで確認します。import_nsがSCSTになっていれば問題なくビルドできています。
root@debian:~# modinfo ib_srpt
filename: /lib/modules/5.10.0-10-amd64/extra/ib_srpt.ko
import_ns: SCST
license: Dual BSD/GPL
description: SCSI RDMA Protocol target driver v3.7.0-pre#in-tree (11 January 2022)
author: Vu Pham and Bart Van Assche
depends: scst,ib_core,rdma_cm,ib_cm
retpoline: Y
name: ib_srpt
vermagic: 5.10.0-10-amd64 SMP mod_unload modversions
sig_id: PKCS#7
signer: SCST Kernel Modules
設定ファイルの作成
昔はscstadminで色々やっていましたが、設定ファイルをある程度作って読み込ませたほうが楽なので以下にサンプルを置きます。SCSTのIBのGIDは/sys/class/infiniband/mlx5_0/ports/1/gids/0などにあるので、こちらをcatなどで開きます。
root@debian:~# cat /sys/class/infiniband/*/ports/*/gids/0
fe80:0000:0000:0000:5849:560e:5c50:0401
fe80:0000:0000:0000:5849:560e:5c50:0409
以下のサンプルはFCでいうところのLUNマスキングをしていない、すべての接続を受け入れてマウントを許可する設定になっています。場合によってはマスキングをしないと意図しないマウントが発生してファイルシステムが壊れるので注意してください。今回はVMFSとESXiからの利用のみを想定しています。TARGET_DRIVER copy_managerは無くてもscstadminが勝手に増やすものなので正直なんだかよくわかりませんが、書いておかないとターゲットの更新をするときなどに--forceをつけて読み直したときに色々終わるので必要なものになります。
cat /etc/scst.conf
HANDLER vdisk_fileio {
DEVICE ram0 {
filename /ramdisk/ram.img
}
}
TARGET_DRIVER copy_manager {
TARGET copy_manager_tgt
}
TARGET_DRIVER ib_srpt {
TARGET fe80:0000:0000:0000:5849:560e:5c50:0401{
enabled 1
rel_tgt_id 1
LUN 0 ram0
}
TARGET fe80:0000:0000:0000:5849:560e:5c50:0409{
enabled 1
rel_tgt_id 2
LUN 0 ram0
}
}
#TARGET_DRIVER iscsi {
#
# enabled 1
#
# TARGET iqn.2022-11.dev-debian-04.sn.1234 {
# QueuedCommands 128
# LUN 0 ram0
# enabled 1
#
# }
#
#}
一度これでSCSTを起動します。systemctl start scst.serviceだとなぜかscst_vdiskが読み込まれないので、手で読み込みます
root@debian:~# for a in scst scst_vdisk ib_srpt ; do modprobe $a ; done
その後、scst_adminで設定を直接読み込んで起動します。
root@debian:~# scstadmin -config /etc/scst.conf
これでESXiにOFEDが入っていればそのうちディスクが見えるはずです。
ESXiからマウントして確認する
LUNマスキングをしていないため、SRPが有効になったESXiがいるIBファブリックにつなぐと定期的にクエリが飛んでいるので勝手にターゲットを認識して未使用ディスクとしてESXiにマウントされます。非公式ながらSRPを使えるESXiは6.7U3が最終です。予め必要なセットアップをしたESXiから見てみます。スペックは以下です。
ターゲット
Dell T5810
CPU Xeon E5-1620 v3
RAM 8*4GB @ 2133MHz (32GB)
HCA: Connect-IB@PCIE 3.0 x16接続 (デュアルポート接続)
RAMDISK 25GB
VMホスト
Supermicro X10SRL-F
CPU Xeon E5-2697 v4
RAM: 8*32GB@2133MHz (256GB)
OFED:MLNX-OFED-ESX-1.8.2.5-10EM-600.0.0.2494585
HCA: ConnectX-3 (not VPI/Pro) @PCIE 3.0 x8接続 ( マルチパス)
その結果が以下です。
速い(確信)
QDRなスイッチに接続されているため、理論値的には80Gbps*0.8 in MB/sで8GB/sが最大ですが、CX3がPCIE 3.0のx8でリンクしているため、PCIEの最大が64Gbpsとなり、それの0.8倍となると6.4GB/sが理論値になるのでかなり近いところまで出ています。もう少しIOPSが出てもいい気がしたので、以下のシステムでも検証してみました。
VMホスト
Supermicro C9Z390-PGW
CPU Core i5 9600K @ AllCore4.8GHz
RAM: 4*32GB@2666 MHz (128GB)
OFED:MLNX-OFED-ESX-1.8.2.5-10EM-600.0.0.2494585
HCA: ConnectX-2 @PCIE 2.0 x8接続 (マルチパス)
その結果が以下です。
速い(確信)
刺さっているのがConnectX-2というPCIE2.0の化石なので帯域は頭打ちになっていますが、CPUのクロックが高いのでIOPSがかなり出ています。
Connect-IBをESXiで使いたい人生だった
Connect-IBはmlx5ドライバを使うため、6.7などでOFEDを入れても認識しません。しかし、デバイスにパススルーをかけてLinux VMでSRPを受け付け、そのディスクをもう一度内部のvmkスイッチとiSCSIで接続することによりストレージプロクシとして動かせば見えるのでは??というスケベ心が起きてしまったので試してみました。これが動けばESXiの上で動くドライバ依存がなくなるので、ESXi8も使えるようになります。センスのない絵にすると以下のような感じになります。SRPドライブはVMによりiSCSIに変換され、ESXiの内部ループバック接続によってDatastoreとしてマウントされます。
結論から言うと、動くには動いたのですが、何故かPCIパススルーをかけたLinuxVM上からのSRPドライブに対してそもそもののパフォーマンスが出ないため、あまり意味がありませんでした。ddなどで負荷をかけるとSRPドライブそのものに対するアクセスが物理環境と比べて負荷が高いように見えました。
とはいえ、ストレージプロクシ経由のESXi8.0環境でも1.4GB/sと10Gbps以上は出ていたので、何かしらのチューニングにより改善する可能性はあります。ただ、物理環境では問題なくてもパススルーVM環境だとib_read_bwが通らなかったりなど、なにか一癖ありそうな雰囲気がありました。起動オプションになにか必要なのかもしれません。
また、SRPドライブをiSCSIでエクスポートし直してファイルシステムがこわれないのか、という疑問については問題ありませんでした。ただし、DEVICEの名前を元の名前と揃えておかないとESXiからマウントしたときのeuiが変わってしまうため、これを合わせる必要はありました。
root@debian:~# cat /etc/scst.conf
HANDLER vdisk_blockio{
DEVICE ram0{ #←ここ
filename /dev/sdb
}
}
TARGET_DRIVER iscsi {
enabled 1
TARGET iqn.2022-11.dev-debian-iscsiloop.sn.1234 {
allowed_portal 10.11.1.1
QueuedCommands 128
LUN 0 ram0
enabled 1
}
}
まとめ
Connect-IBについてはIBで使う限りはなかなか良いのですが、ESXiについてはやはり6.7+CX3止まりということになりそうです。IBは損切りしたいのですが、いかんせん速いので結局これを使い続けることになりそうです。今どきのシステムだとハイパーコンバージドな構成でローカルに高速ストレージを積むのが流行りですが、自宅環境だと最低必要台数とハード構成の縛りが結構きつく、多少の冗長化を捨ててもコンピュートノードとストレージノードを分けられたほうがそれぞれに特化した構成が作れるので都合がいいことが多いです。
とはいえ、そろそろNVMeOFとかiSER使いたいので誰か低消費電力な100Gスイッチください…
[ コメントを書く ] ( 527 回表示 ) | このエントリーのURL | ( 3 / 379 ) | ツイート
<戻る | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 進む> 最後へ>>