Recently I had some discussion about how to license Oracle on VMware vSphere. I have done some research, and got some things clear.
With the introduction of the new competency Virtualization of Business Critical Applications (VBCA), VMware offers some great information (for VMware partners) on how to virtualize business critical apps, but also on how to license these apps.
So, how do things work. First of all, I have used the following documents:
- Understanding Oracle Certification, Support and Licensing for VMware environments by VMware;
- Software investment guide by Oracle;
- Oracle processor core factor table by Oracle.
Licensing Oracle
If you think about Oracle licensing, the way you license the software is dependent on the used licensed model:
- Oracle Standard Edtion and Oracle Edition One will be licensed based on the quantity of sockets containing a CPU. The number of cores on a CPU is irrelevant. Oracle SE supports a maximum of four sockets, Oracle SE one supports a maximum of two sockets.
- Oracle Enterprise Edition licensing is based on the number of cores, taking in account the the so called processor core factor. For Intel and AMD cpu’s this 0.5, see the Oracle processor core factor table document.
- Some applications are licensed through the Named User Plus licensing model. In this case you don’t have to think about number of sockets and cores.
What does this mean in the real world. Well let’s say you have a two socket, hexa (6) core ESXi server and you want to run an Oracle solution on this server. In the Enteprise licensing case you will need a 2 * 6 * 0.5 = 6 CPU license. After you have obtained license, you are allowed to run as many instances of the Oracle software on this particular server.
Oracle licensing and vSphere clusters
Okay, let’s now build a vSphere cluster, containing 2 servers with same configuration as above. You want to leverage vMotion and HA, so you want your virtual machines to run on both nodes. In this case you will need a 2 * (2 * 6 * 0.5) = 12 CPU license.
As you might know, a two node cluster is not very HA efficient, because you’re spoiling about 50% of resources the satisfy HA requirements in a N+1 scenario. A bigger HA cluster will become more HA efficient. Let’s say we have an eight node cluster, in this case we will need about 12.5% per vSphere node to satisfy HA resource requirements, which is much more efficient. Now the Oracle perspective: you will need a 8 * (2 * 6 * 0.5) = 48 CPU license if you want to run your Oracle workload on any cluster node within this HA cluster! Oracle licenses can be…let’s say costly, so this will be probably a NO-GO.
At this point, you might think….DRS Groups! DRS groups is a feature which helps you to pin virtual machines on a subset of ESXi hosts within a vSphere cluster. With this feature you can pin or lock your Oracle VMs to, for example, to the first two hosts in your cluster. So, with DRS groups you can have the advantages of a bigger cluster and by using DRS groups you need less licenses (only for the selected ESXi hosts). From a technical (and a quite logical) perspective, yes this is true…from a licensing perspective, hmmmm. Oracle is not very clear about this configuration. Is this allowed? I haven’t found a clear answer on this so far (do you have it, leave a comment…). I have seen some customers who want to be 100% sure everything is licensed and don’t want to take any risk. Result: a seperate Oracle vSphere cluster, just for running the virtual machines containing an Oracle database.
Note: Make sure to read this additional new article as well!
10 days rule
I forgot to mention the 10 days rule, which comes from Oracle. This 10 days rule tells that you are allowed to run your Oracle servers (vms) on other hardware for 10 days a year, without extra costs! This license rule is devised for disaster recovery purposes. If you hardware fails, or if you need to do some maintenance, you’re allowed to move your VMs to another server. Caution: If your virtual machine is running for 5 minutes on another ESXi host, this will count as one day!
Conclusion
I hope this article will help you to investigate your Oracle on vSphere licensing challenge. Always verify the latest licensing information yourself and don’t use this article as your only source :).
Note: Make sure to read this additional new article as well!
1 Comments
Bernhard
I would like to leave a comment about the question whether DRS groups, are a means to not just limit Oracle workloads to a subset of the servers in the Cluster. The answer is yes. The reasoning is to be found in the licensing rules (OLSA/OMA/ULAS) signed by the customer which are the one and only document licensing rules and obligations can be derived from. You will not find any remark that Oracle must be able to track the non usage of a processor or server in these documents. It is up to Oracle to develop SW which makes sure to do so, if they need it. It is sufficient that the customer makes sure on his own that the Oracle workloads are never running on another server in the cluster and declares that. In the documentation you will find that the to be licensed processors are the ones where the SW is “installed and/or running” (ore some times where the SW is “installed and running”). Since “installation on a processor never really happens” the rule comes down to the question whether the SW is running on a processor. That means licenses need to be purchased for all of these processors. (I leave out the question of hardpartitioning which is not needed here). There is nothing in the rules, that licensing is needed for every processor where there is a possibility to bring the workload to by any means. If that were true, Oracle could also state that all processors in a company, including all of your notebooks etc need to be licensed for the SW.
Hope this helps