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

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

ServerSAN系統(tǒng)的容錯(cuò)能力是指：在網(wǎng)絡(luò)錯(cuò)誤、服務(wù)器硬件失敗的情況下，系統(tǒng)工作不受影響。因?yàn)楫?dāng)存儲(chǔ)系統(tǒng)的節(jié)點(diǎn)數(shù)擴(kuò)展一定的規(guī)模后(如1000個(gè)節(jié)點(diǎn))，同時(shí)系統(tǒng)承受了一定量的用戶請(qǐng)求，節(jié)點(diǎn)上線下線、網(wǎng)絡(luò)斷線連線、磁盤(pán)出錯(cuò)(企業(yè)硬盤(pán)的錯(cuò)誤率在3%左右)的情況就會(huì)很頻繁。在這種情況下，如果系統(tǒng)的容錯(cuò)能力弱，整個(gè)系統(tǒng)就將忙于數(shù)據(jù)遷移和恢復(fù)，正常的客戶數(shù)據(jù)請(qǐng)求的處理會(huì)受到影響。

一般而言，在客戶的IO請(qǐng)求路徑上(比如尋址方式)使用Consistent Hashing、DHT(Distributed Hash Table)或者類(lèi)似的算法，如Ceph的CRUSH算法，都會(huì)導(dǎo)致系統(tǒng)的容錯(cuò)能力弱。這是因?yàn)榇祟?lèi)算法會(huì)在系統(tǒng)的節(jié)點(diǎn)或硬盤(pán)上線下線時(shí)，動(dòng)態(tài)遷移大量數(shù)據(jù)。

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

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

***，需要說(shuō)說(shuō)數(shù)據(jù)安全性。

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

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

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

也正是因?yàn)槿绱耍玫慕鉀Q方案應(yīng)該采用兩地三中心的方式。這也是我個(gè)人推薦的方式。

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

無(wú)論在全球還是國(guó)內(nèi)市場(chǎng)，互聯(lián)網(wǎng)企業(yè)的成功實(shí)踐其實(shí)已經(jīng)印證了這一點(diǎn)，分布式存儲(chǔ)已經(jīng)到了成熟應(yīng)用的階段。但是與此同時(shí)，分布式存儲(chǔ)市場(chǎng)畢竟年輕，特別是市場(chǎng)魚(yú)龍混雜，這無(wú)疑增加了用戶的風(fēng)險(xiǎn)。

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

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