Glusterfs冗餘鏡像（AFR）修復原理以及腦裂分析

研究Glusterfs半年多了，經過實際操做以及源代碼分析，對它有了愈來愈深的瞭解，由衷的讚歎Gluster的總體架構。今天時間不早了，想寫點關於Glusterfs的冗餘鏡像產生腦裂的緣由。

首先，簡單描述一下腦裂，所謂腦裂，就是指兩個或多個節點都「認爲」自身是正常節點而互相「指責」對方，致使不能選取正確的節點進行接管或修復，致使腦裂狀態。這種現象出如今數據修復、集羣管理等等高可用場景。

Glusterfs的冗餘鏡像（下文簡稱AFR）提供了數據副本功能，可以在即便只有一個冗餘節點的狀況下仍能正常工做，不中斷上層應用。當節點恢復後，可以將數據修復到一致狀態，保證數據的安全。

AFR工做原理

AFR數據修復主要涉及三個方面：ENTRY，META，DATA，咱們以冗餘度爲2即含有兩個副本A和B的DATA修復爲例進行講解。記錄描述副本狀態的稱之爲ChangeLog，記錄在每一個副本文件擴展屬性裏，讀入內存後以矩陣形式判斷是否須要修復以及要以哪一個副本爲Source進行修復。初始值以及正常值爲0.（注：ENTRY和META,DATA分佈對應着一個數值）。

Write的步驟可分解爲：

1）下發Write操做。

2）加鎖Lock。

3）向A，B副本的ChangeLog分別加1，記錄到各個副本的擴展屬性中。

4）對A，B副本進行寫操做。

5）若該副本寫成功則ChangeLog減1，若該副本寫失敗則ChangLog值不變，記錄到各個副本的擴展屬性中。

6）解鎖UnLock。

7）向上層返回，只要有一個副本寫成功就返回成功。

上述在AFR中是完整的一個transaction動做。根據兩個副本記錄的ChangeLog的數值肯定了副本的幾種狀態：

1）WISE，智慧的，即該副本的ChangeLog中對方對應的數值大於0並且自身對應的數值等於0.

2）INNOCENT，無辜的，即該副本上的ChangeLog即不指責對方也指責本身，ChangeLog全爲0.

3）FOOL，愚蠢的，即該副本上的ChangeLog是指責本身的。

4）IGNORANT，忽略的，即該副本的ChangeLog丟失。

因此通常狀況下，會選取WISE的副本做爲Sourse進行修復。可是當兩個節點都是WISE狀態時，這就出現了聲名狼藉的腦裂狀態。

AFR腦裂

兩個副本均爲WISE時發生腦裂，那麼在哪一種場景下會產生腦裂呢？咱們仍是以冗餘度爲2的狀況舉一個簡單的例子：某文件X的兩個副本位於物理機A和物理機B上，在A和B上分別運行着進程a和進程b，a和b持續經過各自所在的物理機上的客戶端對文件X進行不一樣的寫操做。而後物理機A和B之間網絡中斷，由於AFR在一個副本的狀況下仍能不中斷上層應用，因此進程a和進程b仍會持續運行，但由於網絡中斷，文件X在A和B上的副本數據再也不一致且都認爲對方是異常的，當網絡恢復時，兩個副本互相「指責」，即出現了腦裂。固然這是腦裂發生的場景之一，有時候是有可能發生腦裂，而有時候是必然發生腦裂。腦裂，也是不少人關心的一個問題，不能一律而論。

關於腦裂，我我的認爲不一樣的場景處理方法也是不一樣的，甚至某些場景的腦裂是沒法避免的，只能儘可能避免腦裂的發生。好了，今天就寫到這裏吧。晚安~

原文出處：

Glusterfs冗餘鏡像（AFR）修復原理以及腦裂分析

http://www.iesool.com/forum.php?mod=viewthread&tid=90&fromuid=2
(出處: 吖Sool-社區)