Following up from my last post… Let’s take a look at how Oracle and IBM deal with virtual environments.
What do they have in common? Well, the weight of a CPU core. How much of a CPU is a CPU core? Oracle’s latest manifest is here. In a nutshell, a CPU core counts as much as Oracle licensing scheme dictates. For instance, in dual core Xeon, a core reasonably is “half” a CPU, so 0.5 + 0.5 (cores) = 1 processor. That’s reasonable. Yet, in a 4-core CPU, a core is not 0.25 of a processor – it still is 0.5, so a Xeon 5504 is equal to 0.5+0.5+0.5+0.5=2 processors according to Oracle. Therefore, for Oracle EE licensed per CPU on a dual socket, 6-core server you need to buy 2 X 6 X 0.5 = 6 CPU licenses. Other CPU variants have different core weights, ranging from 0.25 to 1.
What about virtual systems? Study this document. Oracle has additional definitions on what server partitioning is. Simply put, if a system has the ability to be broken into smaller computers, each with own CPU and memory resources and this configuration is done “on the iron” (hardware assisted via firmware code), that’s hard partitioning. Examples are IBM LPARs (PPC), LDOMs (SPARC), vPars & nPars (HP). Quite strangely, Oracle counts as hard partitions
Sun Oracle Solaris Containers which are implemented entirely inside the Solaris OS without hardware assistance. Now, if you run Oracle inside an OS sitting on a hardware partition, then you can license it by the number of CPUs included in the partition. For example, if you have a 4-socket, 6-core Intel server running Solaris (that is 12 licenses “processors”) but prefer to run Oracle on a Solaris container that is capped at only two processing cores then you need 2 x 0.5 = 1 processor license.
And now the $30000 question: What about a virtualized fabric like vSphere, XEN, KVM and HyperV? Oops. They are not hard partitions. They are soft partitions. Oracle does not care for soft partitions; you have to license the entire physical server. This means that if you prefer to run Oracle inside a VM with 2 virtual CPUs running in an ESX server like the one described above, you have to purchase 12 licenses. And, if you allow this VM to float to another similar ESX server, you have to purchase another 12 processor licenses.
Bad: If you have big multicore boxes for your virtual hosts and need to run only a few VMs with Oracle DBMS, do not virtualize.
Good: If you run tons of small Oracle DBMSs and expect this number to grow, go virtual after you license all virtual hosts that Oracle VMs are allowed to run on. Then you do not need to care about licensing no matter how many DBMSs you use.
What about IBM? Well, being a manufacturer of highly sophisticated, out-of-this-world, next generation computer gear, IBM has chosen to implement an equally sophisticated, out-of-this-world, next generation CPU licensing scheme, here. IBM goes beyond the obsolete concept of CPU core and socket – they define the Processor Value Unit. Just click the link to see for yourselves.
What about virtualization? No worries, here is a full guide, consisting of detailed scenario analyses (in PDF format, downloadable via FTP…). I won’t go into much detail, after all, posts on this blog are meant to be read in 168 seconds, but here’s an example with VMware:
First of all, a VMware vCPU is mapped to a processing core on the underneath ESX server. Then, you must find the corresponding PVU for that core, add all the vCPU->PVU values and voila, you have the PVUs of your virtual machine. Let’s therefore assume that you have 3 VMs running IBM software with a total of 12
vCPUs PVUs. Normally, you would pay 12 licenses. But, if the ESX server underneath has only 8 CPU cores (real, physical, made of silicon), IBM is generous and will license you with the least number of PVUs vs CPU cores: Only 8 cores. The same applies for a vSphere cluster: If your VMs float across the cluster and the total number of PVUs exceed the number of your cluster physical CPU cores, you will be charged for the least quantity.