远程rac,比较难

下面的2张图是做远程rac(RAC on Extended Distance Clusters)的2种模式:

前者是host base的模式,近端数据库节点在读写的时候,同时读写近端和远端的存储,近端和远端的存储中的内容都是一模一样的;远端数据库节点在读写的时候也是一样,同时读写近端和远端的存储。这种方式的远端存储和近端存储都能被打开,可以采用oracle的ASM来实现同时读写多处存储的功能。

后者是array base模式,近端数据库节点在读写的时候,只写近端存储,远端数据库节点也只读写近端存储,近端存储通过存储管理软件,将近端的存储实时同步到远端存储,该技术主要运用的是存储的复制技术(如EMC SRDF)。远端的存储不能被打开。仅仅起到容灾的作用。

远程的rac,看上去很美,其实在实施起来的时候,代价还是很高的:

(1)首先要解决的网络的问题,网络要稳定,高速。要计算网络的时延,要确定数据库是读类型还是写类型还是混合类型,每次读写的吞吐量有多少。不同的节点在做cache fusion的时候,对网络的要求如何?

(2)如果采用host base的方案,那oracle会建议你使用asm,但是为了稳定起见,很多电信运营商的oracle版本还是9i甚至8i、7,要升级到10g,需要很大成本,包含程序代码的重新设计或者修正。而且在10g的rac中,如果发生故障,需要有voting disk决定如何重组cluster,这个就需要在远端和近端的基础上,再设置一个third site作为voting disk。且对于cluster软件的兼容性来说,如果采用的oracle 10gR2,最多能支持100个节点;如果采用veritas的cluster,最多能支持8个节点;如果用的是HP的SG,在10公里以内可以支持16个节点,在10公里以上只支持2个节点;在sun cluster上最多能支持8个节点。在部署的时候,就要得考虑是否使用原来已经安装的cluster软件,rac远端和近端之间的距离有多远。承载业务的节点数有几个。

(3)如果采用array base的方案,首先应用的连接会连到近端和远端的节点,对接远端的网络要求比较高。其次由于是采用存储级的复制,远端的存储不能打开。根据已经有的相关项目经验,为了稳定,一般应用只连接近端节点,放弃连接远端节点——这样,远端的节点,远端的存储就不能被很好的利用起来。远端的节点既然不用,但是却在消耗lisence的费用。远端的存储,我们用存储级的BC/CA已经能实现。

其实,说到底,能否实现,就一个“钱”字……呵呵

相关文章

2条评论

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据