Broadcom, NetApp & SUSE Announce Production Availability of the Industry’s First End-to-End NVMe over Fibre Channel Solution Enabling Groundbreaking Application Performance
]]>vmid 改め VM Insight テクノロジーhttp://kommy.exblog.jp/26415764/2016-11-29T11:27:27+09:002016-11-29T11:27:14+09:002016-11-29T11:27:14+09:00takahiro_komiyaファイバチャネル
VM Insight の要件については下記のとおり。
vmid というのは entity id と application id から構成されており、かつ、source, dest の組から構成されているタグである。entity id は vm の情報であり、通常は仮想マシン名であるはず(ここは vmkernel から hba api をどう呼ぶのかわかれば詳細がわかるが、それはいまのところVMware/HBAメーカしかしらない)。application id は entity id にしたがってファブリックがアサインする固有な id だ。仮想マシンが vmotion したとしても、同じ entity id で登録されれば、同じ application id が割り振られるようになっている。
3) Name Server に自身を登録
a) FC-4 TYPE オブジェクト
0x28h (NVMe over FC)
b) FC-4 Features オブジェクト
ビット 定義
3 予約
2 discovery service supported (1:supported)
1 initiator function supported (1:supported)
0 target function supported (1:supported)
4) Fabric Controller への RSCN の登録(SCR)
5) Name Server に GID_FF(Get PortID_FC4_features)を発行し(IUの中身は initiatorならfeatures:01h, type:28h)、NVMe over FCかつNVMeターゲットポートをサポートするポートIDのリストを取得
6) 上記のリクエストに対する accept CT_IU に含まれるそれぞれの Port ID に対して下記の手順を実行する
a) PLOGI の送信(FC2 リンクの確立);
b) PRLI(FC4 接続の確立)
c) NVMe Report Subsystems コマンドを発行し、ターゲット NVMe_Port 経由でアクセス可能な NVMe Qualified Names(SUBNQNs) のリストを取得
#Windows Server の Synthetic FC HBA 機能などは NPIV を使っているため、ユニークなIDというには制限が多すぎた
VM Insight 機能についてはまだ発表だけで、実装はこれからになる。というのも、VMware やアダプタベンダのサポートも必要になるからだ。これについてはちかいうちに話ができるようになるのでは。
次が2番目の NVMe over FC Fabric だ。ただ、これはこのblogを見ている人であれば、既にいくつも投稿をみているだろう。ここでも書いているとおり、既に NH-IOL での plugfest も行われている。
vmid, NVMeoF (FC/Ethernet) はここから1年半くらい熱いテクノロジだ。
]]>Gen6 FC Plugfesthttp://kommy.exblog.jp/25958972/2016-06-28T12:43:26+09:002016-06-28T12:43:20+09:002016-06-28T12:43:20+09:00takahiro_komiyaファイバチャネル
成果は下記の通り。
Gen6 FC:
Physical conformance to FC Physical Interface-6 (FC-PI-6)
Gen6 32GFC, 16GFC and 8GFC interoperability and backwards compatibility (4lane 128Gは無い)
Multi-topology use case conformance; including 10km ISLs and direct connect
Multi-vendor N_Port Virtualization (NPV) and N_Port ID Virtualization (NPIV) interoperability
Large multi-vendor and high availability redundant fabric conformance
Improved data protection and security
Gen6 – 32GFC and 16GFC forward error correction (FEC) interoperability
T10 Protection Information (PI)
FC port-security, also referred to as port binding
Low-cost high-reliability 32/16/8G FC active-optical-cable(AOC) and DAC interoperability
FC-NVMe – first Industry-wide multi-vendor proof of concept: (キター)
FC Fabric connectivity to a variety of market available NVMe PCI Express-based drives
Multiple vendor FC-NVMe initiator and target interface operations
I/O validation over direct-connect and switched fabric topologies
Concurrent NVMe and legacy SCSI traffic
Backwards compatibility with previous FC speeds, fiber optics, and fiber cables
Packet inspection using updated industry tools
FCoE over 25GbE and Gen 6 converged fabric interoperability and backwards compatibility
25GbE FCoE server to converged Gen 6 FC and FCoE core and storage
Multi-topology use-case conformance
]]>FC-NVMe Data Transfer Ruleshttp://kommy.exblog.jp/25681614/2016-04-18T09:59:21+09:002016-04-18T09:59:11+09:002016-04-18T09:59:11+09:00takahiro_komiyaファイバチャネル
This proposal add data handling functions to FC-NVMe. The goal of this proposal is to translate SGL Data to data residing in the DATA_IU frame. This is needed since FC-NVMe does not use RDMA and thus cannot transfer SGLs directly across the wire.
Two types of data of data are handled:
a) metadata
b) LBA data
]]>NVMe over fabrics battle 続きhttp://kommy.exblog.jp/25287080/2016-01-21T15:26:05+09:002016-01-21T15:25:55+09:002016-01-21T15:25:55+09:00takahiro_komiyaファイバチャネル
#個別にはあるけど。SAP HANA とか
]]>NVMe over fabrics battlehttp://kommy.exblog.jp/25264542/2016-01-13T15:19:10+09:002016-01-13T15:18:43+09:002016-01-13T15:18:43+09:00takahiro_komiyaファイバチャネル
However, FC-NVMe may lead to a Fibre Channel resurgence if it can offer tangible benefits over competing RDMA over RoCE and InfiniBand implementations. There is no doubt that NVMeF is coming to the datacenter on an accelerated time frame - the only question is which interconnect will prove to be the most popular.
上記のいっていることはまったくそのとおりだと思う、ただし上記には多少の強引さもある。
似たような話はいたるところに出ているが、陽に書かれていないのは、Storage Context なのか Non Storage Context なのかという話。前者であれば単なる低遅延ストレージ(とはいえ、NVMeならではの多平行I/Oなどはある)であり、FCの意味もある。米国のようなストレージ/SAN管理者がいるところでは特にそうだ。FCoEがはやらなかった理由でもある。後者の場合、逆に RDMA 勢が強い。もともとFCは Initiator-Target の関係がはっきりしている環境で使う(そうでない環境で問題があるわけではないが)。しかし、RDMA verb を利用する API ベースでの persistence だと必ずしも固定的ではない。とすると、discovery などをfabricサイドで完全に自動化する意味は減る。
]]>Gen6 FC FEChttp://kommy.exblog.jp/25249771/2016-01-08T10:39:43+09:002016-01-08T10:39:28+09:002016-01-08T10:39:28+09:00takahiro_komiyaファイバチャネル
it can correct up to 7 symbols in every 5280-bit transmission. A symbol consists of 10 bits, so there are 528 symbols in every 5280-but transmission.
]]>NVMe over FC fabricshttp://kommy.exblog.jp/25160525/2015-12-08T09:20:00+09:002015-12-08T09:26:35+09:002015-12-08T09:20:03+09:00takahiro_komiyaファイバチャネル
http://www.thefibrechannel.com/articles-by-tfc/qlogic-and-brocade-first-to-demonstrate-non-volatile-memory-express-over-fabrics-with-fibre-channel/
NVMe over Fabric における discovery は既存のさまざまなメカニズムをレバレッジするが、FC の場合、やはり SNS を使用する。このあたり Ethernet Fabric だとどうするのかは考え方次第だが、iSNS なんてのも面白いだろう(NVMe over Ethernet Fabric はまたいずれ)。