Running Oracle on VMware: Challenges

I am sure that there are number of reasons why VMware is preferred to run RDBMS in some cases. But there are some major challenges are there as well.

This note is just to highlight the challenges observed when running Oracle in VMware environment.

• Oracle S/W Licensing in VMware

• Oracle does not recognize VMware as a trusted partition (Hard Partition), possible result is to end up buying less than required (as a result: non-complaint) or more licenses (additional costs) since the environment is ever growing and keeping up with the licenses vs. actual usage is somewhat challenging.

• Oracle Licensing requirement in VMware

• Single Hosts: License All CPUs in a Single Host for Oracle.

• Example: If there is only one Oracle Database VM running with only 4 vCPU but the physical host contains 64 CPU cores. Then –

• For Processor based license: All the CPU's must be licensed.

• For Named User license:  Required to maintain named user plus per processor minimum licenses which are: minimum of 25 Named User Plus per Processor licenses or the total number of actual users, whichever is greater.

• In this example: 25 User * 64 = 1600 Named User Plus Licenses.

• For both cases, will need to pay way more than the actual usage.

• vSphere CPU Affinity might be a solution as per VMware but no reference or certification from Oracle acknowledging this feature.

• VMware Cluster:

• Full Cluster License: If the whole VMware Cluster is licensed, then you can run Oracle in all or any of the physical host within the cluster.

• Partial Cluster License: If the partial VMware Cluster is licensed (e.g. 1 physical host in a 3 node cluster), then Oracle must run in that licensed host. And cannot use VMware HA features to failver or switchover the VM. May need to use DRS Host Affinity rules to restrict the movement of virtual machines within the cluster.

• Oracle Database Performance (In fact, it’s applicable to most RDBMS)

• Let’s say that there are licenses available for the FULL VMware Cluster. Naturally, everyone will try to maximize the license usage by deploying more and more Oracle Databases within the cluster. In essence, the cluster becomes an “all you can eat” cluster from an Oracle licensing standpoint. At this stage the performance problem will kick in –

• Datastores: Since most of the VMware deployments are based on data stores rather uses raw device mapping (RDM), I/O will be a major bottleneck, even with 100s of datastores. Note that Filesystem writes are sequential unlike ASM.

• Most cases, each VM will have only 1 or couple of more data stores for DR replication (SRDF) requirement/restrictions (consistency groups) so performance will be even worse for I/O intensive workloads.

• As of now, I have managed to get maximum 1300 SQL transaction per second which is really nothing comparing other soutions/technologies out there in the market.

• Consolidation will NOT possible due to the I/O restrictions per VM. DBaaS, Pluggable Database, Schema consolidation, consolidate multiple instances in single VM etc. are NOT possible.

• Overheads of O/S & RDBMS replicated per VM.

• VM sprawl: Replace physical sprawl with logical sprawl but logical sprawl is still expensive to manage.

• Result is to end up with thousands of VM’s with Oracle running and became unmanageable.

• Support Position for Oracle Products Running on 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 can 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.

Let me know your thoughts on this.