实际上无论在哪个操作系统(AIX,HP-UX,Solaris,Linux)上安装Oracle10g RAC都不再需要Vendor Clusterware(IBM的HACMP,HP的Service Guard,Veritas的VCS等),无论在存储方面是选择裸设备还是ASM或者是操作系统厂商提供的共享文件系统,比如AIX上的GPFS。

  那么为什么提到AIX,如果一定要选择裸设备(此处提到的裸设备指纯裸设备,因为ASM实际上也是在管理裸设备)作为Oracle数据文件存储方式的话,我们建议安装HACMP呢? 是因为AIX操作系统的特殊性,在AIX操作系统上,每个字符设备(对应一个rhdisk)只能对应一个存储上划分的LUN,而其它操作系统则可以在LUN上继续细分字符设备,比如LUN是128G,那么在AIX上每个rhdisk都只能是128G,每个rhdisk也就是一个裸设备,而其它操作系统则可以继续在这个LUN上划分出多个裸设备,大小可以自定义。

对于Oracle RAC来说,每个控制文件,每个联机重做日志文件,甚至spfile都要对应一个裸设备,那么如果在存储规划的时候我们创建了128G的LUN,那么在AIX上我们只能做成一个128G的控制文件,一个128G的联机重做日志文件,一个128G的spfile,因为单独依靠操作系统我们无法再细分了。

  在AIX操作系统中,必须使用LVM(Logical Volume Manager)来划分LV(Logical Volume),每个LV的大小是可以控制的,在一个LUN上我们可以划分多个LV,因此在操作系统级别达到了规划存储的目的。此时HACMP的作用体现出来,如果要挂载Concurrent Volume Group(实际上不需要HACMP也可以创建LV和VG,但是却无法将VG设置为Concurrent模式,而非Concurrent模式的VG是无法被多个机器同时读写的),就必须安装HACMP,因此更严格地说,这种方式的存储应该称为Raw Logical Volumes,而不是Raw Disks,这两种都是Raw Devices。

实际上,如果我们在存储级别就详细规划LUN的大小,比如创建4个128M的LUN,1个给spfile用,3个给控制文件用,再创建8个256M的LUN,给8个联机重做日志用(4组,每组2个member),然后再继续规划用于SYSTEM表空间的,用于SYSAUX表空间的,用于UNDO表空间的,用于用户数据表空间的LUN分别是多大,那么也仍然可以不需要HACMP就在AIX上搭建起以纯裸设备为存储介质的Oracle10g RAC数据库。

  结论是,因为Oracle Clusterware的存在,在本质上,无论选择什么存储方式,在任何操作系统上都不再需要第三方的集群软件。

  最后再提一下ASM,对于ASM来说,底层可以是raw disks也可以是raw LVs,但是推荐是raw disks,因为本身ASM已经行使了类似于LVM的功能,因此无需再创建多余的LV了,而如果不选择ASM,那么就建议使用raw LVs。