甲骨文在其支持策略上不再明确地排除Real Application Cluster（RAC）产品能用于VMware服务器虚拟化。

这是迈向正确方向的一大步，IT人士表示。但是，将RAC带入甲骨文现有的用于甲骨文数据库的VMware支持策略时，就停滞不前了，意味着甲骨文仍然不能预知用户选择何种服务器虚拟化平台。该支持策略包括：

甲骨文的任何产品都不在VMware虚拟化环境中进行验证。甲骨文支持团队将帮助客户以下面方式在VMware上运行甲骨文产品：甲骨文只对在自身操作系统已知的或发生的问题，或者能证明不是由于运行VMware才出现问题的时候，才进行支持。

RAC不再是个特别的例外，这个事实至少表明甲骨文不再那么敌视VMware。但支持策略不是用户决定是否虚拟和如何虚拟甲骨文的首要因素。

甲骨文虚拟化的障碍

不管甲骨文对待VMware的方式如何，用户在独立的Oracle VM平台或者VMware运行甲骨文应用有着自己的想法。而且，在评估是否虚拟化甲骨文应用和数据库时，hypervisor平台的选择只是用户必须考虑的因素之一。

一些用户已经证实VMware的产品存在局限，所以他们避免虚拟化Oracle的RAC，而不是因为甲骨文的支持策略。

VMware对于附属在Raw Device Mapping（RDM）模式里的RAC集群共享SCSI总线的虚拟机不提供vMotion支持。因此，如果一台物理RAC服务器是处于维护模式，用户只能关掉Oracle虚拟机，才能将它们移动到另一台RAC集群节点，这在业务关键环境中违反了生产服务器级别协议。

另一些人指出，这也存在一些许可条例，在vSphere上运行Oracle之前需要考虑到，不管是支持还是技术问题。

例如Oracle Enterprise Edition版本仍然有个预配置处理器许可机制，尽管通常的策略是软件厂商实行的是预插槽或者预虚拟CPU许可策略来适应虚拟化。

不过，对于来自Sun或Oracle VM的硬分区有个例外，但是VMware不是硬分区，所以你得将与虚拟机相关的所有组件都进行许可。你可以限制虚拟机宿主的地点，但某些情况下这会让虚拟化失去意义。

然而，RAC支持策略的更改是“迈向正确方向的一大步，”Reiter说，“支持协议的更改将改变我们的计划，现在，如果一个客户来找我们，并想在我们的云环境中运行RAC，我们就能如他们所愿了。”他说，“虽然最终我比较希望看到一个许可模式能够与虚拟化技术协调工作。”

分享按钮