金融行業雙活數據中心的建設

金融行業雙活數據中心的建設

「雙活「這個概念，已經被提了不少年了。因爲金融行業對業務的穩定性要求較高，所以雙活也收到金融行業客戶的關注。本文將着重分析雙活數據中心的架構，並對金融行業雙活數據中心給出建設的意見。

 

在正式開始文章以前，咱們帶着三個問題去來讀這篇文章，在文章的最後，我將會對這三個問題進行參考性回覆。

 

Q1: 雙活是哪一個公司的強項？Red Hat、VMware、IBM、EMC？

Q2: 雙活主要靠的是應用層交付，如負載均衡等，而不需底層IaaS層的高可用？

Q3: 大家的雙活方案是什麼？是否能知足咱們的要求？

 

1. 雙活數據中心的概念

雙活是兩個數據中心，每一個都具備獨立運行生產應用所須要的全部資源。此架構下全部的應用請求會被動態負載均衡到兩個數據中心，當其中一個數據中心故障時，另一個數據中心接管全部的應用請求。

 

雙活數據中心的的優點在於：

l  提升用戶的快速體驗和鏈路的利用率，但願能夠經過任意一條鏈路訪問到不一樣數據中心的業務；

l  雙中心都能提供業務負載，須要時可直接在另外一箇中心擴容資源；

l  知足臨時快速加載基礎架構資源的要求。

l  充分利用資源，避免了一個數據中心常年處於閒置狀態而形成浪費，經過資源整合，雙活數據中心的服務能力是雙倍的；

l  若是中斷了一個數據中心，其餘的數據中心仍可獨立響應業務，對用戶來講業務切換是無感知的

 

2.雙活的分類

在討論雙活的分類以前，咱們必須明確一個前提：即雙活針對一套應用（而不是不一樣的應用在不一樣的數據中心實現主備的總體雙活）。在這個前提下，雙活分爲狹義雙活與廣義雙活。

 

• 廣義的雙活數據中心指的是：一個應用WEP/APP/DB，要麼App提供雙活，數據庫跨數據中心主備。要麼App主備，數據庫跨數據中心實現雙活。前者應用雙活，後者是數據庫雙活。

 

• 狹義的雙活數據中心，指的是：一個應用的Web/APP/DB在兩個數據中心都是雙活的。也就是應用雙活+數據庫雙活。

 

接下來，咱們看一下這幾種雙活的特色和實現方式。

 

應用雙活：

• 雙生產中心均提供web層和app層服務

• 數據庫服務只在其中一箇中心提供

• 經過數據複製技術將數據複製到對方

• 出現災難時，根據須要分層切換，或所有切換到另外一中心。

 

 

應用層雙活須要負載均衡器配合。在架構層面，多個數據中心經過內部私有網絡互聯，統一對外提供服務。在多個數據中心內，應用在每一個數據中心都是處於活動狀態，在這種運行模式下，必須使用應用交付設備來實現應用的管理。

 

數據庫雙活：

• 雙中心Web/APP層是主備

• 數據庫雙活，依賴於高端雙活存儲

• 出現災難時，應用切換到第二數據中心

 

 

 

 

狹義雙活：單應用對稱雙活：

• 雙生產中心均須要完成生產業務

• 經過雙活存儲進行數據複製，在兩邊提供無差異的存儲服務

• 經過業務模塊或用戶的方式將業務分配到不一樣的中心

• 平時主要的處理能力均分配給生產應用系統使用

• 出現災難時，根據須要接管的方式，動態調度資源給關鍵應用使用

 

不一樣雙活技術對技術的要求：

3.雙活方案的落地 

在早些年，應用主要是單實例、單體應用。那時應用的高可用主要經過操做系統HA軟件和共享存儲保證，如PowerHA、MC/SG、Redhat Linux HA。彼時，實現應用的雙活是比較難的。由於應用自己不具有雙活的功能。所以，目前大多數落地的雙活方案，更可能是數據庫的雙活。

 

在線網環境，最主流的數據庫毋庸置疑固然是Oracle數據庫。數據庫的雙活方案實現的是Oracle extended RAC。咱們知道，RAC自己就是雙活的，只是默認安裝在一個共享存儲上，不能規避存儲的總體故障。Oracle extended RAC是將數據庫部署在具備同步複製功能的存儲上。以下圖所示。

 

 

咱們能夠看到雙活節點其實包含三個數據中心，提供正常服務的站點A，站點B， 和提供仲裁做用的站點C，站點C上不保存和提供任何的數據服務。目前市場上全部的雙活方案都是如此。Oracle RAC的雙活必須依賴於雙活存儲。雙活存儲有一個關鍵的特徵：在數據中心之間能夠實現同步雙向複製，由於只有這樣，才能保證兩個站點的存儲都能同時被讀寫。

 

目前市場上常見的雙活存儲有：EMC vPlex, HP 3Par，GPFS A-A，SVC的雙活。對Oracle RAC而言，要麼提供塊設備，要麼提供共享文件系統。

 

咱們看一個基於塊設備的雙活存儲方案---vPlex

接下來看一個基於並行文件系統的雙活存儲方案----GPFS A-A：

 

咱們再看一個HP 3Par的雙活存儲方案：

4.Oracle Extended RAC在各類故障場景下的表現

 

將雙節點的Oracle Extended RAC部署到雙活存儲上，模擬各類故障場景。咱們關注出現故障時，數據庫對外服務的表現。從下表能夠看出，數據庫雙活能夠應對單數據中心級別的全部故障。

 

5.容器時代的雙活

近些年，隨着容器、微服務的普及，不少應用已經作到了分佈式和無狀態化。傳統的高可用技術做用被大大削弱。

 

例如，客戶的容器化應用運行在Openshift/kubernetes上，單個應用使用一個Service IP，一個Service IP對應一個或者多個Pods。ServiceIP到不一樣的pods，自己就能夠作負載均衡。這時候，在一個數據中心內部，咱們只須要讓pods運行到不一樣的計算節點上，多個pod同時訪問一個pvc，便可以實現單數據中心業務的高可用，而徹底不是使用傳統的HA軟件，也不用依賴底層虛擬化的HA功能（若是將Openshift安裝到虛擬化上）。

 

在Openshift環境中，雙活數據中心經過以下方式實現。

 

須要兩個獨立的數據中心，部署兩套Openshift集羣。容器的持久化數據保存在雙活存儲上。兩個站點同時對外提供服務，當一個站點出現故障，另一個站點接管新的請求。總體業務不中斷。

因爲容器的彈性能力很強、啓停的速度很快。所以上圖的方案能夠實現基於容器的應用級別雙活。即便咱們在Openshift中部署一些輕量級的數據庫爲應用提供數據，如MySQL，也能夠經過雙活存儲方案實現。或者咱們將MySQL部署到物理服務器，經過雙活存儲實現異地雙活也是能夠的。

 

但上面方案有一個缺點，是什麼呢？成本高。

 

本質上講，運行在容器上的應用，相比於核心業務系統，一般關鍵性沒那麼高。並且容器的持久數據一般是日誌、監控數據和配置文件。咱們只要保證數據不丟失便可。這時候，再爲容器化的應用配置高端的雙活存儲就顯得成本太高。咱們只須要保證企業的核心數據庫是雙活的便可。

 

所以，基於容器的高可用解決方案，咱們能夠考慮以下的配置：兩個獨立的數據中心，部署兩套Openshift集羣。底層存儲單向同步或異步複製。第一站點發生故障時，災第二站點的容器在很短的時間提供服務（秒級）。

 

6.金融行業構建雙數據中心的建議

近兩年，不少國內的銀行在構建直銷銀行、數字銀行。這二者都是互聯網金融的體現。互聯網金融須要的是敏態IT：快速迭代、快速上線。這類業務也一般選用容器平臺構建。對於金融行業客戶而言，在保證傳統核心穩定的狀況下，構建互聯網核心，也就是：雙核心、大外圍是一種廣泛的作法。在這種狀況下，將傳統的核心數據庫實現數據庫雙活，將容器化應用實現跨數據中心主備，是一種既能兼顧成本和業務連續性較高的方法。固然，若是企業對RTO/RPO要求很是高，而且預算較多，實現對稱雙活也是徹底能夠的。

 

 

最後，我將三個問題的參考回覆分享出來：

Q1: 雙活是哪一個公司的強項？Red Hat、VMware、IBM?

A1: 雙活數據中心是個複雜的工程，包含服務器、存儲、硬件、網絡設備、應用等。沒有一個廠商能夠獨立完成。從落地的雙活方案看，數據庫雙活更多，針對數據庫雙活，傳統高端存儲廠商更有優點。從技術的發展看，隨着K8S和微服務的普及，顯然應用的雙活更容易實現，在這種場景中，PaaS廠商和作中間件的廠商會更有優點。

 

Q2: 雙活主要靠的是應用層交付，如負載均衡等，而不須要IaaS的高可用等功能？

A2: 負載均衡在虛擬化和容器出現以前就已經出現，隨着技術的發展，負載均衡更注重於應用交付，而基IaaS更注重於資源調度。兩種技術共同做用於雙活數據中心。

 

因爲K8S自己能夠提供容器的高可用，它確實必定程度上削弱了容器須要依賴虛擬化HA來保證高可用的必要性。例如，咱們能夠將Openshift部署到物理機上，依然能夠實現應用的高可用。而部署到虛擬化上的目的，更可能是出於爲了統一管理、更爲方便爲Openshift集羣增長資源的目的。

 

Q3: 大家的雙活方案是什麼？是否能知足咱們的要求？

A3: 沒有最完美的方案，只有最適合的方案。咱們須要先了解客戶的現狀、條件，投資、以及目標，而後給出一個最適合的方案。就經驗而言，對於金融行業，核心數據庫實現數據庫雙活、應用實現數據中心主備，總體上是更容易實現的。