時代和技術在變，但數控分離的架構設計理念未曾改變

談起數據和控制分離架構，耳熟能詳的就是例如Lustre、StorNext、BeeGFS等一樣的文件系統。但除了文件系統外，還有存儲架構(SDS)、數據服務化/存儲雲化軟體(如 Vipr)、雲計算平台(如 OpenStack)和軟體定義網路(SDN)等也採用這種架構，今天我們就逐個簡單聊一下。

先從文件系統開始。但對大多數人來說，接觸的比較多還是傳統的文件系統，如NFS、CIFS等，所有的數據和元數據存放在一起，通過單一的存儲伺服器提供。這種模式稱之為帶內模式(In-band Mode)。隨著客戶端數目的增加，伺服器就成了整個系統的瓶頸。因為系統所有的數據傳輸和元數據處理都要通過伺服器，不僅單個伺服器的處理能力有限，存儲能力受到磁碟容量的限制，吞吐能力也受到磁碟I/O和網路I/O的限制。

在數據增長、並發要求極高(如 HPC等)的需求面前，當今對數據吞吐量要求越來越大的互聯網應用中，傳統的文件系統已經很難滿足應用的需要。必須要采用分散式文件系統(如 Isilon、OceanStor 9000等)，或高性能SAN文件系統來應對此類需求。

於是，一種新的高性能SAN文件系統的結構出現了，那就是利用存儲區域網路(SAN)技術，將應用伺服器直接和存儲設備相連接，大大提高數據的傳輸能力，減少數據傳輸的延時。這種文件系統就是經典的數控分離架構，所有的應用伺服器都可以直接訪問存儲在SAN中的數據，只有關於文件信息的元數據才經過元數據伺服器處理，減少了數據傳輸的中間環節，提高了傳輸效率，減輕了元數據伺服器的負載。每個元數據伺服器給應用伺服器提供文件系統元數據服務，這種模式也稱之為帶外模式(Out-of-band Mode)。

如上提到的文件系統、CXFS、Lustre、BWFS等都採用這樣的結構，因此它可以取得更好的性能和擴展性。區分帶內模式(In-of-band Mode)和帶外模式(Out-of-band Mode)的主要依據是: 關於文件系統元數據操作的控制信息是否和文件數據一起通過伺服器轉發傳送，後者需要伺服器轉發，前者是直接訪問。

下面再看看存儲架構設計，傳統高端存儲的一個典型設計架構就是數據、控制Cache分離。而在高端存儲中，具備數據、控制分離Cache架構設計的典型代表廠商是HDS和HPE。HDS VSP的內存在物理上分為兩大類，一類是由DCA提供的Memory(全局共享)，另一類是由VSD提供的獨享內存。

VSP的Cache分為Data Cache與Control Memory(即數控分離)。Data Cache即為用戶數據的緩存，完全保存在DCA的Memory上，新寫入存儲的數據進行一一鏡像。Control Memory即為運行業務所需的控制數據。實際上，控制數據包括所有內部運行元數據(Internal Operational Metadata)和系統狀態信息(State Information of The System)，元數據除了包含LUN、Pool的元數據等信息外，還包括執行時間表、映射關係、安裝的各種軟體的數據、系統運行時需要存儲、引用、執行需要的全部狀態信息。

Control Memory在VSD內存(每個VSD自帶內存)、DCA上各存一份。其中在DCA上的Control Memory是以優化後可恢復的格式寫入的，屬於備份而不是純粹的鏡像。VSP專門在控制框的第一對DCA上預留空間，用於存放Control Memory的備份。

VSP的實現更像是全局Cache和專有Cache架構，但在實際業務訪問時，由於對元數據的訪問，讀請求為主且僅發生在VSD內部，和全局Cache無關。因此VSP的Cache設計，可以認為是數控分離架構，可實現元數據訪問的快速訪問、減少DCA的訪問衝突，從而保證性能。

3PAR也實現了數控分離架構，並且明確由數據Cache和控制Cache之分。從3Par的宣傳文檔看，數控分離的其主要客戶價值在於: 對並發的事務型小I/O負載與帶寬型大I/O負載，可以做到高效處理，使其相互之間影響最小，其原理如下圖所示。

如未實現數控分離，則處理小I/O所需的控制數據訪問請求有較大概率與大I/O數據傳輸過程相衝突。這個衝突表現在兩個方面:

一是對用戶數據與控制數據所在公共內存的訪問存在匯流排上的衝突；

二是公共計算資源CPU對SCSI命令的處理指令與數據傳輸過程中Parity、CRC計算指令之間的衝突。

對於前一種衝突場景，當內存匯流排成為系統瓶頸時對系統性能有較大影響；對於後一種衝突場景，則是CPU的計算能力成為系統瓶頸時對系統性能有較大影響。

實現數控分離後，SCSI指令的處理(含元數據的訪問)與用戶數據的傳輸過程在計算資源、匯流排通道上實現了物理隔離，互不干擾，有利於事務型小I/O負載與帶寬型大I/O負載的並發高效處理。

總的來說，數控分離架構在內存帶寬不足、CPU計算能力不足的情況下有性能優勢，且能夠很好規避數據和控制信息訪問衝突問題。然而在CPU計算能力過剩、典型業務場景或內存帶寬過剩的情況下，優勢和價值可能就不太明顯。

大家熟悉的OpenStack雲計算平台，在存儲管理上就是採用數據和控制分離的架構，存儲設備通過Cinder、Malina等Restful API透傳存儲能力，通過Nova給VM掛載卷服務，但VM真正的數據訪問還是直接從OpenStack底層的存儲設備上去讀取。

ProphetStor作為SDS廠商，其Federator是個數據服務平台和SDS存儲平台，採用數據和控制分離架構。提供了存儲發現、抽象、池、分類和配置的核心功能，無論是對接不同上層應用形態還是OpenStack雲平台，所呈現的就是一個Federator平台，Federator之下對接了哪些設備是不對外體現的。Federator提供了與OpenStack無縫集成，如集成了OpenStack Cinder、Nova和Horizon等組件。

存儲設備通過API發現和註冊後作為Federator的存儲資源，對客戶而言，只需要關注Federator。ProphetStor在控制面提供的API如下。

在數據面，Federator支持NetApp、Nexenta、Ceph和FalconStor等多種存儲系統適配接入能力，通過冗餘鏈路支持應用對數據存儲的訪問能力。

在控制面上，Federator的存儲聯邦技術支持從異構物理存儲環境中的多個池在抽象層中協同工作，同時抽象了各種底層存儲資源的內置功能，提供了無縫的存儲集成層、Rest API和Web UI，允許定義和滿足用戶或單個應用程序的存儲需求。

OceanStor DJ也是類似的一款控制面SDS存儲控制軟體，統一管理存儲資源，提供業務驅動、自動化的數據服務。其核心是基於OpenStack相關服務的增強，實現存儲資源統一管理，按需分配和數據保護服務。將存儲和數據保護等能力以XaaS的方式提供，實現存儲價值鏈向軟體服務轉移。

在控制面上，OceanStor DJ將存儲的功能特性從物理陣列中抽象出來，把具備相同或近似能力的多個物理存儲池在邏輯上組成資源池。用戶在請求存儲資源的時候，基於資源池的SLA(Service Level Agreement)能力而無需關心後端由哪台陣列為其應用提供存儲服務。

在數據面上，OceanStor DJ具備集成所有類型的數據服務的能力，以及支持應用程序訪問塊存儲、文件存儲的能力。同時由於它始終具有並繼續使用底層存儲陣列獨特的功能，OceanStor DJ的存儲服務也保留了存儲陣列的增值特性，例如遠程複製等，不會增加用戶的購置成本。

總結:這種控制和數據分離的架構很好的利用了數據旁路技術，在現網部署時，不需要改變現網環境，防止在現網加入設備到存儲和伺服器之間，防止中斷業務。在SDS產品中，更重要的是不會成為整個存儲系統的性能瓶頸，防止存儲數量很多時，網關方案成為性能瓶頸。

技術熱文

求知若渴, 虛心若愚—Stay hungry,Stay foolish

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！