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》