帳號:
密碼:
最新動態
產業快訊
CTIMES / 文章 /
為NVMe-over-Fabrics確定最佳選項
 

【作者: Ian Sagan】   2019年09月17日 星期二

瀏覽人次:【17435】

非揮發性記憶體(NVMe)是一種簡化協定,可提供低延遲操作,並已經被所有重要伺服器和記憶體供應商所採用。這種技術正在替代當下的固態硬碟(SSD)資源中的小型電腦系統介面(SCSI)。


由於這種技術之採用,支援NVMe的SSD目前正在消除傳統儲存方案中的固有瓶頸,從而大大提高從行動平臺到企業資料中心等各種應用的存取速率。在本文中,將回答與支援NVMe的SSD大規模部署和應用相關的一些重要問題。


NVMe為什麼得到廣泛應用和採納?

NVMe從一開始就設計為與快閃記憶體進行高速通訊,並且只需要30個特定用於處理SSD的指令。此外,該協定支援多個深度指令佇列,以便利用最新多核處理器的平行處理功能。籍由每個佇列高達64K之指令,並支援高達64K佇列,NVMe標誌著相較傳統SCSI、SAS和SATA協定之巨大進步,這些傳統協定最初是為旋轉式硬碟(HDD)而開發。


全球基於NVMe的固態硬碟銷售額現已超過與SAS和SATA SSD記憶體相關的產品*。這是由於NVMe協定針對當前和下一代SSD技術(例如3D XPoint和NVDIMM非揮發性DIMM)都能夠提供顯著提高的性能。


為什麼需要考慮NVMe-over-Fabrics?

在初始構思時,NVMe之主要目的是允許CPU使用PCIe匯流排訪問伺服器內基於NVMe的SSD。但是,正如儲存管理員所知,本地伺服器儲存是主要管理難題, 特別是針對需要過量配置昂貴SSD儲存資源(因此才有足夠的空間來應對任何過量需求)之狀況。


不同伺服器需要不同數量高性能NVMe SSD記憶體,具體取決於應用之作業載荷。這些應用可以遷移到不同物理伺服器,但仍需要相同數量SSD記憶體。為了避免每台伺服器都必須配備昂貴的過量SSD記憶體,創建一個可以根據運作負載動態分配儲存的共用NVMe SSD記憶體資源池變得更加經濟高效。


對於本地儲存,最重要的是要將所有資料進行備份,以防伺服器發生故障。此外,由於存在嚴重安全隱患,而且網站之間的複製可能變得難以管理。透過共用儲存,管理員可以避免這些問題出現。換句話說,CIO可以在伺服器上充分利用高性能快閃記憶體,具有現代記憶體陣列所有的高級可用性和安全性功能,以及與本地NVMe SSD記憶體類似的性能和延遲優勢。


NVMe-over-Fabrics還有多遠?

為了幫助解釋這一點,我們可將共用記憶體陣列比作汽車引擎。特定地講,傳統光纖通道(FC)/iSCSI共用記憶體陣列可以認為等同於傳統內燃機,它們已經在業界使用很多年,非常可靠,而且是一種良好的可以長時間運輸的方法。


混合動力汽車越來越普遍,並具有電動車和傳統燃油汽車的一些優勢。類似,較新的NVMe陣列在陣列內部使用混合NVMe,但是它們透過FC或乙太網傳輸協定使用SCSI指令連接到主機。


儘管大多數人都認為電動車將主導未來,但目前它們並不是主流,因為它們比傳統汽車更昂貴,而且基礎設施尚未廣泛完成用於支援電動車充電。本機NVMe陣列可以被認為是全電動車,實現全電動車這一目標所需的基礎設施是NVMe-over-Fabrics。隨著時間推移,NVMe-over-Fabrics或將成為共用記憶體陣列連接到伺服器的關鍵通訊標準,但是在獲得廣泛採納並且在所有初步建設等相關問題得到解決之前尚需一段時間。


應該選擇哪些NVMe-over-Fabrics選項?

儲存管理員面臨的最大困難是如何決定投資正確技術。任何新出現的技術在開始之時都會有多種方法可以實現整體解決方案,NVMe-over-Fabrics也不例外。NVMe指令可以使用TCP/IP透過FC、支援RDMA的乙太網或標準乙太網進行傳輸。下面我們看看這些方式的主要區別。



圖一 : 目前可用的主要fabric連接選項。(source: Marvell)
圖一 : 目前可用的主要fabric連接選項。(source: Marvell)

1. NVMe-over-FC(FC-NVMe)

對於已經擁有FC儲存連接到網路(SAN)基礎設施之用戶,FC-NVMe是一絕佳選項,可以使用16GFC或32GFC主機匯流排適配器和交換機將NVMe協定包含在FC幀中。透過最新升級的FC韌件和驅動程式,可以在Linux伺服器上支援FC-NVMe。因此,如果投資於當代16Gb或32Gb FC主機匯流排適配器和SAN基礎架構,可以為FC-NVMe陣列發佈提供未來保證。


值得注意的是,SCSI(FCP)和NVMe(FC-NVMe)能夠在同一fabric上共存,因此傳統基於FC-SCSI的陣列可以與新NVMe本機陣列同時運作。


2.使用RDMA(NVMe / RDMA)的NVMe-over-Ethernet Fabric

對於這種具備RDMA能力之乙太網,適配器是強制性要求。有兩種不同類型RDMA實施方案,即RDMA-over-converged-Ethernet(RoCE)和Internet廣域RDMA協定(iWARP)。遺憾的是,這些協定不能彼此相互相容。我們現在簡要闡述每個協定之優勢:


a.NVMe-over-RoCE (NVMe/RoCE) -



圖二 : 當網路僅有乙太網可供使用時,NVMe-over-RoCE是共用儲存或超融合基礎架構(HCI)連接的理想選擇。 (source: kacecommunications)
圖二 : 當網路僅有乙太網可供使用時,NVMe-over-RoCE是共用儲存或超融合基礎架構(HCI)連接的理想選擇。 (source: kacecommunications)

當網路僅有乙太網可供使用時,NVMe-over-RoCE是共用儲存或超融合基礎架構(HCI)連接的理想選擇。因此,許多儲存陣列供應商已宣佈計畫支援NVMe-over-RoCE連接。RoCE能夠提供最低乙太網延遲,並且當涉及的儲存網路規模較小時運作良好,只有不超過2個傳輸跳躍。


顧名思義,RoCE需要融合或無損耗乙太網才能運作。這種方法可實現額外網路功能,包括資料中心橋接、優先順序流量控制、以及更複雜設置和網路管理機制。如果低延遲是最重要目標,那麼儘管網路複雜性較高,NVMe-over-RoCE可能仍是最佳選擇。


b.NVMe-over-iWARP(NVMe/iWARP)-


iWARP RDMA協定在標準TCP/IP網路上運作,因此部署起來要簡單許多。雖然其延遲不如RoCE好,但它的易用性和更低管理開銷非常具有吸引力。在現階段,儲存陣列供應商並未設計支援iWARP陣列,因此iWARP目前最適合軟體定義或HCI解決方案,如Microsoft Azure Stack HCI/Storage Spaces Direct(S2D)。


3. NVMe-over-TCP(NVMe/TCP)

NVMe-over-TCP是該領域之新生技術,它於2018年11月批准,可以在現有乙太網基礎設施上運作,無需進行任何更改(充分利用了TCP/IP難以置信的普及性)。 NVMe-over-TCP提供的性能可能不如NVMe-over-RDMA或FC-NVMe快,但能夠在標準NIC和網路交換機上輕鬆實現,因此即便沒有大量硬體投資,仍可獲得NVMe SSD儲存的重要優勢。像MarvellRFastLinQR10/25/50/100GbE這樣的一些NIC可以透過利用內建的NIC中TCP/IP堆疊卸載功能,來卸載和加速NVMe/TCP。


結論

無論決定採用何種NVMe-over-Fabrics技術,Marvell可在實施過程中提供任何幫助。特別是MarvellQLogic 16Gb和32Gb FC主機匯流排適配器能夠支援FC-NVMe,並且(由於採用了通用RDMA功能)Marvell 公司的FastLinQ 41000和45000系列10/25/40/50/100Gb乙太網NIC以及融合的網路適配器支援NVMe-over-RoCE和NVMe-over-iWARP功能,以及NVMe-over-TCP。因此,管理員們可以根據特定需求構建合適的系統,同時確保他們今天部署的設施能夠支援未來網路。


(本文作者Ian Sagan任職於Marvell公司FAE)


註:*依照DRAMeXchange和其它產業研究機構發佈之資料


相關文章
高速數據傳輸方興未艾 NVMe打造現代化儲存新體驗
未來無所不在的AI架構導向邊緣和雲端 逐步走向統一與可擴展
PCIe效能滿足功耗敏感性裝置與關鍵任務應用
PCIe 5.0產品測試驗證引領消費者市場做好準備
互連匯流排的產品生命週期(上)
comments powered by Disqus
相關討論
  相關新聞
» GTC 2024:益登展示跨域人工智慧解決方案
» Ansys模擬分析解決方案 獲現代汽車認證為首選供應商
» Pure Storage更新專為訂閱經濟打造的合作夥伴計畫戰略
» MIC:XR頭戴裝置以Apple與Google新品最受期待
» SOLIDWORKS公開演示未來AI應用 將率先導入工業設計軟體


刊登廣告 新聞信箱 讀者信箱 著作權聲明 隱私權聲明 本站介紹

Copyright ©1999-2024 遠播資訊股份有限公司版權所有 Powered by O3  v3.20.2048.44.221.43.208
地址:台北數位產業園區(digiBlock Taipei) 103台北市大同區承德路三段287-2號A棟204室
電話 (02)2585-5526 #0 轉接至總機 /  E-Mail: webmaster@ctimes.com.tw