数仓集群管理：单节点故障 RTO 机制分析

​​​​摘要：大规模分布式系统中的故障无法避免。发生单点故障时，集群状态和业务是如何恢复的？

本文分享自华为云社区《数仓集群管理：单节点故障RTO机制分析》，原文作者：CloudGanker 。

一、前言

GaussDB(DWS)产品采用分布式架构设计。集群管理（高可用）需要在稳定性和灵敏性之间做好平衡。

集群发生单节点故障（如宕机、断网、下电等）时，端到端业务恢复的 RTO (Recovery Time Objective)流程和指标，主要包含两大过程：集群状态恢复（CM Server 主备倒换，DN/GTM 主备倒换）和业务恢复（CN 可正常执行业务）。

本文关注集群状态恢复部分，剩余部分后续单独分析。

参考链接：

GaussDB(DWS) 集群管理系列：CM组件介绍（架构和部署形态）

GaussDB(DWS) 集群管理系列：CM组件介绍（核心功能）

二、假设条件和关键配置参数

通常情况下故障 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++语言中乘法和除法不满足结合律，本文涉及运算均为整数运算。

三、集群拓扑示例

忽略 CN 的部署，以下图所示的三节点集群为例：

• 两个 cm_server 实例，主备分别部署在节点 1 和节点 2

• 两个 GTM 实例，主备分别部署在节点 1 和节点 2

• 一组 DN 实例，主备从分别部署在节点 1，节点 2 和节点 3

• 每个节点上均部署 cm_agent 组件

​四、整体流程分析

当节点 1 故障，集群将短时间处于不可用状态，然后自动恢复至降级状态，随后可在 CN 上正常执行业务。因此，RTO 流程的讨论可分为四个阶段。

1.单节点故障发生，集群处于不可用状态，cm_server/GTM/DN 处于无主状态

​2.cm_server 备机升主，GTM/DN 等待仲裁

​3.GTM/DN 备机（并行）升主，集群恢复至降级状态

​4.    CN 链接至 GTM 和 DN，正常执行业务

以故障发生时刻为 0 时刻点，下面逐个分析每个阶段并计算相关时间。

五、CM Server 备机升主

单节点故障发生后，集群管理组件出于稳定性考虑，并不会立刻感知故障状态。两个 cm_server 实例之间通信时，根据心跳判断对方的存活状态。如果二者间心跳超时，则进入如下的自仲裁流程（对端链接均指与另一个 cm_server 的链接）。

两次自仲裁轮询之间的睡眠时间固定为 11 秒，心跳超时的阈值为 T_{\rm cms\_hb}=\frac{T_{\rm hb}}{2}Tcms_hb​=2Thb​​，建立链接（包括 cm_server 之间的链接以及 cm_agent 与 cm_server 的链接）的超时时间阈值为 T_{\rm cms\_conn}=\frac{T_{\rmcms\_hb}}{2}-1Tcms_conn​=2Tcms_hb​​−1. 如此设定阈值的原因是，忽略代码的执行时间，当心跳超时判定为真时，cm_server 之间至少可尝试两次建链，而 cm_agent 可与两个 cm_server 均尝试建立链接。

备 cm_server 升主流程和各阶段相应最大耗时为：

1.     判定心跳超时，假定通信即时感知对端故障，可能多等待一次建链超时和睡眠，耗时 T_{\rm cms\_hb}+T_{\rmcms\_conn}+1=\frac{3T_{\rm cms\_hb}}{2}Tcms_hb​+Tcms_conn​+1=23Tcms_hb​​

2.     自仲裁升主的预升主阶段，根据假设，此时 cm_agent 已经发起过预链接，因此直接可预升主并重置心跳，耗时 00

3.     第二次判定心跳超时，耗时 T_{\rm cms\_hb}+T_{\rmcms\_conn}+1=\frac{3T_{\rm cms\_hb}}{2}Tcms_hb​+Tcms_conn​+1=23Tcms_hb​​

4.     自仲裁升主的正式升主阶段，cm_agent 已经发起正式链接，因此正式升主，耗时 00

综上，总的最大耗时为\frac{3T_{\rm cms\_hb}}{2}×2=\frac{3T_{\rmhb}}{4}×223Tcms_hb​​×2=43Thb​​×2。（注意这里是整数运算。）

六、DN/GTM 备机升主

集群管理的仲裁采用被动触发的形式。每个 cm_agent 检测所在节点的实例状态，并定期上报（固定间隔 1 秒）至主 cm_server；主 cm_server 综合各实例状态进行仲裁，然后将必要的仲裁结果发送至相关 cm_agent；cm_agent 收到仲裁结果，执行相应的命令。

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

① CM Agent 1 探测 DN 主实例并发现故障

② CM Agent 1 持续上报实例故障信息至 CMServer

③ CM Server 执行仲裁流程，选择 DN 备机升主

④ CM Server 下发升主命令至 CM Agent 2

⑤ CM Agent 2 对实例执行升主操作

对于单节点故障，DN 和 GTM 实例的仲裁可同时进行，分步骤的时间如下：

1.     cm_server2 升主后，无法收到 cm_agent1 上报的消息，达到超时时间 T_hb 后将 DN1 和 GTM1 的状态强行置为 Down，耗时 T_{\rm hb}Thb​

2.     cm_server2 不断收到 cm_agent2 上报 DN2 和 GTM2 为备机的消息，分别下发 failover 命令执行升主，耗时 11 秒

3.     cm_agent2 收到 failover 命令，（轮询间隔）耗时 0.20.2 秒（按照 11 计算）

4.     cm_agent2 执行 failover，耗时 T_{\rm failover}Tfailover​

5.     cm_agent2 检测到 DN2 和 GTM2 升主成功，耗时 11 秒

6.     cm_agent2 上报 DN2 和 GTM2 为主机的消息，（轮询间隔）耗时 0.20.2 秒（按照 11 计算）

7.     cm_server2 收到 DN2 和 GTM2 已升主的消息，更新集群状态为降级，耗时 00 秒

综上，总耗时为 T_{\rm hb} + T_{\rm failover} +4Thb​+Tfailover​+4.

七、小结

将 CM Server 自仲裁和 DN/GTM 仲裁的时间相加，即为集群状态恢复的耗时（单位：秒）

T_{\rm cluster} = \frac{3T_{\rmhb}}{4}×2 + T_{\rm hb} + T_{\rm failover} + 4 \approx \frac{5T_{\rm hb}}{2} +T_{\rm failover} + 4 \text{（按照实数运算近似）}Tcluster​=43Thb​​×2+Thb​+Tfailover​+4≈25Thb​​+Tfailover​+4（按照实数运算近似）

按照默认值计算，集群状态恢复的理论时间 T_{\rm cluster} = 84Tcluster​=84.

由于分析过程均按最大时间计算，所以理论时间相比实际会有放大。通常情况下，cm_server 判定心跳超时无需多等待一次链接超时，cm_agent 探测实例状态几乎是即时的。因此，实际发生故障时，（按照默认值）cm_server 自仲裁时间约为 T_{\rm hb} = 30Thb​=30，DN/GTM 备机升主时间约为 T_{\rm hb} + T_{\rm failover} =35Thb​+Tfailover​=35，从而集群恢复时间大约为 6565 秒。

用户可根据自身情况，通过调整 instance_heartbeat_timeout 参数选择合适的 RTO 指标。

点击关注，第一时间了解华为云新鲜技术~