Oracle on VMware Cloud on AWS – Unraveling the licensing myth

With the recent launch of VMware Cloud on AWS from VMware, many Business Critical Application (BCA) workloads that were previously difficult to deploy in the cloud no longer require significant platform modifications. VMware Cloud on AWS, powered by VMware Cloud Foundation, integrates VMware flagship compute, storage, and network virtualization products—VMware vSphere, VMware vSAN, and VMware NSX—along with VMware vCenter Server management. It optimizes them to run on elastic, bare-metal AWS infrastructure.

VMware and AWS presented a Better Together demonstration at VMworld 2017 using an Oracle RAC Database for high-availability zero-downtime client connection failover, supporting a Django-Python application running in a Native AWS Elastic Beanstalk environment. This illustrates the further value you can take advantage of by choosing VMware Cloud on AWS as the public cloud infrastructure for your Oracle RAC implementations.

The following topics are covered in this blog post in the following order –

VMware Cloud on AWS –Initial availability model
Understanding Oracle Licensing on VMware vSphere / vSAN environments
Deploying Oracle Workloads on VMware environments
What’s New September 6th, 2018 (SDDC Version 1.5) – ‘Compute Policies’
New Feature announced on September 10th, 2018 – Three Host SDDC
Facts about the Single Host SDDC
vSphere Tags and Attributes
Affinity rules in VMware Cloud on AWS
Understanding Oracle Licensing on the VMware Cloud on AWS

Purpose of this Blog

The purpose of this blog is to provide customers with information along with GUIDANCE when it comes to certification, support, and licensing of Oracle on VMware vSphere
This information along with GUIDANCE is based on the experience and knowledge that VMware and proponents of its technology have acquired from over a decade during which VMware has successfully virtualized the majority of Oracle workloads on vSphere
This blog does not provide ANY legal advice concerning a customer’s license or support agreement with Oracle or any other third party. Rather, this blog is intended to help customers understand the issues and be better prepared for optimal licensing interaction with Oracle and third-party vendors.

In addition to the blog, please refer to the Oracle on vSphere Certification, Support and Licensing Guide 2017

Key Points to take away from this blog

Oracle licensing DOES NOT change , from a licensing perspective, whether you run Oracle workloads on a

Classic vSphere environment connected to a NAS / SAN / iSCSI / NVMe
Hyper-Converged Infrastructure solution vSAN
Oracle workloads on VMware Cloud e.g. VMware Cloud on AWS

Understanding Oracle Licensing on VMware vSphere / vSAN environments

As has been very well documented, Oracle licensing is not based on Memory, Storage, Cluster, vCenter or Network. It is either User-based (Named User Plus) or Processor-based (Socket-based in case of Standard Edition 2 (SE2) or core-based in case of Enterprise Edition (EE) ).

There are only 3 documents which are relevant for any Oracle licensing discussion and contract:

The OLSA/OMA states “Processor: shall be defined as all processors where the Oracle programs are installed and/or running.”

Deploying Oracle Workloads on VMware environments

Some key things to keep in mind when we talk about VMware vSphere Platform, ESXi hypervisor, and vSAN:

VMware vSphere is a platform of virtualized hardware that creates a total abstraction layer between the O/S and the Hardware
ESXi, is a non-Para virtualized, Type1 hypervisor and therefore makes no changes to the kernel of the guest operating system
VMware vSAN , the industry-leading software powering Hyper-Converged Infrastructure solution, in no way changes the location of where compute runs, and hence does not directly impact the licensing impact of any CPU Core or Socket based licensing

When using the Processor (Socket in case of SE2 or cores in case of EE edition) based Oracle licensing model, customers choose one of the 3 approaches:

1) Dedicated vSphere Cluster for Oracle VMs. This model is a widely accepted model purely from an Oracle licensing perspective.

2) Common vSphere Cluster using DRS-Host Affinity rules where the Affinity rules are used “bind” Oracle VMs to a set of ESXi servers pre-designated for Oracle workloads

The above 2 options are explained in the blog post “Preparing for an Oracle audit”.

3) VMware CPU Affinity model which allows for the binding of the VMs running Oracle workloads to specific processors.

More details on Oracle licensing on VMware vSphere Platform, ESXi hypervisor, and vSAN can be found in this article.

All Oracle licensing collateral on vSphere can be found at

What’s New September 6th, 2018 (SDDC Version 1.5) – ‘Compute Policies’

More details of the VMware Cloud on AWS base cluster configuration can be found in this white paper, as well as in the VMware Cloud on AWS FAQs. An FAQ for third party software considerations can be found at Third Party Technology Solutions.

With September 6th, 2018 (SDDC Version 1.5), new features for VMware Cloud on AWS which are now available now includes :

Compute Policies
Compute Policies enable customers to define VM placement constraints as preferential policies in their SDDC by leveraging inventory tags. In a multi-cluster environment, a single policy can be defined to constrain the placement of tagged VMs using the following capabilities:

Simple VM-Host Affinity
This capability constrains the placement of tagged VMs on specifically tagged hosts in each cluster, thereby circumventing the need to define rules on a per-cluster basis.
VM-VM Anti-Affinity
This policy allows the user to specify anti-affinity relations between a group of VMs. These groups of VMs are identified using vSphere tags. The policy automatically applies to all the VMs that have the tags specified in the policy. DRS will try to ensure that all the VMs in the vCenter that have the policy’s VM-tag, are preferably placed on separate hosts.
Disable DRS vMotion
This policy allows the user to specify that a virtual machine not be migrated away from the host on which it was powered-on, unless the host is placed into maintenance mode.

More information on the ‘September 6th, 2018 (SDDC Version 1.5) – Compute Policies’ feature can be found here.

With this release , we can use VM – Host affinity rules to bind Oracle VMs to a set of ESXi servers within the SDDC cluster is available. As mentioned above , VM placement constraints are preferential policies.

Key aspect to keep in mind is the difference between a mandatory policy and preferential policy. Mandatory policies are equivalent to the DRS “must” rules, while preferential policies are similar to the DRS “should” rules.

Preferential policies cannot block a host from entering into maintenance mode. However, a policy cannot be violated for fixing cluster imbalance or host over-utilization.

FAQ on ‘Compute Policy’ can be found here.

New Feature announced on September 10th, 2018 – Three Host SDDC

Before this point, the minimum cluster size was 4 hosts with each host with 2 sockets, 18 cores per socket.

With this new release, the minimum cluster size for SDDC deployments has been reduced to three hosts. These are considered full production SDDCs and will be treated like four host SDDCs from an SLA and supportability point of view.

Customers can scale up to four hosts or down to three hosts by simply adding or removing hosts from existing SDDCs. New SDDCs can be created by selecting three hosts at deployment time.

With this feature release , customers do not have to go with the minimum 4 node SDDC, they now have a choice to go with the minimum 3 node SDDC and pay reduced Oracle licensing costs with this setup.

More information on the ‘Three Host SDDC’ feature can be found here. As we are al aware, the maximum cluster size is 16 ESXi hosts.

Facts about the Single Host SDDC

The minimum size SDDC that you can create in VMware Cloud on AWS is 1 host with the Single Host SDDC. However, 1 host SDDCs have a limited SLA and are not for production use.

The smallest production SDDC that we support is 3 hosts. With our Single Host SDDC starter configuration, customers can create single host SDDC environments. For more details, refer to the Single Host SDDC FAQ section.

FAQs on ‘Single Host SDDC’ can be found here.

vSphere Tags and Attributes

Tags and attributes allow you to attach metadata to objects in the vSphere inventory to make it easier to sort and search for these objects.

A tag is a label that you can apply to objects in the vSphere inventory. When you create a tag, you assign that tag to a category. Categories allow you to group related tags together. When you define a category, you can specify the object types for its tags, and whether more than one tag in the category can be applied to an object.

For vSphere Tags and Attributes, VMware Cloud on AWS supports the same set of tasks as an on-premises SDDC

More information on this can be found here.

Affinity rules in VMware Cloud on AWS

Since Sept 6th 2018, VM – Host affinity and VM – VM Anti Affinity rules in the VMware Cloud on AWS SDDC is available , so we can use use VM – Host affinity rules to bind Oracle VMs to a set of ESXi servers within the SDDC cluster is available.

As part of this framework, we are introducing a set of policies that the customer can now take advantage of to improve workload performance and uptime as well as simplify management of licensing cost.

Affinity rules: Enable policy-based control of VM placement and resourcing decisions based on user inten

VM-Host Affinity: Ability to associate VMs to a specific host group within a VMware Cloud on AWS SDDC cluster. This capability enables customers to optimize their application software licensing costs and TCO. It allows customers to implement VM-Host placement constraints as preferential policies at the SDDC level by leveraging inventory tags. Note: These preferential policies allow failovers and evacuation of VMs when a host is placed into maintenance
VM-VM Anti-Affinity: Ability to spread a specific group of virtual machines across multiple hosts for higher availability for mission-critical applications. This prevents simultaneous failure of those virtual machines in the event that a host fails.

More information on this can be found here.

This post Oracle RAC on Stretched Clusters for VMware Cloud on AWS – Anti-Affinity within AZ & HA across AZs focuses on to effectively provide Site level HA along with Infrastructure level HA to an Oracle RAC on Stretched Clusters for VMware Cloud on AWS using vSphere Tags and Attributes.

Impact of Host Auto Remediation on VMware Cloud on AWS on Oracle Licensing

From the “VMware Cloud on AWS Operations Guide”

Auto-remediation – During auto-remediation, a failed host is replaced by a new host, and its host tags are applied to the replacement host. While auto-remediation is in progress, the current recommendations by the Elastic DRS algorithm are ignored. After auto-remediation completes, the algorithm runs again and fresh recommendations are applied. If an auto-remediation event is initiated for a cluster while an Elastic DRS recommendation is being applied to that cluster, the auto-remediation task is queued. After the Elastic DRS recommendation task completes, the auto-remediation task starts.

For example, in a 3 Node SDDC dedicated for Oracle , for sake of simplicity , lets name the servers ‘S1’, ‘S2’ & ‘S3’ .

The Oracle VM’s have been tagged appropriately with the VM tags
The ESXi servers ‘S1’, ‘S2’, ‘S3’ have been tagged appropriately with the host tags
Compute Policies are set in place for VM-Host Affinity to ensure the Oracle VM’s only runs on Oracle Host’s
Servers ‘S1’, ‘S2’ ad ‘S3’ are fully licensed for Oracle Licensing
We have Oracle workloads running on ‘S1’, ‘S2’ and ‘S3’.

Now ‘S1’ is facing a component failure e.g faulty DIMM, faulty network card , bad socket board etc.

The sequence that follows would be :

-The Auto remediation workflow for adding a Host kicks off
-EDRS recommendation is ignored when Auto Remediation starts
-vSphere DRS is still active and may be moving VM’s from S1 , which is still up , to S2 and S3 at this point
-Now the workflow introduces a new server ‘S4 ‘ as part of the auto remediation process without any host tags
-In parallel the workflow is working on reviving the failed ‘S1’ server , if it is able to successfully revive and resurrect ‘S1’ , then ‘S4’ will be removed else ‘S1’ will be removed and ‘S4’ will be the new ‘S1’
-Tags for the new injected ‘S4’ host is added by auto-remediation and ‘S4’ gets host tags only after the failed host ‘S1’ is removed
-Meanwhile DRS is active and is in the process of moving off VM’s from S1 to S2, S3 and possibly can move some VM’s to the new server S4
-In case server ‘S1’ is PSOD , then HA will bring up VM’s on S2, S3 and possibly on the new server S4

Now the above scenario would result in Oracle VM’s concurrently running on 4 Servers of which server ‘S4’ is unlicensed for Oracle Licensing. Hence , we would need to “Compensate” / “Factor” for the extra server injected. That is the “Compensation factor”.

Remember, Compute policies are a “SHOULD” / Soft policy and NOT a “MUST” / Hard policy. In the scenario we discussed, that means VMs could get moved to the new host even before it has the right tags. vSphere DRS does not look at Tags whereas vSphere Compute Policy does.

On-premises vSphere DRS rules will not move the VMs to new host in this same scenario till the DRS rules are modified but DRS rules are not exposed on the VMware Cloud on AWS.

Oracle Software Licensing Basics

From the “Oracle Software Licensing Basics” ;

License Term provides the timeline for customer’s usage

Perpetual License is the right to use the license perpetually
Term Licensing provides the right to use the license for specified period (1 5 years)

https://www.oracle.com/a/ocom/docs/corporate/oracle-software-licensing-basics.pdf

Oracle Licensing permits customers to purchase “Term Licensing” which provides customers the right to use the Oracle license for specified period (1 5 years) .

Oracle Term Licensing can help with providing relief when it comes to providing for the ” Compensation Factor” as part of the Auto Remediation in case of a host failure , which is not very often. This helps reducing the cost factor when it comes to buying Oracle EE Licensing for 1 whole server .

Bringing it together – Understanding Oracle Licensing on the VMware Cloud on AWS

With VMware Cloud on AWS, customers who wish to deploy a dedicated SDDC cluster for their Oracle workloads using Enterprise Edition (EE) will use the same formula for calculating the effective number of cores as they have in non-cloud based systems.

For example, in the VMware Cloud on AWS, every host has 2 sockets with 18 cores per socket. The absolute number of cores for that 1 host = No of sockets per host * no of cores per socket 2 x 18 = 36 physical cores

Therefore, the effective number of cores for licensing Oracle workloads using Enterprise Edition (EE) for that 1 host = Absolute number of cores * Processor Core Factor = 36 x 0.5 = 18 effective cores per host

Given the effective number of cores liable for Oracle licensing per host in the SDDC cluster, we can then determine the effective number of cores we need to license for Oracle for ALL of the hosts in the SDDC cluster.

As part of provisioning the SDDC cluster for Oracle workload , the number of ESXi servers needed to sustain the workload (Current Usage + Capacity Planning for future growth) needs to be calculated.

Assume number of ESXi servers needed to sustain the workload = N (N is NOT the number of ESXi servers in the SDDC Cluster, it is the number of ESXI servers needed to sustain the Oracle workload)

For a non-stretched SDDC Cluster :

As part of the next step , for Oracle Licensing compliance , we need to do the following steps

Tag ALL the Oracle VM’s with the appropriate Oracle tag
Tag (N+1) ESXi hosts in the Oracle SDDC Cluster
License the (N+1) ESXi hosts identified as Oracle ESXi servers in the SDDC Cluster

For example , on determination that N=3 is the number of ESXi servers needed to sustain Oracle workloads, we would need to

License (N+1) = 4 servers for Oracle Licensing purpose
Tag all Oracle VM’s and 4 ESXi servers with appropriate Oracle tag

A stretched SDDC Cluster is logically a Single Cluster stretched across 2 AZ’s and hence even if we have 2 AZ’s, we only have to compensate for 1 single server , as the possibility of 2 servers failing simultaneously is not very often.

The above calculations are done taking into account a 1 Node failure. For multiple node failure scenarios, one would have to compensate accordingly.

In case of any hard Host failure, the customer will receive appropriate notification from the VMware Cloud on AWS SRE team about the failed host.

This way we take into account , different scenarios like Host Maintenance for patching/upgrade, Failed Host Component / Host replacement to ensure that we are always compliant from an Oracle Licensing perspective.

It is the customers responsibility to appropriately Tag the new ESXi server in the SDDC cluster which has been introduced to replace the failed host with the appropriate Oracle Tag so that the Oracle VMs can use the original N+1 capacity, they had to start with , prior the host failure to ensure continued Oracle license compliance.

Conclusion

Oracle licensing DOES NOT change , from a licensing perspective, whether you run Oracle workloads on a

Classic vSphere environment connected to a NAS / SAN / iSCSI / NVMe
Hyper-Converged Infrastructure solution vSAN
Oracle workloads on VMware Cloud e.g. VMware Cloud on AWS

When evaluating licensing for all deployment options it is important to consider Maintenance, Retirement, and Failed hardware host replacement.

Please consult the above reference FAQ or future VMware Cloud documentation to fully understand how these processes work for VMware Cloud on AWS.

All Oracle on vSphere white papers including Oracle licensing on vSphere/vSAN, Oracle best practices, RAC deployment guides, workload characterization guide can be found in the following documents:

Oracle on VMware Collateral – One Stop Shop