1. 程式人生 > >兩地三中心到雙活資料中心(轉載)

兩地三中心到雙活資料中心(轉載)

 

從兩地三中心到雙活資料中心

從兩地三中心到雙活資料中心

兩地三中心

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

 

 

在這一案例中,正常情況下,業務執行在主機房的裝置之上。主儲存與輔儲存存在單向同步關係,即主儲存的所有資料變更都會實時同步複製①到次儲存上,從而保證兩個儲存資料完全一致。同時,為防止極端災害發生,主儲存的資料變更也會通過非同步複製②的方式同步到遠端容災機房的儲存裝置上。

當主中心因為各種原因中斷服務時,可以通過手工命令或者軟體自動切換的方式讓業務切換到輔機房。同時建立次儲存到榮災機房儲存的非同步複製關係,保護資料。

如果極端情況發生,輔機房也不能執行業務,那麼遠端容災機房還有一份資料儲存,可以用它恢復業務。

注意:上圖只是一種兩地三中心的實現方式,還有好幾種其它方式,比如:

⑴遠端容災中心也配置伺服器,當災害發生時容災中心可以執行業務;

⑵3個儲存的拓撲方式不同。但是基本原理差別不大,在此就不做贅述。

兩地三中心的優點是防範了各種危害磁碟陣列硬體資料的風險(不包括軟體或者人工誤刪除資料操作),缺點是成本巨高,且裝置使用效率低,特別是輔機房裝置不能在業務正常執行時使用,浪費很大。為此,儲存裝置廠商改進了設計,讓次儲存和冗災儲存變成可讀不可寫狀態,從而讓部分業務如BI等執行在輔機房和冗災機房,分擔了主機房裝置的負載。

但是這種做法不夠純粹,實施需要主機應用軟體配合。而且主輻機房切換需要業務中斷數分鐘到數小時的時間,前端業務感知不好。

於是儲存裝置廠商又發展了雙活資料中心技術來改進這個缺點。

 

①同步複製可以保證資料完全一致,但是對資料傳輸頻寬和時延要求都很高,成本昂貴,適用用於近程。

②非同步複製不保證資料完全一致,存在資料丟失的情況,但是對資料傳輸頻寬和時延要求較低,適用於遠端。

 

雙活資料中心

下面我們以HP XP7磁碟陣列與ORACLE RAC配合為例,展示這個技術方案。

 

 

這個方案裡,主輔機房裡面的主機可以同時訪問主輔機房的儲存,這樣兩個機房的主機和儲存與ORACLE RAC技術配合,共同為業務提供服務。

那麼兩個儲存的資料一致性又如何保證呢?XP7技術方案的核心在於:兩個儲存配合,虛擬出一個磁碟陣列(類似於主機叢集軟體的浮動軟體包技術),主機向虛擬磁碟陣列發出IO請求,主儲存和輔儲存合作,共同完成主機對虛擬磁碟陣列的IO請求。主輔儲存資料雙向同步,通過陣列內部機制保證資料一致性。

當主輔儲存任一出現問題時,倖存的陣列會繼續支援虛擬陣列服務,主機感受不到虛擬陣列的後臺狀態變化。再配合oracle RAC提供的資料庫叢集功能,可以實現應用無中斷執行,前端基本無故障感知。

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

由於主輔儲存有一定的物理距離,如果資料同步鏈路故障,比方說國內常見的修路挖斷光纖的狀況,就會出現“腦裂”的情況,這時候,仲裁磁碟起作用的時候到了。

仲裁盤是獨立於主輔儲存的第三個磁碟裝置(不建議用容災機房的儲存),通過FC鏈路與主輔儲存連線。當主輔儲存的資料鏈路出現異常時,主輔儲存會通過仲裁盤決定哪一個儲存繼續提供服務,不提供服務額儲存會進入鎖定狀態,一直等到資料鏈路恢復,兩個陣列資料同步完成之後再恢復正常。

那麼,如果仲裁盤失效時,會出現什麼情況呢?很簡單,兩個儲存都鎖定,不提供服務。畢竟資料的完整性是最重要的。

圖中的仲裁伺服器又是做什麼的呢?顧名思義,它是一臺伺服器或者虛擬機器,上面執行專用程式為主輔儲存提供基於IP協議的仲裁服務。

對於HP XP7或者HDS G系列陣列而言,是不需要圖2中的仲裁伺服器的。但是,有些裝置廠商基於各方面考慮,不使用磁碟仲裁,而是仲裁伺服器,比如EMC Vplex或者netapp。

此外,有些廠商的方案沒有使用虛擬儲存的技術,而是把兩臺物理儲存暴露給主機,然後在陣列上通過其它辦法實現兩個陣列的資料同步。這種辦法我有一些疑問,希望以後能得到高人指點

還有,市場上不僅有基於儲存實現的雙活,還有基於主機軟體實現的雙活,如果做得好,都是可以滿足需求的。但是有一點需要特別注意:就是“腦裂”狀況的處理,我認為:沒有第三方仲裁裝置的雙活方案都是不夠強壯的,可能難以應付現實環境下的複雜狀況。

除了“腦裂”,方案設計者還要考慮“鎖競爭”問題:當主輔機房鏈路中斷後,儲存有仲裁機制,oracle RAC也有自己的仲裁機制,如果出現RAC鎖機制判定主機房裝置繼續提供服務,儲存卻判定輔機房儲存繼續提供服務情況,就會導致“雙活”變成“雙死”。

這種情況對於某些應用軟體或者非磁碟仲裁的儲存裝置可能是一個需要費一番周折才能解決的問題,但是對於本例中的XP7+RAC,我們是可以通過如下配置來避免這種情況的發生:

因為RAC的仲裁機制使用的是磁碟,我們只需把仲裁盤配置在虛擬的磁碟陣列上就可以避免“鎖競爭“的情況發生。因為RAC仲裁盤在虛擬陣列上,主或輔儲存任意一個被鎖定,它對應機房的主機也就不可能訪問得了虛擬陣列上的鎖盤,自然不可能得到仲裁盤的認可,也就不能繼續運行了。