雲原生趨勢下的容災架構演進之路

語言: CN / TW / HK

業務發展,“穩”字先行!

當今,數字化轉型已經駛入快車道,同時受到疫情常態化的影響,企業構建IT系統容災能力,既是保障自身業務發展的需要,也是承擔社會責任實際要求。

容災方案發展階段

回顧企業容災方案的發展,通常有這樣四個階段:

1、數據冷備:實現簡單,無需業務改造;

2、在線熱備:因為冷備只備了數據,故障恢復時需把應用服務部署起來,恢復時間較久;常態下熱備服務不提供在線訪問,導致資源大量浪費,且可靠性難保障;

3、同城雙活:相比於異地多活,實現起來較為簡單,業務改動較少,可提供在線服務,讓資源有效利用,故障恢復時間比較短;

4、異地多活:多活實現比較複雜,需要業務做Set化的改造,同時運維也較為複雜,但優勢明顯——故障恢復時間非常短。

那麼,有沒有一種方案,可以避免投入過多資源,減少業務改造,並且維持較低的運維成本,同時縮小故障恢復時間呢?

騰訊雲通過分析眾多客户實踐與案例發現,同城雙活已經能夠滿足絕大多數客户容災的需求。結合內外部不同階段用户的容災架構落地經驗, 騰訊雲總結提煉了一套以低成本為核心的雲原生容災解決方案,解決了不同行業、不同階段客户的容災場景,如同城雙活、兩地三中心、跨雲多活、跨雲災備、混合雲等。

詳解騰訊雲原生同城雙活方案

在2022年1月7日舉辦的TOP100Summit上,騰訊雲泛互聯網行業首席解決方案架構師邱浩,詳細介紹了騰訊雲原生同城雙活方案。

在接入層,騰訊雲負載均衡CLB產品在跨可用區做主備部署,單可用區出現故障的時候,流量不受影響,外網流量引入到備可用區。負載均衡器在非常短的時間(約30秒)內,即可切換到備可用區恢復服務。主可用區恢復之後,CLB能夠探測到並自動把流量恢復到主可用區。整個切換不需要人工操作,故障恢復時間比較短,一般分鐘級就能夠恢復。

值得注意的是,負載均衡器只有主可用區不可用的時候,才會切換到備可用區,而不是出現一個故障就會整體切換,因為整體可用區的切換會對業務帶來較大的影響。

在數據層,保障數據一致性和可靠性至關重要。邱浩詳細介紹了騰訊雲數據庫MySQL容災方案的最佳實踐。在數據一致性方面,通過強同步策略,保證數據一致性;同時,通過內核修改和優化,提升TPS的吞吐能力。在高可靠方面,騰訊雲數據庫實現了整條鏈路的可靠性保障,即使用户選擇了第一和第二個可用區來部署數據庫的實例,雲數據庫會在不可見的第三個可用區也部署探測節點,實時探測MySQL主節點與備節點運行狀況,真正做到在一個可用區或者網絡分區,把故障剔除掉,保證數據庫可靠性。在低成本方面,一般來説核心數據庫高可用是一主兩備、部署在同一個可用區,在升級為跨可用區部署的時候,在後台可以把兩個備庫其中的一個移到備可用區,這樣對於成本來説是零增加。此外,發生故障之後,雲數據庫MySQL讀寫訪問的IP完全不需做變更,應用層不需重新發版,也毋需通過中間件修改訪問IP,整個故障切換和恢復都由雲數據庫後台自動完成,免去用户手工恢復環境的代價。

接下來,邱浩還詳細介紹了雲上緩存數據庫Redis是如何實現故障還原、高可用性。一般來説,業務對於緩存數據庫Redis的訪問性能要求比較高,比如一次請求只有0.1毫秒,但是跨可用區訪問的網絡延時大約需要1毫秒,於是讀取大量緩存的時候就會有性能損耗。通過騰訊雲網絡就近接入能力,使應用層感知到本可用區Redis部署在哪裏,在讀取的時候優先就近訪問本可用區的副本節點,這樣無論是從哪個可用區讀取時,都是在訪問本可用區的副本。這樣就提供了一種本地訪問體驗,並且降低了請求的耗時。此外,雲上產品還將Redis內核需求化,切換時能夠指定從庫權重。

如果是自建Redis,就需要應用每一台應用客户端,實現就近感知的能力。由每一台客户端探測Redis所有的副本時延情況,選擇一個最低網絡時延副本分發流量。而云上,通過網絡、網關,路由器可以自動學習,感知到它的網絡就近路由信息,不需要應用程序再做額外探測。

對於極致可用性的場景,可以把數據庫副本分散在三個可用區。當一個可用區主節點發生故障時,還有兩個可用區有容災能力。這樣的好處是增強了可用區能力,缺點則是需要更多的資源投入。

接下來,邱浩詳細介紹了騰訊雲數據庫MongoDB容災方案、騰訊雲消息列隊Kafka容災方案、Elastic Search容災方案、COS容災方案。其中, 騰訊雲數據庫MongoDB 能夠實現自動選主協議。雲產品實現邏輯與社區版本類似,但是進一步優化了內核鎖粒度。 Mongo一定要部署到三個可用區,避免單個可用區出現故障的情況。同時,Mongo在雲上也有就近接入的特性。

騰訊雲原生同城雙活案例

之後,邱浩通過一個案例詳細介紹了騰訊雲如何實現單可用區升級為雙可用區雙活架構:國內某領先電商SaaS平台,其業務需求全部部署在公有云單可用區。一旦出現可用區故障,發生服務中斷,就會影響其上百萬商家與上億買家。由於此電商平台業務資源數量眾多,如果使用熱備方案,成本浪費比較嚴重。同時,由於該平台使用了大量的數據層或中間件服務,如果完全依靠自身做改造,需要投入非常大的精力;另外,數據同步與環境管理的代價也比較高。

平台使用騰訊云云原生同城雙活方案之後,由於雙可用區都是百分之百承接流量,資源有效利用,業務毋需改造,運維代價大大降低,故障恢復時間也降為分鐘級。


解決架構升級的挑戰

在架構升級時會遇到一些挑戰:老的業務會面臨流量二次穿越問題,這就造成了兩個可用區之間的網絡延時;經過多次二級流量穿越之後,就會導致訪問時延在極端情況下放大十數倍,影響業務性能。 通過智能流量調度方案,可以實現http和rpc流量就近訪問本可用區。

除了這些基礎保障,更加重要的是如何保障整個雙活容災可靠性。以數據庫容災為例,如果是主庫故障,管控就會探測到數據實例故障,然後觸發HA切換,更新數據庫路由信息;網絡管控獲取路由存放的數據庫地址,更新正確的數據庫路由信息。更新之後會下發到對應可用區的備庫實例上,對應的可用區路由信息更新,將VIP舊的路由信息擦除掉,使路由信息指向新的主庫,完成整個切換。 如圖所示,每層組件都在不同可用區做了多副本,真正實現整個鏈路的可靠性與容災能力。

在完成雙活部署或驗證之後,還要做真實的多輪容災演練,以確保核心業務整體架構具備真正的容災能力。 在經過多輪演練之後,效果符合預期,驗證完成。以上就是將單可用區的架構,升級為多可用區的全過程。

騰訊雲兩地三中心案例

接着邱浩為大家帶來雙活架構之後的演進介紹:如何實現兩地三中心架構。

如圖所示,依據上面的闡述,左側廣州六區和四區可以實現同城雙活。如果跨地域的話,需要做一個接入跟應用的熱備部署,平時不承載流量。數據層做一個災備同步,部署在跨地域,這樣便可以實現兩地三中心的架構。

傳統方案中,異地災備最難的就是網絡抖動問題,尤其是redis跨地域複製,是落地的一大卡點。這是因為Redis原生代碼在跨地域複製的場景中無法保證目的端實例服務的可用性,在寫入量過大或者長時間斷開復制的情況下,Master節點的backlog可能無法滿足斷點複製日誌的續傳,導致目標節點必須進行全量複製。在全量複製數據同步的過程中,目標節點不能提供訪問,因此無法保障服務的可用性,詳情可參考redis官方文檔。

騰訊雲Redis支持全球複製功能,能夠完全兼容Redis4.0和5.0,全球複製版本在保障性能前提下優化了複製的日誌數據,使得Redis可以進行跨地域複製。斷點續傳避免跨地域網絡抖動導致的同步問題,消除兩地三中心落地的卡點。

分佈式雲TDCC
解決多雲及混合雲趨勢下的容災挑戰

多雲環境下,如何在充分利用雲上彈性伸縮能力?如何避免業務被單一雲廠商綁定?如何治理多雲及混合雲環境下的應用?如何低成本實現跨雲或混合雲雙活?

騰訊雲分佈式雲TDCC可以解決這些難題。如圖所示,跨雲雙活案例:客户的業務接入層和應用層服務獨立部署在騰訊雲和其他雲上,數據通過專線實時同步。藉助騰訊雲TDCC產品,統一管理不同雲上的容器應用集羣。不同容器集羣註冊到TDCC,管理人員通過K8S API或TDCC控制枱,統一發布應用到兩朵雲,實現跨雲雙活部署,無需改造現有業務發佈流程,又充分利用雲上資源彈性,避免技術綁定。 TDCC可以管理多雲、多IDC的容器應用集羣,實現一次發佈全球運行。

容災注意事項

最後,邱浩對容災過程中需要注意的事項進行了總結。包括明確容災目標、容易忽略的問題、定期演練等。

容災是個複雜的話題,業務在不同發展階段組合多種技術棧,進一步增加了容災的複雜度。在傳統容災方案下,需要研發人員投入大量人力和資源實現容災。現在,藉助雲原生技術,可以低成本的實現高可靠的容災架構,既能滿足業務的容災需求,又能兼顧技術的發展趨勢。