想在linux运行健壮的Oracle RAC吗？- 内有biti精彩回帖。

oldunix

原帖由 biti_rainy 于 2008-7-28 22:15 发表


还是那句话，除了 dmp在多厂家存储上的不可替代性外，请举出其独到之处
我们可以探讨探讨，如果真发现非买不可的特长，我也好买点，还 symantec销售一个人情

就卷管理而言

如果是IBM环境，好像如果做双阵列软镜像，在1年半前，从IBM那获得的信息是存在一些问题的

sun环境的SVM，从我的实践看，也存在一些问题；

HP的环境我只在98年搞过hot spare(MC/SG),不太清楚

Linux环境，目前好像除了Veritas，没有其他的厂商提供方案

Veritas 的问题是产品卖得太贵，但从我2003年搞过的项目看，确实是最让我放心的！

如果有钱，建议还是用Veritas for RAC,肯定会有回报的

郑重声明：我不是Veritas的，仅仅是Veritas的用户：可以参看我在chinaunix上的帖子，

其实我何尝不想减少使用第三方集群，但在重大系统，还是可靠性说了算！

oldunix

原帖由 biti_rainy 于 2008-7-28 22:18 发表


    aix上使用 raw device 那也是在lvm上的 lv啊，这时 os上的 磁盘管理方式而已，怎么存在着oracle认证问题，这又不是 cluster filesystem 。  兄台可能把 lvm的概念混淆了吧

LVM仅仅是逻辑卷，解决的问题是物理盘（pv）方面的问题：文件如果大于物理盘、可靠性和性能

Oracle RAC是并行集群数据库，任何底层的技术，是需要认证的，就像Veritas的卷管理也一样：要不为什么Veritas的Vxvm要分出一项Cluster Vxvm(还卖得巨贵)

Solaris的zfs很不错，但现在谁敢将他用在数据库上？

[ 本帖最后由 oldunix 于 2008-7-28 22:39 编辑 ]

biti_rainy

说句实在话，在2008年的今天，卷管理也好rac也好，可靠的解决方案已经很多了，其实我跟一个symantec销售关系非常好，他手下也有一个从oracle跳槽过去的资深的工程师，但他就无法给我一个购买这个产品的理由，其实我也乐意找出要买的关键点好做预算，但一直没有成功


当然，我们都是 aix和linux 为主，我们是所有主机存储相关的硬件和选型都归dba负责的，所以我们必须了解所有细节。因为系统从头到脚都是自己处理的。

至于什么双阵列 lvm 有问题一类，这几乎是不可理解的， 这完全跟oracle没关系，是在oracle之下的 vg中的mirror 而已。ibm的人很少有同时清楚 oracle和 aix的，或许是因为一个不完全清楚原因的离子导致建议不确切也不一定。 因为 如果 mirror lv存在问题，那就是lvm的问题，跟oracle无关。


btw：  采用双阵列做mirror的做法，如果不是跨在异地(比如同城的mirror)做容灾，在本地这样做几乎没太大意义。 因为存储的可靠性一般是比较高的，如果同一个存储中做 raid10 再跨存储做mirror 太浪费了，还不如做个standby 再将redo log放再两个存储上方便呢。  如果存储做 raid5 再做 跨存储的mirror，这样性能影响比较严重。

biti_rainy

原帖由 oldunix 于 2008-7-28 22:34 发表


LVM仅仅是逻辑卷，解决的问题是物理盘（pv）方面的问题：文件如果大于物理盘、可靠性和性能

Oracle RAC是并行集群数据库，任何底层的技术，是需要认证的，就像Veritas的卷管理也一样：要不为什么Veritas的Vxvm要分出一项Cluster Vxvm(还卖得巨贵)

Solaris的zfs很不错，但现在谁敢将他用在数据库上？

你混淆了一个概念，为什么一定要用cluster filesystem  ？
用 raw device就不存在你这些问题了，只是管理麻烦点！

现在 asm 也越来越稳定，oracle  ocfs这种准垃圾东西是不如 veritas的 文件系统好，但  raw device你总不能说问题更多，asm在linux平台也用的很多了，veritas的在这方面的市场空间将更困难。

biti_rainy

早几年veritas  在电信这种地方卖的很好，主要是那时候很少替代方案，veritas的  vcs又确实做的非常好，但是它在新兴市场就没那么如意

一方面是因为替代的解决方案越来越成熟，另一方面就是它这个价格还很贵。

传统企业，一下子是不会轻易选择新的方案的，这是veritas市场的重点。

oldunix

原帖由 biti_rainy 于 2008-7-28 22:45 发表


你混淆了一个概念，为什么一定要用cluster filesystem  ？
用 raw device就不存在你这些问题了，只是管理麻烦点！

现在 asm 也越来越稳定，oracle  ocfs这种准垃圾东西是不如 veritas的 文件系统好，但  raw device你总不能说问题更多，asm在linux平台也用的很多了，veritas的在这方面的市场空间将更困难。

cluster vxvm和cluster file system 肯定不同！

我从前做的Veritas DBE/AC 就是用raw卷

归档在集群文件系统上（备份也比较简单，虽然我后来在没有买Cluster File system的RAC上用NFS及归档参数的值defer解决了NFS环境归档影响性能的问题）

asm的问题在于如果有个阵列关了（出故障），然后又恢复了，你要处理起来，可能够你喝一壶（在打开Solaris MPXIO的时候）我测试了，脑袋都大！

OCFS还是不错的，如果只用它来存归档，用raw存数据文件，在单阵列环境是低成本的解决方案

oldunix

原帖由 biti_rainy 于 2008-7-28 22:41 发表
说句实在话，在2008年的今天，卷管理也好rac也好，可靠的解决方案已经很多了，其实我跟一个symantec销售关系非常好，他手下也有一个从oracle跳槽过去的资深的工程师，但他就无法给我一个购买这个产品的理由，其实我也乐意找出要买的关键点好做预算，但一直没有成功


当然，我们都是 aix和linux 为主，我们是所有主机存储相关的硬件和选型都归dba负责的，所以我们必须了解所有细节。因为系统从头到脚都是自己处理的。

至于什么双阵列 lvm 有问题一类，这几乎是不可理解的， 这完全跟oracle没关系，是在oracle之下的 vg中的mirror 而已。ibm的人很少有同时清楚 oracle和 aix的，或许是因为一个不完全清楚原因的离子导致建议不确切也不一定。 因为 如果 mirror lv存在问题，那就是lvm的问题，跟oracle无关。


btw：  采用双阵列做mirror的做法，如果不是跨在异地(比如同城的mirror)做容灾，在本地这样做几乎没太大意义。 因为存储的可靠性一般是比较高的，如果同一个存储中做 raid10 再跨存储做mirror 太浪费了，还不如做个standby 再将redo log放再两个存储上方便呢。  如果存储做 raid5 再做 跨存储的mirror，这样性能影响比较严重。

据我测试raid10（无论软件还是硬件测试）是提高速度的
另外有些用户实在有钱，数据又不多

biti_rainy

原帖由 oldunix 于 2008-7-28 23:10 发表



cluster vxvm和cluster file system 肯定不同！

我从前做的Veritas DBE/AC 就是用raw卷

归档在集群文件系统上（备份也比较简单，虽然我后来在没有买Cluster File system的RAC上用NFS及归档参数的值defer解决了NFS环境归档影响性能的问题）

asm的问题在于如果有个阵列关了（出故障），然后又恢复了，你要处理起来，可能够你喝一壶（在打开Solaris MPXIO的时候）我测试了，脑袋都大！

OCFS还是不错的，如果只用它来存归档，用raw存数据文件，在单阵列环境是低成本的解决方案

我没有用 veritas的产品在生产环境，只是有同事测试过。 不管同或者不同，但这并不重要。如果你也要用 raw device又不用 vcs，那真没必要购买 veritas的产品 。

至于 归档的备份问题，这算是问题吗？ 如果你用 rman 备份到带库，同时连接多个节点就可以了。 最坏，script 拷贝到一个节点也不是大问题，没必要为这些事情要花那么多钱。

另外，你总在强调单阵列出故障的问题，我不知道你们使用什么存储产品，我们公司几年来从来没有在存储上出过影响数据库可靠性的故障。 其实存储的冗余是最容易做的，也是最可靠的，不知道为什么值得用两套存储来解决这样的低概率的问题，这样还不如做个standby来代替备份呢！ 如果存储本身在规划和采购的时候存在缺陷，那是另一回事情。

顺便说一下，我们使用过的存储产品包括  emc  cx200/cx300/cx500/cx700/cx3-40/cx3-80/dmx3 ;  hds  9570/ams1000/9970v/usp100    ;  ibm  ds8300
所有这些产品都没有出现过阵列完全因故障而实效的情况。因为存储几乎所有部件都是冗余并且可在线更换的。

biti_rainy

原帖由 oldunix 于 2008-7-28 23:17 发表


据我测试raid10（无论软件还是硬件测试）是提高速度的
另外有些用户实在有钱，数据又不多

我们只在存储上做 raid，从来不在os上做软raid（lvm  stripe除外），我们的数据库全部都是 raid10 ，只有数据仓库的历史数据采用 raid5


存储上是否提高速度的大方向，无非都是让 io 尽量均匀低分布到所有磁盘上。 所以 raid group中的 stripe 也好，还是 lvm中的 stripe（因为一个raid group毕竟磁盘数量有限，需要横跨多个raid group）也好，都是这样一个解决方案。 虽然有些产品自己可以解决这个问题，比如 hp eva，3par，emc 的 dmx中划分解决方案……  asm也在尝试解决负载均衡和 rebanlace的问题。 说来说去大家的思路都是一样的。


至于有钱数据又不多的，还双阵列＋  veritas， 可不就是挣这些用户的钱么。 今天一个供应商跟我讲，他一年做4千万的单子，我们公司2千万，大约只有10％多一点的利润。 而另外的其中1000万大约有 50％以上的利润。 所以我们公司是跑量的，那些地方是挣钱的。 你还别说，50％以上的利润，客户自己还分了个开心呢！

[ 本帖最后由 biti_rainy 于 2008-7-28 23:37 编辑 ]

oldunix

原帖由 biti_rainy 于 2008-7-28 23:25 发表


我没有用 veritas的产品在生产环境，只是有同事测试过。 不管同或者不同，但这并不重要。如果你也要用 raw device又不用 vcs，那真没必要购买 veritas的产品 。

至于 归档的备份问题，这算是问题吗？ 如果你用 rman 备份到带库，同时连接多个节点就可以了。 最坏，script 拷贝到一个节点也不是大问题，没必要为这些事情要花那么多钱。

另外，你总在强调单阵列出故障的问题，我不知道你们使用什么存储产品，我们公司几年来从来没有在存储上出过影响数据库可靠性的故障。 其实存储的冗余是最容易做的，也是最可靠的，不知道为什么值得用两套存储来解决这样的低概率的问题，这样还不如做个standby来代替备份呢！ 如果存储本身在规划和采购的时候存在缺陷，那是另一回事情。

顺便说一下，我们使用过的存储产品包括  emc  cx200/cx300/cx500/cx700/cx3-40/cx3-80/dmx3 ;  hds  9570/ams1000/9970v/usp100    ;  ibm  ds8300
所有这些产品都没有出现过阵列完全因故障而实效的情况。因为存储几乎所有部件都是冗余并且可在线更换的。

1、有些用户确实有要用2个阵列的需求，那就得为他们设计这样的系统:客户是上帝！我们现在讨论的是双阵列的情况
在我们公司工程师的基础就是存储：阵列及Brocade交换机、SANergy，StorNex文件系统，各种阵列都有包括常见的不常见的

2、归档方面的解决方法,你说的连接多个实例的方法我也用过，但也存在一些问题：如果你没有采用第三方备份软件，只用disk做介质管理器，你备份的文件会在两台机器上！即使你购买第三方软件，你需要购买足够多的备份软件客户端许可。

用我的那种方法，可以解决上面的这个问题，但也会带来新的问题：启动过程复杂一点
采用集群文件系统，就没有以上的任何问题！

[ 本帖最后由 oldunix 于 2008-7-29 00:16 编辑 ]