Counting Licenses on Azure AVS
Introduction
As companies move their workloads to the cloud, or change cloud service providers, they are often faced with the challenge of how to license their Oracle database software. Oracle does not make it easy. Typically, there is nothing in the Oracle-Customer contracts that defines this licensing. To be fair to Oracle, cloud offerings are constantly changing, and it would be impossible to define every scenario on a license agreement. Oracle does publish some cloud licensing guidelines, but these change constantly and are not part of the contractual relationship between the parties. In fact, this document changed three times this year alone. Companies cannot and should not modify their licensing approach based on this fleeting guidance.
The good news is there are several cloud offerings, that if implemented correctly, will closely align with Oracle’s published and unpublished rules on licensing their software. One such option is Microsoft’s Azure AVS.
What is Azure AVS?
Azure VMware Solution (AVS) is a Microsoft service, verified by VMware, that runs on dedicated and isolated bare-metal Azure infrastructure. AVS serves as a private VMware cloud where customers migrate on-premises workloads to dedicated clusters.
AVS offers node/server configurations based on core, memory, and storage. A minimum of 3-nodes is required to deploy in AVS.
Customers looking for AVS licensing guidelines from Oracle will face the same issue as for on-premise VMware deployments. There remains a lack of documentation from Oracle on VMware. The good news is, unlike VMware on-premises, where you are forced to license or re-configure your VMWare farm, the AVS setup, if done correctly, is already in close alignment to Oracle requirements.
Aligning with Oracle’s Unwritten VMware “Rules”
Oracle has 2 primary considerations when licensing their software to run on VMware. First, are the cluster(s)/vCenter(s) you are considering for licensing isolated such that you cannot vMotion outside of the isolated environment? The second is around storage. Does it only serve the isolated environment or, if shared, segmented in a way that the LUNS are only presented to the VMs in the isolated environment?
The main driving force behind the first requirement is to restrict the ability of vMotion. Oracle’s default stance will be to ask customers to license all physical cores across all the hardware where you can vMotion. As an example, if you deploy Oracle programs on one cluster and cannot vMotion outside of that cluster, then you license all the physical cores across all the hardware in that cluster. If you can vMotion between 2 clusters, then you must license all the physical cores across both clusters. If there is no restriction on vMotion, then Oracle will ask you to license all physical cores within the scope of vMotion’s ability.
Outside of vMotion, shared storage is also a criterion. Oracle’s view is that any data on shared storage can be accessed by any hardware connected to the storage. To prevent this, Oracle wants you to either (i) separate storage servicing the isolated environment or (ii) if shared then the storage must be segmented in a way that the LUNS are only presented to the VMs in the isolated environment.
To align with Oracle’s unwritten rules, you must demonstrate both. Keeping a record/report of your migration activities will help support your position.
The Microsoft AVS setup consists of Software-Defined Data Centers (SDDC). Within the SDDC, you have a vCenter which may manage multiple clusters. You can vMotion between clusters within the same SDDC but cannot vMotion across SDDCs without significant effort.
As noted above, when it comes to licensing, Oracle is tracking the ability to vMotion. For the most efficient license setup, the SDDC must be one of your considerations when deploying Oracle programs in AVS.
Deploying Oracle programs on single cluster in AVS
If your only AVS estate is a single dedicated cluster hosting Oracle programs, then by default you won’t have access to any other clusters and cannot vMotion outside of your own cluster. This setup is in close alignment with Oracle’s first requirement. From a storage perspective, your cluster will be supported by its own data store. In essence, the default AVS setup aligns with Oracle’s requirements. Licenses required for each Oracle program will be based on the total number of physical cores across the cluster.
Deploying Oracle and Non-Oracle programs on multiple clusters in AVS
If you intend to use multiple clusters, some of which may host Oracle programs, then it is imperative to make sure each of your dedicated clusters hosting Oracle programs reside in different SDDC’s than your non-Oracle clusters. If the Oracle cluster is in the same SDDC as the non-Oracle clusters, then you will have the ability to vMotion across all your clusters and Oracle will require you to license all the physical cores across all clusters including the non-Oracle clusters.
If your Oracle cluster is in a separate SDDC from your non-Oracle clusters, you cannot vMotion between the clusters in different SDDC’s. It takes significant effort to configure your clusters to allow vMotion. In this case, you would only need to license all the physical cores across the Oracle clusters
The key to being license efficient is to make sure your Oracle cluster is in a different SDDC than your non-Oracle cluster.
Deploying multiple Oracle programs on multiple clusters in AVS
Let’s say you have multiple clusters with a mix of Oracle and Non-Oracle clusters. In addition, you have one cluster dedicated to the Oracle database programs and another dedicated to Oracle middleware programs. As noted above, the Oracle and Non-Oracle clusters should reside in separate SDDCs to restrict licensing to only the physical cores in the Oracle cluster. With multiple Oracle programs, it is recommended to take this one step further and separate your Oracle cluster hosting different Oracle programs. In this case, the cluster hosting the Oracle database programs should reside in a separate SDDC than the cluster hosting Oracle middleware programs.
If the database and middleware clusters reside in the same SDDC, you will need to license both clusters for both Oracle database and middleware programs. If they are in separate SDDCs, then you only license one cluster for Oracle database programs and one cluster for middleware programs.
Further, being in separate SDDCs means each cluster will have their own data store.
Additionally, you may want to separate clusters into different SDDCs, if you are applying multiple license metrics for the same Oracle program. For example, you are hosting your production Oracle database in one cluster and the non-production database on another cluster in order to use your Processor licenses (production) and your Named user plus licenses (non-production). Keeping them in different SDDCs will allow you to apply both processor and NUP licenses as intended. If both clusters are in the same SDDC, Oracle will ask you to license both by the Processor metric.
The key takeaway here is – when hosting Oracle programs in AVS, it is critical to include SDDCs as part of your planning to be most license and cost efficient.
How to calculate your license requirement
Similar to on-premises, licensing Oracle programs on Azure AVS is based on the total number of physical cores in the dedicated cluster(s). To calculate the license requirement multiply the total physical cores in the cluster by the applicable core factor, which varies from 0.25 – 1.0 depending on the make and model of the processor. The core factor table resides on Oracle’s website (Oracle Processor Core Factor Table).
When licensing by the Named User Plus metric the minimums requirement must be considered. That is, at the very least, you must maintain a minimum number of NUP licenses per licensable processor. The minimums requirements are different for different programs. The minimums may have been negotiated during contract negotiations.
To identify the NUP licenses required you must take the greater of the actual usage or applicable minimums. First calculate the number of licensable processors as noted above. Then multiply that by the minimum requirement. Compare this to the actual usage. Actual usage in non-production is your IT personnel that have access to the deployment. If applying to a production environment, then actual usage includes the front-end users as well. The greater number between actual usage and minimums requirement will be your license requirement.
The table below shows the currently available (August 2024) hardware types in AVS and the associated licensable processors for the cluster, assuming 2 physical servers per cluster.
Note 1– to identify the Named user plus minimum requirement, multiply the ‘Total processor licenses for cluster’ by the applicable program minimum. For Oracle database EE the standard applicable minimum is 25 NUP per processor. For database SE, the minimums are 10 NUP per server and not per processor. For most middleware programs it is 10 NUP per processor.
Note 2- The Host type AV64 cluster is always accompanied by a secondary cluster of one of the other Host types. This may be a good option if you are hosting the same Oracle program across multiple clusters in the same SDDC.
Unlimited License Agreements (ULAs)
If you have a ULA (Unlimited License Agreement) with Oracle and are planning to move to AVS before you certify, then the move to AVS may present an opportunity to further maximize your ULA. The timing of your move will be critical as well. We recommend talking to an independent expert as there may be some nuance based on the contract language in your ULA.
Where To Get Help?
Using Oracle, whether on-premises or in the cloud, is fraught with licensing traps. As you make your cloud journey you may find yourself in need of licensing guidance. There are several places’ people go for advice.
Ask Oracle. If you go to Oracle, be prepared for an audit. They may see your move to a non-Oracle cloud and try to force you to OCI. Also, Oracle is not equipped to give you an independent view of your Oracle licensing. They will always support Oracle’s position, whether or not that fits in with your contracts.
Ask An Oracle Reseller. While not as risky in terms of audits, this group simply does not have the contract and licensing expertise to give you the insights you require. Also, remember that this group makes more money when they sell you more Oracle.
Ask An Independent Expert Advisor. Today there are over 40 companies claiming to be independent licensing experts. Ensure your advisor is truly independent (does not make any money from Oracle, is not owned by a reseller, etc.). Also ensure they have true expertise from working at Oracle in their contracts, business practices, and audit functions. Being a former Oracle salesperson does not make you an Oracle expert.
Palisade Compliance meets both those criteria. Palisade Compliance is 100% independent of Oracle, and we make no money from the sale of their products. Palisade was founded by former Oracle executive and Global Vice President of Contracts, Business Practices, and LMS (Audits). Our team have over 100 years’ experience in the field. Our average Oracle experience per person is greater than that of Oracle’s current team!