Re: Oracle RAC on VMWare

From: <niall.litchfield_at_gmail.com>
Date: Mon, 10 Aug 2020 11:29:43 +0100
Message-ID: <CABe10sZW9k7SuEh1TZrJgZ-xWknBxhJ5mtzi=aU5BZMC7e4Hdg_at_mail.gmail.com>



Aww shucks guys, I'm blushing now.

On Fri, Aug 7, 2020 at 6:50 PM Clay Jackson (cjackson) < Clay.Jackson_at_quest.com> wrote:

> 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
>
> *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 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_at_xerox.com> 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
> <https://nam05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.orawin.info%2F&data=02%7C01%7Cclay.jackson%40quest.com%7Cc8458cc735b34f99eb1708d83af410ac%7C91c369b51c9e439c989c1867ec606603%7C0%7C0%7C637324167207359792&sdata=wXG5whevRKBnu0XYpQ7BXIzZHO3Z%2FSAnVpWoubq8aCA%3D&reserved=0>
>
>
>

-- 
Niall Litchfield
Oracle DBA
http://www.orawin.info

--
http://www.freelists.org/webpage/oracle-l
Received on Mon Aug 10 2020 - 12:29:43 CEST

Original text of this message