aix-hacmp双机卷组磁盘missing修复案例分享

落日映苍穹つ 2023-10-04 22:53 22阅读 0赞

工程师重启客户服务器后的第二天，客户反映ogg同步不成功，检查发现ogg使用的oggvg激活失败，其中一块hdisk34磁盘显示状态missing，现场工程师exportvg后重新importvg失败。

readvgda hdisk34显示该磁盘没有VGDA数据，但是读取oggvg的其他磁盘（hdisk17、hdisk18）VGDA信息，hdisk34包含其中。读取hdisk34的PP数据，并没有清零，所以比较明显，hdisk34应该是在异机被误加入到卷组后又被删除。

因为不确定故障发生原因情形下，贸然进行修复，可能会造成更深的破坏。主要对两台主机上的以下日志进行检查：

1.  smit.log（普通文本）
2.  alog -t lvmcfg -o
3.  alog -f /tmp/lvmt.log -o

由于两个alog文件尺寸有限，在发生故障后，修复动作和自动同步操作把alog中的原有记录冲掉，导致看不到oggvg的历史变更操作，但是在节点一的smit.log还是找到一些线索，下面是给客户的故障原因分析：

2017年8月21日，在drcadb01节点上，通过HACMP的CSPOC菜单执行了创建卷组操作，其中包含了drcadb02节点上oggvg使用的hdisk34(PVID:00cf030ccd223202):

<table> 
 <tbody> 
  <tr> 
   <td style="border-color:#000000;width:465pt;"> <p style="margin-left:0;">[Aug 21 2017, 09:25:27]</p> <p style="margin-left:0;"></p> <p style="margin-left:0;">&nbsp;&nbsp;&nbsp; Command_to_Execute follows below:</p> <p style="margin-left:0;">&gt;&gt; _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'</p> <p style="margin-left:0;">&nbsp;00cf030ccd223202 00cf036c0c27fdc1 00cf036c0c280088 00cf036c0c28033f 00cf036c0c28064a 00cf036c0c2808f5 00cf036c0c280bb8 00cf0</p> <p style="margin-left:0;">36c537f70c4 00cf036ccb24823c 00cf036ccb248505</p> </td> 
  </tr> 
 </tbody> 
</table>

随后又执行了该卷组的删除操作：

<table> 
 <tbody> 
  <tr> 
   <td style="border-color:#000000;width:465pt;"> <p style="margin-left:0;">[Aug 21 2017, 09:47:46]</p> <p style="margin-left:0;"></p> <p style="margin-left:0;">&nbsp;&nbsp;&nbsp; Command_to_Execute follows below:</p> <p style="margin-left:0;">&gt;&gt; /usr/sbin/reducevg -df vg00 hdisk34 hdisk52 hdisk51 hdisk50 hdisk49 hdisk48 hdisk47 hdisk23 hdisk54 hdisk53</p> </td> 
  </tr> 
 </tbody> 
</table>

由于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块写入信息，并不会破坏文件系统的完整性。

重构的步骤不复杂，大致过程如下：

1.   exportvg oggvg；
2.   readvgda hdisk17，主要利用其中的lvcb信息和pp-lp映射关系；
3.   mkvg -S -y oggvg -f hdisk17 hdisk18 hdisk34，-S指定scalable VG。
4.   mklv创建逻辑卷，指定map
5.   编辑/etc/filesystems，把/oraogg文件系统加入，然后执行chfs -a log=/dev/loglv01 /oraogg，更新LVCB信息；
6.   fsck /dev/oraogglv检查后，mount /oraogg正常。