RAC平台物理机与虚拟化平台选型分析.docx

?

?

RAC平台物理机与虚拟化平台选型分析

?

?

生产环境准备搭建Oracle12cRAC，是直接在物理机上搭建还是在vSphere虚拟化平台上搭建？

生产环境准备搭建3节点Oracle12cRAC实现高可用。

现在有两个选择：

一个是直接在物理机上搭建，少了虚拟化平台这一层效率更高，但是管理不便，某节点故障之后需要重新配置，耗时较长，心跳网络还需要单独布线。

二个是在vSphere虚拟化平台上搭建，可以直接通过vCenter进行远程管理，某节点故障之后可以通过虚拟机克隆快速恢复，心跳网络通过虚拟交换机即可，但是担心稳定性及效率，还有据说虚拟化平台上搭建的racOracle不提供技术支持。

还有就是共享存储已经做了存储级别的主备同步，是否还有必要做Dataguard进行数据库级别的主备同步？原因呢？

还望各位大佬不吝赐教，给出最佳的生产环境实践方案。

问题来自社区会员@Stewart某银行项目经理，问题发布于后，很多同行分享了观点，目前原题主所在企业已经完成了搭建，并在下面的讨论中反馈了几点经验供大家参考。

下文来自twt社区众多同行实践经验分享，欢迎大家参与交流，各抒己见。

*“争议”栏目内容来自同行分享的一手体验和观察，仅代表个人观点

@岳彩波产品经理：

不建议在虚拟环境搭建RAC和数据库，前期看似省钱，后期维护问题较多，增加了太多的不确定性。

@韩成亮?数据库管理员：

关于是否使用虚拟化平台搭建RAC集群还是物理机，这个问题是多方面的考虑，使用虚拟化确实有你说的这部分优点当然也存着缺点，是否使用需要你综合考虑，比如说人力成本，授权成本(包括RAC和vSphere)，技术成本（部署一套RAC会涉及服务器、存储设备、HBA卡、操作系统等多方面的技术）所以你的考虑不无道理，使用虚拟化部署方便了管理（这部分的管理其实占比很少，你的操作总归是通过命令行来执行）却存在一定的性能损耗，而且会有木桶效应，总归还是需要满足业务，业务才是你这套环境的存在价值所在，如果不放心可以进行对比压力测试。

至于你说的DG，是必要的，要时刻有危机感，虽然不一定会发生。

个人建议使用物理机器部署三节点RAC+多路存储冗余（非存储级别主备，使用ASM故障组，多路存储冗余）。

@潘延晟?系统工程师：

首先是看你的业务量。如果你的业务量比价庞大，对运算、IO、还有网络的需求都比较高，物理机运行都有些吃力，那就建议在纯物理环境下运行。

其次看技术能力对那种方案驾驭的更好，是对虚拟化环境更熟还是有很强的DBA管理数据库，系统运行的稳定除了成熟的技术手段，良好的运维也是很关键的。

第三就是根据企业的自身特点、资金投入、技术能力综合考量所需要的架构。随着X86架构性能的提升，X86架构的虚拟化平台也有了很大的发展，传统的虚拟化架构运行数据库时的问题也可以通过多种技术手段来避免。比如提高X86整体硬件的配置，采用万兆或者10万兆的网络减少网络影响，采用oracleasm来避免虚拟化层的IO损耗，通过vmwarevmotion来实现多机的动态迁移，存储级别的和数据库级别的主备同步则可以根据你实际的容灾数据中心情况、技术能力还有业务的重要程度来决定。

数据库作为信息化最为核心的部分。自然是要竭尽所能去保证它的稳定运行和安全可靠，往往随着业务变得越来越重呀，技术架构也变得越来越复杂，对运维技术，资金投入也越来越高，多数时候对技术的选择最后都是受限于资金和能力上。

传统意义来说，体量较大的数据库业务并不是很建议在虚机上运行RAC。

@eximbank某金融企业系统架构师：

根据业务数据流量来定，而不是根据运维的简便来搭建。您得先咨询业务应用！

@贺磊山西英伦斯顿?数据库开发工程师：

如果物理机资源不够的话，可以在VMware上搭建。建议在物理机上搭建。

@杨文云GBS数据库管理员：

第一步确认一下vSphere是不是Oracle认证的虚拟平台，不是的话出现问题Oracle就作为一般的RAC问题处理，底层的问题不提供技术支持。

共享存储已经做了存储级别的主备同步这个不太明白，可以直接切换数据库提供服务么？还是只是一个数据的备份。一般情况非ADG不会直接切换数据库启动，几分钟就可以接管服务。

@asdf-asdfcloudstone研究学者：

1、看你业务需求。见到过vmware上双机rac，运行良好。

2、如果vm性能无法承载rac数据库，进行物理机部署也相对简单。

3、小型机rac下移，见到过3几点x86rac，保证性能可用。

4、dataguard备库技术，看你容灾设计，如果需要数据库容灾或者需要数据库异地容灾，可部署，对数据库进行高度数据保护也可部署。

@bryan金融研发软件架构设计师：

依据生产经验，建议直接