知識星球
談起資料和控制分離架構，耳熟能詳的就是例如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產品中，更重要的是不會成為整個儲存系統的效能瓶頸，防止儲存數量很多時，閘道器方案成為效能瓶頸。
要分享的內容結束了，如果呈現出來的儲存技術大餐還未盡興，那就點選原文連結獲取已整理成文的<傳統企業儲存知識完全解析>電子書吧。
技術熱文
溫馨提示：
請搜尋“ICT_Architect”或“掃一掃”二維碼關註公眾號，點選原文連結獲取更多技術資料。
求知若渴, 虛心若愚—Stay hungry, Stay foolish
