Re: Oracle RAC on VM

I do prefer Oracle on physical, but there are situations where virtualisation helps a lot.

Once, I've implemented a two-node vmware cluster with several RAC "virtual clusters":
- two-nodes cluster, two processors multi-core with many virtual RAC clusters deployed
- by default, each RAC had one node on one ESX and the other node on the other ESX
- no vmotion
why?
The RACs were all Standard Edition. This configuration helped in simulating instance caging on SE by creating VMs with few vcpus. Also, the environment was multitenant (many customers/departments on it) and this solution allowed us to offer competitive prices that would have been impossible with EE.
Moreover, the Standard Edition license would have made possible to scale the architecture to many fully-licensed ESX nodes.

Best regards

-- 
Ludovico




2014-08-22 17:07 GMT+02:00 John Piwowar <jpiwowar_at_gmail.com>:



> I hear this argument often, and when I do, I encourage people to consider:

>

> 1) if you open an SR and Oracle thinks it's a hardware or OS problem, they

> will likely direct you to the HW/OS vendor. No reason to expect anything

> different with hypervisor problems.

>

> 2) If *Oracle* is your HW, OS, or hypervisor vendor in a situation where

> one of this components of you stack is suspected, you can expect your SR to

> be moved to an appropriate group.  It's not "one throat to choke," it's a

> hydra. ;-)

>

> I'm a fan of virtualization in principle, but like any

> platform/infrastructure decision, it's not a one-size-fits-all solution.

> The licensing issue, already discussed in the thread, is a legit concern

> with VMWare, but people also find a way to either live with it or work

> around it. Performance *could* be an issue, but you really don't know that

> until you run some tests with your workloads and can quantify the

> differences. Then you (as an organization, not Kevin ;-) get to decide if

> those differences are significant enough to impose the operational overhead

> of introducing an exception to your strategic direction.  Your best bet is

> to be prepared for a data-driven discussion.  :)

>

> This is coming off sounding a bit lecture-y and jerky, and I apologize. I

> blame email, lack of coffee, and typing with thumbs. ;) Good luck with the

> decision/exploration.

>

>

> On Friday, August 22, 2014, Justin Mungal <justin_at_n0de.ws> wrote:

>

>> If you open an SR and Oracle thinks it's the hypervisor, they will tell

>> you to reproduce the issue in a non-virtualized environment in order to

>> continue getting support. This has never happened to me, but we don't have

>> that many virtualized systems running Oracle.

>>

>>

>> On Thu, Aug 21, 2014 at 5:14 PM, Kevin Lidh <kevin.lidh_at_gmail.com> wrote:

>>

>>> As a DBA, I never wanted to work on Oracle on VMware but it seems to be

>>> the trend.  Now that I’m a manager, I’m looking to propose moving to RAC

>>> for HA and also back to physical machines.  Since this goes against the

>>> strategic direction of our organization, I’m sure I’ll be asked why we

>>> can’t do RAC on VMs.  I have my personal opinions about this but I was

>>> wondering what the broader audience of experts believe.

>>>

>>>

>>>

>>> Factors I’m considering are:

>>>

>>> 1)      Servers closer to the storage for performance.  In

>>> virtualization, you have an intermediary processing your requests and

>>> responses.

>>>

>>> 2)      Access to all resources licensed.  We keep a certain percentage

>>> of our hosts free to handle the load in case one in the cluster fails.

>>> With RAC, you have access to all the resources all the time.  And since you

>>> have to pay for it all anyway, I see that as a good thing.

>>>

>>> 3)      Performance in general.  I don’t have any evidence but I can’t

>>> believe that another layer between my OS calls and the hardware could be as

>>> fast as not having that layer.

>>>

>>>

>>>

>>> Thanks in advance,

>>>

>>>

>>>

>>> Kevin

>>>

>>

>>

>

> --

> Sent from a mobile device, because leaving the couch to find a real

> keyboard would unnecessarily delay this vital communication. So would

> proofreading, so don't be surprised by typos.

>


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