Re: oracle on VM or non-VM ?!!

From: Tim Gorman <tim.evdbt_at_gmail.com>
Date: Sun, 26 Nov 2017 13:27:10 -0700
Message-ID: <a04f4cf1-6227-760c-3e4c-5dcfa7005d66_at_gmail.com>



Expanding on a few of Andrew's points, I can't believe that it has been almost 10 years now, but it has...

9 years ago, I was hired by our local rapid-transit agency specifically to assist in deploying Oracle RAC and Oracle DataGuard.  At that time, they had also begun using VMWare ESX with HA, VMotion, and Storage VMotion for their internal infrastructure.

Oracle RAC is a scalability option only -- it was not designed as an HA solution and any HA capabilities it possesses are necessary for it to simply exist.  So, if more horsepower is needed, then scale up with hardware until the limit for the chosen hardware platform is reached.  Beyond that limit, use Oracle RAC to continue to scale up across servers.

For database high-availability (HA), use Oracle DataGuard.  Period. Full stop.

Long story short:  none of their systems needed to scale beyond the hardware limit of their chosen platform, so there was no need for Oracle RAC.  Also, database change rate was well within the capabilities of Storage VMotion, and so with VMware HA, VMotion, and Storage VMotion, they had a more comprehensive solution for HA than DataGuard, because VMware would move the entire environment, not just the database as DataGuard would.

So I scotched the two reasons I was originally hired, and my 18-month engagement was concluded in 4 weeks.  I had talked my way out of a decent gig, but as a taxpayer it was the responsible solution.  While it is joyous and wonderful to deploy the right tools on a job, it is excruciatingly painful and downright frustrating to deploy the wrong tools for a job.

But, Oracle sales was very unhappy.  Their response was to begin a campaign to paint the customer's infrastructure team as incompetent, "incapable" of understanding "advanced features" like RAC and DataGuard.  Four years later, after turnover in staff and management, they became an Exadata shop.  So it goes...


Having said this, understand that Oracle will license based on the core count in the ESX host or hosts in a virtual machine cluster. They will not bother with niceties about virtual machines being restricted to individual nodes within a cluster, even if VMware says it will "back you up" on such a restriction.  If any VM within a cluster runs Oracle, then all of the cores in the cluster will be licensed by Oracle.  So, understanding this, it is important to designate a hypervisor cluster entirely for Oracle use only if concerned about maximizing Oracle licensing.  Just my US$0.02...


Answering your questions directly...

  1. Does Oracle on VM (type 1) have notable perf issues ?      A1) No.  There are always issues in any configuration, but nothing notable, inherent, or pervasive
  2. Does license cost (or TCO) increase with VM/Oracle combination?      A2) No, TCO will decrease with VM/Oracle in some situations (see comments above)
  3. Is RAC on VM widely used ?      A3) I don't know
  4. RAC on non-VM or single instance on VM - which is good from a HA perspective ?      A4) RAC is not an HA solution, so non-RAC on VM with either DataGuard or VMware HA/VMotion/StorageVMotion
  5. If VM is advisable, VMware or Oracle VM - which works best overall ?      A5)  I don't know.  Oracle VM is probably less expensive, but VMware probably has better features

On 11/26/17 12:35, Andrew Kerber wrote:
> My company, House of Brick technologies specializes in virtualizing
> oracle. I am not a licensing expert, I specialize in Oracle, and
> moving from physical to virtual.
> I can say that rac works just fine on VMware, but with VMware HA, the
> need for RAC is much reduced.
>
> Most companies determine that VMware HA is sufficient for their needs,
> though we have moved several from rac on physical to rac on virtual.
>
> The performance difference between oracle on physical and Oracle on
> Virtual Machines is basically nonexistent. There is a certain amount
> of tuning that needs to be done to optimize performance on physical
> machines, but once tuned the difference in performance is non-existent.
>
> We have been around for about 20 years, so we have a lot of experience
> in this area.
>
> http://houseofbrick.com/expert-services/professional-services-consulting/
>
>
> On Sun, Nov 26, 2017 at 1:32 AM, JP . <jprem_at_outlook.com
> <mailto:jprem_at_outlook.com>> wrote:
>
> Friends,
>
> we want to move all our existing prod oracle databases (around 20
> instance, max db size ~500G) from our old h/w (non-VM) to new
> ones. HA,easy manageability, performance,cost being the key
> factors considered for the new machines , would like to know if
> VM(type-1) would suit our needs.
>
> I was looking for "VM or non-VM" kind of articles (from a license,
> HA , performance perspective). But could not come to a conclusion.
> It's a bit confusing. Want to clarify with experts here.
>
> 1) Does Oracle on VM (type 1) have notable perf issues ?
> 2) Does license cost (or TCO) increase with VM/Oracle combination ?
> 3) Is RAC on VM widely used ?
> 4) RAC on non-VM or single instance on VM - which is good from a
> HA perspective ?
> 5) If VM is advisable, VMware or Oracle VM - which works best
> overall ?
>
> Your advice and inputs would be very much helpful. Thanks in advance.
>
> ~ JP ~
>
>
>
>
> --
> Andrew W. Kerber
>
> 'If at first you dont succeed, dont take up skydiving.'

--
http://www.freelists.org/webpage/oracle-l
Received on Sun Nov 26 2017 - 21:27:10 CET

Original text of this message