在此前的文章中，判斷超融合存儲優(yōu)劣的幾個原則初探(1)判斷超融合存儲優(yōu)劣的幾個原則初探(2)我們說到了裸設備訪問方式，以及系統(tǒng)I/O路徑的問題，應該說這是ServerSAN系統(tǒng)性能影響比較大的兩個因素，用戶在選型中，需要進行仔細地了解和考察。除了影響系統(tǒng)性能的因素之外，我認為系統(tǒng)可擴展性(High Scalability)和容錯能力以及安全性都是需要認真考慮的因素。

對于系統(tǒng)的可擴展性首先要考察系統(tǒng)是否存在瓶頸。需要考察系統(tǒng)是否存在這樣一個組件(component)：系統(tǒng)大部分請求(request)需要經過這個組件或由這個組件來處理，其特征是如果這個組件通常由一臺或幾臺服務器構成，往往就存在著瓶頸的問題，比如SleepDog Storage系統(tǒng)中存在一個Cluster Manager，的組件，它的功能是用于監(jiān)控數據節(jié)點上線/下線的變化，通常通過ZooKeeper來實現。對于ZooKeeper來說，其監(jiān)控能力存在著上限，如1000個數據節(jié)點，如果這1000個數據節(jié)點里面，還有更小的單元的狀態(tài)需要監(jiān)控，如邏輯卷狀態(tài)等，如此就會演變成為上萬個連接數需要被管理，這就大大超過了ZooKeeper的可承受范圍。在這種情況下， Cluster Manager就會成為了ServerSAN系統(tǒng)的瓶頸，導致系統(tǒng)擴展性不好。

ServerSAN系統(tǒng)的容錯能力是指：在網絡錯誤、服務器硬件失敗的情況下，系統(tǒng)工作不受影響。因為當存儲系統(tǒng)的節(jié)點數擴展一定的規(guī)模后(如1000個節(jié)點)，同時系統(tǒng)承受了一定量的用戶請求，節(jié)點上線下線、網絡斷線連線、磁盤出錯(企業(yè)硬盤的錯誤率在3%左右)的情況就會很頻繁。在這種情況下，如果系統(tǒng)的容錯能力弱，整個系統(tǒng)就將忙于數據遷移和恢復，正常的客戶數據請求的處理會受到影響。

一般而言，在客戶的IO請求路徑上(比如尋址方式)使用Consistent Hashing、DHT(Distributed Hash Table)或者類似的算法，如Ceph的CRUSH算法，都會導致系統(tǒng)的容錯能力弱。這是因為此類算法會在系統(tǒng)的節(jié)點或硬盤上線下線時，動態(tài)遷移大量數據。

優(yōu)秀的ServerSAN系統(tǒng)可以通過日志的方式，將節(jié)點或硬盤在下線期間的數據記錄下來，等它們上線后，只復制缺失的數據而避免拷貝所有的數據。

在這里，我們同樣需要一個簡單的判斷的方法。我個人的推薦是，可以通過觀察系統(tǒng)是否存在一個中央控制單元，或中央監(jiān)控單元或中央元數據庫;I/O尋址算法是否使用了DHT或類似的算法。來簡單判斷系統(tǒng)容錯能力好壞。

***，需要說說數據安全性。

我們知道：數據安全性、數據一致性(Data Consistency)和系統(tǒng)性能三者互斥的，即一個系統(tǒng)很難同時達到高數據安全性、強數據一致性和高IOPS的系統(tǒng)。以異地容災為例，在ServerSAN系統(tǒng)中其方法是將一份數據復制到兩個或多個副本到異地數據中心，如此大大提高了系統(tǒng)的安全性。但如此一來，該系統(tǒng)數據一致性和系統(tǒng)性能就有可能會受到影響。

不論是同步復制還是異步復制，這樣的影響都是存在的。

首先是同步數據復制，是在系統(tǒng)成功響應客戶的寫請求之前，數據被復制到至少兩個數據中心，如果是異地數據中心則對于網絡帶寬、延時都有很高的要求，否則將導致系統(tǒng)的性能及其低下。但保持異地數據中心的高網絡帶寬和低延遲，成本會是非常高的。不得已，就會采用異步方式，即在一個數據中心的寫請求一旦成功寫入本地的數據中心即可返回，系統(tǒng)可以在后臺將這部分寫復制到另外的一個數據中心去。非常顯然，異步方式會導致兩個中心的數據存在不一致性。

也正是因為如此，好的解決方案應該采用兩地三中心的方式。這也是我個人推薦的方式。

總之，分布式存儲技術還處于快速的發(fā)展之中，技術并不斷突破和創(chuàng)新。但總體來說，優(yōu)秀的分布式系統(tǒng)已經比較成熟，已經能夠滿足用戶業(yè)務應用的需要，與傳統(tǒng)磁盤陣列相比，分布式存儲的優(yōu)勢毋庸置疑。用戶可以結合實際應用的需要大膽嘗試和選用分布式存儲系統(tǒng)。

無論在全球還是國內市場，互聯網企業(yè)的成功實踐其實已經印證了這一點，分布式存儲已經到了成熟應用的階段。但是與此同時，分布式存儲市場畢竟年輕，特別是市場魚龍混雜，這無疑增加了用戶的風險。

筆者希望通過自己多年經驗的分享，能夠幫助用戶能夠使用和應用好分布式系統(tǒng)。個人的經驗有限，難免存在紕漏，不足之處敬請批評指正。

作者簡介：陳靚，1999年北京航空航天大學碩士畢業(yè)，2002年考入美國俄亥俄州立大學學習計算機科學，2006年獲得該校博士學位。此后入職美國Amazon，于AWS Storage Team(云計算核心存儲團隊)工作，長達7年之久，曾經擔任系統(tǒng)架構師和研發(fā)團隊帶頭人，負責設計和實現了著名的AWS Glacier系統(tǒng)結構;2011年加入AWS S3團隊，負責對AWS S3 的Volume子系統(tǒng)新版本的研發(fā)。2013年，接受南京市政府321計劃的感召，選擇歸國創(chuàng)業(yè)，創(chuàng)辦了南京鵬云網絡科技有限公司，致力于私有云存儲產品的研發(fā)。2015年入選中組部“國家千人計劃”專家人才。