oracle rac 数据同步原理,从HDS VSP G1000的ORACLE RAC双活测试报告了解其实现原理

大家周二好。

今天有一点点时间，因此和大家来学习一下HDS VSP G1000的双活原理。

大家知道，高端存储的双活，最重要的应用场景应该就是和ORACLE RAC配合了，因为关键业务大部分都采用ORACLE RAC数据库。

HDS在2月2日发布了一个VSP G1000和ORACLE RAC的双活测试的技术笔记，我们今天通过这个文档简单了解一下VSP G1000的GAD技术实现的一些原理和细节。

这个是测试的解决方案的环境。采用了两台IBM P770小型机，配置还是很高大上的。从这个图中，我们看到除了两个VSP G1000外，还有一个阵列HUS-VM，放在第三个站点，作为仲裁设备(Quorum device)使用。我们看到，目前主流的双活解决方案中，都需要仲裁设备，因为这样可以防止脑裂，保证数据的一致性。据说国内个别厂商的双活方案居然没有这个仲裁机制，这样的产品还是不建议大家用，如果要用，就部署在一个数据中心里，否则数据的一致性很难得到保障。

上图中黄色的ANUE是网络仿真的设备，可以仿真数据中心的距离。这次测试，HDS分别仿真了三个距离：0KM，50KM和100KM。

西瓜哥在去年上海HCC大会看到华为的双活数据中心演示的时候，华为采用的100KM的物理光纤，类似下面8大盘，可能更有感觉一些。

每个VSP G1000采用RAID 6，划分为32个RAID组。硬盘采用200多块15K的SAS盘。

而IBM P770小机，每天物理服务器划分成两个LPAR分区，每个LPAR运行一个ORACLE实例，因此一共有四个实例。

IBM小机的OS是AIX，多路径软件采用的是HDS的HDLM(Hitachi Dynamic Link Manager)。HDLM非常关键，它把下面两台VSP G1000的GAD看成一个设备。也就是说，主机看到的是一个LUN，而不是两个。

系统正常工作的时候，主站点只有一半端口有流量，另外一半端口是没有流量的。从站点也一样。只有故障切换的时候，多路径软件才把流量引到另外一半端口。两台VSP G1000的流量通过同步复制进行同步。

这个就是主站点故障后流量的流向变化。

HDS在测试的时候采用Swingbench软件来进行负载模拟(华为在上海HCC大会采用真实的银行应用做的演示)。

下面列出HDS实验室使用的软件和其版本。

Swingbench模拟订单的生成，HDS首先模拟订单之间有延迟的情况(延迟时间是850-1050ms之间)。这个应该比较符合日常现实的情况，因为一般情况两个订单一般是有一些间隔的。

我们从测试结果看到，不管距离是0KM，50KM或者100KM，每分钟处理的订单数基本都是66(除了最后一个100KM的情况略有出入)，不管是双活状态，切换状态还是回切以后都一样。这个说明存储没有成为瓶颈，因为订单不多。

如果把订单之间的延时取消，就有点像双11晚上零点，大家都集中下单的情况。我们看到压力上来了，系统每秒可以处理3000左右的订单量。

但比较奇怪的是，0KM的情况并不是最好的，最好的情况是50KM的双活正常的状态，每秒处理4843个订单。甚至100KM的情况都比0KM的情况好。

这个情况好像不太好解释。HDS的测试报告也没有说为什么出现这种情况。西瓜哥初步分析，就像我们跑马拉松一样，有一句话叫欲速则不达。0KM的情况下没有时延，可能链路上有任何积压都可能造成流量控制发生作用(负反馈)，而50KM，可能各个系统部件的工作速度比较协调，基本没有流量控制，因此性能最好。就像跑步你需要配速一样，找到自己合适的步伐，那么你就会跑得更远。当然，西瓜哥也是猜测，不知道真实情况是否如此。

好，我们最后总结一下。

1、HDS VSP G1000的GAD功能最长确实可以支持100KM了；

2、但必须采用HDS的多路径软件HDLM来配合；

3、数据中心的距离越近不见得性能就越好(这个也可以看出HDS的GAD方案还有优化空间)。

今天就分享到这里。下次见(这里不写明天见，因为今年可能很难承诺每天一篇了。)