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

举报
CloudGanker 发表于 2021/03/13 14:21:11 2021/03/13
【摘要】 大规模分布式系统中的故障无法避免。发生单点故障时,集群状态和业务是如何恢复的?

一、前言

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 f a i l o v e r T_{\rm failover} (通常小于5秒)

关键配置参数如下:
【CM侧配置参数】实例心跳超时instance_heartbeat_timeout(默认30秒), 后续用 T h b T_{\rm hb} 表示。

说明:由于C/C++语言中乘法和除法不满足结合律,本文涉及运算均为整数运算。

三、集群拓扑示例

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

  • 两个cm_server实例,主备分别部署在节点1和节点2
  • 两个GTM实例,主备分别部署在节点1和节点2
  • 一组DN实例,主备从分别部署在节点1,节点2和节点3
  • 每个节点上均部署cm_agent组件

image

四、整体流程分析

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

  1. 单节点故障发生,集群处于不可用状态,cm_server/GTM/DN处于无主状态
    image
  2. cm_server备机升主,GTM/DN等待仲裁
    image
  3. GTM/DN备机(并行)升主,集群恢复至降级状态
    image
  4. CN链接至GTM和DN,正常执行业务

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

五、CM Server备机升主

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

image

两次自仲裁轮询之间的睡眠时间固定为 1 1 秒,心跳超时的阈值为 T c m s _ h b = T h b 2 T_{\rm cms\_hb}=\frac{T_{\rm hb}}{2} ,建立链接(包括cm_server之间的链接以及cm_agent与cm_server的链接)的超时时间阈值为 T c m s _ c o n n = T c m s _ h b 2 1 T_{\rm cms\_conn}=\frac{T_{\rm cms\_hb}}{2}-1 . 如此设定阈值的原因是,忽略代码的执行时间,当心跳超时判定为真时,cm_server之间至少可尝试两次建链,而cm_agent可与两个cm_server均尝试建立链接。

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

  1. 判定心跳超时,假定通信即时感知对端故障,可能多等待一次建链超时和睡眠,耗时 T c m s _ h b + T c m s _ c o n n + 1 = 3 T c m s _ h b 2 T_{\rm cms\_hb}+T_{\rm cms\_conn}+1=\frac{3T_{\rm cms\_hb}}{2}
  2. 自仲裁升主的预升主阶段,根据假设,此时cm_agent已经发起过预链接,因此直接可预升主并重置心跳,耗时 0 0
  3. 第二次判定心跳超时,耗时 T c m s _ h b + T c m s _ c o n n + 1 = 3 T c m s _ h b 2 T_{\rm cms\_hb}+T_{\rm cms\_conn}+1=\frac{3T_{\rm cms\_hb}}{2}
  4. 自仲裁升主的正式升主阶段,cm_agent已经发起正式链接,因此正式升主,耗时 0 0

综上,总的最大耗时为 3 T c m s _ h b 2 × 2 = 3 T h b 4 × 2 \frac{3T_{\rm cms\_hb}}{2}×2=\frac{3T_{\rm hb}}{4}×2 。(注意这里是整数运算。)

六、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对实例执行升主操作

image

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

  1. cm_server2升主后,无法收到cm_agent1上报的消息,达到超时时间T_hb后将DN1和GTM1的状态强行置为Down,耗时 T h b T_{\rm hb}
  2. cm_server2不断收到cm_agent2上报DN2和GTM2为备机的消息,分别下发failover命令执行升主,耗时 1 1
  3. cm_agent2收到failover命令,(轮询间隔)耗时 0.2 0.2 秒(按照 1 1 计算)
  4. cm_agent2执行failover,耗时 T f a i l o v e r T_{\rm failover}
  5. cm_agent2检测到DN2和GTM2升主成功,耗时 1 1
  6. cm_agent2上报DN2和GTM2为主机的消息,(轮询间隔)耗时 0.2 0.2 秒(按照 1 1 计算)
  7. cm_server2收到DN2和GTM2已升主的消息,更新集群状态为降级,耗时 0 0

综上,总耗时为 T h b + T f a i l o v e r + 4 T_{\rm hb} + T_{\rm failover} + 4 .

七、小结

将CM Server自仲裁和DN/GTM仲裁的时间相加,即为集群状态恢复的耗时(单位:秒)

T c l u s t e r = 3 T h b 4 × 2 + T h b + T f a i l o v e r + 4 5 T h b 2 + T f a i l o v e r + 4 (按照实数运算近似) T_{\rm cluster} = \frac{3T_{\rm hb}}{4}×2 + T_{\rm hb} + T_{\rm failover} + 4 \approx \frac{5T_{\rm hb}}{2} + T_{\rm failover} + 4 \text{(按照实数运算近似)}

按照默认值计算,集群状态恢复的理论时间 T c l u s t e r = 84 T_{\rm cluster} = 84 .

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

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

image

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。