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

講師介紹：朱祥磊

運營商系統架構師

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

為什麼要講雙活資料中心？從應用系統和系統保護來說，分這麼幾個角度：

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

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

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

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

下面從這五個方面展開談，一個是資料層，二是儲存層，三是接入/應用層，四是虛擬化/雲平臺；五是技術關鍵點。

一、資料層

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來進行不同中心的業務接入。

四、虛擬化

模式一 相互獨立的雙叢集

模式二 跨中心單叢集模式

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

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

虛擬化雲平臺雙活

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

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

五、雙活技術關鍵點

1、跨中心大二層網路

第二個方案是採用二層光纖直連技術打通。每個中心部署互聯匯聚交換機，中心內的匯聚（閘道器）交換機通過鏈路聚合接入該互聯匯聚交換機，互聯匯聚交換機通過鏈路聚合接入波分裝置，鏈路聚合保證整網無二層環路。同時在匯聚互聯交換機配置二層風暴抑制。

第三種基於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社群