如今SDS領域玩家眾多，技術流派也很多，有開源的、有閉源的；有對稱結構、有非對稱結構；有叫SDS的、也有叫HCI（Hyper-ConvergedInfrastructure）、還有叫ServerSAN、云存儲的，令人眼花繚亂、摸不清頭腦。

應該說SDS還處在發展的初期階段，相應的技術和測試標準都還不完善，客戶對其技術了解的深度也不夠。兩大因素綜合起來造成客戶選擇SDS的時候會感覺無從下手。

三類SDS應用場景的三大關鍵指標

SDS按照提供的數據組織方式分為塊存儲、文件存儲和對象存儲三類。按照交付模式又分成獨立存儲形態和HCI形態（也就是把SDS、計算和網絡集成在一個系統里）兩種。本文僅以SDS的塊存儲類別為例，從企業用戶的角度如何選擇一款適合自己的SDS。

SDS塊存儲的主要應用場景和傳統的SAN設備類似，主要應用在需要提供裸磁盤（塊設備）的場景，例如：服務器虛擬化、桌面虛擬化、數據庫等。當然SDS塊存儲提供出的塊設備也可以格式化成本地文件系統，存放一些非結構化數據，但這不是主要應用場景。

建議客戶選擇SDS的時候，首先需要問一下自己兩個問題：1、主要應用場景是什么？2、最關注的前三位的技術指標是什么？而且還要清楚SDS發展在什么階段（目前SDS還處在社會主義的初級階段），把預期和現實拉得近一些，有些過高的要求在這個階段SDS還不能提供。

關于SDS技術評價通常包括以下7個維度：可靠性、穩定性、擴展性、功能、性能、易用性、兼容性。

針對SDS塊存儲前三位技術指標維度為：

三大應用場景都把可靠性和穩定性排在了前兩位，之所以這樣排列因為存儲是IT系統的基石。所謂的可靠性就是局部故障不會導致數據丟失和業務中斷，這一點理所應當排在第一位；穩定性是指不會因為局部故障造成性能大幅抖動，給業務響應造成影響，比如說看個小電影中途老卡誰受得了。

說到這有人會問，這兩點對于傳統陣列是必須和默認的要求？我想說，傳統陣列都是昂貴、專用的硬件堆起來，發生硬件故障的概率很低，而SDS大都部署在廉價的標準x86服務器上，x86服務器發生硬件故障的概率要高很多；并且SDS都是分布式系統，要管理幾十臺、乃至成千上萬臺x86服務器上，這樣發生硬件故障的概率會呈數量級的上升。如何保證大規模分布式系統的可靠性和穩定性也正是SDS首要解決的難點。

Amazon的S3系統由上百萬臺服務器組成，每分鐘都會有很多設備下線和上線，能保證這樣大規模集群的可靠性和穩定性，應該沒幾個廠家有這樣的技術吧？

另外還別忘了，SDS還處在“社會主義初級階段”并不是拿出來一個廠家就能保證幾千臺服務器的SDS系統可靠和穩定的。

VSI和VDI環境通常規模很大，而且規模增長的速度也較快，所以把擴展性放在了第三位。對于數據庫應用，性能是毋容置疑非常重要的一個指標，所以排在了第三位。

眼見未必為實，測試中的那些“貓膩”

終于想清楚我要的SDS長什么樣了，忽然又想起一件大事“誰家的產品能達到我的要求呢？”

一個最直接的辦法就是拿測試來說吧（測試還是蠻麻煩的一件事，準備測試環境、編寫測試規范、查看測試結果……）。或許還有一個偷懶的辦法，就是“你們有和我的需求差不多的案例嗎？我去問問那家企業用的咋樣啊”，但耳聽為虛眼見為實，聽一面之詞總是不踏實。

相比之下測試是一個較為讓人放心的辦法，但如果你不熟悉SDS的水，同樣有些坑你也發現不了，嘿嘿。

好了，下面這一段就是從測試和技術構架角度幫助客戶判斷關鍵技術指標優劣。

1、B域、C域，1/3節點損壞和RTO為0

可靠性在SDS上主要體現在兩個方面，當集群中磁盤或節點發生故障時，數據會不會丟失？業務會不會中斷？中斷的時長是多少？

這里有兩個指標需要關注：1、容錯度，2、故障恢復時間。

先說一下容錯度這個指標。

因為主流的SDS都采用副本技術，以三副本為例，丟失1份數據，應該還有2份數據存在，數據不會丟，也就是容錯度為1/3個節點。但如果超過1/3的節點同時down機，集群還能工作嗎？這個不一定所有廠家都能做到。

很多SDS的容錯域都是提前配置好的。以3副本9個節點為例，通常會配置3個容錯域ABC、每個容錯域各3個節點，每個容錯域保存獨立的副本數據。例如當以一個容錯域A的3臺機器都故障時，還有兩2個副本存在，數據不會丟失，業務照常運行，這就是通常所說的能容忍1/3節點宕機。這樣的要求大多數廠家都能做到，但如果同時B域或者C域也有機器down機呢？這時候多半會出現兩副本都丟失情況，系統異常了。

故障恢復時間這個指標也很關鍵。當系統中發生節點宕機，故障恢復的時間當然越快越好了，最高的要求是故障恢復時間等于0。要實現這個指標很不容易，因為當SDS系統中節點發生故障時，要恢復這個故障，需要做很多事：第一步，發現這個故障；第二步，選出一個節點接替故障節點，并進行數據重構；第三步，重新刷新尋址空間，讓客戶機能獲取數據位置的變化。每一步都需要時間花費，特別對大規模集群來講，想把故障恢復時間控制得很小更是難上加難。宣稱故障恢復時間為零的SDS廠家并不多。

所以故障恢復時間的數量級是衡量一個SDS可靠性等級的一個非常重要的因子。用戶可以根據前端業務對故障恢復時間的敏感程度，設立相應的要求標準。

2、Ceph性能抖動的問題

對于SDS來講，它的穩定性主要關注點在：當系統發生磁盤/節點故障，恢復數據而產生數據遷移時，前端的性能表現是否穩定。

在前面可靠性段落中談到了，SDS故障恢復有三個步驟，每一步處理不好都會影響性能表現。特別是數據重構和重新尋址這兩個環節，會對性能穩定性造成很大的影響。

例如著名的開源產品Ceph，不止一個客戶反映當系統中出現節點宕機的情況下，性能下降和波動很厲害，對業務影響很大。只所以出現這個問題首先是和它元數據管理和尋址的方式（Crush算法）有關，即在節點動蕩時，元數據（其實是ceph內部保存的資源列表）發生變化，從而導致數據的地址發生變化，最終導致大量的沒有必要的數據遷移，規模越大，這個問題暴露的越明顯。其次是它數據遷移采用整盤拷貝的方式，會有無效遷移導致的網絡帶寬的擁擠。

還有一個坑透露一下，有些SDS系統在拔盤或者宕節點時，可以不發生數據重構，當磁盤或者節點重新上線或歸位時才重構。因此，穩定性測試時最好觀察一下，磁盤或者節點歸位后的表現。甚至建議，用頻繁的節點上/下線來測試它的穩定性，因為節點抖動還是會時常發生的。

3、VSAN的局限

擴展性很難測試，因為你要準備幾百臺、上千臺的服務器環境是不可能，除非你是土豪，那怎么辦？沒辦法，看構架吧。市場上主流SDS分為有中央元數據管理節點的非對稱構架和無中央管理節點的全對稱構架兩大類，前者相比后者擴展性受限。簡單的理解就是“非對稱構架”中好比有個指揮官，一個指揮官能管的人比較有限的。“全對稱構架”中是沒有指揮官的，全憑自覺性，像是一大堆人在干活，一個病了，無需向領導請假，會有另外一個人立馬自動接替他的工作。舉例證明：VSAN是有中央管理節點的，它官方宣稱的單集群支持最大節點數64個；鵬云網絡的ZettaStor是無中央節點的，能支持萬級的節點數量。因此從具體實例上也能看出，構架決定了其擴展能力。

4、SSD緩沖擊穿

目前閃存技術發展得很快，性能比傳統磁介質硬盤高了幾個數量級，正是因為閃存技術的發展也給SDS造就了可以在性能上PK傳統陣列的基礎。

如果你很有錢的話完全可以用SSD做主存。但目前SSD價格還較貴，性價比較高的方式是用SSD做緩存，通常一個存儲節點上配個幾百GB-1TB的SSD做緩存。SSD緩存對性能的貢獻在小數據量時會表現的非常好，一旦數據量足夠大，SSD被穿透，那就實打實地看落盤（寫到硬盤持久化層）的性能表現了。如果你的系統數據量很小，SSD緩存的容量足夠你支持業務峰值，那可以多些關注SDS緩存加速的性能表現。如果你的系統數據量很大，那SSD會長時間被穿透，那你就重點一下落盤的性能表現了。

目前SDS廠家在SSD緩存利用效率上，水平都差不太多，沒有太多很獨到的算法出現。倒是落盤這個環節，因為選擇的技術路線不同，表現不一。有的就是差不多發揮原有磁盤的性能，甚至還低；有的利用一些IO算法，把普通磁盤的性能表現提升幾倍，像鵬云網絡的ZettaStor在落盤時采用了“變隨機為半順序”的IO優化算法，把隨機IO裸盤的速度提升了3-5倍。鵬云網絡之所以能做這樣的IO優化，因為ZettaStor是完全自主開發的。采用開源方案的廠家要實現起來估計會很難，這是要動到其核心文件系統層的。

有些廠家在性能測試時會用很小的卷、很小的數據去測試，看上去IOPS會很高，但真實環境不會是這么小的負載，所以一旦多創建些大卷，進行長時間大數據量的性能測試，SSD被寫穿透時，性能立馬一落千丈，鳳凰變烏雞了。

不記得那位大咖說過一句話，“不談延遲的性能測試都是耍流氓”。

看一個系統的延遲小不小，一個是實測，另外從構架上也能看出些端倪。就是看一下它的IO路徑是否夠短。例如，直接寫裸磁盤的總比經過文件系統層轉換再寫裸磁盤的IO路徑短很多吧，這就是為什么Ceph想降低延遲很難的原因所在。眾所周知，Ceph的塊存儲不是直接訪問裸磁盤的，而是通過文件系統把裸磁盤轉換成塊設備給應用的。

小結

看到了這些問題，是不是讓你對SDS望而卻步了？如果這樣，你就把孩子、臟水一起潑掉了。

就像改革開放，陽光和蒼蠅總會一起進來，良莠不齊，這是目前SDS市場的正常現象，鵬云網絡之所以把些傷疤揭開，是因為相信，真金不怕火煉！用戶可以不選擇鵬云網絡，但一定要爭取選擇正確！這是寫作本文所期待的！