re: if you run vmware don't
For rebuttal see
http://houseofbrick.com/managing-oracle-licensing-in-a-shared-storage-environment/
Also see this long post on the "entire agreeement" concept at
http://houseofbrick.com/oracle-licensing-soft-partitioning-on-vmware-is-your-contractual-right-2/
Iggy
--
Iggy Fernandez
Email: iggy_fernandez@xxxxxxxxxxx
Blog: Explaining
the Explain Plan
Author of Beginning
Oracle Database 12c Administration
Editor of the NoCOUG Journal
From: ian@xxxxxxxxxxxxxxxxx
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: consolidation
Date: Tue, 13 Oct 2015 17:53:43 +0000
I fall into Jeremy’s camp on this one. I imagine out of ignorance,. I
don’t understand the hardware savings over carving a machine into multiple
vms, each running its own database and listener, over running the same
number of databases and a single listener on a “real” server I can see
management advantages if for some reason you cannot use the same ORACLE_HOME
for all the databases, but I don’t see how you save on hardware.
Also if you run vmware don;t you have to license every CPU in the “vCenter”
cluster. Perhaps not problem if the cluster is dedicated to Oracle
Ian
On Oct 13, 2015, at 10:16 AM, Tim Gorman <tim@xxxxxxxxx> wrote:
I'll argue that the use-case of many small-memory instances is precisely
the most advantageous use-case for VM clusters, especially when you
consider how VM clusters share memory (shm, heap, etc) between VMs based on
workload.
But I think it is more important to consider the right metrics, which isn't
necessarily memory, because it generally isn't licensed. Same with IP
addresses. CPU is a heavily-licensed resource, and I challenge anyone to
come up with a more manageable and efficient use of CPU than VM clusters,
for any use-case or scenario. Licensing doubles down (or triples down, or
more) on the cost of a compute resource, and licensing unused CPU incurs a
double- or triple-penalty (or more).
Of course manageability is never to be short-changed, as human time and
availability should also be considered heavily-licensed, in a way. It is
probably the most finite of resources, though sometimes elastic. Having a
farm of custom stacked servers to manage is bad enough, trying to get some
redundancy into that dog's breakfast is nobody's idea of a good time.
Let's put it another way: if your own personal money was at stake to make
the most manageable and most cost-effective use of a limited amount of
physical resources to fulfill an open-ended current and future set of
workloads, would you really consider the "stacking" architecture that the
OP described? I would certainly have done so in 1995, and still did in
2005, but definitely not in 2015. There's a reason that the cloud has
become economically viable, and the root cause is virtualization.
If someone is managing dozens, hundreds, or thousands of Oracle instances
and they're trying to hand-roll re-invent virtualization (which is now a
very mature and predominant solution) using decades-old habits and
assumptions, then my BS detector starts beeping softly.
On 10/13/15 10:32, Jeremy Schneider wrote:
On Tue, Oct 13, 2015 at 11:25 AM, Tim Gorman <tim@xxxxxxxxx> wrote:
Q: Why isn't the hosting team and vendor proposing a VM cluster to runDefinitely a good architecture, but there is still a case to be made
VMs
on a template of one database instance and listener per VM instead?
A: Because then you wouldn't need as much hardware, and it would be too
easy to manage, and it would be more highly available, all of which
results
in lower M2V (a.k.a. money to vendor) and M2H (a.k.a. money to host).
for other modes of consolidation!
1) i do think VM-based consolidation makes a strong manageability argument
2) every VM needs an IPs, and in some cases that might be a limited
resource
3) if you have lots of small databases with small SGAs, then VM-based
consolidation might be very memory-inefficient. in that case you may
need *more* hardware to do VM-based consolidation that you'd need for
instance-level consolidation.
4) some apps support schema/tablespace-level consolidation which
probably beats everything else for efficiency. also 12c containers may
give these same efficiencies around RAM/SGA.
i had a blog post about this a few years ago...
http://ardentperf.com/2013/12/02/osp-2c-build-a-standard-platform-from-the-bottom-up/
but i've hijacked woody's thread now! changing the subject line...
--
http://about.me/jeremy_schneider
--
//www.freelists.org/webpage/oracle-l
��i��0���zX���+�� n��{�+i�^
