工程师重启客户服务器后的第二天,客户反映ogg同步不成功,检查发现ogg使用的oggvg激活失败,其中一块hdisk34磁盘显示状态missing,现场工程师exportvg后重新importvg失败。
readvgda hdisk34显示该磁盘没有VGDA数据,但是读取oggvg的其他磁盘(hdisk17、hdisk18)VGDA信息,hdisk34包含其中。读取hdisk34的PP数据,并没有清零,所以比较明显,hdisk34应该是在异机被误加入到卷组后又被删除。
因为不确定故障发生原因情形下,贸然进行修复,可能会造成更深的破坏。主要对两台主机上的以下日志进行检查:
由于两个alog文件尺寸有限,在发生故障后,修复动作和自动同步操作把alog中的原有记录冲掉,导致看不到oggvg的历史变更操作,但是在节点一的smit.log还是找到一些线索,下面是给客户的故障原因分析:
2017年8月21日,在drcadb01节点上,通过HACMP的CSPOC菜单执行了创建卷组操作,其中包含了drcadb02节点上oggvg使用的hdisk34(PVID:00cf030ccd223202):
[Aug 21 2017, 09:25:27] Command_to_Execute follows below: >> _CSPOC_CALLED_FROM_SMIT=true /usr/es/sbin/cluster/sbin/cl_mkvg -f -n -S -cspoc -n'drcadb01' -r'None' -V'63' -l'false' '-E' 00cf030ccd223202 00cf036c0c27fdc1 00cf036c0c280088 00cf036c0c28033f 00cf036c0c28064a 00cf036c0c2808f5 00cf036c0c280bb8 00cf0 36c537f70c4 00cf036ccb24823c 00cf036ccb248505 |
[Aug 21 2017, 09:47:46] Command_to_Execute follows below: >> /usr/sbin/reducevg -df vg00 hdisk34 hdisk52 hdisk51 hdisk50 hdisk49 hdisk48 hdisk47 hdisk23 hdisk54 hdisk53 |
由于hdisk34磁盘的reserve_policy(保持策略)设置为no_reserve(不加锁),所以上述的创建和删除操作都取得了成功。这样hdisk34上的vgda(卷组控制信息)被彻底删除。
由于oggvg在drcadb02节点上处于打开状态,日常的文件系统访问并不需要使用到vgda信息,所以该操作成为一个隐患埋藏在系统中,并没有立即发作,直至2018年2月11日因系统维护重启drcadb02节点,需要重新激活oggvg时,操作系统发现VGDA信息不同步,因而无法激活卷组。
因为在当日14点的HACMP拓扑发现结果中,drcadb02节点上oggvg包含有hdisk34,hdisk34是在这5个小时内才加入到oggvg的可能性不高,所以上述的故障原因分析可信度比较高。有缺憾的地方是,除了alog信息不可得外,drcadb02节点上的smit.log和命令历史中完全找不到oggvg装入(原先在drcadb01上定义)和扩容的信息,使得分析结果的证据链不够完整。
接下来尝试recreatevg修复不成功,recreatevg要求构成vg的所有磁盘上的vgda信息是完整并且一致的,由于hdisk34上没有vgda信息,所以命令执行失败。
那么只能通过readvgda hdisk17获得的vgda信息重构oggvg了。
中途有一个小插曲,oggvg上只有2个LV,读取LVCB发现没有平时熟悉的“AIX LVCB”字符。因为scalable类型的卷组LVCB信息是放在VGDA里面,同事提供了一个测试环境,验证了这属于正常现象,LV的头部已经没有LVCB信息,这意味着对于scalable vg,允许反复测试lvmap(对这个案例,因为有完整的vgda信息,所以并不需要),而不用担心lvcb的写入,而抹去正常的应用数据。另外,文件系统会跳过LV头部的4K块,所以随便往头部的4K块写入信息,并不会破坏文件系统的完整性。