A question I tend to ask my customers almost always is what their current state is regarding IT transformation and journey to the cloud. Of course such a strategy does not work very well on bare metal and some kind of isolation between services and physical hardware is required – which naturally includes virtualization, as well as the use of some kind of container technology, as-a-Service paradigms, changes in IT administration and operations etc.
Nearly always the answer includes “We already virtualized everything! … Well, ehm, except Oracle….”
TL;DR: There are no more roadblocks for virtualizing Oracle, including license issues. See the last section “Mythbusting” of this post for a summary on myths and truths.
Top virtualization objections
The reasons for avoiding virtualization of database servers are typically the usual suspects:
- Bad experience with previous consolidation attempts
- Expected performance overhead / sizing limitations
- Technical issues / more complexity
- Different strategy for DB consolidation (such as going with Pluggable Databases / Multitenant)
- No need because we have a ULA / PULA / Special contract
Most of these have been covered on my blog before so I will focus on the two biggest showstoppers:
- Virtualizing Oracle not supported on the preferred platform (i.e. VMware)
- The Oracle on VMware licensing dragon (The claim from Oracle that once you run Oracle on VMware, you have to fully license ALL vSphere/ESX hosts in your entire datacenter – including clusters that don’t run Oracle at all – also known as Galaxy Licensing.)
Oracle Virtualization benefits
So why would one want to virtualise Oracle databases anyway?
The quick answer: Massive cost reduction as well as operational benefits.
A small recap of the stuff I’ve written before:
By virtualizing Oracle it is often possible to reduce the amount of processors required to run consolidated workloads. This because individual servers no longer have to be sized for peak loads as workloads can dynamically move between servers, allowing much higher average CPU utilization. There are a number of design rules to keep an eye on, and there are some notable exceptions but in general this is how it works. There are also a number of additional operational benefits of moving to a virtualized environment.
Why VMware? Because IMHO it’s currently the only platform that is both capable in dynamically balancing workloads, and stable enough for mission critical workloads.
With some exceptions, other hypervisors or alternative consolidation strategy (Such as Oracle Multitenant a.k.a. Pluggable Databases) simply don’t yet offer enough efficiency benefits or are either not supported or lacking the required features or matureness.
With note that I have seen customers also being succesful with IBM Power systems (AIX LPARs) and I yet need to see how wel Linux KVM is up to the job – please let me know if you achieved good results with KVM!
Oracle now supported on VMware
In September last year during Oracle Openworld, Oracle and VMware announced a cloud agreement regarding Hybrid Cloud deployments using VMware on Oracle’s cloud. As part of the agreement Oracle now also officially supports Oracle deployments on VMware (even if it’s not part of a Hybrid Cloud strategy). Note that Oracle supported VMware before but with some side restrictions and requirements – most notably having to move back to bare metal in case of certain issues.
One small step for VMware & Oracle , one giant leap for VMware & Oracle mutual customers
This new agreement eliminates the first major roadblock in virtualizing Oracle.
The Final Frontier
With the support issue resolved, there remains one final barrier to go virtual: the licensing dragon.
This could be a big one as many customers don’t want to take the supposed risk of becoming non-compliant with their licensing, and they want to avoid any trouble with audits, legal issues and ultimately the risk of having to pay a huge amount of money to get rid of such licensing issues.
Needless to say that in the past I have been in customer engagements where we secured the “technical win” where the customers expressed their preference for one of our converged or hyperconverged cloud platforms to run Oracle, but lost anyway due to these licensing risks. With the advantage of these platforms gone, all we can do is offer just a bunch of servers and/or disks, and our real value-add is gone. In that case, unfortunately, we often lose because we don’t hold the licensing/discount wildcard and we have no further unique selling points.
A lot has been written about why this does not make sense and how you can avoid this issue (see my previous post on the matter) but the usual comment is that even though we all agree, Oracle does not accept this as a valid isolation strategy and our customers don’t want to take the risk and rather pay much more to avoid legal disputes.
Why does Oracle not accept? My take is that Oracle doesn’t want to run customers as efficient as possible – as this reduces their license and maintenance revenue – so they will use any kind of FUD tactics to scare customers away from innovation and optimization.
With the Oracle / VMware announcement, nothing has been mentioned about licensing – so even with the support issue gone, the perceived licensing problems remain. Let’s take a deeper look.
Around mid 2018 I started working with a company named LicenseFortress as they somehow could solve the licensing stalemate issue. The idea is as follows:
- LicenseFortress signs off the proposed architecture to verify it does not contain potential license violations. They look at things like affinity rules, VLAN isolation, tracking audit logs etc (essentially what I recommended in my License Dragon post). If your architecture is one of DellEMC’s CI or HCI platforms, then this is easy as these architectures are well known for them.
- A Virtual Appliance (LicenseFortress Discovery – you can try it for 60 days) is deployed that continuously monitors the customer’s environment for compliance issues and notifies immediately if some rules are broken. This goes beyond just bean counting the number of CPU cores – it also checks for license violations not related to running on VMware (for example, accidentally running an in-memory query). So LF Discovery enforces license compliancy at all times
- A financial guarantee is provided to protect customers against licensing claims from Oracle. See “Premier” under Subscriptions for more info
- If Oracle LMS requests an audit, we can be sure the environment is compliant
- If Oracle claims this is not the case, LicenseFortress assists with technical as well as legal support to refute the claims
- If Oracle sues the customer (which we consider highly unlikely to happen but it’s a theoretical possibility) LicenseFortress offers legal support and guides the entire process
- If the customer would lose the case and is forced to buy additional licenses and support, this is also covered in the financial guarantee. LicenseFortress is backed by a large insurance company for these potential large claims.
The end result is that:
- The customer does no longer have to worry about being compliant – the required proof is constantly maintained by LicenseFortress Discovery
- The financial risk of being non-compliant is covered even in case of legal disputes
- Protection against any kind of license violations – not just Oracle on VMware related
I really think this approach is brilliant and unique – so I have become a big advocate within Dell resulting in working together on multiple occasions: At DellEMC we work with LicenseFortress to remove any financial risk (with respect to license compliance) when our customers want to go with Oracle on VMware.
Let me phrase that again:
We work together to remove ANY financial risk running Oracle virtualized on our platforms
(with respect to license compliancy of course)
I’m expecting more information / announcements on this anytime soon – stay tuned !
Some myths and other statements regarding licensing:
VMware has performance overhead
Kind of true – there is a small overhead – we measured about 4% on ESX version 5 – but with modern CPU enhancements and improvements to the hypervisor, current systems will have even less
On vSphere 6.7 a single VM can scale to 128 vCPU, 6TiB RAM, 62TB per virtual LUN (source: vInfrastructure blog). Not many workloads are too large for these limits. Of course the physical hardware has to support this.
Well, yes you’re introducing another layer (the hypervisor). Which is why you should choose a mature, proven platform for which many tools and integrations are available. With the right tools in place this does not have to be a problem – and many companies have virtualized most of their workloads already so no additional skills/tools need to be added.
Different strategy for database consolidation
Maybe – depends on which one. One common mentioned alternative is Oracle Multitenant – see my post on that for more info.
No need because we have a ULA / Other special agreement
Depends on the conditions of course – sometimes it could make sense to delay a consolidation project to maximize the amount of CPUs before ULA certification. Beware however of the pitfalls (work with a license consulting company for guidance on this). My take is that in the long run, reducing the amount of processing power to run your real estate is a good thing but timing may be critical.
The myth “We can deploy as much servers/options/VMs as we want, we have a ULA” often does not hold true in the long term.
Oracle is not supported on VMware
Simply untrue. Oracle has supported running on VMware for years – and with the recent announcement, even the requirement for reproducing on physical hardware has gone.
Oracle needs to be licensed on ALL VMware hosts
Simply untrue. You can license by physical host even within the same VMware cluster if you like, i.e. only licensing specific hosts for Oracle within the very same cluster (i.e. sub-clusters). I verified this with LicenseFortress and they offer their guarantee on sub-licensed clusters. I also have reference customers who are doing exactly this (without Oracle’s approval) and there are no compliance issues whatsoever.
Oracle needs to be licensed on all sockets
Untrue. According to LicenseFortress we can license a single socket on a multi-socket host – but special care must be taken to prevent Oracle software to be accidentally running on the wrong socket. There are ways to enforce this.
Oracle needs to be licensed on all cores of a socket
True until proven otherwise – although not everybody agrees – See for example House of Brick – Oracle Licensing: Soft Partitioning on VMware is Your Contractual Right but LicenseFortress don’t allow this in their guarantee (as of today) as it is considered too high of a risk.
If you really need this, also consider buying servers with less cores per socket, or using Oracle Standard Edition, or even a different database (EDB Postgres for example) to achieve more cost efficiency.
With the last frontier gone, it’s time to leave the past behind and start the next chapter in the journey to the cloud – migrating the Oracle workloads.
Contact me for more details if you’re interested.
Special thanks to the guys at LicenseFortress for reviewing this blog post’s contents and providing valuable feedback!
This post first appeared on Dirty Cache by Bart Sjerps. Copyright © 2011 – 2020. All rights reserved. Not to be reproduced for commercial purposes without written permission.
2,231 total views