案例:深入解析asm rebalance无法启动

某银行ods系统的一体机(数据库版本为19.8)上,由于某个存储节点掉了4块盘,磁盘处于offline状态,在超过了”_asm_disk_repair_time”时间内没有online,被磁盘组自动drop force,之后在drop disk rebalance未完成的情况下,将4块盘重新加入了磁盘组,由于担心rebalance影响ods跑批业务,所以在跑批阶段中断rebalance操作,在空闲时重新发起rebalance,反复启停rebalance很多次,但是在某一次中断rebalance之后,发现rebalance就再也无法启动了。

从日志中可以发现,从17点17分中断rebalance之后,在18分重新发起rebalance,从alert日志以及rbal trace文件可以看到rbal进程再也没有arbn进程去做rebalance。

仔细的查阅了rebalance相关的后台进程trace以及asm alert日志都没有任何有用的信息。从发起rebalance命令的进程trace中,发现了非常重要的信息。

从trace的报错来看,熟悉asm元数据和asm相关函数的应该知道kfgp开头的都是pst相关的函数,虽然报错相关信息很陌生(反正我是第一次见),但是至少可以给问题分析确定了一个方向,那就是该磁盘组的pst导致了rebalance无法启动。

回顾一下rebalance和pst的内部原理,思考一下rebalance和pst有何联系。

PST全称叫Partner and Status Table,是ASM的物理元数据,位于asm磁盘的第二个AU(AU1),也属于Physically addressed metadata,PST对于ASM非常重要,它记录了该磁盘组所有磁盘的磁盘号、磁盘之间的partner关系、failgroup信息、PST心跳信息以及磁盘状态,磁盘的第二个AU(AU1)为PST保留,但并不是磁盘组内的所有磁盘都有PST,磁盘组冗余级别不同,PST的个数也不同,如下:

  • External Redundancy一般有一个PST
  • Normal Redundancy至多有个3个PST
  • High Redundancy 至多有5个PST

详细的PST介绍参考之前的一篇文章http://www.minniebaby.tech/2021/10/20/asm-physically-addressed-metadata-partner-and-status-table/

这里就不深入讨论了,主要深入分析一下rebalance。

这里只强调一下pst与rebalance相关的地方,每块磁盘的partner只有20个slot,可以通过kfed或者x$kfdpartner查看每块磁盘的partner关系,如下:

partner[n]就是partner slot,rebalance时就需要改动partner列表去实现,slot有三种状态,

  • active:(P=1 P=1)说明是有效的partner
  • drop:(P=0 P=1)是解除partner关系
  • new:(P=1 P=0)是新建立的partner关系

drop和new状态的slot会在rebalance操作完成之后被清理,每块磁盘最多只能有8个active的partner slot。

ASM rebalance就非常常见了,通常是删加盘触发,或者手动rebalance触发,其意义就是让每个文件在ASM磁盘组的所有磁盘上都均匀分配。rebalance操作通常分为3个阶段:

  • rebalance plan
  • extent relocating
  • extent relocating

rebalance的哪个阶段和pst有何联系需要深入分析一下。

1.rebalance plan

该阶段的主要作用是制定rebalance plan,尽可能的将磁盘组中的每个文件在每个磁盘上平均分配。通过打开对kfc(metadata cache)的kst trace深入分析rebalance plan。其实质就是重构磁盘组之间磁盘的partnership,大致也可细分分为2个阶段:

第一个阶段的工作是提供最终有哪些磁盘需要参与此次rebalance,以及每块磁盘当前使用情况,为第二个阶段做准备,从kfc的kst trace可以发现如下信息:

可以看到依次读取了asm 2号、1号、8号文件,分别是Disk Directory、File Directory、Disk Used Space Directory。

  • 1.读取Disk Directory的作用是为了获取磁盘组中所有磁盘的信息(磁盘大小、所属失败组、磁盘状态)等等,状态正常的磁盘都将参与此次rebalance。
  • 2.读取File Directory的目的是为了获取Disk Used Space Director所在位置。
  • 3.读取Disk Used Space Director获得每块磁盘当前已使用的大小

关于Disk Directory的介绍可以参考http://www.minniebaby.tech/2021/10/21/asm-virtually-addressed-metadata-disk-directory/

关于File Directory的介绍可以参考http://www.minniebaby.tech/2021/10/21/asm-virtually-addressed-metadata-file-directory/

第二个阶段的主要工作是根据第一阶段得到的信息去做PST重新配置,call stack为kfgPstPrepare->kfgCanRepartner->kfgpCreate->kfgpPartners->kfgPstUpdate,其目的是得到rebalance plan,保证让磁盘组上的文件平均分布在每块磁盘上,并且需要确保ASM磁盘组的冗余的。同时重构PST需要遵循2个原则,由asm隐藏参数控制:

  • 每个failgroup只能最多与4个failgroup互为partner
  • 每块磁盘只能最多与其他failgroup中的8块盘互为partner

2.extent relocating

rbal会根据rebalance plan,根据power分配给arbn进程,真正的去做rebalance,该步骤最为耗时,rebalance是按照asm file分批去做relocate的,每次relocate最多120 asm file extent,由asm隐藏参数控制。

3.compacting

compacting阶段主要是将磁盘上存的数据尽可能的移动到磁盘的外圈磁道上去,对于机械磁盘,外圈寻址会更快。可以通过隐藏参数对asm实例或磁盘组属性去禁用compacting。

通过对asm rebalance内部原理的解析,回头去看此次案例,问题 肯定出在rebalance plan阶段,并且也说明了每一次终止rebalance之后再发起rebalance都要重新经历rebalance plan。核心的报错信息kfgpPartner: necessary rebalancing detected. Avail slot for disk120 7 target 8 ,结合trace里120号磁盘的的pst dump,该报错的含义应该是120的active partner目前是7但应该为8,

得到的关键信息如下,其中ptotal 20格外显眼,因为partner slot最大就是20:

  • num 120a:120号磁盘
  • ptotal 20:已经使用了20个partner slot
  • pact 7:active的partner slot为7
  • pnew 0:new partner slot为0
  • pdrp 13:drop partner slot为13
  • pset dsk 120 [20]后面的就是partner列表,d128fg3的意思是失败组fg3的128号盘,slot状态为drop a96fg1 的意思是失败组fg1的96号盘,slot状态为active。

那么用kfed去读取一下120号盘的partner列表对比一下发现active partner是8,对比pst dump发现其中一个partner的slot从active变成了drop,就是141号盘。猜测是在pst Prepare阶段取消了141号盘和120号盘之间的partner关系,想新找一块盘来和120组成partner关系,但是由于drop状态的slot在rebalance未完成期间不能清理,而且目前120号盘的pst slot已经用满了,所以报错。

这里尝试了使用15195事件设置level 57完全重建磁盘之间的partner关系,报出了隐藏在背后的真正错误,也验证了之前的猜测。

故障原因,我觉得是用户频繁的起停rebalance导致,因为每次启停rebalance都会触发pst重新配置,并且rebalance未完成之前drop状态的slot无法清理也无法重用。

搞清楚故障的来龙去脉之后,解决方案其实很简单,就是drop 120号磁盘。

此条目发表在Oracle, Oracle troubleshooting分类目录,贴了, 标签。将固定链接加入收藏夹。

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注