Re: Oracle RAC on VM
Date: Fri, 22 Aug 2014 09:17:35 -0600
Message-ID: <53F75F0F.70608_at_gmail.com>
If I were to summarize (please correct me if I'm wrong Tim), I'd have to say
"VM, RAC, etc. are all tools. Understand the tools, so you can use the right one for the job."
For me,
RAC is often overkill in it's intended form. As a means of virtualizing Oracle services (think vMotion-like between instances) and especially now with Multi-Tenant, it has the ability to shine.
Ditto VM, whether OracleVM (which I like) or VMWare (which I don't dislike, except for Oracle licensing). As long as the underlying hardware supports the entire load (no CPU or memory overcommit, no sparse disk allocation for DB/ASM/FRA), the networking is satisfactory (no VLAN w/ spanning tree, heartbeat & vMotion on separate NIC), and as long as the admins understand the parameters to set it up correctly for the load (as compared to 'I found this setting on the internet') I believe VM capabilities provide a new level of benefit to the environment. But as with any tool, it is easy to abuse.
Based on my experiences squashing OPS (years ago), helping several customers with VMWare and OracleVM, and now some Exadata fun times.
/Hans
On 22/08/2014 8:44 AM, Tim Gorman wrote:
> 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 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" <kevin.lidh_at_gmail.com>
>> Do: 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:
>>
>> 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
>>
>>
>>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Fri Aug 22 2014 - 17:17:35 CEST