远程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已经能实现。

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