I keep hearing stories from Customers and Prospects where Oracle appears to be trying to deceive them for the purposes of extorting more license money from them than they are legally required to pay. I also keep hearing stories of Oracle telling them they would not be supported if they virtualized their Oracle systems on VMware vSphere. This has gone on now for far too long and it's time to fight back and stop the FUD!
In my opinion the best way for you to prevent this situation for your company is by knowing the right questions to ask, and by knowing what your obligations are. The aim for this article is to give you the tools to pay only what you legally owe, while making the most efficient and economic use of your licenses, and get the world class support that you are used to, even in a virtualized environment on VMware vSphere. All without sacrificing availability or performance.
I'm going to start this article by quoting Dave Welch, CTO, House of Brick - "I believe in paying every penny I owe. However, beyond that, it is my discretion to who or what I donate and in what amount. I have no patience with individuals or entities that premeditate the creation of OLSA compliance issues. I similarly have no patience with the knowing spreading of FUD by some professionals in what could be construed as extortion of funds beyond customers’ executed contractual obligations. I will continue to vigorously promote and defend the legal rights of both software vendors and their customers even if that means I induce accelerated hair loss through rapid, frequent hat swapping." Source Jeff Browning's EMC Communities article - Comments by Dave Welch of House of Brick on Oracle on VMware Licensing.
I agree with Dave on this. So I am going to show you how you can pay what you owe, while using what you pay for as efficiently and cost effectively as possible, and show you how you can still enjoy the full support you are entitled to. Without the scaremongering that sometimes accompanies discussions with Oracle Sales Reps.
For those that aren't familiar with the term FUD, it is an acronym which stands for Fear, Uncertainty and Doubt. Something some companies and professionals seem to go to great lengths to create in the minds of customers.
FUD #1 - Oracle Licensing and Soft Partitioning
Oracle's Server/Hardware Partitioning document outlines the different types of partitioning and how they impact licensing. Oracle may try and tell you that licensing a VMware environment will be more expensive as they don't consider VMware Hard Partitioning. This is complete rubbish. This assertion is completely irrelevant unless you were only planning on deploying a single small database on a very small subset of a very large server. In this case you probably wouldn't be using Enterprise Edition and may not be paying per CPU Core (Named User Plus instead). Why would you deploy such a system when you could easily purchase a server that is the right size for the job and licensed appropriately for the job? There is absolutely no requirement to run Oracle Enterprise Edition just because you are virtualizing your databases.
There is absolutely no increase in licensing costs over and above what you would have to pay for the same physical infrastructure to run your Oracle Database if you were running it in the OS without virtualization. You still have to pay what you owe, for what you use. The truth is that your costs could actually be significantly less when virtualizing on VMware vSphere as you can get more productive work done for the same amount of physical hardware, and therefore the license requirements and your costs will be significantly less. This is because you can run multiple Oracle databases on the same server and effectively share the resources, including memory, provided you take care during your design to ensure any undesirable performance impacts are avoided. Take this image for example showing consolidating two dissimilar workloads on the same hardware (Source: VMware).
Even if you only want to deploy a single database server you are significantly better off if you right size the host server and VM and deploy it isolated out of a cluster, but still virtualized, even if it is the only VM on the host. This will allow you to still take advantage of many of the benefits of virtualization, such as significantly easier disaster recovery due to the complete hardware independence, better monitoring via your existing virtualization monitoring tools, the ability to run unlimited number of database VM's on the fully licensed host server. If you want high availability and non-disruptive maintenance and upgrades then you just need to add a second fully licensed host server. You can still make use of all the resources of both servers.
I discussed in my article Oracle RAC 11g R2 Standard Edition on vSphere how you could deploy up to 4 VMware vSphere hosts with a single CPU socket each to run an unlimited number of Oracle Standard Edition Databases, including Oracle RAC. This is an incredibly cost effective solution, especially as Oracle Standard Edition is not memory limited, and is licensed by processor up to a maximum of 4 sockets per host, but unlimited cores. You still pay per core, but significantly less. You should make yourself familiar with the different Oracle Database Editions and their limitations. When you virtualize on vSphere because you get HA you may be able to downgrade some Oracle Enterprise Edition licenses to Standard Edition and potentially make a significant saving, at least in maintenance costs. You also gain effective resource isolation capabilities without having to use Oracle Database Enterprise Edition. Remember what I said before, there is no requirement to run Enterprise Edition when you virtualize your databases, you can run any of the editions provided you deploy them within the license and technical restrictions. In all cases you must ensure that all processors are licensed for Standard Edition in compliance with the OLSA and Software Investment Guide.
If you are using Oracle Database Enterprise Edition there is an opportunity to save significant amounts of money if you are migrating from traditional Unix platforms to Linux or Windows running on VMware vSphere. This is due to the way that Oracle calculates the CPU Core License Factor. The Intel CPU's have a Core License Factor of 0.5 compared with some of the higher end traditional Unix platforms Core License Factor of 1.0. This means you need half as many licenses to cover the same number of of Intel CPU Cores as you have in your traditional Unix platform. Oracle may say that's because the Intel systems are inferior and don't perform. However based on my experience modern x86-64 hardware will outperform most of their Unix counterparts. In some cases you can achieve up to 5x the performance compared to a traditional Unix system when utilizing the same amount of licensed hardware (One of my customers did). Not that the new SPARC T4 Processor now has a 0.5 core factor, the same as an Intel Xeon CPU. I take this to mean Oracle recognises the power of the Xeon chips, but one key thing to note is that the SPARC T4 is over twice the price per core as the Intel Xeon counter parts.
The real hard dollar licensing savings here will come into play when re-negotiating maintenance if you already own all the perpetual licenses you need. It will also come into play if you expand the environment as you will be able to avoid purchasing any additional licenses, seeing as you have spare licenses after the switch to the x86-64 platform. If you are in a position where you need to expand the environment and you're on a traditional Unix, now might be the perfect time to make the switch and put the additional license money into the cost of the migration project instead. I have outlined in a previous article what I think are the Top 10 Reasons to Migrate Oracle Databases from Traditional Unix to Linux on vSphere. License Maintenance costs are not the only cost savings by switching to x86-64 from traditional Unix, you may also save significant amounts of power, cooling, data center floor space and hardware maintenance costs. In one of my recent projects the 15 months of the cost of the traditional Unix platform hardware maintenance paid for the entire project costs to switch, services, software and hardware.
If you have an uncapped ELA (ULA in Oracle Terms - Unlimited License Agreement) you can deploy the database software wherever you like the whole discussion about soft or hard partitioning, or the number of cores, is completely irrelevant. You should deploy as many databases as possible and make the best use of your software entitlement. This will come into play quite strongly with my next FUD item below. Be careful to only use the features you are licensed for however, so you don't get any nasty surprises come audit or ELA/ULA renewal time (provided your use is within your OLSA agreement).
FUD #2 - Oracle Sub Cluster Licensing is Not Possible
Still on the licensing topic, but this area of FUD comes into play when you want to only license a subset of hosts that make up part of a large cluster for use by Oracle. Contrary to what many might believe or try and tell you it is fairly easy to deploy and license a subset of a larger VMware vSphere Cluster. It is also perfectly acceptable under the Oracle Software License Agreement, provided you can prove that the Oracle binaries have only been executed/run on the systems that make up the subset of the cluster. Now just because you can do this doesn't necessarily mean I would recommend it and after I explain how you can do it I'll tell you why in many cases this might not be a good idea, and it has largely nothing to do with licensing.
If you don't have a copy of your signed and executed Oracle License and Services Agreement (OLSA) you should get one and read it thoroughly. You should also become familiar with the Oracle Software Investment Guide and the Oracle Licensing Data Recovery Environments Guide, which is an extract from the Software Investment Guide. I would advise that you get a copy of the Software License Investment Guide and Licensing Data Recovery Environments Guide that was valid at the date you signed your Oracle Software License Agreement. This will ensure you know what the policy that applied to you at the date you signed the agreement.
Before we even get into the mechanics of this you won't have to even worry about this if you have an uncapped ELA or ULA. If you have an uncapped ELA or ULA you can run your databases anywhere and everywhere, and it's in your best interests to do so as it will mean come true-up or renewal time all your clusters will be covered and fully licensed (dependant on the wording of your specific OLSA). The following will only be a concern if you are licensed with a capped or limited license agreement, or you do not have an ULA. If Oracle tries to use this as an objection for virtualizing on VMware vSphere just ask them this: "Why is sub cluster licensing even a relevant reason not to virtualize given we have an uncapped ELA or ULA?" One of my customers asked Oracle this and Oracle agreed it wasn't relevant. The same applies if you are licensed under Named User Plus.
The following is an extract from Dave Welch's comments with regard to the Oracle Software License Agreement and Oracle Software License Investment Guide with regard to processor based licensing:
- "Customers must license all physical cores or sockets on a host where Oracle executables are “installed and/or running” (with physical cores factored per Oracle’s published Core Factor Table, and potentially subject to the so-called 10-day rule [whose terms became more restrictive sometime during 2007]). Notice the tense. Oracle customers are contractually obligated for licensing the physical servers where the Oracle executables are and have been, not where they might go. To imply otherwise without explicit contractual inducement would not be unlike concluding that I am legally obligated to purchase transportation to or obtain a visa for destinations that I clearly have the capability of visiting but where I have neither ever been nor yet made a determination to even visit."
- "Furthermore, customers must pay a license to cover the use of remote mirroring at the storage unit or shared disk array layer to transmit Oracle executables to a SAN whether or not that set of Oracle executables is “installed and/or running” on any physical host connected to the SAN."
So you can tell from the above you must be able to prove where the binaries are installed and/or running or where they have been installed and/or running. Regardless if the mechanism is manual or automatic. I strongly recommend that you read the Certification of an Oracle ULA Agreement (or: Need to defuse a time bomb) article posted on the License Consulting blog. It will give you some insight into the Oracle Audit and Certification process and some really big traps you need to try and avoid.
I will discuss both manual and automated ways of ensuring license compliance, but first lets contemplate for a moment a situation in an unvirtualized environment where you've taken a snapshot of a production systems LUN's and presented them to another system. Both the production system and the new system must be fully licensed. This is fine, and you would know which systems the binaries are installed and/or running on as you have had to go to a lot of effort to snapshot the LUN's and present them. This changes a bit when you are running in a large cluster.
License Isolation Method #1 - Storage Zoning / Masking to a Subset of Cluster Hosts
VMware Best Practices recommend that you present all LUNs to every host within a cluster. Under normal circumstances this makes perfect sense and is definitely the best option. However if you wanted to license a subset of the cluster for Oracle you might choose to zone and mask the Oracle LUN's/Datastores to only the hosts within the cluster that will run Oracle. This will prevent the virtual machines without some further manual actions to run on any other hosts within the cluster. You can still have DRS enabled in fully automated mode and it can happily migrate the Oracle VM's around the hosts that are licensed and zoned/masked to the storage. This has an advantage of being fairly easy to administer and manage. This still allows the use of Maintenance Mode and VMware HA. One of the major downsides here is you could easily reach the maximum number of LUNs per Host if your databases consume multiple LUNs and the rest of the non-Oracle VM LUNs are also zoned/masked to the Oracle Hosts. If those non-Oracle LUNs are not zoned or masked to the Oracle hosts then I'd question why you aren't choosing method 4 below.
License Isolation Method #2 - DRS Set to Manual or Disabled for Oracle VM's
This method will allow you to run all the hosts in a DRS cluster fully automated while restricting the movement of the Oracle VM's. Administrators would have to manually move the VM's, which would add administrative and management overheads. License compliance would be maintained provided the administrators only moved the VM's to licensed hosts. You would need vMotion logs or an audit trail to prove which systems the Oracle software were/are installed and/or running. You may need to disable these VM's from VMware HA to ensure there was no possibility of the Oracle software being installed and/or running on an unlicensed host. Given the chances of error and the difficulty introduced in managing the cluster this method is not recommended, even though it will meet the license conditions provided it is configured and administered correctly. Suffers from the same limitation as method 1 with regard to likelihood of reaching max number of LUNs per host.
License Isolation Method #3 - DRS Host Groups
This method allows you to ensure the Oracle VM's are only installed and/or running on a subset of the hosts within a cluster without any special storage configuration and also with the DRS cluster remaining fully automatic when used in combination with DRS Must Rules. This is fairly easy to administer and allows for the use of maintenance mode and VMware HA. You can use the advanced option ForceAffinePoweron to ensure the VM's will only be restarted by HA on a fully licensed host when there is a host failure. You will need vMotion Logs, or an audit trial of some sort to be able to prove where the Oracle software was/is installed and/or running. Suffers from the same limitation as method 1 with regard to likelihood of reaching max number of LUNs per host. There was a video recorded with Richard Garsthagen of Oracle on VMworld TV during VMworld US 2012. The video can be viewed in this article on the License Consulting Blog - VMworld – Richard Garsthagen (Oracle) on licensing VMware / virtualized environments.
License Isolation Method #4 - Dedicated Oracle Cluster
While not technically a way of deploying a sub cluster of hosts for Oracle inside of a larger cluster this is often my preferred method of deployment. The main reason this is generally my preferred deployment method is because of it's simplicity. Other reasons include:
- You know the VM's will only be running within this cluster, so you can license the whole cluster and be done with it.
- You can ensure you make optimal use of your licensed hardware without any non-Oracle VM's consuming valuable infrastructure that is licensed for use by Oracle.
- This allows an easier isolation of resources, as you will not have any non-Oracle VM's consuming resources as would be the case with method 1, 2 and 3.
- You can run a different consolidation or overcommitment ratio for the Oracle Cluster, which you might want to do for availability and performance reasons.
- You can right size the infrastructure for your exact Oracle requirements (smaller or larger hosts and NUMA node sizes).
- No complicated settings for VMware HA and no risk of a VM restarting on an unlicensed host in the case of a host failure.
- Much easier from an audit and compliance perspective.
- Less likely to reach the limit of the maximum number of LUNs per Host compared to method 1, 2 or 3.
- Much lower likelihood of human error causing a licensing compliance issue.
With a properly designed dedicated cluster for Oracle you can make efficient and optimal use of your physical licensed hardware while still allowing maintenance and failure capacity. I disagree that this is significantly harder to manage than having a subset of hosts in a larger cluster. I actually argue that this is far more efficient to manage, especially given the need to ensure license compliance and the financial consequences of getting it wrong and the much lower likelihood of human error. Even if your dedicated cluster has only 2 or 3 hosts it still has a number of benefits. Probably one of the most significant benefits is the reduced likelihood of reaching the maximum number of LUNs per host. If you are running a big Oracle environment this is a very real possibility especially if your databases demand maximum performance and are therefore configured with multiple LUNs each.
Audit and Compliance Made Easy
Although vMotion Logs may be an acceptable way to provide proof of where Oracle software was/is installed and/or running my preferred method would be to use vCenter Configuration Manager (vCM). vCM is a tool that is purpose built to ensure audit and compliance and configuration management. It will track every modification to configuration items including vMotion Migrations. It is also used to ensure regulatory compliance with standards such as HIPPA, SOX, PCI DSS, DISA STIG and others. vCM is accredited as a SCAP 1.0 tool. It is relatively easy to get up and running and produces all the necessary reports once it has been configured. It can be purchased in isolation or as part of the vCenter Operations Enterprise or Enterprise Plus Edition Suites. vCM is not limited to compliance of virtual machines and VMware environments, it also supports physical systems, including workstations and traditional Unix systems. I would strongly recommend you consider this given the direct integration with the VMware vSphere environment and the tremendous value it can add to your entire virtual and physical infrastructures.
If you didn't want to use vCM you may want to consider another tool such as SPLUNK, which allows for secure storage of log records and easy visualization of those logs.
FUD #3 - Oracle is NOT Certified to Run on VMware vSphere
This isn't FUD, it's true. Oracle isn't certified to run on VMware vSphere. This is because Oracle does not certify below the Operating Systems. So your system isn't certified to run on Dell, HP, or IBM hardware either. Oracle instead certifies the operating systems that run their software. So provided you are running a fully certified and supported version of the OS then you are covered. This is because VMware does not modify the OS. This topic is covered in the Understanding Oracle Certification, Support and Licensing for VMware Environments white paper published by VMware.
FUD #4 - Oracle Does NOT Support Running on VMware vSphere
Is Oracle trying to tell you that if you virtualize on VMware vSphere that you won't get support? Are they saying that they will fail to meet their contractual obligations and support the software that you've potentially paid millions of dollars for? That although your running on a certified and supported OS, that because you've changed the underlying hardware that they won't support you any longer? Or are they just saying you will have to move your databases back to physical if there is a support problem?
I've heard all of the above, and still do sometimes. It's very surprising given that Oracle has been supported on VMware since 2007 and Oracle RAC 11g R2 (22.214.171.124) has been supported on VMware vSphere 4 and above since November 2010. Oracle has a very explicit support statement when it comes to operating in a VMware environment. The support statement is covered in Metalink 249212.1 and an extract is below:
"Support Status for VMware Virtualized Environments
Oracle has not certified any of its products on VMware virtualized environments. Oracle Support will assist customers running Oracle products on VMware in the following manner: Oracle will only provide support for issues that either are known to occur on the native OS, or an be demonstrated not to be as a result of running on VMware.
If a problem is a known Oracle issue, Oracle support will recommend the appropriate solution on the native OS. If that solution does not work in the VMware virtualized environment, the customer will be referred to VMware for support. When the customer can demonstrate that the Oracle solution does not work when running on the native OS, Oracle will resume support, including logging a bug with Oracle Development for investigation if required.
If the problem is determined not to be a known Oracle issue, we will refer the customer to VMware for support. When the customer can demonstrate that the issue occurs when running on the native OS, Oracle will resume support, including logging a bug with Oracle Development for investigation if required.
NOTE: Oracle has not certified any of its products on VMware. For Oracle RAC, Oracle will only accept Service Requests as described in this note on Oracle RAC 126.96.36.199 and later releases."
So we've had that 'Not Certified" statement come up in this, so refer to FUD #3. Let's break this down.
- The above is very clear. Oracle support will recommend an appropriate solution on the native OS for any known issues. This makes perfect sense and as VMware does not modify the native OS this is absolutely fine.
- If the solution does not work in a VMware virtualized environment the customer will be referred to VMware for support. This is perfectly understandable and acceptable. If there is a problem with the VMware software then VMware will need to support it, I'll discuss the VMware extended support policy below.
- If the problem is an unknown issue then the customer will be referred to VMware Support and when it's demonstrated to be an issue on the native OS Oracle will resume support. Again this is perfectly understandable. If the problem is with VMware software that VMware should fix it. However VMware does not modify the OS therefore the problem if it's not directly related to the VMware vSphere software will is being experienced and would be experienced by the native OS.
So the above means for any Oracle problems with the Oracle software Oracle will support you. End of story. You potentially have to prove it's an Oracle software problem, but that is no different to the system being run on a native OS. If it's an unknown problem to Oracle they may ask you to reproduce on a different hardware platform.
If the above isn't enough to satisfy you that you are supported when running on a VMware vSphere platform and on a supported and certified OS then the VMware Extended Support Policy should. Under the VMware Extended Support Policy for Oracle Databases VMware Technical Support will take total ownership of any Oracle Database problems reported to them, as well as providing access to a team of Oracle DBA resources, and working with Oracle support until resolution.
I have to say that the Oracle Support team is world class and I've always had a good experience dealing with them. I have had the same world class experience when dealing with VMware Global Support Services, and especially the Oracle Technical Support Engineers.
In addition to the above it wouldn't do any harm to get Oracle to confirm in writing that your environment will be supported. Oracle backed down after they knew a customer of mine was serious and put in writing that they would fully support the environment in accordance with the terms of the contractual obligations and their support policy. So now there is absolutely no ambiguity about the situation. It is supported, end of story.
Key Questions to Ask Oracle to Fight the FUD
- Where does it say in my OLSA, which is our legally binding contract, that I must purchase licenses over and above the licenses I require for all of the CPU cores or Sockets where the Oracle Software is running and/or installed?
- Where does it say in the OLSA, which is our legally binding contract, that I am not able to run on a subset of cluster hosts provided I can prove where the Oracle Software is installed and/or running in accordance with the contracted terms and conditions?
- How is licensing a complete cluster with the required number of hosts any different from licensing the required number of standalone native physical servers?
- Does Oracle Certify the underlying hardware platforms below the OS that run Oracle software such as IBM, HP or Dell servers?
- Given that you don't certify below the OS why would running a fully certified and supported OS on top of VMware vSphere be unsupported or be any different from a support perspective than running on native given that VMware does not modify the OS?
I have added two more items to this list of FUD in another article called Return of the FUD – Oracle Licensing on VMware vSphere.
I hope this article has been some help and has empowered you to stand up for your rights under your legally binding contracts. You can find more commentary from Jeff Browning and Dave Welch at the following locations: Oracle Storage Guy - Dave Welch of House of Brick on Oracle on VMware Licensing, Comments by Dave Welch of House of Brick on Oracle on VMware Licensing and Oracle Licensing on VMware - Reprise.
Read Certification of an Oracle ULA Agreement (or: Need to defuse a time bomb). It will help you understand where you might end up during an Oracle audit / certification process and how to use the process to your best advantage and avoid some traps. Follow this up with this article by the same authors - The impartial objective of Oracle’s compliance auditors: A 5 Million Dollar target.
A great reference for Oracle Licensing and Support has been written and published by VMware titled Understanding Oracle Certification, Support and Licensing for VMware Environments. Some of what I'm about to describe is covered in this document and I would definitely recommend you read it.
Maybe a reason Oracle appears to be trying to perpetuate these myths around licensing and support is because the traditional Unix hardware business and Solaris is on a major downward trend. See IT Candor's Server Market Report for the details.
For guidance and ides for design and architecture for your Oracle Databases on vSphere here are two great articles. Deploying Enterprise Oracle Databases on vSphere, Blueprint for Successful Large Scale Oracle Virtualization on vSphere.
For additional information on virtualizing Oracle visit my Oracle Page.
This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.