攜程資料庫高可用和容災架構演進
作者簡介
郜德光,攜程技術保障中心高階資料庫經理,負責資料庫相關的運維工作,參與了SQL Server和MySQL的高可用以及資料庫容災建設。喜歡鑽研技術,對資料相關的技術一直保持著濃厚的興趣。
網站穩定性對任何一家公司來說都至關重要。業務長時間中斷,不僅僅意味著收入的損失,更可能會失去客戶。資料庫的穩定性和HA/DR建設是網站高可用建設非常重要的一個環節。
本文分享了攜程資料庫(SQL Server,MySQL和Redis)的高可用和容災的重構歷程,以及重構的原因。也會簡單分享一下DR切換工具,該工具可以一鍵將主站資料庫切換到DR站點,用於在主站IDC故障時,快速恢復資料庫服務。
1.0時代【1999~2008】
自攜程1999年成立到2008年左右,公司資料庫產品主要是SQL Server。
這個階段是公司初創和快速發展時期,以優先發展業務為主。資料庫的架構設計比較簡單。高可用通過資料庫的映象技術來實現。映象主要的架構如下圖所示。甚至為了節省伺服器資源,我們採用多個主資料庫共享一個輔助資料庫伺服器的方式。
這種映象方式搭建和運維都比較簡單。主機如果出現故障,先嚐試重啟能否解決,如果不能恢復,則通過映象切換的方式,切換資料庫服務到從機。
這種HA架構比較簡單、粗糙,優點是不需要群集和共享儲存等資源,成本低。缺點是主機故障時沒法自動轉移,業務恢復速度較慢,嚴格來講還不具備HA的能力。
前期對於支撐當時業務發展來說已經夠了,隨著後期業務快速發展,已經無法滿足業務穩定性的需要。
2.0時代【2008~2012】
這一階段,業務進入快速發展階段,對資料庫的依賴也越來越重。開始大量採用SAN共享儲存來存放資料。單臺數據庫已無法支撐業務的壓力,因此,也對資料庫架構進行調整,引入了複製分發,用於讀寫分離。
架構如下圖所示:產品的價格首先錄入到錄入資料庫。通過SQL Server自有的表級別的複製分發技術,把資料傳遞到多個產品資料庫,以供業務訪問。如果業務訪問壓力大,則通過新增產品查詢伺服器的方式來進行擴容。
對於非讀寫分離場景的資料庫,高可用是通過Failover Cluster群集方式。DR依舊採用資料庫映象的方式。
如下圖所示:一旦伺服器主節點硬體故障,則會通過自動故障轉移,轉移業務到服務備節點,切換時間大概在2分鐘左右。主備伺服器都連線後臺共享儲存。
同時,還對資料庫服務搭建了映象,一旦儲存發生故障,主備服務節點都不可用的情況下,則通過切換映象到映象伺服器上,映象服務本身也是一個Failover Cluster群集,也做了高可用。
由於SQL Server的映象伺服器平時是不可讀的,我們還通過一個日誌傳輸服務,搭建了只讀資料庫,以供BI取數或查詢。這個只讀資料庫也用於驗證資料庫備份的有效性。
由於業務的需求越來越複雜,資料庫的架構開始逐漸複雜起來,主要體現在:
1、複製分發架構過於複雜,如城市表,基本上所有部門都需要使用,通過拉複製分發鏈路,把城市列表資訊傳遞給其他部門的資料庫,能快速解決問題,但隨之而來,使得資料庫的關係變成蜘蛛網狀。維護起來相當困難。
2、過於依賴底層的SAN儲存。SAN儲存內含相當複雜的儲存技術和網路技術,複雜一點的問題就需要依賴供應商來解決。
2012年,微軟推出了AlwaysOn高可用性組,可以不依賴於共享儲存。AlwaysOn高可用性組同時也具備讀寫分離的功能,而且也能做容災。所以,我們逐漸朝AlwaysOn這個架構演進,並用SSD來代替SAN儲存。
3.0時代【2012~2014】
在2014年左右AlwaysON技術已經非常成熟,對於多IDC環境下支援也已經非常好,是SQL Server主流的HA/DR方案解決方法。
因此在2014年後,我們開始逐步把SQL Server改造為Always ON架構。架構如下圖所示:寫還是一個節點,但可提供多個節點的讀。並且其中的一個節點是同步模式,用於做寫節點的高可用。
純AG架構
上面新的架構非常靈活。由於2014版本已經支援8個只讀副本,AlwaysOn延遲又低,因此完全解決了群集+映象架構中遇到的複製分發讀寫分離架構瓶頸的問題,同時也不在需要為離線查詢和ETL取數部署單獨的只讀資料庫。讀副本的備份功能也大大降低了備份時主機的壓力。
在推進Always ON新架構過程中,我們也逐步用SSD來取代原有的SAN。除了SSD的價格越來越便宜容量越來越大,相比SSD,SAN儲存對DBA基本是黑盒子,需要專業的運維團隊支援,運維成本更高。
4.0時代【2014~2018】
SQLServer AlwaysON技術比較成熟,但其存在一個關鍵的問題,在於AlwaysON技術是閉源的。DBA難以深入瞭解該技術的底層細節。雖然脫離了SAN儲存的依賴,但還是依賴於Windows的Failover Cluster叢集。
因此,2012年開始在攜程內部逐步推廣開源的MySQL和Redis 。在推廣MySQL的時候,我們意識到MySQL的效能比不上SQL Server, 所以同時推廣資料庫分庫分表方案和前端Redis快取。
MySQL的高可用和DR是通過MHA(Master High Availability)來實現的。具體架構如下:
通過MHA管理節點,來監聽主節點的可用性情況,一旦發現主機不可訪問,則切換到slave節點。MHA的高可用模式,既兼顧到高可用,也兼顧到DR。對於讀寫分離的需求,主要是通過分庫分表方案來進行的。部分有采用讀寫分離。
對於MHA的方式,是通過域名/虛擬IP的方式,提供給業務使用。其最大的風險的是腦裂。主機沒完全掛死,同時主從切換後,新的主機開始提供業務訪問,就產生了腦裂。為了解決這個問題,我們在資料庫訪問層,引入了動態資料來源技術,不通過域名/虛擬IP的方式,而是通過實IP的方式。提供業務訪問,有效的降低了腦裂的風險,同時不通過域名解析,能加快主從/DR切換時間。
隨著MySQL的引入,Redis也逐漸廣泛使用起來。由於Redis的Key/Value訪問速度非常快,目前攜程對Redis的依賴比對資料庫還重要。Redis本身需要有高可用和DR的方案。
對於Redis,藉助框架部門開發的中介軟體CRedis,用於Redis的訪問和高可用控制。
簡要架構如下圖所示:
說明如下:
1、業務訪問的時候,通過引用框架的客戶端元件讀取配置資訊。Redis切換由哨兵發起,並且Credis配置能及時捕獲,並通知客戶端IP和埠的變化。
2、對Redis拆分多個Group,以避免訪問熱點。每個Group包含多個Redis例項。
3、Redis例項Master/Slave在一個機房, 另外兩個例項Slave-DR在另個機房。
4、訪問請求通過CRedis配置路由到指定的分片。
5、Slave-DR例項和主例項的資料同步通過框架同步工具XPipe來實現。XPipe 已經開源,更多資訊請訪問:https://github.com/ctripcorp/x-pipe。
為應對日常DR演練以及硬體故障時快速恢復業務的場景,DBA設計開發了集中、一鍵式DR自動化切換工具,支援所有資料庫產品。用來幫助DBA快速、安全的完成資料庫切換。
DR切換工具支援不同的切換維度,覆蓋了所有的場景:
1、單個或多個數據庫群集,應對單機故障或日常維護等場景;
2、單個業務線下所有資料庫群集,應對DR切換演練場景;
3、IDC下所有資料庫群集,應對主IDC故障場景;
目前為止已經利用DR工具成功完成了200+次的切換演練。下面是用DR工具準備單群集切換的一個例子:
如上圖所示,工具中搜索到對應的群集後,工具會根據元資料資訊展示群集的整體架構:節點(名字、IP地址等)、IDC、複製關係。
每個節點提供2種切換方式:
1、強切工單,強制切換。主機或主站down時,可能有資料丟失;
2、演練工單,正常切換。主機可用時,演練或計劃內主機維護時使用;
生成的工單後續可以自動執行。
DBA把DR複雜的切換恢復流程全部整合工具裡面,工具同時支援API根據不同維度快速批量生成切換工單,支援併發切換,可以快速完成業務的切換恢復。
為保證DR工具的高可用性,在設計DR工具時也消除了工具對單個IDC的依賴。只要保證一個IDC可用,就可以通過工具發起切換。
從以上架構的演變過程,我們可以看到是從簡單 à 複雜 à 簡單的一個演變趨勢,但是穩定性和可用性有了質的飛越。 資料層本身變得越來越簡單,而擴充套件了大量的輔助架構,來提升自動化運維能力。
希望以上的分享對大家有所幫助。
【推薦閱讀】
-
ofollow,noindex"> 攜程機票日誌追蹤系統架構演進
11月23日上海,
攜程首屆技術峰會,
一起來聚~
戳下圖瞭解詳情
↓↓↓