RE: Oracle RAC on VM
Date: Fri, 22 Aug 2014 12:17:44 -0600
Message-ID: <003501cfbe35$5f3cadb0$1db60910$_at_gmail.com>
This did help a lot, Tim. I’m actually more open-minded than I implied but wanted to be upfront with my current mindset. When I started here as a DBA, I had to do some creative server configuration and tuning on Linux VMs that I never had to do on physical servers in my previous jobs. The creation of the architecture predated me so it’s possible that it wasn’t set up correctly, or optimally at least, for Oracle. Moving forward, I’m working with all the teams and management to look at the whole stack and redesign where necessary.
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Tim Gorman
Sent: Friday, August 22, 2014 8:44 AM
To: oracle-l_at_freelists.org
Subject: Re: Oracle RAC on VM
Kevin,
I had to endure debates 20 years ago when some people felt that RAID-0 striping in storage consumed more processing than it provided benefit. Around the same time, debate about setting the Oracle parameter TIMED_STATISTICS was rife. I argued that the additional processing in capturing timings within the V$ views more than compensated the effort to do so by getting rid of meaningless ratios and providing the best tuning metric of all: time. Up to the late 1990s, I frequently encountered production systems with TIMED_STATISTICS=FALSE set by DBAs who felt they were wringing every last cycle from the database, when in fact they turned the database into a black box which could not be optimized scientifically. Before that, in the 1980s, I recall a debate with a VAX VMS sysadmin who asserted that compiling a program with certain optimizations enabled consumed more system resources than the program saved over the program's lifetime. He also argued that compiling a program more than 10 times during the course of development was negative ROI as well, that developers should think long and carefully before compiling. Almost 30 years later, I'm still coming up with retorts that I wish I had thought of back then.
So I believe that the argument that the hypervisor as intermediary processing sapping performance is likewise missing the most important points and is disastrously incorrect. You have to break eggs to make an omelette. As long as you're not using any of the 43 remaining Faberge eggs or those from an endangered species, the omelette is worth it.
There is a misconception that virtual machines exist only in a free-for-all environment involving a cloud of virtuals on a small number of overworked physicals, resulting in unpredictable performance and behavior. This can be true, and frequently is true.
Virtual machines used in production are often configured with vCPU and vRAM reservations, so that the resources are reserved for their use only and are never allocated to other virtual machines. Setting VM hyperthreading to "none" is a way to prevent dilution of CPU as well. And of course, virtual machines can always be configured 1:1 on physical servers if desired.
Six years ago I was hired by a public transportation agency to assist them implementing Oracle RAC and DataGuard. It turned out that none of their applications consumed more than half the resources of their servers, so there was no need for the scalability of RAC, and so I talked them out of that. Then, with VMware VMotion replicating entire virtual machines and not just the database (as with DataGuard) leaving the necessity to replicate file-systems with rsync, it was easy to convince them to use VMotion for fault-tolerance and high-availability. As they had only one data center at the time, business continuance and disaster recovery was not in scope. This allowed the government agency to avoid the operate their Oracle databases as straight standalone non-RAC non-DataGuard instances, applying the KISS principle where it was needed most.
So, although it was cushy government contract in a downtown location likely to last for years, I talked myself out of that contract within 6 months. My prime contractor was surprised and a bit disappointed, and Oracle sales was angry enough to spit nails, but it was the right course for them and I'd do the same thing again.
However, sometimes folks can't be saved; they later bought an Exadata, so Oracle got their licenses back in the end. :-)
Hope this helps...
-Tim
On 8/22/14, 2:01, przemolicc_at_poczta.fm <mailto:przemolicc_at_poczta.fm> wrote:
Pro VM:
- snapshots before any patching, upgrade - very, very handy feature :-)
- performance: we migrated some Oracle-s (EBS) to Vmware and nobody is complaining (it is not very loaded though ...)
Regards
P.
Od: "Kevin Lidh" <mailto:kevin.lidh_at_gmail.com> <kevin.lidh_at_gmail.com>
Do: oracle-l_at_freelists.org <mailto:oracle-l_at_freelists.org> ;
Wysłane: 0:16 Piątek 2014-08-22
Temat: Oracle RAC on VM
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:
- Servers closer to the storage for performance. In virtualization, you have an intermediary processing your requests and responses.
- 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.
- 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
--
http://www.freelists.org/webpage/oracle-l
Received on Fri Aug 22 2014 - 20:17:44 CEST