ASM磁盘容量改变的故障处理

某个数据库环境中的ASM磁盘,由于历史原因,全部配置为没有RAID信息的JBOD模式。今天在做产品升级,由于软件需要,需要将原来加入到ASM中每个JBOD的磁盘配置为RAID0。配置过程采用了rolling up的方式,每次对一个diskgroup中的一个failgroup的磁盘配置RAID。 大体步骤为,以磁盘组ssddg的failgroup1为例:

  1. 在ASM中操作,将failgroup1的磁盘全部offline;
  2. 在OS层将这些磁盘卸载;
  3. 配置failgroup1的磁盘为raid0;
  4. 在OS层将这些磁盘加载;
  5. 在ASM中操作,将failgroup1的磁盘全部online。

有自信去做这件事是考虑到磁盘的数据不会受到影响,但是没有考虑到元数据。于是遇到下面的问题:所有节点通过存储软件正常加载上来已经做成RAID0的磁盘。然而在asm磁盘组中要把这些盘online上来时报了下面这个错误:

图片描述

初步一看,以为是自己操作的疏漏,共享磁盘在另一个RAC节点没有加载,才会报“磁盘不是集群范围可见”的错误;但检查了/dev下的路径以及通过dd命令确认可读写以后,可以确认这些盘都正常加载了,在OS层是集群可见的。

下一步,只能去ASM的alert日志看看是否有更具体的报错信息。在alert日志的最后部分能看到上图中的报错。这个信息暂时不足以分析问题。向前追溯日志一直到最开始的错误信息,可以看到,在online磁盘的操作发起以后,对应每个磁盘都有如下报错:

WARNING: group 4/0xff88596d (SSDDG) disk 0: disk size(762496M) is smaller than disk header value(763097M)

报错的字面意思很明白:磁盘头元信息记录的磁盘大小(763097M)要大于磁盘的实际大小(762496M)。紧跟着是如下信息:

NOTE: process rbal+asm1 (16016) initiating offline of disk 0.3915950646 (SSDDG_0000) with mask 0x7e in group 4
NOTE: sending set offline flag message 2479816269 to 1 disk(s) in group 4
WARNING: Disk SSDDG_0000 in mode 0x11 is now being offlined
WARNING: Disk SSDDG_0000 in mode 0x11 is now being offlined

到这里,可以推出由于ASM元信息记录的磁盘size超过了实际的size,磁盘在online时自检失败,online动作立刻终止。而后面的ORA-15282报错,只是假象。

下面我想先把这个warning排除,来验证我的推测。

在mos上没有搜到该案例,只能用掌握的那点元数据的知识解决了。首先用kfed把盘头的元数据读取出来,重定向到文本。搜索763097这个数字,找到了下面这行:

图片描述

从条目的名称kfdhdb.dsksize也可以看出这个条目记录的是磁盘的大小。在创建ASM磁盘组时,会把盘的大小更新到这个条目,如果没有指定size子句,一般都是磁盘(或者分区)的真实大小。操作系统识别到的磁盘大小可以用fdisk查看到,结果显示两者确实如报错所说,大小有差异。产生差异的原因大家都应该猜到了,对盘做了RAID配置之后,可用大小发生了变化(可能是因为RAID信息占据了更多的磁盘大小,这块谁可以解释比较清楚欢迎提出)。

下面要解决ASM元信息与实际情况不一致的问题。考虑到ASM中可以通过resize命令改变ASM磁盘的可用大小,该操作包括两个方面:更新ASM元信息(disk header和at表等等)和rebalance磁盘组的数据。但是这个操作前提是磁盘需要是online状态。

现在出问题这些磁盘online都会报错,因此需要非常规手段先让online这一步成功:

首先用kfed read命令将磁盘头数据重定向到文本文件中,然后vi编辑文本,将dsksize的值修改成762496,最后将改过的文本kfed merge到原磁盘。

做这个操作时我有几点考虑:

  1. ASM磁盘头的元信息在1号au的倒数第二个块有备份,如果修改元数据发生意外,可以用kfed repair修复;
  2. 导出的元数据的文本,也可以作为一个备份;
  3. 先对其中一块磁盘做修改,试试效果。

对其中一块ASM磁盘完成以上操作之后,在ASM中做online该单块磁盘的动作就成功了。有了这个验证之后,再将所有的ssddg磁盘的dsksize都改掉并在ASM中online起来。

用asmcmd命令行的lsdsk命令去看盘的大小时,发现确实是修改后的762496M。

之后在mos搜到了另外一个报错,有相同的解决方法,见(doc id 1077175.1)ASM disk group mount fails with ORA15036: disk is truncated。

有兴趣的同学可以参考《解密Oracle ASM 内核》这本书中的ASM元信息AT表,stride等相关知识,去验证:resize这一步除了更新磁盘头部记录的磁盘可用大小以外,还会更新at表最后一个块记录的可用au的信息等等元数据;而且resize动作发起之后,ASM会对现有数据做rebalance。而手工使用kfed修改,只会改变磁盘头部记录的磁盘可用大小。

来源:沃趣科技(woqutech)
作者:邱大龙

你可能感兴趣的:(ASM磁盘容量改变的故障处理)