Re: Oracle RAC on VMWare

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
>

--
http://www.freelists.org/webpage/oracle-l