1. 双活数据库存储复制架构

现在的数据库双活环境部署在马坡和鹏博士机房，属于无偏重的对等双活架构。两机房数据库所用存储通过GPFS实时复制，保证数据一致性，同时提供了双机房并发访问和写入存储的能力（SRDF存储复制只能单边访问）。现有架构如如下：

2. 现有存储链路稳定性分析

但是之前出现过多次连接双机房的运营商链路抖动，引发了一系列的问题。虽然已经通过使用多家运营商的链路来提高防御能力，但是存储链路抖动还是对应用带来了影响。尤其是部署在数据库双活环境的应用，因为交易量大，所以很容易感知到链路抖动问题。计费系统是最先部署到数据库双活环境的应用，每次存储链路抖动，都会相应的在操作系统看到errpt里面有相关磁盘访问失败的错误，同时查看计费的业务处理时间，当时都执行了40秒左右。

经过和硬件厂商，基础环境运维团队的深入分析，发现操作系统的对磁盘的访问请求超时时间是40秒，对应到当时业务现象也比较吻合。存储厂商分析的原因是链路抖动会导致访问存储的信号丢失，下一次继续访问是由磁盘这个超时机制控制的。但是无论是存储厂商还是硬件厂商，都不建议改小磁盘的超时属性，而且这个属性在现阶段最小也是30秒。

在此基础上，运维团队从数据库使用存储的机制上进一步分析磁盘超时对于数据库业务的影响。数据库存储主要存放数据和日志文件。数据文件是依据一定的策略异步写入存储，所以对存储链路没有那么敏感，不会受到太大的影响。而日志文件是从日志缓存顺序写入磁盘，并且在事务提交的时候必须要等到存储返回写入成功才能算提交完成。所以正是由于日志单并发写磁盘时候遇到链路抖动，需要等待40秒才重新尝试成功，因此事务提交也等了40秒超时才能完成，引发了业务告警。

3. 容错方案可行性分析

因为是日志文件写入存储受到了磁盘访问超时的影响，但是不建议通过调整磁盘超时参数来解决，所以只能考虑绕过磁盘超时这个属性。GPFS是一套非常成熟的分布式存储引擎，可以通过NSD（Net Shared Disk）网络共享的方式提供分布式处理能力。所以我们想到了通过网络访问NSD的方式绕开存储链路，也就避免了磁盘访问超时参数。

对此我们对日志文件存储采用存储链路复制和网络链路复制做了对比性测试。性能测试无论是吞吐量还是响应时间都没有明显差异，而可用性测试的结果差别很大，修改为网络访问模式后，交易受影响的时间从40秒缩短到了4秒！

NSD方案可能的缺点如下：

• 网络TCP发包在网络链路里面经过HASH算法固定走一条链路，没有负载均衡.
• 固定链路闪断，网络如果没有断链路的策略，会导致TCP不停切换回原链路，影响比较久。
• 延时稍微比走存储链路高一点点，没有明显区别。

针对这些缺点，我们分析日志文件使用存储的特点是单并发，低吞吐量。同时走的也是双活环境的私网，属于专用网络，与业务网络相互独立互不影响。所以我们最终的方案是仅调整日志文件所在存储的复制模式，由原来的存储链路复制，改为网络链路复制。

4. 上线部署方案分析

为了在生产环境修改存储复制模式，我们测试了各种部署方案，可以根据不通的应用场景选取对应的部署方案：

• 方案一、整体停集群部署：部署快，安全，但是业务响应时间长。
• 方案二、GPFS在线启停磁盘的方式部署：部署步骤多，存在两次在线数据同步，对业务可能有性能影响，整体不停业务。
• 方案三、轮询重启集群节点部署：通过摘除F5的方式，不停业务，不产生性能影响。部署步骤明确，风险低。

本次计费系统上线部署方案采用方案三，轮询重启集群节点部署，通过摘除F5的方式重启集群节点，不停业务，不产生性能影响。