Fluid Cache for SAN是個什么樣的解決方案?

它與全閃存陣列相比，有什么優勢?

本文全面闡釋了Fluid Cache for SAN，也為用戶提供了有關兩個方案如何選擇的建議。

在8月的中國閃存峰會之后，另外一場圍繞閃存話題的“2015中國數據加速峰會”日前在北京舉行。盡管會議的名字不同，但閃存在加速數據中心應用中所扮演的重要角色沒有改變，不變的還有一位演講人，有著十幾年豐富經驗的存儲老兵——戴爾大中華區高級存儲經理張委，他的演講重點依然是流動數據4.0和端到端閃存解決方案。

評價一個演講是否成功，要看觀眾對內容的吸收程度，以及有沒有進一步關注的興趣。在這兩次會議上，都有朋友向我了解、討論戴爾Fluid Cache for SAN相關技術，而且他們還并不是專門從事傳統企業存儲(磁盤陣列)的工作——其中一位是分布式存儲、文件系統方面的專家，另一位則是來自互聯網行業的資深DBA。

除了關注技術實現之外，昨天那位朋友還向我提出了一個問題：“Fluid Cache for SAN與全閃存陣列相比，有什么優勢呢?”這確實是一個好問題，也引發了我進一步的思考。如果兩個方案同時放在用戶手里，該如何選擇?——在回答這個問題之前，我想帶大家先簡單回顧一下相關的產品技術。

Fluid Cache

高速、可靠、陣列整合的服務器端閃存

引用自張委在2015中國數據加速峰會上的演講資料，以下同

如上圖，在外部存儲陣列中使用閃存，其性能會受制于存儲網絡瓶頸，此外還有RAID保護、陣列本地管理等方面的抵消。因此，最終的服務器實際訪問性能與SSD理論計算性能的差距很大。

如何更好地發揮閃存性能?Fluid Cache for SAN不只是把SSD/PCIe閃存卡放到服務器中那么簡單。在存儲介質I/O上，它利用了高效的NVMe協議;集群互連網絡目前采用10GbE或者40GbE(未來換用100GbE沒有難度);在以太網上的RDMA傳輸還能夠實現跨節點直接內存訪問，避免用戶態-內核態轉換所造成的性能損失。

正如上面的架構圖，Fluid Cache集群能夠從3個節點擴展到8個節點，其中“Cache貢獻者服務器”限定為戴爾品牌服務器，而訪問高速緩存池的“Cache客戶端服務器”則不限品牌。

關于“與Compellent存儲完美集成”這一點包括2個方面：和SC8000/9000陣列在Enterprise Manager界面中一體化管理;還有快照整合，也就是在陣列生成Replay回放點之前，服務器端閃存中的寫Cache數據將會刷回到后端陣列，以保證數據一致性。

Fluid Cache for SAN與其它服務器閃存緩存方案相比，重要的不同點在于與陣列的無縫整合。它的緩存層對用戶訪問來說是透明的。

這里總結了Fluid Cache for SAN的三大優勢。1.多個服務器上的PCIe/NVMe SSD可以整合為一個閃存池。2.不只加速讀，而且還有寫緩存，也就是說寫策略為write-back而不是write-through。為了保證高可用，避免單點故障，寫緩存中的數據會在服務器節點間鏡像存儲。3.SSD高速閃存模塊為2.5英寸，從機箱前端熱插拔維護，戴爾是業界第一家將SFF-8639的規格引入到服務器上的。

讓我們來看一下Fluid Cache for SAN的擴展性，當OLTP測試環境從3節點架構增加到8節點，并發用戶數提高至7.4倍，每秒交易數增加到6.4倍，同時平均響應時間下降87%達到6ms。為什么延時也會下降呢?我覺得可能是該用例在3節點的緩存池空間只能容納下一部分熱數據，由此產生的后端陣列訪問限制了性能。

混合分層

讓不同閃存最大發揮價值接下來我們再看看戴爾新發布的旗艦級SC9000陣列、經濟型全閃存陣列，以及獨特的混合全閃存配置。

關于存儲系統的硬件形態，一直有“控制器”和“服務器”這兩種路線之爭，在以往，前者在以往“控制器”多代指RISC專用架構，而EMC、NetApp等則是后者——開放架構居多。早在10年前，一位在存儲圈已經很資深的朋友曾經對我說，國內有些“迷信”控制器架構，而服務器架構在國外更受歡迎。

上圖引用自《戴爾SCv2000：入門級陣列硬件設計功力》一文，中端的SC4020在硬件外型上也與之相仿。

后來，隨著IA架構CPU的性能不斷加強，以及在低功耗/嵌入式領域的發力，“控制器”和“服務器”的界限已經模糊。比如上圖中的SBB結構，里面放x86還是RISC CPU，從外面已經看不出來。這種小尺寸、盤/控一體機箱的限制是，CPU的功耗不能太高(不能超過50W)、內存容量和接口擴展能力也都有限。

相比之下，像戴爾SC8000/9000的這類高端控制器，可以采用雙路多核高主頻Intel Xeon處理器(存儲的應用特點決定了頻率比核心數更重要)，支持較大的內存和較多的I/O擴展卡。在今天，“存儲即軟件”更大程度上決定了不同品牌陣列之間的差異性，而出現在某些采購招標參數中的“控制器架構”、“非x86 CPU”等，并非是為用戶考慮，而只不過是一種商業手段罷了。

從另一個方面來看，同樣在2個控制器下，SC8000/9000支持多達960個驅動器，SCv2000和SC4020不超過192個。相應地，它們基于各自定位，在性能、軟件功能上也有所不同，比如只有SC4020及以上型號支持跨不同類型驅動器的自動分層存儲。

戴爾除了率先推出“重新定義存儲經濟性”的TLC 3D NAND企業級SSD的全閃存陣列之外，還將多年來的存儲技術精華——讀寫分離自動分層存儲技術引入全閃存配置。其具體技術特點我們在《向Gartner全閃存魔力象限說“不”》一文中有過介紹，在這里就不詳細展開了。

總的來說，這種閃存優化的自動分層，能夠讓來自主機的寫操作永遠寫入高耐久度/性能的SLC或者eMLC閃存，廉價的MLC或者TLC分層則充分發揮其讀性能以及容量(性價比)優勢。在不顯著提高成本的情況下，兼顧了用戶對“有一定比例寫操作”的需求。

服務器端

緩存、全閃存陣列怎么選?現在到了方案設計討論部分。

首先，Fluid Cache for SAN有點像將陣列中最上層閃存移動到服務器，至少實現的功能類似，當然性能肯定是Fluid Cache更好。

那么，如果使用了Fluid Cache for SAN，后端還需要用閃存，或者分層存儲嗎?

這里面的關鍵點在于，有沒有相對固定的熱數據集，因為主要是未命中的讀I/O會直接訪問后端陣列。我個人的思路是：1、如果是新購系統，SSD/磁盤的分層不建議與Fluid Cache混用;2、如果絕大多數讀I/O都能夠在服務器閃存命中的話，后端用全磁盤即可;3、如果讀的范圍較為分散且隨機，此時后端可以考慮用TLC一類的廉價全閃存方案，Fluid Cache層主要保證寫入速度。

以上的簡要分析，希望對大家有參考意義。

流動數據架構4.0Live Volume不只是復制保護

最后我再簡單談談戴爾的流動數據架構4.0。上圖中“T1存儲內部”和“Fluid Cache for SAN”無需再交待;“T0服務器內部”緩存方案用于加速本地硬盤，無法在服務器故障時提供高可用性;最后是陣列之間流動的Live Volume，作為一個可以實現高可用和容災的技術，大家是否關心它有哪些超越傳統同步/異步復制的地方?

關于Live Volume，我們在《深入DellWorld2015：SC9000存儲軟硬件更新解密》一文中，介紹了最新SCOS 6.7版本支持的自動切換與VMware vMSC(vSphere Metro Storage Cluster)認證。上圖引用自戴爾存儲顧問李英文的一次演講資料，主要介紹Live Volume的另一個關鍵點。

如果是站點級故障，應用服務器和數據存儲一起切換是一種情形。另一種情況，是正在運行的本地/遠程數據中心之間遷移工作負載。比如對于虛擬機遷移，希望底層看到的是同一個共享存儲，也就是所謂的“雙活”。按照傳統陣列復制的方式，控制器和盤同時切換至遠程數據中心，會有一個時間上的中斷(少則數秒);而戴爾Live Volume還支持另一種方式——先切換控制器，臨時透過遠程控制器訪問本地陣列中的數據，再依靠Replay和同步技術將兩端數據追平。