數倉集羣管理：單節點故障RTO機制分析

摘要：大規模分佈式系統中的故障沒法避免。發生單點故障時，集羣狀態和業務是如何恢復的？

本文分享自華爲雲社區《GaussDB (DWS) 集羣管理系列：單節點故障RTO機制分析（集羣狀態恢復篇）》，原文做者：CloudGanker 。

1、前言

GaussDB(DWS)產品採用分佈式架構設計。集羣管理（高可用）須要在穩定性和靈敏性之間作好平衡。

集羣發生單節點故障（如宕機、斷網、下電等）時，端到端業務恢復的RTO (Recovery Time Objective)流程和指標，主要包含兩大過程：集羣狀態恢復（CM Server主備倒換，DN/GTM主備倒換）和業務恢復（CN可正常執行業務）。

本文關注集羣狀態恢復部分，剩餘部分後續單獨分析。

參考連接：

GaussDB (DWS) 集羣管理系列：CM組件介紹（架構和部署形態）
GaussDB (DWS) 集羣管理系列：CM組件介紹（核心功能）

2、假設條件和關鍵配置參數

一般狀況下故障CN自動剔除的觸發時間較長（默認10分鐘），所以本文不涉及CN剔除和實例修復的流程，也不討論CN故障時DDL業務的中斷。

假設以下：

1. 除明確故障外（如節點已經宕機），連接可在超時時間內成功創建（即創建連接時間按超時時間計算）
2. 消息傳遞不消耗時間
3. DN/GTM執行failover時間不超過 T_{\rm failover}Tfailover​ （一般小於5秒）

關鍵配置參數以下：
【CM側配置參數】實例心跳超時instance_heartbeat_timeout（默認30秒）, 後續用 T_{\rm hb}Thb​ 表示。

說明：因爲C/C++語言中乘法和除法不知足結合律，本文涉及運算均爲整數運算。

3、集羣拓撲示例

忽略CN的部署，如下圖所示的三節點集羣爲例：

• 兩個cm_server實例，主備分別部署在節點1和節點2
• 兩個GTM實例，主備分別部署在節點1和節點2
• 一組DN實例，主備從分別部署在節點1，節點2和節點3
• 每一個節點上均部署cm_agent組件

4、總體流程分析

當節點1故障，集羣將短期處於不可用狀態，而後自動恢復至降級狀態，隨後可在CN上正常執行業務。所以，RTO流程的討論可分爲四個階段。

1）單節點故障發生，集羣處於不可用狀態，cm_server/GTM/DN處於無主狀態

2）cm_server備機升主，GTM/DN等待仲裁

3）GTM/DN備機（並行）升主，集羣恢復至降級狀態

4）CN連接至GTM和DN，正常執行業務

以故障發生時刻爲0時刻點，下面逐個分析每一個階段並計算相關時間。

5、CM Server備機升主

單節點故障發生後，集羣管理組件出於穩定性考慮，並不會馬上感知故障狀態。兩個cm_server實例之間通訊時，根據心跳判斷對方的存活狀態。若是兩者間心跳超時，則進入以下的自仲裁流程（對端連接均指與另外一個cm_server的連接）。

6、DN/GTM備機升主

集羣管理的仲裁採用被動觸發的形式。每一個cm_agent檢測所在節點的實例狀態，並按期上報（固定間隔1秒）至主cm_server；主cm_server綜合各實例狀態進行仲裁，而後將必要的仲裁結果發送至相關cm_agent；cm_agent收到仲裁結果，執行相應的命令。

以某個主 DN 故障爲例，一次典型的仲裁流程包括：

① CM Agent 1探測DN主實例並發現故障
② CM Agent 1持續上報實例故障信息至CM Server
③ CM Server執行仲裁流程，選擇DN備機升主
④ CM Server下發升主命令至CM Agent 2
⑤ CM Agent 2對實例執行升主操做

對於單節點故障，DN和GTM實例的仲裁可同時進行，分步驟的時間以下：

7、小結

將CM Server自仲裁和DN/GTM仲裁的時間相加，即爲集羣狀態恢復的耗時（單位：秒）

用戶可根據自身狀況，經過調整instance_heartbeat_timeout參數選擇合適的RTO指標。

 

點擊關注，第一時間瞭解華爲雲新鮮技術~