I’ve been seeing a lot of commentary on the Oracle support policy change that happened last week, and I think some people are missing a big distinction here:
It isn’t so much that Oracle now supports VMware, but that Oracle no longer doesn’t support VMware, if that makes sense. They aren’t supporting VMware, but they aren’t not supporting it, either.[0]
Article 249212.1 in Oracle’s Metalink states:
Oracle has not certified any of its products on VMware virtualized environments. Oracle Support will assist customers running Oracle products on VMware in the following manner: Oracle will only provide support for issues that either are known to occur on the native OS, or can be demonstrated not to be as a result of running on VMware.
If a problem is a known Oracle issue, Oracle support will recommend the appropriate solution on the native OS. If that solution does not work in the VMware virtualized environment, the customer will be referred to VMware for support. When the customer can demonstrate that the Oracle solution does not work when running on the native OS, Oracle will resume support, including logging a bug with Oracle Development for investigation if required.
To me, this means that if you don’t want to get caught between Oracle support saying it’s a VMware problem and VMware support saying it’s an Oracle problem you still need a physical host in your implementations. Chad Sakac, who also has a great post on this news, mentions using EMC V2P tools for this, but for my organization we’re just putting one physical host in our clusters, alongside a bunch of virtual hosts. We get all the benefits of virtualization for the application plus the ability to instantly prove it’s an application bug vs. a virtualization problem, so we don’t get stuck between two vendors pointing their fingers at each other when we have a service down. We won’t get to 100% virtualization, but it’s not as bad as it was, and we certainly don’t have to buy a really expensive physical machine, either.
Overall, I agree with the general assessment that this is progress, but this was actually the easy step. Oracle’s products tax performance and technology and routinely exercise bugs in operating systems, drivers, and hardware. To get Oracle to fully support another layer of abstraction, with all new & different performance problems, bugs, and odd interactions, is going to be a way bigger battle.
————————–
[0] Bart Simpson: “Dad, are you licking toads?” Homer Simpson: “I’m not not licking toads.”
You still have to be prepared for the sticker shock that will ensue when you realize that you need to license every processor core of every host that might run Oracle instances, regardless of current load or resource partitioning. That’s made it a non-starter in our shop. There’s no reasonable way to dip a toe in the pool and have HA. Plus our DBAs think they’ll get crappy performance.
the wording in that metalink article you quote doesn’t really look any different from the last time I looked at it 3 years ago(10gR2), where Oracle said the same thing — they’ll support the issues as long as you can reproduce the problem on real hardware. Maybe the “referring to vmware support” is new, but doesn’t look like any change.
For the first commenter, I’d suggest you investigate using Oracle SE (not SE One), get a couple of servers with 1 CPU in each system(dual socket with 1 cpu populated), I’d suggest 12 core opteron 6100 of course, and run Oracle SE with RAC for an easy HA solution. RAC is included in the cost of SE. Your looking at roughly $40k in license fees(assuming your using per socket perpetual licensing), and you can expand it to a max of 4 servers(or 4 sockets take your pick).
If you tried the same with Oracle EE you’d be out $120k for 2 sockets and RAC (RAC is billed separately for EE). EE and SE do have slightly different feature sets, so depends on your requirements. Last company I was at that used Oracle(about 3 years ago) had absolutely no trouble going from EE to SE. Using EE from the beginning was a big mistake for them especially given that they only licensed SE One.
You could run VMware as well of course, at least 2-3 years ago VMware did not support running systems with 1 CPU(regardless of # of cores), not sure what their stance is on it now.
As long as you have no Oracle in production, Oracle at one time at least(maybe still does) have a policy where you can use their product for free for development purposes until it gets to production, then at that point you have to pay for both production and development systems. So provided your not in production you should be able to dip your toes in and play around w/o an issue, assuming this policy is still in place(not sure if it was an official or “unofficial” policy). Support is a different matter of course.
Bob, when you say “we’re just putting
one physical host in our clusters, alongside a bunch of virtual hosts” I assume you are talking about clusters like Red Hat or Solaris clusters? If so, I’m curious – how do you share SAN storage between the physical and virtual cluster nodes, RDMs or NPIV in VMware?