從兩地三中心到雙活數據中心

從兩地三中心到雙活數據中心

兩地三中心

兩地三中心的有幾種實現形式，下圖是一種典型案例。

在這一案例中，正常狀況下，業務運行在主機房的設備之上。主存儲與輔存儲存在單向同步關係，即主儲存的全部數據變動都會實時同步複製①到次存儲上，從而保證兩個存儲數據徹底一致。同時，爲防止極端災害發生，主存儲的數據變動也會經過異步複製②的方式同步到遠程容災機房的存儲設備上。

當主中心由於各類緣由中斷服務時，能夠經過手工命令或者軟件自動切換的方式讓業務切換到輔機房。

若是極端狀況發生，輔機房也不能運行業務，那麼遠程容災機房還有一份數據保存，能夠用它恢復業務。

注意：上圖只是一種兩地三中心的實現方式，還有好幾種其它方式，好比：⑴遠程容災中心也配置服務器，當災害發生時容災中心能夠運行業務；⑵3個存儲的拓撲方式不一樣。可是基本原理差異不大，在此就不作贅述。

①同步複製能夠保證數據徹底一致，可是對數據傳輸帶寬和時延要求都很高，成本昂貴，適用用於近程。

②異步複製不保證數據徹底一致，存在數據丟失的狀況，可是對數據傳輸帶寬和時延要求較低，適用於遠程。 

雙活數據中心

兩地三中心的優勢是防範了各類危害磁盤陣列數據（不包括軟件或者人工誤操做）的風險，缺點是成本巨高，且設備使用效率低，特別是輔機房設備不能在業務正常運行時使用，浪費很大。

因而存儲設備廠商又發展了雙活數據中心技術來改進這個缺點。

下面咱們以HP XP7磁盤陣列與ORACLE RAC配合爲例，展現這個技術方案。

這個方案的核心在於:兩個存儲配合，虛擬出一個磁盤陣列（相似於主機集羣軟件的浮動軟件包技術），主機向虛擬磁盤陣列發出IO請求，主存儲和輔存儲合做，共同完成主機對虛擬磁盤陣列的IO請求。主輔存儲數據雙向同步，經過內部機制保證數據一致性。

這個方案的優勢在於兩個機房的主機都只看到一個虛擬磁盤陣列，兩臺存儲的內部同步機制徹底對主機透明，主機應用配置簡單。

因爲主輔存儲有必定的物理距離，若是數據同步鏈路故障，就會出現「腦裂」的狀況，這時候，仲裁磁盤起做用的時候到了。

仲裁盤是獨立於主輔存儲的第三個磁盤設備（不建議用容災機房的存儲），經過FC鏈路與主輔存儲鏈接。當主輔存儲的數據鏈路出現異常時，主輔存儲會經過仲裁盤決定哪個存儲繼續提供服務，不提供服務額存儲會進入鎖定狀態，一直等到數據鏈路恢復，兩個陣列數據同步完成以後再恢復正常。

那麼，若是仲裁盤失效時，會出現什麼狀況呢？很簡單，兩個存儲都鎖定，不提供服務。畢竟數據的完整性是最重要的。

圖中的仲裁服務器又是作什麼的呢？顧名思義，它是一臺服務器或者虛擬機，上面運行專用程序爲主輔存儲提供基於IP協議的仲裁服務。

對於HP XP7或者HDS G系列陣列而言，是不須要仲裁服務器的。可是，有些設備廠商基於各方面考慮，不使用磁盤仲裁，而是仲裁服務器，好比EMC Vplex或者netapp 。

此外，有些廠商的方案沒有使用虛擬存儲，把兩臺物理存儲暴露給主機，而後在陣列上經過其它辦法實現兩個陣列的數據同步。這種辦法我有一些疑問，但願之後能獲得高人指點

還有，市場上不只有基於存儲實現的雙活，還有基於主機軟件實現的雙活，若是作得好，都是能夠知足需求的。可是有一點須要特別注意：就是「腦裂」情況的處理，我認爲：沒有第三方仲裁設備的雙活方案都是不夠強壯的，難以應付現實環境下的複雜情況。

關於「腦裂」，還有「仲裁競爭」問題：當主輔機房鏈路中斷後，存儲有仲裁機制，oracle RAC也有本身的仲裁機制，若是出現RAC鎖機制斷定主機房設備繼續提供服務，存儲卻斷定輔機房存儲繼續提供服務狀況，就會致使「雙活」變成「雙死」。

這種狀況確實是一個問題，但是若是仔細研究RAC的鎖定機制，咱們是能夠經過恰當配置來避免這種狀況的發生的，建議以下：

RAC的仲裁機制使用的是磁盤，咱們只需把仲裁盤配置在虛擬的磁盤陣列上就能夠避免「鎖競爭「的狀況發生。由於RAC仲裁盤在虛擬陣列上，主或輔存儲任意一個被鎖定，它對應機房的主機也就不可能訪問得了虛擬陣列上的鎖盤，天然不可能獲得仲裁盤的承認，繼續運行。