如何進行雲端儲存架構框架設計？

隨著網際網路類新興業務的激增、業務資料快速增長，雲端儲存技術應運而生。本文深入剖析了雲端儲存通用框架、硬體架構以及其底層原理這三個技術層面的差異性，為雲端儲存架構框架設計提供了理論依據;再結合細分行業及其業務應用場景的差異性需求，最終確定了滿足企業需求的雲端儲存總體架構，並詳細介紹了架構設計評估和技術選型過程中的一些實踐經驗。

【作者】陳萍春，現就職於保險行業，擁有多年的系統、儲存以及資料備份等運維工作經驗。

1. 概述

隨著網際網路類新興業務的激增、業務資料快速增長，使得企業資料中心儲存系統面臨新的挑戰：大資料、雲端計算等新技術應用帶來了新的儲存應用場景;海量資料儲存衝擊著傳統儲存架構，效能容量成為瓶頸;儲存系統擴容和新建週期長，無法滿足業務敏捷需求。

雲端儲存技術應運而生，敏捷、資源可彈性部署、按需獲取的特性很好地滿足了資料中心海量資料和新興業務快速上線的儲存需求。

2. 雲端儲存技術分析

顧名思義，雲端儲存是在雲端計算基礎上衍生和發展出來的，透過網路將大量異構儲存裝置構成了統一的儲存資源池，在集中式儲存技術基礎上，融合了分散式儲存、多租戶共享、軟體定義儲存等多種雲端儲存技術。

新技術應用都有其兩面性，在設計構建雲端儲存架構框架之前，有必要詳細瞭解和剖析雲端儲存技術，這樣才能結合自身需求做好規劃。下文將從雲端儲存通用框架、儲存硬體架構以及分散式底層儲存技術這三方面展開敘述。

2.1 雲端儲存通用框架

相比於傳統儲存來說，雲端儲存系統是一種層次化的體系結構，其通用框架可參考圖 1 分為雲端儲存服務和雲端儲存資源池兩種，其中雲端儲存資源池是雲端儲存最為核心的部分。

圖 1.雲端儲存通用框架圖

雲端儲存資源池又可細分為資料儲存層、儲存抽象層和儲存介面層。資料儲存層是雲端儲存的基礎，由不同型別的硬體裝置組成，提供多種 IO 效能的儲存資源;儲存抽象層實現了不同型別的儲存裝置的邏輯虛擬化管理，為上層應用提供不同儲存資源的抽象，實現儲存資源的靈活調配;儲存介面層提供了不同型別的儲存介面，實現儲存系統與外部應用的資料傳輸。

雲端儲存服務為使用者提供統一的協議和程式設計介面，提供雲資料盤和物件儲存服務，是雲端儲存資源排程控制的入口，授權使用者可以公共應用介面訪問雲端儲存。

2.2 雲端儲存硬體架構

資料儲存層可根據差異化的需求、細分行業以及不同的應用場景，部署不同架構的資料儲存，這也是儲存硬體選型的關鍵。一般可分為集中式和分散式兩種儲存架構，其中分散式儲存中又可以依據計算與儲存是否解耦，再細分為獨立部署與超融合兩種架構，下文將對這三種架構儲存進行評估。

2.2.1 集中式儲存

集中式儲存的代表是傳統 SAN 儲存或 NAS 儲存，使用專用硬體和儲存控制器。其架構如圖 2 所示，儲存控制器採用雙控或多控互聯架構，包含 RAID 功能和大容量 Cache 。控制器後端連線到磁碟櫃，磁碟櫃包含了多個 RAID 組，每個 RAID 組又包含多塊磁碟，這就組成了集中式的磁碟陣列。

圖 2.集中式儲存硬體架構示意圖

集中式儲存一般提供塊儲存或檔案儲存介面服務，其優點可總結為：

效能：IO 分片粒度小，資料 IO 傳輸路徑短，表現為低時延和高 IOPS ;

可靠性高 ：專有硬體和儲存控制器的可靠性高，基於 RAID 和硬體冗餘等技術也較成熟;

資料強一致性： 控制器、磁碟間的集中式互聯架構最大限度地保證了資料的強一致性。

當然傳統集中式儲存也有其劣勢，這也是分散式架構興起的原因，表現在：

擴充套件性差： 集中式儲存是無法無限制地擴充套件磁碟櫃的，受限於儲存控制器的擴充套件能力;

成本較高： 集中式儲存的高可靠專有硬體也會帶來更高的裝置採購成本和維保成本。

2.2.2 分散式儲存 - 獨立部署架構

分散式儲存採用可擴充套件的系統結構，透過網路將資料分散儲存在多臺獨立的儲存節點上，其架構如圖 3 所示，分散式儲存 - 獨立部署架構由多個專門的儲存節點組成，對外提供各種儲存服務。

圖 3.分散式儲存 -獨立部署架構示意圖

分散式儲存不再依賴於傳統專用硬體，大部分部署在通用伺服器之上，透過軟體定義的方式來實現核心儲存邏輯，其優勢在於：

靈活迭代： 相比於硬體的迭代，軟體版本迭代週期更快更靈活;

硬體成本低： 消除了專有硬體依賴，硬體成本低;

易擴充套件： 分散式架構易於橫向擴充套件，效能容量線性擴充套件。

而分散式儲存的劣勢在於：

複雜度高： 相比於集中式單體架構來說，分散式運維複雜度高;

穩定性低： 部分產品技術成熟度不夠，硬體故障或系統異常場景下，儲存效能易受影響。

2.2.3 分散式儲存 - 超融合架構

超融合架構是一個包含計算、網路、儲存的整體架構解決方案，其儲存本身也是分散式儲存。在超融合形態中，計算與儲存是同一軟體堆疊執行在通用伺服器中的，其架構如圖 4 所示，大多數超融合產品在其節點上會部署控制器虛擬機器 CVM ， CVM 會承擔儲存服務功能，而普通的虛擬機器需與 CVM 通訊才可訪問資料儲存。

圖 4.分散式儲存 -超融合架構示意圖

超融合傾向於計算層和儲存層可以很好耦合的設計理念，除了分散式儲存的優點外，其優勢還包括：

降低運維複雜度： 透過架構設計、部署、日常運維管理的簡化，單一廠商可提供所有軟硬體的支援。

而分散式儲存的獨立部署架構的優勢在於資源自由調配、計算與儲存層可獨立部署擴充套件。這樣來看，超融合的劣勢如下：

新的資源孤島： 無法與外部做資源共享，會帶來資源利用率和統一管理問題;

效能問題： 計算與和儲存會爭搶伺服器硬體資源和網路頻寬，效能問題會更明顯;

橫向擴充套件性不足： 效能風險也間接帶來了無法大規模部署的問題;

系統內部複雜性： 系統架構的簡化帶來了更高的內部複雜性。

2.3 分散式底層儲存技術

相比於集中式儲存，分散式儲存的複雜性更高，但更適應大規模的雲部署場景，有必要深入瞭解其底層原理。分散式儲存存在著獨立部署和超融合的硬體架構差異，而從邏輯層面來看，不管是獨立部署還是超融合架構，又主要分為分散式檔案系統( DFS )和分散式鍵值( k-v )儲存這兩種儲存技術。

2.3.1 分散式檔案系統

雲端儲存技術的複雜性還在於儲存虛擬化技術，它遮蔽了資料 IO 與底層資料儲存的對映與實現細節。如圖 5 所示，分散式檔案系統( DFS )是一種虛擬檔案系統，本身有著檔案目錄結構特徵。而 DFS 對外提供的儲存單元則是由檔案組成，這些檔案又會被邏輯分片，再按照多資料副本分佈演算法分佈到不同資料節點上。

圖 5.基於 DFS的雲端儲存底層原理示意圖

基於 DFS 的雲端儲存邏輯清晰，也有著比較廣的應用範圍，比如 GFS 、 HDFS 等典型應用，包括一些超融合底層儲存也是基於 DFS 來實現的，但也存在著明顯缺陷：

擴充套件性受限： 基於目錄結構的檔案系統，會成為 DFS 大規模擴充套件的瓶頸;

效能方面： 檔案目錄資訊可以透過快取到記憶體中來提高定位資料的速度，但是當檔案數量達到一定量級時，硬體無法滿足時，效能會急劇下降。

2.3.2 分散式鍵值儲存

分散式檔案系統的檔案目錄管理遵循著 map-reduce 的設計思路，化大為小，分而治之，再合併處理，其架構中需要後設資料管理節點來協調，本質上還是一種中心化;分散式鍵值( k-v )儲存是一種無中心化架構，解決了主節點本身的瓶頸，其架構設計思路則是均衡設計，所有節點的地位都是對等的，透過資料佈局演算法均衡分佈在不同節點上。一致性 hash 演算法和虛擬節點是一種通用做法，不同於簡單雜湊 hash 將資料分佈在一條直線上，而是採用首尾相連，將整個雜湊值空間組織成一個虛擬圓環。

ceph 是一種典型基於分散式鍵值的儲存系統，其 object 資料分佈採用的是 crush 演算法，是在一致性 hash 演算法基礎上，充分考慮多副本、故障域隔離等約束設計而來，其實現原理如圖 6 所示。

圖 6.基於分散式 KV的雲端儲存底層原理示意圖

與基於 DFS 的雲端儲存相比，基於分散式 KV 的雲端儲存可以支援更好的擴充套件性，但是也存在如下缺陷：

複雜度高： 基於分散式 KV 的雲端儲存又增加了一層儲存抽象，系統設計和運維複雜度都很高;

效能方面： 寫入延時增加，多資料副本寫入的時延更高一些;

3. 雲端儲存架構框架設計

3.1 總體設計原則和方法

雲端儲存總體設計應堅持以下三項原則：

合適原則： 應與具體所處行業和應用場景相適應，考慮企業實際業務應用情況，注重成本、收益、風險三方面的平衡;

簡單原則： 雲端儲存架構框架本身具有很高的複雜度，架構設計和實際落地過程中更應注意循序漸進，化繁為簡;

前瞻性原則： 應採用業界主流雲端儲存技術，保持技術的先進性，考慮架構的擴充套件能力。

雲端儲存分析設計包括兩種思維方法：

1)自頂向下

自頂向下方法是從雲端計算的整體架構出發，逐步求精，去分析設計雲端儲存通用框架及其組成元素。該設計分析方法既需要對問題域有清晰的瞭解，對行業未來一段時間內的應用場景有清晰的認識，又需要能把控住求解域，對雲端儲存技術發展和應用有深刻的認識。

2)自底向上

自底向上方法則相反，針對實際需要解決的問題，去做雲端儲存產品的技術選型，逐步搭建雲端儲存架構框架，從具體到抽象。

雲端儲存架構框架設計採用哪種方法是需要根據企業實際情況來定的，自頂向下方法需要更高的技術把控力，也需要更多的專案預算，落地前需要謀而後動，充分測試;而自底向上的方法則追求快速應用落地，但需要注意技術應用的連貫性，也需要考慮架構框架最終目標。

而以我司實際情況來看，更適合採用自低向上的方法，根據各種業務應用場景，去評估落地適合的雲端儲存方案，降低試錯成本，在不斷的實踐過程中，去推進雲端儲存架構框架的演進。

3.2 需求分析

3.2.1 應用場景分析

不同行業、業務場景往往決定了雲端儲存不同的應用場景，傳統行業和網際網路行業之間往往也有著明顯差異：

核心業務應用場景： 傳統行業核心業務邏輯的變化不頻繁，核心系統的業務量增長是規律的，可預估的，系統架構穩定;而網際網路行業來說，業務系統追求敏捷迭代，業務量起伏變化較大，系統架構從簡單到複雜，要求彈性伸縮;

網際網路業務應用場景： 對於傳統行業來說，網際網路是一種新的業務擴充渠道，是業務轉型的方向，需要逐步試點開放的;

非結構化資料場景： 非結構化資料場景也有很大差異，在部分場景下，非結構化資料多是系統產生或收集的臨時資料，一次寫入多次讀取，要求 IO 效能穩定，如個人網盤場景;另外一些場景下，非結構化資料要求長期存放，一次寫入很少讀取，逐漸成為冷資料，典型的如銀行保險業務雙錄場景;

資料災備與安全： 無論是傳統行業還是網際網路行業，都需要考慮業務連續性需求，建立資料災備體系和敏感資料保護方案。而金融行業還有著更加嚴格的國家法律法規和金融監管部門要求，業務系統的 RTO 、 RPO 要求更加明確，重要、敏感資料需要安全可控，一般會審慎選擇雲端儲存的部署模式。

3.2.2 資料儲存需求

部署模式

敏感資料情況決定了雲端儲存的部署模式，對於涉及敏感資料較多的系統，一般採用私有部署模式;對於非敏感資料，雲端儲存的成本往往是一個是重要的考慮點，公有云部署除了考慮資料儲存費用外，也還需考慮儲存流量費用。

綜合考慮我司的業務應用場景，雲端儲存排除了公有云模式，而是採用了私有部署模式。

儲存訪問介面

儲存訪問介面對應的是雲端儲存的功能需求，對於我司來說，包括塊儲存、 NAS 儲存介面和物件儲存 S3 介面。塊儲存對應於雲伺服器硬碟需求， NAS 儲存對應於多個雲伺服器間的檔案共享需求，物件儲存 S3 介面對應於網際網路類業務非結構化資料儲存和冷資料歸檔需求。

資料儲存分級

資料儲存分級可以在滿足不同業務系統儲存需求的基礎上，降低整體雲端儲存成本，結合我司業務情況分為：a). 核心業務型別系統及其資料庫，需要最高的儲存效能和可靠性;b). 其他輕量級資料庫，需要較高的儲存效能和可靠性;c). 網際網路類新業務和其他非關鍵類應用，需要一定的儲存效能和較好的擴充套件性;d). 非結構化型別業務資料，需要較高的擴充套件性，儲存效能要求不高;e). 資料備份與歸檔，資料儲存冷熱分層;f). 開發測試系統，利舊儲存。

3.3 雲端儲存總體架構

從行業發展趨勢和企業 IT 戰略轉型方向看，我司傳統業務依然處於基礎性的重要地位，這也決定了集中式儲存架構將與分散式儲存架構長期並存的狀態。分散式儲存架構主要用於新的線上業務場景，集中式 SAN 儲存和 NAS 儲存在傳統業務場景依然佔據重要地位。

最終確立了統一納管異構儲存資源，提供多種型別資料介面、面向海量資料場景的雲端儲存架構，如圖 7 所示 . 可透過引入超融合架構來構建私有云 IaaS 平臺，實現 IT 基礎架構雲化轉型，分別構建開發測試、網際網路類新業務應用等超融合叢集。而海量的半結構化和非結構化資料需要透過分散式物件儲存來構建可彈性擴容的資料湖，採用基於策略的資料全生命週期管理，提供熱、溫、冷不同資源池，實現資料在不同資源池以及雲平臺間的流動和分層。

圖 7.雲端儲存架構示意圖

3.4 架構設計評估

雲端儲存架構設計是否合理，需要從敏感點、權衡點以及架構風險點這三個方面去評估：

敏感點

敏感點對應於不同資料儲存的共有的一些特性，比如儲存的軟硬體成本、可靠性、儲存 IO 效能、架構複雜度、靈活擴充套件能力、資源孤島、故障域隔離和可管理性等屬性;

權衡點

權衡點則是影響多個架構質量屬性的敏感點，需要架構師評估取捨的部分。比如儲存架構是集中式還是分散式決定了儲存的架構複雜度和靈活擴充套件能力;儲存的軟硬體成本也很大程度上決定了儲存的可靠性和效能;資源孤島雖然會造成資源浪費，但合理規劃好，也是故障域隔離的前提。

風險點

對於架構師來說，最需要關注的往往是架構中的風險點，是架構設計成敗的關鍵。分散式儲存架構存在著複雜度高、新技術引入風險以及版本迭代速度快等風險點;超融合架構還面臨著擴充套件性受限、資源孤島等風險;而傳統儲存架構主要風險點在於難以應對海量資料儲存擴充套件，成本較高，與新技術的適配度也不高。

對應於我司的雲端儲存架構設計，傳統 SAN 儲存效能穩定， IO 延時低，成本高，不易擴充套件，但適合於核心業務場景;NAS 儲存效能不高，但易於使用和檔案共享，成本也不高，適合於絕大多數檔案共享訪問場景;分散式物件儲存效能一般，架構複雜度高，但可以靈活擴充套件，支援海量資料儲存，成本低，適合於海量結構化資料儲存和網際網路業務場景;而超融合架構可以很好地與計算資源融合，架構簡單，成本低，雖然有擴充套件性受限和資源孤島問題，但結合公司業務和計算資源配比建立不同超融合叢集，可以做好資料儲存分級，隔離不同的故障域。

3.5 技術選型

按照雲端儲存架構設計評估，我司還需要分別引入分散式物件儲存和超融合兩種不同硬體架構的雲端儲存方案。結合雲端儲存底層儲存技術的分析，分散式物件儲存更適宜採用基於分散式鍵值儲存的產品，效能需求不高，擴充套件性更強;超融合則傾向於基於分散式檔案系統的產品，邏輯架構更加清晰，並不追求超大規模部署，而小規模部署下效能更有優勢。

對於傳統行業來說，開源雲端儲存技術並不能拿來即用，是不適應不同業務系統的儲存需求的。要在雲端儲存這樣的基礎架構領域做到技術自主是非常困難的，也缺乏相應的技術積累、人才隊伍建設和研發資源投入。因此大多數傳統企業都需要選擇不同廠商的雲端儲存產品，做技術選型也就是在篩選不同廠商產品。

不同廠商的分散式儲存都會有其清晰的市場定位和優勢場景，其中廠商對於儲存產品核心技術的把控能力是最重要的，其次是廠商的售後服務水平，當然還要看產品的定價水平。對於我司這樣的中小企業來說，更傾向於跟隨策略，篩選市場份額前列、有大規模的同行業落地案例的廠商產品。

在篩選出了廠商產品之後，技術層面還需要做好 POC 測試，來驗證技術選型。對於雲端儲存產品來說，選型測試還需要考慮以下六點：

業務應用場景

業務型別決定了資料儲存分級標準，資料型別決定了使用儲存連線方式以及雲端儲存產品型別等功能需求，資料容量則決定了雲端儲存的擴充套件效能力要求;

相容性

對於雲端儲存產品來說，軟硬體的相容性是一個重要指標，包括通用伺服器選型、裝置微碼驅動版本、作業系統版本、不同虛擬化平臺等的相容性;

IO效能

IO 效能也是雲端儲存是產品是否適配業務應用場景的另一個重要考量點，相比於通用的儲存效能指標資料，業務場景下的測試更有說服力;

高可靠性

透過開展破壞性測試，來驗證雲端儲存產品的高可靠性;

易管理性

分散式架構複雜度高，雲端儲存的易管理性關係到運維人員是否能很好地管控雲端儲存;

資料保護和容災

資料保護和容災會增加成本，但依然需要考慮資料多維度的安全。