GlusterFS複製卷修復原理以及腦裂分析

• 2020 年 1 月 23 日
• 筆記

裂腦

所謂腦裂，就是指兩個或多個節點都「認為」自身是正常節點而互相「指責」對方，導致不能選取正確的節點進行接管或修復，導致腦裂狀態。這種現象出現在數據修復、集群管理等等高可用場景。

    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 客戶端與伺服器端仲裁機制對比。

參考資料說明

    絕大多數內容來自：GlusterFS冗餘鏡像（AFR）修復原理以及腦裂分析，寫的不錯，做了一些的小的改動，特別是對裂腦的態度。這裡標成原創，提高曝光率。