四种存储双活方案对性能影响的比较分析
存储双活架构影响存储性能的因素有哪些？
首先明确存储双活的效果：两个主机分别对两个双活存储，本地读，本地写。
那么影响写性能的因素有：
1.距离：距离越大，写IO同步往返延迟（RTT）越高。
2.缓存容量：本地缓存容量越小，写缓存延迟占比越高，越容易造成写缓存满所导致的缓存无法及时刷入后端存储。
3.存储磁盘本身和RAID级别：磁盘本身所能承受的最高写IOPS越高，响应时间越小，所组成的磁盘阵列整体性能越好，RAID级别不同，其磁盘阵列能提供的最高IOPS和响应时间也不同。
4.读写比例：读写比例越高，写缓存越容易及时刷入后端存储，写缓存延迟占比越低，需要同步至对端存储的写IO频率越低，性能越高。
5.数据的分布：卷在后端磁盘阵列上分布越均匀，其写IO的并发度越高，写IO性能越好。
6.链路带宽：链路带宽越高，能提供的写IO吞吐量峰值越高，减少了因链路带宽不足造成写IO性能降低的瓶颈。
影响读性能的因素有：
1.缓存容量：缓存容量越高，读IO命中缓存的几率越高，减少了直接读写后端存储磁盘的频率。
2.数据的分布：数据卷在后端磁盘阵列上分布越均匀，直接读磁盘阵列的并发度越高，读IO性能越好。
3.存储磁盘本身：磁盘本身所能提供的IOPS越高，响应时间越短，读IO性能越好。
所以可以看到，抛开存储本身的因素（缓存、数据分布、磁盘本身），因为存储双活架构的搭建，而导致性能下降的因素为：
1.距离
2.链路带宽
3.写IO同步频率
所以我们在搭建存储双活架构时，为减轻对存储性能的影响，应该尽量：
1.缩短双活存储的距离：极致是本地存储双活
2.增大链路的带宽：本地---多链路绑定，多个SAN端口Trunking。跨站点---运营商扩容链路带宽
3.减少写IO同步的频率：上层应用和数据库转变设计方式，减少写I/O频率，分批次同步。
另外：提升单个存储本身的性能（包括后端存储、存储控制器或者存储网关）
四种存储双活方案对性能影响的比较分析
相比单存储直接提供读写来说，存储双活一定会增加读写响应时间，更别说存储还是跨两个不同数据中心的，随着距离的增加，理论上每增加100KM，会增加1ms的RTT（往返延迟时间），我们先来分析不同厂商的存储双活方案带来的性能影响：
（1）IBM SVC Enhanced Stretch Cluster(ESC)和HDS GAD等
IBM SVC ESC和HDS GAD的读写方式都很类似，这里就放在一起来看。
SVC ESC：
HDS GAD：
读：ESC和GAD在两个存储拉开到两个数据中心，形成AA模式的架构，对于读来说，是两个数据中心分别对各自中心的存储本地读，这样读来说不存在跨站点的RTT，读性能跟单存储是一样的。
写：某数据中心的写操作会先写到本地控制节点缓存，然后再跨站点同步至另一控制节点缓存中，并原路返回，告诉主机写操作完成，等到缓存达到一定的水位时，再刷入各自底层存储当中，这时的写操作存在1倍的跨站点RTT。当两个数据中心都要对某一数据块写操作时，会先在缓存表对应的数据块中加锁，并同步锁信息至对端缓存表，实现双活存储的写并发。所以写也是本地写的方式，性能跟单存储比是降低的。
（2）SVC HyperSwap
SVC HyperSwap的HyperSwap卷有master和aux之分，读写复杂度也高很多，master卷所在站点的主机读写是本地读本地写，而aux卷所在站点的主机读写方式是转发模式。
假设初始化后，Site1的卷为Master卷，Site2的卷为Aux卷
读：
Site1读I/O
1.主机向SVC I/O Group1的任意一个节点发送读请求
2.SVC I/O Group1将该请求传至Storage Pool1
3.Storage Pool1响应请求，并将数据传至SVC I/O Group1
4.SVC I/O Group1将数据结果传至主机
Site2读I/O
1.主机向SVC I/O Group2的任意一个节点发送读请求
2.SVC I/O Group2将该请求转发至SVC I/O Group1
3.SVC I/O Group1将请求传至Storage Pool1
4.Storage Pool1响应请求，并将数据传至SVC I/O Group1
5.SVC I/O Group1将数据回传给SVC I/O Group2
6.SVC I/O Group2将数据结果传至主机
所以可以看到AUX卷所在站点的主机需要跨站点读对端存储，存在1倍的RTT，而MASTER卷所在的主机读IO和单存储性能相差无几。
写：
Site1写I/O
1.主机向Site1的其中一个SVC节点2发送写I/O请求
2.该SVC节点2将写I/O写入缓存
3.该SVC节点2将写I/O同步至节点1缓存，并同时通过MM发送写I/O至站点2的节点3和节点4
4.SVC节点1、3、4陆续回复节点2的写响应
5.SVC节点2回复主机写响应
6.两个站点的SVC节点分别将缓存写入各自站点的存储当中
Site2写I/O
1.主机向Site2的其中一个SVC节点3发送写I/O请求
2.该SVC节点3将写I/O转发至Site1的任意SVC节点2
3.SVC节点2将写I/O写入缓存
4.该SVC节点2将写I/O同步至节点1缓存，并同时通过MM发送写I/O至站点2的节点3和节点4
5.SVC节点1、3、4陆续回复节点2的写响应
6.SVC节点2回复SVC节点3的转发响应
7.SVC节点3回复主机的写响应
8.两个站点的SVC节点分别将缓存写入各自站点的存储当中
同理，AUX卷所在站点的主机需要跨站点写对端存储，并且回写AUX卷底层存储，总共存在2倍的RTT，而MASTER卷所在的主机写IO和单存储性能相差无几。
所以很明显，SVC HYPERSWAP的SVC节点是跨站点双活，而存储则为ACTIVE-STANDBY。
(3)NetApp MCC
MCC的双活方式实际上是两个数据中心的存储互为镜像，各自提供不同的存储服务。
对于AGGX来说，为站点A的主机提供本地读和本地写，并通过集群节点的NVRAM写日志同步至站点B，维持数据一致性，也是等到日志达到水位线，刷入底层存储当中。
对于AGGY来说，也是类似，为站点B的主机提供本地读和本地写，并同步NVRAM的写日志至站点A。MCC通过这种方式实现两个站点存储的双活，MCC集群节点也是双活，但对于某一应用主机来说，实则只在一个站点活动。
性能方面，MCC的读性能和单存储类似，写性能存在1倍的RTT。
(4)SVC Vplex Metro
Vplex Metro和其他三种方式都不一样，是一种分布式的存储双活/多活架构。Vplex没有写缓存，有了分布式缓存，标榜为access anywhere
没有写缓存就意味了，主机对VPLEX的写是透写模式，主机的写IO只是经过VPLEX的虚拟化直接落入到底层存储，并在分布式缓存目录表中记录这个写IO是通过哪个VPLEX引擎写入的。当需要对该数据块进行读操作时，先是在分布式缓存目录中查找数据块是通过哪个VPLEX引擎写入的，然后再通过本地的VPLEX引擎转发该读请求至上一次写入该数据块的VPLEX引擎，通过它来读取它后端的存储，最终原路返回。另外，对于写入的IO，透穿过VPLEX写底层存储时，还将同步一份IO副本至另一VPLEX引擎的底层存储。
所以可以看到，对于某数据中心VPLEX的读操作来说，如果刚好上次该数据块的写操作时也是发在该VPLEX中，那么读是本地读，亲和性好。如果刚好上次该数据块的的写操作不是在该VPLEX，那么就需要跨站点进行读操作，亲和性弱，存在1倍的跨站点RTT；对于写，都是本地写，只不过需要将该写IO同步至另一站点的底层存储，也存在1倍的跨站点RTT。
好了，写了这么多，将几种主流的存储双活架构的读写操作流程写清楚了。简单对比如下：
由这张图可以看到：
读性能：
SVC ESC、HDS GAD和NETAPP MCC都是本地读，性能最好，而SVC HYPERSWAP和SVC VPLEX METRO的本地读不“稳定”，某些情况下，存在跨站点读的问题，增加了读响应时间。
写性能：
基本上所有的存储双活方案都存在写往返延迟的问题，最少为1倍的RTT，其中SVC ESC、HDS GAD、NETAPP MCC、SVC VPLEX METRO都存在1倍RTT，这是无法避免的，可以说是存储双活的必然问题，而SVC HYPERSWAP某些情况下，存在2倍RTT的问题，写性能影响更严重。
当然评价一个存储双活方案，不能仅从性能影响去看，更应该看重其综合能力，这里不再赘述。
本文地址：
http://www.talkwithtrend.com/Question/404829
点击阅读原文，关注社区 “存储双活”技术主题 ，将会不断更新优质资料、文章，您也可以前往提出疑难问题，与同行切磋交流。
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
长按识别二维码即可下载
或到应用商店搜索“twt”
*本公众号所发布内容仅代表作者观点，不代表社区立场