Dave Welch (@OraVBCA), Chief Evangelist and Nick Walter, Principal Architect
On June 14, 2020, Oracle published Oracle Real Application Clusters (RAC) Support on Third-Party Clouds–An Overview and Clarification. It attempts to list reasons why Oracle doesn’t consider any clouds other than their own as supported for Oracle RAC.
Quoting from the brief:
“The lack of natively provided shared storage in addition to certain network limitations that would need to be worked around on most Third-Party Clouds prevent Oracle from supporting Oracle RAC in any Third-Party Cloud regardless of technical feasibility.”
RAC is network connections and voting disk. Oracle customers working with House of Brick to implement RAC in VMware Cloud on AWS have not reported problems configuring RAC. Similarly, we have talked to people who have implemented RAC on AWS native using dedicated hardware. Speaking from first-hand experience, it is not rocket science for a support organization to monitor those network connections and storage. A few years ago there were some valid reasons people could not run RAC in AWS, chiefly the lack of native support for multicast networking. But now there are several well-tested workarounds that eliminate this obstacle. Plus, AWS announced at the last re:Invent conference that they are rolling out native multicast support. The technologies that VMware Cloud on AWS or AWS native use to enable RAC are technically no different than the solutions that are used on-premises to enable multicast networking and shared SCSI disks. Accordingly, Oracle is making a very weak technical argument against supportability.
This backpedaling is a feeble attempt at justifying vendor lock, plain and simple. Taking Oracle Support’s assertion at face value, would therefore translate to concerns that Oracle customers should have as to their ability to be adequately supported by Oracle for any of Oracle’s core technology offerings. If single instance Oracle can be configured and supported in VMware Cloud on AWS or Amazon EC2 for example, so can any other Oracle core technology that may have a few extra network connection types and an additional storage object.
Although there was some hope within House of Brick for Oracle Cloud VMware Solution (OCVS) when announced, we were quite candidly more enthusiastic about the enhanced, less fettered Oracle Support statements that accompanied the announcement. To his credit, Mark Hurd guided the Oracle side of the landmark OCVS agreement. It is difficult for us to imagine that Mark Hurd was, or would be, on board with the new support restriction. The time to announce such a restriction was in the Oracle Support announcement in conjunction with the OCVS announcement, not now. RAC licensing in VMware Cloud on AWS and Amazon EC2 Dedicated Hosts is feasible and attractive. That said, Oracle knows full well that most organizations will not be willing to go there without support. You should be aware of the risks, of course.
The RAC support restriction announcement adds to incentives that IT architecture teams may have to consider competing solutions to Oracle core technology. When it comes to High Availability (HA), every public cloud provider has solutions already available that will bring excellent HA to Oracle workloads. (See Dave Welch’s blog series The RAC Dilemma.)
In our years of observation, through the rise of virtualization, while Oracle Sales was doing everything it could to dissuade customers from implementing Oracle workloads on VMware, Oracle Support was in fact supporting them. Time will tell whether Oracle Support holds true to the newly announced support restriction. Ultimately, Oracle can decide to decline support on service requests that Oracle directly manages for RAC running on third-party clouds. But, it would certainly be a purely competitive move with no technical basis.
Meanwhile, we encourage organizations considering implementing RAC on any third-party cloud to have a look at VMware’s Global Support Services. Consider the landmark VMworld 2014 session “VAPP2980 VMware Global Support Services Panel – What Goes Wrong and How We Fix It.” This session describes the actual day-to-day interaction between the VMware and Oracle Support teams. As you read the detailed minutes of the session, you may be surprised by the motives behind that day to day interaction. Given that the brief includes a quote about customers perhaps being forced to replatform off clouds to prove an issue to Oracle Support, this could be just a retread of the same ploy Oracle used against VMware originally. We hope that the issue fizzles out just like Oracle’s original attempt to scare people away from using VMware did. In the meantime, quoting VMware’s Don Sullivan, “VMware supports Oracle workloads wherever vSphere is in the stack.” That statement hasn’t changed since well before 2014. It doesn’t change now.
June 30, 2020 update:
Today Google announced, ”Google is fully committed to support all Oracle workloads running in Google Cloud VMware Engine.” Implied by that statement is Google’s front-end management of clients’ service requests. The announcement is copious in its use of every conceivable angle to assure that its commitment to provide full support for all Oracle workloads is not misunderstood. Among other things, the announcement makes clear:
- Google works in coordination with VMware Global Support Services.
- Oracle is fully involved in the Service Request as often as may be necessary, minimally due to its TSAnet contractual obligation. This is consistent with Oracle’s routine involvement as detailed in the VMworld 2014 Global Support Services session mentioned above.
We fully expect such unfettered support commitments for all Oracle products from other hyper-scaled cloud providers. Given its competitors’ superior support commitments, is it possible that Oracle will eventually get jealous and pull in their horns on their support statement for RAC on third-party cloud providers?