You and me both, Tim! This is one of the best “RAC Reality” summaries I’ve seen.
Clay Jackson
Database Solutions Sales Engineer clay.jackson_at_quest.com<mailto:clay.jackson_at_quest.com>
office 949-754-1203 mobile 425-802-9603
From: oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> On Behalf Of Tim Gorman
Sent: Friday, August 7, 2020 10:04 AM
To: niall.litchfield_at_gmail.com; Amir.Hameed_at_xerox.com
Cc: oracle-l_at_freelists.org
Subject: Re: Oracle RAC on VMWare
CAUTION: This email originated from outside of the organization. Do not follow guidance, click links, or open attachments unless you recognize the sender and know the content is safe.
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_at_gmail.com<mailto:niall.litchfield_at_gmail.com> 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!
