Oracle on GCVE – Support, License & Architecture Considerations

by | Aug 26, 2020 | Cloud, Cloud Computing, Oracle, Oracle Licensing | 0 comments

Bob Lindquist, Client Services Director and Mike Stone (@HoBMStone), CIO & Principal Architect

The Journey of Oracle & Google Cloud

House of Brick has worked with Google for many years, advising on the best ways to run Oracle workloads in Google Cloud. We presented to NoCOUG in February 2018 about the options available at that time for deploying Oracle in Google Cloud.

Until recently, the primary options for deploying Oracle database workloads with Google Cloud Platform (GCP) were:

  1. Rehost – move to a bare metal solution in a co-located data center with GCP high speed interconnects
  2. Replatform – migrate to an open source database such as Cloud SQL for PostgreSQL
  3. Rewrite – refactor application and database workloads to leverage a cloud native option like Google Cloud Spanner

While these options were feasible, they required a good amount of upfront planning and logistical effort to execute.  For many Oracle customers, especially those that ran Oracle database-dependent applications, the challenges meant keeping Oracle on premises while moving other, non-Oracle workloads, to GCP.

Google Cloud VMware Engine – A Bridge to Cloud for Oracle Workloads

With the May 2020 announcement of Google Cloud VMware Engine (GCVE), Oracle customers now have a new option offered by the Google and VMware partnership. Instead of worrying about replatforming or rewriting, customers who have virtualized their Oracle workloads on VMware vSphere can move their workloads to a VMware service on GCP, managed by Google Cloud.

The GCVE announcement further confirms  support statements as noted in a July 2020 blog by Sudhir Balasubramanian of VMware.  With these statements, and proven support for on premises Oracle on VMware deployments, customers can be assured that Oracle on GCVE is a viable option.

Oracle & Cloud Considerations – Support, Licensing & Architecture

For over six years, HoB has been speaking about support, license, and architecture considerations for Oracle customers considering private and public cloud options.  We have written a variety of blogs and white papers, and presented at several conferences, including VMworld, to counter the Fear, Uncertainty and Doubt (FUD) which Oracle sales teams use to confuse customers.

We have also assisted many customers in successfully deploying Oracle on VMware to the cloud.  All of these customers have received support from Oracle when needed.  While Oracle sales teams issue threats or execute audits to try to get customers to Oracle Cloud instead, we have been able to defend customers against such actions, so they receive continuous support.

House of Brick has heard five core myths for Oracle & cloud deployments, which may still need to be busted:

  1. The Oracle license agreement is confusing and intentionally vague when it comes to the cloud.
  2. It costs twice as much to run Oracle in a public cloud than it does in the Oracle Cloud.
  3. Licensing Oracle applications in the cloud is a complex process.
  4. If they run in a public cloud, people should be afraid of Oracle audits.
  5. The Oracle Cloud is the best solution for running Oracle software.

In six years, public cloud options for database workloads have come a long way. The new GCVE option fills several gaps for business critical workloads, such as Oracle, to be well supported in the cloud.

Oracle on GCVE – the “Lift & Shift” Option for VMware Virtualized Oracle Workloads

With the announcement of GCVE, Oracle customers now have a new “Lift & Shift” option for:

  1. Running Oracle on vSphere hosted by Google, using current Oracle support
  2. Using dedicated hosts with Oracle licensable core counts
  3. Reducing cores on each GCVE node to optimize needed Oracle licenses
  4. Architecting the GCVE nodes to limit movement of Oracle VMs
  5. Leveraging GCVE with a private cloud for Oracle HA, DR, and other use cases

Whether or not the Oracle customer is running on VMware today, moving Oracle to GCVE is a great bridge for moving business-critical workloads into the cloud, as well as leveraging other GCP features.  Google’s CIO Guide to Application Migration (see page 15) is a good reference, and provides steps for moving to Google Cloud Platform. It also describes how GCVE helps meet customer’s needs no matter where they are in the cloud journey

, Oracle on GCVE – Support, License & Architecture Considerations

Source: CIO Guide to Application Migration – page 15

Running Oracle on vSphere Hosted by Google Using Current Oracle Support

As HoB has seen for more than a decade, customers running Oracle on VMware have been receiving full and productive technical support.  This fact is also noted in VMware‘s GCVE blog (referenced above):

My Oracle Support Portal Note 249212.1 states “Oracle customers with an active support contract and running supported versions of Oracle products will receive assistance from Oracle when running those products on VMware virtualized environments.

Since GCVE is using VMware vSphere to host Oracle workloads, the same support statement applies to such deployments.  There are other GCVE deployment considerations we will outline further, but Oracle customers with current Oracle Support contracts will receive any needed patches or other support when deployed on GCVE.

Using Dedicated Hosts with Oracle Licensable Core Counts

A key benefit of GCVE for Oracle customers is the use of dedicated hosts.  A GCVE cluster is composed of a minimum of three dedicated hosts each with a minimum of 36 Intel cores.  Oracle processor licensing for Intel chips uses a .5 core factor, meaning that one Oracle processor license is needed for every two cores where Oracle is “installed and/or running”.  For a three-node cluster of GCVE, this would equate to 18 Oracle processor licenses for customers doing BYOL (Bring Your Own License).

Oracle sales teams may try to use what they call the “Oracle Cloud Policy” to further confuse customers about their cloud licensing options.  We have a variety of blogs and conference presentations that clarify what this “policy” actually means.  To note, Google is not specifically mentioned in the Oracle document titled Licensing Oracle Software in the Cloud Computing Environment.

BYOL can be the most cost-effective Oracle licensing option when deploying to GCVE.  Instead of worrying about vCPU licensing or other options that Oracle may push, BYOL – along with the next consideration we describe – is usually the simplest approach.

Reducing Cores on Each GCVE Node to Optimize Needed Oracle Licenses

Another benefit of GCVE is the ability to reduce cores on a cluster’s nodes using a feature called “custom core counts”.  Using the example above, a three-node cluster of GCVE will usually have 36 cores per node.  Even with BYOL, the Oracle processor license costs can be significant for the 18 licenses required.

However, if each node disabled 18 of the 36 cores, then Oracle would be “installed &/or running” on just 18 cores  total – so only nine processor licenses would be required per node instead of 18.  At nearly $50,000 USD (list price) for Oracle Enterprise Edition Database licenses, this offers a savings of almost $450,000 USD per node.

While custom core counts may not change the cost of the GCVE nodes themselves, the Oracle license savings more than make up for any such platform cost.  When talking about a cluster (or multiple clusters) with more than three nodes, the Oracle license savings can easily reach millions of dollars for database and other Oracle product licenses.

Architecting the GCVE Nodes to Limit Movement of Oracle VMs

One of the greatest Oracle myths is that customers running Oracle on VMware need to license VMware servers that aren’t running Oracle.  We will wait a minute while you re-read that statement…

…okay, welcome back.  This myth got so ludicrous that we actually created a comic called “The Oracle Parking Garage” that we’ve used in many presentations and other HoB materials.  To paraphrase the comic, the above statement is like someone telling you to pay for every spot in a garage since you could have parked in any of them.

, Oracle on GCVE – Support, License & Architecture Considerations
The Oracle Parking Garage comic

This is where VMware’s host and anti-host affinity rules for vMotion come into play.  As any VMware administrator knows, vSphere VMs can be restricted from moving to other hosts via vCenter.  This means, for a GCVE deployment of Oracle using the three-node cluster, rules can be set so that the VMs running Oracle stay on only two nodes.  This is a VMware architecture that we have successfully defended each and every time a customer has involved HoB in a related Oracle audit.

The obvious benefit of using host and anti-host affinity rules is license savings.  Using the customer core count example above of 18 core nodes, we can restrict the VMs running Oracle to just two nodes of 18 cores each.  This means a total of 36 cores require Oracle processor licenses, using that same example’s dollar figures, and amounts to an additional savings of nine processor licenses that are no longer needed for the third node.  This equates to an additional $450,000 USD in savings from using the affinity rules to restrict use of the third node.

To summarize the combined custom core counts and affinity rule scenario, Oracle Enterprise Edition Database deployed on GCVE would now only require 18 processor licenses at a cost of approximately $900,000 USD for the cluster – compared to a cost of $2,700,000 USD to license Oracle EE Database on a full three-node GCVE cluster.  Using custom core counts and affinity rules affords a savings of about $1,800,000 USD on Oracle Enterprise Edition Database in this scenario.

Leveraging GCVE with a Private Cloud for Oracle DR and Other Use Cases

GCVE leverages the common VMware Cloud Foundation tools that customers use for on-premises deployments of VMware.  This means that for use cases like Disaster Recovery (DR), GCVE is a great fit for utilizing VMware SRM and other tools to keep key workloads available in the event certain situations occur.

The same considerations apply for using GCVE for DR as noted previously.  The support, license and architecture implications should be considered thoroughly to ensure an optimized and audit defensible deployment of Oracle DR.

As a second site for Oracle DR or other use cases, GCVE can be considered as a viable alternative to incurring the capital and operational costs of a dedicated DR data center.  Also, GCVE is a service managed by Google Cloud, letting customers’ staff focus on more important business and IT concerns.

Summary – Deploy Oracle on GCVE with Confidence

With the general release of Google Cloud VMware Engine, Oracle customers now have a Google Cloud Platform based option to confidently deploy their database workloads in a public cloud environment.

This includes being secure in the knowledge that for Oracle on GCVE deployments:

  • Support – the deployment is supportable by Oracle & VMware
  • Licensing – that options exist to optimize licenses used for Oracle on GCVE
  • Architecture – use cases are available for DR, managed services, and other hybrid cloud needs

 

Lastly, customers are well aware that their Oracle contracts allow for regular audits of product deployments. But,  this is not a reason for fear – quite the opposite.  As GCVE affords Oracle customers the options to deploy an audit defensible architecture that is supportable and licensable.

House of Brick has helped many Oracle customers optimize their costs when deploying to cloud’s like GCVE.  For more information on our professional services and engagement options, please see the House of Brick Services Overview.

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *