守得云开见月明:一次ASM存储高可用故障解决过程分析

关注我们获得更多内容

作者 | 姜劲松，云和恩墨专家支持部Oracle技术专家，Oracle OCP，MySQL OCP，RHCE等认证专家。长期服务移动运营商行业客户，精通 oracle 性能优化，故障诊断，特殊恢复领域。23年IT从业经验、资深数据库及系统软硬件集成专家。

百万级用户规模营销账务系统研发及实施运维经验，主持过11省千万级电力营销业务系统运维主管工作；设计实施过10多个阿里云平台新能源SAAS系统。历任开发工程师、项目经理、技术经理、项目总监、运维主管、云平台架构师等职位。

前言

Oracle ASM 全称为Automated Storage Management，即自动存储管理，它是自 Oracle10g 这个版本 Oracle 推出的新功能。这是 Oracle 提供的一个卷管理器，用于替代操作操作系统所提供的 LVM，它不仅支持单实例配置，也支持RAC这样的多实例配置。

给 Oracle 数据库管理员带来极大的方便，ASM 可以自动管理磁盘组，并提供数据冗余和优化。 ASM提供了丰富的管理和容灾手段，通过适当的配置，可以实现高效的数据库层面的存储容灾功能。

本案例通过某客户项目现场1次ASM存储容灾无法实现预期目标的问题分析解决过程，和大家共同探讨对于非预期问题的解决之道。

 

01问题简述

背景说明：

1、Oracle12.2RAC+ASM Normal Redendancy 模式，数据库存储采用双存储冗余架构，规避单存储故障导致服务中断及数据丢失；

2、 ASM DiskGroup 设计2个 Failgroup(FG)，1个FG磁盘全部存储在1#存储；1个FG全部磁盘存储在2#存储中；

3、期望任意存储故障或断电，数据库实例不受影响，数据不丢失，故障存储上线后数据自动同步。

 

在实际高可用测试中，拔掉1个存储，发现如下现象：

1.CRS集群不受影响，ocr/votedisk自动Failover;

2.DB Controlfile/Redolog发生I/O错误，导致LWGR/CKPT等核心进程长时间阻塞后，Oracle主动重启DB实例(1个或2个实例)后，数据库恢复正常；

3.数据库数据正常，故障存储Online后自动同步正常。

02测试过程

1) 第一类测试

1、存储完成拔线：16:56:05

2、实例16:57:37-16:57:39 挂掉

ASM日志：

2018-08-01T16:57:41.712885+08:00

NOTE: ASM client node11:node1:node1-rac disconnected unexpectedly

DB:

2018-08-01T16:57:45.214182+08:00

Instance terminated by USER, pid = 10158

 

2018-08-01T16:57:36.704927+08:00

Errors in file /oracle/diag/rdbms/node1/node11/trace/node11_ckpt_10158.trc:

ORA-00206: error in writing (block 3, # blocks 1) of control file

ORA-00202: control file: '+DG_DATA_FAB/NODE1/CONTROLFILE/current.265.981318275'

ORA-15081: failed to submit an I/O operation to a disk

ORA-15081: failed to submit an I/O operation to a disk

ORA-15064: communication failure with ASM instance

2018-08-01T16:57:36.705340+08:00

Errors in file /oracle/diag/rdbms/node1/node11/trace/node11_ckpt_10158.trc:

ORA-00221: error on write to control file

ORA-00206: error in writing (block 3, # blocks 1) of control file

ORA-00202: control file: '+DG_DATA_FAB/NODE1/CONTROLFILE/current.265.981318275'

ORA-15081: failed to submit an I/O operation to a disk

ORA-15081: failed to submit an I/O operation to a disk

ORA-15064: communication failure with ASM instance

Oracle CKPT 进程因为控制文件 IO 错误阻塞，导致主动重启 instance，每次测试都在超时70s之后开始Terminate instance。

怀疑是ASM实例offline disk时间过慢，希望调高CKPT阻塞时间阀值解决问题，但是没有找到对应的参数。

既然是controlfile存在此问题，是不是因为DATA磁盘比较多，导致offline检测时间长呢？

尝试将controlfile转移到磁盘较少的REDO DG，仍然在controfile这里报错：

systemstatedump文件：

----- Beginning of Customized Incident Dump(s) -----

Process CKPT (ospid: 4693) is waiting for event 'control file sequential read'.

Process O009 (ospid: 5080) is the blocker of the wait chain.

===[ Wait Chain ]===

CKPT (ospid: 4693) waits for event 'control file sequential read'.

LGWR (ospid: 4691) waits for event 'KSV master wait'.

O009 (ospid: 5080) waits for event 'ASM file metadata operation'.

 

node1_lgwr_4691.trc

----- END DDE Actions Dump (total 0 csec) -----

ORA-15080: synchronous I/O operation failed to write block 1031 of disk 4 in disk group DG_REDO_MOD

ORA-27063: number of bytes read/written is incorrect

HPUX-ia64 Error: 11: Resource temporarily unavailable

Additional information: 4294967295

Additional information: 1024

NOTE: process _lgwr_node1 (4691) initiating offline of disk 4.4042263303 (DG_REDO_MOD_0004) with mask 0x7e in group 3 (DG_REDO_MO

D) with client assisting

2) 第二类测试

尝试对 controlfile 进行 multiplex:

1、每个存储分配1个10GB LUN给服务器；

2、基于每个LUN创建1个DG，controlfile multiplex到这2个DG中。

重新开始模拟1个存储故障测试，发现仍然会发生控制文件无法读写，重启实例！