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

Posted 2020-07-16

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》

本文出自 “稀里哗啦的瞎说” 博客，请务必保留此出处http://leesbing.blog.51cto.com/1344594/1784197