某银行ods系统的一体机(数据库版本为19.8)上,由于某个存储节点掉了4块盘,磁盘处于offline状态,在超过了”_asm_disk_repair_time”时间内没有online,被磁盘组自动drop force,之后在drop disk rebalance未完成的情况下,将4块盘重新加入了磁盘组,由于担心rebalance影响ods跑批业务,所以在跑批阶段中断rebalance操作,在空闲时重新发起rebalance,反复启停rebalance很多次,但是在某一次中断rebalance之后,发现rebalance就再也无法启动了。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
2021-06-30T17:17:21.183103+08:00 SQL> alter diskgroup datac1 rebalance power 0 2021-06-30T17:17:21.186100+08:00 NOTE: cache closing disk 77 of grp 1: (not open) _DROPPED_0077_DATAC1 2021-06-30T17:17:21.186162+08:00 NOTE: cache closing disk 107 of grp 1: (not open) _DROPPED_0107_DATAC1 2021-06-30T17:17:21.186216+08:00 NOTE: cache closing disk 113 of grp 1: (not open) _DROPPED_0113_DATAC1 2021-06-30T17:17:21.186268+08:00 NOTE: cache closing disk 119 of grp 1: (not open) _DROPPED_0119_DATAC1 2021-06-30T17:17:21.187265+08:00 NOTE: GroupBlock outside rolling migration privileged region 2021-06-30T17:17:21.227738+08:00 NOTE: stopping process ARBA 2021-06-30T17:17:25.269379+08:00 NOTE: rebalance interrupted for group 1/0xa1b08317 (DATAC1) ... 2021-06-30T17:18:57.863092+08:00 SQL> alter diskgroup datac1 rebalance power 5 2021-06-30T17:18:57.866314+08:00 NOTE: cache closing disk 77 of grp 1: (not open) _DROPPED_0077_DATAC1 2021-06-30T17:18:57.866376+08:00 NOTE: cache closing disk 107 of grp 1: (not open) _DROPPED_0107_DATAC1 2021-06-30T17:18:57.866430+08:00 NOTE: cache closing disk 113 of grp 1: (not open) _DROPPED_0113_DATAC1 2021-06-30T17:18:57.866482+08:00 NOTE: cache closing disk 119 of grp 1: (not open) _DROPPED_0119_DATAC1 2021-06-30T17:18:57.867615+08:00 NOTE: GroupBlock outside rolling migration privileged region |
从日志中可以发现,从17点17分中断rebalance之后,在18分重新发起rebalance,从alert日志以及rbal trace文件可以看到rbal进程再也没有arbn进程去做rebalance。
仔细的查阅了rebalance相关的后台进程trace以及asm alert日志都没有任何有用的信息。从发起rebalance命令的进程trace中,发现了非常重要的信息。
1 2 3 4 5 6 7 8 9 10 11 12 |
ksedsts()+426<-kfnmGroupBlockGlobal()+659<-kfnmGroupBlockPriv()+318<-kfgFinalize()+334<-kfxdrvAlter()+3415<-kfxdrvEntry()+1417<-opiexe()+28735<-opiosq0()+4494<-kpooprx()+387<-kpoal8()+830<-opiodr()+1202<-ttcpip()+1222<-opitsk()+1903<-opiino()+936<-opiodr()+1202 <-opidrv()+1094<-sou2o()+165<-opimai_real()+422<-ssthrdmain()+417<-main()+256<-__libc_start_main()+245 ----- End of Abridged Call Stack Trace ----- Partial short call stack signature: 0xb0ac14de6c5e2e9c SQL> alter diskgroup datac1 rebalance modify power 2 kfgbSendRebalUpdate: xic 2600134044 gn 1 power 2 phase 0 flags 0x1 op=0 NOTE: detected a paused rebalance of group DATAC1 kfgpCreate: max_fg_rel 4, max_disk_part 8 kfgpPartners: NOT appliance. kfgpPartners: max_fg_rel, max_disk_part(4, 8) has been adjusted to (3, 8) due to actual FG, disk configuration (3, 144, num_singledisk_fg 0) kfgpPartner: necessary rebalancing detected. Avail slot for disk120 7 target 8 WARNING: Too many uncompleted reconfigurations. Rebalance needs completion. |
从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关系,如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
kfdpDtaEv1[1].status: 127 ; 0x030: I=1 V=1 V=1 P=1 P=1 A=1 D=1 kfdpDtaEv1[1].fgNum: 2 ; 0x032: 0x0002 kfdpDtaEv1[1].addTs: 2462919836 ; 0x034: 0x92cd2c9c kfdpDtaEv1[1].partner[0]: 49152 ; 0x038: P=1 P=1 PART=0x0 kfdpDtaEv1[1].partner[1]: 49157 ; 0x03a: P=1 P=1 PART=0x5 kfdpDtaEv1[1].partner[2]: 49155 ; 0x03c: P=1 P=1 PART=0x3 kfdpDtaEv1[1].partner[3]: 49154 ; 0x03e: P=1 P=1 PART=0x2 kfdpDtaEv1[1].partner[4]: 10000 ; 0x040: P=0 P=0 PART=0x2710 kfdpDtaEv1[1].partner[5]: 0 ; 0x042: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[6]: 0 ; 0x044: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[7]: 0 ; 0x046: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[8]: 0 ; 0x048: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[9]: 0 ; 0x04a: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[10]: 0 ; 0x04c: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[11]: 0 ; 0x04e: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[12]: 0 ; 0x050: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[13]: 0 ; 0x052: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[14]: 0 ; 0x054: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[15]: 0 ; 0x056: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[16]: 0 ; 0x058: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[17]: 0 ; 0x05a: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[18]: 0 ; 0x05c: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[19]: 0 ; 0x05e: P=0 P=0 PART=0x0 |
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可以发现如下信息:
1 2 3 4 |
kfcbpInit: gn=2 fn=2 blk=0 pin=1204 (0x9f3072e8) shar current kffd.c 2109 kfcbpInit: gn=2 fn=1 blk=8 pin=1206 (0x9f3072e8) shar current kfdus.c 620 kfcbpInit: gn=2 fn=8 blk=0 pin=1207 (0x9f3072e8) shar current kfdus.c 649 |
可以看到依次读取了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
1 2 3 4 5 6 7 8 9 10 11 12 |
SQL> @sp partner_target -- show parameter by sp -- show hidden parameter by sp old 3: where x.indx=y.indx and ksppinm like '_%&p%' new 3: where x.indx=y.indx and ksppinm like '_%partner_target%' NAME VALUE DESC ---------------------------------------- ---------- ------------------------------------------------------------------------------------------ _asm_partner_target_disk_part 8 target maximum number of disk partners for repartnering _asm_partner_target_fg_rel 4 target maximum number of failure group relationships for repartnering |
2.extent relocating
rbal会根据rebalance plan,根据power分配给arbn进程,真正的去做rebalance,该步骤最为耗时,rebalance是按照asm file分批去做relocate的,每次relocate最多120 asm file extent,由asm隐藏参数控制。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
SQL> @sp rebalance_plan -- show parameter by sp -- show hidden parameter by sp old 3: where x.indx=y.indx and ksppinm like '_%&p%' new 3: where x.indx=y.indx and ksppinm like '_%rebalance_plan%' NAME VALUE DESC ---------------------------------------- ---------- ------------------------------------------------------------------------------------------ _asm_rebalance_plan_size 120 maximum rebalance work unit ARB0 relocating file +DATAC1.256.1050862343 reason 6 (15 entries first xnum 0x7) ARB0 relocating file +DATAC1.307.1051960599 reason 6 (2 entries first xnum 0x0) ARB0 relocating file +DATAC1.308.1051960605 reason 6 (7 entries first xnum 0x9) ARB0 relocating file +DATAC1.309.1051960605 reason 6 (16 entries first xnum 0x0) ARB0 relocating file +DATAC1.309.1051960605 reason 6 (1 entries first xnum 0x80000000) ARB0 relocating file +DATAC1.312.1051961551 reason 6 (7 entries first xnum 0x1) ARB0 relocating file +DATAC1.312.1051961551 reason 6 (1 entries first xnum 0x80000000) ARB0 relocating file +DATAC1.313.1051961555 reason 6 (9 entries first xnum 0x8) ARB0 relocating file +DATAC1.317.1052321267 reason 6 (120 entries first xnum 0x5) |
3.compacting
compacting阶段主要是将磁盘上存的数据尽可能的移动到磁盘的外圈磁道上去,对于机械磁盘,外圈寻址会更快。可以通过隐藏参数对asm实例或磁盘组属性去禁用compacting。
1 2 3 4 5 6 7 8 9 10 11 |
SQL> @sp rebalance_compact -- show parameter by sp -- show hidden parameter by sp old 3: where x.indx=y.indx and ksppinm like '_%&p%' new 3: where x.indx=y.indx and ksppinm like '_%rebalance_compact%' NAME VALUE DESC ---------------------------------------- ---------- ------------------------------------------------------------------------------------------ _disable_rebalance_compact FALSE disable space usage checks for storage reconfiguration |
通过对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,
1 2 |
disk (0x7f66a40eaa40), num 120a slot 65535 fg 2 ptotal 20 pact 7 pnew 0 pdrp 13 pset dsk 120 [20]: d128fg3 d89fg1 d138fg3 d97fg1 d98fg1 d124fg3 d142fg3 d145fg1 d35fg3 d45fg1 a88fg1 d33fg3 d40fg1 a96fg1 a46fg1 a20fg1 a12fg3 a147fg1 d141fg3 a78fg3 |
得到的关键信息如下,其中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已经用满了,所以报错。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
kfdpDtaEv2[42].super.status: 127 ; 0x888: I=1 V=1 V=1 P=1 P=1 A=1 D=1 kfdpDtaEv2[42].super.fgNum: 2 ; 0x88a: 0x0002 kfdpDtaEv2[42].super.addTs: 2456886661 ; 0x88c: 0x92711d85 kfdpDtaEv2[42].super.partner[0]: 16512 ; 0x890: P=0 P=1 PART=0x80 kfdpDtaEv2[42].super.partner[1]: 16473 ; 0x892: P=0 P=1 PART=0x59 kfdpDtaEv2[42].super.partner[2]: 16522 ; 0x894: P=0 P=1 PART=0x8a kfdpDtaEv2[42].super.partner[3]: 16481 ; 0x896: P=0 P=1 PART=0x61 kfdpDtaEv2[42].super.partner[4]: 16482 ; 0x898: P=0 P=1 PART=0x62 kfdpDtaEv2[42].super.partner[5]: 16508 ; 0x89a: P=0 P=1 PART=0x7c kfdpDtaEv2[42].super.partner[6]: 16526 ; 0x89c: P=0 P=1 PART=0x8e kfdpDtaEv2[42].super.partner[7]: 16529 ; 0x89e: P=0 P=1 PART=0x91 kfdpDtaEv2[42].super.partner[8]: 16419 ; 0x8a0: P=0 P=1 PART=0x23 kfdpDtaEv2[42].super.partner[9]: 16429 ; 0x8a2: P=0 P=1 PART=0x2d kfdpDtaEv2[42].super.partner[10]: 49240 ; 0x8a4: P=1 P=1 PART=0x58 kfdpDtaEv2[42].super.partner[11]: 16417 ; 0x8a6: P=0 P=1 PART=0x21 kfdpDtaEv2[42].super.partner[12]: 16424 ; 0x8a8: P=0 P=1 PART=0x28 kfdpDtaEv2[42].super.partner[13]: 49248 ; 0x8aa: P=1 P=1 PART=0x60 kfdpDtaEv2[42].super.partner[14]: 49198 ; 0x8ac: P=1 P=1 PART=0x2e kfdpDtaEv2[42].super.partner[15]: 49172 ; 0x8ae: P=1 P=1 PART=0x14 kfdpDtaEv2[42].super.partner[16]: 49164 ; 0x8b0: P=1 P=1 PART=0xc kfdpDtaEv2[42].super.partner[17]: 49299 ; 0x8b2: P=1 P=1 PART=0x93 kfdpDtaEv2[42].super.partner[18]: 49293 ; 0x8b4: P=1 P=1 PART=0x8d kfdpDtaEv2[42].super.partner[19]: 49230 ; 0x8b6: P=1 P=1 PART=0x4e kfdpDtaEv2[42].siteNum: 1 ; 0x8b8: 0x0001 kfdpDtaEv2[42].spare: 0 ; 0x8ba: 0x0000 |
这里尝试了使用15195事件设置level 57完全重建磁盘之间的partner关系,报出了隐藏在背后的真正错误,也验证了之前的猜测。
1 2 3 4 5 6 7 8 |
kfgpCreate: max_fg_rel 4, max_disk_part 8 kfgpPartners: NOT appliance. kfgpPartners: max_fg_rel, max_disk_part(4, 8) has been adjusted to (3, 8) due to actual FG, disk configuration (3, 144, num_singledisk_fg 0) kfgpPartners: verifying consistency of newly formed partners. kfgpPartners: repartnering completed. kfgpGet: insufficient space provided by caller. size 21, pcnt 20, KFPTNR_MAXTOT 20 WARNING: Too many uncompleted reconfigurations. Rebalance needs completion. |
故障原因,我觉得是用户频繁的起停rebalance导致,因为每次启停rebalance都会触发pst重新配置,并且rebalance未完成之前drop状态的slot无法清理也无法重用。
搞清楚故障的来龙去脉之后,解决方案其实很简单,就是drop 120号磁盘。