NVMe-oF 1.1規範:多路徑、非對稱命名空間和NVMe/TCP

引言:總體感覺,NVMe就是在不斷引入傳統存儲SCSI的特性,那麼它和分佈式存儲/超融合又能碰撞出什麼火花呢?


今天給大家分享的是NVMe-oF 1.1規範,看下面的圖有朋友可能會問:這不是去年10月的文檔嗎?不錯,早在去年7月24日NVMe 1.4規範正式公佈時,NVMe-oF 1.1 Specification就進入了45天的批准期,然而直到近幾天我才從nvmexpress.org組織官網上下載到它。

NVMe-oF 1.1規範:多路徑、非對稱命名空間和NVMe/TCP

網盤分享

(請訪問文章底部鏈接,附NVM Express 1.4和NVM Express Management Interface 1.1另外2個文檔)

提到NVMe over Fabric,我就會想到它的幾種應用場景:

1、 存儲陣列到主機的網絡連接(替代FC、iSCSI等);

2、 服務器、本地NVMe存儲解耦(跨機箱/JBOF),SSD存儲資源池化共享;

3、 分佈式存儲/超融合系統內部互連?

關於上面第3點,對技術專家來說應該早有答案,而我會在下文中寫出自己的理解和分析,班門弄斧還望大家多指正。

首先,我們來看看當初新聞裡宣佈的NVMe-oF 1.1主要特性:

  • TCP transport supports NVMe-oF on current data center TCP/IP network infrastructure.
  • Asynchronous discovery events inform hosts of addition or removal of target ports in a fabric-independent manner.
  • Fabric I/O Queue Disconnect enables finer grain I/O resource management.
  • End-to-end (command to response) flow control improves concurrency.

我想先聊下這次被正式加入規範的NVMe/TCP。

背景閱讀:《NVMe over TCP:iSCSI的接班人?》

NVMe/TCP加入、網卡卸載的重要性

NVMe-oF 1.1規範:多路徑、非對稱命名空間和NVMe/TCP

與之前的1.0版一樣,NVMe over FC protocol (FC-NVMe) 在新規範裡的篇幅還是一點點,卻仍被排在3種傳輸協議層的頭一個。原因不難想到——那就是光纖通道(Fibre Channel)存儲網絡的已有投資、用戶群,包括SAN交換機和HBA卡等,以及相對更早、更成熟的應用,比如Dell EMC PowerMax等全閃存陣列。

NVMe-oF 1.1規範:多路徑、非對稱命名空間和NVMe/TCP

NVMe over Fabric跑在RDMA協議層上可以有3種選擇:iWARP、InfiniBand和RoCE,其中IB主要集中應用於HPC領域、iWARP普及的不太樂觀,而RoCE的主導和領先者也是Mellanox。

NVMe-oF 1.1規範:多路徑、非對稱命名空間和NVMe/TCP

上面我引用了2018年5月一篇The Register記者的採訪文章《CTO觀點:關於FC-NVMe與NVMe-oF的那些事兒》,當然今天的情況應該會更樂觀。

NVMe-oF 1.1規範:多路徑、非對稱命名空間和NVMe/TCP

上圖中的PDUs是Protocol Data Units(協議數據單元)的縮寫,我想這張圖不用解釋大家也能看懂。

根據我看到的信息,NVMe/TCP並不是在所有的網卡上都能跑出比較理想的性能。這個有點像早期的iSCSI和FCoE,純軟件支持會比較差一些,推薦使用驅動/Firmware支持NVMe/TCP硬件卸載的網卡。

NVMe-oF 1.1規範:多路徑、非對稱命名空間和NVMe/TCP

在《VMware vSAN下一目標:NVMe-oF存儲擴展?》中我曾列出過上面這張圖,Lightbits使用一張FPGA卡來跑NVMe/TCP target和全局FTL等數據服務。這個要想大規模普及,估計離不開initiator端網卡的優化支持。

如今vSAN對NVMe-oF的支持還沒有正式宣佈,前文中我介紹過2種具體的技術實現方式:

- 使用RoCE連接JBOF SSD擴展櫃

- 使用NVMe/TCP連接lightbits閃存“陣列”

除了vSAN之外,對於更多的分佈式存儲/Server SAN和超融合(HCI)而言,NVMe-oF可以被用於計算資源與存儲介質(SSD盤)之間的連接嗎?在解釋這一點之前,我們先來看看NVMe的另外2個新特性:

Multipath和ANA(Asymmetric Namespace Access)

NVMe-oF 1.1規範似乎簡單了點,除了協議本身之外沒有寫更多的東西,所以這部分就要參考NVMe1.4規範了。

NVMe-oF 1.1規範:多路徑、非對稱命名空間和NVMe/TCP

上圖是一個雙控制器/雙端口的NVM子系統示例,在EMC DSSD之後,使用PCIe直連服務器和存儲陣列的應用估計寥寥無幾,所以該子系統基本上代表了雙端口NVMe SSD 和JBOF機箱的設計。比如這裡的NS(NameSpace)B,就可以通過2個NVMe控制器同時提供前端訪問。

NVMe-oF 1.1規範:多路徑、非對稱命名空間和NVMe/TCP

系統的規模再大點,就不是隻靠雙端口SSD能解決了。多主機通過多個NVMe控制器來訪問同一個SSD命名空間,我理解這裡的Namespace就類似於傳統存儲的(SCSI)LUN,而控制器和NVMe盤之間應該會有PCIe Switch。

上圖中Host A對NSID 1的訪問就有2個路徑。具體到4個Controller,可能是x86“刀片”、FPGA或者像Mellanox Bluefield、Broadcom StingrayPS1100R那樣的SoC“智能網卡”。

至於什麼是Asymmetric Namespace Access(ANA,非對稱命名空間訪問)呢?這有點讓我想起了傳統存儲陣列的ALUA(Asymmetric LogicalUnit Access)。

NVMe-oF 1.1規範:多路徑、非對稱命名空間和NVMe/TCP

如上圖,我理解NVMe Controller 1和2可能位於同一模塊或者機箱內,而NVMe Controller 3位於另一模塊/機箱。這時如果是PCIe Fabric,虛線兩邊應該擁有各自的PCIe Switch,之間又有互通。舉例來說,SSD Namespace B和D同時連接到3個NVMe控制器,位於左邊的Controller 1和2訪問性能效率應該較高,而Controller 3不是最優路徑。

我注意到NS B和D被劃在了一個ANA Group,這個感覺也比較像傳統存儲的LUN分組,包括分配/解除映射、路徑策略切換、QoS等操作都可以統一發起。如果存儲軟件支持快照等高級特性,創建時間點一致的快照可能也會調用這個ANA Group吧。

如果用基於RDMA或者TCP以太網的NVMe Fabric,情況會比PCIe要複雜一些,畢竟系統拓撲的規模也增大了,但原理應該和上面這個基本相同。

分佈式存儲/超融合支持NVMe-oF的要點

最後是前面留下的那個問題,NVMe規範對SSD的管理粒度只到NameSpace,而大多數對等節點的分佈式存儲/超融合都需要將底層磁盤(閃存)空間打散成更小粒度的數據塊,這時就需要底層有個文件系統或者類似的對象組織結構,讀寫時產生的跨節點數據操作一般應該是通過私有協議來實現。

NVMe-oF 1.1規範:多路徑、非對稱命名空間和NVMe/TCP

那麼vSAN在計劃中之所以能支持NVMe-oF,應該是將計算節點與JBOF/Lightbits解耦的原因,服務器節點更像是SDS管理網關的感覺。同時帶有本地盤的服務器節點也能一起組成異構集群。

NVMe-oF 1.1規範:多路徑、非對稱命名空間和NVMe/TCP

此時,我又想起了傳統存儲的Scale-up和Scale-out...

注:本文只代表作者個人觀點,與任何組織機構無關,如有錯誤和不足之處歡迎在留言中批評指正。進一步交流技術,可以加我的QQ/微信:490834312。如果您想在這個公眾號上分享自己的技術乾貨,也歡迎聯繫我:)

尊重知識,轉載時請保留全文。感謝您的閱讀和支持!


分享到:


相關文章: