對于大部分人來說，NVMe over Fabrics（簡稱NVMf）還是個新東西，因為其第一個正式版本的協(xié)議在今年6月份才發(fā)布。但是這并不影響人們對NVMf的關(guān)注，因為這項依托于NVMe的技術(shù)很可能繼續(xù)改變存儲市場格局。

NVMf的貢獻(xiàn)在于提供除PCIe外訪問NVM的另一個途徑-Fabrics，并且將fabrics鏈路在latency上增加的overhead維持在10us以內(nèi)。來自NVMf spec的一張圖清晰的展示了它的野心，圍繞著NVMe的戰(zhàn)場再一次擴(kuò)大了。

提供fabrics途徑后，可以在其他節(jié)點直接訪問NVMe設(shè)備，那么最基本的應(yīng)用就是替代傳統(tǒng)的iSCSI，在閃存系統(tǒng)中導(dǎo)出NVMe。

NVMf以NVMe為基石，適配Fabrics場景，新增或刪減了的一些Command、概念。

1，Host，Target和Transport

client端稱作Host，處理client請求的部分稱作Target端（連接物理NVMe設(shè)備），Host和Target之間使用NVMe命令交流。Transport是連接Host和Target的橋梁，可以是RDMA或者FC。在Fabrics傳輸過程中，NVMe命令會被相應(yīng)的Transport代碼封裝（Capsule）和解析。

2，NVMe Subsystem，NVMe Namespace和Port

一個Subsystem就是一個NVMe子系統(tǒng)，Subsystem在target端，Host可以申請連接某個target的Subsystem。一個Port代表一個Transport資源。Subsystem必須和Namespace，Port建立關(guān)系，但是他們的聯(lián)系又是很靈活的：即一個Subsystem可以包含多個Namespace，一個Namespace可以加入多個Subsystem，一個Port可以放入多個Subsystem。如下可以將一個NVMe Namespace放入兩個Subsystem中形成Fabric多路徑配置。

3，NVMe Subsystem中的NVMe Controller

在NVMe Subsystem中，NVMe Controller是一個虛擬的概念，但是具有NVMe協(xié)議規(guī)定的屬性（如部分NVMe寄存器，NVMe Queue和處理NVMe Command）。當(dāng)一個host接入Subsystem后，就會創(chuàng)建一個Controller對象。那么如何處理NVMe寄存器的訪問呢？這就要涉及到NVMf定義的幾個Command。

4，NVMf新增和刪減Command

在NVMf下，Host和Target之間的傳輸舍棄了Doorbell的設(shè)計，刪除了NVMe Queue Create等Admin Command。NVMe Queue的創(chuàng)建在構(gòu)建Controller后就已經(jīng)完成了。

NVMf協(xié)議新增加的Command如下圖，其中Property用來訪問NVMe Controller寄存器（僅限于有限的幾個寄存器，如Controller Configuration），Connect用來連接Host與Controller的NVMe Queue，Authentication則用于權(quán)限管理。

5，NVMe Command的傳輸方式

Host和Target間的NVMe命令可以在Transport封裝時將I/O 數(shù)據(jù)置于NVMe Command（64Bytes）之后，或者使用SGL表示。如果是前者，則target直接從offset處讀取數(shù)據(jù)，如果是后者，則需要通過RDMAread獲取數(shù)據(jù)（Transport為RDMA的情況下）。雖然聲稱使用SGL，但是無論是SPDK還是Kernel 實現(xiàn)的Target在提交給物理設(shè)備的時候都會轉(zhuǎn)換成PRP，所以目前的NVMe SSD還無需擔(dān)心由于無法處理SGL請求導(dǎo)致的問題。

NVMf的推廣很大程度上要依賴于其代碼的實現(xiàn)，好在從Linux Kernel 4.8開始就被收納，目前只有RDMA一種Fabric Transport。接下來我們看看內(nèi)核態(tài)NVMf的代碼框架。

Host端，主要是Host端代碼和非NVMf模式下Local NVMe的處理。不管是Host端，還是Local的請求都會經(jīng)過Linux blk-mq再下發(fā)到物理NVMe設(shè)備。當(dāng)然，在經(jīng)過Fabrics前，I/O請求會先被封裝成NVMe Command格式。

Target端，實現(xiàn)了兩種Transport（Loopback和RDMA），用戶設(shè)置通過configfs進(jìn)行。在收到Host端的I/O請求后，Target也是經(jīng)過blk-mq下發(fā)到物理設(shè)備（其實是通過submit_bio向Host端的Local NVMe代碼發(fā)起請求，類似于文件系統(tǒng)的方式）。

SPDK也加入了NVMf陣營，實現(xiàn)了Target端的代碼。由于SPDK天然的優(yōu)勢，Target端的I/O請求可以直接發(fā)給物理Controller（Direct模式下），并且按照NVMf的規(guī)定將物理Controller作為NVMf獨占，在I/O路徑和框架上看起來更簡潔。

不過，值得一提的是，無論是SPDK還是內(nèi)核NVMf，從Host端過來的NVMe Command都要被Target代碼解析成普通的I/O Request發(fā)給PCIe NVMe代碼處理，所以NVMf下無論是NVMe Queue還是NVMe Command都是相對于Subsystem和host之間而言。

說明

本文最先發(fā)布于公眾號《存儲技術(shù)最前線》，歡迎關(guān)注獲取最新NVMe技術(shù)和資訊

參考資料

1, NVM Express over Fabrics Revision 1.0 spec

2, NVM Express Over Fabrics by Dave Minturn,Intel undle Openfabrics Alliance

3, Under the Hood with NVMe over Fabrics by Dave Minturn,Intel at SNIA forum

4, NVM Express Device Drivers by Uma M.Parepalli at FlashMemroy Summit

總結(jié)

以上是生活随笔為你收集整理的NVMe over Fabrics：概念、应用和实现的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。