有关rac.raw.asm.ocfs2的讨论

以下内容摘自chinaunix.net




RAC环境，如果不是用raw, 在生产环境还是应该选择ASM.无论从性能，目前各自版本的成熟度，厂商研发投入和支持力度，最佳实践以及成功案例，现在这个阶段都不应该在生产系统中使用ocfs2.

gfs 和ocfs2是一种东西,  和ocfs, gpfs不是一种东西. ocfs 和当中的任何一种都不一样.

gfs/ocfs2 使得多个节点访问共享存储的同一个位置成为可能，他们通过普通网络建立不同节点上文件系统缓存的同步机制，通过集群锁，杜绝多个节点的不同应用操作同一个文件产生的竞争关系从而破坏文件的可能性，通过普通网络交换节点之间的心跳状态. 这是功能上的类似。从成熟度，性能来考虑，目前ocfs2还远不能和gfs相提并论，能够用ocfs2的地方都可以用gfs来替代，但是反之就不行.  gfs在 HA集群环境，担当了一个"廉价缩水版"的polyserv.   至少目前来看，我个人的观点是gfs在技术，成熟度，开发力量投入，性能上都要领先ocfs2 差不多3年左右的时间.而且这种差距可能进一步拉大.


ocfs2是一个clusteraware 的文件系统，在每个RAC node上都有instance运行，并通过网络通信+lock的机制,确保不同的node对同一个存储区域的读写是在控制下进行并且所有的node通过 ocfs2 instance知道谁写了/谁读了. 所以ocfs2 filesystem的完整性是有保障底线的.
当你把ocfs2创建在LVM上的时候，LVM的 control在不同的node上是各管各的，由每个node的OS和LVM module自己来控制，node之间的LVM 并不通信，他们都是独立的，不排斥不加锁得去访问/操作共享存储上的区域，虽然你可以从每个node上用lvm工具scan到共享盘阵上的pv/vg /lv,但是一旦涉及到读写操作，所有的node便完全孤立来做了.所以LVM metadata 的读写就变成一个严重的问题.
所以 ocfs2+LVM 用在RAC的数据共享上是不可取的.
HA里面用LVM 很常见，但是都是一头用一头锁的，RAC那种需要同时访问操作的，我恐怕就不是这样简单了.
yep, ocfs can only be used in RAC environment,  ocfs2 is different, Oracle make it to be a general cluster file system for normal application.



ocfs是只能for oracle的，也是oracle把集群文件系统纳入发展视线的第一个版本，之前我也说过，这个版本当时并没有定位在通用集群文件系统上，无论是质量，性能，稳定性等等在oracle用户圈子，反面的意见占大多数.

即便是在今天ocfs2的阶段，oracle mailing list, forum上大量充斥对于ocfs2质量，性能和可靠性的投诉.

ocfs1不能直接升级到ocfs2, 如果以后要升级，需要做DB的导入导出操作.ocfs1的 bug在网上比比皆是，触目惊心.
说白了，你们这样的架构的选择，最后就是给施工单位/人员和客户自找麻烦，痛苦的还在后面呢.

ASM 是Oracle 在 linux, HP-UX, Solaris 等多个商用高端Unix平台采用的新一代存储管理系统，在Oracle公司的产品地位，开发的投入，用户范围，适用的层次和领域都是ocfs2项目无法比的.
ASM在功能上，相当于 RAW+LVM. 在数据量和访问量的线性增长关系上，表现也很出色，在实际的真实测试环境中，ASM的性能基本接近RAW, 因为还有Volume 开销，所以性能上有一点点地开销，也是很容易理解的. CLVM+OCFS2的性能在线性增长的测试中，明显低于ASM和RAW. 前天我一个朋友给我发来了他在欧洲高能实验室一个年会上作的slide,他们实验室的IT部门统计了一下，整个实验室各种单数据库和集群加起来，现在有 540多个TB的数据跑在ASM上面，经过重负荷的使用和测试，他们对于ASM是表现是相当满意的. 他们大部分的系统是IA64+linux和AMD Opteron+Linux.


ASM的性能基本上和RAW差不多. 但是管理性上好很多很多。但是牺牲的代价就是引入了系统的复杂性，多了一层东西，问题出现的几率也大很多.

生产系统,不要用ocfs2. raw+ASM就可以了.目前的RAC环境，看不出有任何理由在生产环境用ocfs2的必要.

RAC涉及到存储的就是2个个地方，一个是OCR和voting(以及他们的redundant config),另外一块就是Oralce Data和Flashback recovery area.
现在Oracle的RAC配置一般是两种  raw(ocr+voting)+ASM(data+flashback recovery area),另外一种是 ocfs2+ASM
OCR和 voting 占用的空间很小，根本没有必要在用了ocfs2的下面用一个OS的LVM来支持，就算你那样做了，也是错误的，因为目前OCR和voting 都需要存储是clusterware的，这也是用raw或ocfs2的原因，你用lvm+ocfs2的话，底下的OS LVM不是clusterware的，所以就会把你的数据破坏掉，这个话题是一个很老的话题了，你到oracle forum去搜，或者有metalink账号的话你看看就知道了，没有意义多讨论.

如果你用 OS LVM+ocfs2 用来放 Data+Flashback Recovery Area,我建议你还是不要这么干，不是说不可以，只不过ocfs2实在是很脆弱，你有订阅 ocfs2的maillist 么？ 去看看吧.
Data+FRA用ASM 或RAW都很好，无论是性能上还是管理上，还是可靠性尚.


oracle 没有说best practise 建议你用ocfs2, 实际上在社区没有一个oracle得人敢出来说ocfs2 你们放心用在生产环境把.
RAC安装从来没有推荐过用ocfs2, 你看Oracle RAC的产品经理在oracleworld上的发言了么？说得很清楚.


一点补充，

ocfs2还是一个处于开发初始阶段的系统，虽然名字有一个2，但实际上是第一版支持general purpose的集群文件系统。ocfs2用来做生产系统是不明智的(见我的帖子)和不正确的。ocfs2现在用的话，你根本无法lock down一个stable set.



我的voting /orc 用 raw , 10gr2有 redundant 的配置，所以raw比较方便，而且因为尺寸都很小，所以需要额外backup的时候也很方便.

voting/orc 用raw与否，对于运行性能没有太多影响，但是当集群因为不稳定的时候，系统开始做node membership的变动的时候，性能上还是有区别的.datafile 在linux平台用raw存放显示不出性能优势，用ASM性能上面有保证.


如果要部署RAC, 如果需要快速完工并且在这方面经验欠缺的话，Oracle  提供的 "Oracle Validated Configurations" 是一个最好的帮手。
Oracle刚开始推出 OVC的时候，我觉得特别特别好，即便是对于非常熟悉linux/oracle/RAC得人来说，也是一个大大减轻工作量的好工具.
搞不清楚状况，被工作任务紧逼的朋友，可以完全按照 OVC来完成任务，已经做好RAC并且碰到故障问题的时候，也可以按照 OVC来做排查参考.
Oracle Validated Configurations
... urations/index.html