宣告

本文為筆者根據自身的專案經驗，以及參考大量文件書寫而成。文中提到很多廠商的解決方案和概念，第一不方案之間的優劣評判，第二不進行廠商間的相互攻擊，第三文中僅代表個人觀點，不代表任何廠商的官方立場。

目前業內主流的雙活儲存技術

雙活這個概念，2013年前後比較火熱，那時候筆者有幸參與了IBM的一些雙活專案，如GPFS A-A，PowerHA/HyperSwap等。因此本文也是有感而發，經驗之談。

談到雙活，首先這是一個很寬泛的概念。廣義上說，雙活是兩個或多個數據中心，每個都具有獨立執行生產應用所需要的所有資源。此架構下所有的應用請求會被動態負載均衡到兩個資料中心，當其中一個數據中心故障時，另外一個數據中心接管所有的應用請求。

而雙活方案在落地的時候，通常是狹義的雙活，也就是資料庫層的雙活，為什麼這樣呢？首先來講，隨著技術的發展，WEB/APP很多情況下都已經實現了甚至多活；其次，傳統意義上的雙活方案，通常成本比較高，而用較高成本保護的業務系統，當然是很重要的業務系統。因此，業內主推的雙活方案，通過是做資料庫的雙活。

線上網環境，最主流的資料庫毋庸置疑當然是Oracle資料庫。而市面上通常的雙活方案實現的是Oracle extended RAC。RAC本身就是雙活的，只是預設安裝在一個共享儲存上，不能規避儲存的整體故障。Oracle extended RAC是將資料庫部署在具有同步複製功能的儲存上，這樣當一個儲存出現故障時候，資料庫asm對應的虛擬LUN的路徑會實現快切換，指向到另外一個儲存，在切換過程中，資料庫的資料不會丟失，I/O會hang 20秒左右（看到20s這個數字能默默點點頭的讀者都是老司機），然後繼續。因此通常我們可以稱這種方案RTO和RPO都為0。

而如果資料庫的資料檔案安裝在並行檔案系統上，當一個節點的儲存down以後，那麼I/O會迅速切換到該檔案系統的另外一個副本上。切換過程中，I/O hang的時間也是類似的。

“雙活”方案通常三個資料中心，提供正常服務的站點A，站點B，和提供仲裁作用的站點C，站點C上不儲存和提供任何的資料服務。目前市場上所有的雙活方案都是如此。

主流的儲存雙活技術

目前市場上常見的雙活EMC vPlex, HP 3Par，GPFS A-A，SVC的雙活。對OS而言，要麼提供block裝置，要麼提供共享檔案系統，本質上講，都是某種儲存虛擬化技術或者儲存複製技術。

我們看一個基於塊裝置的雙活儲存方案---vPLEX

基於HP 3PAR的Oracle extended RAC方案：

基於並行檔案系統的雙活方案----GPFS A-A：

最後看一下基於VMware VSAN的雙活儲存方案，這也是基於塊裝置的：

以上幾種方案裡，孰優孰劣，筆者不做品評，應該說每種方案都有其優缺點。既然存在，就有理由。

Gluster的HA/DR

最近筆者在研究開源的產品。那麼基於開gluster有沒有類似的AA/DR的方案呢？AA目前暫時沒有正式有，但HA/DR是有的。

關於Gluster的基本概念，筆者此前的公眾號文章《SDS那麼火，你家有沒有？》有過一定的介紹，關注gluster操作細節的朋友，可以進行檢視。本文後面內容不會過多介紹gluster的基本概念，因此不瞭解的朋友請自行閱讀其他文章。

我為什麼提gluster這個方案呢？（https://www.gluster.org/），首先它有很多個好處：

1.支援容量大，擴充套件性強：

Gluster叢集節點數最多可到數千，其總容量在PT級。實際上，gluster作為開源的SDS解決方案，在很多行業都有實際應用的案例，目前Gluster使用範圍很廣，如存放石油行業，用於存放勘探資料；電視臺用於存放影音檔案；多媒體超算領域用於存放海量資料。由於gluster是沒有元資料的，因此它的擴充套件性也是非常強的。

2.配置簡單、方便、靈活

Gluster作為儲存叢集，它利用多臺X86伺服器的本地檔案系統，通過伺服器之間的乙太網絡，組成統一對外名稱空間（說接地氣點就是一個統一mount點，方便使用者或應用訪問）。本地檔案系統型別可以是ext4或者xfs等。Brick的檔案系統可以位於一整塊本地磁碟/一個分割槽、本地磁碟組成的Lun/一個分割槽，甚至也可以是JBOD上的單塊磁碟或者共享儲存上的LUN，因此配置起來十分靈活。。至於說配置簡單方便，讀者可以參考筆者以前的文章中：的《SDS那麼火，你家有沒有？》“6條命令卷配好，8條命令卷可用（被客戶端）”的部分。

3.使用場景廣泛

Gluster提供多種連線方式，Samba、NFS、FUSE等，linux原生支援FUSE。

gluster既可以給Linux提供共享儲存空間，也可以給windows提供共享儲存空間；既可以給物理機提供儲存空間，還可以給虛擬機器提供共享儲存空間，並且可以給容器和AWS公有云提供共享儲存空間。

Gluster的HA（同步複製）

與傳統共享儲存一樣，本地高可用/雙活的基礎是資料的同步複製技術。對Gluster有一定了解，或者讀過我文章的朋友，應該瞭解gluster可以設定帶副本的卷，副本之間的資料是實時同步的。通過設定gluster卷的資料副本，可以實現本地高可用。

那麼Gluster目前是否可以做本地雙活儲存呢？關於這點，紅帽官方還沒有釋出。但從目前技術上，是可以實現的。筆者相信在不遠的將來，該功能能實現。

那麼雙活關鍵要解決什麼問題呢？有常見的幾個（但不限於）：

1. 故障域設定問題
2. 本地讀問題
3. 腦裂問題

故障域的設定問題

與vSAN的延伸叢集類似，一個Gluster也可以設定不同的故障域，然後將不同的副本放到不同的故障域中。實現這種配置是通過開源專案Heketi來實現的，目前該技術在紅帽的Gluster 3.1.3中屬於TP的狀態。

Heketi（https://github.com/heketi/heketi），是一個基於RESTfulAPI的GlusterFS卷管理框架Heketi的優勢在於可以自動在GlusterFS叢集確定GlusterFS bricks的位置以保證bricks和它對應的副本均勻分佈在叢集中的不同可用區，另外Heketi提供的一套RESTful API來實現對GlusterFS叢集的各類操作，可以方便的和雲平臺進行整合，實現容器編排和卷管理的自動化銜接。

Gluster在建立volume的時候，可以設定副本數量。並將不同的副本放到一個叢集不同的Zone中，也就是故障域。

本地讀問題

主流的雙活儲存都是能夠實現資料本地讀的，如HP 3PAR、SVC，軟體方式實現如VSAN、GPFS也可以實現本地讀。

Gluster作為一個開源的SDS方案，也不例外，通過設定如下引數實現：

#mount -t glusterfs -oxlator-option=cluster.read-subvolume=gv0-client

也可以通過Gluster的storage console的圖形化介面實現：

腦裂問題

常見的雙活儲存，通常是給儲存叢集設定仲裁。而gluster不僅可以設定儲存叢集中server端（gluster）的Quorum，還能設定client端的Quorum。

首先，我們知道gluster叢集實際上有一個trusted storage pool的概念，所有建立的volume都屬於一個trusted storage pool。

Server端仲裁

叢集中以設定Quorum比率。gluster的Quorum是通過glusterd服務實現的，這個服務在gluster叢集的節點上都會執行。我們設定Quorum比率以後，所有節點的glusterd都會檢查好的節點是夠高於這個比率。

# gluster volume set all cluster.server-quorum-ratio 51%

設定51%的意思很明顯，就是叢集中必須有大於50%的gluster節點是好的，trusted storage pool才是正常的，否則這個trusted storage pool會處於offline的狀態。

接下來，還有最重要的一個步驟，就是讓某個volume參與到server端仲裁機制：

#gluster volume set VOLNAME cluster. server-quo rum-type server

那麼問題來了，如果一個叢集是偶數個節點，比如兩個節點的gluster，我們將仲裁比率設定為51%，那麼當一個節點down了，另外一個節點也就須down，資料也就必須必能訪問，這樣也是必須不成的。

因此，需要設定dummy node。這個節點不包含任何bricks，只參與投票。

dummy node設定也非常簡單：

# gluster peer probe DummyNodeName

讀到這裡，可能有讀者會問，通常儲存叢集的仲裁比率都是設定為大於半數，那麼設定比率的引數不就沒有意義了麼？

這是不對的。

仲裁比率，我們通常設定為51%，但是也可以更高。

我們設想一個場景，三個節點的gluster叢集，我們將仲裁比率設定為77%。這種情況，當有一個節點down以後，好的節點數量只有66%，儲存池一定會處於offlne的狀態，那麼怎麼辦？

很簡單，增加兩個dummy node。那麼現在，儲存節點依然是3個，但是仲裁節點是5個。當有1個儲存節點down，剩餘比率是80%，儲存池依然可以訪問，當有兩個儲存節點down，那麼存活節點比率變為60%,小於77%，儲存池offline。

至於說將仲裁比率設定為多少合適，那需要根據客戶現場的實際情況以及業務的中業務重要性進行區分，gluster只是給了使用者更多的介面，讓使用者看到更多的東西，而這點也恰恰是開源的魅力之一。

接下來我們看看client端的仲裁。

Client端的仲裁

這裡我們先解釋一個概念：複製組 replicate group。它是什麼呢？我們舉個例子，有一個volume，型別是分散式複製卷，副本數是3。每份資料存在於一個物理伺服器的兩個bricks上。那麼這個volume就有三個複製組，每個複製組有兩個bricks，一共有6個bricks。

Client仲裁的作用是什麼？在預設情況下，當一個複製組裡只有一個bricks是好的的時候，gluster還是允許client修改資料。當出資料中心之間出現網路中斷以後，不同的client能夠訪問到不同的bricks，這時候，不同的client有可能會同時修改不同bricks上相同的檔案。這就會造成資料不一致，而當網路修復以後，兩邊的資料都被修改過，很短判斷以哪份為準。

是不是有點繞？舉個例子說明一下，有一個兩副本的卷，叫volume1，它有兩個副本，每個副本有一個bricks，因此這個volume1一共有兩個bricks。分別存放在node1和node2兩個server上。這個卷有兩個客戶端可以訪問，一個是大衛，一個是小衛。我們知道，當大衛寫資料的時候，必須兩個bricks的資料都寫了，才提示寫成功。當node1和node2之間失聯以後，這時候大衛向node1上的bricks寫了資料，寫完以後，node1無法通知node2，本節點上的資料寫完了；而同樣，如果小衛在node2上寫了資料，寫完以後，node2也無法通知node1本節點上的bricks寫完了，這就會造成資料的不一致。而node1和node2都認為自己是正常的，自己的資料是準確的，要用自己的這份資料去同步到對方的節點上。

那麼怎麼避免這種情況呢，一個卷有三個副本，每個副本有1個bricks，我們將客戶端仲裁的數量設定為3，只有當大衛這個節點能夠成功往2個bricks上寫資料時，gluster才認為這個寫是成功有效的，否則寫入失敗，返回read only的錯誤。

這裡補充重要一點，在當前版本的gluster下，通過NFS和SMB協議共享的卷，它的寫副本是在gluster server端完成的。而通過FUSE協議共享的卷，寫副本是在client完成的。而無論是哪種方式，我們都應該避免出現腦裂。

設定最少需要能否寫bricks的數量，例如我們設定為3.

# gluster volume set VOLNAME cluster.quorum-count=4

而在RHEV和openstack的環境下，這個資料設定成自動即可：

# gluster volume set VOLNAME cluster.quorum-type=auto

關閉客戶端仲裁的方法：
#gluster volume reset VOLNAME cluster.quorum-type

Gluster的非同步複製

Gluster的非同步複製可以通過Local Area Networks (LANs), Wide Area Networks(WANs), 甚至 Internet進行資料增量複製。

Gluster的同步複製和非同步複製對比如下：

非同步複製不僅可以實現兩個站點之間的卷複製，還可以實現多個站點之間的複製，多份複製有兩種方式：

方式1：

方式2：

卷的非同步複製配置起來並不複雜：

# gluster volume geo-replication volume1example.com::slave-vol create push-pem 其中volume1是主卷，slave-vol是遠端的卷。

配置好以後，啟動複製：

# gluster volume geo -replication volume1example.com::slave-vol start

到這裡，一定會有讀者問，那麼非同步複製的時間間隔是多少？這個間隔受一些引數的影響：rollover-time、fsync-interval。在gluster中，我們無法直接調整一個引數來修改資料更新時間間隔，geo-replicate預設是以最快的速度進行同步，但如果網路距離較長的話，資料傳輸要經過網際網路，那麼同步時間可能會比較長，期間Geo-replication會一直保持Starting的狀態。狀態由Starting轉為OK表示資料同步過程結束。通過調整這兩個引數，可以影響同步的效能：

一個紅帽客戶使用gluster做非同步複製的案例，我們可以進行參考：

總結：

截止到目前，讀者應該大致瞭解了Gluster的同步複製和非同步複製的機制。如本文開明宗義所述，任何一個方案，都有其適應場景，筆者希望能有更多的朋友一起來研究此項技術，為開源事業一起做出貢獻。