一場將陣列控制器移出數(shù)據(jù)路徑之外的變革又洶涌襲來。

叮鈴鈴，現(xiàn)在是NVMeF時間！

NVMe-over-Fabrics (簡稱NVMeF)共享存儲訪問機制可能會徹底令傳統(tǒng)存儲陣列業(yè)務被丟入歷史的垃圾堆，除非相關供應商擁有出色的創(chuàng)造力，并以某種方式繼續(xù)證明為NVMeF數(shù)據(jù)訪問提供數(shù)據(jù)管理服務的必要性。

這一切是如何發(fā)生的？

NVMeF架構面向服務器當中發(fā)出存儲IO請求的應用程序，而服務器與目標存儲系統(tǒng)則利用RDMA傳輸直接面向服務器內(nèi)存與存儲驅(qū)動器進行數(shù)據(jù)往來傳遞，為了提供理想的性能表現(xiàn)，這里的存儲驅(qū)動器基本上是指固態(tài)存儲驅(qū)動器。

之所以需要引入這樣一套機制，是因為虛擬多核心服務器往往不得不坐等IO操作完成，其配套的聯(lián)網(wǎng)SAN與文件管理系統(tǒng)無法快速做出反應，而這將直接導致計算效率低下。利用SATA與SAS閃存驅(qū)動器（SSD）替代這些存儲系統(tǒng)中的磁盤驅(qū)動器能夠在一定程度上帶來性能改善，但這又將引入兩種新的網(wǎng)絡——陣列中的SATA或者SAS，外加陣列與訪問服務器間的塊訪問光纖通道/iSCSI或者文件協(xié)議。這意味著仍有相當一部分時間被耗費在數(shù)據(jù)傳輸所產(chǎn)生的IO請求當中。

內(nèi)部陣列網(wǎng)絡問題可通過使用NVMe驅(qū)動器（其速度高于SAS與SATA）以及NVMeF網(wǎng)絡的方式解決。指向各驅(qū)動器的數(shù)據(jù)由RDMA傳輸至存儲陣列控制器的內(nèi)存當中。其通過控制器軟件堆棧進行處理，同時跨越外部網(wǎng)絡實現(xiàn)陣列往來。

NVMeF模式

以上流程皆需要時間。NVMeF模式旨在利用類似于擴展PCIe總線的機制取代傳統(tǒng)塊訪問網(wǎng)絡，提供端到端NVMe協(xié)議且能夠顯著提升SCSI上的并行性，并可作為訪問服務器與目標存儲陣列之間的RDMA傳輸機制實現(xiàn)運行。這不僅能夠降低物理網(wǎng)絡的傳輸時間，同時亦可通過直接訪問驅(qū)動器將存儲陣列控制器的軟件堆棧從整個傳輸流程當中移除。

好吧，一部分陣列控制器軟件堆棧內(nèi)置于塊訪問協(xié)議當中，例如LUN處理以及將其映射至驅(qū)動器的協(xié)議。然而在多數(shù)情況下，例如RAID模式當中，情況并非如此，其仍然存在于數(shù)據(jù)路徑之內(nèi)。而消除陣列控制器則會帶來另一種后果，失去數(shù)據(jù)管理服務。

我們發(fā)現(xiàn)閃存驅(qū)動器的容量正在日益提高，這意味著用戶已經(jīng)不再需要能夠訪問共享式存儲系統(tǒng)的方式接入體積超出物理驅(qū)動器的數(shù)據(jù)集。希捷公司已經(jīng)擁有64 TB SSD，而三星公司則公布了一款128 TB全新設計方案。

NVMeF訪問與持續(xù)提供的服務器直連存儲（簡稱DAS）容量上限意味著，我們已經(jīng)不再需要陣列控制器這種東西，這可能代表著我們習以為常的現(xiàn)有全閃存雙控制器以及整體陣列將不復存在。相反，存儲陣列在本質(zhì)上只是一堆構成遠程DAS結構的閃存驅(qū)動器（即JBOF），其中包含某些主干共享訪問所必需的NVMe前端。當然，我們也可以直接在超融合型系統(tǒng)當中引入容量更高的DAS存儲資源。

在這樣的嚴峻形勢之下，戴爾、HDS、HPE、IBM、NetApp、Tegile以及Tintri等存儲陣列供應商又該走向何處？

將控制器數(shù)據(jù)管理功能遷移至應用堆棧

一種潛在的可能性在于將部分陣列控制器功能遷移至訪問服務器當中，并在一定程度上將其與NVMe訪問流程并行執(zhí)行。如果這種思路真的可行，那么確實能夠帶來理想的指導方向。

數(shù)據(jù)管理服務此前就已經(jīng)能夠在服務器應用堆棧層級進行交付，具體實例包括：
 

　　但這意味著NVMe驅(qū)動器將無法直接查看，而只能經(jīng)由分卷管理器之類機制實現(xiàn)訪問，這樣的訪問方式也會帶來時間消耗。

其中一部分時耗可以通過在硬件當中執(zhí)行數(shù)據(jù)管理的方式實現(xiàn)消除。RAID已經(jīng)能夠立足硬件實現(xiàn)，且具備通過接入ASIC或者FPGA實現(xiàn)的相對底層的壓縮與擦除編碼操作。

不過對于重復數(shù)據(jù)刪除等級別較高的服務，其需要占用CPU周期與內(nèi)存容量且無法單純利用硬件加以實現(xiàn)。

在這樣的情況下，我們可以采取這樣的方法：使用NVMe架構內(nèi)陣列控制器。驅(qū)動器能夠在200微秒之內(nèi)對數(shù)據(jù)請求作出響應，而NVMe指向驅(qū)動器的訪問則耗時約為10微秒。通過提升數(shù)據(jù)管理堆棧的執(zhí)行效率并將底層任務交由硬件直接完成，我們將能夠把這200微秒的時間浪費壓縮至100微秒以下，這意味著用戶將可在無需變更數(shù)據(jù)管理服務的前提下實現(xiàn)NVMeF加速。

而各類數(shù)據(jù)管理服務將能夠在陣列控制器或者應用程序服務器當中完成。

雙訪問陣列

另一種可行方案在于在現(xiàn)有陣列基礎之上或者以并行方式為一級數(shù)據(jù)添加JBOF，從而建立起雙軌陣列。在此之中，指向及來自該JBOF的數(shù)據(jù)將以二級數(shù)據(jù)的形式被導入至數(shù)據(jù)管理服務域，并在這里進行保護、復制或者重復數(shù)據(jù)刪除等常用操作。

這種方式能夠幫助客戶以并行方式同時運行NVMeF數(shù)據(jù)訪問與原有塊數(shù)據(jù)訪問流，從而更好地完成面向NVMeF時代的過渡。

在NVMeF時代下提供數(shù)據(jù)管理服務

需要指出的是，數(shù)據(jù)管理服務的實現(xiàn)道路并非一帆風順。數(shù)據(jù)保護、復制以及重復數(shù)據(jù)刪除等應對驅(qū)動器、服務器系統(tǒng)乃至高成本存儲故障的重要功能皆很難達成。其中一部分數(shù)據(jù)管理功能需要運行在訪問服務器當中，方可真正在DAS驅(qū)動器故障以及服務器故障場景下實現(xiàn)保護。

那么此類方案將由誰來提供？首先自然是服務器供應商，其能夠憑借操作系統(tǒng)擴展實現(xiàn)這一目標。其次則為陣列供應商，他們可以將陣列軟件組件轉(zhuǎn)換為服務器插件。

就目前來看，陣列供應商在這一領域仍面臨著嚴重問題，這是因為在以某種方式建立起NVMeF未來發(fā)展路徑的過程當中，其當前套件可能將不再適用于存儲一級數(shù)據(jù)。當然，供應商也有可能找到優(yōu)于NVMeF的新型數(shù)據(jù)訪問與存儲方法。但這項任務恐怕將極難達成。

對于服務器與服務器系統(tǒng)軟件供應商而言，這更像是一種潛在機遇而非迫在眉睫的問題。那么，Veritas分卷管理器與其它類似的產(chǎn)品能夠把握機會，在新時代下繼續(xù)生存下去？

服務器系統(tǒng)軟件與陣列控制器軟件工程師們顯然非常睿智，因此我們期待看到他們能夠拿出怎樣的最終方案。