本文转自@TWT社区，【作者】杨建旭。

【摘要】本文介绍在有业务压力下的存储高可用切换测试，从中发现的影响切换工夫的问题，以及对问题的剖析。

个别状况下，咱们压力测试关注的都是交易系统吞吐量、业务的响应工夫，批处理零碎的解决工夫，然而咱们很少关注某一个计算机部件的故障而导致的高可用切换过程的业务中断工夫，以及切换过程中的性能体现。这其实也是咱们性能测试所关注的，因为在有压力和没有压力的状况下，这个业务中断的工夫是不一样的；切换过程和失常处理过程中零碎性能的体现也是不一样的。

本文介绍在有业务压力下的存储高可用切换测试，从中发现的影响切换工夫的问题，以及对问题的剖析。

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

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

连贯备存储也相似，但不管利用指向主存储还是备存储，先落盘的都是主存储。然而这些不是本文的要害。

二、 单台故障后会产生什么？

当主存储故障，备存储会主动切换为主存储（扭转了身份），并且利用会通过多路径软件辨认出主存储故障（当达到超时工夫），切换到备存储。

当备存储故障，利用也会通过多路径软件辨认出备存储故障，把 IO 门路切换到主存储。

三、 测试后果

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

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

在主存储故障后大概 40 多秒后，仿佛利用发现了主存储故障，之后切到备存储做业务，但仿佛直到 3 分钟之后，业务量才齐全起来，两头 40 秒 ~3 分钟的过程中，有毛刺状 CPU 。但即便是吞吐量复原之后，依然偶然有吞吐量忽然降落的状况。

四、 问题剖析

一般来说，存储高可用的过程 40 秒就足够了，咱们做了 LVM 模式高可用的测试，确实在 40 秒实现存储切换，那么：

1、为什么 GAD 切换工夫比 LVM 长？
首先从原理上讲， LVM 模式是这样的

都是主存储，一个存储坏了，只有利用本人发现了，多路径软件间接切到另一个存储就功败垂成了。

而 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 住。

这个图就完满的验证了下面的猜测。

CPU 显著的忽高忽低就是业务量时而有，时而没有，对应的就是日志一会儿能够写，一会儿不能写。
为什么时而不能写呢？因为写完 LUN1 ，要切换到 LUN2 下面写，而 LUN2 这时候还没有在存储层面实现主备切换，利用在下 IO 的时候，存储才意识到本人这个 LUN 应该做切换了，而且应该尽快切换（有点像催单的意思），之后 LUN2 优先实现启动，持续做业务。以此类推， LUN3 也是一样。

五、 调优

基于上述猜测，如何做调优呢？

1） 多路径软件（ HDLM ）探测存储是否活着，有一个超时工夫的设置。把这个超时工夫缩短，能够尽早发现存储的故障。

2） 让存储本人尽早发现自己的故障。多路径软件中有一个 HealthCheck 的选项，大略的意思是每隔多久去看一看本人的 LUN 是不是还活着。如果不活着就在另一台存储上把对应的备份激活。把这个 HealthCheck 的工夫缩短，从默认的 60 分钟改为 1 分钟。那么存储在产生故障最多一分钟之后，将取得音讯，并把故障的 LUN 在另一台存储上拉起。

六、 调优后的后果

完满的验证。

中断工夫只有不到一分钟，复原之后也没有呈现吞吐量忽然降落的状况。

七、 后续

事实上，这其实是 GAD 在某个 AIX 版本上的 bug ，但通过这样的性能测试，咱们岂但发现了 bug ，还通过内部的参数优化了切换的成果。