Oracle on VMware Cloud on AWS – Custom CPU Core Count
VMware Cloud on AWS is an on-demand service that enables customers to run applications across vSphere-based cloud environments with access to a broad range of AWS services. Powered by VMware Cloud Foundation, this service integrates vSphere, vSAN and NSX along with VMware vCenter management, and is optimized to run on dedicated, elastic, bare-metal AWS infrastructure. ESXi hosts in VMware Cloud on AWS reside in an AWS availability Zone (AZ) and are protected by vSphere HA.
The use case for deploying VMware Cloud on AWS are multi-fold namely
- Data Center Extension & DR
- Cloud Migration
- Application modernization & Next-Generation Apps build out
The following topics are covered in this blog post in the following order –
- VMware Cloud on AWS –Initial availability model
- Brand New Feature – Custom CPU Core Count – February 12th, 2019 (SDDC Version 1.6)
- Important considerations regarding Custom CPU Core Count capability
- Oracle Licensing Considerations with ‘Custom CPU Core Count’ feature
- Understanding Oracle Licensing on the VMware Cloud on AWS with ‘Custom CPU Core Count’
- 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
As has been very well documented in the previous blog post , 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.”
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
Brand New Feature – Custom CPU Core Count – What’s New February 12th, 2019 (SDDC Version 1.6)
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 the ‘What’s New February 12th, 2019 (SDDC Version 1.6)’ announcement , VMware Cloud on AWS now supports Custom CPU Core Count capability.
This capability gives you more flexibility in configuring SDDC clusters and allows you to reduce costs for running mission-critical applications licensed per-core.
More information on Custom CPU Core Count can be found at Feature Brief: Custom CPU Core Count
More details can be found in the post ‘Significantly cut application licensing costs by using the new VMware Cloud on AWS feature Custom CPU Core Count.
Important considerations regarding Custom CPU Core Count capability
- This feature is for additional clusters ONLY i.e the first / initial cluster ie the management cluster must have all cores enabled, see VMware Cloud on AWS – FAQ – Current limitations of the Custom CPU Core Count Capability
- All subsequent clusters (except cluster 1 ie the management cluster ) can have this feature
- Changing the number of cores does not affect the price of the host
- This is at “Add Cluster” deployment time decision only. This cannot be changed post deployment.
- All hosts in the cluster must have the same number of CPU cores, including Add/Remove Host operations.
More details about the above considerations can be found here and here .
An important caveat to keep in mind is reducing core count affects the compute performance of all workloads on the host and increases the likelihood of system performance degradation. For example, vCenter and vSAN overhead can become more noticeable, and operations like adding clusters and hosts can take longer to complete.
Oracle Licensing Considerations with ‘Custom CPU Core Count’ feature
With respect to Oracle licensing , we can now have best of both the worlds
- We no longer need to provision a minimum 4 node SDDC cluster , we can now provision a minimum 3 node SDDC Cluster
- We now have the capability of specifying how many cores we need per node when deploying the SDDC cluster
Understanding Oracle Licensing on the VMware Cloud on AWS with ‘Custom CPU Core Count’
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 with ‘Custom CPU Core Count’, for i3 hosts, there are 3 options for core count
- Default Physical Cores – number of cores is 36 cores
- standard 2 host cluster/ stretched 2 & 4 host cluster – number of cores can be reduce to 16
- standard 3+ host cluster/ stretched 6+ host cluster – number of cores can be reduce to 8 or 16
In this example ,. Cluster 2 was deployed with 8 cores per socket ie total of 16 cores per server.
Cluster 2 has 3 nodes , each node with 2 socket , 8 cores per socket.
Therefore, effective number of cores for licensing Oracle workloads using Enterprise Edition (EE) for 1 node = ( number of sockets) * ( number of cores / per socket) * Processor Core Factor = 2 x 8 x 0.5 = 8 effective cores per host
As mentioned above the initial Cluster i.e. Cluster 1 , in this case , has all cores enabled.
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.
More details can be found at in the post ‘Oracle on VMware Cloud on AWS – Unraveling the licensing myth.
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:
