平台人生
作者平台人生2017-01-05 10:59
软件开发工程师, 平台人生

成也萧何,败也萧何 ---HPUX双机失效案例分析

字数 3262阅读 6079评论 1赞 3

作者:吕伟
文章来自微信公众号:平台人生


本期平台处操作系统运维团队与大家分享一个HPUX双机失效的生产案例,看看价值不菲的双Superdome 高可用架构如何溃于蚁穴。有关HPUX或双机的基本概念,本文不做介绍,请各位自行baidu。

1. 环境介绍

分析对象:两台HP Superdome(下文简称为NODE1/2),
配置:128C/512G(是不是够X),
软件版本:MC/ServiceGuard Cluster版本为11.20,OS版本为11.31 1309,
双机资源:SAN存储、VIP和Informix数据库,
模式:Failover,NODE1是主节点,双机通过直连心跳线连接。

2. 故障和处理过程

某天的15:06收到告警,提示Node2网络不可达(看到告警,我还是心平气和,有双机,且是备机,没啥大事),突然,过了一分钟,告警提示,Node1 网络不可达,word哥,心脏都快跳出来了,这尼玛赶上两台机器同时崩了,可以去买彩票了。火速赶往机房后,发现两台机器指示灯无异常,通过console查看,Node1处于重启过程,Node2 夯死,并且手工RS Node2无反应,最后通过电源复位(类似于长按你笔记本的电源键)重启Node2。16:00,Node1重启完毕,首先恢复了生产。当晚分析系统相关的日志如下:

FRU Type: IO Expander Midplane
                Location: 0x0500FFFF01FFFF69  enclosure5/midplane0
               Timestamp: xxx xxx
        Indictment State: Indicted
Deconfig State: Deconfiguration of this resource not supported
 FRU Type: Xbar Flex Module Link Connector
                Location: 0x0100FF03FF080053  Resource path not applicable.
        Indictment State: Indicted
          Deconfig State: Deconfiguration of this resource not supported

上面一堆英文的意思是Node2夯死的原因是IOX笼子中板故障,于是当晚立即进行了更换并且恢复了双机环境。
但是,一个IOX笼子故障,咋会把主节点Node1搞重启呢,这个大块头重启一次就要50分钟啊,从日志来看,Node1重启的原因是MC/ServiceGuard(群集软件)发出了一个INIT信号,就是MC告诉node1你要重启,真是双机软件不仅没有起到高可用的效果,还把好端端的主节点给搞重启了。。。。。。。,具体日志如下:
• System dump time : 2016 UTC-8
• System up time :
• Load average : 0.33 0.35 0.35
• Node Name :
• Model : Superdome2 32s (20 cells)
• BIOS revision : 006.098.000
• HP-UX release : B.11.31
• ================
• = Crash Events =
• ================
• Note: Crash event 0 was a INIT !
• Note: This is a Service Guard INIT !

• Note: It seems cmcld has been executed within the last 1 second,
• nevertheless the system has been brought down by a INIT through the
• safety timer mechanism.

3.Node1重启原因分析

我们从Node1的双机日志中,发现了蛛丝马迹:

====================
= ServiceGuard Log =====================
......
:CLM:01: Action - Setting current_base_safety_time to (0:3313368717) and next_base_safety_time to (0:3313368817)
• : Action - Safety time is at (0:3313376017) or 72.000000 seconds from now (0:3313368817)
• : Action - Starting sequence update timeout of 60.000000 seconds.
• :CLM:01: Event - Member NODE2 seems unhealthy, not receiving heartbeats from it.

看到没,里面有个叫safety time的东西,查看safety time的日志:

这个就是我们要分析的重点,safety time是硬件自身维持的时钟,不同于操作系统OS经过NTP纠正后的时钟。NTP协议不能纠正这些硬件时钟。由于Node1有两个blade笼子,他有两个晶振模块来管理各自的硬件时间,我们来看下硬件时间的具体数值:

Safety time使用ticket作为基本单元,从上图看出第二个晶振模块的时钟比第一个快了3284个ticket,换算成大家习惯的秒,就是大约32秒,15:06:18日志报告event NODE1与NODE2的心跳中断,根据safety timer的log记录机制,实际上在7秒前(根据MC Cluster相关配置参数计算得出)即15:06:11与NODE2的心跳中断。15:06:11后safety Timer停止更新,MC/ServiceGuard safety Timer设计机制保证在规定的时间内完成Cluster重组(对本案例,此时间为72秒),15:06:11,NODE2 hang,DB5107 检测到心跳中断,一旦未收到心跳信息,safety_timer机制将停止更新safety_time_tsb(safety Timer计时器),其将保持在15:06:11 + 72秒,即15:07:23,在15:06:51,即仅经过40秒后(15:06:51 - 15:06:11),此时CPU 128-254的时钟比正常值快了32秒,这些CPU的previous_tsb=16:06:51+32秒= 15:07:23,此时15:06:51, CPU 128-254 的previous_tsb等于safety_time_tsb满足了Safety Timer机制发起INIT重启的条件,将NODE1自身重启。

据说,这是全球首例。

4.解决方案

  1. 主动更换相应的备件(时钟模块GPSM1/1、GPSM2/1及相应的clock cable)。
  2. 提供CPU时钟偏移检测脚本,监测SD2的时钟同步情况,及时发现、处理可能的隐患
  3. HP Lab正在开发补丁,改善MC/ServiceGuard safety timer的检测机制,避免硬件时钟不同步触发safety timer机制,提高Cluster的可靠性。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

3

添加新评论1 条评论

腾蛇lxf腾蛇lxf系统运维工程师, 朴锐颖T
2019-11-05 16:53
还能联系到您吗?请教晶振模块是个啥东东,最近我们遇到问题也只想HSO ,晶振模块!
Ctrl+Enter 发表

本文隶属于专栏

作者其他文章

相关资料

X社区推广