posted

0 Comments

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
  • Understanding Oracle Licensing on the VMware Cloud on AWS
  • New Feature – Compute Policies – September 6th, 2018 (SDDC Version 1.5)
  • New Feature – Three Host SDDC – September 10th, 2018
  • Single Host SDDC
  • 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’

 

 

 

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:

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, 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 the VMware Cloud on AWS

 

As we are already aware of , Effective number of cores for licensing Oracle workloads using Enterprise Edition (EE) for 1 host = Absolute number of cores / per socket per host * Processor Core Factor

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.

More details can be found at in the post ‘Oracle on VMware Cloud on AWS – Unraveling the licensing myth.

 

 

 

New Feature announced on September 6th, 2018 (SDDC Version 1.5)  – Compute Policies

 

With September 6th, 2018 (SDDC Version 1.5), a new feature called ‘Compute Policies’ was released which enabled customers to define VM placement constraints as preferential policies in their SDDC by leveraging inventory tags.

This would allow customers to define

  • Simple VM-Host Affinity
  • VM-VM Anti-Affinity
  • Disable DRS vMotion

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.

More details can be found at in the post ‘Oracle on VMware Cloud on AWS – Unraveling the licensing myth’.

 

 

 

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.

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 the hosts in the 3 node SDDC cluster, taking into account Maintenance, Retirement, and Failed hardware host replacement.

 

 

 

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.

 

 

 

Brand New Feature – Custom CPU Core Count – What’s New February 12th, 2019 (SDDC Version 1.6)

 

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.

Before, you were not able to specify how many CPU cores per host you want in your cluster. It was always all CPU cores enabled: 36 for I3 or 48 for R5 host types.

Now, you can also select 8 or 16 CPU cores per host to better tailor your SDDC cluster for your needs.

 

 

 

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 firs / initial cluster must have all cores enabled and al subsequent clusters 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
    • number of cores (8 / 16 / 36) in case of i3 hosts
    • number of cores (8 / 16 / 48) in case of r5 hosts.

 

 

 

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’, there are 2 options for core count

  • number of cores (8 / 16 / 36) in case of i3 hosts
  • number of cores (8 / 16 / 48) in case of r5 hosts

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

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 the hosts in the SDDC cluster, taking into account Maintenance, Retirement, and Failed hardware host replacement.

As mentioned above the initial Cluster i.e. Cluster 1 , in this case , has all cores enabled.

 

 

 

 

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.

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