Re: Oracle RAC on VMWare

From: Mladen Gogala <gogala.mladen_at_gmail.com>
Date: Fri, 7 Aug 2020 13:16:45 -0400
Message-ID: <bf1040e2-fd9e-4ebd-ada6-f20ef500ee7e_at_gmail.com>



There is a legendary paper by Moans Nogood called "You probably don't need RAC". Mr Nogood, whom I would very much like to meet in real life, discusses various aspects of RAC architecture and what exactly RAC can be used for.  Despite all the advances in RAC technology since that paper was written, that paper is still relevant today. It is doubly as relevant for the VMWare consideration. First of all, RAC is a fault tolerance option, not a performance option. If you want to performance out of the application accessing RAC, you will have to ensure the locality of reference, also known as "functional partitioning", else global cache locks will kill the performance. RAC utilizes all the hardware of your nodes, in particular fast Ethernet and and CPU "test and set lock" instruction for needles and pins. VMWare throttles network connections so 10Gb Ethernet will give you approximately 2Gb real throughput. The "test and set lock" instruction is emulated on the virtual CPU and is thereby much slower than the real thing which utilizes bus and MMU. What would be the business use for such "snailfied" RAC? Personally, I don't see one. RAC is one of the methods for ensuring database accessibility in case of a single component failure. By introducing VMWare into the mix, you simply increase the number of components that can fail, without any visible benefits.

On 8/7/20 10: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
> <mailto: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

-- 
Mladen Gogala
Database Consultant
Tel: (347) 321-1217


--
http://www.freelists.org/webpage/oracle-l
Received on Fri Aug 07 2020 - 19:16:45 CEST

Original text of this message