I’ve been meaning to write an article on how Oracle’s licensing works with regards to VMware and how to minimize costs, but Oracle Storage Guy (Jeff Browning) said it better in this blog post ( http://oraclestorageguy.typepad.com/oraclestorageguy/2010/05/oracle-license-costs-on-the-vmware-vsphere-platform.html ) than I could have said it. Go read his blog post in another tab and then continue on..
Back? Good.
So a real world example. My main vSphere cluster is a 16 blade Dell Cluster. 11 of those blades are Dell M600 blades each with I2 Intel Xeon E5430 processors (those are pre-Nahelm for those curious) and 5 of those blades are Dell M610 blades each with 2 Intel Xeon 5550 (Nahelm). In both cases, each blade has 2 sockets, with each core having 4 cores. With the Xeon 5550 processors, they also have 2 logical (hyperthreading) cores per physical core, giving me a total of 16 logical processors per M610 blade. Oracle licensing does not count logical cores, only physical ones.
Rather than paying to license 8 cores on 16 blades (which at list rates would work out to 8 * 16 * 0.5 * $47,500 ) for $3,040,000 or just over $3 MILLION DOLLARS in Oracle licensing, we have two clusters in vCenter. One of these contains 8 M600s and 3 M610s and basically contains everything in our cluster with the exception of our Oracle products licensed by processor. The other cluster is 2 M610 nodes and it holds all our Oracle databases and other Oracle products that are licensed by processor. That works out to (8 * 2 * 0.5 * $47,500) $380,000 or the same performance for about 1/10 of the price.
Now, you may be asking how those two blades are handling the load – I’m writing this blog entry during the middle of our production day. I’m running 20 Oracle database servers (one instance per VM server) combined on the two blades.
Blade #1 – 1044 MHz CPU utilized, 25897MB RAM utilized
Blade #2 – 4448 MHz CPU utilized, 27093MB RAM utilized
I didn’t make a typo. I’m running 20 database servers essentially off of 2 CPUs worth of processing power (each Xeon 5550 is 2.67 MHz) and I’ve got 32 CPUs of processing power in the two node cluster (4 sockets, each with 4 physical cores, each physical core with 2 logical cores), so that’s not going to be a bottleneck at any time soon.
On the RAM side, each M610 has 48G of RAM and right now I’m utilizing about 48G of RAM. Each M610 can handle up to 192G of RAM, but we went with 12 4G sticks due to that being the current cost sweet spot. Again, not a bottleneck.
So like Jeff said, utilization on Oracle database servers is typically low. If I wasn’t virtualized at all, I’d have to have 20 physical servers and license all those processors for Oracle Enterprise Edition. If I allowed my Oracle VMs into my regular VMware cluster, I’d have all the advantages of VMware (HA (high availability), vMotion, Storage vMotion, etc) but I’d have to pay 10x the cost in Oracle licenses. Instead I’ve got a separate VMware cluster only licensing what I need and getting all the advantages of VMware.
For those curious about what we’re doing with all those instances, some are development / support environments, but we’re running our production Oracle E-Business Suite, Oracle Hyperion, Oracle Agile, and various other smaller load systems on two nodes supporting hundreds of end users.
What can I say? VMware rocks.
Great account for the savings you can get from virtualization just in licensing. I’m just sitting here if Oracle will ever get with the program and change to more virtualization friendly licensing and support like nearly everyone else in the entire IT industry has done. Just seems like they’re pretty clueless over there.
Now a day’s it is very important to understand licensing model. Vendor should be open to accept virtualization as a key mantra and should not use tactic to extract $ or impose their product on customer.
Thanks,
Vikash
Great article Jay, and I have seen similar returns on customers I have helped down the path to running Oracle on VMware. Oracle will allow you to segment your license if you’re running Oracle VM (so you could run an Oracle VM based database on your large cluster and just pay for the cores you have assigned to the VM), so it’s a bit anti-competitive that they won’t recognise the ‘soft partitioning’ used in VMware. Their argument is that threads of code in VMware may use *any* of the cores on your server, even if you only assign the VM 2 vCPUs for example. It seems like a fudge to improve the position for Oracle VM to me, but fortunately people are starting to see the light and the massive savings they can make in licensing are outweighing the FUD.
While Oracle maintain this position, just use smaller blades/servers such as 2 socket Nehalems ($190K 5570 $285k 5670 license costs) so you get the granularity of the license hikes in the hardware. By maintaining a separate ‘DB’ cluster in VMware you can then grown the compute power (and your license) in more manageable pieces as and when required.
Yeah, I’m all for using smaller blades / servers – on the database the company had already bought 10 processor licenses of the database from before we virtualized, and we only have blade resources of 8 processor licenses available to Oracle so we’re just “stuck” with that over-capacity for now.
I do currently utilize smaller servers for my EBS Apps tiers as we only have 8 processor licenses but it was a bit out of the scope of the article.
Yeah, I hope through customers being more vocal that Oracle will be forced to change their “soft partitioning” stance with regards to VMware, but I hold little hope that will happen any day soon.
Great resource.
What I’m not following is why bother with virtualization at all. You can run more than one instance per server… Why not run 10 instances on each of 2 physical servers instead of creating 20 vmware server and running an instance on each? You seem to be working around oracle instead of with it.
You are entirely correct – you can run more than one database instance on one server. But should you?
Let’s take your example – 2 physical boxes with 10 instances each vs 20 separate VMs each with an instance on it. What if you’ve got one instance thats hitting the CPUs or storage harder than the other instances on that physical box? Now you’re impacting the performance of the other instances. Sure you can do workarounds with Oracle consumer groups, if it’s an issue you’ve anticipated…. with VMware I can setup resource minimums for the whole VM – this VM gets a guaranteed amount of RAM, Storage and CPU resource. I can’t do that with multiple instances on the same OS host.
What if someone does something that causes the database to start using more disk space and runs the file system out of space (the /home or /tmp for example)? All your instances are now unavailable. Virtualized – sure, that one Oracle instance is down, but the others are unaffected.
What if I’ve got 5 Oracle instances on that 10 instance physical host all using the same Oracle home and I want to patch it? That’s downtime to all those Oracle homes. If they’re all in their own VMs, downtime one at a time, as needed.
What if I’m running different Oracle versions on different OS’s ? At my main client, I’ve got an Oracle 9i database (9i isn’t supported on RHEL/OEL 5) on Linux, an Oracle 10g database on Windows (product the database is for does not have a Linux version), and of course a variety of Oracle 10g/11g instances on Linux. If I’m running physical that’s at least 3 hosts (RHEL4, Windows, RHEL5) I need to run – and pay for Oracle CPU licenses for all the CPUs on all those boxes. That Oracle 9i database easily runs on one core, but it’s still mission critical. I don’t think I can find a new one core box these days. Same with that 10g on Windows database.
On top of ALL THAT, there’s advantages in other areas like recoverability and disaster planning – see my post (and the comments) at http://weinshenker.net/blog/2010/07/05/oracle-vm-vs-vmware-vsphere_1/ . Virtualizing Oracle brings some complexibility to the picture, but the things you gain are well worth it.
Um, that is a terrible situation. What happens when one of the hosts goes down unexpectedly of for maintenance? You are already maxed out. You need to make sure you can run all of your stuff on one node in order to have protection/flexibility. That is why multiple (more than 2) nodes are better, easier to have the capacity to take one host out when there are more hosts to support the load. You are making some pretty big sacrifices and taking on a huge amount of risk for trying to save on licensing costs in such an agressive manner…
Thanks for the feedback Scott, but I disagree on the risk in the situation. Allow me to explain.
The storage that the VMs live on is an enterprise class SAN, not on disks inside the host. So if I lose a host, VMware High Availability (HA) will bring up all DBs that were on that host the other licensed host. Yes, that’s downtime, but only a few minutes while the VMs restart on the surviving host. The company is aware of this downtime and decided that the cost of the HA downtime was far less than the cost of the additional Oracle licenses.
As I mentioned in the article, I do have the capacity to run all of the instances at their normal load on one host. Now you could say that if all my VMs were running at full capacity that I wouldn’t have enough CPU / RAM capacity on one ndoe, and that’s true. However, in such a situation we could shut down the development / test instances on the surviving host to allow production to run unencumbered. Also note that in the event of a hardware failure, Oracle’s 10 day DR policy allows me to bring in another host that isn’t typically part of my Oracle cluster to handle the load.
Oracle licensing per host costs 4 enterprise edition database licenses (each host has 2 x86 sockets with 4 cores each, resulting in 8 cores times the Oracle Intel x86 architecture .5 modifier). At that cost, it’s cheaper for me to have a completely unused host lying in a closet rather than buying those licenses. Instead I’m able to use that host in the other VMware clusters and instead just move it into the Oracle cluster (a process taking only a couple of minutes and resulting in no downtime to the VMs running on that host since I can vMotion them to another host beforehand) in the event of the disaster.
As I’ve explained above, the only risk I’m taking on to save on the $2.2M in Oracle licensing is just the downtime associated with restarting the VMs that lived on the down host – an automated process taking less than 10 minutes. Without doubt there are places where that downtime is unacceptable. This organization isn’t one of them.
On a related note, since I wrote the initial blog post, Oracle now supports RAC 11.2.0.2 virtualized under VMware. As a result, You could now run RAC nodes on each VMware host and reduce your downtime risk considerably. This organization decided the cost of the RAC licenses was more expensive than the HA downtime, and some of the applications aren’t supported on 11.2.0.2 RAC.
Hi,
we had all ESX Cluster licensed. Now we have consolidated all VM’s running Oracle inside (170) to a new Cluster and reduce the core count by 200. Because all cores were licensed before we now have 200 cores free for future use before we reach our highwater mark. :o) … and in the meantime, for very new project it will be double if we really need oracle as the db backend …
Sorry Larry !
I recommend that people only license a vSphere server or two ( two initially) at a time so you only need to buy what you actually need. Oracle always seems willing to sell me an additional license but returns are rather unlikely 🙂