从Oracle RAC角度看跨数据中心的存储双活配置注意事项

共计 3175 个字符，预计需要花费 8 分钟才能阅读完成。

Oracle RAC 在设计的时候是没有考虑跨数据中心双活的，它的设计目的是为一个数据中心内有着共享存储的多个主机实现负载均衡和高可用性。但是由于它的架构确实有着跨数据中心实现负载均衡和高可用性的潜力，所以有几家存储设备供应商对它的使用环境做了扩展，提出了跨数据中心的解决方案。Oracle 对此采取了默认的态度，但是建议所有的解决方案在投入客户生产之前进行仔细的测试。

对于 RAC 而言，跨数据中心解决方案的最大瓶颈是节点之间的 interconnect，因为它对时延和带宽的要求都非常高。一般而言，本地 interconnect 传输时延在 1~2ms 之间，本地 IO 的延时则在 8~15ms 之间。这两个时延对性能的影响相当大，如果使用双数据中心方案，随着机房距离的增长，它们都会严重影响性能。而且由于 interconnect 的时延基数低（1~2ms），导致机房距离产生的时延对整个 interconnect 影响的占比更大：想想如果因为距离延长导致 2ms 的传输延迟，对于 interconnect 就是 100%~200% 的延迟增长，对于 IO 则只有 15%~25% 的增长。当然，随着 SSD 在存储中的大量使用，距离对 IO 的影响也在加大。

为了直观展示传输距离对 IO 和 interconnect 延时的影响，图一和图二显示了 HP 的测试结果作为参考：

图一

图一显示的是 IO 时延受距离影响的结果，这个测试结果是在 Buffer-to-Buffer Credits(BBC) 功能打开情况下取得的。BBC 功能可以让大量的未应答的数据包保存在缓存的同时继续发送数据包。在数据流量很大的情况下，距离越远，BBC 的作用越大。

如果在距离 100km 的情况下，打开 BBC，IO 延迟与本地相比大约为增加 43%；如果不打开 BBC，IO 延迟大约增长 120~140%。另一个厂家的测试表明，在 20km 的距离下，不打开 BBC 将会导致流量下降 20~24%。

图二则是分别使用高负荷和低负荷对配置一条或者两条 interconnect 的 RAC 进行测试，考察了距离对 interconnect 的影响。

图二

图二这个测试有两个发现：

1.        两条链路与一条链路相比，在高负荷情况下可以大约降低 50% 时延

2.        100km 可以带来大约 1ms 的时延增加。

图一和图二显示的是距离对链路的影响，下面的图三和图四则展示距离对 RAC 整体性能的影响。

由于在远距离传输过程中，Buffer-to-Buffer Credits(BBC) 功能对传输性能影响很大，所以需要强调图三展示了两个厂家在打开 BBC 功能情况下取得的测试结果。同时作为对比，图四展示的是没有打开 BBC 功能的测试结果。

从图三和图四中可以看到，打开 BBC 的情况下，两个测试厂商在的方案性能都相当不错。但是如果不打开 BBC，随着距离延长，性能会有剧烈下滑。考虑到同机房配置比较好的双节点 RAC 性能大约比单节点高 30~60%，如果因为远程机房 RAC 集群出现大于 20% 的性能下降，就要慎重考虑是否使用 RAC 方案了。

还有两点需要注意的是：

1.        各厂家给出的测试结果往往是在极致优化的情况下测得的最佳数据，实际客户现场的优化程度往往大幅低于厂家测试环境

2.        厂家往往只会给出对自己最优的测试结果。比如图三中两个厂家给出的测试距离范围是不一样的，原因可能是超出该范围，性能会有较大的下滑。

基于上述测试，Oracle 建议基于连接机房的线缆的距离考虑是否采用 RAC 双活方案：

1.        距离小于 50km 的机房，可以考虑使用双活 RAC。

2.        距离大于 50km，小于 100km 的机房，慎重考虑使用双活 RAC。如要使用，需要进行非常慎重的测试。

3.        距离大于 100km，不建议使用双活 RAC，可以考虑 RAC one node 做高可靠集群①。

① RAC one node 是 RAC 的一个变种，效果有点类似传统的 HP MC/SG + Oracle 方案，由于同时只会有一个节点在运行，不会有大量数据跑在 interconnect 上。

如果决定使用跨数据中心的 RAC，如下配置建议需要慎重考虑：

1.        interconnect 和 IO 链路使用非共享的，端到端线缆直连，英语称之为”Dark Fibre”。

2.        强烈建议在传输通路上打开 BBC 功能。

3.        在 Oracle clustware 里配置 3 个 voting disk 或者 voting file。两个数据中心各配一个 voting disk，另外在第三机房配置一个基于 NFS 或者 ISCSI 的 voting file 以提高 RAC 系统可靠性。

通过之前的测试结果，前两点建议比较容易理解，下面我们对对第三点建议做一个详细阐述：

如果不配置基于第三机房的 voting file，当两个数据机房的链接断开之后，两边的主机都只能访问本地存储，而不知道对方状态。此时因为没有第三方仲裁，两边的 RAC 主机都会退出集群，从而导致业务中断。因为如果不这样，将会导致数据紊乱，后果更加严重。

远程 voting file 的配置考量：

一般而言，Oracle clustware 每秒通过读写少于 1 千字节的数据方式访问 Voting file 一次。每个写请求 IO 的应答应该在 200 秒内（缺省，long disk timeout）或者 27 秒内（可配置，short disk timeout）返回。为此，Oracle 建议 voting fiel 的写 IO 应该在 14（27/2）秒内的时间内返回，传输带宽至少 128k bps。

存储双活与 RAC 集群的仲裁竞争问题

l  对于 HP XP7 而言，因为使用了虚拟磁盘阵列技术，只需要把 voting disk/file 配置到虚拟磁盘阵列上，就可以避免出现竞争。因为访问不了虚拟磁盘阵列上的 voting disk 的 RAC 节点是不可能被 RAC clusterware 仲裁为活着的。这种情况下不需要 RAC 配置远程 voting file。

l  对于 HP 3par 这种使用 ALUA 协议的准存储双活方案，因为 RAC 节点只同时使用一个物理阵列，结果与 XP7 类似，只要把 voting disk 都配置为 peer persistence 卷，就可以避免仲裁冲突。这种情况下不需要 RAC 配置远程 voting file。

l  对于其它没有使用虚拟磁盘阵列技术的存储双活方案提供商，特别是做了本地读写优化的提供商，这是一个需要非常慎重考虑的问题。因为大部分这种存储双活方案提供商的仲裁是使用第三地点的虚拟机实现的，个人建议将这个虚拟机与 RAC 的第三个 Voting file 尽可能物理接近，减少物理因素差异造成仲裁结果冲突的可能性。

l  有的存储供应商提供通过手工调整仲裁算法的方式保证存储仲裁结果与 RAC 相同。对此因为没有详细资料，所以不便评论，但是 Oracle 官方对此持反对态度。

参考书目：

《Oracle RAC and Oracle RAC One Node on Extended Distance (Stretched)Clusters》

《Using standard NFS to support a third voting  file for extended cluster configurations – OracleClusterware 11g Release 2》

《Oracle Clusterware Administration and Deployment Guide》

《HP 3Par Remote Copy Software User’s guide》

更多 Oracle 相关信息见 Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12

本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2017-04/142643.htm