Re: Oracle RAC on VMWare

From: <niall.litchfield_at_gmail.com>
Date: Mon, 10 Aug 2020 11:29:12 +0100
Message-ID: <CABe10saTGREbzXmFKaY9H+g6oy6bQhjOGHnAynbkEN=qr9ZX2g_at_mail.gmail.com>



Thanks for the update Mikhail - I'd either forgotten or missed the change to object space reservation. It doesn't look as though the list of unsupported operations has changed though.

On Fri, Aug 7, 2020 at 4:56 PM Mikhail Velikikh <mvelikikh_at_gmail.com> wrote:

> Hello,
>
>
> -
>>
>> 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.
>
>
> - This restriction has been lifted recently:
> - https://kb.vmware.com/s/article/2121181
> -
> -
> -
>>
>> Using Oracle RAC on a vSphere 6.x vSAN Datastore (2121181)
>
> -
>
>
> -
>
> Starting VMware vSAN 6.7 Patch 01, Oracle RAC on vSAN does NOT require
> the shared VMDKs to be Eager Zero Thick provisioned (OSR=100) for
> multi-writer mode to be enabled. Shared VMDKs can be thin provisioned
> (OSR=0) for multi-writer mode to be enabled. For existing Oracle RAC
> deployments migrating to this vSAN 6.7 Patch 01 vSAN version or higher ,
> one can use SPBM (Storage Policy Based management) to change the existing
> storage policy from OSR = 100 to OSR =0 ( Or vice versa if required). This
> is an online change and does not require a downtime.
>
>
>
>
> Best regards,
> Mikhail Velikikh
>
>
>
> On Fri, 7 Aug 2020 at 15:44, <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
>>
>

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

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

Original text of this message