Introduction to VMware vSphere , VMware vSAN and VMware Cloud on AWS
Some key things to keep in mind when we talk about VMware vSphere Platform , ESXi hypervisor , vSAN and VMware Cloud on AWS :
- 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
- VMware Cloud on AWS brings VMware’s enterprise-class SDDC software to the AWS Cloud with optimized access to native AWS services. Powered by VMware Cloud Foundation, VMware Cloud on AWS integrates VMware’s compute, storage and network virtualization products (VMware vSphere, VMware vSAN and VMware NSX) along with VMware vCenter Server management, optimized to run on dedicated, elastic, bare-metal AWS infrastructure.
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
Oracle Licensing Myths
There are myths floating around that
- Oracle Licensing requires licensing all of the cores , for every vSphere host , attached to a given vCenter , whether the host is part of the vSphere Cluster which runs Oracle workloads or not
- Oracle licensing requires licensing every Site connected to the Primary site where the Oracle workloads primarily resides
These myths are perpetuated by overzealous licensing and sales teams which is in contrast of the reality of the actual Contractually Impactful documents.
If this were true , it would require you to license EVERY existing vSphere host in EVERY datacenter and cloud , be that yours or a company down the street.
- Starting VMware vSphere 6.0 , Cross vCenter vMotion feature was introduced which allowed customers to live migrate a VM between two different vCenter Servers, part of the same vCenter Single Sign-On (SSO) Domain . So vCenter’s and SSO domains are not an obstacle to vMotion.
- With vCenter Server 7.0 Update 1c, in the vSphere Client, Advanced Cross vCenter vMotion feature was introduced to manage the bulk migration of workloads across vCenter Server systems in different vCenter Single Sign-On domains (Advanced Cross vCenter Server Migration Integrated in vSphere 7 U1c)
Just because you have the capability to do something does not mean you have done it , have you ? So by this above very faulty logic you would need to license every host in the galaxy.
Wow !! That faulty logic would cost you many $$$ , probably buy you a beautiful island 🙂
in other words…. 🙂
This post intends to clear up the reality of how to effectively license Oracle workload on VMware vSphere, vSAN and VMware Cloud on AWS and to make it a cost effective one as well.
Remember Oracle licensing is for Current usage of Compute (Physical Sockets (SE2) / Physical Cores (EE) ) or NUP , not proposed futuristic usage !!! Remember , you only pay for the food you eat at a restaurant , not what there on the menu !!!!
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
Oracle Licensing on VMware and Contractual Documents
Oracle Licensing on VMware sessions have been run successfully in many Trade shows / Events ( notably IOUG, EMC World, VMworld ) , also Webinars, where it has been proved beyond any doubt , that there are only there are only 3 documents which are contractual and relevant for any Oracle licensing discussion and contractual:
- Technical Support Policy
- Processor Core Factor Table
- Oracle License and Service Agreement (OLSA) / Oracle Master Agreement(OMA)
- The OLSA/OMA defines Processor as “Processor: shall be defined as all processors where the Oracle programs are installed and/or running.”
Oracle Partitioning Policy – Non-Contractual
There is another document called “Oracle Partitioning Policy“ which is often mentioned by the licensing and sales team, what they very conveniently fail to mention is that “Oracle Partitioning Policy” is NOT a contractual document.
Two things to keep in mind about the “Oracle Partitioning Policy”
- “Oracle Partitioning Policy” is NOT referenced in any way in the OLSA/OMA and hence is not an artifact in any Oracle Licensing discussion
- Read the disclaimer in the document “This document is for educational purposes only and provides guidelines regarding Oracle’s policies in effect as of April 5, 2016. It may not be incorporated into any contract and does not constitute a contract or a commitment to any specific terms”
So we can safely dispel with this noise and focus on the facts i.e. the Contractual documents.
Thanks to numerous collateral and efforts by our premier partners notably House of Brick , VLSS (LicenseFortress) , License Consulting , we are able to dismiss the ridiculous claim by Oracle Sales about licensing “All Sites” or “Galaxy licensing” as we call it , when it comes to licensing Oracle on VMware.
Anyone who has read the Oracle licensing document, most important, the OLSA / OMA, is well aware that Oracle licenses are either User based (Named User Plus) or Processor(Socket in case of SE2 or cores in case of EE edition) based.
More information about it can be found in the below documents:
Since Oracle licensing is not Memory, Storage, Cluster, vCenter or Network based, its either User based (Named User Plus) or Processor(Socket in case of SE2 or cores in case of EE edition) based, we do not need any memory segmentation, storage segmentation or for that matter any network segmentation based on the above.
Keep in mind none of these segmentation requirements are stipulated in the OLSA / OMA which is a contractual document.
The illustration below of an “Oracle Parking Garage” from House of Brick sums up the FUD!!!
http://houseofbrick.com/the-oracle-parking-garage/
Licensing Oracle workloads on VMware – Example
For example, let’s say we have a vSphere Cluster dedicated to run Oracle workloads called “OraCluster” with 3 ESXi servers, each ESXi server having 2 socket x 10 cores each. The processor is Intel Family.
Total no of effective cores for licensing Oracle workloads in “OraCluster” using Enterprise Edition (EE)
= Absolute number of cores in cluster * Processor Core Factor
= ( 3 servers * 2 sockets per server ) * ( 10 cores/socket ) * ( Processor Core Factor for Intel Family )
= 6 * 10 * 0.5
= 30 Effective cores liable for Oracle licensing
The Processor Core factor table is published by Oracle and can be found at the below url:
http://www.oracle.com/us/corporate/contracts/processor-core-factor-table-070634.pdf
The same logic and formula for calculating effective number of cores applies to licensing Oracle on vSAN or VMware Cloud on AWS.
Licensing Oracle workloads on VMware vSAN (Hybrid/All Flash)
It should be known that running vSAN in no way impacts Oracle licensing and existing tools of segmentation (DRS affinity groups and rules) and existing auditing tools (VMware LogInsight) perform as expected.
Oracle VM uses the compute power of the ESXi servers in the vSAN Cluster to run the Oracle workload , just as in the case of a Classic vSphere Cluster.
As pointed our earlier, Oracle licenses are either User based (Named User Plus) or Processor(Socket in case of SE2 or cores in case of EE edition) based regardless of whether Oracle workloads run on ESXI servers in a vSAN cluster OR vSphere cluster.
Conclusion
In 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
Keep in mind, Oracle licensing is not Memory, Storage, Cluster, vCenter or Network based, its either User based (Named User Plus) or Processor(Socket in case of SE2 or cores in case of EE edition).
To reiterate, there are only 3 documents which are contractual and relevant for any Oracle licensing discussion and contractual:
- Technical Support Policy
- Processor Core Factor Table
- Oracle License and Service Agreement (OLSA) / Oracle Master Agreement(OMA)
- The OLSA/OMA defines Processor as “Processor: shall be defined as all processors where the Oracle programs are installed and/or running.”
All Oracle licensing collateral on vSphere can be found at
- Oracle Licensing Webinar Recording – Links to the webinar and corresponding introduction article
- Updated Understanding Oracle Licensing, Certification and Support on VMware guide
- Licensing Databases on EMC and VMware Technology
To sum it up , the myths perpetuated by overzealous licensing and sales teams is the cause of FUD which customers are facing today.
Who you gonna call ? “Myth busters”
For any Oracle Licensing on VMware help , please reach out to your respective VMware Account teams who can get our team involved in a discussion (Internal VMware folks can reach directly to us at the Tier1-Apps-Sales-Support team mailing list) and we can definitely help guide you and connect you to some of our premier partners if required for further discussions.
