提及甲骨文產品，鮮有話題能夠像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客戶群，這樣的局面自然也無法很快得以改進。