上篇文章《IO時(shí)延你被騙了多久》，竟然沒有人給瓜哥發(fā)紅包!很不像話!冬瓜哥起早貪黑打把勢(shì)賣藝，最終卻連五毛黨都趕不上，所以瓜哥決定這篇文章之后休息一段時(shí)間，玩玩游戲，看看電影，睡睡大覺了。

　　曾幾何時(shí)，你可能被“集群FS” “共享FS”“SANFS”“并行FS”“分布式FS”這些名詞弄得頭暈眼花，冬瓜哥一度也是，而且也找很多人去求證，倒頭來每個(gè)人的說法都不一樣，于是 冬瓜哥開始潛心自己研究總結(jié)。究其本質(zhì)原因是集群系統(tǒng)里有好幾個(gè)邏輯層次，而每個(gè)層次又有不同的架構(gòu)，組合起來之后，花樣繁多，而又沒有人愿意用比較精準(zhǔn) 的名字來描述某個(gè)集群系統(tǒng)，取而代之只用了能夠表征其某個(gè)層次所使用的架構(gòu)來表征整個(gè)系統(tǒng)，這是產(chǎn)生理解混亂的原因。本文會(huì)對(duì)現(xiàn)存的集群文件系統(tǒng)框架進(jìn)行 一個(gè)清晰的梳理、劃界。即便是大名鼎鼎的維基百科，恐怕也沒有一篇文章徹底的梳理所有這些框架，都是零零散散的混亂定義，讓人看了摸不著頭腦。維基百科中 文頻道，冬瓜哥之前增加過一條“集群文件系統(tǒng)”的定義，還有百度百科，大家可以去看看，那個(gè)條目寫的非常概要，而本文則展開講述。

　　【主線1】從雙機(jī)共享訪問一個(gè)卷說開去

　　把一個(gè)卷/Lun/LogicalDisk/Virtual Disk，管它叫什么的，同時(shí)映射給多臺(tái)主機(jī)，管它用什么協(xié)議，IP/FC/IB/SAS，這多臺(tái)主機(jī)會(huì)不會(huì)同時(shí)認(rèn)到這個(gè)卷？會(huì)。每臺(tái)主機(jī)OS里的驅(qū)動(dòng)觸發(fā)libfc/libiscsi/libsas等庫(kù)發(fā)出scsi report lun這個(gè)指令的時(shí)候，存儲(chǔ)系統(tǒng)都 會(huì)將這個(gè)卷的基本信息在scsiresponse里反饋回去，包括設(shè)備類型、廠商、版本號(hào)等，主機(jī)再發(fā)送scsi inquery lun來探尋更具體的信息，比如是否支持緩存以及是否有電池保護(hù)等。接著主機(jī)發(fā)出scsi read capacity來獲取這個(gè)卷的容量，最后主機(jī)OS會(huì)加載一個(gè)通用塊設(shè)備驅(qū)動(dòng)，注冊(cè)盤符。冬瓜哥說的有點(diǎn)多了，上面這些其實(shí)與主題無關(guān)，但是冬瓜哥的思路 屬于線性再疊加類比和發(fā)散思維，必須一步一步串起來，所以不得不多說點(diǎn)。

　　那么在主機(jī)1使用NTFS或者EXT等文件系統(tǒng)格式化這個(gè)卷，寫文件，其他主機(jī)上是否可以直接看到這個(gè)文件？曾幾何時(shí)，不少人問冬瓜哥這個(gè)問 題，瓜哥也測(cè)試過不少人對(duì)這個(gè)問題的看法，喜憂參半。有人天然的認(rèn)為，如果不能實(shí)現(xiàn)這種效果，還玩?zhèn)€屁？持有這種觀點(diǎn)的人就是只浮于表面的那些人而且裝逼 過甚。聽到這個(gè)問題考慮考慮猶豫地說出”應(yīng)該可以吧“的那些人，還算能動(dòng)動(dòng)腦子不過其知識(shí)體系的完整度也真讓人捉急。實(shí)際上，有一定幾率其他主機(jī)可以看到 新寫入的數(shù)據(jù)，但是大部分時(shí)候，其他主機(jī)要么看不到，要么錯(cuò)亂(磁盤狀 態(tài)出了問題比如未格式化等等)。所以多主機(jī)天然可以共享卷，但是天然卻共享不了卷中的文件。咋回事？因?yàn)槊颗_(tái)主機(jī)上的文件系統(tǒng)從來不會(huì)知道有人越過它從后 門私自更改了磁盤上的數(shù)據(jù)，你寫了東西我不知道，我認(rèn)為這塊地方是未被占用的，我寫了東西把你覆蓋掉了，你也不知道，最后就錯(cuò)亂了，跑飛了。多主機(jī)共同處 理同一個(gè)卷上的數(shù)據(jù)，看上去很不錯(cuò)，能夠增加并發(fā)處理性能，前提是卷的IO性能未達(dá)到瓶頸，所以這種場(chǎng)景并不只是思維實(shí)驗(yàn)，是切切實(shí)實(shí)的需求，比如傳統(tǒng)企業(yè)業(yè)務(wù)里最典型的一個(gè)應(yīng)用場(chǎng)景就是電視臺(tái)非線編系統(tǒng)，要求多主機(jī)共享訪問同一個(gè)卷、同一個(gè)文件，而且要求高吞吐量。但是，上述問題成為了絆腳石。

　　咋解決？很顯然兩個(gè)辦法，在這方面，人類的思想都是一樣的，逃不開幾種方案，只要你了解問題根源，稍微動(dòng)點(diǎn)腦子，就不比那些個(gè)底層系統(tǒng)設(shè)計(jì)者想出的辦法差到哪去。

　　圖1

　　如圖1下半部分所示，第一種辦法，既然多個(gè)FS各干各的又不溝通，那么干脆大伙誰都別管理文件了，找個(gè)集中的地方管理文件，大伙想要讀寫創(chuàng)建刪除截?cái)嘧芳尤魏挝募?目錄，把指令發(fā)給這個(gè)人，讓它執(zhí)行，返回結(jié)果，這不就可以了么？是啊，這特么不就是所謂NAS么我說。主機(jī)端的文件系統(tǒng)沒了？非也。還在，只不過只負(fù)責(zé)訪問本地非共享的文件數(shù)據(jù)，對(duì)于那些需要被/與其他主機(jī)共享的文件，放到另一個(gè)目錄里，這個(gè)目錄實(shí)體存在于NAS上，主機(jī)端采用NFS/CIFS客戶端程序?qū)⑦@個(gè)實(shí)體目錄掛載到本地VFS某個(gè)路徑下面，凡是訪問這個(gè)路徑的IO請(qǐng)求都被VFS層重定向發(fā)送給NFS/CIFS客戶端程序代為封裝為標(biāo)準(zhǔn)NFS/CIFS包發(fā)送給NAS處理。這樣，就可以實(shí)現(xiàn)多主機(jī)同時(shí)訪問同一份數(shù)據(jù)了。

　　【支線】數(shù)據(jù)一致性問題的謬誤

　　在這里冬瓜哥給各位開一個(gè)支線任務(wù)。很多人有所迷惑，多個(gè)主機(jī)共享訪問同一個(gè)文件，那么就能避免我寫的數(shù)據(jù)不會(huì)覆蓋你寫的么？不能。既然不能， 那上面豈不是白說了？倒頭來數(shù)據(jù)還不是要相互覆蓋，不一致？估計(jì)我問出這個(gè)問題之后，一大堆人就干瞪眼了，迷糊了。如果不加任何處理，兩個(gè)諸如記事本這樣 的程序打開同一個(gè)文件，同時(shí)編輯，最后的確是后保存的覆蓋先保存的。但是此時(shí)的不一致，是應(yīng)用層的不一致，并不是文件系統(tǒng)層的不一致，也就是說并不會(huì)因?yàn)?主機(jī)A寫入的數(shù)據(jù)覆蓋掉了主機(jī)B寫入的數(shù)據(jù)而導(dǎo)致NAS的文件系統(tǒng)不一致從而需要FSCK或者磁盤格式未知等詭異錯(cuò)誤。那么NAS就放任這種應(yīng)用層的相互 亂覆蓋么？是的，放任之。為何要放任？為何NAS不負(fù)責(zé)應(yīng)用層數(shù)據(jù)一致？那我要問問你，NAS怎么能保證這一點(diǎn)？A寫了個(gè)123進(jìn)去，同時(shí)B寫了個(gè)456 進(jìn)去，NAS是最終把文件保存成123456呢，還是142536呢？還是145236呢？NAS如何能管得了這個(gè)？所以NAS根本就不管應(yīng)用層的一致。 那咋整？鎖啊。應(yīng)用打開某個(gè)文件的時(shí)候，先向NAS申請(qǐng)一個(gè)鎖，比如要鎖住整個(gè)文件或者某段字節(jié)，允許他人只讀，還是讀寫都不行，這些都可以申 請(qǐng)。如果你用MS Office程序比如Word打開某個(gè)NAS上的文件，另一臺(tái)主機(jī)再打開一次，就會(huì)收到提示只能打開只讀副本，就是因?yàn)橛衅渌鳈C(jī)對(duì)這個(gè)文件加了寫鎖。此 時(shí)便可保證應(yīng)用層一致了，而記事本這種程序是根本不加鎖的，因?yàn)樗筒皇菫榱诉@種企業(yè)級(jí)協(xié)作而設(shè)計(jì)的，所以誰都能打開和編輯。所以，應(yīng)用層不一致，與底層 不一致根本就是兩回事。

　　【主線2】標(biāo)準(zhǔn)店銷模式和超市模式

　　NAS是成功解決了多主機(jī)共享訪問存儲(chǔ)的問題，但是自身卻帶來了新問題，第一，走TCPIP協(xié)議棧到以太網(wǎng)再到千兆萬兆交換機(jī)，這條路的開銷太大，每一個(gè)以太網(wǎng)幀都要經(jīng)過主機(jī)CPU運(yùn)行TCPIP協(xié)議棧進(jìn)行錯(cuò)誤檢測(cè)丟包重傳等，這期間除了CPU要接受大量中斷和計(jì)算處理之外，還需要多次內(nèi)存拷貝，而普通Intel CPU平臺(tái)下是不帶DMA Engine的，只有Jasper Forest這種平臺(tái)才會(huì)有，但是即便有，對(duì)于一些小碎包的內(nèi)存拷貝用DMAEngine也無法提升太多性能，主機(jī)CPU耗費(fèi)巨大;第二，系統(tǒng)IO路徑較 長(zhǎng)，主機(jī)先要把IO請(qǐng)求發(fā)給NAS，NAS翻譯成塊IO，再發(fā)送給磁盤，IO轉(zhuǎn)了一手，增加了時(shí)延;第三，NAS本身是個(gè)集中式的存儲(chǔ)設(shè)備，如果NAS設(shè) 備出現(xiàn)IO或者CPU瓶頸，前端主機(jī)數(shù)量再多也沒用。

　　這就是店銷模式的尷尬之處。你想買什么東西，你不能碰，你得讓店員給你拿，如果店員數(shù)量有限，顧客多，那就只能排隊(duì)，或者烏泱泱一幫人你一句我 一句與店員交流，這顯然出現(xiàn)了瓶頸。后來，對(duì)于量大的店，改為了超市模式，顧客先看看貨物的分布圖，然后自己去對(duì)應(yīng)貨架拿貨物結(jié)賬，極大地提升了性能。存 儲(chǔ)也可以這么干。

　　圖2

　　如圖2所示，如果找一臺(tái)獨(dú)立的節(jié)點(diǎn)，專門來管理FS元數(shù)據(jù)，比如塊映射信息、bitmap、權(quán)限等等，而讓原來的兩個(gè)節(jié)點(diǎn)直接認(rèn)到卷。什么!？ 你不是說多個(gè)主機(jī)認(rèn)到同一個(gè)卷，數(shù)據(jù)會(huì)被損毀么？這是沒把東西串起來，沒動(dòng)腦子想。冬瓜哥是說過，但是前提是兩主機(jī)上的FS各管各的?，F(xiàn)在我不讓它各管各 的，還是把FS拿出來，但是拿到旁邊去，平時(shí)別擋路，讓原來的節(jié)點(diǎn)直接訪問盤，但是節(jié)點(diǎn)訪問盤之前，必須經(jīng)過第三個(gè)節(jié)點(diǎn)也就是圖中的FS節(jié)點(diǎn)的授權(quán)和同 意，這樣的話就不會(huì)不一致，而且還能獲得更高的速度，因?yàn)榇藭r(shí)可以使用比如FC/SAS/IB等對(duì)CPU耗費(fèi)少(協(xié)議傳輸層直接在卡里硬件完成)的鏈路類 型，另外IO直接從節(jié)點(diǎn)下來到卷，不用轉(zhuǎn)手。此時(shí)的IO流程是：節(jié)點(diǎn)上使用一種特殊的客戶端(并非傳統(tǒng)NFS/CIFS客戶端)，任何對(duì)文件的操作都通過 Eth交換機(jī)向FS節(jié)點(diǎn)查詢，比如一開始的ls，后續(xù)的open/read/write等，F(xiàn)S會(huì)將對(duì)應(yīng)文件的信息(權(quán)限、屬性、對(duì)應(yīng)的卷塊地址等)返回 給節(jié)點(diǎn)，節(jié)點(diǎn)獲取這些信息，便直接從卷上讀寫數(shù)據(jù)，所有的元數(shù)據(jù)請(qǐng)求包括鎖等，全部經(jīng)由Eth網(wǎng)與FS節(jié)點(diǎn)交互。這便是存儲(chǔ)里的超市模式。

　　專業(yè)術(shù)語，店銷模式稱為帶內(nèi)模式或者共路模式，超市模式則為帶外模式或者旁路控制模式或者隨路模式。而圖2中所示的方式，則就是所謂帶外NAS系統(tǒng)。或者有人起了個(gè)更忽悠人的名字：“共享文件系統(tǒng)”/“共享式文件系統(tǒng)”，或者SanFS，也就是多主機(jī)通過SAN網(wǎng) 絡(luò)共享訪問同一個(gè)卷，而又能保證文件底層數(shù)據(jù)一致性。上述的這種共享文件系統(tǒng)無非包含兩個(gè)安裝組件，元數(shù)據(jù)節(jié)點(diǎn)安裝Master管理軟件包，IO節(jié)點(diǎn)安裝 客戶端軟件包，經(jīng)過一番設(shè)置，系統(tǒng)運(yùn)行，所有IO節(jié)點(diǎn)均看到同樣的目錄，目錄里有同樣的同一份數(shù)據(jù)，因?yàn)樗鼈兌际菑脑獢?shù)據(jù)節(jié)點(diǎn)請(qǐng)求文件目錄列表以及數(shù)據(jù) 的，看到的當(dāng)然是一樣的了。如圖所示，NFS/CIFS客戶端是不支持這種方式的，需要開發(fā)新的客戶端，這個(gè)客戶端在與FS節(jié)點(diǎn)通信時(shí)依然可以使用類似NFS的協(xié)議，但是需要增加一部分NFS協(xié)議中未包含的內(nèi)容，就是將文件對(duì)應(yīng)的塊信息也傳遞給客戶端，需要做一下開發(fā)，其他的都可以沿用NFS協(xié)議，此外，這個(gè)特殊客戶端在IO路徑后端還必須增加一個(gè)可直接調(diào)用塊IO接口的模塊，NFS客戶端是沒有實(shí)現(xiàn)這個(gè)的。

　　【主線3】對(duì)稱式協(xié)作與非對(duì)稱式協(xié)作

　　咱們?cè)僬f回來，除了使用帶內(nèi)NAS或者帶外NAS方式之外，還有另一種辦法解決多節(jié)點(diǎn)共享處理同一份數(shù)據(jù)，而且相比NAS顯得更加高大上和學(xué)院 派。如圖1上半部分所示，既然大伙各管各的又不溝通，那我讓你們之間溝通一下不就可以一致了么？沒錯(cuò)，在各自的FS之上，架設(shè)一個(gè)模塊，這個(gè)模塊專門負(fù)責(zé) 溝通，每個(gè)人做的改變，均同步推送給所有人，當(dāng)然，要改變某個(gè)數(shù)據(jù)之前，必須先加鎖占坑，否則別人也有可能同時(shí)在試圖改變這個(gè)數(shù)據(jù)。加鎖的方式和模式有很 多種，這個(gè)瓜哥會(huì)在后續(xù)文章中介紹。很早期，Win平臺(tái)有個(gè)名為Sanergy的產(chǎn)品，其角色就是構(gòu)架在NTFS之上的一個(gè)溝通同步、加鎖、文件位置管理 和映射模塊，但是很難用，性能也很差，這個(gè)產(chǎn)品后來被IBM收購(gòu)以后就沒下文了，其原因是該產(chǎn)品與NTFS松耦合，對(duì)NTFS沒有任何改動(dòng)，只是在上面做了一些映射定向，開銷非常大，是一個(gè)初期在廣電領(lǐng)域非線編系統(tǒng)對(duì)于多機(jī)共享卷的強(qiáng)烈需求下出現(xiàn)的產(chǎn)品。再比如Ibrix(HP x9000 NAS的底層支撐集群文件系統(tǒng))則是架構(gòu)在EXT3 FS之上的集群管理模塊，其對(duì)EXT3文件系統(tǒng)也沒有修改。

　　這種模式的集群文件系統(tǒng)，稱為“對(duì)稱式集群文件系統(tǒng)”，意即集群內(nèi)所有節(jié)點(diǎn)的角色都是均等對(duì)稱的，對(duì)稱式協(xié)作，大家共同維護(hù)同一份時(shí)刻一致的文 件系統(tǒng)元數(shù)據(jù)，互鎖頻繁，通信量大，因?yàn)橐粋€(gè)節(jié)點(diǎn)做了某種變更，一定要同時(shí)告訴集群內(nèi)所有其他節(jié)點(diǎn)。相比之下，上文中所述的那種超市模式的帶外NAS文件 系統(tǒng)，則屬于“非對(duì)稱式集群文件系統(tǒng)”，有一個(gè)集中的獨(dú)裁節(jié)點(diǎn)，非對(duì)稱式協(xié)作，或者說沒有“協(xié)作”了，只有“獨(dú)裁”。

　　顯而易見，對(duì)稱式協(xié)作集群有個(gè)天生的劣勢(shì)，就是看上去好看，人們都喜歡對(duì) 稱，但是用起來就不那么舒坦了，兩個(gè)原因，第一個(gè)是其擴(kuò)展性差，節(jié)點(diǎn)數(shù)量不能太多，否則通信量達(dá)到瓶頸，比如32個(gè)節(jié)點(diǎn)的話，每個(gè)節(jié)點(diǎn)可能同時(shí)在與其他 31個(gè)節(jié)點(diǎn)通信，此時(shí)系統(tǒng)連接總數(shù)近似為32x32，如果一千個(gè)節(jié)點(diǎn)，則連接總數(shù)為999x999，節(jié)點(diǎn)性能奇差。其次，安全性方面，對(duì)稱式協(xié)作，多個(gè)節(jié) 點(diǎn)間耦合性非常緊，一旦某個(gè)節(jié)點(diǎn)出現(xiàn)問題，比如卡殼，那么向其加鎖就會(huì)遲遲得不到應(yīng)答，影響整個(gè)集群的性能，一人出事全家遭殃，再就是一旦某個(gè)節(jié)點(diǎn)發(fā)飆把 文件系統(tǒng)元數(shù)據(jù)破壞了，也一樣是全家遭殃，重則整個(gè)系統(tǒng)宕機(jī)FS再也掛不起來，輕則丟數(shù)據(jù)或不一致。所以，也只有少數(shù)幾家技術(shù)功底深厚的追求完美的公 司做出了類似產(chǎn)品，典型代表就是Veritas的CFS，類似的產(chǎn)品還有Ibrix。還有一些對(duì)稱式協(xié)作集群產(chǎn)品，其內(nèi)部并非是純粹的對(duì)稱式協(xié)作，而是按 照某種規(guī)則劃分了細(xì)粒度的owner，比如目錄A的owner是節(jié)點(diǎn)A，目錄B的owner是節(jié)點(diǎn)B，所有的IO均需要轉(zhuǎn)發(fā)給owner然后由owner 負(fù)責(zé)寫盤，這樣不需要加鎖，降低通信量;或者將鎖的管理分隔開，比如目錄A的鎖管理節(jié)點(diǎn)職責(zé)賦給節(jié)點(diǎn)A，這樣大家訪問目錄A就都向A節(jié)點(diǎn)加鎖，而不用所有 人都發(fā)出鎖請(qǐng)求，GPFS對(duì)稱式協(xié)作FS就是這種做法。但是這些加了某種妥協(xié)的架構(gòu)也就不那么純粹了，但的確比較實(shí)際。這些不怎么純粹的協(xié)作管理，可以被 歸為“Single Path Image”，也就是其協(xié)作方式是 按照路徑劃分各個(gè)子管理節(jié)點(diǎn)的，甚至每個(gè)節(jié)點(diǎn)可能都掌管一個(gè)獨(dú)立的文件系統(tǒng)，然后由協(xié)作層將其按照路徑虛擬成一個(gè)總路徑，Windows系統(tǒng)之前內(nèi)置有個(gè) DFS就是這么干的;而純粹的對(duì)稱協(xié)作，可以被歸為“Single Filesystem Image”，意即整個(gè)集群只有一個(gè)單一文件系統(tǒng)，所有人都可以管理任何元數(shù)據(jù)，完全純對(duì)稱。當(dāng)然，SPI和SFI這兩個(gè)估計(jì)逼格高甚，可能不少人已經(jīng)難 以理解了，所以冬瓜哥也就不再繼續(xù)費(fèi)手指頭打字了。

　　即便如此，對(duì)稱式協(xié)作集群的節(jié)點(diǎn)數(shù)量也不能增加到太多。而非對(duì)稱式集群，由于耦合度很低，只是多對(duì)1耦合(每個(gè)IO節(jié)點(diǎn)對(duì)元數(shù)據(jù)節(jié)點(diǎn)之間耦合)，通信量大為降低，目前最大的非對(duì)稱式協(xié)作集群FS可達(dá)單集群13K臺(tái)，基于HDFS。

　　說到這里，冬瓜哥要做個(gè)總結(jié)了。

　　 圖3

　　如圖3和圖4所示，冬瓜哥把集群文件系統(tǒng)架構(gòu)分割為三層，最底層為數(shù)據(jù)訪問層或者說存儲(chǔ)層，在這一層，上述的架構(gòu)都使用了共享式架構(gòu)，也就是多 節(jié)點(diǎn)共享訪問同一個(gè)或者同多個(gè)卷。再往上一層，冬瓜哥稱之為協(xié)作管理層，這一層有對(duì)稱式協(xié)作和非對(duì)稱式協(xié)作兩種方式，分別對(duì)應(yīng)了多種產(chǎn)品，上文中也介紹 了。最頂層，就是數(shù)據(jù)訪問層，其實(shí)這一層可有可無，如果沒有，那么需要把應(yīng)用程序直接裝在IO節(jié)點(diǎn)上，應(yīng)程序直接對(duì)路徑比如/clusterfs /cluster.txt進(jìn)行代碼級(jí)調(diào)用即可比如read()。

　　圖4

　　而如果將某個(gè)節(jié)點(diǎn)上的這個(gè)路徑，使用NFS/CIFS server端export出去，再找一臺(tái)server用NFS/CIFS客戶端mount上來讀寫的話，那么這個(gè)集群系統(tǒng)就成了一臺(tái)集群NAS了，從任 何一個(gè)節(jié)點(diǎn)上都可以mount，這樣就增加了并發(fā)度，增加了性能，當(dāng)然，前提是底層的卷提供者未達(dá)到瓶頸。把應(yīng)用和IO節(jié)點(diǎn)裝在同一臺(tái)server上，有 些低逼格的說法叫做“HCI”，所謂超融合系統(tǒng)。冬瓜哥之前是一名純粹的產(chǎn)品經(jīng)理，也善于包裝忽悠，有興趣者可以看本公眾號(hào)(大話存儲(chǔ))之前文章：《可視 化存儲(chǔ)智能—思路、技術(shù)和展現(xiàn)》。

　　往事不可追如冷風(fēng)吹。好了，大家可以看到一個(gè)集群文件系統(tǒng)的三層框架架構(gòu)，其中在協(xié)作管理層，有兩種架構(gòu)，第一種是對(duì)稱式協(xié)作，第二種是非對(duì)稱 式協(xié)作。好了，其實(shí)上面這句話就是前文啰嗦一大堆的精髓所在。而我們現(xiàn)有的多數(shù)教材，是反過來說，它先特么給你總結(jié)和抽象，把你搞暈，然后可有可無懶懶散 散的舉幾個(gè)不明不白的例子。冬瓜哥對(duì)此深惡痛絕，去特么的!耽誤了多少莘莘學(xué)子的寶貴人生!這也是冬瓜哥急切想進(jìn)入教師體制的原因，因?yàn)榭吹絼e人說不清楚 某個(gè)東西，瓜哥心里捉急啊。

　　【支線】RAC、SMP和AMP

　　咋樣？做完剛才那個(gè)主線任務(wù)，是不是有種蕩氣回腸的感覺呢？休息一下，來做個(gè)支線吧。Oracle RAC屬于對(duì)稱式協(xié)作+共享存儲(chǔ)型集群。而早期的CPU和RAM之間的關(guān)系，也是對(duì)稱式協(xié)作+共享存儲(chǔ)型集群，如果把CPU看做節(jié)點(diǎn)，RAM看做存儲(chǔ)的 話，多CPU通過FSB共享總線通過北橋上的DDR控制器訪問下掛的集中的RAM。多個(gè)線程可以隨意在多CPU上任意調(diào)度，哪個(gè)CPU/核心執(zhí)行都可以， 這不是對(duì)稱是什么？而且針對(duì)緩存的更新會(huì)有一致性廣播探尋發(fā)出，這不是協(xié)作是什么？多CPU看到同樣的RAM地址空間，同樣的數(shù)據(jù)，這不是共享存儲(chǔ)是什 么？這種CPU和RAM之間的關(guān)系又被稱為SMP，對(duì)稱對(duì)處理器。 與對(duì)稱式協(xié)作面臨的尷尬相同，系統(tǒng)廣播量太大，耦合太緊，所以后來有了一種新的體系結(jié)構(gòu)成為AMP，非對(duì)稱對(duì)處理器。典型的比如Cell B.E處理器，被用于PS3游戲機(jī)中，其中特定的內(nèi)核運(yùn)行OS，這個(gè)OS向其他協(xié)處理內(nèi)核派發(fā)線程/任務(wù)，運(yùn)行OS的內(nèi)核與這些協(xié)處理核之間是松耦合關(guān) 系，雖然也共享訪問集中的內(nèi)存，但是這塊內(nèi)存主要用于數(shù)據(jù)存儲(chǔ)，而不是代碼存儲(chǔ)，這種處理器在邏輯架構(gòu)上可以擴(kuò)充到非常多的核心。具體冬瓜哥不再多描述， 后續(xù)看機(jī)會(huì)可能會(huì)在其他文章中詳細(xì)介紹Cell B.E處理器。

　　但是好景不長(zhǎng)。十年前，共享存儲(chǔ)型的SMP處理器體系結(jié)構(gòu)，被全面替換為NUMA架構(gòu)。起因是因?yàn)榧蟹挪嫉膬?nèi)存產(chǎn)生了瓶頸，CPU速度越來越 快，數(shù)量越來越多，而內(nèi)存控制器數(shù)量太少，且隨著CPU節(jié)點(diǎn)數(shù)量增加滯后，訪問路徑變得太長(zhǎng)，所以，每個(gè)CPU自己帶DDR控制器，直接掛幾根內(nèi)存條，多 個(gè)CPU在互聯(lián)到一起，形成一個(gè)分布式的RAM體系，平時(shí)盡量讓每個(gè)CPU訪問自己的RAM，當(dāng)然必要時(shí)也可以直接訪問別人的RAM。在這里冬瓜哥不想深 入介紹NUMA體系結(jié)構(gòu)，同樣的事情其實(shí)也發(fā)生在存儲(chǔ)系統(tǒng)架構(gòu)里。

　　中間插入一個(gè)問卷調(diào)查，投票完請(qǐng)繼續(xù)閱讀余下部分。冬瓜哥的逼格你覺是否需要再提高？

　　【主線4】分布式存儲(chǔ)集群——不得已而為之

　　錢、性能 for 互聯(lián)網(wǎng)企業(yè);可靠性、錢、性能for傳統(tǒng)企業(yè)。人們無非就是受這幾個(gè)主要因素的驅(qū)動(dòng)?；ヂ?lián)網(wǎng)企業(yè)動(dòng)輒幾千個(gè)節(jié)點(diǎn)的集群，讓這幾千個(gè)節(jié)點(diǎn)共享卷，是不現(xiàn)實(shí)的，首先不可能用FC這種高成本方案，幾千端口的FC交換機(jī)網(wǎng)絡(luò)，互聯(lián)網(wǎng)就算有錢也不會(huì)買些這個(gè)回來。就用以太網(wǎng)!那只能用iSCSI來 共享卷，可以，但是性能奇差。其次，互聯(lián)網(wǎng)不會(huì)花錢買個(gè)SAN回來給幾千臺(tái)機(jī)器用，一個(gè)是沒錢(是假的)，第二個(gè)是沒有哪個(gè)SAN產(chǎn)品可以承載互聯(lián)網(wǎng)幾千 個(gè)節(jié)點(diǎn)的IO壓力的，雖然這些廠商號(hào)稱最大支持64K臺(tái)主機(jī)，我估計(jì)它們自己都沒有實(shí)測(cè)過，只是內(nèi)存數(shù)據(jù)結(jié)構(gòu)做成可容納64K條而已。

　　那怎么解決幾千個(gè)節(jié)點(diǎn)的集群性能問題？首先一定要用非對(duì)稱式協(xié)作方式，是的，互聯(lián)網(wǎng)里從來沒有人用過對(duì)稱式集群，因?yàn)閿U(kuò)展性太差。針對(duì)存儲(chǔ)瓶頸 問題，則不得不由共享式，轉(zhuǎn)為分布式。所謂分布式，也就是每個(gè)節(jié)點(diǎn)各自掛各自的存儲(chǔ)，每個(gè)節(jié)點(diǎn)只能直接訪問自己掛的磁盤卷，而不能直接訪問他人的磁盤，這 與NUMA訪問內(nèi)存是有本質(zhì)不同的，NUMA里任意CPU可以直接在不告訴其他人的前提下直接訪問其他人的RAM。為什么分布式就可以提升IO性能？這其 實(shí)是基于一個(gè)前提：每個(gè)節(jié)點(diǎn)盡量只訪問自己所掛接硬盤里的數(shù)據(jù)，避免訪問別人的，一旦發(fā)生跨節(jié)點(diǎn)數(shù)據(jù)訪問，就意味著走前端以太網(wǎng)絡(luò)，就意味著低性能。 NUMA就是這么干的，OS在為進(jìn)程分配物理地址時(shí)，盡量分配在該進(jìn)程所運(yùn)行在的那個(gè)CPU本地的RAM地址上。

　　互聯(lián)網(wǎng)里的Hadoop集群使用的Mapreduce就可以保證每個(gè)節(jié)點(diǎn)上的任務(wù)盡量只訪問自己硬盤里的數(shù)據(jù)，因?yàn)檫@種大數(shù)據(jù)處 理場(chǎng)景非常特殊，所以能從應(yīng)用層做到這種優(yōu)化。而如果你把一個(gè)Oracle RAC部署在一個(gè)分布式集群里，RAC是基于共享存儲(chǔ)模式設(shè)計(jì)的，它并不知道哪個(gè)數(shù)據(jù)在本地哪個(gè)在遠(yuǎn)端，所以難以避免跨節(jié)點(diǎn)流量，所以效率會(huì)很低。但是我 們的Server SAN同志雖然使用了分布式存儲(chǔ)架構(gòu)，但是卻成功的使用高性能前端網(wǎng)絡(luò)比如萬兆甚至IB以及高性能的后端存儲(chǔ)介質(zhì)比如PCIE閃存卡規(guī)避了超級(jí)低的相對(duì)效率，而把絕對(duì)性能提上去了，其實(shí)考察其對(duì)SSD性能的發(fā)揮比例，恐怕連50%都不到。

　　值得一提的是，在分布式集群中，雖然數(shù)據(jù)不是集中存放的，但是每個(gè)節(jié)點(diǎn)都可以看到并且可以訪問所有數(shù)據(jù)內(nèi)容，如果數(shù)據(jù)不存在自己這，那么就通過 前端網(wǎng)絡(luò)發(fā)送請(qǐng)求到數(shù)據(jù)所存儲(chǔ)在的那個(gè)節(jié)點(diǎn)把數(shù)據(jù)讀過來，寫也是一樣，寫到對(duì)應(yīng)的遠(yuǎn)端數(shù)據(jù)節(jié)點(diǎn)。入圖5所示便是一個(gè)分布式+對(duì)稱式集群。

　　圖5

　　分布式存儲(chǔ)架構(gòu)得到廣泛應(yīng)用的原因一個(gè)是其擴(kuò)展性，另一個(gè)是其成本，不需要SAN了，普通服務(wù)器掛十幾個(gè)盤，就可以是一個(gè)節(jié)點(diǎn)，幾千上萬個(gè)節(jié)點(diǎn)就可以組成分布式集群?？v觀市場(chǎng)上，大部分產(chǎn)品都使用非對(duì)稱式+分布式架構(gòu)，成本低，開發(fā)簡(jiǎn)單，擴(kuò)展性強(qiáng)。具體產(chǎn)品就不一一列舉了，大家自行都能說出幾個(gè)來。

　　圖6所示則是一個(gè)分布式+非對(duì)稱式集群。

　　圖6

　　分布式系統(tǒng)一個(gè)最重要的地方是一定要實(shí)現(xiàn)數(shù)據(jù)冗余，不但要防止盤損壞導(dǎo)致數(shù)據(jù)丟失，還要防止單個(gè)節(jié)點(diǎn)宕機(jī)導(dǎo)致的數(shù)據(jù)不可訪問。Raid是 空間最劃算的冗余方式，單節(jié)點(diǎn)內(nèi)可以用raid來防止盤損壞導(dǎo)致的數(shù)據(jù)不可用，但是節(jié)點(diǎn)整個(gè)損壞，單機(jī)Raid就搞不定了，就得用跨節(jié)點(diǎn)之間做Raid， 這樣會(huì)耗費(fèi)大量網(wǎng)絡(luò)流量，Erasure Code(EC)就是傳統(tǒng)Raid的升級(jí)版，可以用N份校驗(yàn)來防止N個(gè)節(jié)點(diǎn)同時(shí)損壞導(dǎo)致的數(shù)據(jù)丟失，但是也需要耗費(fèi)大量帶寬。所以常規(guī)的實(shí)現(xiàn)方式是直接使 用Raid1的方式將每份數(shù)據(jù)在其他節(jié)點(diǎn)上鏡像一份或者兩份存放，Raid1對(duì)網(wǎng)絡(luò)帶寬的耗費(fèi)比Raid5或者EC要小得多。

　　哎呦，寫到這，冬瓜哥都有點(diǎn)剎不住了，這篇幅太長(zhǎng)了，現(xiàn)在的人都浮躁，看幾段就不愿意看了，沒關(guān)系，浮躁之人就讓他浮躁吧，冬瓜哥一定要把想說 的說完，而且說清楚，這才是冬瓜哥，冬瓜哥一直都是這樣，這樣的冬瓜哥才是冬瓜哥。看完冬瓜哥文章的，自然也會(huì)受益。看不完的，不進(jìn)則退。

　　【支線】各種集群NAS

　　對(duì)于一個(gè)集群NAS來講，其可以使用分布式+對(duì)稱式(Isilon就是這么做的，GPFS有兩個(gè)版本，其分布式版本也是這種架構(gòu))，也可以使用 分布式+非對(duì)稱式(互聯(lián)網(wǎng)開源領(lǐng)域所有集群FS)，也可以使用共享式+對(duì)稱式(VeritasCFS，Ibrix)，也可以采用共享式+非對(duì)稱式 (BWFS)。但是集群NAS一般都泛指一個(gè)獨(dú)立的商用系統(tǒng)，而商用系統(tǒng)一般都是面向傳統(tǒng)企業(yè)的，擴(kuò)展性要求不是很高，而對(duì)“高雅”的架構(gòu)卻情有獨(dú)鐘，所 以這些傳統(tǒng)集群NAS廠商一般要么使用對(duì)稱式要么使用共享式這些“高雅”的架構(gòu)。

　　【支線】YeeFS架構(gòu)簡(jiǎn)析

　　講了這么多，冬瓜哥認(rèn)為需要結(jié)合實(shí)際的產(chǎn)品來把這些概念和架構(gòu)匹配起來，效果最佳。YeeFS由達(dá)沃時(shí) 代(DaoWoo)公司出品，是一個(gè)典型的分布式非對(duì)稱式集群文件系統(tǒng)+集群SAN(或者說Server SAN)。想到這里，你此時(shí)應(yīng)該在腦海里想到“哦，非對(duì)稱式，那在協(xié)作管理層一定要有元數(shù)據(jù)節(jié)點(diǎn)了。哦，分布式，那在存儲(chǔ)層一定是每個(gè)節(jié)點(diǎn)各管各的磁盤或 者卷了”，“那么前端訪問層呢？”，哎呦，不錯(cuò)，你終于學(xué)會(huì)思考了，而且思路框架已經(jīng)有點(diǎn)逼格了嘿。YeeFS在前端訪問層支持NFS、CIFS以及Linux下的并行訪問客戶端，NFS和CIFS可以從任意節(jié)點(diǎn)Mount，對(duì)于ServerSAN訪問方式，支持iSCSI連接方式。行了，我已經(jīng)了解這款產(chǎn)品了!得了吧你，就這三板斧，逼格還早呢。

　　上面只是使用了我們所建立的框架思維來套用到一款產(chǎn)品上，從大架構(gòu)方面來了解一款產(chǎn)品，類似大框架的產(chǎn)品還有很多，如果它們?nèi)家粋€(gè)模子，那就 不會(huì)有今天的ServerSAN產(chǎn)品大爆炸時(shí)期的存在了?？疾煲豢頢erverSAN產(chǎn)品，從用戶角度看主要看這幾樣：性能、擴(kuò)展性、可用性、可靠性、可 維護(hù)性、功能、成本。從技術(shù)角度除了看大框架之外，還得關(guān)心這幾個(gè)東西：是否支持POSIX以及其他接口，數(shù)據(jù)分塊的分布策略、是否支持緩存以及分布式全 局緩存，對(duì)小文件的優(yōu)化，是否同時(shí)支持FS和塊，數(shù)據(jù)副本機(jī)制，副本是否可寫可讀可緩存。

　　YeeFS支持標(biāo)準(zhǔn)POSIX及S3/VM對(duì)象接口。Posix接口很完善也很復(fù)雜，不適合新興應(yīng)用，比如你上傳一張照片，你是絕對(duì)不會(huì)在線把 這個(gè)照片中的某段字節(jié)更改掉的，POSIX支持seek到某個(gè)基地址，然后寫入某段字節(jié)，而這種需求對(duì)于網(wǎng)盤這種新應(yīng)用完全是累贅，所以催生了更加簡(jiǎn)單的 對(duì)象接口，給我一個(gè)比如hash key，我給你一份完整數(shù)據(jù)，要么全拿走要么刪除，要改沒問題，下載到本地改完了上傳一份新的，原來的刪除。對(duì)分塊的布局方面，YeeFS底層是基于分塊 (又被很多人稱為object，對(duì)象)的，將一堆分塊串起來形成一個(gè)塊設(shè)備，便是集群SAN，將一對(duì)obj串起來形成文件，這就是集群NAS，這些對(duì)象塊 在全局磁盤上平均化分布，以提升IO并發(fā)度。在實(shí)際案例中YeeFS曾經(jīng)支持到3億的小文件存儲(chǔ)同時(shí)還可以保證優(yōu)良的性能，業(yè)界對(duì)小文件存儲(chǔ)的優(yōu)化基本都 是大包然后做第二層搜索結(jié)構(gòu)，相當(dāng)于文件系統(tǒng)中的文件系統(tǒng)，以此來降低搜索時(shí)延。數(shù)據(jù)可用性方面，默認(rèn)2個(gè)副本，可調(diào)。YeeFS支持讀寫緩存，但是不支 持全局的分布式共享緩存，后者實(shí)現(xiàn)起來非常復(fù)雜，也只有由傳統(tǒng)存儲(chǔ)演變過來的高大上型ServerSAN比如VMax這種，通過IB來互聯(lián)，高速度高成 本，才敢這么玩，即便如此，其也只敢使用基于hash的避免查表搜索的緩存分配方式，而二三線廠商恐怕玩不起這個(gè)。YeeFS節(jié)點(diǎn)向元數(shù)據(jù)節(jié)點(diǎn)加鎖某個(gè) obj之后便可以在本地維護(hù)讀寫緩存。YeeFS的副本也是可讀寫的，并且在保持并發(fā)度的前提下還保持完全同步的強(qiáng)一致性。整個(gè)集群可在線添加和刪除節(jié)點(diǎn) 而不影響業(yè)務(wù)。

　　在對(duì)閃存的利用方面，YeeFS采用三個(gè)維度來加速，第一個(gè)是采用傳統(tǒng)的冷熱分層，第二個(gè)維度，采用只讀SSD Cache來滿足那些更加實(shí)時(shí)的熱點(diǎn)數(shù)據(jù)的性能提升，第三個(gè)維度采用非易失NVRAM來作為寫緩存，并將隨機(jī)的IO合并成連續(xù)的大塊IO寫入下層，極大的 優(yōu)化了性能。此外，YeeFS在元數(shù)據(jù)訪問加速方面，采用了元數(shù)據(jù)切分并行無鎖設(shè)計(jì)，多線程并行搜索，提升速度;元數(shù)據(jù)一致性方面，采用主備日志、分組提交方式，既保證性能又保證一致性。

　　其他功能方面，支持去重和壓縮，支持在客戶端緩存文件布局信息，避免頻繁與元數(shù)據(jù)節(jié)點(diǎn)交互信息。節(jié)點(diǎn)宕機(jī)之后的數(shù)據(jù)重構(gòu)采用的是Raid2.0 的方式，將數(shù)據(jù)重構(gòu)到所有磁盤的空閑空間，提升并發(fā)度，降低重構(gòu)時(shí)間。元數(shù)據(jù)節(jié)點(diǎn)支持?jǐn)U展為多元數(shù)據(jù)節(jié)點(diǎn)協(xié)作并行處理元數(shù)據(jù)請(qǐng)求，以保證數(shù)千節(jié)點(diǎn)的超大規(guī) 模集群的性能。

　　YeeFS 客戶端的一些主要配置:元數(shù)據(jù)緩存超 時(shí)時(shí)間設(shè)置，每個(gè)客戶端有緩存元數(shù)據(jù)的能力，超時(shí)時(shí)間從0開始往上不等; 數(shù)據(jù)緩存大小設(shè)置，包括寫緩存和讀緩存的大小設(shè)置; 并發(fā)連接數(shù)設(shè)置，可以控制一個(gè)客戶端在IO上往其它存儲(chǔ)節(jié)點(diǎn)上的最大連接數(shù)目控制; 其它的一些配置命令，例如導(dǎo)出目錄設(shè)置(這個(gè)客戶端只能導(dǎo)出文件系統(tǒng)中的某個(gè)目錄)，客戶端權(quán)限控制(這個(gè)客戶端上是允許讀寫操作還是只讀操作)，IP控 制等。 YeeFS的IO節(jié)點(diǎn)上一些配置比如數(shù)據(jù)校驗(yàn)是否打開，日志大小，IO線程，IO線程與磁盤之間的關(guān)系等。元數(shù)據(jù)節(jié)點(diǎn)上主要配置是一些整體系統(tǒng)配置，文件 或者目錄的副本數(shù)配置，存儲(chǔ)池的配置，負(fù)載均衡、數(shù)據(jù)重構(gòu)等一些整體系統(tǒng)的配置。

　　YeeFS這個(gè)產(chǎn)品映入瓜哥眼簾的一個(gè)原因是其支持的比較完善，包括POSIX接口、既是集群SAN又是集群NAS。第二個(gè)原因，則是其提到的 “應(yīng)用感知”優(yōu)化，這與瓜哥一直在提的“應(yīng)用定義”不謀而合，詳見之前文章《可視化存儲(chǔ)智能解決方案》。其可以在系統(tǒng)底層針對(duì)不同應(yīng)用不同場(chǎng)景進(jìn)行IO層 面的QoS調(diào)節(jié)。另外，現(xiàn)在的所謂“軟件定義”存儲(chǔ)系統(tǒng)，過于強(qiáng)調(diào)硬件無關(guān)性，忽視硬件特性。而YeeFS比較注重硬件的特性，如Flash、RDMA、 NUMA、NVRAM等的優(yōu)化和利用，針對(duì)不同硬件的不同特點(diǎn)，定義不同的場(chǎng)景。

　　YeeFS還有兩個(gè)兄弟，YeeSAN和WooFS。YeeSAN是YeeFS的簡(jiǎn)化版，只提供分布式塊存儲(chǔ)服務(wù)，強(qiáng)調(diào)比YeeFS塊服務(wù)更的高IOPS和低時(shí)延。而YeeFS可以同時(shí)提供文件和塊服務(wù)。WooFS是專門針對(duì)跨數(shù)據(jù)中心實(shí)現(xiàn)的廣域分布式的產(chǎn)品，通過統(tǒng)一的名字空間實(shí)現(xiàn)多個(gè)數(shù)據(jù)中心間的數(shù)據(jù)共享，任何一個(gè)數(shù)據(jù)中心的應(yīng)用可以通過標(biāo)準(zhǔn)Posix接口直接訪問存儲(chǔ)在其他數(shù)據(jù)中心的數(shù)據(jù)，這里就不過多介紹了。

　　好，到此為止，你應(yīng)該能更加深入的了解一款產(chǎn)品了，后續(xù)碰到任何產(chǎn)品，大家都可以用這種思路去切入、審視、分析和判斷，這樣可以防止被忽悠。

　　【主線5】串行訪問/并行訪問

　　對(duì)于一個(gè)分布式架構(gòu)的集群NAS(不管是對(duì)稱式還是非對(duì)稱式)，某個(gè)應(yīng)用主機(jī)從某個(gè)節(jié)點(diǎn)mount了某個(gè)路徑，訪問其中數(shù)據(jù)，如果訪問的數(shù)據(jù)恰 好不存儲(chǔ)在本機(jī)而是遠(yuǎn)端節(jié)點(diǎn)，那么該節(jié)點(diǎn)先從源端節(jié)點(diǎn)把數(shù)據(jù)拿到本地，再發(fā)送給請(qǐng)求數(shù)據(jù)的主機(jī)。為何不能讓應(yīng)用主機(jī)預(yù)先就知道數(shù)據(jù)放在哪，然后自己找對(duì)應(yīng) 的節(jié)點(diǎn)拿數(shù)據(jù)？這樣可以節(jié)省一次IO轉(zhuǎn)發(fā)過程。是的，你能想到的，系統(tǒng)設(shè)計(jì)者也想到了。但是傳統(tǒng)的NFS/CIFS客戶端是無法做到這一點(diǎn)的，必須使用集 群文件系統(tǒng)廠商開發(fā)的特殊客戶端，其先從元數(shù)據(jù)節(jié)點(diǎn)要到文件布局信息，然后直接到集群中的IO節(jié)點(diǎn)讀寫數(shù)據(jù)，這樣的話，應(yīng)用主機(jī)就可以同時(shí)從多個(gè)IO節(jié)點(diǎn) 讀寫數(shù)據(jù)，而不再像之前那樣從哪個(gè)節(jié)點(diǎn)mount的就只能從這個(gè)節(jié)點(diǎn)讀寫數(shù)據(jù)，這就是所謂的并行訪問模式，指的是應(yīng)用主機(jī)訪問這個(gè)集群時(shí)候，是串行從一個(gè) 節(jié)點(diǎn)讀寫數(shù)據(jù)，還是可以并行從多個(gè)節(jié)點(diǎn)同時(shí)讀寫數(shù)據(jù)。幾乎所有的互聯(lián)網(wǎng)開源集群文件系統(tǒng)都支持并行訪問。此外，也可以看到，超市模式再一次在應(yīng)用主機(jī)和集 群之間得到了使用。

　　【主線任務(wù)大結(jié)局】終極大總結(jié)

　　1. 集群文件系統(tǒng)在數(shù)據(jù)訪問層或者說數(shù)據(jù)存儲(chǔ)層可分為共享存儲(chǔ)型和分布存儲(chǔ)型，或者說共享式和分布式，分別稱為共享FS和分布式FS。

　　2. 集群文件系統(tǒng)在協(xié)作管理層可分為對(duì)稱式集群和非對(duì)稱式集群;

　　3. 集群文件系統(tǒng)在協(xié)作管理層針對(duì)元數(shù)據(jù)的管理粒度還可以分為Single Filesystem Image和Single Path Image;

　　4. 分布式集群文件系統(tǒng)在前端訪問層可以分為串行訪問和并行訪問，后者又稱為并行FS。

　　5. 不管什么架構(gòu)，這些FS統(tǒng)稱為“集群文件系統(tǒng)”。多個(gè)層次上的多種架構(gòu)兩兩組合之后，便產(chǎn)生了讓人頭暈眼花的各種集群文件系統(tǒng)。

　　不僅是集群文件系統(tǒng)，集群塊系統(tǒng)也逃不出上面的框架，相比于“集群塊系統(tǒng)”逼格稍微高那么一點(diǎn)點(diǎn)的名詞，就是“Server SAN”，一個(gè)分布式塊存儲(chǔ)系統(tǒng)，再包裝包裝，把應(yīng)用裝它上面，就是所謂HCI了，說實(shí)話冬瓜哥一開始都不知道HCI是個(gè)啥，還是被人邀請(qǐng)加入了一個(gè) HCI的群才知道竟然還有人搞出了這個(gè)詞，哎，世界之大，逼格混雜!