【大話存儲II】學習筆記（15章），文件級集群系統
【大話存儲II】學習筆記（15章），塊級集群存儲系統裏面分析的主要是塊集群系統，同樣文件級存儲也可以集群化。
因為NAS系統的前端網絡是以太網，速度比較低，導致NAS主要用於一些非關鍵業務中，比如文件共享。但是一些特殊應用也需要多主機同時訪問某個大文件，比如3D渲染集群等。如果我們使用塊集群存儲系統，則會存在一個問題，需要在應用程序上引入文件鎖，而NAS的文件系統一般都自帶有文件鎖機制，所以還不如把NAS存儲系統進行集群化。
在談怎麽樣把NAS系統進行集群化之前，我們說說集群文件系統的架構。集群文件系統是個很寬泛的概念，分布式文件系統、並行文件系統、共享文件系統統都可以稱為集群文件系統。
集群文件系統
集群文件系統，顧名思義，就是把提供文件存儲的設備進行集群化。一般來說，我們可以使用一堆服務器來提供文件服務。
本章中，我們首先對集群文件系統架構進行分類，主要有如下幾種
共享與非共享存儲型集群
對稱與非對稱集群
自助型與服務型集群
SPI與SFI型集群
串行與並行集群
是否共享LUN
我們可以按照集群是否有共享LUN將架構分為共享存儲集群和非共享存儲集群
共享存儲集群
集群的所有節點都是共享使用後端存儲的，註意這裏的共享不是說共享磁盤陣列，而是說可以共享訪問同一個LUN。
這就引出另一個問題了，多主機同時讀寫同一個LUN裏面的文件，如何保證數據一致性？無法保證數據一致性的原因在於存在多個獨立的文件系統邏輯，每個客戶端都要維護自己的文件系統緩存，而且它們之間不互相通信。
我們可以直接把多余的文件系統實例去除掉，只保留一份文件系統邏輯，這就形成了共享式SAN文件系統了。
下圖為傳統的架構。多個主機共同訪問一個LUN的文件，會產生數據不一致。因為主機各自為政，任意一臺客戶端要訪問目標文件的時候，會向自身內存中的文件系統發起請求，從而執行IO。
下圖是進化後的架構，只需要有一個客戶端主機上保留一份文件系統，也就是元數據服務器。所以客戶端要訪問文件的時候，需要先通過網絡向元數據服務器發出請求，然後自行向目標發起訪問。
非共享存儲集群
與共享存儲集群相反則是非共享存儲集群，每個節點都獨占一個LUN。當然集群也可以使用同一臺磁盤陣列，但是各自的存儲空間是之前劃分好的，只能自己訪問，別人不能訪問。
同樣我們也可以單獨剝離出元數據服務器，然後把後端主機並行化。
這樣的好處在於，客戶端從存儲節點讀取數據的時候，完全可以並行訪問。可以大大提升訪問效率。
共享與非共享存儲集群對比如下：
讀寫數據的過程：當某節點需要訪問其他節點上的數據的時候，
共享存儲集群：每個節點可以直接對後端存儲中的LUN進行讀寫，前端傳輸的只有元數據，而沒有實際數據流量。
非共享存儲的集群文件系統：如果要訪問非當前節點的數據，需要通過前端網絡進行傳輸，速度較慢。
緩存一致性：共享存儲需要考慮緩存一致性，一般來說需要把寫緩存給關了，非共享式不需要考慮。
某節點故障以後：共享存儲，一個節點故障，另外的節點可以直接接管。非共享存儲，為了防止單點故障，需要將每個節點的數據鏡像一份到其他節點。
是否需要使用SAN陣列：共享存儲必須使用SAN陣列，非共享式集群可以不使用SAN陣列，服務器節點的本地槽位多的話，可以使用本地磁盤，但是不可使用DAS磁盤箱。
非共享存儲型文件系統又可稱為“分布式文件系統”，即數據分布存放在集群中多個節點上。
是否引入IO節點
上一小節中講的架構中，客戶端可以直接訪問到共享存儲。
實際上可以在插入一個中間層，可以對後端文件以另一種形式進行輸出。
比如
比如在LUN上層引入了對象存儲網關，則就是對象存儲。
需要客戶端需要使用支持OSD協議的代理，比如pNFS
如果引入了私有設備，則需要使用相應的代理。
如果引入了NAS頭，則形成了集群NAS，對外只需要使用標準的NFS客戶端即可。
典型代表是：Panasas , Lustre , Ibrix
終上所述，集群文件系統最後演化成了兩種：
客戶端直接訪問後端SAN
客戶端和後端FC SAN 之間引入IO節點的模式
這兩種方式各有其優劣
客戶端直接訪問SAN的模式，客戶端與後端的磁盤陣列沒有其他的處理模塊，IO效率最高。
但是成本隨著客戶端的增加而增加，因為目前FC HBA卡非常貴，如果每個客戶端安裝FC HBA卡，成本將非常高。此外，因為後端LUN都由元數據服務器來掛載，存在單點故障，一旦元數據服務器出問題了，則系統就癱瘓
客戶端與SAN之間引入了IO節點的模式：
客戶端可以使用便宜一點的
以太網來進行IO節點的訪問，另一方面如Ibrix這樣所有節點的角色對等的架構，每個節點都是MDS和IO節點，這樣的話，一旦某個IO節點故障，則其他任何一個IO節點就可以接管故障節點的資源，容錯率高了很多。當然有利必有弊，IO效率相對就比較低了，而且受以太網速率的限制，客戶端IO速度也不高。
角色是否對等
可以根據每個節點的角色是否對等分為對稱式和非對稱式文件系統。
所謂對稱式集群文件系統指的是集群中所有節點的角色和任務都相同，完全等價。
在對稱式集群中，所有節點都很聰明，每時每刻都能保持精確溝通與合作，共同掌管全局文件系統的元數據。每個節點要更新某元數據的時候，需要先將其鎖住，其他節點就必須等待，這樣節點之間的溝通量就很大。
所有節點在同一時刻均看到同一片景像。
那麽非對稱式集群呢？
在非對稱集群中，只有少數節點（主備節點）是聰明的，他們掌管著系統內全局文件系統信息，其他節點不清楚。
當其他節點要訪問某文件的時候，需要首先聯系這個聰明節點，得到要訪問文件的具體信息（比如存放在哪個節點中的哪的LUN的什麽地址裏面。）
每個傻節點上需要安裝一個代理客戶端來於聰明節點通信，它獲得了文件的具體信息之後，才能讓主機從後端的LUN中拉取數據。
我們把聰明的節點叫Metadata Server, MDS或者MDC，是系統中唯一掌握文件系統元數據的角色。
那麽對稱集群文件系統與非對稱的典型代表是哪些？
對稱式集群：Veritas ClusterFS , HP Ibrix
非對稱式集群：中科藍鯨BWFS，EMC MPFS
顯然這兩種架構各有優劣勢。
非對稱式集群易於實現，溝通成本低，對應的產品也多。
客戶端只能通過元數據服務器進行掛載，所以性能受限於元數據服務器，不過我們可以引入多個元數據節點來均攤負載。
對稱式集群文件系統：因為所有節點的地位相同，所以掛載任何一個節點的目錄即可，但是節點之間構成的復雜度高，不利於擴展。
當節點少的時候，由於對稱式集群中每個節點都可以充當元數據服務器的角色，所以性能更好。
是否對外提供服務
按照是否對外提供服務分為自助型和服務型
什麽叫自助型集群？就是應用是使用本地磁盤的，比如一個集群中每個節點都安裝了某種應用，然後現在有共享系統內所有文件的需求，就可以在應用節點上直接部署集群文件系統。
所以每個節點不但是數據的生產者，還是底層文件的消費者,這就是自助型
那什麽是服務型集群文件系統，如下圖。
框內是集群文件系統，框外又增加了一排主機，群外的客戶端主機通過某種協議來訪問集群中文件數據。
集群中的服務節點不是數據的消費者，只是服務者
為什麽要使用服務型集群呢？自助型不是挺好的嗎？主要原因如下
降低成本。自助型集群中每個節點都需要高速網卡，比如FC HBA卡，集群規模擴大，則成本也會擴大。
可以接入更多的客戶端
可以用較少的節點服務於更多的客戶端主機。而且內部溝通信息量更小。
統一路徑型與統一文件系統型集群
之前我們講過，為了實現集群的Single Name Space統一命名空間，有兩種方式
- 懶人做法：既然每個節點都有各自的文件系統，那麽就直接把輸出路徑虛擬化一下，集中管理起來就OK。再向外輸出一個Single Path Image。只管路徑統一，放在那裏不管。典型代表就是微軟的DFS
- 勤快人做法：讓每個節點都知道所有文件的位置，在文件系統層進行整合而不只是在表層路徑上進行整合，即Single FileSystem Image。典型代表，CFS等大多數集群FS。
SFI的優點在於可以將一個文件切分到各個節點中，這是SPI無法做到。
但是SFI的擴展性能往往比較有限，SPI則可以整合大量的節點。這是因為SFI的集群FS的節點之間需要同步復雜的狀態，每個節點所維護的狀態機非常復雜，當節點數量增加的時候，節點狀態機的協同加上網絡延遲，性能自然上不去。
而SPI模式下，節點相互獨立，同步的信息很少。。
串行與並行集群
對於服務型集群，可以提供兩種方式的對外訪問：
串行的方式：掛載集群中的某個節點的目錄，然後所有的通信都通過這個節點執行。
並行訪問：
客戶端最開始會掛載在某個節點上，但是只是通過這個節點獲取元數據信息，客戶端可以並行的訪問從多個節點中讀寫數據。
- 對稱模式下的並行
- 非對稱模式下的並行
- 對稱模式下的並行
集群文件系統中的關鍵問題
集群本質是一堆服務器合作處理任務，這一點集群塊存儲系統與集群文件存儲系統沒有區別。但是當我們面對的不是單一節點以後，會多出很多的問題， 比如說能不能用統一的目錄對後端的文件進行訪問，比如說多主機對某個文件訪問的時候會不會有沖突，還有就是每臺設備都會緩存數據，會不會有緩存不一致的情況。
下面我們將一一講解
統一命名空間（Single Name Space）
如果我們要訪問某個文件，則需要知道文件的路徑，也就是說文件是在哪個目錄裏面，比如windows下面的路徑"D:\data\file.txt"，或者Linux下面的"/usr/someone/file.txt"。windows和Linux文件系統的設計方式不同，所以路徑看上去也不同。
Windows默認為以各個分區做為入口，所以路徑開始會指明是在那個分區裏面。
而Linux是以全局為入口，所以開頭是根目錄"/"，而各個分區都
掛載到某個目錄下，比如分區sda2掛載到/home/mnt下面。那麽如果我們進入到/home/mnt，其實就相當於進入了sda2分區文件系統的根入口。同理Windows也可以把分區掛載到某個目錄下。
如果我們把一個目錄掛載到另一個目錄下面，這個被掛載的目錄就可以稱為虛擬目錄。也就是說通過虛擬目錄訪問到的不是原本屬於此目錄下的文件，而是掛載在其上的目錄樹。
所以虛擬目錄更應該理解為一個路徑，它只是提供一個路牌，路牌上的路名不等於路的本身，只是一個名字而已。
現在我們來看一個集群環境下的情況。
每個節點都有各自的路徑，但是既然多節點組成了集群，對外應該呈現為一套路徑。
比如說客戶端看到路徑/cluster/data1，而這個路徑真實應該在節點A上。不管向集群中哪個節點發出請求，所有的請求都應該重定向到節點A來，收到請求的節點就相當於一個代理而已。也就是說已經被某節點使用的路徑，不能再被其他節點所使用了。
這就是統一命名空間（Single Name Space）：集群中的所有節點上供客戶端掛載的路徑不重復，對外呈現為單一的NAS服務器。
這就是與非集群環境下最大區別。非集群下，兩臺NAS設備有同一個路徑，而且對外可見，那麽客戶端可以掛在兩個不同的獨立存儲空間，這樣當然管理起來很麻煩。
那麽怎麽實現統一命名空間呢？有兩種形式
單一路徑影像（Single Path Image）：
節點只需要管理自己的文件系統空間，然後在上面加一個中間層，可以把多個文件系統虛擬為同一個空間。比如/a和/b虛擬化為一個/c，這種方式就是單一路徑鏡像。
這種方式下，每個節點其實只能看到自己節點上的路徑，如果收到了訪問其他節點目錄的請求，應該將請求重定向到另外的節點上，當然處理的結果還是由收到請求的節點返回給客戶端，這樣做的目的是保證對客戶端的透明。
單一文件系統影像（Single FileSystem Image）
單一路徑影像只是在路徑上進行了一層虛擬化，所以可以對外呈現出單一的虛擬目錄。而單一文件系統影像更徹底，它想將所有節點的文件系統進行融合，所以它會在本地文件系統（如EXT3）上加了一層虛擬化邏輯，這樣就改變本地文件系統的邏輯，比如可以這樣，客戶端看來，某個文件在/fs/a上面，但是實際上有可能前半端在節點A，後半段在節點B。
因為文件系統已經“徹底”融合了，所以集群中的每個節點都知道所有文件的存放位置和狀態，所以這種模式下，收到客戶端IO請求的節點會對IO進行解析，然後就知道數據應該落到哪些節點上，最後把IO拆分後發到對應的集群節點上進行讀取或者寫入。而不是像單一路徑影像那樣將請求重定向到其他節點上。
總之單一路徑影像屬於松耦合，更利於節點的擴充。而單一文件系統影像是把文件系統都融合了起來，屬於緊耦合，擴展性不好，實現難度大。
集群中的分布式鎖機制
在單節點的的單一操作系統內，可能有多個應用程序對同一個文件進行修改，這樣極有可能出現數據不一致的情況，於是我們引入了鎖，這樣一個文件在同一時刻只允許這個應用程序修改，其他應用程序只能等待。
這樣又會出現一個問題，若幹某個文件加鎖了，卻遲遲未被處理，其他應用程序就只能等待，時間自然就白白浪費了。
鎖也不是，不鎖也不是，那麽有沒有兩全其美的方法呢？
當然有，比如
字節鎖：
程序只是把某端或者某些字節加鎖了，所以多個程序可以並行的讀寫文件的不同部分。這樣鎖的粒度就降低了，可以並行的讀寫同一文件，性能自然得到提高。
集群中的分布式鎖
集群其實可以看作一臺大的獨立系統，集群外的客戶端相當於應用程序，因為有並行，自然也需要鎖。
但是集群是由多個節點組成的，維護鎖需要由哪些節點負責呢？一般有兩種方式
集群中所有節點選一個節點負責鎖的維護，這就是
集中式鎖管理，用於非對稱式集群- 所有節點共同維護鎖，鎖的信息在節點上同步，這就是
分布式鎖管理，用於對稱式集群。
元數據鎖
如果一個集群中，所有的節點的角色對等，而且共享存儲，那麽此時所有的節點掌握著文件系統元數據，而且是實時同步的。
那麽當節點要為某個文件分配空間的時候，需要把相關的元數據鎖住。為什麽呢？因為如果不鎖住，如果此時其他節點也在分配空間，則兩個節點分配的空間可能有沖突。
那麽當一個節點要分配數據了，可以利用分布式鎖機制通知其他節點，位圖已經由它掌控了。當然分配完成之後，還要再與其他節點同步一下自己的元數據緩存。
緩存一致性
我們知道集群的節點會維護一個讀緩存，所以一個節點有可能緩存其他節點的某些內容。那麽就存在一種情況，某一時刻節點存儲的內容被應用修改了，但是這段內容的讀緩存有可能在其他的節點上，如果此時有終端讀到了緩存裏面的內容，則出現與實際數據不一致的情況。
那麽怎麽辦？可以把讀緩存的數據作廢或者讀入新數據以更新,這就是寫即作廢機制，可以保證全局緩存一致性。
那寫緩存呢？
對於有共享存儲的集群，
最好不開寫緩存，也就是寫入的時候最好要直接寫到磁盤上再返回成功，就好比公用物品必須放回原處，別人才能繼續用，而不能只是放到自己的緩存。
如果實在要使用寫緩存也可以，當寫的數據放到了緩存裏面以後，需要立刻通知到集群中其他節點。那麽其他節點要對這段數據進行操作的話，需要與此節點進行聯系。不過這就需要花費溝通成本來保證緩存一致性了。
如果集群沒有共享存儲
寫入的數據都緩存在本節點中，其他節點要訪問數據的話，必須聯系數據的擁有者，不存在不一致的問題。
如果集群文件系統是對外提供服務的，那麽寫緩存最好關閉，因為集群節點沒有類似SAN磁盤陣列的掉電保護機制，一旦掉電，則數據丟失。
集群、並行、分布式、共享文件系統辨析
大家平時可能聽到多種叫法：集群文件系統、SAN共享文件系統、分布式文件系統、並行文件系統。這些概念之間是否有什麽聯系呢？
SAN共享文件系統：指的是共享存儲集群文件系統。又可簡稱為
SAN文件系統分布式文件系統：可以等價於
非共享存儲集群文件系統，也就是說同一個文件系統下的文件是存放在不同的節點裏面並行文件系統：可以提供
並行訪問的集群文件系統，一般需要在主機客戶端上安裝一個代理或者新的文件系統掛載器，專門實現並行訪問。分布式不一定代表著並行，但是並行一定是分布的。並行文件系統
集群文件系統：分布式文件系統、並行文件系統、共享文件系統統稱為
集群文件系統。分布式和共享式指的是數據分布的方式，而並行指的是用戶對數據的訪問方式。
集群NAS
在【大話存儲】學習筆記（10~13章），NAS、IP SAN這一章中，我們講到了NFS/CIFS協議，它們是網絡文件訪問系統，主要的作用是讓主機可以通過網絡的訪問NFS服務器上的文件，所以它其實不是管理文件與扇區的對應關系的。
而FAT、NTFS是實實在在的文件系統，是管理文件與塊的對應關系的，我們稱為文件管理系統
那麽現在我們要構建一個集群NAS，希望他能對外提供文件訪問服務。
最底層仍然使用NTFS、EXT3等文件管理系統，主要來管理文件與塊的對應關系，
然後在上面增加一層集群文件系統，主要用來管理集群的元數據信息
再包裹一層NFS就可以對外提供文件服務了，形成了分布式並行文件系統。
如下圖所示
可以看出一個集群NAS系統其實可以分為三層架構
第一層：底層存儲空間層，可以是Share Everything（共享型）或者Share Nothing（非共享型）
- 第二層：集群文件系統層，它建立在共享型或者非共享型存儲空間之上
如果底層存儲是共享型的話，一般文件系統層都使用Single Filesystem Image。
如果底層存儲使用非共享型，則既可使用Single Path Image ,又可使用Single Filesytem Image模式。
第三層：NAS協議輸出層，可以有四種訪問模式：傳統CIFS，傳統NFS，pNFS並行客戶端，並行或者串行訪問。
總結一下，將集群文件系統中的文件用NAS協議輸出，就是集群NAS。它可以對外提供統一的命名空間，以及統一管理，若是出現了故障，還可以進行故障的切換，在線平穩的遷移等。
所以集群NAS不是簡單的NAS設備的堆砌，它可以更加的靈活，比如
集群NAS有統一命名空間
比如某個應用程序需要在一個目錄下放幾十萬個小文件，如果要把這麽多文件放到傳統的NAS的同一目錄下，性能相當的低。
如果我們把文件分散到不同的目錄呢，雖然可以並發讀取小文件，但是每個文件存放的路徑必須對主機可見，麻煩的事就來了，我們必須得修改應用程序來適應這麽多目錄。
此時集群NAS的統一命名空間就非常有用了，我們之前說過，統一命名空間指的是對外呈現統一的虛擬目錄，屏蔽了底層的細節。具體做法是將文件系統承載於多個Segment，每個Segment又分配到不同的Segment Server上，這樣主機只需要掛載一個目錄，而且還不影響性能。
統一管理、故障切換、在線遷移。如果集群NAS設備之間共享存儲則
集群NAS可以隨時將負載過高的節點上的Segment遷移到負載低的，因為這些Segment Server之間共享存儲，所以不涉及到數據移動的過程。
獨立的NAS Server發生故障，所管理的數據就無法訪問了，但是集群NAS因為共享存儲，所以在某節點故障之後，可以由正常節點進行接管（後端Segment以及IP地址等），
【大話存儲II】學習筆記（15章），文件級集群系統