提及甲骨文产品，鲜有话题能够像Oracle许可带来这么多的争论和困惑；而在Oracle许可方面，最令人纠结糟心的，莫过于如何在VMware环境中获得Oracle产品的许可。有关这方面的说法流言满天，彼此矛盾；来自Oracle的信息也是不一致、不清晰或完全不合理。这就变成用户想在VMware上运行Oracle产品，却无法获得准确细节，还可能面临被Oracle审计、处以百万级美元罚款的风险。

客户和潜在客户经常谈及Oracle销售人员采用的“恐吓”策略，要他们不要用VMware，否则许可成本可能会是一个天文数字，需要给整个环境内所有集群的所有服务器购买许可，哪怕Oracle产品只是在一个微不足道的集群内角落边缘的一台服务器上运行。

来自各方的专家（博主、专栏作者、论坛高手等）对此也是众说纷纭，彼此相斥的信息更是让大家莫衷一是。VMware曾于2015年3月份发表白皮书《了解面向VMware环境中的Oracle认证、支持和许可》（英文版），就是想说明白在VMware环境下，Oracle许可应该如何使用。Oracle既没有封杀这篇白皮书，也没有拿出其他的说法。

这倒不是说，Oracle从未提供过这样的信息。事实上，Oracle提供了大量文档，试图澄清Oracle在许可政策的立场。但是，发布的文档，如2015年的《软件投资指南》（英文版）和2014年的《Oracle分区策略》（英文版），都很清楚地声明，这些内容“仅用于教育目的”，“不可纳入任何合同”，而且“不构成合同或者任何具体条款的承诺”。这样说来，这些信息其实也没有什么太大的帮助。

至于在VMware环境中的许可细节，Oracle似乎有意保持含糊。唯一稍有干货的文档就是Oracle主协议（OMA）（英文版）和《订购文档》（英文版）。前者定义了所有产品的一般许可限制，后者概述了针对特定产品的限制。这些文档还经常引用其他许可策略的参考文档，如《Oracle软件技术支持策略》（英文版）或《处理器内核参数表》（英文版），这两者都不包括关于该文档“不可纳入任何合同”的声明。

Oracle许可的基本概念

为了更好地理解Oracle许可的争议从何而来，让我们先回顾几个基本概念。首先是分区（partitioning），Oracle使用这个术语是指一台服务器内的CPU被分为区（section），或段（segment）。为了方便Oracle许可之用，有两种分区类型：

• 软分区（Soft partitioning）：操作系统资源管理器将操作系统进行分区，把CPU资源分配给一套应用。这样的例子包括Solaris 9 Resource Containers，HP Process Resource Manager， Affinity Management，Oracle VM和VMware。
• 硬分区（Hard partitioning）：服务器在物理上划分到不同的系统，每个系统独立存在，带有自己的CPU、操作系统、内存和其他资源。这样的例子包括Solaris Zones、物理域、逻辑分区和微分区（Micro-Partitioning）。

Oracle支持多种硬分区技术，用来确定所需的产品软件许可数量。但是，Oracle明确指出，软分区不能用来确定所需的Oracle许可数量。

Oracle支持两种Oracle许可：按照用户数（Named User Plus，即NUP）和按照CPU（Processor）数

按照用户数（NUP）授权需要确定用户和人数，通常用于较小、可控制的环境。

按照CPU数授权一般用于用户数不易确定的情况，如互联网应用。它是基于安装或运行Oracle产品的服务器具有的处理器内核数，而不是用户数。这种按照CPU数授权也正是争论不断的焦点。按照CPU数授权，就必须知道内核系数，它是用来确定所在环境中所需处理器内核数量的基础。可以参考Oracle官网提供的参数表，查询系数。只要知道该系数，乘以CPU数量，就可以计算出所需Oracle许可的数量。

单个服务器的Oracle许可

因为Oracle将VMware划为软分区（soft partitioning）技术，所以，虚拟机不能用来决定在其环境中运行Oracle应用所需Oracle许可的数量。在这种情况下，按CPU数适用于主机系统，即，根据Oracle的《软件投资指南》（SIG），“所有安装以及（或者）运行Oracle程序的处理器都必须授权”。尽管《软件投资指南》（SIG）是一个不具约束力的文件，它意味着，只要所有的服务器处理器内核被授权，Oracle就允许你在服务器上安装任意台虚拟机。

但是，如果只在一台虚拟机上运行Oracle产品，当然也就只有一部分的处理器分配给这台虚拟机，那该怎么计算？Oracle的政策对此规定很明确：所有的处理器内核必须获得许可。

不过，VMware的白皮书却不是这么建议。它说，客户可以使用vSphere CPU Affinity来限制虚拟机使用特定的内核，这样，只需这些内核获得许可。该白皮书还说，客户可以使用服务器的BIOS来关闭一些插槽，这样将减少需要获得许可的内核数量。

集群服务器的Oracle许可

如果Oracle许可在一台服务器上的虚拟机都这样错综复杂，那我们继续讨论集群，将会怎样？试想一下，从一台单个的主机转为整个集群，以及是否所有主机必须获得许可，即使你只是在主机群的一个子集上运行一款Oracle产品。

如果一个产品是安装或者运行在所有主机上，许可通常不存在问题。多数情况下，Oracle, VMware和其他厂商都认同按CPU数授权是要求所有机器都获得授权。虽然按CPU数授权是否也适用于Affinity之类的策略仍存在争议，但总的原则不变。Oracle不计算虚拟机的数量，只计算服务器和CPU数量。

但是，假设你只在主机群一个子集的虚拟机上运行Oracle产品，甚至仅在一台主机上运行，由于使用诸如VMware vMotion之类的技术，Oracle仍然希望你为集群所有的主机购买许可，甚至包括由vCenter服务器管理的所有主机，尽管它们所在的集群没有Oracle产品。

因为这些技术可能让虚拟机在主机之间进行移动，Oracle期望所有的主机都要获得许可。Oracle产品是否仅影响一台机器，这并不重要。虚拟机可能移到其他主机，似乎这是Oracle在近期一次审计中发现的问题，并威胁客户，如果主机无许可，将处以高额罚款。

虽然Oracle坚持一个集群内（甚至以外）的所有主机都要有许可是非常公平之举，但VMware的白皮书却说，仅仅许可子集的主机是完全可以接受的，因为你可以使用DRS Host Affinity规则在集群内限制虚拟机的移动，有效地使某些主机无法使用。通过这种方式，你只需要为Oracle产品将运行的那些主机获得许可。

到目前为止，我们还没有听到来自Oracle的任何消息（无论是销售团队、审计师或许可管理服务），表明Affinity是一个可以接受的选择。此外，那些同意VMware诠释的人也再次指出，Oracle的很多许可文件以及Oracle使用的语言具有非契约性，其中规定，“所有安装以及（或者）运行Oralce程序的处理器必须获得许可”。但对那些现在还没有运行Oracle程序、但可能以后会运行的处理器是否要获得许可，并未明确说明。

Oracle许可与VMware环境的纠结持续进行

目前大家对何为正确的行事方法还未达成共识，Oracle也还没有拿出精确合理的准则来帮助客户，而只是对服务器和集群提供一种极端的“全有或全无（all-or-nothing）”观点。但，Oracle仍拥有对许可违规进行高额罚款的权力，而与Oracle开战绝非易事。

即使围绕这些问题存在诸多模糊，很多客户还是会继续基于使用和实用性为Oracle产品购买许可，而不是基于可能进行部署的数量。如果遇到审计，他们唯一的希望就是归咎于合同缺乏清晰度，并动用律师团队。但，不完全遵从Oracle版本法规的做法，风险高，代价可能相当昂贵。

最后，Oracle的主协议和订购文档似乎是最终的文字版本，其中声明，它们将取代之前所有的口头和书面协议。但是，即使如此，Oracle还是留下了很多不确定的空间。当涉及到VMware许可，不要主观臆想，要确保公司的法务部参与进每个环节。Oracle已经把困难、混乱的许可流程丢给它的VMware客户群，这样的局面自然也无法很快得以改进。