This is awesomely concise, and should be read carefully as a result.
Particularly awesome is the comment about "*N 9s*". I didn't initially
understand to what he was referring, but then I recognized the "/we need
five 9's availability/" gibberish that management uses, a catchy phrase
that means little in practical terms. Instead, discussions about RTO
(recovery time objective) and MTTR are much more actionable, as Niall
indicates.
Also amazingly awesome is the first bullet item about "/RAC aware
applications ... ONS events via TAF.../" which is another hugely
important point understated wonderfully. Please be sure to comprehend
all that is stated, because *almost everyone believes* that a RAC
database magically imparts transparent application failover to
applications by itself.
Thanks Niall! I'm so stealing this...
On 8/7/2020 7:42 AM, niall.litchfield@xxxxxxxxx wrote:
Hi Amir
We have run RAC on VMWare platforms ( a couple of different versions). My view is that by and large implementing RAC on top of VMWare is usually done for the wrong reasons (to migrate workloads as is and to consolidate workloads). There are a few reasons why you might wish to run RAC.
* You have built RAC aware applications that can already respond
appropriately to ONS events via TAF, Application Continuity etc.
* You have a strictly low downtime tolerance in the event of
failures - as in downtime can be no longer than x seconds, not as
in N 9s.
* You already run rolling upgrades/patching and don't want to lose
that ability or switch to standby first upgrades/patching
* Your workload is already larger than the largest physical machine
you have can cope with.
If the last one is your use case for RAC then the Oracle VMs won't be a great size for a platform that's designed to enable efficiency among lots of relatively small workloads. It's possible they'll be too large for the underlying ESX hardware anyway. If you actually have a bunch of smaller workloads that you wish to consolidate and you don't meet the criteria above then it's probable that single instance (perhaps SIHA for automatic restarts) is a better bet for you. It plays much more nicely with the VMWare architecture.
Some things you need to remember.
* You'll need to allocate thick provisioned multi-writer disks for
the database storage - this means that some VMWare features aren't
available to you.
* You should ensure that you apply anti-affinity policies to make
sure the RAC nodes don't all end up on the same physical hardware!
* You'll need a specific private network(s) for your RAC clusters.
* You may well have added licensing headaches to deal with.
* VMWare admins are often big fans of overallocating CPU and Memory
- this tends to work very, very badly indeed with
performance-sensitive database workloads.
* RAC clusters often have high-performance SAN storage dedicated to
them. Virtualized databases tend to have shared (often lower
performance) storage. If your database application is extremely
I/O demanding then a VMWare platform may struggle. VMWare can help
with identifying this.
On Thu, Aug 6, 2020 at 2:08 AM Hameed, Amir <Amir.Hameed@xxxxxxxxx <mailto:Amir.Hameed@xxxxxxxxx>> wrote:
Hi,
Our data center is in the process of doing hardware refresh and
their priority is to move every physical server to VMWare VM.
Currently, we primarily run middleware and some single instance
databases on VMWare but all databased that are RAC’d are
configured on physical servers. I believe that Oracle didn’t
certify RAC on VMWare until recently. I am reaching out to this DL
to find out:
1.Are there folks on this DL running Oracle RAC on VMWare and what
has been their experience?
2.Are there any caveats of running Oracle RAC on VMWare?
Any feedback will be greatly appreciated.
Thank you,
Amir
--
Niall Litchfield
Oracle DBA
http://www.orawin.info
