RAC performance on Vmware

Question

Hello to all
Last month I have been assigned an assignment to work on RAC. Our application is a data ware housing and we striving for performance. Our high management orders me to implement Rac for performance. I have started work on RAC. And submit my finding. I found that RAC is slower on VMware software
We have installed the oracle RAC software on the followings:
Two VM machines (with 4 GB ram each, 1 Processor each with hard drive space 50Gb each)
     Two Physical machines with following specs:
•     Intel Core 2 Duo (2.0 GHZ)
•     2 GB ram each
•     80 GB SATA Hard Drive each
•     One Shared Drive on network (SATA 80 GB)
•     Two LAN card on each system (1 Giga bits each). One for private and other for public.
o     VM Performance Issues
     We are facing following issues on VM machines:
•     Slow I/O (Very slow loading and execution performance)
•     CPU was on 100 % without any activity
•     The VM machines were on a single server thus they were sharing the same physical hard drive and LAN cards
But today my Boss sends me an article in which claim that RAC is faster on VMWARE software instead of Physical machine. Now I have to answer to higher management. I could not understand what I said. Becoz during my experiment it perform very poor. Plz help me or suggest me what is your opinion. I’m waiting for your reply
Link of article
http://www.channelregister.co.uk/2009/05/08/oracle_vmware/ ?
Regards
Edited by: Oracle Studnet on May 11, 2009 3:01 AM

Answer 1

Hi Oracle Student,
I see a few problems here. First off, I think the author of the article, Chris Mellor, may have misunderstood the comments made by Chuck Hollis of EMC and/or The Oracle Storage Guy (both linked to in Mellor's article), and I think that you and your management definitely have misunderstood something.
It sounds to like you're running RAC nodes on virtual hosts? That's just crazy, and makes no sense!
First off, RAC is NOT a performance solution. It's a high availability solution! The only time it makes sense as a performance solution is when your application's requirements are so large, you can't buy a single node that's large enough to support your app! So, for example, your application is well-designed and optimized, and it still needs more performance than you can get from a Sun E25K or HP Superdome, etc. Machines in this class have on the order of 256 CPUs and hundreds of GBs (possibly into the TBs) of RAM. This level of hardware is on the order of 10s of millions of dollars. There are VERY, VERY FEW applications that really need this kind of capacity. If you are one, then it makes sense to look at RAC for PERFORMANCE. Otherwise, RAC is NOT a performance solution!
It is, however, a high availability solution! So, if you need to provide an Oracle database in a high availability environment, then RAC is (part of) the solution. It will provide high availabiliy at OS/node level. If a server crashes, this is where RAC is beneficial. It won't do anything for disk/SAN failure, though. (That's where DataGuard would come in.)
Finally, if you read the two blogs cited in the article you provided the link to:
http://chucksblog.emc.com/chucks_blog/2009/05/why-oracle-doesnt-like-vmware.html
http://oraclestorageguy.typepad.com/oraclestorageguy/2009/05/response-to-comments-from-alessandro-perilli-blog.html
If you read those, it becomes obvious that they're comparing RAC on physical hardware to single-instance on VMWare. It makes NO SENSE to run RAC on two virtuall machines, particularly if the two VMs are on the same physical machine.
What they are describing is the following:
Suppose you have two nodes, let's say they are HP DL-585s, each w/ 4 dual-core CPUs and 64 GB of RAM. (Just two hypothetical, typical pieces of hardware.) Now, your requirement is to best utilize these two nodes to provide high availability for two databases. How do you do it?
Well, there are two solutions (possibly more, but these are the two relevant ones) to consider:
RAC or VMWare.
RAC:
You set up your two nodes in a cluster, load Oracle Clusterware, possibly ASM, the Oracle database software. You create two databases, call them db1 and db2. Each node will run an instance of each db. So, node1 will have instances db1-1 and db2-1. Node 2 will have db1-2 and db2-2. So, (assuming that a single node has enough capacity to support all your users), you have server-level high availability. If a node crashes, (assuming properly configured failover, TAF, FAN, etc) the users would fail over to the remaining node.
VMWare:
Same two physical nodes as before. This time, you install VMWare, and set them up in VM cluster, and you define that each of your nodes will host one VM, and it can failover to the other node. Now, install single instance Oracle on each VM. VM1 will host db1, and VM2 will host db2. Now, in the event of a failure, VM1 (with db1 running inside of it) could failover to node 2, or VM2 could failover to node 1.
So, there are similarities here. In each case, high availability is provided for node failure, either via RAC or VMWare. So, why run one or the other? Well, the article author seems to imply that VMWare is cheaper, and it very well may be true. So, there's a cost advantage to running RAC.
What about RAC advantages? Well, RAC is more tightly integrated w/ the database, and with some effort (TAF and FAN configuration) it can be even more tightly integrated, which allows for much smoother failovers. In the event of a VMWare failover, there will certainly be a longer hang/pause when failover occurs.
Some other thoughts to consider are:
- RAC is generally going to be managed by the DBA
- VMWare, most likely, managed by a sysadmin. How does that fit into the picture at your company? It may or may not work for you, depending on your company, etc.
Bottom line, and the take-away idea here, is to compare RAC on physical hardware vs. single instance Oracle on VMWare cluster! Comparing RAC on bare metal to RAC on VMWare doesn't make any sense.
Hope that helps,
-Mark