Blog updated on June 18th, 2019.
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.
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, Hyper-Converged Infrastructure solution like vSAN, or VMware Cloud on AWS.
VMware Cloud on AWS – Compute Cluster Configuration – Initial availability model
At initial availability, the VMware Cloud on AWS base compute cluster configuration contains
- 4 hosts with 2TB of memory total with each host configured with 512GB of memory
- Each host contains dual CPU sockets that are populated by a custom-built Intel Xeon Processor E5-2686 v4 CPU package
- Each socket contains 18 cores running at 2.3GHz, resulting in a physical cluster core count of 144
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.
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:
- Technical Support Policy
- Processor Core Factor Table
- Oracle License and Service Agreement (OLSA) / Oracle Master Agreement (OMA)
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
- Oracle Licensing Webinar Recording
- Updated Understanding Oracle Licensing, Certification and Support on VMware guide
- Licensing Databases on EMC and VMware Technology
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.
Therefore, the effective number of cores for licensing Oracle workloads using Enterprise Edition (EE) for that 1 host = Absolute number of cores / per socket per host * Processor Core Factor
= 2 x 18 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, taking into account Maintenance, Retirement, and Failed hardware host replacement.
What’s New September 6th, 2018 (SDDC Version 1.5)
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.
From an Oracle licensing perspective, this policy will be violated when a host enters a maintenance mode. Hence once we determine the effective number of cores we need to license for Oracle for all of the hosts in the SDDC cluster, we also need to take into account Maintenance, Retirement, and Failed hardware host replacement.
FAQ on ‘Compute Policy’ 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 intent.
- 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.
Conclusion
In conclusion, Oracle licensing does not change from a licensing perspective, whether you run Oracle workloads on a classic vSphere environment, Hyper-Converged Infrastructure solution like vSAN, or 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.
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.
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:
