上篇文章《IO時延你被騙了多久》，竟然沒有人給瓜哥發紅包!很不像話!冬瓜哥起早貪黑打把勢賣藝，最終卻連五毛黨都趕不上，所以瓜哥決定這篇文章之后休息一段時間，玩玩游戲，看看電影，睡睡大覺了。
曾幾何時，你可能被“集群FS”“共享FS”“SANFS”“并行FS”“分布式FS”這些名詞弄得頭暈眼花，冬瓜哥一度也是，而且也找很多人去求證，倒頭來每個人的說法都不一樣，于是冬瓜哥開始潛心自己研究總結。究其本質原因是集群系統里有好幾個邏輯層次，而每個層次又有不同的架構，組合起來之后，花樣繁多，而又沒有人愿意用比較精準的名字來描述某個集群系統，取而代之只用了能夠表征其某個層次所使用的架構來表征整個系統，這是產生理解混亂的原因。本文會對現存的集群文件系統框架進行一個清晰的梳理、劃界。即便是大名鼎鼎的維基百科，恐怕也沒有一篇文章徹底的梳理所有這些框架，都是零零散散的混亂定義，讓人看了摸不著頭腦。維基百科中文頻道，冬瓜哥之前增加過一條“集群文件系統”的定義，還有百度百科，大家可以去看看，那個條目寫的非常概要，而本文則展開講述。
【主線1】從雙機共享訪問一個卷說開去
把一個卷/Lun/LogicalDisk/Virtual Disk，管它叫什么的，同時映射給多臺主機，管它用什么協議，IP/FC/IB/SAS，這多臺主機會不會同時認到這個卷？會。每臺主機OS里的驅動觸發libfc/libiscsi/libsas等庫發出scsi report lun這個指令的時候，存儲系統都會將這個卷的基本信息在scsiresponse里反饋回去，包括設備類型、廠商、版本號等，主機再發送scsi inquery lun來探尋更具體的信息，比如是否支持緩存以及是否有電池保護等。接著主機發出scsi read capacity來獲取這個卷的容量，最后主機OS會加載一個通用塊設備驅動，注冊盤符。冬瓜哥說的有點多了，上面這些其實與主題無關，但是冬瓜哥的思路屬于線性再疊加類比和發散思維，必須一步一步串起來，所以不得不多說點。
那么在主機1使用NTFS或者EXT等文件系統格式化這個卷，寫文件，其他主機上是否可以直接看到這個文件？曾幾何時，不少人問冬瓜哥這個問題，瓜哥也測試過不少人對這個問題的看法，喜憂參半。有人天然的認為，如果不能實現這種效果，還玩個屁？持有這種觀點的人就是只浮于表面的那些人而且裝逼過甚。聽到這個問題考慮考慮猶豫地說出”應該可以吧“的那些人，還算能動動腦子不過其知識體系的完整度也真讓人捉急。實際上，有一定幾率其他主機可以看到新寫入的數據，但是大部分時候，其他主機要么看不到，要么錯亂(磁盤狀態出了問題比如未格式化等等)。所以多主機天然可以共享卷，但是天然卻共享不了卷中的文件。咋回事？因為每臺主機上的文件系統從來不會知道有人越過它從后門私自更改了磁盤上的數據，你寫了東西我不知道，我認為這塊地方是未被占用的，我寫了東西把你覆蓋掉了，你也不知道，最后就錯亂了，跑飛了。多主機共同處理同一個卷上的數據，看上去很不錯，能夠增加并發處理性能，前提是卷的IO性能未達到瓶頸，所以這種場景并不只是思維實驗，是切切實實的需求，比如傳統企業業務里最典型的一個應用場景就是電視臺非線編系統，要求多主機共享訪問同一個卷、同一個文件，而且要求高吞吐量。但是，上述問題成為了絆腳石。
咋解決？很顯然兩個辦法，在這方面，人類的思想都是一樣的，逃不開幾種方案，只要你了解問題根源，稍微動點腦子，就不比那些個底層系統設計者想出的辦法差到哪去。
圖1
如圖1下半部分所示，第一種辦法，既然多個FS各干各的又不溝通，那么干脆大伙誰都別管理文件了，找個集中的地方管理文件，大伙想要讀寫創建刪除截斷追加任何文件/目錄，把指令發給這個人，讓它執行，返回結果，這不就可以了么？是啊，這特么不就是所謂NAS么我說。主機端的文件系統沒了？非也。還在，只不過只負責訪問本地非共享的文件數據，對于那些需要被/與其他主機共享的文件，放到另一個目錄里，這個目錄實體存在于NAS上，主機端采用NFS/CIFS客戶端程序將這個實體目錄掛載到本地VFS某個路徑下面，凡是訪問這個路徑的IO請求都被VFS層重定向發送給NFS/CIFS客戶端程序代為封裝為標準NFS/CIFS包發送給NAS處理。這樣，就可以實現多主機同時訪問同一份數據了。
【支線】數據一致性問題的謬誤
在這里冬瓜哥給各位開一個支線任務。很多人有所迷惑，多個主機共享訪問同一個文件，那么就能避免我寫的數據不會覆蓋你寫的么？不能。既然不能，那上面豈不是白說了？倒頭來數據還不是要相互覆蓋，不一致？估計我問出這個問題之后，一大堆人就干瞪眼了，迷糊了。如果不加任何處理，兩個諸如記事本這樣的程序打開同一個文件，同時編輯，最后的確是后保存的覆蓋先保存的。但是此時的不一致，是應用層的不一致，并不是文件系統層的不一致，也就是說并不會因為主機A寫入的數據覆蓋掉了主機B寫入的數據而導致NAS的文件系統不一致從而需要FSCK或者磁盤格式未知等詭異錯誤。那么NAS就放任這種應用層的相互亂覆蓋么？是的，放任之。為何要放任？為何NAS不負責應用層數據一致？那我要問問你，NAS怎么能保證這一點？A寫了個123進去，同時B寫了個456進去，NAS是最終把文件保存成123456呢，還是142536呢？還是145236呢？NAS如何能管得了這個？所以NAS根本就不管應用層的一致。那咋整？鎖啊。應用打開某個文件的時候，先向NAS申請一個鎖，比如要鎖住整個文件或者某段字節，允許他人只讀，還是讀寫都不行，這些都可以申請。如果你用MS Office程序比如Word打開某個NAS上的文件，另一臺主機再打開一次，就會收到提示只能打開只讀副本，就是因為有其他主機對這個文件加了寫鎖。此時便可保證應用層一致了，而記事本這種程序是根本不加鎖的，因為它就不是為了這種企業級協作而設計的，所以誰都能打開和編輯。所以，應用層不一致，與底層不一致根本就是兩回事。
【主線2】標準店銷模式和超市模式
NAS是成功解決了多主機共享訪問存儲的問題，但是自身卻帶來了新問題，第一，走TCPIP協議棧到以太網再到千兆萬兆交換機，這條路的開銷太大，每一個以太網幀都要經過主機CPU運行TCPIP協議棧進行錯誤檢測丟包重傳等，這期間除了CPU要接受大量中斷和計算處理之外，還需要多次內存拷貝，而普通Intel CPU平臺下是不帶DMA Engine的，只有Jasper Forest這種平臺才會有，但是即便有，對于一些小碎包的內存拷貝用DMAEngine也無法提升太多性能，主機CPU耗費巨大;第二，系統IO路徑較長，主機先要把IO請求發給NAS，NAS翻譯成塊IO，再發送給磁盤，IO轉了一手，增加了時延;第三，NAS本身是個集中式的存儲設備，如果NAS設備出現IO或者CPU瓶頸，前端主機數量再多也沒用。
這就是店銷模式的尷尬之處。你想買什么東西，你不能碰，你得讓店員給你拿，如果店員數量有限，顧客多，那就只能排隊，或者烏泱泱一幫人你一句我一句與店員交流，這顯然出現了瓶頸。后來，對于量大的店，改為了超市模式，顧客先看看貨物的分布圖，然后自己去對應貨架拿貨物結賬，極大地提升了性能。存儲也可以這么干。
圖2
如圖2所示，如果找一臺獨立的節點，專門來管理FS元數據，比如塊映射信息、bitmap、權限等等，而讓原來的兩個節點直接認到卷。什么!？你不是說多個主機認到同一個卷，數據會被損毀么？這是沒把東西串起來，沒動腦子想。冬瓜哥是說過，但是前提是兩主機上的FS各管各的?，F在我不讓它各管各的，還是把FS拿出來，但是拿到旁邊去，平時別擋路，讓原來的節點直接訪問盤，但是節點訪問盤之前，必須經過第三個節點也就是圖中的FS節點的授權和同意，這樣的話就不會不一致，而且還能獲得更高的速度，因為此時可以使用比如FC/SAS/IB等對CPU耗費少(協議傳輸層直接在卡里硬件完成)的鏈路類型，另外IO直接從節點下來到卷，不用轉手。此時的IO流程是：節點上使用一種特殊的客戶端(并非傳統NFS/CIFS客戶端)，任何對文件的操作都通過Eth交換機向FS節點查詢，比如一開始的ls，后續的open/read/write等，FS會將對應文件的信息(權限、屬性、對應的卷塊地址等)返回給節點，節點獲取這些信息，便直接從卷上讀寫數據，所有的元數據請求包括鎖等，全部經由Eth網與FS節點交互。這便是存儲里的超市模式。
專業術語，店銷模式稱為帶內模式或者共路模式，超市模式則為帶外模式或者旁路控制模式或者隨路模式。而圖2中所示的方式，則就是所謂帶外NAS系統?；蛘哂腥似鹆藗€更忽悠人的名字：“共享文件系統”/“共享式文件系統”，或者SanFS，也就是多主機通過SAN網絡共享訪問同一個卷，而又能保證文件底層數據一致性。上述的這種共享文件系統無非包含兩個安裝組件，元數據節點安裝Master管理軟件包，IO節點安裝客戶端軟件包，經過一番設置，系統運行，所有IO節點均看到同樣的目錄，目錄里有同樣的同一份數據，因為它們都是從元數據節點請求文件目錄列表以及數據的，看到的當然是一樣的了。如圖所示，NFS/CIFS客戶端是不支持這種方式的，需要開發新的客戶端，這個客戶端在與FS節點通信時依然可以使用類似NFS的協議，但是需要增加一部分NFS協議中未包含的內容，就是將文件對應的塊信息也傳遞給客戶端，需要做一下開發，其他的都可以沿用NFS協議，此外，這個特殊客戶端在IO路徑后端還必須增加一個可直接調用塊IO接口的模塊，NFS客戶端是沒有實現這個的。
【主線3】對稱式協作與非對稱式協作
咱們再說回來，除了使用帶內NAS或者帶外NAS方式之外，還有另一種辦法解決多節點共享處理同一份數據，而且相比NAS顯得更加高大上和學院派。如圖1上半部分所示，既然大伙各管各的又不溝通，那我讓你們之間溝通一下不就可以一致了么？沒錯，在各自的FS之上，架設一個模塊，這個模塊專門負責溝通，每個人做的改變，均同步推送給所有人，當然，要改變某個數據之前，必須先加鎖占坑，否則別人也有可能同時在試圖改變這個數據。加鎖的方式和模式有很多種，這個瓜哥會在后續文章中介紹。很早期，Win平臺有個名為Sanergy的產品，其角色就是構架在NTFS之上的一個溝通同步、加鎖、文件位置管理和映射模塊，但是很難用，性能也很差，這個產品后來被IBM收購以后就沒下文了，其原因是該產品與NTFS松耦合，對NTFS沒有任何改動，只是在上面做了一些映射定向，開銷非常大，是一個初期在廣電領域非線編系統對于多機共享卷的強烈需求下出現的產品。再比如Ibrix(HP x9000 NAS的底層支撐集群文件系統)則是架構在EXT3 FS之上的集群管理模塊，其對EXT3文件系統也沒有修改。
這種模式的集群文件系統，稱為“對稱式集群文件系統”，意即集群內所有節點的角色都是均等對稱的，對稱式協作，大家共同維護同一份時刻一致的文件系統元數據，互鎖頻繁，通信量大，因為一個節點做了某種變更，一定要同時告訴集群內所有其他節點。相比之下，上文中所述的那種超市模式的帶外NAS文件系統，則屬于“非對稱式集群文件系統”，有一個集中的獨裁節點，非對稱式協作，或者說沒有“協作”了，只有“獨裁”。
顯而易見，對稱式協作集群有個天生的劣勢，就是看上去好看，人們都喜歡對稱，但是用起來就不那么舒坦了，兩個原因，第一個是其擴展性差，節點數量不能太多，否則通信量達到瓶頸，比如32個節點的話，每個節點可能同時在與其他31個節點通信，此時系統連接總數近似為32×32，如果一千個節點，則連接總數為999×999，節點性能奇差。其次，安全性方面，對稱式協作，多個節點間耦合性非常緊，一旦某個節點出現問題，比如卡殼，那么向其加鎖就會遲遲得不到應答，影響整個集群的性能，一人出事全家遭殃，再就是一旦某個節點發飆把文件系統元數據破壞了，也一樣是全家遭殃，重則整個系統宕機FS再也掛不起來，輕則丟數據或不一致。所以，也只有少數幾家技術功底深厚的追求完美的公司做出了類似產品，典型代表就是Veritas的CFS，類似的產品還有Ibrix。還有一些對稱式協作集群產品，其內部并非是純粹的對稱式協作，而是按照某種規則劃分了細粒度的owner，比如目錄A的owner是節點A，目錄B的owner是節點B，所有的IO均需要轉發給owner然后由owner負責寫盤，這樣不需要加鎖，降低通信量;或者將鎖的管理分隔開，比如目錄A的鎖管理節點職責賦給節點A，這樣大家訪問目錄A就都向A節點加鎖，而不用所有人都發出鎖請求，GPFS對稱式協作FS就是這種做法。但是這些加了某種妥協的架構也就不那么純粹了，但的確比較實際。這些不怎么純粹的協作管理，可以被歸為“Single Path Image”，也就是其協作方式是按照路徑劃分各個子管理節點的，甚至每個節點可能都掌管一個獨立的文件系統，然后由協作層將其按照路徑虛擬成一個總路徑，Windows系統之前內置有個DFS就是這么干的;而純粹的對稱協作，可以被歸為“Single Filesystem Image”，意即整個集群只有一個單一文件系統，所有人都可以管理任何元數據，完全純對稱。當然，SPI和SFI這兩個估計逼格高甚，可能不少人已經難以理解了，所以冬瓜哥也就不再繼續費手指頭打字了。
即便如此，對稱式協作集群的節點數量也不能增加到太多。而非對稱式集群，由于耦合度很低，只是多對1耦合(每個IO節點對元數據節點之間耦合)，通信量大為降低，目前最大的非對稱式協作集群FS可達單集群13K臺，基于HDFS。
說到這里，冬瓜哥要做個總結了。
圖3
如圖3和圖4所示，冬瓜哥把集群文件系統架構分割為三層，最底層為數據訪問層或者說存儲層，在這一層，上述的架構都使用了共享式架構，也就是多節點共享訪問同一個或者同多個卷。再往上一層，冬瓜哥稱之為協作管理層，這一層有對稱式協作和非對稱式協作兩種方式，分別對應了多種產品，上文中也介紹了。最頂層，就是數據訪問層，其實這一層可有可無，如果沒有，那么需要把應用程序直接裝在IO節點上，應程序直接對路徑比如/clusterfs/cluster.txt進行代碼級調用即可比如read()。
圖4
而如果將某個節點上的這個路徑，使用NFS/CIFS server端export出去，再找一臺server用NFS/CIFS客戶端mount上來讀寫的話，那么這個集群系統就成了一臺集群NAS了，從任何一個節點上都可以mount，這樣就增加了并發度，增加了性能，當然，前提是底層的卷提供者未達到瓶頸。把應用和IO節點裝在同一臺server上，有些低逼格的說法叫做“HCI”，所謂超融合系統。冬瓜哥之前是一名純粹的產品經理，也善于包裝忽悠，有興趣者可以看本公眾號(大話存儲)之前文章：《可視化存儲智能—思路、技術和展現》。
往事不可追如冷風吹。好了，大家可以看到一個集群文件系統的三層框架架構，其中在協作管理層，有兩種架構，第一種是對稱式協作，第二種是非對稱式協作。好了，其實上面這句話就是前文啰嗦一大堆的精髓所在。而我們現有的多數教材，是反過來說，它先特么給你總結和抽象，把你搞暈，然后可有可無懶懶散散的舉幾個不明不白的例子。冬瓜哥對此深惡痛絕，去特么的!耽誤了多少莘莘學子的寶貴人生!這也是冬瓜哥急切想進入教師體制的原因，因為看到別人說不清楚某個東西，瓜哥心里捉急啊。
【支線】RAC、SMP和AMP
咋樣？做完剛才那個主線任務，是不是有種蕩氣回腸的感覺呢？休息一下，來做個支線吧。Oracle RAC屬于對稱式協作+共享存儲型集群。而早期的CPU和RAM之間的關系，也是對稱式協作+共享存儲型集群，如果把CPU看做節點，RAM看做存儲的話，多CPU通過FSB共享總線通過北橋上的DDR控制器訪問下掛的集中的RAM。多個線程可以隨意在多CPU上任意調度，哪個CPU/核心執行都可以，這不是對稱是什么？而且針對緩存的更新會有一致性廣播探尋發出，這不是協作是什么？多CPU看到同樣的RAM地址空間，同樣的數據，這不是共享存儲是什么？這種CPU和RAM之間的關系又被稱為SMP，對稱對處理器。與對稱式協作面臨的尷尬相同，系統廣播量太大，耦合太緊，所以后來有了一種新的體系結構成為AMP，非對稱對處理器。典型的比如Cell B.E處理器，被用于PS3游戲機中，其中特定的內核運行OS，這個OS向其他協處理內核派發線程/任務，運行OS的內核與這些協處理核之間是松耦合關系，雖然也共享訪問集中的內存，但是這塊內存主要用于數據存儲，而不是代碼存儲，這種處理器在邏輯架構上可以擴充到非常多的核心。具體冬瓜哥不再多描述，后續看機會可能會在其他文章中詳細介紹Cell B.E處理器。
但是好景不長。十年前，共享存儲型的SMP處理器體系結構，被全面替換為NUMA架構。起因是因為集中放布的內存產生了瓶頸，CPU速度越來越快，數量越來越多，而內存控制器數量太少，且隨著CPU節點數量增加滯后，訪問路徑變得太長，所以，每個CPU自己帶DDR控制器，直接掛幾根內存條，多個CPU在互聯到一起，形成一個分布式的RAM體系，平時盡量讓每個CPU訪問自己的RAM，當然必要時也可以直接訪問別人的RAM。在這里冬瓜哥不想深入介紹NUMA體系結構，同樣的事情其實也發生在存儲系統架構里。
中間插入一個問卷調查，投票完請繼續閱讀余下部分。冬瓜哥的逼格你覺是否需要再提高？
【主線4】分布式存儲集群——不得已而為之
錢、性能 for 互聯網企業;可靠性、錢、性能for傳統企業。人們無非就是受這幾個主要因素的驅動?；ヂ摼W企業動輒幾千個節點的集群，讓這幾千個節點共享卷，是不現實的，首先不可能用FC這種高成本方案，幾千端口的FC交換機網絡，互聯網就算有錢也不會買些這個回來。就用以太網!那只能用iSCSI來共享卷，可以，但是性能奇差。其次，互聯網不會花錢買個SAN回來給幾千臺機器用，一個是沒錢(是假的)，第二個是沒有哪個SAN產品可以承載互聯網幾千個節點的IO壓力的，雖然這些廠商號稱最大支持64K臺主機，我估計它們自己都沒有實測過，只是內存數據結構做成可容納64K條而已。
那怎么解決幾千個節點的集群性能問題？首先一定要用非對稱式協作方式，是的，互聯網里從來沒有人用過對稱式集群，因為擴展性太差。針對存儲瓶頸問題，則不得不由共享式，轉為分布式。所謂分布式，也就是每個節點各自掛各自的存儲，每個節點只能直接訪問自己掛的磁盤卷，而不能直接訪問他人的磁盤，這與NUMA訪問內存是有本質不同的，NUMA里任意CPU可以直接在不告訴其他人的前提下直接訪問其他人的RAM。為什么分布式就可以提升IO性能？這其實是基于一個前提：每個節點盡量只訪問自己所掛接硬盤里的數據，避免訪問別人的，一旦發生跨節點數據訪問，就意味著走前端以太網絡，就意味著低性能。NUMA就是這么干的，OS在為進程分配物理地址時，盡量分配在該進程所運行在的那個CPU本地的RAM地址上。
互聯網里的Hadoop集群使用的Mapreduce就可以保證每個節點上的任務盡量只訪問自己硬盤里的數據，因為這種大數據處理場景非常特殊，所以能從應用層做到這種優化。而如果你把一個Oracle RAC部署在一個分布式集群里，RAC是基于共享存儲模式設計的，它并不知道哪個數據在本地哪個在遠端，所以難以避免跨節點流量，所以效率會很低。但是我們的Server SAN同志雖然使用了分布式存儲架構，但是卻成功的使用高性能前端網絡比如萬兆甚至IB以及高性能的后端存儲介質比如PCIE閃存卡規避了超級低的相對效率，而把絕對性能提上去了，其實考察其對SSD性能的發揮比例，恐怕連50%都不到。
值得一提的是，在分布式集群中，雖然數據不是集中存放的，但是每個節點都可以看到并且可以訪問所有數據內容，如果數據不存在自己這，那么就通過前端網絡發送請求到數據所存儲在的那個節點把數據讀過來，寫也是一樣，寫到對應的遠端數據節點。入圖5所示便是一個分布式+對稱式集群。
圖5
分布式存儲架構得到廣泛應用的原因一個是其擴展性，另一個是其成本，不需要SAN了，普通服務器掛十幾個盤，就可以是一個節點，幾千上萬個節點就可以組成分布式集群?？v觀市場上，大部分產品都使用非對稱式+分布式架構，成本低，開發簡單，擴展性強。具體產品就不一一列舉了，大家自行都能說出幾個來。
圖6所示則是一個分布式+非對稱式集群。
圖6
分布式系統一個最重要的地方是一定要實現數據冗余，不但要防止盤損壞導致數據丟失，還要防止單個節點宕機導致的數據不可訪問。Raid是空間最劃算的冗余方式，單節點內可以用raid來防止盤損壞導致的數據不可用，但是節點整個損壞，單機Raid就搞不定了，就得用跨節點之間做Raid，這樣會耗費大量網絡流量，Erasure Code(EC)就是傳統Raid的升級版，可以用N份校驗來防止N個節點同時損壞導致的數據丟失，但是也需要耗費大量帶寬。所以常規的實現方式是直接使用Raid1的方式將每份數據在其他節點上鏡像一份或者兩份存放，Raid1對網絡帶寬的耗費比Raid5或者EC要小得多。
哎呦，寫到這，冬瓜哥都有點剎不住了，這篇幅太長了，現在的人都浮躁，看幾段就不愿意看了，沒關系，浮躁之人就讓他浮躁吧，冬瓜哥一定要把想說的說完，而且說清楚，這才是冬瓜哥，冬瓜哥一直都是這樣，這樣的冬瓜哥才是冬瓜哥?？赐甓细缥恼碌?，自然也會受益?？床煌甑?，不進則退。
【支線】各種集群NAS
對于一個集群NAS來講，其可以使用分布式+對稱式(Isilon就是這么做的，GPFS有兩個版本，其分布式版本也是這種架構)，也可以使用分布式+非對稱式(互聯網開源領域所有集群FS)，也可以使用共享式+對稱式(VeritasCFS，Ibrix)，也可以采用共享式+非對稱式(BWFS)。但是集群NAS一般都泛指一個獨立的商用系統，而商用系統一般都是面向傳統企業的，擴展性要求不是很高，而對“高雅”的架構卻情有獨鐘，所以這些傳統集群NAS廠商一般要么使用對稱式要么使用共享式這些“高雅”的架構。
【支線】YeeFS架構簡析
講了這么多，冬瓜哥認為需要結合實際的產品來把這些概念和架構匹配起來，效果最佳。YeeFS由達沃時代(DaoWoo)公司出品，是一個典型的分布式非對稱式集群文件系統+集群SAN(或者說Server SAN)。想到這里，你此時應該在腦海里想到“哦，非對稱式，那在協作管理層一定要有元數據節點了。哦，分布式，那在存儲層一定是每個節點各管各的磁盤或者卷了”，“那么前端訪問層呢？”，哎呦，不錯，你終于學會思考了，而且思路框架已經有點逼格了嘿。YeeFS在前端訪問層支持NFS、CIFS以及Linux下的并行訪問客戶端，NFS和CIFS可以從任意節點Mount，對于ServerSAN訪問方式，支持iSCSI連接方式。行了，我已經了解這款產品了!得了吧你，就這三板斧，逼格還早呢。
上面只是使用了我們所建立的框架思維來套用到一款產品上，從大架構方面來了解一款產品，類似大框架的產品還有很多，如果它們全都一個模子，那就不會有今天的ServerSAN產品大爆炸時期的存在了?？疾煲豢頢erverSAN產品，從用戶角度看主要看這幾樣：性能、擴展性、可用性、可靠性、可維護性、功能、成本。從技術角度除了看大框架之外，還得關心這幾個東西：是否支持POSIX以及其他接口，數據分塊的分布策略、是否支持緩存以及分布式全局緩存，對小文件的優化，是否同時支持FS和塊，數據副本機制，副本是否可寫可讀可緩存。
YeeFS支持標準POSIX及S3/VM對象接口。Posix接口很完善也很復雜，不適合新興應用，比如你上傳一張照片，你是絕對不會在線把這個照片中的某段字節更改掉的，POSIX支持seek到某個基地址，然后寫入某段字節，而這種需求對于網盤這種新應用完全是累贅，所以催生了更加簡單的對象接口，給我一個比如hash key，我給你一份完整數據，要么全拿走要么刪除，要改沒問題，下載到本地改完了上傳一份新的，原來的刪除。對分塊的布局方面，YeeFS底層是基于分塊(又被很多人稱為object，對象)的，將一堆分塊串起來形成一個塊設備，便是集群SAN，將一對obj串起來形成文件，這就是集群NAS，這些對象塊在全局磁盤上平均化分布，以提升IO并發度。在實際案例中YeeFS曾經支持到3億的小文件存儲同時還可以保證優良的性能，業界對小文件存儲的優化基本都是大包然后做第二層搜索結構，相當于文件系統中的文件系統，以此來降低搜索時延。數據可用性方面，默認2個副本，可調。YeeFS支持讀寫緩存，但是不支持全局的分布式共享緩存，后者實現起來非常復雜，也只有由傳統存儲演變過來的高大上型ServerSAN比如VMax這種，通過IB來互聯，高速度高成本，才敢這么玩，即便如此，其也只敢使用基于hash的避免查表搜索的緩存分配方式，而二三線廠商恐怕玩不起這個。YeeFS節點向元數據節點加鎖某個obj之后便可以在本地維護讀寫緩存。YeeFS的副本也是可讀寫的，并且在保持并發度的前提下還保持完全同步的強一致性。整個集群可在線添加和刪除節點而不影響業務。
在對閃存的利用方面，YeeFS采用三個維度來加速，第一個是采用傳統的冷熱分層，第二個維度，采用只讀SSD Cache來滿足那些更加實時的熱點數據的性能提升，第三個維度采用非易失NVRAM來作為寫緩存，并將隨機的IO合并成連續的大塊IO寫入下層，極大的優化了性能。此外，YeeFS在元數據訪問加速方面，采用了元數據切分并行無鎖設計，多線程并行搜索，提升速度;元數據一致性方面，采用主備日志、分組提交方式，既保證性能又保證一致性。
其他功能方面，支持去重和壓縮，支持在客戶端緩存文件布局信息，避免頻繁與元數據節點交互信息。節點宕機之后的數據重構采用的是Raid2.0的方式，將數據重構到所有磁盤的空閑空間，提升并發度，降低重構時間。元數據節點支持擴展為多元數據節點協作并行處理元數據請求，以保證數千節點的超大規模集群的性能。
YeeFS 客戶端的一些主要配置:元數據緩存超時時間設置，每個客戶端有緩存元數據的能力，超時時間從0開始往上不等; 數據緩存大小設置，包括寫緩存和讀緩存的大小設置; 并發連接數設置，可以控制一個客戶端在IO上往其它存儲節點上的最大連接數目控制; 其它的一些配置命令，例如導出目錄設置(這個客戶端只能導出文件系統中的某個目錄)，客戶端權限控制(這個客戶端上是允許讀寫操作還是只讀操作)，IP控制等。 YeeFS的IO節點上一些配置比如數據校驗是否打開，日志大小，IO線程，IO線程與磁盤之間的關系等。元數據節點上主要配置是一些整體系統配置，文件或者目錄的副本數配置，存儲池的配置，負載均衡、數據重構等一些整體系統的配置。
YeeFS這個產品映入瓜哥眼簾的一個原因是其支持的比較完善，包括POSIX接口、既是集群SAN又是集群NAS。第二個原因，則是其提到的“應用感知”優化，這與瓜哥一直在提的“應用定義”不謀而合，詳見之前文章《可視化存儲智能解決方案》。其可以在系統底層針對不同應用不同場景進行IO層面的QoS調節。另外，現在的所謂“軟件定義”存儲系統，過于強調硬件無關性，忽視硬件特性。而YeeFS比較注重硬件的特性，如Flash、RDMA、NUMA、NVRAM等的優化和利用，針對不同硬件的不同特點，定義不同的場景。
YeeFS還有兩個兄弟，YeeSAN和WooFS。YeeSAN是YeeFS的簡化版，只提供分布式塊存儲服務，強調比YeeFS塊服務更的高IOPS和低時延。而YeeFS可以同時提供文件和塊服務。WooFS是專門針對跨數據中心實現的廣域分布式的產品，通過統一的名字空間實現多個數據中心間的數據共享，任何一個數據中心的應用可以通過標準Posix接口直接訪問存儲在其他數據中心的數據，這里就不過多介紹了。
好，到此為止，你應該能更加深入的了解一款產品了，后續碰到任何產品，大家都可以用這種思路去切入、審視、分析和判斷，這樣可以防止被忽悠。
【主線5】串行訪問/并行訪問
對于一個分布式架構的集群NAS(不管是對稱式還是非對稱式)，某個應用主機從某個節點mount了某個路徑，訪問其中數據，如果訪問的數據恰好不存儲在本機而是遠端節點，那么該節點先從源端節點把數據拿到本地，再發送給請求數據的主機。為何不能讓應用主機預先就知道數據放在哪，然后自己找對應的節點拿數據？這樣可以節省一次IO轉發過程。是的，你能想到的，系統設計者也想到了。但是傳統的NFS/CIFS客戶端是無法做到這一點的，必須使用集群文件系統廠商開發的特殊客戶端，其先從元數據節點要到文件布局信息，然后直接到集群中的IO節點讀寫數據，這樣的話，應用主機就可以同時從多個IO節點讀寫數據，而不再像之前那樣從哪個節點mount的就只能從這個節點讀寫數據，這就是所謂的并行訪問模式，指的是應用主機訪問這個集群時候，是串行從一個節點讀寫數據，還是可以并行從多個節點同時讀寫數據。幾乎所有的互聯網開源集群文件系統都支持并行訪問。此外，也可以看到，超市模式再一次在應用主機和集群之間得到了使用。
【主線任務大結局】終極大總結
1. 集群文件系統在數據訪問層或者說數據存儲層可分為共享存儲型和分布存儲型，或者說共享式和分布式，分別稱為共享FS和分布式FS。
2. 集群文件系統在協作管理層可分為對稱式集群和非對稱式集群;
3. 集群文件系統在協作管理層針對元數據的管理粒度還可以分為Single Filesystem Image和Single Path Image;
4. 分布式集群文件系統在前端訪問層可以分為串行訪問和并行訪問，后者又稱為并行FS。
5. 不管什么架構，這些FS統稱為“集群文件系統”。多個層次上的多種架構兩兩組合之后，便產生了讓人頭暈眼花的各種集群文件系統。
不僅是集群文件系統，集群塊系統也逃不出上面的框架，相比于“集群塊系統”逼格稍微高那么一點點的名詞，就是“Server SAN”，一個分布式塊存儲系統，再包裝包裝，把應用裝它上面，就是所謂HCI了，說實話冬瓜哥一開始都不知道HCI是個啥，還是被人邀請加入了一個HCI的群才知道竟然還有人搞出了這個詞，哎，世界之大，逼格混雜!
來自“大話存儲”公眾號
