数据库双活和存储双活的结合方案及对链路和性能的要求？

目前数据库双活方案还是比较推崇ORACLE RAC和DB2 PureScale，机制也非常先进，可靠性强。
ORACLE RAC有两种方式可以实现数据库节点双活+存储节点双活(ACTIVE-ACTIVE，而不是ACTIVE-STANDBY方案)：
1.ORACLE RAC+ASM+存储双活（两个存储MDISK虚拟一个VDISK共享给ORACLE RAC节点）
2.ORACLE RAC+GPFS等并行文件系统+两个独立存储
DB2 PureScale的话和存储双活结合案例还是没有，依靠的还是DB2多MEMBER节点+2个主备CF节点+GPFS并行文件系统实现的。
所以这三种方案中只有第一种是与存储双活真正结合的方案，也有落地成功案例，如ORACLE RAC+SVC ESC。
对于这种方案，对链路、性能的要求与对业务连续性和业务性能的要求是息息相关的。业务连续性要求越高，链路的质量和冗余度要求越高；业务性能要求越高，其并发度越高，后端存储需要承担的IOPS和IO吞吐量越高；其对响应时间要求越小，对链路的时延要求越小，存储和节点间距离越近。
所以还是两个关键点：链路和存储性能，存储性能可以采用高性能存储来规避，闪存阵列是个好东西，配合缓存高和性能强的存储网关可以解决性能问题；链路问题，一是尽量缩短链路距离，二是改善链路质量，三是想尽办法解决写IO同步频率。
所以最佳存储双活+数据库双活方案就是：本地存储（闪存）双活+本地数据库双活+高性能（CPU等）高容量（缓存）存储网关，并且优化数据库写IO频率（增大数据库缓存，分批提交，数据库和应用分区等等）

通过使用多家运营商的链路来提高防御能力，但是存储链路抖动还是对应用带来了影响。尤其是部署在数据库双活环境的应用，因为交易量大，所以很容易感知到链路抖动问题。部署到数据库双活环境的应用，每次存储链路抖动，都会相应的在操作系统看到errpt里面有相关磁盘访问失败的错误
操作系统的对磁盘的访问请求超时时间是40秒，对应到当时业务现象也比较吻合。存储厂商分析的原因是链路抖动会导致访问存储的信号丢失，下一次继续访问是由磁盘这个超时机制控制的。但是无论是存储厂商还是硬件厂商，都不建议改小磁盘的超时属性，而且这个属性在现阶段最小也是30秒。