在10月22号和10月23号,都是在3:02左右, 复制组DR_vm_2to1_2和DR_vm_2to1_1分别停掉:
Id : 54
State : New
Message Code: 0x03800de
Time : 2023-10-22 03:02:28 CST
Severity : Degraded
Type : Component state change
Message : Remote Copy Group 5(DR_vm_2to1_2) Degraded (Group stopped - IO to secondary timed out, the reason for the hung IO should be resolved before restarting the group {0xa})
Id : 55
State : New
Message Code: 0x03800de
Time : 2023-10-23 03:02:18 CST
Severity : Degraded
Type : Component state change
Message : Remote Copy Group 4(DR_vm_2to1_1) Degraded (Group stopped - IO to secondary timed out, the reason for the hung IO should be resolved before restarting the group {0xa})
过分析3par 22号和23号的历史性能日志, 发现在对应问题时间点,数据卷vm_5T_II_16都有突增的读写IO:
该卷的数据虽然是存在SSD硬盘的CPG(SSD_r5_PRD)上,但快照数据是存在FC硬盘的CPG上的(FC_r6):
所以当该卷出现大量数据修改的I/O时,就会导致大量的被修改的数据移到快照空间,从而导致FC硬盘的IOPS突增。从10月22号和10月23号FC硬盘的性能日志看,确实都有突增:
10月22号FC硬盘IOPS:
10月23号FC硬盘IOPS:
FC硬盘的IOPS安全上限是150左右,从上图看FC硬盘的IOPS已经达到了250左右,严重超出安全阈值,FC硬盘性能达到瓶颈导致响应时间升高,从而导致远程复制组I/O超时停止。
1, 在主机业务侧规避3:00左右对卷vm_5T_II_16的突增I/O访问
2, 如果第1点无法避免,建议将卷vm_5T_II_16的快照CPG改为SSD_r6,改完后手动删除所有vm_5T_II_16卷的快照,或等待之前所有的快照过期自动删除后,再重新启动复制组
该案例暂时没有网友评论
✖
案例意见反馈
亲~登录后才可以操作哦!
确定你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作