《從IT應用架構角度，暢談雙活數據中心容災解決方案》要點：
本文介紹了從IT應用架構角度，暢談雙活數據中心容災解決方案，希望對您有用。如果有疑問，可以聯系我們。

本文根據朱祥磊老師在〖5月6日DBAplus社群濟南數據庫技術沙龍〗現場演講內容整理而成.

講師介紹：朱祥磊

運營商系統架構師

• 負責業務支撐系統架構規劃和建設.獲國家級創新獎1項、通信行業級科技進步獎2項、移動集團級業務服務創新獎3項,申請發明專利13項.

為什么要講雙活數據中心?從應用系統和系統保護來說,分這么幾個角度：

首先做容災,第一個要考慮的是主備,上圖左側是最早出現的主備模式,一般是在兩個中心建互備系統,比如我在B中心,容災系統在另外一個地方,這種模式比較容易切換.假如A中心出問題了,就綁定在B中心,或者是把數據復制到B中心,容災資源是閑置著,承擔著容災的任務.另外真的出問題了,我得需要一個定位,因為并不能確認它是否確實不能用了,所以,要確保這個業務完整,數據也不丟,定的時間加上切換流程,至少得0.5小時,甚至更長,甚至一兩天,這樣導致弊端很多.

后來為了節約資源,發展到現在雙中心互備,A中心一部分做生產,B中心也一部分做生產,在原來的儲備方式上做了一個改進,優點是因為這兩個中心都有生產業務運行,可通過資源共享技術節省資源.但僅僅是計算源,對于存儲來說,由于這個存儲空間必須要保證完整來做,所以沒有辦法充分利用起來,還是閑置狀態.針對這種問題,我們現在又有了雙活并行模式,同一個系統,兩個中心都可以承擔業務,同時對外服務,壞掉任何一方不影響.

這是非常理想的一種狀態,今天主要講的是要實現這種架構或部分實現,需要哪些技術,需要做哪些工作,只是簡單的講,不一定很深入,也希望能夠和大家一起溝通交流,看有沒有更好更優的方案.

我主要從應用到基礎設施的角度來講.因為從整個應用架構來看,咱們有一些業務可能是有接入層,下面是應用邏輯,后面包括還有一些接口,再下面是數據層,再下面是基礎架構,有可能有存儲和網絡,這么幾層,每一層都會有相應的雙活實現技術.例如應用層可能有各種集群,數據層可能有一邊同時可讀寫,或一邊只能讀等.再如基礎架構層,在網絡上對穩定性和帶寬吞吐性能要求更高,甚至需要打通跨中心的大二層網絡,存儲方面則需改變一主一備的讀寫機制,實現同時可讀寫.

下面從這五個方面展開談,一個是數據層,二是存儲層,三是接入/應用層,四是虛擬化/云平臺；五是技術關鍵點.

一、數據層

首先講數據層(這里指傳統數據庫)中的雙活方式,一種叫Active Standby方式,一種方式為兩個都是Active方式,此外還有數據邏輯復制軟件模式.

Active Standby是基于Oracle ADG技術,這個模式采用從主庫向備庫傳輸redo日志方式,備庫恢復數據過程可以用只讀方式打開進行查詢操作,實現了部分雙活功能,在主節點故障后可以將備節點切為生產.

Active—Active方式指的是兩點都可以同時讀寫,例如通過Oracle Extend RAC實現多個集群節點同時對外提供業務訪問.該方式能做到故障無縫切換,提升應用系統整體性能.這種模式理論上不需進行人工切換操作.

另外在基于邏輯復制的軟件,利用數據庫在線日志中的數據變化信息,通過網絡將變化信息投遞到目標端,最后將目標端還原數據,從而實現源目標的數據同步.

方式一：Oracle ADG

首先第一個模式是Oracle ADG模式.通過網絡從生產向容災傳輸歸檔或redo日志,容災端恢復方式同步恢復.這個數據庫不斷把日志寫入到備庫.這種方式的優點是存儲支持異構.

應用場景：可以把這個庫可以作為應急或容災用,作為數據保護手段.

方式二：邏輯復制

通過DSG、GoldenGate等邏輯復制軟件技術實現跨中心數據庫的相互復制,這種邏輯復制支持表級的復制,要求兩個數據中心各建一套數據庫,物理獨立,同時能讀寫.基于數據庫日志準實時復制數據,支持異構數據庫,異構OS.可以實現一對一、一對多,多對一、雙向復制等多種拓撲結構.把日志進行分析,寫到這個庫,是以跨中心的共享存儲基礎,通過共享存儲資源和Oracle數據庫集群軟件管理,實現各個中心節點對數據庫并行訪問.

方式三：Oracle 遠程RAC??

Oracle Extended RAC以跨中心共享存儲為基礎,通過共享存儲資源和Oracle Clusterware數據庫集群管理,實現各個中心節點對數據庫并行訪問.

共享存儲可以采用存儲自身數據復制技術,存儲虛擬網關或遠程卷管理等技術,以Oracle ASM存儲卷管理為例,實現數據的雙向實時復制.

要點：

• 兩個數據中心分別部署一套存儲,各提供一套LUN設備給全部數據庫主機.
• 存儲的SAN網絡和RAC心跳網絡需使用低延遲、高帶寬的DWDM光纖鏈路.
• 配置ASM磁盤組.每個磁盤組配置兩個失效組,每個失效組對應來自一套存儲的LUN設備.
• 在第三個站點部署用于RAC的第3個投票盤,使用NFS的方式掛載到所有數據庫主機.
• 與管理普通的RAC系統類似,需要重點加強對站點間光纖鏈路情況的監控與應急.

內存庫雙活技術

內存庫雙活技術,將數據放在內存中直接操作的數據庫,相對于磁盤,內存的數據讀寫速度要高出幾個數量級,將數據保存在內存中相比從磁盤上訪問能夠極大地提高應用的性能.

應用場景：用于實時計費,讀寫分離場景,主要有Oracle Times Ten,Altibase商用以及華為等相關產品.內存庫集群部署主要有HA模式,雙活模式,線性拆分和分布式集群四種模式.

內存庫通過復制手段,實時地復制到另外一個中心,它們之間是一個跨中心的數據,這是HA模式.另外雙活模式,和這個模式是HA模式的延伸,可能一部分表是一個方向復制,另外一些表反過來.還有一種是線性拆分模式,將內存數據放在多個內存庫集群中,每個內存庫存放一部分數據,并互為備份,這種模式需要應用進行針對性改造.分布式集群模式,自動實現不同數據分片和副本機制,是目前比較流行的一種結構.

數據層雙活技術比較

邏輯技術軟件容易出現邏輯錯誤導致數據不一致,而且很難稽核.ADG模式數據在數據庫級是完全一致的,當然前提是能正常同步,但是不支持兩邊同時能讀寫.從數據延遲來看,不管是ADG還是邏輯復制軟件,都跟日志量有關系,后面會講我們在不同日志量情況下做的測試延遲結果.

二、存儲層

存儲層作為雙活系統核心基礎架構平臺,其雙活技術在整個架構中起到關鍵作用,目前基于存儲層雙活方案主要有下面三種：

• 基于遠程卷管理軟件的虛擬化,比如Symantec SF、IBM GPFS、Oracle ASM等.
• 基于存儲網關虛禮化,如EMC、vplex、IBM、SVC.在傳統存儲上面增加了一個虛擬化網關,在每個機房里面,新增存儲虛擬化網關設備組成跨站點集群,并對存儲卷進行重新封裝,對外提供主機訪問.
• 存儲卷鏡像技術,將兩套磁盤陣列組成一個集群,兩臺存儲上的LUN被虛擬化為一個虛擬卷.

流派一 遠程卷管理軟件

• 數據同步：底層數據復制采用遠程卷管理軟件,如賽門鐵克的storage Foundation(SF)、IBM的GPFS、Oracle的ASM等,通過邏輯卷鏡像技術實現底層數據邏輯同步.上層應用采用Oracle Extended RAC方案實現遠程多節點RAC,使生產和容災節點都處于在線狀態,應用邏輯訪問的是同一個數據庫.
• 數據讀寫：支持雙讀寫.
• 數據一致性：完全一致.

上面是不用遠程卷管理軟件的一個情況,我只需要認識到自己機房的存儲就可以了.底層存儲實現遠程復制到容災存儲上,如果改造成遠程管理軟件,那么服務器既要認到本地存儲也要認到對端存儲,實現兩邊都是同時可以對存儲讀寫的,而且還可以通過設置策略,寫的話向2個存儲同時寫,讀的話可以優先讀本地的,從而可以加快讀的速度.

流派二 存儲網關虛擬化

實現原理：將存儲虛擬化技術和Oracle的遠程RAC技術結合,實現跨中心的數據雙活訪問.平時兩邊主機分別訪問本地存儲,故障情況下可垮中心訪問對方存儲.對于同一個數據塊的讀寫沖突機制,是由Oracle RAC來保證的.存儲不能直接給服務器訪問,需要先通過中間層虛擬化網關設備,再訪問存儲.為了防止出現兩個中心間網絡全斷情況下,兩邊互相不知道誰還活著,需要建一個仲裁節點(建議在第三個中心),實現讓誰作為主,讓誰作為訪問的仲裁機制,從而防止數據不一致這種極端情況.

流派三 基于存儲自身卷鏡像

這是一個存儲自身卷的鏡像,這是一些新的設備情況,它的優點,整個網絡架構沒有改變,從主機到交換機到存儲,也沒有增加任何的設備,這種是相對來說比較易于實行(也需要一個仲裁站點).

存儲層雙活技術對比

這是一個存儲層的雙活技術比較,容災技術有2個重要參數,RPO(故障恢復點)和RTO(故障恢復時間).這幾種理論上都能實現RPO等于0,也能支持雙活讀寫.從可靠性來看,這個數據不是完全決定的,需要根據實際情況定.從異構性來說,除了存儲自身虛擬化和存儲HA機制不支持外,其余都支持.但不管存儲雙活有哪幾種,雙活都需要用到遠程Extend RAC.

三、接入/應用層

下圖是一個例子,一個比較前端的系統,分為接入/接口層、應用層、主機/數據庫層、存儲層等,各個層面統籌考慮雙活機制,才能實現零切換.首先不能像原來煙筒式的數據庫連接,應考慮統一數據庫訪問接口,并實現應用自動重聯機制,確保自動切換,減少人工切換.在應用層,則考慮雙中心部署相同的應用集群方式,或跨中心的集群方式.

從接入層看,如何把業務接入到兩個中心,一般有這么幾種,一種是采用全局負載均衡(如F5的GTM)、DNS、或前置CDN等技術實現跨中心靈活接入.

• 業務多中心并行模式：通過一組GSLB來對外提供服務,GSLB監控服務的狀態,并通知組內其他設備,對于每一個DNS請求返回最佳結果,好的策略選擇和配置方式可以最大幅度提高客戶體驗.
• 業務多中心互備模式：對于內網業務通過一組SLB來提供服務,實現DNS解析,負載分發和故障切換.
• 前置CDN,通過CDN來進行不同中心的業務接入.

四、虛擬化

現在都在講云計算,是非常熱門的,其主要技術特征,首先是帶來虛擬化技術,其次應用實現集群化和x86化.相應帶來的問題：我們原來的雙活設計模式,可能不適應這種虛擬化或應用集群化模式,需要重新考慮業務連續性雙活方案.我總結了四大類：

1. 繼續沿用傳統基于負載均衡的雙活架構.每個中心部署獨立的云化應用集群,通過接入層負載均衡實現雙活.舉個例子,有Web集群,通過前面接入增把業務分發到不同集群去.
2. 基于分布式應用協調機制,可以建一套跨中心應用集群,通過分布式應用協調機制,實現跨中心的高可靠性集群,統一配置,統一管理和任務分配.
3. Hadoop、MPP等的雙活機制,應用寫兩份方式實現雙活,跨中心集群方式.
4. 虛擬化平臺的跨中心雙活(遷移),我們也是既可以建跨中心集群,也可以建兩個獨立集群,通過一些業務來分發.舉個例子,我們現在可以建云資源池,建一些獨立的池.

模式一 相互獨立的雙集群

在每個中心部署獨立的云化應用集群：

1. 如Web類應用可通過接入層和負載均衡實現雙活訪問；
2. 如Hadoop或MPP集群應用可通過上層應用實現雙集群數據同步,從而實現雙活.

模式二 跨中心單集群模式

第一種是基于分布式應用協調機制：構建一套跨中心應用集群,通過分布式應用協調如ZooKeeper實現跨中心的高可靠性集群,實現統一配置、統一管理和任務分配.

第二種是基于數據副本保護機制：如詳單云和大數據的Hadoop集群、大數據的MPP集群等,通過進行合理規劃設計,確保任一中心節點都是完整的數據副本,由集群自動維護兩個中心的數據副本同步機制來實現雙活.

虛擬化云平臺雙活

基于存儲陣列雙活和VMware 跨站點集群功能實現虛擬化平臺數據中心容災解決方案,在陣列雙活技術支撐下,通過VMware Cluster 的HA高可用功能實現故障業務切換保護,從而達到保證業務連續性的要求.

 

• 網絡站點間二層互聯,采用波分傳輸,存儲實現雙活為上層提供共享存儲；
• 將兩個數據中心服務器配置為一個集群,通過HA和DRS實現高可用和資源動態智能分配；
• 服務器之間建議通過萬兆以太網提供心跳服務與vMotion遷移流量,集群內的所有服務器需符合集群的兼容性規則.
• 應用層：由四臺服務器構建VMware ESXi Cluster.

 

五、雙活技術關鍵點

1、跨中心大二層網絡

為了降低二層網絡,evn otv必須整體在一個二層網絡里,這種情況怎么實現呢?這里就需要考慮到大二層網絡,有那么幾種技術,一種是EVN/OTV/EVI技術,通過Mac in ip,實現了這兩個中間的二層網絡互通.EVN的話,以中間為界,這是一個機房,這是另外一個機房,這是它們內部接入的交換機,然后它們把這個接入到這上面,中心間也是類似的,這個P和這個P之間打通,這樣就實現了互通.

第二個方案是采用二層光纖直連技術打通.每個中心部署互聯匯聚交換機,中心內的匯聚(網關)交換機通過鏈路聚合接入該互聯匯聚交換機,互聯匯聚交換機通過鏈路聚合接入波分設備,鏈路聚合保證整網無二層環路.同時在匯聚互聯交換機配置二層風暴抑制.

第三種基于MPLS網絡的VPLS互聯.每個中心的核心交換機與專用的MPLS域專用網絡直連,通過MPLS專屬網絡的本地PE設備與對端中心的機房PE設備之間建立VPN,將各個PE設備所互連的二層網絡通過MPLS? VPN方式建立二層互通.

第四種為基于Overlay網絡的大二層互聯.

以Vxlan實現方式為例,每個中心通過單獨的ED設備與Underlay網絡連接,在每個中心內部業務數據通過VXLAN進行業務交換,涉及到跨中心業務互訪時,將通過與ED設備直連的leaf設備剝離VXLAN標簽轉換為VLAN業務后,由ED設備再次進行VXLAN封裝,從而通過大二層透傳到對端中心的ED設備剝離VXLAN標簽,由對端中心的leaf設備重新封裝VXLAN標簽.一種是VPLS模式,這個是一個標準協議,但是技術比較復雜.大二層互聯也是疊加在現有的網絡之上,但是是每個廠家私有協議,在復雜的網絡環境中很難實現對接.支持Overlay網絡,可以跨裸光.

2、關于Golden Gate

還有剛才提到的Golden Gate性能瓶頸在數據同步環節,即在復制進程Replicat入庫速度,因為在容災端恢復數據過程是執行邏輯SQL,比較消耗資源.

抽取進程(Extract) ：該進程主要瓶頸在于LCR(logical change record)轉換為UDF環節,主要優化建議：

• 拆分Extract進程,建議同一個schema下表盡量在一個進程組中
• 優化進程參數如eofdelay、flushsecs等
• I/O部分建議增加日志讀取間隔3s,增加內存刷新時間3s

投遞進程(Pump)：帶寬優化和IO優化：

• 復制的表最好有主鍵或唯一索引,減少生產日志量
• 數據傳輸過程啟用數據壓縮特性,減少帶寬需求量
• 適當增大TCP緩存
• 增加隊列讀取間隔為3s,內存刷新時間為5s

復制/應用進程(Replicat)：該環節出現性能問題較多,需要重點優化：

• 合并小交易減少事物數量,減少寫checkpoint file/table次數
• 大交易拆分(maxtransops參數),提高寫入速度
• 基于表或Range等拆分replicat進程

還有就是這邊變化得非常大,尤其在這方面是非常大的,如何優化中進行一定的拆分,建議同一個schema下表盡量在一個進程組中,這個獨立解決也可以進行帶寬優化和IO優化.合并小交易減少事物數量,減少寫checkpoint file次數.大交易拆分,提高寫入速度,基于表等拆分進程.這是一個表,在每分鐘產生的數據量,如果在16G以下,基本上是準時的,但如果在16G以上延遲非常高,每分鐘40G的話,能延遲到1小時了.所以它做的市場上的業務量大,能延遲.

3、關于ADG

這也是我們一個前提測試的情況,我們用了一個數據庫的數據總量11G,存儲總量是這些,這是它的規格,有40G,有280G左右,我們當時采用的是千兆網,傳輸日志平均占用帶寬為16.24MB/s,單個小時內峰值為52MB/s.目前這是一個測試情況,另外一個注意的地方,需要做的好多測試參數,底層依賴于存儲,他們之間設置的參數有規則,參數的超時時間不能隨便設,必須保證RAC的磁盤仲裁要晚于GPFS的仲裁,使得在網絡故障情況下GPFS提前RAC做出判定.這樣才能避免數據的損壞.

4、防止“腦裂”現象

• 由于數據中心間距離遠,網絡穩定性相比同機房差,必須需要額外進行冗余設計,如網絡連接、內部網絡、san連接等.2個數據中心間網絡不穩定情況下,無論存儲虛擬化技術還是Oracle的RAC均可能出現“腦裂”現象,造成訪問中斷,數據不一致現象發生,需要仔細設計,如采用互聯環狀全冗余架構等、完善的仲裁機制等.
• 對跨中心間的網絡帶寬、存儲訪問帶寬利用率不能超過30%.
• 雙活由多層軟硬件組成,如數據庫RAC、遠程文件系統、存儲等,需要仔細規劃它們之間的心跳參數,確保越低層的心跳超時時間越高.

5、全面的計劃內外測試場景

雙活涉及到跨中心網絡層,數據層和存儲層,故障場景相比較傳統架構更多,更復雜,相互之間存在多種依賴關系,需要充分設計故障測試場景.如果建設的話需要重點進行測試.

這是我們建設的一個雙活數據中心架構的例子,這是兩個機房,它的上層是接入網,下層是Spine.下面是各個虛擬化接口,應用層,提供虛擬層跨中心遷移功能.再下面是個存儲層,雙活架構.

今天分享就到這里.若有疑問,歡迎留言交流.

文章來自微信公眾號：DBAplus社群

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4121.html