銀行跨數據中心資料庫雙活架構設計：設計原則及技術選型
災備中心要承載業務運行，這已經是一個共識。因此災備中心的概念也在弱化，取而代之的是IDC數據中心概念。首先數據需要在多數據中心複製，保證數據不丟失。其次業務多數據中心部署，同時提供服務。這一點在互聯網行業做得最好。這也是因為互聯網行業本身的業務特點促成的。然而對於傳統行業，不能完全照搬互聯網行業的分散式技術。更多的系統是需要在現有架構的基礎上進行改造。這也是為什麼要做雙活的數據中心。
每個系統在多數據中心部署的目標是不同的，可以是分散式業務，也可以是讀寫分離，也有完全對等雙活的業務部署。在這些部署方案裡面，資料庫雙活技術也成為重點關注的對象。然而在使用這些技術的時候存在很多誤區，並非所有的場景都適合，所以企業需要一定的取捨，真正用好這些技術才能達到業務多數據中心建設的目的。
社區最近組織了交流活動，以幫助大家更好的明確理解數據中心建設，我們將活動內容總結為設計原則、技術選型和五大難點攻克，分別推送給大家。
交流分享者——本次活動專家：
孔再華 民生銀行 資料庫架構師
具有豐富的資料庫環境問題診斷和性能調優的經驗，擅長Db2 pureScale 集群產品的項目諮詢和實施，目前負責推廣資料庫同城雙活架構建設，曾經負責Db2資料庫雙活項目的設計和管理工作，有著豐富的實踐經驗。目前在社區top100關注榜中位列第6。
馮帥 點融網 高級DBA
精通Oracle、 MySQL。 擅長異構資料庫數據同步及遷移、資料庫的設計和調優。參與過oracle、MySQL資料庫的雙活項目，有豐富的經驗。
韓成亮 某金融單位 資料庫架構師
擅長資料庫的設計、性能診斷、SQL調優，熟悉異構資料庫之間的數據同步和遷移，目前從事MySQL相關的運維和架構工作。曾經設計過MySQL資料庫的雙活項目方案，有豐富實踐經驗。在社區MySQL領域聲望榜中排行第三。
還有以下會員熱心分享：
岳彩波 中能源 資料庫運維工程師
libai21 海通證券 軟體架構設計師
kernelry 賽姆科技 資料庫架構師
為什麼要做資料庫雙活？資料庫雙活的目的及意義是什麼？
在兩地三中心建設過程中，我們發現採用傳統的容災技術後，會碰到3個問題：
1. 切換時間太長，在今年同城災備演練中，即使通過自動化實現，主切備和備切主都需要花費40分鐘時間。
2. 操作風險太大，比如核心系統切換涉及到20步以上的操作步驟和上百條命令，每條命令都有出錯的可能。
3. 建設成本太高，同城機房按照1比2甚至1比1 的比例進行建設，伺服器平時完全閑置，除了一次性投入，每年還要耗費大量的維護費用。
因此相對於傳統容災方式，我們希望建設一個雙活平台，解決降低RTO時間、降低成本和降低切換風險等需求。（孔再華）
※※※
核心目的是為了業務的連續性。
在傳統數據中心中，業務系統的數據往往都是存放在一個資料庫中，這種模式的數據中心存在著一定的業務連續性風險——即如果資料庫出現故障宕機，所有與這台資料庫有連接的業務系統就會停頓，甚至會丟失數據。
資料庫雙活互為備份或者鏡像，當一個發生故障、業務自動切換到另一個，業務均會繼續運行，不受影響，且數據在故障過程中無丟失，解決了傳統單點故障問題。
其實還有其他的優點，比如容災，備份，負載等其他的RTO、RPO需求。（韓成亮）
※※※
單點故障問題的解決方法就是雙活，因為你資料庫或者操作系統或者存儲任何一方是單點的情況下，任何一方出現問題將影響整個業務的運行，所以就需要雙活來避免單點故障這個問題發生而影響業務。（kernelry）
跨數據中心資料庫雙活方案設計時應該遵循哪些原則？
如果將資料庫雙活平台作為未來的常規建設，應用越來越多的系統，那麼在建設初期，我們就要設定好平台的目標：
1、通用性：基於LUW開放平台，支持部署在任何廠商的存儲、伺服器和操作系統上。不能選擇一體機，大型機等不通用的設備。
2、無差別性： 雙中心交易對等，同城之間同時處理業務請求，無主次之分。只有這樣的系統才能面對失去單數據中心的風險。
3、高可用性：最下化降低同城切換時間，同城站點出問題不會影響全局業務。業務切換需要在最短時間內完成。
4、可維護性：基礎設置重大變更不停機，可以通過滾動升級的方式完成維護操作。
5、可遷移性：平台對業務系統透明，開發無需改動代碼，即可快速部署到該平台。同樣該平台部署的系統也可平滑遷移出來。
6、安全穩定運行，該平台可以實現5個9的運行目標。（孔再華）
※※※
網路傳輸的高效性
網路傳輸的高可用性
網路傳輸的高安全性
伺服器的高效性
伺服器的高可用性
伺服器的高安全性
資料庫的高效性
資料庫的高可用性
資料庫的高安全性
配置的最優化
資源利用最大化
最後是良好的管理性，總之一切為了高效性，高可用，高安全性，滿足業務的需求，當然還有結合你的成本考慮。（韓成亮）
做資料庫雙活方案設計有哪些工作需要考慮？
做資料庫雙活方案的設計需要考慮很多方面：
業務選型：資料庫雙活在實現雙中心對等並重的同時，也對業務系統有著苛刻的要求。因為幾十公里的延時會導致通信和存儲變慢，從而產生蝴蝶效應。所以首先要做的是明確什麼樣的業務適合上雙活。業務選型的要素：業務類型簡單，應用讀寫比高，作為新技術的驗證，最好首先從獨立性高的業務開始，不要影響其他業務。
技術選型：選好適合的業務系統後，下面考慮的是採用什麼資料庫技術。是Oracle的RAC還是DB2的pureScae集群。上線後的數據訪問時什麼樣的，是無差別的讀寫，還是需要做讀寫分離。這些都是在選擇雙活技術的考慮因素。選擇好上層資料庫產品後，還需要考慮共享文件系統的選型。在民生有DB的GDPC雙活，也有Oracle的RAC雙活。但是這兩個環境的底層共享文件系統都是選擇了GPFS。因為這裡不僅僅考慮了技術的優缺點，成熟度，還要考慮公司的運維能力。
硬體選型基礎建設：硬體選型在這個方案裡面尤其重要，是一切實現的基礎。主機採用什麼設備，X86還是P系列，網路是採用RDMA還是TCPIP，如果是RDMA，那麼是選擇RoCE還是Infiniband。存儲採用哪個廠商的信號，是否考慮SCSI-3PR的技術。雙中心建設大二層網路需要採購什麼什麼設備，和當前網路設備是否能集成公用等等。最後硬體換進過的拓撲架構是什麼樣的，怎麼做好冗餘高可用等。
運維建設：最後能上還得能玩雙活才行。運維建設很重要，完善的文檔，有經驗的運維人員，廠商支持力度才是雙活環境保駕護航的重點。（孔再華）
資料庫雙活技術該如何選型?
主流資料庫雙活技術的詳細對比
1 技術方案性能相關的對比
2 技術方案的自有特性
3 技術方案差異性
4 技術方案的優缺點
5 技術方案成本考慮
6 技術方案管理性
其實最主要的的你需要了解你的業務核心需求是什麼，一切的一切都是以業務為前提的。（馮帥）
※※※
這個技術選型要考慮很多方面： 首先是定義目標。為什麼要做雙活，覆蓋到什麼程度，將會有哪些候選應用。這些應用的特點是什麼，只需要做讀寫分離還是需要無差別雙活訪問。有了這個目標之後才是選型。如果是讀寫分離，資料庫基於日誌的同步技術或者是第三方工具來做數據複製都是沒問題的。這種模式實現也簡單，能夠快速部署上線。但是如果目標比較高，需要RPO=0，RTO分鐘級，那麼就需要選擇無差別的雙活模式，需要考慮DB2的pureScale或者是Oracle的RAC這樣的集群產品。定義好數據複製的技術後，下一步是這種方案下的基礎環境選型，採用什麼伺服器，存儲，網路，如何搭建網路，怎麼實現冗餘，各個環節的高可用配置該怎麼做。最後這個雙活的方案基本就確定了。在這個過程中還需要考慮後期的運維，人員的能力，對業務的侵入性等因素。（孔再華）
※※※
我覺得應該從業務需求入手，看看業務對雙活的真正需求是什麼，然後選擇對應的方案。
目前的技術沒有明顯的優劣，都有各自的優勢和缺點，所以一定要選擇合適的。
多數據中心數據有哪些同步方式，該如何選擇？（libai21）
※※※
多數據中心數據同步大致分為兩種方式，一種是存儲複製，一種是數據複製。
存儲複製通過存儲複製技術，將磁碟同步或者非同步複製到不同數據中心。一般同城數據中心距離較近，會採用同步的模式。同步模式會對寫操作有延遲，進而影響一部分性能。異地數據中心因為距離較遠，採用非同步模式，對本地數據訪問沒有影響。
存儲複製還分為硬體技術複製和軟體技術複製。硬體技術複製是存儲廠商提供的技術，優點是方案成熟，配置簡單，對於應用適應性強。缺點是成本高，單活，對網路傳輸壓力大。所以建議高級別的業務系統採用這種方式。軟體複製技術是使用例如LVmirror，GPFS等軟體技術來複制不同數據中心的磁碟。優點是成本低，靈活性高，缺點是配置複雜，適用性差，需要對應用當前環境停機改造，後期維護起來複雜。所以這種方式用的很少。
數據複製時通過資料庫技術或者第三方軟體實現數據中心間的數據同步。同樣數據複製也分為同步和非同步兩種模式，分別適用於短距離數據中心和長距離數據中心。數據複製可選擇性比較多，
資料庫本身提供了數據複製的技術，例如DB2的HADR，oracle的dataguard，mysql的主從同步。這些技術都屬於ActiveStandby模式，Standby可以開啟只讀，做上讀寫分離。這種方式在數據中心同步中使用非常廣泛，也是主要推薦的一種方式。出現災難切換的時候，資料庫能很快切換到其他數據中心，相對於存儲複製的冷備方式，熱備能夠大大加快切換速度，也減少了切換的未知風險。
資料庫還未第三方工具提供了日誌解析的介面，所以有很多複製工具也被用來實現數據中心的數據同步。但是這種方式通常不會用於整庫複製。而且這種第三方工具也沒有同步模式。通常是作為實時性要求不高的業務數據同步。這種工具還有個很好的優點是支持異構，可以在不同種類的資料庫間實現數據同步。
資料庫物理複製技術和工具邏輯複製技術都可以滿足不同數據中心之間數據複製。
但是各項技術各有千秋，使用場景也不一樣。
最後說說資料庫雙活的運用場景。資料庫雙活要求在兩個數據中心都能看到相同的數據，所以數據一定是同步複製的，並且都可讀寫。因此可選的複製技術並不多。存儲技術有存儲虛擬化，雙中心訪問的是最終虛擬的盤，實際底層由存儲進行複製。這種其實運用的不多，因為存儲複製也要防止腦裂的問題需要加仲裁。在腦裂的時候有可能選擇任意一邊存活。而上層資料庫集群也有腦裂問題，可能選擇另一邊存活，這就會導致底層存儲和上層資料庫選擇可能不一致，結果服務不可用。而且次方案成本也非常高。另外一種就是資料庫自帶的軟體複製技術。現在只有Oracle的RAC和DB2的pureScale集群能提供這種跨數據中心的雙活方案。Oracle有ASM，DB2有GPFS，都可以做存儲實時同步。因為這些文件系統軟體和資料庫的緊密結合，成為資料庫雙活方案的不二之選。（孔再華）
※※※
多數據中心同步數據要看方式，看用的什麼資料庫，什麼方案，Oracle的話可以用ogg等同步數據，如果是做災備數據中心的話可以用dataguard。（岳彩波）
活動地址：http://www.talkwithtrend.com/activity/?id=881
TAG:talkwithtrend |