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

oldunix · 发表于 2008-7-28 23:49

原帖由 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:17 编辑 ]

biti_rainy · 发表于 2008-7-29 13:35

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

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

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

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

1：还是那个观点，双阵列对于 oracle来说是透明的，所以解决方案应该和 oracle 无关。因为oracle “可以不认识阵列还是本地磁盘”。只能说以前或许 veritas的解决方案最成熟，但在今天，存在其他成熟的解决方案。至于用户有特别的考虑要求双阵列，那和我们讨论的主题有了偏离。但因果关系是要搞清楚的，不能因了一个特殊的原因导致的既定事实，来说明oracle放在两个以上阵列上一定要采购 veritas的产品。

2：备份这种问题，不足以支撑购买昂贵的软件，script 足够方便了，scp 或者 rcp 一类足够放到同一个地方去。我们原来曾经有 nbu带库备份，就是一台linux本地挂一个scsi的15块磁盘的柜子（2万块都不用）做一个nas，同时接了带库，其他系统拷贝到上面然后远程调用这台linux上的 nbu 就完成备份，这样 agent 只有一个就够了。当然，这样的方法跟系统的规模和容量相关的。但不管怎么说，备份归档日子文件，对于oltp类型数据库我一般不觉得会有什么严重问题。所以如果这个用途用来支持购买这样的产品，我是不认同的。除非你是购买了这样的产品顺带用到这个功能。主次不能颠倒。

oldunix · 发表于 2008-7-30 01:36

原帖由 biti_rainy 于 2008-7-29 13:35 发表

1：还是那个观点，双阵列对于 oracle来说是透明的，所以解决方案应该和 oracle 无关。因为oracle “可以不认识阵列还是本地磁盘”。只能说以前或许 veritas的解决方案最成熟，但在今天，存在其他成熟的解决方案。至于用户有特别的考虑要求双阵列，那和我们讨论的主题有了偏离。但因果关系是要搞清楚的，不能因了一个特殊的原因导致的既定事实，来说明oracle放在两个以上阵列上一定要采购 veritas的产品。

2：备份这种问题，不足以支撑购买昂贵的软件，script 足够方便了，scp 或者 rcp 一类足够放到同一个地方去。我们原来曾经有 nbu带库备份，就是一台linux本地挂一个scsi的15块磁盘的柜子（2万块都不用）做一个nas，同时接了带库，其他系统拷贝到上面然后远程调用这台linux上的 nbu 就完成备份，这样 agent 只有一个就够了。当然，这样的方法跟系统的规模和容量相关的。但不管怎么说，备份归档日子文件，对于oltp类型数据库我一般不觉得会有什么严重问题。所以如果这个用途用来支持购买这样的产品，我是不认同的。除非你是购买了这样的产品顺带用到这个功能。主次不能颠倒。

关于1，你说的磁盘，本地或者是阵列，阵列也是本地的吧！我没说非要Veritas,但确实需要1个第三方集群软件，只是Veritas确实是比较好的，也可以说是最好！有些用户就是愿意为可靠性付账！

关于2，通过scp或者rcp、ftp之类传输，当然也可以用rsync来做，但传输后，从可靠性上来说，需要再次试验1下。你购买了第三方备份软件，还做不到无人值守，那对用户也太说不过去：第三方软件就是为了无人值守的，如果做不到，还不如直接写rman脚本来做。当然我们最近准备测试oracle的security backup。你说的主次颠倒，我没明白：其实用户的需求是分层次的，就象双阵列1样，象一些不允许关键时候停机的环境，用户就有这种想法，实现了对他们也确实有用。

本帖搂主讨论的就是基于veritas构建健壮的oracle RAC，怎能说我跑题！

如果不使用第三方集群，你怎么做个双阵列环境下的oracle rac?最好测试1下，让大家学习学习！

其实只用ORACLE crs ，做出来的RAC如果关闭主阵列（如果是2节点，就是含有1个VOTE盘的那个阵列），集群在1分钟之内，就会瘫痪！

关闭镜像阵列，肯定是稳定的，但这样没有消除单点故障!

HA的核心就是通过冗余来消除单点故障！怎能说双阵列无意义？

netbanker · 发表于 2008-7-30 05:27

oracle has integreated solution for RAC, so....

StudyCow · 发表于 2008-8-7 12:54

双陈列rac的性能,受到光纤连接的影响,可能会存在问题..

biti_rainy · 发表于 2008-8-7 13:55

原帖由 oldunix 于 2008-7-30 01:36 发表

如果不使用第三方集群，你怎么做个双阵列环境下的oracle rac?最好测试1下，让大家学习学习！

其实只用ORACLE crs ，做出来的RAC如果关闭主阵列（如果是2节点，就是含有1个VOTE盘的那个阵列），集群在1分钟之内，就会瘫痪！

关闭镜像阵列，肯定是稳定的，但这样没有消除单点故障!

HA的核心就是通过冗余来消除单点故障！怎能说双阵列无意义？

我就是没有搞明白，双阵列跟集群有什么必然的联系。那我就说，比如 aix下 lvm 的 mirror 功能一样可以让一个文件跨在两个阵列上做mirror，保障可用性啊。这个问题跟集群是两码事情。你无非使用了 storage foundation for oracle rac 而已。 storage foundation 有最基础的版本，额外组件有 for ha 和 for oracle rac 这样的，但双阵列和集群软件无关。

至于 vote，这个是不是可以使用 lvm 里面的一个 lv 作为 raw device来使用？如果可以这样用，那oracle就在 lvm 之上。

ha的核心是通过冗余来消除故障，我只是说在我们的几年经历中，高端存储还没有发生过无法提供服务的故障，存储发生故障的概率远低于主机发生故障的概率，因为存储里面几乎所有组件都是有冗余的，不像主机的单点那么多。当然双阵列当然可以提高可用性，按照这个思路，3阵列比双阵列还稍微有意义一点。其实总的来说就是可靠性要求几个9而已。双阵列上去，可以提高一个level的可用性，但oracle rac本身的其他环节引发的故障概率远大于这个方面，可能你只是把木桶边缘最高的一块再拔高了。但你有你的道理，我有我的做法，就这样而已。

btw：有一种情况除外，那就是如果你要选择一个中低端存储，可靠性保障比较困难，另当别论。

biti_rainy · 发表于 2008-8-7 14:04

原帖由 oldunix 于 2008-7-30 01:36 发表

关于2，通过scp或者rcp、ftp之类传输，当然也可以用rsync来做，但传输后，从可靠性上来说，需要再次试验1下。你购买了第三方备份软件，还做不到无人值守，那对用户也太说不过去：第三方软件就是为了无人值守的，如果做不到，还不如直接写rman脚本来做。当然我们最近准备测试oracle的security backup。你说的主次颠倒，我没明白：其实用户的需求是分层次的，就象双阵列1样，象一些不允许关键时候停机的环境，用户就有这种想法，实现了对他们也确实有用。

备份这个问题，根据具体的环境不同的投入预算，当然有不同的解决办法。要达到最高的可用备份，最佳就是有个standby，standby就可以解决将所有归档传递到同一个主机的需求。

至于 ftp 一类的不可靠，1，依然可以通过一些比较简单的校验，比如文件大小校验，来识别简单的错误。因为这种备份出错毕竟还是很少的，真出了错，在下一个全备周期内就可以解决掉了。

备份，从可靠性上来讲，都是需要验证的，无论你怎么做的备份，都要验证，第三方备份软件做备份也要验证！脚本只要写的足够健壮，当然可以不需要人去干预，偶尔做个检查就好了。只是你觉得更应该相信厂家，减少自己的麻烦罢了。当然，也许你客户更相信厂家。如果是我自己做，我无非是要权衡成本、管理便利等综合因素，不会只依靠厂家而已。

btw： nbu我们也有，storage foundation下周我们也要上线2套数据库，不过这2套是免费送的，veritas 跟我们沟通了好几年，现在决定试一下他们的产品。他们很希望我们能有机会检验下他们的产品。当然，用这个产品，最主要的原因是我考虑到未来多种存储产品的整合，必须要第三方软件来管理！