巨杉金融級數據庫多活架構實踐
此外，在半年時間內，多個平臺也曾出現數據安全問題。7月24日，由於某雲廣州一區主備兩條運營商網絡鏈路同時中斷，導致部分用戶出現資源訪問失敗、控制臺登錄異常。7月18日，某雲全球負載均衡系統出現問題，導致Snapchat等多個熱門在線服務遭遇停機或者響應緩慢情況。6月27日，某雲運維失誤，導致一些客戶訪問阿裏雲官方控制臺出現問題。4月6日，某訪問出現問題……
而伴隨數據在企業內部價值的不斷提升，數據已經成為了企業的生命線與核心資產。無論在中國還是海外，金融行業的數據安全已經成為了監管機構的首要要求。在中國，銀行核心系統安全一直是我國銀監會所關註的重點，對於大部分銀行數據中心，監管機構目前提出了對於數據安全和數據高可用的“兩地三中心”以及“雙活”的能力。
“兩地三中心”即生產數據中心、同城災備中心、異地災備中心建設方案。這種模式下，兩個城市的三個數據中心互聯互通，如果一個數據中心發生故障或災難，其他數據中心可以正常運行並對關鍵業務或全部業務實現接管。如今，一些大型銀行，甚至已經實現了“三地五中心”。“雙活”數據中心就是同個城市部署兩個數據中心，多活一方面是多中心之間地位均等，正常模式下協同工作，並行的為業務訪問提供服務，實現了對資源的充分利用，避免一個或兩個備份中心處於閑置狀態，造成資源與投資浪費；二是在一個數據中心發生故障或災難的情況下，其他數據中心可以正常運行並對關鍵業務或全部業務實現接管，實現用戶的“故障無感知”。
數據庫多活方案對比
隨著眾多企業客戶對於業務延續性需求的增加，傳統業務中的停機維護窗口越來越小，甚至在很多互聯網類型的應用中要求24x7不間斷服務，導致系統對於數據庫的運維能力、持續服務能力、高可用能力以及災難恢復能力都有著新的需求。
其中，數據庫的多活架構從RTO/RPO，乃至對業務中間件的任務分發來說都至關重要。在傳統多站點主從架構的環境中，往往業務中間件需要了解不同數據中心的角色，確保讀寫操作永遠被導向主站點，而一些允許異步訪問的只讀類業務可以由備中心完成。但是，在一個復雜的業務環境中，這種構建方式往往會使得業務模型極度復雜，在進行主備中心切換時也會涉及到很多配置的調整。
其中，Oracle的RAC一般坐落在單數據中心內，以共享磁盤為基礎，上層通過搭建多個Oracle運行實例，共同連接到一個SAN中，所有的事務控制、鎖等待等機制都通過高速網絡在數據中心內的多個Oracle實例之間共享。
圖1：Oracle RAC抽象架構
而IBM的GDPS則是更加標準的多活架構。通過在多個數據中心內搭建IBM DB2 for z/OS數據庫，並且在數據庫之間通過QRep進行數據復制，輔以上層的Workload控制器進行任務分發，實現應用程序在多個站點之間的數據庫中做到多活。
傳統數據庫的一些應用程序層面的多活架構，可以通過對業務進行切分完成。例如，存在於北京和上海數據中心的數據庫可以分別負責北方與南方用戶的賬戶維護，同時上海和北京的數據中心可以互相做對方數據中心的災備節點，這種架構也是比較典型的應用程序邏輯切分的多活模型。
不論是Oracle的RAC、IBM的GDPS、還是應用程序的業務切分，其核心設計理念基本都是基於傳統集中式數據庫的架構進行設計並實現的。但是，在分布式數據庫的領域，其多活設計思路與傳統架構設計相比更加優秀。
由於大部分分布式數據庫都秉承著計算存儲分離的設計思路，因此其SQL解析與執行器往往與數據存儲和事務控制分別運行在不同的進程中。在這種情況下，利用數據庫自身分布式與三副本復制的特性，將數據打散放置在多個數據中心內，每個數據中心配置本地SQL服務節點，從應用程序的角度看不需要關註底層數據庫的主從架構，僅需要通過JDBC連接到本地的SQL服務節點進行讀寫操作即可。
在這種架構下，每個SQL節點完全對等，並均可以處理讀寫操作。所有的事務控制、一致性控制、鎖等待等機制都由底層的分布式數據庫直接提供。
圖2：分布式數據庫的存儲、計算（SQL）分離架構示意
通過該機制，整個集群同樣可以提供秒級的RTO與RPO能力，同時對於應用程序來說並不需要關心後臺數據庫的主備配置，僅需要簡單連接到本地的MySQL服務節點即可像使用傳統數據庫一樣使用多活分布式數據庫。
金融分布式數據庫災備多活實踐
SequoiaDB已經在內部實現了容災備份以及“雙活”的機制，主要特點包括：
?異地容災：異地的容災和備份，保證數據安全，中心間距離超過1000km以上。滿足金融機構“兩地三中心”的監管需求。
?同城雙活：同城雙中心的數據準實時同步，保證數據一致；雙中心數據可以實現同時讀寫，大大提升讀寫效率；中心切換RTO 小於 10分鐘。
?數據壓縮機制：節約帶寬資源，加快同步和備份過程。
?更便捷的災備管理：系統集群中統一管理災備中心，簡化了維護成本，也幫助使用者更快上手。
圖3：SequoiaDB異地多活架構示意圖
針對某大型銀行企業，巨杉分布式數據庫為其數據庫實現了異地災備的架構，以下就以實際業務對改方案進行簡單的介紹。
1.災備架構
該架構是基於SequoiaDB的三副本方案構建的同城災備，其中兩副本部署在本機生產環境中，一副本部署在災備環境中，整個集群跨越生產環境與災備環境兩個機房。為了保證災備環境與生產環境的數據保持實時一致，開啟巨杉數據庫中數據同步強一致性的功能。
開啟數據同步強一致性後，每次進行數據更新時，只有當存活的節點全部同步完成後，應用端才回收到更新成功的返回，這樣就能在最大程度上保證了數據不丟失。
圖4：同城災備物理部署架構圖
在同城災備的基礎上，在異地機房單獨部署一套SequoiaDB集群作為異地災備集群。異地集群只保持單副本，兩地間結構化數據的同步通過傳輸同城災備集群日誌到異地災備集群，然後通過重放日誌記錄的方式實現結構化數據的同步。
圖5：異地容災部署架構圖
- 災難應對
1）單節點故障應對
由於采用了三副本高可用架構，個別節點故障情況下，數據組依然可以正常工作。針對個別節點的故障場景，無需采取特別的應對措施，只需要及時修復故障節點，並通過自動數據同步或者人工數據同步的方式去恢復故障節點數據即可。
圖6：單節點故障情況
2）本地生產環境整體故障應對
當生產環境機房出現整體故障時，整個集群環境將會失去三分二的節點，如果從每個數據組來看，相當於每個數據組有兩個數據節點出現了故障，存活的節點只剩余一個。當這種情況發生時，如果不采取任何措施，災備環境中存活的節點，只能為業務提供查詢功能。
當這種場景發生時，為了讓使災備環境中的一個副本繼續提供讀寫服務，這時需要使用SequoiaDB的集群Takeover功能，把災備環境中的集群分裂成單節點集群，這時災備環境節點均可提供讀寫服務。分裂集群的耗時相對比較短，一般在十分鐘內便能完成。
圖7：本地環境故障應對示意
其中分裂集群之後，不可再啟動生產集群的兩個副本，需要使用SequoiaDB的合並集群功能後才能進行啟動，否則將出現腦裂，即生產集群也開始提供數據更新服務。將造成生產集群和災備集群兩個數據版本，很難將兩者合並。
3）災備環境整體故障應對
當災備環境出現整體故障時，由於每個數據組都有兩個副本部署在生產環境中，每個數據組存活節點的數量還大於每個數據組的總節點數，所以每個數據組仍然能夠為應用層提供讀寫服務。針對災備環境整體故障的場景，無需采取特別的應對措施，只需要及時修復故障節點，並通過自動數據同步或者人工數據同步的方式去恢復故障節點數據即可。
圖8：災備環境故障恢復示意
4）網絡故障應對
當同城網絡出現故障，導致本地環境與災備環境無法進行通信時，由於采用了三副本的架構，應用程序可以通過訪問本地兩副本集群。針對同城網絡的故障場景，無需采取特別的應對措施，只需要及時修復網絡故障，修復後通過自動數據同步或者人工數據同步的方式去恢復災備節點的數據即可。
圖9：網絡故障恢復示意圖
該用戶的影像平臺采用了同城雙活架構，每個數據組都有兩個節點落在主機房中，另外一個節點落在災備機房中。在數據同步方面，使用了SequoiaDB提供的節點強一致性的功能，當數據寫入主節點時，數據庫會確保節點間的數據都同步完成後才返回，這樣即使在主機房發生整體災難時也能有效得保證數據的完整性與安全性。由於當主機房整體出現故障時，可以使用SequoiaDB數據庫提供的分裂功能在數分鐘內快速地把災備機房中的單一副本分裂成獨立的集群為業務提供服務，因此RTO幾乎接近零。由於SequoiaDB開啟了節點數據強一致性的功能，因此RPO也幾乎接近零。
小結
在金融級強監管的要求之下，無論是“兩地三中心”還是數據的容災備份等等要求，使得金融級的分布式數據庫不斷的在數據安全方面進行新的創新。
未來，分布式數據庫作為數據管理的最核心樞紐，也將不斷提高數據安全、數據可用性方面的功能。通過雙活、多活以及高可用災備等機制不斷創新，數據庫安全將會提升一個新的臺階。
巨杉金融級數據庫多活架構實踐