杨建旭
作者杨建旭2019-01-16 14:21
技术经理, 中国人民银行清算总中心

性能测试中的存储高可用切换

字数 2117阅读 3656评论 2赞 4

介绍

一般情况下,我们压力测试关注的都是交易系统吞吐量、业务的响应时间,批处理系统的处理时间,但是我们很少关注某一个计算机部件的故障而导致的高可用切换过程的业务中断时间,以及切换过程中的性能表现。这其实也是我们性能测试所关注的,因为在有压力和没有压力的情况下,这个业务中断的时间是不一样的;切换过程和正常处理过程中系统性能的表现也是不一样的。

本章节介绍在有业务压力下的存储高可用切换测试,从中发现的影响切换时间的问题,以及对问题的分析。

一、存储服务器高可用的类型

存储的高可用类型很多,先来介绍一种存储的高可用类型GAD

pxvcyot638j

pxvcyot638j

连接备存储也类似,但不论应用指向主存储还是备存储,先落盘的都是主存储。然而这些不是本文的关键。

z8hviolg1d9

z8hviolg1d9

二、单台故障后会发生什么?

当主存储故障,备存储会自动切换为主存储(改变了身份),并且应用会通过多路径软件识别出主存储故障(当到达超时时间),切换到备存储。

当备存储故障,应用也会通过多路径软件识别出备存储故障,把IO路径切换到主存储。

三、测试结果

在这个测试当中,我们除了关注我们通常所关注的一定吞吐量情况下业务响应时间、数据库IO响应时间、磁盘IO响应时间,我们还会关注单台存储故障后的切换时长和切换过程的性能表现。

下面是带着压力,存储高可用切换过程中的CPU利用率的图。

mntt8qw5bv9

mntt8qw5bv9

在主存储故障后大约40多秒后,似乎应用发现了主存储故障,之后切到备存储做业务,但似乎直到3分钟之后,业务量才完全起来,中间40秒~3分钟的过程中,有毛刺状CPU。但即使是吞吐量恢复之后,仍然偶尔有吞吐量突然下降的情况。

四、问题分析

一般来说,存储高可用的过程40秒就足够了,我们做了LVM模式高可用的测试,的确在40秒完成存储切换,那么

1.为什么GAD切换时间比LVM长?

首先从原理上讲,LVM模式是这样的

lfp3029ixoj

lfp3029ixoj

都是主存储,一个存储坏了,只要应用自己发现了,多路径软件直接切到另一个存储就大功告成了。

而GAD的主存储出了故障,不但应用要把路径切换到备存储,并且,存储本身要做调整。即备存储要把自己的身份变成主存储。为什么要变身份呢?因为,在一个存储故障的情况下,写IO的逻辑也和平时不一样。仲裁要告诉备存储,你现在变成主了,而且是没有备机的主机。

这么一来,就会多一些时间上的耽搁。当然,这个耽搁也本不该这么长(2分钟)。

2.为什么有CPU的毛刺,3分钟之后才完全恢复

这是这个CPU图中的疑点。明明故障发生40秒之后,已经在备存储上看到了有IO读写,并且,业务系统也开始做业务了,为什么CPU忽高忽低呢?业务的吞吐量也没有完全起来,直到3分钟以后。

那么,我们做个推理

1)CPU高的时候,是有业务做成功,即可以做写IO,而CPU低的时候,没有业务做成功,即不能做写IO。
2)那么为什么有时候能写IO,有时不能写呢?

是不是因为业务系统中用到了多个LUN,这些LUN并不是同一时间在备存储启动的,而是一个一个慢慢启动的?

这个推理其实很好理解,因为,我们在Windows开机的时候,很早就可以看到Windows的桌面了,但这时候开启应用可能失败。因为Windows为了让用户体验更高,采用了先展示桌面,后面慢慢启动那些服务的策略。那么存储系统是不是也是这样的呢?

我们做一个小实验,把业务系统写日志的那个盘(LV),在建盘的时候,把它条带化(打散)到3个LUN上面。写日志时候,在LUN1写4M数据(举例),之后就切到LUN2上写数据,写满4M之后,又去LUN3上面写。

注:应用的逻辑是,业务完成的标志是写日志完成,如果写不了日志,这个业务就Hang住。

dvup682xzhl

dvup682xzhl

这个图就完美的验证了上面的猜想。

1.CPU明显的忽高忽低就是业务量时而有,时而没有,对应的就是日志一会儿可以写,一会儿不能写。
2.为什么时而不能写呢?因为写完LUN1,要切换到LUN2上面写,而LUN2这时候还没有在存储层面完成主备切换,应用在下IO的时候,存储才意识到自己这个LUN应该做切换了,而且应该尽快切换(有点像催单的意思),之后LUN2优先完成启动,继续做业务。以此类推,LUN3也是一样。

五、调优

基于上述猜想,如何做调优呢?

1)多路径软件(HDLM)探测存储是否活着,有一个超时时间的设置。把这个超时时间缩短,可以尽早发现存储的故障。
2)让存储自己尽早发现自己的故障。多路径软件中有一个HealthCheck的选项,大概的意思是每隔多久去看一看自己的LUN是不是还活着。如果不活着就在另一台存储上把对应的备份激活。把这个HealthCheck的时间缩短,从默认的60分钟改为1分钟。那么存储在发生故障最多一分钟之后,将获得消息,并把故障的LUN在另一台存储上拉起。

六、调优后的结果

ue4yxq5uei

ue4yxq5uei

完美的验证。
中断时间只有不到一分钟,恢复之后也没有出现吞吐量突然下降的情况。

七、后续

事实上,这其实是GAD在某个AIX版本上的bug,但通过这样的性能测试,我们不但发现了bug,还通过外部的参数优化了切换的效果。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

4

添加新评论2 条评论

#杨建旭技术经理, 中国人民银行清算总中心
2019-01-16 16:54
在第七章中其实已经说明了“事实上,这其实是GAD在某个AIX版本上的bug,但通过这样的性能测试,我们不但发现了bug,还通过外部的参数优化了切换的效果”。 但是,不管有没有这个bug,存储双活的原理就是这样,存储必须自己知道自己的一个LUN挂了,然后把备机中对应的LUN激活。
#ktcloud系统工程师, SYSTEX Rainbow Tech inc.
2019-01-16 15:52
GAD不是双活吗?为什呢还会存在激活盘这个问题呢?难道是因为站点A的主机激活站点B的存储时间问题?
Ctrl+Enter 发表

本文隶属于专栏

关于TWT  使用指南  社区专家合作  厂商入驻社区  企业招聘  投诉建议  版权与免责声明  联系我们
© 2019  talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30